Resumo

  • O ASN 0 é uma não identidade reservada: não pode ser usado pelo peer em OPEN nem carregado em AS_PATH, AS4_PATH, AGGREGATOR ou AS4_AGGREGATOR. Já ORIGIN 0 é um código BGP válido para IGP.
  • RFC 7607 distribui a autoridade de recusa pelo campo: encerra a tentativa de conexão que reivindica AS 0, trata como withdrawn as rotas de um AS_PATH com zero e descarta apenas o atributo agregador ou de transição malformado quando essa é a regra aplicável.

O relatório de mudança dizia apenas: “AS0 vazou durante a migração”. A frase parecia suficiente até a equipe comparar os equipamentos. Em um deles, o peer não passava de OpenSent. Em outro, a sessão continuava estável, mas algumas rotas sumiam. Em um terceiro, a rota permanecia e o campo AGGREGATOR desaparecia.

Não era uma divergência sobre a reserva do número. Era uma divergência sobre onde o número havia sido escrito.

RFC 7607 proíbe AS 0 em cinco lugares: o AS do peer em OPEN e quatro atributos de UPDATE — AS_PATH, AS4_PATH, AGGREGATOR e AS4_AGGREGATOR. O documento não transforma todos os casos em reset de sessão. Ele encaminha cada ocorrência para o procedimento correspondente ao objeto que ficou sem significado confiável.

Essa precisão protege dois interesses ao mesmo tempo. Impede que uma identidade impossível seja aceita ou propagada e impede que o receptor derrube estado válido que não depende do erro. A disciplina central não é “bloquear o maior número de coisas”; é manter a localização do zero até o fim da investigação.

Reservado não quer dizer provisório

O registro atual de Autonomous System Numbers da IANA classifica 0 como Reserved e aponta para RFC 7607. O registro de ASNs de propósito especial mostra outros números com regras próprias: AS_TRANS 23456, faixas de documentação, faixas privadas e os últimos números reservados.

AS_TRANS representa informação durante a convivência de speakers com capacidades de dois e quatro octetos. ASNs privados podem ser usados dentro de um escopo controlado. AS 0 não representa “ASN ainda não conhecido”, “rede sem nome” nem “preencher depois”.

O problema costuma nascer em sistemas que não falam BGP. Uma coluna não aceita null; um template converte string vazia em inteiro; a automação de aquisição não recebeu o local-AS definitivo. O valor padrão atravessa a fronteira e vira uma afirmação protocolar.

Bloquear na geração é correto. A documentação Junos sobre ASNs de quatro bytes registra, para o produto e escopo descritos, falha de commit ao configurar números restritos como zero. Isso prova uma barreira de produto, não o comportamento de todos os neighbors e versões. O parser de entrada continua responsável por mensagens recebidas.

Zero no OPEN: a identidade não se estabelece

RFC 4271 define o campo My Autonomous System do OPEN. RFC 7607 determina que, ao receber zero como peer AS, o speaker deve abortar a conexão e enviar NOTIFICATION OPEN Message Error com subcódigo Bad Peer AS. Um roteador também não deve iniciar a conexão dizendo pertencer ao AS 0.

A unidade recusada é a adjacência pretendida. Não existe uma sessão Established da qual se possam preservar algumas rotas. A prova deve guardar OPEN, NOTIFICATION, direção da conexão, endpoints, horário, número de tentativas e configuração que gerou o valor.

Reduzir a validação de peer-AS para “fazer subir” não é remediação. Nenhuma parte controla AS 0 e pode autorizar a exceção. Uma migração que precise conviver com ASNs reais diferentes deve modelar esses ASNs explicitamente e testar o efeito de local-as ou mecanismo equivalente.

Zero no AS_PATH: a alcançabilidade é retirada

Um UPDATE cujo AS_PATH contém AS 0 é malformado segundo RFC 7607. O processamento segue RFC 7606, que atribui treat-as-withdraw a AS_PATH malformado. Todas as rotas daquele UPDATE são tratadas como retiradas e removidas do Adj-RIB-In.

A sessão pode permanecer de pé. Esse detalhe evita que uma única rota defeituosa retire milhares de anúncios válidos do mesmo peer. A preservação da sessão não suaviza a proibição; ela restringe o dano à alcançabilidade que não pode mais ser acreditada.

O receptor não deve apagar o zero e concatenar o restante do caminho. Também não deve substituir 0 pelo ASN que “provavelmente” deveria estar ali. AS_PATH participa de detecção de loop e seleção e representa o que o vizinho afirmou. Uma edição local fabricaria procedência. A origem do defeito precisa emitir um novo caminho.

Filtros de borda ajudam. A documentação de FRRouting traz um exemplo de lista para bogon ASN que casa _0_ no AS_PATH. É defesa em profundidade e oferece contadores úteis. Não observa o peer AS do OPEN nem demonstra o tratamento de AGGREGATOR e dos atributos AS4.

Zero no AGGREGATOR: perde-se o atributo

AGGREGATOR identifica o AS e o speaker que formaram uma rota agregada. RFC 7607 também proíbe zero nessa posição, porém RFC 7606 define attribute discard para AGGREGATOR malformado. O atributo é descartado e o restante do UPDATE continua em processamento.

A rota pode sobreviver se passar pelos outros controles. Isso explica por que equipamentos conformes podem mostrar resultados diferentes diante de “AS0 em UPDATE”: AS_PATH com zero exige retirada da alcançabilidade; AGGREGATOR com zero exige descarte do atributo.

Sobreviver não significa que a ocorrência possa ser ignorada. A informação de agregação foi perdida e o emissor produziu um campo proibido. O log local deve nomear atributo, peer, horário e ação, e a correção precisa alcançar o sistema que escreveu o valor.

RFC 6793 define AS4_PATH e AS4_AGGREGATOR para a transição de ASNs de quatro octetos. RFC 7607 declara zero malformado nesses atributos e usa os procedimentos de RFC 6793. No contexto correspondente, o speaker descarta o atributo, registra o erro localmente e continua o UPDATE.

Os OPENs negociados fazem parte da evidência. Dois NEW speakers, capazes de quatro octetos, não devem transportar AS4_PATH ou AS4_AGGREGATOR entre si. Portanto, a simples presença do atributo pode ser anormal antes de examinar seu conteúdo. Um coletor sem o contexto de capacidade enxerga bytes, mas não consegue explicar a decisão.

ORIGIN 0: um teste para a telemetria

RFC 4271 reserva outro uso legítimo para zero. No atributo ORIGIN, 0 significa IGP, 1 significa EGP e 2 significa INCOMPLETE. ORIGIN 0 não afirma que o ASN originador seja zero.

Uma plataforma que indexa todos esses valores em um campo genérico pode misturar ORIGIN, origin ASN derivado de AS_PATH, rota default e métricas. O ruído leva à supressão de alertas; a supressão pode esconder a violação real.

O teste de regressão deve incluir um UPDATE válido com ORIGIN 0 e cinco amostras com ASN 0 nos locais proibidos. O sistema precisa aceitar o canário válido, identificar cada campo inválido e registrar a ação esperada. Rejeitar todo byte zero não é uma implementação rigorosa; é uma implementação sem semântica.

Guardar PDU ou representação sem perda, tipo de mensagem, type code do atributo, direção, peer, AFI/SAFI, capacidades, versão e timestamp torna o evento reproduzível. O rótulo “AS0 detectado” pode existir na interface, desde que nunca substitua o registro.

O AS 0 ROA pertence a outra linha de autoridade

RFC 6482 define ROA como objeto assinado com um asID e autorizações de prefixo. RFC 6483 explica que um detentor de recursos pode usar asID 0 para declarar que o prefixo e seus more-specifics não devem ser usados no roteamento.

Isso não autoriza uma rota a usar AS 0 como origem. RFC 6907 deixa a consequência clara: nenhuma rota BGP válida tem origin ASN 0, portanto nenhuma rota pode casar um AS 0 ROA. Uma rota de ASN real pode ficar Invalid quando há cobertura e nenhum ROA candidato valida a origem e o comprimento.

Há uma ressalva essencial. RFC 6483 permite coexistência entre AS 0 ROA e ROAs de ASNs roteáveis. Se um destes casa prefixo, maxLength e origem real, o resultado é Valid. O AS 0 ROA não revoga uma autorização positiva compatível.

Também não se deve fundir relógios. OPEN e UPDATE são processados no fluxo da sessão. O ROA passa por publicação, cadeia de certificados, coleta e cache de relying parties. Corrigir a mensagem BGP e corrigir o objeto RPKI podem produzir convergência em horários diferentes. Um case file precisa de duas cronologias ligadas, não de uma única coluna “AS0”.

Provar recepção, seleção e exportação

RFC 7854 define BMP e permite observar UPDATEs, peer state e Adj-RIB-In pre- e post-policy. A primeira vista demonstra o que chegou; a segunda, o que sobreviveu ao tratamento local. Sem ambas, não se separa falha do emissor de contenção do receptor.

RFC 9069 adiciona Loc-RIB ao BMP. Ela mostra as rotas escolhidas pelo Decision Process, não o encaminhamento efetivo. Quando há alegação de impacto, FIB e tráfego precisam completar a prova.

RFC 8671 adiciona Adj-RIB-Out pre- e post-policy. A obrigação de não propagar AS 0 pode ser testada nos peers materiais. Um coletor não prova ausência global, mas uma lista explícita de saídas cria um perímetro auditável.

RFC 7454 oferece a disciplina geral de filtros de entrada, saída e caminho. RFC 7607 fornece a decisão específica. A cadeia operacional deve ligar mensagem original, capacidades, ação, diferenças de RIB, seleção, encaminhamento quando relevante, saídas, causa no gerador e nova mensagem limpa.

Fontes