Skip to main content


Introdução a VRF​

O Virtual Routing and Forwarding - VRF, é uma forma de criar vários roteadores virtuais dentro de um mesmo equipamento físico. Em um roteador comum, existe apenas uma tabela de roteamento e todas as interfaces compartilham essa mesma visão da rede. Quando se usa VRF, cada instância tem a sua própria tabela de rotas, suas próprias interfaces e o seu próprio espaço de encaminhamento.


Isso significa que é possível isolar completamente o tráfego de uma rede em relação a outra, mesmo que passem pelo mesmo hardware.


Quando uma interface é atribuída a uma VRF, todos os pacotes que entram por ela são analisados e roteados apenas de acordo com as rotas daquela VRF específica, sem qualquer influência das rotas existentes em outras instâncias. Cada VRF enxerga apenas o que está configurado para ela, e não tem conhecimento da existência das demais. Isso garante isolamento e segurança, evitando que um cliente, rede ou serviço interfira no tráfego de outro.


Essa tecnologia é muito usada por provedores de internet para atender vários clientes diferentes no mesmo backbone, sem que seja necessário dedicar um roteador físico para cada um. Também é bastante comum em redes corporativas, onde setores como produção, testes e visitantes precisam compartilhar a mesma infraestrutura, mas de forma completamente isolada. Em cenários mais avançados, o VRF é peça-chave em soluções como MPLS VPN, definidas por padrões como o RFC 4364, onde cada cliente tem a sua "VPN" com roteamento independente.


Uma boa forma de imaginar o VRF é pensar em um prédio. Sem VRF, todas as pessoas moram no mesmo andar e compartilham os mesmos corredores. Com VRF, esse prédio passa a ter andares independentes, com portas e corredores separados. Cada andar tem a sua própria lista de moradores e ninguém consegue atravessar de um para o outro sem que exista um caminho autorizado e configurado. No roteador, esses "andares" são as tabelas de roteamento separadas, e as "portas" são as interfaces associadas a cada VRF.


Para deixar ainda mais simples de entender. O VRF se assemelha a VLAN, porém, VLAN ocorre em L2 (Ethernet). Já o VRF ocorre em L3 (roteamento/IP). VLAN só separa o domínio de broadcast, mas, se o mesmo roteador enxergar as duas VLANs, ele ainda vai ver todas as rotas juntas, a menos que você use VRF para separar.


Num roteador, você poderia usar ACL para filtrar quem fala com quem. Com VRF, você nem precisa criar ACL para isolar. A ACL é mais "manual" e não escala tão bem quando você tem dezenas de redes. Além disso, VRF deixa a configuração mais organizada, porque cada tabela de rotas é independente.



VRF na prática​

Imagine que você trabalha para um provedor que precisa entregar internet para duas empresas diferentes, a Empresa Alpha e a Empresa Beta, usando o mesmo roteador no seu datacenter. Essas duas empresas exigem que o tráfego seja completamente isolado, mas você quer evitar comprar dois roteadores físicos só para isso. É aí que o VRF entra como solução perfeita.


No seu roteador, você cria duas instâncias de VRF, uma chamada ALPHA e outra chamada BETA. Para cada uma, você configura uma tabela de roteamento própria e associa as interfaces correspondentes. No caso da Alpha, a interface GigabitEthernet0/0 será ligada diretamente à rede dessa empresa, e para a Beta será a interface GigabitEthernet0/1.


No Cisco, a configuração ficaria mais ou menos assim:

! Criando VRFs
ip vrf ALPHA
 rd 100:1
 route-target export 100:1
 route-target import 100:1

ip vrf BETA
 rd 100:2
 route-target export 100:2
 route-target import 100:2

! Associando interfaces
interface GigabitEthernet0/0
 ip vrf forwarding ALPHA
 ip address 10.10.10.1 255.255.255.0

interface GigabitEthernet0/1
 ip vrf forwarding BETA
 ip address 192.168.20.1 255.255.255.0

Depois disso, a Empresa Alpha só consegue se comunicar com os endereços e rotas configurados na VRF ALPHA, e a Beta só vê a tabela da BETA. É como se, internamente, o roteador tivesse se transformado em dois roteadores distintos, cada um com a sua rede particular.



VRF no Linux​

No Linux, o conceito de VRF existe há alguns anos no kernel e é implementado através do módulo vrf junto com o iproute2. Ele funciona criando dispositivos virtuais que atuam como "pontos de montagem" para tabelas de roteamento específicas. A lógica é exatamente a mesma dos roteadores Cisco ou Juniper, cada VRF terá sua própria tabela de rotas e só vai encaminhar pacotes de interfaces associadas a ela.


Vamos imaginar um laboratório parecido com o cenário que usei antes, com duas empresas chamadas Alpha e Beta, cada uma com sua rede separada. No seu servidor Linux, você tem duas interfaces físicas: eth1 conectada à Alpha e eth2 conectada à Beta.


O passo a passo seria assim:

# Carregar o módulo VRF no kernel:
sudo modprobe vrf

Crie as tabelas de roteamento no arquivo /etc/iproute2/rt_tables:

cat << EOF > /etc/iproute2/rt_tables
10 VRF_ALPHA
20 VRF_BETA
EOF

Crie as interfaces VRF e associar cada uma a uma tabela:

sudo ip link add vrf-alpha type vrf table 10
sudo ip link add vrf-beta type vrf table 20

Suba as interfaces VRF:

sudo ip link set vrf-alpha up
sudo ip link set vrf-beta up

Associar as interfaces físicas a cada VRF:

sudo ip link set dev eth1 master vrf-alpha
sudo ip link set dev eth2 master vrf-beta

Configure os endereços IP dentro de cada VRF:

sudo ip addr add 10.10.10.1/24 dev eth1
sudo ip addr add 192.168.20.1/24 dev eth2

Adicionar rotas específicas para cada VRF:

sudo ip route add 10.10.20.0/24 via 10.10.10.254 table 10
sudo ip route add 192.168.30.0/24 via 192.168.20.254 table 20

Verificando as tabelas:

sudo ip route show table 10
sudo ip route show table 20

Agora, o tráfego da interface eth1 (Alpha) só vai seguir pelas rotas da tabela VRF_ALPHA e o da eth2 (Beta) só pelas rotas da VRF_BETA. Mesmo que as redes usem endereços iguais, como 192.168.0.0/24, elas não vão conflitar porque estão isoladas em VRFs diferentes.


O bom disso é que funciona tanto para roteamento IPv4 quanto IPv6, e você pode até criar VRFs para separar tráfego de gerenciamento (por exemplo, SSH e SNMP numa VRF isolada) do tráfego de produção.


Linux faz o papel de VRF por padrão

No Linux, por padrão, se você simplesmente configurar duas interfaces com redes diferentes, o kernel não vai "misturar" pacotes entre elas sem que o roteamento permita, ou seja, o forward de pacotes entre interfaces (ou redes) não acontece, a menos que a gente permita isso, então parece que VRF não teria muito a acrescentar. Mas o ganho real do VRF aparece em cenários onde existe roteamento ativo ou várias tabelas de rotas precisam coexistir.


Quando você ativa o roteamento (ip_forward = 1) para transformar o Linux em roteador, todas as rotas ficam na mesma tabela principal (main). Isso significa que, se você tiver várias redes usando endereços iguais ou quiser isolar o tráfego de clientes, precisa usar truques de iptables, ip rules ou políticas de roteamento para separar tudo.


Com VRF, cada "grupo" de interfaces e rotas fica em sua própria tabela, sem precisar de firewall complicado. O kernel sabe exatamente qual tabela usar baseado na interface de entrada. Por exemplo:

  • Sem VRF: você precisa criar regras de marcação (ip rule) para separar tráfego de Alpha e Beta.
  • Com VRF: só de associar a interface eth1 ao vrf-alpha e a eth2 ao vrf-beta, o isolamento já está garantido.


VRF no Linux com Netplan​

No Linux com Netplan dá para criar VRFs usando a chave vrfs: no YAML de configuração. Isso é bem útil se você quer que as VRFs sejam persistentes após reboot, sem precisar rodar todos aqueles comandos ip link e ip route manualmente.


Você pode criar um arquivo dentro de /etc/netplan/, dando a ele um nome no formato xx-nome.yaml, onde xx é um número que define a ordem de aplicação da configuração. Por exemplo: 10-vrf.yaml.

network:
  version: 2
  ethernets:
    eth1:
      addresses:
        - 10.10.10.1/24
      vrf: vrf-alpha

    eth2:
      addresses:
        - 192.168.20.1/24
      vrf: vrf-beta

  vrfs:
    vrf-alpha:
      table: 10
    vrf-beta:
      table: 20

A seção vrfs: cria as VRFs e associa cada uma a uma tabela de roteamento. Nas interfaces (eth1, eth2), usamos vrf: <nome> para dizer que aquela interface pertence a determinada VRF.


Cada VRF vai ter a sua tabela separada (table: 10 e table: 20). Ao aplicar essa configuração (sudo netplan apply), o Netplan cria automaticamente as interfaces VRF (vrf-alpha, vrf-beta) e associa as físicas a elas.


Verificando depois de aplicar:

ip link show type vrf
# Deve listar vrf-alpha e vrf-beta

ip route show table 10
# Mostra a tabela de rotas da VRF Alpha

ip route show table 20
# Mostra a tabela de rotas da VRF Beta


Te convencendo a usar VRF​

Em um servidor Linux configurado apenas como host, com duas interfaces ligadas a redes diferentes e o encaminhamento de pacotes (ip_forward) desativado, a adoção de VRF pode parecer um exagero, o mesmo vale para um Roteador (com ressalvas).


Nessas condições, cada interface atua de forma independente e não há risco de tráfego cruzado entre elas. No entanto, quando o Linux assume funções mais complexas (como roteador, firewall, servidor de VPN (VPNs de operadora, não servidores VPN normais) ou concentrador de redes) a VRF deixa de ser um detalhe opcional e passa a ser uma ferramenta estratégica.


O benefício mais evidente aparece em casos de sobreposição de endereços IP. Imagine dois clientes conectados ao mesmo equipamento, ambos usando internamente o bloco 192.168.0.0/24. Sem VRF, as rotas dessas redes iriam para a mesma tabela principal, gerando conflitos imediatos. A solução tradicional seria criar regras de roteamento baseadas em marcação de pacotes, algo trabalhoso e difícil de manter. Com VRF, o isolamento é natural, cada cliente fica em sua própria instância, com uma tabela de rotas exclusiva, permitindo que endereços idênticos coexistam sem impacto um sobre o outro.


Outro uso extremamente prático é a separação entre tráfego de produção e gerenciamento. Em ambientes corporativos e de provedores, é comum manter uma rede dedicada apenas para administração, onde circulam acessos SSH, SNMP e logs. Quando essa rede de gerenciamento está isolada em uma VRF própria, mesmo que a rede de produção seja comprometida, o acesso administrativo continua protegido, pois está em um domínio de roteamento completamente separado.


No Linux, essa abordagem pode ser implementada da mesma forma que em roteadores de alto nível, garantindo que a gestão continue segura e independente. Em ambos os casos, a VRF oferece um isolamento de camadas superiores que simplifica a configuração, organiza o roteamento e reduz a dependência de regras complexas de firewall ou políticas de roteamento. Ela resolve problemas que, sem essa funcionalidade, exigiriam soluções manuais, mais frágeis e difíceis de manter.



Sobreposição de endereços IP​

A sobreposição de endereços IP é um problema recorrente em ambientes onde múltiplos clientes ou redes independentes se conectam ao mesmo equipamento. Ela ocorre quando dois ou mais domínios de rede utilizam a mesma faixa de endereçamento, como, por exemplo, 192.168.0.0/24. Esse cenário é extremamente comum em redes corporativas e domésticas, pois endereços privados definidos pelas RFCs 1918 (IPv4) e 4193 (IPv6) são reutilizados livremente.


O problema surge quando essas redes precisam ser roteadas através de um mesmo dispositivo. No Linux, sem VRF, todas as rotas são armazenadas na tabela principal (main). Se duas redes com endereços idênticos forem anunciadas, apenas a primeira rota válida permanecerá ativa, a outra será ignorada ou substituída. Isso impossibilita que o equipamento encaminhe pacotes corretamente para ambas, pois não existe, em uma única tabela, um critério para distinguir qual destino usar.


Tradicionalmente, essa limitação poderia ser contornada com o uso de políticas de roteamento avançadas (Policy Based Routing - PBR). Nesse método, regras adicionais são criadas no ip rule para definir qual gateway ou interface usar com base em parâmetros como endereço de origem ou marcação de pacotes feita no firewall (iptables ou nftables). Embora funcione, essa solução é trabalhosa, difícil de manter e propensa a erros, especialmente em ambientes com muitos clientes ou mudanças frequentes.


O VRF resolve essa questão de forma muito mais elegante. Ao criar instâncias de roteamento independentes, é possível associar cada interface física ou lógica a uma VRF específica, cada uma com a sua própria tabela de rotas. Assim, redes sobrepostas coexistem sem conflito, pois o encaminhamento é decidido dentro do contexto daquela VRF. Um pacote que entra pela interface associada à vrf-cliente1 jamais será roteado usando a tabela de vrf-cliente2, mesmo que os dois usem exatamente a mesma faixa de IP.


Em um cenário prático, imagine um servidor Linux atuando como concentrador de VPN (VPNs de operadora, não servidores VPN normais) para dois clientes, ambos utilizando a rede interna 192.168.0.0/24. Com VRF, cada túnel é atribuído a uma instância separada, e cada VRF mantém sua própria rota para 192.168.0.0/24, sem que uma interfira na outra. Isso simplifica a configuração, elimina a necessidade de regras adicionais de PBR e garante isolamento lógico, preservando a estabilidade e previsibilidade do roteamento.


Sobre Separação de tráfego de produção e gerenciamento

O ideal seria usar duas interfaces, uma para tráfego e outra para gerenciamento. Mas se você tem apenas uma interface física, ainda dá para separar produção e gerenciamento com VRF usando interfaces lógicas:

  • Subinterfaces VLAN (eth0.10, eth0.20)
  • Interfaces virtuais (dummy, macvlan, veth)
  • Ou até mesmo IPs secundários (embora o mais organizado seja via VLAN).

O que o VRF precisa é de interfaces diferentes para associar a cada tabela de roteamento, não necessariamente físicas. Com VLANs, por exemplo, você poderia ter:

  • eth0.10 → VRF_PRODUCAO
  • eth0.20 → VRF_MGMT

Isso é bem comum em datacenters: um único link físico carrega várias VLANs (trunk), e o roteador ou servidor separa as redes em VRFs diferentes para manter o isolamento L3.