Allow providing the MAC address for the uplink gateways on OVN

[stgraber]

Is there an existing issue for this?

• [x] There is no existing issue for this feature

What are you currently unable to do

Currently the gateway MAC addresses are determined by OVN effectively through ARP. This usually works fine, but can be problematic in more complex environments that use floating gateways through VRRP or similar.

In this environment, the MAC address is well known and could be applied directly, avoiding any risk of picking up the wrong MAC through ARP or NDP.

What do you think would need to be added

I'd like to add two options to the physical network:

• ipv4.gateway.hwaddr
• ipv6.gateway.hwaddr

This would then seed entries into the Static_Mac_Binding in the NorthBound so that we don't end up with dynamic entries for the gateway in the SouthBound database.

[davidbockelman]

Hello, I'm a student at UT in Professor Chidambaram's Virtualization course. Could me and my partner take on this issue?

[stgraber]

For sure!

[OGCbn]

I am @davidbockelman 's partner, could I be added.

[davidbockelman]

Hello, me and my partner have a plan to address this issue, but we want to make sure it's the right approach before continuing. As we understand it, for a OVN network with the ipv4.gateway.hwaddr and/or ipv6.gateway.hwaddr options set, we want to create a Static_Mac_Binding entry for the network's internal logical router port on the logical router. This would essentially replicate the behavior of this command: ovn-nbctl create static_mac_binding \ ip=<the-internal-gateway-IP> \ logical_port=<router-name>-lrp-int \ mac=<ipv4.gateway.hwaddr> From an implementation standpoint, we would be looking at the creation of the internal logical router port in the setup() function in driver_ovn.go, and seed the Static_Mac_Binding there. Are there any flaws in this plan or areas we've missed?

[davidbockelman]

We're a little confused on how our new options would interact with the bridge.hwaddr option. It seems like this option allows the user to apply a specific MAC address to the logical router's ports. In that case, would this option conflict with our new options (i.e. only one or the other can be set)?

[stgraber]

bridge.hwaddr controls the MAC address of the OVN logical router itself, ipv4.gateway.hwaddr and ipv6.gateway.hwaddr set on the uplink network allows providing the external gateway address which is what all traffic will head through when exiting the logic router through it's external port.

[stgraber]

The entry should look like:

ip=192.168.0.1
logical_port=incus-net1-lr-lrp-ext
mac=00:16:3e:71:1e:01

So your approach is fine minus the fact that it needs to go onto lrp-ext, not lrp-int.

[davidbockelman]

Thanks! So, just to clarify, we're adding the new config options to the network types that can be an uplink network (physical, bridge), not the ovn network type itself? Then, when setting the uplink network for an ovn network, we would check if the uplink network has any of these new options, and if so, seed the Static_Mac_Binding at the ovn network's external logical router port? Thanks in advance for your help.

[stgraber]

Yes, that's correct, in fact, only to the physical network type as that's the only case where the gateway isn't already known and under our control.

The physical network type is also the only place where an OVN uplink has an ipv4.gateway or ipv6.gateway field.

And yes, that's correct, when bringing up the OVN network, we'd check if its uplink has those keys and if so, add the required Static_Mac_Binding entries. If not, we should clear any Static_Mac_Binding for that interface (lrp-ext).