Well, in the last skill, we just took a look at a situation where we had switch
one as the root and then we saw this indirect failure concept and this is
where the max age timer really came into play because switch three or rather
switch two over here, switch three was on the right, switch two had a failure
and
it's uplink on here but switch three had lost that battle I suppose if you
want to call it that with switch two and it placed its port into the blocking
state and because switch two try sending now superior BPDUs having lost its WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
state and because switch two try sending now superior BPDUs having lost its
root port and now thinks it's the root switch three is just going to ignore
these superior BPDUs until the max age timer has expired at which point it
says hey that original BPDU has now timed out that takes 20 seconds at that
point we transition from blocking to whoops listening to learning and this
whole
process takes 30 seconds so 20 seconds to detect plus 30 seconds means we're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
process takes 30 seconds so 20 seconds to detect plus 30 seconds means we're
down for 50 seconds so that the end of the day the max age timer is going to
help us out here but it does take some time for us to come back online and so
what we transition to from a topology perspective looks like this where we have
switch one connecting to switch three and then switch two over here now let's
look
at this scenario in a little bit greater detail because what we just said is
that
we have now failed over but we have a different aspect of layer two to keep in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we have now failed over but we have a different aspect of layer two to keep in
mind me specifically what happens when we have hosts hanging off of switch two
so
they were up here in this situation as well and so we have MAC address A and
MAC address B looking up here at the original topology if I got a path
back it in before everything went down and it was destined for MAC address A WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
back it in before everything went down and it was destined for MAC address A
where would switch three send it well if switch three knows where MAC address A
lives and eventually it will so let's just assume that it does know it's going
to point out this way because this port here is blocked meaning that this path
goes around like this which is perfectly fine we're not looking for
efficiency here we're we're looking for loop prevention and we have prevented
this loop and so yeah we go up through switch one down to switch two which
means
I have an entry in here that points towards let's just say this is gig zero WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I have an entry in here that points towards let's just say this is gig zero
zero on this network so I point to gig zero zero which is going to take me to
switch one well now that we have failed over what does the cam table look like
here on switch three well it without any other mechanisms at play it's not
going
to change if I get a packet in here destined for MAC address A it's still
going to see MAC address A living out gig zero zero so what's it going to do WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to see MAC address A living out gig zero zero so what's it going to do
it's going to send it up to switch one and switch one's going to say well wait
a
second I showed that it was out this port this port is down therefore I have no
location for it so what does a switch do when it doesn't have an entry for a
MAC address it's going to flood it out so it's going to flood it out all of
these
ports but the rule is I can't flood it back out the same port that I received
it on which means it's never going to find it this traffic is just going to
go to switch one yeah technically get flooded out but ultimately it's just WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
go to switch one yeah technically get flooded out but ultimately it's just
going to get dropped it's going to hit a dead end at switch one it will never
get down here to where the host actually lives this right here this entry is a
problem because that MAC address no longer lives out gig zero slash zero and
the
reason it no longer lives out there is because there was a topology change any
time we have a topology change it's entirely possible that our cam table WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
time we have a topology change it's entirely possible that our cam table
entries our MAC address entries are out of date and therefore we need to do
something about this because there is a scenario where host A here MAC address
A is just listening so if it's just listening for traffic meaning it's not
generating traffic well then we're going to be sitting here listening for and
waiting for a long time a standard cam timeout by default at least on Cisco WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
waiting for a long time a standard cam timeout by default at least on Cisco
switches is 300 seconds which is five minutes so we're going to have to wait
potentially all the way up to 300 seconds for me to time this entry out
having not gotten a packet from MAC address A this entire time and then I
can start to flood this out and eventually that traffic will be received
again now just to get it out of the way yes if MAC address A is not just
listening
but also sending traffic then switch three will get this packet and update the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but also sending traffic then switch three will get this packet and update the
entry and we won't have to wait but the reality is that yeah we waited 50
seconds for this to come back online we might have to wait a whole lot longer
for it to come online if that host is not generating traffic if I'm generating
traffic towards that host and it doesn't even know somebody's trying to
communicate and so it's not sending any traffic at all at that point we're
going
to be stuck in a really bad place so we need to do something about this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to be stuck in a really bad place so we need to do something about this
topology change and there are two specific situations that we're going to
register something as a topology change the first situation is if a port
transitions into the forwarding state and the other possibility is that a port
transitioned from either learning or forwarding to blocking in either of
these specific situations we might find that there is a scenario kind of like
this happening where we end up black-holding traffic sending traffic off to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this happening where we end up black-holding traffic sending traffic off to
get dropped so these two situations are going to lead us to declaring that
there has been a topology change on the network so what we need to do now is we
need to notify the network so we can take action and what better way to
notify the network of a topology change then with a topology change
notification which we typically abbreviate as a TCN TCN's are a mission WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
notification which we typically abbreviate as a TCN TCN's are a mission
critical part of spanning tree protocol operation and not just important with
traditional spanning tree but also very important with rapid spanning tree so
as
with a lot of the other concepts that we've talked about we're going to really
learn how it works with traditional spanning tree when we get to rapid
spanning tree we'll learn that there are a few differences but foundationally
the
concept is the same we need to alert the network that there's been a change so
that we can update MAC address entries in our cam tables otherwise we might end WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that we can update MAC address entries in our cam tables otherwise we might end
up sending traffic the wrong direction so let's look at our situation we had
switch 3 and switch 3 took a port and transitioned that port to forwarding this
qualifies as a topology change and so switch 3 is going to be responsible for
sending a TCN now what exactly is a TCN well this is a bridge protocol data WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
sending a TCN now what exactly is a TCN well this is a bridge protocol data
unit so we talk about BP to use being sent by the root and and they usually
always flow downstream when we're talking about standard BP to use well
this is a TCN BP to you and it's going to flow upstream the goal is to get to
the
root because in traditional spanning tree we need the root to be aware that
there was a topology change so it can alert the rest of the network so it's
going to look something like this we have our broken topology here where we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to look something like this we have our broken topology here where we
have
switches 1 2 and 3 and switch 3 is going to send a TCN BP to out its root port
the port that is the closest port to the root and if there were other switches
in
the path then it would continue to get forwarded upstream as well in our case
it just needed to go one hop before it got to the root so next the root is
going
to be responsible for setting a TCN flag inside of the BP to you now we just WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to be responsible for setting a TCN flag inside of the BP to you now we just
introduced the concept of a new BP to you we call it the TCN BP to you well the
standard BP to you is known as a configuration BP to you and so we can
start to distinguish between these usually if we just say hey we're sending
BP to use we're talking about configuration BP to use but in this
specific case we see that we have a TCN BP to you and so it's worth WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
specific case we see that we have a TCN BP to you and so it's worth
differentiating between the two so then what's going to happen is we're going
to
set again this flag so that the normal flow of BP to use which right now looks
like this these would be our standard or our config BP to use this is a normal
part of the process we just send these every two seconds or whatever the hello
timer is and so the next BP to you that I send there's a flag just a single bit
that's going to be set that says that hey there has been a topology change and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's going to be set that says that hey there has been a topology change and
so I set that bit inside of the BP to you so when the normal BP to you is
received and propagated down everybody's going to be aware that there was a
change so what happens when we have a change detected well again we need to
make sure that we're solving this problem with the timeout it's way too long
and
so what we're going to do is we're going to set our cam table timeouts equal to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so what we're going to do is we're going to set our cam table timeouts equal to
the forward delay timer by default that is 15 seconds so we're going to change
it from 300 and put it at 15 seconds and if our forward delay timer happens to
be 10 seconds then it would set it to 10 seconds but for now we'll just assume
that it's the default setting so we set it to 15 seconds which means that
whether it's a 50 second failover process or simply 15 seconds of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
whether it's a 50 second failover process or simply 15 seconds of
transitioning from learning to forwarding either way in those situations the
timeout has already happened if I haven't gotten a MAC address update from a
particular entry then I'm going to time that out before the network even comes
back online in its new state so that is the idea so once again our topology
here
we know that we have MAC address A living out switch to switch three thinks WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we know that we have MAC address A living out switch to switch three thinks
that MAC address A lives out towards switch one like it used to and let's
say that the timeout is you know maybe it's counting down it's at about 210
seconds well as soon as I receive a TCN this timeout is going to go to 15
seconds and start counting down meanwhile I'm transitioning from listening to
learning on this port here and this is going to take 30 seconds so by the time WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
learning on this port here and this is going to take 30 seconds so by the time
this port comes online I have flushed this entry I've said I don't actually
have a location for A anymore because 15 seconds have now passed now when I
receive a packet on switch three destined for port A I'm going to flood it out
both of these links which will eventually get to port A or MAC address A and
ideally MAC address A responds and lets everybody know where it now lives now
just to wrap up this conversation there is one big caveat to consider as we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
just to wrap up this conversation there is one big caveat to consider as we
move forward and that is what about edge ports because this topology change
notification is very important we absolutely have to have it and we have
defined our topology changes like this but notice a port going into the
forwarding state you know what else triggers a port going into the forwarding
state connecting a laptop to a switch port at which point the port turns into
a forwarding port now we know there's no topology change that is an end host WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a forwarding port now we know there's no topology change that is an end host
that's at the very edge of the network and so these edge ports by default are
going to create topology change notifications and this is not okay
because if we think about a large network then we're going to see that we
constantly have people turning on PCs and turning off PCs and plugging in
laptops and unplugging laptops and so 802.1d spanning tree by default doesn't WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
laptops and unplugging laptops and so 802.1d spanning tree by default doesn't
account for edge ports meaning we're constantly going to be sending DC ends
out which means we're constantly going to be operating with MAC timeouts in the
entire network at 15 seconds which is going to create a whole lot more flooding
because MAC addresses will time out far more often so this is a problem that
needs to be resolved and we're going to resolve that problem in the next video