Resumo

  • Maximum-prefix mede quantidade de estado de roteamento, não a validade da rota que ultrapassa o teto. Se a ação for encerrar, uma rota adicional pode remover todas as rotas fornecidas pela mesma sessão.
  • Uma política robusta define vizinho e família, esclarece se conta recebido ou aceito, projeta crescimento e variação, escolhe resposta proporcional e comprova o resultado da notificação aos pacotes.

O número não cai sozinho

Um limite pode passar anos parecendo apenas mais um parâmetro. A equipe vê o valor, observa que o contador está abaixo dele e conclui que existe margem. Essa leitura omite a decisão mais importante: o que o equipamento está autorizado a fazer quando a margem termina.

Se a resposta configurada é fechar a sessão, a atualização excedente não é simplesmente recusada. A conexão BGP é encerrada e as rotas anteriores perdem a origem que as sustentava. Algumas serão substituídas por outros peers, talvez com caminho pior; outras podem desaparecer da FIB. Um mecanismo criado para limitar estado local passa a reorganizar a alcançabilidade.

Isso não torna o limite errado. Uma exportação acidental de tabela completa, um crescimento explosivo de deagregação ou uma nova família inesperada podem consumir memória, processamento e tempo de convergência. O problema surge quando o número é tratado como se carregasse uma avaliação de risco que nunca recebeu. Ele é um orçamento quantitativo; a ação define o raio de impacto.

A liberdade prevista no BGP

RFC 4271 permite impor um teto local ao número de prefixos aceitos de um vizinho. Ao alcançar o teto, a implementação pode descartar novos prefixos e manter a conexão, ou terminar a conexão BGP. Quando encerra por excesso, envia uma notificação Cease.

RFC 4486 identifica a situação com o subcódigo 1 de Cease, Maximum Number of Prefixes Reached. A mensagem pode carregar AFI, SAFI e o valor do teto em quatro octetos. Esses dados ajudam a distinguir a execução de uma política de volume de um encerramento administrativo ou de outra condição de recurso.

O padrão não seleciona o valor porque não conhece o contrato da sessão. Um cliente com poucos prefixos, um peer com visão parcial e um trânsito que entrega rotas completas têm populações legítimas diferentes. A capacidade da plataforma, os caminhos alternativos e os serviços afetados também variam. A decisão local precisa, portanto, de justificativa local.

Um teto de quantidade não valida conteúdo

Ultrapassar o máximo não prova vazamento ou ataque. Entrada de clientes, migração, deagregação legítima em uma contingência e mudança aprovada de agregação podem elevar o total. Da mesma forma, ficar abaixo do máximo não prova correção: um conjunto pequeno pode conter origem indevida, caminho incompatível com a relação ou next hop inseguro.

Filtros de prefixo, políticas de AS_PATH, validação de origem RPKI, regras de next hop e comunidades examinam características das rotas. Maximum-prefix examina volume. As duas famílias se complementam porque estado válido também consome capacidade, mas uma não herda o significado da outra.

Chamar o teto de controle de segurança só é preciso quando o recurso e a falha estão nomeados. Ele pode proteger memória do processo, tempo de convergência e capacidade de absorver atualizações. Não autentica intenção comercial, não culpa a última rota e não afirma que o conjunto abaixo do teto é seguro.

Onde o contador observa

Um mesmo valor pode significar fronteiras diferentes conforme a plataforma.

A documentação BGP do FRRouting descreve maximum-prefix contando prefixos aceitos por padrão. Com force, conta todos os recebidos, inclusive os rejeitados pela política de entrada, o que depende de preservar o estado inbound necessário. O próprio documento alerta que destruir a sessão é muito mais destrutivo do que rejeitar rotas indesejadas.

No Junos, prefix-limit atua sobre prefixos recebidos, enquanto accepted-prefix-limit atua sobre os aceitos pela política. As opções incluem encerramento, descarte do excesso e ocultação, com comportamento de recuperação distinto.

Contar antes da política mostra o volume que o vizinho tentou entregar. Isso revela uma tabela completa mesmo que filtros descartem quase tudo, mas também pode fechar uma sessão por estado que nunca seria utilizável. Contar depois da política aproxima o limite do estado admitido, enquanto filtros fortes podem esconder a pressão total de entrada.

Há ainda a diferença entre prefixo e caminho. ADD-PATH, famílias VPN e estruturas internas podem manter múltiplos caminhos para o mesmo destino. A versão em produção deve ser consultada para definir a unidade real. Transferir o número sem transferir essa definição cria uma proteção apenas aparente.

A ação escolhe o tipo de falha

Avisar mantém sessão e rotas. Dá tempo para investigar, mas não contém crescimento. Seu valor depende de entrega, propriedade e tempo de resposta. Um alarme sem responsável só registra a aproximação do problema.

Descartar o excesso preserva o estado anterior e a sessão. Evita a retirada total, porém cria uma visão parcial, possivelmente sensível à ordem das atualizações. A redução posterior do contador pode não reintroduzir as rotas sem route refresh ou nova avaliação.

Ocultar o excesso mantém informação fora da seleção normal. Pode facilitar a recuperação, mas continua consumindo recursos. Se a meta era reduzir memória, a semântica interna precisa ser medida.

Encerrar interrompe a fonte com clareza. Também elimina todas as rotas que só existiam por aquela sessão. O tráfego migra para alternativas, pode exceder capacidade de backup, alongar caminhos ou perder destinos sem redundância.

Nomes parecidos não asseguram resultado igual. A orientação da Cisco descreve percentual de aviso, encerramento padrão, modo apenas de aviso e intervalo opcional de reinício. A documentação do Arista EOS mostra limite capaz de desabilitar o peering e uma ação de aviso que pode manter a sessão descartando rotas posteriores. O estado final deve ser inspecionado diretamente.

O relacionamento financia o orçamento

RFC 7454 recomenda limites específicos por peering. Para quem deveria anunciar um conjunto restrito, um valor abaixo da tabela completa pode detectar a exportação acidental dela. Para um upstream que entrega a tabela completa, o teto precisa ficar acima do esperado e ainda dentro da capacidade segura do receptor.

O cálculo parte do conjunto legítimo previsto pelo relacionamento. Acrescenta variabilidade observada, crescimento plausível, novos clientes, deagregações autorizadas e migrações. Depois compara a projeção com a capacidade da plataforma e com o custo da ação. O valor precisa de dono, data de revisão e caminho de mudança emergencial.

RFC 4778 recomenda coordenação sobre o volume esperado e folga para oscilações válidas. Um limite invisível para a outra parte pode transformar expansão legítima em indisponibilidade. RFC 7454 também requer revisão periódica porque populações de rotas mudam.

Folga é mais útil quando expressa em tempo e variância. A mesma porcentagem pode cobrir anos em uma relação madura e semanas durante integração. Pouca folga faz o controle disparar por rotina; folga excessiva o torna decorativo. O objetivo é preservar tempo de decisão sem aceitar estado que o receptor não suporta.

Reiniciar não significa recuperar

Um temporizador de reinício reduz interrupção se o excesso já desapareceu. Se o vizinho envia o mesmo conjunto, automatiza um ciclo: estabelecer, ultrapassar, fechar, aguardar e estabelecer de novo.

Tempo decorrido não é evidência de correção. A retomada deve se apoiar em retirada confirmada, filtro corrigido, novo teto aprovado ou capacidade ampliada. Um clear manual sem mudança documentada apenas troca o relógio por uma pessoa.

RFC 8538 sugere tratar o Cease de maximum-prefix como hard reset no contexto de Graceful Restart. Rotas obsoletas não deveriam ser mantidas silenciosamente como se o evento fosse uma reinicialização comum, ocultando uma decisão explícita de volume.

Evidência até o plano de dados

O registro começa pela configuração efetiva de vizinho e AFI/SAFI, incluindo herança, aviso e ação. Também preserva a versão do software e a documentação que define recebido versus aceito, prefixo versus caminho.

No evento, captura a última atualização admitida, a passagem do contador, código e subcódigo Cease, dados AFI/SAFI/teto, estado da sessão, temporizadores e logs possivelmente limitados. Rotas retiradas, descartadas, ocultas e mantidas precisam ser separadas.

Depois acompanha destinos. Quais melhores caminhos mudaram? As alternativas estavam na RIB e foram instaladas na FIB? Os links que receberam tráfego tinham capacidade? Sondas para classes críticas chegaram ao destino? O mesmo total antes e depois não comprova os mesmos prefixos, atributos ou next hops.

O controle só funciona quando mantém o recurso nomeado dentro do objetivo e produz um estado de serviço compatível com a decisão aprovada. O contador isolado não prova nenhum dos dois.

Fontes