Steve Kersley | 9 Oct 18:59 2014
Picon
Picon

SNMP agent down

I’m trying out the NAV virtual appliance (4.1.0), talking to 25 or so Cisco switches.  It was working fine but after a few weeks, one of the switches is showing a problem, “SNMP agent down”.  The SNMP agent is not down.  The switch is fine, its configuration hasn’t changed.  I can talk SNMP to it fine using the same credentials from other machines, and the NAV VM can talk SNMP fine to all of the other switches – all have the same SNMP credentials, and most are the same model of Cisco switch.  (I was going to test from the NAV VM or watch the network traffic but the appliance doesn’t come with the snmp tools or tcpdump, and is isolated from the Internet so not easily able to install them)

 

Restarting the switch made no difference.

 

I’ve had a rummage in the logs without seeing anything obvious.  Any clues where to look to find why NAV is unable to talk SNMP to this one switch suddenly, after working fine for several weeks?

 

Steve.

Morten Brekkevold | 13 Oct 16:42 2014
Picon
Picon

Re: Unmanaged switches

On Tue,  7 Oct 2014 22:22:45 +0200 (CEST) <pentium100@...> wrote:

> Is there a way to insert an unmanaged switch to the network map? I use some of
> them in my network and would like to mark them on the map. Right now I have
> real network topology something like this:
>
> Router -- managed switch  -- unmanaged switch -- devices
>
> Only one devices on the unmanaged switch is shown, even though multiple MACs
> are detected on the relevant port of the managed switch. Is there a way to
> mark that there is an unmanaged switch so that those devices are drawn on the
> map (with link speed/usage pulled from the devices if possible)?

Hi,

There is no way to insert an unmanaged switch into one of NAV's maps.
NAV was created solely with managed devices in mind, and no one has ever
expressed any interest in anything else.

The reason NAV has detected a device from behind the unmanaged switch as
a neighbor on the relevant port of the managed switch, is likely that
either CDP or LLDP communication has taken opalce between the two, and
these packets have passed through the unmanaged switch as if it were
invisible.

--

-- 
Morten Brekkevold
UNINETT

Corey Thompson | 1 May 17:44 2014
Picon

Integration with GIS

Before I start doing such, I'm wondering if anyone has done any 
integration between NAV and a PostGIS based GIS system (mostly using 
QGIS for "frontend"), as I would rather add to existing work rather than 
repeating it...I thinking of just creating views in postgres referencing 
NAV data for the GIS to use to retrieve device inventory, status, and 
statistics in spatial queries. If it becomes successful and useful, I 
will do a writeup.

  --
Corey Thompson
Technology Manager
East Grand Forks Water and Light
1010 5th Avenue Northeast
East Grand Forks, Minnesota 56721
218-399-3310 direct
cthompson@...

Joachim Tingvold | 27 Apr 05:50 2014

Setting up NAV from scratch/non-OVA (Graphite-issues)

Hi,

Decided to install NAV from 'scratch' (i.e. not use the OVA-package). Got NAV running fine, but had some
hiccups getting Graphite working as it should. Found no documentation on this what-so-ever (neither on
the NAV-pages, or the Graphite-pages), so had to try-and-fail some. Thought I'd share.

 - Debian Wheezy (not OVA)
 - NAV via apt (from https://nav.uninett.no/debian)
      root <at> tardis:~# dpkg -s nav|grep Vers
      Version: 4.0.1-3

1) Fixed /etc/nav/graphite.conf;
	base=http://localhost:8888/

2) Copied content of '/usr/share/graphite-web/apache2-graphite.conf' into own VHost;
	<VirtualHost localhost:8888>
	( + add NameVirtualHost + Listen in /etc/apache2/ports.conf)

3) Set 'CARBON_CACHE_ENABLED=true' in '/etc/default/graphite-carbon'
   Set 'ENABLE_UDP_LISTENER = True' in '/etc/carbon/carbon.conf'
   Set 'SECRET_KEY = <longsecretstring>' in '/etc/graphite/local_settings.py'
   Set 'TIME_ZONE = '<Gallifrey>' in '/etc/graphite/local_settings.py'

4) cd /usr/share/pyshared/graphite
   python manage.py syncdb

5) Started carbon-cache (/etc/init.d/carbon-cache start)

6) Started NAV + apache

Should work.

Some of the errors I got along the road; <http://files.jocke.no/b/nav-graphite-error.txt>.

--

-- 
Joachim
Attachment (smime.p7s): application/pkcs7-signature, 5009 bytes
Joachim Tingvold | 27 Apr 16:56 2014

Setting up NAV from scratch/non-OVA (Graphite-issues)

Hi,

Decided to install NAV from 'scratch' (i.e. not use the OVA-package). 
Got NAV running fine, but had some hiccups getting Graphite working as 
it should. Found no documentation on this what-so-ever (neither on the 
NAV-pages, or the Graphite-pages), so had to try-and-fail some. Thought 
I'd share.

  - Debian Wheezy (not OVA)
  - NAV via apt (from https://nav.uninett.no/debian)
       root <at> tardis:~# dpkg -s nav|grep Vers
       Version: 4.0.1-3

1) Fixed /etc/nav/graphite.conf;
	base=http://localhost:8888/

2) Copied content of '/usr/share/graphite-web/apache2-graphite.conf' 
into own VHost;
	<VirtualHost localhost:8888>
	( + add NameVirtualHost + Listen in /etc/apache2/ports.conf)

3) Set 'CARBON_CACHE_ENABLED=true' in '/etc/default/graphite-carbon'
    Set 'ENABLE_UDP_LISTENER = True' in '/etc/carbon/carbon.conf'
    Set 'SECRET_KEY = <longsecretstring>' in 
'/etc/graphite/local_settings.py'
    Set 'TIME_ZONE = '<Gallifrey>' in '/etc/graphite/local_settings.py'

4) cd /usr/share/pyshared/graphite
    python manage.py syncdb

5) Started carbon-cache (/etc/init.d/carbon-cache start)

6) Started NAV + apache

Should work.

Some of the errors I got along the road; 
<http://files.jocke.no/b/nav-graphite-error.txt>.

--

-- 
Joachim

davide | 22 Apr 18:36 2014

Is there a way to change the default 10 rows in the lists?

It should be useful if I can change the default 10 rows in the

"Show xx entries"

in the lists.

I searched through the configuration file and in the .js but I can't change
this.

I wish to put 50 rows or at least "all".

Thank you

Morten Brekkevold | 22 Apr 15:22 2014
Picon
Picon

Re: Manually adjust topology - [interface] table changes

On Sat, 19 Apr 2014 14:57:32 +0200 (CEST) <davide@...> wrote:

> I read https://nav.uninett.no/doc/3.15/howto/debugging-topology.html but I
> can't resolve the error in topology discovering on my network.
>
> I have some Catalyst 3550 with stackable modules that automaticaly are not
> correclty connected.
>
> I changed the [interface] table to adjust my topology and all is okay but my
> changes are lost from automatic discover.
>
> How can I permanently change the [interface] table?

You can't. All information in the interface table consists of
collected/detected information. Any changes made outside of NAV will
only be temporary.

If you would post details of your actual topology, where NAV is
mistaken, and add the details collected as described in [1], we may be
able to make a more qualified comment as to what may be happening. Feel
free to replace device names and text you would rather not divulge, as
long as you do it consistently.

[1] https://nav.uninett.no/doc/4.0/howto/debugging-topology.html#looking-for-the-missing-link

--

-- 
Morten Brekkevold
UNINETT

Morten Brekkevold | 22 Apr 12:36 2014
Picon
Picon

Re: Nav 4.0.1 trouble with nav pping service

On Mon, 14 Apr 2014 09:48:02 +0200 (CEST) Jostein Berge
<jostein.berge@...> wrote:

> Having some trouble starting pping after upgradring from 3.15 
> Running on 
> pping.log produces the following error : 
[snip]
> File "/usr/lib/python2.7/dist-packages/nav/metrics/carbon.py", line 57, in send_metrics_to 
> carbon.send(packet) 
> socket.error: [Errno 111] Connection refused 
>
>
> Anyone have solution for this ? 

Yes, this likely means the Carbon backend is not running, so NAV cannot
send its metrics to it. Please start the carbon-cache backend.

--

-- 
Morten Brekkevold
UNINETT

John-Magne Bredal | 22 Apr 09:38 2014
Picon
Picon

Re: Shutdown a port

Hi!

On 04/16/2014 01:39 PM, davide@... wrote:
> NAV 4
> 
> I can change port description or vlan in "Configure port".
> 
> How can I change the port administrative status?
> 

It is not possible to change the administrative status of the interface from
PortAdmin. The reason for this is that it simply has not been requested from the
NAV users.

The tool used for setting the interface administrative status is Arnold. The use
case for Arnold is that you have a mac- or ip-address that you want to shut out
from your network, so you search for that in Arnold and set the administrative
status of the resulting interface.

However, if you wish to manually set administrative statuses from PortAdmin,
that is something we can implement. Please register a bug for this on
https://bugs.launchpad.net/nav/+filebug and we will handle it.

regards

--

-- 
John-Magne Bredal
UNINETT AS

Morten Brekkevold | 22 Apr 13:04 2014
Picon
Picon

Re: Problem with uplink detecion

On Thu, 10 Apr 2014 12:00:24 +0000 "martin.jaburek@..."
<martin.jaburek@...> wrote:

> I can understand, that it is trying to determine the topology based on
> vlans. 
>
> How do you handle the situation when we have many vlans with different STP
> roots? Or some uplinks are limited to a subset of available vlans. 

NAV will traverse the path of each VLAN individually, starting at the
determined root router port for that VLAN. NAV does not get root
information from STP, but has detected which subnet prefix(es) are
routed on that VLAN, and uses this to detect the root router port. 

On the device connected to that router port (or on the same device, in
the case of an L3 switch), NAV will descend further on all trunks with
the current VLAN allowed, and non-trunks having this as their native
VLAN.

STP information is only used to find STP blocked ports. STP blocked
ports will not be traversed by the detector, only registered as blocked
on the VLAN that is being detected.

> Or if we have different allowed vlans from one side and the other
> side?

You mean a mismatch in the list of allowed vlans on each side of a
trunk? That would be logged as an error.

> I attached navtopology.log. I reduced it to include only three devices
> oriented messages. 
>
> They are connected:
> DEVICE_003 Te0/1 (role: vlan492 ... ROOT, vlan25 ... ROOT) <-> DEVICE_009
> Te2/2 (role: vlan492 ... DESG, vlan25 ... DESG)
> DEVICE_003 Gi0/24 (role: vlan492 ... DESG, vlan25 ... DESG) <-> DEVICE_001
> Gi1/0/9 (role: vlan492 ... ALTN, vlan25 ... ALTN)
>
> DEVICE_009 and DEVICE_001 are then connected through other switches.
>
> On webinterface ipdevinfo/DEVICE_003 there are N/A uplinks.

Do you mean to say there are _no_ uplinks listed whatsoever, or that
there are uplinks where the port name is unavailable?

> I'm not sure about rules you apply for uplink detection, maybe the log will
> help

What is the actual uplink of DEVICE_003?

According to your log, most VLANs are attempted traced through Gi0/24 on
DEVICE_003, but most of them seem to be STP blocked on this port.

If this is the actual uplink, but it is STP blocked on all VLANs, NAV
will not set a direction for the port/VLAN combination, it will set the
port/VLAN combination as blocked. If there is no information about
directionality of the link, nothing will be listed in the uplinks list.

--

-- 
Morten Brekkevold
UNINETT

Mischa Diehm | 31 Mar 12:28 2014
Picon
Picon

NAV mac-search with Nexus and FabricPath

Hi,

we have FP activated in our datacenter and use Cisco Nexus (5,6,7)k. I'm not sure what caused the problem but NAV can't find MAC-addresses on these devices and even on catalysts behind them anymore. I don't know what algorithm is used to figure out where a MAC-address is attached but maybe someone who knows can clarify what is needed for that to work?

Thanks in advance,
Mischa


-- 
Mischa Diehm | Network Operations Center (NOC)
UniBasel | UniRechenZentrum (URZ)
Klingebergstr. 70 | CH-4056 Basel
Tel. +41 61 267 1574 | http://urz.unibas.ch
Attachment (smime.p7s): application/pkcs7-signature, 2977 bytes

Gmane