The static mroutes were making the assumption that the vif index
and the ifindex were the same. This is not necessarily the case.
Additionally if we are displaying a *,G route only display
the G.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we receive a group in a IGMP report
let's look it up based upon a hash
instead of a list.
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>
When we are at scale, it is possible that
we have a very large number of ifchannels
per interface. So make lookup for
that situation to be a hash lookup.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are only looking at one ifchannel, for inheritance, narrow
the search down to only the interface/ifchannel we are interested in
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we receive a igmp packet, there is no need
to ensure that it is a igmp packet, as that is
what we have asked for.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we get a packet from the network for pim, we do not
need to check to see that it is a pim packet, since that
is what we've asked to receive.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When receiving a J/P packet, only check to see if we should
log when the J/P packet is not for us.
Very slight performance improvement additionally
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
pim_upstream_join_timer_decrease_to_t_override passed in
a `struct in_addr` that in all cases was part of the
upstream data structure that was passed in already.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Switch pim over to using packed data structures for building
Join/Prune messages to be sent.
This is a pre-cursor to the ability to handle the ability
to aggregate Join/Prune messages together.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
For:
pim_msg_build_header
pim_msg_addr_encode_ipv4_ucast
pim_msg_addr_encode_ipv4_group
pim_msg_addr_encode_ipv4_source
Assume that the buffer size passed in is of sufficient size
already. This is assured already because buffer sizes
are checked for minimum lengths for the entire packet
ahead of time. So we are double checking.
Additionally at scale we will be calling these functions
a very very large number of times.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the 'struct pim_msg_header' and convert
all places that encoded/decoded the message header
to use it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Document the J/P packet format and ensure
that the smallest size packet that we
may send will actually fit.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Convert the const int size of the encoded
types to #defines so that they can be
used elsewhere.
Return Null instead of 0.
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>
Ticket:CM-12924
Reviewed By:shapd
Testing Done: configure PIM neighbor, verify PIM hello packet dump for ttl to be 1.
Set TTL to 1 for outgoing multicast control packets destine to ALL-PIM-ROUTERS as oppose to unicast mcast packets.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Ticket: CM-12041
Reviewed By: sharpd, CCR-5556
Testing Done: Tested on Local setup generating PIM Register (Data/Null) and processing both Tx/Rx with correct checksum.
Provided quagga debian to submitter and checksum cases passed on submitter setup.
1. PIM Register msg checksum only accounts for 8 bytes (4 bytes for PIM header and next 4 byetes before data payload).
In PIM header checksum calculation checked PIM packet type (in this case REGISTER type) then only pass 8 bytes as length
rather than full packet length.
2. PIM Register Rx path also handled with 8 byte and full pim lenth checksum.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Ticket: CM-13771
Reviewed By: CCR-5537
Testing Done: yes
Fix to CM-13771 where DBG message was out of order.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Cleanup the in_ifname and out_ifname buffers
to be large enough to hold the actual interface
names.
Additionally move the common variables to be defined
once, instead of inside of multiple for loops
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In all cases pim_sock_open was called, we just passed
in the pim_ifp->primary_address, which is accessible
from the interface pointer. So just pass that in.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This fixes the issue a crash when we have configured an interface
inside of a vrf, and apply pim commands to it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The library libzebra that is installed with FRR will
conflict with Quagga. So let's rename it to libfrr.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Fix broken switch statement that would
allow the case statement to fall through.
Fix possible buffer overwrite.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When on the RP we received a prune *,G for an established S,G
If join_desired is no longer true we need to prune and
reset some timers, in addition to removing the inherited
interface from the olist.
This was not happening because we were just removing
the inherited oif from the *,G.
Ticket: CM-14561
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Valgrind noticed that we have a read of uninitialized memory:
Conditional jump or move depends on uninitialised value(s)
==13749== at 0x428067: pim_ifassert_winner_set (pim_assert.c:57)
==13749== by 0x4266F0: pim_ifchannel_add (pim_ifchannel.c:535)
==13749== by 0x426CC1: pim_ifchannel_join_add (pim_ifchannel.c:730)
==13749== by 0x427B5B: recv_join (pim_join.c:95)
==13749== by 0x427B5B: pim_joinprune_recv (pim_join.c:270)
==13749== by 0x42354F: pim_pim_packet (pim_pim.c:249)
==13749== by 0x4236C0: pim_sock_read (pim_pim.c:349)
==13749== by 0x4E60587: thread_call (thread.c:1462)
==13749== by 0x40C75E: main (pim_main.c:266)
==13749==
This commit fixes that issue.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We were creating the pimreg device with a
created ifindex of 255. This was causing
issues when a interface was assigned a ifindex
of 255 by the kernel. Subsuquently pim
would stay in a hosed up state.
Modify the ifindex used for the pimreg device
to be 0.
Ticket: CM-14625
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are creating the igmp ifchannel we were creating
it with both a P and a I flag. This was causing
it to not be cleaned up properly when the interface
was shut down. Subsuquently when the interface
came back up we would attempt to add it back in
but it would fail.
Ticket: CM-14586
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
