Ethernet Networkig

Ethernet Networking in a Nutshell:

First, we have to understand how Ethernet works. For a nicely summarized history as well as an explanation of the type of media it can run on, you can click here.

Assuming everything is on the same network....... When a computer wants to talk to another computer on your network it 'listens' to see if there is any other traffic on the wire it is attached to. If it detects that it is all clear, it will send its traffic. Sometimes (and the likelihood increases the more computers you have on your network and the more heavily it is used) two hosts will send their data at the same time. When this happens, a collision occurs. When a collision is detected, a timer starts on each of the hosts which must expire before it will attempt to send traffic again. Meanwhile, while this is happening, the user staring at the monitor is busy complaining about how slow the network is.

Now, when host 'A' tries to access a resource from host 'B' for the first time it will send a broadcast to every host on the network asking for host 'B' to tell it where it is at. All the rest of the hosts on the network will receive this broadcast, look at the request, and decide "He's not talking to me" and purge the request from its NIC memory buffer. Host 'B', however, will say "Oh, that's me!" and respond with it's MAC address. Host 'A' will then write that address into its address resolution protocol (ARP) cache, and from that point on when 'A' wants to talk to 'B', it will attempt to talk directly to 'B' by using its MAC address. If all your hosts are attached to hubs, you begin to run into a problem. Why? Because a hub broadcasts all information that it receives

in a port (that's a physical port on the device, not the layer 4 tcp/udp port) out of *all* of it's ports. That means that every time a computer tries to send or request information, all the computers attached to the hub get it. Every host that the traffic is *not* destined for, has to examine the traffic, say "Nope, not for me" and discard it. Not only does this consume processor cycles, but the wire stays full on even moderately utilized networks. Remember, the wire has to be 'empty' before a host can send traffic. Because of this, 30 is about the practical limit of hosts that you can stick together on hubs without segmenting your network. More than that, and your network will crawl along so slowly, you might as well pack a lunch before trying to access a network resource.

A switch (or switches) eliminates much of this problem because it is a little bit smarter than a hub. Rather than burp out traffic that comes in on a port out all the ports, when 'A' tries to talk to 'B' using it's MAC address, the switch knows which port that 'B' is plugged into, and only sends the traffic out that port. This greatly reduces the likelihood of collisions and speeds up your network considerably. Why, you might ask, does this only reduce collisions and not eliminate them entirely? It's because of how ethernet works. Ethernet still depends on broadcasts for a lot of things. That first time 'A' tries to find 'B', it's still going to send a request to all nodes on the network asking "Where is host 'B'?". Now, on a small network this broadcast traffic isn't enough to cause significant slow downs. Simply replacing your hubs with a simple layer 2 switch(es) will increase your network preformance dramatically.

What happens, however, when you have a large network? At some of the sites I'm responsible for, I have over six hundred workstations trying to talk to a dozen servers. That's a lot of broadcast traffic! Even though the sites are switched, enough broadcast traffic is generated by those machines to impact network performance. This problem is solved by using a slightly smarter swtich. One that can create virtual local area networks or VLAN's. Essentially, by creating two VLANs on a switch, you split