Repository navigation
IPv6 L2 Announcements unreachable behind Proxmox Linux bridge with multicast snooping #46274
Description
Is there an existing issue for this?
- I have searched the existing issues
Version
equal or higher than v1.19.4 and lower than v1.20.0
What happened?
IPv6 LoadBalancer VIPs managed by Cilium L2 Announcements were unreachable when running behind a Proxmox Linux bridge with multicast_snooping=1.
The lease holder was correctly elected and the VIP was present in the IPv6 L2 responder map. The solicited-node multicast MAC address was also programmed on the lease holder interface.
However, Neighbor Solicitations sent to the VIP's solicited-node multicast group (ff02::1:ff00:1) never reached the lease holder node. As a result, no Neighbor Advertisement was generated and the client could not resolve the VIP's MAC address.
Disabling Linux bridge multicast snooping immediately restored connectivity:
echo 0 > /sys/class/net/vmbr0/bridge/multicast_snoopingAfter disabling snooping, Neighbor Solicitations reached the lease holder and IPv6 connectivity to the LoadBalancer VIP worked as expected.
How can we reproduce the issue?
- Deploy a Kubernetes cluster using Cilium v1.19.4 on VMs connected through a Proxmox Linux bridge (
vmbr0). - Ensure Linux bridge multicast snooping is enabled (default configuration):
cat /sys/class/net/vmbr0/bridge/multicast_snooping
# 1- Enable Cilium L2 Announcements.
- Create an IPv6 LoadBalancer Service and ensure a lease holder is elected.
- Verify that the VIP appears in the IPv6 L2 responder map.
- From another host on the same L2 network, attempt to connect to or ping the IPv6 LoadBalancer VIP.
- Observe that Neighbor Solicitations for the VIP are transmitted by the client but do not reach the lease holder node.
- Observe that the client's neighbor entry remains unresolved (FAILED).
- Disable Linux bridge multicast snooping:
echo 0 > /sys/class/net/vmbr0/bridge/multicast_snooping- Retry the same test.
- Observe that Neighbor Solicitations now reach the lease holder and the IPv6 VIP becomes reachable.
Cilium Version
Client: 1.19.4 95e477fd 2026-05-13T02:45:22+00:00 go version go1.25.10 linux/amd64
Daemon: 1.19.4 95e477fd 2026-05-13T02:45:22+00:00 go version go1.25.10 linux/amd64
Kernel Version
Kubernetes Node:
Linux k8s-tenant-cp-1 6.8.0-117-generic #117-Ubuntu SMP PREEMPT_DYNAMIC Tue May 5 19:26:24 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
Proxmox Node:
Linux pve2 7.0.2-6-pve #1 SMP PREEMPT_DYNAMIC PMX 7.0.2-6 (2026-05-20T08:55Z) x86_64 GNU/Linux
Kubernetes Version
Server Version: v1.36.1
Regression
Unknown.
This is the first version where I tested IPv6 L2 Announcements in this environment (Cilium v1.19.4), so I cannot confirm whether this is a regression or an existing limitation.
I have not yet tested earlier Cilium versions.
Sysdump
No response
Relevant log output
Anything else?
This issue may be related to #44311, although the observed behavior appears slightly different.
P.S. It seems that the issue #43530 I raised previously was related to this. I was still rather inexperienced at the time, and I apologise for any inconvenience caused.
Cilium Users Document
- Are you a user of Cilium? Please add yourself to the Users doc
Code of Conduct
- I agree to follow this project's Code of Conduct
Activity
bersoare commentedon Jun 2, 2026
looks like the current code signals only the L2 layer about the address (change NIC mcast filters to accept the packets), so the kernel doesn't do an explicit join towards the group. without the MLD join, the bridge is never aware of the receiver.
https://github.com/cilium/cilium/blob/main/pkg/datapath/l2responder/l2responder.go#L473
the fix could be as simple as performing join/leaves at the L3 layer, but i need to get a better understanding of the surrounding logic to make sure we handle some edge cases properly (ex: ipaddr -> solicited node mac reference tracking)