The MPLS-OPS Archive

["Yogesh Dhingra" <yogesh.dhingra@hotmail.com>]

hi Alaerte,

I'm not sure but i think that this will work out when link comes up :

Use this command in global configeration mode.

mpls traffic-eng reoptimize events link-up


Regards,
Yogesh
Sr. Engineer - MPLS NOC,
HCL-New Delhi (INDIA)

>From: <Alaerte.Vidali@nokia.com>
>To: <mpls-ops@mplsrc.com>
>Subject: [MPLS-OPS]: Fast Reroute Behavior when link is recovered
>Date: Thu, 2 Nov 2006 09:47:55 -0600
>MIME-Version: 1.0
>Received: from host.secure4-hosting.net ([209.239.41.31]) by 
>bay0-mc4-f4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2444); Thu, 2 
>Nov 2006 08:34:05 -0800
>Received: (from mplsrc12@localhost)by host.secure4-hosting.net 
>(8.12.11.20060614/8.12.10) id kA2GY3mS012022;Thu, 2 Nov 2006 11:34:03 -0500
>X-Message-Info: LsUYwwHHNt2cuMplLz2Uf7hn6t/0JNgzHJxjkYwAQKM=
>Resent-Date: Thu, 2 Nov 2006 11:19:44 -0500
>X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to 
>mpls-ops-request@mplsrc.com using -f
>x-mimeole: Produced By Microsoft Exchange V6.5
>Content-class: urn:content-classes:message
>X-Security: MIME headers sanitized on host.secure4-hosting.netSee 
>http://www.impsec.org/email-tools/sanitizer-intro.htmlfor details. 
>$Revision: 1.138 $Date: 2003-01-26 11:25:54-08 X-MS-Has-Attach: 
>X-MS-TNEF-Correlator: Thread-Topic: Fast Reroute Behavior when link is 
>recovered
>Thread-Index: Acb+lkM1YPS1ChRsSomO6ZO9BMmQLA==
>X-OriginalArrivalTime: 02 Nov 2006 15:47:56.0954 (UTC) 
>FILETIME=[44356FA0:01C6FE96]
>X-eXpurgate-Category: 1/0
>X-eXpurgate-ID: 149371::061102174831-69101BB0-5D4E7023/0-0/0-1
>X-Nokia-AV: Clean
>X-Spam-Score: 0.001 () HTML_MESSAGE
>X-Scanned-By: MIMEDefang 2.53 on 209.239.41.31
>X-SpamProbe: GOOD 0.0000000 d8f41bcb9a781fdb0381a58d9319527c
>Resent-Message-ID: <yhqXUB.A._g.gqhSFB@host.secure4-hosting.net>
>Resent-From: mpls-ops@mplsrc.com
>X-Mailing-List: <mpls-ops@mplsrc.com> archive/latest/8465
>X-Loop: mpls-ops@mplsrc.com
>Precedence: list
>Resent-Sender: mpls-ops-request@mplsrc.com
>Return-Path: mpls-ops-request@mplsrc.com
>
>Greetings,
>
>I have tested Fast Reroute on 7600 with IOS 12.2(18) SXF5 and after
>recovering the link from a failure, the original tunnel path is
>recovered. For example:
>
>OSRa-----------------OSR1---- -------------OSR2---------OSRb
>                                |                       |
>                                |                       |
>                                --------------------OSR3
>
>Tunnel is between OSRa and OSRb. One explicit path is used, no dynamic
>tunnel at all.
>FRR is configured to protect link between OSR1--OSR2 using link
>OSR1-OSR3.
>When link OSR1--OSR2 fails, FRR recover from the failure using
>OSR1--OSR3--OSR2.
>When link OSR1--OSR2 is recovered, FRR is deactivated and original
>tunnel again follow original path: OSRa--OSR1--OSR2--OSRb.
>That was the result during tests, simulating failures.
>
>But there are user reports saying that when link OSR1--OSR2 is
>recovered, FRR keeps active and original path is not recovered.
>Have you seen this situation?
>
>Thanks,
>Alaerte
>

_________________________________________________________________
The next best thing! Messenger Video Conversation. Click here! 
http://join.msn.com/messenger/overview2000

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml