Guide de déploiement de la redondance CSR1000v HA sur Amazon AWS

Introduction

Ce document décrit le guide de configuration sur la façon de déployer des routeurs CSR1000v pour la haute disponibilité sur le cloud Amazon AWS. Il vise à donner aux utilisateurs une connaissance pratique de la haute disponibilité et la capacité de déployer un banc d'essai entièrement fonctionnel.

Pour plus d'informations sur AWS et HA, reportez-vous à la section.

  

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Un compte Amazon AWS
• 2 CSR1000v et 1 AMI Linux/Windows dans la même région
• HA version 1 est pris en charge sur Cisco IOS-XE® versions 16.5 à 16.9.  À partir de la version 16.11, utilisez HA version 3. 

Components Used

Les informations contenues dans ce document sont basées sur Cisco IOS-XE® Denali 16.7.1.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Objectif

Dans un environnement à zones de disponibilité multiples, simulez le trafic continu du data center privé (VM) vers Internet. Simulez un basculement de haute disponibilité et observez que la haute disponibilité réussit lorsque la table de routage commute le trafic de CSRHA vers l'interface privée de CSRHA1.

Topologie

Avant de commencer la configuration, il est important de bien comprendre la topologie et la conception. Cela permet de résoudre les problèmes potentiels ultérieurement.

Il existe différents scénarios de déploiement haute disponibilité en fonction des besoins du réseau. Dans cet exemple, la redondance haute disponibilité est configurée avec les paramètres suivants :

• 1x - Région
• 1x - VPC
• 3x - Zones de disponibilité
• 6x - Interfaces/sous-réseaux réseau (3x face publique/3x face privée)
• 2x - Tables de routage (publiques et privées)
• 2x - routeurs CSR1000v (Cisco IOS-XE® Denali 16.3.1a ou version ultérieure)
• 1x - VM (Linux/Windows)

Une paire haute disponibilité comprend deux routeurs CSR1000v, dans deux zones de disponibilité différentes. Considérez chaque zone de disponibilité comme un data center distinct pour une résilience matérielle supplémentaire.

La troisième zone est une machine virtuelle qui simule un périphérique dans un data center privé. Pour l'instant, l'accès à Internet est activé via l'interface publique sur afin que vous puissiez accéder à la machine virtuelle et la configurer. En général, tout le trafic normal doit transiter par la table de routage privé. 

Envoyez une requête ping à l'interface privée de la VM → table de routage privé → CSRHA → 8.8.8.8 pour la simulation du trafic. Dans un scénario de basculement, observez que la table de routage privé a commuté la route vers l'interface privée de CSRHA1.

Diagramme du réseau

Terminologie

RTB : ID de la table de routage.

CIDR : adresse de destination de la route à mettre à jour dans la table de routage.

ENI : ID d'interface réseau de l'interface Gigabit CSR 1000v vers laquelle le trafic est acheminé.
Par exemple, si CSRHA échoue, CSRHA1 prend le relais et met à jour la route dans la table de route AWS pour pointer vers son propre ENI.

REGION - Région AWS de CSR 1000v.

Restrictions

• Pour les sous-réseaux privés, n'utilisez pas l'adresse IP 10.0.3.0/24, qui est utilisée en interne sur le routeur Cisco CSR 1000v pour la haute disponibilité. Le routeur Cisco CSR 1000v doit disposer d'une accessibilité Internet publique pour effectuer des appels REST API qui modifient la table de routage AWS.
  
  
• Ne placez pas l'interface gig1 du routeur CSR1000v dans un VRF.  La haute disponibilité ne fonctionne pas autrement.

Configuration

Le flux général de configuration doit commencer par la fonctionnalité la plus englobante (Région/VPC) et descendre jusqu'à la fonctionnalité la plus spécifique (Interface/sous-réseau). Cependant, il n'existe pas d'ordre de configuration spécifique. Avant de commencer, il est important de bien comprendre la topologie.

Astuce : Donnez des noms à tous vos paramètres (VPC, Interface, Sous-réseau, Tables de routage, etc.).

Étape 1. Choisissez une région.

Cet exemple utilise US West (Oregon).

Étape 2 : création d’un VPC

1. Sur la console AWS, accédez à VPC > Tableau de bord VPC > Démarrer l'Assistant VPC.

   

2. Sélectionnez VPC avec un sous-réseau public unique.

   

3. Lorsque vous créez un VPC, un réseau /16 vous est affecté pour être utilisé comme vous le souhaitez.
   
   
4. Un sous-réseau public /24 vous est également attribué. Les instances de sous-réseau public utilisent des adresses IP élastiques ou des adresses IP publiques pour que vos périphériques puissent accéder à Internet.

   

5. vpc-b98d8ec0 est créé.

   

Étape 3 : création d’un groupe de sécurité pour le VPC

Les groupes de sécurité sont comme des listes de contrôle d’accès pour autoriser ou refuser le trafic.

1. Sous Sécurité, cliquez sur Groupes de sécurité et créez votre groupe de sécurité associé au VPC créé ci-dessus nommé HA. 

   

2. Sous Inbound Rules, définissez le trafic que vous souhaitez autoriser pour sg-1cf47d6d. Dans cet exemple, vous autorisez tout le trafic.

   

Étape 4. Créez un rôle IAM avec une stratégie et associez-le au VPC. 

IAM accorde à votre CSR l'accès aux API Amazon.

Le routeur CSR1000v est utilisé comme proxy pour appeler les commandes de l'API AWS afin de modifier la table de routage. Par défaut, les AMI ne sont pas autorisés à accéder aux API. Cette procédure crée un rôle IAM qui est utilisé lors du lancement d'une instance CSR. IAM fournit les informations d'identification d'accès permettant aux CSR d'utiliser et de modifier les API AWS.

1. Créer un rôle IAM. Accédez au tableau de bord IAM et accédez à Rôles > Créer un rôle, comme illustré dans l'image.

   

2. Comme l'illustre l'image, autorisez l'instance EC2 à appeler AWS en votre nom.

   

3. Créez un rôle et cliquez sur Suivant : Vérifiez, comme le montre l'image.

   

4. Donnez-lui un nom de rôle. Pour cet exemple, comme le montre l'image, le nom du rôle est routetablechange.

   

5. Ensuite, vous devez créer une stratégie et l'associer au rôle que vous avez créé ci-dessus. Tableau de bord IAM et accédez à Politiques > Créer une politique.

   

   {
   "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. Donnez-lui un nom de stratégie et associez-le au rôle que vous avez créé. Dans cet exemple, le nom de la stratégie est CSRHA avec accès administrateur, comme illustré dans l'image.

   

7. Comme l'illustre l'image, associez la stratégie au rôle que vous avez créé appelé routetablechange.

   

8. Résumé.

   

Étape 5. Lancez les CSR1000v avec le rôle AMI que vous avez créé et associez les sous-réseaux publics/privés.

Chaque routeur CSR1000v possède 2 interfaces (1 publique, 1 privée) et se trouve dans sa propre zone de disponibilité. Vous pouvez penser que chaque CSR se trouve dans des data centers distincts.

1. Sur la console AWS, sélectionnez EC2, puis cliquez sur Launch Instance.

   

2. Sélectionnez AWS Marketplace.

   

3. Entrez CSR1000v et, dans cet exemple, utilisez le routeur de services cloud Cisco (CSR) 1000V - BYOL pour des performances maximales.

   

4. Sélectionnez un type d'instance. Dans cet exemple, le type sélectionné est t2.medium.

   

5. Lorsque l'instance est configurée, vous devez vous assurer de sélectionner le VPC que vous avez créé ci-dessus avec le rôle IAM ci-dessus. En outre, créez un sous-réseau privé que vous associez à l'interface privée.

   

6. Cliquez sur Create new Subnet for Private Subnet. Dans cet exemple, la balise Name est HA Private. Assurez-vous qu'il se trouve dans la même zone de disponibilité que le sous-réseau public.

   

7. Faites défiler vers le bas et sous Configurer les détails de l'instance, cliquez sur Ajouter un périphérique, comme illustré dans l'image.

     

   

8. Une fois l'interface secondaire ajoutée, associez le sous-réseau privé que vous avez créé appelé HA Private. Eth0 est l'interface publique et Eth1 est l'interface privée.

   Note: Le sous-réseau créé à l'étape précédente peut ne pas apparaître dans cette liste déroulante. Vous devrez peut-être actualiser ou annuler la page et recommencer pour que le sous-réseau apparaisse.

   

9. Sélectionnez le groupe de sécurité que vous avez créé sous VPC et assurez-vous que les règles sont correctement définies.

    

10. Créez une nouvelle paire de clés et assurez-vous de télécharger votre clé privée. Vous pouvez réutiliser une clé pour chaque périphérique.  

    Note: Si vous perdez votre clé privée, vous ne pourrez plus vous connecter à votre CSR. Il n'existe aucune méthode de récupération des clés.

    

    

11. Associez l'IP élastique à l'ENI de l'interface publique pour l'instance que vous avez créée et accédez à AWS console > EC2 Management > Network Security > Elastic IP's.

    Note: La terminologie publique/privée peut vous dérouter ici. Pour les besoins de cet exemple, la définition d'une interface publique est Eth0, qui est l'interface Internet. Du point de vue d'AWS, notre interface publique est leur adresse IP privée.

    

    

12. Désactivez Source/Dest Check lorsque vous accédez à EC2 > Network Interfaces. Vérifiez chaque ENI pour le contrôle Source/Dest.

    Par défaut, cette vérification de la source/destination est activée pour tous les ENI. Fonction anti-usurpation destinée à éviter qu'un ENI soit submergé par du trafic qui n'est pas réellement destiné à lui en vérifiant que l'ENI est la destination du trafic avant de le transmettre. Le routeur est rarement la destination réelle d’un paquet. Cette fonctionnalité doit être désactivée sur tous les ENI de transit CSR ou elle ne peut pas transférer de paquets.

    

13. Connectez-vous à votre routeur CSR1000v.

    Note: Le nom d'utilisateur fourni par AWS à SSH dans le CSR1000v peut être incorrectement répertorié comme racine. Remplacez-le par ec2-user si nécessaire.

    Note: Vous devez pouvoir envoyer une requête ping à l'adresse DNS vers SSH dans. Le voici : ec2-54-208-234-64.compute-1.amazonaws.com. Vérifiez que le sous-réseau/eni public du routeur est associé à la table de routage publique. Passez brièvement à l’étape 8 pour savoir comment associer le sous-réseau à la table de routage.

    

Étape 6. Répétez l'étape 5 et créez la deuxième instance CSR1000v pour HA.

Sous-réseau public :  10.16.1.0/24

Sous-réseau privé : 10.16.5.0/24

Si vous ne parvenez pas à envoyer une requête ping à l’adresse IP élastique de ce nouvel AMI, passez brièvement à l’étape 8 et vérifiez que le sous-réseau public est associé à la table de routage public.

Étape 7. Répétez l'étape 5 et créez une machine virtuelle (Linux/Windows) à partir d'AMI Marketplace.

Pour cet exemple, utilisez Ubuntu Server 14.04 LTS sur le marché.

Sous-réseau public :  10.16.2.0/24

Sous-réseau privé : 10.16.6.0/24

Si vous ne parvenez pas à envoyer une requête ping à l’adresse IP élastique de ce nouvel AMI, passez brièvement à l’étape 8 et vérifiez que le sous-réseau public est associé à la table de routage public.

1. Eth0 est créé par défaut pour l'interface publique. Créez une deuxième interface appelée eth1 pour le sous-réseau privé. 

   

2. L'adresse IP que vous configurez dans Ubuntu est l'interface privée eth1 attribuée par AWS.

   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. Effleurez l'interface ou redémarrez la machine virtuelle.

   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. Envoyez une requête ping 8.8.8.8 pour le test. Assurez-vous que la route 8.8.8.8 a été ajoutée à l'étape 7.

   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

     

   Si 8.8.8.8 n'est pas répertorié dans le tableau, ajoutez-le manuellement :

   ubuntu@ip-10-16-2-139:~$ sudo route add -host 8.8.8.8 gw 10.16.6.1 dev eth1

Étape 8 : configuration des tables de routage privée et publique

1. Lorsqu’un VPC est créé via l’assistant à l’étape 2, deux tables de routage sont automatiquement créées. S'il n'existe qu'une seule table de routage, créez-en une autre pour vos sous-réseaux privés, comme illustré dans l'image. 

   
   

   

2. Voici une vue des deux tables de routage. La passerelle Internet (igw-95377973) est automatiquement associée à la table de routage PUBLIC. Étiquetez ces deux tableaux en conséquence. La table PRIVATE NE doit PAS avoir cette route.

   

3. Associez les 6 sous-réseaux à la table de routage appropriée

   3 Les interfaces publiques sont associées à la table de routage publique :

   Sous-réseaux publics : 10.16.0.0/24, 10.16.1.0/24, 10.16.2.0/24

     

   3 Les interfaces privées sont associées à la table de routage privé :

   Sous-réseaux privés : 10.16.4.0/24, 10.16.5.0/24, 10.16.6.0/24

   

Étape 9 : configuration de la traduction d’adresses de réseau (NAT) et du tunnel GRE avec BFD et tout protocole de routage

Configurez le tunnel GRE (Generic Routing Encapsulation) via les adresses IP élastiques des routeurs CSR 1000v (recommandé pour éviter les problèmes de renouvellement de bail DHCP, qui détectent les erreurs). Les valeurs BFD (Biderection Forwarding Detection) peuvent être configurées pour être plus agressives que celles indiquées dans cet exemple, si une convergence plus rapide est requise. Cependant, cela peut entraîner des événements d'homologue inactif BFD pendant une connectivité intermittente. Les valeurs de cet exemple détectent une défaillance d'homologue dans un délai de 1,5 seconde. Il existe un délai variable d’environ quelques secondes entre l’exécution de la commande AWS API et l’entrée en vigueur des modifications de la table de routage VPC.

• Configuration sur CSRHA

GRE et BFD : utilisés pour observer les conditions de basculement haute disponibilité

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 et routage : utilisés pour l'accessibilité Internet des VM via l'interface privée

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

• Configuration sur CSRHA1

GRE et BFD : utilisés pour observer les conditions de basculement haute disponibilité

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 et routage : utilisés pour l'accessibilité Internet des VM via l'interface privée

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

Étape 10. Configuration de la haute disponibilité (Cisco IOS XE Denali 16.3.1a ou version ultérieure) 

Surveillez les événements d'homologue BFD en configurant chaque CSR 1000v à l'aide de la commande aws du fournisseur cloud spécifiée ci-dessous. Utilisez cette commande pour définir les modifications de routage vers (VPC) Route-table-id, Network-interface-id et CIDR après la détection d'une erreur AWS HA, telle que BFD peer down.

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. L'adresse IP de l'homologue #bfd est l'adresse IP du tunnel homologue.

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

2. Le nom de table #route-table se trouve sous la console AWS, naviguez vers VPC > Tables de routage. Cette action modifie la table de routage privée.

   

3. L'adresse/préfixe #cidr ip ipaddr est l'adresse de destination de la route à mettre à jour dans la table de routage. Sous la console AWS, accédez à VPC > Tables de routage. Faites défiler vers le bas, cliquez sur Edit, puis sur Add another route. Ajoutez l'adresse de destination de test 8.8.8.8 et l'ENI privé de la CSRHA.  

   

   

4. Le nom #eni elastique-network-intf-name se trouve dans votre instance EC2. Cliquez sur votre interface privée eth1 pour chacun des CSR correspondants et utilisez l'ID d'interface.

   

5. Le nom #region est le nom de code trouvé dans le document AWS. Cette liste peut être modifiée ou étendue. Pour trouver les dernières mises à jour, consultez le document Région et zones de disponibilité d'Amazon.

Exemple de configuration de redondance sur 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

Exemple de configuration de redondance sur 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

Vérifier la haute disponibilité

1. Vérifiez les configurations BFD et cloud.

   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. Exécutez une requête ping continue de la machine virtuelle vers la destination. Assurez-vous que la requête ping passe par l’interface privée eth1.

   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. Vérifiez la table de routage privé. L'interface eni est actuellement l'interface privée de CSRHA où il s'agit du trafic.

   

4. Arrêtez Tunnel1 de CSRHA pour simuler un basculement HA.

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

5. Notez que la table de routage pointe vers la nouvelle interface ENI qui est l'interface privée de CSRHA1.

Dépannage

• Assurez-vous que les ressources sont associées. Lors de la création de VPC, de sous-réseaux, d'interfaces, de tables de routage, etc., bon nombre de ces éléments ne sont pas associés automatiquement. Ils ne se connaissent pas. 
  
• Assurez-vous que l'adresse IP élastique et toute adresse IP privée sont associées aux interfaces appropriées, avec les sous-réseaux appropriés, ajoutées à la table de routage appropriée, connectées au routeur approprié et au VPC et à la zone appropriés, associées au rôle IAM et aux groupes de sécurité.

• Désactivez le contrôle de la source/destination par ENI.

• Pour Cisco IOS XE 16.3.1a ou version ultérieure, il s'agit des commandes de vérification supplémentaires disponibles.  

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

• Voici les échecs courants observés dans les débogages :

Problème : httpc_send_request a échoué

Résolution : Le protocole HTTP est utilisé pour envoyer l'appel d'API du CSR à AWS. Assurez-vous que DNS peut résoudre le nom DNS répertorié dans votre instance. Assurez-vous que le trafic http n'est pas bloqué.

*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

Problème : la table de routage rtb-9c000f4 et l'interface eni-32791318 appartiennent à des réseaux différents

Résolution : Le nom de la région et l'ENI sont incorrectement configurés dans différents réseaux. Region et ENI doivent se trouver dans la même zone que le routeur.

*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>

Problème : Vous n'êtes pas autorisé à effectuer cette opération. Message d'échec d'autorisation codé.

Résolution : Rôle/stratégie JSON IAM créé de manière incorrecte ou non appliqué au CSR. Le rôle IAM autorise le CSR à effectuer des appels API.

*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>

  

Informations connexes

• Redondance de la passerelle VPC - Cisco

• Guide de déploiement des routeurs de services cloud de la gamme Cisco CSR 1000v pour les services Web Amazon

• Répartition des types d'instance
• EC2 et VPC
• Interfaces réseau élastiques, du guide de l’utilisateur d’EC2, avec le nombre d’ENI par type d’instance
• Mise en réseau améliorée sous Linux : conseils pratiques, informations de base utiles
• Explication des instances/locataires dédiés et procédures
• Documentation générale EC2
• Documentation générale VPC
• Régions et zones de disponibilité
• CSR1000v Haute disponibilité version 3