Influencing Path Selection in EIGRP

[limtohsoon]

Hi Sir,

I have a network of 4 routers (see attached network diagram). All the links between the routers have the same bandwidth and delay values. EIGRP is enabled on all the routers' interfaces.

Thus, R1 has two equal-cost paths to 10.3.3.3/32 (loopback address of R4) via R2 (192.168.1.18) and R3 (192.168.1.34).

I'd like R1 to prefer the path R2>R4 to reach 10.3.3.3/32. My way of accomplishing this is by modifying the AD at R1, as follows:

R1 router

---------

!

router eigrp 1

distance 91 192.168.1.34 0.0.0.0 1

!

access-list 1 permit 10.3.3.3

!

The above config works; R1 has only a single path to 10.3.3.3/32, via R2 (192.168.1.18).

I'd like to get some second opinions from you all whether this method is the most ideal for this case. If you know of other recommended methods, please suggest to me.

Thank you.

B.Rgds,

Lim TS

[ankurbhasin]

Hi Lim,

You can also play with metrics. The way eigrp calculates metric is using a formula (10 to the power 7/ min bandwidth + total load)*256 and using the minimum bandwidth on the link and total load.

You can chnage the bandwidth value on the interface and play with the metric.

You can increase the bandwidth on the interface which you can to be a best path.

Check this link for more details

http://www.cisco.com/warp/customer/103/eigrp-toc.html#eigrpmetrics

You may need a CCO login for the same.

HTH

Ankur

[Richard Burts]

As Ankur says you can influence EIGRP choice of path by altering the EIGRP metric on an interface. You can alter the bandwidth or the delay. If you are going to manipulate the metric it is probably better to alter the delay than to alter the bandwidth.

There is another alternative which is also available to alter the EIGRP choice of path. It can be done using an offset list. An offset list can reference an access list so that you can influence the path for some routes and not others (if you alter the metric it is altered for ALL routes). You can apply an offset list to inbound advertisements (if you want to influence what the router learns from others) or you can apply an offset list to outbound traffic (if you want to influence what the router advertises to others).

As to which of the alternatives is the best, I think that it depends slightly on what it is that you want to accomplish. Once you have clearly defined your requirements it will be easier to choose which alternative will be best for that.

HTH

Rick

[limtohsoon]

Hi Richard,

I've tried the offset list alternative, as follows:

R1 router

---------

!

router eigrp 1

offset-list 1 in 20

!

access-list 1 permit 10.3.3.3

!

It works; R1 has only a single path to 10.3.3.3/32, via R2 (192.168.1.18).

Thank you.

B.Rgds,

Lim TS

[Kevin Dorrell]

Thanks for that useful tip Rick. I've been looking at the documentation, and there are a couple of points about it that are not entirely clear:

http://www.cisco.com/en/US/products/ps6350/products_command_reference_chapter09186a008044643e.html#wp1097748

First, if I apply an offset to an incoming advertisement, does that offset get propagated outwards when I re-advertise the route out the other interfaces? If so, which part of the composite metric is affected, the delay or the bandwidth? (I presume the offset is applied to the result of the calculation only locally.)

Secondly, as with all metric fiddling, if it is applied only locally, don't you have to be very careful that it does not end in a routing loop? After all, if I have adjusted the topology database locally, but the rest of the topology has a different view, that sounds like a recipe for loops.

That is one reason I would be very cautious about fiddling the AD, because my view of what consitutes the best route becomes different from everyone else's.

I guess these are potential pitfalls in all DV protocols.

Kevin Dorrell

Luxembourg

[limtohsoon]

Hi Kevin,

For curiosity sake, I've done a lab to test the effect of an offset route when propagated to upstream routers.

Say, R2 receives a route from R1 and it offset the route by 20. R2 installs the route in its routing table and, say, the metric is 40642580 (after 20 is added to the result of the calculation). R2 then advertises this route to R3. R3 sees the AD of this route via R2 as 40642580. However, the determination of minimum bandwidth and cumulative delay parameters are not affected by the offset. R3 will calculate the metric based on the formula like usual. After the metric is calcuated, R3 finally adds 20 to the metric and installs it in the routing table. In short, the offset is propagated to other routers.

What would you recommend then?

Thank you.

B.Rgds,

Lim TS

[Kevin Dorrell]

Lim

Sounds like the offset-list really is the most flexible way of influencing the route.

QED, right?

I wasn't sure about what you said about "However, the determination of minimum bandwidth and cumulative delay parameters are not affected by the offset." That kid of implies that the offset is propagated from R2 to R3 as a separate field in the routing update. Maybe it is, I don't have the packet format to hand.

But I did stumble across a document you might find useful if you have not seen it already:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c2d96.shtml#modifycompositemetric

Thanks for starting this enlightening thread.

Kevin Dorrell

Luxembourg

[Richard Burts]

Kevin

The offset list in EIGRP is a feature that took me a while to get comfortable with, so I sympathesize with your concerns.

First, if you apply an offset list to incoming updates, the additional value is added to the metric that is recorded in the EIGRP topology table. And this means that it will also affect any outbound advertisement of the prefix that EIGRP generates. And the offset value is added to the delay component and does not affect the bandwidth component. (Which makes good sense since the delay component is propagated along the complete path, while bandwidth is propagated only as far as it is the lowest bandwidth.)

Secondly, your assumption that the effect of the offset being only local is not correct. The effect of the offset list is propagated to neighbors. So your concerns about producing varying views of the network topology data base will not lead to problems.

HTH

Rick

[Kevin Dorrell]

OK, that's good. If it is propagated, the routing-loop problem disappears, along with any concerns about inconsistent feasible successors.

So it is like fiddling the delay metric in the usual way, but selectively by prefix. That sounds really useful. It must mean that you could use it to force some routes to go through a feasible successor rather than through the least cost route.

I was quite concerned about the previous suggestion of playing with the Administrative Distance, 'cos I know that is not propagated, and so can result in loops. Same goes for playing with the K constants, IINM.

Thanks again for your time.

Kevin Dorrell

Luxembourg

[Kevin Dorrell]

I was wrong about the K values. I've just been readng Doyle, and I see there is an "EIGRP Parameters" TLV message that get propagated from router to router, and which carries all the K values. (Page 366, Fig 8.29)

OTOH, I am looking at the IP Internal Routes TLV on page 367 Fig 8.30, and I don't see the offset being carried separately, unless it is using the "reserved" field starting at octet 22. Strangely, he seems to discuss offset lists only in the context of RIP, and not under EIGRP. I wonder why.

Kevin Dorrell

Luxembourg

[limtohsoon]

Hi Richard,

I've done a simple lab (see attached network diagram) to test the effect of the propagation of an EIGRP offset route.

After the offset-list was configured on R2, R3's cumulative delay to the 10.3.3.3/32 route is still 25100 usec, the same as before offset-list was configured on R2. The offset value of 20 was only added after the metric was calculated (i.e. 40642560 + 20 = 40642580). So, I doubt whether the offset value is actually added to the delay component when propagated by R2. Any thoughts?

Thank you.

B.Rgds,

Lim TS

[Richard Burts]

Lim

Your lab does seem to show that the offset affects the calculated metric but does not increment the delay. I thought I remembered working with this and seeing a change in delay, but that was a while ago and I no longer have those results.

In a way it makes it simpler if the offset is propagated separately and does not alter the delay. What seems to me to be important is that some components of the EIGRP metric cumulate along the path (delay and now it seems offset) while the other component (bandwidth) propagates to the point where there is a lower value and then the lower value is propagated.

Interesting experiment.

HTH

Rick

[ruwhite]

"The offset value of 20 was only added after the metric was calculated (i.e. 40642560 + 20 = 40642580). So, I doubt whether the offset value is actually added to the delay component when propagated by R2."

This is correct.... :-)

The offset is added after the metric calculation, and does not, AFAIK, modify the actual route metrics, so it won't influence the route on any of the router's neighbors.

The delay is cumulative, the bandwidth is always the minimum, and the offset is local only. If you want to set the actual delay in the route, the new route map support should let you:

http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a0080220721.html

Look at the "setting metrics" section. This will actually set the metric on the propagated route.

HTH.

:-)

Russ.W

[Kevin Dorrell]

Russ,

Does that mean that the offset has no influence over the advertised distance of thisrouter as seen by its upstream neighbors? This would make the behavior different to that of the offset in RIP, which really does add to the hop count. It also sounds as if it could break the loop-avoidance mechanism of EIGRP.

Your suggestion of setting the delay metric with a route map is interesting, but AFAICS it only allows you to set the delay to an absolute.value rather than an offset, so it might break if the topology changes.

Kevin Dorrell

Luxembourg

[Richard Burts]

Russ

It is with some trepidation that I disagree with you, but in this case I do. The effect of the offset is not local only. I have several router in my network which use offset lists. I have extracted information about one route which is advertised from the first router to the middle router which has an inbound offset. The middle router then advertises to the last router. I have extracted the EIGRP topology information for a route from the three routers which shows clearly that the effect of the offset list on the middle router is propagated to the third router.

! this is the topology table of the first router in the test

! note FD of 29184

!

sh ip eig top 172.16.5.0 255.255.255.128

IP-EIGRP (AS 1999): Topology entry for 172.16.5.0/25

State is Passive, Query origin flag is 1, 2 Successor(s), FD is 29184

Routing Descriptor Blocks:

10.6.67.1 (Vlan67), from 10.6.67.1, Send flag is 0x0

Composite metric is (29184/28928), Route is Internal

Vector metric:

Minimum bandwidth is 100000 Kbit

Total delay is 140 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 4

10.6.35.1 (Vlan35), from 10.6.35.1, Send flag is 0x0

Composite metric is (29184/28928), Route is Internal

Vector metric:

Minimum bandwidth is 100000 Kbit

Total delay is 140 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 4

! the route is advertised to the middle router which has an inbound offset of 60000

! that offset is reflected in the Reported Distance of 89184

! note the FD here is 91744

!

sh ip eig top 172.16.5.0 255.255.255.128

IP-EIGRP (AS 1999): Topology entry for 172.16.5.0/25

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 91744

Routing Descriptor Blocks:

10.12.25.1 (GigabitEthernet0/2), from 10.12.25.1, Send flag is 0x0

Composite metric is (91744/89184), Route is Internal

Vector metric:

Minimum bandwidth is 100000 Kbit

Total delay is 2583 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 5

! the route is advertised to the last router which has another inbound offset of 1000

! that offset is reflected in the Reported Distance of 92744

! note that the Reported Distance clearly includes the effect of the offset on the middle

!

sh ip eig top 172.16.5.0 255.255.255.128

IP-EIGRP (AS 1999): Topology entry for 172.16.5.0/25

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 17867080

Routing Descriptor Blocks:

10.24.44.33 (Tunnel1), from 10.24.44.33, Send flag is 0x0

Composite metric is (17867080/92744), Route is Internal

Vector metric:

Minimum bandwidth is 512 Kbit

Total delay is 502622 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1420

Hop count is 6

I am not clear what the mechanism is for propagating the offset. But clearly the offset is propagated.

HTH

Rick