许鹏鹏,某局点5560X ipv6直连不通
组网及说明
交换机--------服务器
问题描述
交换机下挂服务器,从该交换机主动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
CRM论坛(CRMbbs.com)——一个让用户更懂CRM的垂直性行业内容平台,CRM论坛致力于互联网、客户管理、销售管理、SCRM私域流量内容输出5年。 如果您有好的内容,欢迎向我们投稿,共建CRM多元化生态体系,创建CRM客户管理一体化生态解决方案。本文来源:知了社区基于知识共享署名-相同方式共享3.0中国大陆许可协议,某局点5560X IPv6直连不通