Dynamische Routen konfigurieren
Wenn ein dynamisches Routing-Protokoll aktiviert ist, überwacht der entsprechende Routing-Prozess Routenaktualisierungen und kündigt Routen an. Routing-Protokolle ermöglichen es einem Upstream-Router, die Equal Cost Multipath (ECMP) -Technik zu verwenden, um den Datenverkehr auf identische virtuelle Server zu verteilen, die auf zwei eigenständigen NetScaler-Appliances gehostet werden. Dynamisches Routing auf einer NetScaler-Appliance verwendet drei Routingtabellen. In einem Setup mit hoher Verfügbarkeit spiegeln die Routingtabellen auf der sekundären Appliance die auf der primären Appliance.
Informationen zu Befehlsreferenzhandbüchern und nicht unterstützten Befehlen für das dynamische Routingprotokoll finden Sie unterBefehlsreferenzhandbücher für das dynamische Routing-Protokoll und nicht unterstützte Befehle.
NetScaler unterstützt die folgenden Protokolle:
- Routing Information Protocol (RIP) Version 2
- Öffnen Sie Shortest Path First (OSPF) Version 2
- Border Gateway Protocol (BGP)
- Routing Information Protocol der nächsten Generation (RiPNG) für IPv6
- Öffnen Sie Shortest Path First (OSPF) Version 3 für IPv6
- ISIS-Protokoll
Sie können mehrere Protokolle gleichzeitig aktivieren.
Routing-Tabellen in NetScaler
In einer NetScaler-Appliance enthalten die NetScaler-Kernel-Routingtabelle, die FreeBSD-Kernel-Routing-Tabelle und die NSM-FIB-Routingtabelle jeweils unterschiedliche Routen und dienen einem anderen Zweck. Sie kommunizieren miteinander, indem sie UNIX-Routing-Sockets verwenden. Routenaktualisierungen werden nicht automatisch von einer Routingtabelle an eine andere weitergegeben. Sie müssen die Weitergabe von Routenaktualisierungen für jede Routingtabelle konfigurieren.
NS-Kernel-Routingtabelle
死NS-Kernel-Routing-Tabelle enthalt Subnetzrouten, die dem NSIP und jedem SNIP und MIP entsprechen. Normalerweise sind in der NS-Kernel-Routing-Tabelle keine Routen vorhanden, die VIPs entsprechen. Die Ausnahme ist ein VIP, das mithilfe des Befehls add ns ip hinzugefügt und mit einer anderen Subnetzmaske als 255.255.255.255 konfiguriert wurde. Wenn mehrere IP-Adressen zu demselben Subnetz gehören, werden sie als eine einzige Subnetzroute abstrahiert. Darüber hinaus enthält diese Tabelle eine Route zum Loopback-Netzwerk (127.0.0.0) und alle statischen Routen, die über die CLI (CLI) hinzugefügt wurden. Die Einträge in dieser Tabelle werden vom NetScaler bei der Paketweiterleitung verwendet. Über die CLI können sie mit dem Befehl show route überprüft werden.
FreeBSD-Routingtabelle
Der einzige Zweck der FreeBSD-Routingtabelle besteht darin, die Initiierung und Beendigung des Verwaltungsverkehrs (Telnet, SSH usw.) zu erleichtern. In einer NetScaler-Appliance sind diese Anwendungen eng mit FreeBSD verbunden, und es ist unerlässlich, dass FreeBSD über die notwendigen Informationen verfügt, um den Datenverkehr zu und von diesen Anwendungen abzuwickeln. Diese Routingtabelle enthält eine Route zum NSIP-Subnetz und eine Standardroute. Darüber hinaus fügt FreeBSD Routen vom Typ WasCloned (W) hinzu, wenn der NetScaler Verbindungen zu Hosts in lokalen Netzwerken aufbaut. Aufgrund des hochspezialisierten Nutzens der Einträge in dieser Routingtabelle Bypass alle anderen Route-Updates aus dem NS-Kernel und den NSM-FIB-Routingtabellen die FreeBSD-Routingtabelle. Ändern Sie es nicht mit dem Befehl route. Die FreeBSD-Routingtabelle kann mit dem Befehl netstat von jeder UNIX-Shell aus überprüft werden.
Netzwerkdienstmodul (NSM) FIB
Die NSM-FIB-Routingtabelle enthält die anzeigbaren Routen, die von den dynamischen Routing-Protokollen an ihre Peers im Netzwerk verteilt werden. Es kann enthalten:
- Verbundene Strecken. IP-Subnetze, die direkt vom NetScaler aus erreichbar sind. In der Regel sind Routen, die dem NSIP-Subnetz entsprechen, und Subnetze, über die Routing-Protokolle aktiviert sind, in NSM FIB als verbundene Routen vorhanden.
- Kernel-Routen. Alle VIP-Adressen, auf denen die Option -hostRoute aktiviert ist, sind in NSM FIB als Kernel-Routen vorhanden, sofern sie die erforderlichen RHI-Levels erfüllen. Darüber hinaus enthält NSM FIB alle auf der CLI konfigurierten statischen Routen, für die die Option - advertise aktiviert ist. Wenn der NetScaler im SRADV-Modus (Static Route Advertisement) arbeitet, sind alternativ alle auf der CLI konfigurierten statischen Routen in NSM FIB vorhanden. Diese statischen Routen sind in NSM FIB als Kernel-Routen gekennzeichnet, da sie eigentlich zur NS-Kernel-Routing-Tabelle gehören.
- Statische Routen. Normalerweise ist jede in VTYSH konfigurierte statische Route in NSM FIB vorhanden. Wenn die administrativen Entfernungen von Protokollen geändert werden, ist dies möglicherweise nicht immer der Fall. Ein wichtiger Punkt, den es zu beachten gilt, ist, dass diese Routen niemals in die NS-Kernel-Routing-Tabelle gelangen können.
- Gelernte Routen. Wenn der NetScaler so konfiguriert ist, dass er Routen dynamisch lernt, enthält die NSM-FIB Routen, die von den verschiedenen dynamischen Routing-Protokollen gelernt wurden. Von OSPF erlernte Routen bedürfen jedoch einer speziellen Verarbeitung. Sie werden nur dann auf FIB heruntergeladen, wenn die Option fib-install für den OSPF-Prozess aktiviert ist. Dies kann über die Router-Config-Ansicht in VTYSH erfolgen.
Dynamisches Routing in einem Hochverfügbarkeits-Setup
In einem Hochverfügbarkeits-Setup führt der primäre Knoten den Routing-Prozess aus und leitet Routing-Tabellenaktualisierungen an den sekundären Knoten weiter. Die Routingtabelle des sekundären Knotens spiegelt die Routingtabelle des primären Knotens wider.
Ununterbrochene Weiterleitung
Nach dem Failover benötigt der sekundäre Knoten einige Zeit, um das Protokoll zu starten, die Routen zu erlernen und seine Routingtabelle zu aktualisieren. Dies wirkt sich jedoch nicht auf das Routing aus, da die Routingtabelle auf dem sekundären Knoten mit der Routingtabelle auf dem primären Knoten identisch ist. Diese Betriebsart wird als Non-Stop-Forwarding bezeichnet.
Mechanismus zur Vermeidung von Schwarzen Löchern
Nach dem Failover injiziert der neue Primärknoten alle seine VIP-Routen in den Upstream-Router. Dieser Router behält jedoch die Routen des alten Primärknotens 180 Sekunden lang bei. Da der Router sich des Failovers nicht bewusst ist, versucht er, den Datenverkehr zwischen den beiden Knoten auszugleichen. In den 180 Sekunden, bevor die alten Routen ablaufen, sendet der Router die Hälfte des Datenverkehrs an den alten, inaktiven Primärknoten, der praktisch ein schwarzes Loch darstellt.
Um dies zu verhindern, weist der neue primäre Knoten beim Einfügen einer Route eine Metrik zu, die geringfügig niedriger ist als die, die vom alten primären Knoten angegeben wurde.
Schnittstellen für die Konfiguration von dynamischem Routing
Um dynamisches Routing zu konfigurieren, können Sie entweder die GUI oder eine Befehlszeilenschnittstelle verwenden. Der NetScaler unterstützt zwei unabhängige Befehlszeilenschnittstellen: die CLI und die Virtual Teletype Shell (VTYSH). Die CLI ist die native Shell der Appliance. VTYSH wird von ZeBos verfügbar gemacht. Die NetScaler Routing Suite basiert auf ZebOS, der kommerziellen Version von GNU Zebra.
Hinweis:
Citrix empfiehlt, VTYSH für alle Befehle zu verwenden, mit Ausnahme derjenigen, die nur in der CLI konfiguriert werden können. Die Verwendung der CLI sollte im Allgemeinen auf Befehle zur Aktivierung der Routing-Protokolle, zur Konfiguration der Host-Route-Werbung und zum Hinzufügen statischer Routen für die Paketweiterleitung beschränkt sein.
Referenzhandbücher für Dynamic Routing-Protokoll und nicht unterstützte Befehle
In der folgenden Tabelle sind Links für Befehlsreferenzhandbücher für verschiedene dynamische Routingprotokolle und nicht unterstützte Befehle auf der NetScaler Appliance aufgeführt:Referenzhandbücher für dynamische Routingprotokolle und nicht unterstützte Befehle.