Welcome to Network+ N10-006

00:00:00
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.
00:00:18
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.
00:00:34
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
viewing.
Describe Routers and Switches
00:00:00
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.
00:00:18
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.
00:00:38
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.
00:00:58
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.

00:01:20
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.
00:01:36
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.
00:01:52
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.
00:02:05
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
also,
00:02:21
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
internet.
00:02:37
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.
00:02:52
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
internet.
00:03:12
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

router.
00:03:29
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.
00:03:45
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.
00:04:03
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.
00:04:19
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.
00:04:41
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.
00:05:02
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.
00:05:22
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.
00:05:48
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
00:06:18
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.
00:06:38
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.
00:06:59
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.
00:07:16
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.
00:07:39
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.
00:08:03
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.
00:08:23
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.

00:08:41
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.
00:09:08
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.
00:09:22
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.
00:09:46
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.
00:10:17
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.
00:10:36
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.
00:10:53
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.
00:11:07

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.
00:11:26
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.
00:11:47
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.
00:12:14
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
addresses.
00:12:42
[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.
00:13:06
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.
00:13:20
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.
00:13:50

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.
00:14:09
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.
00:14:34
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.
00:14:56
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.
00:15:28
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.
00:15:48
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
00:00:00
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.
00:00:19

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.
00:00:42
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.
00:00:58
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.
00:01:12
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.
00:01:33
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.
00:01:54
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.
00:02:24
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.
00:02:43
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.
00:02:59
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.
00:03:17
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.
00:03:37
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.
00:03:52
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.
00:04:10
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.
00:04:26
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.
00:04:50
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.
00:05:15

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.
00:05:29
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.
00:05:47
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.
00:06:10
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.
00:06:47
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.
00:07:05
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.
00:07:21
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
NetScaler.
00:07:38
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.
00:07:58
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.
00:08:17
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.
00:08:33
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.
00:08:48
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.
00:09:11
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
00:00:00
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.
00:00:33
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.
00:00:55
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.
00:01:11
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.
00:01:25
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.
00:01:57
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.
00:02:18
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.
00:02:34
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
IDS.
00:02:51
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.
00:03:07

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.
00:03:23
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
cetera.
00:03:40
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.
00:03:58
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,
absolutely.
00:04:23
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.
00:04:37
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.
00:04:54
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.
00:05:24
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
functionality.
00:05:39
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.
00:05:55
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.
00:06:15
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
00:00:00
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.
00:00:17
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
Network.
00:00:48
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.
00:01:04
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".
00:01:21

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.
00:01:34
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.
00:01:47
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.
00:02:10
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.
00:02:25
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
fun.
00:02:56
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.
00:03:23
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.
00:03:39
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
ports.

00:04:00
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.
00:04:16
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.
00:04:32
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.
00:04:50
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.
00:05:07
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.
00:05:31
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.
00:05:49
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.
00:06:09
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.

00:06:27
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
point.
00:06:48
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.
00:07:19
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.
00:07:37
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.
00:07:56
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.
00:08:21
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.
00:08:48
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.
00:09:02
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
internet.
00:09:20
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
00:00:01
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.
00:00:25
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.
00:00:38
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.
00:00:56
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.
00:01:11
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.
00:01:32

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.
00:01:47
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.
00:02:06
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
files.
00:02:22
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.
00:02:42
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.
00:03:01
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.
00:03:19
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
not.
00:03:37
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.

00:03:52
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.
00:04:07
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.
00:04:28
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.
00:04:45
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.
00:05:03
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.
00:05:22
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.
00:05:40
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.
00:06:00
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.
00:06:18
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.
00:06:36
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.
00:06:54
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.
00:07:16
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.
00:07:31
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.
00:07:53
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.
00:08:08
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.
00:08:23
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.
00:08:38
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.
00:08:56
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.
00:09:10
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.
00:09:23
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.
00:09:38
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.
00:09:54
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.
00:10:15
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
00:00:00
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 10.1.0.0 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.
00:00:26
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.
00:00:50
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.
00:01:22
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.
00:01:50
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.
00:02:12
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.
00:02:31
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
acknowledgment.
00:02:49

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
"Explora".
00:03:11
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
function.
00:03:29
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.
00:03:46
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
10.1.0.0 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.
00:04:15
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.
00:04:36
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
arrangements.
00:04:53
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.
00:05:10
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.
00:05:25
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.
00:05:43
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.
00:06:02
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.
00:06:17
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.
00:06:33
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.
00:06:52
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.
00:07:12
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.
00:07:35
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.

00:07:50
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.
00:08:05
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.
00:08:22
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
00:00:00
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.
00:00:15
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.
00:00:28
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.
00:00:43
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
scopes.
00:00:59
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.

00:01:16
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 10.1.0.250 just as an
example.
00:01:35
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.
00:01:49
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
network.
00:02:11
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.
00:02:37
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
used.
00:02:51
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
10.1.0.1. 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 10.1.0.1. So back at the
Windows 2012 DHCP Server Manager, let's put in the default gateway as 10.1.0.1. And we'll click
on Add.
00:03:33
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.
00:03:55
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 8.8.8.8. 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.
00:04:14
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.
00:04:34
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.
00:04:46
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.
00:05:05
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.
00:05:26
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.
00:05:41
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.
00:05:54
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 10.1.0.0 space 255.255.0.0. And for the time being, please just know that the

255.255.0.0 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.
00:06:22
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.
00:06:39
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.
00:06:56
In this case, we're using 8.8.8.8 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 10.1.0.1 and the end range of 10.1.0.99. So that basically tells
this router, please don't hand out any of those IP addresses.
00:07:31
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.
00:07:49
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.
00:08:06
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.
00:08:21
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.
00:08:39

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.
00:08:53
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.
00:09:09
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.
00:09:27
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.
00:09:52
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 255.255.0.0. 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.
00:10:17
Sort of like street number 10.1 and house number 0.105. And the default gateway we want this
computer to use is 10.1.0.1. 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 8.8.8.8. 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.
00:10:46
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.
00:11:06
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.
00:11:24
Number one, it helps us to confirm that the DNS is working. Because we said google.com, yet we're
actually going out to 70.186.10.26. 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.
00:11:48
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.
00:12:10
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.
00:12:25
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.
00:12:43
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-- 10.1.0.100. It looks like the first IP
address from the pool on the DHCP server, the router.
00:13:02
It also has our default gateway of 10.1.0.1. 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.
00:13:19
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.
00:13:37
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.
00:13:52
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.
00:14:05
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
10.1.0.100, which is the IP address that in the next packet, the request, the client said, that sounds
great.
00:14:35
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 10.1.0.1. We have the domain name server at 8.8.8.8. 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.
00:15:03
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.
00:15:21
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.
00:15:39
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
00:00:00
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.
00:00:21
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
00:00:42
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,
00:00:59
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,
00:01:18
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.
00:01:34
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.
00:01:51
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.
00:02:09
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.
00:02:23
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.
00:02:40
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.
00:02:58
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.
00:03:14
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.
00:03:28
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,
00:03:49
the server should respond back with an IPv4 address. Which may look like 72.1.6.4 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.
00:04:12
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.
00:04:35
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.
00:05:10
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.
00:05:28
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.
00:05:51
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.
00:06:18
So we could say, for example, hey, this address of 8.8.8.8-- 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.
00:06:36
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.
00:06:51
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.
00:07:05
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.
00:07:22
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.
00:07:37
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
00:07:56
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.
00:08:17
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 23.1.2.5. When Jill does her DNS request to her
DNS server, saying, what is the IP address of www.acme.com?
00:08:41
The response back to should Jill should be 23.1.2.5. 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.
00:09:02
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.
00:09:18
Let's say that address is 42.1.3.9. 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.
00:09:35
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.
00:09:49
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 42.1.3.9 to 42.1.3.11.
And then when Bob's at work, he tries to connect to the old address and it's not working.
00:10:08
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.
00:10:25
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.
00:10:42
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.
00:11:00
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 42.1.3.11. 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.
00:11:21
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.
00:11:40
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
address.
Configure and Verify DNS
00:00:00
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.
00:00:24
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.
00:00:51
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.
00:01:13
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.
00:01:30
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.
00:01:46
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.
00:02:01
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 23.1.2.98. And we can click on Add Host.
00:02:19
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.
00:02:32
And there's our sample A record of 23.1.2.98, 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].
00:03:02
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?

00:03:17
The result was 23.1.2.98. 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 23.1.2.98. And it just so happened that I got some responses back
from 23.1.2.98. And not every device on the internet is allowing ping request to be responded to.
00:03:41
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 8.8.8.8, 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
00:04:11
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
computer.
00:04:34
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
sample.acme.com.
00:04:56
And it's being resolved to 23.1.2.98. 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.
00:05:17
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
administrator.
00:05:44
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.
00:05:58

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.
00:06:14
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 8.8.8.8. 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.
00:06:33
It could mean that between you right now and the target of 8.8.8.8 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.
00:06:50
This time it resolved to 8.8.8.8. That's now in our cache, locally, on this computer. And then we did
our business with our ping requests out to 8.8.8.8. 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.
00:07:11
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.
00:07:25
So let's try it. IP config, we'll press Enter. And IP config reports that we have an IP address of
10.1.0.101. There's our default gateway of 10.1.0.1. 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.
00:07:50
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.
00:08:09
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.
00:08:26
That 8.8.8.8 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.
00:08:44
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.
00:09:03
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.
00:09:18
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.
00:09:45
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.
00:10:10
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.
00:10:28
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.
00:10:44
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.
00:11:00
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.
00:11:21
And now it's like a game of chess. nslookup says, OK, great. I'm connected, and I'm using DNS
server 8.8.8.8. 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.
00:11:37
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.
00:11:59
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.
00:12:11
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
record.
00:12:30
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.
00:12:47
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.
00:13:13
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.
00:13:36

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.
00:13:51
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.
00:14:08
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.
00:14:22
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 8.8.8.8, 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.
00:14:39
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.
00:14:54
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 10.1.0.101, that's Bob's computer, and destined to 8.8.8.8, which is
Google's DNS server.
00:15:20
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.
00:15:38
So if we go down the packet 34 and select it, packet 34 is the response that's coming from 8.8.8.8
back to our client at 10.1.0.101. 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.
00:16:02
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.
00:16:21
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.
00:16:38
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.
00:17:04
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.
00:17:18
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.
00:17:37
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.
00:17:51
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.
00:18:12
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.
00:18:29
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
00:18:47
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.
00:19:07
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
00:00:00
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.
00:00:24
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.
00:00:40
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.
00:01:02
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.
00:01:17
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.
00:01:39

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.
00:01:55
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.
00:02:16
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.
00:02:32
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.
00:02:57
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.
00:03:16
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.
00:03:38
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.
00:04:04
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.
00:04:21
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
envelope.
00:04:40
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,
00:04:54
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.
00:05:11
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.
00:05:28
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.
00:05:42
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.
00:06:01
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
excited.
00:06:19

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.
00:06:32
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.
00:06:56
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.
00:07:09
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
part.
00:07:30
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.
00:07:51
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.
00:08:09
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.
00:08:28
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.

00:08:45
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
00:00:00
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.
00:00:16
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.
00:00:32
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.
00:00:47
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.
00:01:00
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.
00:01:17
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.
00:01:34
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.

00:01:47
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.
00:02:10
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.
00:02:31
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.
00:02:45
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.
00:02:59
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
upon.
00:03:18
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.
00:03:34
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
model.
00:03:52
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.
00:04:12
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.
00:04:28
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.
00:04:45
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.
00:05:02
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.
00:05:20
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.
00:05:39
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.
00:05:59
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.
00:06:16
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.
00:06:36
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.
00:07:01
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.
00:07:18
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.
00:07:36
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.
00:07:54
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.
00:08:14
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.
00:08:37
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.

00:08:55
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.
00:09:10
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.
00:09:36
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.
00:09:58
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.
00:10:25
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.
00:10:47
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.
00:11:03
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.
00:11:25

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
suite.
00:11:48
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
00:12:03
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.
00:12:24
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.
00:12:47
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.
00:13:10
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.
00:13:24
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.
00:13:45
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.
00:14:08
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.
00:14:32
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.
00:14:57
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.
00:15:41
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.
00:16:06
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.
00:16:56

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.
00:17:33
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.
00:18:08
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.
00:18:26
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.
00:18:49
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.
00:19:14
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.
00:19:36
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.

00:19:53
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.
00:20:12
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.
00:20:31
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.
00:20:50
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.
00:21:12
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.
00:21:49
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
00:00:00

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.
00:00:19
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.
00:00:53
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 10.1.0.101. 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 10.1.0.1. 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
network.
00:01:46
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
connectivity.
00:02:08
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.
00:02:35
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.
00:02:57

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.
00:03:12
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.
00:03:29
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.
00:03:46
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 10.1.0.1. And Router 1 said, that's me. That's my IP address.
00:04:08
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.
00:04:26
Let's do an ipconfig just to verify that we do have an IP address. And sure enough, our address is
10.1.0.101, and we've been configured to use a default gateway of 10.1.0.1, and this default
gateway IP address is the IP address that R1 is using for his interface connection to this same
network.
00:04:45
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 10.1.0.1, 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.
00:05:13
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 10.1.0.1, and I'd like you to notice something
interesting.

00:05:31
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.
00:05:54
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
10.1.0.1 once again. You'll notice that this time each of the ping responses are about equal.
00:06:13
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
10.1.0.1 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
segment.
00:06:44
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.
00:07:04
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.
00:07:22
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.
00:07:39
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.
00:08:02
And then here in the Target, it's specifying I'm looking for the Layer 2 address associated with

10.1.0.1, 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.
00:08:26
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.
00:09:09
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.
00:09:30
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.
00:09:46
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.
00:10:00
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.
00:10:30
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.
00:10:55

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.
00:11:18
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
00:00:00
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.
00:00:22
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.
00:00:53
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.
00:01:16
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
together.
00:01:34
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.

00:01:59
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.
00:02:23
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.
00:02:43
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.
00:03:02
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.
00:03:46
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
00:00:00
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.
00:00:36
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 172.67.83.0/24
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.
00:01:06
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.
00:01:29
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
networks.
00:01:43
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.
00:01:55
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.
00:02:22
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.
00:02:46
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.
00:03:03
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.
00:03:22
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.
00:03:59
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.
00:04:21
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.
00:04:52
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
subnetting.
00:05:13
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 172.67.83.0, 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.
00:05:44

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
00:06:01
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.
00:06:19
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
00:06:43
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.
00:07:04
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.
00:07:32
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.
00:07:52
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.
00:08:09
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
Nugget.
00:08:37
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.
00:09:00
OK, it'd be 172.67.83.0/26. 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.
00:09:30
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.
00:09:55
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.
00:10:12
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.
NAT
00:00:00
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.
00:00:18
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 10.1.0.0/16. 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.
00:00:38
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.
00:01:01
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 72.195.166.22. 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.
00:01:33
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 72.195.166.22. And that would be the Layer 3 IP header address where it was going.
00:02:04
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.
00:02:28
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.
00:02:42
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.
00:02:58
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 72.195.166.22. 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.
00:03:27
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 72.195.166.22 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.
00:03:52
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.
00:04:11
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
72.195.166.22. That's not me, so I'm not going to continue deencapsulating it and see what's in the
payload.
00:04:35
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.
00:04:50
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.
00:05:08
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.
00:05:34
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 23.1.2.65

through 80. And these would represent IP addresses that are routable over the internet.
00:05:55
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
Incorporated.
00:06:12
So that way, if a server on the internet ever need to send a packet to 23.1.2.67, 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.
00:06:28
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.
00:06:59
So now the internet sees this source IP address as 23.1.2.65 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 23.1.2.65, R2
has to remember to untranslate that and replace the address back with the 10.1.0.50 so that it can be
further routed all the way back into Bob.
00:07:30
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.
00:07:46
And when we replace the source address, as we did here-- so Bob's source address of 10.1.0.50 got
replaced with the source address of 23.1.2.65 for that packet's journey over the internet-- they refer
to that as Source NAT, because we're replacing the source address.
00:08:02
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.
00:08:21
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
10.3.0.99. That's the IP address it has on our DMZ. Now, that IP address of 10.3.0.99 starts with a
10, it's in the RFC 1918 private address space. That's not routable over the internet.
00:08:47
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 23.1.2.80. So we'll change the range of the NAT pool, and we'll use 23.1.2.80, which is still
allocated to us to our company, as a globally routable address.
00:09:11
What we'll go ahead and do is have R2 map that IP address over to this internal IP address of
10.3.0.99. So now when Lois is sending a packet to 23.1.2.80, 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, 23.1.2.80,
over to 10.3.0.99 and then continue to route it inside our network.
00:09:43
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.
00:10:00
So Lois would go to 23.1.2.80, 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.
00:10:15
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
internet.
00:10:38
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.
00:10:56
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.
00:11:25
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.
00:11:49
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.
00:12:12
Let's say she has the IP address of .51. So Laura's source IP address is 10.1.0.51, 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.
00:12:45
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.
00:12:59
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.
00:13:14
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.
00:13:45
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.
00:14:09
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.
00:14:25
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 10.1.0.0, 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.
00:15:01
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.
00:15:18
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
provider.
00:15:35
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.
00:15:49
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.
00:16:02
So here is the inside computer, which was 10.1.0.101. 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.

00:16:25
And on this router, it's also changing those source ports to the source ports the router wants to use
for the PAT. So 10.1.0.1, 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.
00:16:45
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.
00:17:04
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
server.
00:17:23
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.
00:17:49
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
00:00:00
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.
00:00:25
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.

00:00:52
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.
00:01:24
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.
00:01:39
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
configuring.
00:01:57
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
firewall.
00:02:12
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.
00:02:31
And for our demonstration, let's say the default gateway is going to be the IP address here on router
1, which is 10.1.0.1. The mask is going to be 16 bits in length, which we represent in dotted
decimal. So that'll be 255.255.0.0. And the DNS server will tell computer 2 to use is-- let's use one
of Google's out on the internet-- at 8.8.8.8. 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.
00:03:01
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.

00:03:16
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.
00:03:34
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
terminal.
00:03:50
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
interface.
00:04:18
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.
00:04:33
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
10.1.0.1 with a 16-bit mask-- what we're going to do is we're going to type in the command IP
address.
00:04:51
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 10.1.0.1 space 255.255.0.0, 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.
00:05:15
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.
00:05:33

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.
00:05:49
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 10.2.0.0-- 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 10.2.0.1. And we'll put a 16-bit mask in dotted decimal. And then we'll do a no
shutdown there as well.
00:06:15
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.
00:06:37
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 10.4.0.2 with a 16-bit mask. Now also on this
router, router 2, it is also performing network address translation.
00:06:56
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.
00:07:10
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.
00:07:34
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
provider.
00:07:52
So we'll go into interface config for Ethernet 3/2. We'll give it the IP address of 192.168.1.253 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.

00:08:09
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.
00:08:28
And that is network E. And network E is the 10.5.0.0/16 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 10.5.0.2 with a 16-bit mask, which is spelled 255.255.0.0. We'll
say IP NAT inside.
00:08:51
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.
00:09:21
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.
00:09:40
We'll give it the IP address of 10.5.0.4 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.
00:10:01
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 10.1.0.0/16 network.
For the default gateway we'll point to dot one on that same network.
00:10:19
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 8.8.8.8 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.
00:10:36
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.
00:10:51
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.
00:11:09
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.
00:11:23
And you'll notice when I hit Tab, it automatically wants me to use 255.0.0.0. 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.
00:11:53
And then we'll specify that the DNS server that we want to use is 8.8.8.8, 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.
00:12:20
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.
00:12:35
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 10.1.0.1. Press Enter.
00:12:52
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 8.8.8.8, which is our DNS server, which is on the
internet. We'll press Enter. And it's coming back saying destination host unreachable.
00:13:09
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 10.1.0.1. However when computer 2 tried to access an internet resource like
8.8.8.8, it was not successful. And my friend, on a new network, here is the reason why.
00:13:40
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.
00:13:58
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.
00:14:17
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
00:00:00
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
10.1.0.1. We tried pinging that IP address of Router 1, and we could not get there.
00:00:29
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.
00:00:49
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.
00:01:09

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.
00:01:32
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.
00:01:49
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.
00:02:12
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.
00:02:30
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 10.4.0.100. 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.
00:03:09
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.
00:03:28
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,

00:03:47
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.
00:04:06
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.
00:04:25
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.
00:04:45
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.
00:05:12
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.
00:05:28
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.
00:05:59
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.
00:06:25

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.
00:06:38
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.
00:06:57
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 10.2.0.100, which is the firewall. So there's our quad zeros with three periods
in between.
00:07:14
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 10.2.0.100, 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.
00:07:34
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.
00:08:03
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
route.
00:08:19
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 10.2.0.100, 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.
00:08:42
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 192.168.1.1. And
then we get out of configuration mode.
00:09:16
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 192.168.1.1, which is our service provider, as the next hop.
00:09:31
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.
00:10:01
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.
00:10:18
We'll specify the default route. And we'll say that 10.5.0.2, 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.
00:10:41
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.
00:11:07
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 8.8.8.8, and sure enough, Router 2 has successful connectivity
out to the internet.
00:11:25

It's using the default route to reach the 8.8.8.8 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
way.
00:11:41
So next, let's see if Router 2 can ping the 10.1 network. In fact, let's try to ping 10.1.0.1. 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,
dude.
00:12:02
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 192.168.1.1
for routing. And that's going out this way.
00:12:22
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.
00:12:47
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.
00:13:05
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.
00:13:20
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.
00:13:36
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 192.168.1.1, which is the
service provider. And then it's very likely that our service provider just dropped it.

00:13:51
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.
00:14:16
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
00:00:00
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.
00:00:16
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.
00:00:33
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.
00:00:52
So the branch office has the 10.6.0.0 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.
00:01:15
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.
00:01:41

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.
00:02:07
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.
00:02:23
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.
00:02:52
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.
00:03:23
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.
00:03:54
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.
00:04:15
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.
00:04:34

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.
00:05:01
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.
00:05:24
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.
00:06:15
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.
00:06:32
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.
00:06:50
And the network 0.0.0.0 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.
00:07:06
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.

00:07:33
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 10.4.0.100 as the next hop, and that is the IP
address on the firewall.
00:08:06
Now earlier, we could not ping the 10.1 Network. Let's try it again. We'll ping 10.1.0.1, 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.
00:08:46
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.
00:09:09
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 8.8.8.8, 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 8.8.8.8 as our target, it's going to show us each hop in the path
between this PC and 8.8.8.8, which is on the internet. So on the packet's journey out to the internet,
the first hop was R1 at 10.1.0.1. The second hop was the firewall at 10.2.0.100. The third hop was
R2 with 10.4.0.2. And the fourth hop was our internet service provider at 192.168.1.1. Then the next
hop was 10.72.0.1, which is inside my service provider's network.
00:10:05
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 8.8.8.8. 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.
00:10:25
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
00:00:00
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.
00:00:21
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.
00:00:39
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.
00:00:55
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.
00:01:14
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.
00:01:41
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.
00:01:57
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.
00:02:15

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.
00:02:32
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.
00:02:46
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.
00:03:00
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.
00:03:18
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.
00:03:33
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.
00:03:53
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.
00:04:19
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.

00:04:51
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.
00:05:09
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.
00:05:27
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.
00:05:44
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.
00:06:00
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.
00:06:20
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.
00:06:40
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.
00:06:54
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.
00:07:10

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.
00:07:32
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.
00:07:47
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.
00:08:10
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.
00:08:27
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.
00:08:50
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.
00:09:12
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.
00:09:33
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.

00:09:57
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.
00:10:17
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.
00:10:39
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.
00:10:56
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.
00:11:30
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.
00:11:43
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.
00:12:14
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.

00:12:38
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
SSH.
00:12:58
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.
00:13:14
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.
00:13:31
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.
00:14:01
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.
00:14:27
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.
00:14:49
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.
00:15:10
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.
00:15:24
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.
00:15:39
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.
00:16:00
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.
00:16:19
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
running.
00:16:37
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.
00:16:53
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.
00:17:18
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.
00:17:35

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
IP.
00:17:53
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.
00:18:13
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.
00:18:30
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.
00:18:49
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.
00:19:06
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.
00:19:26
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.
00:19:44
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.
00:20:05
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.
00:20:22
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.
00:20:41
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.
00:20:57
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.
00:21:24
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
request.
00:21:45
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.
00:22:03
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.
00:22:19
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
SNMP.

00:22:45
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.
00:23:06
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.
00:23:39
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.
00:23:56
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
encryption.
00:24:11
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.
00:24:26
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.
00:24:46
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.
00:25:07

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.
00:25:21
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
00:00:00
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.
00:00:19
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.
00:00:43
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.
00:01:07
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.
00:01:32
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.
00:01:50

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.
00:02:06
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 10.1.0.190 with a 16-bit mask. I've
also taken the opportunity to disable that interface for just a moment.
00:02:27
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.
00:02:46
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.
00:03:04
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.
00:03:20
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.
00:03:34
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.
00:03:51
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.
00:04:08
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.
00:04:23
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.
00:04:40
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.
00:04:56
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.
00:05:24
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.
00:05:43
And based on this IP address that's associated with that of 10.1.0.1, 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 10.1.0.100,
which is PC Number 2's IP address that it got via DHCP, and the destination is 8.8.8.8, which is the
IP address of its DNS server, which it also learned via DHCP.
00:06:13
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.
00:06:29
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.

00:06:49
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.
00:07:06
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.
00:07:29
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.
00:07:45
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.
00:08:06
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 10.1.0.100, which is the IP address of PC 2,
going to 10.1.255.255, which is a Layer 3 broadcast address for the 10.1 network. And we could do
the same thing for TCP.
00:08:34
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 10.1.0.100 and 104.67.97.142. Whatever server
that is out on the internet, this conversation that we have highlighted used the most amount of bytes
during that capture period.
00:08:55
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
well.
00:09:11
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
00:00:00
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.
00:00:18
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.
00:00:32
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.
00:01:00
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 8.8.8.8,
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.
00:01:28
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.
00:01:54
And then the service provider is routing over the internet, along with a lot of other internet routers,
to the final destination of 8.8.8.8. 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.
00:02:46
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.
00:03:17
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.
00:03:34
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.
00:03:59
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.
00:04:30
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.
00:04:56
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.
00:05:15

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 8.8.8.8, he probably is a little bit depressed-- Router 1 is-because it's not his own IP address.
00:05:35
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 8.8.8.8, he consults his routing table, and he makes a forwarding decision, based on that Layer 3
information.
00:05:57
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.
00:06:19
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.
00:06:39
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.
00:06:58
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 8.8.8.8. The firewall says, nuts, that's not me because if it was, I
would continue to de-encapsulate.
00:07:18
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.
00:07:49

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.
00:08:05
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 8.8.8.8, 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.
00:08:27
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.
00:08:44
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.
00:09:12
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.
00:09:28
And the last stop, here, for this DNS request, is when it finally reaches the Google DNS server, at
8.8.8.8. 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.
00:09:50
And then Router 8.8.8.8 is going to de-encapsulate. And it's going to look at the Layer 3
information and say, hey, this is for 8.8.8.8. 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.
00:10:11
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.
00:10:30

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.
00:10:44
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.
00:11:04
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
request.
Using VLANs for Isolation
00:00:00
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.
00:00:16
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.
00:00:30
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
reasons.
00:00:47
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.
00:01:02
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 10.1.0.0/16. 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
subnet.

00:01:26
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.
00:01:46
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
VLAN.
00:02:18
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.
00:02:40
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 10.1.0.101. Lois has 10.1.0.102. The
Attacker's computer got 10.1.0.103. 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
else.
00:03:08
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.
00:03:40
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.
00:03:58
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
networks.
00:04:23
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.
00:04:48
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.
00:05:02
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.
00:05:22
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.
00:05:41
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.
00:05:58
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 10.1.0.101. Lois is at 10.1.0.100. 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 10.1.0.1, 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.
00:06:43
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.
00:07:05
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.
00:07:29
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 10.1.0.0/16 network. So let's have some fun.
00:07:44
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.
00:08:02
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.
00:08:17
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.
00:08:41
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.
00:09:01
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.

00:09:19
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.
00:09:38
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.
00:10:00
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.
00:10:21
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.
00:10:57
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.
00:11:15
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 10.1.0.1, 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.
00:11:47
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, 10.1.0.101. Our default gateway is 10.1.0.1. And let's do a couple
commands just to verify basic connectivity. Let's do a ping over to 10.1.0.1, which is our default

gateway.
00:12:06
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.
00:12:30
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.
00:12:56
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.
00:13:11
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.
00:13:29
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.
00:13:46
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.
00:14:04
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.
00:14:32
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.
00:14:49
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.
00:15:14
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.
00:15:35
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
VLAN.
00:16:09
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.
00:16:33
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 10.1.0.1, 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.
00:16:51
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, 10.1.0.1 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 10.1.0.100. 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.
00:18:03
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
success.
00:18:31
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.
00:18:51
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.
00:19:15
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.
00:19:36
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 10.1.0.1. In the background, the ARP was resolved correctly,
because the pings are now successful.
00:19:56
So if we hit the up arrow key and did a arp -a, you'll notice that we now have the ARP resolution for
10.1.0.1. 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.
00:20:14
And then I'll go ahead and do that trace out to a Google DNS server, 8.8.8.8. 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 8.8.8.8. 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
00:00:00
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
airport.
00:00:18
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.
00:00:32
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
forth.
00:00:55
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.
00:01:14
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.
00:01:30
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.
00:01:51
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.
00:02:16
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.
00:02:37
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.
00:03:05
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.
00:04:01
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.
00:04:23
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.
00:04:45
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.
00:05:09
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.
00:05:30
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.
00:05:56
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.
00:06:15
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.
00:06:31
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.
00:06:48
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.
00:07:11
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.

00:07:37
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.
00:08:22
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.
00:08:44
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.
00:09:05
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.
00:09:31
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.
00:09:52
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.
00:10:25

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
00:00:00
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.
00:00:23
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.
00:00:37
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.
00:01:00
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.
00:01:49
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.
00:02:14
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.
00:02:33
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.
00:03:14
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.
00:03:28
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.
00:03:54
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.
00:04:10
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
trunking.
00:04:27
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.
00:04:53
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.
00:05:18
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
engineering.
00:05:36
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.
00:05:57
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.
00:06:18
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.
00:06:33
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.
00:06:54
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.
00:07:20
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.
00:07:36

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.
STP
00:00:00
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.
00:00:34
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
mode.
00:00:52
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
connected.
00:01:12
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.
00:01:27
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.
00:01:42
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.

00:02:07
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.
00:02:32
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.
00:03:27
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.
00:03:44
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.
00:03:59
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.
00:04:16
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.
00:04:38
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.
00:05:15
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.
00:05:33
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.
00:05:47
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.
00:06:18
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.
00:06:38
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.
00:07:00
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
OK.
00:07:18
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.
00:07:36
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.
00:07:53
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.
00:08:40
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.
00:08:57
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.
00:09:18
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.
00:09:34
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.
00:10:08
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
did.
00:10:33
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.
00:10:59
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.
00:11:17
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.
00:11:35
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.
00:12:01
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.
00:12:22
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.
00:12:56
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.

00:13:12
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.
00:13:39
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.
00:14:18
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.
00:14:45
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
00:00:00
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.
00:00:15
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.
00:00:37
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.
00:00:59
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.
00:01:14
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.
00:01:31
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.
00:01:48
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.
00:02:07
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.
00:02:29
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
options.
00:02:59
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.
00:03:17

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.
00:03:37
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.
00:04:01
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.
00:04:30
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.
00:04:59
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.
00:05:28
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.
00:05:44
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.

00:06:11
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.
00:06:29
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.
00:06:54
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.
00:07:10
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.
00:07:33
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.
00:07:48
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.
00:08:28
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.

00:08:45
On switch 1, which currently is supporting all these customers that are in subnet A, which is the
10.1.0.0/16 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.
00:09:05
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.
00:09:33
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 10.1.0.11/16, 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.
00:10:14
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.
00:10:29
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.
00:10:51
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 10.3.0.0 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 10.3.0.105
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.
00:11:27
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 10.1.0.11, 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
terminal.
00:12:25
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.
00:12:49
So for example, if we were going to connect to router two, which is on network D here, and it's at
10.4.0.2, 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.
00:13:07
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.
00:13:40
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.
00:13:55
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.
00:14:12
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.
00:14:37
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.
00:15:00
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.
00:15:13
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.
00:15:33
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.
00:15:48
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.
00:16:07
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.
00:16:25
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.
00:16:41
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.

00:16:55
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.
00:17:13
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.
00:17:33
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.
00:17:46
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.
00:18:22
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,
00:18:45
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.
00:18:59
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.
00:19:29
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.
00:19:49
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.
00:20:12
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.
00:20:32
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
switch.
00:20:49
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.
00:21:06
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
RADIUS.
00:21:24
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.
00:21:40

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 10.1.0.11, 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.
00:22:07
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.
00:22:31
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.
00:22:45
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.
00:23:03
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.
00:23:30
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.
00:23:45
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.
00:24:02
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.
00:24:18
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.
00:24:45
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.
00:25:08
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.
00:25:37
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.
00:25:55
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)
00:00:00
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.
00:00:17
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.
00:00:45
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.
00:01:03
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.
00:01:25
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.
00:01:39
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.
00:01:55
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.
00:02:09
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.
00:02:24
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.
00:02:45
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.
00:02:59
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.
00:03:21
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.
00:03:40
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.
00:04:05
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.
00:04:27
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.
00:04:51
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
switches.
00:05:16
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.
00:05:42
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.
00:06:01
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.
00:06:25
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.
00:06:41
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.
00:07:04
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.
00:07:24
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.
00:07:41
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.

00:07:57
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.
00:08:20
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.
00:08:36
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.
00:08:58
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.
00:09:12
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.
00:09:33
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.
00:09:56
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.
00:10:14
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.
00:10:30
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.
00:10:53
So if PC1 did a ping to 8.8.8.8, 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.
00:11:22
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.
00:11:57
So here at PC1, let's do a ping to 8.8.8.8. We'll press Enter. And sure enough, we have responses
coming back from 8.8.8.8, 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.
00:12:24
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
00:00:00
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.
00:00:19

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.
00:00:49
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.
00:01:03
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.
00:01:56
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.
00:02:18
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.
00:02:48
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.
00:03:04
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.
00:03:27
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.
00:03:48
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.
00:04:02
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.
00:04:48
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.
00:05:06
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.
00:05:38
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

purposes.
00:06:03
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.
00:06:22
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.
00:06:46
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
00:00:00
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.
00:00:19
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.
00:00:39
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.
00:01:00
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.
00:01:19
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.
00:01:38
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.
00:01:59
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.
00:02:14
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.
00:02:37
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.
00:02:56
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.
00:03:27
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.

00:03:42
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.
00:04:00
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 10.1.0.1, 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.
00:04:49
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.
00:05:11
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.
00:05:41
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, 10.1.0.11, 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 255.255.0.0. 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.
00:06:44

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 10.1.0.1. That
would be a good verification that our IP connectivity on the switch is working.
00:07:09
So let's go for it. We'll do a ping to 10.1.0.1, 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 10.3.0.50 with a 16-bit mask, and we try to
open up an SSH or a Telnet session over to the switch.
00:07:41
Well the switch, which is on the 10.1.0.0 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.
00:08:05
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
10.1.0.1 in our topology as its default gateway.
00:08:32
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 10.1.0.1
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.
00:09:04
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 10.4.0.0 slash 16. Router 2 interface, 3 slash 1 interface, has a last octet of dot 2.
So R2 is reachable at 10.4.0.2. 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.
00:09:45
We'll do a ping to 10.4.0.2, 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.
00:10:06
So let's do a trace route to 10.4.0.2, 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 10.4.0.2. 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.
00:10:40
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.
00:10:59
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.
00:11:21
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.
00:11:50
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.
00:12:08
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.
00:12:30
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.
00:13:03
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.
00:13:37
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
with.
00:13:54
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.
00:14:22
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.
00:14:41
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.
00:14:56
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.

00:15:11
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.
00:15:29
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.
00:15:46
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.
00:16:05
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.
00:16:30
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.
00:16:43
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 10.1.0.11. And what
should happen? As a result of us trying to connect to the VTY lines, it should prompt us for a
username.
00:17:09
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.
00:17:25
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 10.1.0.11. It's prompting us for a username.
00:17:43

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.
00:18:01
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 10.1.0.1, 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.
00:18:24
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.
00:18:46
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
00:00:00
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.
00:00:18
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.
00:00:42
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.
00:01:05
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.
00:01:24
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.
00:01:40
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.
00:02:02
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.
00:02:16
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.
00:02:32
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.
00:02:56
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.
00:03:11
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.
00:03:28

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
network.
00:03:47
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.
00:04:03
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.
00:04:27
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.
00:04:44
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.
00:05:05
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.
00:05:37
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.

00:05:52
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.
00:06:15
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.
00:06:41
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.
00:07:01
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.
00:07:17
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.
00:07:32
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.
00:07:56
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.

00:08:15
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.
00:08:36
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
points.
00:08:51
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
point.
00:09:08
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.
00:09:22
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.
00:09:43
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.
00:10:03
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
alone.
00:10:19
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.
00:10:38
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.
00:10:52
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.
00:11:08
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.
00:11:29
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.
00:11:45
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.
00:12:06
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.
00:12:23
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.

00:12:44
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.
00:13:02
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.
00:13:20
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.
00:13:42
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.
00:14:03
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.
00:14:21
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.
00:14:35
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.
00:14:47
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
better.

00:15:02
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.
00:15:28
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.
00:15:48
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
work.
00:16:05
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.
00:16:24
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.
00:16:41
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.
00:17:17
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

efforts.
00:17:37
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.
00:17:59
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.
00:18:17
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.
00:18:30
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.
00:18:44
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.
00:19:06
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.
00:19:23
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.
00:19:45

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.
00:20:07
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.
00:20:30
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.
00:20:44
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.
00:20:58
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.
00:21:14
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.
00:21:39
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.
00:21:54
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.
00:22:55
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.
00:23:14
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.
00:23:56
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.
00:24:16
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.
00:24:49
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.
00:25:05
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
interference.

00:25:25
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.
00:25:43
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
MUMIMO.
00:26:01
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
00:00:00
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.
00:00:16
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.
00:00:29
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.
00:00:42
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.
00:01:11
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.

00:01:24
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.
00:01:39
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.
00:02:04
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.
00:02:17
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.
00:02:36
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.
00:02:56
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.
00:03:13
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.
00:03:37
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.
00:04:14
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
delivered.
00:04:34
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.
00:04:50
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.
00:05:14
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.
00:05:39
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.
00:06:16
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.

00:06:36
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.
00:07:00
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.
00:07:23
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.
00:07:39
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.
00:07:54
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.
00:08:22
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.
00:08:36
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.
00:08:52
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.

00:09:09
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.
00:09:27
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.
00:09:50
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.
00:10:10
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.
00:10:25
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.
00:10:48
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.
00:11:04
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.
00:11:26

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.
00:11:44
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.
00:12:01
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.
00:12:27
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.
00:12:47
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.
00:13:04
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.
00:13:19
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.
00:13:36
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.

00:13:56
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
network.
00:14:13
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.
00:14:28
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
selection.
00:14:43
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.
00:15:00
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.
00:15:17
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.
00:15:34
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.
00:15:53
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
network.
UTP Cabling
00:00:01
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.
00:00:21
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.
00:00:37
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.
00:00:55
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
Pair.
00:01:23
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.
00:01:37
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.
00:01:52
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.

00:02:13
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.
00:02:29
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.
00:02:45
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.
00:02:59
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
technology.
00:03:25
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.
00:03:39
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.
00:03:54
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.
00:04:09
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.
00:04:28
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.
00:04:45
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.
00:05:02
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.
00:05:19
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.
00:05:38
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.
00:05:51
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.
00:06:15
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.
00:06:35
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.

00:06:49
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.
00:07:15
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
pitcher.
00:07:31
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.
00:07:51
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.
00:08:11
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.
00:08:39
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
heaven.
00:09:02
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.

00:09:18
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.
00:09:41
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.
00:09:56
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.
00:10:19
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.
00:10:33
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
switch.
00:10:52
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.
00:11:17
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.
00:11:36
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.

00:11:57
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.
00:12:17
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.
00:12:33
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.
00:12:59
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.
00:13:20
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.
00:13:44
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.
00:14:02
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.
00:14:21
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.

00:14:39
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.
00:15:10
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.
00:15:28
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.
00:15:52
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.
00:16:27
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.
00:16:42
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.
00:16:57
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.

00:17:13
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.
00:17:35
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.
00:17:53
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.
00:18:11
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.
00:18:39
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.
00:18:57
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.
00:19:12
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.
00:19:28
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.
00:19:45
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.
00:20:16
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
tester.
00:20:34
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.
00:20:47
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.
00:21:05
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
00:00:00
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.
00:00:18
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.
00:00:40
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.
00:00:54
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.
00:01:17
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.
00:01:36
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.
00:01:52
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.
00:02:07
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.
00:02:24
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.
00:02:38
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.
00:02:53
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.
00:03:12
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.
00:03:31
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.
00:03:52
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.
00:04:09
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.
00:04:23
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.
00:04:42
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
runs.

00:05:05
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.
00:05:25
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.
00:05:39
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.
00:05:55
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.
00:06:17
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.
00:06:34
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
place.
00:06:50
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.
00:07:08
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.
00:07:25

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.
00:07:41
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.
00:08:00
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.
00:08:16
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.
00:08:29
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
work.
00:08:51
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.
00:09:05
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.
00:09:23
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.
00:09:39
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.
00:10:00
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.
00:10:19
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.
00:10:41
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.
00:11:12
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.
00:11:32
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
itself.
00:12:05
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.

00:12:26
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.
00:12:50
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.
00:13:14
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.
00:13:31
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.
00:13:50
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.
00:14:14
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.
00:14:31
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.
00:14:50

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.
00:15:05
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.
00:15:22
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.
00:15:41
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.
00:15:59
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.
00:16:17
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.
00:16:36
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.
00:16:59
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.
00:17:15
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.
00:17:48
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.
00:18:08
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.
00:18:26
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.
00:18:39
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.
00:19:00
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.
00:19:15
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.
00:19:33
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.
00:19:48
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.
00:20:04
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.
00:20:33
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.
00:20:57
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.
00:21:16
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.
00:21:31
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.
00:21:46
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.
00:22:02
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.
00:22:23

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.
00:22:40
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.
00:22:55
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.
00:23:11
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.
00:23:35
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
00:00:00
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.
00:00:16
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.
00:00:36
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.
00:00:53
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.
00:01:10
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.
00:01:23
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.
00:01:41
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.
00:01:59
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.
00:02:13
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
network.
00:02:33
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.
00:02:49
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.

00:03:01
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.
00:03:17
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
problem.
00:03:32
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.
00:03:44
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.
00:03:59
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.
00:04:14
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 10.1.0.0/16 network? So that's our
network address.
00:04:38
And let's say that router 1 is at 10.1.0.1/16. But let's say Bob's computer is configured-- and I'll put
here Bob-- and say Bob it configured as 10.1.0.5. But let's say Bob's mask is a 29-bit mask. It's been
either accidentally or maliciously configured incorrectly.
00:04:58
So from Bob's computer's point of view, he would think that 10.1.0.1 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.
00:05:17

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 10.1.0.0/29 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.
00:06:08
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.
00:06:22
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.
00:06:38
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.
00:07:11
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.
00:07:32
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.
00:07:47
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.

00:08:05
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.
00:08:19
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.
00:08:36
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.
00:08:49
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.
00:09:11
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.
00:09:31
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.
00:09:56
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.
00:10:10
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.

00:10:23
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.
00:10:36
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.
00:10:49
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.
00:11:09
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.
00:11:26
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
00:00:00
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.
00:00:17
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.
00:00:34
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.
00:00:51
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.
00:01:17
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.
00:01:42
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.
00:02:16
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.
00:02:30
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.
00:02:59
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.
00:03:14
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.
00:03:29
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.
00:03:52
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.
00:04:08
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.
00:04:32
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.
00:04:52
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
snuff.
00:05:14
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.
00:05:30
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
switch.
00:05:45
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.
00:06:03
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.
00:06:22
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.
00:06:39
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
communications.
00:06:55
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.
00:07:21
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.
00:07:37
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.
00:07:56
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.

00:08:12
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.
00:08:30
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.
00:08:52
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.
00:09:18
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.
00:09:34
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,
initially.
00:09:51
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.
00:10:11
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.
00:10:27
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.

00:10:41
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.
00:11:11
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.
00:11:30
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.
00:11:49
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.
00:12:05
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.
00:12:21
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.
00:12:36
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.
00:12:51
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.
00:13:13
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.
00:13:28
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.
00:13:52
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.
00:14:10
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.
00:14:25
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.
00:14:43
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.
00:15:01
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

00:00:00
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."
00:00:18
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
success.
00:00:43
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.
00:01:01
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
used.
00:01:19
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
propagates.
00:01:37
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.
00:01:56
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
optics.
00:02:12

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.
00:02:37
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
copper.
00:02:53
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.
00:03:10
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.
00:03:29
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.
00:03:57
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.
00:04:17
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.
00:04:30
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.
00:04:52
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
fiber.
00:05:16
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.
00:05:33
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.
00:05:50
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.
00:06:10
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.
00:06:24
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
00:00:00
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.
00:00:17
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.
00:00:43
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.
00:00:59
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.
00:01:21
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.
00:01:53
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
resolution.
00:02:16
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.
00:02:54
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.
00:03:12
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
Linux.
00:03:33
And both of those devices should be associated with VLAN 1, along with the IP subnet of
10.1.0.0/16, 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, 10.1.0.105 with a 16-bit
mask. That looks good.
00:03:54
And the default gateway is 10.1.0.1. 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.
00:04:11
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.
00:04:28
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.
00:04:51
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 8.8.8.8. 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.

00:05:13
Let's try pinging the default gateway. So we'll do a ping out to 10.1.0.1. 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.
00:05:31
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 10.1.0.1. 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.
00:06:06
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.
00:06:21
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.
00:06:35
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.
00:06:53
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.
00:07:10
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.
00:07:29
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.
00:07:44
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 10.1.0.0/16 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 10.1.0.100, and also the mask,
which indicates we're using a 16-bit network mask. It also is showing us a loopback address.
00:08:15
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.
00:08:33
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.
00:08:47
And that's going to show us the routing table. And this is reflecting our default gateway at 10.1.0.1.
So there's the route, the 0.0.0.0, and our default gateway for that is 10.1.0.1. Another way on Linux
to see that same information is to use the command route dash n.
00:09:04
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 10.1.0.1 via Ehternet0, meaning we'd use our Ethernet0 interface on
this device to forward over to our default gateway.
00:09:26
Now on this Linux box, let's see if we can ping out to 8.8.8.8. 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.
00:09:42
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 8.8.8.8 and press Enter. So in our path, we have 10.1.0.1, which is Router
1. Then we have 10.2.0.100, which is the firewall, 10.4.0.2, which is Router 2, 192.168.1.1, which
is our service provider. Then we start going through our service provider's network.
00:10:10

Then we hit a global address on one of the internet routers. And that continues until we hit the final
destination of 8.8.8.8. 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
gateway.
00:10:34
So this computer is saying, to reach 10.1.0.1, 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
Protocol.
00:10:52
And just for grins, let's see whether or not we can ping 10.1.0.105, 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.
00:11:16
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.
00:11:47
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.
00:12:11
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.
00:12:34
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.

00:12:52
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.
00:13:19
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.
00:14:10
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.
00:14:25
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.
00:14:44
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
them.
00:15:20
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 8.8.8.8, which is one of Google's DNS servers out on the internet.
00:15:35

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 10.1.0.1. 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.
00:16:02
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 8.8.8.8. We
should have the hops involved between us, the Windows computer, and the 8.8.8.8 IP address. And
sure enough, that trace was successful.
00:16:28
And since it was successful, let's also demonstrate pathping. So we'll type in pathping to the same
destination of 8.8.8.8. 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.
00:16:45
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.
00:16:59
And we'll go to 8.8.8.8 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.
00:17:18
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
place.
00:17:36
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 10.1.0.105. These are our source ports that we were using. And
we were going to port 443, which is the well-known port for HTTPS.
00:17:52
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.

00:18:07
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 10.1.0.105, which is the IP address of
this Windows machine itself.
00:18:27
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.
00:18:43
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
00:00:00
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
tools.
00:00:20
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.
00:00:40
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."
00:00:58
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.
00:01:15
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.
00:01:29
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.
00:01:44
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.
00:01:58
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.
00:02:13
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.
00:02:39
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.
00:02:55
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]
00:03:13
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.
00:03:34
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.
00:03:48
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.
00:04:04
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.
00:04:18
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.
00:04:36
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.
00:04:49
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
optics.
00:05:05
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.
00:05:21
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.
00:05:38
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

00:05:57
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.
00:06:17
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
day.
00:06:33
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
internet.
00:06:53
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.
00:07:07
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.
00:07:29
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.
00:07:54
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.
00:08:12

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.
00:08:32
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.
00:08:56
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 8.8.8.8, 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 8.8.8.8. And if we change the location-- for example, we try to
launch this from-- let's go ahead and launch it from Lisbon.
00:09:29
Let's go ahead and click on Go. And it will show us the path from the router in Lisbon over to
8.8.8.8. 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.
00:09:52
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.
00:10:07
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.
00:10:21
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.
00:10:36
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.

00:10:51
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.
00:11:06
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.
00:11:26
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
itself.
00:11:47
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.
00:12:10
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.
00:12:42
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.
00:13:17
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.

00:13:33
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.
00:13:51
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.
00:14:07
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.
00:14:23
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.
00:14:40
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.
00:14:54
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.
00:15:12
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.
00:15:26
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.
00:15:44
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
00:00:00
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.
00:00:17
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.
00:00:31
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.
00:00:54
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.
00:01:10
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.
00:01:38
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.
00:01:53

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
points.
00:02:21
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.
00:02:45
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.
00:03:07
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.
00:03:23
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.
00:03:46
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.
00:04:04
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.
00:04:24

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.
00:04:38
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.
00:05:02
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
out.
00:05:25
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.
00:05:44
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.
00:05:57
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.
00:06:14
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.
00:06:32
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.
00:06:49

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.
00:07:08
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.
00:07:28
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.
00:07:43
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.
00:07:58
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
safe.
00:08:16
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.
00:08:30
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.
00:08:45
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.
00:09:08
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.
00:09:20
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.
00:09:35
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.
00:09:52
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.
00:10:05
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.
00:10:33
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.
00:11:00
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.
00:11:16
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.
00:11:36
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.
00:12:06
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.
00:12:20
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.
00:12:44
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.
00:12:58
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.
00:13:10
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.
00:13:34
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
is [INAUDIBLE] by AC.
00:13:53
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.

00:14:09
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.
00:14:37
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
across.
00:14:54
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.
00:15:11
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.
00:15:26
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.
00:15:41
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
network.
00:16:04
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.
00:16:19
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.
00:16:34
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.
00:16:48
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.
00:17:09
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.
00:17:30
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.
00:17:46
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.
00:17:59
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.
00:18:20
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.
00:18:36
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.

00:18:51
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
00:00:00
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.
00:00:17
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 10.1.0.1, and for
configuration B, the default gateway's address would be 10.1.0.110. 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
config.
00:01:03
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.
00:01:22
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
gateway.
00:01:46
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.
00:02:06
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.
00:02:35
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.
00:03:08
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.
00:03:28
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.
00:03:44
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.
00:04:10
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.
00:04:49
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.

00:05:10
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 10.1.0.20. 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.
00:05:45
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.
00:06:05
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
computer.
00:06:22
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.
00:06:39
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.
00:06:55
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
devices.
00:07:14
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.
00:07:35

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
duplex.
00:07:58
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.
00:08:16
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.
00:08:34
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.
00:08:49
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.
00:09:09
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 8.8.8.8 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.
00:09:38
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.
00:10:00
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.

00:10:16
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.
00:10:48
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.
00:11:08
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 10.1.0.0, and they keep track of each other.
00:11:30
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.
00:11:46
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 10.1.0.106, and let's say it's been given a mask of 16, it's been given a
default gateway, a default router, of 10.1.0.1, which is all good-- if it also has been given a DNS
server of 10.1.0.40 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.
00:12:25
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 10.1.0.40, 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.
00:12:45
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.
00:13:05

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.
00:13:22
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.
00:13:44
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 10.1.0.1 with a mask of 255.255.255.240. Well, here's the problem
with that.
00:14:15
If this sub network that we're really supporting is a /16, the range for that subnet is 10.1.0.1-- that's
the starting address-- all the way to 10.1.255.254. 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.
00:15:17
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.
00:15:33
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.
00:15:54
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.

00:16:17
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.
00:16:42
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.
00:17:01
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.
00:17:20
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
router.
00:17:36
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
10.1.0.0/16 IP subnet.
00:17:58
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.
00:18:16
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.
00:18:39
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.
00:19:07
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.
00:19:33
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.
00:19:52
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.
00:20:19
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.
00:20:36
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.
00:20:57
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
network.

00:21:34
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.
00:21:53
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.
00:22:17
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.
00:22:43
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.
00:23:02
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.
00:23:19
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.
00:23:36
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
be.

00:24:02
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.
00:24:41
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.
00:25:11
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.
00:25:29
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.
00:25:51
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.
00:26:09
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.
00:26:24
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.

00:26:40
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.
00:26:54
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.
00:27:14
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.
00:27:37
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.
00:27:59
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.
00:28:12
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.
00:28:36
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.
00:29:02

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.
00:29:23
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.
00:29:42
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.
00:29:58
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.
00:30:16
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.
00:30:39
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.
00:31:00
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.
00:31:15
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.
00:31:48
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.
00:32:10
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, 224.1.2.3. 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.
00:32:56
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.
00:33:11
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.
00:33:30
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.
00:33:44
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
00:00:00
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.
00:00:22
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.
00:00:40
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.
00:01:13
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
providers.
00:01:35
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.
00:01:59
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.
00:02:15
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.
00:02:29
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.
00:02:44
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
connections.
00:03:01
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.
00:03:32
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.
00:04:05
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.
00:04:20
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.
00:04:45
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.
00:05:00
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.
00:05:26
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.
00:05:39
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,
00:05:56
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.
00:06:09
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.
00:06:35
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.
00:06:48
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.
00:07:35
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
Rate.
00:07:52
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.
00:08:13
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.
00:08:51
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.
00:09:12
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.
00:09:34
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.
00:09:56
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 interface serial 2/1. And in this
demonstration, we'll imagine that we have a leased line that's set up from a service provider
between router two and this branch office router and we'll implement point to point protocol for the
layer 2 protocol to use on these wide area network interfaces.

00:10:22
And let's also set the speed to 64,000 bits per second. And the reason that we're doing that here in
the demonstration is just to reinforce the concept that wide area works are typically much slower
than the high speed local area networks that the WAN link is connecting together.
00:10:38
So here at the branch office, we have a local area network. At the headquarter over here, we have a
local area network, and the WAN connection is connecting those two high speed local area
networks together. So here on router two, we'll go into Configuration mode, and we are on a Cisco
IOS router.
00:10:53
Again, the syntax is going to vary a little bit depending on which flavor router or which vendor's
router you're using. We'll go into interface configuration mode for serial 2/0. That's the special
compartment, if you will, where we can apply commands to that interface.
00:11:08
We'll set the encapsulation to point to point protocol. Next, we'll give this interface an IP address of
10.5.0.2 with a 16-bit mask. We'll specify the clock rate of 64,000 bits per second. And we'll bring it
up with a no shut down command, and then we'll exit completely out of our Configuration mode.
00:11:28
And now the interface is up, our next stop is right here at the branch office router. Let's go there
next. Here at the branch office, we're using interface serial 2/1 to connect to the service provider's
wide area networking circuit that we have purchased the use of or leased the use of from that
service provider.
00:11:46
We'll specify that we want this interface to use encapsulation PPP. You know what the best layer 2
protocol is? It's the one that's compatible with the layer 2 protocol on the other side. So because R2
is using PPP, we'd want the branch office to use PPP because they're going to be talking directly to
each other over the leased line.
00:12:04
We'll give the branch office interface an IP address of 10.5.0.4 with a 16-bit mask. We'll give it a
clock rate of 64,000 bits per second. We'll bring up with the no shutdown. Now just for a moment, I
want to do a show command. I just wanted to verify that the encapsulation at layer 2 is PPP.
00:12:22
That looks great. I also want to verify that the interface is up. So here in the output, it indicates that
serial 2/1 is up and the line protocol is up. So we can often think of this as layer 1 as the first up and
layer 2 as the second up for the layer 2 protocol.
00:12:38

And then next, I just want to verify that here on the branch router, that we have a routing protocol
that's currently enabled. So on this Cisco router, the command show IP protocols indicates the
routing protocols that are currently in place. This says I have RIP, and specifically, it's RIP Version 2
that is dynamically learning and sharing information.
00:12:55
And currently, I'm including all networks as part of this routing process. So what that means is if
this link is successfully up and router two is also running the RIP Version 2 routing protocol, that
means all the headquarters routes, for example, the 10.1, the 10.2 and so forth, all those routes
should be advertised up to the branch router and should be part of that branch router's routing table.
00:13:16
And one way of verifying that is with the command show IP route RIP. Again, the actual syntax
you're not responsible for in Network Plus, but it's the concept I'm driving home. So here in the
routing table, this branch router knows about the 10.1 network that's over by R1, the 10.2 network,
which is the network between R1 and the firewall, the 10.3 network, which is our DMZ, the 10.4
network-- 10/4, good buddy-- that's the network between router two and the firewall.
00:13:41
And it also knows about the 192.168.1 network, which is this network right here between router two
and our service provider. And here in the output of the show command, I just told it to show me the
RIP learned routes, and because this network, which is 10.5, is directly connected, that's why 10.5 is
not showing up here in this output.
00:13:59
It's only showing me the routes that it learned via RIP. If we change that command a little bit and
just do this show IP route without the RIP, then it would show us all the routes this router knows
about, which include the directly connected 10.5 network right there.
00:14:14
So on this router, because we have routes to all of the HQ networks, we should be able to ping, or
reach a device on one of those networks. So if we did a ping, for example, or a trace route to one of
R1's IP addresses, let's do that. Let's do a trace route to 10.1.0.1, and that will show us each of the
hops in the path.
00:14:32
That also helps us to verify full connectivity from the branch router all the way to R1, and all the
devices between R1 and the branch router have routes all the way back to the branch router. In this
Nugget, we've taken a look at wide area networks and an example of implementing one, and the key
thing about wide area networks is that we're usually using or leveraging or purchasing a network
that belongs to somebody else.
00:14:54
In our example here, we're leveraging or using a network that is being leased to us from a service
provider, and that WAN circuit is allowing us to connect our headquarters network to our branch

office. I am glad that you joined me for this Nugget. I hope this has been informative for you and I'd
like to thank you for viewing.
WAN Technologies
00:00:00
Everybody WAN Tech tonight! When I wrote out WAN Technologies, I made the short-cut of tech.
That song came to mind. In this Nugget, you and I get to chat about some additional WAN
Technologies that might be used either inside these service provider cloud or as well as connecting
to a service provider itself.
00:00:18
And with that, let's begin. Back in the '80s, when I first started working with computer networks,
the internet as we know today was not like the internet as we know today. I mean the internet
existed, but it wasn't easily accessible. And it didn't have the millions of other devices that are also
connected to the internet today.
00:00:37
So let's say this is our building that we work at, and let's say we go home for the day, and we're
sitting in our home. Why does my house look like a telephone? I don't know. So we're sitting at
home, and if we needed a remote access into the network, it's very likely we could use a network,
but the network we would use was the PSTN, the Public Switched Telephone Network.
00:00:57
And we take our computer, which speaks digital, we would connect that to a modem. A modem is a
fancy device that converts analog to digital and digital to analog. And that's why it's called a
modem, a modulator demodulator. And through my phone line, using unshielded twisted pair, it
would connect into the phone network.
00:01:16
And then using that Public Switched Telephone Network, which my company was also connected
to, I could remotely connect to some device-- they often refer to it a NAS. And NAS stands for
Network Access Server. It's a server that also, in this case, was connected to the Public Switched
Telephone Network, which could allow me to connect.
00:01:33
And it, in those days, also had a modem, or equivalent, over here on its side as well. And that
connecting over the Public Switched Telephone Network was known as dial-up. You basically
dialed a phone number and then connect at very low speeds to the device that you wanted to
manage or connect to.
00:01:48
Now, at headquarters, it's very likely that they had capacity for lots of connections to come in over
the Public Switched Telephone Network. So if they wanted to support, for example, 12 or 13 or 14
users who all wanted to connect remotely using the Public Switched Telephone Network, instead of

having 12 or so sets of lines, they would probably use one digital line and use something called
ISDN, which stands for Integrated Services Digital Network.
00:02:12
Think of it as digital telephone lines. So they could have one cable that went over to the Telco
company. So we go ahead and draw a Telco companies down here. And so telephone carriers also
have links between them, and they happen to call these trunks. That's where we got, in ethernet, the
concept of a trunk as well.
00:02:30
It's a connection between these providers of Public Switched Telephone Networks that can carry
multiple calls simultaneously. Just like an ethernet trunk can carry multiple VLANs, a phone trunk
has the ability to carry multiple calls. So in any event, getting back to our data center here.
00:02:45
We'd have ISDN interface on one of our devices. If we had ISDN here, the ISDN could support
multiple calls over that one ISDN link that went out to our Telco company. So in addition to using
those for remote dial-in from users, the ISDN could also be used for the telephony inside of the
building as well.
00:03:03
So back in the day, before we did Voice over IP, we used to have separate networks, a separate
network just for telephony and telephone stuff and a different, completely separate network, for
data. However, now what we do is we integrate the two together.
00:03:16
We have a very reliable data network. And then we digitize that voice and use the same data
network to carry those packets. And we refer to that as Voice over IP, or VoIP. Depending on what
type of service we get from our service provider, we could be using fiber as the link between the
service provider and ourselves.
00:03:36
And some of the terms regarding fiber are SONET, DWDM, and CWDM. SONET stands for
Synchronous Optical Networking. And whenever I see SONET, I also think of the acronym SDH,
which stands for Synchronous Digital Hierarchy, which boils down to using fiber optics and light
frequency to send the bits across our networks.
00:03:59
And whenever we get throughput, whether it's throughput via fiber or via copper, usually we just
want more. With a rebel yell, you want more, more, more. And that's what users and companies
want. And one method of getting a lot more throughput with fiber is to use some really creative
technologies called WDM.
00:04:21
WDM stands for Wavelength Division Multiplexing. And the concept of multiplexing is sending or

receiving multiple sets, or channels of data, at the same time. So instead of just using one frequency
of light, what we do is we can have one channel using one frequency and another channel using a
different frequency, for example, a different color on that same fiber optic cable.
00:04:43
So the acronyms CWDM stands for Coarse Wavelength Division Multiplexing, and DWDM stands
for Dense Wavelength Division Multiplexing. Now, dense not in the sense that, hey, this is dumb.
But dense in the fact that it can get so many different channels, it's just crazy, a very dense number
of channels on one piece of fiber.
00:05:04
As an example, I think dense can support-- and it varies on the technology but-- about 96 different
channels at the same time. Think of that as different chunks of frequencies all being used at the
same time, 96 different channels. And depending on how that's use, we might be able to get up to
100 gigabits per second on each channel.
00:05:23
So when we talk about getting more, more, more, that is absolutely a way of doing it, with Dense
Wavelength Division multiplexing. And with Coarse Wavelength Division Multiplexing, it has
around 16 channels, or frequency sets, that it can use. And those around 2.5. And as technology gets
better and better, it's possible that we might be able to even get more possible throughput and more
channels with those technologies.
00:05:46
So in our MDF, if we had a device that was going to integrate or connect to a Dense Wavelength
Division Multiplexing or Coarse Wavelength Division Multiplexing, it's very likely we have a
switch that had these SFP port that we've talked about previously. And just as a reminder, the
evolution was we had GBICs back in the early days.
00:06:05
And now more popular are the SFPs, the Small Form Pluggable modules that we would plug-in.
And they have SFPs that are specific for the frequencies, or groups of frequencies, that we want to
go ahead and use. So we would plug-in the SFP, and that SFP would have-- as far as the
termination, it might a fiber LC connector or the other connector types that we talked about in the
Nugget we had on fiber optics.
00:06:28
There also is-- and I don't know that Network Plus is going to ask you. But there's also something
called a C-form Pluggable, which for short is just CFP. CFP is designed for 100 gigabit. It just has
the ability to support even more. So to terminate the fiber, we're likely going to have an SFP or a
CFP module that would fit into our switch.
00:06:50
And then, again, we just take the fiber cable that's terminated with the type of connector that the
SFP or the CFP supports and then connect it to that module. So if we were getting a leased line from

our service provider, for example, between our branch office, in our central headquarter site.
00:07:05
In the US, we very likely may be using a T-carrier. We talked about T-1S and T-3S. In our previous
Nugget on WAN Fundamentals. And outside the US, instead of having T-carriers, some countries
use E-carriers, and so they have writings such as E-1 and E-3. So and E-1 is around 2 megabits per
second. And I'm running just a little bit.
00:07:26
And an E-3 would be 34 megabits per second. And if we're using optical, we have optical
measurements as well. So here's a sample of two of them, OC3, for optical carrier 3, and OC12,
optical carrier 12. OC3 is about 155 megabits per second while an OC12 is around 622 megabits per
second. And a higher number, with all of those, represents increased or greater amounts of
throughput.
00:07:53
So the Ts and the Es are representing copper, and the O represents optical. What if we have a branch
office-- Let's say this is branch office 1, and we have another branch office, number 2. And for the
purpose of discussion, let's say branch office 2 is not within the reach of any service provider.
00:08:10
So for our discussion, we'll say that no carrier, no service provider, has access or provides access
physically where that branch office is. The first question we might ask is, why in the world do we
have a branch office that has no possible service providers? That'd be the first question.
00:08:25
However, hypothetically, for our case, what we could do is we could use satellite. So at this branch
office, we could put in a satellite dish that could communicate with a satellite that's orbiting the
planet. And at some point, somebody else on the Earth-- let's say it's our service provider over
here-- that is also able to communicate or that satellite connection.
00:08:45
So the signals could go up to the satellite and then down to the service provider, and vice versa. And
that could facilitate our branch office 2 connectivity over to our headquarters location. Now, the big
problem with satellite is-- well, there's two actual problems.
00:08:59
One is speed because we're not going to reach the speeds that we could with copper or fiber, and the
other big killer is latency. If we have any applications, such as voice or video, that have any real
time or near real time requirements for the application to work, the latency or the delays that
satellite is going to introduce, is probably going to break most of those time sensitive applications.
00:09:22
For example, if we had a user over in this branch office-- let's call him George. And George was
using a Voice over IP application to call and talk with Lois, over here at the corporate headquarters.

Can you imagine what a bummer it would be if it took 1 to 2 to 3 seconds for all the traffic that
George is sending into the network? These are digitized voice packets to be received by Lois.
00:09:42
It'd be almost unbearable for George and Lois to have a conversation with that type of latency, that
type of delays. So let's say we use these satellite services because it was our only option, and then
we got an email message saying that there was a carrier that was supporting WiMAX.
00:09:57
Now, WiMAX is a wireless technology. Some people have referred to it as Wi-Fi on steroids.
WiMAX actually stands for Worldwide Interoperability for Microwave Access. So now, if the
service provider had WiMAX where the signal were arrange at the branch office, and at the branch
office, we also had a WiMAX antenna that we could use to communicate on that WiMAX network,
that would be a lot faster than sending signals up to a satellite into space and having those signals
come down to the service provider.
00:10:26
Another really affordable access method that we can use is called broadband cable. For example,
let's say that you and I are at this house. It's a residential location. There's a very good chance that
that house may have cable network services from a cable company that's providing that cable
services.
00:10:43
Now, the cool thing about coax cable is that we can send a whole bunch of different frequencies
down that cable at the same time. And that's partly why it's called broadband cable. So in our Local
Area Networks, we use technologies like 100BASE-T or 1,000Base-T. The base representing
baseband, one signal at a time.
00:11:02
However, with broadband cable using a coaxial cable, we can indeed send multiple signals. That's
why a cable company can deliver voice services as well as TV and internet over one common
connection, that coax cable that comes into the residents. Now, what do we do in a house if there is
no cable? I don't know.
00:11:23
Read a book? Well, one of the answers might be using DSL or ADSL. DSL stands for Digital
Subscriber Line, and the most popular implementation of digital subscriber line is known as
Asymmetric Digital Subscriber Line. Asymmetric means that it's not the same.
00:11:40
Upload and download are not the same speeds. Because most people are going to have the need for
downloading, perhaps the upload is set for 1 megabit per second, and the download is set for 3
megabits per second. That's an example of asymmetric when we're talking about upload and
download.

00:11:58
So DSL, it operates over twisted pair. So it there was a telephone company-- so we'll put it back a
Telco company here-- and they have unshielded twisted pair that goes into the house, they can use
that unshielded twisted pair to integrate these signals, for example, for internet access or for
network services over that unshielded twisted pair.
00:12:17
ATM stands for Automatic Teller Machine. That's what I always thinking about when I see ATM.
However, it is also a fairly high speed technology that a lot service providers have used in the past,
and it stands for Asynchronous Transfer Mode. And that Layer 2, it uses something called cells for
the movement of data.
00:12:34
So if our service provider was providing us connectivity via ATM, we would have an ATM interface
on one of our devices, very likely a router, that will allow us to connect using this ATM circuit.
Now, PPP, the Point-to-Point Protocol, we've discussed in our WAN Introduction Nugget.
00:12:51
And multilink PPP allows us to combine multiple serial links using multilink PPP to get greater
throughput. In a previous Nugget, we took a look at how we could take multiple links on ethernet
and logically bind them together to create one larger link that had greater throughput.
00:13:08
Well, in Wide Area Network connectivity, if we have multiple serial connections that go, for
example, between us and our service provider, we can logically use those as one logical circuit with
a feature called multilink PPP. And that's basically because two links are better than one.
00:13:25
And that's what multilink PPP can bring to the Table. Another protocol that's really cool is MPLS.
MPLS stands for Multi-protocol Label Switching, and it's a method that a lot of companies don't
use, but a lot of service providers do use. And what it allows a server provider to do is to create
these paths inside of their service provider network-- they're called LSPs, Label Switching Paths-for them to move traffic through their networks.
00:13:50
And then based on using MPLS, a service provider can provide some really cool options to
customers. For example, this service provider could tell ACME Incorporated that it could build a
logical Layer 2 circuit between the headquarter site and the branch office.
00:14:05
So if we had a router here and a router here, both of these routers would think they're on the same
Layer 2 network very similar to the same VLAN as each other. Now, would the speed be great?
Well, it depends. How much are you paying the service provider for a throughput? Another really
cool option, if the service provider is running MPLS internally, is a feature called Layer 3 VPNs.

And how that would work is the service provider would actually neighbor up and become neighbors
with the branch office.
00:14:33
Normally, we don't neighbor up with the service provider. We don't share routes directly with the
service provider. We just use the links the service provider gives us. But with Layer 3 VPNs, we
actually start becoming neighbors with the service provider.
00:14:46
The branch office tells the service provider all of its routes. The headquarters' router tells the service
provider about all its routes. And then using Layer 3 VPN services with MPLS in the cloud, the
service provider keeps track of all that customers traffic to make sure they can route between each
other.
00:15:02
Now, with just one customer, that's no big deal to keep track of the routes between the branch office
and the headquarters site for ACME Incorporated. But if the service provider had-- let's say 1,000
customers-- the service provider could create 1,000 of these logical Layer 3 VPNs and keep all of
their customers separately isolated from each other and still provide full connectivity leveraging
MPLS in their own cloud.
00:15:27
And we wouldn't normally find MPLS being used inside of a company like Acme Incorporated. It's
mostly a service provider. Next, we have GSMCDMA. And these are wireless technologies. GSM
stands for Global System for Mobile communications. That's what GSM is.
00:15:44
And CDMA stands for Code Division Multiple Access. And for Network Plus, I believe the most
important aspect is just being aware that GSM and CDMA are referring to wireless technologies
that can be used for network access. And these are primarily used by devices, such as cellphones
and smartphones that have voice and data abilities through the carrier's network.
00:16:07
So regarding some of the terms, we have G. Now, G stands for generation. So for example, at one
point, there was 1G and 2G and 3G. And you might say, oh 3G, I recognize that. And yes, as the
technology gets better and better, they're just referring to those as generations.
00:16:25
So now there's 4G and there's also something called LTE. LTE stands for Long-term Evolution. It's
really a direction that we're going and not an exact specific set of technologies that you can put your
thumb on and say, yup, that's LTE. That's exactly LTE.
00:16:41
Some of the other acronyms here, we have HSPA+ which stands for high speed packet access. The
3G is just representing the third generation, which has the ability to support voice and data. And

Edge is also an acronym. It stands for Enhanced Data GSM Environment.

00:16:58
So all of these are simply wireless technologies that can be used primarily in mobile devices. Now,
just be aware that if Bob or Lois is using these technologies, they could be then walking into their
company and then switching over to Wi-Fi, which is the 802.11 standards for their data. And that
makes sense because the cost inside of our network, by using an access point with Wi-Fi, is going to
be virtually free compared to using the data network of our carrier who might have caps on the
amount of data that we can send and receive.
00:17:29
And then once we see that cap, they may charge us additional fees. Or, even if they don't charge us
additional fees, it's very likely that our throughput is going to be way higher on the access point
with Wi-Fi in our company compared to using these cellphone provider's network, whether it's 3G,
4G, or LTE. And one last technology down here, Metro-Ethernet is becoming more and more
popular.
00:17:51
A service provider may connect to us and allow us to connect to the service provider using ethernet.
It would look something like this. The service provider very well may have a device, such as a
multi-layer switch, a device that does Layer 2 forwarding and Layer 3 routing physically at our
company.
00:18:08
That could be called customer premise equipment. It's equipment that's at the premises of the
customer. So the service provider's connection to this device, it could be lots of different things.
They might have fiber. They may be using copper. They could even be using wireless because the
backend connection from the service provider to this switch that they've put on our premises-- what
we could do is go from an ethernet port on that device and plug it into our network.
00:18:33
That would be our WAN connection. It looks and feels like ethernet. And on the backend, they're
doing whatever they want to do as far as the forwarding of that data. So inside the service provider
network, they could be using MPLS. They could be using ATM.
00:18:46
They could be using DWDM, and lots of other technologies, because most of that in the cloud, the
service provider network, is going to be transparent to the end user. So if they had that same service
at our branch office, we might have ethernet connections from the branch office to our service
provider, ethernet connections from our main office to the service provider.
00:19:05
And here's where we would have to be a little bit careful because even though we have ethernet-let's say it's 10 megabits or 100 megabits or a gigabit-- that doesn't mean that we have that much
throughput from the headquarters location our to the branch office.

00:19:18
So even though we have fast ethernet, for example, maybe our guaranteed throughput is 1 megabit
per second between the two offices, between the branch office and headquarters site. And if that
was the case, we might want to set up some additional traffic shaping for that link to make sure that
we're not cramming, or trying to cram, so much information over that WAN connection to the point
that most of it would not make it because if we send 2 or 3 megabits per second into the cloud,
what's going to happen? And if the answer is I'm not sure what's going to happen.
00:19:48
That's scary. If traffic is going to be deleted or not make it to the other side, we want to control that.
We don't want to just leave it up to the cloud and say, I hope some of it makes it. We would want to
use traffic shaping, which is a form of quality of service, to make sure that we control what traffic is
sent, how much of it sent, in order to make sure we have reliable communications over the WAN
connection between our branch office in our headquarter site.
00:20:13
In this video, we've taken a look at some additional acronyms and technologies that are often used
both inside the service provider's cloud as well as for the connection from the service provider to
our location. I appreciate you joining me for this Nugget.
VPNs
00:00:01
Is there a method that we can use to protect our traffic as it goes over untrusted networks, such as
the internet? To provide confidentiality, authentication, and data integrity, the answer is absolutely
yes. And we call them virtual private networks. Let's begin.
00:00:16
I'd like you to imagine that it's Tuesday afternoon. You and I have just gone out and had a great
lunch. We're on our way back into the office. And, lo and behold, who do we see but our manager
who says, hey, I need your help. And we're like, what can we do for you.
00:00:28
And our manager says, well, I'm going to be out of the office for like a week. But I still access to
the company resources while I'm out. Can you set that up for me securely? And what do we say?
Absolutely, yes. And one of the primary methods that we might use to supply our manager with that
access is to use something called a Virtual Private Network, or VPN.
00:00:49
And it goes something like this. Let's go ahead and say this represents the house of our manager.
Let's call our manager Bob for this discussion. It's very likely that Bob has connectivity to the
internet. Maybe he's using DSL, Digital Subscriber Line, or he has cable-- so he's got a cable
modem, and has internet access through his cable provider.
00:01:08

And as a result, he has fairly high-speed connectivity to the internet. What we could do is we could
deploy something called a VPN gateway. And a VPN gateway is a fancy term for a device that
allows the negotiation and set up of a VPN connection, if you will, between itself and some other
device.
00:01:29
And many times, the VPN gateway functionality can be integrated as part of an existing firewall. So
if you've got a unified threat management system or a firewall that supports the ability to terminate
and be the endpoint for a virtual private network, the firewall would be doubling up and acting also
as the VPN gateway.
00:01:47
So whether it's a separate device or appliance, or it's integrated into the firewall, the functionality of
a VPN gateway is to negotiate, set up, and provide secure access or a virtual private network
between itself and some other endpoint for a point to point virtual private network tunnel.
00:02:03
Now, in our case, this would be an example of a Host-to-Site. That's what the blueprint calls it. In
the business we simply call it a remote-access VPN tunnel, where Bob's computer that's connected
to the internet is going to build this virtual private network using the internet to connect over to our
VPN gateway.
00:02:20
So we would say that Bob is using a remote-access VPN. He's getting remote-access over that VPN.
And oftentimes, there's a little piece of software that's running on Bob's computer that's acting as a
VPN client, that does the thinking on this end while we connect to a VPN gateway that does the
thinking on that end.
00:02:37
And when I say the thinking, I'm talking about the negotiation and the set-up of a virtual private
network. A logical connection between Bob's computer and the VPN gateway. Now the benefit of
having a virtual private network that's set up is, number one, we have really good authentication
capabilities.
00:02:53
For example, the VPN gateway's not just going to say, ah, I've got a request for a virtual private
network. Come on in. Have a good day. Instead we're going to do authentication. And the
authentication is very likely going to be done against a AAA server. Let's say this is a AAA server.
00:03:07
And in a previous Nugget, we've discussed the concept of authentication, authorization, and
accounting. So when Bob is authenticating the VPN gateway, can check with the AAA server to
verify that Bob's credentials that he's supplied-- like his username and password, as an example-are accurate.

00:03:24
So the VPN gateway makes the request of the AAA server. Says, hey, it's Bob. Here's his password.
And then the AAA server can give us the two thumbs up or two thumbs down regarding whether or
not that's the correct username and password to allow access. So when we're authenticating users,
like Bob who wants to get access through the network, it's very likely that we're going to use the
AAA protocol of RADIUS between the VPN gateway and the AAA server.
00:03:49
RADIUS is an open standard for AAA that's used between devices like a VPN gateway, who wants
to check with a AAA server regarding authentication. In this case, the authentication of Bob the
user. Now, there is another protocol that we can use between a device and the AAA server.
00:04:04
It is proprietary, and it's called TACACS+. And it is proprietary to Cisco. And it is generally not
used if we're doing the authentication of the average user, like Bob, who just wants access through
the network. However, if we're trying to authenticate administrators-- for example, let's say that you
and I are administrators for this network.
00:04:24
And let's say we're going to go ahead and log into the switch, and we're going to make
configuration changes. It's very likely that, in that scenario, when we're trying to authenticate users,
we could still use the same AAA server. But it's very likely that we're going to be using TACACS+
in a Cisco environment for the authentication of the administrators.
00:04:42
In this case, that'd be you or I. And then, subsequently, could also be used for authorization for the
individual commands that we're trying to use on this switch regarding managing that switch. And,
of course, the accounting records would also include details of what we did while we were there.
00:04:57
So in the case of end-use authentication, it's very likely that most of the time we're going to use
RADIUS as the AAA protocol between the VPN gateway and the AAA server. Now, in the old days,
like 20 years ago, before we had the internet to leverage to build our virtual private networks, we
might have used the public switched telephone network.
00:05:17
So Bob may have had a modem that connected up to the PSTN. And we may have a device at our
network that was also connected to the public switched telephone network. And on the company's
side, maybe we have ISDN to support multiple calls simultaneously. But in either case, this device
here used to be called a RAS, Remote Access Server, because it can supply access for remote users,
or individuals who want remote access.
00:05:41
And more currently, we'd refer to these as NAS, a Network Access Server. Simply a device that is

providing access. So could a VPN gateway be loosely referred to as a remote access server or a
network access server? The answer is yes, because it is providing remote access to additional
resources.
00:05:57
But it's doing it via VPNs, Virtual Private Networks, as opposed to a connection over the public
switched telephone network. So we're going to be using the VPN, and not the PSTN. So once Bob
successfully authenticates the VPN gateway, he's going to negotiate the virtual private network-this logical pipe, if you will, this logical tunnel between the VPN gateway and Bob.
00:06:17
And the benefit of the VPN tunnel is, not only the authentication-- we make sure it's really Bob
before we build the tunnel-- but we also have confidentiality. And that's due to encrypting
everything. So once Bob and the VPN gateway have this tunnel set up, all the traffic that is coursing
over this virtual private network, which is going over the internet between Bob and the VPN
gateway, everything is encrypted.
00:06:41
And in order to decrypt that information, a person would need the right keys. And for the VPN, the
only two devices that have the correct keys for the locking and unlocking of that data for the
encryption is Bob's computer, which is very likely running some kind of a VPN software client on
his computer to handle that end and the VPN gateway.
00:07:01
Anybody in the middle, who tries to eavesdrop on that traffic, if they collect it and capture it, even
if they do see it, they're not going to know what the heck it means because it's all encrypted. It's like
cipher text-- all gobbledygook. And without the correct keys to decrypt that information, that's
what's maintaining our confidentiality as we send the data back and forth between Bob's computer
and the VPN gateway.
00:07:22
Our virtual private networks also give us the benefit of data integrity. And that's done through a
concept called hashing. And two popular and very well-known hash algorithms are MD5 and SHA.
And there's several flavors of SHA. And the concept is this. If we have a packet that we send on the
network, and it's received by the VPN gateway, if the sender and receiver both run this really quick
hashing algorithm, they can come up with a number.
00:07:49
It's called a digest. It's just a really small string of characters that are generated as a result. So if Bob
runs the hashing algorithm, and then sends the packet, if the receiver receives that packet and then
runs the same hashing algorithm, it can compare the digest it generated to the VPN gateway to the
digest Bob sent.
00:08:06
And if they match, the VPN gateway knows that that packet has not been manipulated, or corrupted,

or tainted somewhere in the path between Bob's computer and the VPN gateway. For example, an
attacker trying to take a packet, change the content, then send it on its way.
00:08:22
And one of the things that prevents an attacker from just generating a new hash and attaching a new
hash is that we could also include some secret key information as part of that hash, which the
hacker has no knowledge of. So he wouldn't be able to recreate a new hash if he did manipulate the
packet and wanted to create a new correct matching hash.
00:08:41
So the concept of hashing is very similar, as we discussed previously, if we want to download a file
from the internet. If we wanted to download a file and verify that that file has not been corrupted, or
to verify that some hacker hasn't taken the file, added malware into it, repackaged it, and now we're
downloading the tainted file, the person who downloads the file could run a hashing algorithm
against it, look at that hash value, the digest, and then compare that against what's published on the
vendor's website.
00:09:08
And if the hash we generated matches the hash that's advertised or published by the person or entity
who created the file, then we can have a comfort level that we have data integrity, due to the hashes
matching. Now, besides an individual user who is building a virtual private network to the company
site-- in this example, the headquarters site-- we could also build what are called site-to-site virtual
private networks.
00:09:31
For example, what happens if this serial WAN connection that we're paying for fails, and we now
have lost connectivity between the headquarters site and our branch office? What could we do? If
the branch office is also connected to the internet-- hopefully through a different service provider,
assuming the other service provider completely failed-- what we could do is we could build what's
called a site-to-site virtual private network between the branch office and our headquarter location.
00:09:58
And this end of the tunnel could be terminated at the firewall if it's acting as a VPN gateway, or at a
separate device that's a dedicated appliance for VPN services. And it's pretty cool. We have all the
same benefits of a virtual private network. We've got the authentication.
00:10:13
Both sides could verify that they're talking to the other correct party. We have confidentiality due to
the encryption. And we have data integrity that would be provided as part of the VPN through
hashing services. And you might think, well, why not do this all the time? Let's just get a high-speed
internet connection and not have any kind of a leased line or packet switch connection between the
two sites.
00:10:34
Just let's use the internet. And a lot of companies do that. One thing we'd want to consider though is

what is the guaranteed level of service or service level agreement that we have as we send packets
over the internet. It might be kind of hard to control, for example, things like latency and delay, if
we have applications that are sensitive to those kinds of delays, such as Voice over IP or video
applications, that may not do extremely well if there's significant delays or latency that's introduced
by going over the public internet.
00:11:02
Then one other option we have with virtual private networks is we could build them host-to-hosts.
So we could have a computer here. Let's say it's PC 2. We could have PC 1. And they could build a
virtual private network between them. So if this line represents the virtual private network, maybe
their physical connectivity goes like this.
00:11:19
Here's router one. Here's router two. Here's router three. So the red path is the physical path. But
logically, they would have this virtual private network that pretty much makes them look like
they're on the same network as each other. And there's two major families of technologies that are
used to build these virtual private networks.
00:11:37
One is called IPsec, because is designed to protect, encrypt, and provide data integrity for individual
Layer 3 IP packets. So with IPsec, each and every packet going back and forth between the branch
office and the headquarter site would be protected if we're using IPsec.
00:11:53
Another technology that is becoming very, very popular as well for VPNs is using SSL/TLS. Now,
we've touched on these acronyms previously. SSL stands for Secure Sockets Layer. And TLS is
Transport Layer Security. You and I know this as HTTPS. And because most computers' browsers
support HTTPS, a lot of vendors are using and leveraging that HTTPS capability that's built into
computers to support remote access.
00:12:21
So typically what we'll see is, if we have site-to-site virtual private networks-- for example, between
a branch office and a headquarters office-- if they're building a site to site tunnel between those two
locations, it's very likely going to be using IPsec.
00:12:33
And if it's a remote access that's connecting to, for example, a headquarter site, it could be using
IPsec or SSL/TLS. And the trend is moving more and more to SSL/TLS because most customers'
computers already support HTTPS without having to install a huge client at each PC to make the
VPN functional.
00:12:55
Another technique that we might see for site-to-site VPNs is building what's called a GRE tunnel.
GRE is an acronym for Generic Routing Encapsulation. And we can build, for example, a GRE
tunnel, a logical connection from, for example, headquarters to the branch office.

00:13:13
Now, the problem with a GRE tunnel, all by itself, is that it is not secure. So in many
implementations, what companies will do for site-to-site tunnels is they will build a GRE tunnel.
And then they'll add on top of that IPsec to protect the individual packets that are going back and
forth over the GRE tunnel.
00:13:33
And I'd like to add one more little tidbit here regarding remote access. There's also protocol such as
Point-to-point Tunneling Protocol, which acronym is PPTP, if you ever see that. It's basically a VPN
technology. Now, the challenging thing is the actual protocol for PPTP doesn't spell out exactly how
the encryption should be done to protect the packets as they go back and forth from a remote access
client to a VPN gateway.
00:13:58
However, the implementations of PPTP-- for example, by Microsoft, with their PPTP-- does include
the encryption that does provide that confidentiality for a PPTP session. So if we see the acronyms
PTP, that could just stand for point-to-point. And PPTP is the point-to-point tunneling protocol,
which is a protocol that we might use as a remote access VPN client to connect to our VPN
gateway.
00:14:21
So I thought it would be fun to share with you a VPN client that I currently use on my computer. So
this is off my live computer. And I will do some editing to remove any kind of confidential
information here. But this is a Cisco AnyConnect Secure Mobility Client.
00:14:36
This is some software that I run on my local computer that allows me to successfully build virtual
private network connections or tunnels to CBT Nuggets corporate. So this allows me to effectively
communicate on the network at CBT Nuggets from this computer, which is here in Nevada.
00:14:51
And in setting this up, it asks me for authentication. I had to prove who I was. It then negotiated the
tunnel. And now all the traffic that I send from my PC over this VPN tunnel is protected. And it's
confidential due to the encryption provided by the virtual private network.
00:15:05
So currently, I'm doing tunneling for IPv4. The word Split, from a VPN prospective, simply says
this. Here's my computer. So I'm connected to the rest of the world. And I've also got a virtual
private network over to CBT Nuggets. And what this split tunneling is saying is that at CBT
Nuggets, there is several specific networks.
00:15:23
Let's say there's network 1 and 2 and 3 and 4. And split tunneling says, hey, only send traffic for
these specific IP subnets over the tunnel. If you're going to some other destination, go ahead and

simply send that out naked, straight out to the internet.

00:15:38
And by doing split tunneling, from a VPN perspective, it takes a lot of load off of the server at CBT
Nuggets. Because, for example, if I go to yahoo.com or google.com, I was sending all my traffic
through the tunnel, those Google requests would go out to CBT, and then have to be rerouted from
CBT back out on the internet.
00:15:57
With split tunneling, only the traffic that needs to go to CBT is going to CBT when the VPN is up.
Currently it says that the duration of the tunnel has just been a little bit over an hour. Here's a virtual
IP address that I've been assigned. So any traffic I send over the tunnel to CBT Nuggets to their
networks, it's going to appear that I'm coming from the address of 172.16.3.26, which is a private
RFC 1918 address space. And that's recognizable, based on the first two octets of 172.16 that are in
that private RFC 1918 address space.
00:16:28
It's also showing right here the actual server on the internet the VPN gateway that I'm connected to.
And I have blurred that out in post editing for the benefit of security. And if we scroll down a little
further, it's indicating that we're using DTLS, which is a flavor of TLS, Transport Layer Security.
00:16:45
So this is a VPN based on SSL/TLS. as opposed to IPsec, for this remote access VPN. Here it also
indicates that I'm using AES, which is the Advanced Encryption Standard for confidentiality. And
I've also got SHA1, which is a hashing algorithm providing the data integrity.
00:17:03
And if we go over to Route Details, this is indicating that while the VPN is up, any packets that this
computer sends to any of these network addresses-- and I'm going to go ahead and gray out the one
that's not an RFC 1918 address space-- if my computer tries to send packets to those subnets, those
packets will be going over the VPN due to the split tunneling.
00:17:22
And any traffic that's not going to any of these specific subnets will be going out just plain Jane
naked out to the internet. And that's due to the split tunneling with the virtual private network that's
currently set up. And most vendors have their VPN functionality integrated into their firewall.
00:17:39
And that would be true for Check Point, and Palo Alto, a little company called Cisco Systems, and
others. In the old days, Cisco had this separate device called a VPN Concentrator, that was an
appliance that would be used as a VPN gateway. But that has been retired for many, many years.
00:17:59
And now Cisco and these other vendors are integrating that virtual private network functionality
into the firewall appliance itself. And often, this device will be a UTM, a Unified Threat

Management system, that does firewall services, VPN services, and more.
00:18:13
In this Nugget, we've taken a look at some benefits of using virtual private networks, some types of
virtual private networks, and the technologies that are primarily used to implement the virtual
private networks. I appreciate you joining me for this Nugget.
00:18:27
If you have a desire for more security, I would also encourage you to check out CompTIA's security
plus course right here at CBT Nuggets. And then, beyond that, there's also CCNA security on the
Cisco side. There's a CCSA course for Check Point on the Check Point side.
00:18:43
And we also have Palo Alto training all right here at CBT Nuggets. So after Network Plus, be aware
that those additional courses and resources are available to you as you increase your knowledge
regarding security products offered by multiple vendors. And I hope to see you in one of those
courses.
Virtualization
00:00:00
Let's get virtual, virtual. In this Nugget, we're going to take a look at how we can take a device that
normally would run on its own dedicated hardware and trick it. And we'll trick it into running what
it thinks is its own real hardware, but actually it's running as a virtual machine or a virtual device
inside of some other application.
00:00:20
Let's begin. I'd like you to imagine that you and I have been put in charge of these two servers,
which are currently on our DMZ. Maybe one of them is handling web services like HTTP and
HTTPS, and the other one is handling maybe email, SMTP. And one of the challenges with having a
single physical server for each of our services-- one for web and one for SMTP-- is that we may be
totally underutilizing those resources.
00:00:47
Maybe the web server is about 15% utilized at any given time, and the SMTP server, it goes
somewhere between 10% and 20%. But here's the question I have for you. How much of each of
these computers did we pay for? And if you're saying, well, Keith, I think we probably paid for
100% of them, you'd be absolutely right.
00:01:06
We pay for both computers, but we're only using a fraction of their capabilities. So in the world of
virtualization, one of the tricks we can play is we can have one physical computer, and on that
computer we can run something called a hypervisor. So the hypervisor runs on this physical
computer.
00:01:21

And what a hypervisor does for a living, it creates an environment for other devices and other
operating systems to run. So as an example of a very popular hypervisor provided by VMware, it's
called ESXi. That's what VMware named it. So we can install ESXi on this one physical computer.
00:01:40
And then inside the physical computer, we could have our web services running as a separate virtual
server, a virtual machine, running in this environment. And we can also have our SMTP server
running as a separate virtual machine. And the cool thing, running both of those virtual machines
inside of one physical computer, we're still only looking at like 35% utilization of this physical box.
00:02:03
So we've just saved ourselves some hardware, and we can also grow and very easily deploy
additional virtual servers using a virtualized environment. And one of the biggest players in that
space is VMware, another big player is Microsoft, and another player in that virtualization space is
Citrix.
00:02:20
And it makes a lot of sense to do virtualization for various services. So a large proportion of the
servers that are on the Internet today are running as virtual machines, virtual servers, on some
bigger physical box. And what I would like to do as a quick demo is let's go to computer 2 just for a
moment. And let's do a Trace Route from this Windows 8 machine out to the Internet to 8.8.8. So
here on computer number two, which is running Windows 8.1, let's go ahead and issue the tracert
command, because that's how you spell trace route on a Windows computer.
00:02:56
We'll do a dash d to tell it don't bother to do name resolution of each of the router hops in the path to
the final destination. And let's do a trace route out to 8.8.8, one of Google's DNS servers, and we'll
press Enter. So from this computer, the packet went to its default gateway.
00:03:14
Then it went to the firewall's address, then R2. Then it went to the service provider's IP address of
192.168.1.1, at least based on our topology. And then the next hop in that provider network was
10.72. And then it continued on through additional routers that are using public address space on the
Internet until finally it got to the final destination of 8.8.8. And now, it's time for Confessions with
Keith.
00:03:37
The confession I have is that most of this network topology that we're working with is also
virtualized. It's not physical gear. Let me show you what I mean. Starting with this computer right
here, this Windows 8.1 computer we were just looking at, that computer is not running on its own
hardware.
00:03:54
It's running as part of a hypervisor. It is virtualized. Now we have to kind of whisper when we say
that, because the operating system itself doesn't know. It just thinks hey, I'm booting up Windows 8,

and here's my hardware I have. And all that hardware is simply emulated by the hypervisor that's
providing that environment.
00:04:12
And for this environment, for that computer, I am in a VMware product for that hardware
emulation. Specifically, I'm using VMware Workstation. But I also could have used VMware's ESXi
hypervisor, as well. The Linux box right here that we have also taken a look at is also running as a
virtualized machine, meaning it's not running on its own physical hardware.
00:04:34
These two switches-- switch number 1 and switch number 2-- are also virtualized. The emulation
for these switches is being provided by a tool called GNS3. And I happen to be running version 1.x
of the GNS3 emulator. Now these switches are indeed running Cisco software, except the Cisco
software doesn't know that it isn't live hardware.
00:04:57
The software from Cisco thinks it's running on physical gear. And that also leads to these
connections between the computers and the switch. Those connections are all virtualized. So I
simply, in software, specified where I want those connections to be. And then the software, GNS3 in
this case, simply made those connections happen based on my instructions.
00:05:16
Now one thing that I did not emulate-- and it is real-- is the access point. So when we did our
wireless, I had a physical access point. And as part of that demonstration and part of that Nugget, I
also used a physical switch, because on that physical switch I had to do PoE, Power over Ethernet,
which was supplying the power over the ethernet connection to that access point.
00:05:38
In a sense, you could say they were both quote unquote "real". They were not virtualized. So when
we did our ping and computer 2 sent the information into the switch and the switch forwarded it
over to the router, router one is also a virtualized Cisco router.
00:05:51
It's running Cisco software on a virtualized emulator. And that emulator for the network here is
GNS3. The next stop was the firewall at .100 in our trace route. The firewall is, yet once again,
virtualized. So far, we've seen virtualized servers-- in this case we have a virtualized computer,
computer two-- virtualized switches, virtualized routers, and virtualized firewalls.
00:06:15
And then our trace as that packet got sent out to router two, router two is also virtualized. In fact,
everything except for the access point and the power over ethernet switch are all running as
virtualized devices on a single computer that's here in my office.
00:06:32
And if you're excited by that and thinking whoa, that is stinking cool, I am right there with you, my

friend. It is absolutely very, very cool. So after you finish Network+, there is a VMware course
called VCA. That's the VMWare Certified Associate course that's available here at CBT Nuggets.
00:06:50
I would encourage you to take a look at that. That would be a great warmup. We've also got some
GNS3 courses right here at CBT Nuggets. There's a course called GNS3 version 1.x Fundamentals
that will help get you up to speed with GNS3, the hardware emulator for networking.
00:07:05
And there's also a course on the Cisco side called CCNA hands-on labs that also uses GNS3 for the
hardware emulation. And I should also point out that our branch office, and the wide area network
connection that connects to the branch office, that's all virtualized as well as part of GNS3,
including the router that's sitting at the branch office.
00:07:27
Now you might be thinking wait, Keith, didn't you do a trace route from computer two all the way
to the Internet at 8.8.8.8? And the answer is yes, we did. So I do have some integration between the
virtualized network and a physical or real network. And that integration happens right here, between
the virtualized on the left and the physical and real Internet on the right.
00:07:50
So all of these devices on the left are using virtual network interface cards for their communications
on the network. And over here on the right, starting with this router right here, which is at
192.168.1.1, that is using a physical network interface card.
00:08:05
I should also point out that this one computer that's creating this entire virtualized environment, it
also has a physical network interface card that's allowing that connectivity between the virtual
world and the physical environment. And when I refer to the physical environment, that could also
include wireless as well.
00:08:21
There's also quite a buzz these days about something called SDN, which stands for Software
Defined Networking. And the concept of SDN is an idea that says let's take administrators-- so we
take the administrator-- and instead of having an administrator, for example, connect to a switch and
work at the command line interface to implement features like VLAN assignment and trunking and
so forth on each and every switch, let's separate the admin out and give the admin a beautiful,
graphical user interface that they can say here's what I want to have happen.
00:08:53
And then there'd be a software layer that could take that request and then apply it to the switch or
switches to implement that on the devices. So when I think of SDN, I think of George Jetson. Back
in the-- I think it was maybe the '70s, there was a cartoon with George Jetson, and his job at Spacely
Sprockets was to simply push the button.

00:09:14
Everything was automated to the point that's all he had to do was push the button, and then
everything happened for him in the background. So with SDN, an administrator would not have to
know the details of how to configure a switch port or a trunk, or how to configure a rule on a
firewall or how to configure an access control list on a router interface.
00:09:33
With SDN, the admin can say here's what I want to happen, and then through the software that is
interacting with both the administrator and the actual network itself, those changes could be
implemented. Again, going back to George Jetson, we hit the button.
00:09:47
Now I really don't think it's ever going to be as brainless as pressing a button and everything's going
to work, but I do want to point out that SDN is a very popular direction that companies are heading.
I also want to point out that, behind SDN, we still have all the interactions that are still going on.
00:10:06
For example, switches and routers and firewalls really are being configured. And if something goes
wrong or doesn't work correctly, having the knowledge and skills of what's really happening behind
the scenes will still be a very, very valuable skill set to have.
00:10:20
In the process of virtualizing switches and routers and firewalls and so forth, there are some
additional products that are out there for that purpose, including Cisco has a product called VIRL.
My good friend Anthony Sequeira has a course right here at CBT Nuggets on how to work with and
operate that product.
00:10:35
There's the GNS3, which we've just discussed, which has the ability to do some emulation. And
mostly these are tools that we can use for learning and modeling and practicing with designs and
concepts to build our skills and do proof of concept. And then for the production network, we might
actually use physical devices such as physical switches and physical routers and physical firewalls.
00:10:56
Or, we might mix and match. We might have physical switches, but perhaps we virtualize the router
and firewall functionality. And these can be delivered as virtual appliances, which is just saying that
we're running the same functionality, but instead of doing it on its own physical hardware, it's done
somewhere in software.
00:11:13
And VMware has a product called NSX which allows us to basically virtualize most of the network,
including our switches, our routers, our security, including virtual private network access that's all
simply implemented logically in software. And that, by the way, integrates very nicely with
VMware's Software Defined Data Center.

00:11:34
So SDDC, if you see that from VMware, that's the Software Defined Data Center, where all of our
servers and so forth are all virtualized. And then we can use VMware's NSX in conjunction with
that to virtualize the switches and routers that are connecting all of those virtual servers together in
this virtualized environment.
00:11:53
So as a little sneak peek here, this is our Windows 8.1 workstation, which is running inside of
VMware Workstation. And VMware Workstation is an example of a hypervisor, providing this
virtual environment this computer is running in. And for the network portion, I'm running GNS3. In
GNS3, here is PC 2-- actually this is an icon representing PC 2, which is a placeholder for that
virtual machine running in VMware Workstation.
00:12:19
This computer is representing a Linux box, specifically the Kali Linux box that we're using as PC
number one. And if we click on the Label tool, we can actually take a look at the interfaces
involved. So here's our two connections that are going between switch 1 and switch 2 that we
implemented port bonding with to make them appear as one logical EtherChannel, using the Cisco
terminology.
00:12:39
Here's our connection from the switch over to router one's interface 3/0, our connection from R1
over to the firewall. If we want to change the icon for any of these, we certainly could as well. And
with the icon change, it looks a little bit more like a firewall, or perhaps a router that has integrated
firewall services as part of it.
00:12:57
Then here we have R2. There's our WAN link out to the branch office. Then I've got switch 3 that's
connected to a cloud, and that cloud represents access to the rest of the network, specifically it leads
to the Internet. So that's a sneak peak at the behind the scenes of a virtualized network courtesy of
GNS3. In this Nugget, we've taken a look at some benefits of using virtualization, where each
device, instead of running it on its own dedicated hardware, can run virtually in a virtualized
environment courtesy of some type of a hypervisor, such as from VMware, GNS3, or other vendors'
products that are providing that virtualization service.
Network Based Storage
00:00:00
In this Nugget, you and I get to take a look at some of the benefits as well the technologies that we
can use for network-based storage. Let's begin. Back in the early days when I first started working
with network-based servers-- back then it was like Novell file services back in the '80s-- one of the
key aspects was to make sure we had a drive that was both reliable and fairly quick, by those
standards.
00:00:23

And one of the technologies for the actual hard disk in a server was to get a fairly powerful hard
disk controller. Now, this is an Adaptec SCSI controller, S-C-S-I, stands for Small Computer
System Interface. So we plug this into the server, and then we'd use a ribbon cable to connect into
the adapter.
00:00:43
And then from each of these ribbon cables, we could connect multiple hard drives. And with the
SCSI protocol, it was simply a set of commands that were used to communicate between the
controller and the hard drives themselves. For example, write this block of information or read this
block of information to or from the hard drive.
00:01:00
Well, now as we skip forward a couple of decades, a huge trend for our servers is to no longer use
hard disk storage that is physically attached. But instead, we're using network-based storage. And
there are several reasons for that. For example, if we buy a network-based storage device-- and
there's lots of vendors that make them.
00:01:20
For example, EMC is a company that makes lots of products, including storage appliances, devices
that are designed specifically to provide storage services that are network-based. If this was a server
on the network, it could access storage from the storage appliance here.
00:01:35
And there are several different technologies that can be used for network-based storage. For
example, we could have it be file-based, where the server reads and writes to the storage as files. As
a simple example, if the server was writing to a Word document, it would show up and look like a
Word document on the storage device.
00:01:54
Compared to block-based, with block-based the server is simply giving instructions to the storage
device to simply write blocks of data, as opposed to individual files. One of the methods that we can
use to read and write to a storage device is using a protocol called iSCSI.
00:02:10
Now, if the acronym SCSI looks familiar, it's because it is. What we did with iSCSI is we took the
same command set regarding the reading and writing of blocks that a computer would normally do
with its own SCSI adapter as it reads and writes blocks from a locally connected drive, and we do it
over i.
00:02:29
And that I represents IP, as an IP protocol. So a server that's working with a network storage device,
if they're using iSCSI, the server is simply using SCSI commands but is sending them over IP or to
the storage device, who is then de-encapsulating those packets, processing the request, and then
sending the information back to the server.

00:02:50
Another technique that can be used is called Fibre Channel. And in Fibre Channel, it is very
expensive to set up. There are a ton of details to be worked out for it to work correctly. But the
reality is, once it's all paid for and set up, it is extremely reliable.
00:03:07
So if you have a storage requirement where it cannot be down no matter what and the response time
has to be very, very quick no matter what and you've got the budget no matter what, you might want
to implement Fibre Channel as network-based storage to go ahead and read to and write from over
the network.
00:03:22
So with iSCSI, we're actually making requests over a more traditional Ethernet network. And with
Fibre Channel, it's more of a dedicated network just for storage. And the acronym for that is SAN,
Storage Area Network. If we're using Fibre Channel, we'd want to make sure that we've optimized
everything in that environment for that storage.
00:03:41
Because a user or a system might be retrieving or writing a huge file, normally in Ethernet our
maximum MTU is around 1,500 bytes. So that means if we are writing a gigabyte worth of data, we
are going to have to chop that up into a lot of smaller pieces.
00:03:57
And every time you chop up something into a smaller piece, it takes overhead. So the bigger the
information that we're going to be reading or writing over the network, the less efficient an MTU of
like 1,500 is. So on specialized networks where we are supporting network-based storage,
sometimes we'll use something called a jumbo frame.
00:04:15
Now, I'd like you to think with me about this word "jumbo." What does it mean? Well, if you're
saying, Keith, it sounds like it's big. It's large. And that's exactly what it is. By using jumbo frames,
let's say for example we're using a 9,000-byte frame, as opposed to a 1,500-byte frame. When we
chop up that gigabyte file or that data that we need to send to or retrieve from the storage appliance,
we won't have to chop it up as many times if we're using a jumbo frame.
00:04:44
But at the same time, we would want to make sure that all of our switches in the path between the
server and the storage device, we want to make sure that all those switches have two things going
for them. Number one, they can support jumbo frames and that they've been administratively
configured to support jumbo frames.
00:05:02
Because one bad switch or one switch that's not willing to support a jumbo frame would stop the
traffic from being able to flow between the server and the storage appliance. Another acronym that

we might see with storage-based networking is NAS, which is a little bit unfortunate, because NAS
could mean Network Access Server.
00:05:23
Or if it's related to storage, it could mean Network Attached Storage. So we'd want to be familiar
with the context of where that acronym is being used. And as one example of network-attached
storage, we have NFS, Network File System, that we could use as an appliance or as a device on our
network that a server that supports NFS could use that storage appliance for the writing and reading
of data.
00:05:45
So instead of the server using its own hard drive, it would be using the services of one of these
network appliances providing network-based storage services. Another huge benefit of using
network-based storage is that we can optimize our resources. Now, you may have noticed here I've
got this diagram of something called VMware vSphere.
00:06:03
This is like the commercial-grade version of a virtualization environment that VMware sells. So in
this virtualized environment called vSphere, we have these ESXi hosts. Now, we've introduced
these previously in the Virtualization Nugget as a device that's running the virtualization software
from VMware.
00:06:22
So in this environment, we have three of these hosts. They're each running the ESXi software,
which is a hypervisor. And then within the hypervisor, we have one or more virtual machines or
virtual servers that's running on each of those ESXi hosts. Now, one of the really cool features in a
virtualized environment is-- let's say that this ESXi host is at 90% utilization. And the Host number
3 is over here, and it's at 10% utilization. You know what we could do? We could either manually or
we could dynamically have the system move virtual machines from one ESXi host, one hypervisor,
to another.
00:06:59
So maybe we take this VM and that virtual machine and we start running them over on ESXi. Why?
Because this guy is only running at 10%, and ESX1 is running at 90%. That feature in a VMware
environment is called Distributed Resource Scheduler. But one of the tricks for that is that each of
these virtual machines, these virtual servers, has a virtualized hard drive, which is sitting on storage.
00:07:24
So if ESX1 was using a local hard drive and was storing all the files for VMs number 1 and 2, it
wouldn't be an easy task for ESXi host number 3 on the right to take over that responsibility,
because ESXi host number 3 doesn't have access to the local storage on Host number 1. So here's
the solution.
00:07:45
Instead of using local storage in this virtualized environment, we use-- (CROONS) da, da, da, daa--

network-based storage. And we could be using iSCSI or NFS or Fibre Channel. It really doesn't
matter which method we use. But the key is we're using centralized network-based storage.
00:08:01
So if the virtual hard drives for VM number 1 and 2 are now being stored on network-based storage,
the Distributed Resource Scheduler can now very easily move these two virtual machines from
running on Host number 1 and have them run on Host number 3. And at the moment of cut-over,
Host number 3 simply takes over the files for those virtual machines that are on this network-based
storage.
00:08:23
And then Host number 3 starts using its own RAM and CPUs to support the functioning of the VM
number 1 and VM number 2, which are now running over here on ESXi 3. And with this example,
I'm just pointing out one of the many benefits of using network-based storage, which is accessible
to multiple devices over the network.
00:08:43
And at some point, I hope that you join me for our Data Center Virtualization course for VMware
right here at CBT Nuggets, where I'll walk you through how to create this entire environment. And
one of the things that we do in that course is we take a look at creating an iSCSI server or an iSCSI
appliance.
00:09:00
And an iSCSI appliance, which is providing the storage-based services, is referred to as an iSCSI
target. So if you see the term iSCSI target, think of, oh, that's the iSCSI server. That's the device that
has the storage which is providing network-based storage via iSCSI.
00:09:16
So we'll put right here the word "server." Now, as far as the device that's actually requesting to use
the iSCSI services, that's referred to as an iSCSI Initiator, which we can write here as the client
using the iSCSI services. So if you've ever heard the term "it takes two to dance," in iSCSI here's
the two.
00:09:35
It takes the initiator as well the target, which is the client and the server if we're using iSCSI as the
protocol for our network-based storage. In this Nugget, we've taken a look at some benefits of using
network-based storage, as well as some examples, including iSCSI, Fibre Channel, and Network
File System, or NFS.
00:09:54
We also identified that if we're using jumbo frames on our switches that are part of our storage
networks, which can facilitate larger transfers of data between the clients requesting that
information and the appliances, our servers, that are providing that storage.
IPv6

00:00:00
IP version 6. Let's begin. IPv6 is a fascinating protocol. And I honestly thought that, at this time in
my life, IPv6 would be the dominant protocol. It's been around for over a decade. We've run out of
IPv4 addresses, except we still continue to squeeze the life, or breathed life I should say, into IPv4
by doing tricks such as network address translation with PAT, by hiding tens of thousands of IP
addresses behind a single, global, routable address.
00:00:32
In any event, IPv6 is becoming more and more popular. And here is my homework assignment for
you regarding IP version 6. I would like you to watched two specific Nuggets from my IPv6 course,
right here, at CBT Nuggets. They are Nuggets number 2 and Nugget number 3. And what I like to
do is give you a quick tour just to confirm the titles of those Nuggets for you.
00:00:55
So let's pop over to the IPv6 course and take a look at those two Nuggets. So this is the IPv6 course,
here, at CBT Nuggets. And the two Nuggets I'd like you got to watch are these two guys right here.
Nugget number 2 is called a 128bits, Masks, Hex, and You. And Nugget number 3 is called Multiple
IP Address Types. Those are the two Nuggets that I absolutely want you to watch.
00:01:21
They're assigned homework as part of your preparation for Network Plus. Now, in this third
Nugget, right here, Multiple IP Address Types, there is a teeny little exercise, a hands-on exercise
regarding configuring, working with a Cisco router. You are excused from that hands-on portion.
00:01:36
I don't expect everybody watching this Nugget to have access to a Cisco router. However, in this
Nugget, Nugget number 2, there's also some exercises that involve pen and paper regarding writing
out different types of IPv6 addresses. And for those written exercises, as part of this video 3, I
absolutely want you to do that.
00:01:55
So the very next two Nuggets I want to do as part of your Network Plus preparation are these two
from IPv6 course. And that is Nugget 2 and Nugget 3. In addition to those two Nuggets, I want to
talk about, just for a moment, two bullet points from the blueprint for Network Plus regarding IPv6.
And that's these guys right here.
00:02:14
DHCP is an option for IPv6 as well. It's not required due to a feature called auto configuration,
where a device can automatically determine what network it's on and get its own IP address using a
process called EUI 64 for its host address. And the details for that will be covered in IPv6. But if we
wanted to, we could also use DHCP, for IPv6, to assign IP addresses and/or to assign options such
as DNS servers that IPv6 host can use to do name resolution. Another challenge that comes up with
IPv6 is that maybe not everybody's running it.
00:02:50

For example, let's say we have user called Bob. And Bob's sitting here at a PC that's running IP
version 4 and IP version 6. Well, congratulations, Bob, you can use either one of those protocol
stacks. That's referred to as a dual stack device. But what if Bob is connected to, let's say, VLAN
20. And VLAN 20 only has a router connected to it that supports IP version 4. Let's call this router
6. So there's an IPv4 subnet associated with VLAN 20. And let's say there's also another VLAN and
connected, And router 6 only supports IPv4 on both. Well, how in the world is Bob going to get
access over to an IPv6 network if it's isolated by a router that only supports IP version 4? And one
of the answers to that is to do tunneling.
00:03:35
We can do tunneling of IPv6 traffic over IPv4 networks, or IPv4 traffic over IPv6 networks. And
one example of doing that type of tunneling is called Teredo. And as an example, let's put off of our
one an IPv6 server, meaning a server that is reachable via IPv6. And let's say Bob wants to send a
packet to that server.
00:03:57
So Bob would craft a packet. It would be an IPv6 packet that is destined to the IP address of this
server. It's very likely that Bob learned about that IP address due to DNS. Now the problem is how
do we get this IPv6 packet over to the IPv6 network? And the answer is we can encapsulate that
inside of an IPv4 packet. So if this network device, let's say this is a multi-layer switch, DSW2, is
also running IPv6 and IPv4 and also supports this feature called a Teredo tunnel, the game we could
play is that Bob's computer could logically build this connection, this tunnel between Bob and
DSW2. So we're routing IPv4 packets back and forth between Bob's computer and the multilayer
switch.
00:04:43
But when this end of the tunnel gets that information, it can de-encapsulate the IPv4 packet, pull out
the IPv6, and then continue to route that IPv6 packet over the network so they can get to this server
at the server's address. That would be an example of doing tunnelling.
00:04:59
And we're sending IPv6 over, at least on this little leg of our journey, an IPv4 network. And that my
friends, is what Teredo tunneling is all about. It's taking a user like Bob, which is isolated from the
IPv6 network, and building a path, if you will, or a logical tunnel that he can use, using IPv4, to get
the IPv6 traffic, which is being carried as part of the payload, to the IPv6 network so it can be
routed.
00:05:25
Now to support that magic, DSW2, this multilayer switch, would need to support the Teredo tunnel.
So whatever vendor we're using for that multilayer switch, we'd need to have the right software to
support it. And we'd also need to have some software running on Bob's computer which could do
that encapsulation of the IPv6 traffic in the IPv4 packets. And it just so happens that there is a client
for a Teredo tunnel, called miredo, that Bob could be running on his computer, that could provide
that functionality for Bob.

00:05:54
So the Teredo tunnel is an example of doing tunnelling, specifically IPv6 being carried in an IPv4
packet. And miredo is an example of a client that could provide that functionality on Bob's
computer. And the other end of the tunnel would be supported by our network device that also
supports the Teredo tunneling.
00:06:12
Now, in the IPv6 course, there are additional Nuggets that go into more detail on DHCP and also on
tunneling. But they're well beyond the scope of what you need to be aware of for Network Plus. So
once again, the homework is the two Nuggets, Nugget number 2 and Nugget number 3, from the
IPv6 course. And I'd like you to make those your very two next Nuggets as you continue your
preparations for your Network Plus certification.
Fault Tolerant Default Gateways
00:00:00
What is the benefit, or why would we buy two devices when we only need one? Well, one of the
answers to that might be because we want to have fault tolerance in our networks. Let's begin. The
IP packets that our users send and receive are usually between themselves and various servers, like
web servers, file servers, and so forth.
00:00:20
And here's my question. Out of all the packets that we're sending and receiving, how many of those
do you think stay local on the network, meaning they're going for local resources on the same exact
subnet? And it's very likely that most of our traffic is being routed outside of our local subnet,
courtesy of our default gateway.
00:00:37
And that leads us to a problem. What if the default gateway that the entire subnet is using, what if it
fails? Well, we just have a whole bunch of users who are going to be out of luck. And that's why
many companies implement something called fault tolerance.
00:00:52
Fault tolerance is the ability to have a single fault in the network at some point and continue
working. And the general song for fault tolerance is, why buy one device when we can buy two and
provide fault tolerance? And we can do that same thing for the default gateway.
00:01:07
Instead of having one default router, like router 1, we could have two routers that are providing
default gateway services for this subnet. So here's our 10.1 subnet over here. It's very likely our
clients are alerting their IP addresses and default gateways from a DHCP server.
00:01:22
And what we could do instead of just having one default gateway, we could use a first hop
redundancy protocol-- the acronym for that is FHRP-- and allow these two routers, router 1 and

router 6 in this diagram, to work together to support the default gateway function for the 10.1
subnet and for this VLAN. Now, there are several different ways of implementing fault tolerance for
the default gateway.
00:01:44
We could use a proprietary solution. Cisco has a couple of them. One is called HSRP. That's the hot
standby router protocol. So if you have two Cisco routers, and you want them to work together, you
can use HSRP. Cisco also has one called gateway load balancing protocol, which is yet another first
hop redundancy protocol that we can use to have two routers working together to support the
default gateway services that are needed by the clients on a specific subnet.
00:02:12
And you might ask the question, well, what if we're not using Cisco routers? Well, there's also an
open standard for a first hop redundancy protocol. It's called VRRP, which stands for virtual router
redundancy protocol. And regardless of what we're using to provide this functionality, it goes
something like this.
00:02:30
These two routers are going to be both connected to this VLAN. So for example, let's say over here,
we have VLAN 1, which is supporting 10.1.0.0/16 in our topology. And these two routers are also
connected to a same subnet, same VLAN over here on the other side, as well.
00:02:48
And this cloud, in our case, is now representing some additional networks. And the key part here is
that both these routers have interfaces in common VLANs. So they're both in VLAN 1 on the left,
and they're both in the VLAN on the right. And they both have IP addresses.
00:03:02
So maybe router 1's interface here is 10.1.0.1. Maybe R6 is 10.1.0.6, because we planned it out that
way, here on the left hand side on this 10.1/16 network. But now here's the problem. As we have
computers that get IP addresses, and they learn about a default gateway, very likely through DSCP,
which one do they use? .1 or .6? And the answer is we are going to have them point to neither.
00:03:25
What we would do is we would pick one. Let's say we want to run HSRP because these are Cisco
routers, and we can run HSRP. And then we would configure these two interfaces on the Cisco
routers as part of an HSRP group, and we would configure what's referred to as a virtual IP address,
which would be an IP address on this subnet that the clients can use as a default gateway and an
associated virtual MAC address, which is associated with that virtual IP address.
00:03:52
And then check this out. If we have a DHCP server, as it hands out IP addresses, it can hand out as a
default gateway .5. So computer 1, computer 2, the internal server, all the devices on this VLAN,
would be configured either dynamically through DHCP or statically to use .5-- 10.1.0.5-- as their
default gateway.

00:04:14
And then if the computers ever need to use the default gateway, they would do an ARP, Address
Resolution Protocol, to discover the layer 2 address associated with this IP address. And when that
request is made, the ARP request, one of these routers will be acting as the active router who'll be
responding and answer that ARP request and sending back this as the ARP response.
00:04:34
And if computer 1 ever forwards a frame to its default gateway, it'll be using this, the virtual MAC
address, as that destination layer 2 address. And that frame would be forwarded through the network
to whichever of these two routers is currently acting as the active router.
00:04:48
See, the cool thing is this. Maybe router 1 is the active router. He's doing all the work. He's
supporting the virtual IP address. And at the same time, router 1 and router 6 are kind of keeping
track of each other. If router 1 is powered off or destroyed or something else bad happens, and
router 6 no longer hears the little hello messages-- the language of love they use to keep track of
each other-- router 6 will assume the worst, and it will take over the responsibility of the virtual IP
address and the virtual MAC.
00:05:14
So currently, computer number 2, which is our Windows 8 client, it's got a default gateway of .1 on
the 10.1.0.0 network. And so we want to accomplish two things. Number one, we need to set up
router 1 and router 6 to work as an HSRP pair to support the new virtual address.
00:05:31
And let's use .5 as the new virtual address. We can also configure not only the virtual IP address but
also the virtual MAC address. And that's done on the interfaces right here of router 1 and router 6.
So here on router 1, we'll go into configuration mode, and we'll go into the compartment or the
interface called ethernet 3/0, and that's this interface right here, the one that's currently connected to
switch 1. And switch 1 and switch 2 and all these devices are part of the same exact subnet and
VLAN.
00:05:58
And for Cisco's HSRP, the command and interface config, to create a standby group and assign a
virtual IP address is standby, the group number, the keyword IP, and the virtual IP address that we
want to use for HSRP. I'm also going to specify the virtual MAC address that should be associated
with that virtual IP.
00:06:17
There are some defaults in place that we could use, but I'm using a specific MAC address, so it'll be
very easy to see. And I'm also going to set the priority for this router, router 1's interface, to be a
little higher than the default. The default priority for HSRP on a Cisco router is 100. I'm going to
tell this interface to be 101. Next, let's go over to router 6, the second router in this pair. And here on
router 6, we'll go into configuration mode. We'll go into interface ethernet 3/0. That's the one

connected to the 10.1 subnet. We'll give it the standby IP address for that same group and the
standby MAC address.
00:06:48
They're both supporting that same virtual IP address. And if we went back to router 1 for a moment,
and we did a show command, for example, show standby, it could give us the details regarding that
standby group. So in the output, router 1 is saying, I am the active router for the standby group.
00:07:04
And the standby router is my good buddy at 10.1.0.6, which is the IP address of R6. And the virtual
IP address that we're supporting is 10.1.0.5, and this is the virtual MAC address associated with that
virtual IP address of 10.1.0.5. So in a production network, the next likely step that we would take is
we would change our DHCP so it handed out the options of .5 as the default gateway instead of the
default gateway of .1. And that way, any new DHCP clients would get the new information, and
they could start using .5, which is now a virtual IP address that's being logically supported by both
router 1 and router 6. So at the moment, router 1 is active, and if we look at the configuration for
router 6, it would show it as standby, a backup.
00:07:50
In case router 1 goes away, router 6 can step in and take over the responsibilities for the virtual IP
address and the virtual MAC address. In our demonstration here on computer 2, instead of changing
DHCP, we're just going to go in and statically configure the IP address and default gateway on
computer 2 to use .5 as its default gateway. So on our Windows 8.1 workstation, which is
representing computer 2 in our topology, we're in Control Panel under Network and Internet,
Network Connections, and looking at the details for Ethernet0. We'll right click, go to Properties,
and then we'll scroll down.
00:08:24
And then we'll modify the properties of the TCP/IP Version 4 Protocol Stack. We'll double click on
it. Currently we're a DHCP client. And what we want to do for this demonstration is tell it to use the
IP address of 10.1.0.105. The mask is 16 bits, so we'll put that in in dotted decimal. And the default
gateway, which is the part that we really want to change for this demonstration of HSRP, is 10.1.0.5.
So whichever device, router 1 or router 6, who's currently the active router for the standby group
should be supporting that IP address by responding to ARP request.
00:08:58
And then as frames get sent to the default gateway, the active router should be processing those and
forwarding those as the default gateway. And for the DNS server, we'll go ahead and specify that,
for DNS, we can use 8.8.8.8, which is a Google DNS server out on the internet. And we'll click on
OK.
00:09:13
OK once more. And at the command prompt-- and the question I have for you at the command
prompt of this Windows computer is, what command could we issue to see what the current IP
address is and default gateway being used by this computer? And if you're saying, ooh, Keith, got it.

00:09:28
It's ipconfig. I would 100% agree with you. Let's do ipconfig, and there's the IP address that we just
assigned of 10.1.0.105, and there's our default gateway of 10.1.0.5. OK, my next question for you
is, how do we find out whether or not the layer 2 address has already been resolved for 10.1.0.5 on
this Windows computer? Think about that for a moment.
00:09:50
How do we see the ARP cache? And if you said, Keith, we're going to use the command arp-a, you
would again be absolutely right. And if you're able to answer those questions fairly quickly, it's
likely because you've had experience or you've practiced with those commands, which I'm strongly
encouraging you practice everything you possibly can, hands on.
00:10:09
So we'll do an arp-a, and look at that. My computer has resolved the IP address of 10.1.0.5 to the
MAC address, 00-00-12-34-56-78. So at some point, this Windows 8.1 computer had a burning
desire to reach some resource outside of its local 10.1 network. It may have been checking for a
Microsoft Windows Update.
00:10:28
It may have been doing a DNS request. Regardless of why, this computer used ARP to resolve the
layer 2 address. And when it sent out the ARP request saying, hey, I need the layer 2 address of
10.1.0.5, the router currently acting as the active router for the HSRP group saw that broadcast and
said, hey, I'm the active router, did a reply, and replied back with this layer 2 address. So now this
computer, anytime it wants to send frames to its default gateway, would be sending it to this MAC
address right here, which is being supported by the active router.
00:10:58
So if we want to verify connectivity, we could do a ping, for example, out to 8.8.8.8. That seems to
be working. We could also do a tracert out to that same address. So we'll do a tracert-d for don't
bother doing name resolution on the way out. And that's showing us the full path.
00:11:18
So right here, it says the first hop is 10.1.0.1. And the reason it's showing as 10.1.0.1 is, even though
we're using 10.005 as our default gateway, the trace route command is manipulating the time to live
field, so the first router to get that with a low TTL that couldn't be forwarded anymore was router 1.
So router 1 actually sent an ICMP message back to this PC saying, hey, I killed your packet due to
TTL expiring.
00:11:43
And when it sent the ICMP message back, it used its own IP address as the source. And that's why it
shows up as 10.1.0.1. Now, what I think would be fun is this. What if we totally turned off router 1?
What should happen in the background is router 6 will no longer see the little keepalive messages it
uses for HSRP, and it will, in a matter of seconds, think that router 1 is no longer available. And as a
result, router 6 that's currently acting as standby, will move its state to active.

00:12:12
And then it, router 6, will start supporting that same virtual IP address that's .5 and the associated
virtual MAC address that's part of that HSRP standby group. Now, one of the benefits of having all
of this virtualized is that we can just go over to router 1 in our test lab, and we can power it off.
00:12:29
So in GNS3, my virtualized environment for this lab, we'll right click on router 1, and from the drop
down, we'll say Stop. So effectively, router 1 is no longer running. It is powered off. Now, it might
take a few moments for the network to converge. For example, R6 is very likely to very quickly
notice that R1 is no longer sending little hello messages as part of the HSRP protocol.
00:12:50
So R6 may go active in just a few seconds, but it may take a few moments for the firewall and other
networking devices to converge based on layer 3 routing. And convergence is when every network
device understands how to reach all the other networks. So if we have a dynamic routing protocol, it
may take a few moments for the network to converge or agree on how to reach all the networks.
00:13:15
So back at the computer, one thing we could do is let's take at the ARP cache again and do arp-a
again. So this computer still believes that 10.1.0.5, which is the virtual IP address being supported,
has the layer 2 associated address of the 00-00-12-34-56-78, and, if we did ipconfig again, the
ipconfig information still shows us that we're using 10.1.0.5 as a default gateway, except now that
virtual IP address should be supported by R6 automatically due to the HSRP that we configured
because R1 is no longer running.
00:13:49
So here on the PC, if we use the up arrow key a few times and just did that trace route one more
time to 8.8.8.8, notice that it's still working, but this time, the first hop is coming back as 10.1.0.6,
and that's because router 6 is the active standby router who's providing the default gateway services
associated with the virtual IP address of .5. So this is an example from the user perspective of what
fault tolerance looks like.
00:14:14
They are supposed to not even notice that there was a failure in the network. One of our routers
goes down, yet the network continues to function, because we had reliability and fault tolerance
built into it. In this Nugget, we've taken a look at the concept of using two or more devices to
support fault tolerance in the network, specifically in the case of routers-- two or more routers
running a first hop redundancy protocols, such as VRRP or HSRP, that both support a virtual IP
address between them so that, if a single router fails, the other router can pick up the slack and keep
the network functioning.
Considering Network Requirements
00:00:01
In this Nugget, we're going to take a look at some considerations and requirements that we should

take a moment to think about when implementing a computer network. Let's begin. At one of the
really fun companies I have the opportunity of working for, the programmers had a sign by their
areas.
00:00:15
And it said this. You start programming and coding, and I'll go find out what they want. And the
reason that's funny is because we're putting the cart in front of the horse. We should identify the
requirements first and then build the network to meet those requirements.
00:00:31
I thought what would be fun is for you and I to take a look at implementing a basic network. And
let's use a home network, because a lot of the same concepts apply. So the very first step is we'd
want to have a list of requirements. For example, we may want to have internet access.
00:00:46
We may have a shared printer. So we want to be able to do printing over the network. And maybe
we have a media server, which has the ability to stream either audio, or video, or both inside of our
network. So after we've identified what the requirements are, we then identify the devices we're
going to have on our network.
00:01:04
And many of those devices are providing the functionality we're looking for. For example, we'll
need a printer that we connect to the network. And is that printer wired or is it wireless? And the
same would be true for our media server, as well as our computers that are going to be connecting
to the network.
00:01:19
Are they wired devices? Are they wireless? We also want to consider environmental limitations. So
one of the questions we might ask is how much power are these devices going to consume. And are
these circuits that they're connected to able to handle that much power? We also might want to
consider uninterruptible power supplies as short term battery backups in case we lose power if we
want our network devices to keep on going.
00:01:42
Also, regarding environmental, we would want to consider space, heat, humidity, and other
environmental factors that could either impact or we need to have set up to support our networking
gear. An example would be a small closet where we're going to keep our router or other device.
00:01:58
Or if we decide we're going to put our router up in the attic, which is not air conditioned, at least, in
Las Vegas, that is a huge mistake, because the attic could get 120 or higher degrees during the
summertime due to lack of air conditioning in the attic area.
00:02:15
We'd also want to consider equipment limitations. For example, if we're going to implement a

server, we might want to consider what is the amount of workload that server can perform. How
much can it do? So in a business, if we have a service that's going to be supporting 300 users, how
many of those users simultaneously does that server have the ability to support? Or on our home
network, as far as connectivity to the internet and throughput, what is the amount of throughput that
we're getting from the service provider? And how much throughput can our network support? We
also have some limitations regarding our wireless.
00:02:45
How far is our wireless access point-- which is integrated into our home router-- how far can that
signal travel in the environment it's in, especially with lots of walls that might be separating the
access point that's built into the router with the wireless devices that are using the access point to
get connectivity to the router and to the other devices connected to that router? Regarding
compatibility, it would be great if we had compatible technologies.
00:03:10
For example, if the access point is using 802.11ac but yet, none of our wireless devices support that,
we'd want to make sure that either the access point on the router was backwards compatible with
other technologies, such as 802.11n or 802.11g, to make sure we have that compatibility between
the wireless radio and the wireless devices that are going to use that radio to get access to the
network.
00:03:35
And if we're going to be using cables, for example, unshielded, twisted pair cables, we'd want to
make sure we're using the correct types of cables for that connectivity. So if this is fast ethernet, 100
megabits per second for wired connectivity, we don't, I repeat, don't want to be using Cat 3 cable,
which is not up to spec to support 100 megabits per second. We also want to make sure that our
ethernet connections don't exceed 100 meters from the switch all the way to the network device.
00:04:02
Now, in our home network, that's very likely not going to be a problem. But in an office or a
building, we'd want to be very careful not to exceed those lengths. So those would be some
additional wired considerations. As far as wireless, as far as making sure we have the right standard
that we're using, that we also have our wireless devices within range of the access point in the
router, and also making sure we did a site survey or are at least aware of the other frequencies and
channels being used by other devices, for example, our neighbors, or other businesses, to make sure
we're choosing, when possible, frequency ranges that are not in conflict with those other access
points.
00:04:36
And regarding security, here's a couple of best practices. Number one, we do not want to leave the
default passwords in place on our network devices. That's a big no-no, especially on a wireless
device where it doesn't take a physical connection to get access to that device.
00:04:52
Also, for our wireless, we want to make sure we use some encryption. So I'd recommend using

WPA2 where possible, that for encryption it's using AES, the advanced encryption standard, to
encrypt all the wireless traffic that's going back and forth between our wireless clients and the
wireless access point that's integrated as part of most home routers.
00:05:12
Also, when we're choosing pass phrases and passwords to use for our security, we'd also want to use
at least eight characters or more, which should include alpha-numerics and special characters, the
ones that make you look like you're swearing, like gosh darn it, like that.
00:05:29
So eight characters or longer, numbers, letters, and also, for the alpha characters, upper and lower
case, because the tougher we can make our passwords, the harder it will be for somebody to do a
brute force attack where they just try over, and over, and over again, lots of possible combinations.
00:05:46
And one way to help resist against that type of a brute force attack is by having a fairly complex
password. And following these rules for password creation can help us in getting there. The other
option that most devices have the ability to set up is to deny management of this router from the
internet.
00:06:03
So here's our service provider. They may be providing connectivity via cable modem or digital
subscriber line, DSL. So this device represents either a cable modem or the device that terminates
the DSL. So they've got their connection coming in here. And for this example, let's say it's coax
cable coming in from our service provider, who's delivering services via coax, like a cable
company.
00:06:24
And then we have this ethernet connection that goes into the LAN port on our wireless router. And
then the wireless router has, usually, four switch ports that are integrated. And normally, there's no
configuration at all that we can do, as a user, on these four switch ports.
00:06:38
They just give us the ability to connect multiple devices, wired devices, into that VLAN. So at the
end of the day, wireless clients, as well as wired clients, will all be part of one logical Layer 2
VLAN, one broadcast domain on the inside. And this router is also going to be performing network
address translation.
00:06:57
Specifically, it's going to using PAT, port address translation. So inside the network, we might be
using an IP address of 192.168.1.0/24. The router's also acting as a DHCP server to hand out those
addresses. The router is very likely being assigned an IP address dynamically.
00:07:15
On cable modem, it's very likely going to be assigned via DHCP. So it's got some IP address on the

LAN side. And then, as user traffic goes through this router out to the internet, this router is acting
as a PAT device, port address translation taking a single IP address that's been given from the
service provider and doing NAT against all the IP addresses on the inside that are going through the
router.
00:07:36
In this Nugget, you and I have taken a look at a set of requirements and considerations that we want
to take a look at when we're implementing a 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.
Physical Security Controls
00:00:00
One other reason we have controls in the network is to reduce the amount of risk or impact that
some unauthorized event can bring. And physical security controls are the focal point for this
Nugget. Let's begin. Security can take on many different forms. For example, we have technical
security controls.
00:00:19
For example an access control list is stopping certain types of traffic from going between two router
interfaces, or access control lists on a firewall. And those would both be examples love technical
controls for security. Another example of a control would be an administrative control.
00:00:35
Let's say somebody's getting a top secret clearance. There's quite a bit of effort and time spent on
doing a background check so that person can get their top secret clearance. And for physical
controls here's our laundry list right here. A mantrap. And right here we've a example of a woman
trap.
00:00:53
It's a person trap. It's where the individual goes in. There's one person admitted at a time. And it
might be steel bars or it might be glass. Or it might be simply a small room where the person goes
in and then they might be weighed, for example, to make sure the weight is approximate, or there
might be other controls in that room to verify the person is really who they say they are.
00:01:13
Maybe they have to type in a PIN number or a code, and if that's successful then they're allowed to
go ahead and continue on into the room or building that the mantrap was set up to protect. And you
might ask, well, what happens if you get in the mantrap and then you can't authenticate? Then it
might require intervention, for example, from a security guard, which is another example of a
physical security control, to intervene.
00:01:37
And for a person who is unauthorized, who is trying to get in, they're pretty much a captive
audience at that point because they can't go in the building, and on some mantraps, like this one,

they may not be able to exit out the way they came in. So that's our first example of a physical
security control, a mantrap.
00:01:53
Another place that we would want to have some physical controls on would be our network closets.
For example the IDFs, the intermediate distribution frames, on each of the floors. They have the
patch panels in our switches, and the cabling in those wiring closets.
00:02:07
We'd also want to make darn sure that in our data center we also have physical controls to restrict
who is allowed to physically enter. So even though physical security is a little bit of a pain, it's also
a very critical step as one aspect for securing our networks.
00:02:24
So regarding access to our wiring closets in our data center. We may have keypads that we simply
punch in a code. We may have a proximity reader where we have a card. It just have to get close to
the reader, and when we get close to the reader it senses, OK, it's you.
00:02:38
Or we have a key fob that's used for physical access into a room or building. Or the controls to the
door may be remotely controlled by somebody who's viewing a closed circuit TV. They see it's you.
You put in your PIN, and they also have to verify that it's someone they recognize.
00:02:53
They hit the button, and then a combination of those factors allows you in that building or in that
room. Different physical controls have different reasons for being there. For example, some might
be there as a deterrent. Consider a fence. Is a fence a preventive measure or is it a deterrent? And I
guess it depends on how high is the fence, what kind of barbs do they have on the top, or is it a
short fence? So a physical security control may not be designed to completely prevent something
from happening, but it could act as a deterrent or it could be there to detect that something is or has
happened.
00:03:27
An example of a physical security control that could act both as a deterrent as well as a detective
physical control would be an example of video monitoring. So maybe we have some IP cameras
and/ or CCTV, which is closed circuit TV, and then those cameras are all being fed into a control
room and they're being watched or observed by an individual.
00:03:47
For example, a security guard that is watching everything that's happening. Now, a camera all by
itself doesn't stop activity from happening. Now, you might ask, well, how exactly does security
monitors act as a deterrent? How's that going to deter some type of behavior that we don't want to
have happen? Well, if there are signs all over the place that security camera recording is in place
and being monitored 24/7, some individual who is unauthorized or someone who has malicious
intent, they may think twice before carrying out their intentions when they know it's being recorded.

00:04:22
Another type of physical security control could include biometrics to be used as part of physical
authentication before allowing an individual to enter a room or a building. So the biometrics could
be used as part of a mantrap. The user looks into the scanner, it looks at his eyeball.
00:04:38
It could be analyzing is retina or his iris iris, depending on how the reader set up, to then correctly
identify that user. And we could have multi-factor authentication. So the biometrics would be
something that the user is. For example, the way his or her eye is formed.
00:04:52
And the intricacies of their eyeball. That's something they are. And If there was also a PIN pad on
the doors as well and they had to type in a PIN code, that pin code would be something they know.
So something they know, and something they are together being required it is an example of two
factor or multi-factor authentication.
00:05:08
In this Nugget, we've taken a look at several, physical security controls that are often found in
network security. 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. And I'd like to thank you for viewing.
Power Management
00:00:03
Power-- absolute power. Well, without power-- without electricity-- our networks, and the servers,
and devices they support are in a heap of trouble. In this Nugget, you and I get to take a look at
some power management concepts that we can use to help optimize our uptime for our networks
and the systems they support.
00:00:18
Let's begin. I have several children. Most of them are grown. But you know what I never got? I
never had the question where the kid comes up and says, daddy where does power come-- where
does power come from. It just never has happened. Power is not just magically present in the forms
that we normally need it in.
00:00:36
In many countries, we take electricity for granted. And it's delivered to our homes and businesses
normally as AC-- Alternating Current. And here in the United States, that's somewhere between 50
and 60 cycles per second or measured in what are called Hertz.
00:00:50
So in our wall jacks and our outlets if we wanted to test to see what the voltages were, as well the
Hertz, we can use a tool such as a multimeter to measure exactly that. So assuming the power
actually makes it to our building, where our networks and systems are and our data centers are,
there's a lot that goes on inside the building as well to manage that power.

00:01:10
For example, the circuits that come in are going to come into some type of a circuit breaker. Now a
power converter can refer to lots of different functions. So we take a look at the two basic forms of
power or electricity that we're going to be using. We have AC, and we have DC.
00:01:25
AC stands for Alternating Current, which has a waveform that looks something like this, except it's
a symmetrical sine wave, and mine's not symmetrical. Imagine that being perfect wave and then
we'd have AC. And DC is simply levels of voltages. So it's not alternating in amplitude.
00:01:44
It's just a constant voltage. So DC does not have a waveform that alternates. Its a steady voltage.
Now in most homes, we use the Alternating Current just as it comes in. But you'll notice that as a
power plant delivers this Alternating Current to us, they've got transformers involved at multiple
places.
00:02:02
And these transformers are a middleman, if you will, between AC and AC. They may be
conditioning, or modifying, or changing the levels, or the voltages, but they're generally dealing
with AC on both sides. Now inside of our company, we have a lot of devices that use DC.
00:02:17
In fact, all of our computing devices are using Direct Current. So to convert AC over to DC, one of
our primary methods is going to be-- here it is-- a power supply. So the servers, computers, routers,
switches, many of them have a plug that supports AC coming into the unit, and then the power
supply converts that to DC for the benefit of that server, that computer, that router, or that switch to
go ahead and use.
00:02:43
It's their own power supply. Now some network devices have DC inputs. So you'd have DC already
in your building. So somewhere, you've already done the conversion from AC to DC. In that case,
we plug-in a Direct Current supply of power to that network device.
00:02:59
So the actual conversion from AC to DC wouldn't be done on the power supply of the network
device it's already set up for DC. The conversion would be done somewhere else in our building,
which could be in or near the data center for that conversion. Now in the event that the power
company there is a failure, for example, maybe lightning strikes and there's a total power failure
coming into the building, we could also use something called a UPS-- an Uninterruptible Power
Supply.
00:03:23
And a UPS relies on its batteries. So with a battery, you've got this stored amount of energy, this
electricity, that's available from the battery. And if we wanted to power something that was AC, we

would need something called an inverter that takes DC and converts it over to AC.
00:03:39
And many people are already familiar with an inverter as those little devices you take in your car.
You plug it into the 12 volt DC adapter, and it inverts that so you have output of AC. So in the
United States that would be approximately 120 volts and approximately 50 to 60 Hertz as far as the
wave form being generated for AC power.
00:03:59
And then if we had situations where we had DC voltages that needed to be adjusted or regulated, we
might have other devices that go from DC to DC, such as a voltage regulator, to get the voltages at
the specific levels that we want them to be. Now what are the challenges if we are using a battery
backup system when we lose power? We may have a battery life that we can support our critical
systems somewhere between, for example, maybe 30 minutes and two hours. And then beyond that,
because the battery capacity isn't great enough, we're going to lose power once again.
00:04:27
So UPSes are great for fairly short term outages. And we also may want to have some line
conditioning in our building so that when the power kicks back in-- when it comes with a huge
surge-- we don't have that huge surge pumping into our building, hitting our equipment.
00:04:42
So we might have some devices, intermediate devices, that are doing line conditioning and power
conditioning to help avoid severe impacts when the power comes back on. Now one of our concerns
is this, what if the power from the power company doesn't come on in time where our UPSes have
been working as hard they can? Their batteries are almost out, yet we still want our networks to
function.
00:05:04
What do we do then? Well, to prepare for that scenario, a longer term solution to supply power for
our infrastructure, for our networks and systems, would be to use a generator. By using a generator
that kicks in when there's a loss of power, we have our short term UPS to handle the immediate
distribution of power to our systems and networks, and then the generator can kick in.
00:05:27
Now these are usually gas powered or diesel powered. So we'd want to make sure they were
prepared and properly tested and had fuel. Also as you'd imagine, because they are burning fuel
they're going to be somewhere not physically inside the data center. They're going to be outside
units normally.
00:05:42
And then these devices would generate very likely AC power that could also be fed in to our line
conditioning for electrical circuits, and then be fed to the rest of our systems and data center. So
uninterruptible power supplies, battery backed up for fairly short term, and for a longer term in the
event that we don't have it coming into the power company again, we would go ahead and use a

generator.
00:06:03
Now in addition to this fault tolerance by having UPSes and power generators for fault tolerance of
our power, we also want to make sure that our individual devices, such as routers and switches-let's take a switch, for an example, and let's say this is a multi-layer switch, which is a box, a device
that can do routing at Layer 3, as well as Layer 2 forwarding based on Layer 2 addresses on
ethernet.
00:06:27
So it's got it all. And let's say this switch has dozens or even hundreds of devices that are connected
to this device. Maybe this is a device inside of our MDF, that's core to our entire network. What we
would also want to have for this switch is we would want to have redundancy for this device
regarding power.
00:06:47
So for that it's very likely to have two power supplies or two power inputs. We'll call this power
supply a and power supply b. And this input can be AC or DC depending on the type of switch it is,
but we would want it to have two. That way if either one failed the system, the switch could
continue to function.
00:07:09
The other critical pieces-- we'd also want to feed these power supplies from two different power
sources. So for example, maybe we have power source, a, that's feeding power supply, a, and power
source, b, that is feeding power supply b. And you might think, well, that might take some
engineering and some work to make sure that it's all done correctly.
00:07:29
And the answer is, yes it does. And the flip side of that, if we don't take those precautions, and let's
say we have, for example, we accidentally plug both of these power supplies into the same power
source, c, and that power source fails, guess what? Our switch is done.
00:07:44
Even if we have power to the building, and we have our UPS, and our generators available, this
switch-- if we have one power source feeding both power supplies, the redundant power supplies
and this power source fails that switch is adios amigo. We just have a major failure of a core
component of our network.
00:08:01
So fault tolerance is implemented by having redundancy on all of our critical systems. In this
Nugget, we've taken a look at some concepts regarding power management and why it makes sense
to plan ahead for fault tolerance regarding power. I appreciate you joining me for this Nugget.
Network Topologies
00:00:00

Network topologies are cool. In fact, I think it would be a great name, for like a rock and roll band.
[GUITAR SOUND EFFECTS] Network Topologies! [GUITAR SOUND EFFECTS] And there's a
lot of network topologies that we're going to commonly see in our networks today.
00:00:11
And in this Nugget, I'd like to chat with you about a few of those. Let's begin. I remember about 25
or 30 years ago, when I started learning about networking-- one of the confusing topics for me was
that a network topology isn't always the same for the physical layout, as the logical layout of the
network.
00:00:31
So we could have, for example, a network that is physically wired and connected as a star, but
logically operates as a bus. For an example, if we go back in the time machine, like 20 or 30 years
ago, when we had ethernet we used coaxial cable and had little terminators on each end.
00:00:48
And then we had little t-connectors that connected each of our computers to the coax. So in the old
networks like this, if we used ethernet, we'd use carrier sensing multiple access with collision
detection. So in PC1, if it wanted to communicate on the network it would first of all sense to
identify whether or not there was current signals on the network being sent by some other device.
00:01:09
And if it thought it was clear, it would send that message on to the network. And that message
would hit the coax. It would go this way, it would go that way, and would continue to go. So all the
machines are going to see, basically every single bit that's sent by every other device on this
network.
00:01:22
And the terminator simply absorbs the signal so it doesn't reflect back in. So in this ethernet
network, which is based on coax-- it was 10 base 2. 10 megabits per second, base band, and the
length could be approximately 200 meters, just shy of that. That's what the 2 represents. This is
wired as one giant bus.
00:01:43
A shared bus that's connecting all these devices together on this network. So it is a physical
implementation of a bus. It's also a logical implementation. A single signal is sent and seen by every
other device on that network. And then as we started moving away from coax, and we started using
a hub-- and a hub is an example of a layer 1 device. It's simply a multi-port repeater.
00:02:04
So we have our three computers. There's computer 1, computer 2, and computer 3 that are all
connected to the hub. In fact, let's add a few more computers on here as well. So connecting to this
hub, we're using unshielded twisted pair. And if computer 1 sends a signal into the network for
using a hub at layer 1, the hub simply repeats that signal out all of the other ports where devices are
also connected to that hub.

00:02:26
So in that sense, logically, with a hub and all these devices connected to it, it's also acting like a
common bus, where a single signal sent by one device is seen by every other device, every single
time. So logically, this is also acting as a bus. However, if you look at this, it is physically wired as
a star.
00:02:45
The hub is at the center, and each of the network devices have an individual connection to that hub.
So this is an example of a physical star, but a logical bus. So if we were to go through our topology
for our network plus lab here, we can say that our switches, which are operating at layer 2-- so we
have each of the computers connected to the switches and a switch is the central point for that
physical star.
00:03:08
Now, one of the negatives of a star topology is that if the switch fails, whether its power that's
turned off to the switch, or the switch has a problem as a whole, that switch, if there's a problem
with it, could act as a central point of failure for that network.
00:03:22
Because it is the center, if you will, of the network connectivity for all the devices that connect to it.
Router 2, as it's connecting out to the branch office router out here, over the serial interface that's
provided by the WAN provider-- this could be an example of a point to point.
00:03:38
A point to point network means there's only two devices. It also implies that the technology is set up
to support only those two devices. So we have one end of this WAN link here at router 2. We have
the other end here at the branch. And this wide area network link would have its own subnet.
00:03:54
And if we're conserving IP address space in a production network, it's very likely that we'd use a
slash 30 mask for that subnet. So what I thought would be effective for you and I to do for just a
moment is to take a look at some icons that represent the concepts of the various types of network
topologies that we might come across.
00:04:13
So let's do that now. On the top left, we have the full mesh. Now, a full mesh is where every device
on the network has a direct, and if you will, point to point connection to every other device on the
network. It's like the epitome of redundant connections.
00:04:29
And the benefit of a full mesh is that we don't have a single point of failure. If we have a full mesh,
if one of those links goes down, no problem. There's other connections involved that we can still
use to go from point A to point Z. And a full mesh seems like a really great idea for redundancy, but
it's kind of a nightmare to implement, because there's so many individual connections between each

and every device on the network.

00:04:54
So instead of having a full mesh, it's very likely that a of times we'll see a partial mesh, where we do
have some redundancy, but it's not every single device connected to every single other device. So
when comparing a full mesh to a partial mesh, just think of a full mesh as having no single point of
failure.
00:05:11
And a partial mesh simply doesn't have as many links. There is some redundancy, but it's not a
single connection between every device and every other device. Next we have a bus topology. As
we mentioned earlier, a bus implies that when a signal is sent, it is received by everybody else
sharing this common bus.
00:05:31
And the bus topology on ethernet also might imply that we're using carrier sensing multiple access
with collision detection, where we only have one signal being sent or received at any given time on
that shared bus. We could also say that a bus represents a giant collision domain, because only one
device can send at a time.
00:05:50
If two people try, there's going to be a collision. So on a logical bus, all of the devices on this
network are sharing a collision domain. They're also sharing a broadcast domain. Then the
evolution of working with a bus was to move to a star. Now one of the negatives of the star is that
we have a potential single point of failure, and that's the center of that star.
00:06:10
So if that's a hub or a switch in our physical star topology, that single point of failure-- if it fails-- is
going to cause heartache for all the devices that are relying on that switch or hub. Now in our
networks today, we are using intelligent layer 2 switches for that center of our star.
00:06:26
And the benefit of having the layer 2 switch at the center is that we can take individual ports and we
can carve them into separate VLANs. So we could have, for example, maybe these three computers,
be in VLAN10, and we can have these three computers be in VLAN 11. So by doing that, we have
two separate broadcast domains.
00:06:45
One for VLAN 10, one for then 11. The other benefit of the switch is that each port on the switch is
its own independent, separate, collision domain. Which means that none of these computers in
VLAN 10, and none of these computers in VLAN 11 is ever expecting to have a collision.
00:07:01
And that's because every port on the switch is acting as its own collision domain. That's also why
we're not using, in a layer 2 switch environment, we're not using collision detection, because we're

not expecting any collisions to happen. And you might ask, well, if this is VLAN 11 right here, and
we have computer 4 and computer 5, and they're both talking to computer 6 at the same time, how's
that going to work? How could there not be a collision? And the magic is, on the back plane of the
switch, it has some buffering capabilities where it can do buffering.
00:07:31
We're talking about microseconds and milliseconds of buffering to allow the traffic to be moved and
delivered correctly without any collisions taking place. So we've addressed bus, we've addressed
mesh, both partial and full. And we've also just addressed star.
00:07:44
Now a long time ago, we also used to have something called token when I was growing up. Back in
the '80s, when we first started working with high speed local area networks, the name of the game
was token ring. And token ring operated logically as a star. And it's pretty cool.
00:07:59
It's worth a few seconds of mentioning here. With token ring, the network would pass this token.
Basically a signal saying, hey, the network's clear, the network's clear. And if somebody wanted to
talk, what they would do is they would grab that free token, they would flip it and say, hey, OK, the
token's busy, and then they would put their message on the network and it would logically be sent
around to all the devices.
00:08:20
And then, after that message made it's loop, the device who caused the token to be busy would flip
it back to be a free token, and then the next person would go ahead and communicate. And with
token ring there was no collisions. Because it was organized and the devices had to wait for the
talking stick.
00:08:36
A talking stick is where you have a group of people and only the person who's holding the talking
stick gets to communicate at that time. And in token ring, having the token and having access to that
token, reminds me of that talking stick. So token ring had its day, but it's an example of a
technology that was a logically operating as a ring.
00:08:54
Now the interesting about token ring 2 was that it was physically wired as a star. So you would have
this device in the middle. They called it a multi-station access unit, or a MAU. And the tokens and
the messages would be logically propagated around the network logically like a ring, but it was
physically wired as a star.
00:09:11
A hybrid network topology is one that may have some characteristics of a bus and other
characteristics of a star. So here we have most of our devices on this common bus, and then we have
this one device that branches out to other devices in a mini star. So hybrid, when you boil it all
down, is a network topology that can use a some of two or more different types of topologies in that

network.
00:09:33
A point to point implies that we have two and only two devices connected to a network. And our
example was the wide area network connection between our 2 at our corporate headquarters, and
the branch office router, using a WAN circuit. And very likely a serial link to logically connect them
together, point to point.
00:09:51
Now if we had multiple locations-- let's say this is our headquarters site, and we had branch number
1 and branch office number 2 and branch office number 3, and we wanted to connect all three
branches, but we didn't want to use individual point to point logical circuits for each, we wanted to
have one common subnet-- let's say this was 10.9.0.0/28 as our mask-- and we wanted to use this
one common network to connect from the headquarters to branch 1, 2, and 3, that would be an
example of a point to multipoint.
00:10:25
And a common occurrence of a point to multipoint would be in wide area network services. And we
have multiple branch offices that are connected to the headquarters site or the WAN connectivity
over a common IP subnet. And if we ever see the term hub and spoke, it's generally referring to
where we have the headquarters site, we have WAN circuits.
00:10:43
For example, branch 1, 2, and 3, and we have point to point connections between the headquarters
site and each of the individual branch office remote sites. And if we look at that, it also looks a little
bit like a star, and we have the hub and spoke with a centralized location, the headquarters location,
and each of the branch offices with a point to point connection, connecting the branch office back to
headquarters.
00:11:05
And then we have this bad boy right here. We have a tree topology. I'd like you think about a tree
for a moment. Just imagine in your mind a tree. So its got the root of the tree. As it goes up, there's
likely some branches that go out. And what we could notice about every tree is that the branches,
they don't grow back in and graft back into the tree.
00:11:25
They go out. There's no loops in a tree. The branches go out, and that's it. So in a tree topology,
there will be no loops or no redundant paths. In this tree topology, the root is right here. It's like an
upside down tree. There's a root and here the individual branches that are going out.
00:11:43
And there's no loops that are present. And that's why when we have a protocol like the spanning tree
protocol, what it does, is if it sees a loop-- for example, let's say we have a connection like this. So
these three nodes have parallel paths. Spanning tree in a layer 2 environment would identify that,
and then it would start blocking on one or more of those paths to prevent that loop.

00:12:06
And the result is a tree. A logical network topology at layer 2 that does not loop back in on itself. So
there's no active parallel paths in spanning tree, because spanning tree's job is to identify parallel
paths and to create a tree structure that does not connect back into itself, just like branches of a tree.
00:12:26
And this guy right here-- I thought if we have a tree topology, could we have a bush topology? And
you'll notice these little nodes are green, and that's because it's a little bit of humor. There's no bush
topology. I just thought it be fun to actually throw that in.
00:12:40
And the last two bullets here are client server and peer to peer. And these are not referring
specifically to network topologies, but rather the method that we're using services on a network. In
a client-server model, we have devices are very clearly defined.
00:12:54
For example, let's have a user Bob, who's sitting at his PC, and he's accessing a server on the
internet or internally, it doesn't really matter. That server is serving up web content. So Bob, using
his browser acting as a client, is accessing and requesting services of a server.
00:13:11
So the browser itself was built to be a client, and the web server function, running on the web
server, was built to provide services. So that is a client-server model. So what exactly then is peer to
peer? Well if we have two computers-- let's call this computer number 1 and computer number 2.
And let's say they are both connected to some type of a network.
00:13:31
It could be an ad hoc wireless network or they could both be connected to the same subnet, but if
computer 1 starts sharing resources-- let's say computer 1, one his local computer, whether it's
Linux or Windows, sets up a shared folder and calls it share number one and shares it.
00:13:47
Well then computer number 2, assuming that permissions are set up correctly, could access those
resources. So in that moment, computer 2 would be acting as a client and computer 1 would be
acting as a server. But what if the computer 2 sets up a share. We'll call it share 2. And once that
share is set up, computer 1 accesses those resources and pulls down those files to computer number
1. So in that context, computer 1 is acting as a client, getting services, in this case file services, from
the share on computer number 2 which is now acting as a server.
00:14:17
So when we have two devices that are both acting as, for example, a client and a server, to each
other, that would be an example of peer to peer, or peer to peer networking, where each device
could both consume and provide services to other network devices at the same time.
00:14:33

What additional topology that is not in the blueprint, but I added it here, is a dual ring topology.
Now I have a question for you. Why would anybody use two of something instead of just one? And
one of the primary reasons of dual anything, weather's it's dual power supplies, or dual network
connections, or dual default gateways, or dual servers, is for fault tolerance.
00:14:56
So in a dual ring topology, the second ring is therefore fault tolerant. So if there's a failure with a
primary ring, the other ring can go ahead and carry the traffic, so that the network can still function.
So in this Nugget, we've taken a look at several of our network topologies, including the full mesh,
where there's no single point of failure, as well as the very popular star topology that we have in our
switch environments.
Network Isolation
00:00:00
Can a network have benefits from isolation and segmentation? The answer is absolutely yes. We can
have performance improvements as well as security improvements. In this Nugget, we'll take a look
at some other ways of implementing that isolation and segmentation, along with the benefits that it
brings.
00:00:16
Have you ever heard the statement that we shouldn't keep all of our eggs in one basket? And I'm
thinking there reason for that is that if we drop the basket, boom there goes all of our eggs. If we
have two baskets, if we had isolated some of the eggs from the others, if we had a disaster, or a
problem, or a security issue, it wouldn't impact the entire batch of eggs because we still have some
in that separate basket.
00:00:37
Well, that same concept holds true in our networks. By using the technique of isolation and
segmentation in our networks today, we can reduce the risk of security breaches as well as reduce
the risk of a single failure causing a complete failure of all of our network systems.
00:00:53
And ideally, we're not going to have any weak links in our chain. Not every single network has the
same level of importance. For example, if there's a network with two users that are doing word
processing in a shared printer and that network goes down, although that is inconvenient for those
two users who are using the word processing and the shared printer, it's not devastating.
00:01:14
Compare it to a SCADA system. Now, SCADA is an acronym that stands for supervisory control
and data acquisition system. An example would be an industrial control system that is managing and
monitoring an oil refinery and the systems that manage all of that.
00:01:30
For example, a SCADA system would have network devices that are monitoring and reporting back

on the details. For example, what is the pressure in this container at this moment, or for pipes that
are carrying material such as oil or gas, what is the quantity involved? And it's really important that
the networks in these types of systems, these industrial control systems, are able to successfully
collect the data and also to input controls.
00:01:54
For example, to modify a valve to reduce the amount of fuel or oil that's going through a certain
part of the system. Or if there's a catastrophe, the control should be there to shut everything down to
make it safe. So in an industrial control system, it's possible in every component being monitored
and measured is using a separate channel just for that device.
00:02:14
So that way a network failure in that part of the network would only impact the monitoring for
example, of a single device and not the entire oil refinery. So you might have, for example, a plant
network that has isolation and segmentation from the process network, which has further separation
from the field network.
00:02:30
And the network segmentation and isolation should help us or assist us so that if there's a problem
with the plant network, it should not negatively impact the process network or the field network.
And then the field network, for example, each one of these could represent a different refinery or oil
processing or water plant or sewage treatment, or whatever that industrial system is that's being
managed and monitored using a network specifically designed to manage and monitor that system.
00:02:56
Now, a lot of companies have older systems that are still in place. And you might ask, well, why do
they have this old monolithic computer system in the 21 century? And the answer is it's working, it's
generating revenue, and it's reliable. It's very likely they're going to keep it unless they have a
business reason to replace it.
00:03:14
So one thing we need to be careful with if we have a legacy system in place and we're adding new
networks around it, we want to maintain that isolation between the legacy system and our new
system. We don't want a new network to compromise the security or the functionality of a legacy
system.
00:03:31
And a lot of times, legacy systems might have older stuff that's running, older services that are
running. Maybe there's an FTP service that's running as part of a legacy system and FTP is an
example of an insecure protocol. It doesn't do any encryption on its own between the client and the
FTP services running.
00:03:48
So by segmenting the legacy network from the new network, we can limit access to those open
services, and as a result, providing protection because there's no access between the two. And

sometimes if you do need to have connectivity, we need to be careful about the types of cabling and
such that are in place.
00:04:06
For example, if we're implementing new fast ethernet or gigabit ethernet and our legacy system has
cat three cabling and we try to use the existing cabling for a high speed connection, that might cause
us problems because the cabling would need to be up to snuff, up to the category required for the
technology being used.
00:04:23
Another example of network segmentation would be to separate private networks from public
networks. Let's say you and I go into a business, it's very possible that they may have guest Wi-Fi.
You're going to McDonald's or Starbucks it's very possible that they're offering Wi-Fi services.
00:04:39
What we can hope is happening with those wireless networks is hopefully the public networks that
they're offering to the customers are completely separate from their private corporate networks,
meaning they're not on the same subnet, not on the same VLAN.
00:04:54
Because we do not want to allow any access to our inside private networks from outside networks
including guest networks. It's also very likely that between the public networks, the untrusted
networks, and our private networks we are going to have some type of a firewall.
00:05:11
And that firewall standing between the public and private networks can enforce our policy about
traffic that should never be allowed between those two. Regarding attacks that may happen on the
network. It's really not a question of if a company will be attacked, it's really a question of when.
00:05:28
And then when they attack, the next question is is it going to be successful or not? A honeypot is a
special device, a server that may appear or look like it's a real company server, but it doesn't have
any access to the real or critical data for the company.
00:05:45
And that would be an example of a honeypot server. And the reason a honeypot server might be
used is that a company could put one on the network and then monitor the types of attacks and
wacky requests and other things that are being attempted against that server to learn more about the
attacker and what they're trying to do.
00:06:02
And then, if they discover that there is some vulnerability, meaning the attacker was successful in
getting some data, even though it's not sensitive, off this honeypot server, the company could then
help put additional safeguards in place on their real servers that would protect against that attack
being successful on their real production servers.

00:06:18
And a honeypot is it's not really entrapment, but it kind of feels like entrapment. We're putting a
server that is not well protected in the attempt of snaring an attacker to see what that attacker's
doing. And what happens if you have multiple honeypot servers, or what if you have a company
that's strategically placing hundreds or thousands of these honeypot servers around the globe, you
can refer to that as a honey net, a collection of honeypot servers.
00:06:44
And as far as isolation goes, these honeypot servers, they may or may not go on our real DMZ. We
may create another network segment just for the honeypot servers, and on that separate network
segment, we can have virtually zero access into the corporate resources.
00:07:00
So that would be example of isolating, network wise, our honeypot servers from the rest of our
devices on the network. And anything that we're going to try, for example, if we have new patches,
new updates, new upgrades, we never, ever, ever, ever want to apply those first thing on our
production systems.
00:07:18
Whether it's an update for a switch, or a router, or a server, or a workstation, we want to make sure
we test that first in a separate testing environment. For example, a testing lab, to make sure that the
patch does what it's supposed to do, and that it's not creating some weakness or vulnerability or a
problem that would impact our business.
00:07:38
So the testing lab regarding network segmentation, we'd want that testing lab environment to be in a
separate VLAN, a separate subnet, and possibly without any connectivity to our production
network. So we can work in our lab and test environment without doing any negative impact to our
production network.
00:07:54
And then my friend, after the update, the patch, the fix, has been verified, we would then use proper
change control methods and procedures to identify what we're going to do, what the rollback
process is if we need it, have that approved by management, and then at the next authorize change
window, where we've already communicated users that during this time period the network might
be down, we can implement those changes.
00:08:19
And then document what we implemented. In one of our early Nuggets in this course, we talked
about load balancing. That's for example, we have maybe three or four servers that all have the
same content, and we can have a load balancer that's distributing requests across those servers.
00:08:34
Maybe we're using round robin. Server one gets a request, server two, server three, server four, they

can be isolated from each other. So if we have server one on VLAN 10, server two on VLAN 20,
and server three on VLAN 30, and server 4 on a different subnet. In fact, we could have them also
on different switches.
00:08:49
That's another example of further segmentation. That way failure of the switch, if they're all using
different switches and they're all on different VLANs, a single failure of a part of our network won't
impact the results that the load balancers are able to get from those servers.
00:09:04
We also might want to segment our networks and modify the size of our VLANs as an example for
the benefit of performance optimization. What happens with IPv4 if we have one thousand devices
all connected to the same VLAN? The answer is, you get fired. One of the negative impacts of
putting so many devices on the same VLAN is that a VLAN is simply a broadcast domain, a layer 2
broadcast domain. So if one device sends a broadcast, that means 999 other devices all receive that
frame, and they have to de-encapsulate it to see if there's any payload or content that's interesting to
those 999 devices. And most of the time, it won't be.
00:09:47
So by creating multiple VLANs, which are also going to be associated with IP subnets, maybe our
maximum VLAN size is going to be 200. And then one broadcast only has to be processed by the
other 199. Also a failure for that VLAN will only affect those devices in the VLAN as opposed to
all the devices in the network.
00:10:08
So that's another example of network isolation and network segmentation by creating smaller
VLANs. And we might have special VLANs just for voice traffic. So our IP telephones, the voice
over IP, could all be handled in separate VLANs where we have special QoS, quality of service, to
prioritize any traffic inside of that VLAN, the voice VLAN.
00:10:29
So that if there's congestion on the network or things slow down a little bit, the priority throughput,
the priority forwarding can be for that voice traffic. And you might say, well that doesn't seem fair.
Well, the reality is voice traffic really cares about latency, or on the other hand, a protocol like email
SMTP using TCP port 25, if the email gets delayed a few milliseconds or even a few thousand
milliseconds, it's not the end of the world.
00:10:55
The email can still get there, and it's not going to cause a failure of the email system. With a voice
call for voice over IP, we lose a couple seconds, or three seconds, we drop a whole bunch of
packets. And that voice call from a user's perspective, is no longer a functioning application, it's
broken.
00:11:11
So sometimes this segmentation and the isolation will be done for security purposes, maybe certain

subnets or certain networks that are going to be isolated from other networks for the benefits of
security. And then regarding routing between subnets, we can put access control lists on the router
interfaces to filter and control what traffic is allowed to go between them.
00:11:30
And in some networks, we may have to do isolation and segmentation simply for compliance.
Maybe we're an organization that has PII, which stands for personally identifiable information,
people's social security numbers, and birth dates, and medical records and so forth.
00:11:46
And as a result of having that information about users and about our customers, the customers'
networks and systems may be required based on regulations to have certain types of segmentation
and isolation set up, simply to be in compliance with the regulations that they are required to follow.
00:12:02
In this Nugget, we've taken a look at network segmentation and isolation to have more secure and
better performing networks than if we didn't do the isolation. 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.
Unified Communications
00:00:00
In this Nugget, you and I are going to first define Unified Communications, what it's all about. And
then we'll take a look at a few of the details regarding what goes in to a Unified Communications
Network. Let's begin. I'd like you to imagine that you and I are getting into a time machine, and
we're about to go back 20 years to look at companies 20 years ago. And as you and I get out of this
time machine and start looking at companies, what we're going to see is we're going to see some
very basic local area networks using some really old technology.
00:00:30
And we're going to see separate networks, completely separate networks, for things like telephone
systems. Now having multiple separate networks was the only way of doing it back in those days.
But now, as we move back to our present day, what most companies are doing, we're integrating all
of our technologies onto common networks.
00:00:48
For example, we can do voice, and video, and data all over our common infrastructure. And when
we're doing that, that's an example of Voiceover IP, meaning we're sending voice packets, taking
voice, we're digitizing it, packetizing it, and sending it across our IP networks.
00:01:05
Now one of our challenges as we try to integrate all of these devices to work on common networks
is that not every device is the same. For example, here we have an old analog phone, like at
grandma's house, depending upon where grandma lives. And what we might find on this old analog
telephone is that that user may pick up the handset and dial a number.

00:01:27
And you know what a user expects to happen when they dial in number, they expect to have the
other side get a ring, and if somebody's at the other side, to pick up and have a communication,
have a conversation using the telephone. Well, what if the number that we're dialing is an IP base
phone over here? Now to make that work from an analog phone to an IP phone there are
infrastructure devices including Legacy and current PBXs, which stands for a Private Branch
Exchange.
00:01:55
20 or 30 years ago, that was the Legacy device that we would use to integrate the public switched
telephone network with our company's phones for access to and from the public switched telephone
network and the rest the world for telephone calls. In today's current companies, we still likely have
some Legacy components, but we also have modules or ability in our PBXs to work with digital
phones, as well as IP phones.
00:02:18
So a PBX that could handle that is very likely going to be modular with software and hardware that
can handle all three of those environments. And as they go back to the conversation between the
person on this older analog phone and the IP phone, at some point in our network we're going to
have some device that's going to have to make those changes, or make those conversions in order
for those two users to have a transparent experience where they pick up the phone they dial, and
they just talk.
00:02:42
Now, in addition to Voiceover IP, it's also extremely likely that we're going to have video that's
being sent over our networks. An example of that might include something like Skype. Now there's
many flavors of Skype, including Skype for business or whatever they're going to call it in the
future.
00:02:57
But the key is, you can have real-time communications, including video, between two entities. And
that video traffic is also happening across our data network. So the Voiceover IP and video are
examples of real-time applications whose packets and frames need to be transported fairly quickly.
00:03:15
If we have large delays, or if the latency is too big, it can break those applications, meaning it won't
make the application's functional. And if you've ever had a conversation on a cellphone that just
wasn't working well where you couldn't hear everything, you know what I'm talking about.
00:03:29
For real-time communications, the voice and video has to get there in a timely manner. Now as we
integrate multiple services together, it's often referred to as Unified Communications or UC. And it's
going to vary a little bit based on vendor. For example, Microsoft might implement it one way,
Cisco might implement a slightly different way.

00:03:48
But at the end of the day, if we're using the same standards, we should have the ability to interoperate with multiple vendors' devices as part of our Unified Communications. And a big part of
that Unified Communications is called SIP. That's an acronym that stands for Session Initiation
Protocol.
00:04:08
For example, we've got two devices on our network, and they want to initiate a video call or a voice
call. To get the ball rolling to set up the initial connection, a protocol-like session initiation protocol
is very likely going to be used for both video and voice.
00:04:23
And also behind the scenes, we're going to be using something called a CODEC. CODEC is an
acronym that stands for Coder Decoder. And there's lots of different CODECs that we could use as
we encode and decode Voiceover IP and video messages that are being sent over our data networks.
00:04:40
And you might ask, what's the best CODEC to use? And the best CODEC to use would be number
one, one that's compatible with your devices. For example, if we have a Unified Communications
Gateway, and it supports CODEC-X, that is the CODEC that we'd want to use.
00:04:55
Now if we had a Unified Communications Gateway that supported CODEC-X and Y, and Y was
more efficient, and all of our devices also supported that CODEC, then in that case, we'd want to
use the most efficient and compatible CODEC that was available on that device.
00:05:10
So a gateway is simply a device that can help us get from here to there, like on an IPv4 so that we
have a default gateway. And that's just to route packets. In Unified Communications, a gateway is
very likely going to be making conversions from one type of signaling to a different type of
signaling, which also could involve going from one network such as the public switched telephone
network or to a digital world.
00:05:34
Or vice versa. Also, in the initial set up of our conversations, it's very likely they we're using some
type of a Unified Communications server, which could include, for example, an IP-based PBX or a
PBX that has the ability to interact and work with both the old telephony as well as the new IPbased telephony world, including the session initiation protocol and the CODECs and everything
else that's involved as part of that Unified Communications system.
00:06:01
And the Unified Communication device could be a lot of different things. For example, we might
have a multimedia client that's supporting video, or maybe we have a device that supports just
Voiceover IP, or an IP telephone, or a projector, a multimedia projector or camera.

00:06:15
Those are all examples of devices that could work with and participate a Unified Communication
network. Now, one of the challenges is this. Let's say, you and I have several options available to us.
Let's say we have a multimedia video option available both on our computer and our phones.
00:06:31
Let's say that we also have a Voiceover IP option available on our computer and our cell phones and
our smartphones. We also have in our office a dedicated IP phone. We also have email that's
available at multiple different locations, and we also have texting that's available primarily maybe
on our smartphone, but possibly also on our computer as well.
00:06:51
Now the question we might want to ask is this, if an email comes in, where do we want to receive it,
and how do we want to receive it and process that? So if we look at the question of where, when,
and the way we want to handle it, maybe we want some email messages to be read to us.
00:07:07
And this is one of the benefits of a Unified Communications environment. So you and I could do, is
we could set up rules seven ways to Sunday. For example, we could say, if an email comes in from
so and so, we want to automatically get a text message indicating that we have that there, and we
want to have the ability to have that email read to us, which is a conversion.
00:07:27
We're converting it from an email message to an audio stream. Now one of the challenges also is,
let's say that Bob and Lois want to communicate with each other. And the question they have is
what method should Bob used to communicate with Lois? What's the preferred method? Let's say
that Bob wants to make a video call.
00:07:42
How does Bob know whether or not Lois is at a point where she could take a video call or not? And
to solve that question regarding whether this person is available or not, many Unified
Communication systems have implemented something called Presence, which simply let's
somebody like Bob know what the options are at that moment in time regarding contacting Lois.
00:08:02
For example, if Bob goes to his computer, and normally he has like seven options of how he can
communicate and talk with Lois. With Presence, we could go ahead and have, for example, four of
those grayed out temporarily while those four options are not available based on Lois' current
information of where she's at what she's able to do as far as communications.
00:08:20
So the Unified Communications Presence relates to the awareness of the availability and
reachability of a person that you want to communicate with, and the methods that we might use at
that point in time to communicate with that person. Continuing on with our example, let's imagine

that Bob sees that Lois is available for a video chat, so he initiates a video call.
00:08:40
She picks up and now they're talking. Now initially, it was using SIP, Session Initiation Protocol to
set up that call, there is a Unified Communications server involved in that initial setup. And as part
of that Session Initiation Protocol, there are specific CODECs that were decided upon and used for
the ongoing communication between Bob and Lois.
00:08:59
Now the end user doesn't really have to care about what those protocols and CODECs are, because
they're being implemented as network services as part of the Unified Communications. Just be
aware that behind the scenes for Voiceover IP and video, they're SIP used to set up the calls, and
there's CODECs used for the coding and decoding of the packets being sent.
00:09:18
So with the conversation between Bob and Lois, it's very likely that we're using Unicast. Unicast,
whether we're talking about Layer 2 or Layer 3, Unicast is traffic, or packets, or frames that's
coming from a specific single source and going to a specific single destination.
00:09:34
So for example, a packet from Bob to Lois would have the source address of Bob and the
destination address of Lois. And packets from Lois to Bob would have a source of Lois and a
destination of Bob. Now regarding some of our communications, what if we have the CEO that's
going to deliver a message to the entire company real-time? One option could be to have a single
stream sent individually to all those nodes.
00:09:58
But if we do that, if we use Unicast to deliver that to 100 people, the device that's actually sending
on behalf of the CES computer is going to have to maintain and manage 100 different sessions. So
if we're delivering a video message to a large group of nodes or devices, another option that we
might use instead is called Multicast.
00:10:18
Multicast, and let's bring the Multicast over here, so here we have the CEO or the CEO's device and
with Multicast it sends the stream out to the network one time. And then the network intelligently
can deliver that to those devices who are part of that Multicast group.
00:10:35
So Unicast is one to one, like Bob to Lois, and Multicast is one to many, where we send the packet
out, the information out one time, and then the network then flows that out, repeats that out to all
the devices that need to receive that information. And I also just want to point out that Multicast, as
far as forwarding Multicast across multiple routers, that does not just happen by accident.
00:10:58
There would have to be design and configuration set up to allow the Multicast to be routed through

the network to the devices who needed to receive it. And the last piece I'd like to touch on here is
quality of a service. That's what QoS stands for. We've touched on QoS several times throughout
this course together so far, and the reason it's here under Unified Communications is that because
our Voiceover IP and our real-time video calls, for example, between Bob and Lois, those are very
sensitive to delays and latency.
00:11:28
And so if the network gets busy, what we can do is we can train the network to give certain types of
traffic better priority. For example, let's take this router. If a router can only forward x number of
packets, let's say it's 1,000 packets within a certain time slice, but there's 2,000 packets that need to
be forwarded, we can train the router on which of those packets it should go ahead and forward.
00:11:53
It's like having 2,000 people that need to get in a lifeboat, and the lifeboat only supports 1,000.
We're telling the router which 1,000 to go ahead and save and forward. And for the remaining
packets, there's no guarantee. And that's what quality of service is all about.
00:12:06
Now Layer 3 in the IP Header, there are some bits involved that we can use to identify certain types
of traffic, and the application of that is this. If we have an IP phone as the IP phone's traffic goes
into the local area network, we could mark or manipulate those bits in the IP header, the DSCP bits,
and that sense for Differentiated Services Code Point.
00:12:31
And it's called that because we want to differentiate the service that we're going to provide for
forwarding of this device's traffic compared to some other packet that has less preferred bits that are
set as part of the DSCP in the IP Header. But going back to our IP telephone, any packets that the IP
telephone sends into the network, either at the phone itself or on the switch port where they come
in, we have the bits for DSCP set to look very favorable.
00:12:58
And then we train our forwarding devices. We train our devices, like our routers, that if there is
congestion, and it doesn't have the ability to send everybody's traffic right now, the router can then
look at the IP headers and look at these DSCP bits, and based on those bits, it can make its
lifesaving choices.
00:13:15
And the intent is, that if there is congestion, if there comes a moment when there's just not enough
throughput available, we want to make sure that our real-time applications like voice and video are
given priority for forwarding, so that those applications can still survive.
00:13:29
So just for fun, I wanted to show you the IP Header. Let's grab packet number eight right here. And
in packet number eight, if we look at the Layer 3 IP Header information, right here we have the
Differentiated Services field, and that's these bits right here for the Differentiated Services Code

Point, which is DSCP.

00:13:47
And you'll notice in this packet that we're looking at here in the IP Header, we have a 1100 00. And
what I want to point out here is that the manipulation of these bits is absolutely meaningless. It
doesn't even matter unless we've also trained our routers that if there is congestion, they should look
at specific bits in the IP Header.
00:14:09
Specifically at these DSCP bits, and then based on those bits and what they currently are, to make
priority forwarding decisions of certain packets over other packets. Another aspect we have
regarding QoS is called COS, Class of Service, which is involving Layer 2 marking of frames. For
example, if we have traffic that's going over a trunk, we have some 802.12 tags as part of that
trunking, we can also implement some bits that are set regarding Class of Service regarding certain
types of traffic.
00:14:39
And at the end of the day, it's all about making sure that when push comes to shove, the network
and the forwarding devices can make priority forwarding decisions based on those markings,
including Layer 3 and Layer 2, so that our real-time latency sensitive traffic can be forwarded first
in the hope that those real-time applications will still be functional and usable because we're giving
them priority treatment over the network.
Monitoring Tools
00:00:00
In this Nugget we're going to take a look at some monitoring tools that we can use in computer
networks. Let's begin. Having the ability to find out what's really going on is super important in
computer networks. And monitoring tools are a big part of that.
00:00:13
Some of the monitoring tools we can set up proactively to collect information so we can see trends
that are happening. Other monitoring tools we might only use when we're investigating or doing
troubleshooting. In either case, the sooner we know about the some situation that's happening on
our network the better.
00:00:30
And many of these it we have seen before. For example, a packet/network analyzer, an example is
Wireshark, which we've used several times in this course. Where we could collect the data, maybe
we're using port mirroring to collect the data from a VLAN and then we're analyzing it.
00:00:45
And part of the output that a protocol analyzer could show us, for example, would be the top
devices on the network. Which devices are creating the largest amount of traffic flows? And what
protocols are being used primarily by those devices? Now, using a protocol analyzer, like

Wireshark, just to identify who the top talkers are, that's a little bit of overkill.
00:01:07
Because a protocol analyzer, what we're doing is we're collecting all the data which could be quite a
bit and then analyzing that data. Another way of identifying our top devices on the network
regarding protocols is to use a method called the NetFlow. And with NetFlow we can enable that,
for example, on a router.
00:01:23
And the NetFlow record would give us information similar to a phone bill. When I put the phone
bill you can see the numbers that were called, the duration of the calls. But it doesn't have the actual
content, the actual payload, the voice conversations in the phone bill.
00:01:36
That's a lot like NetFlow. It tells who is communicating. It gives some quantity information. But it
doesn't actually contain the payload of all those conversations. And Netflow is example of
something called packet flow monitoring. And the cool thing about Netflow is that we can start
seeing trends of what's happening, building our baseline of what normal traffic looks like in the
network.
00:01:58
And then if we have a problem we could take a look at the current flow of traffic and the current
situation and compare it against the baseline and say, whoa, look at this. This one protocol, ICMP is
way out of line. This is way higher than it normally is and we can start investigating and finding out
what's causing that ICMP traffic, where it's coming from, where it's going to.
00:02:16
And if it's malicious software or software gone bad, we can take the next logical steps to resolve
that. Another very common reporting mechanism and monitoring tool that we're going to have in
most computer networks is a method called SYSLOG. And here's how the SYSLOG game is
played.
00:02:31
We could identify a server. Let's say it's server number 1. And we could run some SYSLOG server
software. Which means this device, server number 1, is willing to collect and receive SYSLOG
messages from devices who send it. So then we could train our devices like Switch 2 to go ahead
and report and send SYSLOG messages over to a SYSLOG server.
00:02:51
And SYSLOG is simply a kind of shortcut word for system log. So we're creating log files
regarding system events. So if we have several switches and a few routers we could trade all of
them to forward their SYSLOG messages to the SYSLOG server. And then if we wanted to view
these SYSLOG messages we could use that server number 1 to view all those messages that were
received from the various network devices.

00:03:13
Another method we could use for monitoring our network devices is called SNMP, the Simple
Network Management Protocol. And for this example, let's go ahead and make this device right
here, server 2, an SNMP server. And depending on the flavor of SNMP we're using we also might
call this an SNMP manager.
00:03:33
So what we could do is we could configure switch 2 to act as an SNMP managed device. And again,
depending on the version of SNMP, this might be called an SNMP agent that is running on this
switch. And then using the Simple Network Management Protocol we could configure Traps.
00:03:52
A Trap is a message that is generated by, for example, a switch or the agent running on the switch
and sent over to an SNMP manager or an SNMP server. And we can control what types of messages
are sent. For example, if we tell the switch via its SNMP configuration that if an interface goes
down it should go ahead and generate an SNMP trap and send it over to the SNMP managers so that
we're aware of it.
00:04:18
Also with SNMP, there's something called a Get. A Get with SNMP is when the SNMP manager
simply makes a request. So the SNMP manager sends a request to the SNMP agent or the SNMP
manage device. And it says, I would like this information. For example, maybe I need to know the
bandwidth utilization on this link or I want to know the interface status.
00:04:39
So a Trap is a message generated by the SNMP managed device, for example, a switch. And a Get
is a message is generated by the server asking for information. And a proper response to the Get
request from the SNMP manager would be the switch sending the information that the manager
requested.
00:04:55
Now, as part of Simple Network Management Protocol, there are lots of different things that we
could look at and monitor. And this tree that I've just drawn today, way simplified example of
different objects or different things we could look at. So let's imagine that each of these little black
dots that I'm circling with blue represents a piece of information or a detail that could be retrieved
by the SNMP manager.
00:05:18
And the challenge here is that not every device, for example, a switch from Juniper, is going to have
different managed objects then a switch from Cisco. Some of the pieces maybe similar but some
might be different. And as a result, we have a MIB, a Management Information Base that effectively
describes the object that we're going to manage.
00:05:37

So here's how it works. You and I, at this server, if we're going to manage a Cisco device we would
use a Cisco MIB. And we would integrate that as part of our SNMP. And if we're also going to be
managing a Juniper switch, for example, we would also want to make sure we integrate the Juniper
management information base, the MIB, as part of our SNMP management system so that we could
correctly identify, monitor, and set the parameters on that type of a device as well.
00:06:02
And if an SNMP manager wanted to go ahead and make queries regarding, for example, all of these
parameters, it's referred to as walking. We could walk the tree and go all the way down to every
single element in order. Or we could walk a portion of the tree.
00:06:16
And that's what an SNMP walk refers to. It's the SNMP manager gathering information about the
individual components available as part of a minute so if a MIB had, for example, 1,000 different
things to look at, the SNMP going through all those items may take a little while to complete.
00:06:33
And before I leave the topic of SNMP, I also want to point out that SNMP has evolved over the
decades. And the older versions were SNMP version 1 and SNMP version 2. And there's also
subsets of those as well. But here's the key. Friends don't let friends use SNMP version 1 or SNMP
version 2 because they are both insecure. So if you're going to be using SNMP, what we want to do
is use SNMP version 3, which has the ability to support encryption to keep the conversations
confidential as those conversations happen over the network and SNMP version 3 also supports
authentication so that our SNMP managed devices, such as switch 2, won't accept commands that
are coming in for example, from an attacker who's pretending to be the SNMP manager.
00:07:26
The other benefit, too, is that we have data integrity available also with SNMP version 3. So when
you think of SNMP version 3, think of the three benefits as authentication, encryption, and data
integrity. And when possible, we'd want to avoid using SNMP version 1 and SNMP version 2. If we
got a call from Lois and she said, I can't access any network resources.
00:07:50
One of these we might want to just determine is are other users complaining? For example, if Bob
has no problem getting access to network resources it's very likely isolated to either Lois' computer
or maybe the switch port that Lois is connected to. So with interface monitoring we may be doing
SNMP to monitor specific interface characteristics.
00:08:10
And we also might use vendors show commands to actually look at the details of an interface to
check the speed or the duplex or the VLAN assignment regarding that port. Or to see whether that
port is administratively shut down or whether it's been shut down to some security feature like in a
Cisco environment if we have port security enabled.
00:08:30

And we use the defaults, which says that only one Mac address is allowed connected to that switch
port. If Lois is running a virtual machine or has another device with a different Mac address and this
switch sees that second Mac address, the defaults for port security in the Cisco environment would
shut down that port and put it into something called error disable.
00:08:50
So a show command on a vendor's equipment could also be an example of a monitoring for looking
at the specifics of an interface. Now, one of our challenges is this-- if we have a system. For
example, let's say we have SNMP set up, and a port goes down or there's another issue with the
switch and a Trap message is sent, we want to make sure that you and I get that message.
00:09:11
So as part of the alerts we have systems including SNMP that have the ability to convert that
message into email, meaning the event happens there's a set of rules that are checked. And then
based on those rules, an email can be sent so that we can be aware of it.
00:09:26
So that could be an email message or an SMS/text message for the intention of making sure that we
are aware of those issues that we need to be aware of right away as the administrator. SIEM is an
acronym that stands for Security Information and Event Management.
00:09:43
So if we look at the SIEM, that is not just one vendor's product. That could be any vendor's product
which is assisting us with security information and event management. An example of this might be
software that does real time analysis of security alerts that are maybe generated from our switches
and routers and servers that can help us quickly identify, for example, the severity of that alert.
00:10:04
Because in a large network there may be hundreds or even thousands of events that happen every
day that are security related. But maybe only two or three that need direct immediate intervention
by the security administrator. In our Nuggets involving wireless we talked about wireless tools.
00:10:19
The survey tool would assist us in identifying what's currently out there. And those same types of
tools that we used for the survey we could also use for troubleshooting as well if problems arise. In
our Nugget on power management we talked about the need for redundancy as far as power goes
for our critical systems.
00:10:36
And if we do have a power issue of some type, it would be really good to know that our backup
systems have kicked in. Or if there's marginal issues with the power coming in, maybe we're having
brownouts or sags or dips in the power. We'd want to have power monitoring tools that can help us
identify that those events are happening.
00:10:54

And in our data centers as well are wiring closets, we'd want to have proper environmental
monitoring tools so that if an air conditioner unit, for example, in a wiring closet fails, we want to
know before it gets to 125 degrees that that AC has failed. It'd be nice to know maybe when it starts
getting to 85 or 90 or 95 that we could have some kind of an alarm goes off regarding the
temperature.
00:11:17
And then that could be sent as an email or text message so that we could be aware of it and take
action. And in the data center we'd also want to manage our humidity as well. So we have systems,
environmental controls in the data center, that are going to manage not just the temperature, but also
the humidity.
00:11:32
If there's not enough humidity we could have risks due to static electricity. If there's too much
humidity we have the risk of condensation. So there's a happy safe place somewhere between those
extremes. And if our systems are not performing correctly, we definitely want to be aware that
there's a problem before it causes damage.
00:11:51
Now, I'd like to draw your attention to this guy in the hoodie right here, who is playing our attacker
in this diagram. An attacker, if they are connected to our network, could have the ability to run a
port scanner. Now, a port scanner could be a great thing or a terrible thing depending on who's using
it and what is found based on that port scanner.
00:12:12
For example, if an attacker connects to our network the first thing he might be or she might do is do
a complete ping sweep. A ping sweep is where the attacker is finding out who on that network is
able to respond or willing to respond to ping request. So let's say that Bob and Lois' computer are
both set up to respond to ping requests.
00:12:31
And now the attacker knows there's two devices. There's dot five and dot 95 which are Bob and
Lois' computers respectively. So now that it knows about those two IP addresses, if can start doing a
port scan of those IP addresses. So maybe it's going to check between Port 1 and 65,000. And you
might ask, why would an attacker scan to see what ports are open on these computers? And the
answer is if there's open ports, for example, if Bob has the open port of TCP port 80 behind that,
that's a well known port for HTTP services. So it's very likely that Bob's computer is running some
type of a web server software.
00:13:10
And then the attacker could go ahead and start to take advantage of that to see whether or not he can
get additional information through that open service of HTTP. And as an example of a port scanner,
one very popular tool it's called nmap, N-M-A-P, and it has a GUI cousin called Zenmap.
00:13:28

They basically do the same thing. Zenmap is simply a graphical user front end for the tool called
nmap. So I just did a scan a few moments ago of my internal network here. And it was able to
determine that all of these devices exist. So if we select one of these, for example, 192.168.1.1 it's
showing me all the open ports.
00:13:48
Now, the type of scan I ran, I told it to scan like the 100 most likely ports. I didn't do a complete
scan of 1 through 65,000 on each IP address that showed up because that would take too long. And
it found DNS and HTTP and several others. And these are in green are all examples of open ports
on that device at dot 1. Literally all those ports are open which implies their services sitting and
waiting behind those ports.
00:14:12
It also shows 94 closed ports, which means that the scanner knocked on the door of 100 ports. Six
of those ports responded-- those are right here-- because they are open ports. And 94 of them did
not respond because they are closed ports. In this Nugget, we've discussed several types of
monitoring tools and how that could be used on a computer network.
Routing Metrics
00:00:00
Which path is the best? Well it depends on which routing protocols we're using and which metrics
those routing protocols are using to make those best path decisions. Let's begin. I'd like you to
imagine with me two routers. Let's call it Router A and Router Z.
00:00:18
And between Router A and Router Z there's a whole bunch of other routers and networks. And if
you and I ever wanted to have a packet routed from Router A over to Router Z, my question is,
which path should we use for the routing of that packet, path A, B, or C? Because this is a very
important question if we want to choose the quote, unquote, best path.
00:00:37
Now a routing protocol, as we've discussed in a previous Nugget such as RIP Version 2, allows the
routers to all communicate with each other, advertising routing information for the benefit of
learning how to reach all of the networks. And the reality, is not every routing protocol is going to
use the same criteria for identifying the quote, unquote, best path.
00:00:57
For example, routing protocols such as RIP and RIP Version 2. RIP uses hop counts to determine
the quote, unquote best path. So for example, it could say that over path A it has to go over two
routers or two hops to get from Router A to Router Z. And over path B we could say we're using
one hop.
00:01:15
Or we're going over one Layer 3 device in order to get to our final destination. And on path C, it

would be three hops. So if we ran the routing information protocol RIP or RIP Version 2, RIP would
indicate that path B is the best path because it goes for the lowest number of hops to get from the
source to the destination.
00:01:33
And then information regarding the number of hops in the path is communicated by running the RIP
Routing Protocol on each of our routers. Now one of the challenges with using hop counts is that it's
not always the quote, unquote, best path. For example, if these links right here were 64 kilobits per
second on path B, and on path C each of them were 256 kilobits per second, the actual throughput
would be better on path C. So another routing protocol-00:02:01
such as Cisco's proprietary EIGRP-- takes into consideration the bandwidth involved as part of the
routing protocol metrics in order for it to make is best decision on which path is best. And we might
also have a protocol that could factor in MTU as well, the Maximum Transmission Unit, making
sure that we have the optimal MTU from end to end across a path.
00:02:23
Any of these factors could be integrated into the metrics that we're going to calculate-- based on the
routing protocol we're going to use-- to determine the best path through the network. We can also
have a routing protocol that's embedding the cost of a link.
00:02:36
An example of that would be OSPF. There's a mathematical formula with OSPF that gives each
individual link based on the bandwidth an effective cost. And that's just yet another example of one
of the mechanisms that we could use to help routers determine the best path to take through a
network.
00:02:54
If we were using Voice Over IP or Video Conferencing-- both of which are a latency sensitive-- we
could have some monitors setup to measure the latency over path A and path B and path C. We
could then-- depending on our network gear-- have it use that information to determine the most
optimal path for the type of traffic that we're forwarding.
00:03:14
Now one of the challenges is this. What if we have two routing protocols running at the same time?
Let's say we have RIP Version 2 running on all of these routers, and we also have OSPF. Now the
challenge, is if all these routers are running both of these routing protocols, which one are we going
to believe? Do we want to believe OSPF, or do we want to believe RIP? And that's why on Cisco
routers-- and they have a similar function on most other platforms as well-- we have something
called administrative distance.
00:03:42
And the funny thing about administrative distance, it has nothing to do with distance. But it has
everything to do with determining which routing protocol-- if they're both running-- we should

believe the most. And administrative distance is a lot like golf.

00:03:58
The routing protocol has the lowest administrative distance, is the one we're going to believe the
most. So by default, on a Cisco router, a RIP Version 2 route has an administrative distance of 120.
And OSPF has a default administrative distance for internal routes of 110. So if RIP Version 2 and
OSPF were both running, all the routers would buy into and believe the OSPF routing information
and not use the RIP Version 2 information. All because of the lower administrative distance of
OSPF.
00:04:29
Although most of these metrics that we've looked at are dealing with routing, which refers to Layer
3. For example IP Version 4 is a Layer 3 protocol, and a router operating at Layer 3 could make
forwarding decisions based on that Layer 3 information. And at Layer 2 we have something called
Spanning Tree Protocol, which is looking for parallel paths and making sure that we don't have
Layer 2 loops. And this SPB-- SPB stands for Shortest Path Bridging-- and the application for SPB
is to replace Spanning Tree Protocol in a data center environment.
00:05:05
So if we contrast that to Spanning Tree Protocol, which simply saw parallel paths and killed
everything except for one of them, the Shortest Path Bridging would allow us to keep those multiple
parallel paths and utilize all of that bandwidth. This last piece, Route Aggregation, is all about
summarizing our routes.
00:05:21
For example, here at the branch office, we currently are learning about a whole bunch of 10
networks. We know about the 10.1 network. We know about the 10.2 network, the 10.3 network,
10.4 network, and those are all being advertised up to the branch office.
00:05:37
Depending on which routing protocol we're using-- if we're doing route aggregation, which is
another fancy way of saying summarizing our routes-- instead of saying we have all these 16-bit
networks, we could summarize them and say we have a 10.0.0.0/8 network. And then we could
have one routing entry on the branch office instead of four routing entries.
00:05:57
And that summarization could be done on router two for the benefit of the branch router not having
to have as big of a routing table. Now in our topology having four little routes is not a big deal.
However, in a network with hundreds or thousands of subnets, using summarization and route
aggregation can help greatly simplify the routing tables on our routers that don't need to have all
those intricate details.
00:06:21
As an example, let's take this router right here, the branch office router, and let's take a look at the
routing table. And once again, it's not the syntax that you need to learn or memorize for Network

Plus, but it's the concepts. So here we have our four networks.
00:06:34
So these have all been dynamically learned via the RIP Routing Protocol. And these are all
advertised up to the branch router via RIP. So this first number on a Cisco router, this represents the
administrative distance for the Routing Protocol RIP. So if RIP was used, and OSPF was used, and
the router how to choose between which routing protocol to believe, the branch router would choose
OSPF if it were running because OSPF has a lower and better administrative distance then the 120
from RIP. This column right next to it is showing us the hop count, which is what RIP uses to
determine the best path through the network.
00:07:10
So effectively, from the branch router's perspective-- its routing table-- it believes that the 10.1
network is three hops away, the 10.2 network is two hops away, and that the 10.4 network is only a
single hop away. So if there were multiple choices via RIP regarding forwarding, the router would
use the path that had the least number of hop counts associated with it.
00:07:31
Because hop counts is the metric that RIP is using for its decision making. So for route aggregation
or route summarization, if we wanted to on router two, we could set up summarization to say, hey,
you know what? To get to 10.0.0.0/8, which is a summarization of 10.anything, go ahead and
forward those packets my way.
00:07:52
And then router two could advertise that summarized route and then not share the more detailed
10.1, 10.2, 10.3, and 10.4 because the summarization was being sent up to the branch office router.
Now RIP is not one of the best protocols on the planet. In fact, it's one of the least desirable
protocols because it's just not that smart.
00:08:11
However, as an example of doing some summarization, let's go to router two. And what we'll do on
router two is we'll advertise via RIP, a summary address for 10 anything up to the branch office.
And what we should see, is that route should show up in the routing table on the branch office
router.
00:08:28
So here on router two we'll go into configuration mode. And we'll go into interface serial 2/0, which
is the interface that we're using to connect to our wide area network that leads up to the branch
office. And here we use the command IP summary-address for RIP.
00:08:42
And we'll put in a summary address of 10.0.0.0 with an 8-bit mask. So RIP is not the fastest to
converge. It may take a few moments for the branch router to realize and learn this new
information. But once it has, if we go back to that branch router and we issue that same show
command again-- which is showing the RIP learned routes-- there's our new route.

00:09:03
So we have this 10 network that we've just learned about. And now if we wanted to, we could also
go into the configuration of router two, and tell it to stop advertising the 10.1, 10.2, 10.3 and 10.4.
And we did that additional configuration R2, the branch office router now only has to know about
on 10 network route, as opposed to four individual specific 10 network routes. And that's an
example of a route summarization-- or route aggregation-- where we can have a single route
represent or hold the place of multiple more detailed routes.
00:09:36
In this Nugget, we've taken a look at some routing protocols and examples of what those routing
protocols use as metrics to help them identify the most preferred path for routing through the
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.
Interface Monitoring
00:00:00
In this Nugget we're going to discuss and do an example of interface monitoring on a network
device. Let's begin. I remember somebody once telling me that if mama ain't happy ain't nobody
happy, well in a networking perspective if Layer 1 and Layer 2 aren't happy, the upper Layers of the
protocol stack don't have much of a chance.
00:00:20
So quite often, especially when troubleshooting, we want to make sure that our interface monitoring
skills are up to snuff. And some of the monitoring that we're going to do is going to vary on the type
of gear that we're monitoring. For example, are we monitoring a switch and its interfaces, or a
router and its interfaces, or perhaps a firewall, or a server and its interfaces respectively? And the
output is going to vary a little bit, again based on the vendor and the gear that you're using on the
network.
00:00:46
And some common elements that we're likely to see when we look at interfaces are the status of that
interface. In a Cisco environment, if an interface is administratively shut down that means it's not
going to work. And that would be one of the first things we want to look at if we were doing
troubleshooting.
00:01:00
Meaning, did we as an administrator allow the interface to be up and operational. And then
secondly, it needs to have connectivity. So on an ethernet network the connectivity would be getting
the link a little signal from the devices connected to that switch port.
00:01:14
Whether it's a printer, or a computer, or a server that's completing the circuit between that device
and a switch. And we had a separate Nugget on the unshielded twisted pair and the correct pairs of
wires to use based on the standards for unshielded twisted pair.

00:01:28
So on an ethernet network we'd be looking for things like speed and duplex. If we have it set to
auto, hopefully the two devices-- for example, the PC and the switch-- have automatically
negotiated full duplex at the highest possible speed supported by both parties.
00:01:42
And on a serial connection, for example or wide area network connection up to the branch office we
would not expect to see anything related to speed and duplex because speed and duplex is related to
ethernet and not to a serial WAN connection. Details regarding errors, utilization, discards, packets
being dropped, or interface resets would all be really good to know about early on.
00:02:05
Especially if that interface is to a common device, for example from a switch to a router or a WAN
connection. And a great way of getting that information centrally collected is using SNMP. We
could run SNMP agents on the devices, such as our routers and switches.
00:02:22
And we can have that SNMP function running on our routers and switches sending alerts over to
our SNMP management station. So for example if utilization exceeds 80%, or if there's excess of
errors, or discards, or packet drops, or interface resets we could send that information over via
SNMP.
00:02:38
Now on the older, insecure versions of SNMP that would be referred to as an SNMP trap. Where the
SNMP agent running on those devices generates the message that's being sent over to the SNMP
manager. With the SNMP version 3 which is the one the supports authentication and data integrity,
they refer to it as an inform as opposed to a trap.
00:02:59
But is basically the same animal. We're communicating from the SNMP device information over to
an SNMP management station. So what I thought would be fun to do is, let's take a look at a router
interface. We'll use some show commands specific for the router I'm on.
00:03:13
It happens to be a Cisco iOS router. And as we go through it together we'll take a look and see
which of these common elements we can find in the output of a show command on that router
interface For this demonstration, let's use router R2. And let's use a show command to look at the
interface details for interface gigabit 1/0. Now on a Cisco router the output is going to scroll one
page up at a time and then we can press enter to bring it up one more line at a time or press space to
bring up an entire page at a time.
00:03:43
So as an example of interface monitoring, let's take a look for errors. Down here in the bottom we
have input information and output information. So regarding input errors, it's showing us that we

have zero input errors and also zero output errors. So from an error perspective that seems great.
00:04:00
Regarding utilization on this Cisco device, this interface currently have a load of 1 out of 255. And
the txload represents traffic that we're sending out, and the rxload represents traffic that's coming
into the interface. So a 1 out of 255 is the lowest it could possibly be. If we had a value of 200 or
240, that my friend would represent a relatively high quantity or percentage of utilization on this
interface.
00:04:28
Here we have the information regarding our speed and duplex. So this is 1,000 megabits per second,
which is one gigabit. And we're operating at full duplex. It's also indicating here that the interface is
up and up. And often on a Cisco device we can loosely associate the first up meaning that Layer 1 is
up, and the second part here for protocol up is loosely analogous to Layer 2. Which is handy if we
want the interface and the connection for this interface to be functional.
00:04:55
Down here it also indicates that we've had five interface resets. And depending on the type of
equipment that we're using and how long these counters have been running, that may or may not
indicate some kind of a problem with this interface. Sometimes an interface if it's functioning
correctly will do a reset in hoping to correct itself to start working and start functioning.
00:05:15
So if we cleared the counters, for example, regarding this interface and then a minute later had 10 or
15 interface resets, that would very likely indicate that there's a problem either with the interface or
with the media that this interface is connected to.
00:05:29
And also a five minute input and output rate regarding the traffic coming in and out of this
interface. And the fact that we have received zero packets on this interface indicates on this router
interface that there's a problem. Because it's very, very unlikely that we're going to receive zero
packets on a router interface if it's connected to an active network.
00:05:49
So one way we could use to verify that we are connected to, for example, the correct switch is we
could use Layer 2 protocols such as Cisco's CDP or LLDP that we've discussed in a previous
Nugget. Just to verify at Layer 2 that we are connected to the right device and right port on that
device that we think we are.
00:06:08
And those are handy ways of verifying basic connectivity without having to physically walk to
where the gear is to take a look at the physical cabling. In this Nugget we've discussed some ideas
regarding monitoring and interface on a network device, including going to the output of a show
command on a Cisco router interface as an example.

Cables, Connectors, and Tools

00:00:00
Cables, connectors, and some tools. Let's begin. So here's the story. I was going through the
blueprint for Network+ n10-006, and there was a few items regarding cables and connectors and
tools that I hadn't crossed off explicitly on my list. So a few of these we may have touched on
before, but I just wanted to make darn sure that you and I take a moment to make sure these are
covered.
00:00:23
So let's start with RJ-45. The RJ-45 connector looks like this. We're familiar with that one. It's eight
pins. And we've talked about the standards for the termination of that unshielded twisted pair cable
using the RJ-45 connector. And I would strongly recommend that if you haven't already or if you
need to go back and review it that you commit to memory the wires involved for both the 568A and
568B standards. Now, to actually terminate this cable, we'd need some tools.
00:00:55
For example, we might need a wire snip so we can, for example, cut the cable off to the length we
need it, peel back this outer plastic-like coding. And this outer coating, it may either be PVC or
plenum. And the whole key behind that is that if this cable is going to run in some type of an
airway, thus supplying air to the facility or to the building, it needs to be a plenum-rated cable.
00:01:20
I've been told that if it burns, it's less toxic. And that reminds me of the story of me going to the
store and buying some pajamas for one of my children. And on the label it said "Flame Retardant."
And I said, does that mean they don't burn? And she said, no, that means they don't like to burn.
00:01:36
Well, a plenum cable in heat will absolutely be destroyed. It's simply less toxic. And whether it's
PVC or plenum with unshielded twisted pair, it is indeed unshielded. We don't have any kind of a
metal foil or wrapping around the outside. So then, as we take a look at the eight wires which are
made up of the four pairs, we might need some wire strippers to pull the plastic away from each of
these set of wires.
00:02:02
And if we look at the details for the wires, it's not just a solid strand of copper for each wire. It's
actually a whole bunch of really fine, small strands of wire. And they do that for better connectivity.
And if it bends, there's a better chance of it not losing connectivity.
00:02:17
And then, with the wires in the correct order, we would push on the RJ-45 connector, use our
crimper tool, and make sure we have a solid connection between these pins here and the wires
inside that RJ-45 connector. Now, what if the RJ-45 cable that we just created is not long enough?
What we could do is we could use a UTP coupler.

00:02:38
And a coupler is a device that takes two things and puts them together. For example, a Cat6 inline
UTP coupler would allow us to put a UTP cable with an RJ-45 connection in this end, another one
in that end to extend the cable. And this is just a passive device.
00:02:55
It's not supplying any type of power. So we still have to make sure that our overall run is no longer
than 100 meters from the network interface card on our PC or server all the way to the other end at
the switch port, to stay in spec. We'd also want to make sure we observe the current category of
cable.
00:03:11
If the network infrastructure is requiring Cat 6, everything as part of the cabling needs to be up to
that specification. A weak link, for example, using a Cat 3 coupler, could impact our signal where it
could be unusable. Or if it's workable, maybe there's some problems being injected because our
entire cable plant from end to end which is requiring Cat 6 has a weak link that's causing some
failures. Now, an RJ-11 connector is like a mini-me version of an RJ-45 connector. This is an RJ-11
right here. And it's got less wires in the cabling and less pins.
00:03:49
So we traditionally see RJ-11 connectors used in telephone systems. And then this guy right here,
the RJ-48C, it looks a lot like this. And I'm crossing out the color codes for the wires because the
big difference between an RJ-45 and an RJ-48 is how the actual wiring is done because the physical
connectors, they look identical.
00:04:15
It's got eight pins. It's just the wiring is done a little bit differently from end to end. An RJ-48C is
often used for WAN connections. For example, a T1 could be delivered from the service provider
over an RJ-48C cable connection, which would then plug into our customer's device.
00:04:32
So the RJ-48C connection could plug into-- let's say, we have a WAN router. It's got this jack here.
We plug it in. And then on the customer's router here, it's got a CSU/DSU, which stands for Channel
Service Unit/Data Service Unit. It's the electronics and the brains, if you will, that allow this router
to communicate over that T1 circuit using the wide area network connectivity provided from the
service provider over this T1 connection.
00:04:58
In the old days, the CSU/DSU was an external unit. It kind of looked like a big modem. But now, in
the 21st century, the electronics for that are usually integrated into the router that's connecting to
that WAN circuit provided by the service provider. So in summary, RJ-11-- think telephone. RJ-45-think ethernet. And for RJ-48C-- think about wide area network connectivity, for example, a T1
circuit that's being provided from a service provider.
00:05:24

As technology changes, our interfaces also change. In the old days, on virtually every computer, for
example, there was a serial interface. It was called an RS-232. And the RS-232 was a standard for
serial. Now, the interesting thing is that sometimes this is also referred to as EIA-232 because the
standard is created by the Electronic Industries Association.
00:05:48
So regardless of whether we see RS-232 or EIA-232, we're talking about standards for serial
communications. And we're also talking about relatively slow speeds like 9,600 bits per second. So
relatively slow speeds compared to everything else that we're using today.
00:06:07
For example, a T1 for a wide area network connectivity-- a T1 circuit might be operating at 1.54
million bits per second, where the lowly RS-232 may be doing 9,600 or even possibly double that.
But it's still really, really low compared to our other higher speed connectivity options for
networking.
00:06:28
So on the back of our computers, we'd have one of two options for our serial ports back in the day.
We'd have this 9-pin male serial port. Has nine pins. Or they also had a 25-pin flavor of the same
thing. And they called it a DB-9 or a DB-25. And then we'd get a cable, back in the day, and connect
from that serial port over to the device that we wanted to communicate with.
00:06:51
Maybe it was a serial printer or some other device that had an RS-232 interface on it. Now, one of
the challenges that a lot of people face today is that we don't have DB-9 or DB-25 RS-232
interfaces on our computers anymore. A new computer is going to have a USB interface.
00:07:11
So that's a newer and better serial interface that a lot of computers use now. So if you and I
purchased a brand new router or a switch, it's very likely to contain as part of our purchase, for
example, from Cisco or Juniper, a console cable. And that's what this is right here.
00:07:29
Now, this console cable has this RJ-45 connector at one end and a DB-9 serial connector for RS-232
at the other. So we have a couple of options. Number one is go through the junk box and see if we
can find an older computer that still has an RS-232 DB-9 port, or we could purchase an adapter.
00:07:50
And that's what most people do. They buy an adapter that goes from USB on one side to a DB-9
male RS-232 interface on the end. So if we connect this all together, the USB would plug into our
computer. This DB-9 would connect to this end of the console cable. And then this RJ-45 looking
connector would plug into the console port, which is expecting that RJ-45 connector. And here's the
interesting thing about this cable.
00:08:16

This is not a straight-through cable. It also is not a crossover cable. It is referred to as a rollover
cable. And it gets a little funky because on one end we have an RJ-45 connector and the other end
we have a DB-9. So on this DB-9 connector, we're not using all nine pins, if you will.
00:08:37
We're using eight. And those pins also have corresponding numbers. So a rollover cable-- if we look
at the pinouts, for example, 1, 2, 3, 4, 5, 6, 7, 8 on one side. They map to 8, 7, 6, 5, 4, 3, 2, 1 on the
other. It's literally a one for one rollover. 1 to 8, 2 to 7, and so forth. And that's the pinout for a
rollover cable, which we commonly call a console cable, that we would use to initially connect to
the console port on a router or a switch as one of our networking devices.
00:09:09
Next, I'd like to chat with you about our wiring closets. It's very likely that we're going to be using
some type of patch panel inside the wiring closet. So we might have, for example, a 19-inch rack in
each wiring closet on each floor where all the UT cabling comes in from that floor.
00:09:24
And what we can do is we can terminate that cabling at the patch panel. So this is the back view of
the patch panel, right here. So we have the unshielded twisted pair cabling that's coming in. So to
terminate this, we'd take our cabling and then we'd put one wire in each slot, use this really cool
little punch down tool that pushes the wire into the groove.
00:09:44
And the punch down tool is designed so that you can very accurately get the connection between
the metal on this block-- it's called a 110 block-- and the actual wire that you're pushing in. I also
would like you notice something. On this unshielded twisted pair cable that's coming in, you'll
notice that the actual punch down of each of the wires is done very close to where the cable comes
out, and there's not a whole bunch of free floating wire.
00:10:08
And that's because we're trying to maintain the correct number of twist per foot based on the
specification that we're supporting, whether it's Cat 5 or Cat 6. So we're maintaining the integrity by
not pulling out, for example, two feet of wire and untwisting it before we terminate it at the back of
this 110 punch down block. So the 110 block is a type of a block that you can punch down wires
into.
00:10:31
The 110 does not refer to quantity of wires. The 110 is talking about the specification. And
normally, 110 blocks are going to be used with Cat 5 and Cat 6 cabling plants as part of the patch
panels. So we take another look at this on the back. Here's where we had punched down all of our
unshielded twisted pair cabling here.
00:10:50
And on the front, we have these RJ-45 connections. We take a patch cable and go from that, for
example, over to a port on our physical switch. And then hopefully, these would also be labeled, so

we'd know exactly where they go. So the connectivity would be from the switch port to the patch
panel.
00:11:07
The patch panel is then wired via a horizontal run on that floor over to an office or a cube. In that
office or cube, it's also very likely going to be punched down. So here's that cable in the user's cube
or office. We use the punch down tool to get the wire seeded and connected to the right pins.
00:11:25
And then the user, like Bob, would take his computer with a patch cable, and then plug that in into
that jack in his office. So right here, also, they have an example of 568B wiring. And I want you to
pay very close attention to something. Look at where the pins are.
00:11:40
So we have pin 1, 2, 3, 4, 5, 6, 7, 8. So when we learned the pinouts for pins 1 through 8 in our
previous Nugget on unshielded twisted pair-- this is saying the same thing for 568B. It just has them
here shown in a non-sequential order. So at the end of the day, it's still white/orange for pin 1. It's
still orange for pin 2. White/green for pin 3. Blue for 4. White/blue for 5. Green for 6. White/brown
for 7. And brown for 8. So the 568B standard has not changed. The secret here on this 110 block is
that these numbers for these wires are not in a sequential numerical order, but they still have the
correct wire associated with the correct pin based on the standard.
00:12:24
So this is a 110 block. So what is a 66 block? Well, 66 refers to yet another standard which is old,
really old, and it looks something like this. So here is a 66 block, and it also uses a punch down
tool. So for example, you may have wires coming in on this side that are punched down, wires
coming in on the left hand side, and you can also place jumpers between them to create the
connection.
00:12:49
So if you see a 66 block in a wiring closet, it's very likely being used for telephony. It could be used
for-- for example, 10 megabits per second with Cat 3 cabling. That's a possibility, but it's a bad idea.
All of our ethernet networking should be on 110 blocks or better to support Cat 5 and Cat 6. And
any time we're dealing with old 66 blocks or Cat 3 cabling, we're going to have problems on our
higher speed ethernet if we try to use the older technologies.
00:13:20
Now, a lot of companies will have fiber for the vertical run in their companies. And we have
different types of fiber optic cables. We have single mode and multi-mode, and we have different
SFP modules to go into our switches to support the termination types on that fiber.
00:13:35
For example, we might have SC connectors or LC connectors or ST connectors. And one aspect
regarding our connectors is that if we have any kind of obstruction like dirt and dust, for example,
between the connector and the fiber optic cable, that could cause us a degradation of the light that's

being used to communicate our bits back and forth across that media.
00:13:57
One of the aspects-- and this is pretty cool-- that we can use with our fiber optic cables is we can
control the method that we're using for the termination. And two options here in the blueprint are
APC and UPC. When terminating the fiber optic cable to one of our connectors, we could use a flat
surface termination.
00:14:16
And it was discovered that if we use APC, which is Angled Physical Contact, as opposed to flat
surface contact between the optical connector and the fiber optic cabling, there would be less of a
loss. So the APC stands for Angled Physical Contact, and UPC stands for Ultra Physical Contact.
00:14:36
So if we had to rate these as far as their ability to get the signal through, we would give the bronze
medal to flat surface. We'd give the silver medal to Angled Physical Contact. And we'd give the
gold medal to Ultra Physical Contact. So this is one of those rare occasions in a Nugget where we
can talk about strippers and physical contact and be totally legitimate because of course, we're
referring to wire strippers with copper wiring and physical contact regarding the termination of fiber
optic cables.
00:15:07
And if we ever need to convert between different types of media-- for example, maybe we need to
go from single mode fiber to ethernet over copper or perhaps, from multi-mode fiber over to
ethernet on copper or from single mode fiber over to multi-mode fiber or vice versa, or if we're
going to go from fiber over to coax, we have devices in our network that can be used called media
converters that can do that conversion for us.
Network Infrastructures
00:00:00
In this Nugget, you and I are going to take a look at several different types of network
infrastructures. Networks, like people, come in many different shapes and sizes. Some networks are
built for specific purposes, for example a specialized network like a Medianet.
00:00:15
A Mediatnet would have a specified purpose, for example, of voice or video or other multimedia
support over a network. And the acronym VTC refers to Video Teleconferencing. In today's
networks, we can take voice and video and digitize it and packetized it and send it across our IP
networks.
00:00:34
In doing so, we're often going to use protocols like Session Initiation Protocol. And what SIP is
going to do, among other protocols, is going to assist us in setting up and negotiating individual
sessions for voice and video between two or more devices on the network.

00:00:51
An ISDN, which stands for Integrated Services Digital Network, is a fancy way of saying digital
phone lines. So a company may have a PRI ISDN line coming in. The company can take chunks or
sections of that as individual channels and use that in different ways.
00:01:08
Maybe they'll use some of it for voice traffic. Maybe they'll use other channels for data. And the big
concern with any Medianet is latency and delay, because most a real time conversations-- the key
word there is real time-- and if there's a huge delay or latency between the two individuals who are
using the Medianet to communicate with each other that can cause a failure of that application.
00:01:29
So that's why we use techniques like QoS, Quality of Service, to help prioritize certain types of
traffic in the event that there is congestion on the network. And not every network is the same size.
For example, let's consider this little teeny dog here, and let's talk about PANs.
00:01:44
PAN is an acronym for a Personal Area Network-- very, very small. So examples of personal area
networks would be Bluetooth. Many of us have already experienced the range that Bluetooth
supports. For example, we leave our smartphone in one room. We have our Bluetooth headset on.
00:02:01
We walk away from it, and after so many meters, we no longer get the signal. Bluetooth is one
method we could use for a personal area network. Another option is infrared, and there's also NFC,
which stands for Near Field Communication. In fact, I was at Interop last week, and as part of the
registration process, they gave me a badge.
00:02:22
And then as I went by the individual booths, if they wanted to scan my badge, I would just get my
card physically close to their NFC device, and it would scan my badge and collect that information.
Now NFC also has the concept of an initiator as well as a target.
00:02:37
Now, we've seen these terms before, but it was in the context of iSCSI, where the iSCSI initiator
was the client, and the iSCSI target was the network appliance that was providing the storage via
iSCSI over the network. And in combination with that, if we wanted to support large frames across
the network, we might want to enable jumbo frames as well.
00:03:00
Now, in the concept of NFC, the initiator would be like, for example, the NFC reader that has
power. That would be the device that the vendor holds if they want to scan people's badges. And my
Interop registration card that they've given me would be the target within NFC.
00:03:15

And a lot of smartphones have NFC built into them, so you just have to get physically close for
example, between two phones to exchange contact information. The local area network is usually
geographically local, for example, inside of a building. So in our network topology for Network
Plus, we have a local area network at the headquarters office, and we have a local area network at
the branch office.
00:03:38
And if we allow connectivity between them, using a service provider, we also would have wide area
network connectivity between the two LANs. So over here there's a local area network. here there's
a local area network. And here's our WAN connection between them.
00:03:53
And another popular option for wide area connectivity is also, instead of using a serial connection,
is to simply leverage a virtual private network connection. So maybe we use the internet, and we
build a virtual private network between the branch office and the headquarters office.
00:04:09
And we would still have, in effect, a wide area network, but it's being implemented courtesy of a
virtual private network being overlaid on top of the existing internet. And a MAN is a Metropolitan
Area Network. So, for example, let's say we're in California-- northern California-- and we've got
several offices fairly close.
00:04:30
For example, we've got one in San Jose, one in San Francisco, one in Palo Alto, one in Sunnyvale,
and we've got some really cool microwave that's connecting those four sites together at relatively
high speed. That could be considered a metropolitan area network.
00:04:44
And for this example, we'll just call it Silicon Valley-ish, in that general area. And at each of those
sites, it's very likely that that company is also going to have a wireless local area network courtesy
of some access points that are at each of those sites.
00:04:59
And on those access points, it's very likely that they're going to be using 802.11i, which is also
known as WPA2-- WiFi Protected Access. And in our Wireless Nugget, we also talked about using
non-overlapping channels and making sure that the access point, as it's physically connected to the
switch, is using the appropriate speed and duplex.
00:05:20
And sometimes a wireless network is referred to as a hot spot. For example, we go to Starbucks or
McDonald's, and they've got a quote unquote "hot spot." It's simply a wireless network that we are
able to connect to. And from a security perspective, be very, very careful about connecting to any
open wireless network.
00:05:39

Because, if it's open, there's no authentication required. How do we know it's really being provided
by the establishment and not by the person who's sitting two seats down, who's acting as a rogue
access point, trying to collect our information Another type of special purpose network that we
might see is an ICS.
00:05:58
And ICS stands for an Industrial Control System. For example, an oil refinery a or a power plant are
going to have industrial control systems to monitor and manage their system. And we've already
discussed, in previous Nugget, the concept of SCADA, which stands for Supervisory Control and
Data Acquisition.
00:06:18
So a SCADA system could be a subset, if you will, over overall industrial control system. So an ICS
server would be an industrial control system server as part of that infrastructure. And DCS stands
for a Distributed Control System. And you can imagine how some of these networks might be very
critical.
00:06:36
Because if we have some component of our system that fails, and there's too much pressure in one
point or the wrong chemicals or the wrong quantities start to be mixed together, our system should
be able to identify that those issues are happening and stop it.
00:06:50
So a DCS is a Distributed Control System. So, for example, if we have a failure at some point in our
network, it shouldn't stop these safeguards that are implemented at each of the locations. And for
security reasons, it's going to very likely be a closed network.
00:07:05
And the reason for that is because a closed network is going to be more secure and better protected
than one that's open. Industrial control systems are going to involve programmable logic controllers,
referred to as PLCs. These controllers generally will interoperate with things like motors and
sensors and pumps.
00:07:23
And a remote terminal unit is a circuit board. You can kind of think of that like a very mini me
version of a computer that has the responsibility of interacting with one or more devices in that
network. And although, regarding Network Plus, you probably are not going to have to recite the
details of the interactions in a SCADA network or an industrial control system, what I think would
be within the scope for Network Plus is to understand the importance of isolation and security for
these types of networks.
00:07:51
Because we're talking about a situation where if the network goes down or has a problem, there
could be loss of life and serious consequences if these networks were compromised. So one of the
techniques that we would use to protect a network like this is to have network isolation.

00:08:06
So our common users and so forth would never have any type of direct access to the SCADA a
system or to the ICS. And we'd also want to have physical security and fault tolerance in place to
help protect those systems as well the networks that allow those systems to communicate with each
other.
Cloud Services
00:00:00
When Joni Mitchell sang the song "Both Sides, Now," with the lyrics "I've looked at clouds from
both sides now" back in 1969, I'm sure she had no idea about the cloud services and how prevalent
the cloud would be in our current day networking. Let's begin.
00:00:17
I'd like you to imagine that you and I work at a company. We've been invited to a meeting where
they have decided they want to build their own software that can do calendaring and scheduling.
And in this meeting, we've identified that we have some internal server resources that we can use,
as far as where we can run the application once it's created.
00:00:37
We also have some application developers who can write the software. And of course, we have a
whole bunch of users that can leverage that calendaring and scheduling software. Now just think
about all the effort that would go in to creating this software. We have programmers.
00:00:52
We have servers. And at the end of the day, that's going to equate to quite a bit of time and money to
get this software created. Now instead of having the internal servers that can run the software and
having developers, whether they're contracted or internal, developer, create, and test the software,
why don't we just purchase the software as a service? And that, my friend, is what Software as a
Service is all about.
00:01:16
We let somebody else already create the software, manage the software, host the software-- and
what we do is we have our users simply access and run the software. So out here in the cloud we
have, for example, some service like Google. I think Google is a terrific example of somebody that
has cloud-based services, including Google Apps.
00:01:38
They've got a fantastic calendar application, and they take care of all the details. They have the
servers to run it. They created and tested the software, and they support it. And you and I, as users,
simply using a browser, we connect and simply take advantage of that software.
00:01:53
Now calendaring and scheduling through Google Apps is a simple example of Software as a
Service. But it could also be custom applications that have been created and are being hosted, in the

cloud, by a third party vendor. So that you and I as customers-- all we have to do is pay for the
access to that application and simply connect and use it.
00:02:12
So Software as a Service is one of our first examples of letting someone else provide the services.
And in our first example here it's software being delivered as a cloud-based service. And I want to
point out that just because they're in the cloud does not mean that no one has to take ownership
responsibility for those apps.
00:02:30
The person who is providing those services is responsible for the maintenance and care and feeding
of the application, as well the servers that those applications are running on. But from the end user's
perspective, it's simply point and shoot. Now let's imagine that after we make the recommendation
of using Google's calendar application, which is a free Software as a Service being delivered by
Google-- in that same meetings it's next discussed about a custom application that we are going to
write in house, that isn't currently available.
00:03:00
Or for other security reasons, we want to create it on our own. And for this example, let's say it's a
preventive maintenance program. And you might think, preventive maintenance, how is that going
to be a critical aspect? Well maybe we have an industrial control system for an oil refinery or a
power plant, and we want a preventive maintenance application that can track the hours of use, for
example, on certain types of equipment, so we can do appropriate preventive maintenance on those
devices and schedule downtime.
00:03:28
And then just wait for stuff to break. So as we discussed the creation of this preventive maintenance
application, we would need some programmers. So we either have internal programmers or contract
programmers, who could write that code for us. And we'd also need a development environment for
those programmers to work in.
00:03:45
So maybe we have our own servers internally that are providing a framework for the support and
creation and testing of that custom application. But then, before we kick off that project, we identify
that, you know what, it's going to take a lot of computing resources for the creation and
development of this custom application.
00:04:03
Instead of using our own internal servers for this platform, where they can develop the application,
why not purchase, as a service, a platform for the development of that application? And that, my
friend, is what PaaS, Platform as a Service, is all about.
00:04:19
So with Platform as a Service, our developers, instead of logging into our local servers in our local
programming environment, they can go ahead and connect to a platform, a development platform,

that's hosted and supported by a third party in the cloud. So that third party would be responsible for
the servers that were supporting this environment, as well the operating systems and all the other
details behind the scenes to support that development environment.
00:04:46
So our developers would get connectivity to this development platform. And using that platform,
that could then create and test and validate the software that our developers are creating. And then
once the application is ready to go, we could then deploy the application either on our local servers
or maybe we get a third party to deploy the application that our developers just wrote in the cloud.
00:05:08
Which again, would be Software as a Service. And when developing new applications, another
really important thing to consider would be is this application already available as Software as a
Service through some third party vendor. Do we really have to write our own? And many times,
applications are readily available as Software as a Service where we don't even have to go through
the effort of creating a development platform and creating the software ourselves.
00:05:35
So going back to this meeting that we're in, the next item that came up was the idea that they
wanted to build a data center right here at the headquarters location. So they talked about some
details that might go into that data center. We're going to need some physical servers in that data
center.
00:05:50
We're going to need storage appliances-- very likely network based storage. We're going to want
operating systems that run on those servers. It's very likely we're going to have some virtualization
services, perhaps from VMware or Microsoft, that are running in our data center.
00:06:03
And the cost for bringing up our own data center is pretty significant. So in that same meeting, what
you and I could say is, hey, why don't we consider purchasing infrastructure as a service. And so our
boss turns to us and says, what do you mean, infrastructure as a service.
00:06:20
And what we could say is-- we could say, well there's companies out there like Amazon and
Microsoft that offer some pretty amazing infrastructure services. We can have the number of CPUs
and RAM and memory and operating systems that we want. But we don't have to physically hosts
it.
00:06:36
We can actually purchase the services of those systems from a provider, in the cloud, who is selling
us the service of that infrastructure. So for example, instead of having the hardware here at our
physical location, we could just purchase those services as Infrastructure as a Service.
00:06:52

So the case of AWS, which is Amazon Web Services, you could sign on and say, you know what, I
need 15 Windows 2012 servers with this much memory and this much CPU. And I need this much
storage. And with a few clicks, poof, it's there. Ready to go. So with Infrastructure as a Service, it's
very similar to having our own data center but having it provided for us via the cloud instead of
having that physical infrastructure at our location.
00:07:20
And one of the really cool things I like about Infrastructure as a Service is that it's a pay as you go
model. For example, if we need a whole bunch more CPU right away, we can pay for the additional
CPU and later, if we don't need it, we can scale it back very dynamically.
00:07:34
And we can manage all that through the interface that our provider has given to us. In the case of a
AWS, it's really, really cool. And Azure from Microsoft and other vendors also have their solutions,
as well. If we have cloud-based services that are available to the general public, for example, over
the internet like Google Apps, that's an example of public cloud services.
00:07:57
If there are cloud services set up for a specific organization-- not open to the general public-- that
would be example of private cloud services. Community cloud services could be consumed by, for
example, multiple organizations. But those services are specific to an interest or an idea or a
concept that is common to all of those organizations.
00:08:16
For example, security is a huge topic that a lot of organizations are concerned with. So if there are
some community cloud services that could coordinate and identify malicious attacks that are
happening all over the globe, organizations like Cisco and Palo Alto and Checkpoint could be
consumers of those cloud services regarding the insecurity attacks that are happening.
00:08:38
And it's very likely that each of these organizations are big enough, on their own, to go ahead and
get their own data without joining a common community. So this can serve as an example of three
different organizations who are consuming resources-- cloud services-- because they all have a
common interest in those services.
00:08:55
In this example, it would be information regarding security and real time attacks that may be
happening around the globe. And these organizations, absolutely, want to know about those the
moment they happen. And hybrid cloud services-- very similar to a hybrid car, have multiple inputs.
00:09:12
It could be the combination, for example, of public and private and community cloud services
which could be from different providers. So maybe we have Provider A doing the public cloud,
Provider B doing the private cloud, Provider C doing the community cloud, and a hybrid might take
aspects from each of those providers and their cloud services for a group of consumers, which could

be individuals or corporations, who are interested in specific aspects from each of those cloud
services.
00:09:38
In this Nugget, we've taken a look at how we can outsource our applications, development
platforms, and even our infrastructure by leveraging cloud-based services. 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.
Using a Baseline
00:00:00
How do we know if 38% utilization OF some resource is acceptable or too high? The answer is
we'd want to compare that against a baseline. And in creating a baseline, we're going to need to
collect information regarding what normal looks like from our monitoring and reporting tools.
00:00:17
In this Nugget, we're going to review several of those tools that we can use in creating a baseline. I
remember being told a story about a man who had some shoulder surgery done, and he asked the
doctor, hey, doc, after my shoulder heals, will I be able to play the piano? And the doctor said,
absolutely, yes.
00:00:35
You should have full functionality. And the guy says, great! I always wanted to play the piano. One
of the important things about working with our networks that we support, and manage, and monitor
is to make sure that we understand what normal looks like. For example, if somebody comes and
says, hey, the network utilization is at 62%, is that a problem? It depends.
00:00:57
It depends on what the baseline or what normal looks like on your network. And there's lots of
monitoring tools that we can use to create a baseline. For example, we could use protocol analyzers
to look at the traffic that's flowing across our networks. We could use tools like Netflow to collect
statistics and information regarding the protocols that are being used and the top talkers on our
network.
00:01:18
And those tools can also generate graphical reports so that you and I can see what's actually
happening on our network and create a baseline. Now, the concept of a baseline also can apply to
our configurations. For example, every new machine that we deploy on our network may get a
certain set of configurations.
00:01:36
And that could be our baseline for our configuration. So depending on the context for the word
baseline, it could refer to either the normal operating functionality of our network and the quantity
of traffic, or it could refer to our standard procedure for a basic set of configurations on a device.
00:01:51

And one of the benefits of having a baseline and collecting information regarding how our network
is performing is that we can start identifying bottlenecks before they become a real problem for our
users and for the applications that our network is there to support.
00:02:05
So for example, this could be a baseline for an application, or for a network traffic, or for CPU
utilization, or memory utilization. The concept applies to all those. And what we would do, by
gathering information through tools like Netflow, and protocol analyzers, and packet sniffers, and
other monitoring tools is we could find out what the normal looks like.
00:02:26
So for example, this green area represents what the normal traffic is. The blue line represents what
we're currently experiencing. And then if the current activity gets into the yellow or into the red, we
could have alerts that are being sent to us indicating, hey, warning, Will Robinson.
00:02:42
There might be a potential problem or issue here. So it's important to make sure we know what our
baselines are on our network. Another huge benefit of a baseline is a really good before and after
picture. For example, let's say you and I are going to deploy a new update, or a new driver, or a new
version of software on a networking device.
00:02:59
Before we deploy that in production, what are we going to do? We're going to test it. We're going to
test it in a test environment first and make sure that all the security issues and performance issues
are taken care of so we don't introduce problems onto our production network, because we want to
practice everything first.
00:03:16
So we would create a baseline of our test environment before we implement the update. And then
once the update, or the patch, or the upgrade is applied in our test environment, we can go ahead
and take a look at our utilization again and compare what's happening now against our baseline
before the update.
00:03:32
So the process would be, you have something new. You check your existing baseline. You apply the
new update to your test environment, check the baseline again to see what impact that change had in
your test environment. And then after all the security concerns and performance issues have been
addressed, you can then begin to roll that out as part of your production system, using proper
change control.
00:03:54
So by having the appropriate tools in place, like protocol analyzers, Netflow, SNMP that can
generate alerts based on excessive usage, we can start to identify when a bottleneck occurs and then
jump on it before it becomes a huge problem. And when you think of bottleneck, I'd like you think
of a timer that has sand.

00:04:13
So the sand's up here. It's trying to pour down. This part right here is the bottleneck. And then in a
computing system, that bottle that could be memory. It could be CPU. It could be network
communications. It could be storage communications. Basically, we're talking about the weakest
link or the slowest link in a chain.
00:04:29
And oftentimes, when we think of bottleneck and the concept of networking, we're talking about
bottlenecks in network communications across the network, for example, across a slower wide area
network, at which point we would start using quality of service in traffic shaping so that that slow
link in our network doesn't negatively impact our real time applications like voice and video.
00:04:49
Now regarding the information we do collect from our various systems, whether it's SNMP, or
syslog, or from our Netflow, we want to make sure that those logs are kept safe. And I've got two
thoughts about log management. Number one, we don't want to give the administrators the ability to
delete or manipulate those logs.
00:05:07
Because if it's tracking all the activity on the network, and there's some kind of misbehavior going
on by an administrator, we want to collect that and have that as a record that can be looked at for the
purposes of auditing. And secondly, we also want to make sure the information is available as a
read-only aspect so that the administrators can see what's going on.
00:05:25
So it's kind of like a double-edged sword. They need access to see what's happening. But they also
need to make sure they can't delete that data. And as we've mentioned before, that information we
collect can be produced into reports and into graphs with the intention that we can see the
information that's important to us.
00:05:41
For example, we can see the trend of bottlenecks happening. Or we can see the fact that there's a ton
of this certain type of traffic, which normally isn't on our network, which may be indicative of
perhaps an attack that's happening on our network or some other non-authorized activity.
00:05:56
And regarding utilization, it would be a great idea if we could have some method of gathering
information regarding bandwidth storage, network device CPU utilization, network device memory
usage, and if we have Wi-Fi, also wireless channel utilization. How saturated and how busy are our
wireless networks? And what I thought would be fun is, as far as utilization goes, I'd like to share
with you a virtualization tool.
00:06:20
This one's from VMware. And inside of a virtualized environment, we could have several or

thousands of virtual devices-- for example, Linux, and Windows, and virtualized appliances-- all of
them running as virtual machines inside of a bigger computing platform.
00:06:36
So what we're looking at right here is VMware's vSphere Web Client. And I am currently
highlighted on a single virtual machine running in this virtualized environment. And with that
selected, I've grabbed the Monitor tab, the Performance sub tab, and I've clicked on Advanced.
00:06:51
And here it's showing us the CPU utilization for that specific virtual machine. And if we wanted to
take a look at other details we've got in that virtual machine, we could take a look at the data store,
disk memory, network, and power. So if we looked at memory, for example, here it's showing us a
real time report regarding the memory that that virtual machine is using.
00:07:10
So the graph is up here, and then the decode is down here. In this Nugget, we've reviewed a few of
our monitoring and tracking performance tools that we can use to create a baseline and then
leverage that baseline to do a before and after picture, as well as get alerts in the event that
utilization or additional resources are going above our normal baselines.
00:07:29
I have had a great time in this Nugget. If you want more information after you finish your Network
Plus, if you want more training regarding VMware and virtualization, I would have start with the
VMware VCA and then the VMware VCP, which are both available right here at CBT Nuggets.
Configuration Managment
00:00:00
In this Nugget, we're going to discuss configuration management. Let's begin. I learned very early
in my career in computers/ networking that there's really only two types of users-- people who have
lost data that was meaningful to them, and it's painful, and the second group is people who will, at
some point, lose important data.
00:00:21
And one set of data that we want to make sure that we don't completely lose is our configuration
information for our networking devices. Whether it's workstations, servers, routers, or switches, we
want to make sure we have backups of those configs if those systems are critical.
00:00:36
And there's lots of creative solutions for doing archives and backups of our configs and of complete
disks at times. And the big question is, if we lose something, for example, let's say that router two
just goes belly up, and we have to replace it with new physical hardware, how quickly could we
restore the configuration to make the new router two-- the new one we put in-- functional and have
it work, including network address translation, its serial connection up to the branch office, and
everything else today has to do? And if it takes several hours to get that guy up and running, that

could be a huge impact on the business, because they would have no access between the corporate
location and the branch office and also no communication between the corporate office and the
internet.
00:01:20
And that's often why, from a network perspective, we'll often have fault tolerance. For example, if
you use two routers, whether you use router two and router six, and we use a technology like HSRP,
that we've discussed previously, or VRRP, and that way we don't have a single point of failure.
00:01:37
So if either R6 or R2 fails, the other router can still carry the load. We've already discussed the
concept of baselines in a previous Nugget. And what should happen if we do lose router two, and
we have to physically replace it, the performance will be, hopefully, very similar to the previous
router that was in its place.
00:01:55
And we can compare that, once again, by using our baselines. Now a big topic today in most
networks is the concept of BYOD, and that stands for Bring Your Own Device. And companies
have various stances based on their policies regarding it. So let's say you and I work at a company
where we are allowing people to bring their own devices into the network.
00:02:19
Now, do we want to just allow anybody to connect, and the answer is probably not. We want to have
some serious authentication to verify who that user is before we have them come in, and we also
may want to have some specialized software running on their mobile device, or we might want to
set up our access point to only specifically allow certain MAC addresses to be allowed to connect to
the network.
00:02:41
So as part of a coordinated effort, we may have an on-boarding and off-boarding process for mobile
devices, including mobile devices that are owned by the users at our company. And it may go
something like this-- Bob comes into the office. He has a brand new the iPad Air 2 too and says, I
want to get network access via my iPad Air.
00:02:59
Now, one option we could do is just say, hey, Bob, let's go ahead and not have you use that for the
corporate network. But if you want internet access, we have a separate, completely isolated guest
network that you can use for just internet access. And then, we don't really have to worry about an
on-boarding process, because the guest network, the wireless guest network, is completely isolated
from our production network.
00:03:21
However, if Bob says, nope, I really need it to access corporate resources on the corporate network.
At that point, part of the on-boarding process might be, for example, finding out what is the Layer 2
MAC address on his wireless card built into his iPad and then adding that to an access control list as

part of our wireless system.

00:03:41
In addition, we could also set up some software on Bob's iPad. So there's lots of options in adding
additional components and pieces to mobile devices, including iPads, androids, et cetera. And then
after we have the on-boarding process, we also might have some additional documents to give to
him to sign, indicating that he agrees to the policy regarding that mobile device and any sensitive
data and also make him aware that it's really important that he protects any data-- company data-on that the iPad, regardless of where that iPad is.
00:04:12
So that could be part of our on-boarding process. And then, two months later, when Bob decides
he's not going to use his iPad at work anymore, we would also have an off-boarding process as well,
which would remove the software that we placed on his iPad or his mobile device.
00:04:25
We would also remove the access control list entry that permitted his layer 2 address to get access to
the wireless network. And these processes, the on-boarding and off-boarding, are really important.
Because if we just on-board a whole bunch of mobile devices and forget about them, we now have a
whole bunch of additional possible access methods into our network that leave us more open for an
attack or abuse.
00:04:47
And we can avoid a lot of that by having an off-boarding process to make sure we clean up after
ourselves for mobile devices that no longer need access to our network. Another cool thing that we
can do for our computers that are accessing the network is require some type of an antivirus or antimalware software to be running on those devices.
00:05:07
And one of the challenges is this; how do we guarantee, or how do we check to see whether or not
computer one or computer two has the correct software in place? Or how do we check to see if they
have a firewall in place? And Windows has a built-in firewall, and there's third-party firewalls as
well, and that might be another thing we want to check to make sure that antivirus or anti-malware
and a firewall are all running in software on a computer before we allow it to connect to our
network.
00:05:33
Now, here's the challenge; how in the world do we verify whether or not a computer has those
required elements? And one option is to use NAC. And NAC is an acronym that stands for Network
Admission Control. And it generally works like this; we'll install some little agent on a computer.
00:05:51
It's not very big. It's fairly small, and it can either be resident-- it runs on the computer all the time-or when the user connects we basically run the software at that moment. And what the agent can do
is the agent can go ahead and check on that computer it's running on to find out whether or not the

required elements are in place.

00:06:09
For example, is there an anti-virus running? Has it been updated within x-number of days? Is there a
personal firewall running on that computer? And the agent's going through looking for those
requirements that we've specified in our policy. So that adds on another layer of security.
00:06:25
We're now checking to make sure the computer that this connecting is up to snuff, as well as the
user is authenticating on top of that. It's also really important to have very quick and accurate access
to documentation, including network diagrams, both the physical cabling plant, as well as how the
network is logically laid out.
00:06:44
We would want documentation regarding asset management. For example, let's say that Bob is
given a mobile device from the company. And when I say given, I mean it's hand it over to Bob for
Bob to use, such as a laptop or a mobile device. We would want to have documentation regarding
that asset and who it's been checked out to.
00:07:02
It's also not just the computer; it's the data that's on that hard drive or on that computer that is
probably the most sensitive and most valuable information that the company should be protecting.
We'd want to have documentation regarding your IP address utilization.
00:07:16
For example, if we have a subnet right here. We're using the 10.1.0.0 subnet with a 16-bit mask.
Because we have two octets for host addressing, it's very likely that we're never going to run out of
IP addresses, because we have two to the power of 16 possible hosts that we could place from an IP
addressing perspective on that subnet.
00:07:37
However, if we had a 10.9.0.0 subnet with a slash 28, now we only have four bits. So we have two
to the power four, which would be 16 minus two, because we can't use the broadcast address. We
can't use the network address. So we only have 14 available host addresses on this subnet. So we'd
want to be tracking that to make sure that if we start getting close to the edge of that and running
out, that we can properly address that and not have a network failure as a result of not enough IP
addresses being able to be handed out via DHCP.
00:08:10
Regarding vendor documentation, if this is a Cisco network or a Juniper network, we'd want to
make sure we have the documentation on the switches and on the routers that we're using. So if we
need to troubleshoot or verify, we could have access to that documentation for that purpose.
00:08:24
And we also, of course, want to have documentation regarding our policies, our standards, the

operating procedures. And every user, at least annually, should have to go ahead and sign an
agreement specifying that they understand what the policies are. They understand the rules
regarding network usage, regarding company and business purposes versus personal.
00:08:45
And some form of user awareness training should be occurring in our organizations at least
annually to make sure our users know what they should not do certain things, such as open
attachments that could cause harm to their computer or click on a link that's taking advantage of
their computer.
00:09:03
And in many companies, as well, we'll also some fairly tight controls regarding what the user is
technically able to do on their local computer. And that helps prevent the user from making changes
on their local computer that could lead to a security breach of some type.
00:09:20
In this Nugget, we've taken a look at some concepts regarding managing our configurations,
including backing them up, having access to documentation, and controlling what devices are
allowed to connect to our network based on the current configuration of those workstations that are
trying to connect.
Applying Updates and Patches
00:00:00
Is it possible to apply updates and patches without having a negative impact on our production
network? And the answer is, absolutely yes. Let's begin. One of my first recollections about really
being burned, and it was all my fault, was when I did an update of a network driver in a server.
00:00:18
Back in the day, in the '80s, it was Novell NetWare, which was the network operating system that
we used. And the driver update, I mean the brochure looked great. Better throughput, less hassle, so
what I did, is I updated the network driver. And the next day, under heavy load, that server went
belly up.
00:00:35
And it's very likely due to the network card driver that I had personally installed. And what I failed
to do is I failed to go through proper change control. Again this is back in the '80s, the wild frontier.
And today, with a little bit more wisdom and experience, I would have handled that quite
differently.
00:00:51
So for example, with a driver update, what I should have done, and what I would do now, is I would
apply that driver update in a test environment on gear in that test lab, and then benchmark it there,
to make sure that it would perform well. The other thing that you and I would want to do before we
ever deploy a new driver in a production system is to make sure we go through proper change

control, which can help us verify that we've done proper testing and verification, we've
communicated with the users of the network system regarding this update.
00:01:20
It's very likely have a change window, which is an advertised period of time when the network may
be down for this update. And we'd also want to make sure we had a backup copy of the original
driver, so that if we needed to, we could roll back to that previous driver and have at least the
functionality we had before the update was made.
00:01:38
So updates come in all kinds of flavors. We might have operating system updates, this could apply
to the operating system on a computer, or the operating system on a router, or the operating system
on a switch. And again, any time we do an update of any type on a system, we want to do that in a
test environment first to validate it, make sure we understand all the ramifications of that update
before we roll it out into production.
00:02:01
A firmware update, firmware's just simply software that resides on chips on a computer, for
example, a computer or a switch or a router may have a version of firmware that needs to be
updated. Maybe the new update has some new security features that we need to take advantage of.
00:02:15
So once again, before we roll that out into a production environment, we'd want to test it and verify
it first in our test environment. And there's lots of reasons for doing updates. There could be a new
feature that we want, or there could be a security flaw, or a vulnerability that's being corrected, and
that's why we're doing the update.
00:02:29
I would also strongly recommend that in production, if there is no real solid reason, no business
reason for doing the update, perhaps you don't do the update. That's also a possibility that we may
want to consider. The network's functioning, it's working, there's no security problem, the vendor's
currently supporting our version of the software.
00:02:50
We may want to consider leaving it as it is. Now many times before we do an upgrade, whether it's
firmware, or a driver, or an operating system, many time there's the opportunity to do a
configuration back up that we would definitely want to do beforehand.
00:03:04
And also, we'd want to verify that we can really restore from that backup up if we need to, in case
things go terribly, horribly wrong. So the upgrade would be going to the new version of the
software or firmware. And the downgrade would be going back from the newly updated software
that isn't working correctly, or has an issue or problem and reverting back down to the original
version.

00:03:27
That's what a downgrade is all about. And it's a great practice before we do any kind of change on
the network to have a backup of all the details, the configuration, the operating system, everything
we need in the event we need to revert back to that original state.
00:03:41
One of the cool features that Microsoft offers in many of their operating systems is called the Last
Known Good. And this can come in very handy. For example, let's say that we've just installed a
driver and the system is not behaving correctly, or it's not operating correctly.
00:03:56
Now there's a couple things we could do at that point. We could roll back just the driver and go back
to the original driver before the problems cropped up. Or we could go ahead and reboot the
computer back to the Last Known Good. Now that's a little bit more impactful than just rolling back
the driver, because the Last Known Good is going to boot to the settings, the drivers, and the
registry settings, based on the last time the computer booted successfully.
00:04:18
So if we'd gotten really industrious, and we had changed four or five of the drivers for different
elements of the computer, and then we go back to the Last Known Good, it's going to revert back
and none of those updates that we'd just applied would be there anymore.
00:04:31
So ideally, we'd roll back the individual driver that was having the problem, and if that didn't work,
or if the computer wouldn't boot correctly, then we could go back to the Last Known Good. And the
Last Known Good does not wipe out your entire hard drive.
00:04:42
It's just these settings regarding drivers and registry, that's what's being reverted back to the last time
the computer booted successfully. There's also some very cool options in Windows to create a
restore point. And the benefit of creating restore points is that at some future time, if something gets
out of whack, we could revert back to a restore point and have the functionality we did at that point
in time.
00:05:04
In this Nugget, we've identified that there are several different opportunities we may have for
updates. Maybe the operating system or firmware or drivers, and the key element about doing any
type of an update is to do it in a test environment first to validate that it's going to work correctly.
00:05:18
We'd want to have a backup configuration for the device that we're about to upgrade in the
production network. And then third, using change control and proper notification, we would then
apply the changes to our production systems and document those changes.
Managing Risk

00:00:00
In this Nugget, you and I are going to discuss several concepts related to the idea of risk. Let's
begin. There's a saying in business, and that is, risk happens. Risk is unavoidable in most
businesses. But we do have some choices of how we deal with it. We can either accept that risk.
00:00:18
We can try to reduce it to manageable levels. Or we can transfer that risk. For example, if I'm going
to buy a house, and I'm borrowing the money for that house, I'm required by the lender to buy
hazard insurance so that if the building burns to the ground, at least the insurance will repay the
loan so they don't have that risk.
00:00:37
Now regarding business, if there's some kind of a natural disaster, for example, an earthquake, a
tsunami, or something else that takes out the entire business, disaster recovery and an associated
DRP, a Disaster Recovery Plan, which should have been planned for ahead of time, should kick into
gear so that we can recover from that disaster.
00:00:57
And it starts here with preparing. So we'd identify what could possibly go wrong. We would plan on
how we're going to respond to it. For example, maybe we have two data centers, one in Las Vegas,
one in another part of the country, so that if there's a disaster in one part of the country like an
earthquake or a flood, or something like that, the alternate location can be used for our data
processing.
00:01:17
So usually, the better our planning is, the better the response is going to be towards that recovery.
And a big part of that, also, is the mitigation, which is identifying risks and then taking measurable
steps to reduce that risk. For example, if we think that attackers might be trying to steal our data, we
might want to put in mitigation techniques such as firewalls and other security measures in the
hopes that we can prevent, or at least reduce that risk from occurring.
00:01:40
And one of the very first steps of any disaster recovery plan is going to be how do we protect
human life? So in our companies, we're going to have evacuation plans, very likely a fire drill now
and then, and user training to make sure that everybody knows exactly what to do in the event of an
emergency to protect themselves and their coworkers.
00:01:59
And then, once the disaster recovery plan has been put into place and it's been activated, companies
are also likely going to have a Business Continuity Plan as well, a BCP. And the Business
Continuity Plan is, how do we stay in business? For example, for a politician, the number one job of
a politician is to do what? Is to get elected.
00:02:19

The second major objective of a politician is to stay elected or get reelected. And in business,
business continuity is all about maintaining the business after a disaster has happened. How do we
get back in the swing of things, and keep on serving our customers and providing our services to
continue to generate that stream of revenue that's so important for a business to stay in business.
00:02:41
And a really important part of the planning steps for helping to keep a business up and running and
protected is to identify any single points of failures regarding critical nodes, critical assets, and then
making sure that we have redundancy for those. For example, in the network, we can use hot
standby router protocol, and we can have two routers as a default gateway for a specific subnet.
00:03:03
And that way, if one of the routers fails, the other one can take over and continue to provide that
forwarding function. Or if we have critical servers, we can have multiple servers providing that
functionality. And we can either load balance across the multiple servers, or we might use some
techniques with virtualization, such as high availability and fault tolerance for virtual servers.
00:03:23
We also want to avoid a failure of our networks and systems due to a lack of power. So we've
already discussed in these Nuggets the concept of battery backups and uninterruptable power
supplies. So for longer time periods, we'd have a generator that would kick in to supply the power.
00:03:38
Our employee should know who the first responders are. For example, in an organization, we might
have individual people who have been trained for certain responsibilities in the event a disaster
recovery plan has been initiated by the company. They would have practiced their drills and know
exactly what to do, who to report to once that disaster recovery plan has been kicked into gear.
00:03:57
Now not every risk is going to be due to some kind of a large calamity. We also might have a
security risk, a security breach that could be leaking information. For example, a company that has
a big logo that looks like a target, a couple of Decembers ago, were attacked.
00:04:12
And they had a data breach where ttens of thousands of customers who shopped at that
establishment had their credit card information stolen by the attackers. So on the back end, we need
to proper technical controls to watch for that. And we also want to make sure we have proper end
user awareness and training.
00:04:29
For example, if you see something, say something. Everybody should know exactly what to do in
the event that they see something suspicious either in a co-worker or an email, or some other
communication or action is taking place. If the end user is pondering over the question, gee, I
wonder what I should do in this situation, that could be a telltale sign that we need more training,
and user awareness training, for that individual.

00:04:53
And to help enforce that, we want to make sure that every user has seen and read the company
policies that apply to them, and that they've agreed to that. And having that renewed or reviewed
every single year and signed is not a bad idea. And that way, as new security threats come up and
new training is available, it can help refresh in the mind of every single employee their
responsibility for data security as well as asset security within their company.
00:05:20
And in other Nuggets, we have already brought up the topic of vulnerability scanning and
penetration testing. And in the concept of risk, here's why they're important. For example, we know
that TCP Port 80 is the well-known port for web services. And maybe we have a policy in our
company that no computers, end user computers, should be running any type of a web service.
00:05:40
So what we could do is we could go ahead and use a port scanner like EndMap or ZenMap that
we've talked about earlier in this course. And we could do a vulnerability scan against our network
looking for those open ports. And then if we find TCP Port 80 that's open, we could take further
steps to make sure that it's locked down, because we would want to make sure that that host is not
listening on Port 80 and welcoming in HTTP connections.
00:06:05
And perhaps, in our environment, if we have a critical server that we've identified, perhaps we put a
firewall in front of it so the world, or the rest of the network, can access the server through the
firewall. And maybe the firewall's only allowing specific types of protocols and ports through the
firewall to the server.
00:06:22
And this would be an example of reducing risk by implementing some additional security between
the users who want access to the server and the server itself. And then once we think we're secure,
what we could do is verify that we are secure. And one way of doing that is with penetration testing.
00:06:39
And we could do that internally, or we could hire an outside firm to do that for us. And penetration
testing, the goal of it would be to verify that we have reduced our risk. If the penetration testing
team is successfully able to compromise a server, or get information that they shouldn't have, or
bring it down, that would imply that we haven't done quite as good a job as we should have in
reducing our risk regarding that asset, in this case, that asset being the server and the data on that
server.
00:07:07
In this Nugget, we've taken a look at some concepts regarding risk and the fact that we can mitigate
that risk by having fault tolerance, and business plans regarding disaster recovery and business
continuity. 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.

Denial of Service Attacks

00:00:00
In this Nugget, we're going to take a look at examples of denial-of-service attacks, which can be
implemented against networks and systems. Let's begin. I'd like to chat with you for a moment
about what a denial-of-service attack feel like from an end user perspective, so let's take an end user
out here on the internet.
00:00:16
Let's say we have Larry, and Larry is accessing one of our web servers. And so he opens up his
browser, he puts in the URL, and nothing happens. There's no response from our web servers, so he
does it again. He tries a second browser. If he knows a little bit about networking, maybe he tests
DNS.
00:00:33
He uses maybe nslookup to verify that name resolution is working. And if he confirms that name
resolution is working but yet he still can't access these servers, that, my friends, is what a DoS feels
like to the end users. It's when a service on the network should be available but it isn't due to some
kind of an attack.
00:00:52
Specifically, a denial-of-service attack, which is done to either interrupt or completely bring down a
service. Now, I want to make it really clear for both of us that it is never OK to participate in or to
initiate a denial-of-service attack against a system or network unless it's our own network and we
have explicit permission from the powers that be on our own network to go ahead and try or attempt
a denial of service attack.
00:01:19
Now, there are dozens and dozens of ways to implement a denial-of-service attack. For example, if
you and I can get physical access to a server, or to a switch, or to a router, how hard would it be to
remove power? And the answer is, pretty easy. And if we remove power-- poof.
00:01:35
We've just disabled the service that device was providing, whether it was a switch, or a router, or a
server. So physical security is an important aspect in helping to protect our networks and servers in
our infrastructure, and denial-of-services can be done by taking advantage of some vulnerability.
00:01:49
For example, if this is a certain flavor of a server that isn't patched yet, and there's a known
vulnerability, and we take advantage of that vulnerability by sending a certain string of commands,
or a certain URL, or a certain request to that server that takes advantage of that vulnerability and
causes that server to stop functioning, that would be an example of a denial-of-service attack.
00:02:09
But many times, a denial-of-service attack is done in a coordinated effort, and when we have

multiple systems that are all joining together at the same time to be part of a denial-of-service
attack, they call it a distributed denial-of-service attack. And you might wonder, well, how would an
attacker get access to, for example, 10,000 computers to participate in a coordinated denial-ofservice attack? And the answer is, end users.
00:02:34
Let's say, for example, an attacker is looking to build a botnet, a network of machines that will all
act when the attacker tells them to act. So for example, we have the attacker at the top, and then he
may have a few key systems that are then controlling other systems.
00:02:50
And these could be our 10,000 botnet devices, and all they are is computers. And normally, most of
these devices are going to be fairly high speed. For example, our computers from our homes and
from colleges with high speed connections courtesy of DSL and cable modem.
00:03:04
And the users at these computers at some point clicked on a URL, or installed software that they
shouldn't have, and behind the scenes there was some little piece of malicious software that now is
periodically checking in with the control system. And whenever the attacker now wants to launch a
distributed denial-of-service attack, he gives those marching orders to his first layer machines, and
then they subsequently communicate that to all the individual computers that are part of the botnet.
00:03:31
So your mom's computer, assuming she's connected to the internet, if she's got this botnet agent
installed and the attacker gives the signal, her computer, unknown to her, is going to be participating
in launching the attack. So a botnet is one method of implementing a distributed denial-of-service
attack against a system.
00:03:49
And because it may take a while to build a fairly good sized botnet, an attacker may lease a botnet
from another attacker and then use it. Now, of course all of those activities regarding a botnet would
be extremely illegal, and you and I would want to have no part or participation in any of that
knowingly, but think about what we could do if we had 10,000 computers. If we wanted to cause a
denial-of-service attack against this company, Acme Incorporated, and we knew what their IP
addresses were, what we could do is we could have these 10,000 devices all send traffic at the same
time to those IP addresses that are associated with this company.
00:04:26
And because, in this scenario, all of that traffic coming in through the internet is going over this link
from the service provider to the router, it's very likely that we can spike the traffic. And as a result,
we could have saturation, which would cause denial-of-service for the real user, like Larry, who's
trying to access a web server at that company.
00:04:44
That spike in traffic is also going to be a hardship for the users internal to this company to get out to

the internet due to the saturation on this link. And that would be an example of a coordinated attack
using lots of different machines to participate in the distributed denial-of-service attack.
00:05:00
Now, if an attacker doesn't have a botnet and they still want to cause some denial-of-service based
on the flooding or the overwhelming of traffic, it can leverage protocols that are already in use. For
example, DNS. What does that do? Well, DNS is domain name system.
00:05:14
It resolves names, like cbtnuggets.com, to an IP address. So Bob the user makes a DNS request and
gets a DNS response so that Bob's computer can learn the IP address associated with the URL that
he's trying to reach. However, what if an attacker on the internet, either by himself or with a botnet,
did a DNS request up to a DNS server but he spoofed the source IP address? So let's say this IP
address that this router 2 is using is 23.1.2.5, just as an example. So if the attacker sends a DNS
request but uses the source IP address, 23.1.2.5, the response from the DNS server is going to go
back to router 2. So the attackers sending DNS requests and getting responses sent back to
23.1.2.5-- that probably all by himself wouldn't really cause a huge disruption of service because it's
just one device.
00:06:07
However, if the attacker leveraged a botnet and sent, for example, 10,000 DNS requests up to the
DNS servers on the internet and all the replies are coming back to router 2's address, that could
cause problems. Including traffic problems on this link, as well as this router who has to deencapsulate and is trying to process all these packets, just to realize, hey, this is a UDP packet layer
four and I never requested this DNS information.
00:06:33
I'm going to discard it. However, router 2, because this is the IP address he's supporting, has to go
ahead and process and de-encapsulate all the way up to transport layer, every single one of those
packets. And that could cause a DoS, denial-of-service, on the router itself because it's using all of
its processing power de-encapsulating all those packets, and it doesn't have enough CPU cycles left
to process all the other normal traffic.
00:06:55
We can also play that fun game with NTP, network time protocol. It uses UDP Port 123. And with
network time protocol a device, for example a router, can make an NTP request out to an NTP
server. It gets a response back, and it's not really too big of a deal.
00:07:11
However, if we have a botnet, for example, of 10,000 devices and each is consistently sending over,
and over, and over again NTP requests with a spoofed source address, the responses come back to
the 23.1.2.5 that, once again, could cause a disruption of service on router 2 because router 2, once
again, has to de-encapsulate all the way up to layer four just to see, hey, this is an NTP response.
00:07:34

I didn't request this, and it can discard it. However, if it has hundreds of thousands of these
responses to deal with, it's very likely we could cause a DoS on router 2 just from the NTP
responses coming back into router 2. Another type of reflective, or amplified, attack that's using a
third party as part of the attack is called Smurfing, and a Smurfing attack would go something like
this.
00:07:55
Let's say that router 2 is our target-- 23.1.2.5. So what the attacker can do is send out a ping request.
Now ping uses ICMP, the Internet Control Message Protocol, and in that ping it's actually a ping
request-- an echo request. And generally, if a device is supporting it, there'll be a ping response-- an
echo reply-- going back.
00:08:15
That's a great way to verify layer 3 connectivity from one point in the network to another. And
here's how the attacker could leverage that. The attacker could spoof the source address to make it
appear as if we're coming from 23.1.2.5. So when the ping goes out to a third party the response
would go back to 23.1.2.5, which, once again, would consume some bandwidth on this link between
R2 and the service provider. So router 2, seeing that it's destined to 23.1.2.5, would de-encapsulate
it, see that it's an ICMP echo reply.
00:08:47
R2 would say to itself, I never sent an ICMP echo request. I didn't expect this reply. It would
discard it, but it would still take up some CPU cycles and some bandwidth. Now, one single ping
isn't going to cause a big problem. However, what if the attacker could send that ping to a broadcast
address for a network? For example, let's say the attacker sends a ping to 41.1.2.255, and based on
the hacker's reconnaissance attacks and what he's discovered, he knows that there's a network of
45.1.2.0/24. So what the attacker has actually done is sent a ping request to a broadcast address.
00:09:23
So on that network a router, if it's not otherwise prepared to handle it differently, would then
forward that ping as a broadcast to all the devices on the 45.1.2.0 subnet. So now we could have, for
example, 254 possible devices on that subnet who all got a ping request and who are all now
responding, except they're not responding back to the attacker, they're going to respond back to the
source IP address where it appears that ping came from because the attackers spoofed that source
address as part of this Smurf attack.
00:09:56
And if you're wondering, oh, my goodness, what can be done to help protect against these types of
attacks? The answer is there's lots that could be done, and we'll save those for courses like the
Security+ and as we get into specific vendors, including Cisco, CCNA Security, Check Point, Palo
Alto, and other firewall and security products that can help us to mitigate or reduce the risk of these
types of attacks.
00:10:21
Now, sometimes a denial-of-service attack might be done unintentionally, which is referred to as a

friendly DoS, and that might be happening based on Bob. Bob has downloaded some tools. For
example, he downloaded maybe BackTrack or Kali Linux, which is an amazing Linux based
distribution of some really key and really effective attack tools.
00:10:44
In fact, if you have interest in Kali Linux or BackTrack and penetration testing tools, I would direct
you to this course here at CBT Nuggets called Penetration Testing with Linux Tools. So one of the
Nuggets, for example, is on how to implement a denial-of-service attack using yersinia.
00:11:03
Now, here's a really important warning for both of us to heed. In this course, the Penetration Testing
with Linux Tools right here at CBT Nuggets, I built this with the intention of making us aware of
these types of attacks which can happen. There is never a good or a legal reason to use these types
of attacks on other networks that are not your own where you do not have permission to implement
these attacks, but there's just a boatload on wireless, there's man-in-the-middle attacks, DHCP
starvation, CDP flooding, HSRP attacks, trunking, ARP attacks.
00:11:38
For example, an ARP, Address Resolution Protocol, on ethernet-- it's when we're trying to discover
the Layer 2 address of some other device on that same subnet, on that same VLAN. Well, if an
attacker is doing ARP spoofing, he's trying to poison the ARP caches of the other devices on that
network so that when they encapsulate at layer 2, instead of using the correct layer 2 address of the
server they're trying to reach, they're actually going to use the layer 2 address of the attacker's
machine.
00:12:04
And that way, all of those frames can be forwarded over to the attacker, and then the attacker has a
chance to analyze and look at that information, look at each of those frames, before forwarding that
traffic over to the final and real destination it was intended for.
00:12:17
And the list goes on with just tons and tons of various attack tools that are all included with the
distributions of BackTrack and or Kali Linux, which is the current flavor of the distribution that has
all of these tools. So if you have a curiosity about learning more about these attacks, this would be
the course you'd want to check out, and it's called Penetration Testing with Linux Tools right here at
CBT Nuggets.
00:12:39
And in that course, I also have the huge warnings as well regarding never using these attacks in
production against other systems or networks which are not your own for which you do not have
permission to run these attacks. And back to our point. That is how, for example, a user like Bob
might have implemented a denial-of-service attack against his own network because maybe he
wasn't clear on how the attack worked or whether or not it would be successful.
00:13:03

All he knows is he clicked a couple of buttons and all of a sudden the network is no longer
functioning. Not just for him but for possibly others as well. And then regarding physical denial-ofservice attacks, we talked about how if we have physical access to a device we could turn it off or
power it off to cause a denial-of-service.
00:13:20
However, there's also the potential for launching what's called a Permanent denial-of-service attack.
For example, our attacker, who is out here on the internet, if we've given public access to a web
server and the attacker figures out a way to embed inside the URL commands that will cause the
firmware on the computer to be changed-- that's the software in chips on this computer.
00:13:44
If the attacker can pull that off, this server, if it's no longer functional, a simple reboot is not going
to fix it because he's permanently changed the firmware. And that's going to be a lot longer for us to
get that server up and running if the firmware has been changed, or if there's been logical damage to
the circuits on that server.
00:14:02
That's another example of a permanent denial-of-service attack against that server. In this Nugget,
we've taken a look at the concept of a denial-of-service attack and some various methods that these
attacks maybe implemented. I'm glad you joined me for this Nugget.
Threats to Wireless
00:00:00
Wireless threats and vulnerabilities-- let's begin. I'd like you to imagine that you and I have just got
to work. We open up our laptops, we connect to the network, and then as we take a look at the
network shares that are available, they don't look right.
00:00:15
There are shares that we don't recognize and other shares, which normally are there, aren't. It's very
possible that our computer is connected to the incorrect wireless network. And if there's an attacker
or a rogue access point involved, it was very likely the intent of the attacker to get us to connect to
them.
00:00:31
One method an attacker could use to do that-- to get us to connect to their unauthorized or rogue
access point-- is to become an evil twin, which is made to look like a legitimate access point or a
legitimate wireless network, but in fact, is the attacker's wireless network.
00:00:47
And unfortunately, our computers remember wireless networks that we've connected to in the past.
So if we go to Starbucks or to McDonald's or somewhere else where they have an open, free Wi-Fi,
and we've connected to that wireless network in the past, that would be yet another method the
attacker could use to get our computer to connect to his wireless network-- by creating an access

point and, perhaps, advertising an SSID that matches one that we currently have in our list of
networks we've connected to before, in the hopes that our computer will automatically connect.
00:01:18
So an evil twin is an access point that's pretending to be legitimate. For example, you go to an
airport or to a coffee shop, you never really know if the access point you're connecting with and
using has been provided by the facility or if it's an attacker's.
00:01:32
And that's why it's not a great idea, especially on company equipment, to use public and free Wi-Fi.
So an evil twin is an example of somebody who has a rogue access point-- one that is not authorized
for that area-- who would like you and your computer to connect to that wireless network, based on
a wireless network you've connected to in the past, or having that new evil twin look very similar to
your corporate network.
00:01:54
Maybe the hacker has done a denial of service attack against the real access points and now has put
up his own access point as an evil twin. Another way that attackers can take advantage of our
networks is by doing something called a war driving. Now a long time ago, for example, with the
movie War Games, there was war dialing where you dial number after number after number,
actually your computer would, hoping to connect to another modem and then get access to that
system.
00:02:21
Well with war driving, we just assemble a few components. For example, we can get a GPS, an
antenna, a computer. And then what we can do is drive through neighborhoods and then identify the
various wireless networks that are there. And not only can we identify the SSIDs that are being
broadcast, but we can also identify what type of security they're using.
00:02:40
It's also very likely we could identify the vendor. And an attacker who knows what he's doing is also
very likely to have all that automated. So the attacker just slowly drives through the neighborhood
and the software collects all that information, maps it out with the GPS, and at the end of the day,
the person doing the war driving now as a really good map, along with the Wi-Fi networks that
were present.
00:03:02
Now one of the vulnerabilities that we have-- if we have wireless networks in our homes or
businesses that are not secure, they're open, and an attacker discovers it, the next step the attacker
could take is to go back near the proximity of that wireless network and try to get access.
00:03:19
Now the process of war chalking is not quite as high tech as using a GPS and creating maps of
where the wireless networks are, but war chalking would involve, perhaps, using chalk and writing
on the physical buildings, or areas, where those Wi-Fi networks exist, with indicators regarding

open networks, closed networks, and what type of security is in use.

00:03:41
And I think that's the type of technology that Fred Flinstone may have used, back in the day, if he
was doing war driving. And that would be for the benefit of other people, for example, Barney
Rubble. So when Barney sees these symbols he can say, oh gee, there's an open wireless network
over here.
00:04:01
I don't think we're going to see a whole bunch of physical markings on the edges of buildings
anymore. Most of the information regarding the wireless networks is going to be digitized and
mapped out and created by people doing war driving. And it doesn't actually have to be in a car.
00:04:16
You could, for example, have a briefcase with all the gear in it-- with a battery. And you can put it
on the back of a bicycle and just pedal around the neighborhood collecting the information. Or if
you're in a part of the world that maybe isn't quite as technologically advanced, instead of war
driving, we could call it war trotting.
00:04:35
So there's his antenna. There's the computer. Here's the big monitor. So maybe this individual, after
several months of collecting information, could possibly sell that to other individuals or hackers
who want that information and then upgrade to a laptop.
00:04:50
A fantastic wireless technology that's been growing in popularity ever since it came out is
Bluetooth. And with Bluetooth, it could be taken advantage of. For example, let's say we're sitting
in the airport. We've got our mobile device. And all of a sudden there's information being fed into
our Bluetooth device-- maybe it's an advertisement or some other unsolicited information.
00:05:13
That's what bluejacking is all about. Bluejacking is pushing information to a Bluetooth device
which was not being expected or invited. On the other hand, bluesnarfing is when somebody has
connected via Bluetooth to your device, and they are stealing information.
00:05:29
So bluejacking is data going to your Bluetooth enabled device. And bluesnarfing is the theft of data
from your device via Bluetooth. And then regarding security for wireless networks, friends don't let
friends use WEP. That's one of the earliest and oldest and easiest to break security methods for
wireless.
00:05:50
When possible, we should be using WPA2, which is also known as 802.11i. We've talked about that
in an earlier Nugget. The personal mode is when we're using a pre-shared key. Or if we're suing
enterprise mode, it means we have a centralized server for authentication, such as a RADIUS server.

00:06:07
And one of the features to help people do security in wireless networks, especially for home
networks, is called WPS. And that stands for Wi-Fi Protected Set-up. Now one of the challenges
with wireless is that there are certain weaknesses and vulnerabilities in these technologies.
00:06:25
For example, with WEP there's just tons of them. And it's really, really easy to break. That's why
WPA, Wi-Fi Protected Access, was built as a better method for security. And also why WPA2 was
built as even a better method for security. There's also a PIN that's associated with the WPS that
could be compromised with a brute force attack by an attacker.
00:06:47
A brute force attack is when the attacker tries over and over and over and over again with different
combinations, attempting to discover what the password, or in case of WPS, what the PIN number
is. And when I think of a brute force attack, I think of a rain dance.
00:07:01
And a rain dance is done, as a ritual, in an attempt to get it to rain. And you know what? Rain
dances always work if you just keep on dancing until it rains. And a brute force attack is going to be
successful if we have enough time, and we keep on hammering and hammering and hammering
until we reach the magic combination of what that password or what that PIN is.
00:07:24
So some mitigation techniques, for example, would be to not enable WPS on our home routers. We
would not want to use WEP or WPA and only use WPA2 for security. And on top of that, we want to
use a passphrase with WPA2 that is longer than eight characters, upper and lowercase,
alphanumeric, special characters-- to make it very, very tough to be broken via brute force attacks.
Threats and Vulnerabilities
00:00:00
In this Nugget, we're going to take a look at some additional threats and network vulnerabilities that
are very commonly seen in networks today. An attacker who has some exploits that are taking
advantage of, or leveraging, a vulnerability-- what that boils down to is risk.
00:00:15
What is the likelihood of an attack being successful on our network? And unfortunately, many times
our companies are only as secure as our weakest link in the chain. So here we have this chain, and I
got a paper clip as a weak link. And attackers are normally going to go for the easiest method they
can to get access into the network.
00:00:35
So in this Nugget, let's chat about some of the threats and vulnerabilities that we might see in
networks today. The first on our list is a brute force attack. As an example of an attacker using a
brute force attack against a Cisco router, for example, let's say the password for access to this router

was Cisco123, which by the way, is a really bad password. Because an attacker can use a couple of
methods for attempting to login.
00:01:01
The attacker could use a dictionary attack, which has 11 billion different passphrases that are
commonly used on networks. And then the attacker tries to log in using each one of those, in order.
But another method, in case the dictionary attack didn't work, is a brute force attack, where we
simply try all the possible combinations one after the other.
00:01:21
So maybe on the 700,000 try, the attacker is able to discover the password is Cisco123 with a brute
force attack. Now there are several different ways we can help mitigate or reduce the risk of this
type of an attack. And we cover a lot of those mitigation techniques in some later Nuggets in this
course, regarding hardening our network devices.
00:01:41
And for further training, regarding reducing these risks, we have other courses like Security Plus or
for vendor specific courses like CCNA Security and Checkpoint and other courses here at CBG
Nuggets that are going to walk you through how to counteract many of these attacks.
00:01:56
The next our list is a session hijacking attack. Effectively, let's say that Bob is the administrator.
Bob has a session with this Cisco router. He's currently managing it. And the attacker, basically,
interrupts the session that Bob has with the router and steps in.
00:02:11
So the authentication has already been done, and the router doesn't realize it is now communicating
with a different device instead of the administrator, Bob. So the attacker has hijacked the existing
session. Social engineering is one of the easiest ways for an attacker to gain access.
00:02:28
Social engineering is all about tricking, or compromising, the user. For example, let's say we're a
big dog fan-- we love dogs. And we receive an email one day saying, oh, check out this really
awesome dog document. So it's a PDF. We double click on it, we open this attachment, and malware
has just been installed on our computer.
00:02:47
So the malware that's now running on-- let's go ahead and take Lois' computer-- that malware that's
running could be collecting keystrokes, like a key logger, and then sending that information out to
the attacker. What that means, unfortunately, is that when Lois logs in, we now have her username
and password.
00:03:04
As Lois authenticates or puts other passcodes to other areas of the network, if we're collecting all
those keystrokes and sending them out to the attacker, we're now collecting all that information.

Some malware may be introduced as a worm which has the ability to discover other systems on the
network and automatically propagate.
00:03:21
And so on this network, if we had a protocol analyzer that was running, and we were looking at the
traffic, if we had malware that was currently scanning and looking for other open ports, we would
see just a whole boatload of these scans happening, first of all from Lois' computer.
00:03:35
And then as other computers are infected, those other computers would also start doing scans
looking for yet additional victims on the network. And a good intrusion prevention system, if it was
in place, could identify that those scans were happening, send off alerts, and potentially stop the
scans from propagating through the network.
00:03:52
And it was all because of social engineering, an email, a compromised system-- in this example, it
was Lois' system that was compromised-- that caused the malware to start spreading in the network.
VLAN hopping is a technique that could allow an attacker to jump in on a different VLAN.
00:04:08
For example, let's say this port right here, which is an access port, that should be in VLAN 1, is
connecting Computer 2 to VLAN 1. However, if the hacker jumps on Computer 2 and runs some
software, the potential exists for Computer 2 to negotiate a trunk with this switchport.
00:04:26
Now in a perfect environment, we would have configured the switch not to allow the dynamic
negotiation of trunks. But by default, a lot of ports do allow that. So then the attacker, with access
via a trunk to the switch, now has access to all the VLANs that are on that switch.
00:04:43
So if the attacker wanted to be on VLAN 10 or VLAN 20, which normally would be secure-- now
that the attacker is directly on VLAN 20, by hopping VLANs, he or she, the attacker, has just
bypassed the security of access control lists that would have been on router interfaces that otherwise
would have prevented that traffic.
00:05:01
Now unfortunately, attacks can come from users that already have some access to the system. So for
example, if Bob is a disgruntled employee and he's frustrated and he's already connected to the
network, he could then perhaps launch additional attack tools and reconnaissance tools to learn
information and cause damage to the network-- or to possibly access data that he otherwise
shouldn't have access to.
00:05:26
So there is a concern and a level of trust that we should put in place for our users, but we really
should give our users just the ability, at the most, to do their jobs and not any additional access. We

could also have intrusion prevention systems in place on the network to help identify malicious
activity as it's happening.
00:05:45
There are a lot of companies that make the virus scanning software. And every computer should be
running some type of a virus scanning software and periodically keeping it up to date. However, a
virus scanning software is only going to match based on an existing type of virus or malware that's
been already identified.
00:06:04
And if there's something brand new that hasn't yet been identified by the antivirus company, and
that attack or that virus can take advantage of a system, that's referred to as a zero day attack. There
is no warning for a zero day attack. It's some kind of vulnerability that a system has that no one
really knows about yet except for the attack who just discovered it.
00:06:25
And those can be pretty tough to deal with. Now we also have some software that we can
implement on our host, for example, Host Based IPS, or HIPS-- sometimes is called HIDS for Host
Based Intrusion Detection System. And depending on the vendor, some of those will be able to go
through and identify what normal looks like.
00:06:44
What are the normal applications and memory calls and disc requests that a system is making? And
then if something goes out of the ordinary, it fires off the alerts and prevents that from happening.
We've talked, in other Nuggets, about doing vulnerability scans where the administrator will simply
scan the network looking for specific ports that are open, which otherwise shouldn't be.
00:07:04
For example, we'll pick on Bob again-- Bob, the user, on Computer 2, should not have FTP services
running. He shouldn't be an FTP server from his computer for two reasons. Number one, FTP is not
a secure protocol. And number two, Bob's computer shouldn't be acting as any type of a server.
00:07:22
Bob's computer should be acting as a client only. And in corporate environments, we're going to
have dedicated servers, or virtual servers, specifically for the purposes of sharing resources,
including file services. So if there are open ports, that usually indicates there is an open running
service behind it, and those would be vulnerabilities on our network.
00:07:41
Because an attacker could also do that scan, connect to the FTP service on that computer, and then
very likely get access to information that, otherwise, the attacker should not have access to. Another
challenge is that we may have older systems that, unfortunately, are forgotten about, or they simply
aren't updated with current patches.
00:07:59

For example, how often does Microsoft deliver some type of a patch that involves a security fix or a
security update? The answer is at least monthly, on average, and very likely more often that. So
that's why we would want to do our regular updates and patches.
00:08:15
And for servers and mission critical devices, we would always want to practice and verify those
patches and updates in a test environment first. And then after we verify that they're not going to
cause damage to our system, then with change control, we can implement those patches and updates
in the production network.
00:08:33
And if we do have legacy systems which have some open services imports, and we can't do much
about it, we can at least isolate those networks from our more current networks. And that way, by
limiting access to the legacy system, we're also limiting the impact of an attacker using some type
of an exploit against vulnerabilities on that legacy system.
00:08:53
An unencrypted channel is simply referring to communications that happen over a network where
there's no secrecy involved. There's no confidentiality. And effectively, all these protocols right here
are considered insecure, or unsecure, because they are sent in clear text.
00:09:09
And that means an attacker, if he's eavesdropping on a network-- or maybe the attacker is doing an
ARP poisoning attack so that every device thinks that the default gateway's Layer 2 address is the
attackers Layer 2 address. And so as everybody is sending traffic to the default gateway, or so they
think, the attacker is really receiving all those frames.
00:09:27
And if they're clear text, guess what? There's no secret about what's in those packets. Because the
attacker can read those, because they're not encrypted with any type of encryption algorithm. The
attacker also has the ability, at his computer, to forward those frames on to the real Layer 2 address
after he's had the chance to see them and/or manipulate those frames.
00:09:46
So that means if we're using any of these protocols-- Telnet, HTTP, SLIP, FTP, TFTP, as well as
SNMP that is less than SNMP version 3-- and we're supplying any type of credentials, guess what?
We've just supplied those in clear text. I went to a security conference here in Vegas.
00:10:05
They had this one booth, and it had just a wall of various IP addresses, the protocols in use, and
portions of the username and portions of the password. And they were blocking them because they
didn't want to be liable. And it was just so easy for this group at this booth to collect this
information, because all they did was they eavesdropped on the network traffic.
00:10:26

And anything that was clear text, anytime there was a username and password involved, because it
was also clear text, that information is now known by that group. It was just a warning system to
help remind people that using insecure and unsecure protocols, in conjunction with their usernames
and passwords, is a really, really bad idea.
00:10:46
And other protocols do have, for example, some encryption built in. For example, SSH, secure
shell, could be used instead of Telnet. So SSH uses TCP port 22. And it's not the actual port number
that makes it secure, it's the encryption algorithms that SSH incorporates that provides the
confidentiality.
00:11:06
So that way if the attacker does get the actual packets, the attacker will not be able to de-encode and
understand the payload of those packets, because they're encrypted. Instead of HTTP, we could use
HTTPS which uses TCP port 443. Again, it's not the actual port number, it's the way the protocol
operates that provides the encryption.
00:11:27
Another protocol-- Remote Desktop Protocol, RDP-- uses TCP port 3389. And RDP, when
implemented correctly, does have the ability to provide confidentiality. And RDP is an example of a
tool we could use for remote control of another system. For example, if Bob is sitting here and Bob
wants to take remote control of computer number one, computer number one could be running RDP
services.
00:11:51
And computer two could run an RDP client to connect and remotely take control of computer one.
And that's assuming that the operating system on computer one supports RDP, and that they have
connectivity, from an IP perspective, between the two computers. Now another challenge is that
access points, because they're wireless-- those signals could be picked up by devices that are close
to those access points.
00:12:15
So maybe somebody who's in the parking lot could pick up those signals from the wireless access
point. Or another office on the other side of a wall that's fairly close to an access point-- they could
also pick up those signals. And that's why we would also, on our wireless, want to make sure that
we're using encryption.
00:12:30
So if we're using WPA2, we're using AES encryption, which stands for Advanced Encryption
Standard, that provides that confidentiality for our wireless frames as they go over the wireless
network. Another very interesting fact is that even if we're using copper cabling, like unshielded
twisted pair, the data that's being sent back and forth over an unshielded twisted pair can be
retrieved.
00:12:52

And it's my understanding that some gear can actually be several yards away from that cabling and
still be able to pick up these signals that are being emanated from it. So if we had a network where
we want to make sure that nothing was leaking out, we could go ahead and use a tempest room, or a
tempest environment, which is designed to contain all of the signals.
00:13:14
So in a tempest room or a tempest area where we're concerned about any type of radio frequency
emanation, it's a lot like Vegas. What happens in Vegas, stays in Vegas. Regarding these signals,
nothing escapes. And that way, if no signals escape, the enemy or whoever the attacker is, won't be
able to pick up and receive those signals.
00:13:34
So it's very likely that even if we have a tempest environment, where we're containing everything,
we're still going to avoid using unsecure protocols. And instead of those unsecure protocols, we'll
use secure protocols which incorporate encryption, even in a tempest environment.
00:13:49
In this Nugget, we've taken a look at threats and vulnerabilities that we need to be aware could exist
in a network. If you'd like to take a closer look at some of the attack tools that could exploit known
vulnerabilities in networks today, I would invite you to check out our Penetration Testing With
Linux Tools course, which is right here at CBT Nuggets.
Switch Port Security
00:00:00
In this Nugget, we're going to take a look at some techniques that we can use on our switches to
help harden them, to make them more resistant against attacks. Let's begin. For devices that are
connecting to our network over unshielded twisted pair cabling, our first line of defense is the Layer
2 switch itself. And there's several cool things we can do regarding switchport security on that
switch.
00:00:21
So here we have Bob and here's Lois and here's an attacker. And you might ask, how in the world
did an attacker get access to our network? It's very likely that the attacker simply walked up to a
wall jack that was not being looked after, connected the network device in, and poof.
00:00:36
He's been given an IP address via DHCP and he is on the network. Now one of the things an
attacker could do who's connected to our network is the attacker could become the DHCP server. So
by being a DHCP server, when Bob's computer comes on the network and asks for an IP address,
the attacker could hand out IP address to Bob and also a default gateway.
00:00:57
But guess what default gateway Bob's going to be given? Bob could be given the default gateway of
the attacker's address. And then the attacker could forward the packet to the real default gateway

after the attacker has performed its man-in-the-middle attack.

00:01:10
Because now all of Bob's traffic that's trying to leave the network is now going through the attacker.
So one way of preventing this from happening is by using a process called DHCP snooping. With
DHCP snooping it's sort of like the Nancy Reagan policy on drugs many, many years ago.
00:01:26
And that policy was just say no, meaning that if any device on the network on any of these access
ports tries to send packets into the network that look like they're packets from a DHCP server-- for
example, we have the DORA. So the client packets would be the discover and the request and the
server packets I'll circle in green would be the offer and the acknowledgement.
00:01:49
Anytime a packet is being sent that's an offer or an acknowledgement and is using the associated
server ports associated with that DHCP, the switch port is simply going to say no. You cannot send
those into the network. I don't trust this port, says the switch with DHCP snooping as a port where a
DHCP server should be.
00:02:08
It's an untrusted port for DHCP. So that allows all the devices to become DHCP clients, but it
prevents any of those devices from being DHCP servers. And then what we can do is we can take a
switch port that is connected, for example, to a DHCP server, and we can simply tell the switch that
from a DHCP snooping perspective that this port is a trusted port and it's OK for DHCP server
packets to come into the network on this port because it's coming from our real DHCP server.
00:02:37
And that's what DHCP snooping is all about is protecting against a rogue and unauthorized device
acting as a DHCP server. ARP inspection is looking to make sure that nobody is lying about Layer 3
to Layer 2 mapping information. So that means if Bob is doing an ARP request, looking for his
default gateway, that the attacker won't be able to respond to that request and say, oh, yeah, that's
me.
00:03:01
In addition, if the attacker tries to lie or do ARP poisoning by doing something called a gratuitous
ARP with the incorrect Layer 3 to Layer 2 mapping. And so what happens is the switch could
actually dynamically learn the Layer 3 to Layer 2 mapping for the real device on this port.
00:03:18
And it learned that in most environments as a result of the DHCP snooping that we did earlier
because in addition, DHCP snooping besides stopping malicious DHCP servers from acting up on
the network, it's also allowing the switch to memorize the Layer 3 to Layer 2 mapping on each of
those ports in that VLAN.
00:03:36

So when the attacker tries to do anything tricky or illegal regarding ARP information, the switch
port says, nope. Not going to happen. I know that's not your Layer 2 address. I don't know why
you're trying to say that, but I'm not going to let that information bother anybody else on the
network because it's a lie.
00:03:52
And that prevents ARP spoofing, which also prevents an ARP man-in-the-middle attack. Another
technique we can use is Mac address filtering we could specify, for example, that only certain Mac
addresses are allowed as part of frames on the network. The switch is basically saying, I'm so sorry.
00:04:09
I'm not going to allow your frame onto the network because of the Mac address that you're trying to
use. So we can do filtering based on Mac addresses. So on a Layer 3 router, we might do filtering at
Layer 3 with IP addresses. And on the switch, we can do Layer 2 filtering based on Mac addresses.
00:04:26
Another very valuable security measure is the proper configuration of access ports. For example, if
we know that Bob and Lois are going to be connecting to these ports respectively, we could go
ahead and configure these ports as access ports, meaning they're not going to be trunk ports.
00:04:40
They're going to be supporting a single VLAN. And then we could assign them to a VLAN. For
example, VLAN 7. And while we're at it, we also might want to assign this printer to that same
VLAN. So the printer would be connected on an access port that is also assigned to VLAN 7. So
Bob, Lois, and the printer are all part of the same VLAN.
00:04:57
Then for ports that we aren't currently using. For example, ports that go out to a wall jack in an
office where there's no computing device connected to it yet. On a switch port, we want to take
those ports and assign them to some unused VLAN. Maybe we create VLAN 999 and we assign all
of the unused switch ports to that bogus VLAN 999 so that now when the attacker connects to the
network, he is going nowhere fast.
00:05:23
There's no DHCP services on VLAN 999. There's no default gateway. He's basically singing the
song, all by myself. Don't want to be in VLAN 999 all by myself anymore. And the other thing we'd
want to do too is configure this port as an access port and tell it not to be able to do dynamic trunk
negotiation because we don't want the attacker to negotiate a trunk, and then have access to all the
VLANs, including VLAN 7. So by correctly setting up the ports, we're setting up correct isolation
between networking devices, using the concept of VLANs for that isolation.
00:06:03
Now there's actually-- it's kind of funny. There's one other really cool benefit that a Cisco switch
brings to the table and other vendors do as well. But in Cisco, they literally call this feature port
security. And what port security allows us to do is to control the number of Mac addresses allowed

on a port.
00:06:22
So for example, if we were enabling port security on all these ports, and by default with port
security enabled, the maximum number of Mac addresses that the switch is able to learn and
associate with each of these ports respectively is just one. So Bob and Lois, as they connect and the
switch memorizes Bob's Mac address on this port and Lois' Mac address on this port, if Bob's Mac
address just somehow magically shows up on another port-- let's say it shows up over here, for
example, or perhaps on this port-- with port security, if the same Mac address shows up somewhere
else, the default behavior is to shut down the port.
00:07:02
And also with port security, the default behavior is that if more than one source Mac address is seen
on a port, the default is also to shut down the port. And there are other options that we can specify,
but that's the default behavior. And that helps us to protect against somebody, for example,
connecting a hub or another switch to that port, and then having a whole bunch of additional
devices simultaneously access the network through a single switch port.
00:07:29
That would also help us, by the way, if the attacker was also trying to somehow misuse or abuse
someone else's Layer 2 address and trying to use it here on this other port in the same VLAN. So
even without ARP inspection and DHCP snooping, if the attacker tries to use the same Mac address
that Bob's using over here, that would trigger a violation and shut down the port as well.
00:07:49
Now in addition to the actual switch ports themselves, we also have the VTY lines. And the VTY
lines simply support virtual terminals. And on a Cisco switch, there's normally 0 through 15, which
is 16 different VTY or virtual terminal sessions that the switch can support by default.
00:08:08
So if Bob is the administrator, for example, of the switch, what Bob could do is connect to the
management IP address using, for example, SSH as a secure shell to establish a command line
session to the switch. And when he's connecting, he's actually connecting on one of these logical
virtual terminal lines.
00:08:25
So what we could also do to improve the security posture of the switch is we could set up access
control lists that tell the switch, hey, only accept inbound SSH connections on these VTY lines from
certain IP addresses. And then if the attacker is attempting to connect to one of these virtual
terminal lines, if he's coming from an IP address that's not allowed, he won't even be given the
opportunity to try to log on.
00:08:49
And that's going to prevent him from being able to try dictionary attacks or brute force attacks
because he won't even have the opportunity to log on. And if for some reason we needed more than

16 simultaneous administrator log ons to this switch, we could simply create additional virtual
terminal lines in a Cisco environment.
00:09:08
Those would be referred to as VTY lines. And the actual maximum that we could create may
depend on the version of the software. So if we had a reason or a need for 30 administrators to all
log on to manage this switch at the same time we could create 0 through 29 VTY lines, which
would be a total of 30 individual virtual terminal sessions that could be supported through those 30
VTY lines on a Cisco switch.
00:09:33
In this Nugget, we've taken a look at some hardening techniques to help make a switch more
resilient and more robust against typical attacks. Hey, thanks for joining me for this Nugget. I hope
this has been informative for you. And I'd like to thank you for viewing.
Network Hardening Techniques
00:00:00
In this Nugget, we get to chat about some network hardening techniques that we can use to make
our network a more secure place. Let's begin. I'd like you to imagine that our boss has called us in
and has asked us to supply some recommendations regarding what we could do right from the getgo to help improve the security on our networks.
00:00:20
And here is a list, my friend, of some of the ideas that we would share with our boss regarding
making our networks more secure. We would absolutely want to have some antivirus or antimalware software running somewhere in our network. It could either be host-based, for example,
running on individual computers and individual servers, or it could be network-based.
00:00:42
Maybe we have our firewall that's responsible for analyzing all the traffic that's going over our
network and identifying the malicious content if it sees it. So a device that's capable of that would
be like a UTM, a Unified Threat Management machine. Think of it like a firewall on steroids.
00:01:00
And because new attacks do come up all the time, we might even use with this UTM cloud-based
services, where the firewall would go out periodically and check for updates on its own and apply
those updates regarding new signature matches for new attacks. We also might subscribe to a
service up in the cloud that is watching for, globally, network attacks that are going on.
00:01:23
And it could feed that information to the firewall. So for the example, if there's a hostile country
that's sending a whole bunch of traffic and attacking various systems, this server up in the cloud
that's aware of those attacks could feed that information to our UTM device, our firewall, so that
our firewall, if it sees packets coming in from that certain source address or that range or block of

addresses, could take extra precautions against that type of traffic that's coming into our network.
00:01:49
We'd also recommend to our manager that a security policy should be established by senior
management, and then based on that security policy, we could implement the controls to implement
that policy. For example, we might have access control lists on our routers and our firewalls.
00:02:04
We could have access control lists that are filtering based on certain types of ports or certain IP
addresses. And we could also have our devices in the network filter based on types of URLs and
types of sites that our users are attempting to access. And when doing web content filtering, it's also
likely that our unified threat management system is also using a server up in the cloud to get the
classification information regarding websites.
00:02:28
So if Bob the user is trying to go out to www.gaming.com, the firewall needs to know, first of all,
what category is gaming.com in? Is it truly a gaming website? And if it's allowed by policy or not,
the unified threat management system can go ahead and enforce that by either allowing the traffic to
go ahead and go out, or it can stop it if the policy is not allowing it.
00:02:49
And many times, when we implement an access control list or an access list-- sometimes it's called
an ACL, Access Control List-- at the very end of an access control list is a Deny All or Deny Any.
And it says Implicit because it's not literally a line in the access control list.
00:03:05
For example, let's say we have three lines in our access control list, and the first line says, permit IP
traffic to destination Y. And the second line says, deny protocol Z. And the third line of our access
control list says, permit protocol Q to anywhere, meaning to any IP address.
00:03:26
If this is our access list and we've applied it to an interface, either on a router or a firewall and a
packet comes in, the router or firewall using this access control list is going to compare the packet
against each of these lines in order until it gets a match.
00:03:39
So it's going to compare it to line number 1. If it's a match, it will permit it, and it's done. Next
packet, please. If it didn't match line number 1, it would check entry number 2 and see if it's a
match. Is it protocol Z? If it is a match, the packet would then be denied.
00:03:53
If it's not a match, it would go to 3 in the access list. And that says, permit protocol Q to anywhere.
If it's not protocol Q and doesn't match any of these lines, it would then have the implicit deny,
which says, sorry, didn't match any of our permits or denies explicitly in the list.

00:04:10
We're going to deny you. And the packet is dropped. Now, I'd like to ask you a question about this
access list. Do you think it matters the order that we have this access list in? And the answer is yes,
it does matter. For example, if we didn't want Bob the user to be able to use protocol Z anywhere,
unfortunately if Bob is sending packets to destination Y, because the access list entry 1 is only
looking for IP traffic going to a certain IP address, if it matches, boom, the packet is permitted, and
they would never get to line number 2. So if we meant to have protocol Z never allowed anywhere,
we might want to move this entry to and move it into the first position and make it line number 1.
And that would make this entry number 2. And if we reordered it in that fashion, the very first thing
to be looked at would be, is this protocol Z? And if it is, it would be denied.
00:05:00
And if it isn't, then it would go to line number 2 to see if it's IP traffic going to this destination of Y.
So we need to be careful with a couple things, with the Deny All at the end that's implied, as well as
the ordering of the access control list entries that we've applied to our router or firewall interfaces.
00:05:17
We should do vulnerability scans and make sure that we do not have any unneeded network services
that are currently running on our devices. If we don't need FTP services running on a server, we
should disable those services so that they're not available to an unauthorized individual, such as an
attacker who may be trying to get access into the system.
00:05:37
In previous Nuggets, we've already mentioned the fact that we should not be using insecure or
unsecure protocols, and instead, we should be using secure protocols. And here's a nice laundry
list-- SSH for remote session, SNMP for remote management of our systems, and SNMP version 3
supports authentication data integrity and confidentiality through encryption.
00:05:57
TLS and SSL, which we love and know and see as users as HTTPS, can be used for secure
communications with secure web servers. SFTP is a secure flavor of FTP. And HTTPS we've just
described. And IPsec would be one of our options if we're using virtual private networks.
00:06:15
So we could use IPsec or SSL depending on the technology that we're using to protect our traffic as
it goes over otherwise untrusted networks. In our discussions on wireless, we've already identified
that WEP is a really bad idea. It's better than nothing, but not much.
00:06:31
And the fact that WPA is better and WPA2 is best means that we should always use WPA2.
Enterprise implies it we have a centralized AAA server, such as this one here. And personal implies
that we're using a pre-shared key. And to make sure that isn't cracked, we should probably use a
really tough key, something that's eight characters or longer, upper and lowercase, alphanumeric,
special characters, to make it really resistant to a brute-force attack.

00:06:56
TKIP was an intermediate step in helping make wireless more secure. It stands for Temporal Key
Integrity Protocol. And AES is the encryption algorithm, the advanced encryption standard that we
use with WPA2 today. We could also point out to our boss that 802.1x can be used for both wireless
as well as wired.
00:07:15
For example, if we have this device that wants to get access to the network and the users connecting
to the switch, we can enable 802.1x on the switchport and on the switch. And then on this computer,
we can have something called a supplicant. And you can think of the supplicant as an agent, or a
little piece of software that communicates between the computer and the switch.
00:07:35
And the primary purpose is for the authentication and validation of the devices trying to connect. So
the benefit of using 802.1x with a switchport is that the attacker who finds an open jack and plugs
in, he won't get any further than that switchport, because he won't be able to authenticate using
802.1x. And if we compare that to the user Bob and Bob has supplied his credentials via the
computer, the computer can supply those via 802.1x, and here's how it goes.
00:08:03
The supplicant running on this computer supplies the credentials to the switch. The switch does a
check with a AAA server, and that's usually done via RADIUS protocol. And basically, we're asking
the policy server, this AAA server, hey, I've got this user's credentials.
00:08:18
Is this user allowed to access the network? So the policy server, besides checking for the
credentials, can also check other factors regarding that machine that's connecting. And assuming
that Bob is allowed to connect, the access rights can be communicated back.
00:08:31
In this case, they'd be communicated back to the switch, at which point the switchport would be
authorized, and Bob would now be able to communicate through that port to the rest of the network.
TLS stands for Transport Layer Security, same thing as it meant over here.
00:08:45
And TTLS is Tunneled Transport Layer Security that we can use with 802.1x and something in the
background called EAP, which is the Extensible Authentication Protocol. And the long story short
with 802.1x and EAP is we want to validate that the device that's trying to connect to our network is
authorized and should be on our network.
00:09:07
And we can also do MAC address filtering. And MAC filtering can be used with wired as well as
wireless. So we could set up a list of allowed MAC addresses, and then any device that's trying to
attempt to come into the network who is not on the approved list regarding their layer 2 address

would not be able to access any further into the network.

00:09:26
If we have a remote user who is connecting via, for example, a point-to-point protocol over a serial
link, we could use CHAP or MSCHAP authentication for the authentication of that user. So CHAP
as an industry standard, and MSCHAP is an enhancement from Microsoft regarding CHAP.
00:09:42
Now, what we want to avoid if we're using point-to-point protocol is a user authentication called
PAP, Password Authentication Protocol, because PAP sends the credentials in clear text, which is a
big no-no if we're concerned about security. EAP stands for the Extensible Authentication Protocol.
00:10:00
It is used extensively with 802.1x authentication. It's a framework that we can use for authenticating
users. And Kerberos is an example of an authentication method that's used by Microsoft's Active
Directory. And the cool part about Kerberos is that a user can authenticate once into the network, in
this example a Microsoft Active Directory network, and then once the user has authenticated, that
same user does not have to reauthenticate to get to additional resources that they're entitled to in that
Active Directory network.
00:10:31
If we want to make really sure who a person is, we can use a multi-factor authentication, which we
have discussed previously in this course. The three factors are something that a person knows.
Examples would be a password or a PIN number. Another factor would be something the user has.
00:10:49
For example maybe they have a card, either a smart card with a computer chip in it or a tokengenerating card that generates a new number every 60 seconds or Google Authenticator, which
generates a code every 60 seconds. And the third factor is something that the user is, which refers to
biometrics, a fingerprint, the characteristics of a body part.
00:11:10
[LAUGHS] That sounded bad. For example, an eye, either the iris or a retina scan or their voice
pattern, the way they speak. So to meet the requirement for multi-factor authentication, you need to
use at least one factor from two or more categories. So it could be something the person knows and
has.
00:11:29
That would work as multi-factor authentication. Or something the user has and is-- that would also
work, or something that the user knows and something the user is. And that would also work-- so
any two. So you might ask the question, well, what's the difference between two-factor
authentication and multi-factor authentication? And the answer is, two-factor authentication is an
example of multi-factor authentication.
00:11:53

And if you had all three factors required to authenticate a user, which would be something the user
knows plus something the user has plus biometrics, something the user is, that would also be an
example of multi-factor authentication using at least one of each of the three factors.
00:12:09
And so maybe in a Kerberos environment, we're requiring multi-factor authentication, but since it's
single sign-on, once the user has been authenticated once, he is no longer required to reauthenticate
every single time that user gets access to a different resource inside of that Active Directory
network.
00:12:26
And Single Sign-On we'll often see as SSO. So that's the acronym for single sign-on. So these are
all network hardening techniques. And the last piece here regarding hashes is about data integrity.
For example, let's say that Bob is right here, and Bob wants to download a file from the internet.
00:12:43
So he downloads the file, he looks at in his Downloads folder and wonders, is this the accurate file,
or is this a file that some hacker has gotten, has embedded their malicious code in, re-compiled it,
and I'm about to install it? That's a good question, by the way.
00:12:59
So besides Bob having some locally running anti-malware software on his host, on his computer,
what Bob could also do is open a browser up to the vendor's website, for example, Cisco Systems, if
it was an IOS image that he downloaded. And what Cisco and other vendors are going to do is
they're going to list an MD5 or a SHA fingerprint. It's also sometimes called a digest.
00:13:23
And what we would do is we would look at that fingerprint or that digest that's associated with the
file that we downloaded, and then we would run the same algorithm on the file we downloaded, and
the fingerprint, or the digest, that the vendor is reporting for that file, that should match exactly with
the fingerprint/digest that we generated for that same file.
00:13:43
In this Nugget, we've taken a look at some network hardening techniques that we can use to make
our network overall a more secure environment. Hey, thanks for joining me for this Nugget. I hope
this has been informative for you, and I'd like to thank you for viewing.
Firewall Features
00:00:00
In this Nugget, I'd like to share with you a little bit more about some details regarding firewalls and
their features that we would commonly find on networks today. Let's begin. A lot like people,
firewalls come in different shapes and sizes and have various sets of features that we may want to
use.
00:00:16

For example, a host based firewall is software that is running on a host. Let's imagine we have a
critical server right here, and what we could do is have a host-based firewall running in software on
this device that's preventing unauthorized inbound requests.
00:00:31
Another location we're very likely to find firewalls are network-based firewalls, like this bad boy
right here. And a couple of decades ago, it was all about packet filtering. And we had access control
lists on the firewall interfaces that controlled exactly what would be allowed through and what
would not be allowed through.
00:00:49
But the challenge with that is when we have users, like Bob and Lois and hundreds of other users on
the inside of our network, and they're all going out to the internet. With only packet filtering using
access control lists, it's a pain in the rear, because Bob could be going to anywhere on the internet-or trying to go to anywhere on the internet-- and what Bob is expecting is that when he goes out to
the internet he's expecting a response to come back in.
00:01:12
So today, in the 21st century, most of our firewalls are stateful. And we've touched on this before, in
other Nuggets in this course, and as a reminder, a stateful firewall remembers. [SINGING] I will
remember you. And so this firewall is saying, every time Bob's packets go out to the internet, the
firewall remembers-- in memory, in a stateful table-- the details about Bob's session.
00:01:35
What was the source IP address? What was the destination IP address? What was the source port?
What was the destination port? And if the reply traffic comes back in that is correct, meaning it has
the correct ports involved, the correct IP addresses involved-- if everything is correct regarding a
correct reply packet, the firewall, because of the stateful filtering, will dynamically allow that reply
traffic to come back in.
00:01:56
And that's what a stateful inspection is all about. So for a brand new firewall, what we could do is
we could put IP addresses on the various interfaces, we could specify which interfaces are
connected to, for example, the inside; which interfaces are connected to the outside; which
interfaces are connected to our DMZ.
00:02:14
It's very likely we would configure routing capabilities on this firewall so that it has a default route
that leads out to the internet-- and perhaps static routes for other internal routes, or we could run a
dynamic routing protocol, like RIP or OSPF, on that firewall so it could dynamically learn the
networks and build its routing table appropriately.
00:02:34
And then the default attitude on most firewalls will be to say no to any traffic that is trying to come
in from the outside. And also, the default attitude may be yes for any traffic from the inside that's

trying to go out. So as Bob goes out to the internet, the initial flow of traffic is allowed, the stateful
filtering remembers that session and dynamically overrides the default behavior of no regarding the
reply traffic coming back in, because of the stateful filtering, the stateful database that the firewall is
building.
00:03:03
And for users on the outside, like Larry, who want to get to a web server on the DMZ, we would go
ahead and use an access control list on the outside interface of the firewall that explicitly permits
certain types of traffic-- for example, traffic coming from anywhere on the internet.
00:03:19
It is going to an IP address associated with one of these servers, as well as requiring it to have a
specific port, such as 443 for HTTPS, that would allow a user on the outside, like Larry, to go ahead
and access one of these secure web servers. And stateless inspection is just talking about packet
filtering without any ability for a firewall to remember the state of a session.
00:03:43
Now one of the very interesting things about this firewall right here is that this firewall could be
implemented as a physical appliance-- meaning a device that you slide into a rack that is actually
the firewall itself-- or it could be implemented completely in software.
00:03:59
It could be implemented as a virtual machine running in a virtualized environment, such as
VMware's vSphere. And the trend is more and more to move to the virtualized environment,
because devices like firewalls and other virtual devices are much quicker to deploy in a virtualized
environment, as opposed to having the physical hardware for every single device.
00:04:19
As an example, the firewall that we have in our Network Plus topology-- this device right here-- is
not a physical firewall. It's simply a virtual machine-- a firewall appliance that's running in my
virtualized environment here in my lab. One of the challenges that we may face in our network is
when we have a user like Bob that's trying to go out to the internet, do we want to allow Bob to go
to any possible website? And the answer is probably not.
00:04:45
Based on our company policy, we may have some restrictions in place regarding what Bob is not
allowed to go to. For example, let's say we are not allowed to go to any hate-based websites-- zero
tolerance for it. So one of our controls would be administrative.
00:05:00
We'd have Bob get the training that he's not allowed to go to hate sites. And then secondly, we'd
have him sign an agreement saying that he understands the policies and the rules about what he's
allowed to do and not do. And then, just like President Reagan used to say-- trust but verify-- we'd
also want to follow that up with technical controls so that if Bob is trying to go to a hate site, we can
have the firewall go ahead and block that.

00:05:23
And that would be an example of doing URL filtering. So what we would do on the firewall is we
would configure our policy regarding what types of sites are allowed to be visited or not. The
firewall would have access to some cloud-based service that is keeping track of the entire internet
and being updated very likely daily.
00:05:41
And then when Bob goes to www.example.com, the firewall is going to check its database just to
verify whether or not that is a hate site, and if it is, it's going to deny Bob's access going out.
Another scenario that we might have as a part of our policy is that we might allow Bob-- on lunch
breaks and so forth-- to go out to Facebook to check status updates on his personal time-- for
example, on breaks or on his lunch.
00:06:04
Or if Bob is in charge of social media for his company, he's going to be going out to Facebook all
the time. However, even though we want to allow Facebook, maybe we don't want to allow games
to be launched and run through Facebook-- for example, many, many years ago it was Farmville,
and they've got newer games and newer games all the time.
00:06:24
So how in the world do we allow Bob to go to Facebook, but stop him from running applications
within Facebook? One of our solutions to that challenge could be to use a firewall that is both
application aware and context aware. And what that means is at the upper layers of the protocol
stack, the firewall is able to look at the types of content that's going back and forth.
00:06:44
And it can distinguish between general Facebook traffic and applications that are being run through
Facebook or from Facebook. And normally, when we start taking a look at a firewall that can do
that application awareness and application inspection, we're talking about a device that is a UTM-a Unified Threat Management system.
00:07:03
And in addition to application awareness, it also has the ability to support data loss prevention. So if
it sees information that look like social security numbers or credit card numbers that are trying to go
out from the network, it can stop that. It can provide anti-malware inspection as well as intrusion
prevention system services right on the firewall itself.
00:07:22
And the features, specifically, that you'll have in your firewall depend on the vendor that you're
using and the licenses that you've purchased from that vendor for those features. And what we're
going to notice also is that the more features and the more throughput that a firewall or a UTM
supports, the more expensive it's going to be.
00:07:39

So normally, the vendors also have a little mini-me version of these firewalls that we could deploy,
for example, in a small office or home office that have many of the same features, but they support
a fewer number of users-- for example, 10 users or 50 users-- because companies want the same
level of protection at a branch office as they do at the headquarters site.
00:08:00
And that way they can purchase the licenses or the appliance or the model of hardware to support
their needs, and pay less for a smaller model that will be deployed at the branch office. And I've got
a couple favorites regarding unified threat management.
00:08:13
I really, really like Check Point. I also really like Palo Alto. I happen to be certified in both of those.
Another player in the UTM game that I'm just becoming more aware of is called Sophos, and
they've got a free home version for the UTM that you can download and use at your home for free.
00:08:30
And also Cisco Systems has a device called the ASA, which is the Adaptive Security Appliance-which is a firewall-- and they are also getting more and more integrated with additional features,
becoming more and more of a real UTM system. So if you're taking a look at UTM, I would
recommend you check out Check Point and Palo Alto if you want to put that side by side with Cisco
Systems as well.
00:08:53
And then your company, based on all the evidence and the testing, can make their own decision
about which of these solutions may be best for your environment. Oh, and by the way, we also have
courses here at CBT Nuggets on Check Point, Palo Alto, as well as Cisco Systems ASA firewalls.
00:09:08
So after Network Plus, if you want to dig more into the security aspect with those devices, check
out our courses on those topics. Now let's imagine that we have a firewall that is a UTM, a Unified
Threat Management system, and we have a full license for all of its features.
00:09:23
What could we possibly do with it? Well, it's likely going to be application and context aware. It's
very likely going to have stateful inspection as well as stateless, meaning we can still do packet
filtering with access control lists. So access control lists will still be available.
00:09:37
And one of the features that many vendors offer is the ability to deploy this firewall either as a layer
2 or a layer 3 implemented device. And what do we mean by that? Well, in our topology here, here
we have the 10.1 network that's here, and then we have the 10.2 network between the firewall and
router one, and then I believe we have the 10.3 here, and the 10.4 with a 16-bit mask. So the last
two octets would be zero zero.
00:10:03

Well, if we would deploy the firewall like this, as a layer 3 device, that would be an example of
deploying a firewall in routed mode. So if we did a [? tracert ?] from computer 2, it would show
router 1 as a layer 3 hop in the path. It would show the firewall as a layer 3 hop in the path, Router
Two as a layer 3 hop in the path, and so forth. And that leads us to our next possibility-- what is a
virtual wire? A virtual wire is really handy if we want to add a firewall but we don't want it to be its
own layer 3 hop in the path. And it could go something like this.
00:10:35
Let's say, here we have the 10.7 network-- so here we have devices on that network, and then we
have a router-- we'll call this router 9. And then we have another interface-- let's call this the 10.8
network. And let's say then we have router 10, and then router 10, for example, goes out to the
internet. Well, if we were going to inject a firewall here between R9 and R10, if we integrated it as a
layer 3 device, we would have to add another network-- maybe have 10.8 on the left and 10.9 on the
right-- and we have to change our IP addressing scheme.
00:11:05
If we implemented the firewall as a virtual wire-- and often that's referred to as a transparent
firewall, meaning it doesn't take a layer 3 hop-- we could inject it here, and the firewall would go
right here on the network. But on both sides it would still be 10.8. So in that sense, from a network
topology perspective, it's very much like a switch, a layer 2 switch. So all of the frames and packets
have to go through that firewall, except-- here's the cool part-- the firewall can still implement all of
its policies.
00:11:35
For example, it can still do IP packet filtering based on layer 3 information. It can still do
application aware and context aware inspection. It can still do network address translation, if we
have it doing that. So that way, depending on the vendor's implementation, we still have all the
features of a unified threat management system, except we're not implementing it as a layer 3 hop in
the path. And that's what a virtual wire or a transparent mode firewall is all about.
00:12:00
Regarding a demilitarized zone-- and the DMZ is a great place where we can put resources that we
want available to the outside users. So if this is the inside of our network, and this represents the
outside of our network, and the blue here represents the DMZ, we could use an access control list to
specifically allow just certain types of traffic to the resources in the DMZ, such as our web servers.
00:12:22
And what we want to avoid is allowing traffic initiated on the outside, like from Larry, from ever
being able to go directly into the inside-- and that's if Larry is trying to initiate that connection. So
the DMZ is another concept regarding isolation to help keep our inside resources secure.
00:12:38
And as we mentioned in our discussion on access control lists, there is an implicit deny at the end of
an access control list. And there's also, on many firewalls, an implicit deny regarding traffic from
the outside that is trying to go to either the DMZ or the inside, so that by default that traffic would

not be allowed.
00:12:56
And the exception to that would be if we created access control lists, applied them on the outside
interface that allowed just specific traffic from the outside up to our DMZ resources that we wanted
the outside users to be able to access. Now regarding blocking or allowing traffic, one of the-- it's
kind of funny.
00:13:13
One of the concepts that's kind of funny is outbound verses inbound. It means different things
depending on the context. For example, let's take the user Bob, who's sitting at computer 2, and Bob
is sitting on the inside network work from the firewall's perspective.
00:13:29
And Bob is trying to access a resource that's out off the outside. So from a big picture perspective,
Bob's request as he's going to the internet is an outbound request. His traffic is being sourced from
his computer, which is on the inside, and the destination IP address is somewhere on the internet,
which is off of the outside interface.
00:13:47
So that would be outbound traffic. The reply coming back from that server back to Bob could be
considered, from the big picture, as inbound traffic. And that is perfectly good, as long as the
context is the entire topology. However, it gets a little dicey when we start looking at the firewall
itself.
00:14:04
I'd like you to imagine, just for a moment, that you and I are this firewall. That is us. And Bob is
sending a packet, and that packet is being sent into the switch, it's being forwarded to the router, the
router routes it to us. As that packet comes in to us, is that an inbound packet? And the answer is-regarding this interface on this firewall-- the answer is yes.
00:14:27
It's coming in to the firewall on that inside interface. So from the firewalls perspective, that packet,
indeed, is an inbound packet. So if we had an access control list applied on this interface, we could
specify which direction the access list is going to be applied for.
00:14:42
Is it traffic coming into the firewall, or going out of the firewall? And then for that same packet-assuming it's allowed-- as we forward it out the outside interface, that packet, from this interface's
perspective, is now an outbound packet. And the actual placement of a firewall depends on where
we want the protection.
00:15:00
So generally we'll have at least one firewall that is protecting the inside network, the private
network, from the big bad internet, like we have in this topology. But we could also have individual

firewalls inside of our network. For example, maybe we have a human resources department, and
they've got a network, and perhaps we'd want to put a firewall that's between the human resources
subnet slash VLAN and the rest of our network.
00:15:23
So over here maybe we have sales. And depending on our network situation, that firewall may be
there for the intent of keeping HR out of the sales network or vice versa. It just depends on our
security policy and what we're trying to protect. So I want to give you a quick demonstration of
what it might look like to work with a firewall.
00:15:41
This is an example from Check Point. So if we expand the network objects, and we go to the
corporate gateway and select that, from here we can see the details regarding this firewall. So here
on the general properties page it has the platform it's currently running on, and it has the security
features which are currently enabled on this appliance.
00:15:58
If you go to Topology, it's showing as the various interfaces and the IP addresses on those
interfaces. And because this is a UTM device, it has lots of features, including AntiBot and antivirus. It has identity awareness that associate a user with an IP address.
00:16:12
It's learned that from the network. And that way we can set up rules. So for example, if we want
Bob to have certain rights through the network, we can set those up in policy, and then the firewall
can associate, oh, this is Bob's IP address. I'm going to go ahead and apply those rules based on this
address.
00:16:26
It has IPS support, VPN support, data loss prevention, and a whole bunch of other bells and
whistles. If we click on Policy, here's how we could implement policy. So each of these entries
represents a rule. So for example, in this entry number six regarding outbound HTTP, if traffic is
being sourced from here going to anywhere, and the protocol is TCP port 80, it's going to require
client authentication before allowing that traffic to go.
00:16:51
And one of the cool things about Check Point is that if we wanted to move this, for example, higher
up in the list of rules-- because they're processed in order from top down-- we could simply drag
and drop it to put it there. Another really cool feature with Check Point is they've got some amazing
reporting tools.
00:17:05
For example, if we go to SmartConsole and we go to SmartView Monitor, it can provide details
regarding the top services, top destinations, top security rules. So if you click on, for example, Top
Services, we could select our corporate gateway, click OK. And here it's giving us the details
regarding the top services, which is way cool.

00:17:22
Or if we wanted to look at the top interfaces for our corporate gateway, click OK. Here it's showing
us the utilization on the various interfaces. And another cool thing is we could dig into the details of
individual packets that have gone through our network.
00:17:35
So for example, if we go to SmartConsole and go to SmartEvent, here in the timeline it gives us a
really bird's eye view of what's really happening in our network. And if we wanted to dig into one
of these, we could go ahead and simply double click on it, and it could give us the details of exactly
what happened.
00:17:48
So this shows us that the user called Josh at this IP address was trying to download a malicious file.
It was prevented. He was using HTTP port 80. And it happened yesterday at 21:33. And over here it
gives us the details of the actual file that he tried to download.
00:18:03
And the cool thing is, is that the firewall, this UTM device, stopped it. And this is the summary
page, if we want to take a look at the details for this. And I just can't get over how cool Check Point
is with how easy they make it to get that bird's eye view of what's really happening on the network,
and then very quickly drill down to look at the details.
00:18:20
Once last thing I'd like chat with you about in this Nugget is the changing of the guard. [SINGING "RULE BRITTANIA"] The changing of the guard in a network is not always a beautiful thing. For
example, the previous administrator may not have given us all the information regarding the
existing network and/or the passwords involved to manage it.
00:18:42
So if, for example, this firewall was implemented as a virtual wire implemented firewall, we
wouldn't know off the top of our heads what the correct IP address is to manage this device. So if
this was a transparent firewall, a virtual firewall, there would be one logical IP subnet between
router 1 and router 2. And so now the question is, how do we find out what the IP address is for this
firewall so we can even try to connect to it? And many times when we're managing firewalls we're
going to be using SSH to get a remote shell securely to that firewall, or we'll use HTTPs to that
firewall.
00:19:16
But it's tough if we don't know what the IP address is. And in a situation where we don't know what
the management IP address is of the firewall, what we may have to do is we may have to schedule
change control, communicate to all the users that there's going to be a period of downtime-- for
example, Tuesday night from 11:00 PM to 1:00 AM-- and then what we might have to do is use a
console cable to directly connect to the firewall.
00:19:39

And each of the vendors have their own methods for passive recovery. And sometimes passive
recovery can be disabled on a firewall, so it's not even possible. So then what we might have to do
is simply wipe out the entire firewall to get back to its factory defaults, and then reconfigure it the
way we want it to be.
00:19:55
And the same concept applies to a small office, home office device. There's often a reset button
where you can plug it in, hold on the reset button for, like, 30 seconds, and then it will basically
wipe out the entire configuration and set it back to its factory defaults, with the default username
and default password, so we can then start rebuilding the firewall.
Network Access Control Models
00:00:00
Network Access Control Models-- I remember someone telling me that a stitch in time saves nine.
And the concept about that is that if we identify a problem or issue early on and deal with it directly
then, that can save us from doing a lot of damage control later.
00:00:18
And regarding network access control, and individuals or devices that are connected to our
networks, let's consider computer two here for a moment that we've often used for the user Bob.
Now here's the question. If Bob's computer does not have antivirus software, or has a whole bunch
of malware running, do we really want to allow that device to connect to our network, and as a
result, potentially have a security issue from Bob's machine-- either having data leaked out through
Bob's machine or having Bob's machine be responsible for the compromise of other devices on our
network? And I know we've already talked about 802.1x a couple of times in these Nuggets.
00:00:54
It shows up in the blueprint multiple times. And I thought we would err on the side of caution to
make sure covered it. And the concept about 802.1x is to validate a device, like a computer, and
make sure we know who the user is, for example, behind that device, before we allow that device to
communicate on the network.
00:01:11
And here's a reminder regarding that process. So for example, if this is Bob's computer, he's
connected to a physical switch. He wants to get access to the network. Before Bob is ever allowed
to communicate with other devices on the network, a little agent running on his computer in
802.1x-- we call that a supplicant-- is going to supply the credentials over to the switch.
00:01:32
The switch is going to check with the AAA server, or policy server, regarding whether or not those
are the correct credentials for Bob. Another aspect of this is we can also send over details regarding
the posture of Bob's machine-- a posture assessment. For example, maybe we're requiring certain
versions of personal firewalls on Bob's computer or anti-malware software that is relatively up-todate.

00:01:54
And so the agent could be reporting all of that over to the policy server. And then the policy server
could say, you know what, that doesn't meet policy. He doesn't have up-to-date software. As a
result, the policy server could communicate back to the switch and say, you know what, this guy's
no good.
00:02:08
He can't get in, because he doesn't have the correct software involved. Now the agent that's actually
providing that check of the software on Bob's computer-- that could be a persistent agent, which is
running all the time on Bob's computer, or it could be a non-persistent agent, which is simply run
just at the moment we're doing the checking.
00:02:26
And then after the checking is done, then the agent application is no longer running. And if Bob is
not compliant, maybe for example we're requiring some virus scanning software and Bob's
computer doesn't have any, the policy server can inform the switch that the port that Bob is
connected to-- that should be placed in a quarantine VLAN.
00:02:43
Sometimes that's referred to as a quarantine network, or a remediation network, where Bob can get
access to the software updates that he needs to get his machine compliance for network access. So
maybe Bob is placed in VLAN 777. And while he's on that network, he can go ahead and access the
resources for doing his updates, installing the virus scanning software that's required, or updating
the software.
00:03:06
And then once he has it, he can attempt to connect again, at which point, he'll send the credentials
over. The agent will send the posturing information over. The policy server will give a big thumbs
up or thumbs down. And if Bob's computer's is compliant, then the AAA server can let the switch
know to go ahead and put Bob in his normal VLAN.
00:03:23
Maybe Bob is normally assigned to VLAN 9, and so the switch port can be configured for VLAN 9.
And then Bob would have access and be connected, logically, to VLAN 9. And this is an example of
edge control. We're controlling access at the edge of our network.
00:03:39
And does that means that once Bob has been authorized and has access into the network that he has
full access to everything? And the answer is no. We can still set up restrictions. For example, on the
server, Bob may have read-only access to specific servers or read-write access to others.
00:03:54
And as Bob's traffic is going over the network, we could also have rules on firewalls and routers,
including access control lists, on the interfaces of our routers, that are controlling whether or not

Bob's packets are going to be allowed from one network to the other.
00:04:08
And the access list would be an example of access control once Bob has access to the network
itself. So whether it's access control on a server or access control via network interfaces with access
control lists, those are both examples of access control once Bob is into the network.
00:04:23
And many networks are going to have a guest network. And the key about a guest network is that it
is going to be isolated, completely separated, logically, from the private network. That way if a user
is on the guest network, they won't have any access to the private network resources.
00:04:38
So maybe the guest network has access out to the internet or to other basic service such as DHCP
and a default gateway for that guest network, but that's about it. In this Nugget, we've taken a look
at a few Access Control Models, including access control at the edge using technologies like 802.1x
and access control internally in the network, by using techniques such as access control lists on
router interfaces.
Computer Forensics
00:00:00
In this Nugget, you and I get to discuss a few forensic concepts as they relate to computers and
digital systems. Unfortunately, when there is some type of a digital incident-- for example, a server
or a host was compromised either by an attacker or an internal user, it's very likely that if we have
digital evidence from forensics, it's very likely that that information will not-- I repeat, will not-- be
admissible if that case ever goes to court.
00:00:28
And the reason for that is that the handling and the processing of that information and data is
normally not done in a sufficient manner that it would be considered in a court of law to be reliably
accurate. So regarding incidents that happen on our network, we would have a team or an individual
who would be the first responder.
00:00:48
So some incident happens, and the first responder would go in to take a look. The first responder
would very likely secure the area. And part of securing the area is to make sure that nothing gets
modified until all the evidence is correctly documented and collected.
00:01:02
And if the first responder is not trained in a certain area, escalation to somebody else on the team
may be necessary. Also escalation outside of the company may be required. For example, to law
enforcement. So the documentation of the scene may include pictures, what physical devices are
there-- for example, how many computers or what computer, the serial number of that computer, the
components installed on that computer.

00:01:26
And as part of the collection of evidence and data, we also might use e-discovery. Now, e-discovery
might be looking across multiple systems, perhaps to track where a user has been. And we may
have logs on our other devices, including routers and firewalls that could identify the IP addresses
involved between the system that has been compromised and other devices that were
communicating with that system.
00:01:47
And at every step of the way, we want to preserve the evidence. For example, on a hard drive, if
there's any possibility of writing to the hard drive after the incident has occurred, that could corrupt
that evidence. So a lot of times, we'll take a hard drive and we'll create an image of that hard drive.
00:02:03
And we'll also create a checksum or a digest regarding the drives, just to verify that there's an exact
match. And then as far as forensics goes, if we need to do more detail in looking into the drive, we
could do it on the copy while preserving the original drive as evidence.
00:02:19
And that way we're not tampering with or modifying the data on that initial drive that's going to be
used as evidence. And one aspect regarding the evidence is called chain of custody. And it involves
tracking and making sure we are accountable for knowing exactly where that evidence is every step
of the way, from the initial responder who got on the scene and then following the evidence every
step of the way so we know exactly where it was.
00:02:42
For example, how was the physical data transported from one location to another? Who had
possession of it? So a chain of custody is like a paper trail that documents every single moment
from the time the first responder showed up until the time that evidence is going to be used, for
example, in a court of law.
00:02:59
And if there's a break in the chain of custody, or tampering, or modification of that evidence could
happen, that would be enough of a mistake in most environments for that evidence to not be
admissible in court. An examiner would very likely create a forensics report regarding what they
found and what they discovered.
00:03:17
And sometimes the data isn't all just at our fingertips. Perhaps another organization or entity has
that data. So a legal hold could be issued to help preserve that data so it's not changed or deleted or
disposed of. And if properly maintained, the data being preserved by that legal hold could then
possibly be used in a court of law as part of a case.
00:03:37
And computer forensics is a very interesting field. And normally people who deal with it are going

to be specialists in that field. I know father and son team in California, and that's all they do. They
focus as expert witnesses and first responders so they can properly collect and handle the data so it's
still admissible in court, as well as do discovery and forensics on the media and on the computer
systems so they can create the reports about their findings.
00:04:03
And if you want more information regarding computer forensics, I would encourage you to check
out forensiccontrol.com. They've got some great documentation, including a Beginner's Guide to
Computer Forensics, which can provide you, if you're interested, with further information and more
details regarding the field of computer forensics.
Common Security Issues
00:00:00
Identifying and resolving security issues on our networks. Let's begin. I've had the opportunity to
see some really great security implemented in my time, and I've also seen some examples of
absolutely really poor security as well. One of those examples is a misconfigured firewall.
00:00:18
I had a call from a friend who was implementing a firewall. They said, well, I couldn't get it
working correctly. So what I did was, on the firewall, I just created access control lists on both
interfaces, the inside and the outside. And I did an access list that said, permit IP from anywhere to
anywhere.
00:00:36
And that was his whole access control situation for the firewall. And that absolutely is a
misconfiguration, because at that point the firewall really isn't providing any type of filtering if it's
simply allowing all traffic in both directions to go through the firewall.
00:00:51
And one way of solving problems like that is using at least two people, where we're identifying
what the objectives are for the firewall, we're doing a test config inside of a test environment. And
then we have a second person validate that configuration.
00:01:05
And that may include some penetration testing just to validate that the types of traffic that we're
trying to filter are literally being filtered. Another security issues is if we have, for example, an
application that doesn't require security, or doesn't require authentication.
00:01:19
So generally speaking, if we have an application inside of our company, we want to require user
authentication before giving access to that application, or to any other resource. And if we're using
Microsoft Active Directory and we're using Kerberos, we're likely using single sign on, where we
could log on once, and after we've authenticated, we can then access additional resources without
further authentication.

00:01:41
But even with single sign on, we're still authenticating once. And the system is only giving us
access based on that successful authentication. To protect against malware, we could use virus
scanning software and anti-malware software on our individual computers, as well as on a UTM, a
Unified Threat Management system.
00:02:00
To protect against a denial of service, it really depends on the type of denial of service that's being
implemented. If we have known vulnerabilities on our servers, we want to get those fixed, meaning
we want to do the updates and the patches that remove the vulnerability that might cause a denial of
service if that vulnerability is exploited by an attacker.
00:02:20
If we're concerned about a distributed denial of service, and having a botnet consume, for example,
all the resources on this link, we might have our service provider do limits regarding the types of
traffic that are allowed over that link. So that way if 10,000 machines that are part of a botnet are all
sending ICMP messages, if our service provider is filtering and only allowing, for example, maybe
10% of our bandwidth to be consumed by ICMP, that would help limit the impact of that type of
denial of service attack.
00:02:50
If we have open ports that represent open services that shouldn't be available on our systems, we'd
want to do our vulnerability scans, identify where those systems are that have those open ports, and
then go ahead and close those ports, more specifically, disable the service, and that way the port
won't be open.
00:03:08
A long, long time ago, in a galaxy far away, we were worried about the ping of death. And a ping of
death is when a ping request is sent that is just huge. And so as a result of it being so huge, it's
usually chopped up into multiple segments, or multiple pieces, as it's being sent across the network.
00:03:29
And the intent of the ping of death was that the receiving device wouldn't incorrectly handle it and
could cause a denial of service attack as a result of the receiving device trying to process that ping
request. Well, virtually every operating system on the planet nowadays is no longer susceptible to a
ping of death, so we don't have to worry too much about that.
00:03:49
But if we are concerned about the ping of death, as well as lots of other types of attacks, we could
have an IPS system, an Intrusion Prevention System, or have the IPS built in as part of our firewall,
as part of a Unified Threat Management system that could identify malicious types of traffic and
attacks that are trying to go through the firewall.
00:04:07

And the firewall itself could go ahead and block them and stop that traffic right in its tracks. Now in
the blueprint, it has right here unreachable default gateway. And it's not clear to me how that could
possibly be an ICMP-related issue. However, a default gateway is an important aspect for every
computer to have.
00:04:26
So for example, in our topology, network right here is the 10.1.0.0 network with a 16-bit mask, and
the router is at .1. So if Computer 2 had the IP address of 10.1.0.50, using the default gateway at
10.1.0.1 is perfect. However, if there was a misconfiguration on Computer 2, and it was told, hey,
your default gateway should be 10.2.0.1, that, my friend, is on a completely different subnet.
00:04:53
And as a result, this PC would think that its default gateway is not reachable, because it can't get to
the default gateway because it's not on the same subnet as this computer. So as a general correct
configuration, we'd want to make sure that PCs and other devices have a default gateway that is on
the same IP subnet as the computer that's using the default gateway.
00:05:14
As attackers discover vulnerabilities in existing operating systems, whether it's a server or a router
or a switch or a firewall, it's very likely that the vendor of that product is going to provide an update
that compensates for that vulnerability in their operating system or in their firmware.
00:05:32
So what we want to do is identify and keep up to date regarding the updates for firmware and
software, and test that first in a test environment. And then after we validate that the update is valid
and that it's not going to harm our equipment and that it works correctly, we could then, with
change control, go ahead and implement that into our production network.
00:05:50
The interesting thing about users is that virtually every user has the potential to cause damage on
our network, either unintentionally or maliciously. So from a security perspective, if we have a
trusted user, for example, Bob, who is an authenticated user on the network, we still don't want to
give unfettered access regarding that user.
00:06:10
We still want to have accounting in place, so as Bob is accessing various resources and sending
traffic through the network, that the network is keeping track of what Bob is doing, so later we
could go back and have that audited if we need to. And an untrusted user would be, for example, a
guest user who maybe is on our guest network, which should have total isolation between the guest
network and our private production network.
00:06:34
An untrusted user could also be an individual, such as an attacker, who is trying to access our
wireless network, or who has physical access to our building and is physically attempting to get
access through an RJ45 jack in one of the offices or cubes or areas that leads to one of our switch

ports on the switch.

00:06:52
And if an attacker can get access to the network, and they start doing packet sniffing, that is a
security risk, because if they can do packet sniffing and there's unsecure protocols in use such as
HTTP, FTP, and Telnet, as well as SNMP Version 1 or SNMP Version 2, if there's usernames or
passwords or credentials inside of that traffic, the attacker now, because of the packet sniffing, also
has access to those credentials.
00:07:19
And one of the solutions to that is simply to use Layer 2 switches. And the benefit of Layer 2
switches is that the switch is not, by default, going to forward every frame to every other port in the
VLAN. A switch, after it's memorized everybody's Layer 2 Mac addresses, is only going to forward
a frame to the port where that frame needs to go.
00:07:38
So if an attacker is connected to an access port on a switch, that attacker is not going to see all of
the packets and frames between all the other devices, because the switch is not going to send every
frame out every port. Again that's one of the benefits of a Layer 2 switch. One of the options we've
talked about regarding authentication is to make sure that every device that connects into the
network has to prove who they are before we give them access.
00:08:02
And one method that we've talked about is using 802.1x. And in combination with that, we're
usually using a AAA server. And the protocol between the switch and the AAA server is normally
going to be RADIUS when we're doing the authentication of end users who are trying to access the
network.
00:08:19
One of the aspects in setting up a AAA server to work with a switch is making sure we have the
correct passwords involved to allow that communication. So on the RADIUS server, if we
configure the password of Nugget!23, which, by the way, is characteristic of a good password.
00:08:35
It's at least eight characters or longer, it's got upper and lowercase, alphanumeric, plus it has a
special character, the exclamation mark. So if we configure this password on the AAA server, but
when we configure the switch we configure the password with a lowercase n-u-g-g-e-t-!-2-3,
because of the password mismatch, the switch would not be able to successfully make requests of
the AAA server.
00:08:59
So having a password that is correctly set up on both the AAA client, the switch, and the AAA
server is critical in getting that to work. And the same thing holds true for Cisco's proprietary
TACACS protocol, which, in a Cisco environment, could be used as a protocol between the network
device and the AAA server instead of RADIUS.

00:09:17
And traditionally, TACACS is going to be used for the authentication of administrators who are
working with that switch. And TACACS breaks down the AAA function very specifically as three
separate channels, one for authentication, one for authorization, and one for accounting.
00:09:33
And those are pretty important features that TACACS brings to the table and breaks out separately,
because we definitely want to make sure that the administrators are properly authenticated on a
device before they start making changes. Secondly, we want to make sure they are authorized to
make those changes.
00:09:48
If they try to issue a command and they're not authorized, the AAA server, using TACACS, can say,
eh, nope. Sorry. You're not allowed to issue that command on that switch. And the accounting aspect
is the documentation of what the administrator did do. So the following morning, after a change
control window, if the network.
00:10:06
is not working correctly, we can go back to the accounting records and take a look and see exactly
what changes were made and by whom, because all of that information regarding who was logged
and what they did can be stored as accounting records on that same AAA server.
00:10:20
And another thing we'd want to watch out for is default passwords and settings, which are currently
in use on many systems. If the default password system, for example, let's say this firewall, is
password, and we never change that, an attacker is very likely to try that as one of his guesses as he
tries to log on and compromise that firewall.
00:10:38
It's one of the first things we'd want to do in the settings of a new device, is to go in and change the
default password to some password that we want to use. And again, following proper standards like
eight or more characters, upper and lowercase, alphanumerics, and special characters are always a
good idea to help make it resilient or resistant against a brute force attack.
00:10:58
Many times, when an application is being developed by the programmers, they often put in back
doors. And that allows them, while they're building the application and testing it, to get very quick
access to the application without having to authenticate every time.
00:11:12
Well, before that application is deployed into a network, it should go through proper security
controls and testing, and any back doors should be removed. If it's not removed, that would be an
example of a misconfigured application. And sometimes administrators of systems will integrate
back doors into their own systems so that if something terrible happens, they can still get access in.

00:11:34
And if an administrator hides it well enough, and then there's a new administrator who comes on
board, that back door access into the system could still be present, which represents a vulnerability.
It's a weakness that, if exploited or discovered by an attacker, could compromise the system.
00:11:49
On ethernet, we're going to be using Address Resolution Protocol to map our Layer 3 IP addresses
to the corresponding Layer 2 hardware address. And we've talked about, in these Nuggets, the
concept of a ARP poisoning attack, where an attacker sends ARP messages, bogus ARP messages,
into the network to try to trick the other devices to have the incorrect Layer 2 address for something
like a server or default gateway on that local network.
00:12:14
And the intent is, by the attackers, that when the devices, for example, Computer 1, is trying to
reach the server, it'll actually use the Layer 2 address of the attacker-- let's say the attacker at the
moment is that Computer 2-- and then the frame is encapsulated with the address of Computer 2,
the switch is going to forward it over to Computer 2, which the attacker. And then once the
Computer 2 has had a chance to see it, it can then for that to the correct Layer 2 address of the
server.
00:12:39
And as a result, it's a man in the middle attack. And if we're using unsecure protocola such as FTP
and Telnet and HTTP, and if we're using usernames and passwords in conjunction with those clear
text protocols, the attacker now knows those credentials. Another technique tht an attacker may use
is banner grabbing.
00:12:57
Let's say we have an attacker out here on the Internet, and we've allowed Port 80 to the IP address
or addresses of the servers in our DMZ. Now the attacker doing reconnaissance or discovery may
want to learn what operating system is running on these web servers.
00:13:12
And why might he want to know that? It's because if he can determine what the operating system is,
he can then start researching what vulnerabilities may exist on those operating systems. There's also
organizationally unique identifiers that are built into things like Mac addresses on a device that
could also assist in giving away who the vendor is of piece of equipment.
00:13:33
Now with OUI, with the Layer 2 address, he'd have to be at the same local network to really get that
information. But with banner grabbing, the attacker doesn't have to be local. So for example, the
attacker could go ahead and connect to a port that's being allowed through the firewall, and then
take a look at how that server responds.
00:13:49

And by analyzing the response, the attacker could determine, oh, that's a Microsoft web server that's
running, or that's an Apache web server that's running. And based on that information, the attacker
could then go ahead and do that further research into possible attacks that could take advantage of a
vulnerability in one of those platforms.
00:14:06
So how do you prevent something like banner grabbing? And the answer is this guy right here. On
our firewall, it could be set up to filter certain types of responses from the web servers back to
clients. So the information would never be revealed in the event the attacker was asking.
00:14:22
And that's one of the benefits of placing a firewall smack dab between the users and the servers that
are being accessed. Another challenge in security regarding Active Directory is giving individuals
memberships to groups and then forgetting to remove that membership when the user no longer
needs those rights.
00:14:41
As an example, let's imagine Bob being given the responsibility of working in the accounting
department. So instead of giving Bob individual rights to, let's say, five or six individual servers, we
could make Bob a member of the accounting group, and that accounting group has then been given
access to the rights needed by members of the accounting group.
00:14:59
So Bob now as those rights. Then, six months later, Bob changes roles. He moves over to
marketing. And to get the rights needed for the marketing group, he has been added to a group
called marketing, which gives Bob the rights associated with the marketing group.
00:15:13
But the challenge is this. If he's no longer a member or needs the accounting rights, we need to
make sure we go back and remove Bob from the accounting group. Otherwise, Bob now has more
rights than he actually needs for his job. So to help protect against that, auditing should be done
periodically regarding user accounts.
00:15:30
And not just regarding what rights a user effectively has in the network, but also for accounts that
haven't been used in two or three months. If we have accounts on our network that haven't been
used in two or three months, there's a good chance that we should disable those accounts or even
delete those accounts, because an unattended account is simply an extra vulnerability that we have
on our network that an attacker, if he discovers the credentials for that account, could potentially
use to gain access into our system.
00:15:57
Another security issue is jamming, which, how do you stop that? Simply take away the MP3 player
from that person who's jamming. Or take away their air guitar. And the concept of jamming has
several applications. One of those is a wireless network. On our wireless access points, we are using

somewhere in the 2.4 or 5 gigahertz range frequencies.

00:16:18
And if a rogue access point comes in, the rogue access point, if it wanted to, could intentionally jam
our production access points simply by getting on the same frequencies and creating tons and tons
of noise. And then, while the jamming is happening, the attacker could bring up additional access
points as evil twins with the intent of enticing users to connect to this bogus access point as a
compromise of the network.
00:16:41
So to help mitigate jamming, many access points use a wireless LAN controller as the central brains
for the wireless networks as well as using software to identify rogue access points as they come up.
And that wireless LAN controller, in many systems, can have the access points intentionally jam the
rogue access points so it won't be effective.
00:17:01
So the question is, who has the most horsepower? Is it our access points that we have collectively
inside of our network? Or is it the little access point that's been brought up by an attacker? It's very
likely that our wireless LAN controller and the access points in the building overall are going to
have more power to identify and jam an attacker as long as that functionality exists in our wireless
system, as opposed to an attacker jamming us.
WAN Troubleshooting
00:00:00
In this Nugget, you and I get to focus on a few topics regarding troubleshooting, as they relate to
wide area networks. Let's begin. I'd like you to imagine that you and I work at the help desk for
ACME Incorporated. And we're here at the headquarters office, and we've just got a telephone call
from Bob, who is at the branch office.
00:00:18
And Bob is indicating that he doesn't have access to the corporate headquarters over the WAN link.
And this serial WAN connection is being provided to us from a service provider. And our job,
should we choose to accept this mission, is to troubleshoot why.
00:00:32
Now, there are several things that could go wrong. Router 2 could be powered off. Router three
could be powered off. The interfaces, respectively, could be down. The service provider's link could
be having a problem. One of the cables or connectors from R2 going to WAN provider's circuit,
either at the headquarters location or at the branch office-- maybe that got pulled out or broken.
00:00:53
So there's lots of things that could go wrong, and what we're going to do is take a look and see if we
can resolve it. Let's start with the basics by going to router 2 and taking a look at this interface serial
2/0. So here are router 2, we'll issue a show command. This is a Cisco IOS router.

00:01:08
Let's do a show interface serial 2/0. That'll give us the details regarding this interface right here.
And as part of this output, we have serial 2/0 is up, line protocol is down. And what that implies is
that at layer 1 we might be OK, but at layer 2 our protocol that's in use-- the layer 2 protocol is
currently down.
00:01:30
And you know what they say, if layer 2 ain't happy, the upper layer protocols don't have a chance.
So let's take a look and see what the layer 2 protocol is that we're using on this WAN link. And it
shows right here the encapsulation-- this is the Layer 2 encapsulation-- is PPP. That's point-to-point
protocol.
00:01:46
And if we go to the bottom of this output, these are attributes related to serial connections. And
because all of them say up, it looks like, at least from a hardware perspective and cabling
perspective here, that we're seeing all the signals that we should be seeing from our service
provider.
00:02:01
So it doesn't look like it's a problem with the service provider's wide area network connection. Also,
what's interesting is right here it's indicating that we've had some packets that have been input on
this interface, and also some packets that have been output on that interface, which implies that it
was working at some point.
00:02:18
But take a look at this, 26 interface resets. That's a lot. An interface reset will often happen when an
interface that's trying to function or send traffic can't do it. And it will do a reset to kind of shake
itself loose to see if that will start causing it to work.
00:02:33
Another option we could use is the show IP interface brief. And the reason I added the exclude
unassigned is that I've got a lot of additional interfaces here on router 2. And I just want to focus on
the interfaces that have IP addresses. So there's our serial 2/0. There's its IP address.
00:02:47
And here is the layer 1 and layer 2 status. So layer 1 is up, layer 2 is down. So let's make a road trip
out to the branch office router. And on the branch office router, let's do a show interface for serial
2/1. And in the output here, it's showing us that layer 1 is up, layer 2 is down, which is again a
problem. We have the encapsulation of HDLC, and that also is a problem.
00:03:12
There's nothing wrong with HDLC being used as a layer 2 protocol for encapsulation, if the other
side is also using HDLC. But what we have here is this side is using PPP, and R3, the branch router,
is using HDLC. We have incompatible layer 2 protocols. Either we can set them both to HDLC, or

set them both to PPP, but they have to match each other.
00:03:37
And while we're at it, we can also go ahead and look at the bottom just to verify that the service
provider's link is working for us. So all of these indicators here are representative that the circuit
from the service provider-- the WAN circuit, the serial link-- is up and operational.
00:03:53
Because all of these indicators are indicating up. So to fix the encapsulation, we're going to go into
configuration mode on this Cisco router. We'll go into interface serial 2/1, and we'll simply tell it
that we want the encapsulation to be PPP. We'll press Enter.
00:04:08
And just for good measure I'm going to do a shut down. This isn't required, but it wasn't working
before, so doing an administrative shut down on an interface is not going to lose any functionality.
And then I'm going to do a no shut down. And that, by the way, is how I taught my Cisco dog to
stand up.
00:04:25
I use the command no sit, and it stands. Well, in a Cisco environment that's how you bring an
interface up, is by using the command no shutdown. And so now that that interface is up, let's take a
look and do a show IP interface brief. And here we have serial 2/1 on this router, and now it has a
status of up and up.
00:04:44
And it do a show IP route rip, that will show us our RIP-learned route. RIP is one of our dynamic
routing protocols that we can use to learn and exchange routes with other neighboring devices. And
check it out, R3 has learned them all over the serial 2/1 interface, which implies-- if the routing
protocol is learning information on that interface, it implies that we also have connectivity over that
interface over to R2. So if we did a ping, for example, over to 10.1.0.1, which is an interface over
here on R1-- and in fact instead of doing a ping, we could do a trace route.
00:05:19
So on Windows it would be trace rt, and on a Cisco router it's trace route. And let's do a trace route
to 10.1.0.1, and that should show us the full path between R3, the branch router, an R1. So as we
look at the path here, the first hop was 10.5.0.2, which is the IP address on R2 serial 2/0 interface.
00:05:40
The next hop was 10.4.0.100, which is the firewall's interface. And that's because our firewall is
being implemented as a layer 3 firewall. So it shows up as a routed device in our network. And then
the final address is 10.2.0.1, which is an IP address are R1 owns. So great, we troubleshot our WAN
connection, and it was due to incompatible layer 2 protocols being used between the two routers on
each side of that WAN serial connection.
00:06:07

Now, there's lots of other things that could also cause problems or issues with WAN connectivity.
For example, maybe we have loss of internet connectivity. For example, if this site, this branch
office, if the way it gets to the internet is over the WAN connection to router 2, and then the traffic
is then routed out to the internet.
00:06:26
If we lost this WAN connection, that would also be a reason why we're losing the internet
connection. Many companies, if they have WAN connections in place, for example, between the
headquarter location and a branch office, they might also have a separate service provider just for
internet access.
00:06:40
And that way they could use a virtual private network as a backup, in the event that their primary
WAN connection fails. And as we were troubleshooting R2 and the branch router 3, if there were
interface errors on an interface that were excessive, that could help us zero in on focusing on the
problem.
00:06:58
For example, if there's no errors anywhere on R3 or R2, and they could both connect to each other,
then maybe we have a routing issue where maybe router 2 isn't advertising routes over to R3. So in
that case, the link would be fine. The WAN connection would be fine.
00:07:11
But the functionality isn't fine, just because router 2 and router 3 aren't sharing routes via RIP or
OSPF appropriately. Another challenge we could have in wide area network connectivity is
something called split horizon. And to demonstrate that we need yet another branch office.
00:07:26
So we'll say this is branch office number one, and we'll create branch office number two. And what
we could do is we could use, for example, the same service provider and the same physical
interface, and actually have a technology like Frame Relay that we're using to connect between
router 2 and router 3, as well as between router 2 and let's say router 4. And with Frame Relay,
behind the scenes there's something called a permanent virtual circuit.
00:07:51
It's a logical path, if you will, between the routers. So between R2 and R4 there's a permanent
virtual circuit using the Frame Relay service provider. And between router 2 and router 3, there's yet
another permanent virtual circuit. But at the same time this cloud, the entire connection between the
routers is, for example, one subnet, maybe the 10.6.0.0/16 network. And if you're saying Keith, a
16-bit network for your WAN connection? You're wasting a whole bunch of IP address space.
00:08:21
Let's go ahead and make this a /29, and then we're not wasting so many IP addresses for a network
that only needs three IP addresses, one for R2, one for R3, and one for R4. Now, the problem that a
topology like this incurs regarding split horizon is that protocols like RIP Version 2 have some

rules.
00:08:39
And one of those rules is split horizon. And split horizon says, if a route or a network is learned on
this interface, let's call this interface B, and let's say the route is 172.16.0.0/16. If you learn about
that route, via RIP for example, on this interface, don't bother advertising it back out on that same
interface B. And that's what split horizon does.
00:09:02
Effectively, anything learned on a specific interface, don't bother advertising it out on the same
interface. And in a typical ethernet network, that is not a problem. However, in this WAN topology,
check this out. If the branch office has network 10.7.0.0/16, and it advertises that down to the
headquarters router, router 2, and router 2 learns about it on the serial 2/0 interface-- split horizon,
by default, is going to say, well, I learned about the network 10.7 on this interface. Split horizon
says I shouldn't advertise it back out on that same interface.
00:09:36
And as a result, R3 will never learn about the 10.7 network, because this hub router at headquarters
site isn't advertising it back out off of that same interface serial 2/0. To solve it, we could just
disable split horizon on this interface and tell router 2, ah, by the way, if you learn routes on this
interface, please advertise it back out on the same interface.
00:09:58
And as a result R3 would then start learning about that 10.7 network. Another challenge that might
come up is DNS, domain name system. Bob decides that he wants to access this web server. Maybe
that web server in DNS is www.acme.com. And so Bob opens up his browser, plugs in
www.acme.com,
00:10:19
and he cannot get to that server. So he's frustrated by that. He doesn't call anybody, but that night he
goes home, and from his house he opens up his browser. And he goes to www.acme.com, and it
works no problem. And what could be happening is Bob. Maybe Bob's internal company is using an
internal server for DNS, domain name system.
00:10:40
So when Bob is at this branch office and has an IP address assigned through DHCP at the branch
office, which includes information about a default gateway and which DNS server to use, maybe
Bob is told to use this DNS server. And this DNS server has, for whatever reason, the incorrect
information about reaching these servers.
00:10:57
Maybe internal DNS server is referring to internal addresses, which Bob can't reach because of
routing issues. Or maybe the DNS server is pointing to global or external addresses before they're
NAT'd, and because Bob is trying to access them from within the internal network, the firewall isn't
allowing that access.

00:11:13
And as far as troubleshooting a DNS issue, what is the command that you and I would use from a
Windows computer to identify and verify whether or not DNS is working? What is the tool? Starts
with N. And if you're saying, Keith, I got it, it's Nslookup, you would be absolutely correct.
00:11:32
And that's a fantastic way to rule out whether or not the DNS is working. If you can run Nslookup
and do a name resolution to an IP address, at least we know the DNS resolution is working. Another
telltale sign that DNS is not working is if we have an IP address of a server, and we can connect to
it via the IP address, but we can't connect via a name.
00:11:51
That also points to DNS as a possible problem. And yet, here's one more scenario that might come
up. In many companies, we use proxy servers. In fact, this firewall, as part of a unified threat
management system, may be operating as a proxy. Or the proxy could be a separate physical or
logical server on the network.
00:12:10
But with a proxy it would work something like this. So here's Bob. Bob gets around, doesn't he? He
was over here at the branch, now he's at headquarters. Bob's browser may be configured to use a
proxy. So whenever Bob goes out to the internet, in his proxy settings in his browser it says, oh, use
proxy1.acme.com. And what that would cause to happen is Bob's computer would actually make the
request over to a proxy server, who could then fulfill the request on behalf of Bob the user.
00:12:36
And the trick is, to get to proxy1.acme.com, we have to have a correct DNS resolution in our
company that says, oh, proxy1.acme.com is this IP address, the IP address of our proxy server. And
as an example of a problem, let's say this proxy server is being replaced.
00:12:52
So the techs come in, and they implement a new proxy server, and it is proxy2.acme.com. And of
course, before deploying a new proxy server, they've tested that in a test environment. They're sure
it's good. They put proxy2 into the network, they train the browsers either manually or through
group policy that they should now be using the proxy server called proxy2.acme.com. Bob fires up
his browser, tries to connect to www.cbtnuggets.com, and anh, nothing.
00:13:21
And one of the reasons for that could be that Bob's computer is trying to go to proxy2.acme.com,
but maybe we never updated DNS to make sure we had name resolution inside our company that
had a mapping for that new proxy server. So in testing that, we could use Nslookup and verify
whether or not proxy2.acme.com is resolvable to an IP address.
00:13:44
And if it isn't, that would be another example of a DNS issue. If our WAN connectivity is using

something like microwave, or some other type of wireless technology, if there's interference with
those signals, that could also cause a degradation or a loss of service regarding our WAN
connectivity.
00:14:00
In our troubleshooting we did at the beginning, if our router configurations are incorrect, which they
were, on either serial 2/0 or 2/1, and as long as they're agreeing with each other and have the same
layer 2 protocol, they would work fine. And besides just the serial connection, we could also have
issues regarding routing protocols, or access control lists, or other elements that may be preventing
WAN communications between the two sites.
00:14:25
And CPE is an acronym that stands for Customer Premise Equipment. That is equipment that is
physically located at the customer location. So we might have a Smart jack or NIU. NIU is a
Network Interface Unit. It's also very likely that the Smart jack/NIU would be the demarc between
the service provider who's providing the link and our gear.
00:14:46
So that's where the service provider could terminate their circuit, at this Smart jack. And it's called a
Smart jack because it has some electronics in it that we could use for testing to help verify is it the
circuit from the provider that has the problem, or is it us, the customer, and our gear? And demarc is
simply a shortcut name for demarcation, a separation between the service provider stuff and our
stuff.
00:15:08
And often, with a Smart jack there will be an option for applying a loopback. Now, the word
loopback has several different applications. In IP version 4, we have a loopback address, which is a
logical layer 3 IP address that starts with 127 dot anything. 127 dot anything are all loopback
addresses. Every IPv4 router on the planet believes that anything that starts with 127 is itself. Also
on a router, such as a Cisco router, we can create a logical loopback interface.
00:15:40
And this logical loopback interface is just a make believe layer 3 interface that we can assign an IP
address to. And oftentimes, we'll use loopbacks on a Cisco router as we're implementing some fault
tolerance schemes. Or if we want to test reachability, we could simply create a loopback interface,
assign it an IP address, add that as part of a routing protocol, just to verify we have connectivity
between that interface, that loopback interface on a router, and some other destination.
00:16:06
And then, related to wide area networks, we have testing that could also use a loopback. And the
purpose of a loopback back for the WAN testing would be to take router 2 out of picture. So without
requiring on any of the circuitry or interfaces of router 2, we could logically put this loopback in
place.
00:16:22

Normally it's done at the Smart jack itself. And because the Smart jack is a smart device, it's also
possible that it could be electronically enabled. And with that loopback applied, the service provider
could then do testing on their circuit without any variables being provided based on the
configuration of router 2, which is managed by Acme Incorporated.
00:16:41
So I think it's better that the word loopback could be used in various different contexts. And that
way, if the word shows up, loopback, we can look for the additional context where that loopback is
being used. And part of the equipment that terminates a wide area network connection, a serial
connection, is going to be a CSU DSU, you a Channel Service Unit Data Service Unit.
00:17:00
In the old days, those were external devices. Nowadays, those are usually integrated as part of an
interface on a router, such as a Juniper or Cisco router. And if we need to take the circuit that's being
provided by the wide area network service provider and move it, maybe add the router or some
other device that's several hundred feet away, we might have to use a line driver or a repeater if
we're ever sending a signal further than it was originally intended.
00:17:24
Because wide area network communications are generally not free, at least not to the companies
that are paying for them, it's very likely we're going to have policies in place regarding the types of
traffic that are allowed over that WAN link, and also prioritization.
00:17:38
So if we have latency-sensitive applications, like voice and video, that are being used in real time,
we would want to use QoS, and possibly traffic shaping, to prioritize and make sure that that traffic
gets across the link. While other traffic that isn't as sensitive to latency and delay can be either
dropped and have those applications retry again later, or have them pushed to the back of the line.
00:18:00
And all these aspects, including throttling and blocking, what the utilization limits are going to be
for the WAN connectivity, as well as what is fair use, those should all be specified in policy, and
then complied with. Now, in my home network, I also a fair access policy that I've agreed to with
my service provider.
00:18:17
So what they've said is I've got a limit. I thinks it's 400 gigabytes per month of usage. And that's
their fair access policy for me, based on what I'm paying them for the service. And regarding this
last item, I'm reminded of a sign, it was a joke sign that I saw.
00:18:34
It was in a restaurant, and it said, "if you think the waiter is rude, you should see the manager."
Well, for wide area network connectivity, if we have fairly limited bandwidth compared to the high
speed local area network speeds that we're used to, we should see satellite.

00:18:49
Because that's one of the worst latency offenders regarding WAN communications. And it's also
why we wouldn't go to satellite communications as our first option for our WAN connections, due
to the latency. And also, as we take a look at price per gig, the cost is much more efficient when
we're using other WAN technologies.
Policies, Procedures, and Safety
00:00:00
Policies, procedure, and safety. Let's begin. Back in the mid '90s when I worked at Paramount
Pictures, I became friends with the safety officer on the lot, and let me tell you what, this guy could
go anywhere he wanted to. There were closed sets, at least at that point Star Trek were closed sets.
00:00:18
You couldn't have strangers in that set. However, if you're with the safety officer, and you're a guest
of the safety officer, you could get in. So I hd the opportunity to meet many of the captains of Star
Trek, and it was a boatload of fun. Safety is a huge concern.
00:00:32
So in this Nugger I wanted to chat with you just for a few moments about some of these acronyms,
and some of these functions. Starting off, we'd want to have security policies at the company and
have our employees agree to them. So an employee knows what is expected, what they're allowed
to do, what they're not allowed to do, and they agree to that on paper.
00:00:50
Or perhaps digitally sign to agree. And that should also include the consent to monitoring. So if the
company is doing video monitoring or audio monitoring, or both, the employees absolutely have to
be aware of that before the monitoring is done. There should be policies in place regarding the
network and acceptable use of the network, what's expected of the employees.
00:01:12
That's what an AUP is all about. That's an Acceptable Use Policy. For example, if a child is going to
school, it's very likely that that child and that child's parent are going to have to sign an acceptable
use policy that they agree on what is allowed and not allowed when they're using a school
computer.
00:01:29
That same concept applies to businesses as well, and there's a lot of documentation in business.
That's because if there's agreements that are made, if they're not in writing, they're hard to enforce.
So a written agreement signed by both parties is a very common thing in business today.
00:01:44
And some of the documents that we might be using in our businesses would be, for example, an
SOW-- that's a Statement of Work. If we're going to hire a company to come in and do some work
for us, the statement of work would detail things such as what's going to be done, when it's going to

be done, and what's to be expected.

00:02:01
Because it sets a clear expectation for both parties of what to expect. And if there's a long term
service that's being set up between, for example, two organizations, or a business and a vendor, they
might set up a master service agreement. That's what MSA stands for.
00:02:16
So once the MSA is set up, which might detail, for example, how long it's going to take to get paid,
and what's authorized, then as individual projects arise, instead of having to write out full contracts
for all the details for all these projects, they could refer back to the already agreed to MSA, the
master service agreement, and that could help expedite and speed things along as each of the new
projects comes up.
00:02:38
Another type of agreement that could be set up between two parties is called an MOU, which stands
for a Memorandum, or Memo of Understanding. So maybe two companies are going to be working
together, and they want to have some details put on paper regarding guidelines regarding their
interactions.
00:02:55
Now, as the companies get more serious on a project, they might want to take further steps and have
further agreements to lock down the details of any kind of joint projects. And perhaps the
memorandum of understanding is the first step towards that. And an SLA stands for a Service Level
Agreement.
00:03:11
For example, let's say we hire a service provider for our WAN connection between our headquarters
location and our branch offices. And as part of that, they may guarantee us a certain level of service.
For example, we are up 99.4% of the time, or we'll guarantee you a certain amount of throughput.
00:03:30
Or we'll guarantee that your packets and frames will arrive with a maximum latency of, for
example, 500 milliseconds or less. So it's great to have those as an understanding of what is to be
expected from a vendor, or from a company, and the SLA, the service level agreement, is spelling
that out.
00:03:47
Now, because electricity is so important for our digital world, it's important that we not only have it,
and then for critical systems we'd want to have fault tolerance that we've previously discussed, but
we'd also want to make sure that iit's properly implemented.
00:04:00
And part of that is to make sure that we have proper grounding for all of our electrical systems. And
a good way to help verify that is to only use certified electricians to either implement or to upgrade

or troubleshoot any kind of electrical problem. ESD stands for Electrostatic Discharge.
00:04:17
I remember my first time back in the '80s when I completely fried a computer. It was a PS2, back in
the day. That was the cat's meow. I think it was a PS2 model 60, or model 80. It was a tower
computer, and I had brought it home. I was working at Blue Cross of California at the time, and I'd
brought home this computer because I was going to be doing some work on it, and I put it on a
carpeted floor, and I had the keyboard and the monitor all set up.
00:04:44
And I walked over to it over the carpet, I touched the keyboard, and there was a big enough
electrostatic discharge that I could see the arc off my fingertip, and that went through the keyboard,
through the cable, to the motherboard, and it caused the failure of the computer.
00:05:00
So it was kind of a bummer the next day, bringing that computer back. What happened, Keith?
Well, I kind of shocked it. But when working with any type of exposed electronics, we want to
make sure that we are not going to fry anything by doing proper grounding.
00:05:14
And one great way of doing that is by using a wrist strap, or making sure we touch something metal
that's grounded before we touch sensitive electronics, which also should be grounded. So if our
body is grounded and we're touching devices that are grounded, there shouldn't be the opportunity
for an electrostatic discharge.
00:05:32
And it's also important that we manage the air as well. We want our humidity to be in a sweet spot.
We don't want it so humid that we have condensation, and we don't want it so dry, because the
dryness can promote things like ESD between a human and an electronic device that was not
expecting a huge surge of electricity through static discharge.
00:05:52
So HVAC is an acronym, and the acronym stands for Heating, Ventilating, and Air Conditioning.
And as part of that regarding safety, we'd also want to make sure that if there's a fire in the building,
that the HVAC system is smart enough to go ahead and not take, for example, smoke from one area
of the building and pump it into the other areas of the building.
00:06:12
So our alarm systems for fire very likely are also going to be tied into our HVAC systems. And
regarding installation safety, you know, lift with your knees, team lift, all that good stuff. Make sure
you know how to use the tools appropriately, make sure there's adequate training.
00:06:26
Don't leave stuff where there's a tripping hazard, don't place stuff that could fall over or tip over,
because a safety isn't just for yourself, it's for your co-workers as well. If we're working with

chemicals or other possible dangerous ingredients, there is very likely an MSDS required by law for
those products.
00:06:44
MSDS stands for a Material Safety Data Sheet, which explains in detail the proper handling and use
of that product. In our buildings we should have well communicated emergency procedures, and
they should be practiced periodically to make sure that they can be followed, and that they can
work.
00:07:01
So things such as an alert system to let people know there is a fire or emergency, I have been in
buildings before where the alert goes off, and everybody just stands around. It's probably a drill. If
there really is an emergency, I would really like to get to a place that's safe.
00:07:17
So as part of getting out of the building, there should be diagrams indicating where to go for exits.
And that would also apply to our fire escape plan. So many of these items are referring to
understanding and being able to follow the correct exit signs to get to a safe location, and the fact
that the building should have those in place.
00:07:34
Now, one of the tricky parts is doors. If you are in a secure environment and there is an emergency,
you should be able to get out. That is the bottom line. Let's imagine that we have doors that lock
electronically, and for example, to get into a building or through a door, we get our badge, we get it
close to the proximity reader, and it unlocks opens the door for us.
00:07:57
Well, in the event that there is a fire or an emergency, we may want to decide to have our system
have fail open doors. Now, the benefit of having a fail open system is that the humans can still go
through the doors, and that's good. If we need to go from one area to the other because of an
emergency, we want that ability to happen.
00:08:14
Now, in the second breath, it's also a possible security breach as well, because if there's an
emergency and the locks are no longer restricting access through a building, we're accepting that
additional risk. The other option could be to do a fail close.
00:08:29
Or if there's a failure of the system, the doors fail to a closed position. Closed meaning locked
position. And in the event there wasn't a manual override, for example, from the inside that could
effectively trap somebody inside of a building. So it's not as safe for the human element, but it is
more secure because in a failed situation, the doors lock.
00:08:50
The door is closed. At the end of the day, if there's an emergency and or there's a disruption to the

system, we obviously want to make sure that all of the humans have the ability to exit and get to a
place of safety. And if there is a fire, and let's say there's a fire extinguisher somewhere nearby, not
every fire extinguisher is built for every type of fire.
00:09:09
So you'd want to have some knowledge regarding the type of fires that you might see, and the type
of extinguisher that we could possibly use. And in a data center, it's also very likely they we're using
some type of a chemical agent that could put out the fire.
00:09:23
Back in the '80s we used halon. And that-- now in the 21st century, halon is a thing of the past. It
wasn't very environmentally friendly, and now we have some newer and better chemicals that can
put out fires without using water. Because water and computers, that's a really bad mix.
00:09:39
We want to avoid that when possible. So we'll have fire suppression systems in our data centers that
are using chemicals instead. 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.
Change Control
00:00:00
In this Nugget, you and I get to take a look at some really great ideas, regarding how we can
manage change using Change Control Procedures. Let's begin. I can remember back in the early
'80s when I first got into computer networking, and it really was the wild frontier for the local area
network side.
00:00:19
However, we were starting to integrate more and more with the mainframe folks. And those guys
had some really solid structure. They would have a weekly Change Control meeting, and I learned a
lot by just watching those groups. And I also was forced to do a lot more with Change Control once
we had tighter integration between the mainframe and then delivering the contents via local area
networks.
00:00:43
And I can still remember my early frustrations with that. It was like, hey, I'll just go make this
change. And they're like, no, no, we're not to make that change right now. We're going to talk about
it. We're going to discuss it. And we're going to make sure that the change is correctly done and
documented.
00:00:58
And although I make a little bit of fun of that now, having proper Change Control can save your
life. And it can protect the organization from unnecessary downtime. So some of the elements
inside of Change Control would be documenting on paper or electronically the reason that we're
going to make a change.

00:01:16
Is it an update? Is it a fix? Is it a correction? What is the purpose? And anytime we're going to
change, if it's possible, we want to practice that and verify that and validate that change in a test
environment first that is completely separate from our production network.
00:01:32
That way, when it comes time to actually implement the new thing, whatever it is, we don't have a
whole bunch of surprises, regarding how it installs, how it behaves, or whether or not it causes a
security problem because we'll test all that in a test environment first.
00:01:46
And then, as part of the change request form that we would fill out, we would include the
configuration procedures, which devices are we going to be working with, what is the exact
configuration that we're going to be changing. We're going to specify what the rollback process is, if
we need to go back to the prior version.
00:02:03
For example, let's say our Change window, our Change Control window is from 11:00 PM till 2:00
AM. And we know that if it doesn't go well, it takes an hour to roll it back. We'd want to document
that rollback process, what it is, how long it would take. Because if our Change Control window
ends at 2:00, and it is 1:00 AM, either the upgrade and update should be finished by 2:00 AM, or the
rollback should be completed in going back to the original state by 2:00 AM. And so by having the
rollback process documented, it also is going to help you and I in confirming that we know what
that rollback process is which includes making sure we have a good backup of the initial
configuration or the initial software.
00:02:44
And we have the knowledge of how to do a rollback if needed. And again, we've practiced that in
our test environment. So there's no surprises. We'd also want to have in our Change Control
document, the potential impact because nobody likes surprises. So if we're updating software and
that software behaves differently, we'd want to make sure, before we roll it out, we have proper user
training or at least user awareness, regarding the differences that are going to expect.
00:03:10
And there should also be proper notification channels and escalation, regarding the update of the
change. So if something isn't going quite right, who are we supposed to call and contact and
inform? We'd also want to communicate what the downtime is to the network users in advance so
that they can prepare.
00:03:27
So for example, as part of our Change Control process, we'd have a notification system that says, on
Tuesday between 3:00 AM and 4:00 AM, we're doing this upgrade, and there may be intermittent
connectivity or complete downtime for the network for that hour.
00:03:41

So a user who's expecting to use the network during that time could communicate that, hey, that's a
problem for me. Or that same user could work around the Change Control window. And then, all
changes should be approved by management. And what they would do is, they would get the
Change Request form.
00:03:56
And they would go down the checklist to make sure that everything has been addressed. And in
some environments, it'll be one team that's actually doing the documentation, regarding the changes
that need to be done. And it might be handed off to a completely separate team to implement the
update.
00:04:10
And the maintenance window is simply the window of time that we've communicated to our users
that the network maybe down or maybe impacted while we're doing the update or the upgrade. In
many companies, they often have a standing maintenance window. For example, maybe it's every
Tuesday from 1:00 AM to 4:00 AM. And then whether or not we need to use that Change Window,
doesn't really matter because we've given the users advanced warning.
00:04:34
So if it's Wednesday, and we have an update or a patch, we'd need to decide, can it wait till our
maintenance window, which has already been communicated and agreed to, or is it urgent? Do we
need to test this right now in our test environment and roll it out immediately? And in some cases,
for example for huge security risks, we might have to do it sooner than our normally scheduled
maintenance window.
00:04:55
We've already touched on the fact that we should notify anybody who's going to be impacted by that
change. And any change that we do, besides the testing and the verification, once it gets rolled out,
there also should be very good documentation, regarding that change.
00:05:09
If it was a router or a switch configuration that was changed, it should be documented. If we're
adding on new devices to the network, for example, we're adding a new switch or we're adding a
new server, that should be documented. Or if we're moving gear, of course, that should also be
documented.
00:05:24
And when there's changes that happen on the networks, the key is, don't act alone. Make sure that
any change that happens that we use the buddy system. And a great way to do that is to make sure
that we're complying and following through with a Change Control System.
Racks, Labels, and More
00:00:00
In this Nugget, I'd like to chat with you a little bit about Rack options that we have, as well as some

details regarding labeling that, if used, can save us a boatload of time. Let's begin. Regarding the
Racks that are in our IDS or Intermediate Distribution Frames and down here in the Data Center,
the main distribution frame, Racks come in various sizes and flavors.
00:00:21
And the intent is, of these Racks, are to provide organization for us, so in some of these Racks we
could have Patch Panels, as well as servers that are rail-mounted and they slide into the Racks.
Switches and routers could also be slid into these Racks.
00:00:35
And depending on whether we had two-post or four-post really depends a lot on how tall the Rack
needs to be, how much gear will it be holding. And a freestanding Rack in a corporate environment
is usually a terrible idea, because of the safety hazard. If it's freestanding, it's not bolted to the floor,
and it could tip.
00:00:54
That's just bad news, especially for a Rack that we're going to be sliding things into and out of, or it
has a Patch Panel on it which we're going to be plugging cables into. And speaking of cables, it's
also a great idea if we have cable management systems that can protect our cables as they're going
through the building, whether we're talking about the vertical runs that go between the floors and
down to the MDF, or the horizontal runs that go out to the workstations and other devices on those
floors.
00:01:20
So having the cable trays can protect those cables by keeping them off of the floor. And that also
helps protect the cables including fiber optics from being bent excessively, which could damage the
effectiveness of the cable. We also make sure we have proper airflow for our computing devices.
00:01:36
And normally, in the Data Center, there'll be a hot row and a cold row. So if this is the top view, for
example, of our racks of equipment, maybe all the gear on this rack are placed so that all the heat
from those devices is being sent out into this row.
00:01:50
That would be our hot aisle or our hot row. And then, in this rack, we could have all the devices
positioned, so that their fans are blowing all their hot air out this way to the hot aisle. And then over
here, we have a cold row. And then over here, we could have another hot row or a hot aisle.
00:02:05
And once again, we'd have all the exhaust, the fans, pointed in that direction from our computing
devices to send the heat that direction. And then we get vent it up, and out, and away from the
facility. And there's a lot of really creative ways of cooling data centers these days.
00:02:20
And if we're using air for cooling our systems, having the hot and cold aisles, and making sure we

have proper airflow for each of our computing devices, is definitely something that we want to
have. And a big part of that, of course, is to also have device placement in those racks so that the
fans are all blowing in the correct direction.
00:02:38
Now also, regarding these racks, it's very likely that to get to the area, if this is the data center, to get
to these devices, there should be some kind of a keyed entry. So maybe you have a badge or a card
that we get close to a proximity reader, it identifies us.
00:02:53
If we're using multi-factor authentication, maybe we also have to put in a pin on a keypad along
with our badge to get entry in. But we could also have security on the racks themselves. For
example, some type of a locking system on these racks so that even if we do physically get close to
the racks, we still have to have some additional access to get to the competing equipment in those
racks.
00:03:14
It's also very likely in a data center that we're going to have surveillance in place to record what's
physically happening in that space. For example, who is physically there in addition to the logging
we can do at the door as people come in or go out of the data center.
00:03:28
So Rack Security would be an additional step we could take. In addition, we'd also make sure that
the racks are securely installed, so that they don't have the ability to tip over. And that would be
another aspect of Rack Security, physical security. And the closed circuit TV would be an example
of Rack monitoring.
00:03:44
We could also have sensors on the Racks themselves, that when they're opened, it also documents
the fact that the rack was opened. Another factor that we could also have regarding Rack
Monitoring is monitoring the heat. So if the heat, all a sudden, gets inordinately high, it could set off
alerts.
00:03:59
So we could take action to correct the problem, before the heat starts doing permanent damage to
our equipment. The last piece I'd like to talk with you about here, is regarding Labeling. Labeling is
so important. If you and I walked into a wiring closet, and it just looks like spaghetti, there's just
hundreds of cables that are all plugged into Patch Panels with RJ45 terminations, and nothing is
documented.
00:04:22
That is really, really a bad situation for troubleshooting. It's also really bad for adding new devices
to the network. So there should be documentation on the Patch Panels indicating where they lead to.
For example, this connection on this patch panel leads out to office 1B., or 1C, or 1D, or wherever it
goes to based on the floor plan.

00:04:42
It would also be helpful to build in naming conventions for our labeling. For example, if the Help
Desk got an alert that a printer that was named HP 11D was having an issue or an error, if we
integrated that to mean, for example, let's say it's an HP, a Hewlett Packard laser printer.
00:05:01
And that it's on Floor 11, and it's just outside of Cube D or Office D, by integrating into the names
of our devices the physical location of those devices, that is also extremely helpful for everyone
involved including our users, who may want to find a printer.
00:05:18
And as circuits are coming in from our service provider, we would want all of that documented, so
it's very, very clear what this cable does, where it goes, what it's used for. So Port Labeling, Circuit
Labeling, System Labeling, because the person, my friend, that's going to help all that
documentation and the labeling, the person that's going to help is you.
00:05:37
So my recommendation is, create and maintain a very accurate documentation system, including the
labels and be meticulous about it. If you're going to add a connection, or you're going to plug
something in and it's not documented, take a moment, add that label.
00:05:52
Because for every minute that you spend in the organization, in the planning, in the documentation
labeling, is very likely going to save you hours. 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.