Konfigurationsbeispiel für den intelligenten Traffic Director des Nexus 7000
Inhalt
Einführung
Dieses Dokument beschreibt grundlegende Schritte zur Fehlerbehebung und Verifizierung von Intelligent Traffic Director (ITD) auf dem Nexus 7000. In diesem Dokument wird eine Server Load Balancing-Bereitstellung verwendet, um Konzepte im Zusammenhang mit ITD zu veranschaulichen.
Weitere Informationen zum ITD finden Sie in den folgenden Ressourcen:
- Cisco Intelligent Traffic Director auf einen Blick
- Befehlsreferenz für Cisco Nexus NX-OS Intelligent Traffic Director der Serie 7000
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie mit der ITD vertraut sind.
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:
- Cisco Nexus Switches der Serie 7000
- Cisco NX-OS Version 6.2(10)
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Hintergrundinformationen
ITD wird zum Lastenausgleich des Datenverkehrs verwendet, der auf einer bestimmten Layer-3-Schnittstelle zwischen einer Anzahl von Geräten eingeht, die als ITD-Knoten konfiguriert sind.
- ITD wird auf dem Nexus 7000 in der NX-OS-Version 6.2(8) und höher unterstützt und verfügt über wichtige neue Funktionen in Version 6.2(10).
- ITD kann unabhängig von Hardwarekomponenten (Linecard-Typen, Chassis-Typ usw.) implementiert werden.
- ITD fügt der CPU des Supervisor-Moduls keine Last hinzu.
Datenverkehrsfluss mit ITD
Die Informationen in diesem Dokument basieren auf dieser Topologie. In diesem Szenario würde sich ein Lastenausgleich für den Datenverkehr von den Hosts in VLAN 10, der an Webserver in VLAN 40 adressiert ist, zwischen Server 100 und Server 101 erhoffen.
- ITD verwendet richtlinienbasiertes Routing, um den Lastenausgleich in der Hardware des Nexus 7000 zu implementieren. Wenn ITD konfiguriert wird, werden Zugriffslisten und eine Routenübersicht dynamisch erstellt, um Datenverkehr basierend auf Ihrer im ITD definierten Lastenausgleichsrichtlinie weiterzuleiten.
- Diese Zugriffslisten werden erstellt und auf die in der ITD-Konfiguration konfigurierte Eingangsschnittstelle angewendet. In diesem Fall trifft Datenverkehr, der in VLAN 20 eingeht, entweder "bucket_1" oder "bucket_2", basierend auf dem signifikanten Bit im letzten Oktett, das durch die Zugriffslistenmaske definiert ist:
N7k-2(config)# show ip access-lists
IP access list TEST_itd_vip_1_bucket_1
10 permit ip 1.1.1.0 255.255.255.127 192.168.30.1/32
IP access list TEST_itd_vip_1_bucket_2
10 permit ip 1.1.1.128 255.255.255.127 192.168.30.1/32 - Die Routenübersicht leitet dann den Datenverkehr weiter, basierend auf der Klausel, mit der der eingehende Datenverkehr übereinstimmt. Dieses Beispiel zeigt, dass Datenverkehr, der auf "bucket_1" trifft, an den Knoten 192.168.40.100 weitergeleitet wird und Datenverkehr, der auf "bucket_2" trifft, an den Knoten 192.168.40.101 weitergeleitet wird.
N7k-1(config)# show route-map TEST_itd_pool
route-map TEST_itd_pool, permit, sequence 0
Description: auto generated route-map for ITD service TEST
Match clauses:
ip address (access-lists): TEST_itd_vip_1_bucket_1
Set clauses:
ip next-hop verify-availability 192.168.40.100 track 2 [ UP ]
route-map TEST_itd_pool, permit, sequence 1
Description: auto generated route-map for ITD service TEST
Match clauses:
ip address (access-lists): TEST_itd_vip_1_bucket_2
Set clauses:
ip next-hop verify-availability 192.168.40.101 track 2 [ UP ] - Die IP-Adresse wird nicht vom ITD übersetzt. Der Datenverkehr, der den Nexus 7000 zu den Knoten ausführt, hat eine Zieladresse von 192.168.30.1 und behält die ursprüngliche IP-Quelladresse bei.
- Der Rückverkehr wird als Unicast zurück zum ursprünglichen Absender gesendet, wobei die Quelladresse des ITD-VIP 192.168.30.1 angegeben ist.
Konfigurieren
Diese Funktionen müssen im Virtual Device Context (VDC) aktiviert werden, in dem Sie ITD konfigurieren:
N7k-1(config-itd)# show run | i feature
feature pbr
feature sla sender
feature sla responder
feature itd
Schritt 1: Konfigurieren der ITD-Gerätegruppe
Die ITD-Gerätegruppe besteht aus den Knoten, zwischen denen der Datenverkehr Load Balancing durchläuft, z. B. Webserver, Firewalls usw. Die Gerätegruppe wird wie folgt konfiguriert:
N7k-1(config)# itd device-group TAC-device-group
N7k-1(config-device-group)# node ip 192.168.40.100
N7k-1(config-device-group)# node ip 192.168.40.101
N7k-1(config-device-group)# probe icmp
Testkonfiguration
Mit der Testkonfiguration können Sie folgende Testtypen definieren:
| ICMP | Sendet eine ICMP-Echoanfrage (Internet Control Message Protocol) und überwacht eine Antwort. Wenn der Server eine Antwort zurückgibt, kennzeichnet ITD den Server als übergeben. |
| DNS | Sendet eine Anforderung an einen Domain Name Server (DNS), der eine konfigurierte Domäne an den Server übergibt. Wenn der Server mit einer konfigurierten IP-Adresse für diese Domäne antwortet, kennzeichnet die ITD die Adresse als aktiv. |
| udp | Sendet ein UDP-Paket an einen Server und markiert den Server nur dann als fehlgeschlagen, wenn der Server eine Meldung über den ICMP-Port nicht erreichbar zurückgibt. |
| TCP | Initiiert einen 3-Wege-TCP-Handshake und erwartet, dass der Server eine Antwort sendet. Wenn der Handshake erfolgreich ist, sendet die ITD eine FIN, um die Sitzung zu beenden. Wenn die Antwort ungültig ist oder keine Antwort erfolgt, markiert ITD den Server als fehlgeschlagen. |
Im Allgemeinen werden die DNS-, UDP- und TCP-Tests verwendet, um die Verfügbarkeit bestimmter Dienste zu bewerten, die auf den Node-Servern ausgeführt werden.
Mithilfe der Testkonfiguration können Sie außerdem folgende Parameter definieren:
- Frequenz - ITD pingt den Knoten alle x Sekunden.
- timeout - ITD erwartet eine Antwort vom Knoten innerhalb von y Sekunden.
- Wiederholungs-Downcount - die Anzahl der Versuche, um den Knoten zu überprüfen, bevor er als "Probe Fail" (Testausfall) markiert und Failure ausgeführt wird.
- Wiederholungszahl - die Anzahl der Versuche, den Knoten zu überprüfen, bevor er als "OK" markiert und dem Pool erneut hinzugefügt wird.
Betrachten Sie zum Beispiel diese Konfiguration (dies ist die Standardkonfiguration, wenn Sie probe icmp konfigurieren):
- Pingen Sie den Knoten alle 10 Sekunden.
- Warten Sie fünf Sekunden, bis der Knoten antwortet.
- Wenn der Knoten dreimal nicht antwortet, markieren Sie den Knoten als "Testfehler".
- Wenn der Knoten dreimal hintereinander antwortet, markieren Sie den Knoten als "OK".
Angesichts dieser Konfiguration reagiert ITD auf einen Knoten, der nach mindestens 35 Sekunden nicht erreichbar ist (3 x Frequenz + Timeout).
Standby-Knoten
Ein Knoten kann auf Knoten- oder Gerätegruppenebene als Standby konfiguriert werden. Ein Standby-Gerät auf Knotenebene empfängt Datenverkehr nur, wenn der zugehörige aktive Knoten ausfällt. Ein Standby auf Gerätegruppenebene empfängt Datenverkehr, wenn einer der aktiven Knoten ausfällt.
Die Standby-Konfiguration auf Geräteebene lautet:
7k-1(config-device-group)# node ip 192.168.40.100 standby 192.168.40.103
Die Standby-Konfiguration der Gerätegruppe lautet:
7k-1(config-device-group)# node ip 192.168.40.106 mode hot-standby
Schritt 2: Konfigurieren des ITD-Service
In diesem Schritt wird der ITD-Service definiert, d. h. der Datenverkehr, den Sie ausgleichen möchten, und wie.
Konfigurieren des ITD-Service
N7k-1(config)# itd TAC-ITD-service
Definieren der Gerätegruppe
Verweisen Sie auf die zuvor konfigurierte Gerätegruppe:
N7k-1(config-itd)# device-group TAC-device-group
Konfigurieren der Eingangsschnittstelle
Der Datenverkehr, der an dieser Schnittstelle eingeht, wird durch ITD ausgeglichen. Bei der Eingangsoberfläche muss es sich um eine Layer-3-Schnittstelle (physische Schnittstelle, Port-Channel oder Switched Virtual Interface (SVI)) handeln.
N7k-1(config-itd)# ingress interface vlan 20
Jede Layer-3-Schnittstelle kann nur als Eingangs-Schnittstelle für eine ITD-Instanz zugewiesen werden.
Konfigurieren der virtuellen ITD-IP-Adresse
Die virtuelle ITD-IP-Adresse (VIP) muss sich in einem anderen Subnetz befinden als die Hosts und Knoten:
N7k-1(config-itd)# virtual ip 192.168.30.1 255.255.255.255 advertise enable
Das ITD-VIP ist im Wesentlichen eine Dummy-Schnittstelle aus Nexus 7000-Perspektive. Beispielsweise reagiert der Switch nicht auf Ping-Anfragen, die an das VIP adressiert sind. Sie wird verwendet, um den Datenverkehr mit der Routenübersicht abzustimmen, die automatisch erstellt und auf die ITD-Eingangsschnittstelle angewendet wird.
Definieren der ITD-Load-Balance-Methode
load-balance method src ip buckets 2
Mit der Load Balancing-Methode können Sie Ihren Load Balancing-Hashing-Mechanismus definieren. Diese Optionen sind verfügbar:
| src ip | Quell-IP |
| src ip-l4port | Quell-IP- und L4-Port |
| dst ip | Ziel-IP |
| dst ip-l4port | Ziel-IP- und L4-Port |
Schritt 3: Definieren des Failover-Verhaltens
Sie müssen ein Failover-Verhalten konfigurieren, oder ITD reagiert nicht auf Knotenausfälle:
N7k-1(config-itd)# failaction node reassign
Um die ITD-bezogene Konfiguration anzuzeigen, geben Sie den Befehl show run services ein:
N7k-2# show run services
!Command: show running-config services
!Time: Wed Apr 22 00:15:11 2015
version 6.2(10)
feature itd
itd device-group TAC
node ip 192.168.40.100
node ip 192.168.40.101
probe icmp frequency 10 timeout 5 retry-down-count 1 retry-up-count 1
itd TEST
device-group TAC
virtual ip 192.168.30.1 255.255.255.255 advertise enable
ingress interface Vlan20
failaction node reassign
load-balance method src ip buckets 2
no shut
Schritt 4: Konfigurieren des ITD-VIP als Loopback-Schnittstelle auf Knotenservern
Damit die Server Datenverkehr an das ITD-VIP senden können, müssen sie als IP-Alias auf der Loopback-Schnittstelle des Servers konfiguriert werden. Der Server akzeptiert Anfragen für die VIP-Zieladresse und sendet die Antwort von der ITD-VIP-Adresse.
Konfigurieren der virtuellen Netzwerkschnittstelle in Linux
Installieren des Microsoft Loopback-Adapters in Windows
Weitere Konfigurationsoptionen
Weighöhe Knoten zuweisen
Mit der Lastverteilungsmethode können Sie auch festlegen, wie viele Buckets den Datenverkehr einteilen sollen. Die Bucket-Konfiguration ist optional. Standardmäßig entspricht die Anzahl der Buckets der Anzahl der konfigurierten Knoten. Wenn Sie die Anzahl der Gruppen konfigurieren möchten, muss der Wert eine Leistung von 2 (2, 4, 8, 16, 32 usw.) aufweisen. Die Konfiguration lautet wie folgt:
N7k-2(config-itd)# load-balance method src ip buckets 16
Standardmäßig werden Buckets aktiven Knoten in einem Round-Robin-Muster zugewiesen. Sie können jedoch bestimmte Knoten mit mehreren Buckets gewichten, die den Datenverkehr für ein oder mehrere Geräte gewichten. Sie weisen Gewicht unter der Gerätegruppenkonfiguration zu. In dieser Konfiguration empfängt 101 doppelt so viel Datenverkehr wie Server 100.
N7k-1(config)# itd device-group TAC-device-group
N7k-1(config-device-group)# node ip 192.168.40.100 weight 33
N7k-1(config-device-group)# node ip 192.168.40.101 weight 66
N7k-1(config-device-group)# probe icmp
Sie können die Bucket-Zuweisungen mit der Ausgabe des Befehls show itd überprüfen:
N7k-2(config-itd)# show itd
Name Probe LB Scheme Status Buckets
-------------- ----- ---------- -------- -------
TEST TCP src-ip ACTIVE 16
Device Group VRF-Name
-------------------------------------------------- -------------
TAC
Pool Interface Status Track_id
------------------------------ ------------ ------ ---------
TEST_itd_pool Vlan20 UP 3
Virtual IP Netmask/Prefix Protocol Port
------------------------------------------------------ ------------ ----------
192.168.20.1 / 255.255.255.255 IP 0
Node IP Config-State Weight Status Track_id Sla_id
------------------------- ------------ ------ ---------- --------- ---------
1 192.168.40.100 Active 33 OK 1 10001
Bucket List
-----------------------------------------------------------------------
TEST_itd_vip_1_bucket_1
TEST_itd_vip_1_bucket_3
TEST_itd_vip_1_bucket_5
TEST_itd_vip_1_bucket_7
TEST_itd_vip_1_bucket_9
TEST_itd_vip_1_bucket_16
Node IP Config-State Weight Status Track_id Sla_id
------------------------- ------------ ------ ---------- --------- ---------
2 192.168.40.101 Active 66 OK 2 10002
Bucket List
-----------------------------------------------------------------------
TEST_itd_vip_1_bucket_2
TEST_itd_vip_1_bucket_4
TEST_itd_vip_1_bucket_6
TEST_itd_vip_1_bucket_8
TEST_itd_vip_1_bucket_10
TEST_itd_vip_1_bucket_11
TEST_itd_vip_1_bucket_12
TEST_itd_vip_1_bucket_13
TEST_itd_vip_1_bucket_14
TEST_itd_vip_1_bucket_15
Konfigurieren des Fehlers
Wenn ein Knoten ausfällt, erkennt die Sonde den Knoten und setzt ihn in den Status "Probe Fail" (Fehler der Probe). Standardmäßig leitet die ITD den Datenverkehr weiter an den ausgefallenen Knoten weiter. Damit ITD den Datenverkehr von einem ausgefallenen Knoten ableiten kann, muss Folgendes konfiguriert werden:
itd TEST
failaction node reassign
Was geschieht, wenn ein Knoten nicht erreichbar ist?
- Wenn die Neuzuweisung des Failaction-Knotens konfiguriert ist, setzt ITD den nicht erreichbaren Knoten in den Test Fail-Modus und leitet den Datenverkehr an andere Knoten in der Gerätegruppe weiter.
- Wenn Failaction Node Neuzuweisung NICHT konfiguriert ist:
Szenario 1: Konfigurierter Test/Standby-Knoten: an den ersten verfügbaren Standby-Knoten weitergeleitet.
Szenario 2: Test konfiguriert, kein Standby-Knoten konfiguriert: Datenverkehr nicht neu zugewiesen, wird weitergeleitet.
Szenario 3: Keine Sonde konfiguriert: ITD kann den Ausfall nicht erkennen, der Datenverkehr wird weiterhin an einen nicht verfügbaren Knoten weitergeleitet.
- Wenn alle Knoten nicht erreichbar sind, wird der Datenverkehr geroutet.
Überprüfen
In diesem Abschnitt wird beschrieben, wie Sie die grundlegende Konfiguration und den Betrieb der ITD überprüfen.
Überprüfen von ITD-Services
Um den Status der ITD anzuzeigen, geben Sie den Befehl show itd ein.
- Überprüfen Sie, ob der Service den AKTIVEN Status hat.
- Überprüfen Sie, ob der Gerätepool im UP-Zustand ist.
- Überprüfen Sie, ob die Knoten den Status OK haben.
N7k-2(config-itd)# show itd
Name Probe LB Scheme Status Buckets
-------------- ----- ---------- -------- -------
TEST TCP src-ip ACTIVE 16
Device Group VRF-Name
-------------------------------------------------- -------------
TAC
Pool Interface Status Track_id
------------------------------ ------------ ------ ---------
TEST_itd_pool Vlan20 UP 3
Virtual IP Netmask/Prefix Protocol Port
------------------------------------------------------ ------------ ----------
192.168.20.1 / 255.255.255.255 IP 0
Node IP Config-State Weight Status Track_id Sla_id
------------------------- ------------ ------ ---------- --------- ---------
1 192.168.40.100 Active 33 OK 1 10001
Bucket List
-----------------------------------------------------------------------
TEST_itd_vip_1_bucket_1
TEST_itd_vip_1_bucket_3
TEST_itd_vip_1_bucket_5
TEST_itd_vip_1_bucket_7
TEST_itd_vip_1_bucket_9
TEST_itd_vip_1_bucket_16
Node IP Config-State Weight Status Track_id Sla_id
------------------------- ------------ ------ ---------- --------- ---------
2 192.168.40.101 Active 66 OK 2 10002
Bucket List
-----------------------------------------------------------------------
TEST_itd_vip_1_bucket_2
TEST_itd_vip_1_bucket_4
TEST_itd_vip_1_bucket_6
TEST_itd_vip_1_bucket_8
TEST_itd_vip_1_bucket_10
TEST_itd_vip_1_bucket_11
TEST_itd_vip_1_bucket_12
TEST_itd_vip_1_bucket_13
TEST_itd_vip_1_bucket_14
TEST_itd_vip_1_bucket_15
Überprüfen der dynamisch erstellten Zugriffslisten und Routenzuordnung
Diese Konfiguration wird dynamisch erstellt, wenn Sie ITD konfigurieren:
- Pro konfiguriertem Bucket gibt es eine Zugriffsliste und einen Routenzuordnungs-Eintrag.
- Routenzuordnungen und Zugriffslisten werden mit dem Namen des ITD-Diensts erstellt, dem das Präfix vorangestellt wurde (z. B. <Dienstname>_itd_vip_1_bucket_1).
N7k-2(config)# show ip access-lists
IP access list TEST_itd_vip_1_bucket_1
10 permit ip 1.1.1.0 255.255.255.127 192.168.20.1/32
IP access list TEST_itd_vip_1_bucket_2
10 permit ip 1.1.1.128 255.255.255.127 192.168.20.1/32
N7k-2(config)# sho route-map TEST_itd_pool
route-map TEST_itd_pool, permit, sequence 0
Description: auto generated route-map for ITD service TEST
Match clauses:
ip address (access-lists): TEST_itd_vip_1_bucket_1
Set clauses:
ip next-hop verify-availability 192.168.30.2 track 2 [ UP ]
route-map TEST_itd_pool, permit, sequence 1
Description: auto generated route-map for ITD service TEST
Match clauses:
ip address (access-lists): TEST_itd_vip_1_bucket_2
Set clauses:
ip next-hop verify-availability 192.168.30.2 track 2 [ UP ]
Überprüfen der Konfiguration der Eingangsschnittstelle
Überprüfen Sie, ob die Routenübersicht auf die ITD-Eingangsschnittstelle angewendet wird:
N7k-2(config-itd)# show run int vlan 20
!Command: show running-config interface Vlan20
!Time: Thu Apr 23 00:42:41 2015
version 6.2(10)
interface Vlan20no shutdown
ip address 192.168.20.1/24
ip policy route-map TEST_itd_pool
Testkonfiguration überprüfen
Stellen Sie sicher, dass die Sondenfrequenz in dieser Ausgabe über den folgenden Befehl programmiert ist:
N7k-2# show run | i probe
probe icmp frequency 5
N7k-2# show run sla sender
!Command: show running-config sla sender
!Time: Tue Apr 28 18:04:02 2015
version 6.2(10)
feature sla sender
ip sla 10001
icmp-echo 192.168.40.100
frequency 5
ip sla schedule 10001 life forever start-time now
ip sla 10002
icmp-echo 192.168.40.101
frequency 5
ip sla schedule 10002 life forever start-time now
Die Internet Protocol Service Level Agreement (IPSLA)-Objekte werden dynamisch erstellt, wenn ITD konfiguriert wird. Auf diese Objekte wird in der ITD-Routenübersicht verwiesen.
Fehlerbehebung
Für diese Konfiguration sind derzeit keine spezifischen Informationen zur Fehlerbehebung verfügbar.
Zugehörige Informationen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
04-May-2015 |
Erstveröffentlichung |
Feedback