While running MLD conformance test 9.2 core is getting generated.
Test setps:
1. ANVL: Listen (for upto <GeneralQueryRecvWaitTime> seconds) on <AIface-0>.
2. DUT: Send MLD General Query Message.
3. ANVL: Send MLD Report Message to <DIface-0> containing:
• IPv6 Source Address field set to link-local IPv6 Address of HOST-1
• IPv6 Destination Address field set to <McastAddrGroup>
• MLD Multicast Address field set to <McastAddrGroup>.
4. ANVL: Wait for <ProcessTime> seconds for DUT to process and add <Mcas- tAddrGroup> to its Multicast Address list.
5. ANVL: Send MLD General Query Message to <DIface-0> containing:
• IPv6 Source Address field set to link-local IPv6 Address of RTR-1 which is numerically less than the link-local IPv6 unicast address of <DIface-0>
• IPv6 Destination Address field set to link-scope all-nodes multicast address.
6. ANVL: Send MLD Multicast-Address-Specific Query Message to <DIface-0> containing:
• IPv6 Source Address field set to link-local IPv6 Address of RTR-1
• IPv6 Destination Address field set to <McastAddrGroup>
• MLD Multicast Address field set to <McastAddrGroup>
• MLD Maximum Response Delay field value set to 0.
7. ANVL: Verify that the Maximum Response Delay timer for <McastAd- drGroup> is set to zero.
While running above test, when group specific query is received we start gm_t_sg_expire timer.
Once this timer expires, we clear the corresponding entry.
During this sg->state was still set to JOIN. This happened because receiver went down without sending leave.
Added a condition to update the sg->state before starting the timer.
If receiver goes down without sending leave we will update sg->state to GM_SG_JOIN_EXPIRING or GM_SG_NOPRUNE_EXPIRING based on previous state.
If we receive a join then sg->state will be refreshed and will be updated to JOIN state.
Fixes: #13387
Signed-off-by: Abhishek N R <abnr@vmware.com>
The cli "show ip pim nexthop json" gives the RPF information.
However it doesn't give PIM enable status on the nexthop interface.
Added pimEnabled field in this clis,
this will tell if PIM is enabled or not on the nexthop interface.
Example:
frr# show ip pim nexthop
Number of registered addresses: 1
Address Interface Nexthop
108.0.0.2 ens224 108.0.0.2
frr# show ip pim nexthop json
{
"108.0.0.2":{
"address":"108.0.0.2",
"nexthops":[
{
"interface":"ens224",
"pimEnabled":true,
"nexthop":"108.0.0.2"
}
]
}
}
frr# configure terminal
frr(config)# int ens224
frr(config-if)# no ip pim
frr(config-if)# end
frr# show ip pim nexthop json
{
"108.0.0.2":{
"address":"108.0.0.2",
"nexthops":[
{
"interface":"ens224",
"pimEnabled":false,
"nexthop":"108.0.0.2"
}
]
}
}
Signed-off-by: Sarita Patra <saritap@vmware.com>
This commit ensures proper cleanup by deleting the gm_join_list when a PIM interface is deleted. The gm_join_list was previously not being freed, causing a memory leak.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in multicast_mld_join_topo1.test_multicast_mld_local_join/r1.asan.pim6d.28070
=================================================================
==28070==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x56230373dd6b in qcalloc lib/memory.c:105
#2 0x56230372180f in list_new lib/linklist.c:49
#3 0x56230361b589 in pim_if_gm_join_add pimd/pim_iface.c:1313
#4 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868
#5 0x562303767280 in nb_callback_create lib/northbound.c:1235
#6 0x562303767280 in nb_callback_configuration lib/northbound.c:1579
#7 0x562303768a1d in nb_transaction_process lib/northbound.c:1710
#8 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104
#9 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137
#10 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49
#11 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88
#12 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991
#13 0x5623036c5f1b in cmd_execute_command lib/command.c:1053
#14 0x5623036c6392 in cmd_execute lib/command.c:1221
#15 0x5623037e75da in vty_command lib/vty.c:591
#16 0x5623037e7a74 in vty_execute lib/vty.c:1354
#17 0x5623037f0253 in vtysh_read lib/vty.c:2362
#18 0x5623037db4e8 in event_call lib/event.c:1995
#19 0x562303720f97 in frr_run lib/libfrr.c:1213
#20 0x56230368615d in main pimd/pim6_main.c:184
#21 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 192 byte(s) in 4 object(s) allocated from:
#0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x56230373dd6b in qcalloc lib/memory.c:105
#2 0x56230361b91d in gm_join_new pimd/pim_iface.c:1288
#3 0x56230361b91d in pim_if_gm_join_add pimd/pim_iface.c:1326
#4 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868
#5 0x562303767280 in nb_callback_create lib/northbound.c:1235
#6 0x562303767280 in nb_callback_configuration lib/northbound.c:1579
#7 0x562303768a1d in nb_transaction_process lib/northbound.c:1710
#8 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104
#9 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137
#10 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49
#11 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88
#12 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991
#13 0x5623036c5f1b in cmd_execute_command lib/command.c:1053
#14 0x5623036c6392 in cmd_execute lib/command.c:1221
#15 0x5623037e75da in vty_command lib/vty.c:591
#16 0x5623037e7a74 in vty_execute lib/vty.c:1354
#17 0x5623037f0253 in vtysh_read lib/vty.c:2362
#18 0x5623037db4e8 in event_call lib/event.c:1995
#19 0x562303720f97 in frr_run lib/libfrr.c:1213
#20 0x56230368615d in main pimd/pim6_main.c:184
#21 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 96 byte(s) in 4 object(s) allocated from:
#0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x56230373dd6b in qcalloc lib/memory.c:105
#2 0x562303721651 in listnode_new lib/linklist.c:71
#3 0x56230372182b in listnode_add lib/linklist.c:92
#4 0x56230361ba9a in gm_join_new pimd/pim_iface.c:1295
#5 0x56230361ba9a in pim_if_gm_join_add pimd/pim_iface.c:1326
#6 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868
#7 0x562303767280 in nb_callback_create lib/northbound.c:1235
#8 0x562303767280 in nb_callback_configuration lib/northbound.c:1579
#9 0x562303768a1d in nb_transaction_process lib/northbound.c:1710
#10 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104
#11 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137
#12 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49
#13 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88
#14 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991
#15 0x5623036c5f1b in cmd_execute_command lib/command.c:1053
#16 0x5623036c6392 in cmd_execute lib/command.c:1221
#17 0x5623037e75da in vty_command lib/vty.c:591
#18 0x5623037e7a74 in vty_execute lib/vty.c:1354
#19 0x5623037f0253 in vtysh_read lib/vty.c:2362
#20 0x5623037db4e8 in event_call lib/event.c:1995
#21 0x562303720f97 in frr_run lib/libfrr.c:1213
#22 0x56230368615d in main pimd/pim6_main.c:184
#23 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x56230373dd6b in qcalloc lib/memory.c:105
#2 0x56230361b91d in gm_join_new pimd/pim_iface.c:1288
#3 0x56230361b91d in pim_if_gm_join_add pimd/pim_iface.c:1326
#4 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868
#5 0x562303767280 in nb_callback_create lib/northbound.c:1235
#6 0x562303767280 in nb_callback_configuration lib/northbound.c:1579
#7 0x562303768a1d in nb_transaction_process lib/northbound.c:1710
#8 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104
#9 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137
#10 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49
#11 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88
#12 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991
#13 0x5623036c5f6f in cmd_execute_command lib/command.c:1072
#14 0x5623036c6392 in cmd_execute lib/command.c:1221
#15 0x5623037e75da in vty_command lib/vty.c:591
#16 0x5623037e7a74 in vty_execute lib/vty.c:1354
#17 0x5623037f0253 in vtysh_read lib/vty.c:2362
#18 0x5623037db4e8 in event_call lib/event.c:1995
#19 0x562303720f97 in frr_run lib/libfrr.c:1213
#20 0x56230368615d in main pimd/pim6_main.c:184
#21 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f3605dbfd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x56230373dd6b in qcalloc lib/memory.c:105
#2 0x562303721651 in listnode_new lib/linklist.c:71
#3 0x56230372182b in listnode_add lib/linklist.c:92
#4 0x56230361ba9a in gm_join_new pimd/pim_iface.c:1295
#5 0x56230361ba9a in pim_if_gm_join_add pimd/pim_iface.c:1326
#6 0x562303642247 in lib_interface_gmp_address_family_static_group_create pimd/pim_nb_config.c:2868
#7 0x562303767280 in nb_callback_create lib/northbound.c:1235
#8 0x562303767280 in nb_callback_configuration lib/northbound.c:1579
#9 0x562303768a1d in nb_transaction_process lib/northbound.c:1710
#10 0x56230376904a in nb_candidate_commit_apply lib/northbound.c:1104
#11 0x5623037692ba in nb_candidate_commit lib/northbound.c:1137
#12 0x562303769dec in nb_cli_classic_commit lib/northbound_cli.c:49
#13 0x56230376fb79 in nb_cli_pending_commit_check lib/northbound_cli.c:88
#14 0x5623036c5bcb in cmd_execute_command_real lib/command.c:991
#15 0x5623036c5f6f in cmd_execute_command lib/command.c:1072
#16 0x5623036c6392 in cmd_execute lib/command.c:1221
#17 0x5623037e75da in vty_command lib/vty.c:591
#18 0x5623037e7a74 in vty_execute lib/vty.c:1354
#19 0x5623037f0253 in vtysh_read lib/vty.c:2362
#20 0x5623037db4e8 in event_call lib/event.c:1995
#21 0x562303720f97 in frr_run lib/libfrr.c:1213
#22 0x56230368615d in main pimd/pim6_main.c:184
#23 0x7f360461bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 400 byte(s) leaked in 11 allocation(s).
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Problem:
ANVL Conformance test case 7.31 failed because DUT after
receiving MLD Done msg and a query message with lower adddress,
DUT did not keep on sending the group specific queries since it moved
to non-querier state.
As per RFC 2710 s4 p7, DUT is supposed to keep sending the group
specific queries until either it receives the membership report or
there is no response even after last member query is sent.
Fix:
Whenever group specific queries are sent out we are checking if
the self node is querier, if not it does not sends this query out.
This check is preventing the continuation of the last queries
which must be sent out although the self node is not the querier.
Hence removing the check from the api gm_trigger_specific_query
and adding in the caller to make sure this event is only added
for queriers. This will make sure the last member queries are sent out
even during the transition phase.
Also earlier this event was getting added for non-querier
as well which is redundant since queries were not required to be sent
out by non-queriers.
Issue: #13539
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Problem:
When ipv6 pim configuration is removed from the IIF on FHR node,
if we wait for RST timer to expire and then add the ipv6 pim configuration on the IIF again,
it is seen that pimreg is not getting added due to which null register wont be sent,
the register flag state also remains NO_INFO forever instead of RegPrune.
The reason for this is, when RST timer expires and IIF is unknown for the (S,G) upstream,
the FHR state is not reset due to which when the RP becomes reachable,
upstream state changes from NotJoined to Join but the register suppress timer could not be started
since we see there is no change in FHR state.
Fix:
When the Register Timer expires and the reg state is set to PIM_REG_NOINFO,reset the FHR flag,
so that when the RP becomes reachable can be because of config change or RP not reachable,
it is able to resume its duty.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
We were using the pim interface socket to send the register
stop msg, it works fine in cases where the interface on which
register msg is received and the interface on which the register-stop
msg is supposed to be sent is the same.
But when the interfaces are different, msg send fails because
the outgoing interface is not right.
Fixes: #13774
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Max response time in the code is being used as decisecond but the user input is taken in millisecond.
Also yang expects the field to be in decisecond.
The below condition in yang is failing due to the mismatch in units.
```
units deciseconds;
must ". <= ../query-interval * 10";
```
Issue: #11892
Signed-off-by: Abhishek N R <abnr@vmware.com>
Problem:
-------
The cli "show ipv6 pim state" is not displaying when outgoing
interface list is empty.
This is fixed now.
Before Fix:
----------
frr# show ipv6 pim state json
{
"ffaa::5":{
"1100::10":{
"ens224":{
},
"installed":1,
"isRpt":false,
"refCount":1,
"oilListSize":0,
"oilRescan":0,
"lastUsed":0,
"packetCount":40,
"byteCount":3080,
"wrongInterface":1
}
}
}
frr# show ipv6 pim state
Codes: J -> Pim Join, I -> MLD Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN, M -> Muted
Active Source Group RPT IIF OIL
After fix:
---------
Case 1:
- "show ipv6 pim state" output for 1 mroute with 1 oil.
frr# show ipv6 pim state
Codes: J -> Pim Join, I -> MLD Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN, M -> Muted
Active Source Group RPT IIF OIL
1 1100::10 ffaa::5 n ens224 ens256( J )
Case 2:
- "show ipv6 pim state" output for 1 mroute with multiple oil.
frr# show ipv6 pim state
Codes: J -> Pim Join, I -> MLD Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN, M -> Muted
Active Source Group RPT IIF OIL
1 1100::10 ffaa::5 n ens224 ens192( J )
ens256( J )
Case 3:
- "show ipv6 pim state" output for 1 mroute with no oil
frr# show ipv6 pim state
Codes: J -> Pim Join, I -> MLD Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN, M -> Muted
Active Source Group RPT IIF OIL
1 1100::10 ffaa::5 n ens224
Case 4:
- "show ipv6 pim state" output for multiple mroute with multiple oil
frr# show ipv6 pim state
Codes: J -> Pim Join, I -> MLD Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN, M -> Muted
Active Source Group RPT IIF OIL
1 * ff05::2 y ens224 pim6reg(I )
ens192(I )
1 * ffaa::5 y ens224 pim6reg(I )
ens192(I )
Issue: #13070
Signed-off-by: Sarita Patra <saritap@vmware.com>
The vrf name should be separated when it is displayed. And remove
unnecessary space after number.
Before:
```
pim_upstream_sg_running: (100.100.1.100,232.100.100.100)x is not installed in mroute
pim_upstream_del(pim_ifchannel_delete): Delete (100.100.1.100,232.100.100.100)[x] ref count: 1 , flags: 1048585 c_oil ref count 2 (Pre decrement)
```
After:
```
pim_upstream_sg_running: (100.100.1.100,232.100.100.100)[x] is not installed in mroute
pim_upstream_del(pim_ifchannel_delete): Delete (100.100.1.100,232.100.100.100)[x] ref count: 1, flags: 1048585 c_oil ref count 2 (Pre decrement)
```
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Consider LHR in `SSM` case, and its `oif` goes from up to down.
As the `oif` changes down, the `channel_oil` is still wrongly reserved
with `PIM_OIF_FLAG_PROTO_STAR` protocol.
The mechanism of adding `STAR` protocol for <S,G> entry without `oif`
is introduced by commit `2164ed5`, which should be only used for ASM.
PR #13699 wants to clean this `STAR` protocol after the `oif` becomes up
again. That case is for SSM, as the `oif` changes down, the `channel_oil`
should be removed, so the fix of that PR is wrong.
In `pim_ifchannel_delete()` we should check the `ch->parent` before that
mechanism of adding `STAR` protocol. If `ch->parent` is NULL, we should
skip that mechanism with SSM.
Fixes#13696
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Move the mld/igmp deletion common code to api pim_gm_interface_delete
code for IPv6 deletion(gm_ifp_teardown) for MLD was missing in this flow
Making the code common fixes this too.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Rename pim_cmd_interface_delete to pim_pim_interface_delete
and move the api to pimd/pim_iface.c
Changed the return type of the api from int to void.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Move pim_if_membership_clear api from pimd/pim_nb_config.c
to pimd/pim_iface.c
Also fixed curly braces warning
WARNING: braces {} are not necessary for single statement blocks
1773: FILE: /tmp/f1-127504/pim_iface.c:1773:
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Receiver---LHR---RP
Problem:
In LHR, ipv6 pim state remains after MLD prune received.
Root Cause:
When LHR receives join, it creates (*,G) channel oil with
oil_ref_count = 2. The channel_oil is used by gm_sg sg->oil
and upstream->channel_oil.
When LHR receives prune, currently upstream->channel_oil is
deleted and gm_sg sg->oil still present. Due to this channel_oil
is still present with oil_ref_count = 1
Fix:
When LHR receives prune, upstream->channel_oil and pim_sg sg->oil
needs to be deleted.
Issue: #11249
Signed-off-by: Sarita Patra <saritap@vmware.com>
Currently, in PIM Northbound, when a path to RP is not found during config apply, we are treating this as a NB_ERR_INCONSISTENCY.
However, there are two issues with this approach:
When OSPF or IGP convergence is completed, it is possible that the RPF check will succeed.
If we have multiple groups and RPs (e.g. 50 RPs), we will receive 50 logs with inconsistency errors.
example:
2023/05/27 22:57:45 PIM: [G822R-SBMNH] config-from-file# ip pim rp 192.168.100.1 239.100.0.0/28 2023/05/27 22:57:45
PIM: [VAKV3-NMY7B][EC 100663337] error processing configuration change: error [internal inconsistency] event [apply]
operation [create] xpath [/frr-routing:routing/control-plane-protocols/control-plane-protocol[type='frr-pim:pimd']
[name='pim'][vrf='default']/frr-pim:pim/address-family[address-family='frr-routing:ipv4']/frr-pim-rp:rp/static-rp/rp-list
[rp-address='192.168.100.1']/group-list[.='239.100.0.0/28']] message: No Path to RP address specified: 192.168.100.1
Issue: #13620
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
`pimregX` of specific vrf can be deleted from kernel after this vrf
is deleted. However, then `pimdregX` will never come back to
kernel after adding it ( the same vrf ) back. That is to say, it exists
only in daemon, but not in kernel.
The root cause is this `pimregX` is not really deleted for its special
usage, and `pim_if_create_pimreg()` wants reusing it.
I have tried 4 solutions:
1. Remove the `configured` flag of `pimregX`, allow its deletion.
A few timers still use `pimregX` after its deletion. So, not adopted.
2. Remove `pimregX` by vrf hook in `pim_instance_terminate()`.
It has no vrf id there. So, not adopted.
3. Reuse `pimregX` in `pim_if_create_pimreg()`.
If `pim->regiface->info` is true, then reuse old `pimregX` and only call
`pim_if_add_vif()` to install it into kernel. But at that time, it maybe
is in default VRF. The `pim_zebra_interface_set_master()` doesn't work
at that time because it shouldn't wait there for its changing into
correct VRF. So, not adopted.
4. Not reuse it.
If `pim->regiface->info` is true, there must have been pim instance with
VRF deleted and created before. Actually delele old one in
`pim_if_create_pimreg()`, then recreate new one.
Finally, this PR adopted the fourth solution.
Fixes#13454
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Problem:
Execute the below commands, pim6d core happens.
interface ens193
ip address 69.0.0.2/24
ipv6 address 8000::1/120
ipv6 mld
ipv6 pim
We see crash only if the interface is not configured, and
we are executing PIM/MLD commands.
RootCause:
Interface ens193 is not configured. So, it will have
ifindex = 0 and mroute_vif_index = -1.
Currently, we don't enable MLD on an interface if
mroute_vif_index < 0. So, pim_ifp->MLD = NULL.
In the API pim_if_membership_refresh(), we are accessing
pim_ifp->MLD NULL pointer which leads to crash.
Fix:
Added NULL check before accessing pim_ifp->MLD pointer in
the API pim_if_membership_refresh().
Issue: #13385
Signed-off-by: Sarita Patra <saritap@vmware.com>
`pim_if_create_pimreg()` need use the `mroute_socket`, so adjust the order.
First call `pim_mroute_socket_enable()`, then call `pim_if_create_pimreg()`.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
When entering some show commands that use json in pimd
when the interface cannot be found do not output non-json
format in that case.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Assume that `pim_ifp` has two ip (v4) addresses, one is primary, the other
is secondary. After remove primary ip, the secondary ip doesn't be promoted,
so `pim_ifp->primary_address` will wrongly be set to "0.0.0.0", it leads to
`pim_sock_delete(ifp)` on this interface.
Add the promotion for primary address.
Fixed#13590
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Some interfaces are special, they have the same `ifindex` with pimreg.
Use macro for `ifindex` of pimreg.
And adjust log.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
`setsockopt()` should be only called once with `MRT_TABLE`
in "enable" case, otherwise it will fail. In current code,
`mroute_socket` of "pim instance" with VRF can't be correctly
closed.
Skip it in the "disable" case to let `mroute_socket` safely
closed.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Coverity complains about these being tainted/untrusted loop boundaries.
The way the code works, it's counting up groups/sources, but keeps
checking against remaining data length in the packet - which is
perfectly fine IMHO. Except Coverity doesn't understand it :(
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Coverity shows a path where the pim instance may
be null. In this code path if we have no pim
vrf there is nothing to do anyway so just return
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently the function `pim_parse_nexthop_update()` clearly
updates nexthop interfaces even as PIM-disabled.
Just correct the wrong comments about those PIM-disabled interfaces
to avoid misleading.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
ZEBRA_IMPORT_CHECK_UPDATE has been gone for more than a year; remove
some leftover dead references to it.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
1. Added interface name, group address and detail option to existing
"show ip igmp groups" so that user can retrieve all the groups
or a particular group for an interface. Detail option shows the source
information for the group. With that, the show command
looks like:
"show ip igmp [vrf NAME$vrf_name] groups [INTERFACE$ifname [GROUP$grp_str]] [detail$detail] [json$json]"
2. Changed pim_cmd_lookup_vrf() to return empty JSON if VRF is not present
3. Changed "detail" option to print non pretty JSON
4. Added interface name and group address to existing
"show ip igmp sources" so that user can retrieve all the sources for
all the groups or, all the sorces for a particular group for an
interface. With that, the show command looks like:
"show ip igmp [vrf NAME$vrf_name] sourcess [INTERFACE$ifname [GROUP$grp_str]] [json$json]"
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
Topology Used:
=============
Cisco---FRR4----FRR2
Initially PIM nbr is down between FRR4----FRR2 from FRR2 side
Cisco is sending BSR packet to FRR4.
Problem Statement:
=================
No shutdown the PIM neighbor on FRR2 towards FRR4.
FRR2, receives BSR packet immediately as the new neighbor
comes up. This BSR packet is having no-forward bit set.
FRR2 is not able to process the BSR packet, and drop the
BSR packet.
Root Cause:
==========
When PIMD comes up, we start BSM timer for 60 seconds.
Here, the value accept_nofwd_bsm is setting to false.
FRR2, when receives no-forward BSR packet, it is getting
accept_nofwd_bsm value as false.
So, it drops, the no-forward BSM packet.
Fix:
===
Set accept_nofwd_bsm as false after first BSM packet received.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Effectively a massive search and replace of
`struct thread` to `struct event`. Using the
term `thread` gives people the thought that
this event system is a pthread when it is not
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This is a first in a series of commits, whose goal is to rename
the thread system in FRR to an event system. There is a continual
problem where people are confusing `struct thread` with a true
pthread. In reality, our entire thread.c is an event system.
In this commit rename the thread.[ch] files to event.[ch].
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
After doing "no ipv6 pim" and "ipv6 pim" on receiver interface in LHR,
mroutes were not created.
When we enable pim after disabling it, we refresh the membership on pim interface.
First we clear the membership on the interface, then we add it back.
For PIMv6 we were only clearing it, membership was not added back. So mroutes were not created.
Now added code to fetch all the local membership information into PIM.
Fixes: #12005, #12820
Signed-off-by: Abhishek N R <abnr@vmware.com>
We have this valgrind trace:
==1125== Invalid read of size 4
==1125== at 0x170A7D: pim_if_delete (pim_iface.c:203)
==1125== by 0x170C01: pim_if_terminate (pim_iface.c:80)
==1125== by 0x174F34: pim_instance_terminate (pim_instance.c:68)
==1125== by 0x17535B: pim_vrf_terminate (pim_instance.c:260)
==1125== by 0x1941CF: pim_terminate (pimd.c:161)
==1125== by 0x1B476D: pim_sigint (pim_signals.c:44)
==1125== by 0x4910C22: frr_sigevent_process (sigevent.c:133)
==1125== by 0x49220A4: thread_fetch (thread.c:1777)
==1125== by 0x48DC8E2: frr_run (libfrr.c:1222)
==1125== by 0x15E12A: main (pim_main.c:176)
==1125== Address 0x6274d28 is 1,192 bytes inside a block of size 1,752 free'd
==1125== at 0x48369AB: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==1125== by 0x174FF1: pim_vrf_delete (pim_instance.c:181)
==1125== by 0x4925480: vrf_delete (vrf.c:264)
==1125== by 0x4925480: vrf_delete (vrf.c:238)
==1125== by 0x49332C7: zclient_vrf_delete (zclient.c:2187)
==1125== by 0x4934319: zclient_read (zclient.c:4003)
==1125== by 0x492249C: thread_call (thread.c:2008)
==1125== by 0x48DC8D7: frr_run (libfrr.c:1223)
==1125== by 0x15E12A: main (pim_main.c:176)
==1125== Block was alloc'd at
==1125== at 0x4837B65: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==1125== by 0x48E80AF: qcalloc (memory.c:116)
==1125== by 0x1750DA: pim_instance_init (pim_instance.c:90)
==1125== by 0x1750DA: pim_vrf_new (pim_instance.c:161)
==1125== by 0x4924FDC: vrf_get (vrf.c:183)
==1125== by 0x493334C: zclient_vrf_add (zclient.c:2157)
==1125== by 0x4934319: zclient_read (zclient.c:4003)
==1125== by 0x492249C: thread_call (thread.c:2008)
==1125== by 0x48DC8D7: frr_run (libfrr.c:1223)
==1125== by 0x15E12A: main (pim_main.c:176)
and you do this series of events:
a) Create a vrf, put an interface in it
b) Turn on pim on that interface and turn on pim in that vrf
c) Delete the vrf
d) Do anything with the interface, in this case shutdown the system
The move of the interface to a new vrf is leaving the pim_ifp->pim pointer pointing
at the old pim instance, which was just deleted, so the instance pointer was freed.
Let's clean up the pim pointer in the interface pointer as well.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add a hash_clean_and_free() function as well as convert
the code to use it. This function also takes a double
pointer to the hash to set it NULL. Also it cleanly
does nothing if the pointer is NULL( as a bunch of
code tested for ).
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
After restarting pim6d, in some cases the ifindex is 0 for the interfaces,
so the vif index is also assigned as 0.
This causes the interface name to be pim6reg.
Fix:
If the ifindex is 0 and the interface name is not "pimreg" or "pim6reg",
the function will return without assigning vifindex with an error message.
Issue: #12744
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
When hitting gm_sg_update from the S,G expiry timer, t_sg_expire will
already be cancelled. But when arriving there from e.g. the MLD packet
getting cleared out, it'll still be running.
Clear out the timer if we arrive with `has_expired == true`.
Fixes: #12441
Reported-by: Vijay Kumar Gupta <vijayg@vmware.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
When the router is non dr for an interface, it installs mroute to drop
the packets from directly connected source. This was done to avoid packets
coming to cpu as nocache hit. Later when it gets change from non-DR to DR,
these entries are not cleared. So the packets are still dropped.
This causes register packets not getting generated.
So cleaning up the mroute entries and channel oil without
upstream reference which was created to drop.
Co-authored-by: Saravanan K <saravanank@vmware.com>
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
While configuring global or non-multicast address for IPv6 mld join command,
displaying a custom error-message "invalid multicast address"
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
New correct behavior:
eva# conf
eva(config)# ip pim rp 192.168.1.224 224.0.0.0/24
No Path to RP address specified: 192.168.1.224
eva(config)# ip pim rp 224.1.2.3 224.0.0.0/24
% Bad RP address specified: 224.1.2.3
eva(config)#
Fixes: #12970
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If the pimreg device exists but it has not been set to the pim->pimreg pointer we can have
a crash. Just prevent the crash since it's some sort of startup / re-org the network
issue.
(gdb) bt
0 0x00007f0485b035cb in raise () from /lib/x86_64-linux-gnu/libpthread.so.0
1 0x00007f0485c0fbec in core_handler (signo=6, siginfo=0x7ffdc0198030, context=<optimized out>) at lib/sigevent.c:264
2 <signal handler called>
3 0x00007f04859668eb in raise () from /lib/x86_64-linux-gnu/libc.so.6
4 0x00007f0485951535 in abort () from /lib/x86_64-linux-gnu/libc.so.6
5 0x00007f0485c3af76 in _zlog_assert_failed (xref=xref@entry=0x55692269b940 <_xref.23164>, extra=extra@entry=0x0) at lib/zlog.c:680
6 0x00005569226150d0 in pim_if_new (ifp=0x556922c82900, gm=gm@entry=false, pim=pim@entry=false, ispimreg=ispimreg@entry=true,
is_vxlan_term=is_vxlan_term@entry=false) at pimd/pim_iface.c:124
7 0x0000556922615140 in pim_if_create_pimreg (pim=pim@entry=0x556922cc11e0) at pimd/pim_iface.c:1549
8 0x0000556922616bc8 in pim_if_create_pimreg (pim=0x556922cc11e0) at pimd/pim_iface.c:1613
9 pim_ifp_create (ifp=0x556922cc0e70) at pimd/pim_iface.c:1641
10 0x00007f0485c32cf9 in zclient_interface_add (cmd=<optimized out>, zclient=<optimized out>, length=<optimized out>, vrf_id=77) at lib/zclient.c:2214
11 0x00007f0485c3346a in zclient_read (thread=<optimized out>) at lib/zclient.c:4003
12 0x00007f0485c215ed in thread_call (thread=thread@entry=0x7ffdc0198880) at lib/thread.c:2008
13 0x00007f0485bdbbc8 in frr_run (master=0x556922a10470) at lib/libfrr.c:1223
14 0x000055692260312b in main (argc=<optimized out>, argv=0x7ffdc0198b98, envp=<optimized out>) at pimd/pim_main.c:176
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Topology:
========
FHR----Source
Problem:
=======
When FHR receives multicast traffic, there is no RP configured,
PIMD does NHT register for RP address 0.0.0.0 and group 224.0.0.0/4
PIM6D does NHT register for RP address 0::0 and group FF00::0/8
frr# show ip pim nexthop
Number of registered addresses: 1
Address Interface Nexthop
---------------------------------------------
frr# show ipv6 pim nexthop
Number of registered addresses: 1
Address Interface Nexthop
---------------------------------------------
Fix:
====
Dont track nexthop for RP 0.0.0.0 & 0::0.
frr# show ip pim nexthop
Number of registered addresses: 0
frr# show ipv6 pim nexthop
Number of registered addresses: 0
Issue: #12104
Signed-off-by: Sarita Patra <saritap@vmware.com>
Topology:
RP---FHR---Source
Problem Statement:
1. In FHR, Enable PIM and IGMP on source connected interface
2. Start multicast traffic. (s,g) mroute and upstream will be created as expected.
3. Disable PIM on source connected interface.
4. Disable IGMP on source connected interface.
5. Stop the traffic.
Mroute will never get timeout.
Root Cause:
In FHR, when PIMD receive multicast data packet on
source connected interface which is IGMP enabled, but PIM
not enabled. PIMD process the packet, install the
mroute and start the KAT timer.
Fix:
Don't process multicast data packet received on PIM disabled
Signed-off-by: Sarita Patra <saritap@vmware.com>
Topology:
=========
RP---FHR<ens224>---Source
Problem Statement:
=================
Step 1:
Enable PIM and IGMP on source connected interface ens224
Step 2:
Start multicast traffic. (s,g) mroute and upstream will be created as expected.
dev# show ip mroute
IP Multicast Routing Table
Flags: S - Sparse, C - Connected, P - Pruned
R - SGRpt Pruned, F - Register flag, T - SPT-bit for SSM FHR
Source Group Flags Proto Input Output TTL Uptime
50.0.0.4 225.1.1.1 SF PIM ens224 pimreg 1 00:37:55
dev# show ip pim upstream
Iif Source Group State Uptime JoinTimer RSTimer KATimer RefCnt
ens224 50.0.0.4 225.1.1.1 NotJ,RegJ 00:37:57 --:--:-- --:--:-- 00:02:43 1
Step 3:
Disable PIM on source connected interafce ens224
dev# show ip mroute
IP Multicast Routing Table
Flags: S - Sparse, C - Connected, P - Pruned
R - SGRpt Pruned, F - Register flag, T - SPT-bit for SSM FHR
Source Group Flags Proto Input Output TTL Uptime
50.0.0.4 225.1.1.1 SF PIM ens224 pimreg 1 00:38:05
dev# show ip pim upstream
Iif Source Group State Uptime JoinTimer RSTimer KATimer RefCnt
ens224 50.0.0.4 225.1.1.1 NotJ,RegJ 00:38:08 --:--:-- --:--:-- 00:02:32 1
Step 4:
Disable IGMP on source connected interface ens224
dev# show ip pim upstream
Iif Source Group State Uptime JoinTimer RSTimer KATimer RefCnt
ens224 50.0.0.4 225.1.1.1 NotJ,RegJ 00:38:15 --:--:-- --:--:-- 00:03:27 1
dev# show ip mroute
IP Multicast Routing Table
Flags: S - Sparse, C - Connected, P - Pruned
R - SGRpt Pruned, F - Register flag, T - SPT-bit for SSM FHR
Source Group Flags Proto Input Output TTL Uptime
50.0.0.4 225.1.1.1 SF PIM <iif?> pimreg 1 00:38:18
Pim upstream IIF is still pointing towards the source connected
interface which is not pim enabled and not IGMP enabled and
Mroute is still present in the kernel and KAT timer is still running
on the interface, where ifp->info is already set to NULL.
This leads to crash.
Root Cause:
==========
When "no ip pim" commands get executed on source connected interface,
we are updating upstream IIF only when IGMP is not enabled on the same
interface.
Fix:
===
When PIM is disabled on source connected interface, update upstream IIF
no matter if IGMP is enabled or not on the same interface.
Issue: #12848
Issue: #10782
Signed-off-by: Sarita Patra <saritap@vmware.com>
Before fix:
==========
frr# show ipv6 mld interface
Interface State V Querier Timer Uptime
ens224 up 1 fe80::250:56ff:feb7:a7e3 query 00:00:24.219 00:00:07.031
After fix:
=========
frr(config-if)# do show ipv6 mld interface
Interface State Address V Querier QuerierIp Query Timer Uptime
ens224 up fe80::250:56ff:feb7:a7e3 1 local fe80::250:56ff:feb7:a7e3 00:01:22.263 00:08:00.237
Issue: #11241
Signed-off-by: Sarita Patra <saritap@vmware.com>
We should not display down interfaces or MLD disabled interfaces in
"show ipv6 mld interface" command.
Before fix:
==========
frr# show ipv6 mld interface
Interface State V Querier Timer Uptime
ens192 up 2 fe80::250:56ff:feb7:d04 query 00:00:25.432 00:00:07.038
ens224 up 1 fe80::250:56ff:feb7:a7e3 query 00:00:24.219 00:00:07.031
pim6reg down
After fix:
=========
frr# show ipv6 mld interface
Interface State V Querier Timer Uptime
ens192 up 2 fe80::250:56ff:feb7:d04 query 00:00:25.432 00:00:07.038
ens224 up 1 fe80::250:56ff:feb7:a7e3 query 00:00:24.219 00:00:07.031
Issue: #11241
Signed-off-by: Sarita Patra <saritap@vmware.com>
When upstream RPF address is secondary address, and
neighborship is built with primary address,
then pim_neighbor_find() fails.
Verify the upstream RPF address is present in the
neighbor primary and secondary address list.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When upstream RPF address is secondary, and
neighborship is built with primary address,
then pim_neighbor_find() fails, due to which when there
is upstream change it wont send prune.
Verify the nexthop is present in the neighbor primary
and secondary address list.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When there is a mismatch in nexthop address (secondary address)
and neighborship address(primary address) on the same interface,
RPF check fails.
This is fixed now.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When route to RP is having nexthop secndary address,
neighborship is built with primary address,
then pim_neighbor_find() fails, which causes RP IIF
Unknown.
Fix:
Verify pim neighborship on the RP connected interface.
Issue: #11526
Signed-off-by: Sarita Patra <saritap@vmware.com>
Problem 1:
When route to BSR is having nexthop secondary address,
neighborship is built with primary address,
then pim_neighbor_find() fails, which cause drop of BSM
packet.
Fix 1:
Verify pim neighborship on the BSM received interface.
Problem 2:
Problem 2:
Source IP BSM address is primary address, where
as nexthop also can be primary or secondary address.
Fix 2:
Avoiding the check (nhaddr == src_ip) for PIMV6
Issue: #11957
Signed-off-by: Sarita Patra <saritap@vmware.com>
For incoming no-receiver SSM traffic, there isn't going to be a RP, much
less a RPF. We should install an MFC entry with empty oif regardless,
so we don't get swamped with further notifications.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Whether due to a pimd bug, some expiry, or someone just deleting MFC
entries, when we're in NOCACHE we *know* there's no MFC entry. Add an
install call to make sure pimd's MFC view aligns with the actual kernel
MFC.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This path here is pretty far on top of the list of issues that operators
will run into and have to debug when setting up PIM. Make the log
messages actually tell what's going on. Also escalate some from
`debug mroute detail` to `debug mroute`.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Coverity complains that MLAG_MSG_NONE cannot be reached in
the switch statement. Which is true so let's make it happy.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The files converted in this commit either had some random misspelling or
formatting weirdness that made them escape automated replacement, or
have a particularly "weird" licensing setup (e.g. dual-licensed.)
This also marks a bunch of "public domain" files as SPDX License "NONE".
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Passing a pre-formatted buffer in these places needs a `"%s"` in front
so it doesn't get formatted twice.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Use `getpid()` to initialize the sequence number. This change silences
Coverity Scan warning about truncated use of `time()` which in this case
is not a problem.
Found by Coverity Scan (CID 1519828)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Topology:
========
Receiver----R1----(ens192)R2(ens224)----R3----R4----Source
--------------------------
R1=LHR
R2=RP
R4=FHR
Problem:
=======
1. Direct connected link between R1 and R3 is down initially.
2. So traffic flow path is R4<->R3<->R2<->R1<->Receiver.
3. Mroutes are properly created on all the nodes.
4. Up the direct connected link between R1 and R3.
5. Traffic flows in both the paths.
R4<->R3<->R2<->R1<->Receiver
R4<->R3<->R1<->Receiver
6. Duplicate traffic received at the receiver.
Root Cause:
==========
Initially when the direct connected link between R1 and R3 is
down, traffic flows via RP(R2). So in RP (S,G) installed with
IIF as ens224 and OIF as ens192 (reference = 2) with mask
PIM_OIF_FLAG_PROTO_STAR and PIM_OIF_FLAG_PROTO_PIM.
Now when the direct link between R1 and R3 is Up, LHR(R1) sends
SGRPT prune. After prune received, RP(R2) will remove OIF ens224
with mask PIM_OIF_FLAG_PROTO_STAR.
Since OIF ens224 is still present with mask PIM_OIF_FLAG_PROTO_PIM,
RP(R2) will not send prune towards R3.
So traffic continues to flow in the path R4<->R3<->R2<->R1<->Receiver.
Fix:
====
When SGRpt prune received, remove OIF irrespective of the OIF is
installed with mask "PIM_OIF_FLAG_PROTO_STAR" or "PIM_OIF_FLAG_PROTO_PIM".
Once OIF is removed, RP sends prune towards R3.
Issue: #11347
Signed-off-by: Sarita Patra <saritap@vmware.com>
Add some safe guards to avoid crashes and alert us about programming
errors in packet build.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Increase the MSDP peer stream buffer size to handle the whole TLV
(maximum is 65KiB due to 16bit field). If the stream is not resized
there will be a crash in the read function attempting to put more than
9192 (`PIM_MSDP_SA_TLV_MAX_SIZE`) bytes.
According to the RFC 3618 Section 12 we should accept the TLV and we
should not reset the peer connection.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
As per RFC 7761, Section 4.9.1
The RPT (or Rendezvous Point Tree) bit is a 1-bit value for use
with PIM Join/Prune messages (see Section 4.9.5.1). If the
WC bit is 1, the RPT bit MUST be 1.
ANVL conformance test case is trying to verify this and is failing.
Issue: #12354
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
As per RFC 7761, Section 4.9.1
The RPT (or Rendezvous Point Tree) bit is a 1-bit value for use
with PIM Join/Prune messages (see Section 4.9.5.1). If the
WC bit is 1, the RPT bit MUST be 1.
ANVL conformance test case is trying to verify this and is failing.
Issue: #12354
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
While doing nexthop lookup, only allow the nexthop
interafce which is PIM enabled.
Issue: #10782
Issue: #11931
Signed-off-by: Sarita Patra <saritap@vmware.com>
Problem:
When "no ip pim" is executed on source connected interface, its
ifp->info is set to NULL. But KAT on this interface is still
running, it wrongly dereferences NULL. This leads to crash.
Root Cause:
pim upstream IIF is still pointing towards the source connected
interface which is not pim enabled and Mroute is still present in
the kernel.
Fix:
When “no ip pim” command gets executed on source connected interface,
then loop through all the pnc->nexthop, if any new nexthop found,
then update the upstream IIF accordindly, if not found then update
the upstream IIF as Unknown and uninstall the mroute from kernel.
When “ip pim” command gets executed on source connected interface,
then also loop through all the pnc->nexthop and update the upstream IIF,
install the mroute in kernel.
Issue: #10782
Issue: #11931
Signed-off-by: Sarita Patra <saritap@vmware.com>
Bring error handling up front and delay creating socket so that
we don't think too much about closing the socket in error cases.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Saw this EC log:
```
PIM: [WX4HZ-FA72S][EC 100663307] pim_rp_find_match_group: BUG We should have found default group information
```
The root cause is group address of "0.0.0.0" is wrongly introduced into
`pim_rp_find_match_group()`. So add a check to avoid it.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
... the prefix length wasn't ignored as expected. Both S and G are
always /32. But expecting "le 32" in prefix-list config is unexpected &
counterintuitive.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
If PIM had received a register packet with the Border Router
bit set, pimd would have crashed. Since I wrote this code
in 2015 and really have pretty much no memory of this and
no-one has ever reported this crash, let's just remove this
code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In pim_ecmp_nexthop_search: All paths that lead to this null pointer comparison already dereference the pointer earlier
There may be a null pointer dereference, or else the comparison against null is unnecessary.
Coverity CID-1519749
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
In tib_sg_oil_setup: Value returned from a function is not checked for errors before being used.
If the function returns an error value, the error value may be mistaken for a normal value.
Here, only the nexthop value is being used. So casted the return type to void.
Coverity CID-1519816
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Rather than running selected source files through the preprocessor and a
bunch of perl regex'ing to get the list of all DEFUNs, use the data
collected in frr.xref.
This not only eliminates issues we've been having with preprocessor
failures due to nonexistent header files, but is also much faster.
Where extract.pl would take 5s, this now finishes in 0.2s. And since
this is a non-parallelizable build step towards the end of the build
(dependent on a lot of other things being done already), the speedup is
actually noticeable.
Also files containing CLI no longer need to be listed in `vtysh_scan`
since the .xref data covers everything. `#ifndef VTYSH_EXTRACT_PL`
checks are equally obsolete.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Problem:
frr(config)# show ip pim rp-info
RP address group/prefix-list OIF I am RP Source Group-Type
109.0.0.3 224.0.0.0/4 ens192 no Static ASM
frr(config)# int ens192
frr(config-if)# no ip pim
frr(config) show ip pim rp-info
RP address group/prefix-list OIF I am RP Source Group-Type
109.0.0.3 224.0.0.0/4 ens192 no Static ASM
rp-info OIF is still having ens192 which is PIM disabled.
Fixing this as part of this PR.
Issue: #12044
Signed-off-by: Sarita Patra <saritap@vmware.com>
Problem:
=======
frr(config)# do show ipv6 pim interface
Interface State Address PIM Nbrs PIM DR FHR IfChannels
ens192 up fe80::250:56ff:feb7:3619 0 local 0 1
Configure ens192 interface link-local address as RP.
frr(config)# ipv6 pim rp fe80::250:56ff:feb7:3619
No Path to RP address specified: fe80::250:56ff:feb7:3619
frr(config)# do show ipv6 pim rp-info
RP address group/prefix-list OIF I am RP Source Group-Type
fe80::250:56ff:feb7:3619 ff00::/8 Unknown yes Static ASM
Fix:
===
RP should not be link-local, multicast and unspecified address.
Signed-off-by: Sarita Patra <saritap@vmware.com>
