BGP Data Query, very easy to use

[bkbristlin]

I have been going through all the logs and poller cache etc. I found something in the logs.
02/01/2011 09:45:00 AM - CMDPHP: Poller[0] Host[5] DS[675] WARNING: Result from SNMP not valid. Partial Result: U
02/01/2011 09:45:00 AM - CMDPHP: Poller[0] Host[5] DS[675] WARNING: Result from SNMP not valid. Partial Result: U
02/01/2011 09:45:00 AM - CMDPHP: Poller[0] Host[5] DS[675] WARNING: Result from SNMP not valid. Partial Result: U

The host "5" is the 7606S, 675 is the graph for BGP. Not sure what it is saying is partial at this point though.

[bkbristlin]

Scott,
Are you able to upload some screenshots of your BGP templates and an snmpwalk of what you see for prefixes? I have been working on this for several days now and have progressed, barely. If I use your templates I get nothing to graph. If I use mcutting's templates and change the two .5 OID's to .7 I can get the messages TX/RX to graph. I've gone through all the debug information and everything looks fines except that the rrdtool shows a NaN value for the prefixes.

One thing I thought might be the case was that since you are using a 2851 you probably aren't receving a full routing table so you would have less prefixes. I set the max to 0 for the graph and it didn't change anything so I used the rrdtool to tune it and still no luck. At this point I'm unsure.

I've changed everything I can think of, done a ton of reading, and still can't find why it won't graph prefixes. I tried to build my own XML file but I'm still unclear on all the different requirements so I get nothing each time I add the query to the device.

[bkbristlin]

FINALLY!! I got this to work. I took the info from this query and from another one, figured out what everything meant and then put the best of both worlds together

Attached are the files for this.
For those on older systems, this was built and exported on 0.8.7g.

[lard]

Hi,

Thanks for your work on this bkbristlin - I originally attempted graphing BGP in 2006 so nice to finally get this working on one of my cacti systems

I did use your updated templates but hit a few issues, the graphs were not displaying and rrd files not created.

I believe it was related to the data template titles (I wasn't getting unique data sources names) so added |host_description| to the data template RRD title and this is now working - for others who may hit this I've exported the templates that are now working on my platform (0.8.7g)

Hope that helps!

[bkbristlin]

Good to hear. I plan to get an IPv6 version going soon. We are starting the IPv6 process now so I am waiting on IP's.

[lard]

Good to hear. I plan to get an IPv6 version going soon. We are starting the IPv6 process now so I am waiting on IP's.

Sounds good - we're likely to complete our implementation mid year so great timing

One query on the current snmp query - I get in/out updates but "nan" for number of prefixes - this is a Cisco 7300 and slightly stumped as to why it's not reporting?

Could you check this is the same as your data query template bgpmonitor.xml please?


<bgpPrefixes>
<name>bgpPrefixes</name>
<method>walk</method>
<source>value</source>
<direction>output</direction>
<oid>1.3.6.1.4.1.9.9.187.1.2.4.1.1</oid>
<oid_suffix>1.1</oid_suffix>
</bgpPrefixes>

All the others such as as name are using standard SNMP 2 Mib but this one is a cisco oid?

[bkbristlin]

- <bgpPrefixes>
<name>bgpPrefixes</name>
<method>walk</method>
<source>value</source>
<direction>output</direction>
<oid>.1.3.6.1.4.1.9.9.187.1.2.4.1.1</oid>
<oid_suffix>1.1</oid_suffix>
</bgpPrefixes>


Same thing. Are you able to run an snmpwalk on your router for that OID and get results?

[lard]

interestingly I'm getting no response for anything on the bgppeer oid - reading into a couple of cisco docs it looks like this may have been depreciated in the IOS version we're running which is odd - I'll do some more digging and see how to get this information

http://www.cisco.com/en/US/docs/ios/12_ ... #wp1067537

From that doc:

cbgpPeerTable Support

The cbgpPeerTable has been modified to support the enhancements described in this document. The following new table objects are supported in the CISCO-BGP-MIB.my:

•cbgpPeerLastErrorTxt

•cbgpPeerPrevState

The following table objects are not supported. The status of theses objects is listed as deprecated. However, these objects are not operational:

•cbgpPeerPrefixAccepted

•cbgpPeerPrefixDenied

•cbgpPeerPrefixLimit

•cbgpPeerPrefixAdvertised

•cbgpPeerPrefixSuppressed

•cbgpPeerPrefixWithdrawn

[lard]

interestingly I'm getting no response for anything on the bgppeer oid - reading into a couple of cisco docs it looks like this may have been depreciated in the IOS version we're running which is odd - I'll do some more digging and see how to get this information

http://www.cisco.com/en/US/docs/ios/12_ ... #wp1067537

From that doc:

cbgpPeerTable Support

The cbgpPeerTable has been modified to support the enhancements described in this document. The following new table objects are supported in the CISCO-BGP-MIB.my:

•cbgpPeerLastErrorTxt

•cbgpPeerPrevState

The following table objects are not supported. The status of theses objects is listed as deprecated. However, these objects are not operational:

•cbgpPeerPrefixAccepted

•cbgpPeerPrefixDenied

•cbgpPeerPrefixLimit

•cbgpPeerPrefixAdvertised

•cbgpPeerPrefixSuppressed

•cbgpPeerPrefixWithdrawn

o.k. perhaps it's not the IOS version - not responding on a 7300 running 12.2.20 - working fine on a 7200 running 12.4.18

To be honest the 7300's have been nothing but trouble in the past......

[bkbristlin]

That's too bad. We don't have any 7300's so I can't test.
We have 12008's, 7200, 7600's, and 7600S's.
It works fine on all those. If it can work with the code on a 12008 you would think a 7300 woud work.

Does the command "show bgp all summary" work?

[xenon]

It's the suffix that may be different on different CISCO platforms/IOSversions.
I found out that mine was 1.128 instead of 1.1 via a simple snmpwalk
Great template btw, thanks!

[bkbristlin]

It's the suffix that may be different on different CISCO platforms/IOSversions.
I found out that mine was 1.128 instead of 1.1 via a simple snmpwalk
Great template btw, thanks!

Good to know. What model router do you have?

[xenon]

I'm monitoring a 7609 with RSP720-3CXL running c7600rsp72043-advipservicesk9-mz.122-33.SRD5.bin.

It will be very nice to have advertised prefixes and the maximum prefix limit visible on those graphs
I'll work on it when I have time but I know you guys will beat me to it anyway

[bkbristlin]

Oh the 1.128 must be a product of the 3CXL. We have the 3BXL with the same IOS.

I'm a little confused what you mean by advertised prefixes and the maximum prefix limit. The max I don't think exists, that would be a limitation of your memory.

[xenon]

You are probably right about the 3CXL.

This might trow some light on what I mean:
cbgpPeerAcceptedPrefixes cbgpPeerAcceptedPrefixes 1.3.6.1.4.1.9.9.187.1.2.4.1.1
cbgpPeerDeniedPrefixes cbgpPeerDeniedPrefixes 1.3.6.1.4.1.9.9.187.1.2.4.1.2
cbgpPeerPrefixAdminLimit cbgpPeerPrefixAdminLimit 1.3.6.1.4.1.9.9.187.1.2.4.1.3
cbgpPeerPrefixThreshold cbgpPeerPrefixThreshold 1.3.6.1.4.1.9.9.187.1.2.4.1.4
cbgpPeerPrefixClearThreshold cbgpPeerPrefixClearThreshold 1.3.6.1.4.1.9.9.187.1.2.4.1.5
cbgpPeerAdvertisedPrefixes cbgpPeerAdvertisedPrefixes 1.3.6.1.4.1.9.9.187.1.2.4.1.6
cbgpPeerSuppressedPrefixes cbgpPeerSuppressedPrefixes 1.3.6.1.4.1.9.9.187.1.2.4.1.7
cbgpPeerWithdrawnPrefixes cbgpPeerWithdrawnPrefixes 1.3.6.1.4.1.9.9.187.1.2.4.1.8

I'm using administrative prefix caps on all neighbors as a configuration failsafe in case someone say leaks the entire bgp table in the local peering. It looks like this in the configuration:
neighbor x.x.x.x maximum-prefix N restart M
and it means that if get more than N prefixes from that neighbor the bgp session will drop for M minutes.

I've checked and the N value is returned correctly snmpwalking .1.3.6.1.4.1.9.9.187.1.2.4.1.3 (again suffixed by 1.128 in my case).
I'm still looking for a way to snmpget the advertised-routes (a.k.a. - sh ip bgp neighbors x.x.x.x advertised-routes) because cbgpPeerAdvertisedPrefixes 1.3.6.1.4.1.9.9.187.1.2.4.1.6 returns weird numbers... I'll let you know if I find something.