| Age | Commit message (Collapse) | Author |
|---|
|
(cherry picked from commit 794f193d11c8c1b5fed78f4e40280480446ab593)
|
|
(cherry picked from commit 0a8a0188033d6b27c521f082fdddae9873dd5d3d)
|
|
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.
|
|
(cherry picked from commit e1b2f1012ca18ef4ecf2b53e9bb01a50880cbd3c)
|
|
(cherry picked from commit 57fca79636b783dc4be2df1bc1ff12a0ce79d988)
|
|
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.
|
