Recent commit 4d0e7a49cf
brought in changes that moved a check for ret up
in the code, caused some code to be left around
and be effectively dead since it would never be called.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
```
==5445==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x7ff4c6bedb19 bp 0x7ffc95f2e400 sp 0x7ffc95f2e3c0 T0)
==5445==The signal is caused by a READ memory access.
==5445==Hint: address points to the zero page.
#0 0x7ff4c6bedb19 in hash_iterate lib/hash.c:246
#1 0x5618f41f5f59 in bgp_evpn_nh_finish bgpd/bgp_evpn_mh.c:4663
#2 0x5618f41dcbe8 in bgp_evpn_vrf_delete bgpd/bgp_evpn.c:7336
#3 0x5618f43bdd35 in bgp_delete bgpd/bgpd.c:4098
#4 0x5618f417ef6e in bgp_exit bgpd/bgp_main.c:206
#5 0x5618f417ef6e in sigint bgpd/bgp_main.c:164
#6 0x7ff4c6cac6c4 in frr_sigevent_process lib/sigevent.c:117
#7 0x7ff4c6cd8258 in event_fetch lib/event.c:1767
#8 0x7ff4c6c0dcbc in frr_run lib/libfrr.c:1230
#9 0x5618f418080d in main bgpd/bgp_main.c:555
#10 0x7ff4c670c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#11 0x7ff4c670c304 in __libc_start_main_impl ../csu/libc-start.c:360
#12 0x5618f417ea20 in _start (/usr/lib/frr/bgpd+0x2e4a20)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV lib/hash.c:246 in hash_iterate
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The type of the val field in ecommunity_val is used inconsistently
in a number of places. It should be defined as uint8_t.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
When we get a update on a route that we already have information on
from another router and that route has been leaked ensure that
we do not crash when trying to releak the code when we may want
to modify the as path.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When a prefix in a vrf is imported into evpn as a type5,
copy the asn of the source to make sure it is reflected
in the target vrf.
Ticket: cumuluslinux-2554562
Signed-off-by: Don Slice <dslice@nvidia.com>
When we leak routes and are using a different ASN in the
source vrf from the target vrf, it's possible we could
create loops because of an incomplete as-path (missing
the source vrf ASN). This fix adds the source vrf ASN and
stops the importing of a BGP prefix that has the target
ASN in the as-path in the source vrf.
Signed-off-by: Don Slice <dslice@nvidia.com>
While it's okay to allow overwriting the ASN of a bgp vrf/instance
that is either hidden or automatically created, it's dangerous to
allow it on explicitly defined instances. If that were allowed,
a typo entering the bgp config could take down existing peering,
which would be a bad thing.
Signed-off-by: Don Slice <dslice@nvidia.com>
1. bgp coredump is observed when we delete default bgp instance
when we have multi-vrf; and route-leaking is enabled between
default, non-default vrfs.
Removing default router bgp when routes leaked between non-default vrfs.
- Routes are leaked from VRF-A to VRF-B
- VPN table is created with auto RD/RT in default instance.
- Default instance is deleted, we try to unimport the routes from all VRFs
- non-default VRF schedules a work-queue to process deleted routes.
- Meanwhile default bgp instance clears VPN tables and free the route
entries as well, which are still referenced by non-default VRFs which
have imported routes.
- When work queue process starts to delete imported route in VRF-A it cores
as it accesses freed memory.
- Whenever we delete bgp in default vrf, we skip deleting routes in the vpn
table, import and export lists.
- The default hidden bgp instance will not be listed in any of the show
commands.
- Whenever we create new default instance, handle it with AS number change
i.e. old hidden default bgp's AS number is updated and also changing
local_as for all peers.
2. A default instance is created with ASN of the vrf with the import
statement.
This may not be the ASN desired for the default table
- First problem with current behavior.
Define two vrfs with different ASNs and then add import between.
starting without any bgp config (no default instance)
A default instance is created with ASN of the vrf with the import
statement.
This may not be the ASN desired for the default table
- Second related problem. Start with a default instance and a vrf in a
different ASN. Do an import statement in the vrf for a bgp vrf instance
not yet defined and it auto-creates that bgp/vrf instance and it inherits
the ASN of the importing vrf
- Handle bgp instances with different ASNs and handle ASN for auto created
BGP instance
Signed-off-by: Kantesh Mundaragi <kmundaragi@vmware.com>
Add counters for redistributed routes, and local aggregates to the
output of "show ip bgp statistics".
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
Use forward references instead of including the main bgpd.h
header in the bgp scripting header to reduce external impact
of changes.
Signed-off-by: Mark Stapp <mjs@cisco.com>
Include SID structure information when removing an SRv6 End.DT4 or End.DT6 SID
from the forwarding plane.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Include SID structure information when installing an SRv6 End.DT6 or End.DT4 SID
in the forwarding plane.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
This is helpful for migrations, etc.
The neighbor is configured with:
```
router bgp 65000
neighbor X local-as 65001 no-prepend replace-as dual-as
```
Neighbor X can use either 65000, or 65001 to peer with.
Closes: https://github.com/FRRouting/frr/issues/13928
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The 'nexthop_set failed, resetting connection - intf' log message
is often seen when peering with BGP peers. This message has been
displayed by introducing a recent fix that extracts the IP/port
information of outgoing connections when peering is not yet
established.
Fix this by separating the update of the socket information from
the call to bgp_zebra_nexthop_set().
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The check for an equivalent bgp pointer makes no sense
in the context of the workqueue as that we have a
work queue per bgp process, as such the bgp pointer
will always be the same as the pqnode.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There is a need to be able to process certain bgp
routes earlier than others. Especially when there
is major trauma going on in the network. Start
the ability for this to happen.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Code was scanning a table then identifying a prefix
that needed to be modified then calling code that
reran bestpath on the entire table again.
If you had multiple items that needed processing
you would end up scanning and setting the entire
table to be scanned multiple times. No bueno.
a) We do not need to reprocess items that are not
being modified.
b) We do not need to walk the entire table multiple
times, we have the data that is needed already.
Modify the code to just call bgp_process on the
interesting nodes.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
