Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
Dieses Dokument beschreibt den Konfigurationsleitfaden zur Bereitstellung von CSR1000v-Routern für Hochverfügbarkeit in der Amazon AWS Cloud. Es soll den Benutzern praktische Kenntnisse über HA und die Möglichkeit geben, ein voll funktionsfähiges Testbett bereitzustellen.
Weitere Informationen zu AWS und HA finden Sie im Abschnitt.
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
Die Informationen in diesem Dokument basieren auf Cisco IOS-XE® Denali 16.7.1.
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.
In einer Umgebung mit mehreren Verfügbarkeitszonen simulieren Sie kontinuierlichen Datenverkehr vom privaten Rechenzentrum (VM) zum Internet. Simulieren Sie einen HA-Failover, und stellen Sie fest, dass HA erfolgreich ist, da die Routing-Tabelle den Datenverkehr von CSRHA zur privaten Schnittstelle von CSRHA1 umleitet.
Vor Beginn der Konfiguration ist es wichtig, die Topologie und das Design vollständig zu verstehen. So können potenzielle Probleme später behoben werden.
Die HA-Bereitstellung hängt von den Netzwerkanforderungen ab. In diesem Beispiel wird die HA-Redundanz mit den folgenden Einstellungen konfiguriert:
Es gibt zwei CSR1000v-Router in einem HA-Paar in zwei verschiedenen Verfügbarkeitszonen. Betrachten Sie jede Verfügbarkeitszone als separates Rechenzentrum für zusätzliche Hardware-Ausfallsicherheit.
Die dritte Zone ist eine VM, die ein Gerät in einem privaten Rechenzentrum simuliert. Derzeit wird der Internetzugriff über die öffentliche Schnittstelle aktiviert, sodass Sie auf das virtuelle System zugreifen und es konfigurieren können. Im Allgemeinen sollte der gesamte normale Datenverkehr die private Routing-Tabelle durchlaufen.
Ping the VM's private interface → private route table → CSRHA → 8.8.8.8 für Traffic Simulation. In einem Failover-Szenario beobachten Sie, dass die private Routing-Tabelle die Route zu der privaten Schnittstelle von CSRHA1 umgeschaltet hat.
RTB - Die Routing-Tabelle-ID.
CIDR - Zieladresse für die Route, die in der Routing-Tabelle aktualisiert werden soll.
ENI - Die Netzwerkschnittstellen-ID der CSR 1000v-Gigabit-Schnittstelle, an die der Datenverkehr weitergeleitet wird.
Wenn z. B. CSRHA ausfällt, übernimmt CSRHA1 die Weiterleitung in der AWS-Weiterleitungstabelle und aktualisiert sie, um auf die eigene ENI zu verweisen.
REGION - Die AWS-Region CSR 1000v.
Der allgemeine Konfigurationsfluss besteht darin, mit der umfassendsten Funktion (Region/VPC) zu beginnen und den Weg bis zur spezifischsten Funktion (Schnittstelle/Subnetz) zu gehen. Es gibt jedoch keine spezifische Konfigurationsreihenfolge. Bevor Sie beginnen, ist es wichtig, zuerst die Topologie zu verstehen.
Tipp: Geben Sie Namen für alle Ihre Einstellungen (VPC, Schnittstelle, Subnetz, Routentabellen usw.).
In diesem Beispiel wird US West (Oregon) verwendet.
Sicherheitsgruppen sind wie ACLs, um Datenverkehr zuzulassen oder zu verweigern.
IAM gewährt Ihrem CSR Zugriff auf Amazon APIs.
Der CSR1000v wird als Proxy für den Aufruf von AWS API-Befehlen zum Ändern der Routing-Tabelle verwendet. Standardmäßig ist AMIs kein Zugriff auf APIs erlaubt. Bei diesem Verfahren wird eine IAM-Rolle erstellt, und diese Rolle wird beim Start einer CSR-Instanz verwendet. IAM stellt Zugriffsberechtigungen für CSRs bereit, um AWS-APIs zu verwenden und zu ändern.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:AssociateRouteTable", "ec2:CreateRoute", "ec2:CreateRouteTable", "ec2:DeleteRoute", "ec2:DeleteRouteTable", "ec2:DescribeRouteTables", "ec2:DescribeVpcs", "ec2:ReplaceRoute", "ec2:DisassociateRouteTable", "ec2:ReplaceRouteTableAssociation" ], "Resource": "*" } ] }
Jeder CSR1000v-Router hat zwei Schnittstellen (1 Public, 1 Private) und ist in einer eigenen Verfügbarkeitszone. Jeder CSR ist in separaten Rechenzentren verfügbar.
Hinweis: Das im vorherigen Schritt erstellte Subnetz wird in diesem Dropdown-Menü möglicherweise nicht angezeigt. Möglicherweise müssen Sie die Seite aktualisieren oder abbrechen und erneut starten, damit das Subnetz angezeigt wird.
Hinweis: Wenn Sie Ihren privaten Schlüssel verlieren, können Sie sich nicht erneut bei Ihrem CSR anmelden. Es gibt keine Methode zum Wiederherstellen von Schlüsseln.
Hinweis: Öffentliche/private Terminologie kann Sie hier verwirren. Für die Zwecke dieses Beispiels ist die Definition einer öffentlichen Schnittstelle Eth0, d. h. die Internet-Schnittstelle. Aus der Sicht von AWS ist unsere öffentliche Schnittstelle ihre private IP.
Standardmäßig ist diese Quell-/Ziel-Prüfung für alle ENIs aktiviert. Eine Anti-Spoofing-Funktion, die verhindern soll, dass die ENI mit Datenverkehr überlastet wird, der nicht wirklich für sie bestimmt ist, indem vor der Weiterleitung überprüft wird, ob die ENI das Ziel des Datenverkehrs ist. Der Router ist selten das tatsächliche Ziel eines Pakets. Diese Funktion muss auf allen CSR-Transit-ENIs deaktiviert sein, oder sie kann Pakete nicht weiterleiten.
Hinweis: Der von AWS für SSH im CSR1000v bereitgestellte Benutzername ist möglicherweise falsch als Root aufgeführt. Ändern Sie diese Einstellung bei Bedarf in ec2-user.
Hinweis: Sie müssen in der Lage sein, einen Ping an die DNS-Adresse zu senden, um SSH einzugeben. Hier ist es ec2-54-208-234-64.compute-1.amazonaws.com. Überprüfen Sie, ob das öffentliche Subnetz/die öffentliche Route-Tabelle mit dem Router verknüpft ist. Fahren Sie kurz mit Schritt 8 fort, wie Sie das Subnetz der Routentabelle zuordnen.
Öffentliches Subnetz: 10.16.1.0/24
Privates Subnetz: 10.16.5.0/24
Wenn Sie die elastische IP-Adresse dieser neuen AMI nicht pingen können, gehen Sie kurz zu Schritt 8, und stellen Sie sicher, dass das öffentliche Subnetz der öffentlichen Routing-Tabelle zugeordnet ist.
Verwenden Sie für dieses Beispiel Ubuntu Server 14.04 LTS auf dem Markt.
Öffentliches Subnetz: 10.16.2.0/24
Privates Subnetz: 10.16.6.0/24
Wenn Sie die elastische IP-Adresse dieser neuen AMI nicht pingen können, gehen Sie kurz zu Schritt 8, und stellen Sie sicher, dass das öffentliche Subnetz der öffentlichen Routing-Tabelle zugeordnet ist.
ubuntu@ip-10-16-2-139:~$ cd /etc/network/interfaces.d/ ubuntu@ip-10-16-2-139:/etc/network/interfaces.d$ sudo vi eth1.cfg auto eth1 iface eth1 inet static address 10.16.6.131 netmask 255.255.255.0 network 10.16.6.0 up route add -host 8.8.8.8 gw 10.16.6.1 dev eth1
ubuntu@ip-10-16-2-139:/etc/network/interfaces.d$ sudo ifdown eth1 && sudo ifup eth1 ubuntu@ip-10-16-2-139:/etc/network/interfaces.d$ sudo reboot
ubuntu@ip-10-16-2-139:~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.16.2.1 0.0.0.0 UG 0 0 0 eth0 8.8.8.8 10.16.6.1 255.255.255.255 UGH 0 0 0 eth1 <-------------- 10.16.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.16.6.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
Wenn 8.8.8.8 nicht in der Tabelle aufgeführt ist, fügen Sie sie manuell hinzu:
ubuntu@ip-10-16-2-139:~$ sudo route add -host 8.8.8.8 gw 10.16.6.1 dev eth1
Drei öffentliche Schnittstellen sind der Public Route Table zugeordnet:
Öffentliche Subnetze: 10.16.0.0/24, 10.16.1.0/24, 10.16.2.0/24
Drei private Schnittstellen sind der Private Route Table zugeordnet:
Private Subnetze: 10.16.4.0/24, 10.16.5.0/24, 10.16.6.0/24
Konfigurieren Sie den GRE-Tunnel (Generic Routing Encapsulation) über die Elastic IPs der CSR 1000v (empfohlen, um Probleme mit der DHCP-Lease-Verlängerung zu vermeiden, die Fehlfehler erkennen). Wenn eine schnellere Konvergenz erforderlich ist, können die BFD-Werte (Biderection Forwarding Detection) so konfiguriert werden, dass sie aggressiver sind als in diesem Beispiel dargestellt. Dies kann jedoch zu BFD-Peer-Down-Ereignissen bei gelegentlichen Verbindungen führen. Die Werte in diesem Beispiel erkennen Peerfehler innerhalb von 1,5 Sekunden. Zwischen der Ausführung des Befehls AWS API und dem Wirksamwerden der VPC-Routingtabelle liegt eine variable Verzögerung von etwa einigen Sekunden.
GRE und BFD - werden zur Einhaltung der Bedingungen für HA-Failover verwendet.
interface Tunnel1 ip address 192.168.1.1 255.255.255.0 bfd interval 500 min_rx 500 multiplier 3 tunnel source GigabitEthernet1 tunnel destination 52.10.183.185 /* Elastic IP of the peer CSR */ ! router eigrp 1 bfd interface Tunnel1 network 192.168.1.0 passive-interface GigabitEthernet1
NAT und Routing - wird zur Erreichbarkeit des VM-Internets über die private Schnittstelle verwendet
interface GigabitEthernet1 ip address dhcp ip nat outside no shutdown ! interface GigabitEthernet2 ip address dhcp ip nat inside no shutdown ! ip nat inside source list 10 interface GigabitEthernet1 overload ! access-list 10 permit 10.16.6.0 0.0.0.255 ! ip route 10.16.6.0 255.255.255.0 GigabitEthernet2 10.16.4.1
GRE und BFD - werden zur Einhaltung der Bedingungen für HA-Failover verwendet.
interface Tunnel1 ip address 192.168.1.2 255.255.255.0 bfd interval 500 min_rx 500 multiplier 3 tunnel source GigabitEthernet1 tunnel destination 50.112.227.77 /* Elastic IP of the peer CSR */ ! router eigrp 1 bfd interface Tunnel1 network 192.168.1.0 passive-interface GigabitEthernet1
NAT und Routing - wird zur Erreichbarkeit des VM-Internets über die private Schnittstelle verwendet
interface GigabitEthernet1 ip address dhcp ip nat outside no shutdown ! interface GigabitEthernet2 ip address dhcp ip nat inside no shutdown ! ip nat inside source list 10 interface GigabitEthernet1 overload ! access-list 10 permit 10.16.6.0 0.0.0.255 ! ip route 10.16.6.0 255.255.255.0 GigabitEthernet2 10.16.5.1
Überwachen Sie BFD-Peer-Down-Ereignisse, indem Sie jeden CSR 1000v mit dem unten angegebenen Befehl "Cloud Provider" konfigurieren. Verwenden Sie diesen Befehl, um die Routing-Änderungen an (VPC) Route-Table-ID, Network-Interface-ID und CIDR zu definieren, nachdem ein AWS HA-Fehler wie BFD Peer Down erkannt wurde.
CSR(config)# redundancy CSR(config-red)# cloud provider [aws | azure] node-id # bfd peer ipaddr # route-table table-name # cidr ip ipaddr/prefix # eni elastic-network-intf-name # region region-name
CSRHA#show bfd neighbors IPv4 Sessions NeighAddr LD/RD RH/RS State Int 192.168.1.2 4097/4097 Up Up Tu1
Konfigurationsbeispiel für Redundanz auf CSRHA
redundancy cloud provider aws 1 bfd peer 192.168.1.2 route-table rtb-ec081d94 cidr ip 8.8.8.8/32 eni eni-90b500a8 region us-west-2
Konfigurationsbeispiel für Redundanz auf CSRHA1
redundancy cloud provider aws 1 bfd peer 192.168.1.1 route-table rtb-ec081d94 cidr ip 8.8.8.8/32 eni eni-10e3a018 region us-west-2
CSRHA#show bfd nei IPv4 Sessions NeighAddr LD/RD RH/RS State Int 192.168.1.2 4097/4097 Up Up Tu1 CSRHA#show ip eigrp neighbors EIGRP-IPv4 Neighbors for AS(1) H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 0 192.168.1.2 Tu1 12 00:11:57 1 1470 0 2
CSRHA#show redundancy cloud provider aws 1 Cloud HA: work_in_progress=FALSE Provider : AWS node 1 State : idle BFD peer = 192.168.1.2 BFD intf = Tunnel1 route-table = rtb-ec081d94 cidr = 8.8.8.8/32 eni = eni-90b500a8 region = us-west-2
ubuntu@ip-10-16-3-139:~$ ping -I eth1 8.8.8.8 PING 8.8.8.8 (8.8.8.8) from 10.16.6.131 eth1: 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=50 time=1.60 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=50 time=1.62 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=50 time=1.57 ms
CSRHA(config)#int Tun1 CSRHA(config-if)#shut
show redundancy cloud provider [aws | azure] node-id debug redundancy cloud [all | trace | detail | error] debug ip http all
Auflösung: HTTP wird verwendet, um den API-Anruf vom CSR an AWS zu senden. Stellen Sie sicher, dass DNS den in Ihrer Instanz aufgelisteten DNS-Namen auflösen kann. Stellen Sie sicher, dass der HTTP-Datenverkehr nicht blockiert ist.
*May 30 20:08:06.922: %VXE_CLOUD_HA-3-FAILED: VXE Cloud HA BFD state transitioned, AWS node 1 event httpc_send_request failed *May 30 20:08:06.922: CLOUD-HA : AWS node 1 httpc_send_request failed (0x12) URL=http://ec2.us-east-2b.amazonaws.com
Auflösung: Regionenname und ENI sind in verschiedenen Netzwerken falsch konfiguriert. Region und ENI sollten sich in derselben Zone wie der Router befinden.
*May 30 23:38:09.141: CLOUD-HA : res content iov_len=284 iov_base=<?xml version="1.0" encoding="UTF-8"?> <Response><Errors><Error><Code>InvalidParameterValue</Code><Message>route table rtb-9c0000f4 and interface eni-32791318 belong to different networks</Message></Error></Errors><RequestID>af3f228c-d5d8-4b23-b22c-f6ad999e70bd</RequestID></Response>
Auflösung: IAM JSON-Rolle/Richtlinie wurde falsch erstellt oder nicht auf den CSR angewendet. Die IAM-Rolle autorisiert den CSR, API-Aufrufe durchzuführen.
*May 30 22:22:46.437: CLOUD-HA : res content iov_len=895 iov_base=<?xml version="1.0" encoding="UTF-8"?> <Response><Errors><Error><Code>UnauthorizedOperation</Code><Message>You are not authorized to perform this operation. Encoded
authorization failure message: qYvEB4MUdOB8m2itSteRgnOuslAaxhAbDph5qGRJkjJbrESajbmF5HWUR-MmHYeRAlpKZ3Jg_y-_tMlYel5l_ws8Jd9q2W8YDXBl3uXQqfW_cjjrgy9jhnGY0nOaNu65aLpfqui8kS_4RPOpm5grRFfo99-8uv_N3mYaBqKFPn3vUcSYKBmxFIIkJKcjY9esOeLIOWDcnYGGu6AGGMoMxWDtk0K8nwk4IjLDcnd2cDXeENS45w1PqzKGPsHv3wD28TS5xRjIrPXYrT18UpV6lLA_09Oh4737VncQKfzbz4tPpnAkoW0mJLQ1vDpPmNvHUpEng8KrGWYNfbfemoDtWqIdABfaLLLmh4saNtnQ_OMBoTi4toBLEb2BNdMkl1UVBIxqTqdFUVRS**MSG 00041 TRUNCATED** **MSG 00041 CONTINUATION #01**qLosAb5Yx0DrOsLSQwzS95VGvQM_n87LBHYbAWWhqWj3UfP_zmiak7dlm9P41mFCucEB3Cs4FRsFtb-9q44VtyQJaS2sU2nhGe3x4uGEsl7F1pNv5vhVeYOZB3tbOfbV1_Y4trZwYPFgLKgBShZp-WNmUKUJsKc1-6KGqmp7519imvh66JgwgmU9DT_qAZ-jEjkqWjBrxg6krw</Message></Error></Errors><RequestID>4cf31249-2a6e-4414-ae8d-6fb825b0f398</RequestID></Response>
Bereitstellungsleitfaden für Cloud Services Router der Cisco Serie CSR 1000v für Amazon Web Services