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

Merge pull request #5355 from statio/T9128-nhrp-tunnel-firewall-rules

2026-08-03T14:19:35+00:00

nhrp: T9128: fix duplicate nftables meter name for multiple redirect tunnels

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.

nhrp: T9128: fix duplicate nftables meter name for multiple redirect tunnels

2026-07-27T07:07:24+00:00

Committing a second NHRP tunnel with "redirect" enabled failed with "Failed to apply NHRP tunnel firewall rules". The redirect chain in nhrpd_nftables.conf.j2 is rendered in a per-tunnel loop but hardcoded the nftables meter name "loglimit-0". With two redirect-enabled tunnels the loop declared the named set "loglimit-0" twice in table vyos_nhrp_redirect, which nft rejects, aborting the atomic ruleset load so the commit failed. Derive the meter name from the loop index (loglimit-0, loglimit-1, ...) so every redirect-enabled tunnel gets a unique meter. The first tunnel keeps the name "loglimit-0", leaving single-tunnel setups unchanged. Add a smoketest that configures two tunnels with redirect + multicast and verifies the commit succeeds and both meters are present. Also clear the "vpn ipsec" tree in tearDown so the IPsec profile created by the existing test does not leak into the new one.

dhcp-server: T9093: allow option interface-mtu up to 16000

2026-07-23T16:03:05+00:00

DHCP option 26 (Interface MTU, RFC 2132) is a 16-bit unsigned value and Kea accepts the full range, but the CLI validator capped it at 9000 - below the 9216 used on common jumbo fabrics and below VyOS's own interface MTU maximum of 16000. Relax the constraint to 576-16000 and exercise a jumbo value (9216) in the smoketest. Co-authored-by: Christian Breunig

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

Merge pull request #5324 from tjjh89017/frr-exporter-collectors

2026-07-20T15:05:37+00:00

T9073: frr-exporter: add CLI support for optional collectors and collector options

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 #5139 from sever-sever/T8529

2026-07-16T20:41:18+00:00

T8529: Add configuration CLI to enable OpenSSL FIPS