Início
VPN em Camada 3
Devido ao crescente número de empresas que dependem da rede de computadores para a troca de informações entre suas filiais, torna-se cada vez mais necessário o uso de uma tecnologia que garanta qualidade e eficiência para esse fim.
O MPLS (Multi Protocol Label Switching) foi desenvolvido como uma solução que funciona em conjunto com o protocolo IP, capaz de transferir pacotes a um ritmo elevado e que possui mecanismos de gestão de recursos que permitem o tratamento diferenciado dos fluxos de tráfego, isolando-os dos demais tráfegos da rede. O crescimento e a importância dessa tecnologia tornam seu estudo em disciplinas de Redes voltado a cursos de Informática, Telecomunicação, Elétrica e Telemática, fundamental para a formação de um bom profissional.
Esta série de tutoriais procura apresentar experiências laboratoriais que permitem compreender, de uma maneira simples, os principais mecanismos de roteamento e entrega dos pacotes em redes virtuais privadas com a tecnologia MPLS, como também comparar com tecnologias tradicionais. As experiências utilizaram o emulador GNS3, que além de poupar espaço físico e tempo, contribuiu para um ambiente versátil que não obrigou o uso de equipamentos físicos, assemelhando-se muito de um modelo real. A possibilidade de estudar tecnologias que trabalham em equipamentos de grande porte, geralmente encontrados em operadoras de serviço, faz com que profissionais da área tenham a capacidade de desenvolver diferentes soluções em redes de computadores sem mesmo de fato portar o equipamento.
Este tutorial parte II apresenta as parte II (configuração do BGP/MPLS VPN) e III (configuração do IPsec em Redes IP) do modelo conceitual, a seguir apresenta a análise comparativa desses modelos, e finalizará com os resultados alcançados.
Redes MPLS II: Introdução
Nos últimos anos, as redes de computadores e telecomunicação sofreram inúmeras transformações. Com os crescentes avanços nas áreas tecnológicas, contribuíram para o desenvolvimento de sistemas de transmissão de dados com alto desempenho. No final dos anos 90, foi introduzida no mercado mundial a tecnologia MPLS (Multi Protocol Label Switching), onde se permitiu controlar a forma com que o tráfego flui através das redes IPs, otimizando o desempenho da rede e também melhorando o uso dos seus recursos.
Em redes IPs tradicionais, o encaminhamento dos pacotes, requer uma pesquisa que compara o endereço de destino do pacote com cada uma das entradas na tabela de roteamento, encaminhando cada um para a saída correspondente. Esse procedimento é repetido a cada nó percorrido ao longo do caminho, da origem ao destino. Isso de fato parece relativamente simples, porém, considerando que cada equipamento processa milhares e as vezes milhões de pacotes por segundo, essa tarefa pode sobrecarregar a rede.
O MPLS é uma tecnologia de encaminhamento de pacotes baseada em rótulos que vem sendo adotado por operadoras para oferecer serviços diferenciados com eficiência nos transportes de dados. Os produtos oferecidos por operadoras baseados em MPLS, permitem disponibilizar não apenas velocidade de conexão, mas também a diferenciação de tráfego como Multimídia (Voz, Vídeo) e aplicações críticas, com garantias aplicáveis de QoS (Quality of Service), através das classes de serviço.
Atualmente o MPLS é um passo fundamental para a escalabilidade da rede, considerado essencial para um novo modelo de Internet no século XXI. MPLS é relativamente jovem, porém vem sendo implantada com êxito em redes de grandes operadoras de serviços em todo mundo.
Nesse trabalho será abordada a utilização de VPN camada 3 em redes MPLS como solução na segmentação de redes e segregação de tráfego, provendo aos assinantes/clientes das operadoras de serviço a interligação de estações distribuídas em uma ampla área geográfica de maneira rápida e seguras.
Objetivos
Os objetivos deste trabalho foram divididos em objetivo geral e objetivos específicos.
O objetivo geral é implementar uma solução de VPN de camada 3 em redes MPLS, utilizando emuladores como ferramenta de teste para demonstrar o desempenho e analise comparativa com outros tipos de redes.
Entre os objetivos específicos, destacam-se:
Abrangência
Propõe-se realizar um projeto de rede onde uma estrutura MPLS será montada, configurada e analisada através do uso de softwares, bem como emuladores de rede, emuladores de Sistemas Operacionais e sniffers.
O simulador de rede usado emula os IOS (Internetwork Operating System) que são os softwares que rodam em roteadores da linha Cisco Systems, sendo que cada equipamento opera como uma máquina real, com acesso a todas as funcionalidades e protocolos, podendo comportar uma topologia de rede ampla em um único computador. Nessa estrutura serão estudadas as formas de roteamento que os backbones (operadoras) usam para comunicar-se com outros backbones e roteadores de assinantes (clientes) – CPE (customer premises equipment), tendo como foco principal do trabalho, mostrar e analisar o desempenho e vantagem da utilização de VPNs de camada 3 em redes MPLS através de nuvem privada.
A nuvem privada é a forma utilizada por operadoras de serviço para interligar vários pontos de uma mesma organização isolando o tráfego da nuvem pública a qual todos têm acesso. As análises serão executadas através da utilização de softwares específicos para o monitoramento de rede, capturando dados e posteriormente a gerando gráficos e relatórios. Assuntos como QoS, Engenharia de Tráfego, VPN de camada 2 e segurança não serão aprofundados, como também não serão implementadas soluções MPLS para a internet pública.
Para esse estudo será utilizado o programa GNS3 versão 0.7.2, um programa gratuito resultado de um projeto open source que pode ser utilizado em diversos sistemas operacionais como Windows, Linux e MacOS X. Com o GNS3 pode-se fazer praticamente tudo o que é possível fazer com roteadores e pix da linha Cisco. O GN3 é um gerenciador gráfico que está ligado diretamente a outros 3 softwares:
Este programa é um emulador e não um simulador, pois utiliza as mesmas imagens binárias dos equipamentos reais, proporcionando assim, num local que já possua estes equipamentos, a possibilidade de testar uma nova versão do IOS antes mesmo de colocá-lo nos equipamentos reais.
A motivação do uso desse software nesse TCC, se deu principalmente por ser gratuito e permitir utilizar os mesmos IOS dos roteadores, criando um ambiente de simulação que se aproxima bastante do ambiente real.
Para virtualização dos sistemas operacionais será utilizado o Virtual Box na versão 3.2.8. Virtual Box é um software de virtualização desenvolvido pela Oracle para arquiteturas de hardware x86 também gratuito, que visa criar ambientes para instalação de sistemas distintos. Ele permite a instalação e utilização de um sistema operacional dentro de outro em pleno funcionamento, assim como seus respectivos softwares, com dois ou mais computadores independentes simultaneamente, compartilhando fisicamente o mesmo hardware.
O sistema operacional que será virtualizado no Virtual Box para gerar o tráfego nos ambientes do GNS3 será o Ubunto na versão 10.4. Ubuntu é um sistema operacional de código aberto mais popular do mundo na atualidade. Desenvolvido para notebooks, desktops e servidores, ele contém todos os aplicativos que qualquer outro sistema operacional tem, em versões similares e livre de licenças.
Para análise do tráfego de rede será utilizado o Wireshark. O é um programa que verifica os pacotes transmitidos pelo dispositivo de comunicação (placa de rede, placa de fax modem, etc.) do computador. O propósito deste tipo de software, também conhecido como sniffer, é detectar problemas de rede, conexões suspeitas, auxiliar no desenvolvimento e resolução de problemas. O programa analisa o tráfego de pacotes recebidos e organiza-os por protocolo. Todo o tráfego de entrada e saída é analisado e exibido em um ambiente gráfico de fácil visualização contribuindo para a explicação dos casos.
Metodologia
Para a realização deste trabalho serão adotados os seguintes procedimentos:
Tutoriais
O tutorial parte I apresentou inicialmente os conceitos sobre Redes de Computadores, e a seguir os conceitos das Redes IP MPLS, e finalizou apresentando a parte I do modelo conceitual utilizado neste trabalho, relativa à configuração básica do MPLS com o protocolo OSPF.
Este tutorial parte II apresenta as parte II (configuração do BGP/MPLS VPN) e III (configuração do IPsec em Redes IP) do modelo conceitual, a seguir apresenta a análise comparativa desses modelos, e finalizará com os resultados alcançados.
Modelo Conceitual 2 – BGP/MPLS VPN
Esta seção continua a apresentação iniciada no tutorial parte I das experiências e implementações que foram realizadas, recorrendo o emulador GNS3, com o objetivo de estudar algumas características fundamentais do MPLS e VPN camada 3 em MPLS.
A fim de facilitar o entendimento, a topologia proposta para análise do trabalho será novamente apresentada conforme foi montada, através da ilustração da figura 1:
Figura 1: Captura da topologia MPLS no GNS3
Fonte: Elaboração do autor, 2010
No cenário acima, os roteadores usados para simular os equipamentos de núcleo “Ps” foram o Cisco 7200 com a versão de IOS c7200-jk9s-mz.124-13b.bin. Para os equipamentos “PEs” foram usados o modelo Cisco 3725 com a versão de IOS c3725-adventerprisek9-mz.124-15.T5.bin. E para os equipamentos de acesso ao cliente “CEs” o modelo Cisco 2691 com a versão de IOS c2691-adventerprisek9_ivs-mz.124-9.T7.bin. A escolha das versões IOS usadas para formar a topologia foi outro fator importante. Cada versão possui características e funcionalidades diferentes, com suporte a um conjunto específico de protocolos.
A escolha dos protocolos envolvidos na topologia, como protocolo de encapsulamento, de roteamento, túneis também foi outro fator determinante. O objetivo foi montar toda a rede usando apenas protocolos não proprietários, ou seja, a mesma topologia poderá ser implementada com roteadores de outros fabricantes.
Já os computadores emulados com o programa Virtual Box, foram usados uma imagem do sistema operacional Ubuntu versão 10.4 para simular uma operação, gerando tráfego pela rede MPLS de um ponto a outro da rede. E a captura das informações foi recorrida ao Wireshark em cada ponto ligado a um par de roteadores.
Em todas as experiências descritas em cada tópico, foram usados os mesmo endereços de IP das interfaces. Os testes e análises serão de maneira separada e sequenciada.
Configuração do BGP/MPLS VPN
Nesse tópico será abordada a constituição de VPNs camada 3 com suporte no MPLS. As configurações a seguir são referentes aos roteadores PEs e CEs conforme visto na Figura 20: Captura da topologia MPLS no GNS3 da seção Modelo Conceitual 1 – MPLS com OSPF do tutorial parte I. Da mesma forma que no caso anterior relatado no tutorial parte I, as configurações foram realizadas com a ajuda do emulador GNS3, dando continuidade ao que já foi implementado.
Figura 2: Captura da topologia BGP/MPLS VPN em análise do GNS3
Fonte: Elaboração do autor, 2010
As configurações nessa seção restringem-se somente aos roteadores PEs e CEs, os roteadores de núcleo Ps não precisarão sofrer qualquer alteração no que já foi implementado, já que sua participação nesse caso é prover o transporte dos pacotes rotulados no MPLS. O procedimento de configuração será mostrado somente nos roteadores CE1 e PE1, tendo em vista que as configurações nos roteadores PE2, CE2, CE3 e CE4, mudaram somente parâmetros de endereçamento IP conforme as tabelas 4 e 5, como também hostname, senhas, e descriptions.
Tabela 1: Relação de endereço IP/interface dos roteadores PEs
Fonte: Elaboração do autor, 2010
Tabela 2: Relação de endereço IP/interface dos roteadores CEs
Fonte: Elaboração do autor, 2010
As configurações realizadas no PE1 seguem a seguinte sequência:
Na sequência dos quadros 1, 2 e 3, pode-se observar que o endereçamento IP das VPNs são iguais, e um não interferirá no outro, devido ao comando ip vrf forward vinculado a cada interface de saída para os roteadores CEs. Em condições normais, sem o uso desse comando, o equipamento acusaria que um mesmo endereço IP já esta em uso em outra interface no equipamento, recusando o comando ip address com endereço IP na mesma faixa. Com o uso das VRFs, uma tabela de roteamento virtual é montada para cada uma das VRFs, dando total independência da tabela de roteamento global do roteador. No quadro 1 mostra a sequência de comandos necessária para disponibilizar o recurso de VPN em MPLS para os roteadores CEs. Em seguida nos quadros 2 e 3, é exibido como ficou as configurações no PE1 e PE, omitindo alguns comandos que por padrão já vem configurado.
Fonte: Elaboração do autor, 2010
Fonte: Elaboração do autor, 2010
Fonte: Elaboração do autor, 2010
Fonte: Elaboração do autor, 2010
Nos quadros 2 e 3, verificou-se como ficou as configurações dos roteadores PE1 e PE2. Essas configurações garantem o acesso isolado dos roteadores CEs, onde o CE1 e CE2 fazem parte da VPN_A e o CE3 e CE4 da VPN_B. Foi observado também que tanto a VPN_A quanto a VPN_B possuem as mesmas características. Elas não precisariam necessariamente ser configuradas com as faixas IPs iguais, mas foram configurados dessa maneira com a intenção de mostrar como uma rede não sobrepõe outra. No quadro 4 o mesmo procedimento foi realizado com os roteadores CEs.
Fonte: Elaboração do autor, 2010
Na configuração do roteador CE1 seguiu a seguinte sequência:
Foi adotado o DHCP (Dynamic Host Configuration Protocol), para dar mais comodidade ao usuário final, já que esse protocolo proporciona a distribuição dinâmica de IPs para a rede, nesse. A mesma configuração foi inserida nos demais roteadores CEs, mudando apenas os parâmetros de endereçamento IP nas interfaces, rotas e no DHCP, conforme a tabela 5. Nos quadros 5, 6, 7 e 8 verificou-se como ficaram as configurações no s CEs.
Fonte: Elaboração do autor, 2010
Fonte: Elaboração do autor, 2010
Fonte: Elaboração do autor, 2010
Fonte: Elaboração do autor, 2010
Como na seção anterior, algumas configurações foram omitidas pelo fato de já virem configuradas por padrão nos equipamentos. Foi exibido o que de fato é necessário para o funcionamento.
Testes e Análise do BGP/MPLS VPNs
Com os roteadores PEs e CEs devidamente configurados, o próximo passo foi verificar o funcionamento e parâmetros relevantes quanto ao funcionamento das VPNs em redes MPLS. Primeiro foi verificado as informações sobre o roteamento nos roteadores PE1 e PE2. No quadro 9 segue as informações obtidas com a saída do comando show ip router no roteador PE1.
Fonte: Elaboração do autor, 2010
Observou-se na saída do comando show ip route, que na tabela de roteamento consta apenas os endereços IPs globais, usados para a comunicação entre os roteadores Ps e PEs. Informações sobre os endereços de IPs usados nas VPNs não são apresentados na saída desse comando. Isso acontece devido a capacidade que o VRF tem em isolar o roteamento usado nas VPNs, dos demais roteamentos do equipamento. Na saída do comando show ip router vrf VPN_A e show ip router VPN_B, essa história muda, apresentando uma nova tabela de roteamento para cada VFR designada conforme os quadros 10 e 11.
Fonte: Elaboração do autor, 2010
Fonte: Elaboração do autor, 2010
As linhas que precedem com “B” indica que para chegar nessa rede será preciso passar pelo BGP. O “S” são as rotas estáticas usadas para o roteamento com os CEs, e o “C” como já foi visto, são as redes diretamente conectadas as interfaces. Informações sobre o roteamento das VPNs pode ser obtido através do comando show ip bgp vpnv4 all, conforme mostrado no quadro abaixo.
Fonte: Elaboração do autor, 2010
Nas informações mostradas no quadro 12, é possível ver todas as saídas das VRFs no BGP, como também a redistribuição para as rotas estáticas usadas paca a comunicação fim a fim dos CEs. Pode-se ver também que as redes que não contém a sigla “i” de internal, são os IPs referentes aos endereço de WAN e LAN dos roteadores CE1 e CE3, que não estão configuradas nos equipamentos PEs, e sim previstas no roteamento estático. No roteador PE2 o mesmo ocorre só que referentes aos endereços de WAN e LAN dos roteadores CE2 e CE4, conforme o quadro 13.
Fonte: Elaboração do autor, 2010
Da mesma forma que o roteador não consegue visualizar os IPs das VPNs na sua tabela de roteamento principal, também não conseguirá receber respostada dos pacotes emitidos diretamente para esses IPs, conforme teste abaixo.
Fonte: Elaboração do autor, 2010
No quadro 14 pode-se observar que apesar do endereço IP 172.16.1.1 estar configurado na interface serial0/0 do próprio roteador PE1, foram disparados 50 pacotes ICMP com 100% de perda. Isso mostra que as redes das VRFs estão de fato isoladas do restante das redes. Para o PE1 poder realizar esse teste, o comando ping precisa fazer uma chamada na VRF correspondente a rede. Abaixo o comando usado para esse teste.
Fonte: Elaboração do autor, 2010
Outro fator importante a ser analisado foi a tabela de encaminhamento dos rótulos MPLS. Como agora novas redes foram atribuídas aos roteadores PEs, a tabela MPLS sofreu alterações conforme a saída do comando show mpls forwarding-table, verificado nos dois roteadores PEs.
Fonte: Elaboração do autor, 2010
Conforme as informações mostradas no quadro 16, a tabela de encaminhamento dos rótulos MPLS sofreu alterações quando comparada ao quadro 12 da seção Modelo Conceitual 1 – MPLS com OSPF do tutorial parte I. Para cada rede associada a uma VRFs, foi adicionado um novo rótulo. Observado também que, mesmo contendo endereços IPs iguais, o mecanismo de encaminhamento MPLS tratará de maneira diferenciada cada rede, tendo como base a associação das VRFs em cada interface. O parâmetro Aggregate significa que para esse prefixo, o rótulo será removido do pacote, e então será feito uma consulta na tabela de roteamento (nesse caso a tabela de roteamento da VRF). Já o Untagged, indica que o rótulo será removido e encaminhado para o próximo salto. Os endereços 172.16.1.2/32 e 192.168.1.0/24, pertencem a roteadores CEs, não farem parte da rede MPLS, portanto não participaram do processo LDP do MPLS.
Da mesma forma como foi mostrado no quadro 16, no quadro 17 as mesmas informações foram coletadas só que desta vez no ilustrando a saída no roteador PE2.
Fonte: Elaboração do autor, 2010
Depois de verificar o funcionamento da arquitetura BGP/VPN MPLS nos roteadores PEs, verificou-se também o funcionamento entre os roteadores CEs. No quadro 18 mostra o resultado dos testes realizados com pacotes ICMP disparados do roteador CE1 para o endereço da interface FastEthernet0/0 do CE2, testando a conectividade da VPN_A, e entre CE3 e CE4 testando a conectividade da VPN_B mostrados no quadro 19.
Fonte: Elaboração do autor, 2010
Fonte: Elaboração do autor, 2010
De acordo com os resultados verificados nos quadros 18 e 19, constatou-se que tanto a conectividade da VPN_A quando da VPN_B está em perfeito funcionamento. Outro fator importante analisado também foi o caminho percorrido entre CE1 e CE2 através do comando traceroute, conforme o quadro abaixo.
Fonte: Elaboração do autor, 2010
Verificou-se no quadro 20 que o caminho percorrido entre os roteadores CE1 e CE2, conectados na VPNA é: CE1?PE1? P1? PE2? CE2.
Apesar do IP público 220.110.90.13 referente ao roteador P1 aparecer no caminho percorrido até o CE2, não é possível “pingar” nesse equipamento conforme mostrado no quadro 21.
Fonte: Elaboração do autor, 2010
O retorno “U” significa nesse caso, que os pacotes estão sendo transmitidos do roteador CE1, porém o roteador P1 não tem uma entrada na tabela de roteamento para retornar o pacote. Isso mostra que a conexão da VPN de fato está isolada.
Sabendo-se que o caminho percorrido é CE1?PE1? P1? PE2? CE2, foi verificado como os protocolos de roteamento fazem a convergência de rota em caso de falhas.
No exemplo apresentado no quadro 22 foi provocado uma falha no P1 , colocando em shutdown a interface FastEthernet1/1 que da acesso ao PE1, logo após disparar os pacotes do CE1 para o C2. Segue o teste abaixo:
Fonte: Elaboração do autor, 2010
Fonte: Elaboração do autor, 2010
Fonte: Elaboração do autor, 2010
Pode-se observar que a topologia proposta para analise, configurada com os protocolos de roteamento OSPF (para comunicação da nuvem pública) e BGP (para comunicação das VPNs em nuvem privada), reagiu com rapidez à falha. No quadro 21, observou-se que apenas 3 pacotes foram perdidos dos 500 disparados, isso devido ao poder de convergência que o protocolo OSPF oferece. Posteriormente no quadro 24 foi realizado novamente o comando traceroute, e mostrou que a conversão da rota para o IP 220.110.90.9 do roteador P2, foi realizado com sucesso, traçando a rota CE1?PE1? P2? PE2? CE2.
Devido ao crescente número de empresas que dependem da rede de computadores para a troca de informações entre suas filiais, torna-se cada vez mais necessário o uso de uma tecnologia que garanta qualidade e eficiência para esse fim.
O MPLS (Multi Protocol Label Switching) foi desenvolvido como uma solução que funciona em conjunto com o protocolo IP, capaz de transferir pacotes a um ritmo elevado e que possui mecanismos de gestão de recursos que permitem o tratamento diferenciado dos fluxos de tráfego, isolando-os dos demais tráfegos da rede. O crescimento e a importância dessa tecnologia tornam seu estudo em disciplinas de Redes voltado a cursos de Informática, Telecomunicação, Elétrica e Telemática, fundamental para a formação de um bom profissional.
Esta série de tutoriais procura apresentar experiências laboratoriais que permitem compreender, de uma maneira simples, os principais mecanismos de roteamento e entrega dos pacotes em redes virtuais privadas com a tecnologia MPLS, como também comparar com tecnologias tradicionais. As experiências utilizaram o emulador GNS3, que além de poupar espaço físico e tempo, contribuiu para um ambiente versátil que não obrigou o uso de equipamentos físicos, assemelhando-se muito de um modelo real. A possibilidade de estudar tecnologias que trabalham em equipamentos de grande porte, geralmente encontrados em operadoras de serviço, faz com que profissionais da área tenham a capacidade de desenvolver diferentes soluções em redes de computadores sem mesmo de fato portar o equipamento.
Este tutorial parte II apresenta as parte II (configuração do BGP/MPLS VPN) e III (configuração do IPsec em Redes IP) do modelo conceitual, a seguir apresenta a análise comparativa desses modelos, e finalizará com os resultados alcançados.
Redes MPLS II: Introdução
Nos últimos anos, as redes de computadores e telecomunicação sofreram inúmeras transformações. Com os crescentes avanços nas áreas tecnológicas, contribuíram para o desenvolvimento de sistemas de transmissão de dados com alto desempenho. No final dos anos 90, foi introduzida no mercado mundial a tecnologia MPLS (Multi Protocol Label Switching), onde se permitiu controlar a forma com que o tráfego flui através das redes IPs, otimizando o desempenho da rede e também melhorando o uso dos seus recursos.
Em redes IPs tradicionais, o encaminhamento dos pacotes, requer uma pesquisa que compara o endereço de destino do pacote com cada uma das entradas na tabela de roteamento, encaminhando cada um para a saída correspondente. Esse procedimento é repetido a cada nó percorrido ao longo do caminho, da origem ao destino. Isso de fato parece relativamente simples, porém, considerando que cada equipamento processa milhares e as vezes milhões de pacotes por segundo, essa tarefa pode sobrecarregar a rede.
O MPLS é uma tecnologia de encaminhamento de pacotes baseada em rótulos que vem sendo adotado por operadoras para oferecer serviços diferenciados com eficiência nos transportes de dados. Os produtos oferecidos por operadoras baseados em MPLS, permitem disponibilizar não apenas velocidade de conexão, mas também a diferenciação de tráfego como Multimídia (Voz, Vídeo) e aplicações críticas, com garantias aplicáveis de QoS (Quality of Service), através das classes de serviço.
Atualmente o MPLS é um passo fundamental para a escalabilidade da rede, considerado essencial para um novo modelo de Internet no século XXI. MPLS é relativamente jovem, porém vem sendo implantada com êxito em redes de grandes operadoras de serviços em todo mundo.
Nesse trabalho será abordada a utilização de VPN camada 3 em redes MPLS como solução na segmentação de redes e segregação de tráfego, provendo aos assinantes/clientes das operadoras de serviço a interligação de estações distribuídas em uma ampla área geográfica de maneira rápida e seguras.
Objetivos
Os objetivos deste trabalho foram divididos em objetivo geral e objetivos específicos.
O objetivo geral é implementar uma solução de VPN de camada 3 em redes MPLS, utilizando emuladores como ferramenta de teste para demonstrar o desempenho e analise comparativa com outros tipos de redes.
Entre os objetivos específicos, destacam-se:
- Estudar a tecnologia MPLS;
- Estudar os tipos de roteamento;
- Estudar as VRFs (VPN Routing and Forwarding Table) em uma estrutura MPLS;
- Estudar os softwares utilizados na proposta;
- Configurar as tecnologias de redes estudadas nos softwares utilizados;
- Analisar o desempenho do funcionamento da implementação;
- Comparar com outras estruturas de redes convencionais.
Abrangência
Propõe-se realizar um projeto de rede onde uma estrutura MPLS será montada, configurada e analisada através do uso de softwares, bem como emuladores de rede, emuladores de Sistemas Operacionais e sniffers.
O simulador de rede usado emula os IOS (Internetwork Operating System) que são os softwares que rodam em roteadores da linha Cisco Systems, sendo que cada equipamento opera como uma máquina real, com acesso a todas as funcionalidades e protocolos, podendo comportar uma topologia de rede ampla em um único computador. Nessa estrutura serão estudadas as formas de roteamento que os backbones (operadoras) usam para comunicar-se com outros backbones e roteadores de assinantes (clientes) – CPE (customer premises equipment), tendo como foco principal do trabalho, mostrar e analisar o desempenho e vantagem da utilização de VPNs de camada 3 em redes MPLS através de nuvem privada.
A nuvem privada é a forma utilizada por operadoras de serviço para interligar vários pontos de uma mesma organização isolando o tráfego da nuvem pública a qual todos têm acesso. As análises serão executadas através da utilização de softwares específicos para o monitoramento de rede, capturando dados e posteriormente a gerando gráficos e relatórios. Assuntos como QoS, Engenharia de Tráfego, VPN de camada 2 e segurança não serão aprofundados, como também não serão implementadas soluções MPLS para a internet pública.
Para esse estudo será utilizado o programa GNS3 versão 0.7.2, um programa gratuito resultado de um projeto open source que pode ser utilizado em diversos sistemas operacionais como Windows, Linux e MacOS X. Com o GNS3 pode-se fazer praticamente tudo o que é possível fazer com roteadores e pix da linha Cisco. O GN3 é um gerenciador gráfico que está ligado diretamente a outros 3 softwares:
- Dynamips: o núcleo do programa que permite a emulação Cisco IOS.
- Dynagen: um texto baseado em front-end para o Dynamips.
- Qemu: uma máquina de fonte genérica e aberta emulador e virtualizador.
Este programa é um emulador e não um simulador, pois utiliza as mesmas imagens binárias dos equipamentos reais, proporcionando assim, num local que já possua estes equipamentos, a possibilidade de testar uma nova versão do IOS antes mesmo de colocá-lo nos equipamentos reais.
A motivação do uso desse software nesse TCC, se deu principalmente por ser gratuito e permitir utilizar os mesmos IOS dos roteadores, criando um ambiente de simulação que se aproxima bastante do ambiente real.
Para virtualização dos sistemas operacionais será utilizado o Virtual Box na versão 3.2.8. Virtual Box é um software de virtualização desenvolvido pela Oracle para arquiteturas de hardware x86 também gratuito, que visa criar ambientes para instalação de sistemas distintos. Ele permite a instalação e utilização de um sistema operacional dentro de outro em pleno funcionamento, assim como seus respectivos softwares, com dois ou mais computadores independentes simultaneamente, compartilhando fisicamente o mesmo hardware.
O sistema operacional que será virtualizado no Virtual Box para gerar o tráfego nos ambientes do GNS3 será o Ubunto na versão 10.4. Ubuntu é um sistema operacional de código aberto mais popular do mundo na atualidade. Desenvolvido para notebooks, desktops e servidores, ele contém todos os aplicativos que qualquer outro sistema operacional tem, em versões similares e livre de licenças.
Para análise do tráfego de rede será utilizado o Wireshark. O é um programa que verifica os pacotes transmitidos pelo dispositivo de comunicação (placa de rede, placa de fax modem, etc.) do computador. O propósito deste tipo de software, também conhecido como sniffer, é detectar problemas de rede, conexões suspeitas, auxiliar no desenvolvimento e resolução de problemas. O programa analisa o tráfego de pacotes recebidos e organiza-os por protocolo. Todo o tráfego de entrada e saída é analisado e exibido em um ambiente gráfico de fácil visualização contribuindo para a explicação dos casos.
Metodologia
Para a realização deste trabalho serão adotados os seguintes procedimentos:
- Revisão Bibliográfica de todo assunto abordados no projeto.
- Estudo das tecnologias de redes.
- Estudo das técnicas de roteamento.
- Estudo da topologia a ser implementada.
- Estudo dos softwares a serem utilizados na implementação.
- Pesquisa dos equipamentos suportados pela topologia.
- Levantamento das IOS (Internetwork Operating System) dos equipamentos.
- Implementação da topologia nos simuladores.
- Configuração dos equipamentos nos simuladores.
- Descrever detalhes de analise e desempenho.
Tutoriais
O tutorial parte I apresentou inicialmente os conceitos sobre Redes de Computadores, e a seguir os conceitos das Redes IP MPLS, e finalizou apresentando a parte I do modelo conceitual utilizado neste trabalho, relativa à configuração básica do MPLS com o protocolo OSPF.
Este tutorial parte II apresenta as parte II (configuração do BGP/MPLS VPN) e III (configuração do IPsec em Redes IP) do modelo conceitual, a seguir apresenta a análise comparativa desses modelos, e finalizará com os resultados alcançados.
Modelo Conceitual 2 – BGP/MPLS VPN
Esta seção continua a apresentação iniciada no tutorial parte I das experiências e implementações que foram realizadas, recorrendo o emulador GNS3, com o objetivo de estudar algumas características fundamentais do MPLS e VPN camada 3 em MPLS.
A fim de facilitar o entendimento, a topologia proposta para análise do trabalho será novamente apresentada conforme foi montada, através da ilustração da figura 1:
Figura 1: Captura da topologia MPLS no GNS3
Fonte: Elaboração do autor, 2010
No cenário acima, os roteadores usados para simular os equipamentos de núcleo “Ps” foram o Cisco 7200 com a versão de IOS c7200-jk9s-mz.124-13b.bin. Para os equipamentos “PEs” foram usados o modelo Cisco 3725 com a versão de IOS c3725-adventerprisek9-mz.124-15.T5.bin. E para os equipamentos de acesso ao cliente “CEs” o modelo Cisco 2691 com a versão de IOS c2691-adventerprisek9_ivs-mz.124-9.T7.bin. A escolha das versões IOS usadas para formar a topologia foi outro fator importante. Cada versão possui características e funcionalidades diferentes, com suporte a um conjunto específico de protocolos.
A escolha dos protocolos envolvidos na topologia, como protocolo de encapsulamento, de roteamento, túneis também foi outro fator determinante. O objetivo foi montar toda a rede usando apenas protocolos não proprietários, ou seja, a mesma topologia poderá ser implementada com roteadores de outros fabricantes.
Já os computadores emulados com o programa Virtual Box, foram usados uma imagem do sistema operacional Ubuntu versão 10.4 para simular uma operação, gerando tráfego pela rede MPLS de um ponto a outro da rede. E a captura das informações foi recorrida ao Wireshark em cada ponto ligado a um par de roteadores.
Em todas as experiências descritas em cada tópico, foram usados os mesmo endereços de IP das interfaces. Os testes e análises serão de maneira separada e sequenciada.
Configuração do BGP/MPLS VPN
Nesse tópico será abordada a constituição de VPNs camada 3 com suporte no MPLS. As configurações a seguir são referentes aos roteadores PEs e CEs conforme visto na Figura 20: Captura da topologia MPLS no GNS3 da seção Modelo Conceitual 1 – MPLS com OSPF do tutorial parte I. Da mesma forma que no caso anterior relatado no tutorial parte I, as configurações foram realizadas com a ajuda do emulador GNS3, dando continuidade ao que já foi implementado.
Figura 2: Captura da topologia BGP/MPLS VPN em análise do GNS3
Fonte: Elaboração do autor, 2010
As configurações nessa seção restringem-se somente aos roteadores PEs e CEs, os roteadores de núcleo Ps não precisarão sofrer qualquer alteração no que já foi implementado, já que sua participação nesse caso é prover o transporte dos pacotes rotulados no MPLS. O procedimento de configuração será mostrado somente nos roteadores CE1 e PE1, tendo em vista que as configurações nos roteadores PE2, CE2, CE3 e CE4, mudaram somente parâmetros de endereçamento IP conforme as tabelas 4 e 5, como também hostname, senhas, e descriptions.
| ROTEADORES | SERIAL 0/0 | SERIAL 0/1 |
| PE1 | 172.16.1.1/30 | 172.16.1.1/30 |
| PE2 | 172.16.2.1/30 | 172.16.2.1/30 |
Tabela 1: Relação de endereço IP/interface dos roteadores PEs
Fonte: Elaboração do autor, 2010
| ROTEADORES | SERIAL0/0 | FASTEHERNET0/0 |
| CE1 | 172.16.1.2/30 | 192.168.1.1/24 |
| CE2 | 172.16.2.2/30 | 192.168.2.1/24 |
| CE3 | 172.16.1.2/30 | 192.168.1.1/24 |
| CE4 | 172.16.2.2/30 | 192.168.2.1/24 |
Tabela 2: Relação de endereço IP/interface dos roteadores CEs
Fonte: Elaboração do autor, 2010
As configurações realizadas no PE1 seguem a seguinte sequência:
- Configuração da VRF VPN_A;
- Configuração da VRF VPN_B;
- Configuração de IP e protocolo para ativação de VPN_A na serial0/0;
- Configuração de IP e protocolo para ativação de VPN_B na serial0/1;
- Configuração do roteamento BGP;
- Configuração do vizinho (loopback do roteador PE2) no BGP;
- Configuração do BGP/MPLS VPN IPv4;
- Configuração da VRF VPN_A no BGP/VPN;
- Configuração da VRF VPN_B no BGP/VPN;
- Configuração do roteamento estático para cada VRF.
Na sequência dos quadros 1, 2 e 3, pode-se observar que o endereçamento IP das VPNs são iguais, e um não interferirá no outro, devido ao comando ip vrf forward vinculado a cada interface de saída para os roteadores CEs. Em condições normais, sem o uso desse comando, o equipamento acusaria que um mesmo endereço IP já esta em uso em outra interface no equipamento, recusando o comando ip address com endereço IP na mesma faixa. Com o uso das VRFs, uma tabela de roteamento virtual é montada para cada uma das VRFs, dando total independência da tabela de roteamento global do roteador. No quadro 1 mostra a sequência de comandos necessária para disponibilizar o recurso de VPN em MPLS para os roteadores CEs. Em seguida nos quadros 2 e 3, é exibido como ficou as configurações no PE1 e PE, omitindo alguns comandos que por padrão já vem configurado.
- Código:
ROUTER_PE_1> enable
ROUTER_PE_1# configure terminal
ROUTER_PE_1(config)# ip vrf VPN_A
ROUTER_PE_1(config-vrf)# rd 100:110
ROUTER_PE_1(config-vrf)# route-target export 100:110
ROUTER_PE_1(config-vrf)# route-target import 100:110
ROUTER_PE_1(config-vrf)# ip vrf VPN_B
ROUTER_PE_1(config-vrf)# rd 100:120
ROUTER_PE_1(config-vrf)# route-target export 100:120
ROUTER_PE_1(config-vrf)# route-target import 100:120
ROUTER_PE_1(config-vrf)# interface serial0/0
ROUTER_PE_1(config-if)# description ## ACESSO CE1 ##
ROUTER_PE_1(config-if)# ip vrf forwarding VPN_A
ROUTER_PE_1(config-if)# ip address 172.16.1.1 255.255.255.252
ROUTER_PE_1(config-if)# encapsulation PPP
ROUTER_PE_1(config-if)# no shutdown
ROUTER_PE_1(config-if)# interface serial0/1
ROUTER_PE_1(config-if)# description ## ACESSO CE2 ##
ROUTER_PE_1(config-if)# ip vrf forwarding VPN_B
ROUTER_PE_1(config-if)# ip address 172.16.1.1 255.255.255.252
ROUTER_PE_1(config-if)# encapsulation PPP
ROUTER_PE_1(config-if)# no shutdown
ROUTER_PE_1(config-if)# router bgp 100
ROUTER_PE_1(config-router)# neighbor 220.110.90.2 remote-as 100
ROUTER_PE_1(config-router)# neighbor 220.110.90.2 update-source Loopback0
ROUTER_PE_1(config-router)# neighbor 220.110.90.2 next-hop-self
ROUTER_PE_1(config-router)# no auto-summary
ROUTER_PE_1(config-router)# no synchronization
ROUTER_PE_1(config-router)# address-family ipv4
ROUTER_PE_1(config-router-af)# neighbor 220.110.90.2 activate
ROUTER_PE_1(config-router-af)# neighbor 220.110.90.2 send-community both
ROUTER_PE_1(config-router-af)# exit-address-family
ROUTER_PE_1(config-router)# address-family ipv4 vrf VPN_A
ROUTER_PE_1(config-router-af)# redistribute connected
ROUTER_PE_1(config-router-af)# redistribute static
ROUTER_PE_1(config-router-af)# no synchronization
ROUTER_PE_1(config-router-af)# exit-address-family
ROUTER_PE_1(config-router-af)# exit-address-family
ROUTER_PE_1(config-router)# address-family ipv4 vrf VPN_B
ROUTER_PE_1(config-router-af)# redistribute connected
ROUTER_PE_1(config-router-af)# redistribute static
ROUTER_PE_1(config-router-af)# no synchronization
ROUTER_PE_1(config-router-af)# exit-address-family
ROUTER_PE_1(config-router)# exit
ROUTER_PE_1(config)# ip route vrf VPN_A 192.168.1.0 255.255.255.0 172.16.1.2
ROUTER_PE_1(config)# ip route vrf VPN_B 192.168.1.0 255.255.255.0 172.16.1.2
Fonte: Elaboração do autor, 2010
- Código:
ROUTER_PE_1#show running-config
!
ip vrf VPN_A
rd 100:110
route-target export 100:110
route-target import 100:110
!
ip vrf VPN_B
rd 100:120
route-target export 100:120
route-target import 100:120
!
interface Loopback0
ip address 220.110.90.1 255.255.255.255
!
interface FastEthernet0/0
description ## ACESSO P2 ##
ip address 220.110.90.10 255.255.255.252
speed 100
full-duplex
mpls label protocol ldp
mpls ip
!
interface Serial0/0
description ## ACESSO CE1 ##
ip vrf forwarding VPN_A
ip address 172.16.1.1 255.255.255.252
encapsulation ppp
clock rate 128000
!
interface FastEthernet0/1
description ## ACESSO P1 ##
ip address 220.110.90.14 255.255.255.252
speed 100
full-duplex
mpls label protocol ldp
mpls ip
!
interface Serial0/1
description ## ACESSO CE3 ##
ip vrf forwarding VPN_B
ip address 172.16.1.1 255.255.255.252
encapsulation ppp
clock rate 128000
!
Fonte: Elaboração do autor, 2010
- Código:
!
router ospf 1
log-adjacency-changes
network 220.110.90.1 0.0.0.0 area 0
network 220.110.90.10 0.0.0.0 area 0
network 220.110.90.14 0.0.0.0 area 0
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 220.110.90.2 remote-as 100
neighbor 220.110.90.2 update-source Loopback0
neighbor 220.110.90.2 next-hop-self
no auto-summary
!
address-family vpnv4
neighbor 220.110.90.2 activate
neighbor 220.110.90.2 send-community both
exit-address-family
!
address-family ipv4 vrf VPN_B
redistribute connected
redistribute static
no synchronization
exit-address-family
!
address-family ipv4 vrf VPN_A
redistribute connected
redistribute static
no synchronization
exit-address-family
!
ip forward-protocol nd
ip route vrf VPN_A 192.168.1.0 255.255.255.0 172.16.1.2
ip route vrf VPN_B 192.168.1.0 255.255.255.0 172.16.1.2
!
Fonte: Elaboração do autor, 2010
- Código:
ROUTER_PE_2#show running-config
!
ip vrf VPN_A
rd 100:110
route-target export 100:110
route-target import 100:110
!
ip vrf VPN_B
rd 100:120
route-target export 100:120
route-target import 100:120
!
interface Loopback0
ip address 220.110.90.2 255.255.255.255
!
interface FastEthernet0/0
description ## ACESSO P2 ##
ip address 220.110.90.18 255.255.255.252
speed 100
full-duplex
mpls label protocol ldp
mpls ip
!
interface Serial0/0
description ## ACESSO CE2 ##
ip vrf forwarding VPN_A
ip address 172.16.2.1 255.255.255.252
encapsulation ppp
clock rate 128000
!
interface FastEthernet0/1
description ## ACESSO P1 ##
ip address 220.110.90.22 255.255.255.252
speed 100
full-duplex
mpls label protocol ldp
mpls ip
!
interface Serial0/1
description ## ACESSO CE4 ##
ip vrf forwarding VPN_B
ip address 172.16.2.1 255.255.255.252
encapsulation ppp
clock rate 128000
!
- Código:
!
router ospf 1
log-adjacency-changes
network 220.110.90.2 0.0.0.0 area 0
network 220.110.90.18 0.0.0.0 area 0
network 220.110.90.22 0.0.0.0 area 0
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 220.110.90.1 remote-as 100
neighbor 220.110.90.1 update-source Loopback0
neighbor 220.110.90.1 next-hop-self
no auto-summary
!
address-family vpnv4
neighbor 220.110.90.1 activate
neighbor 220.110.90.1 send-community both
exit-address-family
!
address-family ipv4 vrf VPN_B
redistribute connected
redistribute static
no synchronization
exit-address-family
!
address-family ipv4 vrf VPN_A
redistribute connected
redistribute static
no synchronization
exit-address-family
!
ip forward-protocol nd
ip route vrf VPN_A 192.168.2.0 255.255.255.0 172.16.2.2
ip route vrf VPN_B 192.168.2.0 255.255.255.0 172.16.2.2
!
Fonte: Elaboração do autor, 2010
Nos quadros 2 e 3, verificou-se como ficou as configurações dos roteadores PE1 e PE2. Essas configurações garantem o acesso isolado dos roteadores CEs, onde o CE1 e CE2 fazem parte da VPN_A e o CE3 e CE4 da VPN_B. Foi observado também que tanto a VPN_A quanto a VPN_B possuem as mesmas características. Elas não precisariam necessariamente ser configuradas com as faixas IPs iguais, mas foram configurados dessa maneira com a intenção de mostrar como uma rede não sobrepõe outra. No quadro 4 o mesmo procedimento foi realizado com os roteadores CEs.
- Código:
Router>enable
Router# configure terminal
Router(config)#enable secret Ce1!+mp*
Router(config)#hostname ROUTER_CE_1
ROUTER_CE_1(config)# interface serial0/0
ROUTER_CE_1(config-if)# description ## ACESSO PE1 ##
ROUTER_CE_1(config-if)# ip address 172.16.1.2 255.255.255.252
ROUTER_CE_1(config-if)# encapsulation ppp
ROUTER_CE_1(config-if)# bandwidth 128
ROUTER_CE_1(config-if)# no shutdown
ROUTER_CE_1(config-if)# interface fastethernet0/0
ROUTER_CE_1(config-if)# description ## REDE LOCAL ##
ROUTER_CE_1(config-if)# ip address 192.168.1.1 255.255.255.0
ROUTER_CE_1(config-if)# no shutdown
ROUTER_CE_1(config-if)# ip dhcp pool host1
ROUTER_CE_1(dhcp-config)# network 192.168.1.0 255.255.255.0
ROUTER_CE_1(dhcp-config)# default-router 192.168.1.1 255.255.255.0
ROUTER_CE_1(dhcp-config)# exit
ROUTER_CE_1(config)# ip route 0.0.0.0 0.0.0.0 172.16.1.1
Fonte: Elaboração do autor, 2010
Na configuração do roteador CE1 seguiu a seguinte sequência:
- Configuração de IP e protocolo para ativação da interface serial0/0;
- Configuração de IP para ativação da interface fastehernet0/0;
- Configuração do protocolo DHCP;
- Configuração da rota estática.
Foi adotado o DHCP (Dynamic Host Configuration Protocol), para dar mais comodidade ao usuário final, já que esse protocolo proporciona a distribuição dinâmica de IPs para a rede, nesse. A mesma configuração foi inserida nos demais roteadores CEs, mudando apenas os parâmetros de endereçamento IP nas interfaces, rotas e no DHCP, conforme a tabela 5. Nos quadros 5, 6, 7 e 8 verificou-se como ficaram as configurações no s CEs.
- Código:
ROUTER_CE_1#show running-config
!
hostname ROUTER_CE_1
!
ip dhcp pool rede_local
network 192.168.1.0 255.255.255.0
default-router 192.168.1.1 255.255.255.0
!
interface FastEthernet0/0
description ## REDE LOCAL ##
ip address 192.168.1.1 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0
description ## ACESSO PE1 ##
bandwidth 128
ip address 172.16.1.2 255.255.255.252
encapsulation ppp
!
i
dp route 0.0.0.0 0.0.0.0 172.16.1.1
!
Fonte: Elaboração do autor, 2010
- Código:
ROUTER_CE_2#show running-config
!
ip dhcp pool rede_local
network 192.168.2.0 255.255.255.0
default-router 192.268.2.1 255.255.255.0
!
interface FastEthernet0/0
description ## REDE LOCAL ##
ip address 192.168.2.1 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0
description ## ACESSO PE2 ##
bandwidth 128
ip address 172.16.2.2 255.255.255.252
encapsulation ppp
!
ip route 0.0.0.0 0.0.0.0 172.16.2.1
!
Fonte: Elaboração do autor, 2010
- Código:
ROUTER_CE_3#show running-config
!
ip dhcp pool rede_local
network 192.168.1.0 255.255.255.0
default-router 192.168.1.1 255.255.255.0
!
interface FastEthernet0/0
description ## REDE LOCAL ##
ip address 192.168.1.1 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0
description ## ACESSO PE1 ##
bandwidth 128
ip address 172.16.1.2 255.255.255.252
encapsulation ppp
!
ip route 0.0.0.0 0.0.0.0 172.16.1.1
!
Fonte: Elaboração do autor, 2010
- Código:
ROUTER_CE_4#show running-config
!
ip dhcp pool rede_local
network 192.168.2.0 255.255.255.0
default-router 192.168.2.1 255.255.255.0
!
interface FastEthernet0/0
description ## REDE LOCAL ##
ip address 192.168.2.1 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0
description ## ACESSO PE2 ##
bandwidth 128
ip address 172.16.2.2 255.255.255.252
encapsulation ppp
!
ip route 0.0.0.0 0.0.0.0 172.16.2.1
!
Fonte: Elaboração do autor, 2010
Como na seção anterior, algumas configurações foram omitidas pelo fato de já virem configuradas por padrão nos equipamentos. Foi exibido o que de fato é necessário para o funcionamento.
Testes e Análise do BGP/MPLS VPNs
Com os roteadores PEs e CEs devidamente configurados, o próximo passo foi verificar o funcionamento e parâmetros relevantes quanto ao funcionamento das VPNs em redes MPLS. Primeiro foi verificado as informações sobre o roteamento nos roteadores PE1 e PE2. No quadro 9 segue as informações obtidas com a saída do comando show ip router no roteador PE1.
- Código:
ROUTER_PE_1#show ip route
-- Omitido --
Gateway of last resort is not set
220.110.90.0/24 is variably subnetted, 8 subnets, 2 masks
C 220.110.90.8/30 is directly connected, FastEthernet0/0
C 220.110.90.12/30 is directly connected, FastEthernet0/1
C 220.110.90.1/32 is directly connected, Loopback0
O 220.110.90.2/32 [110/3] via 220.110.90.13, 08:20:46, FastEthernet0/1
[110/3] via 220.110.90.9, 08:21:17, FastEthernet0/0
O 220.110.90.3/32 [110/2] via 220.110.90.13, 08:20:46, FastEthernet0/1
O 220.110.90.4/32 [110/2] via 220.110.90.9, 08:21:17, FastEthernet0/0
O 220.110.90.16/30 [110/2] via 220.110.90.9, 08:21:17, FastEthernet0/0
O 220.110.90.20/30 [110/2] via 220.110.90.13, 08:20:46, FastEthernet0/1
Fonte: Elaboração do autor, 2010
Observou-se na saída do comando show ip route, que na tabela de roteamento consta apenas os endereços IPs globais, usados para a comunicação entre os roteadores Ps e PEs. Informações sobre os endereços de IPs usados nas VPNs não são apresentados na saída desse comando. Isso acontece devido a capacidade que o VRF tem em isolar o roteamento usado nas VPNs, dos demais roteamentos do equipamento. Na saída do comando show ip router vrf VPN_A e show ip router VPN_B, essa história muda, apresentando uma nova tabela de roteamento para cada VFR designada conforme os quadros 10 e 11.
- Código:
ROUTER_PE_1#show ip route vrf VPN_A
-- Omitido --
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
B 172.16.2.2/32 [200/0] via 220.110.90.2, 08:26:54
C 172.16.1.0/30 is directly connected, Serial0/0
B 172.16.2.0/30 [200/0] via 220.110.90.2, 08:26:54
C 172.16.1.2/32 is directly connected, Serial0/0
S 192.168.1.0/24 [1/0] via 172.16.1.2
B 192.168.2.0/24 [200/0] via 220.110.90.2, 08:26:54
Fonte: Elaboração do autor, 2010
- Código:
ROUTER_PE_1#show ip route vrf VPN_B
-- Omitido --
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
B 172.16.2.2/32 [200/0] via 220.110.90.2, 08:30:01
C 172.16.1.0/30 is directly connected, Serial0/1
B 172.16.2.0/30 [200/0] via 220.110.90.2, 08:30:01
C 172.16.1.2/32 is directly connected, Serial0/1
S 192.168.1.0/24 [1/0] via 172.16.1.2
B 192.168.2.0/24 [200/0] via 220.110.90.2, 08:30:01
Fonte: Elaboração do autor, 2010
As linhas que precedem com “B” indica que para chegar nessa rede será preciso passar pelo BGP. O “S” são as rotas estáticas usadas para o roteamento com os CEs, e o “C” como já foi visto, são as redes diretamente conectadas as interfaces. Informações sobre o roteamento das VPNs pode ser obtido através do comando show ip bgp vpnv4 all, conforme mostrado no quadro abaixo.
- Código:
ROUTER_PE_1#show ip bgp vpnv4 all
BGP table version is 25, local router ID is 220.110.90.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:110 (default for vrf VPN_A)
*> 172.16.1.0/30 0.0.0.0 0 32768 ?
*> 172.16.1.2/32 0.0.0.0 0 32768 ?
*>i172.16.2.0/30 220.110.90.2 0 100 0 ?
*>i172.16.2.2/32 220.110.90.2 0 100 0 ?
*> 192.168.1.0 172.16.1.2 0 32768 ?
*>i192.168.2.0 220.110.90.2 0 100 0 ?
Route Distinguisher: 100:120 (default for vrf VPN_B)
*> 172.16.1.0/30 0.0.0.0 0 32768 ?
*> 172.16.1.2/32 0.0.0.0 0 32768 ?
*>i172.16.2.0/30 220.110.90.2 0 100 0 ?
*>i172.16.2.2/32 220.110.90.2 0 100 0 ?
*> 192.168.1.0 172.16.1.2 0 32768 ?
*>i192.168.2.0 220.110.90.2 0 100 0 ?
Fonte: Elaboração do autor, 2010
Nas informações mostradas no quadro 12, é possível ver todas as saídas das VRFs no BGP, como também a redistribuição para as rotas estáticas usadas paca a comunicação fim a fim dos CEs. Pode-se ver também que as redes que não contém a sigla “i” de internal, são os IPs referentes aos endereço de WAN e LAN dos roteadores CE1 e CE3, que não estão configuradas nos equipamentos PEs, e sim previstas no roteamento estático. No roteador PE2 o mesmo ocorre só que referentes aos endereços de WAN e LAN dos roteadores CE2 e CE4, conforme o quadro 13.
- Código:
ROUTER_PE_2#show ip bgp vpnv4 all
BGP table version is 25, local router ID is 220.110.90.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:110 (default for vrf VPN_A)
*>i172.16.1.0/30 220.110.90.1 0 100 0 ?
*>i172.16.1.2/32 220.110.90.1 0 100 0 ?
*> 172.16.2.0/30 0.0.0.0 0 32768 ?
*> 172.16.2.2/32 0.0.0.0 0 32768 ?
*>i192.168.1.0 220.110.90.1 0 100 0 ?
*> 192.168.2.0 172.16.2.2 0 32768 ?
Route Distinguisher: 100:120 (default for vrf VPN_B)
*>i172.16.1.0/30 220.110.90.1 0 100 0 ?
*>i172.16.1.2/32 220.110.90.1 0 100 0 ?
*> 172.16.2.0/30 0.0.0.0 0 32768 ?
*> 172.16.2.2/32 0.0.0.0 0 32768 ?
*>i192.168.1.0 220.110.90.1 0 100 0 ?
*> 192.168.2.0 172.16.2.2 0 32768 ?
Fonte: Elaboração do autor, 2010
Da mesma forma que o roteador não consegue visualizar os IPs das VPNs na sua tabela de roteamento principal, também não conseguirá receber respostada dos pacotes emitidos diretamente para esses IPs, conforme teste abaixo.
- Código:
ROUTER_PE_1#ping 172.16.1.1 repeat 50
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
..................................................
Success rate is 0 percent (0/50)
Fonte: Elaboração do autor, 2010
No quadro 14 pode-se observar que apesar do endereço IP 172.16.1.1 estar configurado na interface serial0/0 do próprio roteador PE1, foram disparados 50 pacotes ICMP com 100% de perda. Isso mostra que as redes das VRFs estão de fato isoladas do restante das redes. Para o PE1 poder realizar esse teste, o comando ping precisa fazer uma chamada na VRF correspondente a rede. Abaixo o comando usado para esse teste.
- Código:
ROUTER_PE_1#ping vrf VPN_A 172.16.1.1 repeat 50
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 4/25/76 ms
Fonte: Elaboração do autor, 2010
Outro fator importante a ser analisado foi a tabela de encaminhamento dos rótulos MPLS. Como agora novas redes foram atribuídas aos roteadores PEs, a tabela MPLS sofreu alterações conforme a saída do comando show mpls forwarding-table, verificado nos dois roteadores PEs.
- Código:
ROUTER_PE_1#show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 220.110.90.4/32 0 Fa0/0 220.110.90.9
17 Pop tag 220.110.90.3/32 0 Fa0/1 220.110.90.13
18 19 220.110.90.2/32 0 Fa0/1 220.110.90.13
17 220.110.90.2/32 0 Fa0/0 220.110.90.9
19 Pop tag 220.110.90.16/30 0 Fa0/0 220.110.90.9
20 Pop tag 220.110.90.20/30 0 Fa0/1 220.110.90.13
21 Aggregate 172.16.1.0/30[V] 0
22 Untagged 172.16.1.2/32[V] 0 Se0/0 point2point
23 Untagged 192.168.1.0/24[V] 0 Se0/0 point2point
24 Aggregate 172.16.1.0/30[V] 0
25 Untagged 172.16.1.2/32[V] 0 Se0/1 point2point
26 Untagged 192.168.1.0/24[V] 0 Se0/1 point2point
Fonte: Elaboração do autor, 2010
Conforme as informações mostradas no quadro 16, a tabela de encaminhamento dos rótulos MPLS sofreu alterações quando comparada ao quadro 12 da seção Modelo Conceitual 1 – MPLS com OSPF do tutorial parte I. Para cada rede associada a uma VRFs, foi adicionado um novo rótulo. Observado também que, mesmo contendo endereços IPs iguais, o mecanismo de encaminhamento MPLS tratará de maneira diferenciada cada rede, tendo como base a associação das VRFs em cada interface. O parâmetro Aggregate significa que para esse prefixo, o rótulo será removido do pacote, e então será feito uma consulta na tabela de roteamento (nesse caso a tabela de roteamento da VRF). Já o Untagged, indica que o rótulo será removido e encaminhado para o próximo salto. Os endereços 172.16.1.2/32 e 192.168.1.0/24, pertencem a roteadores CEs, não farem parte da rede MPLS, portanto não participaram do processo LDP do MPLS.
Da mesma forma como foi mostrado no quadro 16, no quadro 17 as mesmas informações foram coletadas só que desta vez no ilustrando a saída no roteador PE2.
- Código:
ROUTER_PE_2#show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 220.110.90.4/32 0 Fa0/0 220.110.90.17
17 Pop tag 220.110.90.3/32 0 Fa0/1 220.110.90.21
18 18 220.110.90.1/32 0 Fa0/1 220.110.90.21
16 220.110.90.1/32 0 Fa0/0 220.110.90.17
19 Pop tag 220.110.90.8/30 0 Fa0/0 220.110.90.17
20 Pop tag 220.110.90.12/30 0 Fa0/1 220.110.90.21
21 Aggregate 172.16.2.0/30[V] 0
22 Untagged 172.16.2.2/32[V] 0 Se0/0 point2point
23 Untagged 192.168.2.0/24[V] 0 Se0/0 point2point
24 Aggregate 172.16.2.0/30[V] 0
25 Untagged 172.16.2.2/32[V] 0 Se0/1 point2point
26 Untagged 192.168.2.0/24[V] 0 Se0/1 point2point
Fonte: Elaboração do autor, 2010
Depois de verificar o funcionamento da arquitetura BGP/VPN MPLS nos roteadores PEs, verificou-se também o funcionamento entre os roteadores CEs. No quadro 18 mostra o resultado dos testes realizados com pacotes ICMP disparados do roteador CE1 para o endereço da interface FastEthernet0/0 do CE2, testando a conectividade da VPN_A, e entre CE3 e CE4 testando a conectividade da VPN_B mostrados no quadro 19.
- Código:
ROUTER_CE_1#ping 192.168.2.1 repeat 500
Type escape sequence to abort.
Sending 500, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!
Success rate is 100 percent (500/500), round-trip min/avg/max = 4/16/68 ms
Fonte: Elaboração do autor, 2010
- Código:
ROUTER_CE_3#ping 192.168.2.1 repeat 500
Type escape sequence to abort.
Sending 500, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!
Success rate is 100 percent (500/500), round-trip min/avg/max = 4/17/92 ms
Fonte: Elaboração do autor, 2010
De acordo com os resultados verificados nos quadros 18 e 19, constatou-se que tanto a conectividade da VPN_A quando da VPN_B está em perfeito funcionamento. Outro fator importante analisado também foi o caminho percorrido entre CE1 e CE2 através do comando traceroute, conforme o quadro abaixo.
- Código:
ROUTER_CE_1#traceroute 192.168.2.1
Type escape sequence to abort.
Tracing the route to 192.168.2.1
1 172.16.1.1 20 msec 12 msec 8 msec
2 220.110.90.13 36 msec 24 msec 16 msec
3 172.16.2.1 12 msec 8 msec 12 msec
4 172.16.2.2 16 msec 32 msec *
Fonte: Elaboração do autor, 2010
Verificou-se no quadro 20 que o caminho percorrido entre os roteadores CE1 e CE2, conectados na VPNA é: CE1?PE1? P1? PE2? CE2.
Apesar do IP público 220.110.90.13 referente ao roteador P1 aparecer no caminho percorrido até o CE2, não é possível “pingar” nesse equipamento conforme mostrado no quadro 21.
- Código:
ROUTER_CE_1#ping 220.110.90.13 repeat 50
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 220.110.90.13, timeout is 2 seconds:
U.U.U.U.U.U.U.U.U.U.U.U.U.U.U.U.U.U.U.U.U.U.U.U.U.
Success rate is 0 percent (0/50)
Fonte: Elaboração do autor, 2010
O retorno “U” significa nesse caso, que os pacotes estão sendo transmitidos do roteador CE1, porém o roteador P1 não tem uma entrada na tabela de roteamento para retornar o pacote. Isso mostra que a conexão da VPN de fato está isolada.
Sabendo-se que o caminho percorrido é CE1?PE1? P1? PE2? CE2, foi verificado como os protocolos de roteamento fazem a convergência de rota em caso de falhas.
No exemplo apresentado no quadro 22 foi provocado uma falha no P1 , colocando em shutdown a interface FastEthernet1/1 que da acesso ao PE1, logo após disparar os pacotes do CE1 para o C2. Segue o teste abaixo:
- Código:
ROUTER_CE_1#ping 192.168.2.1 repeat 500
Type escape sequence to abort.
Sending 500, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!...!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!
Success rate is 99 percent (497/500), round-trip min/avg/max = 1/17/60 ms
Fonte: Elaboração do autor, 2010
- Código:
ROUTER_P_1> enable
ROUTER_P_1# configure-terminal
ROUTER_P_1(config)# interface fastEthernet 1/1
ROUTER_P_1(config-if)# shutdown
ROUTER_P_1(config-if)#
*Nov 1 03:54:42.498: %OSPF-5-ADJCHG: Process 1, Nbr 220.110.90.1 on FastEthernet1/1 from FULL to DOWN, Neighbor Down: Interface down or detached
*Nov 1 03:54:42.518: %LDP-5-NBRCHG: LDP Neighbor 220.110.90.1:0 (1) is DOWN (Interface not operational)
*Nov 1 03:54:44.474: %LINK-5-CHANGED: Interface FastEthernet1/1, changed state to administratively down
*Nov 1 03:54:44.478: %ENTITY_ALARM-6-INFO: ASSERT INFO Fa1/1 Physical Port Administrative State Down
*Nov 1 03:54:45.474: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/1, changed state to down
Fonte: Elaboração do autor, 2010
- Código:
ROUTER_CE_1#traceroute 192.168.2.1
Type escape sequence to abort.
Tracing the route to 192.168.2.1
1 172.16.1.1 12 msec 16 msec 4 msec
2 220.110.90.9 12 msec 16 msec 16 msec
3 172.16.2.1 8 msec 32 msec 72 msec
4 172.16.2.2 16 msec 28 msec *
Fonte: Elaboração do autor, 2010
Pode-se observar que a topologia proposta para analise, configurada com os protocolos de roteamento OSPF (para comunicação da nuvem pública) e BGP (para comunicação das VPNs em nuvem privada), reagiu com rapidez à falha. No quadro 21, observou-se que apenas 3 pacotes foram perdidos dos 500 disparados, isso devido ao poder de convergência que o protocolo OSPF oferece. Posteriormente no quadro 24 foi realizado novamente o comando traceroute, e mostrou que a conversão da rota para o IP 220.110.90.9 do roteador P2, foi realizado com sucesso, traçando a rota CE1?PE1? P2? PE2? CE2.
Última edição por Felipe Marques em Sáb 11 maio - 9:44, editado 1 vez(es)
