The GRE tunnel: a packet inside another packet
Every mechanism has a step-by-step animation, the configuration explained line by line and exam notes. Where a parameter changes the outcome, there is a simulator where you change it yourself.
TL;DR
A GRE tunnel puts an entire packet inside another IP packet, with protocol 47 and 4 bytes of header, to carry it across a network that would not route it: private addresses over the Internet, multicast, IPv6 or MPLS over a core that does not understand them. The result is a virtual interface, Tunnel0, that you route on like a point-to-point link — with OSPF, EIGRP, multicast, anything. The tunnel is up based on local conditions, not a negotiation: source up, destination routable (not through the tunnel!), optionally keepalives received. The costs: 24 bytes (ip mtu 1476, tcp adjust-mss 1436), default metrics that lie (BW 100 Kbit) and zero security, hence GRE over IPsec. With mGRE and NHRP, the same tunnel becomes DMVPN. Most incidents come from MTU, from recursive routing and from NAT along the path.
How to read the notes: red = critical for the exam, green = theory, blue = numbers, yellow = pitfalls, cyan = differences between platforms and standards. In the animations, the configuration lines used at the current step are highlighted automatically; the ← → arrows change the step when the animation is selected.
The analogy, in short
Think of the car crossing the sea on the shuttle train: the car (your packet) cannot drive on rails (the Internet only routes public addresses), so it boards a wagon (the GRE header), the train (the outer IP header) carries it to the other terminal, and there it drives off and continues its journey. The driver never saw the rails; the train never opened the car doors. The wagon has a size limit (MTU), the terminal sends empty test wagons (keepalive), and the armored wagon (IPsec) hides what is inside.
The model holds up to §9. From §10 onward (VRFs, MPLS and L2 in GRE, ERSPAN), it breaks; see the full analogy and its limits in §14.