Resumo

  • Multipath admite várias rotas qualificadas no encaminhamento local, mas não garante capacidade dobrada, diversidade física ou divisão igual de bytes.
  • BGP define os candidatos; resolução e hardware montam o grupo; o hash e a população de fluxos determinam o uso efetivo.
  • A validação precisa ligar Adj-RIB-In, RIB, FIB, contadores por membro, filas e testes de falha. Uma tela de rotas prova apenas uma etapa.

A metade que nunca esteve no protocolo

Considere um exemplo de mecanismo, não um incidente. Duas rotas para o mesmo prefixo atendem aos critérios multipath do equipamento e aparecem em um grupo ECMP. O plano registra “50/50”. Um fluxo grande e persistente cai no membro A, ocupa sua fila e deixa o membro B com folga.

As sessões podem continuar estáveis e ambas as rotas permanecer instaladas. O erro não precisa estar no BGP nem no ECMP; está na inferência de que dois membros significam metade dos bytes para cada um. O hash distribui identidades de fluxo, não transforma todos os fluxos no mesmo tamanho.

A RFC 4271 descreve a avaliação de rotas elegíveis, a escolha, a instalação na Loc-RIB e a determinação do next-hop imediato. Implementações de multipath estendem localmente esse resultado mantendo caminhos adicionais que se qualificam. Não criam uma obrigação interdomínio para que todos os pares anunciem ou usem o mesmo conjunto. RFC 4271, seção 9.1.2

“Iguais” também depende da implementação. A Cisco documenta condições específicas e mantém um best path designado para anúncio. O FRRouting faz a checagem multipath depois de critérios anteriores e permite relaxar a igualdade exata do AS_PATH. A Arista registra ainda outro comportamento padrão para esse relaxamento no contexto EOS citado. São contratos locais de admissão, não certificados de capacidade, independência ou risco idênticos. Documentação Cisco, documentação FRRouting, documentação BGP do Arista EOS

Três decisões em sequência

Primeiro vem a elegibilidade: quais rotas são viáveis, permitidas pela política e equivalentes segundo o produto? maximum-paths é um teto, não evidência de quantos membros chegaram ao ASIC.

Depois vem a construção. Cada next-hop precisa ser resolvido e programado na FIB. Dois endereços podem compartilhar túnel, placa ou circuito remoto; quantidade de rotas não prova diversidade física. Restrições de hardware também podem produzir duas entradas no RIB e um único membro no grupo efetivo.

Por fim, o hash escolhe o membro de cada fluxo. A RFC 2991 explica por que manter um fluxo no mesmo caminho reduz reordenação e como mudanças de membros podem perturbar pacotes. A RFC 2992 analisa o hash-threshold. Uma boa distribuição do espaço de hash pode aproximar a contagem de fluxos, mas não iguala bytes quando os fluxos têm tamanhos diferentes. RFC 2991, RFC 2992

Assim, três fatos exigem provas próprias: as rotas se qualificaram, os membros foram programados e o tráfego realmente os utilizou.

O hash depende do que consegue enxergar

Os campos disponíveis mudam com família de endereços, encapsulamento, hardware e configuração. No IPv6, o flow label pode acrescentar entropia quando cabeçalhos de transporte não estão acessíveis. A RFC 6438 também delimita as dificuldades de túneis, fragmentos e conteúdo opaco. Muitas conversas internas com o mesmo tuple externo podem parecer um só fluxo. RFC 6438

Não é seguro escrever apenas “hash de cinco campos”. A auditoria registra plataforma, família, encapsulamento, campos, seed e granularidade. A documentação da Arista sobre seed, polarização e ECMP resiliente mostra essa superfície local, sem estabelecer um padrão universal. Documentação Arista

A composição do tráfego pesa tanto quanto o algoritmo. A RFC 7424 descreve muitos fluxos mapeados em poucos enlaces e destaca o desequilíbrio criado por fluxos grandes. Milhares de sessões curtas podem gerar uma média suave; um backup ou replicação pode dominar um membro por horas. Pacotes, bytes, fila, descartes e latência respondem a perguntas diferentes. RFC 7424

Membros com capacidades distintas acrescentam uma decisão de política. ECMP comum não descobre sozinho que um enlace comporta dez vezes o outro. ECMP ponderado e roteamento adaptativo são mecanismos separados, com riscos e evidências próprios.

Visibilidade não é encaminhamento

ADD-PATH aumenta o que o vizinho pode ver. A RFC 7911 permite anunciar vários caminhos para o mesmo prefixo sem substituir implicitamente o anterior, mas não obriga o receptor a instalar todos nem determina a divisão de tráfego. O inverso também ocorre: multipath local com anúncio apenas do best path. RFC 7911

PIC trata de preparar reparo rápido após falha, não de membros carregando tráfego simultaneamente em estado normal. O Junos documenta ainda a seleção BGP multipath e a política de load balancing da tabela de encaminhamento como etapas separadas. O rótulo histórico “per-packet” frequentemente descreve hash por fluxo e precisa ser interpretado no contexto do equipamento. Documentação Junos

Da rota recebida ao pacote observado

Defina antes do teste os prefixos, famílias, pares, limite, responsável e condição de rollback. Preserve os candidatos Adj-RIB-In e o resultado exato da comparação. Se houver multipath-relax, registre o que foi relaxado; mesmo comprimento não significa mesmo risco.

Verifique a recursão, os domínios de falha e o identificador do grupo realmente programado. Se o RIB mostra dois caminhos e o hardware um, a investigação começa em resolução, capacidade ou programação, não no hash.

Meça por período representativo os pacotes, bytes, descartes e filas de cada membro. Identifique os fluxos dominantes e use sondas com muitas chaves a partir dos ingressos relevantes. Um ping demonstra apenas seu caminho. Remova e restaure um membro: hash resiliente pode limitar remapeamento, mas não elimina toda movimentação ou reordenação.

O rollback só termina quando candidatos, RIB, FIB e comportamento de pacotes retornam ao estado esperado.