You are familiar with the fundamental operation of a virtual private network (VPN), and the concept of tunneling by now. The device at one end of a VPN tunnel takes an IP packet, encrypts it making it unreadable, and then sends the encrypted packet after encapsulating it in a new IP header. The new IP header is needed to route the packet in the unsecured network as the original IP header is now encrypted and unreadable and hence cannot be used for routing.
In this section, we cover configuration for the tunneling part of VPN operation, leaving out the encryption part. This is all you need for your CCNA Routing and Switching exam. The configuration in this section involves the creation of a tunnel, demonstrating how routers encapsulate the original IP packet inside another IP packet. The encapsulated IP packet is not encrypted in the configuration we show in this chapter. This lets us present the basic tunneling configuration yet leaving the more specialized security configuration to another more relevant Cisco certification in the security track.
Generic Routing Encapsulation (GRE) is a method to tunnel IP packets between two end points. GRE is an Internet Engineering Task Force (IETF) standard defined in RFC 2784. GRE encapsulates the original IP packet with a new IP header also appending an additional GRE header.
A GRE tunnel creates the illusion of a point-to-point link between two routers that are otherwise not directly connected to each other. The routers at the two ends of a GRE tunnel use virtual interfaces, known as tunnel interfaces, in place of serial interfaces used by directly connected routers. The virtual interfaces on routers at the two ends of a GRE tunnel are configured with IP addresses from the same subnet.
GRE Tunnel Configuration
Because GRE tunnels work pretty much like a serial link between two routers connected directly across a leased line, it is logical to review configuration for directly connected routers first. We will then build on this basic configuration to create a fully fledged GRE configuration providing more or less the same features.
Figure 12-3 Serial Link
The network shown in Figure 13-3 above is how wide-area networks can be built using leased lines to connect remote sites. This sort of infrastructure is completely private and there is usually not a need to encrypt traffic flowing between sites across leased lines. Also, the network is wholly owned by a single enterprise allowing the use of private IP addresses even on WAN links.
Referring to Figure 12-3, the two routers are directly connected to each other over a leased line. There are a number of encapsulation options but HDLC is being used which is also the default serial encapsulation on Cisco routers. There is a /30 subnet in use on the serial link as indicated and the two end points are assigned legitimate IP addresses from the subnet. The choice of /30 subnets provides for only two valid IP addresses and that’s all what we need here.
The LAN side of router R1 is using the subnet 10.10.1.0/24 with 10.10.1.1 assigned to the LAN interface that acts as the default gateway for local hosts. Similarly, the LAN side of router R2 is using the subnet 10.10.2.0/24 with 10.10.2.1 assigned to the LAN interface that acts as the default gateway for local hosts. The router R1 already knows about its directly connected networks but it must also learn about the remote subnet 10.10.2.0/24 via a dynamic routing protocol or static configuration. We have chosen static routing but we could also have used RIP, EIGRP, or OSPF. If you choose to use a dynamic routing protocol, it must be enabled on the serial interface. The same applies to router R2 as well and the configuration shown below should help clarify these concepts. We don’t have to configure encapsulation on serial interfaces as HDLC is already the default encapsulation on serial interfaces.
The configuration on R1 looks like:
R1(config-if)#ip address 10.10.1.1 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#interface Serial0/0
R1(config-if)#ip address 192.168.12.1 255.255.255.252
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#ip route 10.10.2.0 255.255.255.0 192.168.12.2
And the configuration for R2 goes here:
R2(config-if)#ip address 10.10.2.1 255.255.255.0
R2(config-if)#no shutdown
R2(config)#interface Serial0/0
R2(config-if)#ip address 192.168.12.2 255.255.255.252
R2(config-if)#no shutdown
R2(config-if)#exit
R2(config)#ip route 10.10.1.0 255.255.255.0 192.168.12.1
At this point, hosts on Site A can ping hosts on site B, and vice versa.
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 don’t 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-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-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:
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. Let’s 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.