Resumo
- A RFC 6860 permite que o OSPF mantenha a relação topológica usada pelo SPF e, ao mesmo tempo, deixe de anunciar o prefixo numerado de uma rede somente de trânsito como destino instalável na RIB e na FIB.
- “Oculto” tem alcance estreito: OSPFv2 pode continuar expondo endereços nas LSAs, um receptor legado pode instalar uma rota
/32, e gestão, Forwarding Address ou enlace virtual podem depender do endereço removido.
O enlace não deve desaparecer junto
Uma contagem menor de rotas não basta para aprovar a mudança. O mesmo número pode cair porque a prefix suppression funcionou ou porque uma adjacência falhou. A verificação correta procura duas coisas diferentes: continuidade do grafo e ausência deliberada da alcançabilidade do prefixo.
Em um enlace ponto a ponto numerado no OSPFv2, a Router-LSA normalmente traz uma descrição Type 1 do roteador vizinho e uma descrição Type 3 da rede stub. A primeira vira uma aresta para o SPF. A segunda gera a rota para a sub-rede. A RFC 6860 omite o Type 3 e conserva o Type 1.
O roteador continua sabendo como chegar a destinos depois do vizinho, sem ensinar a todos que a sub-rede da interface é um destino. Isso não desliga a porta, não apaga o endereço e não aumenta a métrica para drenar tráfego. A mudança limita a projeção do endereço para as tabelas remotas.
O DR ainda precisa contar quem está ligado
Em rede broadcast, o Designated Router origina uma Network-LSA com a lista de roteadores conectados. Remover a LSA inteira destruiria a informação topológica que deve sobreviver.
Por isso, a RFC 6860 preserva a LSA e usa 255.255.255.255 como máscara especial. Um receptor atualizado processa normalmente a topologia, mas não instala a rota da rede. O mesmo vale para NBMA operado segundo o modelo broadcast.
A compatibilidade produz uma diferença importante. Um software antigo pode interpretar a máscara como /32 e instalar uma rota host para o endereço de interface do DR. O receptor atualizado não instala nada. A norma trata uma única rota host como exposição menor que a sub-rede inteira, mas não esconde que as RIBs ficam diferentes.
Assim, uma captura da LSDB não encerra a prova. O relatório precisa identificar cada receptor, sua versão e a rota resultante. Igualdade de estado de enlace não implica igualdade de estado de roteamento.
No OSPFv3, endereço e topologia já são camadas distintas
As Router-LSAs e Network-LSAs principais do OSPFv3 descrevem topologia sem carregar endereços de rede. Link-LSAs associam endereços ao enlace em escopo local; Intra-Area-Prefix-LSAs associam prefixos a roteadores ou redes.
A supressão conserva as LSAs topológicas e omite o prefixo de trânsito na formação das Intra-Area-Prefix-LSAs pertinentes. O suporte a famílias de endereços da RFC 5838 reaproveita essa organização em cada instância.
Isso torna a fronteira mais limpa, não invisível. Link-LSAs, Router IDs, configuração e telemetria continuam disponíveis. Um endereço pode permanecer atribuído e se tornar inalcançável no domínio. A afirmação auditável é específica: aquele receptor não instalou aquele prefixo a partir daquela instância OSPF.
Conhecer o endereço não cria uma rota
A motivação de segurança é reduzir as redes do núcleo que um remetente remoto consegue alcançar. Mesmo que o endereço seja conhecido, a ausência de informação de encaminhamento impede que os roteadores o tratem como destino OSPF comum.
Isso não é criptografia, autenticação nem controle de acesso. No OSPFv2, o endereço de interface pode aparecer como Link Data; o endereço do DR pode permanecer no Link State ID. O equipamento diretamente conectado tem rota local. Estática, outro protocolo, túnel ou rede de gestão podem criar caminho alternativo.
Logo, “oculto” exige referência: oculto de qual RIB, em qual roteador, instante e instância? A FIB foi verificada? Havia outra fonte de rota? O teste de pacote partiu do ponto cujo risco se pretendia reduzir?
O benefício de convergência tem o mesmo limite. Menos prefixos pode significar menos trabalho, mas só uma medição antes e depois prova ganho na topologia concreta.
O endereço talvez tivesse outro emprego
Endereços de trânsito frequentemente são usados por ping, traceroute, gestão direta, correlação de alarmes e automação. O serviço fim a fim pode sobreviver enquanto a capacidade de diagnosticar o enlace piora.
Uma Forwarding Address não nula em AS-external-LSA ou NSSA-LSA depende de uma rota correspondente. O endereço de uma interface suprimida não pode continuar nessa função; a consequência pode ser um caminho menos direto para rotas externas.
Uma extremidade de enlace virtual OSPF também precisa ser alcançável por um caminho intra-área. O endereço suprimido não pode servir de extremidade. Preservar a aresta do grafo não preserva uma função que exige alcançabilidade do endereço.
Sessões interdomínio, ACLs, coletores, scripts e rotas de emergência entram no inventário. “Somente de trânsito” é uma conclusão operacional revisável, não um atributo automático da interface.
Um recibo para continuidade, outro para supressão
As documentações atuais de FRRouting e Cisco registram controles de prefix suppression. Isso comprova capacidade em famílias nomeadas, não aplicação correta em produção.
O recibo de continuidade inclui adjacência, Type 1 ou equivalente topológico, resultado SPF e canários de pacote. O recibo de supressão inclui a omissão do Type 3 ou associação de prefixo, a máscara especial quando aplicável, a ausência da rota nas RIBs/FIBs atualizadas e qualquer /32 legado aceito no plano.
Versão, escopo, exceções, caminho alternativo de gestão, Forwarding Address, enlace virtual, responsável e condição de rollback unem os dois recibos. Sem essa junção, uma redução de contagem pode mascarar perda de controle.
O lugar delimitado de Álvaro Retana
Yi Yang, Álvaro Retana e Abhay Roy assinam a RFC 6860, publicada em 2013. O texto reconhece ainda um grupo maior de inventores e revisores. O perfil IETF de Retana registra uma carreira ampla, mas não lhe atribui propriedade sobre OSPF, código de fornecedor ou redes de terceiros.
A coautoria documentada sustenta uma conclusão mais precisa: Retana participou de uma norma coletiva que recusou transformar topologia e alcançabilidade de endereço em um único estado. A especificação fornece semântica mínima; a implementação oferece capacidade; o operador decide o escopo; o código em execução produz a prova.
O registro final separa cinco frases: o enlace existe; OSPF o usa; a interface tem endereço; os receptores não instalam o prefixo; as funções necessárias continuam. A RFC 6860 permite respostas diferentes. A disciplina está em não comprimi-las novamente em um selo genérico de “oculto”.
Fontes
- https://www.rfc-editor.org/rfc/rfc6860.html
- https://www.rfc-editor.org/rfc/rfc2328.html
- https://www.rfc-editor.org/rfc/rfc5340.html
- https://www.rfc-editor.org/rfc/rfc5838.html
- https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/15-e/iro-15-e-book/iro-ex-lsa.html
- https://www.cisco.com/c/en/us/td/docs/routers/ios-xe/ip-routing/b-ip-routing/m_iro-pref-supp-v3.html
- https://docs.frrouting.org/en/latest/ospfd.html
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
