With v6 interface based peering, we send the global as well as the LL address
as nexthops to the peer. When either of these were removed on the interface
we were not necessarily resetting the connection. Leaving bgp in a state
where the peer had reachability for addresses that are no longer in use.
Modify the code that when we receive an interface address deletion
event. Check to see that we are using the v6 address as nexthops
for that peer and if so, tell it to reset.
I initially struggled with a hard reset of the peer or a clear but
choose to follow other places in the code that we noticed address
changes that resulted in hard resets.
Ticket: #2799568
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When a regular access-list is updated, we should update references to
regular access-lists, not as-path access-lists.
Fixes#9707.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Deleting a mesh-group member no longer deletes the mesh-group.
Complete bug description at:
https://github.com/FRRouting/frr/issues/9664
Signed-off-by: Adriano Marto Reis <adrianomarto@gmail.com>
This `XFREE()` call is in plainly in the wrong spot. `rp_all` (the
224.0.0.0/4 entry) isn't supposed to be free'd ever, and the
conditional above makes quite clear that it remains in use.
It may be possible to exploit this as a heap corruption bug, maybe even
as RCE. I haven't tried; I randomly noticed this while working on the
BSM code. Luckily this code is only run by the CLI for the clear
command, so the surface is very small.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The paf data structure is stored based upon an internal
bgp enum. The code is looking over all AFI/SAFI's and
doing a paf_af_find which then calls afindex to find
the right paf structure. Let's just loop over the
peer->peer_af_array[] and cut straight to the chase.
Under some loads the paf_af_find was taking up 6%
of the run time. This removes it entirely.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The ospf6 router-id is provided by order of preference by:
ospf6d itself if the "ospf6 router-id X.X.X.X" command is set.
- zebra. If the "ip router-id X.X.X.X" zebra command is set, the
configured IP is provided as the ID or alternatively the highest
loopback IPv4 address or else the highest interface IPv4 address.
The running ospf6 router-id is stored in ospf6->router-id.
ospf6->router-id can change in the following conditions:
- A configuration change provides a new router-id value according to
the above rules. ospf6->router-id is updated to the new value if
there is no adjacency in FULL state. Otherwise, the ospf6d process
must be restarted to take the new router-id into account.
- On startup of both zebra and ospf6d, if ospf6d has not yet received a
valid router-id, ospf6d->router-id is set to 0 (i.e. 0.0.0.0). Then,
zebra notifies ospf6d that the router-id is available.
At ospf6->router-id, the current behavior of ospf6d is the following:
- The self generated LSAs that refer to the previous router-id as the
advertising router are kept.
- Self generated LSAs are created with router-id value.
- LSAs from the redistribution that refer to the previous router-id are
kept and no new redistribution LSAs are created.
As a consequence, the routers in the ospf6 areas will get incorrect
LSAs and might not be able to install prefixes of those LSAs into their
RIB.
This fix solves this issue by resetting the areas and the redistribution
when ospf6->router-id updated.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The typesafe containers have been around for quite a while now and
haven't gone up in a blaze of flames, so let's add a "strong
recommendation" to use them for new code and refactors.
For the nhrpd custom lists I'm already working to remove them; meanwhile
the old skiplists are primarily used in RFAPI (4 users outside of that),
so those could be next.
What remains are the old `list_*` and `hash_*`, which have >300 and >100
users respectively, making them a much harder problem to tackle. And
the new hash implementation doesn't have the same level of
debug/introspection yet (it's on my TODO.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
following command: show bgp l2vpn evpn rd all tags
does not append rd contexts one after the other
before:
dut-vm# show bgp l2vpn evpn rd all tags
Network Next Hop In tag/Out tag
Route Distinguisher: 65000:999
*> [5]:[0]:[24]:[10.40.1.0]
10.209.36.1 Route Distinguisher: 65000:1000
*> [5]:[0]:[24]:[10.40.1.0]
10.209.36.1
Displayed 2 out of 2 total prefixes
after:
dut-vm# show bgp l2vpn evpn rd all tags
Network Next Hop In tag/Out tag
Route Distinguisher: 65000:999
*> [5]:[0]:[24]:[10.40.1.0]
10.209.36.1
Route Distinguisher: 65000:1000
*> [5]:[0]:[24]:[10.40.1.0]
10.209.36.1
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
