EIGRP Tie-breaker

[jpl861]

Hey Guys,

I am trying to figure out what will be the behavior of EIGRP when 2 process are configured across the network with the same networks participating in the process. We are in the process of renumbering our EIGRP process so we can just maintain one across the domain but was wondering what will be the behavior once we connect the EIGRP islands with the end-state AS#.

I have tried this in the lab and it is always using the lower EIGRP AS#. It doesn't matter which order the EIGRP process came up but as long as there are 2 routes with the same metric and prefix length, it will always use the lower number EIGRP process. I cannot find a document referring to this but was wondering if this may be IOS specific or it's written somewhere.

Any idea?

Thanks!

[Richard Burts]

It is not clear what is your topology? I think that you are saying that you have two processes on each router (with different process numbers) and that each process has the same network statements, so that both processes will run on each interface. This means that both processes will form equivalent neighbor relationships and each process will learn the same routes and will have exactly the same next hop for each route learned. Is that the case?

I assume that you are looking for a way to validate the operation of both processes. I do not believe that you can use the content of the routing table to validate the operation of both processes. You would probably need to look into the topology table built by each process to be able to validate their operation.

HTH

Rick

[jpl861]

Yes Sir. Everything is the same but just running 2 process per router.

You can still validate using the RIB because it says "Known via "EIGRP XX:"" The lower AS# is always being used on my testing.

Here's a sample. Just 2 routers on a p2p setup with loopback addresses. All interfaces are in 10.x and network statements are 10.0.0.0 for both EIGRP 10 and 20.

IOU1#sh ip route 10.0.255.2
Routing entry for 10.0.255.2/32
Known via "eigrp 10", distance 90, metric 409600, type internal
Redistributing via eigrp 10
Last update from 10.0.12.2 on Ethernet0/0, 00:00:07 ago
Routing Descriptor Blocks:
* 10.0.12.2, from 10.0.12.2, 00:00:07 ago, via Ethernet0/0
Route metric is 409600, traffic share count is 1
Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Added EIGRP AS#5. Now, it's saying that best path is known via EIGRP 5.

IOU1#sh ip route 10.0.255.2
Routing entry for 10.0.255.2/32
Known via "eigrp 5", distance 90, metric 409600, type internal
Redistributing via eigrp 5
Last update from 10.0.12.2 on Ethernet0/0, 00:00:07 ago
Routing Descriptor Blocks:
* 10.0.12.2, from 10.0.12.2, 00:00:07 ago, via Ethernet0/0
Route metric is 409600, traffic share count is 1
Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

Created EIGRP 30. Route table's best path is still EIGRP 5.

IOU1#sh ip route 10.0.255.2
Routing entry for 10.0.255.2/32
Known via "eigrp 5", distance 90, metric 409600, type internal
Redistributing via eigrp 5
Last update from 10.0.12.2 on Ethernet0/0, 00:01:07 ago
Routing Descriptor Blocks:
* 10.0.12.2, from 10.0.12.2, 00:01:07 ago, via Ethernet0/0
Route metric is 409600, traffic share count is 1
Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

IOU1#sh ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(20)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.0.12.2 Et0/0 11 00:03:54 5 100 0 5
EIGRP-IPv4 Neighbors for AS(10)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.0.12.2 Et0/0 12 00:03:29 9 100 0 5
EIGRP-IPv4 Neighbors for AS(5)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.0.12.2 Et0/0 13 00:01:40 2 100 0 3
EIGRP-IPv4 Neighbors for AS(30)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.0.12.2 Et0/0 11 00:00:41 17 153 0 2

Created EIGRP 1. Route known from EIGRP 1.

IOU1#sh ip route 10.0.255.2
Routing entry for 10.0.255.2/32
Known via "eigrp 1", distance 90, metric 409600, type internal
Redistributing via eigrp 1
Last update from 10.0.12.2 on Ethernet0/0, 00:00:07 ago
Routing Descriptor Blocks:
* 10.0.12.2, from 10.0.12.2, 00:00:07 ago, via Ethernet0/0
Route metric is 409600, traffic share count is 1
Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

IOU1#show ip eig neigh
EIGRP-IPv4 Neighbors for AS(20)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.0.12.2 Et0/0 12 00:05:11 5 100 0 5
EIGRP-IPv4 Neighbors for AS(10)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.0.12.2 Et0/0 14 00:04:46 9 100 0 5
EIGRP-IPv4 Neighbors for AS(5)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.0.12.2 Et0/0 14 00:02:57 4 100 0 5
EIGRP-IPv4 Neighbors for AS(30)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.0.12.2 Et0/0 12 00:01:58 17 153 0 2
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.0.12.2 Et0/0 13 00:00:38 3 100 0 3

So I am not sure if this is a behavior specific to the IOS or this is really how it should behave but I cannot find any documentation.

IOU1#sh ip eigrp topo 10.0.255.2/32
EIGRP-IPv4 Topology Entry for AS(20)/ID(10.0.255.1) for 10.0.255.2/32
State is Passive, Query origin flag is 1, 0 Successor(s), FD is Infinity
Descriptor Blocks:
10.0.12.2 (Ethernet0/0), from 10.0.12.2, Send flag is 0x0
Composite metric is (409600/128256), route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 6000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Originating router is 10.0.255.2
EIGRP-IPv4 Topology Entry for AS(10)/ID(10.0.255.1) for 10.0.255.2/32
State is Passive, Query origin flag is 1, 0 Successor(s), FD is Infinity
Descriptor Blocks:
10.0.12.2 (Ethernet0/0), from 10.0.12.2, Send flag is 0x0
Composite metric is (409600/128256), route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 6000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Originating router is 10.0.255.2
EIGRP-IPv4 Topology Entry for AS(5)/ID(10.0.255.1) for 10.0.255.2/32
State is Passive, Query origin flag is 1, 0 Successor(s), FD is Infinity
Descriptor Blocks:
10.0.12.2 (Ethernet0/0), from 10.0.12.2, Send flag is 0x0
Composite metric is (409600/128256), route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 6000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Originating router is 10.0.255.2
EIGRP-IPv4 Topology Entry for AS(30)/ID(10.0.255.1) for 10.0.255.2/32
State is Passive, Query origin flag is 1, 0 Successor(s), FD is Infinity
Descriptor Blocks:
10.0.12.2 (Ethernet0/0), from 10.0.12.2, Send flag is 0x0
Composite metric is (409600/128256), route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 6000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Originating router is 10.0.255.2
EIGRP-IPv4 Topology Entry for AS(1)/ID(10.0.255.1) for 10.0.255.2/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600
Descriptor Blocks:
10.0.12.2 (Ethernet0/0), from 10.0.12.2, Send flag is 0x0
Composite metric is (409600/128256), route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 6000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Originating router is 10.0.255.2

[Richard Burts]

What you have posted is interesting. What you are doing is quite unusual. I understand the rationale of having two processes running on the router as a means of transitioning to a consistent AS number across the entire network. But it is still pretty unusual. What I am seeing is logical and appropriate. The RIB has a single entry for the destination. Did you expect multiple entries in the RIB? If you think about it an entry in the routing table consists of a destination address, a mask, an exit interface, and (perhaps) a next hop. If you think about it there is only one route to 10.0.255.2. You learn that single route from multiple neighbors, so there are multiple instances of that same route, but it is still the same route and so there is only a single entry in the routing table.

Perhaps you are thinking about the ability of EIGRP to learn a route from multiple neighbors (on different devices), and to create multiple entries in the routing table, and to do equal cost routing. In that case there would be two distinct paths and each will be an entry in the RIB. But in your case there is really only one path and one entry in the RIB.

So your question is simply if there are two (or more) instances of exactly the same path what does EIGRP use for a tie breaker? It could have used the oldest entry (the one learned first). But your experiment makes it clear that it uses the lowest AS number. Do you perceive a problem in this? Or is it just an attempt to understand the internals of the routing protocol?

Perhaps one of the engineers from Cisco just jump in with their insight?

HTH

Rick

[jpl861]

Thanks for the feedback Rick.

Basically here's the situation. The AS# to be removed is in the middle of the network. The distribution is running dual EIGRP process facing the core and edge devices. Some devices are still using the old AS (higher number) and some are using the new one. Although 90% of our DC is already running the new AS#. The core facing distribution is old EIGRP. Core facing other DCs are running new AS. Distribution facing edge devices use both old and new. So basically what we only need to do is to overlay the new EIGRP AS in the core to connect these 2 islands of EIGRP. But as you can see there are multiple redistribution points in the network, the distribution and core. So that's what I am currently testing. If I connect the 2 islands of new EIGRP AS then the redistribution should be out of the picture.

(eBGP/EIGRPAS1)Core(AS2)----(AS2)Distribution(AS1)----(AS1)Edge(AS1)

(eBGP/EIGRPAS1)Core(AS2)----(AS2)Distribution(AS2)----(AS2)Edge(AS2)

As you can see above (there are 2 scenarios). 

1. Distribution is redistributing routes between AS1 and AS2. In the core, there is also a mutual redistribution between the two AS#s.

2. The mutual redistribution is on Core and Edge only

It's a little bit more complex than that because the network statements in the distribution switch were also messed up including the redistribution filters.

Now, if I enable dual EIGRP between core and distribution and redistribute eBGP routes into both process, which one will EIGRP pick as best since they are both equal coming from different AS#. Right now eBGP routes are just getting injected to AS2 between the core and distribution. If I enable AS1 in between too and redistribute BGP to EIGRP AS1, distribution switch "may" get both routes from different AS so the question which is best. If it picks AS1 as best, then the segment between distribution and edge should have redistribution for those BGP redistributed routes, because prior to the dual process between core and distribution, those redistributed routes are advertised all the way to the edge for AS2 process. If it picks AS1 then a redistribution must take place.

We want to do it as fast as we could and very minimal changes that's why we are shooting for this kind of approach and not really deal with "this part of the network should be this AS and this should be that and bla bla bla, then we merge it after one by one." So it's more of "ships in the night" approach.

[Richard Burts]

I still do not have a good understanding of some of what you are describing. But let me respond to part of it. You mention that you would redistribute BGP into both EIGRP processes and then you ask which one EIGRP will prefer. I do not see that it will make any difference which one EIGRP prefers. Both EIGRP processes will learn external routes and will advertise those external routes to their neighbors in that AS. So each BGP route will be advertised to all routers in each AS. Every router should have two entries in the EIGRP tolopolgy table for each BGP route. It does not matter which one EIGRP prefers because exactly the same route gets into the routing table.

I have been thinking about your comment that you are doing mutual redistribution in some places. If there are situations where a device is running a single AS then it does introduce some complication. Assuming that some device is running AS1 and advertises some routes to a neighbor in AS1. That neighbor may be doing redistribution. If so then that device will have one route for the subnet with AD of 90 (internal EIGRP) in AS2 and will have an entry in AS2 for that subnet with AD of 170 external EIGRP). In that case it should be clear that on these routers that they will prefer the route from AS1.

Even though we now may have situations where we can determine which AS will be preferred I am not sure that ultimately it will make any real difference. No matter which is preferred it is still the same route (same destination, same mask, same outbound interface, same next hop) that is being advertised. And no matter which is preferred it will be the same route that gets placed in the RIB.

HTH

Rick

[jpl861]

Hi Rick,

Just an update here. Our migration was completed years back when we removed the other EIGRP AS. We basically have two EIGRP that we wanted to collapse into one that's why I asked last time if both EIGRP process has the same set of routes, which one will be picked up by the router. I found answer here from John Tiso.

If two EIGRP processes run and two equal paths are learned, one by each EIGRP
process, both routes do not get installed. The router installs the route that was learned
through the EIGRP process with the lower autonomous system number.

Thanks!

[Richard Burts]

Thanks for the update. Glad to know that your conversion went well. Interested in the confirmation that the lowest AS # determines which route is selected.