O Border Gateway Protocol (BGP) é a espinha dorsal da internet, mas sua implementação em redes de médio e grande porte pode se tornar complexa rapidamente. A principal dor de cabeça dos administradores de rede ao escalar o BGP é a necessidade de uma malha full-mesh (conexão total entre todos os roteadores), o que gera um crescimento exponencial das sessões OSPF/BGP, consumo excessivo de memória e CPU, e complexidade na manutenção. Para resolver isso, utilizamos o conceito de Route Reflectors (RR). Neste tutorial técnico, vamos configurar um Route Reflector utilizando Mikrotik RouterOS em conjunto com o BMR (BGP Mesh Reflector), simplificando a arquitetura da sua infraestrutura.
O que é um Route Reflector e por que usar no Mikrotik?
Em uma topologia BGP padrão, cada roteador iBGP precisa ter uma sessão direta com todos os outros roteadores iBGP na mesma área de confiança (confederation ou AS único). Se você tem 10 roteadores, terá 45 sessões BGP. Isso consome recursos valiosos do routerboard. O Route Reflector quebra essa regra tradicional. Ele permite que um roteador central (o RR) reflita as rotas aprendidas de um cliente para outros clientes. Assim, você reduz a complexidade de malha para uma topologia estrela, onde todos os roteadores conectam-se apenas ao refletor.
No ecossistema Mikrotik, especialmente com o uso do BMR (BGP Mesh Reflector), essa configuração é otimizada para garantir estabilidade e previsibilidade. O BMR não é apenas um recurso, mas uma abordagem de design que prioriza a separação clara entre roteadores de borda e roteadores core de refletor.
Pré-requisitos e Topologia Lógica
Antes de aplicar os comandos, definamos nossa topologia simplificada para fins didáticos:
- Roteador A (Cliente 1): Conectado à internet via eBGP e atua como cliente do RR.
- Roteador B (Cliente 2): Outro provedor de borda ou datacenter, também cliente do RR.
- Roteador C (Route Reflector): O roteador central que irá refletir as rotas entre A e B. Este será nosso foco principal na configuração do BMR.
Todos os roteadores devem estar no mesmo autonomous system (AS) para fins de iBGP neste exemplo, ou configurados como confederação se houver múltiplos ASs. Vamos assumir um único AS 65001 para simplificar.
Passo 1: Preparação do Sistema e Políticas Básicas
Antes de ativar o BGP, certifique-se de que o roteamento IP básico está funcionando. O Mikrotik deve conseguir alcançar os peers via interface física ou loopback. Utilize endereços loopback para as sessões BGP, pois são mais estáveis do que IPs de interface física.
No Roteador C (o Route Reflector), defina uma interface loopback:
/ip address add address=192.168.10.1/32 interface=loopbackGaranta que haja conectividade de roteamento IP (ICMP) entre os três roteadores. O BGP não verifica a validade da rota antes de estabelecer a sessão TCP, mas se o caminho IP estiver quebrado, a sessão não sobe.
Passo 2: Configurando o BGP Básico no Route Reflector
Agora vamos entrar na configuração do protocolo BGP. No RouterOS, a configuração do BGP é feita em duas partes principais: a definição do sistema e a criação das peers (vizinhos).
Definindo o Sistema BGP
No roteador que atuará como Route Reflector, defina o AS number e habilitamos o comportamento de refletor. Note que não usamos mais o comando antigo route-reflector isoladamente em versões recentes; a lógica é integrada ao peer ou via scripts BMR, mas para clareza didática, configuraremos os peers como clientes.
/routing bgp template set [find] client-to-client-routing=yesO parâmetro client-to-client-routing=yes é crucial. Ele instrui o roteador a permitir que rotas aprendidas de um cliente sejam refletidas para outros clientes. Por padrão, em iBGP, as rotas aprendidas de um peer não são repassadas a outro peer (regra do split horizon). O RR inverte essa lógica.
Criando os Peers Clientes
Agora, conectamos o Roteador A e o Roteador B ao nosso Route Reflector. Definimos cada um como client=yes.
/routing bgp session add name=peer-a address-family=ipv4 remote-as=65001 peer-type=external client=yes template=default connection-template=default connect-to=192.168.10.2
/routing bgp session add name=peer-b address-family=ipv4 remote-as=65001 peer-type=external client=yes template=default connection-template=default connect-to=192.168.10.3Atenção: No exemplo acima, assumimos que 192.168.10.2 é o loopback do Roteador A e 192.168.10.3 é o do B. O parâmetro peer-type=external aqui é usado para forçar a sessão iBGP entre roteadores distintos na mesma AS, ou ajuste conforme sua necessidade de eBGP/iBGP real. Se for estritamente iBGP, use peer-type=internal.
Passo 3: Implementando o BMR (BGP Mesh Reflector)
O BMR no Mikrotik é uma feature que automatiza e simplifica a gestão dessa malha. Em vez de gerenciar sessões manualmente, o BMR permite definir um "mesh" onde alguns roteadores são reflexores e outros são apenas clientes finais.
No RouterOS moderno, isso é frequentemente gerenciado através de routing bgp template avançados ou scripts de automação. No entanto, a configuração manual clássica que garante o funcionamento do Route Reflector segue a lógica de atribuição de Cluster ID.
Atribuindo o Cluster ID
Para evitar loops em topologias com múltiplos Route Reflectors, é obrigatório definir um cluster-id. Este ID identifica o refletor dentro do cluster. Todos os roteadores no mesmo cluster devem ter o mesmo Cluster ID.
/routing bgp session set [find name=peer-a] cluster-id=10.0.0.1
/routing bgp session set [find name=peer-b] cluster-id=10.0.0.1Se você estiver utilizando a feature BMR via script ou template específico da versão, certifique-se de que o template base tenha route-reflector=yes.
/routing bgp template set [find default] route-reflector=yes client-to-client-routing=yes cluster-id=10.0.0.1Ao aplicar este template aos peers configurados como clientes, o Mikrotik saberá automaticamente que ele é um refletor e que deve espelhar as rotas.
Passo 4: Configurando os Clientes (Roteadores A e B)
A configuração nos roteadores cliente é mais simples. Eles não precisam saber que estão falando com um Route Reflector; eles apenas estabelecem a sessão iBGP normal, mas devem estar cientes de que podem receber rotas refletidas.
No Roteador A:
/routing bgp session add name=rr-peer address-family=ipv4 remote-as=65001 peer-type=internal client=no template=default connect-to=192.168.10.1Note que client=no. Isso é importante para evitar loops caso haja múltiplos refletores, mas em uma topologia simples de estrela, o cliente apenas recebe as rotas.
Passo 5: Filtros e Controle de Roteamento
O BGP sem filtros é perigoso. Você deve garantir que seus clientes não injetem rotas malucas na internet via seu refletor. Utilize routing filter ou listas de acesso.
/routing bgp session set [find name=peer-a] import-filter="if (origin == 'igp') drop; else accept"
/routing bgp session set [find name=peer-a] export-filter="if (destination ~ 0.0.0.0/0) drop; else accept"O exemplo acima é ilustrativo. Na prática, use listas de roteamento (/routing filter) para permitir apenas prefixes específicos ou bloquee o prefixo default se não quiser propagá-lo.
Passo 6: Verificação e Troubleshooting
Após aplicar as configurações, verifique o estado das sessões. No Mikrotik, use os comandos abaixo para diagnosticar problemas comuns.
Verificando Sessões BGP
/routing bgp session print where status=establishedSe as sessões não subirem, verifique:
- Conectividade IP (ping entre loopbacks).
- Máscaras de rede (/32 para hosts).
- TTL: Por padrão, o BGP usa TTL=1. Se os roteadores não forem diretamente conectados fisicamente, você deve aumentar o TTL.
/routing bgp session set [find name=peer-a] ttl=255Verificando Reflexão de Rotas
Para ver se as rotas estão sendo refletidas corretamente, consulte a tabela de roteamento BGP:
/routing bgp route print where source=bgpObserve o campo reflected. Se estiver marcado como "yes" (ou visível na saída detalhada), significa que o Route Reflector está funcionando e espelhando as rotas de um cliente para outro.
Dicas Avançadas para Infraestrutura Estável
Para profissionais de TI que buscam alta disponibilidade, considere as seguintes práticas ao usar Mikrotik como Route Reflector:
- Multipath: Habilite o carregamento de carga se houver múltiplos caminhos.
- Graceful Restart: Ative
graceful-restart=yesno template BGP para evitar flapping de rotas durante reinicializações do roteador. - Keepalive Timers: Ajuste os timers de keepalive e hold-time para detectar falhas mais rapidamente em links instáveis, mas evite valores muito agressivos que causem oscilação.
/routing bgp template set [find default] graceful-restart=yes hold-time=30s keepalive-time=10sConclusão
A implementação de Route Reflectors com Mikrotik simplifica drasticamente a escalabilidade de redes BGP. Ao substituir a malha full-mesh por uma topologia estrela controlada pelo BMR e templates adequados, você reduz o consumo de recursos do routerboard e facilita o gerenciamento da sua infraestrutura. Lembre-se sempre de testar em ambiente de laboratório antes de aplicar em produção e de utilizar filtros rigorosos para manter a segurança da sua rede.
Com esta configuração, sua rede está pronta para escalar horizontalmente, adicionando novos clientes ao Route Reflector sem a necessidade de criar novas sessões entre todos os nós existentes. Isso é essencial para provedores de internet, datacenters e corporações com múltiplas filiais conectadas via BGP.