| Age | Commit message (Collapse) | Author |
|---|
|
nhrp: T9128: fix duplicate nftables meter name for multiple redirect tunnels
|
|
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.
|
|
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 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 <christian@breunig.cc>
|
|
vpp: T8367: Fix identical default MAC on bridged loopback interfaces
|
|
firewall: T9076: add per-remote-group update interval
|
|
T9073: frr-exporter: add CLI support for optional collectors and collector options
|
|
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.
|
|
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.
|
|
T8529: Add configuration CLI to enable OpenSSL FIPS
|
|
router-advert: T9084: allow name-server-lifetime 0 in CLI validator
|
|
options
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 <json|plain-text>
- collector bgp peer-group
- collector bgp peer-hostname
- collector bgp peer-type
- collector ospf-instance <id>
- 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
|
|
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.
|
|
Add 'set firewall group remote-group <name> interval <value>' 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 <noreply@anthropic.com>
|
|
vpp: T9018: Auto-enable promiscuous mode for interfaces with VLANs
|
|
vpp: T9062: Enable DHCP/DHCPv6 client detection on VLAN sub-interfaces
|
|
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.
|
|
smoketest: T9048: harden DHCP client process checks against CI timing races
|
|
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.
|
|
deleted
Deleting "protocols static" set config_dict['static'] to a dict object shared
by reference across every deleted protocol. Merging the PPPoE/DHCP default-route
data into it left the "deleted" marker in place, so the entire staticd section -
including the just-merged default route - was skipped during FRR rendering,
dropping the default route from the RIB/FIB.
Copy the shared deleted-protocol marker before mutating it, and clear the marker
once DHCP/PPPoE content has been merged in so the section is still rendered.
|
|
Adversarial review findings on the previous head:
* get_process_cmdline() could re-resolve a NEW PID after the
'ip vrf pids' membership assertion had already run against the old
one, so the two assertions could validate different processes. The
helper now returns the (pid, cmdline) pair it actually validated and
the VRF checks moved after it, targeting the returned PID.
* The one-shot retry left a residual double-race window. The helper
now polls PID discovery and the /proc read together under the same
PROCESS_WAIT_TIMEOUT deadline.
🤖 Generated by [robots](https://vyos.io)
|
|
The re-resolve path read /proc/<pid>/cmdline without defaultonfailure,
so a repeated PID race raised an unhandled exception (test ERROR)
instead of failing with a clear assertion message.
🤖 Generated by [robots](https://vyos.io)
|
|
Interface smoketests fail intermittently in CI on DHCP-related
assertions (test_interfaces_cli job pass rate 42-55% over the last 30
workflow runs). Three timing hazards in the interface test base class:
* process_named_running() was polled with a 10 second window at all
dhclient/dhcp6c call sites - too short on a loaded runner. Raise to a
shared PROCESS_WAIT_TIMEOUT of 60 seconds; the poll returns as soon
as the process appears, so this only delays the failure path.
* /proc/<pid>/cmdline was read unguarded after PID discovery. dhclient
re-executes itself while daemonizing, so the discovered PID can be
gone by the time /proc is read - read_file() then raises and the test
errors out instead of failing cleanly. New get_process_cmdline()
helper re-resolves the PID once when the read fails.
* tearDown() asserted daemon absence immediately after the config was
removed, reporting daemons still in their shutdown path as leaks.
Use the existing wait_for_result() shim helper with the same 60s
bound to grant a grace period before declaring a leak; the poll
returns on first observation of a clean state, so passing runs pay
no extra wall clock.
🤖 Generated by [robots](https://vyos.io)
|
|
T9002: grant CAP_NET_RAW to blackbox-exporter when ICMP modules are configured
|
|
Add the new configuration CLI to enable OpenSSL FIPS-140
(Federal Information Processing Standard) cryptographic modules
|
|
The blackbox-exporter runs as node_exporter user which cannot create
ICMP sockets due to restricted ping_group_range. Add CAP_NET_RAW
capability to the systemd service when ICMP modules are configured.
In non-VRF mode, use systemd AmbientCapabilities/CapabilityBoundingSet.
In VRF mode, replace runuser with setpriv to preserve the capability
across the UID change.
|
|
This change re-implements the intended behaviour from T4180 aswell as from
T4506, it ensures that both the vrf-member interface aswell as the vrf itself
is added as an oifname -> meaning that traffic traversing and originating from
withing VyOS is matches outbound.
Changes done by c-po:
* re-sort dependency list to keep diff low
* vyos.configdict.is_vrf_changed() should return early and not carry
over the to-be return value
* keep common coding style (dict by . separation) in nftables-zone.j2
Co-authored-by: Christian Breunig <christian@breunig.cc>
|
|
T8963: policy-route: trigger domain resolver for domain groups
|
|
https: T9022: serve the full CA certificate chain
|
|
Add input-queue-limit and output-queue-limit CLI nodes to expose global FRR
"bgp input-queue-limit" and "bgp output-queue-limit" commands via our CLI.
Parameters control the maximum number of queued messages for all BGP peers
during message parsing. FRR default is 10000 which we honor.
Note that this is a global option and can only be set for the global/default
BGP instance.
|
|
When a certificate is assigned to the HTTPS service, nginx was only
sent the leaf certificate. An intermediate CA was included only when
an operator manually configured "ca-certificate", and even then just
that single CA - the rest of the issuer chain was never followed.
As a result, clients that do not already trust the issuing intermediate
CA (for example Let's Encrypt's newer E- and R-series intermediates)
could not build a path to a trusted root and rejected the connection.
Build the complete chain from the CA certificates present in the PKI
using find_chain(), the same helper already used by HAProxy, OpenConnect,
stunnel and the other PKI consumers. The intermediate chain is now
discovered automatically, so configuring "ca-certificate" is no longer
required; it remains accepted for backwards compatibility.
|
|
`advertise-all-vni` is globally active
When `advertise-all-vni` is configured in the global/default BGP instance,
VyOS generated a `vni <id>` sub-block under each VRF BGP `address-family
l2vpn evpn` context. This conflicts with advertise-all-vni: FRR already
owns all kernel VNIs and returns `% Failed to create VNI` when frr-reload.py
attempts to apply the VRF-level vni sub-block. FRR then performs an early
exit from config processing, silently dropping the entire l2vpn evpn
address-family for all subsequent VRF BGP instances.
|
|
T9011: enable proxy_ndp sysctl for static IPv6 neighbor proxy
|
|
bgp: T5526: Fix BGP neighbor validation not raising when interface does not exist
|
|
T8097: strongswan: add CLI for ESN
|
|
|
|
geoip: T5746: Add GeoIP ASN support
|
|
exist
Validation of interface-based BGP neighbors relied on checking physical
interface existence, which silently skipped the check when interface didn't
exist yet, letting invalid config reach FRR. Fix by checking whether the
neighbor is not an IP address instead, and improve the error messages to
show the correct command.
|
|
|
|
openvpn: T8998: fix ccd-exclusive without client-config-dir
|
|
haproxy: T8931: Improve WebSocket support for HAProxy
|
|
T8990: bgp: fix VPNv4/VPNv6 leaked routes flapping on every commit
|
|
Introduce 'anycast-gateway' leafNode for pseudo-ethernet interfaces.
When set, a local FDB entry is installed on the parent bridge to
prevent the shared anycast MAC from leaking over the VXLAN overlay.
|
|
vpp: T8603: Expand ACL support to logical interfaces
|
|
|
|
VRF route leaking via VPNv4/VPNv6 caused all imported (leaked) routes to
be withdrawn and reinstalled on every commit - even commits unrelated to
BGP, VRF or routing - briefly blackholing traffic that depends on them.
Root cause: the BGP address-family template rendered the route-target
using the "route-target vpn ..." alias. FRR accepts that alias on input
but its config writer only ever emits the canonical "rt vpn ..." form.
frr-reload.py diffs the generated config against FRR's running config
line by line and has no normalisation for this, so the route-target lines
never matched and were deleted and re-added on every reload. Re-applying
the route-target runs FRR's vpn_leak_prechange()/postchange(), a
non-atomic withdraw-all then reinstall-all of every leaked route.
Emit the canonical "rt vpn" keyword so the rendered config round-trips
through frr-reload unchanged. FRR also folds an identical import+export
route-target into "both" (an order-sensitive, byte-identical match), so
do the same to stay idempotent; reordered or differing lists stay split
on both sides.
Add test_bgp_33_vpn_route_target_idempotency covering both / identical
export+import / asymmetric route-target, reading the generated FRR config
(getFRRconfig/vtysh returns FRR's already-canonical form and cannot catch
the alias).
|
|
By default now for each proposal two proposals are sent: with `-noesn`
and without. Update test accordingly.
|
|
Emit `client-config-dir` when `reject-unconfigured-clients` is set,
even without server client entries, so OpenVPN does not crash-loop.
|
|
|
|
|
