When trying to track down a MTYPE_TMP memory leak
it's harder to search for it when you happen to
have some usage of ttable_dump. Let's just give
it it's own memory type so that we can avoid
confusion in the future.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Moved all existing global/vrf PIM config to the new subnode.
Existing configuration updated to be hidden and deprecated.
Both versions of configuration still work together.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
Somehow this tiny function ended up being written in a very convoluted
way that enabled the braces mixup in the previous commit. Rewrite it to
be less confusing.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The `!rp_info ||` check got added during a cleanup pass. Unfortunately
the braces/and/or combination is not correct :(
Fixes: b1945363fb ("pimd: Various buffer overflow reads and crashes")
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
When turning on debug pim trace, there are lots of messages
surrounding the timing of rpf lookup. 99% of the time
no-one cares about these anymore. Let's make them
not seen unless we turn up debugs
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add a hash_clean_and_free() function as well as convert
the code to use it. This function also takes a double
pointer to the hash to set it NULL. Also it cleanly
does nothing if the pointer is NULL( as a bunch of
code tested for ).
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Topology:
========
FHR----Source
Problem:
=======
When FHR receives multicast traffic, there is no RP configured,
PIMD does NHT register for RP address 0.0.0.0 and group 224.0.0.0/4
PIM6D does NHT register for RP address 0::0 and group FF00::0/8
frr# show ip pim nexthop
Number of registered addresses: 1
Address Interface Nexthop
---------------------------------------------
frr# show ipv6 pim nexthop
Number of registered addresses: 1
Address Interface Nexthop
---------------------------------------------
Fix:
====
Dont track nexthop for RP 0.0.0.0 & 0::0.
frr# show ip pim nexthop
Number of registered addresses: 0
frr# show ipv6 pim nexthop
Number of registered addresses: 0
Issue: #12104
Signed-off-by: Sarita Patra <saritap@vmware.com>
Problem:
frr(config)# show ip pim rp-info
RP address group/prefix-list OIF I am RP Source Group-Type
109.0.0.3 224.0.0.0/4 ens192 no Static ASM
frr(config)# int ens192
frr(config-if)# no ip pim
frr(config) show ip pim rp-info
RP address group/prefix-list OIF I am RP Source Group-Type
109.0.0.3 224.0.0.0/4 ens192 no Static ASM
rp-info OIF is still having ens192 which is PIM disabled.
Fixing this as part of this PR.
Issue: #12044
Signed-off-by: Sarita Patra <saritap@vmware.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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
