Original subtitles

>> 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.