Mikrotik BGP: Como solucionar problemas de adjacências

O protocolo BGP (Border Gateway Protocol) é a espinha dorsal da internet, responsável por trocar informações de roteamento entre sistemas autônomos. No ecossistema Mikrotik, a implementação do BGP pode ser poderosa, mas também complexa. Um dos problemas mais comuns e críticos enfrentados por administradores de rede é a falha na formação de adjacências BGP. Sem uma adjacência estabelecida, não há troca de rotas, o que resulta em perda total de conectividade com os peers.

Este tutorial técnico detalha um processo sistemático de troubleshooting para diagnosticar e resolver problemas de adjacência BGP no RouterOS. O foco está na análise lógica da configuração, verificação de conectividade de camada 3 e validação dos parâmetros de sessão.

1. Verificação Inicial do Estado da Sessão

O primeiro passo em qualquer investigação de rede é observar o estado atual do serviço. No Mikrotik, a ferramenta monitor-connection fornece dados em tempo real sobre as sessões BGP ativas.

1. Acesse o terminal do seu roteador Mikrotik via SSH ou Console.
2. Execute o comando para listar todas as conexões BGP:

/routing bgp connection print where dynamic=yes

Analyze a saída. Você estará procurando pelo campo state. Os estados possíveis incluem:

• IDLE: A conexão não foi iniciada ou foi recusada.
• CONNECT: Tentando iniciar a conexão TCP (porta 179).
• ACTIVE: Falha na tentativa de conectar; tentando novamente.
• OPENSENT: Pacote OPEN enviado, aguardando resposta.
• OPENCONFIRM: Resposta OPEN recebida e validada; enviando KEEPALIVE.
• ESTABLISHED: Sessão ativa e saudável.

Se o estado for IDLE, CONNECT ou ACTIVE, o problema geralmente reside na conectividade de rede ou em firewalls que bloqueiam a porta TCP 179. Se o estado travar em OPENSENT ou OPENCONFIRM, o problema é configuracional (ASN, TTL, MD5, etc.).

2. Validação de Conectividade de Camada 3 e Porta TCP

O BGP depende do TCP para transporte. Antes de investigar parâmetros complexos, certifique-se de que o roteador consegue alcançar o peer IP e que a porta 179 está aberta.

Teste de Ping Básico

Verifique se há alcançabilidade básica:

/ping <IP_DO_PEER>

Se o ping falhar, resolva as rotas de roteamento ou problemas de interface antes de prosseguir. O BGP não pode formar adjacência se não houver rota para o próximo salto do peer.

Teste Específico da Porta 179

O ping ICMP não valida a porta TCP 179. Use o comando tool netutil ou scripts de teste TCP para verificar a conectividade específica:

/tool netutil connect-address=<IP_DO_PEER> connect-port=179 protocol=tcp

Se esta conexão falhar, verifique as regras de firewall (/ip firewall filter) tanto no roteador local quanto em dispositivos intermediários (firewalls perimetrais, WAFs ou balanceadores) que possam estar bloqueando a porta 179. Muitos provedores de nuvem exigem liberação explícita dessa porta.

3. Verificação da Configuração do Sistema Autônomo (ASN)

Um erro clássico é a incompatibilidade de ASN. Ambos os lados devem estar configurados corretamente, e o ASN deve ser único dentro do seu sistema autônomo (a menos que esteja usando 4-byte ASNs corretamente).

1. Verifique sua configuração local de BGP:

/routing bgp template print

ou, se configurado diretamente na conexão:

/routing bgp connection print

Confirme que o remote-as no seu Mikrotik corresponde ao ASN do peer, e que o local-as (definido no template ou na conexão) é o seu ASN. Uma divergência aqui fará com que a outra parte rejeite o pacote OPEN imediatamente.

4. Análise de Parâmetros de Otimização e Segurança

Muitas adjacências falham devido a configurações de segurança ou otimização mal aplicadas. Vamos analisar os três culpados mais frequentes: TTL, MD5 e Route-Map.

TTL (Time To Live) Multihop

Por padrão, o BGP define TTL como 1 para conexões eBGP diretas. Se seu peer está a múltiplos saltos de distância (multihop), ou se você está usando iBGP sobre um IGP, o TTL deve ser ajustado.

Verifique se a opção multihop=yes está ativada na conexão BGP:

/routing bgp connection set [find where name="peer-name"] multihop=yes

Se multihop estiver ativo, verifique se o TTL está configurado para um valor suficiente (geralmente 255 ou um valor específico definido no template). Se o peer esperar um TTL diferente e você não o especificar, a sessão pode cair.

Autenticação MD5

Se a configuração do peer exige autenticação TCP MD5, ela deve ser idêntica em ambos os lados. Uma diferença de um caractere na senha invalidará a conexão TCP antes mesmo do BGP começar a trocar mensagens.

1. Verifique se o campo md5-key está preenchido na configuração Mikrotik:

/routing bgp connection print where name="peer-name" show-property=md5-key

Se você não usa MD5, certifique-se de que o peer também não esteja exigindo. Em ambientes de teste ou laboratório, evite ativar MD5 desnecessariamente para simplificar o troubleshooting.

Route-Maps e Prefix-Lists (Inbound/Outbound)

Embuma route-map mal configurada geralmente permita a adjacência mas filtre as rotas, algumas implementações ou versões do RouterOS podem fechar a sessão se filtros agressivos forem aplicados durante a negociação inicial, especialmente se combinados com route-reflector ou políticas de segurança estritas.

Para isolar esse problema, remova temporariamente os filtros de entrada e saída da conexão BGP:

/routing bgp connection set [find where name="peer-name"] inbound-filter="" outbound-filter=""

Se a adjacência for estabelecida após remover os filtros, o problema está na lógica de aceitação dos prefixos ou AS-paths.

5. Log e Debugging Ativo

Quando a análise visual não revela o erro, ative logs detalhados para acompanhar o ciclo de vida da negociação BGP.

1. Habilite o logging de eventos BGP:

/logging add topics=bgp,detail file=bgp-debug.log

O arquivo de log gerado conterá mensagens como BGP: peer <IP> state change: OPENSENT -> OPENCONFIRM. Isso é crucial para identificar onde a conexão falha.

Interpretando Logs Comuns:

• "Hold timer expired": O peer não enviou KEEPALIVE dentro do tempo acordado. Verifique latência alta ou perda de pacotes.
• "Connection refused": O peer está vivo, mas o processo BGP não está escutando ou bloqueando a conexão.
• "Authentication failure": Erro de MD5 ou senha incorreta.
• "Invalid remote AS": O ASN recebido não corresponde ao esperado na configuração.

Lembre-se de desativar o logging detalhado após a resolução para evitar consumo excessivo de disco:

/logging remove [find where topics=bgp]

6. Verificação de Recursos do Sistema (CPU e Memória)

O BGP é um protocolo que consome recursos conforme o número de rotas cresce. Se o roteador Mikrotik estiver sobrecarregado, ele pode não conseguir manter a sessão BGP.

1. Verifique o uso de CPU:

/system resource monitor

Se a CPU estiver consistentemente acima de 80-90%, o roteador pode estar dropping pacotes KEEPALIVE ou não conseguindo processar as atualizações de rota. Em casos extremos, isso leva ao colapso da adjacência.

2. Verifique a memória:

/system memory monitor

O RouterOS armazena todas as rotas BGP na RAM. Se a memória estiver esgotada, o processo BGP pode falhar silenciosamente ou reiniciar, derrubando as adjacências.

7. Conflitos de Roteamento e Proximity

Em algumas topologias complexas, especialmente quando se mistura OSPF ou IS-IS com BGP, é possível que o roteador perca a rota para o peer IP do BGP devido a mudanças na tabela de roteamento.

1. Verifique se o peer IP do BGP está presente na tabela de roteamento (routing table):

/ip route print where dst-address=<IP_DO_PEER>

O caminho para o peer deve ser estável. Se a rota flutuar (devido a instabilidade no IGP subjacente, como OSPF), a sessão BGP cairá repetidamente.

Dica Pro: Next-Hop Self

Se você estiver configurando iBGP, certifique-se de que o next-hop-self está ativado se os seus peers iBGP não tiverem rota direta para o originador das rotas eBGP. Embora isso afete principalmente a instalação de rotas na tabela IP, problemas de next-hop podem causar loops ou blackholes que simulam falhas de adjacência em testes de conectividade.

/routing bgp template set [find where name="default"] next-hop-self=yes

8. Ferramentas Externas e Validação Cruzada

Às vezes, o problema não está no Mikrotik, mas na configuração do peer ou na rede entre eles.

Uso de bgpdump e RPKI

Embora o bgpdump seja主要用于 análise histórica, verificar se as rotas que você espera receber estão sendo anunciadas globalmente pode ajudar a validar se o peer está configurado corretamente. Se o peer não está anunciando nenhuma rota para o mundo, mas diz estar "Established", pode ser um problema de filtro outbound.

Conferência com o Operador do Peer

Em links transitários ou peering IXPs, a comunicação é vital. Pergunte ao peer:

• Qual ASN eles veem vindo?
• Eles estão recebendo KEEPALIVEs?
• Há mensagens de erro específicas no log deles?

Muitas vezes, o log do Mikrotik diz "Connection Refused", mas o log do peer pode indicar "Invalid AS" ou "Authentication Failed". A correlação desses logs é a chave para resolução rápida.

9. Checklist Final de Resolução

Antes de considerar o problema resolvido, execute esta verificação final:

1. Estado da Sessão: /routing bgp connection print mostra ESTABLISHED.
Compartilhar: Link copiado!
Tags: #Mikrotik #BGP #troubleshooting #adjacência #roteamento #OSPF #bgpdump #router os