- Topics
- Network Infrastructure
- Security
- Collaboration, Voice and Video
- Wireless - Mobility
- Small Business Support Community
- International Zone
- Small Business FAQ
- Small Business Online Device Emulators
- OnPlus Service
- Small Business Security
- Voice Systems
- Small Business Support Community
- Jabber Video Support
- Small Business Network and Smart Storage
- Small Business Wireless
- WebEx Telepresence
- Online Chat Support
- FindIT Network Management Discussions
- Non-Product Related Small Business Technical Questions
- Small Business Routers
- Small Business Smart Tips
- Small Business Support Service
- Small Business Switches
- Small Business Surveillance
- Regional Service & Support Options
- ATAs, Gateways and Accessories
- Small Business Voice and Conferencing

- Data Center
- Service Providers
- Services
- Solutions and Architectures

- Experts
- Events
- Community

- Cisco Support Community
- :
- Network Infrastructure
- :
- LAN, Switching and Routing
- :
- EIGRP Variance value of 2

Options

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page

turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-22-2011
11:35 AM

12-22-2011
11:35 AM

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:

Configurations:

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

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

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

Solved! Go to Solution.

Labels:

1 ACCEPTED SOLUTION

Accepted Solutions

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-23-2011
04:43 PM

12-23-2011
04:43 PM

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

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-22-2011
11:56 AM

12-22-2011
11:56 AM

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?

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-23-2011
09:50 AM

12-23-2011
09:50 AM

@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

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-23-2011
04:43 PM

12-23-2011
04:43 PM

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

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-24-2011
12:44 AM

12-24-2011
12:44 AM

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

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-24-2011
01:12 AM

12-24-2011
01:12 AM

Hello Amit,

That is very kind of you, thank you!

Best regards,

Peter

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-24-2011
01:58 AM

12-24-2011
01:58 AM

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

Latest Documents

Created by Kevin DeMott
on 04-19-2018
01:49 PM

0

0

0

0

We have 3 identical switches configured by someone else and would like to claim some of the Gigabit ports(G1/G2/G3/G4) for use on servers. When we try to change the wiring and configuration, we run in to connectivity issues. Attached is a des...
view more

Created by Dennis Mink
on 03-06-2018
09:17 PM

8

10

8

10

This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does
"Th...
view more

Created by mustiman
on 03-05-2018
05:53 AM

5

0

5

0

Question
bonjours
j ai une question j ai achete un routeur cisco 887VA-k9 , je le configuré avec la configuration ci- dessous
si je le lier avec mon pc portable sur l un de ses ports directement ça marche toute est bien ( la connexion internet + m...
view more

1811

Views
10

Helpful
6

Replies
Popular Blogs

Created by ashirkar
on 10-01-2013
02:06 AM

7

74

7

74

Created by ashirkar
on 10-18-2012
03:19 AM

31

49

31

49

Created by Akula Jyoti Lakshmi
on 08-09-2011
09:13 PM

15

43

15

43