| Age | Commit message (Collapse) | Author |
|---|
|
It makes no sense to have a parser for the ethtool values in ethtool.py
and ethernet.py - one instance ios more then enough!
|
|
Only update the RX/TX ring-buffer settings if they are different from the ones
currently programmed to the hardware. There is no need to write the same value
to the hardware again - this could cause traffic disruption on some NICs.
|
|
Not all interface drivers have the ability to change the speed and duplex
settings. Known drivers with this limitation are vmxnet3, virtio_net and
xen_netfront. If this driver is detected, an error will be presented to the
user.
|
|
Ethernet adapters have a discrete set of available speed and duplex settings.
Instead of passing every value down to ethtool and let it decide, we can do
this early in the VyOS verify() function for ethernet interfaces.
|
|
|
|
Check a port availability only if it was changed in current commit.
This should protect from fail-positive errors when other parameters
change for an interface.
|
|
The commit fixes the problem, when port availability check is
triggered even if a port for WireGuard interface is not defined
(randomized port, default behavior).
|
|
|
|
Add new CLI command:
* "set protocols ospf redistribute table <n>"
|
|
Mandatory FRR options for spf-delay-ietf did not get rendered in the Jinja2
template.
|
|
wireguard: T3763: Added check for listening port availability
|
|
`print` was removed or replaced to `ValueError`, where possible.
|
|
Extended CLI command: "set vpn ipsec remote-access connection rw pool" with a
"radius" option.
|
|
Each wireguard interface requires a unique port for in and out
connections. This commit adds the new `vyos.util` function -
`check_port_availability`, and uses it to be sure that a port
that is planned to be used for wireguard interface is truly
available and not used by any other services (not only other
wireguard interfaces).
|
|
|
|
After commit 209ce3d9 ("container: T3769: when container networks are used,
always bridge the networks") IP masquerading (NAT) was disabled. No need to
keep the haipin flag.
|
|
As VyOS is a network operation system with bridging and NATing available from
the VyOS CLI, it makes no sense to let podman do it's own sort of "NAT".
If one really want's to NAT into a container, use the VyOS CLI to do so. If you
wan't to bridge your networks, use the VyOS CLI to do so.
|
|
|
|
Volumes must have both a source and destination path specified. Also the
source path must exist on the current system.
|
|
A call to .items() was missing that triggered the following error:
ValueError: too many values to unpack (expected 2)
|
|
As VyOS CLI is the only truth for dealing with containers we do not need to
query if a container is running, exists or what so ever. We simply always
restart it if something changes and do not rely on the underlaying Linux
status.
If a users does container stuff under the hood - it will be overridden.
|
|
|
|
A container is limited to 256MB memory by default and will always restart on
failure.
|
|
|
|
A environment variable MUST always have a value specified. Non existing
values will cause the following error:
Traceback (most recent call last):
File "/usr/libexec/vyos/conf_mode/containers.py", line 269, in <module>
apply(c)
File "/usr/libexec/vyos/conf_mode/containers.py", line 224, in apply
env_opt += " -e ".join(f"{k}={v['value']}" for k, v in container_config['environment'].items())
File "/usr/libexec/vyos/conf_mode/containers.py", line 224, in <genexpr>
env_opt += " -e ".join(f"{k}={v['value']}" for k, v in container_config['environment'].items())
KeyError: 'value'
|
|
Now that MSS clamping is done on the "per-interface" level the entire PPPoE
stuff would have needed to get a full copy in GNU BASH for this or, participate
in the common library.
Add a new PPP ip-up script named 99-vyos-pppoe-callback which will call the
vyos.ifconfig.PPPoEIf.update() function to configure everything as done with
all other interfaces. This removes duplicated code for VRF assignment and route
installation when a PPPoE interface is brought up or down.
|
|
WWAN does no londer need to render any configuration files.
|
|
level
Getting rid of "set firewall options" and move it from:
set firewall options interface ethX adjust-mss 1400
set firewall options interface ethX adjust-mss6 1400
to:
set interfaces ethernet ethX ip adjust-mss 1400
set interfaces ethernet ethX ipv6 adjust-mss 1400
In addition add an extra option called clamp-mss-to-pmtu instead of a value.
|
|
This adds the following new commands:
set protocols bgp address-family ipv4-unicast route-map vpn export foo-map-out
set protocols bgp address-family ipv4-unicast route-map vpn import foo-map-in
set protocols bgp address-family ipv6-unicast route-map vpn export foo-map-out
set protocols bgp address-family ipv6-unicast route-map vpn import foo-map-in
|
|
|
|
|
|
|
|
|
|
convention
|
|
|
|
|
|
We only delete iptables rules if they really exist - if we try to delete a non-
existing rule a PermissionError exception is thrown.
We could either ignore the error code (that is what the old Vyatta code did),
or we check what we are doing beforehand.
|
|
|
|
Commit 6f87d8c9 ("ospf: T3757: support to configure area at an interface level")
did not allow the old way an area and netwokr was set-up as the if
expression was missing a check if 'area' was set in both the interface and the
ospf process.
|
|
|
|
FRR supports configuring either network prefixes per area, or assign an
interface to an area to participate in the routing process. This is already well
known from other venders and supported by FRR.
A valid VyOS OSPF configuration would then look like:
vyos@vyos# show protocols
ospf {
interface dum0 {
area 0
}
interface eth0.201 {
area 0
authentication {
md5 {
key-id 10 {
md5-key vyos
}
}
}
dead-interval 40
hello-interval 10
priority 1
retransmit-interval 5
transmit-delay 1
}
log-adjacency-changes {
detail
}
parameters {
abr-type cisco
router-id 172.18.254.201
}
passive-interface default
passive-interface-exclude eth0.201
}
|
|
pbr: T3702: Add rules match fwmark
|
|
default behavior
|
|
|
|
When removing bgp (vrf) instances the assigned VRF vni must be deleted from FRR
prior the removal of the bgp settings (T3734).
This is now done by moving the CLI command "set vrf name red vni 1000" to a
dedicated Python script with a priority higher then bgp.
|
|
|
|
isis: T3708: Fix errors in MTU calculation
|
|
|
|
|
|
|
