Exibir código-fonte para Redes MPLS para Provedores

=== 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 <u>escalabilidade</u>, 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:
[[Arquivo:Bpf-mplsparaprovedores-1.png|centro|miniaturadaimagem|800x800px]]
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:
## ''NEXT_HOP:'' o endereço IP de origem utilizado pelo roteador do AS 100 para a sessão EBGP com o roteador R1.
## ''Origin:'' assumimos neste exemplo que o prefixo tenha sido gerado nativamente no BGP, e não por redistribuição.
## ''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:
## 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.
## 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:
## Na perspectiva do roteador R4, o atributo NEXT_HOP para este prefixo é o endereço IP da interface Loopback do roteador R1.
## O roteador aceita e utiliza esta rota porque consegue realizar uma computação recursiva para este NEXT_HOP do BGP.
### 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:
## Realiza duas modificações por padrão: 
### inclui o AS 200 na lista de Autonomous Systems associados ao prefixo.
### 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á:
[[Arquivo:Bpf-mplsparaprovedores-2.png|centro|miniaturadaimagem|800x800px]]
# 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.
## 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).
## 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''".
## 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.
## 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.
## 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.
### 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)''.
#### Possui dúvidas sobre o ECMP e como isto é implementado? Confira este artigo na Wiki do BPF: [[Balanceamento de Trafego em Redes MPLS]]
### 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.
#### O roteador R4 retirará "-1" do TTL restante no cabeçalho IP e recomputará um novo CRC para o cabeçalho IPv4.
#### 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)).
#### 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.
## 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.
### O roteador R3 <u>descartará o pacote</u> e encaminhará uma notificação para o remetente do pacote via uma mensagem ICMP.
## 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'''!''
[[Arquivo:Bpf-mplsparaprovedores-3.png|centro|miniaturadaimagem|800x800px]]
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 <u>estejam</u> 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 '''<u>não</u>''' 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 <u>nenhum atributo</u> é 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:
[[Arquivo:Bpf-mplsparaprovedores-4.png|centro|miniaturadaimagem|800x800px]]

====== 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.
## Participando as interfaces diretamente conectadas, <u>exceto</u> as interfaces externas. 
## Participando as interfaces Loopback, na condição de ''passive interface''.
### Necessário, pois os roteadores precisam possuir conectividade IP entre as interfaces Loopback por algumas razões:
#### Viabilizar a sessão com o protocolo Label Distribution Protocol (LDP) entre eles.
#### Viabilizar a sessão IBGP entre os roteadores R1 e R4 apenas.
#### Viabilizar outras soluções que beneficiam-se do MPLS e, portanto, dependem das interfaces Loopback (ex: MPLS TE, L2VPN, L3VPN...)
#### 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:
## 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.
## Cada roteador aloca Labels com base nos prefixos IGP (independentemente do protocolo aqui; Connected, Static, OSPF, etc.).
### Labels são alocados somente sobre os prefixos IGP mencionados na tabela de roteamento de cada roteador!
## 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'').
## 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.
### 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. 
#### 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:
## '''Control Plane (Plano de Controle):'''
### '''''Tabela BGP:''''' onde ficam hospedados os prefixos BGP gerados localmente e aqueles recebidos de vizinhos IBGP e/ou EBGP. Mantida em memória RAM.
### '''''Tabela LSDB e Tabela de Adjacência do OSPF:''''' estruturas de dados mantidas pelo protocolo de roteamento OSPFv2. Mantida em memória RAM.
### '''''Tabela de Roteamento (RIB):''''' a famosa "routing table" dos roteadores. Mantida em memória RAM.
### '''''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.
### '''''ARP Cache:''''' tabela que contém o cache das resoluções do protocolo ARP.
## '''Data Plane (Plano de Dados):'''
### '''''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.
#### 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.
### '''''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...).
### '''''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.
## 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.
[[Arquivo:Bpf-mplsparaprovedores-5.png|centro|miniaturadaimagem|650x650px|Fonte: Juniper Networks]]
[[Arquivo:Bpf-mplsparaprovedores-6.png|centro|miniaturadaimagem|650x650px|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.
## As interfaces Ethernet0/0 e Ethernet0/1 do roteador R4 está habilitada para o MPLS.
## O roteador R4 possui duas sessões LDP com os roteadores R3 e R2, respectivamente.
## O roteador R4 recebeu labels referentes ao prefixo 10.1.1.1 /32 de seus respectivos vizinhos R3 e R2.
## 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).
### 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.
## 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). 
## 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''").
### 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.
## 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.
* '''<u>E, um dos melhores argumentos, a questão financeira:</u>''' 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!

[https://youtu.be/OWI4ndstx-o Demonstração do BGP Free Core em Redes MPLS para Provedores]

=== 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" (<nowiki>RFC 3107</nowiki> “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: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.Furtado Leonardo Furtado]'''
[[Categoria:Roteamento]]