| Age | Commit message (Collapse) | Author |
|---|
|
Move keepalived configuration from /etc/keepalived to /run/keepalived.
|
|
|
|
Commit b7d30137b1 ("vyos.ifconfig: provide generic get_mac_synthetic() method")
provided a common helper to generate MAC addresses used by EUI64 addresses for
interfaces not having a layer2 interface (WireGuard or ip tunnel).
The problem is that every call to the helper always yielded a new MAC address.
This becomes problematic when IPv6 link-local addresses are generated and
modified on the interface as multiple link-local (fe80::/64) addresses can
easily be added to the interface leaving ... a mess.
This commit changes the way how the "synthetic" MAC is generated, we generate a
UUID which is stable as it is based on the interface name. We take out the last
48 bits of the UUID and form the "MAC" address.
|
|
When IPv6 is disbaled on an interface also the sysfs files related to IPv6 for
this interface vanish. We need to check if the file exists before we read it.
|
|
When using VRRP on any given interface and performing an action against that
interface - be it even only changing the alias - will trigger a removal of the
VRRP IP address.
The issue is caused by:
# determine IP addresses which are assigned to the interface and build a
# list of addresses which are no longer in the dict so they can be removed
cur_addr = self.get_addr()
for addr in list_diff(cur_addr, new_addr):
When the script calls into the library - we will drop all IP addresses set on
the adapter but not available in the config dict.
We should only remove the IP addresses marked by the CLI to be deleted!
|
|
There is no need to alter interface parameters if they have not changed at all.
|
|
The key defaults to 0 and will match any policies which similarly do not have
a lookup key configuration. This means that a vti0 named interface will pull in
all traffic and others will stop working. Thus we simply shift the key by one
to also support a vti0 interface.
|
|
states
Turns out an AX88179 USB 3.0 NIC does not support reading back the speed and
duplex settings in every operating state. While the NIC is beeing
initialized, reading the speed setting will return:
$ cat /sys/class/net/eth6/speed
cat: /sys/class/net/eth6/speed: Invalid argument
Thus if this happens, we simply tell the system that the current NIC speed
matches the requested speed and nothing is changed at this point in time.
(cherry picked from commit e2b7e1766cc22c5cd718a5001be6336bdca92eec)
|
|
Move the two implementations to get the driver name of a NIC from ethernet.py
and ethtool.py to only ethtool.py.
(cherry picked from commit 07840977834816b69fa3b366817d90f44b5dc7a7)
|
|
(cherry picked from commit 1572edd2cef355710d1129907d3e49451a6c31d4)
|
|
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.
|
|
It makes no sense to have a parser for the ethtool value sin ethtool.py
and ethernet.py - one instance ios more then enough!
|
|
This makes understanding the code easier what is "really" called without
opening the man page.
|
|
Deprecated in the Linux Kernel by commit 08a00fea6de277df12ccfadc21 ("net:
Remove references to NETIF_F_UFO from ethtool.").
(cherry picked from commit f5e46ee6cc2b6c1c1869e26beca4ccd5bf52b62f)
|
|
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.
|
|
Some tc qdisc rules are generated by old perl code
It prevent to unexpected override this code by python.
|
|
Check eui64_old value before deleting
It can be empty or not ipv6 address.
(cherry picked from commit 0de23064b9d575ce0569839e3b4453a0c2e9dc1c)
|
|
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!
|
|
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.
|
|
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
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
|
|
In some cases, we need to wait until local address is assigned.
And only then l2tpv3 tunnel can be configured.
For example when ipv6 address is in "tentative" state
or we wait for some routing daemon/route for a remote address.
|
|
Also renames peer pubkey to public-key for consistency
|
|
VRF: T3655: proper connection tracking for VRFs
|
|
Currently, all VRFs share the same connection tracking table, which can
lead to problems:
- traffic leaks to a wrong VRF
- improper NAT rules handling when multiple VRFs contain the same IP
networks
- stateful firewall rules issues
The commit implements connection tracking zones support. Each VRF
utilizes its own zone, so connections will never mix up.
It also adds some restrictions to VRF names and assigned table numbers,
because of nftables and conntrack requirements:
- VRF name should always start from a letter (interfaces that start from
numbers are not supported in nftables rules)
- table number must be in the 100-65535 range because conntrack supports
only 65535 zones
|
|
|
|
XFRM interfaces are similar to VTI devices in their basic functionality but
offer several advantages:
* No tunnel endpoint addresses have to be configured on the interfaces.
Compared to VTIs, which are layer 3 tunnel devices with mandatory endpoints,
this resolves issues with wildcard addresses (only one VTI with wildcard
endpoints is supported), avoids a 1:1 mapping between SAs and interfaces, and
easily allows SAs with multiple peers to share the same interface.
* Because there are no endpoint addresses, IPv4 and IPv6 SAs are supported on
the same interface (VTI devices only support one address family).
* IPsec modes other than tunnel are supported (VTI devices only support
tunnel mode).
* No awkward configuration via GRE keys and XFRM marks. Instead, a new identifier
(XFRM interface ID) links policies and SAs with XFRM interfaces.
|
|
Add implementation with XML and Python.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It is not possible to change the VLAN encapsulation protocol "on-the-fly". For
this "quirk" we need to actively delete and re-create the VIF-S interface.
|
|
|
|
Option specifying the rate in which we'll ask our link partner to transmit
LACPDU packets in 802.3ad mode.
set interfaces bonding bond0 lacp-rate <slow|fast>
slow: Request partner to transmit LACPDUs every 30 seconds (default)
fast: Request partner to transmit LACPDUs every 1 second
|
|
|
|
Instead of having a dedicated ERSPAN interface type, rather move the specifics
into "interface tunnel". A migrator is not needed as there is yet no LTS release
with this feature and this is considered experimental.
|
|
|
|
Removing a VLAN (VIF) interface from the CLI always deleted all interfaces the
kernel listed as "upper" in the /sys/class/net folder. This had the drawback
that when deleting a VIF, also the VRF interface was simply deleted - killing
all VRF related services.
|
|
Private VLAN, also known as port isolation, is a technique in computer
networking where a VLAN contains switch ports that are restricted such that
they can only communicate with a given "uplink". The restricted ports are
called "private ports".
Each private VLAN typically contains many private ports, and a single uplink.
The uplink will typically be a port (or link aggregation group) connected to a
router, firewall, server, provider network, or similar central resource.
Q: https://en.wikipedia.org/wiki/Private_VLAN
|
|
As we can also use the TunnelIf() class from op-mode we must ensure that read-only
access to the class works even if required configuration keys as "encapsulation"
are not passed to the class on invokation.
This fixes an isse where "show interfaces tunnel" returned:
Traceback (most recent call last):
File "/usr/libexec/vyos/op_mode/show_interfaces.py", line 313, in <module>
args.vrrp
File "/usr/libexec/vyos/op_mode/show_interfaces.py", line 48, in handled_function
function(*args, **kwargs)
File "/usr/libexec/vyos/op_mode/show_interfaces.py", line 222, in run_show_intf_brief
for interface in filtered_interfaces(ifnames, iftypes, vif, vrrp):
File "/usr/libexec/vyos/op_mode/show_interfaces.py", line 77, in filtered_interfaces
interface = klass(ifname, create=False, debug=False)
File "/usr/lib/python3/dist-packages/vyos/ifconfig/tunnel.py", line 99, in __init__
if self.iftype in ['gretap', 'ip6gretap']:
AttributeError: 'TunnelIf' object has no attribute 'iftype'
|
|
Commit e5b335830ef ("vyos.ifconfig: T1579: remove calls to
vyos.ifconfig.Interface.get_config()") removed the PPPoEIf class as it seemed
to be unused. It turns out it is required by the op-mode commands for e.g. "show
interfaces".
|
|
dhcp: T3300: add DHCP default route distance
|
