http://permalink.gmane.org/gmane.network.nav.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.network.nav.user/1144 <pre> [snip] If you've done a package upgrade on the server, you may have received a PostgreSQL update that caused the PostgreSQL server to restart. That may disturb one or more of your Apache worker processes, depending on what they were doing at the moment, so you should restart Apache as well. </pre> Morten Brekkevold 2013-05-08T07:05:19 http://permalink.gmane.org/gmane.network.nav.user/1143 <pre>I've been running NAV (3.14.15 on Debian appliance) for a few weeks without any issues but recently I started getting errors when running the Layer 2 trace tool. I tried upgrading but I guess the package for Debian hasn't been released yet... Any suggestions would be appreciated. Thank you. The error message is below: MOD_PYTHON ERROR ProcessId: 1023 Interpreter: 'nav-appliance.uninett.no' ServerName: 'nav-appliance.uninett.no' DocumentRoot: '/usr/share/nav/htdocs' URI: '/l2trace/' Location: '/' Directory: None Filename: '/usr/share/nav/htdocs/l2trace' PathInfo: '/' Phase: 'PythonHandler' Handler: 'django.core.handlers.modpython' Traceback (most recent call last): File "/usr/lib/python2.6/dist-packages/mod_python/importer.py", line 1537, in HandlerDispatch default=default_handler, arg=req, silent=hlist.silent) File "/usr/lib/python2.6/dist-packages/mod_python/importer.py", line 1229, in _process_target result = _execut</pre> Ted 2013-05-07T13:23:06 http://permalink.gmane.org/gmane.network.nav.user/1142 <pre> You're very welcome, and thank you for your kind words, though I would like to remind you that English is the official language of this mailing list. I will respond accordingly. This may correspond with the 15 minute interval of the ipdevpoll topo job, which collects CDP/LLDP and the forwarding tables of switches. I don't have any direct experience with Cisco ASA devices, but I do know that some devices have problems breathing when SNMP bulk requests are used. On Cisco, there is also the issue that we need to use multiple SNMP sessions due the way Cisco handles VLAN information using multiple VLAN-indexed communities. ipdevpoll uses a default max-repetitions value of 50 for bulk requests, which is known to cause problems with some devices. You might want to try to reduce this to a much lower number in `ipdevpoll.conf`. We've reduced this to 10 for many of our customers; for one of them we've even had to reduce it further. We're considering extending the config file to allow changing the snmp paramete</pre> Morten Brekkevold 2013-05-07T07:11:10 http://permalink.gmane.org/gmane.network.nav.user/1141 <pre>Hei, Takk for et glitrende program! Jeg har testkjørt dette hos oss i et halvårs tid, men sliter med et alvorlig og et mindre alvorlig problem: 1: Cisco ASA. Vi bruker denne serien ganske mye og i de fleste tilfeller fungerer NAV bra. Mot bokser som har 10-30 VLAN ser det ut til å gå som det skal. På bokser med mange VLAN (128+) får vi derimot en feil på SNMP-tasken hvert kvarter: 2013-05-02T11:27:18.100301+02:00 XXX &lt;164&gt;May 02 2013 11:27:18: %ASA-4-711004: Task ran for 150 msec, Process = snmp, PC = 8c4b7c8, Call stack = 2013-05-02T11:27:18.100301+02:00 XXX &lt;164&gt;May 02 2013 11:27:18: %ASA-4-711004: Task ran for 150 msec, Process = snmp, PC = 8c4b7c8, Call stack = 0x08B70783 0x08B50B1D 0x08B4F87C 0x08063B63 2013-05-02T11:27:18.100311+02:00 XXX &lt;164&gt;May 02 2013 11:27:18: %ASA-4-711004: Task ran for 152 msec, Process = snmp, PC = 8b77990, Call stack = 2013-05-02T11:27:18.100311+02:00 XXX &lt;164&gt;May 02 2013 11:27:18: %ASA-4-711004: Task ran for 152 msec, Process = snmp, PC = 8b77990, Call stack = </pre> Inge Bjørnvall Arnesen 2013-05-02T12:42:03 http://permalink.gmane.org/gmane.network.nav.user/1140 <pre> Uh, sorry about this borked release announcement. See the second, signed post for the real contents. I'll get out of your inbox now. </pre> Morten Brekkevold 2013-04-25T07:51:12 http://permalink.gmane.org/gmane.network.nav.user/1139 <pre>NAV 3.14.1592, another maintenance release of the endless NAV 3.14 series is now available for download at Launchpad: https://launchpad.net/nav/3.14/3.14.1592 This release changes some aspects of how Cricket is configured to collect traffic statistics, so we have added a couple of important upgrade notes: * The Cricket trees `switch-ports` and `router-interfaces` have been consolidated into a single `ports` tree, where all physical ports' traffic stats now also are collected. After running the usual `syncdb.py` command, you should run `mcc.py` once manually (as the navcron user) to ensure the Cricket config tree is updated right away. When everything is up and running again, you can optionally delete the `switch-ports` and `router-interfaces` directories from your `cricket-config` directory, as they are no longer used by NAV. * NAV now supplies its own `subtree-sets` configuration to Cricket. If you have made manual changes to your Cricket collection setup and/or this </pre> Morten Brekkevold 2013-04-25T07:48:20 http://permalink.gmane.org/gmane.network.nav.user/1138 <pre>NAV 3.14.159, another release of the endless NAV 3.14 series is now available for download at Launchpad: https://launchpad.net/nav/3.14/3.14.159 The release fixes the following reported issues: * LP#1155128 (IndexError crash in Machine Tracker) * LP#1158214 (mcc.py does debug logging even when configured not to) * LP#1160921 (Geomap won't load map data over HTTPS in Chrome) * LP#1161108 (Room bulk import format doesn't include geo position) * LP#1163256 (snmptrapd crashes with "interrupted system call" error) * LP#1164582 (netmap bails on fetching network graph if interface.speed missing) * LP#1165017 (Adding 0.0.0.0/0 as excepted range causes netbiostracker to hang) Please report bugs at https://launchpad.net/nav/+filebug Binary packages for Debian will be made available as soon as possible. The Debian package is maintained by Morten Werner Forsbring, on commission from UNINETT. Some people have experienced that the Debian package upgrade seems to freeze.</pre> Morten Brekkevold 2013-04-25T07:43:46 http://permalink.gmane.org/gmane.network.nav.user/1137 <pre>ok! 2013/4/15 Morten Brekkevold &lt;morten.brekkevold-GzBtVWGcKeFuMpJDpNschA&lt; at &gt;public.gmane.org&gt; </pre> Bruno Galindro da Costa 2013-04-15T11:43:00 http://permalink.gmane.org/gmane.network.nav.user/1136 <pre> That is indeed the problem. Make the navtopology process debug log by adding this line to the `[levels]` section of your `logging.conf`: nav.topology = DEBUG Using the --vlan switch to navtopology should log in detail how it descends for each VLAN from the router to the edge switches. </pre> Morten Brekkevold 2013-04-15T11:14:13 http://permalink.gmane.org/gmane.network.nav.user/1135 <pre> We always prefer that users use the bug tracker. Blueprints are mostly for planning and writing specifications for new features. Blueprints can be linked to bug reports, which means we will create them and attach them to wishlist reports if deemed useful. </pre> Morten Brekkevold 2013-04-15T11:10:13 http://permalink.gmane.org/gmane.network.nav.user/1134 <pre>NAV 3.14.159, another release of the endless NAV 3.14 series is now available for download at Launchpad: https://launchpad.net/nav/3.14/3.14.159 The release fixes the following reported issues: * LP#1155128 (IndexError crash in Machine Tracker) * LP#1158214 (mcc.py does debug logging even when configured not to) * LP#1160921 (Geomap won't load map data over HTTPS in Chrome) * LP#1161108 (Room bulk import format doesn't include geo position) * LP#1163256 (snmptrapd crashes with "interrupted system call" error) * LP#1164582 (netmap bails on fetching network graph if interface.speed missing) * LP#1165017 (Adding 0.0.0.0/0 as excepted range causes netbiostracker to hang) Please report bugs at https://launchpad.net/nav/+filebug Binary packages for Debian will be made available as soon as possible. The Debian package is maintained by Morten Werner Forsbring, on commission from UNINETT. Some people have experienced that the Debian package upgrade seems to freeze.</pre> John-Magne Bredal 2013-04-11T07:28:20 http://permalink.gmane.org/gmane.network.nav.user/1133 <pre> Hm ok. Here they are: SWITCH A: [image: Imagem inline 2] SWITCH B: [image: Imagem inline 3] Actually there is no vlan detected on ports. I think this is the problem... How can I debug this? 2013/4/10 Morten Brekkevold &lt;morten.brekkevold-GzBtVWGcKeFuMpJDpNschA&lt; at &gt;public.gmane.org&gt; </pre> Bruno Galindro da Costa 2013-04-10T12:49:23 http://permalink.gmane.org/gmane.network.nav.user/1132 <pre> Good idea. As I said in some off-list email, I'd rather you open a bugreport which Ok. When is the case to open a blueprint? Or you always prefers open a bug report to classify it as wishlist priority? 2013/4/10 Morten Brekkevold &lt;morten.brekkevold-GzBtVWGcKeFuMpJDpNschA&lt; at &gt;public.gmane.org&gt; </pre> Bruno Galindro da Costa 2013-04-10T12:31:01 http://permalink.gmane.org/gmane.network.nav.user/1131 <pre> Hi Ted, I'm guessing you're they guy who asked the same question on IRC last night. I'll repeat RockJ's answer here, just in case. The syslog analyzer only understands messages in Cisco format, and it will also attempt to truncate the log file each time is has been read (meaning it requires write access to it). It would therefore be a bad idea to point it to /var/log/messages. You should redirect syslog messages from your Cisco devices to a separate log file with the correct file permissions. That's just a pecularity of the Debian package. NAV's localstatedir is configured by the Debian package to `/var/lib/nav`, but since Debian wants the logs to go to `/var/log/nav` it symlinks `/var/lib/nav/log` to `/var/log/nav`. </pre> Morten Brekkevold 2013-04-10T10:21:33 http://permalink.gmane.org/gmane.network.nav.user/1130 <pre> If your objective is to stop NAV from talking SNMP to a device entirely, you could change its category to something that doesn't require SNMP, such as `OTHER`. As I said in some off-list email, I'd rather you open a bugreport which we would classify as wishlist priority. </pre> Morten Brekkevold 2013-04-10T10:02:27 http://permalink.gmane.org/gmane.network.nav.user/1129 <pre> Correct. No. These images only display the collected lists of VLANs allowed on the trunk ports. You need to open these ports in ipdevinfo, not in the tabular reports system. The lists of actual detected vlans, if any, on these ports should be there. </pre> Morten Brekkevold 2013-04-10T10:00:08 http://permalink.gmane.org/gmane.network.nav.user/1128 <pre>I am running NAV ver. 3.14.15 (downloaded the virtual appliance and did an upgrade) but I am unable to get the syslog part to work (as well as cricket but that I am still researching) The original logger.conf points to /var/lib/nav/log/cisco.log - shouldn't that point to /var/log/nav? Anyway I changed that to point to /var/log/messages I also had to enable in rsyslog.conf to receive UDP messages by uncommenting the lines $ModLoad imudp and $UDPServerRun 514. When I do tail -f /var/log/messages I can see that the Cisco switches are sending messages. If I try to pull up the syslog messages through NAV however it tells me that there are no messages. Any pointers would be greatly appreciated. </pre> Ted 2013-04-09T15:26:24 http://permalink.gmane.org/gmane.network.nav.user/1127 <pre> So, if I execute navtopology --l2 --vlan booth of explained actions will be executed one after the other? The uplink field in ipdevinfo requires the proper VLAN detection to have These pictures awnser your question? Switch A - Trunk port 1:24 [image: Imagem inline 1] Switch B - Trunk port 1:26 [image: Imagem inline 2] 2013/4/3 Morten Brekkevold &lt;morten.brekkevold-GzBtVWGcKeFuMpJDpNschA&lt; at &gt;public.gmane.org&gt; </pre> Bruno Galindro da Costa 2013-04-06T19:40:36 http://permalink.gmane.org/gmane.network.nav.user/1126 <pre> hmm ok. Is there a workarround to make this work without remove the device from NAV? Can I open a blueprint for it? 2013/4/4 Morten Brekkevold &lt;morten.brekkevold-GzBtVWGcKeFuMpJDpNschA&lt; at &gt;public.gmane.org&gt; </pre> Bruno Galindro da Costa 2013-04-06T00:50:07 http://permalink.gmane.org/gmane.network.nav.user/1125 <pre> Maybe, depending on what you are hoping to achieve. NAV has a maintenance scheduling tool. You can schedule maintenance tasks for entire locations, rooms or ranges of devices. Scheduling a maintenance task for a device will, however, not stop NAV from polling it. It will only stop alerts from being sent when NAV detects a problem with the a device (any "problems" will be logged, though). No. We've thought about it, but nobody has expressed any wishes for such functionality, so it has never been implemented. </pre> Morten Brekkevold 2013-04-04T09:29:23 http://permalink.gmane.org/gmane.network.nav.user/1124 <pre>Guys, is it possible to configure NAV to: 1 - ignore a single or a range of devices to be ignored from the polling process? I think this will be possible when we put it in maintenance mode. I'm right? 2 - apply per device ipdevpool's plugins intervals? According to docs, its is possible to set intervals for all devices but I hope that exists some other "hide" config to do that :) </pre> Bruno Galindro da Costa 2013-04-03T20:59:36 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.network.nav.user