MPLS TE para engenharia de trafego no seu backbone

Boa tarde Network Folks! Como estão?

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

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

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 adicao 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!