In certain conditions when we are deleting the interface
from an OIL do not delete the mroute. That decision
should be made by the state machine.
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 we get a SGrpt Prune embedded in the *,G Join,
Display the created ifchannel as being SGRpt state.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
pim_jp_agg list should not ref count pim_upstream as that
the deletion of pim_upstream deletion should remove
the pim_upstream from the j/p agg list.
Cleanup a memory leag of jag
Make comparison of js cleaner in add_group
Move THREAD_OFF to before the neighbor find.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Suppose you have a unnumbered ecmp connections between
two switches:
st1-l3# show ip pim neighbor
Interface Neighbor Uptime Holdtime DR Pri
swp52 6.0.0.10 00:00:01 00:00:29 1
swp53 6.0.0.10 00:00:06 00:00:26 1
And for a given (S,G) the RPF goes:
st1-l3# show ip nht
99.1.1.1
resolved via bgp
fe80::4e76:25ff:fee7:42d1, via swp52
fe80::4e76:25ff:fee7:42d5, via swp53
Client list: pim(fd 14)
Now suppose, 52 is the choosen RPF( since we can only pick one )
and the interface goes down. As such we will choose to use
swp53.
The problem was that the pim_rpf_update call is made
it will change the rpf interface to 53, but not tell
the calling function that the RPF_CHANGED because
it is only looking at the rpf_addr(the nexthop)
to see if it is changed and if we are in an unnumbered
dual ecmp to the same box it was not detecting and
notifying.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The J/P Aggregation + the NHT tracking code was not
playing nicely together
1) Clean up pim_upstream ref counting to keep a bit better
track of it.
2) When we delete pim_upstream zero it out to hopefully
catch issues faster in the future
3) Clean up J/P Agg source list a bit better to keep order
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When creating the pim upstream data structure, if we fail
to create remove the reference we saved to it on the side
in the pnc code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
Changed the state field in the "sh ip pim upstream" output to include
register and join state info as a comma separated value. Register info
is supressed if reg-state=NoInfo.
Sample output:
=============
root@fhr:/home/cumulus# net show pim upstream
Iif Source Group State Uptime JoinTimer
RSTimer KATimer RefCnt
swp1 33.1.1.1 239.1.1.2 J,RegP 00:00:18 --:--:--
00:00:44 00:03:24 2
root@fhr:/home/cumulus#
root@rp:/home/cumulus# net show pim upstream
Iif Source Group State Uptime JoinTimer
RSTimer KATimer RefCnt
lo * 239.1.1.2 J 00:02:08 00:00:52
--:--:-- --:--:-- 1
swp1 33.1.1.1 239.1.1.2 J 00:00:16 00:00:11
--:--:-- 00:03:26 1
root@rp:/home/cumulus#
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-14700
Testing Done: pim-smoke
This is another follow-up change to the reg-state and up-join-state
separation. The upstream join state machine can now respond to
JoinDesired macro changes independent of router role.
I have also dropped the PRUNE state from the upstream-join-state
enumeration. RFC4601 only defines JOINED and NOTJOINED states. And PRUNE
can really be replace by NOTJOINED.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-14700
Testing Done: Register state machine in FHR only, combined FHR-RP and
FHR-RP-LHR/all-in-one setups. Also ran pim-smoke.
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.
pimd/pim_sock.c:178:13: error: implicit conversion from
'int' to 'char' changes value from 148 to -108
[-Werror,-Wconstant-conversion]
ra[0] = 148;
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(Note: the allow_delete thing is called "zebra" on the commandline
because that's the clearest context there, while it is called "FRR" in
the CLI because that's considerably less confusing in a vtysh env.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
There exists situations where we may have cleaned not
properly cleaned up the various J/P aggregation lists.
This commit fixes those issues.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Contains the fetch-and-run-thread logic, and vty startup (which is the
last thing happening before entering the main loop).
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Centralise read_config/daemonize/dryrun/pidfile/vty_serv into libfrr.
This also makes multi-instance pid/config handling available as part of
the library. It's only wired up in ospfd, but the code is in lib/.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Start centralising startup & option parsing into the library.
FRR_DAEMON_INFO is a bit weird, but it will become useful later (e.g.
for killing the ZLOG_* enum, and having the daemon name available)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The 'show ip pim state' command was not
working quite correctly from when
we moved over to the new vtysh-grammar.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
When you enter these commands, under an interface:
ip igmp version ...
ip igmp query-interval ...
ip igmp query-max-response-time ...
ip igmp query-max-response-time-dsec ...
These commands will now just turn on igmp for the
interface.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the ability for PIM to send Join/Prunes as an
aggregated message instead of individual messages
for each S,G.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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:
