[c-nsp] FRR Recovery Time

[Oliver Boehmer (oboehmer)]

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