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

[Nilesh Khambal]

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<mailto:jneiberger at gmail.com>>
Date: Monday, October 8, 2012 2:40 PM
To: Nilesh Khambal <nkhambal at juniper.net<mailto:nkhambal at juniper.net>>
Cc: "juniper-nsp at puck.nether.net<mailto:juniper-nsp at puck.nether.net>" <juniper-nsp at puck.nether.net<mailto: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<mailto: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