pim6d: Register message getting dropped in source node, mroute stuck in RegJ
The socket created for pimv6 was created using AF_INET for PIMV6
too.
Since the api pim_reg_sock is common to both PIMv4 and PIMv6,
need to use PIM_AF instead of AF_INET.
Donatas Abraitis [Tue, 16 Aug 2022 06:28:21 +0000 (09:28 +0300)]
bgpd: Change warning message when BGP community-list is not found
Before:
```
donatas-laptop# show bgp ipv4 unicast community-list testas
% testas is not a valid community-list name
donatas-laptop# con
donatas-laptop(config)# bgp community-list standard testas permit internet
donatas-laptop(config)# do show bgp ipv4 unicast community-list testas
donatas-laptop(config)#
```
`is not a valid community-list name` is a misleading warning message.
Doing the same for filter-list, access-list, prefix-list, route-map.
Donald Sharp [Mon, 15 Aug 2022 16:01:02 +0000 (12:01 -0400)]
pbrd: VTY_GET_CONTEXT can fail
Although VTY_GET_CONTEXT can return a failed value, it will
never happen in pbrd because of how context work. In
any event add some code to make coverity happy
Donald Sharp [Mon, 15 Aug 2022 15:43:27 +0000 (11:43 -0400)]
pimd: vrf may be NULL from pim_cmd_lookup_vrf
The call into pim_cmd_lookup_vrf may be NULL
and dereferencing it before ensuring that the
vrf pointer is non-NULL is a good way to crash.
A crash can be initiated in pim:
eva# show ip msdp vrf NOEXIST mesh-group
vtysh: error reading from pimd: Permission denied (13)Warning: closing connection to pimd because of an I/O error!
eva# 2022/08/15 11:47:38 [PHJDC-499N2][EC 100663314] STARVATION: task vtysh_rl_read (560b77f76de6) ran for 16777ms (cpu time 0ms)
Donald Sharp [Thu, 11 Aug 2022 01:49:37 +0000 (21:49 -0400)]
ospfd: When a neighbor goes down clear the oi->obuf if we can
When a neighbor goes down on an interface and that interface
has no more neighbors in a viable state where packets should
be being sent, then let's clear up the oi->obuf associated
with the interface the neighbor is on.
Donald Sharp [Wed, 10 Aug 2022 20:15:29 +0000 (16:15 -0400)]
ospfd: Increase packets sent at one time in ospf_write
ospf_write pulls an interface off the ospf->oi_write_q
then writes one packet and places it back on the queue,
keeping track of the first one sent. Then it will
stop sending packets even if we get back to the first
interface written too but before we have sent the full
pkt_count. I do not believe this makes a whole bunch
of sense and is very restrictive of how much data can
be sent especially if you have a limited number of peers
but large amounts of data. Why be so restrictive?
Quentin Young [Fri, 11 Jun 2021 23:01:42 +0000 (19:01 -0400)]
bgpd: don't adv conditionally withdrawn routes
If we have conditional advertisement enabled, and conditionally withdrew
some prefixes, and then we do a 'clear bgp', those routes were getting
advertised again, and then withdrawn the next time the conditional
advertisement scanner executed.
When we go to advertise check the prefix against the conditional
advertisement status so we don't do that.
Quentin Young [Tue, 15 Jun 2021 23:49:19 +0000 (19:49 -0400)]
bgpd: apply cond-adv policy to update group
The new outbound filter to apply conditional advertisement policy was
not working properly due to complications with update groups. The two
routemaps were properly copied into the update group peer filter but not
the conditional advertisement state.
Signed-off-by: Quentin Young <qlyoung@nvidia.com> Signed-off-by: Mark Stapp <mstapp@nvidia.com>
anlan_cs [Tue, 9 Aug 2022 00:41:22 +0000 (20:41 -0400)]
ospf6d: fix missing cost change
After all needed interfaces ( for example: interface "a1", vrf "vrf1", and
"a1" is binded to "vrf1" ) are ready/created, then restart/start frr. zebra
at startup will call `netlink_interface()` to process all interfaces and notify
all clients, but its calling `get_iflink_speed()` maybe fails for unexpected
order of the coming interfaces: when processing "a1", "vrf1" maybe is unknown
at that time. `if_zebra_speed_update()` timer is introduced to deal with this
order problem.
Currently only ospfd and ospf6d deal with this speed change to recalculated
route cost. ospfd can deal with this change, but ospf6d will wrongly missed it.
Since both `ipv6 ospf6 cost COST` and `auto-cost reference-bandwidth COST` are
not set, cost of this ospf6 interface should be calculated with interface
speed, but it is wrongly kept to `10`, which is based on interface speed being
`0` for it missed speed change. Further, ECMP function becomes invalid after
restart frr, beacuse some ospf6 interfaces of one ECMP are wrongly with cost
`10`.
To avoid missing, recalculate cost for ospf6 interfaces based on potentially
changed speed.
Donald Sharp [Tue, 9 Aug 2022 14:23:35 +0000 (10:23 -0400)]
zebra: System routes should be processed the same time as kernel
For whatever reason. ZEBRA_ROUTE_SYSTEM routes were being processed
last. Since a system route is just another kernel route type. Let's
just switch it to be processed the same time as kernel routes.
Donald Sharp [Tue, 9 Aug 2022 13:22:43 +0000 (09:22 -0400)]
zebra: Explicitly call out the correct queue name
There were more than a few places where the NHG meta
queue was not being explicitly called out. Let's
be consistent and use the same nomenclature as much
as possible when talking about metaQ's.
Donald Sharp [Mon, 8 Aug 2022 19:41:42 +0000 (15:41 -0400)]
staticd: When changing the underlying nh ensure it is reinstalled
There exists some nexthop attributes that are not the unique
part of the nexthop and if you change the static route
with those values then the route is not being updated
in zebra with the new values:
Example of brokenness:
eva# conf
eva(config)# ip route 1.2.3.9/32 192.168.119.1 enp39s0 label 16020
eva(config)# do show ip route 1.2.3.9
Routing entry for 1.2.3.9/32
Known via "static", distance 1, metric 0, best
Last update 00:00:05 ago
* 192.168.119.1, via enp39s0, label 16020, weight 1
eva(config)# ip route 1.2.3.9/32 192.168.119.1 enp39s0 label 16040
eva(config)# do show ip route 1.2.3.9
Routing entry for 1.2.3.9/32
Known via "static", distance 1, metric 0, best
Last update 00:00:12 ago
* 192.168.119.1, via enp39s0, label 16020, weight 1
Fixed behavior:
eva# conf
eva(config)# ip route 1.2.3.10/32 192.168.119.1 enp39s0 label 16020
eva(config)# do show ip route 1.2.3.10
Routing entry for 1.2.3.10/32
Known via "static", distance 1, metric 0, best
Last update 00:00:04 ago
* 192.168.119.1, via enp39s0, label 16020, weight 1
eva(config)# ip route 1.2.3.10/32 192.168.119.1 enp39s0 label 16040
eva(config)# do show ip route 1.2.3.10
Routing entry for 1.2.3.10/32
Known via "static", distance 1, metric 0, best
Last update 00:00:01 ago
* 192.168.119.1, via enp39s0, label 16040, weight 1
I've gone through most of the items in staticd that can change
the nexthop Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Donald Sharp [Mon, 8 Aug 2022 16:32:15 +0000 (12:32 -0400)]
zebra: Don't install connected routes multiple times into FRR
When moving an interface between vrf's we do not need
to install the connected routes multiple times.
eva# show ip route vrf all
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
VRF BLUE:
C>* 4.5.6.7/32 is directly connected, dummy7, 00:00:10
VRF default:
K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:00:10
C>* 192.168.119.0/24 is directly connected, enp39s0, 00:00:10
eva# exit
sharpd@eva ~/f/t/topotests (multiple_connected_installs)> sudo ip link add GREEN type vrf table 11000
sharpd@eva ~/f/t/topotests (multiple_connected_installs)> sudo ip link set GREEN up
sharpd@eva ~/f/t/topotests (multiple_connected_installs)> sudo ip link set dummy7 master GREEN
sharpd@eva ~/f/t/topotests (multiple_connected_installs)> vtysh
Hello, this is FRRouting (version 8.4-dev).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
eva# show ip route vrf all
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
VRF GREEN:
C>* 4.5.6.7/32 is directly connected, dummy7, 00:00:05
VRF default:
K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:01:03
C>* 192.168.119.0/24 is directly connected, enp39s0, 00:01:03
eva# exit
sharpd@eva ~/f/t/topotests (multiple_connected_installs)> sudo ip link set dummy7 nomaster
sharpd@eva ~/f/t/topotests (multiple_connected_installs)> sudo vtysh -c "show ip route vrf all"
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
projects / matthieu / frr.git / log