Welcome, Guest. Please login or register.

Author Topic: Ambiguous SNMP Version []  (Read 4607 times)

spiffturk

  • Guest
Ambiguous SNMP Version []
« on: July 21, 2009, 03:06:45 PM »
Just came across a strange one.  We just recently installed a few Cisco 3560E switches (Gigabit version of the normal 3560).  We noticed yesterday that several of our switches were no longer being probed by NeDi.  So after some digging around, it turns out that NeDi is dying when it tries to probe any of these new switches:

Code: [Select]
-bash-3.2$ ./nedi.pl -t 130.207.219.98

NeDi 1.0.4 - 4.Apr 2009
OUI: 14892 NIC vendor entries read
Dev: 1654 devices read from nedi104.devices
Link: 0 links (WHERE type = "STAT") read from nedi104.links


Discovery with 1 seed(s) on Tue Jul 21 08:40:46 2009
====================================================================================
Device Status      Todo/Done-Time
------------------------------------------------------------------------------------
130.207.219.98 NATLGAC3560C Can't call method "close" on an undefined value at ./inc/libsnmp.pl line 410.
-bash-3.2$

Perl is not my forte, but I tossed in a couple print statements in libsnmp.pl and found that basically what's happening is:

1) Net::SNMP-session(); is being called with $version not set
2) Net::SNMP returns an initialized $session variable and a $error set to "Ambiguous SNMP version []"
3) the Enterprise{} routine gets to line 410 where it tries to call $session->close(), and dies.

The code in question, with my prints:

Code: [Select]
print "Version:  $main::dev{$_[0]}{sp}\n";
        ($session, $error) = Net::SNMP->session(-hostname  => $main::dev{$_[0]}{ip},
                                                -community => $main::dev{$_[0]}{cm},
                                                -timeout   => $misc::timeout,
                                                -version   => $main::dev{$_[0]}{sp},
                                                -translate => [-octetstring => 0x0]
                                                );
print "Session: $session\n";
print "Error: $error\n";

And output on one of the new switches:

Code: [Select]
-bash-3.2$ ./nedi.pl -t 130.207.219.88

NeDi 1.0.4 - 4.Apr 2009
OUI: 14892 NIC vendor entries read
Dev: 1657 devices read from nedi104.devices
Link: 0 links (WHERE type = "STAT") read from nedi104.links


Discovery with 1 seed(s) on Tue Jul 21 08:59:49 2009
====================================================================================
Device Status      Todo/Done-Time
------------------------------------------------------------------------------------
130.207.219.88 NATLGAC3560C Version: 
Session:
Error: Ambiguous SNMP version []
Can't call method "close" on an undefined value at ../inc/libsnmp.pl line 411.
-bash-3.2$

So, any pointers on how to resolve this?  Currently, I've removed the new switches from the seedlist so that NeDi will continue to run for our other devices.  It seems like there should be some sort of error-checking to ensure $session is set before calling close() so that it skips the offending device and doesn't just kill the scan for other devices.  But that aside, any suggestions as to how I can figure out why the version is not being set?  I'm using just standard SNMPv1 on everything.

Thanks,

--
Will

spiffturk

  • Guest
Re: Ambiguous SNMP Version []
« Reply #1 on: July 24, 2009, 09:19:44 PM »
Minor update:  I've temporarily hacked together a solution.  in the Enterprise routine, just before the call to Net::SNMP->session(), I added this:

Code: [Select]
if (! $main::dev{$_[0]}{sp}) {
        $main::dev{$_[0]}{sp} = 1;
}

Crude, but it fixes my issue.  I guess I'll do some hunting later on to try to find where {sp} is being set so I can figure out why it's not being set correctly on its own.

--
Will

rufer

  • Guest
Re: Ambiguous SNMP Version []
« Reply #2 on: July 27, 2009, 09:13:08 AM »
What IOS are you running? SNMP on 12.2(50)SE was unusable for my 3560 because the MIBs had a loop in it.

Greetings
Rufer

spiffturk

  • Guest
Re: Ambiguous SNMP Version []
« Reply #3 on: October 15, 2009, 09:18:04 PM »
What IOS are you running? SNMP on 12.2(50)SE was unusable for my 3560 because the MIBs had a loop in it.

Yep, it's 12.2(50), though SE2.  I'm now coming back to this issue, because my earlier fix isn't really a fix.  It kept NeDi from dying, but NeDi didn't find anything on the afflicted device.  I was hoping that the newer code, 12.2(52)SE would fix this, but no dice.  If it's an actual bug in Cisco's SNMP implementation, I'd be happy to submit it for a fix--but I'd need some help hammering out exactly what the bug is.

What do you mean by the MIB having a "loop"?  Is it something we can work around?  Specifically, I'm trying to get it to detect CDP neighbors, but NeDi doesn't seem to even attempt it.  I can pull this information directly from the switch via SNMP, so I know it's capable of providing the information, but somewhere in the code, NeDi decides not to attempt it (verified by a packet trace and a strategically placed "print" statement where it would normally be detecting neighbors).

Anyone care to offer a hint?  I'd be happy to cough up some verbose output if it would be helpful.

Thanks,

--
Will

spiffturk

  • Guest
Re: Ambiguous SNMP Version []
« Reply #4 on: October 19, 2009, 08:44:02 PM »
Another step forward:

I think the problem may be the sysobj definition for the 3560E (1.3.6.1.4.1.9.1.796.def), at least in part.  For testing purposes, I replaced the 3560E's .def with the 3560's-- magically, it seems that connected phones are now found.  This is admittedly not a final solution, but it's definitely a step in the right direction.  I'll do some experimenting to see if I can narrow down exactly which part of the definition is thwarting me but this should at least get me up and running with the 3560Es at the base level.

Currently, the following values differ between the two .def files:
Type, Icon, Serial, IFdupl, IFduix, Halfdp, Fulldp, Modesc, Moclas, Movalu, Modhw, Modsw, Modfw, Momodl, Temp.

I don't know which (if any) of those would impact NeDi's probing of CDP, but it seems something in there does.  As I said, I'll experiment and see if I can figure out which specific one it is.  If I come up with anything, I'll post back here in the hopes that it'll help someone else down the line (or perhaps it could be fixed the the official .defs-- whichever).

--
Will

ralto

  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: Ambiguous SNMP Version []
« Reply #5 on: April 30, 2010, 12:44:57 PM »
Hi,

have the same problem, any solution?