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>
