cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6788
Views
20
Helpful
24
Replies

Load Balancing across GRE Tunnels, EIGRP

michael brock
Level 1
Level 1

Hello, First post here and I did do a search, but didnt come up with much.

I have two GRE tunnels across 2 seperate WAN links. One link is 45 Mbps and the other link is 6Mpbs. I was thinking the Variance command would be the choice here(well only choice)  since we are running EIGRP.

Below are the (Edited)configs on the spokes

First tunnel

           

INTERFACE TUNNEL 10500

DESCRIPTION 45Mbps

DAMPENING

BANDWIDTH 45000

IP ADDRESS X.X.X.X

TUNNEL SOURCE X.X.X.30

TUNNEL MODE IPSECIPV4

TUNNEL DESTINATION X.X.X.29

SERVICE POLICY OUTPUT SHAPING-45000

Second Tunnel

INTERFACE TUNNEL 10501

DESCRIPTION 6Mbps

DAMPENING

BANDWIDTH 6312

IP ADDRESS X.X.X.X.

TUNNEL SOURCE SERIAL 0/0/0

TUNNEL DESTINATION X.X.X.46

SERVICE POLICY OUTPUT SHAPING-6312

This is my first project for my new job, so I obviously want to get it right. If I am missing some critical information or you need clarification on something, please do not hesitate to request it.

Thanks in advance

1 Accepted Solution

Accepted Solutions

Hello Micheal,

If you do a sh ip route eigrp  at present their should be only on path for all routes in the rib table.

Now when you apply a variance value this will install another path into the rib, meaning you will then have two paths showing in the routing table.

The variance calculation can be done by the metric extracted from the Eigrp topology table:

P 10.170.9.24/30, 1 successors, FD is 1345280

       via 10.170.2.50 (1345280/65280), Tunnel10500, serno 72548

       via 10.170.2.56 (1688576/65280), Tunnel10501, serno 72568

1345280/1688576 =1.25 round out the highest value =  variance 2

@Richard/Joseph

I think what I am trying to get at, is with or without the variance, CEF will default to forward via per destination anyway. I agree deterministically if the variance is applied and a new path is now availble, another scr/dst could use this new path, BUT wouldnt this other scr/dst always use that same path, and not load share between the two without per-packet...correct???

(by the way in my testing i used a variance of 9)

res

Paul

Please don't forget to rate this post if it has been helpful.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

View solution in original post

24 Replies 24

Richard Burts
Hall of Fame
Hall of Fame

Michael

Variance might work for you, but it is certainly not your only option. You have shown us the tunnel configuration but not the EIGRP configuration, which might be helpful for us to see.

Note that in using variance the less desirable path must still qualify as a feasible successor. With the large difference in bandwidth between the links I am not sure whether this will qualify. If it does then variance should produce load sharing.

If it does not qualify then there is an alternative that I would suggest to you. Use EIGRP to select the 45Mb as the primary path and the 6 Mb as a backup/failover path. Then use Policy Based Routing to send some traffic over the 6 Mb path. This also produces the load sharing effect.

I will note that one of your tunnels has the tunnel mode ipsec ipv4 command (but does not have the necessary space between ipsec and ipv4) and the other tunnel does not have it. And neither of the tunnels has the command

tunnel protection IPsec profile profile-name

which you will need.

HTH

Rick

HTH

Rick

Richard, Thank you for the response. I left some items out of the configs for ease of reading. These tunnels are currently up and operational. so I dont need to build them, I just need to be able to load balance between them.

Below is the EIGRP routing configuration

Router EIGRP 200

net 10.170.0.50 0.0.0.0

net 10.170.2.50 0.0.0.1

net 10.170.2.52 0.0.0.1

net 10.170.2.54.0.0.0.1

net 10.170.2.57 0.0.0.0

net 10.170.2.172 0.0.0.3

net 10.170.3.44 0.0.0.3

net 10.170.2.172 0.0.0.3

passive-interface default

no passive-interface Tunnel 10500

no passive-interface Tunnel 10501

no passive-interface Tunnel 20500

permit eigrp any any

Thanks again for your help

Michael

It is good to know that the tunnels are already up and operational. With bandwidths of 45 and 6 you would need a variance of at least 9. And with that amount of difference my comments about the requirement that the less desirable path still qualify as a feasible successor still applies. And my suggestion about using PBR is still an alternative to consider.

HTH

Rick

HTH

Rick

michael brock
Level 1
Level 1

Thanks and I think you might be right, I am not seeing the 6Mbps path showing up in as a FS when I run the command "show ip eigrp topology 10.170.2.52, ony the route through tunnel 10500 (The 45Mbps) shows up. the 6 meg is not present. Looks like Ill be looking into so PBR.

Thanks again for your help, and if you have some other suggestions or comments, feel free to share!

Joseph W. Doherty
Hall of Fame
Hall of Fame

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

A PIRO version of PfR might be an alternative solution.

Hello Michael,

FYI when using the variance command in eigrp on links with different metric costs, you are initating unequal-loadbalancing,

meaning if you use a raitio of 9,  8 packets will go via the 45 mb link and the 9th packet via the 6mb link and thats providing you also enable ip cef per-packet load-balancing  as by default cef is set to per- destination.

can you post your running config and also sh ip eigrp topology

res

Paul

Please don't forget to rate this post if it has been helpful.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

FYI when using the variance command in eigrp on links with different metric costs, you are initating unequal-loadbalancing, 

meaning if you use a raitio of 9,  8 packets will go via the 45 mb link and the 9th packet via the 6mb link and thats providing you also enable ip cef per-packet load-balancing  as by default cef is set to per- destination.

I thought without per-packet (which is often inadvisable for flow sequencing reasons), CEF balances flows in the ratios between paths, equal or unequal.  No?

Hello Joseph,

As i understand this variance command and when it is applied by calculation of the Highest/lowest metric for the advertised  route, the src to dst path is consistent to per-destination load-sharing, and the secondary path isnt utilised until per-packet load sharing is applied.to the interfaces.

This can be verified this by checking cef  table in succession sh ip cef exact-route x.x.x.x y.y.y.y (scr des)

The variance aplied on it own does only allow for the additional path to be submitted into the rib table


I do agree we regards to per-packet load sharing being responsible for the re-ordering of packet arriving out of sync and can drop certain data traffic.

Please correct me if I am wrong in my interpretation of this feature as I dont wont to submitting incorrect information.

( by the way in my previous post, I meant to say with a variance of 9, after every 9 packets that goes the 45 mb link 1 packet will go the 6mb link)

res

Paul

Please don't forget to rate this post if it has been helpful.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Variance enables unequal metric load sharing and should work whether sharing is per destination (per flow) or per packet.

People sometimes think that per packet should be attractive because they think that it will produce more equal utilization. But I can show scenarios where per packet does not produce equal utilization.

Given a reasonably diverse set of flows (source/destination pairs) per destination sharing produces pretty much equal utilization. And if the flows are not reasonably diverse then you can not be sure of what utilization will be produced with either type of load sharing. So in general it is preferable to use the default of per destination load sharing.

There are some situations where per packet sharing is beneficial. If you are sure that you have one then use per packet. But if you are not sure then it is safer to use per destination.

HTH

Rick

HTH

Rick

Hello richard,

here are some test results which I am basing my assumptions on.


R1#sh ip route eigrp

     2.0.0.0/24 is subnetted, 1 subnets

D       2.2.2.0 [90/557056] via 100.1.12.2, 00:12:41, FastEthernet0/1

                [90/187392] via 10.1.12.2, 00:12:41, FastEthernet0/0

     22.0.0.0/24 is subnetted, 1 subnets

D       22.22.22.0 [90/557056] via 100.1.12.2, 00:12:41, FastEthernet0/1

                   [90/187392] via 10.1.12.2, 00:12:41, FastEthernet0/0

Per-Destination:

R1#sh ip cef exact-route 1.1.1.1 2.2.2.2

1.1.1.1 -> 2.2.2.2 => IP adj out of FastEthernet0/0, addr 10.1.12.2      (1)

R1#sh ip cef exact-route 1.1.1.1 2.2.2.2

1.1.1.1 -> 2.2.2.2 => IP adj out of FastEthernet0/0, addr 10.1.12.2      (2)

"           "           "           "           "           "

R1#sh ip cef exact-route 1.1.1.1 2.2.2.2

1.1.1.1 -> 2.2.2.2 => IP adj out of FastEthernet0/0, addr 10.1.12.2     (9)

R1#sh ip cef exact-route 1.1.1.1 2.2.2.2

1.1.1.1 -> 2.2.2.2 => IP adj out of FastEthernet0/0, addr 10.1.12.2     (10)

R1#sh ip cef exact-route 1.1.1.1 2.2.2.2

1.1.1.1 -> 2.2.2.2 => IP adj out of FastEthernet0/0, addr 10.1.12.2     (11)

Per-Packet:

R1#sh ip cef exact-route 1.1.1.1 2.2.2.2

1.1.1.1 -> 2.2.2.2 => IP adj out of FastEthernet0/0, addr 10.1.12.2      (1)

R1#sh ip cef exact-route 1.1.1.1 2.2.2.2

1.1.1.1 -> 2.2.2.2 => IP adj out of FastEthernet0/0, addr 10.1.12.2       (2)

"           "           "           "           "           "

R1#sh ip cef exact-route 1.1.1.1 2.2.2.2

1.1.1.1 -> 2.2.2.2 => IP adj out of FastEthernet0/0, addr 10.1.12.2      (9)

R1#sh ip cef exact-route 1.1.1.1 2.2.2.2

1.1.1.1 -> 2.2.2.2 => IP adj out of FastEthernet0/1, addr 100.1.12.2     (10)

R1#sh ip cef exact-route 1.1.1.1 2.2.2.2

1.1.1.1 -> 2.2.2.2 => IP adj out of FastEthernet0/0, addr 10.1.12.2 (11)

res

Paul

Please don't forget to rate this post if it has been helpful.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I believe CEF is deterministic for the same SRC/DST pair. Try different pairs and see if the both interfaces are selected.

Paul

I am not clear what you believe this test demonstrates, but to me it demonstrates the expected behavior of CEF load sharing. When you are in per destination (actually per flow) sharing mode the same source destination pair will always take the same path when multiple paths to the destination are in the routing table. And when you are in per packet sharing mode the traffic will sometimes use one path and sometimes use the other path.

Given the metrics reported (557056 and  187392)  I am guessing that you used a variance of at least 3. And I believe that the traffic distribution will put 3 packets on the more attractive path for every 1 packet it puts on the less attractive path.

What would be interesting would be to do what Joseph is suggesting. Look for the path selected for source 1.1.1.1 to other destinations in 2.2.2.0 and look for other sources going to 2.2.2.2. I believe that you will find that some of them take the more expensive path.

HTH

Rick

HTH

Rick

Please excuse my ignorance, but I am having trouble copying and pasting my topology table for you to see as requested. Is there a way to do this??

Thanks again for the input everyone!

Michael

I am not sure what the difficulty comes from and so it is difficult to give you the solution. In general copy and paste of this kind of thing should be fairly simple. In your terminal emulator session you issue the command show ip eigrp topology. Then you highlight the appropriate text and copy. (the mechanics of which key strokes do copy may vary depending on which terminal emulator you are using). Then in the response window of the forum you do a paste (again the mechanics of which key strokes may vary depending on the browser that you are using)

I have sometimes had difficulty with cut and paste when the output spanned several pages/screens and in that case I generally issue the command, get the first screen of output, do the copy and paste, get the second screen of output, do the copy and paste, etc.

If you can identify the source of your difficulty then perhaps we can give better advice about how to solve it.

HTH

Rick

HTH

Rick