EIGRP best path selection with identical metric

[Map23]

Hello forum,

can anyone explain me which criterion is used for best path selection on EIGRP when "maximum paths" command is used and load balacing is active for one route.

For example if situation is like this:

D       10.1.3.0 [90/307200] via 10.1.2.4, 00:03:47, Ethernet0
                 [90/307200] via 10.1.2.3, 00:03:48, Ethernet0

And maximum paths  command is used, which route stay active on global table ?

I tried that on lab and seems that lower IP address is selected, but I didn't find official documentation about that.

Could anyone help me ?

Thank you

[cadet alain]

Hi,

you want to know which path the traffic will take with both routes installed in the routing table?

if so then the answer is that the router will load-share per src-dst ip pair due to CEF switching.

Regards

Alain

Don't forget to rate helpful posts.

[Map23]

Hello Alain,

thank you for your answer. My question is different. When you have the situation above:

D       10.1.3.0 [90/307200] via 10.1.2.4, 00:03:47, Ethernet0
                 [90/307200] via 10.1.2.3, 00:03:48, Ethernet0

routing is managed like your answer. But in this situation if you use "maximum paths" command only one route is used by the router. I want to say which is the regular criterion for the choice of this route.

Sorry, I hope that now my question is clear

Thank you

[shajakhan85]

Hi...

Good question...

Maximum paths command to use for multiple paths, but You configured maximum paths 1, which triggered this question.

Not to worry more about this. if you want prefered route as primary use variance.....

Maximum paths EIGRP defaults to 4 paths for load balancing but the maximum that can be set is 16.

[Peter Paluch]

Hi Marcello,

If I remember correctly, with maximum-paths 1, it is the first (i.e. oldest) route that get installed into the routing table. I vaguely recall labbing that up quite some time ago. Would that confirm your observation?

Best regards,

Peter

[Vignesh Rajendran Praveen]

Hi Marcello,

I confirm that it's the first one in that will stay and subsequent ones will be rejected by the RIB.

***********Plz do rate this post if you found it helpful*************************

Thanks & Regards,

Vignesh R P

[John Blakley]

From what I've just tested, it looks like it's choosing the lowest address of the two routes. I've tried clearing one of the neighbors to see if the oldest route was preferred, but it didn't seem to be.

For example, I had two routers addressed at 192.168.34.3 and 34.4. They both advertise 3.3.3.0/24. Changing max paths to 1 left 34.3 in the table. I shut the 34.3 neighbor down for a few seconds and brought it back up. The router still chose 34.3 after resetting maximum-paths back to default and then back to 1 again.

The next thing that I did was change 192.168.34.3 to 192.168.34.4. I then had 3.3.3.0/24 pointing to both .6 and .4. I changed to max paths again and .4 stayed in the table, but then again that could be due to what Peter said about the older route (although that's why I tried shutting down .3 to make .4 in the table longer, but that didn't help). This is a good question and I'd like to know the answer to it as well.

HTH,
John

*** Please rate all useful posts ***

[dslice]

I vaguely remember when the randomness was changed several years ago. I might be able to find the DDTs tomorrow at work, but it had to do with some DMVPN problem a teammate fixed by making the equal cost paths have a deterministic ordering. Peter was right that in the past it was purely temporal ordering.

Sent from Cisco Technical Support iPad App

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

This is really an interesting trivia question.  If something like this is not defined as part of the EIGRP "standard", then something you wouldn't want to rely on as it could be changed, and if Donald's memory is correct, has been.

[Map23]

Thank you to all,

John your test is equal to my lab and I found same results. Low IP is always preferred. The problem is that if is possible I need to find official Cisco documentation about it. Like this question:

Q. If there are two EIGRP processes that run and two equal paths are learned, one by each EIGRP process, do both routes get installed?

A. No, only one route is installed. The router installs the route that was learned through the EIGRP process with the lower Autonomous System (AS) number. In Cisco IOS Software Releases earlier than 12.2(7)T, the router installed the path with the latest timestamp received from either of the EIGRP processes. The change in behavior is tracked by Cisco bug ID CSCdm47037.

Found on:  http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a008012dac4.shtml#eight

If is possible I would like to find the same for my question, only for know if for all IOS low IP is always preferred.

Thank you so much for your answers.

Marcello

[dslice]

I found the DDTs where my teammate made the change I remembered.

CSCse42362

It has to do with topo table ordering to solve a DMVPN problem, but the effect is that the topo table is now ordered (within the equal-cost successors) based on IP address rather than temporal ordering.   This also impacts the order the topo table entries are used in the calls to the RIB for routing table installation, thus changing the determinism of the next-hop that successfully installs.

[John Blakley]

Okay...I think I can see what's going on even though I can't find any documentation on it. The route that's being installed is the lowest IP address because in the topology table it's sorted by address. If I change 192.168.123.4 to 192.168.123.2, then the topology table is resorted to 192.168.123.2 being the top of the list. Metrics play a large part in this though because if I change the delay on this loopback interface on .3, then .4 is moved to the top of the list.

Equal metrics:

P 2.2.2.0/24, 2 successors, FD is 156160

        via 192.168.123.3 (409600/128256), FastEthernet0/0

        via 192.168.123.4 (409600/128256), FastEthernet0/0

Another equal metric after changing the address 192.168.123.4 to 192.168.123.2:

P 2.2.2.0/24, 2 successors, FD is 156160

        via 192.168.123.2 (156160/128256), FastEthernet0/0

        via 192.168.123.3 (156160/128256), FastEthernet0/0, serno 8

The routing table looks like this:

D       2.2.2.0 [90/156160] via 192.168.123.3, 00:01:05, FastEthernet0/0

                [90/156160] via 192.168.123.2, 00:01:05, FastEthernet0/0

Changing max-paths to 1:

D       2.2.2.0 [90/156160] via 192.168.123.2, 00:00:04, FastEthernet0/0

Different metrics:

R1(config-if)#do sh ip eigrp top all

P 2.2.2.0/24, 1 successors, FD is 156160, serno 7

        via 192.168.123.4 (156160/128256), FastEthernet0/0

        via 192.168.123.3 (1308160/1280256), FastEthernet0/0, serno 8

So, from what I gather, having different metrics takes the preferred route to the top of the topology table. When we have equal cost routes, the preferred route is sorted by IP address.

To test this even further, I hung another subnet off of a different interface of R1 and addressed it at 10.24.0.1. R4 is addressed at 10.24.0.4. After playing with the metrics to get them exact, it shows up in the table for the same route:

D       2.2.2.0 [90/156160] via 192.168.123.3, 00:00:09, FastEthernet0/0

                [90/156160] via 192.168.123.2, 00:00:09, FastEthernet0/0

                [90/156160] via 10.24.0.4, 00:00:09, FastEthernet0/1

Changing max-paths to 1:

D       2.2.2.0 [90/156160] via 10.24.0.4, 00:00:05, FastEthernet0/1

Topology table:

P 2.2.2.0/24, 1 successors, FD is 156160, serno 17

        via 10.24.0.4 (156160/128256), FastEthernet0/1

        via 192.168.123.2 (156160/128256), FastEthernet0/0

        via 192.168.123.3 (156160/128256), FastEthernet0/0, serno 8

And as you can see below, 10.24.0.4 is the absolute newest neighborship:

R1(config-router)#do sh ip eigrp neigh

IP-EIGRP neighbors for process 100

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

1   10.24.0.4               Fa0/1             12 00:12:11   60   360  0  3

2   192.168.123.2           Fa0/0             13 00:21:37   63   378  0  29

0   192.168.123.3           Fa0/0             14 00:29:06   67   402  0  34

So I don't think it has to do with the oldest route, but rather the lowest IP address. I'd love to see this documented though...

HTH,

John

HTH,
John

*** Please rate all useful posts ***

[Map23]

Thank you to all,

we didn't find docs but, we have many evidence that confirm that lower IP is preferred. I hope that is the same for all last IOSs

Thank you

Regards

[jon]

HI

I have tested this on two different platforms:

1: 3560 running 12.2(55)SE

     result with maximum-path 1

     Router will always select oldes route

2: 1841 running 12.4(24)T1

     result with maximum-path 1

     Router will always select oldest route

Now as the EIGRP have an open draft I tried to look for answer how this is selected, without finding the answer

http://tools.ietf.org/html/draft-savage-eigrp-00

As far as I can see, oldes route is always selected

For my test I did no change to configuration, just pulling/unpulling cables

[dslice]

We put out a new copy of the draft recently, but I'm sure this implementation detail isn't in there. It's not important in producing a compatible implementation. Again, the change to making it IP address ordered rather than temporal ordering was to fix a problem and not really a design thing.

Sent from Cisco Technical Support iPad App