Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Community Member

EIGRP Variance value of 2

Hii,

I know there are a lot of EIGRP variance posts in this forum. But a good friend of mine stumblede across a scenario where the FS does not get installed in the RIB.

Topology:

Screen Shot 2011-12-22 at 7.54.49 PM.jpg

Configurations:

R1

interface Serial0/0

description ---- Link to R3 ---->

ip address 10.0.13.1 255.255.255.252

!

interface Serial0/1

description ---- Link to R2 ---->

ip address 10.0.12.1 255.255.255.252

delay 10

!

router eigrp 100

variance 2

network 10.0.0.0

no auto-summary

R2

interface Serial0/0

description ---- Link to R1 ---->

ip address 10.0.12.2 255.255.255.252

!

router eigrp 100

redistribute connected metric 1 1 1 1 1

network 10.0.12.2 0.0.0.0

no auto-summary

R3

interface Serial0/0

description ---- Link to R1 ---->

ip address 10.0.13.2 255.255.255.252

!

router eigrp 100

redistribute connected metric 1 2 1 1 1

network 10.0.13.2 0.0.0.0

no auto-summary

NOTE! I haven't enabled EIGRP on the interfaces between R2 and R3. Just needed a route in the RIB to redistribute (10.0.23.0/30)

Output from R1 where I want the unequal cost load sharing:

R1#sh ip eigrp topology all-links

P 10.0.23.0/30, 1 successors, FD is 2560002816, serno 98

        via 10.0.12.2 (2560002816/2560000256), Serial0/1, serno 94

        via 10.0.13.2 (2560512512/2560000512), Serial0/0, serno 97

R1#sh ip route eigrp

D EX    10.0.23.0 [170/2560002816] via 10.0.12.2, 00:25:40, Serial0/1

Only the FD is installed in R1's RIB. Why is that? I've meet the feasibility condition:

R3 RD = 2560000512

FD = 2560002816

2560002816 - 2560000512 = 2304 (which is less than the FD!)

I've tried with variance 3 and now the FS is installed into the RIB!!!

Can anyone please explain this weird observation?

Thanks

/JZ

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: EIGRP Variance value of 2

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

6 REPLIES
Bronze

EIGRP Variance value of 2

I'm curious why you're setting your delay higher on R3 than R2 on redistribution of connected.  I'm assuming 10.0.23.0 is a connected interface?  If you're trying to load share by just a variance statement on R1, then I'd think you would want to keep your metrics on R2 and R3 the same.

What happens if you match up your redistribution metrics on R2 and R3?

Community Member

Re: EIGRP Variance value of 2

@cflory: Well, I'm trying to make sense of the theory behind unequal cost load sharing with EIGRP. Keeping metrics the same with everything set to the default in this topology, EIGRP will automatically do equal cost load sharing, hence variance isn't needed.

And we can all agree that if a route meets the feasibility condition (RD is less than FD), EIGRP multiplies the FD with the value of the variance command and installs any FS route below or equal to the product of the calculation.

In the above example this calculation is: 2 x 2560002816 > 2560000512 (feasibility condition true)

Variance calculation: 2560512512 <= 2 x 2560002816 (true)

See my friends post about this here: http://www.packet-forwarding.net/?p=929

Thank you.

/JZ

Cisco Employee

Re: EIGRP Variance value of 2

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

Cisco Employee

EIGRP Variance value of 2

Hi Peter,

Thanks for taking timeout for this detailed explanation of the EIGRP behaviour. I will try to report this behavior/BUG to the EIGRP development team and comeback with an update.

Many thanks again.

Cheers,

-amit singh

Cisco Employee

EIGRP Variance value of 2

Hello Amit,

That is very kind of you, thank you!

Best regards,

Peter

Community Member

EIGRP Variance value of 2

Peter,

Very good examination. Good work!

I would also like to thank my good friend, Kim, for pointing out this bug. Curiosity is a great thing!

I'm looking forward to getting an update about this.

Merry Xmas.

/JZ

1811
Views
10
Helpful
6
Replies
CreatePlease to create content