Resumo

  • O AC-Flag 0x10 de RFC 9983 declara que um prefixo pretende ser anunciado por múltiplos nós; esse é o alcance exato da sua semântica.
  • Rota calculada, FIB instalada, escolha ECMP, saúde da instância e êxito da aplicação precisam de observação própria, mesmo quando o flag está correto.

Há um atalho linguístico sedutor em operações: uma topologia mostra anúncios repetidos, um coletor vê o AC-Flag e a organização passa a falar de “anycast saudável”. A frase elimina as fronteiras que tornam um incidente investigável.

RFC 9983, publicada pelo IETF como Standards Track em maio de 2026, especifica a OSPFv2 Anycast Property Advertisement. Ela aloca 0x10 como Anycast Flag no registro de flags do Extended Prefix TLV. O significado é deliberadamente restrito: o prefixo é destinado a ser anunciado por mais de um nó. Um prefixo configurado como anycast deve fixar o flag; outro deve removê-lo.

O flag resolve uma pergunta que a mera duplicidade não responde. Dois anúncios podem revelar um serviço anycast intencional, mas também podem surgir em migração, topologia transitória ou configuração errada. Ao transportar a intenção, a rede passa a ter um fato comum. Uma LSA Opaque de Extended Prefix reanunciada para outra área deve preservar o flag, de modo que o fato não se perca na fronteira entre áreas.

Ele continua sendo um fato sobre intenção, não uma confirmação de execução.

A distância entre a declaração e o pacote útil

Uma afirmação de disponibilidade precisa atravessar camadas distintas. Primeiro está a configuração aprovada: qual identidade de gestão declarou o prefixo anycast? Depois estão as LSAs efetivamente originadas e recebidas. Em seguida, cada roteador executa seu cálculo local, aplica filtros e políticas e talvez instale uma rota na FIB. Só então um fluxo real é submetido a recursão, hash ECMP, adjacências e condições de retorno. Por fim, a réplica escolhida precisa estar saudável, possuir o estado correto e completar a operação da aplicação.

Nada em uma camada garante automaticamente a próxima. A LSA pode não alcançar a área relevante. A RIB pode possuir uma candidata que a política impede de chegar à FIB. A FIB pode existir enquanto uma escolha ECMP leva a uma instância drenada. Uma sonda de rede pode passar enquanto a chamada autenticada falha. Chamar tudo isso de “estado anycast” reduz causas diferentes a um símbolo que não as observou.

O RFC mantém essa separação. Ele ainda alerta que receptores que usem o flag para decisões de encaminhamento ou segurança devem considerar erro de configuração e implementação inconsistente. A conclusão não é que o bit seja fraco; é que o bit deve ser usado como a evidência que é, sem atribuir-lhe poder de testemunhar o que ocorreu depois.

Na leitura editorial de Heng Lu, a especificação comum mínima deve conter apenas o que precisa ser comum. “Este prefixo pretende ser multi-nó” cabe nessa camada. Critérios de saúde, política de distribuição, dono do serviço e sucesso de negócio dependem do contexto local. Exigir que o flag os represente troca evidência por conveniência.

Uma contradição que a automação não deve apagar

RFC 9983 proíbe que o AC-Flag e o N-flag de RFC 7684 estejam simultaneamente ativos. Ao receber ambos, o roteador deve tratar a situação como anomalia de configuração, ignorar o N-flag e deveria registrar o evento com limitação de taxa.

Isso é uma instrução para o desenho de observabilidade. Um processo que converte todos os flags em “metadado válido” apaga justamente a contradição que o protocolo identificou. Também não é lícito converter o conflito, sem outras provas, em declaração de indisponibilidade: o RFC não cria essa causalidade. O estado deve ser retirado de qualquer decisão automática positiva, ter suas origens rastreadas e ser corrigido sob mudança controlada.

BGP-LS amplia a vista, não a autoridade

Quando vários roteadores anunciam o prefixo, ao menos um AC-Flag basta para que RFC 9983 o considere anycast; um prefixo único sem o flag é específico de nó. O documento recomenda gestão consistente e monitoração rigorosa de configurações obsoletas, pois o flag prevalece na identificação da propriedade.

O atributo de prefixo de RFC 9085 permite que BGP-LS carregue os flags relevantes. Um inventário passa a enxergar a declaração em outro lugar, mas não adquire por isso a capacidade de provar a FIB de cada ingress, a seleção de um fluxo ou o efeito de uma transação. Três bancos que repetem a mesma origem são três cópias, não três observadores independentes.

RFC 9983 também introduz o dado gravável anycast-flag nos modelos YANG de OSPF e gestão de roteamento, RFC 9129 e RFC 8349. Quem administra esse dado pode alterar uma afirmação da qual dependem ferramentas posteriores. O RFC exige transporte seguro, autenticação mútua e cita NACM para restringir acesso. Isso transforma a gestão do flag em uma superfície de controle: escritor, revisão, versão, escopo e tratamento de conflito devem ser auditáveis.

Um inventário que preserve o caminho da verdade

Para cada prefixo crítico, ligue a configuração e seu aprovador, LSAs por área, RIB/FIB nos ingressos relevantes, evidência de seleção de dados, saúde/capacidade de cada réplica e resultado de aplicação. O objetivo não é bloquear alertas à espera de todos os itens. É fazer com que o nome da conclusão corresponda ao que foi visto. “AC-Flag observado” é preciso. “Serviço anycast saudável” requer a cadeia inteira.

Essa disciplina altera a qualidade da resposta a incidentes. Sem ela, equipes corrigem o anúncio ou a tela e deixam intacta a decisão local que falhou: seleção, admissão por saúde, identidade da instância ou estado de aplicação.