Ethernet switching in a nut shell
Ok, I'll qualify this right away by saying that this has nothing to do with security. Having read some of the posts lately, however, I believe it may be of help to some members here. There is no way I can possibly cover everything here, but I will try to hit some of the highlights.
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 recieve 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 recieves 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 the switch in half and create two virtual switches. All the hosts on VLAN 1 will only talk (and broadcast) to the hosts on VLAN 1. The same goes for the hosts on VLAN 2. So, if I have at a site a dozen users who access the AS 400, I can put them on their own VLAN with the AS 400 so that when they broadcast for AS 400 services, the other 588 users don't get that broadcast. Cisco switches using the proprietary ISL protocol can support 1000 VLANs. Many standards based switches can support even more! This is a great way to keep your broadcast traffic under control. VLAN's are a wonderful thing!
Ok....now what happens if VLAN 1 needs to talk to VLAN 2? Hmmmmm.....now we have a problem. The simple solution is to plug in a "router on a stick" or a router that that has interfaces on both VLAN's. This isn't the best solution though, because switches switch must faster than routers can route. So there is even a more intelligent breed of switch. Layer 3 switches. L3 switches combine the functionality of a router built into the switch. This way, you can route traffic between VLAN's, without having all that broadcast traffic clogging up your network. Of course, with this kind of control, comes blood pressure raising price tags.
So.....I've skipped volumes of info trying to keep this short. Hopefully, it helps clarify a little bit about the benifits of hubs/switches/intelligent switches. If anyone is interested, I'd be happy to do more on layer 4-7 switching and/or spanning tree.
Re: Ethernet switching in a nut shell
Quote:
Originally posted here by thread_killer
If anyone is interested, I'd be happy to do more on layer 4-7 switching and/or spanning tree.
Yes Please!
