On 6/8/26 1:58 PM, Chanyeol Yoon wrote: > Hi all (and Ales, Dumitru), >
Hi Chanyeol Yoon, > 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. > Glad to hear that worked! > 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. > The kernel bridge (SVI) is a representation of the router port (or the other way around depending on how you look at things). So yes, they should have the same MAC address. Maybe we need to update our documentation a bit to make that requirement more explicit. > 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. > Right, that's expected. > 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. I'd check with neutron folks, it sounds like this could break easily if they ever reconcile the router port configuration, e.g., I remember there are neutron tools to resync the NB database according to what's in the neutron databases. > - 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. > Yes, it's a requirement. See above. > 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`. > I see it as the integrator's responsibility. > 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. > I don't know, I'll CC some neutron folks (Jakub, Daniel) in case they can share more info on this front. > 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? > If I'm reading this correctly, I think what you need is a DGP LRP bound to each chassis. The LRP mac should match the bridge MAC on the chassis it's bound to. > 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. > Thanks for trying it out! Regards, Dumitru > 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 > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
