vpp: T8367: Fix identical default MAC on bridged loopback interfaces

VPP assigns loopback interfaces a default MAC address derived only from
the interface instance number (de:ad:00:00:00:<instance>), with no
host-specific entropy. Two independent VPP nodes configuring the same
loopback instance (e.g. as a bridge BVI over VXLAN) therefore end up with
an identical MAC address.
When that MAC arrives from a peer over the shared L2 segment, VPP's L2
learning logic rejects it as a `mac move violation` - it's statically
pinned to the local BVI and cannot legitimately appear on another port.
This silently drops ARP traffic between the loopbacks while ordinary
bridged client traffic (unique MACs) is unaffected, breaking
loopback-to-loopback connectivity.
Add a mac-address option to the VPP loopback interface, and fall back to
a deterministic, host-unique MAC (derived from host UUID/hostname, same
scheme already used for container interfaces) whenever none is
configured, so the collision can no longer occur by default.
Also fix a related bug found while reproducing the above: a loopback is
fully deleted and recreated in VPP on every apply, receiving a new
`sw_if_index` each time. The loopback conf_mode script never registered
the bridge it's a BVI member of as a dependent, so the bridge kept its
L2 membership bound to the stale, deleted index instead of reattaching
the current one. Register the bridge dependency and reuse the existing
`verify_vpp_remove_bridge_interface()` check to block deleting a
loopback still in use as a BVI.

0 files changed, 0 insertions, 0 deletions