GET VPN: encryption without tunnels, with one key for the whole group
Every mechanism has a step-by-step animation, the configuration explained line by line and exam notes. Where a parameter changes the outcome, you get a simulator where you change it yourself.
TL;DR
GET VPN encrypts the traffic of a private WAN without building tunnels: a Key Server distributes to all site routers (Group Members) the same traffic key (TEK) and the same policy, via GDOI on UDP 848, and each GM encrypts in tunnel mode with header preservation — the outer header copies the original addresses, so MPLS routes, QoS classifies and multicast replicates exactly as before. Keys change through rekeys signed by the KS, multicast or unicast; anti-replay is time-based (TBAR), because on a group SA the counter makes no sense; the KS is doubled through COOP. The price: addresses must be routable across the whole WAN and nobody is allowed to NAT them, so GET VPN is not for the Internet.
How to read the notes: red = critical for the exam, green = theory, blue = numbers, yellow = pitfalls, cyan = differences between the GDOI standard and the Cisco implementation, and between platforms. In the animations, the configuration lines used at the current step are highlighted automatically; the ← → arrows change the step when the animation is focused.
The analogy, in short
Think of a retail chain whose stores send each other documents through the company's internal courier, in envelopes sealed with a shared cipher, received by all of them from the key custodian at headquarters. The address on the envelope is the real one, so the courier changes nothing; the custodian sends out a signed circular with the new cipher from time to time; every envelope carries a stamp with the time from the custodian's clock, so nobody can resend an old envelope.
The model holds up to §9. From §10 onward (PKI, Suite B, the integrations and troubleshooting), it breaks; see the full analogy and its limits in §14.