Generic Routing Encapsulation (GRE) tunnels work just like a serial link, with virtual tunnel

interfaces replacing physical serial interfaces. The routers still use physical serial interfaces to
connect to the physical network which may be a single leased line directly connecting two
routers. More commonly, the two routers would rather be connected over a private WAN service
provider or the public Internet. The GRE tunnel would operate as an overlay network but behave
like a point-to-point serial link in many ways. The IP addresses on the two tunnel end point

interfaces would be configured from a single subnet, as if they were directly connected.

Figure 12-4 GRE Tunnel Interfaces

We summarize GRE tunnel configuration steps here:

Step 1: Create tunnel interfaces on R1 and R2 using the interface tunnel number
command. The tunnel interface number is locally significant only and can be just any
permissible number. We choose the number 0 on both sides only for the sake of
consistency and predictability. The numbers otherwise dont have to match.

Step 2: Choose a subnet to be used on tunnel interfaces and assign an IP address from the
subnet to both end points. We have chosen a /30 subnet as this scheme results in the most
efficient address assignment.

Step 3: Configure the source IP address of the tunnel interface using the tunnel source
interface or the tunnel source ip-address command. The source interface or IP address
 must be the one that connects the router to the public part of the network. Please note that
we are using private IP addresses on the physical serial interfaces on the two routers
because we are working in a test environment. In a real deployment, the IP addresses on
the two serial interfaces would typically be public IP addresses. If you refer to the
interface in the command tunnel source, the IP address configured on the listed interface
is used. The tunnel source on one end point must match the tunnel destination at the other
end point and vice versa.

Step 4: Configure the destination IP address of the tunnel interface. The destination IP
address must be from the public part of the network though we are using private IP
addresses even for the public part of the network in our test environment as already
explained.

Step 5: Configure the routers to use the tunnel interfaces to reach remote subnets. We
may use either static routing or a dynamic routing protocol enabled on tunnel interfaces
to achieve that. In our test environment we opt for static routing as the scenario is simple
and the focus here is not on dynamic routing protocols.

The following configuration for R1 is in addition to the configuration already shown. We will
configure a virtual tunnel interface and then configure a new static route to make sure outgoing
packets to the remote subnet are diverted to the tunnel interface rather than the serial interface.

R1(config)#interface Tunnel 0
R1(config-if)#ip address 10.10.12.1 255.255.255.252
R1(config-if)#tunnel source Serial0/0
R1(config-if)#tunnel destination 192.168.12.2
R1(config-if)#no shutdown
R1(config)#no ip route 10.10.2.0 255.255.255.0 192.168.12.2
R1(config)#ip route 10.10.2.0 255.255.255.0 10.10.12.2

And here goes the configuration for R2:

R2(config)#interface Tunnel 0
R2(config-if)#ip address 10.10.12.2 255.255.255.252
R2(config-if)#tunnel source Serial0/0
R2(config-if)#tunnel destination 192.168.12.1
R2(config-if)#no shutdown
R2(config)#ip route 10.10.1.0 255.255.255.0 192.168.12.1
R2(config)#ip route 10.10.1.0 255.255.255.0 10.10.12.1

The routers will start using the tunnel interfaces to route packets to the remote subnets
10.10.1.0/24 and 10.10.2.0/24.

GRE Tunnel Verification

The tunnel configuration is complete but we need to test whether it can pass user traffic or not.
There are some invaluable show commands that can be used for tunnel verification. A good
starting point for GRE tunnel verification is the good old show ip interface brief command. If
the tunnel interface is in an up/up state, the tunnel is successfully established.

R1#show ip interface brief

Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.10.1.1 YES manual up up
Serial0/0 192.168.12.1 YES manual up up
Tunnel0 10.10.12.1 YES manual up up

R2#show ip interface brief

Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.10.2.1 YES manual up up
Serial0/0 192.168.12.2 YES manual up up
Tunnel0 10.10.12.2 YES manual up up

The show interfaces tunnel command provides a lot of useful information including interface
status and configuration settings as highlighted in output below:

R1#show interfaces tunnel 0

Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.10.12.1/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 192.168.12.1, destination 192.168.12.2
Tunnel protocol/transport GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled
Tunnel TTL 255
Fast tunneling enabled
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input 00:28:44, output 00:28:44, output hang never
<Some output omitted>

We seem to have a working tunnel interface according to the verification commands used so far.
However, a router will not send any packets over the tunnel until the routing table tells router to
do so. We need to have local routes to remote subnets pointing to the tunnel in order to make the
router send packets over the tunnel. In this example, we are using static routing configuration to
do so. Lets verify if there are any routes pointing to the tunnel interface on R1:
R1#show ip route
<Some output omitted>

192.168.12.0/30 is subnetted, 1 subnets

C 192.168.12.0 is directly connected, Serial0/0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.10.1.0/24 is directly connected, FastEthernet0/0
S 10.10.2.0/24 [1/0] via 10.10.12.2
C 10.10.12.0/30 is directly connected, Tunnel0

We can run a traceroute to verify that traffic passes through the tunnel and find out the path
taken by packets:

R1#traceroute
Protocol [ip]:
Target IP address: 10.10.2.1
Source address: 10.10.1.2
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 10.10.2.1

1 10.10.12.2 0 msec 4 msec 0 msec

2 10.10.2.2 4 msec 4 msec 0 msec

You may have noticed that the traceroute does not list any IP addresses on the serial interfaces
of routers though the traffic physically passes through them. The reason is that the packets sent
by traceroute are encapsulated before being sent from R1 to R2. Any other user packets between
Site A and Site B are also treated in a similar fashion.