Replace cli 'debug static' with 'debug pim static', to make
the 'debug static' node available for staticd (eventually).
Signed-off-by: Mark Stapp <mjs@voltanet.io>
The decision for Update_SPTbit(S,G, iif) includes a test
for JoinDesired(S,G) in section 4.2.2. When we were deciding
to update the spt bit we were not taking this into account.
This commit fixes this issue.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we receive a S,G join and the ifchannel is in S,G RPT Prune state,
pim should transition the ifchannel state to JOIN and transition the
pim_upstream state for the S,G stream.
Ticket: CM-24513
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
pim was sending a triggered response on every S,G RPT prune information
read. Suppose we had this in a *,G message:
*,G
S1, G RPT Prune
S2, G RPT Prune
We would send two triggered *,G messages upstream. This leads to over
processing and quickly changing state if S1 or S2 were in different
states.
Modify the code to send just one Triggered *,G upstream after looking
at all S,G state for a *,G.
Ticket: CM-24531
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
On the LHR after we decide that traffic is flowing and
we set the SPT bit for the S,G *and* the incoming IIF
of the S,G is different than the incoming IIF of the *,G
we should immediately send the *,G S,G RPT Prune as
a triggered response instead of waiting for the next
cycle.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Track whether or not we have received an answer from
our query to do nexthop tracking. This allows us to
go straight to doing a synchronous query for our
RPF.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Start the separation of tracking a Destination from the act
of looking it up. The cojoining of these two concepts led
to a bunch of code that had to think about both problems leading
to weird situations and code paths. Simplify the code by making
pim_ecmp_nexthop_search a static function and we only ever
call pim_ecmp_nexthop_lookup when we need to do a RPF().
pim_ecmp_nexthop_lookup will now attempt to find a stored pnc
and if it finds one it will report on the answer from it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When creating new RP information from a `ip pim rp A.B.C.D/M A.B.C.D`
we should determine if we are the RP even if we can or cannot
determine if we have a path to the RP via RPF.
This is because we should determine if we are the RP based upon a
connected ip address match not whether or not we have a path to
the RPF. We would normally think this is not important but
RPF is inherently asynchronous and we can have a state where
we have registered for nht but have not received the actual
path back yet from zebra.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The current reverse logic led to this code construct
if (!pim_nexthop_lookup(...)) {
//Do something successfull
}
This is backwards and will cause logic errors when people
use this code. Fix to use true/false for success/failure.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a new pim neighbor comes up, we need to go through and
mark nexthops that we have received from zebra for reachability
tracking so we can refigure stuff. If we pass in the new neighbor
we can limit the search to those nexthops out the interface that
the new neighbor has come up.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The pim_resolve_upstream_nh function call is no longer being used
let's remove it from the code base.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Issue: (*,G) mroute uptime is not updated in mroute table,
after deleting and adding the RP
Root cause: When RP gets deleted or becomes not reachable, then
we un-install the entry from the kernel, but still maintains the
entry in the stack. When RP gets re-configured or becomes reachable,
"show ip mroute" shows the uptime, when the channel_oil gets created.
Fix: Introduce a new time mroute_creation in the channel_oil, gets
updated when mroute gets installed in the kernel.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When we delete an interface, we need to set the interface
ifindex to an internal value so that we don't end up in
a state where the re-addition of the same ifindex, due to
a rename operation, causes an infinite loop.
Fixes:#4007
Fix-Suggested-by: Saravanan K
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are displaying S,G string data we already auto
display the string as (S,G) no need to have ((S,G)).
Cleanup some that were found during log look through.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The pim_rp_check_is_my_ip_address function was checking to see
if we were the actual RP as well as the pim_register code
was doing the same thing. Remove the reduncancy a bit and
just make this function check for that we are the actual receiver
of this data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The code as written will scan the entirety of all pim upstreams
on a rpf change, this is not necessary because we know that when
we get a nexthop change we already scan the upstreams reliant
on that and do this work. There is no need to do this again a
short time later.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The interface column in pim was limited to 8 or 9 columns
all over the place in pim, fix the code up to allow interface
length to be up to 16 columns.
Ticket: CM-23083
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are shutting down, delay the zlookup free to as
late as possible since we may need it still
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Suppose we have 2 routers A and B. Both Router A and B have
the same priority of 1000. Router A is the elected DR.
Now suppose B lowers his priority to 1. He still looses the
DR election and we are not sending a hello with the new priority.
Immediately after this A's priority is also lowered to 1, it
looses the election and sends the hello. B receives this hello
and elects A as the DR( since it has the better ip address)
At this point A believes B is the DR, and B believes A is the
DR until such time that the normal hello from B is sent to A,
which if timed correctly can be a significant amount of time).
This code just causes a hello to be sent if the priority is
changed. Now both sides will be able to converge quickly
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When RP gets deleted, find all the (*, G) upstream whose group belongs to
the deleted RP, release the upstream from pnc->upstream_hash in the function
pim_delete_tracked_nexthop().
Signed-off-by: Sarita Patra <saritap@vmware.com>
When a RP gets deleted, find all the (*, G) upstream whose
group belongs to the deleted RP.
case 1: if the group belongs to any other rp, then call
pim_upstream_update() to update the upstream addr and rpf
information.
case 2: If no RP found for the group, then clear the pim
upstream address and rpf information.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When a new RP is configured, find all the (*, G) upstream whose
group belongs to the new RP and then update the upstream structure
with the below fields.
1. De-register for the old RP.
2. Set the upstream address as new RP
3. Register for the new RP.
4. Update the upstream rpf information and kernel multicast forwarding
cache(MFC), if the new RP is reachable.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When route to RP gets modified, FRR receives a notification from
zebra, and call the function pim_resolve_upstream_nh() to compute the
nexthop and update upstream->rpf structure.
Issue: In case when RP becomes not reachable, FRR only uninstall
the mroute from the kernal, but not update the upstream->rpf structure.
Fix: When FRR receives a notification from zebra saying RP becomes
not reachable, then update the following fields.
1. update channel_oil incoming interface as MAXVIFS
2. Un-install the mroute from the kernel.
3. Switch upstream state from JOINED to NOTJOINED.
4. Clear the nexthop information of the upstream.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When route to RP gets modified, FRR receives a notification from
zebra, and call the function pim_update_rp_nh() to compute the
new nexthop and will update the source_nexthop information of
rp_info. This is not working for the case when RP becomes not
reachable.
Fix: When FRR receives a notification from zebra saying RP becomes
not reachable, then delete the source_nexthop informatio of rp_info.
Signed-off-by: Sarita Patra <saritap@vmware.com>
In this commit, we are creating a dummy upstream & dummy channel_oil
for (*, G) when RP is not configured or not reachable.
Dummy upstream: <upstream_addr = INADDR_ANY, rpf = Unknown>
Dummy channel oil: <iif = MAXVIFS>
Signed-off-by: Sarita Patra <saritap@vmware.com>
When FRR receives IGMP/PIM (*, G) join and RP is not configured or not
reachable, then we are creating a dummy upstream with incoming interface
as NULL and upstream address as INADDR_ANY.
Added upstream address and incoming interface validation where it is necessary,
before doing any operation on the upstream.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When FRR receives IGMP/PIM (*, G) join and RP is not configured or
not reachable, then we are creating a dummy upstream with incoming
interface as NULL.
Added some null checks for the incoming interface, while displaying
the pim upstream information in the cli command "show ip pim upstream".
Signed-off-by: Sarita Patra <saritap@vmware.com>
