Imagine um cenário em que uma empresa receba o tráfego de internet em um único router. Passado algum tempo a empresa precisa criar um novo circuito no mesmo router para outra filial usando um túnel GRE.
Devido a requisitos de negócio, o tráfego de internet precisa ser separado do tráfego corporativo no mesmo router. Para tal, é proposto implementar VRF-Lite no router, segmentando as tabelas de routing. Porém, isto causaria um novo problema! A interface WAN estaria em uma tabela de roteamento diferente a do túnel.
Para garantir a segmentação do tráfego entre internet e o corporativo, a solução a aplicar denomina-se Front-Door VRF (FVRF).
Esta tecnologia é bastante simples de entender, desde que já conheças os fundamentos de VRF e Túneis GRE.
Para exemplo usarei a topologia abaixo:
Iremos implementar FVRF no R4 e garantir que estabeleça um túnel GRE com o R2. A configuração dos routers entres (provedores) não será tida em conta pois servirá somente como underlay.
Vejamos a configuração do R2:
!
interface Ethernet0/0
ip address 192.168.2.2 255.255.255.0
interface Ethernet0/1
ip address 10.102.0.2 255.255.255.0
ip ospf 1 area 1
router bgp 65102
bgp log-neighbor-changes
network 192.168.2.0
neighbor 192.168.2.25 remote-as 64512
interface Tunnel24
ip address 192.168.24.2 255.255.255.0
ip ospf network broadcast
ip ospf 1 area 1
tunnel source 192.168.2.2
tunnel destination 192.168.4.4
Basicamente do lado do R2, temos uma sessão BGP com o router PE25 para propagação da rede 192.168.2.0/24. Na interface E0/1 e na interface tunnel24, está habilitada OSPF para ser anunciada pelo túnel ao R4. Nada de mais até aqui.
Agora vejamos a configuração do R4
ip vrf WAN
rd 65105:65105
!
!
interface Ethernet0/0
ip vrf forwarding WAN
ip address 192.168.4.4 255.255.255.0
!
interface Tunnel24
ip address 192.168.24.4 255.255.255.0
ip ospf network broadcast
ip ospf 1 area 1
tunnel source 192.168.4.4
tunnel destination 192.168.2.2
tunnel vrf WAN
router bgp 65105
!
address-family ipv4 vrf WAN
network 192.168.4.0
neighbor 192.168.4.23 remote-as 64512
neighbor 192.168.4.23 activate
exit-address-family
!
interface Ethernet0/1
ip address 10.105.0.4 255.255.255.0
ip ospf 1 area 1
O requisito de segmentar o tráfego entre as redes precisa ser garantido do lado do R4, para tal foi criada uma vrf WAN e associada a interface que liga ao provedor. Tal como no R2, temos a interface E0/1 e o túnel GRE habilitados com o protocolo OSPF. Adicionalmente existe o parâmetro tunnel vrf WAN indicando que a interface deve ser a vrf WAN para chegar ao IP de destino do túnel.
R4#sh int tun24
Tunnel24 is up, line protocol is up
Hardware is Tunnel
Internet address is 192.168.24.4/24
MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel linestate evaluation up
Tunnel source 192.168.4.4, destination 192.168.2.2
Tunnel protocol/transport GRE/IP
Validando a adjacência OSPF entre R4 e R2:
R4#show ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
192.168.255.2 1 FULL/DR 00:00:35 192.168.24.2 Tunnel24
Consultando a tabela de routing de R4:
Gateway of last resort is 10.105.0.5 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O 10.102.0.0/24 [110/1010] via 192.168.24.2, 00:33:54, Tunnel24
Testando ping a partir da interface lan do R4
R4#ping 10.102.0.2 source 10.105.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.102.0.2, timeout is 2 seconds:
Packet sent with a source address of 10.105.0.4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms