Resumo

  • A classe opcional transitiva permite que uma extensão atravesse equipamentos que ainda não entendem sua semântica. Se o caminho for aceito e anunciado adiante, o atributo acompanha a rota com Partial igual a 1; nenhum AS posterior pode apagar essa marca.
  • Partial registra custódia semântica incompleta. Não autentica a origem, não aponta qual salto ignorou o tipo, não valida o valor e não prova suporte ou consentimento de política.
  • O tratamento revisado de erros pode descartar o atributo ou tratar a rota como retirada sem derrubar a sessão. É preciso correlacionar bytes recebidos e enviados, ação tomada, RIB, FIB e pacotes — não apenas vizinhança Established.

Às 2h10, uma operadora testa um novo atributo de política entre dois pontos controlados. A borda de origem usa a versão nova. O trânsito intermediário não reconhece o código. A borda receptora acaba de ser atualizada e sabe decodificá-lo.

O UPDATE chega corretamente enquadrado: flags, tipo, comprimento, valor e um prefixo IPv4. O trânsito consegue delimitar o objeto, mas não interpretar seu conteúdo. Como Optional e Transitive estão ativos, aceita o caminho, preserva os bytes, ativa Partial e anuncia a rota ao receptor.

Ali a autoridade muda. O receptor conhece o tipo e aplica a gramática específica. O valor é inválido; a rota vira treat-as-withdraw. A sessão TCP continua, os KEEPALIVEs chegam e o trânsito ainda conta o prefixo. Só o caminho do cliente desaparece.

O episódio é sintético, mas o limite é real. O BGP foi desenhado para que informação futura atravesse nós antigos sem uma atualização global sincronizada. A consequência é que um roteador pode transportar corretamente uma semântica que não tem como verificar. Uma atualização posterior transforma o que era opaco em algo analisável — e talvez rejeitável.

Quatro bits, quatro compromissos

Os quatro bits superiores de Attribute Flags têm funções separadas. Optional distingue extensões de atributos well-known que toda implementação deve reconhecer. Transitive define se um atributo opcional desconhecido pode cruzar uma fronteira BGP. Partial indica informação incompleta em um atributo opcional transitivo. Extended Length escolhe um campo de comprimento com um ou dois octetos. Os quatro bits inferiores são reservados.

Um atributo well-known precisa ser entendido; Transitive fica ativo, Partial deve ser zero. Um atributo opcional não transitivo pode ter utilidade entre falantes compatíveis, mas um receptor que não o reconhece o ignora e não o propaga. Partial também é zero nessa classe.

A reserva para evolução está no opcional transitivo. O RFC 4271 não exige que todos entendam todas as extensões. Um caminho com atributo desconhecido dessa classe deve normalmente ser aceito. Se for repassado, o atributo vai junto e Partial passa a 1.

É uma promessa estreita: custódia de bytes, não compreensão. O roteador conhece limites, código e flags. Não sabe se o valor tem autorização comercial, origem autêntica, estrutura interna válida ou comportamento seguro em um decodificador futuro.

Extended Length também não certifica o conteúdo. Só muda a largura do campo que anuncia o tamanho. Um objeto pode estar bem delimitado e ser semanticamente defeituoso. O nó antigo o preserva justamente porque não possui a lógica que encontraria o erro.

Partial não é nota de confiança

O nome sugere “danificado”, “não verificado” ou “baixa confiança”. O significado é mais específico. Um falante que repassa um atributo opcional transitivo desconhecido marca Partial. Se um falante posterior reconhecer o atributo e receber a marca, não pode limpá-la. Um falante que não seja a origem e adicione um novo atributo dessa classe também a utiliza.

A marca afirma que não se pode presumir custódia semântica completa desde a origem. Não identifica o AS ignorante, não conta quem compreendeu o objeto, não registra uma alteração permitida e não prova que o emissor tinha direito de anexá-lo.

Partial tampouco é autenticado. É um bit dentro do UPDATE e herda a confiança da sessão e da cadeia operacional. Não substitui validação de origem, política de relacionamento, proteção do transporte, procedência de configuração ou evidência de pacotes.

Sua utilidade está na modéstia: preserva a admissão de que o objeto cruzou uma fronteira sem domínio semântico pleno. Isso pede investigação e política localizada, não confiança automática nem bloqueio indiscriminado.

Uma atualização desloca a fronteira do conhecimento

“Desconhecido” depende de implementação, release, família e função habilitada. Os mesmos bytes podem ser opacos na terça-feira e interpretados na quarta.

Enquanto o tipo é desconhecido, seu interior não é validado. Quando passa a ser reconhecido, entram em vigor flags permitidos, comprimento, subestruturas, significado e ação de erro. Um valor transportado por meses pode produzir attribute discard ou treat-as-withdraw no primeiro decodificador ou depois de uma atualização local.

Isso não prova regressão. A versão nova talvez seja a primeira capaz de detectar uma malformação real. O trânsito antigo também pode ter cumprido perfeitamente a base. O incidente nasce da combinação entre adoção desigual, propagação opaca e uma fronteira semântica recém-ativada.

Por isso, toda atualização precisa de um inventário prévio de rotas com atributos desconhecidos: código, flags, comprimento, hash do valor, vizinho, AFI/SAFI, NLRI e Partial. Depois, verifica-se quais códigos viraram conhecidos, qual validação passou a rodar, qual ação ocorreu e quais rotas mudaram.

Sem essa base, a perda vira “bug de software”. Com ela, é possível separar falha do parser, rejeição correta, contenção ampla demais e emissor fora do contrato.

Preservar a sessão não preserva o serviço

O modelo inicial do BGP-4 podia reiniciar uma sessão inteira por causa de um atributo malformado, eliminando rotas válidas não relacionadas. Atributos opcionais transitivos ampliavam o risco: nós ignorantes podiam distribuir um valor não verificado até muitos sistemas que o reconheciam.

O RFC 7606 restringe vários erros a três ações relevantes. Session reset continua sendo a mais forte. Treat-as-withdraw remove do Adj-RIB-In as rotas do UPDATE defeituoso e mantém a sessão. Attribute discard remove o atributo e continua processando o anúncio.

Não é uma escala simples. Descartar o atributo pode ser mais enganoso que retirar a rota: a conectividade continua, mas desaparece a semântica que deveria influenciar seleção ou instalação. Por isso o descarte só serve, em princípio, a atributos sem efeito nessas decisões.

Treat-as-withdraw torna a falha visível como perda de rota, mas pode passar despercebido em monitores de sessão. O vizinho segue Established, o Hold Timer não expira e há KEEPALIVEs. Nada disso prova que o NLRI continua presente.

Se Optional ou Transitive conflitar com a definição de um atributo reconhecido, o RFC 7606 normalmente exige treat-as-withdraw, salvo regra específica. MP_REACH_NLRI ou MP_UNREACH_NLRI duplicado provoca treat-as-withdraw para todas as rotas do UPDATE e preserva a sessão; para a maioria dos demais atributos, ocorrências posteriores são descartadas. Com vários erros, vale a ação mais forte.

Portanto, “suporta RFC 7606” não fecha a questão. É necessário saber a classificação aplicada, a regra daquele atributo e o conjunto resultante de rotas. Um equipamento pode salvar corretamente a sessão e interromper o serviço.

A rede local mantém o poder de contenção

A propagação padrão protege a extensibilidade, mas não obriga um operador a permitir que todo código desconhecido atravesse toda fronteira produtiva. Procedência, custo e efeito a jusante podem ser requisitos prévios.

A documentação atual da Juniper expõe duas escolhas diferentes: remover atributos opcionais transitivos desconhecidos mantendo a rota, ou retirar as rotas que os carregam. Há exceções por código e escopo global, de grupo ou vizinho. O readback de vizinhança mostra atributos descartados e atributos que causaram retirada.

São controles locais, não uma lei universal. Remover o atributo pode preservar pacotes apagando uma semântica necessária. Retirar qualquer rota com código novo pode transformar adoção gradual em indisponibilidade. Uma exceção larga demais reabre a exposição.

A pergunta correta é: qual código atravessa qual relacionamento e AFI/SAFI, depois de qual evidência, com qual ação diante da incerteza? Cliente, route server, refletor interno, peer e laboratório podem exigir políticas diferentes.

A documentação do Cisco NX-OS mostra a granularidade necessária: listar prefixos com atributos desconhecidos ou descartados e exibir flags, tipo, comprimento e valor para uma rota. Um contador global não distingue experimento benigno de objeto anômalo presente em centenas de milhares de prefixos.

Propagação é custódia, não consentimento

O roteador que preserva um atributo que não entende não concorda com seu significado; cumpre um contrato de transporte de informação. Confundir os atos cria conclusões comerciais e de segurança falsas.

Se o atributo expressa uma classe de serviço, um AS de trânsito ignorante não passa a oferecer o serviço, validar elegibilidade ou aceitar responsabilidade. Partial não transforma transporte em anuência. Cada rede receptora conserva seus contratos e políticas.

Desconhecido também não quer dizer hostil, e código atribuído pela IANA não quer dizer seguro. O registro dá identidade estável ao objeto; não prova conformidade do emissor nem ausência de falhas de recursos, parsing ou lógica no receptor.

Há soberania prática mesmo sobre bytes opacos. A rede decide se eles entram em logs, cruzam tenants, saem do domínio, disparam ação de rota ou permanecem disponíveis para investigação. Opaco não significa sem custodiante.

A prova deve guardar hashes dos bytes recebidos e enviados, não apenas texto de CLI. Exibições podem normalizar flags, abreviar valores ou omitir atributos. UPDATE bruto e Adj-RIB pré e pós-política mostram se o sistema preservou, alterou ou removeu o objeto.

O canário precisa tornar a ignorância observável

Não se deve inventar um código aleatório na tabela pública. O ensaio pertence ao laboratório, a uma relação bilateral controlada ou ao procedimento da extensão real: poucos prefixos, código conhecido, política reversível e sondas independentes.

Quatro estágios devem ser registrados: UPDATE de origem com bytes exatos; salto ignorante com Partial antes e depois e anúncio de saída; salto reconhecedor com versão do decoder, validação, ação e Adj-RIB-In; plano de dados com rota selecionada, FIB e pacotes.

Teste um valor válido, um valor bem enquadrado mas semanticamente inválido e um controle desconhecido não transitivo. O primeiro produz o efeito documentado; o segundo, a ação de erro; o terceiro para no nó ignorante. Assim se comprova a classificação, não só a presença.

Depois, atualize o salto antes ignorante e repita o mesmo UPDATE. Um resultado diferente pode estar correto. Esse ensaio revela a mudança essencial: reconhecer o tipo desloca a fronteira de validação.

O rollback precisa de duas alavancas independentes. Uma remove ou corrige o atributo na origem; outra contém o tipo na fronteira sem reiniciar sessões alheias. Se alguma depender de código emergencial, o teste não está pronto.

A primazia do código em execução é literal aqui. A norma fornece o mecanismo; a cadeia implantada decide se bytes e rota sobrevivem. A prova é o UPDATE capturado, a transição de Partial, a ação local, o RIB e o pacote entregue.