Is there any benchmark for too many collisions? We have an IP network with Cisco Routers and Switches. Our routers are running 10meg1/2dux (as well as the switch port hooked to them). We see about 5 to 8% collisions on our Ethernet with 2meg of traffic throughput (that's all that's being sent). We are running 11.2, BGP and OSPF.
A well-behaved network should have less 50 to 100 broadcast packets per second. It's important to measure the number of packets, not percentage of bandwidth, because it is the number of packets that causes poor performance on workstations. For each broadcast packet that is received the workstations must analyze the packet at the processor. That is, the packet must be opened and data analyzed to determine if the information is destined for this workstation. If you have around 500 packets per second, studies show that workstations are losing around 10% of CPU performance as they read and analyze the broadcast packet contents.

By submitting your personal information, you agree to receive emails regarding relevant products and special offers from TechTarget and its partners. You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

There are two types of broadcasts, Layer 2 and Layer 3 broadcasts. Layer 2 broadcasts are used for applications like ARP and system discovery and are the most common broadcast type. Problems due to Layer 2 are usually solved with switches by adding more bandwidth. Inherently, there is not normally a lot of Layer 2 broadcast because it isn't used much.

Layer 3 broadcasts are far more common. In IP environments, you can broadcast the network searching for another machine. Say you have a network, 192.168.1.0/24. If you want a packet to get to all IP enabled machines, you send a packet to 192.168.1.255 and all workstations will hear and process that packet. IPX has a similar mechanism. This is what Microsoft NetBIOS will use if you do not have a WINS server in use and commonly creates a large number of broadcast packets.

So to look at some solutions:

Incorrect speed/duplex sensing First, 10MB Ethernet is always half duplex. That is what the standard specifies. There are a number of pseudo-standardized 10MB full duplex (3Com has one) solutions, but they only work under very specific conditions. (If you have 10 MB full duplex, you usually have a problem unless you have a specifically matched switch for the network interface card, again a 3Com NIC with a 3Com switch).

The most common cause of this problem is a duplex mismatch between the switch and the workstation or router. I would check the port that the router is connected to and make sure that it is 10MB half duplex. If it auto sensing, then set it to 10MB half duplex.

When you connect a device to an auto-sensing port, a system goes through a process of "flash testing" each possible connection speed and duplex. This process is less than perfect and sometimes can get it wrong, especially when you have an auto-sensing card that is carrying out the same procedure.

Cabling problems I would replace the cable on the router. Seventy percent of problems like this are caused by a faulty cable. Also change the patch lead on your Linux boxes.

Packet analysis To determine if you have a Layer 2 or Layer 3 broadcast problem, you should get a packet sniffer and have a look at the broadcast packets. Look at the source of the packets to determine what the application is. I use Network Associates Sniffer as it has an intelligent engine that will analyze the capture and report in clear English for most problems.

If you have a lot of IP and IPX network broadcasts and you use Microsoft Windows, you should implement a Microsoft WINS server and set the NetBIOS node type to hybrid mode. This stops Windows from broadcasting for name resolution.

If you have IPX as well as IP on your workstations, you should disable NetBIOS over IPX to stop name broadcasts.

If you have IPX only, you should implement IP to resolve this problem.

Otherwise, the Sniffer capture will have to be analysed by an experienced person to determine what the source of broadcasts are. Good Luck.

0 comments

E-Mail

Username / Password

Password

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy