[c-nsp] MPLS TE Fast Re-route

[Rob Shakir]

On Tue, Sep 15, 2009 at 12:25:36AM +0100, Charlie Greenaway wrote:
> Hi,
> 
> I have a question on MPLS TE and Fast Re-Route.
> 
> I have a test network and I want to check that the behaviour I am seeing is correct.
> 
> When you set-up an backup path for patch-protection, it would seem that RSVP
> sends signalling messages down the backup path to reserve the bandwidth.
> However, it does not seem to build an LSP and assign labels to it until the
> primary path breaks.  Is this correct?  Has anyone got any advice on using
> MPLS FRR?

Hi Charlie,

What's the platform that your test network is based on? I don't think that what
you're seeing is the intended behaviour, if you have properly functioning FRR.

Looking at as 12410 running 12.0(32)S13, we see that the LFIB does show some
labels for the FRR paths, in both cases. Where my device has built an NNHOP
tunnel (via auto-tunnel), in 'sh mpls traffic-eng fast-reroute database' there
is a new label assigned:

Prefix             Tunnel     In-label Out intf/label   FRR intf/label   Status
10.0.0.0/30 Tu1334     200      PO4/0:Untagged   Tu65464:339      ready  

Looking at label 339:

12410>sh mpls forwarding-table labels 339
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface              
339    3783        x.y.z.a 65455 [4653] 0          Gi1/1.5    a.b.c.d

i.e. there is a label assigned for this re-route, and it has a forwarding table
entry. The same thing is true for any manually configured backup tunnels.

Within your topology, are you running path protection? (I'm not sure whether
your 'patch protection' is a typo). I would still assume that in this case there
is a requirement to have a configured LSP to switch to for protection, the
assumption that one can signal and establish a new LSP within the intended
timeframe for FRR is somewhat flawed.

On your test PE that has configured protection for a tunnel, when you run 'sh
mpls traffic-eng tunnels tu<x> protect' for the tunnel, does the device think
that it has an active FRR path to re-route to (as per the below)?

12410>sh mpls traffic-eng tunnels tu1121 prot | i Fast Rero|Backup Tu|Out
  Fast Reroute Protection: Requested
    Outbound: FRR Ready
      Backup Tu5129 to LSP nhop

If not -- I'd suggest that the device hasn't properly signalled for a FRR path
for the tunnel.

To verify this, can you see a reservation for the tunnel on all the midpoints
for the tunnel? When the label is returned from a P node to a PE, the RRO object
that is returned should contain the label that is expected once the FRR label
has been popped. If the reservation has been made succesfully, the LSP labes are
assigned, and should be in the LFIB throughout the tunnel's path.

One gotcha that we've seen with FRR is platforms that run SSO are incapable of
running auto-tunnel backup (and hence won't let you configure it), this seems to
get to the stage that the device works out that there is no FRR path, and then
tries to configure it, and silently fail. The 'sh mpls tra tu tu<x> prot' then
show something akin to the below:

  Fast Reroute Protection: Requested
    Outbound: Unprotected: no backup tunnel assigned

I'm not sure what FRR advice you'd like, but feel free to ping me a mail on/off
list if you think there's anything I can assist with.

Kind regards,
Rob

-- 
Rob Shakir                      <rjs at eng.gxn.net>
Network Development Engineer    GX Networks/Vialtus Solutions
ddi: +44208 587 6077            mob: +44797 155 4098
pgp: 0xc07e6deb                 nic-hdl: RJS-RIPE

This email is subject to: http//www.vialtus.com/disclaimer.html