FRR (fast reroute) este dupa parerea mea cel mai uzitat “feature” de MPLS traffic-engineering. Cand vine vorba de a implementa MPLS TE, toti marii provideri de internet (tier 1 sau 2) se rezuma la FRR deoarece, in cele mai multe dintre cazuri, un “full-mesh” de tunele MPLS configurat cu “bandwith reservation” pentru optimizari de banda creaza mari probleme datorita complexitatii.  Asadar, daca avem o retea MPLS si ne dorim convergenta foarte buna in cazul in care pica un nod sau un link, recomand implementarea FRR.

Sunt intrebat destul de frecvent doua lucruri legate de FRR:

1. De ce nu ne putem baza doar pe convergenta IGP intr-o retea ?
In principiu, depinde de retea. Intr-o retea mare, convergenta IGP este lenta iar 5-10 secunde de “packet loss” sunt de neacceptat. Daca optimizam IGP-ul pentru convergenta “sub-second” il facem foarte sensibil la “packet loss” si referindu-ma la un protocol de tip “link-state” cum de alttel majoritatea retelelor mari gen ISP utilizeaza (OSPF, IS-IS) pentru ca au suport de MPLS , SPF-ul va fi rulat de foarte multe ori, ceea ce fara indoiala ca nu este de dorit.

2. Daca am mai multe “path-option” intr-un tunel MPLS nu se cheama ca fac FRR ?
Nu, pentru ca nu exista “presemnalizare” pentru un tunel de backup. Configurand mai multe “path-option” influentam doar rerutarea LSP-ului.

Inainte de a trece la configurare, voi aminti niste termeni de baza din FRR:

PLR – Point of Local Repair (routerul de unde incepe tunelul de backup)
MP – Merge Point (routerul unde se termina tunelul de backup)
NHop – Next-hop router (routerul care se afla la un HOP distanta de PLR … practic exista link fizic intre PLR si NHop)
NNHop – Next-next-hop router (routerul care se afla la doua hopuri dinstanta de PLR)

 

• FRR node protection

Avem LSP de la R1 la R7 (Tunnel 17) si ne dorim ca traficul dintre aceste doua routere (in sensul R1 -> R7) sa nu fie afectat in momentul in care pica R3. Pentru a ne proteja tunelul MPLS Tu17 vom crea un nou tunel Tu26 intre R2 si R6. PLR este R2, MP si NNHop este R6.


R1 - R7:

(config) # mpls traffic-eng tunnels
(config)# mpls ldp router-id Loopback 0
!
(config-if)# mpls ip
(config-if)# mpls traffic-eng tunnels
!
(config)# router ospf 10
(config-router)# mpls traffic-eng router-id Loopback 0
(config-router)# mpls traffic-eng area 0

R1:

(config) # interface Tunnel17
(config-if)# ip unnumbered Loopback0
(config-if)# tunnel destination 7.7.7.7
(config-if)# tunnel mode mpls traffic-eng
(config-if)# tunnel mpls traffic-eng autoroute announce
(config-if)# tunnel mpls traffic-eng path-option 5 explicit name path-17
(config-if)# tunnel mpls traffic-eng fast-reroute
!
(config)# ip explicit-path name path-17 enable
(cfg-ip-expl-path)# next-address 10.10.10.2
(cfg-ip-expl-path)# next-address 10.10.10.6
(cfg-ip-expl-path)# next-address 10.10.10.22
(cfg-ip-expl-path)# next-address 10.10.10.26

R2:


(config)# interface Tunnel26
(config-if)# ip unnumbered Loopback0
(config-if)# tunnel destination 6.6.6.6
(config-if)# tunnel mode mpls traffic-eng
(config-if)# tunnel mpls traffic-eng path-option 10 explicit name path-26-exclude-3
!
(config)# ip explicit-path name path-26-exclude-3 enable
(cfg-ip-expl-path)# exclude-address 3.3.3.3
!
(config)# interface X [ interfata X catre R3 (node protection) sau R5 (link protection)]
(config-if)# mpls traffic-eng backup-path Tunnel26

  

• FRR link protection

Practic configul este identic. Trebuie tinut cont doar de faptul ca tunelul de backup trebuie sa aiba “head / tail” pe routerele intre care se afla link-ul pe care dorim sa-l protejam (vezi diagrama de mai jos). PLR este tot R2 iar MP si NHop este R5.

 

Sa luam exemplul cu “link protection” si sa cautam explicatia pentru o atat de buna convergenta. Atat timp cat link-ul R2-R5 este UP, R2 forwardeaza pachetele prin Tu16 dupa label-ul primit de la R5 (in cazul nostru label 26)

R2#sh mpls traffic-eng tunnels | b LSP Tunnel R1_t16
LSP Tunnel R1_t16 is signalled, connection is up
InLabel  : FastEthernet0/0, 25
OutLabel : Ethernet1/0, 26
FRR OutLabel : Tunnel25, 26

R2#sh mpls traffic-eng fast-reroute database detail | i Out
Input label 25, Output label Et1/0:26, FRR label Tu25:26

R1#traceroute 6.6.6.6
1 10.10.10.2 [MPLS: Label 25 Exp 0] 280 msec 64 msec 8 msec
2 10.10.10.6 [MPLS: Label 26 Exp 0] 52 msec 40 msec 12 msec
3 10.10.10.26 40 msec *  12 msec

Cand cream pe R2 (PLR) tunelul de backup Tu25 acesta primeste peste primul label de MPLS si label-ul 26 formand un “label stack” astfel incat in momentul in care pica link-ul R2 – R5 si  de pe R2  dispare label 26 de pe E1/0, va fi folosit automat acelasi label 26 de pe Tu25.

R2#sh mpls traffic-eng tunnels | b LSP Tunnel R1_t16
LSP Tunnel R1_t16 is signalled, connection is up
InLabel  : FastEthernet0/0, 25
OutLabel : Ethernet1/0, 26
FRR OutLabel : Tunnel25, 26 (in use)

R1#traceroute 6.6.6.6
Tracing the route to 6.6.6.6
1 10.10.10.2 [MPLS: Label 25 Exp 0] 84 msec 76 msec 12 msec
2 10.10.10.10 [MPLS: Labels 23/26 Exp 0] 100 msec 20 msec 20 msec
3 10.10.10.14 [MPLS: Labels 21/26 Exp 0] 48 msec 52 msec 44 msec
4 10.10.10.18 [MPLS: Label 26 Exp 0] 24 msec 44 msec 8 msec
5 10.10.10.26 12 msec *  36 msec

In cazul “node protection” in care PLR nu stie label de la MP pentru ca nu sunt direct conectate printr-un link, se foloseste flag-ul “Label Recording”.

Notificarea de link down este facuta de alarmele SONET pe interfetele POS (50 ms) sau de “hello-urile” RSVP trimise by default la 100 ms.

Cateva comenzi utile:

show mpls traffic-eng backup-path tunnel 
show mpls traffic-eng fast-reroute backup-prot-preemption 
show mpls traffic-eng fast-reroute timers 
show mpls traffic tunnel backup 
show mpls traffic-eng fast-reroute database 
show mpls traffic-eng tunnels 
show mpls traffic-eng tunnels summary 
show tunnel mpls traffic-eng fast-reroute