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”,此故障排除。

05-04 04:36