不涉及
S125和对端两台路由器对接,设备运行中出现,ospf邻居断开并保持在ExStart状态
Debug信息显示交换机没有收到对端的ospf dd报文,但是在交换机侧流统可以统计到DD报文,说明DD报文没有上送平台处理,那就要从设备端口到上送平台这一阶段着手。
如下,收到的都是组播地址,没有单播DD报文,
*Dec 29 11:54:01:149 2018 C02-N1/C01-N2-H3C-S12508-1 RM/6/RMDEBUG:OSPF 100: RECV Packet.
*Dec 29 11:54:01:149 2018 C02-N1/C01-N2-H3C-S12508-1 RM/6/RMDEBUG:Source Address: 66.224.100.131
*Dec 29 11:54:01:149 2018 C02-N1/C01-N2-H3C-S12508-1 RM/6/RMDEBUG:Destination Address: 224.0.0.5
*Dec 29 11:54:01:149 2018 C02-N1/C01-N2-H3C-S12508-1 RM/6/RMDEBUG:Ver# 2, Type: 1, Length: 52.
*Dec 29 11:54:01:150 2018 C02-N1/C01-N2-H3C-S12508-1 RM/6/RMDEBUG:Router: 66.225.10.4, Area: 0.0.0.0, Checksum: 50852.
*Dec 29 11:54:01:150 2018 C02-N1/C01-N2-H3C-S12508-1 RM/6/RMDEBUG:AuType: 00, Key(ascii): 0 0 0 0 0 0 0 0.
*Dec 29 11:54:01:150 2018 C02-N1/C01-N2-H3C-S12508-1 RM/6/RMDEBUG:Net Mask: 255.255.255.128, Hello Int: 10, Option: _E_.
*Dec 29 11:54:01:151 2018 C02-N1/C01-N2-H3C-S12508-1 RM/6/RMDEBUG:Rtr Priority: 1, Dead Int: 40, DR: 66.224.100.131, BDR: 66.224.100.130.
*Dec 29 11:54:01:151 2018 C02-N1/C01-N2-H3C-S12508-1 RM/6/RMDEBUG:Attached Neighbor: 66.225.10.1.
*Dec 29 11:54:01:151 2018 C02-N1/C01-N2-H3C-S12508-1 RM/6/RMDEBUG:Attached Neighbor: 66.225.10.3.
首先查看端口下的配置,发现vlan虚接口下有包过滤
interface Vlan-interface200
ip binding vpn-instance guanli
ip address 66.224.100.129 255.255.255.128
packet-filter 3003 inbound
检查该acl 3003,发现该acl没有放通ospf报文,现场将acl中添加rule 0 permit ospf解决
但是现场之前正常运行,突然出现了问题,为什么会出现这种情况呢?
首先看下设备底层的实现,对于224.0.0.5和224.0.0.6的报文底层下发如下两条acl来copy to CPU,其余的和ospf相关的acl只有修改cos值和限速用的。ospf的单播报文和普通的目的IP为本设备的报文相同,是通过查表而不是acl来上送CPU的。
========
Acl-Type RX IPv4 Middle High, Stage IFP, Global, Installed, Active
Prio Mjr/Sub 523/19, Group 2 [2], Slice/Idx 2/29, Entry 825, Double: 1053/1565
Rule Match --------
Ports: 0x0bfffffe; 0xffffffff
Lookup: VLAN ID valid[y], STP forwarding, 0x1c, 0x1c
Dest IP: 224.0.0.6, 255.255.255.255
IP protocol: ospf
Vlan Class id: 0x0 Mask: 0x20
Actions --------
CAR cir 0x400, cbs 0x800, pir 0x400, pbs 0x800, mode srTCM color blind
Account mode packets, green and non-green
Copy_to_cpu : Yes
Change CPU pkt COS 30
Permit
Red Deny
Red_Copy_to_cpu : No
Yel Deny
Yel_Copy_to_cpu : No
MatchedName:12, IPV4_MC_OSPF_6
Accounting: Hi 0, LO 0
========
Acl-Type RX IPv4 Middle High, Stage IFP, Global, Installed, Active
Prio Mjr/Sub 523/19, Group 2 [2], Slice/Idx 2/30, Entry 826, Double: 1054/1566
Rule Match --------
Ports: 0x0bfffffe; 0xffffffff
Lookup: VLAN ID valid[y], STP forwarding, 0x1c, 0x1c
Dest IP: 224.0.0.5, 255.255.255.255
IP protocol: ospf
Vlan Class id: 0x0 Mask: 0x20
Actions --------
CAR cir 0x400, cbs 0x800, pir 0x400, pbs 0x800, mode srTCM color blind
Account mode packets, green and non-green
Copy_to_cpu : Yes
Change CPU pkt COS 30
Permit
Red Deny
Red_Copy_to_cpu : No
Yel Deny
Yel_Copy_to_cpu : No
MatchedName:11, IPV4_MC_OSPF_5
Accounting: Hi 0, LO 0
========
然后查看优先级发现,224.0.0.5/6在优先级高于包过滤,所以配置两边可以交互hello报文,但是后面的单播报文被过滤掉了
97 PktFilter IP on PORT FALSE 8 28
9 RX IPv4 Middle High TRUE 11 19
检查设备发现主用引擎在故障前重启了,根据现场的现象应该是:
1、建立的邻居时未配置包过滤,所以可以正常建立邻居
2、然后添加了包过滤,此时ospf邻居建立成功后只会交互hello报文和update报文,都是224.0.0.5/6了
3、主备切换后ospf邻居重新建立,单播报文被过滤。
现场将acl中添加rule 0 permit ospf解决
目前早期的S12500实现方式如此, 其他产品如S6800等都是通过acl将单播的ospf报文上送的CPU。
该案例暂时没有网友评论
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作