Bridges can be created with default settings, with specific settings,
and they can be sync'd at runtime with all of the settings in this
change.
Notably missing are two features:
- unknown unicast flooding into specific interfaces (as opposed to
on/off on the bridge)
- learn-limit, which does not have an API getter, only a setter.
The handling of BVI is awkward, with the autoderived interface name
"bviXX" based on the bridgedomain bd_id. Lots of special casing happens
on account of this decision, and to make matters worse there is poor
interaction (leading to VPP crashes) when BVIs and Loopbacks are used
at the same time: https://lists.fd.io/g/vpp-dev/message/21116
In this commit, I reintroduce the ability to set bridgedomain virtual
interfaces by means of the 'bvi' keyword. The 'bvi' must:
- be a Loopback interface
- must be used at most once (bvi_unique())
When pruning, I now need to prune bridgedomains before pruning
loopbacks, because any given loopback might be a BVI for a bridge. So,
I'll remove the loop/BVI from the bridge (by setting it to L3) and only
then removing the loopback from VPP.
In the reconciler, remove BVIs that have changed in prune_bridgedomains()
and set it in sync_bridgedomains().
The handling of BVI is awkward, with the autoderived interface name
"bviXX" based on the bridgedomain bd_id. Lots of special casing happens
on account of this decision, and to make matters worse there is poor
interaction (leading to VPP crashes) when BVIs and Loopbacks are used
at the same time: https://lists.fd.io/g/vpp-dev/message/21116
This is step one of a refactor of the logic. In this commit, I'm
removing all of the BVI logic from the codebase, rendering bridgedomains
unable to have IP interfaces. In the next commit, I will introduce new
behavior in the schema, allowing for 'bvi' to be a loopback
interfacename which will be used as BVI for a bridgedomain, restoring
the ability to use bridgedomains with IP interfaces (using a loop).
