The original
spanning tree protocol was developed way back in the mid 1982 by Radia Perlman. This was a long time before
which is, as we know them today, even existed. What you're seeing here
is the original paper published in 1985,
outlining how spanning tree works, and it worked well for its time. But back in the early nineties, the demand
on networks wasn't what it is today. They didn't connect phones
to their network. They didn't have mobile devices
or high speed internet. So if it took a whole minute
for an interface to come back up,
that wasn't considered a big deal. It wasn't long
before this needed to change. So one of the improved versions
is being tree called rapid spanning tree protocol was released
with the aim of improving how quick a network change is detected
and handled? So we're going to take a look
at what is change in rapid spanning tree
and how it achieves this fast convergence. Just because
Burning Tree has been improved on doesn't mean we need to throw away
everything we've learned. There are a lot of similarities. For instance, there is still a bridge being blues are still sent
through the network. Switches still need to find the best
path to the bridge and links are still blocked
to prevent loops. So then what's changed? Well, for one also, which is actively seen BP use not just the bridge. The BPU format has changed a little
to include more information. There are a few new port states
to supplement the blocking state. There are improvements to bring ports up
quicker, and Cisco have added their own
pavilion technology. We're going to take a look
at all of these changes in this video. So considering
there's a few versions of spanning Tree, how do you know which one use
which is running? Once again, we come back to the old show
spanning tree command. On this, which we see the way running a
version of spanning tree called I Travel. This is the original version of spanning
tree. Usually, Cisco switches
will run some type of RSVP by default. That means that you can take a brain,
you switch out of the box, connect to your network and it will
automatically have RSVP protection. But we just can't leave it at that. We still need to know how to tune it
to our knees and how to troubleshoot something
if it breaks. Let's start by seeing how we can change
the version that we're using. We do this with the spanning tree mode command
and you'll see there's a few options here. Rapid PVS is Cisco's
version of RTP as a Cisco's version, as they have added features that aren't
strictly part of the Irish TB standard. Don't worry,
we'll cover those a bit more later. Now, if we check the version once again, we can see that
it has been changed to RSVP. Now, as usual, this video has plenty of quizzes
that you can test yourself out on. And we're starting to get you to think
a bit more outside the box. The basic concept of bridge
IDs are still the same in RTP. That is, the lowest bridge
ID becomes the root bridge. But if you take a look at the bridge
priority, you'll notice that something doesn't
quite look right. In the last video, we said that the bridge
priority was in increments of 4096. But here the value is 61,441, which clearly is not divisible by 4096. So what's happening here? In our step, the BPU message now includes a system wide
extension field on a Cisco switch. This is basically the VLAN ID. And that's why we see the breach
priority broken down into two parts here. The priority and the suicide. The system I.D. here is one
because we're looking at Villa one. You should also notice the Bridge I.D. priority is different to the Route I.D. priority. This tells us that the local switch
is not the route bridge. Let's take a look at our other switch. Notice here
that it says this bridge is route. This means that the switch we're currently
logged on to is the route bridge. Quite simply, if you don't see this. Some others, which is the route bridge. Let's take a look
at BP's use again for a minute. In the original spanning tree protocol,
only the Root Bridge would generate BP to use and other switches
would forward them through the network. The only exception to that is with DCNS, when a switch would use a BPU to notify
the network of a topology change. In Irish Ole's, which is Nelson
BPT used to their neighbors. These are a type of hollow message
to identify themselves and to learn about the other switches
they're connected to. Individual BP to use are no longer flooded
or forwarded through the entire network. BP to use are now sent only
to the immediate neighbor. A significant advantage of
this is being able to use BP to use to see
if an immediate neighbor is up or down. If three BP use go missing in a row,
then the neighbor is considered to be down. Beads are sent out at regular intervals,
according to a hollow timer. This is still every two seconds
by default. We can change that time or if we want to in configuration mode,
we use the spanning tree command. Notice that we have to include a villain. No, this is a Cisco thing. They require configuration
to be applied per villain. And we include the hollow time, key word
and the time in seconds that we want. Now, a quick
architectural question for you. Why would we want to control
where the bridges within our topology? When it comes to ports, some things change
and some things remain the same. The report, for example, is the same. There is still one report per switch,
and it still points out the best to the average. The only exception, of course, is the river itself,
which does not have any reports. All ports on the bridge
are always designated ports. Speaking of designated ports,
they're the same two. These are ports that point away
from the bridge and can still forward regular traffic, each network segment
can only have one designated port. If there were more than
one, there would be a loop. What do I mean, though, when I say network segment? In nearly all cases these days,
this is a link between two switches. The segment is the link itself, and there are only two devices
on this segment. But a more complicated scenario is
where you might have an old fashion hub or a dumb switch or something like that
in a case like this. More than one device
can connect to the single segment. This is rare these days, though
we shouldn't be seeing hubs anymore, but it is still possible,
so be aware of it. If this does happen,
if you do find a hub in your network, be aware that you can only have one
designated port for the entire segment. If there was more than one,
we would definitely have a look. Therefore, one of these ports would need to be blocking instead. The blocking port is
where things get interesting. Blocking ports can now be categorized as either alternate ports or backup ports. Any type of blocking port will block
regular traffic, but still allow BP to use. In fact, a port must be receiving
BP to use to be in a blocking state. Of course,
you might wonder why this is the case. first, remember that all switches in bpd
use used their neighbors. If a port is not receiving BP to use,
then it is not connected to another, which is probably connected
to something like a PC, a printer, a server or some other end device. We can't create loops on interfaces connected to these devices,
so these ports do not need to be blocking. As I just mentioned, blocking ports can be alternate or backup, an alternate port is one
that has received a superior BPU from a different switch
in the same network segment. The network segment in this case is just
that link between the two switches. This here is an alternate port,
as is an alternate path to the bridge. It's ready to take over
if the current report fails. Back up ports come into play
when there is a shared segment that is something like a hub that allows two or more switches
to connect to each other. In our example, once, which has two links, one link on this, which becomes designated on the other switch the port is blocking, this would be an alternate
port, as we just discussed. Now, back on the switch with two links,
something interesting will happen. The switch will see its own BP use
that is, each port will send BP to use
and the other port will receive them. Only one of these can be designated,
though, so the other must be blocking. But because the Switch receives
a BPU from itself, the blocking port will be a backup port. It's called a backup port
as it's the backup to this segment. Just remember,
as we previously said, that jobs are rare, so you are unlikely to see back at ports, if you do see backup ports in your
network, you probably have a hub somewhere and you should probably take steps
to replace them. We can examine the output of show spanning
tree to see these port types here, we can see the role which would be route
designated alternate or back backup. The status
which can be forwarding or blocking, and of course, the cost
which we spoke about last video. The cost is determined
by the speed of the port. There may be times
when we want to override this, though perhaps we want to make traffic flow
over a different path for troubleshooting purposes to do this. We can figure an interface and then
we enter the spanning tree cost command. The cost is any numerical value. Of course,
you should verify our change with show spanning tree and you'll see here
that the cost has changed. This has in effect changed
which ports are route and which are alternate. So have a look at this topology. Can you figure out what would happen
from a spanning tree point of view if the Red Link were to break? In the original spanning tree port needs to work through the blocking,
listening, learning and forwarding states all up, it would take about 50 seconds
report to come online, which is far too long in a modern network. RSVP addresses this issue by changing the states to discarding
learning and forwarding the old blocking and listening states have effectively
been combined into discarding. But the big change is how all these work. They don't have time is anymore. Instead,
they have a negotiation procedure. As before,
when an interface first comes up, it is in the blocking state,
so a loop can't form before it's detected. For example, imagine that we're adding
a new switch into the network. There's no loop here,
but spanning three doesn't know that yet. The switches will start setting BP to use, which starts
a negotiation process called async. This gets a bit complicated,
but basically they use new fields in the BPU message to share information. They negotiate the link to the bridge
first and enable that link at this point,
the downstream links are still blocked. Once which will propose
which links would be forwarding and which should be blocked,
the same process then completes four downstream switches and the appropriate
links transition to forwarding. Yeah, I have very much oversimplified
this process. The point to remember is that RCP takes a much more active approach
in bringing up the interfaces. There are no timers,
which means interfaces come up faster. This approach means RCP can respond
very quickly to changes in the network. But don't take my word for it. Let's see it in action. first, we're changing a flavor of spanning
tree to PVC. This is one of Cisco's versions
of the original Spring Tree Standard. I'll get to why this is called BVA later. Next, I'm enabling
spanning tree general and event debugging. So in case you've forgotten
or you haven't come across debug yet, debugging is getting extra
logging information from us, which
so we can use it for troubleshooting. I have a separate video on that
if you want to review on how that works. If we're on the console port, which I am, we will see all debug logs in real time. However,
if you're connecting to a switch with S.H. or Telnet, you need to run
the Terminal Monitor command first. What this does is sends a logs
directly to your terminal session so you can see them. You know, so we're already getting a few logs
as there's always something happening. I'm now going to bring up a new link
on Gigabit zero to. Notice that we can see the interface
going through the various states. first listening. And learning. And finally forwarding. As you can see, it takes too long for a port to transition to 40. I'm now going to shut that port down
so we can try and RSVP. Of course, we'll get a few more debug logs
along the way. Now we'll change your RCP mode. This in itself
will generate a lot of logs. We'll just wait until they're finished. OK, that looks stable now. And now I'm going to bring up
gig zero slash two again. And that's done. See how much faster
that was with Iris TPY. We can't go back and look
at a few of the steps that it took, such as selecting designated as the port role
and sending the RSVP proposal. Of course, you should always remember to disable any bugs
when you're done troubleshooting. Got another quiz question for you. But I don't think you'll find this one
very hard. When we think of spanning tree topologies, we can think about different ways
that ports can behave. So far, we've mainly talked
about the links between switches. As far as RCP is concerned,
these are either point to point ports, which is a direct connection
between two switches or shared ports, which connect to a shared segment
like having a hub in your network. We've looked at both of these already, but there's a third type
we haven't looked at called an edge port. This is where edge devices connect. These are devices like PCs, printers,
routers, basically anything
that's not connecting switches together. Why is this important, because
spanning tree is there to stop loops? And where do loops occur in devices
that forward layer two frames? So basically, Hobson switches edge devices do not forward frames,
so they do not cause loops. So as you can see,
there's no reason to worry about BP to use port
states blocking ports, that sort of thing. When we have an edge device connected now
in the old days, that would be a problem because even if we're connected
to an edge device, it would still take 50 seconds
for that port to come online. And that's just waste of time
to address this. But even before RCP was invented,
Cisco created a feature called Port Fast. It was such
a good feature that when RCP was released, it became a built-in part of the standard,
which we now know as the edge port. When we know that certain ports
are for edge devices only,
we can configure them with port fast. So let's see how it's done. Under interface configuration, we enter the spanning tree port fast
command. Despite being part of the vendor
neutral RSVP, we still call it port fast
when using Cisco switches. Just remember that other vendors
will call it an edge port. Notice that we're given a warning. We have authorized a switch to bypass
many of the spanning tree procedures on this port
in order to get it to perform better. This is fine, but be aware
that connecting a switch here, while Port Fast is active
may introduce a loop into the network. If we look at the spending details again, we can see that
this interface is now listed as an export. It also goes straight
into the forwarding mode, bypassing the discarding, learning and forwarding
states. It's also worth
noting that if this port goes up or down, it will not trigger a tsien to others,
which is. Practically, though, what happens
if someone plugs a switch into an airport, whether it's malicious or accidental,
this can happen. By default, this might introduce a loop into the network,
which is, of course, very bad. Does this mean that port fast
is just too risky to use? Not necessarily. There's another feature that came along
with Port Fast called BPU God. Now, as far as I know,
this is not on the exam, but I feel it's too important
not to mention it, at least briefly. So imagine we have configured an edge port with port fast
and we connect a workstation to be safe. We also configure BP to you guard. Then someone comes along, disconnects
the workstation and connects a switch. When the news which is connected,
it will start sending BP to use. The original switch will see this, and
it will think, hang on, that's not right. There must be a switch connected. The port will then loses edge port status
and it will become a regular port. In this way,
our network is still protected from loops. I have a couple of trivia questions
for you this time. You might need to do
some of your own research on these ones, but don't worry, it'll be time well-spent. The original spanning tree
known as or two to one day has quite a few drawbacks
in the modern network. We've looked at
a few of them in this video. Over time,
there have been a few improvements to the original protocol
and a few new variants of spanning tree. Not all of which are shown here. Cisco even had a few proprietary versions which only worked with other Cisco
switches. There have also been vendor neutral versions that work on all switches
like R.S.V.P.. To be honest, these take a lot of Cisco's
improvements, like better time as port roles and other features,
and they make them standards. So our step is the vendor
neutral improvement on spanning tree Cisco's implementation of this is called pavilion rapid spanning tree. This means that Cisco's enhanced
version of RCP is aware of VLANs, while the official version of RCP is not. Another version of speeding treacle Ms Adobe is the vendor
neutral option that is available in a way. OK, so what do I mean when I say velan away or pavilion? Well, traditionally the spanning tree
topology is the same
for the entire switching domain. If a port is the root port,
it's the report for all villains. If a port is blocked,
it is blocked for all villains. In the pavilion model, there is a separate
spanning tree instance for each feeling. Take this topology, for example. We have two villains, ten and 20. We can configure different priorities, bridges and link costs for each feeling. This means that the switch selected
to be the regional villain ten may be entirely different to the switch
selected to be Root Bridge for Villain 20. There are pros and cons of this approach,
of course. In a traditional model,
some links would still be blocked. These
links would be then sitting there idle all the time, essentially
being wasted in our pavilion model. A link may be blocked for Valentin and
a different link is blocked for Velan 20. This means that we're utilizing
all our links, on the other hand,
the switch needs to maintain a separate instance for every villain,
even if they have the same configuration. If you have a lot of villains, then your switch will have a lot
of spending tree processes. This puts more load on this,
which is hardware mzgee that's multiple spanning
tree is a reasonable alternative in this case, but that's outside
the scope of a county level video. Let's see how this looks on a switch. first,
we're creating a two villains, ten and 20. We want this which to be the bridge for Valentin,
but not for villain 20. This is done by changing the bridge
priority, as we saw in the last video. This time,
I'm going to show you a shortcut. We're going to run spanning Tree Valentin Route Primary. This is a macro or shortcut on Cisco Switches
that sets the Bridge ID for us. So this which will become the route
by specifying Valentin this change will only happen for the violent end
spanning three instance. We can do the same for VLAN 20 using the secondary keyword. This will set a bridge party
that's a little worse than the current route bridge,
but still better than other switches. So either Route Bridge fails this, which
will be the next in line to take over. We can now take a look at the result with show spanning Tree Valentin. This is the same as show spanning tree
command we've been using. It's just limiting the output
to volunteer any information only. We can indeed see that
this is the bridge for the U.S. in. Let's do the same for Velan 20. You can see here that some other
which is the bridge for Velan 20, the local bridge party is a little worse
than the bridge. Question ten, here is the big one
I want you to think about. I have this question in the real world,
and it's likely that you will too. You will need to put in some
additional research to find the answer. We have a two part lab today, in the first part, you need to implement
RCP and add general enhancements. In Part two. Someone has broken down network. You need to find the fault and repair it. We're now going to move on
from spanning tree head over to the next video,
which looks at bundling multiple links
into a single ether channel.
