Alright, so let's get into this second demo section,
specifically covering network changes.
So if we look at this network topology again,
we'll see all the different metrics that are standing in
for the cost of the different interfaces.
In this case for the lab,
we are setting those as the delays that are currently
configured on each one of those.
So those are in tens of micro seconds,
so that would be actually what you would configure on the interface
if you were going to try to replicate this lab.
But let's move into the lab real quick and I want to force a route to go active,
and I want to show it to you in a capture window so you know what it looks like,
and I'm also going to show it to you on the device running a debug.
So let's go into R1 real quick.
And if we look at its topology table,
and we're going to cover this network and move back into topology,
if we look at the link between R1 and R3,
currently it has a cost of 5.
So if we roll back to R2 just real quick,
and if we look at that interface, it's this one,
so if we say delay is currently 50 microseconds,
and if you were to configure this in tens of microseconds,
this would be 5 tens of microseconds.
So this is the interface that we're going to play around with,
this network, the 10.10 .10 .8 network.
So if we move back to R1 and look at this topology table,
and we'll see in this case there are currently two
successors to get to that network.
The reason for that is is that R1's cost through R2 and R3 to get to
that network is the same because on R2 and R3,
its cost is the same for that network.
So we showed R2 had a configured delay metric of 50 microseconds.
In the configuration of R3, it's configured exactly the same.
So R1 sees an equal cost path to that network through either R2 or R3,
and because of that, they both have the same metric as shown here and here,
and they both advertise the same metric,
which is this.
The second number here is the advertised metric coming from those devices.
Knowing what the IP addresses are on those interfaces,
I know that this .2 is R2 and this .6 is R3.
But to show you what I want to show you,
I want to bring down the interface between R1 and R2
and have that route go active.
But if I do that in this current configuration,
all it's going to do is drop this route.
It's going to see that it still has a second path that goes there.
It's never going to go active because all it's going to do is drop this.
There's no point in reprocessing because I already
have another successor sitting here.
So in order to sort of force this so I can show you what I
want to show you is I'm going to go onto R3,
and on the interface that goes between R2 and R3,
I'm going to just bump the delay cost up just a little
bit to 60 microseconds instead of 50.
When I do that, it's going to take this second route out of here.
Now the only thing you'll notice here is it completely goes away.
Well if you remember from our earlier modules, now why isn't it there?
Isn't it feasible?
Isn't there another path that should be available and shown here?
Well,
the reason for that is because whenever I change
that delay on R3 for that network, what it does,
if I just put an additional command here and we'll see it,
whenever you use this additional, it's actually all-links,
but that's a short version,
it shows you all the network information that I got from that device.
In this case, R1 received an update from R3 for this network.
However, it received it with an advertising cost of 4096.
And that's accounting for the bandwidth, as well as the delay.
Well the current successor, which is the one that goes through R2,
which is this line, has a feasible cost,
or feasible metric, of 4096, whereas its advertising is 3840.
Now if you remember back, the feasible condition,
the feasibility condition that we referenced in an earlier module,
this advertised cost needs to be less than the current feasible cost or it will
not be considered feasible per the feasibility condition,
and it will not be placed into the normal EIGRP topology table.
And since this isn't less than that, I guess it's the same,
it's only by one, and it seems like a small number,
but because it's the same,
this second route here via R3 is not considered feasible by R1.
So it won't consider this for anything.
This just shows you that it knows it's there,
but it's not going to pay attention to it at all,
which means that if this second route through R2,
we should be at the main table here, this one,
if this one goes down,
it's not going to pay attention to that other route at all.
It's going to immediately send this route into active
and it's going to send a query out, its other interfaces,
in this case the only other interfaces between R1 and R3,
and it's going to say, how do I get here?
Basically,
this information that's in this other display here
with the all-links parameter set,
is strictly there for more or less troubleshooting purposes.
The EIGRP process on the device does not pay attention to it.
So what we're going to do right now is I'm going to disable
the interface going between R1 and R2.
But before I do that, I want to do one additional thing.
I want to put one debug command on R1.
And given that this is a vendor specific command,
debug EIGRP Finit State Machine, this debug will show you as the State,
the EIGRP States change,
and as the dual process on this device goes through its
thing and puts that route to active and gets additional
information from its neighbors, it will show all that information on it.
On top of watching this, whenever I remove that link,
I will also be showing you an example of what the capture
looks like and you will see the traffic go back and forth as
it's doing the query reply process.
So let me remove that link, and we'll see what happens.
Alright, there it goes, there's that interface.
I didn't actually disable the link on either one of the
devices as I'm shutting down the interface,
I took the link away.
So whenever I do this, it had to wait a second,
and some of that I sped up in post, but it waited for its hold time to go down.
Now let's just let this throw out all these numbers here
while the debug capture picks up here,
because it wasn't just that route that was going through from R1 to R2,
there were several routes that R1 had preferred
going through that specific path.
So it's not just that .8 network,
which we're seeing here sort of flow around here,
it was also several other ones.
So let's turn debugging off for a second here.
And let's just sort of watch this go here, hold on.
Let's go to the top.
Okay, the neighborship came down, and I'm just going to follow the one for .8.
There are other destinations that it's doing the same thing,
but remember that process, the reply, query reply,
process and every process that goes on inside EIGRP is route specific.
They may piggyback on the same packets, but the process itself is done per route.
So in this case,
the EIGRP process is looking for a new way to get to the .8 /30 network.
So find me a different path.
Currently, this was my previous.
I'm poisoning my route through R2.
I did have this route through it, which this is that part where I said,
well, it really doesn't use it.
It says I knew about it, but it's verifying it with its other neighbors now.
And the next thing it does is it throws that route active.
So 10.10 .10 .8 /30 goes active.
So it sends a reply not subject to split horizon,
and then at that point it's waiting on a response from its other neighbors.
So in this case, it's waiting on a response from R3.
Go back and see, and just see, there it is, down here a little bit.
Okay, received reply.
And now, R3 in this case is advertising you can get via R3 with this metric,
so basically it's verifying what it already knew,
but it won't actually use the route until it verifies it.
Yes, you still have a route.
You can still get to that network and it's via .6,
which is R3 in this case, and it's clearing it.
Let's see.
And this is the next one.
And that is the end of its process.
So it basically went out and it sent and said,
query, I lost my route to this one.
I'm going to poison it.
I need to find a new route for .8.
And then it waits,
and a lot of the stuff in the middle we're seeing is for the other routes.
And then eventually, it got that route back from R3 here,
which verified, yes, you can get there via me now.
See, it's right there, route installed 10.10 .10 .8 via 10.10 .10 .6,
which is R3.
Now let's take and see what that looks like on the captures.
So on this capture right here is on the link between R1 and R3.
We can see the hellos after the fact.
Okay, these are all hellos coming into it, normal hellos.
Notice that I left this neighborship configured as a static neighbor so you
won't see any multicast traffic going back and forth.
That was just for the purposes of seeing how this looks a little bit
different whenever you're not using multicast.
And at this point, you'll see that R1 sends a query through R3 saying,
I don't have routes to any of these numbers anymore.
And if we look at the .8 one,
you'll see this is R1 poisoning the previous route that
existed to the .8 network via himself.
So it's saying to R3, previously I had told you I have a route to .8.
I'm saying that right now I no longer have it.
So I'm saying delay infinity.
So I'm saying,
take this route out of your topology table for this network via me.
And on top of that, it's also saying as being part of the query,
do you have another path to here?
So the first thing that R3 will do is it will send an
acknowledgement packet back which says, okay,
I received it.
So if you look at the update packet and go to the top here,
sequence number of 30, and this is R3 coming back saying,
I acknowledge 30, so I've got it.
.5, which is R1 in this case, is sending another one out,
so that's where I was talking about multiple packets sometimes are used.
And then R3 sends a reply back that says,
okay, I know how to get to all these networks.
And for the .8 network, now if you remember the 6 we had from earlier,
this is 6 microseconds.
So now he's saying back, I have a route to get to .8.
This is my metric to it.
So in this case, it's only using these two metrics.
So you can get there via me.
And it's using that 0602 TLV that we talked about earlier.
And let's see, the sequence number is 99.
R1 turns around and sends an acknowledgement back that says acknowledge 99.
So it's saying, okay, I got that packet.
I'm happy.
You'll see there are some other updates going on
here as he has gotten additional,
R3 has gotten additional information for the other networks that R1
came through and said I can't get there anymore.
But once he finishes his process,
he'll ack all the stuff back to R1 and then he'll,
or both R1 and R3 will return to a normal hello
conversation going back and forth.
So that is the process of what a network change will do.
The same thing, or similar thing, happens whenever you add a network.
Instead of using a query or a reply process, you would just use update packets.
So in this case, real quick,
I'm going to re-enable the interface that goes between R1 and R2,
put everything back to where it was before we just did that last experiment,
and then I'm going to add a new network and we're
going to look at the capture again.
And we're back.
We changed everything back to where it was.
So let's see here again,
R1's back to having two equal cost paths to that network.
What we want to show here is we're going to show an update.
So I'm going to enable that same debug that I had on there earlier.
And I'm going to go to, let's see, R3 I'd say, let's see.
Let's just add sort of a random network on here and show what
it looks like whenever you do an update.
Because R3 is configured with the network 0.0 .0 .0 command,
it says all the interfaces that exist on R3 should
be placed in the EIGRP process.
As soon as I hit Enter here, R3 is going to send an update packet back to R1.
So I'm going to try to jump back to R1 real quick and show you the process.
Turn the bug off.
So in this case, the network was the 150.150 .150 .0 /24 network.
And if we look at R1, okay,
I've got a packet in from R3 that says that he now
knows how to get to the 150 network, 150.150 .150 .0 /24.
This is his metric.
I don't have a metric to it is basically what this is saying.
Currently I have an unreachable, I don't know how to get there.
So it's installing this metric via R3.
And then what he's going to turn around and do is he's going to
send an update back out his other interfaces,
so in this case his other interface goes between R1 and R2.
And one of the things he receives back on that,
well, here's rcvupdate, destination not active.
This is R1 getting an update from R2 in this case.
Now remember that R2 also has a connection that goes directly to R3,
as well as several other paths to get to R3.
And R2, in this case, is advertising, I can get to that network as well,
and its cost is this.
Now if we look here closer, you'll see that his advertised cost is 131840.
Previously,
we had gotten an update directly from R3 that said his
feasible cost from R1 would be 130, so that's not going to be a feasible route.
So if we look at the topology table here in a minute on R1,
you're not going to see this in a normal topology table,
but you will see it if we use the additional all-links parameter,
Currently we have two available options,
130816, which is from R3 directly.
And there's another route, which is via R2, which is not going to be feasible.
And this is another one via R2 which is now saying,
poison that route I just gave you.
So in this case,
since he's poisoning the route after he advertised it back to me,
that's not going to be shown in that.
So if we verify this, topology table, to the 150 network goes via R3,
which is this one, currently on passive.
It's only one successor and it goes here, which is R3.
If I put the all-links parameter on here,
he doesn't have any route through R2 anymore because R2,
as we jump up here, see R2 gave us it,
and then as he was being additionally updated through his other routes,
he turned around and poisoned it right after he advertised it to us.
So we got new information.
He got new other information that says, okay,
I have a better route to there, which may have been via R1 in this case.
This path may have broke the feasibility condition on his from R2's perspective.
So then he re-advertised and poisoned it.
If you're really interested in getting into the numbers,
you can actually calculate all the metrics and you can
walk through why he poisoned it.
I'm not going to do that here, but it's an interesting exercise in math.
So in this case,
the only entries that we have in our topology table
to get to that 150 network are .6.
But we do know that we can get there also via R2.
So if we actually close the interface between R1 and R3 in this case,
R1 would go active and send a query packet out to R2.
We know R2, just from looking at the debugs, has another path to that network.
So,
you would see a similar interaction between R1 and R2 as we
just showed previously between R1 and R3.
So let's move back here into the capture window,
and let's just see what this looks like in the capture window.
So this is between R1 and R3.
This is the initial update packet with a new TLV, or the 150 network.
And so this is it initially advertising and saying, I know how to get there.
This is my metric information.
This is R1 saying, okay, 114 sequence number, 114 acknowledgement.
And me sending it back with a poison.
So this is basically saying, you're my best path to that network,
so I'm going to poison that back through me.
Basically,
it's just a verification that R3 had sent me a route that had a
better metric than I have available to that network,
so I'm automatically going to send back a poison.
It's just verifying that yes, my best path is through you.
You're my successor, so I'm going to poison it.
So this is R3 acknowledging back we have 39,
which would have been this one, 39 sequence,
39 acknowledgement.
At that point, on this interface, R1 doesn't have to send any more packets.
So it's basically an update from R3 to R1, from R1 to R3, and you're done.
So let's look at what R1 and R2 are saying to each other,
because remember, it sent us an update, and then it poisoned itself.
So if we go between, on the interface between R1 and R2,
go up here a little bit, we're going to see an update.
This is R1 telling R2 that I now have a path to the 150.150 .150 .0 network.
This is R2 doing the same exact thing.
If you remember, R2 advertised.
So R2 got a packet that's from R3 directly.
It said I have a path to go there.
So this is the one that R2 says, I have a path to R1.
R1 sends I have a path back behind me through R3 directly.
They ack each other.
So this is R1 acking this packet.
This is R2 acking this packet.
And then at that point, R2 has that additional information that R1 just sent it,
and because it got that information and probably other information
from other routers on the other side of him,
so he is also connected to R4 and R5,
and because he got that additional information,
he'll turn around, and remember,
the TLV is still for the 150.150 .150 .0 /24 network,
and this is the poison.
So I'm going to advertise it.
Hey, I got new information.
But between that time and the next one, so if we look at the time codes here,
we'll see in how small amount of time we're talking about here,
within 3 microseconds I think that is, or milliseconds.
I've got additional information.
I'm going to re-update and say, okay, so sorry, you have the best path.
You're my successor.
Poison me.
Now again, we'll see the Ack.
This is the sequence number coming from R2 to R1 of 77.
This is R1 acknowledging back that.
And at that point, they're done.
So at this point, I believe if I went into R2,
and jump into the lab here, and to poison that,
I'm going to take a wild stab that R2 should
currently use R1 to get to that network.
So at least one topology.
So, we look at that network from R2's perspective,
he actually has three different other routes that are available,
three total routes that are available to get to the 150 network.
One via, this is via R1, 14, it's not going to be here.
So he's also connected to R4.
It was 14, so this 14 is via R4, and 10 is going to be via R3.
So he's saying,
and this is where we get to take a look at successors and feasible successors,
R2 has three different total entries that are feasible to
get to the 150.150 .150 .0 /24 network.
Only one of them has the lowest metric, but in this case,
the route via R1 is my best metric.
So if I'm actually going to realistically send traffic to the 150 network,
and it'll see this if I look at the routing table,
you're only going to have one entry in here for the 150 network,
and it's going to be via R1.
Now if we look at this, there's the feasible, 131072, 131072.
So it's going to use this one.
However, should this route go down,
I have two other available feasible successors that are in the table.
Now they aren't the same cost,
so this one via R4 would have preference over this one via R3.
So oddly enough, directly to R3 is not the best metric.
So it'll send it through R1.
if the one through R1 failed, it would go through R4,
and if the one through R4 failed, then it would go directly to R3.
But because these are considered feasible successors,
and the reason you know that is because they're in the main typology table,
they're not just in the all-links table.
And if we look at the all-links, there's probably going to be another entry here.
Well, there may have been another entry there.
There was probably another one advertised via R5,
but it probably got poisoned out by R5.
But if it's in this main table, EIGRP will actively consider it.
So that means if this route goes down,
it will not put this route into active mode.
It'll stay passive and all it'll do is it'll just drop this
route out of the topology table and it will exchange that route
in the routing table with this one.
If this one goes down, it would exchange it for this one.
And none of that would place that route into an active state.
It would stay passive.
Now if it lost all three of these,
then R2 would go active on that route and look through its other interfaces.
So in this case, it's only connected to one other device.
It's only connected to R5, other than these three.
So if all three of these went down, it would send an active query,
it would put this route in active and send a query message to R5.
So that's a little walkthrough of the different ways that changes on the
network will affect the topology tables throughout.
And everybody runs their own individual route specific
feasibility role verifications and how they send and relay the
information back and forth from each other.
Now the one last thing I did want to show you here,
and I'll show you on the link between R1 and R2,
that's the most recent capture we were looking at,
and that was the Restart flag.
Now if you remember whenever we were looking at the flags,
the update flags, one of them was Restart.
And the two conditions that I've been able to see that I've seen the Restart
flag actively used is whenever you do a soft reset of the neighborship or
whenever a graceful restart is being used on a device.
In this case,
the hardware that I have right now does not support graceful restart,
so I can't show you that one, but I can do a soft reset.
And whenever I do that on a Cisco device, that's rather easy.
And I'm just going to reset all of them.
So it's just a clear IP EIGRP neighbor soft.
And whenever I do that,
I want to move over and show you what the capture looks like.
You'll notice on R1, we'll show the capture in a second,
on R1, you don't see the neighborships go down,
you just see a re-sync.
And that's all it's doing.
It's not actually bringing the neighborship down and
reestablishing a neighborship from scratch.
All it's doing is it's forcing a re- exchange of information between the two.
So basically R1 and R2, and in this case also R1 to R3,
are sending information back and forth saying,
these are all the table contents that I have in my
topology table and they're just sending that information
again back and forth to each other.
So if we move over to the capture window,
we go up here a little bit, we'll see here's R1.
And now this is only on the link between R1 and R2,
so we're not going to see any of that stuff between R1 and R3.
This is R1, and R1 is saying, on the flags,
he actually has three different flags set: the INIT flag.
Well, I'm initiating this, and I'm saying, I need all your information.
So this flag is basically saying, send me all your information to R2.
Restart.
All I'm doing is soft restart, so it sets a restart flag.
And End of Table because on top of sending this initial,
he's also sending all of his current active routes that he has successors for.
He's sending all this information to R2,
so this is sort of preempting having to send additional packets.
It's saying, these are all my database contents.
End of Table is saying, this is all of it.
If it wasn't all of his routing information,
he would not set that flag, and it would be more than one packet that was sent.
So that's why he sets all three flags.
And what you're going to see is R2 is going to acknowledge that packet,
so that's 41 and 41.
R2's going to basically do the same thing.
He's going to send a, since it's not an initial,
I'm not being, the reset was not initiated on R2,
so the INIT flag won't be set, but the reset flag will be set.
And since his whole routing table contents can be sent inside one packet,
he's also setting the End of Table flag along with all of his known entries.
So what R1 does to that, since we need to maintain the reliability,
is he will turn around and acknowledge it back.
So if you see his sequence number from R2 to R1 was 80, 80.
This is R1 saying, okay, got the message.
And at that point, we see, at that point,
they just resume their hello operations again.
And in this case, between R1 and R2, multicast is allowed,
so all the hellos go to the multicast contrast that we talked about,
the 10 address.
So with that, we're going to end this demo section.
And in the next demo section, we're going to move on and talk about external routes.