Como o BGP faz a seleção da melhor rota: passo a passo para provedores

O que acontece antes de o BGP comparar as rotas

Antes de comparar, o roteador descarta o que não pode usar: rotas barradas pelo filtro de entrada, com próximo salto inalcançável ou com o próprio ASN no caminho. Só o que sobra entra na disputa pelo best path.

Cada vizinho manda as rotas que conhece, e o roteador guarda essas listas separadas, uma por sessão. A RFC 4271 chama esse depósito de Adj-RIB-In; dali o roteador tira, para cada prefixo, um único caminho para instalar e para repassar aos outros vizinhos.

A escolha é feita prefixo a prefixo, e não operadora a operadora. Um mesmo link pode ser o caminho preferido para metade da internet e o reserva para a outra metade, e é isso que os serviços de BGP para provedores organizam quando a borda tem mais de uma saída.

• Filtro de entrada: prefix-list, filtro de AS_PATH ou RPKI podem rejeitar a rota antes de ela ser avaliada.
• Próximo salto: se o roteador não tem rota até o next-hop, a rota fica guardada, mas não concorre.
• Laço de AS: a rota que já traz o ASN do provedor no AS_PATH é descartada para evitar laço.

O segundo item é o que mais confunde quem está começando. Num iBGP sem next-hop-self, a rota aparece no roteador de núcleo, mas nunca vira ativa, porque o endereço do enlace de trânsito não é conhecido ali.

Prefixo mais específico ganha antes de qualquer atributo

O best path decide entre caminhos para o mesmo prefixo, com a mesma máscara. Se existe um /24 e um /23 que cobrem o mesmo endereço, a tabela de encaminhamento usa o /24, não importa o LOCAL_PREF do /23.

Essa regra explica muitos casos de tráfego que "ignora" a política. Se uma operadora recebe do seu cliente um /24 e da outra só o /22 agregado, todo o tráfego para aquele /24 vai pela primeira, mesmo com prepend no anúncio.

Como o BGP seleciona a rota: o algoritmo do melhor caminho

O algoritmo é uma sequência de desempates, e a ordem importa mais que os valores. Um critério de cima sempre vence os de baixo, por maior que seja a diferença entre eles.

Os fabricantes acrescentam passos próprios a essa lista. Cisco e MikroTik colocam um peso local, o weight, antes do LOCAL_PREF, e alguns preferem a rota eBGP mais antiga antes do router-id [CONFIRMAR na documentação da versão do equipamento].

A leitura certa da tabela é de cima para baixo: o roteador olha o LOCAL_PREF de todos os caminhos e fica só com os empatados no valor mais alto. Depois repete o processo com o AS_PATH, e assim por diante, até sobrar um.

LOCAL_PREF: a decisão de saída fica com o provedor

O LOCAL_PREF é um número que o provedor coloca nas rotas ao recebê-las e que circula só dentro do próprio ASN. Quanto maior, mais preferido o caminho; o padrão costuma ser 100 [CONFIRMAR na versão do equipamento].

Como vem primeiro, ele resolve a maior parte das políticas de saída. Colocar 200 nas rotas do IX.br e 100 nas dos trânsitos faz o tráfego sair pelo ponto de troca sempre que o destino estiver lá, sem depender do tamanho do caminho.

AS_PATH e ORIGIN, os critérios que vêm de fora

Empatado o LOCAL_PREF, vence o caminho com menos ASNs no AS_PATH. É o critério que mais se parece com "caminho mais curto", mas conta redes atravessadas, não distância nem atraso.

O ORIGIN raramente decide alguma coisa hoje, porque quase todas as rotas chegam marcadas como IGP. Ele aparece quando alguém redistribui rotas no BGP sem cuidado e elas chegam como incompletas.

Por que o MED só vale entre rotas do mesmo vizinho?

O MED é a sugestão de um vizinho sobre qual de vários links com ele você deve usar. Por padrão, o roteador só compara MED entre rotas que vieram do mesmo ASN, porque valores de operadoras diferentes não têm a mesma escala.

Na prática, o MED serve quando o provedor tem duas conexões com a mesma operadora, em cidades diferentes. Entre a operadora A e a operadora B, ele simplesmente não entra na conta.

Desempates finais: eBGP, custo interno e router-id

Quando tudo empata, o roteador prefere a rota que aprendeu direto de outra rede e, depois, a que tem o próximo salto mais perto pelo protocolo interno. É o que faz cada borda sair pelo próprio link quando as duas têm caminhos iguais.

Se ainda houver empate, vence o vizinho de menor router-id. Esse último passo é um sorteio disfarçado: se a sua política depende dele, ela não é uma política.

Exemplo: o BGP seleciona a rota do IX.br como melhor caminho

O exemplo mostra um provedor que recebe o mesmo destino por dois trânsitos e pelo IX.br, sem nenhuma política, e depois com uma regra de LOCAL_PREF. Os números de ASN e de IP são de documentação.

1. Cenário: o provedor AS 64500 recebe 198.51.100.0/24 pelo trânsito A (AS_PATH 64496 64505 64510), pelo trânsito B (64497 64510) e pelo route server do IX.br (64505 64510).
2. LOCAL_PREF: sem política, as três rotas chegam com o valor padrão e empatam no primeiro critério.
3. AS_PATH: o trânsito A sai da disputa com três ASNs; B e o IX.br seguem empatados com dois.
4. ORIGIN e MED: as duas rotas são IGP e vêm de vizinhos diferentes, então o MED não é comparado.
5. Desempate final: ambas são eBGP com o mesmo custo interno, e a escolha cai no router-id do vizinho, que ninguém escolheu.
6. Correção: uma regra de entrada coloca LOCAL_PREF 200 nas rotas do IX.br, e o ponto de troca vence no primeiro critério.

# Todas as rotas recebidas para o prefixo, ativas e inativas
/routing/route/print detail where dst-address=198.51.100.0/24

# Cadeia de entrada do route server do IX.br
/routing/filter/rule
add chain=ixbr-in rule="if (dst-len > 24) { reject }"
add chain=ixbr-in rule="set bgp-local-pref 200; accept"

# Aplicar a cadeia na conexão com o route server
/routing/bgp/connection/set [find name=ixbr-rs1] input.filter=ixbr-in

Depois da mudança, o mesmo comando de consulta deve mostrar a rota do IX.br como ativa e as dos trânsitos como reservas. Numa borda real, a cadeia do IX.br também leva os filtros de prefixo e de RPKI que já existiam.

O que o exemplo ensina

Sem política, o resultado parece aleatório porque é decidido no fim da lista. Basta um vizinho trocar de router-id, ou uma sessão reiniciar, para o tráfego mudar de link sem ninguém ter mexido na borda.

A política boa decide cedo, no LOCAL_PREF, e deixa os critérios de baixo só para casos de empate real. É o mesmo princípio usado na análise de rotas assimétricas, quando a ida e a volta precisam ser alinhadas.

Como influenciar a escolha na saída e na entrada?

A saída é decidida pelo próprio provedor, porque é o roteador dele que escolhe. A entrada é decidida pelos roteadores das outras redes, e o provedor só consegue pedir, com prepend, communities, MED ou anúncios mais específicos.

O prepend é a ferramenta mais conhecida e a menos confiável. Muitas operadoras dão LOCAL_PREF maior para rotas de clientes do que para rotas de parceiros, e isso vence qualquer número de repetições do seu ASN.

As communities da operadora costumam funcionar melhor, porque mexem no LOCAL_PREF lá dentro. O guia de configuração de communities BGP mostra como montar esse pedido.

Quando vale anunciar um prefixo mais específico?

Vale quando prepend e communities não bastam e o tráfego de entrada precisa ser dividido de verdade. O provedor anuncia o /22 inteiro pelos dois links e um /24 de dentro dele só pelo link que deve receber aquela parte.

O custo é crescer a tabela de todo mundo e precisar de ROA para cada prefixo anunciado. Sem ROA, o /24 pode ser marcado como inválido por quem valida RPKI e simplesmente sumir de parte da internet.

Erros comuns ao interpretar a escolha do BGP

Quase todo erro vem de esquecer a ordem dos critérios ou de esperar que o BGP meça desempenho. Ele compara atributos, não latência, perda ou ocupação de link.

O último item poupa tempo em qualquer diagnóstico. A rota ativa mostra o resultado; as reservas, com os seus atributos lado a lado, mostram em qual critério a disputa foi decidida.

Prepend que não muda nada: o caso mais comum

Um provedor faz três prepends no link B para trazer o tráfego de entrada para o link A, e nada muda. A operadora B dá LOCAL_PREF alto para rotas de clientes, então continua usando o anúncio direto.

A saída é pedir à operadora B, por community, que rebaixe a preferência do seu anúncio, ou anunciar um prefixo mais específico pelo link A. Se a sessão começou a cair depois da mudança, o guia de BGP caindo no provedor separa as causas.

Checklist para descobrir por que uma rota foi escolhida

Siga a mesma ordem do algoritmo, critério por critério, comparando a rota ativa com as reservas. O critério em que elas deixam de empatar é o que decidiu a escolha.

A Táquion Tech configura as políticas de LOCAL_PREF, prepend e communities de cada sessão e entrega a borda com um documento que explica a escolha de saída para cada tipo de rota.

Quando a escolha está certa e o tráfego ainda não se distribui como deveria, o problema costuma estar na divisão de prefixos entre os links, e não no algoritmo em si.

Perguntas frequentes

Thiago Manoel

Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]

Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.

A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.

Conheça a equipe da Táquion Tech