Sensor for BGP status

This article applies to PRTG Network Monitor 16.3.25 or later

I work with BGP in my network. I know how to monitor a single peer with the OID, but what I really need is to monitor all of them and find if one of them is in active state. I know that there is OID for the bgp peer table.(1.3.6.1.2.1.15.3) but how can I monitor a snmp table?

There are two very distinct ways of monitoring BGP Peers in PRTG. Essentially, the "best" solution for you will depend on the number of peers that you have and the granularity you need. If unsure, try the "Device Template" approach first.

1) Monitoring BGP Peers using single Sensor per Peer via Device Template

The most detailed and easier to set-up approach is to use a Custom Device Template, this will deploy one sensor per peer on your BGP Router. 

This approach may be good for small deployments, but if you have dozens or hundreds of peers it becomes unpractical. If you have a highly dynamic deployment (where peers change very frequently) it may also lead to frustration.

While there are no BGP Peer sensors in PRTG by default, I've put together a couple of lookups and a device template, which can be used to automate the deployment of these sensors using auto-discovery. The sensors will focus on the BGP peer's state.

Adding Custom Sensors using the Auto-Discovery + Template

You can use the device template that we provide below to automatically create custom sensors with the PRTG auto-discovery.

The metrics that are available can vary. The sensors can monitor the following if the data is available:

• BGP Peer
  • State
  • Admin Status (Started/Stopped)
  • Established Time
  • Established Transitions

The device template creates the available and compatible sensors based on the data at hand. The sensors implement default alerts whenever possible, but you can still fine-tune most channels by defining additional limits in the sensor channels settings or modifying the lookups included by default.

Requirements

• PRTG Network Monitor 16.3.25 or later
• Because the device template relies on the auto-discovery process, the device you want to monitor needs to be reachable via PING.
• SNMP must be enabled and the device must support the BGP4-MIB.

Known Issues and Limitations

• If a peer's address changes, you will need to handle this manually. This can be done by deleting the sensor and re-running the auto-discovery or by updating the Identifier in the sensor's settings to the new address. You can re-run the auto-discovery as many times as you want, it will never duplicate sensors.
• To discover new peers automatically, use the Discovery Schedule from within the device's settings
• PRTG shows some of the alerts as reported by the monitored device via SNMP using lookups. If the status is not reported correctly via SNMP, PRTG cannot detect any issues. For additional alerts, please set up limits for additional channels.
• This device template was created based on data collected from other customers, so we cannot guarantee that the sensors described above will work on your systems or that the default thresholds are optimal for your use case. Use these components at your own risk. Please test and validate the sensors in your environment after deploying them.

Deployment and Usage

1. Download the required zip archive containing the template's files here.
2. Extract the archive to your PRTG program directory. By default, this is %Program Files (x86)%\PRTG Network Monitor\.
3. In PRTG, restart the core server: open Setup | System Administration | Administrative Tools | Restart Core Server and click Go!. This ensures that the MIB and lookups are loaded before you run the auto-discovery.
4. Create a new device in PRTG with the address (IP or FQDN) of the device that you want to monitor and configure the SNMP credentials accordingly.
5. Right-click your new device, select Run Auto Discovery with Template, browse for BGP and select the Custom BGP v4 Peer State v0.x template from the list.
   Note: Using the auto-discovery with a dedicated device template is convenient here because it automates the creation of the custom sensors in an organized fashion.
6. The sensors are deployed after a couple of seconds.
7. You can adjust the channel limits or lookups to your needs later.

Result

The resulting sensors look like this:

Device Overview

Sensor Overview

No sensors deployed? :(
Please read ahead for troubleshooting.

Troubleshooting

Have any issues? Please don't hesitate to contact us by replying to this post or via a support ticket. Please make sure to mention this KB post. Please read ahead for troubleshooting steps that you can take in advance.

Auto-Discovery Log

Your auto-discovery log tells you a lot about what went wrong during the sensor's deployment. You can troubleshoot the auto-discovery by inspecting the auto-discovery log. If you get entries like the one below (NOT FOUND), it means that the required protocol or Object Identifier (OID) is not available and the sensors can't be deployed.

[...] 21.08.2017 09:17:17: Template Loaded; 
Device ID: 22848; Name: Custom BGP v4 Peer State v0.2 21.08.2017 09:17:18: Template Check; 
Device ID: 22848; Check ID: ping; FOUND 21.08.2017 09:17:19: Template Check; 
Device ID: 22848; Check ID: snmp; FOUND 21.08.2017 09:17:20: Template Check; 
Device ID: 22848; Check ID: snmptable_bgpPeerTable; 
NOT FOUND [...]

In the example above, some sensors were skipped because the device did not respond to the snmptable_bgpPeerTable check. This means that this data is probably not available on your device. You can track this data by looking for the name after snmptable_. In this case, a search for bgpPeerTable will tell you what OID from what MIB is missing.

You can also use this log to identify if the discovery was interrupted because the device did not respond to PING or to a basic SNMP check.

SNMP Data

If the discovery log is not sufficient, you can review the SNMP data directly from your device. To do so, save the text below (in the white box) as .txt and use it with the Scan Script option in our SNMP Tester. This will allow you to review which SNMP queries succeed and which do not deliver any data. Please have this information at hand when contacting our support team.

-------- 
Walk Default 
-------- 
hrSystemUptime walk=1.3.6.1.2.1.25.1.1 
-------- 
MIB-2 System walk=1.3.6.1.2.1.1 
-------- 
Sensor Specific Queries 
---- 
walk=1.3.6.1.2.1.15.3 
---

Version History

2) Monitoring BGP Peer Status using a Custom Script based sensor

The custom script provides a summarized overview of all peers in a single sensor. It focuses on the actual number of peers in each state and will list any "offending" peers in the sensor's message. The setup is more complex and it requires additional software. In its current form it does not support SNMP V3. 

You can use an example script written in PowerShell that allows PRTG to monitor the bgpPeerState from the bgpPeerTable as described in the Cisco documentation. Add an EXE/Script Advanced sensor to your PRTG installation and select this script in the sensor settings.

• Download Custom Powershell Monitor BGP Peers

Requirements

• NET-SNMP Tools installed in the Probe and available "in the path" of the Probe performing the queries. (Windows Download )
• Powershell Version 3 or above enabled and working on the Probe performing the queries.
• Monitored Device must respond to SNMP Requests

Logic

The custom EXE/Script sensor will perform a walk at the 1.3.6.1.2.1.15.3.1.2 OID and count the numbers of peers in each state. It will additionally display a message indicating which peers are NOT in the Established state.

Within PRTG this can be very useful together with limits: You can get a warning or error sensor status if any amount of peers in any status goes above or below a limit. The default Warning Limit for the non-primary channels is 1.

Custom Sensor

The script we provide is a PowerShell script that actually uses the snmpwalk.exe component from NET-SNMP Tools to perform a walk on the SNMP Table from the router.

If the result is valid, it is parsed using substring. Furthermore, the IP addresses are extracted from the string array using the split command.

The result is an XML output that conform with the PRTG API.

Because EXE/Script sensors have a considerable impact on PRTG's performance, Windows Server 2012 R2 is the best probe candidate for this type of sensor.

Usage/Set-up instructions

1. Copy the code below and paste it in blank notepad document
2. The file should be saved in the following folder: "C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML" with your name of choice. (i.e. Custom Powershell Monitor BGP Peers.ps1)
3. Head to your device that runs BGP, select Add Sensor, browse and select EXE/Script Advanced Sensor
4. Select the Script from the drop-down (Custom Powershell Monitor BGP Peers.ps1)
5. Enter the required parameters -hostaddr '%host' -community '%snmpcommunity'
6. Save/Continue

Code

This is the code of the custom sensor (also available as download at the top of this post). It can also be downloaded here.

# Monitor Status of BGP Peers in Cisco Devices using bgpPeerState within 1.3.6.1.2.1.15.3.1.2 in PRTG (Summaries) v0.5 10/01/2017
# Originally published here: https://kb.paessler.com/en/topic/25313
#
# Parameters in PRTG should be: 
# -hostaddr '%host' -community '%snmpcommunity' -port '161' -timeout '5'
# Alternatively (without placeholders):
# -hostaddr 'myrouter.domain.tld' -community 'public' -port '161' -timeout '5'
#
# Requites net-snmp installed and in the path since it will use snmpwalk.exe (http://www.net-snmp.org/)
#
# It's recommended to use large scanning intervals for exe/xml scripts. (Not below 300 seconds)


param(
    [string]$hostaddr = "router.domain.tld",
    [string]$community = "public",
    [string]$port = "161",
    [string]$timeout = "5",
    [string]$troubleshooting = 0
)

$version = "0.5"

$queryMeasurement = [System.Diagnostics.Stopwatch]::StartNew()
$walkresult = (snmpwalk.exe -Ln -On -v 2c -c $community $hostaddr":"$port ".1.3.6.1.2.1.15.3.1.2" -t $timeout 2>&1)

if ($troubleshooting -eq 1){
    snmpwalk.exe -Ln -On -v 2c -c $community $hostaddr":"$port ".1.3.6.1.2.1.15.3.1.2" -t $timeout
    Exit
    }

#Check if snmwalk.exe suceeded.
if ($LASTEXITCODE -ne 0 ){
    write-host "<prtg>"
    write-host "<error>1</error>"
    write-host "<text>Error: $($walkresult) / ScriptV: $($version) / PSv: $($PSVersionTable.PSVersion)</text>"
    write-host "</prtg>"
    Exit
}

#Validate output. Expects *INTEGER* in the result. Example: "12.34.56.78 = INTEGER: 6" - String and array have distinc handling.
if (($walkresult -is [String]) -and ($walkresult -notlike "*INTEGER*") -or ($walkresult -is [array]) -and ($walkresult[0].ToString() -notlike "*INTEGER*")){
    write-host "<prtg>"
    write-host "<error>1</error>"
    write-host "<text>Error: $($walkresult) / ScriptV: $($version) / PSv: $($PSVersionTable.PSVersion)</text>"
    write-host "</prtg>"
    Exit
}

$walkresult = $walkresult.Substring(22)
$peersmsg = $null

foreach($entry in $walkresult | where-object { $_ -notlike "*: 6"}){
    $peersmsg += "$($entry.split()[-0]) "
}

$peerstatus = new-object int[] 6
$peerstatus[5] = ($walkresult | where-object { $_ -like "*: 6"}).Count
$peerstatus[4] = ($walkresult | where-object { $_ -like "*: 5"}).Count
$peerstatus[3] = ($walkresult | where-object { $_ -like "*: 4"}).Count
$peerstatus[2] = ($walkresult | where-object { $_ -like "*: 3"}).Count
$peerstatus[1] = ($walkresult | where-object { $_ -like "*: 2"}).Count
$peerstatus[0] = ($walkresult | where-object { $_ -like "*: 1"}).Count

$queryMeasurement.Stop()

write-host "<prtg>"

write-host "<result>"
write-host "<channel>Peers Established</channel>"
write-host "<value>$($peerstatus[5])</value>"
write-host "</result>"

write-host "<result>"
write-host "<channel>Peers OpenConfirm</channel>"
write-host "<value>$($peerstatus[4])</value>"
Write-host "<LimitMode>1</LimitMode>"
write-host "<LimitMaxWarning>1</LimitMaxWarning>"
write-host "</result>"

write-host "<result>"
write-host "<channel>Peers OpenSent</channel>"
write-host "<value>$($peerstatus[3])</value>"
Write-host "<LimitMode>1</LimitMode>"
write-host "<LimitMaxWarning>1</LimitMaxWarning>"
write-host "</result>"

write-host "<result>"
write-host "<channel>Peers Active</channel>"
write-host "<value>$($peerstatus[2])</value>"
Write-host "<LimitMode>1</LimitMode>"
write-host "<LimitMaxWarning>1</LimitMaxWarning>"
write-host "</result>"

write-host "<result>"
write-host "<channel>Peers Connect</channel>"
write-host "<value>$($peerstatus[1])</value>"
Write-host "<LimitMode>1</LimitMode>"
write-host "<LimitMaxWarning>1</LimitMaxWarning>"
write-host "</result>"

write-host "<result>"
write-host "<channel>Peers Idle</channel>"
write-host "<value>$($peerstatus[0])</value>"
Write-host "<LimitMode>1</LimitMode>"
write-host "<LimitMaxWarning>1</LimitMaxWarning>"
write-host "</result>"

Write-Host "<result>"
Write-Host "<channel>Script Execution Time</channel>"
Write-Host "<value>$($queryMeasurement.ElapsedMilliseconds)</value>"
Write-Host "<CustomUnit>msecs</CustomUnit>"
Write-Host "</result>"

if ($peersmsg) {
    write-host "<text>Not Established: $($peersmsg)</text>"
    write-host "<Warning>1</Warning>"
}

write-host "</prtg>"

The script was tested against a router with 65 peers on PRTG 15.3.17, using NET-SNMP 5.5.0 x86 with PRTG/Probe running on Windows Server 2012 R2 x64 (not all versions of windows have the same PowerShell support). Please note that we cannot provide deep technical support for custom scripts.

Version History

Disclaimer:
The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.