Re: EIGRP - Split Horizon

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 - 16:15:43 ART