|
0:00:13
|
So let's move on then to our
|
|
0:00:15
|
next topic which is going to be some of the more advanced options that we can change in the spanning tree domain.
|
|
0:00:22
|
First of these are going to be the timers that affect the transition between the port states.
|
|
0:00:28
|
So the port states being the down state, the blocking state, listening, learning, and forwarding
|
|
0:00:34
|
when we're talking about either the legacy common spanning tree
|
|
0:00:38
|
or the per VLAN spanning tree or per VLAN spanning tree plus.
|
|
0:00:43
|
As I mentioned these catalyst IOS switches, they are going to run PVST plus by default.
|
|
0:00:55
|
Okay, there's a question here - the command output displayed by show spanning tree root,
|
|
0:01:03
|
it displays the cumulative cost
|
|
0:01:07
|
it displays the cumulative costs to the root
|
|
0:01:10
|
sparing us the trouble of looking at the show spanning tree detail. Correct.
|
|
0:01:14
|
So when we look at this output here, it's show spanning tree root,
|
|
0:01:18
|
this cost value here, this is our total end to end cost along the path.
|
|
0:01:26
|
Now we could see this also just by looking at the show spanning tree, if I said show spanning tree VLAN one,
|
|
0:01:33
|
it tells us what the root cost is here but it really doesn't tell us why that was derived.
|
|
0:01:40
|
So you can use either of those outputs to see it
|
|
0:01:44
|
but only show spanning tree detail is really going to tell you why it got that cost in the first place.
|
|
0:02:04
|
So again here with the timers, this is going to affect how long we have to wait in the different port state
|
|
0:02:09
|
which ultimately affects what the convergence time is going to be for spanning tree.
|
|
0:02:15
|
Now there's three timers that we use in either common or per VLAN spanning tree in order to converge.
|
|
0:02:21
|
They are the hello, maximum age, and the forwarding delay.
|
|
0:02:25
|
The hello timer as you can probably guess it's how often you send BPDUs.
|
|
0:02:30
|
Okay, just like an OSPF hello interval or EIGRP hello interval, that's how long we're sending basically the keep alives out the interfaces.
|
|
0:02:38
|
So this defaults to two seconds and this is going to be controlled by the root bridge.
|
|
0:02:45
|
So in common spanning tree and per VLAN spanning tree, only the root bridge is allowed to generate BPDUs.
|
|
0:02:53
|
So BPDUs basically start at the root of the spanning tree and then flow down towards the leaves.
|
|
0:03:01
|
We'll see in the next revision of spanning tree for rapid spanning tree,
|
|
0:03:06
|
the BPDUs are generated on a hop by hop basis.
|
|
0:03:09
|
But with the legacy versions it's only the root bridge that is generating these.
|
|
0:03:14
|
Next we have the maximum age. This controls how long you will wait for a hello before essentially declaring the neighbor down.
|
|
0:03:23
|
So the maximum age you can think of this like the dead interval in OSPF.
|
|
0:03:28
|
So if we have a link that is in the blocking state, it means that we previously heard a BPDU from some other neighbor on the segment,
|
|
0:03:37
|
and their cost to the root was better, whether it's based on the actual cost value or based on their bridge ID,
|
|
0:03:44
|
they were the preferred device on that link to become the designated port.
|
|
0:03:51
|
Or likewise on our root port, we would be receiving BPDUs from the designated port on the other side.
|
|
0:03:59
|
So a maximum age says that if I didn't receive a BPDU for the last twenty seconds
|
|
0:04:04
|
then I'm going to start recalculating that state.
|
|
0:04:08
|
So I'll assume that what ever BPDUs came in there, they're no longer valid and I need to look at some other path towards the root bridge.
|
|
0:04:17
|
Then lastly we have the forwarding delay.
|
|
0:04:20
|
This is how long the router stays in each of the listening and learning phases when it is building the CAM table.
|
|
0:04:29
|
So essentially when an interface comes from the disabled state or the blocking state and attempts to go to forwarding
|
|
0:04:37
|
the first thing the switch tries to do is figure out what are the end hosts in the network.
|
|
0:04:42
|
And it does this by listening for BPDUs then learning where it's actually inserting MAC addresses into the cam table
|
|
0:04:51
|
with the assumption that when we actually get to forwarding we're going to need these MAC addresses to actually switch the packets.
|
|
0:04:58
|
So listening is just seeing if the BPDUs are coming in, the learning is where we're actually building the cam table,
|
|
0:05:03
|
and then finally we go to forwarding which is sending and receiving traffic.
|
|
0:05:08
|
The forward delay by default is fifteen seconds which means that the total of listening and learning together is thirty seconds.
|
|
0:05:17
|
So we should see that as a worst case scenario for the default spanning tree timers
|
|
0:05:23
|
the convergence time can be as long as fifty seconds.
|
|
0:05:27
|
So if we were moving from blocking to forwarding
|
|
0:05:33
|
we would have to wait twenty seconds for the maximum age to expire
|
|
0:05:37
|
then we would elect ourselves as a root port or a designated port
|
|
0:05:42
|
go through both the listening and learning phases before we can actually start to forward traffic.
|
|
0:05:48
|
The key for all of these timers though is that they're only set on the root bridge.
|
|
0:05:54
|
Configuration wise we set them in global config
|
|
0:05:58
|
on a per VLAN basis or a per instance of spanning tree.
|
|
0:06:03
|
Then when we look at the show spanning tree VLAN or the show spanning tree root
|
|
0:06:08
|
we can see the particular timers that the root bridge has configured.
|
|
0:06:14
|
So if we look at this on the command line and on switch one we see the output from the show spanning tree VLAN one.
|
|
0:06:21
|
Whoever is the root bridge here has the default hello time of two seconds, maximum age of twenty, and the forwarding delay of fifteen.
|
|
0:06:31
|
So let's see here who is this root bridge. So who has this particular MAC address.
|
|
0:06:38
|
So let's go to the switches, the other switches, we'll say show spanning tree VLAN one.
|
|
0:06:46
|
Okay, switch two is not the root bridge and switch three, if we show spanning tree
|
|
0:06:52
|
VLAN one, likewise switch three is not the root bridge
|
|
0:06:58
|
which should leave us with switch four. Okay, switch four it says this bridge is the root.
|
|
0:07:04
|
So if we were to modify the timers, if we say spanning tree for VLAN
|
|
0:07:12
|
for VLAN one, I want to change what is the hello time.
|
|
0:07:18
|
Let's say that we're sending hellos every one second.
|
|
0:07:21
|
Okay, I'll also change what the maximum age is. Let's say the max age is five seconds.
|
|
0:07:30
|
Actually that's below the minimum. Let's say ten seconds. Okay, so we'll set it to be half.
|
|
0:07:36
|
Then the forward time, this is for each of listening and learning, not total.
|
|
0:07:44
|
So if I were to say five, it means that as a total it's going to take me ten seconds to get through both listening and learning.
|
|
0:07:56
|
Now if we look at the other switches, let's go back to switch one and look at the show spanning tree VLAN one output again.
|
|
0:08:03
|
We can see now those timers have changed so in the root bridge's BPDU
|
|
0:08:09
|
the hello is one, the max age is ten, and the forward delay is five.
|
|
0:08:14
|
If I were to be elected the root bridge, my timers would be two, twenty, and fifteen, which are the defaults.
|
|
0:08:22
|
But the key point with the legacy common spanning tree or PVST and PVST plus,
|
|
0:08:28
|
is that the root bridge is the only device that's generating the BPDUs.
|
|
0:08:32
|
So whatever timer value is set on the root bridge that's the one that's going to affect everyone else in the network.
|
|
0:08:40
|
Now I could change these on switch one but the key point is that it's not going to affect anything until switch one actually becomes the root bridge.
|
|
0:08:49
|
So if you had some sort of design where you had a primary root and then some sort of back of root bridge
|
|
0:08:55
|
you would want to make sure that the timers match on all of them so that if the secondary device takes over
|
|
0:09:01
|
that it's still using the timer values that you had wanted it to.
|
|
0:09:12
|
Now in any case, most of the time you wouldn't even want to change these timers.
|
|
0:09:16
|
If you're trying to speed up convergence there's other features that we can enable
|
|
0:09:21
|
or we could just run rapid spanning tree which is not really going to need these to begin with.
|
|
0:09:35
|
So now let's talk about what are some of these features that we can use in order to speed up the convergence of the network.
|
|
0:09:42
|
Okay, the first one we have is the port fast feature which is designed for edge ports
|
|
0:09:47
|
which are going down to end hosts or phones or printers,
|
|
0:09:51
|
something at the edge of the network that does not actually running spanning tree.
|
|
0:09:57
|
So since the link is not running spanning tree we're going to assume that there's no Layer 1 loop in the network
|
|
0:10:03
|
so we don't really have to go through the listening and learning phases.
|
|
0:10:08
|
Now when we turn port fast on an interface it does not mean that spanning tree is disabled,
|
|
0:10:13
|
it just means that we go from blocking to forwarding or disabled to forwarding
|
|
0:10:20
|
without having to go through the listening and learning phases.
|
|
0:10:24
|
Now we'll see when we look at this on the command line, using port fast also affects the topology change notification
|
|
0:10:32
|
that is usually generated by the leafs of the spanning tree
|
|
0:10:37
|
to tell the root bridge that something is changed in the network and we need to do a recalculation.
|
|
0:10:43
|
So in any spanning tree design, for every single port that connects to a device that does not run spanning tree
|
|
0:10:50
|
you should be configuring this as an edge port.
|
|
0:10:54
|
So whether it goes to your end host, whether it goes to your phones, to anything else that's not another switch,
|
|
0:10:59
|
these interfaces should always be running as port fast mode.
|
|
0:11:11
|
So let's look at the topology here that we're using for today. It's pretty similar to what we saw yesterday
|
|
0:11:18
|
but now I have the six different routers,
|
|
0:11:21
|
router one through router six, preconfigured in three different VLANs.
|
|
0:11:26
|
So routers one and two, they're in VLAN ten and they're using the subnet ten.
|
|
0:11:32
|
So router one is ten zero zero one; router two is ten zero zero two.
|
|
0:11:39
|
Router three and four, they are in VLAN twenty and then likewise they're addresses are twenty zero zero three
|
|
0:11:47
|
and twenty zero zero four. So we have the routers spread out between the different four switches
|
|
0:11:53
|
which is going to give us some diversity in the path selection that we're going to be changing.
|
|
0:11:58
|
So first let's look at switch one and see what happens when router one enables or disables it link
|
|
0:12:06
|
from the perspective of the convergence.
|
|
0:12:20
|
So on switch one let's look at the show spanning tree for VLAN ten.
|
|
0:12:26
|
It says that the link going down to router one is a designated port and it is in the forwarding state.
|
|
0:12:33
|
Okay, the timers that the root bridge is advertising are the defaults. We're using two, twenty, and fifteen.
|
|
0:12:42
|
So to speed up the demonstration here a little bit I'm also going to change these again on switch four.
|
|
0:12:48
|
So on switch four let's say show run include spanning tree.
|
|
0:12:54
|
And these three commands I'm going to do the same thing but I'm going to do this for VLAN ten.
|
|
0:13:03
|
So let's say for VLAN ten the hello forwarding
|
|
0:13:08
|
and the max age timers are one, five, and ten respectively.
|
|
0:13:28
|
So now when we verify this on switch one with the show spanning tree VLAN ten
|
|
0:13:33
|
we can see that the timers have changed so hello was one second, max age is ten, the forwarding delay is five.
|
|
0:13:39
|
On switch one I'm going to enable time stamps for the logs so we'll say service time stamps
|
|
0:13:46
|
for my actually debug messages and let's say uptime
|
|
0:14:00
|
and
|
|
0:14:04
|
actually let's say show
|
|
0:14:09
|
show version should show us the uptime
|
|
0:14:12
|
so the counter is going to be somewhere around twenty hours, ten minutes since the last time that it was reloaded.
|
|
0:14:19
|
So on switch one now let's look at the debug spanning tree
|
|
0:14:24
|
events.
|
|
0:14:25
|
Okay, spanning tree events should show us the progression through the different phases of the interfaces.
|
|
0:14:32
|
So as we move from disabled to listening to learning to forwarding or from blocking to listening to learning to forwarding.
|
|
0:14:41
|
On router one next I'm going to disable the interface.
|
|
0:14:47
|
Okay, this should cause switch one to generate a topology change notification
|
|
0:14:52
|
to tell the root bridge that some interface has now left the tree for that particular instance.
|
|
0:15:00
|
If we were to go to switch four and look at the same thing, so switch four is the root bridge, we'll look at debug spanning tree events
|
|
0:15:08
|
we should see that when the interface comes back up
|
|
0:15:13
|
switch one is going to generate a new topology change notification
|
|
0:15:22
|
so we see we're moving from
|
|
0:15:27
|
listening to learning to forwarding. We could see each of those took five seconds so from
|
|
0:15:35
|
eight seconds after, thirteen seconds after we move from listening to learning
|
|
0:15:39
|
then from thirteen to eighteen seconds after we move from learning to forwarding
|
|
0:15:43
|
once the link is in the forwarding state now we send the topology change notification.
|
|
0:15:49
|
When switch four gets this
|
|
0:15:52
|
it is going to respond with a topology change in its own configuration BPDU
|
|
0:15:59
|
which is going to do what?
|
|
0:16:03
|
What is the topology change notification do in the spanning tree domain?
|
|
0:16:19
|
Okay, it's not technically a recalculation. It kind of you could consider it as a recalculation.
|
|
0:16:26
|
Basically what it's trying to do is tell the switches that you need to flush out your MAC address tables or flush out the cam table.
|
|
0:16:33
|
Okay, the way it does this is that it sets the cam aging time to be equal to the max age.
|
|
0:16:41
|
So if we were to look at switch two for example
|
|
0:16:45
|
and say show MAC address table aging,
|
|
0:16:50
|
the default aging time is 300 and I'm assuming that this is going to be 300 seconds not 300 minutes.
|
|
0:16:57
|
So if we say MAC address table aging time, it's in seconds. Okay, so 300 there should be the default.
|
|
0:17:07
|
Okay, so then this means that 300 seconds divided by 60 is five minutes by default.
|
|
0:17:16
|
So normally a MAC address is going to stay in the table for five minutes
|
|
0:17:21
|
if it has been idle. So every time that a host sends traffic into the network
|
|
0:17:27
|
the switch is going to reset this timer for that particular MAC address. Okay, it's basically an idle timer.
|
|
0:17:33
|
Now if the MAC address is not in the table
|
|
0:17:37
|
when the switch receives a frame that is going to that particular host, what is it going to do?
|
|
0:17:48
|
So if switch two receives a frame for a destination it doesn't know it's going to flood the frame.
|
|
0:17:53
|
So it treats it since it's an unknown unicast packet or it could be a broadcast, it's going to send it out every port that's in that particular VLAN.
|
|
0:18:03
|
Now the place that this becomes a problem
|
|
0:18:07
|
is that we know router one's interface is an edge port.
|
|
0:18:12
|
Okay, router one is not running spanning tree. It's basically an end host in the network.
|
|
0:18:16
|
So there's no reason that when router one connects its interface or disconnects it interface
|
|
0:18:22
|
that it should cause the entire cam table of the whole network to age out.
|
|
0:18:28
|
So this means that if you do not set the interfaces at the edge to be port fast ports,
|
|
0:18:35
|
you'll have tons of unknown unicast frames being flooded through the network.
|
|
0:18:40
|
So you'll see that the host will have to keep sending ARP requests for each other or the actual unicast frames are going to be treated like broadcasts.
|
|
0:18:49
|
Now we can actually see this in action if we ping between router one and router two.
|
|
0:18:55
|
Okay, we see that router one has reachability to router two.
|
|
0:18:58
|
And what I've also done on these interfaces to make it a little bit easier for us to read
|
|
0:19:03
|
I've change the MAC addresses of all the routers so that router ones address ends in zero zero zero zero one
|
|
0:19:12
|
where router twos address ends in all zeros and then a two.
|
|
0:19:19
|
So every interface that is shown in the diagram, I have that MAC address command on
|
|
0:19:23
|
So when we're looking at the cam table it makes it a little bit easier to read.
|
|
0:19:28
|
Now if we look at the topology here, let's figure out for VLAN ten
|
|
0:19:34
|
what is the forwarding path from the edges of the network up to the root.
|
|
0:19:40
|
Now we looked at this before on switch one. We know that switch one's forwarding path
|
|
0:19:45
|
goes to switch three and then from switch three it's using this port channel.
|
|
0:19:51
|
Okay, that's going to be the lowest cost path which was the cost of thirty-one versus the thirty-eight.
|
|
0:19:56
|
Switch two is directly connected to switch four so it's going to use this direct connection
|
|
0:20:03
|
on FastEthernet nineteen to get to the root bridge. So this essentially means that the link between
|
|
0:20:10
|
switch two and switch three and the link between switch one and switch two, this should not be used for forwarding traffic.
|
|
0:20:18
|
So if we look at the cam table
|
|
0:20:20
|
the cam table should only have entries on switch one's port 16,
|
|
0:20:25
|
switch three's port 13 plus the port channel, switch two's port 19,
|
|
0:20:32
|
then every interface on the root bridge can have addresses in the cam table.
|
|
0:20:37
|
So if switch one is sending a frame to switch two
|
|
0:20:42
|
because router one and router two are connected to switch one and switch two respectively, the traffic is going to have to go this way.
|
|
0:20:51
|
This means that all four of these switches should know about the MAC addresses of router one and router two.
|
|
0:20:57
|
So once it does the initial flooding then they're going to know where those unicast destination is actually located.
|
|
0:21:04
|
Now we can see this if we go to any of these switches and let's say on switch three
|
|
0:21:09
|
we say show MAC address table dynamic for that particular VLAN.
|
|
0:21:15
|
Okay, we see router one and router two's MAC addresses. They're the ones that end in zero zero zero one and zero zero two respectively.
|
|
0:21:22
|
Now if we go to...and also on switch three, let's look at the debug spanning tree events.
|
|
0:21:30
|
If we go to router one and shut the interface down again
|
|
0:21:35
|
this will then cause a topology change notification
|
|
0:21:40
|
to be received or actually generated by switch one, switch one sends it to switch three,
|
|
0:21:46
|
switch three then sends it up toward the root bridge. Once the root bridge replies back,
|
|
0:21:52
|
we should see that the cam table will then get flushed out.
|
|
0:21:57
|
Okay, it depends where exactly the event happens but if we look at this on
|
|
0:22:03
|
switch one
|
|
0:22:12
|
we see switch one does have the MAC address of two. Let's see if anybody else flushed this out.
|
|
0:22:32
|
And let's see what are timers are here. If we show spanning tree VLAN ten,
|
|
0:22:38
|
okay, the maximum age is ten seconds
|
|
0:22:49
|
so we should be removing the MAC address. It could be that router two is generating frames
|
|
0:22:56
|
that's causing a keep alive there. Let's clear the ARP cache on one and two
|
|
0:23:08
|
and then we'll bring the interface back up. So now on switch one
|
|
0:23:15
|
this is going to cause another topology change - we're going from disabled to listening to learning and then to forwarding.
|
|
0:23:21
|
Once we go into the forwarding state we should see the topology change sent.
|
|
0:23:25
|
Okay, then if we look at the cam tables
|
|
0:23:30
|
show MAC address table dynamic VLAN ten
|
|
0:23:43
|
uh, wrong output. I need to say show MAC address table dynamic VLAN ten.
|
|
0:23:49
|
Okay, we see now the MAC address of router two is gone.
|
|
0:23:56
|
We know we didn't hit five minutes since the last time we sent a frame.
|
|
0:24:00
|
It's the fact that the topology change was generated
|
|
0:24:04
|
which flushes out the cam table for that entire VLAN.
|
|
0:24:09
|
So figure if you have 100 hosts that are in VLAN ten spread across the network,
|
|
0:24:14
|
every time one of them plugs into the network
|
|
0:24:17
|
it's going to flush out all of the other MAC addresses unless they are sending traffic exactly at that time.
|
|
0:24:23
|
So the cam aging time is an idle time out. It's not an absolute timeout.
|
|
0:24:28
|
But it becomes inefficient when you're using these default convergence timers.
|
|
0:24:35
|
So not only is the portfast feature used to skip over the listening and learning phases
|
|
0:24:41
|
really what it is meant to do is not generate the TCN.
|
|
0:24:47
|
So if we go to switch one and say at the port level spanning tree portfast
|
|
0:24:53
|
the next time we go to router one and shut down the link
|
|
0:24:59
|
switch one knows that the link is down but this does not generate a TCN.
|
|
0:25:06
|
If we go to router one and bring the interface back up
|
|
0:25:11
|
switch one is going to say we'll jump immediately from forwarding, or excuse me, from blocking to forwarding
|
|
0:25:18
|
because we're no longer going through the listening and learning phases.
|
|
0:25:23
|
So it actually has dual functionality here. It's used to
|
|
0:25:27
|
make sure the edge ports are not subject to the forwarding delay so they don't have to wait that 30 seconds by default
|
|
0:25:34
|
but also it's an optimization so that the cam table does not get flushed out
|
|
0:25:39
|
so it cuts down on the amount of unknown unicast flooding in the network.
|
|
0:25:46
|
Now as I mentioned when port fast is on it does not mean that spanning tree is disabled.
|
|
0:25:52
|
The switch is still sending BPDUs and listening for BPDUs
|
|
0:25:57
|
and there is a default protection mechanism built in
|
|
0:26:00
|
that if BPDUs are received on the interface, which is an indication that someone is running spanning tree,
|
|
0:26:07
|
the switch will automatically revert the port out of its edge status or out of it's portfast status.
|
|
0:26:15
|
Now we can see this on switch one if we look at the show spanning tree for VLAN ten.
|
|
0:26:22
|
It says that FastEthernet zero slash one, this is a point to point edge port.
|
|
0:26:29
|
So this is a port running port fast.
|
|
0:26:31
|
If it goes up or down it's not going to be subject to the forwarding delay and we're not going to generate a topology change notification.
|
|
0:26:43
|
Now in addition to this if the interface were to start running spanning tree
|
|
0:26:49
|
we will remove it out of it's edge state and generate a topology change.
|
|
0:26:55
|
So on switch one if we look at the show interface or show spanning tree
|
|
0:27:00
|
interface FastEthernet one portfast, it says portfast is enabled for VLAN ten.
|
|
0:27:07
|
If we look at the show spanning tree interface FastEthernet zero slash one detail
|
|
0:27:17
|
we see that we are sending BPDUs but we haven't received any.
|
|
0:27:25
|
And we haven't received any because router one's not running spanning tree. It's just a regular end host.
|
|
0:27:29
|
But if we look at this counter we should see that the value is going to go up.
|
|
0:27:35
|
So if we show spanning tree interface FastEthernet zero slash one detail and I'll include just BPDUs.
|
|
0:27:44
|
Okay, we'll see based on whatever the configuration BPDU timer is, basically the hello timer,
|
|
0:27:50
|
that's how often we're going to be sending them out the link and in this case our timer is set to one second.
|
|
0:27:58
|
And again we can see PortFast e is on.
|
|
0:28:01
|
Now if we were to go to router one, and let's make sure I'm still debugging here. Okay, we're debugging spanning tree events.
|
|
0:28:08
|
On router one, I am going to run spanning tree.
|
|
0:28:12
|
We'll say bridge one protocol IEEE. Okay, this is turning the
|
|
0:28:21
|
spanning tree instance on for bridge group one. Okay, again, bridge group one is basically a VLAN.
|
|
0:28:27
|
Then at the interface level we'll say bridge one protocol IEEE, or not bridge group one,
|
|
0:28:34
|
just bridge group one on it's own. Okay, that's assigning the link to the bridge group. We're assigning it to the VLAN basically.
|
|
0:28:41
|
Now when we look at switch one, it says that we heard a BPDU,
|
|
0:28:47
|
okay, and specifically we heard a new root advertisement on FastEthernet zero slash one.
|
|
0:28:53
|
It says that the new bridge ID, 3276800DBC00 etc. on FastEthernet one, it's superseding the old one.
|
|
0:29:05
|
Okay, the old one had a priority of 32778.
|
|
0:29:08
|
The new one is 32768 so this one is better.
|
|
0:29:13
|
This means that we need to transition this from blocking to forwarding.
|
|
0:29:19
|
Once it becomes the forwarding state this is going to be the root port.
|
|
0:29:24
|
So now if we look at the show spanning tree VLAN ten,
|
|
0:29:33
|
this interface is the root port. Notice that it is no longer an edge port.
|
|
0:29:41
|
If we look at show spanning tree interface FastEthernet one portfast, portfast is now off.
|
|
0:29:49
|
If we look at the detail of the link we can see now the BPDUs are being sent and they are being received.
|
|
0:29:59
|
So the key point here is that you technically could enable portfast on every single interface.
|
|
0:30:06
|
The switch will automatically figure out which interfaces are supposed to run portfast and which ones should not.
|
|
0:30:13
|
And it's based on the fact that any interface that receives BPDUs, it cannot be in the portfast state.
|
|
0:30:21
|
This is where the global command spanning tree portfast default comes in.
|
|
0:30:28
|
This command says I'll just run portfast on every interface. I already have this protection mechanism built in
|
|
0:30:35
|
that's going to figure out which ones should run port fast and which ones should not
|
|
0:30:40
|
so I can just enable it everywhere. Okay, this command here, this would be the equivalent
|
|
0:30:46
|
of saying interface range FastEthernet one to twenty-four and from Gig zero one to two spanning tree portfast.
|
|
0:31:04
|
Okay the difference being then it's just one command to enter in global config as opposed to a bunch of them at the individual interface levels.
|
|
0:31:14
|
Now if we do have the global process enabled, which is again this command, spanning tree portfast default,
|
|
0:31:20
|
we still can go to an individual link and turn the process off by saying no spanning tree portfast.
|
|
0:31:30
|
For trunk interfaces, portfast will not be on by default
|
|
0:31:36
|
even if the link is not receiving BPDUs. So if we look at the show
|
|
0:31:43
|
show interface trunk, right now 13 and 16 are trunk interfaces. If we show
|
|
0:31:50
|
spanning tree interface FA zero slash 13 portfast,
|
|
0:31:57
|
portfast is disabled for all of those instances of spanning tree.
|
|
0:32:04
|
You could technically have a case where the interface is a trunk but it's also an edge port at the same time.
|
|
0:32:12
|
That would typically be the case where the trunk is going down to one of your servers.
|
|
0:32:17
|
So let's say that on switch one, we have some link here, let's say FastEthernet ten,
|
|
0:32:23
|
that is going to some VMware server that has a bunch of different VLANs. So this is a trunk.
|
|
0:32:31
|
We know that the server itself is not running spanning tree so it's okay to define that as an edge port.
|
|
0:32:37
|
In this case we would go to the individual link level,
|
|
0:32:42
|
interface FastEthernet ten and say spanning tree portfast trunk.
|
|
0:32:50
|
So this is forcing spanning tree to be on even if the interface is in trunking mode.
|
|
0:32:55
|
Previously portfast would only run if the link was in access mode.
|
|
0:33:02
|
So if we now say switchport trunk encapsulation dot1q switchport mode trunk
|
|
0:33:12
|
if this interface were to come up, in this case it's not actually connected to anything. Okay, we see it's not connected.
|
|
0:33:20
|
If the line protocol came up here we would see that all of the VLANs that we have in the database
|
|
0:33:27
|
by looking at the show interface trunk.
|
|
0:33:31
|
Once all of these VLANs begin to forward on that new trunk interface
|
|
0:33:36
|
they're not going to listen for changes in the spanning tree domain.
|
|
0:33:41
|
So if the trunk link goes down or comes back up, it's not going to generate a topology change.
|
|
0:33:46
|
Additionally when it goes from blocking to forwarding or from disabled to forwarding,
|
|
0:33:51
|
we're not going to have to go through the listening and learning phases.
|
