Move the upstream_list, hash and wheel into 'struct pim_instance'
Remove all pimg to pim in pim_upstream
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
As a transitory mechanism, if c_oil->pim is set, use that particular
pim instance, else use the default pimg.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are handling the thread read/writes for
a pim mroute socket, make it so that it can
be appropriately handled by the 'struct pim_instance'
instead of defaulting to the default VRF's
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This change allows other non-linux platforms to be a bit
more forgiving if we ask for a very very large size.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Convert the socket fd to be owned by the pimg pointer as
well as the counters associated with the fd. This will
allow us to future proof our code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we add a thread pointer to thread_add_XXX functions
when the specified function is called, thread.c is setting
the thread pointer to NULL. This was causing pim to
liberally pull it's zassert grenade pin's.
Additionally clean up code to not set the NULL pointer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The FSF's address changed, and we had a mixture of comment styles for
the GPL file header. (The style with * at the beginning won out with
580 to 141 in existing files.)
Note: I've intentionally left intact other "variations" of the copyright
header, e.g. whether it says "Zebra", "Quagga", "FRR", or nothing.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The way thread.c is written, a caller who wishes to be able to cancel a
thread or avoid scheduling it twice must keep a reference to the thread.
Typically this is done with a long lived pointer whose value is checked
for null in order to know if the thread is currently scheduled. The
check-and-schedule idiom is so common that several wrapper macros in
thread.h existed solely to provide it.
This patch removes those macros and adds a new parameter to all
thread_add_* functions which is a pointer to the struct thread * to
store the result of a scheduling call. If the value passed is non-null,
the thread will only be scheduled if the value is null. This helps with
consistency.
A Coccinelle spatch has been used to transform code of the form:
if (t == NULL)
t = thread_add_* (...)
to the form
thread_add_* (..., &t)
The THREAD_ON macros have also been transformed to the underlying
thread.c calls.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
In this patch, PIM nexthop tracking uses locally populated nexthop cached list
to determine ECMP based nexthop (w/ ECMP knob enabled), otherwise picks
the first nexthop as RPF.
Introduced '[no] ip pim ecmp' command to enable/disable PIM ECMP knob.
By default, PIM ECMP is disabled.
Intorudced '[no] ip pim ecmp rebalance' command to provide existing mcache
entry to switch new path based on hash chosen path.
Introduced, show command to display pim registered addresses and respective nexthops.
Introuduce, show command to find nexthop and out interface for (S,G) or (RP,G).
Re-Register an address with nexthop when Interface UP event received,
to ensure the PIM nexthop cache is updated (being PIM enabled).
During PIM neighbor UP, traverse all RPs and Upstreams nexthop and determine, if
any of nexthop's IPv4 address changes/resolves due to neigbor UP event.
Testing Done: Run various LHR, RP and FHR related cases to resolve RPF using
nexthop cache with ECMP knob disabled, performed interface/PIM neighbor flap events.
Executed pim-smoke with knob disabled.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
When we have a *,G mroute that starts receiving any particular
S,G, we will get wholepkt callbacks due to the pimreg in the
OIL for the *,G.
So we need to do SPT switchover, but this can fail if we
do not have a path to the S( but we do to the RP!).
In this case fail gracefully.
Ticket: CM-15621
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This allows SPT switchover for S,G upon receipt of packets
on the LHR.
1) When we create a *,G from a IGMP Group Report, install
the *,G route with the pimreg device on the OIL.
2) When a packet hits the LHR that matches the *,G, we will
get a WHOLEPKT callback from the kernel and if we cannot
find the S,G, that means we have matched it on the LHR via
the *,G mroute. Create the S,G start the KAT and run
inherited_olist.
3) When the S,G times out, safely remove the S,G via
the KAT expiry
4) When the *,G is removed, remove any S,G associated
with it via the LHR flag.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There exists a common pattern in pim where we were setting
a variable to a value in the error case when we would no
longer need it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Interface type has been replaced with the SSM range config. And SSM
groups can now co-exists with ASM groups. I have left the pim ssm
per-interface cli control hidden. It now enables pim-sm with a warning.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-15344
Testing Done: pim-smoke
SSM groups (232/8 or user configured SSM range) can exist in the same
multicast network as ASM groups. For such groups all RPT related state
machine operations have to be skipped as defined by section 4.8 of
RFC4601 -
1. Source registration is skipped for SSM groups. For SSM groups mroute
is setup on the FHR when a new multicast flow is rxed; however source
registration (i.e. pimreg join) is skipped. This will let the ASIC black
hole the traffic till a valid OIL is added to the mroute.
2. (*,G) IGMP registrations are ignored for SSM groups.
Sample output:
=============
fhr# sh ip pim group-type
SSM group range : 232.0.0.0/8
fhr# sh ip pim group-type 232.1.1.1
Group type: SSM
fhr# sh ip pim group-type 239.1.1.1
Group type: ASM
fhr#
Sample config:
=============
fhr(config)# ip pim ssm prefix-list ssm-ranges
fhr(config)#
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-15344
Testing Done:
1. SSM/ASM source-registration/igmp-joins.
2. On the fly multicast group type changes.
3. pim-smoke.
When an interface bounces and we receive a packet before
pim has a chance to fully bring the 'struct pim_usptream'
back up correctly, first check to see if we already have
an associated data structure before creating it again.
This removes a case where both the c_oil and up ref counts
were being incremented and never removed properly.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add pim Nexthop tracking feature 1st part where, specific RP or Source address (unicast address)
register with Zebra. Once nexthop update received from Zebra for a given address, scan RP or upstream
entries impacted by the change in nexthop.
Reviewed By: CCR-5761, Donald Sharp <sharpd@cumulusnetworks.com>
Testing Done: Tested with multiple RPs and multiple *,G entries at LHR.
Add new Nexthop or remove one of the link towards RP and verify RP and upstream nexthop update.
similar test done at RP with multiple S,G entries to reach source.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
With the separation of register-state and upstream-join-state we no
longer need an enumeration that covers both states. This commit includes
the following -
1. Defined new enumeration for reg state (this 1:1 with RFC4601).
2. Dropped JOIN_PENDING enum value from upstream join state. RFC4601
only define two values NOT_JOINED and JOINED for this state.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-14700
Testing Done: Verified register setup manually and ran pim-smoke
On the FHR upstream-join-state is not particularly relevant as we
don't need to send upstream JPs for the SG. So that field was being
overloaded with the register-state. However some of the events that
triggered changes to the JoinDesired macro were accidentally overwriting
the state with join info (instead of treating it as register info)
confusing the register state machine.
To make the PIM RFC macros' implemention simple I have separated out
the register-state. And upstream->state now solely describes the
upstream-join-state independent of the role of the PIM router.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-14700
Testing Done: verified pim-register state-machine with separate and
combined FHR/RP routers. Also ran pim-smoke.
Automatically turn on pim if the daemon is turned on.
Hide the 'ip multicast-routing' command
Disable the 'no ip multicast-routing' command
Do not display the 'ip multicast-routing' command.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Suppose we have this
(*,G) IIF = swp1 OIL: swp3
(S,G) IIF = swp2 OIL: swp3 swp4
There exists situations where we can receive the mcast
packet for (S,G) on both swp1 and swp2. In this case
the packet received on swp1 will be sent from the kernel
to us as a WRVIF and WRVIFWHOLE.
As per normal, WRVIF packet processing handles the assert
case so we know we have not received the packet on a downstream
interface, so no assert.
The WRVIFWHOLE packet processing can then check to see if
it received the packet as a result of the (*,G) mroute
from upstream. If we have then we can safely drop
the packet.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-14652
Testing Done: Tested via sending IGMP report and flap port and verified pim upstream and mroute, the entry is deleted. Run pim-smoke
Even after Report received port down event, IGMP entry alawys exists in upstream, mroute, kernel.
The entry exist because it was recreated after delete due missing check if group has no more source list,
mode is exclude, last source address was * means (*, G) so do not trigger to create entry.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket:CM-14056
Reviewed By:sharpd, CCR-5603
Testing Done: verified multiple ifdown/ifup event on submitter setup and dev setup with 2k s,g entries, ran pim-smoke.
1. during ifdown event, pim vif for bridge was not resetting vif_index to -1 due to errno received from
kernel during vif del sequence. It could be timing issue where kernel may have delete prior to pimd sending request.
For vif_del even kernel returns error, reset vif_index to -1 in pimd DB so next if up event VIF receives new vif_index
and reprograms in kernel.
2. during mroute del sequence reset mfcc_parent to MAXVIF.
3. during mroute add check if parent mfcc_parent is MAXVIF then do not download to kernel such mroute entry.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
This commit does these three things:
1) Add code to 'show ip pim state' to show where OIF's got their
decision to include that interface
2) Add code in pim_mroute_[add|del] to display what we think we are
adding to the kernel
3) Add code to properly track where we got the incoming request from and
to appropriately not remove a OIL if we have state still
Ticket: CM-14034
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Chirag Shah <chirag@cumulusnetworks.com>
The PIM_MRT and registration for WRVIFWHOLECACHE
is a bit of linux specific code. Until such
time that this gets implemented we will have
issues being able to work within the context
of PIM-SM.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When you do a series of ifdown/ifup for
an interface that is receiving packets
through the kernel pim socket, it is
possible that the interface has been
deleted but the kernel is still going
to deliver us a packet. In that case
do not allow us to crash.
Ticket: CM-13981
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When debugging is turned on for 'debug mroute' we
are unable to tell when a mroute has been added
or deleted from the mrib. Notice when we
do it and who called it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add 'ip pim packets <1-100>' command.
Allows you to control the number of packets read in before
giving control back to another part of the process.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Modify mroute_read to be non-blocking and
then to read in up to 3 packets at a time
to be handled.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Debugs are extremely expensive currently. Let's
store 'struct prefix_sg sg' string format in
the ifchannel, upstream and msdp_sa structures.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1. This is needed to layout the MSDP macros for determining what SAs are
originated by a MSDP speaker.
2. We no longer let the kat timer expire on an active flow. Activity
counters/lastuse is polled via a wheel for every SG entry. If new
activity is detected the keepalive timer is started and SPT bit set.
A SRC_STREAM reference is also created for the entry if one doesn't
already exist.
3. If KAT actually expires it means the flow is no longer active. At
this point we stop advertising the SA to MSDP peers. We also pull
the SRC_STREAM reference (deleting the entry if there are no other
references).
PS: Checking counters on KAT expiry will come in the next change.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
We are receiving notifications from the linux
kernel that we are filling up the receive buffer
for upcalls into pimd. Let's increase the size
to something a bit bigger.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
