Virtuelle IP-Adressen (VIP-Adressen) für VRRP

Die virtuelle IP-Adresse bzw. VIP für dp0bond1 oder dp0bond0 für VRRP ist eine variable IP-Adresse, die bei einem Failover vom Master- zum Backupgerät wechselt. Beim Bereitstellen einer VRA werden zugehörige Netzverbindungen für öffentliche und private Daten sowie echte IP-Adressen für beide Schnittstellen zugewiesen. Außerdem wird jeder der beiden Schnittstellen eine VIP zugewiesen (unabhängig davon, ob das Gerät eigenständig ist oder zu einem HA-Paar gehört). Datenverkehr mit einer Ziel-IP in VLAN-Teilnetzen, die der VRA zugeordnet sind, wird direkt über eine statische Route im FCR oder BCR an die betreffenden VRRP-VIPs gesendet.

Die virtuellen VRRP IP-Adressen für Gateway-Gruppen sollten nicht geändert und die VRRP-Schnittstelle nicht inaktiviert werden. Diese IP-Adressen dienen als Methode für die Weiterleitung des Datenverkehrs zum Gateway, wenn ein VLAN zugeordnet ist. Wenn sie inaktiv sind, ist der VLAN-Datenverkehr somit ebenfalls inaktiv. Wenn die IP-Adresse nicht vorhanden ist, kann der Datenverkehr vom BCR bzw. FCR nicht zur VRA selbst weitergeleitet werden. Diese virtuelle Adresse bzw. VIP ist zu diesem Zeitpunkt nicht änderbar. Diese Einschränkung wird künftig möglicherweise geändert; zurzeit wird jedoch weder die Migration einer VRA zwischen Pods, FCRs oder BCRs noch das Ändern der VIP unterstützt.

Im Folgenden finden Sie ein Beispiel für die Standardkonfigurationen der VIPs dp0bond0 und dp0bond1 für eine bestimmte VRA. Beachten Sie, dass sich Ihre IP-Adressen und VRRP-Gruppen (vrrp-groups) möglicherweise von diesem Beispiel unterscheiden.

set interfaces bonding dp0bond0 vrrp vrrp-group 2 virtual-address '10.127.170.1/26'
set interfaces bonding dp0bond1 vrrp vrrp-group 2 virtual-address '159.8.98.209/29'

Weitere Informationen finden Sie unter Zugeordnete VLAN-Teilnetze mit VRRP.

Standardmäßig ist VRRP inaktiviert. Dadurch wird sichergestellt, dass neue Bereitstellungen und erneutes Laden keine Ausfälle auf dem Mastergerät verursachen. Damit der VLAN-Datenverkehr übertragen werden kann, muss VRRP erneut aktiviert werden, sobald das Bereitstellen bzw. das erneute Laden abgeschlossen ist. Das folgende Beispiel erläutert die Standardkonfiguration:

set interfaces bonding dp0bond0 vrrp vrrp-group 2 'disable'
set interfaces bonding dp0bond1 vrrp vrrp-group 2 'disable'

Führen Sie die folgenden Befehle aus, um VRRP auf den beiden Schnittstellen nach einer Bereitstellung oder einem erneuten Laden zu aktivieren. Die Aktivierung ist sowohl für eigenständige Schnittstellen als auch für HA-Paare erforderlich. Schreiben Sie dann die Änderung fest:

delete interfaces bonding dp0bond0 vrrp vrrp-group 2 'disable'
delete interfaces bonding dp0bond1 vrrp vrrp-group 2 'disable'

VRRP-Gruppe

Eine VRRP-Gruppe besteht aus einem Cluster mit Schnittstellen oder virtuellen Schnittstellen, die Redundanz für eine primäre Schnittstelle (Masterschnittstelle) in der Gruppe bereitstellen. Die VRRP-Gruppe definiert virtual_router_id in der Keepalive-Konfiguration. In dem VRRP-Protokoll selbst wird dies als VRID bezeichnet. Die VRRP-Gruppe verfügt über eine eindeutige numerische Kennung, der bis zu 20 virtuelle IP-Adressen zugewiesen werden können.

Die ID der VRRP-Gruppe wird von IBM Cloud zugeordnet und sollte nicht geändert werden. Wenn eine neue Gateway-Gruppe zum ersten Mal hinter einem Frontend Customer Router (FCR) bzw. Backend Customer Router (BCR) bereitgestellt wird, ist sie VRRP-Gruppe 1. Für die Bereitstellung nachfolgender Gateway-Gruppen wird dieser Wert erhöht, um Konflikte zu vermeiden. Die nächste Gruppe ist dann beispielsweise Gruppe 2, danach folgt Gruppe 3 usw. Die Berechnung und Zuweisung erfolgt durch den Bereitstellungsprozess. Das Ändern dieses Wertes kann zu Konflikten mit anderen aktiven Gruppen führen und in der Folge einen Master/Master-Konflikt sowie eine Betriebsunterbrechung für beide Gateway-Gruppen verursachen.

Bei der Migration einer vorherigen Konfiguration sollten Sie Ihren Konfigurationscode dahingehend überprüfen, dass keine statische VRRP-Gruppen-ID zugewiesen wird.

Die VRRP-Gruppen-ID wird in der Datenbank dauerhaft festgelegt, d. h. beim erneuten Laden des Betriebssystems oder bei einem Upgrade wird derselbe Gruppen-ID-Wert verwendet. Beim erneuten Laden des Betriebssystems wird jede vom Benutzer geänderte VRRP-Gruppen-ID durch den vom System zugewiesenen Wert überschrieben.

VRRP-Priorität

Der ersten Maschine in einer Gateway-Gruppe wird die Priorität 254 zugeordnet. Dieser Wert wird beim Bereitstellen jedes weiteren Geräts verringert. Verwenden Sie auf keinen Fall den Prioritätswert 255. Dieser Wert definiert den "Eigentümer" der VIP-Adresse und kann zu unbeabsichtigtem Verhalten führen, wenn die Maschine mit einer Konfiguration online geschaltet wird, die nicht mit dem aktiven Mastersystem übereinstimmt.

Präemptive Verarbeitung in VRRP

Die präemptive Verarbeitung sollte in allen VRRP-Schnittstellen stets inaktiviert sein, damit ein neues Gerät oder ein Gerät, dessen Betriebssystem erneut geladen wird, nicht versucht, den Cluster zu übernehmen.

VRRP-Heartbeatintervall

Die Masterschnittstelle oder virtuelle Schnittstelle signalisiert dem LAN-Segment durch das Senden von Heartbeatpaketen (advertisements), dass sie weiterhin aktiv ist, und verwendet dabei die von IANA für das VRRP zugewiesenen Multicast-Adressen (224.0.0.18 für IPv4 und FF02:0:0:0:0:0:0:12 für IPv6).

Standardmäßig ist das Intervall auf 1 gesetzt. Dieser Wert kann erhöht werden, es wird jedoch nicht empfohlen, einen Wert über 5 festzulegen. In einem ausgelasteten Netz kann es viel länger als eine Sekunde dauern, bis alle VRRP-Benachrichtigungen vom Master auf der Sicherungseinheit ankommen. Daher sollte für Netze mit hohem Datenverkehr der Wert 2 verwendet werden.

VRRP-Synchronisation (sync-group)

Die Synchronisation der Schnittstellen in einer VRRP-Synchronisationsgruppe (sync group) ist wie folgt ausgelegt: Wenn das Backupsystem die Funktion einer Schnittstelle der Gruppe übernimmt, werden auch die Funktionen aller anderen Schnittstellen der Gruppe vom Backupsystem übernommen. Beispiel: Wenn eine Schnittstelle in einem Master-Router ausfällt, wird die Funktionalität des gesamten Routers von einem Backup-Router übernommen.

Dieser Wert stimmt nicht mit der VRRP-Gruppe überein. Er definiert, für welche Schnittstellen eines Geräts ein Failover durchgeführt wird, wenn bei einer Schnittstelle in der betreffenden Gruppe ein Fehler festgestellt wird. Es wird empfohlen, alle Schnittstellen derselben Synchronisationsgruppe (sync-group) zuzuweisen. Andernfalls werden manche Schnittstellen als Master eingestuft und mit Gateway-IPs versehen, während andere als Backup eingestuft werden. Dies führt dazu, dass der Datenverkehr nicht mehr korrekt weitergeleitet wird. Aktiv/Aktiv-Konfigurationen werden nicht unterstützt.

RFC-Kompatibilität für VRRP

Die RFC-Kompatibilität aktiviert bzw. inaktiviert RFC 3768-MAC-Adressen für VRRP in einer Schnittstelle. Diese sollten in nativen Schnittstellen aktiviert und in den konfigurierten virtuellen Schnittstellen inaktiviert sein. Bei manchen virtuellen Switches (insbesondere VMware) treten Probleme auf, wenn diese Adressen aktiviert sind. Dadurch geht Datenverkehr von der Hypervisor-Hostmaschine verloren und wird nicht an die Gateway-IP gesendet. Lassen Sie diese Einstellung unverändert und verzichten Sie auf das Konfigurieren der Einstellung für virtuelle Schnittstellen.

VRRP-Authentifizierung

Wenn ein Kennwort für die VRRP-Authentifizierung festgelegt ist, muss auch der Authentifizierungstyp definiert werden. Wenn das Kennwort festgelegt ist und kein Authentifizierungstyp definiert wird, gibt das System einen Fehler aus, wenn Sie versuchen, die Konfiguration festzuschreiben.

Umgekehrt kann das VRRP-Kennwort nur gelöscht werden, wenn auch der VRRP-Authentifizierungstyp gelöscht wird. Andernfalls gibt das System einen Fehler aus, wenn Sie versuchen, die Konfiguration festzuschreiben. Wenn Sie sowohl das VRRP-Authentifizierungskennwort als auch den Authentifizierungstyp löschen, ist die VRRP-Authentifizierung inaktiviert.

Die IETF hat entschieden, dass die Authentifizierung für VRRP Version 3 nicht verwendet werden soll. Weitere Informationen finden Sie unter RFC 5798 VRRP.

Unterstützung für Version 2/3

VRA unterstützt Protokolle für die Version 2 (Standardwert) und die Version 3 von VRRP. In Version 2 dürfen IPv4 und IPv6 nicht gleichzeitig verwendet werden, in Version 3 ist dies jedoch möglich.

VPN für Hochverfügbarkeit mit VRRP

VRA bietet die Möglichkeit, die Konnektivität über einen IPsec-Tunnel mithilfe eines IBM Cloud® Virtual Router Appliance-Paares mit VRRP aufrechtzuerhalten. Wenn ein Router ausfällt oder zu Wartungszwecken abgeschaltet wird, stellt der neue VRRP-Master-Router die IPsec-Konnektivität zwischen den lokalen und fernen Netzen wieder her.

Beim Konfigurieren der Hochverfügbarkeits-VPN mit VRRP müssen Sie nach jedem Hinzufügen einer virtuellen VRRP-Adresse zu einer VRA-Schnittstelle den IPsec-Dämon reinitialisieren. Dies ist erforderlich, weil der IPsec-Service nur Verbindungen zu den Adressen überwacht, die beim Initialisieren des Internet Key Exchange-Servicedämons in der VRA vorhanden sind.

Führen Sie den folgenden Befehl auf dem Master- und dem Backup-Router aus, damit die IPsec-Dämons beim Aktivieren eines Failovers auf einem neuen Mastergerät erneut gestartet werden, nachdem die virtuelle IP übernommen wurde, wie im folgenden Beispiel gezeigt:

vyatta@vrouter# set interfaces bonding dp0bond1 vrrp vrrp-group 1 notify ipsec

Firewalls für Hochverfügbarkeit mit VRRP

Wenn zwei Geräte ein HA-Paar bilden, ist sorgfältig darauf zu achten, dass auf dem Mastergerät nicht der Zugang für das andere Gerät blockiert wird. Der Port 443 muss zwischen beiden Geräten offen bleiben, damit die Konfigurationssynchronisation funktionsfähig bleibt, und VRRP muss zum Senden und Empfangen freigegeben sein (einschließlich des Multicastbereichs 224.0.0.0/24).

Zugehörige VLAN-Teilnetze mit VRRP

Für die VIF-Konfiguration mit VRRP wird eine virtuelle IP-Adresse (die erste verwendbare IP im Teilnetz; die Gateway-IP an die jeglicher Datenverkehr in dem Teilnetz weitergeleitet wird) und eine echte Schnittstellen-IP-Adresse für die VIF auf beiden Geräten benötigt. Um nicht zu viele verwendbare IP-Adressen zu belegen, sollte für die echten Schnittstellen-IPs ein Out-of-band-Adressbereich wie 192.168.0.0/30 (mit der Adresse .1 für das eine Gerät und der Adresse .2 für das andere Gerät) verwendet werden. Sie können mehrere virtuelle VRRP-IPs verwenden, jedoch wird nur eine echte Adresse für jede virtuelle Schnittstelle benötigt.

Hier finden Sie ein Beispiel für eine VRRP-Konfiguration mit zwei privaten VLANs und drei Teilnetzen:

set interfaces bonding dp0bond0 address '10.100.11.39/26'
set interfaces bonding dp0bond0 mode 'lacp'
set interfaces bonding dp0bond0 vif 10 address '192.168.255.81/30'
set interfaces bonding dp0bond0 vif 10 description 'VLAN 10 - Two private subnets/VIPs'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 advertise-interval '1'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 virtual-address '10.100.105.177/28'
set interfaces bonding dp0bond0 vif 10 vrrp vrrp-group 1 virtual-address '10.100.38.1/26'
set interfaces bonding dp0bond0 vif 11 address '192.168.255.89/30'
set interfaces bonding dp0bond0 vif 11 description 'VLAN 11 - One private subnet/VIP'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 advertise-interval '1'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond0 vif 11 vrrp vrrp-group 1 virtual-address '10.100.212.65/26'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 'rfc-compatibility'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond0 vrrp vrrp-group 1 virtual-address '10.100.11.5/26'
set interfaces bonding dp0bond1 address '169.110.20.28/29'
set interfaces bonding dp0bond1 mode 'lacp'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 notify 'ipsec'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 preempt 'false'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 priority '254'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 'rfc-compatibility'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 sync-group 'vgroup1'
set interfaces bonding dp0bond1 vrrp vrrp-group 1 virtual-address '169.110.21.26/29'

• Eine VRRP-Synchronisationsgruppe (VRRP sync-group) unterscheidet sich von einer VRRP-Gruppe (VRRP group). Wenn eine Schnittstelle, die zu einer Synchronisationsgruppe gehört, den Status ändert, werden alle anderen Mitglieder dieser Synchronisationsgruppe ebenfalls in denselben Status versetzt.
• Die VRRP-Gruppennummer der VLAN-Schnittstellen (VIFs) sollte in fast allen Fällen mit der entsprechenden nativen Schnittstelle identisch sein. Beispielsweise sollte dp0bond1.789 immer dieselbe VRRP-Gruppennummer wie dp0bond1 aufweisen, es sei denn, die beiden Schnittstellen nutzen dieselbe Synchronisationsgruppe gemeinsam. Die Verwendung unterschiedlicher Gruppennummern bei der VIF und der nativen Schnittstelle kann dazu führen, dass eine "Split Brain"-Bedingung auftritt, wenn gleichzeitig unterschiedliche Synchronisationsgruppen verwendet werden. Nutzen zwei Schnittstellen dieselbe Synchronisierungsgruppe gemeinsam, obwohl sie zu verschiedenen VRRP-Gruppen gehören, erfolgt bei beiden gleichzeitig der Übergang zu Master und Backup, wodurch die "Split Brain"-Bedingung vermieden werden kann. Wird die native Schnittstelle jedoch mit einer anderen VRRP-Gruppennummer und einer anderen Synchronisationsgruppe als die VLAN-Schnittstelle eingerichtet, da bei VLAN-Schnittstellen eingerichtete Teilnetze statisch an die virtuelle Adresse der nativen Schnittstelle weitergeleitet werden, wenn die VLAN-Schnittstelle als Backup-Schnittstelle und die native Schnittstelle als Master angezeigt wird, sendet der Router VLAN-Schnittstellenverkehr an die VRA, bei der die native Schnittstelle die Masterschnittstelle ist, auch wenn die VLAN-Schnittstelle sekundär und in der VRA nicht aktiv ist. Diese spezielle Situation wird als "Split Brain"-Bedingung bezeichnet und verursacht eine Betriebsunterbrechung. Aus diesem Grund ist bei der Einrichtung von Synchronisationsgruppen in Verbindung mit VRRP-Gruppen mit Umsicht vorzugehen. Auch das Verwenden derselben VRRP-Gruppennummern bei mehreren VRA-Hochverfügbarkeitspaaren in demselben Transit-VLAN ist zu vermeiden, da vier Vyattas, die dieselbe Gruppe verwenden, dazu führen, dass drei VRAs potenziell einen Backupstatus aufweisen und nur ein Master verfügbar ist, sodass eine Betriebsunterbrechung eintritt.
• Die tatsächlichen Schnittstellenadressen auf den nativen VLANs (z. B. dp0bond1: 169.110.20.28/29) befinden sich nicht immer in demselben Teilnetz wie deren VIPs (169.110.21.26/29).

Manueller VRRP-Ausweichbetrieb

Falls Sie einen VRRP-Failover erzwingen müssen, kann dies durch die Ausführung des folgenden Befehls auf dem Gerät, das gerade VRRP-Master ist, erreicht werden:

vyatta@vrouter$ reset vrrp master interface dp0bond0 group 1

Die Gruppen-ID ist die VRRP-Gruppen-ID der nativen Schnittstellen und kann - wie oben beschrieben - in Ihrem Paar anders lauten.

Verbindungssynchronisation

Wenn zwei VRA-Geräte ein HA-Paar bilden, kann es hilfreich sein, statusabhängige Verbindungen zwischen beiden Geräten zu überwachen, damit im Falle eines Failovers der aktuelle Status aller auf dem ausgefallenen Gerät vorhandenen Verbindungen auf dem Backupgerät repliziert werden kann. Dadurch kann auf die vollständige Neuerstellung der aktiven Sitzungen (z. B. SSL-Verbindungen) verzichtet werden, die zu einer Funktionsunterbrechung für den Benutzer führen könnte.

Dieses Verfahren wird als Synchronisierung der Verbindungsüberwachung bezeichnet.

Um diese Funktion zu konfigurieren, müssen Sie die Failover-Methode deklarieren sowie die Schnittstelle zum Senden der Verbindungsüberwachungsdaten und die IP des fernen Peers wie folgt angeben:

set service connsync failover-mechanism vrrp sync-group SYNC1
set service connsync interface dp0bond0
set service connsync remote-peer 10.124.10.4

Die andere VRA verfügt über die gleiche Konfiguration, jedoch über einen anderen fernen Peer (remote-peer).

Beachten Sie, dass die Leitung überlastet werden kann, wenn viele Verbindungen zu anderen Schnittstellen führen und in Konkurrenz zu anderen Datenverkehrsströmen in der deklarierten Leitung treten.

Funktion für VRRP-Startverzögerung

Die Vyatta-Betriebssystemversion 1801p und höher enthält den neuen Befehl vrrp.

vrrp gibt ein Wahlprotokoll an, das die Verantwortung für einen virtuellen Router dynamisch einem der VRRP-Router in einem LAN zuordnet. Der VRRP-Router, der die IPv4- oder IPv6-Adressen steuert, die einem virtuellen Router zugeordnet sind, wird als Master bezeichnet und leitet Pakete weiter, die an diese IPv4- oder IPv6-Adressen gesendet wurden. Der Wahlprozess stellt einen dynamischen Failover in der Weiterleitungsfunktion bereit, falls der Master nicht mehr verfügbar sein sollte. Alle Protokollnachrichten werden entweder mit IPv4- oder IPv6-Multicast-Datagrammen ausgeführt. Das Protokoll kann dadurch über eine Vielzahl von LAN-Technologien mit mehreren Zugriffsmöglichkeiten, die IPv4/IPv6-Multicasting unterstützen, betrieben werden.

Um den Datenaustausch im Netz zu minimieren, sendet nur der Master für jeden virtuellen Router regelmäßige VRRP-Mitteilungen als Nachrichten. Ein Backup-Router versucht nicht, den Master präemptiv zu verarbeiten, es sei denn, er hat eine höhere Priorität. Dadurch wird die Serviceunterbrechung beseitigt, die bisher bis zur Verfügbarkeit eines bevorzugteren Pfads bestand. Es ist auch möglich, alle präemptiven Verarbeitungsversuche administrativ zu untersagen. Falls der Master nicht mehr verfügbar ist, wird der Backup mit der höchsten Priorität nach einer kurzen Verzögerung zum Master und bietet einen kontrollierten Übergang der Verantwortung des virtuellen Routers mit minimaler Serviceunterbrechung.

Bei Bereitstellungen von IBM Cloud ist der Startverzögerungswert auf den Standardwert eingestellt. Sie können diesen Wert nach Ihrem Ermessen ändern, wenn Sie Ihre Failover- und Hochverfügbarkeitsmethoden testen.

vrrp {
start-delay <0-600>
}

interfaces {
  bonding dp0bond1 {
address 161.202.101.206/29 mode balanced
vrrp {
      start-delay 120
      vrrp-group 211 {
preempt false
priority 253
virtual-address 161.202.101.204/29
} }
}