Re: EIGRP - Split Horizon

Jules,

>Please elaborate further if you think that is not the question I
answer.

I think it's the question you are attempting to answer, but -
according to my interpretation at least - you appear to be introducing
some new and undocumented logic in your effort to do so, which I
confess I find frustrating and perhaps leads me to come off as
"heated." Also, you earlier grafted on a piece of a private
communication - which lacks context here - in an attempt to make the
case that I had made an incorrect or misleading statement to Dave. I
also find that frustrating, because I was merely highlighting what I
believed to be the point of confusion (dang, I wish we had the use of
italics here!). I was not indicating in that quote what I thought to
be the correct or actual behavior, but rather what I thought to
probably be what Dave was >expecting< to happen, according to a
literal interpretation of the language of your earlier posted Rule 1
(which I include for reference below because not everybody uses a mail
client that organizes threads in "G-Mail" fashion - myself included).
It's normal to first ensure that you understand the problem or the
point of confusion at hand, which was the reason for having made that
statement - walking through things before we got started in earnest.
I believed I had clarified this in my earlier reply to your private
communication, so was surprised to see that resurface here.
"According to that definition.." being the more salient portion of the
overall quote (and here again, my soul pines for italics).

What I continue to interpret you to be stating is that there exists
some special "unique path" and "interface" logic within EIGRP. I have
read everything that I know to have been printed by Cisco and Cisco
press on the topic of EIGRP - and have deployed it on both small and
large scales - and I remain unaware of the existence of or need for
this logic. EIGRP is a distance-vector protocol, agreed? Granted, it
implements DUAL vs. Bellman-Ford and it is said by some to act in some
ways as a link-state protocol (which I would agree with). But at the
end of the day, the behavior of distance-vector EIGRP can be distilled
as follows (my words):

"Advertise every prefix/destination currently active in the routing
table to every neighbor active in the neighbor table, EXCEPT WHERE
SPLIT HORIZON WOULD PREVENT AN EIGRP SPEAKER FROM DOING SO." (I am
not yelling here, but rather am communicating in a world which, sadly,
lacks italics).

There is no special "path" or "INTERFACE" logic beyond that of which I
am aware. Nor does there seem to be a need of it. If you attempt to
follow such a logic (at least as I have interpreted it from your
earlier posts), I think you run into trouble pretty quickly - even
using the original topology under discussion. Following the R3->R2
metric change, the "path" from R3 to R1 Lo0 via R2 remains unique and
is still coming in on a different R3 interface than the R3 interface
connecting to R4, no? Doesn't your logic suggest that R3 advertise
this unique "path" via R2 to R4 (which it doesn't), because it is
being received by R3 on a different interface than the one connecting
it to R4 (it's now chosen neighbor to reach R1 Lo0 under this
scenario)? Dave posted that R3 ceased to advertise that particular
"path" out its interface to R4 with a simple metric increase toward
R2, which would, according to my understanding of EIGRP and all
distance-vector protocols, be precisely the expectation. The logic
being followed in this case is classic Rule 2 below. R3 at one point
was failing to advertising R1 Lo0 to R2 (as was R4) because R3 (and
R4) was using its interface toward R2 to reach that destination (as
you note below). This also is Rule 2. R3 [i]ceased[/i] (hey - I have
italics after all!) advertising R1 Lo0 to R4 at the point when the R3-
>R2 metric was increased such that R3 changed to selecting neighbor
R4 to Reach R1 Lo0 - even though the "path" via R2 is unique and
coming in on a different interface. Rule 2. R3 at that same time
[i]began[/i] advertising R1 Lo0 to R2 when it switched to the route
(or path, if you prefer) via R4. This can be explained with nothing
more than the above simple distance-vector logic of a router
advertising its "best" route to each and every destination/prefix
active in its local routing table to every active neighbor in the
neighbor table, [i]except where split horizon would prevent an EIGRP
speaker from doing so.[/i] This is the point in time in which the
whole Feasibility Condition logic comes into play and sorts out what
are certain to be loop-free paths and what are uncertain to be loop-
free paths (note that the FC logic can never determine that a path is
[i]certain[/i] to be looping - Query logic is required to sort this
out - but rather only that it [i]might be[/i] and thus can't be
considered to be an FS).

So to summarize where I think we're at...

You earlier stated that "I think at the end we missed the real point
of our back and forth discussion." You went on refute Dave's
assertion that "R3 and R2 now advertise the route to each other
because neither router is using the other as 'Best'," offering instead
a logic which involves "same prefix, but different routes path
received on different INTERFACE." I simply disagree that such a logic
exists or is needed. My position is that Dave's stated understanding
of EIGRP's behavior is, indeed, correct; R3 and R2 advertise every
active route to every active neighbor - except where to do so would
involve advertising a "best" route out a chosen "best" path -
including R1 Lo0 to each other. Nothing less, nothing more...

Earlier posted rules for reference:

> 1- "Split horizon blocks information about routes from being
> advertised by a router out of any interface from which that
> information originated."
> 2- "The split-horizon rule prohibits a router from advertising a
> route through an interface that the router itself uses to reach the
> destination."

On Jan 10, 2011, at 12:36 , jules NYA BAWEU wrote:

> Scott,
>
> I kinda noted that you came out a little heated in your last;
> please, be advise that I will bow to any knowledge that comes at me;
> that is why we are here.
>
> Having say that, just so we don't waste our time, I invite you to go
> to the original post by Dave and answer this question for us:
>
> "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???"
>
> Please elaborate further if you think that is not the question I
> answer.

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