BGP multihoming: redundância de trânsito com 2+ upstreams

Multihoming é conectar seu ASN a dois ou mais provedores de trânsito ao mesmo tempo, anunciando o mesmo bloco IP por todos eles. Se um upstream cair — corte de fibra, manutenção, incidente — o BGP reconverge e o tráfego passa a fluir pelo caminho remanescente, sem intervenção manual. É o mecanismo básico de alta disponibilidade de qualquer provedor sério.

Além de redundância, multihoming dá poder de engenharia de tráfego: você escolhe por qual upstream sair para cada destino, negocia melhor capacidade e não fica refém de uma única política comercial ou técnica. O pré-requisito é ter ASN e bloco próprios, porque só assim você anuncia rotas independentes.

A saída é a parte mais fácil de controlar porque a decisão é sua. Recebendo full-table dos upstreams, o roteador escolhe o melhor caminho por prefixo usando os atributos do BGP. O atributo local-preference é o mais usado: defina preferência maior no upstream preferido e ele será a saída padrão, com o outro assumindo se o primeiro sumir.

Se o seu equipamento não aguenta duas ou três tabelas completas de memória, é possível pedir default-route mais rotas parciais (por exemplo, apenas as rotas dos clientes diretos do upstream). Isso reduz consumo de RIB/FIB, mas abre mão de parte do controle fino de saída — um trade-off legítimo para roteadores de menor porte.

A entrada é mais difícil porque quem decide é a rede remota. As ferramentas clássicas são AS-path prepend (repetir seu ASN no anúncio para tornar um caminho artificialmente mais longo e menos atraente) e as BGP communities publicadas pelos upstreams, que permitem sinalizar local-preference ou prepend dentro da rede deles.

Outra técnica é a desagregação seletiva: anunciar prefixos mais específicos por um upstream para atrair aquele tráfego, mantendo o agregado nos demais. Use com parcimônia, pois prefixos muito específicos poluem a tabela global e podem ser filtrados. O balanceamento de entrada é sempre aproximado — trate como ajuste iterativo, não como chave liga-desliga.

Filtre rigorosamente o que você anuncia e o que aceita. Para fora, envie apenas seus prefixos e os de clientes com route object; jamais repasse full-table de um upstream para outro, sob risco de virar trânsito acidental e derrubar sua rede. Para dentro, aplique prefix-list e max-prefix para se proteger de vazamentos do vizinho.

Adote RPKI com ROV para rejeitar rotas de origem inválida e mantenha ROAs corretos para seus próprios prefixos. Combine com BFD para detecção rápida de falha de enlace, acelerando a reconvergência muito além dos timers padrão do BGP.