Resumo

  • O RFC 3069 permitiu que VLANs de clientes separadas compartilhassem uma sub-rede IPv4 e um gateway sem fundir seus domínios de broadcast de camada 2.
  • Como um host no mesmo prefixo tenta ARP primeiro, um roteador no super-VLAN precisa mediar a comunicação. A máscara não prova adjacência nem autorização.

Menos endereços, mais mediação

A conta de endereços era convincente. No exemplo do RFC, três clientes previam dezesseis hosts cada. Sub-redes separadas consumiriam 28 endereços ao somar rede, broadcast direcionado e gateway, além do arredondamento para blocos de potência de dois. O arranjo do RFC 3069 usava dezenove: os três sub-VLANs de clientes compartilhavam 1.1.1.0/24 e o gateway 1.1.1.1, mas mantinham intervalos de hosts sem sobreposição. Um endereço ocioso podia ser realocado sem renumerar o cliente.

Essa economia não tornava os clientes vizinhos na camada 2. Cada sub-VLAN continuava em seu próprio domínio de broadcast. Ainda assim, todos os hosts usavam o comprimento do prefixo do super-VLAN. A lógica IP comum considerava qualquer endereço em 1.1.1.0/24 local e tentava ARP, em vez de enviar o pacote ao gateway padrão. ARP resolve o endereço de camada de enlace na rede local; não une domínios de broadcast isolados.

O roteador do super-VLAN fornecia a mediação que faltava. O RFC 3069 diz que ele pode executar uma função semelhante a Proxy ARP: responder à consulta por um endereço localizado em outro sub-VLAN, receber o quadro e encaminhar o pacote. Para o host, o destino parecia um vizinho. No sistema de encaminhamento, o roteador estava no meio. O prefixo descrevia uma relação de endereçamento, não um fato físico ou de camada 2.

Por trás da simplicidade há estado operacional. O roteador precisa saber a qual sub-VLAN cada endereço pertence, decidir se o solicitante pode usar o endereço de origem informado, responder ARP de forma coerente e encaminhar pelo caminho previsto. Máscara plausível ou resposta ARP bem-sucedida não provam que a associação endereço-VLAN esteja atualizada ou autorizada. O RFC recomenda intervalos de endereço persistentes: descartar pacotes IP ou ARP que entrem por um sub-VLAN com origem não alocada a ele e, opcionalmente, registrar o evento. A eficácia depende dos dados locais de alocação e associação.

Alguns comportamentos usuais de uma sub-rede deixam de caber em um único domínio de broadcast. O RFC 3069 não oferece broadcast direcionado, pois o endereço de todos os bits iguais a um não pode representar simultaneamente vários domínios de camada 2 isolados. Multicast também requer tratamento próprio; um roteador multicast talvez precise de estado semelhante a rotas de host para que as verificações RPF funcionem entre domínios separados. Mais tarde, o RFC 4562 descreveu como a separação por VLAN de cada cliente complica a replicação multicast e torna o teto de 4096 VLANs uma restrição operacional em redes de acesso banda larga.

A economia de endereços não eliminou custos; transferiu-os para o estado do roteador e a operação da rede.

O limite das evidências importa. O RFC 3069 é Informational, não um Internet Standard, e omite detalhes de implementação de propósito. O documento relata que a Extreme Networks tinha uma implementação funcional em serviço em data centers de provedores havia mais de um ano; é um relato dos autores, não uma pesquisa independente de adoção. Sobre outros fornecedores, fala apenas em rumores. Não apresenta medições amplas de interoperabilidade, taxa de falhas ou resultados para clientes.

Leia o pacote, não apenas a máscara

Quando um fluxo no mesmo prefixo falha, a máscara é apenas uma pista. É preciso examinar a solicitação e a resposta ARP no sub-VLAN de entrada, o endereço de origem, a alocação endereço-VLAN no roteador, a decisão de proxy/ARP e o resultado do encaminhamento. Para multicast, importam também o estado RPF e as rotas específicas do emissor. Esses registros mostram o que o roteador fez em um ponto de observação; não provam automaticamente o sucesso da aplicação nem o isolamento de todos os caminhos de acesso.

Fontes