Age | Commit message (Collapse) | Author |
|
(cherry picked from commit 5c29377fa91595088118419275f6d05b1fbfbd1d)
|
|
Deprecated in the Linux Kernel by commit 08a00fea6de277df12ccfadc21 ("net:
Remove references to NETIF_F_UFO from ethtool.").
|
|
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.
|
|
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.
(cherry picked from commit ce784a9fcb7199f87949f17777b7b736227c85b3)
|
|
(cherry picked from commit 50364a4b7a9de85fe59a6a4fb611bafb64c9f7f0)
|
|
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
(cherry picked from commit 147f655a69cd9526cd23f51ab18027cb5abc95b2)
|
|
(cherry picked from commit 324aa9598c7d90efc917a00447380f985553b657)
|
|
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.
(cherry picked from commit eac8915413cedce089234fdbef57ad25da208eec)
|
|
(cherry picked from commit 80ee5233aa8245ded09d04f2618a580d5dcc6b46)
|
|
(cherry picked from commit 794f193d11c8c1b5fed78f4e40280480446ab593)
|
|
interfaces: T3777: Does not delete empty eui64 address
|
|
Check eui64_old value before deleting
It can be empty or not ipv6 address.
|
|
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!
(cherry picked from commit 31169fa8a763e36f6276632139da46b1aca3a7af)
|
|
(cherry picked from commit d22f97af23abb5c12f8ea79c50fdda7ee0a3832d)
|
|
|
|
Migrate back to old iptables NAT implementation as we can not use nft which
requires Kernel 5.10 for proper prefix translation support. Kernel 5.10
unfortunately breaks with Intel QAT :(
|
|
FRR: op-mode: T3776: rename "restart frr <daemon>" to "restart <daemon>"
|
|
This commit adds configurations usable for "make testc" that are known to be
good on VyOS 1.2 installations - thus they must work on 1.3.
|
|
(cherry picked from commit dbe406c8b0d174f7ef3f80d189521cddd6cca5ef)
|
|
|
|
As IS-IS is a new feature and the CLI configuration changed from 1.3 -> 1.4
(required by T3417) it makes sense to synchronize the CLI configuration for
both versions. This means backporting the CLI from 1.4 -> 1.3 to not confuse
the userbase already with a brand new feature.
As 1.3.0-epa1 is on the way and should not contain any CLI changes afterwards,
this is the perfect time.
|
|
Partial backport of commit 421fa38445a, this is required to backport the
complete IS-IS functionality from current.
|
|
(cherry picked from commit d9d923ea4e0bbe0cc154dc2fbdd626585b5d7449)
|
|
(cherry picked from commit 059307f924c604eb2bdeab19a2db8ce6d8e09f90)
|
|
|
|
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.
|
|
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
(cherry picked from commit df22bc2c96d5095eaec978a58bf5d2361d758a86)
|
|
Commit 99440fc0 ("Makefile: fix logic to detect empty "node.def" files")
disabled the detection of empty node.def files for op-mode commands. The
generation of a duplicate and thus empty node.def file is not prohibited
by commit 17b5ac14 ("T3165: op-mode: prevent override of populated node.def file
with empty content") and thus the check is re-enabled!
(cherry picked from commit e99cdf40c72dec8b9019eca728aaad0f82c6030b)
|
|
(cherry picked from commit 68567d60626aa7ee5f990af792eb63f6887d93de)
|
|
(cherry picked from commit d225f938b2250229621c7013c47ce52b839ae169)
|
|
That nasty workaround to always specify the same value for the node.def file
as the help text is no longer necessary after commit 17b5ac14 ("T3165: op-mode:
prevent override of populated node.def file with empty content".
The redundant definitions are no longer necessary.
(cherry picked from commit 536991d0c6f305256ce6ab5975d15116f027b7b6)
|
|
This is an extension to commit b4fdcebe ("T3165: prevent override of populated
node.def file with empty content") which implemented the same thing for the
configuration mode commands.
(cherry picked from commit 17b5ac143c9128ac3e187d8d8167dd8fe6cbca7d)
|
|
(cherry picked from commit 252bc820b0d130d8d81b5711586eca41287abdca)
|
|
|
|
(cherry picked from commit 8fc06b5f8bbfcc49e69406fd70cd5cd42fb6d39f)
|
|
(cherry picked from commit ddff5eba85feea2a8d6d24e1914ce6d51ce2ea74)
|
|
interfaces
(cherry picked from commit 081e0334c00887c373fafde761cca960667be21b)
|
|
(cherry picked from commit b121ee14ff1961b56568b0116de3c246ea4af934)
|
|
vyos@vyos# show interfaces pppoe
pppoe pppoe10 {
+ access-concentrator asdfg
authentication {
password bar
user foo
}
default-route force
no-peer-dns
source-interface eth0.202
}
vyos@vyos# python3
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from vyos.config import Config
>>> from vyos.configdict import get_interface_dict
>>> from vyos.configdict import leaf_node_changed
>>> conf = Config()
>>> base = ['interfaces', 'pppoe']
>>> tmp = get_interface_dict(conf, base, 'pppoe10')
>>> leaf_node_changed(conf, ['access-concentrator'])
>>> ['']
(cherry picked from commit f476e456e20393e7e7e91b73e369c9b033fbf048)
|
|
WireGuard, Tunnel and also PPPoE all need a ways to calculate a synthetic MAC
address used for the EUI64 link-local addresses. Instead of copying the code
from Tunnel to WireGuard to PPPoE, use a generic implementation.
(cherry picked from commit b7d30137b17da49ed5099d4d96659b363fc7bcc9)
|
|
(cherry picked from commit 8c1c9e1c37be9e88e8a7ea0182a43a3396eff623)
|
|
(cherry picked from commit 9c97bd1b0214e102ac36eae8b2c3c9ff672a0bf3)
|
|
(cherry picked from commit e1debb1b57a445fa2357f7dbb5b3f04383f8b1e3)
|
|
Both building blocks only differed in the help text, so use IP for both
IPv4 and IPv6.
(cherry picked from commit 0e751221d0832acac807e7f0bc97d7bb31230c3a)
|
|
(cherry picked from commit 0a8a0188033d6b27c521f082fdddae9873dd5d3d)
|
|
(cherry picked from commit 6bd780887c0e13dc9272ec499ebc6f01cfaf7ea6)
|
|
(cherry picked from commit 1a498915efdc433dda7bd6e5fcc08703a48560c6)
|
|
This reverts commit 5849ba88a1a20e4d3584843e0be46e456c5f7980.
|
|
build"
This reverts commit 0ecc2c26f7ac939e4e23c14f5027ac7592c25761.
|
|
|