Redes MPLS para Provedores

Nota sobre direitos autorais, termo de uso e isenção de responsabilidade

Consulte os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional.

Autor: Leonardo Furtado

Introdução

Este artigo visa a esclarecer os principais motivos pelos quais os provedores devem considerar arquiteturas baseadas no MPLS para as suas infraestruturas. Para mantermos a objetividade e um tamanho no máximo "razoável" do artigo, concentraremos maiores detalhamentos em um conceito ou solução específica, e resumiremos as possibilidades no final do artigo.

Por que implementar o MPLS na rede do provedor?

A tecnologia MPLS apresenta diversos benefícios para as funções de comutação e roteamento nos backbones dos provedores, dentre os quais podemos citar:

Desempenho Geral nas Funções de Encaminhamento de Pacotes

Em termos mais técnicos e no que diz respeito aos componentes de hardware e software – diga-se de passagem, roteadores e switches presentes nas redes das provedores – a adoção do MPLS para as funções de label switching historicamente tem apresentado vantagens significativas no quesito desempenho, especialmente nas plataformas mais legadas.

No que tange à principal função de um roteador, em particular nas ações de I/O específicas para processamento de pacotes, há dois procedimentos que são relativamente mais intensos: determinação de caminhos (“path determination”) e encaminhamento de pacotes (“packet switching”). É fato que a maioria do hardware legado não realiza uma legítima separação entre os planos de controle (“Control Plane”) e de dados (“Data Plane”), portanto, considerando o roteamento IP, a verificação dos endereços IP de destino contidos nos cabeçalhos IP de pacotes em trânsito se dá em muitos casos em hardware pouco especializado (em muitas vezes ocorre por interrupções de software mesmo ou, em alguns casos, por mecanismos de caching), particularmente em ambientes com equipamentos que implementam soft-routing, usando a lógica de consulta “longest prefix match” (prefixo mais específico) sobre uma estrutura de dados pouco otimizada - tal como uma tabela de roteamento padrão.

Ao localizar a interface de saída e a adjacência a ser utilizada para o encaminhamento de um pacote, um novo cabeçalho de Enlace de Dados (Camada 2) precisa ser reescrito e inserido no payload para poder compatibilizar e viabilizar a entrega deste pacote com a tecnologia de enlace associada a esta interface de saída, e esta é indiscutivelmente uma das ações mais onerosas em termos de processamento. Ou seja, o “packet rewrite”, uma das funções mais importantes, consome boa parte dos ciclos de processamento pelas funções de I/O de rede.

O MPLS label switching historicamente contribuiu para o aumento do desempenho do backbone – ou minimização do esforço de processamento de pacotes – por viabilizar o processamento de pacotes através de consultas mais simplificadas, visto que o cabeçalho utilizado pelo MPLS (conhecido por “shim header”) possui menos instruções para o roteador ter que lidar, e as ações no plano de dados são realmente bem simplistas (push de label, swap de label, pop de label), além de que todas as estruturas de dados que regem as regras de processamento de pacotes são mantidas sincronizadas e pré-computadas no Plano de Dados dos roteadores. Portanto, comparando as ações realizadas por um roteador para roteamento IP apenas, e o mesmo roteador fazendo procedimento similar, porém focado no label switching (MPLS), o referido roteador desprenderá menos esforço para concluir o mesmo objetivo, que é o encaminhamento de pacotes em trânsito, quando fazendo isto pelo MPLS. Ou seja, o MPLS é considerado mais eficiente neste aspecto, se comparado ao encaminhamento IP tradicional.

No entanto, para constar, em plataformas mais modernas, como é o caso dos roteadores Cisco, Juniper, Huawei, Brocade e outros, praticamente não haverá qualquer diferença no quesito desempenho entre roteamento IP nativo/puro e MPLS, pois todo o Plano de Dados destes tipos de equipamentos reside em hardware especializado e múltiplas ações podem ser executadas sobre os pacotes simultaneamente e com mínimo ou zero degradação de desempenho, tais como consulta de prefixos em eficientes e melhor otimizadas tabelas programadas em hardware dedicado (ex: uma FIB ou IP Forwarding Table), reescrita de pacotes praticamente em taxa de linha com instruções de adjacências já pré-computadas, também mantidas em hardware especializado; operações com ACLs, QoS, e tantos outros recursos, também implementados em nível silício, e não mais por interrupções de software.

Em suma, o label switching por MPLS não faz tanta diferença hoje em dia na questão "desempenho", considerando as tecnologias implementadas em hardware especializado dos fabricantes. Mas isto não torna o MPLS menos atraente, muito pelo contrário, pois há inúmeros cenários onde o MPLS se demonstra uma tecnologia madura e flexível.

Maximização da Eficiência e Flexibilidade do Plano de Controle do Backbone

Uma das principais vantagens com a adoção do MPLS no backbone é a simplificação da configuração dos protocolos de roteamento no backbone. Com o MPLS a rede poderá crescer quase que exponencialmente sem que sejam necessárias alterações significativas em seu projeto original, em particular o IGP da rede. Desde que, claro, o projeto técnico geral da infraestrutura seja bem montado: topologia, interconexões, alocação e distribuição do endereçamento IPv4 e IPv6, boas práticas na configuração dos protocolos e demais serviços de rede, etc.

Um cenário bem atraente viabilizado pelo MPLS é o chamado “BGP-Free Service Provider Core”. Como o próprio nome sugere, um backbone cujo “Core” é completamente isento do protocolo BGP, o que é algo muito desejável para diversos tipos de projetos em ISP.

O BGP, fundamental para os provedores, introduz muitos desafios principalmente no quesito escalabilidade, o quais, em redes maiores, suavizamos com estratégias tais como “Route Reflectors” e “Confederations”. Ao observarmos uma rede pela perspectiva do protocolo BGP apenas, em especial os ISPs de trânsito aqui, é notório nestes casos que todos os roteadores no backbone e que estiverem em linha com o tráfego dos serviços de trânsito do AS, em tese, devam possuir a tabela completa de Internet para poder realizar o encaminhamento destes pacotes dos fluxos de tráfego em trânsito.

Quais roteadores em um AS precisam efetivamente rodar o BGP?

Ilustremos o problema aqui:

Na ilustração acima, caso o BGP tivesse sido habilitado somente entre os roteadores R1 e R4 no AS 200:

O roteador do AS 100 anunciaria o prefixo 50.50.50.0/24 para o roteador R1 do AS 200, através de uma sessão EBGP entre eles, e contendo os seguintes atributos:
1. NEXT_HOP: o endereço IP de origem utilizado pelo roteador do AS 100 para a sessão EBGP com o roteador R1.
2. Origin: assumimos neste exemplo que o prefixo tenha sido gerado nativamente no BGP, e não por redistribuição.
3. AS_PATH: contendo na lista de Automous Systems o valor "100", denotando o AS que gerou este anúncio para a tabela de Internet.
O roteador R1 do AS 200 possui uma sessão IBGP apenas com o roteador R4:
1. Por configuração do administrador, realiza a modificação do atributo NEXT_HOP para si próprio (via next-hop-self) e repassa o anúncio para o roteador R4.
2. Os demais atributos são mantidos de forma inalterada, tais como os Well-Known Mandatory AS_PATH e ORIGIN.
O roteador R4 do AS 200 recebe, valida e aceita o prefixo recebido através da sessão IBGP que mantém com o roteador R1:
1. Na perspectiva do roteador R4, o atributo NEXT_HOP para este prefixo é o endereço IP da interface Loopback do roteador R1.
2. O roteador aceita e utiliza esta rota porque consegue realizar uma computação recursiva para este NEXT_HOP do BGP.
  1. Possui duas rotas IGP (por OSPF) de métricas iguais via as vizinhanças diretamente conectadas com os roteadores R3 e R2, respectivamente.
O roteador R4 do AS 200 anuncia/repassa o prefixo para o roteador do AS 300:
1. Realiza duas modificações por padrão:
  1. inclui o AS 200 na lista de Autonomous Systems associados ao prefixo.
  2. Modifica o atributo NEXT_HOP associado ao prefixo para o seu próprio endereço IP utilizado como origem para a sessão EBGP com o roteador do AS 300.

O problema em AS de trânsito sem MPLS e onde o BGP estiver rodando apenas nas bordas

O problema que este cenário provocará:

Na ilustração acima, o roteador do AS 300 possui a rota para a rede 50.50.50.0 /24, aprendida via uma sessão EBGP que mantém com o roteador R4 do AS 200.
1. Na perspectiva do roteador do AS 300, a lista de AS é "200 100", o que significa que o prefixo foi originado no AS 100 e passou pelo AS 200 (trânsito).
2. Ainda na perspectiva do roteador do AS 300, o NEXT_HOP é o endereço IP 192.168.0.5, que é o endereço IP do seu vizinho EBGP (roteador R4).
Os servidores de conteúdo localizados no AS 300 começam a encaminhar tráfego para o usuário requisitante, localizado no AS 100.
O roteador do AS 300 encaminha estes pacotes para o next hop associado à rota BGP. O recursivo é realizado com sucesso, pois o NEXT_HOP está presente em uma rede IP diretamente conectada na perspectiva do próprio roteador do AS 300 (rede IP 192.168.0.4 /30).
O roteador R4 do AS 200 recebe o pacote e, após validações óbvias de instruções L2 (CRC e endereço MAC e destino) e L3 (CRC), verifica o endereço IP de destino citado no cabeçalho IP do pacote recebido e realiza uma consulta em suas estruturas de encaminhamento de pacotes (geralmente a FIB, mas, para fins didáticos, citemos apenas "tabela de roteamento"). É o chamado procedimento "longest prefix match".
1. O roteador R4 encontra a rota mais específica em sua tabela de roteamento, a rede 50.50.50.0 /24, uma rota aprendida por uma sessão IBGP que possui com o roteador R1, que não está diretamente conectado ao próprio roteador R4.
2. O roteador R4 determina que o NEXT_HOP "10.1.1.1" é acessível via duas rotas IGP (OSPF) que são acessíveis via duas adjacências OSPF que o roteador R4 possui: 10.0.0.13 e 10.0.0.9.
3. O roteador R4 determina que estas adjacências OSPF estão em duas redes diretamente conectadas através das respectivas interfaces Ethernet 0/0 e Ethernet 0/1.
  1. Qual interface será efetivamente utilizada pelo roteador R4 para encaminhar o pacote? Como há duas rotas de métricas iguais e oriundas de um mesmo protocolo de roteamento (OSPF), o procedimento será realizado pelo Equal Cost Multipath (ECMP).
    1. Possui dúvidas sobre o ECMP e como isto é implementado? Confira este artigo na Wiki do BPF: Balanceamento de Trafego em Redes MPLS
  2. Suponhamos para todos os efeitos que o hashing ou o "uni-duni-te" tenha decidido por encaminhar o pacote através da adjacência que o R4 possui com o roteador R3, ou seja, pela interface Ethernet 0/0.
    1. O roteador R4 retirará "-1" do TTL restante no cabeçalho IP e recomputará um novo CRC para o cabeçalho IPv4.
    2. O roteador R4 escreverá um novo quadro Ethernet denotando o endereço MAC de origem (Eth0/0 do R4) endereço MAC de destino (Eth0/0 do R3), além das demais instruções que denotam o tipo de payload (ex: EtherType 0x0800 (IPv4)).
    3. O roteador R4 transmite o pacote através de sua interface Ethernet 0/0.
O roteador R3 recebe o pacote e faz as mesmas validações iniciais realizadas pelo R4, pois, entendam, o roteamento IP é realizado salto-a-salto e completamente per-hop behavior.
O roteador R3 consulta o endereço IP de destino citado no cabeçalho IPv4 do pacote recebido do R4 e faz uma consulta sobre a rota mais específica disponível em sua tabela de roteamento.
1. O roteador R3 não possui qualquer rota que satisfaça ao critério do endereço IP de destino contido no cabeçalho IP do pacote recebido.
  1. O roteador R3 descartará o pacote e encaminhará uma notificação para o remetente do pacote via uma mensagem ICMP.
2. Cenário alternativo: caso o roteador R3 tivesse uma rota default via R4, por exemplo, ocorreria um routing loop!

Solução para o problema descrito acima numa rede sem o MPLS

Implementar o protocolo BGP em todos os roteadores que estiverem "em linha" com o tráfego em trânsito no AS! Para sanearmos o problema descrito acima, seria necessário implementar sessões IBGP entre todos os roteadores em trânsito, e este é um argumento de possíveis problemas de escalabilidade na medida em que a rede crescer. Para a resolução do exato problema descrito acima, não basta apenas ter o BGP rodando em todos os roteadores, mas as próprias sessões IBGP tem que ser completamente FULL MESH!

Por que o Full Mesh das sessões IBGP é exigido neste cenário?

O protocolo BGP funciona de forma relativamente diferenciada entre sessões EBGP e IBGP:

EBGP
- Assumimos que na maioria dos casos os roteadores EBGP vizinhos estejam diretamente conectados - e não me refiro à conexões físicas diretas, mas o fato de estarem interconectados através de uma mesma subrede IP. Inclusive o TTL do cabeçalho IP usado pelos pacotes/mensagens do BGP é igual a "1" para este tipo de sessão, ou seja, é realmente esperado que os roteadores numa sessão EBGP estejam na mesma subrede IP, do contrário a sessão não funciona.
  - É possível relaxarmos esta exigência via implementação de EBGP Multihop.
- Os atributos AS_PATH e NEXT_HOP dos anúncios são sempre modificados entre as sessões EBGP. Outros atributos podem ser modificados mediante configuração de políticas de roteamento pelo administrador da rede.
IBGP
- Ao contrário das sessões por EBGP, assumimos quase que integralmente na maioria dos casos que os roteadores IBGP vizinhos não estejam diretamente conectados - e não me refiro à conexões físicas diretas, mas o fato de estarem ou não interconectados em uma mesma subrede IP.
- Por padrão, nenhum atributo é modificado dentro do AS por uma sessão IBGP. Isto inclui todo e qualquer atributo que estiver associado à rota, valendo para o AS_PATH, NEXT_HOP, Origin, Communities, etc.
  - OBS: é possível via configuração de políticas de roteamento fazer a modificação de atributos quando repassando um anúncio para um vizinho IBGP ou EBGP. Um exemplo clássico aqui é a modificação do atributo NEXT_HOP feita pelo roteador R1 no cenário demonstrado anteriormente.
  - Uma vez que nenhum atributo é modificado dentro de um AS pelas sessões IBGP, nada impediria deste anúncio circular indefinidamente dentro do AS 200 demonstrado, certo? Por que? Note que não há métricas de diâmetro ou custos ou qualquer coisa que pudesse auxiliar na seleção do caminho e, principalmente, na detecção de um routing loop.
    - Por este motivo o BGP implementa o conhecido Split Horizon

"Não repassar para vizinhos IBGP quaisquer prefixos que tenham sido aprendidos através de uma sessão IBGP" - Split Horizon do BGP

Portanto, isto explica não somente a necessidade de termos que rodar o protocolo BGP em todos os roteadores do AS 200 demonstrado, mas como as próprias sessões deverão ser Full Mesh (sessões entre todos; ou "de todos para todos"). Onde isto pode ser mais operacionalmente complexo: a quantidade de sessões IBGP requeridas em um AS pode crescer drasticamente na medida em que novos roteadores com sessões IBGP são introduzidos no AS. A fórmula para derivarmos isto inclusive é a N*(N-1)/2. Isto significa que, numa rede com 10 roteadores precisando rodar o BGP, teríamos 45 sessões IBGP!

Há como flexibilizarmos e minimizarmos substancialmente a quantidade de sessões IBGP em um AS através de duas soluções:

Route Reflectors
Confederations

Ou até mesmo uma combinação de ambos. Todavia, em ambos os casos, uma coisa não será eliminada: a necessidade de termos o BGP em todos os roteadores do cenário demonstrado! E é aí que entra a solução “BGP-Free Service Provider Core”.

A Solução BGP-Free Service Provider Core

Com o advento do MPLS, esta exigência de todos os roteadores do Core da rede terem que possuir a tabela de roteamento de Internet completa pode ser completamente removida do projeto. Isto significa que, sim, com o MPLS é possível a construção de um Core completamente isento de BGP. O cenário:

Compreendendo a Construção do Cenário e seus Componentes

Os roteadores do AS 200 (R1, R2, R3 e R4) estão rodando o protocolo de roteamento OSPFv2 como IGP para atendimento dos prefixos internos (/30 e /32 (loopbacks)) do AS apenas - sem prefixos de clientes como rotas IGP.
1. Participando as interfaces diretamente conectadas, exceto as interfaces externas.
2. Participando as interfaces Loopback, na condição de passive interface.
  1. Necessário, pois os roteadores precisam possuir conectividade IP entre as interfaces Loopback por algumas razões:
    1. Viabilizar a sessão com o protocolo Label Distribution Protocol (LDP) entre eles.
    2. Viabilizar a sessão IBGP entre os roteadores R1 e R4 apenas.
    3. Viabilizar outras soluções que beneficiam-se do MPLS e, portanto, dependem das interfaces Loopback (ex: MPLS TE, L2VPN, L3VPN...)
    4. Outras facilidades administrativas.
Para o AS 200, o protocolo BGP está em operação somente entre os roteadores R1 e R4; havendo uma sessão IBGP entre eles.
A troca de anúncios BGP flui normalmente à exemplo do que foi esclarecido nos cenários anteriores.
O MPLS label switching está em ação neste AS 200:
1. Sessões LDP existem nos roteadores, obviamente somente entre as vizinhanças diretamente conectadas (sem full mesh) e estas sessões são estabelecidas entre as interfaces Loopback.
2. Cada roteador aloca Labels com base nos prefixos IGP (independentemente do protocolo aqui; Connected, Static, OSPF, etc.).
  1. Labels são alocados somente sobre os prefixos IGP mencionados na tabela de roteamento de cada roteador!
3. Cada roteador distribui seus Labels alocados localmente para seus vizinhos, mesmo sem que haja uma solicitação ou pedido para tal, pois o Framed-Mode do MPLS opera por distribuição não solicitada de labels (unsolicited downstream label distribution).
4. Cada roteador recebe os labels do vizinho e os guarda em uma tabela específica, cujo nome varia de acordo com o fabricante. Por exemplo, Label Information Base (LIB) com a Cisco, e MPLS Routing Table com a Juniper.
  1. Cada roteador verifica em sua tabela de roteamento pela melhor rota para cada destino que tiver sido mencionado em um label recebido. Havendo vários labels recebidos de um diversos vizinhos LDP, o MPLS rodando no roteador escolherá o label anunciado por um vizinho que for, na tabela de roteamento, o Next Hop para o encaminhamento de tráfego para aquele prefixo de destino/rota na tabela de roteamento.
    1. O roteador continua mantendo as demais opções de labels para estes destinos em sua tabela de labels, mesmo que não sejam via o Next Hop na tabela de roteamento, num procedimento conhecido por retenção liberal de labels (Liberal Label Retention). Isto serve para agilizar a convergência da rede em caso de falhas com o Next Hop pelo IGP. Outros mecanismos podem ser configurados para maximizar a eficiência da convergência nestes casos, tais como o sincronismo entre IGP e LDP.
Os roteadores mantém estruturas de dados em áreas sistêmicas dedicadas para as funções de encaminhamento de pacotes. Os nomes e termos usados, e, obviamente, as minúcias e detalhamentos destas estruturas, variam de acordo com cada fabricante. No entanto, é possível, à título de conhecimento/educação aqui, "generalizar", considerando o cenário exemplificado acima:
1. Control Plane (Plano de Controle):
  1. Tabela BGP: onde ficam hospedados os prefixos BGP gerados localmente e aqueles recebidos de vizinhos IBGP e/ou EBGP. Mantida em memória RAM.
  2. Tabela LSDB e Tabela de Adjacência do OSPF: estruturas de dados mantidas pelo protocolo de roteamento OSPFv2. Mantida em memória RAM.
  3. Tabela de Roteamento (RIB): a famosa "routing table" dos roteadores. Mantida em memória RAM.
  4. Tabela de Labels (LIB, MPLS Routing Table): a tabela que contém os Labels gerados e alocados localmente pelo roteador, assim como os labels recebidos das vizinhanças LDP.
  5. ARP Cache: tabela que contém o cache das resoluções do protocolo ARP.
2. Data Plane (Plano de Dados):
  1. Tabela de Encaminhamento de Pacotes IPv4/IPv6: o nome muda de acordo com o fabricante, pois a Cisco a denomina de Forwarding Information Base (FIB) enquanto a Juniper a denomina IP Forwarding Table, e outros fabricantes usam outros nomes. É uma representação mais eficiente da tabela de roteamento, tanto no aspecto da qualidade de informações mantidas (mais simplista e objetiva aqui) quanto na estruturação destes dados, pois, geralmente, são estruturas montadas sobre conceitos Tree Bitmap (TBM) ou M-trie, ou outras. Computacionalmente mais eficientes.
    1. Este tipo de estrutura num primeiro momento é montada em software, para que sejam construídas as cadeias de invocação de recursos (Feature Invocation Arrays e congêneres) para o pipeline de processamento de pacotes e, posteriormente, isto é programado em estruturas de dados mantidos em TCAMs e similares nos processadores de rede (NPU). Cada alteração que ocorre na tabela de roteamento (ex: entra uma rota, ou sai uma rota) é refletida do Plano de Controle para o Plano de Dados, pois a intenção é que todas as ações envolvendo o processamento de pacotes sejam feitas em silício especializado, e não por software.
  2. Tabela de Adjacências: que contém os procedimentos necessários para a reescrita de cabeçalhos (ex: L2) devidamente prontas, já pré-computadas. Os nomes são específicos para cada fabricante: Label Information Forwarding Table (LFIB) com a Cisco, MPLS Forwarding Table com a Juniper, etc. Cada entrada da tabela de encaminhamento de pacotes citada anteriormente aponta para uma ou mais adjacências pré-computadas. O maior fomentador de instruções para esta tabela de adjacência é o protocolo ARP (IPv4) e ND (IPv6), que reside no Plano de Controle, além das configurações gerais da interface de saída associada à adjacência (MTU, tag de VLAN...).
  3. Tabela de Encaminhamento de Pacotes com Labels: é uma tabela específica para ações de encaminhamento de pacotes que contém labels. Quando um roteador recebe um pacote que contém label (ex: quadro Ethernet com campo EtherType denotando 0x8847), a consulta não considerará a tabela de encaminhamento de pacotes IP, e sim uma tabela específica para operações com labels (para push, swap, pop, e o efetivo encaminhamento do pacote em seguida). Esta tabela é montada com base nas resoluções de melhor rota na tabela de roteamento + label recebido de vizinho LDP que for o Next Hop para o encaminhamento de tráfego para esta rota, conforme ditado pela tabela de roteamento. Ou seja, considera informações de ambas as tabelas de roteamento e de labels.
3. Essas estruturas todas dos planos de controle e de dados são atualizadas constantemente via diversos mecanismos de comunicação entre processos (interprocess communication ou IPC), cujos específicos variam conforme o fabricante do equipamento. A proposta é que as ações de encaminhamento de pacotes não sejam executados por interrupções de software, e sim por silício especializado. É o que se espera de um equipamento de classe específica para operação em ambientes de redes de provedores.

Fonte: Juniper Networks

Fonte: Cisco

Compreendendo o Funcionamento do Cenário de BGP-Free Core em uma Rede MPLS

O roteador do AS 300 encaminha o tráfego para o endereço IP de destino 50.50.50.1, cuja rota considerada foi uma rota EBGP para a rede 50.50.50.0/24 via 196.168.0.5, através da interface Ethernet 0/2.
O roteador R4 do AS 200 recebe o pacote, faz as validações iniciais já discutidas/apresentadas, e determina o caminho por rota IBGP 50.50.50.0/24 via Next Hop BGP 10.1.1.1 (sessão IBGP que mantém com o R1).
O roteador R4, sabendo que para chegar até o Next Hop BGP 10.1.1.1, utilizará uma das duas rotas IGP/OSPF disponíveis. Suponhamos que tenha optado a rota OSPF via a adjacência que possui com o roteador R3 através da interface Ethernet 0/0.
1. As interfaces Ethernet0/0 e Ethernet0/1 do roteador R4 está habilitada para o MPLS.
2. O roteador R4 possui duas sessões LDP com os roteadores R3 e R2, respectivamente.
3. O roteador R4 recebeu labels referentes ao prefixo 10.1.1.1 /32 de seus respectivos vizinhos R3 e R2.
4. Ambos os vizinhos R3 e R2 são Next Hop IGP válidos para encaminhamento de tráfego com destino ao 10.1.1.1 (Next Hop BGP da rota 50.50.50.0/24).
  1. Portanto, duas entradas na tabela de encaminhamento de pacotes com labels (LFIB/MPLS Forwarding Table) já ficam criadas e prontas para serem utilizadas.
O roteador R4 faz o "push" do Label conforme instruído pela tabela LFIB/MPLS Forwarding Table.
O roteador R3 recebe o quadro Ethernet vindo do roteador R4 em sua interface Ethernet 0/0.
1. O campo EtherType do quadro recebido indica que o payload é MPLS (EtherType 0x8847 (MPLS Unicast)) e, por conta disto, o R3 não consultará a estrutura de encaminhamento de pacotes IP! O roteador trabalhará exclusivamente por operações com labels em uma estrutura específica para este propósito (MPLS Forwarding Table/LFIB).
2. A LFIB determina que, para encaminhar o pacote para o endereço IP 10.1.1.1, caso o pacote tenha sido recebido com label o valor gerado localmente pelo próprio R3, a operação deverá ser uma disposição do label ("pop").
  1. Isto porque o roteador R3 é o penúltimo salto até chegar ao roteador R1. O recurso Penultimate Hop Popping (PHP) do MPLS é habilitado por padrão, mas pode ser configurado para não ser realizado em determinadas ocasiões.
3. Ou seja, o roteador R3 retira o label e encaminha o pacote IP para o último salto (R1).
O roteador R1 recebe o pacote IP (quadro EtherType com valor 0x0800 indica isso), ou seja, consulta o endereço IP de destino sobre a estrutura de encaminhamento de pacotes IP (FIB ou IP Forwarding Table), e determina que o Next Hop é o 192.168.0.0 via interface de saída Ethernet 0/2. E transmite o pacote para o roteador do AS 100, que por sua vez entrega para o usuário que está em uma rede diretamente conectada.

Benefícios do BGP-Free Core deste Cenário Demonstrado

Resumiremos os benefícios deste tipo de solução para que isto possa ficar bem esclarecido:

Foi possível eliminar por completo o BGP no "Core" da rede, que seria, na topologia demonstrada, os roteadores R2 e R3 representados.
A eliminação do BGP por completo dos roteadores R2 e R3 simplificou substancialmente o projeto técnico e toda a parte do BGP no geral.
A configuração dos roteadores de Core fica bem mais enxuta e os equipamentos implementam apenas tecnologias mais simplistas, mas não menos necessárias ou eficientes: IGP (OSPF), LDP (label switching), QoS (se houver; desejável), e outros recursos necessários em projetos de infraestrutura.
O projeto técnico geral ficou mais leve no cenário demonstrado. Operacionalmente menos complexo também em alguns aspectos.
E, um dos melhores argumentos, a questão financeira: roteadores de classe carrier grade e que precisam ao mesmo tempo performar com muita capacidade e manter pesadas estruturas de rotas (full routes), costumam representar um pesado investimento de ordem financeira para os provedores.
- Considerando a topologia apresentada nos cenários estudados neste artigo, todos os roteadores precisariam suportar o BGP, conforme ficou provado/esclarecido. Para acomodar bem full routes e ofertar excelente capacidade de comutação, seriam considerados equipamentos caros como Juniper MX 240 ou superior, série Cisco ASR 1000 ou Cisco ASR 9000, Huawei NE40, apenas para exemplificar alguns casos e opções, para a composição do hardware dos roteadores R2 e R3.
- Conseguiríamos atender excepcionalmente bem as mesmas necessidades de projeto de AS de trânsito num Core isento de BGP com MPLS, usando, para os roteadores R2 e R3, roteadores Cisco NCS 540 ou 5500, Juniper QFX, Huawei S6720, apenas para citar alguns casos e opções, que são excepcionais para aplicações baseadas no MPLS e que, ao mesmo tempo, custam bem menos do que as outras opções citadas.
- Isto se traduz em investimentos muito mais em conta para os projetos de infraestruturas do provedor!

Vídeo Demonstrativo de um Cenário com BGP-Free Core para Redes MPLS de Provedores

Para este artigo produzi um vídeo bem objetivo demonstrando o funcionamento deste tipo de cenário. O vídeo está disponível também no canal do YouTube do Brasil Peering Forum!

Demonstração do BGP Free Core em Redes MPLS para Provedores

Resumo dos Argumentos para a Adoção do MPLS nas Redes dos ISPs

Editado/inserido em 10 de maio de 2020:

Seria um caso de uma "guerra da desinformação"? O MPLS foi criado no ano de 1997, após um esforço tremendo de profissionais, empresas e órgãos extremamente talentosos, para sanar diversas das complicações inerentes do roteamento IP tradicional e ao mesmo tempo em que destravando oportunidades inovadoras para os segmentos de telecomunicações. O MPLS teve o seu primeiro RFC datado no ano de 2001. Ou seja, é uma tecnologia com 19 anos de maturidade e que tem sofrido evoluções significativas ao longo deste tempo, incorporando novos recursos e capacidades. E tudo isso para que, em pleno ano de 2020, eu me depare com vídeos de YouTube e áudios de grupos de WhatsApp onde alguns "consultores" de ISP sugerem que o MPLS não deva ser usado por ser desvantajoso, por não proporcionar benefícios significativos, por tornar os projetos técnicos desnecessariamente complexos, dentre outros argumentos surreais. Tudo bem, cada caso é um caso, e isto é uma grande verdade! Nem todas as redes precisam de MPLS, outra verdade, e eu aceito isto com muita naturalidade. Mas tem um porém...

... o que me impressiona não é "usar ou não o MPLS", e sim que os argumentos usados por alguns especialistas, pelo menos nos casos que eu tive acesso, são absolutamente contrários ao que o MPLS propõe-se a fazer, ou seja, os (pseudo)especialistas mal sabem que o MPLS é justamente a tecnologia mais indicada para sanar diversos dos problemas que são provocados pelas mesmas tecnologias legadas e padrões de projetos que eles recomendam para as redes de seus clientes. Ou seja, um tiro no pé. Não é difícil refutar (educadamente ou ironicamente) ou contra argumentar estes casos.

Nem tudo se resume a "resolver problemas" numa rede. Fato. Mas, além desta questão de antecipar e resolver desafios/problemas, quando é que estas pessoas considerarão a inovação tecnológica como mecanismo para "destravar" o crescimento dos negócios, através da oferta de produtos mais competitivos, adoção de tecnologias mais confiáveis e que permitam conceber cenários com maior elasticidade, flexibilidade, menor esforço, e empregando menos custos e recursos?

Analogias à parte, até parece que a nossa realidade aqui (telecom, redes, MPLS..) não está tão distante assim do que propagam os Terraplanistas! A humanidade sabe que a Terra não é plana desde os remotos tempos de Eratóstenes (276 a.C. a 194 a.C.), mas, ironicamente, em 2020, cada vez mais pessoas afirmam que a Terra é plana! Estaríamos todos nós regredindo? Saindo da analogia e voltando ao tema principal: será que para estes profissionais a lógica funciona conforme está mostrado abaixo?

OBS: não sinta-se ofendido! Estou apenas esclarecendo o meu ponto de vista de forma descontraída e fornecendo os argumentos (logo a seguir) para aqueles que se interessarem pelo tema! Estou aberto a diálogos com qualquer um sobre o tema, mesmo com aqueles que pensem de forma diferente ou que divirjam sobre as minhas opiniões e argumentos. Caso mudem de opinião a respeito, não se esqueçam de citar a fonte destas dicas; o autor e a URL deste artigo do BPF, ok? :-)

F r e e y o u r m i n d

Vamos lá?

1- Benefício de processamento: operações realizadas com consultas sobre shim heders (cabeçalho do MPLS) são computacionalmente menos onerosas/intensas do que operações L3 padrão, ou seja, aquelas executadas normalmente sobre cabeçalhos IP, lá no plano de dados. O MPLS pode trazer benefícios para esta questão de overhead de processamento, algo que afeta especialmente arquiteturas baseadas em softrouter (Mikrotik, VyOS, FRR, e outras.).

2- Benefício de redução de esforços operacionais e de riscos de indisponibilidade: comparando com ambientes L2 nativos, o provisionamento de serviços é absurdamente mais simplificado em backbones turbinados por MPLS. Nas redes L2 tradicionais, todo elemento de rede ativo (switch) precisa conhecer as VLANs, e os respectivos entroncamentos (uplinks e afins) precisam autorizar explicitamente estas VLANs, o que resulta em mais configurações e em mais elementos de rede para viabilizar o serviço, além de abrir espaço ou dar margem para o surgimento de incidentes decorrentes de falha humana durante as ações de configuração. No transporte de serviços L2 sobre redes MPLS, os pontos de intervenção humana são reduzidos e bastante simplificados para geralmente 2 ou poucos locais onde estas configurações seriam exigidas. Um benefício de redução de esforços operacionais, e também um benefício de redução de riscos de downtime/indisponibilidades decorrentes de falha humana.

3- Benefício de escalabilidade L2: projetos de infraestruturas L2 nativas possuem diversas restrições associadas à escalabilidade dos próprios protocolos de resiliência Ethernet, incluindo aqui as variações de protocolo Spanning Tree (802.1d, 802.1w, 802.1s, ou o 802.1aq), EAPS, G.8032 e REP. Em adição, os protocolos de resiliência Ethernet possuem limitações de diâmetro e não são seguramente imunes quanto aos riscos de bridging loops, que podem provocar distúrbios graves numa rede de ISP. Além destas complicações e as demais citadas no ponto "2", uma rede L2 nativa jamais escalará tanto quanto uma rede que combina um plano de controle L3 com um arquitetura de label switching (MPLS), que é bastante resiliente na questão de loops, mais escalável e mais indicada para os cenários de convergência de serviços.

4- Benefício de escalabilidade L3 e redução de custos: comparando com ambientes L3 "nativos", o MPLS proporciona várias vantagens. Desde a (já citada) redução de processamento com as operações de determinação de caminhos (lookup) e encaminhamento de pacotes (packet switching e rewrite), a projetos de redes que prevêem a eliminação do protocolo BGP do core da rede ("BGP-Free Core"). Só na questão do BGP Free Core as vantagens são muitas, desde benefícios de ordem técnica e operacional, a um dos principais indicadores-chave de performance do negocio (do inglês "KPI") da cabeça e do coração de donos de ISP, que é o custo. Interessante que alguns donos de ISP parecem não se importar com isto, mesmo que praticamente todas as decisões que tomem sejam centradas no fator de menor custo, não é mesmo? Pois bem, saibam que projetos BGP-Free Core, que são baseados no MPLS, promovem excepcional REDUÇÃO DE CUSTOS, incluindo custos operacionais (opex) e os pesados investimentos com o hardware de ativos de rede (capex).

OBS: redução de custos como, exatamente? O BGP-Free Core permite dispensar a necessidade de equipamentos "parrudos" no core da rede, ou seja, equipamentos que devam possuir suporte em hardware a full routes, os quais enquadram-se aqui roteadores como o Juniper MX, Cisco ASR 1000, Cisco ASR 9000, Huawei NE20/NE40, e demais arquiteturas notoriamente mais caras ($$$). Ao invés de gastar fortunas com estes tipos de equipamentos, você poderia muito bem investir em arquiteturas mais especializadas para a missão de core com boa densidade de portas 10/40/100G, boa relação de throughput/largura de banda de comutação/wirespeed switching, suporte a tecnologias essenciais para o backbone (IGP+MPLS+TE+QoS-OAM+MP-BGP para outras AFI/SAFI), dentre outras características. Ou seja, seria muito mais interessante e econômico, e com benefícios nas questões de desempenho, flexibilidade, densidade de portas, manutenção de SLA e etc., investir em roteadores ou switches mais especializados para esta missão, como, por exemplo, o Cisco NCS 540, NCS 5500, Juniper QFX, ou Huawei S67x0, para citar alguns exemplos, do que investir nas plataformas "parrudas" citadas anteriormente. E, melhor ainda, esta alternância permite reduzir custos sem que haja prejuízos na qualidade e sofisticação da rede, muito pelo contrário! Enfim, o argumento "BGP-Free Core", por si só, já justifica praticamente qualquer ISP a considerar um projeto com MPLS!

5- Benefício de viabilidade rápida e pouco traumática do IPv6: o MPLS não suporta nativamente o IPv6 - coisa que é da alçada de uma tecnologia mais recente chamada Segment Routing v6 (SRv6) - mas, felizmente, é possível acomodar simultaneamente as famílias de endereço IPv4 unicast e IPv6 unicast sobre uma infraestrutura comum baseada no MPLS, ou seja, combinando e estendendo os benefícios do MPLS para ambos os protocolos IPv4 e IPv6. É o que chamamos de IPv6 Provider Edge over MPLS ou "6PE". O 6PE permite você manter o backbone operando apenas com endereçamento IPv4, podendo ser ainda com endereços privativos, enquanto, na borda, mais precisamente nas interfaces "customer-facing" e demais conexões externas, você habilita o regime de pilha dupla / dual-stack (IPv4 + IPv6). As sessões BGP internas (IBGP) de um ambiente assim são estabelecidas com IPv4-only, mas os NLRIs negociados nestas sessões incluem ambos o IPv4 e o IPv6, e todas as operações com pacotes do tráfego em trânsito no backbone fluem por ações com labels. Um ganho de simplicidade no ponto de vista de projeto técnico na área sistêmica denominada "Plano de Controle", redução das exigências dos requisitos de capacidade do plano de dados, e com vantagens adicionais nas questões de segurança, escalabilidade e convergência, além de pavimentar bem rapidamente a adoção do IPv6, e de forma pouco traumática. Quando combinado com projetos BGP-Free Core, o 6PE acentua ainda mais os já discutidos benefícios de redução de custos.

6- Benefício da evolução de serviços L2: projetos de infraestrutura onde estão previstos a oferta de serviços de transporte de tráfego L2 podem ser executados de várias formas e com várias tecnologias, inclusive as legadas. Comparando projetos L2 tradicionais com projetos L2VPN MPLS, as vantagens são muito superiores no segundo caso, e com diversos benefícios para as questões de imunidade contra bridging loops, escalabilidade, confiabilidade, resiliência, gerenciamento, usabilidade, e até mesmo a construção de "produtos do provedor" para seus clientes outrora mais difíceis de serem concebidos com tecnologias tradicionais ou legadas. Ironicamente, as próprias tecnologias L2VPN MPLS (VPLS e VPWS) estão aos poucos tornando-se "legadas", migrando para o Ethernet VPN (EVPN), que é centrado em AFIs/SAFIs específicas do BGP, mas que continuam operando sobre o MPLS tradicional, ou já com o Segment Routing, e podendo ainda coexistir com o VXLAN em ambientes de data center.

7- Benefício da evolução de serviços L3: projetos de infraestrutura para serviços de interconexão de sites (VPN) de empresas do segmento corporativo podem ser construídos de várias maneiras, cada qual com conjuntos de requisitos e desafios distintos. Uma solução de L3VPN MPLS consegue viabilizar customizações e possibilidades de cenários que são praticamente "inviáveis" com projetos L3 tradicionais sem o MPLS, obviamente destacando aqui complexidades, desafios, e a própria viabilidade técnica em larga escala da solução. Experimente montar uma L3VPN sem o MPLS, e surpreenda-se com a complexidade no ponto de vista de matrizes de participantes, overlapping de endereços IP, filtros de rotas, políticas de roteamento, firewalls, filtros de pacotes, e tudo aquilo que você teria que lançar no projeto técnico para assegurar a comunicação e a privacidade entre os sites de seus clientes! Agora, experimente fazer o mesmo com o L3VPN MPLS. E veja/compare a diferença.

OBS: está fora de discussão comparativa entre L3VPN MPLS e SD-WAN, ok?

8- Benefícios da engenharia de tráfego: engenharia de tráfego não é exclusividade de uma solução que funciona no topo do MPLS, ou seja, do MPLS-TE, mas, sim, a necessidade de acomodarmos melhor os fluxos de tráfego sobre os recursos de rede existentes. Esta necessidade sempre existiu e sempre existirá para redes L2 nativas ou L3 nativas. Há muitos desafios associados aqui, mas o fato é que a engenharia de tráfego com MPLS-TE é absolutamente mais flexível, vantajosa, e menos complexa do que qualquer modalidade ou gambiarra que normalmente se usa em ambientes L2 e L3 nativos. Sem contar que, como diferencial, o MPLS-TE pode ser usado para a rápida recuperação e rápida reconvergência da rede (nível sub-segundo) em cenários de falhas (mecanismo make-before-break com o FastReroute (FRR)).

9- Benefícios de evolução das próprias arquiteturas centradas no conceito de label switching: o MPLS deu tão certo, mas tão certo, que, fundamentalmente, no plano de dados, continua basicamente sendo o que é e sempre foi. No entanto, no plano de controle, novas tecnologias estão surgindo para dar um belo upgrade nas redes MPLS atuais, mirando nesta evolução de qualidade e aprimoramento dos níveis de serviços das redes, fornecendo maior elasticidade, flexibilidade e escalabilidade. É o caso do Segment Routing (SR e SRv6), SR-TILFA, SR-TE e todo o combinado tecnológico que anda lado-a-lado com estas novas tecnologias (Ex: EVPN-VPWS, EVPN-Multihoming All-Active, EVPN-PBB, EVPN-IRB, EVPN-VXLAN, etc.).

10- Consulte o mercado, em particular os service providers/ISPs sérios e profissionais, e veja se eles estariam dispostos a remover o MPLS de seus ambientes: apenas t e n t e. Aproveite a oportunidade para questionar bastante as motivações, critérios adotados, e tudo mais. Este networking com outras empresas, profissionais e especialistas poderá ser muito bom para você tirar as suas próprias conclusões, além de servir como ótima ferramenta para o seu crescimento profissional.

Outras Tecnologias e Soluções viabilizadas pelo MPLS

Para não sacrificarmos este artigo e torná-lo algo muito grande, sintetizarei este entendimento:

Infraestrutura melhor alinhada e mais compatível com padrões Metro Ethernet / Carrier Ethernet.
MPLS L3VPN: VPNs ponto a ponto e ponto-multiponto, com roteamento entre PE e CE em instâncias de roteamento dedicadas e isoladas por cliente, possibilitando ainda serviços gerenciados sobre CPE de clientes, privacidade e segregação de redes de clientes sobre um backbone comum, confecção de sofisticados cenários de Extranets, dentre outras aplicações de alto valor agregado.
MPLS L2VPN: por tecnologia VPLS hierárquico (H-VPLS) sobre o conceito Ethernet Virtual Circuit (EVC) e outros termos similares implementados por fabricantes de renome para extensão de LANs multiponto, e VPWS/EoMPLS para extensão de LANs ponto a ponto de clientes.
Solução combinada L2 e L3 com MPLS no Acesso: para transporte do tráfego L2 do assinante até a borda de serviços (roteador de borda ou PE), onde ocorrerá os serviços de roteamento IP e demais recursos.
MPLS QoS: para o aprimoramento da qualidade de serviço (QoS) e níveis de serviço (SLA) de aplicações de missão crítica de clientes; prioridade nos serviços de comunicação em tempo real, combinando DS-TE com modos Uniform, Pipe e Short-Pipe e modelos Maximum Allocation Model (MAM) ou Russian Doll Model (RDM).
MPLS Traffic Engineering (TE): para fins de engenharia de tráfego de serviços de Internet e/ou tráfego de clientes corporativos; interconexão de Data Centers, comunicação inter-POP, etc., possibilitando encaminhar diversas classes de tráfego em padrões administrativamente configurados e desassociados das premissas regidas pelas tabelas de roteamento, acarretando em maios flexibilidade e melhor utilização dos recursos de rede disponíveis. O MPLS TE evitará que poucos links fiquem sobrecarregados enquanto a maior parte dos enlaces do backbone fiquem ociosos.
MPLS TE com Fast Reroute (FRR): para proteção milissegundo contra quedas de roteadores e enlaces no backbone, maximizando muito consideravelmente as métricas de disponibilidade de serviços do provedor.
MPLS Transport Profile (TP): com integração ao IP/MPLS com uso de G-MPLS e T-LDP baseado nas extensões de MPLS TE.

E, para finalizar, o MPLS viabiliza a adoção de tecnologias mais vigentes para simplificação, flexibilidade, elasticidade das infraestruturas, sem contar que é mais aderente aos novos padrões de programabilidade. Seja pelos modelos tradicionais do MPLS ou pelas suas evoluções tais como Segment Routing, SRv6, EVPN VXLAN e derivados. Para exemplificar, algumas das evoluções dos projetos MPLS:

Unified MPLS (originalmente "Seamless MPLS"): uma abordagem que viabiliza a escalabilidade para redes muito grandes, tipicamente uma realidade para os grandes operadores de telecomunicações. O Unified MPLS adota os cenários MPLS típicos, mas com algumas modificações na forma em que projetamos o roteamento interior (IGP) do backbone assim como o label switching referentes aos prefixos IGP do AS, além da inclusão de mecanismos adicionais tais como o BGP-4 Labeled Unicast, o "BGP-LU" (RFC 3107 “Carrying Label Information in BGP-4"), e, opcionalmente, porém desejável, de componentes periféricos tais como BGP PIC, extensão do MPLS para o Acesso, protocolos OAM, mecanismos de fast reroute tais como o LFA/R-LFA, ou ainda a infraestrutura de cada domínio IGP do MPLS unificado sendo tratada já por mecanismo Segment Routing Topology Independent Loop-Free Alternate (SRTILFA) para as necessidades de label switching + engenharia de tráfego + fast reroute, cujas as ações são governadas por um único protocolo (pelo próprio IGP), ao contrário do que fazemos normalmente com o emprego de múltiplos protocolos nos projetos MPLS tradicionais.
SDN-enabled Agile Carrier Ethernet: evolução das arquiteturas Unified MPLS com princípios plenos de programabilidade e orquestração (NSO, PCE, XTC, etc.) para maior flexibilidade, seleção inteligente de caminhos e engenharia de tráfego, mecanismos de proteção contra falhas de equipamentos e enlaces, e afins. Esta abordagem aprimora substancialmente as ferramentas que devemos usar para sanear os mesmos desafios de sempre; atender as mesmas necessidades. No entanto, são procedimentos e ferramentas bem mais atraentes e em diversos aspectos. Esta abordagem é inovadora e representa um MPLS bem mais sofisticado e escalável para infraestruturas bastante elásticas e autônomas.

Confira este mapa mental que resume muitos dos componentes das soluções baseadas no MPLS: https://wiki.brasilpeeringforum.org/images/1/1b/MPLS_Mind_Map_-_Leonardo_Furtado.pdf

Espero que este artigo tenha sido útil!

Autor: Leonardo Furtado

Redes MPLS para Provedores

Índice