| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Done with a combination of regex'ing and banging my head against a wall.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
| |
|
|
|
|
|
|
|
| |
This patch just introduces the callback mechanism for the
resilient nexthop changes so that upper level daemons
can take advantage of the change. This does nothing
at this point but just call some code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
| |
|
|
|
|
|
|
|
|
| |
When adding a nhg to a route map, make sure to specify the `family`
of the rm by looking at the contents of the nhg. Installation in the
kernel (for DSCP rules in particular) relies on this being specified in
the netlink message.
Signed-off-by: Wesley Coakley <wcoakley@nvidia.com>
Signed-off-by: Stephen Worley <sworley@nvidia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Represent installed ("allocated") NHG tables with a hash keyed by table
ID. Replaces a pre-allocated array of booleans that implemented this
functionality before.
+ PBR table range > 65535 is fixed (was OOB access before :))
+ Pre-compute next available ID to save time when only checking
if all tables are allocated
Signed-off-by: Wesley Coakley <wcoakley@nvidia.com>
|
| |
|
|
|
|
|
| |
Given a received nexthop update, only send down an update to the
relevant nexthop group. Avoid sending down superfluous updates
Signed-off-by: Wesley Coakley <wcoakley@nvidia.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
The pnhc->nexthop was a pointer copy. Causing issues
with the ability to move pointers around for the
different pnhc since the pnhc mirrored the nexthop
caches. When we received a vrf change if we shared
pointers it was impossible to know if we had
already updated the code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
|
|
|
|
|
| |
We had multiple pnhc cache entries with the same nexthop
pointer. This causes some large amount of confusion.
Fixup the code to handle this situation better.
Ticket: CM-31044
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
|
|
|
|
|
| |
PBR needs the ability to allow ephermeal interfaces( bonds,
vrfs, dummy, bridges, etc ) to be destroyed and then
recreated and at the same time keep track of them and
rebuild state as appropriate when we get a change.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently when a vrf is deleted than added back in PBR was
not going through and touching up all the data structures
that needed to be massaged to allow it to start working again.
This includes:
a) Search through the nexthop groups to find any nexthop
that references the old nexthop id and set it right again.
b) Search through the nexthop cache for nht and reset
those nexthops to the right vrf as well as re-register
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
| |
Signed-off-by: Wesley Coakley <wcoakley@cumulusnetworks.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Implement the ability to replace any existing `set *` or
`match` with another one or adding more config without having
to first delete the original config already there.
Before, we needed to constantly execute a `no` command for everything
to remove the rule before making changes to it. With this
patch, you can replace configs on individual sequences much
easier.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that nexthop groups can contain interface nexthops, make the
necessary adjustments in pbrd to handle them appropriately.
For normal IP nexthops, pbrd uses the NHT callbacks to validate
these nexthops (i.e. check if they are reachable). NHT can't be
used for interface nexthops though. To work around this issue,
use the interface event callbacks from the zclient API to validate
interface nexthops (an interface nexthop is valid only if the
corresponding interface is up and running).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
| |
|
|
|
|
|
| |
* Add log messages to indicate when we have run out of table IDs
* Increase minimum range size to 1000 to reduce risk of hitting this
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
|
| |
|
|
|
|
|
|
|
| |
The buffer size was insufficiently sized to hold the
entirety of the data being passed in.
Modify the nht code to use a bit bigger buffer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pbr_events.c file was a mistake in that it overly complicated
the code and made it hard to think about what was happening.
Remove all the events and just do the work where needed.
Additionally rethink the sending of the pbr map to
zebra and only send one notification at a time instead
of having the sending function attempt to figure out
what to do.
Clean up some of the no form of commands to make them
work properly.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
|
|
|
This is an implementation of PBR for FRR.
This implemenation uses a combination of rules and
tables to determine how packets will flow.
PBR introduces a new concept of 'nexthop-groups' to
specify a group of nexthops that will be used for
ecmp. Nexthop-groups are specified on the cli via:
nexthop-group DONNA
nexthop 192.168.208.1
nexthop 192.168.209.1
nexthop 192.168.210.1
!
PBR sees the nexthop-group and installs these as a default
route with these nexthops starting at table 10000
robot# show pbr nexthop-groups
Nexthop-Group: DONNA Table: 10001 Valid: 1 Installed: 1
Valid: 1 nexthop 192.168.209.1
Valid: 1 nexthop 192.168.210.1
Valid: 1 nexthop 192.168.208.1
I have also introduced the ability to specify a table
in a 'show ip route table XXX' to see the specified tables.
robot# show ip route table 10001
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, P - PIM, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR,
> - selected route, * - FIB route
F>* 0.0.0.0/0 [0/0] via 192.168.208.1, enp0s8, 00:14:25
* via 192.168.209.1, enp0s9, 00:14:25
* via 192.168.210.1, enp0s10, 00:14:25
PBR tracks PBR-MAPS via the pbr-map command:
!
pbr-map EVA seq 10
match src-ip 4.3.4.0/24
set nexthop-group DONNA
!
pbr-map EVA seq 20
match dst-ip 4.3.5.0/24
set nexthop-group DONNA
!
pbr-maps can have 'match src-ip <prefix>' and 'match dst-ip <prefix>'
to affect decisions about incoming packets. Additionally if you
only have one nexthop to use for a pbr-map you do not need
to setup a nexthop-group and can specify 'set nexthop XXXX'.
To apply the pbr-map to an incoming interface you do this:
interface enp0s10
pbr-policy EVA
!
When a pbr-map is applied to interfaces it can be installed
into the kernel as a rule:
[sharpd@robot frr1]$ ip rule show
0: from all lookup local
309: from 4.3.4.0/24 iif enp0s10 lookup 10001
319: from all to 4.3.5.0/24 iif enp0s10 lookup 10001
1000: from all lookup [l3mdev-table]
32766: from all lookup main
32767: from all lookup default
[sharpd@robot frr1]$ ip route show table 10001
default proto pbr metric 20
nexthop via 192.168.208.1 dev enp0s8 weight 1
nexthop via 192.168.209.1 dev enp0s9 weight 1
nexthop via 192.168.210.1 dev enp0s10 weight 1
The linux kernel now will use the rules and tables to properly
apply these policies.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
|
