EIGRP - Feasibility Condition

Unanswered Question
Feb 25th, 2010

Guys,

I am implementing a eigrp lab challenge. This was provided by a friend.

This lab required many configurations. I made all the tasks, however, the last one was to make a load balance to 1.1.1.0/21 between the interfaces se0/0 and se0/1.

When checking the topology table, the alternate path is not there because it does not conform the FC (feasibility condition). That's the correct and expected behavior. Anyway, on this lab, it was intensionally configured to get this way. hehe...

R3#sh ip eigrp top
<omitted for brevity>

P 1.1.0.0/21, 1 successors, FD is 41715
        via 10.0.230.1 (41715/501), Serial0/1
<omitted for brevity>

Using the all-links option, I can see the alternate route:

R3#sh ip eigrp top all-links
<omitted for brevity>

P 1.1.0.0/21, 1 successors, FD is 41715, serno 53
        via 10.0.230.1 (41715/501), Serial0/1
        via 10.0.220.2 (183771/181771), Serial0/0
<omitted for brevity>

I found two ways to make the load balance, (that worked), but according to my friend, those solutions are not the ones he wants. He told something related to disable the feasibility condition... I never heard before that is possible to turn the FC off or manipulate it.

My 2 solutions were:

Use offset-list to manipulate the metrics.

Use a route-map and manipulate the metrics (adding/subtracting)

With both routes on the topology table, I used variance.

Both solutions I did, was tested and worked.  They act in the same way.

I wondering because with my solutions, if something changes in the path between the R3 and the destination 1.1.0.0/21, like a bandwidth change on a remote router or it gets another path that increases/decreases the metric, using offset or any add/subtract metric solution, the load balancing might stop to work due the varicance value.

My question is:

Is possible to make load balance between those routes using other solutions than the listed above?

Below, the configs from R3 as follows:

R3 eigrp config:

router eigrp 1
network 0.0.0.0
metric weights 0 1 1 1 1 1
no default-information in
distance eigrp 90 80
no auto-summary

interface Serial0/0
description R3 TO R2
bandwidth 56
ip address 10.0.220.3 255.255.255.0
ip authentication key-chain eigrp 1 R3TOR2
serial restart-delay 0
!
interface Serial0/1
description R3 TO R1 - DLCI 301
bandwidth 256
ip address 10.0.230.3 255.255.255.0
ip hello-interval eigrp 1 3
ip hold-time eigrp 1 9
encapsulation frame-relay
serial restart-delay 0
frame-relay map ip 10.0.230.1 301 broadcast
no frame-relay inverse-arp

PS: I guess I can not change the bandwidth, but I can change the weight on K values (minimum value of 1).  I did not try yet to increase the K values and see what happens with the metrics.
.

Regards,

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Jon Marshall Thu, 02/25/2010 - 04:26

ronaldobf wrote:

Guys,

I am implementing a eigrp lab challenge. This was provided by a friend.


I wondering because with my solutions, if something changes in the path between the R3 and the destination 1.1.0.0/21, like a bandwidth change on a remote router or it gets another path that increases/decreases the metric, using offset or any add/subtract metric solution, the load balancing might stop to work due the varicance value.

My question is:

Is possible to make load balance between those routes using other solutions than the listed above?

PS: I guess I can not change the bandwidth, but I can change the weight on K values (minimum value of 1).  I did not try yet to increase the K values and see what happens with the metrics.
.

Regards,

Don't know whether this is what your friend is looking for but the metric is based by default on bandwidth and delay and it is this metric that is used for the feasible distance. So if you want to make the feasible distance irrelevant or more specifically the same everywhere simply set all the K values to 0 ie.

router eigrp 10

metric weights 0 0 0 0 0 0

with this all routes will show as [90/1] in the routing table. You would need to apply the metric command to all routers otherwise you get a K-mismatch error message.

Jon

ronaldobf Sat, 02/27/2010 - 18:43

Jon,

You're right. This is also another possible solution, anyway, I can not disable the K values. The minimum values for them is 1.

The lab asks:

- Use all K values

- Configure the bandwidth as shown on the drawing

No worries. I don't see any other solution I can take other than the listed below:

- Manipulate the metric via route-map/offset-list

- Manipulate the delay on the interface configuration

- Manipulate the K vweights

I could accomplish all the objectives of this lab, including the load balance. For my situation, I used a route-map to manipulate it.

Never mind. I was just wondering if there was any other way, since my friend still asks me for other, and, according to him, a better solution.

Thanks for your sugestion.

Actions

This Discussion

Related Content