← Zurück zur Übersicht
Routing

GRE Tunnel

Generic Routing Encapsulation

GRETunnelEncapsulationIP-in-IPOverlayVPNRouting

GRE kapselt beliebige Layer-3-Protokolle in IP-Pakete ein und erzeugt so virtuelle Punkt-zu-Punkt-Verbindungen über IP-Netze. Mit GRE können nicht-routbare Protokolle transportiert, Multicast über Unicast-Netze geleitet oder VPN-Overlay-Netze aufgebaut werden.

GRE Tunnel – IP-in-IP EncapsulationRouter ATunnel-Src: 1.1.1.1Router BTunnel-Dst: 2.2.2.2Internet / IP-UnderlayGRE Tunnel (virtuell)Paket-Struktur im GRE-TunnelOuter IPGRE HdrInner IPOriginal PayloadVorteileMulticast-Routing über UnicastBeliebiges Layer-3-ProtokollEinfach, statelessOverlay-Netze aufbauenNachteileKein Verschlüsselung+20 Byte MTU-OverheadKein eingebauter Auth→ Kombination mit IPsec

Entstehung und Beteiligte

Generic Routing Encapsulation wurde von Cisco-Ingenieuren entwickelt und 1994 in RFC 1701/1702 dokumentiert. RFC 2784 konsolidierte 2000 das Grundformat. GRE ist bewusst ein einfaches Kapselungsprotokoll.

Welches Problem sollte gelöst werden?

Pakete eines Protokolls sollten durch ein anderes IP-Netz transportiert werden, etwa Routingprotokolle oder Multicast zwischen entfernten Standorten. Normale IP-Pakete boten keine zusätzliche Tunnelhülle.

Technische Hürden und Lösungen

GRE verschlüsselt und authentifiziert nicht. Zusätzliche Header verkleinern die nutzbare MTU und können Fragmentierung verursachen. NAT behandelt IP-Protokoll 47 anders als TCP- oder UDP-Ports. Für Vertraulichkeit wird GRE häufig mit IPsec kombiniert.

Standardisierung und Einordnung

Routingverfahren beantworten die Frage, über welchen nächsten Knoten ein Paket sein Ziel erreicht. Ihre Entwicklung ist eng mit dem Wachstum des Internets und großer Unternehmensnetze verbunden. Die schwierigsten Probleme sind Schleifen, langsame Konvergenz, unvollständige Informationen und die Skalierung großer Tabellen. Kein Algorithmus kennt das gesamte reale Netz in Echtzeit; Router arbeiten mit ausgetauschten Zuständen, Regeln und Metriken.

Technik im praktischen Betrieb

Im Betrieb müssen Steuerungsebene und tatsächliche Weiterleitung getrennt geprüft werden. Eine Route kann im Protokoll gelernt, durch eine Richtlinie verworfen oder wegen eines anderen Präfixes nie verwendet werden. Nach Änderungen sind Nachbarschaft, Datenbank, Routingtabelle, Forwarding-Tabelle und Rückweg zu kontrollieren. Schnelle Konvergenz ist nicht automatisch stabil: zu aggressive Timer können kurze Lastspitzen als Leitungsfehler interpretieren. Zusammenfassungen und Filter reduzieren Größe, können aber Detailinformation verbergen.

Warum das Thema heute noch relevant ist

Die Relevanz dieser Verfahren wächst mit der Abhängigkeit von Netzen. Schon eine kleine fehlerhafte Ankündigung kann heute Rechenzentren, Cloudregionen oder Teile des Internets betreffen. Historisch gewachsene Vertrauensmodelle werden deshalb durch Filter, Authentifizierung, RPKI, Telemetrie und Automatisierung ergänzt. Trotzdem bleibt menschliche Kontrolle notwendig: Ein formal gültiger Weg kann geschäftlich oder sicherheitstechnisch falsch sein, und ein schneller Ersatzpfad kann andere Leitungen überlasten.

Daten und Meilensteine

  • GRE trägt die IP-Protokollnummer 47.
  • RFC 2784 beschreibt das Basisformat.
  • GRE kann Multicast und viele Layer-3-Protokolle kapseln.
  • GRE über IPsec kombiniert flexible Kapselung mit Verschlüsselung.

Was ist GRE?

Generic Routing Encapsulation (GRE, RFC 2784) ist ein Tunnelprotokoll von Cisco (1994), das beliebige Layer-3-Protokolle in IP-Pakete einkappselt. Das "äußere" IP-Paket transportiert das "innere" Paket quer durch ein IP-Netz, als wäre es ein direkter Link.

GRE ist zustandslos und hat keinen eigenen Mechanismus für Verschlüsselung oder Authentifizierung. Es ist das einfachste Tunnelprotokoll — ideal für Szenarien, wo Routing-Protokolle (OSPF, EIGRP) über WAN-Links geführt werden müssen, die kein Multicast unterstützen.

GRE-Header-Struktur

Ein GRE-Paket hat folgenden Aufbau:

1. Outer IP Header: Quell-IP = Tunnel-Quelle (Router A), Ziel-IP = Tunnel-Ziel (Router B), Protokoll=47 (GRE). 2. GRE Header: 4 Byte minimal. Enthält Protocol Type (welches Protokoll folgt, z.B. 0x0800 = IP, 0x86DD = IPv6, 0x883F = OSPF). 3. Inner IP Header + Payload: Das originale Paket, das getunnelt wird.

Der Overhead beträgt 24 Byte (20 Byte Outer IP + 4 Byte GRE). Bei Standard-MTU von 1500 Byte verbleiben nur 1476 Byte für das innere Paket. MSS-Clamping auf TCP oder erhöhte MTU am Tunnel ist daher wichtig.

Anwendungsfälle

DMVPN (Dynamic Multipoint VPN) ist die häufigste GRE-Nutzung in Enterprise-Netzen. Hub-and-Spoke-VPN mit dynamisch aufgebauten Spoke-to-Spoke-Tunneln. Cisco-proprietär, aber sehr verbreitet.

Multicast über Internet: Routing-Protokolle (OSPF, EIGRP) nutzen Multicast. GRE transportiert diese Multicast-Pakete als Unicast über das Internet — Routing-Protokolle laufen im Tunnel.

IPv6-Transitioning: 6in4 (RFC 4213) tunnelt IPv6 über IPv4 — ein spezialisierter GRE-Verwandter.

GRE over IPsec: GRE für Routing-Protokolle + IPsec für Verschlüsselung — die Standardkombination in Enterprise-VPNs. GRE allein würde Daten unverschlüsselt übertragen.

GRE vs. moderne Alternativen

GRE ist simpel und bewährt, aber veraltet in modernen Umgebungen. Alternativen:

VXLAN (RFC 7348): Layer-2-over-Layer-3, speziell für Data Centers. WireGuard: Modernes VPN mit integrierter Verschlüsselung. IPsec-Tunnel: Verschlüsselt, aber komplex. GENEVE (RFC 8926): Flexibler als VXLAN, für Cloud-Native-Environments.

GRE bleibt relevant in: Legacy-Cisco-Netzen (DMVPN), Kombinationen mit IPsec, Labs und Test-Setups.