EVPN asymmetric irb: Automatically pull in all vxlan-enabled vlans (per vrf)

[jbemmel]

I'm looking to add further support for asymmetric IRB. This model assumes all VTEPs know all L2 VNIs, even if they have no hosts attached locally - so I'm thinking the logic should pull in all vlans when a vrf has asymmetric irb enabled ( evpn enabled but no transit_vni )

Is that ok, or do people prefer to leave it up to users to manually make sure all vlans are present where needed?

[ipspace]

It's too much hassle. Not only do you have to pull in VLANs on nodes that don't use them, you also have to create VLAN (and VXLAN) interfaces out of thin air on nodes that have no physical interfaces using those VLANs, and that's where I gave up and decided not to support it.

Asymmetric IRB won't work (at the moment) regardless of how you try to tweak the lab topology, and I don't think it's a worthwhile investment of time to try to make it work.

[ipspace]

Here's an idea I got now that we fixed those pesky node_data VRFs and VLANs.

On most platforms, asymmetric IRB won't work even if we pull in VLAN data because the VLAN interface won't be there (and we need an IP address in the destination VLAN for IRB to work).

How about adding create_interface attribute to VLANs -- that would trigger the creation of VLAN interface even when there are no physical interfaces using that VLAN. I would suggest we use string value 'irb' (only when the VLAN mode is not bridge) or 'always'.

The EVPN module could then set that flag on every VLAN EVPN cares about.

[jbemmel]

Would you prefer this over an approach in which the evpn module imports a 'create_svi_interface' method from the vlan module, and invokes that on selected vlans?

It's "flag-and-create-in-one-place" versus "create-where-needed"

The "flagging" approach opens the door to users to create interfaces in situations where they are not needed/used...

[ipspace]

If I've learned anything during the hours I wasted today fixing bugs, it's that tight coupling between modules tends to be a bad idea.

As for "creating interfaces where they are not needed/used", we're giving people enough rope in so many places that one more won't hurt (just look at a half-dozen addressing methods, most of them implemented because someone was looking for future flexibility ;).

Finally, we would need the extra interfaces in VXLAN-only asymmetric IRB, in VXLAN VRF Lite implementation, in using VXLAN as an overlay transport between routers... Wait until I get this implemented ;))

[ipspace]

Implemented in d5eb0fa and 520b675