BGP caiu o que fazer: o que verificar primeiro no provedor
BGP caiu o que fazer: primeiro descubra se os assinantes ficaram sem internet ou se o tráfego já saiu pelo outro link, porque isso decide a urgência. Depois guarde o log e o estado da sessão antes de mexer em qualquer coisa e só então acione a operadora com o horário e a mensagem exata da queda.
Resumo
- A primeira pergunta não é a causa, e sim o impacto, se a base inteira parou ou se o desvio para o outro link funcionou.
- Uma rota padrão estática apontando para o link morto é o motivo mais comum de o tráfego não migrar sozinho.
- Log, estado da sessão e contadores da interface precisam ser salvos antes de reiniciar ou limpar a sessão BGP.
- Rede parada por mais de alguns minutos, sem causa à vista, é o ponto de chamar um Especialista em vez de tentar sozinho.
BGP caiu: o que fazer nos primeiros minutos
Nos primeiros minutos, meça o impacto, confira o desvio, salve as provas e só depois acione a operadora. Essa ordem evita gastar o tempo da queda procurando a causa enquanto os assinantes continuam sem navegar.
Uma sessão que estava estabelecida há semanas e cai de repente é um caso diferente de uma sessão nova que nunca subiu. Aqui a borda funcionava, a configuração não mudou sozinha e o que aconteceu tem rastro: no log do roteador, nos contadores da interface e, muitas vezes, do lado da operadora.
O tempo pesa mais do que a causa nesse momento. Se a base inteira parou, o caminho mais curto é o suporte emergencial para provedor, com um Especialista entrando na borda enquanto você cuida do atendimento. Se só um dos links caiu e o outro segurou o tráfego, há tempo para seguir o roteiro abaixo com calma.
1 · Impacto
Medir quem ficou sem internet
Monitoramento, chamados entrando e um teste de navegação de dentro da rede dizem se a base parou.
2 · Desvio
Conferir se o tráfego mudou de link
Com dois links, veja se a rota padrão e o tráfego de saída já estão no caminho que sobrou.
3 · Provas
Guardar log e estado da sessão
Último motivo de encerramento, estado atual, contadores da interface e cópia da configuração.
4 · Operadora
Abrir chamado com os dados
Designação do circuito, hora exata, mensagem do log e o que já foi testado do seu lado.
Se o passo 2 mostrar que o tráfego já desviou, a urgência cai e o resto pode seguir sem pressa. Se mostrar que não desviou, corrija o desvio antes de investigar a causa.
Caiu e ficou fora ou está subindo e caindo?
Olhe há quanto tempo a sessão está no estado atual e quantas vezes ela mudou na última hora. Uma queda única que não volta pede este roteiro; uma sessão que sobe e cai em ciclos é instabilidade, com outras causas.
Para a oscilação, as causas e as mensagens de log estão no guia de BGP caindo no provedor. Se a sessão é nova e nunca chegou a estabelecer, o caso é o de sessão BGP que não sobe, que começa pela configuração e não pelo impacto. Se além da borda caíram OLTs e concentrador, siga a triagem de quando a rede do provedor caiu.
Os assinantes ficaram sem internet ou o tráfego desviou?
Depende de quantos links o provedor tem e de como a rota padrão foi montada. A tabela mostra os três cenários mais comuns e o que fazer primeiro em cada um.
| Cenário | O que o assinante sente | Primeira ação |
|---|---|---|
| Dois links e o tráfego desviou | Quase nada, ou lentidão no pico se o link que sobrou é menor | Conferir a ocupação do link que ficou e abrir chamado sem pressa |
| Dois links e o tráfego não desviou | Base sem navegar, embora o outro link esteja no ar | Corrigir a rota padrão ou a política de saída antes de qualquer outra coisa |
| Um único link de trânsito | Base inteira sem internet | Testar o caminho físico até a operadora e acionar a operadora na hora |
| Só a sessão com o IX.br caiu | Lentidão para alguns destinos, como vídeo e jogos | Confirmar que o trânsito absorveu o tráfego e avisar o ponto de troca |
O teste que separa os cenários leva um minuto: de uma máquina dentro da rede, navegue e faça um traceroute para um destino externo. Se o caminho sai pelo link que sobrou, o desvio funcionou; se para na sua borda, o tráfego está sendo mandado para um vizinho que não existe mais.
Por que o tráfego não foi para o outro link
Na maioria das vezes, a culpa é de uma rota padrão estática apontando para o IP da operadora que caiu. Quando o problema está depois da interface, ela continua no ar, a rota estática continua ativa e todo o tráfego de saída vai para um caminho morto.
- Rota padrão estática: sem verificação do próximo salto, ela não sai da tabela quando a sessão cai.
- Anúncio por um link só: se os seus prefixos eram anunciados só na operadora que caiu, o tráfego de volta não encontra você.
- Link reserva menor: o desvio funcionou, mas o link que sobrou satura no pico e parece que a rede caiu.
- Filtro de saída esquecido: uma política montada para um link só barra o anúncio no outro vizinho.
O terceiro caso é comum em provedor que contratou o segundo link como reserva. O guia de link de trânsito saturado mostra como confirmar que o problema virou capacidade, e não mais a queda.
Na prática: queda às oito da noite com dois links no ar
Um provedor com duas operadoras perde a sessão com a principal no horário de pico. O monitoramento mostra a outra sessão estabelecida, mas o atendimento recebe dezenas de chamados de assinantes sem navegar.
- Impacto: o traceroute de dentro da rede para na borda, e não sai por nenhum dos dois links.
- Desvio: a tabela mostra a rota padrão estática ainda apontando para o IP da operadora principal, com a interface no ar.
- Contenção: o técnico desativa essa rota com o backup salvo, e o tráfego sai pela segunda operadora.
- Causa: com a base navegando, o log mostra que a sessão caiu por fim do tempo de espera, e a operadora confirma rompimento no transporte.
A rede voltou antes de a operadora consertar a fibra, porque o problema que tirava os assinantes do ar era a rota estática, e não a sessão em si.
BGP caiu: o que verificar primeiro na borda
Verifique o motivo do encerramento no log, o estado atual da sessão, a interface e o caminho até o vizinho, nessa ordem. Salve cada saída num arquivo antes de alterar qualquer configuração.
- Motivo da queda: a última mensagem de encerramento daquele vizinho, com data, hora e texto exato.
- Estado atual: se a sessão está tentando conectar, parada por limite ou estabelecida sem receber rotas.
- Interface: status, erros, descartes e, em fibra, o nível óptico do transceptor que liga à operadora.
- Caminho: ping até o IP do vizinho com pacote pequeno e com pacote grande sem fragmentar.
- Alteração recente: qualquer mudança na borda nas últimas horas, comparada com o último backup.
# MikroTik RouterOS 7
/routing/bgp/session/print detail
/log/print where topics~"bgp"
/ip/route/print where dst-address=0.0.0.0/0
/interface/ethernet/monitor sfp-sfpplus1 once
/ping 203.0.113.1 count=20 size=1472 do-not-fragment
/export file=borda-depois-da-queda
# Huawei VRP
display bgp peer
display bgp peer 203.0.113.1 log-info
display ip routing-table 0.0.0.0
display interface brief
# Cisco IOS
show ip bgp summary
show ip bgp neighbors 203.0.113.1 | include Last reset
show ip route 0.0.0.0A cópia da configuração no fim da lista não é burocracia. Se alguém mexer na borda durante a queda, é ela que permite voltar ao ponto em que tudo funcionava e comparar o que mudou.
O que o estado da sessão conta depois da queda
Numa sessão que já funcionava, o estado atual aponta o tipo de problema mais rápido do que qualquer teste. A máquina de estados do BGP está descrita na RFC 4271, e cada fabricante mostra os nomes do seu jeito.
- Tentando conectar: a conexão TCP com o vizinho não fecha, o que aponta para link, transporte ou IP.
- Parada sem tentar: em geral, a sessão foi desligada por um limite de prefixos e espera intervenção manual.
- Estabelecida sem rotas: a sessão subiu, mas a operadora não está mandando prefixos, o que pede chamado com ela.
O código de encerramento também ajuda. A RFC 4486 lista os motivos de encerramento administrativo, como limite de prefixos atingido e vizinho desconfigurado, que aparecem no log com nomes parecidos.
Como acionar a operadora sem perder tempo
Ligue com os dados que a operadora vai pedir já separados, porque cada pergunta sem resposta atrasa o chamado.
Tenha à mão, antes de ligar, estas cinco informações:
- Designação do circuito: o código do link que está no contrato ou na fatura da operadora.
- Hora exata da queda: com fuso, tirada do log do roteador, e não do primeiro chamado de assinante.
- Mensagem de encerramento: o texto do log, copiado sem resumir.
- Testes feitos: interface no ar ou não, nível óptico, ping até o IP do vizinho com o resultado.
- Mudanças do seu lado: se houve alteração na borda nas últimas horas, diga logo, para não perder tempo.
Com esses dados, o chamado já chega ao nível certo da operadora. Se ela responder que do lado dela está tudo normal e a interface do seu lado está no ar, peça que confirme se a sessão aparece para ela e se o seu IP de vizinho ainda está configurado.
A operadora diz que está tudo normal e a base continua parada?
No suporte emergencial, um Especialista entra na borda com acesso registrado, separa o que é seu do que é da operadora e trabalha até o tráfego voltar.
Erros comuns quando o BGP caiu
Os erros mais caros são os que apagam a prova da causa ou que tornam a próxima subida mais difícil. Quase todos nascem da pressa de fazer alguma coisa enquanto o telefone toca.
Evite enquanto a sessão estiver fora
- Reiniciar a borda primeiro: o log em memória some, e a causa vira palpite.
- Limpar todas as sessões: derrubar também a sessão que está segurando o tráfego deixa a base inteira sem saída.
- Tirar o limite de prefixos para subir: a sessão volta, mas uma tabela inesperada pode encher a memória da borda.
- Insistir na subida em sequência: derrubar e subir várias vezes pode fazer outras redes penalizarem as suas rotas.
- Mexer sem backup: qualquer ajuste feito sem cópia da configuração atual não tem caminho de volta.
A penalidade do quarto item tem nome: amortecimento de rotas, descrito na RFC 2439. Redes que aplicam essa regra deixam de usar por um tempo os prefixos que mudam demais, e o provedor fica com a sessão no ar e parte da internet sem alcançar os seus assinantes.
Quando vale chamar um Especialista?
Vale chamar quando a base está parada e você não tem uma causa provável em poucos minutos, ou quando a correção envolve mexer em política de roteamento no horário de pico. Nesses casos, o tempo gasto tentando sozinho custa mais do que a ajuda.
Marque o que vale para a queda de agora
- O tráfego não desviou e ninguém da equipe sabe onde fica a rota padrão.
- A operadora diz que está tudo normal e a interface do seu lado está no ar.
- A sessão parou por limite de prefixos e ninguém sabe se o limite está certo.
- Só uma pessoa sabe acessar a borda, e ela não atende.
- A correção exige mudar filtros ou anúncios com a base inteira navegando.
Uma marca já justifica uma segunda opinião. Duas ou mais, com a base parada, pedem um Especialista na borda agora.
A Táquion Tech atende provedores de todo o Brasil por acesso remoto registrado e trabalha junto com o técnico da casa durante a queda. Tempo de primeira resposta: [PREENCHER tempo de primeira resposta da emergência].
O que conferir depois que a sessão voltar
A sessão estabelecida não garante que a rede voltou ao normal. Confira os pontos abaixo antes de encerrar o incidente.
- Prefixos recebidos: a quantidade é parecida com a de antes da queda.
- Prefixos anunciados: os seus blocos aparecem no looking glass da operadora ou do IX.br.
- Distribuição do tráfego: cada link voltou a carregar a parte que carregava antes.
- Rota padrão: a estática problemática foi corrigida, e não só desativada às pressas.
Registre a linha do tempo enquanto ela está fresca: hora da queda, hora do desvio, hora da volta e o que foi feito. O relatório pós-incidente organiza esses dados e, com o monitoramento de BGP, a próxima queda é vista antes do primeiro chamado.
Perguntas frequentes
A sessão BGP voltou sozinha, preciso investigar?
Precisa, porque a causa que derrubou uma vez pode derrubar de novo no pior horário. Guarde o log da queda e peça à operadora o registro do lado dela para comparar os horários.
Posso reiniciar o roteador de borda quando o BGP cai?
Só depois de salvar o log, o estado das sessões e a configuração. Reiniciar antes apaga a prova da causa e derruba também as sessões que ainda estavam segurando o tráfego.
Por que a sessão caiu e a internet continuou funcionando?
Porque o tráfego desviou para outro link ou para o ponto de troca, como deveria. Mesmo assim, confira se o link que sobrou aguenta o horário de pico sozinho.
Como saber se a culpa é da operadora ou minha?
Se a interface caiu ou o nível óptico sumiu, o problema está no caminho físico, que pode ser de qualquer lado. Se a interface está no ar e o vizinho não responde ao ping, a operadora precisa conferir o lado dela.
O limite de prefixos pode derrubar a sessão sozinho?
Pode. Quando a operadora manda mais rotas do que o limite configurado, o roteador encerra a sessão e, em muitos equipamentos, só volta com intervenção manual.
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.
Fontes
- RFC 4271 (A Border Gateway Protocol 4): máquina de estados da sessão BGP e tempo de espera entre mensagens
- RFC 4486 (Subcodes for BGP Cease Notification Message): motivos de encerramento administrativo, como limite de prefixos atingido
- RFC 2439 (BGP Route Flap Damping): penalidade aplicada a prefixos que mudam muitas vezes em pouco tempo
