OSPF LFA loop-free alternate FRR and BGP PIC best-practices cisco

28.02 2024 | by massimiliano

OSPF LFA (Loop Free Alternate) Trova un path di backup (quando il path principale fallisce) entro un valore temporale inferiore […]

OSPF LFA (Loop Free Alternate)

Trova un path di backup (quando il path principale fallisce) entro un valore temporale inferiore a 50msec

OSPF calcola il path di backup in una pre-computation order ed installa il backup next-hop nella sua forwarding table

OSPF utilizza due metodi per il calcolo del LFA FRR

per-link: per tutte le prefix che sono raggiungibili attraverso uno stesso link, ospf calcola il path di backup assegnando loro lo stesso indirizzo next-hop

per-prefix: in questo caso ospf utilizza un path di backup su base prefix ed offre un migliore load-balancing, quindi ciascuna prefix può usare differenti links alternativi

quando ospf utilizza un path di backup, non fa riferimento al miglior path su base metrica, ma utilizza in algoritmo di tie-break per decidere quale percorso utilizzare, chiamati: SRLG (shared risk links groups), interface protection, broadcast interface protection, node protection, downstream path, line-card disjoint interfaces, metric, ecmp primary e secondary

SRLG (shared risk links groups): rappresenta un gruppo di interfacce che hanno la stessa probabilità di cadere allo stesso tempo, ad esempio delle SVI che utilizzano la stessa interfaccia fisica

Interface Protection: non calcola il path di backup (LFA) che utilizza la stessa interfaccia di uscita utilizzata per il path primario

Broadcast Interface Protection: non calcola il path di backup (LFA) che utilizza la stessa rete broadcast come path primario (con una rete broadcast ad esempio un switch, si potrebbero avere differenti next-hop ma usare lo stesso link e se uno switch fallisse si rischia di avere down sia il path primario che quello di backup)

Node Protection: non calcola di path di backup (LFA) che utilizza lo stesso next-hop router come path primario

Downstream Path: simile a EIGRP feasible successor, si basa sul concetto di avere un neighbor con una metrica più bassa verso la destinazione come metrica totale del path primario

Line-card Disjoint Interfaces: non calcola il path di backup (LFA) che utilizza la stessa line-card per il path primario

Metric: il calcolo del path di backup è eseguito su un tie-break algoritmo e non sul concetto di metrica più bassa; in ogni caso possiamo utilizzare questo attributo di metrica come tie-break per il calcolo dell’LFA

ECMP primary: preferisce un path di backup appartenente all’ equal cost multipath (ad uno dei links ospf in ecmp)

ECMP secondary: preferisce un path di backup che non appartiene all’equal cost multipath

OSPF Remote LFA è utilizzato quando è necessario bypassare un certo router come next-hop path utilizzando un tecnica di tunneling chiamata Remote-LFA attraverso un protocollo di segnalazione via MPLS LDP (LSP tunnel)

Remote-LFA architectures:

Example Config OSPF LFA

R1, R2, R3, R4, R5, R6:

under interface

mpls ip

oppure sotto ciascuna interface che lavora in ospf

mpls ldp autoconfig area 0

2) abilitare gli mpls hello request from non direct connected routers (comportamento di default) poiché abbiamo bisogno di creare un collegamento tra due routers non direttamente connessi

mpls ldp discovery targeted-hello accept

3) abilitare il remote LSA sotto il processo OSPF in tutti i router del dominio

router ospf < process >

fast-reroute per-prefix enable area 0 prefix-priority low

fast-reroute keep-all-paths

fast-reroute per-prefix remote-lfa tunnel mpls-ldp

BGP PIC CORE and EDGE

BGP PIC CORE: diminuisce i tempi di convergenza quando un Core Router fallisce ed il processo IGP (OSPF or ISIS) deve trovare un percorso di backup (best path) verso il router di confine PE (edge router)

BGP PIC EDGE: diminuisce i tempi di convergenza quando un router edge PE fallisce ed il protocollo BGP deve indirizzare il pacchetto a differente router edge PE

BGP PIC CORE aiuta a velocizzare i tempi di convergenza quando vi è un failure all’interno della rete CORE ed il BGP next-hop non cambia

Con una FIB di tipo flat dove abbiamo una relazione 1:1 tra prefix e next-hop, quando un next-hop cambia (a causa di un fault) il router fa un lookup della sua tabella FIB per ciascuna prefix ed aggiorna il relativo next-hop, caricando di molto la CPU del router stesso

Una nuova FIB chiamata hierarchical FIB migliora questo processo di computazione attraverso una differente memorizzazione del BGP next-hop e del IGP next-hop con il vantaggio che quando l’IGP next-hop cambia solo la parte di FIB che è interessata ad essere aggiornata cambia, in modo indipendente dalla prefix

La hierarchical FIB è supportata da molte piattaforme; in caso non fosse supportata (ad esempio in IOS cisco) possiamo abilitare questa feature con il comando:
- cef table output-chain build favor convergence-speed
- tuning IGP timers
- implement BFD or FRR

BGP PIC EDGE aiuta a velocizzare i tempi di convergenza quando vi è un failure a livello di PE routers oppure in un link di collegamento tra PE-CE nodes, ed il BGP ha bisogno di convergere rapidamente tra differenti PE del dominio

Configurare il BGP per permette di preinstallare un path con next-hop di backup

Example config BGP PIC

P2 RR

router bgp <as>

address-family ipv4

bgp additional-paths select all

neighbor < ip_address > additional-paths send

neighbor < ip_address > advertise additional-paths all

router bgp <as>

address-family ipv4

bgp additional-paths install

neighbor < ip_address > additional-path receive