IP/MPLS Loop Free-Alternate Path (LFA)
Fala Pessoal, me chamo José Petrucio e vamos dar inicio uma série de artigos para falarmos de tecnologias e métodos para reparo de falhas em redes de alto performance e desempenho.
Grande maioria dessas tecnologias se enquadram dentro de um conceito chamado Fast Reroute Mechanism ( FRR), implementando em sua maioria em redes de ISP’s. Dentro de FRR temos diversas tecnologias tais como LFA, MPLS TE FRR, REP, BGP PIC, e por ai vai. Porem nessa primeira série de artigos falaremos sobre LFA e rLFA ( remote LFA ). Nessa primeira parte falaremos exclusivamente de LFA, abordando os detalhes, assim como funcionamento na prática.
Fiquem a vontade para comentar e entrar em contato comigo no LinkedIn. Se gostou do que leu, incentivo a dar “claps” aí do lado esquerdo do artigo e compartilhar nos seus grupos. Não se esqueça de seguir a mim e ao TechRebels clicando follow lá em cima :)
Existem vários Fast Reroute Mecanismos focaremos em específico LFA e Remote LFA (Loop Free-Alternate path). Que tem como principal premissa convergência rápida para mitigar falhas de rede, em um time frame extremamente curto.
Hoje em dia muitas aplicações exigem uma rede estável e confiável, entretanto quando uma falha ocorre e inevitável que tenhamos um período de instabilidade ou interrupção por menor que seja. Uma rede que possa reagir rapidamente a essas falhas é essencial. Basicamente é isso que visamos alcançar com ( FRR ).
“Vamos destrinchar essa tech e como podemos aplica-la de forma eficiente”
Primeiro de tudo vamos falar de 2 conceitos importantes e suas diferenças “Fast Convergence and Fast Reroute”
- Fast convergence
Quando falamos de “Fast Convergence” sempre temos que entender os eventos quem ocorrem em nossa rede e como nossos devices reagem a eles.
Durante uma falha basicamente nos temos as seguintes ações sendo executadas para que nos recupera da mesma.
Por mais rápido que detecção falha possa ocorrer, com uso de algumas técnicas para gatilhos dessas falhas como BFD, Carrier delay, link-fault-management (802.3ah)e etc, mudar os SPF throttling timers para uma rápida propagação de falhas. Por mais que essas ações possam ser tomadas e ajustada para melhor performance durante uma falha da rede, ainda teremos que passar por todos os passos descritos acima. Nosso problema reside no tempo total de convergência que pode levar na ordem de segundos em alguns dos cenários. Para que todos os roteadores tenham essa nova informação ou que os algoritmos de roteamento tenha computado novas informações, e então atualizarem data plane dos Routers para novo data path seja usado de acordo essa 4 passos tem que ser concluídos . Em Redes de Service Provider isso poder ser uma grande dor de cabeça para clientes e aplicações que exigem alta performance. Temos como exemplo Voice, Video Stream, Aplicações financeiras e etc.
O que é LFA, e como isso me ajuda?
LFA é um mecanismo que a principal ideia consiste de ter uma entrada instalada em hardware ( Forwarding Plane ), um backup path, que protege nosso link ou node em caso de falhas, comutando o trafego para o backup path imediatamente. O principal objetivo do LFA reduzir o tempo reação falha usando um caminho de backup pré-computado livre de loop (LFA) para o mesmo destino do caminho principal, ou seja, reduzindo tempo convergência e agindo antes que os protocolos de roteamento para reparar a falha.
Em outras palavras nos teríamos caminho de backup que em caso de detecção de falha, o trafego seria imediatamente comutado ( backup path), sem termos que espera pela route engine completar todos processo de atualização baseado nas informações do nosso IGP. Estamos falando de disaster recovery na ordem de sub-seconds , após uma falha massiva na rede reduzindo perda de pacotes ao mínimo possível. Esse tempo de convergência se assimila ao MPLS TE FRR que em certos cenários pode alcançar 50ms.
( alguns testes mostraram um tempo de recovery de 20ms porem maioria das literaturas tratar 50ms como tempo padrão de recovery como existem algumas variáveis que impactam nisso )
Sendo assim podemos expressar Fast Reroute (LFA) com os seguintes passos:
MPLS TE “Fast Reroute” é um mecanismo de Fast Reroute para proteger os túneis MPLS (MPLS TE) de uma falha num link ou ate mesmo no node, permitindo que o trafego continue sendo enviado via um “protected path” ou Tunnel de Backup fazendo by-pass do link ou node atingido pela falha, evitando assim perda de trafego e rápida convergência, algumas literaturas com base em cenários específicos sugerem que tempo de recovery é <= 50ms.
A ideia por trás do LFA é similar ao do MPLS TE FRR que basicamente consiste de um backup path instalado no Forwarding Plane do Router.
Então Porque Não usar MPLS TE FRR ao invés de LFA?
- Simples, LFA não introduz nenhum Extensão de Protocolo, como MPLS TE. Assim como MPLS TE nos fornece um backup path pre-computed.
- LFA tem significado local ou seja não exige modificações em todos os routers da rede para se implementado, implementação é local no router em questão.
- Não exige alterações ou extensões no IGP para se implementado, implementação e planejamentos são simples.
- Recomendado para implementações em POP’s ou sites remotos com multiples path, ou topologia em Anel.
E como isso Funciona ?
A ntes de vermos na prática ainda temos alguns detalhes que precisamos discutir. A RFC5286 que descreve todos aspectos por traz de como LFA funciona. Uma delas são chamadas de “Inequality”. Essas inequality descreve um conjunto de condições que tem serem alcançados para prover um backup path livre de loop. Vamos a elas!
Inequality #1(Link Protection):
- Essa primeira condição define os critérios que deveram ser alcançados para que LFA possa proteger um link em caso de falha.
D(N,D) < D(N,S) + D(S,D)
D = Destination
N = Neighbor potentially LFA
S = Indica Router que realiza o cálculo de LFA ( Source )
Abaixo segue um exemplo de como funciona primeira condição:
Na figura acima vemos que R3(N) pode ser backup path para R1(S) por que esse path satisfaz a condição 1:
4 < ( 2 + 4 ).
De acordo com a primeira condição temos “ D(N,D) < [D(N,S) + D(S,D)]”:
R1 = S
R3 = N
R4 = D
Distância de R3 para destino R4 “D(N,4)” tem que ser menor que a Distância de R3 para source R1 D(N,2) mais Distância de R1 para o Destino que é router R4 “D (S,4)”. O principal objetivo aqui é garantir que ao instalarmos como backup path R3. R3 não enviara o trafego de volta para R1 ( Loop Free-Alternate Path) :).
Inequality #2 (Downstream Path)
- Essa segunda condição se aplica em cenários mais restritivos como por exemplo onde dois routers podem ser um LFA do outro ou em caso node failure.
De acordo com segunda condição temos:
D(N,D) < D(S,D)
No cenário acima podemos ver que o Router 1 LFA Path seria via R2. Esse path satisfaz “inequality 1”.
16 < (9+15)
R2 LFA path seria via R1 que também satisfaz “inequality 1”.
15 < (9 + 16 )
Ambos R1 e R2 tem seus links protegidos em caso de falhar. Mas se Router R3 falhar? R1 e R2 poderiam causar um loop entre eles . Dai entramos com Inequality 2.
D(N,D) < D(S,D)
Em caso de falha do router nesse caso R3 qual Loop free path usar?
R1 LFA será via R2 baseado na condição 2. D(N,D) < D(S,D) logo ( 15 < 16 ) ou seja distancia de R2 para destino R5 é menor que a distancia de R1 para destino.Porem quando olhamos o mesmo da perspectiva de R2 não atingimos essa condição.
De R2 teríamos 16 < 15 via R1 que não satisfaz nossa inequality 2. Logo LFA Path via R1 não seria possível. Porem se aplicarmos mesma inequality 2 no path R2-R4 condição seria alcançada.
14 < 24
Logo a distancia de R4 para o destino R5 é menor que a distancia de R2 para R5. Nesse cenário em caso de “link failure” teremos R1 selecionando R2 como LFA path. R2 de utilizar o path via R4 como LFA path.
Inequality#3 (Node Protection)
- Nossa terceira condição fornece proteção em caso de falha de um “Node”. Basicamente tenta garantir que em caso de falha ao usarmos um Path nosso neighbor router (N) não use um determinado router para alcançar o destino (D).
D(N,D) < D(N,E) + D(E,D)
No cenário acima tendo como base inequality 3, R1 checa se em caso de falha R3 vai tentar usar R2 como repair path.
R1 = S
R2 = E (Neighbor used as next-hop )
R3 = N Neighbor potentially LFA
R4 = D Destination
Parecido com Inequality 2, R1 ao realizar seu cálculo irá levar em consideração se R3 utiliza como path R2. Se sim, esse caminho não atende os pré-requisitos para ser LFA path, a intenção do Node Protection evita usar um node ja em uso pelo primary-path como possível backup path.
Per-Link and Per-Prefix LFA
Per-Link LFA tem como principal objetivo bypass um link que falhou e se baseia somente na“inequality #1” . Existem muitos desafios quando Per-Link LFA é usado, como por exemplo problemas de capacidade, não fornece “Node Protection”. Em certos cenários não funciona, Backup-path pode acabar ocasionando um sub-optimal path.
Não vamos entrar em detalhes por que mais tarde iremos ver que durante nossos teste SPF algoritmo que iremos usar, default configuration é somente Per-Prefix LFA. IOS e ISO-XE não tem suporte Per-link LFA. Per-link LFA é suportado plataformas rodando IOS-XR.
Per-Prefix LFA determina um backup path para cada prefixo. Ou seja, não necessariamente todos os prefixo terão seu backup path pelo mesmo caminho.
Vale a pena mencionar quando o router não consegue um LFA path com protection node, mas um LFA path com link-protection esta disponível, o LFA path com somente link-protection será utilizado.
Vamos Por a mão na massa!!!
Para demonstrar funcionamento do LFA, no nosso LAB estaremos usando OSPF como routing protocol e a topologia que segue abaixo.
LFA fornecer inúmeros proteções baseado em diversas topologias porem melhor proteção possível são em “Meshed Networks” como iremos ver agora.
No nosso cenário iremos focar no prefixo 100.100.100.100/32 antes de configurarmos OSPF para FRR vamos dar uma olhada na nossa routing table no CE1.
quando checamos os outputs acima confirmamos que melhor caminho para se chegar no prefixo 100.100.100.100/32 via CE1 > PE1 > CORE Router.
Agora vamos configurar o OSPF para FRR:
- OSPF FRR configuration:
Configuração é bem simples como podemos ver. Mais temos alguns detalhes para checar aqui.
- fast-reroute per-prefix enable area 0 prefix-priority low , a keyword “low” significa que todos os prefixos terão a mesma prioridade. Por default IOS considera qualquer prefixo /32 como “high priority” prefixo.
Vamos dar uma olhada nas alterações que nossa RIB,FIB, SPF protocol sofreram depois de configurarmos OSFP com FRR habilitado:
Começando pelo nosso “sh ip route” podemos ver que temos uma nova entrada ( repair path ) para prefixo de destino 100.100.100.100/32 em nossa RIB. CEF também aponta repair path via GigabitEthernet1 como repair path, ou seja, nosso control-plane e data-plane estão sincronizados e ciente que em caso de falhar podemos fazer o Switch do trafego imediatamente via esse path.
Logo em seguida temos a saída do “sh ip route repair-paths” que nos trazem uma informação importante. Métrica do nosso repair path que tem um total de 18, maior que métrica atual mas obedece nossas Inequality.
Por ultimo temos a saída do “sh ip ospf rib” que nos mostra mais alguns detalhes importantes.
O primeiro fica por conta do Flag: HiPrio que indica o nosso prefixo tem maior prioridade. Como mencionada antes /32 prefixo são interpretados como High priority. Podemos classificar prefixos específicos como HiPrio para isso basta configurarmos uma “route-map” e classificarmos como priority dentro das configurações do OSPF. Segue exemplo abaixo:
Continuando na análise dos flags nos temos:
Intfdj — Significa que o repair path esta usando uma interface diferente do primary path.
CostWon — caminho com o melhor custo, em alguns casos podemos ter mais de um repair path disponível.
NodeProt — Node Protection esta sendo realizado para o prefix 100.100.100.100/32 ou seja em caso de falha do link entre PE1 e CE1 nosso tráfego sera encaminhado para PE2 que por sua vez para o Core router e não corremos o risco de o nosso tráfego utilizar o link entre PE2/PE1
Dowstr — Inequality escolhida pelo router nesse caso ( Downstream Path D(N,D) < D(S,D))
Agora vamos dar uma olhada em outro cenário e como nosso calculo para LFA path será calculado. Na topologia abaixo nos teremos mais de um repair-path disponível.
Olhando para nossos outputs abaixo reparamos que nosso LFA Path mudou.
Nos temos 2 caminhos candidatos a LFA Backup a princípio ambos com mesma métrica para o nosso prefixo de destino, porem somente um deles foi escolhido como nosso Repair-path
E possível checar quais desse atributos estão sendo usados e claro podemos influenciar esses atributos.
SRLG — (Shared Risk Link Group ) é uma configuração manual que atribuímos a uma interface para evitar aquela interface ou path seja eleito como LFA path.
Primary-Path — Prefere uma path que é parte de um ECMP ( Equal Cost Multipath ), ou seja uma interface que seja um Port-Channel.
Interface-Disjoint — Prefere um Backup LFA via diferente interface que a interface usada no caminho principal.
Lowest-metric — Como o próprio nome diz a seleção de rotas e baseada na menor métrica para o destino quando comparado com outro candidato backup path.
Linecard-disjoint — Backup LFA escolhido via diferente Line Card, isso depende da plataforma em uso.
Node Protecting — Prefere um caminho que não passe pelo mesmo next-hop que o caminho principal.
Broadcast interface disjoint — Evita uma interface conectada a uma Broadcast Network. Exemplo se uma interface esta conectado ao um Switch e esse atributo é utilizado LFA evita caminho via esse path.
Agora que estamos cientes dos possíveis atributos que podemos usar, No nosso novo LFA Path vemos uma coisa bem interessante. Nosso antigo path esta com Flag “SRLG”
Configuração:
Nossa configuração alteramos como OSPF ira fazer seleção de rotas. Usamos o atributo “SRLG” como “tie-break”. Interface G2 é nosso primary-path , ambos Gi1 e Gi2 interfaces, fazem parte do mesmo “SRLG”. SRLG faz com que interfaces membro do mesmo grupo sejam evitadas como repair-path logo em caso de falha do nosso primary-path, Gi1 será evitada como repair-path devido nossa configuração. Como observado antes nosso Path via Gi1 recebeu o flag “SRLG”.
Abaixo nos temos os atributos checados para seleção de rotas antes e depois da nossa configuração.
- SRLG atributo aplicado.
Se observamos bem temos um comando novo adicionado as configurações do OSPF “ fast-reroute keep-all-paths”. Por padrão quando temos OSPF FRR configurado somente os melhor path entres todos os candidatos é mantido.
“ fast-reroute keep-all-paths” nos mostras todos os candidatos avaliados para repair path.
Outro ponto que vale mencionar é que em caso de falha do nosso “repair path” e tivermos múltiplos outro “repairs path” disponível mas que não foram instalado devido as policy de tiebreaks. Nossos policy de tiebreak retorna ao default e os path disponíveis são reavaliados para serem instalados como repair path.
Por ultimo vale destacar cobertura que LFA tem nos prefixos instalados em nosso database.
Como vemos acima 100% dos nossos prefixos estão protegidos ou seja em caso de falha teremos um repair-path para cada prefixo instalado em nossa routing table.
Proteção fornecida por LFA é totalmente baseado no design no qual é empregado. Como dito anteriormente “Mesh Networks” tem melhores desempenhos quanto LFA. Em contrapartida “Ring Networks” são as piores para aplicação de LFA. Em “Ring Networks” temos um inconveniente conhecido como “Micro Loops” e para concertar ou melhor superar isso, surgiu o rLFA (Remote LFA).
RFC 6571 detalha diferentes tipos de Network Designs em especial para Service Provider, e quais os níveis de proteção variam de acordo com cada cenário.
Porem rLFA e MicroLoops serão abordados no segundo post desta serie :).
Conclusão
Cada vez mais procuramos reduzir possíveis falhas em nossas redes e em caso de falha otimizar ou máximo tempo de recovery. Nesse artigo introduzimos um pouco sobre LFA, como uma das ferramentas que podem nos ajudar garantir cada vez mais nível mínimo de interrupção em nossas redes. Abordamos os conceitos por traz dessa feature, assim como, os benefícios, suas diferenças quando comparado outras “fast reroute” features, e como melhor tiramos proveito disso.
Se gostou do conteúdo, dê palmas para o artigo aí do lado esquerdo e compartilhe nos seus grupos. Não se esqueça de seguir a mim e ao TechRebels clicando follow aí embaixo :)
Sobre o autor
José Petrucio é High Touch Technical Support Engineer. Graduado em Redes de Computadores, certificado CCIE R&S. Iniciou a carreira na área de TI como analista e hoje atua em suporte especializado para protocolos de roteamento em ambientes de altíssima complexidade.
linkedin.com/in/jose-petrucio-silva-5a643043
