Okay, now let's get into this short demo here,
specifically covering external routes and how they
look and are advertised in EIGRP.
Now if you look at the topology here,
what we're going to be doing is we're going to be adding the
200.200 .200 .0 /24 network into the network,
but instead of being directly placed into the EIGRP process,
we're going to redistribute it from a different routing protocol.
So if we look on R6, we jump over to the lab,
we're going to see on R6,
I have preconfigured the Loopback interface with that network,
and I have preconfigured that network to be routed via OSPF.
I have not done any configuration in order to take that
route from OSPF and place it into EIGRP yet.
Because on R1 I have not enabled any debugs,
and I wanted to jump back to R1 and show it received this update.
And then we're going to jump and look at the updates as they come in from
R2 and R3 into R1 and just sort of see the differences between a normal
EIGRP route internal and an external route.
So let's move on to R6.
The knowledge as to how to do this configuration is outside the scope here,
so we're just going to throw it in here real quick.
(Working) As we see here, as it was a little faster than I was,
R1 received an update for the 200 network,
it's received an update from R2 in this case.
If you jump down here a little bit,
you'll also see it got another update from R3.
I don't currently have a route to it.
Okay, install a route to that network via R2.
Received it from R3 with a slightly higher metric.
See here's his metric, feasible metric for this route through R3,
feasible metric through R2.
Now you can tell me right now, you look at this and you look at this.
This is a little exercise.
Which one of these will be in the normal topology table?
Which one will be in the all-links topology table?
Then we're going to look and see here, it says,
okay, I got two different ones here.
The one through R2 has a lower cost,
so it's going to basically reiterate and say I'm only
going to put this in a routing table.
Receives an update from 6 with this metric.
This is R3.
This is the new information it's got, and it installs this again.
So what do you think?
Based on that information, what's going to be in here?
From here,
you can see that the 200 network only has one feasible successor that's
in here via R2 with that 5888 that we saw up here.
If we look at the all-links version,
we won't see anything because we caught it at the end the bug here.
R3, it sent the metric initially.
It learned it, and then it sent it to its neighbors initially and said,
okay, here's my metric.
Then it got additional information and send an additional update,
a follow up update that says, hold on, and it poisoned that route back out.
So this update right here is what's going to completely
remove it from the topology table.
This is the process here on R1 saying, okay, these are the two metrics.
It's removing,
this is the actual entry that's saying I'm removing it from the topology table.
And the only route that's going to be installed in the
routing table is going to be via R2.
So what does that look like on the captures?
Well first, let's take a look.
Let's move over to the capture window here.
Let's run up here a little bit.
See, we got an update from R2.
So R1 went to the multicast address, but it's being interpreted as R1,
and it says, I have an update for the 200 network.
In this case, it's an external route.
So instead of using 0602 here, it's going to be using 0603.
An IPv4 route, router IDs and such, and this is the destination, 200.200 .200.
And the subnet mask or prefix length is /24, 24 bits.
R1's going to turn around and ack that back.
So the sequence number is 91, 91.
R1's going to send a message back out saying,
how to reach this network is infinity.
So I'm poisoning it at this point because my
successor route is going to be via R2.
So I'm basically saying, okay, my route, don't come to me.
R2 has a better route than me.
So the effect of this is that R2 will remove this route from
its topology table in an effort to ensure that there are no
potential loops in the network.
As an answer to this second update, this update from R1 to R2,
R2 will send back sequence 46 an acknowledgement packet.
And that's it.
Now hold on a second, let's move over to capture between R1 and R3.
So now we're over here on our capture between R1 and R3,
let's back up here and find this update.
There's going to be a couple more updates here,
because remember that R3 actually initially sent us the route.
R3 initially sent a route to R1 that says, I can reach it, and here's my metric.
We received additional information from R1 that said,
whoops, R1's going to be my successor, now poison that.
So the initial one it's going to see is from .6,
which is R3 to R1 saying, hey, look, I can get to this 200 network.
So this is the first one, that same TLV type, 0603.
This is R126, R1 ack and back, 126.
R1 turning around and saying, okay, I can reach there also,
and this is my metric.
R3 acking that back, it's 47, 47 sequence, 47 acknowledgement.
At that point, between here and here,
R3 realizes that it's not the best route for R1 to go through,
so it's going to turn around and send another route back out,
another update.
And this is going to be the poison.
It's saying, okay, remove my entry.
Don't come through me.
And the response 129 sequence, 129 acknowledgement.
At that point, packet exchange is complete,
and we're back to our normal operation.
Not overly confusing.
Basically exactly the same way as it would look with an internal route,
but in this case, instead of using that 0602 TLV,
they use a 0603 TLV.
Now that's important inside EIGRP because if you remember,
administrative distance is what Cisco devices and several other
vendor's devices use in order to determine what routing protocol is the
best one to trust to reach a specific network.
So if there are multiple routes to the same destination,
but via different routing processes,
each one is considered based on its administrative distance,
while the administrative distance of EIGRP internal routes
is not the same as EIGRP external routes.
So in this case,
if I had an internal route option that went to the 200 network and I had
an external route option that went to the 200 network,
I would use the internal one over the external one.
And that's the fundamental difference whenever we look in the EIGRP.
It's just considered the external routes are inside
any given routing protocol process,
external routes are almost always going to be given
lower priority than internal routes.
Sort of just follow logic.
But it's an important thing to make sure also that you do
know about that extra reachability should you lose an
internal route to a destination, and that gives you sort of a back up option.
The other thing I wanted to point out inside this TLV is there's an
additional little field in here that they include,
which tells you where that information came from,
from the external,
what external routing protocol process did this information come from?
And in this case,
it found out that the external protocol that this came from was OSPF,
and that the originating AS was 10.
In this case, this is just the process ID.
And the router ID of that device from OSPF's perspective was 200.200 .200 .1.
So for now, that's going to do it for this demo.
It's going to be short.
The next one's also going to be a shorter one, and we're going to talk about authentication.