Traffic Engineering —MPLS-TE — Fast Reroute
Neste artigo vamos entender uma das features de proteção para LSP, com o objetivo de diminuir ou eliminar a perda de pacote nas falhas dos links de capacidade em um core MPLS, durante a convergência do túnel LSP.
Espero que você curta bastante a leitura. Não esquece de me seguir aqui e ao TechRabels clicando follow lá em cima.
Escrevi em um post passado sobre os protocolos de labels utilizado em MPLS, caso você seja novato aqui no TechRebels ou perdeu algum degrau da nossa escalada, sugiro seguir o fluxo dos posts para as peças se encaixarem. Neste post será focado apenas no protocolo RSVP.
Fast Reroute
Um túnel LSP estabelecido sobre a MPLS é um canal entre dois roteadores. Com o fast reroute será pre-estabelecido um segundo túnel temporário para manter o encaminhamento de pacotes, enquanto ocorre o recálculo do LSP principal.
O túnel secundário é mantido através de roteadores intermediários ao path do LSP, demonominado DETOURs, este roteador por padrão deverá estar em até seis saltos de distância do Headend. Um importante detalhe, nesta feature a largura de banda no tunnel secundário não é garantida e nem sempre será o melhor caminho até o TailEnd (destino).
Vamos observar, a solicitação do Fast Reroute em um túnel MPLS.
Detalhes sobre a configuração de túnel:
O nome do LSP foi configurado como "FAST-REROUTE"
Tem como origem o IP 10.0.0.1 e como destino ao IP 10.0.0.2, também possui requesito adicional a configuração a largura de banda de 1Mbps.
Para verificar se o túnel continuará enviando trafego na falha do path primário (10.12.1.2), devemos identificar se o fast-reroute encontrou um DETOUR (path alternativo).
Iremos provocar a falha do path primário, e vamos observar o comportamento do LSP.
Na próxima tela será exibido os logs com o recalculo do LSP para o roteador (10.0.0.2), perceba os milésimos de segudos para reestabelecer o túnel primario, nesse período de tempo o LSP foi mantindo UP por um roteador DETOUR, não havendo perda de pacote ou percepção de convergencia para os serviços que estão sendo transportados entre os roteadores.
Temos um flag MBB (Make Before Break) é quando o path primário foi identificado (que é um pre-requesito para nosso túnel principal), o trafego volta a fluir por este, deixando de utilizar o path identificado pelo DETOUR (fast reroute).
O túnel LSP foi estabelecido por outro path (10.12.2.2), note que o fast-reroute permanece sendo requisitado em seu novo path.
Nosso pacotes estão voando em nosso backbone!!!
Ambos exemplos, temos um roteador com funcão de DETOUR. Mas se este não estiver em seis saltos do Headed, qual será o comportamento do MPLS-TE?
No cenário sem um DETOUR, o túnel LSP deverá ser recalculado, ou seja, iremos ter perda de pacotes.
Espero que tenha sido objetivo em demostrar a configuração e verificação técnica da feature fast-reroute. Por ser uma topologia com apenas dois possíveis paths, os logs são bem pequenos (O objetivo é facilitar o entendimento dos logs).
Certamente é um incremento de resiliência fantástica em seu backbone MPLS.
Sobre o autor:
Renato Antonio é Engenheiro de Redes na Tely. Graduado em Redes de computadores pela Unibratec, certificado CCIE RS pela Cisco Systems e JNCIS-SP e JNCIP-SP pela Juniper.
#Juniper #ServiceProvider #TrafficEngineering #RSVP #LDP #ISIS #JNCIS-SP #CCIE
