[j-nsp] Odd drop behavior on low-rate multicast streams

[Nilesh Khambal]

Hi John,

Did you check by sending the traffic after enabling this configuration? Once the forwarding entry is created with traffic, it should have the timeout set to Never for that entry in "show multicast route group <blah> extensive" output. 

Forwarding entry won't get created until we see the traffic hitting this PIM join entry. Creation of entry with flow-map is  still traffic driven (except the very first time when the PIM join is received). Only the deletion (once created is affected by flow-map. 

Let me know what you see after sending traffic. 

Thanks,
Nilesh. 

--------------------------------
Sent from my mobile device

On Oct 30, 2012, at 12:31 PM, "John Neiberger" <jneiberger at gmail.com> wrote:

> Nilesh,
> 
> We're trying this configuration and it's not having the results I
> expected. Previously, there would be no entry in "show multicast
> route" for a particular group, but there would be an entry in "show
> pim join extensive". After implementing the flow map with the timeout
> set to never, I would have expected an entry to appear in the
> multicast routing table since there are active PIM joins, but that
> doesn't seem to be the case.
> 
> Can you confirm what I should expect to see? Shouldn't I see an entry
> in the multicast routing table for all entries matched in the flow map
> now?
> 
> Thanks,
> John
> 
> On Mon, Oct 8, 2012 at 3:44 PM, Nilesh Khambal <nkhambal at juniper.net> wrote:
>> Sure. Make sure you implement this workaround across all Juniper boxes that
>> are in path for this multicast group traffic.
>> 
>> - Nilesh.
>> 
>> From: John Neiberger <jneiberger at gmail.com>
>> Date: Monday, October 8, 2012 2:40 PM
>> To: Nilesh Khambal <nkhambal at juniper.net>
>> Cc: "juniper-nsp at puck.nether.net" <juniper-nsp at puck.nether.net>
>> 
>> Subject: Re: [j-nsp] Odd drop behavior on low-rate multicast streams
>> 
>> On Mon, Oct 8, 2012 at 3:28 PM, Nilesh Khambal <nkhambal at juniper.net> wrote:
>> 
>> Hi John,
>> 
>> Is it the first packet that gets lost from the stream or the subsequent
>> ones?
>> 
>> If the route does not exist on MX for your (S,G) in the forwarding-table,
>> then when you receive the packet for this (S,G) on MX, it will be punted to
>> the routing-enginer (control-plane) for what is known as multicast route
>> resolution to install the route. Control plane does usual the checks (IIF,
>> receivers etc) on the packets and installs the route in the forwarding
>> table. This is probably what you are seeing in this case. Creation and
>> maintenance of multicast route in the forwarding-table is a data-driven. If
>> there is no data for the timeout period, which is usually 6 mins by default,
>> route (a.k.a forwarding cache) will timeout and the new traffic will need to
>> be resolved again by control plane to install the route. The
>> forwarding-cache timeout knob can increase the value when route will be
>> timed out when there is no traffic hitting the route but depending upon the
>> frequency of your data traffic, it might not be useful in all use cases.
>> 
>> You might want to consider "flow-map" configuration. This gives you control
>> over which groups you want "not" to timeout. The forwarding-cache knob you
>> mentioned in other email will affect all multicast routes which you may not
>> want.
>> 
>> http://www.juniper.net/techpubs/en_US/junos12.2/topics/example/mcast-flow-map.html
>> 
>> 
>> Thanks,
>> Nilesh.
>> 
>> 
>> Nilesh,
>> 
>> It is only the first packet that gets dropped. If the sender is
>> configured to immediately send a second copy of the message, that one
>> arrives at the destination. I think it's a great idea to use a flow
>> mask to control this because we can set this particular S,G to never
>> timeout while leaving default rules in place for everything else.
>> 
>> Thanks!
>> John
>