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

À l’issue de la connectivité Virtual Connect, deux tunnels 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 pour chaque centre de données redondant au sein de la région concernée. Les éléments réseau supplémentaires requis pour le peering sont échangés par le partenaire ou le client à Cisco via le formulaire d’activation de Control Hub Virtual Connect.

La figure 1 montre un 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 Hub, où les Sites Hub du Client sont connectés aux DC1 et DC2 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 un site Hub avec deux tunnels est également un modèle de déploiement pris en charge.

La bande passante par tunnel est limitée à 250 Mbps.

Les sites distants du client situés dans la même région doivent se reconnecter au(x) site(s) Hub via le WAN du client et Cisco n’est pas responsable de cette connectivité.

Les partenaires doivent 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 2 montre les Régions d’appairage de la connectivité Cloud de l’instance dédiée.

Le routage du module complémentaire Virtual Connect est mis en œuvre à l’aide d’un BGP externe (eBGP) entre l’instance dédiée et l’équipement sur site du client (CPE). Cisco publiera son réseau respectif pour chaque DC redondant au sein d'une région sur le CPE du client et le CPE est tenu de publier une route par défaut vers Cisco.

• Cisco maintient et attribue

  • Adressage IP de l’interface du tunnel (lien transitoire pour le routage) Cisco attribue à partir d’un espace d’adresses partagé désigné (non routable publiquement)

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

  • Numéros de systèmes 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 des routes entre Instance dédiée et CPE

  • Cisco divisera le réseau /24 attribué en 2 /25 pour chaque DC de la région respective

  • Dans Virtual Connect, chaque réseau /25 est annoncé à CPE par Cisco sur les tunnels VPN point à point respectifs (lien transitoire)

  • CPE doit être configuré avec les voisins eBGP appropriés. Si vous utilisez un CPE, deux voisins eBGP seront utilisés, l'un pointant vers chaque tunnel distant. Si vous utilisez deux CPE, alors chaque CPE aura un voisin eBGP qui sera affecté au tunnel distant unique pour le CPE.

  • Le côté Cisco de chaque tunnel GRE (IP de l'interface du tunnel) est configuré comme le voisin BGP sur le CPE

  • CPE est tenu de publier un itinéraire par défaut sur chacun des tunnels

  • Le CPE est responsable de la redistribution, au besoin, des routes apprises au sein du réseau d'entreprise du cutomer.

• En cas de défaillance de liaison sans défaillance, un seul CPE aura deux tunnels actifs/actifs. Pour deux nœuds CPE, chaque CPE aura un tunnel actif et les deux nœuds CPE devront être actifs et passer du trafic. Dans le scénario de non-défaillance, le trafic doit être divisé en deux tunnels allant vers les bonnes destinations /25, si l’un des tunnels tombe, le tunnel restant peut transporter le trafic pour les deux. Dans un tel scénario de panne, lorsque le réseau /25 est en panne, le réseau /24 est utilisé comme route de secours. Cisco enverra le trafic client via son WAN interne vers le DC 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.

Le côté Instance dédiée peut ne pas toujours commencer 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 : Vérifiez une liste d'accès crypto IPsec pour le trafic GRE (protocole 50) de l'IP de transport du tunnel CPE vers l'IP de transport du tunnel d'instance dédiée. Assurez-vous que l'interface du tunnel GRE est activée pour GRE keepalives, si l'équipement ne prend pas en charge GRE keepalives alors Cisco est averti car GRE keepalives sera activé sur le côté Instance dédiée par défaut. Assurez-vous que BGP est activé et configuré avec l'adresse voisine de l'adresse IP du tunnel d'instance dédiée.

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 BGP du côté CPE 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.

Le centre de données Instance dédiée ne peut pas toujours démarrer 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é Instance dédiée. Si le pare-feu local le permet, alors tentez également un ping vers l’adresse IPsec distante. Si le ping n'a pas réussi à partir de l'adresse IPsec locale vers l'adresse IPsec distante, alors effectuez une route de traçage pour aider et déterminer où le paquet est abandonné. Certains pare-feu et équipements Internet peuvent ne pas autoriser l'itinéraire de traçage.

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 liste d’accès crypto pour le tunnel IPsec qui transporte le trafic du tunnel GRE ne permet que les paquets GRE de traverser. Par conséquent, les pings ne fonctionneront pas de l'IP de transport du tunnel à l'IP de transport 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.