Introduction

Virtual Connect est une option supplémentaire pour la connectivité du Cloud à l’instance dédiée Webex Calling (Instance dédiée). Virtual Connect permet aux clients d’étendre en toute sécurité leur réseau privé sur Internet en utilisant un VPN IP point à point. Cette option de connectivité offre une installation rapide de la connexion réseau privée en utilisant l’équipement clientèle sur site (CPE) et la connectivité Internet existante.

Cisco héberge, gère et assure le VPN IP redondant et l’accès Internet requis dans la/les région(s) des centres de données dédiés de Cisco où le service est requis. De même, les administrateurs sont responsables de leurs services CPE et Internet correspondants qui sont requis pour l’installation de Virtual Connect.

Chaque ordre Virtual Connect dans une région d’instance dédiée particulière comprend deux algorithmes de routage génériques (GRE) protégés par un chiffrement IPSec (GRE sur IPSec), un à chaque centre de données Cisco dans la région sélectionnée.

Virtual Connect a une limite de bande passante de 250 Mbps par tunnel et est recommandé pour les déploiements plus petits. Puisque deux VPN point à point sont utilisés tout le trafic vers le Cloud doit passer par l’en-tête du client CPE, et il peut donc ne pas être approprié lorsqu’il y a beaucoup de sites distants. Pour d’autres options de peering (peering), reportez-vous à connectivité sur le Cloud.

Avant de soumettre la demande de peering pour Virtual Connect, assurez-vous que le service d'instance dédiée est activé dans cette région respective.

Conditions préalables

Les prérequis pour l’établissement de Virtual Connect incluent :

  • Le client fournit

    • Connexion Internet avec bande passante disponible suffisante pour prendre en charge le déploiement

    • Adresse(s) IP publique(s) pour deux IPSec

    • Adresses IP de transport GRE côté client pour les deux GRE

  • Partenaire et Client

    • Travaillez ensemble pour évaluer les besoins en bande passante

    • Assurez-vous que le(s) périphérique(s) réseau(s) Border Gateway Protocol de routage (BGP) et une conception de tunnel GRE sur IPSec

  • Le partenaire ou le client fournit

    • Équipe réseau avec connaissance des technologies de tunnel VPN de site à site

    • Une équipe réseau approfondie des principes de BGP, eBGP et de routage général

  • Cisco

    • Cisco a attribué des numéros de système auto-annonce privés (ASN) et une adresse IP transitoire pour les interfaces tunnel GRE

    • Cisco a attribué un réseau de classe C (/24) public mais pas Internet routable pour l’adresse Dedicated Instance Cloud

Si un client a uniquement 1 périphérique CPE, alors le 2 vers les centres de données Cisco (DC1 et DC2) dans chaque région, seront de ce périphérique CPE. Le client a également une option pour 2 périphériques CPE, chaque périphérique CPE doit se connecter au tunnel 1 uniquement vers les centres de données de Cisco (DC1 et DC2) dans chaque région. Une redondance supplémentaire peut être réalisée en terminant chaque tunnel dans un site physique séparé/emplacement dans l’infrastructure du client.

Détails techniques

Modèle de déploiement

Virtual Connect utilise une architecture de fin à deux niveaux, où les avions de routage et de contrôle GRE sont fournis par un périphérique et le plan de contrôle IPSec est fourni par un autre.

Une fois la connectivité Virtual Connect terminée, deux GRE sur IPSec seront créés entre le réseau d’entreprise du client et les centres de données de l’instance dédiée Cisco. Un à chaque centre de données redondant dans la région respective. Les éléments réseau supplémentaires requis pour l’peering sont échangés par le partenaire ou le client avec Cisco via le formulaire d’activation Control Hub Virtual Connect.

La figure ci-dessous montre l’exemple du modèle de déploiement de connexion virtuelle pour l’option à 2 concentrateurs côté client.

Virtual Connect - VPN est une conception de concentrateur, où les sites du concentrateur du client sont connectés au CD1 et au CD2 des centres de données de l’instance dédiée dans une région particulière.

Deux sites Hub sont recommandés pour une meilleure redondance, mais le site One Hub avec deux autres sites est également un modèle de déploiement pris en charge.

La bande passante par tunnel est limitée à 250 Mbps. Pour garantir un basculement efficace, le trafic combiné sur les deux tunnels ne doit pas dépasser 250 Mbps, car tout le trafic sera acheminé via un seul tunnel en cas de panne.

Les sites distants du client dans la même région, auraient besoin de se connecter au(s) site(s) du concentrateur sur la réseau WAN du client et Cisco n’est pas responsable de cette connectivité.

Les partenaires sont censés travailler en étroite collaboration avec les clients, en veillant à ce que le chemin le plus optimal soit choisi pour la région de service Virtual Connect.

La figure ci-dessous montre les régions d’appairage de connectivité cloud de l’instance dédiée.

Régions de connexion virtuelles

Routage

Le routage pour l’add-on Virtual Connect est implémenté en utilisant le BGP (eBGP) externe entre l’instance dédiée et l’équipement du client sur site (CPE). Cisco publiera leur réseau respectif pour chaque CD redondant dans une région vers l’IE du client et celui-ci est requis pour publier un route par défaut vers Cisco.

  • Cisco conserve et attribue

    • Adresse IP de l’interface Tunnel (lien transitoire pour le routage) Cisco attribue à partir d’un espace d’adresse partagée désigné (non routable publiquement)

    • Adresse de désitination du transport tunnel (du côté de Cisco)

    • Numéros de système autonomes privés (ASN) pour la configuration de routage BGP du client

      • Cisco attribue à partir de la plage d’utilisation privée désignée : 64512 à 65534

  • EBGP utilisé pour échanger les routes entre l’instance dédiée et CPE

    • Cisco divisera le réseau attribué /24 en 2/25 un pour chaque CD dans la région respective.

    • Dans Virtual Connect, chaque /25 réseau est à nouveau annoncé sur CPE par Cisco sur le VPN de point à point respectif (lien transitoire)

    • CPE doit être configuré avec la configuration eBGP appropriée. Si vous utilisez un CPE, deux champs eBGP seront utilisés, un pointant vers chaque tunnel distant. Si vous utilisez deux CPE, alors chaque CPE aura un point de ponitage eBGP voisin au tunnel distant unique pour le CPE.

    • Le côté Cisco de chaque tunnel GRE (interface IP de tunnel) est configuré en tant que BGP voisin sur le CPE

    • CPE est obligatoire pour publier un route par défaut sur chacun des navigateurs

    • CPE ne peut pas redistribuer, si nécessaire, les routages appris dans le réseau d’entreprise du cutomer.

  • En cas de situation de d’échec de non-échec, un seul CPE aura deux CPE actifs/actifs. Pour deux nodes CPE, chaque CPE aura un tunnel actif et les deux nodes CPE doivent être actifs et passer le trafic. En cas de situation de non panne, le trafic doit être divisé par deux vers les destinations correctes /25, si l’une des destinations est en panne, le tunnel restant peut transporter le trafic des deux. Dans un tel scénario de panne, lorsque le réseau /25 est à l’arrêt alors le réseau /24 est utilisé comme route de sauvegarde. Cisco enverra le trafic client via son WAN interne vers le CD qui a perdu la connectivité.

Flux de trafic de connexion virtuelle

Flux de circulation lorsque les deux tunnels sont ouverts

Instance dédiée - Connexion virtuelle

Cette image illustre une architecture réseau Virtual Connect, détaillant le flux de trafic lorsque les tunnels principaux et secondaires sont opérationnels.

Il s'agit d'un modèle de connectivité active permettant à un client d'accéder aux applications UC hébergées dans les centres de données de Cisco, en tirant parti de la double connectivité. GRE/IPSEC tunnels sur Internet avec BGP pour l'échange de routes.

Définitions :

  • Locaux du client:
    • Il s'agit du réseau sur site du client, où se trouvent les utilisateurs et leurs appareils (par exemple, les téléphones IP, les ordinateurs exécutant des clients UC).
    • Le trafic provenant d'ici doit atteindre les applications UC hébergées dans les centres de données de Cisco.
  • Centres de données Cisco Webex Calling Dedicated Instance (instance dédiée) (WxC-DI DC-A et WxC-DI DC-B):
    • Il s'agit des centres de données de Cisco hébergeant les applications UC.
    • DC-A et DC-B sont géographiquement distincts, offrant une redondance.
    • Chaque centre de données dispose de son propre sous-réseau pour les applications UC :
      • DC-A subnet:X.X.X.0/25
      • DC-B subnet:X.X.X.128/25
  • GRE/IPsec Tunnels (Tunnel 1 et Tunnel 2):
    • Il s'agit des connexions sécurisées et cryptées entre les locaux du clientet le centre de données Ciscovia l'Internet public.
    • GRE (encapsulation de routage générique) : Ce protocole est utilisé pour encapsuler divers protocoles de couche réseau dans des liaisons point à point virtuelles. Il permet aux protocoles de routage comme BGP de fonctionner sur le tunnel.
    • IPsec (sécurité du protocole Internet) : Cette suite de protocoles fournit des services de sécurité cryptographique (authentification, intégrité, confidentialité) pour les communications IP. Il crypte le trafic encapsulé GRE, garantissant une transmission sécurisée des données sur Internet.
  • Protocole de passerelle frontalière (BGP):
    • BGP est le protocole de routage utilisé pour échanger des informations de routage entre les locaux du client et les centres de données Cisco.

Comme le montre le schéma ci-dessus, les appareils déployés dans les locaux du client doivent établir deux GRE/IPSEC tunnels.

Les conventions de nommage utilisées ci-dessous avec XX / YY, DC-A DC-B sont génériques pour toutes les régions où une instance dédiée est proposée. Ces valeurs seront uniques pour chaque région et les valeurs réelles pour chaque région. Les valeurs spécifiques sont fournies lors de l'activation de la connexion virtuelle.

Du côté de Cisco, les tunnels IPSec et GRE seront terminés sur des appareils différents. Le client doit donc s'assurer de configurer les adresses IP de destination IPSec et GRE sur les appareils en conséquence. Les clients peuvent utiliser la même adresse IP pour GRE et IPSEC si elle est prise en charge sur leurs appareils. Reportez-vous au schéma ci-dessus. Les valeurs liées à l'IP sont fournies lors de l'activation de la connexion virtuelle sur le portail.

  • Tunnel 1: Connecte les locaux du client à « Dedicated Instance DC-A » (Data Center A) via Internet. Ce tunnel utilise BGP AS:64XX1 côté client et BGP AS:64XX2 du côté de l'instance dédiée DC-A. Les configurations de source de tunnel IPSEC et GRE sont divisées entre les détails fournis par le client et ceux fournis par Cisco.
  • Tunnel 2: Connecte les locaux du client à « Dedicated Instance DC-B » (Data Center B) via Internet. Ce tunnel utilise BGP AS:64YY1 côté client et BGP AS:64YY2 du côté de l'instance dédiée DC-B. Comme pour le tunnel 1, les configurations de source de tunnel IPSEC et GRE sont partagées entre le client et Cisco.

Dans BGP AS:64XX et BGP AS:64YY, XX et YY sont spécifiques à une région particulière.

Une fois que le GRE/IPSEC les tunnels étant établis vers les centres de données de l'instance dédiée Webex Calling (A et B), le client doit recevoir les itinéraires suivants annoncés par Cisco sur les sessions BGP correspondantes.

  • Pour DC-A : Les itinéraires annoncés par Cisco seront X.X.X.0/25 et X.X.x.0/24. En option si IaaS est demandé et configuré pour les itinéraires client Y.Y.Y.0/25 et Y.Y.Y.0/24 sera annoncé par Cisco.
  • Pour DC-B : Les itinéraires annoncés par Cisco seront X.X.X.128/25 et X.X.x.0/24. En option si IaaS est demandé et configuré pour les itinéraires client Y.Y.Y.128/25 et Y.Y.Y.0/24 sera annoncé par Cisco.
  • Le client doit faire de la publicité pour 0.0.0./0 acheminer vers Cisco via les deux connexions (tunnels)
  • Le client doit suivre le préfixe le plus long (/25) itinéraires pour envoyer du trafic à Cisco via les tunnels respectifs lorsque les deux tunnels sont opérationnels.
  • Cisco renverra le trafic via les mêmes tunnels pour maintenir la symétrie du trafic.

Flux de circulation :

  • Trafic destiné aux « DC-A UC Apps » (X.X.X.0/25) depuis les locaux du client, les flux passent par le tunnel 1.
  • Trafic destiné aux « DC-B UC Apps » (X.X.X.128/25) depuis les locaux du client, les flux passent par le tunnel 2.

Scénario de basculement : flux de circulation lorsque l'un des tunnels est en panne

Instance dédiée - Connexion virtuelle

Comme indiqué dans le schéma ci-dessus, lorsque le tunnel vers DC-A est en panne, le BGP établi via le tunnel vers DC-A sera en panne.

Impact sur BGP: Lorsque le tunnel 1 tombe en panne, la session BGP sur ce tunnel tombe également en panne. Par conséquent, DC-A ne pourra plus annoncer ses itinéraires (en particulier X.X.X.0/25) au client via ce chemin. Par conséquent, le routeur client détectera le chemin comme inaccessible.

Maintenant que le tunnel 1 est en panne, le routeur client sur le site du client supprimera automatiquement les itinéraires appris via le tunnel 1 de sa table de routage ou les marquera comme inaccessibles.

  • Trafic destiné au réseau d'applications UC (X.X.X.0/24) ou le sous-réseau DC-A (X.X.X.0/25) sera ensuite redirigé via le tunnel de travail vers DC-B qui continue d'annoncer le X.X.X.0/24 qui comprend le X.X.X.0/25 réseau.
  • Un comportement similaire sera observé si le tunnel vers DC-B est en panne alors que le tunnel vers DC-A est toujours actif.

Processus de connectivité

Les étapes de haut niveau suivantes décrivent comment établir une connectivité avec Connect virtuelle pour l’instance dédiée.
1

Commandez dans Cisco CCW

2

Activer La connexion virtuelle à partir de Control Hub

3

Cisco effectue la configuration réseau

4

Le client effectue la configuration réseau

Étape 1 : Commande CCW

Virtual Connect est un add-on pour l’instance dédiée dans CCW.

1

Accédez au site de commande CCW, puis cliquez sur Connexion pour vous connecter au site :

https://apps.cisco.com/Commerce/guest.
2

Création d’une estimation.

3

Ajouter un SKU « A-FLEX-3 ».

4

Sélectionnez Modifier les options.

5

Dans l’onglet Abonnement qui s’affiche, Sélectionnez Options et Add-ons.

6

Sous Add-ons supplémentaires, cochez la case à côté de « Virtual Connect for Dedicated Instance ». Le nom SKU est « A-FLEX-DI-VC ».

7

Entrez la quantité et le nombre de régions dans lesquelles Virtual Connect est nécessaire.

La quantité de Virtual Connect ne doit pas dépasser le nombre total de régions achetées pour l’instance dédiée. En outre, un seul ordre Virtual Connect est autorisé par région.
8

Lorsque vous êtes satisfait de vos choix, cliquez sur Vérifier et enregistrer dans la partie en haut à droite de la page.

9

Cliquez sur Enregistrer et Continuer pour finaliser votre commande. Votre ordre finalisé appose maintenant dans la grille d’ordre.

Étape 2 : Activation de Virtual Connect dans Control Hub

1

Connectez-vous à Control Hub https://admin.webex.com/login.

2

Dans la section Services , accédez à la section Appel > connexion dédiée > connectivitéCloud.

3

Dans la carte Virtual Connect, la quantité de Virtual Connect achetée est répertoriée. L’administrateur peut maintenant cliquer sur Activer pour initier l’activation de Virtual Connect.

Le processus d’activation peut être déclenché uniquement par les administrateurs ayant le rôle « d’administrateur clientèle complet ». Cependant, un administrateur avec le rôle « Admin du client en lecture seule » ne peut voir que le statut.
4

En cliquant sur le bouton Activer, le formulaire Activer Virtual Connect s’affiche pour que l’administrateur fournisse les détails techniques de Virtual Connect nécessaires pour les configurations d’peering (peering) du côté de Cisco.

Le formulaire fournit également des informations statiques du côté de Cisco, en fonction de la région sélectionnée. Ces informations seront utiles pour les administrateurs clients pour configurer l’PE sur leur côté pour établir la connectivité.

  1. Adresse IP de transport du tunnel GRE: Le client est tenu de fournir les adresses IP de transport tunnel latérales du client et Cisco affectera dynamiquement les adresses IP lorsque l’activation sera terminée. L’IPSec ACL pour un trafic intéressant doit autoriser le transport local tunnel IP/32 à distance Transport IP/32. L’ACL doit également spécifier uniquement le protocole IP GRE.

    L’adresse IP fournie par le client peut être privée ou publique.

  2. Pairs IPSec: Le client est tenu de fournir les adresses IPSec Tunnel source et Cisco alloue l’adresse IPSec de destination. Effectuer la traduction NAT d’une adresse interne IPSEC tunnel à une adresse publique est également pris en charge si nécessaire.

    L’adresse IP fournie par le client doit être publique.

    Toutes les autres informations statiques fournies dans l’écran d’activation sont le suivi des normes de sécurité et de chiffrement de Cisco. Cette configuration statique n’est pas personnalisable ou modifiable. Pour une assistance supplémentaire concernant les configurations statiques du côté de Cisco, le client doit joindre le CAT.
5

Cliquez sur le bouton Activer lorsque tous les champs obligatoires sont remplis.

6

Une fois que le formulaire d’activation Virtual Connect est rempli pour une région particône, le client peut Exporter le formulaire d’activation à partir de Control Hub, l’onglet Appel > Instance dédiée > Connectivité sur le Cloud et cliquer sur Exporter les paramètres.

Pour des raisons de sécurité, l'authentification et le mot de passe BGP ne seront pas disponibles dans le document exporté, mais l'administrateur peut les afficher dans Control Hub en cliquant sur Afficher les paramètres sous Control Hub, Appel > Instance dédiée > Onglet Connectivité Cloud.

Étape 3 : Cisco effectue la configuration réseau

1

Lorsque le formulaire d’activation Virtual Connect est terminé, le statut est mis à jour sur Activation en cours dans l’appel > instance dédiée > carte Connexion virtuelle sur le Cloud.

2

Cisco effectuera les configurations requises sur l'équipement côté Cisco dans un délai de 5 jours ouvrables. Lorsque ce sera terminé, le statut sera mis à jour sur « Activé » pour cette région particulière dans Control Hub.

Étape 4 : Le client effectue la configuration réseau

Le statut est changé en « Activé » pour avertir l’administrateur du client que le côté de la configuration de Cisco pour la connectivité VPN IP a été rempli en fonction des entrées fournies par le client. Mais, l’administrateur du client est attendu de terminer ses configurations sur les CP et de tester les chemins de connectivité pour que le tunnel Virtual Connect soit En ligne. En cas de problèmes rencontrés au moment de la configuration ou de la connectivité, le client peut joindre le CAT Cisco (Centre d’assistance technique) pour obtenir de l’aide.

Dépannage

Dépannage et validation de la première phase d'IPsec (négociation IKEv2)

La négociation du tunnel IPsec implique deux phases, la phase IKEv2 et la phase IPsec. Si la négociation de la phase IKEv2 n’est pas terminée, aucune deuxième phase IPsec n’est initiée. Tout d’abord, émettez la commande « show crypto ikev2 sa » (sur l’équipement Cisco) ou une commande similaire sur l’équipement tiers pour vérifier si la session IKEv2 est active. Si la session IKEv2 n'est pas active, les raisons potentielles peuvent être :

  • Le trafic intéressant ne déclenche pas le tunnel IPsec.

  • La liste d'accès au tunnel IPsec est mal configurée.

  • Il n'y a aucune connectivité entre le client et l'adresse IP du point de terminaison du tunnel IPsec de l'instance dédiée.

  • Les paramètres de session IKEv2 ne correspondent pas entre le côté instance dédiée et le côté client.

  • Un pare-feu bloque les paquets UDP IKEv2.

Tout d’abord, vérifiez les journaux IPsec pour tous les messages indiquant la progression de la négociation du tunnel IKEv2. Les journaux peuvent indiquer où il y a un problème avec la négociation IKEv2. L’absence de messages de journalisation peut également indiquer que la session IKEv2 n’est pas activée.

Certaines erreurs courantes avec la négociation IKEv2 sont :

  • Les paramètres de l'IKEv2 côté CPE ne correspondent pas à ceux du côté Cisco, revérifiez les paramètres mentionnés :

    • Vérifiez que la version IKE est la version 2.

    • Vérifiez que les paramètres de chiffrement et d’authentification correspondent au chiffrement attendu côté instance dédiée.

      Lorsque le chiffrement « GCM » est utilisé, le protocole GCM gère l’authentification et définit le paramètre d’authentification sur NULL.

    • Vérifiez le paramètre de durée de vie.

    • Vérifiez le groupe de modules Diffie Hellman.

    • Vérifiez les paramètres de la fonction pseudo-aléatoire.

  • La liste d'accès pour la carte cryptographique n'est pas définie sur :

    • Permis GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (ou commande équivalente)

      La liste d'accès doit être spécifiquement destinée au protocole « GRE » et le protocole « IP » ne fonctionnera pas.

Si les messages du journal ne montrent aucune activité de négociation pour la phase IKEv2, une capture de paquets peut être nécessaire.

Le côté instance dédiée ne peut pas toujours démarrer l'échange IKEv2 et peut parfois s'attendre à ce que le côté CPE du client soit l'initiateur.

Vérifiez la configuration côté CPE pour les prérequis suivants pour le lancement de la session IKEv2 :

  • Recherchez une liste d'accès cryptographique IPsec pour le trafic GRE (protocole 50) de l'IP de transport du tunnel CPE vers l'IP de transport du tunnel de l'instance dédiée.

  • Assurez-vous que l'interface du tunnel GRE est activée pour les keepalives GRE. Si l'équipement ne prend pas en charge les keepalives GRE, Cisco est averti car les keepalives GRE seront activés par défaut du côté de l'instance dédiée.

  • Assurez-vous que BGP est activé et configuré avec l’adresse voisine de l’IP du tunnel de l’instance dédiée.

Une fois configuré correctement, ce qui suit démarre le tunnel IPsec et la négociation IKEv2 de première phase :

  • Les keepalives GRE de l'interface du tunnel GRE côté CPE vers l'interface du tunnel GRE côté instance dédiée.

  • Session TCP du voisin BGP du côté CPE au voisin BGP du côté de l'instance dédiée.

  • Envoyez une requête ping depuis l'adresse IP du tunnel côté CPE vers l'adresse IP du tunnel côté instance dédiée.

    Ping ne peut pas être l'IP de transport du tunnel vers l'IP de transport du tunnel, il doit être l'IP du tunnel vers l'IP du tunnel.

Si une trace de paquets est nécessaire pour le trafic IKEv2, définissez le filtre pour UDP et soit le port 500 (lorsqu'aucun périphérique NAT ne se trouve au milieu des points de terminaison IPsec) soit le port 4500 (lorsqu'un périphérique NAT est inséré au milieu des points de terminaison IPsec).

Vérifiez que les paquets UDP IKEv2 avec le port 500 ou 4500 sont envoyés et reçus vers et depuis l'adresse IP IPsec DI.

Le centre de données de l'instance dédiée ne démarre pas toujours le premier paquet IKEv2. L’exigence est que le périphérique CPE soit capable d’initier le premier paquet IKEv2 vers le côté de l’instance dédiée.

Si le pare-feu local le permet, essayez également un ping vers l'adresse IPsec distante. Si le ping échoue de l'adresse IPsec locale vers l'adresse distante, effectuez un traçage d'itinéraire pour vous aider et déterminer où le paquet est abandonné.

Certains pare-feu et équipements Internet peuvent ne pas autoriser le traçage d'itinéraire.

Dépannage et validation de la deuxième phase d'IPsec (négociation IPsec)

Vérifiez que la première phase IPsec (c'est-à-dire l'association de sécurité IKEv2) est active avant de dépanner la deuxième phase IPsec. Exécutez une commande « show crypto ikev2 sa » ou équivalente pour vérifier la session IKEv2. Dans la sortie, vérifiez que la session IKEv2 est active depuis plus de quelques secondes et qu'elle ne rebondit pas. Le temps de disponibilité de la session s'affiche sous la forme du « temps d'activité » de la session ou équivalent dans la sortie.

Une fois que la session IKEv2 est vérifiée comme étant active, examinez la session IPsec. Comme avec la session IKEv2, exécutez une commande « show crypto ipsec sa » ou équivalente pour vérifier la session IPsec. La session IKEv2 et la session IPsec doivent être actives avant l'établissement du tunnel GRE. Si la session IPsec ne s'affiche pas comme active, vérifiez les journaux IPsec pour détecter les messages d'erreur ou les erreurs de négociation.

Certains des problèmes les plus courants qui peuvent être rencontrés lors des négociations IPsec sont :

Les paramètres côté CPE ne correspondent pas à ceux côté instance dédiée, revérifiez les paramètres :

  • Vérifiez que les paramètres de chiffrement et d’authentification correspondent aux paramètres côté instance dédiée.

  • Vérifiez les paramètres Perfect Forward Secrecy et assurez-vous qu'ils correspondent aux paramètres du côté de l'instance dédiée.

  • Vérifiez les paramètres de durée de vie.

  • Vérifiez que l'IPsec a été configuré en mode tunnel.

  • Vérifiez les adresses IPsec source et de destination.

Dépannage et validation de l'interface du tunnel

Lorsque les sessions IPsec et IKEv2 sont vérifiées comme étant actives, les paquets de maintien en activité du tunnel GRE peuvent circuler entre les points de terminaison de l'instance dédiée et du tunnel CPE. Si l'interface du tunnel n'affiche pas d'état, voici quelques problèmes courants :

  • L'interface de transport VRF du tunnel ne correspond pas au VRF de l'interface de bouclage (si la configuration VRF est utilisée sur l'interface du tunnel).

    Si la configuration VRF n'est pas utilisée sur l'interface du tunnel, cette vérification peut être ignorée.

  • Les Keepalives ne sont pas activés sur l'interface du tunnel côté CPE

    Si les keepalives ne sont pas pris en charge sur l'équipement CPE, Cisco doit être averti afin que les keepalives par défaut du côté de l'instance dédiée soient également désactivés.

    Si les keepalives sont pris en charge, vérifiez qu'ils sont activés.

  • Le masque ou l'adresse IP de l'interface du tunnel n'est pas correct et ne correspond pas aux valeurs attendues de l'instance dédiée.

  • L'adresse de transport du tunnel source ou de destination n'est pas correcte et ne correspond pas aux valeurs attendues de l'instance dédiée.

  • Un pare-feu bloque l'envoi des paquets GRE dans le tunnel IPsec ou leur réception depuis le tunnel IPsec (le tunnel GRE est transporté via le tunnel IPsec)

Un test ping doit vérifier que l'interface du tunnel local est opérationnelle et que la connectivité avec l'interface du tunnel distant est bonne. Effectuez la vérification ping depuis l'IP du tunnel (pas l'IP de transport) vers l'IP du tunnel distant.

La liste d'accès cryptographique pour le tunnel IPsec qui transporte le trafic du tunnel GRE autorise uniquement le passage des paquets GRE. Par conséquent, les pings ne fonctionneront pas de l'IP de transport du tunnel vers l'IP de transport du tunnel distant.

La vérification ping génère un paquet GRE généré à partir de l'IP de transport du tunnel source vers l'IP de transport du tunnel de destination, tandis que la charge utile du paquet GRE (l'IP interne) sera l'IP du tunnel source et de destination.

Si le test ping échoue et que les éléments précédents sont vérifiés, une capture de paquet peut être nécessaire pour garantir que le ping icmp génère un paquet GRE qui est ensuite encapsulé dans un paquet IPsec, puis envoyé de l'adresse IPsec source à l'adresse IPsec de destination. Les compteurs sur l'interface du tunnel GRE et les compteurs de session IPsec peuvent également aider à montrer si les paquets d'envoi et de réception augmentent.

En plus du trafic ping, la capture doit également afficher les paquets GRE keepalive même pendant le trafic inactif. Enfin, si BGP est configuré, les paquets BGP keepalive doivent également être envoyés sous forme de paquets GRE encapsulés dans des paquets IPSEC via le VPN.

Dépannage et validation BGP

Sessions BGP

BGP est requis comme protocole de routage sur le tunnel VPN IPsec. Le voisin BGP local doit établir une session eBGP avec le voisin BGP de l'instance dédiée. Les adresses IP des voisins eBGP sont les mêmes que les adresses IP des tunnels locaux et distants. Assurez-vous d’abord que la session BGP est active, puis vérifiez que les routes correctes sont reçues de l’instance dédiée et que la route par défaut correcte est envoyée à l’instance dédiée.

Si le tunnel GRE est opérationnel, vérifiez qu'un ping est réussi entre l'IP du tunnel GRE local et l'IP du tunnel GRE distant. Si le ping réussit mais que la session BGP ne démarre pas, examinez le journal BGP pour détecter les erreurs d'établissement BGP.

Certains des problèmes de négociation BGP les plus courants sont :

  • Le numéro AS distant ne correspond pas au numéro AS configuré côté instance dédiée, revérifiez la configuration AS voisine.

  • Le numéro AS local ne correspond pas à ce que le côté instance dédiée attend, vérifiez que le numéro AS local correspond aux paramètres d'instance dédiée attendus.

  • Un pare-feu bloque l'envoi des paquets TCP BGP encapsulés dans des paquets GRE dans le tunnel IPsec ou leur réception depuis le tunnel IPSEC.

  • L'IP du voisin BGP distant ne correspond pas à l'IP du tunnel GRE distant.

Échange de routes BGP

Une fois la session BGP vérifiée pour les deux tunnels, assurez-vous que les itinéraires corrects sont envoyés et reçus du côté de l'instance dédiée.

La solution VPN d'instance dédiée s'attend à ce que deux tunnels soient établis à partir du customer/partner côté. Le premier tunnel pointe vers le centre de données de l'instance dédiée A et le deuxième tunnel pointe vers le centre de données de l'instance dédiée B. Les deux tunnels doivent être à l'état actif et la solution nécessite un active/active déploiement. Chaque centre de données d'instance dédiée annoncera son instance locale /25 itinéraire ainsi qu'un /24 itinéraire de secours. Lors de la vérification des routes BGP entrantes provenant de l'instance dédiée, assurez-vous que la session BGP associée au tunnel pointant vers le centre de données de l'instance dédiée A reçoit le centre de données de l'instance dédiée A /25 itinéraire local ainsi que le /24 itinéraire de secours. De plus, assurez-vous que le tunnel pointant vers le centre de données de l'instance dédiée B reçoit le centre de données de l'instance dédiée B /25 itinéraire local ainsi que le /24 itinéraire de secours. Notez que le /24 l'itinéraire de sauvegarde sera le même itinéraire annoncé à partir du centre de données d'instance dédiée A et du centre de données d'instance dédiée B.

La redondance est fournie à un centre de données d'instance dédiée si l'interface du tunnel vers ce centre de données tombe en panne. Si la connectivité au centre de données de l'instance dédiée A est perdue, le trafic sera transféré du centre de données de l'instance dédiée B vers le centre de données A. Dans ce scénario, le tunnel vers le centre de données B utilisera le centre de données B. /25 route pour envoyer le trafic vers le centre de données B et le tunnel vers le centre de données B utilisera la sauvegarde /24 itinéraire pour envoyer le trafic vers le centre de données A via le centre de données B.

Il est important que, lorsque les deux tunnels sont actifs, le tunnel du centre de données A ne soit pas utilisé pour envoyer du trafic vers le centre de données B et vice versa. Dans ce scénario, si le trafic est envoyé au centre de données A avec une destination au centre de données B, le centre de données A transmettra le trafic au centre de données B, puis le centre de données B tentera de renvoyer le trafic à la source via le tunnel du centre de données B. Cela entraînera un routage sous-optimal et peut également interrompre le trafic traversant les pare-feu. Il est donc important que les deux tunnels soient situés dans un active/active configuration pendant le fonctionnement normal.

Le 0.0.0.0/0 l'itinéraire doit être annoncé du côté client vers le côté centre de données de l'instance dédiée. Les itinéraires plus spécifiques ne seront pas acceptés par le côté instance dédiée. Assurez-vous que le 0.0.0.0/0 l'itinéraire est annoncé à la fois à partir du tunnel du centre de données de l'instance dédiée A et du tunnel du centre de données de l'instance dédiée B.

Configuration MTU

Du côté de l'instance dédiée, deux fonctionnalités sont activées pour ajuster dynamiquement le MTU pour les paquets de grande taille. Le tunnel GRE ajoute davantage d’en-têtes aux paquets IP circulant dans la session VPN. Le tunnel IPsec ajoute des en-têtes supplémentaires au-dessus des en-têtes GRE, ce qui réduira encore le plus grand MTU autorisé sur le tunnel.

Le tunnel GRE ajuste la fonctionnalité MSS et le chemin du tunnel GRE dans la fonctionnalité de découverte MTU est activé côté instance dédiée. Configurez « ip tcp adjust-mss 1350 » ou une commande équivalente ainsi que « tunnel path\u0002mtu-discovery" ou une commande équivalente côté client pour aider au réglage dynamique du MTU du trafic via le tunnel VPN.