lá Network Folks !!
Meu nome é Pedro e sou analista SR de redes com foco em Data Centers e Service Providers. Há 2 anos criei o site www.howtonetwork.com.br e posto diversos artigos técnicos sobre diversos temas de routing/switching voltados para esses dois ambientes para ajudar a comunidade técnica que encontra dificuldade de alguns temas específicos em PT/BR e uso referencias de DBZ (Dragon Ball Z) para dar alivio cômico nesses assuntos técnicos rs. Irei deixar esse post sobre MPLS TE para engenharia de trafego no seu backbone que fiz a algumas semanas e convido a todos para acessarem os demais artigos no site que mencionei a cima. Let's routing!
Nesse artigo irei explicar sobre o que é MPLS TE (Traffic Engineering) que tanto ouvimos falar e porque implementa-lo no seu backbone ISP para prover alta disponibilidade e engenharia de trafego para os seus clientes. Quero deixar avisado que o tema MPLS TE é muito extenso e complexo, e que a ideia desse artigo e deixar o mais objetivo e claro possível para que seja usado como um apoio inicial para quem estiver estudando poder seguir em outros links/vídeos/livros mais profundos nesse assunto. Outro ponto, sugiro que para você seguir com a leitura desse artigo, que veja esse artigo que escrevi sobre o que é MPLS , e esse vídeo dissecando MPLS do 0 feito pelo Leonardo Furtado para comunidade Tech Talk!
Pega o seu café bem forte e vem comigo!
O que é MPLS TE?
MPLS TE é uma das solucoes que rodam no topo do MPLS para fornecer engenharia de trafego e redundância de caminhos. Imagine o radar do dragão do DBZ. Ele já possui "pré mapeado"onde as esferas do dragão estão e os personagens seguem o caminho ate o destino. O que o MPLS TE faz é justamente isso, nos iremos "pré mapear" o caminho ate o destino pois as vezes nem sempre o caminho que possuímos (baseado na tabela do IGP) é de fato o melhor caminho.
Para realizar o MPLS TE , usaremos o RSVP (Resource Reservation Protocol) para ser o nosso Control plane para realizar algumas funções para que o MPLS TE funcione, sendo elas :
Reserva de recursos para aplicações.
"Re routing"sem a necessidade de alterar métricas do IGP da rede
Estabelecimento e manutenção dos LSP's do túnel.
Por que MPLS TE?
Imagine o cenário abaixo! Possuímos 2 caminhos possíveis para chegar em R5 partindo da origem R3. Podemos ir via R4-R5, ou R1-R2-R5. Pelo método IP tradicional, R3 iria para R5 via R4 já que o caminho R3-R4 esta up para chegar ao destino. Porem, o links em R3-R4 esta congestionado (ou degradado) e a experiência para chegar em R5 esta muito ruim. Do método tradicional, teríamos que mexer em métricas IGP em R3 para que ele piore o caminho via R4 e que comece a usar R1, o que nem sempre e vantajoso e pode desencadear diversos problemas. Ai que o MPLS TE brilha! Com o MPLS TE, podemos criar um tunel (nesse exemplo, de R3 para R2) para que somente o trafego com destino a R5 passe por esse tunel.
Essa definição de caminhos do túnel podem ser em dois formatos:
Explicit Paths = Onde eu defino manualmente o caminho que o trafego ira fazer na rede MPLS
Constraint Based = Baseada na métrica do próprio IGP (modo default do MPLS TE) e somente suportado no OSPF e IS-IS.
Cenario
Na topologia abaixo, iremos configurar 2 tuneis MPLS TE para dois clientes distintos (CLI-A em rosa e CLI-B em azul). Esses clientes possuem cada um uma L3VPN (se você não sabe o que é isso, sugiro que veja esse link e esse vídeo) como serviço com a operadora de ASN 65000.A ideia e fazer com que cada cliente use um link para mostrar a manipulação de trafego sem alterarmos nada no IGP.
OBS: Não irei entrar no mérito as configurações da L3VPN em si pois não é o foco desse artigo
Vamos começar?
1)Habilitar o MPLS no core
Esse passo já foi feito no artigo citado no começo desse de "O que é MPLS".
2)Habilitar o MPLS TE no core MPLS e configurar o RSVP
Habilitaremos a feature MPLS TE em todos os roteadores do backbone MPLS com o comando abaixo
PE1,2,P1,P2,P3
Feito isso, iremos configurar o RSVP nas interfaces que estão na nuvem MPLS. Essa configuração é necessária para prover a comunicação do Headend-to-Tailend (Headend é o PE que iniciou a comunicação, e tailend é o roteador de destino no fim do caminho).
PE1
P1
P2
P3
PE2
Como podemos ver, definimos a reserva de banda de 70Mbps para as interfaces.Esse valor DEVE estar disponível em todo o caminho que o túnel ira passar (que iremos cria-lo daqui a pouco). Abaixo um comando show da demonstração da reserva de banda que criamos.
PE1
3)Habilitar MPLS TE no nosso IGP core
Após isso, vamos configurar o MPLS TE no nosso IGP (no caso, OSPF). Isso é necessário para o flood de informações de alocação de recursos pela rede.Os atributos de recurso são inundados pelos roteadores para torná-los disponíveis no roteador de headend do túnel TE durante a computação do caminho LSP.
OBS:O MPLS TE só e suportado nos IGP's OSPF e IS-IS com suas devidas extensões.
Vamos realizar a configuração em todos os routers da operadora.
PE1
P1
P2
P3
PE2
4)Configurar o tunel MPLS TE
Vamos a configurar os tuneis MPLS TE dos nossos PE's.
Veja que definimos qual o caminho explicito (path-option 1 explicit) que o túnel irá passar. Como possuímos dois tuneis, fiz a configuração de dois caminhos explícitos para ilustrar trafego da VRF-A passando pelo túnel 2 e VRF B passando pelo túnel 1.
PE1
PE2
Abaixo podemos ver os tuneis UP.
PE1
PE2
O comando abaixo mostra quais os hops que os tuneis explícitos que configuramos irao fazer para alcancar o destino que definimos no "tunnel destination".
Tunnel1 explicit path
Tunnel2 explicit path
5)Configurar o roteamento através do túnel MPLS TE
Tuneis configurados e UP, vamos configurar o roteamento para passar através do tunel MPLS TE. Podemos fazer de duas formas isso.Podemos fazer via rota estática , ou forma dinâmica via "autoroute announce" na configuracao da interface túnel (item 4 demonstrado anteriormente). No nosso caso, nos usamos as duas formas. O autoroute sendo usado para o destino 10.2.2.2 e estática para 10.222.222.2222.
PE1
Você pode esta se perguntando, porque dois tuneis, e porque o destino é a loopback? Se verificarmos a tabela de roteamento da vrf CLI-A, vemos que recebemos o prefixo 10.2.2.0/24 com o next-hop de 10.222.222.222, e na vrf CLI-B para alcançar 10.2.2.0/24, nosso next-hop 10.2.2.2 (esses endereços são as loopbacks de PE2).
Para fins didáticos, eu criei 2 tuneis onde cada trafego (VRF CLI-A e VRF CLI-B) passe em tuneis diferentes.
Mas que efeito tem esse anuncio de 10.2.2.0/24 chegar com next-hop de 10.222.222.222? Bom,PE2 anuncia a rede da vrf CLI-A com o comando " bgp next-hop Loopback1"na configuração da VRF, o anuncio da rede VRF CLI-A via PE2, chega como endereço de next-hop a loopback de 10.222.222.222. Isso foi necessário para demonstrar como o caminho será diferente entre as VRF's. Como essa loopback 10.222.222.222 não participa do MPLS (logo, não possui label) e é usada somente para fins de redirecionamento de trafego, eu preciso informar ao PE1 (no nosso caso, de forma estática) que para ele alcançar a rede 10.222.222.222, ele precisa enviar o trafego pelo Túnel 2 (e o inverso ocorre no PE2 para a loopback 10.111.111.111 de PE1). Fazendo isso, todo o trafego do CLI-A será transportado através do Túnel 2, ja que o next-hop para alcançar a rota é alcançável via tunel 2.
PE1
Abaixo as tabelas de roteamento das vrf's do ponto de vista de PE1.
PE1 vrf CLI-A 10.2.2.0/24 via 10.222.222.222
PE1 vrf CLI-B 10.2.2.0/24 via 10.2.2.2
Vamos testar a comunicação e demonstrar que cada VRF passa por um túnel diferente?
CPE1-CLIA to CPE2-CLIA (PE1-P1-P2-P3-PE2)
CPE1-CLIB to CPE2-CLIB (PE1-P1-P3-PE2)
Perfeito! Comunicação funcionando perfeitamente em VRF's distintas e por tuneis distintos.Agora, vamos testar a alta disponibilidade do túnel? Derrubei a comunicação entre P1-P3 para que o único caminho disponível seja P1-P2-P3, porem , o CLI-B paga por um SLA mais agressivo, sendo obrigado garantirmos que ele não fique indisponível. Com isso, temos que garantir que o túnel que esse cliente passa tenha um outro caminho em caso de falha no caminho principal. Poderíamos ter usado o FRR (Fast reroute) mas para o artigo não ficar extenso, somente criei outro explict-path usando o caminho criado para o CLI-A.
PE1 Tunnel1 com dois caminhos possíveis
Feito a adição desse caminho no path-option , vejamos como ficou a conexão do CPE1-CLIB com destino ao CPE2-CLIB?
CPE1-CLIB traceroutes
Perfeito.Quando derrubamos a conexão, o caminho para alcançar o CPE2-CLIB mudou (conforme a diferença demonstrada nos traceroutes) e a comunicação se manteve intacta.
Espero que esse artigo ajude a clarear e a ilustrar um pouco o poder que o MPLS TE tem e como ele é um forte aliado para o backbone dos ISP's. É um tema complexo, então não se sinta desanimado em não entender na primeira lida e procure pegar demais fontes conforme adicionei no decorrer do artigo.
Até a próxima!
