Implantação de route reflector: guia prático para provedores

O que o route reflector muda no iBGP

O route reflector quebra, de forma controlada, a regra que obriga todo roteador do iBGP a falar com todos os outros. Ele recebe as rotas dos clientes e as repassa aos demais, e cada roteador passa a ter só duas sessões.

No BGP interno, uma rota aprendida de um vizinho iBGP não é repassada a outro vizinho iBGP. Essa regra evita loop, mas obriga a malha completa, em que todos os roteadores do mesmo ASN precisam de sessão direta entre si.

O refletor é a exceção prevista na RFC 4456: ele pode repassar a um cliente a rota que aprendeu de outro. Com dois refletores, a rede cresce sem reconfigurar todos os roteadores a cada equipamento novo, e esse é o desenho padrão na configuração de BGP para provedores com mais de quatro ou cinco roteadores.

Por que a malha completa deixa de escalar?

Dentro do mesmo ASN, a malha completa exige n × (n − 1) ÷ 2 sessões: com 5 roteadores são 10, com 10 são 45 e com 20 já são 190. Cada sessão é uma configuração a manter, uma senha a trocar e um ponto a conferir em toda mudança.

O custo real aparece quando entra um POP novo. Na malha, alguém precisa abrir janela em todos os roteadores para criar a sessão com o recém-chegado, e basta esquecer um para aquele roteador ficar sem parte das rotas.

Como funciona a implantação de route reflector?

As bordas aprendem rotas de fora e mandam ao refletor, que escolhe o caminho preferido e o repassa a todos os clientes. O tráfego não passa pelo refletor, porque o próximo salto continua sendo a borda que aprendeu a rota.

Nesse desenho, a borda continua sendo o lugar das políticas de entrada e saída. Filtros de prefixo, communities e a validação de origem pelo RPKI ficam nas bordas, onde a rota entra, e o refletor só distribui o que já foi aceito.

Originator-id e cluster-list: como o refletor evita loop

Ao refletir uma rota, o refletor grava nela o originator-id, que identifica o roteador de origem, e acrescenta o próprio cluster-id à cluster-list. Um roteador que recebe de volta uma rota com o próprio identificador a descarta.

É por isso que o cluster-id pede planejamento: dois refletores com o mesmo valor descartam as rotas que um reflete para o outro. Isso pode ser desejado, num par redundante que atende os mesmos clientes, ou um problema, se cada um atende um grupo diferente.

Decisões de desenho antes de configurar

As decisões principais são quantos refletores usar, onde eles ficam e se encaminham tráfego ou só trocam rotas. Errar aqui costuma aparecer só no dia em que um equipamento cai.

• Dois refletores: um só vira ponto único de falha do controle da rede.
• Fora do caminho do tráfego: refletor que só troca rotas pode ser um servidor ou roteador virtual. [CONFIRMAR software indicado]
• Cluster-id: os dois refletores no mesmo cluster ou em clusters diferentes, conforme a política.
• Add-path: envia mais de um caminho por prefixo, evitando que caminhos reserva fiquem escondidos.
• Bordas como clientes: as bordas continuam aplicando next-hop-self.

Os dois refletores devem ficar em lugares diferentes, de preferência em POPs distintos e com energia separada. Dois refletores no mesmo rack caem juntos na primeira falha de energia e levam embora a troca de rotas da rede.

Refletor dedicado ou borda acumulando a função?

Usar a própria borda como refletor parece econômico, mas mistura duas cargas no mesmo equipamento. A tabela mostra quando cada opção faz sentido numa rede de provedor regional.

Configuração de referência do refletor

O exemplo mostra o lado do refletor, com um peer-group para os clientes. Nos clientes, basta criar sessões iBGP com os dois refletores a partir da loopback.

router bgp 64500
 bgp router-id 10.255.0.101
 bgp cluster-id 10.255.0.100
 neighbor RR-CLIENTES peer-group
 neighbor RR-CLIENTES remote-as 64500
 neighbor RR-CLIENTES update-source Loopback0
 neighbor 10.255.0.1 peer-group RR-CLIENTES
 neighbor 10.255.0.2 peer-group RR-CLIENTES
 neighbor 10.255.0.3 peer-group RR-CLIENTES
 address-family ipv4
  neighbor RR-CLIENTES route-reflector-client
  neighbor RR-CLIENTES send-community both
  neighbor 10.255.0.1 activate
  neighbor 10.255.0.2 activate
  neighbor 10.255.0.3 activate

O comando route-reflector-client é o que transforma a sessão comum em sessão de cliente. O send-community both garante que as communities marcadas nas bordas cheguem aos outros roteadores, o que importa para quem usa a configuração de communities BGP na engenharia de tráfego.

O que muda no lado dos clientes

Cada cliente ganha duas sessões, uma com cada refletor, usando a loopback como origem. As bordas mantêm o next-hop-self nessas sessões, para que o próximo salto das rotas externas seja um endereço que a rede interna alcança.

O segundo refletor recebe a mesma configuração, com outro router-id. O cluster-id pode ser igual ou diferente, conforme a decisão tomada no desenho.

Implantação de route reflector passo a passo, sem parar a rede

A migração aproveita que a malha completa e os refletores podem conviver por um tempo. Primeiro as sessões novas sobem ao lado das antigas, e só depois a malha sai, um roteador por vez.

1. Suba os refletores: ligados ao protocolo interno, com loopbacks alcançáveis de todos os roteadores.
2. Crie as sessões com os refletores: em todos os roteadores, mantendo a malha antiga no ar.
3. Confira as rotas: cada roteador deve receber dos refletores as mesmas rotas da malha.
4. Retire a malha: remova as sessões antigas, um roteador por vez, em janela de mudança.
5. Teste a falha: desligue um refletor de cada vez e veja se o tráfego segue igual.

A implantação de route reflector exige um protocolo interno estável, então revise antes a configuração de iBGP, porque loopbacks sem rota derrubam as sessões novas. Se a borda usa gateway compartilhado, veja a configuração de VRRP; se o tráfego volta por um caminho diferente depois da troca, veja a análise de rotas assimétricas.

Plano de volta em cada etapa

Enquanto a malha antiga existir, voltar atrás é só remover as sessões com os refletores. Por isso a retirada da malha é a última etapa e acontece aos poucos, com conferência entre um roteador e outro.

Guarde a configuração de cada roteador antes de mexer e anote quantas rotas ele recebia pela malha. Se o número cair depois da troca, a sessão antiga volta e a diferença é investigada com calma.

Na prática: três bordas, dois POPs e um roteador de agregação

Numa rede com três bordas e um roteador de agregação, a malha tem seis sessões e ainda é administrável. O problema começa quando o provedor planeja um terceiro POP com mais duas bordas, e a malha salta para quinze.

Com dois refletores virtuais, um em cada POP principal, cada um dos quatro roteadores atuais ganha duas sessões, e as bordas novas já nascem com só duas. A janela de retirada da malha leva um roteador por noite, e a rede nunca fica sem caminho conferido.

Erros comuns na implantação de route reflector

Os problemas aparecem como caminho reserva que não funciona, rota em loop ou rede inteira sem rotas quando um equipamento cai. Quase todos nascem de pular uma conferência na migração.

O caminho reserva que some sem add-path

Sem add-path, o refletor envia aos clientes só o caminho que ele considera melhor. Se as duas bordas aprendem o mesmo prefixo, os clientes conhecem só uma saída e, quando ela cai, esperam o refletor recalcular para descobrir a outra.

Na prática, isso vira alguns segundos ou minutos de perda numa falha de link que deveria ser imperceptível [CONFIRMAR tempo típico de convergência]. O add-path precisa estar ligado no refletor e nos clientes.

Checklist de validação da implantação

Confira as sessões, compare as rotas com as da malha antiga e simule a queda de um refletor. Só depois disso a implantação pode ser dada como concluída.

A Táquion Tech implanta os route reflectors por etapas, com a malha antiga ativa até as rotas conferirem e um plano de volta escrito para cada janela de mudança.

Perguntas frequentes sobre route reflector

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