Jacob,
I have replicated your config on C2691 IOS, 12.4(15)T13 Advanced IP Services, and I can confirm the surprising behavior myself: when using exactly the redistribution metric you suggested, indeed, the variance 2 is apparently not sufficient to allow the feasible successor route to be entered into the routing table.
After an extended experimenting, I believe I understand now what is going on. There is an outspokenly silly bug in the IOS code: the resulting EIGRP metric is obviously stored in IOS as an unsigned 4B integer (a classic unsigned int in C language) which can overflow if the route's metric and the multiplier in the variance command are sufficiently large. Please bear with me while I try to explain this in a bigger detail.
The variance N command allows using all feasible successor routes which satisfy the condition
FS_metric <= S_metric * N
(the feasible successor metric may be at most N times higher than the current successor metric, but not more)
FS is the feasible successor and S is the successor. Note the hidden gotcha: if the (S_metric * N) grows above the maximum value that can be stored in an unsigned int (which is 4294967295), this value simply overflows. The overflowed result will be matematically equal to the value of (S_metric * N) MOD 2^32 and may or may not satisfy the above variance condition anymore, hence the erroneous behavior you are experiencing.
This means that actually, only a selected set of variance values would, in your particular case, allow the FS route to be used. I've concocted a quick-and-dirty C program to print out the values of the (S_metric * N) constrained into 4B unsigned int:
#include
int main(void) {
unsigned int i;
for (int j = 2; j <= 128; j++) {
i = 2560002816 * j;
printf ("%d: %u %s\n", j, i, (2560512512<=i)?"Y":"N");
}
return 0;
}
The program prints out the value of N used in the variance command, the value of (S_metric * N) derived from your S_metric=2560002816 and compares it to the value of FS_metric=2560512512. If the FS_metric is lower or equal, it says "Y", otherwise, it says "N".
After running the program and filtering out only the responses with "Y", this was the output:
3: 3385041152 Y
5: 4210079488 Y
8: 3300153344 Y
10: 4125191680 Y
13: 3215265536 Y
15: 4040303872 Y
18: 3130377728 Y
20: 3955416064 Y
23: 3045489920 Y
25: 3870528256 Y
28: 2960602112 Y
30: 3785640448 Y
33: 2875714304 Y
35: 3700752640 Y
38: 2790826496 Y
40: 3615864832 Y
43: 2705938688 Y
45: 3530977024 Y
48: 2621050880 Y
50: 3446089216 Y
52: 4271127552 Y
55: 3361201408 Y
57: 4186239744 Y
60: 3276313600 Y
62: 4101351936 Y
65: 3191425792 Y
67: 4016464128 Y
70: 3106537984 Y
72: 3931576320 Y
75: 3021650176 Y
77: 3846688512 Y
80: 2936762368 Y
82: 3761800704 Y
85: 2851874560 Y
87: 3676912896 Y
90: 2766986752 Y
92: 3592025088 Y
95: 2682098944 Y
97: 3507137280 Y
100: 2597211136 Y
102: 3422249472 Y
104: 4247287808 Y
107: 3337361664 Y
109: 4162400000 Y
112: 3252473856 Y
114: 4077512192 Y
117: 3167586048 Y
119: 3992624384 Y
122: 3082698240 Y
124: 3907736576 Y
127: 2997810432 Y
In other words, only the values before the colon sign can be used in the variance command to achieve the unequal-cost load balancing. Other values will result in an overflow whose resulting value is such that the FS_metric no longer satisfies the necessary condition mentioned at the beginning of my post. You can see that using variance 3 will work while, for example, using variance 2 will not. In fact, all following values for variance command will not yield correct results:
2: 825038336 N
4: 1650076672 N
6: 2475115008 N
7: 740150528 N
9: 1565188864 N
11: 2390227200 N
12: 655262720 N
14: 1480301056 N
16: 2305339392 N
17: 570374912 N
19: 1395413248 N
21: 2220451584 N
22: 485487104 N
24: 1310525440 N
26: 2135563776 N
27: 400599296 N
29: 1225637632 N
31: 2050675968 N
32: 315711488 N
34: 1140749824 N
36: 1965788160 N
37: 230823680 N
39: 1055862016 N
41: 1880900352 N
42: 145935872 N
44: 970974208 N
46: 1796012544 N
47: 61048064 N
49: 886086400 N
51: 1711124736 N
53: 2536163072 N
54: 801198592 N
56: 1626236928 N
58: 2451275264 N
59: 716310784 N
61: 1541349120 N
63: 2366387456 N
64: 631422976 N
66: 1456461312 N
68: 2281499648 N
69: 546535168 N
71: 1371573504 N
73: 2196611840 N
74: 461647360 N
76: 1286685696 N
78: 2111724032 N
79: 376759552 N
81: 1201797888 N
83: 2026836224 N
84: 291871744 N
86: 1116910080 N
88: 1941948416 N
89: 206983936 N
91: 1032022272 N
93: 1857060608 N
94: 122096128 N
96: 947134464 N
98: 1772172800 N
99: 37208320 N
101: 862246656 N
103: 1687284992 N
105: 2512323328 N
106: 777358848 N
108: 1602397184 N
110: 2427435520 N
111: 692471040 N
113: 1517509376 N
115: 2342547712 N
116: 607583232 N
118: 1432621568 N
120: 2257659904 N
121: 522695424 N
123: 1347733760 N
125: 2172772096 N
126: 437807616 N
128: 1262845952 N
You can easily see why - for example, variance 2 will try to compare the FS_metric to the value of 2560002816*2 - however, the result of this multiplication is stored into an unsigned integer variable and overflows - the variable will hold the value of 825038336 which is not larger than
the FS_metric=2560512512:
825038336 - 2560512512 = -1735474176
So the surprising behavior we're experiencing here is actually just a simple integer overflow bug... Is anyone from EIGRP development team reading this to have this bug corrected?
Best regards,
Peter
