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>
Register and Null register send handling
In IPv6 PIM Null Register message if dummy PIM Header is included as
data, this dummy PIM header checksum needs to be valuated
Signed-off-by: plsaranya <Saranya_Panjarathina@dell.com>
Within one Address List Hello option, all the addresses MUST be of
the same address family. It is not permitted to mix IPv4 and IPv6
addresses within the same message. In addition, the address family
of the fields in the message SHOULD be the same as the IP source and
destination addresses of the packet header.
Signed-off-by: sarita patra <saritap@vmware.com>
There's a common pattern of "get VRF context for CLI node" here, which
first got a helper macro in zebra that then permeated into pimd.
Unfortunately the pimd copy wasn't quite adjusted correctly and thus
caused two coverity warnings (CID 1517453, CID 1517454).
Fix the PIM one, and clean up by providing a common base macro in
`lib/vty.h`.
Also rename the macros (add `_VRF`) to make more clear what they do.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The ICMP6_FILTER option is always checked by the kernel, so the cost is
taken whether or not anything is set there. Use it instead of taking on
additional cost with a BPF program.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
1. Adding a field family in the existing ZEBRA_IPMR_ROUTE_STATS
to get the ipv4 as well as ipv6 trafic stats between pim and zebra.
2. Modify the debug to print both v4/v6 prefixes
pimd: pim6d: Modify pim_zlookup_sg_statistics to get ipv6 stats
Modify the pim_zlookup_sg_statistics api to
get ipv4/ipv6 stats from zebra. Making the api
common.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
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>
