Hi,
Is there a way to rename the 'interface'-fields on a switch?
We have some (really) old switches (Netgear FSM726) that has really long interface-names; "FSM726 Management Switch 10/100 Mbps Ethernet Network Interface 1", which kinda breaks the "Switch port status"- and "Switch port activity"-tabs on the "IP Device Info"-page of the devices in question.
Could I change this in the DB in some way? Or will it just be overwritten next time navcron runs?
On Wed, 16 Mar 2011 03:58:25 +0100 Joachim Tingvold joachim@tingvold.com wrote:
Is there a way to rename the 'interface'-fields on a switch?
Not in NAV, no.
We have some (really) old switches (Netgear FSM726) that has really long interface-names; "FSM726 Management Switch 10/100 Mbps Ethernet Network Interface 1", which kinda breaks the "Switch port status"- and "Switch port activity"-tabs on the "IP Device Info"-page of the devices in question.
Could I change this in the DB in some way? Or will it just be overwritten next time navcron runs?
We had similar issues with Cisco devices before NAV 3.6. For Cisco devices we used their ifDescr value as interface names; a typical value would be "GigabitEthernet3/2", which is way too long for the port matrix in ipdevinfo (today we use the ifName value always, which in the Cisco case would be "Gi3/2").
Before NAV 3.6, ipdevinfo had some shortening logic especially for Cisco interfaces names, which knew how to shorten "GigabitEthernet3/2" into "Gi3/2".
I might imagine some sort of generic algorithm for shortening interface names if they happen to exceed some maximum length. Something that might work in this case is to pick the rightmost word containing any digits. Wouldn't work nicely for GigabitEthernet3/2, though.
Any idea what the ifDescr values look like on this device (snmpwalk ifDescr)?
On Wed, Mar 16, 2011, at 09:42:30AM GMT+01:00, Morten Brekkevold wrote:
We had similar issues with Cisco devices before NAV 3.6. For Cisco devices we used their ifDescr value as interface names; a typical value would be "GigabitEthernet3/2", which is way too long for the port matrix in ipdevinfo (today we use the ifName value always, which in the Cisco case would be "Gi3/2").
Before NAV 3.6, ipdevinfo had some shortening logic especially for Cisco interfaces names, which knew how to shorten "GigabitEthernet3/2" into "Gi3/2".
I might imagine some sort of generic algorithm for shortening interface names if they happen to exceed some maximum length. Something that might work in this case is to pick the rightmost word containing any digits. Wouldn't work nicely for GigabitEthernet3/2, though.
Any idea what the ifDescr values look like on this device (snmpwalk ifDescr)?
It doesn't have ifName at all, so I guess NAV falls back to use ifDescr?
root@nav:~# snmpwalk -v 2c -c public sw-mgmt-cr2-x02 ifDescr IF-MIB::ifDescr.1 = STRING: FSM726 Management Switch 10/100 Mbps Ethernet Network Interface 1 [...] IF-MIB::ifDescr.24 = STRING: FSM726 Management Switch 10/100 Mbps Ethernet Network Interface 24 IF-MIB::ifDescr.25 = STRING: FSM726 Management Switch 1000 Mbps Ethernet Network Interface 25 IF-MIB::ifDescr.26 = STRING: FSM726 Management Switch 1000 Mbps Ethernet Network Interface 26 IF-MIB::ifDescr.27 = STRING: FSM726 Management Switch CPU Ethernet Network Interface
It would be hard to filter this out on a general basis, I guess, unless one use the ifIndex in conjunction with ifDescr.
On Wed, 16 Mar 2011 13:58:09 +0100 Joachim Tingvold joachim@tingvold.com wrote:
Any idea what the ifDescr values look like on this device (snmpwalk ifDescr)?
It doesn't have ifName at all, so I guess NAV falls back to use ifDescr?
Correct. If the device doesn't reply to ifName requests, NAV substitutes the ifDescr value as an ifName value.
root@nav:~# snmpwalk -v 2c -c public sw-mgmt-cr2-x02 ifDescr IF-MIB::ifDescr.1 = STRING: FSM726 Management Switch 10/100 Mbps Ethernet Network Interface 1 [...] IF-MIB::ifDescr.24 = STRING: FSM726 Management Switch 10/100 Mbps Ethernet Network Interface 24 IF-MIB::ifDescr.25 = STRING: FSM726 Management Switch 1000 Mbps Ethernet Network Interface 25 IF-MIB::ifDescr.26 = STRING: FSM726 Management Switch 1000 Mbps Ethernet Network Interface 26 IF-MIB::ifDescr.27 = STRING: FSM726 Management Switch CPU Ethernet Network Interface
It would be hard to filter this out on a general basis, I guess, unless one use the ifIndex in conjunction with ifDescr.
We could go about this another way as well. If you look at each individual switch port, NAV has assigned a port number to it, based on the port number found in BRIDGE-MIB (this number is unique across the IP device, even when it has multiple modules).
If a device doesn't reply to ifName, but a bridge port number was found, it could substitute the port number for the ifName value - only falling back to ifDescr if it's not a switch port. What do you think?
Are the port numbers NAV has found for your switch reasonable?
On Thu, Mar 17, 2011, at 15:57:44PM GMT+01:00, Morten Brekkevold wrote:
We could go about this another way as well. If you look at each individual switch port, NAV has assigned a port number to it, based on the port number found in BRIDGE-MIB (this number is unique across the IP device, even when it has multiple modules).
You are referring to dot1dBasePort, yes?
If a device doesn't reply to ifName, but a bridge port number was found, it could substitute the port number for the ifName value - only falling back to ifDescr if it's not a switch port. What do you think?
Yes, that sounds good. If this happens, maybe one should also keep the ifDescr in the «IP Device Info»-section?
Are the port numbers NAV has found for your switch reasonable?
If you're referring to «Port» in the «IP Device Info»-section, then yes, it's reasonable (it's an integer, going from 1 through 26).
Hello all,
I installed the latests nav version (nav-3.8.2) from source on OpenSuse 11.4 64 bit and used the INSTALL..rst for installation
After nav start only snmptrapd doesn't start and find no errors in the log. nlnedmon0003:/srv/local/nav # bin/nav start Starting: alertengine cricket eventengine ipdevpoll logengine mactrace maintengine networkDiscovery pping servicemon smsd thresholdMon Failed: snmptrapd
If I execute bin/snmptrapd.py this message is displayed: nlnedmon0003:/srv/local/nav # bin/snmptrapd.py Traceback (most recent call last): File "bin/snmptrapd.py", line 33, in <module> from nav.snmptrapd import agent File "/srv/local/nav/lib/python/nav/snmptrapd/agent.py", line 17, in <module> from nav.Snmp import backend File "/srv/local/nav/lib/python/nav/Snmp/__init__.py", line 35, in <module> version.verifyVersionRequirement(3, 4, 3) AttributeError: 'tuple' object has no attribute 'verifyVersionRequirement'
For pysnmp I installed version pysnmp-4.1.16a
The nav buildconf.py: """NAV build configuration variables.""" prefix = "/srv/local/nav" exec_prefix = "/srv/local/nav" bindir = "/srv/local/nav/bin" libdir = "/srv/local/nav/lib" pythonlibdir = "/srv/local/nav/lib/python" pythondir = "/srv/local/nav/lib/python" sysconfdir = "/srv/local/nav/etc" localstatedir = "/srv/local/nav/var" webroot = "/srv/local/nav/share/htdocs" webrootdir = "/srv/local/nav/share/htdocs" initdir = "/srv/local/nav/etc/init.d" crondir = "/srv/local/nav/etc/cron.d" djangotmpldir = "/srv/local/nav/lib/templates" VERSION = "3.8.2"
Mels
On 03/19/2011 11:05 AM, mels wrote:
Hello all,
I installed the latests nav version (nav-3.8.2) from source on OpenSuse 11.4 64 bit and used the INSTALL..rst for installation
After nav start only snmptrapd doesn't start and find no errors in the log. nlnedmon0003:/srv/local/nav # bin/nav start Starting: alertengine cricket eventengine ipdevpoll logengine mactrace maintengine networkDiscovery pping servicemon smsd thresholdMon Failed: snmptrapd
If I execute bin/snmptrapd.py this message is displayed: nlnedmon0003:/srv/local/nav # bin/snmptrapd.py Traceback (most recent call last): File "bin/snmptrapd.py", line 33, in <module> from nav.snmptrapd import agent File "/srv/local/nav/lib/python/nav/snmptrapd/agent.py", line 17, in
<module> from nav.Snmp import backend File "/srv/local/nav/lib/python/nav/Snmp/__init__.py", line 35, in <module> version.verifyVersionRequirement(3, 4, 3) AttributeError: 'tuple' object has no attribute 'verifyVersionRequirement'
For pysnmp I installed version pysnmp-4.1.16a
The nav buildconf.py: """NAV build configuration variables.""" prefix = "/srv/local/nav" exec_prefix = "/srv/local/nav" bindir = "/srv/local/nav/bin" libdir = "/srv/local/nav/lib" pythonlibdir = "/srv/local/nav/lib/python" pythondir = "/srv/local/nav/lib/python" sysconfdir = "/srv/local/nav/etc" localstatedir = "/srv/local/nav/var" webroot = "/srv/local/nav/share/htdocs" webrootdir = "/srv/local/nav/share/htdocs" initdir = "/srv/local/nav/etc/init.d" crondir = "/srv/local/nav/etc/cron.d" djangotmpldir = "/srv/local/nav/lib/templates" VERSION = "3.8.2"
Mels
After I set in nav.conf DJANGO_DEBUG=True, I get this message in the mail when I try login.
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py", line 100, in get_response response = callback(request, *callback_args, **callback_kwargs)
File "/srv/local/nav/lib/python/nav/web/webfront/views.py", line 86, in login return do_login(request)
File "/srv/local/nav/lib/python/nav/web/webfront/views.py", line 122, in do_login origin = reverse('webfront-index')
File "/usr/lib/python2.7/site-packages/django/core/urlresolvers.py", line 351, in reverse *args, **kwargs)))
File "/usr/lib/python2.7/site-packages/django/core/urlresolvers.py", line 272, in reverse possibilities = self.reverse_dict.getlist(lookup_view)
File "/usr/lib/python2.7/site-packages/django/core/urlresolvers.py", line 194, in _get_reverse_dict self._populate()
File "/usr/lib/python2.7/site-packages/django/core/urlresolvers.py", line 173, in _populate for name in pattern.reverse_dict:
File "/usr/lib/python2.7/site-packages/django/core/urlresolvers.py", line 194, in _get_reverse_dict self._populate()
File "/usr/lib/python2.7/site-packages/django/core/urlresolvers.py", line 162, in _populate for pattern in reversed(self.url_patterns):
File "/usr/lib/python2.7/site-packages/django/core/urlresolvers.py", line 244, in _get_url_patterns patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
File "/usr/lib/python2.7/site-packages/django/core/urlresolvers.py", line 239, in _get_urlconf_module self._urlconf_module = import_module(self.urlconf_name)
File "/usr/lib/python2.7/site-packages/django/utils/importlib.py", line 35, in import_module __import__(name)
File "/srv/local/nav/lib/python/nav/web/seeddb/urls.py", line 20, in <module> from nav.web.seeddb.views import netbox, service, room, location, organization
File "/srv/local/nav/lib/python/nav/web/seeddb/views/__init__.py", line 21, in <module> from nav.web.seeddb.views.list import netbox_list, service_list, room_list
File "/srv/local/nav/lib/python/nav/web/seeddb/views/list.py", line 24, in <module> from nav.web.seeddb.forms import NetboxFilterForm, RoomFilterForm
File "/srv/local/nav/lib/python/nav/web/seeddb/forms/__init__.py", line 18, in <module> from nav.web.seeddb.forms.edit import *
File "/srv/local/nav/lib/python/nav/web/seeddb/forms/edit.py", line 27, in <module> from nav.Snmp import Snmp, TimeOutException, SnmpError
File "/srv/local/nav/lib/python/nav/Snmp/__init__.py", line 35, in <module> version.verifyVersionRequirement(3, 4, 3)
AttributeError: 'tuple' object has no attribute 'verifyVersionRequirement'
<ModPythonRequest path:/index/login/, GET:<QueryDict: {}>, POST:<QueryDict: {u'origin': [u''], u'username': [u'admin'], u'password': [u'admin']}>, COOKIES:{'nav_sessid': 'd093027f55116d809fa88e501eb4c0c6'}, META:{'AUTH_TYPE': None, 'CONTENT_LENGTH': '37', 'CONTENT_TYPE': 'application/x-www-form-urlencoded', 'GATEWAY_INTERFACE': 'CGI/1.1', 'HTTP_ACCEPT': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8', 'HTTP_ACCEPT_CHARSET': 'ISO-8859-1,utf-8;q=0.7,*;q=0.7', 'HTTP_ACCEPT_ENCODING': 'gzip,deflate', 'HTTP_ACCEPT_LANGUAGE': 'nl,en-us;q=0.7,en;q=0.3', 'HTTP_AUTHORIZATION': 'Basic YWRtaW46', 'HTTP_CONNECTION': 'keep-alive', 'HTTP_CONTENT_LENGTH': '37', 'HTTP_CONTENT_TYPE': 'application/x-www-form-urlencoded', 'HTTP_COOKIE': 'nav_sessid=d093027f55116d809fa88e501eb4c0c6', 'HTTP_HOST': 'nav', 'HTTP_KEEP_ALIVE': '115', 'HTTP_REFERER': 'http://10.31.1.121/index/login/', 'HTTP_USER_AGENT': 'Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101203 SUSE/3.6.13-0.2.1 Firefox/3.6.13', 'PATH_INFO': u'/index/login/', 'PATH_TRANSLATED': None, 'QUERY_STRING': None, 'REMOTE_ADDR': '10.31.106.79', 'REMOTE_HOST': None, 'REMOTE_IDENT': None, 'REMOTE_USER': None, 'REQUEST_METHOD': 'POST', 'SCRIPT_NAME': '', 'SERVER_NAME': 'nav.test.local', 'SERVER_PORT': 80, 'SERVER_PROTOCOL': 'HTTP/1.1', 'SERVER_SOFTWARE': 'mod_python'}>
On Fri, 18 Mar 2011 13:58:36 +0100 Joachim Tingvold joachim@tingvold.com wrote:
individual switch port, NAV has assigned a port number to it, based on the port number found in BRIDGE-MIB (this number is unique across the IP device, even when it has multiple modules).
You are referring to dot1dBasePort, yes?
Correct.
If a device doesn't reply to ifName, but a bridge port number was found, it could substitute the port number for the ifName value - only falling back to ifDescr if it's not a switch port. What do you think?
Yes, that sounds good. If this happens, maybe one should also keep the ifDescr in the «IP Device Info»-section?
As long as an ifDescr value was found for an interface, it is stored in the db. We're only discussing alternate ways to derive an ifName value if none is found on the device.
Are the port numbers NAV has found for your switch reasonable?
If you're referring to «Port» in the «IP Device Info»-section, then yes, it's reasonable (it's an integer, going from 1 through 26).
I've posted this as a wishlist item here: https://bugs.launchpad.net/nav/+bug/739718
On Sat, 19 Mar 2011 11:05:39 +0100 mels mels@mels-kooijman.nl wrote:
Hello all,
I installed the latests nav version (nav-3.8.2) from source on OpenSuse 11.4 64 bit and used the INSTALL..rst for installation
[snip]
version.verifyVersionRequirement(3, 4, 3)AttributeError: 'tuple' object has no attribute 'verifyVersionRequirement'
For pysnmp I installed version pysnmp-4.1.16a
I see, but INSTALL.rst specifies that NAV needs PySNMP-SE, not PySNMP 4.
If you need to install PySNMP-SE from source, it can be found here: http://sourceforge.net/projects/twistedsnmp/files/pysnmp-se/3.5.2/
-
Joachim Tingvold -
mels -
Morten Brekkevold