| Age | Commit message (Collapse) | Author |
|---|
|
T7731: Static ARP entries are missing after an interface status change
|
|
When deleting the 'protocols' node under a VRF, a `KeyError` was raised in
`frrender.py` because the 'protocols' dictionary key was missing when
attempting to update protocol states. This prevented configuration
commits from completing successfully.
|
|
|
|
Commit fb9f2f3e950 ("pppoe: T7485: allow explicit request for CPE IPv6 address
via IA_NA") introduced the CLI node definition for address dhcpv6, which at the
time had only a single available option. Because of that, the node wasn't
defined as <multi/> in the XML schema.
However, the generic interface code expects address to be a <multi/> XML node,
which is translated into a list in Python. This mismatch caused an error
referencing the letter d, corresponding to the first character of dhcpv6.
|
|
Commit 9775bb49e ("frr: T7664: drop BASH/SED implementation in smoketest
getFRRconfig()") dropped a custom BASH/SED based implementation of how we
interacted with FRR to make use of the utility helpers from FRR team.
This changed added some arbitray warnings when executing about unclosed
files handles. ResourceWarning: unclosed file <_io.BufferedReader name=5>
Instead of importing the frr-reload Python module, we simply call popen() by
ourself.
|
|
Commit 9775bb49e ("frr: T7664: drop BASH/SED implementation in smoketest
getFRRconfig()") changed how we searched strings using a regex. In the
past we searched at the beginning of a line ^ till the end $. THis logic
was dropped in commit 9775bb49e marking some tests failing as they matched,
when they should not match.
Example: getFRRconfig('vrf red') showed output for both VRF red and red15 as
both started with "red". This has been fixed.
|
|
The original VRF DHCP test case, introduced in commit 186900f7165b2
("smoketest: T7927: test DHCP route preservation"), used a fixed delay of
8 seconds to wait for the DHCP server and client to initialize. This approach
was unreliable and could cause unnecessary test delays.
Since commit 354517677f ("wlb: T7977: Updated smoketest to validate nft vmap
weight buckets"), the "vyos.utils.misc.wait_for()" helper provides a more
efficient busy-wait loop with an early-exit condition. This test case now uses
wait_for() to detect when the DHCP-assigned default route becomes available,
eliminating the fixed sleep and reducing test runtime.
|
|
Commit 186900f7165b2 ("smoketest: T7927: test DHCP route preservation") which
was added to validate a bugfix for DHCP default routes added it's own
little regression. Tests defined a VRF named red15, but when reading in the FRR
configuration we have had a hardcoded search for "vrf red" instead.
This has been fixed to re-use the defined VRF variable name we perform our test
on.
|
|
|
|
wlb: T7977: Fix weight calculation for multiple interfaces
|
|
firewall: T7112: Default action drop fails
|
|
veth: T7990: fix stale DHCP clients when removing virtual Ethernet pairs
|
|
Prevent `KeyError` by safely handling missing 'member' dict in zone config.
Add smoketest to verify commit fails gracefully when zone has no interfaces.
|
|
|
|
container: T7305: fix VRF loss when restarting pods
|
|
T7849: ZBF allow to use wildcard interfaces as member
|
|
When removing a veth interface, the kernel automatically deletes its peer
interface, since veth devices always exist in pairs. However, this automatic
removal does not trigger the remove() helper in vyos.ifconfig.interfaces, which
can leave associated DHCP(v6) clients running indefinitely.
For example:
ip link add veth0 type veth peer name veth1
ip link del dev veth1
Removing veth1 will also delete veth0 in the kernel, but the VyOS cleanup
routines are never called for veth0. This patch ensures that peer removal
correctly purges both interfaces and their associated state.
This drops the workarounds in veth smoketest and falls back to the common
interface smoketests from the inherited base class.
|
|
Container networks are only started when there is at least one active consumer.
If a network is created without any attached containers, it does not need to be
assigned to a VRF yet.
When the last container in a pod is stopped, its associated container network
is removed. Upon container restart, the kernel recreates the network, but the
VRF assignment may be lost in the process.
This change ensures that all container networks are correctly reattached to
their designated VRFs when a pod restarts.
|
|
smoketests: T7971: Add docstrings to nftables verification helpers
|
|
- Fixed issue in T7977
- Added smoketest for 3 or more interfaces in rule
- Added wait_for function to utils/misc.py
|
|
Allow to use wildcard interfaces for zone-based firewall
It should allow interfaces like ipoe*/pppoe*/l2tp*
|
|
checks
- Renamed `permitted-peers` to `permitted-peer` across templates, schema, and tests.
- Added support for multiple `permitted-peer` entries and trimmed empty values.
- Replaced TLS/UDP warning with ConfigError for strict validation.
- Updated tests to use TCP for TLS and verified new validation logic.
|
|
T6686: adds container health checks
|
|
|
|
T7896: Add frr profile selection
|
|
|
|
Co-authored-by: Christian Breunig <christian@breunig.cc>
|
|
* dhcp-server: T3936: Added support for DHCP Option 82
This commit adds support in both the CLI and the underlying code for
DHCP Option 82 to be used to filter/route DHCP address assignments.
The primary use case for this is to support enterprise switches which
can "tag" DHCP requests with physical real world informaiton such as
which switch first saw the request and which port it originated from
(known in this context as remote-id and circuit-id). Once
client-classes have been defined they can be assigned to subnets or
ranges so that only certain addresses get assigned to specific
requests.
There is also a corresponding documentation update which pairs with
this code change.
(cherry picked from commit 326b5e713cb363a2b9f69e2204c4ee2ccd9939bb)
* Update src/conf_mode/service_dhcp-server.py
Co-authored-by: Nataliia S. <81954790+natali-rs1985@users.noreply.github.com>
* Update src/conf_mode/service_dhcp-server.py
Co-authored-by: Nataliia S. <81954790+natali-rs1985@users.noreply.github.com>
* Update interface-definitions/include/dhcp/dhcp-server-common-config.xml.i
Co-authored-by: Nataliia S. <81954790+natali-rs1985@users.noreply.github.com>
---------
Co-authored-by: Daniil Baturin <daniil@baturin.org>
Co-authored-by: Nataliia S. <81954790+natali-rs1985@users.noreply.github.com>
|
|
T7938: VPP: Rewrite sFlow implementation
|
|
haproxy: T7906: Probing of a port other than the one to which normal traffic is sent
|
|
is sent
Add support for specifying a custom health check port for HAProxy backend servers.
This allows health probes to target a dedicated endpoint - such as port 8080 - separate
from normal traffic ports (e.g., 80 or 443).
|
|
|
|
|
|
T3680: protocols: add dhclient hooks for dhcp-interface static routes
|
|
In large networks with many zones where simple allow/deny rules are not sufficient,
zones become tedious to manage. Many use cases can be simplified by providing an
ability to define a default ruleset for traffic from other zones. This change proposes
adding the follwing syntax:
set firewall zone <name> default_firewall name <name>
set firewall zone <name> default_firewall ipv6_name <name>
The proposed behavior is the following:
local in:
The default firewall ruleset for the local zone will be appended after all
from configurations.
local out:
If a non-local zone does not have a from local ruleset but does have a
default_firewall ruleset, the default_firewall ruleset will be appended using
oifname
forward:
The default firewall ruleset for the zone will be appended after all from
configurations
To keep the behavior consistent with from ruleset configurations, a return is appended
after the default_firewall ruleset.
The proposed behavior differs slightly from the default_policy configuration for the
local out chains. The default_policy applied in the out templates comes from the local
zone, not the actual outbound zone. The proposed change does not amend this, but does
make default_firewall logically consistent with the intent of the out rules.
|
|
Due to an issue in FRR where dynamic PPPoE interfaces sometimes receive an
ifIndex of 0 (which is invalid), disable the testcase and add a marker.
Test was just recently added in commit 75e9fd60c ("smoketest: T7858: add PPPoE
client tests with IPv4, IPv6 and DHCPv6-PD")
|
|
This extends commit 2c521f135 ("smoketest: T7858: make failfast main argument
dynamic").
|
|
Upgrades to FRR 10.4 have shown that there are cases where FRRs mgmtd will
SIGSEGV - to cover for this case and fail the smoketests we will monitor the
PID of the mgmtd process.
|
|
This extends commit 2c521f135 ("smoketest: T7858: make failfast main argument
dynamic").
|
|
|
|
While working on task T7664 (FRR 10.4 upgrade), I identified the need for
additional validation and safeguards around the FRR management daemon. The
most appropriate place for this logic is in the setUp() and tearDown() methods
of the smoketest base class, VyOSUnitTestSHIM.
However, during implementation, it became apparent that test cases do not
consistently invoke the base class's setup and teardown methods. This
inconsistency complicates the process of capturing the FRR mgmtd PID at the
start of a test and verifying that it remains unchanged by the end - a key step
in detecting crashes or unexpected terminations (e.g., SIGSEGV) of the FRR
management daemon during tests.
|
|
kea: T7925: Improve error handling, validate IPv6 PD prefix length
|
|
|
|
Execute commands for vpp sflow with API calls. Use values for polling interval and sampling rate from 'system sflow'. Add op-mode command
|
|
T5942: Make failover support dhcp-interface
|
|
frrender: T7927: de-nest DHCP and PPPoE interface section for VRFs
|
|
smoketest: T7657: check for Kernel option CONFIG_SLUB_DEBUG
|
|
This complements commit cf4666257 ("frrender: T7927: de-nest DHCP and PPPoE
interface section for VRFs") by validating the new DHCP behavior.
When a VRF bound interface obtains an IP via DHCP, the default route received
must be reflected in FRR's routing table (vtysh). Ensure the dynamic DHCP
learned route is retained even when unrelated sections of the FRR configuration
are modified.
|
|
|
|
|
