Re: [j-nsp] Cisco IGP fast convergence
On 30 May 2012 01:52, Colby Barth cba...@juniper.net wrote: I don't agree that you want the SPF IW to = 0. In the case of SRLG's in the network you may want to have a bit of delay in there to try and capture all the incoming LSPs before running an SPF. This is a personal preference and network dependent but would be my recommendation. Your also gonna want to change the IOS-XR lsp generation timers. Absolutely personal preference and you can get lot of data from gathering some historic spf logs to determine optimal config for given network. The n fast then slow approach is much cruder approach, almost like JNPR approach is digital and either situation is optimal or completely fscked up, and CSCO approach is analog, setting itself to needed response for various scenarios. And as this is purely software feature, I would certainly hope JNPR would deploy it, here, as well as interface hold-time, and generally when delays are configured, exponential back-off would be preferred instead of static values. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Cisco IGP fast convergence
Hi Expert, We are planning to deploy MX in our all Cisco network. However, my tech team are not comfortable with mismatch LSA timer which MX unable to configure certain parameter. At the moment we are using the following setting on Cisco. timers throttle spf 50 50 5000 timers throttle lsa 0 20 5000 Has anyone deploy this type of setting and successfully integrate with Juniper without any issue. EZ Joe ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco IGP fast convergence
On Tuesday, May 29, 2012 12:19:19 PM Wan Tajuddin Wan Hussin wrote: Has anyone deploy this type of setting and successfully integrate with Juniper without any issue. You'll quickly notice that many configurable timers in Cisco are not available in Junos. However, this isn't a train- wreck, and they inter-op fairly well. Juniper spend more time adding fast convergence into the code without many options, while Cisco do the same but give you lots of knobs (good and bad thing). Just make sure you tune your timers appropriately for your network conditions, taking into account whether you designing for link or node failure. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco IGP fast convergence
Or just use BFD ... Thank you, -- Doug Hanks - JNCIE-ENT #213, JNCIE-SP #875 Sr. Systems Engineer Juniper Networks On 5/29/12 4:54 AM, Mark Tinka mark.ti...@seacom.mu wrote: On Tuesday, May 29, 2012 12:19:19 PM Wan Tajuddin Wan Hussin wrote: Has anyone deploy this type of setting and successfully integrate with Juniper without any issue. You'll quickly notice that many configurable timers in Cisco are not available in Junos. However, this isn't a train- wreck, and they inter-op fairly well. Juniper spend more time adding fast convergence into the code without many options, while Cisco do the same but give you lots of knobs (good and bad thing). Just make sure you tune your timers appropriately for your network conditions, taking into account whether you designing for link or node failure. Mark. ___ 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] Cisco IGP fast convergence
On Tuesday, May 29, 2012 04:08:40 PM Doug Hanks wrote: Or just use BFD ... Might not always be available on the other side of the link :-). Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco IGP fast convergence
On Tuesday, May 29, 2012 07:41:37 PM Doug Hanks wrote: Should be an architectural requirement imho :D The reality is always different, as you know :-). The situation is compounded when kit is older and can't be easily replaced, for various reasons; or is off the development cycle, e.g., the 6500 used to have BFD support on SVI's, and then it was removed in newer code. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco IGP fast convergence
On Tue, May 29, 2012 at 3:19 AM, Wan Tajuddin Wan Hussin eazy_...@yahoo.com wrote: We are planning to deploy MX in our all Cisco network. However, my tech team are not comfortable with mismatch LSA timer which MX unable to configure certain parameter. At the moment we are using the following setting on Cisco. timers throttle spf 50 50 5000 timers throttle lsa 0 20 5000 Has anyone deploy this type of setting and successfully integrate with Juniper without any issue. These timers throttle SPF runs and LSA flooding. I don't recall anything for controlling the latter in Junos, but there are some knobs under protocols/ospf/spf-options that accomplish results similar to the former. That being said, you may not need to tweak anything on Junos. The IOS defaults tend to be conservative because they are designed for older/slower hardware, whereas Junos was designed with the assumption that the control plane would be separate and would have reasonable processing power available. If you're concerned about transient loops then loop free alternates are better use of your resources. They don't prevent transient loops (nothing can), but they allow the forwarding plane to compensate for certain link failures. You should also look into BFD (as Doug mentioned), though that's a solution for a different problem. :w ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco IGP fast convergence
On (2012-05-29 07:08 -0700), Doug Hanks wrote: Or just use BFD ... Not really solution for SPF timers though. Juniper is clearly lacking in SPF configuration options. What you operationally want is 0 delay for SPF calculation to start, to cover typical event of single link going down as rapidly as possible. (Sure for some topologies LFA will cover that) But if LSPs keep coming in, you want to exponentially back-off, to run SPF less and less frequently. Same thing as interface up/down dampening, here also JunOS has just static values, no exponential back-off. Both cause you to choose rather conservative value in JunOS, while in IOS you can rock aggressive values. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco IGP fast convergence
All-
JUNOS has a few config options and we have interop'd in the field for sometime
with Cisco's IGP FC config's:
SPF IW value defaults:
IOS-XR default: IW: 50ms, 2ndaryW: 200ms, MaxW: 5000ms
JUNOS defaults: IW: 200ms, MaxW: 5000ms, RRs: 3
The Cisco alg. is an exponentially increasing timer, whereas ours is not. As
an example, if a router receives a new LSP at time 0, Cisco will run a full SPF
50ms later. If a 2nd LSP is rx'd, the router will not run another SPF
computation for a minimum of 200ms. If a 3rd LSP is rx'd then the next SPF IW
timer is 400 msec and so on and so forth until the maximum wait achieved.
In the JUNOS implementation, we will run consecutive full SPFs on 200 ms
intervals 3 times and then we wait the holddown interval before we run another
full SPF. Forcing the implementations to approach one another requires config
on both sides. The end result is you really want to tune the IW values to
match, reduce the IOS-XR secondary wait timer and reduce both the JUNOS and
IOS-XR holddown timers to approach SPF alignment.
JUNSO config:
spf-options {
delay 50;
holdtime 3000;
rapid-runs 3;
}
IOS-XR SPF configuration:
spf-interval initial-wait 50 secondary-wait 100 maximum-wait 3200 level 2
I don't agree that you want the SPF IW to = 0. In the case of SRLG's in the
network you may want to have a bit of delay in there to try and capture all the
incoming LSPs before running an SPF. This is a personal preference and network
dependent but would be my recommendation. Your also gonna want to change the
IOS-XR lsp generation timers.
IOS-XR SPF configuration
spf-interval initial-wait 50 secondary-wait 100 maximum-wait 3200 level 2
This will align JUNOS and IOS-XR in that regard.
There are also changes recommended for cnsp intervals, LSP generation intervals
lsp intervals that require changes (mostly in IOS-XR) that you should
consider. Unicast me if you are interested in a thorough explanation and JUNOS
and IOS-XR config's.
thanks,
-Colby
On May 29, 2012, at 2:38 PM, Saku Ytti wrote:
On (2012-05-29 07:08 -0700), Doug Hanks wrote:
Or just use BFD ...
Not really solution for SPF timers though. Juniper is clearly lacking in
SPF configuration options. What you operationally want is 0 delay for SPF
calculation to start, to cover typical event of single link going down as
rapidly as possible. (Sure for some topologies LFA will cover that)
But if LSPs keep coming in, you want to exponentially back-off, to run SPF
less and less frequently.
Same thing as interface up/down dampening, here also JunOS has just static
values, no exponential back-off.
Both cause you to choose rather conservative value in JunOS, while in IOS
you can rock aggressive values.
--
++ytti
___
juniper-nsp mailing list
juniper-nsp@puck.nether.netmailto: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
