Monitorar sessão BGP no Zabbix: explicação para provedores
Monitorar sessão BGP no Zabbix é ler por SNMP, em cada roteador de borda, o estado de cada vizinho e o número de vezes que a sessão subiu, e disparar um alerta quando o estado deixa de ser Established ou quando a sessão oscila. Com a descoberta automática, cada vizinho novo entra sozinho no monitoramento, sem cadastro manual.
Resumo
- O BGP4-MIB devolve o estado da sessão como um número de 1 a 6, e só o 6 significa Established.
- O contador de transições para Established revela a sessão que cai e volta antes de alguém ver o gráfico.
- O MIB padrão cobre vizinhos IPv4; sessões IPv6 e prefixos recebidos dependem do MIB de cada fabricante.
- Sem monitoramento da sessão, a queda de um trânsito aparece só como tráfego mudando de link.
O que é monitorar sessão BGP no Zabbix
É usar o Zabbix para perguntar ao roteador de borda, a cada minuto, como está cada sessão BGP com operadoras, IX.br e caches. A resposta vira histórico e alimenta alertas de queda e de oscilação.
Muitos provedores já têm o Zabbix coletando tráfego das interfaces, mas não as sessões. O resultado é conhecido: o link com uma operadora continua de pé, a sessão por cima dele cai, e o único sinal é o tráfego migrando para a outra saída no gráfico.
O Zabbix cuida da visão de dentro da borda. A visão de fora, que mostra se os seus blocos continuam visíveis na internet, vem de outras ferramentas, e o monitoramento de BGP para provedores junta as duas num só conjunto de alertas.
O que a equipe passa a ver
Com a coleta das sessões, a equipe vê o estado de cada vizinho, há quanto tempo ele está de pé e quantas vezes reiniciou. Isso transforma uma reclamação vaga de lentidão numa linha do tempo com hora exata.
- Estado atual: Established ou um dos estados de falha, por vizinho.
- Tempo de sessão: há quantos segundos a sessão está de pé desde a última subida.
- Transições: quantas vezes a sessão chegou a Established, o que denuncia oscilação.
- Mensagens trocadas: contadores de updates recebidos e enviados, úteis para ver vizinho mudo.
Como o Zabbix enxerga uma sessão BGP
O Zabbix lê a tabela de vizinhos do roteador pelo BGP4-MIB, padronizado na RFC 4273, em que cada linha é um vizinho identificado pelo endereço IP. Cada coluna da tabela vira um item, e cada item pode ter um trigger.
Roteador
Tabela de vizinhos BGP
O roteador mantém, para cada vizinho, o estado, o tempo de sessão e os contadores de mensagens.
Descoberta
Uma regra acha os vizinhos
A regra de descoberta percorre a tabela e cria itens para cada endereço de vizinho encontrado.
Itens
Estado e transições
A cada minuto, o Zabbix lê o estado e o contador de transições de cada vizinho.
Trigger
Regra de problema
Estado diferente de 6 ou duas subidas na mesma hora abrem um problema com a gravidade combinada.
Ação
Aviso a quem trata
A ação manda a mensagem ao responsável, com o nome do vizinho e o roteiro.
O roteador não precisa de nenhuma mudança de configuração além do acesso SNMP de leitura liberado para o servidor do Zabbix.
Os seis estados e o número que o SNMP devolve
O SNMP não devolve o nome do estado, mas um número. Mapear esse número num valor legível, no próprio Zabbix, é o que faz o alerta dizer Active em vez de 3.
| Valor | Estado | O que costuma indicar |
|---|---|---|
| 1 | Idle | Sessão desativada, bloqueada por filtro ou à espera depois de um erro |
| 2 | Connect | Tentando abrir a conexão TCP com o vizinho |
| 3 | Active | A conexão não completa: endereço, rota ou porta 179 bloqueada |
| 4 | OpenSent | Mensagem OPEN enviada, aguardando a do vizinho |
| 5 | OpenConfirm | OPEN trocado, faltando o primeiro keepalive |
| 6 | Established | Sessão de pé e trocando rotas |
Uma sessão parada em 3 por muito tempo tem causa diferente de uma que vai a 6 e volta a 1 a cada poucos minutos. O guia sobre sessão BGP que não sobe detalha o que cada estado parado revela.
Exemplo: descoberta e trigger de sessão BGP no Zabbix
O exemplo abaixo cria uma regra de descoberta pelo BGP4-MIB, dois itens por vizinho e três triggers. Os OIDs são do MIB padrão e os endereços são de documentação.
# 1. Testar no servidor do Zabbix se o roteador expõe o BGP4-MIB
snmpwalk -v3 -l authPriv -u noc-leitura -a SHA -A 'TROCAR-auth' \
-x AES -X 'TROCAR-priv' 198.51.100.1 1.3.6.1.2.1.15.3.1.2
# resposta esperada, um vizinho por linha (6 = Established):
# ...15.3.1.2.203.0.113.1 = INTEGER: 6
# 2. Regra de descoberta (tipo SNMP agent)
# Chave: bgp.peer.discovery
# OID: discovery[{#PEERSTATE},1.3.6.1.2.1.15.3.1.2,{#PEERAS},1.3.6.1.2.1.15.3.1.9]
# Cada {#SNMPINDEX} é o IP do vizinho, ex.: 203.0.113.1
# 3. Protótipos de item
# bgp.peer.state[{#SNMPINDEX}] OID 1.3.6.1.2.1.15.3.1.2.{#SNMPINDEX}
# bgp.peer.transitions[{#SNMPINDEX}] OID 1.3.6.1.2.1.15.3.1.15.{#SNMPINDEX}
# bgp.peer.uptime[{#SNMPINDEX}] OID 1.3.6.1.2.1.15.3.1.16.{#SNMPINDEX}
# 4. Protótipos de trigger
# Sessão fora de Established por duas leituras seguidas
max(/Borda BGP/bgp.peer.state[{#SNMPINDEX}],#2)<6
# Sessão subiu duas vezes ou mais na última hora (oscilação)
max(/Borda BGP/bgp.peer.transitions[{#SNMPINDEX}],1h)-min(/Borda BGP/bgp.peer.transitions[{#SNMPINDEX}],1h)>=2
# Sessão reiniciou nos últimos dez minutos
last(/Borda BGP/bgp.peer.uptime[{#SNMPINDEX}])<600
O primeiro trigger usa duas leituras para não abrir problema por uma resposta SNMP perdida. O segundo pega a oscilação que o primeiro deixa passar, quando a sessão cai e volta entre duas coletas. O terceiro serve como aviso de menor gravidade, para alguém olhar o motivo no log do roteador.
A macro {#PEERAS}, com o ASN do vizinho, permite dar nomes legíveis e gravidades diferentes por tipo de sessão. Uma queda do AS 64501, de trânsito, pode ser grave, enquanto a de um cache fica como aviso.
Prefere o template pronto e testado na sua borda?
No monitoramento de BGP para provedores, um Especialista ajusta descoberta, gravidades e roteiros para as suas sessões e soma a observação dos seus blocos de fora do ASN.
IPv6 e MikroTik, onde o MIB padrão não chega?
O BGP4-MIB indexa os vizinhos por endereço IPv4, então sessões IPv6 não aparecem nele. Para elas, use o MIB do fabricante, como as tabelas de vizinhos BGP da Cisco, da Juniper e da Huawei, que também trazem o número de prefixos aceitos por sessão.
Algumas versões do RouterOS não expõem as sessões BGP por SNMP [CONFIRMAR na versão do equipamento]. Nesse caso, a coleta passa pela API do roteador ou por um script que o Zabbix executa, e o resto do template continua igual.
Quando a sessão sem monitoramento vira problema?
Vira problema no dia em que uma sessão cai sem derrubar a interface e o provedor passa horas sem saber. O custo aparece como fatura de trânsito mais alta, lentidão no pico ou bloco inteiro sem saída.
Com uma operadora só, a queda da sessão derruba todos os assinantes e alguém percebe rápido. Com duas ou mais, o tráfego vai para o link restante e a rede parece normal até o pico da noite, quando esse link satura.
Sinais de que a sua borda precisa desse monitoramento
- O tráfego trocou de operadora sozinho e ninguém soube dizer por quê.
- A operadora avisou de uma queda de sessão que a equipe não tinha visto.
- O provedor entrou no IX.br ou ligou um cache novo nos últimos meses.
- A borda tem sessões IPv6 que ninguém confere desde que foram criadas.
- O Zabbix mostra o link de pé, mas não tem nenhum item de BGP.
Duas marcas já justificam incluir as sessões no Zabbix. Três ou mais indicam que a borda está operando no escuro há algum tempo.
Na comparação de caminhos, o roteador escolhe a saída pelos atributos de cada rota, como mostra o guia sobre como o BGP escolhe entre as rotas. Sem a sessão, aquele caminho simplesmente deixa de existir na comparação.
Erros comuns ao monitorar BGP pelo Zabbix
Os erros mais frequentes deixam o template bonito e o alerta mudo. Confira os cinco abaixo antes de confiar no painel verde.
Evite estes erros no template
- Trigger em estado igual a 1: a sessão pode ficar presa em 3 ou 2 e o alerta nunca dispara; compare com 6.
- Coletar a cada cinco minutos: a oscilação entre duas coletas passa despercebida se não houver item de transições.
- Ignorar vizinhos desativados: sessão desligada de propósito fica em Idle e alerta para sempre; filtre na descoberta.
- Mapear só IPv4: o template padrão não vê o IPv6, e a sessão IPv6 pode estar caída há meses.
- Esquecer a dependência: se o roteador de borda para de responder, todas as sessões dele abrem problema ao mesmo tempo.
Zabbix sozinho ou com observação externa?
O Zabbix basta para saber se as sessões estão de pé, mas não mostra como a internet vê os seus blocos. Quem tem ASN próprio precisa das duas visões para cobrir queda de sessão e anúncio indevido.
| Situação | Zabbix na borda | Observação externa |
|---|---|---|
| Sessão com operadora caiu | Vê na hora | Vê depois, pela mudança de caminho |
| Sessão oscilando | Vê pelo contador de transições | Vê só se a rota sumir |
| Outro ASN anuncia o seu bloco | Não vê | Vê, com o ASN de origem |
| Seu bloco sumiu da internet | Não vê | Vê, com os coletores que perderam a rota |
O guia sobre como monitorar BGP mostra a parte externa e o desenho do alerta de queda. A Táquion Tech configura as duas visões e entrega cada trigger com roteiro, deixando a ferramenta e as senhas em nome do provedor.
Perguntas frequentes
O Zabbix tem template pronto para BGP?
Há templates oficiais de alguns fabricantes que incluem a tabela de vizinhos BGP, e outros na comunidade. Vale conferir se o template usa o MIB que o seu roteador expõe e se compara o estado com 6, não com 1.
Dá para ver os prefixos recebidos pelo Zabbix?
O BGP4-MIB padrão não traz o número de prefixos aceitos por vizinho. Os MIBs de Cisco, Juniper e Huawei trazem, e com eles o Zabbix alerta quando o contador zera ou chega perto do limite.
Qual intervalo de coleta usar nas sessões BGP?
Um minuto é um bom ponto de partida para o estado das sessões de trânsito. Junto com o item de transições, esse intervalo pega tanto a queda longa quanto a oscilação rápida.
O Zabbix recebe trap de queda de BGP?
Recebe, com o serviço de traps SNMP configurado no servidor. O trap avisa no instante da queda, e a coleta periódica confirma o estado depois, caso a mensagem se perca.
Monitorar BGP pelo Zabbix pesa no roteador de borda?
Ler o estado de algumas dezenas de vizinhos por minuto pesa muito pouco. O que pesa é percorrer a tabela de rotas inteira por SNMP, algo que não se deve fazer na borda.
Fontes
- RFC 4273: Definitions of Managed Objects for BGP-4: tabela bgpPeerTable, com bgpPeerState, bgpPeerFsmEstablishedTransitions e bgpPeerFsmEstablishedTime
- Descoberta de OIDs SNMP (documentação do Zabbix): regra de descoberta com {#SNMPINDEX} e protótipos de item
- Funções de histórico (documentação do Zabbix): funções last, max e min usadas nas expressões de trigger