[c-nsp] FRR Recovery Time

[gladston at br.ibm.com]

Thanks a lot Oliver,

>From what I read on Cisco pages, only these alarms trigger the line 
protocol down:
-Section loss of signal                         SLOS
-Section loss of frame                  SLOF
-Line alarm indication signal   LAIS 
 
And these alarm do not trigger the line protocol down by default: (but can 
do if configuring 'pos delay trigger path...') 
-Path alarm indication signal   PAIS
-Path remote defect indication  PRDI
-Path loss of pointer 

We are only receiving LRDI alarms on RB1. I could not find reference for 
this alarm. Do you know about this specific alarm, if it should trigger 
the line protocol down or if there is a specific command to do so?

Cordially,
------------------------------------------------------------------
Alaerte Gladston Vidali
IBM Global Services - SO
Tel.55+11+2121-2879   Fax:55+11+2121-2449




"Oliver Boehmer \(oboehmer\)" <oboehmer at cisco.com> 
23-01-2006 09:25

To
Alaerte Gladston Vidali/Brazil/IBM at IBMBR
cc
<cisco-nsp at puck.nether.net>
Subject
RE: [c-nsp] FRR Recovery Time






gladston at br.ibm.com <mailto:gladston at br.ibm.com> wrote on Sunday,
January 22, 2006 9:59 PM:

> Sorry it took so long to get the requested information. It was
> necessary to wait for a maintenance window.
>
> There is a new information. We used RSVP hellos to detect the
> failure, and this test revealed that FRR is working pretty well. The
> problem is that without RSVP hellos the POS alarms are not enough
> deactivate the remote interface on the remote end router to have
> bidirectional communication recovered.
>
> The failure is simulated disconnecting the fiber on the POS interface
> of RA1.
>
> I am wondering if the Carrier has some configuration that does not
> let the POS alarms arrive at RB1 when the fiber on RA1 is
> disconnected.  Any feedback concerned to this is really appreciated.

Well, if your carrier can't deliver any remote alarms to RB1, this is
bad (and is actually *very* strange) and will prevent you from doing
FRR. Did you collect "show controller pos" while the link was down?

Can you try

int pos x/x
carrier-delay ms 0
pos ais-shut
pos delay triggers line 100
pos delay triggers path 100
pos report lrdi
pos report lais
pos report prdi
pos report pais
pos report slos
pos report slof

on your POS link to see if it makes a difference? If your POS link is
unprotected, you could also tune down delay/line triggers to zero.

In case it doesn't work out, the best you can do in this case is to tune
your OSPF so RB1 will be notified about the failure at RA1 using LSA
updates. This can be done in sub-seconds as well by tuning down
carrier-delay to 0 sec on your link and tuning down OSPF's exp-backoff
timer for SPF/LSA updates, for example:

router ospf 1
timers throttle spf 50 20 5000
timers throttle lsa all 0 20 5000
timers lsa arrival 15
timers pacing flood 15

Hope it helps,

oli