Mostrando postagens com marcador ISP. Mostrar todas as postagens
Mostrando postagens com marcador ISP. Mostrar todas as postagens

segunda-feira, 5 de maio de 2014

Fundamentos de VRF na Virtualização de Roteadores

Olá Pessoal.

Esse artigo apresenta os conceitos básicos da tecnologia VRF (Virtual Routing and Forwarding) para fins de virtualização de tabelas de roteamento. De maneira bastante simplista podemos começar pensando da seguinte maneira: assim como VLAN é uma tecnologia para virtualização de switches (layer 2), VRF é uma tecnologia para virtualização de roteadores (layer 3). 

A tecnologia VRF é comumente utilizada por provedores na oferta do serviço VPN/MPLS para conectividade dos seus clientes através de um núcleo comum de equipamentos de grande porte, o que permite o compartilhamento organizado da sua infraestrutura. Com VRF é possível criar diferentes tabelas de roteamento lógicas em um mesmo roteador físico, o que explica a possibilidade de conexão de diversos clientes através de equipamentos compartilhados com garantia de que haverá isolamento total da visualização da topologia da rede e, consequentemente, do tráfego de dados. 

Outra vantagem é que, uma vez que as tabelas de roteamento são logicamente independentes, é possível configurar endereços com sobreposição (overlap) entre o roteador de borda da operadora (PE) e o roteador de borda do cliente (CE), o que é interessante quando os clientes utilizam endereços comuns, algo que ocorre com os endereços privados da RFC 1918 (10/8, 172.16/12 e 192.168/16). 

Para exemplificar o processo de configuração de VRFs estaremos utilizando como base o cenário apresentado abaixo. O PE representa o roteador de borda da operadora que é um equipamento comum a dois clientes, sendo que cada cliente está isolado através de uma VRF lógica que contempla os equipamentos separados nos quadros cinza e verde. Reparem que a rede entre o provedor e os clientes é igual (192.168.0.0/30), o que seria impossível de configurar em situação normal porque o roteador acusaria erro de sobreposição de endereços nas interfaces f0/0 e f1/0.


O processo de configuração do VRF e separação das tabelas de roteamento lógicas é bastante simples nesse exemplo. Basta criar as VRFs e então associar cada interface física (ou sub-interface lógica) com sua respectiva VRF. Ao fazê-lo, o roteador passará a trabalhar com múltiplas tabelas de roteamento distintas, cada uma identificada por seu nome lógico. 

01. PE(config)# ip vrf CINZA
02. PE(config-vrf)# rd 1:1
03. PE(config-vrf)# ip vrf VERDE
04. PE(config-vrf)# rd 2:2
05. PE(config-vrf)# exit
06. PE(config)# int f0/0
07. PE(config-if)# ip vrf forwarding CINZA
08. PE(config-if)# ip address 192.168.0.1 255.255.255.252
09. PE(config-if)# no shut
10. PE(config-if)# int f1/0
11. PE(config-if)# ip vrf forwarding VERDE
12. PE(config-if)# ip address 192.168.0.1 255.255.255.252
13. PE(config-if)# no shut
14. PE(config-if)# int lo1
15. PE(config-if)# ip vrf forwarding CINZA
16. PE(config-if)# ip address 172.30.0.1 255.255.0.0
17. PE(config-if)# int lo2
18. PE(config-if)# ip vrf forwarding VERDE
19. PE(config-if)# ip address 172.20.0.1 255.255.0.0 

Nas linhas de 01 a 04 foram criadas duas VRFs denominadas CINZA e VERDE, sendo que o nome e o valor RD (Route Distinguisher) são válidos localmente. No PE configurei duas interfaces de loopback (linhas de 14 a 19), uma associada com cada cliente. Fazer isso é interessante caso o leitor queira aproveitar o cenário para configurar roteamento entre os roteadores e observar o aprendizado de rotas que ocorre em cada cliente.

O cliente da "VRF CINZA" aprende a rede 172.30.0.0/16, enquanto que o cliente da "VRF VERDE" aprende a rede 172.20.0.0/16, o que confirma que o isolamento lógico está funcionando. Tomando como exemplo o protocolo EIGRP, a configuração dos roteadores CE não muda nada (eles sequer conhecem as VRFs), mas no PE é necessário usar o recurso address-family (AF) para especificar a VRF. O parâmetro "Autonomous-System" deve referenciar o AS do respectivo CE:

PE(config)# router eigrp 65001
PE(config-router)# address-family ipv4 vrf CINZA
PE(config-router)# autonomous-system 1
PE(config-router-af)# network 192.168.0.0
PE(config-router-af)# network 172.30.0.0
PE(config-router-af)# exit
PE(config-router)# address-family ipv4 vrf VERDE
PE(config-router-af)# autonomous-system 2
PE(config-router-af)# network 192.168.0.0
PE(config-router-af)# network 172.20.0.0
PE(config-router-af)# exit

CE1-CINZA(config)# router eigrp 1
CE1-CINZA(config-router)# network 192.168.0.0
CE1-CINZA(config-router)# exit

CE2-VERDE(config)# router eigrp 2
CE2-VERDE(config-router)# network 192.168.0.0
CE2-VERDE(config-router)# exit

Os roteadores CE1-CINZA e CE2-VERDE não precisam de nenhuma configuração adicional, já que eles não têm ciência da existência das VRFs lógicas em PE. No entanto, para o PE é necessário anexar o parâmetro "vrf NOME" nos principais comandos de manipualação e diagnóstico de rotas e hosts, a exemplo dos comandos "ip route" e "ping". As saídas abaixo trazem a alguns comandos básicos:

!--- Visualização da VRF CINZA
PE# show ip vrf CINZA
  Name                             Default RD          Interfaces
  CINZA                            1:1                 Lo1
                                                       Fa0/0
!--- Visualização da VRF VERDE
PE# show ip vrf VERDE
  Name                             Default RD          Interfaces
  VERDE                            2:2                 Lo2
                                                       Fa1/0
!--- Visualização da Tabela de Rotas da VRF CINZA
PE# show ip route vrf CINZA
Routing Table: CINZA
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C    172.30.0.0/16 is directly connected, Loopback1
     192.168.0.0/30 is subnetted, 1 subnets
C       192.168.0.0 is directly connected, FastEthernet0/0

!--- Visualização da Tabela de Rotas da VRF VERDE
PE# show ip route vrf VERDE
Routing Table: VERDE
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C    172.20.0.0/16 is directly connected, Loopback2
     192.168.0.0/30 is subnetted, 1 subnets
C       192.168.0.0 is directly connected, FastEthernet1/0

!--- Exemplo de Uso do Ping na VRF CINZA
PE# ping vrf CINZA 192.168.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

Caso o leitor tenha mais interesse no assunto e queira se aprofundar através de um exemplo realista da aplicação dessa tecnologia em provedores (oferta de VPN/MPLS), sugiro a leitura de outro artigo que escrevi há algum tempo intitulado "Configuração da Nuvem MPLS em Provedores".

Abraço.

Samuel.

quarta-feira, 1 de janeiro de 2014

Delegação de Prefixos IPv6 em Roteadores Cisco

Olá Pessoal.

Em outros artigos que escrevi aqui no blog, mostrei ao leitor como configurar o DHCPv6 nas modalidades stateless e stateful. O DHCPv6 ainda possui um novo recurso bastante útil para provedores (ISPs) denominado Delegação de Prefixos (Prefix Delegation), comumente referenciado como DHCPv6-PD.

A idéia básica por trás desse recurso é que o roteador PE (Provider Edge) de um ISP pode entregar uma rede /64 ou mesmo um bloco /56 (com 256 sub-redes /64) para o roteador CE (Customer Edge) de seus clientes. Na realidade é possível entregar qualquer bloco menor a partir de um prefixo principal porque o roteador "quebra" o prefixo principal. Nesse contexto cabe destacar as recomendações do NIC.br de que empresas recebam um prefixo /48 (65.536 sub-redes /64) e usuários residenciais um prefixo /56 (256 sub-redes /64). Para exemplificar o processo de configuração do DHCPv6-PD utilizaremos o cenário abaixo.


Observem que o ISP detém o bloco 2001:DB8:CAFE::/48 e será configurado com o DHCPv6-PD para gerar sub-prefixos /56 para seus clientes. A interface f0/0 do roteador CE (cliente do ISP) está conectada na interface f0/0 do roteador ISP-PE. Na sequência iremos configurar o roteador CE do cliente para receber o prefixo via DHCPv6 e, posteriormente, esse prefixo /56 será utilizado para gerar novos prefixos /64 nas interfaces f1/0 e f2/0 que estão diretamente conectadas nas sub-redes locais.

Então vamos às configurações necessárias para configurar o roteador ISP-PE:

01. ISP-PE(config)# ipv6 local pool CLIENTE 2001:db8:cafe::/48 56
02. ISP-PE(config)# ipv6 dhcp pool ISP
03. ISP-PE(config-dhcp)# prefix-delegation pool CLIENTE lifetime infinite infinite
04. ISP-PE(config-dhcp)# exit
05. ISP-PE(config)# int f0/0
06. ISP-PE(config-if)# ipv6 address 2001:db8:cafe::1/64
07. ISP-PE(config-if)# ipv6 dhcp server ISP
08. ISP-PE(config-if)# no shut
09. ISP-PE(config-if)# end
10. ISP-PE# show ipv6 local pool

Na primeira linha criamos um pool local (denominado CLIENTE) informando o bloco principal /48 do provedor que deverá ser "quebrado" em prefixos /56. Na segunda linha estamos configurando o serviço DHCP configurado para fazer a delegação de prefixos, seguindo a lógica do pool local criado anteriormente. Por fim, na sétima linha ativamos a interface f0/0 para prover o serviço DHCP.

A figura abaixo traz a saída do comando "show ipv6 local pool", onde o leitor pode observar que o prefixo 2001:DB8:CAFE::/48 está configurado para gerar até 256 sub-prefixos /56 e que, até esse momento, nenhum sub-prefixo está sendo utilizado pelo(s) cliente(s). 


Agora vamos às configurações do roteador CE do cliente:

01. CE(config)# int f0/0
02. CE(config-if)# ipv6 enable
03. CE(config-if)# ipv6 address autoconfig default
04. CE(config-if)# ipv6 dhcp client pd FROM-ISP
05. CE(config-if)# no shut
06. CE(config-if)# end
07. CE# show ipv6 dhcp interface

A figura abaixo traz a saída do comando "show ipv6 dhcp interface", onde o leitor pode observar os blocos ativos que o roteador CE está recebendo do seu ISP, sendo que, a partir dessa informação, é possível utilizar o prefixo /56 recebido para quebrá-lo em sub-prefixos /64 nas interfaces f1/0 e f2/0.


Pois bem, vamos às configurações finais no roteador CE do cliente:

08. CE(config)# int f1/0
09. CE(config-if)# ipv6 enable
10. CE(config-if)# ipv6 address FROM-ISP ::1:0:0:0:1/64
11. CE(config-if)# no shut
12. CE(config-if)# int f2/0
13. CE(config-if)# ipv6 enable
14. CE(config-if)# ipv6 address FROM-ISP ::2:0:0:0:1/64
15. CE(config-if)# no shut
16. CE(config-if)# end
17. CE# show ipv6 int brief

Observem nos destaques em amarelo (linhas 10 e 14) que, a partir do prefixo FROM-ISP (2001:DB8:CAFE:0::/56), estamos criando duas sub-redes /64 fazendo referência explícita ao quarto quarteto do endereço IPv6. É por isso que na configuração enxergamos 5 quartetos... A figura abaixo traz a saída do comando "show ipv6 int brief", onde o leitor pode observar os endereços configurados nas interfaces f1/0 e f2/0.


Por fim é interessante observar novamente o prefixo delegado no roteador ISP-PE, afinal agora um prefixo /56 (gerado a partir do original /48) já está em uso, restando 255. Também vale mencionar que o roteador ISP-PE automaticamente cria uma rota 2001:db8:cafe::/56 associada às as sub-redes do cliente, conforme ilustrado na figura abaixo:



Esse recurso de DHCPv6-PD é, de fato, MUITO útil para provedores.

Abraço.

Samuel.

sexta-feira, 6 de setembro de 2013

Palestras do Cisco Academy Day 2013

Olá Pessoal.

No dia 05/09 ocorreu o evento Academy Day 2013 organizado pela Cisco. O evento ocorreu simultaneamente em São Paulo e no Rio de Janeiro, sendo que as palestras realizadas no período noturno foram transmitidas online via Internet. Se você não pôde acompanhar as palestras por algum motivo, não há razão para ficar chateado! A gravação das palestras realizadas no evento já estão disponíveis e podem ser acompanhadas através do link logo abaixo da figura.


Vários dos participantes do evento (presencial e remoto) pediram pelos slides utilizados nas apresentações dos especialistas, por isso estou comparilhando abaixo os links para que vocês possam ter acesso aos materiais das apresentações.

- IPv6 na Internet e no Novo Currículo CCNA 5.0

- Tendências Tecnológicas em Redes das Operadoras de Telecomunicações

- Redes WiFi de Nova Geração

Abraço.

Samuel.

quarta-feira, 16 de janeiro de 2013

Configuração da Nuvem MPLS em Provedores

Olá Pessoal.

Esse post traz um assunto relevante no contexto atual das telecomunicações que é o MPLS. Atualmente a tecnologia MPLS (Multi-Protocol Label Switching) é comumente utilizada pelas operadoras de telecomunicações (ISP) como solução de conectividade de longa distância.

E antes de entrar na discussão técnica, uma primeira observação importante é que a configuração dessa tecnologia no ambiente corporativo (enterprise) é totalmente diferente da configuração na nuvem da operadora (ISP). 

Aliás, quem possui um link MPLS na empresa sabe bem que ela é transparente, já que você simplesmente recebe a conectividade da operadora e pronto - é como se houvesse um link privado entra as unidades remotamente conectadas... Bom, então se a coisa é simples assim qual seria a razão da "novela" que se faz acerca dessa tecnologia?

A simplicidade de uns é a complexidade de outros! Os roteadores instalados na empresa cliente normalmente sequer têm noção do que é MPLS e por isso toda a complexidade da infraestrutura está na nuvem da operadora.

Diferente de outras tecnologias de Camada 2 (HDLC, ATM e Frame-Relay) que eram tradicionalmente utilizadas na longa distância (e ainda são), o MPLS surgiu como uma tecnologia de Camada 2¹/² que traz uma abordagem de operação totalmente nova: o chamado roteamento baseado em rótulos.

Essa tecnologia não utiliza mais o cabeçalho do datagrama IP na decisão de roteamento, fazendo o reencapsulamento do datagrama com um novo cabeçalho de 4 bytes que possui um rótulo de 20 bits. Toda a decisão de encaminhamento dos pacotes é determinada com base nesse rótulo, o que agiliza o processo de roteamento e permite a implementação de técnicas de engenharia de tráfego, entre outras coisas mais.

O assunto é extenso e obviamente que o meu objetivo não é substituir um bom livro sobre o assunto - por isso serei o mais objetivo possível e o foco é que vocês consigam reproduzir um cenário prático de MPLS. Vamos trabalhar com o  cenário observado na figura abaixo. 



Antes de partir para a configuração, existem vários conceitos fundamentais que o leitor precisa ter em mente para entender o papel dos elementos envolvidos no cenário. Então que tal começar pelo começo? Parece razoável... ;-)

O Custormer Edge (CE) é o equipamento instalado nas unidades remotas da empresa que irão receber a solução de conectividade provida pela operadora. Outro elemento importante é o Provider Edge (PE) que se trata do roteador da operadora diretamente conectado a um (ou mais) roteador(es) do(s) cliente(s), ou seja, PEs são conectados a CEs. Por fim, o elemento P (Provider) são os demais roteadores distribuídos pela nuvem MPLS que representa a infraestrutura de rede da operadora.

Outro conceito fundamental é a tecnologia VRF (Virtual Routing and Forwarding) que traz consigo outros dois elementos igualmente importantes: o RD (Route Distinguisher) e o RT (Route Target). Através do VRF é possível criar múltiplas instâncias da tabela de roteamento, sendo que cada uma dessas tabelas virtuais é totalmente independente das demais. No contexto do MPLS é comum que cada cliente tenha sua própria VRF porque essa prática traz mais segurança e flexibilidade

Sem as VRFs individuais o tráfego entre as sub-redes de todos os clientes da operadora iriam compor uma única tabela de roteamento, o que seria péssimo do ponto de vista de segurança. Outro benefício comum é que se torna possível que os clientes utilizem endereços de redes iguais, já que as instâncias VRF são independentes. E é muito comum que as empresas utilizem endereços privados da RFC1918 (192.168 /16, 172.16 /12 e 10 /8).

No entanto, em algum momento é necessário que as rotas entre o roteador da empresa (CE) e o roteador da operadora (PE) sejam redistribuídas para um processo BGP no PE. Isso porque deve existir um pareamento iBGP entre um PE e outro PE remoto para viabilizar na prática a chamada VPN MPLS, um túnel abstrato que só existe nas bordas da rede MPLS, já que os roteadores P sequer conhecem as várias VPNs.

Eis que surge um problema: Fica claro que é possível ter endereços repetidos através das VRFs porque elas representam tabelas de roteamento distintas, mas como fica a redistribuição das rotas iguais para o processo BGP!!!??? Isso só é possível através da adição de um identificador nas rotas para torná-las únicas que é denominado RD (Route Distinguisher). Também existe o RT (Route Target), uma community BGP que indica o membro de uma VPN, permitindo que rotas sejam importadas e exportadas das VRFs no processo de redistribuição

Há alguns formatos para o RD/RT, sendo que sua forma mais comum consiste em:  
ASN de 16 Bits + Número de 32 Bits ; Ex.: 65000:100. 

No cenário apresentado nesse post teremos duas VRFs denominadas Cliente1 e Cliente2 que serão identificadas da seguinte forma:

- VRF Cliente 1, RD 65001:111, RT 65001:1
- VRF Cliente 2, RD 65002:222, RT 65002:2

Mesmo com "toda" essa carga teórica, acreditem que fui bastante sucinto e fiz o possível para "suavizar" essa postagem apresentando apenas os conceitos fundamentais. Como o processo de configuração consiste em várias linhas de comando, estarei dividindo o processo de configuração nas seguintes etapas: 

  1. Configuração Básica das Interfaces e Endereços IP
  2. Roteamento IGP (EIGRP) na Nuvem da Operadora (AS 200)
  3. Criação e Associação da VRF e Configuração do RD/RT
  4. Configuração do Roteamento EIGRP no PE e CE
  5. Configuração da Redistribuição de Rotas EIGRP e BGP
  6. Configuração do MP-BGP no(s) PE

As etapas 1 e 2 não dizem respeito à configuração do MPLS propriamente dito, no entanto são pré-requisitos para o cenário funcionar devidamente. Como os roteadores da empresa (CE) nao têm ciência do MPLS, eles possuem apenas configurações básicas.

1) Configuração Básica das Interfaces e Endereços IP

A única configuração que merece destaque nessa primeira etapa é que estamos habilitando o encapsulamento MPLS na interface que se conecta a outro roteador da nuvem da operadora. Reparem que as interfaces que se conectam aos roteadores CE não têm essa configuração, já que o tráfego até o PE é puramente IP.

PE1(config)# int lo 1
PE1(config-if)# ip address 1.1.1.1 255.255.255.255
PE1(config-if)# int f0/0
PE1(config-if)# ip address 172.16.5.2 255.255.255.252
PE1(config-if)# mpls ip
PE1(config-if)# int s1/0
PE1(config-if)# clock rate 64000
PE1(config-if)# ip address 172.16.1.1 255.255.255.252
PE1(config-if)# no shut
PE1(config-if)# int s2/0
PE1(config-if)# clock rate 64000
PE1(config-if)# ip address 172.16.2.1 255.255.255.252
PE1(config-if)# no shut

PE2(config)# int lo 1
PE2(config-if)# ip address 2.2.2.2 255.255.255.255
PE2(config-if)# int f0/0
PE2(config-if)# ip address 172.16.6.2 255.255.255.252
PE2(config-if)# mpls ip
PE2(config-if)# int s1/0
PE2(config-if)# clock rate 64000
PE2(config-if)# ip address 172.16.3.1 255.255.255.252
PE2(config-if)# no shut
PE2(config-if)# int s2/0
PE2(config-if)# clock rate 64000
PE2(config-if)# ip address 172.16.4.1 255.255.255.252
PE2(config-if)# no shut

P(config)# int lo 1
P(config-if)# ip address 3.3.3.3 255.255.255.255
P(config-if)# int f0/0
P(config-if)# ip address 172.16.5.1 255.255.255.252
P(config-if)# mpls ip
P(config-if)# int f1/0
P(config-if)# ip address 172.16.6.1 255.255.255.252
P(config-if)# mpls ip
P(config-if)# no shut

2) Roteamento IGP (EIGRP) na Nuvem da Operadora (AS 200)

Essa segunda etapa também é bem básica, consistindo apenas na configuração de um protocolo de roteamento IGP qualquer na nuvem da operadora. Não há nenhum destaque especial, então apenas trarei os comandos:

PE1(config)# router eigrp 200
PE1(config-router)# network 172.16.0.0
PE1(config-router)# network 1.1.1.1
PE1(config-router)# no auto-summary

PE2(config)# router eigrp 200
PE2(config-router)# network 172.16.0.0
PE2(config-router)# network 2.2.2.2  
PE2(config-router)# no auto-summry

P(config)# router eigrp 200
P(config-router)# network 172.16.0.0
P(config-router)# network 3.3.3.3 
P(config-router)# no auto-summary 

3) Criação e Associação da VRF e Configuração do RD/RT

A configuração abaixo é necessária apenas nos roteadores de borda (PE), já que os roteadores da empresa (CE) não têm ciência do MPLS. Reparem que em cada roteador de borda criamos duas VRFs e informamos os valores RD/RT previamente definidos. Por fim, associamos cada VRF com sua respectiva interface (cliente).

PE1(config)#ip vrf Cliente1
PE1(config-vrf)#rd 65001:111
PE1(config-vrf)#route-target both 65001:1
PE1(config-vrf)#exit
PE1(config)#ip vrf Cliente2
PE1(config-vrf)#rd 65002:222
PE1(config-vrf)#route-target both 65002:2
PE1(config-vrf)#exit
PE1(config)#int s2/0
PE1(config-if)#ip vrf forwarding Cliente1
% Interface Serial2/0 IP address 172.16.1.1 removed due to enabling VRF Cliente1
PE1(config-if)#ip address 172.16.1.1 255.255.255.252
PE1(config-if)#exit
PE1(config)#int s2/1
PE1(config-if)#ip vrf forwarding Cliente2
% Interface Serial2/1 IP address 172.16.2.1 removed due to enabling VRF Cliente2
PE1(config-if)#ip address 172.16.2.1 255.255.255.252
PE1(config-if)#exit


PE2(config)#ip vrf Cliente1
PE2(config-vrf)#rd 65001:111
PE2(config-vrf)#route-target both 65001:1
PE2(config-vrf)#exit
PE2(config)#ip vrf Cliente2
PE2(config-vrf)#rd 65002:222
PE2(config-vrf)#route-target both 65002:2
PE2(config-vrf)#exit
PE2(config)#int s2/0
PE2(config-if)#ip vrf forwarding Cliente1
% Interface Serial2/0 IP address 172.16.3.1 removed due to enabling VRF Cliente1
PE2(config-if)#ip address 172.16.3.1 255.255.255.252
PE2(config-if)#int s2/1
PE2(config-if)#ip vrf forwarding Cliente2
% Interface Serial2/1 IP address 172.16.4.1 removed due to enabling VRF Cliente2
PE2(config-if)#ip address 172.16.4.1 255.255.255.252
PE2(config-if)#exit



4) Configuração do Roteamento EIGRP no PE e CE

A próxima etapa consiste na configuração de um protocolo de roteamento entre a empresa para que o provedor possa conhecer as rotas anunciadas pela empresa. Esse processo de configuração é bem simples nos roteadores da empresa (CE), no entanto há alguns comandos adicionais nos roteadores do provedor (PE) que são necessários para associar as rotas de cada cliente com sua respectiva VRF anteriormente criada. 

Talvez a observação mais importante aqui é que o número de AS utilizado nos processos EIGRP do CE e PE não precisam ser iguais, uma vez que na configuração EIGRP do PE há uma sub-seção de configuração para cada VRF em que devemos informar o mesmo número utilizado no processo do roteador remoto (CE). Caso contrário, as rotas dos diversos clientes seriam todas compartilhadas na tabela de roteamento padrão, o que não é desejado...

CE1A(config)#router eigrp 65001
CE1A(config-router)#network 192.168.1.0
CE1A(config-router)#network 172.16.0.0
CE1A(config-router)#no auto-summary


CE2A(config)#router eigrp 65002
CE2A(config-router)#network 192.168.1.0
CE2A(config-router)#network 172.16.0.0
CE2A(config-router)#no auto-summary  


PE1(config)#router eigrp 1
PE1(config-router)#address-family ipv4 vrf Cliente1
PE1(config-router-af)#autonomous-system 65001
PE1(config-router-af)#network 172.16.0.0
PE1(config-router-af)#no auto-summary
PE1(config-router-af)#

PE1(config-router-af)#address-family ipv4 vrf Cliente2
PE1(config-router-af)#autonomous-system 65002
PE1(config-router-af)#network 172.16.0.0
PE1(config-router-af)#no auto-summary


***

CE1B(config)#router eigrp 65001
CE1B(config-router)#network 192.168.2.0
CE1B(config-router)#network 172.16.0.0
CE1B(config-router)#no auto-summary


CE2B(config)#router eigrp 65002
CE2B(config-router)#network 192.168.2.0
CE2B(config-router)#network 172.16.0.0
CE2B(config-router)#no auto-summary  


PE2(config)#router eigrp 1
PE2(config-router)#address-family ipv4 vrf Cliente1
PE2(config-router-af)#autonomous-system 65001
PE2(config-router-af)#network 172.16.0.0
PE2(config-router-af)#no auto-summary
PE2(config-router-af)#

PE2(config-router-af)#address-family ipv4 vrf Cliente2
PE2(config-router-af)#autonomous-system 65002
PE2(config-router-af)#network 172.16.0.0
PE2(config-router-af)#no auto-summary


(*) Obs.: No processo EIGRP dos roteadores PE que irão estabelecer vizinhança com os roteadores CE utilizamos o AS 1 para não misturar as rotas dos clientes com o processo EIGRP 200 que utilizamos nas primeiras etapas para trocar as rotas internas entre os roteadores da nuvem MPLS.  

5) Configuração da Redistribuição de Rotas EIGRP e BGP

Até agora os roteadores PE já aprenderam as rotas dos clientes diretamente conectados, no entanto não existe uma ligação entre as unidades remotas dos clientes porque o PE1 não está diretamente ligado ao PE2. Ou seja, PE1 conhece as rotas anunciadas por CE1A, mas não é capaz de receber as rotas de CE1B. 

Na próxima etapa a gente vai configurar um pareamento iBGP entre PE1 e PE2 para criar a abstração do túnel da VPN/MPLS. No entanto, antes temos que configurar a redistribuição mútua entre o EIGRP estabelecido com os roteadores CE e o BGP que estará em execução nos roteadores PE.

PE1(config)# router bgp 200
PE1(config-router)# address-family  ipv4 vrf Cliente1
PE1(config-router-af)# redistribute eigrp 65001
PE1(config-router-af)# exit
PE1(config-router)# address-family ipv4 vrf Cliente2
PE1(config-router-af)# redistribute eigrp 65002
PE1(config-router-af)# exit
PE1(config-router)# exit
PE1(config)# router eigrp 1
PE1(config-router)# address-family ipv4 vrf Cliente1
PE1(config-router-af)# redistribute bgp 200 metric 10000 1000 255 1 1500
PE1(config-router-af)# exit
PE1(config-router)# address-family ipv4 vrf Cliente2
PE1(config-router-af)# redistribute bgp 200 metric 10000 1000 255 1 1500


PE2(config)# router bgp 200
PE2(config-router)# address-family ipv4 vrf Cliente1
PE2(config-router-af)# redistribute eigrp 65001
PE2(config-router-af)# exit
PE2(config-router)# address-family ipv4 vrf Cliente2
PE2(config-router-af)# redistribute eigrp 65002
PE2(config-router-af)# exit
PE2(config-router)# exit
PE2(config)# router eigrp 1
PE2(config-router)# address-family ipv4 vrf Cliente1
PE2(config-router-af)# redistribute bgp 200 metric 10000 1000 255 1 1500
PE2(config-router-af)# exit
PE2(config-router)# address-family ipv4 vrf Cliente2
PE2(config-router-af)# redistribute bgp 200 metric 10000 1000 255 1 1500



6) Configuração do MP-BGP no(s) PE
   
O último passo consiste no estabelecimento do túnel virtual entre as unidades remotas da empresa para prover ao cliente a abstração de que existe uma conexão privada de longa distância (WAN) entre as unidades. Assim que essa configuração for feita, os roteadores CE1A e CE1B vão conhecer as rotas uns dos outros e a empresa terá conectividade remota!

PE1(config)#router bgp 200
PE1(config-router)#neighbor 2.2.2.2 remote-as 200
PE1(config-router)#neighbor 2.2.2.2 update-source lo1
PE1(config-router)#address-family vpnv4
PE1(config-router-af)#neighbor 2.2.2.2 activate
PE1(config-router-af)#neighbor 2.2.2.2 send-community


PE2(config)#router bgp 200
PE2(config-router)#neighbor 1.1.1.1 remote-as 200
PE2(config-router)#neighbor 1.1.1.1 update-source lo1
PE2(config-router)#address-family vpnv4
PE2(config-router-af)#neighbor 1.1.1.1 activate
PE2(config-router-af)#neighbor 1.1.1.1 send-community


Pronto! Depois de MUITAS linhas de comando já temos uma implementação básica de VPN/MPLS funcionando entre duas empresas clientes, cada uma com apenas duas unidades remotas. Ao visualizar a tabela de roteamento VRF Cliente1 no roteador PE1 é possível observar que a rota 192.168.2.0/24 da unidade remota foi aprendida via BGP.

PE1#show ip route vrf Cliente1

Routing Table: Cliente1
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/30 is subnetted, 2 subnets
C       172.16.1.0 is directly connected, Serial2/0
B       172.16.3.0 [200/0] via 2.2.2.2, 00:02:37
D    192.168.1.0/24 [90/2172416] via 172.16.1.2, 00:42:44, Serial2/0
B    192.168.2.0/24 [200/2172416] via 2.2.2.2, 00:02:37

Também vamos aproveitar que tivemos todo esse trabalho para observar a tabela BGP do PE1, já que assim fica evidente a importância do identificador RD.

PE1#show ip bgp vpnv4 all
BGP table version is 17, local router ID is 1.1.1.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: 65001:111 (default for vrf Cliente1)
*> 172.16.1.0/30    0.0.0.0                  0         32768 ?
*>i172.16.3.0/30    2.2.2.2                  0    100      0 ?
*> 192.168.1.0      172.16.1.2         2172416         32768 ?
*>i192.168.2.0      2.2.2.2            2172416    100      0 ?
Route Distinguisher: 65002:222 (default for vrf Cliente2)
*> 172.16.2.0/30    0.0.0.0                  0         32768 ?
*>i172.16.4.0/30    2.2.2.2                  0    100      0 ?
*> 192.168.1.0      172.16.2.2         2172416         32768 ?
*>i192.168.2.0      2.2.2.2            2172416    100      0 ?


Agora vamos observar a tabela de roteamento do roteador CE1A instalado na empresa. Observem que ele apenas conhece a rota remota como se as unidades estivessem diretamente conectadas entre si. Essa é a grande vantagem da implementação VPN do MPLS, afinal o cliente não enxerga a nuvem MPLS.

CE1A#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/30 is subnetted, 2 subnets
C       172.16.1.0 is directly connected, Serial2/0
D       172.16.3.0 [90/2681856] via 172.16.1.1, 00:08:33, Serial2/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
D    192.168.2.0/24 [90/2684416] via 172.16.1.1, 00:08:34, Serial2/0

 

Para finalizar esse post (que já está extenso demais), há vários comandos de exibição (show) que podemos utilizar para verificar o efeito de todas as configurações realizadas em cada uma das etapas.  Por isso deixo registrada uma relação de comandos de exibição caso o leitor queira reproduzir o cenário e sugiro uma observação detalhada das tabelas VRF e BGP.

PE1# show ip route
PE1# show ip route vrf Cliente1
PE1# show ip route vrf Cliente2
PE1# show ip bgp 
PE1# show ip bgp summary
PE1# show ip bgp vpnv4 all  
PE1# show ip eigrp vrf Cliente1 neighbors
PE1# show ip eigrp vrf Cliente2 neighbors
PE1# show ip eigrp vrf Cliente1 topology
PE1# show ip eigrp vrf Cliente2 topology   

Abraço.

Samuel.