Resumo

  • O BGP-LS deriva objetos de nó, enlace e prefixo de informações IGP/TE, aplica política e divulga uma visão física, abstrata ou mista; ele não replica o LSDB nem preserva os números de sequência de LSA/LSP.
  • Sessão estabelecida e produtores redundantes não provam atualidade. Toda decisão deve manter ligados a origem, o Instance-ID, os withdrawals, os atributos, a regra de merge do consumidor e o resultado real no FIB e nos pacotes.

Os painéis não mostravam falha de protocolo. As sessões estavam estabelecidas, os objetos continuavam chegando e o controlador aceitava o grafo. A discrepância só apareceu quando os pacotes alcançaram o ponto onde o enlace já não existia.

A reconstrução encontrou dois feeds coerentes isoladamente. Um produtor ainda via A–B; o outro ainda via B–A. Depois de uma partição, nenhum deles possuía a história completa do withdrawal. O consumidor interpretou as duas metades como duplicatas complementares e produziu uma afirmação mais forte que qualquer fonte: o enlace está inteiro.

A RFC 9552 descreve esse risco ao tratar de produtores redundantes e nós de origem inalcançáveis. Publicada em dezembro de 2023, ela substitui integralmente a RFC 7752 e incorpora as atualizações da RFC 9029. Sua fronteira operacional é clara: BGP-LS transporta uma representação governada; não autentica a verdade física.

O produto da derivação não é o banco de origem

Um produtor normalmente lê o LSDB de OSPF ou IS-IS e o TED, deriva NLRI de Node, Link e Prefix e coloca propriedades no BGP-LS Attribute. Um objeto pode combinar dados vindos de várias LSA ou LSP. Os números de sequência da origem não acompanham a nova representação.

Parte do material pode ter envelhecido, sido purgada, considerada malformada ou ignorada segundo o protocolo fonte. Nem todo campo deve ser exportado. Além disso, a política decide conteúdo e, em certos casos, o momento da divulgação.

Essa seleção não é necessariamente perda. A RFC 9552 permite representar topologia física, uma abstração com nós agregados e caminhos virtuais, ou uma combinação. Um consumidor ALTO pode receber um mapa deliberadamente mais grosso que um PCE. Divergir do inventário não basta para declarar erro.

O teste correto compara a visão com um contrato: domínios, objetos, atributos, grau de abstração, meta de atualização, limite de frescor, classificação e finalidade. Sem esse contexto, uma abstração aprovada, uma perda de transporte e um dado vencido parecem o mesmo null.

Cada papel presta uma conta diferente

A norma separa Producer, Propagator e Consumer. O Producer origina informação Link-State em BGP, em geral a partir de um IGP, mas também pode usar fontes Direct ou Static. O Propagator processa UPDATE, executa o BGP Decision Process e anuncia o resultado selecionado. O Consumer é a aplicação que usa a visão e pode não ser um speaker BGP.

Uma plataforma pode acumular papéis; o registro não pode. Deve ser possível apontar quem derivou o objeto, qual política o autorizou, qual cópia BGP foi selecionada, qual vizinho a recebeu, como o consumidor resolveu duplicatas e qual decisão foi tomada.

A interface do speaker para o Consumer deve ser unidirecional. O consumidor não pode usá-la para injetar informação de volta à originação BGP-LS. Ler a topologia e escrever na rede são poderes distintos. Uma solicitação southbound precisa de outra identidade, outra autorização e outro log.

Por isso a seta “IGP → BGP-LS → controlador” é enganosa. Há decisões independentes de aceitação na fonte, derivação, exportação, seleção BGP, merge, cálculo, aprovação, programação e verificação.

Instance-ID delimita o universo observado

Informação não VPN usa AFI 16388 / SAFI 71; a VPN usa SAFI 72. A RFC 4760 fornece a capacidade multiprotocolo e MP_REACH/MP_UNREACH. A capacidade confirma o canal, não a exatidão de um enlace.

Protocol-ID distingue IS-IS L1/L2, OSPFv2, OSPFv3, Direct e Static. O BGP-LS Instance-ID de oito octetos separa instâncias IGP. Produtores do mesmo domínio devem usar o mesmo valor; domínios diferentes precisam de valores únicos. Caso contrário, o consumidor divide uma rede em duas ou funde redes independentes.

ASN, área, router ID, topology ID e descritores completam a identidade. Produtores redundantes também precisam ser consistentes nos TLV opcionais, pois diferenças podem gerar chaves distintas ou propriedades parciais.

Mudar um descriptor TLV muda a chave NLRI. O produtor deve anunciar a nova e retirar a antiga com MP_UNREACH. Uma migração só termina quando a nova identidade existe e a antiga desapareceu do produtor, das RIB, do Adj-RIB-Out e do grafo consumido.

Dois produtores podem envelhecer em direções opostas

O processo da RFC 4271 escolhe entre caminhos BGP. Ele não sabe qual observação está fisicamente mais atual. A melhor rota BGP é uma decisão de protocolo, não um laudo de campo.

No caso da ponte fantasma, não houve duas observações completas concordantes. Houve duas metades antigas. O merge criou uma ligação inteira que nenhuma fonte individual poderia sustentar. Contar fontes, portanto, não mede independência nem frescor.

A prova precisa incluir alcançabilidade do nó de origem por produtor, identidade e idade do LSA/LSP, epoch do LSDB/TED, hora de originação, caminhos selecionado e alternativos, withdrawals esperados e estado do merge. Uma sessão verde não cobre nenhum desses pontos.

A RFC 9552 recomenda retirar objetos de nós de origem inalcançáveis, exceto quando o uso exige explicitamente manter uma visão completa do LSDB. A exceção requer dono, finalidade, idade máxima e sinalização visível. Retenção silenciosa não pode ser o padrão.

NLRI presente pode esconder Attribute perdido

A identidade fica no NLRI e muitas propriedades no BGP-LS Attribute. No contexto de tratamento de erros da RFC 7606, um atributo malformado pode ser descartado enquanto o NLRI permanece.

O consumidor precisa diferenciar propriedade omitida por política, TLV desconhecido preservado, atributo descartado por erro e propriedade inexistente. Tratar tudo como valor vazio permite que um default do algoritmo converta perda de evidência em preferência de caminho.

Conjuntos grandes de atributos podem depender das mensagens estendidas da RFC 8654. Capacidades ou exclusões de TLV diferentes fazem dois consumidores receberem propriedades distintas sob a mesma identidade. Compare fingerprints completos, não apenas contagens de NLRI.

O registro da IANA confirma a definição de códigos. Não confirma que um equipamento coletou corretamente o dado nem que o dado ainda corresponde ao mundo físico.

Um feed não concede poder de instalação

A arquitetura PCE consome topologia/TED; o ALTO trabalha com mapas abstratos; a RFC 8571 transporta métricas TE de desempenho. Nada disso torna o recebimento uma autorização para calcular ou instalar.

Preserve a cadeia. Na fonte: identidade LSA/LSP, protocolo, alcançabilidade e epoch. No Producer: versão, Protocol-ID, Instance-ID, descritores, política, originação e withdrawal. Na propagação: capacidade, UPDATE, seleção, alternativas, descartes e atraso. No Consumer: conjunto, regra de duplicata, merge, falta de atributos, frescor e autorização.

Vincule o caminho calculado ao snapshot exato, restrições, versão do algoritmo e aprovação. Depois prove pedido southbound, aceitação pelo dispositivo, label/FIB e canários positivos e negativos. Sucesso de API não é instalação; instalação não é entrega de pacotes.

Isolamento protege disponibilidade, não reduz sensibilidade

Atualizações Link-State podem ser mais frequentes que prefixos BGP comuns. A RFC 9552 recomenda route reflectors dedicados ou isolamento equivalente e restringe a distribuição a um domínio administrativo, evitando interferência com a distribuição regular.

Topologia e métricas TE podem ser comercial ou operacionalmente críticas. Peerings devem existir apenas entre speakers confiáveis, e peers de consumo não devem enviar UPDATE. Cisco IOS XR, IOS XE e Juniper documentam controles reais de instância, política, fila, tabela e aquisição; comandos e defaults continuam específicos de produto e release.

Sources