Nav-users

nav-users@lister.sikt.no

1379 discussions

Switch inventory isn't updated
by Bruno Galindro da Costa 15 Aug '14

15 Aug '14

At http://nav.setic.ufsc.br/report/swport, I can view my interfaces with VLANs assignments. The problem is: the information for a given netbox isn't updated. All of the jobs are running fine for that netbox (green lights in jobs list). For example: I've a set of tagged VLANs in a trunk port on that switch that isn't reported by NAV. I'll sent to Morten DEBUG logs from ipdevpolld inventory job. -- Att. Bruno Galindro da Costa

2 6

Announcement: NAV 4.1.1 released
by Morten Brekkevold 14 Aug '14

14 Aug '14

The first maintenance release of the NAV 4.1 series is now available, version 4.1.1. The source code is available for download at Launchpad [1]. A new package for Debian Wheezy has been published in our APT repository [2]. Changes ======= The following reported issues have been fixed in the new release: * LP#1052804 (NoReverseMatch error on multiple pages when adding IPv6 host with no DNS name) * LP#1316599 (NoReverseMatch exception when trying to load netmap) * LP#1333170 (Disused prefixes aren't properly deleted from the database) * LP#1338548 (Searching for an apparently "invalid" hostname crashes ipdevinfo) * LP#1339575 (Room and organization data keys cannot be added using SQL without first checking for NULL values) * LP#1340193 (NAV gets confused when re-using VLAN tags for multiple broadcast domains) * LP#1340576 (Virtual status of router addresses cycles back and forth, causing net type to swing back and forth between lan and link) * LP#1355693 (Interface names not present in linkState alert messages) * LP#1355923 (dump.py -t room crash) Please refer to the release notes [3] for further information on upgrading from versions prior to 4.1. Happy NAVing everyone! Links ===== [1] https://launchpad.net/nav/4.1/4.1.1 [2] https://nav.uninett.no/wiki/nav_on_debian [3] https://nav.uninett.no/doc/4.1/release-notes.html -- Morten Brekkevold UNINETT AS

1 0

Graphite update frequency
by Bruno Galindro da Costa 14 Aug '14

14 Aug '14

How many times NAV input data into graphite per day for a given switch port? I need to know what is the graphite update frequency of collected data of my switch ports. Is each 1 min/ 5 min...? -- Att. Bruno Galindro da Costa

3 4

Netmap showing gray traffic
by Bruno Galindro da Costa 13 Aug '14

13 Aug '14

Why netmap is showing gray traffic of my interfaces? See this print (I've removed the net prefix for security reasons): [image: Imagem inline 1] In the above example, I've put in evidence the conection beetween 251.245 and 251.247. Here are those interface graphs: *251.245:* [image: Imagem inline 3] *251.247:* [image: Imagem inline 4] -- Att. Bruno Galindro da Costa

3 9

NAV not getting LLDP information from switches
by Bruno Galindro da Costa 13 Aug '14

13 Aug '14

I've two switches: xxx.xxx.251.245 and xxx.xxx.252.121. 250.121 is connected to GigabitEthernet 1/0/5 of 251.245 251.245 is connected to GigabitEthernet 1/48 of 250.121 251.245 is a 5500G-EI 24-Port (3Com Switch 5500G-EI 24-Port Software Version 3Com OS V3.03.02s168p22 from 3com) 250.121 is a DGS-3120-48TC (DGS-3120-48TC Gigabit Ethernet Switch from dlink) All of them has LLDP enabled. This is the neighbor information on switch port 1/48 of 250.121: Port ID : 1:48 ------------------------------------------------------------------------------- Remote Entities Count : 1 Entity 1 Chassis ID Subtype : MAC Address Chassis ID : 00-1E-C1-ED-78-80 Port ID Subtype : Interface Name Port ID : GigabitEthernet1/0/5 Port Description : GigabitEthernet1/0/5 System Name : xxxxxx System Description : Switch 5500G-EI 24-Port System Capabilities : Bridge, Router Management Address Count : 1 Port PVID : 1 PPVID Entries Count : 0 VLAN Name Entries Count : 1 Protocol ID Entries Count : 0 MAC/PHY Configuration/Status : (See Detail) Power Via MDI : (See Detail) Link Aggregation : (See Detail) Maximum Frame Size : 1522 Unknown TLVs Count : 0 This is the neighbor information on switch port 1/0/5 of 251.245: LLDP neighbor-information of port 5[GigabitEthernet1/0/5]: Neighbor index : 1 Update time : 80 days,21 hours,14 minutes,30 seconds Chassis type : MAC address Chassis ID : 2810-7B68-9D90 Port ID type : MAC address Port ID : 2810-7B68-9DC0 Port description : D-Link DGS-3120-48TC R2.00.010 Port 48 on Unit 1 System name : xxxxxx System description : Gigabit Ethernet Switch System capabilities supported : Repeater,Bridge System capabilities enabled : Repeater,Bridge Management address type : ipV4 Management address : xxx.xxx.252.121 Management address interface type : IfIndex Management address interface ID : 5121 Management address OID : In NAV, the DIRECT NEIGHBORSHIP CANDIDATES reports that *another.host* is a candidate neighbor to 1/0/5 of 251.245. BUT *another.host* is physically connected in switch port 1/2 of 252.121, as reported bellow: [image: Imagem inline 3] AFAIK, Nav will use LLDP over CAM to build the network topology. But, in this case, maybe is occurring something wrong, because seems that Nav isn't collecting LLDP informations from switches to build the network topology. Another strange thing is the UNRECOGNIZED NEIGHBORS report. It is reporting that 251.245 is an unrecognized neighbor of 252.121 with lldp as source. Why?? [image: Imagem inline 4] Morten, I'll send to you by e-mail the result of these commands: root@nav:~# ipdevpolld -J topo -n xxx.xxx.252.121 root@nav:~# snmpwalk -v2c -c 1brass12 xxx.xxx.252.121 .1.0.8802.1.1.2.1.4 root@nav:~# snmpwalk -v2c -c 1brass12 xxx.xxx.252.121 .1.0.8802.1.1.2.1.3 root@nav:~# ipdevpolld -J topo -n xxx.xxx.251.245 root@nav:~# snmpwalk -v2c -c 1brass12 xxx.xxx.251.245 .1.0.8802.1.1.2.1.4 root@nav:~# snmpwalk -v2c -c 1brass12 xxx.xxx.251.245 .1.0.8802.1.1.2.1.3 -- Att. Bruno Galindro da Costa

2 6

Sysname () is already in database
by jorr＠streamguys.com 13 Aug '14

13 Aug '14

Hello, I am demoing out the NAV appliance and we have a number of physical and virtual hosts that do not have reverse DNS entries available, resolution of the IPs belonging to the hosts results in unknown.domainname.tld. When attempting to add multiple hosts to the NAV seed database, I receive errors when NAV attempts to resolve the DNS name of the host, claiming that the host already exists, despite all unique information with the exception of the failed resolution of the fqdn. Is there a work-around so that NAV does not lookup the DNS name of said devices? Sincerely, Jesse

3 4

dump.py -t room error
by Sigurd Mytting 12 Aug '14

12 Aug '14

Hi! Trying to dump rooms I get this: # /usr/lib/nav/dump.py -t room #roomid[:locationid:descr:opt1:opt2:opt3:opt4:position] Traceback (most recent call last): File "/usr/lib/nav/dump.py", line 233, in <module> main() File "/usr/lib/nav/dump.py", line 229, in main handler() File "/usr/lib/nav/dump.py", line 102, in room line.extend(['%s=%s' % x for x in room.data.items()]) AttributeError: 'str' object has no attribute 'items' Can anyone verify the same problem with Debian and UNINETT 4.1 packages? Cheers, -Sigurd

2 1

nav installation, error 500
by Alexander Zubkov 12 Aug '14

12 Aug '14

Hello. I have installed NAV on Ubuntu 14.04 using this manual: https://nav.uninett.no/wiki/nav_on_debian But when I try to connect to server with my browser, I receive "500 Internal Server Error". This is what I see in apache's error.log: [Thu Jul 31 20:59:00.541666 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] mod_wsgi (pid=938): Exception occurred processing WSGI script '/usr/share/pyshared/nav/wsgi.py'. [Thu Jul 31 20:59:00.541733 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] Traceback (most recent call last): [Thu Jul 31 20:59:00.541775 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] File "/usr/lib/python2.7/dist-packages/django/core/handlers/wsgi.py", line 206, in __call__ [Thu Jul 31 20:59:00.541851 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] response = self.get_response(request) [Thu Jul 31 20:59:00.541889 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 185, in get_response [Thu Jul 31 20:59:00.541934 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] resolver, sys.exc_info()) [Thu Jul 31 20:59:00.541980 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 232, in handle_uncaught_exception [Thu Jul 31 20:59:00.542044 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] if resolver.urlconf_module is None: [Thu Jul 31 20:59:00.542079 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] File "/usr/lib/python2.7/dist-packages/django/core/urlresolvers.py", line 360, in urlconf_module [Thu Jul 31 20:59:00.542138 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] self._urlconf_module = import_module(self.urlconf_name) [Thu Jul 31 20:59:00.542173 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] File "/usr/lib/python2.7/dist-packages/django/utils/importlib.py", line 40, in import_module [Thu Jul 31 20:59:00.542216 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] __import__(name) [Thu Jul 31 20:59:00.542249 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] File "/usr/lib/python2.7/dist-packages/nav/django/urls.py", line 22, in <module> [Thu Jul 31 20:59:00.542313 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] from django.conf.urls.defaults import patterns, include, url [Thu Jul 31 20:59:00.542357 2014] [:error] [pid 938:tid 127863399364352] [remote 192.168.0.0:8082] ImportError: No module named defaults What is wrong with my installation?

2 1

GnuPG key transition
by Morten Brekkevold 12 Aug '14

12 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1,SHA256 This is to certify that I have transitioned from my old 1024 bit GnuPG key to a new 4096 bit one (for those of you who actually care to verify my signatures on tarballs, Debian packages and e-mails). My old key will continue to be valid until I publish a revocation certificate for it at a later date, but I will only be using the new key for signatures from now on. My old key was: pub 1024D/4A5C3A44 2003-03-31 Key fingerprint = 4321 140D DC2A 7789 32A2 371D 5F12 25D2 4A5C 3A44 My new key is: pub 4096R/04D271B4 2014-07-24 Key fingerprint = 38C0 CC84 CEE3 E55E 2A07 3298 61D9 2617 04D2 71B4 To fetch my new key from a public key server, you can simply do: gpg --keyserver subkeys.pgp.net --recv-key 04D271B4 If you already know my old key, you can now verify that the new key is signed by the old one: gpg --check-sigs 04D271B4 - -- Best regards, Morten Brekkevold UNINETT -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlPqEgwACgkQXxIl0kpcOkRvBwCfUsUhbBqG607LLOS4Yirhdq2d B4gAoIEU7TgwMLS0AGY3girVFM9RAD1QiQIcBAEBCAAGBQJT6hIMAAoJEGHZJhcE 0nG09fYQAKsruDg3JIxlOfb6lPYjzRtYVh3r9fhpZ9T7daKHX5bLbTs/nw7NxqqM eUf14U1IIFI4fj190SklJFV5UR5sPdB/n3sbFMg6lZO4PJ7SwtmZ1CmIYbyHJ/7A FHtbwRX2TyIBrZNO+QF9Xh9/OtOuYrBjsFPlx7E6cUL4HProX9L+8ZfnX3MfLC0/ oOQI3/lbcthSoJyujGCnjg7Ko1e9YjU8F776rdq6YgGNdd5zHIZzV2mHgbcwGyoN z+qdOtC6ZFRc4VRTidDme7i3ywTYjsdMvhz7+ZRWV+12GBT/I6DavRGIhOWDJsx/ dyvFespk9haUX0wmYsVSTKEeJln9AJ25FxOuqorl/9j3Hfne2hMs8aLSalR6Tgva aeBIUxJTF2TA8XWmQq9366SwIBvy2/opJcaloeGGcjBgUKEFbaWoufaVLPllRFzQ kSBacUjArBY7C9jbUOdtgp2a5un1Aw+eJlCML9npTRLTWabCT8YfL2Ut2E8mWBYv hAI6fMTJhIB+kfgGLys6lU3cLHUg7wDhUkTFVPpTNbaGdsWahDUG2xQDHMHjFoWF kylHjvKBwoNfQWoFpOkWGT9R7/7nQACTXK5DoxFNmFGVeMPoBA9egY1KBPhZ6fyR bvWqDGd7dJ+/nuHofnkgzIsW11wHvKj0T3C3JiM8xmu9LBpIxgJl =TvjZ -----END PGP SIGNATURE-----

1 0

Re: NAV not getting LLDP information from switches
by Morten Brekkevold 26 Jul '14

26 Jul '14

On Wed, 9 Jul 2014 10:34:49 -0300 Bruno Galindro da Costa <bruno.galindro(a)gmail.com> wrote: > See attached files. There may be another fault lurking in here: > 2014-07-09 08:05:27,217 [DEBUG jobs.jobhandler] [topo x.x.251.245] Now calling plugin: nav.ipdevpoll.plugins.lldp.LLDP(u'x.x.251.245') > 2014-07-09 08:05:27,234 [DEBUG timestamps.timestampchecker] [topo x.x.251.245] 'lldp': timestamps appear unchanged since last run As I wrote in another post, NAV will not do LLDP processing on this device until the timestamp of the lldpRemTable changes. If the LLDP neighbors were unidentifiable on the first run, but have become identifiable at a later time, this will not be rectified by NAV until this device changes this timestamp and causes NAV to process it again. If you search for the MAC addreses using the Machine Tracker and interface reports, as I asked, and found the MAC addresses to be identifiable, you may be able to kickstart a new processing of the LLDP information by deleting NAV's stored timestamps. Something like this would do it: sudo -u postgres psql nav \ -c "DELETE FROM netboxinfo WHERE key='poll_times' AND var='lldp'" It may be a better strategy for NAV here to invalidate these timestamps on set intervals to force reprocessing of the LLDP information; just not on every run of the LLDP collector. -- Morten Brekkevold UNINETT

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nav-users