vyos-1x.git/smoketest/scripts/cli/test_vpp.py, branch nos-task-id

vpp: T8468: Apply MAC address changes on VPP interfaces

2026-07-29T10:45:21+00:00

The interface config filter stripped the "mac" node, so a MAC address configured on a VPP interface never reached the dataplane. Allow "mac" through the filter; VPP applies it to the hardware interface via lcp-sync. Some DPDK drivers (e.g. vmxnet3) cannot change the MAC and would fail to bring the interface up. Reject such a change at verify time - both when setting the MAC and when adding an interface that already has one to VPP.

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

2026-07-20T09:02:54+00:00

VPP assigns loopback interfaces a default MAC address derived only from the interface instance number (de:ad:00:00:00:), 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.

Merge pull request #5314 from natali-rs1985/T9018

2026-07-09T13:56:31+00:00

vpp: T9018: Auto-enable promiscuous mode for interfaces with VLANs

vpp: T9062: Enable DHCP/DHCPv6 client detection on VLAN sub-interfaces

2026-07-09T09:26:19+00:00

The 'ip4-dhcp-client-detect' and 'ip6-icmp-ra-punt' VPP features were only ever enabled on the base ethernet interface, so DHCP and DHCPv6 clients never worked on VLAN sub-interfaces (vif/vif-s) of a VPP-managed interface. Apply the same feature toggles to each vif/vif-s using its own address configuration. vif-c is intentionally excluded, as Q-in-Q sub-interfaces are not currently functional under VPP.

vpp: T9018: Auto-enable promiscuous mode for interfaces with VLANs

2026-07-07T08:35:18+00:00

VPP drops VLAN-tagged frames unless the parent interface has promiscuous mode enabled, causing VLAN sub-interfaces to lose connectivity. Automatically enable promiscuous mode on VPP interfaces that have VLAN sub-interfaces (vif/vif-s) configured.

vpp: T8603: Expand ACL support to logical interfaces

2026-06-17T14:09:42+00:00

T8972: VPP: sync LCP interface VRF table binding

2026-06-16T11:17:37+00:00

Merge pull request #5130 from natali-rs1985/T8460

2026-04-24T12:43:36+00:00

vpp: T8460: Use isolated cpus for VPP cpu-cores

Merge pull request #5129 from inetman28/fix-acl-subinterfaces

2026-04-24T12:13:57+00:00

VPP: T8495: fix issue with assigning acl on sub interfaces

vpp: T8460: Use isolated cpus for VPP cpu-cores

2026-04-21T13:45:43+00:00

VPP CPU core assignment now uses kernel-isolated CPUs (from /sys/devices/system/cpu/isolated) with explicit corelist-workers instead of computing offsets from available cores with skip-cores/workers. Added validation that enough CPUs are actually isolated before VPP starts, and that isolate-cpus config only references existing CPU IDs. Moved smoketest for kernel option 'isolate-cpus' to test_vpp.py