CSR1000v HA Redundancy Deployment Guide on Amazon AWS

Einführung

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.

  

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

• Ein Amazon AWS-Konto
• 2 CSR1000v und 1 Linux/Windows AMIs in derselben Region
• HA-Version 1 wird von Cisco IOS-XE® Versionen 16.5 bis 16.9 unterstützt.  Verwenden Sie ab 16.11 HA Version 3. 

Verwendete Komponenten

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.

Ziel

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.

Topologie

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:

• 1x - Region
• 1x - VPC
• 3x - Verfügbarkeitszonen
• 6x - Netzwerkschnittstellen/Subnetze (3x öffentliche/3x private Ausrichtung)
• 2x - Routentabellen (öffentlich und privat)
• 2x - CSR1000v-Router (Cisco IOS-XE^® Denali 16.3.1a oder höher)
• 1x - VM (Linux/Windows)

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.

Netzwerkdiagramm

Terminologie

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.

Einschränkungen

• Verwenden Sie für private Subnetze nicht die IP-Adresse 10.0.3.0/24. Diese wird intern auf dem Cisco CSR 1000v verwendet, um eine hohe Verfügbarkeit zu gewährleisten. Der Cisco CSR 1000v muss über öffentliche Internetzugänge verfügen, um REST-API-Anrufe zu tätigen, die die AWS-Routing-Tabelle ändern.
  
  
• Stellen Sie die Gig1-Schnittstelle des CSR1000v nicht in eine VRF-Instanz ein.  HA funktioniert anders nicht.

Konfiguration

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.).

Schritt 1: Wählen Sie eine Region aus.

In diesem Beispiel wird US West (Oregon) verwendet.

Schritt 2: Erstellen Sie einen vPC.

1. Navigieren Sie in der AWS-Konsole zu VPC > VPC Dashboard > Start VPC Wizard.

   

2. Wählen Sie VPC mit einem einzelnen öffentlichen Subnetz aus.

   

3. Wenn Sie einen vPC erstellen, wird Ihnen ein /16-Netzwerk zugewiesen, das wie gewünscht verwendet wird.
   
   
4. Ihnen wird auch ein öffentliches /24-Subnetz zugewiesen. Öffentliche Subnetzinstanzen verwenden Elastische IPs oder öffentliche IPs für den Internetzugriff Ihrer Geräte.

   

5. vpc-b98d8ec0 wird erstellt.

   

Schritt 3: Erstellen Sie eine Sicherheitsgruppe für den VPC.

Sicherheitsgruppen sind wie ACLs, um Datenverkehr zuzulassen oder zu verweigern.

1. Klicken Sie unter Sicherheit auf Sicherheitsgruppen und Erstellen Sie Ihre Sicherheitsgruppe, die dem oben erstellten vPC mit dem Namen HA zugeordnet ist. 

   

2. Legen Sie unter Eingehende Regeln fest, welcher Datenverkehr für sg-1cf47d6d zugelassen werden soll. In diesem Beispiel lassen Sie den gesamten Datenverkehr zu.

   

Schritt 4: Erstellen Sie eine IAM-Rolle mit einer Richtlinie, und ordnen Sie sie dem VPC zu. 

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.

1. Erstellen Sie die IAM-Rolle. Navigieren Sie zum IAM-Dashboard, und navigieren Sie zu Roles > Create Role (Rollen > Rolle erstellen), wie im Bild gezeigt.

   

2. Wie im Bild gezeigt, lassen Sie zu, dass die EC2-Instanz AWS in Ihrem Namen anruft.

   

3. Erstellen Sie eine Rolle, und klicken Sie auf Weiter: Prüfen, wie im Bild gezeigt.

   

4. Geben Sie ihm einen Namen für die Rolle. In diesem Beispiel ist, wie im Bild gezeigt, der Rollenname routetemäßig zu ändern.

   

5. Als Nächstes müssen Sie eine Richtlinie erstellen und sie der zuvor von Ihnen erstellten Rolle hinzufügen. IAM-Dashboard, und navigieren Sie zu Richtlinien > Richtlinien erstellen.

   

   {
   "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": "*"
   }
   ]
   }

   

6. Geben Sie ihm einen Richtliniennamen und fügen Sie ihn der von Ihnen erstellten Rolle hinzu. In diesem Beispiel wird der Richtlinienname CSRHA mit Administratorzugriff genannt, wie im Bild gezeigt.

   

7. Wie im Bild gezeigt, hängen Sie die Richtlinie an die von Ihnen erstellte Rolle an, die als routetfähige Änderung bezeichnet wird.

   

8. Zusammenfassung

   

Schritt 5: Starten Sie die CSR1000v-Module mit der von Ihnen erstellten AMI-Rolle, und ordnen Sie die öffentlichen/privaten Subnetze zu.

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.

1. Wählen Sie in der AWS-Konsole EC2 aus und klicken Sie dann auf Instanz starten.

   

2. Wählen Sie AWS Marketplace aus.

   

3. Geben Sie CSR1000v ein, und in diesem Beispiel verwenden Sie den Cisco Cloud Services Router (CSR) 1000V - BYOL für maximale Leistung.

   

4. Wählen Sie einen Instanztyp aus. In diesem Beispiel ist der ausgewählte Typ t2.medium.

   

5. Wenn die Instanz konfiguriert ist, müssen Sie sicherstellen, dass Sie den oben erstellten VPC und die obige IAM-Rolle auswählen. Erstellen Sie zusätzlich ein privates Subnetz, das Sie der privaten Schnittstelle zuordnen.

   

6. Klicken Sie auf Neues Subnetz für privates Subnetz erstellen. In diesem Beispiel ist das Name-Tag HA Private. Stellen Sie sicher, dass sich das Gerät in derselben Verfügbarkeitszone wie das öffentliche Subnetz befindet.

   

7. Blättern Sie nach unten, und klicken Sie unter Configure Instance Details (Instanzdetails konfigurieren) auf Add Device (Gerät hinzufügen), wie im Bild gezeigt.

     

   

8. Wenn die sekundäre Schnittstelle hinzugefügt wurde, ordnen Sie das von Ihnen erstellte private Subnetz mit dem Namen HA Private zu. Eth0 ist die öffentliche, Eth1 die private Schnittstelle.

   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.

   

9. Wählen Sie die Sicherheitsgruppe aus, die Sie unter VPC erstellt haben, und stellen Sie sicher, dass die Regeln korrekt definiert sind.

    

10. Erstellen Sie ein neues Schlüsselpaar, und stellen Sie sicher, dass Sie Ihren privaten Schlüssel herunterladen. Sie können für jedes Gerät einen Schlüssel wiederverwenden.  

    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.

    

    

11. Ordnen Sie die Elastic IP der ENI der öffentlichen Schnittstelle für die von Ihnen erstellte Instanz zu, und navigieren Sie zu AWS-Konsole > EC2 Management > Network Security > Elastic IP's.

    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.

    

    

12. Deaktivieren Sie die Quell-/Ziel-Prüfung, wenn Sie zu EC2 > Network Interfaces (EC2 > Netzwerkschnittstellen) navigieren. Überprüfen Sie alle ENIs auf Quell-/Zielprüfung.

    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.

    

13. Stellen Sie eine Verbindung zum CSR1000v her.

    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.

    

Schritt 6: Wiederholen Sie Schritt 5, und erstellen Sie die zweite CSR1000v-Instanz für HA.

Ö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.

Schritt 7: Wiederholen Sie Schritt 5, und erstellen Sie eine VM (Linux/Windows) aus dem AMI Marketplace.

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.

1. Eth0 wird standardmäßig für die öffentliche Schnittstelle erstellt. Erstellen Sie eine zweite Schnittstelle mit dem Namen eth1 für das private Subnetz. 

   

2. Die IP-Adresse, die Sie in Ubuntu konfigurieren, ist die private eth1-Schnittstelle, die von AWS zugewiesen wurde.

   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

3. Klappen Sie die Schnittstelle, oder starten Sie das virtuelle System neu.

   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

4. Ping 8.8.8.8 für den Test. Stellen Sie sicher, dass die 8.8.8.8-Route gemäß Schritt 7 hinzugefügt wurde.

   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

Schritt 8: Konfigurieren der Tabellen für private und öffentliche Routen

1. Wenn in Schritt 2 ein VPC über den Assistenten erstellt wird, werden automatisch zwei Routentabellen erstellt. Wenn es nur eine Routentabelle gibt, erstellen Sie eine weitere für Ihre privaten Subnetze, wie im Bild gezeigt. 

   
   

   

2. Hier sehen Sie eine Ansicht der beiden Routentabellen. In der Tabelle für die PUBLIC-Route ist das Internet-Gateway (igw-95377973) automatisch angeschlossen. Kennzeichnen Sie diese beiden Tabellen entsprechend. Die PRIVATE-Tabelle sollte diese Route NICHT aufweisen.

   

3. Ordnen Sie alle 6 Subnetze der entsprechenden Routentabelle zu.

   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

   

Schritt 9: Konfigurieren Sie Network Address Transaltion (NAT) und GRE Tunnel mit BFD und einem beliebigen Routing-Protokoll.

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.

• Konfiguration auf CSRHA

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

• Konfiguration auf CSRHA1

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

Schritt 10: Konfigurieren Sie die hohe Verfügbarkeit (Cisco IOS XE Denali 16.3.1a oder höher). 

Ü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

1. Der #bfd Peer-ipadr ist die IP-Adresse des Peer-Tunnels.

   CSRHA#show bfd neighbors
   
   IPv4 Sessions
   NeighAddr LD/RD RH/RS State Int
   192.168.1.2 4097/4097 Up Up Tu1

2. Den Tabellennamen für die #route-table finden Sie unter der AWS-Konsole. Navigieren Sie zu VPC > Route Tables. Diese Aktion ändert die private Routentabelle.

   

3. Das #cidr ip ipadr/prefix ist die Zieladresse für die Route, die in der Routentabelle aktualisiert werden soll. Navigieren Sie unter AWS-Konsole zu VPC > Route Tables. Blättern Sie nach unten, klicken Sie auf Bearbeiten und dann auf Weitere Route hinzufügen. Fügen Sie unsere Testzieladresse 8.8.8.8 und die private ENI von CSRHA hinzu.  

   

   

4. Der #eni elastischer-network-intf-name ist in Ihrer EC2-Instanz enthalten. Klicken Sie auf die private Schnittstelle eth1 für die jeweiligen CSRs und verwenden Sie die Interface ID.

   

5. Der Name der #Region ist der im AWS-Dokument enthaltene Codename. Diese Liste kann sich ändern oder vergrößern. Aktuelle Informationen finden Sie im Dokument Region und Verfügbarkeitszonen von Amazon.

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

Überprüfen der Hochverfügbarkeit

1. Überprüfen Sie BFD- und Cloud-Konfigurationen.

   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

2. Führen Sie einen kontinuierlichen Ping von der VM zum Ziel aus. Stellen Sie sicher, dass der Ping über die private eth1-Schnittstelle gesendet wird.

   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

3. Überprüfen Sie die private Routentabelle. Das eni ist derzeit die private Schnittstelle von CSRHA, wobei es sich um den Datenverkehr handelt.

   

4. Fahren Sie Tunnel1 von CSRHA herunter, um ein HA-Failover zu simulieren.

   CSRHA(config)#int Tun1
   CSRHA(config-if)#shut

5. Beachten Sie, dass die Routentabelle auf die neue ENI verweist, die die private Schnittstelle von CSRHA1 ist.

Fehlerbehebung

• Stellen Sie sicher, dass Ressourcen zugeordnet sind. Beim Erstellen von VPC, Subnetzen, Schnittstellen, Routentabellen usw. werden viele dieser Tabellen nicht automatisch miteinander verknüpft. Sie kennen einander nicht. 
  
• Stellen Sie sicher, dass die Elastische IP-Adresse und jede private IP-Adresse den richtigen Schnittstellen (mit den richtigen Subnetzen) zugeordnet ist, die der richtigen Routing-Tabelle hinzugefügt wurden, mit dem richtigen Router verbunden sind und mit dem richtigen VPC und der richtigen Zone verbunden sind, die mit der IAM-Rolle und den Sicherheitsgruppen verknüpft sind.

• Deaktivieren Sie die Quell-/Ziel-Prüfung pro ENI.

• Für Cisco IOS XE 16.3.1a oder höher sind dies die zusätzlichen Prüfbefehle.  

show redundancy cloud provider [aws | azure] node-id
debug redundancy cloud [all | trace | detail | error]
debug ip http all

• Im Folgenden sind häufig auftretende Fehler aufgeführt, die beim Debuggen auftreten:

Problem: httpc_send_request ist fehlgeschlagen

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

Problem: Routing-Tabelle rtb-9c0000f4 und Schnittstelle eni-32791318 gehören zu verschiedenen Netzwerken

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>

Problem: Sie sind nicht autorisiert, diesen Vorgang auszuführen. Nachricht für verschlüsselte Autorisierungsfehler.

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>

  

Zugehörige Informationen

• VPC-Gateway-Redundanz - Cisco

• Bereitstellungsleitfaden für Cloud Services Router der Cisco Serie CSR 1000v für Amazon Web Services

• Instanztypen-Aufschlüsselung
• EC2 und VPCs
• Elastische Netzwerkschnittstellen (Elastic Network Interfaces), im EC2 User Guide, enthalten Anzahl der ENIs pro Instanzentyp
• Enhanced Networking auf Linux-Anleitungen, nützliche Hintergrundinformationen
• Dedizierte Instanzen/Tenancy-Erklärung und Anleitung
• Allgemeine EC2-Dokumentation
• Allgemeine VPC-Dokumentation
• Regionen und Verfügbarkeitszonen
• CSR1000v Hochverfügbarkeitsversion 3