| Age | Commit message (Collapse) | Author |
|
vpp: T9018: Auto-enable promiscuous mode for interfaces with VLANs
|
|
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.
|
|
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.
|
|
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
|
|
Authentication protocols are implemented as modules in accel-ppp-ng.
The CLI setting configures which modules need to be loaded, for this
change to take effect pppoe server must be restarted.
|
|
https: T9022: serve the full CA certificate chain
|
|
Reaches a clean typos baseline for the T8490 ruleset pilot. Categories:
- Comments/docs: recursivly, taret, passsed, characted, arhive, AtrributeError;
"ned" -> "new" (migration comments).
- Messages/strings: writeable -> writable (x5); OCaml log "Commandis" -> "Command is".
- Local variables (all refs in-function): commited, formating, presistent;
inpt_range -> input_range; tz_datas -> tz_data_raw (avoids the tz_data collision).
- Self-contained renames (definition + all references in-file): formated_stats,
_get_formatted_output_conections -> ..._connections, expension_failure ->
expansion_failure (ping + traceroute), snmpd_restart_reqired -> ..._required.
False positives are allowlisted centrally (vyos/.github, separate PR), NOT changed
here: mke2fs, Maya-calendar "Mak", RFC 4122 "IDentifier" (hostapd), and VPP's
"U-Forwrd" bridge-domain column header (op_mode/vpp.py + the VPP smoketest assert
the real upstream `vppctl` output). Verified: typos clean, py_compile of every
edited .py, zero remaining old-identifier references.
🤖 Generated by [robots](https://vyos.io)
|
|
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
|
|
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.
|
|
|
|
concurrent rekey
The vti-up-down hook and vpn_ipsec.py modify a flat-file DB
(/tmp/ipsec_vti_interfaces) through three context managers that do an
unlocked read-modify-write. During a coordinated rekey, strongSwan fires
the hook for many VTIs concurrently, so the writers lost-update each
other: an interface whose up-client add is overwritten is left admin-down
while its CHILD_SA stays installed.
Serialise all DB access by reusing vyos.utils.locking.Lock. A new
_vti_updown_db_lock() context manager wraps the three public context
managers, and remove_vti_updown_db() holds the lock across both the DB
processing and the os.unlink() to close the create/delete race.
Make the helpers absence-safe under the lock so callers no longer compose
a separate existence check with a locked operation:
open_vti_updown_db_readonly() yields None when the DB does not exist and
remove_vti_updown_db() is a no-op when it is absent. Drop the
now-redundant unlocked vti_updown_db_exists() pre-checks in vti.py and
vpn_ipsec.py and handle the None yield.
|
|
haproxy: T8931: Improve WebSocket support for HAProxy
|
|
vpp: T8913: Skip bond teardown for non-structural config changes
|
|
pseudo-ethernet: T8540: Add anycast-gateway support for EVPN
|
|
qos: T7965: Fix qos fails to reapply on dynamic interfaces after reconnection
|
|
The previous vyos-netlinkd implementation for QoS policy re-apply was very heavy.
It conducted a full CLI validation and re-apply on every interface. Instead we
do not only re-apply the QoS configuration to the interface which has had an
address change detected by vyos-netlinkd.
This can be tested by checking "tc qdisc show" before disconnecting a PPPoE
interface and during/after reconnect. There will be no qdisc until the dynamic
interface has received an IP address - then the qdisc will be re-applied.
|
|
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
|
|
|
|
dhcp-server: T8524: Validate DDNS key-name references defined tsig-key
|
|
pki: T8994: add graceful error handling in case certbot fails
|
|
If ACME and certbot are used for PKI and e.g. haproxy it can become an issue if
certbot is blocked by the firewall. The renewal service will fail and tear-down
the production service - even if the certificate is yet not expired.
The production service was not restarted. This has been changed as every service
which is stopped prior to the renew is later restarted even upon failure of
renewing said certificate.
|
|
|
|
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.
|
|
|
|
|
|
vpp: T8930: Block vif driver to prevent unhandled traceback on XCP-NG
|
|
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>
|
|
When a key-name is set under dynamic-dns-update forward-domain or
reverse-domain, validate that the referenced TSIG key is defined under
dynamic-dns-update tsig-key. Previously the missing key was only caught
at runtime, causing kea-dhcp-ddns to fail to start with a fatal error.
Also fix a pre-existing bug in `verify_ddns_domain` (formerly
`verify_ddns_domain_servers`) where the function was called with the full
tagNode dict but iterated as if it received a single domain config,
causing the DNS server address check to never actually run.
|
|
removal
|
|
VPP bond teardown was triggered on every commit regardless of
what changed, dropping all subinterfaces and BGP sessions even
for trivial changes like descriptions or IP addresses.
Only mode, hash-policy and mac_address require full recreation
since VPP has no in-place update API for these; all other
changes are now applied incrementally.
|
|
|
|
The `vif` driver is fundamentally incompatible with VPP — no DPDK poll-mode
driver exists for Xen paravirtual interfaces and no PCI address is exposed,
so `allow-unsupported-nics` cannot rescue it either.
|
|
T8454: fix VRF-bind port availability check in service_https
|
|
python: T8857: replace bare except clauses with except Exception in config scripts
|
|
When service https is configured with a listen-address on a VRF
interface, adding or changing the vrf option causes the commit to
fail with "TCP port 443 is used by another service!" even though
no conflict exists.
Root cause: check_port_availability() performs a socket.bind() in
the default network namespace. When the listen-address belongs to
a VRF interface the address is unreachable from the default
namespace, so the bind fails with OSError which is misinterpreted
as "port in use". The secondary check via is_listen_port_bind_service()
also fails because psutil cannot see sockets bound inside a VRF.
Fix: add an optional vrf parameter to check_port_availability().
When set, the test socket is bound to the VRF master device via
SO_BINDTODEVICE before the bind() call, so that the address is
resolved in the correct L3 domain. This is done in-process (no
subprocess) and works for both IPv4 and IPv6.
service_https verify() now passes the configured VRF (if any) to
check_port_availability(). Non-VRF configurations are unaffected.
Add smoke test for HTTPS with listen-address inside a VRF.
Co-authored-by: Christian Breunig <christian@breunig.cc>
|
|
snmp: T8538: Persist engineBoots counter across reboots
|
|
When setting 'vpn ipsec logging log-level 0', DPD informational
messages (log level 1) were still appearing in the system journal.
The root cause is that charon-systemd reads both `charon-systemd.conf`
and `charon-logging.conf` and applies the higher of the two log levels
to the journal. The VyOS only managed `charon-systemd.conf`, leaving
`charon-logging.conf` at its default level of 1, which silently overrode
the user-configured level.
Fix this by rendering `charon-logging.conf` on every commit with
syslog backend set to -1 (silent), making `charon-systemd.conf`
the sole authoritative source for journal log verbosity.
This also eliminates duplicate log entries in the journal that occurred
when both backends were active and writing to the same destination.
|