Identify where "rogue" switches are connected to

[pc_sg]

Hi!
Maybe this is an already answered question, but haven't find it.
I need to identify where "rogue" switches are connected in our LAN.
Rogue means unmanaged switches used to increase available port in areas where official LAN is not well or enough distributed (but not only, so "rogue")
If anyone ask why we in ICT don't know them, it depends on some anarchy of employees and relevant responsible, and past carelessness of old ICT chiefs...


I supposed Population is the answer, but i present only in few reports (i.e. Reports - Combination) but is not easy to use.
And seems that Population hold all MAC detected on a given port from the first discovery of each device, and is of course too much, I need a shorter period, even current situation.


Else I must do a switch by switch MAC address table export and consolidation, a really huge work.


Maybe NeDi is able to do the same in a simpler way, or maybe a artfully query in the NeDi database.


Could anyone help me?


Thanks in advance!

[Hannu Liljemark]

Does population count decrease if you run scheduled maintenance to delete old nodes from the DB?

We've used three ways to find rogue switches, but you're probably familiar with them all:

Reports->Nodes->"Node distribution" -> "Nodes / Port"
Reports -> Devices -> "device connections" -> "Neighbor undiscovered"
Monitoring -> Events -> Discover events (class like ned%)

And next step would be to deploy 802.1x to manage what gets connected to the network...

Br,
Hannu

[pc_sg]

Quick brief reply: never done a maintenance. Tested right now, some problem with authentication (root, nedi uses a nedi.conf use and password) and then another possible error "ERROR 1186 (HY000) at line 3: Binlog closed, cannot RESET MASTER".


I'll do a look to your advices, maybe from next monday (we have a short vacation starting this evening    ) the I'll report here.

Thanks a lot!

[Hannu Liljemark]

Looks like we're still using the script from this thread:

http://forum.nedi.ch/index.php?topic=1446.0

I need to look into implementing the current contrib/nedi_db_maintenance.sh

[pc_sg]

Indeed I used the one in "contrib".


The "production" NeDi is still the 1.5.225, I had always trouble doing an upgrade through NeDi web interface, and doing it manually always need a database rebuild, so all history lossing.
Maybe the script in this release is not the latest one?
Should I use the one in 1.6 ? Is it compatible?

[Hannu Liljemark]

The 1.6 html/log/Readme.txt has the following tip if you can't update via web interface:

> "nedi.pl -i updatedb" updates the DB from 1.5.225

So you can just backup nedi.conf and seedlist, then untar the tgz contents over your old files, maybe move new nedi.conf and seedlist to somewhere else and then restore the production nedi.conf and seedlist. Finally diff the old and new nedi.conf to see what has changed and then do the updatedb thing to update the database.

I've now switched to contrib/nedi_db_maintenance.sh and it seems to work ok once you modify the dbpass logic (use the stuff that's commented out, which grabs the dbpass from nedi.conf) and remove mysql's --ssl parameter if it doesn't work (or fix mysql to make it work). I think it's safer to use the script that comes with the same Nedi version as table names might have changed. The http://forum.nedi.ch/index.php?topic=1446.0 script was also pretty good with 1.5.225 and I think it also cleaned up the rrd files, where as nedi_db_maintenance.sh only does DB maintenance as its name implies.

Br,
Hannu

[pc_sg]

Thanks!
I saw the strange "root instead of nedi.conf dbuser" access mod in the distributed file. If I don't remove the root part in fron of the relevant line it give errors.


But even modified, it shows some other errors.
    "ERROR 1227 (42000) at line 2: Access denied; you need (at least one of) the RELOAD privilege(s) for this operation"
so a gave all rights to "nedi" db user.


Then
    "ERROR 1186 (HY000) at line 3: Binlog closed, cannot RESET MASTER"


 and then


    "nedi.chat       optimize        note    Table does not support optimize, doing recreate + analyze instead"
but next
    "nedi.chat       optimize        status  OK
and the same for all the other tables


Then no messages like a "done", it remains like hanged until I press enter...


Anyway nodes table now seems cleaned.


Other advices?


Thanks again!

[Hannu Liljemark]

We've just ignored the error regarding missing "RELOAD" permissions as it didn't seem important, but I think I have not seen this "RESET MASTER" error.

Now that the nodes table is clean from old legacy, do you see if it helped with the original mac address # per port issue at all?

[pc_sg]

Yes and no.
Not exactly...
No and yes!


After the database cleaning the nodes report showed on some switched and port a abnormal number of nodes seen (max was 190 on a sigle port!).


After some time (now apprx 4 hours later, so more then 16 discoveries, one on every 15 minutes) the same report shows much, much less nodes/port, and a reasonable amount of nodes per port and per device.


If this is true and stable, should be reliable enough to detect where "rogue" switches are connected to.


Thanks a lot for your adivice!

(Once more: how often is fine to run the cleaning script using crontab?  [size=78%])[/size]

[Hannu Liljemark]

We run the cleaning script once a week every Saturday, but the network is rather small (<50 MB database).