IP FRR with MPLS in IOS XR

[aacole]

I'm designing a new service provider infrastructure based on IOS XR/ASR9000 routers, and have a question about the use of IP FRR in an MPLS/IS-IS network. Its for a TV/radio broadcast backbone, so fast convergence is essential.

The configuration documentation I've read implies that IP FRR is only used for traditional IP networks, although product updates and other Cisco information indicates that it is recommended for use in MPLS/LDP networks as well.

Is the documentation out of step with the latest implementation of IP FRR?

As I see this, I'm using IS-IS to give my MP-BGP peers connectivity across the IS-IS core, so any feature that improves convergence for the path between the end points has to be a good thing.

Kit is due to be delivered to pre-stage next week so I'll get a chance to test this anyway, anyone any real world experience of such a setup?     

[Mahesh Gohil]

Hi,

Not sure the information i am providing is useful or not.

We use FRR between two node

P(IOS-XR)-------PE(IOS)

Between these two we create primary tunnel101 as primary travelling over direct link and we have backup of this as tunnel201 which travel to some other path.

Below is configuration from IOS-XR node.

---------------------------Config--------------------

interface tunnel-te101
ipv4 unnumbered Loopback0
load-interval 30
logging events lsp-status reoptimize
logging events lsp-status state
logging events lsp-status reroute
autoroute announce
destination 10.10.10.101
fast-reroute
record-route
path-option 1 dynamic

interface tunnel-te201
ipv4 unnumbered Loopback0
logging events lsp-status reoptimize
logging events lsp-status state
logging events lsp-status reroute
destination 10.10.10.201
record-route
path-option 1 explicit name backup1_Tunnel201

explicit-path name backup1_Tunnel201
index 1 exclude-address ipv4 unicast 10.10.10.2

interface POS0/13/0/1
bandwidth 622000
mtu 4474
ipv4 address 10.10.10.1 255.255.255.252
encapsulation ppp
pos
  crc 32
!
load-interval 30

mpls traffic-eng
interface POS0/13/0/1
  backup-path tunnel-te 201

mpls ldp
interface tunnel-te101
!
interface POS0/13/0/1

rsvp
interface GigabitEthernet0/3/0/1
  bandwidth 1000000

----------------------

Regards # Mahesh

[aacole]

Hi Mahesh,

Thanks for your reply, at this stage I wasnt planning to implement TE tunnels, I just wanted to see if IP FRR would maintain the BGP peerings across a backup path following a failure of the primary path and switch over to the backup path in less than say 50ms.

Andy

[Nagendra Kumar Nainar]

Hi Andy,

It should. IP FRR will have the backp path precalculated and installed in your RIB. When it detects the failure of primary path, it will immediately use the backup path. So you need to make sure the link (or nexthop node) failure detected quicckly.

If it is back-to-back connected, the failure can be detected within millisec. Else, you may use some fast detection mechanism like BFD to detect the nexthop failure.

HTH,

Nagendra

[aacole]

Hi Nagendra,

Ok, thanks, I had thought about using BFD, but after posting up my message I've since found that the underlying DWDM multiplexers have the capability to signal to the locally attached routers if any WAN issues occur. I've yet to test this, but I'm hoping that this feature would give me the sub 50- mS failover times I'm looking for by dropping the local link to the PE router. It certainly looks that way when I read the documentation.

Otherwise, yes BFD has to be the way forward.

Andy