vxlan purging remotes is a feature where we clean up
existing fdb remote entries in favor of the ones specified in the
interfaces file. Obviously in precense of an external controller
like bgp or vxrd this is not a good thing because these remotes
maybe installed by these external controller daemons.
This patch makes the purgining behaviour explicit by a new attribute.
We will ship with a default policy file which sets vxlan-purge-remotes to no.
This also cleans up a bug introduced by fix to CM-13767 where we were
trying to delete default remote entry pointing to the local ip.
more details below.
problem:
for static configuration, ifupdown2 has some code to "purge" existing
default remote fdb entries and install
new ones corresponding to the ones specified in the interfaces file
(with vxlan-remoteip).
For non-static configuration (ie in presence of an external controller),
it skips this "purge"...because these entries
maybe added by an external controller. To detect that there is no
external controller running..., today it
checks if the vxrd process is running or not. We need to extend this
check to now include bgp (for evpn)...and it gets trickier with bgp
since just checking the quagga pid is not good.
Solution:
I would like to make this purging explicit with an attribute. This patch
adds a 'vxlan-purge-remotes yes|no' attribute. vxlan remote address purging
will take into affect when:
vxlan-remoteip attribute is present in the interfaces file
or
vxlan-purge-remotes is set to 'yes'
We will ship a ifupdown2 default policy file to disable purging by
default (vxlan-purge-remotes no).
For existing customer deployed static configs, since the interfaces file
will already have remote entries, this change
will behave as existing code (ie purge = yes).
For existing vxrd deployments, as long as already deployed interfaces
files have no vxlan-remoteip entries,
this patch does not change any behavior (can people confirm that
existing vxrd deployments have no vxlan-remoteip entries in their
interfaces ?)