Networking

Cisco administration 101: Configure GRE tunnels

Using generic routing encapsulation (GRE) tunnels on Cisco routers can come in handy with Cisco router administration, and configuring GRE tunnels is relatively easy. David Davis has the details in this edition of Cisco Routers and Switches.

Originally developed by Cisco, generic routing encapsulation (GRE) is now a standard, defined in RFC 1701, RFC 1702, and RFC 2784. GRE is a tunneling protocol used to transport packets from one network through another network.

If this sounds like a virtual private network (VPN) to you, that's because it theoretically is: Technically, a GRE tunnel is a type of a VPN—but it isn't a secure tunneling method. However, you can encrypt GRE with an encryption protocol such as IPSec to form a secure VPN.

In fact, the point-to-point tunneling protocol (PPTP) actually uses GRE to create VPN tunnels. For example, if you configure Microsoft VPN tunnels, by default, you use PPTP, which uses GRE.

Why would I use GRE?

Why would you tunnel traffic using GRE? Here are some of the reasons:

  • You need to encrypt multicast traffic. GRE tunnels can carry multicast packets—just like real network interfaces—as opposed to using IPSec by itself, which can't encrypt multicast traffic. Some examples of multicast traffic are OSPF, EIGRP, and RIPV2. Also, a number of video, VoIP, and streaming music applications use multicast.
  • You have a protocol that isn't routable, such as NetBIOS or non-IP traffic over an IP network. For example, you could use GRE to tunnel IPX or AppleTalk through an IP network.
  • You need to connect two similar networks connected by a different network with different IP addressing.

How do I configure GRE tunnels?

Configuring GRE tunnels on Cisco routers is relatively easy—all it takes is a few simple commands. Here's an example of a simple configuration:

Router A:

interface Ethernet0/1
ip address 10.2.2.1 255.255.255.0

interface Serial0/0
ip address 192.168.4.1 255.255.255.0

interface Tunnel0
ip address 1.1.1.2 255.255.255.0
tunnel source Serial0/0
tunnel destination 192.168.4.2

Router B:

interface FastEthernet0/1
ip address 10.1.1.1 255.255.255.0

interface Serial0/0
ip address 192.168.4.2 255.255.255.0

interface Tunnel0
ip address 1.1.1.1 255.255.255.0
tunnel source Serial0/0
tunnel destination 192.168.4.1

In this example, the two routers each have a virtual interface—the tunnel interface. This interface is its own network, just like a point-to-point T1 circuit would be. The traffic going over the tunnel network is tunneling through the serial network.

To each of the routers, it appears that it has two paths to the remote—the serial interface and the tunnel interface (running through the tunnel). This tunnel could then transmit unroutable traffic such as NetBIOS or AppleTalk. If it's going through the Internet, you could use IPSec to encrypt it.

As you can see in the output below, the tunnel interface on Router B is an interface like any other:

RouterB# sh ip int brie
Interface   IP-Address   OK?  Method  Status                 Protocol
Ethernet0   10.1.1.1     YES  manual  up                     down
Serial0     192.168.4.2  YES  manual  up                     up
Serial1     unassigned   YES  unset   administratively down  down
Tunnel0     1.1.1.1      YES  manual  up                     up
RouterB#

Troubleshooting GRE tunnels

Because GRE takes one packet and encapsulates it in another packet, you might run into a situation where the packet you're sending is larger than your interface allows. The solution to this issue is to configure ip tcp adjust-mss 1436on the tunnel interface.

While GRE doesn't provide encryption, you can enable a key on each side of the tunnel using the tunnel key command. This is like a simple clear-text password with no encryption.

Because GRE tunnels are stateless, it's possible for one side of the tunnel to go down while the other side remains up. The solution to this problem is to enable keepalive packets on each side of the tunnel. By doing this, each side of the tunnel periodically sends a keepalive to the other side. If one side doesn't receive a keepalive in the specified time, the tunnels go down on each side.

For more information, check out Cisco's list of Generic Routing Encapsulation (GRE) resources.

Miss a column?

Check out the Cisco Routers and Switches Archive, and catch up on David Davis' most recent columns.

Want to learn more about router and switch management? Automatically sign up for our free Cisco Routers and Switches newsletter, delivered each Friday!

David Davis has worked in the IT industry for 12 years and holds several certifications, including CCIE, MCSE+I, CISSP, CCNA, CCDA, and CCNP. He currently manages a group of systems/network administrators for a privately owned retail company and performs networking/systems consulting on a part-time basis.

8 comments
MisterMike45
MisterMike45

Hey, quick question. Are there any caveats about using the HSRP VIP's (Virtual IP's) on the source and destination addresses on the GRE Tunnel interfaces?

njorogengugi
njorogengugi

Very informative.possible to have full examples of configuring ipsec tunnels

der_nodle
der_nodle

Hi, I de like de know how to configure a gre tunnel on a router and tow radundante routers using HSRP. thanks

aadeshjoshi
aadeshjoshi

This article is wonderful, Now i know what is GRE tunnel, how it work and how to configure it on router. Thanks David, Keep writing such articles. Regards Adesh

acastillo
acastillo

Hi!...anybody here knows if I can use a GRE tunnel from one CE to another between 2 different AS to run Multicast (MVPN)???

DemRoyer
DemRoyer

I've been using this method for years in order to tunnel IPX traffic over the Internet, something my Cisco vendor originally tried to tell me couldn't be done. By establishing GRE tunnels, and then encrypting them with IPSec, I can have all of my remote Novell 4.x servers securely communicating over the Internet using their native IPX protocol. This functionality allowed us to get rid of our expensive point-to-point WAN links and implement a much more cost effective Internet VPN-based WAN. As for why we're still running Novell 4.x servers all over the place, that is a topic for another post...

EEnglish34
EEnglish34

Very nice article. Keep up the good work.

thuongctran
thuongctran

It is marvelous!! I got a job because of this question since I read this article by accident a few days before the job interview. Lately, I found out the interviewer had read it. It was great!!! Thanks for good tip