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

[John Neiberger]

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
>
>