cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5643
Views
5
Helpful
10
Replies

Load Balance Multiple DMVPN tunnels

srroeder
Level 1
Level 1

Trying to load balance 2 DMVPN tunnels from one remote router back to our headquarters site.   The remote router is a 2811 running 12.4.24.  It has two DSL connections and I have built two DMVPN tunnels back to my headquarters site with each tunnel going to a seperate router.  I am running EIGRP across the WAN and LAN.   Please see attached drawing.

When I set two equal default routes and simply let EIGRP do the balancing the router favors the 180.7.250.1 route and very little traffic goes across the 180.7.249.1 route.

The reason I am trying this is because this site is in kind of a remote area and I can only get a 500KB up and 1.5MB down DSL circuit.  So to boost performance a little I wanted to try running two circuits.

I am open to any suggestions or hints on how to get a little more bandwidth to this site.

Thanks in advance.DMVPN load balance.bmp

1 Accepted Solution

Accepted Solutions

EIGRP metrics are determined by Delay, Bandwidth, Reliability and Load. You have the same router, same tunnel interface. All interfaces involved in eigrp need to match exactly the same if you want to load balance across it. See how the composite metrics are different below. If you can make them match your traffic will load balance.

View solution in original post

10 Replies 10

Lei Tian
Cisco Employee
Cisco Employee

Hi,

DMVPN reply on routing for load balancing; is your hub site advertising out default route only? On your spoke router, you can configure offset-list under eigrp process to manipulate eigrp metric per prefix base. That way you can load balance the traffic leaving the spoke site, but you cannot control the return path on spoke router.

HTH,

Lei Tian

b.schlegel
Level 1
Level 1

I've done this in the past by using bandwidth statements on your branch tunnel interefaces and adjusting the delay on the lan side of the router.  I'd start by just using eigrp again and then issuing a "sh ip route" on your spoke routers.  Does each spoke router just want to go over it's own tunnel or does it pass over to the local network from one of the spokes?

Thank you for your quick response and suggestions.

Attached here are the configs for the 3 devices.  The spoke with two VPN tunnels and the two hub routers.

On the spoke I think you have a different eigrp group then you do on the two hubs.  I'd try dropping the static routes and see if it's load balancing on the spoke.  You should see something like this sh ip route 180.7.3.161

Heres the results from one of my routers running a GRE tunnel and using eigrp

Test#               sh ip route 172.22.9.1

Routing entry for 172.22.9.0/24
  Known via "eigrp 100", distance 90, metric 297246976, type internal
  Redistributing via eigrp 100
  Last update from 10.2.13.1 on Tunnel2, 06:30:32 ago
  Routing Descriptor Blocks:
    10.2.13.1, from 10.2.13.1, 06:30:32 ago, via Tunnel2
      Route metric is 297246976, traffic share count is 1
      Total delay is 500100 microseconds, minimum bandwidth is 9 Kbit
      Reliability 255/255, minimum MTU 1006 bytes
      Loading 56/255, Hops 1
  * 10.1.13.1, from 10.1.13.1, 06:30:32 ago, via Tunnel1
      Route metric is 297246976, traffic share count is 1
      Total delay is 500100 microseconds, minimum bandwidth is 9 Kbit
      Reliability 255/255, minimum MTU 1006 bytes
      Loading 82/255, Hops 1

Test#

both tunnels have equal metrics and are load balancing

Yes,  the EIGRP group on the spoke is a mis-type on my part.  It should be 180 and I checked that it is 180 in the current running config.  having said that I will try dropping the static routes and see what happens

Thanks for the help everyone,  still not working right.  Here is what I see when I remove all static routes.  180.7.2.220 is a FTP server , inside my network.

spoke#sho ip route 180.7.2.220
Routing entry for 180.7.2.0/24
  Known via "eigrp 180", distance 90, metric 2818816, type internal
  Redistributing via eigrp 180
  Last update from 180.7.250.1 on Tunnel0, 07:47:43 ago
  Routing Descriptor Blocks:
  * 180.7.250.1, from 180.7.250.1, 07:47:43 ago, via Tunnel0
      Route metric is 2818816, traffic share count is 1
      Total delay is 10110 microseconds, minimum bandwidth is 1000 Kbit
      Reliability 255/255, minimum MTU 1400 bytes
      Loading 1/255, Hops 2

here is my eigrp config...........

router eigrp 1707
network 170.7.0.0
network 170.7.249.0 0.0.0.255
network 170.7.250.0 0.0.0.255

What are the results of "sh ip ei top all"

spoke#sho ip ei top 180.7.2.0/24
EIGRP-IPv4 Topology Entry for AS(180)/ID(180.7.250.3) for 180.7.2.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2818816
  Descriptor Blocks:
  180.7.250.1 (Tunnel0), from 180.7.250.1, Send flag is 0x0
      Composite metric is (2818816/28416), route is Internal
      Vector metric:
        Minimum bandwidth is 1000 Kbit
        Total delay is 10110 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1400
        Hop count is 2
  180.7.249.1 (Tunnel1), from 180.7.249.1, Send flag is 0x0
      Composite metric is (2819072/28672), route is Internal
      Vector metric:
        Minimum bandwidth is 1000 Kbit
        Total delay is 10120 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1400
        Hop count is 3

EIGRP metrics are determined by Delay, Bandwidth, Reliability and Load. You have the same router, same tunnel interface. All interfaces involved in eigrp need to match exactly the same if you want to load balance across it. See how the composite metrics are different below. If you can make them match your traffic will load balance.

Thank you so much for your help,    yes I see how the two routes differ,   I am going to try some different

scenarios to try and make them equal.

Steve

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: