Hello all,
I'm sure this is not a bug in net-snmp per se, but perhaps it's a bug
in an application with an SMUX add-in. My only goal here is to find out
if this is actually a bug or not (I think it is). If so, I'll dig inside
the application to address it.
The BGP4 MIB provides for, among other things, access to a router's BGP
routing table, and this is useful for network management purposes.
This is a snippet of a table, in order, and thne parts after the leading
bgp4PathAttrASPathSegment are a network number, the CIDR /## nbits,
and the IP address of a router. I've added a bit of spacing to make it
easier to read. We never care about the router part, but the Network
and /## both are:
Network /## Router
.......................... ------------ --- ---------
bgp4PathAttrASPathSegment. 64.158.223.0 .24. 10.1.1.5 = (data)
bgp4PathAttrASPathSegment. 64.159.64.0 .19. 10.1.1.5 = (data)
bgp4PathAttrASPathSegment. 64.160.0.0 .12. 10.1.1.4 = (data) ****
bgp4PathAttrASPathSegment. 64.160.71.0 .24. 10.1.1.4 = (data)
bgp4PathAttrASPathSegment. 64.160.100.0 .23. 10.1.1.4 = (data)
bgp4PathAttrASPathSegment. 64.160.143.0 .24. 10.1.1.4 = (data)
bgp4PathAttrASPathSegment. 64.160.151.0 .24. 10.1.1.4 = (data)
bgp4PathAttrASPathSegment. 64.160.254.0 .24. 10.1.1.4 = (data)
bgp4PathAttrASPathSegment. 64.161.79.0 .24. 10.1.1.4 = (data)
bgp4PathAttrASPathSegment. 64.161.99.0 .24. 10.1.1.4 = (data)
bgp4PathAttrASPathSegment. 64.161.255.0 .24. 10.1.1.5 = (data)
This part is all in order. The line marked **** is the interesting one,
and the entry I seem to have a hard time locating.
I have always believed that when doing a table walk, providing an OID
gets you the first OID *after* the one provided, but I don't know that
this is doing the right thing.
Let's start by walking the leading part:
$ snmpbulkwalk localhost bgp4PathAttrASPathSegment.64.160
?? where is 64.160.0.0 ?
bgp4PathAttrASPathSegment. 64.160.71.0 .24. 10.1.1.4 = (data)
bgp4PathAttrASPathSegment. 64.160.100.0 .23. 10.1.1.4 = (data)
bgp4PathAttrASPathSegment. 64.160.143.0 .24. 10.1.1.4 = (data)
bgp4PathAttrASPathSegment. 64.160.151.0 .24. 10.1.1.4 = (data)
bgp4PathAttrASPathSegment. 64.160.254.0 .24. 10.1.1.4 = (data)
It looks like it entirely skips the first entry even though it appears to be
the next one purportedly in line. It seems that I have to fill out zeros of
the IP address *and* fill in the /nbits to get it:
$ snmpbulkwalk localhost bgp4PathAttrASPathSegment.64.160.0
bgp4PathAttrASPathSegment.64.160.0 = No Such Instance currently exists at this
OID
$ snmpbulkwalk localhost bgp4PathAttrASPathSegment.64.160.0.0
bgp4PathAttrASPathSegment.64.160.0.0 = No Such Instance currently exists at
this OID
$ snmpbulkwalk localhost bgp4PathAttrASPathSegment.64.160.0.0.0
bgp4PathAttrASPathSegment.64.160.0.0.0 = No Such Instance currently exists at
this OID
$ snmpbulkwalk localhost bgp4PathAttrASPathSegment.64.160.0.0.12
bgp4PathAttrASPathSegment.64.160.0.0 .12. 10.1.1.4 = (data)
I think that all of these should return at least the first line, maybe more.
I am seeing this behavior in the Quagga BGP daemon, which plugs in as an SMUX
extension to net-snmp. When I make the same queries against the real Juniper
routers, I get the behavior I expect.
Is this a bug? Or is an implementation allowed to do things like this if it
makes internal implementation easier (as this almost certainly does).
Thanks,
Steve
--
Stephen J Friedl | Security Consultant | UNIX Wizard | +1 714 544-6561
www.unixwiz.net | Tustin, Calif. USA | Microsoft MVP | [EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
