Roteamento entre VRFs com MP-BGP

A utilização de VRFs (Virtual Routing and Forwarding) em Roteadores permite a criação de tabelas de roteamento 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.

A configuração de VRFs é bem simples e há um artigo aqui do blog que pode ser consultado  aqui .

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

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(config-vrf)#rd ?
  ASN:nn or IP-address:nn  VPN Route Distinguisher
! Configurando a VRF para os clientes A B e C 
ip vrf Cliente_A
 rd 65000:1
!
ip vrf Cliente_B
 rd 65000:2
!
ip vrf Cliente_C
 rd 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
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 vrf Cliente_A
 rd 65000:1
 route-target export 65000:1
 route-target import 65000:1
 route-target import 65000:2
!
ip vrf Cliente_B
 rd 65000:2
 route-target export 65000:2
 route-target import 65000:2
 route-target import 65000:1
!
ip vrf Cliente_C
 rd 65000:3
 route-target export 65000:3
 route-target import 65000:3
!

Segue 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 vrf forwarding Cliente_A
 ip address 1.1.1.1 255.255.255.0
!
interface Loopback2
 ip vrf forwarding Cliente_B
 ip address 2.2.2.2 255.255.255.0
!
interface Loopback3
 ip vrf forwarding Cliente_C
 ip address 3.3.3.3 255.255.255.0
!
router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 no auto-summary
 !
 address-family ipv4 vrf Cliente_A
 redistribute connected
 no synchronization
 exit-address-family
 !
 address-family ipv4 vrf Cliente_B
 redistribute connected
 no synchronization
 exit-address-family
 !
 address-family ipv4 vrf Cliente_C
 redistribute connected
 no synchronization
 exit-address-family
!

Segue abaixo os outputs das rotas aprendidas para o roteamento entre VRFs e o teste de ICMP

R1#show ip route vrf Cliente_A
Gateway of last resort is not set
     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, Loopback1
     2.0.0.0/24 is subnetted, 1 subnets
B       2.2.2.0 is directly connected, 00:08:22, Loopback2
R1#ping vrf Cliente_A 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

Para dúvidas ou sugestões deixe um comentário.

Leave a Reply

Your email address will not be published. Required fields are marked *