cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6228
Views
0
Helpful
2
Replies

Best practices for multiple GRE tunnels in a hub-and-spoke config?

RHITCHCOCK
Level 1
Level 1

I'm currently setting up what will the first site with approximately 5 to follow using carrier ethernet as primary connectivity and DSL/Cable as backup.  All traffic will flow through HQ.  The carrier ethernet will be 10Mbit bi-directional, the DSL/Cable will be typical low speeds like 3-5Mbit down, 1Mbit up.

At HQ I have a 2951 w/sec and 3 physical interfaces.

At new site (Site A) I have a 1941 w/sec and 4 physical interfaces.  I will probably have the same or similar at the sites to follow.

I'll be doing a VPN over the carrier ethernet to each site, and an additional VPN over DSL/Cable to each site.  I plan to build gre tunnels with keepalives over both.  I'll be using EIGRP for route discoveries over the gre tunnels.  I can favor the routes over carrier ethernet using the bandwidth setting on the gre interfaces.

I have read that it is best practice to use loopback interfaces to terminate the gre tunnels.  If that is the case:

Should I use a separate loopback interface to terminate each gre tunnel?

That would not be a problem at Site A - there would be two loopback interfaces, one for the tunnel over carrier ethernet, one for the tunnel over DSL/Cable.  But at HQ there would initially be two, then as I added sites, four, six, then eventually twelve loopback interfaces.  I can see this being a concern from a management standpoint, but it it from a performance standpoint?  If so:

Should I terminate multiple gre tunnels on one loopback interface?

So at HQ I would have two loopback interfaces, each with six gre tunnels terminating into them eventually.  Less to keep track of, but will there be a performance hit using this method?  Obviously I'm not dealing with huge amounts of data, since all my carrier ethernet links are 10Mbit.

Basically, my question is, what's better: a larger number of loopback interfaces?  Or a larger number of gre tunnels terminating on the same interface?

I've done some searching, but so far haven't found an answer on which would be a better approach.  Thanks!

1 Accepted Solution

Accepted Solutions

Richard Burts
Hall of Fame
Hall of Fame

Robert

DMVPN as suggested by Paolo is a possibility. But GRE tunnels with IPSec running EIGRP is also a realistic possibility, and perhaps preferable if you really want traffic from the spokes to go through the hub. One of the advantages of DMVPN is that it facilitates spoke to spoke direct communication. But if there are reasons why you want spoke to spoke traffic coming through the hub then DMVPN is not such a good choice.

In some environments it may be preferable to use loopback interface addresses to terminate GRE tunnels. In other cases it may be preferable to terminate GRE tunnels on physical interfaces. If you have a router that will have GRE tunnels and there is more than one interface of the router that can get to the tunnel destination then loopback interface addresses are optimal for terminating GRE since it frees you from the potential impact if one of the physical interfaces goes down. If there is only one interface that gets to the tunnel destination then there is little benefit in using loopback interface address to terminate the GRE tunnel.

Another aspect to consider is that one of the most important requirements in implementing GRE tunnels is that the tunnel destination address must be reachable from the source before the tunnel comes up. In cases where the router may have public IP addresses on its outbound interface (which may be the case with your carrier ethernet and DSL) it is easier to accomplish this when using the outbound physical interface then it is with a loopback interface address.

I have implemented GRE tunnels with IPSec running EIGRP over the tunnel multiple times and it works well. I have typically decided not to use tunnel keepalives in this environment. I find that the EIGRP hello process is very effective in determining whether the tunnel is working or not and therefore the tunnel keepalives are a bit redundant.

HTH

Rick

HTH

Rick

View solution in original post

2 Replies 2

paolo bevilacqua
Hall of Fame
Hall of Fame

You best choice is DMVPN, read about it.

Richard Burts
Hall of Fame
Hall of Fame

Robert

DMVPN as suggested by Paolo is a possibility. But GRE tunnels with IPSec running EIGRP is also a realistic possibility, and perhaps preferable if you really want traffic from the spokes to go through the hub. One of the advantages of DMVPN is that it facilitates spoke to spoke direct communication. But if there are reasons why you want spoke to spoke traffic coming through the hub then DMVPN is not such a good choice.

In some environments it may be preferable to use loopback interface addresses to terminate GRE tunnels. In other cases it may be preferable to terminate GRE tunnels on physical interfaces. If you have a router that will have GRE tunnels and there is more than one interface of the router that can get to the tunnel destination then loopback interface addresses are optimal for terminating GRE since it frees you from the potential impact if one of the physical interfaces goes down. If there is only one interface that gets to the tunnel destination then there is little benefit in using loopback interface address to terminate the GRE tunnel.

Another aspect to consider is that one of the most important requirements in implementing GRE tunnels is that the tunnel destination address must be reachable from the source before the tunnel comes up. In cases where the router may have public IP addresses on its outbound interface (which may be the case with your carrier ethernet and DSL) it is easier to accomplish this when using the outbound physical interface then it is with a loopback interface address.

I have implemented GRE tunnels with IPSec running EIGRP over the tunnel multiple times and it works well. I have typically decided not to use tunnel keepalives in this environment. I find that the EIGRP hello process is very effective in determining whether the tunnel is working or not and therefore the tunnel keepalives are a bit redundant.

HTH

Rick

HTH

Rick
Review Cisco Networking for a $25 gift card