一、AR29的loopback0无法访问AR28的loopback0

image.png

1.1 故障根因判断

1.1 AR29的loopback0接口地址无法访问AR28的loopback0接口地址的根本原因在于AR29与AR28之间用于建立OSPF邻居关系的接口不在同一个广播域。

1.2 LSW6上连接AR29与AR28的接口VLAN划分错误。

1.2 故障分析

2.1 故障现象重现——在AR29上使用源地址为自身loopback0去pingAR28的loopback0接口地址，测试及输出结果如下所示：
image.png
通过以上输出结果可知，故障确实存在，由于AR29与AR28之间运行OSPF路由协议，进一步检查AR29的路由表中是否存在AR28的loopback0接口地址路由。

2.2 在AR29上使用命令display ip routing-table查看路由表中是否存在AR28的loopback0接口地址路由，输出结果如下所示：
image.png
通过以上输出结果可知，AR29的路由表中不存在AR28的loopback0地址路由，需要进一步检查AR29与AR28之间的邻居关系是否正常。

2.3 在AR29上使用命令display ospf peer brief查看与AR28的邻居关系是否正常建立，输出结果如下所示：
image.png
通过以上输出结果可知，AR29在OSPF域中与AR27、AR28建立OSPF邻居关系，所以初步判断OSPF配置错误，需进一步检查。

2.4 由于AR27与AR28、AR29处在同一个OSPF域中，所以可以通过AR27的测试结果来判断AR28的配置是否正确，输出结果如下所示：
image.png
image.png
通过以上输出结果可知，AR27与AR28之间OSPF邻居关系正常，且学习到了AR28的loopback0接口地址路由，所以判断AR28的OSPF配置正确，此时需要对比AR27与AR29的OSPF是否一致来判断AR29的OSPF配置是否正确。

2.5 在AR27/AR29上分别使用命令display ospf brief来检查对比配置，判断AR29的OSPF配置是否正确，输出结果如下所示：
image.png
image.png
通过以上输出结果可知，AR29的OSPF配置正确，并且将loopback0接口宣告进了OSPF进程中，需要进一步检查OSPF邻居建立是否有其它错误。

2.6 在AR29上使用命令display ospf error interface g0/0/0查看是否收到OSPF错误报文，输出结果如下所示：
image.png
通过以上输出结果得知，AR29用于与AR28建立邻居关系的接口G0/0/0没有收到任何OSPF错误报文，这种现象只有两种情况下会产生：一是OSPF邻居正常建立，二是接口没有收到任何OSPF报文。由于OSPF邻居关系没有正常建立，所以初步判断AR29与AR28之间用于建立OSPF邻居关系的三层地址不通，需进一步检查。

2.7 在AR29上使用命令ping -a 10.5.128.29 10.5.128.28来测试三层地址是否可达，测试及输出结果如下所示：
image.png
通过以上输出结果可知，AR29与AR28之间用于建立OSPF邻居关系的接口三层地址不通，需进一步检查二层地址是否可达。

2.8 在AR29上使用命令display arp查看是否有AR28的IP-MAC的映射，输出结果如下所示：
image.png
通过以上输出可知，AR29的ARP表中没有关于AR28的IP-MAC的映射关系，所以初步判断AR29连接LSW6的接口Down，需进一步检查。

2.9 在AR29上使用两次display interface g0/0/0命令查看接口状态是否正常，输出结果如下所示：
image.png
image.png
通过以上输出结果可知，AR29连接LSW6的接口物理及协议正常，并且两次测试结果中收到的组播报文数量在增加，所以可以判断端口正常。

综合分析：
通过以上测试结果可以发现，AR29的OSPF配置正确，AR29与LSW6直连的接口正常，AR28的OSPF配置正确，但是AR29与AR28之间用于建立OSPF邻居关系的接口三层地址及二层地址不可达。所以可以判断故障的根本原因在于AR29与AR28用于建立OSPF邻居关系的IP地址不在同一个广播域，LSW6上用于连接AR29与AR28的接口VLAN划分错误。

1.3 故障处理

3.1 LSW6上vlan划分错误的故障需在LSW6上执行以下命令：

display port vlan 确定连接AR27、28、29的接口VLAN不一致的情况
system-view 进入系统视图
interface {连接AR29的接口ID} 进入接口视图
port link-type access 将接口配置为access模式
port default vlan {与AR27、28一致的VLAN id} 配置连接AR29的接口vlan与AR27、28一致

执行完以上命令后在AR29上执行以下命令进行测试：

ping -a 10.5.128.29 10.5.128.28 AR29与AR28用于建立OSPF邻居关系的接口三层地址应该可达。
display ospf peer brief AR29与AR28之间应该正常建立邻居关系
display ip routing-table | include 10.5.1.28 AR29能够正常学习到AR28的loopback0接口地址
ping -a 10.5.1.29 10.5.1.28 AR29的loopback0能与AR28的loopback0互通，故障解决


3.2 其它高可能性故障——LSW6上配置了mux-vlan需要在LSW6上执行以下命令：**

display mux-vlan 确定哪些接口配置了mux-vlan
system-view 进入系统视图
interface {开启了mux-vlan的接口ID} 进入接口视图
undo port mux-vlan enable 关闭mux-vlan功能

执行完以上命令后在AR29上执行以下命令进行测试：

ping -a 10.5.128.29 10.5.128.28 AR29与AR28用于建立OSPF邻居关系的接口三层地址应该可达。
display ospf peer brief AR29与AR28之间应该正常建立邻居关系
display ip routing-table | include 10.5.1.28 AR29能够正常学习到AR28的loopback0接口地址
ping -a 10.5.1.29 10.5.1.28 AR29的loopback0能与AR28的loopback0互通，故障解决

3.3 其它高可能性——LSW6和AR28上配置了过滤策略则需要在AR28和LSW6上执行以下命令：

display traffic-filter applied-record 检查调用了ACL的接口
display traffic-policy applied-record 检查调用了traffic-policy的接口
system-view 进入系统视图
interface {相关接口ID} 进入接口视图
undo traffic-filter inbound/outbound 删除策略
undo traffic-policy inbound/outbound 删除策略

3.4 如果以上操作都未能排除故障，则需要用户提供完整的设备配置或前往用户现场进行排查，并拨打华为400服务热线请求华为TAC专家协助排除故障，谢谢！
**

二、AR29的loopback0无法访问AR33的loopback0

image.png

1.1 故障根因判断

  1. AR29与AR33的OSPF区域类型不匹配，AR29的OSPF配置为普通区域类型，AR33的OSPF配置为NSSA类型。
  2. AR29和AR33的Hello时间不一致，AR29的配置为10秒，AR33配置为15秒。

1.2 故障分析

2.1 故障现象重现——在AR29上使用命令ping -a 10.5.1.29 10.5.1.33测试故障是否存在，测试及输出结果如下所示：
image.png
通过以上测试结果可知，故障确实存在，由于AR29与AR33之间运行OSPF路由协议，所以进一步查看AR29的路由表中是否学习到了AR33的loopback0接口地址路由。

2.2 在AR29上使用命令display ip routing-table查看路由表中是否存在AR33的loopback0接口地址路由，输出结果如下所示：
image.png
通过以上输出结果可知，AR29的路由表中并没有AR33的loopback0接口地址路由，所以需要进一步检查AR29与AR33的OSPF邻居关系是否正常建立。

2.3 在AR29上使用命令display ospf peer brief查看正常与AR33建立full的邻接关系，输出结果如下所示：
image.png
通过以上输出结果可知，AR29与AR33之间没有建立OSPF邻居关系，需进一步判断OSPF邻居建立是否出现错误，由于邻居关系的建立依赖于底层连通性，所以下一步检查路由器之间的网络连通性。

2.4 在AR29上ping AR33的G0/0/1接口测试三层连通性，测试及输出结果如下所示：
image.png
通过以上输出结果可知，AR29可以ping通和AR33的互联接口，说明AR29和AR33之间无连通性故障，所以下一步检查接口是否发布到OSPF进程中。

2.5 在AR29上使用命令display ospf interface all查看接口是否宣告进OSPF进程中，输出结果如下所示：
image.png
由以上输出结果可知，AR29的loopback0和G0/0/1接口都发布在OSPF区域2中，并且得知G0/0/1接口网络类型是广播型，Hello间隔是10秒，Dead间隔是40秒，MTU是1500。由于OSPF邻居关系建立依赖于底层的连通性，所以下一步检查OSPF的错误信息来判断邻居协商的情况。

2.6 在AR29上使用命令display ospf error interface g0/0/1查看OSPF建立是否收到OSPF错误报文，输出结果如下所示：
image.png
通过以上输出结果可知，AR29用于与AR33建立邻居关系的接口上收到了关于Hello间隔错误的报文，说明AR29与AR33的Hello时间不匹配，而无法正常建立邻居关系。为确定是否还存在其它影响邻居无法建立的因素，需进一步检查。

2.7 在AR29上打开调试命令来确定AR29与AR33是否存在其它因素影响邻居关系的建立，测试及输出结果如下所示：
image.png
image.png
image.png
通过以上输出结果可知，AR29和AR33之间确实存在Hello时间不一致的情况（AR29：Hello Int：10；AR33：Hello Int：15），并且发现区域类型不一致（AR29：Option：E；AR33：Option：N），其中AR29被配置为普通区域，AR33被配置为NSSA区域。其它影响邻居关系建立的因素Router-id不冲突，DeadTimer一致（缺省为4倍的Hello时间），Area信息一致，接口掩码一致，Hello报文源地址在同一个网段，认证不存在错误。

综合分析

此故障产生的根本原因在于AR29与AR33的OSPF区域类型配置不匹配和Hello时间不匹配，从而无法形成邻接关系而导致无法计算路由。
**

1.3 故障处理

3.1 根据拓扑图可知，AR33与AR29处于OSPF区域2中，将AR33的Area2配置为普通区域，所以需要在AR33上执行以下命令解决此故障：

  1. system-view         //进入系统视图
  2. ospf 1              //进入OSPF进程1视图
  3. area 2              //进入OSPF区域2
  4. undo nssa           //将AR33的区域2配置为普通区域
  5. interface g0/0/1    //进入AR33的G0/0/1接口视图
  6. ospf timer hello 10 //将接口的Hello周期配置为10秒，与AR29保持一致


执行完以上命令后在AR29上进行以下测试：**

  1. display ospf peer brief     //检查AR29与AR33的OSPF邻居状态是否为full
  2. display ip routing-table    //AR29应该能学习到AR33的loopback0接口地址
  3. ping -a 10.5.1.29 10.5.1.33 //AR29的loopback0接口地址应该能与AR33的loopback0接口地址互通，故障解决

3.2 如果以上处理方式仍然不能解决AR29与AR33的loopback0互通的问题，则可能有以下几种高可能性：

AR33的loopback0接口没有宣告到OSPF进程中，需执行以下命令解决：

  1. system-view               //进入系统视图
  2. ospf 1                    //进入ospf 1进程中
  3. area 2                    //进入区域2中
  4. network 10.5.1.33 0.0.0.0 //将AR33的loopback0接口宣告进OSPF进程中

AR29和AR33在OSPF进程下做了路由过滤策略，需执行以下命令解决：

  1. display ospf brief            //检查是否做了区域策略
  2. system-view                   //进入系统视图
  3. ospf 1                        //进入OSPF 1进程下
  4. undo filter-policy xxx import //删除OSPF进程下的路由过滤策略

AR33的接口做了过滤策略，需执行以下命令解决：

  1. display traffic-filter applied-record //检查是否有接口ACL策略
  2. display traffic-policy applied-record //检查是否有接口policy策略
  3. system-view //进入系统视图
  4. interface {启用了策略的接口ID} //进入接口视图
  5. undo traffic-filter inbound/outbound //删除相关策略
  6. undo traffic-policy inbound/outbound //删除相关策略

执行完以上命令后在AR29上执行以下命令测试：

  1. display ospf peer brief     //检查AR29与AR33的OSPF邻居状态是否为full
  2. display ip routing-table    //AR29应该能学习到AR33的loopback0接口地址
  3. ping -a 10.5.1.29 10.5.1.33 //AR29的loopback0接口地址应该能与AR33的loopback0接口地址互通，故障解决

3.3 如果以上操作都未能排除故障，则需要用户提供完整的设备配置或前往用户现场进行排查，并拨打华为400服务热线请求华为TAC专家协助排除故障，谢谢！
**

2.1 故障根因判断

  1. AR29与AR33的OSPF区域类型不匹配，AR29配置为普通区域类型，而AR33配置为NSSA类型。

2.2 故障分析

2.2.1 故障现象重现——在AR29上ping测试AR33的loopback0接口地址，验证故障是否存在，测试及输出结果如下所示：
image.png
通过以上测试结果可知故障确实存在，需要在AR29上检查路由表中是否存在AR33的loopback0接口地址的路由。

2.2.2 在AR29上使用命令display ip routing-table查看路由表中是否存在AR33的loopback0接口地址路由，输出结果如下所示：
image.png
通过以上输出结果可知，AR29的路由表中并没有AR33的loopback0接口地址的路由，由于AR29与AR33之间运行OSPF路由协议，所以下一步检查AR29与AR33之间的邻居关系是否正常建立。

2.2.3 在AR29上使用命令display ospf peer brief查看与AR33的OSPF邻居关系是否正常建立，输出结果如下所示：
image.png
通过以上输出结果可知，AR29并没有与AR33建立任何OSPF邻居关系，由于OSPF邻居的建立依赖于底层的连通性，所以下一步检查路由器之间的网络连通性是否正常。

2.2.4 在AR29上使用ping命令测试与AR33的G0/0/1接口的3层连通性，测试及输出结果如下所示：
image.png
通过以上输出结果可知，AR29与AR33之间不存在连通性故障，所以下一步检查接口是否发布到OSPF进程中。

2.2.5 在AR29上使用命令display ospf interface all查看接口是否发布到OSPF进程当中，输出结果如下所示：
image.png
通过以上输出可知，AR29在区域2中发布了G0/0/1和loopback0接口地址，并且得知G0/0/1接口的网络类型为广播，Hello间隔为10秒，Dead间隔为40秒，MTU为1500。由于邻居关系的建立依赖于底层连通性，所以下一步检查OSPF的错误信息来判断邻居协商的情况。

2.2.6 在AR29上使用命令display ospf error interface g0/0/1查看是否收到OSPF邻居建立的错误报文，输出结果如下所示：
image.png
通过以上输出结果可知，AR29与AR33的Hello报文的Option比特位与对端不匹配，影响Option位的关键配置是区域类型，所以需要进一步通过Debug判断具体不一致的Option的参数。

2.2.7 在AR29上打开调试命令来确定AR29与AR33的Option协商参数，并判断是否还存在其它因素导致OSPF邻居关系建立失败，输出结果如下所示：
image.png
image.png
image.png
由以上输出结果可知，AR29与AR33区域类型不一致（AR29：Option：E；AR33：Option：N），其中AR29被配置为普通区域类型，AR33被被配置为NSSA区域类型。
其它影响OSPF建立的因素Router-id不冲突，Hello间隔一致，Dead间隔一致（默认为4倍的Hello时间），接口掩码信息一致，Area信息一致，Hello报文源地址在同一个网段，认证不存在错误。

综合分析:
此故障产生的根本原因在于AR29与AR33的OSPF区域类型配置不匹配，从而无法形成邻接关系导致无法计算路由。

2.3 故障处理

3.3.1 根据拓扑图可知，AR33与AR29处于OSPF区域2中，将AR33的Area2配置为普通区域类型，所以需要在AR33上执行以下命令以解决此故障：

  1. system-view  //进入系统视图
  2. ospf 1       //进入OSPF进程1
  3. area 2       //进入OSPF区域2
  4. undo nssa    //将AR33的区域2配置为普通区域

执行完以上命令后在AR29上进行以下测试：

  1. display ospf peer brief  //检查AR29与AR33的OSPF邻居状态是否为full
  2. display ip routing-table | include 10.5.1.33 //AR29应该能正常学习到AR33的loopback0接口地址
  3. ping -a 10.5.1.29 10.5.1.33 //AR29的loopback0接口地址应该能与AR33的loopback0接口地址互通，故障解决

3.3.2 如果以上处理方式不能解决AR29与AR33的loopback0互通的问题，则可能存在以下几种高可能性：

AR33没有将loopback0接口宣告进OSPF进程中，需要执行以下命令解决：

  1. system-view //进入系统视图
  2. ospf 1      //进入OSPF进程
  3. area 2      //进入区域2
  4. network 10.5.1.33 0.0.0.0 //将AR33的loopback0接口宣告进OSPF进程中

AR29与AR33的OSPF进程中做了路由过滤策略，需执行以下命令解决：

  1. dsiplay ospf brief  //检查是否做了区域策略
  2. system-view         //进入系统视图
  3. ospf 1              //进入OSPF进程1
  4. undo filter-policy xxx inport //删除OSPF进程下的路由过滤策略

AR33的接口做了过滤策略，需执行以下命令解决：

  1. display traffic-filter applied-record //检查是否有接口ACL策略
  2. display traffic-policy applied-record //检查是否有接口policy策略
  3. system-view           //进入系统视图
  4. interface {相关接口ID} //进入接口视图
  5. undo traffic-filter inbound/outbound //删除策略
  6. undo traffic-policy inbound/outbound //删除策略

执行完以上命令后在AR29上进行以下测试：

  1. display ospf peer brief  //检查AR29与AR33的OSPF邻居状态是否为full
  2. display ip routing-table | include 10.5.1.33 //AR29应该能正常学习到AR33的loopback0接口地址
  3. ping -a 10.5.1.29 10.5.1.33 //AR29的loopback0接口地址应该能与AR33的loopback0接口地址互通，故障解决

3.3.3 如果以上操作都未能解决故障，则需要用户提供完整的设备配置或前往用户现场进行现场排查，并拨打华为400服务热线请求华为TAC专家协助排除故障，谢谢！

3.1 故障根因判断

  1. AR29与AR33的Hello间隔不一致，AR29的Hello时间为10秒，AR33的Hello时间为15秒。

3.2 故障分析

3.2.1 故障现象重现——在AR29上使用源地址为自身loopback0接口ping AR33的loopback0接口地址，确定故障是否存在，测试及输出结果如下所示：
image.png
通过以上测试结果可知，故障确实存在，需要在AR29上检查路由表中是否存在AR33的loopback0接口地址的路由。

3.2.2 在AR29上使用命令display ip routing-table检查路由表中是否存在AR33的loopback0接口地址的路由，输出结果如下所示：
image.png
通过以上输出结果可知，AR29的路由表中不存在AR33的loopback0接口地址的路由，由于AR29与AR33之间运行OSPF路由协议，所以下一步检查AR29与AR33的OSPF邻居关系是否正常建立。

3.2.3 在AR29上使用命令display ospf peer brief查看与AR33的OSPF邻居状态是否为full，输出结果如下所示：
image.png
通过以上输出结果可知，AR29与AR33没有建立任何OSPF邻居关系，由于OSPF的建立依赖于底层的连通性，所以下一步检查AR29与AR33之间互联的接口的三层连通性。

3.2.4 在AR29上使用命令ping 10.5.40.34测试与AR33的直连接口三层连通性
image.png
通过以上输出结果可知，AR29与AR33之间互联的接口通信正常，排除连通性故障，所以下一步检查接口是否发布到OSPF进程中。

3.2.5 在AR29上使用命令display ospf interface all查看接口是否宣告进OSPF进程中和相关参数，输出结果如下所示：
image.png
通过以上输出结果可知，AR29的接口G0/0/1和loopback0都发布在了Area2中，并且得知接口G0/0/1的网络类型为广播，Hello间隔为10秒，Dead间隔为40秒，MTU为1500。由于OSPF邻居的建立依赖于底层连通性，所以下一步检查OSPF的错误报文来判断邻居协商的情况。

3.2.6 在AR29上使用命令display ospf error interface g0/0/1检查是否收到OSPF建立的错误报文，输出结果如下所示：
image.png
通过以上输出结果可知，AR29与AR33的Hello间隔不一致，而导致无法正常建立邻居关系，为了确定是否存在其它因素导致OSPF邻居无法正常建立，需要进一步测试。

3.2.7 在AR29上打开debug调试功能来确定AR29与AR33是否还存在其它因素影响邻居关系的建立，测试及输出结果如下所示：
image.png
image.png
image.png
通过以上输出结果可知，AR29与AR33的Hello间隔不一致确实存在（AR29：Hello Int：10；AR33：Hello Int：15）。
其它影响OSPF邻居建立的因素Router-id不冲突，Dead Time一致（默认为Hello时间的4倍），Area信息一致，区域类型一致，接口掩码一致，Hello报文的源地址在同一个网段，认证不存在错误。

综合分析：
通过以上测试可知，AR29的loopback0无法访问AR33的loopback0的根本原因在于AR29与AR33的Hello报文间隔不一致，从而无法建立OSPF邻居关系导致无法计算路由。
**

3.3 故障处理

3.3.1 通过debug信息得知，AR33上面的Hello时间是15秒，AR29的Hello时间为10秒，所以需要在AR33上执行以下命令解决此故障：

  1. system-view //进入系统视图
  2. interface g0/0/1 //进入接口视图
  3. ospf timer hello 10 //将接口的Hello周期配置为10秒，与AR29保持一致

执行完以上命令后在AR29上进行以下测试：

  1. display ospf peer brief //AR29与AR33之间应该正常建立full的邻接关系
  2. display ip routing-table | include 10.5.1.33 //AR29的路由表中应该存在AR33的loopback0接口地址路由
  3. ping -a 10.5.1.29 10.5.1.33 //AR29的loopback0应该能与AR33的loopback0正常通信，故障解决

3.3.2 如果以上操作不能解决此故障，则可能存在以下几种高可能性：

AR33的loopback0接口没有宣告进OSPF进程中，则需要进行以下操作解决：**

  1. system-view //进入系统视图
  2. ospf 1      //进入OSPF进程
  3. area 2      //进入Area 2
  4. network 10.5.1.33 0.0.0.0 //将AR33的loopback0接口宣告进OSPF进程中

AR29和AR33的OSPF进程中做了路由过滤策略，则需要进行以下操作解决：

  1. display ospf brief //检查OSPF进程下是否做了过滤策略
  2. system-view //进入系统视图
  3. ospf 1      //进入OSPF进程
  4. undo filter-policy xxx import //删除路由过滤策略

AR33的接口做了过滤策略，则需要执行以下命令解决：

  1. display traffic-filter applied-record //检查是否存在接口ACL策略
  2. display traffic-policy applied-record //检查是否存在接口policy策略
  3. system-view //进入系统视图
  4. interface {相关接口ID} //进入接口视图
  5. undo traffic-filter inbound/outbound //删除策略
  6. undo traffic-policy inbound/outbound //删除策略

执行完以上命令后在AR29上执行以下命令测试故障是否解决：

  1. display ospf peer brief //AR29与AR33之间应该正常建立full的邻接关系
  2. display ip routing-table | include 10.5.1.33 //AR29的路由表中应该存在AR33的loopback0接口地址路由
  3. ping -a 10.5.1.29 10.5.1.33 //AR29的loopback0应该能与AR33的loopback0正常通信，故障解决

3.3.3 如果执行完以上命令都未能解决故障，则需要用户提供完整的设备配置或前往用户现场进行现场排查，并拨打华为400服务热线请求华为TAC专家协助排除故障，谢谢！
**

三、AR32的loopback0无法访问AR28的loopback0

image.png

3.1 故障根因判断

  1. AR28在区域0下做了针对自身loopback0接口的路由汇总后面加关键字not-advertise
  2. AR28上做了针对自身loopback0接口的3类LSA的过滤行为（在Area0的export方向，或Area1的import方向）。
  3. AR28上使用filter-policy import命令对loopback0接口的路由做了过滤。
  4. AR28的G2/0/0接口上做了ospf filter-lsa-out summary acl命令做了3类LSA泛洪过滤。

3.2 故障分析

3.2.1 故障现象重现——在AR32上使用源地址为自身loopback0去ping AR28的loopback0地址，测试故障是否存在，测试及输出结果如下所示：
image.png
通过以上输出结果可知，故障确实存在，需要进一步检查AR32的路由表中是否存在AR28的loopback0接口地址路由。

3.2.2 在AR32上使用命令display ip routing-table查看路由表中是否存在AR28的loopback0接口地址路由，输出结果如下所示：
image.png
通过以上输出可知，AR32的路由表中不存在去往AR28的loopback0接口地址的路由，由于AR32与AR28之间运行OSPF路由协议，所以下一步检查AR32与AR28的邻居关系是否正常建立。

3.2.3 在AR32上使用命令display ospf peer brief查看与AR28的邻居关系是否为full，输出结果如下所示：
image.png
通过以上输出结果可知，AR32与AR28之间建立了full的邻接关系，由于OSPF计算出对方路由的前提是收到对方的LSA，所以在AR32上查看OSPF的LSDB。

3.2.4 在AR32上使用命令display ospf lsdb查看数据库中是否有关于AR28的loopback0口对应的LSA，输出结果如下所示：
image.png
通过以上输出可知，AR32的OSPF LSDB表中不存在AR28的loopback0所对应的3类LSA，但有AR28通告的1类LSA，需进一步查看该1类LSA中的详细信息。

3.2.5 在AR32上使用命令display ospf lsdb router 10.5.1.28查看AR28产生的1类LSA。
image.png
通过以上输出可知，AR28通告的1类LSA中只有描述G2/0/0对应的transnet类型的链路状态描述信息没有loopback0接口所对应的链路状态描述信息，所以可以判断AR28的loopback0没有发布在OSPF区域1中，由于不能判定AR28的loopback0是否发布在区域0中，所以要到AR27上查看OSPF的LSDB。

2.6 在AR27上通过命令：display ospf lsdb router 10.5.1.28查看AR28通告的1类LSA是否存在loopback0口所对应的链路状态信息。
image.png
通过以上输出可知AR27的OSPF区域0的LSDB中AR28通告的1类LSA中存在loopback0对应的stubnet类型的链路状态描述信息，可以判定AR28的loopback0已经发布在OSPF区域0中。

综合分析：
由于在AR27上的区域0的OSPF LSDB中能看到AR28的loopback0口是做为Type-1-LSA存在，但AR32的区域1的OSPF LSDB中无法看到AR28的loopback0的LSA，所以判定是在AR28上做了相应的3类LSA过滤行为，在当前环境中针对自身loopback0接口的3类LSA的过滤方式有以下4种：

  1. 在区域下使用filter命令调用ACL或者prefix-list，先deny AR28的loopback0接口路由，再permit any。
  2. 在AR28的区域0中使用汇总命令加上关键字not-advertise。
  3. AR28的G2/0/0接口上使用了ospf filter-lsa-out summary acl命令做了3类LSA泛洪过滤，先deny AR28的loopback0接口路由，再permit any。
  4. AR28上在OSPF进程中使用了filter-policy import命令对loopback0接口的路由做了过滤。

3.3 故障分析

3.3.1 AR28上做了路由过滤策略的故障处理需在AR28上执行以下命令：

  1. system-view //进入系统视图
  2. ospf 1      //进入OSPF进程1
  3. undo filter-policy import //删除路由过滤策略
  4. area 0 //进入区域0
  5. abr-summary 10.5.1.28 255.255.255.255 //如果有路由汇总命令并添加了not-advertise关键字请删除
  6. undo filter export //删除export策略
  7. area 1 //进入区域1
  8. undo filter import //删除import策略
  9. interface g2/0/0 //进入接口视图
  10. undo ospf filter-lsa-out //删除LSA泛洪策略

执行完以上命令后在AR32上进行以下测试：

  1. display ospf lsdb //检查OSPF数据库中是否存在AR28的类型3的LSA
  2. display ip routing-table //检查AR32的路由表中是否存在AR28的loopback0接口地址路由
  3. ping -a 10.5.1.32 10.5.1.28 //AR32的loopback0接口地址应该能与AR28的loopback0接口地址互通，故障解决

3.3.2 高可能性——能收到路由但是ping测不通则可能是AR28/AR32上做了流量过滤策略，需要在AR28/AR32上执行以下命令：

  1. system-view //进入系统视图
  2. interface g2/0/0{或者AR32的G0/0/0} //进入接口视图
  3. undo traffic-filter inbound/outbound //删除接口过滤策略
  4. undo traffic-policy inbound/outbound //删除接口过滤策略

3.3.3 如果以上操作都未能解决故障，则需要用户提供完整的设备配置或前往用户现场进行现场排查，并拨打华为服务热线请求华为TAC专家协助排除故障，谢谢！

四、AR32无法访问ISIS所有路由

image.png

4.1 故障根因判断

  1. AR28的接口G2/0/0上使用了ospf filter-lsa-out ase，做了5类LSA在出方向上的过滤。

4.2 故障分析

4.2.1 故障现象重现——在AR32上执行命令ping -a 10.5.1.32 10.1.5.30，测试与AR30的loopback0的连通性，测试及输出结果如下所示：
image.png
通过以上测试结果可知，AR32确实与ISIS区域的AR30互访存在故障，下一步检查AR32的路由表中是否存在访问ISIS区域的路由。

4.2.2 在AR32上使用命令display ip routing-table查看是否存在ISIS区域的路由，输出结果如下所示：
image.png
通过以上输出结果可知，AR32的路由表中不存在ISIS区域的路由条目，但是存在OSPF区域的内部路由，例如AR28的loopback0地址，说明AR32与AR28的邻居不存在问题，由于OSPF路由计算依赖LSDB中的LSA，所以需要进一步判断LSDB中是否存在ISIS网络中的5类LSA。

4.2.3 在AR32上使用命令display ospf lsdb检查OSPF LSDB表，输出结果如下所示：
image.png
通过以上输出可知，AR32的LSDB中不存在类型5的LSA，由于类型5的LSA整个AS内泛洪，且AR28没有权限登陆，所以下一步检查AR27的LSDB是否存在类型5的LSA。

4.2.4 在AR27上执行命令display ospf lsdb查看是否存在5类LSA，输出结果如下所示：
image.png
通过以上输出可知，AR27的LSDB中存在5类LSA。

4.2.5 在AR27上执行命令display ip routing-table protocol ospf | include ASE，输出结果如下所示：
image.png
通过以上输出可知，AR27的路由表中存在源自于ISIS区域内的OSPF外部路由。、

4.2.6 在AR31和AR34上查看路由表，确定OSPF引入ISIS是否正常，输出结果如下所示：
image.png
image.png
通过以上输出结果可知，AR34上 存在两条等价默认路由，AR31的路由表中存在源自于OSPF区域的全部路由条目，说明ASBR（AR28）的ISIS进程下成功引入了OSPF路由。由于AR30不能登陆，所以不能判断AR30上的路由表是否存在路由缺失。

综合分析：
由于OSPF外部路由是在整个OSPF网络内泛洪的，在AR27上存在源自于ISIS的5类LSA，而在AR32上不存在源自于ISIS路由的5类LSA，表明AR28上针对5类LSA做了发送的过滤动作，又因为AR32上只存在AR28这一个邻居，所以可以肯定的是在AR28的G2/0/0下执行了ospf filter-lsa-out ase，导致AR32不存在源自于ISIS区域路由的5类LSA。

4.3 故障处理

AR28在接口G2/0/0下做了5类LSA的过滤需执行以下命令解决：

  1. system-view //进入系统视图
  2. interface g2/0/0 //进入接口视图
  3. undo ospf filter-lsa-out //删除针对LSA5过滤的行为

修改完成后，逐一执行以下验证命令，排除后续可能存在的问题：

验证命令一：display ip routing-table protocol ospf
查看是否通过OSPF学习到去往ISIS区域的路由，如果存在该路由条目，则执行验证命令二，否则参见高可能1。

验证命令二：ping -a 10.5.1.32 10.1.5.30
如果能ping通，则表明故障排除，如果不通，则参见高可能2。

高可能1：在AR32上存在路由过滤需执行以下命令解决：

  1. ospf //进入OSPF进程视图
  2. display this //查看OSPF进程下配置是否存在路由过滤的行为
  3. undo filter-policy xxx import //删除路由过滤行为

高可能2：在AR32/AR28/AR30/AR31/AR34上存在流量过滤行为，在这下路由器上分别执行以下操作：

  1. interface GigabitEthernet x/x/x //进入相关接口配置视图
  2. display this //查看接口下的配置是否存在留恋过滤的行为
  3. undo traffic-filter inbound/outbound //删除流量过滤行为

最后在所有设备上保存配置：

  1. quit //执行两次，退至用户试图<>模式
  2. save //保存该配置，防止设备断电后，故障重现

五、AR32的loopback0不能访问AR31的路由器所有端口，不能访问AR34的G0/0/1口

  • AR32的loopback0不能访问ISIS区域里的部分设备，请诊断问题的原因。

image.png

5.1 故障根因判断

  1. AR28的接口G0/0/2口使用了基于源地址为AR32 loopback0口出方向的流量过滤策略。

5.2 故障分析

5.2.1 故障现象重现——在AR32上使用ping命令测试故障是否存在，测试及输出结果如下所示：
image.png
image.png
image.png
image.png
通过故障现象重现分析，怀疑是AR32路由表中不存在AR34的G0/0/1，AR31的loopback0，G0/0/1，G0/0/2接口的路由，导致AR32无法正常访问这四个接口的地址，其它接口地址均可以ping通，输出结果省略。

5.2.2 通过以上推断，在AR32上使用以下命令进行验证，输出结果如下所示：
image.png
通过AR32输出的路由表进行分析，发现AR32存在ISIS网络中的所有路由条目，因此可以排除AR32控制平面问题，怀疑是AR34与AR31不存在AR32的loopback0接口地址的路由条目，导致AR32无法访问这四个接口。

5.2.3 通过上述推断，在AR34与AR31上使用以下命令进行验证：
image.png
通过AR34输出的路由表进行分析，虽然不存在AR32的loopback0接口地址路由，但是存在两条缺省路由，因此可以排除AR34控制平面问题，继续测试AR31是否存在AR32的loopback0接口地址路由。
image.png
通过AR31输出的路由表进行分析，AR31路由表中存在AR32的loopback0接口地址路由，因此可以排除AR31路由器控制平面问题，同时表明AR28上单点双向引入正常并且路由信息也正常。
综上分析，AR28,AR32,AR30,AR31,AR34不存在控制平面问题。同时也可以排除物理层与数据链路层故障，因此故障定位在数据层面。
由于AR32是通过AR28进行访问AR31的三个直连接口与AR34的G0/0/1，因此怀疑某台路由器使用了基于目的地址为AR31的三个接口和AR34的G0/0/1的流量过滤策略。

5.2.4 通过上述推断，AR32不带源地址使用tracert命令验证到达AR31的三个接口与AR34 G0/0/1口的连通性，测试及输出结果如下所示：
image.png
image.png
image.png
image.png
通过验证结果进行分析，AR28,AR31,AR34没有使用基于目的地址为AR31的三个接口和AR34的G0/0/1接口地址的报文做过滤策略，怀疑是某台路由器使用了基于源地址为AR32的loopback0接口地址做了过滤策略，通过在AR32上使用tracert命令进行验证。

5.2.5 通过上述推断，在AR32上使用loopback0接口做为源地址进行tracert验证，测试及输出结果如下所示：
image.png
image.png
image.png
image.png
通过验证结果进行分析，AR32的tracert报文都是在第二跳出现无法正常回显的现象，初步判断在AR28和AR31之间存在丢包现象。

5.2.6 在AR32上以loopback0做为源地址，10.5.130.31做为目标地址做ping测试。同时在AR31上查看G0/0/2接口的相关信息做前后对比，测试及输出结果如下所示：
image.png
image.png
经过重复多次ping测试，并观察AR31的G0/0/2信息，发现接口是UP状态，并且接口上input方向收到的Unicast单播报文数量始终没有增加，由于AR31的接口没有收到ping测数据包，可以判断AR28没有将数据包发送出去。

5.2.7 在下游AR31和AR34上进一步排查流量过滤策略中需要调用的ACL，输出结果如下所示：
image.png
image.png
结果显示在AR31和AR34上无相关的ACL，所以可以排除后续在AR31和AR34上做流量过滤的可能。

5.2.8 测试针对反向访问数据包是否存在过滤行为。在AR31与AR34上针对AR32的loopback0做路由跟踪，观察数据包走向。
image.png
image.png
image.png
image.png
结果显示在AR34和AR31上针对AR32的loopback0地址做路由跟踪是成功的，所以可以排除AR34与AR31到AR32方向访问路径上针对AR32环回口地址的数据包过滤。

5.2.9 综上分析，通过2.1-2.3步骤判断各路由器不存在控制平面问题路由信息完整。通过2.4步骤可以判断不存在对报文目的地址存在过滤行为，通过2.5-2.8步骤可以判断AR28的G0/0/2接口outbound方向做了针对源地址为AR32的loopback0的报文过滤行为。
**

5.3 故障处理

5.3.1 登陆AR28路由器，删除流量过滤策略，需执行以下命令解决：

  1. system-view //进入系统视图
  2. interface g0/0/2 //进入接口G0/0/2接口的视图
  3. undo traffic-filter outbound //删除流量过滤策略
  4. undo traffic-policy outbound //删除流量过滤策略

执行完以上操作后，在AR32上执行以下命令验证：

  1. ping -a 10.5.1.32 10.5.1.34
  2. ping -a 10.5.1.32 10.5.1.31
  3. ping -a 10.5.1.32 10.5.130.31 
  4. ping -a 10.5.1.32 10.5.14.31  
  5. ping -a 10.5.1.32 10.5.14.34

如果全部ping通则表示故障已全部排除。

5.3.2 其它高可能性

高可能性一：如果在ping测试后，某些地址还是无法访问，则存在使用高级ACL过滤报文的可能，需要删除这些高级ACL。

5.3.3 如果执行完以上命令故障依然存在，则需要用户提供完整的设备配置或前往用户现场进行现场排查，并拨打华为400服务热线请求华为TAC专家协助排除故障，谢谢！
**

六、AR32的loopback0无法访问AR34的G0/0/0口和loopback0

image.png
**

6.1 故障根因判断

**

  • AR30的G0/0/0口出方向做了基于源地址为AR32 loopback0的流量过滤策略。

**

6.2 故障分析

6.2.1 故障现象重现，在AR32上使用ping命令测试故障是否存在，测试及输出结果如下所示：
image.png
image.png
通过故障现象进行分析，AR32的loopback0接口地址无法访问AR34的loopback0和G0/0/0接口的地址，怀疑是AR32路由表中不存在AR34的loopback0与G0/0/0接口的路由条目，导致AR32无法正常与AR34的两个接口地址通信。

6.2.2 通过上述分析，在AR32上使用以下命令进行验证，验证结果如下所示：
image.png
通过AR32输出的路由表进行分析，AR32路由表中存在AR34的loopback0与G0/0/0接口地址的路由条目，怀疑是AR34路由表中不存在AR32的loopback0接口地址的路由条目，导致AR32无法访问AR34的这两个接口地址。

6.2.3 通过上述分析，在AR34上执行以下命令进行验证路由表是否存在AR32的loopback0接口地址路由，输出结果如下所示：
image.png
通过AR34输出的路由表进行分析，虽然AR34路由表中不存在AR32的loopback0口路由条目，但是存在两条缺省的等价路由，进而可以排除AR34与AR32控制平面问题，怀疑是AR30或者AR31路由表中不存在AR32的loopback0和AR34的loopback0与G0/0/0接口地址的路由条目。

6.2.4 根据上述推断，在AR31路由器上使用以下命令进行验证，验证结果如下所示：
image.png
通过AR31输出的路由表信息进行分析，AR31的路由表中存在AR32的loopback0与AR34的loopback0与G0/0/0接口地址的路由条目，因此可以排除AR31控制平面问题。
由于AR32存在AR34的loopback0与G0/0/0接口地址路由条目，因此可以判断AR28上单点双向引入正常且路由表项也正常。
继续测试AR30是否存在AR32的loopback0与AR34的loopback0和G0/0/0接口地址的路由条目。

6.2.5 由于AR30路由器无法登陆，通过在AR32上带源测试AR30上是否存在AR32的loopback0的路由，测试及输出结果如下所示：
image.png
通过AR32的tracert的结果分析，AR32的loopback0能tracert通AR30的接口，说明AR30的接口存在去往AR32的路由，AR30的控制层面的问题排除，需要进一步定位数据层面的丢包点。

6.2.6 在AR32上分别不带源和带源地址（10.5.1.32），以10.5.1.34做为目标地址做路由跟踪来判断数据的丢包点：
image.png
image.png
根据上图显示结果对比发现，在AR32上带loopback0做为源地址，在第三跳中显示为的地址为10.5.34.34（AR34的G0/0/0口），数据包在AR30和AR34之间发生了丢包，不带源地址测试正常。怀疑是在AR30和AR34上存在针对AR32的loopback0的源地址过滤。

6.2.7 在AR32上以loopback0做为源地址，10.5.34.34做为目标地址做ping测试，同时在AR34上查看G0/0/0接口的信息做前后对比，测试及输出结果如下所示：
image.png
image.png
路由跟踪到达AR30后就无法回显了，经过多此观察AR34的G0/0/0口信息，发现接口上input方向收到的Unicast单播报文数量始终没有增加，可以判断AR30的G0/0/0接口发送报文能力存在问题。

2.8 在下游AR34上进一步排查流量过滤策略中需要调用的ACL。
image.png
image.png
结果显示在AR34上无相关的ACL，所以可以排除后续在AR34上做流量过滤的可能。

2.9 测试针对反向访问数据包是否有过滤行为。在AR34上针对AR32的loopback0做路由跟踪，观察数据包走向。
image.png
结果显示在AR34上针对AR32的loopback0地址做路由跟踪是成功的，所以可以排除AR34-AR32的反方向的数据包过滤。

综合分析：
首先通过2.1-2.5步骤排除相关路由器上路由控制层面上的故障，通过2.6步骤初步判断AR30和AR34之间存在报文过滤的行为。
通过2.8步骤可以得出AR34上不存在报文过滤行为，通过2.9步骤也排除了反方向数据包过滤行为，最终得出故障根因为AR30的G0/0/0口上的outbound方向做了针对AR32的loopback0地址的流量过滤。*

6.3 故障处理


6.3.1 登陆AR30路由器，删除流量过滤行为，需执行以下命令解决：**

  1. system-view //进入系统视图
  2. interface g0/0/0 //进入G0/0/0接口视图
  3. undo traffic-filter outbound //删除流量过滤策略
  4. undo traffic-policy outbound //删除流量过滤策略

经过以上操作后，若AR32可以正常访问AR34的G0/0/0和loopback0接口，说明故障排除。

6.3.2 其它高可能性
**
高可能性一：如果在ping测试后，某些地址还是无法访问，则存在使用高级ACL过滤报文的可能，需要删除这些高级ACL。

6.3.3 如果以上操作都未能解决故障，则需要用户提供完整的设备配置或前往用户现场进行现场排查，并拨打华为400服务热线请求华为TAC专家协助排除故障，谢谢！

七、AR34没有学习到两条等价默认路由

image.png

7.1 故障根因判断

  1. AR31配置了错误的区域ID，导致AR31与AR34无法建立ISIS邻居关系。
  2. AR31配置了错误的ISIS类型（类型1），正确配置应该为类型1/2。

7.2 故障分析

7.2.1 故障现象重现，在AR34上查看路由表，确定路由表是否不存在两条缺省路由，测试及输出结果如下所示：
image.png
如上输出结果所示，AR34确实只存在一条缺省路由，并且没有任何ISIS路由通过AR31，由拓扑可知AR34需要与AR30与AR31建立ISIS邻居关系，所以需要进一步检查ISIS邻居关系是否正常。

7.2.2 在AR34上使用命令display isis peer命令检查ISIS邻居关系是否正常，输出结果如下所示：
image.png
如上输出结果所示，AR34只与AR30建立了ISIS邻居关系，与AR31没有建立ISIS邻居关系，ISIS邻居关系建立依赖于底层的连通性。接下来检查AR34和AR31之间连通性是否正常。

7.2.3 在AR34上ping AR31的G0/0/1接口IP地址，测试直连接口三层连通性是否正常，测试及输出结果如下所示：
image.png
通过以上测试结果可知，直连链路连通性正常。接下来确定AR34接口是否正常发布进ISIS进程中。

7.2.4 在AR34上使用命令display isis brief查看AR34协议的相关配置，输出结果如下所示：
image.png
通过以上输出结果可知，AR34是level-1路由器，接口都已经加入到ISIS进程中，如果要和AR31形成邻接关系要求AR34和AR31在同一个区域中，并且AR31的路由器类型为level-1-2同时要能和AR28建立起level-2的邻接关系。

7.2.5 在AR34上采用display isis error interface g0/0/1命令查看AR34连接AR31接口的ISIS错误报文情况，输出结果如下所示：
image.png
如上输出中存在“Mismatched Area Addr（L1）：107”错误计数，而且计数在增长，所以可以初步判断AR31与AR34直连链路正常，但区域配置不匹配。需要进一步确定AR34的区域配置是否正确。

7.2.6 在AR34和AR31上分别使用命令display isis lsdb local查看自身产生的LSP，测试及结果如下所示：
image.png
image.png
通过以上输出得出结论AR34与AR31 ISIS的区域ID配置不匹配，且AR31的区域ID配置成了错误的49.0006。通过此输出还可以发现AR31可能配置了错误的ISIS类型为Level-1，因为ATT位没有置1，并且AR31的LSDB中自身并没有产生Level-2的LSP，需进一步确认。

7.2.7 在AR31上使用display isis brief命令检查AR31的ISIS类型，输出结果如下所示：
image.png
如上输出结果所示，AR31配置成了错误的ISIS类型（Level-1），导致只发送level-1的Hello报文，无法与AR28建立Level-2的邻接关系，也不会产生ATT位置位1的 level-1的LSP，导致AR34无法计算出等价的路由。

综合分析：
问题的根本原因在于AR31的ISIS区域ID配置错误（配置成了49.0006，正确配置为49.0005），并且AR31配置了错误的ISIS类型（Level-1）。

7.3 故障处理

7.3.1 AR31区域ID配置错误的故障解决需要在AR31上执行以下命令：

  1. system-view //进入系统视图
  2. isis {进程ID} //进入ISIS进程
  3. undo network-entity 49.0006.0000.0000.0031.00 //删除错误的区域ID
  4. network-entity 49.0005.0000.0000.0031.00 //修改为正确的区域ID

7.3.2 AR31的ISIS类型配置错误的故障解决需要在AR31上执行以下命令：

  1. system-view //进入系统视图
  2. isis {进程ID} //进入ISIS进程
  3. is-level level-1-2 //修改ISIS类型为level-1-2

执行完以上命令后，如果在AR34上通过display ip routing-table命令查看路由表任然没有存在两条默认路由，可能存在以下高可能性，请逐一排查。

7.3.3 高可能性1——AR28连接AR31的接口没有使能ISIS，在AR28上执行以下命令：

  1. system-view //进入系统视图
  2. interface {连接AR31的接口ID} //进入接口视图
  3. isis enable {ISIS进程ID} //接口使能ISIS

7.3.4 高可能性2——AR28的G0/0/2接口配置了ISIS的验证，在AR28上执行以下命令：

  1. system-view //进入系统视图
  2. interface g0/0/2 //进入接口视图
  3. display this //查看接口相关配置
  4. undo isis authentication //删除认证配置

7.3.5 高可能性3——AR31上使用attached-bit advertise never，让AR31不产生ATT置位1的LSP，在AR31上执行以下命令：

  1. system-view //进入系统视图
  2. isis {ISIS进程ID} //进入ISIS进程
  3. undo attached-bit advertise //删除ATT位不置1的命令

7.3.6 高可能性4——AR34在ISIS进程下，针对下一跳设置了不同的weight值，在AR34上执行以下命令：

  1. system-view //进入系统视图
  2. isis {ISIS进程ID} //进入ISIS进程
  3. display this //查看接口相关配置
  4. undo nexthop 10.5.x.x //如针对不同的下一跳配置了不同的weight值请删除

7.3.7 如果执行完以上操作均未能解决故障，则需要用户提供完整的设备配置或前往用户现场进行排查，并拨打华为400服务热线请华为TAC专家协助排除故障，谢谢！

7.4 故障根因判断

  • AR31配置了错误的ISIS路由器级别（level-1），应该配置为level-1-2。

7.5 故障分析

7.5.1 故障现象重现——在AR34上查看路由表，确定路由表中是否存在两条默认路由，输出结果如下所示：
image.png
通过以上输出结果可知，故障确实存在，AR34只有一条缺省路由，下一跳指向AR30，缺少一条指向AR31的缺省路由，并且可以得知接口G0/0/0和G0/0/1开销都为10，由拓扑可知AR34需要与AR30与AR31建立ISIS邻居关系，所以需要进一步检查ISIS邻居关系是否正常。

7.5.2 在AR34上使用命令display isis peer命令检查ISIS邻居关系是否正常，输出结果如下所示：
image.png
通过以上输出结果可知，AR34与AR30和AR31建立了正常的ISIS邻居关系，因为产生默认路由需要level-1-2路由器产生的level-1的LSP中ATT位置1，所以需要查看ISIS的LSDB。

7.5.3 在AR34上使用命令display isis lsdb 查看ISIS数据库，输出结果如下所示：
image.png
如上输出结果可知，AR31中ATT位没有置1，所以AR34不会产生指向AR31的默认路由。由于要产生ATT置1的LSP，需要满足前提条件为此路由器为level-1-2路由器，并且要存在不在同区域的level-2的邻居路由器。

7.5.4 在AR31上通过命令display isis peer查看ISIS邻居，输出结果如下所示：
image.png
通过以上输出结果可知，AR31只与AR34形成level-1的邻居关系，没有和AR28形成level-2的邻居关系。由于邻居关系的建立依赖于底层的连通性，所以下一步检查AR31与AR28直连的接口三层是否能互通。

7.5.5 在AR31上ping测试与AR28直连链路的连通性，测试及输出结果如下所示：
image.png
通过以上输出结果可以排除AR31与AR28之间物理链路故障的可能。需要进一步检查AR31的ISIS进程信息是否有误。

7.5.6 在AR31上使用命令display isis brief查看ISIS进程相关信息，输出结果如下所示：
image.png
如上输出结果可知，AR31被配置为路由器级别为level-1的路由器。

综合分析：
由于AR31没有和AR28形成level-2的邻居关系，所以自身产生的level-1的LSP不会ATT位置1，并且自身路由器级别位level-1，只能发送level-1的Hello报文，导致无法与AR28建立邻居关系，所以需要把AR31改为level-1-2路由器。

7.6 故障处理


7.6.1 AR31区域ID配置错误的故障需要在AR31上执行以下命令：**

  1. system-view //进入系统视图
  2. isis {isis进程ID} //进入ISIS进程
  3. is-level level-1-2 //将路由器级别修改为level-1-2

执行完以上命令后在AR34上进行以下测试：

  1. display isis peer //检查AR34与AR31是否正常建立ISIS邻居关系
  2. display isis lsdb //检查AR31发来的LSP中ATT位是否置1
  3. display ip routing-table //检查路由表中是否存在两条缺省路由，故障解决

完成上述排除后，如果AR34上再次通过display ip routing-table查看路由表仍然没有2条默认路由，并且AR31仍然无法与AR28形成邻居关系时，可能存在以下几种高可能性，请逐一排查。

7.6.2 高可能性1：AR28连接AR31的接口没有使能ISIS，在AR28上执行以下命令：

  1. system-view //进入系统视图
  2. interface {连接AR31的接口ID} //进入接口视图
  3. isis enable {isis进程ID} //接口使能ISIS

7.6.3 高可能性2：AR28的接口G0/0/2配置了ISIS认证，在AR28上执行以下命令：

  1. system-view //进入系统视图
  2. interface {连接AR31的接口ID} //进入接口视图
  3. undo isis authentication-mode //关闭ISIS认证

7.6.4 高可能性3：AR31上使用了attached-bit advertise never，让AR31不会产生ATT位置1的LSP，需要在AR31上执行以下命令：

  1. system-view //进入系统视图
  2. isis {ISIS进程ID} //进入ISIS进程
  3. undo attached-bit advertise //删除ATT位不置1的命令

7.6.5 高可能性4：AR34在ISIS进程下，针对下一跳设置了不同的weight值，在AR34上执行以下命令：

  1. system-view //进入系统视图
  2. isis {ISIS进程ID} //进入ISIS进程
  3. dis this //查看进行下相关配置
  4. undo nexthop 10.5.x.x //如针对不同的下一跳配置了不同的weight值请删除

7.6.6 如果以上操作都未能解决故障，则需要用户提供完整的设备配置或者前往用户现场进行现场排查，并拨打华为400服务热线请华为TAC专家协助排除故障，谢谢！
**

7.7 故障根因判断

**

  • AR31配置了错误的区域ID，导致AR31与AR34无法建立ISIS邻居关系

**

7.8 故障分析

7.8.1 故障现象重现——在AR34上查看路由表中两条缺省路由是否存在，输出结果如下所示：
image.png
通过以上输出结果可知故障确实存在，AR34只存在一条下一跳指向AR30的缺省路由，缺少一条指向AR31的缺省路由，由拓扑可知AR34需要与AR30和AR31建立ISIS邻居关系，所以需要进一步检查ISIS邻居关系是否正常。

7.8.2 在AR31/AR34上采用display isis peer命令检查ISIS邻居关系是否正常， 输出结果如下所示：
image.png
image.png
通过以上输出结果可知，AR34只与AR30建立了level-1的ISIS邻居关系，与AR31没有建立ISIS邻居关系，AR31与AR28建立了Level-2的邻居关系，ISIS邻居关系建立依赖于底层的连通性。接下来检查AR34和AR31之间连通性是否正常。

7.8.3 在AR34上ping AR31的G0/0/1接口IP，测试及输出结果如下所示：
image.png
通过以上测试结果可知，直连链路连通性正常。接下来确定AR31接口是否正常发布进ISIS进程中。

7.8.4 查看AR31与AR34的ISIS相关参数，输出结果如下所示：
image.png**
image.png
通过以上输出结果可知，AR31/AR34的各相关接口都以加入ISIS进程中，并且AR31为level-1-2路由器。

7.8.5 在AR34上使用命令display isis error interface g0/0/1查看是否存在错误计数，输出结果如下所示：
image.png
根据以上输出结果可知，存在“Mismatched Area Addr（L1）：66”的报错提示，表示AR34和AR31有交互level-1的Hello报文的能力，但无法建立ISIS邻居的故障原因是Hello报文中区域ID不一致所导致，level-1邻居建立要求区域ID一致。因为双方已经检测到Hello报文参数不一致，说明无ISIS认证错误的可能。

7.8.6 在AR34上使用命令display isis lsdb local verbose，查看当前AR34的区域信息，输出结果如下所示：
image.png
根据以上输出结果可知，AR34的区域ID为49.0005，system ID为0000.0000.0034。

7.8.7 在AR31上使用命令display isis lsdb local verbose level-1，查看AR34区域ID，输出结果如下所示：
image.png
根据以上输出结果可知，AR31的区域ID为49.0006，system ID为0000.0000.0031，AR31与AR34之间的system id不冲突。

综合分析：
发现AR34和AR31无法建立邻居关系的原因是双方的区域ID不一致，如改变AR34的区域ID会影响AR34和AR30的邻居关系，所以需要改变AR31上的ISIS区域ID，与AR34保持一致。并且不会对AR31和AR28的level-2的邻居关系产生影响（level-2建立邻居关系无需区域ID一致）。而根据AR31上的其它输出信息显示，双方的system id不冲突，并无其它故障点存在，并且双方已经检测到Hello中的参数不匹配，所以也可以排除ISIS认证失败的可能性。

7.9 故障处理

7.9.1 AR31区域ID配置错误的故障需要在AR31上执行以下命令：

  1. system-view //进入系统视图
  2. isis {ISIS进程ID} //进入ISIS进程视图
  3. undo network-entity 49.0006.0000.0000.0031.00 //删除错误的区域ID
  4. network-entity 49.0005.0000.0000.0031.00 //修改为正确的区域ID

执行完以上命令后在AR34上用以下命令进行测试：

  1. display isis peer //检查AR34与AR31是否正常建立ISIS邻居关系
  2. display isis lsdb //检查AR31发来的LSP的ATT位是否置1
  3. display ip routing-table //检查路由表中是否存在两条缺省路由，故障解决

如果执行完以上排除后，在AR34上再次通过display ip routing-table查看路由表仍然没有两条默认路由，可能存在以下几种高可能性，请逐一排查。

7.9.2 高可能性1：AR31上使用attached-bit advertise never，让AR31不产生ATT置1的LSP，需在AR31执行以下命令：

  1. system-view //进入系统视图
  2. isis {ISIS进程ID} //进入ISIS进程视图
  3. undo attached-bit advertise //删除ATT位不置1的命令

7.9.3 高可能性2：AR34在ISIS进程下，针对下一跳设置了不同的weight值，在AR34上执行以下命令：

  1. system-view //进入系统视图
  2. isis {isis进程ID} //进入ISIS进程视图
  3. undo nexthop 10.5.x.x //如针对不同的下一跳配置了不同的weight值请删除

7.9.4 如果执行完以上操作均未能排除故障，则需要用户提供完整的设备配置或者前往用户现场进行现场排查，并拨打华为400服务热线请华为TAC专家协助排除故障，谢谢！