| Age | Commit message (Collapse) | Author |
|---|
|
Deprecated in the Linux Kernel by commit 08a00fea6de277df12ccfadc21 ("net:
Remove references to NETIF_F_UFO from ethtool.").
(cherry picked from commit f5e46ee6cc2b6c1c1869e26beca4ccd5bf52b62f)
|
|
An analysis of the code base from VyOS 1.2 -> 1.3 -> 1.4 revealed the following
"root-cause"
VyOS 1.2 uses the "old" node.def file format for:
* Generic Segmentation Offloading
* Generic Receive Offloading
So if any of the above settings is available on the configuration CLI, the
node.def file will be executed - this is how it works.
By default, this CLI option is not enabled in VyOS 1.2 - but the Linux Kernel
enables offloading "under the hood" by default for GRO, GSO... which will boost
the performance for users magically.
With the rewrite in VyOS 1.3 of all the interface related code T1579, and
especially T1637 this was moved to a new approach. There is now only one handler
script which is called whenever a user changes something under the interfaces
ethernet tree. The Full CLI configuration is assembled by get_interface_dict() -
a wrapper for get_config_dict() which abstracts and works for all of our
interface types - single source design.
The problem now comes into play when the gathered configuration is actually
written to the hardware, as there is no GSO, GRO or foo-offloading setting
defined - we behave as instructed and disable the offloading.
So the real bug originates from VyOS 1.2 and the old Vyatta codebase, but the
recent XML Python rewrites brought that one up to light.
Solution:
A configuration migration script will be provided starting with VyOS 1.3 which
will read in the CLI configuration of the ethernet interfaces and if not
enabled, will query the adapter if offloading is supported at all, and if so,
will enable the CLI nodes.
One might say that this will "blow" the CLI configuration but it only represents
the truth - which was masked in VyOS 1.2.
(cherry picked from commit a515212f4efb08846df04405f31a828edcd63552)
|
|
VyOS 1.4 already had a migrator for interfaces 20 -> 21, but this is a different
one compared to the one in VyOS 1.3 - thus we bump every migration scripts
version by one to have the same 20-to-21 converter in both VyOS 1.3 and 1.4.
This is possible as VyOS 1.4 (sagitta) is still a highly experimental version
and expected to break from time to time :(.
|
|
option
Commit 31169fa8 ("vyos.ifconfig: T3619: only set offloading options if
supported by NIC") added a warning for the user if an offload option was about
to change that was not possible at all (harware limit).
Unfortunately the warning was even displayed if nothing was done at all. This
got corrected.
|
|
|
|
|
|
interface: T3782: Fix unexpected delete qdisc rule
|
|
Some tc qdisc rules are generated by old perl code
It prevent to unexpected override this code by python.
|
|
Add a new method which supports checking if the desired speed and duplex
setting is actually supported by the underlaying network interface card.
>>> from vyos.ethtool import Ethtool
>>> tmp = Ethtool('eth0')
>>> tmp.check_speed_duplex('100', 'full')
False
>>> tmp.check_speed_duplex('1000', 'full')
True
|
|
|
|
Commit d22f97af ("vyos.ethtool: T3163: rename unused methods for offload
validation") reworked the entire class on how data should be presented to the
user, but forgot to drop the is_fixed_lro() method.
|
|
Check eui64_old value before deleting
It can be empty or not ipv6 address.
(cherry picked from commit 0de23064b9d575ce0569839e3b4453a0c2e9dc1c)
|
|
wireguard: T3763: Fixed uninitialized port issue
|
|
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.
|
|
In the past we always told ethtool to change the offloading settings, even if
this was not supported by the underlaying driver.
This commit will only change the offloading options if they differ from the
current state of the NIC and only if it's supported by the NIC. If the NIC does
not support setting the offloading options, a message will be displayed
for the user:
vyos@vyos# set interfaces ethernet eth2 offload gro
vyos@vyos# commit
[ interfaces ethernet eth2 ]
Adapter does not support changing large-receive-offload settings!
|
|
|
|
wireguard: T3763: Added check for listening port availability
|
|
We need to copy the configuration before this is done in super().update() as we
utilize self.set_dhcpv6() before this is done by the base class.
|
|
|
|
`print` was removed or replaced to `ValueError`, where possible.
|
|
bgp: evpn: T3739: add route-map match support
|
|
Extended CLI command: "set vpn ipsec remote-access connection rw pool" with a
"radius" option.
|
|
(cherry picked from commit b4b2c91127289c7b62afb24304054d57357a48c5)
|
|
The current command to restart any of the FRR processes is:
vyos@vyos:~$ restart frr
Possible completions:
<Enter> Execute the current command
bfdd Restart Bidirectional Forwarding Detection daemon
bgpd Restart Border Gateway Protocol daemon
ospf6d Restart OSPFv3 daemon
ospfd Restart OSPFv2 daemon
ripd Restart Routing Information Protocol daemon
ripngd Restart RIPng daemon
staticd Restart Static Route daemon
zebra Restart IP routing manager daemon
From a real-life example: Two engineers needed 5 minutes to figure it is under
"restart frr" - that is why this commit drops the artificial "frr" level on the
op-mode commands to restart routing protocol daemons.
It's less intuitive to have "restart frr ospfd" or "restart frr bgpd" compared
to "restart ospf" and "restart bgp" - we have the same for "restart ssh" or
"restart snmp" and not "restart openssh sshd".
This commit also drops the d (daemon) suffix of the op-mode comamands so the
commands align with the VyOS CLI, else there would be a miss-understanding from
ospf6d to ospfv3.
(cherry picked from commit 8ad8b0d51bf21c583e6d687576cb1a61195e7215)
|
|
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).
|
|
ipsec: T3780: shutting down vti when tunnel is down
|
|
|
|
|
|
T3773: delete the original "show system integrity" command
|
|
... there was a type setting ecp512 instead of ecp521.
|
|
When the interface name was stripped down from "eth0.201" to "eth" to determine
the appropriate interface section, VRRP interfaces got left out on the call
to rstrip().
VRRP interfaces now show up in "show interfaces" as they did in VyOS 1.2.
vyos@vyos:~$ show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
dum0 172.18.254.201/32 u/u
eth0 - u/u
eth0.10 172.16.33.8/24 u/u
eth0.201 172.18.201.10/24 u/u
eth1 10.1.1.2/24 u/u
eth1v10 10.1.1.1/24 u/u
eth2 - u/u
lo 127.0.0.1/8 u/u
::1/128
|
|
|
|
|
|
Commit 474db49a ("bgp: T3759: "l2vpn evpn" and ipv4/ipv6 safi route-targets
differ") made it possible to specify a whitelist separated list of route-targets,
this is now validated through the smoketests.
|
|
The "l2vpn evpn" address-family route-target command only accepts a single
route-target value consisting of (A.B.C.D:MN|EF:OPQR|GHJK:MN). The
"ipv4-unicast or ipv6-unicast" address-family route-target command for VPNs
support multiple, whitespace separated route-target values.
This commit adds a new custom validator named "bgp-route-target" with a --single
and a --multi option to pass one or more route-target values.
|
|
|
|
... as we will get another bgp route-target validator soon.
|
|
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.
|
|
Commit a30d74f4 (container: op-mode: T3765: add "connect container mysql-server")
added a CLI op-mode command to attach to a container - users typically not want
to attach and consume stdout (can be done via logs) but rather wan't to debug
inside the container image.
vyos@vyos:~$ connect container unifi
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 202 0.0 0.0 4640 828 pts/1 Ss 21:06 0:00 /bin/sh
root 203 0.0 0.0 34416 2872 pts/1 R+ 21:06 0:00 \_ ps faux
root 187 0.0 0.0 18388 3124 ? S 21:03 0:00 /bin/bash
root 186 0.0 0.0 4640 788 ? S 21:03 0:00 /bin/sh
root 185 0.0 0.0 4640 824 ? S 21:03 0:00 /bin/sh
root 184 0.0 0.0 4640 836 ? S 21:03 0:00 /bin/sh
root 1 0.0 0.0 18520 3228 pts/0 Ss+ 20:50 0:00 bash /usr/local/bin/docker-entrypoint.sh unifi
root 12 4.8 14.2 3688080 572756 pts/0 Sl+ 20:50 0:48 java -Dunifi.datadir=/unifi/data -Dunifi.logdir=/unifi/log -Dunifi.rundir=/var/run/unifi -
root 35 0.7 3.4 1102700 139752 pts/0 Sl+ 20:50 0:07 \_ bin/mongod --dbpath /usr/lib/unifi/data/db --port 27117 --unixSocketPrefix /usr/lib/un
Linux 57c689f739ed 5.10.60-amd64-vyos #1 SMP Fri Aug 20 14:44:59 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
|
|
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.
|
|
redistributed routes
|
|
|
|
|
|
Volumes must have both a source and destination path specified. Also the
source path must exist on the current system.
|
