Donald Sharp [Tue, 5 Apr 2022 13:26:18 +0000 (09:26 -0400)]
tests: Fix test_multicast_pim_sm_topo3.py from generating a support bundle
The test_multicast_pim_sm_topo3.py test is both spending extra time
looking for state that will never occurr but also generating a support
bundle when it doesn't find it. Fix the test to come to the correct
solution faster.
Donald Sharp [Tue, 29 Mar 2022 14:55:34 +0000 (10:55 -0400)]
zebra: Allow multiple connected routes to be choosen for kernel routes
This bug should only really affect kernel routes. To reproduce:
a) Have multiple connected routes that point to the same prefix
swp8 up default 169.254.0.250/30
swp9 up default 169.254.0.250/30
b) Have a kernel route that uses one of those connected routes
7.6.2.8 via 169.254.0.249 dev swp8 proto static
(But have it choose a non-selected connected nexthop)
c) Introduce an event that causes the rib table to be reprocessed,
say a unrelated interface going up / down
This causes the route to be lost with this message:
2022/03/28 21:21:53 ZEBRA: [YXCJP-0WZWV] netlink_nexthop_msg_encode: ID (3454): 169.254.0.249, via swp8(1383) vrf default(0)
2022/03/28 21:21:53 ZEBRA: [YF2E6-J60JH] nexthop_active: 169.254.0.249, via swp8 given ifindex does not match nexthops ifindex found found: directly connected, swp9
Effectively the nexthop that zebra is choosing would not be the one
that the kernel route has choosen and FRR removes the route:
022/03/28 21:21:53 ZEBRA: [NM15X-X83N9] rib_process: (0:254):7.6.2.8/32: rn 0x56042e632e90, removing re 0x56042e6316e0
2022/03/28 21:21:53 ZEBRA: [Y53JX-CBC5H] rib_unlink: (0:254):7.6.2.8/32: rn 0x56042e632e90, re 0x56042e6316e0
2022/03/28 21:21:53 ZEBRA: [KT8QQ-45WQ0] rib_gc_dest: (0:?):7.6.2.8/32: removing dest from table
What is happening?
Zebra is not looking at all connected routes and if any of them
would have the appropriate ifindex and just blindly rejecting
the route.
So when nexthop resolution happens and it matches a connected
route and the dest->selected nexthop ifindex does not match, let's sort
through the rest of them and see if any of them match and if so
let's keep the route.
David Lamparter [Thu, 7 Apr 2022 12:44:23 +0000 (14:44 +0200)]
vtysh: remove extraneous newline
vtysh_client_execute() expects just a string without a newline; the
newline is passed through and ends up in logging output where newlines
are not quite wanted.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Since additional information such as block_bits_length is needed to
generate SIDs properly, the type of elements in srv6_locator_chunks
list is extended from "struct prefix_ipv6 *" to
"struct srv6_locator_chunk *". Even in terms of variable name,
"struct srv6_locator_chunk *" is appropriate.
ipv6 mld last-member-query-count (1-255)
This command can be use to tune the number of Multicast-Address- Specific Queries
sent before the router assumes there are no remaining listeners for an address on a link.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
ipv6 mld query-max-response-time <1-65535>
This command can be use to tune the max response time for general queries.
The number of seconds represented by the [Query Response Interval] must be less than the [Query Interval]
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
The entire `case NEXTHOP_TYPE_IPV6_IFINDEX:` block here was a bit of a
tripwire to stumble over, since there was no indication at all that this
concerns RFC5549 nexthop handling. So it got mis-adapted for PIM IPv6
support.
Clarify this a whole bunch that this is for v4-over-v6 nexthop mangling,
and nothing else.
This should really also use neighbor's secondary address lists for the
lookup, but that is probably going to break compatibility with other
boxes that don't include v6 addrs in v4 hellos and needs further
machinery to do properly, so for now just leave a breadcrumb.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
pimd: fix pim_instance NULL deference in pim_vxlan_mlag_update
Fixing the below coverity issue.
>>> CID 1515545: (NULL_RETURNS)
>>> Dereferencing a pointer that might be "NULL" "pim" when calling "pim_vxlan_set_peerlink_rif".
902 pim_vxlan_set_peerlink_rif(pim, NULL);
Adding show ipv6 pim join and show ipv6 pim vrf all join
CLIs to display pim join related information and
formatted the json output for "show ip pim join" and
"show ip pim vrf all join" commands.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Adding show ipv6 pim interface and show ipv6 pim vrf all interface
CLIs to display pim enabled interface informations and
formatted the json output for "show ip pim interface" and
"show ip pim vrf all interface" commands.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Donald Sharp [Thu, 31 Mar 2022 17:07:06 +0000 (13:07 -0400)]
pimd: Send immediate join( with possible SG RPT prune bit set
When pimd has this setup:
src ----- rtr ------ receiver
|
rp
And the receiver sends a *,G join to rtr. When the
src starts sending a S,G, rtr can wait up to one join/prune
interval before sending a S,G rpt prune. This interval
causes the pimreg device to be in the S,G OIL as that the
RP does not know to prune this leg off.
rtr receives a *,G igmp join, sends a *,G join towards the rp
rtr receives a S,G packet <WRVIFWHOLE>
creates the S,G upstream, sends the register packet to the rp
the rp sees that it still has downstream interest so it forwards the packet on
After (up to 60 seconds ) the rtr, sends the normally scheduled join for
the G and sends the S,GRPT prune as part of it.
What is being done to fix it:
In wrvifwhole handling, when pimd detects that this is the FHR
and is not the RP *and* the incoming interface for the *,G
is different than the incomding interface for the S,G immediately
send a single join packet for the G( which will have the S,G RPT
prune in it ). Only do this on the first time receiving the
WRVIFWHOLE.
Ticket: #2755650 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Donald Sharp [Fri, 1 Apr 2022 12:47:38 +0000 (08:47 -0400)]
tests: Reduce some pim test timings to more manageable levels
a) Remove the retry mechanism to continue looking for 75%
of the time for pim code.
This alone saves a bunch of time in tests that use lib/pim.py
Effectively all the times given for retry are already long
enough. Additionally some tests are gathering data with
the expectation that they will not find data so the entire
time is being taken up in retry's. Extending the retry
mechanism makes this even worse. This is especially bad
for pim in that keep alive timers are counting down and
state can be removed due to excessive time waiting.
b) Reduce verify verify_multicast_traffic from 40 seconds
to 20 seconds to gather traffic data.
A bunch of tests are doing this:
a) gather pre test start traffic data( taking about 70
seconds to run, because a bunch of time it was looking
for data that does not exist yet)
b) run a change to introduce a different traffic flow
c) gather post test traffic data ( taking about 70
seconds to run )
Why does this matter? Tests were iterating through
all the different routers looking for traffic flow
as well as different mroute state. This is against
the keepalive timer of 210 seconds. It does not take
long before the stream can be removed and the test is
still looking for data that is no longer there due
to state timeout.
The multicast_pim_sm_topo3/test_multicast_pim_sm_topo3.py
test reduced run time from 398 seconds to 297 seconds.
Greatly reducing keepalive timeout problems.
"no ead-es-route-target export RT":
Since existance is already checked in `bgp_evpn_ead_es_rt_cmd`
with `bgp_evpn_rt_matches_existing()`, there MUST be a deleting
node in evpn's `bgp_mh_info->ead_es_export_rtl` list.
Just modify the check for deleting node to an `assert`.
Donald Sharp [Thu, 31 Mar 2022 19:56:24 +0000 (15:56 -0400)]
isisd, lib, ospfd, pathd: Null out free'd pointer
The commands:
router isis 1
mpls-te on
no mpls-te on
mpls-te on
no mpls-te on
!
Will crash
Valgrind gives us this:
==652336== Invalid read of size 8
==652336== at 0x49AB25C: typed_rb_min (typerb.c:495)
==652336== by 0x4943B54: vertices_const_first (link_state.h:424)
==652336== by 0x493DCE4: vertices_first (link_state.h:424)
==652336== by 0x493DADC: ls_ted_del_all (link_state.c:1010)
==652336== by 0x47E77B: isis_instance_mpls_te_destroy (isis_nb_config.c:1871)
==652336== by 0x495BE20: nb_callback_destroy (northbound.c:1131)
==652336== by 0x495B5AC: nb_callback_configuration (northbound.c:1356)
==652336== by 0x4958127: nb_transaction_process (northbound.c:1473)
==652336== by 0x4958275: nb_candidate_commit_apply (northbound.c:906)
==652336== by 0x49585B8: nb_candidate_commit (northbound.c:938)
==652336== by 0x495CE4A: nb_cli_classic_commit (northbound_cli.c:64)
==652336== by 0x495D6C5: nb_cli_apply_changes_internal (northbound_cli.c:250)
==652336== Address 0x6f928e0 is 272 bytes inside a block of size 320 free'd
==652336== at 0x48399AB: free (vg_replace_malloc.c:538)
==652336== by 0x494BA30: qfree (memory.c:141)
==652336== by 0x493D99D: ls_ted_del (link_state.c:997)
==652336== by 0x493DC20: ls_ted_del_all (link_state.c:1018)
==652336== by 0x47E77B: isis_instance_mpls_te_destroy (isis_nb_config.c:1871)
==652336== by 0x495BE20: nb_callback_destroy (northbound.c:1131)
==652336== by 0x495B5AC: nb_callback_configuration (northbound.c:1356)
==652336== by 0x4958127: nb_transaction_process (northbound.c:1473)
==652336== by 0x4958275: nb_candidate_commit_apply (northbound.c:906)
==652336== by 0x49585B8: nb_candidate_commit (northbound.c:938)
==652336== by 0x495CE4A: nb_cli_classic_commit (northbound_cli.c:64)
==652336== by 0x495D6C5: nb_cli_apply_changes_internal (northbound_cli.c:250)
==652336== Block was alloc'd at
==652336== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==652336== by 0x494B6F8: qcalloc (memory.c:116)
==652336== by 0x493D7D2: ls_ted_new (link_state.c:967)
==652336== by 0x47E4DD: isis_instance_mpls_te_create (isis_nb_config.c:1832)
==652336== by 0x495BB29: nb_callback_create (northbound.c:1034)
==652336== by 0x495B547: nb_callback_configuration (northbound.c:1348)
==652336== by 0x4958127: nb_transaction_process (northbound.c:1473)
==652336== by 0x4958275: nb_candidate_commit_apply (northbound.c:906)
==652336== by 0x49585B8: nb_candidate_commit (northbound.c:938)
==652336== by 0x495CE4A: nb_cli_classic_commit (northbound_cli.c:64)
==652336== by 0x495D6C5: nb_cli_apply_changes_internal (northbound_cli.c:250)
==652336== by 0x495D23E: nb_cli_apply_changes (northbound_cli.c:268)
Let's null out the pointer. After this change. Valgrind no longer reports issues
and isisd no longer crashes.
Fixes: #10939 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Trey Aspelund [Thu, 31 Mar 2022 16:35:18 +0000 (16:35 +0000)]
zebra: don't send RAs w/o LLv6 or on bridge-ports
It's confusing for a user to see 'Tx RA failed' in the logs when
they've enabled RAs (either through interface config or BGP unnumbered)
on an interface that can't send them. Let's avoid sending RAs on
interfaces that are bridge_slaves or don't have a link-local address,
since they are the two of the most common reasons for RA Tx failures.
David Lamparter [Thu, 31 Mar 2022 15:35:32 +0000 (17:35 +0200)]
build: stick `-g` into LDFLAGS
Without `-g` in LDFLAGS we won't get debug info even if it's enabled in
CFLAGS. Since we're controlling debug info through CFLAGS, there's no
harm in always having `-g` in LDFLAGS.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Javier Garcia [Thu, 10 Mar 2022 15:32:29 +0000 (16:32 +0100)]
docker: Adding support for ubi-8 images.
- Create frr docker container based in new Red Hat Universal Base
Images.
- This build a docker container based in ubi-8.
- Need to get the devel packages from centos-8 stream repos.
- Centos-8 stream repos added : base, appstream, powertools and epel
Signed-off-by: Javier Garcia <javier.martin.garcia@ibm.com>
projects / mirror_frr.git / log