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 <nkham...@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 <jneiber...@gmail.com> > Date: Monday, October 8, 2012 2:40 PM > To: Nilesh Khambal <nkham...@juniper.net> > Cc: "juniper-nsp@puck.nether.net" <juniper-nsp@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 <nkham...@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 > > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp