- Cannot have LCP, Address or Sub-Interface
- Cannot be PHY
- Cannot be Bond member
- Can be target of L2XC
- Can be member of Bridge
- interface.mtu must be the same as tap.host.mtu
Add YAML tests for common mistakes. This unblocks taps becoming members
of a bridgedomain, and allowing a very cool feature: slowpath networking!
Add int_to_mode() and int_to_lb() in config/bondethernet.py to map back
the retrieved values from VPP into their config strings.
Implement bond and bridge settings dumper, dumping all settings even if
they are default. This helps the user understand the configurable
options.
This requires a schema change, adding 'mode' and 'load-balance' fields,
a semantic invariant that 'load-balance' can only be set in the case of
LACP and XOR bonds, a mapper from the mode/lb strings, ie.
"round-robin" to their VPP numeric counterparts, a bunch of unit tests.
Then in the reconciler, changing bonds (__bond_has_diff()) will
invalidate any LCP or sub-interfaces built on them, so those will have
to be pruned. create_bondethernet() will now create (or re-create)
the bond with the correct flags.
Unit-tests, YAML tests and the integration test all pass.
Updated config-guide.
TIL! Using the existence of obscure member sys._MEIPASS, I can detect if
we're running from a bundled PyInstaller binary, versus running from Python
directly.
Add schema.yaml to the datas of the PyInstaller spec. Then, if the
-/--schema flag is given, use it, and if it's not given, default to the
built-in one if we're running from a bundled binary, or fall-through to
./schema.yaml in other cases.
This avoids the need for config/schema.py as a carbon-copy of the schema,
slick!
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.
Bridge Domains must be [1,16M), Loopbacks must be [0,4096).
Loopbacks should be allowed to have an address without an LCP.
=> Reuse the unittest file for the bounds check for loopbacks.
=> Add a new unittest file for the bounds check for 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
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).
