| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
