EIGRP Topology Table All-Links

[Richard ICMP]

Hello fellas,

I am having trouble understanding an issue related to EIGRP and I would like to pick your brain on this matter.

Topology:

Current conditions:

• All physical links are FastEthernet with default bandwidth of 100 Mbps.
• EIGRP has been configured all all routers to advertise all directly connected interfaces/subnets. Full connectivity exists.
• Split-horizon enabled on all routers
• EIGRP auto-summary is disabled on all routers
• Variance is set to 1 by default
• Simulation ran on GNS3

EIGRP topology tables displaying all possible routes (successor, feasible successor, and non-successor routes) from the above routers:

R1

R1#sh ip eigrp topology all-links 
IP-EIGRP Topology Table for AS(100)/ID(1.1.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status 

P 1.1.1.0/24, 1 successors, FD is 128256, serno 1
        via Connected, Loopback1
P 192.168.34.0/24, 1 successors, FD is 30720, serno 10
        via 192.168.13.3 (30720/28160), FastEthernet0/1
        via 192.168.12.2 (33280/30720), FastEthernet0/0
P 192.168.12.0/24, 1 successors, FD is 28160, serno 2
        via Connected, FastEthernet0/0
P 192.168.13.0/24, 1 successors, FD is 28160, serno 3
        via Connected, FastEthernet0/1
P 192.168.24.0/24, 1 successors, FD is 30720, serno 6
        via 192.168.12.2 (30720/28160), FastEthernet0/0
        via 192.168.13.3 (33280/30720), FastEthernet0/1

R2

R2#show ip eigrp topology all-links 
IP-EIGRP Topology Table for AS(100)/ID(2.2.2.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status 

P 1.1.1.0/24, 1 successors, FD is 156160, serno 4
        via 192.168.12.1 (156160/128256), FastEthernet0/0
P 192.168.34.0/24, 1 successors, FD is 30720, serno 8
        via 192.168.24.4 (30720/28160), FastEthernet0/1
        via 192.168.12.1 (33280/30720), FastEthernet0/0
P 192.168.12.0/24, 1 successors, FD is 28160, serno 2
        via Connected, FastEthernet0/0
P 192.168.13.0/24, 1 successors, FD is 30720, serno 5
        via 192.168.12.1 (30720/28160), FastEthernet0/0
        via 192.168.24.4 (33280/30720), FastEthernet0/1
P 192.168.24.0/24, 1 successors, FD is 28160, serno 3
        via Connected, FastEthernet0/1

R3

R3#show ip eigrp topology all-links 
IP-EIGRP Topology Table for AS(100)/ID(172.16.3.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status 

P 1.1.1.0/24, 1 successors, FD is 156160, serno 9
        via 192.168.13.1 (156160/128256), FastEthernet0/0
P 192.168.34.0/24, 1 successors, FD is 28160, serno 7
        via Connected, FastEthernet0/1
P 192.168.12.0/24, 1 successors, FD is 30720, serno 10
        via 192.168.13.1 (30720/28160), FastEthernet0/0
        via 192.168.34.4 (33280/30720), FastEthernet0/1
P 192.168.13.0/24, 1 successors, FD is 28160, serno 6
        via Connected, FastEthernet0/0
P 192.168.24.0/24, 1 successors, FD is 30720, serno 15
        via 192.168.34.4 (30720/28160), FastEthernet0/1
        via 192.168.13.1 (33280/30720), FastEthernet0/0

R4

R4#show ip eigrp topology all-links 
IP-EIGRP Topology Table for AS(100)/ID(4.4.4.4)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status 

P 1.1.1.0/24, 2 successors, FD is 158720, serno 12
        via 192.168.34.3 (158720/156160), FastEthernet0/0
        via 192.168.24.2 (158720/156160), FastEthernet0/1
P 192.168.34.0/24, 1 successors, FD is 28160, serno 2
        via Connected, FastEthernet0/0
P 192.168.12.0/24, 1 successors, FD is 30720, serno 5
        via 192.168.24.2 (30720/28160), FastEthernet0/1
        via 192.168.34.3 (33280/30720), FastEthernet0/0
P 192.168.13.0/24, 1 successors, FD is 30720, serno 10
        via 192.168.34.3 (30720/28160), FastEthernet0/0
        via 192.168.24.2 (33280/30720), FastEthernet0/1
P 192.168.24.0/24, 1 successors, FD is 28160, serno 3
        via Connected, FastEthernet0/1

 Question:

From R4's perspective, it has two possible routes to the loopback  interface (1.1.1.0/24) configured on R1. Why R2 and R3 are only showing one possible route to 1.1.1.0/24 instead of two possible routes? 

From what I understand R4 should advertise the 1.1.1.0/24 route learned from R3 to R2. Likewise, R4 should advertise the 1.1.1.0/24 route learned from R2 to R3. Split horizon should not apply here (I believe) since R4 is not advertising the learned route (of 1.1.1.0/24) back to the interfaces they were received from. Even when though they won't meet the feasible condition, the routes should be displayed at all times at the "show ip eigrp topology all-links" table. 

Thanks for your knowledge in advance.

--Rich

[Georg Pauwen]

Hello,

your output means that the route did not pass the feasibility condition check. on R4:

P 1.1.1.0/24, 2 successors, FD is 158720, serno 12
via 192.168.34.3 (158720/156160), FastEthernet0/0
via 192.168.24.2 (158720/156160), FastEthernet0/1

The feasible distance (the first number) is larger than the reported distance, so the route is a feasible successor.

If the feasible distance is smaller than the reported distance, the route is not a feasible successor and hence does not get installed in the topology table.

Check the link below:

Feasible Distance, Reported Distance, and Feasible Successor

https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/16406-eigrp-toc.html#anc7

[Peter Paluch]

Hi Georg,

I respectfully disagree - those networks have passed the Feasibility Condition perfectly. Notice: FD (Feasible Distance) is 158720, RD (Reported Distance) through both neighbors is 156160, clearly smaller, and this satisfies the RD < FD condition.

The format of entries is:

P 1.1.1.0/24, 2 successors, FD is 158720, serno 12
  via 192.168.34.3 (158720/156160), FastEthernet0/0
  via 192.168.24.2 (158720/156160), FastEthernet0/1

Colors:

• Feasible Distance
• Reported Distance
• Computed Distance (not relevant for Feasibility Condition)

Admitted, all these distances in EIGRP are very easy to confuse :)

Best regards,
Peter

[Peter Paluch · Accepted solution]

Hi Rich,

The behavior you see here is correct. What we need to focus on is a slight, yet very common misunderstanding of the split-horizon rule.

What the split-horizon rule really says is: Never advertise a network out the interface you are using to reach that network - in other words, it is not that important on what interface you learn about a network; what's important is what is the outgoing interface toward that network, and that's the interface you should never advertise that network through. We are accustomed to think that the interface through which a router learns about a network, and the interface the router uses to reach that network are always the same, but that is not always true. As an example, just think about two routers, R1 advertising an already known route to its neighbor R2, and R2 advertising the route back to R1 because on R2, split-horizon was deactivated by configuration. Should R1 change its outgoing interface just because it learned about this network from R2? Surely not; that network would have a higher metric, and we would have a routing loop anyway. And should R1 stop advertising that network to R2 just because an advertisement about the same network came back from R2? Surely not; that would in fact prevent R1 from telling about that network to R2, so on R2, the network would disappear.

Now, R4 - quite correctly - uses both R2 and R3 as next hops to 1.1.1.0/24, and so both Fa0/0 and Fa0/1 are the outgoing interfaces:

P 1.1.1.0/24, 2 successors, FD is 158720, serno 12
        via 192.168.34.3 (158720/156160), FastEthernet0/0
        via 192.168.24.2 (158720/156160), FastEthernet0/1

Therefore, R4 is not allowed to advertise 1.1.1.0/24 through any of these interfaces, and that is why neither R2 nor R3 display that network even with all-links. Well... almost. What EIGRP uses is in fact Split Horizon with Poisoned Reverse - it does advertise this network back through Fa0/0 and Fa0/1 but with an infinite metric, so R2 and R3 will purposefully remove that network from their topology tables if they ever had it there pointing to R4.

Feel welcome to ask further!

Best regards,
Peter

[Georg Pauwen]

Peter,

good stuff ! Thanks for clarifying, I always only thought of split horizon in combination with frame relay (sub)interfaces.

Indeed when split horizon is disabled, this is the output of 'show ip eigrp topology all-links' on R2:

P 1.1.1.0/24, 1 successors, FD is 156160, serno 17
via 192.168.12.1 (156160/128256), FastEthernet0/0
via 192.168.24.2 (161280/158720), FastEthernet0/1

[Richard ICMP]

Hi Peter, 

Thanks a bunch for the response and for looking into this scenario. 

You've provided a different way of looking into the split horizon concept. That's a good insight. Thank you for that! It bugs me that every book defines split horizon as a distance vector mechanism that prevents the advertisement of a learned route back to the interface where it was learned from.

I do, however, have a follow-up question (perhaps a few more but I will ask one question at a time). 

Quoting a section from your earlier response:

"What EIGRP uses is in fact Split Horizon with Poisoned Reverse - it does advertise this network back through Fa0/0 and Fa0/1 but with an infinite metric, so R2 and R3 will purposefully remove that network from their topology tables if they ever had it there pointing to R4."

I checked this by boucing the loopback interface (1.1.1.0/24) on R1 and took packet captures on R4's Fa0/0 (to R3) and Fa0/1 (to R4). R4 does indeed advertise the 1.1.1.0/24 route to R3 and R4 but they are not installed in the topology table (all-links) of R2 and R3.

What clasifies as infinite metric in EIGRP when route poisoning (or poison reverse) is in effect? In RIP, infinite metric would be a hop count of 16 but I am unsure of EIGRP. 

Below are some snippets extracted from my Wireshark capture:

R4 sending EIGRP update for 1.1.1.0/24 on its Fa0/0 to R3:

Cisco EIGRP
    Version: 2
    Opcode: Update (1)
    Checksum: 0xa45f [correct]
    Flags: 0x00000000
    Sequence: 17
    Acknowledge: 0
    Virtual Router ID: 0 (Address-Family)
    Autonomous System: 100
    Internal Route(IPv4)  =   1.1.1.0/24
        Type: Internal Route(IPv4) (0x0102)
        Length: 28
        NextHop: 0.0.0.0
        Legacy Metric
            Scaled Delay: 4294967295
            Scaled BW: 25600
            MTU: 1500
            Hop Count: 2
            Reliability: 255
            Load: 1
            Route Tag: 0
            Flags
        Prefix Length: 24
        Destination: 1.1.1.0

R4 sending EIGRP update for 1.1.1.0/24 on its Fa0/1 to R2:

Cisco EIGRP
    Version: 2
    Opcode: Update (1)
    Checksum: 0xa460 [correct]
    Flags: 0x00000000
    Sequence: 16
    Acknowledge: 0
    Virtual Router ID: 0 (Address-Family)
    Autonomous System: 100
    Internal Route(IPv4)  =   1.1.1.0/24
        Type: Internal Route(IPv4) (0x0102)
        Length: 28
        NextHop: 0.0.0.0
        Legacy Metric
            Scaled Delay: 4294967295
            Scaled BW: 25600
            MTU: 1500
            Hop Count: 2
            Reliability: 255
            Load: 1
            Route Tag: 0
            Flags
        Prefix Length: 24
        Destination: 1.1.1.0

Thanks in advanced.

--Rich

[Richard ICMP]

<deleted>  

[Peter Paluch]

Hi Rich,

You are very much welcome!

What clasifies as infinite metric in EIGRP when route poisoning (or poison reverse) is in effect? In RIP, infinite metric would be a hop count of 16 but I am unsure of EIGRP.

In EIGRP, the infinite metric is represented by setting the delay component of the metric to the maximum value that can be expressed in the EIGRP packet field that carries the delay component. With older IOSes, EIGRP used what we call Classic Metrics - the ones you are using yourself in your topology - and the maximum delay would be 0xFFFFFFFF (4 bytes). With newer Wide Metrics, the maximum delay would be 0xFFFFFFFFFFFF (6 bytes). The choice of metric style is performed when two routers establish their EIGRP adjacency, depending on what metric styles they support; if they support both, they will use Wide Metrics.

Keep the questions coming!

Best regards,
Peter

[Richard ICMP]

Hi Peter,

Thanks for the response. That is my last question for this thread. I learned a lot and I was able to figure the rest of the things out that I had questions about thanks to your initial response. 

A big thank you for sharing your knowledge with the rest of us. This is my first time posting and I will for sure continue to use this channel. Thanks again!

Cheers,

--Rich

[Peter Paluch]

Hi Rich,
Thank you very much for your kind words. You are very much welcome and I am very glad that you have found these forums useful. Feel always welcome to raise a new discussion here!
Best regards,
Peter

[Julio E. Moisa]

Hi Richard,
Georg and Peter have answered your question, also Split-horizon is not recommeded to be disabled unless you are using NBMA networks.

[Georg Pauwen]

Julio,

actually I didn't answer the question, but I learned something from Peter's explanation of how split horizon works. You are absolutely right, disabling it is not a good idea...

[Julio E. Moisa]

Thank you George, 

@Richard ICMP if the EIGRP metric using default K values, it is calculated through the following simplified formula:

256 x (BW + Delay)

But it is represented like:

256  x  [ (10^7 / minimum bandwith through the destination)  -   ( Sum of delays / 10 )]

R4 has 2 paths with the same information (delay and bandwidth) so you will see 2 paths (equal paths) into the EIGRP topology table , R2 and R3 are going to install the best route to the destination into the routing table.

:-)