Hi there!
Thanks for purchasing my ICND1 Study Guide! Whether you’re preparing for success on the CCENT 100-101 exam or you’re going all the way to the CCNA 200-120 exam, you’ve made an
excellent choice.
(Those of you preparing for the CCNA 200-120 exam should also
grab my ICND2 Study Guide to go along with this one.)
You’re about to benefit from the same clear, comprehensive CCENT and CCNA instruction that
thousands of students around the world have used to earn their
certifications. They’ve done it, and you’re about to do the same!
On the next page or two, I’ve listed some additional free resources that will definitely help you on your way to the CCENT, the CCNA, and
to real-world networking success.
Use them to their fullest, and let’s get started on your exam pass!
Chris Bryant
“The Computer Certification Bulldog”
Udemy:
https://www.udemy.com/u/chrisbryant Over 30,000 happy students have made me the #1 individual
instructor on Udemy, and that link shows you a full list of my free and almost-free Video Boot Camps!
Use the discount code
BULLDOG60 to join my 27-hour CCNA Video Boot Camp for just $44! You can also follow this link, which has the discount built in. https://www.udemy.com/ccna-on-demand-video-boot-camp/?
couponCode=bulldog60&ccManual=
YouTube:
(Over 325 free training videos!)
Website:
http://www.thebryantadvantage.com (New look and easier-to-find
tutorials in January 2014!)
Facebook: http://on.fb.me/nlT8SD
Twitter:
https://twitter.com/ccie12933
Copyright © 2013 The Bryant Advantage, Inc.
All rights reserved. This book or any portion thereof may not be reproduced or used in any manner whatsoever without the express written permission of the publisher except for the use of brief quotations in a book review. No part of this publication may be stored in a retrieval system,
transmitted, or reproduced in any way, including but not limited to photocopy,
photograph, magnetic, or other record, without the prior agreement and written permission of the publisher.
The Bryant Advantage, Inc., has attempted throughout this book to distinguish proprietary trademarks from descriptive terms by following the capitalization style used by the manufacturer. Copyrights and
trademarks of all products and services listed or described herein are property of their respective owners and
companies. All rules and laws pertaining to said copyrights and trademarks are inferred.
First Printing, 2013
The Bryant Advantage, Inc. 9975 Revolutionary Place Mechanicsville, VA 23116
Table Of Contents:
Free CCENT and CCNA Resources
The Fundamentals Of Networking
Ethernet (Header is “You Got Your Ethernet In My Cabling!”)
Hubs & Repeaters (Header is “Hubs, Repeaters, and a little more Ethernet”)
Switching Fundamentals and Security
Introduction To WANs (Header is “A Network Admin’s Book Of WANs)
DNS, DHCP, And ARP
Router Memory, Configs, and More
IP Addresses and the Routing Process
Config Modes and Fundamental Commands
Static Routing
OSPF
Access Lists and The Network Time Protocol
Route Summarization
IP Version 6
NAT and PAT
ROAS and L3 Switching
Binary Math and Subnetting Mastery
The Fundamentals Of
Networking
(With A Little Zen Thrown In)
Before we dive into the nuts and bolts of networking, let’s ask ourselves one question: What is networking?
Why are we doing all of this stuff with routers, and switches, and who knows what else?
That’s two questions, I grant you, but you get the point.
Networking was once simple. We had a few end users with terminals, and maybe a printer in the room, and that was about it.
Things got just a little more complicated after that.
were thrilled that everyone could now print to one printer – and then it seemed like everyone wanted something else!
“Wouldn’t it be great if we could send each other files?”
“Hey, can we set up the network so we can save data to a central
location?”
“We’re adding ecommerce to our business – can we set up our ecommerce servers so that only certain people can have access to them?”
conferencing to our network.” “Wouldn’t it be great if we could see a person’s face while they host an online meeting for the
company?
When the first computer networks were put together – and for many networks after that – services we use today without a second thought, such as GoToMeeting and other video / voice conference tools, were fantasies.
networks have grown and grown and grown in order to handle these services and make them available to our end users in an efficient manner.
Of course, we also have to secure our networks, and the tools we use to do so can complicate our
network operations.
In short, we can have a collection of devices like the ones shown here all in one network, and it’s our job to get them to work together.
If you’re new to networking, I know from experience that the thought of putting all of the stuff together can be intimidating. It was for me the first time I put a network together, and we didn’t even have some of these devices yet!
Here’s the key to success in this field, and to keeping calm when your studies intimidate you – it’s all about the fundamentals.
Success with networking, whether it’s on certification exams or in real-world server rooms, is all about knowing and applying the fundamentals.
The material you’re about to study – networking models, TCP and UDP operation, and other networking fundamentals – is actually the most
important part of your network studies. After all, if you don’t know how the fundamentals work, you can’t possibly master the more advanced concepts.
I’m mentioning all of this now for one reason.
One night, when you’re tired and you’re hitting your studies hard, it’s easy to look at the OSI model and think to yourself, “Do I REALLY need to know this stuff?”
I know because I used to wonder that, too. I’ve been there.
After 10+ years of experience with networking and having helped thousands of networking students around the world meet and exceed their career goals, I can tell you that yes, you REALLY do need to know this material!
You’ll see why as we dive into the networking models and proceed through the course. Let’s get to it!
The OSI Networking Model
The OSI model isn’t just something to memorize for the exam and then forget. You’ll find it helpful for real-world troubleshooting and for breaking networking down into “pieces” that are easier to learn.
We’ll first take an introductory look at the OSI model, getting familiar with what’s going on at each level, and then we’ll use it to create a path for CCENT and CCNA exam
As network administrators, we’re primarily concerned with the
bottom three layers. As CCENT and CCNA candidates, we’re concerned with all seven layers, so let’s start at the top of the model and work our way down.
The Application Layer
That’s not everything you need to know for the exam, but it’s a great start. The Application layer is where our end users interact with the network.
The Application layer performs important behind-the-scenes tasks:
Makes sure the remote communications partner is available (remember, it takes two to network)
Ensures that both ends of the communication agree on a myriad of rules, including data integrity, privacy, and error recovery (or lack of same)
The Presentation Layer
This layer answers one basic question, and that question is…
“How should this data be presented?”
Ever opened a PDF with a non-PDF-friendly word processing app? You can end up with hundreds of pages of unreadable garbage – just page after page of text that means nothing to you. That’s a Presentation Layer issue.
Encryption takes place at this layer, and you’re going to hear a lot about encryption in this and future
The Session Layer
This layer is the manager of the overall data transfer process. It handles the creation, maintenance, and teardown of the communication channel between the two parties (the “session”, hence the name of this layer!).
The Transport Layer
The main purpose of the Transport layer is to establish a logical end-to-end connection between two systems.
That’s not the only thing going on here! Most of the additional Transport layer functions involve either the Transmission Control Protocol (TCP) or the User
Datagram Protocol (UDP). Those two protocols are so important, they have their own section in the course – a section that could be worth 100+ points on your exam, so we’ll be hitting a lot of detail there.
Now we come to the OSI layers that you and I, the network admins, have regular interaction with.
The Network Layer
For the router, the Network layer processes answer two basic questions:
What valid paths exist from here to “Point B”?
Of those paths, what is the best path to get to “Point B”? Boy, that was simple! Class over!
Wellllll, it’s not quite that easy. We’ll dive into the details later in
this course. Right now, it’s enough to know that IP addresses
(172.12.123.1, for example) are used at the Routing layer.
There’s another important address we use in our networks, and that one runs at the next layer down.
The Data Link Layer
We’ll be spending a lot of time with switches in this course, and our switches run at this layer, as do these protocols:
Ethernet
HDLC (High Data Link Control)
PPP (Point-to-Point Protocol) Frame Relay
usually referred to as the MAC address, but it literally has four other names:
Layer 2 address Hardware address
Burned-in address (BIA) Physical address
The first name makes perfect sense, since we’re at Layer 2, but what about those others?
This address is actually burned into the hardware, so you see where the
“hardware” and “burned-in” names come from. Be careful with that last name, though. We sometimes call the MAC address the “physical address” because it physically exists on the hardware – NOT because it runs at the Physical Layer of the OSI model, because it doesn’t.
Right now, I want to introduce you to a set of terms that sound like they do the same thing, but we need to be very clear on the difference:
Error detection Error correction
Remember: Detecting something doesn’t mean you’re correcting it. Here’s why I’m bringing this up right now….
The data link layer performs error detection via the Frame Check
Sequence (FCS). The actual
operation of the FCS goes beyond the scope of the CCENT exam, but as a network admin you really should know the FCS fundamentals:
1. The sender runs a
mathematical formula (an
algorithm) against the
2. The sender places the result of that value into the FCS field of the frame, and then sends the frame.
3. The receiver of the frame runs the same algorithm against the contents of the frame. If the resulting value matches that contained in the FCS field, the frame is fine. If that resulting value does not match, that frame is considered corrupt and is then discarded.
So why no error recovery? It’s the recipient of the frame that detects the error, not the sender, and the recipient can’t retransmit the frame to itself! All the recipient can do is let the sender know there was a problem.
The Physical Layer
All the work we do at the upper layers of the OSI model is all about sending the data across the Physical layer in the form of ones and
zeroes.
The data our end users create is going to be eventually be
“translated” into 1s and 0s. Anything having to do with a physical cable or the standards in use – the pins, the connectors, and the actual electric current – is
running at the Physical layer.
With our end users entering data / sending photos / watching videos / whatever, it sounds like we have to do a lot of work to turn all of that into ones and zeroes.
It’s almost like we need a plan to do so…. and here it is!
The Data Chopping Process
This is actually known as the
overall data transmission process. It’s also a good reminder for
network newcomers as to what we’re actually doing here.
When the end user sends data, the data goes through all seven layers of the OSI model, but it doesn’t keep the same form – otherwise the physical layer would be getting HUGE chunks of data and have no idea what to do with it!
Instead, the Transport layer begins the process of taking the data and segmenting it into smaller units, and each layer below the Transport layer will break the units up into even smaller units, until the data has been transformed into a stream of ones and zeroes that can
successfully be transmitted by the Physical layer.
I can guarantee the following data unit terms and their associated OSI layers will show up on your
At the Application, Presentation, and Session layers, data is simply referred to as “data”. While there are important operations going on at these layers, the “chopping” of the data hasn’t started yet.
That process begins at the Transport layer, where the data is placed into
segments.
At the Network layer, data is placed into packets.
At the Data Link layer, data is placed into frames.
Finally, at the Physical layer, data takes the form of bits, and those bits are all ones and zeroes!
For your exams, be very clear about the data transmission unit
associated with each OSI layer.
There’s a little extra overhead involved with the OSI model. Each layer is going to add its own header
that will be removed by the same layer on the other end of the
session. These headers are
layer-specific. The Transport layer
doesn’t care about the contents of any header except the one placed there by the Transport layer on the other end of the session.
There are almost always exceptions in networking, so let’s introduce you to one right now. Each of the top six layers will place only a header on the data except for the Data Link layer, which will add both a header and a trailer.
This combination of data and a layer-specific header is a Protocol Data Unit (PDU), and there’s a PDU for each layer shown above.
They’re usually referred to by the layer – L7 PDU, L6 PDU, etc.
transmitted by the Physical layer, the data flows back up the model on the other end of the session. As you’d expect, each layer removes the header added by its counterpart on the other end of the session (“same-layer interaction”).
Let’s do a quick comparison of same-layer and adjacent-layer interaction.
“Same-layer interaction” refers to an OSI layer on one end of the session removing the header placed on it by the same layer at the other end of the session.
Adjacent-layer interaction refers
the OSI model on the same host.
For example, the Application layer can have adjacent-layer interaction with the Presentation layer, the Presentation layer can have
adjacent-layer interaction with both the Application and Session layers (the ones directly above and below it), and so forth.
We’ve spent a lot of time with the OSI model, and while we’re not done with it, there’s another networking model….
The TCP / IP Networking Model
This model also uses layers to illustrate the data transport process, but only five layers as opposed to the OSI model’s seven.
For the CCENT and CCNA exams, it’s an excellent idea to know the following:
The layers of the TCP/IP and OSI models (check!)
layer (check!)
How the layers of the two models map to each (coming up!)
Enough prologue and dialogue… here’s the latest version of the TCP/IP model!
The Application layer of the
TCP/IP model maps to the top three layers of the OSI model
(Application, Presentation,
Session). After that, it’s a one-to-one layer mapping all the way down.
You TCP/IP model veterans know this is a LOT easier to deal with than the previous model, which follows:
The Internet layer is bulging a little bit, since I wanted to put at least two of the known names for that layer in there. Don’t even get me
started on the multiple names I’ve seen over the years for the bottom layer. We’re all happier with the much more intuitive, new TCP/IP model.
There’s nothing tricky about these models, and they will be easy points for you on exam day. Having said that, on exam day, quickly double-check any questions you’re given on these models to be sure of the model you’re being asked about. If you’re asked about the OSI
model, don’t give an answer of a layer in the TCP/IP model.
Here’s the magic question I just KNOW some of you are asking:
Why Do We Use Models, Anyway?
Mostly just to aggravate you on exam day.
Just kidding! It only seems that way.
One reason is that networking models help software vendors create (we hope) interoperable products.
overall networking process into smaller pieces makes it a lot easier to learn networking in the first place.
This is a very important point, not just for this section, but for all of your studies – Cisco and otherwise. It’s really easy to become
overwhelmed when you start learning this stuff.
Here’s a surefire cure for that feeling: Just take it one feature at a time. Learn one thing about the
subject matter at a time, and soon you’re got it all mastered.
That’s worked for me for over 15 years and it’ll work for you, too.
Now back to the “why” regarding these models…
Using a networking model to structure your troubleshooting approach is a real help, especially since most of what you and I do as network admins is troubleshooting.
(It’s not like we configure our networks from scratch every single day.)
I always tell students to start troubleshooting at the Physical layer, and you’ll see what I mean as we perform troubleshooting
throughout the course. In my
experience, there are two kinds of network troubleshooters:
1. Those who have a structured approach.
structured approach, and are basically just trying things blindly because they don’t truly understand what they’re doing.
You want to be #1.
In short – or in long – these networking models aren’t just something to memorize for your exams. You’ll be using them throughout your career, even if you’re not consciously thinking about it.
Let’s take a closer look at two new friends that operate at the Transport layer. There’s a ton of fertile
ground for exam questions in this section!
TCP vs. UDP
Here are the similarities between the two:
They both operate at the Transport layer of the OSI model.
They both perform something called “multiplexing”.
You knew the first one, and we’ll talk about the second one later in this section – I promise!
Let’s get to the differences!
TCP Characteristics:
Guarantees delivery of segments
Performs error detection Performs “windowing” “Connection-Oriented”, meaning a two-way
communication between the two endpoints will take place before data is actually
If those terms are new to you, that’s fine, we’ll define them in a moment. First, let’s take a look at UDP:
UDP Characteristics:
“Best-effort delivery”, which is good, but not guaranteed No error detection due to lack of Sequence or Ack numbers
No windowing
“Connectionless”, meaning there’s no pregame
two endpoints – the data exchange just starts!
Even if you don’t know what windowing is, you have to admit that TCP already sounds a lot better than UDP. That very first
characteristic of each – TCP guaranteeing delivery of segments while UDP doesn’t guarantee it – well, that sounds like enough for me to use TCP for everything and UDP for nothing!
world. Many vital protocols, including the protocol that handles the very important work of
dynamically assigning IP addresses, uses UDP.
On top of that, the two most delay-sensitive types of network traffic we have – voice and video – use UDP.
Why?
answer, and you just might figure out that one word as we examine the overall operation of both protocols, starting with TCP and a curious process called the “three-way handshake”.
TCP and the Three-Way Handshake
You’ve probably shaken hands many times in your life, but have you ever taken part in a three-way handshake?
Let’s take this one step further: How in the world can you even
have a three-way handshake?
Here’s how and why:
With TCP, there’s some work to be done before any segments are transmitted. The involved devices have to agree on some basic
parameters before any
transmissions can happen, including the Initial Sequence Number (ISN). Here’s exactly how this handshake proceeds…
The initiating server sends a TCP segment with the SYN bit set. That SYN stands for SYNchronization, and the primary value being
synchronized is the TCP Sequence number.
The recipient responds with a TCP segment of its own, and this one has the Acknowledgement bit set as well as the SYN bit, which is why we call this a “SYN/ACK”.
Part of that SYN/ACK is the server acknowledging receipt of the
original SYN, so it makes sense that the server getting the SYN/ACK needs to ack that. That’s the final step of our 3-way handshake!
Summing up:
SYN in an effort to
synchronize TCP values with the recipient.
2. The receiving server sends a SYN/ACK back for two reasons – one, to
acknowledge receipt of the original SYN, and to further the synchronization process.
3. The initiating server sends an ACK to let the other server know the SYN/ACK was received, and that’s the end of
the handshake.
Now let’s take a look at the UDP 3-way handshake:
< crickets chirping >
That’s it, because UDP doesn’t
have a 3-way handshake.
Sounds like another strike against UDP.
Now for another great TCP feature….
How TCP Detects and Recovers From Lost Segments
While the following is technically not error detection, it’s a very important concept of TCP – how TCP realizes segments have been lost, and how TCP recovers from lost segments.
The TCP header contains separate fields for the sequence number and acknowledgement number, and it’s those two values that allow TCP to detect and recover from lost
In the following example, one host is sending four segments to another. Each of the segments has a
sequence number, and it’s that sequence number that tells the
recipient in what order the segments should be reassembled.
Here’s an illustrated look at the process, starting with S1 sending four 1500-byte segments to S2:
Once the four segments are
received by S2, it would be a really good idea to let S1 know the
segments arrived safely.
S2 does that by sending a segment back to S1, but there will be no data in the segment. The ack number will be set, but it will not be set to the number of the last segment S2 received, as you might expect. Instead, it’ll be the number of the next data segment S2 expects to see, and with this pattern that would be 7500.
The natural assumption is that the ack would be set to 6000, but when S2 tells S1 the next segment number it expects to see, this cumulative
acknowledgement scheme allows
TCP to realize when segments have been lost.
those four segments is lost.
S2 will send an ACK of 3000 back to S1.
When S1 sees that ACK of 3000 coming in, it knows the segment with SEQ 3000 wasn’t seen by S2, so S1 will then retransmit that particular segment. S2 will then send an ACK for that retransmitted segment indicating the NEXT sequence number it expects to see.
In networking studies, as in life, one answer tends to lead to another question. In this case, that question is “How does S1 know how many segments it can send before it has to receive an ACK?”
Another question: “Why doesn’t the recipient just send an ACK for every segment it receives?”
Flow Control and Windowing
Let’s step back to the TCP three-way handshake. We know that during that handshake, parameters are negotiated and agreed upon, one of those being the initial sequence number (ISN).
Another value negotiated during this handshake is the initial size of the
window, which determines how
many bytes of data the recipient is willing to take in before it has to send an ACK.
Note this is the initial size of the window. It’s vital to remember that the size of the window is dynamic, not static. As the recipient realizes it can handle that initial amount of data effectively, the recipient will indicate to the sender that it can send more data before expecting an ACK.
To reiterate a couple of important points regarding windowing:
The initial size of the window is negotiated and agreed upon during the three-way handshake.
expressed in bytes.
The size of the window is dynamic, and it’s changed by the recipient, not the sender. This flow control can raise or lower the size of the
window, also referred to as a
sliding window.
The recipient will lower the size of the window as it sees that errors and / or dropped segments are starting to creep in.
You can see why TCP flow control is such a great feature. It allows segment transmission to stay close to maximum speed while also letting the recipient slow the flow down when transmission is too fast.
Right now, TCP is looking pretty darn good, and UDP isn’t.
There’s one word that describes UDP’s advantage over TCP. Before we trash UDP’s reputation entirely, let’s see what that word is.
UDP’s Advantage Over TCP
Let’s compare the TCP and UDP headers.
UDP’s header:
Quite a difference in size, and that difference leads us to that single word that makes UDP so
attractive… overhead.
features than UDP, those features come at the cost of additional overhead. These headers are
attached to every segment, and that really adds up – especially with the delay-sensitive voice and video traffic found on today’s networks. UDP is used for voice and video traffic for this very reason.
The UDP header is much smaller than the TCP header, and it’s worth your time to note the two headers have three fields in common:
Destination port Checksum
For clarity’s sake, in the TCP header I listed a “Flags” section. That’s actually nine individual 1-bit flags, which include the ACK and SYN flags mentioned throughout this section.
This Just In: A UDP / TCP Similarity!
One factor UDP and TCP have in common is a little something called “multiplexing”. Before we see how multiplexing works, let’s see why we need it in the first place.
You don’t need to know the ins and outs of IP addressing at this point in the course. It’s enough to know that IP addresses are used as a
destination when data is sent to a network host.
So far, so good – until one host starts sending multiple flows of information to the other host. How is the recipient supposed to handle that?
Let’s say the host at 10.1.1.11 is sending three different flows of data to 10.1.1.100:
A file transfer via the Trivial File Transfer Protocol
Email via the Simple Mail Transfer Protocol
Webpage data via HTTP
The server needs a way to keep the incoming flows separate so it can send the TFTP data to the
application that will handle that data, SMTP data to the appropriate
application, and so on. That’s
where our new best friends come in – well-knownport numbers!
These port numbers may not be well-known by you (yet), but they are to our network devices. I’ll have a bigger list of well-known port numbers for you later in this section, and it would be an
excellent idea for you to have those down cold for your exam. Let me introduce you to three of them now:
HTTP: TCP port 80
SMTP: TCP port 25
The three data flows in our example will have the same source and
destination IP addresses, but they’ll have different, pre-assigned port numbers. Those different port
numbers are the reason the recipient knows how to handle the three
incoming flows that all originated from the same host.
When a host receives data marked as UDP port 69, it knows that traffic should be delivered to the TFTP application, TCP port 80 traffic should go to the HTTP application, and so forth.
These port numbers also allow the host to mix the three data types when sending to 10.1.1.100, rather than sending all the TFTP data first,
then the SMTP data, then the HTTP data. This mixing of data streams is multiplexing.
When you hear the term “socket”, you might think of a physical part of a network host, but it’s actually logical. The socket is simply a combination of IP address and port number. The socket for the TFTP traffic heading for 10.1.1.100 would be expressed as
10.1.1.100:69.
You’ll sometimes see a socket (try saying THAT really fast three times!) expressed in this format:
IP address, transport protocol, port number
Using that mode of expression, the TFTP socket on 10.1.1.100 would be (10.1.1.100, UDP, 69).
the port number system works nicely as long as the hosts agree on the port used for a given protocol. For example, if 10.1.1.11 is using TCP port 55 for TFTP, we’re in a lot of trouble.
That’s why most protocols use the same port number at all times, and these port numbers are well-known port numbers. Two bits of info for you on those:
Any port number below 1024 is a reserved, well-known port number.
You do NOT have to
memorize 1024 port numbers for your exams.
I strongly recommend you memorize the port numbers listed throughout the rest of this section. You’ll find them helpful in both your
networking studies and real-world network administration. They’re not just something to memorize for your exam that you’ll never use again, and like the OSI model layer, they become second nature to you.
TCP’s Four-Way Handshake (What?)
I didn’t want to hit you with this during the TCP/UDP comparison, since we had enough going on. Now that you’ve got all of this down, I want to show you TCP’s four-way handshake.
The three-way handshake we saw earlier was during the connection
establishment; the four-way
handshake we’re about to see is the connection termination. I’ve seen
this expressed in several different ways over the years, but in the end each device needs to send a
segment with the FIN bit set and they each need to ACK the FIN they receive.
We’ll wrap this section up with a couple of well-known port numbers
it would behoove ye to know, and then we’ll move on to Ethernet!
TCP 20: File Transfer Protocol (file transfer)
TCP 21: File Transfer Protocol (control)
TCP 22: Secure Shell (SSH) TCP 23: Telnet
TCP 25: Simple Mail Transfer Protocol
TCP and UDP 53: Domain Name System
UDP 67, 68: Dynamic Host Configuration Protocol
UDP 69: Trivial File Transfer Protocol
TCP 80: Hypertext Transfer Protocol
TCP 110: Post Office Protocol (Current version: 3)
UDP 161: Simple Network Management Protocol
TCP 443: Secure Sockets Layer (“HTTPS”)
UDP 514: Syslog (Short for System Logging – more on that in your
ICND2 studies)
UDP 546, 547: DHCP For IP Version 6
This is a great list to get started with, but it’s hardly all of the well-known port numbers. The list on the following page is WAY beyond the scope of the CCENT and CCNA, but it’s a great reference list for future studies.
With those in mind, let’s march on to Ethernet – and BEYOND!
You Got Your Ethernet
In My Cabling!
(You Got Your Cabling In My
Ethernet!)
When we get to Wide Area Networks, we’ll run into quite a few different encapsulations --HDLC, Frame Relay, and PPP in particular.
With Local Area Networks,
whether we’re connecting a host to a switch….
… or we’re connecting two switches…
… or we’re connecting a switch to a router…
…. we’re likely using Ethernet and Ethernet cables. In this section, we’ll talk a bit about how Ethernet works, and the different types of cables we’ll use in this network. And note that I said “Cables With
An S”, because not all Ethernet
cables are the same!
Actually, not all Ethernet types are the same, so let’s start there.
Not All Ethernets Are The Same
“Ethernet” is really an umbrella term at this point, encompassing several different types of Ethernet, different capacities, and different challenges. For both a successful exam experience and a solid
networking career, it’s a great idea to be comfortable with these values.
Most kinds of Ethernet cables are Unshielded Twisted-Pair (UTP). The name is the recipe – the wires inside the cable are indeed pairs of
twisted cables.
Why twist ’em? Twisting pairs of wires inside the cable cuts down on electromagnetic interference (EMI). EMI can interfere with the
electrical signals carried by the wires, which in turn is really going to screw around with our network.
EMI can come from other cables, and also (and infamously) from elevators. I know of more than one network that would slow down at lunchtime and quitting time because
that’s when the elevators were in heavy usage, and the network cables werun right next to the elevator shaft, which in turn gave our network the shaft.
We can even have EMI problems from other wires in the same cable! This crosstalk happens when a signal “crosses over” from one pair of wires to another, making the signal on both sets of wires unusable.
when wires are crossed or crushed. The conductors inside the wires don’t have to be exposed, but if the conductors are too close, the signal traveling on one wire can interfere with the signal on another wire.
Here are some common Ethernet types that run on regular old copper cabling, along with their official IEEE name and more common name. All have a maximum cable length of 100 meters.
802.3, is generally referred to as 10Base-T, and runs at 10 Megabits per second (Mbps).
Fast Ethernet (802.3u) is usually called 100Base-T, and runs at 100 Mbps.
Gigabit Ethernet (802.3ab) is generally called 1000Base-T, and runs at 1000 Mbps.
NOT called 10000Base-T. It’s usually called 10GBase-T, and runs at – you guessed it! – 10 GBPS.
There’s a huge difference between 10GBase-T and 10Base-T. Watch that G!
We also have a version of Gig Ethernet that runs on fiber-optic cable. That version is 802.3z, and is often called 1000Base-LX. This version has a max cable length of 5000 meters, as opposed to 100
meters with all the other versions we’ve seen.
So with that huge max cable length, why aren’t we running everything on 802.3z? It’s the sheer cost of the fiber optic cable. It’s a lot more expensive to install and
Multiple Standards Usually Equal Multiple Nightmares
Luckily, this isn’t one of those situations.
When you send an Ethernet frame from Point A to Point B, there’s a chance the frame could go across a “regular” Ethernet link, then a Gig Ethernet link, and then a Fast Ethernet link as it arrives at its destination.
If we had to do some kind of
translation every time a frame went from one Ethernet type to the other, we’d be doing a lot of translations and adding big time to our
transmission time and overall network workload. Fear not – we don’t have to do anything like that. All of our different Ethernet
standards have the same overall frame format:
There’s another tool that allows us to seamlessly use network and host devices with different Ethernet capabilities – autonegotiation.
Autonegotiation didn’t work all that well years ago, and it got to the point where most network admins manually set card and port settings. Cisco went so far as to make it a best practice NOT to use
autonegotiation.
I mention this because I don’t want you more-experienced network
admins glossing over this section, thinking “Hey, autonegotiation doesn’t work.” Autonegotiation has come so far since the bad old days that it’s actually mandatory for Gig Ethernet over copper, and it’s an important part of the overall Gig Ethernet standards.
Having said that, let’s see how autonegotiation works!
In this example, we have a host device connected to a Cisco switch port. The host is running 10BaseT,
and the switch port has a top capability of 1000BaseT.
The devices announce their capabilities via Fast Link Pulse (FLP). The logical question: “Fast as compared to what?”
Fast as compared to the Normal Link Pulse (NLP)! Basically, the NLP is sent by an Ethernet device
when it has no data frames to send – it’s saying “Hello, I’m still here!”
Here’s the NLP, compliments of Wikipedia:
Here’s the Fast Link Pulse, which autonegotiation-enabled devices use to announce their capabilities:
After the devices exchange this information…
… they come to an agreement on the values to use. As you’d expect, the
lowest speed is the one selected, and full-duplex is preferred over half-duplex. In this situation, the PC port and the switch port it’s
connected to would run at 10 Mbps, full duplex.
Autonegotiation will dynamically adjust if a port capacity changes. Let’s say you replace that PC with a PC that can run at Fast Ethernet speed.
If we manually set all of our switch port settings, we’d have to change the speed on that port manually. With autonegotiation, the switch will realize the new capacity of the device connected to that port, and voila – a 100 Mbps link!
I highly recommend you use autonegotiation on both ends of a link such as this one, or don’t use it at all. You can end up with a link that isn’t working at its real
capacity due to a duplex mismatch – a link where one endpoint is running at half-duplex and the other
end is running at full-duplex.
When using Cisco switches, if autonegotiation is turned off on the other end of the link, the switch should still be able to sense the speed capacity of the other endpoint. If for some reason the speed capacity can’t be detected, the lowest speed supported will be used.
That probably doesn’t surprise you, but this might. If that detected speed is less than or equal to 100 Mbps,
the switch will set its port speed to half-duplex. Hello, duplex
mismatch!
In this example, the Cisco switch has successfully detected the capacity of the remote endpoint to be 100 Mbps. No problem there, but a problem does arise when the Cisco switch sets its port connected to that host to half-duplex as a result of that speed.
Duplex mismatches have a special place in Network Heck, because they can be difficult to spot. The two devices will still be able to exchange data, but it’s going to be a slow, inefficient process.
Run autonegotiation on both ends or don’t run it at all.
Crossover and Straight-Through Cables
We’re going to use a simple
network for this demo, and the two separate physical connections will require two different cable types.
2 and a switch sends on pins 3 and 6. In turn, the PC receives on pins 3 and 6, and the switch receives on pins 1 and 2. This means we can use a straight-through cable to connect the PC to the switch.
The cable name comes from the wires inside the cable. Assuming we’re using Ethernet or Fast
Ethernet for this connection (a safe assumption), we’re going to have four wires inside the cable, and each wire goes straight through from one end to another.
What exactly does “straight
through” mean in this situation? The wire connected to Pin 1 at one end goes straight through to Pin 1 at the other end, the wire on Pin 2 goes straight through to Pin 2 at the other end, and the wires on Pins 3 and 6 go straight through to those pins on the other end.
If you enjoy making your own cables and you run into a
connection issue right away, I can practically guarantee the problem is that one of those wires in your
over to another pin.
Gigabit Ethernet can use straight-through cables as well, but to carry data that quickly, it follows that we’ll have more wires inside the cable. Where Ethernet and Fast Ethernet have 4 overall wires inside the cable, Gigabit Ethernet has eight. In a Gigabit straight-through cable, one wire goes from Pin 1 to Pin 1, one wire from Pin 2 to Pin 2, and so forth for all eight pins.
Wires crossing over inside the cable isn’t always bad. Sometimes
we want those wires to cross over in the cable – hence the name “crossover cable”, our next cable type!
Crossover cables are necessary when we’re connecting two devices of the same type, and in a typical network, that’s going to be two switches. When we tackle
switching in this course, you’ll see why interconnecting switches is so common. Our first step in this
interconnection is choosing the right cable!
We can’t use a straight-through cable for a switch-to-switch
connection, since they use the same pins to send and receive. We’d have the same pins sending data on both ends (a bad idea) and pins 3 and 6 on each end listening for data that will never arrive (sad!).
Communication between the switches is made possible with a
crossover cable. The four wires
inside the cable “cross over” from one pin to another inside an
Ethernet or Fast Ethernet crossover cable:
Wire on Pin 1 crosses over to Pin 3
Wire on Pin 2 crosses over to Pin 6
Wire on Pin 3 crosses over to Pin 1
Wire on Pin 6 crosses over to Pin 2
With this setup, when a switch sends data on the two pins used to send data (Pins 1 and 2), the switch on the other end of the cable will receive the data on pins used to receive data (Pins 3 and 6).
Gigabit Ethernet crossover cables have those same wires cross over in addition to the following:
Wire on Pin 4 crosses over to Pin 7
Wire on Pin 5 crosses over to Pin 8
Wire on Pin 7 crosses over to Pin 4
Wire on Pin 8 crosses over to Pin 5
Now it’s time for a little “real world vs. theory” chat.
After reading that cabling section, some of you are saying “Hey, I used a straight-through cable to connect two switches with no trouble.” And you’re right – you just might have. Most Cisco switches will recognize what you’re trying to do when you connect them to each other with a straight-through cable, and the switch will dynamically adjust itself to make the straight-through cable work.
When it comes to your CCENT and CCNA tests, though, you need to forget about that. Be clear on when you’d use a straight-through cable as opposed to a crossover cable:
Devices transmit on same pins = crossover cable
Devices transmit on different pins = straight-through cable
Both straight-through and crossover cables end with RJ-45 connectors, which “snap” right into place when connected to a PC NIC or switch / router Ethernet port.
Several protocols and services you’ll be introduced to in this course have more than one name, and we’ll start that tradition with the next topic, known by all of these names:
MAC address (Media Access Control)
Physical address (because the address physically exists on the network card)
Burned-In address (BIA – the name comes from the address being physically burned into the NIC)
Ethernet address
That’s nothing! We used to have
seven names for this address, but
the terms “NIC address” and “LAN address” have pretty much fallen by the wayside. Throughout the
courses, I’ll use the term “MAC address”, but you should be familiar with all the names listed
here.
The MAC address is used by switches to send frames to the proper destination in the most
efficient manner possible, a process you’ll be introduced to in the
Switching section. Before we see how that works, I want to introduce you to the address format and the characters we’ll see in this address.
The MAC address is six bytes long (48 bits), and can be expressed in either of these formats:
aa-bb-cc-11-22-33 aabb.cc11.2233
MAC addresses consist of hexadecimal values, and if that phrase gives you anxiety,
fuggetaboutit. By the time this section is over and you get some practice in, you’ll be working with hex like a champ – or more
accurately, like a CCENT and CCNA!
You’ll hear me say this throughout the course, and I’ll start now: The
key to mastering hex, binary, and subnetting is practice. Reading about it is not enough!
The MAC address has two parts, the first being the Organizationally Unique Identifier (OUI, not
pronounced like the French word for “yes”, but Oh-You-Eye). The OUI is assigned to hardware vendors by the Institute of Electrical and Electronics Engineers (IEEE).
unique to that organization and is not assigned to another org.
The second half of the MAC address is simply a value not previously used by the hardware vendor with that particular OUI. Using the earlier MAC address example, we see that…
The OUI of the address is aa-bb-cc
11-22-33 with that particular OUI, so the vendor is doing so now
There’s a special MAC address for broadcast frames, and as we get to that topic, let’s take a look at the three overalltypes of network traffic.
Unicast traffic – Destined for one particular host
for a group of hosts
Broadcast traffic – Destined for everybody
You can spot broadcast and
multicast MAC addresses by using the following rules:
The broadcast MAC address is ff-ff-ff-ff-ff-ff (or FF-FF-FF-FF-FF-FF, as case doesn’t matter in hex).
We have a range of multicast MAC addresses. The first half of a multicast MAC address will always be 01-00-5e. The second half will fall in the range of 7F-FF-FF. Watch that 7!
Remember that Ethernet header and trailer I mentioned briefly?
No?
Well, I don’t blame you, it was a fast mention. Let’s take a more detailed look at both the header and trailer.
The Ethernet Header And Trailer
Here’s a high-level look at the overall Ethernet frame:
A detailed look at the header:
From left to right, a quick look at each field:
The preamble is there for synchronization purposes. The nuts and bolts of this field are (thankfully) way beyond the scope of the
CCENT and CCNA exams. If you’d like to read more about this field, check out the
Wikipedia entry for Ethernet.
The Start Frame Delimiter (SFD) indicates the preamble has ended and the destination MAC address is on deck.
Both the destination and source addresses are MAC addresses.
Finally, the type (EtherType) field indicates the protocol type carried in the data field. In today’s networks, that’s likely IPv4 or IPv6, but it can be plenty of other protocols.
Here’s a detailed look at the Ethernet trailer contents:
That’s it!
Considering the FCS is the Ethernet caboose, it’s easy to think there’s not much going on there, but the FCS is a vital error detection tool. It’s basically a three-step process:
The sender runs an algorithm against the contents of the frame, and takes the result of that algorithm and puts it in the FCS field. The result is the checksum.
The receiver runs the exact same algorithm against the same contents, and expects to come up with the same
checksum contained in the FCS field of the incoming frame.
If the results are the same, the frame is fine. If the results are not the same, something happened to the frame contents as the frame went across the wire, and the frame is dumped.
There is no explicit notification from the receiver to sender that the frame was discarded. The FCS brings us error detection, but not
correction.
We saw two common network connections earlier (PC to switch, switch to switch), and there’s
another one I want to introduce you to – connecting your laptop or PC directly to a switch or router in order to configure it. For that
physical connection, you’ll need yet another type of cable.
When you physically connect your laptop to a router or switch, you’ll
be connecting to the Console port on the network device. For this, you’ll need a rollover cable, also called a console cable. There are 8 wires inside the rollovercable, and they each roll over to a different pin at the other end: Pin 1 to Pin 8, Pin 2 to Pin 7, Pin 3 to Pin 6, and so on.
One end of the console cable will have an RJ-45 connector, similar to that on the end of a land line phone wire. You’ll feel (and maybe hear) that end of the cable snap into the Console port.
It’s the other end of the console cable you need to be aware of. Some console cables have a DB-9 connector on one end, and modern laptops don’t have a DB-9 port. If that’s your situation, get an adapter for your cable – you can find them online at any major cable dealer. (And even most minor ones!)
The need for an adapter is a good thing to find out before you visit a client site.
since they’re almost totally flat and usually colored light blue.
Here’s a link to a page on
PacketByte.com that shows you a console cable, along with two other cable types that you’ll find in any great Cisco home lab!
http://packetbyte.com/Content/Cabling/OtherCables.html
Next up – hubs and repeaters. You might not see many of them in today’s networks, but you need to
understand how they work in order to really grasp switch operation – and you’ll see hubs, repeaters, and switches on your exam, so let’s hit it!
Hubs, Repeaters, And
A Little More Ethernet
Cisco switches operate at the Data Link layer, but to fully understand and appreciate how switches operate (and to be fully prepared for the CCENT and CCNA exams), we need to look at the devices that preceded switches.
These devices are still in some networks, but for reasons you’re about to discover, repeaters and
hubs aren’t terribly popular. If you never work with either in a
production network, to be blunt, you’re not really missing anything. Having said that, you might miss out on some vital exam points if you’re not familiar with them, so let’s dive right in!
Repeaters And Hubs
Both repeaters and hubs are Layer 1 devices.
So with a repeater, what exactly are we repeating, and why?
When you’re listening to a radio station (non-satellite, that is), you know how the signal starts
gradually breaking up as you get farther and farther away from the station? That gradual weakening of
the signal is called attenuation, and attenuation happens to any
electrical signal, including the ones and zeroes we’re sending across the wire.
Let’s say we have two hosts 175 meters apart, and the maximum effective cable length is 100 meters. Obviously, that’s going to be a
problem, since the signal will be strong when it leaves the
transmitting host, but weak or practically nonexistent when it arrives at the other host.
That’s the problem repeaters helped us resolve. A repeater takes an incoming signal and then generates a new, clean copy of that exact signal.
A hub operates in the same fashion, but the hub has more ports. That’s pretty much the only difference between the two. Some hubs have greater capability than others, but a basic hub is simply a multiport repeater.
These hubs and repeaters seem pretty sweet, right? Why would we ever need anything more
complicated and expensive than that?
what happens when a hub is in the middle of a simple little four-PC network.
Using a hub here means that only one PC can send data at a time, because what we have here is one
giant collision domain, meaning that data that one host sends can collide with data sent by another host. The result: All data involved in the collision is unusable.
To prevent this, hosts on a shared Ethernet segment such as this will use Carrier Sense Multiple Access
with Collision Detection,
thankfully referred to as
CSMA/CD. Here’s the CSMA/CD process:
A host that wants to send data will first listen 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 listening to the wire again.
If the media is not in use, the host sends the signal.
If two PCs happen to send data at the exact same time,
the voltage on the wire will change, indicating to the hosts that there has been a data collision.
In that situation, the PCs that sent the data will generate a
jam signal, which indicates
to the other hosts on the shared media that they shouldn’t send data right now.
The PCs that sent the data will then invoke a backoff
timer, set to milliseconds.
When each host’s random timer expires, they will each begin the CSMA/CD process from the beginning where they listen to the wire. Since the backoff timer value is totally random, it’s unlikely the two hosts will have the same problem again.
This entire process happens pretty quickly, but we’d prefer to have no collisions at all, since collisions slow down the network. With the ultra-delay-sensitive voice and
video traffic today’s networks have to handle, delays due to collisions and retransmissions are totally unacceptable – just another reason you won’t see many repeaters and hubs in today’s production
networks.
There’s another big issue with hubs and repeaters, this one having to do with broadcasts.
Just as the current network is a single collision domain, tis also a single broadcast domain. Every
single time one of those PCs on that hub sends a broadcast, every other PC on the hub is going to receive a copy of that broadcast, even if that PC doesn’t need or want the
I want to drive this into your brain right now:
Everything we do on a router or switch has a cost.
I don’t mean a financial cost. I mean a cost in time, a cost to our
available processor power, and/or a cost to our available bandwidth.
Let’s say there are 64 PCs attached to that hub, and only 3 of the other PCs ever need to get a copy of the
broadcast sent by that particular PC.
That leads to several unnecessary costs to our network:
The hub has to create and send 60 unnecessary copies of the data.
Each PC that doesn’t need the broadcast still has to take the time to examine the incoming broadcast, because they don’t know they don’t need it until
they do that.
The bandwidth required to send these 60 unnecessary copies adds up.
It’s a great idea to limit the scope of our broadcasts. In other words, limiting the transmission of broadcasts to hosts that actually need them. That’s a topic we’ll come back to quite a bit in the next section of the course.
Right now, it’s enough to see that between the possible data
collisions and unnecessary
propagation of broadcasts, hubs and repeaters have serious limitations in today’s networks.
Two devices that can help us with these collisions and broadcasts are bridges and switches, and we’ll cover those thoroughly in the next section of the course!
Take a moment to join over 28,000 students in my free and almost-free
Video Boot Camps on Udemy! There’s something for everyone, and there’s a discount code on the opening page for every paid course! My students have made me the #1 individual instructor on Udemy out of over 8000 teachers, and these courses are the reason why! Some free, some paid, all great! See you there!
Switching
Fundamentals And
Security
(Or, “I’d Rather Fight Than
Not Switch!”)
There was one more step between hubs / repeaters and the move to switches, and it was a giant step forward.
The introduction of bridges meant we could create smaller collision
domains, which in turn resulted in fewer collisions. Sounds great, and it was, but bridges didn’t
necessarily replace our hubs and repeaters. Bridges would typically be placed between multiple
repeaters and hubs, as shown in the next illustration.
Having more collision domains may sound like a bad thing at first, but the more collision domains you have, the fewer overall collisions. In this network, we still have the potential for collisions, but by
