LogoفارسیFA

Hands-On Lab: Configuring GRE Point-to-Point Tunnels

This hands-on lab configures a GRE tunnel between two routers across an intermediate transit network, allowing routing protocols and multicast traffic to pass between sites even when the underlying transport network would not normally support them directly.

GRE Tunnel ConfigurationTunnel Source and DestinationVirtual Interface

~3 min read · Updated Sep 12, 2026

Lab Objective

Configure a GRE tunnel between two routers separated by an intermediate router, assign IP addresses to the tunnel interfaces, and verify traffic can pass through the tunnel across the transit network.

Lab Purpose

A GRE tunnel creates a virtual point-to-point link across an existing IP network, commonly used to carry traffic (including routing protocol updates or multicast) across a transit network that would not otherwise support it directly, such as the public internet.

Lab Topology

R1 ---- Gi0/0 ---- ISP ---- Gi0/0 ---- R3
192.168.1.1/30    (transit)    192.168.1.2/30

R1's transit-facing address: 192.168.1.1/30
R3's transit-facing address: 192.168.1.2/30
(ISP router simply routes between these two
addresses and requires no tunnel awareness)

GRE Tunnel0 on R1: 172.16.99.1/30
GRE Tunnel0 on R3: 172.16.99.2/30

Task 1: Configure Transit Connectivity

Configure R1 and R3 with their transit-facing addresses, and ensure the intermediate ISP router provides basic IP reachability between them (a static route or simple IGP is sufficient).

Task 2: Create the GRE Tunnel Interfaces

On both R1 and R3, create a Tunnel0 interface, specifying the tunnel source and destination as each router's transit-facing address.

Task 3: Assign Tunnel IP Addresses

Assign the addresses shown in the topology to each tunnel interface.

Task 4: Verify the Tunnel Is Up

Confirm the tunnel interface shows as up/up on both routers.

Task 5: Verify Traffic Passes Through the Tunnel

Ping across the tunnel and confirm the traffic is actually encapsulated in GRE as it crosses the transit network.

Solution and Verification

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip address 192.168.1.1 255.255.255.252
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# interface tunnel0
R1(config-if)# tunnel source 192.168.1.1
R1(config-if)# tunnel destination 192.168.1.2
R1(config-if)# ip address 172.16.99.1 255.255.255.252

R3(config)# interface gigabitethernet0/0
R3(config-if)# ip address 192.168.1.2 255.255.255.252
R3(config-if)# no shutdown
R3(config-if)# exit
R3(config)# interface tunnel0
R3(config-if)# tunnel source 192.168.1.2
R3(config-if)# tunnel destination 192.168.1.1
R3(config-if)# ip address 172.16.99.2 255.255.255.252

R1# show interfaces tunnel0

Tunnel0 is up, line protocol is up
  Tunnel source 192.168.1.1, destination 192.168.1.2
  Tunnel protocol/transport GRE/IP

R1# ping 172.16.99.2

!!!!!
Success rate is 100 percent (5/5)

R1# show ip route

172.16.99.0/30 is directly connected, Tunnel0
-- The tunnel interface behaves exactly like
-- any other directly connected point-to-point
-- link from a routing perspective, even
-- though the actual traffic is being carried
-- as regular IP packets through the ISP
-- router in between

Key Takeaway

A GRE tunnel creates a logical point-to-point interface layered on top of ordinary IP connectivity, meaning any protocol that can run over a normal interface — including routing protocols like OSPF or EIGRP — can also run directly across the tunnel, treating the entire transit network as a single invisible hop.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

Continue

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

Continue

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

Continue

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

Continue

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

Continue

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

Continue
Previous ArticleNext Article