Virtual Connect utilise une architecture de tête de réseau à deux niveaux, dans laquelle le routage et les plans de contrôle GRE sont fournis par un appareil et le plan de contrôle IPsec par un autre.

Une fois la connectivité Virtual Connect terminée, deux tunnels GRE sur IPsec seront créés entre le réseau d'entreprise du client et les centres de données Cisco dédiés à l' instance. Un pour chaque centre de données redondant 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 avec Cisco via le formulaire d'activation de 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.

Connexion virtuelle - Le VPN est un hub conçu dans le cadre duquel les sites hubs du client sont connectés aux centres de données DC1 et DC2 des instances dédiées d'une région donnée.

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

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

La figure ci-dessous montre les régions de peering de connectivité cloud des instances dédiées.

Le module complémentaire Routing for Virtual Connect est implémenté à l'aide d'un BGP externe (eBGP) entre l'instance dédiée et l'équipement sur site du client (CPE). Cisco fera la promotion de son réseau respectif pour chaque DC redondant d'une région auprès du CPE du client, qui est tenu de proposer un itinéraire par défaut à Cisco.

• Cisco gère et attribue

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

  • Adresse de destination du transport par tunnel (côté Cisco)

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

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

• eBGP était utilisé pour échanger des itinéraires entre une instance dédiée et un CPE

  • Cisco divisera le réseau /24 assigné en 2/25, un pour chaque centre de distribution de la région concernée

  • Dans Virtual Connect, chaque réseau /25 est redirigé vers le CPE par Cisco via les tunnels VPN point à point correspondants (liaison transitoire)

  • Le 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, chaque CPE aura un voisin eBGP pointant vers le tunnel distant unique du CPE.

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

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

  • Le CPE est chargé de redistribuer, selon les besoins, les itinéraires appris au sein du réseau d'entreprise du client.

• En cas de défaillance de la 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 devraient être actifs et transmettre du trafic. Dans un scénario sans panne, le trafic doit être divisé en deux tunnels vers les bonnes destinations /25. Si l'un des tunnels tombe en panne, le tunnel restant peut transporter le trafic des 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 de ses clients via son réseau étendu interne vers le centre de distribution qui a perdu la connectivité.

La négociation du tunnel IPsec comprend 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 de lancement d'une deuxième phase IPsec. Tout d'abord, lancez la commande « show crypto ikev2 sa » (sur un équipement Cisco) ou une commande similaire sur un équipement tiers pour vérifier si la session IKEv2 est active. Si la session IKEv2 n'est pas active, cela peut être dû aux raisons suivantes :

• 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 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, consultez les journaux IPsec pour détecter tout message indiquant la progression de la négociation du tunnel IKEv2. Les journaux peuvent indiquer un problème lors de la négociation IKEv2. L'absence de messages de journalisation peut également indiquer que la session IKEv2 n'est pas activée.

Les erreurs les plus courantes liées à la négociation IKEv2 sont les suivantes :

• 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 cryptage et d'authentification correspondent au cryptage 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 réglage de la durée de vie.

  • Vérifiez le groupe de modules de Diffie Hellman.

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

• La liste d'accès à la carte cryptographique n'est pas définie comme suit :

  • Autorisez GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255 pouces (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 du journal ne révèlent aucune activité de négociation pendant la phase IKEv2, une capture de paquets peut être nécessaire.

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

• Le GRE passe de l'interface tunnel GRE côté CPE à l'interface tunnel GRE côté instance dédiée.

• Session TCP voisine BGP entre le voisin BGP côté CPE et le voisin BGP côté instance dédiée.

• Envoyez un 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 une adresse IP de transport par tunnel, mais une adresse IP par tunnel.

Si un suivi des paquets est nécessaire pour le trafic IKEv2, configurez 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 depuis et vers l'adresse IP IP DI IPsec.

Vérifiez que la première phase d'IPsec (c'est-à-dire l'association de sécurité IKEv2) est active avant de résoudre les problèmes liés à la deuxième phase d'IPsec. Exécutez une commande « show crypto ikev2 sa » ou une commande équivalente pour vérifier la session IKEv2. Sur le résultat, vérifiez que la session IKEv2 est active depuis plus de quelques secondes et qu'elle ne rebondit pas. La durée de disponibilité de la session s'affiche sous la forme d'une « durée active » de la session ou équivalent en sortie.

Une fois que la session IKEv2 aura été vérifiée et active, examinez la session IPSec. Comme pour la session IKEv2, exécutez une commande « show crypto ipsec sa » ou une commande équivalente pour vérifier la session IPsec. La session IKEv2 et la session IPsec doivent être actives pour que le tunnel GRE soit établi. 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.

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

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

• Vérifiez que les paramètres de cryptage et d'authentification correspondent à ceux de l'instance dédiée.

• Vérifiez les paramètres Perfect Forward Secrecy et les paramètres correspondants 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.

Lorsque les sessions IPSec et IKEv2 sont vérifiées comme étant actives, le tunnel GRE permet aux paquets de circuler entre l'instance dédiée et les points de terminaison du tunnel CPE. Si l'interface du tunnel n'affiche pas d'état, les problèmes les plus courants sont les suivants :

• Le VRF de transport par 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 du tunnel, cette vérification peut être ignorée.

• Keepalives n'est pas activé sur l'interface du tunnel latéral du CPE

  Si les keepalives ne sont pas pris en charge sur l'équipement CPE, Cisco doit en être informée 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 que les keepalives sont activés.

• Le masque ou l'adresse IP de l'interface du tunnel ne sont pas corrects et ne correspondent 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 empêche l'envoi de 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 devrait vérifier que l'interface du tunnel local est opérationnelle et que la connectivité avec l'interface du tunnel distant est bonne. Effectuez le ping check depuis l'adresse IP du tunnel (et non celle du transport) vers l'adresse IP du tunnel distant.

Le ping check donne lieu à un paquet GRE généré depuis l'adresse IP de transport du tunnel source vers l'adresse IP de transport par tunnel de destination, tandis que la charge utile du paquet GRE (l'adresse IP interne) sera l'adresse IP du tunnel source et de destination.

Si le test de ping échoue 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 donne lieu à 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 à indiquer si les paquets d'envoi et de réception s'incrémentent.

Outre le trafic ping, la capture devrait également afficher les paquets GRE Keepalive, même en cas de trafic inactif. Enfin, si le BGP est configuré, les paquets BGP keepalive devraient également être envoyés sous forme de paquets GRE encapsulés dans des paquets IPSEC, également via le VPN.

Du côté des instances dédiées, deux fonctionnalités sont activées pour ajuster dynamiquement le MTU pour les gros paquets. Le tunnel GRE ajoute des en-têtes aux paquets IP qui transitent par la session VPN. Le tunnel IPsec ajoute des en-têtes supplémentaires au-dessus des en-têtes GRE afin de réduire encore le plus grand MTU autorisé sur le tunnel.

Le tunnel GRE ajuste la fonction MSS et le chemin du tunnel GRE dans la fonction de découverte des MTU est activé côté instance dédiée. Configurez « ip tcp ajust-mss 1350 » ou une commande équivalente ainsi que « tunnel path \ u0002mtu-discovery » ou une commande équivalente côté client pour vous aider à ajuster dynamiquement la MTU du trafic via le tunnel VPN.