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
Wojciech Kozicki email@example.com 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
I'm sorry to say that the syslog analyzer is an ill conceived
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
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
format. Cisco equipment at NTNU still logs to our NAV 2
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
file to pick up the log lines from. The default is /usr/local/nav/var/log/cisco.log, which means your syslog daemon must
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.
- Woj _______________________________________________ Nav-users mailing list Navfirstname.lastname@example.org 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.email@example.com
-----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
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.firstname.lastname@example.org References: 200601131244.k0DCiTgk002363@duke.cc.uit.no 43C7A6B6.email@example.com Message-ID: 43CB7024.firstname.lastname@example.org
Skipped content of type multipart/mixed