A utilização de VRFs (Virtual Routing and Forwarding) em Roteadores permite a criação de tabelas de roteamentos virtuais que trabalham de forma independente da tabela de roteamento “normal”, protegendo os processos de roteamento de cada cliente de forma individual.
Empresas que prestam serviços de gerenciamento de rede ou monitoração, empresas que vendem serviços em Data Center e provedores de serviço utilizam largamente VRFs, otimizando assim a administração e o retorno financeiro no total do custo de um projeto.
Já o Roteamento entre VRFs ocorre quando há a necessidade de comunicarmos diferentes tabelas de roteamento que estão segregadas por VRF, para compartilharem alguns ou todos os prefixos. Há diversas formas de configurarmos o roteamento entre VRFs, como por exemplo com a utilização de um cabo virado para o próprio roteador com as portas em diferente VRFs [apontando assim uma rota para nexthop da proxima VRF; ou com algum IGP] e também com a utilização de um outro roteador, etc; nesse post explicaremos o roteamento interVRF com o processo MPBGP que é a maneira mais escalável… preparados? Então vamos lá…
Habilitando o import e export das VRFs
Ao configurarmos o processo de roteamento entre VRFs em um mesmo roteador , dois valores de extrema importancia devem ser configurados na VRF: o RD (route distinguisher) e o RT (route target)
RD – Route Distinguisher
Como explicado anteriormente, as VRFs permitem a reutilização de endereços IP em diferentes tabelas de roteamento. Por exemplo, suponha que você tenha que conectar a três diferentes clientes , os quais estão usando 192.168.1.0/24 em sua rede local. Podemos designar a cada cliente a sua própria VRF de modo que as redes sobrepostas são mantidas isoladas em suas VRFs .
O RD funciona mantendo o controle de quais rotas 192.168.1.0/24 pertencem a cada cliente como um diferenciador de rota (RD) para cada VRF. O route distinguisher é um número único adiciondo para cada rota dentro de uma VRF para identificá-lo como pertencente a essa VRF ou cliente particular. O valor do RD é carregado juntamente com uma rota através do processo MP- BGP quando o roteador troca rotas VPN com outros Roteadores PE.
O valor RD é de 64 bits e é sugerido a configuração do valor do RD como ASN::nn ou endereçoIP:nn. Mas apesar das sugestões, o valor é apenas representativo.
[R1-vpn-instance-Cliente_A]route-distinguisher ? STRING ASN:nn or IP_address:nn VPN Route Distinguisher ! ! Configurando a VRF para os clientes A B e C ip vpn-instance Cliente_A route-distinguisher 65000:1 ! ip vpn-instance Cliente_B route-distinguisher 65000:2 ! ip vpn-instance Cliente_C route-distinguisher 65000:3
Quando rotas VPN são anunciados entre os roteadores PE via MP-BGP, o RD é incluído como parte da rota, juntamente com o prefixo IP. Por exemplo, uma via para 192.0.2.0/24 na VRF Cliente_B é anunciado como 65000:2:192.0.1.0 / 24.
RT – Route-Target ou VPN-target
Considerando que o valor do RD é utilizado para manter a exclusividade entre rotas idênticas em diferentes VRFs, o RT (route target)é utilizado para compartilhar rotas entre eles. Podemos aplicar o RT para uma VRF com o objetivo de controlar a importação e exportação de rotas entre ela e outras VRFs.
O route target assume a forma de uma comunidade BGP estendida com uma estrutura semelhante à de um RD (que é, provavelmente, porque os dois são tão facilmente confundidos).
Segue abaixo um exemplo de configuração, onde o Cliente_A fará o roteamento entre VRFs com o Cliente_B, já o Cliente_C continuará com a sua VRF isolada dos outros clientes.
!
!
ip vpn-instance Cliente_A
route-distinguisher 65000:1
vpn-target 65000:1 export-extcommunity
vpn-target 65000:1 import-extcommunity
vpn-target 65000:2 import-extcommunity
!
ip vpn-instance Cliente_B
route-distinguisher 65000:2
vpn-target 65000:2 export-extcommunity
vpn-target 65000:2 import-extcommunity
vpn-target 65000:1 import-extcommunity
!
ip vpn-instance Cliente_C
route-distinguisher 65000:3
vpn-target 65000:3 export-extcommunity
vpn-target 65000:3 import-extcommunity
!
egue abaixo a configuração das interfaces de cada VRF , e o processo MP-BGP responsável por funcionar o import/export de prefixos das VRFs.
! ! interface Loopback0 ip address 192.168.1.1 255.255.255.0 ! interface Loopback1 ip binding vpn-instance Cliente_A ip address 1.1.1.1 255.255.255.0 ! interface Loopback2 ip binding vpn-instance Cliente_B ip address 2.2.2.2 255.255.255.0 ! interface Loopback3 ip binding vpn-instance Cliente_C ip address 3.3.3.3 255.255.255.0 ! # bgp 6500 undo synchronization # ipv4-family vpn-instance Cliente_A import-route direct # ipv4-family vpn-instance Cliente_B import-route direct # ipv4-family vpn-instance Cliente_C import-route direct # !
Segue abaixo os outputs das rotas aprendidas para o roteamento entre VRFs(vpn-instances) e o teste de ICMP
[R1]display ip routing-table vpn-instance Cliente_A
Routing Tables: Cliente_A
Destinations : 4 Routes : 4
Destination/Mask Proto Pre Cost NextHop Interface
1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
2.2.2.2/32 BGP 130 0 127.0.0.1 InLoop0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
[R1]ping -vpn-instance Cliente_A 2.2.2.2
PING 2.2.2.2: 56 data bytes, press CTRL_C to break
Reply from 2.2.2.2: bytes=56 Sequence=1 ttl=255 time=4 ms
Reply from 2.2.2.2: bytes=56 Sequence=2 ttl=255 time=10 ms
Reply from 2.2.2.2: bytes=56 Sequence=3 ttl=255 time=10 ms
Reply from 2.2.2.2: bytes=56 Sequence=4 ttl=255 time=5 ms
Reply from 2.2.2.2: bytes=56 Sequence=5 ttl=255 time=4 ms
--- 2.2.2.2 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 4/5/10 ms
Para dúvidas em sugestões deixe um comentário.
COMUTADORES 