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

[John Neiberger]

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