Welcome, Guest. Please login or register.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - sjwk

Pages: [1] 2 3
Discovery / Re: arpwatch data mostly missing
« on: February 18, 2015, 06:46:58 PM »
Actually, not good. 

Ok, I can't quite work out what parameters I should call nedi.pl with any more.
Back with 1.0.9, I used -vop (with -vopb once per day to backup switch configs), which worked fine.

Looking at the output with 1.4, those options crawled the switches from the seedlist via CDP (virtually all Cisco switches), it read in (but didn't do anything with) the arpwatch data, and based on what you've said above, used the local arp cache on the server to populate IP addresses.

Removing -o, so just having -vp, it crawls all the switches and updates them and their interfaces fine, but does nothing at all with the arpwatch data.

If I change that to '-vpN arpwatch' (or '-vopN arpwatch'), it again reads the arpwatch data but this time actually parses it and loads it to the database.  However, it then doesn't discover the switches. It seems to check them for interface address changes and that's all.  The run takes <1 minute rather than 3-4 minutes, and all devices now show 'discover obsolete' as they've not been updated in several hours.

Actually, looking in the code, it does exit after calling ArpWatch()if -N used, so am I right in thinking I should run it twice, using -vp to update switches, then -vN arpwatch to update nodes? (maybe only parse arpwatch data less often than polling switches?)

Discovery / Re: arpwatch data mostly missing
« on: February 18, 2015, 12:17:12 PM »
OK, seems I was calling it with -o, but without '-N arpwatch'...

Now looks good!

Discovery / Re: arpwatch data mostly missing
« on: February 17, 2015, 12:42:04 PM »
OK, my PerlFu is rusty, but in this chunk (from inside libmisc::ArpWatch()):
                        if(!exists $amc{$mc} or $ad[2] > $amc{$mc}{'time'}){
                                $amc{$mc}{'time'} = $ad[2];
                                &Prt("ARPW:$mc ".localtime($ad[2]) );
                                        my $oui = GetOui($mc);
                                        &Prt(" $oui ");
                                        if($mc =~ /$misc::border/ or $oui =~ /$misc::border/){
                                                &Prt(" matches border /$misc::border/\n");
                                        }elsif($oui =~ /$misc::ouidev/i or $mc =~ /$misc::ouidev/){
                                                &Prt(" matches ouidev /$misc::ouidev/\n");
                                                $nad += CheckTodo($mc,$ad[1]);
                                        } else {
                                        $amc{$mc}{'ip'} = $ad[1];
                                        $amc{$mc}{'name'} = ($ad[3] and $main::opt{'N'} !~ /-iponly$/)?$ad[3]:'';
                                        &Prt(" $amc{$mc}{'ip'}\t$amc{$mc}{'name'}\tOK\n");
(note: I added an else clause here to the if/elsif in order to ensure a '\n' was printed, or the output is unmanageable!)

what is the if ($_[0]) on line 4 of the above matching on?  It seems to be entering that stanza for each record, then not matching the if or elsif inside, so doing nothing, and not initialising the values that are subsequently being used (on line 1529):
                $arp{''}{$mc}{''}{$amc{$mc}{'ip'}} = $amc{$mc}{'time'};

edit: also $oui when printed is '?' for all records.  Nedi does appear to be reading in the oui data.

Discovery / Re: arpwatch data mostly missing
« on: February 17, 2015, 11:35:26 AM »
Ah.  Looking in the output from nedi.pl, I'm seeing rather a lot of errors (about as many as there should be entries in the arpwatch file in fact... - that'll teach me to just grep the output for 'arp' rather than look properly...)

Around 21,000 or so of (inside ArpWatch()):
Use of uninitialized value in hash element at /var/nedi/inc/libmisc.pm line 1529.
Followed by an equally large amount of (inside MapIp()):
Use of uninitialized value $i[0] in concatenation (.) or string at /var/nedi/inc/libmisc.pm line 745.
Use of uninitialized value in concatenation (.) or string at /var/nedi/inc/libmisc.pm line 745.
Use of uninitialized value in concatenation (.) or string at /var/nedi/inc/libmisc.pm line 745.
Use of uninitialized value $i[0] in concatenation (.) or string at /var/nedi/inc/libmisc.pm line 748.
Use of uninitialized value in concatenation (.) or string at /var/nedi/inc/libmisc.pm line 748.

So I think we can assume that's why there's virtually no data!  But why do 10 nodes read fine and the rest fail?

Discovery / arpwatch data mostly missing
« on: February 16, 2015, 07:28:21 PM »
Evening all,
I've upgraded (via a clean install and wipe of the DB) to 1.4.  Since then, nedi is mostly ignoring data in the arpwatch file.  It claims to read it:
ARPW:Reading /var/lib/arpwatch/full.dat
ARPW:21297 arpwatch entries used
Yet there are only 10 nodes (and 10 records in the nodarp table) that have IPs, all the rest just have the IP  Have checked the MAC addresses for a number of nodes missing an IP, and they do exist in the arpwatch data file, with an IP associated.
Oddly, the only IPs that are included are on a 192.168 subnet range that we do use, but which isn't the primary real-world network address range.  Even if for some reason it was just filtering to that subnet, there are a lot more than 10 nodes in that subnet in use.  I can't see any real pattern to those 10 - a mix of physical and virtual machines, running both Windows and Linux systems.

Will have a look through the code and try to work out what it's doing, but just in case I've missed some configuration option that configures what address range to pull from the arpwatch data?  As far as I can see the only arpwatch configuration option is the path to the data file?

GUI / Re: Interfaces with >100% capacity
« on: March 05, 2014, 01:01:23 AM »
I do run with -v - no error lines for those counters, or for that switch.  Although that's the current run.  I don't keep historic output, so no way of looking back at last night's discovery output to see if there errors on that particular run.

Fingers crossed a one-off...  Makes sense though that if one discovery run failed for whatever reason and stored zeroes, the next would have this symptom.  Will keep an eye on it.

GUI / Interfaces with >100% capacity
« on: March 04, 2014, 09:54:58 AM »
Had an oddity last night.  On one switch (Cisco 2960), all interfaces simultaneously showed stupid amounts of traffic.  (highest was 6333% of capacity).  Graph of that interface showed it was supposedly running at almost 800Mb/s over the 10 minute polling period (it's a 100Mb/s interface).  Is there any way to see what went on?

As far as I can see, Nedi reports it's using 64bit counters for that switch (as with all the others), output from discovery confirms this and flags no errors.  The switch has only been up for 46 days, and  even if it was the counters wrapping, I wouldn't expect every single interface to wrap at the same time.  First thought there were high amounts of broadcast traffic although not matching the time of the excessive traffic.  But seeing similar activity on all interfaces on all switches so that's probably normal.  No similar spikes on any of my other switches, including switches connected directly to this one.

As far as I can see, it generated this spike on all interfaces that have been active since the switch started, including interfaces that don't appear to have been active at the time, but interfaces that have never had anything connected had no spike.

Anyone have any thoughts?

Discovery / Re: Two Cisco switches showing no traffic
« on: January 24, 2014, 11:20:02 AM »
Just an update that deleting the device caused it to start using SNMP v2.  Worth bearing in mind that it's a good idea to delete devices if they've been replaced with different models!

Discovery / Re: Two Cisco switches showing no traffic
« on: January 24, 2014, 10:04:56 AM »
Thanks, that's pointed me at the right part of the output!
As you suspected, it is generating errors:
ERR :64bit-in The requested entries are empty or do not exist

Ah.  it also does seem to be connecting with SNMP v1, which is decidedly odd, as the device definition wants to use v2HC - it's the exact same definition as used on all the other identical Cisco 2960s, and those are connecting with v2.  The SNMP configuration is identical on the switches themselves.  If I use the 'test 64bit counters' on that switch in the 'edit def file' view from that switch, it works fine, so it just seems to be the scheduled discovery task that is wrongly using v1.

Looking in the database, the snmpversion value for both of these switches is 129, while all other switches have 130.  Also noted that the 2900 doesn't support 64bit counters - or at least the 64 bit counter test gave no values for that switch (like I say, don't care about that one)

Speculation: this particular 2960 replaced an old 2900, although different model, MAC address, serial number and probably name (can't remember whether I had renamed the old one before it was replaced).  Would that account for it?  Perhaps if it already had a database entry telling it to use v1 for that IP, it continued to do so even after the switch was replaced?  Strange thing is, I replaced 4 old switches with new 2960s and this is the only one misbehaving.

I've just deleted the switch from Nedi, will see if it is working after the next scan.

Thanks for the help.

Discovery / Two Cisco switches showing no traffic
« on: January 23, 2014, 06:58:24 PM »
Weird one here.  I have two switches (one last Cisco 2900, one 2960) showing no traffic on any port in the Device-Status view.  Ignoring the 2900 as it's about to be replaced, and probably isn't set up right, all other 2960s work fine and are, on the whole, identically configured (same credentials, same SNMP).  While not all switches are running the exact same version of IOS (12.2.55), there are two others running that same version.

All other data on the misbehaving 2960 is there - it shows interfaces as active, lists the devices connected, shows CDP neighbours and VLANs etc.  But the inbound/outbound counters for all interfaces on that switch just show as zero, and consequently the active interfaces report shows all ports as inactive (as that appears to use traffic to distinguish active vs inactive). If I launch the realtime traffic graph popup for one of the ports, it shows live traffic data.  Looking at the interface stats on the switch shows incrementing counts.

Actually, the values for in/out octets, errors and discards are all zero (although there may be no errors/discards in the 10 minute poll interval), although the broadcast counter does show values.

Any suggestions where to look to see why this particular switch is not playing ball?

GUI / Re: Bugs, fixes and suggestions
« on: January 21, 2014, 04:54:41 PM »
One more glitch+fix - a number of the image files in .../html/img had the wrong permissions (0700) in the archive so were giving broken link placeholder images.

chmod -R go+r html/img
from the nedi root folder to grant read access to group+other.

GUI / Bugs, fixes and suggestions
« on: January 20, 2014, 11:36:58 PM »
Loving the new look and new features in 1.0.9.

One minor bug - the 'Devices Full' report is incorrectly showing the contact information in the 'Total IF' column - a simple fix:  .../html/inc/librep.php:1463 (in function IntActiv), change $r[2] to $r[3]

And a suggestion (not strictly GUI):
Could the arpwatch data parsing use the timestamp field to pick the most recent entry as the current address rather than the one latest in the file?  Arpwatch will update the timestamp of an earlier (in the file) entry without moving it to the bottom of the file - as a result I have lots of nodes showing up with 'current' IP addresses that date back to when they hadn't been registered/authenticated, or had been using an auto-assigned address when disconnected before getting issued with proper IPs.

I've had a quick poke at misc::BuildArp but I'm not sufficiently caffeinated to tackle that tonight, will update if and when I find time!

Definition Files / Re: - Cisco SG300
« on: January 20, 2014, 11:17:40 PM »
As to the ID, I should have a fix in the next version...That System name is at, right?

Yes, that looks right.  And the value is "" for OIDs matching the other, normal, devices.


Definition Files / - Cisco SG300
« on: January 20, 2014, 05:32:49 PM »
In case it's helpful to anyone, I've modified the bundled definition for - the Cisco (-rebranded Linksys) SG300-10:

I added:
These let it read the system description, and the list of configured VLANs
I also changed to:
as the supplied value was giving me the wrong firmware - it stores two firmwares - active and fallback.  However, details of the firmware turn up multiple times (for instance under and but not sure how to determine which of the two firmware slots is active.  I guess there's another OID that identifies which of the two slots is set as active, but not sure how to get Nedi to read a different OID depending on which version is active.  It probably is not possible, and probably not hugely important anyway...

I also changed DisPro from LLDP to CDP as with LLDP it was giving me errors on every scan where I had two of these devices connected together, whereas using CDP appears to work fine:
LLDP sees 64d814604688,gi9 with unusable IP on gi9

Would there be any reason why using LLDP vs CDP for discovery would be preferable?

I also note that these switches advertise themselves via both LLDP and CDP with their MAC address as their device ID, and their name as the System Name, whereas all other devices I have advertise themselves to neighbours with their name as the device ID.  This confuses Nedi as it can't pair up '64d814604688' (for instance) with the actual device.

Fortunately we only have a couple of these!

GUI / Re: IF graph thumbnails mostly empty in Device-Status view
« on: October 14, 2013, 06:14:45 PM »
That's embarrassing, I never thought to look at the actual numbers... :-)

The numbers are fine (attached).  If I set the graphs to large, they work.  Whether I set them to medium or to small, they show up as blocks exactly the same size - the ones seen in the attachment in the original post were set to medium.

Other graphs do change size when set to small vs medium in the profile - the ones on Monitoring-Health for instance are a lot smaller when set to small in the profile than on medium, but the ones in Device Status are the same size.


Pages: [1] 2 3