Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN

Introdução

Este artigo propõe-se a disseminar conhecimentos acerca da tecnologia Ethernet VPN (EVPN), em particular suas vantagens, benefícios e as justificavas para a sua adoção, além de fornecer comparativos acerca dos cenários de transporte de serviços L2 através de uma rede L2 nativa e também sobre as tecnologias L2VPN MPLS tradicionais (VPWS e VPLS).

Revisão sobre as Soluções Vigentes para o Transporte de Tráfego L2 na Rede do ISP

Conforme citado em outro artigo já publicado em nossa Wiki (Proteção e Resiliência em Redes L2 de Provedores), o Ethernet tornou-se a tecnologia de enlace primária dos operadores de rede em função de uma série de benefícios para o ISP, dentre os quais destaco a excelente relação custo x porta, flexibilidade de cenários, modelo econômico e alta capacidade de transmissão (com taxas já chegando ao 400 Gigabit Ethernet (400GbE), conforme o IEEE P802.3bs, e também com o Terabit Ethernet, ou 1TbE, já sendo estudado). O modelo econômico do Ethernet é um de seus principais atrativos, pois possibilita ótimos cenários envolvendo capacidades e overbooking estatístico, sendo estes seus núcleos de atratividade financeira.

Os operadores de redes e ISPs sempre tiveram a necessidade de efetivar o transporte de circuitos de Camada 2 (L2; Ethernet) através de suas infraestruturas, e isto pode ser concebido de algumas formas, sabendo que para cada uma delas há os “pros” e “contras”. Vejamos:

Transporte de Tráfego L2 Nativo na Rede do Provedor

É a modalidade mais clássica de transporte de tráfego L2, e o termo “nativo” serve justamente para reforçar esta característica. Nesta abordagem, o operador de redes constrói uma rede puramente L2 para transportar o tráfego de seus assinantes e de seus respectivos serviços, e fazendo isto considerando tecnologias clássicas tais como Virtual LAN (VLAN), entroncamento de VLANs com o IEEE 802.1q, com ou sem suporte ao Q-in-Q do IEEE 802.1ad-2005 original (incorporado ao 802.1Q-2011, e, atualmente, o 802.1Q-2018), e ainda um protocolo de resiliência para assegurar as seguintes missões: viabilizar o transporte de tráfego L2 através de uma topologia redundante isenta de loop e ao mesmo tempo em que possibilitando mecanismos de recuperação de falhas (convergência e integridade da rede L2 em cenários pós falhas). Esta abordagem apresenta vantagens e desvantagens, conforme destacado a seguir.

Infraestrutura de Transporte de Tráfego L2 Nativo
Resumo de Vantagens	Resumo de Desvantagens
Requer equipamentos menos "sofisticados", desde que (recomendado) implementem tecnologias L2 em alinhamento com o Metro Ethernet Forum (MEF)	Restrições quanto a escalabilidade devido a limitações de diâmetro dos protocolos de resiliência L2
Projeto e investimentos mais atraentes no conceito direto de CAPEX ("solução mais barata")	Custos OPEX exponencialmente maiores na medida em que a rede for crescendo devido ao paradoxo "o barato (para construir) sai caro (para manter)"
Escopo de funcionalidades tecnológicas mais simplificado e básico, exigindo menos "expertise" por parte dos profissionais do ISP; tecnologias mais simples	Menor imunidade quanto a bridging loops (mortíferos...), seja por falha na convergência do protocolo ou, principalmente, por erro humano durante uma atividade de configuração ou de suporte.

Ilustração de uma rede de acesso em L2 nativo

É muito importante lembrar que o L2 "nativo" não deve ser utilizado no backbone/core da rede, justamente pelas restrições de escalabilidade e também devido a baixa imunidade contra loops na rede. Mesmo que o seu ISP possua redes de Acesso completamente em L2, recomenda-se muito que o "Core" da rede seja construído com tecnologias baseadas na Camada 3 (L3).

A ilustração acima demonstra uma rede de Acesso de um ISP construída com switches e tecnologias L2 simples, incluindo VLAN, 802.1q, um protocolo de resiliência, que pode ser o Resilient Ethernet Protocol (REP), proprietário, Ethernet Automatic Protection Switching (EAPS), proprietário, mas um tanto disponível entre alguns vendors, ou G.8032 Ethernet Ring Protection Switching, padrão aberto. Com relação aos protocolos de resiliência para a rede L2, a única recomendação é que as variantes do protocolo Spanning Tree (802.1d, 802.1w, 802.1s) sejam evitadas neste tipo de infraestrutura, haja vista que o STP como um todo foi projetado para missão LAN, e não para ambientes Metro Ethernet.

Ainda nesta mesma ilustração, observamos dois cenários muito comuns na realidade dos ISPs, sendo um deles o transporte do tráfego de um assinante residencial até o seu roteador de borda, que por sua vez realizará o roteamento do tráfego de/para a Internet e o assinante, assim como a implementação de todo e qualquer recurso sobre os pacotes do serviço contratado por este assinante, e um produto de "L2L" (LAN-to-LAN) de redes L2 corporativas de uma determinada organização, ou ainda como cenário para extensão ou interconexão entre data centers (DCI).

No que diz respeito ao cenário de LAN-to-LAN, uma das maiores preocupações, além do transporte óbvio do tráfego L2 entre os sites do cliente corporativo, é assegurar a integridade da topologia L2, ou seja, promover a extensão dos protocolos de controle do ambiente nativo do cliente, tais como o Spanning-Tree que roda na rede LAN dos dois sites do cliente, assim como protocolos tais como LLDP, CDP, LACP, UDLD e outros. Para estas situações, o provedor/ISP geralmente implementa o tunelamento de protocolos de Camada 2 por meios da tecnologia Layer 2 Protocol Tunneling (L2PT). Este processo é também conhecido pelo termo Generic Bridge PDU Tunneling (GBPT). O L2PT/GBPT poderá ser coberto com detalhes um dia em um artigo aqui na Wiki do BPF...

OBS: não confunda L2PT com L2TP (refresh de L2F e PPTP)!

Por que Migrar uma Rede de Acesso L2 Nativa para o MPLS?

Isto vai de acordo com os conceitos e entendimentos de cada engenheiro de redes, pois cada profissional deverá saber o que é melhor para a sua infraestrutura. Se você consultar a minha opinião direta, a tendência é que eu vá relacionar alguns sólidos argumentos aqui, citados discretamente na primeira tabela logo acima. O maior argumento tem relação com o indicador de Disponibilidade do ISP. Um ambiente L2 "puro" obriga o operador a efetuar configurações em todos os elementos de rede L2 ativos que estiverem no caminho do tráfego a ser transportado, o que, por si só, já tipifica um esforço bem maior para provisionar, configurar, suportar, manter e documentar os assinantes e seus respectivos serviços contratados. Na medida em que a rede cresce, os esforços operacionais associados as ações supracitadas tendem a aumentar consideravelmente. Basta apenas um erro durante uma configuração e numa única VLAN para colocar todo o ambiente em cheque-mate! Um único erro de configuração e/ou provisionamento poderá impactar severamente todos os clientes conectados nestes switches, desde muita lentidão até o completo downtime! Assim como uma possível falha na convergência do protocolo de resiliência L2, ou seja, desastroso! Outro bom argumento envolve a flexibilidade de cenários para o transporte de serviços Ethernet em combinação ou não com serviços IP, algo mais tangível e interessante nas arquiteturas baseadas no MPLS. Meus "2 cents" aqui.

Sem querer radicalizar, você pode optar por manter redes de acesso em L2 desde que observando bem o diâmetro do projeto neste perímetro de Acesso, e desde que o seu ISP possua bons controles de configurações, documentação e uma ótima gestão de mudanças. O investimento em switches de acesso é notoriamente mais em conta que investimentos em roteadores de acesso, portanto o CAPEX é mais favorável, sim. No entanto, sugiro fatorar bem a questão operacional e toda e qualquer situação que vá afetar adversamente os custos estritamente operacionais (OPEX), além de considerar e revalidar os indicadores de capacidades referentes aos recursos, protocolos e serviços que deverão ser suportados pelos equipamentos na planta. Vale a pena ter um CAPEX menor inicialmente, mas incorrer num OPEX bem maior em médio ou longo prazo? Novamente, "meus 2 cents" aqui.

Transporte de Tráfego L2 sobre a Rede MPLS do Provedor

A solução para isto possui um nome: Layer 2 Virtual Private Network over MPLS (L2VPN MPLS). Longe de dissertar novamente sobre o MPLS aqui neste artigo, pois este tema já foi tratado por uma publicação em nossa Wiki (confira o artigo Redes MPLS para Provedores para conhecer os benefícios do MPLS na rede do ISP!). Mas façamos aqui uma breve revisão dos fatos:

1. Uma rede L2 clássica não pode transportar o tráfego de uma mesma VLAN por mais de um caminho simultaneamente, ou seja, o recurso "ECMP" não está disponível para implementações L2 convencionais. Por sua vez, o ECMP é fácil e viável nas redes L3.
2. A engenharia de tráfego em redes L2 é viável e um tanto simples ou fácil de implementar, mas bem menos flexível que os cenários mais sofisticados de engenharia de tráfego para o L3, o que inviabiliza o L2 para alguns setups mais exigentes.
3. Uma rede L2 não possui a mesma escalabilidade de uma rede L3. A diferença chega a ser absurda no KPI "escalabilidade" entre L2 e L3.
4. Protocolos de roteamento (L3) são mais escaláveis e confiáveis do que qualquer protocolo de resiliência L2.
5. Embora a convergência de alguns protocolos de resiliência L2 possa ser bem rápida (casos aqui com o REP/EAPS/G.8032/MST), a convergência dos protocolos IGP (L3) é indiscutivelmente mais confiável, além de rápida, especialmente em redes grandes. O fator "disponibilidade" é frequentemente maior em ambientes L3 grandes, se comparados aos mesmos ambientes quando definidos em L2.

Isto explica as diferenças entre redes L2 e L3 na rede do provedor.

Todavia, estamos discutindo aqui sobre soluções de transporte de tráfego L2, certo? Se o provedor optar por um projeto de infraestrutura com uma rede completamente IP/MPLS, ele terá que encontrar uma forma de transportar circuitos/serviços Ethernet sobre esta rede IP/MPLS. Vejamos algumas das possibilidades para este caso:

Tecnologias de Transporte de Tráfego L2 sobre uma Rede IP ou Rede MPLS

• Layer 2 Tunneling Protocol (L2TP): atendendo exclusivamente conectividade ponto-a-ponto sobre a rede IP. Não será abordado neste artigo.
• Virtual Extensible LAN (VxLAN): setup indicado para soluções avançadas de extensão de data centers, podendo ser sobre uma rede IP pura, ou ainda um Data Center Interconnect com EVPN-VXLAN através da WAN baseada em EVPN-MPLS. Isto será tema para futuro artigo na Wiki do BPF.
• Overlay Transport Virtualization (OTV) ou soluções proprietárias similares de outros vendors: solução proprietária para a extensão de data centers.
• Layer 2 Virtual Private Network over MPLS (L2VPN): as clássicas tecnologias de L2VPN baseadas no MPLS, os consagrados/conhecidos "VPWS" (ponto-a-ponto) e "VPLS" (multiponto). O foco deste artigo está justamente na transição do L2VPM MPLS para o Ethernet VPN (EVPN).

Cada uma das possibilidades apresentadas acima possui seus "pros" e "contras".

Novamente, este artigo é baseado na transição do L2VPN MPLS (VPWS e VPLS) para o EVPN, pois esta necessidade representa mais fielmente os cenários implementados pelos ISPs para o transporte do tráfego L2 dos assinantes sobre uma rede MPLS, enquanto o VXLAN, por sua vez, é frequentemente mais orientado ou relacionado a cenários de conectividade envolvendo extensões de data center sobre uma rede IP ou MPLS.

Sobre o L2VPN MPLS

As tecnologias L2VPN MPLS tradicionais estão bastante difundidas no universo dos provedores de acesso à Internet (ISPs), pois muitos destes provedores já contam com o MPLS em suas redes e inclusive muitos destes ISPs estenderam o MPLS até o perímetro de Acesso, ou seja, eliminando por completo ou em grande parte as infraestruturas L2 existentes de seus ambientes. Um dos maiores argumentos e motivadores quanto a adoção do L2VPN sobre uma rede MPLS estendida para o perímetro de Acesso é a quantidade de elementos envolvidos durante uma atividade de configuração ou provisionamento de assinantes e serviços, além das capacidades de convergência e confiabilidade do IGP, engenharia de tráfego, ECMP, etc.

Permita-me explicar melhor.

Projetos de infraestruturas IP/MPLS tendem a ser bastante imutáveis nos elementos "core-facing", ou seja, os roteadores ou switches MPLS e seus respectivos uplinks sofrem configurações literalmente uma única vez, que é durante a implantação e ativação do equipamento na planta. Muito raramente são exigidas intervenções posteriores na configuração do protocolo de roteamento interior (ex: OSPF) ou no protocolo de alocação e distribuição de labels (LDP) ou ainda no protocolo RSVP-TE (para o MPLS TE), exceto quando realizando upgrades nos equipamentos ou links ou quando realizando expansões na infraestrutura.

Em outras palavras, nós projetamos os ambientes, identificamos as facilidades exigidas e em suas respectivas categorias funcionais, e estes dispositivos sofrem configurações destes recursos primários praticamente uma única vez, como é o caso do IGP (OSPF), MPLS (LDP), MPLS TE (RSVP-TE e modificações no IGP), QoS, gerenciamento, segurança e outros. Muito raramente são exigidas modificações nestas configurações após o equipamento ter sido ativado na planta. Uma vez a rede completamente pronta e funcional, as ações de configurações para a ativação de novos clientes passam a ser muito específicas e envolvem (poucos) elementos de rede igualmente específicos.

Para exemplificar, quando necessitando ativar/provisionar um novo cliente ou serviço na rede, o ISP precisa "tocar" em apenas poucos elementos da infraestrutura, conforme mostrado a seguir:

Pontos operacionais de intervenção humana em uma ativação de L2VPN MPLS ponto-a-ponto: um benefício do L2VPN MPLS

Na ilustração acima, para ativar uma LAN-2-LAN entre dois sites de um assinante corporativo, o ISP precisará acessar e configurar este serviço em apenas dois equipamentos, os quais estão destacados.

Agora analisemos a mesma topologia apresentada no início deste artigo, porém já portada para o cenário de MPLS estendido para o perímetro de Acesso. Note que no referido anel Metro Ethernet não há mais a presença de entroncamentos de VLANs por 802.1q, ou seja, todos os uplinks (interfaces "core-facing" dos equipamento) sendo estritamente em L3, com os devidos endereços IP, além das configurações necessárias de IGP (OSPF), MPLS label switching (LDP) e potencialmente também o RSVP-TE (para MPLS TE), caso a engenharia de tráfego por MPLS seja desejada para esta área. Estas são as configurações "imutáveis" as quais eu me referia.

Nesta mesma topologia temos aqueles mesmos dois casos de estudos: um assinante residencial com produto de Internet configurado, no canto direito superior do anel Metro Ethernet, e a extensão de LAN entre dois sites de um cliente corporativo ou a interconexão entre data centers, o que você preferir simular aqui, logo abaixo.

Onde seriam exigidas configurações para o provisionamento de serviços destes dois casos? Apenas nos equipamentos estritamente necessários para a viabilidade dos produtos contratados! Para o assinante residencial, uma configuração seria exigida apenas no switch que conecta a última milha do assinante e no roteador de borda que efetivamente fornecerá os serviços L3 para o roteamento do tráfego de/para o assinante e a Internet. Já no caso do assinante corporativo demonstrado, apenas nos dois switches que conectam os dois sites, respectivamente. Os demais equipamentos mostrados na topologia não precisarão receber quaisquer configurações para acomodar estes dois novos clientes, sendo esta condição um dos maiores atrativos da solução L2VPN MPLS!

Ilustração de uma rede de acesso em L3/MPLS

Instrução Adicional (extra!): Como conceber Projetos MPLS mais Flexíveis para ambos os Serviços L2 e L3

Uma pausa rápida aqui para comentar uma característica que, sem sombra de dúvidas, compreendo como sendo de alto valor para os projetos MPLS na rede do ISP. Na rede Metro do ISP dois tipos de plataformas podem ser empregados: switches ou roteadores.

Embora em ambas as abordagens seja plenamente viável a adoção dos serviços L2 e L3 através da rede MPLS, há uma diferença especial entre os dois casos. No que diz respeito a definição de VLANs, um switch normalmente precisa sofrer uma configuração "global" para cada VLAN desejada, e as respectivas portas de Acesso "Customer-facing" (em modo "access" ou "trunk") precisam ser associadas para a VLAN de acordo. Nesta arquitetura de switches, a VLAN é "conhecida" (definida) globalmente e, na sequência, fazemos as associações correspondentes de acesso e trunk sobre as portas necessárias. Em adição, cada VLAN possui o seu próprio domínio de broadcast, e cada domínio de broadcast poderá estar associado a apenas uma única VLAN. Isto significa que tráfego entre duas VLANs distintas naquele equipamento ou na rede precisará ser roteado, haja vista que no L2 não é possível interconectar duas VLANs sem o auxílio de um equipamento L3 (ou de roteamento), mesmo que os usuários nestas VLANs estejam posicionados na mesma subrede IP. Exatamente conforme funciona numa rede LAN, então nenhuma novidade aqui.

Acontece que este tipo de arquitetura normalmente restringe operações mais sofisticadas nos tags de VLAN, tais como a reescrita ou mutação dos valores referente aos IDs de VLAN, além de tornar os cenários de classificação do tráfego mais engessados ou rígidos.

Por outro lado, roteadores de missão específica "carrier grade" (assim como potencialmente alguns switches desta classe) já suportam uma classificação e mapeamento bem mais flexíveis dos tags de VLAN. Uma abordagem que me agrada muito é o emprego de equipamentos roteadores onde a VLAN não possui significância global, sendo definida apenas a título de classificação na porta. Ou seja, não há de fato "uma VLAN" no equipamento, e sim a expectativa de recebimento de quadros Ethernet com marcações de VLAN específicas sobre as interfaces. Qual é a vantagem disso? Flexibilidade! Muita flexibilidade! Neste tipo de abordagem é possível mapear VLANs distintas para o mesmo serviço L2 multiponto, por exemplo, tanto para conexões locais (no equipamento) quanto para transporte de L2 sobre a rede MPLS (VPLS), ou ambos simultaneamente! Ou ainda a combinação de transporte L2 local + MPLS PW (VPLS) e roteamento (L3) para o mesmo serviço Ethernet, em algo que chamamos normalmente de Roteamento e Comutação Integrados (do inglês "Integrated Routing & Bridging" (IRB)).

A diferença aqui é clara: mais flexibilidade e possibilidades de construção de cenários outrora muito difíceis, quase que impossíveis, nas implementações com switches tradicionais, mesmo aqueles com suporte ao MPLS.

Consulte a ilustração a seguir para compreender as diferenças entre as duas abordagens:

Comparativo entre as abordagens de classificação de VLANs com switches e roteadores em uma rede Metro

Cenários de L2VPN MPLS: Ponto-a-Ponto e Ponto-Multiponto

Como é de conhecimento de muitos dos ISPs que acompanham a Wiki do Brasil Peering Forum, há dois tipos de setups envolvendo as tecnologias L2VPN MPLS: ponto-a-ponto e multiponto. As principais diferenças entre os dois setups:

• Virtual Private Wire Service (VPWS): um serviço estritamente "ponto-a-ponto". Normalmente conectamos uma VLAN para um destino de pseudowire (o endereço IP de uma interface Loopback de um switch ou roteador remoto através da rede MPLS) e, no equipamento remoto, a configuração no sentido inverso. Não há aprendizado de endereços MAC assim como as decisões de encaminhamento de quadros com base nestes endereços físicos são inexistentes, justamente por ser um serviço ponto-a-ponto.

• Virtual Private LAN Service (VPLS): um serviço de natureza multiponto, podendo ser multiponto, ponto-multiponto (ex: hub and spoke), ou ainda L2+L3 integrados (IRB), algo também conhecido pelo termo de Routed Pseudowire (Routed PW). A principal diferença entre o VPLS e o VPWS, além da natureza multiponto e o suporte ao IRB, está na questão da tabela MAC que é mantida dentro da bridge domain associada ao serviço VPLS. Ou seja, há a manutenção desta tabela MAC (aprendizado dos endereços MAC oriundos tanto das interfaces L2 participantes quanto dos neighbors de PW) e decisões de encaminhamento de quadros são feitas com base nestes endereços físicos.

Para ambas os casos do VPWS e VPLS há dois modelos de implementação: Martini e Kompella.

Há diferenças bem razoáveis entre os dois modelos e isto está fora do escopo do artigo (do contrário teremos um livro até o final do artigo!), mas dá para resumir o principal ou o óbvio:

1) Na implementação Martini, o protocolo LDP é utilizado para sinalizar o label da (L2) VPN entre os roteadores participantes daquele serviço Ethernet. Requer uma configuração explícita para uma sessão direta entre os dois roteadores para o serviço L2VPN desejado, algo chamado de T-LDP (Targeted Label Distribution Label), ou seja, sem um mecanismo de descoberta automática destes roteadores. O drat Martini foi inicialmente padronizado pelo RFC 4906 (Transport of Layer 2 Frames Over MPLS), e, ultimamente, pelo RFC 4762 (Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling).

2) Na implementação Kompella, o protocolo BGP é utilizado tanto para a descoberta automática de vizinhos quanto para o fornecimento do label referente ao serviço (L2) VPN desejado entre os dois ou mais roteadores participantes. Atualmente descrito pelo RFC 4761 (Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling).

Na prática, o Martini é mais simples e fácil de configurar/provisionar, mas o Kompella é mais atraente principalmente em redes grandes ou bem grandes, isto é, bem mais escalável na questão dos pseudowires (algo que queremos eliminar com a chegada do EVPN!). Em termos de encapsulamento, ambos são absolutamente idênticos.

A ilustração a seguir basicamente reúne os cenários VPWS e VPLS e suas possibilidades:

Possibilidades de serviços L2VPN ponto a ponto e multiponto

Outros casos e funcionalidades envolvendo L2VPN

Para serviços ponto a ponto há o consagrado caso do conjunto Any Transport over MPLS (AToM), que inclui opções tais como o Ethernet over MPLS (EoMPLS, o que seria a mesma coisa que VPWS), Frame Relay over MPLS (FRoMPLS), PPP over MPLS (PPPoMPLS), HDLC over MPLS (HDLCoMPLS), etc. Estes estarão definitivamente fora do escopo deste artigo.

Para concluir aqui o L2VPN MPLS e partirmos para o EVPN, informo que há recursos e soluções complementares que viabilizam outras possibilidades e/ou que minimizam os impactos de escalabilidade das implementações tradicionais, tais como Pseudowire Redundancy (backup PW), Pseudowire Headheand (PW-HE), Pseudowire Stitching ou recurso similar com outro nome, projetos com VPLS hierárquico (H-VPLS), mecanismos de prevenção de loop do VPLS tais como Split Horizon Groups, dentre outros recursos e facilidades. Estes temas não serão discutidos neste artigo. No que diz respeito aos mecanismos de balanceamento de tráfego em redes MPLS com ênfase no L2VPN, recomendo a leitura de outro artigo já publicado em nossa Wiki: Balanceamento de Tráfego em Redes MPLS.

Transição dos Serviços L2VPN MPLS para o Ethernet VPN (EVPN)

O EVPN descrito em sua forma mais prática e objetiva possível: o Ethernet Virtual Private Network (EVPN) tem como principal proposta a introdução de um novo modelo para o fornecimento de serviços Ethernet para os operadores de redes. O EVPN é equipado com funcionalidades que maximizam a simplicidade e agilidade operacionais, assim como os indicadores de escalabilidade da infraestrutura. Basicamente o EVPN acomoda muitas das funções disponíveis nas implementações L2VPN tradicionais ou legadas, só que normalmente executando melhor estas funções. Se realizarmos um comparativo de recurso por recurso, perceberemos facilmente que o EVPN é uma solução bastante aderente e que oferece plenas condições de substituir os transportes de serviços Ethernet vigentes nos ISPs!

Dentre as diversas características e funcionalidades que o EVPN reúne, podemos destacar a viabilidade de construção de cenários multiponto e ponto a ponto incluindo E-LAN, E-Line, E-TREE, L3VPN, DCI, DC-Overlay, IRB e outros, que até então eram ofertados por um mix de tecnologias distintas ou bastante dissimilares, de complexa integração e com várias restrições, tais como o VPWS, VPLS, L3VPN, SPB/TRILL, etc. Uma das principais propostas do EVPN é a simplificação devido ao seu potencial de atuar como uma solução de unificação do plano de controle da infraestrutura, pois, até então, dependíamos de um mix de tecnologias distintas para os procedimentos de encapsulamento no plano de dados (MPLS, VxLAN, NvGRE, etc.) através de ambientes dissimilares que necessitavam ser interconectados (enterprise <--> service provider <--> data center).

Áreas Funcionais onde o EVPN é Superior aos Modelos Tradicionais de L2VPN

Sintetizemos aqui as principais diferenças e vantagens do Ethernet VPN (EVPN):

Para os Serviços E-LAN

Sabemos que o VPLS tem sido a opção de escolha aqui para o fornecimento de serviços Ethernet multiponto. É uma das soluções mais usadas pelos ISPs que necessitam transportar serviços L2 através da rede MPLS. No entanto, ao substituirmos as implementações VPLS pelo EVPN, podemos elevar substancialmente a sofisticação e a atratividade destes serviços, e com ganhos em diversas áreas. Alguns exemplos:

O EVPN possibilita cenários multi-homing "All-Active". Até então dependíamos de soluções proprietárias para a construção de LAG (agregação de portas) multi-chassis e para cenários dual-homing apenas, que, além de complexas no ponto de vista de configuração, exigiam links físicos dedicados entre os equipamentos, dentre outras situações e procedimentos. O EVPN viabiliza mais do que o dual-homing: cenários triple-homing e quad-homing são suportados e com a utilização simultânea de todos os links e sem exigir implementações proprietárias, ou enlaces dedicados para conexões inter-chassis, dentre outras restrições dos setups VPLS. O EVPN assegura prevenção de loop para todo o contexto de redundância All-Active e Single-Active.

O EVPN possui também uma habilidade de detecção do tipo de dispositivo de acesso conectado à rede e por qual modalidade (ex: LACP, MSTP, REP, G.8032, etc.) além de fazer a descoberta automática de outros equipamentos PE presentes na mesma rede de Acesso. Em seguida, o EVPN executa a eleição do chamado Designated Forwarder (DF) para orquestrar e compatibilizar estes procedimentos. Vide os RFC 7432, RFC 7623 e o draft-ietf-bess-evpn-overlay-07.txt para maiores informações acerca destes procedimentos.

Para os Setups de Overlay Layer2/Layer3 em Data Centers

O EVPN não somente executa o trabalho dos ambientes 802.1q, 802.1ad e TRILL, mas consegue também fornecer uma utilização bem mais eficiente da banda bi-seccional através do fabric do data center com ótimos recursos de load balancing por fluxo para todos os dispositivos PE multi-homing, conforme mecanismo "Aliasing" suportado. A convergência em casos de falhas é tida como bastante rápida também.

Fornece ótima funcionalidade de gateway Anycast distribuído.

Excepcional para interconexão de data centers com foco em posicionamento e mobilidade flexíveis de workloads. Redundância ativa/ativa por fluxos para servidores dual-attached através de um MC-LAG. Oferece suporte a ambos fabric IP e MPLS. Vide RFC 7432, draft-ietf-bess-evpn-overlay-07.txt, draft-ietf-bess-evpn-inter-subnet-forwarding.txt e draft-ietf-bess-evpn-prefix-advertisements.txt.

Para os Serviços E-Line

O EVPN consegue fazer tudo aquilo que o VPWS tradicional faz, seja Martini (T-LDP) ou Kompella (BGP), mas ainda assim consegue fornecer funcionalidades adicionais tais como o suporte a túneis segmentados através de múltiplos domínios, suporte a serviços ponto a ponto entre um par de equipamentos CE/CPE que estiverem multi-homed com roteadores PE, e operando todo este regime em modo All-Active. Só para se ter uma noção, isto é absolutamente impossível no VPWS. Em adição, descoberta automática e sinalização providos por um único protocolo (BGP) e sem o conceito de pseudowires. Para os serviços E-Line com o EVPN-VPWS, novas facilidades tais como o Flexible Cross Connect são suportadas. Vide draft-ietf-bess-evpn-vpws-09.txt e draft-sajassi-bess-evpn-vpws-fxc-01.txt.

Para os Serviços E-TREE

Comparativamente ao VPLS, o EVPN fornece serviços E-TREE com diversas funcionalidades adicionais. Alguns exemplos incluem o filtro mais eficiente do tráfego (tráfego de um leaf com destino a outro leaf é descartado imediatamente no PE de entrada) e suporte mais flexível de conectividade de sites leaf/root onde a designação seja por circuito L2 ou por endereço MAC. Vide draft-ietf-bess-evpn-etree-09.txt.

Para os Serviços L3VPN em Combinação com Serviços L2

O EVPN pode complementar muito bem as soluções VPN IP existentes com algumas funcionalidades adicionais, dentre as quais destacam-se o multi-homing para um roteador CE/CPE enquanto uma única sessão IP é mantida com este equipamento, além da detecção rápida de falhas com temporizador reduzido de failover, ou seja, alta resiliência. Vide draft-sajassi-bess-evpn-l3vpn-multihoming-01.txt.

Os "Sabores" de EVPN

O EVPN é bastante sofisticado no que diz respeito aos cenários e combinações de serviços L2 e L3. A ilustração a seguir demonstra os principais cenários e possibilidades:

Cenários e possibilidades com o EVPN para serviços L2 e L2+L3

A ilustração a seguir mostra algumas das possibilidades destes cenários relacionados ao EVPN:

Alguns cenários relacionados ao EVPN

Quais Problemas Conhecidos do L2VPN MPLS o EVPN Resolve?

Para o VPWS, o maior benefício - principalmente nas implementações Martini/T-LDP, que são menos escaláveis e mais problemáticas em redes bem grandes - é a eliminação dos pseudowires (PW). Isto porque o serviço L2VPN ponto a ponto é relativamente bem simples nas questões envolvendo o encaminhamento do tráfego L2, já que não há aprendizado de endereços MAC, não há uma tabela MAC propriamente dita, e o encaminhamento dos quadros despreza a consulta dos endereços MAC de destino citados nestes quadros.

O VPLS por sua vez apresenta diversos desafios que são muito bem saneados pelo EVPN! Vejamos alguns casos aqui:

• Soluções VPLS não oferecem redundância com encaminhamento de tráfego "All-Active", o que "engessa" os projetos com clientes dual-homed que necessitam de muita redundância com o operador de redes.
• Looping de tráfego inundado a partir do roteador PE.
• Duplicidade de frames registrados em cenários com clientes dual-homed.
• Flip-Flopping de endereços MAC sobre os pseudowires, pois o balanceamento de tráfego sobre portchannel não produz valores de hash consistentes para quadros com o mesmo endereço MAC de origem em ambientes onde o hashing precisa ser feito com base em instruções L2.
• Requer pseudowires!
• No VPLS, o aprendizado dos endereços MAC ocorre no plano de dados. Já no EVPN, o aprendizado e a distribuição dos endereços MAC ocorre no plano de controle e através do BGP! Mais escalável, flexível e menos oneroso. Um avanço aqui em diversos aspectos e com saneamento de dificuldades conhecidas pelas implementações VPLS tradicionais.

Direções "Futuras" referentes a Serviços MPLS no ISP

Indo um pouco além aqui do proposto pelo artigo e juntando algumas peças do MPLS. Os ISPs em breve convergirão para duas direções possíveis:

1. Migração dos serviços Ethernet de L2VPN MPLS para o Ethernet VPN (EVPN), e isto ocorrendo sobre uma infraestrutura baseada no MPLS clássico, incluindo LDP e RSVP-TE (com atenção especial ao draft-sitaraman-mpls-rsvp-shared-labels-00.txt); ou ...
2. Migração dos serviços Ethernet de L2VPN MPLS para o Ethernet VPN (EVPN) sobre um regime de interoperabilidade e transição do MPLS label switching tradicional (LDP+RSVP-TE) para o Segment Routing/SRv6, incluindo toda a máquina de novas possibilidades aqui (Segment Routing (SR) Topology-Independent Loop-Free Alternate (TI-LFA), Segment Routing Traffic Engineering (SR-TE) + SR Policy + WECMP/UCMP + Traffic Steering + Multi-domain On-Demand SR Policy (ODN) + computação centralizada de caminhos (SR-PCE e soluções compatíveis com isto) + BGP-Link State (BGP-LS) + BGP-TE)

Por que eu particularmente vejo isso dessa forma? Porque eu entendo que são tecnologias/situações que se complementam muito bem! Um overview destas possibilidades aqui:

Segment Routing (SR)

• Tem como proposta/objetivo implementar o label switching (MPLS) sem depender de protocolo específico para a distribuição de labels, ou seja, sem necessitar do Label Distribution Protocol (LDP). Tudo feito pelo IGP (OSPF ou IS-IS).
• Mais escalável, mais flexível e menos oneroso no ponto de vista do plano de controle, já que conseguimos eliminar dois protocolos da rede aqui (LDP e RSVP-TE).

Topology-Independent Loop-Free Alternate (TI-LFA)

• Tem com proposta/objetivo a implementação de engenharia de tráfego + rápida recuperação contra falhas de enlaces/links e roteadores, porém sem exigir protocolos adicionais, ou seja, sem necessitar do Resource Reservation Protocol (RSVP) for Traffic Engineering (RSVP-TE). Tudo feito pelo IGP (OSPF ou IS-IS).
• Tem a proposta de ser mais escalável, sofisticado e flexível e não exige também a criação de interfaces Tunnel para o TE. É menos oneroso e propõe-se ainda ser menos complexo do que as implementações de MPLS TE + FRR tradicionais.
  • OBS: há divergências aqui quanto ao SR-TE ser melhor que as situações citadas pelo (draft-sitaraman-mpls-rsvp-shared-labels-00.txt). Alguns profissionais muito feras do mercado (Tiago Setti é um deles) compartilham desta filosofia.

Ethernet VPN (EVPN)

• Tem como proposta/objetivo a implementação de uma diversidade muito ampla de serviços L2 sobre infraestruturas baseadas no IP/MPLS. Comparado às soluções L2VPN MPLS clássicas tais como o VPLS/H-VPLS e VPWS, o EVPN permite cenários tais como EVPN-VPWS, EVPN PBB-EVPN, EVPN IRB, EVPN VxLAN, etc., em regimes ponto-a-ponto e multiponto, sendo ideal para atendermos às demandas por L2VPN dos dias atuais e com maior flexibilidade e elasticidade.
• Resolve diversos dos desafios encontrados nas soluções L2VPN MPLS clássicas, os quais foram discutidos aqui neste artigo.
• O EVPN não exige um protocolo adicional como ocorre no L2VPN MPLS clássico (em especial a implementação Martini).
• O EVPN também não exige o emprego de Pseudowires (exato, sem PWs!). O EVPN usa o MP-BGP (mais precisamente o AFI 25 e SAFI 70) para trocar rotas específicas tais como o "Route Type 1: Ethernet Auto-Discovery", "Route Type 2: MAC Advertisement", "Route Type 3: Inclusive Multicast" e "Route Type 4: Ethernet Segment". Havendo ainda os tipos 5 a 11 já pré-definidos.
• Maior eficiência no aprendizado e distribuição de endereços MAC. Ao contrário do VPLS, onde o endereço MAC é aprendido no plano de dados, o MP-BGP AFI 25 SAFI 70 distribui os endereços MAC como "rotas" de fato!
• Como vantagens do EVPN, temos a eliminação do conceito de pseudowires (melhor no ponto de vista de control plane, portanto), viabilidade de cenários "All Active" para os fluxos de tráfego, maior sofisticação dos cenários, eliminação da duplicidade de quadros em clientes multihomed, maior flexibilidade de operação e provisionamento.
• O EVPN pode rodar sobre redes MPLS clássicas ou, melhor ainda, sobre o Segment Routing (SR). Apesar de serem coisas completamente distintas, ou seja, o EVPN poder ser transportado sobre uma rede MPLS padrão ou já sobre o Segment Routing, a junção das duas propostas tende a simplificar brutalmente o plano de controle da rede e fazendo isto ao mesmo tempo em que promovendo novas possibilidades.

Considerações Finais

Os provedores de acesso à Internet (ISP) que atualmente contam com infraestruturas baseadas no MPLS, e que necessitem usar extensivamente serviços Ethernet por meios de L2VPN, poderão beneficiar-se muito substancialmente com as abordagens propostas pelo Ethernet VPN (EVPN)! Isto significa que o EVPN é uma realidade e que já pode ser considerado para os seus projetos de redes.

Apesar deste artigo ter proporcionado uma linguagem mais simples e objetiva, uma vez que eu suprimi praticamente todos os detalhes sobre como o BGP funciona para o EVPN, os tipos de rotas do EVPN, as operações que ocorrem nos planos de controle e de dados, etc., entenda que o EVPN constitui naquele tipo de tecnologia que exigirá muitos pré-requisitos por parte dos projetistas e engenheiros de redes. Isto significa que a parte teórica do EVPN é um tanto densa e há muitos conceitos, termos, nomenclaturas, funcionalidades e componentes envolvidos, e todos eles exigirão de você, profissional de redes, uma base muito, mas muito sólida mesmo.

Lidar com o EVPN exigirá amplos conhecimentos sobre redes Ethernet e IP, além de domínio absoluto das arquiteturas baseadas no MPLS e de tudo aquilo que rodar no topo disto.

Como última palavra, recomendo que você estude bastante o tema antes de adotar estes conceitos em sua infraestrutura. Considere a contratação de cursos credenciados juntos aos fabricantes para que você eleve a sua carreira para o próximo nível e que, com iniciativas desta natureza, você possa agregar valor e resultados para a sua carreira e para o seu ISP!

Vídeos Demonstrativos do Ethernet VPN (EVPN)

Tenho certeza que você conseguirá entender ainda melhor o EVPN com este vídeo. Ah! E não somente o EVPN, mas as soluções de L2VPN no geral!

• Demonstração da Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)
• Demonstração de Tecnologias L2VPN com EVPN

Imagem do vídeo demonstrativo setups EVPN-VPWS e EVPN multihoming All-Active

Não se esqueça de acompanhar e de compartilhar os trabalhos do Brasil Peering Forum (BPF). Até o próximo conteúdo!

Autor: Leonardo Furtado