1、我在北京写的排错报告 h3cte考试rip版本实验排错报告 本次排错中，我使用分层方式进行排错。 在各项排错以前，我首先在各路由器上通过displayipinterfacebrief，交换机上使用displaybriefinterface命令查看使用到的接口状态是否为up，通过查看确实为up。在sw2与sw3上使用dislink-aggregationsummary查看两端口正常参加聚合组。在r2，r5设备上通过displayinterfaces6/0查看广域网串口线路，查看ppp链路协商参数的5个up，说明广域网线缆工作正常。并且在各设备上ping与之直连的接口，均能够ping通，由此判断物
2、理层没有错误。 接下来开始对二层进行排错。 错误点一。mstp多域及主备根不符合需求。 根据需求，在sw3，sw1，sw2设备上通过disstpbrief命令查看stp工作状态，发现出现了mast端口。出现mast端口说明mstp中出现了多域，与题目需求的单域需求不符。接下来在各设备上通过disstpregion-configuration命令查看域配置信息，发现实例对应正确，但各设备的域名为mac地址格式，说明可能没有配置域名。在三台设备上通过stpregion-configuration进入stp域视图，通过命令region-nameh3c将设备域名命名为h3c，再通过activeregi
3、on-configuration激活配置后，再进入各设备通过disstpbri发现mast端口消失，多域故障解决。 多域问题解决后，在sw1上通过disstproot，发现实例根端口与要求不符，与需求要求正好相反。进入sw2和sw3设备，通过discurrent-configuration|beginstp命令查看，发现在sw2上配置stpinstance1rootsecondary，stpinstance2rootprimary，sw3配置相反，证明主备根配置不符合需求。在sw2上通过stpins1ropri，stpins2rosec，在sw3上通过stpins1rosec，stpin2ro
4、pri，配置完毕后，在sw1上通过disstpro发现实例根端口与需求相符。至此，stp局部错误排查完毕。 错误点二。ppp验证不符合需求。 根据需求，ppp应为双向验证。但之前物理层排查时该链路通信正常。因验证过程是在ppp协商的lcp阶段协商的，如果ppp链路进入network状态后，再行配置的验证即无法生效。所以我在r2设备的s6/0口上，执行shutdown，undoshut命令，使链路重新进行连接。undoshut之后接口开始出现频繁的up/down，说明验证有问题。在r2设备s6/0口中通过disthis发现该设备接口有命令pppauthentication-modechap，说明
5、本端开启了验证，但除此之外无其它ppp验证命令，说明配置不符合双向验证的需求。在r5设备s6/0口中通过disth发现该设备接口配置了pppchapuserr2，pppchappasswordsimpleh3c，但除此之外无其它ppp验证命令。说明本端在接口上发送用户名密码，但未开启验证。 正常情况下，一段接口发送用户名密码，另一端开启验证，验证应当是通过的。但此处验证失败，说明r2上可能配置了错误的local-user信息或未配。回到r2设备上，通过dislocal-user命令，发现r2上确实配置了让r2用户，但service-type为lan-access。通过local-userr2进
6、入用户视图，通过serppp将用户类型修改为ppp，并通过undoserlan将lan-access类型取消以加强网络平安。再进入r2设备s6/0口，shut，undoshut命令后，稍后发现ppp协商up，至此，ppp单向验证实现。 进入r5设备，通过dislocal-user命令查看r5设备是否配置了用户信息，发现r5上无任何用户。通过local-userr5，passsimh3c，serppp配置一个用户，回到r2设备s6/0口，使用命令pppchapusr5，pppchpasih3c，再回到r5上通过pppauthch，执行shut，undoshut后，稍后发现ppp协商up。至此，p
7、pp双向验证需求实现，本局部错误排查结束。错误点三：ospf邻居建立故障。 根据需求，总部（sw2sw3rt1rt2）各设备应简历ospf邻居，属于骨干区域。但在各上述四设备上通过disospfpeer发现：sw2未与rt1建立邻居关系，rt1未与rt2sw2建立邻居关系，rt2上无任何邻居关系，只有sw2与sw3间的邻居关系正常；分部一区域area1中rt2与rt5之间也没有邻居关系。 在sw2设备上通过disospferror，发现router-id工程计数数值较大，回到用户视图通过resetospfcounters将计数去除，稍后再查看发现该数值再次被计数，说明sw2与rt1间无法建立邻
8、居关系是因为router-id的原因。到rt1设备上通过disospferr发现该设备上router-id及area-id工程均有大量计数，并在显示中发现rt1与sw2设备router-id重复。通过命令ospf1router-id192.168.255.11将sw2的router-id修改为其loopback接口，回到用户视图通过resetospfpro，进程重启后sw2与sw3和rt1建立邻居成功。 回到rt1设备用户视图使用resospfcoun去除计数，再次通过disospferr查看，仅area-id数值一直上升，说明rt1与rt2之间无法建立邻居关系原因是区域错误。在rt1和rt2
9、上通过disospfinterface，发现rt1宣告正常，但rt2设备上g0/1/0和g0/1/1口应当被宣告在area0中，但却宣告在了area1中，应当被宣告在area1中的s0/2/0口被宣告在了area0中。进入ospf进程，undoarea0，undoarea1，再重新创立area0，area1，在area0中network2023.255.12.00.0.0.3，net2023.255.122.00.0.0.3，在area1中net2023.255.25.00.0.0.3，稍后发现rt2正常与sw3，rt1，rt5建立邻居关系。此时在sw2sw3rt1rt2上通过disospfp
10、eer发现应建立邻居关系的设备均已正常存在邻居关系。至此，ospf邻居建立故障排除。 错误点四：rip路由协议错误。错误点五：greoveripsec错误。 因分部二rip区域的排错可能需要先排除greoveripsec局部的错误，遂该两处错误点不严格遵循层次排错的思路，会根据实际需求进行思路转变，两局部排错思路和报告共同书写。 根据需求，rt1与rt3，rt4使用rip，通过greoveripsec隧道互联并学习路由。但在rt1设备上，发现与rt3相连的tunnul接口一直up/down。tunnul口震荡的原因可能是路由表中存在去往目标指向tunnul口的浮动静态路由，或者是在动态路由协议
11、中宣告了源端口。在rt1和rt3上通过disiprouting-tableverbose，未发现浮动静态路由。在上述两设备上通过displayrip，发现协议中宣告了loopback接口。在rt1和rt3上，进入rip视图，通过undonetwork192.168.255.0将loopback宣告取消，之后发现震荡现象消失，通过disiprou发现了rip的路由。但rt4设备的路由未正常学习，可能是做了相关屏蔽或gre隧道不通造成的。 由于greoveripsec使用了虚模板，触发应当由rt4发起。在rt4上，使用ping测试rt1的tunnul接口ip是否能够通信，结果无法通信。再测试公网，
12、发现rt4能够正常与rt1公网接口通信。通过disikesa，发现无信息，说明ike未配置，ipsecacl保护数据流错误，或者接口上未调用ipsecpolicy。 rt4设备上，通过disikepeer，发现未配置ikepeer；disipsecpolicy，发现未配置policy；在rt1上通过disikepeer，发现仅配置了关于rt3的peer，disipsecpolicytemp，发现只配置了关于rt3的模板。由此证明，rt1与rt4间无法通信的原因是ipsec漏配造成的。 在rt1全局视图下，通过disthis，发现配置了ikelocal-name为rt1，在rt4全局视图下，通过
13、disthis，发现配置了ikelocal-name为rt4，再通过disaclall，发现acl未配置。通过aclnu3000，rupeipso192.168.255.40de192.168.255.2023配置acl，再通过ikepeerrt1，exchange-modeaggressive，pre-shared-keysimpleh3c，id-typename，remote-namert1，remote-address20230.1.1.1配置rt4端ikepeer，通过ipsecproposal1创立提议，通过ipsecpolicyrt12023isakmp创立policy，通过sec
14、urityacl3000，ike-peerrt1，proposal1配置policy，最后进入g0/1/0口调用该policy。回到rt1上，通过ikepeerrt4，exchange-modeaggressive，pre-shared-keysimpleh3c，id-typename，remote-namert4配置关于rt4的ikepeer，通过ipsecpolicy-templatebranch20在branch模板上建立节点20，通过ike-peerrt4，proposal1绑定配置。操作完毕后，回到rt4设备上，pingrt1设备tunnul的接口ip，首先丢包一次，接下来通信正常，
15、rt4，rt1上disikesa，disipsecsa发现建立正常，在rt3上检查ikesa，ipsecsa配置，发现正常。至此greoveripsec排错完毕。 当rt4与rt1通信完成的同时，rt1上出现了tunnul口震荡的现象。回到rt4，通过disrip，发现rt4上宣告了tunnul接口，进入rip，通过undonet192.168.255.0撤销该宣告后，稍后rt1上接口不再震荡，rt1路由表中出现了rt4的相关路由。至此，greoveripsec局部及rip路由局部排错结束。 错误点六：通往总部业务网段的路由条目不符合需求 在rt1设备上，通过disiprouting-tabl
16、e发现去往总部的ab业务均指向sw2设备，在rt2设备上disiprou发现去往总部的ab业务均指向sw3设备，与题目需求不符。在sw2设备上进入intvlan20，通过ospfcost202300命令将开销改大，在sw3设备上进入intvlan2023，通过ospfcost202300命令将开销改大。执行后在rt1，rt2设备上通过disiprou，发现rt1的b业务指向rt2，rt2的a业务指向rt1，最终指向正确的地方，至此，总部选路局部排错结束。 错误点七：总部vrrp不符合题目需求 在sw2，sw3上通过disvrrp命令发现vrrp运行正常，主备根符合题目需求，但优先级是20230。通过disvrrpverbose发现两设备的优先级均为20230。正常情况下工作正常，但如果vr
