Virtual Connect utilizza un'architettura headend a due livelli, in cui i piani di indirizzamento e controllo 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 centri dati Cisco dell'istanza dedicata. Uno a ciascun centro dati ridondante all'interno della rispettiva regione. Ulteriori elementi di rete richiesti per il peering vengono scambiati dal partner o dal cliente a Cisco tramite il modulo di attivazione della connessione virtuale Control Hub.

La Figura 1 mostra un esempio del modello di distribuzione di Virtual Connect per l'opzione 2-concentrator sul lato cliente.

Connessione virtuale: la VPN è un design Hub in cui i siti Hub del cliente sono connessi al DC1 e al DC2 dei centri dati dell'istanza dedicata all'interno di una determinata regione.

Due siti Hub sono consigliati per una migliore ridondanza, ma il sito One Hub con due tunnel è anche un modello di distribuzione supportato.

La larghezza di banda per tunnel è limitata a 250 Mbps.

Le sedi remote del Cliente all'interno della stessa regione devono riconnettersi ai siti Hub tramite la WAN del Cliente e non è responsabilità di Cisco per tale connettività.

Ci si aspetta che i partner lavorino a stretto contatto con i clienti, garantendo che venga scelto il percorso più ottimale per la regione del servizio "Virtual Connect".

La Figura 2 mostra le regioni di peering della connettività cloud dell'istanza dedicata.

L'indirizzamento per il componente aggiuntivo Virtual Connect viene implementato utilizzando BGP esterno (eBGP) tra l'istanza dedicata e l'apparecchiatura locale del cliente (CPE). Cisco annuncia la propria rete per ciascun DC ridondante all'interno di una regione al CPE del cliente e il CPE è richiesto per pubblicizzare un indirizzamento predefinito a Cisco.

• Cisco mantiene e assegna

  • Indirizzamento IP interfaccia tunnel (collegamento transitorio per l'indirizzamento) Cisco assegna da uno spazio indirizzo condiviso designato (non indirizzabile pubblicamente)

  • Indirizzo di desitinizzazione trasporto tunnel (lato Cisco)

  • Numeri di sistema autonomo privato (ASN) per la configurazione di indirizzamento BGP del cliente

    • Cisco assegna dall'intervallo di utilizzo privato designato: da 64512 a 65534

• eBGP utilizzato per lo scambio di percorsi tra istanza dedicata e CPE

  • Cisco suddividerà la rete /24 assegnata in 2 /25 una per ogni centro distribuzione nella rispettiva regione

  • In Virtual Connect ogni rete /25 viene pubblicizzata nuovamente a CPE da Cisco sui rispettivi tunnel VPN punto a punto (collegamento transitorio)

  • CPE deve essere configurato con i vicini eBGP appropriati. Se si utilizza un CPE, verranno utilizzati due vicini eBGP, uno che punta a ciascun tunnel remoto. Se si utilizza due CPE, ciascun CPE avrà un eBGP adiacente che si collega al singolo tunnel remoto per il CPE.

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

  • CPE è richiesto per pubblicizzare un percorso predefinito su ciascuna galleria

  • CPE è rispondibile per ridistribuire, come richiesto, i percorsi appresi all'interno della rete aziendale del cutomer.

• In caso di guasto del collegamento, un singolo CPE avrà due tunnel attivi/attivi. Per due nodi CPE, ciascun CPE avrà un tunnel attivo e entrambi i nodi CPE devono essere attivi e passare il traffico. In caso di non-guasto, il traffico deve essere diviso in due tunnel che vanno verso le destinazioni corrette /25, se uno dei tunnel va giù, il tunnel restante 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 del cliente tramite la WAN interna al 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 è possibile avviare una seconda fase IPsec. Innanzitutto, emettere il comando "mostra crypto ikev2 sa" (sull'apparecchiatura Cisco) o un comando simile sull'apparecchiatura di terze parti per verificare se la sessione IKEv2 è attiva. Se la sessione IKEv2 non è attiva, i motivi potenziali potrebbero essere:

• Il traffico interessante non attiva il tunnel IPsec.

• L'elenco di accesso tunnel IPsec è configurato in modo errato.

• Nessuna connettività tra il cliente e l'endpoint del tunnel IPsec dell'istanza dedicata.

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

• Un firewall sta bloccando i pacchetti UDP IKEv2.

Innanzitutto, controllare i registri IPsec per eventuali messaggi che mostrano l'avanzamento della negoziazione del tunnel IKEv2. I registri possono indicare dove si è verificato un problema con la negoziazione IKEv2. La mancanza di messaggi di registrazione potrebbe anche indicare che la sessione IKEv2 non è attivata.

Alcuni errori comuni con la negoziazione IKEv2 sono:

• Le impostazioni per IKEv2 sul lato CPE non corrispondono al lato Cisco; ricontrollare le impostazioni indicate:

  • Verificare che la versione IKE sia la versione 2.

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

    Quando viene utilizzata la crittografia "GCM", il protocollo GCM gestisce l'autenticazione e imposta il parametro di autenticazione su NULL.

  • Verificare l'impostazione Durata.

  • Verificare il gruppo modulus Diffie Hellman.

  • Verificare le impostazioni della funzione Pseudo Random.

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

  • Consenti 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 del registro non mostrano alcuna attività di negoziazione per la fase IKEv2, potrebbe essere necessaria un'acquisizione di pacchetti.

Il lato istanza dedicata non sempre può avviare lo scambio IKEv2 e talvolta può aspettarsi che sia il lato CPE del cliente a essere l'iniziatore. Controllare la configurazione lato CPE per i seguenti prerequisiti per l'avvio della sessione IKEv2: Controllare la presenza di un elenco di accesso di crittografia IPsec per il traffico GRE (protocollo 50) dall'IP di trasporto tunnel CPE all'IP di trasporto tunnel istanza dedicata. Assicurarsi che l'interfaccia tunnel GRE sia abilitata per i keepalives GRE; se l'apparecchiatura non supporta i keepalives GRE, Cisco riceve una notifica poiché i keepalives GRE verranno abilitati sul lato istanza dedicata sul valore predefinito. Assicurarsi che BGP sia abilitato e configurato con l'indirizzo adiacente dell'IP tunnel istanza dedicata.

Una volta configurata correttamente, viene avviato il tunnel IPsec e la prima fase della negoziazione IKEv2:

• Le guarnizioni GRE dall'interfaccia tunnel GRE lato CPE all'interfaccia tunnel GRE lato Istanza dedicata.

• Sessione TCP adiacente BGP dal vicino BGP lato CPE al vicino BGP lato Istanza dedicata.

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

  Il ping non può essere l'IP per il trasporto del tunnel all'IP per il trasporto del tunnel, deve essere l'IP del tunnel all'IP del tunnel.

Se è necessaria una traccia di pacchetti per il traffico IKEv2, impostare 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 viene inserito al centro degli endpoint IPsec).

Verificare che i pacchetti UDP IKEv2 con porta 500 o 4500 vengano inviati e ricevuti da e verso l'indirizzo IP DI IPsec.

Il centro dati dell'istanza dedicata potrebbe non iniziare sempre il primo pacchetto IKEv2. Il requisito è che il dispositivo CPE sia in grado di avviare il primo pacchetto IKEv2 verso il lato istanza dedicata. Se il firewall locale lo consente, provare a eseguire il ping anche all'indirizzo IPsec remoto. Se il ping non viene eseguito correttamente dall'indirizzo IPsec locale a quello remoto, eseguire un percorso di traccia per assistenza e determinare dove viene eliminato il pacchetto. Alcuni firewall e apparecchiature Internet potrebbero non consentire tracciamenti.

Verificare che la prima fase IPsec (ovvero l'associazione di sicurezza IKEv2) sia attiva prima di risolvere i problemi della seconda fase IPsec. Eseguire un comando "show crypto ikev2 sa" o equivalente per verificare la sessione IKEv2. Nell'output, verificare che la sessione IKEv2 sia stata aperta per più di un secondo e che non stia rimbalzando. Il tempo di attività della sessione viene visualizzato come sessione "Tempo attivo" o equivalente in uscita.

Una volta che la sessione IKEv2 viene verificata come attiva e attiva, Investigare la sessione IPsec. Come per la sessione IKEv2, eseguire 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 di stabilire il tunnel GRE. Se la sessione IPsec non viene visualizzata come attiva, controllare i registri IPsec per i messaggi di errore o gli errori di negoziazione.

Alcuni dei problemi più comuni che possono essere incontrati durante i negoziati IPsec sono:

Le impostazioni sul lato CPE non corrispondono al lato Istanza dedicata; ricontrollare le impostazioni:

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

• Verificare le impostazioni Perfect Forward Secrecy e che le impostazioni corrispondano sul lato Istanza dedicata.

• Verificare le impostazioni per l'intero ciclo di vita.

• Verificare che l'IPsec sia stato configurato in modalità tunnel.

• Verificare gli indirizzi IPsec di origine e di destinazione.

Quando le sessioni IPsec e IKEv2 vengono verificate come attive e attive, i pacchetti keepalive del tunnel GRE possono 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 viene utilizzata la configurazione VRF sull'interfaccia tunnel).

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

• Le guarnizioni non sono abilitate sull'interfaccia tunnel laterale CPE

  Se i keepalive non sono supportati sull'apparecchiatura CPE, è necessario notificare Cisco in modo che anche i keepalive predefiniti sul lato istanza dedicata siano disabilitati. Se le guarnizioni sono supportate, verificare che le guarnizioni siano abilitate.

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

• L'indirizzo di trasporto del tunnel di origine o di destinazione non è corretto e non corrisponde ai valori previsti dell'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 test di ping deve verificare che l'interfaccia locale del tunnel sia attiva e che la connettività sia buona per l'interfaccia remota del tunnel. Eseguire il controllo ping dall'IP del tunnel (non dall'IP di trasporto) all'IP del tunnel remoto.

L'elenco di accesso crypto per il tunnel IPsec che trasporta il traffico tunnel GRE consente solo l'attraversamento dei pacchetti GRE. Di conseguenza, i cuscinetti non funzioneranno dall'IP di trasporto del tunnel all'IP di trasporto del tunnel remoto.

La verifica ping determina un pacchetto GRE generato dall'IP di trasporto tunnel di origine all'IP di trasporto tunnel di destinazione mentre il carico utile del pacchetto GRE (l'IP interno) sarà l'IP tunnel di origine e di destinazione.

Se il test di ping non viene superato e gli elementi precedenti vengono verificati, potrebbe essere necessaria un'acquisizione di pacchetti per assicurarsi che il ping icmp risulti in un pacchetto GRE che viene quindi incapsulato in un pacchetto IPsec e inviato dall'indirizzo IPsec di origine all'indirizzo IPsec di destinazione. I contatori sull'interfaccia tunnel GRE e i contatori sessione IPsec possono anche essere utili per la visualizzazione. Se i pacchetti di invio e ricezione aumentano.

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

Sul lato Istanza dedicata, due funzioni sono abilitate per regolare dinamicamente MTU per grandi dimensioni di pacchetti. Il tunnel GRE aggiunge altre intestazioni ai pacchetti IP che passano attraverso la sessione VPN. Il tunnel IPsec aggiunge le intestazioni aggiuntive sopra le intestazioni GRE ridurrà ulteriormente il più grande MTU consentito sopra il tunnel.

Il tunnel GRE regola la funzione MSS e il percorso del tunnel GRE nella funzione di rilevamento MTU è abilitato sul lato Istanza dedicata. Configurare "ip tcp adjustment-mss 1350" o comando equivalente nonché "tunnel path\u0002mtu-discovery" o comando equivalente sul lato cliente per aiutare con la regolazione dinamica di MTU del traffico attraverso il tunnel VPN.