Re: EIGRP - Split Horizon

Jules,

It occurs to me that we may actually be largely in agreement but
having a fundamental - and [i]consistent[/i] - failure to communicate
(imagine that - a failure to communicate...[i]ON THE INTERNET![/i]).
I have been struggling to understand your use of all-caps nearly every
time you say "INTERFACE." Obviously, it's your intent to place great
emphasis here, so I gave it further consideration as I reread all of
your posts. And in doing so, reached the conclusion that were the
topology in question to be ever so slightly different, this might be
an easier discussion to have.

Let's just for a moment take away those six interfaces depicted below
as connecting R2 to both R3 and R4 and also R3 to R4. Put a switch in
the middle, connect R2, R3, and R4 to that switch, and establish a
single VLAN to connect them all. Their addresses look something like
10.1.234.2/24, 10.2.234.3/24, and 10.1.234.4/24. The behavior I would
expect to see in such a topology would change from the originally
observed behavior. This because now not only is R2 the next hop for
both R3 and R4, it's also the case that the advertisement for R1 Lo0
that both R3 and R4 are actively using to reach that destination
originated on the only common interface they share. So I would expect
Split Horizon to block either of them from advertising R1 Lo0 to each
other in this slightly altered scenario because to do so would be
pointless. I think R3 could reasonably assume that R4 has neighbored
up with R2 (might not have if static neighbors have been configured in
such a way that R3 and both R2 and R4 establish but R2 and R4 do not
-- but that's a very strange corner case) on this common shared subnet
and would have learned of R1 Lo0 directly from the same source that R3
itself did.

But that's not the original topology in question (at least as I
interpret the ASCII art and the dialog in the original post) and
didn't you insist that we "stick with the original scenario?" ;-)

Regards,

Scott

On Jan 10, 2011, at 2:37 , jules NYA BAWEU wrote:

> I'm almost about to give up on this...
>
> Again let's save sometime here. Here is the original issue - Please
> stick
> with the original scenario and we will move to the cost changing
> after that.
> Please explain it as it relate to Split Horizon:
>
> Issue:
> " When R3 learns the route of 1.1.1.1/32 from R2 and sends it to R4,
> shouldn't R4 NOT send that same route back to R3 due to split
> horizon???"
>
> What I'm saying is, in your logic, using rule 2 ( -"The split-
> horizon rule
> prohibits a router from advertising a route through an interface
> that the
> router itself uses to reach the destination.") explains why R3 and
> R4 are
> not advertising the 1.1.1.1/32 prefix back to R2 - BUT IT DOES NOT
> explain
> why R3 and R4 are advertising 1.1.1.1/32 to each other - again let's
> stick
> with the original scenario.
>
> Here is my answer to that question TO WHY R3 AND R4 ARE SENDING THE
> ROUTE
> 1.1.1.1/32 BACK TO EACH OTHER:
>
> ===============================
> Starting with your original scenario  I added some interfaces for
> clarity:
>
> R3 fa34 ---------fa43 R4
> fa32 fa42
> | |
> |----fa23 R2 fa24----|
> fa21
> |
> |
> fa12
> R1
>
> Sequential order from 1 to 8 (Note the metricN - where N is the path
> to the
> destination)
> --------------------------------------------------------------
> 1 - R2 receives "R1 loo0 - 1.1.1.1/32 " from R1 (Via R2 interface
> fa21)
>
> R2 routing table
>> 1.1.1.1/32 - metric21 - via fa21
>
> R2 topology table
> - 1.1.1.1/32 - metric21 - via fa21
> --------------------------------------------------------------
> 2 - R2 sends "> 1.1.1.1/32 - metric21" to R3 and R4
> --------------------------------------------------------------
> 3 - R3 receives "R1 loo0" from R2 (Via R3 interface fa32)
>
> R3 routing table
>> 1.1.1.1/32 - metric321 - via fa32
>
> R3 topology table
> - 1.1.1.1/32 - metric321 - via fa32
> --------------------------------------------------------------
> 4 - R4 receives "R1 loo0" from R2 (Via R4 interface fa42)
>
> R4 routing table
>> 1.1.1.1/32 - metric421 - via fa42
>
> R4 topology table
> - 1.1.1.1/32 - metric421 - via fa42
> --------------------------------------------------------------
> 5 - R3 sends "> 1.1.1.1/32 - metric321" to R4
> --------------------------------------------------------------
> 6 - R4 receives "R1 loo0" from R3 (Via R4 interface fa43)
>
> R4 routing table
>> 1.1.1.1/32 - metric421 - via fa42
>
> R4 topology table
> - 1.1.1.1/32 - metric421 - via fa42
> - 1.1.1.1/32 - metric4321 - via fa43 (*)
> --------------------------------------------------------------
> 7 - R4 sends "> 1.1.1.1/32 - metric421" to R3
> --------------------------------------------------------------
> 8 - R3 receives "R1 loo0" from R4 (Via R3 interface fa34)
> R3 routing table
>> 1.1.1.1/32 - metric321 - via fa32
>
> R3 topology table
> - 1.1.1.1/32 - metric321 - via fa32
> - 1.1.1.1/32 - metric3421 - via fa34 (**)
> --------------------------------------------------------------
>
>
> As you will note in (*) and (**) those are 2 different routes (same
> prefix,
> but different path and interface on which there were received).
>
> Your issue was, since R3 already learned the route 1.1.1.1/32 from R4,
> because of split horizon, R3 will not advertise that route back to
> R4: The
> answer
> is no; R3 is able to advertise the route that it received from R2
> because
> that route was received on a different interface - same prefix, but
> different path and interface.
> Like I said in my earlier post the key word here is "interface"
>
> Now you could add this other rule: ""The split-horizon rule
> prohibits a
> router from advertising a route through an interface that the router
> itself
> uses to reach the destination."
> "
> Which explain why R3 and R4 are not advertising the route 1.1.1.1/32
> back to
> R2, but this is another matter.
> ===============================
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Mon Jan 10 2011 - 16:28:10 ART