Hi all (and Ales, Dumitru),
This is a separate topic from the FIP Type-2 advertisement RFC I raised
back in May [1]. Following that discussion, I decided to go with Type-5
for floating IPs instead - since FIPs are NAT entries on the Logical
Router, they advertise naturally as Type-5 (IP prefix) through the LR
NAT path, without needing the northd/FDB changes we discussed for the
Type-2 case. That path works well: bidirectional traffic to a FIP
succeeds (0% loss, ttl=63) in my Kube-OVN based OpenStack/Neutron setup.
While getting Type-5 working, I ran into a question about kernel bridge
MAC handling that I'd like to confirm, since the OpenStack deployment
model differs from the multinode.at scenario.
Background
----------
In the L3 EVPN multinode test, the LRP MAC is assigned at lrp-add time
with a deterministic value (e.g. 00:00:00:01:00:$vni), and the kernel
bridge (br-$vni) is created with the matching MAC. So
"kernel bridge MAC == LR gateway MAC == Rmac == inner dst MAC" holds by
construction.
In an OpenStack/Neutron deployment the order is reversed: Neutron creates
the logical router and assigns the gateway LRP a random MAC
(fa:16:3e:xx:xx:xx) before we get involved. So we align the kernel bridge
MAC to the Neutron-assigned LRP MAC after the fact:
ip link set br-$vni address $LR_GW_MAC
If the bridge MAC does not match the LRP MAC, the decapsulated packet is
bridged at L2 and never reaches the OVN router pipeline (the DNAT path is
not hit). Aligning them makes it work.
What we verified
----------------
- Setting the LRP MAC to a fixed/anycast value (e.g. 00:00:5e:00:01:0a)
via nbctl works, and Neutron does not revert it under normal operation.
- With the bridge MAC aligned to that LRP MAC, FIP traffic via Type-5
works end to end.
Questions
---------
1. Is the "kernel bridge MAC == LR gateway MAC == Rmac == inner dst MAC"
alignment an intentional, required invariant of the native EVPN
design? The multinode test sets them up consistently, and our testing
confirms it's necessary, but I'd like to confirm it's by design.
2. Is aligning the bridge MAC meant to be the integrator's
responsibility, or is there an intent for ovn-controller to program
the bridge MAC from the LRP MAC automatically as part of
dynamic-routing? We currently do it manually with `ip link set`.
3. For OpenStack/Neutron, where Neutron assigns the LRP MAC up front, is
the recommended approach to (a) align the kernel bridge MAC to the
Neutron MAC, or (b) force a deterministic/anycast LRP MAC and align
the bridge to it? We've verified (b) is not reverted under normal
operation, but haven't yet confirmed whether a Neutron router update
event (e.g. adding an interface) could re-assert the original MAC. If
you know the expected behavior at that level, it would help.
4. In a multi-node / multi-VNI setup, is there guidance on Rmac
consistency? With per-node bridge MACs the advertised Rmac differs per
node (it still works, since each Type-5 prefix carries its own Rmac),
but a deterministic per-VNI MAC across nodes seems cleaner for VM
migration and operational tracking. Is that the intended direction?
This is in a real OpenStack deployment (OpenStack-Helm on Kubernetes,
Kube-OVN), so I'm trying to understand the recommended integration
pattern rather than just what happens to work in a lab.
Thanks for the great work on the native EVPN integration.
Best regards,
Chanyeol Yoon
KT Cloud
[1] https://mail.openvswitch.org/pipermail/ovs-dev/2026-May/432232.html
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
