By changing this API call to use a `struct ipaddr`, which encodes the
type of IP address with it. (And rename/remove the `IPV4` from the
command name.)
Also add a comment explaining that this function call is going to be
obsolete in the long run since pimd needs to move to proper MRIB NHT.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The normal flag was enabling detail messages, but what we want is the
detail flag enabling normal messages.
Remove the _ONLY macro while at it, it's only used for config print &
that seems like a place where making the difference explicitly visible
is helpful regardless.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Modifying the "mld_group_watermark_cmd" to "ipv6_mld_group_watermark_cmd"
and "igmp_group_watermark_cmd" to "ip_igmp_group_watermark_cmd" for consistency.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
5421bf8 commit forgot to set the parameter "new" to true
when a new source is created, have fixed it.
igmp_get_source_by_addr api is currently setting the parameter
"new" to false always. This is not right. The caller apis are using
this field to decide and based on that take actions to create timers, etc.
Its need to be set to true when a new source is created.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
frr(config-if)# ip igmp join 232.1.1.1 10.10.10.10
frr(config-if)# do sh ip igmp sources
Interface Address Group Source Timer Fwd Uptime
ens192 232.1.1.1 10.10.10.10 04:10 N 00:00:10
frr(config-if)#
The above output is misaligned and is having Address field which is not
required here.
Fixing it.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
I should've removed this in #10960. It's a hazard in terms of
forgetting to adjust PRs/other changes that might accidentally still
reference the field.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Just simple helpers to get a scope value, never-forward, and is-SSM for
a given address.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Currently pim_zlookup_nexthop 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>
In this PR, we are handling the igmp_mtrace code
after mrib_nexthop_addr modified from prefix
to pim_addr.
Signed-off-by: sarita patra <saritap@vmware.com>
In this PR, we are handling the pim_rpf code
after mrib_nexthop_addr modified from prefix
to pim_addr.
Signed-off-by: sarita patra <saritap@vmware.com>
Currently mrib_nexthop_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>
Adding the config mode command
ipv6 mld watermark-warn <1-65535>
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>
Adding the Interface level config command
ipv6 mld last-member-query-interval (1-65535)
This command can be use to tune the response time for group specific queries.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Adding the Interface level config command
ipv6 mld last-member-query-count (1-255)
This command can be use to tune the number of Multicast-Address- Specific Queries
sent before the router assumes there are no remaining listeners for an address on a link.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Adding the Interface level config command
ipv6 mld query-max-response-time <1-65535>
This command can be use to tune the max response time for general queries.
The number of seconds represented by the [Query Response Interval] must be less than the [Query Interval]
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
The entire `case NEXTHOP_TYPE_IPV6_IFINDEX:` block here was a bit of a
tripwire to stumble over, since there was no indication at all that this
concerns RFC5549 nexthop handling. So it got mis-adapted for PIM IPv6
support.
Clarify this a whole bunch that this is for v4-over-v6 nexthop mangling,
and nothing else.
This should really also use neighbor's secondary address lists for the
lookup, but that is probably going to break compatibility with other
boxes that don't include v6 addrs in v4 hellos and needs further
machinery to do properly, so for now just leave a breadcrumb.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
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>
