Configuração de sessões com route servers: guia prático para provedores

Para que servem os route servers no IX.br

Os route servers evitam que cada participante precise fechar uma sessão com todos os outros. Eles recebem as rotas de todo mundo e repassam a cada um, como uma central de rotas.

Num ponto de troca com centenas de participantes, fechar uma sessão BGP com cada um seria inviável. Com duas sessões, o provedor troca tráfego com a maior parte dos participantes no mesmo dia em que ativa a porta.

A conexão ao IX.br para provedores inclui essa configuração e os ajustes de política. O que muda de uma localidade para outra são os endereços e o ASN dos servidores, informados na ativação.

O route server troca rotas, não tráfego

O servidor de rotas repassa os anúncios mantendo o próximo salto original, que é o endereço do participante na rede do ponto de troca. O tráfego vai direto de um roteador ao outro, sem passar pelo servidor.

Por isso a queda de um route server não derruba o tráfego na hora: as rotas já aprendidas pelo outro servidor continuam valendo. É também por isso que vale ter as duas sessões sempre ativas.

Como funciona a configuração de sessões com route servers?

Cada participante anuncia os próprios blocos aos servidores, que conferem os anúncios e os repassam aos demais. Do lado do provedor, a configuração cuida do que sai, do que entra e de como as rotas recebidas são preferidas.

A configuração de sessões com route servers exige três peças no seu roteador: um filtro de saída que deixe passar só os seus blocos, um limite de prefixos na entrada e uma política de preferência para as rotas recebidas.

Por que o ASN do route server não aparece no caminho?

A RFC 7947 define o route server como transparente: ele não coloca o próprio ASN no caminho das rotas que repassa. Para quem recebe, a rota parece ter vindo direto do participante que a anunciou.

Muitos roteadores conferem, por padrão, se o primeiro AS do caminho é o do vizinho da sessão. Com o route server, essa conferência falha e as rotas são recusadas, e é isso que o ajuste da checagem do primeiro AS resolve.

O que ter pronto antes de configurar

Os servidores de rotas filtram o que recebem, então os seus registros precisam estar certos antes da primeira sessão. Sem isso, a sessão sobe e os seus prefixos não chegam a ninguém.

Os filtros exatos variam por localidade e mudam com o tempo. [CONFIRMAR na documentação do IX.br os filtros aplicados]

IRR e ROA, os dois registros que liberam os seus prefixos

O objeto de rota no IRR diz que o seu ASN pode originar o bloco, e o ROA diz a mesma coisa assinado no RPKI. Os servidores costumam conferir os dois, e um prefixo sem registro fica de fora do repasse.

Se você anuncia blocos de clientes com ASN próprio, os registros desses clientes também precisam estar certos. Um cliente sem objeto de rota tem o prefixo filtrado, mesmo com a sua sessão funcionando bem.

Configuração de referência das duas sessões

O exemplo usa endereços de documentação e o ASN 64511 no lugar do ASN dos route servers. Troque pelos valores informados pelo ponto de troca na ativação da porta.

router bgp 64500
 no bgp enforce-first-as
 neighbor RS-PTT peer-group
 neighbor RS-PTT remote-as 64511
 neighbor RS-PTT description Route servers do ponto de troca
 neighbor 192.0.2.253 peer-group RS-PTT
 neighbor 192.0.2.254 peer-group RS-PTT
 address-family ipv4
  neighbor RS-PTT send-community both
  neighbor RS-PTT prefix-list SAIDA-PTT out
  neighbor RS-PTT route-map PTT-IN in
  neighbor RS-PTT maximum-prefix 200000 90
  neighbor 192.0.2.253 activate
  neighbor 192.0.2.254 activate
!
route-map PTT-IN permit 10
 set local-preference 200
 set community 64500:200 additive

O comando no bgp enforce-first-as é necessário porque o route server não coloca o próprio ASN no caminho. Sem ele, alguns roteadores recusam as rotas.

• send-community both: permite usar as communities do servidor para escolher para quem anunciar.
• prefix-list SAIDA-PTT: garante que só os seus blocos e os dos seus clientes saiam para o ponto de troca.
• maximum-prefix 200000 90: avisa aos 90% do limite e derruba a sessão se ele for ultrapassado. [CONFIRMAR limite adequado à localidade]
• route-map PTT-IN: dá preferência às rotas do ponto de troca e marca a origem com uma community.

Configuração de sessões com route servers passo a passo

Com os registros prontos, a ordem abaixo deixa a janela curta e reversível. Cada etapa tem um ponto de conferência antes da próxima.

1. Crie a prefix-list de saída: só os seus blocos e os dos clientes, conferidos contra o IRR.
2. Monte o route-map de entrada: local-preference e community de origem para as rotas do ponto.
3. Suba as sessões: uma com cada route server, em IPv4 e IPv6, com o limite de prefixos ligado.
4. Confira o que sai: os prefixos anunciados batem com a prefix-list e aparecem no looking glass do ponto.
5. Acompanhe o tráfego: nos dias seguintes, a porta do ponto sobe e o trânsito cai.

As mesmas sessões em IPv6

Cada route server tem também um endereço IPv6 na rede do ponto, e as sessões IPv6 são separadas das IPv4. A estrutura é a mesma, com prefix-list IPv6 de saída e limite de prefixos próprio.

Deixar o IPv6 de fora é comum e passa despercebido, porque o tráfego IPv6 dos assinantes continua saindo pelo trânsito. O custo aparece na conta do link, e não num alarme.

Route server, sessão bilateral ou trânsito: qual rota preferir?

A rota aprendida no ponto de troca costuma ser preferida à do trânsito, porque custa menos e tem menos atraso. A preferência é definida pelo local-preference, com a sessão bilateral acima do route server.

Marque as rotas com uma community de origem para controlar o que sai depois, inclusive para não repassar rotas do ponto de troca ao trânsito. Veja a configuração de communities BGP.

Quando vale fechar uma sessão bilateral

Algumas grandes redes de conteúdo não anunciam tudo pelo route server, ou anunciam com menos prefixos do que na sessão direta. Nesses casos, a bilateral traz rotas que o servidor não entrega.

Vale também quando o volume trocado com uma rede é alto e você quer controle direto da política com ela. Para o resto dos participantes, as duas sessões com os route servers já resolvem.

Erros comuns nas sessões com route servers

Os erros mais comuns fazem a sessão subir sem trocar tráfego ou vazar rotas para o ponto de troca. Os dois passam despercebidos no dia da ativação e aparecem semanas depois.

Vazamento de rotas do trânsito para o ponto de troca

Sem filtro de saída, o roteador de borda pode anunciar ao ponto de troca rotas que aprendeu do trânsito. Outros participantes passam a mandar tráfego da internet inteira pela sua porta, que lota em minutos.

A prefix-list de saída evita esse erro, e os servidores costumam barrar parte dele [CONFIRMAR filtros do IX.br contra vazamento]. Do lado da entrada, a validação de origem de rotas protege você dos vazamentos dos outros.

Checklist depois de ativar as sessões

Confira as duas sessões no dia da ativação e o tráfego nos dias seguintes. O sinal de que deu certo é a porta do ponto de troca subindo enquanto o trânsito cai.

A Táquion Tech configura as sessões com os route servers, os filtros e a política de preferência e acompanha a migração de tráfego nas semanas seguintes. Se a porta continuar vazia com o trânsito lotado, o guia de link de trânsito saturado ajuda a achar o motivo.

Perguntas frequentes sobre sessões com route servers

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