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>
Added common pim_show_bsm_db_helper to suppport both PIM and
PIMV6.
pim_show_bsm_db is moved to pim_cmd_common.c file.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Added pim_show_group_rp_mappings_info_helper to suppport both PIM and
PIMV6.
pim_show_group_rp_mappings_info() is moved to pim_cmd_common.c file.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Added common API pim_show_bsr_helper to suppport both PIM and
PIMV6.
pim_show_bsr() is moved to pim_cmd_common.c file.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Introduced common api pim_process_unicast_bsm_cmd,
pim_process_no_unicast_bsm_cmd which will process
both "[no] ip pim unicast-bsm" command and "[no] ipv6 pim
unicast-bsm" command.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Introduced common api pim_process_bsm_cmd,
pim_process_no_bsm_cmd which will process
both "[no] ip pim bsm" command and "[no] ipv6 pim
bsm" command.
Signed-off-by: Sarita Patra <saritap@vmware.com>
In the current code, if_lookup_by_index()
is called for un-initialized ifindex value.
This issue is introduced after 11098 PR.
Signed-off-by: Sarita Patra <saritap@vmware.com>
RpAddress is showing wrong value in
"show ipv6 pim bsm-database" cli. This is fixed now.
Issue: #12089
Signed-off-by: Sarita Patra <saritap@vmware.com>
There are lib debugs being set but never show up in
`show debug` commands because there was no way to show
that they were being used. Add a bit of infrastructure
to allow this and then use it for `debug route-map`
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Fixed as per rfc7761 section 4.3.1.
"""
Sending Hello Messages
The Address List option advertises all the secondary addresses
associated with the source interface of the router originating the
message. The option MUST be included in all Hello messages if there
are secondary addresses associated with the source interface and MAY
be omitted if no secondary addresses exist.
"""
Issue: #12015
Signed-off-by: Sarita Patra <saritap@vmware.com>
Proof:
eva# conf
eva(config)# no service integrated-vtysh-config
eva(config)# end
eva# wr mem
Note: this version of vtysh never writes vtysh.conf
Building Configuration...
Configuration saved to /etc/frr/zebra.conf
Configuration saved to /etc/frr/ripd.conf
Configuration saved to /etc/frr/ripngd.conf
Configuration saved to /etc/frr/ospfd.conf
Configuration saved to /etc/frr/ospf6d.conf
Configuration saved to /etc/frr/bgpd.conf
Configuration saved to /etc/frr/isisd.conf
Configuration saved to /etc/frr/pimd.conf
Configuration saved to /etc/frr/nhrpd.conf
Configuration saved to /etc/frr/eigrpd.conf
Configuration saved to /etc/frr/babeld.conf
Configuration saved to /etc/frr/sharpd.conf
Configuration saved to /etc/frr/fabricd.conf
Configuration saved to /etc/frr/pbrd.conf
Configuration saved to /etc/frr/staticd.conf
Configuration saved to /etc/frr/bfdd.conf
Configuration saved to /etc/frr/vrrpd.conf
Configuration saved to /etc/frr/pim6d.conf
eva#
Fixes: #12011
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When more than 2 routers are present in LAN and the querier
goes down, the other routers will wait for other querier
present timer to expire to elect a new querier.
This issue will be seen when the router having next lower ip
address expires the other querier present timer first and it
starts sending the query message. Now on the other non-querier
routers it will receive this query and reset its other
querier present timer but the querier is still the old one
and since it is lowest ip, it never gets updated to the newly
elected querier.
Reset the other querier timer only if query is received from
the previously elected querier or a better new querier
This will make sure that non-querier elects the new querier
whose ip address is higher than the old querier
when the old querier goes down via other querier querier
timer expiry
Issue: #12027
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Implementing mld packets debug to information about packet generation for sending
and about packet handling from a received packet.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Changing
IGMP_DEFAULT_ROBUSTNESS_VARIABLE to GM_DEFAULT_ROBUSTNESS_VARIABLE,
IGMP_GENERAL_QUERY_INTERVAL to GM_GENERAL_QUERY_INTERVAL,
IGMP_QUERY_MAX_RESPONSE_TIME_DSEC to GM_QUERY_MAX_RESPONSE_TIME_DSEC and
IGMP_SPECIFIC_QUERY_MAX_RESPONSE_TIME_DSEC to GM_SPECIFIC_QUERY_MAX_RESPONSE_TIME_DSEC
to accomodate both igmp and mld. And moved it to common file.
Signed-off-by: Abhishek N R <abnr@vmware.com>
After restart pim dr address was zero due to which pim (*,G) join
could not get propagated towards RP.
While trying to find primary address ll_highest will be zero initially,
since we have not received address from zebra yet.
So we can get the best address at this point and use it as primary address
whenever ll_highest is zero.
Fixes: #11925
Signed-off-by: Abhishek N R <abnr@vmware.com>
Root Cause:
"clear ipv6 mroute" was not deleting the subscribers of gm_if
structure.
Fix:
The command "clear ipv6 mroute" deletes grp_pends, gsq_pends, sgs,
subscribers, expires of gm_if data structure.
Deleted the common code in gm_ifp_teardown() and called
gm_group_delete().
Issue: #11724
Signed-off-by: Sarita Patra <saritap@vmware.com>
Changed PIM_DEBUG_IGMP_TRACE to PIM_DEBUG_GM_TRACE and
PIM_DEBUG_IGMP_TRACE_DETAIL to PIM_DEBUG_GM_TRACE_DETAIL.
Hence, these macros can be used for both v6 and v4.
Issue: #11895
Co-authored-by: Sai Gomathi N <nsaigomathi@vmware.com>
Signed-off-by: Abhishek N R <abnr@vmware.com>
Changing
PIM_DO_DEBUG_IGMP_EVENTS to PIM_DO_DEBUG_GM_EVENTS
PIM_DO_DEBUG_IGMP_PACKETS to PIM_DO_DEBUG_GM_PACKETS
PIM_DO_DEBUG_IGMP_TRACE to PIM_DO_DEBUG_GM_TRACE
PIM_DO_DEBUG_IGMP_TRACE_DETAIL to PIM_DO_DEBUG_GM_TRACE_DETAIL
PIM_DONT_DEBUG_IGMP_EVENTS to PIM_DONT_DEBUG_GM_EVENTS
PIM_DONT_DEBUG_IGMP_PACKETS to PIM_DONT_DEBUG_GM_PACKETS
PIM_DONT_DEBUG_IGMP_TRACE to PIM_DONT_DEBUG_GM_TRACE
PIM_DONT_DEBUG_IGMP_TRACE_DETAIL to PIM_DONT_DEBUG_GM_TRACE_DETAIL
PIM_MASK_IGMP_EVENTS to PIM_MASK_GM_EVENTS
PIM_MASK_IGMP_PACKETS to PIM_MASK_GM_PACKETS
PIM_MASK_IGMP_TRACE to PIM_MASK_GM_TRACE
PIM_MASK_IGMP_TRACE_DETAIL to PIM_MASK_GM_TRACE_DETAIL
to be used for both IGMP and MLD debugs.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Added Robustness value, Query interval, Query response timer
and Last member query interval field in json output.
Issue: #11891
Signed-off-by: Abhishek N R <abnr@vmware.com>
Changing the macros to common so that it can be used for pimv6 debugs as well
to be used for both IGMP and MLD debugs.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Changing the macros to common so that it can be used for pimv6 debugs as well
to be used for both IGMP and MLD debugs.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
When there is update in the configuration of last_member_query_interval
and last_member_query_count, call gm_ifp_update().
This will update cur_query_intv_trig and cur_lmqc of gm_ifp structure.
Issue: #11901
Signed-off-by: Sarita Patra <saritap@vmware.com>
show ip pim state should show IGMP Report while
show ipv6 pim state should show MLD Report.
Output After Fix:
frr# do sh ip pim state
Codes: J -> Pim Join, I -> IGMP Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN, M -> Muted
Active Source Group RPT IIF OIL
frr# do sh 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
frr#
Issue: #11249
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Modifying igmp_group_count of struct pim_instance
to gm_group_count which is to be used for both IGMP and MLD.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
When calling time(NULL), FRR is intentionally throwing
away the upper 32 bits of value returned. Let's explicitly
call it out so that coverity understands this is intentional
and ok.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
IPv4 and IPv6 behaves a little bit differently with the socket
options.
IPPROTO_RAW socket option is only for IPv4.
Therefore the register packet was not properly getting encapculated
for PIMv6 and was working fine for PIMv4.
So have used IPPROTO_PIM for PIMv6.
Fixes: #11846
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
The socket created for pimv6 was created using AF_INET for PIMV6
too.
Since the api pim_reg_sock is common to both PIMv4 and PIMv6,
need to use PIM_AF instead of AF_INET.
Fixes: #11815
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
The call into pim_cmd_lookup_vrf may be NULL
and dereferencing it before ensuring that the
vrf pointer is non-NULL is a good way to crash.
A crash can be initiated in pim:
eva# show ip msdp vrf NOEXIST mesh-group
vtysh: error reading from pimd: Permission denied (13)Warning: closing connection to pimd because of an I/O error!
eva# 2022/08/15 11:47:38 [PHJDC-499N2][EC 100663314] STARVATION: task vtysh_rl_read (560b77f76de6) ran for 16777ms (cpu time 0ms)
eva#
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When calling pim_upstream_add, the lookup for upstream
or the creation of the upstream cannot fail. As such
up is never NULL.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
in pim_ifchannel.c there exists several spots where
the ch->upstream is assumed to be NULL. This is not
possible.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The problem here is when the same node is FHR as well as RP,
then the node keeps on sending the register packet.
Register-stop is not sent as well.
This problem has occurred because the RP is the same node
and there is no socket created on loopback interface, so the
packet is never send out and never received back on the same
node, so register recv could not be processed on the node and
hence no register-stop is sent.
Since register packets are unicast packets, its better to handle
the send of register packet via a separate register socket.
This fixes the problem mentioned above as well.
Fixes: #11331
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Change the show running commands for bsm and vxlan pimv4 and pimv6
debug commands based on the address family.
Including bsm and vxlan in no debug pimv6 debug.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Allow the same group/source route to be configured on more than one interface.
Currently FRR doesn't allow adding the same mroute on different input interfaces.
Current behavior, if we have the following config:
```
interface eth1
ip mroute eth0 239.0.0.1
interface eth2
ip mroute eth0 239.0.0.1
```
Only one multicast route will be installed with an input interface of the last
interface configured.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
Topology:
R1(LHR) ---- R2 ----R4(FHR)
---- R3 ----
R2 = RP
Steps to reproduce:
1. R1(LHR) sends IGMP join, R4(FHR) sends multicast traffic.
Verify traffic is flowing from FHR to LHR.
2. Restart R1(LHR).
3. Below sequence of events are happening after FRR restart in R1(LHR).
4. R1(LHR) Register RP address to Zebra.
5. R1(LHR) Receive update from Zebra that R2(RP) is reachable via R3.
6. R1(LHR) Receive IGMP join for group 225.1.1.1, will create pim upstream
and (*,G) mroute with IIF towards R3.
7. R1(LHR) Receive update from Zebra that RP is reachable via R2(RP).
8. R1(LHR) Update the PIM upstream IIF, but not updating the (*,G) IIF
even there is RPF change.
9. R1(LHR) receives IGMP join for group 225.1.1.2, will create (*,G) with
IIF towards R2(RP), both upstream and (,G) created with IIF towards R2(RP).
Root Cause:
Mroute IIF is not getting updated when better route update
received. It is still pointing to the older nexthop.
Fix:
Update the mroute IIF when there is change in nexthop.
Fixing Issue #11675
Signed-off-by: Sarita Patra <saritap@vmware.com>
Coverity is complaining that buf has not been initialized.
It has and coverity appears to be confused so let's help it
find the initialization.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The API pim_rp_check_interface_addrs checks if the RP address matches
with the primary address then it returns true.
In case of PIMv4 this condition is true, therefore the router becomes RP.
But in case of PIMv6, this condition does not pass because primary address
for PIMv6 is link-local address.
Also PIMv4 allows secondary addresses to be used as RP
if it is a host route in case primary does not match.
Fixing it by only checking the configured
RP address with the interface address and ignoring the prefix
length since it does not matter.
Fixes: #11335
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
In several places, we are getting the vrf structure using
vrf_lookup_by_name(). Again we are passing vrf->vrf_id to
pim_get_pim_instance() to get the pim_instance.
The API pim_get_pim_instance() again get the VRF structure using
vrf_lookup_by_id(). This is avoided in this PR.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Longest possible length of a IPV6 (S,G) string is 94 bytes
INET6_ADDRSTRLEN * 2 = 46 * 2
(,) = 1
NULL Character at end = 1
Signed-off-by: Sarita Patra <saritap@vmware.com>
These are in packed structs at weird offsets (e.g. 2 bytes), and as such
need a memcpy to get them into proper alignment.
It'd be even better if the pimd code used proper de/serialization, but
let's get this improved one step at a time.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
"show ip pim interface traffic json" shows pruneTx first and then
pruneRx stats
where as
"show ip pim interface <ifname> json" shows pruneRx first and then
pruneTx stats.
Although the values are right but the display looks odd.
Making it same as other stats, first display Rx and then Tx.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
By default, disable pim6d compilation. If someone
wants to enable the compilation, should use ./configure option
with --enable-pim6d.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Fixed ANVL Conformance PIM-SM 16.3 test case.
When (S,G,rpt) prune is received, we were installing
the mroute immediately with none as OIF.
This leads to dropping the (S,G) traffic during prune
pending time as well.
Also we should not install the mroute if there is no
change in the rpf update.
These 2 things lead to the failure of the test case.
Fixed it by blocking the installation in this scenario.
When prune pending timer pops, it will take care of
installing the mroute with none as OIF.
Fixes: #11535
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
For pim callbacks, we pass pim_addr as value, not pointer.
So making it consistent for pim_nht callbacks.
Signed-off-by: sarita patra <saritap@vmware.com>
In this PR, we are handling the pim_vxlan_orig_mr_up_add()
after rpf_addr modified from prefix to pim_addr.
Signed-off-by: sarita patra <saritap@vmware.com>
Currently rpf_addr is of type struct prefix, but it's always
a /32 host prefix. So changing it to pim_addr in order to support both
IPV4 and IPV6.
Signed-off-by: sarita patra <saritap@vmware.com>
Moving the reusable code of pim_show_nexthop apis to common file
pim_cmd_common.c file and adding the json support for show ipv6 pim nexthop
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Problems Identified:
show ip pim nexthop cli didn't have json extension and
show ip pim vrf all upstream have improper json format
Description:
show ip pim nexthop command shows the nexthops that are being used.
Added json support for the command.
show ip pim vrf all upstream displays upstream information for all vrfs about a S,G mroute.
Formatted the json structure for this command.
Signed-off-by: nsaigomathi <nsaigomathi@vmware.com>
Implementing the TBD of watermark-warn CLI for IPv6 MLD
This command can be use to warn the user
when more than the desired limit of groups gets configured.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Modifying igmp_watermark_limit of struct pim_instance
to gm_watermark_limit which is to be used for both IGMP and MLD.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
As per RFC 4601 section 4.9.4, For Register-Stops,
the Mask Len field contains full address length * 8
(e.g. 32 for IPv4 native encoding) (e.g. 128 for IPv6),
if the message is sent for a single group
The issue is seen after 10356, so fixed now.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Fixing IGMPv2 ANVL Conformance issue 3.10
As per RFC 2236 section 3, when the leave message is received at a querier,
it starts sending Query messages for "last Member Query Interval*query count"
During this time there should not be any querier to non-querier
transition and the same router needs to send the remaning queries.
Currently the code is handling this scenario only when leave is receive
for a group and the query is received for the same group.
But we need to handle it irrespective of group since the querier
election is based on interface and not group.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Deletion of pim interface(pim_if_delete) should
do the below things before cleanup.
1. Send a hello message with zero hold time.
2. Delete all the neighbors.
3. Close the pim socket.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Issue:
==16837== Invalid read of size 8
==16837== at 0x17971C: pim_neighbor_find (pim_neighbor.c:431)
==16837== by 0x186439: join_timer_stop (pim_upstream.c:348)
==16837== by 0x186794: pim_upstream_del (pim_upstream.c:231)
==16837== by 0x189A66: pim_upstream_terminate (pim_upstream.c:1951)
==16837== by 0x17111B: pim_instance_terminate (pim_instance.c:54)
==16837== by 0x17111B: pim_vrf_delete (pim_instance.c:172)
==16837== by 0x4F1D6C8: vrf_delete (vrf.c:264)
==16837== by 0x19006F: pim_terminate (pimd.c:160)
==16837== by 0x1B2E4D: pim_sigterm (pim_signals.c:51)
==16837== by 0x4F08FA2: frr_sigevent_process (sigevent.c:130)
==16837== by 0x4F1A2CC: thread_fetch (thread.c:1771)
==16837== by 0x4ED4F92: frr_run (libfrr.c:1197)
==16837== by 0x15D81A: main (pim_main.c:176)
Root Cause:
In the pim_terminate flow, the interface is deleted
before the pim_interface clean up. Because of this,
the pim_interface is having garbage value.
Fix:
Release the pim interface memory and then delete the
interface.
Signed-off-by: Sarita Patra <saritap@vmware.com>
pim_mroute_socket_disable api is present but nowhere called.
This should be called when pim instance is terminated.
Fixed it.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
The command "show ip[v6] mroute" displaying group and source
field for every OIL.
Fix:
Display group and source for the first OIL only.
Signed-off-by: sarita patra <saritap@vmware.com>
If the upstream is freed in pim_upstream_del, then trying to
call pim_upstream_timers_stop will lead to accessing freed memory.
Fix:
Stop the timer only if upstream is not deleted.
Co-authored-by: Sarita Patra <saritap@vmware.com>
Co-authored-by: Mobashshera Rasool <mrasool@vmware.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
The call to gm_update_ll checks for null pointers and
implies to SA that things could not be configured correctly
This is not true with the code flow. Remove the confusing code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Zebra can be setup to use a value that is less than MULTIPATH_NUM.
When pimd connects to zebra, zebra will inform pim about the MULTIPATH_NUM
used. Let's use that value for figuring out our multipath value.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When pim_upstream_inherited_olist_decide calls the api
pim_channel_add_oif, it can pass PIM_OIF_FLAG_PROTO_GM,
PIM_OIF_FLAG_PROTO_PIM and/or PIM_OIF_FLAG_PROTO_STAR.
Now a consider a case where PIM flag was already set
but STAR flag was not set and this api tries to set
both STAR + PIM and passes the same. The api pim_channel_add_oif
returns since it sees that PIM is already set without
setting the STAR flag.
So basically this will lead to issues in scenarios where for the
same OIF multiple flags(IGMP, PIM, STAR) needs to be set.
Fixing it for all combinations.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
The rpf lookup debug was not taking into account the fact that a prefix-list
might be applied and also we might need to make a choice between the two.
So let's give ourselves a bit more data.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
1. Removal of IPV6_HDRINCL option
2. Removal of IPv6 headers in TX
3. Addition of IPV6_PKTINFO and setting of source ipv6 address for TX.
Signed-off-by: Balaji Gurudoss <G_Balaji1@dell.com>
For show ip pim interface traffic cli, doing the below changes
1. Changing DEFUN to DEFPY
2. Move the whole code to a common api and modify it so that can
be reused for pimv6.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Moving pim_show_interface_traffic and pim_show_interface_traffic_single
to pim_cmd_common.c from pim_cmd.c to make it common to
pimd and pim6d.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Moving the common lines of pim_show_join_vrf and pim_show_join_vrf_all cli
in pim_cmd.c and pim6_cmd.c to pim_cmd_common.c file
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
the `show ip pim interface [x] traffic` command was deciding
to skip display of interfaces if they happened to be down at
that moment. This of course does not make a bunch of sense
to limit the output for a interface that may have sent data
in the past.
This fixes this test crash:
rnode = <lib.topogen.TopoRouter object at 0x7fc755be3880>, dut = 'c1', input_dict = {'c1': {'c1-l1-eth2': ['helloTx', 'helloRx']}}, output_dict = {'c1': {}}
def show_pim_intf_traffic(rnode, dut, input_dict, output_dict):
show_pim_intf_traffic_json = run_frr_cmd(
rnode, "show ip pim interface traffic json", isjson=True
)
output_dict[dut] = {}
for intf, data in input_dict[dut].items():
> interface_json = show_pim_intf_traffic_json[intf]
E KeyError: 'c1-l1-eth2'
/home/sharpd/frr8/tests/topotests/lib/pim.py:1496: KeyError
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The pim_channel_oil_empty() function was setting
the pimreg if it ever existed for NULL comparison
but of course the pimreg device is never pulled back
out again when it was needed to be when the pimreg
is not present.
Commit: a5fa982256
broke this.
Fixes: #11368
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Moving the common lines of pim_show_nexthop_lookup cli
in pim_cmd.c and pim6_cmd.c to pim_cmd_common.c file
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Moving the common lines of pim_show_nexthop cli
in pim_cmd.c and pim6_cmd.c to pim_cmd_common.c file
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Moving the common lines of pim_show_neighbors_vrf_all cli
in pim_cmd.c and pim6_cmd.c to pim_cmd_common.c file
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Moving the common lines of pim_show_neighbors cli
in pim_cmd.c and pim6_cmd.c to pim_cmd_common.c file
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Moving the common lines of pim_local_membership cli
in pim_cmd.c and pim6_cmd.c to pim_cmd_common.c file
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Moving the common lines of pim_show_jp_agg cli
in pim_cmd.c and pim6_cmd.c to pim_cmd_common.c file
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Moving the common lines of pim_show_interface_vrf_all cli
in pim_cmd.c and pim6_cmd.c to pim_cmd_common.c file
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Moving the common lines of pim_show_interface cli
in pim_cmd.c and pim6_cmd.c to pim_cmd_common.c file
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Moving the common lines of pim_show_channel cli
in pim_cmd.c and pim6_cmd.c to pim_cmd_common.c file
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
The test for setting pimDesignatedRouterLocal was comparing
the result of pim_addr_cmp to non zero to say that the
pim_dr_addr and primary_address are the same. This is
not correct in that pim_addr_cmp returns 0 for being the
same, so the correct test is !pim_addr_cmp
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
PIM conformance test case 11.12 sends a register stop msg with
source address as 0. This should trigger a register stop for
all the upstreams. It is not happening as such because we are not
considering 0.0.0.0 source address for starg_handling.
Fixed it.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
All rp_info's are being saved in the pim->rp_list and the non prefix-list
rp's are supposed to be saved in table pim->rp_table. What was happening,
though, is that all the plists were being stored at the 224.0.0.0/4 node
of the tree(irrelevant to the fact that we should not be looking up the
non-prefix list rp's in the table) and since we can have multiple prefix lists
and only one rp_info stored at the 224.0.0.0/4 node of the tree, there can be situations
where the 224.0.0.0/4 node can be overwritten due to the order entered.
As such there exists situations where command enter ordering will cause
what we match to, change in pim_rp_find_match_group.
Fixes:
a) Do not store prefix list based rp_info's in the pim->rp_table
b) In pim_rp_find_match_group, ensure that the node lookup does
not correspond to a prefix list based node.
c) When in the situation there are both:
ip pim rp 4.5.6.7 224.0.0.0/16
ip pim rp 5.6.67.8 prefix-list FOO
ip prefix-list FOO permit 224.0.1.0/24
and we receive a group for 224.0.1.5, we were comparing the
224.0.0.0/16 to the 224.0.0.0/4 of the 5.6.67.8 group, when
FRR should have been comparing to entry that matched in the prefix-list
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
pimd is receiving v3 igmp packets on an interface that is setup as v2 and
causing the igmp group as configured on that interface to get a bit
wonky.
Add a check to receiving v3 packets and to drop the packet if the
igmp version configed on the interface is 2.
Fixes: #11105
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
PIM_IPV == 4 is removed form function pim_cmd_show_ip_multicast_helper
as pim_zlookup.c is available for pimv6 aswell.
Signed-off-by: Abhishek N R <abnr@vmware.com>
Implementing debug pimv6 zebra command for debugging about
the events from zebra that come up through the ZAPI.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Implementing debug pimv6 packetdump send and recv coomands for debugging
of pimv6 packet sent and received which are dumped.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Implementing pimv6 packets debug to information about packet generation for sending
and about packet handling from a received packet.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Implementing debug pimv6 nht command for PIMv6 nexthop tracking.
It will display information about RPF lookups and information about when a nexthop changes.
debug pimv6 nht detial for for PIMv6 nexthop in detail.This is not enabled by default.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Added a new cli command "ip pim passive" in the interface context,
to disable sending of pim control packets on the interface.
Signed-off-by: sarita patra <saritap@vmware.com>
Added a new cli command "ip pim passive" in the interface context,
to disable sending of pim control packets on the interface.
Signed-off-by: sarita patra <saritap@vmware.com>
Fresh ground-up MLD implementation with subscriber-tracking for MLDv2.
Intended to be adapted for IPv4 and replace the IGMP implementation at a
later point.
Tested in ANVL, currently at 94/116. Some issues/TODOs are left in the
code as CPP_NOTICE markers, but the code is very much good enough to
proceed since otherwise we're blocked on overall PIM v6 progress.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This is causing build issues on BSD by including (transitively)
`linux/mroute6.h` - try to address by disentangling the headers a bunch.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The IPv6 `mrt6msg` kernel pseudo-header does not have a length field;
accessing what would be the IPv6 payload length reads zeroes.
Pass down the proper length and use that instead.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Firstly, *keep no change* for `hash_get()` with NULL
`alloc_func`.
Only focus on cases with non-NULL `alloc_func` of
`hash_get()`.
Since `hash_get()` with non-NULL `alloc_func` parameter
shall not fail, just ignore the returned value of it.
The returned value must not be NULL.
So in this case, remove the unnecessary checking NULL
or not for the returned value and add `void` in front
of it.
Importantly, also *keep no change* for the two cases with
non-NULL `alloc_func` -
1) Use `assert(<returned_data> == <searching_data>)` to
ensure it is a created node, not a found node.
Refer to `isis_vertex_queue_insert()` of isisd, there
are many examples of this case in isid.
2) Use `<returned_data> != <searching_data>` to judge it
is a found node, then free <searching_data>.
Refer to `aspath_intern()` of bgpd, there are many
examples of this case in bgpd.
Here, <returned_data> is the returned value from `hash_get()`,
and <searching_data> is the data, which is to be put into
hash table.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
