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 1 montre un exemple de modèle de déploiement De Virtual Connect pour l’option 2-ct à côté du 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 sont attendus à travailler en collaboration étroite avec les clients, garantissant ainsi que la voie la plus optimale est choisie pour la région de service « Virtual Connect ».

La figure 2 montre les régions de peering d’instance dédiée de connectivité du Cloud.

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 du tunnel IPsec comporte deux phases, la phase IKEv2 et la phase IPsec. Si la négociation de la phase IKEv2 n’est pas terminée, alors il n’y a pas d’initiation d’une seconde phase IPsec. 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 :

• Un 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 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 tout message qui montre l’avancement de la négociation du tunnel IKEv2. Les journaux peuvent indiquer s’il y a un problème avec la négociation IKEv2. Un manque de messages de journalisation peut également indiquer que la session IKEv2 n'est pas activée.

Voici quelques erreurs courantes dans la négociation IKEv2 :

• 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érifier 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é 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 à 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 :

  • Permit 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écifique au protocole « GRE » et le protocole « IP » ne fonctionnera pas.

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

Lorsqu’il est correctement configuré, le tunnel IPsec et la première phase de négociation IKEv2 commencent :

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

• Session TCP du voisin BGP du voisin CPE du côté BGP vers le voisin BGP du côté instance dédiée.

• Ping de l'adresse IP du tunnel latéral CPE vers l'adresse IP du tunnel latéral de l'instance dédiée.

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

Si un suivi de paquet est nécessaire pour le trafic IKEv2, définissez le filtre pour UDP et le port 500 (lorsqu'aucun périphérique NAT n'est au milieu des points de terminaison IPsec) ou 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 IPsec DI.

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. Effectuez une commande "show crypto ikev2 sa" ou équivalent pour vérifier la session IKEv2. En sortie, vérifiez que la session IKEv2 a été activée pendant plus de quelques secondes et qu'elle ne rebondit pas. La durée de fonctionnement de la session s'affiche en tant que « Durée active » de la session ou équivalent en sortie.

Une fois que la session IKEv2 s'est vérifiée comme active et active, Recherchez la session IPsec. Comme pour la session IKEv2, effectuez une commande "show crypto ipsec sa" ou équivalent pour vérifier la session IPsec. La session IKEv2 et la session IPsec doivent être actives avant que le tunnel GRE ne soit établi. 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.

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é 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 Perfect Forward Secrecy et que les paramètres correspondent sur le côté 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.

Lorsque les sessions IPsec et IKEv2 sont vérifiées comme actives et actives, les paquets keepalive 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 son statut, certains problèmes courants sont :

• Le VRF de transport de l’interface tunnel ne correspond pas au VRF de l’interface de rebouclage (si la configuration du VRF est utilisée sur l’interface 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ées sur l'interface du tunnel côté CPE

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

  Si keepalives est pris en charge, vérifiez que les keepalives 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 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 par rapport à l'interface du tunnel distant. Effectuez la vérification du ping de l’IP du tunnel (et non de l’IP de transport) vers l’IP du tunnel distant.

La vérification du ping aboutit à un paquet GRE qui est généré à partir de l'adresse IP de transport du tunnel source vers l'adresse IP de transport du tunnel de destination alors que la charge utile du paquet GRE (l'adresse IP intérieure) sera l'adresse IP du tunnel source et de destination.

Si le test ping n'est pas réussi et que les éléments précédents sont vérifiés, alors 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 sur l'interface du tunnel GRE et les compteurs de session IPsec peuvent également aider à afficher si les paquets d'envoi et de réception augmentent.

En plus du trafic ping, la capture doit également afficher les paquets GRE conservés 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.

Côté instance dédiée, deux fonctionnalités sont activées pour ajuster dynamiquement 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 au-dessus des en-têtes GRE réduira davantage la plus grande MTU autorisée 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é du côté Instance dédiée. Configurez « ip tcp adjust-mss 1350 » ou la commande équivalente ainsi que « tunnel path\u0002mtu-discovery » ou la commande équivalente côté client pour faciliter le réglage dynamique du MTU du trafic à travers le tunnel VPN.