This makes it clearer what its purpose is, in preparation of actual VPP
dataplane configuration changes. For example remove_lcp() refers
currently to the removal of the LCP from the cache, not the VPP
dataplane itself, so rename it and its siblings cache_remove_*()
instead.
In a future commit, the call remove_*() will refer to the removal of an
object _in VPP_.
file was copied from another project (github.com/pimvanpelt/vpp-snmp-agent) which contains code from another author. That author is not affiliated with this repository, so remove them from the LICENSE file.
Instead of writing the CLI calls to stderr as INFO loglines, now add
them to a list of messages by prune/create/sync.
Always close the VPP connection after finishing, by adding a destructor
to the VPPApi class.
At the end of each phase, print out what was gathered to stdout. Later,
I will make this more advanced (output to file, output directly to a
pipe of a running vppctl binary, etc).
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).
What this means is that the synchronization will run based on loops over
the configuration, rather than over the VPP state. The benefit of this
approach is that no additional API calls have to be made after the
initial VPP configuration is read, making pre-flight checks and diffing
more obvious.
Further, make sync_link_mtu() direction-aware; first we will raise the
link_mtu for interfaces that are growing, and after setting all the
children up/down with sync_mtu_direction() we'll finally shrink
sync_link_mtu() where needed.
We can now do an entire reconciliation run with only one API read at the
beginning!
Include special caveat on LCP MAC changes, for which I'll put in a
TODO for now with a VPP comment {} with the to be run command.
Also make the user aware of a quick in BondEthernets not being able
to have link_mtu != 9000 so if a packet MTU > 9000 is set, this will
work but is an undesirable configuration. Issue a warning in this
case.
