All language subtitles for 03 - Cisco Foundations - Speaking the Language of the OSI Model-eng

>> You don't have to be in the network world
very long before you start hearing people say

things like, "It sounds like
that's a Layer 2 issue,"

or "Did you check the Layer 3 routing table?"

or "That's definitely a layer 8 issue."

So all of this goes into the
concept known as the OSI model,

which really defines networking
as we know it in today's world.

So I want to unpack in this
nugget what is the OSI model,

not just - not just memorizing the layers.

Anybody can do that, but understanding the
layers, and then it's even a step beyond that,

to be able to say, I know how those layers
impact networks and how communication works.

And I added, "Is there a conspiracy here
too," because of the last nugget when I talk

about Cisco inventing the router -

there's a little conspiracy here,
but I'll try to keep it low.

Then we'll get into the layers themselves of
OSI, what adds what, where it's being added,

and then how network devices communicate, how
does this impact what we saw in the last nugget,

which is the switches and the
routers, where do they operate?

How do they work?

All of that will be exposed here.

But let's start off with what it is first.

So what is the OSI model?

A standard architecture defining
network communication.

Rewind your mind back in time
to when IBM ruled the world,

all the computers were quote unquote
"IBM compatible" if you will.

If it was left to vendors to come up with these
standards, IBM would say, we have the IBM model,

and all other computers and network
devices have to follow this model,

but let's say Dell comes along or
Apple comes along and they say,

"We want to create an Apple model."

And so now you've got this issue where,
Apple computers talk to Apple computers,

and IBM talks to IBM and Dell talks to
Dell, and there's no kind of standard

that they all can apply to to
allow cross platform communication;

thus, the OSI model was born.

Now, the OSI model in itself is not a standard,
like you can't go into the Control Panel

and say, "Oh, look, there's the transport
control panel in my Windows device."

It's a framework -- I'm going
to jump straight down here --

it's really a standard to create standards.

And without diving into everything
we're going to explore

through this entire series,
let me give you an example.

The network layer defines a type of addressing.

Actually, you know what, I'm
going to go even lower than that.

Datalink layer also defines addressing,

which we're going to find two different
flavors of addresses that we run into.

In the Ethernet world, we have
something known as Mac addresses.

Now, let's say that somebody
comes up with something new --

and let me before I go there
-- the Mac is a standard.

I mean, there is a standard written for how Mac
addresses should look, how they should be used,

how network cards should handle
them and be applied to them

when they're created at the manufacturer.

I mean, there is a whole standard.

So it's not like there's a Datalink standard

that all network card manufacturers
have to adhere to -no, no, no.

There's a Mac or there's an
Ethernet standard that exists

at the Datalink layer that
all the vendors adhere to.

So again, this is kind of a
standard to create standards.

But if down the road, let's say,
I'm sitting here talking to you

and all of a sudden, I'm like, wait a second.

I pause the recording and
I go, "I've got an idea.

I need to create the Jeremy
standard of communication."

I grab my paper and start scribbling
down notes - that's it, it's brilliant,

I've got an improved network
performance 500 times over.

Bam, and I publish my own
little standard right here.

That's totally fine.

I could come up with the Jer standard,
that would be able to plug-in there

at the Datalink layer, and if the world accepts
it, and all the network card manufacturers like,

why didn't we think of that before?

Let's all jump on board, and they
all apply to the Jer standard --

the beauty is we can change that out.

All the network cards could start being
remanufactured, go by the Jer standard now --

but all of these other layers
above it can stay the same.

Now, what's up there?

We talked about the Datalink, which is
really kind of almost network card level.

And what's up here?

Well, you run into things like IP or TCP --

combine them together and there's
your TCP/IP and as you go up.

So I could change out all the network cards in
the world, but never make a change to TCP/IP

at all, because those are
upper layers above that.

Does that make sense?

So again, it's not a network layer standard;
it's a framework to create standards

and IP is one of the standards
that have been developed.

So that's where I'll stop that discussion,
because we will really spend the rest

of the series exploring what standards are,
what they do, and how we can best use them.

So this is also a way to break
down network communication.

When I first started this nugget, I said, you
won't go long without hearing something like,

"Oh, that's a layer 2 issue,"
or "that's a layer 3."

It really helps you figure out
where's the problem in the network?

It helps with trouble-shooting, it helps
with a more modular way of thinking

versus somebody coming up and
screaming, "The network's down."

I mean, when you hear that immediately,
my mind goes to the OSI model.

I'm like, the network's down.

What does that mean?

I'm going, so what do you mean?

Can you not get on the Internet.

Or I always love it when my family calls,
they're like, "Jeremy, the Internet's down."

I'm like, "Oh, a panic, worldwide crisis."

The Internet's not down, it's the
connection to the Internet down.

So I start working through this
and I say, "Oh, okay, let's think -

so are you saying, it's a physical issue?

Let's just take my parents if they
call me -- "Oh, the Internet's down."

"Oh, okay.

Check your connection.

Is your cable - do you see lights on the back?"

Immediately I'm going to the physical layer.

And then I started you know, thinking through.

I'm like, "Okay, well, wait a sec,
if your connections are good" --

so again, I'm already starting to bite my
tongue because I'm like, "well, let me -

let me take a methodical, middle layer approach.

I'll do a ping and I'll do all this."

So it really helps us define instead of
screaming, "The network is down," we can go oh,

well, what about the network is down?

Oh, a Datalink layer.

Okay, there's something going
on with the switches.

There's something going on with
the routers of the network layer.

Again, really helps us to break it down.

It's never good without leaving
with a conspiracy, right.

It is a competing protocol to
see TCP/IP, or should I say,

was, because the competition is over.

And I shouldn't even say that.

The OSM model was not competing;
the OSI protocol was.

Most people don't know the OSI
protocol ever existed, but this model -

it wasn't just something somebody thought up.

They're like, "Hey, let's
just think of a model."

No, no, no.

they thought of the model to describe
this protocol, developed in 1977,

called the OSI protocol,
as a competition to TCP/IP.

The irony is - you remember VHS and beta,

the videocassettes before DVDs
came along -- which one was better?

Beta, right.

Which one won?

VHS did, except in the recording studios
and movie studios and things like that,

VHS won out in the consumer
- I don't know why that is.

It was the lesser standard,
but the consumer shows,

the Mafia got involved, I don't know, VHS won.

Well, same thing back in the day.

We had the OSI protocol and TCP/IP.

It's kind of like, oh, which
one is it going to be?

Well, ooh, looking at the addressing
of OSI it just was complex.

It was hexadecimal.

There was too many addresses.

It was like, wow, why would we
ever need that many addresses,

and thus, fate has a sense of humor.

TCP/IP was chosen, and now, TCP/IP has exhausted
its IP addresses, and we need TCP/IP version 6

to be released, which looks very similar to
the way OSI addressing looked way back in 1977.

So the funny thing about all of
this is not only was TCP/IP chosen,

which was the lesser protocol,
if I can say that.

But TCP/IP had a model of its own.

It's called the DoD model, Department
of Defense model, which people looked at

and they said, "That just isn't very good."

And so what they did was they took the model
of the better protocol and started using it

to describe TCP/IP communication.

Isn't that ironic for you?

Now we know what it is.

Let's take a look at what it does,
and understand this beautiful model.

First off, isn't that weird?

Here I am thinking, this beautiful --

most people are like, sunsets and
mountains, and I'm like ah, the OSI model.

Wipe the tear from my eye.

Top three layers - notice they're purple.

Bottom three layers, notice they're red.

The top three, the reason I changed
the color code on them a little bit is

because these typically happen
before the data leaves the computer.

Normally our network devices
don't care about that stuff.

I'm saying normally, but that
is kind of a blanket statement.

Normally our network devices are highly
focused on these bottom four layers.

And so when you're looking at this, you
go, okay, where do I really want the depth?

It's layers 1 through 4,
and that's the first thing.

That's why knowing the numbers are key.

It's numbered from the bottom
up, and if we got to get back,

you got to memorize the layers
-- but that's just the beginning.

The acronym I always remember is
please do not throw sausage pizza away,

because that would be a travesty.

So if you remember that, that will
be a good way to remember the layers.

But it also explains my somewhat of a joke, if
you want to call it that, that at the beginning

of the series where I said, a lot of
people might say, oh, it's a layer 8 issue.

Well, that usually is describing
the user at the terminal.

Layer 7 is where the OSM model stops, so there's
somebody saying, oh, it's a user problem.

So that's - if you haven't heard
that joke, you will before long.

So let's break it down.

Let me first off -- I'm going
to hit this in two ways.

One, I want to give you fly-by
description of what these layers do.

And again, the fly-by version, because
I know if I just kind of go, okay,

here's the laundry list, it's going to quickly
be forgotten - where I want to spend the time is

where we watch data being sent
between clients and servers,

and then we break it down one by one.

So let's go piece by piece.

First off, application layer.

Now, again, let me set the paradigm.

This is a standard of standards, right.

The application layer, it's not like
when somebody builds a computer, they go,

okay, I need to install the OSI model.

No, no, no, they install
standards from the OSI model.

So let's talk about the application
layer up top.

The application layer is what the application
itself interfaces with if it's network aware.

So let me define that.

Let's say you have an application
like Solitaire on your computer.

Not even going to look at the OSI
model, because you play it yourself,

unless you're playing it online somehow.

You're playing it yourself on the local
computer, so that's not an application

that would interface with this
layer, but World of War Craft would.

Half-Life, Counter- Strike -- whatever.

I'm just thinking of online
games, but let's go productivity.

Internet Explorer, Firefox, Google Chrome,
peer-to-peer file share transfers --

anything that is network-aware
interfaces with this.

So when you're an application writer, let's
say I or you decide to develop an application.

You're writing the code, this
is what my application does.

It's a putt putt golf application
that works on the network --

you don't have to worry about here's how
my application communicates to the network,

because there are well-known APIs --
application programming interfaces --

that are written at the application
layer for Windows or for Apple or for --

I should say OSX -- or for all the other
operating systems that are out there.

So I write my putt putt golf application
to talk to that API which says, okay,

I'm going to start this network communication.

That way it saves me from having
to write all of the code of like,

this is how you talk to the
network within Windows.

No, no, no.

Just let Windows do that.

They've written the APIs for you.

So the application layer is where the
application exists, and provides -

this provides network access
to the applications.

Presentation layer.

So let's say we've got an application.

It's sending some data down here.

The presentation layer generifies the data.

Yes, I just made that word up.

It turns it into well-known formats, like,
for example, if I'm communicating pictures,

I might store them in jpeg or gif or png format,
which is a well-known format that's understood.

So this is where a lot of our standards exist
for how to format things, htm, html, http --

those kind of things exist at
the presentation layer, html,

a generic language of formatting
web pages online.

You've got Java, you've got encryption --

there's a big one, encryption is
generic at the presentation layer.

And when I say that, I know
some people are like, what?

Generic encryption.

Say no such thing.

Encryption is secure.

Well, yes, it is very secure but it is
generically secure, as in you wouldn't be able

to surf the web securely and do online
bankings if there wasn't a generic

or well-known industry-supported
encryption standard

that anything could use, and it's very secure.

Now, I'll talk about how that is later
- is that going to be the series?

Maybe. That'd be fun to talk about --
how generic encryption works really well,

but that's all presentation layer.

Session layer, just, this
one's probably the most bland.

It starts and ends session, maintains to
make sure that the session is still active.

Creates session IDs in the operating system.

So this is all again, operating
system stuff, application stuff, okay.

So now we come to the transport layer,
the first real layer that defines -

this is dealing with the network,
because it defines how the data is set.

So right here your application will choose.

Now, again, it's not you saying I want
it to be sent this way or that way --

it's the application that people who write
the application say, I want this to be sent.

For instance, one example would
be reliably or unreliably.

That seems like an easy decision.

It's like, well, I want reliable.

Well, what does that mean?

Let me match this up to some protocols
we're going to see -- TCP versus UDP.

And I say, well, I always
want reliability, don't I?

Not necessarily.

What reliability says is I'm going to send a
packet, and I want the other side to receive it,

and to make sure that it receives it, I want it
to send an acknowledgement back to me saying,

I got it, so I know that that packet got there.

Well, I would say that's
huge for data applications.

You absolutely want reliability.

But what about applications like voice-over
IP, where you've got somebody talking

on the phone to someone else over here?

Well, this is real-time conversation.

If a packet gets dropped and maybe
there's a glip in the conversation,

there's no use in sending that at
a later time, because it's gone.

The time is past.

Or, like video, you're watching
video on your TV.

Almost every TV works over a network
nowadays, as you're watching movie on Netflix

or your cable provider's
streaming live media to you.

And some data gets dropped.

You might see the screen kind of get a little
jittery, if some data's dropped, but again,

there's no sense in sending that later,
so that would be an unreliable choice.

So for any real time communication,
unreliable's the way you want to go.

Also with this layer you have application
separation, which really deals with ports.

Yes, that's what it deals with, and that's
what we're going to talk about when I unpack.

I've got a live scenario, I'm like, I
just don't even want to dive into that.

So just remember, you run more than
one application and a time, right.

That's the job of the transport layers,

to keep all of that separate
for your network communication.

Now, we come down to the network layer.

This is where you have logical addressing.

So logical addressing nowadays, boils down
to IP addresses, but it wasn't always so.

Back in the day when I was in networking
and first learning networking myself,

there was protocols like IPX/SPX,
AppleTalk, Net buoy, I mean,

these protocols were widespread
and that was back in the day.

I used to be -- I think I still am --

a certified Novell instructor
that I haven't taught for decades

and I don't remember a thing about, but that's
- I mean, I remember back in the day being, dah,

IPS/SPX -- I can't even say it -- IPS/SPX,
it's the future, TCP/IP, who needs it.

So those were all gone.

Those were standards that are long since
deprecated and now everything is IP.

So a logical address to say, this
is where I want my data to go.

Causes a lot of confusion.

When I come down here and tell you that --

well, actually, the Datalink layer represents
the physical address, which is where I get

to say, this is where I want my data to go.

Wait a sec -- scratching a pad-- I will say
this, this has caused a lot of confusion

for a lot of people learning networking.

Well, what do you mean?

So this is telling your data where to go?

Uh-huh. And - and this is
telling your data where to go?

Uh-huh. But it's different.

There's a way of communicating within a network
that's different than communicating end to end.

Let me give you a brief example that
I think will really demystify it.

I've got my computer right here.

I want to talk to that server over there.

The way networks work, I can't just -- let's
say I want to send a message over that --

I don't know, add an entry to a
database or something like that.

I'm saying 50 people showed
up for a conference today.

So I type in 50 and hit the enter key,
so it's going to send the number 50.

Well, that's the payload.

That's the data that's actually being sent.

But I can't just -- it's not like you know,
finding Nemo, where I just take 50 and I'm like,

okay, go, Nemo, go, find your home.

I have to tell it where to go, so I'm going
to have to say, well, you're going to go

to the destination IP address of that server.

But unfortunately, it doesn't work that way.

Again, it's not like the fish where I
can just say, okay, now, go find you way.

No, no, no, I actually have to say, I
want you to go right here to this router,

because that router will know
how to get to that IP address.

Ah, okay, now we have a problem -- wait a sec.

I have to tell this number
50, we had 50 people show up.

I'm typing that in my database
program, 50, hit the enter key.

I have to tell it to go to this router,
because this router will know how to get

to the IP address of where I'm really going,
thus, now, we're starting to see the need.

Okay, wait a sec, we have two addresses,
one of them -- circle, circle --

has the ability to show me where
I go on my local area network --

the other one tells me where I go end-to-end.

So think of the logical addressing
is this is going to be how you get

to your final destination,
and that should never change.

That's my destination; that's where I'm
going to -- that needs to stay the same.

However, when we come to this
one, that's going to tell me how

to get there from this network's perspective.

But also remember, we have a network
here and we have a network here.

So this one may change quite
a bit on our little journey.

Again, more on that as we
start breaking this down.

Physical layer, this is where
we have electrical signals.

You get shocked.

This is where ones and zeros prevail.

We're actually sending data across the network.

If you hear somebody say, oh, it's a physical
layer problem, I mean, where does your mind go?

Something's broken, right, like
the cable is not plugged in,

or somebody kicks the network cord --
or I found this more times than once --

I have a network cable on the floor in my
office and I have a rolling chair and I just go,

[rolling sound], roll right over that
network cable, destroy the network cable.

So physical layer issues happen all the time,
so physical layer is just what it sounds like.

So now let's talk about this
from a practical sense.

I've got an online bank account, and let's
just say it is with BankofArizona.com --

I don't even know if there is such
a thing, but we'll make it up.

So I'm going to go to my online bank account
and transfer $50 from my checking account

to my savings account because
that's what I'd like to do.

So I log into the -- let's kind
of fast forward a little bit --

I log into the website, my user name, password
-- I get to the point where I say, okay,

transfer $50, so $50 is my transfer
-- from checking to savings.

And I type in the 50 and I click submit.

Okay, what happens?

First things first, I am using a browser.

It could be Internet Explorer, it could be
Firefox, it could be Chrome, down the list we go

through all the different web
browsers that I could be using.

those web browsers interface directly with
the application layer API, which says,

I have data to send across the network.

This is the data.

This is the payload, if you will, that
I'm saying, this is my $50 transfer.

So the first thing you know, this is
before it even leaves the application --

I'm going to format that into the
language that the web server understands.

I mean, over here, we have a web server.

I mean, it could be running IIS for Microsoft.

Could be running Apache from -- well,
it's Open Source -- Linux community.

It could be running Websphere from IBM.

There's all these different web servers that
are out there, and you might be saying, okay,

Jeremy, my God, what's your point?

Well, my point is look at this.

We've got all kinds of different web browsers,

and we've got all kinds of
different web servers.

What's to say that if I'm
using Chrome and looking

at an IIS-supported website that it looks right?

Or what's to say that if I'm using Firefox
looking at an Apache website, it looks right?

Well, that's because there's standards
that are created to presentation layer.

As a matter of fact, Microsoft is
the biggest bender of the rules --

not to throw them under the bus -- but with
Internet Explorer you'll come to some sites

with Chrome or Firefox and it's like -- an --

sorry, this is an Internet
Explorer only website.

Why? Because Microsoft has written
IIS in such a way for some languages

that only Internet Explorer supports it.

Now, those are becoming less and less and less,
because these other browsers are becoming more

and more popular where Internet
Explorer used to rule the world.

But all of this is handled
by the presentation layer.

We've got standards that things
should be written to on this side,

standards like active server pages,
standards like Java, standards like html,

standards like blah, blah, blah, blah
-- this list could go on and on --

jpeg pictures, generic -- we're at a bank.

This is obviously encrypted,
right, so encryption standards.

So right now, our web program is taking our $50
transfer and let's just say it's encrypting it.

It's formatting it in whatever the
web server has suggested that it uses,

to send that $50 transfer back over.

So moves down to session layer.

Now, session layer doesn't have much to
do here because it's already started.

We went to the website at some point, it stated
the session, maintains that session and so on.

Okay, now we come down to the transport layer.

Major action happening here
from the network perspective.

We have to send this $50
transfer across the wire.

First things first.

Do you think that this would be a good
one for reliability or unreliable?

All hands go up -- reliability, which would
be using -- choosing to use the TCP protocol.

I want to know when I click the Submit button

that that $50 transfer got
there, and it's happening.

Like I need those $50 to go into savings.

Maybe the crisis should be the other way.

I need it in my checking.

I need to buy something.

So we're going to choose the TCP
protocol, but then we go one step further.

TCP actually has a series of ports, matter
of fact 1 through 65,530, oh, is it 5 or 6?

It's 5. I had to check.

There's some things that are
6, some things that are 5.

So 65,000 ports.

Now, what does this mean?

Well, the port defines what applications -- kind
of think of it like a tag for your application.

So let's say it this way.

This server might be running the web server.

It might also be an e-mail server.

It might also be an online gaming server.

We don't know -- I mean,
Bank of Arizona, who's that?

Who knows what they could be running over there.

They could be running all kinds
of different services on there.

So I want to know, when my $50 transfer goes
across the wire, that it's going to be going

to the correct application on this side --

IIS or Apache or whatever web server
they're actively running over there.

And it doesn't end up going to their
e-mail server, which would say,

what am I doing with a $50 transfer?

The way I designate that -- and I keep
saying "I," I being the application

or I being the computer -- is by
putting a destination port on there.

So it just so happens that web servers
use two very common destination ports.

Port 80 is known as http.

Every time you go to a website, your
web browser is actually squeezing it --

like you type in Google.com, your web
browser's actually doing behind the scenes,

put a little :80 on there, so that when we go
to Google, we're accessing the web services

on the Google server, not email services
or any of the other services I rattled out,

but the web browser does that for
you; you don't have to know that.

The other one that it uses is Port 443, which
is https, which is what it would do in our case,

because we have a secure session,
encrypted session here with this web server,

so I would actually tag onto the front of
this, destination port 443, destination.

By the way, what I'm doing here, this
is a process -- notice encapsulation.

So when I'm sending this $50 transfer,
behind the scenes it's actually adding data

to the front of my little payload,
this is what I want to send.

But again, it's not Nemo.

We can't just say, go find your home.

We have to add all this stuff to tell
it where it's going and how it's going

and what it's going to do when it gets there.

That's all -- remember I said in the previous
nugget when I was talking about the speed

of the network -- this is the
overhead stuff that's being added

to every single packet that's
being sent -- it's encapsulation.

Now, wait a sec.

That tells it where to go on this
computer or this server over here,

but there's an often forgotten
piece, which is where it came from.

I'm not talking the IP address,
like oh, that's you, Mr. Computer --

I'm talking about the application
on that computer.

Chances are if you're like me,
you've got that ADD thing going

to where you've got the web browser going
to where you've got the web browser going

to your bank but you have
Pandora's open streaming music.

You've got the little -- what do they call it
-- the waste of time bar in Windows on the right

with the stock quotes, the weather --

all of these are network applications
that are constantly receiving data.

So when I send my $50 transfer to
this web server over here, saying,

I want $50 in my savings, and it comes back to
me, I want to make sure that my web browser,

Chrome or Internet Explorer, says, success!

Your $50 was transferred, and it's
not Pandora going $50 has been --

I mean, it wouldn't even understand it.

I want to make sure it comes
from the right thing.

So again, the application
adds a source port as well.

It's a dynamic port.

These are considered well-known.

Matter of fact, ports 1 through
1024 are all considered well-known.

Like, you can't touch those.

Nobody touches those ports for new applications

that they create unless they do all
these sophisticated applications,

because those are all well-known.

Up here, these are considered
dynamic ports, that Windows,

when I open Internet Explorer,
it's going to generate for me.

Matter of fact, I'm having a spontaneous moment.

Let's do this for a second.

I'm going to open a web browser on my computer.

Let-s just -- I've got Google
Chrome, right there.

And you know what, my home page is cbtnuggets,
which is what everybody's page should be.

Just by doing that, I opened Google Chrome,
it created a session with cbtnuggets.com.

Let's check the results.

I'm going to go here and go to a command
prompt and type in the command netstat.

netstat shows all the open
connections coming from my computer.

Now, I'm looking here, I'm
going, whoa, wait a sec.

I've got ec2 such and such,
I've got 80, going http -- what?

Huh? What is this?

How am I going to read this?

Well, first off, when I went to cbtnuggest.com,
which is my home page, this is not a website

that is just sitting on a server.

Everything from this is probably
spread across many different servers.

What you're actually coming to, if I could
draw -- and this is how most websites are.

When you go to a website -- actually,
here, this will help show it even better.

Let's go to the biggest waste of
time website in the world -- MSN.com.

Holy cow, the iPhone 5 is out!

That's something I have to look at.

I'm not going to pause the recording; I'm
going to finish this, because let's look at --

this is news of the day, by the way.

So MSN.com, I come here and I look, I go, okay,

this little butterfly, MSN,
this came from a server.

Matter of fact, if I go back here, and I hit the
up arrow, this thing will just scroll and scroll

and scroll and scroll and scroll, scroll for --

it's kind of hanging, trying to figure
out what name these are and all that,

but it will continue to scroll through all
kinds of different servers all over the place,

because we've got this Buy Stocks, this
little pop star joining XFactor, gossip --

this image -- these all came
from a different server.

If I scroll down, we've got the
NFL rookie, something or another.

This really -- MSN.com, if you
want to know, is just a framework.

Like the first server that
you hit, says, okay, this one,

this picture comes from this server over here.

This ad came from this server over here.

And oh, by the way, these scrolling
pictures on here, that was actually fed

by three different servers over here, so when
my Internet Explorer came here, it's like,

hey, I'm just wanting one session.

It got the feedback, no, you need to go
here and here and here and here and here,

and that's why we come here to the
command prompt, and it's still going.

It's still trying to find all the different
sessions that I'm using, because it's saying,

okay, well, I was sent to this server to
get a web page using http and this server

and this server and this server and this ser
-- notice, they all have this IP address:http.

Now, Windows is very kind in that it
hides -- it should actually say, port 80,

or right here it would say port 443 https,

but you can see that we're
just getting spider-webbed

to all of these different locations.

Now, that's the foreign address, that's the
destination, so that's where we're going.

On this side of things, I can see my computer.

This is me.

I have the IP address, 1723100.72.

Notice I've got :490, :49, :50, :50 -- all
of these are different source port numbers,

so when my web browser went to those websites
it actually got sent to many different websites,

and generated all of these different
unique source port numbers --

each packet would have one
unique source port number,

so when these web servers responded back,
my computer knows exactly where to put them.

So if we were to look - if we were to
talk to this computer and somehow be able

to peel this web page back, this tiger
right here would be able to say --

the tiger wouldn't say anteing but if we
could peel it back it would actually say,

65.55.239.146:http is where this came from.

And it came from the source in here of
this, so when tiger image got sent back,

my web browser knew exactly what application to
send it to and where to put it on the web page.

That comes into the web page formatting.

So that's the idea of port numbers.

So every single packet, my $50 transfer to the
bank, goes to a destination on the web server

but always has a source that
the web server talks back to.

Big layer, huh?

That's the transport layer.

Huge. The network layer deals with
the addressing, the IP addressing.

So I went to Bank of Arizona -- I
don't even know if there is one.

I went to Bank of Arizona -- oh, there is
one, great, Bankofarizona.com, nice and easy.

But behind the scenes, my command prompt is
freezing here, so let's open another one.

My computer used something called DNS.

www.bankofarizona.com, because
we work in terms of names

but computers work in terms of IP addresses.

So when I went to Bankofarizona.com
and got this whole thing going,

my computer found out that Bank of Arizona has
the IP address 21660188, and it filled that in

as the destination IP address
of where I'm going.

It said, I'm going to have the source IP
address of -- I forgot my IP, 172.3100.72 --

that's going to be where I came from.

So that will be one layer of
addressing, where I originally started

from and where I'm finally going.

But you remember, my computer realizes

that I'm not plugged right into
the Bank of Arizona server.

Bank of Arizona is not sitting
on my home network.

I need to go to my router, because it's the one
that knows the path to get to that IP address.

So I use a different source and destination
address, and that's going to be a Mac address.

So again, encapsulating this packet further, I
have the source IP address, which I'll just put,

I think it was .172 or .72 or something
-- destination IP address, so what was it.

It was .8 -- I'll just put dadadada.8.

I do have the full address, I just
can't squeeze it all in there.

So now I need a source and destination --
source and destination Mac address as well,

which is going to be my physical
computer -- it's still describing me --

I'm the original source of this -- but now
I'm going to say I need to get to the router,

I need to get to my network because I
realize Bank of Arizona is not on my network.

Those of you analysts are
going, how did the computer know

that Bank of Arizona's not on its network?

That's when we get into IP addressing, and
subnet masks and all of that kind of stuff,

but for now I'm just going to say, it knows.

So the computer knows and it realizes I have to
send it to my router, so what it's configured

with -- take a look at this;
I'm going to do an IPconfig.

My computer says this is my IP address but
I also know the IP address of my Gateway.

This is my router.

This is where I go if I want to get off my
network, so behind the scenes, when he realizes,

I need to go to Bank of Arizona,
I need to get off of my network,

he's going to do something called an
ARP, an Address Resolution Protocol --

to find out what is the Mac address,
what is the physical address,

Datalink address of this router
so I can add that to the packet.

Matter of fact, digging a little bit here,
I'm going to type in the command arp-a,

which shows I figured this IP address,
which is my gateway, my router,

has the physical address, a/k/a
Datalink address, of this.

This is its Mac address.

What is mine?

I can do an IPconfig/all, and I
can say my address is right here.

This is the IP -- sorry, the
Mac address of my network card.

So let's put these two pieces together.

I'm going to -- good grief,
this is just getting messy.

Hang on. I'm going to this server right here.

I'm coming -- I lost my $50.

It's gone, man.

Add all the headers there that we're tacking on.

But I get to the point where I'm
saying the source IP address is me,

and the destination IP address
is that server over here.

That's where I'm going.

But I know that I can't just
say Go Fish, Find your home.

I'm going to say the source Mac address for
my local communication on this switch is

that nice Mac address that I
highlighted and showed right here.

That's going to be me, so I'll just
put 32 is the source Mac address.

And the destination Mac address
is going to be here.

That's going to be the router that it gets to.

Now, the router is the ultimate bummer
job, because from there, comes down

and physically sends my $50 transfer,
switch looks at it, sends it to the router.

The router's like, oh, oh, I got some mail.

It has my destination MAC
address in this header.

It's for me.

It opens it up and looks at the destination
IP address, which was somewhere around here,

looks at the destination IP address,
it's like oh, this isn't for me.

This is going to some server far, far away,
and by the way, that's the job of the router.

The job of the router, its number one
goal, is to maintain a routing table.

So it knows how to get around
the world at large.

It knows where to send stuff
based on its IP address.

So it goes, oh, it's not for me.

It's going to the bank, so I'm going to
send it to this router, because I'm looking

at my routing table, and it says,
your next destination is right here.

Now, keep in mind, when it did
that, it totally changed networks.

Instead of saying, it came from this source
MAC address and went to this destination,

now it says, oh, okay, we're now coming from me.

I'm the new source and you're the destination.

And then every time we have a network change,

this is the new source and
this is the new destination.

And by the way, there's quite a
few routers in between these two.

If I do a trace route -- I'm going to do -g,
it just goes faster -- www.bankofarizona.com.

It goes through my router, it goes out my
ISP and each one of these represents a router

that it's going through along the way.

Say I'm going here, I'm going
there, I'm going here.

So think of this, every single one of these
lines that come out, represent a router

that I'm passing through on
my way to the Bank of Arizona.

Isn't it amazing?

Look at that.

17 routers, and then it blocked
me, because they're like, okay,

you've gone far enough, buddy, this is a bank.

We're not going to let you
see beyond this point,

so we don't even know how
many routers are past 17.

That's actually surprising to me.

That's a lot of routers that it's going through,
all the way over here to this Bank of Arizona.

Every single time this happens, takes that
Datalink address, rips it off, and replaces it.

Isn't that amazing?

$50 is coming right here.

IP addresses don't change.

Now, I know some of you are
going, what about NAT?

We'll talk about NAT later on.

But every single one of these hops is
going to say, I'm going to go here first.

Okay, rip off that source and
destination MAC address, replace it.

Okay, now I'm going to go
here, rip off, replace.

Now I'm going to go here, rip off, replace.

17 minimum times it's going through this story
all the way to finally reach this destination.

That's how the OSI model
is used in practical use.

Now, on this side, he receives
it, the final server.

He goes, okay, this is my MAC address --
looking at the header -- this is for me.

It looks at the IP address and
he goes, oh, this is for me, too.

It's not a router; it's going directly to him.

He goes, great, that's fantastic.

He then looks and goes, okay, it
looks like he's coming to Port 443.

I'm going to pass that to Apache or
IIS because it's easier to write,

and I'm now going to do my
application layer stuff.

The database says take that $50, move
it from that field to that field,

so now it's added to the savings
account, and I'm going to send

that acknowledgement back saying
I got that, and then I'm going

to send some information refreshing the
web page saying, "Successful transfer."

Isn't this crazy?

We're sitting here -- we go to
websites all the time, right?

I click on Bank of Arizona, and I'm
greeted here by this fall money makeover

and all this kind of data that's on the screen.

There were probably 50, 60 different packets
used to generate this web page that went

through 17 different routers that had -- every
single one of those packets had its source

and destination MAC address changed,
and we have the audacity to be

at some point, oh, this is so slow.

You know, I'm clicking on collection
-- oh, man, that took awhile.

It didn't really, but it's like
-- wow, that's not as fast as --

okay, this is a lot faster than I was
hoping it would be, but you get the point.

A lot of times we're like, man, it's slow,

but if you think about the behind the
scenes, what's really happening -- wow.

It's surprising it's not taking a
good full day for that thing to show

up with the amount of work that's happening.

That's the OSI model in action.

That's what's really happening
behind the scenes.

Okay, last thing I want to
add to this before we wrap up,

is we've seen some core network
devices -- primarily switches, routers,

and I think on the opening nugget we saw the
wireless access points and clients and servers.

Where do these work in the OSI model?

Well, the switches, if you want
to know their primary role,

they sit right here at the Datalink layer.

Their goal?

Learn physical addresses.

Learn MAC addresses.

They are committed -- when I plug
in a network cable into that switch,

I will identify exactly what
physical address exists on there.

So when this guy sends a message and says,

I want to talk to that router,
the switch already knows.

It says, oh, he's right at this port,
let me forward you over, because my job,

my resume says I learn MAC addresses, and I
already have learned where that MAC address is.

And before switches were, there was
this lovely device known as a hub.

A hub actually worked at the
physical layer of the OSI model.

It serves the same purpose of a switch,
which was to connect everything together

and allow LAN-based communication, but it
didn't have the ability to learn MAC addresses.

So anytime somebody would send something,
the hub just sent it out every single port.

So when I sent my $50 transfer to the bank,
all of the different computers and servers

and everything else plugged
into my local network here,

would get my $50 transfer,
they would just ignore it.

Now, if I had somebody malicious over here
-- this is my evil user in the cubicle --

with a program called Wire Shark on his
hand, he could start capturing that data.

Now, it would be encrypted thanks to the
presentation layer, but he could you know,

try and start working it, see if
he could break the encryption.

There's a lot of dangerous stuff if you're using
hubs, which is why we don't use hubs anymore.

Everything that we use is switches,
which are Datalink layer devices.

Routers, if you said, what
layer do they work at?

They work at multiple layers.

I mean, but I would say their
specialty is right here.

They sit right at the network layer, and
if you had like a drag and drop example

where I was okay, where do we drag that device?

He's a network device.

He looks at IP addresses.

That's his primary function, look at IP
addresses and figures out what to do with them.

Says, I'm going to move that one from
here to here based on my routing table,

which tells me where to send everything.

Now, these devices, I mean, you can really
set these guys up with the application layer.

Now, debatably so you could say,
well, doesn't this guy do --

put IP addresses on there and
doesn't he have a MAC address?

Yes, he does.

All of these devices, in some realm,
function at every layer of the OSI model.

I'm just talking where they would specialize,
where you would know these devices to exist,

it would be primarily -- I would
say the applications running

on that computer are working primarily at
the application layer, but also remembering,

it has an IP address, it communicates on
the network just like any device does.

One more piece, I mentioned Wi-Fi.

Where does that fit?

It's an alternative right here.

It serves the same function as a switch.

Its goal is to connect devices to the
network and to learn MAC addresses;

it just does so through airwaves rather than
physical network cables that are coming in.

There's so much more to say here, but
remember, this is where it begins.

This is the foundations of the OSI model.

So let me hit the high points
of what we've discussed,

but then give you a specific direction of
what I want you to do with this information.

Number one, we saw what the OSI model was,

a standard of standards,
allowing network communication.

We saw the conspiracy behind it, which I
know a few high-level politicians claiming

to invent the Internet were involved
in, but they chose TCP/IP instead.

We saw getting to know the layers, what adds
what, what are the functions for each one

of these layers, encapsulating
the packet all the way through.

And then we saw how network devices
communicate using OSI and also

where those network devices fit, where
does the switch fit in the stack,

where does the router fit in the stack.

So here's what I want you to do.

I always like wrapping up each
nugget giving you an action plan,

just because there's so much information.

What's to say this doesn't just
evaporate out of your mind.

I want you to find a friend.

This is a weird goal I have for yoyu right now.

I want you to find a friend, maybe
it's a wife, a husband, a friend,

a dog, somebody you meet on the street.

Just pull them aside and be like,
I want to show you something.

Bring your phone, bring your iPad, bring your
computer, bring him to your computer and pull

up a web browser and go to Google,
and say, you see that web page?

I want to tell you how it got there.

And then sit there and explain to them -- I
know, they're going to be like, I've got -- no.

I'm sorry, I've handcuffed you to the chair.

I don't know if you noticed that when
I said I have something to show you,

but there was a snapping sound; you can't move.

And I'm going to show you how this PC
communicates with that Google server,

or whatever web page you went to, and describe
to them this OSI process the entire way through.

I know you're going, he's joking.

I am dead serious.

This is one of those things that
will quickly evaporate your mind.

I know this is kind of cliché,
but one of the best ways

to learn something is to teach it to somebody.

I guarantee if you -- first, maybe
do a presentation to yourself.

Make sure that you've got it down, because when
you try to explain it, you're going to go, ooh,

wait a second, how did that work?

Wait a second.

Hang on. A lot of times -- because I've seen it
for many different students when I've taught,

people go, oh, okay, that
make sense, great, I got it.

But it didn't really soak in far enough to
where they really got it until they were put

into a position where they had to display
that knowledge, and at that point,

having to display the knowledge didn't
work because they never really confirmed

that they got it in the first place.

So seriously, find a friend and explain this
to them, then move on to the next nugget.

I hope this has been informative for you,
and I'd like to thank you for viewing.