Virtual Connect utilizza un'architettura headend a doppio livello, in cui i piani di controllo del routing e del GRE sono forniti da un dispositivo e il piano di controllo IPSec è fornito da un altro.

Al termine della connettività Virtual Connect, verranno creati due tunnel GRE su IPSec tra la rete aziendale del Cliente e i datacenter di Cisco a istanza dedicata. Uno per ogni datacenter ridondante all'interno della rispettiva Regione. Gli elementi di rete aggiuntivi necessari per il peering vengono scambiati dal Partner o dal Cliente con Cisco tramite il modulo di attivazione di Control Hub Virtual Connect.

La figura seguente mostra l'esempio del modello di implementazione Virtual Connect per l'opzione a 2 concentratori da parte del cliente.

Virtual Connect - La VPN è un modello di hub, in cui i siti hub del cliente sono collegati ai data center DC1 e DC2 dell'istanza dedicata all'interno di una particolare regione.

Si consigliano due siti Hub per una migliore ridondanza, ma anche un sito Hub con due tunnel è un modello di distribuzione supportato.

I partner dovrebbero lavorare a stretto contatto con i Clienti, assicurando che venga scelto il percorso più ottimale per la regione del servizio Virtual Connect.

La figura seguente mostra le regioni di peering per la connettività cloud delle istanze dedicate.

Il componente aggiuntivo Routing for Virtual Connect è implementato utilizzando un BGP esterno (eBGP) tra l'istanza dedicata e l'apparecchiatura premessa del cliente (CPE). Cisco pubblicizzerà la rispettiva rete per ogni DC ridondante all'interno di una regione al CPE del Cliente e il CPE è necessario per pubblicizzare un percorso predefinito verso Cisco.

• Cisco mantiene e assegna

  • Indirizzamento IP dell'interfaccia tunnel (collegamento transitorio per il routing) che Cisco assegna da uno spazio di indirizzi condiviso designato (non instradabile pubblicamente)

  • Indirizzo di destinazione del trasporto in galleria (lato Cisco)

  • Numeri di sistema autonomi privati (ASN) per la configurazione del routing BGP del cliente

    • Cisco assegna dall'intervallo designato per uso privato: da 64512 a 65534

• eBGP utilizzato per scambiare percorsi tra istanza dedicata e CPE

  • Cisco dividerà la rete 24/24 assegnata in 2/25, una per ogni DC nella rispettiva regione

  • In Virtual Connect ogni rete /25 viene pubblicizzata al CPE da Cisco tramite i rispettivi tunnel VPN point-to-point (collegamento transitorio)

  • Il CPE deve essere configurato con i vicini eBGP appropriati. Se si utilizza un CPE, verranno utilizzati due vicini eBGP, uno rivolto a ciascun tunnel remoto. Se si utilizzano due CPE, ogni CPE avrà un vicino eBGP che punta all'unico tunnel remoto per il CPE.

  • Il lato Cisco di ogni tunnel GRE (interfaccia IP del tunnel) è configurato come adiacente BGP sul CPE

  • Il CPE è necessario per pubblicizzare un percorso predefinito su ciascuno dei tunnel

  • Il CPE è responsabile della ridistribuzione, se necessario, dei percorsi appresi all'interno della rete aziendale del cliente.

• In condizioni di guasto del collegamento non guasto, un singolo CPE avrà due tunnel attivi/attivi. Per due nodi CPE, ogni CPE avrà un tunnel attivo ed entrambi i nodi CPE dovrebbero essere attivi e in transito. In uno scenario senza guasti, il traffico deve essere diviso in due tunnel diretti verso le /25 destinazioni corrette, se uno dei tunnel va giù, il tunnel rimanente può trasportare il traffico per entrambi. In uno scenario di errore di questo tipo, quando la rete /25 è inattiva, la rete /24 viene utilizzata come percorso di backup. Cisco invierà il traffico dei clienti tramite la sua WAN interna verso il DC che ha perso la connettività.

La negoziazione del tunnel IPSec prevede due fasi, la fase IKEv2 e la fase IPSec. Se la negoziazione della fase IKEv2 non viene completata, non viene avviata una seconda fase IPSec. Innanzitutto, emetta il comando «show crypto ikev2 sa» (su apparecchiature Cisco) o un comando simile sull'apparecchiatura di terze parti per verificare se la sessione IKEv2 è attiva. Se la sessione IKEv2 non è attiva, i potenziali motivi potrebbero essere:

• Il traffico interessante non attiva il tunnel IPSec.

• L'elenco di accesso al tunnel IPSec non è configurato correttamente.

• Non c'è connettività tra il cliente e l'IP dell'endpoint del tunnel IPSec dell'istanza dedicata.

• I parametri della sessione IKEv2 non corrispondono tra il lato dell'istanza dedicata e il lato cliente.

• Un firewall sta bloccando i pacchetti UDP IKEv2.

Innanzitutto, controlli i log IPSec per eventuali messaggi che mostrano l'avanzamento della negoziazione del tunnel IKEv2. I registri possono indicare dove c'è un problema con la negoziazione IKEv2. La mancanza di messaggi di registrazione può anche indicare che la sessione IKEv2 non è in fase di attivazione.

Alcuni errori comuni nella negoziazione IKEv2 sono:

• Le impostazioni per l'IKEv2 sul lato CPE non corrispondono a quelle di Cisco, ricontrolla le impostazioni menzionate:

  • Verifichi che la versione IKE sia la versione 2.

  • Verifichi che i parametri di crittografia e autenticazione corrispondano alla crittografia prevista sul lato dell'istanza dedicata.

    Quando il codice «GCM» è in uso, il protocollo GCM gestisce l'autenticazione e imposta il parametro di autenticazione su NULL.

  • Verifichi l'impostazione della durata.

  • Verifichi il gruppo di moduli Diffie Hellman.

  • Verifichi le impostazioni della funzione Pseudo Random.

• L'elenco di accesso per la mappa crittografica non è impostato su:

  • Permesso GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (o comando equivalente)

    L'elenco di accesso deve essere specifico per il protocollo «GRE» e il protocollo «IP» non funzionerà.

Se i messaggi di registro non mostrano alcuna attività di negoziazione per la fase IKEv2, potrebbe essere necessaria un'acquisizione dei pacchetti.

Se configurato correttamente, quanto segue avvia il tunnel IPSec e la prima fase di negoziazione IKEv2:

• GRE si mantiene in vita dall'interfaccia del tunnel GRE lato CPE all'interfaccia del tunnel GRE lato Dedicated Instance.

• Sessione TCP vicino BGP dal lato CPE vicino BGP al vicino BGP lato istanza dedicata.

• Ping dall'indirizzo IP del tunnel laterale CPE all'indirizzo IP del tunnel laterale dell'istanza dedicata.

  Ping non può essere l'IP di trasporto dal tunnel all'IP di trasporto del tunnel, deve essere l'IP del tunnel all'IP del tunnel.

Se è necessaria una traccia dei pacchetti per il traffico IKEv2, imposta il filtro per UDP e la porta 500 (quando nessun dispositivo NAT è al centro degli endpoint IPSec) o la porta 4500 (quando un dispositivo NAT è inserito al centro degli endpoint IPSec).

Verifichi che i pacchetti UDP IKEv2 con porta 500 o 4500 siano inviati e ricevuti da e verso l'indirizzo IP DI IPSec.

Verifichi che la prima fase IPSec (ovvero l'associazione di sicurezza IKEv2) sia attiva prima di risolvere i problemi della seconda fase IPSec. Esegua un comando «show crypto ikev2 sa» o equivalente per verificare la sessione IKEv2. Nell'output, verifichi che la sessione IKEv2 sia attiva da più di qualche secondo e che non stia rimbalzando. L'uptime della sessione viene indicato come «Tempo attivo» della sessione o equivalente nell'output.

Una volta verificato che la sessione IKEv2 è attiva e attiva, esamina la sessione IPSec. Come per la sessione IKEv2, esegua un comando «show crypto ipsec sa» o equivalente per verificare la sessione IPsec. Sia la sessione IKEv2 che la sessione IPSec devono essere attive prima che il tunnel GRE venga stabilito. Se la sessione IPSec non risulta attiva, controlli i log IPSec per i messaggi di errore o gli errori di negoziazione.

Alcuni dei problemi più comuni che si possono riscontrare durante le negoziazioni IPSec sono:

Le impostazioni sul lato CPE non corrispondono al lato dell'istanza dedicata, ricontrolla le impostazioni:

• Verifichi che i parametri di crittografia e autenticazione corrispondano alle impostazioni sul lato dell'istanza dedicata.

• Verifichi le impostazioni di Perfect Forward Secrecy e che corrispondano alle impostazioni sul lato dell'istanza dedicata.

• Verifichi le impostazioni relative alla durata.

• Verifichi che l'IPSec sia stato configurato in modalità tunnel.

• Verifichi gli indirizzi IPSec di origine e destinazione.

Quando le sessioni IPSec e IKEv2 vengono verificate come attive e attive, i pacchetti keepalive del tunnel GRE sono in grado di fluire tra l'istanza dedicata e gli endpoint del tunnel CPE. Se l'interfaccia del tunnel non mostra lo stato, alcuni problemi comuni sono:

• Il VRF di trasporto dell'interfaccia tunnel non corrisponde al VRF dell'interfaccia loopback (se la configurazione VRF viene utilizzata sull'interfaccia tunnel).

  Se la configurazione VRF non viene utilizzata sull'interfaccia del tunnel, questo controllo può essere ignorato.

• I keepalive non sono abilitati sull'interfaccia del tunnel laterale del CPE

  Se i keepalive non sono supportati sulle apparecchiature CPE, allora Cisco deve essere avvisato in modo che anche i keepalive predefiniti sul lato delle istanze dedicate siano disabilitati.

  Se i keepalive sono supportati, verifichi che i keepalive siano abilitati.

• La maschera o l'indirizzo IP dell'interfaccia del tunnel non è corretto e non corrisponde ai valori previsti per l'istanza dedicata.

• L'indirizzo di trasporto del tunnel di origine o di destinazione non è corretto e non corrisponde ai valori previsti per l'istanza dedicata.

• Un firewall sta bloccando i pacchetti GRE inviati nel tunnel IPSec o ricevuti dal tunnel IPSec (il tunnel GRE viene trasportato attraverso il tunnel IPSec)

Un ping test dovrebbe verificare che l'interfaccia del tunnel locale sia attiva e che la connettività sia buona con l'interfaccia del tunnel remoto. Eseguire il controllo del ping dall'IP del tunnel (non l'IP di trasporto) all'IP del tunnel remoto.

Il controllo del ping risulta in un pacchetto GRE generato dall'IP di trasporto del tunnel di origine all'IP di trasporto del tunnel di destinazione mentre il payload del pacchetto GRE (l'IP interno) sarà l'IP del tunnel di origine e di destinazione.

Se il test ping non ha esito positivo e gli elementi precedenti vengono verificati, potrebbe essere necessaria un'acquisizione dei pacchetti per garantire che il ping icmp generi un pacchetto GRE che viene poi incapsulato in un pacchetto IPSec e quindi inviato dall'indirizzo IPSec di origine all'indirizzo IPSec di destinazione. Anche i contatori sull'interfaccia del tunnel GRE e i contatori delle sessioni IPSec possono aiutare a mostrare se i pacchetti di invio e ricezione stanno aumentando.

Oltre al traffico ping, l'acquisizione dovrebbe mostrare anche pacchetti GRE keepalive anche durante il traffico inattivo. Infine, se BGP è configurato, i pacchetti keepalive BGP devono essere inviati anche come pacchetti GRE incapsulati in pacchetti IPSEC tramite la VPN.

Sul lato delle istanze dedicate, sono abilitate due funzionalità per regolare dinamicamente l'MTU per pacchetti di grandi dimensioni. Il tunnel GRE aggiunge più intestazioni ai pacchetti IP che fluiscono attraverso la sessione VPN. Il tunnel IPSec aggiunge le intestazioni aggiuntive sopra le intestazioni GRE ridurrà ulteriormente l'MTU massimo consentito sul tunnel.

Il tunnel GRE regola la funzione MSS e il percorso del tunnel GRE nella funzione di rilevamento MTU è abilitato sul lato dell'istanza dedicata. Configura «ip tcp adjust-mss 1350" o un comando equivalente e «tunnel path\ u0002mtu-discovery» o un comando equivalente sul lato cliente per facilitare la regolazione dinamica dell'MTU del traffico attraverso il tunnel VPN.