| Age | Commit message (Collapse) | Author |
|---|
|
(cherry picked from commit 32d6a693de99021d2cd44fb4235e929caf7b4a6d)
|
|
context
* set vrf name <name> ip nht no-resolve-via-default
* set vrf name <name> ipv6 nht no-resolve-via-default
(cherry picked from commit 0fafc4bcdb9efc03796ddab0832471b11ba1bbe0)
|
|
A network namespace can have VRFs assigned, thus we need to get the priorities
right. This lowers both priorities in general as a VRF or NETNS needs to be
available very early as services can run on top of them.
(cherry picked from commit 9dd5ff064a37b4e884f7bd9fb7630bf7829fa1ad)
|
|
|
|
|
|
It is possible to install a route-map which filters the routes between routing
daemons and the OS kernel (zebra)
As of now this can be done by e.g.
* set protocols ospf route-map foo
* set protocols ospfv3 route-map foo
* set protocols bgp route-map foo
Which in turn will install the following lines into FRR
* ip protocol ospf route-map foo
* ipv6 protocol ospf6 route-map foo
* ip protocol bgp route-map foo
The current state of the VyOS CLI is incomplete as there is no way to:
* Install a filter for BGP IPv6 routes
* Install a filter for static routes
* Install a filter for connected routes
Thus the CLI should be redesigned to close match what FRR does for both the
default and any other VRF
* set system ip protocol ospf route-map foo
* set system ipv6 protocol ospfv3 route-map foo
* set system ip protocol bgp route-map foo
* set system ipv6 protocol bgp route-map foo
The configuration can be migrated accordingly. This commit does not come with
the migrator, it will be comitted later.
|
|
No need to have two distinct include blocks as one superseeds the other. Also
this makes the entire behavior of "description" CLI node simpler.
|
|
|
|
|
|
|
|
set vrf name foo protocols ospfv3
|
|
|
|
|
|
|
|
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.
|
|
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
|
|
|
|
|
|
|
|
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.
|
|
Every time when set configuration bgp, you need set AS number. There is very
less benefit in this system so the AS number is moved from a tagNode level down
to a leafNode with the name "local-as", same as on the neighbor or peer-group
level.
This changes the CLI configuration from:
set protocols bgp 100 neighbor 10.10.1.2 remote-as 200
to
set protocols bgp local-as 100
set protocols bgp neighbor 10.10.1.2 remote-as 200
|
|
|
|
VRF support can be tested using:
set vrf name red table 1000
set vrf name red protocols isis domain FOOO
set vrf name red protocols isis net 49.0001.1921.6800.1002.00
set vrf name red protocols isis interface eth1
|
|
|
|
As the amount of include files now has reached a certain amount, it is getting
more and more crowsded, thuse introducing "per topic" subdirectories on the
filesystem to keep a clean structure makes sense.
|
|
As the amount of include files now has reached a certain amount, it is getting
more and more crowsded, thuse introducing "per topic" subdirectories on the
filesystem to keep a clean structure makes sense.
|
|
We must ensure that an interface is already added to a VRF before it is
referenced inside a VRF context, e.g. OSPF.
|
|
Instead of having the dynamic routing protocols OSPF and BGP residing under
the "protocols vrf <name> [ospf|bgp]" nodes, rather move them directly under
the "vrf name <name> protocols [ospf|bgp]" node. Now all VRF related parts
are placed under the same root node.
This eases the verify steps tremendously, as we do not need to check wheter a
VRF eists or not, it will always exist as we operate under a child node.
|
|
|
|
|
|
|
|
VRFs should be created as early as possible.
|
|
|
|
Every VRF that's created is not allowed to be named like any interface that
can be active on the system. This includes eth, lan, br, dum, lo ....
In theoriy this would work but as soon as such a regular interface is created
things will go sideways rather quick thus we limit the namespace which can
be used to create a VRF.
Appending an interface name is still possible like coolvrf-eth0.
|
|
... to not cause any issues with buildin tables or PBR. PBR uses table 1 - 200
so there is a small overlap (by intention)
|
|
By default the scope of the port bindings for unbound sockets is limited to the
default VRF. That is, it will not be matched by packets arriving on interfaces
enslaved to an l3mdev and processes may bind to the same port if they bind to
an l3mdev.
TCP & UDP services running in the default VRF context (ie., not bound to any
VRF device) can work across all VRF domains by enabling the 'vrf bind-to-all'
option.
|
|
|
|
|
|
|
|
This is a work in progress to complete T31 whoever thought it was less than
1 hour of work was ..... optimistic.
Only VRF vreation and show is supported right now. No interface can be bound
to any one VRF.
|
