Re: EIGRP - Split Horizon

Ahh, well then, we are not as much in agreement as I had come to
suspect:

>...in fact they were different routes...

I can't recall ever having seen EIGRP (or any other IGP, for that
matter) described to function in this way (I, of course, do not assert
that it's absolutely not the case - just that I can't personally
recall ever having heard of or read about such a concept). When you
look in R3's topology table (using the 'all-links' switch) to view the
entry for R1 Lo0, how is it organized? Don't we see a single entry
for 1.1.1.1/32 and then, indented, two different interfaces through
which it is reachable? If R3 were to consider that it had two unique
1.1.1.1/32 prefixes in its topology table, wouldn't it stand to reason
that we'd see two distinct entries instead? That would certainly be
my guess but how are we to know (unless we are fortunate enough to
have an EIGRP code writer lurking on the list who in a fit of
temporary insanity due to this protracted dialog suddenly breaks into
the thread and lays it all out for us)?

At the end of the day it's not important to me how the EIGRP code
writers went about the mechanics of their job. In the three interface
scenario I posted, your "Rule 1" would prevent R3 and R4 from
advertising R1 Lo0 to each other. (And, of course, it goes without
saying that in a classic FR topology, Rule 1 would prevent a hub from
advertising a route from Spoke 1 to Spoke 2 until you go in and kill
Split Horizon on that multipoint interface.) Absent such a scenario
(so back to having six distinct interfaces involved to connect R2, R3,
and R4), the only other thing left for an EIGRP speaker to do is to
simply flood all of the active entries in its routing table to all the
active neighbors in the neighbor table [i]unless to do so would mean
advertising its current "best" route along the current "best" path.[/
i] From my perspective, the interface logic of Rule 1 just flat
doesn't apply in this scenario because there's no common interface
shared between R3 and R4 that lies along their current best path. So
move to Rule 2 and get on with it. Why bother carrying an identical
prefix multiple times over in a table when simply following basic
Split Horizon and DUAL logic will do the trick? Is there some
advantage to this approach? The one seemingly obvious disadvantage
would be additional memory consumption to set up the duplicate data
structures in the table, no? Not a code jockey but that stands to
reason in my mind.

Yes, a third musketeer would be great but unless they wrote (or write)
EIGRP code I'm not sure how we'll get anything other than additional
[i]opinion[/i] on the matter at this point?

I'm satisfied that I finally understand where our views diverge on
this topic. I guess it'll be up to poor old Dave to reason out what
he thinks makes the most sense or whether or not any of it really
matters all that much in the end! ;-)

Peace-out!

On Jan 10, 2011, at 5:15 , jules NYA BAWEU wrote:

> Again,
>
> let's stick with the original issue Dave had:
> 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???"
>
> - I might be wrong, but I think Dave is saying: Once R3 sent
> "1.1.1.1/32" that it had learned from R2 to its neighbor R4, upon
> receipt R4 would never advertised that same prefix "1.1.1.1/32 "
> back to R3. The answer is "yes" R4 should be able to advertise the
> same prefix "1.1.1.1/32 " back to it neighbor R3 , but this time it
> would be the prefix (same "1.1.1.1/32 ") that R4 received from R2:
> how does R4 differentiates the prefix "1.1.1.1/32 " received from R3
> from the same prefix "1.1.1.1/32 " received from R2? R4 does that by
> linking each prefix to the INTERFACE where received.
>
> This is not even Split Horizon related. The Split Horizon will come
> in place if R4 was trying to advertise back to R3 the same prefix
> "1.1.1.1/32 " received on its interface connecting it to R3 - then,
> that would be prevented.
>
> Now if if R3 had picket R4 (or vice-versa) as its best path outgoing
> neighbor, then R3 would never advertise the prefix "1.1.1.1/32 "
> received from R2 to its neighbor R4 - this is where what we have
> called here "rule 2" comes in play.
>
> That's why I spent a 30 min drafting a scenario to help Dave
> understand that although R3 and R4 were exchanging info related to
> the prefix "1.1.1.1/32 ", in fact they were different routes - that
> is what made is possible.
>
>
> At this point I would really love a third musketeer to chime in
> please...

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