Multi Protocol Label Switching - teleco.com.br · MPLS no GNS3 da seção Modelo Conceitual 1 ......

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.

1

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

esniffers.

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

osbackbones (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

2

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.

3

Redes MPLS II: 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.

4

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


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


5

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


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.

6

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)# 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)# 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

Quadro 1: Configuração de VPN MPLS no PE1


7

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



!

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

!



ip address 220.110.90.14 255.255.255.252

speed 100

full-duplex


mpls ip

!

interface Serial0/1


ip vrf forwarding VPN_B

ip address 172.16.1.1 255.255.255.252

encapsulation ppp

clock rate 128000

!

Quadro 2.a: Verificação das configurações do roteador PE1 (parte inicial)


8

!

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 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

!

Quadro 2.b: Verificação das configurações do roteador PE1 (parte final)


9


!

ip vrf VPN_A

rd 100:110



!

ip vrf VPN_B

rd 100:120



!

interface Loopback0

ip address 220.110.90.2 255.255.255.255

!



ip address 220.110.90.18 255.255.255.252

speed 100

full-duplex


mpls ip

!

interface Serial0/0


ip vrf forwarding VPN_A

ip address 172.16.2.1 255.255.255.252

encapsulation ppp

clock rate 128000

!



ip address 220.110.90.22 255.255.255.252

speed 100

full-duplex


mpls ip

!

interface Serial0/1


ip vrf forwarding VPN_B

ip address 172.16.2.1 255.255.255.252

encapsulation ppp

clock rate 128000

!

Quadro 3.a: Verificação das configurações do roteador PE2 (parte inicial)

10

!

router ospf 1


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 static

no synchronization

exit-address-family

!

address-family ipv4 vrf VPN_A


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

!

Quadro 3.b: Verificação das configurações do roteador PE2 (parte final)


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.

11

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

Quadro 4: Configurações do CE1


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;

12

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 nos CEs.

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

!


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

!

d

Quadro 5: Verificação das configurações do CE1


13


!


network 192.168.2.0 255.255.255.0

default-router 192.268.2.1 255.255.255.0

!



ip address 192.168.2.1 255.255.255.0

duplex auto

speed auto

!

interface Serial0/0


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

!



14


!


network 192.168.1.0 255.255.255.0

default-router 192.168.1.1 255.255.255.0

!



ip address 192.168.1.1 255.255.255.0

duplex auto

speed auto

!

interface Serial0/0


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

!




!


network 192.168.2.0 255.255.255.0

default-router 192.168.2.1 255.255.255.0

!



ip address 192.168.2.1 255.255.255.0

duplex auto

speed auto

!

interface Serial0/0


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

!


15


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.

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





Quadro 9: Verificação da tabela de roteamento do PE1


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.

16

ROUTER_PE_1#show ip route vrf VPN_A

-- Omitido --



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


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

Quadro 10: Verificação da tabela de roteamento da vrf VPN_A no PE1


ROUTER_PE_1#show ip route vrf VPN_B

-- Omitido --



B 172.16.2.2/32 [200/0] via 220.110.90.2, 08:30:01


B 172.16.2.0/30 [200/0] via 220.110.90.2, 08:30:01


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

Quadro 11: Verificação da tabela de roteamento da vrf VPN_B no PE1


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.

17

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 ?

Quadro 12: Verificação da tabela de roteamento VPNv4 do BGP no PE1


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.

18

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 ?

Quadro 13: Verificação da tabela de roteamento VPNv4 do BGP no PE2


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.

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)

Quadro 14: Teste com pacotes ICMP para o ip da VPN_A do PE1


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.

19

ROUTER_PE_1#ping vrf VPN_A 172.16.1.1 repeat 50



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (50/50), round-trip min/avg/max = 4/25/76 ms

Quadro 15: Teste com pacotes ICMP para o IP da VPN_A do PE1


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.

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


24 Aggregate 172.16.1.0/30[V] 0



Quadro 16: Saída do comando show mpls forwarding-table do PE1


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.

20

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.

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



24 Aggregate 172.16.2.0/30[V] 0



Quadro 17: Saída do comando show mpls forwarding-table do PE2


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.

ROUTER_CE_1#ping 192.168.2.1 repeat 500



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!


Quadro 18: Teste com pacotes ICMP entre o CE1 e CE2


21




!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!


Quadro 19: Teste com pacotes ICMP entre os roteadores CE3 e CE4


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.

22

ROUTER_CE_1#traceroute 192.168.2.1


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 *

Quadro 20: Verificação do caminho entre o CE1 e CE2


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.




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)

Quadro 21: Verificação do caminho entre o CE1 e CE2


23

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:




!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!...!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!


Quadro 22: Teste com pacotes ICMP entre o CE1 e CE2


24

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

Quadro 23: Provocamento de falha na interface FastEhernet1/1 P1


ROUTER_CE_1#traceroute 192.168.2.1


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 *

Quadro 24: Verificação do caminho entre o CE1 e CE2 após falha provocado no P1


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.

Testes com Virtual Box

Os testes realizados nesse tópico tiveram um ponto de vista do usuário final. Para esse teste foi recorrido

ao Virtual Box. O sistema operacional virtualizado foi Ubuntu 10.4 nos computadores C1 e C2 aos

25

roteadores CE1 e CE2, realizando testes e gerando tráfego através da rede. O protocolo usado para esse

fim foi o FTP (File Transfer Protocol).

O FTP é um dos protocolos mais usados para transferência de arquivos na rede. Para melhor ilustrar o

processo de login e transferência do arquivo, o serviço HTTP (Hypertext Transfer Protocol) também foi

usado. O HTTP é usado para comunicação de sites. Todos os dois serviços foram disponibilizados no

computador C2 conectado a interface FastEthernet0/0 do roteador CE2.

As figuras 3 e 4 mostram como ficaram as configurações de endereçamento IP dos computadores C1 e

C2. Na figura 5 foi realizado teste de conectividade, onde foram disparados 20 pacotes ICMP do C1 para

o C2, e na figura 6 disparados do C2 para o C1. Já nas figuras 7 e 8, foi mostrado o caminho percorrido

pelo pacote para chegar de um ponto a outro na rede.

E por fim nas figuras 9, 10 e 11, exibem respectivamente o processo de login no servidor FTP do

computador C2, selecionamento do arquivo a ser transferido e a transferência do arquivo.

Figura 3: Verificação das configurações de endereço IP no C1


26

Figura 4: Verificação das configurações de endereço IP no C2


27

Figura 5: Teste de conectividade com pacote ICMP entre C1 e C2


28



29

Figura 7: Caminho percorrido entre C1 e C2


30



31

Figura 9: C1 efetuando login FTP no C2


32

Figura 10: Selecionamento do arquivo para transferência


33

Figura 11: Transferindo arquivo do C2 para C1


Após a realização de todos os teste entre roteadores Ps, PEs e CEs na topologia proposta, nesse tópico

pode-se observar que da mesma forma os computadores C1 e C2, ligados respectivamente nos roteadores

CE1 e CE2, comunicaram-se de um ponto a outro da rede sem problemas. As informações trafegadas na

rede foram coletadas com o Wireshark para análise no próximo tópico.

Análises com o Wireshark

Com base nas informações extraídas nos tópicos anteriores referentes ao BGP/MPLS VPN, foram

analisadas alguns pacotes relevantes ao tema. A seguir foram capturados alguns pacotes recorrendo

ao Wireshark.

34

Figura 12: Captura dos pacotes BGP entre o nó P1 e PE1


Na figura 12, observou-se que logo após o estabelecimento do OSPF, os pacotes BGP começam a ser

enviados na rede com o finalidade de encontrar vizinhos. No pacote 129, pode verificar que trata-se de

uma mensagem OPEN, usado para iniciar uma sessão BGP. Em destaque, no cabeçalho MPLS o

campo Label já está rotulado com o valor “20”. Assim como no OSPF e LDP, a identificação do BGP

também é associada ao endereço IP da interface loopback, nesse caso 220.110.90.1.

Logo abaixo em destaque, dentro do campo Capabilities Advertisement, a extensão Multiprotocol do

protocolo BGP já aparece agregado a mensagem. Dentro desse campo onde são transportadas

informações de VPN IPv4 address-family , visto com mais detalhes na figura 13.

35

Figura 13: Captura do pacote BGP entre o nó P1 e PE1


O pacote 170 mostrado na figura 13 trata de uma mensagem tipo UPDATE. Nesse pacote a

extensãoMultiprotocol do BGP aparece com mais detalhes. O atributo MP_REACH_NLRI, contém todas

as informações referentes à VPN_A do roteador PE1. Sabe-se disso pela identificação do RD com os

valores “100:110” . Na configuração dos roteadores PE1 e PE2 esses valores são associados a uma vrf

(com o comando ip vrf VPN_A). Observou-se também que para cada prefixo de endereço IP foi atribuída

a um rótulo diferente, conforme já visto anteriormente no quadro 15.

36

Figura 14: Captura do pacote BGP entre o nó P1 e PE1


Já no pacote 171 da figura 14, observou-se na mensagem UPDATE que também possuiu informações

sobre a extensão Multiprotocol do BGP, só que agora referente ao encaminhamento da VPN_B,

constatada pela identificação do RD 100:120. Da mesma forma como aconteceu com a VPN_A, na

VPN_B foram atribuídos diferentes valores de rótulos para cada prefixo de endereço IP. Assim, cada

pacote destinado à esses endereços da VPN_B (neste caso), receberão uma etiqueta, otimizando o tráfego

durante a passagem na rede. Nas figuras abaixo segue exemplos da marcação em diferentes tipos de

tráfego.

37

Figura 15: Captura do pacote ICMP entre o nó P1 e PE1


Como exemplo do tráfego entre host à host, temos o a captura do pacote 231. Esse pacote é do tipo

ICMP, usado para testar a conectividade da rede. Foram aproveitados os testes do tópico anterior, para

coletar informações relevantes ao funcionamento da BGP/MPLS VPN. Pode-se observar que o pacote

ICMP foi rotulado com o valor 23 com destino ao endereço 192.168.1.2. Com base na figura 12, conclui-

se que de fato esse pacote está sendo encaminhado à VPN_A, já que a RD 100:110 está vinculada a vrf

VPN_A do roteador PE1.

38

Figura 16: Captura do pacote FTP entre o nó P1 e PE1


No pacote 499 da figura 16, o destino e o rótulo são os mesmo do exemplo anterior, com a diferença que

agora trata-se de um pacote FTP. Como ilustrado no teste de transferência da figura 10, o computador

CE1 fez uma solicitação para transferir um determinado arquivo. Conforme observado acima, o sentido

do tráfego é C2 para C1, de acordo com a captura no campo Source e Destination.

39

Redes MPLS II: Modelo Conceitual 3 – IPsec em Redes IP

Esta seção continua a apresentação da seção anterior, relativa às 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.

Configuração do IPsec em Redes IP

Nessa análise, a proposta foi configurar e analisar uma conexão VPN IPsec ponto à ponto básica no modo

túnel, criado em cima de uma infraestrutura de rede pública. A figura 17 ilustra como ficou a nova

topologia.

Figura 17: Captura da topologia VPN IPSec em análise do GNS3


Para isso foram usados os mesmos equipamentos de rede MPLS, porém removidas as configurações de

roteamento BGP e MPLS dos roteadores Ps e PEs, aproveitando o roteamento global do OSPF que já

havia sido adotado. Para a comunicação entre roteadores Ps e PEs também foi aproveitado os mesmos

endereços IPs, acrescentando duas novas faixas de endereço global com prefixo /30, para a comunicação

das interfaces seriais que dão acesso aos roteadores CEs. Para os roteadores CEs, apenas dois roteadores

foram usados, CE1 e CE2 com dois computadores ligados a eles C1 e C2.

Da mesma forma com que foi realizado nos tópicos anteriores, nessa experiência foram também usados as

ferramentas GNS3 para emulação dos roteadores, Wireshark para analise dos pacotes trafegados, e

o Virtual Box para gerar tráfego de um host à outro na rede. As tabelas 6, 7 e 8, mostram como ficou a

relação endereço IP/Interfaces dos roteadores.

40

ROTEADOR LOOPBACK0 FASTETHERNET1/0 FASTETHERNET1/1

P1 220.110.90.3/32 220.110.90.21/30 220.110.90.13/30

P2 220.110.90.4/32 220.110.90.9/30 220.110.90.17/30

Tabela 3: Relação de endereço IP/interface dos roteadores Ps


ROTEADOR LOOPBACK0 FASTETHERNET0/0 FASTETHERNET0/1 SERIAL0/0

PE1 220.110.90.1/32 220.110.90.10/30 220.110.90.14/30 190.80.10.1/30

PE2 220.110.90.2/32 220.110.90.18/30 220.110.90.22/30 180.70.10.1/30

Tabela 4: Relação de endereço IP/interface dos roteadores PEs


ROTEADOR FASTETHERNET0/0 SERIAL0/0

CE1 192.168.1.1/24 190.80.10.2/30

CE2 192.168.2.1/24 180.70.10.2/30

Tabela 5: Relação de endereço IP/interface dos roteadores CEs


Com base nos valores das tabelas, segue como ficaram as configurações dos roteadores P1 e PE1

mostrados nos quadros 25 e 26, referentes somente ao que é necessário para o funcionamento na

topologia. Como nos tópicos anteriores, as informações que por padrão já vem configuradas foram

omitidas dando ênfase ao que fato é necessário para o funcionamento.

41

ROUTER_P_1#show running-config

Building configuration...

!

interface Loopback0

ip address 220.110.90.3 255.255.255.255

!



ip address 220.110.90.21 255.255.255.252

duplex full

speed 100

!


description # ACESSO PE1 ##

ip address 220.110.90.13 255.255.255.252

duplex auto

speed 100

!

router ospf 1


network 220.110.90.3 0.0.0.0 area 0

network 220.110.90.13 0.0.0.0 area 0

network 220.110.90.21 0.0.0.0 area 0

!

Quadro 25: Verificação das configurações do P1


Observou-se no quadro 25 que os roteadores de núcleo não sofreram grandes modificações, apenas foram

removidas as configurações do MPLS. As configurações do roteador P2 ficou bem semelhante as

configurações do roteador P1, mudando apenas os parâmetros de endereçamento IP das

interfacesFastEthernet e loopback conforme a tabela 6. No quadro 26, verificou-se como ficou as

configurações do PE1.

42



!

interface Loopback0

ip address 220.110.90.1 255.255.255.255

!



ip address 220.110.90.10 255.255.255.252

speed 100

full-duplex

!

interface Serial0/0

bandwidth 128000

ip address 190.80.10.1 255.255.255.252 no ip proxy-arp

encapsulation ppp

clock rate 128000

!



ip address 220.110.90.14 255.255.255.252

speed 100

full-duplex

!

interface Serial0/1

ip address 190.80.10.5 255.255.255.252 encapsulation ppp

clock rate 128000

!

router ospf 1



redistribute static

network 190.80.10.0 0.0.0.3 area 0

network 190.80.10.4 0.0.0.3 area 0 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

!

Quadro 26: Verificação das configurações do PE1


Em seguida foi verificado também as configurações dos roteadores PE1 mostradas no quadro 27.

43



!

interface Loopback0

ip address 220.110.90.2 255.255.255.255

!



ip address 220.110.90.18 255.255.255.252

speed 100

full-duplex

!

interface Serial0/0

bandwidth 128


clock rate 128000

!



ip address 220.110.90.22 255.255.255.252

speed 100

full-duplex

!

interface Serial0/1


clock rate 128000

!

router ospf 1



redistribute static

network 180.70.10.0 0.0.0.3 area 0

network 180.70.10.4 0.0.0.3 area 0 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

!

Quadro 27: Verificação das configurações do PE2


Nas configurações dos roteadores PE1 e PE2, já houve uma mudança significativa. Pode-se observar em

destaque que além de remover as configurações de funcionamento do MPLS, foram incluídas também

novas faixas de endereçamento IP públicos para cada interface serial, como também, a divulgação dessas

redes no roteamento OSPF. Essas configurações garante uma conectividade totalmente IP na topologia

propostas, como também o roteamento necessário para o acesso dos roteadores CEs.

Nas configurações dos roteadores CEs, os endereços IPs da interface FastEthernet0/0 permaneceram os

mesmos como também as configurações do DHCP. Porém os endereços IPs das interfaces seriais foram

alterados para endereços públicos conforme a Tabela 8. Segue abaixo como ficaram as configurações do

roteador CE1.

44



!

ip dhcp pool host1

network 192.168.1.0 255.255.255.0

default-router 192.168.1.1 255.255.255.0

!

crypto isakmp policy 10 hash md5

authentication pre-share

group 2

!

crypto isakmp key secret1 address 180.70.10.2 !

crypto ipsec transform-set CE1 esp-des esp-md5-hmac !

crypto map VPN_CE1 70 ipsec-isakmp set peer 180.70.10.2

set transform-set CE1

match address 100

!


ip address 192.168.1.1 255.255.255.0

duplex auto

speed auto

!

interface Serial0/0

bandwidth 128

ip address 190.80.10.2 255.255.255.252

encapsulation ppp

crypto map VPN_CE1 !

ip route 0.0.0.0 0.0.0.0 190.80.10.1

ip route 192.168.2.0 255.255.255.0 180.70.10.2 !

access-list 100 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 !



No quadro 28 verificou-se as configurações do roteador CE1. Em destaque alguns parâmetros relevantes

para a construção da VPN IPsec como também os métodos usados nas segurança das informações.

No primeiro destaque temos o comando crypto isakmp policy 10. Esse comando cria uma política para o

gerenciamento para a troca de chaves. Seguido dos comandos hash MD5, (criptografa a

autenticação), authentication pre-share (especificado o modo pré-compartilhado para troca de chaves)

egroup2 (aciona o método de criptografia Diffie-Hellamn com 1024 bits, na troca de chaves). Por padrão,

o algoritmo usado para a proteção do túnel dos dados é o DES (Data Encryption Standard) com chave de

56 bits.

45

No segundo destaque aparece o comando crypto isakmp key secret1 address 180.70.10.2. Esse comando

informa a senha e o endereço IP da ponta remota da conexão VPN, ou seja, o IP público do roteador CE2.

Da mesma forma, esse mesmo comando foi usado no roteador CE2, porém apontando para o IP público

do CE1. Em seguida foi apresentado o comando crypto ipsec transform-set CE1 esp-des esp-md5-hma,

que cria com o nome CE1 um conjunto de métodos para a negociação e segurança do tráfego.

No próximo destaque aparece o comando crypto map VPN_CE1 70 ipsec-isakmp, que mapeia com o

nome VPN_CE1 as regras para aplicação das políticas da VPN. Seguido dos comandos set peer

180.70.10.2 (indica a outra ponta da conexão), set transform-set CE1 (associando a negociação CE1)

ematch address 100 (associa a lista de acesso 100 ao tráfego que será protegido). Em seguida, abaixo do

comando interface Serial0/0, foi aplicado o comando crypto map VPN_CE1, que associa as regras criadas

para a conexão VPN, á interface de saída do roteador CE1.

Para o roteamento estático além da rota padrão, foi adicionada outra rota indicando que para chegar na

rede 192.168.2.0, correspondente a rede local do roteador CE2, os pacotes precisão ser encaminhado ao

IP 180.70.10.2 (IP da interface serial do CE2).

E por último o comando access-list, ou lista de acesso. Esse comando permite mapear o endereço IP, ou

uma faixa de endereço IP, para aplicar posteriormente como política em outro comando. Nesse caso

a access-list 100, mapeou a origem e o destino das faixas IPs do tráfego interessante, que será protegido

no túnel. O mesmo ocorre com o roteador CE2, porém em ordem inversa. Essa lista de acesso foi aplicado

dentro da regra crypto map VPN_CE1 70 ipsec-isakm como foi visto. No quadro 29 foi mostrado como

ficou as configurações no roteador CE2.

46



!

ip dhcp pool host2

network 192.168.2.0 255.255.255.0

default-router 192.168.2.1 255.255.255.0

!

crypto isakmp policy 10

hash md5

authentication pre-share

group 2

crypto isakmp key secret1 address 190.80.10.2

!

crypto ipsec transform-set CE2 esp-des esp-md5-hmac

!

crypto map VPN_CE2 10 ipsec-isakmp

set peer 190.80.10.2

set transform-set CE2

match address 100

!


ip address 192.168.2.1 255.255.255.0

duplex auto

speed auto

!

interface Serial0/0

bandwidth 128

ip address 180.70.10.2 255.255.255.252

encapsulation ppp

clock rate 128000

crypto map VPN_CE2

!

ip route 0.0.0.0 0.0.0.0 180.70.10.1

ip route 192.168.1.0 255.255.255.0 190.80.10.2

!

access-list 100 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

!



Testes e Análises do IPsec

Depois de verificar como ficaram todas as configurações dos roteadores na rede em seguida foram

realizado alguns testes a fim de verificar o funcionamento do IPsec na topologia proposta. Os teste

relacionados abaixo foram analisado somente nos roteadores CE1 e CE2, considerando que os roteadores

Ps e PEs estão em funcionamento, e não participam diretamente do processo funcional da VPN. O papel

dos Ps e PEs nesse caso é fornecer o acesso e transporte dos dados. Nos quadros 30 e 31 foram exibidas

algumas saídas relevantes ao funcionamento do túnel.

47

ROUTER_CE_1#show crypto isakmp sa

IPv4 Crypto ISAKMP SA

dst src state conn-id slot status

180.70.10.2 190.80.10.2 QM_IDLE 1001 0 ACTIVE

IPv6 Crypto ISAKMP SA

Quadro 30: Verificação do comando show crypto isakmp sa no CE1


O comando show de criptografia isakmp sa mostra as SAs, ou associações seguras do gerenciador IKE

atual. O "Active" status significa que o ISAKMP SA está em estado ativo. O modo QM_IDLE indica que

o túnel está funcionado perfeitamente, ou seja, a SA IPSec permanece autenticado e túnel pode ser usado

para transmitir os dados. Os parâmetros dst e src, indicam respectivamente o destino e a origem do túnel,

onde a origem é o IP da interface serial do CE1 e a destino a o IP da interface serial do CE1.

A seguir foi analisado outros parâmetros com a saída do comando show crypto ipsec sa, omitindo apenas

algumas informações desnecessárias para essa análise.

48

ROUTER_CE_1#show crypto ipsec sa

interface: Serial0/0

Crypto map tag: VPN_CE1, local addr 190.80.10.2

protected vrf: (none)

local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0)

current_peer 180.70.10.2 port 500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 628, #pkts encrypt: 628, #pkts digest: 628

#pkts decaps: 628, #pkts decrypt: 628, #pkts verify: 628

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 1, #recv errors 0

local crypto endpt.: 190.80.10.2, remote crypto endpt.: 180.70.10.2

path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0

current outbound spi: 0x12E283CF(316834767)

inbound esp sas:

spi: 0xA46958F6(2758367478)

transform: esp-des esp-md5-hmac ,

in use settings ={Tunnel, }

conn id: 1, flow_id: SW:1, crypto map: VPN_CE1

sa timing: remaining key lifetime (k/sec): (4520277/2289)

IV size: 8 bytes

replay detection support: Y

Status: ACTIVE

outbound esp sas:

spi: 0x12E283CF(316834767)

transform: esp-des esp-md5-hmac ,

in use settings ={Tunnel, }

conn id: 2, flow_id: SW:2, crypto map: VPN_CE1

sa timing: remaining key lifetime (k/sec): (4520277/2288)

IV size: 8 bytes

replay detection support: Y

Status: ACTIVE

Quadro 31: Verificação do comando show crypto ipsec sa no CE1


Foram exibidas através do comando show crypto ipsec sa, informações importante sobre o IPsec. No

primeiro destaque, mostra o IP e o número da porta que eles em que então se comunicando. Logo abaixo

algumas informações sobre pacotes transmitidos que foram encriptados e desencriptados. Na outro

destaque é exibido o ip do túnel local e o remoto. E nos dois destaques seguinte mostra que tanto a

entrada quanto a saída do túnel estão ativas.

Testes com o Virtual Box

49

Os testes realizados a seguir, foram recorridos ao Virtual Box, virtualizando o sistema operacional Ubuntu

10.4, conectados nos roteadores CE1 e CE2 a fim de gerar um tráfego no túnel VPN. Na figura 18 foram

apresentados os testes de conectividade da VPN, disparando 20 pacotes ICMP computador C1 ligado no

roteador CE1 ao computador C2 conectado ao CE1. Considerando os computadores já devidamente

configurados com o endereçamento IP correspondente a cada rede, foi obtido os seguintes resultados.



50



Observou-se nas figuras 18 e 19, que o túnel VPN funcionou normalmente sem perdas. Dos 20 pacotes

disparados do C1 para o C2, 20 obtiveram resposta. O mesmo ocorreu entre C2 e C1.

A seguir nas figuras 20 e 21, foram verificados os caminhos percorridos de um ponto a outro da rede. No

resultado aparecem somente o IP do gateway padrão da rede local e o IP do computador da rede remota.

Isso ocorre devido a construção dos túneis nas VPN, assegurando que as informações sejam isoladas da

rede pública por onde estão sendo transportadas. Nas figuras 20 e 21 pode-se ver os resultados.

51



52



Testes com o Wireshark

Após a realização dos testes entre os computadores C1 e C2, uma analise do tráfego foi realizada

recorrendo novamente ao Wireshark. Durante os testes mostrados anteriormente, foram efetuadas

capturas de pacotes para a verificação das informações trocadas durante essa fase. A proposta foi mostrar

se realmente os pacotes que trafegam nos túneis IPsec são protegidos, e se de alguma maneira esses

pacotes, em caso de captura por terceiros, exibirá alguma informação que implique na segurança das

informações.

A Captura mostrada na figura 22 foi realizada entre os roteadores P1 e PE1.

53

Figura 22: Captura do pacote ISAKMP entre P1 e PE1


Na captura do pacote 81 ilustrado na figura 22, pode-se ver que é um pacote ISAKMP (Internet Security

Association and Key Management Protocol) responsável pela negociação das chaves para o

estabelecimento do túnel. Pode-se ver também que é um pacote UDP (User Datagram Protocol), na porta

500. O UDP é um protocolo não orientado a conexão, ou seja, não oferece garantia nenhuma para o

pacote chegar ao seu destino. O IPsec usa o UDP, porque os mecanismos de controle e confiabilidades

sobre a transmissão dos pacotes, fica sobre a responsabilidade do próprio IPsec.

Observou-se no segundo destaque da figura 22 que o tipo de encriptação do

campo payload(correspondente aos dados que de fato estão sendo transmitidos), usa o algoritmo de

encriptação DES (Data Encryption Standard) conforme já mencionado. Outro parâmetro verificado

anteriormente, que foi capturado em seguida pelo Wireshark, aparece no destaque seguinte, informando

que está sendo usado group2 para a troca de chaves e o MD5 para criptografar a autenticação.

A F mostra um pacote encapsulado com o protocolo ESP (Encapsulating Security Payload). Esse

protocolo é usado pelo IPsec para fornecer confiabilidade e autenticação da origem.

54

Figura 23: Captura do pacote ESP entre P1 e PE1


Pode-se ver que apenas algumas informações poderão ser visualizadas no cabeçalho IP, como a origem e

o destino do pacote. No campo ESP é informado apenas a sequência que os dados serão entregues na

outra extremidade. Observou-se que e fato, as informações transportadas pelos mecanismos de segurança

do IPsec, não ficaram expostas na rede, provando ser um protocolo seguro para o transporte das

informações em redes IPs públicas.

55

Redes MPLS II: Análise Comparativa Quando se trata de conectar vários sites com links WAN, há uma variedade de opções viáveis. Naturalmente, a solução que é certa para uma empresa irá variar dependendo do tamanho da estrutura dessa empresa, o tipo de tráfego que precisa para transmitir, e suas preferências em matéria de segurança, latência e confiabilidade. As desvantagens para túneis VPN Ipsec é que os dados são criptografados, com isso há sobrecarga (latência) associado com a criptografia, a segurança é uma preocupação ainda maior, e a confiança pode ser diminuída devido à complexidade da Internet. Algumas empresas podem até mesmo escolher os links de Internet ADSL para executar túneis VPN de site para site. Enquanto os links de Internet DSL pode ser uma boa opção para uma pequena empresa, eles geralmente são insuficientes para uma empresa que dependem de dados críticos, devido à baixa prioridade oferecida por operadoras de serviço nesses casos. O MPLS é feito geralmente para dar ao cliente um link IP dedicado com endereçamento IP privado sobre ele. Qualquer tráfego enviado do cliente para a transportadora, nesse link, é rotulado. Esse pacote rotulado é enviado através de um caminho marcado switch (LSP) a um roteador switch etiqueta (LSR). Esse roteador encaminha o pacote para o roteador de borda da etiqueta (LER), onde o rótulo é removido do pacote e entregue ao roteador do cliente de destino. Isso possibilita para o cliente criar uma rede privada sem nenhuma criptografia necessária. Um dos principais benefícios do MPLS é que ele cria uma rede totalmente entrelaçada por padrão. Então, por ser ligado à rede MPLS, pode-se ter uma conexão direta com todas as localizações remotas sem qualquer custo adicional ou configuração. Serviços de voz sobre IP (VoIP) é um desafio para implementar sobre túneis VPN Ipsec site-to-site, pois a criptografia causa muita latência. Além do VoIP, outros serviços de QoS podem ser oferecidos em redes MPLS, priorizando certos tipos de tráfego. Para melhor exemplificar os pós e contras de cada uma das tecnologias, a tabela 9 faz uma análise comparativa relacionando algumas características típicas relevantes as redes de computadores.

56

Característica

MPLS VPN IPSec VPN

Confiabilidade Todos os circuitos MPLS são

recebidos através de uma única

transportadora, o que contribui com a

confiabilidade. Entretanto, algumas

operadoras de serviço oferecem VPN

em MPLS usando DSL como enlace

local, o que pode resultar em menor

confiabilidade. Em geral, MPLS será

mais confiável do que VPNs IPSec,

porque há menos complicações na

configuração de tunelamento e

firewall.

Receber todos os circuitos IPSec

VPN através da mesma

transportadora vai aumentar a

confiabilidade (tolerância a falhas)

sobre o uso de múltiplas operadoras

de Internet. Mas devido a vários

concentradores VPN e configuração

de criptografia, uma VPN IPSec

pode ser menos confiável do que

VPN em MPLS devido a

complexidade de gerenciar várias

conexões.

Custo O custo de um projeto MPLS para o

fornecimento de VPN é relativamente

alto. Porém em VPNs IPsec exige

mão de obra especializada para o

gerenciamento dos túneis, quanto a

confiabilidade e segurança das

informações, como também

concentradores para agregar links. No

MPLS VPN esses fatores ficam sobre

a responsabilidade da operado de

serviço.

Ao contrário das VPN em MPLS,

em VPN IPSec são necessários

concentradores VPNs, o que irá

aumentar o custo inicial. Depois de

ter o hardware, o pessoal necessário

para manter o sistema e solucionar

problemas dos túneis VPN IPSec, no

final os valores podem aumentar,

podendo ser o mesmo ou até passar

em comparação a VPN em MPLS.

Segurança VPN e MPLS é mais seguro do que

os túneis VPN IPSec, desde que não

permitir que seus circuitos MPLS

tenham acesso diretamente à Internet.

Para maior segurança, as VPNs

MPLS devem ser usadas apenas como

redes privadas. Usado como uma rede

privada, as VPNs MPLS oferecem um

bom nível de segurança, porém tendo

em vista que os dados nesse caso não

são criptografados.

Elementos que compõem uma rede

de túneis VPN IPSec, é uma

preocupação que deve ser levada em

consideração já que os dados estão

sendo transmitidos através de um

link de internet. Esse circuito

Internet está aberto para conexões de

todo o mundo. Um firewall mal

configurado pode abrir uma rede

VPN IPSec para a Internet.

Segurança é uma preocupação ainda

maior se usar a divisão de túnel em

concentradores VPN. Porém os

dados em VPN Ipsec são

criptografados.

QoS As QoS podem ser oferecidas como

serviço nesse caso. Com MPLS QoS,

pode-se priorizar determinados tipos

de tráfego ao longo da rede da

operadora, provendo QoS fim á fim.

Isso é ótimo para aplicações sensíveis

à latência, como Voz, Vídeo.

Recursos de QoS em VPN Ipsec são

bem limitados nesse caso. Ao

trafegarem na rede, os dados são

criptografados gerando atraso e

pouco pode ser feito quando a isso.

Tabela 6: Analise comparativa entre MPLS VPN e IPsec VPN Fonte: Elaboração do autor, 2010

57

Redes MPLS II: Considerações Finais

A tecnologia MPLS desempenha um papel cada vez mais importante no contexto das redes IP. Com este

trabalho pretendeu-se idealizar um conjunto de experiências capaz de ilustrar os principais conceitos e

funcionalidades da tecnologia usando de VPN para entrega segura das informações.

Através da realização deste trabalho foi possível levantar algumas ideias já adquiridas sobre o MPLS. O

MPLS melhora a eficiência das redes onde utilizadas. Foram estudadas as VPNs camada 3 sobre uma

estrutura MPLS, dada a sua importância atual no contexto das redes IP. Nestas experiências utilizaram-se

roteadores de modo a criarem cenários mais próximos da realidade. Em uma analogia com a realidade,

foram criados cenários correspondentes a duas empresas, com uma unidade em cada extremidade da rede.

Ambas necessitam de realizar troca de informação entre elas de maneira segura e eficiente sem que os

dados de uma não interferissem na outra. A rede de núcleo que interliga uma unidade à outra é a mesma

para as duas VPNs, quando estabelecidas entre as unidades permitem o envio de informação sem

qualquer tipo de erros ou perdas. Neste cenário, também observou-se a troca de etiquetas MPLS realizada

na rede de núcleo, o que foi explicado com a ajuda do analisador de redeWireshark.

Verificou-se também que o MPLS desempenha esse papel com muita eficiência, segmentando as redes

com tabelas de roteamento próprias para cada VPN, criando assim as nuvens privadas. O uso do

protocolo de roteamento BGP para a criação das VPN, junto com o protocolo OSPF para o roteamento

dos IPs públicos na estrutura MPLS, oferecem uma infinidade de recursos e soluções para empresas e

organizações. Nos testes realizados em laboratórios pode-se constatar a eficiência dessas tecnologias

quando trabalham juntas.

Nas últimas experiências foram idealizados testes com VPNs IPsec em redes IP públicas tradicionais, sem

o uso da tecnologia MPLS, também usando o GNS3 para emular os roteadores. Foi aproveitada a

topologia central, com os mesmo roteadores e o mesmo protocolo de roteamento público para testar e

analisar alguns aspectos importantes do protocolo. Observou-se de fato que o transporte das informações

com túneis IPsec, assegura a integridade e a confiabilidade das informações. Contudo, o preço dessa

segurança implica na perda desempenho.

Em suma, neste trabalho foram estudadas algumas características importantes do MPLS e referenciados

alguns aspectos importantes. No entanto, dada a extensão do tema muito ficou ainda por estudar. Do

ponto de vista pedagógico, creio que este trabalho no futuro poder vir a ajudar alunos a perceber um

pouco melhor como funciona o MPLS e a utilidade de alguns dos seus principais mecanismos.

Concluiu-se que este projeto demonstra que é possível utilizar simulações para desenvolvimento de novas

tecnologias em diversas áreas de redes de computadores, e que o MPLS usado em conjunto com

protocolos de roteamento para fornecer VPN como serviço, é muito superior às tecnologias de VPN em

redes IPs tracionais. Esse projeto também comprova que é possível desenvolver e testar projetos em rede

IP sem mesmo portar o roteador físico, estudando soluções que muitas vezes é de conhecimento restrito à

operadoras de serviço.

Sugestões para Trabalhos Futuros

Esse trabalho de conclusão de curso pode servir como suporte para novas propostas em soluções usando a

tecnologia MPLS. Os temas como Engenharia de trafico, Classe de Serviços ou QoS, VPN camada 2 e

Roteamento Inter-AS, são alguns exemplos das funcionalidades e serviços que a tecnologia MPLS

suporta, onde poderão ser estudadas e analisadas usando a mesma metodologia aplicada para o estudo de

VPN camada 3.

58

Dificuldades Encontradas

A falta de uma abordagem dessa tecnologia no curso foi um fator que dificultou a pesquisa dos principais

conceitos. A busca de ferramentas que suportassem todos os protocolos envolvidos no MPLS foi outro

fator que implicou na dificuldade da elaboração do trabalho. Não foi possível fazer uma análise de

desempenho mais detalhada, como taxa de transferência, tempo de resposta precisa e latência do tráfego,

devido algumas limitações das ferramentas usadas no trabalho. Em virtude deste motivo, alguns

resultados de testes realizados não foram divulgados neste trabalho.

Referências

UNIX network programming. 2ª ed. Upper Saddle River: Prentice Hall, 1998.

BRENT D. Stewart. CCNP BSCI – Official Exam Certification Guide. 4ª ed. Indianápolis: Cisco Press,

2008.

COLCHER, Sérgio. et al. VOIP – Voz sobre IP. Rio de Janeiro: Elsevier, 2005.

COMER, Douglas E. Redes de Computadores e Internet: Abrange Transmissão de Dados Ligação Inter-

redes e Web. 4ª ed. Editora Bookman: Porto Alegre. 2007.

COSTA, Daniel Gouveia. DNS – Um Guia para Administradores de Redes. Rio de Janeiro: Brasport,

2006.

CUTHBERT L. G.; SPANEL J. C., "ATM the Broadband Telecommunications Solution". The Institution

of Electrical Engineers, 1993.

ENNE, Antônio José Figueiredo. TCP/IP sobre MPLS. Rio de Janeiro: Ciência Moderna Ltda, 2009.

FILIPPETTI, Marco. CCNA 4.1 - Guia Completo de Estudo. Florianópolis: Visual Books, 2008.

FOROUZAN, Behrouz A. Comunicação de Dados e Redes de Computadores. 3ª ed. Porto Alegre:

Bookman, 2006.

McHOES, A. M.; FLYNN, I. M. Introdução aos sistemas operacionais. São Paulo: Pioneira Thomson

Learning, 2002.

MORGAN, B. e LOVERING, N. CCNP ISCW – Official Exam Certification Guide. Indianapolis: Cisco

Press, 2009.

PEPELNJAK, Ivan. et al. MPLS and VPN Architectures. Indianapolis: Cisco Press, 2003.

PEPELNJAK, Ivan e GUICHARD, Jim. MPLS and VPN Architectures. Indianapolis: Cisco Press, 2007.

POSTEL, J. Transmission control protocol: DARPA Internet program, protocol specification. Request for

Comments RFC 793. [online]. http://www.rfc-editor.org/rfc/rfc793.txt. July 2002.

RANJBAR, Amir. CCNP ONT – Official Exam Certification Guide. Indianapolis: Cisco Press, 2007.

REAGAN, James. CCIP – Study Guide. San Francisco: Sybex, 2002.

STEVEN, W. R. TCP/IP illustrated: the protocols. Boston: Addisson-Wesley, 1994.

TANENBAUM, Andrew S. Redes de Computadores. 4ª ed. Rio de Janeiro: Campus, 2006.

59

http://www.rfc-editor.org/rfc/rfc793.txt

TITTEL, Ed. Coleção Schaum. Redes de Computadores. Porto Alegre: Bookman, 2003.

TORRES, Gabriel. Redes de computadores: curso completo. Rio de janeiro: Axecel books, 2001.

60

Redes MPLS II: Teste seu entendimento

1. No modelo conceitual da configuração do BGP/MPLS VPN, qual é a participação dos roteadores

de núcleo P na rede implementada?

Prover o roteamento do BGP.

Prover o BGP/MPLS VPN IPv4.

Prover o transporte dos pacotes rotulados do MPLS.

Prover o roteamento estático para cada VRF.

2. No modelo conceitual da Configuração do IPsec em Redes IP, qual foi a alteração feita na

configuração dos roteadores Ps e PEs?

Remoção dos parâmetros de endereçamento IP das interfaces FastEthernet.

Remoção das duas novas faixas de endereço global com prefixo /30.

Remoção das configurações de roteamento global do OSPF.

Remoção das configurações de roteamento BGP e MPLS.

3. Qual é um dos benefícios de uso da rede MPLS?

Por criar uma rede totalmente entrelaçada, um elemento conectado a essa rede pode ter conexão

direta com todas as localidades remotas sem custo adicional.

Por criar uma rede totalmente entrelaçada, um elemento conectado a essa rede pode ter conexão

indireta com todas as localidades remotas sem custo adicional.

Por criar uma rede totalmente PPP, um elemento conectado a essa rede pode ter conexão direta com

todas as localidades remotas sem custo adicional.

Por criar uma rede totalmente PPP, um elemento conectado a essa rede pode ter conexão indireta

com todas as localidades remotas sem custo adicional.

61

Multi Protocol Label Switching - teleco.com.br · MPLS no GNS3 da seção Modelo Conceitual 1 ......

Documents

Transcript of Multi Protocol Label Switching - teleco.com.br · MPLS no GNS3 da seção Modelo Conceitual 1 ......