Вы находитесь на странице: 1из 404

Welcome to Network+ N10-006

Welcome my friend to CompTIA's Network Plus N10-006. Let's get started. I wanted to take a few
moments in this introduction to chat with you, to tell you about how excited I am about joining you
in this journey to the world of Network Plus. Now, I realize that not everybody comes from the
same background.
We have different levels of experiences and different expertise. And regardless of the reason that
you want to master this content-- maybe it's a job promotion, or you want to fill in some of the gaps.
Regardless of the reason, I am super excited about logically taking you step-by-step through the
entire process.
And all it's going to take is like 10 to 15 minutes a day. And I guarantee you we're going to have fun
in every single Nugget. So I'm keeping this intro really, really short. And we can start the training
with the very next Nugget. I hope this has been informative for you, and I'd like to thank you for
Describe Routers and Switches
As a result of your and my time together, in this Nugget, we'll be able to describe exactly what a
layer 2 switch does for a living as well as a layer 3 IPv4 router. Let's begin. I'd like you to imagine
the last time that you were using a computing resource-- for example, a tablet, a phone, a computer.
And very likely, the chances are you're doing it right now as we talk together in this Nugget. And
when we boil it all down, the whole gist of network or networks is to share resources from different
devices. And in general terms, a device that is providing resources or providing the content is
referred to as a server.
So for example, a web server could serve up web content, an email server could provide email
content, and so forth. And that client piece would be the function that's receiving that content. For
example, a browser like Chrome or Firefox or Internet Explorer is providing the client function as
we connect up to web servers who are providing the content.
And if you, like me, when we're learning something new, if we have words or terms that are strange
to us, sometimes that's a barrier to getting past it. So what I want to do with you in this Nugget is
talk about some of the common devices that we're very likely to see all the time in computer
networks today and just talk with you one on one about the names of these devices and what they
do for us in the network.

So let's start off with the definition of network. When you see the term "network," what I would
love you to think about when you hear the word "network" is think about street, because you and I
are both familiar with what a street is. For example, your address for the place you live is very
likely on a street.
And other people who live on that same street with you also have that street as part of their address.
So in our topology here, we have Router 1, this little hockey puck-looking symbol. Everything over
here could be considered as one network or one street.
And that would include this Linux computer, the Windows computer, this guy over here too, this
printer, this server, and any other devices that may be on that common network. Now I'd like you to
think for a moment about the street that you currently live on.
Think about the name of that street. And having a name is a very common thing for a street to have.
So just like a street, a network is also going to have a name. And for right now, let's call this
network, this street over here that all these devices are on, let's call that Street Number A. And let's
for the purpose of discussion, let's call this little street right here between this router and this
firewall, let's call that Street Number B. And up here we have a switch and some public-facing
servers. And that's just a fancy way of saying we have some servers that can be accessed from the
And let's say this is Network Number C. And then over here we'll put Network Number D. And this
network between this router and this branch office, we'll have that as Network E. And the network
between this router and the internet service provider, we'll go ahead and call that Network F.
So what we're looking at right here is a collection of networks. And each one of them has a different
name, very much like each street has a different name of the street, Elm Street versus 1st Street and
so forth. So now here's the wrinkle. Let's say we have a user like Bob, who's sitting at this
Computer Number 2 right here, a Windows computer. And Bob wants to go out and connect to the
Well, any time that Bob wants to communicate with a server that's not on its local network-- so
Bob's on the local network, A, and he wants to get out to the internet, which is some different
network. Bob is going to need a little help. And he's going to get that help from a device called a

And in our topology, these little blue hockey puck-looking things, those are examples of IP routers.
And the question might come up, OK, what exactly does a router do for a living? And the answer is,
it routes. It makes forwarding decisions based on its routing table.
So a router plays a game of hot potato all day long. It gets a packet in. It looks at the address of
where this packet needs to go-- the street name, if you will. And then it makes a forwarding decision
based on what the router believes is the best way to forward that packet, that information, in the
direction of the network it needs to get to.
Now, these networks that we've identified as Network A, Network B, Network C, and so forth,
those are representing some type of an IP network address. So in IP, the acronym "IP" stands for
internet protocol. It can be used inside of our local companies and on the internet as well.
And an IP network address is simply like the name of the street that all of these devices are agreeing
to use in this area of our network. And what the router does for a living, it routes between networks.
So if Bob or anybody else here on Network A wants to get to Network B, C, D, E, F, or points
beyond, all those devices are going to need to use the services of this router.
Then it's going to be able to forward traffic between different IP networks. So we can say that a
router makes forwarding decisions based on IP networks. So the router's job is simply to make
forwarding decisions. When it gets a packet, it looks at where it's destined to, and then plays a game
of hot potato to forward it to the next device in the direction of that final destination.
Now, one term that we'll quite often hear-- I'm going to point it out right now-- is layer 3. And
inside of the data that's being sent across networks, there are different categories, or compartments,
if you will, for the information being sent. And that layer 3, that's where we tuck in information
such as IP addresses.
So because the router is making forwarding decisions based on IP addresses, sometimes a router is
referred to as an L3 or a layer 3 device. So let's take a moment and review what we've learned.
Number one, when we hear the term "network," we can think of a street name because an IP
network is very much like a street name that all the devices on that same street share and have in
common, just like all of our neighbors who live on our same street.
Now, if you and I want to send or receive information outside of our own local IP network, our own

local street, we are going to have to use the services of an IP router, which can do that forwarding
for us between IP networks. And because IP addresses are associated with layer three-- that's the
compartment, if you will, that they live in-- we'll often hear a router referred to as a layer 3 device.
The next question might be, well, what if we're not trying to communicate outside of our own local
street? So right here we have Street A. And what
if Computer 1 and Computer 2 want to talk directly to each other? Well, one of the aspects that's
true on an ethernet network-- and that's the most popular technology we're using for high-speed
local area networks. And that acronym is LAN, which stands for local area network.
The concept of LAN simply represents a group of devices, or networks even, that are in fairly close
proximity to each other and forward traffic at very high rates of speed. And that could be 10 million
bits per second, which is often referred to as ethernet 100 million bits per second, referred to as 100
megabits per second, which is also referred to as Fast Ethernet.
So I'll label these as Ethernet and Fast Ethernet. We have 1,000 megabits per second, which is
referred to as gigabit ethernet. And then we also have 10-gig and beyond as well. So back here in
Network A, if Computer 1 wants to talk to Computer 2, each of these computers in Network A has
an IP address.
Now, part of that IP address gives me that common street name-- for example, A. And then
individually these computers will have individual and unique IP host addresses. So maybe
Computer 1 is at .101 and Computer 2 is at .102, as an example. And for right now, we're simply
calling this common network segment Network A for simplicity.
And one thing I want to share with you about ethernet networks is that the network interface cards-that's the little network adapters that each of the computers has-- and the acronym for that is NIC,
for network interface card. So that's one of the names we might refer to that little adapter that
connects these computers to the network-- network interface card, or adapter, network adapter.
And these network adapters have their own physical address that's been burned in to those adapters.
For example, Computer 1, on its network interface card, let's say it has the address of cc, just as an
example. And let's say that Computer 2 has an address of dd. So these are physical addresses that
are burned in, if you will, to the network adapters from the manufacturer.
And from the category perspective, if we looked at where these addresses live and where they're
categorized, they are considered to be at layer 2. And the actual fancy name that they're given is a
MAC-- M-A-C, upper case. MAC, it stands for media access control address.

So on that NIC, it's got a media access control address. However, it's often referred to by a couple of
different terms. We could call it a MAC address on ethernet, or we could call it a physical address.
And because this is also associated with this little compartment called layer 2, it's often referred to
as a layer 2 address. So as a quick review, these two computers have a network interface card.
On each of those network interface cards, there's a burned-in layer 2 or physical address, which can
also be referred to as a media access control or MAC address, that they can use as they send and
receive data with other devices on this same local network.
Now I'd like you to imagine that Computer 1 wants to communicate directly with Computer 2. And
both of these devices are physically connected over what's called a switch. Computer 1 is connected
to Switch Number 1. Computer 2 is connected to Switch Number 2. And there's a cable that's
interconnecting Switch 1 and Switch 2 together. So again, everything over here on this left-hand
side for the moment is part of one network.
Now, focusing just for a moment on layer 2, if Computer 1 is sending information into the switch
which is meant to be received by Computer 2, the question I have for you is this. Do we want that
information to be sent out to the printer? Out to this device called the access point? Do we want it
sent out to the router? Do we want it sent out to the server? Or-- and this is the winning answer, by
the way-- do we want it sent just out to Computer Number 2? Who's the intended recipient of this
information? And the answer is, well, if it was email, Keith, I wouldn't want it to go to everybody.
I'd want it to go just to the person who's supposed to get that email. And I would agree with you.
And that's why we have this really cool device called a layer 2 switch. And here's what a layer 2
switch does for a living. It makes forwarding decisions based on the layer 2 addresses, the physical
or MAC addresses in an ethernet network.
So in our topology here, Switch 1 and Switch 2, they are listening to all the information coming in
to each of the ports on the switches. And by listening to the incoming frames, when Computer 1
sends a frame, he always includes his source address, his source MAC address, when he sends
frames into the switch.
And as a result, Switch 1, by looking at the source address of each of the frames, knows Computer
1's MAC address lives off of this specific port. The same thing would happen with Computer 2.
Computer 2 would be sending frames into the switch. And the switch would look at the source
MAC address.

And the switch would then learn dynamically that Computer 2's MAC address is reachable off of
this port. And that same logic happens over this interconnection between the two switches as well.
Now, our end result, which is what we're after here, is that a switch does not bother and waste
everybody's time by forwarding data that's not needed by those other devices.
So if Computer 1 sends a frame of data into the switch, the switch is going to know, oh, this is
destined for Computer 2. Then Switch 1 will forward it down the interconnection between Switch 1
and Switch 2. And Switch 2 will forward it just directly out to the port where Computer 2 is. And it
won't bother any of the other ports by sending it that information that wasn't intended for those
other ports.
So we could say that a layer 2 switch, which is dealing with MAC addresses, which are also
sometimes called physical addresses and/or also called layer 2 addresses on an ethernet network, we
could say that a layer 2 switch is making forwarding decisions based on that layer 2 information, in
the case of Computer 1 and Computer 2, only forwarding a frame of data where it needs to go and
not sending it everywhere else.
So if we do a little comparison here between switches and routers-- so here our device is going to be
a layer 2 switch. The layer 2 switch is making forwarding decisions based on layer 2 addresses. And
here is what I'd like you to do right now. On ethernet, I'd like you to give me a couple of terms that
we refer to when talking about these layer 2 addresses on ethernet. Can you remember the names?
And I'll give you a moment right now to think about the layer 2 addresses and the names for those
[HUMMING "JEOPARDY!" THEME MUSIC] Fade out the Jeopardy! music. OK, so if you said,
Keith, those are MAC addresses, which stands for media access control addresses, that is one
absolutely correct answer. Or if you said physical addresses, that would also be absolutely correct.
So on ethernet networks, those three terms are all synonymous. Layer 2 addresses, MAC addresses,
physical addresses, we're all talking about the same thing, the burned-in address given to a network
interface card from the manufacturer when they made that interface card.
So if we put a little dotted line here and we compare a layer 3 router, a router is making forwarding
decisions based on IP network addresses, which are an example of layer 3 addresses. And in the
world we live in today, most of the internet is using something called IP, which stands for internet
protocol version 4, as the layer 3 protocol. However, what's gaining popularity a little bit every
single year is IPv6. It's been out for more-- way more-- than a decade.

And since we're running out of IPv4 addresses, we are being pushed, as a planet, slowly towards the
use of IPv6 because there's more IPv6 addresses available. So the layer 2 switch makes forwarding
decisions based on layer 2 addresses. A layer 3 router is making forwarding decisions based on IP
network addresses.
And I've got one more question for you. What if someone made a box like this, and they had little
ports so we could connect into it, and this magical box was able to do layer 3 routing based on IP
networks and forwarding based on IP addresses as well as doing layer 2 forwarding based on MAC
addresses? What kind of a name would we give to this magical box? And I have a proposal.
I propose that we give this box that can do layer 2 forwarding as well as layer 3 forwarding, I
propose we call it a multi-layer box. Now, the term "multi-layer box" doesn't sound that glamorous,
so I suppose we can either call it multi-layer switch/router, which would be literally what it is.
However, here's what the industry calls this box which has those features integrated. They simply
call it a multi-layer switch because it can do the work at layer 2 based on MAC addresses and it can
do the work at layer 3 based on IP addresses. In this Nugget, we've identified the basic functions of
a layer 2 switch-- that's these guys right here-- as well as a layer 3 router, with the layer 2 switch
making forwarding decisions based on layer 2 information such as MAC addresses, and a router
making forwarding decisions based on IP information, such as IP network addresses.
And we've also come up with a term that we can use for a single box that has the ability to do layer
2 switching and layer 3 routing, and we're calling it a multi-layer switch. So here's our action items
for this Nugget. Two things-- number one, I'd like you to teach somebody about layer 2 switches
and IP layer three routers and what they do.
Now, you might think, well, Keith, I need to review this a couple times before I do that. That would
be your second assignment, then. Go ahead and review this video if you need to until you talk to
someone. It can even be over the phone, Skype, whatever. And just give them a brief overview of a
layer 2 switch versus a layer 3 router. Give yourself a big pat on the back.
Describe Firewalls and Load Balancers
In this Nugget, we're going to describe the functions of a firewall as well as a load balancer in a
computer network. Let's begin. Many years ago, when my kids were very young, we went to a
renaissance fair, and it was a lot of fun. Everybody's dressed up in their old renaissance-type outfits,
and there's food and activities from that period.

And one of the amazing things they had was this catapult. They had this huge catapult, and they
were doing demonstrations. So they loading up the catapult and firing it, and whatever they shot in
the air, of course, comes back down due to gravity. And unbeknownst to me, as we are walking up
there as a family towards this catapult, they were just launching something as we were walking up
to it.
And as I saw this object up in the air and then coming down, I thought it was coming right down at
my kids. And so what is a father to do, right? I just run at the kids, bowl them over to get them out
of the way and to protect them with my own life if necessary.
Now as it turns out, it was a pine cone. That really wouldn't have done a whole bunch of damage.
And secondly, it didn't even drop where they were. But my kids and my wife, to this day, have a
really good laugh about it every time they think about dad trying to protect the family.
In our high speed networks today, we also have devices that are out there to quote unquote "protect
the family." And one of these devices is known as a firewall. Now if you've ever seen NASCAR or
any kind of car race, you're probably also aware that the driver sits in one part of the car while the
engine is in a different part of the car, and then there's a firewall between them.
And that's there to protect the driver in one part of the car from the engine in the other part of the
car in the event that there's a fire. And so this icon right here represents a firewall. And one of the
ways I like to think of a firewall is by thinking of Nancy Reagan's policy regarding drugs, and that
was, just say no.
A firewall's attitude regarding traffic that is trying to come in from the outside is, generally
speaking, a policy of no, meaning, no, traffic cannot come in from the outside. Now we might make
some exceptions for that general rule. For example, if we have a couple of public facing web
servers right here, we might poke a couple of holes inside this firewall to allow traffic just
specifically for those services on those servers, so that John, or Jill, or some other user on the
internet could get access to those resources on those servers.
But that's it. And we're going to limit it down to the very minimum, the rule of least privilege that's
required for those users to get what they need from these servers. Another very common practice is
to chop up our network segments into areas. For example, this area here behind the firewall, we
may consider this the inside.
And if there's multiple networks here, those would be the inside networks. And then this area, where
we have some servers which we expect the public from the outside to be able to reach, we may call

that the DMZ, which is an acronym that stands for the Demilitarized Zone.
So these resources aren't sitting on the inside. And networks that lie outside of our control or
perhaps are untrusted, we often refer to-- from a security perspective and from a firewall
perspective-- we consider them to be the outside. So we could have an inside zone, if you will, a
DMZ, and an outside.
And the internet, from most customers' perspectives, is absolutely representing the outside
networks, the least trusted or untrusted networks that they need to be especially careful about.
Another big trend that's happening with firewalls is something called UTM, which stands for
Unified Threat Management.
And I'm going to give a shout out to two of my favorite vendors for unified threat management, and
those are Palo Alto and Checkpoint. They both do an absolutely fabulous job at what they're
designed to do. And with unified threat management, we can be looking for a lot of things.
For example, we want to be aware and stop any time personally identifiable information, or PII,
things like Social Security numbers, individual's bank card information-- we would like to make
sure we see that and stop it before that information is leaked out into the internet or to other
untrusted networks.
So a unified threat management system would have the ability to identify that type of traffic and
stop it before it gets out. And that's also a form of DLP, which stands for Data Loss Prevention. We
can also set up categories for websites that we don't want our users to go to.
For example, I think one that we can all agree on would be hate websites. We should never allow
our customers to be going to hate-based websites. So we can set up a category on our unified threat
management system so that if users attempt to go to a hate-based website, it can be prevented along
with a little message indicating to that user, hey, by the way, our acceptable use policy for the
network is that you're not allowed to go to these types of websites.
So we're simply going to say here, no hate. We also may very well have some policies in place that
prevent our users from going to the opposite of hate, love, and some love respective websites as
well. It all depends on our corporate policy. But a bare minimum, the goal of the firewall is to
prevent or stop certain types of traffic from one network to another, whether it's an outbound
request or an inbound request.

And generally, it's stopping individuals on less trusted networks, like the outside, from getting in.
However, it can also be used, as we demonstrated, to prevent some types of traffic from going out
as well. And generally speaking, firewalls are pretty tough devices.
They can take a beating, so that when they're connected to networks such as the internet, which may
have thousands or hundreds of thousands of attacks being attempted at our network, that firewall
needs to have the strength and robustness to handle it all and not go belly up in a flame of smoke
because it was overloaded trying to defend the network.
So I'd like you imagine this firewall is saying, yes, for specific traffic from the internet if it's going
to the web services on one of these two web servers. And as users start to use these web servers, the
popularity of our web servers grow. So we do is we add some more servers, so maybe we have six
web servers all connected to this switch on this DMZ portion of our network.
One of the challenges we have is if we have thousands of users on the internet who are accessing
these websites, and for our example, let's say that all of these servers have the exact same content
on them, how do we make sure that we have a nice, even balance of load across all these servers?
For example, we do not want to have this guy pegged at 100% utilization and have this guy over
here sitting around at 2%. This huge imbalance between the utilization between server one and
server six is likely to cause some problems because customers connected to server one may get a
very slow response or maybe even some timeouts while users connected to server six are likely to
have a good response.
So it would be better if we had, for example, a 20% load across all the servers to give all of our
customers great responses. Well, one way of accomplishing that, to help distribute the load more
evenly across their servers, is to use a load balancer. Now to implement a load balancer, we'd want
to go ahead and take one.
We could logically put in our network between the firewall and the servers that we have. Let's say
we have six servers to play with. They all have the same web content on them. And this device
could be either a physical device or a virtualized device. So this is our LB, short for Load Balancer.
And two very popular flavors of load balancers that are out there today include F5, which is not
only the name of their company, but it also happens to be a key almost everybody's keyboard. So F5
makes a product for load balancing. And another very popular load balancing device is called the
And the NetScaler is made by a company called Citrix. So what we could do-- on this load balancer,

we'd have some type of a virtual server that represents acme.com. So let's say this is
www.acme.com, and whenever users on the internet go to www.acme.com, those packets are routed
to this load balancer.
And then on the load balancer, we can set up the load distribution method. We could say round
robin. For example, with round robin, if we have user one that makes a request to acme.com for
web services, that request is allocated to server one. If we have request number two from another
user that goes to acme.com, that request goes over to server number two.
And request number three that goes to acme.com, that one is proxied over to server number three
and so forth. And that would be an example of round robin load balancing. And there's lots of
different mechanisms we could have this load balancer use to determine which server to send the
request to.
It could be on the least number of connections, and there's dozens of other variables that we can use
as well. But the overall goal is to have one unified front that the internet sees and then behind that,
multiple servers where we can load balance across those servers.
And that helps us to maximize the resources. Instead of having one server that's at 100% utilization
and five servers that are at 0% utilization, it would be much better to have all of these servers at
17%-- we'll do some rounding there. 17% each, we're going to have a much better result for our
customer as a result of doing this load balancing across multiple identical resources.
In this Nugget, we've described the functions of a firewall as well as a load balancer in a computer
network. I have had a lot of fun in this Nugget. I'm glad that you joined me for it. I hope this has
been informative for you, and I'd like to thank you for viewing.
Describe IDS, IPS, and HIDS
In this Nugger you and I get to discuss and describe how we can integrate intrusion detection and or
prevention into our data network. Let's begin. There are lots of potential attacks that might be
coming into our network. For example, on our firewall, if we had permitted just the minimum
requirements to allow the user Bob on the internet to access one of our web servers, is it possible
that in Bob's communication with those web servers, he could be sending malicious content or
malicious requests? And the answer is absolutely yes.
And the follow up question, would we want to know that that was happening, and would we want to
protect our web server against that malicious attack or malicious traffic that Bob, the attacker, is

sending? And I think in most cases the answer is yes. Now, vendors have come up with some really
amazing solutions to help us identify and prevent those attacks from getting through our network,
and one idea was this.
For example, we could take one of these switch ports here on the switch, connect an IDS system to
it, which is an acronym for Intrusion Detection System, and then we could train this switch to take
all the traffic and replicate it, or copy it over to that port.
So now, in effect, this intrusion detection system gets to see all that traffic that is going to the web
servers. And then this intrusion detection system can use a variety of methods to identify whether or
not the traffic that's going to those web servers is malicious.
For example, one of the methods is to use signatures. And these signatures are looking for telltale
signs of specific attacks. So if vendor Y has 2,000 signatures, those signatures can be used to
compare the traffic against in looking for an attack. We also might have an intrusion detection
system looking for anomalies, and those anomalies could be based on what the normal traffic-- for
example, how much quantity and what types are normally present-- and then all of a sudden there's
a flood which does not match the baseline, or an anomaly could be based on the protocol itself.
For example, maybe it's an HTTP request going up to this web server-- by the way, HTTP is the
language of love when a web browser is talking to a web server. And maybe one of the requests that
is being made isn't a valid HTTP request. And it could be the attacker trying to manipulate or take
advantage of how the protocol is supposed to work by sending in a bogus command.
So an intrusion detection system we have the ability based on the methods implemented by the
vendor for detecting those intrusions, and then sending up red flags. Now, the problem with an
intrusion detection system is that by itself it doesn't stop the attack from happening.
It simply alerts us to the fact that there is an attack, and one of the reasons is that this intrusion
detection system, once it's seen the traffic, that traffic is already on its way to the server. The idea is
it's just getting copies of it. So the acronym for a network based intrusion detection system is simply
And then somebody really smart in the R&D department said, you know what? Let's do something
more than just alert to the fact that there's an attack happening. Let's go ahead and prevent it from
getting to its final destination. And that's called network based intrusion prevention system, or IPS.

And there's many ways this could be implemented. One way would be to disconnect the firewall
from the switch. So this cable here we'd have go over to our IPS device, and this IPS device could
be either a physical appliance, or it could be a virtual device running in a virtualized environment.
And this IPS device would have two interfaces. Another interface would go up here as well. So now
all the traffic between the firewall and the switch has to go through the IPS. So we could use the
same methods for detecting the attack, whether it's signature based, anomaly, protocol violation, et
But this time if the IPS sees the attack, it can say, wait a second, I think that's a bad idea. I'm not
letting those packets continue and make it all the way up to the server. So effectively we're stopping
the attack right here at the IPS appliance, and not allowing the attack to get to the server-- hence the
concept of intrusion prevention system.
We're preventing the attack from making it all the way to its target. Now, I'd like you and I to put on
our executive hats for a moment and imagine that you and I own this company, and we're
responsible for it. Now, if some vendor came in and said, hey, we'd like to give you an intrusion
prevention system, and it's free, what would we say? Well, first of all we'd want to make sure it
works and we're not being attacked by that device, but secondly, if it doesn't cost us any money,
We'd always want that. But of course the reality and the challenge is that a device is going to cost
money. In fact, a network based intrusion detection system, or an intrusion prevention system,
depending on how it's implemented, could be in the tens of thousands of dollars.
However, in our environment let's say we have one web server-- let's say it's server number one, and
we only really need to protect that one server. We don't need to protect an entire network of devices,
just one server. Maybe we decide to do the intrusion detection slash prevention in software running
on that server.
And so if we have software that is acting as intrusion prevention or intrusion detection running on
just that server, we refer to that as a host based intrusion detection slash prevention system, and the
acronym is HIDS. So it really should be HIDPS, but how the heck are you going to pronounce that?
So an intrusion detection slash prevention system that runs as software on a critical resource like a
server is referred to as HIDS-- Host Based Intrusion Detection System.
And if we take this concept of intrusion detection slash prevention one step further, why not
integrate it in devices that are already in our network? For example, maybe we'd integrate the

intrusion detection slash prevention system into an existing router, and many vendors have that
Or even better yet, why not integrate that function of the IDS/IPS, depending on which way we
want to go, inside of our unified threat management system. For example, Palo Alto and Checkpoint
both have those features that you can purchase as integrated components of their firewall systems.
And from an earlier Nugget we discussed that UTM stands for Unified Threat Management, and it's
a really cool term that's used to identify a firewall that has a boatload of services. For example,
besides just filtering of traffic, we could also add on top of that intrusion prevention or detection
services as part of that same device on our network.
In this Nugget we have identified the purpose of an intrusion detection or prevention system, and
how it could be implemented in our network. I appreciate you joining me for this Nugget. I hope
this has been informative for you, and I'd like to thank you for viewing.
Describe Modems, Hubs, and VPN Concentrators
In this Nugget, you and I get to take a look at a couple older technologies that we won't see too
much anymore in current networks, as well as a newer one with VPN concentrators. Let's begin.
Back in the 1980s, when I first began my networking career, the internet, it still existed, but it was
nothing like it is today.
It wasn't really available to everybody back in the '80s. So we have a user like Bob, who normally
sits at this computer and then accesses the file server as a resource here. If Bob goes home and now
he's sitting at his house-- so this is Bob's house-- how can Bob get access to those same resources
without having to drive in? And one of the answers back in those early days was to use another
cloud, except this cloud was called the PSTN, which stands for the Public Switched Telephone
So Bob's house had a telephone line. And this was an analog circuit to that phone. So Bob picks up
the phone. There's dial tone. And it's an analog signal from his phone and from his house to the edge
of the network. Well, unfortunately, Bob's computer is not an analog device.
It's digital. So how in the world do we get a digital device to communicate across an analog
network? And the answer is we need to get a translator. And that translator has a name called a
modem. And modem itself is a shortcut of two different words-- of "modulator" and "demodulator".

However, you and I can just think of a modem as a translator between digital and analog, two
different types of signaling. So Bob's PC would have a cable that connected to the modem. And
there would be another connection on a modem for the phone connector.
And that's how Bob could connect his computer to the public switched telephone network. And of
course, the headquarter site would have another little modem here, or it could be a bank of modems
oftentimes that would be integrated into a line card on this router.
And then this router could be referred to as a Network Access Server, or NAS for short. Sometimes
it's also referred to as NAD for Network Access Device. It simply means that when Bob wants to
connect to the corporate network, his PC connects to an analog modem, which allows a circuit
across the public switched telephone network to connect to the modem and network access server,
and give him access into the network.
So an analog modem is something that I haven't personally used in probably over a decade.
However, as a backup solution or an alternate method to reach our gear that we need to manage, we
still may have some analog modems in place today. But if they're there, they're rarely used.
And the sound that an analog modem makes as it's negotiating and establishing a connection sound
something like this. [SOUNDS OF MODEM DIALING] And on your smartphone, if you currently
use that as the ring tone for your smartphone-- brother, it's me-- because I think that is really, really
Another throwback to a different time is the hub. And unfortunately, hub is not an acronym for
anything. It's just a word-- hub. And one of the things about hubs is that they look a lot like
switches. So for example, if we were to replace these labels with hub-- hub1 and hub2-- and we
changed the icon on the top to represent a hub, to the end users on this network that isn't very busy,
they may not notice the difference.
However, behind the covers, the details of the hub is significantly different. In our earlier Nugget
we took a look at switches and how switches make forwarding decisions based on layer-2
addresses, such as Mac addresses on an ethernet network. Well, a hub is not that smart.
It's not as smart as a switch. And it doesn't have any clue that there's any such thing as a layer-2
address. So the hub, if we're going to compartmentalize its functionality, it is considered a layer-1
device, because all the hub does it receives bits in on a port and it simply repeats them on the other

So in our topology here, if these two devices were hubs, and computer 1 sends information out into
the network, the hub is something I can send it everywhere-- I'll send it to the printer, I'll send it to
the access point, I'll send it to the router, I'll send it down to hub2, I'll send it out to the internal
server, and I'll send it out to the computer.
And unfortunately, if that message was only for one device, all the other devices had to waste a little
bit of time and looking at those signals that were coming in. And another bummer about a hub is
that only one device can communicate on the network at any given time if we're using a hub.
And the reason for that is because the signal is sent everywhere. In a switched environment, where
we have these signals being sent from one port to another specific port, it's possible to have multiple
communications happening simultaneously. However, in a hub, it's one person only getting to talk at
any given time.
So a hub is a layer-1 device. It kind of physically looks like a switch, because it has ports like a
switch, but it acts and smells like a dumb repeater. That's because at layer 1 it's just repeating
whatever it hears come in on one port, it repeats those signals on every other port.
So for those reasons, we rarely, if ever, use hubs in our production networks. Instead, we use a
layer-2 device called a switch that's more intelligent. Now, in the 21st century, if we have a user like
Bob who is normally using this computer here, but happens to have gone home some evening or is
home for the weekend, and now he's at his house, it's very likely that Bob's house is connected to
the internet.
And that could be through cable modem our DSL, or some other high-speed mechanism. And today
it's very likely that if Bob needs access to the corporate resources, for example, this internal server,
it's very unlikely that Bob's going to use an analog modem to connect when he has high-speed
internet connectivity already in place.
Now, here's the challenge. Even though Acme Incorporated is connected at a high speed to the
internet, and so is Bob, we don't want to send traffic over the internet naked, meaning plain text, not
encrypted, because if we do, individuals or entities on the internet may eavesdrop on our traffic and
see confidential information they shouldn't have access to, such as our usernames and passwords.
So to solve that, we're going to use something called a VPN. And VPN stands for "virtual private
network." And virtual private networks today are going to use one of two technologies to implement

their security. One is called IPsec, which stands for IP security.

And the other is called SSL, which behind the scenes actually may be using something called
transport layer security. And the details behind these protocols that are used as part of a virtual
private network we'll save for another Nugget. And as Bob builds a virtual private network from his
PC at his house over to the corporate resources, that VPN tunnel has to terminate or end at some
And one of our options is to use a VPN concentrator, which is a device that we could implement.
And it's very likely going to be on our DMZ of our network. And then when Bob builds those
connections, we could terminate to that VPN concentrator, so that way other employees like Lois
and Sally, and Kim, and Julie would then build their remote access VPNs-- and those are what RA
stands for, by the, way is remote access VPN, a user out there on the internet building their own the
virtual private network to corporate headquarters.
And the benefit of using a VPN, [INAUDIBLE] number one, we have confidentiality. And that's
provided courtesy of something we like to call encryption. Encryption is the scrambling of data so
that any unauthorized eyes, or somebody's looking at the data. If they're not authorized to see it,
they won't be able to tell what the data is.
It's all gobbledygook to them. The second benefit is authentication. For this VPN that Bob's
building Bob has the ability using the technologies involved to validate that this VPN concentrator
really is Acme Incorporated's VPN concentrator, and not some other companies' or some hackers'
VPN concentrator.
And conversely, the VPN concentrator will also have the ability to authenticate Bob and verify that
it really is Bob, the authorized user, who is supposed to have access to the inside resources and who
is authorized to build the VPN. And the reason it's called a VPN concentrator is because it could
potentially support hundreds or thousands or tens of thousands of simultaneous remote access
connections from users coming from all over the globe.
And many times this VPN concentrator function isn't done in a separate appliance, because many
vendors, including Palo Alto, Checkpoint, and Cisco have integrated that functionality of the VPN
concentrator into their firewall solution. So the firewall could act as a unified threat management
system, as well as a VPN concentrator for being the termination point, or the ending point, for the
remote access VPN sessions that are coming in.
So comparatively, if we go back in the time machine 20 years ago, we'd see a whole bunch of users

with analog modems, building connections over the public switched telephone network to get
access to corporate resources. And today, we're going to see very little, if any, analog modems.
But instead, we'll see high-speed connectivity to the internet and then using the technologies of
IPsec or SSL to build virtual private networks over the internet to our corporate locations for the
benefit of the confidentiality that that VPN brings for us, as we send our traffic over the public
In this Nugget, we've discussed a couple of old technologies, including analog modems and hubs,
which we don't use too much anymore, as well as a more current implementation of remote access.
And that is by using some type of a VPN concentrator to terminate our remote access, VPN
sessions, coming in from the internet.
Describe Packet Shapers, Content Filters, and APs
In this Nugget, we get to discuss packet shaping, content filtering, and the role the access point
plays in our networks today. Let's begin. I had a friend once tell me that the harder he worked and
the more prepared he was, the luckier he was, which translates into, if you're prepared and you work
hard, it's very likely that better things are going to happen to you than if you didn't work hard and
didn't prepare.
And I'd like to apply that concept to this link right here in our network, which is connecting Router
2 from our corporate headquarters over to a branch office. They've got a small router over there.
And for this link, this looks like kind of a lightning bolt.
This is a representation of a Wide Area Network connection. Maybe Las Vegas is where our
headquarters is, and maybe this branch office is in Reno, Nevada. So a Wide Area Network provider
who has that connectivity is renting to us or leasing to us that Wide Area Network service.
And that's often referred to as WAN, Wide Area Network. Geographically separate locations are
usually connected at moderately slow speeds. So over here at ACME on the left, we have a Local
Area Network, or a combination of Local Area Networks that are connected together.
And then at the branch office, they've got a Local Area Network out here. And we have a Wide Area
Network connection that's connecting them together. Regarding preparing, what if this circuit we
were leasing from the Wide Area Network service provider, what if it was only 256 kilobits per
second?-- which by today's standards is pretty slow.

And with this slow circuit in place, what if we have a whole bunch of traffic all at once that needs to
go across the circuit? Maybe we have somebody in this branch office that has an IP-based
telephone. And this user over here at the branch office with their IP telephone is having a
conversation with this user.
And this user over here on Computer 1 is running some software on their computer that allows that
user to use Voice over IP. And the acronym of VoIP for Voice over IP, is the concept of using voice
calls but setting the data over our data networks. So back to our scenario, we've got this voice call
that's happening.
Let's say we have another user. Let's say it's Lois here. And let's say that Lois is sending a huge file
transfer between her computer and some server that's over here in the branch office. And maybe
we're using FTP, which is the name of a protocol for File Transfer Protocol that can be used to move
And we have another user here in the branch office. Let's say it's Sally, who wants to send a print
job over to the network printer at the corporate offices. So we have a telephone call. We have a file
transfer. We have a print job. And unfortunately, if this link is 256 kilobits per second, it may or
may not be able to handle all of that traffic at once.
So how do we deal with that? Well, the secret is to plan ahead. And what we could do is we could
set up some type of a packet-shaping methodology. So this may be referred to as a package shaper
or a traffic shaper. And effectively what it does, it pre-decides on how we're going to treat this link
in the event we have congestion and we can't send everything all at once.
So we could prioritize our applications. For example, for Voice over IP, what happens if we delay or
drop Voice over IP traffic between the two users having the voice call? The answer is, if we drop
enough of those packets or we delay them significantly, the voice application will not work.
So I would consider the Voice over IP a pretty high priority. Now, regarding the file transfer
protocol, what happens if the file transfer protocol gets delayed a few milliseconds or few seconds?
As long as the packets all get there, is anyone really going to notice or care? The answer is probably
And the same thing to be true for a print job that's happening over the network. For example, if
Sally sends a print job over to this printer, Sally is not even in that room. So that print job could be
delayed, and no one would know or care that it got delayed by a few seconds.

So by using a traffic shaper or a package shaper, they're both synonymous. We could categorize our
traffic as far as high priority and then perhaps medium priority. And if we had some traffic that we
absolutely did not care about, we could classify that as a low priority.
And then on this link, when push comes to shove, using our traffic shaping we can give a little bit
more bandwidth to the Voice over IP, a little less bandwidth for FTP and print jobs, with the goal
being that the applications that need that real-time bandwidth can get it and the applications that can
survive a few seconds or a few moments of delay very likely won't even know that it happened.
So packet shaping and traffic shaping answers the question of, what do we do when there's not
enough bandwidth, and how do we handle that? And another term that we often use for categorizing
traffic and then prioritizing certain traffic over other types of traffic in the event of congestion is
Quality of Service.
So whatever we see the term QoS or packet shaping or traffic shaping, I'd like you to think of unfair
treatment. We're treating some traffic better than others in the event of congestion when it happens
on the networks. And most of the time, the congestion that happens is going to be happening on the
slowest links that are found in our infrastructure.
In this case, it's our WAN link between the Acme Local Area Network and the branch office Local
Area Network. And that package shaper functionality, that could be either integrated into the
routers, or we might have separate devices at each end that are managing and controlling the packet
shaping that's being done across that serial link.
In our Nugget on the firewall, we touched on several things that firewall can do, including stopping
traffic, for example stopping traffic that's coming in from the outside that shouldn't be allowed in, as
well as stopping certain types of traffic from going out, including personally identifiable
information such as social security numbers.
We also mentioned that we could do content filtering so that if a user was trying to go to a website
that's not allowed by policy, we can go ahead and stop that request from ever making it to the
outside world. And I don't know if I mentioned it or not, the actual term for doing that filtering,
based on the type of website or URL we're trying to go to, that is referred to as content filtering.
And I wanted to make sure that you and I had talked about that label of content filtering in
association with the function of stopping a user from going to a specific type of website based on

policy at our company. So the content filter would be a technical control that we can implement to
enforce our company policy.
What I'd also like to point out is that if we are using a content filter, it could be a network device, an
appliance. So for example, we place that in our network. So here's our content filter right here. And
if we had a firewall that couldn't do the content filtering itself, we could train the firewall to go
ahead and redirect traffic down to the content filter.
The content filter could reroute it back up to the firewall in the event it was acceptable traffic. If it
wasn't acceptable, meaning it was denied by the policy set up in the content filter, the content filter
could go ahead and stop the traffic right there and prevent them from going out to that site, which is
prohibited through company policy.
One of the really amazing advancements in the last decade or so is wireless with Wi-Fi. I mean, we
have restaurants with free Wi-Fi. Most homes have Wi-Fi. Most businesses have Wi-Fi. And the
benefit is we can take a computer like this guy right here that has a built-in network interface card
that's using Wi-Fi signals, which is just radio frequency, to connect to the network.
It's very, very convenient. You don't have to have a physical wire plugging us into a switch.
However, it is important to know what device on the network is sending and receiving that Wi-Fi
that allows this customer to connect. And the answer to that is something called an access point.
The acronym for an access point is simply AP. And an access point would generally connect into a
switch. So there's a wired connection from the switch to the access point. And the access point is
responsible for the sending and receiving of these radio frequencies so that devices like Computer 3
can associate with an access point, authenticate, and get connectivity into the network.
And these access points have lots of different flavors. They have some that focus the direction of
the radio frequency signal in a certain direction. That would be an example of a unidirectional
antenna. And they have some that simply emanate the signal in all directions around them.
And that would be an example of an omnidirectional antenna. And we'll cover more when we talk
about specific Nuggets on wireless. And in a home network, it's very likely that if you have a router,
there's very likely the access point, the Wi-Fi capability that's integrated into that home router.
So for a home router, it might look like this. We might have a connection that's labeled WAN or
Internet. That's the one we plug in to our internet service provider's gear. That may be DSL, or it

may be cable modem that goes off to the internet service provider in the cloud, the internet.
And generally, they have four Local Area Network ports. These would all be for connecting devices
inside your home. And these are simply Layer 2 switch ports. So as you connect devices to these
ports, let's say we have PC 1, 2, 3, and 4, each of these four computers has their own Mac address.
That's the Layer 2 address. And with the Layer 2 switch, if PC 1 and PC 3 are communicating with
each other, a Layer 2 switch only forwards those frames of data to the ports that need that
information. Now at the same time, this box is also doing routing.
So it's also acting as a Layer 3 router. Because it's routing between this internal network where your
four computers are and the Wide Area Network, or the WAN connection, or the internet connection,
that goes off to the service provider and leads towards the internet.
And the way we got started on this whole discussion was the fact that this access point could be
integrated into this router. So with antennae that could be either internal to this box or external,
there may be two, there may be three, there may be four. It depends on the model.
That would be adding the additional Wi-Fi capability so that inside your home you have devices, for
example Device Number 5, which is wireless, which would now have access to your Local Area
Network. But instead of having to use a cable, it's connecting to the access point that's integrated as
part of your home router.
And for the routing part, these four ports and this access point here, these would all be, for example,
Network G, just to label it as an IP network. And then this port would lead off to a different
network, including the internet. So the Layer 3 routing is done between your internal network at
home and the Wide Area Network, or the internet connection, that's being provided from your
service provider.
So for example, maybe this is Network H over here. And the Layer 3 routing is doing routing based
on IP addresses between two IP networks. In this Nugget, we've discussed the function of three
additional components in our network, including a packet shaper, content filter, and an access point.
DHCP Concepts
In this Nugget, you and I get to look at the concepts behind dynamic host configuration protocol.
Let's begin. I'd like you to imagine that you and I are the network administrators and designers of

this network. And what you and I have decided is that this network over here-- the left-- we're going
to name it the network, and we'll make this a 16-bit network. Now we're going to have a
dedicated set of Nuggets just for IP addressing.
For now, I'd like the first two numbers here-- the 10 and the 1 in this example-- represent the street
name, also known as the network number, for our network. So this network is going to have the
name of 10.1. Now one of our challenges in this network is that every device is going to be on the
10.1 network-- that's not so tough, but each of these devices also needs to have its own unique host
identifier or host address.
And the host address I'll have right here in green and in our network it's going to be these last two
numbers, 0.0. So maybe this computer's going to use 0.100. And maybe computer 2 is going to use
0.101. And that printer is going to use 0.102. Now if you and I went in and we manually had to
implement each of these IP addresses on each of these devices, that's referred to as static
configuration of IP addresses where we manually do it in a static fashion on each and every device.
And we may use static in a production environment on critical devices. For example, on a server
where we always want it to have the same exact IP address. Or a router interface, where we wanted
to have the exact same IP address every single time. However, for other devices like computer 1 and
computer 2-- if we want to optimize your and my time as we give IP addresses to these devices-instead of configuring the computer statically, we can use DHCP, which stands for the Dynamic
Host Configuration Protocol.
It's a way we can automate the assignment of IP addresses to devices on our network. And the basic
concept of DHCP is done between a client. A client is a device that would like to get an IP address.
And a DHCP server-- that's a device that knows about a pool of IP addresses that it can hand out
and is willing to do so.
And here's the play-by-play. The client, when it wants an IP address, issues a discover message. And
effectively, the discover is saying, hey, I'm looking for some help. I need a DHCP server who could
possibly assign me an IP address. And the DHCP server, if it hears that message, is going to
respond, and it's going to respond with an offer.
And in that offer, it's going to say, hey, I've got a beautiful IP address. I think you'll like it. It's yours
for the taking. To which the client can say, great, I'll take it. And that's called a request. And then
there's a final message that's sent from the server back to the client, and it's called an

I'll put A-C-K for short for acknowledgement. And in that acknowledgement, is just going to
confirm the details. For example, this is the IP address you're going to use as well as additional
options that the DHCP server can provide to that client. And a great way to remember this backand-forth for DHCP between the client the server is to a children's cartoon called Dora the
It doesn't even rhyme, but it doesn't matter to much. D-O-R-A, which stands for discover, offer,
request, and acknowledge in that order. Now, to set this up, we need to identify a device on our
network that will act as a DHCP server. Now we could have the router if the router supports that
We could add this DHCP service on the router itself. Or, we could have it done on a server. For
example, a Windows server is very able to be a DHCP server as well. So it just depends in our
network what we have available to be acting as a DHCP server and where we want to enable it.
So whatever device we choose use as a DHCP server, whether it's a router or an internal server,
we're going to identify on that DHCP server a pool of addresses. So in this case, it would be on the network. And maybe our pull addresses will be from 0.200 through 0.225. So again here,
the 10.1 represents the network portion, and the 0.200 through 0.225 will be our individual host
addresses that we're handing out to DHCP clients.
And there's a fancy name for that pool, and they call it a scope. So if we see the concept of scope,
simply think of that as a range of DHCP addresses that a DHCP server is willing to hand out to
people that ask for it. Now if we do have a client, let's say computer 1 becomes a DHCP client, and
it sends out a discover, and there's an offer, and the request, and the acknowledgement.
How long exactly does computer 1 get to keep and use that IP address? And the answer is it depends
on the lease. For example, a DHCP server could say, OK, this lease is good for eight days, which
would imply to the DHCP client that before the eight days runs out, it needs to make other
Either it needs to renew that lease for another eight days, or it needs to find another DHCP server.
But the lease information is the amount of time that a DHCP client is allowed to use the IP address
that's been dynamically assigned to it via DHCP. Now sometimes when I go out to eat for fast food,
I'll pull out the food.
Then at the very bottom there will be some fries at the very bottom. I'm thinking, wow, cool, bonus!
Some extra fries! Well, inside of a DHCP offer as well as the acknowledgement, there is also

included some DHCP options. And options can be very handy for a client.
For example, in this network, computer 1 needs to know about the IP address of its default gateway
that it can use if it ever hopes to get off of the local network. So one of the prevalent options that
we'll often see inside of a DHCP offer, as well as the acknowledgement, is the option of a default
gateway for that client to use.
Another very important aspect would be a DNS server. DNS stands for domain name system. We'll
have a separate Nugget just on that. And a DNS server gives a client the ability to translate the
name, like www.cbtnuggets.com, to an IP address, which is critical for IP communications to work.
So two examples of options inside of a DHCP message would include a DNS server and a default
gateway for the client to use. And there may be situations where we want our client to be a DHCP
client, but we don't want that client to get a random IP address.
Instead, we can set up a reservation and we're all familiar with reservations. If we have a reservation
at a restaurant, we show up and boom, they take us to the table. Well, in DHCP, the reservation isn't
just guaranteeing a table. It's also guaranteeing an exact table every time for a client.
So if computer 1 had a reservation for the IP address of 0.206, the DHCP server-- when assigning
an IP address to that computer-- would assign that specific IP address due to its reservation. Now
one of the challenges that we're going to have in our networks is that maybe we don't have a DHCP
server directly connected to every network.
And maybe we don't want our routers who are connected to every network to act as DHCP servers.
Is there a way that we can have one centralized DHCP server? For example, over here be the DHCP
server for multiple different networks, and the answer is yes. And we do it with a little feature called
IP helper or IP relay, and it works like this.
On our DHCP server, we create multiple scopes. So we have a scope for subnet A and subnet B and
subnet C. And for each of these scopes, we've also identified options, such as DNS servers and
default gateways. And then we ask this router through configuration to be a good buddy, and any
time it sees a DHCP discover packet, to go ahead and wrap it up and ship it up to the DHCP server.
At which point the DHCP server will look at that packet and determine, oh, this came from this
specific subnet. Let's say it's subnet A, for example. The DHCP server will see that it has a scope for
subnet A, and it will offer an IP address from that pool back to the IP helper function.

In this case, the router using the IP helper. At which point, the router would make the offer back to
the client. So it's like DORA happening twice. So here we have the client, here we have the relay,
and here we have the server, and I'll box the client as well over here.
So the client does a discover that's forwarded to the server. Then there's the offer that comes back
this way, then the request, and then the acknowledgement. And you might think, well, Keith, why
does the router have to act as a helper for DHCP? The fact of the matter is this client computer does
not yet have an IP address.
It does not yet have a default gateway. It can't on its own power get off of the local network
segment because it doesn't have an IP address, and it doesn't know anything about the default
gateway to use yet before it has an IP address assigned to it. In this Nugget, we've taken a look at
the concepts behind dynamic host configuration protocol along with several of the terms and
concepts associated with DHCP.
DHCP Configuration
In this Nugget, you and I get to roll up our sleeves and do some configuration. First, we'll configure
a Windows 2012 server, and tell it that we want it to be a DHCP server. We'll also configure these
services on a Cisco IOS router to act as a DHCP server.
And then we'll take a look at how to configure a client to either have a static address or to be a
DHCP client. Let's begin. So in a production network, we really wouldn't have to do it on both
devices, but I wanted to give you options and show you how to do it on both.
So we'll start with a Windows 2012 server. I want to take a look at, first of all, what the IP addresses
are. So currently, this computer, the Windows Server, is sitting on that 10.1 network. The first two
numbers are 10.1. And in our network, that represents the street name for network A.
And the host address of this server on that network is 0.111. So what we'll do is we'll go to tools and
we'll select from the Tools menu DHCP for Dynamic Host Configuration Protocol. And here we'll
expand the DHCP section under the server. We'll go to IPv4. And currently, I've got a couple of
I've got a scope for the 10.44 network and a scope for the 23.1.2 network. And what we want to do
is we want to create a new scope for the 10.1 network. So to do that, we'll right click on IPv4. From
the drop down, we'll select New Scope. And we're going to walk through the wizard.

It wants us to give a friendly name to this scope. We'll call this NetPlus 10.1 because that's the
network it's going to represent. We'll click on Next. It's now asking us for the starting address. So
let's give it 10.1.0. And let's give it 225. And for an ending address, let's use just as an
So hopefully, we're not going to have a whole bunch of devices in that network that need IP
addresses because with this scope we're not making a huge amount of IP addresses available. 225
through 250 is 26 individual IP addresses that we're willing to hand out.
And for the length, here it's asking regarding the length of our network. I'm going to put in a 16-bit
length, which in dotted decimal represents 255.255. And we're going to have a separate Nugget just
on IP addressing and subnetting. But for now, please note that this means that the first half
represents the network and the back half represents the actual host ID or host number on that
And we'll click on Next. It's asking us if we want to exclude any specific IP addresses in that range.
And in our example, I'm not going to exclude any specific IP addresses. It's asking us next, how
long do we want the lease to be? By default, it's saying, hey, let's give those IP addresses out for 8
days. And for our lab environment, I'm going to change that to 0 days and 4 hours. And that'll be our
lease duration for these IP addresses when they're handed out.
Next, it's saying, hey, do you want to configure some really cool DHCP options that you're going to
hand out along with these IP addresses, like DNS servers and default gateways? And I'm going to
say, you betcha. Let's click on Next. It's asking for the default gateway that these clients should
Let's take a look at our topology just for a moment. If this is going to be the 10.1 network right here,
we probably want all these devices, if they need to use a default gateway, to use router 1. And
currently, router 1 is at the IP address of 0.1. So the full address of router 1 for this interface 3/0 is So I'm going to specify in the DHCP option that we're now configuring on this server,
we're going to specify that the default gateway we're going to hand out is So back at the
Windows 2012 DHCP Server Manager, let's put in the default gateway as And we'll click
on Add.
And then we'll click on Next. It's now asking about DNS. What DNS server do we want to hand
out? DNS is Domain Name System, and it's the magic by which a computer can determine the IP
address from a name. So for example, when Bob goes to google.com, a DNS server is used so that

Bob's can figure out what the IP address is associated with google.com.
So this Windows Server, by default, is putting in its own IP address on a different network. I'm
going to remove that. And I'm going to add in And click on Add. And that is the IP address
of a public DNS server from Google. And what the DHCP Manager just did, it went out and
checked and verified that DNS is working and running on that system.
And as a result of that testing successful, it allowed me to add it as an option. So we'll click on Next
to continue. It's now asking about NetBIOS name resolution. A long, long time ago, in a galaxy far
away we used NetBIOS name resolution. We don't need it in our network because everything's
going to be resolvable via DNS.
But if you need WINS, Windows Internet Name Service, you could include that option as well right
here. We'll click on Next. And do you want to activate the scope now? And we can click on Yes to
go ahead and activate that scope. And then we'll click on Finish.
So now we have this scope, this pool of addresses that we can hand out from this DHCP server. And
if we wanted to delete or disable the scope, we could right click. And we could deactivate it or
delete it. And what I'd like to do is because I'm going to set up DHCP again on another device, I
don't want to have two DHCP servers competing to hand out IP addresses.
So on this Windows 2012 server, I am actually going to deactivate this scope. And I'll click on Yes
to confirm. So the scope for the 10.1 network is no longer active right now on this DHCP server. So
we created a scope here on this server. We deactivated it because I want to share with you how we
can configure DHCP services on a router.
For our example, router 1 will be running Cisco's IOS version 15.x software. So we're now sitting at
the command line for the Cisco IOS router called router 1. And we're going to go into configuration
mode by typing in the command configure space terminal.
And that gives us the ability to start configuring the details regarding this router. The first thing I'd
like to do is create a scope. Now, they don't call it a scope in a Cisco router. They call it a pool. The
syntax is IP DHCP pool. And we're going to name it.
We'll call ours OUR-DHCP-SCOPE, just to make sure we're clear what this is. Then for this scope,
we're going to specify what network range we're going to hand out IP addresses from with the
syntax network space And for the time being, please just know that the means that the first half of the IP address represents the network and the back half is
going to represent the host addressing for that network.
Sort of like a street name on the left and a house number on the right. If we're going to hand out a
default router to these DHCP clients, the syntax on the Cisco IOS router is default-router. And then
the IP address of the router they should use, the client should use, as a default gateway.
And the concept of a gateway and router are virtually synonymous. If we want to train our DHCP
clients regarding a DNS server that those DHCP clients can use, the syntax on an IOS router would
be dns-server and the IP address of the DNS server we want those clients to use.
In this case, we're using which is a DNS server provided by Google. Now currently, we're
sitting in this DHCP pool configuration mode. If we type in exit, that'll take us back out to the
global configuration on this Cisco router. And if we wanted to exclude addresses and tell this router
not to hand out-- for example, the 0.1 through 0.99, we could do that with the command ip dhcp
excluded-address, the start range of and the end range of So that basically tells
this router, please don't hand out any of those IP addresses.
Start somewhere above that. Now, those commands that we entered are alive and active. However,
if we want those same commands to be around when we reboot this router, we need to also save
those changes to the startup configuration on this router. And the syntax for that is copy runningconfig space startup-config.
And that way the next time we reboot, those changes will still be there on this router. Next, let's go
to the client that will be the DHCP client. And let's do two things. Let's take a look first at how to
configure a static IP address, including details such as the default gateway and DNS servers that this
computer should use.
And then we'll take a look at how we can use DHCP to do dynamic assignment of an IP address to
this computer. So currently we're at the desktop of computer 2. Now in order to get to the control
panel for the network attributes, there's lots of ways of doing it.
We can click on the Windows icon. And we can type in control and go to Control Panel that way.
And then from Control Panel, there's different views that we can use. But if we go down to Network
and Sharing Center and then Change Adapter Settings, that's one way of getting to the properties of
the network adapter for this Windows computer.

Another option would be to right click on the icon on the bottom right, click on Open Network and
Sharing Center, and then Change Adapter Settings. That also gets us to the exact same place. Now,
this interface on this Windows 8 computer is currently disabled.
Now, before we enable it, let's you and I go in and take a look at how to statically configure the IP
address and the options such as default gateway and DNS on this computer. And one way of doing
that is right clicking on this interface. From the drop down menu, selecting Properties.
And then scrolling down here, I'm going to disable IPv6 for the moment because we're not using it
at the moment. Stay tuned though for additional Nuggets in this course on IPv6, because it is
coming. But for now, let's go to IPv4. And we can either double click on Internet Protocol Version 4
or we can select it and click on Properties.
Either way is great. And what it's showing us-- and this would be the default behavior-- is that it
wants to obtain an IP address automagically. And that means use DHCP. It wants to be a DHCP
client. And that also goes for the DNS server. So it's going to learn the IP address via DHCP, the
default gateway via DHCP, and the DNS server it should use all via DHCP.
So if we wanted to configure this statically, we would simply click on the radio button that says use
the following IP address and we could plug-in the information. For example, 10.1.0. And let's use
105 as an example. And the subnet mask is going to be And for now, that just
represents that the first two numbers in this IP address are the network and the last two numbers
represent the actual host address on that network.
Sort of like street number 10.1 and house number 0.105. And the default gateway we want this
computer to use is But if we tap down, we can go ahead and put in the preferred DNS
server, which I'm going to put in as Google's at So we have statically configured, or at least
we will once we click on OK-- we've statically configure the IP address with its associated mask,
the default gateway this computer should use, as well as the DNS server it should use.
And we'll click on OK. And we'll click on Close. The other thing that would be really important to
do would be to enable this interface. So I'll right click on the interface, select Enable from the drop
down, and now we should be good to go. So if we bring up a command prompt- I'm going to click
on the Windows icon, type in cmd, press Enter.
That brings up a command prompt. Let's do a PING, which is an acronym for Packet Internet
Groper. But we all just call it PING. A great way to verify basic connectivity. And we'll test that
connectivity out to www.google.com and press Enter. And that reply coming back does two things

for us.
Number one, it helps us to confirm that the DNS is working. Because we said google.com, yet we're
actually going out to And because we got the traffic there and back, it also implies
that our default gateway is working. And so using ping to ping a name is a great way of verifying
several aspect of our IP configuration with one simple ping command.
So next, let's do this. Let's go ahead and minimize this command prompt for a moment. Let's go
back to the properties of Ethernet0. We'll right click. From the drop down, we'll select Properties.
And let's go down to IP version 4 right here. And let's change the properties so that we're using
dynamic host configuration protocol as a client instead of having a statically configured IP address
default gateway and DNS.
So to configure it for DHCP, we're going to click the radio buttons for obtain IP address
automatically and obtain DNS server automatically. And we'll click on OK. Now in the background,
what should be happening? There should be a discover that's being issued by this client.
There should be an offer from the DHCP server. In our case, that would be our router acting as a
DHCP server. The client would send a request saying, yeah, I love it. I'll take it. And then there
would be a final acknowledgement from the DHCP server. And in that acknowledgement, it will
also confirm the options, including the default gateway and DNS server that that client should use.
So to verify whether or not this is currently working, let's go back to our command prompt. And
we're going to use command ipconfig. Press Enter. And the command ipconfig on a Windows
computer will show us the IP address that we currently have-- It looks like the first IP
address from the pool on the DHCP server, the router.
It also has our default gateway of And if we use the Up Arrow key and use ipconfig
space /all, that will show us additional information above and beyond the basics. So the command
on the Windows computer IP config space /all shows us the IP address.
It also shows us details regarding the lease-- when it was obtained and when it's good till. Here's the
default gateway. There's the DHCP server. And here's the DNS server that was handed to us. And
we learned about that IP address, and the lease time, and the DNS server, and the default gateway
all from the DHCP server.
Now, what I have not yet told you, but I'm sharing with you now is the fact that I have captured the

traffic on this network link between the switches and the router for the intention of using something
called a protocol analyzer so we can see the details of what's really happening on the network.
And the protocol analyzer we're going to use to look at this capture traffic is called Wireshark. So
let's take a look at the traffic that happened on that network segment through the eyes of the
protocol analyzer called Wireshark. So here's what I want to share with you.
I have done a filter focusing on DHCP. I'd like you to notice there's a DHCP discover. And that's
from our Windows 8 client saying, hey, I need to find the DHCP server. There's an offer that was
sent from the router acting as a DHCP server. Inside that offer, if we take a look at it and we open
up the payload for that packet, you can notice here in this offer it's offering the IP address of, which is the IP address that in the next packet, the request, the client said, that sounds
I'll take it. And that was followed up by an acknowledgement from the DHCP server. And if we go
down to that acknowledgement and scroll up just a little bit, you'll notice that in this
acknowledgement, it's confirming some of the options. For example, we have the default gateway
of We have the domain name server at It's also including information regarding the
lease time, which on a Cisco router is a one-day lease by default when the router is acting as a
DHCP server.
So as you continue in your studies, if you're excited and want to learn more about Wireshark and
protocol analysis, I've got several courses right here at CBT Nuggets that really dive into protocol
analysis. One of them is the CCNA hands-on labs through the eyes of Wireshark and GNS3. And
there's another course just on Wireshark.
So I'm pointing out those courses to you now, so that you know that they exist as resources when
you're ready to start studying protocol analysis using Wireshark, which by the way is a blast. In this
Nugget, we've discussed and demonstrated how to set up a DHCP server on a Windows platform as
well as a Cisco IOS router.
We also took a look on the client side at how to statically configure IP addresses as well as train a
client to be a DHCP client. I have had a lot of fun in this Nugget. I'm so glad that you joined me for
it. I hope this has been informative for you, and I'd like to thank you for viewing.
DNS Concepts
In this Nugget, you and I get to discuss DNS concepts, which is the magic behind how a friendly

name, like Google.com, be translated into an IP address. Let's begin. I'd like you imagine our user
Bob sitting at his computer. He just powered it on. He's got an IP address, courtesy of DHCP,
Dynamic Host Configuration Protocol.
He also knows about a default gateway that he can use. And he's also been given a DNS server.
Now, the reason that DNS server is so critical for Bob's computer to be aware of is because when
Bob goes to www.google.com, from an IP network perspective, no one knows what's going on,
because www.google.com
is a name of a web server. And in order to get to that web server, we need to forward that traffic, or
the routers need to forward that traffic, to the right IP network. And that's where DNS comes into
play. What would happen is Bob's computer, when he types in www.google.com, in the background,
Bob's computer would make a DNS request. That's for Domain Name System. The acronym also
could be used for Domain Name Server or Domain Name Service. In any event, his computer
makes a DNS request. And that request is going out to a DNS server. And the request is going to
say, Dear Mr. DNS server,
I need to get to www.google.com. Could you please tell me what the IP address is for Google.com,
so I can send a packet to that server? And the server, if it can reply, will go ahead and respond back
to that client-- in this case, that's Bob's computer-- with the answer.
Oh, that's at 70.20.30.x. I'm just making up those numbers for a moment. And as you can imagine,
there's millions and millions and millions of names out there on the internet. How do we keep track
of it all? Well, we don't just have one DNS server. There's thousands and thousands of DNS servers.
And in the background, they're all working together for that name resolution. So if this server didn't
know about the answer to Google.com, it could go ahead and refer up to another DNS server to ask
that same information. So if this DNS server tells that DNS server, this one can cache it and then for
the information back to Bob.
And that way, if this server has to answer that same question over and over and over again, it
doesn't have to make a request every single time to another DNS server to learn that information. So
a cache is a place where we can store-- usually temporarily-- information that we've received.
So a DNS server may cache DNS information it learned from another server. And, as that answer
goes back to Bob's machine, Bob's machine is also going to cache that information. And the benefit

of that is that if Bob needs to go to that same destination over and over again, he doesn't have to
continue making DNS requests over and over and over.
So in this example, Bob's computer is a DNS client. And this server up here is a DNS server. And if
we label these servers as Server One and Server Two, we could also say that Server One was a
client to Server Two, because Server Two was providing the information that Server One needed.
And generally speaking, in a client-server model, the entity that's making the request is considered
to be the client. And the entity that's providing the information is considered to be the server. Now,
in life, one of the common, respectful things to do is if somebody asks for an apple, you give them
an apple.
If they ask for an orange, you give them an orange. Well, in DNS, we can help accommodate that by
having different record types inside of DNS. And although there are dozens and dozens and dozens
of record types, there's five that I want to share with you right now.
One is an A record. And A stands for an address record. And an A record is referring to a record for
IPv4 address. So for example, if Bob's computer is running IPv4 and he makes a request out to the
DNS server, and says hey, I would like the A record for the server www.google.com,
the server should respond back with an IPv4 address. Which may look like or some other
IPv4 address that's being answered or returned to Bob, the client. Now, another record type that's in
DNS or can be in DNS is a quadruple A record type. And you might think, wow, that looks like it's
four times as long as an A record.
And you know what? It is. So an a record for an IPv4 address is 32 bits in length. And a bit is a
single position they can either be on or off, like a light switch. So for now, you can think of it as 32
light witches long. And a quad A record with four As is an IP version 6 address record.
An IPv6 is 128 bits in length. So if Bob's computer had been running IPv6, and Bob's computer
made a DNS request looking for the quad A record for www.google.com, the response back from
the DNS server would be expected to be an IPv6 answer, which is 128 bits in length. Or rather,
that's the length of an IPv6 address. Another very common record type inside of DNS is an MX
record, which stands for mail exchange, spelled M-A-I-L.
And that type of record would be used, for example, by email servers, just trying to forward email
messages to another email server in a different domain. The CNAME record stands for canonical

name. And by using a CNAME, and we can do an alias from one name to another.
So for example, if we were searching for www.bubba.com, and there was a CNAME record there
that said, oh, what you really want is www.bubba1.com, that would be an example of a CNAME
record. That, of course Bob, at this computer, would continue the resolution of www.bubba-1.com
to an IP address.
And the last one I want to share with you here is a pointer record. And it's called a pointer record
because it actually points to a name. Now, most of the time, we're using DNS to resolve a name,
like www.CBTNuggets.com to an IP address. However, if we want to flip that, if we have an IP
address and we start there, and we say, what is the domain name associated with this IP address?
That's when the pointer record is used.
So we could say, for example, hey, this address of what domain is that associated with?
And the pointer record would point to a name. And that would be one of Google's servers. So when
you see pointer records, think reverse lookups-- having an IP address already and wanting to know
the name behind it.
In large organizations, it's very likely that companies are going to have their own internal domain
name system server. So when DHCP addresses and options are handed out, such as which DNS
server to use, the computers can be told to use the DNS server that's local to their company.
Then the challenge is, how does our internal DNS server know about the rest of the world? So
normally what we'll have is we'll have a service provider DNS server out here on the internet. And
our local DNS server will work in conjunction with the internet service provider's DNS server.
And that DNS server can then work with additional DNS servers as needed for resolution of
everything on the internet that's in DNS. So Bob makes a request to this DNS server. This DNS
server doesn't know. It makes a request to another DNS server. That answer comes back to our local
DNS server.
And the local DNS server feeds the answer back to Bob, regarding hey, google.com is at that this
address. And it can keep that in the cache on that local DNS server, so that future requests, for a
period of time, can be answered locally from the server without making additional requests.
Now, one of our challenges is this. If we have a couple of servers at our location. Let's say their web
servers, and we're acme.com. And let's say these servers are being load balanced, and we're calling

them www.acme.com. Our intention is that when Jill, out here on the internet, types in
www.acme.com, DNS is going
to resolve that to an IP address that is reachable right here. So it may be www.acme.com goes to our
load balancer device. Perhaps we hit F5 or NetScaler that has that IP address associated with
www.acme.com. And then our load balancer can then load balance between the two identical
servers that are sitting on our DMZ.
So working with a service provider, we'd have to, first of all, make sure we got the domain
acme.com registered to us. And then we'd want to make sure there's an A record for www.acme.com
inside of DNS. So just as an example, this was When Jill does her DNS request to her
DNS server, saying, what is the IP address of www.acme.com?
The response back to should Jill should be And then Jill would forward her traffic to her
default gateway. It would be routed up to this load balancer, and then load balanced across those
servers. So we can see that having a DNS entry that points to the IP address for where our devices
are is really helpful, because people can use names instead of memorizing IP addresses.
So what about this scenario? Let's say we have a user who's connected to the internet. Here's his
home. So this is a home user. And for that connection to the internet, this home user could be using
DSL or a cable modem. And for the purpose of this discussion, let's say this user's been assigned a
dynamically assigned IP address.
Let's say that address is So on the internet, that's where this house could be found at this IP
address. Well, the user at this home has installed a camera. And the reason he installed the camera is
because he wanted to keep an eye on his dog while he was away.
So for example, if he's at work, he'd want the ability to go ahead and connect to the camera over the
internet and see his dog. Now, to make that function, their may be a little bit of work that the user
has to do here on their router and firewall to let the correct ports and correct traffic through.
But the problem I want to address right now is this IP address. This IP address is dynamically
assigned from the service provider. What if changes? What if it changes from to
And then when Bob's at work, he tries to connect to the old address and it's not working.
He doesn't know why. And the reason is that the IP address has changed and he's not aware of it. So
to help address that, what we have is a feature called dynamic DNS. And the reason it's called

"dynamic" is because we can have a moving IP address still mapped to a single name.
For example-- and we'll go ahead and give this user a name. We'll say it's Bob. Bob could out to a
company, for example, DynDNS.com is one of them. And what Bob could do is he could register
under that domain. So for example, maybe he gets DynDNS.com/BobsHouse.
And then what he does is he configures his camera to report it. So it's some dynamic DNS software
that's been configured to report in to DynDNS and to report is current IP address. And as it reports
the IP address, it's going to be reporting based on the global address that the internet sees that
camera as.
So there's a little smoke and mirrors that go on there. But the concept is that
DynDNS.com/BobsHouse now knows that that should map to So now Bob simply goes
to that URL, and because it's been dynamically updated, it translates into the right address, so Bob
can get resolution to go to that IP address.
And, if a week later, it change from .11 to .98, no problem, because the camera is sending the
updates to DynDNS.com associated with Bob's house. That information is then dynamically
updated in DNS. And Bob goes to the same URL and can get to the IP address that corresponds to
his camera.
And that's the gist behind dynamic DNS. It's an IP address that can move from time to time, but
some entity behind that IP address is reporting up to the dynamic DNS server to keep it updated. In
this Nugget, we've taken a look at the world of DNS, Domain Name System, which is the magic by
which a name, a common name, a friendly name like google.com, can be resolved into an IP
Configure and Verify DNS
In this Nugget, you and I get to configure and set up DNS on a Windows 2012 server. We'll also
take a look, from a client perspective, at some tools we can use, such as IP config and nslookup to
verify and make sure it's working. Now, in this Nugget, I would strongly encourage you, if you have
a Windows platform to practice with, I would encourage you practicing alongside with me as we go
through this Nugget together.
So as I use a tool-- for example, IP config or nslookup-- I'd like you to pause the Nugget, practice
those commands, and get the hands on practice during this Nugget as we go through it together.
Let's begin. I want to walk you through what it looks like, just a little sample of configuring DNS

on an internal Windows 2012 server. Then we'll take a look at Bob's computer, which is computer
number 2 here, and we'll verify on Bob's computer using IP config.
And we'll verify whether or not it has a DNS server that it can use. And I'd also like to show you
some really sweet tools with IP config where we can actually see the DNS cache on the local
computer regarding names it's previously resolved. And, if we're troubleshooting, how we can also
use IP config to clear on Bob's computer that DNS cached information.
So we're sitting in a Windows 2012. And we've got Server Manager running from here. If we want
to configure DNS, we can got to Tools, and then, from the drop down, go down to DNS. And from
here, if we wanted to create some new records for DNS, we could go to one of our existing zones.
For example, here in my configuration, I've got acme.com. I've got nuglab.local. Or we could right
click and have the option to create a new zone as well. So let's use our existing acme.com. We have
several A records already here. If we wanted to add new records, we could simply right click.
From here, we could select from the drop down, hey I want to create an A record, which would be
for IP version 4, or a quad A record, which would be for IP version 6. There's an option for a
CNAME, which we know is an alias for another DNS name. There's the mail exchange.
So, as n example, let's create a new A record here in acme.com. So let's create an entry called
sample. It automatically puts in acme.com down below because that's the zone I'm currently
configuring it for. And let's give it the IP address of And we can click on Add Host.
We could also click this check box. And that would create the pointer record that's used for reverse
lookups as well, at the same time. So if we click on Add Host, we get a message saying it was
successfully created. That's great. We'll click OK. We'll click Done.
And there's our sample A record of, which resolves to sample.acme.com. So on this DNS
server that I'm currently sitting at, its' using itself as a DNS server. So if we opened up a command
prompt by clicking on the Windows icon, typing in CMD, and pressing Enter, if we tried to do a
ping, out to sample.acme.com, [LAUGH].
I wasn't expecting the ping to be successful. But let's take a look at what happened. So we did our
ping to sample.acme.com. In the background, this computer did a DNS request to itself, which is
the DNS server, and said, hey, what's the IP address for sample.acme.com?

The result was Now here's the funny part-- and why I'm laughing. Because that's a real IP
address that's reachable on the internet, and this computer has access to the internet, it then said,
great, I'm going to start pinging And it just so happened that I got some responses back
from And not every device on the internet is allowing ping request to be responded to.
However, we lucked out. This guy is. But our whole purpose here was just to verify the name
resolution that I created on this DNS server was correctly working, meaning it was resolving the
name to an IP address. And just for grins, if we went back in, and we edited the properties of that
entry, and we changed the IP address to, which is one of Google's DNS servers, and we
clicked on OK-- and then if we go back to the command prompt, and we hit the up arrow key, and
go to sample.acme.com, from here, it's
pinging the same IP address. Why is that? And the answer is my local computer, this computer right
here, is caching that information. It's not checking with DNS anymore. So right here, because we
have the problem of this cached information on this computer right now, let me show you, right
now, with the IP config tool, how we can view and also clear the cached information on this local
So let's start off with the command ipconfig /displaydns. So ipconfig /displaydns and press Enter.
It's going to show us all the cached information regarding DNS resolution that this computer
currently has. And if we scroll down here, check this out. We have this cached information for
And it's being resolved to So even though that DNS record has changed inside of DNS,
from a client perspective, the client has cached and is still using the old information. So if we want
to flush that old information, here's what we'd do. We're going to type in ipconfig once more.
But this time, we're going to use a slash and the command flushdns. And we'll press Enter. Now, if
you get a message indicating, hey, you can't do that, you're not administrator, what you want to do
is, launch the command prompt as administrator. And the way you launch an application as
administrator is you can right click on it, go to the command, right click again, and then say run as
And in a corporate environment, it's very likely that the average user is not going to have
permissions at the administrative level for working with the computer they're sitting in front of. But
if you do, this is how you can run the command prompt as administrator.

So now that we've flushed the local cache on this computer with ipconfig /flushdns, I'm going to
press the Up Arrow key a couple times. And let's do the ipconfig /displaydns one more time. And
now it's reporting nothing here because there's nothing currently in the cache.
So let's do our ping again. We'll ping sample.acme.com, but, this time, because we're making need
DNS request, the answer should come back as Now, if you happen to try this from whatever
computer you're at, and you don't get a response back, it doesn't mean that Google's DNS server
was unwilling to respond back to us.
It could mean that between you right now and the target of there could be some device, such
as a firewall, that is not allowing the ping request going out or allowing the replies to come back.
Those are both required, the request and the reply, to have a successful ping.
This time it resolved to That's now in our cache, locally, on this computer. And then we did
our business with our ping requests out to Next, let's make a road trip out to Bob's
computer, which is computer number two So here, we're sitting in front of a Windows 8.1 enterprise
computer. It's Bob's computer, computer number two in our topology.
And let's bring up a command prompt. And my question is, how would we verify whether or not we
have been configured to use a DNS server? How do we find that out from the command prompt?
And if you're saying, Keith, Keith, it's IP config, I think that's a great start.
So let's try it. IP config, we'll press Enter. And IP config reports that we have an IP address of There's our default gateway of And that's R1's interface address. So we can use
R1 as a default gateway. But you'll notice, with the basic ipconfig command, it doesn't tell us the
details regarding a DNS server or information about the lease time if it is a DHCP address.
So to see additional information, we use the Up Arrow key. And we'll add on the /all. And that will
give us a more detailed view from the output of IP config. So now here with the output of
ipconfig /all, we have additional information. Look at that. Here we have the layer 2 address of the
network interface card. That's fantastic.
It's also indicating that DHCP is enabled, meaning we're a client. There's the IP address that we're
using. Here's our DHCP server, which also happens to be our router. That's why it also shows up as
our default gateway. And, da-da-da, there is our DNS server that we've been configured to use.
That was advertised to us as an option as part of the DHCP exchange. So my next question

would be how do we determine what DNS cached entries are local on Bob's computer right here?
And if you're saying, Keith, Keith, once again it's IP config on a Windows computer, you'd be
absolutely right.
But the question is, what is the option that we need to add in conjunction with IP config to see that
DNS cached information? And, as I recall, it is displaydns, just like that. So ipconfig /displaydns.
We'll press Enter. And, at the moment, we have nothing in the cache.
So I wonder what it would take to put some entries in the cache. Just for a moment I'm going to
open up Internet Explorer, just for a moment, and then I'm going to go ahead and close it. Now that
was just a brief opening and closing of that browser. Do you suppose DNS happened during that
time? And the answer is yes.
If the page came up, and it was giving us current information, absolutely. DNS was resolving a
bunch of names to IP addresses for us in the background. So if we use the up arrow key here and do
the ipconfig /displaydns again, check this out. It is pages, and pages, and pages, and pages of name
resolution that's been done for all of those various objects that we were getting just from going to
the default homepage for Internet Explorer.
So from the top of the list there's bing.com. There's microsoft.com. There's chartbeat.net. There's
msn.com. There's Facebook.com. And all of that was just by opening the default homepage for
Internet Explorer. So there were dozens of DNS requests and replies that happened, all in the
background, in order to connect to and populate the web page that we're looking at.
So if we wanted to flush that information, we'd use ipconfig /flushdns, press Enter, hit the Up Arrow
a couple of times to do a display, and now they're all gone. The other tool I wanted to share with
you right here is nslookup. And to use it, you simply type in nslookup.
And you could press Enter here, which would put us into interactive mode with nslookup, or we
could just go ahead and use it followed by a name. So if we wanted to know, for example, what is
the IP address, or IP addresses, associated with www.google.com.
OK, so let me type in nslookup, put in that name, and then press Enter. So there's the command we
used. There's the DNS server that we're currently using. There's the name of our DNS server that
we're currently using. That's the name we were looking for, www.google.com.
And it gave us back a whole bunch of information. It gave us back a quad A record right here,

which, on Bob's computer, he's not using IPv6, so he doesn't really need it. But it did come back.
And Bob has also received a whole bunch of A records. If we want to use nslookup in interactive
mode, we simply type in nslookup and press Enter.
And now it's like a game of chess. nslookup says, OK, great. I'm connected, and I'm using DNS
server That's the name of the DNS server. Your move. What do you want to do? So, the end
user, in this case, Bob or us, sitting at this computer, we could type in, for example, google.com.
And it knows that, oh, you want me to resolve google.com into IP addresses. And press Enter. So
here it did the resolution. It resolved google.com to this IPv6 addresses, this quad A record, as well
as all these A records. And it left us at the interactive prompt saying, hey, what else you got? And
like most interactive systems, there is some help available.
We can issue a question mark, press Enter, and that will give us the help regarding possible syntax
that we could use. Let me make this a little bit bigger. So we typed in the question mark, and then
we got a boatload of possible options that we could use.
One I'd like to demonstrate is the type. If we were looking for a certain type of record, whether it's
an A record, a quad A, we could actually set the type that we're looking for here in interactive mode
with nslookup and then issue our requests. So for the first example, let's set the type to be an A
So the syntax is set, space, type equal a, meaning I want to see the a records. And we'll press Enter.
So nslookup took that command and said, OK, great. I understand what you want to do. Your turn.
Next, we're going to feed it the question, the name, of what we want the a records for.
And let's once again use google.com and press Enter. Now you'll notice, in the response that came
back, it did not bother giving us the quad A records anymore. It only gave us the a records. And
that's because we set type to a right here. If we wanted to get just the IPv6 quad A records, we could
go ahead and use the Up Arrow key a couple times and set the type to quad A, set space type equal
aaaa, press Enter.
And then we'll use the Up Arrow key a couple times to do google.com. And now we're just getting a
response back regarding the IPv6 address, the quad A record in DNS. We could do the same thing
for looking for mail exchange records. So if we type in mx for the type, press Enter, then a couple
Up Arrows, look for again, it'll give us information regarding MX records.

So for an email server-- and now we know what the email servers are for google.com, we could
then do further resolution of each of those names to find out the IP addresses for each of those
servers. And let's do that. Let's go ahead and set the type back to a.
So we're getting set space type equals a. And let's go ahead and just grab one of these servers. So
the a record associated with this entry right here maps out to this specific IP address. And to DNS,
we simply say, thank you. And for one last example, let's do this.
Let's set the type that we're looking for as a point to record. That's going to be for a reverse lookup.
And for a reverse lookup, that's when we're specifying an IP address, and we want to know the
name associated with it, which is reversed from what we normally do.
Normally, we do the forward lookup, which is, here's a name, what's the IP address? So in this
example, looking for a pointer record, we'll type in, which is a Google DNS server IP
address, press Enter, and it comes back and says the name is google-public-dns-a.google.com.
And that is thanks to the pointer record in DNS that allowed that reverse lookup to happen. Now
what I did not tell you, but I'm excited to share with you now, is that I also did some packet captures
on this link before we started practicing with nslookup.
And that way, we can use a protocol analyzer, such as Wireshark, to take a detailed look at those
packets just to reinforce the concept of the DNS and the types of records that we're requesting via
the DNS. So here in Wireshark, in the protocol analyzer, here's, in packet number 33, we've got a
packet that's being sourced from, that's Bob's computer, and destined to, which is
Google's DNS server.
And it's a DNS query. If we look at the details for that packet down here, under the Query section, it
says we're looking for Google.com, and we would like an A record please. This protocol analyzer is
also telling us, right here, that, in the very next packet, packet number 34, it has the answer from
that DNS server to display.
So if we go down the packet 34 and select it, packet 34 is the response that's coming from
back to our client at It's a DNS response. And in the payload, it says you were asking for
google.com, you wanted an A record, and, regarding answers, I've got a whole bunch of A records,
IPv4 addresses, that are associated with google.com.
So Bob's computer may say, which one do I use? So then it would be up to the browser and the

computer that Bob's using to decide which of those IP addresses Bob's computer's going to use. He
doesn't need to use all of them. He just needs one. And then, if we take a look at our next packet
here, packet 35, this is when we're using nslookup asking for a quad A record.
So this is Bob's computer asking for google.com and asking for a quad record here in packet 35.
And the answer to that is in packet 36. So here in packet 36, the response coming back from the
DNS server is that google.com is at this wacky IP address. It's not too wacky.
It's simply an IPv6 address that's represented in hexadecimal as opposed to decimal. I'd also like to
show you what an example of dynamic DNS looks like. For example, I have this URL here,
http://cbt.gg/KeithBarker. And that's courtesy of bitly. And that maps over to another name, which
maps over to my camera-- which, by the way, I've just turned on.
So if we go to this URL and press Enter, in the background, it's doing all the mapping. There's some
C names involved as well. And when I record, I turned this camera on so people can watch and see
what it's like-- a day in the office of Keith Barker. Let me show you something really cool.
These lights I have, my good friend Anthony Sequeira told me about this product called Hue where
you can change your light source. So this is my Nugget recording light. This is a reading light. And
this is called pencils. This is called deep sea. This is called feet up.
So you can adjust the lights, and it's all remotely controlled. Pretty amazing stuff. Or I could turn
them off, and then the camera would have to adjust to that light. So I'll put it back at my Nugget
recording light set. And that's an example of how my lighting system works.
But, more importantly, it's an example of how dynamic DNS can keep track of this camera. Because
even if my public IP address changes, my IP camera is reporting in the new IP address so that when
people go to the URL, they can get the correct name to IP mapping due to dynamic DNS doing its
work in the background.
Let me give you an example of my home router that also supports dynamic DNS. So I'm logged into
my local router at my home. And there's my public IP address right there, which won't be the same
address next week or next month because it could change. So I'm not too worried about masking
that out.
If I click on Go right here for a dynamic DNS, it's going to take me to the dynamic DNS settings
page. And from here, for dynamic DNS, I can say, yes, I want to enable it. And then I could use a

third party dynamic DNS service, such as dyndns.com or one of the other hundreds that
are out there. And so what would happen if I set up my router to participate, doing dynamic DNS,
the software on this router would do the reporting to the dynamic DNS server to constantly keep it
updated with the correct information regarding the IP address, the globally routable IP address that's
associated with this router on the internet.
In this Nugget we've taken a look at how to configure DNS on a Windows 2012 server. We've also
looked at some command line tools on a Windows platform, including IP config and nslookup, that
can assist us in testing and verifying that DNS is working. I've had a blast in this Nugget.
A Tale of Two Kings
The way that devices communicate on a network today can be compared to the simple process of
one king inviting another king over to lunch. Let's begin. If you, like me, enjoy a great story, we are
going to have a blast with this one. I'd like you imagine a king, we'll call him King A, who wants to
invite King B, who lives in a different kingdom, over to lunch.
So King A, sitting at the top of his kingdom from a pecking-order perspective, doesn't have to go
out himself and deliver the message. He has the whole kingdom working for him. So what he does
is he calls for his scribe. "Da-da-da-da! Bring me my scribe," says the King.
And the scribe comes in and the king says, "I'd like to invite King B to lunch tomorrow." So the
scribe writes it down and then the scribes leaves the presence of the king. And here's my question
for you. Do you think the scribe, in all of his nice clothes and everything else has to go out and
physically go across the countryside to deliver that message personally? And the answer is no for
two reasons.
One, the scribe is way up there in the pecking order in the kingdom. And secondly, we've got a lot
of additional roles to play before that message even hits the countryside. So what the scribe does,
the scribe takes this message and turns to the secret agent who worked for the king.
And this secret agent, a very 007 James Bond type of character takes this message and perhaps he's
going to add some encryption to it as it travels over the countryside. Also, if there's some formatting
differences between the languages between King A and King B, it's very likely that this 007 secret
agent would also provide that translation function to this message.

And then the secret agent takes his results of what he did to the message and he turns around and
hands it to the lawyer. Now this attorney, this lawyer is responsible for deciding whether or not we
should allow a communication to happen between Kingdom A's side and Kingdom B.
And presuming it's OK, says this attorney, to have this communication between Kingdom A and
Kingdom B, the attorney gives the stamp of approval and allows the communication to be set up
between Kingdom A and Kingdom B. Now those top three individuals, the scribe at the very top,
007, the secret agent, and the lawyer, those are like the senior executive staff for the king.
And once the lawyer says, yes, this message can go, it is then handed down from the attorney down
to the middle manager. Now the middle manager is quite nervous. The middle manager may decide
that it is too big of a message to send all at once. So the middle manager may chunk it up.
So instead of being one large message, it could be two smaller messages. And the middle manager
also may decide to do guaranteed mail where he's going to ask for a receipt from the other side
regarding that they got those messages. And if so, the middle manager may label these messages,
perhaps one of two and two of two, specifying that the receipt is required from the other side to
make sure that they got both of these pieces.
And then once the middle manager has chopped these up into manageable pieces and perhaps
labeled them one of two and two of two, it then hands those pieces down to the mail room. Now the
mail room is responsible for addressing. For example, if we look at an envelope, in the top left-hand
corner it usually has the what? The return address.
So in the top left-hand corner it may have the return address called Kingdom A's Castle. And in the
To field we may have a label that says, To Kingdom B's Castle. So that's what the mail room is
going to do. So if there are two parts that are coming down from the middle manager to the mail
room, the mail room is going to create labels for each of them, the from and to addresses, that it
could apply to the envelopes.
And then the mail room hands the messages down to the envelope stuffer. Now the envelope
stuffer's job is pretty important his job is to take the messages, to put them in the envelope and
apply the labels that the mail room created for those messages. And also it's important to note that
as this message gets handed down it's getting slightly bigger every step of the way, because the
middle manager may have added tracking information--for example one of two and two of two-and that takes some room.
The mail room is creating labels for the source and destination address. That's going to be a little

more information for that part as well. And then the envelope stuffer is going to take each of those
messages and then put it in its own envelope, followed by putting the labels that the mail room
created for the source and destination for each of those envelopes.
Now we might ask what's the best envelope to use? And it all depends on the carrier. For example,
if we're using the United States Postal Service we might use a USPS envelope. If we're using FedEx
we might want to use a FedEx envelope. Or if we're using UPS let's go ahead and use a UPS
So in Kingdom A, if they only have pick up from FedEx, the envelope stuffer is going to use a
FedEx envelope. And then the final step after those messages are in their envelopes, those messages
are then sent from Kingdom A to Kingdom B. So if it's FedEx,
there actually would be a FedEx truck that's actually picking up those messages and shipping them
off to Kingdom B. I realize when I just said that that in Kingdom A, if it happened thousands of
years ago there's not likely to be a FedEx. However, if it's a current kingdom I suppose it could have
FedEx there.
In any case, that's the pecking order if King A wants to send a message over to King B. Now I want
you to imagine what it looks like at King B's side of the house when those messages come in. Does
the FedEx guy just get out of the truck and run right to the King and say, hey king, I got a message
for ya? The answer is nay, nay.
There's a whole pecking order that has to be followed, protocols if you will, that have to be
followed for that message to get to the king. So when those messages arrive at King B's castle,
here's what happens. It's physically received wherever the carrier is delivering it.
For example, maybe the dock, if it's FedEx, referring to the dock at the side of the castle. And then
those messages at King B's side of the house are handed up the envelope stuffers, except this time
instead of stuffing messages into envelopes, at King B's side, for this receiving message, we're
taking the content out of the envelope.
So the envelope stuffer, taking the content out of the envelope, hands them up to mail room. And it's
up to the mail room on the receiving side to look at the destination address and ask itself, is this us?
And if it's addressed the Kingdom B's castle and they are indeed at Kingdom B's castle, they get all

They put two thumbs way, way up and say, yay, it's for us. Then the mail room, seeing that this
message really is for Kingdom B, they throw away the labels, because they don't need those
anymore and they hand the contents up to Kingdom B's middle manager.
Now the middle manager is fairly nervous because if he sees a package coming in and it says, OK,
this is one of two, he might be freaking out for a little bit until he gets two of two. And hopefully
it'll be right behind the other one. And if Kingdom A's middle manager is requesting a receipt for
delivery of those messages, it would be Kingdom B's middle manager that responds back and says,
yep, I got one of two, I got two of two.
We are good to go. Then the middle manager, now comfortable that he has both pieces of
information because they both came in, no longer needs those labels of one of two and two of two.
The middle manager can toss those as it hands the content of the message upward.
And that would go up to the lawyer the attorney on Kingdom B's side. Now the receiving attorney
looks at the details and says, hey, it's from Kingdom A. We're in good speaking terms. We'll
definitely let this communication come in. And the attorney at Kingdom B's side hands it all up to
James Bond or the equivalent of James Bond 007, who works for King B. And here's the interesting
If, on the sending side, 007 did some encryption, it would be the receiving-side 007 that does the
decryption to make that information readable. And that also goes for formatting of the data. If
Kingdom A's 007 did the formatting, hopefully the 007 on King B's side can also do that same type
of formatting so they can understand each other.
And then the 007 at King B's side takes the results of whatever manipulations he did with
encryption or formatting and then hands the final result up to the scribe in King B's court. And then
depending on the rules at King B's court, maybe the scribe has certain times of the day that he's able
to interrupt the king to deliver messages.
Or maybe he's allowed to just burst in and say, hey, I've got a message. In either case, the scribe is
going to go in to the king and say, hey king, I have a message. The message is King A wants to
know if you would like to have lunch. And at that point, it would be up to King B to go ahead and
respond or at least that would be the polite thing to do.
And if King B responds, the response would go all the way down the pecking order on King B's
side and be received and go up the protocol stack or up the pecking order at King A's side. And that,
my friend, is the tale of two kingdoms when there's that lunch invitation from one king to another.

The way the devices communicate on a network can be compared to the method that these two
kings used to communicate about lunch. And we'll look at that correlation in the very next Nugget.
Until then, I hope this has been informative for you and I'd like to thank you for viewing.
The OSI Revealed
In this Nugget, we're going to apply the concepts from the King A King B story to computer
networks. Let's begin. One of the interesting attributes I'd like to point out about this King A and
King B story that we went through in the previous Nugget is that the King only interacts with and
only talks to the scribe.
The King doesn't jump down and talk to, like, the middle manager or the mail room. He only works
directly with the scribe. And then the scribe has a relationship not only with the King but also with
the 007-- the agent. And the 007 agent and the attorney also communicate with each other.
But you'll notice that the attorney doesn't talk directly to the scribe or vice versa. They're going
through the 007 agent. And then the attorney works directly with the middle manager, as well as the
agent. And the middle manager and the mail room-- they communicate with each other.
And the mail room and the envelope stuffer also communicate with each other. And the envelope
stuffer has access-- I move the truck over here-- to the carrier, who's actually going to be moving
that information. Now, let me tell you one of the cool benefits about how this organization is set up.
If we wanted to get a new carrier-- let's say we're going to use some other carrier instead of FedEx.
Let's say we're going to use UPS, as an example. How hard would it be for Kingdom A to start
using UPS instead of FedEx? Well, in our story the only direct interaction that we have with the
carrier is the envelope stuffer.
So all we'd have to do is swap out FedEx for UPS, and we would not have to bother anybody here,
because they're isolated and separated from the delivery. The same is true for a scribe. What if we
wanted to replace the scribe? How hard would it to be? Would we have to redo the entire kingdom?
The answer is no.
We take the old scribe out, and we bring a new scribe in. And that new scribe would have
interaction with just the king and the 007 agent. And as a result, the lawyer, the middle manager, the
mail room, and all the other layers wouldn't have to worry about that change.

Because to those other layers, because they're separate and removed from the scribe process, it
wouldn't matter to those other layers-- those other functions-- that are isolated or abstracted from
the scribe. Now, we can take that same type of analogy, where the King talks to the scribe, the
scribe talks to 007, and so forth. And we can apply that to how a computer thinks before it sends
data on a computer network.
And when I say a computer, I'm referring to any type of computing device that is connected to and
working with a network. And to help get our brain wrapped around the logical idea of what goes on
in the computers when they're communicating on a network, we can apply the various roles in
Kingdom A and Kingdom B's castles to individual functions that go on a computer network.
And to assist us with that, we have something called the OSI reference model. It stands for the Open
System Interconnect model, and it really is just a model, or an idea, of how we can categorize
functions that go on inside of a device that's communicating on a network.
And there are seven specific functions or layers, as they're referred to in the OSI reference model.
And these layers, or functions, are numbered. They start at the bottom, just like professional
bricklayers. When they build a wall, where do they start? At the bottom, sure enough.
And they're numbered 1, 2, 3, 4, 5, 6, 7 for these seven different roles or functions, if you will, that
can work together in what's referred to as a protocol stack-- a set of rules or a set of protocols that
work together. So protocols is nothing more than of fancy word for a set of rules that are agreed
So the scribe in our scenario represents what's called the application layer in the OSI reference
model. It's providing services. For example, somebody wants to print-- a printing service.
Somebody wants to save a file-- a file service. The application directly interacts with the
presentation layer.
So if there's a request of the application layer, that's then handed down to the presentation layer,
which represents our 007-- our James Bond. So if we're doing things like encryption, decryption,
and translation services, that's referred to as layer 6, or the presentation layer in the OSI reference
Again, it's just an idea about categorizing functionality inside of a computing device that's
connected to a network. So if there is some encryption or translation that needs to happen, logically

that's where it could happen-- at layer 6. And then the presentation layer hands it down to layer 5,
which is our attorney. And this is a logical function that can set up our sessions.
For example, if the user-- we'll call the user King A-- who's using a browser, wants to connect out to
a web server, it's the session layer's responsibility for managing that session. And you know what?
King A doesn't go to just one website. He may have three or four websites open at the same time.
So the session layer would have the ability to manage multiple sessions. So if King A was going out
to google.com, it would be session between King A's computer and the web server at google.com/
And then the session layer hands it down to the next responsible party in getting the job done, and
that is our middle manager.
Now the middle manager is layer 4 of the OSI reference model. And it has a name. It's called the
transport layer. So just like our middle manager in the King A, King B story, if there's a big chunk
of data that's coming down, maybe it needs to be chopped up or segmented into smaller chunks.
And if the middle manager is doing reliable delivery, the transport layer may add additional
information to those segments, including things such as sequence numbers. And the transport layer
would be expecting receipts from the other side to indicate yes, those packages, those segments of
data made it over to the other side.
Now, I want to point out something here at the transport layer. If the transport layer is adding
additional information, for example, one of two and two of two, the information is getting slightly
larger as it's being sent down the stack. And that's often what these are referred to as-- a protocol
stack, a set of rules that inter-work with each other.
And the process of one layer handing it down to the next layer and handing it down and handing it
down, that process is called encapsulation. And each layer, as it gets it, if it has to add a little bit of
information, it will add that information, usually in something called a header-- a little extra
information at the beginning as part of that encapsulation.
So the transport layer then would send its information down to Layer 3 of the OSI reference model,
which is called the network layer. And the network layer-- layer three-- just like the mail room is
responsible for creating the labels, the source address, and the destination address regarding this
packet-- this data-- that's going to be sent.
So just like the mail room in our analogy-- we had a street name and a house number, or in the case

of the King, the castle number-- the network layer is responsible for adding on the IP source address
and the IP destination address. And once it does that, it then hands that information down to the data
link layer, which is the envelope suffer.
And what the data link layer does, it also adds information. For example, on an ethernet network,
we have Layer 2 ethernet addresses, also referred to as media access control or MAC addresses. So
layer 2 of the OSI reference model on an ethernet network is going to attach a source and
destination layer 2 address. The source address would be where this frame is coming from, and the
destination would be where this frame is going to.
What's the next immediate destination we need to send this to? Is it another device on this local
network? Is it my default gateway? And then with that information added, it's handed down to layer
1 of the OSI reference model, which is the physical layer. And the physical layer is all about
sending that information.
And the physical layer would include things such as the physical cables, the connectors, the
electronic signals that are being sent as that information is now put on and traveling across the
network. And then as that information is sent to its recipient, the recipient is going to receive that
and start to de-encapsulate.
So the receiving side, for example-- just for a moment, let's say this is now the receiving side-- the
receiving side would receive the bits. It would take a look at the layer 2 address and say, yep, that's
us. It would then de-encapsulate the information headed up to the network layer on the receiving
side, who would look at the Layer 3 address and say, yep, that's us.
It would then hand it up to the transport layer were the middle manager says, yep, we'll accept that,
which then gets handed up to the session layer, presentation layer, and application layer. And the
process here, as we receive the data and we strip off the headers and the extra information was
added, that receiving process is called de-encapsulation.
So sending the information, we're doing encapsulation, as we prepare to and send the data. And the
receiving party is going to do de-encapsulation, as they receive and process the information. Now as
cool as the OSI reference model is, it is just a reference model, meaning don't go out and expect to
see a protocol stack that exactly matches the OSI model, because it's kind of like just an idea.
And several decades ago, when the internet was just being born, the developers were creating this
protocol stack called TCP/IP. And these are all acronyms. TCP stands for transmission control
protocol. We'll have a separate Nugget just about that. And the IP stands for internet protocol.

And again, we'll have separate Nuggets with more details on those acronyms. But this is the
protocol stack that they built and were using. And they didn't bother separating the functions for
layers 7 6 and 5. They just lumped it all together. And they called it the application layer.
And then the middle manager, they did indeed call that the transport layer. And for the mail room,
they called that the internet layer, as opposed to network layer. So a slight difference in terminology
there. And for the bottom two layers, they refer to this as the network access layer, which combines
the aspects of sending the bits, the cable, the connectors, as well as the layer 2 addressing on
ethernet, such as MAC addresses, and the rules of the road for how to gain access to the network.
Those are all bundled together. And possession is 9/10 of the law. And because TCP/IP was in use,
and it was being developed and enhanced, even though the OSI reference model was also out there,
they didn't bother going back and saying, well, let's rewrite the TCP/IP protocol suite to exactly
match the OSI reference model.
So pretty much the world today uses the TCP/IP protocol suite for most of their communications,
including the internet. And where it gets a little bit interesting is the actual layers that we refer to in
out TCP/IP protocol stack today. So this right here, this actual-- I'm going to label it TCP/IP-- and in
our current TCP/IP protocol stack today, the upper three layers of the OSI reference model are all
represented by this one layer called the application layer.
And that's great news. So layers 5, 6, or 7, just refer to it generally as the application layer. It's
responsible for application layer services, translation, encryption, decryption, session management,
et cetera. Everything that we'd find in 5, 6, and 7 are all conveniently in one giant lump called the
application layer in our current-- today-- TCP/IP protocol suite.
And the middle manager is simply called the transport layer. So that's great news-- transport layer
across the board. For the internet function of the TCP/IP protocol suite, we borrow a couple of
things from the OSI reference model. We borrow the name. So we call it the network layer inside
the TCP/IP protocol suite.
And we also borrow the number of 3. So when people talk about hey, this is a layer 3 device, they're
talking about a device that primarily operates based on layer 3 address information. And in the
TCP/IP protocols suite, instead of just referring to the bottom two as network access, they borrowed
the names and numbers from those two levels, as well.

So even though we're using TCP/IP, which originally didn't have a data link and physical separated,
we borrow the name and the number from the OSI reference model. So what it really is is the
TCP/IP protocol suite, which is borrowing some names and numbers, for example, layer 1, 2, 3, and
4, from the OSI reference model. However, at the end of the day, it really is just the TCP/IP protocol
So let's take a look at an example of TCP/IP protocol suite in action. Bob the user has a browser.
Woohoo, congratulations, Bob. We all have browsers. So he opens his browser, and he goes out to
google.com. And when Bob is going out to google.com, in the background
DNS is running to resolve the name of google.com to an IP address. So in reality, Bob's computer is
connecting to the IP address of google.com or one of google.com's servers. And in that process, he's
using a protocol-- a set of rules at the application layer-- called HTTP, which stands for hypertext
transfer protocol.
That is the language of love if you're communicating between a browser and a web server on the
internet. So as Bob was establishing the session, in his computer it formulated the perfect HTTP
request. And then it handed that request down to the transport layer, which is layer 4. Now HTTP
has some standards regarding the layer 4 protocols it wants to use.
And the protocol it wants to use at layer 4 is called transmission control protocol, or the acronym
would be TCP. TCP is an example of a reliable, connection-oriented layer 4 transport protocol,
because it's going to be asking for acknowledgements and receipts and synchronizing with the other
side to verify that the data really did get to the other side.
And that additional control that TCP is adding is going to add a little bit of overhead, and it's going
to do that in the form of a TCP header. And a header is the extra information that this layer is adding
for the function of that reliability and tracking.
And again, this process of adding additional header information in each of the layers is the process
of encapsulation as the information is being logically sent down the protocol stack. Once TCP has
added its information, it then hands it over to the mail room, which is the network layer-- layer 3.
And at layer 3, we have one major protocol, and that is IP-- the internet protocol.
Now, there's a couple flavors of IP-- internet protocol. We have IP version 4, which is the most
prevalent. And we also have IP version 6, which is getting more and more popular, mostly because
we've exhausted most of our IPv4 address space. We don't have anymore streets left, so we're
moving over to IPv6, which has trillions more streets that we can play with, because it's a bigger IP

addressing space.
So at layer 3, IP is also going to add a header. And then this header's going be adding specifically
the IP addresses-- the source IP address and the destination IP address. If Bob's going to Google, it
would be the destination IP address of google.com. And then it gets handed down to the envelope
stuffer, and if we're on an ethernet network, which is very, very common, this is the envelope stuffer
at layer 2. And it is also adding header information.
And in that header information, if we're on an ethernet network, it would be adding the source MAC
address-- the media access control address, also sometimes referred to as the layer 2 address. And
then once that information is added, it's then handed down to the physical layer, logically, which is
then sending that information like a telegraph operator on steroids-- da-da da-da-da da da-da da-dada da-da-da-da da-da-- millions of times a minute on the network.
Now, one of the things I found very helpful in my early career back in the '80s working with TCP/IP
and networks, and I still find helpful today, is getting some common ground with terminology. And
one of the sets of terms I'd like to talk with you about and have you endorse and start using as well
is what do we call this stuff that's being sent down the protocol stack at a specific level? For
example, if we just took a snapshot in time, and we just looked at this level for example, layer 3,
which at this point includes the IP header information, also already encapsulated is the TCP header
information, but if we're focusing just on layer 3, we could refer to that information up to that point
as a packet.
Now, the word "packet" by our friends and our colleagues is used all over the place. It's a packet.
Got a packet. Sending a packet. However, if we want to get into the nitty gritty and be more
accurate in our descriptions of this data at various levels, we could refer to the IP header
information and everything behind it-- for example, the TCP header, which is already there, and the
HTTP header, which is already there-- we could refer to that as a packet.
On the other hand, if we're focusing right here on the TCP header information, where maybe it
hasn't yet been encapsulated by IP and doesn't yet have an IP address, we could refer to that as a
segment-- a segment of data. And as that segment of data is handed down and is encapsulated by IP
and becomes a packet, and then IP hands it down to layer 2, and layer 2 ads its header information,
at layer 2, we can refer to that as a frame-- a frame of data, which includes the layer 2 header
information. And on ethernet, again, that would be MAC addresses-- layer 2 ethernet addresses.
And then as layer 2 hands that down to the physical layer for the actual transmission of those bits at
crazy, crazy speed, we just simply refer to that transmission of that information as bits-- a bunch of
ones and zeros traveling across the media very, very quickly.

Another cool byproduct of using these layer numbers-- for example layer 1, 2, 3, and 4-- as we
talked about the TCP/IP protocol suite is that if we have a device on the network that is primarily
making decisions-- forwarding decisions based on, for example, layer 3 information, which would
be based on IP addresses-- that would be called in our network a layer 3 device. Now, it just so
happens that we have a name for these devices that make forwarding decisions based on layer 3
information, and that is a router. And that, my friend, is because a router makes forwarding
decisions based on IP addresses.
If it gets a packet, it looks the destination IP address, and it says, hm, do I know how to forward
that? And if it does, it forwards it. It re-encapsulates it and forwards it onto its next destination. If
we had a device that was making forwarding decisions based on layer 2 information, we could refer
to that as a layer 2 device. And it just so happens that we have a very common layer 2 forwarding
device in our networks today, and that is referred to as a layer 2 switch. Specifically, on an ethernet
network it takes a look at the destination layer 2 MAC address, and it makes a forwarding decision
based on that MAC address.
So we could say that a switch-- an ethernet switch-- is a layer 2 device, a layer 2 switch. And
furthermore, we could say that the layer 2 switch forwards frames based on that layer 2 information
that's in the header in those frames. And when we get down to the physical layer, we also have some
devices that are associated with the physical layer.
For example, a cable, a connector, the electrical signals that are being sent-- those are all examples
of physical layer devices or layer 1 devices. We also have in this category something called a hub.
And a hub kind of looks like a switch. It's got RJ45 ports. But with the hub, if somebody sends a
signal in on one port, it simply blindly repeats it all on the other ports.
A hub does not have any intelligence to look or understand layer 2 information. And for that reason
a hub would be considered a layer 1 device, simply like a glorified repeater, repeating the bits that it
sees out the other ports. And one other kind of interesting observation I'd like to make is regarding
layer 2 devices. Let's consider a network interface card that's sitting in a computer.
If it's a network interface card that's used on an ethernet network, it certainly does have physical
connectors. I mean, we plug the RJ45 cable into the network interface card. So in that concept, a
network interface card could be considered a layer 1 device. However, that same network interface
card also has the layer 2 MAC address that's burned into it from the factory.
It's also controlling a lot of the logic for gaining access to the network. And because of the layer 2
MAC address and the functions it has there at layer 2, a network interface card would probably
better fit into the layer 2 category, as opposed to just a layer 1. And I guess we could use that same

argument with routers as well.

Routers have physical interfaces. They have physical connectors. But because they make
forwarding decisions based on layer 3 information, they're considered primarily to be a layer 3
device. So my friend, here is the takeaway. I would strongly recommend that you memorize these
seven layers of the OSI reference model.
To do that, here's a quick reminder tool. You could take the first letter from each of the layers, and
you could simply make up a cute saying, such as "please do not throw sausage pizza away." If that
works for you, great, or make up another one. And that way you can remember the first letter, and
that can help you remember the labels of the OSI reference model.
I would also recommend that you do a little practice with the actual TCP/IP protocol suite and the
labels and names we associate with them. For example, layers 1, 2, 3, and 4-- what the names are of
the TCP/IP protocol suite at those layers, as well as what we call the data at each of those layers-bits, frames, packets, or segments.
Sometimes you also might hear these referred to as PDUs, which is a kind of funny little acronym
for protocol data units. Please don't say that in public, because if we just want to refer to data at the
application layer, we can just call it data. I would also have you remember that the router is a
perfect example of a layer 3 forwarding device, because that's its primary purpose.
It makes forwarding decisions based on IP addresses at layer 3. And that a layer 2 switch-- an
ethernet switch-- is making its forwarding decisions based on layer 2 addresses, which is contained
in the layer 2 headers. And that's why it's referred to as a layer 2 device. And as a challenge to verify
that you have this down, I would recommend that you-- without looking at this screen-- go to a
separate piece of paper, or a separate drawing mechanism, draw out the TCP/IP protocol suite, write
out the layers, write out the names of the data at those layers, and the devices that commonly
operate and make forwarding decisions at those layers as well.
And I've got a secret for you. If you take the time now to actually write this out and practice it to
really internalize, that will serve you in so many ways. As you communicate with others regarding
networking technologies, it'll also help you greatly if you are ever involved in troubleshooting a
network, because we can leverage this information as we take strategic approaches to fixing or
solving a problem on a computer network today.
How ARP is Used

In this Nugget you and I are going to discuss and verify the Address Resolution Protocol that's used
by IP Version 4. Let's begin. One of the challenges a device on an IP version 4 network faces is that
as it does the encapsulation process-- maybe we have a HTTP request that's going down the
protocol stack.
It gets encapsulated, Layer 4 becomes a segment. It gets re-encapsulated again at Layer 3. It now
becomes a packet. Once it hits Layer 2, and it needs to be encapsulated, and we need to add the
Layer 2 information, the source Layer 2 address, and the destination Layer 2 address how in the
world does our computer know what the Layer 2 burned-in address is on some other device that's on
that same network? And the answer is, by default, it does not know what the Layer 2 address is of
the other device on that local network that it wants to communicate with.
And that's why IPv4 has this really cool protocol called ARP, Address Resolution Protocol, that
allows a computer to dynamically learn the Layer 2 address, the MAC address on Ethernet that
maps to a corresponding computer's Layer 3 IP address. So as an example, let's take Computer 2
right here, and let's say Computer 2 has the IP address of And this router, which is on
this same network segment right here, along with all these other devices I just circled, is at the IP
address of So that's interface 3/0 on Router 1. Now for the purpose of our discussion, let's
just go ahead and presume that the first two numbers here are the network, and that the last two
numbers are the host, meaning the host address the IPv4 host address of these interfaces on the
Now it's very unlikely that this computer, Computer number two, when it was being configured via
DACP, it learned about the default gateway it should use if it ever needed to communicate off of the
local 10.1 network. And for our example, let's presume that this computer just wants to
communicate over to Router 1. Maybe it's going to do a ping request just to verify basic
So as that ping request is being encapsulated, Computer 2 says to itself, I'm on network 10.1. The
destination I'm trying to reach is also on 10.1. That means he's on the local IP subnet, same network
as I am, but now I need to know his Layer 2 MAC address. So that as the encapsulation happens at
Layer 2, this computer can go ahead and correctly add the source MAC address of Computer 2 and
the destination Layer 2 address of the router's interface.
So what Computer 2 does to discover the Layer 2 address of the router interface, it's going to do a
little shouting. It makes me want to shout. And the ARP request is going to send out something
called a broadcast. A broadcast is sort of like an all points bulletin, so with the broadcast everything
on this local network here, the 10.1 network, would see and have to listen to that broadcast.

That means Computer 1 had to process it, the printer had to processes it, the signal was sent out to
the wireless access point which, in turn, was also received by a computer on that wireless network.
This internal server had to see it, and the router had to see it.
Now as you can imagine, sending a broadcast takes a little bit of toll on everybody has to look at it.
And that's because everybody who receive that broadcast frame is going to have to de-encapsulate it
to see what's inside. It's like reading a book. Oh, here's the intro, interesting, I'll keep reading.
And computers, they keep on de-encapsulating or they keep reading until they either get something
that they can process, or they realize it's not for them. For example, if I went to a bookstore said,
hey, this looks like an interesting cover, and I open it up, and I say, oh, this about rocket science, I
would go ahead and close the book.
I'm done. That's not my topic. And that's effectively what all these other devices did except for the
router. And that's because this router, as it started to de-encapsulate that frame, this broadcast frame,
and started looking at the contents, it saw, oh, this is an ARP request, and it's looking for the person
who has And Router 1 said, that's me. That's my IP address.
And as a result, Router 1 responds back to Computer 2 to indicate, hey, buddy, I understand you're
looking for the Layer 2 address associated with my IP address? I have the IP address, and I'm
responding to you so that now you know my Layer 2 address as well. So here on Bob's computer
let's do a couple things.
Let's do an ipconfig just to verify that we do have an IP address. And sure enough, our address is, and we've been configured to use a default gateway of, and this default
gateway IP address is the IP address that R1 is using for his interface connection to this same
Now, what's interesting is if we want to see what we've already discovered via Address Resolution
Protocol, we can use the command arp -a. I haven't learned about the Layer 3 to Layer 2 mapping
yet for my default gateway. But check this out. If we did a ping, which is the IP address of
our default gateway, that will trigger in the background an ARP request, so that we can learn what
that Layer 2 address is of our default gateway.
And assuming the ARP is successful, we'll then be able to go ahead and do the ping requests,
because we'll be able to correctly encapsulate at Layer 2 with the destination Layer 2 address of
who that frame is for. So we'll do our ping to, and I'd like you to notice something

At least, I think it's interesting. I hope you do, too. And that is, our first ping it took 61 milliseconds,
so as far as milliseconds go, there are 1,000 milliseconds in one second. So it's all happening pretty
quick, but that first one the ping took 61 milliseconds to respond, and then the last three took 31
milliseconds, almost half the amount.
Why? Why so much additional time for the first ping? And the answer is, it was waiting for the ARP
resolution to finish. So if we were going to do a ping again, I'll choose the up arrow key into a ping once again. You'll notice that this time each of the ping responses are about equal.
And that's because when we do an ARP request, when a computer or a computing device does an
ARP request, it doesn't forget that information immediately. It caches it. So if you use the up arrow
key a few times into the arp -a again, you'll notice now that we have a mapping that says, hey, the IP address, the Layer 3 address maps over to the Layer 2 address of 00-05-01-01-01-01,
which is the Layer 2 address that R1's network interface card is currently using on our local network
And over here on the right, it indicates that that was a dynamically learned Layer 3 to Layer 2
mapping courtesy of Address Resolution Protocol. And one other note that is also interesting is this.
Notice here it says Physical Address. And because it says Physical Address, sometimes we think,
oh, is that like the physical layer of the OSI reference model? And the answer is no.
A MAC address, a Layer 2 address, unfortunately, but actually sometimes also referred to as a
Physical Address, so don't let the word physical throw you off as far as where that is in the protocol
stack. It is absolutely a Layer 2 address in our TCP/IP Protocol Suite.
Now if we had captured that ARP request, and we did, it would look something like this. If we look
at the details of the payload of this ARP request, it indicates a few basic things. First of all this is a
request. This is ARP trying to discover the Layer 2 address associated with an IP address.
Next, the person who's sending this request has a MAC address of this guy right here and IP address
of this right here. And the benefit of sending this out in conjunction with the ARP request, is that the
person who gets it, in our example, the router, the router can just put that mapping between the
Layer 3 address of Computer 2 and the MAC address of Layer 2 in its ARP cache, so that it doesn't
have to do its own ARP request.
And then here in the Target, it's specifying I'm looking for the Layer 2 address associated with, and currently, I don't know what that Layer 2 addresses is. So as part of the request, I'm
just going to put all zeroes here. And a MAC address, a Layer 2 MAC address is 48 bits in length,
but we often represent them in hexadecimal, which we'll cover in more detail in another Nugget.
Also, if we look here in the Layer 2 header information, it shows the source MAC address of the
person sending this is the same MAC address of the person requesting it. So these two should match
right here. And the destination Layer 2 address is a broadcast. And a special address for a Layer 2
broadcast is 48 1s, or represented in hexadecimal, that would be 12 hexadecimal F characters
representing 48 1s. So any device who receives a frame of data or the destination Layer 2 address is
all 1s in binary or all Fs in hex, they're going to start to de-encapsulate those frames to see if there's
anything relevant for that device in the payload of this frame.
So fortunately, for Computer 2, R1 heard that request and responded with an ARP reply. And if we
look here at the Layer 2 information, Router 2 sourced this from his own MAC address, and sent it
back to the MAC address of computer number two. And this is what's referred to as Unicast,
meaning, it's not meant for everybody like a broadcast.
It's intended for a specific destination. So an ARP request is broadcast and the reply is unicast going
back to the requester. And that way, we don't have to bother all the other devices on the local area
network who really don't care about our little ARP conversation that we're having.
So we're saving all the other devices a little bit of overhead by sending the reply back Unicast as
opposed to sending a reply that's destined to the Layer 2 broadcast address again. And in the
payload of this reply, the sender is indicating his IP address.
This is R1's IP address as well as R1's MAC address, which was the whole purpose for the ARP
request in the first place. Computer 2 wanted to learn the Layer 3 to Layer 2 mapping, specifically
the Layer 2 address of its default gateway. And now it has it. So for future frames it ascends to the
default gateway, it can address those at Layer 2 using the router's Layer 2 address. And if I remove
this filter, that I currently have for this protocol analyzer, we can see the ping request and replies
starting here in number five.
And if we look at Layer 2 of that first ping request, it's being sourced from the Layer 2 address of
Computer 2, and it's being sent to the Layer 2 address of the router. In this Nugget we've discussed
and demonstrated how we can do Layer 3 to Layer 2 mappings from an IP address to a Layer 2
MAC address on a local Ethernet network segment. Here are the hands-on practice that I would
love for you to do before you go to our next Nugget together, and that is this.

Number one, I'd have you run ipconfig on a Windows computer. When you run ipconfig, you'll see
what your IP address is as well as your default gateway. Then I'd like you go ahead and do a ping
over to the IP address of your default gateway. And if your computer didn't previously have an ARP
entry in its ARP cache for your default gateway's Layer 2 address, it will now, because of the ping
that you just did.
And then finally, I'd like you take a look at you're ARP cache by using the command arp -a. And
that's your homework assignment from this Nugget. I have had a great time in this Nugget. I'm glad
you joined me for it. I hope this has been informative for you, and I'd like to thank you for viewing.
IPv4 Addressing and Subnetting
In this Nugget, I'd like to introduce a method that you and I can gain ninja-like IPv4 skills if we'll
simply follow the process. Let's begin. I'd like you to imagine that you and I have been invited to
troubleshoot the engine on a small aircraft. Now, I don't know about you, but I have never, ever
worked on the engine of a small aircraft.
I imagine there's things like a fuel system. There's probably an electrical system. But as far as me
troubleshooting it, it would be very, very challenging. Because again, I don't know the first thing
about engines on airplanes. Now, when it comes to computer networks, if someone asked you and I
to troubleshoot an issue that a customer is having communicating on that network, and it was due to
IEP addresses or subnet addresses or default gateways or the routing between those, it's very likely
that between us, we could knock that out of the park.
And I'll tell you why. It's because I am very familiar with IEP addressing and subnetting. And my
friend, I'd like you to have those skills as well. So to accomplish that, I knew I had created some
IPv4 subnetting content previously, and so what I did is I sat down and I watched all 16 videos.
They're fairly short, 16 short videos from our IPv4 subnetting course.
And my friend, they are perfect for you and I as we continue together in this journey through the
world of Network Plus. So what I'm asking you to do is that after this Nugget is done, I want our
next 16 Nuggets is to be the 16 Nuggets from the IPv4 Subnetting course that we'll go through
Now, one of the challenges-- I'm going to be right up front-- regarding IPv4 addressing and
subnetting is that for a person who is fairly new to it, it has a fairly short shelf life. And you might
saying, Keith, what do you mean a fairly short shelf life? Well, if you learn it-- for example, you go
through it, you do some exercises-- but you don't apply it, that knowledge very likely, for new
person, is going to evaporate over a period of several weeks.

So as a solution to that challenge, as we go through these 16 Nuggets in the IPv4 Subnetting course,
I've included exercises in those Nuggets that I want to do as we go through those Nuggets together.
And by you doing those exercises with me, that will help you reinforce those concepts that we
learned in the IPv4 Subnetting course. Also in that IPv4 Subnetting course, I've also included optout questions.
And here's how they work. At the beginning of each Nugget, they have a few simple questions that,
if you read those and you know the answers to them, you can think to yourself, oh, I've got this. I'm
going to go to the next Nugget. And the reason I did that is because very likely you may want to go
through the IPv4 Subnetting course initially, like right now, the next 16 Nuggets we do together, and
then again later.
Let's say a month goes by, and you want to refresh your skills on IPv4 subnetting. By looking at the
opt-out questions, you may be able to go through the entire course and just watch two or three
videos where you needed to do the brushing up on. And again, the opt-out questions can help you
confirm whether or not you already know the content that's in a specific Nugget in that course.
The third thing we're going to do to really reinforce these skills is that after we've gone through the
IPv4 Subnetting course together and we return together to this Network Plus course, the very next
Nugget in this course is going to be all about applying these subnetting skills that you've learned
from the IPv4 Subnetting Nuggets. So for those of you who are brand new to IPv4 addressing and
subnetting, absolutely go through the Nuggets 1 through 16 in the IPv4 Subnetting course as your
next 16 Nuggets. For those of you who have a familiarity with IPv4 and you think you have a fairly
good understanding of it, I would also encourage you to check out those 16 Nuggets and leverage
the opt-out questions. So that way if you go to a Nugget and you know the answers to the opt-out
questions, you can say, oh, yeah, no problem.
I've got that. I'll jump to the next Nugget. Because I want to make sure that as you and I continue in
this Network Plus course, we have that knowledge in the bag, and we're going to leverage it as we
move forward together. So your action item, my friend, is to enjoy the next 16 Nuggets from the
IPv4 Subnetting course.
IPv4 Review
In this Nugget, we're going to take the skills that we gained by going through the IPv4 Subnetting
course-- which by the way, was an assignment as part of our preparations for Network Plus-- and
apply what we learned to our network topology. Let's begin. I'd like to do a little review question
regarding some of the concepts that we learned and went through together in the IPv4 Subnetting
course. Now if you haven't yet gone through those 16 Nuggets in the IPv4 Subnetting course, I

would strongly recommend you stop this Nugget right now and go through the IPv4 Subnetting
course. And then when you're done, join me right here, and we'll continue our journey together.
Now for those of you who have gone through the subnetting course or have the equivalent
knowledge, I've got a little pop quiz and here it is. We'd like to go ahead and use the
network and plan for these following networks. At the headquarter location, they'd like to have
network A, which is going to support 50 hosts. And when I say 50 hosts, they're referring to 50
devices that are going to be using an IP address. That would include computers and printers and
even the interface on the default gateway on that network.
Also at the headquarters site, they have network B which also, they want to have the ability to
support 50 hosts for. So maybe this is network A right here and maybe the DMZ is going to network
B. Then regarding the branch network, which is out here, they have network C-- I'll label that-where they want to support at least 10 IP addresses. And they also have network D, which they want
to support six hosts.
So they have network C and D out here at the branch. And then they also have wide-area network
and other two-device networks, where they only have two devices on the link. And those are
networks E through H, and they've got four of those. So for example, maybe this is one of those
Maybe that's network E. And the connection between the firewall and this router, maybe that's
network F. And the connection between router 1 and the firewall, maybe that's network G. And then
for network H, we can use our creativity where we want to put that.
But in any event, they have a total of four networks that just need two devices each. Our mission,
should we choose to accept it, is to identify and plan for those specific networks. So it's a total of
eight networks-- two that need 50 hosts, one that needs 10, one that needs 6, and four that need 2.
So if you are freshly off of the VLSM Nugget that we went through in the subnetting course, this is
the exact type of scenario that we were describing.
And as a review of how to solve this, we could first start by identifying how long the masks should
be for each of these networks. So over here, I'm going to put an M for masks. And if we had
networks that needed support for 50 hosts, the question I would ask myself is, Keith, how many
host bits do we need to leave available in an IP address to support 50 hosts? And then, I would do
the finger game to calculate the number of host bits needed.
So if I play that game-- 2, 4, 8, 16, 32, 64-- I would need six host bits available. So that means we

could take the mask all the way out to a /26, and that would leave us six host bits that were available
for host addressing. And we could use that same process for identifying the masks for these other
networks as well.
For example, if we need to port 10 hosts, to play the finger game for that we go 2, 4, 8, 16. That's
enough, so four bits is all we need to support 10 hosts. So that means we could have a /28-bit mask
for those networks. So 28 bits allocated for network address spacing and four host bits for the host
address portion.
For six hosts, let's do the finger game again-- two, four, eight. We'd need at least three bits for host
bits. That means we could take the mask and push it out to 29, and that would still leave three bits
for host addressing. And then for two devices, all we need is two bits-- which means we could take
the mask there out to a /30. So for our masks, they'd be /26, /26. For network C of 10 hosts, they'd
be a /28. For network D of six hosts, it'd be a /29. And all of our WAN connections, where we only
need two devices, it'd be a /30. So it'd be a /30 there, /30 there and could be a /30 there as well.
So that could be one of our first steps in identifying first of all the mask that's going to be used for
those subnets. So when solving this, one the first things I would do is I'd put in the values of the
binary positions-- 1, 2, 4, 8, 16, 32, 64, 128. Up on top, I'd put the mask values of 128-- so I'll put
an M here for mask.
192, 224, 240, 248, 252, 254, and 255. So now, we have the line for the weights of the position as
well as the mask. So because we're starting with a /24, everything we do is going to be focused on
that last octet. So starting on network A-- as well as network B, because they both need 50 hosts-we identified that the mask would be a /26. And that would put the dividing line right here.
And the way we came to that conclusion is that we needed six host bits to support 50 hosts, so we
could push the mask down to that point but not any further. Because if we went any further, we
wouldn't have enough host bits to support the 50 hosts. So we also know that 64 is our block size.
We also know that the first three octets, those are already locked in stone before we started the
So we'll just focus on the final octet. So for our network A, the first subnet, subnet 0, looks like the
parent network. So it would be, but it would have the new mask of /26. So that's
network A-- done. And then we could ask ourselves, OK, what about network B? Well, what is the
next network? Well the block site is 64, so the next subnet would be 64-- for that last octet-- /26.
Those, my friends, are network A and network B.

Now the next question is, what about network C, which we already identified would use a /28? And
here's the secret sauce, playing that off. We are going to take this next subnet. For example, just
pretend we're going to make a third subnet here-- subnet A, subnet B, subnet C. What is the next
subnet if we
add 64 more? And the next subnet would be the first three octets the same, .128. And here's the
magic. Instead of using that as a complete /26, we are going to take that subnet-- I'm going to call
that subnet .128. And we are going to further subdivide that.
So for network C, what we can do is we can simply put a /28 on that. So I will go ahead and put this
in. Let me put this in blue, and let me put the new dividing line right here. So it's a mask of 28. We
start here at 24 then 25, 26, 27, and 28. So our new block size, for these subnets that are using a /28,
is going to be 16. So this right here is subnet C. And if we needed
more subnets that needed the same exact number of hosts, we could just go ahead and use this block
size of 16 and simply add on 16 again and add on 16 again. But our next challenge is, is to carve out
network D. So what we are going to do is identify, just for a moment, what the next subnet would
be if we were still going to use a /28. And so to figure that out, we take 128 plus 16. Let's do our
math over here.
There's 128. There's 16. Carry the one. That's a four. That's a four. So our next subnet would be .
144-- if we were using a /28. However, what we could do is take that next subnet and further divide
it to support network D. So in network D, where we only need to support six hosts, we already
identified that all it would take for that is a /29. And with a /29, the mask moves right here, and the
new block size is eight.
And that's network D. So with network D, our block size is eight. So if we had a need to support
additional networks that needed six hosts each, we could simply take that 144, use the new block
size, and add that to it. And if we add 8 to 144, we would have a .152. Now, the reality is, we don't
need any more networks that support six hosts.
We are now getting down to the networks E through H, which only need to support two devices
each. So to do that, we take what would be the next logical network, and we simply subdivide it
further by putting on the new mask. So this is going to be the 152 network, so the dividing line is
moved right here.
Our new block size is four. And because we need four networks-- that's network E. That's our first
of our four-- we just use the block size. So 152 plus 4 is 156/30, and then 160/30, and then 164/30.

And that would be networks E, F, G, and H. And this, my friend, is leveraging everything we
learned in the IPv4 Subnetting course-- the 16 videos that you should have watched prior to this
And the processes, starting with your biggest networks-- meaning the networks that are going to
have the most hosts or need the most hosts-- carve them out. Figure out the next logical subnet and
then further divide that with the new mask. So if we go back to our topology and actually put those
numbers in, network A could be-- and I'm just going to put the fourth octet in because the first three
octets are not going to change for any of these subnets.
OK, it'd be Network B, for that last octet, would have a 64/26. The branch C
network that only needed 10 hosts would be a .128/28. The D network would end in .144/29. And
the connections that only needed two-- for example, our wide-area network serial links or any other
network where we only need to support two IP addresses.
Those would all be /30s, and the subnets that we identified were .152, 156, 160 and 164. In this
Nugget, we've done a real-world application of the technology that we learned about in the IPv4
Subnetting course. Now, I realize that for many of you, especially if you're new to subnetting, not
all of this is going to sink in right away.
And I want you to have courage. If you have a basic understanding of the concept of kind of what's
happening, that's OK for now. And you can proceed, and we'll go through the course together. But at
some point, I would recommend that you go back through the IPv4 subnetting course, leverage
those opt-out questions.
And as the concepts become more and more familiar because of your review of these videos, your
understanding will improve and improve and improve every single time you watch them. So my
recommendation is, be patient with yourself. You're doing great. Rome wasn't built in a day, and
IPv4 subnetting was not mastered in a day either.
In this Nugget, we'll take a look at some compelling reasons for why we might change an IP address
inside of a Layer 3 packet. And this process is known as Network Address Translation, or NAT. As
we learned in the IPv4 Subnetting course, we have private IP address spaces that we can use
internally inside of our companies.
And that's great. That's what we're using right here. For example, here on this network at our

company, we are using the 10 network. Specifically, we're using We're doing custom
subnetting. And we're using this first 16 bits to represent the network, and the last two octets are
available to identify individual hosts on this network.
So let's say this computer right here is Bob. And Bob is sitting at his computer. It's on the 10.1
network. And Bob decides, hey, you know what? I'm going to go out to the internet. So Bob opens
up a browser and goes to www.google.com. And one of the very first things that's going to happen
is DNS, Domain Name System, is going to resolve the name of google.com to an IP address.
So Bob's computer makes a DNS request, gets the DNS response. And let's say for our example that
DNS resolves google.com to the address of The next thing Bob's computer does is
asks itself, is that IP address right there on the same local network as I am? And the way Bob's
computer makes that decision, it looks at the network address that it's currently on, which is 10.1,
and it compares it to the first two octets, in this case of the IP address it's trying to reach.
And if the network portion of Bob's address does not match the destination, Bob knows two things.
Number one, it's not local. It's not on my local network. And secondly, Bob is going to need the help
of its default gateway. And so for our purposes, let's say that the Router 1 is the default gateway for
the 10.1 subnet and that the Router 1's host address ends in .1. So Bob's computer would forward a
packet to And that would be the Layer 3 IP header address where it was going.
The source address would be Bob's computer. But at Layer 2, what Bob would do, Bob would
forward that to the Layer 2 address of its default gateway. And if Bob's computer did not yet know
the Layer 2 address of the default gateway, it would use an ARP request, A-R-P, Address Resolution
Protocol, to determine what the Layer 2 address is that corresponds to the default gateway of .1.
And that would be sent into the network.
Now, the switch, which is a Layer 2 device, would make a forwarding decision based on that Layer
2 information. The switch would have learned the port where the router lives, based on the MAC
address, and the switch would forward that information at Layer 2 only to the port that needed it.
So the internal server, Switch number 1, and all the other devices wouldn't have to be bothered by
receiving and looking at this Layer 2 frame. So then the router gets the frame. And because when it
receives the frame it looks at the Layer 2 address for the definition and says, hey, that's me, and it
deencapsulates that.
And it starts looking at the higher layers. Once it looks at Layer 3, the router says, hm, the IP
address that this is destined to is And furthermore, says the router, that's not me. So

I'm not going to continue deencapsulating this packet, but what I will do, because I'm a router and I
know how to forward this packet in the direction of where it needs to go, I will continue forwarding
this packet to its destination or in the direction of its destination.
So to help accomplish that, Router 1 has something called a routing table. So in the routing table, if
it knew that to forward a packet to it needed to send it over to the firewall, what the
router would do, it would take the packet at Layer 3, and it would reencapsulate it at Layer 2 with
the Layer 2 address of the firewall. And if the router did not yet know the Layer 2 address of the
firewall, it would go ahead and ARP.
On an Ethernet network, it would ARP to discover the Layer 2 address for that next hop. And when
this firewall receives it, if it's also acting as a Layer 3 device, it would look at that Layer 2 frame,
say, hey, that's me. It would deencapsulate up to Layer 3, look at the IP destination address, and say,
hey, that's not me, but I do know how to route in that direction.
I can forward this packet. So the firewall also has a routing table that it can refer to if it's acting at
Layer 3, and they it can reencapsulate it in Layer 2 with the correct Layer 2 address of R2. So when
R2 receives that frame, it deencapsulates it and says, hey, the IP address this is going to is That's not me, so I'm not going to continue deencapsulating it and see what's in the
But what I can do is I can forward it in the direction it needs to go. And it would also then
reencapsulate and forward based on its routing table. Now, that's kind of a big-picture summary of
what happens. But in this Nugget, I'd like to chat with you specifically about a major problem.
And here's the major problem. The service provider right here, when it's forwarding packets on the
public internet, it is not going to allow packets that are sourced from a private IP address space,
such as 10-anything-- and the service provider also will not forward packets if they are destined to a
private IP address space.
Those are not considered to be routable over the public internet. Because it is likely that there are
millions of companies and entities that are using that private IP address space. So it's not routable
over the internet. So how do we get Bob at Computer 2, who has a source IP address that begins
with a 10 network, how do we get his packet successfully routed over the internet? And the answer
is, my friend, we are going to lie about the IP address that Bob is using.
And this lying process is referred to as Network Address Translation, or NAT. So to implement
NAT, here on R2 what we can do is assign R2 a pool of IP addresses. Let's say we have

through 80. And these would represent IP addresses that are routable over the internet.
Now, as a company, we aren't just going to pick these, nilly-willy, out of the air. These are IP
addresses that are associated with our company. So the entire internet and the routing on the internet
would have to realize that this IP address space is all belonging to this company right here, Acme
So that way, if a server on the internet ever need to send a packet to, 68, 69, 70, et cetera,
the internet is going to route that traffic over to our service provider, who will then route it back
over to us, specifically over to R2. And here's the game we play with NAT.
When Bob sends his packet that goes through the network and it hits R2, R2 is going to say, oh, I
realized based on the rules that have been set up, I need to perform network address translation. So
if Bob's source address is 10.1.0.-- let's say it's 50, just as an example-- what the router is going to
do, it's going to swap it out and replace the source address with 23.1.2.-- let's use the first IP address
in this pool of 65. And then it will continue to forward that packet out to the internet.
So now the internet sees this source IP address as and not as the private IP address space.
And the magic is that R2, this router right here, Router 2, is going to remember that translation and
keep it in memory. Why? Because if a packet ever comes back to the IP address of, R2
has to remember to untranslate that and replace the address back with the so that it can be
further routed all the way back into Bob.
So that's what network address translation is all about. It's about swapping out an IP address from a
Layer 3 packet and replacing it with something else. In this example, we're replacing an RFC
private IP address space with one that is publicly routable over the internet.
And when we replace the source address, as we did here-- so Bob's source address of got
replaced with the source address of for that packet's journey over the internet-- they refer
to that as Source NAT, because we're replacing the source address.
In this example, Bob's computer's source IP address was replaced with a globally routable IP
address so it could be sent over the internet without being blocked at the service provider. So we
might also infer from that, if Source NAT is swapping out the source IP address, then Destination
NAT is very likely swapping out the destination IP address.
And that's exactly what that is. And a scenario where we'd use Destination NAT is this. See this

server right here, this public-facing server, Server number 1? Let's say it has the IP address of That's the IP address it has on our DMZ. Now, that IP address of starts with a
10, it's in the RFC 1918 private address space. That's not routable over the internet.
So how is Lois out here on the internet going to be able to get to that web server? And the answer is,
we are going to set up Destination NAT. So here on R2, once again, we could go ahead and say, let's
use So we'll change the range of the NAT pool, and we'll use, which is still
allocated to us to our company, as a globally routable address.
What we'll go ahead and do is have R2 map that IP address over to this internal IP address of So now when Lois is sending a packet to, that packet will be routed to R2. R2
will see that destination address. And because it's configured with NAT, and R2 is also configured
with a rule that says we're going Destination NAT, R2 is going to change this IP address,,
over to and then continue to route it inside our network.
So in that case, the firewall would get it, and then the firewall would route it up to the final
destination, which is this Server number 1. Or if we were using a load balancer, we could have an
internal load balancer using a private IP address on the inside and then have a globally reachable
address map to it on the outside using Destination NAT.
So Lois would go to, and if that global address was mapped to an internal address of this
load balancer, we'd have a very similar result. Except this time, the packet would be routed to the
load balancer, which could then load balance across multiple servers on the back end.
Now, one of the big challenges with doing network address translation is that usually, especially for
small companies, they don't have a pool of globally routable IP addresses that they can use to
perform network address translation on. In fact, for many small companies, they may only have a
single IP address that's on this router interface right here that allows that router to connect to the
And maybe this was assigned via DHCP from the service provider. Or perhaps the service provider
told us specifically what IP address to use, and that's what we're using. So let's say we have the IP
addresses that ends in .253. And for our discussion, let's say that that IP address is a globally
routable IP address on the internet today.
Now our problem is we have users, like this user and this user and this user, and the challenge is
that these users, whose network address all begins with a 10, which is the RFC 1918 private address
space, how do we get them out on the internet if we don't have a whole pool of IP addresses to use

for individual devices to get a one-to-one network address translation as those packets go out to the
internet? And one solution would be to use PAT, Port Address Translation.
And Port Address Translation is amazing. It's also sometimes in a Cisco environment referred to as
overloading. And it goes something like this. Bob's computer sends a packet out to the internet. It
hits the SNAT device, R2. And if Router 2 is configured to operate as a Network Address
Translation device using PAT-- PAT really is just a subset of Network Address Translation, we're
still swapping out an IP address.
And with PAT, what the router is going to do, it's going to go ahead and put whatever that first three
octets are, .253, with the global routable address. So from the internet's perspective, it looks like
Bob's packets are coming from the IP address that's been assigned to the interface on Router 2, a
single IP address. Now what about another user like Laura? Let's say Laura is sitting at Computer
number 1. She also wants to go out to the internet.
Let's say she has the IP address of .51. So Laura's source IP address is, and once again, the
router, if we're using PAT, will change that source IP address and change it to the first three octets of
whatever is on this interface .253. Sp Bob and Laura's traffic, as it goes out to the internet, are both
going to appear as if coming from .253. Now one of the challenges is if Bob is going out to the
internet and Laura is going out to the internet, it's very likely we're going to have replies coming
back from the internet.
So those replies, as they come back, R2, Router 2 needs to do a very good job of keeping track to
make sure that the correct response goes back to the correct client. And the way it tracks these
translations using PAT is by also including port information.
So with PAT, the router keeps track of not only the IP address involved in that session or in that
conversation, but it also keeps track of Layer 4 information, such as ports with TCP or UDP ports.
And we'll talk more specifically about ports in a separate Nugget.
But for now, I want you to be aware that it's tracking that additional information to make sure that
when the response comes back, that this Router 2 running PAT can correctly forward the correct
response to the correct client. So for example, maybe Bob's source port was 13,000. And maybe
Laura's port was 1875. That will also be tracked in the translation table on Router 2 so that when the
replies come back based on the ports involved and the types of traffic, the router can correctly send
back the response to the correct client.
And the benefit of using Port Address Translation is we can overload tens of thousands of IP

addresses of clients on the inside, for example, on a single IP address that's routable over the
internet. And it's for this reason alone, the ability to Port Address Translation, which is a subset of
NAT, that has kept IPv4 in business for over a decade longer than it really should have.
And that's because, as IPv4 has run out of address space, we can continue overloading tens of
thousands of IP addresses behind one PAT address to extend the lifetime of an otherwise-exhausted
IP addressing scheme. So what I thought would be fun is a simple example.
Let's going to PC number 2 here, which is running Windows 8.1. It's currently connected to this
network. R2 is currently configured with Network Address Translation. Specifically it's using PAT,
Port Address Translation, which is a subset of NAT. And it's doing overload regarding the IP address
on its interface, 3/2. So all the customers here on network, as they send their traffic out to
the internet, Router 2 is going to translate the source IP address, as well as keep track of all those
sessions so that when the reply traffic comes back, it can correctly untranslate that traffic and
forward the responses back to the right party.
So here on Bob's computer, which is PC number 2, let's go ahead and open up a browser. And all
I'm going to do is launch Chrome. It's going to Google's main page. And that's it. Because that was
enough to generate traffic going out to the internet, including DNS, including this web page that
we're looking at.
And Router 2 in our topology did Network Address Translation to allow those packets to be sent to
the internet and also allow the correct return of that traffic to Bob's computer. So here we are on
Router 2, which is the perimeter router between Acme Incorporated and the internet service
And if we issue the command show ip nat translations, it's going to have all the translations that are
currently in the table on this router. Now, this is an example of a Cisco IOS router. And the
command on a different flavor router might be slightly different.
And the point I want to drive home is that this router is doing Network Address Translation and
specifically the subset called PAT, Port Address Translation. And because we're doing translation of
source addresses, it could also be referred to as doing SNAT, or Source NAT.
So here is the inside computer, which was And even though I only opened that one
browser, there was just a ton of different requests to populate and fill that browser. And what I'd
also like to point out are these are the ports involved. So as Bob's computer chose some ports to use
for the individual sessions, Port Address Translation is tracking those.

And on this router, it's also changing those source ports to the source ports the router wants to use
for the PAT. So, which is the IP address on PC 2 that Bob's using, got translated to the
address that ends in .253. And in my lab environment, I also happen be using and RFC 19 address
space on that outside interface as well for this PAT process.
And that's not atypical. Service providers often will use for the first couple of hops until you get
through their network, they'll often use RFC 1918 addresses as well for the customer edges of their
networks. In this Nugget, we learned that Network Address Translation is all about swapping out an
IP address at Layer 3 in an IP header.
If we swap out the IP address on behalf of one of our clients that's going out to the internet, that's
referred to as Source NAT, because we're replacing the source IP address. If a client from the
internet is trying to hit one of our servers or connect to one of our servers, they would be connecting
to a public IP address, which we would be swapping out for an internal address for that destination
And that's an example of a Destination NAT, where we're swapping out the destination IP address in
the header before we continue to forward the packet. And because we don't have enough global IP
addresses for every computing device on the planet for IPv4, we use Port Address Translation,
which allows us to overload a single global routable address with tens of thousands of IPv4 private
addresses per global address.
And that subset of Network Address Translation is referred to as Port Address Translation, because
it's tracking the port information, for example, the TCP or UDP port information, in addition to the
Layer 3 translation to make sure that the replies for each of those requests goes back to the right
individual on the inside network.
Configure IPv4 Addressing
In this Nugget, together we'll apply IPv4 addresses to router interfaces as well as to computers. Let's
begin. I'd like you to imagine in your mind that we've come up with an IP addressing scheme as
follows. So these networks-- these IPv4 networks A, B, C, D, E, F, and G-- represent the networks
A, B, C, D, E, F, and G.
So for networks A through F, we're using a class A address of 10, which is in the private RFC 1918
private address space. We're using a 16-bit mask on networks A through E, a 24-bit mask up here at
the branch office on network F. We're also using a private RFC 1918 address space of 192.168, right
here between router 2 and the service provider. Here, circled in green, are the host IP addresses I've

assigned to the router.

So router 1, its IP address ends in dot 1 on both of its interfaces. And router 2, on its interface going
to the firewall, it ends in dot 2. And the 2/0 interface also has a dot 2. However, the interface that
goes over to the internet service provider, which is on the 192.168.1 network, that has a host address
of dot 253. And our service provider on that same network has an IP address that ends in dot 1. And
our branch office up here across the serial link, they've got a dot 4 as their host IP address in that
last octet.
So what I thought would be fun to do is go to the implementation of our IP addressing scheme on
actual gear. Now there's lots of vendors out there who make routers. The primary vendor is Cisco,
but there are others, such as HP, Juniper, and several others.
So as we go through applying the IP addresses on router 1 and router 2. I'd love for you to focus on
the concept of what we're doing. We're applying IP addresses to router interfaces. The actual syntax
will vary from vendor to vendor, depending on whose router-- which vendor's router we're
Also for our discussion, let's say the firewall is already pre-configured. And it's using dot 100 on all
of its interfaces, the one that goes to router 1, the interface that goes up here to the switch, and the
interface that goes over to the right to router 2. So the firewall team has already configured the
Our job is configure router 1, router 2. There's also a branch router out here. And while we're at it,
let's also configure one of our computers that's on the internal network. And instead of using DHCP,
let's use static configuration to configure its IP address, its mask, its default gateway, and the DNS
server that this PC is going to use.
And for our demonstration, let's say the default gateway is going to be the IP address here on router
1, which is The mask is going to be 16 bits in length, which we represent in dotted
decimal. So that'll be And the DNS server will tell computer 2 to use is-- let's use one
of Google's out on the internet-- at Now you might ask, well, how in the world is this
computer going to get to a DNS server that's way out here on the internet? The answer is it will use
this default gateway.
So as long as the default gateway is configured correctly, and router 1 has reachability out to the
internet, that DNS request from computer 2 should be able to be forwarded all way out to the
internet, including going through the process of network address translation, which we talked about

in our Nugget on that.

That will swap out the private IP address that computer 2 is using for a globally routable address as
a packet gets forwarded out the internet. We're going to begin our configuration right here at router
number 1, which I've affectionately named R1. And this happens to be a Cisco IOS router.
And to get into what's called configuration mode-- to make changes to the router configuration-- we
type in the command configure space terminal. If you're watching somebody else configure this
live, they might just type in config space t, which is a shortcut for the command configure space
It basically means we want to configure this router from the terminal that we're currently connected
on. Next, because a router has lots of different areas that we could configure, we need to go
specifically to the area that we want to configure. And that's interface 3/0. And to do that, we would
simply type in the command interface space Ethernet 3/0 and press Enter. And that takes us
logically into this area, this room, if you will, for the configuration parameters for that specific
And on some devices, even if they say the word Ethernet, sometimes it may be fast Ethernet or
gigabit Ethernet. And when talking about gigabit versus fast Ethernet versus Ethernet, it's all about
speeds. It really is the same technology, but just done at different speeds.
Now sitting here in interface configuration mode for interface 3/0 on router 1, to give it the IP
address that we planned on-- and to be clear, the IP address that we want to assign to this interface is with a 16-bit mask-- what we're going to do is we're going to type in the command IP
Put in the IP address, space, and then the mask in dotted decimal. So here in interface configuration
mode, that would look like this. IP address space, which represents the first 16
bits of the IP address, is being used for the network in the last two octets, the last two numbers, are
being used for host addressing.
And if you need any refreshers on IPv4 addressing or subnetting, I would have you refer back to our
IPv4 subnetting course to brush up, if needed, on any aspects regarding IPv4 or IPv4 subnetting.
The other thing we're going to do here on this interface is we are going to bring it up with the
command no shutdown.

By default, the interfaces on a Cisco router are shut down by default. So the no shutdown brings
them up. And then we're going to type in exit, and that's going to exit us out of that interface
configuration area on this router. And we're now back in an area called global configuration.
However we have another interface to configure. That's this guy right here, interface 3/1. And it's
going to have the IP address of dot one on network B, which is that's the network-- slash
16. So to do that, we'll go into that specific interface, interface Ethernet 3/1. We'll use the command
IP space address of And we'll put a 16-bit mask in dotted decimal. And then we'll do a no
shutdown there as well.
And if we're completely done with configuration, we could go ahead and type in end, and that will
take us out of configuration mode back to what's called privileged mode, here at the command line
interface, the CLI, of the Cisco IOS router. Next let's make a road trip over to router 2. Again we'll
presume for this discussion that the firewall has already been configured for us.
And let's go to router 2. So here on router 2 we'll go into configuration mode. We'll go further into
interface Ethernet 3/1 and give it the IP address with a 16-bit mask. Now also on this
router, router 2, it is also performing network address translation.
And although there are quite a few commands to implement it, one of those commands on a Cisco
router is the command IP NAT on the interface. And that simply identifies this interface-- if use the
IP NAT inside command-- as an inside interface from the perspective of NAT.
And over here on interface 3/2, we could use command IP NAT outside. And that indicates the NAT
that this interface is an outside interface. So if there's a rule in place that says, OK, traffic coming
from the inside that's going to the outside, as long as it matches certain parameters, let's go ahead
and do network address translation, these IP NAT inside and IP NAT outside commands allow the
router to know which interfaces are inside and which interfaces are outside.
So here in interface config for 3/1 on router 2, I'm going to use the command IP NAT inside. We'll
bring the interface up with command no shutdown. And then we'll exit interface configuration
mode. Next, let's go to interface 3/2. This is the interface connecting R2 over to the internet service
So we'll go into interface config for Ethernet 3/2. We'll give it the IP address of with
a 24-bit mask. We'll use the command IP NAT outside. We'll bring it up with a no shutdown. And
then we'll exit interface configuration mode. And we're not focused on memorizing syntax.

We are focusing on the concept of applying IP addresses to the interfaces of a Layer 3 router. In our
example, it's a Cisco IOS router. Next we have this interface right here. This is serial 2/0 that's
connecting to our service provider for a wide area network connection up over to our branch office.
And that is network E. And network E is the network. The IP address we're going to
have on R2 is dot two as the host ID. So here from global configuration we'll go into interface serial
2/0. We'll give it the IP address of with a 16-bit mask, which is spelled We'll
say IP NAT inside.
We'll do a no shut. We'll type in exit. And we'll end to get out of configuration mode. Now you
might ask, well, Keith, how come this is an IP NAT inside interface? And the reason for that is if
users up here at the branch network, if they are forwarding traffic over this WAN link, and that's
how they get out to the internet, because they're also using private RFC 1918 addresses, as router 2
forwards that traffic out to the internet, from a NAT perspective the router 2 needs to make sure it
does the translation of the source addresses before routing the branch's traffic out to the internet.
And that's why we added the IP NAT inside command here well on serial 2/0. And then last but not
least, we need to configure the branch router. So let's go to the branch router. So here at the branch
router, we'll go into configuration mode. We'll go into interface serial 2/1, because that's the
interface it's using to connect over the WAN network.
We'll give it the IP address of with a 16-bit mask based on our plan. And we'll bring it up
with a no shutdown command. Now last but certainly not least, let's go over to computer 2. And we
could use a DHCP service. For example, we could make computer 2 a DHCP client, assuming that
there is a DHCP service running somewhere in this network.
Or we could manually configure the details for the IP address, the mask, the default gateway, and
DNS. So let's do that. Let's use dot 190 as the host ID for computer 2 on the network.
For the default gateway we'll point to dot one on that same network.
For the mask, we'll indicate as a 16-bit network, which is 255.255 in dotted decimal. And we'll tell
this computer to use as its DNS server. So here at PC one, let's go to our Control panel.
There's lots of ways of getting there. We could go to the Windows main page.
Type in control to get there. Or we could right-click on our network interface card and go to
Properties. That would get us there as well. So let's scroll down a little bit and go down to Network.

Here's Network and Sharing Center. That looks great. There's Change Adapter settings.
Here's our Ethernet zero interface on this Windows computer. We'll right-click. We'll go to
Properties of that interface. And we'll scroll down to TCP/IP version 4. And from here we could
double-click or we could click on Properties. And instead of using DHCP, we want to go ahead and
statically configure this.
And we'll specify the IP address as 10.1, which is the network we're on. And our host ID is going to
be 0.190. Based on what? Based on our plan that we just created a few moments ago to identify
what IP address we're going to use on this computer. We'll hit Tab.
And you'll notice when I hit Tab, it automatically wants me to use And that's because it
knows this is a class A address. And by default, the default mask for a class A address is just that
first octet. However, we are doing custom subnetting. And we're using a 16-bit mask. So we'll put
255 for that second octet of the mask to indicate that our network address is 16 bits long. Our
default gateway is at 10.0.1. We just configured that a few moments ago.
And then we'll specify that the DNS server that we want to use is, which is a Google DNS
server. And we'll click on OK. Then we'll click on Close. And let's go to a command prompt just for
a moment and verify our configuration with an IP config. So by typing in IP config, it shows us our
IP address, the mask length-- which we put in-- and our default gateway at 10.0.1. If we want to see
more detail, we could use IP config space /all.
And that would show us additional information, including our Layer 2 MAC address, whether or
not we are DHCP client at this moment or not, because we manually configured the details. There's
our IPv4 address, our default gateway, and there's the DNS server that we configured as well.
So from a troubleshooting perspective what we could do is if we wanted to verify basic
connectivity, we should be able to ping the IP address of our default gateway, because it should be a
local IP address on our same IP subnet. So if we type in ping and type in Press Enter.
Sure enough, we have four replies out of four coming back from our default gateway. That's R1
who's responding to us. So if we did a ping out to, which is our DNS server, which is on the
internet. We'll press Enter. And it's coming back saying destination host unreachable.
What possibly could be the problem? Well, let's take a look at our topology together to identify
what the problem is. So here in the verify stages, we configured IP addresses on the router

interfaces. We configured an IP address on computer 2. We verified that computer 2 could ping its
default gateway at However when computer 2 tried to access an internet resource like, it was not successful. And my friend, on a new network, here is the reason why.
These routers do not know diddly-squat besides what they are directly connected to. Router 1
knows about the 10.1 network because it is directly connected to that network. Router 1 also knows
about the 10.2 network because it is directly connected to that network.
However, what router 1 does not know is anything beyond those directly connected networks. It
doesn't know how to get to network C or network E or network G or anything on the internet,
because we have not implemented any type of routing yet, as far as training the routers on how to
forward traffic.
And that, my friend, is the topic for our very next Nugget. So in this Nugget we identified how to
apply IP addresses based on a plan to our router interfaces, verify connectivity between a computer
and a router on the same subnet. And as I mentioned, in our next Nugget on routing, we'll take a
look on training the routers on how to make intelligent forwarding decisions based on Layer 3
information it sees in each packet that it receives.
Static and Default Routes
Is it possible to educate a router regarding how to forward IP packets? The answer is yes. And we're
going to investigate that and demonstrate that in this Nugget. Let's begin. In our last Nugget
together where we implemented IP addresses on the routers and on PC number 2, we had a little
issue in that the Router number 2 didn't have reachability back to this network. It couldn't reach We tried pinging that IP address of Router 1, and we could not get there.
And in that Nugget, I mentioned it was due to routing. The routers only know by default about
networks they are directly connected to. So if we went up and asked Mr. Router 1, we said, hey,
Router 1, what do you know how to reach? He would say, I know how to reach Network A, which
is 10.1, and I know how to reach Network B, 10.2, because, says Router number 1, I am directly
connected to those networks.
I live on those streets. It's like having a house with two driveways. And that's referred to as a
directly connected route, or a directly connected network. And that is one way of training a router
on how to reach a network. You give it an IP address on a network, and poof-- that router believes
it's connected to that network.

And the information regarding those directly connected routes are put in something called the
routing table of the router. Think of the routing table like a giant map of how to get places. Every
time the router get a packet, needs to forward it, it consults its routing table and says, OK, how do I
forward this packet to get it towards its final destination? And if it doesn't know, if it doesn't have
any information in its routing table, it just gives up.
And it drops that packet, and in some cases, it will go ahead and get a response back to the source,
like for example, if Computer 2 tried to reach the internet and Router 1 didn't know how to get
there, R1 might send a message back to Computer 2 saying, you know what? Sorry, I don't know
how to get there.
I'm so sorry I dropped your packet. And that response back from Router 1 back to Computer 2 is
done with a little management protocol called ICMP, which we'll talk about more in a separate
Nugget. So next, our challenge is, how do we train routers on how to reach or forward in the
direction of networks that are not directly connected? And we have two primary options, and they
are right here.
We can statically configure what is called a static route. It's like hard-coded instructions. So in the
case of Router 2, which has no knowledge, by default, on how to reach the 10.1 network-- that's
Network A over here-- we could configure a static route on Router 2 that says the following.
Dear Mr. Router 2, if you need to forward a packet to the 10.1 network, the next hop, which is a
fancy way of saying the next device in the path, to get to that network is-- and we would go ahead
and give it the IP address of our firewall, which on Network D would be So that route
would then be added to the routing table because of our static route that we added to Router 2. And
if Router 2 ever needed to forward a packet to the 10.1 subnet, it would know that the next hop is
the firewall, at which point it will go ahead and reencapsulate the IP packet into a Layer 2 frame
that had the Layer 2 address of the firewall.
And if Router 2 didn't know the Layer 2 address of that firewall, it would go ahead and do an ARP
request, cache that information, encapsulate the frame, and then it's up to the firewall's job to
forward it the rest of the way. So the world of IP at Layer 3 is like hot potato. You get a packet in,
you look at it, you make a forwarding decision, and you move to the next packet.
And you do it as quickly as possible. And in the event you don't know how to forward a packet, you
drop that packet. Now in the case of Router 2, it would be a really big pain do static routes. For
example, we'd have to have a static route that says how to reach Network F and how to reach
Network C and how to reach Network B. However,

Router 2 is directly connected to Network D, Network E, and Network G. So it's no problem with
those three, but it would need static routes for the rest. Also, what about the networks that are out on
the internet? We certainly are not going to statically configure, manually configure static routes for
each and every network that exists on the internet.
So we have a special type of route, and it's called a default route. It looks like this. If you ever see
your route with four zeroes for the IP address and four zeroes for the mask, that, my friends, is a
default route. That we can go ahead and place, again, in the routing table of the router.
And when I think of default route, even to this day, I think of Star Wars. Remember Princess Leia
saying something like, help us, Obi Wan Kenobi. You're our only hope. That's kind of like what a
default route is. It's a last-ditch effort. If it can't find anything else in its routing table to use to
forward a packet to its final destination, it's going to sigh.
You can think of it sighing, saying, ah, I can use my default route. And then it will go ahead and use
the default route, and that default route is going to specify what that next hop is. So in the case of
R2, it's very likely that if we were going to configure a static default route, we would tell R2 that
the default route would be the IP address of .1 on the 192.168.1 network, which is the service
provider for everything out on the internet.
So here's what I would love to do with you right now. Let's configure static routes on Router 1,
Router 2, and also the branch router out here. And on Router 1, we'll tell it to use the firewall's IP
address as the next hop for its default route, which we'll configure statically.
The firewall, once again, has already been pre-configured by the firewall teams. So that's already in
place. On Router 2, we'll configure a static default route that says to use the service provider as the
next hop. And for the branch router out here, we'll tell the branch router to use R2 as its default
route. So any time these routers have a packet they need to forward and they consult their routing
table, if they don't have an exact match in their routing table for the network this packet is destined
to, they'll go ahead and use the default route and forward the packet using that default route in their
routing table.
So we're going to start our journey here on R1. Now again, the exact syntax isn't critical for
Network Plus. The concept, however, is important to get. So here on Router 1, let's go ahead and do
a show ip route. On a Cisco router, that is the command to look at the IPv4 routing table. And in
Cisco's IOS version 15.x, they also show with this output something called a local route.

And to clean that up just a little bit, I'm going to use the command show ip route, a pipe symbol,
and then I'm going to say, please exclude any output that has the capital L in it. And then I'll just
make the output more simple for us to go through and work with.
So from Router 1's perspective, it currently knows how to reach the 10.1 and the 10.2 networks.
And that's networks A and B. Because it is directly connected to both of those networks. And at the
moment, Router 1 does not know how to reach any networks outside of those two networks that we
see right here.
So here on Router 1, let's go into configuration mode with the command config space terminal. And
we'll configure a static default route using the command ip route, quad zero, space, quad zero, and
then the next hop of, which is the firewall. So there's our quad zeros with three periods
in between.
These are dotted decimal. There's the mask as four zeros. And again, that's the special code for
default route. And the next hop is, which is this interface on the firewall right here. Now
just because we're going to use the firewall as our default route, it doesn't mean the firewall
"automagically" knows how to forward everything.
Every device in the network needs to be configured to make correct forwarding decisions. And it
just happens for us that the people who configure the firewall, they've already configured that for
us. And it's very likely, if we looked at the configuration of the firewall, it would very likely say that
its default route is to forward packets over to Router 2. And that's why, my friends, it would also be
a very good idea for us to configure a default route on R2. So if it receives packets for the internet,
it also will know how to go ahead and forward those packets.
So before we leave Router 1, let's get out of configuration mode and do a show ip route once again.
And you'll notice now in the output of our routing table, it's showing this default route. It's also
indicating over here that it was learned statically, because it was a statically configured default
And it says if I get a packet where I don't know the destination of how to route it, I will go ahead
and forward it to, which is the firewall's IP address. Great. Router 1 is configured with a
static default route. Let's go to Router number 2. On Router 2, let's do a show ip route here as well.
Again, I'm going to exclude the output that has the L in it just to make it a little bit more readable.
And as we look at the routing table here on Router 2, it has three directly connected networks that it
knows about, the 10.4, which is Network D, the 10.5, which is Network E, and the 192.168.1,

which is Network G. So if we want to modify the routing table by adding a static route, and more
specifically a default static route, we'd go into configuration mode with configure, space, terminal,
and use command ip, space, route, quad zeros, space, quad zeros, the next hop of And
then we get out of configuration mode.
So once again, if we do the command show ip route to look at the routing table, we're going to see
the directly connected networks, and we're also going to see the static route, which is the default
route, using, which is our service provider, as the next hop.
And we could actually implement additional static routes besides the default route. We could add a
static route, for example, that told R2 to get to the 10.1 network specifically, to go ahead and hand it
to the firewall as the next hop. But what you're going to find is that in most environments, using
static routes for all the detailed routes is really tedious, takes a lot of effort, and anytime there's a
change, we have to go back and manually change static routes, which is too much administrative
overhead to do, too much burden on you and I, the administrators.
So we have some alternatives to using the static routes anywhere. However, using a default static
route is a very typical and common thing to implement. So we have one more router to do, and
that's our branch router. So let's go out to the branch site. And we'll go into configuration mode on
the branch router, and we'll use the command ip route.
We'll specify the default route. And we'll say that, which is Router 2's IP address, is going
to be the next hop. So anytime we need to forward packets, says the branch router, and we don't
have a more detailed route in our routing table, we're just going to ship that packet off to R2, and
hopefully, says the branch router, R2 knows how to continue forwarding that packet. We don't have
any guarantees.
We're just hoping that the neighbor that we're handing this off to can forward the packet. So on the
branch router, if we do a show ip route here, it should have any directly connected networks, as well
as its default route. So at the moment, it's got the 10.5 network, which is the serial link between
itself and R2. And it also has the default route that says it should use R2 if it ever needs to forward a
packet out to the internet.
So with these default routes in place, let's go down to Router 2 for a moment. And let's verify that
Router 2 can ping an internet resource. I like using a Google DNS server, because it's usually
available. So we'll do a ping out to, and sure enough, Router 2 has successful connectivity
out to the internet.

It's using the default route to reach the address. Because it doesn't have a more detailed route
in its routing table for 8 dot anything, so it used the default route, handed the packet off to its
service provider at .1, and the service provider fortunately knew how to forward it the rest of the
So next, let's see if Router 2 can ping the 10.1 network. In fact, let's try to ping That's
Router 1's interface address on 3/0. And we're getting period, period, period, which is timing out.
We're not getting a response back from anything. So I think the technical term for that is, bummer,
Why isn't it working? R2 cannot ping over to the 10.1 network, or at least it's not successfully
getting a response back. So if we look at the routing table of R2, it doesn't have a specific route to
the 10.1 subnet, which means it's using its default route and sending the packet out to
for routing. And that's going out this way.
So unless our service provider has some magical means of getting to the 10.1 network, that would
explain why we're not successful in our ping. It's very likely that the service provider does not itself
have a route back to our internal 10.1 network. Even if it did, even if the service provider said, yeah,
hand it back to R2, when R2 gets a packet to 10.1 based on its routing table, it would forward it
back to the service provider.
And that would just go back and forth and back and forth, and that's what's called a routing loop. So
a Layer 3 routing loop is when two routers are handing the packet back and forth and back and forth
and back and forth, each of them following the instructions that they have in their routing table on
how to forward a packet.
And as you can imagine, a routing loop is a pretty serious problem, because it's consuming a lot of
resources by the network devices. It's consuming bandwidth. And the packet is not getting to its
final destination, which, of course, is an additional problem.
We can also verify what R2 is going to do with this packet by using a Cisco IOS command called
traceroute. Now, this command is very similar to trace RT on a Windows platform. And on a Cisco
router, the traceroute command will simply show us the path that the packet is taking.
And I'm going to go ahead and hit Control-Shift-6 to stop this output on this Cisco router, because
it's not getting any further. And what this indicates is that our first hop was, which is the
service provider. And then it's very likely that our service provider just dropped it.

Because the IP address of 10-anything is not a destination on the public internet, because it's in RFC
1918 address space, the 10 is. And as a result, we are forwarding in the wrong direction, R2 is,
based on our current routing table. In this Nugget, we've identified a couple of ways of putting
routes in the routing table using directly connected networks that go into the routing table, as well
as manually statically creating routes that can go in the routing table.
The example we used was a static default route. Now, there is a much more efficient way to train a
router regarding how to reach multiple networks, and that is to use a dynamically configured
routing protocol, which, my friend, you and I will cover in the very next Nugget.
Dynamic IP Routing
In this Nugget, we get to take a look at using Dynamic Routing Protocols to dynamically update the
routing table on our devices in the network, such as layer 3 routers. We have directly connected
routes to make it in the routing table. We have statically configured static routes that can go in the
routing table.
But very likely, in most organizations, we're using some type of dynamically learned route that also
is placed in the routing table. And dynamically learned routes are very likely being received and
learned due to something called a Dynamic Routing Protocol.
And with the routing protocol, we would run this on each of our devices. For example, Router 1
could run a common routing protocol. The firewall could run the routing protocol. Router 2 in the
branch office could all run this routing protocol. And effectively, using the routing protocol, they
could share with each other information about networks and reachability to those networks.
So the branch office has the network /24 out here, that's Network F. And if it was running a
routing protocol, it could dynamically advertise or communicate that network over to Router 2. And
so, as Router 2 learns about this network and says, oh, I know how to reach that network of 10.6, I
would go ahead and forward it to the next hop of the branch router to get there.
And there's two broad categories of routing protocols-- one's called an IGP, which says for Interior
Gateway Protocol. And the other broad category is called Exterior Gateway Protocol. And an
Interior Gateway Protocol would be used inside of a company. For example, if this all is Acme
Incorporated, they've got their headquarter site and a branch office, it's very likely they're going to
be running one IGP.

For example, they might be running OSPF, which is an Interior Gateway Routing Protocol that they
could run. Or if they're running Cisco's proprietary IGP, they could be something like EIGRP.
Which, if you're running EIGRP, it would be on Cisco gear. Because even though Cisco has allowed
others to see the standard, it's still, at the end of the day, a Cisco proprietary routing protocol.
And there's also some older protocols, too, like RIP-- Routing Information Protocol, and currently
we have Version 2. And the methods that these routing protocols use to communicate and advertise
networks varies, but there's also some classes within these IGPs.
For example, OSPF is an example of something called a Link State Routing Protocol. Another Link
State IGP is called IS-IS. And for the details of how the specifics of those routing protocols work, I
would have you join us in one of our Cisco courses. And if you're just starting after Network Plus,
you might want to join us for ICND 1, which is a perfect next step in your progression and your
learning as you take a look at building computer networks today.
EIGRP is proprietary to Cisco. And RIP Version 2, very much like OSPF and IS-IS, is an open
standard, but it uses a technology called Distance Vector. And the way I think of Distance Vector is
routing by rumor. For example, if the branch router and Router 2 are both running RIP Version 2,
and the branch router is saying, hey, I can reach the 10.6 Network, Router 2, with a Distance Vector
Routing Protocol, is really just taking the word of the branch router that that network is reachable.
R2 doesn't have a direct knowledge of the 10.6 Network, it's simply believing that 10.6 is reachable,
using the branch router, because the branch router advertised it. Now, if we contrast that to a Link
State Routing Protocol-- with a Link State Routing Protocol, the advertisements from the branch
router regarding a directly connected network of 10.6 is flooded or forwarded over the entire
network so that every single router can see firsthand from the branch router's perspective that that
network does exist, and then they can do their own calculations on how to get there.
The short story is, we don't use a lot of Distance Vector Routing Protocols anymore. We're going to
opt for more accurate routing protocols, like OSPF-- which, besides being more accurate, also
converges faster. And convergence is a point in time when all the routing devices have a correct
routing table to get to any network they need to reach.
And if we take a look at EIGRP, EIGRP from Cisco is kind of an Advanced Distance Vector
Routing Protocol. And that's pretty much we need to say about EIGRP in Network Plus. Again, for
more details on EIGRP, come join us in ICND1 and ICND2, which are Cisco-specific courses here
at CBT Nuggets.

Now, IGPs, such as RIP Version 2 and OSPF, are great for companies that want to dynamically
learn and train their routers about how to reach networks. However, on the internet, where we have
huge entities, huge service providers with 10s of thousands of routes each, when they exchange
routes-- let's say we have ISP1 and ISP2-- when they exchange routes, the service providers do not
use IGPs as they exchange these 10s of thousands of routes with each other.
Instead, they use an Exterior Gateway Protocol, and fortunately there is just one, and that is BGP,
which stands for the Border Gateway Protocol. And so ISP1 and ISP2 are both running BGP. They
have specifically configured each other as neighbors, and they will then dynamically be able to
advertise and received routes with each other regarding making the internet go.
So here's what I would love to do for our little topology right here. Let's go ahead and use the
Legacy Distance Vector Routing Protocol named RIP Version 2, and let's apply it to Router 1, to
Router 2, to our branch office-- the firewall guys have already configured the firewall to run RIP
Version 2. And once we enable it, it can be used to dynamically share all the network information
and the reachability for those networks with our routers so that we do not have to statically
configure individual routes on Router 2 or the branch router or any other routing devices inside of
our infrastructure, because they will be participating with each other to exchange and learned routes
in our networks using RIP Version 2. So what we get to do is, we're going to add the RIP
configuration to R1, to R2, the branch office, and the firewall is already configured for us.
Now, the actual syntax for configuring RIP and enabling it on a Cisco router, not critical for
Network Plus. But the concept that we can use a Dynamic Routing Protocol, such as an IGP called
RIP Version 2-- which is an example of a Distance Vector Routing Protocol-- that part is important.
So that's the configuration for R1. So R1 is now enabled to participate in the routing information
protocol RIP Version 2, and we'll do the same thing on Router 2. So here on Router 2, we'll enable
RIP here as well. So we'll go into Configuration Mode I'll say Router RIP, we'll specify Version 2.
I'm going to say No Auto Summary, please.
And the network in RIP configuration means all interfaces that are currently running IPv4
are also going to be participating and sharing and receiving information via Routing Information
Protocol Version 2. So we'll do the same thing up on our branch router.
So here at the branch router, we'll go into Configuration Mode and enable RIP here as well-- the
same exact concepts that we did over on R1 and R2. And the firewall has already been configured
for us. Now, check this out. Once we give the network a few moments to converge-- which is a
fancy way of saying that all the networks have been learned by each router and that information was
communicated and shared via that routing information protocol that we're running on each router.

So now with RIP enabled on all of our routers, including the firewall-- which was done for us by the
firewall team-- let's go back to R2. And on R2, let's do a Show IP Route once again to see additional
routes that we now have in our routing table. So R2 now knows about the 10.1 and the 10.2 and the
10.3 Network, all learned via RIP Version 2. And in this routing table on R2, it knows that to reach
any of those three networks, it would go ahead and use as the next hop, and that is the IP
address on the firewall.
Now earlier, we could not ping the 10.1 Network. Let's try it again. We'll ping, which is the
IP address on R1's 3/0 interface. And sure enough, we have reachability there and R1 has
reachability back. If we went over to R1, and we issued the command Show IP Route here, it's
showing us here that R1 absolutely knows how to get to the 10.4 Network-- that's the interface
address here on R2, that's how we reply to or ping request that came from R2. And R1 also knows
about the 10.5 Network, that's Network E, as well as the 10.3 Network, which is Network C. And it
knows about the 10.1 and 10.2 because it is directly connected to those two networks.
And if Router 1 ever needed to go out to the internet, it has a default route here as well. So as a
verification of all this is working, if we go back to your Computer 2-- which has an IP address, it's
using R1 as its default gateway-- now because R1 has a default route, and the rest of the network
also knows how to route out to the internet, we should be able to do a ping from Computer 2 out to
an internet resource.
So my friend, let's give that a try. So back here a PC 2 we'll go ahead use the Up Arrow key. We'll
try that pinging again to, only this time we're hoping for better success, and there we go,
four out of four. And if we did a trace out to that destination-- and the way we do that in a Windows
computer is Trace RT-- I'm going to say -d, for don't bother doing DNS Resolution for each hop in
the path-- and then we'll type in as our target, it's going to show us each hop in the path
between this PC and, which is on the internet. So on the packet's journey out to the internet,
the first hop was R1 at The second hop was the firewall at The third hop was
R2 with And the fourth hop was our internet service provider at Then the next
hop was, which is inside my service provider's network.
So this router with the 24 address is a router that has a global address that's on the internet, and that
was followed by several more hops, till the final destination was hit of In this Nugget, we've
identified that we can use a Dynamic Routing Protocol, such as RIP Version 2, to dynamically share
routing information with other routing devices in our networks.
And these dynamically learned routes, along with directly connected network for static routes, show
up in the Routing Table, which is used for a router to make a Layer 3 forwarding decisions on

individual IP packets. I am glad you joined me for this Nugget.

Well-Known Ports
Doctor, doctor give me the news, I gotta bad case of port number blues. And that's exactly what
we're going to focus on in this Nugget. We're going to take a look at two major transport layer
protocols, TCP and UDP. And then take a look at a boatload of TCP/IP applications, and there are
well-known ports that are used on computer networks today.
One of the cool things that I love about networks is roles. The role a device can take in a
transaction. For example, a server. We kind of get the general idea of what a server does. If
somebody makes a request, it serves up content. For example, a web server is sending back or
serving up web content.
A print server is providing printing services and serving a print jobs. While on the other side of the
house, the client is the entity that's making a request. So in our topology the user at computer two,
for example Bob, as he makes a request out to the internet is going to a web server.
He's acting in that moment as a web client, and the server or servers that are responding back to his
requests are acting as web servers. Behind the scenes, as you know, there's a lot of details that are
going on to make those communications possible. And what if we have a server out here on the
internet that is running DNS services.
Meaning it can respond to DNS requests from a client. Maybe it's got web services running, as well
as DHCP services. Now the question I have for you right now is, if Bob makes a request of some
type, and it gets routed across the internet to this server. How does this server know if it's a request
for DNS or web services or DHCP? I mean how does that server keep those all separate? And the
answer to that is port numbers.
And a great analogy would be if a piece of mail came to my home. So it goes into my mailbox, and
we get it from the mailbox. But there are several people in this house that I live in. My kids are
here. My wife is here. How do we know exactly who the letter's for? Well, we look at the details
regarding the name.
So in addition to the destination address, which is my house address, it also has a name. And by
looking at that name we know exactly who that letter or package is for. Well, in that same sense, we
also use port numbers to uniquely identify the service that a packet is destined for.

And this would be carried in the layer four header information. So if a server on the internet is
running DNS services, it's listening. It's paying attention to a specific port number so it could
respond appropriately. If that same server's running web services, it's listening to an additional port
specific for web services.
And these are well-known ports. They're agreed to and understood so that everybody on the
internet, if they want to be a DNS server or web server, are going to be listening to, or paying
attention to those port numbers on their servers so they can respond back to the clients.
And what I would like to do is chat with you for a few moments about some of the common
services and they're well-known ports that are associated with those services. So here's Bob's
computer. He's connected to a network, there's very likely a router or two in the path.
Here's the internet and here is a server that Bob is going to communicate with. So if Bob wants to
go out to a web server, it's very likely he'll fire up his favorite browser. Whether it's Chrome or
Firefox or something else. And he's going to type in the name of that server, like www.acme.com.
In the background, Bob's PC is going to resolve that name, using DNS to an IP address. And then
Bob's computer is going to send a request to that server. Now, specifically, if it's a website we're
communicating with, it would be an HTTP request that the browser would be creating.
And the well-known port for an HTTP server is port number 80. Also, at the transport layer, Bob
does not get to choose what his transport layer protocol is going to be. We have two primary
protocols at layer four in our protocol stack, but there are several others, as well, that operate at
layer four.
The two primary protocols are TCP, which stands for Transmission Control Protocol. And the other
primary protocol at layer four, is UDP. Which stands for User Datagram Protocol. And let's talk just
for a moment about TCP. TCP is the reliable protocol. This is like the middle manager who's very
concerned in Kingdom A about making sure the data has been delivered correctly to Kingdom B.
And so TCP uses sequencing. It uses acknowledgments. TCP uses something called a three-way
handshake before sending important data. Just to make sure the other site is ready and synchronize
to communicate with the first party. And an analogy that I like for the TCP three-way handshake, to
make sure the other side is ready to talk to us, is if we walked into a grocery store and we just
walked up next to another customer and said, hey, do you are the rutabagas are? It's very likely that
they might ignore us or maybe they didn't hear us, we're not sure.

However, if we walked up to that same person, and we kindly said, oh, can you tell me what time
is? And they say, oh, it's a 2:00 PM. And we said, thank you. Then we have an established
communication path, and then we could say, do you know where the rutabagas are? Now, like it or
not, the other party absolutely heard our request.
We had that little three-way handshake beforehand to confirm that we were communicating, and
now here's the question. Well, TCP does that for its TCP sessions. Those little-three way handshake
guarantees that both parties are talking to each other. And periodically, there'll be
acknowledgements regarding, yes, I got the data.
Yes, I got the data. And at layer four we could refer to those as segments, meaning yes, we did
receive that segment of data. So what's the negative of TCP? Well, because it is so connectionoriented and verifying all the transactions, it is a little bit intensive regarding overhead.
It takes overhead for the acknowledgements and the three-way handshakes, and so forth. And really,
that's the primary negative is that there's additional overhead for TCP to operate. Now the other
major protocol, at layer four in the TCP if protocol suite, is called the User Datagram Protocol.
It is called connection-less. You can kind of think of it as, I could care less, or I couldn't care less
about whether this traffic makes it to the other side. It's like taking a brick and throwing it over the
wall and hoping it lands. No guarantees, no acknowledgements, and that's what User Datagram
Protocol is all about.
And we might ask, well, Keith, why in the world would we use a protocol like UDP? And the
answer is, it is very lean and mean. There's very little overhead, and as a result it might be perfect
for applications such as video and audio streaming. Or it's really, really important to get the data
there on time.
And because it's UDP and doesn't have all the overhead of the acknowledgements and the
sequencing, it's a perfect candidate for those types of applications that could afford to possibly miss
a small packet or two, but on the positive side, it got there very, very quickly.
So going back to Bob's session with his web server, Bob does not get to choose which transport
layer protocol he's going to use. And that's because the applications that Bob uses are already
predestined to choose and select certain layer for transport protocols.

So here, next to HTTP, I put TCP. Because HTTP, the application layer service of web services is
going to use TCP as it's transport. It's not up to Bob, the user. If Bob's using HTTP, it's
automatically going to choose to use TCP at layer four. And the well-known server port is port 80
for HTTP. So this is a web server.
It's paying attention to port 80. So as data arrives at the server, is going to de-encapulate layer two.
It's going to say, hey, look at the layer two information. That's my address. It further de-encapsulates
layer three. It says, hey, that's my IP address says the server.
In the layer three header, it also indicates what the layer four protocol is. So it looks, in this case, at
the TCP header at layer four. And in that layer four header it also indicates the TCP port number of
80 that this segment is destined to. And because the web server is listening on port 80, it further deencapsulates, and then receives and processes that HTTP request that Bob has sent.
Now it's also important to note that if Bob's PC is going out to 15 different web servers, Bob's
computer also has to keep all those HTTP sessions straight. And so what Bob does, when he goes
out to web server, he plays a little game from Vegas. It's a roulette wheel.
He spends the roulette wheel, and he picks a number that's generally larger than 1,023. That's an
unused port currently on Bob's computer. Let's say Bob chose 6,783 as an unused port. And what
Bob will do, he will use that as a source port. So in the TCP header it'll show as a source port
coming from 6,783 going to the well-known port of 80 on the server.
And when the server responds back to Bob, it's going to be going from port 80 on the server, back
to port 6,783, which was the source port where Bob initiated the TCP conversation for HTTP with
that server. So here, at the application layer, I've listed the well-known ports and the layer four
protocol that is generally used for these applications.
And for some of these protocols there are exceptions. But by and large, these are the server ports
that I'm listing in this table here in blue. Next, let's say Bob was to go to his bank website, which
need security. Instead of using HTTP, it's very likely that if he tries to using HTTP, the bank is
going to redirect him to HTTPS.
And with HTTPS it uses the well-known port at the server of 443. HTTPS is a secure flavor of
HTTP. Now behind the scenes they use some additional technology, such as secure sockets layer or
transport layer security. But for now, I just want you to be aware that when you see HTTPS, I want
you to think of a secure connection to a web server.

And the well-known port on the server would be 443 if the server is supporting SSL or HTTPS
sessions. Next, at Bob's company, they've got an email server that wants to communicate with other
email servers. And when two email servers get together and they want to communicate they use a
protocol called SMTP.
The Simple Mail Transfer Protocol. And the well-known port is going to be 25 for the SMTP server.
And these first three, by the way, are also using TCP as the transport protocol at layer four. So as the
data gets encapsulated, that layer four into segments, these three protocols would be using TCP,
which by the way is the protocol number 6, that's what TCP is.
And inside that header it would have the port numbers associated with that session, or with that
application. Next, Bob decides to check and see whether or not he has email. So he opens up his
email application. And his email application could to be using a couple of different client protocols
to access Bob's email.
One of them could be POP3 or IMAP. They both use TCP. POP3 uses port 110, and IMAP uses port
143. And that's for a client's interaction with an email server. So email server to server it's port 25
with SMTP. And from a client to an email server it would be POP3 or IMAP. So on this email
server, if is supporting both POP3 and IMAP, it would have port 110 open and port 143. Next, Bob
decides that he wants to go ahead and remotely connect to this router.
We'll call it router one. And you might ask, why would Bob want to connect to a router. Well, if
Bob's the administrator, Bob would want to get command line access to this router so he can take a
look at the configuration. Maybe change some things, or verify some things.
And one way of getting remote command line access to this router is to use a protocol called Telnet.
So Bob would launch his favorite Telnet application on his computer. And then, behind the scenes,
that Telnet application would be encapsulating the request using TCP as the layer four protocol and
going over to the server to the well known port of 23. So if the router was acting as a Telnet server,
it would be listening and have port 23 open on the router. Because that's the well-known port where
a Telnet request would come into.
Now, after Bob attempts using Telnet, he discovers, hey, they've disabled Telnet on the router. Why
would anybody disable Telnet services for the administrators. And the answer is because Telnet is
plain text. Anybody who's eavesdropping or doing a packet sniffer, or packet analyzer on the
network, they would see all the commands that Bob is issuing over that Telnet session, including
Bob's password.

Which is really, really bad. So in a production network, friends don't let friends use Telnet. Instead,
we use another tool that will give us remote access command line interface to a device, and that's
called SSH. It's the Secure Shell Protocol. And it listens on port 22. That's the well-known port for
So if the router has been configured to support SSH, it will be acting as an SSH server. It will be
listening on port 22, and be able to accept incoming SSH requests from a client. So now the Bob's
using SSH, he's looking at the version of the software running on this router.
And he determines, oh, my goodness, this is running an old version of software. I need to update
this. So what Bob does, is he goes through change control. He get the paperwork involved. He does
all the documentation. He schedules downtime. He communicates that well.
And then during downtime, he copies over the new IOS image over to this router. Now there are
several ways of copying a file across a network. One of them is to use a protocol named FTP. It
stands for File Transfer Protocol. And if this router has been configured to support FTP services, it
will be listening and working with port 21 and 20. Port 21 is for, what's called the control channel,
to give commands and so forth using FTP.
And port 20 is the data port or the well-known port for data, that the router would have open if it
was acting as an FTP server. Now there are some exceptions to that well-known port of 20. But
we'll save that for another day. Now as Bob tried to transfer a file over to the router, he discovered
that there was some filtering going on that wasn't allowing port 20 with FTP. And so he decided,
wow, how else can I transfer this file.
Another option he might be able to use is the Trivial File Transfer Protocol. Which is also insecure.
So FTP, itself, is plain text insecure. And TFTP also is plain text insecure. Meaning somebody
eavesdropping on any of those conversations could clearly see, using a protocol or network analyzer
what's going on between the client and the server.
And TFTP, if we're using that, it's listening on the well-known port of 69. And that is a UDP port.
So actually separated this line here, everything below is UDP only. So below the line TFTP is only
using UDP at layer four, and the well-known port is 69. So Bob uses port 69, copies the file over.
Super happy about it.
Does the upgrade. Documents his work. And then the next morning a user is complaining that they

can't access the internet going through the router. So here's the user. I'll put an exclamation mark
there, because they can't get to the internet, and they're upset about it.
So Bob says, hmm, let me go ahead. And can I have remote control into your computer and take a
look and see what's happening? Now, assuming we had basic network connectivity, that might be
possible. Because Bob and the user are on the same subnet. They aren't going through the router to
get to each other.
So to accomplish that, the protocol that might be used, the application that might be used, is RDP.
Which stands for Remote Desktop Protocol. It uses TCP at layer four. And the well-known port is
3,389. So this user computer would be listening on port 3,389. And in Windows, they would have
enabled the remote desktop functionality.
And then Bob, using an RDP client, could connect to, and have basically a remote control session
for that user to see what exactly is going on, on that computer. And after looking at that computer,
Bob discovers that the computer's missing a couple files. And the files that this computer needs are
located over here on server two.
So I'll just put S2 for server two. Now, I'd like to pause for a moment and ask you what are some
methods that we could use to move files between this server and this computer? And what you
might say is, well, Keith, we could use FTP, if FTP is running. Or we could use TFTP if TFTP is
And those would be two great answers. Because those are both protocols, application layer services,
that allow the movement of files between two devices. So congratulations. I would like, however, to
introduce you to another protocol, it's called SMB, Server Message Block.
It's known by a more common term today, which is CIFS. Which stands for Common Internet File
System. And that's a typical way on a Microsoft network to share files or folders across that
Microsoft network. So if server two was supporting shares and supporting Server Message Block, it
would have port 445 open. And this user could connect to those shares and then move the files over.
Or if Bob is still connected to that PC with remote desktop protocol, because he's right there, he
could go ahead and move the files from the server over to that computer. Now, once the client has
been resolved and they're now a happy user, they want to initiate a phone call from software that is
running on their computer.

And in the world of voice over IP, where we can actually take voice conversations, either from a
physical device or from a program that's running on a computer, and we can call and communicate
with other phones. The technology, when we use that over a network is called VoIP, for voice over
Specifically, IP networking. And to initiate a call over a voice over IP network, there's a protocol
called SIP. It stands for Session Initiation Protocol. And based on the actual function within SIP, it
could be using TCP or UDP. But the well-known ports are 5,060 and 5,061. So the user would be
totally oblivious to that.
They would just run their application. For example, a phone application on their computer. They
would dial a number. And in the background Session Initiation Protocol would go ahead and do the
work for them. Another protocol that's also associated with voice over IP is MGCP.
Which stands for the Media Gateway Control Protocol. It can use TCP or UDP. And it's well known
ports are 2,427 and 2,727. Now once the session has been set up for a voice call, for voice over IP,
it's very likely that the rest of the communication, as far as this user actually talking on the phone
with a party the other end.
With voice over IP, that's very likely it could be carried using RTP. Real Time Transport Protocol.
And the reason he uses UDP, is because UDP has less overhead at layer four then the connection
oriented reliable acknowledging TCP. So it's like a one-two punch.
We'll use SIP with TCP to initiate and set up the call. And then UDP to carry the actual payload for
the actual call itself. And it will import your 5,004 and 5,005. Hah, Hah. However that one is all
over the board as far as what ports will really be used in a production implementation using RTP.
But as a default, they do you have 5,004 and 5,005 as registered well-known ports for RTP. Now
after that voice over IP call, after the user hangs up, he decides to go ahead and use an application
where you can have video and audio with another party. So he opens up that new application.
He connects. And an application that uses audio and video is likely using some flavor of H.323.
Which uses TCP and UDP. And the well-known port of is 1,720. So when you see H.323, think of
an audio video conversation. Not just voice over IP, but audio and video that's being used together.
And in the early days of networking, when Microsoft was just getting into the game, they had
something that was called NetBIOS, that they used heavily. And NetBIOS has a boatload of

services and ports involved. And NetBIOS is more of an access method. And NetBIOS leverages
both TCP and UDP.
And the well-known ports are 137 through 139 for NetBIOS applications. So it's very possible that
this user to be made aware of some services on server two that were available on a Common
Internet File System, CIFS with the SMB, because of NetBIOS being implemented in the network
to make those services available.
And then this user, right here, has been so busy. They look down on the clock on their computer,
and say, wow, it's almost lunch time. And I know my clock is accurate, because it automatically
synchronizes. And one of the methods that a clock on a computer can automatically synchronize is
using Network Time Protocol.
And the well-known port is UDP, port 123. So out on the internet, we may have a very reliable NTP
server. And our routers could synchronize to that. Our users could synchronize to that. So that we
have accurate time on our devices in our network. If we go back to Bob's computer, as well as this
user, when they first booted up, it's very likely that they got an IP address courtesy of Dynamic Host
Configuration Protocol, DHCP.
DHCP is based on UDP at layer four. And the two well-known ports are UDP 67 and 68. And the
port number 67 is the well-known port that a DHCP server will be listening on. And port 68 is the
port that a client, who's discovering and trying to get an IP address, will use when it makes the
And then, as Bob's PC, or this happy user right here goes out to the internet, they are using names
for virtually everything. Like www.acme.com. Or www.cbtnuggets.com. And in the background we
have DNS that's resolving all those requests into IP addresses.
And DNS is a well-known port of 53. So if this server out here is a DNS server, as well, it will be
listening on UDP port 53. Now when I say listening, just because a port is open and listening
doesn't necessarily mean that the services is running behind it.
However, normally, if we implement a DNS server, it will automatically open up and be paying
attention to be listening on that UDP port 53 in the case of DNS. And then at the end of a fairly long
day, Bob says, you know what, uhh, there's just so much going on in my network, I wish there was
some way to keep track of all the devices, And one method of keeping track of our devices is using

The Simple Network Management Protocol, which uses UDP ports 161 and 162. And with Simple
Network Management Protocol we can configure our network devices to automatically send what's
called a trap message to Bob's computer, which is acting as a management station for SNMP, if
there are issues that come up with that device.
Also with SNMP, Bob can periodically poll each of the devices to ask them how they're doing, and
what's going on with their resource utilization. And just like with many of these protocols, there's
various flavors and versions of these protocols. And one of the things I'd like to point out regarding
SNMP, is that we do not want to use Version 1. We do not want to use Version 2. We only want to
use Version 3, or some flavor of Version 3. And the reason that we'd want to use SNMP Version 3, is
that it supports encryption.
So anybody eavesdropping with a packet analyzer on our network, they won't be able to see our
passwords and communications and the details of what's happening. And also it supports
authentication. So we can make sure our devices will only correctly respond and work with an
authenticated SNMP manager.
So that prevents a hacker for just making requests and get responses back from devices in our
network. And we'll have some further discussions on SNMP Version 3. But I wanted to point out
that's the only flavor that we'd want to use, because it includes the authentication and the
Now you may be saying to yourself holy schnikers. There's a lot of information here I need to
remember. And that is true. There's no doubt there's quite a bit information here. So let me share
with you a tip. An action item that I absolutely want you to do, and that is this.
I would like you to get some index cards and write out on the front those cards the acronym for the
service. For example, HTTP would go on one card. And HTTPS would go another card. And SMTP,
and so forth. And on the front of card you have those acronyms. On the back you would write the
protocol that they use, primarily.
If it's just TCP, put TCP, as well as the well-known ports for those protocols. Or if it's just one wellknown port, like HTTP, put that well-known port. And then work through them. Go through a few
flashcards during lunch. And that, my friend, will help you to remember the well-known ports, and
the transport protocol that's used for those application layer services.

And as you go through the stack, if there some that you know, just cold every single time, remove
those from the stack. So it's going to get smaller and smaller as you whittle down to those that you
haven't quite memorize yet. And before you know it, you'll have all of them committed to memory.
And you'll be ready for whatever they might throw your way, regarding asking you the port or
protocol number associated with an application layer service. I've had a great time in this Nugget.
I'm glad you joined me for it. I hope this has been informative for you.
Packet/Network Analyzer
In this Nugget, we'll take a look at how a packet / network analyzer can help us look at the nitty
gritty details for the traffic on our networks. Let's begin. One of the really cool tools that we're
going to want to have in our utility belt is something called a packet analyzer, sometimes called a
network analyzer.
And with a tool like this, we can collect the information and the data from the network, and then we
can analyze it with software that's called a protocol analyzer. And there's a lot of different ways to
collect this data. We can put something, for example, in line with the connection a router has going
to the switch and pull it from there, or we could train this switch to replicate the information that's
being sent in or out on a port and send it out on another port.
For example, maybe Computer 2 is being used to collect all the data, and we train Switch 2 to take
all the data that goes in or out on this port and then copy it or replicate it over to that port where the
PC is. And then on the PC, after we collect all that data, we can use the protocol analyzer to look at
the details of the application layer data, the segments, the packets, the frames for that traffic that
was going in and out of the switch.
Now, this tool can be used for lots of things. Number one, it can be used for monitoring. Maybe
we're troubleshooting a problem, and we want to look at the nitty gritty of the protocols that are
being used as they go across the network. Or an attacker-- if he got a hold of this information, he
could use it to maybe eavesdrop on clear text protocols, like FTP, Telnet, and HTTP to hopefully
discover usernames and passwords that are being used with those insecure protocols.
But I thought what you and I would do is we could use this tool called a packet / network analyzer
to collect some data and reinforce what we've already learned. For example, if we capture the data
on the network, we could probably see DHCP traffic, which is used to dynamically assign an IP
address for a client.

We can see ARP, Address Resolution Protocol, as a device is looking for the Layer 2 MAC address
for the device on that same network. We can see domain name system at work, where a client is
trying to resolve a name into an IP address, we can see HTTP, and a boatload more.
So here's what we're going to do. I'm going to go ahead and put the network tap in place to collect
the data. And what I want to do together is take Computer 2 on this network. And currently, this
computer has an IP address that's statically configured. It's using with a 16-bit mask. I've
also taken the opportunity to disable that interface for just a moment.
Because what I want to do with you is-- let's go back to Computer 2. We'll change it to be a DHCP
client. And then with the packet capture running, we'll go ahead and enable the interface. We'll go
out to a website, and we should be able to capture all of this traffic and see what it looks like under
the microscope of a protocol analyzer.
So I've got the protocol analyzer running in the background. It's collecting the data off of the
network. And this is the interface for PC Number 2, the network interface card. So I'll right click.
We'll go to Properties of this network interface card. And let's change it from being a statically
configured IP address, and let's change it to DHCP.
So we'll click the button that says DHCP. Well, at least it should say. It should say be a DHCP
client, because that's would obtain an IP address automatically really means. We'll also tell it to go
ahead and obtain a DNS server automatically via DHCP as well.
And we'll click on OK. We'll click on Close. And let's go ahead and bring up the interface. We'll
right click, and we'll select Enable from the drop down menu. Now, in the background, DHCP is
happening, or should be happening. So this device can get an IP address.
And now let's open up a browser. We'll just go ahead and double click on the icon for Google
Chrome. There's the default homepage for Google. Let's also go out to www.cbtnuggets.com.
There's the CBT Nuggets homepage. The protocol analyzer I happen to be using for this
demonstration is a free one.
It's called Wireshark. And if you have further interest in Wireshark, you might want to check out the
CCNA Hands On Labs, as well as we have a whole course just on Wireshark right here at CBT
Nuggets. And we have 3,229 packets, for lack of a better term, that have been captured.
And I say for lack of a better term, because we have not only the Layer 3 information, but we also

have the Layer 4 information and the application layer information all captured as part of this
protocol analyzer. So if we wanted to go to the very top, we can use this icon right here to go to the
very top.
And I'm going to use a filter so we can zoom in on specific types of traffic. Let's go ahead and start
with boot P. Now, boot P is a funny way of spelling DHCP. There's a long story behind it. You might
want to think of boot P as the grandfather to today's DHCP.
So here in packet 16, we have a DHCP discover. In packet 17, we have an offer from the DHCP
server. Packet 18, we have a request from the client saying, yep, looks great. I'll take it. And then we
have the final A, the acknowledgment from the DHCP server that it's going back to the client.
So that's in this capture. What else is here? Well, let's search for any ARP request that may have
been made. So we'll put ARP in our filter. And here in Packet 20, we have an ARP request. And if
we look at the details for that ARP request, this source MAC address is the MAC address of our PC
Number 2, and the destination of this ARP request is a Layer 2 broadcast. And that's because our PC
does not yet know the Layer 2 address, and that's why it's issuing out the ARP broadcast to ask for
that information.
And fortunately, here in 43, we have the response. And this response is coming from our Cisco
router. And in the response, the sender, the router, is indicating what his Layer 2 address is so that
PC 2 could know what that Layer 2 addresses is, put it in its ARP cache, and then use it any time it
needs to send a frame over to its default gateway.
And based on this IP address that's associated with that of, I know this response is coming
from the default gateway, R1. Next, let's do a search for DNS. There certainly ought to be some
DNS requests that have happened. Here in entry 133, we have a request coming from,
which is PC Number 2's IP address that it got via DHCP, and the destination is, which is the
IP address of its DNS server, which it also learned via DHCP.
And in this specific request, it's asking-- it says PC Number 2-- I'm asking for the resolution of
apis.google.com. I want to know the IP address associated with that. And right here in the protocol
analyzer, it's telling us that the response is in entry 138 right here.
And before we go to that response, I'd like you to notice at Layer 4, take a look at the protocol being
used. For this DNS request, it's using at Layer 4 User Datagram Protocol, UDP. And the destination
port is the well known port of 53. And then here in entry 138, we have the response, the answer to
that DNS request.

If we wanted to do a search for HTTP, we could find that as well. So here in entry 776, if we take a
look at the transport layer, layer four, it's using TCP. And in the Layer 4 TCP header, it's indicating
it's destined for Port 80, the well known port for HTTP.
And if we wanted to look for SSL, which would also be representing any type of HTTPS traffic,
we're going to find that as well. And if we just grab one of these-- for example, we'll grab 902-- SSL
and HTTPS use the well known server port of 443. And we can see that here as we expand the
Layer 4 information in this protocol analyzer looking at the traffic.
So by using a packet / network analyzer, like Wireshark, we can get into the nitty gritty of the traffic
that's going across our network and verify something such as the ARP request, the DNS requests,
the well known ports that are in use by DNS and HTTP and SSL.
And many protocol analyzers also have the ability to identify trends and specific talkers on the
network. For example, if we want to find the top talkers on the network based on the information
that we captured on the network, we can and Statistics, and go to Conversations, and click that from
the drop down menu, and it's going to show us the conversations in place.
For example, we could take a look at IPv4, or TCP, or UDP. And if we wanted to sort based on the
number of bytes, for example, we could just click on Bytes to sort by that column, and it's going to
show us right here that for UDP, the top talker was, which is the IP address of PC 2,
going to, which is a Layer 3 broadcast address for the 10.1 network. And we could do
the same thing for TCP.
We'll click on the TCP tab, we'll go to Bytes, we'll sort by the Bytes column. And the most data
sent-- during our capture, anyway-- was between and Whatever server
that is out on the internet, this conversation that we have highlighted used the most amount of bytes
during that capture period.
And it would also give us the ability to create graphs and charts based on this information. So for
example, if we use one the Graph buttons down below in the bottom-- here's a graph A to B, which
is showing traffic from address A to address B. It can represent that information in a graph format as
In this Nugget, we've taken a look at using a packet / network analyzer, such as Wireshark, to look
at the details of the traffic on our networks. I appreciate you joining me for this Nugget. I hope this

has been informative for you, and I'd like to thank you for viewing.
Hammer Game
In this Nugget, you and I get to play the network version of the hammer game. When I was younger,
I used to really love the midway games. For example, at the county fair. They had the ring toss. And
I was really, really good at if they could guess your age because I looked like I was 12 when I was
16. So I could always win that one.
But one of those typical games that we'd see is the hammer game, where you pay your money, and
then you swing and-- boom!-- try to hit the target so hard that the little thing goes up high enough.
And hopefully, if it hits the bell, then you're a big winner.
Or if you don't hit the bell, at least you can visually see how close you got. And what I would like to
do is I'd like to play the network version of the hammer game with you, right now. It's a boatload of
fun. And here's how the game is played. We're going to trace the traffic as it's going from Computer
1. And specifically, we'll help Computer 1 make a DNS request. Now, a DNS request could be
generated from us using a browser, at Computer 1, while we're going out to www.cbtnuggets.com.
And in the background, the DNS request would be resolving that friendly name of cbtnuggets.com
over to an IP address. And if our DNS server happens to be out here, on the internet, at,
which is one of Google's DNS servers, that DNS traffic would have to be switched through the
switches, routed through the routers and firewalls, until it finally reached the DNS server, who
would then, hopefully, respond back to us and reply back with the IP address of cbtnuggets.com.
So this would be our path. Computer 1 is connected to Switch 1. It would then go down this port, to
Switch 2, and then out to the default gateway, over to the firewall, over to Router 2. Then Router 2
would route it to the service provider. Also, just be aware that we are running Network Address
Translation-- specifically, the PAT flavor, Port Address Translation-- on Router 2. That's translating
our source IP address of 10.1 into a global routable address for the internet.
And then the service provider is routing over the internet, along with a lot of other internet routers,
to the final destination of And what I thought would be fun to do is, for each device that is
going across the path, I'd like us to ask the question, what is the highest layer of de-encapsulation
that we need to do, or the device needs to do, on that traffic, in order to process it correctly? So we
could equate that to, how hard is this little thing gonna be hit, and how high does our puck need to
go, to represent the de-encapsulation that's about to take place? So when the DNS request is made,
by Computer 1, and it goes into the switch, my question is, starting at Switch Number 1, how far
up, in the protocol stack, does a switch need to de-encapsulate, to look at the information, in order

for the switch to make a forwarding decision? That's effectively what this question is.
How deep into that data does the switch need to go? And if you're saying, Keith, ah, this is an easy
one-- we learned like way early on, in this course, that a switch is a Layer 2 device. It makes Layer
2 forwarding decisions, based on Layer 2 addresses. So all the switch really has to do is deencapsulate or at least look at Layer 2, to make its forwarding decision. So I would say that Switch
Number 1 has to look no further than Layer 2. Now, one other aspect regarding Layer 2 switches is
that they're often referred to as a transparent switch.
And that is because they do not do any rewriting of the Layer 2 information. For example, they
don't swap out Layer 2 addresses. They simply receive Layer 2 frames, and then forward those
Layer 2 frames, based on if they know where that Layer 2 address is. And then they'll forward it to
the correct report.
Or in the event they don't know where that destination Layer 2 address is, they'll go ahead and flood
it to every other port that's associated with that same VLAN. So then Switch 2 receives it. And the
question, once again, is, how deep or how far into the protocol stack does the switch need to look,
to determine how to forward this frame? And the answer is, once again, Layer 2 is enough because
the Layer 2 header has the Layer 2 MAC address.
And then Switch 2 would make a forwarding decision, based on that Layer 2 destination MAC
address, inside the header, at which point it gets forwarded over to Router 1. Now, the interesting
thing about this frame that's being sent over to Router 1 is that Computer 1-- it already did ARP. So
it knows the Layer 2 address of its default gateway. And Computer 1, specifically, when it
encapsulated at Layer 2, before it set the frame-- it intentionally put the Layer 2 MAC address of
the router as the destination address in that frame.
So the transparent switches-- they made forwarding decisions, based on that Layer 2 information.
And now it's coming into Router Number 1. So now, when Router 1 receives that information, what
is Router 1 going to do with it? How high, in the protocol stack, does the router go, as far as deencapsulation and looking at the information? And we know he goes at least as high as Layer 2
because he's looking at the Layer 2 address of the destination for the frame.
And he says to himself, oh, my goodness, that's me. That is my MAC address. This frame, at Layer
2, has been specifically sent to me. And it absolutely is going to continue reading. It's like a book
that the router doesn't want to put down because there may be something else, really important, just
coming up.

And as a result of the Layer 2 address matching the router's, he continues de-encapsulating and
looks at the Layer 3 information because, after all, he is a Layer 3 router. Now, when he looks at
that Layer 3 IP address, and it says it's, he probably is a little bit depressed-- Router 1 is-because it's not his own IP address.
If the destination Layer 3 address was the router's own IP address, that would cause Router 1 to
continue to de-encapsulate and start looking higher-- for example, looking at the Layer 4
information. But because the destination Layer 3 address isn't the router, he looks at the destination
of, he consults his routing table, and he makes a forwarding decision, based on that Layer 3
So we can say that for Router 1, as high as he goes is Layer 3, from a routing perspective. Now,
when R1 makes that routing decision, it knows, based on its routing table, who the next hop is. And
if the next hop is the firewall, which it is, R1 would re-encapsulate Layer 2 with the new Layer 2
destination address being that of the firewall's.
And if Router 1 didn't have the firewall's Layer 2 address, he could certainly ARP for it because R1
is on the same local network, right here, with the firewall. R1 if needed, would ARP to request the
Layer 2 address of the firewall. And after getting it, he would re-encapsulate this packet with a
Layer 2 header that had the destination Layer 2 address of the firewall.
And then the firewall receives it. Now, for this example, we are going to presume that this is a
Layer 3 firewall, which is a firewall that can also perform routing functions. And you might be
asking, well, Keith, if there's a Layer 3 firewall, what else is there? Well, there also could be a Layer
2 firewall. And we'll touch on that in another Nugget.
So when this firewall receives the frame from Router 1, the destination Layer 2 address is the
firewall's. So he continues to de-encapsulate. As he looks at Layer 3, he sees that the IP address-the destination IP address-- is The firewall says, nuts, that's not me because if it was, I
would continue to de-encapsulate.
However, because the target destination address is not myself, says the firewall, I will go ahead, and
I will route this. That's also presuming that the rules on the firewall are saying, yes, it's OK to
forward that type of traffic. So the firewall is also de-encapsulating and processing that packet at
Layer 3. So then the firewall would re-encapsulate that packet with a new Layer 2 header, which
has the destination Layer 2 address of Router 2. Again, this is presuming that we're on ethernet, all
the way through, up to this point.

Router 2 receives the frame, and the question is, how high up in the protocol stack is R2 going to
process and de-encapsulate this packet? And you're saying, well, Keith, the other routers operated at
Layer 3. It's probably going to be Layer 3. You'd be absolutely correct.
So it receives the frame at Layer 2. The destination MAC address is Router 2's because that's the
firewall re-encapsulate it with. And then, as Router 2 de-encapsulates that frame and takes a look at
Layer 3 and sees the destination as, it says, that's not me, consults its routing table, and then
continues to re-encapsulate and then forward that packet in the direction it needs to go.
In this case, it would go out to the service provider. Now, I also want to point out, before we leave
Router 2, that if we are using Port Address Translation-- if that's the case-- the router is also paying
attention to and tracking Layer 4 information. For example, port numbers.
TCP or UDP port numbers, based on the type of Layer 4 protocol we're using. So I'm also going to
add here, for PAT, that would also be Layer 4 because it, indeed, is looking at the TCP and UDP
header information, to determine the port numbers involved. So I can track it, inside of the Network
Address Translation table on Router 2. So now the source IP address has been swapped out from
10.1.-- whatever Computer 1 was to a globally routable IP address.
And that packet is re-encapsulated at Layer 2 and shipped off to the service provider, who continues
to go ahead and route it. So the service provider is also going to do a Layer 3 analysis, as well as
every other router in the path, between the service provider and the DNS server.
And the last stop, here, for this DNS request, is when it finally reaches the Google DNS server, at So at Layer 2, as the server receives that Layer 2 frame, it's going to be encapsulated at
Layer 2 with the server's Layer 2 MAC address, assuming that that last leg of our journey is also on
ethernet, which it very likely is.
And then Router is going to de-encapsulate. And it's going to look at the Layer 3
information and say, hey, this is for That's me. And as a result, the DNS server is going to
continue to de-encapsulate. It's going to look at the Layer 4 information. It's going to see that the
transport protocol being used is UDP because that's what DNS uses.
And specifically, it's going to see that the destination port is Port Number 53, which is the wellknown port for DNS. And because this DNS server has that port open and is ready and listening for
DNS requests, it continues. The DNS server continues to de-encapsulate, to accept that request.

And then it turns around and processes it with an answer. And then the response would be fed back
to the internet, all the way back to Computer Number 1. So we could say that DNS server-- how
high does it go? What's the highest level? We could say the application layer.
And that's where the DNS was-- the DNS service that was running on that DNS server. In this
Nugget, we reviewed the concept that Layer 2 switches make forwarding decisions, based on Layer
2 information. Routers-- Layer 3 routers-- make forwarding decisions, primarily based on Layer 3
information, specifically IP destination addresses.
And a server on the internet, such as a DNS server, who is actively listening to and waiting for DNS
requests, when it receives one, will process that and de-encapsulate that information, all the way up
to the application layer in the TCPP protocol suite, so it can interpret and then respond to that DNS
Using VLANs for Isolation
In this Nugget, we get to discuss and then demonstrate the application of Virtual Local Area
Networks, also known as VLANs. Let's begin. I'd like you to think of the word "isolation." Now as
you considered the word isolation, that really is a double-edged sword.
It could be a great thing. For example, let's say that in some part of the city, there's a whole bunch of
bad stuff happening. If we're isolated from that or removed from that, we can be protected from that
bad stuff that's happening. In that sense, isolation is a terrific thing.
However, on the other side of that coin, if we're with a bunch of friends, and we've gone out to
dinner or to an amusement park or somewhere fun, and we get isolated from the rest of our friends,
that's not so good. In our networks, we also use the technique of isolation for several different
For example, our firewall right here can isolate the outside world from our inside resources. They
can have rules set up on those firewalls to limit the types of traffic that are allowed through that
firewall, thus creating isolation for certain types of traffic.
And inside our company, we can also use the concept of isolation by chopping up our networks into
smaller network segments. For example, currently we have all these devices here on one subnet,
which is Subnet A, which is So if Computer 1, which is connected to Switch 1, wants
to communicate with Computer 2 on Switch 2, they can do so on that Local Area Network, on that

They don't have to send traffic through the router, because they're both on the same logical IP
subnet. It, however, could be bad if we don't want Computer 1 talking to Computer 2. Because
they're not going through a router, we can't use access control lists or filtering devices on the router,
because Computer 1 and Computer 2 don't have to use the router to talk to each other.
Because they are on the same IP network. So if you and I decided that we did want to do additional
separation, additional isolation, we could use a technique called a Virtual Local Area Network, or
VLAN. A Virtual Local Area Network, or a VLAN, is controlled by the Layer 2 switch. For
example, here in this switch, we've got 1,2, 3, 4, 5, 6, 7, 8 ports on this switch, called Switch 2. And
by default, all of the ports on this switch, Switch 2, are all assigned to what's called a default
And that is default VLAN number 1. So effectively, if you and I opened up a brand new switch, got
it out of the box, plugged it in, and started plugging computers and devices into that switch, every
port on that switch is, by default, assigned to the default VLAN number 1. So you can kind of think
of it as all ports on this switch are connected to the same network.
Because Bob, Lois, the Attacker, and anyone else who is connecting to this network would also
need to have a common IP Layer 3 address. So maybe Bob has Lois has The
Attacker's computer got And you might say, well, how did the attacker get an IP
address? Simple-- he plugs in to the switch, he gets an IP address via DHCP just like everybody
So perhaps this port here, which is Port number 2, and this port here, which is Port number 4,
perhaps those ports connect out to cubes where Bob and Lois work, respectively, in each of their
cubes. And maybe Port number 5 here, maybe it goes out to the lobby. So the Attacker in the lobby
took his laptop, took a little cable, plugged it into the jack, and that led to Port number 5 on that
switch. So to create isolation between our users and other ports that we may not want in that same
network, we can implement Virtual Local Area Networks.
And it works like this. Instead of having every single port on the switch be assigned to the default
VLAN number 1, what we could do is we could go ahead and say, we want these specific ports, for
example, ports 2, port number 4, and the printer port, we want to go ahead and assign all those to a
specific VLAN.
Let's say we assign those ports to VLAN number 777. And then we take the other ports that either
aren't in use or are going to other areas of the network or going to other computing devices, and

maybe we assign those-- I'll put those in red here-- maybe we assign those to VLAN 222. So what's
happening here, even though we have one physical switch, we still have two different logical
We have one that's for VLAN 777, and we have another one that's for VLAN 222. And we've just
implemented isolation between our users in specific work groups or in certain areas of the company
and other networking devices. And that VLAN assignment regarding which ports are assigned to
which VLANs happens at the Layer 2 switch. We simply go in and tell each of the ports what
VLAN we want them to be associated with.
So we have two different components that need to work together to make the VLANs work. We
have a Layer 2 switch that's assigning the individual ports to specific VLANs. And that's why a
VLAN is referred to as a Layer 2 broadcast domain. I mean, think about it.
If Bob sent a broadcast, like an ARP request or a DHCP discover message into the network, the
broadcast should be forwarded to all other ports. However, in the case of VLANs, that broadcast
from Bob is only going to be forwarded to the other ports with the same VLAN that Bob is
associated with.
So if Bob is associates with VLAN 777, the switch would only forward the broadcast over to Port 4
and Port 6, because those are the only other two ports that are associated with that same VLAN of
777. So the Attacker and these other ports, because they're not in that same VLAN, would not
receive that broadcast.
You can kind of think of a VLAN as, how far would a broadcast go if sent into this VLAN? And the
answer is, it would only be sent as far as the other ports that are associated with that same VLAN.
So the concept of a VLAN, or the words Layer 2 broadcast domain, those are synonymous.
They mean the same thing. Now, the second part to this is that individuals like Bob and Lois on a
specific VLAN at Layer 2 would also need to agree and have a common Layer 3 address as well. So
Bob is at Lois is at Let's say those are both slash 16s. And their default
gateway, which would also need to be associated with VLAN 777, would be at, perhaps,
with a 16-bit mask. So if Bob or Lois ever needs to route a packet off of their local 10.1 network,
they would forward the frame to their default gateway, and then the router would look at the IP
destination address at Layer 3 and then make a routing decision at Layer 3 based on the IP address.
So that brings me up to another point. If we ever do want to forward a packet, Layer 3, a packet
outside of our local subnet, which is also equivalent to our local VLAN, we need a Layer 3 device

who can forward it between different networks, which would also imply the router is able to
forward a packet between different VLANs that are associated with those different networks.
So in our topology here, I've got Computer 1 that's physically connected to Switch 1. I've got a
Computer 2 that's physically connected to Switch 2. And I've got a connector between Switch 1 and
Switch 2. And by default, all of these ports on Switch number 1 and Switch number 2 are all
associated with VLAN 1. That means that Computer 1 and Computer 2 are associated with the same
Layer 2 broadcast domain, the same VLAN.
And as a result, as long as they have compatible IP addresses, meaning that they're in the same
subnet, they should be able to communicate with each other, as well as with the default gateway
that's at .1. So currently this is the network. So let's have some fun.
Let's go ahead and verify our basic connectivity between Computer 1, Computer 2, and the default
gateway, all on the 10.1 network. And then I'd like to walk you through an example of changing the
configuration. We'll use Switch number 2 as an example. We'll change the port that Computer 2 is
connected to. And we'll assign it to a different VLAN.
And then together, we'll take a look at the results of Computer 2 then being in a different VLAN
because the switch port he's connected to is assigned to a different VLAN. Now, as we prepare to
implement these commands, you might be asking, now, do I need to memorize these commands?
The answer is no, you don't.
Because Network Plus is supposed to be a vendor neutral certification exam for networking. And
the commands are going to vary a little bit based on the vendor you're working with. For our
demonstrate, I am going to be using a Cisco device as a switch. So we're currently sitting at Switch
number 2 in our topology. So here on Switch number 2, I'm going to ask it to show us all of the
VLANs that this switch knows about.
And it says, well, I've got VLAN 1. Its name is Default. And that's a good thing, because it is the,
quote unquote, "default VLAN." And check this out. If we look at the ports assigned to that VLAN,
it shows us that all 16 ports on this specific IOS device, all 16 switch ports are currently associated
and assigned to VLAN number 1. That's the default condition.
And this port right here, FastEthernet 1/2, is the port on this switch that is being used by Computer
2 to connect to that switch. So we're going to focus our attention to Fa 1/2 for our configuration.
Now, there's lots of commands that we could use to look at the details for switch ports.

One command on a Cisco device that I like is the show interface status command, because it gives
me a very quick snapshot of all the ports, their status. So for example, here we have Fa 1/2. Status is
connected. It has the VLAN assignment, which is VLAN 1. It also shows the speed and duplex.
So this switch port is capable of doing 10-megabit Ethernet or 100-megabit Ethernet, which is also
referred to as Fast Ethernet. And the a-full and the a-100 represents that it automatically negotiated
the speed of 100 megabits per second and the duplex of full, meaning that PC 2 connected to that
switch port can send and receive at the same time.
And that's one of the benefits of having a switch. We can now full duplex to send and receive
simultaneously between the switch and any devices connected to a port on that switch, which is also
configured to operate in full duplex. Another command that we could issue is the command show
interface FastEthernet 1/2 switchport. And I'm abbreviating the Fast Ethernet with fa.
And again, that is a vendor-specific command here on a Cisco device. And access port is how a
device, like a printer or a computer, gets access into the network. That's why they call it an access
port. Access ports are associated with a single VLAN. And down here under Access Mode, it says
the access mode is VLAN 1, which is the default VLAN. Another command that we could issue is
show interface fa 1/2. And that's going to show us generic interface information that's not specific,
for example, to Layer 2 switching. So here, for example, it's showing us that we're operating in full
duplex, which is fantastic.
And it's also operating at 100 megabits per second, which is also great. So if this showed us that we
were operating at half duplex or 10 megabits per second, because I know the switch is capable of
this full duplex and 100 megabits per second, I'd very likely go to the PC, in this case Computer 2,
which is connected to that port, and take a look at how it's configured.
Because if we want the full throughput, we'd want the highest speeds that both devices support, the
switch port and the host connected to that switch port, as well as full duplex. Anything less than that
is going to impact our performance. So next, let's go out to PC number 2 and just verify we have
basic connectivity that we can ping our default gateway, which is, and we'll also verify we
can ping Computer number 1. And Computer 1 has the IP address ending in 0.100. And Computer
2, we'll use the IP config to verify what its IP address as well.
So here on PC number 2, let's bring up a command prompt. And we'll use the command IP config.
And there's our IP address, Our default gateway is And let's do a couple
commands just to verify basic connectivity. Let's do a ping over to, which is our default

That looks great. Every ping was responded to. And let's hit the up arrow key, and instead of
pinging .1, let's ping .100, which is PC 1. Now, PC 1 is physically connected to Switch number 1,
but there's a cable connecting switch number 1 to Switch number 2, and all the ports on both
switches are associated with VLAN 1. So logically, we are in the same Layer 2 broadcast domain,
the same VLAN.
And each of our devices also believes that we're on the 10.1 IP network at Layer 3. So we have both
of those things going for us. Let's go ahead and do a ping to .100. And those four pings are also
working. So if we look back at our topology, Computer 2 can ping the default gateway at .1, and
Computer 2 can also ping Computer 1. And Computer 1 is at .100. And Computer 2 is at .101. So
all that connectivity looks great.
And that's because all the ports on both the switches, plus the cable that goes between them,
everything is assigned to VLAN 1, the same Layer 2 broadcast domain, the same Layer 2 VLAN,
and a compatible IP subnet also being run at Layer 3 for all the devices on that VLAN.
So back on Switch 2, which is where Computer 2 is connected, let's go into configuration mode on
this Cisco device, and let's create VLAN 777. And at this point, VLAN 777 is just an idea. The
switch is saying, great, there's this VLAN 777. I know about it.
But by default, there are no access ports assigned to VLAN 777. So even though the VLAN exists,
it's not being used by any ports. Let's also, just for fun, we're going to give this VLAN a name. I'm
going to call it Test-VLAN. And then we'll exit VLAN configuration mode.
So now if we issue a show command to see the VLANs that this switch knows about, it should
show us that, in addition to VLAN 1, it's also got this VLAN called 777. And over here to the right,
it shows that there are no ports currently assigned as access ports in that VLAN.
So once again, it's a VLAN that exists but isn't being really used by any ports. So let's change that.
We're going to go and configure Port 1/2, which is the port that PC 2, or Computer 2, is connected
to. And we're going to assign that port, 1/2, we're going to assign that as an access port in VLAN
777. So we've gone into interface configuration mode, the special compartment, if you will, that
we're going to use to configure the details of this switch port.
And the first command I'm going to use is going to tell this port that it's going to operate and behave

as an access port. So in Cisco land, it's switchport mode access. And poof, this port now knows,
great, I'm an access port. Now in reality, it was before, because that's the default state.
However, a little reminding never hurt anybody. So it's an access port. And also by default, it's an
access port still in VLAN number 1. So in the background, the little port might be chanting, I'm
number 1! I'm in number 1! If we want to move that port to a different VLAN, specifically the
VLAN we just created of 777, we would use the command on a Cisco device, switchport access
vlan, and then the number of that VLAN.
And poof, this port has now just been associated or assigned to VLAN 777. So it's always a good
idea to verify what we think we've configured. So let's do a command to verify the interface status
once again. And here it shows that port Fa 1/2, which is the Fast Ethernet 1/2 interface, shows the
status of connected.
And check it out. It's assigned to VLAN 777. So at this point, I'm reminded of a song. It goes
something like this. (SINGING) All by myself. Don't wanna be all by myself. Because that's the
song that Computer 2 could actually be singing right now, because he is the only device in that
Layer 2 broadcast domain, in that VLAN called 777. And you know that story about what happens
in Vegas stays in Vegas? Well, from a Layer 2 perspective, what happens in a VLAN stays in a
And because computer 2 is in a different VLAN than the router and also a different VLAN than
Computer number 1, basically Computer number 2 doesn't have access to diddly squat. He cannot
reach anything because he is in a separate VLAN at Layer 2 all by himself. And a Layer 2 switch is
not going to forward frames outside of the local VLAN.
So to test this, let's go back to PC 2. We'll use the up arrow key a few times. Let's do a ping of our
default gateway once again. So as we do a ping of, it is not making it. And that's because
the frame, even if ARP had been resolved and cached-- and we can verify that with an arp -a.
And the ARP cache timed out. It may be like 10 minutes on a Windows machine. So it doesn't know
the Layer 2 address of its default gateway. So in the background, this PC very likely did an ARP
request, trying to resolve the Layer 3 address of its default gateway, to the appropriate
Layer 2 address. However, because this client is in VLAN 777 and our router is in a different
VLAN, this switch did not forward this frame outside of VLAN 777. Again, what happens in the
VLAN stays in the VLAN at Layer 2. Now still here in our ARP cache, we have So
that's PC 1's Layer 3 address. We've already resolved the Layer 2 address. Even if we try to ping
that, it is going to be unsuccessful, because we are in VLAN 777, and the Layer 2 switch is not
forwarding our Layer 2 frames outside of VLAN 777. So in this scenario, PC 2 already had the

Layer 2 address. It was encapsulating at Layer 2 with the correct Layer 2 address of PC 1 and
forwarding to the switch. And the switch said, hey, I don't have anybody else by that MAC address
in VLAN 777, because you're (SINGING) all by yourself.
And as a result, it failed. Now, what we could do for fun, and I think this would be a really good
exercise as well, is we could go to this port right here on Switch 2. This happens to be port Fast
Ethernet 1/13 on Switch number 2. And what we could do is we could put this port, which is
connecting to the router interface, and we could also put that into VLAN 777. And if we did so, then
Computer 2 and the interface on the router would be the same VLAN, which is the first step to
And then secondly, they both have an IP address in the 10.1 IP Layer 3 subnet. And generally, a
common IP subnet is used by all the devices in a specific Virtual Local Area Network. So if we had
15 VLANs, we'd also have 15 IP subnets associated, one for each of those VLANs.
So let's make that change as well. We'll go over to Port 1/13 on Switch 2. We'll plunk that also into
VLAN 777. And then we should have better success between Computer 2 reaching its default
gateway once they're in the same VLAN. So here on Switch 2, let's go back into configuration
mode. We'll go into the specifics for interface Fast Ethernet 1/13, which is where our router is
connected. We'll specify it's an access port.
And then we'll tell it that it belongs to VLAN 777. Let's also use the command show interface
status, just to verify. So there's Fa 1/2, which is connecting Computer 2 to the switch. And here's
Port Fa 1/13, which is connecting the router, specifically Router number 1's 3/0 interface to that
same switch.
And now that Computer 2 and its default gateway are both in the same VLAN, let's go back to
Computer 2 and verify we have reachability. So back at Computer 2, let's do a arp -a once again.
And let's go ahead and do a ping of In the background, the ARP was resolved correctly,
because the pings are now successful.
So if we hit the up arrow key and did a arp -a, you'll notice that we now have the ARP resolution for And our pings were also successful. In fact, if we wanted to verify our routing out to the
internet as well, we could use a tracert. I'm going to put a -d for don't bother doing the DNS
resolution for each hop on the way out.
And then I'll go ahead and do that trace out to a Google DNS server, And that should show
us each hop in the path towards that final destination. And we have a successful trace all the way

out to In this Nugget, we've taken a look at the concept of a VLAN and how to associate an
access port on a switch with a specific VLAN.
802.1Q Trunking Concepts
In this Nugget, we'll take a look at how trunk ports on a switch can support multiple VLANs at the
same time, using 802.1Q tags to identify the VLANs that a frame is associated with. Let's begin. I'd
like to share with you an experience that I had many years ago while waiting for a plane at the
While I was there, I noticed that there was a young person. I think they were probably under-maybe they were under seven or eight years of age or around that age. And they we're about to be
sent on this airplane to some other destination. Now the parent or guardian that dropped this child
off didn't just say, good luck.
Hope you make it. They worked with one of the attendants for the flight. And what they did, they
created this tag with all the information regarding that child. And they pinned it to that child's
jacket. And it had details, which I assume were things like the details of regarding who the guardian
is, who the appropriate person that would be receiving them on the other end of the flight, and so
And then the child got on the plane. Now on the plane right there, I imagine that the attendant for
the flight kept a pretty good eye on the child. And then when landing at the final destination, I also
have reason to believe that the attendant on that end took very good care to make sure that that child
was delivered to the appropriate party at the receiving site.
So if we take a look at the entire process, the process involved taking the child and then tagging
them, if you will, for lack of a better term, with their information. Putting them on the plane, and
then when they get off the plane, removing the tag while they deliver that child to the correct party
on the other side.
And you might ask, well, Keith, what does the concept of putting a tag on the child to keep track of
it while it's on an airplane, what does that got to do with networks today? And the answer is, that's
exactly how we keep track of a frame as it crosses between one switch going over to another switch,
if we're using a technique called 802.1Q trunking.
To understand how trunking works in a network, let's take a look at our basic topology here. Up in
the top left hand corner, we have PC 1 which is connected to a switchport. And that switchport I've

colored as red. And that switchport that PC 1 is connected to is port 0/1 on the switch. And that
switchport has been assigned to belong to VLAN 10. And that's on switch number 1. If we take a
look at PC number 3, at the top right hand corner.
PC 3 is connected to port 0/3 on the switch. And port 0/3 on switch 2 has also been assigned to be
an access port for VLAN 10. So PC 1 and PC 3 are both participating as part of the same VLAN, in
this case VLAN 10. And based on what we know about VLANs, what happens in a VLAN, stays in
the VLAN.
So if PC 1 issues a broadcast-- for example, an all points bulletin-- maybe it's doing an ARP request
or a DHCP discover message, something that would use a broadcast address as the Layer 2
destination address, that frame is going to go into switch number 1. And then switch number 1
needs to forward it out all other ports that are associated with VLAN 10. Now a trunk is a special
link, in this example, between two switches that is associated with more than just a single VLAN.
So, specifically, the trunk that's going between switch 1 and switch 2 is associated with both VLAN
10 and VLAN 20. So it has the ability to forward frames for either VLAN 10 or VLAN 20. And
here's the rub. If PC 1 sends a broadcast and it goes into the switch and switch 1 is going to forward
that frame over the trunk to switch number 2, how in the world-- when switch 2 receives this
broadcast-- how is switch 2 going to know if that broadcast is associated with VLAN 10 or VLAN
20? Because switch 2 needs to know. It needs to know should I forward this broadcast out to my
VLAN 10 hosts, that are associated with VLAN 10, or should I forward it out to my host on VLAN
20? And the magic that a trunk is going to use to identify which VLAN a frame belongs to as it
crosses the trunk, is using something called an 802.1Q tag. And this is where the analogy with the
airplane becomes in.
With the airplane, we put a tag on the jacket of the child so that while it was traveling on the
airplane it could be identified. So that on the receiving side, the child could be appropriately handed
off to the right party. Well, the same thing here. If we're using 802.1Q tagging for our trunks, what
happens is switch number 1, before it sends the frame, it's going to add a little tag.
In this case, the tag will say VLAN 10. So in addition to the normal ethernet header, there's also
going to be additional information that adds this little VLAN tag of 10. And the benefit is when
switch 2 receives it , it says, oh, this broadcast frame, in our example, is associated with VLAN 10.
And switch 2 can say, thanks for the information. It removes the tag because it no longer needs it.
And then switch 2 can simply forward that frame out any of the ports on switch 2 which are
associated with VLAN 10. Now the other side of this coin is what if PC 2 sends a broadcast into the
network, as an example? PC 2 is connected to port 0/2 which is associated with VLAN 20. And if

it's a broadcast, the switch says, oh, I need to forward that out all other ports that are associated with
VLAN 20, which is going to include our trunk.
So our trunk is associated with VLAN 10 and VLAN 20. So as that frame is being sent over the
trunk to switch 2, switch 1 is once again going to tag that frame. This time it'll tag it with a blue tag.
More specifically, it'll be a tag that says this frame belongs to VLAN 20. And that way when switch
2 receives it it'll say, OK, I got the tag information.
I realize this broadcast is coming from VLAN 20. So it removes that tag. It was only needed as it
crossed the trunk. And then switch 2 would forward that broadcast out of all of its ports that are
associated with VLAN 20. In this case, we have one PC, PC 4, that's connected to port 0/4, on the
switch, which is assigned as an access port on VLAN 20. So a trunk is a Layer 2 connection
between two devices that supports multiple VLANs.
And industry standard protocol on ethernet for supporting trunks is called 802.1Q. And 802.1Q
operates by adding additional information, including something called a tag, that identifies what
VLAN a frame belongs to. And that's for the benefit of the receiving switch who needs to know
what VLAN a frame belongs to.
Now regarding our Shakespeare question, too tag or not to tag? That is the question. On a trunk,
virtually all transit traffic going over the trunk-- when I talk about transit traffic I'm talking about
user traffic, like going from PC 1 to PC 3, and so forth.
Virtually all that traffic will receive tags as it crosses the trunk to indicate is it for VLAN 10 or is it
for VLAN 20? However, there is one exception. And that is referred to as the native VLAN. And
here's how the native VLAN works. The native VLAN is treated special.
If these two switches have set up and agree that VLAN 33, just as an example, that VLAN 33 is the
native VLAN, it's like a common understanding between the two switches that if there is transit
traffic-- for example, from a user that's on PC 6 who's associated with VLAN 33-- and it's
forwarding a frame that needs to go over the trunk.
If that frame is associated with VLAN 33 and if that is the native VLAN, don't bother adding the
802.1Q header. Don't bother adding that 802.1Q tag. And so what that means on the receiving
switch, if we receive a frame and it has no tag, the receiving switch will assume, hey, this must be
for the native VLAN of 33. And it will continue processing it as if it belonged to VLAN 33. So
tagging would be done the majority of the time.

And the exception would be if we have traffic that's associated with what's referred to as the native
VLAN in a Cisco environment. And while we're on the topic of not tagging, I also want to point out
that the switch-- when it's ever sending traffic out to devices that are connected on access ports-- it's
also not going to include any type of an 802.1Q tag. I mean, what would PC 3 do if it's off frame,
and it's de-encapsulating it, and it saw that there was an 802.1Q header, an 802.1Q tag as part of that
frame? What would it do? And the answer is, who knows? It is very likely that a PC, or a printer, or
some other end device has no idea of how to process or handle an 802.1Q tag. So the frames that are
going out to clients on access ports, they are also going to be untagged.
So if we looked at the little summary of what's happening here, it's sort of like the wax on, wax off
with Karate Kid. PC 1 sends the frame into the switch. The switch, if it needs to forward it over the
trunk, is going to tag it just for that trip. The receiving switch is going to say, thank you, remove the
tag, and then forward the frame, as appropriate, to its other ports that are also associated with that
respective VLAN.
And the 802.1Q tag is only used if we're sending information over an 802.1Q port to another
device, who hopefully is able to understand and process that frame, for example, a receiving switch
at the other end of that truck. So I thought what would be fun to look at, is if we got a Wireshark
capture of the traffic as it's coming across the trunk.
So in this scenario, PC 1 has sent a frame into the network. It's coming in on VLAN 10. The switch
is forwarding it over the trunk. It's tagged it as VLAN 10. So here in the ethernet header, it has the
source Mac address. It's a Layer 2 address. That would be of PC 1. It's got the destination Layer 2
address, and that would be of PC 3. And if you'll notice in the ethernet header, it's also indicating
the next protocol in the stack.
And so it has the next protocol as 802.1Q VLAN. And the protocol number is 8,100. So instead of a
protocol stack, each of the headers indicates what's next. So 8,100 in hexadecimal, is the number for
802.1Q, so now we have the 802.1Q information. And what I want to really focus on is this guy
right here.
This 802.1Q header includes the details that this frame is associated with VLAN 10. And that way
when switch 2 receives it, it can process it and associate that frame with VLAN number 10. And
then at the end of this 802.1Q information it points to the next protocol in the protocol stack, which
is 800 in hexadecimal, which is IP version 4. So then in the IP header, which would be next, it has
the source and destination Layer 3 address. And then beyond that it would have the payload,
whether it's ICMP, or TCP, or UDP, or what have you.

So this 802.1Q part gets added by switch 1 before sending it over the trunk. And this 802.1Q part
gets processed and removed by the receiving switch before that frame is forwarded on to its final
destination. In this Nugget, we've identified that trunk ports, in this case between switches, can
support multiple VLANs.
Implementing Trunking
In this Nugget, you and I get to reinforce the concept of trunking by demonstrating how a switch
port can become a trunk by being configured to support 802.1Q tagging and support multiple
VLANs. Let's begin. In our Nugget on trunking concepts, we discovered what a trunk does and its
ability to tag traffic for the various VLANs as that traffic is sent over a trunk.
So in this Nugget, what I thought would be a lot of fun is to go ahead and demonstrate an
implementation of trunks between switches. And in our example, we are going to use Cisco
switches because they are a very popular implementation of switches that support trunking.
And if you're on a different vendor's gear the syntax may be slightly different based on that vendor.
So again, our purpose is to focus on the concept of trunking and not get too wound up in the actual
syntax that's specific to a vendor. In our topology, we have switch 1 and switch 2, and switch 1 and
switch 2 are actually connected with two physical cables between the two.
And the connections are on switch 1, going from its port 1/11, it goes over to switch 2 on its port
1/11. And the second cable goes from port 1/12 on switch 1 over to port 1/12 on switch 2. So to
configure the trunking, we'll go to the interfaces on those respective switches and simply configure
them to be layer 2 trunk ports as opposed to layer 2 access ports. And as long as both switches
support trunking and are property configured, we can have functioning trunks between switch 1 and
switch 2. Because trunks can support multiple VLANs by tagging individual frames with the correct
VLAN, for the demonstration, let's have a little bit of fun, and let's create a couple of additional
VLANs just so we can get a feel for the ability of a trunk to go ahead and carry that VLANs traffic.
Because if we had just one VLAN, like VLAN 1 that we we're using for everything, we really
wouldn't need a trunk, we could simply have the links that go between the switches also assigned as
access ports for VLAN 1, and it would be one giant VLAN. Which, by the way, is the default
behavior for all the ports to be assigned as access ports in VLAN number 1. So we're going to start
on switch number 2, and here on switch number 2, let's go into configuration mode.
We'll create VLAN 50. We'll give it the name of sales, and now we have VLAN 50. Just a Layer 2
broadcast domain that if we wanted to, we could also assign access ports to participate as part of
that VLAN. And for grins, let's create one more. We'll call it VLAN 60, and we'll give it the logical

name of engineering.
And the name itself is really just helpful for the humans. It's really VLAN number that defines the
VLAN. So then on this switch, if we want to take a look at what VLANs we do have, we can use
the appropriate show command here on this Cisco device. And it shows us that we have the default
VLAN, VLAN 1. We've got VLAN 50 of sales and 60 of engineering, and we also have the 777 that
we created here on switch 2 in a previous Nugget. So next, we need to configure the ports 1/11 and
1/12 to tell those two interfaces here on switch 2 that they should behave as trunk ports and support
802.1Q trunking. So to do that, we're going to go into interface configuration mode.
And I'm using a range here, and it's simply a little shortcut. Instead of going into each interface and
issuing the same exact commands, I'm simply going into interface range so I can implement the
same commands on both of these interfaces at the same time.
Now on most switches that support trunking, they're going to support 802.1Q as the open standard
for trunking. However, if you're on a switch that supports other trunking protocols besides the
standard 802.1Q, you could potentially use those as well. So to clear the air, I'm going to tell these
two ports that they are going to use 802.1Q as the protocol for trunking, and that's done with this
command here on a Cisco switch.
And if you're curious, what is the old proprietary protocol for Cisco's proprietary trunking? It's
called Inter-Switch Link, or ISL. But because we've told it that we want to use .1Q, that's the
protocol, 802.1Q, that we're going to be using for these trunk ports.
Next I'm going to tell these interfaces to go ahead and be trunks with the command switchport mode
trunk. So there is the ability in a Cisco environment to dynamically negotiate trunking with the
other side. That negotiation doesn't have to be done. We can just tell these interfaces, hey, do
And that's what we just did with the switchport mode trunk command. The native VLAN, we
discussed in the trunking concepts Nugget, is VLAN 1 by default. However, if we want to change
that, we could do that as well. So I'M going to tell this switch that on these two trunk ports that it
should use VLAN 50 as the native VLAN. And that's perfectly fine as long as on the other side,
switch 1, we also tell it to use the same native VLAN.
And that way the two sides are in agreement on what the native VLAN would be. And as a
reminder, any user traffic for VLAN 50, because VLAN 50 is the native VLAN, the switches don't
bother adding an 802.1Q tag for frames associated with the native VLAN. And in the event that the

interfaces had been administratively shut down, I'm going to bring them up, and then I'm going to
exit all the way out of configuration mode.
Our next would be to go to switch number 1, the other switch, and configure those interfaces with
the same parameters. So here on switch number 1, let's go into configuration mode. We'll create
VLAN 50 so it exists. We'll give it a name of sales. Let's also create VLAN 60 here. We'll name it
And if we do a show command to see what VLANs are currently present here on switch number 1,
It says that we've got VLAN 1, VLAN 50, and VLAN 60. You'll notice here on switch number 1 we
don't have a VLAN called VLAN 777. And as a result, switch 1, because it does not have VLAN
777, it won't be willing to carry that traffic over its trunks.
And if it does receive a frame that is tagged with VLAN 777, its going to throw it in the trash.
Because switch 1 would be saying, hey, I don't even have a VLAN 777. I don't need this frame
coming in from the other switch that claims it's from 777. So just for grins here, what we could do if
we wanted to create VLAN 777 on switch 1, we could create it.
And now if we do a show command, it should show that we have VLAN 50, VLAN 60, and VLAN
777. And because it didn't administratively assign a name for VLAN 777, it gave it this name by
default, which is perfectly fine. The key component of the then is the VLAN number.
A rose by any other name is going to smell the same, or however that phrase goes. So now here on
switch number 1, we'll implement the configurations on port 1/11 and 1/12 to implement the
trunking. We'll specify the protocol we want to use, which in our case is going to be 802.1Q. We'll
use the right syntax for Cisco to implement that.
We'll tell these interfaces that we want them to act as a trunk. We'll also specify a nondefault native
VLAN. The default native VLAN is 1. We'll specify a native VLAN of 50. Why? Because that's
what we told switch 2 to use. They need to agree on that. And now that our trunks are in place, they
should be willing to carry VLAN 1 traffic, VLAN 50 traffic, VLAN 60 traffic, VLAN 777 traffic,
because all those VLANs exist on both switches.
And by default, the trunk ports are associated with all VLANs, meaning they're willing to forward
the traffic for all existing VLANs that the switch has. So here on switch 1, if we use the command
to show the details regarding our trunk interfaces, the syntax is show interface trunk.

Up here it's showing us that port Fa1/11 and 1/12 are currently trunking. The native VLAN over
here on the right is VLAN 50, and the protocol that we're using is 802.1Q. And down here at the
bottom, it's representing the VLANs that this switch, switch number 1, is willing to forward over
the trunks, which is VLAN 1, VLAN 50, VLAN 60, and VLAN 777 on both interfaces. In this
Nugget, we've demonstrated how a switch port can be configured as a trunk to support 802.1Q
tagging and support multiple VLANs.
In this Nugget, you and I get to describe the purpose of spanning tree, and we'll also take a look at
observing this behavior and our existing topology. Let's begin. Here's a more detailed view of our
switch configuration as it relates to the computer number 1, computer number 2, and the router
interface. We have switch number 1 here on the top and switch number 2 here on the bottom. In our
last Nugget, we assigned port FA 1/2 and port FA 1/13 both to VLAN 777 as part of a
demonstration of how we could carve out and assign access ports to specific VLANs.
Now, before we get any further in this Nugget, I want to revert these two interfaces, these two
switch ports, back to VLAN 1 so that PC1, PC2, and the router can all communicate and be part of
the same VLAN. So let's do that right now. So here I'm in switch 2. We'll go into configuration
We'll go specifically into interface FA 1-2. That's where PC2 is connected. And we'll say switchport
access VLAN 1 to assign that access port back to VLAN 1, back to its default state. And then we'll
apply that same treatment to interface fast ethernet 1/13, which is where the router 13/0 interface is
So now all of the ports on switch number 2 should now be associated with VLAN 1. And we could
verify that with a command show interface status, just to verify that the VLAN assignment is
VLAN number 1 across the board. And if we look right here, that is exactly the case.
So let's do a little refresher on how Layer 2 switches operate. That would apply to switch number 1
and switch number 2. These switches, every time they receive a frame that comes in, they look at
the source MAC address and then they memorize it. They say to themselves, OK.
The source MAC address of PC1, that lives off of port FA 1/1, so switch number 1. And switch
number 2-- when it sees a frame come in from PC2, which is on this port FA 1/2, it looks at the
source MAC address that came in, and says, oh, that MAC address, based on the source address I
just saw, can be reached out my FA 1/2 interface. So that's how the switches are memorizing and
learning the MAC addresses.

And they need to know where those Layer 2 addresses live so they can make forwarding decisions
based on Layer 2. MAC addresses on ethernet are 12 hexadecimal characters in length, which
equates to 48 bits. But for the purpose of our demonstration, let's say the PC1's MAC address was
AA, and let's say PC2's MAC address was BB. And furthermore, let's say that router 1's ethernet 3/0
interface was CC.
So from switch 1's perspective, it would think, oh, AA lives off of this interface right here, FA 1/1.
But how about switch 2? Where would switch 2 think that that MAC address lived? And, here's the
secret. If PC1 was sending a frame and the source address was AA, if that frame was forwarded
down to PC2 or to R1, from switch number 2's perspective, that source MAC address is now
coming in on either FA 1/11 or FA 1/12, depending on which of those links switch 1 sent the frame
down to switch 2. So switch 2 is going to have memorized that, oh, to reach the AA MAC address,
it's associated with-- let's say, for example, that it came down FA 1/11. So switch number 2 would
say, oh, to reach the MAC address of AA, I would go ahead and forward it out FA 1/11. One of the
core concepts of Layer 2 switching is to filter-- meaning don't forward a frame where it doesn't need
to go.
So, for example, if PC2 is sending the frame to the Layer 2 address of PC1, when switch 2 receives
that frame, it can forward it directly up this link, up here to switch number 1, and it does not need to
forward that over to the router or anyone else, because it knows exactly where that MAC address is.
So it's making a forwarding decision to the correct destination, and it's filtering it by not forwarding
it on all of the unneeded ports. So a switch that's educated and knows where a MAC address is is
only go forward on ports where it knows that address can be reached.
So the forwarding processes forwarding it where it needs to go, and the filtering process would be
not sending it where it knows it doesn't need to go. Now, what about this scenario? Let's say that
PC1 just booted up. It doesn't know anything about other people's Layer 2 addresses, and so it
doesn't ARP request.
So let's say PC1 is doing an ARP request to learn the Layer 2 address of this default gateway. Well,
that destination is going to be a broadcast. The broadcast in binary is 48 1's. It's an all-points
bulletin. Now, when the switch receives a broadcast, it is not going to know where that Layer 2
destination lives, because no device is ever going to source a frame from the broadcast address.
So effectively, the switch, to err on the side of caution, is going to go ahead and flood. When it
receives a broadcast frame, it's going to flood that frame to every other port within the same VLAN.

And as an example of that, let's just follow the flow of traffic as it's being sent down FA 1/11 on
switch 1. So our broadcast is being sent down to switch number 2. Now, what's switch number 2
going to do when it receives a broadcast? Because the switches do not know where a broadcast
lives, they do what? They forward it on every other port in that same VLAN, which means that
Switch 2 would go ahead and forward it up this port.
It would forward it out to PC2. And it would forward it also out to router 1. So PC2 and router 1-they would receive that broadcast. They would decapsulate it at Layer 2, because there may be
something exciting that they need to see at Layer 3. And as they take a look at the content, if it's not
relevant to them, they'll then say, oh.
This is nothing for me. And they'll simply discard it and go on with their lives. But check this out. If
we sent that broadcast back up on FA 1/12 up to switch 1, what is switch 1 going to do when it
receives a broadcast? Well, it's going to forward it out every other port.
So it'll send it out to PC1, who's now seeing his own broadcast, and it's going to forward it down it's
other port, FA 1/11. And then when switch 2 sees it, it's going to forward the broadcast out of every
other port, which would also include FA 1/12 as it goes back to switch 1. And what we have here is
referred to as a Layer 2 loop. And it is devastating, because that's one of the few opportunities that
our networking gear really gets to be pushed to the upper edge of its limits.
Now unfortunately, as it's doing this looping, it's so busy and consuming so much bandwidth that
the usability, from a user's perspective, usually goes to zero. So the PCs may no longer be able to
reach their default gateway. They may not be able to ping each other successfully all the time,
because the network's just so darn busy with this loop.
And the reality is, if we have parallel paths-- which we do right here, between switch 1 and switch
2. If you have parallel paths at Layer 2, we have the potential for a Layer 2 loop. In fact, the first
broadcast that goes into the network is going to cause a Layer 2 loop. And, to make matters worse,
it's not just going like this in a clockwise fashion.
It's also going like this, in a clockwise fashion if it's being sent down both interfaces and being
received by Switch 2 on both of its interfaces. So we might ask the question-- OK. What is to be
done? Well, one option would be don't put parallel paths in a Layer 2. And for some, that might be
Just have one path between our switches, and that will avoid any parallel paths. We won't have the
potential for a loop. But there's another whole group of people who are going to be upset because

we no longer have fault tolerance. What if we lose one of these links? If we lose a link and there's
no connectivity at all, then we have a failure in the network.
We have lots of connectivity. And the user, especially PC1, won't be able to reach this default
gateway anymore. So it would be nice to have the multiple connections, the parallel paths at Layer
2 for fault tolerance if we could somehow avoid the loops that a Layer 2 parallel path would bring.
And that, my friend, is where STP, da-da-da-da!, Spanning Tree Protocol comes to the rescue. This
is a Layer 2 mechanism that is going to do two things. It is going to identify if there are parallel
paths in the Layer 2 network. And if there are, it's going to block on one or more ports to make sure
that we do not have a Layer 2 loop. And the process, which is quite detailed, that you'll get to study
as you take a look at ICND1 and other vendor's courses for entry-level networking in their vendorspecific implementations, the basic concept of Spanning Tree is that all of the switches that are
participating in running the Spanning Tree protocol, they are going to have an election, and they're
going to decide amongst themselves who is going to be king.
And let's say for our discussion that switch 1 is going to be the king. Now, they have a special name
in Spanning Tree for this king, and they call him the root-- sometimes referred to as the root bridge
or the root switch. Effectively, think of this as the king of Spanning Tree.
And all of the ports on the king, on this root switch, are going to be in a forwarding state. So FA
1/11 and FA 1/12 and FA 1/1-- those are all going to be actively forwarding traffic. And then we
have the rest of the pack. In this example, switch number 2 is referred to as a non-root switch.
Or, in the traditional sense, it would be called a non-root bridge-- meaning, it's just a servant in the
protocol called Spanning Tree. And here's what happens. The root switch is going to be sending out
little BPDUs, which stands for bridge protocol data units.
And it might be sending those out as often as every two seconds. And you might ask, well, what's
the benefit of the route sending out these be BPDUs every two seconds? And the answer is
downstream switches, like switch number 2, that is not the root. If it receives bridge protocol data
that's coming in on two or more interfaces, switch 2 knows, oh my goodness. I've got two possible
paths to get to the root-- meaning, there is a Layer 2 potential loop in the network. And then what
switch 2 is going to do-- is it's going to decide to make a forwarding decision on one of its ports.
Let's say it's port FA 1/11. And then on the other port, which also was receiving BPDUs, it will go
ahead and put that other port in what's called a blocking state. And that's what this blocking right
here is referring to. It's when Spanning Tree has, on purpose, decided to not forward any traffic--

like, for example, customer's traffic on a specific port because of a loop that would be caused if it
And depending on your flavor of Spanning Tree, they might have different terms for this. For
example, it may be called discarding instead of blocking, but the concept is the same. It's not
forwarding user traffic on that port because it wants to avoid a Layer 2 loop. Now, the original
crispy flavor of Spanning Tree is called 802.1D, as in David. And that was developed decades ago.
And there's been some enhancements since then. One of those enhancements is called 802.1W,
which is the standard for Rapid Spanning Tree. And if you want a funny way of remember that, just
think of Elmer's Fudd. I love "Wapid Spanning Twee." And for me, that's still how I sometimes
keep that straight.
802.1W-- Wapid. "Wapid Spanning Twee." So what I thought would be really fun-- I have this
labbed up currently. And what I thought would be fun is to take a look at Spanning Tree on these
two switches to identify what ports are forwarding for VLAN1 and which ports are blocking.
Because I guarantee you if Spanning Tree is running, which it is, and we have a parallel path, which
we do, Spanning Tree has identified a root switch. It's also identified, on the non-root switch, which
port or ports it's going to be actively blocking to prevent a Layer 2 loop. So here in switch number
1. And again, the syntax of how to issue the various commands based on the router or switch that
you're using-- that's not the important part.
The important part is understanding the concept-- in this case, of what Spanning Tree is doing for
us. So in this example, we're looking at the details for Spanning Tree for VLAN number 1. And
here, in the output, it says, hey, this bridge is the root. So we know right off the bat that switch
number 1 is the king for Spanning Tree regarding VLAN 1. It is the root bridge or the root switch.
And as a result, every single port that's associated with VLAN 1 here on switch number 1 is in a
forwarding state. And we can see that detail right here. So port fast ethernet 1/1, which goes out to
PC number 1 on switch 1-- that's in a forwarding state. And both ports 11 and 12, which go down to
switch 2, those are also here on switch 1 in a forwarding state. So next, let's go ahead and take a
look at switch number 2. And what we should see here on switch number 2 is that it has at least one
port in blocking state due to Spanning Tree.
So here on switch 2, we'll issue the command to look at these Spanning Tree details for VLAN
number 1. And sure enough, down here in the interface details, we have port 1/2, which is going out
to our PC number 2. That's our Windows 8.1 computer. That's in a forwarding state.

Interface 1/11, which is connected up to switch 1 on its 1/11, that's also in a forwarding state. But
check it out. Port number FA 1/12 is in a blocking state. And that's due to Spanning Tree logically
blocking any user traffic for VLAN 1 from ever being sent up FA 1/12. And the specific purpose of
doing that is to prevent the Layer 2 loops from occurring inside of our network.
That's the job of Spanning Tree-- identify and stop potential Layer 2 loops. And then on port FA
1/13, which connects out to our router 1 interface, which is interface 3/0 on the router, it's also in
VLAN 1 and it's also in a forwarding state. So, in this Nugget, we've identified some basic
functions of Spanning Tree, which primarily are to identify Layer two parallel paths in a network
and stop it by blocking on one or as many interfaces as are necessary to prevent a Layer 2 loop from
being able to happen. And the stopping of the port from being able to forward user's traffic is
referred to as blocking.
The flooding process is a normal function of a switch if it receives a frame and it doesn't know
exactly where that destination Layer 2 address lives in that VLAN. It will flood it out every other
port. Or, in the case where the switch does know where the Layer 2 address is or which port to
forward it out of, it will go ahead and forward it out of just the port it knows it should go out of, and
it will filter it from bothering other devices in that same VLAN from having to go ahead and receive
and process that frame.
And from the perspective of Spanning Tree, a switch port that is not in a blocking state, or a
discarding state, is in a forwarding state. I'm glad you joined me for this Nugget. I had a great time.
I hope this has been informative for you. And I'd like to thank you for viewing.
Switch Management Concepts
In this Nugget, we're going to focus on the concepts regarding a managed switch. In the next several
Nuggets following this one, we'll walk through some specific examples of implementing these
managed switch features. I'd like you to imagine that you and I are putting this network together for
the very first time.
So we get our physical components. For example, we grab a switch out of the box. It's brand new.
It's got that whole new smell to it. So we pull it out, we set it on the workbench, and then we do our
initial config on it. One of the typical practices when working with a new switch is to have a base
set of parameters, mostly for security and management, that we're going to apply to this switch.
So we might have a template or a baseline configuration that we're going to apply to our switches.
And one of the challenges that we might face is, OK, how do we start configuring a switch that's

brand new out of the box? How do we connect to it? And the first way we're going to connect to the
switch is using a console port, a physical port on the switch that we're going to plug in a console
cable to get access to that switch.
So I thought I would bring us in for a close up view. This is a Cisco Catalyst 2960 switch, and over
here off the left, I didn't put the whole graphic in, but it has 48 ports where we could plug computers
like computer 1, or the printer, or the access point into this switch.
We have 48 ports to play with, and in addition, we have some additional ports here that we can use
for cross connects. For example, there's an adapter that goes in here, and then we could go ahead
and use that to connect, for example, between two switches, or maybe we want to connect to a
switch that's on the fourth floor down to the data center, which is in the basement.
So on this switch, these four ports with the correct adapter would allow us to connect, and they can
support copper cabling as well as fiber. We'll get more into the details of different types of
connectors and cables in a separate Nugget. And our purpose is I they wanted to point out this bad
boy right here.
This is the console port for the switch. So as you and I pull this switch out of box, we would get a
console cable and plug it into this port right here, which is referred to as the console port, and then
we would use the vendor's console cable to connect from our computer over to this console port.
Now, a couple decades ago, every computer had a really old serial port, and back in the day, a serial
port was either a 9 pin serial port or a 25 pin serial port. Most of the serial ports, it was referred to
as RS 232. That was the standard for that type of a serial interface.
As technology improved, the nine pin serial port was more commonly found on computers. Now, if
you look at a computer that was manufactured in the last 5 or 10 years, it's very likely not going to
have a serial RS 232 9 pin serial port, which could be a problem if you have a console cable that at
one end has this type of a connector and at the other end has a DB 9 pin connector. So you might
ask, well, what is to be done? How do we configure this new switch? Well, we have a couple of
We could get a really old computer with a DB 9 RS 232 serial port, or more likely, we just get an
adapter that converts from one of our USB ports, which is also a serial interface, then adapts the
USB serial over to the DB 9, and then the path would be this.

We'd connect from our computer to the adapter, from the adapter to the DB 9 connector, and from
the DB 9 connector to this console port. And then on our computers, we'd run what's called a
terminal emulation program. It's basically a command line interface that gives us basic access to the
belly of the beast, the basic operating system and functionality on this switch.
Now, besides this larger port, we also have a smaller USB flavor, and the type of physical interface
for the console port is going to depend a little bit on the vendor and the model of hardware that
you're currently connecting to. Now, the fact that this switch has these types of connections, for
example, a console port, where it allows you and I to connect to and configure and manage the
switch, that implies that it is a managed switch.
A managed switch has the ability for us to change parameters, change settings on that switch. Also,
a managed switch has the ability for us to remotely connect using TCP/IP over to manage that
switch as well. And the question might come up, well, if this is a managed switch that has a console
port and allows us to change the configuration, what does an unmanaged switch look like? The
answer is it's just a switch, very low end, very simple, that has no console port.
It has no way to remotely connect to it. You simply plug it in, you plug the devices into that switch,
and you're going to use it in its default configuration because an unmanaged switch has no ability to
change the configuration. And the question may come up, if we are connected to the console port,
what does it look like? Well, on a Cisco switch, it's going to give us this command line interface,
something like this, and then from there, we would have to the appropriate vendor's commands to
configure and work with and look at the details on that device.
And for the specifics regarding those vendors, we have separate courses. The cool thing here in
Network Plus is you can leave the driving to me because the actual syntax regarding the
configuration for these devices is not part of Network Plus. The concepts of how they work and
how they operate, those are critical, but the actual driving and the syntax and what commands to use
in a specific vendor's platform-- Cisco, Juniper, Checkpoint, et cetera-- CompTIA's Network Plus is
not expecting you to have those commands memorized.
Next, I'd like you imagine with me that we've placed this switch in the network. So maybe it's on
the fifth floor in the wiring closet, we've got the physical cables in place going out to the various
devices on that floor, and then we discover, oh no, we forgot to change one or two parameters.
We need to make a change. Now, one of the challenges is we don't want to have to walk up to the
fifth floor, go in the wiring closet, that bring our computer, get the console cable, plug it in just to
make a couple of changes. Wouldn't it be great if we were sitting, for example, here a computer two
or maybe somewhere else in the network, wouldn't it be great if we could remotely connect to and

manage that switch remotely? And the answer is absolutely yes.

That would be handy. However, the problem is by default, a switch is a layer 2 device. It's just
making layer 2 forwarding decisions. It doesn't have an IP address to connect to, so even if we
wanted to initiate a remote connection to it, we have no target, no IP address.
So to resolve that, what we could do is we could create a brand new interface. In Cisco, it's
sometimes referred to as a Switched Virtual Interface, also called a VLAN interface. Now, from our
previous Nuggets together, you know that a VLAN is a layer 2 broadcast domain. It's a grouping of
devices that all live in that same area.
And on a switch, we may have VLAN 1, for example, which is the default VLAN that all ports are
assigned to. We may have VLAN 777 if we created that VLAN, and we could also assign ports to
that VLAN as well, and other VLANs that we wanted to create for isolation of our network devices.
And I'd like you to imagine that your switch has a great ability to forward frames in any of these
VLANs. And again, what happens in the VLAN at layer 2 stays in the VLAN. The layer 2 switch is
not moving frames from one VLAN to another. That's the job of a router to route packets between
various VLANs and their various IP subnets, but the layer 2 switch's job is just to forward frames
within a single VLAN.
Sometimes I think the switch maybe feels a little bit left out. Gosh darn it. I'm forwarding frames all
day long for everybody. Why can't I have an IP address in this VLAN and play as well? And the
answer is we can. We can create this additional logical interface.
It's not physically anywhere. You could search the whole box. You wouldn't see a physical interface
called a VLAN interface, but we can create one. So for example, if this switch has two VLANs,
VLAN 1 and VLAN 777, we can create two VLAN interfaces, one logical interface that would live,
if you will, or play with VLAN 1, and another VLAN interface that could live in and play with
VLAN 777, and these would be logical layer 3 interfaces. And the whole benefit of having a layer 3
address in one or both of those VLANs is the ability to communicate with this switch and manage
this switch by you and I, the administrators.
The users are never going to need to connect to an IP address on the switch, but you and I,
absolutely yes. And what we could do if we didn't want to have a separate layer 3 interface for each
VLAN, maybe we just pick VLAN 1, we create a logical layer 3 interface so we can give it an IP
address, and here's my question.

On switch 1, which currently is supporting all these customers that are in subnet A, which is the network, what would be an appropriate IP address to assign the switch 1's VLAN 1
interface if we were going to go ahead and assign an IP address to the switch? I'd like you to think
about that for a moment.
What's a valid IP address on subnet A? And I'll give you a moment to think about that. [HUMMING
"JEOPARDY" THEME"] OK. Jeopardy music is over. And if you said, Keith, I've got this. I've
been through the 16 Nuggets in the IPv4 Subnetting course. If network A is the 10.1/16 network, we
could have 10.1 virtually any other IP address in that subnet.
Now, we know .1 is already taken up by the router so we don't want to duplicate that IP address
because that's a problem. We need to have unique IP addresses, so we wouldn't want to double up
on that .1 host address, but maybe we take, and that's the IP address that we assign to
this VLAN interface number 1 on switch number 1. And then if we need to manage it, we could
connect to that IP address which has been assigned to that switch, and that way, we could connect to
the switch using TCP/IP and using a program like SSH or Telnet and not have to physically walk up
to the fifth floor and plug into the console every time we wanted to manage or configure or look at
the details regarding that switch.
So let's do a quick check. The physical console port is how we initially connect to the switch for
management purposes, but after we configure a VLAN interface, for example, on VLAN 1, we can
connect to that IP address and do management of the switch that way.
And the VLAN interfaces are just logical interfaces. They're hovering, if you will, in the respective
VLAN. If you're looking for a VLAN interface physical port on the switch, you won't find it
because it's not a physical entity. It's a logical layer 3 interface that supports an IP address that's
associated with one of the VLANs on that switch.
Now, one of our other challenges is this. Let's say that you and I happen to be up in the DMZ. So
we have our laptop, we're plugged into that switch, and we're currently on the-- this is network C, so
that's the network. So maybe our computer was assigned an IP address via DHCP, and
while plugged into that port on switch 3, and have the IP address of-- let's say we have
was assigned to us by the DHCP server-- we decide we need to remotely connect to switch number
1 and check one of the parameters or configure a port or a verify a port on the switch.
Is it an access port supporting one VLAN or is it a trunk port that's currently working to support
multiple VLANs across that trunk? So we get out our favorite terminal emulation program. Maybe

it's Putty, which is free, or we have a commercial product like SecureCRT, and both of those give us
the ability to support terminal emulation, and from that application, we connect to, which
is the IP address that we assigned to switch 1. So our packet would be routed through the firewall,
through the router 1, and then it would be forwarded at layer 2 over switch 2 and it would be
delivered to switch number 1. Now, when those incoming requests for, for example, a Telnet session
that we're trying to initialize or SSH, which are both examples of remote administration tools that
we can use to connect to and manage our network devices behind the scenes on the switch, switch 1
is taking those inbound requests and logically processing those on something called a virtual
And there's some history regarding the name. At one point, it was called a virtual teletype, or VTY,
but on most devices, they're simply referred to as VTY lines, which mean Virtual Terminal lines.
And this concept of a virtual terminal, when inbound requests, for example, for Telnet or SSH are
coming in, that concept of VTY lines applies to switches as well as routers.
So for example, if we were going to connect to router two, which is on network D here, and it's at, when we use Telnet or SSH to connect to router two, logically, behind the scenes on router
two, it would be receiving those connections on one or more of our VTY lines on router two.
In the Cisco environment, there's generally zero through four, which is a total of five, VTY lines by
default on many routers, and many switches have zero through 15, which would be 16 VTY lines,
which is a boatload. How many administrators simultaneously do we need logging into a device? If
the answer is I need more than 16, we can go ahead and create on that device additional logical
VTY lines, AKA virtual terminals, to support the needed number of administrators who are trying to
connect to that device.
So if you ever see the concept of virtual terminals or VTY lines, just think of it as the logical
catcher's mitt from baseball that's receiving those incoming Telnet and/or SSH requests for
management from administrators trying to connect to that networking device.
The other thing that we want to be really aware of is, who do we want to allow to log into and
connect to and manage our network devices, in this case, our switch? And hopefully, it's going to be
limited to just the administrators or those who have the authority to go ahead and change the
configuration on those devices.
And to enforce that, it's very likely that we're going to use some type of user authentication, which
means here on the switch, we would want to create at least one user account, and that could be
created locally on the switch, and then we could tell the switch, hey, when people are connecting in
on the VTY lines, the virtual terminals, make sure you ask them who they are and make sure they

have a correct password before you give them access and allow them to start changing things.
So we can create user accounts and the associated passwords on switch 1. However, there is a
problem. Let's say we have a fairly good sized network and there's, let's say, 20 or 30 switches and a
whole bunch of routers. And let's say we create a user account for one of our administrators, Bob,
and let's say we create a user account called superbob and we configure a password as well.
Well, if we configure a username and password on switch number 1, great. One down, a whole
bunch to go because we'd have to go and create that same user account on all the other switches and
all the other routers that we want superbob to be able to manage.
And then, if Bob's password needs to be changed, we'd have to go back to all those devices and
change superbob's password on all those devices. In a medium to large network, that is
unmanageable because we have lots of administrators and we have lots of passwords that are
changing, and it's just too tedious and time consuming to do it manually on each and every device.
So the question may be, Keith, what is to be done? I'm so glad you asked. What we could do instead
of creating local user accounts and the configurations on each and every one of our network devices
that have usernames and passwords, we could use something called AAA.
And if you're thinking, isn't that the Automobile Association of America? That is their acronym,
AAA. However, in a networking and system environment, AAA also refers to the Authentication,
Authorization, and Accounting. Authentication is making sure you understand who a person is.
For example, if you and I went to a bank, how would they authenticate us? They'd probably ask for
some ID. And the bank may do multi-factor authentication where they want us to have, for example,
our bank card, which is something that we have, and also our PIN number, which is something that
we know, and they could use that for the indication.
The most basic form of authentication that a lot of networks use is a username and password, but it
certainly isn't the only way to verify who a user is. So that's the first A of AAA, is finding out and
verifying who the person is. And then secondly, we want to make sure that person is authorized.
Just because the bank knows it's you and I, does that mean they're willing to give us $10 million? At
least for me, the answer is no, they're not. I'm not authorized to get that kind of money via loan or
any other legal method from the bank. And in the network, we could do the same thing.

On switch number 1, we could say, well, Bob's logged in, and is Bob authorized to make this
change or that change? We can control all of that by setting up authorization rules that say yes or no
based on the type of change or modification that Bob is trying to make, and that's the second A in
AAA, authorization.
And the last A is accounting, also referred to as auditing, which is keeping track of what was done.
So the next day when Bob says, I didn't make that change, we could go back to our auditing records
and we could say, well, Bob, based on the accounting records that we have, it shows that you logged
in at this time, that you issued these commands and you saved the config, and then you logged out
five minutes later.
And that's why in our networks, we want to make sure we have really good authentication to verify
that the user really is who they say they are before giving them administrative access regarding
configuring that switch or router. Now, you might be saying, well, Keith, this AAA discussion is
pretty interesting.
However, it doesn't really address the problem of creating separate user accounts on all of our
network devices for superbob. And to solve that, we could use something called a AAA server. AAA
server. And let's say the AAA server is right here on the 10.1 network. Let's say it's at .17. That's its
last octet, .17, 10.1.0/17 with a 16-bit mask. And what we could do on this AAA server is we could
use it as a centralized repository for usernames and passwords, as well as what users are authorized
to do.
So we could create superbob here on this AAA server and then we could just train the switches that
when they do authentication, meaning somebody is trying to connect on one of the virtual terminals
on the logical VTY lines, instead of having to refer to the local configuration on the switch to verify
whether or not it's a valid user, let's go ahead and send a request over to the AAA server that says,
hey, dear Mr. AAA server,
I've got somebody logging in. The name is superbob, the password is blah, blah, blah. Is this
username and password correct? And if the answer is yes, the little message goes back from the
AAA server back to the switch saying, two thumbs up. It's Bob. Yes, yes, yes.
At which point, switch 1 would say, great, I've just authenticated Bob. And then further, once Bob is
authenticated, the switch can also be configured to check with the AAA server regarding any
command that Bob is trying to do. And before processing that command, the switch can check back
with the AAA server and say, is this a valid command that Bob is authorized to do, yes or no? And

if it is, the switch lets Bob implement that command, and if it isn't, the switch says, "Nyah, nyah,
nyah, can't use that command," or something similar to that.
The switch can also use that AAA server as an accounting server to send accounting records
regarding what commands were issued, what changes happened on the system. So that's why it's
called a AAA server. It can do authentication, authorization, and accounting, and as a centralized
user database, we don't have to have user accounts for every single administrator on every single
switch and router.
And while we're on the topic of AAA servers, there's three basic protocols that are used to
communicate between a switch and a AAA server that the switch is using for AAA, and those three
major protocols are RADIUS. It's uppercase and the acronym stands for Remote Authentication
Dial In User Service, but nobody ever says those words.
They just call it RADIUS. That's the protocol that's being used between this switch and the AAA
server. So in that context, the AAA server could be referred to as a RADIUS server, and RADIUS is
an open standard. Another protocol that's popular between a device like a switch and an internal
server is called TACACS+, and TACACS+ is not an open standard.
It is a Cisco proprietary standard. But because so much of the internet and our infrastructures are
running on Cisco devices, it is a very popular protocol for the authentication, authorization, and
accounting of administrators as we connect to, log in, and manage our network devices like a
And the acronym stands for Terminal Access Controller Access-Control System plus, meaning it's
new and improved from the previous version that didn't have the plus following it. So you might
hear people play TACACS or TACACS+. They're talking about the same animal.
It's the Cisco proprietary language of love between a AAA server and a switch that wants to use that
AAA server. And the third protocol, which is a fairly new kid on the block, is called Diameter. And
the reason those crazy kids called it Diameter was because it was supposed to be twice as good as
So if you're a math fan, there you go. There's the math humor for today. But just realize from a AAA
perspective, it's just another AAA protocol that can be used between a device like a switch and a
AAA server for the purpose of authentication, authorization, and accounting.

Another concept I'd like to share with you regarding a managed switch is the networks that we use
to connect to that switch. In this topology, if we give this switch an IP address of, which is
part of this 10.1.0 subnet, and then we sit here at computer two and we're managing this switch, the
management traffic that we're using between our computer and the switch for management
purposes, that management traffic is going over the same exact networks as our user traffic.
So maybe here we have Lois, who's maybe going out to the internet. Maybe she's going to a printer.
And the problem is this. If our management traffic and Lois's traffic are all in VLAN 1, same
subnet, that's referred to as in-band management, which simply means that our management traffic
and our user traffic is coursing through the same exact networks, and in many environments, people
do that.
And you might ask, well, what's the problem with in-band management? And the answer to that
very well could be security. If, for example, at computer two we have superbob, which is our
administrator, and unfortunately, sometimes plain text protocols are used.
They should not be because they're not secure, but maybe superbob is using Telnet to go ahead and
communicate back and forth with the switch. Telnet does not encrypt anything. So if Bob does a
show command or if Bob puts his username and password in, all that traffic back and forth between
Bob and the switch is all unencrypted.
And our mild mannered Lois, although she is supposed to be a typical user, maybe she's got some
hacking skills, and maybe she tricks the switch into forwarding those frames not only to switch 1,
but also over to Lois's computer. And once Lois has those frames, she can use a protocol analyzer or
another attack tool to de-encapsulate the data and take a look at everything that's happening,
including discovering what superbob's password is that he's using to manage the switch.
There are several technical solutions that we could use to solve this problem. Number one, we could
disable the use of Telnet on switch number 1. For example, we could go to these VTY lines, those
logical virtual terminal lines, and we could say no Telnet is allowed, period.
And then, from a technical perspective, we can enforce the switch to not allow inbound Telnet
sessions on the VTY lines, on the virtual terminals. So Bob could use things like Secure Shell,
which does support encryption, to protect the traffic as it goes back and forth between Bob's
computer and the switch.
So SSH is happy, happy because it's secure, and Telnet is not good because it's plain text. Or, if
you're an attacker, Telnet is like, woo hoo, party time. People are sharing their information willy

nilly. I can just look at it. But from a security perspective, we're going to want to use SSH and not
use Telnet.
Another really good idea is to use something called out-of-band management. And with out-of-band
management, we have a separate network, and this could be a separate VLAN that's used just for
the management of our network devices. So in the case of out-of-band management, maybe
superbob is using a VLAN 123 and a separate IP subnet associated with VLAN 123 that connects to
all of the devices for purposes of management.
And Lois's traffic, as she's going to her printer or to her server or out to the internet, maybe Lois's
immediate VLAN is VLAN 17. So VLAN 17 and VLAN 123 are two completely separate layer 2
broadcast domains. They'd have separate IP subnets associated with them, and the out-of-band
management helps give us isolation between the user networks and our management networks.
And if you're saying, Keith, can't we use a router to route between those two subnets? And the
answer is yes, we could use routers to route packets at layer 3 between two different IP subnets
which are associated with two different VLANs, but what we could also do is we could put access
control lists on those router interfaces to control exactly what types of traffic, including source
addresses or destination addresses or layer 4 protocols or both, to control the access regarding the
traffic that's allowed between those VLANs.
And those access lists also could just say no, like Nancy Reagan's policy regarding drugs, which
was the just say no policy. So an access control list also, besides allowing certain protocols, could
just say no altogether to not allow any traffic between two subnets, and that could be enforced
through access control lists on the routers' interfaces.
In this Nugget, we've taken a look at the concepts of switch management, and in the next few
Nuggets, I look forward to walking you through some specific examples of implementing switch
management features. So I'll see you in the next Nugget. Meanwhile, I hope this has been
informative for you and I'd like to thank you for viewing.
Port Bonding (LACP)
What do you call it when two ports strike up a friendship and spend a lot of great quality time
together? The answer may be port bonding. Port bonding is the process to logically combine
multiple links and achieve greater throughput between two devices that are using port bonding.
And in this Nugget, I'd like to discuss the concepts with you and demonstrate it in action. Let's

begin. You know what's a bummer? To me, a bummer is when you have to pay for two of something
but you can only really use one. An example of that are these two ports that are connected between
switch 1 and switch 2. So on switch 1, we paid for port 1/11 and 1/12. And on switch 2, we paid for
port 1/11 and 1/12. It was like a package.
You buy the switch. And each of those ports as a portion of that switch have some cost. And we
have these switch ports connected directly to each other. And we have a separate Nugget on UTP
cabling, which will explain the details regarding the crossover cable that we would use to connect
one switch to another switch.
But here's the rub about having two ports in parallel. In Spanning Tree-- because Spanning Tree is
looking for parallel paths, that layer 2-- and blocking on one of those, one of these switches is
blocking. So let's say, for example, is port F8 1/12 on switch 2. So Spanning Tree has identified a
parallel path and is doing blocking.
So, effectively, as far as forwarding traffic goes, we have one interface in use between these two
switches. And the other one is just sitting there. Now, you might be saying, well, Keith relax a little
bit. Because we have fault tolerance in the network.
For example, if something terrible happens to port F8 1/11 or the cable going between these two
switches, Spanning Tree is intelligent enough to go ahead and say, hey, there's no longer a loop. And
it can start forwarding on F8 1/12. And so it can continue to function.
We'll still have connectivity in the network. And by the way, that concept is true whether or not we
have these as access ports connecting the switches together, or having these configured as trunks, as
we described and demonstrated in previous Nuggets in this course.
The concept of Spanning Tree applies to access ports and trunks. So to overcome the challenge of
Spanning Tree blocking when it sees parallel paths, what we can use is use something called port
bonding. Now, it has several different names depending on the vendor.
It could be called port bonding, or link aggregation. Or in a Cisco environment it's often referred to
as EtherChannel. Those are all referring to the same concept. And that concept is this, it's taking
multiple links-- for example, port F8 1/11 and 1/12-- and making them appear by bundling them
together as one logical link.
And this could apply not just to two links. We could have, for example, four links going between

them. And we could bundle them all together with port bonding or link aggregation and make them
appear as one logical link. So then when Spanning Tree looks at the picture.
And says, hey, I only see one path between the two switches. It will no longer block. And because
all of these four interfaces are working together as part of an EtherChannel bundle, or a link
aggregation group, or a port bonding group, depending on the vendor and which words they're
going to use to describe it, that group of links working together will ensure that they're not going to
send the same frame twice.
And there won't be any loops as a result. Depending on the vendor of the hardware that we're using
and the software that's running on it, there are different methods that we could use to establish this
link aggregation, this port bonding. In a Cisco environment, Cisco's got a proprietary protocol that
lets the switches negotiate the port bonding.
And it's called PAgP. And that acronym that stands for Port Aggregation Protocol. It can use to
negotiate a group of interfaces that will work together to create one logical port, or one logical
EtherChannel as they call it in the Cisco space. Now, the challenge with using proprietary protocols
is that it usually requires a specific vendor, that specific vendor's equipment.
So another protocol that is an open standard that's also use for negotiating and setting up port
bonding is called LACP, which stands for Link Aggregation Control Protocol. And LACP is an open
standard. And if your switch is supported, you can use LACP for these two switches to negotiate
and set up the port bonding, the link aggregation.
And there is yet another option. So besides PAgP, or besides using LACP, we could also just tell the
interfaces that we want them to be part of an EtherChannel-- no discussion. Don't negotiate it. Just
do it. But the concept is the same. We can take two links that-- instead of appearing as separate to
Spanning Tree-- are now participating as one logical interface, or one logical link.
And because we currently have this set up in our environment, I think what we should do is we'll do
a before and after approach. We'll take a look at Spanning Tree. And see where it's currently
blocking. We'll implement port bonding. And then we'll take a look after we implement port
bonding to verify that Spanning Tree is no longer blocking, which means that we now have the
throughput that's capable from both of the interfaces on the switches for throughput between the
It has been scientifically proven that if we want to do a before and after picture, we should probably
do a before picture before making the changes. So here on switch number 1, let's issue the

command show spanning-tree for vlan 1 brief. And that will give us the bird's eye view regarding
Spanning Tree for VLAN 1. And the critical piece I'd like us to look at here for VLAN 1 on switch
1 is that all three interfaces are currently forwarding.
So fast ethernet 1/1 is the interface that goes out to PC number one. And fast ethernet 1/11 and 1/12
are the two interfaces that are going from switch 1 down to switch number 2. And, currently, those
two interfaces-- 11 and 12-- are acting as trunks. Because we configured them as trunks in an earlier
Nugget in this course.
So here on switch one, all the ports associated with VLAN 1 are currently in a forwarding state.
And what that means is, is that as we look at switch 2, switch 2 has got to be blocking on one of
those ports. Because if it didn't, there would be a Layer 2 loop. So let's make a road trip over to
switch number 2. So here on switch number 2, we'll issue the same command to take a look at the
Spanning Tree for VLAN number one.
So port F8 1/2, which is the interface that goes out to PC 2 that's in VLAN1, that's in a forwarding
state. That's great. That's allowing PC number 2 to communicate and participate on VLAN 1. So
that's good that it's in a forwarding state for that access port.
Interface FastEthernet 1/11 is one of the two interfaces that's connecting switch 1 and switch 2
together. And it's forwarding as well. But if we look at the next interface-- which is F8 1/12-- we'll
notice that it currently is in a blocking state from the perspective of Spanning Tree, meaning it is not
forwarding user traffic on this interface between it and switch number 1. And that's a good thing.
Because if it did, we would have loops at layer 2. And one single broadcast would simply loop the
network, and cause a major problem. And this last interface, 1/13, is the interface that's connected
out to router one, who's also participating and connected to VLAN 1. So that, my friend, is the
before picture, before we implement the port bonding.
So to implement the port bonding, let's go back to switch number 1. And here on switch number 1,
we'll go into configuration mode on this device. And we'll configure interface 1/11 and 1/12. I'm
going to use a range command. And that way, I can use the commands for both of those interfaces at
the same time.
It's like a two for one deal. You type in the commands once. And it applies to both those interfaces.
And the command I'm going to use is channel-group 1 mode on. Now, if your device supports it,
you could use, perhaps, link aggregation control protocol, LACP.

Or port aggregation control protocol, that's on a Cisco device. Or was to simply say do it, which
means both these interfaces are now part of one logical interface. And in a Cisco environment, they
refer to that as a port channel. And the port channel they created is Po1 for port channel number
one. Because that's the number that I told it to go ahead and use.
So now we have this one logical interface called port channel number one. And in a Cisco
environment, this would also be referred to as an EtherChannel, which is simply another name for a
group of ports participating together as part of port bonding or link aggregation.
So we'll exit out of configuration mode here. And let's go to the same configuration on the other
side, switch 2. So here on switch 2, we'll go into configuration mode. We'll go into interface range
for the two interfaces that are connecting switch 2 over to switch 1, which are 1/11 and 1/12. And
we'll tell those two interfaces to become part of the same EtherChannel group as well.
And it is done. Now, part of configuring any device is verifying that what we put in place is actually
working. So we'd want to use the appropriate verification commands to see whether or not the
EtherChannel, with quotes around it, in this case is working.
So on a Cisco device, a Cisco switch, we could use the command show EtherChannel summary.
And that is one of the many commands we could use to see the details regarding port bonding. So
this is indicating that we have port channel number one. And these are the two ports-- FastEthernet
1/11 and 1/12-- that are participating as part of this port bonding group.
The next step is to take a look from a Spanning Tree perspective to see how this has changed the
rules. Because we no longer have two individual links between switch 1 and switch 2, instead we
have this one logical EtherChannel bundle. If we do a show Spanning Tree for VLAN 1, check it
out. Because the port channel-- this port bonding group-- appears as one logical interface, it is now
in a forwarding state.
Because Spanning Tree did not see a second and parallel path that it felt it needed to block on
between switch 1 on 1/11 and 1/12 and switch 2 on those same ports due to the port bonding that we
have in place. Another verification tool that we could use is the show interface trunk here in the
Cisco environment.
And that will show us exactly which VLANs are being forwarded across which trunks. And if you'll
notice, port channel one is a trunk. And that's because the two interfaces that we told to become a

port channel were already trunking. Now the port channel itself is a trunk.
And it's forwarding for VLANs 1, 50, 60, and 777. So for grins, if we went up to PC1, and let's say
we tried to ping the internet. So on port 1/13, we have router one that's connected. And then R1 in
its routing table knows how to forward in the direction of the internet-- goes through the firewall,
then through router two, our service provider, to its final destination on the internet.
So if PC1 did a ping to, which is an example of an internet IP address which happens to map
to a Google DNS server, which is out on the internet, the traffic would go in on the switch port. The
switch would forward this down to switch number 2 based on its Mac address forwarding table of
how to reach the Mac address of R1. And it would be sent down one of these two interfaces that are
part of the EtherChannel, or the port bonding, group.
And because we're using 802.1q, that traffic for this journey between here and here would be
tagged. Now, I think we set the native VLAN for 50 on each. So because PC1 is in VLAN 1, and
that's not the native VLAN, that would indeed receive a tag. Switch 2 would receive that frame,
remove the tag. Then it would look at its Mac address forwarding table and realize that the
destination Mac address is out port F8 1/13, and send it over to R1. At which point R1 would deencapsulate, look at the layer 3 IP address, and then make a routing decision, re-encapsulate layer 2,
and send it on its way.
So here at PC1, let's do a ping to We'll press Enter. And sure enough, we have responses
coming back from, which is all the way out on the internet. And our major focus here was to
verify that the port bonding that's happening between switch 1 and switch 2 is working. And since
we have connectivity that, in conjunction with the show commands we did for verification, are a
great indication that the port bonding is indeed working.
In this Nugget we discussed and demonstrated how port bonding can logically combine multiple
links to fool Spanning Tree and achieve greater throughput between two devices that are using port
bonding. We also identified that one mechanism out of several that we can use to negotiate port
bonding is the link aggregation control protocol.
Port Mirroring
Can a switch be taught to take frames that are coming in or out of a port and to copy them over to
another destination for the benefit of protocol analysis or intrusion prevention? The answer is
absolutely, yes, With a concept called port mirroring. Let's begin.

I'd like you to imagine that one of our favorite users, Bob, is sitting at PC 8. And Bob has been
calling the help desk periodically, let's say, a couple times week, indicating that network access
seems slow, or sometimes you can't reach a server. And in our troubleshooting what we did was we
swapped out the ethernet cable, the patch cable, between Port 8 on the switch, and Bob's PC, which
is PC number 8, to see if that would help. And after that change, we waited to see if there's a
difference, and Bob is still complaining periodically that there are issues.
So in our troubleshooting, we also check Bob's PC made sure it had the latest updates, the latest
driver's, the latest patches. And even then, there was no improvement. Meaning Bob was still
calling the help desk periodically with issues that were coming up regarding his network access.
So what do we do? Well, one option is we could take it to the next level and start looking at all of
Bob's data that is either going to Bob's computer or from Bob's computer, and look at that data in a
protocol analyzer. Now, one of the challenges of getting all that data that's either going to or from
Bob's computer right here is that a switch, when it receives a frame-- let's say that PC 8 is talking to
PC 4-- when a frame goes into the switch, and if it's a unicast frame, meaning it's a frame that is
going to a specific destination, it's not a broadcast, but instead is going to the specific Layer 2
destination address of PC 4. The switch is not going to forward that to anybody else except for port
number 4 where that PC is. So how do we get that data over to the administrator's computer so we
can look at it with a protocol analyzer? And one of the options is to use a technique called da, da,
da, da, port mirroring.
Now, it's not always called port mirroring. It depends on the vendor you're working with. In some
environments, it's called switch port analyzer, or span. And on other devices, it's called a monitoring
session. But the concept is that we are going to mirror-- or copy is the word I like to use-- copy the
frames from somewhere in our switch to another, and usually, a nonstandard location.
So here's the situation. You and I get our computer, we plug it into port number one on the switch,
and then we train the switch that we want to take an extra step. And any time it sees traffic going
into this port, port number 8 on the switch, or any time there's traffic that is exiting port number 8,
we want the switch take copies of those frames and copy them over to port number 1, where our
computer's sitting, running protocol analyzer software that's collecting all of those frames.
And the question might come up, well, what if PC 8 is downloading a huge file, or tons of files?
And what we could you do on this computer, we could use a protocol analyzer such as Wireshark.
And we could tell Wireshark that we wanted to collect all of that data and put it into multiple files.
So maybe we tell Wireshark in the set up of Wireshark that we want our file size to be 50 megabytes
in size. And when it gets to that 50 megabyte limit, go ahead and create a new file, which would

also be up to 50 megabytes, and to continue creating new files. In each of those files, all the events,
all the frames of data, and the packets of data, and the segments of data, it would be timestamped so
we know exactly when they happened.
And now, the next time that Bob complains or makes a note that, hey, there seems to be something
not working correctly on the network, we can make a note of that time. And then we can go back to
our Wireshark capture, the protocol analyzer, and take a specific look at the protocols that are being
used, and the packets and the frames to see if there's some kind of corruption or problem with the
protocols themselves.
So using this technique would not be our first approach, but it certainly should be something that we
have in our arsenal that we could leverage if we ever needed to collect data for analysis. Another
cool thing with port mirroring is that it isn't limited to just a port.
For example, on many systems, including Cisco, if we have an entire VLAN, we could say I want to
look at all the VLAN traffic. And we could copy the data that's crossing that VLAN and send it over
to, for example, port number 1. So if we had 20 or 30 devices all connected to that VLAN, we can
collect all those frames and replicate them on port number 1 or port number 2, wherever we send
the data as part of mirroring. So in our topology, if we wanted to see all the traffic is going into and
out of the port that computer 1 is connected to, we could set up port mirroring and train the switch
to send all that data, copies of it all, over to this port where we'd have plugged in our admin
computer, or the computer that's simply running the protocol analyzer that's collecting all of those
frames that are being sent.
Now there's a distinction I'd like to make regarding port mirroring with local verses remote port
mirroring. Local port mirroring is when we're pulling data or frames off of a specific area on a
physical switch and we're sending copies of it to another port on that same physical switch.
So in this example, with switch 1 where the source and destination for that mirroring is on the same
physical switch, that would be an example of local port mirroring, or local mirroring. However,
what if we wanted this admin computer, which is connected to the switch 1, to also receive
information being sent in and out of this port on switch number 2, and have somehow, magically,
that traffic end up over at the same admin port on switch number 1? If we are collecting the data on
a different physical switch, that's referred to as remote mirroring.
And the actual syntax to pull that off is going to vary, not just by vendor, but also by the vendor
specific equipment and version of software you're running on those switches. As you might
imagine, using port mirroring is a handy tool for an administrator, but it could also be devastating if
an attacker could get control of the switch, implement this technology on the switch, for their evil

Because then the attacker could collect and receive frames. And if individuals are using insecure
protocol such as HTTP or Telnet or FTP and they're using their credentials, their usernames and
passwords in conjunction with those clear text protocols, the attacker who now can see all the
frames, would be able then to know what the usernames and passwords are.
And it's a lot like giving the keys to the kingdom over to the attacker, because now the attacker
could log in using those credentials, and have even more access, and do more damage. In this
Nugget, we've discussed the concept of port mirroring, which can be done locally on a switch from
one port to another on the same switch, or remote port mirroring where we're collecting data on the
one switch, and copying or replicating it over to a second switch.
And the benefit of collecting that data is that we can then analyze that data with a protocol analyzer.
Or if the administrator here has some type of an intrusion detection, or intrusion prevention system,
that IDS or IPS can also look at that data to see if there's issues like malicious traffic that's currently
being sent or received on the ports that are being mirrored.
Implementing Switch Management
In this Nugget, you and I are going to walk through some examples of implementing features on a
managed Layer 2 switch. Let's begin. In our previous Nugget on the concepts of switch
management, we learned about some details regarding IP addresses, default gateway, user
configuration, and AAA.
In this Nugget, I'd like to be your cab driver as we take a tour of implementing these technologies
on a switch. And the reason I like the cab analogy is that if you're the passenger in the cabin I'm
driving, it's really up to me. If it's a stick shift, I have to know how to operate the clutch, and the
break, and the gearbox, as we'll get to where we're going.
But you as a passenger can just be familiar with, for example, the general direction of how to get to
a destination, you can see the landmarks as we go by them, but you're not ultimately responsible for
the literal driving of the cab. And I use that analogy because in Network+ you are not going to be
responsible for knowing vendor specific commands.
For example, Cisco, or Juniper, or Checkpoint, or HP regarding their switches and their routers in
implementing the configurations. So in this demonstration, I'd like you to sit back, relax regarding
the syntax, but do be conscious of the concepts of the features that we are implementing on the

managed switch.
Because that's my intention for us in this Nugget, is to reinforce the concepts of a managed switch.
So we're sitting at the console, the command line interface, of switch number 1. And here in switch
number 1 let's teach you a command to see the existing VLANs that exist on this switch, as well as
the ports that are associated with those VLANs.
So here we have VLAN 1, which is the default VLAN, and all of our switch ports by default are
associated with that VLAN. VLAN number 1. And there's a variety of commands that we could
issue based on the vendor and the device we're working with to see the associated VLAN with the
Layer 2 interfaces. So over here on the left, we have all of our Layer 2 switch ports.
We have devices connected to some of them, others there's no device connected, and the VLAN
assignment for all of these ports is number 1. So computer one is actually connected to port fast
ethernet 1 slash 1. At the moment, the printer and the access point are either not connected or
they're turned off.
In ports Fa 1 slash 11 and 1 slash 12, our two interfaces that connect from switch 1 right here all the
way down to switch number 2. And one of the jobs of the switch is to take a look at inbound traffic
as it comes in and look at the source Mac address. And that way the switch in this Mac address table
can memorize, or have learned, which Mac addresses are reachable at which ports.
So for example, computer number one, which is on port Fa 1 slash 1, if it sent any frames into the
switch, the switch in this Mac address table should know what the Mac addresses of computer one;
the switch should know that Mac address is reachable out that port, Fa 1 slash 1; and it should also
know the specific Mac address.
So on the switch, if we wanted to see that information, we could issue the appropriate show
command based on the type of switch we're using to take a look at the Mac address table. And what
this output shows is that switch number 1, this switch, has dynamically learned the Mac address
shown here, and it learned it on this port, Fast Ethernet 1 slash 11, which is one of the two interfaces
that are connecting switch 1 to switch 2. And that Mac address is associated with VLAN number 1.
Now, this Mac address, by the way, is the Mac address of the router interface.
So at some point, router 1 has sent a frame into the network that was forwarded up to switch 1, and
switch 1 saw that coming in on 1 slash 11, saw the source Mac address being this guy right here,
and that's populating the Mac address table on this switch.

Now computer one, even though it's connected here on port 1 slash 1, it looks like we don't have an
entry for that. Now that could be because PC one maybe hasn't sent a frame into the network in
quite a while, and by default, Mac address entries on a switch are timed out if there hasn't been any
new frames seen from that source Mac address.
So what we could do is we could go over to that PC-- this is PC number one-- and we could do a
ping. Let's do a ping of, which is the IP address of our default gateway, and that is actively
forwarding frames through the switch. And if we go back to the switch and we issue that same show
command, it should now show us that it has dynamically learned that Mac address off of Fa 1 slash
1. So this Mac address is the Mac address of PC one that's connected to port 1 slash 1 on switch 1.
And the benefit of the switch learning that is that in the future, if any frames come into the switch
that are destined to this Mac address, switch number 1 can say, oh, I know exactly what to do. I will
forward that out the Fa 1 slash 1 port because I know, says the switch, that's the port I would use to
reach this Mac address.
I'd also like to show you that all of these Layer 2 ports do not have an IP address. They are simply
Layer 2 switch ports. There is no IP address assigned to any of these 16 ports. So here are ports 0
through 15, which are the 16 switch ports on this device, and none of them have an IPv4 address,
which is expected and normal because they are Layer 2 switch ports. But check this out.
At the very bottom, we have this VLAN 1 interface, which is a logical interface on the switch. And
if we assign an IP address, it becomes a logical Layer 3 interface that we can use on this switch for
management purposes. And if we had additional VLANs like VLAN 777 and VLAN 778, we could
additionally create interface VLANs respective for each of those Layer 2 broadcast domains, and
assign them the appropriate IP address from their respective subnets as well.
So here on switch 1, let's go into configuration mode so we can make changes to this switch's
configuration, and if we want to make changes specifically to interface VLAN 1, which is the
logical interface associated with VLAN 1, we would go into interface VLAN 1 configuration mode,
which we've just done. And then we'll give it an IP address, and the syntax we're going use is IP
address,, with a 16-bit mask. And if you've gone through the IPv4 subnetting course,
which I asked you to do as part of our studies for Network+, you realize that the way we implement
a 16-bit mask is by using dotted decimal of And if you need a refresher on any of the
IPv4 or subnetting, please feel free to check out the respective Nugget from the IPv4 subnetting
course to reinforce those skills. Now this interface VLAN 1 may be up or down. I'm going to use a
no shutdown, just to error on the side of caution, to bring that interface up if it had been
administratively down.

And then we can type in exit to exit out of interface configuration for interface VLAN 1 and go
back to global config. So with this IP address now configured on the VLAN 1 interface for switch
number 1, we should be able to ping from the switch over to the router, which is at That
would be a good verification that our IP connectivity on the switch is working.
So let's go for it. We'll do a ping to, cross our fingers and-- yeah! Woo-hoo! The crowd
goes wild. Five out of five. Five successful ping requests and five successful ping replies that came
back. Now the next challenge we have regarding this switch and its IP address is, what if you and I
are sitting here off switch number 3, our IP address is with a 16-bit mask, and we try to
open up an SSH or a Telnet session over to the switch.
Well the switch, which is on the network, when it receives those requests on its VTY lines,
it's virtual terminal lines, if it tries to respond it's going to see that we are on the 10.3 network and
it's on the 10.1 network. And switch 1 is going to use a line from a Beatles song that goes something
like, (SINGING) I get by with a little help from my friends.
And the little help that switch one is referring to is, switch 1 is going to need a default gateway
because switch 1 is on the 10.1 network, and the switch is trying to respond back to us and we're on
a different network. We are not on the local 10.1 network along with switch 1. So the proper way to
have switch 1 use a default gateway is to configure switch 1 with a default gateway and tell it to use in our topology as its default gateway.
This is the same concept as having computer number one or computer number two using a default
gateway. Anytime a device wants to be able to communicate off of its local network, it's going to
use a local default gateway to assist in that process. On this particular flavor of Cisco switch, we're
going to use the command IP default dash gateway, and then the default gateway address of
to configure a default gateway for switch 1 to use. And then we'll go ahead and type in end to get
out completely out of configuration mode.
And one great way you and I cant test to verify that the default gateway is functioning correctly for
switch 1 is to try to ping something that's not local. So for example, over here we have the D
network, which is slash 16. Router 2 interface, 3 slash 1 interface, has a last octet of dot 2.
So R2 is reachable at We could try to ping that from switch 1, should be routed through
the network over to router 2, and if router 2 has a route back to the 10.1 network, router 2 should
respond back through the network back to switch 1. And that would verify that we have reachability
beyond our directly connected 10.1 network that switch 1 is on. So let's try that.
We'll do a ping to, and survey says we have five out of five. And just for grins, if we want
to use a trace route, we can issue a trace route here from the Cisco switch. Now on a Windows

computer, the command is trace RT. On a Cisco router or a Cisco switch, the command is trace
route that you can spell out completely.
So let's do a trace route to, and then it will show us each hop in the path. So our first hop
was our default gateway, so from the switch to the default gateway, which is R1. The next hop was
the firewall interface a dot 100, and then the third hop was the actual router itself at So that
verifies for us the full connectivity between switch 1 and router 2, as well as the individual hops or
routers between switch 1 and router 2. So we can take IP address and default gateway and cross it
off our list.
Next, let's take a look at creating local user accounts and passwords on the switch itself for the
purpose of authentication. Specifically, authenticating an administrator before allowing that
administrator access to the system. So here again on switch 1 we'll go back into configuration
mode, and let's create a local user called superbob.
Bob We'll give him privilege level 15 access, and we'll give him a super secret password of
uppercase N-U-G-G-E-T, exclamation mark, two, three. And in a Cisco environment, privilege level
15 is like King Kong rights on the system. And the reason I call it King Kong rights is because
where does King Kong sit if he's tired? And the answer is, anywhere he wants.
He's King Kong. And in a Cisco environment, if we have an administrator who has privilege level
15 access, what commands can they issue? And the answer is, any commands they want. They're
privilege level 15. They're King Kong. So now that username and password are locally configured
on switch 1. Now, the challenge with having local user accounts on each device is that if we want
that same account on switch 2, on router 1, on switch 3, on router 2, et cetera, we've got to manually
go in and create each of those accounts over and over again.
Or we could use a centralized AAA server where we can create the user account, for example
superbob, one time on the AAA server, and then train a switch to go ahead and use that AAA server
for authentication, authorization, and accounting. And the protocol is the language of love that we
could use between the switch.
And that AAA server could be the open standard RADIUS, which uses UDP at Layer 4. We could
use the Cisco proprietary TACACS+, which uses TCP at Layer 4, or we could use other protocol
such as diameter. All three of those are examples of AAA protocols that can be used to
communicate between a device like a switch and a AAA server.
Part of the blueprint for CompU's Network+ specifies AAA configuration, and it's really tough to do

AAA configuration without doing it on some vendors equipment. I'm going to walk you through a
couple basic steps regarding AAA configuration. And once again, you're not responsible for the
memorization of this configuration, but what you get to remember is that a switch can use a
centralized AAA server and be configured to use it for the authentication, authorization, and
accounting of administrators by configuring the switch to work with that AAA server.
So on a Cisco device, if we want to use a centralized AAA server we're going to use command AAA
space new dash model. And in a Cisco environment, we have a lot of bells, and whistles, and
options that we can configure regarding AAA. Now this command I'm putting in here is simply
saying this-- I want to create a method list-- it's called Method 1-- that I can use for authenticating
logins. So here's the method list called Method 1, and if I use this method list somewhere-- for
example, maybe we apply this method list called Method 1 to a VTY line, a virtual terminal line.
And if we do so, if a user tries to authenticate when connecting through that VTY line-- for
example, coming in through SSH or Telnet-- we're going to attempt, says this switch, to authenticate
that user using one of our configured RADIUS servers. A triple A server that we're using RADIUS
And the reason it says group is we may have several RADIUS servers configured. So the switch
would reach out, connect to one of the configured RADIUS servers, and ask the question, hey,
here's a username called superbob and here's his password. Is it correct? And the reason this is
referred to as a method list is that if switch 1 attempts to reach a RADIUS server and can't-- for
example, maybe we forgot to configure a RADIUS server, the IP address, and the password to reach
that RADIUS server.
Maybe we did not configure that here on switch 1, or maybe there's a network issue. If this method
list is being used and a RADIUS server is not reachable, it will go to the next option in this method
list. So the first option is a RADIUS server. If a RADIUS server is not available, it will then go to
the second method.
The option of local simply tells the switch to try the local configuration on the switch itself. So this
is kind of like a fallback. If you can't reach a RADIUS server for the authentication of a user, go
ahead and use your own configuration. Maybe there's a username and password configured there.
On a good day, if we had configured RADIUS server and it was reachable, it would never have
gotten to local because the RADIUS server would have been reachable and could have told us
whether or not Bob's username and password were correct. Also for this demonstration, on not
configuring a RADIUS server.

So I'm intentionally expecting the RADIUS server to fail, meaning it won't be reachable, and as a
result, it will use the local configuration on this switch. And the good news about our local
configuration is that we just configured superbob as a King Kong user, and we have a password
specified for Bob to use.
And then our last step to make this method list be used, we are going to apply this method list. We
are going to go to our logical VTY lines. And in a Cisco environment, the syntax is line VTY, which
you can think of as virtual terminal line. The first line number and the last line number.
So in this case, I'm going to have 51 virtual terminals available for connecting on this switch, which
is crazy. There's no way we would ever need 51 administrators all at the same time, simultaneously,
have a need for remote access via the VTY lines to this switch.
However, that's just what I told it to do. So you can kind of think of this 0 space 50 as a range. I'm
now in configuration mode for all 51 of those VTY lines, 0 through 50, which is a total of 51. So
now into configuration mode for these virtual terminal lines, I'm going to specify that I want to use
the method list we just created called Method 1 to authenticate any users who are trying to connect.
And when I talk about users who are trying to connect, I'm referring to administrators who are
trying to connect to the IP address on this switch for the purpose of management. And then we can
exit out completely out of configuration mode, and then we can test this.
Now a great way of testing this would be to go over to either, for example, computer one, or
computer two, or even from the router, and we can initiate a Telnet or SSH session over to that
management IP address, the VLAN 1 interface address, on switch 1, which was And what
should happen? As a result of us trying to connect to the VTY lines, it should prompt us for a
We would supply it. It should prompt us for a password. In the background the switch should be
trying to reach a AAA RADIUS server, but because we didn't configure one it's going to fall back to
the local option, and then it should authenticate us using the local configuration on the switch itself.
So the user superbob should be able to log in with the password that we configured for superbob. So
let's try it. Let's make a road trip over to router 1, and from router 1 we are going to initiate a Telnet
session over to It's prompting us for a username.

That's great. We'll put in superbob, we'll press Enter, we'll put in our password, and we are now
connected. And logically, we're connected on one of the VTY lines that switch number 1 has
enabled for remote access. And one of the commands we can issue is who, which is a Cisco
command to see who we're connected as.
And the who command says, yep, we're connected on VTY 0, which is our first of our 51 VTY
lines, the virtual terminal lines. We're logged on as the user superbob, and we're coming in from the
source IP address of, which is the source IP address for this Telnet session that we're using
on R1. So I'm going to type in exit to go ahead and close this session.
If we took the additional steps here on switch 1, which in a production environment we would, and
we identified the IP addresses of our RADIUS servers, as well as the password that our AAA server
is using, then the authentication in the background on switch 1 would have been done using that
AAA server instead of falling back to the local configuration, which is what we just demonstrated.
In this Nugget, we have demonstrated implementing a few of the features of a managed switch,
including configuring an interface VLAN address, specifying a default gateway, increasing the
number of VTY or virtual terminal lines, creating a local user and password for the purposes of
authentication, and setting up basic AAA services on the switch.
WiFi Wireless LAN Concepts
In this Nugget you and I get to discuss several wireless concepts as they relate to wireless local area
networks. Let's begin. I am still blown away by technology. If we think about the layers of the
TCP/IP protocol suite, at layer one-- the very bottom-- we have the physical layer.
And generally we think of cabling, electrical signals, and so forth, but it absolutely-- layer one also
applies to wireless transmissions, as well. And instead of using copper or fiber to transmit those
signals, they use radio frequency. So here in our topology, we have this little device that's connected
to a port on switch one, and it's called an access point-- affectionately referred to as an AP.
And the access point's job is to take signals that are present here on the switch and translate them
into radio frequency. So it's both a transmitter and a receiver. And because of this access point,
computers like computer three here that has a wireless adapter can associate with an access point,
perform authentication-- which we would require in a corporate environment-- and then get access
to the rest of the network.
So once he's connected to the network via the access point, features such as DHCP and ARP and IP

addressing and everything else works the same as it would on a wired ethernet network. And a
wireless card also has a media access control address that's burned into their wireless network card.
So computer one has a layer two address on its network card, computer two does, and so does this
laptop with the wireless adapter-- and so does your smartphone. When you see Wi-Fi I'd like you to
think of wireless local area networks, sometimes called WLANs.
And the group, the IEEE, is the 802.11 and then we're going to fill in the blank right here because
that blank could represent several different wireless standard so we'll talk about here in this Nugget.
Now, you might ask, what does this access point look like? It looks like one of these or one of these
and they have one or more antennas and they may be internal to the access point or they may be
external to the access point.
An access point may have one or it may have multiple antennas, or I suppose that would be
antennae, although that feels weird saying. And in a home environment, we may have a device that
looks something like this. Now, this home based Wi-Fi unit has four antennae.
Some have three, some have two, some have one, some have the antennae integrated so they're not
physically sticking out. But what this home device also has, it has some switch ports so you can
physically connect in your devices at home. It's got a routed interface that we connect to our service
provider network.
It also has built in layer three routing. So in this one home unit, it has layer two switching, layer
three routing, and also at the physical layer, regarding layer one it supports physical connections, it
supports radio frequency, and it also supports network address translation-- specifically, PAT-- on
most home devices doing that network address translation between our private networks at our
home and the public internet.
Now, there's more than one way to deploy an access point. We could deploy it as an extension of
our existing infrastructure. So, for example, like here we have an access point plugged into our
switch and that's extending the network over to, in this example, computer three.
And that would be referred to as infrastructure mode. And regarding infrastructure mode, we don't
have to have this access point just be an extension of, for example, VLAN one. We could also place
this access point in a separate VLAN so that computer three would be in a different VLAN than the
other devices on the ethernet switches.

And then in that separate VLAN we would also want to provide features like DHCP and default
gateways and so forth so that our wireless customers, if they needed to go ahead and route outside
their network, they could use a default gateway, as well. And it's very likely the default gateway
won't be a wireless device, it'll be an infrastructure device that's available somewhere on the wired
Now, besides infrastructure mode there is also a mode called ad hoc. Now, ad hoc sounds like, hey,
let's just throw this together-- and that's exactly what a wireless device can do. So, for example, we
have two PCs-- there's PC one, here's PC two-- and their little wireless adapters are active.
They could actually set up networking directly between them, which is both scary and not
recommended because unless you know exactly who you're connecting to and what services are
available and what they might be able to pull off your computer, an ad hoc network-- because it's
not really managed by any central authority, it's just managed by the people sitting at the
computers-- the end result is it won't be as secure as infrastructure mode, which has been set up
with security in mind.
Or at least, hopefully security was in mind from the initial rollout of the access points in the
corporate network. In most corporate networks they've got more than just one access point because
the signals, the radio frequency signals, they're going to degrade or deteriorate as they go over
distance and through objects.
For example, going through a wall or multiple walls is going to reduce the signal strength on the
other side of that wall as the signal continues. And when we roll out access points, we could roll
them out as autonomous access points, which means that we would-- as an administrator-- connect
each access point and configure it, which in most wireless enterprises that would take too much
work to do.
So instead of using autonomous mode, where each access point has to be individually configured
and managed by an administrator, a company can implement the brains-- and the brains has three
letters, it's WLC, that's eight wireless LAN controller. Now, with a wireless LAN controller we can
associate, for example, AP one-- access point one-- and access point two with this controller, which
basically puts the controller in charge of those access points and then you and I's administrators can
simply connect to the wireless LAN controller and tell it what we want to have happen.
And one of the benefits is it's a one stop shop. We can make our changes on the wireless LAN
controller and the wireless LAN controller can push those changes out to the access points. In
addition, the access points, when they're implemented with a wireless LAN controller, are
considered to be lightweight.

And the reason they're considered to be lightweight when they're working with a wireless LAN
controller is because the controller itself does a whole bunch of decision making. For example, if
this user like Bob right here, when he connects to the access point, instead of the access point
having to do the work of the authentication of Bob-- and by the way, that authentication could be
done through a RADIUS server, and we discussed the concept of RADIUS previously.
Or this access point, if it was autonomous, might have users and their passwords configured here or
might just have a pre-shared key configured on this access point if it was autonomous. However, if
we're working with a wireless LAN controller in lightweight mode, when Bob connects and
associates with an access point, the access point build this logical tunnel, this logical pipe, between
it and the controller, the wireless LAN controller.
And the credentials that Bob puts in, along with the password, the access point in lightweight mode
doesn't have to make any of those authentication decisions. Access point one just sends all that
information, the authentication information, up to the wireless LAN controller and it's up to the
wireless LAN controller to go ahead and talk to a RADIUS server or some other method of
authenticating that user.
And when we have multiple access points and they're working with a wireless LAN controller, we
refer to it as an extended service set. Now, a service set identifier is like the wireless network name
that a user would connect to. You look at the wireless networks that are available and say, oh, I want
to connect to CBT Nuggets.
Then the user would associate with the access point that's broadcasting or advertising that SSID and
after authentication get access to the network through the wireless access point. So with a wireless
LAN controller we can have both these access points behaving and advertising the same SSID.
So if Bob is on the left side of the office and then he goes over to the right side of the office, he'll
still see that same SSID being advertised. And if we've set up our environment correctly with the
wireless LAN controller, Bob can even do roaming. He can actually physically take his computer
and go between these two areas that are being covered by the access points, and when done
correctly, he'll maintain his connectivity the entire time.
One aspect regarding setting up our wireless is also the density. How many devices are we going to
try to support with a single access point? And to determine that, we should probably plan on what is
the capacity of an access point and make sure that we don't have too high of a density of users
requesting the services of that access point.

For example, if we went to a professional football game or a professional basketball game and
they're offering free Wi-Fi the people who have set that up have a boatload of access points to make
sure that based on the average data needs of a user watching that game, the device density won't be
so high or shouldn't be so high that it's overwhelming what an access point can support.
And another benefit of using a centralized wireless LAN controller and having each of these access
points communicate and send all the traffic up to that controller is that the controller can make
really intelligent decisions because it knows exactly what's going on with both of these access
And the protocol lightweight access point protocol, which originally was used with the wireless
LAN controller-- if you're in a Cisco environment, that has been replaced with something called
CAPWAP, which is the language of love that an access point is going to use to communicate and
send information back and forth between the wireless LAN controller that is controlling the access
And if we have a scenario where we have hundreds of users who are getting access through the WiFi, we may not want to put all those users into one VLAN, one layer two broadcast domain, because
there may be just too many people, too many devices, in that VLAN.
So another technique that we can use in conjunction with a wireless LAN controller is called the
VLAN pooling. So even though we might have one SSID advertising a wireless networking of CBT
Nuggets and multiple access points, behind that SSID we can have, for example, 20 different
VLANs and we can just put users in a round robin fashion into those VLANs.
And that way we can maintain and keep the size small of each individual VLAN. Now, what if we
had a few users that were right over here and we didn't want to set up a complete separate access
point for them? How do we get these users to go ahead and use this access point number one? And
one option is to move those users, say hey, move your desks, move closer to the access point.
Or we can also set up something called a bridge, a wireless bridge. So maybe we place the wireless
bridge here. So the bridge itself has the ability to send and receive to the access point and then from
the bridge's perspective, we have more reachability, or further reachability, than the access point
So a wireless bridge could extend the range, if you will, of an access point on a wireless network.

Now, in life it's a common courtesy not to step on other people's toes, and that also holds true in a
Wi-Fi environment. In a radio frequency environment we can't have two devices using the same
exact frequencies, trying to compete for that space.
Or if we try that, we're going to have serious degradation of service. So as we plan out where we're
going to place our APs, maybe this represents the top view of a floor of our building and we have
AP one, two, three, four, and five that we're going to place.
And let's say they're all representing the service set identifier of CBT Nuggets. So that's the wireless
network that customers who want to connect can see as an available network because that SSID is
being broadcast from all the access points. And of course, behind the scenes we've got a wireless
LAN controller that's coordinating the efforts.
Now, I'd like you to imagine that these colors represent different frequencies or different ranges of
frequencies. So let's say yellow is one and pink is 6 and let's say the green is 11. And you'll notice,
based on our placement, that we don't have any overlapping of the same exact frequencies between
two access points.
And that's because if we did, you'd try to use the same exact frequencies by two different access
points, they would both be competing and interfering for that same frequency range. And in the
world of wireless networks in Wi-Fi specifically, we have two frequency categories that we're
dealing with.
We have a 2.4 gigahertz range and also have a five gigahertz range. And I call it a range because it's
not just one frequency inside of those areas. We actually have several groups of frequencies that we
can use. And one of the blessings and challenges of Wi-Fi is that these are unlicensed frequencies,
meaning that multiple companies can use them.
So when you have two companies that are right next to each other, we'd want to take some
precautions to make sure we are not going to be using the same frequencies as our adjacent
neighbor on the other side of a wall. Because even though the wall will cut down a little bit of the
signal, the signal still we present based on where they have their access points placed.
So the question is, if we are going to implement access points, how do we know what frequencies
are currently in use, as well as how close we should place the access points to each other? Because
we want two things to happen-- number one, we want to avoid stepping on the toes of other access
points, not so much because we don't want to hurt them but we don't want them to hurt us.

That's the real reason. And then secondly, as our users connect to our access points and to our
wireless networks, we want to make sure that the roaming works and the coverage works no matter
where they go in our building. So a huge first step in deploying wireless is to do a site survey and
then generating what's known as a heat map.
Now, the heat map is not really showing us hot and cold like it would with an air conditioning
system where we're trying to map out the temperature throughout the space, but with a heat map for
Wi-Fi we're identifying what signals are present, what's their strength, what's their frequency? And
there are lots of tools that we could use to determine that.
Now, some are extremely expensive and others are absolutely free that we could use as part of our
approach for deploying our access points, as well as troubleshooting when an access point isn't
working correctly. So this is my Galaxy Note 4. The funny thing is this is almost the literal size of
my Galaxy Note 4. It's a teeny bit bigger, but it's really close.
In any event, if I go to the home page here under my Tools section, I've got this free app called the
Wi-Fi analyzer. So here in the Wi-Fi analyzer there's lots of tools. For example, I've got a few
wireless networks around me here. One of them is called barker-5g and if I want to find out what
the signal strength is, I can go to that wireless network and it will tell me.
So in a perfect world we'd have zero loss as far as signal. And the reality is, we'll never really have
zero loss if we're using Wi-Fi So up here it has minus 40, minus 50, minus 60, and it's color coded
here. The further the needle goes over to the left, the weaker and worse the signal is.
So if we went and grabbed a different network-- for example, I'm going to grab Barker, as opposed
to baker-5g-- and it has a stronger signal. And if I go down and I search for maybe something that's
not quite as close, here's one that's called NETGEAR91, we'll go and look at that one.
And that signal is very, very weak. Some of the other tools that are available here in the Wi-Fi
analyzer-- I'm going to go and swipe left. Here it's kind of giving me a bird's eye view regarding
various Wi-Fi networks and their signal strength, which is handy.
And I'm going to swipe left again. And then here it's giving me some recommendations regarding
what I might change to have a better signal in the light of what else is currently present. So it's
telling me here that for barker I'm currently on channel 11 and it's saying that channel 14 would be

Now, the challenge for me personally, because I'm in the United States, I have an option with my
gear to use channel 14. So these are all in the 2.4 gigahertz range. The only channels that are nonoverlapping would be channel one, channel six, and channel 11. And what actually happens when
we choose these channels, we're actually using a range of frequencies about 20 megahertz wide in
that 2.4 gigahertz range for each one of these.
So if everybody knew this and everybody chose one, six, 11 as the three non-overlapping channels,
neighbors would stay out of more neighbors ways. And in a corporate environment we can also
avoid using the same frequencies and the same channels as our adjacent tenants that might be on the
other side of a wall as part of a different company.
If we swipe right on this application it's also showing us the various wireless networks, as well as
their signal strengths. And this is here in the 2.4 gigahertz range. And you'll notice it's really, really
busy, which is pretty much the case in any population where a lot of people live or a lot of people
So if we swipe left again here's another view of the wireless networks, their signal strength, and
here's my question-- if we were going to set up a new wireless network right here where this
computer is, would we use channel one, six, or channel 11? Because those are three nonoverlapping channels that we should choose from.
And if you'll notice, some of these are all over the board. It looks like this one here is centered on
channel 10, this one here is channel three. Now, what I really like about going to an amusement
park is I like going when there's very few crowds. And I feel the same way about wireless networks.
See, here in the 2.4 gigahertz range it's very, very, very crowded. However, if we go to the five
gigahertz range it's like crickets. There's not a lot of activity in the 5 gigahertz range, at least close
enough to this wireless tool. And generally speaking, there's a lot more freedom and space that's not
being used in the 5 gigahertz range and the channels in that range, compared to the 2.4 gigahertz
range. So if we were planning, manually, to implement the various channels on our access points in
a corporate environment we'd look at the topology of what we want to cover and then we would do
a site survey, we would test the signals, make a heat map.
And the point here I want to share with you is that here in this 2.4 gigahertz range, look how we're
using the access points. We have coverage overlap-- for example, like 15% to 20%, which is a great
thing to provide roaming services for our customers as they go between the range of one access
point and go to another, assuming you were using a wireless LAN controller to coordinate all of the

And also, the frequency ranges are not in conflict-- they're not competing for the same frequencies.
So this AP, let's say it's AP number one, it's using channel 11 and its neighbors that it overlaps with
are using channel six and channel one. So the blue circles represent channel 11, the yellow circles
represent channel one, and the red or pink circles represent channel six.
And another cool thing about a wireless LAN controller is it can coordinate that on its own. As long
as we have our access points that have the ability to cover the area or the range that they're
supposed to, the wireless LAN controller can reduce, when needed, the power being used for radio
frequency to make an area slightly smaller.
For example, if this access point here and this access point here were both overlapping with each
other because they're both on channel 11, the wireless LAN controller could see that and say, you
know, let me reduce the power by maybe 5% or 10% on those access points.
So we're still covering the areas we need to, but we're not interfering frequency wise between those
two access points. Another thing we want to consider is the antenna type. Not every antenna is the
same. For example, some are referred to as omnidirectional.
They send radio frequencies in all directions. Some access points are configured as a unidirectional.
So if we have, for example, an access point here on this side of the building-- we'll put one right
here-- and we wanted to send and receive signals going this way, we would purchase and use an
access point here that had a unidirectional antenna type that went this way, especially if we didn't
need any coverage on this side.
Or maybe we have another company and we don't want our signals going over that direction, or
maybe this is the parking lot and we like to reduce the amount of Wi-Fi signals that leak out into the
parking lot. So both the antenna type and the antenna placement are important when deploying a
wireless local area network.
Now, many times there are companies that have a need to send a Wi-Fi signal between, for example,
two locations or two points. In fact, just a couple of weeks ago I was at a facility, they've got two
buildings that are separated by a few hundred feet. This is the main building here on the left, here is
the secondary building over here on the right, and all of the gear, including the connection to the
internet is all in the main building.

They've got a few computers and some wireless components here in the second building and they
want to link those together. Now ideally, if we could put a copper or a fiber cable between those
buildings, that would be awesome. But if we want to use Wi-Fi, perhaps we could attach a
unidirectional antenna on the roof or on the side of the building and we could go ahead and have the
two access points signal and communicate the information back and forth.
So this is an example of a unidirectional antenna. It's called a YAGI, and in fact, this one I think is
available on Amazon. So you get your Wi-Fi adapter, you simply plug in this bad boy as an antenna,
and being a unidirectional antenna it's going to focus its sending and receiving in one direction
specifically, which might be a good application depending on how far we have to go to wirelessly
link these two buildings together.
It's also possible we could use a smaller, simpler unidirectional access point on each building
pointing to each other. And based on the distance and any objects in between those two access
points that might degrade the signal, that would also be a possibility, as well.
Some additional cool tricks that we can use with wireless is we can create two different wireless
networks. For example, here we have a sales service set identifier, and that SSID is being broadcast
as part of the access point's wireless network services.
And then we have an engineering down here, and you'll notice we have a single access point. So the
one access point could logically create multiple wireless networks, and then based on which of
those wireless SSIDs a customer connects to, we could then associate them with a specific VLAN.
So users connecting to the wireless engineering network would be associated and connected to
VLAN 20 and users that associate and authenticate with the sales SSID, that wireless network, they
would be associated with the VLAN 10 network. And in larger environments we may have multiple
wireless LAN controllers that are communicating and working with each other to support literally
dozens or hundreds of access points that are part of an infrastructure.
And whether we're playing up in the 5 gigahertz range or the 2.4 gigahertz range, we'd want to
make sure we have appropriate overlap regarding coverage area and not any contention for the same
frequencies between two access points who can see each other's signals.
Because there are lots of different choices in the 802.11 standards that we can use for Wi-Fi, I put
together this table to help simplify and give an overview of what's out there. So it starts off with
these two guys. This is a long, long time ago in a network far away way we had 802.11 a and 802.11
b and these are really, really old technologies 11 was a five gigahertz range 11b was of the 2.4

gigahertz range with the three non-overlapping channels of one, six, and 11 that we should use. So
for example, if we chose channel six, what we're really using is about-- we'll just rough it up a little
bit-- about 20 megahertz wide of a frequency range in that 2.4 gigahertz. So the 20 megahertz
spread on the access point one that's using channel one will not overlap or conflict with a 20
megahertzish spread that access point two is using if it's using channel six, and that would also be
true if it was using channel 11. And here's the maximum data rate per stream.
That's on a great day with a great signal and everything is going well. And then several years after
the original 11a and 11b came out there was 802.11g and it's compatible with 802.11b. Now, the
reality is it's really as good as the slowest client on the network.
So one bad apple can spoil the bunch-- that's also true if you have a mixed environment with mixed
clients. And then a few more years went by and then they came out with 802.11n, as in Nancy, and
that can operate in a 2.4 or 5 gigahertz ranges. And regarding the width of the frequencies that it can
use, it can use a 20 megahertz wide frequency chunk or it can use a 40 megahertz frequency chunk.
And that's why this column over here to the right, the maximum data rate per stream, would be 65 if
we're using a 20 megahertz wide chunk of frequencies or 135ish if we're using a 40 megahertz
chunk. And here's the really great thing with 802.11n-- it can support four of those streams.
So you're saying, Keith, if I use 40 megahertz wide and I use four channels I can get, like, four
times 135 and the answer is theoretically yes. And one of the ways that 802.11n is able to get such
great throughput is because of M-I-M-O, Mimo. It stands for multiple in, multiple out-- multiple
antennas on the wireless access point.
And then I think it was like 2013 they came out with 802.11ac, as in whew, AC, this is cool. It
works in the 5 gigahertz range and as far as the range in megahertz for the channels it's using, it can
use a 20 megahertz, 40 megahertz, 80 megahertz, or 160 megahertz chunk of frequencies. So based
on the chunk of frequencies that's currently being used, it would then be able to support 96 I'm
going to say ish on all of these. For Network Plus you're not going to get the question is it 96 or 98
or 100. So we're not going to be splitting hairs in Network Plus.
Also, I want to point out of these are theoretical maximums, which in English means you're never
really going to get all that. And the maximum data rate per stream is about 100, about 200, about
433, or 866, depending on the width of the frequencies that you're using.
So, for example, if we're using an 80 megahertz wide swath we could get about 433 megabits per
second per stream. Now the cool thing is we also have the ability with 802.11ac of supporting eight
streams. Now, this is if we have the right client equipment, it's a good day, there's not a lot of

So if you're looking for gigabit Wi-Fi, I think if we had three streams times 400-- I'm going to round
it just for easy numbers-- that would be 1.2 gigabits per second of potential throughput if we had
three streams using an 80 megahertz wide swath of frequencies.
So ac supports eight streams compared to 802.11n's four streams. It supports a feature called
downlink multiple user MIMO, which the acronym is MUMIMO. No matter what you do, if you try
to pronounce that it's not going to be good-- MUMIMO. Hey, what are you using? Hey, I'm using
No. We're just going to say we're using 802.11ac that behind the scenes is supporting these really
cool features which make the throughput possible. In this Nugget we've taken a look at several of
the concepts regarding Wi-Fi, which is the 802.11 family of standards that we can use for our
wireless local area networks.
Implementing an AP
In this Nugget, you and I get to walk through the steps of implementing an access point into a
network. I'd like you to imagine that you and I have been asked to implement the access point to
add wireless functionality to our network. So we've gone out. We've purchased the access point.
And we've also done a site survey. And we've identified exactly where we want to place it, so it has
appropriate coverage. We also determined what frequencies we're going to use, what channels we're
going to use, what technology we're going to use for the implementation.
So we've physically put the access point in its place, which is very likely somewhere high like on
the ceiling or on a wall. Now we also need to have a cable. Even though it's a wireless access point,
we do need to have a cable that connects that access point to our switch.
So where that connects-- let's say its port 1/0/23 on this switch. And for our discussion, let's also say
that that is a gigabit port on the switch. Now the access point may or may not also support 1 gig. So
what we could use is auto-negotiation. And auto-negotiation would allow the access point and the
switch to negotiate, for example, 100 megabits per second if that's all the access points can do as
well as full duplex.
So on the switch itself, we'd want to verify that the speed and duplex are set appropriately. And in
our situation, we'd want to manually set that at 100 megabits per second and full duplex, or we can
just make sure that the switch port was set to auto for auto negotiate.

The other thing we want to consider for that port is what VLAN do we want this assigned to. So in a
simple implementation, we could have this be an access port on the switch. And for our discussion,
let's say we're going to put that in VLAN 99. So that's a switch port configuration.
And be aware that if we're going to place this access point in VLAN 99 that users who connect to
and authenticate with this access point are also going to be in VLAN 99. So we very well may want
to have some things such as DHCP servers and default gateways available for all the wireless
customers who are going to end up in VLAN 99. And one more important thing about access points
is that they don't run on vapor.
They actually run on electricity. That's how they generate frequency and send signals. They use
power. Now we have a couple of options for powering an access point. We can buy a little adapter
that we can plug into the wall and then plug that into the access point.
But having that additional transformer isn't very convenient, especially if that access point is on the
ceiling. So another very popular option is use something called P-o-E, which stands for power over
ethernet, meaning over this ethernet cable that's going between the access point and the switch.
Now in order to do power over ethernet, we have to have one of two things going for us. One, we
have to have a switch that is capable of delivering that power over the connection over to the access
point, or we have to have some type of a device to put inline that can automatically just add that
power over the ethernet cable to the access point.
So if we were using an adapter, it would look something like this. We would have a switch port. It
would go to the little power adapter, which itself would have to be plugged in. And then from there,
it goes out to the access point. So this little box, which has to be plugged in, is supplying the power
that the access point is going to be using to run.
And there's two standards for PoE. And they are 802.3af. And there's 802.3at. And if you're
thinking, wait a sec, Keith. I thought the Wi-Fi was like 802.11. And the answer is, it is. But what
we're talking about is completely wired here. The wired connection from the ethernet switch going
over to a device that needs power over that ethernet connection.
And these two standards are a few years apart. The "f" standard, "af," can deliver about 15 watts of
power to a device. And the "at" standard can deliver approximately 25 watts. And I have rounded
those, but that's the ballpark. So if you're purchasing a new device that's expecting to get power

over ethernet, for example like an access point or a network-based camera or an IP telephone, which
you 're all expecting you have power delivered some way, either locally through a transformer or to
receive their power over ethernet, you'd want to make sure that the switch who's delivering that
power over ethernet has the ability to give that device the power it needs.
So if we see just PoE without the plus, that's the "af" standard. And if we see PoE plus, that's
referring to the "at" standard. That has the ability to deliver more power than the older standard.
And what happens when a device connects to a switch that has the ability to deliver power over
ethernet? There's a little negotiation that goes on, so that the correct amount of power can be
And if you have a device like a computer that plugs into a switch, even if the switch supports PoE,
the negotiations, as they say in Star Wars, will be very short. Because a PC doesn't need any power
over ethernet to run. It's got its own power supply. It's plugged into the wall, et cetera.
So once we have the switch all squared away, we also need to make sure that the access point itself,
on its internet connection, has the appropriate speed and duplex to match the switch or least be
compatible with the switch. So if our switch supports 10 megabits, 100 megabits, or 1,000 megabits
per second, and the access point supports 10 or 100, we'd want to make sure that we were either set
up for automatic negotiation of the speed and duplex.
Or on both ends, we could hard code it for 100 megabits per second and full duplex. And then last
but not least, regarding the configuration, we'd want to make sure that the access point wireless side
of the house is all set up, including the SSID and whether or not we want to broadcast that SSID,
the technology that we're going to use-- a/b/g/n/ac, the frequency or the channel or channels that
we're going to be using for wireless.
And regarding security, we'd want to use some flavor of WPA or WPA2. And WPA stands for Wi-Fi
Protected Access. And WPA2 is actually a standard, which is 802.11i as in indigo. So here on switch
one, for this demonstration, I've got the access point attached physically using a cable to port gig
1/0/23. So what we could do is we could go into configuration mode and then go into that interface,
gig 1/0/23. And we can tell this port that we want it to act as an access port, instead of, for example,
being a trunk.
And we can assign this port to be an access port for VLAN 99. So anybody who connects and
associates with this access point is going to be associated with VLAN 99, because that's where the
access point is connecting into the network. So on this switch, if we use the command show
interface status, we can just verify very quickly the details regarding our port.

So there's gig 1/0/23. From the switches perspective, it says there is something connected to it. That
port has been assigned to VLAN 99. And this a-full and a-100 represents that there was automatic
negotiation regarding the speed and duplex. And they negotiated full and 100. And that the switch is
capable of 10, 100, or 1,000 megabits per second, because it's a gigabit port on the switch.
But thankfully, it's willing to negotiate down to a lower speed to be compatible with the device
that's connected to it on that port. Another way of looking at the details for that specific port here on
the Cisco switch is a show interface gig 1/0/23. I wanted to share with you that there's more than
one way on most vendors' products to verify the speed and duplex.
So right here in the output of this interface status for this interface, it is showing us that it is full
duplex and 100 megabits per second. So there's one more thing I wanted to share with you
regarding this switch, which is also the reason they use it for this demo, and that is, it does support
PoE, power over ethernet.
And if we do a show power inline on this specific switch, among other things, it is showing us that
I'm port gig 1/0/23, that we're currently delivering power over ethernet. It is currently delivering
12.2 watts. There's the device name of what we're delivering it to.
That's the access point that's connected on that port. And this switch is indicating that on that port, it
could support a maximum of 30 watts, which is pretty close to the PoE plus standard, the 802.3at of
25-ish watts with a little bit extra for padding. Next let's take a road trip over to the access point to
check the ethernet side of the house with speed and duplex there that's on this guy as well as the
wireless side with the SSID-- the technology we're going to use-- the channel, and security.
This is the Graphical User Interface, the GUI interface, for managing this access point. And
currently, we're looking under Network interfaces, and specifically, under fast ethernet. So
regarding status, it shows that were enabled-- that's a good thing-- and up.
It also shows us that we're running at 100 megabits per second, and we're operating in full duplex.
So if this said it was operating at 10 megabits or half duplex, those are issues I would want to
correct on this access point. And the interface may be slightly different based on the vendor.
And it's the concepts that I want you to take away from this-- that we'd want to make sure we're
getting the full bang for the buck-- our full duplex and the maximum possible speed that's
compatible between the access point and the switch. In this case, 100 megabits per second is all the

access point can do, so I'm OK with that.

And the full duplex implies that we can send and receive simultaneously. We don't have to wait to
take turns for sending or receiving on the network. Next, let's take a look at the wireless interfaces.
Let's go to Radio1, which is 802.11a. And this is a slightly older access point.
In fact, I had to dust this off. I haven't actually touched this access point in quite a while. The last
time I did, I was working on the CCNA Wireless course right here at CBT Nuggets. So if you're
interested in learning a lot of details, with specific towards Cisco, including using a wireless LAN
controller in conjunction with multiple access points, you may want to add CCNA Wireless to your
list of future courses to go through.
So here, for this radio, it's indicating that it is up. That's a great thing. And if we go up here to
Settings, we can go ahead and change some of those parameters if we wanted to. So we'll click on
the Settings tab for the wireless 802.11a radio. And there is just a boatload of nerd knobs-- that's
what I like to call them-- little tweaks that we could make regarding this radio.
Do we want it to act as an access point, or do we want it to act as a repeater, et cetera? However,
you know what? There's another option here. Let's go to Express Set-Up. And here under Express
Set-Up, for this access point, we can specify what we want the IP address to be of the access point.
If we want this access point to be managed via SNMP, Simple Network Management Protocol, we
could specify the community name, which is a fancy way of saying the password. Now the bad
news is, we really do not want to use SNMP unless it supports SNMP version three, which has the
encryption for confidentiality and the authentication to verify that we're only going to communicate
with the right devices.
And then we can specify the role of this access point in the network as well. if we go to Express
Security-- and again the menus may be slightly different based on the type of access point you're
working with-- so if we want to call our wireless network, Bubba, and if we want to broadcast that
SSID, we could put it here.
Now on this access point, regarding the technology we're using, if we go back to network interfaces,
we have an 802.11a radio and an 802.11g radio. And what we do is simply enable the radio for the
technology that we want to use. Now what is the absolute best technology for the 802.11 to use?
And the answer is, it's the one that works the best in your environment.

If all of your clients are older and none of them support 802.11n, you won't get a whole bunch of
mileage out of an 802.11 radio as part of the 802.11 set up, because your clients can't use it. So if
we had determined that we wanted to use 802.11g in this example, we'd want to make sure this guy
is set up for g.
And if we added two or three or four more access points, we'd probably also want to make sure that
they were set up to support g as well if that's the technology that we landed on. And also on this
page is where we could set up the security. And in most environments, we're going to want to use
WPA or WPA2. Now this access point is fairly old.
It's not showing me the WPA2 options. However, on a more current device, we'd have options for
WPA2 Enterprise and WPA2 Personal. And here's the biggest difference. With WPA2 Enterprise-what that represents is that we have a centralized AAA server that the access point, or in the case of
a wireless LAN controller, that that controller can communicate with for the authentication of users.
So we have a RADIUS server that's set up. And when working with a RADIUS server, the RADIUS
server just doesn't answer anybody's questions. Yeah. I'll give you the information if that username
and password is correct. No. In order to work with a RADIUS server, the access point in this case
would also need to know what the password is to use in conjunction with that AAA server or the
RADIUS server.
So in troubleshooting, one of the first things I'd want to do is verify I have the right IP address to
communicate with a RADIUS server. And the second thing, I'd like to verify is that we have the
correct password-- the RADIUS password-- that's already configured up on the RADIUS server so
that we can successfully make those RADIUS AAA requests.
So with WPA2, with a RADIUS server, it's referred to as WPA2 Enterprise as in aye aye captain-Enterprise, Star Trek. Now in some environments, they may still want to use WPA2, but they don't
have a centralized RADIUS server for the authentication of users.
So in that case, we have a WPA2 Personal-- I will spell personal correctly there-- P-E-R-S-O-N-AL-- and with personal, it uses a PSK. And you might be asking, what the heck is a PSK? And PSK is
an acronym that stands for a Pre-Shared Key. You can think of it as a password.
So our end users like Bob and Lois, if we're using WPA2 Personal, their computers would have
been configured to use WPA2. In addition, those computers would also been configured with the
correct pre-shared key that they can use to authenticate with either the access point or the wireless
LAN controller if we're using controllers.

And when our users connect, holy snykers, they could be connecting from almost anything. They
could be connecting from cell phones, or laptops, or tablets, or gaming devices, or media devices.
And each of those devices are going to have a slightly different method for connecting to a wireless
But the basic concept is the same. And that is you select an available SSID-- a wireless network that
you want to associate with-- you provide the credentials, whether it's a Pre-shared Key or a
username and password for the authentication. And then once you're authenticated, you're now
connected to that network.
And you're expecting features like DHCP, default gateways, and so forth to be present on that
network, so you can behave like any other network citizen and have access to all the resources on
the network that are entitled to you. The one other item I wanted to talk with you about is channel
So I've gone in this interface back to Network Interfaces, down to the 802.11a radio. I clicked on
Settings. And if we scroll down, it'll give us the option regarding the radio channel. So by default, it
says it's using dynamic frequency selection, meaning it's choosing the channel by itself.
And this is in the five gigahertz field, because it's 802.11a that we're currently looking at. So if we
did a site survey, and we determined, you know what, we've got some conflicts on that channel. We
could manually specify the channel we want to go to by using the drop down, selecting the channel
we want to use.
So for example, instead of using 149, which it selected for us, maybe we want to go to 157. We'll
choose that. We'll click on Apply. And then we'll start using that channel and the range of
frequencies associated with that channel as it sends and receives radio frequency signals to support
our wireless networks.
In this Nugget, we've discussed and demonstrated how to set up the switch and access point to
support their ethernet connection, including VLAN assignment, duplex speed and power over
ethernet as well as on the access point, how to specify the SSID, the 802.11 technology we're using,
such as a/b/g/n/ac, controlling the channel.
And we also discussed 802.11i, which is WPA2, Wi-Fi Protected Access 2 where we can use it in
enterprise mode, which means we have a centralized AAA server with RADIUS for authenticating

your users, or WPA2 Personal mode, which implies we don't have a AAA server, but we can use a
pre-shared key, a PSK, for the authentication of devices that are trying to connect into our wireless
UTP Cabling
Bump bump, bump bump, bump bump, cabling, cabling. It's cable time in Network+. And on those
notes, let's jump in. In life, sometimes we take things for granted. And one of those things that we
take for granted is the physical cabling and the connectors that make our networks go.
Now, with the exception of like, for example, Computer 3 that gets access to the network via
wireless, many of our devices are going to be physically wired, like Computer 1 and Computer 2.
They are physically connected to switch ports. Now, we already know a few basics about these
switch ports.
For example, at the switch itself, we would configure the switch. We could put that port, that switch
port, into a specific VLAN. On the switch, we can configure the speed and duplex, or we could
allow the switch port to automatically negotiate the speed and duplex with the device that's
connected to it.
And we also know from our wireless Nuggets that the switch could also be providing power over
ethernet to a device such as a network camera, or an IP telephone, or an access point that wants to
receive its power over that ethernet cable. So when you are using physical connectivity to connect
Computer 1 and Computer 2 over to the switch, as well as when we're connecting the router over to
the switch, we are going to be using something called a UTP, which stands for Unshielded Twisted
And I remember back in the '80s, when I was first introduced to twisted pair, I thought it was like
Boy George and Madonna, a twisted pair. On our high speed networks today, the key player is
ethernet, and the major cabling type is unshielded twisted pair.
And the reason it's called unshielded twisted pair is because there isn't a little piece of foil or
shielding that's surrounding the cables. For example in coax, we have this nice metal shielding that
helps to protect the core from interference from outside signals.
And that shielding also protects things that are outside of that cable from receiving the signals that
are being sent through the coax. But in unshielded twisted pair, there is no shielding, no outside
shielding. So that's the unshielded part. And the twisted pair is because there are four pairs of wires

inside of our ethernet UTP cabling.

So that's a total of eight wires, made up of those four pairs. And each of the pairs are twisted, and
it's not just a random amount of twisting. They are twisted a certain number of twists per foot. And
they are strategically designed to have a different number of twists per foot per pair.
So pair one will have a certain number of twists per foot, pair two will have a different number of
twists per foot. And that's all been designed and implemented to support the type of transmissions
that we're going to be sending across those wires. Now, a question that might come up is, can we
just pick up any cable and use it? And the answer is no.
We have to have certain types of cable, and they are categorized. For example we have CAT 5
cable, which we could use for most flavors of fast ethernet and some flavors of gigabit ethernet.
And we also have CAT 6 cable. And there's also variants of each of these as well.
So the secret is, when we're going to be implementing our cabling, we'd want to identify what
technology are we using. And then make sure that we implement all of our connectors and cables
that are up to those specifications. So although it may not be important to memorize the number of
twists per foot for a certain pair inside of that UTP cabling, it would be critical to make sure we
have the right category of cable and connectors that we're using in our infrastructure to support the
For example, fast ethernet that we might be implementing in our network. So together, let's consider
the life of an unshielded twisted pair cable that we're going to be using in our network. Let's say, for
example, we want to connect a PC over to a switch.
And specifically, we'd be going from the network interface card on the PC over to a switch port on
the switch. So here's a close up. This little jacket, it's not resistant to any electromagnetic or radio
frequency interference. It's just a material that's used to keep these pairs together.
And if we were going to be running these cables, these UTP cables, in a plenum area, which means
it's an area of the building which is supplying air flow for the building, we'd have to make sure that
we purchase something called a plenum cable, or plenum-rated cable.
And all plenum cable is going to do, it meets certain requirements regarding how it burns. So it
doesn't generate certain types of toxic fumes when it burns. So if there's a fire, or the cables start
melting, either one would be tragic. We don't want to pump in a whole bunch of toxic fumes that

would be very devastating into the air supply that's being circulated around the building.
So plenum doesn't make the technology faster or slower. It's just a precaution in the event of a
disaster, to help protect human life based on reducing toxic fumes. So here inside this unshielded
twisted pair cable, we have four pairs. And you'll notice, in the pairs, we have a solid blue and a
white blue.
In this pair, we have a brown and a white brown, meaning it's a white cable with a small brown
stripe. And here we have green and white green, and here we have orange and white orange. And on
some cables, for example CAT 6, they've got a plastic separator in the middle that can help keep
these pairs separated from each other.
Now, if we walked up to our PC and just handed it these four pairs, the PC hasn't got a really clean
way of interacting with these pairs. So what we would do is, we would go ahead and straighten out
just a little bit at the end, those wires. And we would stick them inside of this connector.
Now this is an RJ45 connector. And you might ask why is it called RJ45? It's because it was like
one after RJ44 and one before RJ46. It's just a number. RJ stands for Registered Jack, and RJ45,
because of networking, is one of the most popular connectors out there.
So on one side of this RJ45 connector we have this little tab that we can use to help when we push it
into the switch port, to make it click. Or when we push it into the PC's network interface card, it
clicks to make sure it doesn't like drop out accidentally.
And then when we flip that over, we can see these eight metal connectors, which, behind the scenes,
are going to be crimped to each of these wires in the UTP cabling that gives the PC or the switch the
actual connectivity over the cabling. So all we would do is we take these wires, we would go ahead
and stuff them into this RJ45 connector. And then we would get a crimping tool, which is what this
is right here.
And then we would mash down on it, which makes the connection from these little pins on the RJ45
connector to the actual wires themselves. And then we would end up with a connection that looks
like this, with the wires inside. And then each of these pins on the RJ45 connector would now have
physical contact due to the pressure that the crimper gave it, to the individual wires.
So we have eight pins, one pin for each of the wires. And if we're looking at it from this perspective,
pin number one is over here on the left, and pin number eight is over on the far right. So in this

diagram right here, the little tab here is on the backside.

And we're looking at it from the pin side. That's also a good way, by holding it like this, you can
actually see what the colors are of the wires that are associated with each of the pins. So this is the
method we could use to crimp and terminate at RJ45 connectors, our UTP cabling. Now, in a
production environment it makes a lot of sense to get certified cable installers to install our cabling,
as well as terminate when necessary, if it's not already pre-terminated.
So they can verify that everything in that cable, for example, is CAT 6, or CAT 5, or whatever it
needs to be, and that there's no weak link in the cabling that's going to cause the network to either
fail or have degraded performance. Next, I'd like you to imagine that there's a major league baseball
And he is warming up to go into the game. So he's got the ball in the warm up area. There's a
catcher in that warm up area. And I'd like to ask you a question. And the question I would love to
ask is, what type of tool is the catcher going to use as the pitcher throws that baseball towards the
catcher? And you might be saying, now Keith, this is an easy one.
The catcher is going to use his catcher's glove, or his catcher's mitt, to catch the ball. And that's
exactly what's expected. And the point I want to drive here is that when we're sending signals across
cables, we need to make sure we're sending those signals on the correct wires where the receiving
party is expecting to receive those messages or those signals.
And we can use Computer 1 right here connected to the switch as an example. The correct cabling
to use between a computer and a switch would be something called a straight through cable. What
that means is, at the end of the entire process of the cabling that's involved between the computer
and the switch that pin 1 on the computer termination side should match up and lead to pin 1 on the
switch side. And that's what's referred to as a straight through cable.
Now, for a little bit of behind the scenes on that, the PC is expecting use pins 1 and 2-- that's these
two guys right here-- for the pair of wires which it's going to using to transmit, to send information
over to the switch. And the great news is that the switch is expecting to receive signals from that
device connected to the switch port on pins 1 and 2, respectively. See it's like a marriage made in
It's like the pitcher throwing, and the catcher with his catcher's mitt right there ready to pick them
up. Now, on the PC side, if it's expecting to receive information or data from the switch, it's
expecting to receive that on pins 3 and 6, from the PC's perspective.

And the great news is that the switch is expecting to transmit information. And the switch is
expecting to use pins 3 and 6, respectively, to do that. So in basic ethernet, all we're really using is
pins 1, 2, 3, and 6. And the other four wires, although they are present and terminated at the RJ45
connector, are not used in basic ethernet.
Now, if we start going up to higher speeds and different technologies, or integrating some variants
of power over ethernet, that scenario may change. But for the basics, pins 1, 2, 3, and 6 are used for
the sending and receiving of data. And the rest of the wires are not used.
In the event that we needed to take two similar devices, for example, we have two PCs that we want
to connect back to back using an ethernet connection, because they're both expecting to send on
pins 1 and2, and they're both expecting to receive pins 3 and 6, what we could do is we could play a
mean trick. And that mean trick is use a crossover cable between the two of them.
And the crossover termination would look like this. One side we have pin 1, 2, 3, 4, 5, 6, 7, 8. And
at one side we take pin 1, and we map it over to pin 3 at the other side. And we take pin 2, and we
go to pin 6 on the other side. And we do the same process on the other side as well.
So a crossover cable would be 1 to 3, and 2 to 6. And if you flip that, it would be 3 to 1 and 6 to 2
for our crossover cable. And that comes in really handy when you have two like devices. For
example, that works with two PCs, or two nodes on a network that typically would both talk to a
They can talk directly to each other if we put a crossover cable directly between those two devices.
It also comes in handy if we're doing a cross connect between two switches. For example, if we're
using unshielded twisted pair, and we want to implement this connection right here between switch
1 and switch 2, because they're both switches, and they're expecting to talk to an end device, not
another switch, we could once again a crossover cable right there.
So let's say this is a switch 1 here on the left, and switch 2 over here on the right. When switch 1 is
transmitting data, it's going to be using pins 3 and 6 by default. And because switch 2 is expecting
to receive data on pins 1 and 2, that's where those signals will end up.
And the same thing happens if switch 2 is trying to send data. The transmission pins are pins 3 and
6 by default on switch 2. And the receiving pins over on switch 1 would be pin 1 and 2. So the
crossover cable is just a fancy trick to get two like devices, for example two switches, to

communicate with each other over an ethernet connection.

So the question might come up that if we're using a straight through cable, for example, between a
PC and a switch, can we use just any order for the wires? For example, the orange one first, then the
blue one, then the green one. Or is there a specific order that matters? And the answer is there's a
specific order that matters if we want to follow the standard, which we do.
And the cool thing about standards is that there's so many to choose from. And the two specific
standards I want to share with you right now regarding terminating these ends of these UTP cables
in RJ45 connectors, is the standard 568A and the standard 568B. And here's the secret.
If you're doing straight through cables, for example, between a PC and a switch, it really doesn't
matter if you do 568A or 568B as long as-- and here's the trick-- you do the same on both sides. So
at the PC, if you do 568A termination, and at the switch you do the 568A termination,
congratulations. That is a straight through cable, and the pins are used in the correct order.
And part of the reason that the order matters is the number of twists per foot and how a specific
wire is associated with the other wires in that UTP cable. And if we wanted to use 568, that's great,
as long as we use it at both the PC or whatever the end device is-- it could be an access point, or are
printer, as well as a switch-- that that device is connected to.
So here are the standards for 568A. And over here is the standard for 568B. I've also got a visual
representation of what the pin-outs would look like when that UTP cable is terminated and crimped
inside of an RJ45 connector. And again, pin 1 is this guy over here on the far left, and pin 8 is on the
far right. So as you look at these standards, I'd like to point out a few pins that are the same on both.
For example, pins 7 and 8 are white brown and brown. And that's true for 568A and 568B. So that
like a two for one special. Also, pins 4 and 5 are identical between the two. So pin 4 is terminated
with a blue cable, and pint 5 is terminated with the white cable with the thin blue stripe.
And that is exactly this same as it is on 568B. Now, what do those four wires, pins 4, 5, 7, and 8-what do those four wires have in common with plain Jane ethernet? And the answer is, they are not
used. Because we're only using pins 1, 2, 3, and 6 for plain Jane ethernet technology.
So on closer inspection of the A standard, we are using the white/green green and green as pins 1
and 2, and we're using white/orange and orange for pins 3 and 6. So that's basically it. So those are
the four pins that you need to worry about for 568A. And I've got another bonus for you.

If you remember those four for 568A, you simply flip them for 568B. So anywhere in 568B where
there was white/green, you swap it out with white/orange. And anywhere there was green, you swap
it out with orange. And that's how you come up with the 568B. And over here I've got pin 1, which
is the white/orange in that position, followed by orange, followed by white with the green stripe,
then blue, then white with the blue stripe, then green, then white with the brown stripe, and then
brown in the final eighth position over here on the far right.
And a cable company that does professional installation and certification of the cables will not only
install the cable, they will use cable testers to verify the pin-outs are correct, that they're using the
right wires. And they can have those reports generated with the cable tester they use to certify your
cabling infrastructure.
And for a device that's physically close to the switch, we may just be using a patch cable. And you
could actually just look at both ends of the patch cable, and look at the colors being used, to verify
that this is a straight through cable where pin 1 goes to 1 and 2 goes to 2, et cetera. And you can
also verify the standard, is it 568A or 568B, just by looking at the order that they used for the cableto-pin termination going from left to right.
And I have a big reveal I'd like to share with you. And that is, if we need to create a crossover cable
and still follow the standards, you know what we could do? Is we could just terminate one end of
the cable using 568A, and the other end of the cable using 568B. And guess what? We have a
crossover cable, because pin 1 on one side will go to 3 on the other, pin 2 on one side will go to 6
on the other, and vice versa. And that's our crossover cable that we could use when we want to cross
connect any two like devices, like two PCs, or two switches, back to back.
One of the tools that we'll frequently be using when we verify cables, or for doing troubleshooting,
is called a cable tester. And here's one from one of my favorite vendors, Fluke. One of my first
multimeters I had back in the '80s was a Fluke multimeter.
And I just loved it, and they make great equipment. I'm happy to give them a glowing endorsement.
And with the cable tester you can put a little adapter on one end of the cable. So there'd be a little
Fluke adapter, you'd plug in the cable. And then that cable would run anywhere it ran, through the
building, or the ceiling, or what have you.
And the other end you would pug in to the Fluke tester. And then what it could do, it could verify a
couple things. It could verify what the length is of this cable run, all the way to the dongle that we
placed on the other end. And also, if you're not sure exactly where that terminates, they have

multiple adapters or dongles you can place.

So for example, you have 1, 2, 3, 4, 5, 6, 7, 8. And you'd put a little dongle as the termination point
on all those cables. And that would just be RJ45 jacks that are used on these dongles. And then
when you're out at the workspace, the cube, when you plug in, it can actually report back on the
dongle number-- that's the other site-- in addition to how many meters or feet is the cable run.
And for the entire distance between the network interface card on the PC, all the way to switch, that
should be under 100 meters. So generally, what happens is the switch will in a wiring closet, for
example, on the fourth floor. And in that wiring closet there might be a patch panel just for
organizational purposes.
So there's a patch cable from the switch to the patch panel, then there'd be a horizontal run for that
cable, because from that wiring closet out to where the cube or desk is, that would be terminated at
a little wall jack very likely. And then from there, the user would go ahead and take their patch
cable and plug it into their PC.
And that's how they get connectivity. So if we plan on the horizontal run being no longer than 90
meters, that could allow us a few meters right here between the switch and the patch panel in the
wiring closet, as well as a little bit of distance for the patch cable that's going over to the wall jack
that also has an RJ45 connector. Again the goal would be to keep everything for that run from the
PC to the switch under 100 meters. Why? Because that's the specification, and if you go over that
we can start getting into problems.
And a cable tester could assist us in identifying how long that cable is, as well as any issues with the
pin-outs. For example, for a straight through cable, we know that the cabling should have pin 1, 2,
3, and 6, and they should be straight through connections between the PC side and the switch side.
And even though those are the only four being used, the other pins should also be a straight through
connection. Now, what if pin number 1 and the cable connecting pin 1 on one side to pin 1 on the
other had a physical break? Now, the individual cables themselves, they are stranded copper.
It's not just one piece of copper. If you break it open, it's a whole bunch of little teeny wires, copper
strands if you will, that make up that cable. And that's to improve the connectivity of the cable. But
if there was a complete break, the cable tester could show us that that is an open.
It's an intended connection that should be there, but it's not. It's an open circuit. So when I think of

the concept of open, I'm thinking of a connection that should be there but it isn't. Now, what
happens if somebody terminates their own cables and they make a whole bunch of mistakes? For
example, it's miswired.
We have 1, 2, 3, and 6, and at the other side of the cable they've got 2 and 1, and 6 and 3. And this
would be an example of a terrible cable. It's not a crossover cable; it's not a straight through cable. It
is simply miswired. So on the cable tester, it would show as a short, the connection from 1 to 2,
because it's an unintended connection. There shouldn't be connectivity from pin 1 on one side to pin
2 on the other. So an unintended connection is referred to as a short, as in a short circuit.
Shouldn't be there. The connectivity shouldn't be there. Now, at the same time, a cable tester would
also identify that pin 1 from one side is open to pin 1 on the other side, it's not there. So if we have
cabling that is mis-terminated, it's actually going to generate opens as well as shorts from a cable
Because for example, over here pin 1 is not connecting to pin 1. That would be considered an open,
where the connection should be. And pin 1 is going to pin 2, and that would be considered a short
because it's an unintended connection that shouldn't be there.
And we'd have those same types of issues with the other connections as well, because they are
incorrect. And a cable tester is the tool of choice to both certify that cabling is correct, to
troubleshoot cabling that we think has a problem, and to remedy that problem by re-terminating
either one or both sides of the UTP cable.
In this Nugget, we've taken a look at unshielded twisted pair and the RJ45 connectors that we would
terminate with a crimper at each end of the UTP cable. As assigned homework, I would strongly
recommend that you memorize the pin-outs for 568A. And if you get those memorized, converting
that over to 568B will be a piece of cake, because all we're doing for the 568B is we're taking 568A,
and we're swapping out the orange for green on both sides.
Ethernet Standards
In this Nugget, we're going to investigate some additional cables and connectors in the world of
Ethernet. Let's begin. Most of the wiring that we're going to have to carry the signals in our highspeed local area networks is going to be Ethernet. Now, Ethernet can run on copper cabling, such as
unshielded twisted pair.
And it can also run on fiber optic cables. And with fiber optic cabling, we're using light that is being

sent through an optical cable to send those bits screaming across the network. So what I thought
would be fun to do is take a big picture look at a building regarding Ethernet technology and talk
with you about a few additional components that we're going to have as part of our cabling plant.
So in this example, we've got a three story building. So Bob's up here on floor three. Lois is here on
floor two. And then on the first floor we have our data center. And in the data center we have
probably tons of storage as well as tons of computing devices.
If we have any mainframes, they would be here in the data center. If we have virtualization going on
and running lots of virtual machines and servers, they're also very likely here running in the data
center. In the data center we have a raised floor. So underneath the floor we could have tons of
cabling for our network connectivity as well as power that could then be right up through the floor
into each of these racks.
And a standard sized rack is a 19-inch rack like can hold lots of different devices. For example, a
router could be slid into and fit in a 19-inch rack. A switch could be slid into and fit in a 19-inch
rack. A lot of servers can be slid in and put into a 19-inch rack. And then here in the data center we
have this MDF.
Now an MDF is an acronym for main distribution frame. It's a major connectivity point for the
cabling for that building. So at the MDF we have our connections that went perhaps out to the
outside world. So here's our service provider. And the blue cabling represents outside wiring.
So maybe we're using the service provider for internet access and/or we're using the service
provider for wide-area network connectivity between us and our branch office. And all of that could
be integrated into one physical connection coming in from the service provider.
Then here on the second floor, we have a wiring closet. Now, the wiring closet could also be
referred to as an IDF-- an Intermediate Distribution Frame. You can think of it as a mini MDF but
just for that floor. And for that connectivity on the second floor here in the wiring closet, we have
this vertical run.
And this vertical run is the backbone wiring that is connecting the second floor down to the MDF.
You'll also notice that from the MDF we have connectivity up to the wiring closet on the third floor
as well. And for fault tolerance, we have more than just a single connection.
We've got a couple in place. So up here on the second floor it's very likely that we have at least one

switch, a layer 2 switch. And the same thing for the third floor. And we very well could have 19
racks in each of the wiring closets, the IDFs. So the switch could be slid into that rack.
And for organizational purposes, we could also use something called a patch panel, which is a
bunch of RJ-45 connectors on a panel. And what we could do is we could connect to switch to these
patch panels. And then for the connections that go out to the work area, we could connect from that
patch panel to go out to the work area.
And ideally, we'd have really good numbering. So on the patch pedal, for example, it may indicate
what switch port this leads to on the switch as well as which cube out on the second floor that that
connector on the patch panel goes to. So this cable that goes out the work area is referred to as a
horizontal run or horizontal wiring.
And it very well could go through the ceiling and then down the walls. Or in some cases, you may
have troughs in the floor that could be used to carry that wiring out to where the user is. And then
we would terminate it at a little wiring jack on the wall so that the user, we could go ahead and take
the computer at the user's location, take a patch cable, have somebody plug-in to that jack.
So the connectivity would go like this. From the PC, using a patch cable, over to the jack. The Jack
is wired all the way to the patch panel. And the patch panel has connectivity down to a switch port.
And then the switch is connected to the horizontal runs, which give it access down to the data center
in the MDF.
And down here in the MDF we could have our routing happen. If, for example, Lois needed to send
a packet to some other subnet or out to the internet, the layer 3 routing could happen down here on
the first floor. And that way, we don't have to have routers in every single wiring closet.
We can just have basic layer 2 switches in the wiring closet and leave all the heavy lifting, the
routing and access control lists and so forth on router interfaces, down here on the first floor. And I
also should mention that it's probably strongly recommended that, as your users connect to the
network, we are connecting their computing devices to the network.
And we would never want to take an RJ-45 cable and plug it in directly to a person. Seriously
frowned on. So here in the building, this is a high-level overview of how the Ethernet connections
may flow, including the use of wiring closets or IDFs, 19 racks in those wearing closets, patch
panels in those wiring closets, layer 2 switches in those wiring closets, horizontal runs and vertical

Now, regarding Ethernet, we have lots of choices, both for the type of cables we're going to use as
well as for the speeds. A long, long time ago in a network far away, token ring was used. That was
like 20-plus years ago when I started with networking. And when Ethernet came out, it was like a
brand new thing.
And one of the first implementations of Ethernet was to do it on a coaxial cable. Now, a coaxial
cable is called that because it has two conductors. So for example, here's an example of a diagram
of one. We have an internal conductor and we have this conductor.
And they share the same axis. So it's called coaxial cable or, for short, you can just call it coax. And
one of the standards for Ethernet back in the day was called 10BASE2. The 10 stands for how many
megabits per second is supported by that networking technology.
And then BASE represents base band, meaning there could be one signal on that media at a time,
unlike broadband where you could have multiple signals on the media at a given time. And then the
2 represented that this 10BASE2 network could go approximately-- this is a stretch-- approximately
200 meters. It was really just a little bit under that.
But that's what the 2 was there for. And with a 10 network, it would go something like this. We
would take a few PCs. We would put a network adapter in each one of them. And out of that
network adaptor, it had a connector that looked like this. It's called a BNC connector.
And you might say, well, if each of these network cards has a BNC connector, how do you connect
them all together? And the answer would be, you take this T-connector. And you would go ahead
and plug the T-connector onto that BNC connector. And you would twist and it would lock into
And then you would grab some coaxial cable. And then you'd simply go from one side of the T to
the T on the second PC. And then from the second PC from the T over to the third PC. And then
when you're done with the third PC, you'd have a little terminator that you would screw one to that
cable that would kill the signal once it reached the terminator.
And I believe in those days it was like a 50-ohm terminator. And you'd have that on each side. And
this is referred to as a physical bus topology because we're sharing one giant bus, meaning any
device who sends traffic, everybody else on the network has a chance to see it.

And that's also why you'd want to terminate that signal at the very end of the bus so that it didn't
reflect back into the network and interrupt the other signals that were taking place. So the good old
days. Hopefully, you'll never have to implement 10BASE2. But that's how it worked.
Now, I bring up coax because we're still going to see coax. However, it's very likely going to be
used for features such as closed circuit TV or cable TV. And the actual type of coaxial cable that we
use is going to vary based on the application. So for example, RG6 is a much thicker diameter for
the conductor.
And an RG6 cable verses an RG59 which has a smaller conductor. And these are by means not the
only two standards for coax. These are just two of the many standards. So if you're asking, Keith,
which one should I use? And it all depends on the application.
How are you going to use the coax? Look at the specifications and make sure you get the correct
coax. And then when we terminate the coax today, we are no longer going to use these BNC
connectors that we did decades ago. Instead, we're going to use F-connectors.
And with an F-connector, we simply screw on the connector. So here's a coupler or for an Fconnector. Here's a coupler for a BNC connector. And one of my recommendations would be, if
you're ever going to deploy cabling, hire a certified cabling company that can only implement it,
terminate it correctly, but can also generate reports and provide you a warranty regarding their
Because if we have a physical problem with cabling which isn't terminated correctly or it's not the
right type of cable, that can lead to intermittent problems, which is just grief that nobody has time
for. So starting off with a good, solid cable plant is a great idea.
Now, as I mentioned for our high speed networks with Ethernet, we are not going to be using a lot
of coax cable today. Instead, we're going to be using a lot of unshielded twisted pair. And we're
going to be using some fiber. For our Ethernet standards that use unshielded twisted pair cable, that
is this group right here.
So when using unshielded twisted pair, we're going to have at the center of that in today's networks,
we're going to have a switch, a layer 2 switch. It'll have RJ-45 ports that will connect to cables,
unshielded twisted pair cables that are terminated with RJ-45 connectors that go out to our devices.
And assuming that each of those ports on the switch are on the same VLAN, if PC 1 sends a

broadcast into the switch, that broadcast is sent by the switch to all other ports that are in the same
VLAN. I just realized that I should have put PC 3 here and PC 4 there. And that's another
reinforcement of why a VLAN is referred to as a broadcast domain.
Anytime a broadcast is sent into the VLAN, that broadcast would be forwarded to all other ports
associated with that VLAN. And now, with using a switch, you see how this looks like a star? For
example, we have the center of the star, which is our switch. And then we have our PCs and printers
other devices connected to the switch.
This is referred to as a star physical topology. And the type of unshielded twisted pair cabling that
we're using to connect our PCs in this example to the switch depend on the technology that we're
using. So if we're using 10BASE-T-- which represents 10 megabits per second base band, but the T
now says that we're using twisted pair.
Or that's generally what it implies. And back in the early days when we made the jump from
10BASE2 to 10 and we started using switches-- in fact, the first time we did it we actually used
dumb layer 1 hubs as repeaters at the center of the star. And then we upgraded to switches once that
hi-tech was ready regarding layer 2 switching. And with 10 we could use category 3 UTP cable. The
higher the category, the higher the specifications are and generally the more throughput that type of
cable can handle.
So if we had a Legacy system, for example, that was still running 10BASE-T, we could probably
get away with still using Cat 3 UTP cable to connect devices to that. However, we could also use a
better cable and it's not going to harm anything. If we plugged a Cat 6 cable into a 10 network, it
would still function.
We're still using straight through cables. The pinouts haven't changed. And the maximum supported
distance for a run that's from the edge of the switch to the PC itself-- that would include any patch
cables going to patch panels-- is 100 meters. So if we are using patch panels for organizational
purposes, we might want to make our horizontal runs no more than 90 meters. And that leaves us a
few meters from the patch panel in the wiring closet to connect down to the switch and also a few
meters from the jack in the cube or the office that we can use the patch panel to connect to the PC
And so the word Ethernet, just the word itself, sometimes has a general meaning of 10 megabits per
second to some people, but not all. And why is that? Well, we also can use a thing called 100BASET, which is affectionately known as fast Ethernet, that operates at 100 megabits per second. The
cable requirements are a slightly higher grade of cable.

It can operate at 100 megabits per second. It also has a maximum cable specification for 100 meters
from the edge of the switch to the edge of the device that's connecting to the switch over that UTP
cable. And then we have 1000, which is one gigabit per second. And that requires a slightly higher
grade of cable, Cat 5e-- as in elephant. And that can support one gigabits per second.
And generically, going back to why some people call it Ethernet still, we could refer to this one
gigabit ethernet connection as quote unquote ethernet because that still is the technology that is
being used. So if people are talking about ethernet, they may be referring to 10 meg or 100 meg or a
gigabit which is 1,000 meg. So it's not crazy to think that you might have to ask for additional
details regarding the exact specification of what they're using.
And then the 1000BASE-T, there is a bunch of flavors and varieties that that represents. And there's
a 1000BASE-TX, which is implemented slightly different, that requires Cat 6 unshielded twisted
pair cabling as opposed to 5e. And that also can support one gigabit per second.
And the maximum range for that from the edge of the switch to the edge of the PC is also 100
meters. And then, my friend, if that wasn't good enough, we start kicking it up another notch to 10
gigabit per second ethernet. And that requires either Cat 6 or Cat 6a. And it depends on how far we
want that cable run to be.
If we're using Cat 6, that'd be around 55 meters, the maximum from the edge of the device to the
edge of the switch. Or if we're using cat 6a, we could go ahead and go a full 100 meters. And when
this is being implemented, we want to look at the specifics for the vendor-- for example, the switch
manufacturer that we're going to be using-- just to verify that our cabling plan is in tolerance with
what they are requiring for their switch.
So as customers implement new cabling plans, it's very likely they're going to implement cat six or
better, which gives them the ability to support that technology and then everything below that. And
in some companies, they may have Cat 3 that is still in place. They haven't ripped it out yet because
they may be using that for other purposes.
For example, because it's just copper wires with unshielded twisted pair, perhaps they could use
some of that for telephone services as well. And then this section right here is all about fiber optic
cable. And there are lots of different flavors of fiber optic cable that can carry light to transmit
information across their networks.

However, the two major categories for fiber optics are MMF, which stands for multi-mode. And I
put the F there to remind us that it's fiber. So multi-mode fiber, and the other flavor is single-mode
fiber based on the characteristics of how that fiber optic cable works.
And generally speaking, single mode fiber has the capacity to send a signal a further distance. So if
we're ever talking about long distances-- for example, 20 or 30 kilometers-- it's very likely we're
using single fiber if we're using fiber optics to accomplish that.
So we have 100BASE-FX. So 100 over here represents 100 megabits per second. BASE, just like it
did with our copper, represents base band. 100BASE-FX is a lot like fast ethernet on copper except
it runs over fiber optics as opposed to copper. So the cable type it uses is multi-mode fiber.
It supports a 100 megabits per second. And the range is about two kilometers. Now, if we're using
fiber, it has a huge capacity, way beyond 100 megs. So it's very likely we're going to be using it in
some flavor, for example, 10 gig. So we have a whole bunch of different flavors of 10 gig fiber.
So here we have 10GBASE-SW and SR, which are similar in that they both use multi-mode they
both support 10 gigabits per second, and they both can support a range of approximately 26 to 300
meters. And that's going to vary based on the type of multi-mode fiber we use and the specifications
for the switch that's using that fiber.
And then we have the LR and the ER, which both use single fiber. So LR can go 10 kilometers
approximately. And ER can go 40 kilometers. And here's a way that can help you remember the
guidelines of which ones these are. For example, SR, we could think of that as meaning short-range,
meaning it doesn't go very far.
You might look at it and say, Keith, 300 meters, that's pretty far. Yeah, but 300 meters is less than
one kilometer. If we go to LR and ER, they can do 10 kilometers and 40 kilometers. And SR can't
even do one kilometer. So for fiber, if we remember that SR is short-range compared to LR, which
stands for long-range-- it actually stands for a long-reach, but following our analogy, it makes it
easier to remember.
So short-range, long-range, and then ER is extended-range. It actually stands for extended-reach.
But I like the short-range, range-long, and extended-range to remind us of the distance limitations
regarding those three specific fiber technologies for Ethernet.
Now, in addition to the fiber cabling types, there's also lots of different ways to terminate that fiber.

One way is, Fiber, you're fired. That'd be one way of terminating the fiber optic cable. However,
with unshielded twisted pair, we have our beautiful RJ-45 jack. And we have our patch panels with
RJ-45 connectors. And pretty much, the standard ethernet with copper with unshielded twisted pair
looks like RJ-45 at the ends. However, with fiber optic technology, we have several choices.
And those choices are right over here. Now, these acronyms for the various types of determinations
that we can use with fiber, they have meaning as far as what they were initially labeled as. However,
the way that I remember what these fiber termination connections look like-- and I think it'll be
helpful to you as well-- is to think of this guy right here as, you stick it on and then you twist.
And that's how it locks into place. In fact, it kind of feels like a BNC connector on the old coax
cable. So for this fiber connector called ST, think of Stick and Twist, the acronym ST. Although,
that's not why it's called that. And you'll notice a lot of these fiber connectors have a pair.
And that's because we use one fiber optic cable for sending and another fiber optic cable for
receiving. So in unshielded twisted pair, we had different wires for that. In fiber optics we're using
different cables for that. So for the next one, SC, let me tell you how these work.
You take these and you simply-- you don't have to twist-- you simply push them in until they go
Click. So this guy is Stick and Click. So if you were ever asked about an ST connector or an SC
connector, the fact that you're aware that it's a fiber connector, the way you terminate a fiber optic
cable, that's really the important part.
I don't believe you're going to have to recognize any of these on site and say, oh yeah, that's an SC
connector. Although, after you're done here and watching this Nugget a couple times, you may be
able to do just that. Next, we have the FC connector, which I like to think of as Fiber Connector.
That's no what it stands for. But it's a great way to remember it as long, my friend, as long as we
don't get it confused with the coax F-connector, which is the screw-on connector for coax cable. So
the FC actually screws on to the connection with a similar function that the F-connector in coax did.
So it screws on for the connection to be complete. Next, over here we have LC. And the way I
remember LC, see how cute and tiny they are? This is a pair of fiber optic cables terminated with an
LC connector. And the way I remember these is that this little pair is little.
It's a little connector. And these are usually set up as a pair as opposed to, for example, two
connectors that are independent, that just go in next to each other. Again, I think most important part

of this would be to recognize, when you see these types of connectors, that they are associated with
fiber optic cables.
And the MTRJ is a termination type for fiber that really didn't take off. It was designed to look and
feel like an RJ-45 connector, which we know and love as the termination point for unshielded
twisted pair. So whenever you see MTRJ, think RJ. And just realize that this was attempting to be as
common and as similar as an RJ-45 connector was to UTP that we might use MTRJ as an equally
common for fiber.
It did not make it as the most common termination type for fiber. However, MTRJ still is on the
blueprint. So the piece I'd have you be aware of is that these acronyms all refer to termination types
that we would use with fiber. And the way we could apply this knowledge is, for example, if we
were asked some type of a question regarding a point-to-point connection that was 5 kilometers
long and there was no interruptions in that connection.
And we were going to troubleshoot that connection, what type of termination would we'd look for at
the end of that cable? So anything that relates to, for example, coax or anything that relates to
unshielded twisted pair would be out of the question because those technologies with copper cannot
go over a single cable set that far on their own.
And fiber optic cable does not have to be terminated the exact same way on both ends. Now, there
are a whole bunch of rules surrounding it. But as an example, here we have an LC connector on this
end with an ST connector on this end of this fiber optic cable.
We've also got this really cool thing here called a fiber coupler. If we ever needed to, for example,
take a signal from one device and spread it out to two devices, a fiber coupler-- and this is an
example of one of them-- would be the type of device that could provide that functionality for us.
And it looks like this one is terminated on these ends with SC connectors, just visually looking at it.
Now, one of the really handy features that switch manufactures have made available to us is the
adaptability of their devices to support different types of fiber termination.
For example, here on this switch we've got several ports. And in those ports we can slide in
something called an SFP. And SFP stands for Small Form-factor pluggable. So we buy the adapter,
we plug it into this slot on the switch, and then this end of the adapter is set up to support a specific
type of cable termination.

So there's SFPs for fiber and the various connectors that we might have on fiber. There's also SFPs
that we can purchase to support copper as well. And on older devices, before SFPs came out, they
had something called a GBIC, which is simply an adapter like an SFP except it was fatter.
So if you buy a really old switch that has a big empty slot, usually in the front right hand corner of
it, it might be a g slot. And g stands for Gigabit Interface Converter. So in my home lab, I've got
some fairly new switches and I've got some older switches.
And I can connect them all together using fiber because I have SFPs in my newer switches and I've
got GBICs in my older switches that all allow fiber connections to interconnect them together. And
you might be saying, Keith, you don't really need fiber if your devices are right there in your home
next to each other.
And the answer is, you're absolutely right. However, in a building, especially a very tall building,
where I want to have a high-speed, for example, 10 gigabits per second or more backbone, it's very
likely we'd be using fiber for that backbone and redundant pairs for fault tolerance as the vertical
run that connects the switches up in the IDFs down to the main distribution frame, which might be
at or near the data center.
In this Nugget, we've taken a look at several different cable types and their characteristics that we
might use as our infrastructure for both the horizontal runs out to customers as well as the vertical
runs that would go between the IDFs in the wiring closets and the main distribution frame near or at
the data center.
Troubleshooting Methodology
Having a Troubleshooting Methodology can greatly improve our ability to troubleshoot networks,
especially networks that we're not that intimately familiar with. Let's begin. Not too long ago, I had
the opportunity of taking an exam, a troubleshooting exam, for Cisco Systems.
And I was surprised at how detailed and involved the network was and how short of a period of
time I was given to resolve a whole boatload of trouble tickets. And as I think about that, I think
how does that apply to the networks we work on today. Sometimes, if we work on a network, we
get familiar and comfortable with that network.
But on the other hand, if we're consultants or we're just starting at a new company, we might have to
do some really quick troubleshooting and not be as familiar with their specific network as we would
like to be. And that's when, my friend, having a methodology for our troubleshooting really comes

in handy.
And one of the things I always do when doing troubleshooting, especially on a new network, is I
slow down in order to be effective. Because if you and I just run in and we start trying a whole
bunch of things and just hoping that the network will start working, there's a possibility it won't start
working on its own.
There's also the possibility that, as we go through the network and we make slight changes, those
changes themselves could have negative impact on the network. So then we'd be going in the
reverse direction of what we want, regarding solving the overall problem.
So in this Nugget, I'd like to chat with you about a methodology from Network+ that we can use as
a framework for troubleshooting networks. Here are the steps provided by the Blueprint for
Network+ N10-006 regarding troubleshooting. And the first step is to identify the problem.
So let's say that Bob, who's sitting at computer 1 has called the help desk and says, I cannot print, I
can't print. And that would be our first step in gathering information. And it's always desirable if the
problem can be duplicated on demand. One of the worst challenges is that, hey, sometimes this
works and sometimes it doesn't.
Because then we have to find all the variables involved in why it's working, when it works, and why
it doesn't when it doesn't. So if they can duplicate the problem, that's fantastic. Because then we can
see it. We can see the problem as it happens. We'd want to maybe ask Bob a few questions.
For example, one of the questions I'd ask Bob is, when was the last time this worked? When was the
last time you did print to this printer that you're trying to print to now? The other thing we might
want to do is ask other users, are they able to print? So if Lois down here on computer 2 is able to
print, what did we learn? Well, we've learned that the printing function seems to work over the
Lois can print, but Bob cannot. So we would probably not focus our energy on the printer itself,
because the printer is functioning as a network device over the network for Lois. It could be a
permissions issue for Bob. Or maybe Bob has a connectivity problem to the switch itself.
Or maybe Bob hasn't logged onto the network. So he hasn't been authenticated by the network yet.
And as a result, he's not being allowed to print. He doesn't have permissions, because he's currently
an unknown user. And the process of identifying symptoms is great.

And the reason I love the word symptoms is because that's what we should focus on, especially as
we listen to users. A user may tell us, the network is down, or some other factor what they think is a
fact. When in reality, what they're trying to describe is just a symptom of what they're experiencing.
It would also be good to identify what has changed. For example, if Bob said he could print
yesterday, but he can't print today. And we realized, there was a patch or an update that was applied
overnight, that would be a good thing to keep in mind as a possibility of what's causing Bob's
And if Bob is also saying, hey, you know what, I can't print and I can't get to the internet and I can't
use my voice over IP phone, we could mentally make a note that all those three things are
happening for him. But we'd want to approach those individually.
For example, if we're focusing on the printing problem, I like to quote from Star Wars, stay on
target, stay on target. Don't get distracted and start going other directions, until we find the fault
domain, the thing that's causing the problem. And then focus on fixing it.
And to get to there, we have the major bullet number two. So number one is identify the problem.
Step number two is to establish the theory of probable cause, including questioning the obvious.
Let's say, for example, Bob at his computer can ping the router's interface right here.
So Bob has the IP address of his default gateway. And he can successively ping that IP address.
Does that mean that Bob's computer IP address is correct or on the right subnet? And we might
think, yeah Bob's IP address has to be correct, because he can ping another device on the local
network, router 1's interface. However, what if we're on the network? So that's our
network address.
And let's say that router 1 is at But let's say Bob's computer is configured-- and I'll put
here Bob-- and say Bob it configured as But let's say Bob's mask is a 29-bit mask. It's been
either accidentally or maliciously configured incorrectly.
So from Bob's computer's point of view, he would think that all the way through 6 would
be on the same subnet. Now, if you're wondering, hey, Keith, how do you know that with a 29-bit
mask that the range is 1 through 6? Well, going back to our IP subnetting course, which we're using
as part of our preparation for Network+, those have been assigned.

If we have a /29, that's a block size of 8. So our networks would be 0, 8, 16, 24, and so forth for that
last octet. So our first address is the subnet plus 1. So this would be 9, 17, 25. And the last valid IP
address for each those subnets would be the next subnet minus 2. So that would make the last IP
address in the subnet 6, 14, 22, et cetera. So we know that the range for the subnet from
Bob's perspective would be host 1 through 6. So it just so happens that Bob's computer believes that
it is on the same subnet with router 1. And in reality, if this printer is at .52 with this /16, Bob's
computer is going to believe in its own mind that that .52 is on a different subnet. In fact, let's use
an easier one that's already up on the board.
Let's say the address is .10 for that printer, which means that Bob's computer thinks that that is on
the 8 subnet and Bob's computer is on the 0 subnet. In either case, Bob's computer is going to think
it needs a default gateway to go ahead and reach that printer.
And now depending on what type of router we have and whether the router is willing to reroute that
packet out on the same interface up to the printer depends on how that router is configured and what
vendor or router we have. But in either case, a misconfigured IP address on Bob's computer could
cause that problem.
So going back to questioning the obvious, we'd want to make sure that Bob has an interface IP
address on his computer. Make sure he has a correct mask associated with his IP address. Verify the
correct default gateway. Verify correct DNS. And when approaching this problem on Bob's
computer, which we've now isolated down to Bob's computer-- because it's not the printer, it's not
Lois' computer, other devices can print, it's simply something with Bob-- the fault domain is going
to be Bob's computer and/or Bob's connection to the switch based on the problem that we find-- the
approach could be a top-down, a bottom-up, or a divide-and-conquer.
And here's an example of a top-down or a top-to-bottom approach. From the TCP protocol tech
perspective, we've got these layers. We've got layer 1, 2, 3, 4, and the application layer. So here, we
have transport. That is the network layer. And what about layer 2, what is that called? If you're
saying, Keith, that's the data link layer, you'd also be right on the money.
Fantastic. And layer 1, of course, is physical. So as we work together to establish a theory of
probable cause regarding the issues that Bob is having, if we took a top-to-bottom approach, what
we might do is open up a browser and connect to an internal web server.
Because that's going to require the cooperation of the entire protocol stack. So the application layer,
we're generating and forming an HTTP request that gets encapsulated and processed down the stack
until it's sent. Now, if that works, then we know that we have some good network connectivity, at
least for HTTP to a local server.

So that's a top-down approach. The bottom-to-top approach would be, OK, let's go ahead and take a
look at the details for Bob's interface on this computer. Is the physical layer OK? Does the interface
show as up? And then we might look at the ARP cache, for example, on Bob's computer.
Has Bob's computer resolve any IP addresses to layer 2 Mac addresses, working our way up the
protocol stack. And the divide-and-conquer approach is simply somewhere in the middle. For
example, maybe on Bob's computer, we do a ping request. We try to ping this router's interface.
And if that doesn't work, then maybe we ping our default gateway. So when we're doing a ping,
we're starting off somewhere in the middle. We're not taking a look at the layer 2 information
specifically or the physical layer on Bob's computer. We're doing a ping to different destinations and
seeing what the results are.
We could also use TRACERT from Bob's computer to identify how far in the path we're able to get
successful responses from the routers in that path. So going back to our mask issue, if we think the
mask is incorrect-- because we can ping, for example, router 1, but we cannot ping the printer, and
we think it's due the IP address-- then we'd want to go to step number three, which is testing the
theory to determine the cause.
So if we think it's the mask on computer 1, we then go ahead and determine what is the next
appropriate step. Now, on an end user computer, that next appropriate step would probably be fix it.
If it's a network device, like a switch, or a router, or some other device that may impact additional
users, we would want to go through change control before we make a change.
And that way we can document what we plan on doing, what the rollback process would be in case
the change doesn't go well. We'd also want to communicate and get approved by management a
period of downtime where we can make that change. Even if we don't think that the change to a
network device-- if that's the problem we're focusing on-- even if we think it won't cause downtime,
we still want to get that window, often called a maintenance window, where we can do that work.
And if there is an issue, then the users will have been forewarned about that outage. Now, in the
event we cannot determine what the problem is, we may need to test a new theory. Or we may need
to escalate it to the right person who can. Or maybe it's a different team.
For example, if we think, hey, it's due to the firewall, and we are not the firewall team, we may need
to escalate that to the correct individuals, to the firewall team. And step number four is to establish a

plan of action and identify the potential effects.

And that would be done through change control, especially if it's to a common network device, like
a router, or firewall, or a switch. And then step number five is to implement the solution. Or, again,
if we need to escalate it, escalate it to the right team who can implement the solution.
Step number six, we want to verify that not only Bob is now working, once we make the change.
But we also want to make sure that other systems are working as well, that we haven't caused any
additional problems or issues based on the changes that we made.
And then the last step would be to document our findings, actions, and outcomes, and put them into
documentation that will be readily available the next time we have to do troubleshooting. Because
what I've discovered is that, once a problem happens, there's a good possibility that it could happen
again, especially if it's a configuration change on an end user device.
And so by documenting that, the next time Bob calls in, hopefully we'll have our record of what the
issues were in the past regarding Bob. And that could provide a faster approach to resolving the
problem, when it happens a subsequent time. In this Nugget, we've take a look at the Blueprint for
Network+'s approach to troubleshooting.
Although there are lots of great ideas on this page and in this Blueprint, you probably want to have
the order of those items memorized. So that if you're asked, what is the very next step in some
process, for example troubleshooting, you could easily tell them, based on their Blueprint, what
they're looking for.
Troubleshooting Copper Cable
Hey, Doctor, it hurts when I stomp my right foot on the ground really, really hard like this-- boom!
boom! boom! boom! And the doctor says, well, stop doing that! In our cabling plans most of the
problems that we have can be resolved by simply not doing it.
For example, if we're going to terminate a cable incorrectly, how do you solve that? Well, you
terminate it correctly. You follow the standards. And in this Nugget I wanted to chat with you about
several issues that can come up regarding copper cabling, and for most of them the resolution is
simply to follow the standards.
Let's begin. I remember someone once telling me that if mama's not happy or the wife isn't happy,

ain't nobody happy. And very similar to that in the world of a TCP/IP protocol stack, if layer 1 isn't
happy, there's no possible success for the rest of the stack.
Because in order to communicate successfully over the network, we have to have success at layer 1.
And as I look at this list of all these things that could go wrong with copper cabling, many of these
things we have already discussed. For example, if we have incorrect termination at one or both ends
of our cabling, we could have a short-- which is a connection between two pins or two wires that
should not be there, one on each end.
And the opposite, of course, is an open. With an open we're expecting to have a connection, but
there isn't one. And we're going to get shorts and opens when we have incorrect termination. And
one of those mistakes is we could have 568A on one side and 568B on the other side. Now there's
nothing wrong with 568A on one side and 568B on the other if we're going for a crossover cable,
because that's exactly what we'll get.
And a crossover cable is used when we're connecting two like devices. For example, two switches
that we're connecting back to back with Ethernet. But for most of our connections, we are going to
want a straight-through connection, which means pin 1, 2, 3, 4, 5, 6, 7, 8 on one side of the cable
end up at pins 1, 2, 3, 4, 5, 6, 7, 8 respectively at the other end. And we can get that by doing 568A
on both ends or doing 568B on both ends. And while we're talking about cabling, I also want to talk
with you about a console cable.
A console cable is a cable we would use when we connect to the console port, for example, and a
router or a switch to manage it. So we've got our laptop. We get the blue cable. We plug it in. And a
console cable has eight wires in it, but the eight wires are rolled.
So for example pin 1 on one side goes to 8 on the other, 2 to 7, 3 to 6, 4 to 5, 5 to 4, et cetera, all the
way through. So this type of a cable, this console cable, could be referred to as a rollover cable that
we would use for console access. We're not going to use a rollover cable for Ethernet, but we could
use a rollover cable for console access directly connected from our PC with the serial port to the
console port of the device we're managing, like a switch or a router.
I'd like you to imagine a road. It's a two-lane road. They both go same direction. And we have car
one, and we have car two. And they're both going in this direction. Now hopefully, these two cars
would not interrupt each other as they are going down the same road together.
However, in car number one, if they have some really loud music-- I mean super, heavy duty loud
music-- and the windows are open, it's very likely that some of that noise, if they're right next to

each other, is going to get into this car. Just because they're so close to each other.
Now hopefully that music won't disrupt the driving ability in car number two. However, it could
potentially interrupt driver number two. That's what's known as cross-talk. In electronics, a signal
that is being sent over one wire or one circuit could impact and bleed over and be consumed by an
adjacent wire or circuit that's very near to the first one.
And as you can imagine, our wires here-- these eight wires-- they are physically close to each other.
So we would have some potential for cross-talk. But that is one of the reasons why we have the
individual twists, and why those twists are a certain number of twists per foot per pair.
And we can thank Alexander Graham Bell for coming up with the idea about how twisting wires
can help reduce the impact of cross-talk. And he is one of the first patent holders for that idea back
in 1800-something. And we still use the idea of twisting wires and using certain pairs for our
communications today on the Ethernet to help reduce the effect of cross-talk on our signals.
So if this represents 90 meters of UTP cabling and we are going to measure for cross-talk-- let's say
we're going to measure it right here-- the amount of cross-talk that we notice at this end is referred
to as near end cross-talk, and the amount of cross-talk at the far end from where we're measuring is
referred to as far end cross-talk.
Simply where the interference is happening. So that, my friend, is one of the reasons we want to be
very careful about using the exact correct specification or better when we're implementing a cable
plant. If they call for CAT6, we do not want to have anything less, such as CAT5, because the
technology and the interfaces that are connecting to that cable are expecting the cable to be up to
Another challenge that can disrupt our signals that are being sent over copper is electromagnetic
interference and radio frequency interference. For example, we have Bob right here, and this is
Bob's computer. Bob has an unshielded twisted pair cable that goes over to the switch.
And as we know, we may be using some patch cables that connect to RJ45 jacks in offices and in
the wiring closet and the IDF. We may have a patch panel and be using a patch cable between the
switch and that patch panel. But at the end of the day, we have a connection from Bob over to the
And hopefully we're meeting the standards that are required for the technology-- for example, CAT5

or CAT6 all the way, end to end. Well, the horizontal run here that goes-- for example, maybe it's in
the ceiling-- is next to some lights. Now lights, depending on the type of lights they are, may or may
not interrupt signals on a network.
For example, if these are fluorescent lights-- I'll put FL for short, because I can't spell fluorescent,
not without looking it up-- and there's a ballast that's associated with those fluorescent lights, if the
cables are run too close, there could be some electromagnetic interference being generated by that
ballast on the lighting system that could interfere with our signals.
Other things that would do it would be a motor. For example, maybe this cable run is in the floor,
and the cleaning people are coming through and they're using vacuums. And the motor in the
vacuum as it crosses this section impacts the signals that are being sent at that moment due to the
electromagnetic interference.
And with radio frequency interference, that could interrupt our copper cabling as well. However, it's
more likely to have a bigger impact in the wireless space. And the key word in both of those is
"interference." It's signals that are interfering with the signals that we're using for our network
And one way of protecting against that would be to run our cabling, have our cable plant, so that we
don't have it going near other sources of significant electricity. For example, we're avoiding going
by the ballasts for the lighting system. Or with the cable system we're avoiding going by the
generators or the refrigeration unit or any other fair size motor that might cause interference due to
EMI-- Electromagnetic Interference.
If we've decided to ignore the standards and run our cabling longer than the specification-- which
for Ethernet, for most of our ethernet technologies, it's 100 meters total between the interface on the
device that's connected to the switch and the switch port itself.
And one of the reasons is attenuation. For example, I'd like you to imagine that you and I are
standing facing each other, and then we start walking backwards. You walk away from me. I'm
walking away from you. And we're still talking. And as I'm talking, my voice is getting softer and
softer-- not because I'm speaking softer, but because my voice is attenuating over the airways.
And that's an example of voice attenuation, or getting weaker, due to the increased space or distance
between us. And with electrical signals-- and this also goes for radio frequency as well-- there is
attenuation. The further that signal is going to be sent, there's degradation of that signal.

And sometimes that's referred to as dB loss, and dB stands for decibel. And although we're talking
about copper cabling, just for a moment let's take wireless into consideration. If we have an access
point-- let's say we have one milliwatt of power that we are generating.
When a customer tunes in or starts listening to that signal, they are not going to get that one
milliwatt's worth of power. There's going to be some loss. Maybe the loss is 30, or the loss is 60, or
the loss is 90. And that's why in a wireless when we see those numbers, those represent the loss in
decibels based on a perfect and original signal.
So attenuation and dB loss is the concept of a signal getting weaker and weaker the further it goes.
If we have a bad connector, that can certainly cause us problems. So for example, maybe this RJ45
connector with pin 1 right here, maybe when it was crimped, pin number 2, which we are definitely
using in our Ethernet, maybe that didn't get crimped all the way down so it made contact with the
copper wire for-- in this implementation-- the green wire.
I can just physically see that right here. Or maybe the RJ45 connector was missing the pin for 6. So
pin number 6 right here was completely gone. Maybe the person who's crimping it just didn't notice
it, didn't do a visual inspection. And as a result, there is no pin there at all.
That would be another example of a bad connector. If the wiring itself is bad, of course, that would
also cause us problems. And the trick is, when we're doing cable testing-- very likely using
something like a cable tester to do that-- we don't know exactly what's causing the problem,
We just can identify that the problem exists. For example there might be an open or a short, and
then we can start investigating. OK. Let's take a look at the termination at both ends of this cable. If
that's the problem, then we correct it. Or if we're suspicious of termination being the issue, maybe
we re-terminate the end of the cable and put a new connector on there just to verify that we have a
correct termination on that end of the cable.
And also there are some testing devices like a TDR, which stands for a Time Domain
Reflectometer. It's a fancy way for saying it can actually determine how far in-- for example, how
many meters into the cabling-- is there a significant problem, or a kink.
Because the signals are bouncing back differently from that point. Another thing that could cause us
a problem is a split pair. Now what is a split pair? Well, we know we're using pins 1, 2, 3, and 6 for

the sending and receiving of data on an Ethernet network.

And pins 1 and 2 are using the wires of white, green, and green. And pins 3 and 6 are using the
white, orange, and orange. So what would happen if for pins 1, 2, 3, and 6 we use solid green, blue,
orange and brown? Our cable tester would show us that we have connectivity for pins 1, 2, 3, and 6
from end to end. However, a cable tester that's also testing for things like cross-talk is going to be
able to make us aware that cross-talk is a problem.
That's because we're using split pairs. We're using one wire from each pair and not leveraging the
twist in the other half of that pair which helps reduce and mitigate the problem of cross-talk in our
unshielded twisted pair. If we have termination incorrect, and we have the transmit wired up to the
receive side, that's a problem.
Unless it's intended. For example, if we have two like devices and we're setting up a crossover
cable, setting up the transmit of one side to the receive of the other-- that's perfect. However if we
have a problem with the termination where it simply isn't terminated correctly, it's very likely that
that cable is not going to work for us.
Now I also should make you aware of this: some devices are really smart. And what they do is they
have this thing called auto index where they'll automatically determine or identify the type of
cable-- whether it's a crossover or a straight-through-- and they will adapt for that.
And those can be pretty tricky to troubleshoot, because you put a cable in-- it's a crossover-- and it
works. You put a straight-through cable in, and it works. And you scratch your head and say, what?
One of these shouldn't be working. But for the purpose of Network Plus, you can just pretend that
that doesn't exist.
Either the cable is correct, or it's not. And if it's not correct, you want to go ahead and terminate it in
a fashion to make it correct. We talked about cable placement and making sure we avoid things like
generators and other devices that might introduce electromagnetic interference.
Most companies are going to have some type of a cable tray for the management of the cables. So
they're all nice and organized. Also, one of the benefits of having a cable tray is that from the patch
panel we're going to have some connections that go out to the floor.
Those would be our horizontal runs. And then we're going to have some cable that go up or down or
both that connect the patch panel to the MDF, the Main Distribution Frame. One of the benefits of

using cable trays as we work with these cables-- whether they're fiber optic going north and south,
or copper cables like unshielded twisted pair-- having cable trays can first of all keep those cables
off the floor.
And also, once those cables are in the cable trays, they're also hopefully going to be undisturbed. So
there should be a reduction of people for example pulling on them or bending them. Because
whether you're fiber optic cable or unshielded twisted pair, no cable likes to be abused.
If we bend it too far, we can harm the ability for that cable to carry its appropriate signals, whether
they're light or electrical signals. And with fiber there's specifications regarding what the maximum
bend can be and still be in tolerance. So we want to make sure that we identify what that maximum
bend is, and then use cable trays and racks and so forth to stay in place and to be protected against
the humans.
In our Nugget on UTP cabling and how it goes into the building, we touched on the idea of an
adapter that can go in a switch to adapt that switch to use certain types of cabling. For example, the
newer switches have an SFP port. And that stands for Small Form Factor Pluggable.
And the benefit is you can buy a switch, and then usually it's on the right hand side, the front right
hand side, they have a few of these ports. You buy the adapter. You plug it into one of those ports,
and then that adapter is built specifically to terminate copper or terminate fiber.
And if that SFP is specifically for fiber, it would be for a specific type of termination. For example,
an LC connector with fiber. Or if you have an older switch, it may have these larger ports. This
would not be on the same switch because they're either going to have SFPs or GBICs, but usually
not both.
But on the older ones they have these GBICs, and GBIC stands for Gigabit Interface Converter. It's
a lot like the grandfather version of the SFP. It is a little bit bigger and bulkier, but we plug it into
our GBIC port on our switch, and then from that we go ahead and use it to connect to the type of
media it was built for.
And if the GBIC we purchased was for fiber, it would also be for a specific type of fiber
termination. So SFPs and GBICs are examples of transceivers: they both transmit and receive. And
for the point of this discussion, if we have a bad GBIC or a bad SFP that is broken or misbehaving
or not working correctly, that also could cause us problems with our layer 1 connectivity.
Troubleshooting Fiber Cable

In this Nugget you and I are going to take a look at common fiber cabling issues and what we can
do to help prevent them from occurring. Let's begin. I remember watching a skit with Bob Newhart
who played the role of a psychologist in this skit, and the patient comes in and says, "Doctor, I'm
afraid of being buried alive in a box."
And Bob Newhart says, I've got two words for you-- you may want to write them down, here they
go-- "Stop it." And that was his coaching for this woman-- just stop it. And most of the challenges
that we could have in a wired environment whether it's cabling for copper or whether it's cabling for
fiber optics, if we follow the standards and avoid a few things it's very likely you could have tons of
One example that might cause us grief is using the correct SFP or GBIC. Now we've discussed
those little adapters in a previous Nugget. Here's an example of an SFP. And here as well. And
based on the type of cabling we're using, there's going to be specifications for the type of SFP that
we're going to use.
And there's more than just one type of SFP. So if we have the incorrect GBIC or SFP based on the
type of cabling that were using-- the fiber optic cable-- that indeed could cause a problem. So the
solution-- stop it. Use the correct type of SFP based on the type of fiber optic cable that is being
Also, if we have an adapter that is bad-- a bad SFP or a bad GBIC-- that also could cause a problem
with our layer 1 connectivity using that fiber. And just like in copper, any time we send a signal
there is going to be attenuation-- there's going to be a degradation of that signal the further it
Now it's possible with certain types of fiber optic cabling and the correct technologies driving the
light, that we could send a signal for dozens and dozens of kilometers. Which is a lot farther than
copper, but at the end of the day, we can still only send it so far because the signal will attenuate as
it goes further and further down the cable.
So that brings us down here to distance limitations. If we try to run fiber optics further than it's
specification allows for, that could certainly introduce problems at layer 1. Now bending a fiber
optic cable-- if you take a look at these pictures right here, we have two examples of some fiber

Perhaps one is multi-mode and one is single mode fiber, and it looks like we've got some bends
here. Well the fact of the matter is they can bend to a certain degree without harm, however they
can't be bent at a 180 degree angle at a specific point. For example if we took a fiber cable and went
like this and then bent it back right here, that bend radius is way beyond the specifications, I'm sure,
for that fiber optic cable.
So in our vertical runs where it's very likely many companies are using fiber optics, there very well
maybe some conduit. Now the cool thing about fiber optics is that we don't need to worry too much
about electromagnetic interference because we're sending light frequency and we're not using
So issues like crosstalk and so forth don't apply to our fiber optics. However we still may put them
into a conduit, whether it's metal or PVC, just to keep them organized as those vertical runs are in
place between the MDF and our wiring closets. It's also likely that we'd have cable trays and other
cable management systems.
Not only to keep those cables in place but to also keep those cables out of harm's way from the
humans. For example, every time somebody goes into a wiring closet, if there's cables on the floor
or there's cables that are not marked correctly and an administrator, for example, trips on a cable, or
pulls on a cable, or removes the incorrect cable.
All of those can have negative impact on our networks. So by using cable trays and proper cable
management we can maintain the fact that we're not going to bend our cables or put too much stress
on those cables. And hopefully when we had the cable plant implemented, it was implemented by
an installer who was certifying each of those runs and providing a warranty for each of those cables
assuming that we haven't done anything else to for example, yank or bend or harm the cable
structure that's in place.
Now when I was in school I learned about different colors of light. For example the acronym I
remember is Roy G Biv as the name of an individual that can help us remember the colors of light-red, orange, yellow, green, blue, indigo, violet. And as time marches on and technology gets better,
maybe that's the same now or not.
For example we got rid of Pluto, it's no longer officially a planet. Maybe one of these colors also
got wiped, I don't know. In any event the reality of these different colors are based on different
frequencies. And light, indeed, can be sent at different frequencies.
And there's different cabling types to support the different types of signals being sent. So we'd want

to make sure that whatever technology we're using for fiber optics, we have the correct cable-- the
fiber optic cable-- used for that implementation. So in short, not just any fiber optic cable will work
with any fiber optic terminator in any SFP that plugs into any switch.
Everything has to be aligned within tolerances so that all those components are working together to
support the successful communication over that fiber cable. So if we have a connector mismatch,
for example we're using the wrong type of connector based on the type of cabling or it's the
incorrect termination for the type of frequency that we're going to be using on that fiber optic cable,
everything should be aligned to work directly for the technology that we're implementing on the
If we have a dirty connector where the light can't correctly get through. For example at the
termination, if it's not spliced or implemented correctly that also could damage the signals as signals
are being sent to and from using the pair of fiber optic cables between the two devices that are using
the fiber optics.
And a fiber type mismatch can also cause us grief. For example if we're using an implementation
that calls for single mode fiber and we're using multi-mode fiber instead or if we're using multimodal but we simply have the wrong spec for multi-mode because there's lots of different flavors of
multi-mode that we can use that could also cause us grief.
So at the end of the day, we'd want to have a cable plant that's implemented based on the
specifications. We'd want to have it certified. And then using techniques like cable trays and
conduits to protect our cabling from things like being bent or pulled on or kicked that can help us to
protect our physical implementation of our cable plant.
And if we've hired a certified company to implement that for us, and we've followed all the vendor
specifications as well, that will correct most of these issues that are listed on this page. In this
Nugget you and I have looked at common fiber cable issues and the resolution for them.
And the big part of that is if we stay in spec-- we follow the specifications regarding the types of
connectors, the type of cables, and we make sure cables are protected meaning that they're not
pulled or bent beyond their specifications-- we could have a good solid implementation of fiber for
layer 1. I'm glad you joined me for this Nugget.
CLI Tools for Troubleshooting
In this Nugget, we get to walk through a troubleshooting scenario, and we're going to leverage

several command line tools as we verify and troubleshoot connectivity issues on a network. Let's
begin. Someone once said that if the only tool we have is a hammer, we're going to approach every
problem like it's a nail.
And there's a lot of truth in that. Now, if there's a problem on the network, all we really want is the
ability to find out what's going on as quickly as possible and then take the steps towards resolving
the problem. And as we take a look at these tools that we might use at the command line of a
Windows or Linux operating system respectively, what I thought would be really effective for you
and I is to create a troubleshooting scenario or walk through a troubleshooting scenario where we
could use most of these commands.
So here's the situation. Bob, our favor user here at Computer 2 on Windows 8.1 is complaining that
he can't reach and access an internet server over here. In our investigation, we've also talked to a
user at Computer number 1, which is running Linux, and it can get to the internet no problem.
So let's preview some of the commands that we're going to be using. Ipconfig or ipconfig/all is a
fantastic command that we can use to run on a Windows computer to see the details of its IP
address, the default gateway, the DNS, and so forth. Netstat is a command that we can use on a
Linux or a Windows computer that will show us open ports that are currently listening or active on
that system.
Ifconfig is a command that on a Linux box we can use to see the IP address on that system. We
could also use netstat on a Linux box with the option of -rn, and on a Linux box, that will reveal our
default gateway. We could also use ping. Now, ping originally was created for IP version 4.
However, since IPv6 came out, there's also flavors of ping that support IPv6 as well if we're running
IPv6. So we might have ping6 or ping space dash 6, depending on how it's implemented on the
operating system that we're running.
We also have traceroute in several different flavors. On Windows, it would be tracert. On Linux it
would be traceroute. On a Cisco router or switch, it would be traceroute as well. And then there's
also the flavors of that command that are set up to work with IPv6 as well. On a Windows box,
there's nbtstat, which was designed on the Microsoft system to assist us in resolving NetBIOS name
Nslookup can be used when we're working with DNS. We can use it for troubleshooting, why we
can't resolve a name like bubba.com to its associated IP address. Arp is a great command that we
can use to look at the ARP cache on a local system. And that's really important, because if we
cannot resolve the Layer 3 to Layer 2 mapping for the next device that needs to receive our frame,
we won't be able to encapsulate that Layer 2 destination address at Layer 2 and forward the frame.

So looking at the ARP cache can give us an insight as to whether or not the local system has been
able to resolve the Layer 3 to Layer 2 address. Now, the mac address lookup table is a technique
that we would use on the switch itself.
So the switch is going to be memorizing MAC addresses due to every time a frame comes in on a
switchport, the switch looks at the source MAC address, and the switchport then says, oh, I now
know how to reach that Layer 2 address. Because the source address came in on this port, that's the
port I would use if I need to forward a frame to that MAC address.
And then we have pathping. Pathping is a Windows command. It kind of combines ping and
traceroute into one command that we can use to verify the path that a packet is taking as it goes
across the network. So since is Bob is the one complaining that he can't access the internet, let's go
to Computer 2 running Windows 8.1. And then we'll go to Computer 1, which is running a flavor of
And both of those devices should be associated with VLAN 1, along with the IP subnet of, which we've used on VLAN 1 in this portion of our network. So here on Computer 2,
let's run ipconfig and verify it's got an IP address. And sure enough, it does, with a 16-bit
mask. That looks good.
And the default gateway is And if we issue the command ipconfig/all, so I'll use the up
arrow key and add the /all to it, that can help in verifying several things. Number one, we're not
using DHCP. It's been statically configured. There's the IP address and mask and default gateway
that we saw before.
There is the DNS server. And there is the Layer 2 address associated with this interface that ends in
CF-93. I'll go ahead and clear the screen. If we use the command netstat, I'm going to throw in there
-a for all. That will show us all the open ports currently on the system.
So as far as TCP for IPv4, it's got open port 135 and 139. It's got 3389, which is RDP. And it has
several others as well that are open. However, it does not have any connections to any outside
devices. So it's like that song, (SINGING) dancing with myself, dan-dan-dan-dancing with myself.
So it has open and listening ports, but he's not actually connected to any other device, just himself.
And we can tell that based on the foreign address over here. That's the name of this device itself. So
if we wanted to test a ping, let's do a ping out to And what we're doing here is we're just
verifying what Bob has told us, that he doesn't have connectivity to the outside world.

Let's try pinging the default gateway. So we'll do a ping out to And that is really bad. So
what are the possibilities here? Well, maybe the router is having a major problem and no one can
get out to the internet. However, if that was true, then PC 1, the guy that we're running Linux,
wouldn't be able to get out.
So here on our Windows computer, let's do an arp -a to take a look at the ARP cache. And you'll
notice we do not have a ARP entry for our default gateway, which is So PC 2 cannot even
get to his default gateway. The ARP resolution never successfully completed between PC 2 and its
default gateway. So what we might want to do is make sure we have a good patch cable going from
this PC to the wall jack and verify from the wall jack to the wiring closet to the patch panel and then
from the patch panel to the switch that we have all good connections.
We might use a cable tester, for example, to verify that cable run. Now, because when we did an
ipconfig, the IP information showed up, that also implies that the interface is not disabled. For
example, we'll right-click on the interface and select Disable.
We'll go back to the command line. We'll do our ipconfig. You'll notice now ipconfig, because we
don't have an active interface, gives us nothing, specifically nothing about that interface that's down.
So because I just caused that problem, let me go ahead and bring it back up.
I'll right-click on the interface, enable it. Because it's statically configured, we don't need to worry
about DHCP, because we're not using a DHCP service. To get an IP address on this device, we'll go
back to the command line and we'll use the up arrow key and just verify that, once again, we do
indeed have an IP address.
Next let's go over to Computer number 1, we should be in the same subnet as Computer 2, and
verify if Computer 1 has access out to the internet and to the router. And in the process of doing
that, we can verify a few Linux-based commands as well. Here at PC number 1, the Computer
number 1, I'm running a flavor of Linux.
Now, this happens to be a fairly dangerous version of Linux. It's called Kali Linux. And it is chock
full of attack tools. And if you have a desire to learn more about, for example, penetration testing
and hacking tools using Kali Linux or BackTrack, I would encourage you to check out this course,
Penetration Testing with Linux Tools.
The course has 40 videos in it, and it walks you through many of the tools that are part of the Kali

Linux and BackTrack Linux distributions. So once you're done with Network Plus, and you want to
pursue additional security-related videos, I would go ahead and recommend you add this one to
your list.
However, for now, we're just using this Kali Linux box as an example of a Linux workstation that's
sitting in VLAN 1. And on VLAN 1, we're using the network. To verify the IP address
on a Linux box, we'd use the command ifconfig. So ifconfig is showing us the hardware address,
the Layer 2 address, the current IP address that we're using, which is, and also the mask,
which indicates we're using a 16-bit network mask. It also is showing us a loopback address.
And in computers on IP version 4, anything that starts with 127 is a reserved IP address space that
represents the computer itself. So this Linux box thinks that 127-anything is itself. Now, one thing
about the ifconfig command, it's not showing us the default gateway.
And on a Windows computer ipconfig, it would show us the default gateway. So if we want to see
the default gateway information, there's several ways of doing it on Linux. One is to use the
command netstat dash rn, as in Registered Nurse. And we'll press Enter.
And that's going to show us the routing table. And this is reflecting our default gateway at
So there's the route, the, and our default gateway for that is Another way on Linux
to see that same information is to use the command route dash n.
And that will also show us the same exact information. And if that weren't enough, there's one other
way. We could do an ip route show. And that will also show us our default route. So right here, it's
saying that the default route is via Ehternet0, meaning we'd use our Ethernet0 interface on
this device to forward over to our default gateway.
Now on this Linux box, let's see if we can ping out to That's the IP address out on the
internet of one of Google's DNS servers. That is working. Now on Linux, to stop the ping, we do a
Control-C. Otherwise, it will just ping indefinitely. And we could also do a traceroute.
So on a Linux box, we'd spell out the whole word traceroute. On Windows it would be trace rt. And
on Linux, I'm going to use a dash n to say, don't bother doing name resolution for each hop in the
path. And we'll go out to and press Enter. So in our path, we have, which is Router
1. Then we have, which is the firewall,, which is Router 2,, which
is our service provider. Then we start going through our service provider's network.

Then we hit a global address on one of the internet routers. And that continues until we hit the final
destination of So, great-- PC number 1, our Linux box, has connectivity to the internet. And
so here, if we did an ARP dash a, which is the same command we'd use on a Windows box to locate
the ARP cache, we should see that this computer has resolved the Layer 2 address of its default
So this computer is saying, to reach, his MAC address, or the MAC address that maps to
that address, is this guy right here. And that just so happens to be the Layer 2 interface address of
the default gateway's interface. And this Linux box learned about that via Address Resolution
And just for grins, let's see whether or not we can ping, which is the IP address of PC
number 2. And I'll go ahead and do a Control-C to stop that. And it doesn't surprise me that that's
not working. So PC 1 cannot ping PC 2. So if we go back to our diagram, Computer 1 successfully
is able to reach the router and the internet.
And Computer 2 can't even reach this default gateway. Put a big X there. And Computer 1 was not
able to go ahead and ping Computer number 2, either. So I think our fault domain, or where this
problem is isolated to, is somewhere here on Computer 2. It could be the cable that's going between
Computer 2 and the switch. It could be a problem with the configuration of the switch port on
Switch 2 that Computer 2 is connected to. So we might want to do some investigation there at the
switch first and this cable just to verify everything is in order there.
So let's make a road trip and go visit the command line interface, the CLI, of Switch number 2. And
this port where Computer 2 is connected is Port 1/2 on Switch number 2. So here on Switch number
2, let's issue a command to look at the details for Fast Ethernet 1/2. That's the port where PC 2 is
connected. This is indicating that the Ethernet interface is up and up.
Sometimes we think of that as, for example, being Layers 1 and 2, respectively. And the fact that it's
up and up is a great sign. If it said it's administratively down or one of these had been down, then
we could start taking a look at the details for that port, as well as the cable that's connecting the PC
2 to this port. So the first up here implies that we don't have this port administratively, or
configured, to be shut down.
And the line protocol, the second up, is referring to the fact that we're receiving a link signal from
the device at the other end of this switch port. So for example, PC 2 connected over the unshielded
twisted pair is on, powered up. And the switch is sensing that there are signals and that that link is
up, coming from that device at the other end.

It also indicates here that we have full-duplex associated with this port, which is great so we can
send and receive simultaneously, and that the port is currently operating at 100 megabits per second.
So nothing here in this interface output indicates that there's a problem on the switch for Port Fast
Ethernet 1/2 from a speed, duplex, or up perspective. Another question then we could ask of this
switch is, please show us the MAC addresses that you've learned and that you know about.
So the syntax here is going to vary a little bit based on the vendor. But it's the output that I'd like to
focus on. So the switch is saying, I know about this MAC address that I've learned on the
EtherChannel, Port Channel number 1, and I know about this MAC address that ends in CF93.
Now, that's the last four digits of the MAC address for our Windows 8 computer. So it says it
dynamically learned about that address on Fast Ethernet 1/2, which is the absolute correct port. But
I notice here that it thinks that MAC address is associated with VLAN 2, and that is a problem,
because all of the devices on Switch 1 and 2 should be associated with VLAN 1. And if somehow
this port, Fast Ethernet 1/2 got assigned to VLAN 2, that would explain why PC number 2, which is
connected to this port on the switch, isn't having any success in talking to anyone else.
Because he's all by himself. So another command that we could issue is show interface status. That
could show us the status of the interfaces on the switch and the VLAN assignment that they have.
And again, it's the output here, the logic, that I am concerned that we talk about together.
So here, for Fast Ethernet 1/2, we show as connected. That's great. And sure enough, the VLAN
assignment is, too. They auto-negotiated full-duplex. They auto-negotiated the speed of 100. But the
VLAN configuration on that port is in error. The port assignment for that port should be assigned to
VLAN 1, not VLAN 2. So we would want to correct that.
So we'll go into configuration mode on this Cisco device, this switch. And we'll go to interface Fast
Ethernet 1/2, that area, if you will, of the configuration for this device. And now any commands we
put here will apply to this port on the switch. And what we want to do is we want to assign this port
as being associated with VLAN 1. So now that we've done that, this port is now associated with
VLAN 1 and not all by itself in VLAN 2. So now that PC 2 has joined the party and is in the same
VLAN as its default gateway and the same VLAN as PC 1, there should be connectivity between
So if we go back to our Windows computer, and here on the Windows computer, let's use the IP
config command again. So, great, the IP address hasn't changed. We're still at .105. And now let's
try to ping out to the internet, which is one of Google's DNS servers out on the internet.

And we have success. We have four out of four, which is perfect. So now if we took a look at the
ARP cache with arp -a, it should show us that it has successfully resolved the Layer 2 address. It
knows what that Layer 2 address is of its default gateway at Because now that it's the same
VLAN as the default gateway, when the ARP request was sent, which is sent to a Layer 2
destination broadcast address, the router could now see it because it's in the same VLAN.
And then once it sees the request, it responded back to PC number 2 with the Layer 2 address of the
default gateway. If we did a traceroute -d-- and a dash d on a Windows platform simply says, please
don't bother doing the name resolution. And we'll do our traceroute all the way out to We
should have the hops involved between us, the Windows computer, and the IP address. And
sure enough, that trace was successful.
And since it was successful, let's also demonstrate pathping. So we'll type in pathping to the same
destination of Press Enter. It's attempting to do DNS resolution on each hop in the path. In
fact, I'm going to do a Control-C to stop that. I'll type in pathping.
Just press Enter. And that triggers the help output so we can see what the options are. And this says
we can also use -n here to not resolve the addresses to hostnames. So, great, we'll do that to save a
little bit of time. So I'll hit the up arrow key to do pathping again, -n.
And we'll go to and press Enter. So that's yet another way, besides tracert on a Windows
computer, to verify the path that our packets are taking through the network. If we wanted to verify
that DNS is working, we could use nslookup. Or we could just ping some device by its name and
verify that name resolution is working.
And that would give us the IP addresses that are associated with www.google.com. And if we
opened up a browser, and then it's going to let it go to the default homepage, which should open up
quite a bit of stuff, and then we did a netstat -a, we're going to have a boatload of connections in
And even though it was continuing to build a list, I did a Control-C to stop the output just to show
that this is our local IP address of These are our source ports that we were using. And
we were going to port 443, which is the well-known port for HTTPS.
And the output of netstat is simply showing us the services associated with those well-known ports.
And notice over here we have the keyword established, indicating we have an established TCP
session between our local device and several remote servers at these IP addresses.

and these port numbers. Another command, while we're here, is nbtstat. If we just type in nbtstat
and press Enter, it will give us a list of the options we can use. One of those is dash capital A, and
that says we can put in the IP address of a machine. I'll put in, which is the IP address of
this Windows machine itself.
I'll press Enter, and it will show us the NetBIOS name table for this machine. So this computer is a
member of a workgroup called WORKGROUP. That's the computer name, NETPLUSWIN8. of the
computer itself. And there's the Layer 2 MAC address on the interface of this computer.
In this Nugget, we had the opportunity to walk through a troubleshooting scenario using many
command line interface tools, from both a Windows device, a Linux device, as well as a switch to
look at the MAC address table on that switch. I am glad that you joined me for this Nugget.
Troubleshooting Tools
In this Nugget, we're going to take a look at some additional tools that we can hook onto our utility
belt and use them to assist us in troubleshooting various network issues. Let's begin. I'd like to talk
with you about some really cool tools that I still smile when I see, because they remind me of my
early days, back in the early '80s when I first got into networking and started using some of these
It was a lot of fun then, and it can still be very useful now to be familiar with these tools. One of our
basic tools is a multimeter. And here's a picture of one right here. And the reason they call it a
multimeter is because it has the ability to measure multiple things, including voltage levels, as well
as current.
There's also the ability to do a continuity test. So here's end A and here's end B. And we were
looking at both ends of the cables. We could go ahead and send it to Continuity Test, put one lead
on this end, put the other lead on that end. And then if there's continuity, it's like the Monty Python
skit about the machine that goes "bing."
Except it goes "beeep" when there's continuity. So it's a great way to verify, if you have both ends of
a cable, that pin-- for example, pin one goes to pin one on the other side. Now, you could also look
at-- if it's unshielded twisted pair, you could look at the actual RJ45 termination, look at the colors
as well to see if the right wire's there.
And then you could also verify a continuity between the pins. For example, pin one on one side and

pin one on the other, if it's a straight-through cable, by using the continuity test on the multimeter.
Now, a line tester-- when I think of line tester, I think of a tug-of-war.
And in that tug-of-war, we're testing this line. I know in tug-of-war, we're to win to see which team
wins. But whenever I think line tester, I often think of tug-of-war. But a line tester's a very handy
tool. And now it also depends on the type of line that we're testing.
If we're working on, for example, a telephone line where a circuit isn't going all the way through,
we might have what's called a butt set, where it can clamp onto the individual wire. Then a
technician could go ahead and use this butt set to further test that line.
And if we think about it, the telephone network indeed is a network as well. Another type of line
tester would be this little guy right here. This is a toner probe. And there's lots of variance for toner
probes. And as an example, let's say that Lois has been having some problems with connectivity.
And we want to verify that we have the right cable in place. So in the wiring closet, we connect this
little guy, for example, to one of the pins or one of the wires. And then we go to our cube. And right
here at the wall jack, we use this toner probe. And we simply touch each of the pins-- or if it's
exposed UTP cable, each of the wires-- and we wait for an audible sound that indicates that we are
on the same circuit, the same wire that the tone generator is creating on the other side.
Now, with unshielded twisted pair, this wouldn't be a super effective way to do that. A better way of
doing that is with little dongles that we could use that have RJ45 termination already. Here it shows
six of them. So we could plug six of them into different RJ45 jacks on the patch panel.
And then in Lois's queue, we could simply go ahead, plug our tester in, and our tester would tell us
exactly which UTP cable we're using. Is it connected to one, two, three, four, five, or six on the
back end in the wiring closet? So the earlier versions of this, it's called a toner probe, because it
generates a tone. [STEADY TONE]
or [MODULATING TONE] depending on the type of toner probe that you have. Now, this tool
here, this cable tester, also may be used to certify our cabling. So it could generate reports, for
example, regarding the length of the cables. It could also identify that we're identifying the correct
pairs of wires due to the cross talk that it senses, or, I should say, doesn't sense.
As a result, I'm using the correct pairs. And this is likely a tool that the people implementing the
cable plant would use to go through and certify the entire cable plant that they just put in place. And

then generate a report and hand that over, along with the invoice, for the work they've done.
And internally as well, for troubleshooting a problem with unshielded twisted pair, this is a great
tool to have in our arsenal. And when using a cable tester, which could also be part of our
certification for our cabling plant, the output is usually very, very readable.
For example, if we look at these pins, it shows us that we have a straight-through connection for
one, two, three, five, six, seven, eight. But we have an open right here for pin number four. There's
no connectivity between pin four on the far side and pin four on the local side.
And depending on your cable tester, it may also be able to tell you exactly how far along the path
the break is, or the open is. And that might help us in narrowing down where the problem is.
However, if we have a problem like 20 meters into a cable, it's very likely we're going to pull that
run out and put a new one in.
Or if we have additional horizontal runs that are not in use, we may just decide to use a different
UTP cable and simply not use the older one that has the problem. One of the tools that we can use
with our cabling is called a TDR, a Time Domain Reflectometer.
And it has the ability to give us an insight regarding kinks or problems with copper cable and
approximately where those are happening in that cable, as far as, like, for example, how many
meters from the testing equipment that problem is being seen. There's also a similar tool for fiber
It's called an optical time domain reflectometer. And here's an example of one right here. So
because it is measuring light, I guess we could refer to that as a light meter, as opposed to a
photographer who might be using a light meter to check the ambient light in the area.
In the purposes of our networks, we'd be using a light meter for the verification and/or
troubleshooting of our fiber optics. If a network seems slow, it's often a great thing to have a
baseline in place regarding what, quote, unquote, normal looks like. And using some type of a
measuring stick is helpful.
Now, there's lots of public ones, like speedtest.net that are available on the internet. But there's also
lots of verification tools that we can use inside of our network, depending on your vendor, that can
help us to measure, over time, what the typical throughput is from point A to point Z. So as an
example of a publicly available speed test

tool, this is speedtest.net. I'm going to click on Begin Test. It's going to find a relatively close server.
I happen to be in Las Vegas, Nevada. And then it's going to run the test. So it's doing a quick ping,
and then it does a download test. And then it's going to follow that up by an upload test.
So not bad. 41 megabits per second, download; and 22 megabits per second, up. So by creating a
baseline of what normal looks like or feels like during various times of the day, in the future, if we
start having problems, we can run this test again, compare it against the baseline for that time of
That could help us indicate that there is a problem or at least a slowdown somewhere in the system.
It could be a router. It could be a server. It could be the PC. Or it could be a combination of those
factors. Now, to aid us in troubleshooting, there's additional tools such as looking glasses that are
out there on the internet that can provide us an additional insight regarding connectivity over the
So you can kind of think about looking glass like a peephole into the network. And one of the cool
things about a looking glass is that it gives us an insight from a different perspective. For example,
in routing protocols on the internet, we use BGP, the Border Gateway Protocol.
And there's looking glasses specifically for BGP. So we could take a look at the routes and the
routing that's happening on the internet from this service provider's perspective based on the service
provider who's making the looking glass available. This looking glass, which is provided by Cogent
Communications, gives the ability to specify the test that we want to run, the router location that we
want to run the test from.
And then we can go ahead and hit a target address. So if we're interested in the connectivity, for
example, from a different part of the world regarding traffic that's coming into our networks, we
could use a tool like this to verify that. So for the test, from the dropdown, we have pings for IPv4
and IPv6. And we have traces for IPv4 and IPv6 as well as BGP. So as an example, let's do an IP
version 4 trace. We'll select our router location.
And we have quite a selection here. I'm going to go ahead and select Brussels as the router location
for the source. And for the host, or IP address, I'm going to use my outside IP address for a moment.
Now, there's lots of fun ways of identifying what the outsider global IP address that we're currently
being translated into.

So as far as the world knows, this is the IP address that I am appearing as right now. And that very
likely will change over time. And then we'll go back to our looking glass, and we'll say that is the
target we're trying to reach. I'll paste that in. So this will do a trace from a router in Brussels to this
IP address, which my service provider is using for network address translation.
So we'll click on Go. And I'll scroll down a little bit. So at some point here, the routers were
unwilling. And that's OK. But it made it most of the way there. So here we have the first 10 hops.
And because of the domain name here, lvcm.net, that implies to me, along with the prefixes being
used, the network addresses being used, that that is extremely close to my IP address.
So my service provider, at one of their last few hops, they had very likely a firewall device that was
refusing to provide information back that was needed for the completion of the trace. So that's an
example of a looking glass. So if we change this, for example, and we said we wanted to do a trace
to, which is one of many Google's DNS servers, and we clicked on Go, it's going to do a
trace from that router in Brussels to And if we change the location-- for example, we try to
launch this from-- let's go ahead and launch it from Lisbon.
Let's go ahead and click on Go. And it will show us the path from the router in Lisbon over to So that's an example, a very fun example, of using a looking glass to get a different
perspective on traffic as it's crossing the internet. Another very fun tool that we are going to use
quite a bit in our networks is a Wi-Fi analyzer, a network analyzer for our wireless networks.
And we already had a little sneak-peek of this as an Android application when we discussed
wireless. And here's another flavor of 8 wireless analyzer. This one runs on a computer. And at the
moment, it shows me that I do not have any five gigahertz networks in sight.
And that's because the computer that I happen to be running this Wi-Fi analyzer on doesn't have a
five gigahertz radio. That's the reason that this is showing up empty. But over here on the left-hand
side, you can see there's lots of different wireless networks that are present.
Currently, I am using the wireless network called Barker. That's the SSID. The signal strength is
minus 46. And that's referring to the loss. So in a perfect theoretical world, if we had a loss of
nothing, zero, that would be the strongest possible signal that we could be receiving.
But due to attenuation, and walls, and distance that degrade or attenuate the signals, there's always
going to be some loss. And I have this sorted right here by signal. So based on the sorting, the most
strongest signals are shown at the top. And they go weaker as the list goes on.

It's also showing over here the technology that is currently in use. So you'll notice most of these are
n, 802.11 n. And I also have a couple g's here as well. So if we're doing troubleshooting, let's say we
have three access points-- access point one, two, and three in our building.
And they're all advertising the same SSID. For this example, let's say they're all advertising Barker.
And I've got one group of users that's complaining that, hey, I can't access the network. Or hey, my
network access is spotty and dropping off. We might want to take a look at the access point that is
specific to those users-- for example, the access point they are closest to.
And then we'd want to take a look and make sure that on that access point, we have it configured for
the right technology, whether it's b, or g, or a, or n, or ac. We'd also want to make sure that access
point, as it's plugged into one of our switches on this switch port, we'd want to make sure that
switch port was configured for full duplex and had a matching speed that matched the access point
And on the access point, we'd want to make sure the Ethernet interface there was set for full duplex
and matching the speed that was set up on the switch. And if we had, for example, access point one
and access point two that were both using channel six, as an example, and they were geographically
close to each other, and they were interfering with each other, that would be a good opportunity to
change to non-overlapping channels.
So in our business and the 2.4 gigahertz range, that would be channel 1, channel 6, or channel 11.
These channels do not interfere with each other. So on these access points, maybe you have access
point one using channel one. We have access point two using channel 6 and access point three using
channel 11. And that way, even if they had overlapping coverage, which would be a good idea, so
users can roam, they wouldn't have interfering frequencies with each other, because we are using
the non-overlapping channels.
I'm in my home office. It appears that I need to go talk to one of my neighbors, because look at this
right here. This guy is using channel four and channel eight, which means he is going all the way
here to here. Thanks, Mr. Neighbor. I appreciate you chewing up a huge swath of ranges right in the
dead center of the 2.4 gigahertz range. So no matter what I use, whether I'm at 11, which I currently
am, or whether I use 1 as my center frequency, or if I use 6, I'm always going to have some overlap
and interference with his or her access point, depending on which neighbor that is.
And in fairness, it's very likely that my neighbor has no clue that his access or her access point is
currently set up that way on their home router. Another really fun tool is a protocol analyzer. And

one that we've already looked at in this course is the Wireshark.

We've looked at output of that several times in previous Nuggets in Network+. Now, the way we
can collect data for a protocol analyzer to use is to use a technique such as port mirroring, where we
copy the data from either a port or a VLAN over to a destination where we can open that data up
and look at it with a protocol analyzer.
I remember a situation where we had the programming team-- I was on the network side and there
was a development team that was claiming our network was not allowing the communication
between a client and a server. And they somehow thought it was the network that was stopping it,
which is totally fair.
They had written the code. They thought it had worked in their lab environment. But it wasn't
working correctly as it was being deployed. So we could have had-- for example, the client would
be on one subnet, the server be on another. We could have a router that's making Layer 3 routing
decisions between those two different VLANs.
And maybe on the interfaces of the router, maybe there were some type of an access control list, or
ACL, that was preventing certain types of traffic from being able to be routed back and forth
between the client and the server. So what we did is we used a protocol analyzer, and we caught the
data here, and we captured the data here.
Then we looked at the captures inside of a protocol analyzer, so we could determine exactly what's
going on. We also looked at the router details regarding the access control list to determine if the
router was specifically denying or deleting certain types of traffic.
And after all that work, which was very valuable to do, we determined that it wasn't the network. In
fact, what they had done is they had written the client and server so that some of the traffic that
went back and forth between the client and the server was broadcast-based, meaning it would only
work if they were in the same VLAN with each other.
Because as you and I know, what happens in the VLAN regarding broadcast at Layer 2 stay in the
VLAN. So they rewrote their application to make sure it worked based on IP address, without
assuming that the client and the server would be sitting on the same subnet with each other and the
same VLAN.
And at that point, it started working, going across the router. But the point I wanted to make was

using the protocol analyzer instead of just shrugging and say, I don't know what's going on, we
could actually look at the traffic that was on the network, and then start to inspect that and analyze
that traffic using a protocol analyzer.
In this Nugget, you and I have discussed some additional tools that we can clip onto our utility bill
and use when the situation arises. I have had a lot of fun in this Nugget. I am glad that you joined
me for it. I hope this has been informative for you, and I'd like to thank you for viewing.
Troubleshooting Wireless
In this Nugget, we're going to take a look at a laundry list of issues that can come up in a wireless
environment and some of the recommendations regarding correcting those problems. Let's begin. I'd
like to first reinforce the idea that we need tools to see what's going on in that wireless space.
Just walking into an environment and thinking, gee, I wonder what the problem is is not to be very
effective unless we have the tools to solve it, for example, using a Wi-Fi analyzer. And they've got
some great applications for PCs as well as for androids.
So given a scenario, troubleshoot and resolve common wireless issues. Signal loss. Well, if you're
having signal loss, the answer is get some more. So that means either taking a user like this and
moving them closer to an access point, or increasing the power on an access point, or perhaps using
a repeater, or a bridge, or an additional access point, which is closer to the user.
If we're in a situation where we have two buildings, for example, and we simply need to go further,
we might want to choose additional antennas and the correct type of antenna-- in this case, it would
be directional antennas-- that could get the signal in a strong enough fashion to be sent and received
correctly between those two points.
Regarding interference, if there's interference, you'd want to avoid that frequency range or identify
what's causing the interference. So here, we'd be talking a lot about radio frequency interference. So
if Bob the user shows up for work one day and Bob brings his own access point in and plugs it in,
and it happens to be also using channel 11 or overlapping that frequency, that indeed could cause a
problem with the existing company wireless network.
And a huge first step of stopping interference is to identify that the interference is happening. And
because the 2.4 and the 5 gigahertz ranges are fairly open, meaning anybody can use them, there are
other devices that could also be using those frequencies.

So the key is, if you have interference due to overlapping channels or other devices that are trying
to use the same frequencies, we want to identify that it's happening, and then avoid the conflict. Or
if, for example, we had clients that only supported 2.4 gigahertz, and our access points were only up
in the 5 gigahertz range, that mismatching of channels could also cause a complete failure of a
wireless network because the clients have no interaction or capability of interacting with the access
There's also something called a signal to noise ratio. For example, even I talking right here in this
Nugget, I'm going to assume that you can hear me OK. However, if I was at this same volume and
you were not using a headset, and we took this same volume into a crowded area, let's say a
cafeteria or outside on a busy street, it'd be more challenging to hear me because of the additional
noise that's in the background.
So SNR, the signal to noise ratio, is comparing the level of the desired signal, which I'm going to be
assuming that's you wanting to hear what I have to say, the desired signal, compared to the
background noise. So in a data network, the desired signal would be the information being sent
across the media, whether it's wireless or wired, compared to the other noise that's also present in
that space.
Device saturation is about how many devices can an access point support at one given time. For
example, if we have 20 or 30 devices, and they're all making fairly significant demands, we may get
to the point where we have device saturation where an access point simply can't handle the volume.
For example, in a public area, in a school, or in a football, or a baseball stadium where they're
providing Wi-Fi. You might say, well Keith, why in the world would a football stadium want to
provide Wi-Fi? And the answer is the cellphone carriers, they know that they cannot possibly handle
all that data if everybody had to use their cell phones and the data services over the cell.
The cellphone provider will help finance the stadium to put in high speed Wi-Fi to offload some of
that demand, so that their whole network doesn't go belly up. And as part of putting in access points
for a very dense environment where there's lots of clients, wed want to consider device saturation to
make sure that we can handle the load.
Another item that can cause poor performance is bandwidth saturation. So for example, let's say we
have five or six users, and they are doing heavy duty downloads or uploads through the access
points, where try as it might, the access point simply doesn't have enough bandwidth in the
frequency range it's using to go ahead and send and receive any faster.

Or if we had an access point that could support maybe 300 megabits per second out here, but it had
a 10 megabit per second connection to the switch-- DS, by the way, stands for distribution switch
here-- that also could be an example of saturating our bandwidth.
But in this case, it would be on the wired side. I was at a user group meeting the other day, and they
were talking about updates and when we should do updates. And I raised my hand and said, you
know what? If a system is working, and there is no increased functionality that is needed, and
there's no security issues that are currently in place with the current software that's running, I
probably would not do the upgrade.
However, if there were security features that we needed or additional functionality, then in a test
environment, we would test that update, make sure it's solid, practice with it, verify it before rolling
it out to a production network. So anytime we have an update, whether it's software, firmware,
hardware, we'd want to make sure we do really solid testing in a test environment before rolling it
Now the wrong SSID is very often malicious. So for example, we have a disgruntled employee or
somebody who's just testing the waters. They bring in an access point. Let's say our SSID is CBT
Nuggets, and they bring up an access point that shows up as CBT Nugget.
And you might look at that and say, well, what's the difference? Well, this one's CBT Nuggets,
plural, and this one's singular. And maybe they're trying to capture or get somebody to connect and
associate with there rogue access point, the unauthorized access point.
So if a user connects to this unauthorized access point, there's going to be a couple of things that
happen. One, if the attacker is doing a man in the middle attack, maybe the attacker is a routing that
traffic back into the network. So that would be an MITM, a man in the middle attack.
Or maybe the attacker has created an elaborate set of shares. For example, they've got in a
virtualized space on a computer, he set up all these different shares that look like the company
shares. The folders that they can access over the network. And perhaps he's trying to get Bob to
write to or read from some of those folders.
So in the event that a user on the network sees unfamiliar shares, or they see resources that are not
usually available, it's possible that they may have associated with the incorrect SSID, the wrong
wireless network. Which could have significant security implications.

Power levels are also an issue with our access points. Now with a wireless LAN controller that is in
charge of the access points, if the wireless LAN controller knows that access point one is here and
access point two is here, it's going to make sure that does not use the same channel or overlapping
channels, because it doesn't want them to interfere with each other.
So channel six and channel 11 is perfectly fine. However, if we have access point three over here,
and its signal coverages is like this, for example, and it's using channel 11, now a better channel for
this access point three would be one. But for the purposes of discussion here, let's say it's 11.
There's some overlap right here between access point three and access point two.
So the wireless LAN controller would be aware of that, and it could modify the power levels to
bring the power level of AP3 down a little bit, so maybe it's like this now. So it's no longer in that
overlap range with another access point that's using the same frequency ranges.
And if the power level is brought down, reduced by such a factor that there's a client, for example,
right here that can no longer access the network because you can't see the signals well enough, that
could also cause a problem in our wireless network. An open network is rarely a good thing.
The open network implies there's no authentication required. Please connect and have a good day.
For example, we go to a coffee house or a restaurant that might have free Wi-Fi. Those are always
risky. So if you are sure that it's being provided by the vendor of the establishment, it's still not very
Because every else is also connected to that wireless network, and eavesdropping is very possible.
That means other people listening in on what your computer is saying on the network. So if you do
have to use an open network, one really good idea is this.
So let's say that this represents Bob's computer. He's at Starbucks, or what have you. He associates
with the access point, gets access to the internet, and his traffic is being routed up to the internet.
One really great idea is to build what's called a VPN.
That's a virtual private network. And you're going to build that, let's say, it's to headquarters. So let's
say Bob works Acme, Inc. And at Acme, Inc., they've got a device, like for example, probably a
firewall that also is acting as a VPN gateway. Bob can build this private communication channel up
to the firewall at his corporate headquarters.
And then if Bob wants to the internet, the firewall can turnaround NAT-- once again, with network

address translation-- and then forward his traffic out to the internet. So he's going out to CNN.com,
and then the reply would come back through the firewall.
And then Bob's response would go back through this virtual private network, which is totally
confidential. Anybody who's eavesdropping right here on the wireless won't be able to see the data.
Won't be able to make sense of the data, because it's all encrypted.
And only Bob and the firewall have the keys to lock and unlock that data for Bob's VPN session. So
regarding open networks , please do not use them. But when you must use them, use a virtual
private network as an overlay on top of it to protect your conversations.
A rogue access point, we've already touched on that. That is an access point that's been brought into
a corporate environment that should not be there. It's not allowed. Only the access points that are
provided by the company in that space should be allowed in that space.
And so one of the benefits of using a wireless LAN controller is that some systems have the ability
to identify quote, unquote "rogue" access points. So if John brings in an access point and it starts
broadcasting a signal, that can be identified and reported on by the access points, including in many
cases the wireless LAN controller and software in conjunction with that building a map to indicate
where the access point is, so we can triangulate it with multiple access points.
So there's the rogue access point. And these access points very often can be set up to jam. Now
interference, as we know, is usually a bad thing. However, if we're using the access points in our
infrastructure to intentionally jam a rogue access point, meaning we are purposely interfering with
the signals it's sending out, that would be one way of preventing users like Bob from connecting to
the rogue access point.
And you might ask, wow, do people really go to those lengths in corporate environments to protect
their Wi-Fi networks? And the answer is absolutely yes. If you have the wrong antenna type, that's
probably going to equate to lack of signal or a diminished signal.
So unidirectional antennae would be used for sending signals and receiving signals in a specific
direction, where an omnidirectional, for example like this access point, would go an equal
directions all the way out. If you're going between two buildings using uni-directional antennas, it
would very likely be the desired antenna for two reasons.
Number one, we want to cover the distance between the two buildings, so we're going to focus our

sending and receiving in a specific direction. And secondly, if this is our building, we don't want an
omnidirectional access point at the edge of our building simply sending signals in all directions,
because then we're just opening ourselves up for additional access by people in the parking lot, or
anywhere close to that access point, which could then give an attacker more opportunity to try to
break in and compromise our wireless network.
Another issue that could cause problems with our wireless' incompatibilities. Well, Keith, what
could possibly be incompatible? How about frequency ranges 2.4 versus 5 gigahertz? If you have
clients in one and access points in the other, that's a problem.
Or how about the 802.11 family of technologies? For example, A, or B, or G, or N, or AC? You'd
want to make sure that we had clients and access points that were compatible with the same
technology, and then use that technology for the wireless networks. Now most corporations are
going to be using encryption to encrypt the signals as they go back and forth between Bob's client
here and the access point.
And in the background what really happens is the encryption happens here, and then the access
point sends that traffic all up to the wireless LAN controller, so the wireless LAN controller can
make decisions on it, such as forwarding, routing, authentication, et cetera.
And in that wireless space, we have the encryption that's happening. There's lots of different types
of encryption that we can do. And the best type of encryption that we could do would be, one, that
is matching or compatible between the client and the access point.
So if we were using the standard of 802.11i, which is also known as WPA2, Wi-Fi protected access
version two, it uses the encryption called AES, which stands for the advanced encryption standard.
And it also, in enterprise mode, is going to use a centralized server, a AAA server for the
authentication of those users.
So if you had a client that wasn't capable of using WPA2 or AES and the access point was requiring
that, that would be another example of an incompatibility. Some technologies, including MIMO,
multiple in, multiple out, which are used by 802.11n, and we also have the multi-user MIMO, which
It does some amazing things, including using the multiple channels and multiple antennae. And
because radio frequencies do bounce off walls and other objects, it can actually leverage that as part
of its technology to make more throughput happen for the user.

However, balance in this general sense regarding a Wi-Fi signal may not be a great thing. For
example, let's say this is user Bob right here. And Bob is sitting in his cube, and in his cube there is
a wall. Now some the signals that are sent by Bob and the access point, because they both have
wireless transmitters and receivers, to participate in a wireless network, there will be some of those
signals that can penetrate and make it through the wall, and there's also going to be some that
bounce, meaning bouncing off the wall.
And hopefully, there's enough signal that goes through successfully to make it work. However, if
we have, for example, a metal filing cabinet, or we have an access point here, we have a wall here,
and we have Bob here, now that wall you might think, well, the wall's the same width all the way
But if you consider where the signal has to go like this, there's quite a depth of wall coming at an
angle that it has to go through. So that boils down to AP placement. What is in the path between the
access point and the recipient? I once saw a client that had something like this.
They had a couple of buildings, actually had several buildings. But for a couple of them, they had
access point on the top of the building. It was directional, which is great, but they were going into a
second building through a window that had the window film on it, because it is Las Vegas.
It gets really hot in here. And it was also going through an angle. I thought to myself, it's kind of
like a little miracle, that with the distance that's being covered-- they also had a tree in there. A little
pine tree. Actually quite big pine tree between the two.
It was actually amazing that the signals even made it through that far. So ideally, no obstructions
between two access points, especially if we're doing directional access points. And we'd also not
want to go through window film at an angle, because the angle, and there were no film, along with
the tree, are all going to degrade the effective signal that we can use for sending bits through our
Access points to be managed in a couple different ways. If we configure them as a thick access
point, also referred to as autonomous access point, it means to the access point is going to be
managed independently. We're not using a wireless LAN controller.
We'd simply open up a browser, connect to the access point, and configure all the details-- for
example, what frequencies are going to use, what technologies are we going to use, and so forth.

And it's called thick because the access point in Autonomous mode has to do all the work itself.
It doesn't have anybody else to rely on. It can throw frames up to the wireless LAN controller,
because there isn't one, in Autonomous mode for assistance with processing some of those
decisions. Now on the other side of the coin, we could provision an access point as being thin.
And it's called thin because it is going to rely very heavily on the wireless LAN controller for a lot
of decisions, including authentication, routing, and so forth. And we use an access point configured
with a controller, such as a wireless LAN controller, one of the protocols that was developed was
called lightweight access point protocol, LWAPP.
And Cisco has another one called CAPWAP, which in a Cisco environment would more likely be
used than the older LWAPP. So in the event where you had an enterprise environment and one of
our access points was no longer cooperating with, or working with, or reachable by the wireless
LAN controller, we may have to connect to it locally and take a look at it.
And if we see that it's configured in thick mode, or that's acting as an autonomous access point all
by itself, we would have to do a local configuration change on that access point to bring it back into
the family. Some other factors that might affect our wireless connectivity would be concrete walls.
The thicker, the more the impact is going to be. And window film, as we talked about, and window
film at an agle. So if this is the window, here's the access point up here, and here's the other device.
We'll call another access point. And they have directional antennas.
If we're going to add an angle, the window film is not going to help, and the angle is not going to
help. So ideally, we'd have both these access points not having to communicate with each other
going through any object. So if we could put them on the top of the building, line of sight, with
directional antennas, that would be a better option than shooting the signals through a window.
And metal anything is a problem for wireless. So, metal filing cabinets, metal walls, metal studs.
Those are all going to significantly impact and degrade a wireless signal. And we want to make sure
that we are using these standards when implementing our wireless.
And those standards do have limitations regarding throughput, the frequency, range, or ranges that
they use, the distance that they're able to cover, including based on what type of antenna that we're
using, and then the channels available within that band of frequencies.

In this Nugget, we've taken a look at a laundry list of some items that, if not done properly or not
done compatibly, may cause problems in our wireless networks. I have had a great time in this
Nugget. I'm glad that you joined me for it. I hope this has been informative for you, and I'd like to
thank you for viewing.
Troubleshooting Common Network Problems
In this Nugget, we'll take a look how we can identify and resolve common network issues. Let's
begin. I'd like you to imagine that you and I working at the help desk got a call from Bob, and Bob
is the user at computer two on our network. And Bob is complaining that he can't get access out to
the internet.
So we make a road trip down to this computer, and we look at the details for his computer. We
could have done it with IP config, or we could go into Control Panel under Networking and look at
the properties of the IPv4 protocol. And here's my question, which one of these-- I'll label these A
and B-- which one of these would be a workable configuration, assuming that the default gateway is
really at this address? So in situation A, the default gateway router one would be, and for
configuration B, the default gateway's address would be And I'd like you take a moment
right now and just consider which of these two configurations on computer two would be a working
So go ahead and pause me/ whether you're on a computer or a mobile device, pause me for a
moment, and I'd like you to think about that. And then when you've come up with the answer of
which one is correct, A or B, go ahead and resume me, and we'll take a look at the answer.
Now, if you've given that some thought and you've been with me through the 16 Nuggets of the
IPv4 subnetting course, you might come to the realization regarding these two configurations on
Bob's computer that both of them are wrong and cannot work. And the reason for that is that the
computer itself-- it's IP address, based on the mass-- is not on the same network as the default
In fact on a Windows 8.1 environment, if we had clicked Apply to apply this change, it would give
us a big warning, saying warning, Will Robinson, warning. The default gateway is not on your local
network. So the mask of .248-- that's one two, three, four, five bits in on that last octet.
So here's the mask, our block size-- the value of that position is 8. So our subnets are going to be in
blocks of eight. So a sub 0, subnet 8, subnet 16, subnet 24, et cetera. So the IP address here of .20 is
in the 16 subnet. That's where our 20 lives. And the default gateway of .1 is up here on the 0 subnet.

So the problem here is that the default gateway is over here, and the computer's IP addresses is here,
based on the mask.
Now to fix that, we could simply change that mask to a 0, and that would correct it, because then
they would both-- the default gateway and the PC-- be on the same subnet. And you might be
asking, wait a second, Keith. How are we putting these two computers on the same network just by
changing the mask? And really what we're doing is we're changing the attitude of PC 2, computer 2,
to make it believe that it's on the same network, because at the end of the day, each of these devices
that's connected to VLAN 1 on our switches. Their IP address is just what they believe about their
IP address.
They could have received that via DHCP or been statically configured, or misconfigured, but they
all need to agree or believe that they're on the same IP network. In this case, changing the mask to a
0 in that last octet-- or a 00, which would be more appropriate for our Flash 16-bit network-- would
be a solution to that. And the same thing is happening down here.
We have a block size of eight, and if we looked at all these different subnets, the host ending in .100
would be on a different subnet than the host ending in .110. So with this mask, the host IP address is
on a different subnet than its default gateway, which is a problem.
Now, the DNS information, that could be either local or remote. As long as we have a default
gateway, we can reach a remote DNS server no problem. So regarding the identification or
troubleshooting of a default gateway or IP address that's incorrect, one way of accomplishing that
would be to use IP config or looking at the IPv4 properties just to verify whether or not the IP
address and the default gateway are on the same subnet.
Now to accomplish-- and it really is quite a feat in today's networks-- to accomplish a broadcast
storm, where a broadcast goes into the network-- a Layer 2 broadcast-- and then loops around, and
loops, and loops, and loops. To pull that off, we would have to have at least two connections, two
parallel paths, between our switches in the same network in the same VLAN, and we would have to
just say no-- like the Nancy Reagan policy on drugt-- just say no to Spanning Tree Protocol,
because as we've previously learned in this course, Spanning Tree Protocol is there to identify
parallel paths, and then to block, so that we don't have broadcast storms.
So if you have a broadcast storm or a switching loop, that would be caused by disabling Spanning
Tree Protocol on those switches, which by the way, on an ethernet network, is a bad idea. We want
Spanning Tree there so that, in the event there are parallel paths, either accidentally or purpose, we
want to make sure we don't bring the network down due to a broadcast storm.

A duplicate IP address is a huge problem. For example, if computer 2 wanted to use this IP
address-- we'll go ahead and change the mask here to 0.0 so that the default gateway and its IP
address are on the same network. And if another computer tried to use that same exact IP address,
what's going to happen when there's an ARP, Address Resolution Protocol? And this ARP client
says, hey, I'm looking for the Layer 2 address of If two devices have the same IP address,
they both respond with the Layer 2 information. Which one is going to win? And the problem is that
one of them is going to win.
And besides the problem with ARP, we also have a problem with literally two devices having the
same address. So on every subnet, every IP address for every host has to be unique. So if we did
have a situation where we did configure a duplicate IP address, normally there will be a message
that pops up indicating, oops, there's a duplicate IP address in your network.
And one way it can happen is that DHCP is being used to assign IP addresses, and somebody on a
computer decides, hey, you know what? I'm just going to configure my IP address manually, and
they configure an IP address that's already been assigned and put in place by DHCP on another
And if we're using DHCP exclusively to hand out IP addresses, the DHCP service-- what it does in
the background-- when it hands IP addresses, it also does a ping in an attempt to verify whether or
not the IP address, which it's about to hand out, is already in use.
And if it gets a response for that ping, it'll go ahead and skip that IP address and go to the next one.
So the DHCP server by itself is taking precautions to avoid a duplicate IP address. We have taken a
look at speed and duplex several times throughout this course.
The speed referring to, for example, 10, or 100, or gigabit speed, and it should match. Whatever the
switch. Port is configured for, that should also be the same on the computer. And if we're using auto
for auto-negotiation, they should be able to auto-negotiate the best possible speed between the two
And the duplex-- unless we're going back a decade or so into the world of hubs at Layer 1, we
should be using full duplex, and that's one of the benefits of using a switch-- is that we can send and
receive simultaneously on a switchport and not have to wait to verify that no one else is sending
traffic on the network.

And if we did have a mismatch-- let's say we configure the switchport as full duplex, and it's
connected out to PC number 3. And PC number 3, for whatever reason, either failed negotiation, or
it wasn't sure, or was hard configured for half duplex. Well what happened is the switch would be
thinking, hey, I can send and receive any time I want out to this device because I'm operating a full
However, PC 3, if it's ever sending data and it sees other signals being sent at the same time, it's
going to assume that there's a problem, that there's a collision that just took place, because in half
duplex world, we believe that only one device should be talking on the network at a time.
And if two people are, it's considered a collision, very similar to two people who are both speaking
to each other at the same time. So here on the PC, if we looked at the details for the interface, we'd
very likely see lots of collisions on the interface, on the PC.
Where at the switch, we would see zero collisions. And this PC might be able to communicate fairly
well until there's lots of network traffic. And then the busier that PC 3 gets, the more collisions that
are going to happen and the worse the performance is going to be.
So maybe for two or three hours during the day during busy times, PC 3 has really bad performance
because of the duplex mismatch. And then other times of the day when there's not much traffic it
does OK. So on a Cisco switch, we would use the appropriate show commands to show the speed
and duplex as well as any counters regarding collisions that may be taking place.
And on the computer, it would depend on the type of operating system that we're running on that
computer. For end to end connectivity, a great way to test that from computer 2 going out to an
internet resource such as is-- and I want you to fill in the blank? What's a great tool that we
could use to verify end to end connectivity between point A and point Z? Now, if you're saying
things like ping, that's a great idea.
Ping is a great way to verify end to end connectivity. We issue a ping request, which gets routed
through the network all the way to the destination, and then we get an echo reply, a ping response
that comes all way back. That's great. What's another tool that we could use for end to end
connectivity testing? And if you're saying, Keith, there's trace route, and trace route is spelled
differently depending on the device you're running it on.
On Windows, it would be TRACERT. On a Linux box, it would be TRACEROUTE. And it would
also be TRACEROUTE on a Cisco switch or router. And that also can verify full connectivity as
well as the Layer 3 hops in the path to that destination. And we can actually add one more.

We also talked about an additional tool called path ping that we could also use that would verify our
connectivity as well the hops between point A and point Z. Now computer 2, if it's physically
connected to this port on the switch and that port has been assigned to VLAN 2, which we've seen
in a previous troubleshooting Nugget in this course, and all the other devices, including this default
gateway, are in VLAN 1, that's a problem. That would be example of an incorrect VLAN
assignment, and that's controlled at the switchport.
If we have a hardware failure, that certainly could cause us problems in the network. And one of the
challenges is that, what if the router itself has a hardware problem? Maybe this interface or this
interface fails. What do we do? We just basically isolated an entire subnet, entire VLAN from
getting access outside of their network.
One of the technologies that we can use is called first hop redundancy protocols, and with a first
hop redundancy protocol, we're going to have two routers instead of just one. So maybe here we
have router 1 and we also have router 11. So router 1 and router 11 would both be participating in
this VLAN that's supporting subnet, and they keep track of each other.
They're friends. If one of them goes down, the other one will take over, and the goal is to make that
transparent to the rest of the network. So if there's a physical failure, a single point of failure in the
network, hopefully our 11 can continue forwarding the packets.
If we have a misconfigured dynamic host configuration protocol server, that would imply that the
DHCP server is handing out bad information. For example, if computer 2 is a DHCP client and has
been given the IP address of, and let's say it's been given a mask of 16, it's been given a
default gateway, a default router, of, which is all good-- if it also has been given a DNS
server of and there is no DNS server at that IP address, that would be an example of a
misconfiguration, because DHCP is handing out bad information.
And then when computer 2 tries to resolve a name like bubba.com over to an IP address, it makes
the DNS request out to, and there's crickets. So what we just did there, that's a two for one
special. That's a misconfigured DHCP, which is handing out a misconfigured DNS server.
So a misconfigured DNS would be a lack of name resolution. So we could try nslookup as a
command tool to try to verify whether or not DNS is working or not. And even more basic, let's say
we have a client that's trying to be a DHCP client, but there is no DHCP server locally, and there's
no DHCP helper function running on the router.

The client, after trying to get a DHCP address issuing the discover messages-- and maybe you'll do
discover a few times. It'll give up, and then it'll have an address that starts with 169, which stands
for automatic private IP addressing, and what it really means is we're in trouble.
It's when your computer tried to get an IP address from a DHCP server and absolutely failed. So if
you do an IP config and you see a 169 anything, either you need to statically configure an IP
address-- and while you're at it, a default gateway and the DNS server for that computer to use-- or
try to resolve why the DHCP server is not reachable.
Maybe the client is in VLAN 2 and the DHCP service is in VLAN 1, or maybe the DHCP server is
down, and that would be another reason why it's not handing out IP addresses. Another problem that
could come up is misconfiguration. For example, let's say this interface on the router has been
configured with the IP address of with a mask of Well, here's the problem
with that.
If this sub network that we're really supporting is a /16, the range for that subnet is that's
the starting address-- all the way to However, what the router believes is the range-because it has this .240 in the last octet of its mask, it believes that the block size is 16, so it thinks
that for subnet 0, the range is 1 through 14. And then for subnet 16, it's 17 through 30, and for
subnet 32, it starts with 33 and so forth. So the bad news is that the default gateway will only know
how to reach IP addresses on this local subnet that are in the range of 1 through 14. So as much as
the router would like to reply and work with packets from clients that have addresses that had the
last octet higher than 14, the router is going to believe that anybody who has the IP address of .18,
or .19, et cetera is not on this local area network.
And unfortunately, if router 1 has a default route that says, if you don't know how to get to
somewhere, go ahead and forward it over to the firewall, the router is going to take packets that
should be forwarded into this network, and it's going to send them out to the firewall because it has
a default route for that.
So that's also a two for one. That's an interface configuration mistake on the router. It's also ending
up being a routing mistake, because the router does not believe he's directly connected to the
10.100/16 network. In all these devices as well as far as their interfaces, we could have missed
configurations regarding speed, or duplex, which also would impact performance on the network.
Now we've had discussions and separate Nuggets regarding troubleshooting our cabling plants and
our wired networks. So as far as cable placement goes, we want to make sure we avoid-- especially
with unshielded twisted pair, we want to make sure we avoid huge sources of electromagnetic
interference-- big motors, big generators that are cranking through quite a bit of electricity and

generating a lot of EMI.

And that could impact our signals that are being sent on the wire to make them unusable or
unworkable as far as sending bits due to the EMI. Now, interface errors can represent lots of
different problems. For example, let's say we have a computer like computer 2 that's connected to
switch number 2, and let's say that the cable run is 90 meters, the horizontal run. And we also have
some patch cables in the wiring closet as well as at the user's desk.
And once again, Bob is complaining about poor network performance. So we use some show
commands at the switchport, and we verify the speed and the duplex. Those look fine. But in the
output of some of our show commands on the switch, we notice that there's a whole bunch of
interface errors, and perhaps we notice a whole bunch of interface resets on some gear.
After it gets to certain points, it'll try to reset an interface to correct itself. Again, it depends on the
vendor and the device that we're working with. So if we saw, for example, an interface that had like
a million packets or a million frames with problems, maybe that's due to the actual cabling itself.
We could investigate that using a cable tester to help verify the cabling, or maybe we investigate the
device on the other side that's maybe sending bad information or corrupted packets and frames into
the network. Or maybe it's just an interface itself that's having a problem on the local switch or
And if the hardware issue and the switch is not modular, we may have to avoid using that port or
replace the switch. Another challenge may be the density, the amount of users that we have on a
network. For example, let's say, in this network currently, we just VLAN 1, which is supporting the IP subnet.
And I'd like you to consider computer 2-- if it did an ARP request, one ARP request, that Layer 2
broadcast frame is going to be processed and seen by every other device in VLAN 1. No big deal.
The server gets it. The router gets it. The printer gets it. The access point sees it.
The computer 1 sees it. And they all look at it, they deencapsulate and think, oh, he's not looking for
me. I'll discard it-- except for the one lucky winner whose IP address was being looked for who then
responds. Now, the actual request is a broadcast at Layer 2 for that ARP request, and the response
going back is unicast, meaning it's destined for a specific Layer 2 destination.
So if R1 is responding, he encapsulates with a Layer 2 destination address of the computer 2 who

requested it, so we don't have to have two different broadcasts for an ARP request. Now, consider
this same network, but let's add 400 more devices to it. So maybe we add 20 or 30 more wireless
devices and 300 or so more wired devices, and we can continue to Daisy chain switches together
and get switches with more ports to get that many users.
So now the question I have is this. Now that we have 400 devices all in a single VLAN, and
computer 2 now does a broadcast, a Layer 2 broadcast-- maybe it's the DHCP discover, maybe it's
an ARP request-- in any case, a broadcast goes into the network. How many devices now need to
process and deencapsulate that broadcast to see if it's interesting to them? And the answer is all the
other devices.
So the larger our segments of networks are, the larger our VLANs are, the more of an impact
common traffic like broadcasts are going to have on every single device. So in a really busy
network where you have lots of devices all making these requests and doing it quite frequently,
that's going to slow down performance on the entire network.
Also, if there is a significant problem with that network-- let's say there's a broadcast storm. STP
gets turned off, for example. And in a broadcast storm, we've just impacted 400 devices by that
failure. So generally, we want to isolate our number of users and devices into smaller manageable
chunks, smaller networks, smaller VLANs, and then we can route traffic at Layer 3 between the
VLANs that need to communicate with each other.
And one way of identifying are we having an issue with just too much broadcast traffic on our
network is we could set up port mirroring, as we discussed, and send that information over to a
protocol analyzer, which we've also discussed. From the protocol analysis, we can take a look at the
quantity of broadcast traffic.
In fact, we could look at that in comparison with the other unicast traffic that's happening, and that
would be a method of troubleshooting a network that was having really lousy performance just
because there was too many devices in one subnet. Another really cool technique that we can use is
the ability to discover neighboring devices and nodes in a network.
And one of the tools that a lot of networking vendors use is called LLDP, which stands for Link
Layer Discovery Protocol. And it's basically little messages that are sent out periodically by
network devices that support it. So for example on a switch, if it sent out little LLDP messages on
its ports and the routers sent out little LLDP messages a switch could know that it's directly
connected to a router, or a switch like switch 2 could know is it's directly connected to switch 1 due
to LLDP. And that's really handy for troubleshooting, because you and I could be working on a new

We got called in as consultants, and we're trying to verify connectivity. We can use the show
commands that are relevant to LLDP to verify what device is connected to what other device.
There's also applications that are available on other platforms-- for example, Linux and Windows-where we could also run LLDP.
And if the switch is running LLDP with us, that would let us verify from the client the details
regarding the switch that we're connected to. Now, in a secure environment, we would not, as the
administrators, want to be advertising out to access ports, regarding the make and model of our
switch and our capabilities, because if an attacker connected, they could potentially use that
information against us.
In a Cisco environment, they've got a feature called CDP, which stands for Cisco Discovery
Protocol. Very similar to LLDP, except CDP is proprietary, meaning that it was written by, licensed
by, and used by Cisco equipment. For example, Cisco switches, Cisco routers, Cisco phones, and so
forth that can use that information to identify and gain information about the device they're
connected to.
Computing devices are addicted. They are addicted to power. They really need power to run, and so
power failures and power anomalies, such as brownouts, or spikes, or dips in the power can
negatively impact our computing devices. That's why many companies have backup systems in
place for power.
They'll use uninterruptible power supplies that are based on batteries, and those are usually good for
a fairly short time, but they're immediate. So the moment the power indicates that it might be failing
or going down the UPS is going to protect our devices from feeling the effect of the abnormal
power coming in.
And then for anything longer term, we'd probably have generators, which can generate electricity
for longer periods-- for example, longer than just an hour or two hours. So uninterruptible power
supply is generally for short term, and then generators for long term to protect against power
failures and power anomalies.
Also we have things called conditioners for power, which can help even out the fluctuations in
power as that power is fed into our computing and network devices. MTU is an acronym that stands
for maximum transmission unit. It's how big something can be, and there's different MTUs at Layer
2 compared to Layer 3. So the MTU for a packet or a frame is simply identifying how large it can

So if we had an MTU, for example, of 1,500 bytes, that would mean that, as computer 2
communicates with a device on the internet, the entire path could support the maximum
transmission unit size of 1,500 bytes no problem. Now, it's also possible that we might have
segments of our network-- for example, let's say, between router 2 and the service provider for some
reason-- that can only support a maximum transmission unit size for a packet of 1,300 bytes. What
is a router to do? Well, what a router could do is we could go ahead and chop it up, and we could
indicate that, OK, we're going to chop this up, and we're going to send the first part, and then we're
going to send the second part.
And inside of the IP header, there are indicators regarding how that packet has been chopped up for
the benefit of the receiving side to go ahead and put them all back together. So what it exactly is an
MTU black hole? Well, let's say that router 2 going over to the service provider can only support an
MTU of 1,300 bytes. And instead of chopping it up into a smaller piece, it simply says, ah, I can't
handle 1,500. I'm going to go ahead and simply drop your packet, and I'm not going to bother
telling you about it.
It's not going to send a message back to computer 2 saying, sorry, I killed your packet. That's what's
referred to as an MTU black hole. You get no notification. The packet is just dropped due to the
MTU not being supported. And so some protocols can negotiate the MTU from end to end.
So they can verify what the MTU could be from one end to the other, and then they'll both
artificially set to a lower number the MTU for that conversation. Now, a missing route could be
missing multiple places. Let's start at the end computer, computer 2. If we're at the computer 2 and
it doesn't have a default gateway, guess what, it is missing a significant route.
It would know how to connect to anything locally on its local subnet, but it wouldn't have any route,
a default route, a default gateway to use to reach networks outside of the local network. The router
is also a good candidate where, if it's misconfigured or if its routing protocols aren't working
correctly, it could have a missing route.
So in our topology, if router 1 did not have a route for the packet that computer 2 is trying to
forward, router 1 may not be able to forward that packet. At which point, router 1 would say, oh, I'm
so sorry. I had to drop your package because I didn't know how to forward it.
And the game of routing is like hot potatoes. We can statically configure routes on routers. We can
use dynamic routing protocols like RIP Version 2, or OSPF, or on the internet, they use border
gateway protocol. But at the end of the day, it's each router on its own.

It gets a packet in. It looks at the destination IP address, compares it against its routing table, looks
for the best possible match, and if it finds a match, it can go ahead and forward the packet. If there
is no match, it will go ahead and drop the packet.
So if there are missing routes, either on our PCs are or our routing devices, we would want to
correct that by either statically configuring the correct route in the routing table on that device or
making sure we're running the incorrect routing protocol that's able to dynamically learn the routes
so the Layer 3 router can do its job.
Now, in a previous Nugget, we took a look at the concept of port bonding. And the example we had
was two switches, and we have some multiple links going between those two switches, and we
logically bound those ports together using Link Aggregation Control Protocol, which is one of the
protocols that can be used to negotiate that group of ports that are now going to be acting logically
as one.
Well, in some servers-- some servers also have the ability to take multiple network interface cards
and work with them together as a logical group or as backups to each other. And they refer to that as
NIC teaming. So if this is our server-- we'll call it server 1-- that has multiple network interface
cards that are configured and plugged into a switch-- let's give it four cards.
That would go into four different ports. And for fault tolerance, what the heck, we'll put these other
two interfaces on a separate switch. That would give us additional fault tolerance. So the server has
four network interface cards. They're configured as part of NIC teaming.
We've got two of them going to switch 2 and the other two going to switch 1, and they're all
configured in the same VLAN, the same Layer 2 broadcast domain. Now, depending on the
vendor's implementation of NIC teaming, we might have a situation where all four interfaces have
the ability to forward some part of the traffic that's going between the server and the physical
network, and that would be considered active active.
So if we had two interfaces, that would make perfect sense. I'd put four up here, but the concept is
the same. Active active means that all our interfaces are participating in actively forwarding some
type of information. Now, on the other hand, the option of using active passive is where we have
one interface or a couple interfaces that are actively forwarding traffic, and the other two are just
sitting there in the event that the first one or the first ones fail.

And one method to achieve that might be that these two active interfaces are sending out little
messages periodically that are being picked up over on these other two back up or passive
interfaces. And on these other two interfaces, if they fail to see those signals periodically, they will
assume that the primary interfaces are no longer participating or working correctly, and then they
could go ahead and kick into gear.
Or if the link on these two interfaces that were active-- if link fails, we could have the passive
interfaces kick over into active mode and then start doing the work. The objective is to have high
availability so that, if we have a failure in a network, it doesn't impact the overall functionality of
the network.
And as part of NIC teaming, there's going to be decisions made regarding which interface or
interfaces are going to be responsible and actively forward multicasts and/or broadcasts into the
network. Now, we already know what a broadcast is. A broadcast is an all points bulletin.
So a Layer 2 broadcast would be received and processed by every other device in that VLAN. So in
this case, if we have two active interfaces and two passive interfaces, do we need to send the
broadcast on both interfaces or just one? And it's very likely we would only need to send it on one
of the interfaces.
So there may be identified, as part of NIC teaming, a specific interface that is responsible for the
generation of broadcasts all the time. Now, that same concept may apply to multicasts. Now, let's
discuss what multicast is. Unicast is when the one device sends something specifically to another
device, like computer 2 sending a frame to a printer. So the printer has an IP address.
It has a specific Layer 2 address, and that frame and associated packet are going to just that one
address. An example of a broadcast would be a Layer 2 broadcast as used with a DHCP discover
message or an ARP request, where the broadcast goes into the switch, and then it is forwarded or
flooded to all other ports in that same VLAN.
So everybody else has to process and deencapsulate the broadcast to find out if there's a thing in the
payload of that broadcast that is relevant to that device. Well, a multicast, on the other hand,
operates a little bit differently. Let's say we have five devices on our network.
So there they all are, plugged into this network. And we have a server, and this server is pumping
out some music. So as that music is pumped onto the network in the form of packets which have
been encapsulated into frames, who should we address that to? Should we address it to the
broadcast address? If we did that, all five computers would have to deencapsulate those frames, and

the ones that were interested in the content could continue to deencapsulate, and process the music,
and listen to music, and play it, while the others would simply discard, discard, discard, over and
over again.
So here's the idea. If we want a group, a subsection of these devices, to receive those frames and
process them, what we can do is we can take, for example, computer 2, and computer 4, and
computer 5, and put them into a multicast group. And a multicast group is simply a group of
computers that are paying attention to the same addresses.
And in IPv4, we have a class D address range that begins with 224 and goes to 239 for that first
octet. So if we ever see an IPv4 address that begins the 224 through 239, that is a multicast group
address. So what the server could do-- it could send its packets out to a multicast group address-for example, And that also corresponds to a specific Layer 2 ethernet address associated
with that group, and then each of these computers-- computer 2, 4, and 5-- they are running some
software or an application that is paying attention and tuning in to that multicast group and the
corresponding Layer 2 address on ethernet that corresponds to that group.
So now as that music gets pushed onto the network, only computer 2, 4, and 5 will bother
deencapsulating it. If computer 1 or computer 3 even sees the multicast Layer 2 frame destination
address, it won't even deencapsulate. It'll say, oh, that's not me.
I don't care, and I'll continue on its way. And in our corporate networks today, we have switches that
actually are paying attention to which computers have joined multicast groups, and the switches
won't even bother forwarding the frames to the devices that are not participating as part of those
multicast groups.
So going back to our NIC teaming configurations, if we have specific interfaces as part of our NIC
teaming that are responsible for multicast-- the sending or processing of multicasts-- and it's
misconfigured, that could also cause a failure in the network.
In this Nugget, we've taken a look at a lot of common network issues that we're likely to come
across at some point in our networking careers. I appreciate you joining me for this Nugget. I hope
this has been informative for you, and I'd like to thank you for viewing.
Intro to Wide Area Networks
In this Nugget, we're going to introduce and demonstrate an example of a wide area network. Let's
begin. I'd like you to imagine that our boss comes up to us and says, hey, we have a brand new

branch site in Des Moines, Iowa, and we want to get connectivity between the headquarter site,
which is here, and Des Moines, Iowa, the office there, and we'd like to put you-- he says to us-- in
charge of that.
Now, there's a few things that we'd want to have in mind before we start making decisions. Number
one, what's available for connectivity between our headquarter site and Des Moines, Iowa, and what
are the costs involved to get that working? Now in our case, let's presume that our local area
network, our headquarter site, is here in Las Vegas.
And if you're not in Las Vegas, I'd like you to just imagine that you're here with me in Las Vegas.
And the tricky thing about Des Moines, Iowa-- we'll have this branch office represent Des Moines,
Iowa-- is that it is geographically not close, meaning we cannot run an ethernet cable because we
know that with copper unshielded twisted pair, we have about 100 meters, and the distance between
our headquarter site and Des Moines, Iowa is way longer than 100 meters. And you might be
saying, Keith, there's technologies that go a whole bunch further than copper, including fiber optics
and fiber cabling, single mode, specifically.
And you're absolutely right, but what's likely to happen is that if we are going to get connectivity
between the branch office in Des Moines, Iowa and our headquarter site here in Las Vegas, is we
are going to leverage the service of some other entity, very likely a service provider, who has their
own connectivity between those two locations or they are subleasing connectivity from other
So we'd contact our provider in the area. Perhaps it's WANs-R-Us, or perhaps it's somebody like
AT&T or some other provider that's in our area, and we'd simply find out from them what's
available. So from our perspective, we have, for example, router two that's sitting at the edge of our
network that we could use potentially to connect to our service provider network or networks.
And the connection types to the service provider from us could be some flavor of serial, high speed
serial. We could use ethernet technologies, which would include copper or fiber, and we also could
do wireless. Maybe they want to allow wireless connectivity between us and the service provider
for that leg of the journey.
And for this example, we could say that this one service provider, WANs-R-Us, is actually going to
be providing us our WAN connectivity between our headquarter site in Des Moines, Iowa, and this
same service provider is also providing us connectivity to the internet.
And it's also likely we could get that all in one physical connection that's coming into router two.

Here, I have it separated out as two. So this icon right here, the little yellow lightning bolt, that is
indicative or represents in a topology diagram a serial connection.
And for wide area connectivity usually between two sites, we're referring to high speed serial. So if
you're old enough to know what a modem is, or the old, slower technology, we're not talking about
that for our WAN site to site connections. We're talking about high speed, synchronous serial
And some common methods that we use to describe speeds on high speed serial links are, for
example, a T-1. Now, a T-1 is a type of serial circuit, a serial link, but it also is referring to a speed,
which by default is around 1.54 million bits per second. So if we think about that for a moment,
1.54 megabits per second, about one and a half megabits per second, and compare that to our local
area network speeds, our local area network speeds are in the tens and hundreds and gigabit speeds.
So our LAN connectivity is going to be a lot faster internally compared to stuff that we send over
the wide area network simply because the speeds are not as great over the wide area network. And a
T-3, for example, is around 44 megabits per second, but it is still a bunch lower than our local area
network speeds of 100 megabits per second and gigabit per second. Now, what are the questions
that might come up is why not just get the best and fastest wide area network connectivity every
single time? And the answer is cost.
The higher the throughput that we purchase from our service provider, the more money that's going
to cost us. Now also, behind the scenes, there are different types of connections that the service
provider can give us between Las Vegas and Des Moines, Iowa.
For example, if we purchase a leased line, that is a connection that goes between us in Las Vegas to
our branch office in Des Moines, Iowa and it's ours, completely ours just for our use. So if we
purchased a leased line and we got a T-1, for example, at 1.54 megabits per second, that 1.54
megabits per second would be guaranteed to us on our link line in any way we wanted to use it
between our two sites.
And I remember in the early days, we used to use a lot of leased lines and they were very, very
expensive, because whether you're using the leased line or not, you're paying for it all month long.
Now, an alternative to that is we could have a switched circuit.
Now, a switched circuit is simply a connection that's brought up when we need it. For example, let's
say we have transactions that only need to occur two or three hours a day between the central office
and our branch office. With a switched circuit, we could go ahead and have that circuit brought up

this path, if you will, between our headquarter site and our branch office, and our bill would be less
than a leased line because we're only using it for a certain period of time.
So a switched circuit is more similar to a telephone call. You pick up the phone, it dials, it connects,
and then when you're done with the call, you hang up and you're no longer using that service, and
you're only charged for that time that you used the service.
And as time marched forward, additional technologies, including packet switch technologies,
became very, very popular. With a packet switched network, let's imagine that this cloud right here
represents the service provider network, and they've got customer A and they've got customer B. So
here on the left,
we have the headquarter sites for A and B, and then over here on the right, we have the branch
offices for A and B. And with packet switched, here's what the service provider would do. They
would create a logical path between the company's headquarter site and respective branch office.
It would be set up so that anything that customer A sent into the network would end up at the right
location, and the same thing for customer B. Any traffic that customer B puts into the network will
end up at the right location. And while that traffic is going from headquarter to branch or branch to
headquarter, the service provider is packet switching those packets any way they want to inside
their cloud, meaning there's not a dedicated circuit for customer A and there's not a dedicated circuit
for customer B.
The service provider can leverage all the bandwidth any way they want to doing packet switching
across any of their internal resources as long as, at the end of the day, customer A's packets end up
at customer A and customer B's packets end up at customer B.
A very popular example in the early '90s of a packet switched network was frame relay, and it's kind
of a bummer that it's referred to as packet switching and the term is frame relay because as we look
at the word "packet," we think layer 3, and as we take a look at the word "frame," we think layer 2.
And at the end of the day, frame relay really is a layer 2 technology. So from a protocol stack
perspective, at the physical layer, we would be using serial At the data link layer, we'd be using
frame relay for this wide area network connection instead of the ethernet that we used over here in
the local area network, and at layer 3, we'd have IP, and then at layer 4, we'd have our transport
protocol, TCP or UDP or whatever we're using up at layer 4. And then above that, of course, we'd
have the application layer with our application layer data.
So as many customers migrated to frame relay networks that the service provider was offering, the

service provider would have something called a service level agreement, which basically guarantees
a certain level of service, and they would offer something called a CIR, a Committed Information
And this CIR, the committed information rate, was what the service provider was committing to the
customer that they would have from our headquarter site, for example, over to our branch office. So
if we had a CIR of 256 kilobits per second, we could know that at any time, we should expect at
least 256 kilobits per second of throughput between those two sites.
And you might say, well Keith, that's not enough. What if we need, for example, T-1 speeds or
more? Well, you can purchase that, and the higher the CIR, the higher the monthly bill is. So it's a
question of how much throughput do we need for our business to operate over the wide area
network, and are we willing to pay that amount every month for the benefit of using that wide area
network connection provided by our service provider? If we decided not to use frame relay, which
is an example of a packet switched technology, instead, we wanted a leased line, one of the layer 2
protocols we could use between router two and the router at the branch office would be PPP.
And PPP stands for the Point to Point Protocol. So what we would do is purchase this circuit from
our service provider. They would give us a physical connection. So on router two at the headquarter
site, we would have the appropriate interface on our router two physically connect into the jack or
circuit provided by the service provider, and we'd do the same thing at our branch office.
We'd have the router there. We'd physically plug into the circuit at that end as well. And then on
those router interfaces that connect to this circuit, we would tell the routers to use PPP, or the point
to point protocol, and that would be used at layer 2, and we would also configure the appropriate IP
addresses on those serial interfaces if we want those routers to have layer 3 routing capabilities,
which indeed we do.
And then on top of that, we'd want to make sure we had some kind of a routing protocol, such as
RIP version 2 or OSPF, so that the branch office router could share routes with router two, the
router two could share headquarter routes with the branch office router, so that the routing tables on
router two and the branch office router could be populated so they would know how to route to
those other networks.
As an example of implementing our wide area network protocols, let's use router two. This interface
is serial 2/0 on R2. And up here at the branch router, I've got the i