Hello,
I have problems to get mac address table from switch HP 1920. I only can get one o two mac addresses. If I launch a snmpwalk command to these switches from CLI, I get the next error:
Error: OIDs are not increasing
If i execute the snmpwalk command with -Cc, it works fine. How can I configure in NAV the -Cc option?
Thanks in advance.
On Thu, 26 Nov 2015 11:46:09 +0100 despi@datanetconsultores.es wrote:
I have problems to get mac address table from switch HP 1920. I only can get one o two mac addresses. If I launch a snmpwalk command to these switches from CLI, I get the next error:
Error: OIDs are not increasing
If i execute the snmpwalk command with -Cc, it works fine. How can I configure in NAV the -Cc option?
You can't.
Although, when using pynetsnmp as the SNMP backend, there is a possibility to add command line parameters like `-Cc` to internal functions, NAV does not provide any option to do so.
As the man page for snmpwalk warns, agents that behave illegally and return OIDs out of order can cause an snmpwalk process to loop indefinitely. You'd be better off upgrading your switch, either software- or hardware-wise.
-- Morten Brekkevold UNINETT
Hi Morten,
Unfortunately, switches are in the lastest version. I'm going to try to modify the pynetsnmp file to include the -Cc option. Do you exactly what is the file I have to modify? My NAV version is 4.3.2.
Thanks for all.
-----Mensaje original----- De: Morten Brekkevold [mailto:morten.brekkevold@uninett.no] Enviado el: lunes, 30 de noviembre de 2015 8:55 Para: Daniel Espi Climent despi@datanetconsultores.es CC: nav-users@uninett.no Asunto: Re: Problem to get mac address table from 1920 HP switch
On Thu, 26 Nov 2015 11:46:09 +0100 despi@datanetconsultores.es wrote:
I have problems to get mac address table from switch HP 1920. I only can get one o two mac addresses. If I launch a snmpwalk command to these switches from CLI, I get the next error:
Error: OIDs are not increasing
If i execute the snmpwalk command with -Cc, it works fine. How can I configure in NAV the -Cc option?
You can't.
Although, when using pynetsnmp as the SNMP backend, there is a possibility to add command line parameters like `-Cc` to internal functions, NAV does not provide any option to do so.
As the man page for snmpwalk warns, agents that behave illegally and return OIDs out of order can cause an snmpwalk process to loop indefinitely. You'd be better off upgrading your switch, either software- or hardware-wise.
-- Morten Brekkevold UNINETT
On Mon, 30 Nov 2015 11:37:11 +0000 Daniel Espi Climent despi@datanetconsultores.es wrote:
Hi Morten,
Unfortunately, switches are in the lastest version. I'm going to try to modify the pynetsnmp file to include the -Cc option. Do you exactly what is the file I have to modify? My NAV version is 4.3.2.
You could try something like the following patch:
Hi Morten,
I have applied the patch, but it shows the next error in ipdevpoll.log when I restart NAV services.
ile "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 800, in runUntilCurrent call.func(*call.args, **call.kw) File "/usr/lib/python2.7/dist-packages/nav/ipdevpoll/schedule.py", line 137, in run_job deferred = maybeDeferred(job_handler.run) File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 134, in maybeDeferred result = f(*args, **kw) File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1187, in unwindGenerator return _inlineCallbacks(None, gen, Deferred()) --- <exception caught here> --- File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1045, in _inlineCallbacks result = g.send(result) File "/usr/lib/python2.7/dist-packages/nav/ipdevpoll/jobs.py", line 233, in run self._create_agentproxy() File "/usr/lib/python2.7/dist-packages/nav/ipdevpoll/jobs.py", line 111, in _create_agentproxy self.agent.open() File "/usr/lib/python2.7/dist-packages/nav/ipdevpoll/snmp/pynetsnmp.py", line 85, in open super(AgentProxy, self).open() File "/usr/lib/pymodules/python2.7/pynetsnmp/twistedsnmp.py", line 191, in open self.session.open() File "/usr/lib/pymodules/python2.7/pynetsnmp/netsnmp.py", line 415, in open self.args = initialize_session(sess, self.cmdLineArgs, self.kw) File "/usr/lib/pymodules/python2.7/pynetsnmp/netsnmp.py", line 396, in initialize_session args = parse_args(cmdLine, byref(sess)) File "/usr/lib/pymodules/python2.7/pynetsnmp/netsnmp.py", line 378, in parse_args raise ArgumentParseError("Unable to parse arguments", toList(argv)) pynetsnmp.netsnmp.ArgumentParseError: ('Unable to parse arguments', ['/usr/lib/nav/ipdevpolld', '-Cc', '-v', '2c', '-c', 'public', '-t', '25.0', '-r', '3', '10.96.165.11:161'])
-----Mensaje original----- De: Morten Brekkevold [mailto:morten.brekkevold@uninett.no] Enviado el: martes, 01 de diciembre de 2015 12:35 Para: Daniel Espi Climent despi@datanetconsultores.es CC: nav-users@uninett.no Asunto: Re: Problem to get mac address table from 1920 HP switch
On Mon, 30 Nov 2015 11:37:11 +0000 Daniel Espi Climent despi@datanetconsultores.es wrote:
Hi Morten,
Unfortunately, switches are in the lastest version. I'm going to try to modify the pynetsnmp file to include the -Cc option. Do you exactly what is the file I have to modify? My NAV version is 4.3.2.
You could try something like the following patch:
On Tue, 1 Dec 2015 12:04:43 +0000 Daniel Espi Climent despi@datanetconsultores.es wrote:
Hi Morten,
I have applied the patch, but it shows the next error in ipdevpoll.log when I restart NAV services.
File "/usr/lib/pymodules/python2.7/pynetsnmp/netsnmp.py", line 378, in parse_args raise ArgumentParseError("Unable to parse arguments", toList(argv)) pynetsnmp.netsnmp.ArgumentParseError: ('Unable to parse arguments', ['/usr/lib/nav/ipdevpolld', '-Cc', '-v', '2c', '-c', 'public', '-t', '25.0', '-r', '3', '10.96.165.11:161'])
Yeah, it was probably a longshot. Given that `-Cc` is specific to the snmpwalk commandline program, it wouldn't work here - probably only the options documented by the snmpcmd(1) man page will work.
I think the only place this can be fixed is in the pynetsnmp library, in `tableretriever.py`. The version we're using specifically comments that it "defends against going backwards" (understandable, since an agent that misbehaves like this is _bad_).
I won't spend my time patching up third party libraries to work around bad SNMP agent implementations, so unless you can fix it yourself I would suggest filing a feature request or bugreport with the upstream project. The code is located at [1], but the library is part of Zenoss, so you would probably have to use the Zenoss bug tracker.
[1] https://github.com/zenoss/pynetsnmp
-- Morten Brekkevold UNINETT
-
Daniel Espi Climent -
despi＠datanetconsultores.es
-
Morten Brekkevold