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

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

[John Neiberger]

On Mon, Oct 8, 2012 at 3:28 PM, Nilesh Khambal  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

Re: [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 mailto:jneiber...@gmail.com>>
Date: Monday, October 8, 2012 1:33 PM
To: "juniper-nsp@puck.nether.net" 
mailto:juniper-nsp@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 
mailto:jneiber...@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[John Neiberger]

On Mon, Oct 8, 2012 at 2:27 PM, John Neiberger  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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[John Neiberger]

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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] JUNIPER POLICER and CoS Shaping Rate

[Christopher E. Brown]

On 10/8/12 4:02 AM, Tima Maryin wrote:
> On 04.10.2012 14:30, Duane Grant wrote:
> 
> 
>> network-services all-ethernet;
> 
> 
> Btw, it's unsupported thing.
> 
> 
>> There are ways to do it per IFL, but I don't have an example handy.
> 
> 
> 
> Last time i checked build-in ports of MX<=80 did not support per unit 
> scheduling.

That is correct, xe-0/0/0 through xe-0/0/3 are port mode only.  It is
the MIC interfaces that have per-unit shaping.



-- 

Christopher E. Brown  desk (907) 550-8393
 cell (907) 632-8492
IP Engineer - ACS

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] JUNIPER POLICER and CoS Shaping Rate

[Tima Maryin]

On 04.10.2012 14:30, Duane Grant wrote:



network-services all-ethernet;



Btw, it's unsupported thing.



There are ways to do it per IFL, but I don't have an example handy.




Last time i checked build-in ports of MX<=80 did not support per unit 
scheduling.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] CPU monitoring of cluster of two J6350

[Alexander Shikoff]

Hello!

I need to monitor CPU load of every node in a cluster of two J6350 routers
via SNMP. I found KB12142 article which tells that "Work is ongoing to support 
these MIBs on J-Series and SRX Branch in a future release."

Currently my cluster is running JunOS 10.2R3.10.
Does anybody know is there new JunOS version that supports this feature?
Thanks in advance!

-- 
MINO-RIPE
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Dynamic Profiles Question

[Graham Brown]

Hi Caillin,

I've not played with the MX for subscriber management specifically; however
Juniper released a PSN on Thursday detailing a special version of
code targeted specifically for these services.

PSN-2012-10-730 - 11.4X27 Release for MX Subscriber Management

All of the release notes and supporting information (scaling limitations
etc) are found from within the PSN.

HTH,
Graham

On Fri, Oct 5, 2012 at 4:26 PM, Caillin Bathern wrote:

> Hi Everyone,
>
>
>
> I am playing around with subscriber management on 12.2R1.3 MX series in
> the lab at the moment and I have a question about the RI variable.
>
>
>
> https://www.juniper.net/techpubs/en_US/junos12.2/topics/reference/config
> uration-statement/routing-instances-edit-dynamic-profiles.html
>
> This link says that I can configure a static routing instance name
> rather than using the $junos-routing-instance variable yet I am finding
> I cannot configure this.  Does anyone know how this can be done?
>
>
>
> I also cannot find a way to set a default for the junos-routing-instance
> variable which would be an alternative.  Does anyone know how this can
> be done?
>
>
>
> [edit]
>
> admin@MX5T# set dynamic-profiles test routing-instances ?
>
> Possible completions:
>
>   $junos-routing-instance  Dynamic profile routing instance name
>
> + apply-groups Groups from which to inherit configuration data
>
> + apply-groups-except  Don't inherit configuration data from these
> groups
>
> [edit]
>
> admin@MX5T# set dynamic-profiles test routing-instances internet
>
>
> ^
>
> syntax error.
>
> admin@MX5T# set dynamic-profiles test routing-instances internet
>
>
>
> I am also seeing some odd behaviour with vlan rewrite/push/pop/bridging
> when using dynamic profiles and vlan auto-configuration.  Has anyone
> else had issues here or have any recommendations?
>
>
>
> Regards,
>
> Caillin
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Graham Brown
Twitter - @mountainrescuer 
LinkedIn 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp