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>
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>
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>
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>
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>
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>
