Resumo

  • Treat-as-withdraw mantém a sessão, mas remove da Adj-RIB-In todas as rotas contidas no UPDATE ofensivo que puderem ser identificadas. Não corrige a mensagem nem garante caminho alternativo.
  • Reset de sessão, desativação de AFI/SAFI, treat-as-withdraw e descarte de atributo têm alcances diferentes. Parseabilidade da NLRI, semântica do atributo, política local e o erro mais forte determinam a ação.
  • A prova precisa ligar PDU, classificação, ação e todas as NLRI aos estados antes/depois em RIB e FIB, aos pacotes e à substituição limpa enviada após a correção da origem.

A métrica de disponibilidade pode mentir sem estar errada

Imagine, apenas para explicar o mecanismo, um UPDATE com várias rotas comuns e um atributo de caminho malformado. Não há operadora, prefixo, quantidade, captura ou defeito real neste exemplo. Pelo tratamento básico da RFC 4271, um UPDATE Message Error pode produzir NOTIFICATION, encerrar a sessão e remover todas as rotas aprendidas daquele par. Uma anomalia atinge inclusive rotas válidas transportadas por outros UPDATEs da mesma sessão.

Com treat-as-withdraw da RFC 7606, a sessão pode permanecer Established, mas toda rota contida no UPDATE ofensivo é tratada como retirada e removida da Adj-RIB-In. O painel continua verde enquanto aqueles destinos desaparecem. A resposta reduziu o raio de dano em relação ao reset; não preservou necessariamente alcance.

O agrupamento importa. Não se escolhe um “prefixo obviamente ruim” dentro de uma mensagem cujas rotas compartilham atributos. Cada NLRI daquele UPDATE precisa ser contabilizada. Uma pode encontrar alternativa e outra ficar sem rota; o sucesso da primeira não prova o da segunda.

Quatro ações compram contenção com moedas diferentes

A RFC 7606 ordena as ações da mais forte à mais fraca: reset da sessão, desativação de AFI/SAFI, treat-as-withdraw e descarte do atributo. Reset custa todas as rotas da sessão, mas pode ser necessário quando não há limite analisável. Não é correto chamar a ação mais estreita de sempre mais segura.

A desativação por família tem alcance próprio. Pela RFC 4760, seção 7, o receptor pode eliminar todas as rotas recebidas daquele vizinho para o AFI/SAFI afetado e ignorar rotas subsequentes dessa família durante a sessão; ainda pode encerrá-la. Isso é muito mais amplo que retirar um UPDATE.

Treat-as-withdraw pressupõe localizar e analisar completamente a NLRI relevante. Sem essa fronteira, o receptor não sabe o que retirar. Reset ou contenção da família continuam necessários quando a NLRI não pode ser analisada. Parseabilidade é condição de autoridade para a ação estreita, não apenas conveniência de diagnóstico.

Descarte de atributo retira o atributo e continua processando a mensagem. A RFC 7606 limita essa opção a atributos sem efeito sobre seleção ou instalação. Uma política local, contudo, pode transformar informação normalmente acessória em critério. A segurança do descarte depende da política efetiva, após heranças, não de uma lista abstrata.

Quando uma mensagem contém erros que recomendam ações distintas, vale a mais forte. Registrar só o primeiro erro leve pode ocultar por que a implementação deveria ter desativado uma família ou reiniciado a sessão. A evidência deve preservar as classificações e a decisão final.

Retirar não é ignorar silenciosamente

BGP distribui mudanças incrementais. Se o receptor simplesmente descarta o UPDATE, um estado antigo pode continuar instalado. Treat-as-withdraw força a remoção das rotas identificadas e uma nova seleção. As duas respostas mantêm a sessão; suas consequências na FIB podem ser opostas.

A semântica explica exceções. A RFC 6793 define tratamento para AS4_PATH e AS4_AGGREGATOR no contexto da transição para ASNs de quatro octetos. Alguns atributos malformados ou inválidos naquele contexto são descartados com registro local. Isso não autoriza descartar qualquer dado inconveniente.

A RFC 7607 encaminha AS 0 em AS_PATH ou AGGREGATOR para RFC 7606, e em AS4_PATH ou AS4_AGGREGATOR para RFC 6793. Este não é um relatório sobre AS 0; o caso mostra que a localização do erro altera a ação aplicável.

A RFC 8092 oferece outro contraste: Large Communities com comprimento que não seja múltiplo não nulo de 12 recebem treat-as-withdraw; valores duplicados, sozinhos, não tornam o atributo malformado e são deduplicados. Aparência estranha não substitui regra de formato.

O registro IANA BGP Parameters é a autoridade atual para códigos de atributos e subcódigos de erro. Registrar um código permite identificar o objeto; não concede uma política universal de descarte. É preciso seguir a especificação referenciada.

Uma sessão viva pode dividir o sistema autônomo

A RFC 7606 alerta que treat-as-withdraw em iBGP pode causar estado inconsistente, laços persistentes e black holes. Mesmo sem divergência, destinos do UPDATE podem ficar inalcançáveis ou usar caminhos inferiores. Tolerância ao erro não transforma informação malformada em informação correta.

Refletores ampliam o desafio. Um cliente pode remover a rota enquanto outro conserva alternativa com visibilidade distinta. Examinar apenas o roteador que gerou o log não prova consistência. Refletores, clientes e entradas diferentes precisam ser comparados em Adj-RIB-In, Loc-RIB e anúncios a jusante.

Recuperação também é distribuída. Depois da correção no emissor, um UPDATE limpo deve reconstruir estado em todos os pontos. O teste procura rota antiga residual, repetição da mensagem ruim e divergência entre nós. Uma linha “update recebido” não comprova instalação ou encaminhamento.

A contenção só é auditável se o PDU sobreviver

A RFC 7606 pede ferramentas que identifiquem as NLRI e preservem o UPDATE malformado completo. A primeira evidência deve ser o PDU exato ou um equivalente que declare perdas. Sem ele, desaparecimento de rota não identifica por si só atributo, ação ou causa.

A RFC 7854 permite ao BMP Route Mirroring carregar mensagens recebidas e marcar Errored PDU tratado como retirada. Também define Messages Lost, inclusive quando faltam buffers. Espelhamento pode ser opcional, amostrado ou custoso; “BMP habilitado” não significa registro universal e sem perdas.

Em seguida, associe PDU a vizinho, direção, AFI/SAFI, código, flags, comprimento e cada NLRI. Registre software e release, além da configuração efetiva depois de herança de grupos. Só então anote reset, desativação da família, retirada ou descarte.

Compare Adj-RIB-In antes/depois, estado oculto ou rejeitado, Loc-RIB, anúncios e consistência dos refletores. Verifique próximo salto e FIB/hardware. Por fim, use canários de pacote para cada classe material de destino. Cada camada responde a pergunta diferente.

Preserve controles negativos. Se a ação atingiu um UPDATE, rotas do mesmo vizinho transportadas em outras mensagens devem permanecer observáveis. Se a família foi desativada, outras famílias devem continuar funcionando. Sem controle, oscilação simultânea da sessão ou falha de próximo salto pode ser atribuída incorretamente ao mecanismo.

Alinhe o tempo. PDU, log, RIB, FIB e sonda colhidos em fases diferentes da convergência não formam um único estado. Registre qualidade dos relógios, atrasos e começo/fim da ação. Isso evita apagar black hole breve numa média ou chamar diferença transitória de divergência persistente.

Documentação de fornecedor é evidência limitada

A documentação Cisco IOS XR 24.x Implementing BGP mostra ações como TreatAsWithdraw e DiscardAttr e logs limitados por taxa com vizinho, tamanho, atributo, família e NLRI. Ela demonstra observabilidade do IOS XR, não esquema ou padrão universal.

A página Junos BGP Error Messages descreve reset, retirada, descarte, rotas ocultas e diagnóstico, e aplica a ação mais grave diante de múltiplos atributos. Defaults e comportamento de keep permanecem específicos de release e plataforma.

A documentação Nokia SR OS 26.4 BGP contrasta update-fault-tolerance com tratamento legado e descreve retirada ou descarte em erros não críticos. Hierarquia de configuração, padrão e erros suportados não devem ser generalizados.

A revisão deve capturar configuração efetiva após todos os níveis de herança, não apenas o template pretendido. Antes/depois de upgrade, mensagens controladas podem testar a classificação em ambiente isolado. Isso não autoriza injetar erro num vizinho de produção.

Para filtros, registre por que o atributo é dispensável e quais políticas o consultam. Uma nova correspondência pode tornar insegura uma premissa antiga sem alterar o filtro. Dependência semântica também integra o impacto da mudança.

O encerramento exige correção no emissor. A contenção no receptor limita dano, mas não resolve a origem. UPDATE substituto limpo, reconstrução de todas as NLRI, RIBs coerentes, FIB correta, pacotes entregues e ausência de recorrência formam a prova. Manter o indicador verde é só uma propriedade do método escolhido.