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

[Nilesh Khambal]

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.

From: John Neiberger <jneiberger at gmail.com<mailto:jneiberger at gmail.com>>
Date: Monday, October 8, 2012 1:33 PM
To: "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 2:27 PM, John Neiberger <jneiberger at gmail.com<mailto:jneiberger at gmail.com>> wrote:
We have a simple setup like this:

[receiver] ---- [ Cisco-rtr-A] ---- [ Cisco rtr-B] ----- [MX960] -----
[Cisco rtr-C] ---- [source]

The receiver has joined a specific S,G, but this is very low rate,
perhaps just a couple of multicast packets per week. It's a multicast
messaging setup related to emergency alerts. What's weird is that if
you look at the multicast routing tables on the Cisco routers, the S,G
will be there. However, the multicast route is not present on the
Juniper router. It does show up under "show pim join", but there is no
route. The odd behavior we're seeing is that the first message from
source to receiver is always dropped. If we configure the source to
send multiple times, the first one fails but all subsequent messages
succeed. Our thought is that the multicast route is timing out on the
MX 960, so the first packet gets dropped, although it apparently
causes the route to be setup again since the rest of the packets
succeed.

Any idea if we're on the right track? It seems like we're just running
into some sort of timeout issue on this router, but we're not sure
yet.

Thanks,
John

I just ran across this configurable timeout value that I think might
be relevant. It looks like the max is 12 hours, so if this is the
right "knob", I don't think even maxing it out is going to help in our
situation.

timeout (Multicast)

Syntax

timeout minutes;
Hierarchy Level

[edit logical-routers logical-router-name routing-instances
routing-instance-name routing-options multicast forwarding-cache],
[edit logical-routers logical-router-name routing-options multicast
forwarding-cache],
[edit routing-instances routing-instance-name routing-options
multicast forwarding-cache],
[edit routing-options multicast forwarding-cache]
Release Information

Statement introduced in JUNOS Release 8.2.

Description

Configure the timeout value for multicast forwarding cache entries.

Options

minutes—Length of time that the forwarding cache limit remains active.

Range: 1 through 720

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net<mailto:juniper-nsp at puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp