Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPv6 Neighbor Advertisement缺少Source Link-Layer Address字段无法更新邻居信息导致丢包 #963

Open
qazzsq101 opened this issue May 30, 2024 · 0 comments
Assignees
Labels
issue/to-solve issues await answers tobe solved

Comments

@qazzsq101
Copy link

复现协议:IPv6
复现条件:DPVS NA应答交换机NS报文,缺少Source Link-Layer Address字段使交换机无法更新邻居信息导致部分丢包
复现版本:1.8.10
负载模式:Fullnat
台数:3台DPVS(以下称为DPVS-A,DPVS-B,DPVS-C)
MAC地址:M1,M2,M3 与上面台数一一对应
IP地址:IP1,IP2,IP3 与上面台数一一对应
对端邻居(当前网关):华为 FM 12804 数据中心交换机 2台(Vxlan多活网关架构)
概率性:小概率事件

场景复现:
前景:
其中一台 FM 12804学习到DPVS-B的MAC地址为M1(应该学习到的正确地址是M2,学错原因无从考究,可能是调试或者其他原因学习到的)。

在交换机M1地址age老化后:
1、交换机向DPVS-A,DPVS-B同时发送NS报文要求更新邻居信息,报文使用的IPv6和链路层信息如下
DPVS-A:(IP2,M1)(报文这里用了B的ipv6地址IP2,而不是IP1
DPVS-B:(IP2,M2)

2、交换机同时收到A和B的NA回包,并且全都缺少Source Link-Layer Address字段,导致交换机仅更新age时间,不会更新邻居信息,报错问题在这种老化事件中不断循环。

这个问题摇了华为交换机研发上来一同查了好几天,最终查出来是这个原因,华为侧给出的答复是Source Link-Layer Address虽然不是RFC必选字段,但是读取Source Link-Layer Address更新邻居信息是符合RFC协议规范。

后续我看了下咱们的源代码/src/ipv6/ndisc.c ndisc_send_na,ndisc_build_mbuf,似乎确实没有实现这个字段,期望能补齐。

另外DPVS-A收到了非自身IP报文还做了回复,是否应该加个过滤? (dpip link show 里面网卡没开混杂模式,没有promisc字段)

@ywc689 ywc689 self-assigned this May 30, 2024
@ywc689 ywc689 added the issue/to-solve issues await answers tobe solved label May 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
issue/to-solve issues await answers tobe solved
Projects
None yet
Development

No branches or pull requests

2 participants