Hubs And Repeaters: Their Operations And Limitations
Includes Video On "Inexplicable Switch Behavior"!
By Chris Bryant, CCIE #12933
The good old days in networking weren't always good, my friends. Having said that, before we dive into an in-depth discussion of switches, let's revisit the days of repeaters, hubs, and bridges. They're still around, so you better know what they do - and you just might see them on your CCNA and CCENT exams as well!
And if you've never used or touched any of those devices - you won't miss 'em. :) You'll be more than happy to work with switches!
With many networking terms, the name is indeed the recipe, and that's very true of a repeater. A repeater's job is to repeat an electrical signal, the form that our data has taken to be sent across a cable. Remember, "it's all ones and zeroes!"
The repeater actually takes an incoming signal and then generates a new, clean copy of that exact signal. This prevented maximum cable lengths from stopping transmissions, and also helped to ward off attenuation - the gradual weakening of an electric signal as it travels.
For example, we could have two hosts that are 150 meters apart. Perhaps the maximum cable limit between the two hosts is 100 meters; perhaps we simply need to make sure the remote host is getting a clear, strong copy of the signal.
A repeater will ensure that the remote device receives a clear, strong copy of that signal.
A hub is basically the same as a repeater, but the hub will have more ports. That's the only major difference between the two. (Some hubs have greater capabilities than others, but a "basic" hub is simply a multiport repeater.)
Neither hubs nor repeaters have anything to do with the Data Link layer of the OSI model, nor do they perform any switching at all. Hubs and repeaters are strictly Physical layer devices, and that's where the trouble comes in. For our next example, we'll consider a hub with four PCs connected to it.
This simple little network setup actually illustrates two major problems with hubs. First, only one PC at a time is going to be allowed to send data. Using a hub in this situation results in one big collision domain, meaning that data that one host sends can collide with data sent by another host. That results in all data involved becoming unusable.
To prevent this, a host on a shared Ethernet segment will use CSMA/CD (Carrier Sense Multiple Access with Collision Detection). In a nutshell, here's the CSMA/CD process:
A host that wants to send data "listens to the wire", meaning that it checks the shared media to see if it's in use.
If the media is in use, the host backs off for a few milliseconds before checking again.
If the media is not in use, the host sends the data.
If two PCs happen to send data at the exact same time, the voltage on the wire will actually change, indicating to the hosts that there has been a data collision.
This collision results in the generation of a "jam signal", which indicates to the other hosts on the shared media that they should not send data due to a collision.
The two PCs that send the data will both invoke a backoff timer, also in milliseconds, and when that random timer expires, the host will begin the entire process again.
Simple, eh? While this all does occur in a matter of milliseconds, we'd prefer to have no collisions at all! We'll take a look at how bridges and switches limit collisions in the next installment of my exclusive Cisco CCNA / CCENT tutorial series!