|
0:00:12
|
Continuing on with our next section here for spanning tree
|
|
0:00:16
|
we're going to talk about the new open standard versions of multiple spanning tree and rapid spanning tree
|
|
0:00:23
|
and then how this is going to affect some of the larger scale designs for Layer 2 topologies.
|
|
0:00:29
|
Now as I just mentioned both multiple spanning tree and rapid spanning tree are open standard so you can see the
|
|
0:00:36
|
their definitions there, 802.1s and 802.1w respectively. Where essentially
|
|
0:00:43
|
these are an open standard response to Cisco's per VLAN spanning tree and per VLAN spanning tree plus.
|
|
0:00:49
|
So a lot of the features like the port fast, the uplink fast, the backbone fast,
|
|
0:00:55
|
that type of stuff is automatically integrated into rapid spanning tree.
|
|
0:00:59
|
You don't need to explicitly configure it to get those to work.
|
|
0:01:04
|
Now the major difference between multiple spanning tree and per VLAN spanning tree
|
|
0:01:09
|
is that with PVST we have one instance of spanning tree for every VLAN that we have.
|
|
0:01:16
|
This disadvantage of this is that if there are a number of VLANs that are sharing the same physical forwarding path
|
|
0:01:24
|
we still need to do a separate root bridge election and root port election on a per instance basis.
|
|
0:01:31
|
So typically what you see in many network designs is that if you are trying to affect the path selection for VLANs 10, 20, and 30,
|
|
0:01:40
|
and the path selection all ends up to be the same, effectively it would be the same if you had just one instance that you could group all three of the VLANs together.
|
|
0:01:50
|
So multiple spanning tree is generally less overhead than per VLAN spanning tree because we get to define which particular VLANs map to the spanning tree instances.
|
|
0:02:01
|
Now we'll also see that with multiple spanning tree it is higher scalability. It has higher scalability than per VLAN spanning tree
|
|
0:02:15
|
because we have what is known as intra versus inter region operability where with intra region operability
|
|
0:02:26
|
devices share the same instances of multiple spanning tree which will be their VLAN to instance mappings
|
|
0:02:33
|
and two variables that are the configuration revision number and the name.
|
|
0:02:39
|
We'll see on the command line that we will define all three of these variables, the VLAN to instance mappings,
|
|
0:02:46
|
the revision number plus the region, and any of the switches that share that are going to be in the same region.
|
|
0:02:53
|
Any bridges that do not share that information will be considered in different regions
|
|
0:02:58
|
and we will have a different path selection that applies to them versus devices that are inside the same region.
|
|
0:03:06
|
Now the overall goal with this design is that between regions
|
|
0:03:12
|
we hide not only the reachability information of the particulars of the topology but we also hide the failure information.
|
|
0:03:21
|
So if a link goes down and a particular needs to re-converge it's not necessarily going to affect all of the other regions in the network.
|
|
0:03:32
|
So it kind of compartmentalizes the failure scenarios for the large scale network.
|
|
0:03:39
|
There's a question here - did you say with rapid spanning tree to enable uplink fast and backbone fast you don't need to do anything, it is enabled by default? Correct.
|
|
0:03:50
|
So technically it's not the exact same thing as uplink fast and backbone fast but it has the same end result.
|
|
0:03:58
|
So behind the scenes it's implemented differently pragmatically but the end result that if one of our links to the root bridge goes down
|
|
0:04:05
|
we can immediately start forwarding over to the alternate port. We do have the ability to do that in rapid spanning tree.
|
|
0:04:12
|
The same with the backbone fast. If we see that a BPDU has changed and on our root port we receive an inferior advertisement
|
|
0:04:21
|
then the switches can automatically re-converge quickly.
|
|
0:04:28
|
Now the path selection both for the root bridge election and then the root port and designated port elections
|
|
0:04:36
|
it's going to use the same logic as we saw previously with per VLAN spanning tree and then the legacy common spanning tree.
|
|
0:04:43
|
For the root bridge election we will look at the bridge ID which again is made up of the priority, the system ID extension, and the MAC address.
|
|
0:04:54
|
Just like per VLAN and common spanning tree, the priority is going to be 32768 by default so that means that whoever has the lower MAC address
|
|
0:05:05
|
would be preferred as the root bridge automatically. Again, the key result of this in your production network
|
|
0:05:15
|
is that your older switches would be more likely to be elected the root bridge versus the newer ones.
|
|
0:05:21
|
So any time you have spanning tree running over multiple Layer 2 devices usually it is a good idea to check which of them is elected the root
|
|
0:05:29
|
and make sure that it is something that is central to the network.
|
|
0:05:33
|
So if you have the traditional three layer design where you have access distribution and core
|
|
0:05:39
|
typically you would want the root bridge to be somewhere in the core or somewhere in the distribution depending on what the physical topology looks like.
|
|
0:05:48
|
But we'll see with multiple spanning tree the election process is going to be the same.
|
|
0:05:52
|
So this means that if we want to change who the root bridge is we can change the priority where a lower number is going to be preferred over a higher number.
|
|
0:06:01
|
For the root port election, same three step process we go through. We look at the lower cost value.
|
|
0:06:09
|
If there's a tie then we look at the upstream bridge ID. If there's a tie then we go to the upstream port ID.
|
|
0:06:16
|
Again, the very last point with the lowest port ID, we're only going to get to that point
|
|
0:06:22
|
if we have multiple connections to the same upstream bridge. So essentially two or more links between the same switches.
|
|
0:06:33
|
Configuration wise to modify these options the syntax is very similar to per VLAN spanning tree
|
|
0:06:40
|
just we are replacing the VLAN keyword with the MST keyword then the VLAN number with the instance number.
|
|
0:06:48
|
So instead of saying spanning tree VLAN 1 priority, we'll say spanning tree MST 1 priority, where one in the case of MST is some instance that we need to manually define.
|
|
0:07:00
|
So before we get to any of the manipulation of what affects the root bridge election or what affects the root port election
|
|
0:07:08
|
we need to make sure that the switches are agreeing on what are the instance numbers, what are the VLANs that belong to those instances,
|
|
0:07:16
|
and what are both the configuration revision number and the name of the region.
|
|
0:07:23
|
In our particular topology we're going to have three different instances.
|
|
0:07:30
|
Okay, we'll have VLAN 10 being one instance, VLAN 20 being a different instance, VLAN 30 being a third instance,
|
|
0:07:38
|
and then any other VLAN besides that it's going to fall back into the default instance zero.
|
|
0:07:45
|
So however many VLANs that we have we can control which particular numbers are assigned to the instance values.
|
|
0:07:56
|
So let's go to switch one to start and the first thing we need to do is go to the spanning tree MST configuration mode in global config.
|
|
0:08:08
|
This is where we define what the instance mappings are, what the name of the region is, and then what is the configuration revision number.
|
|
0:08:20
|
So these three values, these all have to match in order for the switches to be in the same region.
|
|
0:08:27
|
Okay, then we can also see we can do private VLAN advertisements in this. This would be assuming that you're running VTP version 3.
|
|
0:08:38
|
So I know that these particular platforms don't support VTP version 3
|
|
0:08:43
|
and I'm not 100% sure which ones do. It may only be some of the legacy cat OS versions, or actually the new versions of the cat OS versions would support it.
|
|
0:08:53
|
But for this and I think I mentioned this the other day, for these type of features
|
|
0:09:00
|
if you're unsure of whether your particular equipment or version is going to support it
|
|
0:09:05
|
if you go to cisco.com/go/fn for the feature navigator
|
|
0:09:12
|
you can put in either the particular feature, so in this case search by feature, or what's nice you can compare the images.
|
|
0:09:22
|
So if you're building your own home lab and you're trying to choose do I want to buy an 1841 or do I want to buy a 1825
|
|
0:09:30
|
okay, you could look at the images of both of them and then figure out which features does one of them support versus the other.
|
|
0:09:37
|
So here, let's look at this real quick. I want to see what versions and platforms actually support this. So let's go down to...let's just search for it. Let's say VTP.
|
|
0:09:52
|
VTP version 3, okay, then we can see there's an enhancement multiple spanning tree mapping propagation but let's just look at the regular version of it.
|
|
0:10:03
|
And let's see. Platform. So it says some of these do. Let's take the version first. Let's say regular IOS then the platform
|
|
0:10:21
|
It says 3560. IP services. 122505se. So it looks like the newest one does. Let me search for that. VTP version 3. It says that it does support it. Let's see what are the versions that I'm running here.
|
|
0:10:55
|
This is 12246 and it said the first support was in
|
|
0:11:07
|
12252. So assuming they're running this late of a release in the exam, then potentially you could get tested on it.
|
|
0:11:15
|
It's probably unlikely that they're running the newest, newest code because when you look at this release this may have come out just like 2 or 3 weeks ago.
|
|
0:11:23
|
So usually they'll stick with some particular train because that's what they've tested the individual features on
|
|
0:11:29
|
but since it says not it is supported technically you could get tested on it.
|
|
0:11:34
|
So you may want to try this out but if you go to the configuration guide it should be pretty much self explanatory. If we go then to
|
|
0:11:42
|
configuring VTP, configuring VTP mode
|
|
0:11:54
|
so it's pretty much the same, then configuring a VTP version 3 password
|
|
0:12:01
|
it says that if you say password hidden the secret key is set only in the VLAN database, not in the running config.
|
|
0:12:11
|
Otherwise optional secret entered directly to configure the password. The secret password must contain 32 hexadecimal characters.
|
|
0:12:17
|
This would be the pre-encrypted string then that you would put. But otherwise besides this, if we look at configuration guidelines VTP version.
|
|
0:12:37
|
When VTP version 3 device detects version 2 on a trunk port it continues to send version 3 in addition to version 2.
|
|
0:12:42
|
Okay, so it is backwards compatible with it. So otherwise the only requirement would be that you just in global config you say VTP version 3.
|
|
0:12:52
|
But again, like I talked about on the first day of class, the way that you can figure out that these features are there
|
|
0:12:58
|
is by looking at the release notes and then looking at the new feature documentation.
|
|
0:13:04
|
Because figure for every maintenance release that's coming out there's new features that they're introducing there. It's not all just bug fixes.
|
|
0:13:15
|
Okay, so let's go back to our configuration here. So for the MST we need to agree on the instances
|
|
0:13:23
|
which are the instances are the VLAN to instance mappings, what's the revision number and then what is the name.
|
|
0:13:29
|
So let's say the name here is MST 1; the revision number is 1.
|
|
0:13:36
|
Okay, now I need to know what are the instance to VLAN mappings. So first let's look at what are the VLANs that I have.
|
|
0:13:45
|
I have VLAN 1 which is the default and then 10, 20, 30, up through 100.
|
|
0:13:52
|
So let's say that in instance one,
|
|
0:13:58
|
I want VLAN 10 and 40 and 50.
|
|
0:14:07
|
In instance two I want VLAN 20 and 60 and 70 and instance three I want VLAN 30, 80.
|
|
0:14:20
|
Okay, this means that there's still a couple left over; mainly VLANs 1 and 100 which means that they will by default fall back to instance zero.
|
|
0:14:34
|
So let's look at the result of this.
|
|
0:14:40
|
Okay, we have the name, the revision number, and then the VLAN to instance mappings.
|
|
0:14:45
|
If I want the other switches to be in the same region then I'm just going to take this config and paste it into the other four.
|
|
0:14:55
|
So this is staging the configuration for them. I actually haven't enabled MST yet.
|
|
0:15:02
|
We do it incrementally by making sure everyone agrees on the region information, then we'll actually change the mode.
|
|
0:15:09
|
Okay, next step would be to change the mode. In global config we say the spanning tree mode
|
|
0:15:16
|
is multiple spanning tree where the default is per VLAN spanning tree. We'll talk about the third one, rapid per VLAN spanning tree a little bit later.
|
|
0:15:29
|
Switch three says this. Switch two says it. And then likewise switch one.
|
|
0:15:41
|
Now MST is backwards compatible with both per VLAN spanning tree and common spanning tree
|
|
0:15:48
|
so if you were to implement this in production, typically you have some sort of migration plan
|
|
0:15:53
|
where some of the network is running the new version and you're slowly migrating all of it towards that.
|
|
0:16:00
|
But in the mean time you can have inter-operability between the two and we'll take a look at that a little bit later.
|
|
0:16:06
|
At this point the four switches should be agreeing on the region information. We can verify this if we look at the show spanning tree
|
|
0:16:15
|
but now instead of saying the VLAN we'll say the instance number so show spanning tree MST 1.
|
|
0:16:25
|
The output is a little bit more compact here. We can see that it says what our bridge information is versus the root bridge.
|
|
0:16:33
|
The root bridge has this particular MAC address and this particular priority which is really this particular priority plus that system ID.
|
|
0:16:44
|
So in the case of multiple spanning tree the system ID comes from the instance number.
|
|
0:16:50
|
Now also note that the cost value is more granular to account for much higher speed interfaces like 10 gig E or 100 gig E.
|
|
0:17:00
|
With per VLAN spanning tree and common spanning tree, as you get to the much higher speed interfaces then you start to lose the visibility as to which one you would want to prefer over another.
|
|
0:17:12
|
So as you could guess, a 10 gig E link should be much more preferred than FastEthernet but in per VLAN spanning tree there's not that big of a difference in the cost values between them.
|
|
0:17:24
|
So let's look at now what do the other switches say about MST 1. Switch one is saying that my root port is FastEthernet zero slash 13.
|
|
0:17:35
|
So if we look at our topology it says the root port for this instance is this way.
|
|
0:17:42
|
Okay, I should see that 16 is running too. This interface may be disabled right now.
|
|
0:17:48
|
Let's look at switch three and yeah, that link is disabled.
|
|
0:18:01
|
Now once I enable this new link, if we look at the show spanning tree output, almost immediately
|
|
0:18:11
|
the new link is elected the root
|
|
0:18:15
|
without having to wait for the maximum age to expire; without having to go through the listening and learning phases.
|
|
0:18:22
|
The reason why is that the rapid spanning tree protocol is automatically enabled once we turn MST on.
|
|
0:18:31
|
In rapid spanning tree when the trunk links between the switches come up they use a request and response proposal process
|
|
0:18:39
|
where one switch says that I'm closer to the root. The downstream switch either agrees
|
|
0:18:45
|
and says yes you'll be my root port or disagrees and then counter offers with a new bridge ID.
|
|
0:18:53
|
So one switch could say I'm the root. Here's my info. The other switch says no, you're not the root. I have a better cost.
|
|
0:18:59
|
Okay, in which case the one who initiated the proposal would then change it's port role
|
|
0:19:04
|
from being either a designated alternate or backup port to the root port.
|
|
0:19:10
|
So building of the tree the logic is still the same where the root port faces upstream towards the root bridge
|
|
0:19:16
|
but the speed at which the ports are negotiated is much, much faster in rapid spanning tree versus the legacy common spanning tree or per VLAN spanning tree.
|
|
0:19:30
|
So now switch one says that this is my root port.
|
|
0:19:36
|
Let's look at switch three and look at the same output - show spanning tree MST 1.
|
|
0:19:44
|
Switch three says that it's root port is port channel one which is connecting us to switch four.
|
|
0:19:54
|
On switch four it says I am the root of the spanning tree. So just like we had before
|
|
0:19:59
|
in this particular topology switch four has the lowest MAC address of the four switches
|
|
0:20:05
|
so it will be elected the root bridge for all of the instances. If we simply say show spanning tree root
|
|
0:20:16
|
or show spanning tree without any options, this is going to show us all of the individual instances.
|
|
0:20:25
|
So here from spanning tree root we can see that there are four instances running: 0, 1, 2, and 3.
|
|
0:20:31
|
Zero is always going to be there. That's considered the common internal spanning tree or the CIST.
|
|
0:20:38
|
This is the instance that will be used for the inter-region interoperability.
|
|
0:20:45
|
So if multiple spanning tree is going to inter-operate with per VLAN spanning tree it does it through MST instance number zero.
|
|
0:20:55
|
We could see that the timers for multiple spanning tree are still the same as the original version
|
|
0:21:04
|
but these values are not used unless we're running it on a port between two switches that are not running rapid spanning tree.
|
|
0:21:14
|
So if one switch sends the proposal and it does not get a response back in
|
|
0:21:19
|
then it treats that as a normal legacy spanning tree instance or spanning tree interface where we used the forwarding delay to transition from discarding to forwarding
|
|
0:21:32
|
and we have to wait for the maximum age to expire before we can declare the remote neighbor down.
|
|
0:21:45
|
So now let's look at a case where we're going to modify
|
|
0:21:49
|
the root bridge election. We'll say that for instance number one which is VLAN 10
|
|
0:21:57
|
plus a few others. I believe I said 40 and 50. For instance number one we will configure switch one to be the root.
|
|
0:22:09
|
This will be the MST one root. Then on switch three we will configure it as the MST two root.
|
|
0:22:21
|
So instead of doing this on a per VLAN basis we're now just doing it on a per instance basis.
|
|
0:22:29
|
On switch one we have a couple different options to do this. We could say spanning tree MST one
|
|
0:22:39
|
root primary, just like we did with the previous version of spanning tree, or
|
|
0:22:48
|
we could say spanning tree MST two, my priority is something lower.
|
|
0:22:54
|
Okay, just like the previous version we have to use the increments of 4096
|
|
0:22:59
|
because the bridge ID is made up of both the priority and the system ID extension which is the VLAN or instance number.
|
|
0:23:06
|
So let's say here the priority is something lower. We'll say 12288.
|
|
0:23:16
|
If we look at switch three and now say show spanning tree root, we see that for instance number two
|
|
0:23:26
|
we are the root bridge and also for instance number
|
|
0:23:33
|
actually, not for instance number zero. It says the cost is zero for instance zero though. But for instance two
|
|
0:23:41
|
we see that we are the root bridge for two reason. It says our cost is zero and then the root port is null.
|
|
0:23:47
|
If there's no root port it means that I locally am the root bridge.
|
|
0:23:52
|
If we look at this on switch one and show spanning tree root
|
|
0:24:03
|
switch one likewise says for MST instance one I am the root bridge and we can see the different priority values there.
|
|
0:24:12
|
So this one is with the macro automatically set. The third one there is what we manually configured on switch three.
|
|
0:24:20
|
So the end result is going to be the same whether we're using the macro or manually changing the priority, when we look at the running config
|
|
0:24:29
|
there's no difference between actually using the macro versus changing the priority.
|
|
0:24:34
|
So just like before, the macro runs only once. It does not actively monitor the priority of the root
|
|
0:24:42
|
to make sure that no one else is taking the status away. So again this would mean that I could go to switch two
|
|
0:24:50
|
and for MST instance one set the priority lower and then switch one would lose it's root state.
|
|
0:25:02
|
So now we have switch one is the root for MST instance one. We have switch three is the root for MST instance two.
|
|
0:25:10
|
If we look at the default cost values of the links
|
|
0:25:14
|
we would assume that switch two for instance number one is going to try to forward this way.
|
|
0:25:21
|
Simply based on the hop count we know that it's going to be closer to get to switch one through that directly connected interface
|
|
0:25:27
|
as opposed to going to switch three then to switch one or to switch four to switch three and then to switch one.
|
|
0:25:35
|
If we look at the details of this on switch two and say show spanning tree MST 1 detail
|
|
0:25:44
|
just like we did with the previous version of spanning tree it tells us now what are the VLANs.
|
|
0:25:53
|
It's 10, 40, and 50. This is our bridge ID. This is the root bridge.
|
|
0:26:00
|
Our root port is FastEthernet 13 with a cost of 200,000.
|
|
0:26:07
|
So this means that our local port FastEthernet 13 has a cost of 200,000.
|
|
0:26:18
|
So FastEthernet interface for MST has a cost of 200,000.
|
|
0:26:26
|
The designated bridge which in this case is the root bridge itself, so remember the designated bridge is the upstream neighbor.
|
|
0:26:32
|
It's advertising a cost of zero. So switch one is saying to get to myself I have a cost of zero.
|
|
0:26:40
|
This means that in switch two's decision process it's saying that if I were to go...
|
|
0:26:57
|
If I were to go this direction I have 200,000. If I were to go this direction I have 400,000.
|
|
0:27:08
|
Then let's look at between switch three and switch four. Let's see what's the cost of the port channel link there.
|
|
0:27:19
|
On switch four we'll say show spanning tree MST one detail
|
|
0:27:33
|
so our 200 MB per second interface, that's a cost of 100,000.
|
|
0:27:40
|
So then if we were to go to the other direction, this would be 200,000 here, 100,000 here, and then another 200 here.
|
|
0:27:51
|
So from switch two's perspective then the shortest path is just going to be to directly to switch one.
|
|
0:27:57
|
But let's say that's not the path that we wanted to forward. Okay, we want switch two to go further out of the way. We want it to go...we want it to go this direction.
|
|
0:28:13
|
From switch three we could probably assume that we're already forwarding this way because that's the directly connected interface
|
|
0:28:20
|
and then likewise switch four, since this port channel is 100k, 300,000 is going to be lower than if we were to go through switch two.
|
|
0:28:33
|
So how could we modify this then? How could we get switch two to choose FastEthernet 19 as the root port
|
|
0:28:41
|
as opposed to FastEthernet 13 which it is currently?
|
|
0:28:51
|
So regardless where we make the change we need to make sure that the cumulative cost
|
|
0:28:58
|
on switch two's FastEthernet 19 interface is lower than the cumulative cost on FastEthernet 13.
|
|
0:29:06
|
So it really doesn't matter whether we raise or lower the cost as long as the end result ends up being that one link is or one path is better than the other.
|
|
0:29:15
|
Now probably the easiest way to do it would be to raise the cost of
|
|
0:29:21
|
the connected link between switch two and switch one so then we don't have to do this on multiple devices.
|
|
0:29:27
|
But like I said, you could do it any way you want to. Within the scope of the lab exam it would just depend on what the question is asking you.
|
|
0:29:36
|
So on switch two let's go to FastEthernet 13 and we'll say for spanning tree MST instance one, I want to change the cost and we'll make this a million.
|
|
0:29:51
|
Once I make the change, if we look at instance number one we should see that now that FastEthernet 13 is no longer the root port
|
|
0:29:59
|
FastEthernet 19 is but the convergence is almost immediate.
|
|
0:30:06
|
So we don't need the old information to age out. As soon as there is a change, switch two is generating it's own BPDU
|
|
0:30:15
|
and doing a new proposal to the downstream or in this case the upstream device now, switch four is upstream of switch two.
|
|
0:30:27
|
Okay, there's a question - I still don't understand the role of VTP for multiple spanning tree.
|
|
0:30:34
|
The idea would be to advertise the instance information between the neighbors
|
|
0:30:43
|
because let's say that there's 100 switches in the network. The way that we have to do it now
|
|
0:30:50
|
is that everyone has to manually enter all this.
|
|
0:30:58
|
So this means that if we wanted to change the instance mappings, let's say just add one VLAN,
|
|
0:31:04
|
we would have to go to every single switch and make that change.
|
|
0:31:09
|
Whereas with the VTP version three, you can advertise that information.
|
|
0:31:14
|
So if we look at the...let's go to the multiple spanning tree configuration guide and let's see if it mentions that yet.
|
|
0:31:25
|
VTP. It says VTP propagation of MSD configuration is not supported however you can manually configure the
|
|
0:31:35
|
options on each switch using the CLI. So this documentation, this hasn't been updated yet. If we were to go to
|
|
0:31:48
|
let's look at the main documentation page. Let's see what like 6500 says about this. So if we go to products,
|
|
0:31:58
|
switches, core switches, 6500, configuration guides,
|
|
0:32:11
|
and I want to say 12 2 SX is higher than...
|
|
0:32:19
|
ZY. Let's try SX. Then this would be under
|
|
0:32:43
|
LAN switching. Let's try STP and MST and also VLAN trunking protocol.
|
|
0:32:53
|
So STP and MST, let's search for VTP.
|
|
0:33:00
|
No, it's not updated so you can see whatever this feature is, it's very, very new. So it's not even listed in the documentation yet.
|
|
0:33:08
|
It says in release 12 2 33 SXI VTP v3 supports MST database propagations separate from the VLAN database.
|
|
0:33:16
|
On MST propagation there's a VTP primary server and a secondary server.
|
|
0:33:21
|
Primary allows you to alter the database, secondary can only backup the updated VTP configuration.
|
|
0:33:30
|
So you say VTP primary or VTP secondary.
|
|
0:33:48
|
So you would say VTP primary MST.
|
|
0:33:56
|
VTP primary, MST force
|
|
0:34:01
|
which is that's making them become the server. So even if you were to be tested on this
|
|
0:34:07
|
you can see from the configuration guide, it's not that complicated. I highly doubt that they would test you on it
|
|
0:34:13
|
because it looks like it's the very, very latest release that has introduced it. Okay, even to the point where the documentation doesn't even show that it's supported yet.
|
|
0:34:22
|
But the idea behind it is that you would want to automatically advertise this info instead of having to manually define it.
|
|
0:34:33
|
Okay, there's a question - so typically with MST, VTP could be just left in transparent mode? You still can run VTP
|
|
0:34:43
|
but it's unrelated to the spanning tree instances. So in this case let's look at the
|
|
0:34:50
|
the show spanning tree MST configuration.
|
|
0:34:58
|
Okay, this shows us what are the VLANs that are mapped to the different instances.
|
|
0:35:04
|
So we have four instances. Three of them have been user defined. Zero is the default instance.
|
|
0:35:11
|
If we compare this to the show VLAN brief the VLAN numbers listed in the MST config
|
|
0:35:20
|
don't correspond directly to what we have in the VLAN database.
|
|
0:35:25
|
So we've created VLANs 10, 20, 30, 40, etc. We did not create VLAN
|
|
0:35:35
|
61 to 69 or 71 to 79 but the MST configuration says that if those VLANs were to exist
|
|
0:35:44
|
they would fall back to instance number zero because you have not manually defined it.
|
|
0:35:50
|
So this means that on the VTP server if I were to say VLAN 123, VLAN 234,
|
|
0:36:03
|
I'm advertising this information through VTP so now if we show VLAN brief
|
|
0:36:12
|
VLANs 123 and 234, they have been created and if we look at the show MST configuration
|
|
0:36:21
|
or show spanning tree MST configuration, those VLANs now fall back to instance number zero.
|
|
0:36:35
|
So normally you would want more control over this that if you were to add new VLANs you would want them to be in a specific instance
|
|
0:36:43
|
instead of falling back to the default one but if you don't care about the path selection then you can just let it go to instance number zero.
|
|
0:36:51
|
Just the idea is that you want granular control over the path selection but you don't want to have to run a separate instance for every single VLAN
|
|
0:37:00
|
because figure with per VLAN spanning tree, let's say you used every single VLAN, 4094 of them, the switch is not going to support running 4000 instances of spanning tree.
|
|
0:37:11
|
But with this implementation it would because...well not run 4000 instances but you would group them together.
|
|
0:37:18
|
So I'll say maybe for the standard VLANs for 2 through 1,000 I'll group those in one instance.
|
|
0:37:23
|
Then for the extended VLANs beyond that I'll put those in whatever instances I want.
|
|
0:37:31
|
Okay, there's another comment here. So even if this is used it seems like a lot of management overhead. It would be.
|
|
0:37:37
|
Okay, there's a simpler way that you could do this that if you really don't care that much about the control
|
|
0:37:44
|
you could just run in rapid per VLAN spanning tree.
|
|
0:37:50
|
With rapid per VLAN spanning tree it's the same logic as the normal per VLAN spanning tree
|
|
0:37:56
|
except you're running the new algorithm which is the
|
|
0:38:02
|
the 802.1w for the proposal process between the devices.
|
|
0:38:10
|
So with normal per VLAN spanning tree you're using the hello interval, the max age, and the forward delay in order to make sure that the network doesn't loop.
|
|
0:38:21
|
With rapid spanning tree the switches that are connected to each other are saying this is my bridge information. Do you agree or disagree with it?
|
|
0:38:29
|
Then once they go through the proposal process, that happens within like, you know, less than 100 milliseconds.
|
|
0:38:36
|
So it's really fast to converge because the control plane of it is active. It's kind of like an active adjacency that you have in your IGPs that's now what's been moved down into the rapid spanning tree.
|
|
0:38:51
|
So we could see the configuration for this, the only thing that's really different is doing the instance mappings. Once you get past this point
|
|
0:38:59
|
changing the port roles is going to be the exact same logic where we could change the cost directly, we could change the bandwidth which would implicitly change the cost,
|
|
0:39:09
|
we could change our bridge priority or our port ID which is the port priority,
|
|
0:39:15
|
but those two again would be less common. Okay? You technically can change the port ID but it's only going to be used if you have two links between the same two devices.
|
