许鹏鹏,某局点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直连不通
