ESTUDO SOBRE REDES

INSTITUTO INFNET RIO DE JANEIRO

ESTUDO SOBRE REDES

Yago da silva silva

Resumo

A crescente demanda de serviços de TIC (Tecnologia da Informação e Comunicações) demandou a busca de uma solução que facilitasse a administração, aumentasse a segurança, proporcionasse escalabilidade e realizasse a segregação de clientes no mesmo backbone de um Provedor de Serviço (SP). A tecnologia MPLS L3 VPN, quando aplicada com Multiprotocol BGP – mais conhecido como MP-BGP, mitiga esta demanda, proporcionado gerencia, segurança e escalabilidade. Seu uso pode oferecer serviços de valor agregado como Quality of Service (QoS) e Traffic Engineering, permitindo a convergência de rede englobando voz, vídeo e dados. A implantação de um cenário utilizando esta tecnologia é o foco deste trabalho.

Palavras-chave: MPLS, VPN, Multiprotocol BGP, VRF

Abstract

The growing demand for ICT (Information and Communications Technology) services demanded the search for a solution that facilitates administration, increases security, provides scalability, and performs customer segregation on the same backbone as a Service Provider (SP). MPLS L3 VPN technology, when applied with Multiprotocol BGP – more known as MP-BGP, mitigates this demand, providing management, security and scalability. Its use can offer value-added services such as Quality of Service (QoS) and Traffic Engineering, enabling network convergence encompassing voice, video and data. The implementation of a scenario using this technology is the focus of this work.

Keywords: MPLS, VPN, Multiprotocol BGP, VRF

Introdução

APRESENTAÇÃO

A crescente demanda de tráfego e o dinamismo do mercado, necessitando a cada dia de maior integração entre serviços (voz, vídeo e dados), fazem com que os provedores de acesso à Internet (ISPs – Internet Service Providers) estejam em constante atualização tecnológica. É fundamental acompanhar as tendências do mercado, com o objetivo de entregar sempre a melhor tecnologia para o cliente, com isto provendo uma boa qualidade nos serviços ofertados. (Mendonça, Lins, Oliveira, 2012, p. 6).

O aumento progressivo do volume de tráfego e das informações, associado à grande necessidade por qualidade de serviços que estes promovem, culminou na obrigação de estudar novas tecnologias que favorecessem recursos mais confiáveis, flexíveis e rápidos na transmissão de dados, sejam eles de âmbito pessoal ou corporativo

Os primeiros resultados implantados envolviam ligações físicas de forma praticamente direta entre as partes, obrigando o uso de infraestrutura cada vez mais dispendiosa a cada novo integrante da conexão

A solução para esta necessidade foi o surgimento das chamadas Virtual Private Networks (VPN), que nada mais são do que redes artificiais operando sobre backbones privados e/ou a Internet. Este serviço mostra-se como opção à interconexões dedicadas entre redes distintas, uma vez que aproveita a rede pública para estender o domínio entre duas ou mais redes locais (LAN).

Quando usadas com MPLS, VPNs permitem que diversas redes se interconectem transparentemente através da rede intermediária do seu Service Provider. A rede de um Service Provider pode suportar diversas VPNs IP diferentes entre si. Cada uma delas é vista como uma rede privada para seus usuários, separadas de todas as outras redes. Em uma VPN, cada rede pode enviar pacotes IP para qualquer outra rede nesta mesma VPN. (Cisco Systems, 2007)

VPN, entretanto, é apenas um mero conceito. Há inúmeras maneiras de implantação, cada uma com pontos positivos e negativos que necessitam ser levados em conta visando a forma da rede em questão, que tipo de dado será trafegado e como esse acesso precisará ser feito. Dentre as variadas soluções para a concepção de VPNs, exploraremos nesse trabalho o serviço de VPNs baseadas em MPLS, uma técnica de encapsulamento que vem obtendo grande destaque no mercado por conta de sua alta escalabilidade.  

MPLS é uma tecnologia desenvolvida no âmbito do IETF (Internet Engineering Task Force), no fim dos anos 90 (Lucek e Minei, 2005), que foi concebida com a ideia de combinar o melhor que há no encaminhamento de frames de camada 2, com o melhor do roteamento de camada 3. A inovação foi não realizar mais o encaminhamento dos pacotes da forma tradicional, com base no endereço IP de destino presente em seus cabeçalhos, mas sim, com base em rótulos (ou labels) de tamanho fixo, os quais, como será abordado em detalhes a seguir, também permitiram ao MPLS incorporar outras funcionalidades importantes, como L3 VPN, L2 VPN, ATOM, EoMPLS, MPLS-TE e segregação de serviços com QoS.

Objetivos

Demonstrar o funcionamento da tecnologia MPLS aplicada a uma simulação equivalente a estrutura de rede de um Provedor de Serviço (SP), com segregação de clientes utilizando L3 VPN, com auxilio do Multiprotocol BGP, mais conhecido como MP-BGP.

Detalhar conceitos, com base na literatura que define os protocolos, seus comportamentos situações de uso em que é recomendado, os benefícios trazidos com sua implantação e os desafios da manutenção de uma infraestrutura MPLS L3 VPN.

Descrever os motivos pelos quais esta tecnologia passou a ser amplamente empregada em redes de grande complexidade e os ganhos advindos de sua utilização em infraestruturas de rede de grande porte.

Objetivos Específicos

Sintetizar através de um laboratório, utilizando a ferramenta de simulação de redes UnetLab, toda parte teórica abordada neste trabalho, que possibilitará compreender o pleno funcionamento de uma arquitetura MPLS aplicada a um provedor, em escala e proporção menor, porém exemplificando a estrutura real utilizada em um SP. Compreender como um SP segrega sua rede, identificando como é possível dividir o trafego de diversos clientes utilizando o mesmo meio de transmissão sem haver conflitos.

Metodologia

Apresentar uma revisão teórica do funcionamento do protocolo MPLS, compreendendo a apresentação e seus vários elemento, incluindo nomenclatura e função, as dinâmicas do processo e como estes devem ser previstos e considerados no projeto da rede, e realizar uma demonstração pratica através de um projeto aplicada a um backbone de SP – Service Provider (Provedor de serviços), em um laboratório de um cenário real, de forma a atestar o quão eficiente foi o projeto.

Estrutura do trabalho

Este trabalho está dividido em cinco partes. A primeira parte é introdutória, e apresenta de forma breve os propósitos e a disposição do estudo. 

A segunda parte,  é abordado conceitos de roteamento, apresentando as diferenças sobre planos de controle e de dados e formas de implementação de rotas, além de retratar sobre protocolos de roteamento dinâmico e como estes podem
influenciar no conceito de VPNs. Este capítulo tem como finalidade abordar todos os tópicos tratados no experimento vistos no capítulo 3, englobando o conceito de VPNs, explicitando sua utilidade e mostrando conceitos de tunelamento, encriptação e encaminhamento de dados nas mesmas, MPLS, principal ponto tratado no trabalho como um todo na elaboração das VPNs MPLS, abordando conceitos de sua arquitetura, funcionalidades e mecanismos proporcionados por ele. 

O terceiro capítulo é aquele que descreve e apresenta o experimento, suas nuances e configurações de todos os protocolos e conceitos estudados até ele. 

A parte seguinte, ou capítulo 4, é aquele que apresenta considerações sobre o ambiente emulado, os benefícios percebidos com ele e constatações gerais sobre o que foi criado, visando a experimentação da topologia do capítulo 3 por meio de testes. Nele, é descrito todo o processo de configuração realizado, sequencialmente. 

Em seguida, há um capítulo para conclusões e elucidação de possíveis trabalhos futuros, o capítulo 5, em que são apontados os desafios para uma futura continuação deste desenvolvimento. 

As Referências Bibliográficas referem todos os locais de pesquisa necessários para a elaboração desta monografia.

Revisão de literatura

Redes TCP/IP

Roteamento IPV4

Conforme Mendonça, Lins e Oliveira (2012, p. 6), com adaptações, o IP (Internet Protocol) é o principal protocolo da Internet. Seu intuito é possibilitar a comunicação entre máquinas independentemente do meio de transmissão, este não possui mecanismos de notificação ou correção de erro. O IP não possui mecanismos que realizem consultas de gerenciamento, é sem controle de fluxo, não orientado a conexão e não era prevista qualidade de serviço, ou seja, foi criado para trabalhar em uma rede de melhor esforço. Durante o seu desenvolvimento, passou por inúmeras modificações em seu projeto inicial até adequar-se às novas necessidades, como, serviços de voz sobre uma rede de dados e serviço de vídeo sob demanda.

Ainda de acordo com Mendonça, Lins e Oliveira (2012, p. 12), roteamento é o o processo de escolha do caminho a ser seguido
pelos dados a serem transmitidos numa rede espalhada geograficamente WAN (Wide Area Network). Vários aspectos podem ser levados em consideração, desde a velocidade
dos enlaces até o número de saltos (hops) envolvidos, passando pelo custo
de transmissão e a confiabilidade dos canais. No roteamento há a retransmissão,
processo pelo qual os pacotes são encaminhados de um canal para outro. Nas redes
de datagrama, incluindo as redes IP, o roteamento é tratado pacote a pacote.
O protocolo IP, com sua simplicidade e flexibilidade, possui grande sucesso na
função do roteamento, sendo este protocolo responsável pela entrega das informações
geradas pelas aplicações aos seus destinos de forma correta e eficiente.

Continuando, roteamento IP é o termo utilizado para descrever as ações efetuadas pela
rede TCP-IP (Transmission Control Protocol) para enviar um pacote de um dispositivo a outro, ou seja, os endereços
IPs de origem e destino devem ser diferentes.

Segundo Enne (2009, p. 25), com adaptações, para reduzir o tráfego de roteamento, as redes IP, assim como as redes Multi-Protocol Label Switching (MPLS), podem ser divididas em diferentes autonomous systems (ASes), também referidos como domínios de roteamento (routing domains). Os ASes, por sua vez, podem ser subdivididos em diferentes áreas de roteamento.

Seguindo a definição de Enne (2009, p. 25) os protocolos que operam no interior de um AS são ditos protocolos de roteamento tipo Interior Gateway Protocol (IGP). Os protocolos cuja operação abrange toda a rede, considerando porém a existência de protocolos IGP nos seus diferentes ASes, são ditos protocolos de roteamento tipo Exterior Gateway Protocol (EGP).

No MPLS, os protocolos tipo IGP (OSPF, com ou sem extensões, particularmente) e Intermediate System to Intermediate System Protocol (IS-IS) são os responsáveis pela constituição dos caminhos hop-by-hop, salto a salto, entre os Label Switch Router (LSRs) explicado mais a frente, da rede, por onde passam os pacotes MPLS. No MPLS básico, os protocolos do tipo IGP são normalmente suficientes para o pleno funcionamento do MPLS.

 Em outras aplicações, como VPNs BGP/MPLS, o IP, torna-se necessário seu uso complementar de protocolos tipo EGP (BGP, particularmente) nos LSRs situados nas fronteiras da rede MPLS, Os caminhos hop-by-hop no interior da rede continuam, no entanto, a ser constituídos por túneis MPLS (quando os nós da interiores da rede são também LSRs), podendo alternativamente constituírem-se de túneis IP. 

A seguir uma abordagem resumida sobre as funções exercidas por cada tipo de protocolo em uma rede.

OSPF – Open Shortest Path First

Criado pelo IETF (Internet Engineering Task Force) em 1988, o OSPF é um protocolo de roteamento do tipo estado de enlace, que envia anúncios sobre o estado da conexão a todos os outros roteadores em uma mesma área hierárquica e usa o algoritmo SPF (Shortest Path First) para calcular o caminho mais curto para cada nó. Trata-se um protocolo IGP, de código aberto e amplamente divulgado na literatura. Foi projetado com o objetivo de substituir o protocolo RIP (Routing Information Protocol), resolvendo diversas limitações que este apresenta, e abordar as necessidades das redes grandes e escaláveis, as quais não eram abrangidas pelo RIP. A versão mais recente do protocolo para funcionalidade com o IPv4 é o OSPF versão 2 (OSPFv2), sendo o OSPF versão 3 (OSPFv3) utilizado para o IPv6 (Doyle e Carroll, 2006). Podemos citar algumas das principais características desse protocolo: 

  • Não há limite no custo máximo de uma rota;
  • O OSPF pode efetuar o balanceamento de carga; 
  • A convergência é mais rápida do que o Routing Information Protocol (RIP), já que as alterações de roteamento são difundidas imediatamente e são calculadas em paralelo; 
  • Tem suporte a Variable Length Subnet Mask (VLSM), ou máscara de sub-redes de tamanho variável, técnica que permite a divisão de sub-redes em sub-redes, com o objetivo de reduzir a perda de endereços IPs.
Intermediate System to Intermediate System 

O IS-IS [OSI 10589], assim como o OSPF, é um protocolo intra-domínio, hierárquico e que utiliza o algoritmo de Estado de Enlace. Pode trabalhar sobre varias sub-redes, inclusive fazendo broadcasting para Local Area Network (LANs), WANs e links ponto-a-ponto.

O Integrated IS-IS é uma implementação do IS-IS que, alem dos protocolos OSI, atualmente também suporta o IP. Como outros protocolos integrados de roteamento, o IS-IS convoca todos os roteadores a utilizar um único algoritmo de roteamento. 

Para funcionamento do Integrated IS-IS, os roteadores tambem precisam suportar protocolos como Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP) e End System-to-Intermediate System (ES-IS). Rede Nacional de Pesquisas (1997).

BGP – Border Gateway Protocol

O protocolo BGP-4, definido pela RFC 4271, é o protocolo tipo EGP de maior
importância no presente. Provê um conjunto de mecanismos para o suporte de
roteamento CIDR (Classless Inter-Domains Routing) que eliminam o conceito de
classes de endereçamento no BGP-4. Para isso, o BGP-4 inclui o suporte para
difundir um conjunto de destinos como endereços ou prefixos IP de destino,
independentemente da classe de endereços a que pertencem. Enne (2009, p. 31)

O BGP é utilizado para comunicação inter-AS, ou seja, para comunicação
entre sistemas autônomos, também denominado de EGP (Exterior Gateway
Protocol). Na Figura 1 podemos perceber a atuação desse protocolo na interligação entre os sistemas autônomos 65000, 65500, 65250 e 65520, os quais têm influência
direta na determinação do caminho que será utilizado pelo BGP, já que o BGP toma
decisão de roteamento com base no caminho percorrido entre os ASs, chamado de
protocolo de vetor caminho (Path Vector).

O Protocolo BGP – Utilizado entre AS da Internet
O Protocolo BGP - Utilizado entre AS da InternetMendonça, Lins e Oliveira (2012, p. 24)

Segundo Mendonça, Lins e Oliveira (2012, p. 24), seu principal objetivo é fornecer um sistema de roteamento entre domínios
que garanta a troca, livre de loops, das informações de roteamento entre os
sistemas autônomos. A divulgação das informações de roteamento BGP é feita entre
roteadores que estabelecem uma relação de vizinhança, o que chamamos de peers
(pares). Para que tal estabelecimento ocorra é necessário que dois roteadores
tenham conexão direta entre eles ou que algum protocolo IGP trate de garantir a
alcançabilidade.

Para garantir a alcançabilidade e a confiabilidade entre todas as redes da
Internet faz-se necessário que seja utilizada uma forma confiável de troca de
informações deste protocolo. Para tanto, o BGP faz uso do protocolo TCP (porta
179) para o transporte das informações de roteamento entre dois roteadores que
trocam informações deste protocolo. 

Funcionamento básico  

Entre cada par de IGP ASes envolvido no roteamento BGP existem um ou
mais border routers que procesam também o BGP, ou seja, que são também BGP peers ou BGP speakers. Esses roteadores constituem os denominados ASBRs (AS
border routers). A comunicação de roteamento entre BGP speakers situados nos
extremos de um AS é referida com IBGP (Interior BGP), enquanto a comunicação de
roteamento entre BGP speakers situados em diferentes ASes é denominada EBGP
(Exterior BGP). 

No funcionamento básico do BGP, os BGP speakers coletam as rotas
referentes as sub-redes contidas nos ASes a que pertencem (conduzidas
internamente por um protocolo IGP) e as repassam para os BGP speakers vizinhos. 

Nesse processo são repassadas, para toda a malha BGP, as rotas relativas à
totalidade das rotas dos diferentes ASes envolvidos. No interior de casa AS as rotas
dos demais ASes são distribuídas pelos BGP speakers através dos respectivos
protocolos IGP. 

Multiprotocol label switching (MPLS)

O MPLS é uma tecnologia aberta que foi apresentada inicialmente como uma solução que possibilitava melhorar o desempenho das redes IPs na função de encaminhamento de pacotes IPs, combinando o processo de roteamento de nível 3 com a comutação de nível 2 para realizar o encaminhamento de datagramas através de pequenos rótulos de tamanho fixo. Tais rótulos são números utilizados no protocolo MPLS e, através destes, a decisão de qual interface encaminhar o datagrama é tomada. (Rosen et al, 2001, p.1)

O Cabeçalho MPLS

O item mais importante para o MPLS é o rótulo (De Ghein, 2007). Conforme Mendonça, Lins e Oliveira (2012, p. 29), o rótulo é um identificador curto, de 4 bytes, e com significado local no roteador que é usado para identificar uma FEC (Forwarding Equivalent Class), isto é, um grupo de pacotes IPs que são enviados na mesma maneira, sobre o mesmo trajeto e com o mesmo tratamento de transmissão. 

A figura 2 ilustra a formação do cabeçalho MPLS.

Cabeçalho MPLS
Cabeçalho MPLSRosen et al. (2001)

Como notado na figura 2, o cabeçalho MPLS é formado por 32 bits, contém o campo label (20 bits), o campo EXP (experimental, 3 bits), o campo S – stack bit (1 bit) e o campo TTL (time-to-live, 8 bits) que têm as seguintes funções:

  • Label (Rótulo): contém o valor do rótulo MPLS. Como o tamanho é de 20 bits, esse valor pode variar de 0 a (220 -1), ou 1.048.575. Existem alguns valores que são reservados ao protocolo e têm significados especiais (Rosen et al, 2001b). Veja abaixo tais campos descritos. 
  • 0 – IPv4 Explicit NULL Label: indica que o rótulo deve ser retirado, e, desse ponto em diante, o roteamento será feito com base no endereço de rede.        
  • 1 – Router Alert Label: indica que o datagrama deve ser analisado pelo software local. O encaminhamento seguinte é definido pelo próximo rótulo da pilha MPLS.
  • 2 – IPv6 Explicit NULL Label: mesma funcionalidade do valor 0, mas aplicada ao protocolo IPv6.
     
  • 3 – Implicit NULL Label: valor utilizado pelos LSRs (Label Switch Routers) para a distribuição de rótulos (LDP – Label Distribution Protocol).
  • 4 a 15 – Reservados para definições futuras.
  • 16 a (220 -1) – Rótulos utilizáveis para roteamento.                
  • O campo EXP (experimental) destina-se ao suporte de QoS.
  • O Stack bit é usado para indicar, em label stack, qual é o bottom label (bit stack = 1). Os demais labels de níveis superiores, inclusive o top label, tem o bit stack zerado.
  • O campo TTL (time-to-live), a exemplo do que ocorre em redes IP, destina-se há detecção de looping na rede MPLS. 

Arquitetura MPLS

Conforme Mendonça, Lins e Oliveira (2012, p. 32), por se tratar de uma ligação entre as camadas 2 e 3, já que o MPLS utiliza o sistema de endereçamento dos protocolos de nível 3 e o sistema de comutação da camada 2, o MPLS pode ser considerado um protocolo de camada 2,5 (Harnedy, 2002).

Assim, por ser uma camada de integração, é necessário que esta seja compatível com diversos protocolos da camada 3, assim como tecnologias de camada 2, o que justifica o “MultiProtocol” do MPLS.

É possível separar o plano de controle do plano de encaminhamento na tecnologia MPLS, conforme Figura 3, podendo, dessa forma, tratar os planos

separadamente. Devido a essa característica, caso se deseje mudar a estratégia de roteamento na rede, não será necessário mudar os dispositivos de encaminhamento. O plano precisa reagir quando houver mudanças na rede, mas não é envolvido no processamento individual dos pacotes. No plano de controle é construída e mantida a tabela de encaminhamento do nó em uso. É nesse plano que estão localizadas as funções de controle, tais como sinalização, roteamento, policiamento de tráfego, conversão de endereços, dentre outras. Os protocolos de roteamento, tais como RIP, OSPF, IS-IS e BGP, atuam nesse plano e são usados para trocar informações de roteamento entre os componentes de controle. Já o plano de encaminhamento, que tem sua operação ditada pelo plano de controle, é responsável pelo encaminhamento do tráfego baseado apenas em rótulos. Em resumo, o que os roteadores da rede MPLS fazem é utilizar o plano de controle para, através de um protocolo de roteamento, descobrir e escolher os melhores caminhos até o destino.

Componentes de controle/encaminhamento
Componentes de controle/encaminhamentoINE (2010)

Componentes e Terminologia em Redes MPLS

LSR – Label Switch Router

Um Label Switch Router (LSR) é um roteador que suporta MPLS. É capaz de compreender label MPLS e de receber e transmitir um pacote rotulado em um link de dados. Existem três tipos de LSRs em uma rede MPLS:

  • Ingress LSRs – LSR de entrada recebe um pacote que ainda não foi rotulado, insere um rótulo (label) no inicio do pacote. Ghein (2007, p. 29). Segundo (Mendonça, Lins e Oliveira (2012) os ingress LSRs analisam as informações do cabeçalho de rede e associam cada datagrama a uma FEC. Toda FEC tem um rótulo associado que será utilizado no encaminhamento para o próximo nó.
  • Egress LSRs – LSR de saída recebe pacotes rotulados (labeled), remove os rótulos (labels) e os envia ao próximo nó. LSRs de entrada e saída são também conhecidos com Edge LSRs ou LER (Label Edge Router). Ghein (2007, p. 29).
  • Intermediate LSRs – LSR intermediário recebe um pacote rotulado de entrada, realiza uma operação nele, comuta o pacote, ou seja, troca o rotulo e encaminha-o para o próximo nó. Ghein (2007, p. 29), com adaptações.
    Segundo Mendonça, Lins e Oliveira (2012, p. 37) eles oferecem comutação em alta velocidade, sendo este um processo que mais contribui para o ganho de desempenho na utilização do protocolo MPLS, já que não precisam mais analisar cabeçalhos da camada de rede (IP).eles oferecem comutação em alta velocidade, sendo este um processo que mais contribui para o ganho de desempenho na utilização do protocolo MPLS, já que não precisam mais analisar cabeçalhos da camada de rede (IP).

    Observação: No caso de MPLS VPN os LSRs de Entrada (Ingress) e os LSRs de Saída (Egress) também são conhecidos como Edge LSRs, LER (Label Edge Router) ou PE (Provider Edge). Já o LSR de Trânsito (Intermediate) é também conhecido com P (Provider). Mendonça, Lins e Oliveira (2012, p. 37).

Segundo Zhang et al. (2004, p. 446), existem três tipos de operações que podem ser executadas em um pacote recebido pelo LSR:

  • Push (Inserção) – Push, algumas vezes chamado de imposição, é uma operação executada por um LSR para criar ou adicionar um label stack, ou pilha de rótulos, em um pacote. Esta operação é frequentemente executada em um pacote não rotulado ou em um pacote rotulado onde as informações de próximo salto indicam que um novo rotulo ou rótulos poderão ser inseridos. Push é normalmente executado em um LSR de entrada.
  • Pop (Retirada) – Pop é executado quando um pacote rotulado é recebido e as informações de próximo salto indicam que um ou todos rótulos da pilha poderão ser removidos.
  • Swap (Troca) – Quando chega um pacote marcado, o rotulo do topo da pilha é substituído por um outro rótulo. Troca de rotulo (Label Swapping) é normalmente executada em um core LSR. 

Ainda de acordo com Zhang et al. (2004, p. 446), com as três operações descritas acima, quatro caminhos para troca de pacotes estão disponíveis:

  • IP to IP – Um pacote IP de entrada é comutado para um pacote IP de saída. Esse é o roteamento e comutação IP convencional.
  • IP to Label – Um pacote não rotulado recebe um ou mais rótulos (labels) e é encaminhado para um LSR.
  • Label to IP – Um pacote rotulado é retirado a marcação e é entregue o pacote IP convencional.
  • Label to Label – Um label de entrada é trocado (swapped) por outro label de saída ou o label do topo da pilha é retirado e um ou mais labels tornam-se disponíveis para encaminhamento.

FEC – Forwarding Equivalence Class

De acordo com Mendonça, Lins e Oliveira (2012, p. 32), uma FEC consiste em um grupo de pacotes que podem ser tratados de forma equivalente para propósitos de encaminhamento. Como exemplo, um grupo de pacotes cujos endereços de origem e destino são os mesmos. Pacotes de um mesmo fluxo de dados geralmente pertencem à mesma FEC. Uma FEC é representada por um rótulo e cada LSP (Label Switch Path) é associado a uma FEC. Quando um LER (Label Edge Router) recebe um pacote, verifica a qual FEC ele pertence e o encaminha através do LSP correspondente. Portanto, existe uma associação “pacote-rótulo-FEC-LSP”, e esta associação “pacote-FEC” ocorre apenas quando o pacote entra na rede MPLS, proporcionando grande flexibilidade e escalabilidade a este tipo de rede, conforme é exibida na Figura 4.

Associação “pacote-rótulo-FEC-LSP”
Associação "pacote-rótulo-FEC-LSP"Mendonça, Lins e Oliveira (2012, p. 36)

Seguem alguns exemplos de FECs Ghein (2007, p. 31):

  • Pacotes com um endereço IP de destino combinando com um certo prefixo;
  • Pacotes de Multicast pertencentes a um certo grupo;
  • Pacotes com o mesmo tratamento de encaminhamento, baseados no campo IP Precedence ou IP DiffServ Code Point (DSCP).
Forwarding Information Base – FIB

Segundo Mendonça, Lins e Oliveira (2012, p. 35), é uma tabela que controla a decisão de encaminhamento de um roteador. Para todo possível endereço IP de destino, uma pesquisa de prefixo longo é executada pela FIB. Se um endereço é localizado na tabela, o roteador saberá para qual interface de saída deverá enviar o pacote. Se nenhum endereço é localizado, o pacote é descartado. Os conteúdos da FIB refletem o estado atual da topologia IP que cerca o roteador, como determinado pelos protocolos IPs de roteamento, por exemplo, Open Shortest Path First (OSPF) ou Protocolo de Gateway de Borda versão 4 (BGP4)

Label Forwarding Information Base – LFIB

Conforme Mendonça, Lins e Oliveira (2012, p. 35), é uma tabela que indica onde e como encaminhar os pacotes. É criada por equipamentos pertencentes a um domínio MPLS. A LFIB contém uma lista de entradas que consistem de uma subentrada de ingresso e uma ou mais subentradas de egresso, rótulo de saída, interface de saída, componentes de saída de nível de enlace. É baseada nas informações obtidas pelo LSR através da interação com os protocolos de roteamento.

LSP – Label Switched Path

Segundo Ghein (2007, p. 29), um label switched path (LSP) é uma sequencia de LSRs que trocam pacotes rotulados através de uma rede MPLS ou parte dela. Observe a figura 5. 

Basicamente, o LSP é o caminho através da rede MPLS ou parte dela que os pacotes escolhem. O primeiro LSR de um LSP é o LSR de entrada para aquele LSP, enquanto o último LSR do LSP é o LSR de saída. Todos os LSRs entre os LSRs de entrada e saída são os LSRs intermediários.

Segundo Enne (2009, p. 41), esse caminho percorrido pelos pacotes MPLS entre dois LSRs é determinado por um FEC.

Assim, uma FEC determina múltiplos LSPs entre dois LSRs. Existe, contudo, um (ou eventualmente mais de um, no caso de roteamento multi-path) LSP entre um dado par de LSRs, que representa o caminho efetivo a ser percorrido por pacotes MPLS no sentido de uma FEC. Esse caminho ideal é determinado pelos diferentes elementos de FEC aplicáveis no caso.

Um LSP através de uma Rede MPLS
Um LSP através de uma Rede MPLSGhein (2007, p. 30)

LDP – Label Distribution Protocol 

    Segundo Mendonça, Lins e Oliveira (2012, p. 34), com adaptações, o protocolo LDP, definido pela RFC 3036, é o responsável pela distribuição de rótulos para os prefixos IPs em uma rede MPLS. Os rótulos são atribuídos a cada prefixo IGP aprendido na tabela de rotas global de um roteador. Todos os prefixos anunciados por um mesmo equipamento vizinho recebem o mesmo rótulo. Com isso, os elementos intermediários em uma rede MPLS (elementos conhecidos como P) não precisam conhecer a tabela de roteamento completa da rede. Um pacote IP com rótulo é encaminhado para o próximo enlace (next-hop) baseado somente no rótulo externo, isto é, aquele alocado pelo LDP com base na tabela de roteamento, e isso ocorre até a chegada à rede de destino. Por padrão, o LDP é configurado para formar adjacências somente com seus vizinhos diretamente conectados. Isso é realizado através de um pacote com o endereço de multicast 224.0.0.2 (“all routers”) e TTL igual a 1. Assim que os vizinhos são descobertos inicia-se a troca de rótulos, e as sessões são mantidas através de “Hellos” periódicos. A perda de três “Hellos” faz com que a sessão seja desfeita. Uma falha direta na interface faz com que a sessão seja excluída imediatamente.

    As conexões formadas pelo LDP utilizam a porta UDP 646 para envio de mensagens LDP Hello e a porta TCP 646 para estabelecer comunicação com o vizinho. Andersson et al. (2007, p. 83).

    Funcionamento do MPLS

    Conforme Mendonça, Lins e Oliveira (2012, p. 38), com adaptações,  abaixo é detalhado como as redes MPLS se comportam. Os pacotes são rotulados assim que entram na rede e são encaminhados apenas com base no conteúdo desses rótulos ao longo do caminho. Os roteadores tomam decisão de encaminhamento com base em tais rótulos, evitando assim o esquema de intenso processo de pesquisa de dados utilizado no roteamento convencional. 

    Segundo (Lobo, 2008) é possível também que, em vez de um único rótulo, o MPLS permita que os pacotes de dados carreguem uma pilha de rótulos, segundo a ordem de que o último rótulo a ser colocado no pacote deverá ser o primeiro a ser retirado. 

    Podemos definir basicamente a operação do MPLS em quatro etapas, vide a Figura 6. A seguir é detalhado como as redes MPLS se comportam. Os pacotes são rotulados assim que entram na rede e são encaminhados apenas com base no conteúdo desses rótulos ao longo do caminho. Os roteadores tomam decisão de encaminhamento com base em tais rótulos, evitando assim o esquema de intenso processo de pesquisa de dados utilizado no roteamento convencional. É possível também que, em vez de um único rótulo, o MPLS permita que os pacotes de dados carreguem uma pilha de rótulos, segundo a ordem de que o último rótulo a ser colocado no pacote deverá ser o primeiro a ser retirado (Lobo, 2008). 

    Abaixo conforme Mendonça, Lins e Oliveira (2012, p. 38) podemos definir basicamente a operação do MPLS em quatro etapas, vide a Figura 7:

    Operação do MPLS
    Operação do MPLSMendonça, Lins e Oliveira (2012, p. 38)

    • Etapa 1 – Construção das tabelas de roteamento. Através dos protocolos de roteamento, tais como OSPF e IS-IS, são construídas as tabelas de roteamento, que irão determinar os melhores caminhos para atingir as redes de destino por toda a rede do provedor. Nesta etapa também há a atuação do protocolo LDP, que irá fazer o mapeamento entre rótulos e IPs de destino. Os rótulos serão atribuídos automaticamente, de acordo com os valores citados no item 2.2.1.
    • Etapa 2 – Ingresso dos pacotes na rede. O roteador de borda (Edge LSR) de ingresso recebe os pacotes que irão entrar na rede, executando serviços de nível 3 e valor agregado, tais como QoS, e em seguida acrescenta o rótulo aos pacotes.
    • Etapa 3 – Encaminhamento dos pacotes na rede. O LSR encaminha pacotes usando o mecanismo de troca de rótulos (Label Swapping). Ao receber o pacote com rótulo, o LSR lê o rótulo, o substitui de acordo com a tabela LFIB e o encaminha, sendo essa ação repetida por todos os roteadores no núcleo do backbone.
    • Etapa 4 – Saída do pacote na rede. O roteador de borda (Edge LSR) de saída remove o rótulo e entrega pacotes IPs.

    Nas Figuras 7, 8 e 9, poderemos acompanhar um exemplo prático de encaminhamento de pacotes baseado em rótulos, de acordo com as etapas citadas. A Figura 7 apresenta um processo de roteamento convencional, onde é exibida a entrada de dois pacotes IPs em uma rede MPLS. Através da atuação de um protocolo de roteamento (OSPF, IS-IS), as informações da rede são propagadas e as tabelas de roteamento são construídas. Por exemplo, podemos observar que, no roteador central, todos os pacotes destinados à rede 192.168 serão enviados pela interface 0 e, para a rede 172.16, serão enviados pela interface 1.

    Construção da tabela de roteamento IP
    Construção da tabela de roteamento IPMendonça, Lins e Oliveira (2012, p. 39)

    Na Figura 8 mostra-se a inserção dos rótulos aos pacotes IPs. Através do protocolo LDP, estas associações são anunciadas para os roteadores vizinhos. Por exemplo, vemos que no roteador central o rótulo de saída para a rede 192.168 terá o valor 9, e o rótulo de saída para a rede 172.16 terá o valor 7. Já os rótulos de entrada para tais redes serão 4 e 5, respectivamente.

    Inserção dos rótulos aos pacotes IP
    Inserção dos rótulos aos pacotes IPMendonça, Lins e Oliveira (2012, p. 40)

    Na Figura 9, vemos que, quando todas as tabelas estão atualizadas, é estabelecido um LSP pelo qual serão encaminhados os pacotes correspondentes a esta FEC. Podemos notar que a inserção e retirada dos rótulos serão feitas pelos Edge LSRs, e que o roteador de trânsito, ou P (Provider), fará a troca dos rótulos.

    Pacotes encaminhados baseados nos rótulos
    Pacotes encaminhados baseados nos rótulosMendonça, Lins e Oliveira (2012, p. 40)

    Ainda, de acordo com Mendonça, Lins e Oliveira (2012, p. 38-41), com adaptações, é importante salientar a existência de uma técnica conhecida como PHP (Penultimate Hop Popping) Rosen et al. (2001, p. 18) , que consiste na configuração da retirada do cabeçalho MPLS no penúltimo LSR, e não no LSR de saída. Esta técnica não compromete o funcionamento de um LSP e propicia um ganho de desempenho nos roteadores de borda.Sem o uso desta técnica, ou seja, fazendo a retirada do cabeçalho MPLS no LSR de saída, tem-se duas análises do cabeçalho: a análise do valor do rótulo ao receber o pacote rotulado e a análise do próximo cabeçalho MPLS ou do cabeçalho de rede. Porém, fazendo uso da técnica, se o penúltimo LSR fizer a retirada do rótulo MPLS (popping), em vez de uma troca (swap), apenas uma análise do cabeçalho é realizada. Se for um pacote rotulado, será feita a análise e retirada do cabeçalho MPLS; se for um pacote de rede sem cabeçalho MPLS, será feita a análise das informações do cabeçalho de rede. Portanto, trata-se de uma técnica bastante viável, uma vez que, encaminhado para o LSR de saída, o cabeçalho MPLS não tem mais utilidade, pois será removido e encaminhado segundo informações do cabeçalho de rede ou do próximo cabeçalho MPLS.

    MPLS L3 VPN

    Conforme afirmado por  Kocharians et al. (2015, p. 535), uma das aplicações mais populares do MPLS é chamado MPLS Virtual Private Networks
    (VPN). As VPNs MPLS permitem que um provedor de serviços, ou mesmo uma grande empresa, ofereça serviços de VPN de Camada 3. Em particular, os SP substituem frequentemente os serviços WAN de Camada 2 mais antigos, tais como Frame Relay e ATM por um serviço MPLS VPN. Os serviços MPLS VPN permitem a possibilidade de o SP fornecer uma grande variedade de serviços adicionais aos seus clientes, porque as VPN MPLS sabem a localização dos endereços da camada 3 dos clientes. Além disso, as VPNs MPLS ainda podem fornecer a privacidade inerente aos serviços WAN de Camada 2.

    As VPNs MPLS utilizam encaminhamento IP/MPLS unicast dentro da rede do SP, com recursos MPLS adicionais na borda entre o provedor e o cliente. Além disso, MPLS VPNs usam MP-BGP para superar alguns dos desafios ao conectar uma rede IP a um grande número de clientes IP interligados – problemas que incluem a questão de lidar com espaços de endereços IP duplicados com muitos clientes.

    Conceitos – VPN

    Virtual Private Network (VPN), demonstrada na figura 11, é uma tecnologia que
    permite que uma rede privada se estenda por uma rede pública, normalmente a
    Internet. Ela possibilita que seus usuários troquem informações por redes públicas
    como se estivessem diretamente conectados à uma rede privada (Guimarães et al., 2006)

    Modelo básico de uma VPNModelo básico de uma VPNFilho e Moreira (2016, p. 10)

    Para prover uma conexão segura e privada, VPNs utilizam protocolos de
    tunelamento e encriptação para garantir apenas acessos autenticados. Estes
    protocolos permitem que qualquer tipo de dado trafegado possa ser encapsulado em
    pacotes IP e transferido através de uma rede que não suporte algum protocolo em
    particular, como por exemplo, transmitir pacotes IPv6 numa rede que suporta apenas
    IPv4.
    Técnicas de encriptação garantem que somente pessoas autorizadas consigam
    compreender o conteúdo da mensagem, mesmo que ela seja interceptada,
    proporcionando privacidade da informação trafegada. 

    Tipos de VPN

    Há vários tipos de redes privadas virtuais, das quais pode-se destacar:

    • VPN Intranet: utilizada, por exemplo, para facilitar a comunicação entre
      diferentes sites de uma empresa; ver Figura 11.

    VPN – Intranet
    VPN - IntranetMendonça, Lins e Oliveira (2012, p. 45)

    • VPN Extranet: utilizada para conectar uma empresa a seus fornecedores,
      clientes, etc., conforme ilustrado na Figura 12.

    VPN Extranet
    VPN ExtranetMendonça, Lins e Oliveira (2012, p. 45)

    • VPN de Acesso Remoto: utilizada para conectar uma empresa a seus
      empregados que estejam fisicamente distantes. Neste caso, a estação
      remota disca para o provedor de acesso, conectando-se à Internet, e
      o software de VPN cria uma rede virtual privada entre o usuário remoto
      e o servidor de VPN corporativo através da Internet, conforme
      Figura 13.

    VPN de Acesso Remoto
    VPN de Acesso RemotoMendonça, Lins e Oliveira (2012, p. 46)

    Modelos de VPN

    A topologia de uma VPN pode ser classificada em
    um de dois modelos: Overlay e Peer-to-Peer. 

    O modelo
    Overlay, permite ao provedor do serviço a
    interconexão de múltiplas localidades através de sua
    rede WAN (wide area network), que aparece como
    “privativa” para o usuário. Um roteador em cada
    localidade estabelece conectividade com pelo menos um
    outro roteador de outra localidade através de um
    protocolo interno (IGP). As VPNs Frame Relay, ATM e
    IPSec são exemplos desse modelo.

    Segundo Boava e Iano (2010, p. 72) no modelo Peer-to-Peer, o roteador de borda
    (PE) do provedor troca informação de roteamento com
    o roteador do usuário (CE), que então não mais requer o
    estabelecimento de conectividade com cada roteador de
    outras localidades. Este modelo é mais simples porque
    os roteadores do provedor têm o conhecimento da
    topologia de rede do cliente tornando mais simples o
    trabalho de incorporação de novas localidades numa
    rede full mesh, em comparação com aquele demandado
    em redes overlay. As VPNs BGP MPLS são exemplos do
    modelo Peer-to-Peer. 

    Arquitetura MPLS L3 VPN

    Componentes MPLS L3 VPN

    É importante se familiarizar com a terminologia relativa à VPN MPLS. Consulte a Figura 14 para obter uma visão geral esquemática dos componentes de uma MPLS VPN. Um Service Provider fornece uma infra-estrutura pública comum para que todos clientes utilizem.

    Componentes VPN MPLS
    Componentes VPN MPLSGhein (2007, p. 174)

    Atentando-se para os seguintes componentes presentes em uma arquitetura MPLS detalhados abaixo:

    • CE (Customer Edge) – Um roteador que não tem conhecimento de protocolos MPLS e não envia labels, mas está diretamente conectado a um LSR (PE) na Rede MPLS. Da perspectiva do roteador do cliente (CE), apenas atualizações de rotas e
      dados são encaminhados para o roteador de entrada do provedor (PE). Nesse roteador
      do cliente não é necessária qualquer alteração das configurações da VPN,
      e sim apenas habilitar um protocolo de roteamento ou efetuar um roteamento
      estático para que troque informações com o PE.
    • PE (Provider Edge) – Um LSR que compartilha um link com pelo menos um roteador CE, proporcionando assim uma função específica para a borda da VPN MPLS, incluindo as tabelas BGP (iBGP) e VRF (Virtual Routing Forward) internas.
    • P (Provider) – Um LSR que não tem um link direto para um roteador CE, que permite o roteador apenas encaminhe labels e permite que o LSR ignore as rotas de VPNs dos clientes.

    Portanto, dada as funções de cada componente em uma VPN MPLS, permite-se concluir que é possível uma total separação das redes VPNs dos
    clientes. Essa divisão se dá pela separação de tabelas de roteamento, plano de
    endereçamentos e tráfego. Logo, as VPNs de dois clientes distintos A e B podem
    possuir planos de endereçamento idênticos, cada um com sua própria tabela de
    roteamento e de modo que seus tráfegos jamais se misturem. (Kocharians et al., 2015, p. 537, com adaptações)

    MPLS VPN Control Plane

    O plano de controle (Control Plane) VPN MPLS define protocolos e mecanismos para superar os problemas criados pela sobreposição de espaços de endereços IP de clientes, enquanto incrementa mecanismos para adicionar mais funcionalidade a uma VPN MPLS, particularmente em comparação com os serviços WAN de Camada 2 tradicionais. Para entender a mecânica, é necessário um bom entendimento de alguns mecanismos utilizados pelos roteadores PEs, que são: VRF (Virtual Routing and Forwarding table) RD (Route Distinguisher), RT (Route Targets) e MP-BGP (MultiProtocol Border Gateway Protocol).

    • VRF (Virtual Routing and Forwarding table), conforme mencionado no tópico anterior, é possível a separação do plano de endereçamento e trafego de diferentes clientes em uma MPLS VPN, tal feito é alcançado através do conceito de VRF. Tal conceito permite que múltiplas instâncias da tabela de roteamento coexistam no mesmo roteador simultaneamente. Com VRF, podemos separar um mesmo roteador em diversos roteadores lógicos onde cada interface trabalha com uma tabela de roteamento diferente. Desse modo, é possível que rotas idênticas possam ser encaminhadas para endereços distintos baseados em tabelas de roteamento configuradas separadamente para cada VRF.
    • MP-BGP (MultiProtocol Border Gateway Protocol), MPLS lida com o problema de sobreposição de prefixos adicionando outro número na frente da dos prefixos BGPs IPV4. Cada número diferente pode representar um cliente diferente, tornando os valores de IPV4 únicos. Para fazer isso, MPLS tirou proveito de uma RFC para o BGP, chamado MP-BGP (RFC 4760), que permite a redefinição do campo NLRI (Network Layer Reachability Information)  em atualizações BGP. Essa redefinição permite que um número adicional de comprimento variável, chamado  address family , seja adicionado à frente do prefixo.
    • RD (Route Distinguisher), MPLS RFC 4364, “Redes Privadas Virtuais IP (VPNs) IP BGP / MPLS”, define um tipo específico de address familly para suporte IPV4 MPLS VPN, ou seja, no MP-BGP address familly, chamado Route Distringuisher (RD). O RD é um identificador único de 64 bits que é inserido na frente do IPv4, portanto sendo único dentro do backbone MPLS. A combinação dos endereçamentos IPv4 e esses identificadores de rotas fazem com que as rotas IPv4 sejam únicas através da rede VPN MPLS; dessa forma é possível aos clientes de diferentes VPNs o uso dos mesmos endereços privados.
    • RT (Route Target), é um atributo que indica uma coleção de VRFs pelo qual um roteador PE irá distribuir as rotas, ou seja, ele indica quais rotas devem ser importadas e exportadas pelo MP-BGP, permitindo assim que possa haver conversação entre diferentes VRFs e que também possam ser feitas restrições de importação e exportação de rotas. Os identificadores RT são implementados usando comunidades estendidas do BGP, logo, quando uma rota VPN aprendida de um CE é injetada no VPNv4 BGP, uma lista de VPN route targets é utilizada na identificação de um membro VPN e é associada com cada VRF.

    CEF – Cisco

    Conforme Filho e Moreira (2016, p. 20-21) Cisco Express Forwarding (CEF) é uma tecnologia de camada 3 para comutação de pacotes IP usada majoritariamente em redes de grande escala para melhorar a performance de modo geral em redes CISCO [CISCO SYSTEMS, 2016]. CEF é utilizado para aumentar a velocidade na comutação de pacotes reduzindo a sobrecarga e delays que outras técnicas de roteamento apresentam. Ele possui uma tabela chamada Forwarding Information Base (FIB) similar à de tabela roteamento da maioria dos protocolos de roteamento que mantém apenas o próximo passo para cada endereço IP. Outro componente do protocolo é a tabela de adjacências, que mantém informações de camada 2 para cada entrada na tabela FIB, evitando a necessidade de mais buscas mais custosas.

    Para o funcionamento de MPLS nos roteadores Cisco, é necessário que o CEF esteja habilitado e devidamente configurado. CEF permite que o encaminhamento de dados requeridos para o funcionamento da rede MPLS seja feito de forma correta. Isso não significa que CEF é necessário para o funcionamento de MPLS ou que funcione apenas em roteadores Cisco. Outros vendedores disponibilizam seus próprios protocolos análogos que permitem comutação na camada 3 ou o roteamento é feito no próprio hardware do dispositivo, mas no caso específico entre equipamentos CISCO, se faz necessária sua utilização.

    LAboratório

    Objetivo

    Como já mencionado, o intuito deste trabalho é demonstrar o funcionamento da tecnologia MPLS L3 VPN aplicada a um SP. Como instrumento de simulação, será utilizado a ferramenta UNETLAB, que se trata de um Emulador de Redes gratuito, que permite integrar soluções de dezenas de fabricantes diferentes num mesmo ambiente virtualizado e também é possível utiliza-lo para trabalho simulando um ambiente de produção e homologação.

    A partir dos conceitos reunidos ao longo de todo o trabalho, o presente laboratório tem como finalidade a simulação de um backbone relativo a um SP. Através deste, elucidar a transmissão de tráfego de dois clientes diferentes, sendo aplicado o uso de VRF’s, onde seus espaços de endereçamento IP estariam em VRF’s distintas. O roteamento interno do backbone foi projetado através do protocolo OSPF, sincronizado com LDP, este utilizado para a distribuição dos labels. Para a transmissão das tabelas pertencentes as VRF’s distintas, foi utilizado o MP-BGP para a comunicação entre os PE’s, roteadores de borda do backbone, visível apenas por estes e não pelos outros roteadores que transportam MPLS, P’s (Providers), onde este é um protocolo de camada inferior.

    A topologia é constituída por dois clientes diferentes, denominados Cliente A e Cliente B, onde seus dados são transmitidos via VPNs layer 3 e tem seu roteadores de borda (CE’s) conectados ao backbone em pontos diferentes por meio de um roteador em comum (PE). Tal cenário, possibilita que os roteadores clientes, possam estar localizados em áreas geográficas diferentes, como bairros, cidades e até estados. Neste laboratório foram utilizados 4 CE’s, onde cada cliente é representado por dois roteadores. O Cliente A, possui sua matriz no Rio de Janeiro e uma filial em Macaé. O cliente B possui matriz em Niterói e filial em São Paulo. 

    A comunicação entre o backbone e CE’s de cada cliente foi realizada por meio do protocolo BGP.

    Segundo Mendonça, Lins e Oliveira (2012, p. 138) entre SP, o BGP é adotado para o roteamento entre
    CE e PE, pois oferece inúmeros benefícios, tais como: 

    • A redução do overhead, a manutenção do roteador PE e as configurações

    são simplificadas.

    • A redistribuição entre protocolos de roteamento não é necessária se as

    rotas são aprendidas por meio do BGP.

    Lembra-se que o roteamento entre CE e PE também pode ser realizado por protocolos IGP, como OSPF e IS-IS.

    Topologia

    A topologia do estudo te como objetivo a reprodução em menor escala do cenário real utilizado em um backbone de um SP (Provedor de Serviço). Com o uso das tecnologias necessárias para a concepção do mesmo.

    MPLS L3 VPN Backbone
    MPLS L3 VPN BackboneFonte Própria

    Implementação do laboratório

    A implementação do experimento foi dividida em 3 partes, demonstradas a seguir para entendimento sequencial e construção de conhecimento passo a passo com os comandos utilizados, afim de facilitar a compreensão e concepção da configuração dos elementos pertencentes a um backbone real. São eles:

    • Implementação do CORE MPLS no backbone: nesta fase é configurado o roteamento IGP, necessário para formar as conexões ponto a ponto entre os elementos do backbone e divulgação das interfaces loopback (Rede gerência) e MPLS LDP, onde serão trocados os labels pelo CORE MPLS.
    • Implementação de roteamento MP-iBGP entre os PEs, onde será criado o túnel VPNv4, que possibilitará a comunicação entre os clientes, através do backbone.
    • Implementação do Clientes no backbone: ativação do BGP entre CE-PE e criação da VRFs.

    Por uma convenção de boas práticas, é recomendado para o endereçamento
    de redes ponto a ponto, a utilização de mascaras /30, onde utiliza-se o minimo de
    endereços IPv4, evitando assim desperdício.

    Para efeitos didáticos e uma melhor compreensão do plano de
    endereçamento dos roteadores, foi definido a utilização de redes 10.1.X.X/24 como
    padrão, onde: 

    1º octeto = 10

    2º octeto = 1

    3º octeto = definido do menor roteador para maior, como por exemplo:
    ligação entre CE-R1 e PE-R3, fica definido por 13, entre P-R4 e PE-R7, definido por 47 e assim por diante. 

    4º octeto = definido pelo número do próprio roteador, ou seja, P-R5 = 5,
    CE-R8 = 8. 

    Diante disto, uma conexão entre PE-R3 e P-R6 será identificada da
    seguinte forma: 10.1.36.0/24, onde PE-R3 = 10.1.36.3 e P-R6 = 10.1.36.6/24.

    Equipamentos utilizados

    Todos os roteadores do laboratório são emulações de CISCOs C3725 –
    versão de software c3725-124-25d. Este roteador da série 3700 foi escolhido por
    possuir um consumo médio de 128MBs de memória RAM por instância emulada, o
    que garantiu a possibilidade de criar 9 roteadores com tranquilidade em uma máquina
    com 16GB de RAM, e por suportar todos os protocolos mencionados nos capítulos
    anteriores.

    Implementação do Core MPLS

    Inicia-se a concepção do backbone MPLS pela implementação do Core MPLS, descrita nos passos abaixo.

    Plano de endereçamento
    Redes ponto a ponto – Backbone

    FunçãoEquipamentoInterfaceIP FunçãoEquipamentoInterfaceIP
    PR4fa0/0 10.1.45.4/24  >P R5fa0/0 10.1.45.5/24
    P R5fa1/0  10.1.56.5/24 >P R6fa0/0 10.1.56.6/24
    PR4fa1/0 10.1.34.4/24 > PE R3 fa0/0 10.1.34.3/24
    PR4fa2/0  10.1.47.4/24 > PE R7 fa0/0 10.1.47.7/24
    P R6 fa1/0 10.1.36.6/24 > PE R3 fa1/0 10.1.36.6/24
     P R6fa2/0 10.1.67.6/24 >PE R7 fa1/0 10.1.67.7/24

    Fonte Própria

    Os endereços IP utilizados para identificar os roteadores no processo de roteamento, podem ser identificados na tabela 2.

    Rede Gerencia – Backbone

    IPInterfaceEquipamento
    3.3.3.3Loopback10PE-R3
     4.4.4.4Loopback10P-R4
     5.5.5.5Loopback10P-R5
     6.6.6.6Loopback10 P-R6
     7.7.7.7Loopback10 PE-R7

    Fonte Própria

    Core MPLS
    Core MPLSFonte Própria

    Configuração do Core MPLS

    A seguir serão realizadas as configurações no PE-R3 que visão a integração entre MPLS/LDP e OSPF, estas também feitas de forma análoga no PE-R7, seu objetivo é preparar o roteamento do backbone central, vide figura 16, e a MPLS Cloud, utilizada no resto do laboratório. As configurações feitas nos PEs também devem ser aplicadas nos P’s R4-R5-R6.

    • Habilitando interfaces loopbacks

    Abaixo é criada a interface lookpack (interface virtual) em PE-R3, para fins de conectividade. Todos os IPs de loopback são /32 (255.255.255.255).

    A criação de interfaces loopback na topologia tem duas finalidades:

    • Endereços que identifiquem exclusivamente os roteadores.
    • Usadas para identificar propriedades específicas de alguns protocolos.

    Entrar no modo de configuração global com o comando configure terminal, ao inserir o comando interface loopback [nº da interface], a mesma será criada e por se tratar de uma interface lógica, seu estado estará up (operacional), após isto, adicionar o ip da interface com o comando ip address [endereço ip] + mascara, ao término, executar o comando exit:

    PE-R3(config)#interface loopback 10

    PE-R3(config-if)#

    *Jul 28 17:50:00.984: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback10, changed state to up

    PE-R3(config-if)#

    PE-R3(config-if)#ip add 3.3.3.3 255.255.255.255

    PE-R3(config-if)#exit

    • Configuração do LDP/MPLS

    No modo de configuração global, habilitar o ldp com o comando mpls label protocol ldp, a seguir especificar o router id com mpls ldp router-id loopback 10
    .

    PE-R3(config)#mpls label protocol ldp 

    PE-R3(config)#

    PE-R3(config)#mpls ldp router-id loopback 10

    PE-R3(config)#

    PE-R3(config)#exit

    A especificação do router id é a identificação unica do roteador dentro da nuvem MPLS.

    Caso não seja definido de forma explícita, o roteador escolhe uma interface conforme documentação da CISCO. 

    Escolhe-se preferencialmente o maior IP de loopback. Na ausência de um deste tipo, é escolhido o maior IP operacional no roteador

    Esta configuração é válida para todos os roteadores pertencentes à nuvem MPLS.

    • Habilitando CEF

    Conforme mencionado no tópico 2.3.5, seu uso é necessário em equipamentos Cisco.

    Para habilitá-lo basta inserir o comando ip cef:


    PE-R3(config)#ip cef

    PE-R3(config)#exit


    • Definindo intervalos de Labels

    O comando abaixo define intervalos de Label ID para serem utilizados pelo processo MPLS. Este não é obrigatório, porém sua funcionalidade e a organização que trazidas, didaticamente pode facilitar muito a compreensão do funcionamento das trocas de labels feita no Core MPLS.

    Ao inserir o comando mpls label range 300 399, o roteador deixa de escolher de forma randômica a label que será atribuída aos prefixos recebidos pelo PE-R3 e injetados na nuvem MPLS para utilizar as labels definidas no range, exemplificando, para cada rede associada ao PE-R3, será atribuída uma label, se o PE-R3 tiver 6 redes conectada a ele, serão utilizadas as labels 300, 301, 302… 306. Isto facilita o entendimento ao analisar as labels recebidas pelo PE-R7 por exemplo.

    Este comando também se estende a todos os roteadores da nuvem MPLS, exemplo, P-R5, mpls label range 500 599.


    PE-R3(config)#mpls label range ?

      <16-1048575> Minimum label value for dynamic label range

    PE-R3(config)#mpls label range 300 399

    PE-R3(config)#exit


    • Configuração do OSPF na nuvem MPLS

    A seguir, criaremos um processo OSPF (no caso, router ospf 1), afim de configurar o roteamento interno da nuvem MPLS.

    Assim como no MPLS/LDP, há a necessidade de um identificador único no OSPF, que também precisa ser um endereço IPv4, este endereço é denominado router ID, será o IP da interface loopback.


    PE-R3(config)#router ospf 1

    PE-R3(config-router)#router-id 3.3.3.3

    PE-R3(config-router)#

    Antes de habilitar o OSPF em uma interface, será atribuído um IP a esta, conforme Tabela 2, através do comando ip address + IP + mascara.

    PE-R3(config-if)#interface fastEthernet0/0

    PE-R3(config-if)#ip address 10.1.34.3 255.255.255.0

    O OSPF será habilitado apenas nas interfaces que pertencem ao CORE MPLS, através do comando ip ospf + process id + area, dentro da interface.

    PE-R3(config-if)#interface fastEthernet0/0

    PE-R3(config-if)#ip ospf 1 area 0

    Deve-se aplicar o comando a interface loopback.

    PE-R3(config-if)#interface loopback 10

    PE-R3(config-if)#ip ospf 1 area 0 

    PE-R3(config-if)#

    Todos os comandos acima devem ser replicados aos roteadores do CORE MPLS.

    Forma-se então a adjacência OSPF, conforme log abaixo do PE-R3. No caso, entre PE-R3 > P-R4. Vale notar que a adjacência é formada pela interface loopback.

    *Jul 29 03:32:50.593: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on FastEthernet0/0 from LOADING to FULL, Loading Done

    Após as configurações do OSPF na nuvem MPLS e a formação das adjacências entre os roteadores, será habilitado o MPLS propriamente dito na nuvem.

    • Habilitando o MPLS no CORE

    Existem duas maneiras de habilitar o MPLS: pela interface ou pelo protocolo de roteamento, no caso o OSPF.

    • Pela interface: Neste modo, para habilitar MPLS, será necessário inserir o comando em cada interface do roteador pertencente ao CORE, através do comando mpls ip. O que torna uma tarefa repetitiva em casos de habilitá-lo em diversas interfaces. 
    • Pelo protocolo de roteamento: modo mais simples de configuração, neste caso o MPLS só será habilitado nas interfaces em que o protocolo de roteamento foi configurado, através de apenas um comando mpls ldp autoconfig  dentro das configurações do protocolo.

    Para o laboratório, optou-se pela configuração através do protocolo de roteamento, conforme abaixo:

    PE-R3(config)#router ospf 1

    PE-R3(config-router)# 

    PE-R3(config-router)#mpls ldp autoconfig

    PE-R3(config-router)#

    Forma-se então a adjacência LDP, através da interface loopback conforme explicado anteriormente, veja no log do PE-R3 abaixo: 

    *Jul 29 04:02:02.857: %LDP-5-NBRCHG: LDP Neighbor 4.4.4.4:0 (1) is UP

    Implementação de roteamento MP-iBGP entre os PEs

    MP iBGP e VPNv4
    MP iBGP e VPNv4Fonte Própria

    Nesta fase do laboratório, será configurado o roteamento MP-iBGP nos PE1-R3 e PE2-R7, onde posteriormente será formada a VPNv4, após isto, será possível realizar a conexão entre a matriz e filial dos clientes A e B através do backbone.

    Até o fim do laboratório, não serão mais realizadas configurações nos roteadores P-R4, P-R5 e P-R6.

    • Criando relação iBGP entre PE-R3 e PE-R7

    No modo de configuração, habilita-se o BGP com o comando router bgp [AS (Autonomous System)]. 

    Para que o roteador não aceite apenas endereços IPv4 unicast, o comando no bgp default ipv4-unicast é utilizado para preparar o roteador para ser multiprotocolo.
    Ele fará com que o roteador seja orientado à diferentes address-families com VPN
    IPv4.

    Em seguida, utilizar o comando bgp-log-neighbor-changes para perceber
    mudanças de status dos pares BGP no ato na implementação do experimento e resolução de problemas ao decorrer do mesmo.

    Após, fechar a relação de peer entre os PEs através dos comandos neighbor [IP interface loopback do roteador remoto], remote-as  [AS neighbor] e neighbor   [IP interface loopback do roteador remoto], update-source  [loopback do roteador].

    IP da Interface loopback do roteador remoto é usado como referência para permitir que ele
    reconheça e converse BGP com o roteador PE-R3, desde que seja configurado o mesmo AS nos dois roteadores. 

    Seu uso também é recomendado, pois existem duas conexões físicas que ligam ao backbone, sendo indiferente por qual interface física trafegarão os pacotes, já que a vizinhança será estabelecida pela loopback.

    O comando update-source faz menção à interface loopback de PE-R3, que é a
    interface que reconhecerá estas mudanças.

    PE-R3(config)#router bgp 100

    PE-R3(config-router)#

    PE-R3(config-router)#no bgp default ipv4-unicast

    PE-R3(config-router)#

    PE-R3(config-router)#bgp log-neighbor-changes

    PE-R3(config-router)#

    PE-R3(config-router)#neighbor 7.7.7.7 remote-as 100 

    PE-R3(config-router)#

    PE-R3(config-router)#neighbor 7.7.7.7 update-source lo10

    PE-R3(config-router)#

    • Configuração address familly IPv4 

    Para habilitar address-famillies e configurar uma
    sessão de roteamento usando explicitamente endereços com prefixos IPv4 padrão, inserir o comando address-family ipv4 unicast

    A relação de vizinhança é provida pelo comando neighbor 7.7.7.7 activate,
    o roteador PE-R7 precisará somente reconhecer a vizinhança com o mesmo comando.

    Segundo MendonçaLins e Oliveira (2012p. 137)  o comando next-hop-self é utilizado quando o provedor tem
    um roteamento eBGP com o cliente, porque a sessão internal BGP (iBGP) preserva o atributo next-hop aprendido do par eBGP. Nesse caso, se o “next-hop-self” não for utilizado, a rota BGP ficará inalcançável.

     

    PE-R3(config-router)#

    PE-R3(config-router)#address-family ipv4 unicast

    PE-R3(config-router-af)#

    PE-R3(config-router-af)#neighbor 7.7.7.7 activate 

    PE-R3(config-router-af)#

    PE-R3(config-router-af)#neighbor 7.7.7.7 next-hop-self

    • Configuração BGP VPNv4

    A criação do tunel BGP VPNv4, é feita dentro de uma address family, com o comando address-family vpnv4, em seguida a ativação da vizinhança também é necessário neste caso. Lembrando que é obrigatório  estar dentro do processo BGP.

    O comando neighbor 7.7.7.7 send-community both define o envio tanto de
    communities standard e extended serão enviadas pelo MPBGP.

    PE-R3(config-router-af)#router bgp 100

    PE-R3(config-router-af)#

    PE-R3(config-router)#address-family vpnv4

    PE-R3(config-router-af)#

    PE-R3(config-router-af)#neighbor 7.7.7.7 activate

    PE-R3(config-router-af)#

    PE-R3(config-router-af)#neighbor 7.7.7.7 send-community both

    PE-R3(config-router-af)#

    Implementação dos Clientes no backbone

    Plano de endereçamento

    A seguir na tabela 3 o endereçamento redes ponto à ponto dos clientes, esta segue o mesmo conceito didático utilizado no endereçamento do backbone, explicado acima.

    Redes ponto a ponto – Clientes

    FunçãoEquipamentoInterfaceIP FunçãoEquipamentoInterfaceIP
    PER3 fa2/0 10.1.13.3/24> CE R1 fa0/0 10.1.13.1/24
     PE R3fa3/0 10.1.23.3/24> CER2 fa0/0 10.1.23.2/24
     PE R7 fa2/010.1.78.7/24 > CE R8 fa0/0 10.1.78.8/24
     PE R7 fa3/010.1.79.7/27 > CE R9 fa0/0 10.1.79.9/24

    Fonte Própria

    Abaixo as redes internas dos clientes foram simuladas utilizando as interfaces loopback, vide tabela 4.

    Redes internas clientes

    EquipamentoInterfaceRedeClienteLocalização
    CE1-R1fa0/0 172.16.1.0/24Cliente ARio de Janeiro
    CE2-R2fa0/0172.16.2.0/24Cliente AMacaé
    CE3-R8fa0/0172.16.1.0/24Cliente BNiterói
    CE4-R9fa0/0172.16.2.0/24Cliente BSão Paulo

    Fonte Própria

    Ativação Cliente A
    Ativação Cliente AFonte Própria

    Configuração dos clientes no backbone

    Feita a configuração do tunel BGP VPNv4, está finalizada a parte interna do backbone, restando a última fase da implementação que é a ativação dos cliente, sendo necessário apenas a criação das sessões BGP  e a criação das VRFs.

    Como a conexão entre ambos clientes e o backbone é feita através do protocolo BGP, mais precisamente por eBGP, os passos a seguir é aplicável aos dois clientes, salvo suas peculiaridades. Toma-se como exemplo as configurações aplicadas para o Cliente A, vide figura 18.

    Os passos abaixo devem ser realizados em todos os PEs e CEs da rede, atentando para os atributos específicos de cada cliente.

    • Configuração das VRFs – Virtual Routing and Forwarding 

    A configuração das VRFs é realizada apenas nos PEs. Sua configuração é bem simples. Como exemplo, veja a configuração do PE-R7.

    No modo de configuração global aplicar o comando vrf definition [nome da VRF], a seguir configura-se o route distinguisher (RD)explicado no tópico 2.3.4.2, ele adiciona um identificar único as redes, obtendo-se assim a possibilidade de redes iguais trafegarem no mesmo backbone, sua composição é ASN:nn, IP-address:nn, ou seja, pode-se utilizar o AS + numero identificador ou IP + numero identificador. No laboratório, foi utilizado como identificador do cliente A 100:1 e para o cliente B 200:1

    PE-R3(config)#vrf definition Cliente-A 

    PE-R3(config-vrf)#

    PE-R3(config-vrf)#rd

    PE-R3(config-vrf)#rd ?

      ASN:nn or IP-address:nn VPN Route Distinguisher

    PE-R3(config-vrf)#rd 100:1

    A seguir configurar o route target (RT), também explicado no tópico 2.3.4.2, ele indica quais rotas devem ser importadas e exportadas pelo MP-BGP, permitindo assim que possa haver conversação entre diferentes VRFs e que também possam ser feitas restrições de importação e exportação de rotas. O formato de um RT é o mesmo aplicado ao RD. Este é habilitado dentro da address family IPv4. 

    Ao emitir o comando route target nota-se a existência de variações utilizadas para compreender a troca  de informações entre VRFs. 

    O complemento export define que rotas contidas nesta VRF serão exportadas  com um RT de 100:1 (Cliente A). 

    O complemento import faz o inverso, aprende as rotas de VRFs que são  exportadas também com RT 100:1 (Cliente A). 

    O complemento both pode ser usado caso o desejado seja utilizar os dois complementos com os mesmos parâmetros.


    PE-R3(config)#vrf definition Cliente-A

    PE-R3(config-vrf)#

    PE-R3(config-vrf)#address-family ipv4 

    PE-R3(config-vrf-af)#

    PE-R3(config-vrf-af)#route-target ?

      ASN:nn or IP-address:nn     Target VPN Extended Community

      both         Both import and export Target-VPN community

      export      Export Target-VPN community

      import      Import Target-VPN community

    PE-R3(config-vrf-af)#route-target both 100:1 


    Feito isto, associar a VRF a interface que faz a ligação com o cliente. Para tal, deve-se emitir o comando vrf forwarding [nome VRF] dentro da interface desejada. 

    PE-R3(config)#interface fa2/0

    PE-R3(config-if)#

    PE-R3(config-if)#vrf forwarding Cliente-A


    • Criando a Rede Interna do Cliente A

    Devido ao fato de ser configurado apenas o BGP no CE-R1 e existir apenas uma interface física ligando ao backbone, optou-se pela utilização da interface loopback para simular a rede interna do Cliente A. Isto também se aplica ao Cliente B. Para isto basta apenas configurar uma interface loopback com o endereço da rede do cliente. A rede é definida pela mascara utilizada, no caso um /24.

    CE-R1(config)#interface loopback 0

    CE-R1(config-if)#ip address 172.16.1.1 255.255.255.0

    • Configurando BGP no cliente

    No CE-R1, configurar a interface que fará comunicação com o PE1-R3 com endereçamento IP conforme definido na tabela 3 anteriormente, com intuito de preparar a configuração de eBGP.

    CE-R1(config)#int fastEthernet 0/0

    CE-R1(config-if)#

    CE-R1(config-if)#ip address 10.1.13.1 255.255.255.0

    CE-R1(config-if)#

    CE-R1(config-if)#no shut

     

    Ainda no CE-R1, criar o processo eBGP (interligação de ASes diferentes) com o comando router bgp [AS], no laboratório definido 65001, após isto, especificar o vizinho, com o comando neighbor [IP neighbor] remote-as [AS neighbor], neste caso, será utilizado o ip da interface fisica do proximo salto (PE-R3), pois existe apenas uma conexão entre ambos e não a interface loopback, onde seria necessária se houvesse uma redundância. 

    CE-R1(config)#router bgp 65001

    CE-R1(config-router)#

    CE-R1(config-router)#neighbor 10.1.13.3 remote-as 100

    • Publicando a rede dos clientes no BGP

    A publicação da rede se dá quando o CE divulga a rede no BGP. Toma-se como exemplo o Cliente A. O BGP irá publicar a rede do AS 65001 (CE-R1) para o AS 100 (PE-R3), adiante quando adentrar na nuvem MPLS, esta escolherá o melhor caminho no backbone até PE2-R7, onde irá retirar o AS 100 e publicar no AS 65002 (CE-R8), ao fim, será possível conectividade entre as redes do cliente A. A figura 19 ilustra esse processo.

    Publicação de rotas no BGP
    Publicação de rotas no BGPFonte Própria

    Para publicar a rede no BGP, deve entrar no processo BGP router bgp [AS] e inserir o comando network [rede publicada], [mascara].


    CE-R1(config)#router bgp 65001

    CE-R1(config-router)#network 172.16.1.0 mask 255.255.255.0

    CE-R1(config-router)#

    • Habilitando cliente no backbone

    No PE-R3, configurar a interface que fará comunicação com CE-R1 utilizando o endereçamento IP conforme definido na tabela 3 anteriormente.

    Após a preparação do backbone para receber o cliente, surge a necessidade de associar a VRF criada no PE ao
    BGP, desse modo será estabelecido a relação de peer com o CE.

    Cria-se uma address-family ipv4 vrf CLIENTE-A dentro da configuração global
    do BGP AS 100, definindo esta VRF como aquela que será associada aos consequentes
    comandos de configuração relacionados aos address-families seguintes.
    O comando neighbor [IP neighbor] remote-as [AS] define o AS remoto com o qual
    a VRF se relacionará. Após realizar a ativação do neighbor.

    PE-R3(config-if)#int fa2/0

    PE-R3(config-if)#

    PE-R3(config-if)#ip address 10.1.13.3 255.255.255.0

    PE-R3(config-if)#

    PE-R3(config-if)#no shut

    PE-R3(config-if)#exit

    PE-R3(config)#router bgp 100

    PE-R3(config-router)#

    PE-R3(config-router)#address-family ipv4 vrf Cliente-A

    PE-R3(config-router-af)#

    PE-R3(config-router-af)#neighbor 10.1.13.1 remote-as 65001

    PE-R3(config-router-af)#

    PE-R3(config-router-af)#neighbor 10.1.13.1 activate

    PE-R3(config-router-af)#

    Logo em seguida, observa-se a formação da vizinhança com CE, note que o BGP encontra o neighbor dentro da vpn VRF Cliente-A.

    *Aug 4 04:38:42.183: %BGP-5-ADJCHANGE: neighbor 10.1.13.1 vpn vrf Cliente-A Up

    Análises

    Finalizada a configuração completa do laboratório, entra-se na fase de analise e teste das configurações implementadas.

    Análise do Core MPLS

    Os comandos a seguir, podem ser executados em todos os roteadores pertencentes a nuvem MPLS, como exemplo, as verificações serão feitas a partir do PE-R3.

    Abaixo, vemos na figura 20, as interfaces de PE-R3 que participam do processo MPLS através do comando show mpls interfaces.

    MPLS interfaces
    MPLS interfacesFonte Própria 

    A saída do comando sh mpls ldp neighbor a partir do PE-R3, vide figura 21, mostra a relação de vizinhança formada através do LDP com P-R6 e P-R4, identificada no campo Peer LDP Ident. Sabe-se que se tratam de P-R6 e P-R4, devido ao IP da interface loopback configurada em ambos. 

    Observe o campo TCP connection, nele nota-se que a conexão foi iniciada pelo PE-R3, lembrando que o LDP utiliza a porta TCP 646, conforme explicado no tópico 2.2.3.6, já P-R4 e P-R6 utilizam uma porta randômica.

    Ao final da identificação de cada peer LDP, observe o campo Addresses bound to peer LDP Ident, ele mostra os peers que o neighbor consegue identificar, salientando que são as interfaces que rodam OSPF e que estão dentro do processo MPLS.

    MPLS LDP neighbors
    MPLS LDP neighborsFonte Própria 

    Por fim, para uma visualização ampla referente ao encaminhamento de pacotes na nuvem MPLS , usa-se o comando show mpls forwarding-table, que mostra o conteúdo de toda a Label Forwarding Information Base (LFIB) do roteador. 

    Na LFIB, vê-se os IPs de conversa entre os peers MPLS que não estão conectados diretamente ao PE-R3, porém já foram aprendidos por conta de todo o processo de descoberta demonstrado anteriormente. 

    A ideia é que assim, possam ser encontrados todos os possíveis destinos e caminhos para IPs da nuvem, partindo do PE-R3, e comprovar a eficiência do backbone. Vide a saída do comando na figura 22. 

    Enfatiza-se alguns pontos importantes na saída do comando:

    • Local Label: label local designada pelo roteador
    • Outgoing Label: label informada pelo próximo salto para encaminhamento. Observe que existem informações de Pop Label neste campo, isto significa que o próximo salto advertiu com um implicit null para este destino, caracterizando a operação PHP, explicada no tópico 2.2.4, onde PE-R3 sendo o penúltimo salto antes do destino, as labels param de ser utilizadas. Quando há um número de label neste campo, significa que o destino está a mais de um salto de distancia, ou seja,   demonstra-se ali a label que será a mais externa no próximo salto (Local Tag no próximo) e assim sucessivamente até que os pacotes cheguem em seus destinos.

    A informação No Label será explicada mais adiante na análise referente a conectividade dos clientes.

    LFIB – PE-R3
    LFIB - PE-R3Fonte Própria

    Analise roteamento BGP, VRFs e conectividade fim-a-fim dos Clientes

    A análise abaixo, junto aos comandos emitidos, foram tomados como exemplo o PE-R3, porém são análogos ao PE-R7.

    Observe na figura 23, a saída do comando sh ip bgp vpnv4 all summary, nele pode-se ver a conexões formadas via BGP, tanto por iBGP, quanto eBGP. Note alguns pontos importantes mostrados pelo comando:

    • Neighbor: roteador com quem a vizinhança BGP é formada.
    • AS: AS à qual o neighbor pertence.
    • Up/Down: Tempo referente ao estabelecimento da conexão BGP.
    • State/PfxRcd: indica quantos prefixos ou redes foram recebidos através do neighbor.

    Note que para o neighbor 7.7.7.7, PE-R3 recebeu dois prefixos, referentes aos prefixos aprendidos pelo PE-R7.

    Verificação BGP
    Verificação BGPFonte Própria 

    Abaixo, foram realizadas as verificações referentes as VRFs dos clientes. Observe nas figuras 24 e 25, a saída do comando show vrf detail [VRF], nele obtêm-se informações relevantes como: Interface em que a VRF está habilitada, o RD e as RT utilizadas pelas VRFs.

    VRF Cliente A
    VRF Cliente AFonte Própria 

    VRF Cliente B
    VRF Cliente BFonte Própria 

    Analisando a RIB em PE-R3, nota-se que as redes dos clientes A (172.16.1.0/24) e B (172.16.2.0/24) não foram instaladas na tabela de roteamento. Vide a figura 26.

    RIB – PE-R3
    RIB - PE-R3Fonte Própria 

    Isto acontece propositalmente, em virtude da funcionalidade atribuída pelas VRFs, criam-se duas tabelas de roteamento virtuais, permitindo duas redes iguais trafegando no mesmo meio. Veja na figuras 27 e 28, as tabelas de roteamento criadas para os clientes no PE-R3, após o comando sh ip route vrf [VRF].

    Tabela de Rotas VRF Cliente A
    Tabela de Rotas VRF Cliente AFonte Própria 

    Tabela de Rotas VRF Cliente B
    Tabela de Rotas VRF Cliente BFonte Própria 

    Para testar uma conexão utiliza-se tradicionalmente o comando ping [ip destino]. Veja na figura 29 o teste realizado. Nota-se que não foi possível conectividade, isto acontece, pois, o ping tradicional utiliza informações da tabela de roteamento global do equipamento.

    Teste Ping Sem VRF
    Teste Ping Sem VRFFonte Própria 

    Ao emitir o comando ping acrescido do atributo vrf [VRF], percebe-se que é possível a conectividade, deste modo, o roteador busca informações dentro da tabela de roteamento da VRF informada. Vide a figura 30.

    Teste Ping Com VRF
    Teste Ping Com VRFFonte Própria 

    Ao término, consegue-se conectividade entre as redes do clientes, vide as figuras 31, 32, 33 e 34. Nos roteadores do clientes, não há necessidade de especificar o atributo vrf no teste de ping

    Teste Cliente A – Rio de Janeiro para Macaé
    Teste Cliente A - Rio de Janeiro para MacaéFonte Própria 

    Teste Cliente A – Macaé para Rio de Janeiro
    Teste Cliente A - Macaé para Rio de JaneiroFonte Própria 

    Teste Cliente B – Niterói para São Paulo
    Teste Cliente B - Niterói para São PauloFonte Própria 

    Teste Cliente B – São Paulo para Niterói
    Teste Cliente B - São Paulo para NiteróiFonte Própria 

    Outra ferramente bastante útil é o traceroute, nele obtem-se os saltos do pacote através da rede. Observe a figura 32 com o resultado do traceroute feito no CE-R1 em direção ao CE-R8, estes pertencem ao cliente A. Percebe-se que o pacote faz o caminho PE-R3 > P-R4 > PE-R7 > CE-R8. 

    Traceroute Cliente A – Rio de Janeiro para Macaé
    Traceroute Cliente A - Rio de Janeiro para MacaéFonte Própria 

    Conclusão

    Atualmente, observamos inúmeros exemplos de serviços que trafegam por através de meios físicos comuns, a demanda por soluções cada vez mais eficientes no tratamento de dados com segurança e escalabilidade fica mais evidente. Este trabalho teve o propósito de ilustrar, através de uma exemplo prático, abordando conceitos fundamentais para a implantação de uma solução VPNs de camada 3 por meio de MPLS.

    Ao fim deste estudo, comprovou-se a flexibilidade, escalabilidade, eficiência e segurança quanto a utilização de MPLS aliada ao Multiprotocol BGP na concepção e transporte de VPNs de camada 3. 

    A comutação fornecida pelo MPLS, ao permitir todos os diferentes tipos de encaminhamento (unicast, unicast com tipos de serviço e multicast), é empregada como excelente aliada em pesquisa avançadas referente a engenharia de tráfego e QoS. O experimento concebido no capítulo 4 aplicou conceitos avançados que permitiram a segregação do tráfego de dois clientes distintos através de um meio comum, no caso o backbone, mostrando, assim, que este tipo de solução é viável e possui enormes beneficios relativos à segurança e processamento de dados nos roteadores envolvidos. 

    Como proposta para trabalhos futuros, recomenda-se a simulação de um ambiente com tipos de tráfegos distintos neste backbone, possibilitando a verificação da performance e o comportamento do mesmo, assim como o progresso constante das configurações utilizando maneiras para o desenvolvimento das configurações atuais, tanto na parte relativa ao CORE MPLS do provedor de serviço, quanto nos clientes atendidos.

    O CORE poderia ser subdividido em mais ASs entre os PEs, de modo a se precaver do tráfego originado pelos clientes que se conectam à ele pelos PEs com configurações que escondam o caminho em seu backbone. Por outro lado, os clientes poderiam ter mais subdivisões por meio de roteadores atrás dos seus CEs, utilizando outros protocolos de roteamento para a comunicação entre ambos.

    Poderiam ser aplicadas outras formas de realizar a comunicação entre os PEs e CEs, seja por meio de OSPF ou IS-IS.

    Simular o conceito de peering, adicionando uma conexão com um SP, isto possibilitará a utilização de internet por parte dos clientes, desde modo, outro conceito poderá ser implementado, o BGP free core.

      

    Referências

    AnderssonL. et alRFC 5036: LDP Specification. IETF. 2007. 135 p. Disponível em: <https://tools.ietf.org/html/rfc5036>. Acesso em: 16 Abr. 2017.

    BoavaAdãoIanoYuzo. Conectividade e Segurança na camada de transporte das VPN IP MPLS para as redes NGN. Revista Ciência e Tecnologia, v. 13. Jan./Dez. 2010. 71-76 p.

    Cisco SystemsConfiguring a Basic MPLS VPN. Cisco Systems. 2007. Disponível em: <http://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/13733-mpls-vpn-basic.html>. Acesso em: 11 Jul. 2017.

    ______OSPF Design Guide. Cisco Systems. 2005. Disponível em: <http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/7039-1.html>. Acesso em: 11 Jul. 2017.

    EnneAntônio José FigueiredoTCP/IP sobre MPLS. 1. ed. Rio de Janeiro: Ciência Moderna, 2009. 384 p.

    FilhoCarlos Alberto MoreiraThiago UM ESTUDO DE VPNs LAYER 3 MPLS-BASED UTILIZANDO MULTIPROTOCOL BGP. Rio de Janeiro, 2016. TCC (SISTEMAS DE INFORMAÇÃO)UNIRIO, 2016

    GheinLuc DeMPLS Fundamentals. 1. ed. Indianapolis: Cisco Press, 2007. 651 p.

    GuichardJimPepelnjakIvanApcarJeffMPLS and VPN Architectures. 1. ed. Cisco Press, v. 2, 2003. 504 p.

    GuimarãesAlexandre et alSegurança em Redes Privadas Virtuais – VPNs. 1. ed. Rio de Janeiro: Brasport, 2006.

    INEMPLS Control Plane and Forwarding Plane Interaction. Blog INE. 2010. Disponível em: <http://blog.ine.com/2010/02/28/mpls-control-plane-and-forwarding-plane-interaction/>. Acesso em: 14 Abr. 2017.

    KochariansNarbik et alCCIE Routing and Switching v5.0 : Official Cert Guide. 5. ed. Indianapolis: Cisco Press, v. 2, 2015. 846 p.

    L.Andersson et alLDP Specification. IETF. 2007. 135 p. Disponível em: <https://tools.ietf.org/html/rfc5036>. Acesso em: 5 Ago. 2017.

    LoboLancy MPLS Configuration on Cisco IOS Software. Indianapolis: Cisco Press, 2008.

    MelloGeovanaO MPLS-TP e sua aplicação nas redes de comunicação. São Carlos, 2013. TCC (Engenharia da Computação)UNIVERSIDADE DE SÃO PAULO, 2013

    MendonçaRobertoLinsRafael DueireOliveiraJosé MarioRedes MPLS: Fundamentos e Aplicações. 1. ed. Rio de Janeiro: BRASPORT, v. 1, 2012. 233 p.

    MineiInaLucekJulianMPLS-Enabled Applications: Emerging Developments and New Technologies. 3. ed. Chichester: Wiley, v. 1, 2011. 608 p.

    Rede Nacional de PesquisasRoteamento: O que é Importante Saber. RNP . 1997. Disponível em: <https://memoria.rnp.br/newsgen/9705/n1-1.html#ng-integrated>. Acesso em: 3 Ago. 2017.

    RosenE. et alRFC 3031: Multiprotocol Label Switching Architecture. IETF. 2001. Disponível em: <https://www.ietf.org/rfc/rfc3031.txt>. Acesso em: 14 Abr. 2017.

    RosenE.RekhterY.RFC2547: BGP/MPLS VPNs. IETF. 1999. Disponível em: <https://tools.ietf.org/html/rfc2547>. Acesso em: 25 Mar. 2017.

    Sanchez-MongeAntonioGrzegorz SzarkowiczKrzysztof MPLS in the SDN Era: Interoperable scenarios to make networks scale to new services. 1. ed. California: O`Reilly Media, v. 1, 2015. 920 p.

    StallingsWilliam MPLS: The Internet Protocol Journal – Volume 4, Number 3. Disponível em: <http://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back-issues/table-contents-10/mpls.html>. Acesso em: 25 Mar. 2017.

    TanenbaumAndrewRedes de Computadores. 5. ed. São Paulo: Pearson, 2011.

    ZhangRandy et alBGP Design and Implementation: Practical guidelines for designing and deploying a scalable BGP routing architecture. 1. ed. Indianapolis: Cisco Press, 2004.

    feito

    Use agora o Mettzer em todos
    os seus trabalhos acadêmicos

    Economize 40% do seu tempo de produção científica