I have maybe a diffrent problem This is a tail of may cisco.log file Jan 13 14:00:08 158.X.X.X 448: 1w4d: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/2, changed state to down Jan 13 14:00:13 158.X.X.X 449: 1w4d: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/2, changed state to up Jan 13 14:00:35 volda-XXX 1824540: 1y35w: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/5, changed state to down Jan 13 14:00:38 volda-XXX 1824541: 1y35w: %LINK-3-UPDOWN: Interface FastEthernet0/5, changed state to up Jan 13 14:00:41 volda-XXX 1824542: 1y35w: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/5, changed state to up The switch with the ip-adresse turn up ok in the syslog Analyzer, but the switch with the sysname turn up under parsing errors Any ideas? Peder

...

...

Wojciech Kozicki <woj@tstd.pl> 13.01.2006 11:20:39 >>> On Friday 13 January 2006 11:11, Morten Vold wrote: On 04/01/2006 14:59, Wojciech Kozicki uttered: how should be cisco box configured to have correct analyse in NAV Syslog Analyzer?

I'm sorry to say that the syslog analyzer is an ill conceived subsystem of NAV, and it is debated whether it belongs there or not. The developer that wrote it no longer works on the project, and hardly anyone I know of cares to use it (most sysadmins I know prefer to grep the log files manually).

Well, I am a console person :) But I thin that Logger module is really usefull, sometimes clicking is not so good...

With regards to your actual question, I have no idea about the required format. Cisco equipment at NTNU still logs to our NAV 2 installation, and the syslog analyzer har been rewritten from scratch in NAV 3.

From what I can see, our logs look something like this:

Jan 13 11:03:48 <router_name> 370245: Jan 13 11:03:52: %SEC-6-IPACCESSLOGP: list vlan18out denied udp <ip1>(50186) -> <ip2>(427), 1 packet

Thank You for this info.

What I do know, is that your logger.conf must point to the actual log file to pick up the log lines from. The default is /usr/local/nav/var/log/cisco.log, which means your syslog daemon must be configured to write log entries from external hosts to this file (or configure a different file name). The logengine cron job runs every minute to dump new entries from this file into the database. I also believe logengine will truncate the log file after it has been read.

This works ok, because nav has got my logs, but it puts them into error table. regards - Woj _______________________________________________ Nav-users mailing list Nav-users@itea.ntnu.no http://mailman.itea.ntnu.no/mailman/listinfo/nav-users

From morten.vold at ntnu.no Fri Jan 13 14:10:14 2006 From: morten.vold at ntnu.no (Morten Vold) Date: Fri Jan 13 14:10:08 2006 Subject: [Nav-users] Trouble with editdb and UTF-8 In-Reply-To: <200601131244.k0DCiTgk002363@duke.cc.uit.no> References: <200601131244.k0DCiTgk002363@duke.cc.uit.no> Message-ID: <43C7A6B6.6010406@ntnu.no>

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/01/2006 13:44, Borge Brunes uttered:

My input is UTF-8, so I guess that the ugly serial number ' ??!,' came from initBox.py or another of the py-script editdb use.

Ok, I took a closer look at the code, and this is what seems to be going on: 1. Editdb retrieves a list of OIDs, known to return serial numbers, from the snmpoid table. 2. It then proceeds to query the new IP device for each one of those OIDs. 3. It then interprets all the retrieved values as if they were serial numbers, and queries the NAV database to see if any devices with these serial numbers already exist in the database. What seems to be happening, is that some devices return garbage as their reply to one or more of these OID queries, and that is what PostgreSQL is choking on. You can see which OIDs are queried if you execute the following SQL on your manage database: select snmpoid,getnext from snmpoid where oidkey ilike '%serial%'; I'll try to come up with a solution to this later, as I'm a bit pressed for time right now. - -- Morten Vold, ITEA, NTNU -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDx6a2XxIl0kpcOkQRAkfmAJ9zygYxnUYhLT8uC9/Jw9aZ6Ybo8wCePRY6 MwaPOmwCQ+Z0UVeOvNUGYAA= =ne4y -----END PGP SIGNATURE-----

From morten.vold at ntnu.no Mon Jan 16 09:44:32 2006 From: morten.vold at ntnu.no (Morten Vold) Date: Mon Jan 16 09:44:34 2006 Subject: [Nav-users] Alcatel devices In-Reply-To: <200601131010.07073.woj@tstd.pl> References: <200601131010.07073.woj@tstd.pl> Message-ID: <43CB5CF0.6070802@ntnu.no>

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/01/2006 10:10, Wojciech Kozicki uttered:

anybody was successful monitoring Alcatel switches in NAV? (for example X590), especially in cricket?

I assume that you've successfully added your Alcatel switches to NAV, so that you at least have basic status monitoring? I'm no Cricket expert, but as far as I know, you'll have basic switch statistics monitored by Cricket as long as the switch supports the standard MIBs for this? If there are any special OIDs you wish to monitor and graph with Cricket, I believe you can add these to NAV by using editdb to add an snmpoid (afterward, getDeviceData should automatically test all your IP devices to see which ones support this new OID). Use 'cricket' as the description for the OID, I believe this will trigger makecricketconfig to configure cricket to collect this OID. Cc: John-Magne, for QA ;) - -- Morten Vold, ITEA, NTNU -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDy1zvXxIl0kpcOkQRAgFjAKDcjppcrP2oYl2OKHpf6mxE3ve9uwCeJTe+ 3JGiuGZz/3kDDvykbVR+jYQ= =0S9G -----END PGP SIGNATURE-----

From morten.vold at ntnu.no Mon Jan 16 11:06:28 2006 From: morten.vold at ntnu.no (Morten Vold) Date: Mon Jan 16 11:06:40 2006 Subject: [Nav-users] Trouble with editdb and UTF-8 In-Reply-To: <43C7A6B6.6010406@ntnu.no> References: <200601131244.k0DCiTgk002363@duke.cc.uit.no> <43C7A6B6.6010406@ntnu.no> Message-ID: <43CB7024.9070908@ntnu.no>

Skipped content of type multipart/mixed