Re: [D] EVPN-VXLAN - IPv6 via SLAAC [cloudstack]

["wido (via GitHub)" <gi...@apache.org>]

GitHub user wido closed the discussion with a comment: EVPN-VXLAN - IPv6 via SLAAC

> Finally, we found the problem which is related to VXLAN flags. When IPv6 multicast packets enter our fabric the VXLAN packet somehow gets the flags `0x0a00` instead of `0x0800`, which is being ignored by the kernel and the packet is dropped. See the corresponding code fragment here: https://elixir.bootlin.com/linux/v5.14.21/source/drivers/net/vxlan.c#L1905
> 
> This seems to be a problem with SONiC itself and we will check here further.
> 
> The temporary fix is:
> 
> ```
> tc qdisc add dev ens1f0np0 clsact
> tc filter add dev ens1f0np0 ingress pref 1 proto ip flower ip_proto udp dst_port 4789 action pedit munge offset 28 u8 set 0x08
> tc qdisc add dev ens1f1np1 clsact
> tc filter add dev ens1f1np1 ingress pref 1 proto ip flower ip_proto udp dst_port 4789 action pedit munge offset 28 u8 set 0x08
> ```

I ran into this issue today as well with a Juniper QFX5120 switch acting as L3 gateways.

Looking with Wireshark I looked at the UDP VXLAN packets and decoded them:

- IPv4 packets have flag 0x0800
- IPv6 packets have flag 0x0800, but a Router Advertisement has 0x0a00

I don't know WHY this is happening either. Host is running FRR 10.5 with kernel 6.17.

I tried your 'tc' rules, but they didn't work for me. Need to figure that one out.

GitHub link: https://github.com/apache/cloudstack/discussions/8685#discussioncomment-15921278

----
This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscribe@cloudstack.apache.org