WEBVTT

0:00:03.180000 --> 0:00:07.960000
 Hello and welcome to this video titled
 the goals of loop prevention.

0:00:07.960000 --> 0:00:09.980000
 So what are we going to
 cover in this video?

0:00:09.980000 --> 0:00:14.340000
 We're going to cover what is a bridging
 loop and why is it a bad thing?

0:00:14.340000 --> 0:00:18.560000
 I'm going to introduce you to rapid spanning
 tree as a protocol to prevent

0:00:18.560000 --> 0:00:22.900000
 bridging loops and we're going to look
 at the concept of trees as related

0:00:22.900000 --> 0:00:24.280000
 to rapid spanning tree.

0:00:24.280000 --> 0:00:26.920000
 Why is they have the word
 tree in the title?

0:00:26.920000 --> 0:00:29.100000
 What does that have to do with bridging
 loops and stopping them?

0:00:29.100000 --> 0:00:31.600000
 So let's start with the
 very foundation here.

0:00:31.600000 --> 0:00:33.820000
 What is a bridging loop
 and why do we care?

0:00:33.820000 --> 0:00:35.400000
 What's the bad thing about this?

0:00:35.400000 --> 0:00:40.260000
 Well, let's imagine that we have a
 couple switches or bridges here and

0:00:40.260000 --> 0:00:42.820000
 there is no loop prevention
 at all.

0:00:42.820000 --> 0:00:47.300000
 There is no spanning tree of any flavor
 operating in this environment.

0:00:47.300000 --> 0:00:48.900000
 Here's the problem
 that we would have.

0:00:48.900000 --> 0:00:53.280000
 So the problem really involves traffic
 that needs to be flooded by these

0:00:53.280000 --> 0:00:58.620000
 switches. Imagine that PC sent some
 sort of a frame that was a broadcast

0:00:58.620000 --> 0:01:01.220000
 frame or maybe it's not
 even a broadcast frame.

0:01:01.220000 --> 0:01:04.900000
 It's just something that when the switch
 sees the destination MAC address,

0:01:04.900000 --> 0:01:06.420000
 it doesn't know what
 to do with it.

0:01:06.420000 --> 0:01:09.640000
 It doesn't find it in the MAC address
 table and it says, I need to flood

0:01:09.640000 --> 0:01:15.160000
 this thing. So right now at this point
 in time, the switch on the top

0:01:15.160000 --> 0:01:20.020000
 in his MAC address table is going to
 learn that PCA in his MAC address

0:01:20.020000 --> 0:01:22.520000
 has been learned on
 port number one.

0:01:22.520000 --> 0:01:24.420000
 That all looks good.

0:01:24.420000 --> 0:01:27.900000
 Now he's going to take that frame and
 flood it meaning he's going to copy

0:01:27.900000 --> 0:01:32.860000
 it and send one copy out port number
 two, another copy out port number

0:01:32.860000 --> 0:01:37.080000
 three. Now when the switch on the bottom
 gets that, he's not going to

0:01:37.080000 --> 0:01:40.640000
 be able to process both of those
 frames at exactly the same time.

0:01:40.640000 --> 0:01:42.860000
 He's going to process
 one after the other.

0:01:42.860000 --> 0:01:46.740000
 Now that'll be very, very quick, but
 still, let's see how this is going

0:01:46.740000 --> 0:01:48.260000
 to affect his MAC address table.

0:01:48.260000 --> 0:01:52.680000
 So he's going to learn the source MAC
 address of A as it's coming in.

0:01:52.680000 --> 0:01:55.780000
 And let's say he processes the frame
 on the left first, the one that came

0:01:55.780000 --> 0:01:57.240000
 in on port number four.

0:01:57.240000 --> 0:02:00.940000
 Well, that's the port he will associate
 with that MAC address.

0:02:00.940000 --> 0:02:06.160000
 Now the moment he does that, he's going
 to take that frame and once again,

0:02:06.160000 --> 0:02:09.520000
 because it's a destination address, in
 this case a broadcast that he doesn't

0:02:09.520000 --> 0:02:12.460000
 know what to do with, he's
 going to flood that frame.

0:02:12.460000 --> 0:02:14.360000
 So there it goes.

0:02:14.360000 --> 0:02:17.180000
 Now the moment that happens.

0:02:17.180000 --> 0:02:20.560000
 Now he hasn't even processed the frame
 that came in on port number five

0:02:20.560000 --> 0:02:23.360000
 yet. This is all happening
 in microseconds here.

0:02:23.360000 --> 0:02:27.040000
 The moment that original frame was
 flooded out, look what happened.

0:02:27.040000 --> 0:02:30.940000
 It ended up going right back
 up to the top switch again.

0:02:30.940000 --> 0:02:36.180000
 The top switch is now seeing a frame
 with a source MAC address of A and

0:02:36.180000 --> 0:02:39.340000
 he says, oh, it looks
 like PCA has moved.

0:02:39.340000 --> 0:02:42.700000
 He's no longer on port number one, because
 I'm seeing him come on on port

0:02:42.700000 --> 0:02:48.120000
 number three. That is wrong because
 that's not where PCA lives.

0:02:48.120000 --> 0:02:51.820000
 Not only that, a split second later
 if we go back to the switch in the

0:02:51.820000 --> 0:02:55.300000
 bottom, he's going to have to process
 that frame that came in on port

0:02:55.300000 --> 0:02:59.620000
 number five. He's going to say, oh,
 it looks like A has indeed moved.

0:02:59.620000 --> 0:03:01.720000
 He's no longer on
 port number four.

0:03:01.720000 --> 0:03:05.920000
 I just saw him come in as a
 source on port number five.

0:03:05.920000 --> 0:03:08.000000
 And then what's he going to
 do with that green frame?

0:03:08.000000 --> 0:03:10.140000
 He's going to flood that as well.

0:03:10.140000 --> 0:03:13.860000
 And so that's going to cause, once
 again, a change in MAC addresses.

0:03:13.860000 --> 0:03:15.900000
 Now the switch on the top is going
 to say, oh, it looks like he moved

0:03:15.900000 --> 0:03:18.500000
 again. He's now in
 port number two.

0:03:18.500000 --> 0:03:21.920000
 And then when that gets flooded around,
 the switch on the bottom will

0:03:21.920000 --> 0:03:25.640000
 once again go back to four, five, four,
 five, the guy on the top will

0:03:25.640000 --> 0:03:28.500000
 go two, three, two, three.

0:03:28.500000 --> 0:03:32.560000
 And so we have several
 problems going on here.

0:03:32.560000 --> 0:03:37.100000
 Problem number one, let's just take
 it in the order of least significant

0:03:37.100000 --> 0:03:40.320000
 or least intrusive problem
 to the worst problem.

0:03:40.320000 --> 0:03:43.420000
 So the least problem is with the perspective
 of whoever is controlling

0:03:43.420000 --> 0:03:48.480000
 PCA. Now hopefully that's not your CEO
 or one of your executives of your

0:03:48.480000 --> 0:03:52.080000
 company. If it's just the normal person
 like you and me, that person's

0:03:52.080000 --> 0:03:55.140000
 not going to be too happy because they're
 not going to be getting any

0:03:55.140000 --> 0:03:58.260000
 data. All of a sudden their web browsing
 is going to stop, their email

0:03:58.260000 --> 0:04:03.400000
 is going to stop because anytime Ethernet
 frames reach the top switch,

0:04:03.400000 --> 0:04:08.500000
 which are going to A, at this point
 the top pointing out port number one

0:04:08.500000 --> 0:04:12.780000
 anymore. He's either going to be pointing
 out ports two or three, both

0:04:12.780000 --> 0:04:13.900000
 of which are wrong.

0:04:13.900000 --> 0:04:18.520000
 Neither one of those ports actually
 will get the frame to PCA.

0:04:18.520000 --> 0:04:21.240000
 So PCA is not going to be too happy
 here because he's not going to get

0:04:21.240000 --> 0:04:22.240000
 any information.

0:04:22.240000 --> 0:04:23.800000
 That's one problem.

0:04:23.800000 --> 0:04:30.880000
 Our second problem is that actually that
 was probably of the three problems

0:04:30.880000 --> 0:04:31.780000
 I'm going to identify.

0:04:31.780000 --> 0:04:33.320000
 That was probably in the
 middle of the list.

0:04:33.320000 --> 0:04:37.260000
 The least big deal or the least intrusive
 problem is that we have this

0:04:37.260000 --> 0:04:40.920000
 frame here that's circling and
 circling around on these links.

0:04:40.920000 --> 0:04:45.860000
 Now we know that on Ethernet links
 a switch can only put one frame at

0:04:45.860000 --> 0:04:48.180000
 a time on an Ethernet link.

0:04:48.180000 --> 0:04:52.180000
 So if I'm a switch and here's my port
 leading to you and this port has

0:04:52.180000 --> 0:04:54.960000
 got some memory and in this memory
 I've got a bunch of Ethernet frames

0:04:54.960000 --> 0:04:58.020000
 ready to go, ready to
 transmit on this wire.

0:04:58.020000 --> 0:05:00.980000
 Well I can only put them on
 the wire one at a time.

0:05:00.980000 --> 0:05:04.240000
 So that means if I'm right now in the
 process of putting a broadcast frame

0:05:04.240000 --> 0:05:08.900000
 or flooding something on this wire, that's
 valuable time that these other

0:05:08.900000 --> 0:05:10.320000
 frames have to wait.

0:05:10.320000 --> 0:05:13.080000
 They have to be buffered in memory
 until it's their turn.

0:05:13.080000 --> 0:05:15.600000
 Well if I'm constantly taking the exact
 same frame and putting on the

0:05:15.600000 --> 0:05:18.160000
 wire, putting on the wire, putting on
 the wire because it keeps flooding

0:05:18.160000 --> 0:05:21.840000
 back to me and flooding back to me, that's
 valuable bandwidth that's being

0:05:21.840000 --> 0:05:25.580000
 wasted that could be used with these
 other legitimate frames that need

0:05:25.580000 --> 0:05:27.280000
 to go on that same cable.

0:05:27.280000 --> 0:05:29.360000
 So that's probably the
 least of our problems.

0:05:29.360000 --> 0:05:30.540000
 But that is a problem.

0:05:30.540000 --> 0:05:31.760000
 It's a waste of bandwidth.

0:05:31.760000 --> 0:05:36.200000
 Second problem is from PCA's perspective,
 he's not getting his information.

0:05:36.200000 --> 0:05:39.100000
 So that's probably a little bit worse
 because he's not getting anything.

0:05:39.100000 --> 0:05:42.180000
 But here's the absolute worst
 problem of these three things.

0:05:42.180000 --> 0:05:47.180000
 We saw here that while this was happening,
 these two switches start rapidly

0:05:47.180000 --> 0:05:49.480000
 changing their MAC address tables.


0:05:49.480000 --> 0:05:52.880000
 The guy in the top starts thinking,
 oh PCA is on two, no he's not, he's

0:05:52.880000 --> 0:05:55.640000
 on three, no he's not, he's on two,
 no he's not, he's on three.

0:05:55.640000 --> 0:05:58.780000
 And then the same thing happens with
 the switch on the bottom shuffling

0:05:58.780000 --> 0:06:02.320000
 back and forth between
 four and five.

0:06:02.320000 --> 0:06:07.620000
 Well the process of erasing and writing
 MAC addresses to a MAC table is

0:06:07.620000 --> 0:06:11.900000
 something that the brain, the
 CPU of the switch has to do.

0:06:11.900000 --> 0:06:15.720000
 It was never designed to do
 that very, very quickly.

0:06:15.720000 --> 0:06:17.200000
 Think about this for a moment.

0:06:17.200000 --> 0:06:20.960000
 How long do you think it takes from
 the time's broadcast comes in till

0:06:20.960000 --> 0:06:23.420000
 it goes out and comes
 right back again?

0:06:23.420000 --> 0:06:26.160000
 We're talking microseconds here.

0:06:26.160000 --> 0:06:31.100000
 So if this is even a fast ethernet link,
 forget about gigabit or 10 gigabit,

0:06:31.100000 --> 0:06:34.300000
 if that's fast ethernet, that means
 that one link is capable of handling

0:06:34.300000 --> 0:06:38.640000
 100 million bits per second.

0:06:38.640000 --> 0:06:45.220000
 Your typical broadcast frame will be
 something on the order of 9,000 bits.

0:06:45.220000 --> 0:06:48.020000
 So how many frames are
 9,000 bits long?

0:06:48.020000 --> 0:06:51.360000
 Do you think you can shove down a cable
 that's capable of transmitting

0:06:51.360000 --> 0:06:55.220000
 at 100 million bits in one second?


0:06:55.220000 --> 0:07:00.920000
 That's a lot. So this frame can be
 circling around so super fast that

0:07:00.920000 --> 0:07:03.540000
 the CPUs in the switch
 choke and die.

0:07:03.540000 --> 0:07:07.100000
 The CPUs in the switch say, oh, I can't
 erase and rewrite the MAC address

0:07:07.100000 --> 0:07:09.820000
 table fast enough to
 keep up with this.

0:07:09.820000 --> 0:07:12.900000
 And then your switch
 could actually crash.

0:07:12.900000 --> 0:07:15.820000
 So that obviously would be
 the worst of all scenarios.

0:07:15.820000 --> 0:07:19.540000
 But all of these are the problems
 of a bridging loop.

0:07:19.540000 --> 0:07:23.280000
 So clearly, I think you can understand
 why we want to get rid of bridging

0:07:23.280000 --> 0:07:25.880000
 loops and prevent them from happening
 in the first place.

0:07:25.880000 --> 0:07:30.040000
 And this is what Spanning Tree
 was designed to solve.

0:07:30.040000 --> 0:07:34.000000
 So Rapid Spanning Tree, which is what
 we're focusing on in this course,

0:07:34.000000 --> 0:07:40.920000
 was originally introduced in 2001 as an
 enhancement to the existing classic

0:07:40.920000 --> 0:07:42.900000
 Spanning Tree that
 existed back then.

0:07:42.900000 --> 0:07:48.020000
 So originally 802.1D
 came out in 1998.

0:07:48.020000 --> 0:07:51.660000
 So that was the IEEE
 specification 802.1D.

0:07:51.660000 --> 0:07:53.900000
 So it was out for a while.

0:07:53.900000 --> 0:07:58.620000
 And then a decade or so later in 2001,
 some came up with an enhancement

0:07:58.620000 --> 0:08:02.820000
 called 802.1W, which was
 Rapid Spanning Tree.

0:08:02.820000 --> 0:08:08.320000
 Now, like a lot of standards, this
 is a common theme where a standard

0:08:08.320000 --> 0:08:09.560000
 will be put out.

0:08:09.560000 --> 0:08:12.560000
 And then some people will say, oh, I
 think we could do this enhancement

0:08:12.560000 --> 0:08:16.460000
 to it. So that'll come out as its
 own standard-lown enhancement.

0:08:16.460000 --> 0:08:19.520000
 Then somebody else will say, oh, I
 think we could do also this to it.

0:08:19.520000 --> 0:08:23.460000
 So as time increases, you've got the
 standard, which is going unchanged,

0:08:23.460000 --> 0:08:26.560000
 and all these enhancements
 being added.

0:08:26.560000 --> 0:08:30.040000
 And then usually at some point in time,
 the developers of the original

0:08:30.040000 --> 0:08:33.800000
 standard, they go back and they say,
 OK, let's take all this stuff that's

0:08:33.800000 --> 0:08:38.200000
 been introduced over the last few years
 and roll it up into a new revision

0:08:38.200000 --> 0:08:40.040000
 of the standard.

0:08:40.040000 --> 0:08:42.680000
 And that's exactly what
 happened with 802.1D.

0:08:42.680000 --> 0:08:49.180000
 In 2004, they rolled into it or incorporated
 into it the Rapid Spanning

0:08:49.180000 --> 0:08:51.620000
 Tree protocol 802.1W.

0:08:51.620000 --> 0:08:55.420000
 So technically, there
 is no 802.1W anymore.

0:08:55.420000 --> 0:08:58.580000
 It's now part of 802.1D.

0:08:58.580000 --> 0:09:02.280000
 Now, we call this a common
 spanning tree.

0:09:02.280000 --> 0:09:06.900000
 And the reason for this is because
 the idea with all these versions of

0:09:06.900000 --> 0:09:14.260000
 spanning tree with 802.1D and w was
 that you would create one tree, and

0:09:14.260000 --> 0:09:16.780000
 we're going to look at what that means,
 a tree here in a second, but one

0:09:16.780000 --> 0:09:22.000000
 tree for the entire topology in order
 to prevent or block bridging loops.

0:09:22.000000 --> 0:09:24.940000
 And it didn't matter about VLANs.

0:09:24.940000 --> 0:09:30.080000
 So whether you had one VLAN or 50 VLANs,
 all those VLANs had to follow

0:09:30.080000 --> 0:09:34.460000
 whatever the one tree was that
 was built by Spanning Tree.

0:09:34.460000 --> 0:09:39.620000
 And once that tree was built, that dictated
 where your traffic could go.

0:09:39.620000 --> 0:09:42.740000
 So we call this a common
 spanning tree.

0:09:42.740000 --> 0:09:47.020000
 So because of this, with Spanning Tree,
 all flavors of Spanning Tree,

0:09:47.020000 --> 0:09:51.240000
 there is no redundancy in traffic
 patterns for frames.

0:09:51.240000 --> 0:09:55.460000
 So on the one hand, Spanning Tree is beneficial
 because it prevents bridging

0:09:55.460000 --> 0:09:58.880000
 loops. And in the next slide here, I'll
 show you exactly how it does that.

0:09:58.880000 --> 0:10:00.240000
 So that's a really good thing.

0:10:00.240000 --> 0:10:03.380000
 The downside is there's
 no redundancy.

0:10:03.380000 --> 0:10:07.720000
 What that means is that between any
 point A and point B, point A being

0:10:07.720000 --> 0:10:11.680000
 a host and point B being a server, or
 maybe between two servers or between

0:10:11.680000 --> 0:10:15.860000
 a router and a host, between any two
 points on the network, Spanning Tree

0:10:15.860000 --> 0:10:20.640000
 will ensure there's only one path, one
 physical path that traffic could

0:10:20.640000 --> 0:10:22.860000
 take between those two hosts.

0:10:22.860000 --> 0:10:25.180000
 There's not multiple paths
 that could be taken.

0:10:25.180000 --> 0:10:29.480000
 It trims off all the additional
 redundant paths.

0:10:29.480000 --> 0:10:31.960000
 So why do we call
 it Spanning Tree?

0:10:31.960000 --> 0:10:34.060000
 Where's this concept of
 a tree come into play?

0:10:34.060000 --> 0:10:35.760000
 Well, look at this
 network right here.

0:10:35.760000 --> 0:10:41.660000
 Here, we've got a ton of redundant
 paths between any two of these PCs

0:10:41.660000 --> 0:10:45.420000
 here. Lots of different ways these
 two PCs could get to each other, or

0:10:45.420000 --> 0:10:48.340000
 these multiple PCs could
 get to each other.

0:10:48.340000 --> 0:10:51.880000
 But there's also in here a lot
 of possibility for loops.

0:10:51.880000 --> 0:10:55.900000
 Basically, anything you see in here that
 looks like a triangle, like that

0:10:55.900000 --> 0:10:59.460000
 one right there, that could be a source
 of bridging loops as indicated

0:10:59.460000 --> 0:11:01.240000
 by the red arrows right there.

0:11:01.240000 --> 0:11:04.900000
 Frames could just circle around there,
 anything you see in here that looks

0:11:04.900000 --> 0:11:08.240000
 like that. So there's a lot of potential
 bridging loops in here.

0:11:08.240000 --> 0:11:12.420000
 So what Spanning Tree does in order to
 prevent that is Spanning Tree will

0:11:12.420000 --> 0:11:14.160000
 go through a lot of logic.

0:11:14.160000 --> 0:11:17.900000
 And eventually when that logic is done,
 certain ports in this topology

0:11:17.900000 --> 0:11:21.180000
 will be placed in what's called
 the blocking state.

0:11:21.180000 --> 0:11:27.100000
 Now, when a port is in the blocking
 state, no user data can go in or out

0:11:27.100000 --> 0:11:30.700000
 of that port. You might as well just
 imagine the port doesn't even exist

0:11:30.700000 --> 0:11:34.120000
 anymore, because once it's blocked, it
 can't be used for data transmission

0:11:34.120000 --> 0:11:39.120000
 or reception. So instead of having redundancy,
 we end up having a topology

0:11:39.120000 --> 0:11:43.680000
 that looks like this, where all of our
 redundancy has been trimmed off,

0:11:43.680000 --> 0:11:46.040000
 and we have a tree-like structure.


0:11:46.040000 --> 0:11:49.700000
 Because when you think of a tree, you've
 got the roots of the tree, then

0:11:49.700000 --> 0:11:53.140000
 you've got the trunk and everything
 sort of branches off from there.

0:11:53.140000 --> 0:11:57.740000
 But if you're hanging off any branch and
 you want to get to another branch,

0:11:57.740000 --> 0:11:59.800000
 there's only one way to get there.


0:11:59.800000 --> 0:12:04.100000
 There's not multiple redundant ways
 to get from one limb or branch of

0:12:04.100000 --> 0:12:04.900000
 a tree to another.

0:12:04.900000 --> 0:12:09.440000
 You've got to go to the trunk, up or
 down, and then get to another branch.

0:12:09.440000 --> 0:12:11.640000
 That's the same idea here
 with Spanning Tree.

0:12:11.640000 --> 0:12:16.000000
 It'll take your highly redundant topology,
 trim off all the redundancy

0:12:16.000000 --> 0:12:22.140000
 by blocking links, leaving a topology
 that resembles a tree-like structure.

0:12:22.140000 --> 0:12:25.760000
 So that concludes this video on an introduction
 to Spanning Tree and an

0:12:25.760000 --> 0:12:27.760000
 introduction to bridging loops.

0:12:27.760000 --> 0:12:28.640000
 I hope you found it useful.