Introducao ao IPv6 Provider Edge over MPLS e 6VPE

Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE sobre Infraestrutura BGP-Free Core com MPLS Traffic Engineering

Apresentação

Que "salada" de tecnologias, hein?! Você provavelmente deverá estar pensando "tudo isso?", mas, no entanto, permita-me esclarecer: são tecnologias combinadas através da abordagem modularizada provida pelas infraestruturas baseadas no Multiprotocol Label Switching (MPLS), portanto faz todo o sentido! Este artigo dissertará sobre as tecnologias em foco exatamente conforme mostrado em seu título.

Justificativas e motivadores para a adoção do 6PE e 6VPE

Antes de começarmos a falar dos motivadores, é importante salientar que o IPv6 Provider Edge over MPLS (6PE) e 6VPE não são tecnologias novas. Estas tecnologias estão no mercado há muitos anos e com inúmeros casos de sucesso em muitas operadoras de grande porte, e foram muito úteis por anos, fundamentais até, em alguns casos conhecidos, para viabilizar a adoção bem mais tranquila do IPv6 nas infraestruturas de muitas operadoras.

Começando pelo 6PE, todo o conceito da solução é o de viabilizar o transporte do tráfego de clientes do provedor, sejam residenciais ou corporativos, com a família de endereços IPv6 Unicast, mas que, ao mesmo tempo, o próprio backbone da operadora destes clientes ainda não está preparado para suportar o IPv6. Isto é, um backbone inteiro onde não há endereçamento IPv6 e, consequentemente, não há roteamento de prefixos IPv6 através de adjacências IGP por IPv6 e também as sessões BGP com esta família de endereços IPv6 Unicast. Tecnicamente eu, Leonardo Furtado, prefiro uma infraestrutura completamente em pilha dupla (IPv4 + IPv6) do que partir para uma linha de projetos com 6PE, até mesmo porque houve uma evolução drástica nas arquiteturas dos roteadores vigentes, então não haveria qualquer problema em acomodarmos um dual stack nos dias atuais, e já sendo assim por vários anos. No entanto, há uns 10 anos ou mais, muitas operadoras tinham em seus backbones - e muitas ainda possuem - equipamentos um tanto obsoletos que possuíam limitações tais como a quantidade de prefixos que poderiam ser programados em suas estruturas de comutação baseadas em hardware (TCAMs com M-trie ou Tree Bitmap, etc.), sendo que em alguns casos equipamentos obsoletos escalavam para no máximo 1 milhão de prefixos em hardware, incluindo ou misturando IPv4, IPv6 e MPLS labels. Houve muitos relatos de estouro da capacidade destas TCAMs em operadoras que utilizam largamente equipamentos de classe mais obsoleta. Em adição, quanto ao plano de controle, sendo que esta área sistêmica e funcional do equipamento em sua maior parte fica hospedada em um módulo de controle e supervisão centralizado (ex: RP, RSP, Supervisor), nos equipamentos legados são notórias as restrições ou limitações com relação à capacidade de processamento e quantidade de memória RAM disponíveis para acomodar processos adicionais de software para o uso simultâneo das pilhas de protocolos IPv4 e IPv6, além das estruturas de dados mantidas pelos diversos protocolos de roteamento destas duas famílias. Para exemplificar estes casos do plano de controle, o OSPFv2 para IPv4, além de outras fontes de informação - protocolos adicionais, rotas estáticas, etc. - OSPFv3 para o IPv6, além de rotas de outros protocolos interiores e rotas estáticas, e sem contar ainda com o BGP para ambas as famílias de endereço IPv4 e IPv6 Unicast, além do MPLS, etc. Então um dos motivadores ou argumentos para a adoção do 6PE está na capacidade de processamento do equipamento, assim como a sua habilidade de manter em componentes especializados tabelas IPv4 e IPv6 grandes.

Outra justificativa ou argumento é o prazo necessário para que grandes operadores pudessem implementar o IPv6. Num local ISP (provedor de pequeno e médio porte) isto pode ser concebido muito mais fácil e rapidamente. No entanto, em operadores bem maiores, com centenas de roteadores no backbone, além da borda de serviços, redes de acesso, etc., a adoção do IPv6 exigiu, e de certa forma obviamente ainda exige, extensos testes para a validação de capacidades, convergência, segurança, gerenciamento, automação, etc., algo que por anos não pode ser feito do dia para a noite. Por anos o 6PE foi um ótimo viabilizador do IPv6 em infraestruturas com restrições quanto à adoção do IPv6 no backbone, sejam por motivos de restrições ou limitações de equipamentos, ou por questões mais processuais tais como a conclusão do projeto técnico, validações, homologações e afins.

Quando usar o 6PE?

Em qualquer cenário ou situação onde há impeditivos para a adoção "suave" do IPv6, tais como os exemplos supracitados. Nestes casos, o 6PE pode muito rapidamente viabilizar o transporte simultâneo de IPv4 e IPv6 para clientes, peering e trânsito, sem que sejam exigidas quaisquer modificações nos roteadores puramente de "Core" (os chamados "P-routers").

Quando não usar o 6PE?

Se o aparato tecnológico do seu provedor for compatível com as especificações de um projeto técnico moderno, sofisticado, eficiente e bem aderente na questão de boas práticas e afins, então a melhor abordagem seria o projeto e implantação absolutos do IPv6 em regime de pilha dupla na rede de seu provedor.

Sobre o 6PE

O IPv6 Provider Edge over MPLS (6PE) é uma solução que viabiliza uma o IPv6 com configuração apenas nas interfaces "customer-facing" dos equipamentos Provider Edge (PE). Ou seja, as interfaces que conectam aos clientes corporativos ou residenciais, ou qualquer interface com conexão externa, podem e tipicamente são configuradas para suportar ambas as famílias de endereços IPv4 Unicast e IPv6 Unicast. No entanto, como propósito da solução, as interfaces internas do provedor (chamadas de "core-facing") não são habilitadas para o IPv6 e, portanto, não possuem qualquer configuração de endereços IPv6 e protocolos de roteamento interiores necessários para transportar prefixos IPv6 internos, os quais, novamente, sequer existem.

O 6PE é viabilizado por dois componentes fundamentais: a habilitação da família de endereços IPv6 Unicast para as sessões Internal BGP (IBGP) estabelecidas sobre IPv4 Unicast, juntamente com troca de labels sobre os prefixos IPv6 negociados através destas IBGP. Em adição, o MPLS label switching é mandatório para que os roteadores de Core (P-routers) possam encaminhar os pacotes de trânsito de/para os roteadores PE, mesmo que os roteadores P estejam rodando o BGP.

Não há uma relação direta entre 6PE e BGP-Free Core; uma solução não depende da outra para funcionar. No entanto, o BGP-Free Core pode ajudar substancialmente na redução da complexidade do projeto técnico relacionado ao BGP, além de permitir o emprego de equipamentos de Core de missão mais específica e não necessariamente escaláveis para full routes, ou seja, mais atraentes no ponto de vista financeiro. O 6PE em regime BGP-Free Core está demonstrado na ilustração a seguir:

Contextualização da solução 6PE em um ambiente de Core isento de BGP (BGP-Free Core)

Sobre o 6VPE

O 6VPE é outra solução para viabilizarmos a pilha dupla de clientes sobre um backbone IPv4 só que, neste caso, sendo uma solução especificamente projetada para acomodar cenários de L3VPN por MPLS para clientes com a família de endereços IPv6 Unicast. Basicamente corresponde à ativação da família de endereços VPNv6 no roteadores Provider Edge (PE) cujas as sessões internas IBGP são estabelecidas somente por IPv4 Unicast. Ou seja, resumindo, o 6VPE é o 6PE para aplicações de L3VPN por MPLS em clientes com IPv6 na relação PE-CE, e o transporte de prefixos através de sessões IBGP por IPv4 e, consequentemente, com o tráfego sendo roteado com recursivo por IPv4 e com suporte de label switching.

Quais são as ações e componentes dos roteadores 6PE?

Os roteadores 6PE são essencialmente os Provider Edge (PE) apenas, e não incluem os roteadores puramente de "Core" (P-routers). Os roteadores 6PE, nome que damos aos roteadores PE rodando essa solução, possuem os seguintes componentes e realizam os seguintes serviços:

• Participam do protocolo de roteamento IGP para IPv4 no backbone, incluindo as suas respectivas interfaces Loopback e apenas as interfaces "core-facing";
  • Isto fomenta a conectividade IPv4 entre todos os destinos internos do provedor, em especial as interfaces Loopback com os endereços IPv4 /32;
  • Isto viabiliza o transporte das sessões IBGP (por IPv4) entre os roteadores 6PE;
  • Isto viabiliza, caso a configuração destas sessões IBGP entre os roteadores 6PE contemple a modificação do atributo NEXT_HOP dos prefixos recebidos de clientes, o roteamento recursivo com interesse a estes endereços /32 das interfaces Loopback dos 6PE;
  • Isto viabiliza o estabelecimento das sessões pelo protocolo Label Distribution Protocol (LDP), necessário para a parte do MPLS label switching no backbone do provedor;
    • Consequentemente, haverá a devida troca de labels sobre os prefixos IPv4 internos, em especial os host routes representando os endereços /32 das interfaces Loopback dos roteadores 6PE.
• Rodam o protocolo BGP em regime de sessões Multiprotocol IBGP entre si, ou seja, acomodando tanto o IPv4 Unicast quanto o IPv6 Unicast.
• Trocam labels especificamente por estas sessões MP-IBGP para os prefixos IPv6 recebidos de clientes, ou quando redistribuindo rotas de outros IGP ou rotas estáticas IPv6 de clientes para o BGP. A solução 6PE exige este conceito de troca de per-prefix label durante anúncios de prefixos IPv6 através destas sessões MP-IBGP estabelecidas sobre IPv4 entre os roteadores 6PE;
  • A relação "PE-CE" (a última milha...), na questão do IPv6, pode ser concebida por qualquer método: rotas conectadas, OSPFv3, RIPng, estáticas, BGP...

Quais são as ações e componentes dos roteadores 6VPE?

Muito parecido aqui com o caso do 6PE, até mesmo porque o 6VPE é o "6PE para serviços L3VPN MPLS com IPv6". Destacando aqui os extras:

• A distribuição de labels pelo MP-IBGP pode ser feita de duas formas:
  • Per-prefix label: o roteador 6VPE distribui labels para cada prefixo IPv6 recebido em uma VRF.
  • Per-CE/VRF label: o roteador agrega todas as rotas IPv6 recebidas em uma VRF e fornece um único label, distribuindo este label para seus vizinhos 6VPE.

O funcionamento do 6PE/6VPE

Ilustrando aqui um caso com o 6VPE. É importante salientar que por haver VRFs (tipicamente uma por cliente), os prefixos recebidos nas VRFs podem ser idênticos ou conflitantes, pois esta é uma das vantagens e características das L3VPN por MPLS.

O 6VPE ilustrado na relação PE-CE

Estes prefixos são recebidos em suas respectivas Virtual Routing and Forwarding (VRF), tipicamente uma VRF por cliente em um roteador 6VPE. Em seguida, ocorrem as seguintes interações:

1. O prefixo pode ter que passar por filtros e validações adicionais, caso haja políticas que cuidem destas necessidades (ex: filtros, policies, e outros).
2. Caso a rota IPv6 tenha sido aprendida através de um protocolo de roteamento IGP (ex: RIPng, OSPFv3, EIGRP for IPv6, ou ainda rotas estáticas), a rota precisará ser redistribuída para o BGP.
   1. Caso a rota tenha sido aprendida por EBGP, não será necessária a redistribuição.
3. A rota (seu prefixo) é convertido para um endereço VPNv6 com o auxílio do Route Distinguisher (RD), um endereço de 64 bits que é colocado na frente do endereço IPv6, tornando-o um endereço IPv6 único.
   1. Isto é o que permite a diferenciação entre prefixos conflitantes de clientes em outras VRFs, quando o roteador 6PE tiver que repassar o prefixo VPNv6 pelo backbone para outros roteadores 6VPE.
      1. O RD é configurado por VRF dos roteadores 6VPE.
4. Communities estendidas denominadas Route Target (RT) são adicionadas aos prefixos VPNv6 para denotar a participação de VPN de cada prefixo. Ou seja, para quais VRFs estas rotas deverão ser importadas nos outros roteadores 6VPE do backbone?
5. Communities estendidas denominadas Site of Origin (SoO) podem ser adicionadas, opcionalmente, para identificar sites para a troca destes prefixos com controle mais granular e preventivo quanto à routing loops.
6. Outros atributos BGP podem ser incorporados às rotas ao repasse para outros roteadores 6PE:
   1. Local Preference
   2. MED
   3. NEXT_HOP
   4. AS_PATH
   5. Standard e Extended Communities
   6. Etc.
7. Um label é trocado entre os roteadores 6VPE, à exemplo do que ocorreria numa situação 6PE (sem L3VPN MPLS). Só que, no caso específico do L3VPN com IPv6 sobre sessões MP-IBGP IPv4 (ou seja, o 6VPE), a alocação e distribuição de labels poderá ser feita por prefixo ou por VRF.
8. Uma pilha de labels é colocada sobre os pacotes em trânsito para esta VPN. O inner label é o que foi trocado por prefixo ou por VRF, conforme sinalizado pela sessão MP-IBGP, e o outer label é adicionado, constituindo este label stack, para viabilizar o encaminhamento do pacote com interesse ao roteamento recursivo sobre o atributo NEXT_HOP pelos roteadores de Core (P-routers).

Exemplificando a troca de prefixos VPNv6 entre os roteadores 6VPE por sessões MP-IBGP IPv4

Exemplificando a troca de prefixos VPNv6 entre os roteadores 6VPE por sessões MP-IBGP IPv4 (cont.)

No que tange à troca de labels sobre os prefixos IPv6 vindos dos roteadores dos clientes (CE ou CPE), através destas sessões MP-IBGP, o procedimento pode ser ilustrado da seguinte forma:

Demonstração do procedimento de troca de labels entre os roteadores 6VPE

Já o exemplo a seguir ilustra o encaminhamento de pacotes através de uma rede MPLS em um cenário 6PE típico:

Encaminhamento de pacotes em uma rede MPLS em cenário 6PE típico

Vídeos demonstrativos da solução 6PE e 6VPE

Aliás, mais do que vídeos: literalmente um mini-curso com quase quatro (04) horas de duração, divididos em duas partes/vídeos, devidamente publicados no canal do YouTube do Brasil Peering Forum!

Estes dois vídeos, mini-cursos literalmente, abordam um cenário bastante interessante das tecnologias 6PE e 6VPE em um regime BGP Free Core e com túneis de engenharia de tráfego por MPLS. Confira!

1. Vídeo Introdução ao IPv6 Provider Edge over MPLS e 6VPE sobre BGP Free Core e MPLS TE - Parte 1 (1:53h de duração)
2. Vídeo Introdução ao IPv6 Provider Edge over MPLS e 6VPE sobre BGP Free Core e MPLS TE - Parte 2 (1:38h de duração)

Espero que este artigo e os vídeos correspondentes tenham atendido às suas expectativas. Até o próximo artigo!

Autor: Leonardo Furtado