We updated our installation to 4.8.3 (Real Topology: some C2960 Cisco connected to a pair of Nexus)
NetMap does not work properly (missing some uplinks). We edit IP Device info and, although NAV sees there links as unrecognized and after having added those unrecognized neighbors to NAV. Connections do not appear.
Remote Name (as identified by NAV in unrecognized neighbors) is different from Sysname in the Seed Database (obtained from host file).
Any suggestions? Is it better not to use host file? Does anyone work with Nexus?
Best Regards,
Cris
On Thu, 18 Jan 2018 11:55:29 +0100 cristina.caselles@grupoversia.com wrote:
We updated our installation to 4.8.3 (Real Topology: some C2960 Cisco connected to a pair of Nexus)
NetMap does not work properly (missing some uplinks). We edit IP Device info and, although NAV sees there links as unrecognized and after having added those unrecognized neighbors to NAV. Connections do not appear.
Remote Name (as identified by NAV in unrecognized neighbors) is different from Sysname in the Seed Database (obtained from host file).
Any suggestions? Is it better not to use host file? Does anyone work with Nexus?
Hi there,
a few general questions to get my bearings:
1. You mention upgrading to version 4.8.3. Did the problems appear only after the upgrade? If so, which version did you upgrade from?
2. Do you have a DNS infrastructure, where your network device names are properly maintained?
NAV expects you to maintain a tidy DNS catalog, and does not properly support using host files, AFAIK. If DNS and your devices disagree on what their names are, you may experience problems, especially if NAV needs to resort to name matching for discovery protocol entries.
3. Is LLDP enabled throughout your network? Do you also have CDP enabled? I find it is generally not a good idea to mix the two (and CDP only makes sense in a pure Cisco environment).
We upgraded from 4.7.3 release and we are not sure that all links were correct before upgrading (newbies to NAV).
Our DNS infrastructure it is a bit untidy. What could we do? ( for instance, stopping some jobs?)
As our environment it is not a pure one we have both protocols enabled (CDP & LLDP). However the most problems are in Cisco Environment. Some discovered issues:
- Although in the NetMap view there is a switch connected to a pair of Cisco (HSRP), the IP Device Info (Neighbors Tab) only see one of these link.
- We deleted one device from BBDD and later created it again (waiting to be discovered properly). Unfortunately now the device shows none of the two links.
Any suggestions?
Thank you in advance.
Cristina
-----Mensaje original----- De: Morten Brekkevold [mailto:morten.brekkevold@uninett.no] Enviado el: lunes, 22 de enero de 2018 14:50 Para: cristina.caselles@grupoversia.com CC: nav-users@uninett.no Asunto: Re: Missing some uplinks
On Thu, 18 Jan 2018 11:55:29 +0100 cristina.caselles@grupoversia.com wrote:
We updated our installation to 4.8.3 (Real Topology: some C2960 Cisco connected to a pair of Nexus)
NetMap does not work properly (missing some uplinks). We edit IP Device info and, although NAV sees there links as unrecognized and after having added those unrecognized neighbors to NAV. Connections do not appear.
Remote Name (as identified by NAV in unrecognized neighbors) is different from Sysname in the Seed Database (obtained from host file).
Any suggestions? Is it better not to use host file? Does anyone work with Nexus?
Hi there,
a few general questions to get my bearings:
1. You mention upgrading to version 4.8.3. Did the problems appear only after the upgrade? If so, which version did you upgrade from?
2. Do you have a DNS infrastructure, where your network device names are properly maintained?
NAV expects you to maintain a tidy DNS catalog, and does not properly support using host files, AFAIK. If DNS and your devices disagree on what their names are, you may experience problems, especially if NAV needs to resort to name matching for discovery protocol entries.
3. Is LLDP enabled throughout your network? Do you also have CDP enabled? I find it is generally not a good idea to mix the two (and CDP only makes sense in a pure Cisco environment).
-- Morten Brekkevold UNINETT
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Tue, 23 Jan 2018 09:08:33 +0100 Cristina Caselles cristina.caselles@grupoversia.com wrote:
We upgraded from 4.7.3 release and we are not sure that all links were correct before upgrading (newbies to NAV).
Ok, apologies for the late feedback - I've been travelling and completely forgot about this thread.
Our DNS infrastructure it is a bit untidy. What could we do? ( for instance, stopping some jobs?)
You could clean it up, perhaps? :-)
As our environment it is not a pure one we have both protocols enabled (CDP & LLDP). However the most problems are in Cisco Environment. Some discovered issues:
That could really get you intro trouble, then. CDP packets will pass right through non-Cisco devices, rendering them invisible from the viewpoint of the Cisco devices. As an added complication, some vendors (HP is one example) can pick up passing CDP packets and reflect them in their LLDP neighbor list, causing further mayhem (this functionality is optional in HP switches, as far as I know).
I would advise against CDP in a heterogenous environment - you should preferably only be using LLDP.
- Although in the NetMap view there is a switch connected to a pair of
Cisco (HSRP), the IP Device Info (Neighbors Tab) only see one of these link.
When you say "Netmap", are you viewing a layer 2 or 3 topology map? The latter infers topology from IP layer links (based on subnet addresses), while the former is the one that cares about ethernet-based connections, as discovered through LLDP/CDP or CAM tables.
- We deleted one device from BBDD and later created it again (waiting
to be discovered properly). Unfortunately now the device shows none of the two links.
By BBDD, I assume you mean the "Seed Database" (or SeedDB) tool?
Any suggestions?
Replace CDP with LLDP. I would also clean up DNS, but it should not strictly be necessary for topology to work, as LLDP idenfication can be made from device addresses.
Please read through this guide and see what you find: https://nav.uninett.no/doc/4.8/howto/debugging-topology.html
(I see that guide needs a slight update: The "Direct neighborship candidate" report is now available directly as a hyperlink when browsing a specific port in ipdevinfo.
-
Cristina Caselles -
cristina.caselles＠grupoversia.com
-
Morten Brekkevold