我在北京写的排错报告h3cte考试rip版本实验排错报告本次排错中，我使用分层方式进行排错。在各项排错以前，我首先在各路由器上通过displayipinterfacebrief，交换机上使用displaybriefinterface命令查看使用到的接口状态是否为up，通过查看确实为up。在sw2与sw3上使用dislink-aggregationsummary查看两端口正常加入聚合组。在r2，r5设备上通过displayinterfaces6/0查看广域网串口线路，查看ppp链路协商参数的5个up，说明广域网线缆工作正常。并且在各设备上ping与之直连的接口，均能够ping通，由此判断物理层没有错误。接下来开始对二层进行排错。错误点一。mstp多域及主备根不符合需求。根据需求，在sw3，sw1，sw2设备上通过disstpbrief命令查看stp工作状态，发现出现了mast端口。出现mast端口说明mstp中出现了多域，与题目需求的单域需求不符。接下来在各设备上通过disstpregion-configuration命令查看域配置信息，发现实例对应正确，但各设备的域名为mac地址格式，说明可能没有配置域名。在三台设备上通过stpregion-configuration进入stp域视图，通过命令region-nameh3c将设备域名命名为h3c，再通过activeregion-configuration激活配置后，再进入各设备通过disstpbri发现mast端口消失，多域故障解决。多域问题解决后，在sw1上通过disstproot，发现实例根端口与要求不符，与需求要求正好相反。进入sw2和sw3设备，通过discurrent-configuration|beginstp命令查看，发现在sw2上配置stpinstance1rootsecondary，stpinstance2rootprimary，sw3配置相反，证明主备根配置不符合需求。在sw2上通过stpins1ropri，stpins2rosec，在sw3上通过stpins1rosec，stpin2ropri，配置完毕后，在sw1上通过第1页共8页disstpro发现实例根端口与需求相符。至此，stp部分错误排查完毕。错误点二。ppp验证不符合需求。根据需求，ppp应为双向验证。但之前物理层排查时该链路通信正常。因验证过程是在ppp协商的lcp阶段协商的，如果ppp链路进入network状态后，再行配置的验证即无法生效。所以我在r2设备的s6/0口上，执行shutdown，undoshut命令，使链路重新进行连接。undoshut之后接口开始出现频繁的up/down，说明验证有问题。在r2设备s6/0口中通过disthis发现该设备接口有命令pppauthentication-modechap，说明本端开启了验证，但除此之外无其它ppp验证命令，说明配置不符合双向验证的需求。在r5设备s6/0口中通过disth发现该设备接口配置了pppchapuserr2，pppchappasswordsimpleh3c，但除此之外无其它ppp验证命令。说明本端在接口上发送用户名密码，但未开启验证。正常情况下，一段接口发送用户名密码，另一端开启验证，验证应当是通过的。但此处验证失败，说明r2上可能配置了错误的local-user信息或未配。回到r2设备上，通过dislocal-user命令，发现r2上确实配置了让r2用户，但service-type为lan-access。通过local-userr2进入用户视图，通过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。至此，ppp双向验证需求实现，本部分错误排查结束。错误点三：ospf邻居建立故障。根据需求，总部（sw2sw3rt1rt2）各设备应简历ospf邻居，属于骨干区域。但在各上述四设备上通过disospfpeer发现：第2页共8页sw2未与rt1建立邻居关系，rt1未与rt2sw2建立邻居关系，rt2上无任何邻居关系，只有sw2与sw3间的邻居关系正常；分部一区域area1中rt2与rt5之间也没有邻居关系。在sw2设备上通过disospferror，发现router-id项目计数数值较大，回到用户视图通过resetospfcounters将计数清除，稍后再查看发现该数值再次被计数，说明sw2与rt1间无法建立邻居关系是因为router-id的原因。到rt1设备上通过disospferr发现该设备上router-id及...
