Resumo

  • LOCAL_PREF expressa a preferência do sistema autônomo que recebe a rota; não certifica origem, segurança, preço ou desempenho. Seu alcance depende da política efetivamente aplicada.
  • Uma community pode solicitar tratamento, mas a rede receptora controla a conversão em preferência. Padronizar a sinalização não transfere essa responsabilidade ao cliente.
  • A mudança precisa ser verificada na recepção, propagação interna, seleção, instalação na FIB e saída dos pacotes. Restaurar uma configuração não basta para demonstrar recuperação.

O caminho mais curto pode perder

Considere uma ilustração, não um incidente observado. As bordas A e B oferecem caminhos viáveis para o mesmo prefixo. Ambos passaram pelos filtros e têm próximo salto resolvido. A apresenta AS_PATH menor; B, maior. Uma política atribui LOCAL_PREF 100 a A e 200 a B. No procedimento documentado pela Cisco, supondo também weight igual, B pode vencer antes da comparação de comprimento do AS_PATH. O caminho não ficou fisicamente melhor: ganhou prioridade administrativa. Seleção de caminhos da Cisco.

As condições importam. Weight vem antes de LOCAL_PREF nessa implementação. A preferência não reabilita uma rota rejeitada nem assegura que todos os roteadores escolherão uma única saída. Além disso, compara-se o mesmo prefixo: uma preferência maior no agregado não supera uma rota mais específica instalada quando o encaminhamento faz a correspondência mais longa.

O atributo tem quatro octetos e expressa preferência interna, com vantagem para o valor maior. Na operação EBGP comum, não é exportado; confederações são uma exceção. Assim, um observador externo pode perceber uma mudança de tráfego sem conhecer o número que a motivou. RFC 4271, seção 5.1.5.

O número não contém a justificativa

Uma rede pode querer reduzir custo, preservar capacidade ou evitar uma conexão degradada. Essas razões precisam ser traduzidas em regras, mas não viajam dentro do número. Ver 200 não revela se a preferência decorre de contrato, contingência ou exceção temporária. Essa perda de contexto é um problema de governança: uma decisão comercial pode sobreviver à circunstância que a justificava.

O valor 100 tampouco é uma obrigação universal. A RFC 4277, seção 8, registra um padrão de uso, não um padrão obrigatório do protocolo. A documentação da Juniper sobre preferência local descreve o comportamento específico do Junos, inclusive a atribuição padrão na exportação. Migrar equipamentos exige conferir essas etapas, não apenas copiar uma tabela de valores.

Uma classificação operacional útil deve relacionar cada tratamento ao responsável, às sessões autorizadas, ao conjunto de destinos e às exceções. Chamar todas as prioridades elevadas de “rotas boas” apaga justamente o que interessa quando há conflito. Também dificulta descobrir se uma regra posterior anulou a decisão anterior.

Segurança precisa continuar identificável. A RFC 6483, seção 3, trata o resultado da validação de origem como entrada para a política local. Esse resultado não se confunde com LOCAL_PREF. Admitir uma rota e ordenar candidatas são decisões distintas; uma prioridade alta não autentica o vizinho nem comprova autorização de origem. Misturar tudo em um único número torna mais difícil auditar o efeito de uma exceção comercial.

Quem transforma o pedido em ação

A RFC 1998 descreve um mecanismo em que clientes enviam communities combinadas com o provedor, que as associa a valores internos. O cliente solicita um tratamento; a política receptora o executa. Os exemplos históricos demonstram a técnica, não uma tabela comercial válida para qualquer rede atual.

É nessa associação que deve ficar o limite da delegação. Saber um valor não comprova direito de usá-lo. A operadora precisa relacionar a solicitação à sessão, aos prefixos permitidos, à função oferecida e ao âmbito geográfico. Sem essa vinculação, uma facilidade de autogestão pode ganhar alcance maior que o contrato pretendia.

Os exemplos de Large Communities na RFC 8195 incluem funções de preferência e aplicação regional. Um espaço de identificação mais amplo melhora a expressão do pedido, não autentica quem o faz. A versão do mapeamento também importa: o mesmo sinal pode produzir outro resultado depois de uma alteração na política receptora. Documentação pública e configuração em execução precisam continuar correspondentes.

Manutenção mostra o limite pelo lado oposto. A RFC 8326 recomenda preferência baixa, normalmente 0, para caminhos marcados com GRACEFUL_SHUTDOWN. Reduzir a zero não retira a rota. Sem alternativa elegível, ela ainda pode ser usada. Antes de desligar, é necessário verificar alternativas, propagação e convergência. O documento também reconhece que o vizinho pode usar o mecanismo para engenharia de tráfego, motivo adicional para observar seu uso.

Coerência não é uniformidade automática

Não há exigência geral de que todos os participantes internos tenham valores idênticos, como observa a análise de LOCAL_PREF da RFC 4272. Políticas regionais deliberadas são possíveis. O objetivo operacional é que escolhas e encaminhamento sejam compatíveis, não que toda tela mostre o mesmo número.

Isso não elimina o risco. A RFC 4271, seção 9.1.1, alerta que recalcular a preferência de uma rota aprendida internamente pode produzir laços persistentes. Portanto, a diferença deve ser avaliada no desenho de encaminhamento. Não se pode diagnosticar um laço apenas porque os números divergem, nem declarar segurança apenas porque coincidem.

Refletores de rotas tornam essa análise mais exigente. Um cliente pode não escolher uma alternativa porque não a recebeu, e não porque rejeitou sua prioridade. Pontos com visibilidade diferente precisam entrar na verificação. Quando as preferências empatam, outros critérios e a resolução de próximos saltos continuam relevantes. A política define uma ordem; a topologia e as candidatas disponíveis condicionam seu resultado.

Erros de intenção também diferem de erros de formato. A RFC 7606, seção 7.5, distingue o descarte do atributo recebido externamente do tratamento como retirada quando o atributo interno tem comprimento diferente de quatro octetos. Um valor alto, bem formado, mas comercialmente indevido não será detectado por essa verificação de formato.

A prova começa antes do melhor caminho

A mudança deve partir de uma pergunta verificável: quais destinos deveriam trocar de tratamento, em quais entradas e por qual motivo? O impacto real está no conjunto que a regra casa. Uma alteração de uma linha pode abranger muitos prefixos, enquanto uma configuração extensa pode ter alcance estreito. Família de endereços e exceções precisam constar da delimitação.

Na observação, é preciso ligar as candidatas recebidas em Adj-RIB-In à política aplicada e aos valores resultantes. Depois, acompanhar anúncios internos ou telemetria, comparar Loc-RIB em mais de um ponto e examinar próximo salto, FIB e eventual multipercurso. A visão geral de BGP da Juniper ajuda a distinguir elegibilidade, seleção e encaminhamento, além da preference do processo de roteamento, que não é LOCAL_PREF.

Pacotes fecham a verificação. Testes partindo de entradas relevantes devem confirmar o destino efetivamente casado e a saída utilizada. Contadores de uma interface, isoladamente, não atribuem causa à política: outros fluxos podem explicar a alta. Os registros precisam compartilhar contexto de tempo, prefixo e ponto de observação.

Vale preservar um conjunto de controle que não corresponda à regra alterada. Se ele também mudar, a hipótese de efeito restrito precisa ser revista. O piloto deve combinar escopo pequeno, capacidade alternativa e condições claras de interrupção. Na restauração, repetir a cadeia mostra se a política anterior voltou a produzir o comportamento esperado; recuperar apenas o texto da configuração deixa a conclusão em aberto.

Os mecanismos próximos têm papéis diferentes. MED transmite uma indicação externa sobre entrada; AIGP representa métrica acumulada num âmbito administrativo limitado; Large Community expressa informação ou pedido. Route Refresh auxilia a obter e reavaliar rotas, sem definir a política de preferência. Separar essas funções evita atribuir a uma ferramenta de atualização uma autoridade de decisão que ela não possui.

Esta é uma análise de mecanismos e responsabilidades, não uma medição de uma operadora específica. Coletores públicos não demonstram diretamente o LOCAL_PREF interno. Sem estado dos equipamentos, histórico de configuração e evidência de tráfego, seria indevido atribuir uma saída observada a determinado valor. A limitação reforça a necessidade de prova local, em vez de justificar certeza a partir de sinais externos incompletos.