Short answer: A basic point-to-point GRE tunnel needs a logical tunnel interface, a local tunnel source and a remote tunnel destination; the destination must already be reachable through the transport network.[2]
The tunnel-interface IP address belongs to the logical link, while the source and destination identify the outer transport endpoints.[2] GRE encapsulates packets; it does not itself provide encryption.[1][2]
The interview question is simple: “What are the three main elements of a GRE tunnel, and how does a packet cross it?” The useful answer separates the underlay, which delivers the encapsulated packet, from the overlay, which carries the original traffic.
GRE tunnel source vs destination vs interface address
Scope: a numbered, point-to-point GRE-over-IPv4 tunnel on Cisco IOS/IOS XE, not multipoint GRE or a complete DMVPN deployment. Cisco's example uses a logical tunnel interface with an IP address, a source interface and a destination address.[2]
| Element | Meaning | Fictional Router A example |
|---|---|---|
| Tunnel interface | Logical interface used for the encapsulated traffic.[2] | interface Tunnel10 |
| Tunnel-interface IP | Address on the logical point-to-point link.[2] | 10.255.0.1/30 |
| Tunnel source | Local address or source interface used for the outer packet.[2] | 192.0.2.10 |
| Tunnel destination | Remote endpoint address used for the outer packet.[2] | 198.51.100.20 |
Do not enter the remote inside tunnel address as the tunnel destination in this design. In the example, 10.255.0.2 is the overlay neighbor, while 198.51.100.20 is the destination that the underlay must deliver packets to.
The source may be a loopback rather than a WAN interface; Cisco's example uses loopbacks.[2] Either way, check reachability using the actual configured source, not an unrelated interface address.
Packet flow: inner packet, GRE header, outer IP header
RFC 2784 describes a delivery header around a GRE header and a payload packet; GRE carried directly over IPv4 uses IP protocol 47, not TCP or UDP port 47.[1]
This is an original, fictional packet walk, not a captured production trace:
LAN A host: 10.10.10.10 --> LAN B host: 10.20.20.20
Router A selects Tunnel10 for the remote LAN.
Across the transport network:
Outer IPv4: 192.0.2.10 --> 198.51.100.20, protocol 47
GRE header: payload protocol identifies IPv4
Inner IPv4: 10.10.10.10 --> 10.20.20.20
Router B removes the outer delivery and GRE headers.
Router B forwards the inner packet toward LAN B.
Return traffic needs its own valid reverse path.
After decapsulation, the inner IPv4 destination determines forwarding, and the payload TTL is decremented as specified in RFC 2784.[1] The WAN-facing packet and the LAN-facing packet therefore answer different troubleshooting questions: one proves transport between endpoints; the other proves delivery for the application.
Minimal two-router configuration example
The following is an illustrative IOS/IOS XE-style lab template, not an executed router lab or a production-ready security configuration. Confirm syntax and interface names for your release. The tunnel source/destination structure follows Cisco's documented configuration model.[2]
Assumptions for this invented lab:
- Router A owns
192.0.2.10; its directly reachable transport next hop is192.0.2.1. - Router B owns
198.51.100.20; its directly reachable transport next hop is198.51.100.1. - A lab transport router provides routing between those documentation-address networks.
- The LAN interfaces, host gateways and return paths already exist.
- This example deliberately uses plain GRE only inside an isolated lab.
Router A:
ip route 198.51.100.20 255.255.255.255 192.0.2.1
!
interface Tunnel10
ip address 10.255.0.1 255.255.255.252
tunnel source 192.0.2.10
tunnel destination 198.51.100.20
tunnel mode gre ip
no shutdown
!
ip route 10.20.20.0 255.255.255.0 10.255.0.2
Router B:
ip route 192.0.2.10 255.255.255.255 198.51.100.1
!
interface Tunnel10
ip address 10.255.0.2 255.255.255.252
tunnel source 198.51.100.20
tunnel destination 192.0.2.10
tunnel mode gre ip
no shutdown
!
ip route 10.10.10.0 255.255.255.0 10.255.0.1
The design intentionally separates two lookups: the remote endpoint resolves through the transport next hop, while the remote LAN resolves through the overlay peer. As a troubleshooting rule, never let the route needed to reach the outer endpoint depend on the same tunnel it is supposed to support. Check for recursive endpoint routing after any routing-policy change.
Why GRE up/up does not prove the remote end works
Basic GRE is stateless: without an additional liveness mechanism, the local interface can remain up even when the remote endpoint is unreachable or not configured.[2] Cisco documents local source validity and destination routability as conditions for the ordinary tunnel interface to remain up.[2]
That makes an interface-status check necessary but insufficient. My suggested acceptance sequence is:
- Verify the route to the outer destination, using the correct routing context.
- Test the remote outer address with the configured local source, where ICMP is permitted.
- Verify GRE traffic is allowed between the approved endpoints.
- Test the remote tunnel-interface address.
- Test a host-to-host flow in both directions.
- Test a larger packet or real application transfer, not only a small ping.
A successful outer ping tests ICMP delivery; it does not demonstrate that GRE protocol 47 passes the same path.[1]
What about GRE keepalives?
Cisco GRE keepalives can detect failures that ordinary local interface state misses, but the documented mechanism is supported on point-to-point GRE, not multipoint GRE.[2] The two ends' keepalive timers are independent; configuring keepalives on only one end does not make the other end detect failure the same way.[2]
Do not add keepalives blindly to an encrypted design: Cisco documents incompatibilities with IPsec tunnel protection, as well as VRF and reverse-path-filtering caveats.[2] Choose and test a supported liveness method for the specific platform and design rather than copying one line from a plain-GRE lab.
GRE troubleshooting checklist
These are suggested checks, not diagnostic outputs from a live device. Cisco IOS/IOS XE-style verification commands include:
show interfaces Tunnel10
show ip interface brief
show running-config interface Tunnel10
show ip route 198.51.100.20
show ip route 10.20.20.20
ping 198.51.100.20 source 192.0.2.10
ping 10.255.0.2 source 10.255.0.1
| Symptom | First checks I recommend |
|---|---|
| Tunnel interface down | Administrative state, local source validity and route to the outer destination |
| Tunnel up, overlay ping fails | Mirrored endpoints, protocol-47 policy, remote configuration and reverse path |
| Tunnel peer responds, remote LAN does not | LAN routes, host gateways, endpoint firewall policy and return route |
| Failure after routing changes | Whether the endpoint route now resolves through Tunnel10 |
| Small packets work, larger transfers fail | Tunnel/path MTU, fragmentation behavior and ICMP feedback |
GRE adds encapsulation headers, and RFC 2784 explicitly discusses fragmentation and path-MTU feedback problems.[1] Do not treat one MTU value as universal: determine the actual encapsulation stack and path constraints, especially when IPsec is also present.
Common interview pitfalls
- “GRE uses port 47.” It uses IPv4 protocol number 47; a TCP/UDP port rule is not equivalent.[1]
- “A GRE tunnel is automatically encrypted.” Encapsulation and encryption are separate; IPsec can protect the GRE packets.[1][2]
- “Up/up means the peer is healthy.” Plain GRE state alone does not establish remote liveness.[2]
- “The tunnel destination is the remote Tunnel interface IP.” In this numbered example, the destination is the remote outer endpoint, not its overlay address.[2]
- “Adding keepalives fixes every design.” Supported tunnel type, encryption integration and routing context matter.[2]
A concise interview answer
“A point-to-point GRE tunnel uses a logical tunnel interface, a local source and a remote destination; the transport network must reach that destination independently.[2]
Traffic selected for the tunnel is wrapped in GRE and an outer IP header, then decapsulated at the far end.[1]
GRE over IPv4 uses protocol 47 and does not itself encrypt the traffic.[1][2]
I verify underlay reachability, overlay routing and application delivery separately, because a plain GRE interface can be up while the far end is unavailable.[2]”
Related reading
- IPsec Phase 1 vs Phase 2: SAs, crypto maps and IKEv2
- Administrative distance vs metric vs longest prefix match
Summary and practice task
Remember the three identities: local outer source, remote outer destination and logical tunnel interface. For this lab, draw the inner and outer packet headers before entering any configuration. Then predict what should happen if the far-end router stops forwarding while the local transport route stays installed.
Preparing for a network engineering interview? Explain that failure case aloud, then build an isolated lab and record which checks prove endpoint reachability, tunnel forwarding and actual application delivery.
Post a Comment