vyos-1x.git/python, branch nos-task-id

configsession: T9156: add consistent use of finalizers

2026-08-03T16:42:49+00:00

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.

Merge pull request #5335 from natali-rs1985/T8367

2026-07-23T14:34:03+00:00

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

Merge pull request #5327 from BradKollmyer/T9076-remote-group-interval

2026-07-23T14:28:21+00:00

firewall: T9076: add per-remote-group update interval

T9105: confirm existence of config-mode file before use

2026-07-20T19:25:16+00:00

The vyos-configd list of config mode files available for loading is generated at build time, however, this can be a superset of files present on the running system; confirm existence before load. An example of the above discrepancy is apparent in case supplementary *.deb packages are not required. Recent refactoring of vyos-configd dropped a legacy construction independent of the build-time list, introducing the regression.

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.

utils: T9008: migrate remaining cmd() callers to cmdl() and remove cmd()

2026-07-17T16:10:08+00:00

Complete the safer-subprocess migration started by the cmdl()/ifconfig refactoring and convert every remaining vyos.utils.process.cmd() call site to the list-based cmdl(). Drop the vyos.utils.process.cmd() implementation as it is no longer in use.

Merge pull request #5318 from jestabro/config-manager

2026-07-15T13:27:30+00:00

T9068: Add config manager module and refactor vyos-configd

firewall: T9076: add per-remote-group update interval

2026-07-10T23:31:18+00:00

Add 'set firewall group remote-group interval ' to control how often each remote group list is re-downloaded, independent of the global resolver-interval that also drives domain-group/FQDN resolution. The value accepts plain seconds or time-unit suffixes s/m/h/d/w (e.g. 4h), range 60 seconds to 4 weeks, enforced at commit time after conversion. When unset, the group keeps following 'firewall global-options resolver-interval', so existing configurations are unaffected. vyos-domain-resolver now tracks a last-update timestamp per remote group and sleeps until the next due update instead of a fixed resolver-interval tick, honoring per-group intervals both shorter and longer than the global one. A group is only stamped as updated after a successful download; failed downloads fall back to the cached list and are retried at the resolver cadence rather than after the full group interval. human_to_seconds() now treats a plain number as seconds instead of returning 0. Co-Authored-By: Claude Fable 5

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