交换机--------服务器
交换机下挂服务器,从该交换机主动ping 服务器地址不通,也学不到ND表项,但从服务器主动 ping 交换机是可以通,触发一下ping了之后交换机有了服务器的ND表项之后再从该交换机ping服务器也能通
经过检查,发现现场配置了ip urpf strict检查, ip urpf strict检查是检查接收报文的端口与以报文SIP查找fib表得到的下一跳出接口是否一致, 不一致报文就会被丢弃。
当收到NA报文时, 以SIP去查找fib表,只会匹配到网段路由,由于出接口是vlan虚接口, 与接收到报文的物理口不一致,故报文被丢弃。
另外使用6326版本测试,配置了ip urpf stric后,可以通,无法复现现场问题
使用6510版本测试,配置了ip urpf stric 后和现场现象一样,不通,配置松散模式可解决
经过确认:
NA报文是通过ACL上送CPU的,两个版本ACL上送的CPU动作不一样。R6510版本是copy to cpu, 而R6326版本是trap to cpu,存在差异的原因是,某些场景下需要透传NA报文,因此把动作改为了copy to cpu。
Mrvl芯片的ACl处理在前,配置ip urpf strict后,还会经三层引擎进行urpf检查,而urpf检查失败的处理动作是hard drop, Hard drop的优先级比copy to cpu高,所以R6510版本直接把报文丢弃,未上送CPU。
对于ACL动作是trap to cpu的情况,不会触发三层引擎进行urpf检查,报文直接上送cpu,所以R326版本没有问题。
R6510版本, NA ACL:
========
Acl-Type RX IPv6 High, Stage IPCL 2, Global, Installed, Active
Prio Mjr/Sub 0x30b/0x9, RuleFormat INGRESS_EXT_NOT_IPV6, Vtcame/Idx 4/33,
Rule Match --------
Global range
IP protocol: 0x3a, 0xff
ICMPV6_Type : 0x8800, 0xfe00
Mac to me: 1
Actions --------
Account mode packets, green and non-green
Copy_to_cpu : Yes
Change CPU pkt COS 3
Red Deny
Red_Copy_to_cpu : No
Yel Deny
Yel_Copy_to_cpu : No
MatchedName:47, IPV6_ND_DEST
Accounting: Hi 0, Lo 0
========
R6326 NA ACL:
========
Acl-Type RX IPv6 High, Stage IPCL 2, Global, Installed, Active
Prio Mjr/Sub 0x30b/0x8, RuleFormat INGRESS_EXT_NOT_IPV6, Vtcame/Idx 4/41,
Rule Match --------
Global range
IP protocol: 0x3a, 0xff
ICMPV6_Type : 0x8700, 0xff00
Mac to me: 1
Actions --------
Account mode packets, green and non-green
Redirect : Trap to cpu
Change CPU pkt COS 3
Red Deny
Red_Copy_to_cpu : No
Yel Deny
Yel_Copy_to_cpu : No
MatchedName:46, IPV6_ND_DEST
Skip the following PCL lookups
Accounting: Hi 0, Lo 0
可以使用松散模式解决 ip urpf loose
该案例暂时没有网友评论
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作