Add an alias so people can still type `show ip ro`.
It became ambigious in a recent release.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Apparantly the dependents backpointer trees for singletons
got broken at some point and we never noticed. There is
not really any code making use of this right now so not
suprising but let's go ahead and fix it for zebra and proto
NHGs.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Create appropriate accessor functions for the rn->lock
data. We should be accessing this data through accessor
functions since it is private data to the data structure.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When zebra is running with debugs turned on there
is a use after free reported by the address sanitizer:
2020/10/16 12:58:02 ZEBRA: rib_delnode: (0:254):4.5.6.16/32: rn 0x60b000026f20, re 0x6080000131a0, removing
2020/10/16 12:58:02 ZEBRA: rib_meta_queue_add: (0:254):4.5.6.16/32: queued rn 0x60b000026f20 into sub-queue 3
=================================================================
==3101430==ERROR: AddressSanitizer: heap-use-after-free on address 0x608000011d28 at pc 0x555555705ab6 bp 0x7fffffffdab0 sp 0x7fffffffdaa8
READ of size 8 at 0x608000011d28 thread T0
#0 0x555555705ab5 in re_list_const_first zebra/rib.h:222
#1 0x555555705b54 in re_list_first zebra/rib.h:222
#2 0x555555711a4f in process_subq_route zebra/zebra_rib.c:2248
#3 0x555555711d2e in process_subq zebra/zebra_rib.c:2286
#4 0x555555711ec7 in meta_queue_process zebra/zebra_rib.c:2320
#5 0x7ffff74701f7 in work_queue_run lib/workqueue.c:291
#6 0x7ffff7450e9c in thread_call lib/thread.c:1581
#7 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099
#8 0x55555561a578 in main zebra/main.c:455
#9 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308
#10 0x5555555e3429 in _start (/usr/lib/frr/zebra+0x8f429)
0x608000011d28 is located 8 bytes inside of 88-byte region [0x608000011d20,0x608000011d78)
freed by thread T0 here:
#0 0x7ffff768bb6f in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.6+0xa9b6f)
#1 0x7ffff739ccad in qfree lib/memory.c:129
#2 0x555555709ee4 in rib_gc_dest zebra/zebra_rib.c:746
#3 0x55555570ca76 in rib_process zebra/zebra_rib.c:1240
#4 0x555555711a05 in process_subq_route zebra/zebra_rib.c:2245
#5 0x555555711d2e in process_subq zebra/zebra_rib.c:2286
#6 0x555555711ec7 in meta_queue_process zebra/zebra_rib.c:2320
#7 0x7ffff74701f7 in work_queue_run lib/workqueue.c:291
#8 0x7ffff7450e9c in thread_call lib/thread.c:1581
#9 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099
#10 0x55555561a578 in main zebra/main.c:455
#11 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308
previously allocated by thread T0 here:
#0 0x7ffff768c037 in calloc (/lib/x86_64-linux-gnu/libasan.so.6+0xaa037)
#1 0x7ffff739cb98 in qcalloc lib/memory.c:110
#2 0x555555712ace in zebra_rib_create_dest zebra/zebra_rib.c:2515
#3 0x555555712c6c in rib_link zebra/zebra_rib.c:2576
#4 0x555555712faa in rib_addnode zebra/zebra_rib.c:2607
#5 0x555555715bf0 in rib_add_multipath_nhe zebra/zebra_rib.c:3012
#6 0x555555715f56 in rib_add_multipath zebra/zebra_rib.c:3049
#7 0x55555571788b in rib_add zebra/zebra_rib.c:3327
#8 0x5555555e584a in connected_up zebra/connected.c:254
#9 0x5555555e42ff in connected_announce zebra/connected.c:94
#10 0x5555555e4fd3 in connected_update zebra/connected.c:195
#11 0x5555555e61ad in connected_add_ipv4 zebra/connected.c:340
#12 0x5555555f26f5 in netlink_interface_addr zebra/if_netlink.c:1213
#13 0x55555560f756 in netlink_information_fetch zebra/kernel_netlink.c:350
#14 0x555555612e49 in netlink_parse_info zebra/kernel_netlink.c:941
#15 0x55555560f9f1 in kernel_read zebra/kernel_netlink.c:402
#16 0x7ffff7450e9c in thread_call lib/thread.c:1581
#17 0x7ffff738eaf7 in frr_run lib/libfrr.c:1099
#18 0x55555561a578 in main zebra/main.c:455
#19 0x7ffff7079cc9 in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: heap-use-after-free zebra/rib.h:222 in re_list_const_first
This is happening because we are using the dest pointer after a call into
rib_gc_dest. In process_subq_route, we call rib_process() and if the
dest is deleted dest pointer is now garbage. We must reload the
dest pointer in this case.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
We support configuration of multiple addresses in the same
subnet on a single interface: make sure that zebra supports
multiple instances of the corresponding connected route.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Let's just track the NHEs we get from the kernel(dplane) for
ID usage with internal routes. I tried to be smart originally
and allow them to be re-used internal to zebra but its proving
to cause more bugs than it's worth.
This doesn't break any functionality. It just means we won't
use NHEs we get from the kernel with our routes, we will create
new ones.
Decided this based on various bugs seen ith the lastest one
being on startup with this kernel state:
```
[root@alfred frr-2]# ip next ls
id 15 via 192.168.161.1 dev doof scope link proto zebra
id 17 group 15 proto zebra
[root@alfred frr-2]# ip ro show 3.3.3.1
3.3.3.1 nhid 17 via 192.168.161.1 dev doof
```
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
SIOCGIFMEDIA returns the media state.
SIOCGIFDATA returns interface data which includes the link state.
While the status of the former is usually indicitive of the latter,
this is not always the case.
Ifact some recent net80211 changes in at least NetBSD and OpenBSD
have MONITOR media set to active but the link status set to DOWN.
All interfaces will return link state with SIOCGIFDATA, unlike
SIOCGIFMEDIA. However not all BSD's support SIOCGIFDATA - it has
recently been accepted into FreeBSD-13.
However, all BSD's do report the same structure in ifa_data for
AF_LINK addresses from getifaddrs(3) so the information has always
been available.
Signed-off-by: Roy Marples <roy@marples.name>
Add a param to the common NHE creation callstack so we can
know if this is one we have read in from the dataplane. We can
add some logic on how to handle these special ones later.
I considered putting this on a struct as a flag or something
but it would have required it being put on struct nexthop
since we have some `*_find_nexthop()` functions that can
be called when given NHEs from the dataplane.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
In zebra_evpn_es_evi_show_vni the zevpn pointer if passed into
zebra_evpn_es_evi_show_one_evi will crash if it is null and
we have code that checks that it is non null and then immediately
calls the function. Add a return to prevent a crash.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
No need to check for n->mac existence as that all paths
leading to this code have n->mac already derefed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Use the same lsp and nexthop/nhlfe objects for 'static' and
dynamic LSPs; remove the 'static' objects and their supporting
code.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Zebra's clear duplicate detect command is rpc converted.
There is condition where cli fails with human readable message.
Using northboun's errmsg buffer to display error message to
user.
Testing:
bharat# clear evpn dup-addr vni 1002 ip 2011:11::11
Error type: generic error
Error description: Requested IP's associated MAC aa:aa:aa:aa:aa:aa is still in duplicate state
bharat# clear evpn dup-addr vni 1002 ip 11.11.11.11
Error type: generic error
Error description: Requested IP's associated MAC aa:aa:aa:aa:aa:aa is still in duplicate state
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Display human readable error message in northbound rpc
transaction failure. In case of vtysh nb client, the error
message will be displayed to user.
Testing:
bharat# clear evpn dup-addr vni 1002 ip 11.11.11.11
Error type: generic error
Error description: Requested IP's associated MAC aa:aa:aa:aa:aa:aa is still
in duplicate state
Signed-off-by: Chirag Shah <chirag@nvidia.com>
NetBSD and DragonFlyBSD support reporting of route(4) overflows
by setting the socket option SO_RERROR.
This is handled the same as on Linux by exiting with a -1 error code.
Signed-off-by: Roy Marples <roy@marples.name>
a) Use appropriate %p modifiers for output
2) Display vrf name in addition to vrf id
c) Remove now unused function
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
During quick ifdown / ifup events from the linux kernel there
exists a situation where a prefix that has both a kernel route
and a static route can queued up on the meta-q. If the static
route happens to point at a connected route for nexthop resolution
and we receive a series of quick up/down events *after* the
static route and kernel route are queued up for rib reprocessing.
Since the static route and kernel route are queued on meta-q 1
and the connected route is also on meta-q 1 there exists a situation
where the connected route will be resolved after the static route
fails to resolve, leaving the static route in a unresolved state.
Add a new queue level and put connected routes on their own level,
since they are the fundamental building blocks of pretty much
all the other routes.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When zebra is processing routes to determine what to send
to the rib, suppose we have two routes (a) a route processed
earlier that none of it's nexthops were active and (b)
a route that has good nexthops but has a worse admin distance.
rib_process, would not relook at (a)'s nexthops because
the ROUTE_ENTRY_CHANGED flag was not true and it would
win when compared to (b) because it's admin distance
was better, leaving us with a state where we would
attempt and fail to install route (a) because it
was not valid.
Modify the code to consider the number of nexthops
we have as a determiner if we can use the route.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In rib_process_update_fib, the function is sent two route entries
the old ( previously installed ) and new ( the one to install )
When the function detects that the new is unusable because
the number of nexthops that are usable for that route is 0,
then we uninstall the old route. The problem here is that
we should not attempt to uninstall any route that is
not owned by FRR. Modify the code to not attempt
this behavior
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
b0e9567ed1 fixed an issue whereby
zebra would abort while building an update for a blackhole route.
The same issue, `assert(data_len)` failing in
`zfpm_build_route_updates()`, can be observed when building updates
for unreachable and prohibit routes.
To address this `netlink_route_info_fill()` is updated to not
indicate failure, due to lack of nexthops, for any blackhole routes.
Signed-off-by: Duncan Eastoe <duncan.eastoe@att.com>
When debugging why a route was not successfully installed into the
rib, it would be preferable that the end user only have to turn
on `debug zebra rib detail` as that is what we have been telling
people to do for the last couple of years. Consolidate *back*
to this.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
With l2vni flap leading to duplicate entry creation
in l3vni's l2vni-list.
Use list sorted add with no duplicates.
root@TORC11:mgmt:~# show evpn vni 4001
VNI: 4001
Type: L3
Tenant VRF: vrf1
State: Up
...
L2 VNIs: 1000 1000 1000 0 0 1002
root@TORC11:mgmt:~# ip link set down vx-1002
root@TORC11:mgmt:~# ip link set up vx-1002
root@TORC11:mgmt:~# show evpn vni 4001
VNI: 4001
Type: L3
Tenant VRF: vrf1
State: Up
...
L2 VNIs: 1000 1000 1000 0 0 1002 1002
Ticket:CM-31545
Reviewed By:
Testing Done:
With Fix:
Multiple time flaps vni counts remained the same.
root@TORC11:mgmt:~# ip link set down vx-1002
root@TORC11:mgmt:~# ip link set up vx-1002
root@TORC11:mgmt:~# ip link set down vx-1002
root@TORC11:mgmt:~# ip link set up vx-1002
root@TORC11:mgmt:~# net show evpn vni 4001
VNI: 4001
Type: L3
Tenant VRF: vrf1
State: Up
...
L2 VNIs: 1000 1002
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Only set the NHG/backup NHG pointers of the caller if the read
of the nexthops was successfull. Otherwise, we might free when not
neccessary or double free.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
