In general, routes leaked from the vpn rib to a vrf include any
labels that might have been attached to the vpn route. VRF routes
that have labels attached require a label-switched path and therefore
require nexthops with labels in order to be marked valid by the
nexthop-tracking logic.
However, some routes in the vpn RIB originated in vrfs local to this
router. Even though they may have labels, we must omit the labels
when leaking to a vrf because traffic using those resulting routes
will be carried by this router via IP routing and not label switching.
The nexthops of these routes do not need to indicate a label-switched
path, and thus the routes should be marked valid even when their nexthops
do not have labels.
This changeset omits labels from vpn->vrf leaked routes when the ultimate
source of the vpn route was a local vrf.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
[zebra/zebra_vxlan.c:5779] -> [zebra/zebra_vxlan.c:5778]:
(warning) Either the condition 'if(svi_if_zif&&svi_if_link)'
is redundant or there is possible null pointer dereference: svi_if_zif.
Signed-off-by: Ilya Shipitsin <chipitsine@gmail.com>
rn cannot be null here
issue detected by cppcheck:
[ripd/rip_snmp.c:208] -> [ripd/rip_snmp.c:207]: (warning) Either the condition
'if(rn&&!strncmp(i->name,ifp->name,INTERFACE_NAMSIZ))' is redundant or there is
possible null pointer dereference: rn.
Signed-off-by: Ilya Shipitsin <chipitsine@gmail.com>
Background:
v6 does not have route replace semantics. If you want to add a nexthop
to an existing route, you just send RTM_NEWROUTE and the new nexthop.
If you want to delete a nexthop you should just send RTM_DELROUTE
with the removed nexthop.
This leads to situations where if zebra is processing a route
and has lost track of intermediate nexthops( yes this sucks )
then v6 routes will get out of sync when we try to implement
route replace semantics.
So notice when we are doing a route delete and the route is
not being updated, just send the prefix and tell it too delete.
Ticket: CM-20391
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This commit does 2 things:
1) When receiving a route from the kernel, display the incoming
table as part of the debug, to facilatate knowing what we are
talking about as part of the debug.
2) When displaying nexthop information for routes we were sending
to the kernel, no need to display the route information every time
Display the route then the individual nexthops for what we are doing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Notice when someone deletes a neighbor entry we've put in for
rfc-5549 gets deleted by some evil evil person. When this happens
notice and push it back in, immediately.
Ticket: CM-18612
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The code to reinstall self originated routes was not behaving
correctly. For some reason we were looking for self originated
routes from the kernel to be of type KERNEL. This was probably
missed when we started installing the route types. We should
depend on the self originated flag that we determine from
the callback from the kernel.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com.
When the last match criteria was removed (dst-ip or src-ip), we were
not deleting the rule correctly for ipv6. This fix retains the
needed src-ip/dst-ip during the pbr_send_pbr_map process so the
appropriate information is available for the rule delete.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Since PBR is meant to be for small deployments, allowing
end users to arbitrarily change rule and table ranges
without some more careful thought on what is going on
and how to do it, sets us up for issues.
At this time remove these knobs.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a command is attempted to be configed and it
fails to be installed, indicate via vtysh return
codes that we did not accept the command
Ticket: CM-20216
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we have a PBR installed as a table, we need to notice
when a nexthop changes and rethink the routes for the pbr
tables.
Add code to nexthop tracking to notice the pbr watched
nexthop has changed in some manner. If it is a pbr route
that depends on the nexthop then just enqueue it for
rethinking.
This is a bit of a hammer, we know that only pbr routes
are going to be installing routes in weird non-standard
tables as such we need to only handle nexthop changes
for nexthops that are actually changing that we care
about and to only requeue for route nodes we have
route entries for from PBR
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When displaying a pbr map sequence for a show run do not use the
vty_frame construct. We should display the config even if we
do not have much to display.
Ticket: CM-20196
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The linux kernel puts the vrf rule at 1000, since pbr
rules need to be before this rule, don't allow us to go
beyond.
Ticket: CM-19946
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If an interface is in the process of coming up or
partially deconfigured, prevent pbrd from crashing
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If the match src-ip or dst-ip command entered has already
been received and it's the same prefix, we are done and
do not need to do anything more.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When removing either the match dst or match src of a previously
valid pbr map, we would just try to re-install the rule which
was rejected. This fix deletes the old rule before we re-apply
the new rule.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
If there are no PBR interfaces configured and we do a 'show run', pbrd
crashes with a NPD when it tries to dereference ifp->info.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
When we are entering 'set nexthop' and 'set nexthop-group'
ensure that the cli only allows one of these to happen
at a time.
Ticket: CM-20125
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 commit adds code to notify the compiler that we
will not be changing the arguments to nexthop2str
and we expect thre return to be treated the same.
Additionally we add some code to allow nexthops to
be hashed to be used in a hash.
Signed-off-by: Quentin Young <qlyoung@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>
Handle ECMP for Intra Area Prefix LSAs routes.
Ticket:CM-16139
Testing Done:
Configure ospf6 passive interface R2 and R3 with
same prefix address.
Check Intra Area Prefix LSA update at R1 and R3
which would have ECMP paths with effective two
paths and two nexthops (from R2 and R4).
stop frr at R3 and R1 and R4 route changes back to
one nexthop and one paht.
R1 ---- R2
| |
R3 ---- R4
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
