How Zabbix Strengthens BGP Monitoring: From Theory to Practice

Some of the most relevant OIDs include:

- `1.3.6.1.2.1.15.3.1.2` → `bgpPeerState`: Shows the current state of each BGP session (Idle, Connect, Active, OpenSent, OpenConfirm, Established)

- `1.3.6.1.2.1.15.3.1.9` → `bgpPeerFsmEstablishedTime`: Specifies how long the session has been established

- `1.3.6.1.2.1.15.3.1.10` → `bgpPeerInUpdates`: Number of update messages received from a peer

- `1.3.6.1.2.1.15.3.1.11` → `bgpPeerOutUpdates`: Number of update messages transmitted to a peer

- `1.3.6.1.2.1.15.3.1.7` → `bgpPeerRemoteAs`: Peer's remote Autonomous System

These OIDs allow Zabbix to build detailed monitoring items and smart triggers that alert about anomalies in BGP sessions. Thanks to this standardization, there is no need to depend on proprietary solutions or manual parsing of CLI commands, which significantly simplifies operations in complex environments.

We will now explore how Zabbix uses these OIDs in practice to deliver robust, centralized BGP monitoring.

Why Monitor BGP?

BGP is the protocol that makes it possible for Autonomous Systems to exchange routing information, allowing prefixes to be advertised globally over the Internet. While generally stable, BGP sessions can be affected by multiple factors such as physical link failures, router reboots, configuration errors, unexpected changes in advertised prefixes, or security incidents like route hijacking.

This is why limiting monitoring to a simple ping or interface check is not enough. Detailed visibility into the state of each BGP session is key to detecting problems and reducing troubleshooting times.

Integrating BGP with Zabbix

Zabbix allows incorporating BGP monitoring through SNMP and BGP4-MIB, a set of standardized objects that provide information about active sessions and their state. Thanks to this compatibility, BGP monitoring can be integrated into the same environment where the overall performance of network devices is already being tracked.

Major vendors such as Cisco, Juniper, MikroTik, and Arista natively support BGP4-MIB. This makes it easier to centralize monitoring and uniformly consolidate metrics.

Key Metrics that Can Be Monitored

Zabbix can periodically collect essential BGP data, including:

• BGP session state: Shows whether the session is in Established or an intermediate state (Idle, Connect, Active, OpenSent, OpenConfirm)
• Accepted prefixes: Shows how many prefixes are received from each BGP peer
• Advertised prefixes: Shows how many prefixes the router is advertising to its peers
• Session uptime: Helps identify frequent failures or reboots
• Remote peer ASN and IP address: Provides valuable information for correlating sessions with its counterpart

This data is extracted using standardized BGP4-MIB OIDs and can be visualized in dashboards and historical graphs.

All this information is obtained through standard OIDs such as:

• 1.3.6.1.2.1.15.3.1.2 * Session state (bgpPeerState)
• 1.3.6.1.2.1.15.3.1.9 * Time the session has been in Established state (bgpPeerFsmEstablishedTime)

From Theory to Practice: Implementation Steps

Configuring BGP monitoring with Zabbix doesn’t require any complex steps. The process generally involves:

1. Enabling SNMP on the router, verifying that BGP4-MIB is available.
2. Registering the host in Zabbix, specifying its SNMP interface and appropriate credentials (SNMPv2 or SNMPv3).
3. Creating monitoring items, defining queries for OIDs related to session state, prefixes, and uptime.
4. Configuring value maps for translating numerical states into readable labels, for example: 1 = Idle, 6 = Established.
5. Designing smart triggers that generate alerts when a session changes state or when abrupt variations in the number of prefixes are detected.
6. Building custom dashboards for real-time monitoring of all BGP sessions.

Once the configuration is deployed, Zabbix can notify relevant events via email, instant messaging, or other channels.

Here’s a step-by-step example for monitoring BGP on a router that supports SNMP:

Enable SNMP and BGP MIB on the router.

Cisco:

snmp-server community zabbix_ro RO

snmp-server view BGPView iso included

snmp-server group BGPGroup v2c read BGPView

snmp-server host 192.168.1.100 version 2c zabbix_ro

MikroTik:

Add the router as a host in Zabbix

/snmp set enabled=yes

/snmp community add name=zabbix_ro address=192.168.1.100/32

• Host name: Router-BGP
• SNMP interface: router IP, port 161
• Credentials: SNMPv2 community or SNMPv3 user

Create BGP monitoring items

In Zabbix * Configuration * Hosts * Items * Create Item:

• Name: State of BGP session with 200.229.145.84
• Type: SNMPv2 agentO
• ID: 1.3.6.1.2.1.15.3.1.2.X.X.X.X (peer IP address in decimal notation)
• Key:  bgp.session.state[{#PEER}]
• Type of data: Integer.

Value mapping:

= Idle

= Connect

= Active

= OpenSent

= OpenConfirm

= Established

Repeat for Received prefixes (OID: 1.3.6.1.2.1.15.6.1.1.X.X.X.X) and Uptime.

Create triggers Example:

• Name: BGP session with {#PEER} down
• Expression: {Router-BGP:bgp.session.state[{#PEER}.last()}<>6
• Severity: High

This trigger generates an alert if the session is not in “Established” state.

Design a dashboard

Use graphs and widgets to display:

• Number of active sessions
• Prefixes accepted by peer
• Status of each session with traffic lights

You can use Low-Level Discovery (LLD) to group all peers on a prototype host and monitor multiple BGP sessions without manually configuring them.

Common Use Cases

Proactive BGP monitoring with Zabbix is ​​especially useful in scenarios such as:

• Internet service providers that maintain multiple transit and peering sessions.
• Data centers that publish their own and customer prefixes.
• Academic networks that exchange routes with various institutions.
• Companies with international presence that manage redundant connectivity with multiple carriers.

Having this information strengthens operational capacity and reduces incident response times.

Real Use Case

Zabbix was implemented with SNMPv3 and custom templates in an ISP network with 10 BGP peers. The results:

• Failure detection delay: dropped from 10 minutes to less than 60 seconds.
• Proactive alerts: unexpected prefix variations generate alerts before customers report issues.
• NOC dashboard: complete visibility into BGP health in real time.

Recommended Best Practices

Here are some recommendations to take full advantage of Zabbix capabilities in BGP:

• Use SNMPv3 with authentication and encryption whenever possible.
• Define baseline values for accepted and advertised prefixes.
• Correlate BGP session state with other device health metrics (CPU usage, interface traffic, ICMP availability).
• Clearly document each peer’s ASNs and expected thresholds.

Conclusion

Zabbix combines power and flexibility to transform BGP monitoring from a function once limited to proprietary tools into an accessible, standardized capability that can be adapted to any type of environment. By integrating BGP4-MIB through SNMP, it allows quickly implementing detailed monitoring with customized alerts and historical visibility.

Adopting these practices strengthens network stability and helps anticipate issues before they become visible to users.