something is going haywire with the network. Non-managed switches throughout the school are all flashing like crazy. Gonna be fun afternnon trying to figure this one out

something is going haywire with the network. Non-managed switches throughout the school are all flashing like crazy. Gonna be fun afternnon trying to figure this one out

sounds like a loopback mate.

aye been thinking that. Been round and turned off almost all the switches in the whole school and its still goin on

Start at your core switch and remove all of the links to the sub cabinets and switches one at a time. When the crazy blink stops this should isolate it to a segment of your network at least. You can then just work your way down through the network to isolate it, unless of course the loopback is on your core.

Disconnected each segment of the network one at a time, and it slowly got better the more I unplugged. Swapped out the main switch as well. Its still looking pretty busy though. Its a flat unsegmented network so Im just wondering if its normal traffic. Although there was something up yesterday and the whole network stopped to a halt.
What would wireshark look like if i had a loopback? Can I post up a 5 minute (1.3mb) capture from the main switch for someone to look at?

Wireshark would have a whole bunch of identical broadcasts and multicasts as switched frames do not have a TTL they will keep bouncing around forever in a loopback situation. You would be looking for a whole bunch of ARP requests etc from the same bunch of hosts over and over again.
RabbieBurns (3rd September 2008)

Thanks. I dont see any of that, neither did I during the hectic time yesterday.
Last edited by RabbieBurns; 3rd September 2008 at 12:13 PM.

If you want to post that log here I should be able to have a look at it for you, might be better to email it though as because it contains the data from the packets as well as the packets itself it may contain sensitive information. PM me for my email if your interested.

Just looked through and had a few thoughts. I assume that you have at least one managed netgear switch and that you may be directly connected to it?
There seemed to be an awful lot of TCP reset packets flying around, these are usually the result of something in the traffic path reseting the connection possibly filtering or an upstream router.
There were also a lot of Netbios name querys flying about which could be ok depending on the tools in use (some software is old and ignores DNS) but could be looked into as these are being IP broadcast to the whole school. The main offenders here were:
- 10.10.10.80(00:16:76:72:d7:67) looking for BRN_A20F85
- 10.10.10.253(00:06:5b:f1:74:ff) which was looking for all sorts and generating lots of ARP requests
- SCHOOL3 - 10.10.10.83(00:10:18:19:56:54) - was spewing ARPs everywhere, oftern the same ones so this could be a loopback somewhere near that card.
The thing is that this dump only provides a small bit of the information if you are connected to the managed switch as any filtering that has been done will prevent your station from reciving all of the packets. Ideally you want to connect your machine directly to each of the unmanaged sections and check for tonnes of broadcasts there as the managed switch may be suppressing some of them. You could also do a capture on the core switch with the port that it is connected to set to mirror a diagnostic mode that will push all unfiltered traffic on the switch to your port. This is no substitute for the captures from each unmanaged section of the network through.
Hope this helps in your hunt and diagnostics.

The netgear that you are seeing is probably the point to point wireless bridges that link our three buildings.
I am plugged into a small unamaged switch with all the servers and the ADSL router, which then goes to the main core switch beside it. No managed switches anywhere, but we have just ordered one today
.253 and .83 are 2 of our servers, file server, backup DC and WSUS etc. The other one is just a client over at the junior school, im not sure what thats up to.
Our whole network is just one massive 255.255.0.0 subnet 10.10.1.x and 10.10.10.x all on the one net accross 3 buildings (not my design heh)
From what you saw, would you agree that there isnt anything like a loopback in place, and all the broadcasts are purely symptoms of having such a large flat network?

The behavior of .83 was really weird and could possibly indicate something wrong with it or software behavior that I have not encountered. Having said that it is probably not a loopback as the identical broadcasts were too far apart.
The netgear thing that I was seeing was a device constantly trying to participate in an STP election so I assumed it was a managed switch but could indeed be the point to points.
The tcp resets are more worring though as I have seen networks slow right down because of devices that were generating them, it seemed to be mostly with net traffic though.
Is there no way that your servers could be connected to a larger switch directly as this could improve the speed emencly. We had a simmilar setup where all of the servers were on a small switch and then shared a single 100mb link back to the main network. I personally put in extra cat5e to get them each their own link to the core and the speed difference was vast. This is not only because they did not have to share but because the CPU and backplane in the larger switch could switch the packets so much quicker than the little switch. The little switch incidentally also caused errors from time to time where it would lock up from the load for short periods and had to either be reset or left for 10 minutes to cool down before it would work right again.
Last edited by SYNACK; 3rd September 2008 at 03:47 PM.

Got a 48 port managed switch arriving tomorrow so will plug the servers straight into that and see how it goes.
Cheers for your help
Do those switches support any form of storm control on the ports.
I know that HP and Cisco switches you can disable a port of the input unicast/Multicast/broadcast surpasses a certain percentage of port util
Make sure spanning tree is turned on, if it is a flaky nic on the network then use WS to id the NIC and get shot of it.
Hope this helps
There are currently 1 users browsing this thread. (0 members and 1 guests)