H3C TE BGP拓扑排错报告

farmer111

　　                                                                                   BGP排错报告
　　
　　故障一：PPP链路故障
　　故障现象：
　　RT4和RT5间的PPP链路一会up 一会down
　　故障分析：
　　1)       chap认证的类型是否一致
　　2)       接口下配置的认证用户是否包含PPP服务类型
　　3)       接口下是否配置了chap认证密码
　　4)       接口下配置的chap认证密码是否正确
　　故障解决：
　　1)       在RT4上使用“display current-configuration int s0/1/0”和“display current-configuration int s0/1/1”查看本地的接口下的chap验证类型为chap,在RT5上使用“display current-configuration int s0/1/0”和“display current-configuration int s0/1/1”命令查看本地接口下的chap认证类型，发现两端的认证类型均为chap。
　　2)       在RT4上使用“display current-configuration conf luser”查看本地用户信息，发现本地的chap认证用户rt4没有配置服务类型ppp，在系统视图下输入“local-user rt4”，进入本地用户视图，使用“service-type ppp”为chap认证用户rt4添加ppp服务类型。
　　在RT5上使用“display current-configuration conf luser”查看chap认证用户是否包含服务类型ppp，发现本端设备包含服务类型PPP。
　　3)       在RT4上进入s0/1/0和s0/1/1接口，查看配置的chap认证用户名和认证密码信息，发现只存在用户名，同样进入RT5的s0/1/0和s0/1/1接口，查看配置的chap认证用户名和密码信息，发现只存在用户名，无认证密码信息。
　　由此得出RT4和RT5的chap认证使用的是不配置认证密码的方式，在该方式的chap双向认证中，只有接口下配置的认证用户密码一致时才可以通过认证。
　　4)       在RT4上使用“display current-configuration conf luser”查看本地的chap认证用户的密码，发现密码为h3c，同理在RT5上使用“display current-configuration conf luser”查看本地的chap认证用户rt5的密码，发现密码为rt5，密码不一致，导致chap双向认证一致无法验证成功，一直重复up和down的状态。
　　在RT5上输入“local-user rt5”，进入本地用户视图，使用“password simple h3c”命令修改chap用户rt5的密码为h3c。
　　5)       在RT5上使用“display ppp mp”查看mp-group 捆绑组是否包含题目要求的成员接口，发现题目要求的s0/1/0和s0/1/1都是捆绑组成员。
　　在RT4上使用“display ppp mp”查看mp-group捆绑组是否包含题目要求的成员接口，发现题目要求的成员接口s0/1/0和s0/1/1均在捆绑组中。
　　6)       在RT4上进入输入命令“int Mp-group 1”进入mp-group捆绑组接口，使用shutdown关闭接口，执行undo shutdown 重新激活mp-group 接口，使之重新进行chap认证。
　　在RT5上执行操作和RT4一样，使接口重新进行chap认证。
　　7)       在RT4上使用“display ip interface brief”发现聚合组接口和成员接口的物理和协议均处于UP状态，在RT5上同样使用“display ip interface brief”发现聚合组接口和成员接口的物理和协议状态亦为up状态，此故障排除。
　　故障点二：链路聚合故障
　　故障现象：
　　在SW1和SW2上使用“display link-aggregation verbose”命令查看聚合组接口信息时，提示“Info: No link aggregation group defined at present”（聚合组不存在）
　　故障分析：
　　1)没有创建聚合组
　　故障解决：
　　1)       在SW1上使用“int Bridge-Aggregation 1”创建聚合组。
　　2)       在SW1上进入e0/4/2和e0/4/3接口，将题目要求的接口加入聚合组。
　　3)       在SW2上使用“int Bridge-Aggregation 1”创建聚合组。
　　4)       在SW2上进入e0/4/2和e0/4/3接口，将题目要求的接口加入聚合组。
　　5)       在SW1上使用“int Bridge-Aggregation 1”进入聚合组视图，将聚合组接口封装为题目要求的trunk类型，方向VLAN 10和VLAN 20。
　　SW2上执行SW1同样的操作即可。
　　6)       在SW1上使用“display link-aggregation v”查看聚合组的详细信息，发现接口e0/4/3和e0/4/2都处于S状态，说明题目要求的接口已经加入到聚合组且当前状态为活跃状态。
　　在SW2上同样执行“display link-aggregation v”发现接口已经加入聚合组且当前状态活跃。
　　此故障排除。
　　故障点三：MST故障
　　故障现象：
　　SW1和SW2以及SW3的阻塞端口不符合题目要求，且SW3出现master角色的接口
　　故障分析：
　　1)       是否创建了业务VLAN
　　2)       设备互联接口是否封装为trunk
　　3)       设备互联接口是否放行业务VLAN
　　4)       设备的域配信息的实例和VLAN的对应关系是否一致
　　5)       设备的域配信息的域名是否一致
　　6)       是否指定实例的主备根
　　故障解决：
　　1)       在SW1、SW2、SW3上使用“display vlan”查看三台设备的vlan信息，发现三台设备均存在题目要求的业务VLAN10 和业务VLAN20
　　2)       在SW1、SW2、SW3上使用“display por t”查看三台设备互联的接口是否封装了trunk，发现互联接口封装都为trunk
　　3)       在SW1、SW2、SW3上使用“display por t”查看三台设备的互联接口是放行了业务VLAN10和VLAN100发现三台设备的trunk口都放行VLAN10和VLAN100
　　4)       在SW1、SW2、SW3上使用“display current-configuration conf mst-region”查看三台设备的MST域配信息，发现SW3没有配置mst域的域名，由于在MSTP中，识别同一个域使用的是mst的域配信息的md5校验值，没有配置mst域的域名时，默认会以本台设备的管理mac地址作为域名，因此出现了多mst域。
　　在SW3上输入“stp region-configuration”命令进入 mst域配视图，使用“region-name h3c”命令修改sw3的mst域名，且在该视图下使用“active  region-configuration”重新激活mst域配信息，使mst重新计算生成树。
　　5)       在SW1上使用“display stp instance 2 brief”查看实例2 的接口角色信息，发现实例2 没有阻塞SW1的聚合组接口。
　　在SW2上使用“display stp instance 1 brief”查看实例1的接口角色信息，发现实例1没有阻塞SW2的聚合组接口。
　　在SW3上使用“display stp brief”接口角色信息，发现实例1阻塞SW3的e0/4/1接口，实例2阻塞SW3的e0/4/0接口，不符合题目要求。
　　6)       在SW1上使用“display current-configuration conf | include root”查看是手工指定实例的主备根，发现没有指定。
　　在SW2上使用“display current-configuration conf | include root”查看是否手工指定实例的主备根，发现没有指定。
　　在SW1的系统视图下使用“stp instance 1 root primary”和“stp instance 2 root secondary”手工指定SW1为实例1的主根，实例2的备根。
　　在SW2的系统视图下使用“stp instance  2 root primary”和“stp instance  1 root secondary”手工指定SW2为实例2的主根，为实例1 的备根。
　　7)       在SW1上执行“display stp brief”发现实例2没有阻塞聚合组接口，在SW2上使用“display stp brief”发现实例一没有阻塞聚合组接口，不符合题目要求。
　　由于聚合组接口是stp 开销值为180，而其他接口的开销值为200，此时SW3上的实例1和实例2通过比较RPC，阻塞了SW3上的接口。
　　在SW1上使用命令“display stp brief”查看接口角色，发现实例2阻塞SW1的聚合组接口，在SW2上使用命令“display stp brief”查看接口角色，发现实例1 阻塞SW2的聚合组接口，符合题目要求，此故障排除。
　　故障点四：VRRP故障
　　故障现象：
　　手动shudown　SW1和SW2的上行链路接口RT1的g0/0/0和RT2的g0/0/0口后，VRRP的主备无法进行角色切换
　　故障分析：
　　1)       VRRP的虚拟地址是否配置正确
　　2)       VRRP的虚拟地址和接口所在地址是否处于同一网段
　　3)       VRRP的验证类型是否一致
　　4)       VRRP的验证密钥是否一致
　　5)       侦测上行链路故障时，递减的优先级设置是否得当
　　故障解决：
　　1)       在SW1上使用命令“display current-configuration int Vlan-interface 10”查看vlan 10的虚拟IP 为192.168.10.254 ，在SW2上使用“display current-configuration int Vlan-interface 10”查看vlan 10的虚拟IP为192.168.10.254 ,VLAN 10的虚拟IP一致，无错误。
　　使用和上述一样的操作查看vlan 20的虚拟IP地址，发现VLAN20的虚拟IP地址为192.168.20.254 ，符合题目要求，无错误。
　　2)       VLAN10的虚拟IP192.168.10.254和接口所在地址处于同一网段，无错误，VLAN 20的虚拟地址192.168.20.254也和接口所在的地址处于同一网段，无错误。
　　3)       在SW1和SW2上使用“display current-configuration int Vlan-interface 10”查看vlan 10的vrrp的验证类型是否一致，发现验证类型都为simple且密钥均为h3c。
　　在SW1和SW2上使用“display current-configuration int Vlan-interface 20”查看VLAN20的VRRP验证类型是否一致，发现验证类型都为simple且密钥均为h3c。
　　Vrrp的验证类型和密钥都没有配置错误。
　　4)       在SW1和SW2上使用“display current-configuration int Vlan-interface 10 | include track”查看vlan 10的vrrp上行链路侦测配置，发现没有配置上行链路故障时的递减值，在SW1使用“display current-configuration int Vlan-interface 10 | include priority”发现vlan 10的master的优先级为120。由于没有配置递减值，当上行链路故障时，master设备将自身的优先级递减10，递减后的值为110，而在SW2上使用“display current-configuration int Vlan-interface 10”查看backup设备的优先级，发现为空，默认的优先级为100，这样即使当上行链路出现故障master设备将自身的优先级递减10变为110，此时master设备的优先级仍然大于backup设备的优先级，因此即使上行链路故障，backup设备依旧不可能切换为master角色承担VLAN数据转发。
　　5)         在SW1上使用“int Vlan-interface 10”进入vlan 10的接口视图，修改命令“vrrp vrid 1 track interface Vlan-interface 30 reduced 30”修改上行链路侦测故障时的递减值为30，上行链路故障时，master设备优先级将为90。
　　同理在SW2上修改VLAN 20的侦测上行链路故障时的递减值为30。
　　在SW1上使用“display vrrp”查看vrrp的状态，SW1上VLAN 10的优先级为90，当前角色为backup。
　　在RT1上进入g0/0/0接口视图，使用undo shut命令激活该接口，在SW1上重复执行命令“display vrrp”发现SW1上的vlan 10 接口的优先级为120，当前状态为master，当上行链路激活时，master设备抢占master角色。
　　在SW2上执行和SW1上同样的操作即可，此故障排除。
　　故障点五：OSPF故障
　　故障现象：
　　在RT1上使用“display ospf peer”查看OSPF的邻居，发现存在AS65001中的RT3，在RT2上使用“display ospf peer”发现存在AS65001中的RT4，在RT3上使用“display ospf peer”发现存在AS65000中的RT1，在RT4上使用“display ospf peer”发现存在AS65000
　　中的RT2 。这与题目要求不符。
　　故障分析：
　　连接自治系统间的直连网段被宣告进了OSPF中
　　故障解决：
　　1)在RT1、RT2、RT3上使用“display current-configuration conf ospf”查看OSPF网段宣告信息，发现RT1和RT3自治系统之间的直连网段错误的宣告进OSPF进程中，在RT2和RT4中隧道接口的地址被错误的宣告进了OSPF区域。
　　2)使用命令“ospf 1 ”进入OSPF协议视图下，输入“area 0”进入区域0后，依次在设备上删除下列通告网段：
　　undo network 172.16.1.1 0.0.0.0
　　undo network 172.16.1.5 0.0.0.0
　　undo network 172.16.1.2 0.0.0.0
　　undo network 172.16.1.6 0.0.0.0
　　2)在RT1、RT2、RT3、RT4上依次使用“display  ospf peer”查看OSPF邻居，不同AS间通过OSPF建立起来的邻居关系消失。
　　此故障排除。
　　故障点六：BGP故障
　　故障现象：
　　在SW1、W2、RT5上使用“display  ip routing-table “查看路由表，没有发现BGP路由条目。
　　故障分析：
　　1)       BGP对等体关系是否建立
　　2)       是否发布了BGP路由
　　3)       BGP路由的下一跳是否可达
　　4)       是否使用了路由过滤策略
　　故障解决：
　　1)       在SW1上使用“display  bgp peer”查看BGP对等体关系是否正确建立，发现SW1和RT1以及RT2建立了正确的BGP对等体关系，其状态均为“Established”。
　　2)       在RT5上使用“display current-configuration conf bgp | include network”查看是否发布了BGP路由，发现RT5正确发布了BGP路由。
　　3)       在SW1上使用“display bgp routing-table”查看SW1的BGP路由表，发现BGP路由表中存在RT5上的BGP路由条目，但是下一跳本地不可达。
　　4)       在RT1、使用“display current-configuration conf bgp”查看RT1是否对SW1指定下一跳为本地，发现没有。
　　5)       在RT1和RT2上进入BGP协议视图，对IBGP对等体指定下一跳为本地。
　　RT1 上指定：
　　peer 6.6.6.6 next-hop-local
　　peer 7.7.7.7 next-hop-local
　　peer 6.6.6.6 next-hop-local
　　在RT2上指定
　　peer 1.1.1.1 next-hop-local
　　peer 6.6.6.6 next-hop-local
　　peer 7.7.7.7 next-hop-local
　　在RT3上指定
　　peer 4.4.4.4 next-hop-local
　　peer 5.5.5.5 next-hop-local
　　在RT4上指定
　　peer 3.3.3.3 next-hop-local
　　peer 5.5.5.5 next-hop-local
　　6)       在SW1、SW2、RT5上依次使用“display ip routing-table”命令查看IP路由表中的BGP路由条目发现已经存在，此故障排除。
　　故障点七：BGP选路错误
　　错误点1：
　　故障现象：
　　在RT5上使用“display ip routing-table”查看路由表，发现192.168.10.0 24 192.168.20.0 24的下一跳均为172.16.2.5。
　　故障分析：
　　IGP路由开销导致了两条BGP的路由的下一跳均为172.16.2.5，由于在OSPF中，G口的开销值为1，而两条串行链路的OSPF开销为781，因此IGP路由选路中选择了开销较小的G口。
　　故障解决：
　　1)       在RT5上进入mp-group接口，使用“ospf cost 1”修改开销值为1，使IGP路由负载。
　　2)       在RT5上进入mp-group接口，使用“ospf cost 1”修改其开销值为1，使IGP路由负载。
　　3)       在RT5上使用“display ip routing-table”查看路由表，发现192.168.10.0 24 下一跳为172.16.2.5 ，192.168.20.0 24 下一跳为172.16.2.9。符合题目要求，此故障排除。
　　错误点2：
　　故障现象：
　　在RT3上使用“display  bgp routing-table”查看RT3上的BGP路由表，发现192.168.10.0 24 路由是从RT4学习来的，在RT4上使用该命令查看BGP路由表，发现192.168.20.0 24 是从RT3学习来的，与题目要求相反。
　　故障分析：
　　1)       本地接收时是否进行了过滤
　　2)       对端发送时是否进行了过滤
　　故障解决：
　　1)       在RT3上使用“display current-configuration conf bgp”查看BGP的配置信息，发现从对等体172.16.1.1 接收路由时调用了route-policy fa。
　　2)       使用“display route-policy fa”查看route-policy的节点信息，发现仅存在一个节点规则，由于route-policy有一个隐含的deny节点，因此在使用route-policy修改路由属性时应写一条空策略放行其他路由，否则不匹配节点一的路由都将过滤。
　　3)       在RT3的系统视图下使用“route-policy fa permit node 20”创建一条默认放行的空节点。
　　在RT1、RT2、RT4上修改as-path属性的route-policy中创建一条默认的空节点用来放行其他的路由。
　　RT4
　　route-policy fa permit node 20
　　RT1
　　route-policy fa permit node 20
　　RT2
　　route-policy fa permit node 20
　　4)       依次使用“display bgp routing-table”查看RT3、RT4、RT1和RT2的BGP路由条目，发现均满足题目要求，此故障排除。
　　故障点八：IPsec over GRE错误
　　故障现象：
　　在RT5上使用源为192.168.200.1 目标为总部的OA流进行ping测试，网络不通，在RT4上使用“display  ike sa”观察ipsec 的两个阶段的协商是否建立，发现两个阶段均无协商成功。
　　故障分析：
　　1)       ike peer的预共享密钥是否配置正确
　　2)       是否指定对端peer的地址
　　3)       安全提议是否一致
　　4)       安全ACL是否互为镜像
　　5)       Ipsec policy是否在接口下调用
　　故障解决：
　　1)       在RT4上使用“display ipsec policy”查看策略是否应用在接口上，发现策略应用在了tunnel口上。
　　2)       在RT2上使用“display ipsec policy”查看策略是否应用在接口上，发现策略调用在了物理接口g0/0/2上
　　3)       在R4和RT2上使用“display ike peer”查看ike peer中的预共享密钥和对端的地址是否指定正确，发现预共享密钥和隧道的对端地址均为错误。
　　4)       在RT4和RT2上使用“display ipsec proposal”查看ipsec 的安全提议是否一致，发现安全提议一致
　　5)       在RT4上使用“display acl  all”查看安全acl是否配置正确，发现安全acl正确
　　6)       由于ipsec over gre 中ipsec 隧道的对端地址为gre隧道接口地址，因此应该调用在tunnel口上而并非物理口。
　　7)       进入RT2的g0/0/2接口，使用“undo ipsec policy”取消物理口的策略绑定，将策略绑定在隧道接口。
　　8)       在RT5上使用源为192.168.200.1 目标为总部的192.168.20.254进行测试，发现网络互通，且ipsec 两阶段的协商均正确建立，此故障排除。
　　故障点九：路由过滤错误
　　故障现象：
　　题目要求AS65000禁止将从其他自治系统学习到的BGP路由发布给AS65001，而在RT1、RT2上通过查看，发现发布时调用的route-policy 匹配的as-path acl 不存在，且创建了一个默认放行的空策略。
　　故障解决：
　　1)       在RT1和RT2的系统视图下使用“ip as-path  1 permit ^$”创建一个组号为1 的仅匹配本地AS的路径访问控制列表。
　　2)       在RT1和RT2上执行下面命令删除发布路由时的route-policy fk的默认放行的空节点
　　undo route-policy fk permit node 20
　　此故障排除。
　　故障点十：NAT错误
　　故障现象：
　　在RT5上使用源为192.168.200.1 目标为RT4公网出接口的对端地址200.0.0.2 进行ping测试，发现网络不通。在RT4上使用“display nat session”查看转换条目，发现条目为空。
　　故障分析：
　　1)       本地是否有到达外网的默认路由
　　2)       RT4的外网出接口是否做NAT
　　3)       NAT匹配流的ACL是否正确
　　故障解决：
　　1)       在RT5上通过使用“dis ip route ”发现本地存在默认路由
　　2)       在RT4上使用“display  nat bound”查看公网接口是否做NAT，公网接口已经做NAT
　　3)       使用“dis acl 2000”查看nat匹配流的acl是否正确，发现该acl不存在。
　　4)       在RT4的系统视图下使用“acl number 2000 match-order config”创建该acl，在acl视图下创建规则匹配源为192.168.200.0 的网段“rule permit source 192.168.200.0 0.0.0.255”，此故障排除。