| Age | Commit message (Collapse) | Author |
|---|
|
pki: T9135: derive ACME certificate chains from disk
|
|
firewall: T8221: Add last-used option to firewall rules
|
|
qos: T9134: Fix commit crash when classes match different protocols
|
|
The PKI testsuite's setUpClass() already clears out pki and service https so
it can run on a live system, but left an existing load-balancing haproxy
configuration in place, which could reference certificates the tests then
delete out from under it.
|
|
container: T7736: fix smoketest failures caused by netavark/aardvark-dns IPv6 DAD race
|
|
flow-accounting: T9122: bind NetFlow export to the configured VRF
|
|
On a live system, prevent that the smoketest default route overwrites
any other dynamically learned route by defining a higher distance.
|
|
VyOSUnitTestSHIM.tearDownClass() restores the pre-test configuration from
/tmp/vyos-smoketest-save but never removed the file afterwards. Since it
is a fixed, shared path, whichever user ran a smoketest last ends up
owning it with no group/other write permission - the next user to run
any smoketest on the same box gets a hard "Permission denied" writing to
that path, even though nothing else is actually wrong.
|
|
netavark assigns the IPv6 gateway address to a container "pod-*" bridge
and immediately invokes aardvark-dns to bind its DNS listener to it. While
the address is "tentative" during Duplicate Address Detection, that bind()
fails with EADDRNOTAVAIL and container startup fails for any IPv6-enabled
network.
The kernel only skips DAD for an address if both "all" and the specific
interface's own accept_dad are disabled at the moment the interface is
created. A per-interface override is always either too late for a network's
first-ever container - as the network can only be created in-time and not
explicitly before starting the first container.
|
|
qos: T8996: Implement set-dscp packet remarking for shaper policy
|
|
sflow: T9065: Always set psample group even when egress sampling is disabled
|
|
Podman's default "vethN" auto-naming for a container's host-side veth can
collide with VyOS's own "virtual-ethernet vethN" interfaces.
Bump the minimum Podman dependency to 5.8 (which supports "host_interface_name"
network connect option) and use it to name every non-macvlan container network
attachment "veth-<container name>" instead, eliminating the collision by
construction. Container names too long to fit are shortened to a recognizable
prefix plus a short hash of the full name; verify() rejects the rare case
where two containers still generate the same interface name.
Add "show container interface" to display the resulting name-to-container
mapping.
|
|
nhrp: T9128: fix duplicate nftables meter name for multiple redirect tunnels
|
|
Every class match is installed as its own tc filter, and tc binds a
filter priority ("prio"/"pref") to a single protocol. Two filters with
the same priority but different protocols are rejected by the kernel, so
the commit crashes - e.g. one class matching "ether protocol arp" and
another matching IP. The filter priority came from the class id, the
class "priority" (which the limiter defaults to 20 for every class),
or the per-class match index - none of which is unique across classes.
Assign every match a unique tc filter priority by ranking the matches in
evaluation order (class id, an explicit or default class "priority", or
the per-class match index) and numbering them 1, 2, 3, ... This keeps the
match evaluation order unchanged across all class-based policies (shaper,
shaper-hfsc, limiter, round-robin, priority-queue). The class "priority"
still drives the HTB class scheduling priority on the shaper; the tc
filter priority is an internal evaluation-order rank, not the CLI
"priority" value.
Add smoketests for mixed-protocol classes (shaper and limiter) and for
match evaluation order.
|
|
- Add last-used option to firewall rules
- Updated output of show firewall to include last-used
- Added smoketest for last-used option
|
|
I had initially treated the VRF as just another interface that could be
used as a source-interface, but after a bit more research none of the
major vendors treat VRFs as interfaces - Cisco and Juniper both source a
flow exporter from a routed interface and never from a VRF - and I don't
think we should either.
Reject a source-interface that names a VRF device with a clear message
instead of the misleading "is not a member of VRF" error, and cover the
rejection in the smoketest. VRF export continues to be selected through
the "system flow-accounting vrf" node.
|
|
After the migration from pmacct to the ipt_NETFLOW kernel module the
"system flow-accounting vrf" node no longer had any effect on the export
path. NetFlow is emitted by the kernel module, so there is no daemon left
to wrap in "ip vrf exec" and the module socket was never bound to the VRF.
A collector reachable only inside a VRF therefore never received any flows
when the export was configured with a source-address.
Bind the export socket to a device via the ipt_NETFLOW "%device"
destination suffix: a per-server source-interface takes precedence,
otherwise the global VRF device is used, reproducing the previous
"ip vrf exec" behaviour. The module parses "@source-address" before
"%device", so the source-address is now rendered first - the previous
template emitted them in the opposite order, which only worked because the
two options are mutually exclusive per server.
Reject a source-interface that is used together with a VRF but is not a
member of that VRF: the exported flows would otherwise silently leave via
a different routing table. This mirrors the existing OSPF, OSPFv3, IS-IS
and BGP checks.
|
|
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.
|
|
The set-dscp option was defined in XML but never implemented in
Python — no tc commands were generated to rewrite DSCP on egress.
Add tc pedit actions to shaper filter commands. The pedit target
is chosen per-match: IPv4 uses "ip dsfield", IPv6 uses
"ip6 traffic_class". Ether matches with protocol ip or ipv6 also
get the corresponding pedit; other non-IP match types skip pedit
to avoid corrupting packets like ARP. The retain 0xfc mask
preserves ECN bits. For IPv4, a csum ip4h action recalculates
the header checksum after pedit. For the default class, separate
catch-all filters (prio 255/256) are added per protocol.
|
|
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.
|
