Skip to main content

Identifying network collision over a network

More
11 years 1 month ago - 11 years 1 month ago #38208 by Arani
Hi all,

One of my customer networks is experiencing a lot of collision issues. I know exactly why it is so. Without my knowledge, the customer has introduced multiple 'hubs' (and I really mean hubs, not switches), within the network for the sake of extending the existing network. Obviously, by virtue of how a hub functions, the entire network is being flooded, thanks to the broadcast storms generated by these hubs. Unfortunately, the customer is reluctant to admit their actions.
I have to prove to them that it's these hubs which is causing all the network congestion issues.

So, long story short, what is a good managed switch, that I can use to sieve through these frames, and take some network statistics to prove that network congestion exists, and it is because of those hubs?

All suggestions are welcome, even in terms of how can I actually measure the network i.e. should I use a managed switch to take stats, or should I do something else?

Looking forward to all responses.

Cheers

Picking pebbles on the shore of the networking ocean
Last edit: 11 years 1 month ago by Arani.
More
11 years 1 month ago - 11 years 1 month ago #38209 by Nevins
Hello Arani,

Well as you know the hubs themselves will not have any reporting tools so you are going to have to use a device that does, your best option would be to add in a switch nearest to the exit router as you can.

Then use the command:

show interface ethernet [interface number]




The results should be

router#show interface ethernet 0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0010.7b36.1be8 (bia 0010.7b36.1be8)
Internet address is 10.200.40.74/22
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:06, output hang never
Last clearing of "show interface" counters never
Input queue: 1/75/1/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: random early detection(RED)
Output queue :0/40 (size/max)
5 minute input rate 1000 bits/sec, 2 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
2058015 packets input, 233768993 bytes, 1 no buffer
Received 1880947 broadcasts, 0 runts, 0 giants, 1 throttles
3 input errors, 0 CRC, 0 frame, 0 overrun, 3 ignored
0 input packets with dribble condition detected
298036 packets output, 32280269 bytes, 0 underruns
0 output errors, 10 collisions, 0 interface resets
0 babbles, 0 late collision, 143 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out





(more on troubleshooting here)
Troubleshooting Ethernet Collisions

Description and Common Causes of Incrementing Error Counters


You're going to want to see no less then 7% collisions in order to make you argument. Once you find the proof you need I highly suggest doing 2 things. The first is doing as many home runs as you possibly can eliminating points of failure and then if a wireless network exists make sure it's tied into the network separately from the physical network as close to the exit router as you can get it. This way if you need to implement port security or troubleshoot a wireless issue you don't have to deal with a ton of intermediary devices.

Good Luck,


-Nevins

Useful Threads
================================
www.firewall.cx/forum/2-basic-concepts/3...e-resource-page.html
Last edit: 11 years 1 month ago by Nevins.
More
11 years 1 month ago #38215 by Arani
Hi Nevins,

Thanks for all that info. Unfortunately, I don't have access to any of the switches on the network. So for now it will have to be introducing a host which is running something like nChronos.

Cheers

Picking pebbles on the shore of the networking ocean
Time to create page: 0.145 seconds