Re: EIGRP - Split Horizon

From: jules NYA BAWEU <nyabaweu_at_gmail.com>
Date: Sun, 9 Jan 2011 19:32:25 -0800

Guys,

I hate closing on this note, but please don't bite me.

I think at the end we missed the real point of our back and forth
discussion.

Dave, here is your original issue from your main post: "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???"

In your last post you said: "R3 and R2 now advertise the route to each other
because neither router is using the other as 'Best'."
That is not the real reason; the main reason is because R3 and R2 are
advertising 2 different routes (same prefix, but different routes path
received on different INTERFACE); I will elaborate on that.

First, lets start with the definition of Split horizon - according to
Cisco: "Split horizon blocks information about routes from being advertised
by a router out of any interface from which that information originated."

For the sake of it, lets forget about this other rule for now: "The
split-horizon rule prohibits a router from advertising a route through an
interface that the router itself uses to reach the destination."

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.

Please feel free to comment.

HTH

Thx

Blogs and organic groups at http://www.ccie.net
Received on Sun Jan 09 2011 - 19:32:25 ART

This archive was generated by hypermail 2.2.0 : Tue Feb 01 2011 - 07:39:17 ART