Nav-users October 2006

nav-users@lister.sikt.no

3 participants
5 discussions

Installation of NAV on CentOS 4.4
by kaa＠msu.net 19 Oct '06

19 Oct '06

Hi, Tor Pretorius wrote: > Hello, > > I try to install Nav-3.1-0-1 on CentOS-4.4 and get a error > > rpm -ivh nav-3.1.0-1.noarch.rpm > error: Failed dependencies: > perl(Pg) is needed by nav-3.1.0-1.noarch This is known issue. Just add --nodep. This rpm works in the way described at http://metanav.ntnu.no/moin.cgi/InstallingOnRHEL4 > > > I have install pgsql_perl5-1.9.0 > > > > Mvh > Tor Pretorius > ITAS -- With best regards, Alexander Krapivin mailto:kaa@msu.net NOC MSUNET ICQ UIN:3967345 MSU, Moscow, Russia

1 0

Cisco port numbering, suggestions?
by morten.brekkevold＠uninett.no 12 Oct '06

12 Oct '06

Greetings everyone, This post may become rather lengthy, but if you are interested in Cisco module issues and port numbering vs. interface names, please bear with me. I would really appreciate some feedback from our users, as the changes we are implementing will affect everyone. Removing the "submodule hack" ----------------------------- This summer I worked on fixing some of the problems with module detection on Cisco equipment. There were several problems related to the fact that gDD attempts to map Cisco's submodule paradigm in to NAV's data model by assigning module number 10 to submodule 1/0, number 11 to submodule 1/1 and so forth. Apparently, there isn't much equipment that actually employs submodules, and oftentimes these modules will not be self-sustainable devices, as in the case of the 3750 Metro. The basic metro reports two submodules, the first (1/0) contains 24 Fa ports and two Gi ports, while the second (1/1) contains two Gi ports. Basically, the Metro is just one physical device, and with the code changes I've made, the Metro will appear in NAV as one single module with 28 ports. Meaning that submodules are largely ignored by NAV, which now attaches the ports of all submodules to the top module itself. Port numbering -------------- As you may know, NAV assigns port numbers to switch interfaces. I'm told this is an old convention stemming from the old CatOS CLI implementation, where interfaces only had port numbers and not names. In many parts of the user interface, NAV refers to switch interfaces only by their module and assigned port numbers. In the Cisco case, NAV assigns (or rather, used to assign) port numbers by interpreting interface names and/or descriptions. This means that Fa1/5 would become port 5 on module 1, and Fa2/0/3 would become port 3 on module 20 (!). On devices with both Fa and Gi interfaces, Cisco reuses these numbers. A module would have both an Fa1/1 and a Gi1/1 interface. NAV would assign the port number 1 to the Fa1/1 interface, and when it found the Gi1/1 interface, it would see a port numbering conflict and assign the ifindex value of the Gi1/1 interface as its port number (typically resulting in something like 10101 as its port number). With the submodule changes described above, the code will rely more on the the portIfIndex table from the CISCO-STACK-MIB [1]. This table enumerates the interfaces of a Cisco stack into modules and port numbers. For a Metro 3750, this table will actually enumerate all 28 interfaces as port 1 through 28 on module 1. I've received some criticism for this from people running NAV from the latest trunk revisions, though. Apparently, many Cisco devices will enumerate Gi interfaces before Fa interfaces, meaning that Gi1/1, Gi1/2 and Fa1/1 will become ports 1, 2 and 3 in that order. This represents a change in the port number assignments that NAV has made earlier. Previously, it would have started assigning port numbers to the Fa interfaces first (either because their ifindex values are lower, or because they sort first alphabetically). Consequently, if you upgrade your NAV installation to the trunk (or the upcoming 3.1.1 version), any switch you have that has both GigabitEthernet and FastEthernet interfaces will have its ports renumbered in NAV. The complaints I've received about this largely revolve around the fact that some users have implemented external systems that relate to NAV by referring to module and port numbers, and that this reference breaks when NAV suddenly decides to assign new port numbers. A typical example of this would be that when searching for a MAC address in the Machine Tracker before the change, you might be told a machine is connected to foo-sw, module 1, port *5*. Then you upgrade NAV, perform the same search in the Machine Tracker, and now you are told the machine in question is connected to foo-sw, module 1, port *7*. The interface name in these two cases will remain the same, e.g. "FastEthernet1/0/5" or "Fa1/0/5", but this string is not available in the Machine Tracker (yet). Numbering vs. names ------------------- Now, other feedback we've received (both internal and external) tells us that today, port numbers are largely irrelevant in real world situations. Several network engineers have told us that they care about interface names (the ones they see on the CLI, such as Fa1/5), rather than arbitrary port numbers. Their viewpoint is that NAV should place more importance on interface names than on port numbers, meaning we should put interface names in all parts of the user interface that has port numbers today, including the Machine Tracker. The NAV dev-team is leaning towards the latter solution, but this is too big a change for the 3.1.1 bug release, and we might not even have time to do it for version 3.2, which is scheduled for late October. The question is, what do you, the users, think about this? The situation, as it stands, is that a new port number assignment scheme will turn up in the 3.1.1 bug release, because of the submodule bugfix. This may confuse some people, as interface names are not readily available in many parts of the user interface. Should we try to stay with a numbering scheme compatible with the old one for the 3.1.1 release, and wait for interface names in the UI before we change the port numbers? This might delay the 3.1.1 release even further, as we need to make changes to the standing bugfix before the release. Is it okay to renumber ports in the 3.1.1 release, as long as interface names become more prominent in the UI in the 3.2 or 3.3 release? Should we prioritize more prominent interface names in the 3.2 release, or is it okay to wait until the 3.3 release? Now's your chance to influence these decisions, before further implementation takes place. [1] http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=1.3.6.1.4.1… -- mvh Morten Brekkevold UNINETT

1 1

Nav 3.0 makecricketconfig.pl error
by morten.brekkevold＠uninett.no 06 Oct '06

06 Oct '06

Erik Weber wrote, On 05-10-2006 15:39: > Still using Nav 3.0 (latest debian release, anyone know if a 3.1 is > gonna be released soon?) Actually, Morten Werner is sitting next to me working on that right now. He came up here from Oslo on Wednesday to have a little brainstom/workshop with us. He's also uploaded a preliminary 3.1 package to the official Debian unstable archives, which hopefully means that NAV 3.1 will be part of the next Debian stable release. That said, he's also backporting a 3.1 package for the current stable release. These new packages will also feature automatic database initialization and upgrades on install. > Anyway, when running makecricketconfig.pl i get this error message: > > Use uninitialized value in pattern match (m//) at > /usr/lib/nav/makecricketconfig.pl line 927 > > This happens when it process a switch named nara-sw002-01 (catalyst > 3524XL) > > Anyone know about a fix for it? I don't. But what's on line 927 of /your/ makecricketconfig.pl anyway? I'm looking at makecricketconfig.pl from NAV 3.0.1 (which is in the latest Debian package), and that line is a comment: # Write to file. -- mvh Morten Brekkevold UNINETT

1 0

Field Length of orgid
by mturczan＠nyp.org 03 Oct '06

03 Oct '06

Folks, I tried to import a record with the proper orgid set as follows: F-1196A:10.10.10.10:Org_East_Campus:SW:ro::rw:Access Layer Switch:::: And I received the following error: Syntax error: Field 'orgid' exceeds max field length I assigned the Organisation field the same way, and it seems like the field itself can hold a maximum of 30 characters. Is there another identifier somewhere that corresponds to 'orgid' in the IP Devices bulk import? Regards, Mark -------------------- This electronic message is intended to be for the use only of the named recipient, and may contain information that is confidential or privileged. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the contents of this message is strictly prohibited. If you have received this message in error or are not the named recipient, please notify us immediately by contacting the sender at the electronic mail address noted above, and delete and destroy all copies of this message. Thank you.

2 1

Mahinetracker
by odd.hauge＠hiMolde.no 03 Oct '06

03 Oct '06

Hi. A request/question? Is it possible to get the port description included in the mac search result window? Very often I need to track a machine to a specific switch port, after finding the port I need to get into the Report interface of Nav to find the description of the switch port to see who (what?) is behind the port. If the description of the switch port had been included in the mac-address search result window it would have saved me a lot of time.... - odd arne hauge

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nav-users October 2006