| Age | Commit message (Collapse) | Author |
|---|
|
(cherry picked from commit 31acb42ecdf4ecf0f636f831f42a845b8a00d367)
|
|
iifname/oifname
When any of the following features NAT, NAT66 or Firewall is enabled, for every
VRF on the CLI we install one rule into nftables for conntrack:
chain vrf_zones_ct_in {
type filter hook prerouting priority raw; policy accept;
counter packets 3113 bytes 32227 ct original zone set iifname map @ct_iface_map
counter packets 8550 bytes 80739 ct original zone set iifname map @ct_iface_map
counter packets 5644 bytes 67697 ct original zone set iifname map @ct_iface_map
}
This is superfluous.
(cherry picked from commit d6e9824f1612bd8c876437c071f31a1a0f44af5d)
|
|
Remove unused import (left over) from commit 36f3791e0 ("utils: migrate to new
get_vrf_tableid() helper")
(cherry picked from commit b551f542c5c906c901e3be37ad3fd68c8248473d)
|
|
Commit 452068ce7 ("interfaces: T6592: moving an interface between VRF instances
failed") introduced a new helper to retrieve the VRF table ID from the Kernel.
This commit migrates the old code path where the individual fields got queried
to the new helper vyos.utils.network.get_vrf_tableid().
(cherry picked from commit 36f3791e0c15267483d59a3bb74465811d08df88)
|
|
When adding and removing VRF instances on the fly it was noticed that the vni
statement under the VRF instance in FRR vanishes. This was caused by a race
condition which was previously designed to fix another bug.
The wierd design of a Python helper below the VRF tree to only generate the
VNI configuration nodes is now gone and all is rendered in the proper place.
(cherry picked from commit e7bb65894f86372dc0f6e8fd39b1628e0a224c68)
|
|
Fix for restoring default ip rule values after deleting VRF
Defult values:
```
$ ip rule
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
```
After adding and deleting a VRF we get unexpected values:
```
$ ip rule
1000: from all lookup [l3mdev-table]
2000: from all lookup [l3mdev-table] unreachable
32765: from all lookup local
32766: from all lookup main
32767: from all lookup default
```
(cherry picked from commit ce0bc35f8b5ff80a7b8fbfdf1b9ccc10c5c254fd)
|
|
(cherry picked from commit 09ac2851f89f2b7d94a21c3506e46f380e961fba)
|
|
required
(cherry picked from commit 6f7d1e15665655e37e8ca830e28d9650445c1217)
|
|
Always enable VRF strict_mode
(cherry picked from commit 117fbcd6237b59f54f2c1c66986a8ce073808c84)
|
|
A code path was missing to check if only priority is available in the result of
"ip --json -4 rule show", in the case of l3mdev it's a dedicated key!
(cherry picked from commit a009143a62caca207fdffffcf0b490c747a87025)
|
|
There is no need to add and remove this table during runtime - it can lurk
in the standard firewall init code.
(cherry picked from commit 89f0d347bfe5e468355817a617dc71823a58c284)
|
|
This prevents the following error when configuring the first VRF:
sysctl: cannot stat /proc/sys/net/vrf/strict_mode: No such file or directory
(cherry picked from commit a821b8c603999665ce8a77acb0e44a743811992a)
|
|
Enable/Disable VRF strict mode, when net.vrf.strict_mode=0 (default) it is
possible to associate multiple VRF devices to the same table. Conversely, when
net.vrf.strict_mode=1 a table can be associated to a single VRF device.
A VRF table can be used by the VyOS CLI only once (ensured by verify()), this
simply adds an additional Kernel safety net, but a requirement for IPv6 segment
routing headers.
(cherry picked from commit 10701108fecb36f7be7eb7ef5f1e54e63da5fb4e)
|
|
This is a workaround for the priority inversion from T5492 ("CLI node priority
is not inversed on node deletion"). As this is a corner case bug that's only
triggered if an interface is removed from a VRF and also the VRF is removed in
one commit, priorities are not honored.
Thus we implement this workaround which stop the DHCP(v6) client processes on
the VRF associated interfaces to get out the DHCP RELEASE message before
interfaces are shut down.
|
|
Helper functions can and will be re-use din different code places.
|
|
* T5195: move run, cmd, call, rc_cmd helper to vyos.utils.process
* T5195: use read_file and write_file implementation from vyos.utils.file
Changed code automatically using:
find . -type f -not -path '*/\.*' -exec sed -i 's/^from vyos.util import read_file$/from vyos.utils.file import read_file/g' {} +
find . -type f -not -path '*/\.*' -exec sed -i 's/^from vyos.util import write_file$/from vyos.utils.file import write_file/g' {} +
* T5195: move chmod* helpers to vyos.utils.permission
* T5195: use colon_separated_to_dict from vyos.utils.dict
* T5195: move is_systemd_service_* to vyos.utils.process
* T5195: fix boot issues with missing imports
* T5195: move dict_search_* helpers to vyos.utils.dict
* T5195: move network helpers to vyos.utils.network
* T5195: move commit_* helpers to vyos.utils.commit
* T5195: move user I/O helpers to vyos.utils.io
|
|
|
|
|
|
|
|
Commit dafb0da2 ("static: T4883: add a description field for routing tables")
added an iproute2 description table but lacked checking if the key exists.
This has been fixed and also converted to Jinja2 to keep the "common" style
inside the routing protocols. It might feel overengineered indeed.
|
|
VRF names: "add, all, broadcast, default, delete, dev, get, inet,
mtu, link, type, vrf" are reserved and cannot be used for vrf name
|
|
|
|
|
|
|
|
|
|
|
|
We always mangled and worked on the "ip rule" singleton even when nothing
needed to be changed. This resulted in a VRF hickup when the same VRF was added
and removed multiple times.
set interfaces ethernet eth1 vrf foo
set vrf name foo table '1000'
commit
delete interfaces ethernet eth1 vrf
delete vrf
commit
set interfaces ethernet eth1 vrf foo
set vrf name foo table '1000'
commit
broke reachability on eth1 - a reboot was required.
This change will now only alter the ip rule tables once when VRF instances
are created for the first time and will not touch the Kernel "ip rule"
representation afterwards.
|
|
|
|
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.
|
|
Somehow we hit a priority inversion here as we need to remove the VRF assigned
VNI before we can remove a BGP bound VRF instance. Maybe move this to an
individual helper script that set's up the VNI for the given VRF after any
routing protocol (in our case this was triggered by running "make testc" when
building an ISO image by the bgp-rpki config).
|
|
This is a completing commit to a55585a833 ("frr: T2175: remove no longer
required loop when removing routing protocols") that was missed out
previously.
|
|
This extends commit 22791e26 ("VRF: T3655: proper connection tracking for VRFs")
so that when the netfilter table is removed, we first check if it exists at all,
and if it does not exist we do not remove it.
This fixes the smoketest error:
PermissionError: [Errno 1] failed to run command: nft delete table inet vrf_zones
|
|
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
|
|
because of typo
change from `bind_to_all` to `bind-to-all`
refer: interface-definitions/vrf.xml.in
|
|
Commit 548d9057e3e (vrf: T3344: move dynamic routing protocols under "vrf name
<name> protocols") temporary removed the possibility to specify the VNI for a
given VRF to to changing of the CLI configuration nodes.
As VNI is set inside zebra, we can re-use the now widely deployed frr python
library to configure and change the configuration without any interference to
other FRR daemons.
|
|
Re-issuing the same iproute2 commands can lead to errors, simply ignore
them and not raise a Python exception.
|
|
|
|
|
|
47: bar: <NOARP,MASTER,UP,LOWER_UP> mtu 65536 qdisc noqueue state UP group default qlen 1000
link/ether 76:7d:c0:53:6d:89 brd ff:ff:ff:ff:ff:ff
inet 127.0.0.1/8 scope host bar
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
|
|
|
|
|
|
|
|
airbag must now be explicitly installed.
the patch also allow to fully disables the installation of the logging
code at setup (and not just installing and doing nothing)
|
|
convert all call to jinja to use template.render
|
|
|
|
|
|
|
|
If the unreachable routes for IPv4 and IPv6 are not deleted, there will be an
error when creating the same VRF again after removal.
Error changing VRF: Command '['sudo', 'ip', '-4', 'route', 'del', 'vrf',
'Blue', 'unreachable', 'default', 'metric', '4278198272']' returned
non-zero exit status 2.
|
|
|
|
The list of VRFs to remove has been converted to a dict. The deletion of a VRF
was no longer triggered as the logic still thought it is a list.
|
