All language subtitles for 27 - Routing - Routing Protocols Concepts-eng

>> You'll find quickly in the Cisco and network world

that automated processes are usually to be avoided.

And the reason why is, you know, we make enough mistakes on our own, right?

When we're manually configuring something, it's like, "Oh, I mistyped.

Oh, I did this," you know.

And you get the criticism, you're like, "Gosh, my fault, I'm sorry."

And it makes you feel bummed.

But it's even worse if an automated process goes bad behind the scenes

because then you really know it's not your fault,

but everybody thinks it's your fault anyway because it's always your fault, right?

So usually you're like I just feel better, you know,

take like auto negotiation of speed and duplex.

You know, I just feel better hard coding it 'cause then I know it's going to work.

It's not going to be something that comes back to bite me later

because I trusted an automated system.

Now, we come to routing protocols which is taking the static routing that we saw

in the last nugget and automating the process.

Initially, you're going to be like "eh."

But I will say it is necessary, you know.

It's necessary to kind of trust your routers, to start doing this static routing replacement

for you to where they're going to come in and build the routing tables dynamically.

So, that's going to be what we'll look at in this nugget.

First off, big picture routing protocol overview then I'll focus on OSPF.

When you get into the concept of routing protocols, it really is a simple concept.

It goes something like this.

When your router boots up and you configure

with just a base configuration, what does it know about?

It knows about directly connected stuff.

When I go in and configure this router with an IP address of 192.168.3.1,

the router immediately knows I'm connected to the 192.168.3.0 network.

It's now one network smarter.

I go over here and configure this one with 192.168.2.2 and it goes, "Okay,

I must be connected to the 2.0 network."

So what is routing protocols?

Tell your friend what you know, that's pretty much it.

You configure the routers with a routing protocol which is really just a language.

Think of it like English, French, German, I mean all the different languages that are out there.

So as long as these two are speaking the same language like let's say OSPF,

that's one of the languages that exist, and they are compatible,

and we'll learn what compatible means and we look specifically about OSPF,

router 2 will communicate over to router 1 and say, "Hey router 1,

I know about 192.168.2.0 and 3.0, why?

Cause I'm plugged into them.

Somebody configured me with IP addresses in those networks."

Router 1 gets that message and its like, "Oh, wow, that's great.

You know what router 2, I knew about 192.168.2.0 because I'm plugged into it too.

So that's nothing new to me, thanks for the superfluous information

but it doesn't really matter to me, but what does matter to me is you just told me

that you know about 192.168.3.0 and that's great 'cause I didn't know that one even existed.

So tell you what, I'm going to add that to my routing table, put a little o in from of it,

so everybody knows I learned about it via OSPF and I'm going to now add to my routing table

that I know how to reach the 192.168.3.0 network.

And you know what router 2, since you told me about it, I'm going to use you to get there."

That's it.

That's routing protocols and all its glory.

I mean so let's take one more sec.

Router 1 is going to talk to router 3, again, using that same language of OSPF

and router 1 is going to say, "Hey router 3, I now know about 192.168.2.0, why?

Cause I'm plugged into it.

I know about 192.168.1.0, again, why?

Cause I'm plugged into it.

And, by the way, I have a friend, I just made a friend and he told me that he has 192.168.3.0

as well which is great because I didn't know about that before but now I do."

These conversations we have of routers, right?

So router 3 is like, "That's fantastic.

Now I knew about 192.168.1.0,

so you're not telling me new there.

I'm not even going to add that to my routing table because you know what?

I already knew about it and I really believed myself over you."

Notice I'm actually introducing little words like believe ability.

"So I believed myself.

But you know what, I did not know about 192.168.2.0/24

nor did I know about 3.0/24, so you know what, I'm going to add those to my routing table.

And since you told me about them friend, router 1, I'm going to point to you as the next hop."

"And when I say next hop, I mean I'm going to use you

to get there," router 3 says to router 1.

Now, the neat thing about routing protocols is they keep this going.

You know, router 1 is going to, you know, on a regular basis, just say, "Hey router 3,

I still know about these routes, just FYI, they're still there."

"Oh, okay that's great," you know.

"Router-- oh, okay.

Hey, I still now about the"-- I mean they continually check in with each other

to make sure that they still indeed know about the rest.

Now why do they do that?

Well, what if something very bad happens?

What if somebody unplugs this network and that whole network goes down?

Well, router 2 can tell router 1, "Hey, you know what, the network is down."

And router 1 is like, "Oh, I totally get that.

I'm sorry for you, let me cross that out.

I'm going to remove that from my routing table 'cause it doesn't exist anymore."

Same thing with router 3, you know, router 3 gets the FYI

and he removes it from his routing table.

So both from a cleanup perspective, that's kind of nice

that they dynamically adjust their routing table to react to events,

but also from a redundancy perspective.

So let's just imagine with me real quick

that router 3 actually has a very slow backup connection to this router over here

which has a very slow backup connection to this router over here which has a pretty decent speed

to this, you know, to this router right here.

So essentially router 3 has not one but two ways to get to 192.168.3.0,

a faster way and a slower way.

With these routing protocols, what's going to happen is router 2 is going

to tell router 4 about this network.

And router 4 is like, "Oh great, I now know about the three network too.

That's great, I'm going to tell my friend router 5 about the three networks."

And that's going to end up getting back.

It's like a big gossip chain, right?

They're all talking to each other.

They're all exchanging [inaudible].

And that all ends up back at router 3.

Now router 3 hears about the 3.0 network this way and he hears

about the 3.0 network from this way, from router 1.

So now he's like, "Whoa, great.

I've got two ways to get there."

One that's really good.

You know, this way is really fast and how does he know it's fast?

We'll talk about that.

It depends on the kinds of routing protocols and the flavors of routing protocols that we choose.

But he's going to say, "Okay, well this way is really fast.

I like that way.

That's going to go on my routing table.

But you know what?

This way is pretty sweet too.

I've got-- at least I've got something there."

So that way, let's say that instead of this network going

down right there, maybe this WAN link goes down.

There's a backhoe in the driveway and chunk, you know, takes out the fiber line

or whatever is coming in that brings in that connection, it goes down.

Router 1 is going to notify router 3 and say, "Hey men, I lost the 3.0 network again

and the 2.0 network to top it all off."

And the router 3 is like, "Oh men, I'm so sorry about that.

But you know what, I'm not going to remove that from my table.

I'm just going to say I'm going to go that way 'cause, yeah, it may be slower

but slower is better than none at all."

So we start seeing real quick that routing protocols add more

than just a time-saving feature like I don't have to manually configure things.

They add other benefits as well.

We first off see that they are dynamic so that the networks automatically are advertised

and routers automatically build their routing tables based on what their neighbors tell them.

So there's this time-saving dynamic nature to them.

But also, we now see that there's a level of redundancy to where the routers will speak

to each other on a regular basis.

And a matter fact, you'll see in really, really sensitive networks

like high traffic, really critical networks.

Sometimes you'll tune down that little check in timer even to less than a second

to where the routers are like, "Hey, hey, hey."

They're constantly making sure that the other router is online because as soon

as that router goes offline, they want to know about it and then take some kind

of alternate path to keep the connection active because maybe there's

such critical traffic going across.

So these routing protocols allow us to be redundant and fail over automatically but--

I mean, think to the static routing world, that just doesn't happen, right?

I mean with static routing, you say go that way, the router's going to go that way

until you get involved and say go another way.

Finally, these routing protocols introduce a level of best pathness because they're able

to look at the network and say, "Okay, well based on whatever criteria," and we're going

to talk about that, "but based on whatever criteria,

I have decided that going this way is better than going

that roundabout way the other direction."

So they automatically are able to determine what the best path is.

I had to speak in big picture generalities on the previous slide

because we hadn't selected a specific routing protocol.

I used the OSPF as just a little part of the example.

But depending on which when you pick, there are specifics that apply to just that protocol.

Now, initially when you see this, it's like, "Well why?

Why do we have all these choices of routing protocols?

I mean doesn't the routing protocol, isn't its goal just to tell its friends like we saw

on the last one, just to convey that information?"

Well, yeah.

I would say that's the core mission statement.

But-- I mean think about it this way.

Think about like a car, right?

Why is there not just one model of car?

I mean don't they all have the same core function to move you from point A to point B?

Well, yeah, the core, that's what they do.

But the-- I mean some people want to buy a car that takes, you know, virtually no maintenance.

You know, they don't really care what it looks like.

It's just inexpensive.

It just gets them from point A to point B and that's all that they want

and that they don't care about anything else.

Whereas other people want a car that maybe cost 100,000 dollars and it gets them from point A

to point B really fast and sleek but it's going to take a lot of day to day maintenance

to keep up, same concept with these routing protocols.

Some networks are kind of like, "Yeah, we're just, you know,

doing our thing, advertising routes.

We don't really care about the routing protocol."

You know, if we have a failure and it takes to 90 seconds for it to figure

out that there's a failure and recover, that's cool 'cause we're going to get there

and our network doesn't really care to put the time and effort

into picking a routing protocol that will do that.

Whereas other networks, I mean you'll see some networks that are-- I mean there are people.

Listen to this and just to convey how critical networks are.

There are people, there are organizations that are spending hundreds and hundreds of thousands

of dollars to move their networks from a network that maybe takes two seconds to detect a failure

and revert, you know, and correct itself, to move that from two seconds

down to 200 milliseconds or 300 milliseconds or a hundred milli-- I mean creepy, crazy.

I mean, you think about somebody's crazy for buying a car that, you know,

does a 180 miles an hour for a 100,000 dollars.

I mean think about this.

People are spending, you know, five times that amount to get a network

that [inaudible] just 1.5 seconds faster.

That's the kind of world that we live in today.

So what are they?

Let me-- let's look at the overview of these.

I'm going to start of with RIP 'cause that's where most people start.

RIP is your-- RIP is your Ford Pinto of cars, meaning-- well I don't know.

It's going to get you there.

It will work.

It's not going to be fast.

It's not going to be smooth or quick or anything like that, but it will work, you know.

It gets you from point A to point B and you just don't care what it looks like.

RIP has a default advertising cycle of once every 30 seconds.

So essentially, when I'm saying, "Hello neighbor, I know about this, this and this,"

and telling the neighbor what networks he knows about,

he's going to repeat himself once every 30 seconds and every 30 seconds,

he's going to tell the router everything.

I mean it's kind of like you ever have a friend

who tells you the same story every time you see him because they don't remember

that they told you that story last time?

That's RIP.

I mean-- but it's doing it every 30 seconds,

telling the router the whole story about the entire routing table.

Now, with a 30 second, this is known as kind of a hello timer or an advertisement timer.

With a 30 second hello timer, it's actually going

to take 90 seconds before a router determines that the other one is dead.

So essentially, if you're used to somebody saying hello every 30 seconds and then all

of a sudden they stop saying hello, you're not just going

to be like, "Well, they must have died."

I mean you're going to give them some time.

Maybe they're just stuttered or something.

Or in the routing world, maybe they were just congested.

Their processor was over loaded.

They missed a hello for whatever reason.

The packet got dropped.

So we give them some time.

We give them a few moments to recover from that.

But that cost us sometime that, you know, if a router does go down, RIP isn't going to know

about it by default for 90 seconds.

That's an eternity nowadays in terms of the entire network being down.

So last thing I want to talk about is actually something called the metric.

The metric is how does a routing protocol figure out the best way to reach a destination?

I mean I mention that in the previous slide and said, "Oh, this was-- this way is really fast.

This way is really slow."

Well, some routing protocols can do the fast-slow thing.

They can actually look at the bandwidth for-- I can't even draw while I'm talking here.

They're going to look at the bandwidth for link but other protocols don't.

So for instance, let's say we've got this little ring of routers here.

Router 1 is connected to network A and so is router 6, we'll stay over here,

and so we go through 2, 3, 4 that-- you know, that goes between them.

And router 2 is going to say, "Okay, what's the best way to get to network A?"

Maybe this is a 2400 baud modem like my old Commodore Amiga BBS I used to run.

You know, maybe that's a 2400 baud modem and then this is a, you know,

gigabit per second Metro Ethernet or a fiber optic cable running all the way this way.

Well, if router 2 is running RIP, it uses a metric of hop count.

Now hops, you've heard me say, I think even in the previous slide,

that is going to be the next hop address.

A hop is determined to be a router.

So if router 2 is routing RIP, he's going to hear about network A from router 1,

router 1 is can be like, "Hey, router 2, I know about this," but router 6 is also going

to tell router 4 who tells router 3 who tells router 2 about network as well.

So router 2 hears about network A from two places.

Which one is it going to use of it if it uses RIP?

That way, because it goes, "Oh look, I only have to go one hop," a router is a hop

and I reach it this way, whereas I have to go one, two, three hops to get there the other way

and that-- well, three is bigger than one.

It doesn't even look at the bandwidth.

You and I are looking at it and you're like, "That's crazy,"

and that's why most people don't use RIP.

It's been around for a long time.

You know, it's kind of like, you know, think positive Jeremy, right?

What's the positive of RIP?

If I had to pull something out of the air, I would say it's supported everywhere.

Everything supports RIP because it's been around since, you know, 1960s, '70s time.

I mean as TCP/IP came out of the womb thus came RIP.

So, it's-- everything supports RIP.

So if you can't figure out a routing protocol, that's going to be it.

So, that's what RIP is.

Let's look at-- where do I go from here?

Let's go to OSPF.

No, no, I'm going to go here 'cause that's a quick discussion.

Cisco looked at RIP and they say, "This is a terrible protocol.

We can do better."

And so, they created IGRP which actually ended up training

out to be worse when it was said and done.

I would say, the one thing that IGRP improved was-- instead of using a metric of hop,

it uses a metric of bandwidth and delay.

It's actually able to detect how fast the lines are and--

I shouldn't say detect, but look at the speed of those signs.

But the big problem is they said, "Well we're going to make this more efficient too.

So we're going to make the default hello timer 90 seconds."

Well, that's great, a grand concept, but the problem with that is

if you increase the default hello or how often it's advertising its routes,

then you have to increase the default dead timer.

So, I mean IGRP becomes an absurd 270 seconds before it even detects that the network is down.

Long story short, Cisco realized, they're like, "Why are we trying to compete

with RIP in the first place anyway?"

And so, they got rid of it.

IGRP is dead.

That's why I said it's a quick discussion.

You won't even see it if you're taking a certification exam anymore.

I just wanted to kind of give it an honorable or maybe not so honorable mention, it is flushed.

Let's look at OSPF.

OSPF, the most popular routing protocol in the world.

That's why I discussed it on the previous slide.

OSPF stands for Open Shortest Path First, keyword to that is Open.

As in it's an open standard, everybody can use OSPF without having to pay somebody.

It's kind of-- think of it like open source, right?

Anybody can use this.

This one, I mean if I were to compare it to a vehicle, this guy would be your-- oh what?

Man, I should've prepared for this.

This guy is your corvette.

Now that's such a good description.

A corvette-- I mean if somebody pulls up in a corvette--

first off, are there cooler cars out there?

Yeah, there are.

But are you-- I mean if you see a guy pull up in a corvette to the office, are you going to be--

are you going to walk out and be like, "Dude, you got-- you just have a corvette?"

I mean, no, nobody criti-- I mean you're going to be like, "That's a sweet car."

I mean it does.

It does a job and it does it well.

OSPF actually has a default hello timer.

Now, and this is where we start getting into the specifics that I don't want to dive too deep

into because the hello timer can actually change.

But we'll just go with a default hello timer being 10 seconds.

But the beauty about OSPF is it's not like RIP.

RIP sends its entire life store.

Remember I said it's like the friend who keeps telling you his life story.

OSPF, you know, when routers first communicate, he's going to say,

"Hey, I know about all these routes."

And then he's going to be like, "Hey, I know about all these routes," and then that's it.

They just, from there on out, send little hellos.

He goes, "Hi, hi, hi, hi."

I mean is there any reason for these routers to say anything else?

I mean why on earth would router 1 tell its whole routing table

to router 2 again every 10 seconds?

I mean it's kind of like, well, nothing's changed but FYI, hear it all.

I mean that's what RIP does.

So OSPF just says, "You know what?

I'm just going to say hi."

And then if something changes, I'll tell you,

but I'm not going to waste bandwidth sending everything every 10 seconds.

Now you might say, "Well, why is that relevant?"

It's relevant because once we know that it's just a little high, it's like a ping, right?

Ping, ping, ping.

It doesn't really do anything.

We can crank that timer down and people do.

You can take it down to three seconds, two seconds.

You can take it down below a second, into the milliseconds

where the router is literally going, "Hello."

I mean it's like machine gun to the other router because that way you can determine, you know,

the second that router goes down as you tune that down.

So that's great.

So that's where the corvette feels of this comes in.

Now what about metric?

OSPF is actually-- it's complex.

It's not really complex.

The metric is something known as the cost which really is just the bandwidth.

So if you have two routers and they have a let's just say a T1 line, right?

T1 is 1.544 megabits per second, that's the speed of it.

OSPF actually uses something called the cost which is the bandwidth.

So let's just say 1.544 divided by-- I'm sorry, I'm taking the formula backwards.

It's actually the bandwidth 1.544 into 100.

So this is in megabits per seconds.

So that equals what the metric is.

So the OSPF would look at this link and-- yeah, I just got to bust this out.

So let's take 100 divided by 1.544 and this is going to say, "Oh, that cost is--

"it's going to round it up 'cause it doesn't use the decimal point.

So it's can say, "Actually this link cost me 65."

Oh, I said-- 65.

I'm going to look at that and say, "That cost me 65."

Whereas maybe he has another path to the same network, maybe it's just plugged right

into that same network, and that's a hundred megabit per second connection.

OSPF is going to look at that and say, "Oh okay, well a hundred into a hundred.

This one cost me one."

One is better, it's lower, it's cheaper, it's faster than 65 which is the T1 line.

So I'm going to go that way.

Actually I had to pause because 65 didn't look right to me and it's not.

So, Cisco devi-- I rounded because I'm human.

Cisco devices don't even see what's after the decimal point.

So when they do this quick calculation that I showed you, they would've just said, "Okay,

well at 64, you know, beyond the decimal point is dead to me."

So that would be an actual cost of 64 but, nonetheless, you get the idea, right?

So that's where it says the metric equal to cost.

There's a lot of features that are associated with OSPF that you can do

but that's why it's the most popular routing protocol in the world.

So, what about this one?

I'll give the brief flyby of that one.

IS-IS was the competitor to OSPF, says for intermediate system to intermediate system.

Now, this was created and actually bought these protocols were created back in the day

where people were still like, "Is TCP/IP the future?"

You know, that-- we're talking like the 1980's, right,

before there was really the internet and its common place.

TCP/IP was still an unknown.

Like is that going to be the one?

There is actually another protocol that was doing quite well

in the competition and it was known as OSI.

I know, freeze frame for a second.

Wait a second.

Where have I seen that before?

Wasn't that a model?

Wasn't-- isn't there the OSI model?

Yes, it actually-- the OSI model was a never meant to be just a model.

It actually was meant to describe the protocol developed by the same group, the OSI protocol.

Now, you remember VCRs before there was DVD players?

Remember there was a beta and a VHS?

Maybe some of you are.

Now, hopefully, you're not so young that you don't remember VCRs.

But there was beta and there was VHS, right?

Well with TCP/IP, this was the VHS.

It worked and it ended up winning, but OSI was actually the better standard.

So IS-IS was the routing protocol for OSI

and it actually was the better routing protocol than OSPF.

But again, because of the way a politics and mafia and whatever else got involved

in that works, you never really hear about the OSI protocol just like you never really hear

about the IS-IS routing protocol, but it's still out there.

It's still alive and well, and used in, I would say, some of the most sophisticated networks

like service providers, people that really need a [inaudible].

If I were to compare this to a car, this is like 1967 Corvette Stingray.

It still a corvette.

It's still amazing.

However, if you've got one of those, chances are you either have a lot of money or you built it

and restored it yourself as in you know how to tune that and tweak that thing

out toward it can take any modern corvette that you throw at it and-- and let me--

men, this car thing is just growing, I love it.

It's very-- I mean when somebody is running IS-IS, a network administrator looks at him,

they're like, "Whoa, you know what you're doing."

I mean there's like anybody-- I don't mean to put down OSPF but I kind of do.

Anybody can go out if you got the cash and just buy a corvette, right?

You don't need to know anything about cars.

However, to get a 1967 Corvette Stingray or restore one, I mean when the guy who just went

and bought a corvette pulls up to him, he's like, "Wow, you know.

My car is newer but men you really know what you're doing

and I bet you, you could take me off the line."

And that's the idea with IS-IS.

I won't even get into the hello timers and all that because we really dive

into a whole another world with IS-IS.

I just want you to know that it exists.

It's rarely used.

But when somebody uses it, men, they know what they're doing and they can really tune it out.

Tuned it out, shows how much of a car guy I am.

Tweak out, make it scream.

That brings us to EIGRP.

EIGRP, if it were car, it would be a Ferrari, because it is extremely fast.

It can be one of the fastest protocols that exist on the planet.

However, you got to be kind of a select group to get in.

There's only so many Ferraris made every year.

It's not common.

And the analogy I'm trying to draw here is it is a select group of Cisco people that use EIGRP.

It is proprietary.

EIGRP was created by Cisco for Cisco, so you need to be running Cisco everywhere.

Why would you run anything else, I know.

But some people choose not to.

But you have the running Cisco everywhere on your routers to support this.

Now, because of that fact alone, you'll find companies

that even half all Cisco everywhere not using EIGRP because they don't--

you know, OSPF is kind-- you know, it's like a corvette is good enough,

you know, why do we need anything better?

And then why would we tie our self into Cisco that we could never get out without a lot

of pain in reconfiguring all of our routing protocol?

So EIGRP, Cisco's goals was to take the best of RIP which I know you're kind

of like, "What's the best of RIP?"

It's easy.

It's really easy to configure RIP and it just kind of-- it's--

you just type in a few commands and, bam, you're running RIP.

EIGRP is the same way.

It's really easy to get into but they wanted to have all of the features of OSPF and more.

There are some shortcomings in OSPF, some design constrains that make it painful.

Some of the features that people want it that OSPF just couldn't do.

I'll give you one of them.

It's, for instance, unequal cost load balancing.

You know, every protocol, even RIP supports equal cost load balancing.

Like if I have two T1 lines going to this location, I'll, you know, send one packet here,

one packet here, it can load balance between those two links.

But what if I have a faster link here?

Maybe this is a T3 line which it's-- by the way, that's not three times the T1 line.

T3 is 44 megabits per second whereas T1 is 1.5, right?

So, all of the other routing protocols look at that and they're like, "Well,

I'm using that," that one just sits there idle.

I mean it could even be so much as like maybe one side is 1.5 and the other is 1.8, you know,

or something like that and all of the routing protocols are like,

throw their hands in the air, we're not using

that because we, you know, we only do equal cost.

Well EIGRP introduces features like unequal cost where it can intelligently load balance

over both of those links, so a lot of great stuff but tying you into the Cisco world.

What's better is they came up with a great metric.

Metric of EIGRP is actually bandwidth plus delay.

They cannot only look at the bandwidth of a line, how much bandwidth is there,

but also how much of a delay is there, on that?

Like how long does it take the packet to get from point A to point B?

You may have a huge line but the delay on it might be a high.

Like it still takes a lot longer for a packet

because maybe the shared distance it has to travel.

Maybe it's satellite link or something like that that it's using.

So you can combine those two things together.

But that's-- I feel like a salesman just now.

That's not all.

There's more.

With the metric of EIGRP, you can also add in reliability like how reliable is that link,

how loaded, you know, the load, the current amount of traffic actually passing

over the link, and there also is one called the MTU which nobody uses

but it is the maximum transmission unit.

How big of a packet can be sent across that link?

So what EIGRP does is use this big formula.

It's actually known as the K-value formula that can combine all these things together.

It only-- I should say, by default, it only uses bandwidth and delay.

But you can throw all these other things into the big mixing pot

and create this really sophisticated metric with EIGRP.

So you see what I mean when I say there are some cool features?

Cisco is just like, "You know what?

Let's-- if we're going proprietary, let's go at it.

And let's just give people what they really want."

Okay, last protocol I want to look at is BGP, the boarder gateway protocol.

If I were to say this is a car, BGP is the Hummer.

No, I'm not-- [inaudible] tallk before Hummer went mainstream

and created the girly versions, like the H2, H3.

I'm talking at the original H1 military grade vehicle, you can roll over anything.

I mean it's mean.

It's ferocious.

It's not fast but it can accomplish just about anything that you want other

than take a Corvette Stingray off the line, right?

So BGP, just to give an idea, BGP is the routing protocol that we use for the internet.

So whereas these little routing protocols are really meant for inside of a network,

like inside of your organization.

It can handle, you know, a couple of hundred, a couple of thousand routes,

maybe looking at inside of your company.

I mean BGP, you're looking at hundreds and hundreds and hundreds

of thousands of routes that are in there.

It's the Hummer, it's pulling stuff along.

So-- I mean-- and also to give you an idea, BGP-- what's the best to put it?

It's an entire series at CBT nuggets.

It's an entire certification exam as in-- you know, I put an entire series together of 20--

I think it was 20 individual nuggets that just on this one protocol, it's huge the amount

of stuff that you can do with it.

So, this is not for the average Cisco person.

Most people that are in Cisco, that are Cisco certified do not deal

with BGP on a regular basis.

If you're dealing with BGP, you are usually working at an ISP,

like you are a service provider or some really, really big enterprise company that needs

to interface and essentially become a kind of ISP on their own.

So, BGP is beefy, it's mean, and unusually outside the scope of most

of the Cisco series that we're talking about.

Okay. One more thing I want to add on our routing protocol discussion here.

Can routers run multiple routing protocols at the same time?

So, give you an example.

Can I have a router here that maybe connects to, you know, this half of the network

and it communicates with that side using OSPF and then it talks to this half of the network

and maybe on this half of the network that uses EIGRP or RIP or BGP?

I mean can I do that?

The answer is, yes, you can.

That's actually an advance routing situation.

It's where you get into redistribution like sending one protocol

into the other and-- I mean you can do [inaudible].

That's CCNP stuff.

I mean people do it a lot, but it's CCNP level material.

The reason that I bring it up now is as soon as you introduce that point of the discussion,

there's a chance that maybe-- you know, maybe--

you know, I kind of drew these pictures going their own way.

But maybe this wraps around something like that to where this router hears

about the same route via OSPF as it does via EIGRP.

Now, normally-- I showed you before, normally if that happens, it says, "Well, okay.

I'm hearing about it this way.

I'm hearing about this way.

Which one is better, as in which is the better metric, right?"

We talked about that on the previous slide where I was saying, you know, RIP would say,

"Well this is one hop," remember that, "And this way is [inaudible]."

So which is better route?

Well, if you've got different routing protocols, you can't do that.

That game doesn't work because you-- maybe one side is RIP and the other side is the EIGRP.

One side is saying, "Oh, I can reach network A and it's five hops away."

EIGRP is saying, "Well, I can reach the network A and it's, you know, a K-value formula plus,

minus the square root of, you know, blah, blah, blah, and it's a 59621 cost."

And so, you can't say, "Well, okay.

Well then how does-- how do we translate five hops into this K-value formula?"

You can't.

They're apples and oranges, they can't be compared.

So what Cisco and actually the industry created is this thing known as administrative distance.

Jot this one down in your head, administrative distance.

What is that?

It is above the metric, like it's more powerful than the metric.

And it says how believable is the routing protocol.

How-- you know, for instance, if I have EIGRP versus OSPR

or Rip versus the EIGRP, which one is more believable?

It all comes down to a simple number.

Each one of these routing protocols is assigned a number.

The lower the number is the better.

So it's a golf score.

You want a lower number, right?

So let's just look at RIP.

RIP the champion of them all has an administrative distance of 120, right?

OSPF has an administrative distance of 110.

So let's just talk that story right there.

Let's say we've got RIP on this side versus OSPF on this side.

Who wins? OSPF does.

Because when the router is looking, he's saying, "Okay, I hear about network A

from RIP and network A from OSPF.

Well OSPF's administrative distance, its believability is just better.

You know, RIP maybe saying it's one hop

and OSPF maybe saying it's a cost of 9,122, but I don't care.

I'm not even looking at that because I can't compare cost

to hops because it's apples and oranges.

Hops do not equal a certain amount of bandwidth.

They're totally different.

So I'm just going to look at this number and say OSPF is better, right?"

EIGRP, administrative distance of 90.

So immediately, beats OSPF, beats RIP.

BGP probably won't need-- these three, the ones that I just wrote up there,

you'll want to know them right off the top of your head.

Those-- you know, know what they are, know what protocol has them, know--

for instance, if I saw them on a lineup and something said,

"What has the administrative distance of 110?"

I'd be saying OSPF, you know, it's right there.

BGP and there are exemptions everywhere.

You can actually go get a table.

Just go to Google, type in administrative distance, there's a whole table.

You'll see there's a different kinds of BGP routes, internal,

external, all that kind of stuff.

But as a mainstream standard has a administrative distance of 20.

Wow! I mean compare that and it's just like that's unbelievably good compared

to all of the other routing protocols.

Now, here, you know what's funny?

These are Cisco administrative distances, right, because of Cisco series,

Cisco devices that we're working with.

It's almost insulting that EIGRP had an administrative distance of 100

because that makes it look better that OSPF.

But when you create your own protocols like Cisco did, you can do that kind of stuff.

And then you can say, "Well, I'm better than OSPF," and that's probably one

of the reasons it's no longer around, it's gone.

So again, once you would want to know OSPF, know RIP, no EIGRP, just so the scene is complete,

IS-IS, just FYI, you won't need to know this but it is an administrative distance of 115.

Now, one thing is missing from all of this gibberish around the screen,

and that is what about the static route?

Anyone remember from the pervious nugget what a static route was set to?

One. One, that's how much the router believes you.

So when you go in and you say, "Router, go that way,"

there is no routing protocol that's going to overrule you.

You have dictated.

The only thing that can beat a static route is something with a cost of zero.

And the only thing that has an administrative distance

of zero is a directly connected interface.

So if I'm on this router and I'm saying, "Router, go that way to get to network A,"

and the router is literally plugged into network A, it's going to say, "No."

It's right-- you plugged me into it.

You must be mistaken network admin, because it's right there.

What was I thinking?

My thought process was like, "Oh yeah,

I can squeeze routing protocols and OSPF in the same nugget.

It should fit."

It's that same instinct that when my wife calls at 4:30 and she's like, "Hey,

you're going to be leaving on time?"

I'm like, "Oh yeah, just a couple more things I got to wrap up and I'm out the door.

You know, 9 o'clock at night, there I am."

So what have we seen in here?

Routing protocols are friends telling friends.

I mean at the core, that's what routing protocols are,

is just one router telling another this is the network that I know about.

However, when we start getting into jellybean of protocol choices,

we see there's a lot more complexity to it because people want different things.

They want easy to use routing protocols.

Another person wants an industry standard routing protocol.

Another person wants the cool features but they're willing to go proprietary just

like the different cars that are out there.

So, that gives you-- the things that I would want you to take away is to understand,

you know, what these different protocols are, what advantages they might have over the other.

Just, again, from a big picture perspective, take away that administrative distance,

take away what the metric is, how each one

of those routing protocols finds the best way around the network.

Now, something that just popped in my head, I was saying-- I think I showed that, right?

Well, for all of the routing protocols that count when we're looking at ICND1 level.

You might say, "Well what was the metric of BGP?"

BGP, yes, it's like-- the metric is like 12, 13 things long.

It's super complex when you get into the metric of BGP.

There's no one simple answer to that.

So get those thoughts down in your mind.

And then let's jumped into the next nugget and that's where I'm going to pick

up the OSPF concepts and configuration.