The entire `case NEXTHOP_TYPE_IPV6_IFINDEX:` block here was a bit of a
tripwire to stumble over, since there was no indication at all that this
concerns RFC5549 nexthop handling. So it got mis-adapted for PIM IPv6
support.
Clarify this a whole bunch that this is for v4-over-v6 nexthop mangling,
and nothing else.
This should really also use neighbor's secondary address lists for the
lookup, but that is probably going to break compatibility with other
boxes that don't include v6 addrs in v4 hellos and needs further
machinery to do properly, so for now just leave a breadcrumb.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The only function these macros have is to make the code confusing.
"PIM_IF_DO_PIM" sounds like it triggers some action, but it doesn't.
Replace with "bool" fields in struct pim_interface.
(Note: PIM_IF_*_IGMP_LISTEN_ALLROUTERS was always set, without any way
to unset it. It is completely removed now and always enabled.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Adding new show CLI to display regarding pim neighbors.
Changing DEFUN to DEFPY for "show ip pim neighbor" command.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Adding the new cli to display pim local membership information.
Changing DEFUN to DEPFY for "show ip pim local-membership"
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Adding show ipv6 pim join and show ipv6 pim vrf all join
CLIs to display pim join related information and
formatted the json output for "show ip pim join" and
"show ip pim vrf all join" commands.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Adding show ipv6 pim interface and show ipv6 pim vrf all interface
CLIs to display pim enabled interface informations and
formatted the json output for "show ip pim interface" and
"show ip pim vrf all interface" commands.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Adding new CLI to display pim channel informations.
Changing DEFUN to DEPFY for ""show ip pim channel"
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
When pimd has this setup:
src ----- rtr ------ receiver
|
rp
And the receiver sends a *,G join to rtr. When the
src starts sending a S,G, rtr can wait up to one join/prune
interval before sending a S,G rpt prune. This interval
causes the pimreg device to be in the S,G OIL as that the
RP does not know to prune this leg off.
before:
Timestamp: Thu Mar 31 10:15:18 2022 288767 usec
[MROUTE](10.103.0.5,239.0.0.4) Iif: rtr-lan_src Oifs: rtr-lan State: resolved Table: default
Timestamp: Thu Mar 31 10:15:18 2022 288777 usec
[MROUTE](10.103.0.5,239.0.0.4) Iif: rtr-lan_src Oifs: rtr-lan rtr-lan-1 State: resolved Table: default
Timestamp: Thu Mar 31 10:15:18 2022 288789 usec
[MROUTE](10.103.0.5,239.0.0.4) Iif: rtr-lan_src Oifs: pimreg rtr-lan rtr-lan-1 State: resolved Table: default
Timestamp: Thu Mar 31 10:15:49 2022 324995 usec
[MROUTE](10.103.0.5,239.0.0.4) Iif: rtr-lan_src Oifs: rtr-lan rtr-lan-1 State: resolved Table: default
<31 seconds>
After:
Timestamp: Thu Mar 31 12:56:15 2022 501921 usec
(10.103.0.5,239.0.0.27) Iif: rtr-lan_src Oifs: pimreg rtr-lan State: resolved Table: default
Timestamp: Thu Mar 31 12:56:15 2022 501930 usec
(10.103.0.5,239.0.0.27) Iif: rtr-lan_src Oifs: pimreg rtr-lan rtr-lan-1 State: resolved Table: default
Timestamp: Thu Mar 31 12:56:15 2022 502181 usec
(10.103.0.5,239.0.0.27) Iif: rtr-lan_src Oifs: rtr-lan rtr-lan-1 State: resolved Table: default
<sub second>
What is actually happening:
rtr receives a *,G igmp join, sends a *,G join towards the rp
rtr receives a S,G packet <WRVIFWHOLE>
creates the S,G upstream, sends the register packet to the rp
the rp sees that it still has downstream interest so it forwards the packet on
After (up to 60 seconds ) the rtr, sends the normally scheduled join for
the G and sends the S,GRPT prune as part of it.
What is being done to fix it:
In wrvifwhole handling, when pimd detects that this is the FHR
and is not the RP *and* the incoming interface for the *,G
is different than the incomding interface for the S,G immediately
send a single join packet for the G( which will have the S,G RPT
prune in it ). Only do this on the first time receiving the
WRVIFWHOLE.
Ticket: #2755650
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Problem:
Once Assert election is over and winner is elected, the downstream router has to prune from the upstream LOSER if it has joined already and have to join with upstream elected WINNER
pim_rpf_update function takes care of changing the rpf_ch if the
existing one is PIM_IFASSERT_I_AM_LOSER
Signed-off-by: plsaranya <Saranya_Panjarathina@dell.com>
Re-evaluate the creation/deletion of groups when there is
a change in group type.
Issue: #10128
Co-authored-by: Vishal Dhingra <rac.vishaldhingra@gmail.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Currently FRR creates an (S,G) PIM state when an IGMPv3
(S,G) join with INCLUDE mode is received for the ASM group.
Since it is an ASM group, we should not create (S,G) PIM state
and should not be sending PIM (S,G) joins towards the source.
This is a misconfiguration. So keep this group in IGMP table
and do not create PIM state.
Issue: #10128
Co-authored-by: Vishal Dhingra <rac.vishaldhingra@gmail.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
... this shouldn't run for IPv6. (We'll switch to not using
IPV6_HDRINCL later, so the kernel will handle it, but for the time being
let's just stop trying to use the IPv4 code for IPv6.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Problem:
PIM assert is not triggered even after receiving WRONGVIF notification because of Could_assert flag not set.
CouldAssert(S,G,I) =
SPTbit(S,G)==TRUE
AND (RPF_interface(S) != I)
AND (I in ( ( joins(*,G) (-) prunes(S,G,rpt) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G) )
(-) lost_assert(*,G)
(+) joins(S,G) (+) pim_include(S,G) ) )
Once SPTbit is set, Could_assert has to be reevaluated
Signed-off-by: plsaranya <Saranya_Panjarathina@dell.com>
IPV6_HDRINCL is a TX-only option (unlike IP_HDRINCL), so on RX there
never are IPv6 headers to be looked at / skipped over.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
- im6_src/dst are in6_addr, not pim_addr, so `%pI6` should be used
- the sockopt is IPV6_RECVPKTINFO not IPV6_PKTINFO
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Modifying the code as per RFC 4604 section 2.2.1
EXCLUDE mode does not apply to SSM addresses, and an SSM-aware router
will ignore MODE_IS_EXCLUDE and CHANGE_TO_EXCLUDE_MODE requests in
the SSM range.
Issue is observed when a group in exclude mode was in ASM range
as per the prefix-list and then prefix-list is modified to make
it fall under SSM range. The (*,G) entry remains there.
So when the group moves to ssm range and it is exclude mode,
delete the group from the IGMP table.
Co-authored-by: Vishal Dhingra <rac.vishaldhingra@gmail.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
show ip mroute json command displays the source, group info
per oil, so for pruned group since the OIL is empty, it is not
showing.
Fix: Added the above information per source.
Signed-off-by: sarita patra <saritap@vmware.com>
Now we return all zeroed stats, which seems wrong. Handle the same way, as
with PIM interfaces. Return empty JSON and a warning for VTYSH.
```
exit1-debian-11# sh ip igmp statistics interface belekas
% No such interface
exit1-debian-11# sh ip igmp statistics interface belekas json
{
}
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Adding the Interface level config command
ipv6 mld query-interval <1-65535>
This command can be use to tune the timing for the general queries sent by the querier.
Signed-off-by: Abhishek N R <abnr@vmware.com>
Adding the Interface level config command
ipv6 mld version <1-2>
This command can be use to configure MLD version on the interface.
Signed-off-by: Abhishek N R <abnr@vmware.com>
Adding the Interface level config command
ipv6 mld join
This command can be used to configure the static MLD join
for IPv6 group addresses on the interfaces.
Signed-off-by: Abhishek N R <abnr@vmware.com>
The current code in pim_register_stop_recv would never fail as
that the code was always returning 0 in all cases, but
if the code parses an incorrect afi then it has failed and
should return as much
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
RCA: (*,G) register stop was not handled
Fix: Loop through all (S,G) under the (*,G) and apply reg stop
Authored-by- Saravanan K <saravanank@vmware.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
We only care about link-local addresses for IPv6 operation. Also, MLD
needs the lowest while PIM needs the highest...
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Try to untangle some spaghetti...
This is an 1:1 change that should not result in any functional
difference.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
These will corrupt memory if mroute_vif_index is -1 (e.g. interface not
operating.) That shouldn't happen, but it does while doing development
work, so trip an assert rather than corrupting memory.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Currently the nexthop tracking code is only sending to the requestor
what it was requested to match against. When the nexthop tracking
code was simplified to not need an import check and a nexthop check
in b8210849b8 for bgpd. It was not
noticed that a longer prefix could match but it would be seen
as a match because FRR was not sending up both the resolved
route prefix and the route FRR was asked to match against.
This code change causes the nexthop tracking code to pass
back up the matched requested route (so that the calling
protocol can figure out which one it is being told about )
as well as the actual prefix that was matched to.
Fixes: #10766
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
socket changes to support IPv6 PIM
Signed-off-by: Balaji Gurudoss <G_Balaji1@dell.com>
[DL: cleaned up & refactored a whole bunch more.]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
sockopt_cork is a no-op function that was cleaned up
in 2017. Since then it's still not being used. At
this point in time there is little point in keeping a
dead function that will not be used because of vagaries
between platforms
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This isn't a system or interface setting, it's a socket behavior. It is
both irrelevant and confusing to the user since it doesn't affect any
system behavior (but it sounds like it does). Whether it is enabled or
not is solely relevant to how the code is designed to work.
So, remove it from output.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
And filter by group for PIM.
```
exit1-debian-11# show ip pim rp-info
RP address group/prefix-list OIF I am RP Source Group-Type
192.168.10.17 238.0.0.0/24 eth2 no Static ASM
192.168.10.110 232.0.0.0/24 eth2 no Static SSM
exit1-debian-11# show ip pim rp-info 238.0.0.0/24
RP address group/prefix-list OIF I am RP Source Group-Type
192.168.10.17 238.0.0.0/24 eth2 no Static ASM
exit1-debian-11# show ip pim rp-info 238.0.0.0/24 json
{
"192.168.10.17":[
{
"rpAddress":"192.168.10.17",
"outboundInterface":"eth2",
"iAmRP":false,
"group":"238.0.0.0/24",
"source":"Static",
"groupType":"ASM"
}
]
}
exit1-debian-11#
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Fixing the below problem:
Dereferencing a pointer that might be "NULL" "group_dnode"
when calling "yang_is_last_list_dnode" in api pim_process_no_rp_cmd
Although there is no NULL pointer dereference since
yang_dnode_exists is called before using the dnode.
So removing the unnecessary yang_dnode_exists api call
and directly get the node and if node does not exists,
return.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
IPv4 uses "struct ip" and IPv6 uses "struct ip6_hdr" as
headers. Get the src and dst in pim_sgaddr.
Added api pim_sgaddr_from_iphdr to do so.
Signed-off-by: Mobashshera Rasool <mrasool@vmwaer.com>
Added this api to fill all multicast group address based on IP version.
For PIMv4 its 224.0.0.0/4, for PIMv6 its FF00::0/8.
Changed the code where its being used currently.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Pass pim_addr as parameter for rp address to accomodate ipv6.
Modifying pim_rp_cmd_worker and pim_no_rp_cmd_worker function
parameters from in_addr to pim_addr.
Changes in the caller functions are done as well to make it work
for IPv6.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
1. Return value of this function pim_rp_del_config is nowhere used.
So made it as a void function.
2. Paramater const char *rp is first converted to string from prefix
in the caller and then back to prefix in this api pim_rp_del_config.
Fixed it by directly passing the address instead of string.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
1. Moving the processing of the above command to an api.
2. Change DEFUN to DEPFY
3. Make the api common for pimv4 and pimv6 processing.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Modify the apis pim_process_rp_cmd and pim_process_no_rp_cmd
to accomodate ipv4 as well as ipv6.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Changes correct typo in JSON output for IGMP interface statistics show
command from "leaveV3" to "leaveV2".
Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
Problem Statement:
=================
PIM Logs are coming at interval of 1 minute although pim
is not enabled.
Root Cause Analysis:
====================
By default, RCPM configures the PIM debugs when router comes up
via script. The product cannot disable PIM even though it is not required.
Hence moving these logs under a new debug option which will not be
enabled by default.
Fix:
====
Added a new option "detail" in the cli:
debug pim nht detail
Co-author: Mobashshera Rasool <mrasool@vmware.com>
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
We can use PIMADDR_ANY instead of INADDR_NONE to initalize rp->rpf_addr
when there is no rp configured for group_all.
Signed-off-by: sarita patra <saritap@vmware.com>
Adding the file pim6_cmd.h and pim6d_cmd.c as the base changes
for implementing the CLI changes
Removed the pim_cmd_init from the stub file.
Co-authored-by: Sarita Patra <saritap@vmware.com>
Co-authored-by: Abhishek N R <abnr@vmware.com>
Co-authored-by: Sai Gomathi N <nsaigomathi@vmware.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Currently the code is expecting the TOS value for received
packet to be 0xC0 and hence it is discarding packets having
TOS value other than 0xc0.
We need to make sure that we are sending the packet with
TOS 0xC0 and while receiving we can allow any TOS value.
Let's follow Postel's law.
Checked Cisco behavior as well. It also accepts all TOS values.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
224.0.0.0/24 cannot be used by igmp since this is reserved
for routing protocols and other low-level topology discovery or
maintenance protocols.
Fixes: #10614
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
The pim_upstream data structure has a ref count that is
not properly being incremented/decremented and when an
instance is removed this is causing crashes because timers
are still popping afterwords on data structures that are
now freed.
Since getting the ref count code is extremely hard and
we know that this crash is happening, add a bit of code
to prevent the timers from popping at all when we go
through and free up other data structures that we
are pointing at.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This creates `pim6_stubs.c`, which is intended to temporarily provide
stubbed-out definitions of some functions we don't have yet for IPv6.
This makes pim6d compile without the `PIM_V6_TEMP_BREAK` hack, and is
very important as an intermediate step to get a working environment for
further work.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This is just hitting the pim_mroute code with a hammer until it doesn't
print warnings anymore. This is NOT quite tested or working yet, it
just compiles.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Just fixing a bunch of compiler errors, this will NOT actually configure
IPv6 PIM properly.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Since `pim_sgaddr` is `pim_addr` now, that causes a whole lot of fallout
anywhere S,G pairs are handled.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
These are sprinkled relatively widely through the PIM codebase, so for
the time being reduce the "compiler warning surface" by moving them
forward to proper types without actual implementations.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
`show ip pim assert` shows S,G ifchannel information even when
there is no information available about the assert process.
Fix the code to not dump non-interesting cases.
Fixes: 10462
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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.
Fixes: #10422
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
In all places that pim_nht_bsr_del is called, the code
needs to not unregister if the current_bsr is INADDR_ANY.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
I'm now seeing in my log file:
2022/01/28 11:20:05 PIM: [Q0PZ7-QBBN3] attempting to delete nonexistent NHT BSR entry 0.0.0.0
2022/01/28 11:20:05 PIM: [Q0PZ7-QBBN3] attempting to delete nonexistent NHT BSR entry 0.0.0.0
2022/01/28 11:20:06 PIM: [Q0PZ7-QBBN3] attempting to delete nonexistent NHT BSR entry 0.0.0.0
When I run pimd. Looking at the code there are 3 places where pim_bsm.c removes the
NHT BSR tracking. In 2 of them the code ensures that the address is already setup
in 1 place it is not. Fix.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
XPATH_MAXLEN denotes the maximum length of an XPATH. It does not make
sense to allocate a buffer intended to contain an XPATH with a size
larger than the maximum allowable size of an XPATH. Consequently this PR
removes buffers that do this. Prints into these buffers are now checked
for overflow.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
VRF name should not be printed in the config since 574445ec. The update
was done for NB config output but I missed it for regular vty output.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Problem Statement:
==================
(rcv1)-----A----B---C
v3 enabled with src 90.0.0.1
|
(rcv2)--
v2 enable with src none
rcv1 sends the packet in INCLUDE mode, rcv2 sends the IGMPv2 report
and PIM convers this report into exclude mode.
As per the state machine the group structure was
getting added and deleted. As group gets deleted the mroute for 90.0.0.1
and recreated back.
This effects the end to end trafiic.
Root Cause Analysis:
====================
As per state machine
INCLUDE (A) IS_EX (B) EXCLUDE (A*B,B-A) (B-A)=0
Delete (A-B)
Group Timer=GMI
EXCLUDE (X,Y) TO_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y)=Group Timer
Delete (X-A)
Delete (Y-A)
Send Q(G,A-Y)
Group Timer=GMI
The above equations were getiing calulated for IP address
90.0.0.1 and 0.0.0.0
This results in group creation deletion.
Fix:
====
As per RFC 4604.
drop the exclude mode, IGMP reports, if destnation group is
SSM based.
EXCLUDE
mode does not apply to SSM addresses, and an SSM-aware router will
ignore MODE_IS_EXCLUDE and CHANGE_TO_EXCLUDE_MODE requests in the SSM
range,
Signed-off-by: Abhishek N R <abnr@vmware.com>
Signed-off-by: Vishal Dhingra <rac.vishaldhingra@gmail.com>
Problem Statement:
==================
(rcv1)-----A----B---C
v3 enabled with src 90.0.0.1
|
(rcv2)--
v3 enable with src none
rcv1 sends the packet in INCLUDE mode, rcv2 sends the IGMP report
in exclude mode. As per the state machine the group structure was
getting added and deleted. As group gets deleted the mroute for 90.0.0.1
and recreated back.
This effects the end to end trafiic.
Root Cause Analysis:
====================
As per state machine
INCLUDE (A) IS_EX (B) EXCLUDE (A*B,B-A) (B-A)=0
Delete (A-B)
Group Timer=GMI
EXCLUDE (X,Y) TO_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y)=Group Timer
Delete (X-A)
Delete (Y-A)
Send Q(G,A-Y)
Group Timer=GMI
The above equations were getiing calulated for IP address
90.0.0.1 and 0.0.0.0
This results in group creation deletion.
Fix:
====
As per RFC 4604.
drop the exclude mode, IGMP reports, if destnation group is
SSM based.
EXCLUDE
mode does not apply to SSM addresses, and an SSM-aware router will
ignore MODE_IS_EXCLUDE and CHANGE_TO_EXCLUDE_MODE requests in the SSM
range.
Signed-off-by: Abhishek N R <abnr@vmware.com>
Signed-off-by: Vishal Dhingra <rac.vishaldhingra@gmail.com>
These really don't serve much of a purpose, especially with how
inconsistently they're used.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Only pim_sgaddr uses are covered by this since regular in_addr is still
used for singular addresses, so only a part of pim_inet4_dump calls are
gone with this.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Renamed frr-igmp.yang to frr-gmp.yang, igmp to gmp container.
to support IGMP and MLD protocol.
frr-gmp.yang, created a list of address family under mgmd
container. For PIMV4 the key is IPV4, where as for PIMV6
the key is IPV6. This is done for PIMV6 development.
This commit will have all the northbound changes to support
IPV4 address family.
Signed-off-by: sarita patra <saritap@vmware.com>
Need a separate constant that is IPv6 when needed. Also assign the
whole struct rather than just s_addr.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Replaces comparison against INADDR_ANY, so we can do IPv6 too.
(Renamed from "pim_is_addr_any" for "pim_addr_*" naming pattern, and
type fixed to bool.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
... and replace with `%pSG` printfrr specifier. This actually used a
static buffer in the formatting function, so subsequent formatting would
overwrite earlier uses.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
frr-pim.yang, created a list of address family under pim
container. For PIMV4 the key is IPV4, where as for PIMV6
the key is IPV6. This is done for PIMV6 development.
This commit will have all the northbound changes to support
IPV4 address family.
Signed-off-by: sarita patra <saritap@vmware.com>
Fix the code as per RFC 2236 section 2.5:
Note that IGMP messages may be longer than 8 octets, especially
future backwards-compatible versions of IGMP. As long as the Type is
one that is recognized, an IGMPv2 implementation MUST ignore anything
past the first 8 octets while processing the packet. However, the
IGMP checksum is always computed over the whole IP payload, not just
over the first 8 octets.
Fixes: #10331
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
As per test case IGMP Conformance test case 5.6, report
messages longer than 8 octets should be accepted to support
future-backward compatibilty.
Fix the code as per RFC 2236 section 2.5:
Note that IGMP messages may be longer than 8 octets, especially
future backwards-compatible versions of IGMP. As long as the Type is
one that is recognized, an IGMPv2 implementation MUST ignore anything
past the first 8 octets while processing the packet. However, the
IGMP checksum is always computed over the whole IP payload, not just
over the first 8 octets.
Fixes: #10331
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Mostly just 2 sed calls:
- `sed -e 's%struct prefix_sg%pim_sgaddr%g'`
- `sed -e 's%memset(&sg, 0, sizeof(pim_sgaddr));%memset(\&sg, 0, sizeof(sg));%g'`
Plus a bunch of fixing whatever that broke.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Just putting the infrastructure in place and having it disabled is
actually good progress here; have the compiler make itself useful and
tell us what we have to do to get the basics right.
(The next commit will cause a *lot* of compile errors as soon as
`PIM_V6_TEMP_BREAK` is set; but there is no reason to force everything
into a single step here.)
To enable `pim_addr = in6_addr`, run `make PIM_V6_TEMP_BREAK=1` (remove
previous compile results with `rm pimd/pim6d-*.o`)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Depending on whether we're compiling pimd or pim6d, these types take on
the appropriate AF being used.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Since this is only used in very few places, moving it out of the way is
reasonable. (`%pSG` will be pim_sgaddr)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This newborn pim6d is essentially an empty husk, but it does build
without warnings or errors and has the build system integration prepared
and working.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Modifying the members of pim_interface which are to be used
for both IPv4 and IPv6 to common names(for both MLD and IGMP).
Issues: #10023
Co-authored-by: Mobashshera Rasool <mrasool@vmware.com>
Co-authored-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
Changed struct in_addr source_addr to struct PIM_ADDR source_addr
which is to be used in both IPv4 and IPv6(Both MLD and IGMP).
Reviewed-by: Mobashshera Rasool <mrasool@vmware.com>
Signed-off-by: sarita patra <saritap@vmware.com>
Changed struct in_addr upstream_addr and struct in_addr upstream_register
to struct PIM_ADDR upstream_addr and struct PIM_ADDR upstream_register
which are to be used in both IPv4 and IPv6(Both MLD and IGMP).
Reviewed-by: Mobashshera Rasool <mrasool@vmware.com>
Signed-off-by: sarita patra <saritap@vmware.com>
Changed struct in_addr last_lookup to struct PIM_ADDR last_lookup
which is to be used in both IPv4 and IPv6(Both MLD and IGMP).
Reviewed-by: Mobashshera Rasool <mrasool@vmware.com>
Signed-off-by: sarita patra <saritap@vmware.com>
Changed struct in_addr group_addr to struct PIM_ADDR group_addr
in struct igmp_group which is to be used in
both IPv4 and IPv6(Both MLD and IGMP).
Reviewed-by: Mobashshera Rasool <mrasool@vmware.com>
Signed-off-by: sarita patra <saritap@vmware.com>
Changed struct in_addr address to struct pim_addr in struct
pim_iface_upstream_switch which is to be used in both IPv4
and IPv6(Both MLD and IGMP).
Reviewed-by: Mobashshera Rasool <mrasool@vmware.com>
Signed-off-by: sarita patra <saritap@vmware.com>
Changed struct in_addr group to struct pim_addr group
which is to be used in both IPv4 and IPv6(Both MLD and IGMP).
Reviewed-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Changed struct in_addr source_addr to pim_addr source_addr
in struct igmp_source which is to be used in
both IPv4 and IPv6(Both MLD and IGMP).
Reviewed-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Changed struct in_addr source_addr to pim_addr source_addr
in struct igmp_join which is to be used in
both IPv4 and IPv6(Both MLD and IGMP).
Reviewed-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Based on compiler option, pim_addr will be changed to in_addr
or in6_addr for pimd and pim6d respectively.
Reviewed-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
This change is to accomodate IPv6 and IPv4 in the same code.
Based on pimd or pim6d, this will be compiled.
Reviewed-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Changed struct in_addr ifassert_winner to pim_addr
which will be used in both IPv4 and IPv6(Both MLD and IGMP).
Reviewed-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Added apis which will be decided on compile time
for pimd and pim6d daemon
Reviewed-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
PIM_ADDR will be controlled at compile time for IPv4 and IPv6.
in_addr and in6_addr will be compiled for the respective daemons.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
The zlog_warn used to be bounded by a debug guard
but the debug guard was removed but the code was
never fixed up to remove the open and close paranthesis.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently, it is possible to rename the default VRF either by passing
`-o` option to zebra or by creating a file in `/var/run/netns` and
binding it to `/proc/self/ns/net`.
In both cases, only zebra knows about the rename and other daemons learn
about it only after they connect to zebra. This is a problem, because
daemons may read their config before they connect to zebra. To handle
this rename after the config is read, we have some special code in every
single daemon, which is not very bad but not desirable in my opinion.
But things are getting worse when we need to handle this in northbound
layer as we have to manually rewrite the config nodes. This approach is
already hacky, but still works as every daemon handles its own NB
structures. But it is completely incompatible with the central
management daemon architecture we are aiming for, as mgmtd doesn't even
have a connection with zebra to learn from it. And it shouldn't have it,
because operational state changes should never affect configuration.
To solve the problem and simplify the code, I propose to expand the `-o`
option to all daemons. By using the startup option, we let daemons know
about the rename before they read their configs so we don't need any
special code to deal with it. There's an easy way to pass the option to
all daemons by using `frr_global_options` variable.
Unfortunately, the second way of renaming by creating a file in
`/var/run/netns` is incompatible with the new mgmtd architecture.
Theoretically, we could force daemons to read their configs only after
they connect to zebra, but it means adding even more code to handle a
very specific use-case. And anyway this won't work for mgmtd as it
doesn't have a connection with zebra. So I had to remove this option.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Problem:
=======
Generate query once cli is generating IGMPv2 report for IGMPv3 enabled interface
Description:
===========
If the version is not specified in the cli, it was taking version 2 as default
Fix:
===
If the version is not specified in the cli along with ip igmp generate-query-once,
the default will be the version enabled on that interface.
Signed-off-by: nsaigomathi <nsaigomathi@vmware.com>
Modifying name of struct igmp_sock to struct gm_sock, which is to be used
by both IPv4 and IPv6(for both MLD and IGMP).
Co-authored-by: Mobashshera Rasool <mrasool@vmware.com>
Co-authored-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
Modifying name of struct igmp_group to struct gm_group, which is to be used
by both IPv4 and IPv6(for both MLD and IGMP).
Co-authored-by: Mobashshera Rasool <mrasool@vmware.com>
Co-authored-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
Modifying name of struct igmp_source to struct gm_source, which is to be used
by both IPv4 and IPv6(for both MLD and IGMP).
Co-authored-by: Mobashshera Rasool <mrasool@vmware.com>
Co-authored-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
Fix:
====
Modifying name of struct igmp_join to struct gm_join, which is to be used
by both IPv4 and IPv6(for both MLD and IGMP).
Co-authored-by: Abhishek N R abnr@vmware.com
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Modifying the members of pim_interface which are to be used
for both IPv4 and IPv6 to common names(for both MLD and IGMP).
Issue: #10023
Co-authored-by: Mobashshera Rasool <mrasool@vmware.com>
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
RCA: When upstream transition from Joined to NotJoined due to SGRpt
prune, then only SGRpt prune was sent and SG Prune is missed.
Fix: Send SG Prune towards source as well as SGRpt prune towards RP.
Signed-off-by: sarita patra <saritap@vmware.com>
Since f60a1188 we store a pointer to the VRF in the interface structure.
There's no need anymore to store a separate vrf_id field.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Problem Statement:
==================
on rp_change, PIM processes all the upstream in a loop and for selected
upstreams PIM has to send join/prune based on the RPF changed.
join and prune packets are not getting aggregated in a single packet.
Root Cause Analysis:
====================
on pim_rp_change pim_upstream_update() gets called for selected upstreams.
This API calculates to whom it has to send join and to whom it has to
send prune via API pim_zebra_upstream_rpf_changed(). This API peprares
the upstream_switch_list list per interface and inserts the group and
sources.
Now PIM is still in the pim_upstream_update() API context, i.e PIM
is still processing the same upstream. In the last there is a
call to pim_zebra_update_all_interfaces() which processes the
upstream_switch_list list, sends the packets out and clears the list.
Fix:
====
Don't process the upstream_switch_list in the upstream context.
process all the upstreams prepare the upstream_switch_list and then
process in one go. This will club all the S,G entries.
It also saves list cleanup with respect to memory allocation and
deallocation multiple times.
Signed-off-by: Vishal Dhingra <rac.vishaldhingra@gmail.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
`pim_ifchannel_ifjoin_switch()` changes flags that `pim_forward_stop()`
looks at. This leads to data flow continuing until we have some reason
to sync state again.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
rp-count==0 isn't a broken BSM, it just means the BSR no longer has any
Candidate RPs for the group range. Previous behavior is badly mistaken
since it stops processing the entire packet.
Fix to correctly remove group range on rp-count==0 and continue
processing remainder of the packet.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
NHT won't have a result yet when we get the first BSM from a new BSR.
Hence, the first packet(s) are lost, since their RPF validation fails.
Re-add the blocking RPF check that was there before (though in a much
more sensible manner.)
Also nuke the now-unused pim_nexthop_match* functions.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
... where it actually belongs. And make a bunch of stuff static, since
it's no longer used across files now.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The Bootstrap message RX path needs a RPF check for the BSR address,
and this is implemented both incorrectly as well as quite ugly.
Clean up and fix case when we have multiple interfaces to the same LAN
and/or ECMP nexthops (both would cause message duplication, the former
can even cause BSM forwarding loops.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Most users of if_lookup_address_exact only cared about whether the
address is any local address. Split that off into a separate function.
For the users that actually need the ifp - which I'm about to add a few
of - change it to prefer returning interfaces that are UP.
(Function name changed due to slight change in behavior re. UP state, to
avoid possible bugs from this change.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
We should always treat the VRF interface as a loopback. Currently, this
is not the case, because in some old pre-VRF code we use if_is_loopback
instead of if_is_loopback_or_vrf. To avoid any future problems, the
proposal is to rename if_is_loopback_or_vrf to if_is_loopback and use it
everywhere. if_is_loopback is renamed to if_is_loopback_exact in case
it's ever needed, but currently it's not used anywhere.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
These really serve no purpose other than slowing our build down. If
there's a benefit to any of these, they can be readded.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
We had various forms of min/max macros across multiple daemons
all of which duplicated what we have in compiler.h. Convert
everyone to use the `correct` ones
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
enum based switches should never use default. It makes
it very hard to fix and find issues when the enum is
changed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
pim-vxlan uses periodic null registers to bootstrap a new (VTEP, mcast-grp).
These null registers were not being sent if the (S, G) was already present
and in a register-join state.
Ticket: #2848079
Signed-off-by: Anuradha Karuppiah <anuradhak@nvidia.com>
frr-reload fails to recognize wildcard "*" for
member address in frr.conf/runing-config as cli
syntax expects in v4 address format.
Ticket: #2816923
Testing:
Without fix:
running config:
ip msdp mesh-group foo1 member *
Frr reoad failure log:
2021-11-02 11:05:04,317 INFO: Loading Config object from vtysh show running
line 5: % Unknown command: ip msdp mesh-group foo1 member *
Traceback (most recent call last):
File "/usr/lib/frr/frr-reload.py", line 1950, in <module>
With fix:
--------
running config displays:
ip msdp mesh-group foo1 member 0.0.0.0
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Problem Statement:
==================
Mroutes are not recovered after shut/no shut of DUT to RP links
One interface is not added in OIL List in intermediate router,
hence traffic never received at LHR and mroutes not created for (S,G).
Root Cause Analysis:
====================
Generally (*,G) PIM Join is received first and then (S,G) joins are received.
This issue occurs when (S,G) join comes first and then the (*,G) Join.
When (S,G) PIM Join is received, ifchannel is created and channel_oil
OIF flag is set to PIM_OIF_FLAG_PROTO_PIM. Now when (*,G) join is received
the flag PIM_OIF_FLAG_PROTO_STAR is not inherited due to wrong check present in
function pim_upstream_inherited_olist_decide.
Fix:
===================
When (*,G) PIM Join is received, it should always add PIM_OIF_FLAG_PROTO_STAR
flag for all the (S,G) channel oils no matter what order the (*,G) or (S,G)
is received.
Fixes: #9918
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Problem:
-------
(*,G) created on transit node where same groups are defined as SSM
At present FRR has SSM checks for IGMP report, but SSM check is missing for PIM join.
Fix:
----
Whenever there is a modification in prefix list for SSM range, then we need to browse the ifchannels (PIM joins)
and groups coming in SSM range with (and *,G) should be removed from ifchannel database and also withdraw those routes
from upstream routers.
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
Problem :
=======
(*,G) created on transit node where same groups are defined as SSM
At present FRR has SSM checks for IGMP report, but SSM check is missing for PIM join.
Fix :
===
When an interface receives the PIM (*,G)join with G as SSM group, then PIMd supposed to discard that join.
There is no need to maintain PIM state for this group.
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
This removes a giant `switch { }` block from lib/zclient.c and
harmonizes all zclient callback function types to be the same (some had
a subset of the args, some had a void return, now they all have
ZAPI_CALLBACK_ARGS and int return.)
Apart from getting rid of the giant switch, this is a minor security
benefit since the function pointers are now in a `const` array, so they
can't be overwritten by e.g. heap overflows for code execution anymore.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
It allows FRR to read the interface config even when the necessary VRFs
are not yet created and interfaces are in "wrong" VRFs. Currently, such
config is rejected.
For VRF-lite backend, we don't care at all about the VRF of the inactive
interface. When the interface is created in the OS and becomes active,
we always use its actual VRF instead of the configured one. So there's
no need to reject the config.
For netns backend, we may have multiple interfaces with the same name in
different VRFs. So we care about the VRF of inactive interfaces. And we
must allow to preconfigure the interface in a VRF even before it is
moved to the corresponding netns. From now on, we allow to create
multiple configs for the same interface name in different VRFs and
the necessary config is applied once the OS interface is moved to the
corresponding netns.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
FRR should only ever use the appropriate THREAD_ON/THREAD_OFF
semantics. This is espacially true for the functions we
end up calling the thread for.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Problem Statement:
==================
On new neighbor addition, the tx counter for hello msg is reset.
Fix:
=================
Do not reset the tx counter on new neighbor addition.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Problem Statement:
==================
pim maintains two counters hello tx and hello rx at interface level.
At present pim needs to send the hello message prior to other pim
message as per RFC. This logic is getting derived from the tx hello
counters. So when a new neighbor is added, tx counters are set to
zero and then based on this, it is further decided to send hello in
pim_hello_require function.
Fix:
====
Separating the hello statistics and the logic to decide when to send hello
based on a new flag. pim_ifstat_hello_sent will be used to note down
the hello stats while a new flag is added to decide whether to send hello
or not if it is the first packet to a neighbor.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Deleting a mesh-group member no longer deletes the mesh-group.
Complete bug description at:
https://github.com/FRRouting/frr/issues/9664
Signed-off-by: Adriano Marto Reis <adrianomarto@gmail.com>
This `XFREE()` call is in plainly in the wrong spot. `rp_all` (the
224.0.0.0/4 entry) isn't supposed to be free'd ever, and the
conditional above makes quite clear that it remains in use.
It may be possible to exploit this as a heap corruption bug, maybe even
as RCE. I haven't tried; I randomly noticed this while working on the
BSM code. Luckily this code is only run by the CLI for the clear
command, so the surface is very small.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
pim_msdp_peer_rpf_check creates an nexthop to do
a rpf search against and doesn't initialize it
sucht that the pim_nexthop_lookup function is
making decisions against the nexthop just
created that was uninitialized.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This makes a lot more sense semantically (and matches the way groups are
handled.) Also allows placing additional restrictions on source
creation (e.g. limit on number of sources or ACLs.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Intentionally separate here because the previous patch does a whole
bunch of "move stuff up 1 level of indentation", and reviewing that is
easier when you can use the ignore-whitespace option on diff.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
IGMP group/source memberships are a property of the interface; the
particular IP address that the querier used to collect the data is
irrelevant.
... and IGMP packets get delivered only once to pimd anyway, since we
receive them on the "global" per-VRF IGMP socket. (The one in igmp_sock
is only used for sending queries.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
pimd's include files are very interdependent. Let's chop that down a
bit to gain some flexibility.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Problem
======
In pim_msg_send_frame api, the while loop was executed only once.
Fix
===
while is changed to if, as in the code flow
the while part is getting executed only once.
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
Problem :
=======
When all the groups from Ixia are stopped,
groups still keep refreshing and not getting timeout
RCA:
====
IGMP Report is coming in include mode without any source address, this problem will come.
Fix :
===
If the requested filter mode is INCLUDE *and* the requested
source list is empty, then the entry corresponding to the
requested interface and multicast address is deleted if present.
If no such entry is present, the request is ignored.
When an interface receives the IGMP report without any source, then the group is deleted.
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
There is a possibility that the same line can be matched as a command in
some node and its parent node. In this case, when reading the config,
this line is always executed as a command of the child node.
For example, with the following config:
```
router ospf
network 193.168.0.0/16 area 0
!
mpls ldp
discovery hello interval 111
!
```
Line `mpls ldp` is processed as command `mpls ldp-sync` inside the
`router ospf` node. This leads to a complete loss of `mpls ldp` node
configuration.
To eliminate this issue and all possible similar issues, let's print an
explicit "exit" at the end of every node config.
This commit also changes indentation for a couple of existing exit
commands so that all existing commands are on the same level as their
corresponding node-entering commands.
Fixes#9206.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
While defaults are good picks for "reasonable" guesses, min and max
range values really aren't. Operators and experimenters often like to
configure "unreasonable" values to stress test, tests boundary
conditions and explore innovations.
With that in mind, change all ranges to 1..max (of type).
While we're here add optional ignored values in the "no" CLI forms.
Signed-off-by: Christian Hopps <chopps@labn.net>
Problem Statement:
==================
IGMP query is sent at irregular intervals
(more than 30 seconds) when "ip igmp query-max-response-time 100"
command is executed multiple times.
RCA:
=================
When "ip igmp query-max-response-time 100" is executed, the timers
are reset resulting in the delay of sending the query.
Fix:
=================
When there is no change in the config value, we should not reset
the timers.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
When we decide that we do not need a item on the partial_bsrp_list
don't just drop the memory on the floor, free it up.
This was happening when we decided that a pending item has
a hold time of 0.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Some no commands were not accepting values and left us in
a situation where a cut-n-paste of the non-no line would
not be properly accepted.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The only difference in daemons' interface node definition is the config
write function. No need to define the node in every daemon, just pass
the callback as an argument to a library function and define the node
there.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
This commit is to correct the order in which the fields are
accessed while verifying it. First the fields should be
verified, and if it is valid then access it.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Allow the join-prune interval to be as small as 5 seconds instead
of limiting the value to 60.
This can and will come at a price of being able to converge less
mroutes.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
IGMPv3 packets with invalid TOS should be dropped.
Test Case ID: 4.10
TEST_DESCRIPTION
Every IGMP message described in this document is sent with
IP Precedence of Internetwork Control (e.g., Type of Service
0xc0)
(Tests that IGMPv3 Membership Query Message conforms to
above statement)
TEST_REFERENCE
NEGATIVE: RFC 3376, IGMP Version 3, s4 p7 Message Formats
Issue: #9071
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
IGMPv3 packets with invalid TTL should be dropped.
Test Case ID: 4.10
TEST_DESCRIPTION
Every IGMP message described in this document is sent with an IP
Time-to-Live of 1 (Tests that IGMPv3 Membership Report Message
conforms to above statement)
TEST_REFERENCE
NEGATIVE: RFC 3376, IGMP Version 3, s4 p7 Message Formats
Issue: #9070
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Problem Statement:
==================
valgrind shows memleaks in rp_table, when pimd shuts down gracefully.
2020-05-05 22:09:29,451 ERROR: Memory leaks in router [r4] for daemon [pimd]
2020-05-05 22:09:29,451 ERROR: Memory leaks in router [r4] for daemon [zebra]
2020-05-05 22:09:29,637 ERROR: Found memory leak in module pimd
2020-05-05 22:09:29,638 ERROR: ==6178== 184 (56 direct, 128 indirect) bytes in 1 blocks are definitely lost in loss record 21 of 21
2020-05-05 22:09:29,638 ERROR: ==6178== at 0x4C2FFAC: calloc (vg_replace_malloc.c:762)
2020-05-05 22:09:29,638 ERROR: ==6178== by 0x4E855EE: qcalloc (memory.c:111)
2020-05-05 22:09:29,638 ERROR: ==6178== by 0x4EAA43C: route_table_init_with_delegate (table.c:52)
2020-05-05 22:09:29,638 ERROR: ==6178== by 0x1281A1: pim_rp_init (pim_rp.c:114)
2020-05-05 22:09:29,638 ERROR: ==6178== by 0x11D0F8: pim_instance_init (pim_instance.c:117)
2020-05-05 22:09:29,638 ERROR: ==6178== by 0x11D0F8: pim_vrf_new (pim_instance.c:150)
2020-05-05 22:09:29,638 ERROR: ==6178== by 0x4EB1BEC: vrf_get (vrf.c:209)
2020-05-05 22:09:29,638 ERROR: ==6178== by 0x4EB2B2F: vrf_init (vrf.c:493)
2020-05-05 22:09:29,638 ERROR: ==6178== by 0x11D227: pim_vrf_init (pim_instance.c:217)
2020-05-05 22:09:29,638 ERROR: ==6178== by 0x11BBAB: main (pim_main.c:121)
Fix:
====
rp_info is allocated in pim_rp_init API. rp_info pointer is present
in rp_list and rp_table. In rp_list cleanup, the memory for rp_info
gets freed. rp_table clean up should be done first and then rp_list.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Problem:
S,G entry has iif = oif in FHR is LHR case.
Setup:-
R11-----R2----R4
R11 :- FHR and LHR
R2 :- RP
R4 :- LHR
Issue :-
1) shut mapped interface in R11
2) wait for 5 min
3) do FRR restart
5) No shut of mapped interface
OIL is added for local interface also where OIL is same as IIF
and duplicate traffic observed on R4 receives in Ixia
RCA:
pim_ifchannel_local_membership_add adds inherited oif from starg when iif for
SG is unavailable.
When rpf for that SG resolves to this inherited oif from starg, iif is also in oif.
This results in dup traffic.
Fix:
If iif is not available, do not inherit from starg.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Problem Statement:
In Prune pending state, when Join is received, and there is hold timer change
the Expiry timer is not getting updated with new Hold timer.
Root Cause:
When thread_add_timer function is called and the thread is already in the list
the thread api just returns, it does not modify the timer value.
So when we want to change the timer, we need to first call THREAD_OFF and then
call thread_add_timer.
The Expiry timer thread is not cancelled in PIM_IFJOIN_PRUNE_PENDING state,
therefore the timer change is not taking effect.
Fix:
Call THREAD_OFF in that flow.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Making the interface holdtime range to 3.5 times the hello-time
As per 7761, Section 4.11:
The Holdtime in a Hello message should be set to
(3.5 * Hello_Period), giving a default value of 105 seconds.
Therefore providing the user also to configure max upto 3.5 times
the hello timer interval.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
When we have a "192.0.2.1 peer 192.0.2.2/32" address on an interface, we
need to (a) recognize the local address as being on the link for our own
packets, and (b) do the IGMP socket lookup with the proper local address
rather than the peer prefix.
Fixes: efe6f18 ("pimd: fix IGMP receive handling")
Cc: Nathan Bahr <nbahr@atcorp.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
1. Add the querierIP object to igmp_sock datastruct to save the IP address of the querier.
Management of the querierIP object is added.
2. To show the querier IP address in the CLI "show ip igmp interface".
3. To add the json object querierIP for querier IP address in the json CLI "show ip igmp interface json".
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
... the PIM code is kinda misusing prefix lists to match addresses.
Considering the weird semantics of access-lists, I can't fault it.
However, prefix lists aren't great at matching addresses by default,
since they try to match the prefix length too. So, here's an "address
match mode" for prefix lists to get that to work more reasonably.
Fixes: #8492
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
There's an IGMP socket per interface, so they should be bound to that
interface. Which also makes IGMP work in VRFs.
Fixes: #7889
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
