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