Hi Carsten,
Hope you are well...
On 02/07/2002 0:28, "Strahler, Carsten" <Carsten.Strahler@lambdanet.net>
wrote:
> Hi Dave,
>
> thanks for your response. You said, that secondary path + fast reroute is
> the fastest option.
> But why should I establish a secondary path when I use fast reroute?
> As I understand fast reroute each LSR on the path computes his own detour.
> When I configure a secondary LSP and the primary fails, the secondary
> becomes active. And if the seconadary fails too fast reroute will be used.
> Am I wrong ?
Carsten the fast-reroute will be made immediately on the detection of a
break for all LSPs it is configured for.
When a path is broken it can take time for the tear message to be received
by the head end/ingress LSR. Only when this happens will any change be made
to secondary (or standby). So having fast reroute provides a short term
fast fix until the switch to the backup LSP is made.
You can have a secondary or a standby as your backup, as fast reroute will
keep traffic flowing while a standby LSP is signalled. There will be no
difference in speed of the recovery (ie traffic flowing) there will only be
a difference in speed of the cutover to the backup LSP (secondary/standby)
You have to decide if you want to have your backup LSPs pre-signalled
(thereby taking up resources) or signalled at the time of the primaries
failure (thus taking time to be signalled)
If you have a primary and secondary you must take into account fate sharing.
If have a standby then it will not share the same fate as it has to be
signalled after a break.
Hope this helps
> Carsten
>
>> -----Ursprüngliche Nachricht-----
>> Von: Dave Humphrey [mailto:dave.humphrey@telindus.co.uk]
>> Gesendet: Montag, 1. Juli 2002 18:34
>> An: 'Strahler, Carsten'; juniper-nsp@puck.nether.net
>> Betreff: RE: MPLS redundancy - fast reroute or secondary path
>>
>>
>> There are various options which increase speed of recovery
>> but require more
>> state to be retained.
>>
>> Secondary LSP's can be configured to back-up a Primary, the
>> secondary LSP's
>> can be pre-signalled or not. Pre-signalling cuts down on the
>> time it will
>> take traffic to switch to the secondary because it will
>> already be up. the
>> downside is that the routers on the secondary path will have
>> to maintain
>> "state" for an LSP which is not being used. State ikn the
>> case is the RSVP
>> traffic (mainly refreshes) to maintain the LSP.
>>
>> Fast reroute in Juniper terms should be the quickest way of
>> recovering from
>> LSP failure. Each node in the path calculates a detour around it's
>> downstream neighbor which will kick in if that neighbot
>> dissappears. When
>> the failure is detected the node doing the rerouting will
>> signal back to the
>> ingress LSP that fast reroute has been invoked and the
>> ingress LSP can then
>> make its own decision about re-routing the LSP.
>>
>> If you configure a primary LSP reversion will always take
>> place at least
>> once. To avoid this configure two secondarys rather than a
>> primary and a
>> secondary. With this set-up there is no primary LSP to revert
>> to. Just make
>> sure that the path you want to use first is the secondary you
>> configure
>> first.
>>
>> To summarise:
>>
>> Primary no secondary = slowest. (Primary will recover via IGP
>> if possible)
>> Primary and non standby (non pre signalled) secondary = Next slowest.
>> Primary and standby secondary )pre signalled) = A bit faster
>> than above.
>> Primary and standby secondary with fast reroute = fastest.
>>
>> If reversion is not wanted then configure no primary and two
>> secondaries.
>>
>> Dave
>>
>> -----Original Message-----
>> From: Strahler, Carsten [mailto:Carsten.Strahler@lambdanet.net]
>> Sent: 01 July 2002 17:14
>> To: juniper-nsp@puck.nether.net
>> Subject: MPLS redundancy - fast reroute or secondary path
>>
>>
>> Hi,
>>
>> to minimize the paket loss when a LSP fails Juniper provides
>> two mechansim -
>> fast reroute and secondary path.
>> What are the pro and cons of both ? Are they revertive ?
>>
>> Thanks
>>
>>
>> ------------------------------------------------------------
>> Carsten Strahler
>>
>> IP Planning
>>
>> Lambdanet Communications GmbH (AS 13237)
>> web: www.lambdanet.net
>> -----------------------------------------------------------
>>
>
>
-- Gary (SysTest) 1.3.327 x 62618
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:36 EDT