[c-nsp] Monitoring BGP with NAGIOS

[Frank Bulk - iName.com]

Ian:

Thanks for your input.  I agree, snmptraps are the next obvious step.  The
URL you provided was the one I refered to when looking through the results
of my walk through Cisco's BGP MIB. =)

Since my upstream monitors our edge routers, including BGP, the monitoring
is more to document that something happened.  I won't have it page me at 3
in the morning, but when my upstream tells me that they're doing
maintenance, I'll know when I wake up if it did impact BGP.  It's also
another input into my event correlation system (me) -- if a customer tells
me that they've lost internet access, or if I've asked for another netblock
to be advertised, I'll know immediately to look at a routing issue.

Frank

-----Original Message-----
From: Ian MacKinnon [mailto:Ian.Mackinnon at lumison.net] 
Sent: Thursday, July 23, 2009 9:15 AM
To: frnkblk at iname.com; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Monitoring BGP with NAGIOS

Hi Frank,

You say maybe traps is the next step.....
You can get an snmp trap when a peer changes state, you can then get nagios
to respond to the traps using traphandler

Some info at
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gt_bmibe.html

We are using nagios and traphandlers to respond to things like link up/down

I guess if you poll often enough you can be sure to catch a peer in a bad
state, but do you actually care at 3 in the morning that a peer was down for
30s and is now back?

Ian

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Frank Bulk
Sent: 23 July 2009 15:04
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Monitoring BGP with NAGIOS

We're a small shop and our group's upstream is single-homed in terms of
providers but dual-homed in terms of physical connectivity, with a private
ASN.



Occasionally there's BGP events and I would like to be remotely notified --
NAGIOS can do that and I prefer SNMP polling.  We're not doing an SNMP TRAP
or syslog processing at this time - that would be an obvious next step for
us.



Currently the NAGIOS plugin I'm developing polls the bgpPeerState,
bgpPeerIn/OutUpdates and bgpPeerIn/OutTotalMessages and alerts me if there's
a change.  Since a BGP session could be re-established in a short amount of
time, I would like to trigger an alert if the number of In/Out Updates or
Messages exceeds the regular value (I'm presuming that when the BGP session
re-establishes, these counters climb more quickly than during times of
stability).  But I'm not sure if Updates/Messages are normally sent every 30
or 60 seconds (I've seen 60 on a wiki page, but "sh ip bgp neighbors" says
that the "keepalive interval is 30 seconds" and "Default minimum time
between advertisement runs is 30 seconds".  I'm guessing this knob can be
adjusted in IOS, so ideally I would like the NAGIOS plugin to accommodate
for that, such that if the counters move '5' in 5 minutes that's OK with a
60 second period, but if it's a 30 second period, then those counts should
move 10 times.  But keep-alive/scan interval doesn't seem to be listed in
the MIB.



Also, there's a lot more information available at the Cisco CLI when
executing "sh ip bgp summary", specifically:

.         BGP table version

.         # of network entries

.         # of path entries

.         # of prefixes

.         # of paths

.         Up/Down times

Is any of that available via SNMP, because my walking isn't showing that at
all?



If you think I'm going about this the wrong way, please feel free to tell
me. =)



Regards,



Frank

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.20/2249 - Release Date: 07/21/09
18:02:00

--

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender. Any
offers or quotation of service are subject to formal specification.
Errors and omissions excepted.  Please note that any views or opinions
presented in this email are solely those of the author and do not
necessarily represent those of Lumison.
Finally, the recipient should check this email and any attachments for the
presence of viruses.  Lumison accept no liability for any
damage caused by any virus transmitted by this email.