- Nav-users - lister.unit.no

Patching forgetSQL on Python 2.5/2.6
by Morten Brekkevold 22 Mar '10

22 Mar '10

Hi all, forgetSQL is an unmaintained piece of shi^H^Hoftware that NAV versions up to 3.5 depend on. While we have removed this dependency from the coming NAV 3.6, some will experience warnings when running NAV under Python 2.5, and outright failures on Python 2.6, due to problems with the forgetSQL module. The forgetSQL module raises string exceptions in three places, and these are deprecated in Python 2.5, and not supported in 2.6. You may see error messages such as these: /var/lib/python-support/python2.5/forgetSQL.py:212: DeprecationWarning: raising a string exception is deprecated raise "NotFound" or File "/var/lib/python-support/python2.6/forgetSQL.py", line 212, in __new__ raise "NotFound" TypeError: exceptions must be classes or instances, not str I'm attaching a quick forgetSQL patch I've written to overcome these problems until NAV 3.6 has reached a stable release. -- Morten Brekkevold UNINETT

2 1

automatic Switch configuration rediscovery
by Rudolph Bott 19 Mar '10

19 Mar '10

Hi List, is there a way to trigger some sort of automatic device rediscovery? We recently changed a lot of ports on our cisco 4500 series switches to trunk mode and although this happened more than 2 weeks ago, NAV still does not reflect these new settings in the switch overview/IP Device Info. Is NAV even supposed to see these kind of changes or might I be hitting a bug? We are currently using NAV 3.5.4 - I know its not the latest release but at least its close to it ;-) On top of that I couldnt find any hints regarding this problem in the latest changelog. -- Mit freundlichen Grüßen / with kind regards Rudolph Bott

2 3

Angående uoverenstemmelser med det vi har fra NAV
by kadaffi.nasir＠hil.no 19 Mar '10

19 Mar '10

Hei Jeg stusser på tidsrommet på det som ble registert av nav og det vi har mottatt fra CERT: Tidsrom: 2010-03-16 21:33:36.26 - 2010-03-16 23:13:18.90 (UTC) Maskin: 158.36.199.6 [] Kontaktet: 195.244.8.148 på 1311/tcp (442 TCP SYNs) Det som er registert på NAV er: 158.36.199.6 00:15:c5:a4:d1:cd 2010-03-17 10:34 2010-03-18 05:35 på den gitte IP-adresse, og at den mac-adressen som er oppgitt fra NAV er registert med en annen IP-adresse på den gitte tidsrom: 158.36.196.163 2010-03-17 10:41 2010-03-18 01:26 00:15:c5:a4:d1:cd 2010-03-16 20:43 2010-03-16 23:29 2010-03-15 21:27 2010-03-15 23:13 2010-03-14 16:27 2010-03-14 21:59 2010-03-12 07:42 2010-03-12 07:59 2010-03-11 17:57 2010-03-11 23:43 2010-03-10 17:57 2010-03-11 01:15 158.36.196.163 2010-03-15 19:13 2010-03-15 21:29 00:15:c5:a4:d1:cd 2010-03-11 11:42 2010-03-11 17:43 Har dere mulighet for å se hva som har skjedd her? Mvh Achmad Kadaffi Nasir Førstekonsulent / IT-Tjenesten Høgskolen i Lillehammer / Lillehammer University College 2626 LILLEHAMMER NORWAY Telefon +47 61288181

2 1

Occasionally hardware changes for no reason
by Stokkenes Vidar 16 Mar '10

16 Mar '10

Hello everyone, Ever since we installed NAV, we've had a couple of switches that occasionally report a change in hardware versions for no particular reason. The output of the email is the following: <snip> This is an automatically generated message from NAV: Hardware version changed to: V09 from: 14 </snip> Does anyone know why this would happen? These come from switches with 1 year++ uptime where the IOS or hardware version hasn't been touched for half a year. We also have switches that report sudden date changes, such as the following (in Norwegian): Dette er en automatisk generert melding fra NAV: Boks switchname.domain.com (XXX.XXX.XXX.XXX) har gjennomført en coldstart: Gammel oppe siden: 1970-01-01 01:00:00 Ny oppe siden : 2010-01-15 12:16:21.863+01 Could this be a defective mainboard battery? Or is it simply NAV playing tricks with me :( Any help would be appreciated :-) Best regards, Vidar Stokkenes Helse Nord IKT

2 1

Log-engine, timestamp
by ronny.raudstein 11 Mar '10

11 Mar '10

I have installed NAV 3.5.5 on Centos 5.4, and followed the instructions by Roger Aas. Think this has been an issue in earlier versions too. The log engine seems to timestamp the syslog messages when the cisco.log file is parsed rather than when the message is generated on the device. Messages in cisco.log has correct timestamp. Look at the sample below: Cisco.log Mar 7 11:27:45 host: Mar 7 2010 11:27:47: %SEC-6-IPACCESSLOGP: list fraDMZ denied tcp x.x.x.x(2173) -> y.y.y.y(9100), 1 packet NAV - Syslog Analyzer 2010-03-07 11:27:00 host SEC-6(6)-IPACCESSLOGP 'list fraDMZ denied tcp x.x.x.x(2171) -> y.y.y.y(9100), 1 packet' Regards, Ronny Raudstein Kvinnherad Kommune

2 1

Announcement: NAV 3.5.5 released
by Morten Brekkevold 11 Mar '10

11 Mar '10

NAV 3.5.5 is now available for download at Launchpad: https://launchpad.net/nav/3.5/3.5.5 This release fixes 17 bugs in NAV 3.5. The log of all changes to the 3.5 series is attached to this message. A binary package for Debian 4 and 5 (Etch and Lenny) will be made available as soon as possible. The Debian package is maintained by Morten Werner Forsbring, on commission From UNINETT. At the same time I would like to apologize for lack of responses to mailing list posts the last few months. We were hoping to have NAV 3.6 ready by now, but everything has been delayed due to the fact that I was away from work for more than two months (beginning around 20th November). Happy NAVing everyone! -- Morten Brekkevold UNINETT

4 9

Installing NAV on CentOS, new installation guide
by Roger Aas 25 Feb '10

25 Feb '10

I have now made available a new version of the installation guide of NAV on CentOS (a Red Hat Enterprise Linux clone). It is based on the latest versions of NAV and CentOS available. You will find it on this link on MetaNAV: http://metanav.uninett.no/installingoncentos5 Please give me feedback if you find any errors or omissions. Or if you just want to thank me for making this guide. Best regards, Roger Aas Atea AS

2 1

Jabber dispatcher clogs the whole alertqueue
by Ingeborg Hellemo 05 Feb '10

05 Feb '10

We have used the jabber dispatcher since december. We soon discovered that our XMPP-server implementation (Openfire) sometimes freeze. It does not crash completely, but takes forever to answer connections. When this freeze happens and NAV tries to send an alert via jabber, the whole alertqueue clogs up and no alerts gets sent at all - no email, no sms, nothing. When the jabber-daemon is restarted all the backed up alerts are sent right away. (This of course happened during the holidays and we have disabled the jabber dispatcher ever since.) Is it possible to add a timeout or something to jabber_dispatcher.py to prevent this to happen? --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg.hellemo(a)uit.no Dep. of Information Technology --- Univ. of Tromsø

5 4

Observing Voice VLAN enabled ports?
by Stokkenes Vidar 05 Feb '10

05 Feb '10

Hello everyone, I am wondering if anyone have found a way to use NAV to see if a certain port is voice vlan enabled? I submitted a LP ticket about this quite some time back, but I didn't receive a reply or any feedback on it (https://bugs.launchpad.net/nav/+bug/362233) Typically we have VoIP-people dropping by our office asking "Is Port44 on switch-2.hostname.com voice enabled, and which voice vlan?" I thought maybe IP Device Info would show this in forms of another vlan, but it doesn't. It would be to great value for us atleast :-) ------------------------------------------------------ Vidar Stokkenes

1 0

Module mapping problems
by Geir Inge Jensen 02 Feb '10

02 Feb '10

Hi, I thought I should give NAV a tryout in a large service provider network. After some initial problems fetching the device information for some devices (had to remove the OSPF oid) I was finally up and running. I had to add all my device types but that was easily done (I have mostly Cisco 7600 and 7300 series devices). However, NAV has a huge problem trying to figure out which module each port belongs to (especially the 10Gb ports). Attached is a device info screen grab of one of my modules (module 5), and as you can see NAV things the module has ports from module 1, 2, 4 (and 5) as well as loopbacks and vlans. Other parts of NAV seems to get things correct (the explorer) however because of these problems they can't detect where the port connects to (link type "none"). Which sadly makes NAV useless. Is there a way I can fix this? Whenever the device info is able to pinpoint which module the port belongs to it is also able to detect the device the port connects to (including the 10Gb ports). However, that seems to be the exception and not the rule. FYI, the screen grab is from a 7609 running SRD1. Regards, Geir Inge Jensen

1 0

Netmap issue
by Andrey Gordon 18 Jan '10

18 Jan '10

Hi all, I'm checking out NAV and I can't seem to get Netmap to display properly. It come up in a ginormous size. Here is an example: http://picasaweb.google.com/Andrey.Gordon/Nav#5427047978054828082 I'm not sure where to start. Running on Debian 5.0.3 Any advice is much appreciated... ----- Andrey Gordon [andrey.gordon(a)gmail.com]

2 1

New user, cron error, some confusion, debian lenny-test packages
by Nils Olav Fossum 11 Jan '10

11 Jan '10

Hi, Something must have stopped over night as I have gaps in cricket graphs and all lines in netmap have gone grey. Im not sure if this has was the case at previous nights. Im using the lenny-test packages on Debian Lenny. Running "/usr/share/cricket/collect-subtrees normal" as navcron I get these messages: --- snip --- Error and the lines leading up to it: [06-Jan-2010 11:45:17 ] Retrieved data for 10.0.20.2 (): 0,0,45486572,20045736,17856320 [06-Jan-2010 11:45:17 ] Retrieved data for 10.7.0.11 (): 0,0,0,0,48601868,6105112,2442848594 [06-Jan-2010 11:45:18 ] Retrieved data for 10.7.0.9 (): 9,8,81827916,35395284,1346517318,26 Use of uninitialized value in split at /usr/share/cricket/collector line 274. [06-Jan-2010 11:45:18*] Could not find any datasources for target type 10.7.0.10. [06-Jan-2010 11:45:18*] No data retrieved. Skipping RRD update. --- snip --- And the list goes on. This is the line in usr/share/cricket/collector: 274 my(@targetDSs) = split(/\s*,\s*/, $ttRef->{'ds'}); I hope someone can give me a clue where to look.. mvh Nils Olav Fossum

2 3

installation on ubuntu 9.04
by vvatikiotis＠gmail.com 07 Jan '10

07 Jan '10

Hello all, I'm trying to install nav on ubuntu 9.04 and this fails cause of 2 (only 2) dependency failures. a) python < 2.5. 9.04 has python 2.6. b) postgress = 8.1. Ubuntu has postgres 8.3 Is it necessary to pin these 2 dependency versions ? I have knowledge of python but I'd assume that 2.6 is good enough against 2.5 source code. Same goes for postgres Correct me if I'm wrong. In the mean time I'l try to force install nav. btw, seems VERY promising. thx all vassilis

4 4

Temperature OID on SW, how to exclude it from cricket
by Jan I. Ellertsen 06 Jan '10

06 Jan '10

Hello all I have an issue with SW boxes, and nav/cricket tryes to collection data from an not existing oid 1.3.6.1.4.1.9.9.13.1.3.1.3.1 We use Catalyst 3560E switches as core building switches, and therefor I want to put them in SW mode for having them on the netmap. Does anyone know where I set that I do not want that OID polled on a 3560 switch ? -- Regards; Jan I. Ellertsen phone w:+4755584009 f:+4755584070 desk:+4755584201 e-mail: Jan.Ellertsen(a)uib.no - IT-Dept, University of Bergen.

2 2

Possible maintainers of a Redhat/EPEL NAV package
by Stokkenes Vidar 25 Nov '09

25 Nov '09

Hello everyone, This is probably a very delicate request, so I'll try to keep myself short. Due to our companys policies, we are trying to run everything in production on Redhat Linux servers. This is a problem when it comes to NAV, as the maintainer of the old Redhat RPM package is MIA, and no one else have really stepped forward to continue his work. I am aware of that compiling NAV from source is a viable option for someone, but considering I'm a repository maniac I would like to see Redhat on a somewhat "public" Redhat repository. We are currently undermanned and don't really have time to develop or maintain the package ourselves. However we do have resources to hire an external consulant to make the package for us. So therefor I am wondering. Lets say we hire someone to get NAV packed for Redhat Linux and submit it to EPEL, are there anyone more RPM/EPEL experienced than me who are interested in maintaining and committing new changes to the package? I've already contacted consulants at (Linpro) Redpill and gotten a time/cost estimate to develop the package. Now I just need someone volunteers to maintain the package once it's been initially set up (preferably people with commit access on EPEL) Any help or inputs would be appreciated! Best regards, ------------------------------------------------------ Vidar Stokkenes Networking Consulant Networking and telecom Department Helse Nord IKT - Tromsø Phone: (+47) 76 16 61 87 or (+47) 77 66 99 55 Cell: (+47) 95 87 99 42 e-mail: vidarst(a)hn-ikt.no

1 0

Cabling and patch data removed in NAV 3.6?
by Vidar Faltinsen 13 Nov '09

13 Nov '09

nav-users, As you might know there is ongoing work on preparing a NAV 3.6beta. In 3.6 there are some changes to the database, i.e the interfaces will now relate directly to the netbox (switch or router), not to a module. We will still keep module information, but the strict mapping from interface to module is changed. This effects a number of front end (and back end) tools and we are in the process of updating it all. One system that is effected is the seed database subtool where you can add data on your twisted pair cabling and your patches from switch to jack in the wiring closets. We are seriously considering _not_ to maintain/keep this tool from 3.6. Our feeling is that _not_ many people use this part of NAV. It has never given full effect since the machine tracker does not include these data in its search results (which has been our intention of course). We also argue that by using sensible interface description naming standards you will in effect document the same data. I.e. if you set the jack number and room number as description of the switch ports that are patched to your end users/offices you have these data. The "details" link under interface in the MAC search results in machine tracker give this information (it displays the interface view of ip device info). In my opinion you should in fact do this documentation as part of your interface description, because this is useful when working directly with the switch through the CLI. Should you then double the work and do it both in the seed database patch register in addition?... Another argument is that other systems do cabling documentation more comprehensive. NAV has i.e. no support for documenting your fibre cabling. A system like Telemator (http://www.mxdata.no/) or equivalent cabling information systems do this better. Looking at integration between these systems and NAV is of course interesting. I know the University of Tromsø has done some interesting work here. Yet another mishap with the NAV patch register is that when you replace your switch with a new one, you will in the process loose your patch data for the switch and will have to do this registering from scratch again. So people out there - who is going to miss the patch and cabling part of NAV? Best regards, - Vidar

1 0

Re: EdgeCore ES4612 no port info
by Morten Brekkevold 10 Nov '09

10 Nov '09

On Mon, 09 Nov 2009 14:49:55 +0200 Kostua <kostua(a)innkom.zp.ua> wrote: >> I hope I will find something useful from the getDeviceData.log that >> can tell me why this happens. >> >> > ok, done. sending attachment. [...] > Nov 08 10:34:57 2009 172.16.2.49_13 CGW_DEVHANDLER-4-PROCESS_CGW Oidkeys [ifDescr, ifSpeed] are required, but not supported by 172.16.2.49, type ES4612, unable to fetch data! This tells me that the OID profile of the device is lacking, for some unknown reason. Please browse to Toolbox -> Report and search for 172.16.2.49 in the "IP Device Report" search box. What is the number in the "snmp" column? What is the list of oidkeys reported when you click on the number in the snmp column? To make getDeviceData re-profile the device, browse to Toolbox -> SeedDB -> IP Devices Edit, find 172.16.2.49 and edit it. Don't change anything, just click the "Update" button and finish the procedure. To speed things up, you can then restart getDeviceData. Tail getDeviceData.log and verify that you get several log messages from OID_TESTER about 172.16.2.49. When the messages stop appearing, please check the snmp column in the IP device report again. -- mvh Morten Brekkevold UNINETT

1 0

Re: EdgeCore ES4612 no port info
by Kostua 06 Nov '09

06 Nov '09

Ok. I recently moved NAV from vmware to dedicated server, and Cricket began to draw traffic graph. In "IP Device Info" show right numbers of ports (8) but port status of all ports indicated "Not active"

2 1

FYI: FreeBSD and XMPP
by Ingeborg Hellemo 21 Okt '09

21 Okt '09

In case someone wants to configure XMPP on FreeBSD the correct python-library to install is net-im/py-xmpppy (not net-im/py-pyxmpp...) --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg.hellemo(a)uit.no Dep. of Information Technology --- Univ. of Tromsø

1 0

Re: VS: Radius service monitor
by Istvan Bernath 16 Okt '09

16 Okt '09

Thanks for the kind reply! Right now all our active switches are registered in NAV. There are about 130 pcs. 2510-48 and a couple of 2600-8, 2610, 2626, 2650, 2810 and 2824. The core switches are two 5406 and a single 5412. Traffic data is collected from the switches correctly. Statistics are presented fine via Cricket. Alerts, like firmware upgrade and cold start, are all noticed via Alert Manager as it should. Topology right now is totally missing, but luckily I've cached a hint of topology with a single 2824 in the middle and one 2626 one 2650 and a 2510 as the neighbors before my colleague, sorry to say, have updated to the latest firmware. The magic surely was, that the 2824 had a complete CDP and LLDP implementation in the old firmware, while all the new HP firmware has only a crippled Receive Only CDP implementation. The missing topology is rather crucial since we can be flooded by SMS and mails in case a box at the top fails. MAC information is collected, so it is possible to find a MAC number belonging to an IP number, but the MAC is not associated to any switch port, so we can not trace MAC, and use Arnold. Service monitoring is rather important for us, since our server people do need a better identification of a functioning server than a simple ping. Needless to say that a process can fail while the server still is pingable. Right now we are monitoring DNS, HTTP, IMAP, SMB, SMTP with success. The only service we are missing, for the time beeing, is the RADIUS. If I can help the developers with any tests, I would be more than happy to do it! Thanks again! Istvan >>> Morten Brekkevold <morten.brekkevold(a)uninett.no> 10/15/09 11:14 AM >>> On Fri, 02 Oct 2009 12:12:41 +0200 "Istvan Bernath" <ibe(a)life.ku.dk> wrote: > Sorry about the inconvenience! > > I've been on the sidelines in the past 3 years, receiving all > messages from the nav-users list and running a maintained and > updated test installation all that time. > > To my pleasure this time it will be official, and the Faculty of > Life Sciences, Copenhagen University gives NAV a chance as the > global monitoring tool of all the new HP 2510 switches our net is > now upgraded to. Music to my ears. Although I'm curious as to how NAV will perform on an all HP network. We've had some problems with HP in the past. Not all of them are completely behind us, but they hopefully will be in NAV 3.6. > Monitoring of several services will also be crucial. NAV's service monitoring capabilities have been somewhat downplayed by UNINETT, due to lack of resources. We've left maintenance of those systems in the capable hands of the University of Tromsø. Hopefully, their developers can answer your questions, as I don't know radius or the service monitor all that well. I've prodded one of their guys to look at your servicemon question. > I have though problems with monitoring the Radius service, and booth > topology and MAC behind a port do not work with the new HP ProCurve > switches. Your topology problems are intriguing. Are you experiencing a total lack of topology information, or just plain wrong topology? I've had reports of the latter from other HP-heavy installations. Are you able to search any MAC data for any of your switches? > I hope somebody can help me rectifying the last problems. It might take some Q&A, but hopefully we can be of assistance :) -- mvh Morten Brekkevold UNINETT

3 2

Re: VS: Radius service monitor
by Istvan Bernath 15 Okt '09

15 Okt '09

Sorry about the inconvenience! I've been on the sidelines in the past 3 years, receiving all messages from the nav-users list and running a maintained and updated test installation all that time. To my pleasure this time it will be official, and the Faculty of Life Sciences, Copenhagen University gives NAV a chance as the global monitoring tool of all the new HP 2510 switches our net is now upgraded to. Monitoring of several services will also be crucial. I have though problems with monitoring the Radius service, and booth topology and MAC behind a port do not work with the new HP ProCurve switches. I hope somebody can help me rectifying the last problems. Kind Regards Istvan

2 1

EdgeCore ES4612 no port info
by Kostua 15 Okt '09

15 Okt '09

Hello nav users! When adding a new device EdgeCore ES4612 not provide information about activity at the ports. At Home > Reports > Switch ports: indicated only ifindex, module and port. via snmp everything looks fine: %snmpwalk -v2c -c some 172.16.2.49 ifSpeed IF-MIB::ifSpeed.1 = Gauge32: 1000000000 IF-MIB::ifSpeed.2 = Gauge32: 1000000000 IF-MIB::ifSpeed.3 = Gauge32: 1000000000 IF-MIB::ifSpeed.4 = Gauge32: 1000000000 IF-MIB::ifSpeed.5 = Gauge32: 1000000000 IF-MIB::ifSpeed.6 = Gauge32: 1000000000 IF-MIB::ifSpeed.7 = Gauge32: 1000000000 IF-MIB::ifSpeed.8 = Gauge32: 1000000000 IF-MIB::ifSpeed.9 = Gauge32: 1000000000 IF-MIB::ifSpeed.10 = Gauge32: 1000000000 IF-MIB::ifSpeed.11 = Gauge32: 1000000000 IF-MIB::ifSpeed.12 = Gauge32: 1000000000 %snmpwalk -v2c -c some 172.16.2.49 ifOperStatus IF-MIB::ifOperStatus.1 = INTEGER: up(1) IF-MIB::ifOperStatus.2 = INTEGER: up(1) IF-MIB::ifOperStatus.3 = INTEGER: up(1) IF-MIB::ifOperStatus.4 = INTEGER: lowerLayerDown(7) IF-MIB::ifOperStatus.5 = INTEGER: lowerLayerDown(7) IF-MIB::ifOperStatus.6 = INTEGER: lowerLayerDown(7) IF-MIB::ifOperStatus.7 = INTEGER: lowerLayerDown(7) IF-MIB::ifOperStatus.8 = INTEGER: lowerLayerDown(7) IF-MIB::ifOperStatus.9 = INTEGER: up(1) IF-MIB::ifOperStatus.10 = INTEGER: up(1) IF-MIB::ifOperStatus.11 = INTEGER: up(1) IF-MIB::ifOperStatus.12 = INTEGER: up(1) IF-MIB::ifOperStatus.19 = INTEGER: up(1) Any idea ?

2 5

VS: Radius service monitor
by Stokkenes Vidar 02 Okt '09

02 Okt '09

For some reason Istvan can't seem to get this mail through to the list. So forwarding it to help him out :) -Vidar -----Opprinnelig melding----- Fra: Istvan Bernath [mailto:ibe@life.ku.dk] Sendt: 30. september 2009 10:09 Til: nav-users(a)uninett.no Emne: Radius service monitor Hi, Is there anybody that can help me with the radius service monitor? In the /var/lib/nav/log/servicemon.log logfile there are entries suggesting that the process tries to communicate with the radius server, but that is not the case. Packet capture with Wireshark shows that there are no radius packages sent to the server. [2009-09-30 09:13:44] abstractChecker.py:run:118 [Info] xxx.yyy.zzz:radius -> Failed connecting to ('130.226.xxx.yyy', 1812): 'User-Name') [2009-09-30 09:13:44] rrd.py:update:109 [Debug] Updated xxx.yyy.zzz.31.rrd Just to be sure, a request with "radtest" produces a log entry on the radius server, and the expected packages can also be captured with Wireshark. rad_recv: Access-Accept packet from host xxx.yyy.zzz port 1812, id=101, length=20 Best Regards Istvan

2 1

Radius service monitor
by ibe＠life.ku.dk 01 Okt '09

01 Okt '09

Hi, Is there anybody that can help me with the radius service monitor? In the /var/lib/nav/log/servicemon.log logfile there are entries suggesting that the process tries to communicate with the radius server, but that is not the case. Packet capture with Wireshark shows that there are no radius packages sent to the server. [2009-09-30 09:13:44] abstractChecker.py:run:118 [Info] xxx.yyy.zzz:radius -> Failed connecting to ('130.226.xxx.yyy', 1812): 'User-Name') [2009-09-30 09:13:44] rrd.py:update:109 [Debug] Updated xxx.yyy.zzz.31.rrd Just to be sure, a request with "radtest" produces a log entry on the radius server, and the expected packages can also be captured with Wireshark. rad_recv: Access-Accept packet from host xxx.yyy.zzz port 1812, id=101, length=20 Best Regards Istvan

1 0

Uplink not show ( switches Cisco )
by jean.tomaz.da.silva＠gmail.com 17 Sep '09

17 Sep '09

Hi, Using "IP Device Info" the information about "Uplink" not is appear in the switch's Cisco. So, the tool "NetMap" show switchs like "disconnected". Does you can to help ? Best Regards, Jean Tomaz

2 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nav-users