- 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!
Special care is taken for bondethernet, where the MAC changes when
the first member is added to it. BondEthernet requires its MAC to
be set in the bondethernets section, disallowing the MAC of individual
members to be set.
Also write a dumper for MACs of all types. Update integration test
cases to stress the MAC changes on loops, bonds, and phys.
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.
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).
Returns True if there is at most one occurence of the ip_interface (an IPv4/IPv6 prefix+len)
in the entire config. That said, we need the 'iface_addresses' because VPP is a bit fickle in
this regard.
IP addresses from the same prefix/len can be added to a given interface (ie 192.0.2.1/24 and
192.0.2.2/24), but other than that, any prefix can not occur as a more-specific or less-specific
of any other interface.
So, we will allow:
- any ip_interface that is of equal network/len of existing one(s) _on the same interface_
And, we will reject
- any ip_interface that is a more specific of any existing one
- any ip_interface that is a less specific of any existing one
Update unit tests to ensure ip_interfaces are allowed in all cases.
Refactor validator main function to avoid 'interface' symbol clash.
Add get_mtu() for interfaces, returns the sub-int's MTU or its parent's MTU, defaulting to 1500.
Ensure MTU for all bridge-domain members is set to the same value.
Ensure all bridge-domain members are L2 (have no LCP, have no address)
