Hubs, Switches, and Routers
Posted on October 29, 2007
Filed Under Networking
If you want to connect three devices on a 10-Base-T LAN, that crossover cable we talked about in the previous chapter just won’t cut it. It’s time to get a hub, or a switch. To paraphrase the infamous Pitr, “Hub, switch, what is difference?”
They look a lot alike: There is a row of RJ-45 jacks, sometimes called “ports.” (What’s a “jack”? It looks like the hole in the wall where you’d plug in a telephone, only bigger.) There may be some lights to tell you it’s working. There will be some way to provide electric power to it — probably a “wall wart” transformer or a small “brick.” The prices have even started to converge — you can get a modest switch for about the same money as a similar hub.
A hub is the simpler of the two. It simply connects all the devices on its “ports” together. A switch is a bit smarter; it understands when two devices (out of four, five, eight, sixteen, or even more) want to talk to each other, and gives them a switched connection.
What does “switched” mean?
A hub is like a CB radio, with devices constantly yelling “Breaker! Breaker!” and trying to talk around each other. A switched connection is like a private phone call. A switch is like a tiny telephone company that lets pairs of devices make direct connections. When you are using a switch, the only time you will see traffic from other devices is when it is (a) directed to the address of the machine you are using, or (b) when it is “broadcast” using your network’s broadcast address (again, as discussed previously).
So a switch is better, right? Well, for many purposes, yes. If you have six PC’s, and you want to transfer some big files between two of them and still be able to use the other four for other things, a switch will make a big difference in performance. But if you want to install an intrusion detection device (or a network “sniffer”) to learn about your network, you won’t see very much unless you use a hub. If you’re a student trying to learn about network protocols or an administrator with security in your job description, putting a hub in the right place is the best way to do it.
The Collision Domain
If it seems odd to you that a device can “sniff” traffic that doesn’t belong to it, you’re not alone. Ethernet was created based on a rather strange idea: The “bus,” or cable, is being shared by all the devices using it, and they work out for themselves how to share it. Unlike other networking schemes, there is no single master device to control and synchronize the Ethernet network. (Such a device would be complex, expensive, and would be a “single point of failure.” A hub may be a SPOF, but it’s a simple, cheap, and robust one.)
How do these devices work things out amongst themselves? It’s a process called CSMA/CD, Carrier Sense Multi-Access/Collision Detection. It works this way: Once a device starts to send a packet, the other devices on the bus (that’s the Multi-Access) “hear” it (Carrier Sense) and know not to transmit until the first device finishes sending its “packet.” When two devices start to talk at the same time, this is the collision that has to be “detected.” When an Ethernet device detects that it’s in a collision, it “backs off” for a random amount of time. This randomness is the trick that makes the network work without the need for a central authority — since each device waits randomly, that pretty much assures that sooner or later, one of the devices will get the bus to itself long enough to finish sending its packet. Remember, the first device only has to get control of the bus long enough to start sending a clean packet before it gets interrupted; that will make all the other devices shut up. Collisions only happen when two devices start to transmit at almost exactly the same instant, so collision detection should only come into play rarely, not for every packet. If you reach that point, your Ethernet throughput declines badly.
Yes, there is one bit of additional complexity needed to support collision detection: Ethernet devices must be able to listen while they are talking.
Collision, back-off, retransmission
In the animation, we have two NIC devices, blue on the right and red on the left. The packets they send are represented as a stream of the same color. When the “blue” NIC sees the red stream while it is transmitting its blue signal, it says “Oops!” because it knows that there has been a collision. Likewise, a few nanoseconds later the red NIC sees the blue stream, and there is a red “Oops!” Both devices then pause for a random length of time. In this example, the red NIC is the one that tries again first, while the blue one is still waiting, and so the red packet is sent without further interruption. The animation then repeats. Don’t feel sorry for the blue NIC; it will get to send its packet, eventually.
The collision domain determines how much distance an Ethernet segment — a LAN — can cover. It is calculated by figuring out how far the beginning of a packet can get before the end of the packet is sent. Once the sender has finished a packet, it can’t recover from a collision as easily; so if another computer on the same segment has not yet heard the start of the packet, collisions really become a serious problem.
By strictly limiting the length of the LAN, we can be sure that no collision will go undetected — that is, no packet will finish before its beginning has made it all the way to the other end of the LAN. We’re talking about bits moving at practically the speed of light, but also very short times, a few hundreds or thousands of nanoseconds. A “light nanosecond” is a measure of distance short enough that computer pioneer Admiral Grace Hopper used to hand out bits of wire “one nanosecond long” as souvenirs.
A big packet size gives the sending device a longer time to detect collisions. A LAN using short packets is more of a challenge, because a packet may be finished before the sender realizes it had a collision with another device. If that happens, the network becomes “flaky” and unreliable. A collision that is detected quickly enough has only a small impact on the network’s performance, because “back off and try again” is a normal function of Ethernet, supported by the electronics of the network devices themselves.
Collisions imply a network running in half-duplex like an old CB radio: “What’s your 20? Over” “I’m at the 7-11. Over” Only one device can talk at a time.
There is also a “full-duplex” mode which is more like a telephone; there are two sets of wires in use, and that allows two devices to talk at once. Collisions aren’t supposed to happen in full duplex. But you will see collisions, bad ones, if you have a duplex mismatch. That’s when you have one device in half-duplex and another device in full-duplex. The one in full-duplex never stops to listen for a quiet wire and so does not even realize that it is failing to send its packets, until a higher level protocol (the software layer) says “Hey, I’m missing some packets!” and forces the underlying hardware to send them again. Remember, a collision that is detected quickly enough is handled in hardware, but this sort of collision will cause your network performance to degrade horribly, because software is so much slower than hardware.
This is a good example of why network protocols have multiple layers — the hardware supports the software, and the software keeps the hardware honest.
To keep things simple, let’s stick with the old-fashioned half-duplex network for now.
Network cards have a Media Access Control or “MAC” address; it’s sort of like a serial number. One of the first things a new machine does when it joins a network is to say “Hi! I’m here!” to the rest of the network. This involves another protocol, Address Resolution Protocol or “arp.” The “Hi, I’m here!” message really says “Hey, if you are an intelligent switching device or router that can hear me, link my MAC address with this IP address.” The router then makes a little note that it can now handle requests directed to that IP address. If you’re looking for gory details, I recommend Interconnections by Radia Perlman.
All the devices within one segment, one collision domain, listen to all the traffic that goes by to see if their address is in the packet header. If it is, they grab the packet. If not, they ignore it. But (software being what it is), you can tell your NIC to grab all the packets that go by. This is called “promiscuous mode” and it is the first step in writing a “network sniffer” or “network analyzer.” If you run a sniffer program such as Ethereal, you will see at least the broadcast traffic for your local network — it mostly consists of machines saying “Hey, what NIC card has this IP address?” If you are using a hub, you may also see traffic that is not directed at your machine. Remember, a hub will pass all packets to all machines. It’s up to each of them to skip the packets they don’t want.
Packets of data have headers, which are like the address on an envelope. When the NIC sees its own address in the headers of a packet, the NIC sends an “interrupt” to the computer’s processor to tell it that here is a packet that needs to be handled, perhaps by copying it into memory and then transferring control to an application program such as Mozilla.
And routers…?
A router is first of all a device with two network interfaces. That matters because if you aren’t a member of a network, you can’t participate in it. One interface means one network… or does it?
It does, except that those interfaces don’t have to be physical ports — you can create one, two, or even more virtual ports that have different addresses and so can belong to different networks, and this works even if you only have one physical NIC with one port; but a good router will have the two (or more) physical NICs, plus “something” to transfer packets between them.
I’m trying to avoid bashing you over the head with the OSI Seven-Layer Model, so to sum up let’s just say that a hub provides physical connections without adding any intelligence, so the devices that are connected to it are left to work out things as best they can.
A switch adds the ability to direct packets within one network based on the MAC addresses of the devices attached to it, while a router uses the IP addresses in the packets to route them between multiple networks.
So, what is the “something”? It can be software — a Linux PC configured for IP forwarding, or a Windows PC running Internet Connection Sharing — but if you’re doing serious work, it will be a specialized chunk of hardware from a company such as Cisco, running some equally specialized software (perhaps a version of embedded Linux).
One example of a router is a so-called cable modem. It is actually a router, with one interface on the cable company’s LAN, and the other on your home LAN. In my case, that means one connector is a cable TV connector (it’s called an “F” connector; this is not the same as the BNC connector used by “thinwire Ethernet”). The one I’m using offers a choice betwwen a standard RJ-45 and a USB connection on the PC side.
(”USB?” I hear you mutter.) Yep; remember that you can make a PPP connection over a phone line? You can also run a program that will create a fake or “virtual” NIC on a USB port. Since USB is faster than a regular serial port, this should in theory be almost as good as a real NIC, all the way up to 10Mbit/sec or so, which is as much as your cable company is likely to give you. Since it depends more heavily on your operating system software, though, it sucks up resources you would probably rather use in other ways. The first time I tried a standalone USB fake-NIC, it crashed my notebook consistently. Given a choice, I’ll use the RJ-45 port, thank you!
Different cable companies handle things differently; in my case, when I set up a cable modem it used DHCP to get a dynamic address from the cable company. (Yes, the “D” in DHCP stands for “dynamic.”) To see that it worked and to check the IP address, you would run one of these commands:
- If you’re still using Windows 98, you would configure your PC to “get an IP address automatically”, reboot (duh!) and then run winipcfg from the Start button’s “Run” menu.
- In Windows 2000 or XP, pick Start, Run, cmd to get a command line window, then run ipconfig -all. It looks like this:
C:\>ipconfig -allWindows IP Configuration
Host Name . . . . . . . . . . . . : Sample
Primary Dns Suffix . . . . . . . : example.com
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : NoEthernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : NVIDIA nForce MCP Networking AdapterPhysical Address. . . . . . . . . : 00-0C-7D-7C-8A-77
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.1.8
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 192.168.1.3
If the IP address begins with “164.” that means it was not able to get an address assigned to it, and you need to try again (the command “ipconfig -renew” will do that). - In Linux or OS X, you would open a terminal window and run the command “ifconfig -a” to see “all” of your Ethernet interfaces. The output looks like this:
user@dahlgren:~$ /sbin/ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:0C:76:DF:4E:44
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7583317 errors:0 dropped:0 overruns:0 frame:0
TX packets:6809820 errors:1 dropped:0 overruns:1 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3741776557 (3.4 GiB) TX bytes:4198062528 (3.9 GiB)
Interrupt:23 Base address:0xe400lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:924697 errors:0 dropped:0 overruns:0 frame:0
TX packets:924697 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:162332257 (154.8 MiB) TX bytes:162332257 (154.8 MiB)
I consider myself lucky that I’ve not yet had to deal with a DSL setup that required “PPPoE.” If you have and you’d like to share some tips, please note that we have a discussion area over at BrassCannon.org.
If you want to share your cable connection with more than one PC, you will need another router. That can take different forms depending on your level of experience, your enthusiasm, and your budget. These are alternatives — you only need one:
- Set up a Linux PC to do IP forwarding and IP masquerade (also known as NAT, Network Address Translation). You can do this with one NIC, but it’s better with two. I’ve touched on that elsewhere in an article that needs an update.
An old 486 is quite adequate for this use, so this is essentially a no-cost solution but requires time and effort; if you’re a hobbyist, you may consider that to be an additional attraction rather than a problem. Price: Spare parts, a Linux CD, and a rainy weekend. - There used to be a product for Windows called Sygate Home Network. They’ve been bought by Symantec, though, and don’t seem to be offering it any more. Pity; it had capabilities similar to the Linux solution though the overhead of Windows meant that a small Pentium was the minimum machine required. Its successor would be the built-in Internet Connection Sharing module in Windows XP.
- Buy a dedicated hardware box such as the one from Linksys, either with a single port to “uplink” to your existing hub/switch, or with a built-in multi-port switch of its own. This is a great solution, since it also acts as a firewall to keep out rude strangers. It also means you don’t “waste” a computer. If you have a nice PC, it’s a pain to be careful about what you run on it just to avoid inconvenience to your partner(s); even if you use a crappy old 486, it still needs to be monitored and it sucks a lot of electricity compared to a simple blue box. I recommend the Linksys family of “Cable/DSL Routers” for this application. Life is too short to fuss with a whole PC for what ought to be a “toaster” (a simple “plug it in and use it” solution). Price: less than $60 for the Linksys BEFSR11 single-port version, less than $90 for the BEFSR41 which also has an integrated 4-port hub. (The prices for the hardware continue to fall.)
Firewall Features
A firewall isn’t magical; its primary job is to reject traffic aimed at services you don’t provide. That won’t protect you if you click on a nasty link that in turns asks for a Windows program that proceeds to hijack your machine and turn it into a spam-spewing zombie.
Even so, a default Windows installation prior to Windows XP Service Pack 2 would happily accept candy from strangers. Prior to XP Service Pack 2, as little as forty seconds of direct exposure to the Internet would result in a Windows PC being “owned” by a rude stranger.
XP Service Pack 2 and Windows 2003 will now do their best to ensure that you have their built-in software firewall turned on, but they also have built-in trust for certain sites and don’t warn you when a bad program on your PC tries to call out.
ZoneAlarm is a third-party (non-Microsoft) program which will warn you about unexpected traffic in both situations, inbound and outbound; this makes it a better choice. The firewall features of a hardware cable router (which goes between your PC and your cable modem) work even better, and don’t require precious PC resources.
Another advantage of the router is that it allows you to keep a log of addresses that attempt to connect to your LAN. It can even provide a warning when trojan horse programs on your computer try to “phone home.” In effect, it turns your inexpensive gateway into an intrusion detection system. If you’re running Windows, I recommend Link Logger — you can try it for 14 days before you buy it. It works with Linksys cable routers, Netgear, and some others.
Summing Up
You can set up a “gateway router” in hardware or by running software. It can protect you against outside attack and inside misuse in a number of ways, too.
Linux can be hardened to act as its own firewall using ipfilter or ipchains. It also has available an excellent intrusion detection package called snort, and there are many others.
For well under $100, I recommend a hardware router (a Linksys BEFSRxx) and LinkLogger software. If you have no money and a lot of time, though, implementing a Linux or NetBSD solution is educational as well as effective.
I have used each of the above at different times and for different reasons. The dedicated hardware (Linksys) is working well and I’m happy with it. It also “levels the playing field,” so my office partner no longer feels like a second-class citizen, as she did when my PC was the one that controlled our Internet access. That’s not a technical issue, but it’s worth keeping in mind.
A Practical Example
I just updated the firmware in my Linksys, and it drove home a little lesson from the previous page. Your router and your PC have to be on the same “network.” For example, the default address for the Linksys router is 192.168.1.1, but I’ve been using the block 172.16.0.* on my PCs. So to configure my router, I had to change the default on my PC, reboot, change the address of the router using its built-in mini-Web-server configuration screen — and of course as soon as I did that, it stopped talking to my PC! So I had to change the address of my PC back again, and reboot, and then log in to the router again. This might seem like a real hassle, and it is.
Of course, with a Linux machine you can just use ifconfig to change addresses without rebooting… or set up a virtual port, and be on both networks at the same time.
Comments
Leave a Reply
You must be logged in to post a comment.