|
0:00:12
|
The next two features here, loop guard and UDLD, or unidirectional link detection
|
|
0:00:18
|
we'll look at together even though technically only loop guard is a spanning tree feature, essentially these two are going to accomplish the same thing.
|
|
0:00:27
|
The idea is that with some physical topologies typically with fiber links there can be a case where the send channel
|
|
0:00:35
|
from one end of the link to the other is working but the received channel is not.
|
|
0:00:41
|
So with optical interfaces since we actually have two different fibers that are making up the pair
|
|
0:00:49
|
we have one physical link that is for sending the traffic and on physical link is receiving,
|
|
0:00:55
|
it is feasible to have one of the break but the other one still work.
|
|
0:01:00
|
The problem that we could run into there is that with spanning tree if we are able to send packet but we are not able to receive packets
|
|
0:01:10
|
it means that the maximum age would expire on the interface and we could run into a case where two switches
|
|
0:01:18
|
are both elected the designated port at the same time. So the case here would be that if we had
|
|
0:01:28
|
switch one as the root that is connecting down to switch two and to switch three
|
|
0:01:41
|
and we have a full mesh of connectivity between the devices.
|
|
0:01:46
|
Assuming that all of the links have the default costs and they're equal, switch two would say that this is the root port and on the other side we have the designated port.
|
|
0:01:58
|
Likewise, switch three would say this is the root port and this is the designated port.
|
|
0:02:05
|
What's going to happen between switch two and switch three in this topology?
|
|
0:02:14
|
One of those ports should be elected as designated. One of them should be in the blocking state.
|
|
0:02:21
|
So assuming that both of them have equal costs to the root bridge, let's say that every interface has a cost of one,
|
|
0:02:31
|
then how are they going to determine which one is supposed to be the designated port, which one is supposed to be the blocking port?
|
|
0:02:44
|
It should be whoever has the lower bridge priority or in the case of a tie, whoever has the lowest MAC address. So it's based on the bridge ID.
|
|
0:02:54
|
So let's assume that switch two has the lower bridge ID. So switch two's port becomes designated. Switch three's port becomes blocking.
|
|
0:03:03
|
On the blocking port we are not sending BPDUs but we are listening for BPDUs.
|
|
0:03:12
|
Now on the link between them let's assume that switch two has two physical channels that are making up the link. We have the send channel and we have the receive channel.
|
|
0:03:24
|
So each of these are going one way but together they're making up the fiber pair.
|
|
0:03:30
|
For whatever reason switch two's send channel goes down.
|
|
0:03:37
|
So switch two cannot send to switch three which means switch three cannot receive. However switch three can send to switch two and switch two can receive.
|
|
0:03:46
|
What's going to happen on switch three then? Who previously was the blocking port.
|
|
0:04:00
|
The blocking port is going to be receiving BPDUs and waiting for what to happen?
|
|
0:04:08
|
It's going to wait for the maximum age to expire because remember the MACs age is basically like the dead interval.
|
|
0:04:14
|
So after 20 seconds by default switch three says that the other end of the link is no longer sending me BPDUs
|
|
0:04:22
|
so I need to now transition from the blocking state to forwarding and now become a designated port.
|
|
0:04:31
|
So in this case both of the interfaces begin to forward at each other. We have multiple designated ports on the same segment.
|
|
0:04:39
|
This is a violation of the spanning tree logic but the problem is spanning tree cannot detect this by default because it's a Layer 1 issue; it's based on the physical link.
|
|
0:04:51
|
The solution for this then is to create some sort of Layer 1 keep alive that will be able to tell us can we both send traffic and receive traffic on the link.
|
|
0:05:05
|
This is what the spanning tree loop guard and the unidirectional link detection feature are used to do.
|
|
0:05:12
|
Unidirectional link detection could be enabled on interfaces that are not running spanning tree
|
|
0:05:18
|
but the loop guard feature is inherent to spanning tree so it has to be on a Layer 2 interface only.
|
|
0:05:25
|
Now there's a document on Cisco's website that talks about the differences between these two. If you just search for loop guard versus UDLD.
|
|
0:05:40
|
You'll see that on this particular document there's a table and you can see it explains what the case is there that I just talked about.
|
|
0:05:48
|
There's a table that says why would you want to use one versus the other. With loop guard and UDLD, both of them you configure on the port basis.
|
|
0:06:01
|
Okay for both of them you can automatically recover out of it so if the link stops becoming unidirectional then you're able to fix that.
|
|
0:06:11
|
Protection against spanning tree failures caused by unidirectional links - both of them yes when enabled on all links in the redundant topology. The difference is going to be these two.
|
|
0:06:22
|
So loop guard can prevent against failures in the spanning tree process itself which would be some sort of code bug.
|
|
0:06:33
|
So if on your switch the spanning tree software itself crashes then loop guard is going to figure that out. UDLD would not be able to do that.
|
|
0:06:42
|
Where loop guard would not be able to protect against a mis-wiring which means you accidentally plug the receive channel into the send transceiver
|
|
0:06:52
|
and vice versa, you plug what should be the send port into the receive port, loop guard is not going to be able to figure that out.
|
|
0:06:59
|
For this reason it's very common that you would run both at the same time.
|
|
0:07:06
|
So you can run both features which is going to cover you in all cases.
|
|
0:07:11
|
The difference between them being that loop guard is going to use the spanning tree BPDUs that are already there
|
|
0:07:18
|
where unidirectional link detection is using a new keep alive.
|
|
0:07:23
|
Configuration wise, if we go to the configuration guide and then the loop guard and all the other stuff that I was talking about up to this point
|
|
0:07:33
|
this is all going to be under optional spanning tree features; where unidirectional link detection, this is under it's own document.
|
|
0:07:42
|
So UDLD configuration guidelines, it says you go to the link level and you say either...actually this is in global config. You say UDLD aggressive or enable or the message timer.
|
|
0:07:55
|
Okay, UDLD aggressive mode on all fiber optic ports versus enable, there's a difference between how the keep alives work in aggressive versus enable.
|
|
0:08:06
|
There's a write up on our blog where Peter got into some details about this so if you search for site blog dot INE.com UDLD loop guard
|
|
0:08:20
|
This one - UDLD modes of operation - so there's some differences between the aggressive and the regular mode that you would run in.
|
|
0:08:33
|
But otherwise the configuration is really straightforward; just at the port level you say UDLD port or UDLD port aggressive.
|
|
0:08:43
|
Okay the difference between them, it's basically how long it takes them to figure out that the link is down.
|
|
0:08:49
|
If they think the link is down the aggressive one starts to actively send more frames to try to detect that.
|
|
0:08:56
|
For the loop guard configuration, at the interface level this is simply going to be the either...where is it here? This one says
|
|
0:09:16
|
spanning tree loop guard default. It doesn't actually show it on the interface. So it looks like for the newer versions you can do it either way. If we said spanning tree
|
|
0:09:32
|
loop guard default, okay, so that would be on every port, or you could say spanning tree guard loop.
|
|
0:09:51
|
Okay, there's a question - are the send and receive channels not different?
|
|
0:09:57
|
It depends on the physical interface. So if it's an optical interface then yes, send and receive is different.
|
|
0:10:04
|
If it's a copper interface, like an RJ-45 port, then it's less likely that you would run into that case
|
|
0:10:12
|
because it would mean that one of the single wires in the twisted pair would go down but not the other one
|
|
0:10:23
|
where usually with copper either you have 100% connectivity or no connectivity.
|
|
0:10:28
|
So you technically can use it both on fiber and copper interfaces but most of the time on copper interfaces you wouldn't really need it.
|
|
0:10:38
|
Okay, there's another question - would you configure loop guard and UDLD on both sides? Yes. So for UDLD
|
|
0:10:44
|
you want to make sure that both of the neighbors are sending and receiving the keep alives.
|
|
0:10:50
|
For loop guard technically you could configure it just on one interface but you normally would want to do it everywhere.
|
