PIM was handling vif creation deletion poorly
for interface down and up events. Fix this
issue by keeping track of which vif index'es
we have issued and allow the wholes to be
filled in.
Ticket: CM-14556
Signed-off-by: Donald Sharp <sharpd@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>
Rename the qpim_zclient_update variable to zclient.
This is to follow the naming conventions in the rest
of the code.
Additionally move the struct zclient * pointer into pim_zebra.c
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Start the abstraction of the zclient data structure out from a
global variable for the entire program to a global variable
to the pim_zebra.c file.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We were adding the 'ip msdp ...' command to
the parser 2x. Some new code added to the
parser apparently catches this for us now.
Signed-off-by: Donald Sharp <sharpd@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>
thread.c fails to build if we do not have CLOCK_MONOTONIC
no need to have pim have any knowledge of it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Mixing well-known and variable property names makes the output difficult
to parse. so wrapped variable-keyed dicts with well-known property
names (such as "oil") in the following outputs -
"show ip mroute json"
"show ip msdp mesh-group json"
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
When you bounce interfaces and the system is under heavy
load there exists situations where zebra may or may not
have told us the new ifindex, but we've requested a
nexthop lookup, which bypasses normal mechanisms for
zebra communication, we may get back a ifindex that
we may have not created a ifp for yet.
Ticket: CM-14052
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
When shutting down, actually delete the right data
structures.
Stupid cut-n-paste error on my part.
Ticket: CM-14018
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There exists situations where we have noted that
we need to rescan but have missed the window
of opportunity to actually redo the scan
so for the moment allow the S,G 30 second
scanner notice the missed opportunity and
fix it. We'll remove this later.
Ticket: CM-13988
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Sending (S,G)RPT prune was causing issues due to not handling
it properly at this point in time. So just don't send it right now
Ticket: CM-13969
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>
Bridges and bonds when ifdowned are removed from
the kernel in it's entirety, while pim assumed
that interfaces were kept around in some fashion.
Basically when we had an ifdown event, for all ifchannels
on that interface delete from the OIF. Also note
the fact that the vif has gone away and we need to
recreate it on the next ifup.
Ticket: CM-13896
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we have network churn and we have an inherited_olist
notice when we may have a situation where we need
to recalculate the inherited_olist.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we receive a packet from a neighbor, reset the
hold time as that we *know* that they are still
alive.
During heavy packet load, we were seeing cases
where neighbors were being reset because we
were timing out due to not processing the hello
packet in time.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we encounter an error in the state machine
for an individual ifchannel, do not bring the entirety
of the pim daemon down. Notice the issue and continue
on.
Ticket-CM-13939
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In certain error conditions it is possible to
attempt to send packets when the socket is not ready
instead of dumping to the log a million error messages
only note the issue if we have packet debugs on.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Modify pim_usptream_new to auto create the pim
channel oil. Why? Because there exists situations
where we have upstream state and we are attempting
to set the inherited_olist on it and we have
not created the channel oil yet. When that
happens we end up with mroutes that are
being meanies.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There exists situations where PIM stores a S,G channel oil
and doesn't delete it. When a new upstream comes in for
it we were not ensuring that the IIF for the S,G channel oil
was correct.
Ticket: CM-13908
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>
In the normal case when we have debugs turned on and the
stream is not running, only display one line of output
instead of 2.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Cleanup some pim debugs:
1) For some reason some PIM_DEBUG_PIM_TRACE were not showing up
switched them to PIM_DEBUG_TRACE
2) Some mroute debugs were a bit redundant. Reduce.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we receive a new *,G ifchannel, handle the inherited_olist
for S,G mroutes in a place where it is more appropriate.
Ticket: CM-13892
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
When the switch in question is both a FHR and the RP
for the received multicast group stream. When we go
to send the NULL register to the RP( ourselves )
do not send it if we have not seen packets for
that stream in time greater than PIM_KEEPALIVE_PERIOD
and I_am_RP(G).
Ticket: CM-13880
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
12 is too slow of a slow-start in scale setup (say with 6000 SAs)
when sources are being learnt one at a time (but in a rapid fire
fashion).
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
If we were in the middle of a partial read when the tcp connection is
reset we were clearing the buffers but not the packet size. This can be
problematic when the connection is re-established.
There is no easy way to repro and test this without scale (and a timing
pattern that is hard to predict). So this change is mostly untested.
Ticket: CM-13852
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
When a group is in the 224.0.0.0/24 range and we
have igmp v2 turned on do not allow it to be
considered for inclusion as a mroute.
Ticket: CM-13855
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by:
So there exist conditions where we can start the Prune
Pending Timer and receive other packets that cause
us to not stop the pending timer. This was
due to a missread of the state machine.
Additionally when the prune pending timer pops and
we are not in prune pending state, note the fact
and move on with our life instead of crashing and burning
Ticket: CM-13851
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by:
This is done irrespective of the reason for del and is intended as a
catchall for cases (unclear which ones) where the RP can drop the SG
without KAT expiry.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
When we receive a invalid group( say outside of the 224/4
range) don't allow it to create state. Nicely reject
the rejectable.
Ticket: CM-13821
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
To avoid unnecessary ka activity in the network. When the SA
advertisment timer fires we build SA TLVs and send them to peers. As a
part of this tx we were also restarting the ka timer to avoid
unnecessary ka generation in the next 60 seconds. However because the
adv timer was restarted after tx (i.e. after ka restart) ka timer would
always endup firing just before the adv timer.
The entry_cnt in a SA TLV is one byte. I was trying to push 765 SAs into
each TLV resulting in strange problems in a scale setup.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
There exists conditions where PIM will have it's
upstream route removed and an unreachable route
is installed that points out the downstream
interface. This unreachable route is removed
from bgp as soon as it's path selection algorithim
works properly, but pim has already deleted
the oif and never puts it back in.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When issuing a vtysh -m command it expects the
output it receives to be the complete command
not a partial match.
The 'debug pim packets joins' command
was being outputted as 'debug pim packets join'
This was making quagga-reload.py unhappy. Adding
the joins word allows it to complete successfully
Ticket: CM-13805
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
There exists situations where an interface flaps
and routing recovers and we attempt to install
an upstream but since we have no neighbor out
that interface still. Let's cause the hello
to go out immediately for the 3.1 release
to allow mrouting to recover in this situation.
We will need to revisit this issue after
we have proper nexthop tracking in place
Ticket: CM-13185
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Make the 'ip igmp query-max-response-time' command
take input in deci-seconds and make the
'ip igmp query-max-response-time-dsec' command hidden.
Ticket:CM-13786
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
When debugging nexthops, we print allot of unnecessary data
Move some debugs to trace detail to reduce log clutter.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we add in or delete ip addresses from an interface
we may need to rescan the rp's that we know of to make
sure that they are still available.
Ticket: CM-12623
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
When a new rp is entered, pim is looking at all rp's and failing the check if
any of the RP's have no path to the RP, instead of the one that was
just entered being wrong.
Ticket: CM-12623
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
When we modify the 224.0.0.0/4 rp address with a:
'ip pim rp A.B.C.D'
We need to let msdp know that this command was entered.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
When we get a new neighbor for an interface, we need
to send a hello out that interface in some situations.
At this time we were tracking this by the pim_ifstat_hello_sent
value but not reseting it when we received a new neighbor.
Ticket: CM-13769
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Was failing with a vague error -
"Source set failed"
Changed to used the error string (used by the rest of the commands) -
"Pim not enabled on this interface"
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Currently the mroute-IIF and upstream RPF-IIF/neigh are resolved separately.
This must change i.e. be merged together for a couple of reasons -
1. In the case of ECMP we will use a load-share mechanism (based on G or
SG) to pick an RPF neighbor in 3.2.1 (to use the load-sharing cap of
anycast-RP). Using a different resolution mechanism for mroute-IIF will
simply not work.
2. In a non-CLOS topology it is actually possible to have routers that
do not participate in PIM. In this case the tree will be set up using
different routers than the ones chosen for the mroute IIF. And traffic
will not be forwarded.
This change is however too big for 3.2.0. So to handle CM-13714 I have
simply forced rpf update on neigh add which fixes the specific problem
seen on link flap in a clos (it is not very efficient but traffic
recovers).
In problem state -
(jessie-30-dev-switch-amd64-sbuild)root@spine-1:/home/cumulus# ip mr
(0.0.0.0, 225.1.1.1) Iif: lo Oifs: swp3 lo
(20.0.11.253, 225.1.1.1) Iif: swp1 Oifs: swp3
(jessie-30-dev-switch-amd64-sbuild)root@spine-1:/home/cumulus# vtysh -c
"show ip pim upstream"
Iif Source Group State Uptime JoinTimer
RSTimer KATimer RefCnt
lo * 225.1.1.1 Joined 00:08:44 00:00:15
--:--:-- --:--:-- 1
swp2 20.0.11.253 225.1.1.1 Joined 00:08:35 00:00:56
--:--:-- 00:02:59 1
(jessie-30-dev-switch-amd64-sbuild)root@spine-1:/home/cumulus#
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
When receiving a JOIN/PRUNE message if we have trace
turned on we output this:
2016/11/28 17:11:46.368827 PIM: pim_socket_recvfromto: HAVE_IP_PKTINFO to=224.0.0.13,103
2016/11/28 17:11:46.368956 PIM: Recv PIM JOINPRUNE packet from 169.254.0.6 to 224.0.0.13 on swp31s1: ttl=255 pim_version=2 pim_msg_size=34 checksum=e623
2016/11/28 17:11:46.369003 PIM: pim_joinprune_recv: from 169.254.0.6 on swp31s1
2016/11/28 17:11:46.369053 PIM: recv_prune: prune (S,G)=(20.0.11.253,229.1.2.3) rpt=0 wc=0 upstream=169.254.0.5 holdtime=210 from 169.254.0.6 on swp31s1
2016/11/28 17:11:46.369099 PIM: nonlocal_upstream: recv prune (S,G)=(20.0.11.253,229.1.2.3) to local upstream=169.254.0.5 on swp31s1
Clean up the messaging to this:
2016/11/28 17:11:46.368956 PIM: Recv PIM JOINPRUNE packet from 169.254.0.6 to 224.0.0.13 on swp31s1: ttl=255 pim_version=2 pim_msg_size=34 checksum=e623
2016/11/28 17:11:46.369053 PIM: recv_prune: prune (S,G)=(20.0.11.253,229.1.2.3) rpt=0 wc=0 upstream=169.254.0.5 holdtime=210 from 169.254.0.6 on swp31s1
Ticket: CM-13752
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
When a nexthop lookup is done we can get an ECMP output. But not all
nexthops are pim neighbors. If for this reason PIM chose a nexthop other
than the first the rpf info was not being set correctly i.e.
nexthop ip was still the one associated with the first path but
interface was set to the one associated with second path.
This problem is seen on a link flap in the CLOS topology.
Ticket: CM-13714
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
The RP address in the SA is only for informational/display purposes. It
is still confusing if we show a stale value.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
With the change over to using the kernel upcall for igmp messages,
we need to add in a read thread for the igmp socket to drain
the igmp socket's receive queue.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Anycast rp requires multiple ip addresses on the lo. If PIM is used in
an unnumbered BGP network it picks one of the lo addresses as the
pim-primary for the swp interfaces. But if the anycast IP is picked up
by both sides pim nbr will never converge. So a static "use-source" config
is provided to allow the administrator to force the the hello source to the
unique IP address.
Sample output:
=============
dell-s6000-04(config-if)# do show running-config pimd
>>>>>> SNIPPED >>>>>>>>>>>>>>>>>
interface lo
ip pim sm
ip pim use-source 100.1.1.5
!
>>>>>> SNIPPED >>>>>>>>>>>>>>>>>
dell-s6000-04(config-if)# do show ip pim interface lo
Interface : lo
State : up
Use Source : 100.1.1.5
Address : 100.1.1.5 (primary)
100.1.1.100
>>>>>> SNIPPED >>>>>>>>>>>>>>>>>
dell-s6000-04(config-if)# do show ip pim interface lo json
{
"lo":{
"name":"lo",
"state":"up",
"address":"100.1.1.5",
"index":1,
"lanDelayEnabled":true,
"useSource":"100.1.1.5",
"secondaryAddressList":[
"100.1.1.100"
],
>>>>>> SNIPPED >>>>>>>>>>>>>>>>>
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Acked-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>
Anycast requires that the lo interface be associated with multiple
addresses. One is the anycast IP address (which is the same on all RPs
participating in RP redundancy) and the second is the unique IP address
that will be used as the router id by routing protocols.
To accomodate that we maintain a list of secondary addresses per-pim iface
and allow any of them to be the RP address. This lets the I_am_RP macro
succeed on anycast RPs.
Note that the support is limited i.e. we don't actually advertise a
secondary list to the neighbors. This is assuming the anycast IP will never
be used as a router id i.e. will never be an RPF neighbor.
Sample output:
==============
dell-s6000-04# sh ip pim interface lo
Interface : lo
State : up
Address : 100.1.1.1 (primary)
100.1.1.2
100.1.1.3
100.1.2.1
>>>>>>> SNIP >>>>>>>>>>>>>>>
dell-s6000-04# sh ip pim interface lo json
{
"lo":{
"name":"lo",
"state":"up",
"address":"100.1.1.1",
"index":1,
"lanDelayEnabled":true,
"secondaryAddressList":[
"100.1.1.2",
"100.1.1.3",
"100.1.2.1"
],
>>>>>>> SNIP >>>>>>>>>>>>>>>
dell-s6000-04#sh ip pim rp-info
RP address group/prefix-list OIF I am RP
100.1.2.1 224.0.0.0/4 lo yes
dell-s6000-04#
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
There exists situations where we can receive data
faster than we can process it. Make the buffer
large enough to catch these situations for
the pim sockets.
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>
When we received a packet we were dumping packet information
with debugs on 2 times for each packet where we had overlapping
data being passed.
Since debugs are expensive, reduce the count to 1.
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>
Cleanup some turned on debug code that is no longer
needed to be turned on in the pim_sock_read
code path.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Give ourselves a few more seconds to wait for a response
for a NULL Register. This will benefit us under heavy
mroute churn on the RP.
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>
Add the 'ip pim register-suppress-time ...' command.
Remove the 'no ip pim rp keep-al...' command as
that the register suppress set that value.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Use the NULL c symbol to signify that we are
intentionally setting the pointer to NULL
instead of 0.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If you specified the 'ip pim rp ...' after the
system has been configured it was not accepting
the new rp. This fixes that issue.
Ticket:CM-12623
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we receive a 'no ip pim sm' for an interface
that has both pim and igmp on it, only turn
off pim.
Ticket: CM-12985
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a 'show ip pim rp-info' is issued shortly
after a restart/start, pim will crash because
nexthop information has not been fully resolved
and the outgoing interface is NULL.
Ticket: CM-13567
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1. Add support for mesh-group based configuration that is easy to apply
via automation. The older per-peer configuartion is temporarily hidden
and will be cleaned up later.
Sample config -
ip msdp mesh-group cumulus source 100.1.1.4
ip msdp mesh-group cumulus member 100.1.1.5
ip msdp mesh-group cumulus member 100.1.1.6
2. Added support for detail peer and sa-cache displays. Along with
filter keys.
3. Add json output for all the msdp displays.
With this commit basic support for anycast-RP with MSDP (in numbered
network is complete). Unnumbered support will be added separately.
Ticket: CM-13306
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
We've already allocated the mp data structure
and am using hash_alloc_intern for the hash_get
function. This will return the passed
in data structure. There is no possibility
of mp being NULL.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We need to react to route changes/Interface up/down events
faster in PIM. Reduce the timer down to 50ms.
Ticket:CM-13549
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
1. Added a new MSDP source reference flag for creating (S,G) entries
based on the SA-cache. The RFC recommends treating as SA like rxing
a (S, G) join (which is a bit different then treating like a traffic
stream).
2. SA-SPT is only setup if we are RP for the group and a corresponding
(*,G) exists with a non-empty OIL.
3. When an SA is moved we need to let the SPT live if it is active (this
change will come in a subsequent CL).
Testing done:
1. SA first; SPT setup whenever (*, G) comes around.
2. (*, G) first. As soon as SA is added SPT is setup.
3. (*, G) del with valid SA entries around.
Ticket: CM-13306
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
When determining the inherited_olist(S,G) add
the determination that we have received a
prune(S,G,rpt) from a neighbor.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add some more code to handle the prune(S,G) with the
sptbit set. Turns this ifchannel into a (S,G,rpt).
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When leaving a channel, there exists a possibility
that we have not created the channel oil yet.
Ensure that we have channel oil before dereferencing
Ticket: CM-13522
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>
According to Figure 5( Downstream per-interface (S,G,rpt)
state when we receive a (*,G) we need to move (S,G,rpt)
children of the (*,G) into different states. This
implements that.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we called pim_parse_addr_group, don't reinitialize
the 'struct prefix_sg' *after* we've parsed the group.
Ensure in other places that we do this work, we initialize
prior as well.
Ticket: CM-13510
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we have multiple incoming joins for
a single group on a interface, we need to
allow proper output.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If you add to the json by grp, if you have multiple
ifchannels for that group, on the the first one will
be displayed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Don't delete the ifchannel if the expiry timer is still running.
We might need to add the prune pending timer as well? Not sure
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we read in the S,G from the join/prune message,
convert it into a 'struct prefix_sg' at an
earlier point in time.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Modify the pim_parse_addr_source function to take
a 'struct prefix_sg' and to fill in the src data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Modify the pim_parse_addr_group to use 'struct prefix_sg sg'.
This is the first of 2 commits to clean up this parsing to
be a bit better.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the ability for pim ifchannels *,G's to know their
corresponding S,G's. This will facilitate handling
S,G,rpt state information better.
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>
This fix handles two issues:
1) Searching entire vrf_iflist to get per interface pim_ifchannel_list
2) Display of ifchannel information in pim not being ordered correctly.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a 'show ip pim join' is issued and we have
(S,G,rpt) being sent back up to us. We need
to order correctly for this situation.
Signed-off-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>
The (S,G,rpt) prune inclusion was incorrectly considering
if the RPF' was the same for (S,G) and (*,G).
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Do not reset the time the mroute has been in it's
current state if we get a transition to the same state.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add logic to show that we are making decisions about
the s,g,rpt prune send. We are not actually sending
anything yet.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Some igmpv2 messages are sent to 224.0.0.2. We were
not listening for these messages and as such we
were ignoring some withdrawals.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a static igmp join is issued, before routing
has come up, the ability to recover was accidently
removed from the code.
Ticket: CM-13379
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When the nexthop lookup fails when establishing the
upstream state as part of a register receive, kill
the upstream state.
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 get a request to look up the mroute statistics
from the kernel, ensure that the interface returned
is a valid usable interface.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This commit includes the following changes -
1. Support for MSDP peer DB (hash and sorted list).
2. Support for the following timers - keepalive, connect-retry, hold.
3. TCP session management (lower-ip is active, higher-ip is passive).
4. MSDP KA packet rx/tx.
5. Limited temporary config (will be replaced with the more automation
friendly RP-set).
Testing done -
Peer bringup/deletion (including interop with another vendor)
Sample out -
root@dell-s6000-04:~# sudo vtysh -c "show ip msdp peer"
Peer Local Mesh-group State Uptime
100.1.1.1 100.1.2.1 default established 00:07:27
100.1.3.1 100.1.2.1 default established 00:31:50
root@dell-s6000-04:~#
Coming soon -
1. part-2: SA cache management.
2. part-3: SPT setup using source in SA cache.
3. part-4: CLI cleanup.
Ticket: CM-13306
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
Pass in the upstream data structure to pim_msg_join_prune_encode
so it can decide to send (S,G,rpt) information if it wants to or
not.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The test commands are not being maintained and
are not out of date with the rest of the system. There
are better ways to test code and in addition these
commands if entered by a user could seriously impact
their running system.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When sending a join/prune send in the upstream pointer.
this will allow us to implement some of the other state
machines necessary.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We are seeing situations where nexthop lookups are failing
unexpectedly. Don't consider the lookup to have succeeded
in this case to allow the next lookup to work?
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
When we print a debug in the pim_upstream_add, there
exists failure cases for pim_upstream_new where
we cannot create a upstream data structure. Make
sure the debug handles it right.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Cache the last time we looked up the nexthop for this particular
address. Store time to usec accuracy.
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>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
This cleans up the following so that they always collect the data to
display in json structures and then either dumps the json output or
traverses it to produce the non-json output.
show ip pim local-membership
show ip pim interface
When handling a igmp request, fill in group address before
we attempt to output debug information on it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When outputting data about ifchannels due to debug
include the interface this is happening on.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In some situations, the deletion of the ifchannel would
not ocurr if the last flag cleared was the assert flag.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When entering debug commands under 'conf t' mode
allow the debugs to be saved for future fun and
adventure.
Ticket: CM-13213
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If the incoming interface comes back, reinstall the channel oil
if the mroute is not installed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When looking up the channel_oil use a hash
to find it. Keep the list around for quick
walks of the channel oils.
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 receiving callbacks from the kernel allow bigger
packet sizes than 3k to be handled appropriately.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When looping over S,G's associated with a *,G,
there can exist situations where we have not created
the channel oil for the S,G yet. Don't allow this
to crash the system.
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 receive a join/prune for a upstream
that we are unable to create, safely ignore
the request until the situation resolves itself.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When starting up allow the 1st query to go out immediately,
well ok 1 second, and then the next queries to go out in
query_interval/4 seconds until startup mode is finished.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are disabling pim, there exists some
race conditions where we are attempting
to send a register stop out a interface that
is not setup for pim yet.
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>
When we reject a register message from someone, give some reasoning
as to the why of it being rejected to help in debugging the situation.
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>
When doing a rpf check ensure that
if we've considered the RP to be a loopback
allow there to be no neighbor on the other
side.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When looking up nexthops for a path, we
should only allow nexthops that we
actually have neighbors formed for. Otherwise
when we send join/prune messages they will
do nothing.
Ticket:CM-12754
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Do not assert when looking up a neighbor, we don't know
if we have a neighbor don't punish us.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
NEXTHOP_TYPE_IPV4 has the ifindex of the route. Pass it
along so the other side can use it if it is needed.
This will make pim much happier in that we will need to do less
recursive lookups.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When looking up nexthops for a address, just
use the MULTIPATH_NUM as the number allowed
to receive instead of an arbitrary limit of 20 paths.
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>
When rebooting a switch, if under unnumbered config
there exists a situation where some interfaces
may not create the vif in the kernel.
Ticket: CM-12830
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When pim starts up there is no need to assert in pim_init
if state is not set as wanted. Especially for qpim_debugs
as that I would like to turn on debugs before we even start
doing anything in the code.
As for the PIM_MROUTE_IS_ENABLED, the variable is set
right above it, so no need to assert on it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a interface goes down we accidently put ourselves into
an infinite loop.
Ticket: CM-12803
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In pim_rpf.c when we receive multiple paths for the
rpf we are complaining that we are not sure what
to do with it yet. Change the _info to _debug
and don't print out unless we are debugging
stuff.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we get a v6 address/ifindex combo back from
a v4 lookup. Check to see if the outgoing
interface only has one neighbor and if so
use that neighbors loopback address as
the route to use.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a interface is configured as BGP unnumbered, it
has a v6 LL address as well as no v4 addresses. In
this case let's look at the lo's ip address as the
primary address to use.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
rebase
The recent conversion of in_addr_t to struct prefix
caused a display issue in the 'show run' of the rp.
Ticket: CM-12752
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The pim_find_primary_addr function just called 1 static function
that was called no where else.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Restructure code to remove SA warning from clang build.
For some reason, the Clang SA system thought that si.sin_port and
si.sin_addr where not being set to anything. Fix this problem.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When I converted over to using 'struct prefix'
I broke the initialization of the rp.
In addition, I used the wrong AFI type
to switch on in pim_rpf.c
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 is setup code to allow us to receive v6 addresses from
a nexthop lookup from zebra. This will allow us to work
with unnumbered interfaces.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In the nexthop lookup routine, fix the duplicate code
to not check for too many indexes earlier.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Specify the ifindex of the interface that we want
to turn on IP_MULTICAST_IF on instead of the
address. If we pass in the address then the
fact that we have multiple interfaces with the
same ip address causes confusion in the kernel.
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>
If a neighbor comes up *after* igmp joins and *after* all
the routes are installed into the kernel, then we never
go back and fix up the rpf cache information. So joins
never go out for those igmp joins.
Ticket: CM-12613
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
