When we get a callback for a specific (S,G) and
we have no ifchannel for it, see if we have a
(*,G) channel and handle it appropriately.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we handle the thread arguments,
there is no need to assert. As that
if they are wrong, we are going down
shortly anyways.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This commit includes -
1. Maintaining SA cache with local and remote entries.
2. Local SA entries - there are two cases where we pick up these -
- We are RP and got a source-register from the FHR.
- We are RP and FHR and learnt a new directly connected source on a
DR interface.
3. Local entries are pushed to peers immediately on addition and
periodically. An immediate push is also done when peer session is
established.
4. Remote SA entries - from other peers in the mesh group and passed
peer-RPF checks.
5. Remote entries are aged out. No other way to del them
currently. In the future we may add a knob to flush entries on
peer-down.
Testing done -
Misc topologies with CL routers plus basic interop with another vendor (
we can process their SA updates and they ours).
Sample output -
root@rp:~# vtysh -c "show ip msdp sa"
Source Group RP Uptime
33.1.1.1 239.1.1.2 local 00:02:34
33.1.1.1 239.1.1.3 local 00:02:19
44.1.1.1 239.1.1.4 100.1.3.1 00:01:12
44.1.1.1 239.1.1.5 100.1.3.1 00:00:55
root@rp:~#
Ticket: CM-13306
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we decide to ignore a incoming packet, allow detailed
debugging to give a pointer to where to go to understand the
issue.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we have a FHR/RP/LHR all on the same box, we were
experiencing a situation where we were not sending
a register stop nor where we setting the sptbit.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
fd
When we are looking up the incoming interface for the ipmr
call back socket from the kernel, look to see if the src
is connected as well as has a valid pim_ifp to use.
This is to allow vrr configuration in a mlag env.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Fix possible double free of upstream and in
addition add some debug code to help find
where the problem is coming from.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we receive a igmp message through the kernel upcall, make
sure that we are configured to work on that interface via pim/igmp
before attempting to use that interface.
Ticket: CM-13338
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we have pim_mroute.c or pim_register.c create
the upstream state, only delete it then when
the KAT timer expires, else we will not have
the refcount right and we will do bad things.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we have intentionally not installed a mroute( for whatever
reason ), do not ask for information about that mroute from the
kernel when it happens.
Ticket: CM-12986
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Pim is outputting a bunch of unprotected debugs.
In a system with a high # of events even with
no logging we will receive lots of messages.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The kernel now reports lastused as the time in hz since
we last saw any packets. So let's start tracking it
that way.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When you send a register stop it is not necessary to
have a neighbor out the choosen interface.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we do a RPF lookup return a path that we have
neighbors for in those cases where we need to have
a neighbor to pass along the SG state via a pim
join/prune message.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Pim sometimes needs the upstream rpf lookup to
only take into account if we have a nbr out
the selected interface or not. Move
the code for this to a better spot so
we can make a more intelligent decision
here.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We need the ability to know where upstream state
comes from and to do the right thing from there.
ticket: CM-12771
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
mrib_nexthop_addr and rpf_addr should be 'struct prefix'
so that we can safely handle unnumbered data from a nexthop
lookup in zebra
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This has 2 fixes:
On nocache event, crate the channel oil first in
case we don't need to actually create the upstream
information
on wrvifwhole, create the channel oil and install
it, then only create the upstream information
if we are connected to the source.
Ticket: CM-12593
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Move the pim_mroute_conected_to_source function to pim_iface.c
because this is a interface question not a mroute question.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
On the RP when we receive a register packet for the
same interface that we received the *,G join on
allow the RP to receive the packets but to do
nothing with them.
Additionally check the last_used values even
if the ioctl fails.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When sending register packets to the RP from the FHR
we should be using the ip address of the incoming interface
that received the mcast packet.
Ticket: CM-12445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
I tried to be smart and skirt around rpf lookup if I knew
the incoming interface. This turns out to be not necessarily
a good thing because we can easily have asymetrical routing.
This fix removes the attempt to cache the ifp we received
the incoming packet on and just lets the lookup work like
it should.
Additionally it removes the weird hardcoding of the rpf
interface from the register stuff.
Ticket: CM-12530
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
reb
Ensure that when an upstream is removed that we actually
remove the route
Also when we get a callback for whole packet before
we send a register stop make sure we are actually on the
RP.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When there is allot of IGMP activity for the
kernel upcall that we are ignoring, just
ignore it for the moment as well.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When on the RP, if we receive the first correctly routed
mroute from upstream, Set the SPT bit so that the
state machine will work properly.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The RP was not properly handling the series of events:
1) When a WRVIFWHOLE is received if we are the RP,
send a pim register stop to the FHR.
2) When a register was received we were sending
a join (S,G) towards the S, then a immediate prune (S,G)
followed by another join (S,G). Just send the first join
3) Save whom we received the S,G register from so we
can use it later
4) Allow a join timer to restart itself instead
of causing a crash.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
SA found these two issues:
1) Check of ifp non-null caused other non-checks down code
to assume ifp could be null. This is not the case.
If we get a callback at this point we must have a valid ifp pointer.
2) We were inadvertently calling igmp_source_reset_gmi with
a possible NULL source pointer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Fix the struct prefix to be an actual struct prefix_sg.
This cleans up a bunch of code to make it look nicer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we receive a NOCACHE upcall, add the pimreg interface
to the oil so that we can receive the data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The kernel upcalls for control messages should
be PIM_DEBUG_MROUTE instead of PIM_DEBUG_PIM_TRACE
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Convert more of the code to pass around a 'struct prefix sg'
instead of individual struct addr's.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
