Resumo

  • A etiqueta de rota externa do OSPF registrava se sua estrutura era automática, se a informação de caminho era completa e se o comprimento pertencia às classes zero, um ou maior que um.
  • Uma etiqueta manual era LocalInfo opaco; uma automática também não carregava o AS_PATH completo. O processo de geração determinava o que os mesmos bits podiam significar.
  • Caminhos truncados ou preservados em um registro BGP separado não podiam ser reexportados a partir do resumo OSPF.

A tradução cabia; a história, não

Na borda de um sistema autônomo, BGP e OSPF descreviam alcançabilidade com modelos diferentes. BGP carregava história interdomínio; OSPF calculava rotas internas. Um ASBR podia importar uma rota para OSPF, e outro ASBR podia mais tarde tentar anunciá-la novamente em BGP.

RFC 1403 colocou uma pequena declaração de proveniência nessa travessia. Entre os 32 bits do external-route tag, havia um bit Automatic, um de Completeness, dois de PathLength, doze de uso arbitrário e dezesseis para um número de AS.

PathLength era uma classe, não uma cópia do caminho. A etiqueta dizia algo sobre a condição da evidência; não preservava uma sequência arbitrária de ASes.

Quando Automatic era zero, os outros 31 bits tinham interpretação local. Esse modo manual continuava sendo o padrão por compatibilidade, e o RFC proibia inferir características da rota a partir dele. Só a geração automática ativava a gramática compartilhada de completude e comprimento.

Automatic tampouco era autenticação. O documento não discutia segurança. O bit informava como ler o campo, não se o equipamento ou sua entrada mereciam confiança.

Uma ausência podia ser definitiva ou provisória

Para caminhos locais ou com um vizinho, a classificação e o número de AS ainda permitiam uma reconstrução limitada, sujeita às políticas explícitas. Caminhos maiores excediam a capacidade do tag.

Se o caminho já chegasse truncado, a etiqueta podia marcar “incompleto e longo”, mas não recuperar a sequência. Outro roteador de borda jamais deveria reexportar essa rota para BGP.

Se o caminho completo continuasse disponível, OSPF carregaria apenas a projeção de alcançabilidade. O registro íntegro deveria circular em BGP entre os ASBRs do mesmo AS. O roteador que pretendesse anunciar externamente precisava esperar essa atualização.

RFC 1403 chamou o segundo caso de “out of band”. Não era um canal paralelo de dados, mas outro protocolo de roteamento guardando a evidência que não cabia no resumo. No primeiro caso, a história havia sido perdida; no segundo, tinha outra custódia. Em nenhum deles o tag ganhava poder para inventá-la.

Presença não era autorização

O padrão para exportar OSPF em BGP era nenhum. Rotas externas exigiam configuração explícita. A importação BGP em OSPF também precisava ser selecionada, e uma default route não podia surgir sem decisão administrativa.

Aprender uma rota, projetá-la no IGP e anunciá-la para peers eram eventos diferentes. Uma entrada na tabela OSPF não provava nem a permanência da proveniência BGP nem a autorização para publicação.

O tratamento de métricas reconhecia a mesma fronteira. OSPF cost e o INTER-AS METRIC do BGP-3 tinham tamanhos e funções diferentes. RFC 1403 deixava o atributo BGP opcional ausente por padrão. Converter o número não importava automaticamente seu significado.

A correlação entre BGP Identifier e OSPF router ID ajudava a encontrar a prova inteira. Quando vários ASBRs importavam o mesmo destino, o anunciante precisava saber qual saída sua rota OSPF realmente usava e associá-la ao caminho BGP correspondente.

RFC 1745 atualizou o desenho para BGP-4, IDRP, prefixos variáveis, path sets, MULTI_EXIT_DISC e LOCAL_PREF. Saídas de custo igual podiam exigir a união de caminhos em um conjunto. A regra de perda permaneceu: caminho truncado nunca seria reexportado; caminho completo maior que o tag precisava chegar por BGP/IDRP antes do anúncio.

Até a relação entre OSPF Forwarding Address e BGP NEXT_HOP mostrava apenas a construção do próximo salto. Não provava forwarding observado, resposta remota ou resultado da aplicação.

RFC 1403 e RFC 1745 hoje são Historic e não oferecem análise de segurança. Eles não descrevem a operação atual. Seu princípio histórico é mais preciso: uma marca de incompletude só tem valor quando retira as decisões que dependem do detalhe ausente.

Fontes

Essas fontes sustentam status documental, semântica dos campos e requisitos especificados, não adoção atual, autenticidade, forwarding bem-sucedido ou resultado do usuário.