[FROG] Setting defaults for autodetected VRFs/VxLANx

Eugene Crosser crosser at average.org
Mon Jul 15 09:04:13 EDT 2019

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 self offload
9e:ac:3b:97:76:7c dst self offload
ae:65:c5:d5:80:67 dst 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'

I would really like to understand how it all fits together, if we are to
run this thing in production...

Thanks again,


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.frrouting.org/pipermail/frog/attachments/20190715/1f471505/attachment.sig>

More information about the frog mailing list