Introdução ao Roteamento
Quando você acessa um site, seu computador precisa enviar pacotes de dados até o servidor que hospeda esse site. Só que esse servidor pode estar em outro estado, país ou até continente. Então, o computador precisa descobrir como fazer esses dados "viajarem" pela rede até chegar lá. É aqui que entra o roteamento. O roteamento é o processo de seleção de um caminho que os pacotes devem seguir até o destino.
Quando o destino está na mesma subrede, ou seja, quando o dispositivo de origem e o de destino compartilham o mesmo domínio de broadcast, como em uma rede doméstica ou dentro de uma LAN corporativa, a máquina de origem executa uma rotina de roteamento local, consultando sua tabela de rotas para decidir como alcançar o destino. Nesse caso, ele encontra uma rota diretamente conectada (ou link-local), o que indica que o pacote pode ser entregue diretamente ao destino, sem passar por um gateway.
Existem situações em que a máquina de origem tem na tabela de roteamento, rotas específicas para outras subredes, que não são locais, mas que não precisam passar pelo gateway padrão, elas passam por outro próximo salto (next hop) previamente definido. Esse tipo de configuração pode ocorrer por diversos motivos, por política de rede, por otimização de tráfego, por roteamento estático configurado manualmente ou por DHCP com opções avançadas.
Nesse cenário, o processo funciona de forma direta. Primeiro, o computador verifica se o IP de destino está na mesma subrede. Ele faz isso comparando seu próprio endereço IP com o do destino, usando a máscara de sub-rede. Se estiver na mesma rede, ele sabe que pode enviar os dados diretamente.
Mas antes de enviar o pacote IP, ele precisa do endereço físico (MAC) do destinatário, já que a comunicação real que ocorre na camada de enlace (camada 2), é feita pelo endereços MAC. Para descobrir o MAC, ele usa o protocolo ARP (Address Resolution Protocol) se o endereço IP for versão 4, caso seja IPv6 é utilizado o Neighbor Discovery Protocol (NDP). O ARP envia uma mensagem de broadcast (para IPv4) ou multicast (para IPv6) como se estivesse fazendo a pergunta: "Quem tem o IP X? Me diga seu MAC." O dispositivo dono daquele IP responde com seu endereço MAC. A partir daí, o computador pode montar uma unidade de camada 2, que encapsula o pacote IP, e enviá-lo diretamente para o destino (quem realiza a entrega do pacote nesse caso é o switch).
Agora, quando o destino não está na mesma subrede, ou seja, quando o IP de destino não pertence ao mesmo domínio de broadcast que o do remetente, o computador não pode enviar o pacote diretamente ao destino final. Ele precisa da ajuda de um roteador para alcançar redes diferentes, e é aí que entra o processo de roteamento.
Primeiro, o computador detecta que o IP de destino não pertence à sua subrede. Ele compara seu próprio IP com o do destino usando sua máscara de sub-rede. Quando a comparação mostra que estão em redes diferentes, o computador sabe que precisa encaminhar esse pacote para o seu gateway padrão, que é justamente o endereço IP do roteador configurado na máquina.
Embora o pacote IP tenha como destino final o IP remoto (fora da subrede), a unidade de camada 2 precisa ser entregue ao roteador primeiro. Para isso, o computador precisa do endereço MAC do roteador. Então, ele faz um ARP (caso ainda não conheça o MAC do gateway), ao obter o MAC, ele monta a unidade de camada 2.
O pacote IP é encapsulado em uma estrutura de camada 2 apropriada ao meio físico, por exemplo, uma unidade de camada 2 (no caso de redes Ethernet), e essa estrutura é endereçada ao MAC do roteador (para links Ethernet, mas em links ponto-a-ponto (PPP, HDLC, MPLS) não existe MAC). Ela é então enviada pela rede local até o roteador. Quando o roteador recebe essa unidade de enlace, ele a desencapsula, extrai o pacote IP e analisa o endereço IP de destino. Com base nisso, consulta sua tabela de roteamento para decidir qual será o próximo salto. Essa decisão pode resultar no envio direto ao destino (caso ele esteja em uma rede diretamente conectada) ou no encaminhamento para outro roteador mais próximo do destino. A escolha do caminho é feita com base em protocolos de roteamento como OSPF, BGP ou RIP, dependendo da topologia e política da rede.
Os roteadores trabalham na camada 3 do modelo OSI, que é a camada de rede, ou seja, o foco é sempre o pacote IP. Acontece que quando um Roteador vai repassar o pacote IP para outro roteador, ele precisa de um meio físico para transmitir o pacote ao próximo salto, e esse meio exige que o pacote IP seja encapsulado novamente em uma estrutura da camada 2, como uma unidade de camada 2 se o meio físico for uma interface Ethernet.
Esse processo se repete em cada roteador ao longo do caminho, o roteador recebe a estrutura de camada 2 (como um quadro Ethernet), desencapsula essa estrutura e mantém o pacote IP. Em seguida, ele consulta sua tabela de roteamento, decide o próximo salto e reencapsula o pacote IP em uma nova estrutura de enlace, apropriada ao meio físico da interface de saída, por exemplo, uma nova unidade de camada 2 se a interface for Ethernet. Nesse reencapsulamento, os endereços de camada 2 (como os MACs) são sempre atualizados, o MAC de origem será o da interface do roteador, e o MAC de destino será o do próximo salto (próximo roteador ou host final).
Esse procedimento se repete até que o pacote IP chegue ao roteador final, que está diretamente conectado à rede de destino. Esse roteador, então, encapsula o pacote IP em uma última estrutura de camada 2, agora endereçada diretamente ao dispositivo de destino, e realiza a entrega final.
Loop de Roteamento
Em redes com múltiplos roteadores e caminhos possíveis, especialmente em situações de falha ou má configuração, pode ocorrer o chamado loop de roteamento, um cenário em que um pacote IP fica circulando de forma contínua entre roteadores, sem nunca alcançar o destino. Isso pode acontecer, por exemplo, quando uma sequência cíclica de decisões equivocadas de encaminhamento em que cada roteador acredita que outro é o melhor caminho para o destino. Os Loops também podem surgir temporariamente durante a convergência de protocolos dinâmicos ou de forma permanente se regras como split-horizon/poison reverse forem ignoradas.
Para evitar que pacotes fiquem presos nesse ciclo indefinidamente, os protocolos IP implementam um mecanismo de controle de vida útil chamado TTL (Time To Live) no IPv4 e Hop Limit no IPv6. Esse campo faz parte do cabeçalho do pacote IP e define o número máximo de saltos (hops) que o pacote pode realizar entre roteadores.
Cada vez que um pacote IP passa por um roteador, o valor do campo TTL ou Hop Limit é reduzido em 1. Quando esse valor chega a zero, o roteador descarta antes de consultar a tabela de rotas.
Roteamento entre VLAN
Quando implementamos VLANs em uma rede, estamos criando domínios de broadcast na camada 2, geralmente associados a sub-redes IP distintas. Isso permite segmentar logicamente os dispositivos, como em uma rede onde RH está na VLAN 10, ADM na VLAN 20 e TI na VLAN 30. Mesmo com todos conectados fisicamente ao mesmo switch, cada VLAN opera como se fosse uma rede separada.
Ao separar dispositivos em VLANs diferentes, a comunicação direta entre eles deixa de existir na camada 2, porque o switch só encaminha quadros para portas em que o VLAN ID esteja habilitado, untagged em portas de acesso, ou tag permitido em portas trunk. Importante lembrar que, quadros sem tag recebidos em uma porta trunk são atribuídos à VLAN nativa antes do encaminhamento. Por padrão, essa é a VLAN 1, mas pode ser alterada conforme a política da rede.
Quando um host envia um quadro Ethernet, ele é encaminhado apenas às portas da mesma VLAN, com base no endereço MAC de destino. Se o destino estiver em outra VLAN, o tráfego precisa passar por um dispositivo de camada 3, que realize o roteamento entre VLANs. Esse roteamento pode ser feito de duas maneiras principais:
SVI (Switch Virtual Interface)
Uma interface lógica em um switch de camada 3, com um IP configurado para cada VLAN.Router-on-a-Stick
Uso de subinterfaces 802.1Q em um roteador, cada uma associada a uma VLAN e configurada com um IP correspondente.
Em ambos os casos, cada host configura como gateway o IP da sua respectiva SVI ou subinterface. Ao tentar se comunicar com outro IP fora de sua sub-rede, o host realiza uma requisição ARP (ou NDP, no caso de IPv6) para descobrir o endereço MAC do gateway, e envia o quadro Ethernet com esse MAC de destino, ou seja, o MAC da SVI ou subinterface, não o do host final.
O roteador recebe esse quadro, desencapsula o pacote IP, toma uma decisão de roteamento e reencapsula o pacote em um novo quadro de camada 2 adequado ao meio (Ethernet, 802.11, etc.). Em ambientes com enlaces sem endereçamento MAC, como links PPP ou HDLC, o roteador envia diretamente o pacote IP pelo enlace, sem necessidade de encapsulamento com MACs.
Vale destacar que VRF-Lite não é um método de inter-VLAN, mas sim uma técnica de virtualização de tabelas de roteamento, usada para manter isolamento entre domínios de roteamento. Dentro de cada VRF, o roteamento entre VLANs ainda ocorre via SVI ou subinterfaces, a VRF apenas define contextos lógicos separados para esse tráfego.
Por padrão, o roteamento entre VLANs é permitido assim que SVIs ou subinterfaces estão ativas e em redes diferentes (alguns switches exigem ativar IP routing globalmente, um exemplo seriam usando o comando ip routing em IOS). Se não houver controle adicional, dispositivos de diferentes VLANs poderão se comunicar livremente, o que pode não ser desejável.
Por isso, é comum aplicar ACLs (Access Control Lists) nos próprios SVIs ou interfaces físicas, restringindo o tráfego permitido entre VLANs com base em critérios como IP de origem, destino ou porta de aplicação. Em cenários mais avançados, firewalls internos também podem assumir essa função.
IP em VLAN
Nos switches, especialmente nos de camada 3, criamos interfaces chamadas SVIs (Switch Virtual Interfaces). Uma SVI é uma interface lógica associada a uma VLAN específica, e nela configuramos o endereço IP que servirá como gateway para os hosts daquela VLAN.
Por exemplo:
interface vlan 30
ip address 172.16.32.1 255.255.255.0
Esse IP será o gateway padrão para os dispositivos da VLAN 30. Quando um host dessa VLAN tenta se comunicar com um IP fora de sua sub-rede, ele envia o pacote para esse gateway, e o switch L3 realiza o roteamento entre VLANs com base nesse endereço.
Em switches de camada 2 (L2), também é possível configurar um IP associado a uma VLAN, mas esse IP não é usado para roteamento. Ele serve apenas para gerenciamento do próprio switch, acesso via SSH, Telnet, SNMP, etc.
Roteamento com portas roteadas (routed ports)
Em alguns cenários, como o representado na imagem abaixo, um switch de camada 3 ou até mesmo um roteador não precisa configurar IP em SVI, pois usa IP diretamente nas portas físicas configuradas como routed ports.
Neste exemplo, os dispositivos distribution1 e distribution2 estão conectados diretamente aos switches de acesso e utilizam interfaces físicas com IP atribuído diretamente, sem VLANs internas. Em switches L3 baseados em Cisco IOS (como Catalyst ou IOSv-L3) isso é feito com o comando abaixo:
interface Ethernet0/1
no switchport
ip address 172.16.32.1 255.255.255.0
Esse comando transforma a interface em uma porta roteada (routed port), que opera exclusivamente na camada 3. Essas portas não participam de protocolos de switching, como STP, CDP ou VTP, e não mantêm tabela de endereços MAC. Como essas portas não participam do STP, é fundamental ativar BPDU Guard nas interfaces do switch de acesso ou aplicar spanning-tree portfast para evitar loops e atrasos na convergência.
O BPDU Guard é um mecanismo de proteção contra loops na camada 2 das redes Ethernet. Ele é usado em portas que não devem receber BPDUs (Bridge Protocol Data Units), como portas configuradas como acesso (access ports) conectadas diretamente a hosts, impressoras, ou qualquer outro dispositivo final.
As BPDUs são mensagens trocadas entre switches para formar e manter a topologia da árvore de expansão (Spanning Tree Protocol). Elas permitem que os switches detectem loops e desativem portas para evitar que os quadros fiquem circulando indefinidamente na rede.
O problema é que se uma porta de acesso (que deveria estar conectada apenas a um host final) começa a receber BPDUs, isso pode indicar que um switch foi conectado indevidamente nessa porta, e isso pode causar instabilidade ou até permitir ataques à topologia da rede, como bridge spoofing.
O BPDU Guard protege contra isso, desativando imediatamente a interface ao detectar qualquer BPDU nela. Quando ativado, o BPDU Guard vai fazer:
- Desliga a interface (coloca em estado err-disable) se um BPDU for recebido.
- Bloqueia temporariamente a porta até que um administrador intervenha (ou configure errdisable recovery).
- Funciona melhor em conjunto com o
spanning-tree portfast, que acelera a ativação da porta em redes seguras.
interface FastEthernet0/1
switchport mode access
spanning-tree portfast
spanning-tree bpduguard enable
Essa combinação diz ao switch: "essa porta conecta a um host, ative rapidamente, e se aparecer alguma mensagem de STP aqui, desligue a porta na hora".
Em algumas plataformas específicas, como simuladores IOSv-L3 ou roteadores da série ASR-1000 (onde as interfaces já são L3 por padrão), o modo switchport não está disponível, qualquer tentativa de aplicar comandos de VLAN resultará em erro.
Se for necessário criar VLANs nesses contextos, o método varia conforme o equipamento:
Em roteadores (L3 puro): utiliza-se subinterfaces 802.1Q com encapsulamento por VLAN:
interface GigabitEthernet0/0.10
encapsulation dot1Q 10
ip address 192.168.10.1 255.255.255.0Em switches L3: o padrão é configurar SVIs (Switch Virtual Interfaces) para cada VLAN e usar trunks nas conexões com os switches de acesso.
Em switches L3 como IOSv-L3 ou Catalyst, é obrigatório habilitar o roteamento IP com o comando global:
ip routing
Sem esse comando, o equipamento cria SVIs com IP, mas não realiza roteamento entre VLANs. Cada routed port consome uma porta física e uma entrada na TCAM (memória de encaminhamento), por isso, é importante planejar a capacidade física e lógica do switch. Em redes com muitas VLANs, o uso de trunks com SVIs costuma ser mais escalável.
Bloquear a comunicação entre VLANs
Em muitos casos, você não quer que todas as VLANs possam se comunicar livremente. Por exemplo, usuários da rede de visitantes não devem acessar servidores internos da rede corporativa. Se o roteamento entre VLANs estiver habilitado, você precisa implementar mecanismos de controle para restringir essa comunicação.
Você pode fazer isso de duas formas, veja abaixo:
ACLs (Access Control Lists)
As ACLs são a forma mais comum e eficiente para bloquear ou permitir tráfego entre VLANs. Você aplica a ACL nas interfaces VLAN (SVIs) ou nas interfaces físicas, controlando exatamente quem pode acessar o quê.
Exemplo de ACL aplicada à SVI da VLAN 10, bloqueando acesso à VLAN 20:
ip access-list extended BLOQUEIO-ADM
deny ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255
permit ip any any
interface vlan 10
ip access-group BLOQUEIO-ADM in
VACLs e PVLANs
Além das ACLs, é possível bloquear a comunicação entre VLANs usando VACLs (VLAN Access Control Lists) ou PVLANs (Private VLANs), cada uma com aplicações específicas.
As VACLs, ou VLAN Access Maps, são aplicadas dentro da própria VLAN para filtrar o tráfego que circula nela. Diferente das ACLs tradicionais, que atuam nas SVIs ou interfaces físicas, as VACLs operam no plano de comutação, ou seja, são eficazes mesmo quando o tráfego permanece dentro da mesma VLAN e não precisa ser roteado. Isso as torna úteis quando há necessidade de inspecionar ou bloquear tráfego entre hosts de uma mesma VLAN ou entre VLANs com trunk em Layer 2.
Por exemplo, uma configuração de VACL no IOS Cisco poderia ser:
ip access-list extended FILTRO-VLAN
permit ip host 192.168.10.10 any
deny ip any any
vlan access-map BLOQUEIO 10
match ip address FILTRO-VLAN
action forward
vlan access-map BLOQUEIO 20
action drop
vlan filter BLOQUEIO vlan-list 10
Já as Private VLANs (PVLANs) são uma técnica de segmentação dentro de uma única VLAN. Elas são muito usadas em ambientes onde os dispositivos compartilham a mesma VLAN por exigência da aplicação (como hospedagem em datacenters), mas não podem se comunicar entre si. Usando PVLANs, é possível configurar portas como "isolated" (não se comunicam nem entre si), "community" (comunicam-se apenas com portas do mesmo grupo), e "promiscuous" (têm acesso a todas).
Portanto, enquanto as ACLs são mais flexíveis e diretas para controle entre VLANs roteadas, as VACLs e PVLANs são alternativas valiosas para cenários específicos. VACLs são preferidas quando o tráfego está em Layer 2 e você precisa bloquear dentro da própria VLAN. As PVLANs são úteis em ambientes de segurança onde múltiplos clientes compartilham a infraestrutura, mas não podem se ver na rede.
Habilite o modo de VLAN privada no switch:
# Cria a vlan dentro do switch:
vlan 100
private-vlan primary # vlan primária.
private-vlan association 101 102 # associa as vlans 101 e 102 dentro da vlan 100.
# Cria a vlan dentro do switch:
vlan 101
private-vlan isolated # hosts isolados entre si.
# Cria a vlan dentro do switch:
vlan 102
private-vlan community # hosts com comunicação mútua.
A VLAN primária numa Private VLAN (PVLAN) não é usada diretamente pelos hosts, porque ela funciona como um "guarda-chuva lógico" que organiza as VLANs secundárias. Em uma PVLAN, o switch não permite que você configure diretamente um host para usar a VLAN primária sozinha. Em vez disso, os hosts são sempre associados a uma VLAN secundária, que pode ser do tipo isolated ou community.
Para os hosts poderia fazer assim:
interface ethernet0/0
switchport mode private-vlan host
switchport private-vlan host-association 100 101
no shutdown
interface ethernet0/1
switchport mode private-vlan host
switchport private-vlan host-association 100 101
no shutdown
Os hosts em uma Private VLAN (PVLAN) pode se comunicar com o gateway e acessar a internet, desde que exista uma porta configurada como promiscuous ligada ao gateway, e isso esteja corretamente mapeado à VLAN primária e às VLANs secundárias.
Firewalls
Se a política de segurança for mais complexa ou envolver inspeção de pacotes, autenticação, NAT, etc., é possível usar um firewall entre as VLANs, mas isso normalmente é feito em redes maiores ou ambientes críticos. Em redes corporativas padrão, ACLs em switches L3 resolvem bem o problema.