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:
ROUTER-B#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#
Notes:
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 1436 on 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.
Loading...
Be First To Comment
Related Post
Leave Your Comments Below