Num provedor com mais de uma saída — dois trânsitos, um IX, um cache de CDN — a queda de uma sessão BGP raramente derruba o cliente na hora. O tráfego simplesmente muda de caminho. Esse é exatamente o perigo: a sessão com o PTT cai às 2h, tudo passa pelo trânsito pago, o link satura às 20h e o NOC só descobre a causa olhando pra trás. Monitorar o estado de cada sessão, e não só o link físico, fecha essa lacuna.
Onde estão os dados: BGP4-MIB
A maioria dos roteadores expõe as sessões BGP via SNMP pela BGP4-MIB (RFC 4273). Os objetos mais úteis, na tabela bgpPeerTable (1.3.6.1.2.1.15.3.1):
bgpPeerState(.2) — estado da sessão: 1 idle, 2 connect, 3 active, 4 opensent, 5 openconfirm, 6 established.bgpPeerRemoteAs(.9) — ASN do vizinho.bgpPeerFsmEstablishedTime(.16) — há quantos segundos a sessão está no estado atual. Valor que zera de repente indica flap.bgpPeerRemoteAddr(.7) — IP do vizinho, usado como índice.
Limitação importante: a BGP4-MIB padrão é só IPv4. Sessões IPv6 e contadores de prefixos recebidos normalmente ficam em MIBs proprietárias (Cisco, Juniper, Huawei e outros têm as suas). Confira o que o seu equipamento oferece antes de montar o template.
Montando no Zabbix
- Regra de LLD sobre a
bgpPeerTable, usando o endereço do peer como macro ({#PEER}) e trazendo o ASN junto. - Protótipo de item pro estado e pro tempo no estado.
- Value mapping pra mostrar "established" em vez de "6".
- Triggers: - Estado diferente de 6 por mais de alguns minutos → problema (com severidade maior pra trânsito do que pra peer secundário). - Tempo no estado menor que o anterior (o contador zerou) → flap, mesmo que a sessão tenha voltado.
- Macros de contexto pra nomear o peer (
{$BGP.PEER.NAME:"200.0.0.1"}) — "trânsito A caiu" é muito melhor que "200.0.0.1 state 1".
Além do estado
- Prefixos recebidos (quando a MIB do fabricante expõe): queda brusca no número de rotas de um upstream é sinal de problema mesmo com a sessão "established".
- Tráfego por interface de peering lado a lado com o estado da sessão: confirma se o tráfego migrou de fato.
- Dependência: se a interface física caiu, o alarme de BGP é consequência — configure a dependência pra não receber dois alertas da mesma causa.
Sessão BGP é o tipo de coisa que se esquece de monitorar justamente porque "nunca cai". Se quiser ajuda pra montar o template pro seu roteador de borda, fale com a gente.
Fontes: IETF — RFC 4273, Definitions of Managed Objects for BGP-4 e Zabbix — Low-level discovery (documentação 7.0).