tests: Addition of AutoRP Discovery uncovered broken PIM test
With AutoRP discovery running by default, that adds a new
IGMP group that needs to be accounted for in IGMP output.
For pim.py
The clear IGMP interfaces function is in a broken state. It was
already ignoring any errors and returned true always, but with
the addition of the AutoRP discovery group, you could end up
with a different group order in the json which would cause a key
error making the test fail. For now I just added a check to
avoid the key error.
Uses hardcoded sample AutoRP packets injected in to test
message parsing and proper application of AutoRP learned
RP info. Tests mix of AutoRP and static RP's.
autorp discovery
Enables Auto RP discovery for learning dynamic RP information using the
AutoRP protocol.
autorp announce RP-ADDR [GROUP | group-list PREFIX-LIST]
Enable announcements of a candidate RP with the given group range, or
prefix list of group ranges, to an AutoRP mapping agent.
autorp announce {scope (1-255) | interval (1-65535) | holdtime (0-65535)}
Configure the parameters of the AutoRP announcement messages.
The scope sets the packet TTL.
The interval sets the time between TX of announcements.
The holdtime sets the hold time in the message, the time the mapping
agent should wait before invalidating the candidate RP information.
debug pim autorp
Enable debug logging of the AutoRP protocol
show ip pim [vrf NAME] autorp [json]
Show details of the AutoRP protocol.
To view learned RP info, use the existing command 'show ip pim rp-info'
Perform AutoRP discovery and candidate RP announcements using the
AutoRP protocol.
Mapping agent is not yet implemented, but this feature is not
necessary for FRR to support AutoRP as we only need one AutoRP
mapping agent in the network.
Donald Sharp [Mon, 23 Sep 2024 19:07:28 +0000 (15:07 -0400)]
tests: Add v4/v6 forwarding off/on
There are no tests that ensured that turning off then on
v4 and v6 forwarding actually worked. This does so.
This was found via looking at the code coverage.
bgpd: Delete EVPN VRF instace if it's not a hidden instance only
```
==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
```
isisd: Fix infinity flag not being set successfully
When creating SPF neighbors and calling spf_adj_list_parse_tlv(), the F_ISIS_SPF_ADJ_METRIC_INFINITY flag is only set to a local variable flags and not set to the SPF neighbor sadj->flags. Additionally, the pseudo node metric pseudo_metric is also not reflected in the F_ISIS_SPF_ADJ_METRIC_INFINITY flag, the metric should be checked using sadj->metric.
ospfd: Interface 'ip ospf neighbor-filter' startup config not applied.
When 'ip ospf neighbor-filter <filter-name>' is configured in the startup
configuration, it is in the running configuration but not applied on the
interface.
Donald Sharp [Fri, 20 Sep 2024 14:58:46 +0000 (10:58 -0400)]
zebra: Pass in ZEBRA_ROUTE_MAX instead of true
zebra_nhg_install_kernel takes a route type. We don't
know it at that particular spot but we should not be passing
in `true`. Let's use ZEBRA_ROUTE_MAX to indicate we do not
know, so that the correct thing is done.
tests: adjust topotest after bgp_redistribute_add() fix
In ospf_multi_vrf_bgp_route_leak, the admin distance for the
redistributed ospf route should be 110, and should remain as 110 after
it's imported into another vrf, and then downloaded to zebra.
Before adding an NHLFE entry, zebra calls nhlfe_nexthop_active_ipv4()/nhlfe_nexthop_active_ipv6() to check if there is a corresponding directly connected route for the next hop prefix of the NHLFE. If such a route exists, it directly overwrites the output interface of the NHLFE's next hop with the output interface of the directly connected route. If the output interface of the directly connected route is different from the output interface of the NHLFE's next hop, deleting the NHLFE entry later will fail because nhlfe_nhop_match() cannot find the same next hop address and output interface, leading to an NHLFE entry leak.
Establishing neighbors in ISIS only requires the existence of the neighbor's IP address and does not need the neighbor's IP address to be in the same subnet as the local IP address. When zebra creates an adjacency label entry, it uses the neighbor's IP address as the next hop. If the neighbor's IP address is not in the same subnet as the local IP address and there is a local directly connected route with the neighbor's IP address prefix, it will result in an issue where the corresponding adjacency label entry in zebra cannot be deleted.
We cannot enforce that ISIS must establish neighbors using IPv4 and IPv6 addresses in the same subnet, but we can ensure that IPv4 or IPv6 addresses in different subnets do not create adjacency labels.
ospfd: Fix heap corruption vulnerability when parsing SR-Algorithm TLV
When parsing the SR-Algorithm TLV in the OSPF Router Information Opaque
LSA, assure that not more than the maximum number of supported
algorithms are copied from the TLV.
Donald Sharp [Mon, 19 Jul 2021 14:29:42 +0000 (10:29 -0400)]
bgpd: Fixup crash when leaking from default vrf for mpls vpn's
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.
Don Slice [Wed, 9 Jun 2021 20:50:20 +0000 (16:50 -0400)]
bgpd: copy source vrf ASN to leaked route and block loops
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.
Don Slice [Fri, 4 Jun 2021 20:22:24 +0000 (16:22 -0400)]
bgpd: do not allow override ASN unless hidden or auto-created
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.
Don Slice [Fri, 16 Jul 2021 18:36:10 +0000 (14:36 -0400)]
bgpd: VRF-Lite fix default bgp delete
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
projects / mirror / frr.git / log