Fix: 06e4e90132
Modified BGP to pay more attention the prefix returned from
zebra to ensure that a LPM wasn't accidently causing BGP
import checks to think it had a match when it did not.
This unfortunately removed the check to handle the route
removal.
This sequence of config and events would leave BGP in a bad state:
ip route 100.100.100.0/24 Null0
router bgp 32932
bgp network import-check
address-family ipv4 uni
network 100.100.100.0/24
Then if you removed the static route the import check would
still think the route existed:
donatas-pc(config)# ip route 100.100.100.0/24 Null0
donatas-pc(config)# do sh ip bgp import-check-table
Current BGP import check cache:
100.100.100.0 valid [IGP metric 0], #paths 1
blackhole
Last update: Sat Apr 23 22:51:34 2022
donatas-pc(config)# do sh ip nht
100.100.100.0
resolved via static
is directly connected, Null0
Client list: bgp(fd 17)
donatas-pc(config)# do sh ip bgp neighbors 192.168.10.123 advertised-routes | include 100.100.100.0
*> 100.100.100.0/24 0.0.0.0 0 32768 i
donatas-pc(config)# no ip route 100.100.100.0/24 Null0
donatas-pc(config)# do sh ip nht
100.100.100.0
resolved via kernel
via 192.168.10.1, enp3s0
Client list: bgp(fd 17)
donatas-pc(config)# do sh ip bgp import-check-table
Current BGP import check cache:
100.100.100.0 valid [IGP metric 0], #paths 1
blackhole
Last update: Sat Apr 23 22:51:34 2022
donatas-pc(config)# do sh ip bgp neighbors 192.168.10.123 advertised-routes | include 100.100.100.0
*> 100.100.100.0/24 0.0.0.0 0 32768 i
donatas-pc(config)#
Fix this by moving the code to handle the prefix check to the
evaluation function and mark the bnc as not matching and actually
evaluate the bnc.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
5421bf8 commit forgot to set the parameter "new" to true
when a new source is created, have fixed it.
igmp_get_source_by_addr api is currently setting the parameter
"new" to false always. This is not right. The caller apis are using
this field to decide and based on that take actions to create timers, etc.
Its need to be set to true when a new source is created.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
watchfrr and staticd do not require <1024 ports to be running, thus they can
start, but others fail.
We should allow only users with EUID=0 (sudo or root) running frrinit.sh.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
In addition to turning on isis bfd debugging traces, the internal
bfd messaging debug is also enabled. Reversely, when isis bfd traces
are off, the internal messaging debug traces are off too.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add initial zebra tracepoint support infrastructure
as well as add a frr_zebra:netlink_interface
callback.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If you are in a situation where you have multiple addresses on an
interface, zebra creates one connected route for them.
The issue is that the rib entry is not created if addresses were
added before the interface was running.
We add the address to a running interface in a typical flow.
Therefore, we handle the route & rib creation within a single ADD event.
In the opposite case, we create the route entries without activating them.
These are considered to be active since ZEBRA_IFC_DOWN is not set.
On the following interface UP, we ignore the same ADDR_ADD as it overlaps
with the existing prefixes -> rib is never created.
The minimal reproducible setup:
-----------------------------------------
ip link add name dummy0 type dummy
ip addr flush dev dummy0
ip link set dummy0 down
ip addr add 192.168.1.7/24 dev dummy0
ip addr add 192.168.1.8/24 dev dummy0
ip link set dummy0 up
vtysh -c 'show ip route' | grep dummy0
Signed-off-by: Volodymyr Huti <v.huti@vyos.io>
Recent commit e92508a741 changed
the prefix_master->str to a RB tree. This introduced a condition
whnere on shutdown the prefix list was removed from the master list
and then operated on by passing around a name. Which was then used
to lookup the prefix list again when we operated on the code.
This change to a RB Tree first deleted the item from the RB tree
first thus introducing this crash
Crash:
(gdb) bt
index=0x556c07d59650, pentry=0x556c07d29380) at lib/routemap.c:2397
arg=0x7ffdbf84bc60) at lib/hash.c:267
event=RMAP_EVENT_PLIST_DELETED) at lib/routemap.c:2489
Grab the first item on the list, clean it and then remove it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When we do "log file /var/log/frr/something", permissions are set to
0640 (frr:frr), but when the logrotate kicks in, we have 0640 (frr:frrvty).
I believe, we should have a consistent permissions.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
At the moment we set /var/log/frr permissions to 0750 (frr:frr), but the log
file is 0640 (root:adm) (unless logrotated) and that doesn't allow adm group
to even open the directory.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
