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

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.

Merge pull request #5139 from sever-sever/T8529

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

T8529: Add configuration CLI to enable OpenSSL FIPS

Merge pull request #5332 from BradKollmyer/T9084-rdnss-lifetime-zero

2026-07-16T17:29:05+00:00

router-advert: T9084: allow name-server-lifetime 0 in CLI validator

T9084: Merge ranges into one for lifetime validator

2026-07-16T15:13:31+00:00

Co-authored-by: Alexandr K.

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

2026-07-16T11:46:02+00:00

frr_exporter v1.5.0 enables the bgp, ospf, bfd and route collectors by default, while bgpl2vpn, pim and vrrp must be enabled explicitly. Expose bgpl2vpn (CLI: bgp-l2-vpn) and pim under "service monitoring prometheus frr-exporter collector", following the same CLI style as the node-exporter collectors node. The vrrp collector is not exposed since VyOS implements VRRP with keepalived and FRR's vrrpd is never started. Also expose the collector options available in v1.5.0: - collector bgp accept-filtered-prefixes - collector bgp advertised-prefixes - collector bgp peer-description - collector bgp peer-group - collector bgp peer-hostname - collector bgp peer-type - collector ospf-instance - collector detailed-routes The bgp.* options are shared by the bgp, bgp6 and bgpl2vpn collectors upstream. The bgp6 collector remains unconditionally enabled, hence existing configurations render the same ExecStart and no migration is required. Includes code generated by Claude Code

router-advert: T9084: allow name-server-lifetime 0 in CLI validator

2026-07-14T19:26:37+00:00

valueHelp already documented 0 ("Name-servers should no longer be used") and conf-mode only enforces MaxRtrAdvInterval when lifetime > 0, but the XML constraint only allowed 1-7200. Match the default-lifetime pattern (--range 0-0 --range ...) and smoke-test AdvRDNSSLifetime 0.