| Age | Commit message (Collapse) | Author |
|
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
|
|
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.
|
|
|
|
|
|
dhcp-server: T8524: Validate DDNS key-name references defined tsig-key
|
|
firewall: T8546: Fix conntrack_required for global state-policy
|
|
Add refresh-on-ttl-perc, nothing-below-nxdomain, and minimum-ttl-override
under service dns forwarding with recursor template and smoketest coverage.
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Daniil Baturin <daniil@baturin.org>
|
|
|
|
bgp: T8223: Prevent `advertise-all-vni` in multiple BGP VRF instances simultaneously
|
|
|
|
T8923: normalize "can not" to "cannot" and other typo fixes
|
|
Replace two-word "can not" / "Can not" with "cannot" across comments,
ConfigError messages, CLI help text, and op-mode output.
Standard SNMP MIB files under mibs/ are left unchanged.
|
|
|
|
|
|
As salt has been marked deprecated via T8056 and is thus deprecated in VyOS 1.5
and VyOS 1.4 it is time to remove it from the rolling release.
|
|
simultaneously
FRR only allows one BGP instance to hold `advertise-all-vni` at a time
(FRR issue #9405). When a default BGP instance is present it is always
started before named VRF instances, so if a named VRF holds
the flag FRR silently rejects it on every boot (regardless of default
EVPN config), causing the running config to diverge from what is
stored in VyOS.
Enforce the following policy in verify():
- Default BGP instance may always hold `advertise-all-vni`.
- A named VRF may hold it only when no default BGP instance exists.
- Only one BGP instance (default or named VRF) may hold it at a time.
The default BGP verify path additionally scans dependent VRFs so that
adding or modifying the default BGP instance while a named VRF already
holds the flag is caught even when the VRF node is not part of the
current commit.
|
|
Signed-off-by: Miaosen Wang <secretandanon@gmail.com>
|
|
vrf: T8936: Specify `pref 1998` when deleting fwmark routing rules on VRF removal
|