Common Address Redundancy Protocol
| CARP (Common Address Redundancy Protocol) | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Familie: | Internetprotokollfamilie | ||||||||||||||||||||||||
| Einsatzgebiet: |
Steigerung der Verfügbarkeit | ||||||||||||||||||||||||
| |||||||||||||||||||||||||
| Standards: | |||||||||||||||||||||||||
Das Common Address Redundancy Protocol (CARP) ist ein Netzwerkprotokoll, mit dessen Hilfe sich die Verfügbarkeit von IP-Systemen erhöhen lässt. Dies wird dadurch erreicht, dass mehrere Rechner innerhalb eines lokalen Netzes dieselben virtuellen IP-/MAC-Adressen für die Kommunikation mit anderen Systemen nutzen können. Haupteinsatzgebiet von CARP ist die Erstellung hochverfügbarer Gateways (Router/Firewall); mit CARP lassen sich aber auch Applikationsserver hochverfügbar machen. In der Internetprotokollfamilie ist es das Protokoll Nummer 112. Entwickelt wurde CARP vom OpenBSD-Team. Die Entwicklung war nötig, weil es (aus patentrechtlichen Gründen) nicht möglich ist, im Rahmen eines Open-Source-Projektes VRRP einzusetzen. Dadurch war es nötig, ein eigenes Protokoll zu schreiben. Zusätzlich konnten auf diese Weise grundlegende Fehler des VRRP und HSRP vermieden werden. Die erste OpenBSD-Version, bei der CARP integriert war, war Version 3.5.
Inzwischen ist CARP auch auf andere Plattformen portiert worden. Eine freie Userland-Portierung ist UCARP (zurzeit erhältlich für Linux 2.4/2.6, OpenBSD und NetBSD). Für DragonFly BSD, FreeBSD[1] und NetBSD existieren Kernel-Implementierungen.
Abgrenzung zu VRRP
Die grundsätzliche Aufgabe und Funktionsweise von CARP ähnelt VRRP. Es gibt aber einige grundlegende Unterschiede:
- Der wichtigste Vorteil von CARP ist, dass es, im Gegensatz zu VRRP, patentfrei von jedermann genutzt werden kann.
- Ein grundsätzlicher Unterschied zu VRRP ist die protokollunabhänge Arbeitsweise von CARP. Damit ist CARP für IPv4 und IPv6 nutzbar.
- Des Weiteren wurde bei der Entwicklung von CARP sehr viel Wert auf Sicherheit gelegt, so sind beispielsweise die zwischen den Cluster-Rechnern ausgetauschten Nachrichten prinzipiell kryptographisch mit SHA-1 bzw. HMAC signiert.
- CARP nutzt ein Feature namens arpbalance. Dabei nutzen alle Rechner dieselbe virtuelle IP-Adresse, aber jeder Rechner bekommt noch eine eigene virtuelle MAC-Adresse. Dadurch ist Lastverteilung zwischen den Rechnern möglich. Dieses Merkmal funktioniert bisher nur unter OpenBSD sowie auf FreeBSD bis Version 9.3[2], userland CARP (UCARP) implementiert diese Funktion für andere Plattformen, z. B. Linux bisher nicht.
Funktionsweise
Um CARP zu nutzen, braucht man mindestens zwei Systeme, die die gleiche Aufgabe erfüllen und im selben Subnetz liegen. Diese Systeme haben jeweils eine eindeutige IP- und MAC-Adresse und bilden einen Cluster. Zusätzlich wird diesem Cluster jetzt eine virtuelle IP- und MAC-Adresse zugewiesen. Über diese virtuelle IP/MAC kommuniziert der Cluster mit anderen Systemen. Damit das funktioniert, wird ein Cluster-Rechner Master und die anderen Slaves, wobei der Master die Kommunikation mit der Außenwelt übernimmt. Über das CARP-Protokoll stellt jedes Cluster-Mitglied sicher, dass die anderen Maschinen noch arbeiten. Wenn der Master ausfällt, übernimmt einer der Slaves sowohl die virtuelle MAC-Adresse als auch die virtuelle IP-Adresse.[3]
Besonders interessant ist CARP im Zusammenhang mit hoch verfügbaren Firewalls. Dabei ist es zusätzlich nötig, die Zustandstabellen zu synchronisieren, um Verluste von Verbindungen bei Ausfall des aktiven Cluster-Rechners zu verhindern. Bei der Kombination OpenBSD/pf wird hierfür pfsync eingesetzt, unter Linux/Netfilter ist diese Funktion mit conntrackd umsetzbar.
Weblinks
- Man page-Eintrag Beschreibung der Original OpenBSD-Implementation
- https://ucarp.wordpress.com/
- Firewall Failover with pfsync and CARP (OpenBSD)
Einzelnachweise
- ↑ carp(4). Abgerufen am 8. Oktober 2018.
- ↑ FreeBSD 10.0-RELEASE Release Notes. Abgerufen am 8. Oktober 2018.
- ↑ heise online: OPNsense-Firewall 20.1 mit VXLAN, IPsec Public Key und kompletter Doku. Abgerufen am 26. November 2021.
