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 Virtual Connect pour l’option 2 concentrateur 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.

Les partenaires doivent travailler en étroite collaboration avec les Clients, s’assurant que le chemin le plus optimal est choisi pour la région de service Virtual Connect .

La figure ci-dessous montre les régions d’appairage de connectivité Cloud Instance dédiée.

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

La négociation des tunnels IPsec implique deux phases, la phase IKEv2 et la phase IPsec. Si la négociation de la phase IKEv2 n'est pas terminée, il n'y a pas d'initiation d'une seconde phase IPsec. Tout d'abord, lancez 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 possibles peuvent être :

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

• La liste d’accès aux tunnels IPsec est mal configurée.

• Il n’y a pas de connectivité entre le client et l’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 trouver les messages qui montrent 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.

Quelques erreurs courantes avec la négociation IKEv2 sont :

• Les paramètres de l'IKEv2 du côté CPE ne correspondent pas au côté Cisco, vérifiez à nouveau 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 du côté de l’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 modulaire de Diffie Hellman.

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

• La liste d'accès de la carte de chiffrement 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 pour le 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.

Lorsqu'il est correctement configuré, ce qui suit commence le tunnel IPsec et la négociation de première phase IKEv2 :

• Keepalives GRE de l’interface tunnel GRE côté CPE à l’interface tunnel GRE côté Instance dédiée.

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

• Ping de 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 tunnel à l'IP de transport tunnel, il doit être l'IP de tunnel à l'IP de 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 n'est 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 DIsec.

Vérifiez que la première phase IPsec (c'est-à-dire l'association de sécurité IKEv2) est active avant de dépanner la seconde phase IPsec. Effectuez une commande « show crypto ikev2 sa » ou équivalent 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 fonctionnement de la session s'affiche en tant que « Temps actif » de la session ou équivalent en sortie.

Une fois que la session IKEv2 est active et active, Examinez la session IPsec. Comme pour la session IKEv2, effectuez 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 n'apparaît pas comme active, consultez les journaux IPsec pour détecter les messages d'erreur ou les erreurs de négociation.

Voici quelques-uns des problèmes les plus courants qui peuvent être rencontrés au cours des négociations IPsec :

Les paramètres du côté CPE ne correspondent pas au côté de l’instance dédiée, vérifiez à nouveau les paramètres :

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

• Vérifiez les paramètres de confidentialité du transfert parfait et que les paramètres correspondent 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 destination.

Lorsque les sessions IPsec et IKEv2 sont vérifiées comme actives et actives, les paquets keepalive du tunnel GRE peuvent circuler entre l’instance dédiée et les points de terminaison du tunnel CPE. Si l’interface du tunnel n’affiche pas le statut, quelques problèmes courants sont :

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

  Si la configuration VRF n’est pas utilisée sur l’interface tunnel, ce contrôle peut être ignoré.

• Les keepalives ne sont pas activées sur l'interface tunnel côté CPE

  Si les keepalives ne sont pas prises en charge sur l’équipement CPE, alors Cisco doit être informé afin que les keepalives par défaut du côté de l’instance dédiée soient également désactivées.

  Si les keepalives sont prises en charge, vérifiez que les keepalives sont activées.

• Le masque ou l’adresse IP de l’interface du tunnel est incorrect 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 les paquets GRE envoyés dans le tunnel IPsec ou reçus du tunnel IPsec (le tunnel GRE est transporté sur le tunnel IPsec)

Un test ping doit vérifier que l’interface du tunnel local est opérationnelle et que la connectivité est bonne avec l’interface du tunnel distant. Effectuer le contrôle ping de l’IP du tunnel (pas l’IP de transport) vers l’IP du tunnel distant.

La vérification ping se traduit par 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 de ping n'a pas réussi et que les éléments précédents sont vérifiés, une capture de paquets peut être nécessaire pour s'assurer que le ping icmp aboutit à 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 de l'interface du tunnel GRE et les compteurs de session IPsec peuvent également aider à afficher si les paquets d'envoi et de réception sont incrémentés.

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 ainsi que sur le VPN.

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

Le tunnel GRE ajuste la fonction MSS et le chemin du tunnel GRE dans la fonction de découverte MTU est activé du côté de l’instance dédiée. Configurez la commande « ip tcp adjust-mss 1350 » ou équivalente ainsi que la commande « tunnel path\u0002mtu-discovery » ou équivalente côté client pour faciliter le réglage dynamique des MTU du trafic à travers le tunnel VPN.