Thanks for the response! On 7/15/19 1:57 PM, Alexis Bauvin wrote:
My question is: should it be made possible (or maybe it is already possible?) to set default attributes for VRF/EVPNs that FRR autodetects? So that one could add something like this just once:
The issue with this is, with several VNIs provisioned in the VRF, how would you know which one is to be the L3VNI? As far as the interface "topology" goes in the Kernel, nothing differentiates a L2VNI from a L3VNI, except that a L2VNI may eventually have other interfaces enslaved to its bridge to be useful. But there can always be a moment where even a L2VNI only has a single interface, the VXLAN one (e.g. during provisioning). TL;DR: how do you reliably discriminate the proper VNI?
If there is exactly one VxLAN interface in the tree that grows from this VRF, then use its VNI. If there is none or more than one, then do not apply the default. Assuming that "simple" configurations will only have one VxLAN, and "complex" ones will require more sophisticated configuration anyway? And if the VRF interface was found "eligible for default config" at this stage, then also apply to it the "router bgp ... vrf DEFAULT" snippet. Shouldn't this work?
On a related note, I understand that currently FRR can fetch FDB only from 'bridge' interfaces, but not directly from VxLAN interfaces.
Partially correct: only bridges interfaces have a FDB (Forwarding DataBase), because a FDB is what makes a bridge a switch, and VXLAN interfaces don’t.
Umm?... I think they do? They a "logically" switches, aren't they? $ bridge fdb show dev vx1 9e:ac:3b:97:76:7c vlan 1 offload master br1 9e:ac:3b:97:76:7c offload master br1 ae:65:c5:d5:80:67 vlan 1 offload master br1 ae:65:c5:d5:80:67 offload master br1 72:57:cc:e1:7c:bd vlan 1 offload master br1 72:57:cc:e1:7c:bd offload master br1 1e:28:11:86:71:81 vlan 1 master br1 permanent 1e:28:11:86:71:81 master br1 permanent 72:57:cc:e1:7c:bd dst 10.42.16.6 self offload 9e:ac:3b:97:76:7c dst 10.42.16.8 self offload ae:65:c5:d5:80:67 dst 10.42.16.6 self offload
The FDB is needed because type 3 (VTEP) routes are installed in the FDB on the port corresponding to the VXLAN interface. And in L3VNI mode, to be able to route a packet, the data needed comes from three places: - Next hop IP comes from the routing table - Next hop MAC comes from the neighbor table - VTEP IP comes from the FDB, where the router’s MAC (or the type 3 route) is installed So sadly, the bridge is needed.
I am very probably missing something, but I do not see how the bridge's FDB can be useful when it is known to only bridge between two interfaces: VRF itself and VxLAN. MACs of all remote routes are (by definition) in the VxLAN's FDB. The only other FDB entry in the bridge will be the MAC of the VRF interface itself (or whatever enslaved interface is the "router"), and we know it anyway. I just cannot imagine how the switch (in this topology) can get _any_ MAC information that cannot be fetched from the VxLAN's FDB or from the other interfaces' configurations. I would really like to understand how it all fits together, if we are to run this thing in production... Thanks again, Eugene