|
0:00:13
|
The next distance-like behavior that we have for EIGRP
|
|
0:00:17
|
is that it does still use Split Horizon.
|
|
0:00:20
|
Now, when EIGRP Split Horizon is not really used as a loop prevention mechanism
|
|
0:00:27
|
as more so, it's used just to make the updating process a little bit more efficient.
|
|
0:00:33
|
Because normally, there's not a case where you woud advertise a route to me,
|
|
0:00:37
|
and then I should advertise it right back to you.
|
|
0:00:40
|
Really, the only valid design case for that
|
|
0:00:43
|
is if we're running some sort of partially meshed non-broadcast topology.
|
|
0:00:48
|
We'll see, this would be true of designs today,
|
|
0:00:52
|
where it's very common to run EIGRP,
|
|
0:00:56
|
which is for a Dynamic Multipoint VPN, or DM VPN.
|
|
0:01:04
|
Where DM VPN is basically a multipoint GRE tunnel
|
|
0:01:09
|
that we can use between a hub and the different spokes
|
|
0:01:14
|
to essentially form an automatic full mesh of IP Sec tunnels.
|
|
0:01:22
|
And in these type of designs, typically, EIGRP
|
|
0:01:25
|
is the IGP that is used to route them.
|
|
0:01:29
|
So, in this practical design, on the hub,
|
|
0:01:33
|
when it receives an update in one of the tunnels from the spokes,
|
|
0:01:37
|
it would need to disable Split Horizon so that it can go back out the same interface down to the other spokes.
|
|
0:01:45
|
We'll see the same logical case in our topology
|
|
0:01:50
|
with the frame-relay interface that router 5 is using.
|
|
0:01:56
|
So, as opposed to the RIP process
|
|
0:01:59
|
where RIP automatically disables Split Horizon on the main interface in frame-relay,
|
|
0:02:05
|
EIGRP is gonns use Split Horizon on every single interface.
|
|
0:02:10
|
So, this would then mean, when router 2 sends an update to 5,
|
|
0:02:14
|
5 is not gonna be able to send this back to 3, to 1, or to router 4.
|
|
0:02:20
|
So, on router 5's interface,
|
|
0:02:23
|
wherever the IP address is assigned either under the main interface in frame-relay,
|
|
0:02:27
|
or potentially, a multipoint sub-interface,
|
|
0:02:30
|
we would then wanna go and disable the Split Horizon process.
|
|
0:02:36
|
Now, we will see what will happen is that when router 2 now sends an update to router 5,
|
|
0:02:45
|
5 is gonna send it right back to router 2,
|
|
0:02:49
|
but based on the logic of the feasibility condition,
|
|
0:02:53
|
router 2 will know that it is never valid to use router 5 to reach those destinations.
|
|
0:03:00
|
So, once Split Horizon is off, then, we look at the Show IP EIGRP Topology All Links,
|
|
0:03:05
|
we will see that there's a bunch of duplicate information that is advertised between the routers.
|
|
0:03:11
|
So, this is the real reason that Split Horizon is on.
|
|
0:03:14
|
Not for loop prevention, but just to make sure that I'm not sending an update to you,
|
|
0:03:19
|
and then, you're sending it right back to me.
|
|
0:03:21
|
Because I'm still gonna have to process that update,
|
|
0:03:24
|
and use it as part of my calculation before I can throw it away.
|
|
0:03:30
|
Now, we could see that this is the case on router 2.
|
|
0:03:34
|
If we were again similar to our RIP configuration,
|
|
0:03:37
|
if we were to disable the link that router 2 connects to router 3 with,
|
|
0:03:43
|
which essentially means now,
|
|
0:03:46
|
router 2 has only one physical path to the rest of the network.
|
|
0:03:51
|
We'll see that router 2 is not gonna learn about any of the other destinations.
|
|
0:03:54
|
Like router 1, or router 3, or router 4,
|
|
0:03:57
|
because when these updates go from these neighbors to 5,
|
|
0:04:03
|
5 is not gonna send an update back to router 2.
|
|
0:04:10
|
So, if we now look at the Show IP Route,
|
|
0:04:15
|
we'll see that a lot of the information in the topology, we do not know about.
|
|
0:04:19
|
So, we don't know how to reach the loopback of router 3, for example.
|
|
0:04:24
|
We don't know how to reach the loopback of router 4.
|
|
0:04:27
|
Okay, we can tell based on the state of router 2's table
|
|
0:04:30
|
that router 5 is using the frame-relay interface to reach those destinations.
|
|
0:04:37
|
These other interfaces, or the other routes that we are learning,
|
|
0:04:42
|
these are the ones that we can infer that in router 5's table, it is not routing out the frame-relay.
|
|
0:04:49
|
So, if I were to trace any of these destinations, like to 155.10.8.8,
|
|
0:04:57
|
router 5 does not send that traffic back out the frame-relay.
|
|
0:05:00
|
Or the 155.10.108.10.
|
|
0:05:10
|
Now, the way that I can infer this based on how the routing table looks
|
|
0:05:15
|
is that again, EIGRP will only advertise what is actually installed in the routing table.
|
|
0:05:22
|
So, whatever router 5 has installed as EIGRP that is via serial 0/0/0,
|
|
0:05:34
|
these are the routes that cannot be advertised to router 2,
|
|
0:05:38
|
because they would be violating the Split Horizon rule.
|
|
0:05:41
|
This likewise means that the alternate paths of these destinations
|
|
0:05:48
|
are not installed via other links.
|
|
0:05:51
|
So, if I were to say, Show IP EIGRP Topology for 150.10.3.0/24,
|
|
0:06:01
|
it actually says, "I have a bunch of possible ways that I could get to this destination,
|
|
0:06:07
|
but not all of these are valid routes."
|
|
0:06:11
|
So, if I were to look at the one that is reachable via router 4's point-to-point link,
|
|
0:06:18
|
It says that the total metric here is 2.3 million,
|
|
0:06:23
|
and the advertised metric is a 161,000.
|
|
0:06:29
|
Now, if we look at what is the total feasible distance,
|
|
0:06:32
|
so what is the lowest end-to-end metric,
|
|
0:06:36
|
we see that this is 2.2 million.
|
|
0:06:40
|
Since this value lower than what router 4's value was.
|
|
0:06:46
|
So, router 4's value is 2.3 million,
|
|
0:06:49
|
it means that this one is not gonna get installed in the routing table.
|
|
0:06:53
|
Since it is not installed in the routing table,
|
|
0:06:55
|
I therefore cannot advertise it,
|
|
0:06:57
|
which means that even thought there's a valid path to reach router 3's loopback this way,
|
|
0:07:04
|
since I'm not installing it on the table, I cannot receive the update in,
|
|
0:07:08
|
and then, advertise it out this direction.
|
|
0:07:14
|
So, the key point here is that depending on the individual state of the topology,
|
|
0:07:19
|
we could have a design where it looks like router 2 has full reachability to the entire network,
|
|
0:07:24
|
but only in the case where router 5 is not using the frame-relay to reach other destinations.
|
|
0:07:32
|
Where in reality, what we should be doing
|
|
0:07:35
|
is just going to router 5's interface,
|
|
0:07:38
|
and saying on...
|
|
0:07:40
|
serial 0/0/0, "I want to disabled Split Horizon for EIGRP process 1."
|
|
0:07:53
|
So now, if we look at the change in router 2's table,
|
|
0:07:56
|
and we Show IP Route EIGRP,
|
|
0:08:01
|
we should see now that router 2 has full routing information for everything that's in the topology.
|
|
0:08:10
|
Now, once the Split Horizon process is disabled,
|
|
0:08:14
|
let's take a look at what the spokes of the network
|
|
0:08:18
|
see as the routes are being learned from router 5.
|
|
0:08:23
|
So, on router 2,
|
|
0:08:25
|
let's look at the Show IP EIGRP Topology All Links.
|
|
0:08:36
|
And specifically, I want to see...
|
|
0:08:41
|
the loopback of router 2.
|
|
0:08:46
|
And...
|
|
0:08:49
|
Actually, I think this is the only connected interface that we're advertising.
|
|
0:08:52
|
Let's look at the Show IP EIGRP Interfaces.
|
|
0:09:00
|
So, it's only this top interface, which is the frame-relay, and then the loopback.
|
|
0:09:05
|
These are the only active links that are being advertised in EIGRP.
|
|
0:09:09
|
So, let's say also on router 2,
|
|
0:09:12
|
I'm gonna advertise the 192.10.10.2 interface.
|
|
0:09:19
|
So, this is router 2's link that connects to BB2.
|
|
0:09:26
|
So, these one here is now being advertised up to router 5.
|
|
0:09:30
|
Since router 5 now has disabled Split Horizon,
|
|
0:09:34
|
we should see the updates goes from 2 to 5,
|
|
0:09:37
|
then from 5 right back to 2.
|
|
0:09:42
|
If we look at the topology, and say Show IP EIGRP...
|
|
0:09:46
|
Topology All Links,
|
|
0:09:54
|
we see that this connected interface
|
|
0:09:56
|
is actually also being learned back from router 5.
|
|
0:10:02
|
Which is fine though, because when we look at the feasible distance of the connected interface,
|
|
0:10:09
|
so, it's basically metric just based on the delay and the bandwidth of the connected Fast Ethernet 0/0,
|
|
0:10:17
|
this would always be lower...
|
|
0:10:20
|
than whatever router 5 could potentially advertise to us.
|
|
0:10:26
|
So, even though there is duplicate routing information,
|
|
0:10:29
|
and we could see this on let's say, router 3.
|
|
0:10:32
|
If we Show IP EIGRP...
|
|
0:10:36
|
Topology All Links.
|
|
0:10:41
|
And we look at let's say...
|
|
0:10:45
|
Switch 1's loopback.
|
|
0:10:48
|
Where switch 1's loopback, this is from router 3's perspective.
|
|
0:10:52
|
Switch 1 advertises this out the directly connected link.
|
|
0:10:57
|
So, router 3 is gonna choose, "This is the best path...
|
|
0:11:00
|
towards that", because it's simply the closest in the topology.
|
|
0:11:04
|
The update goes from 3 to 5.
|
|
0:11:07
|
It goes from 5 back to 3.
|
|
0:11:10
|
When 3 receives this update back in, technically, it is part of the route calculation.
|
|
0:11:15
|
But when we look at the possible paths,
|
|
0:11:18
|
the one that is via switch 1 is always gonna be lower than the other possible routes.
|
|
0:11:29
|
So, the key point being here with Split Horizon,
|
|
0:11:32
|
with EIGRP, it's technically not a loop prevention mechanism.
|
|
0:11:35
|
It's just there to cut down on the amount of useless routes
|
|
0:11:39
|
that you would never use in the first place.
|
|
0:11:41
|
Based on the feasibility condition, the router is always gonna know
|
|
0:11:45
|
who is closer to the destination in the topology.
|