Virtual Connect utilizza un'architettura headend a due livelli, in cui il controllo DI routing e DISPONIBILIT E IL controllo BLUETOOTH sono forniti da un dispositivo e il controllo IPSec è fornito da un altro.

Al termine della connettività Virtual Connect , verranno creati due tunnelLUS su IPSec tra la rete aziendale del cliente e i centri dati dell'istanza dedicata di Cisco. Uno a ciascun centro dati ridondante all'interno della relativa Regione. Ulteriori elementi di rete richiesti per il peering vengono s scambiati dal partner o dal cliente con Cisco tramite il modulo di attivazione della Connessione virtuale Control Hub.

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

Virtual Connect - VPN è un design dell'hub in cui i siti dell'hub del cliente sono connessi al centro dati DC1 e DC2 dei centri dati di un'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.

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

La Figura 2 mostra le aree di peering della connettività cloud per istanze dedicate.

Il routing per il componente aggiuntivo Virtual Connect viene implementato utilizzando BGP (eBGP) esterno tra l'istanza dedicata e l'apparecchiatura locale del cliente (CPE). Cisco pubblicizza la relativa rete per ciascun controller di dominio ridondante all'interno di una regione al CPE del cliente e al CPE viene richiesto di pubblicizzare un indirizzo predefinito a Cisco.

• Cisco gestisce e assegna

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

  • Indirizzo di desitiazione trasporto tunnel (lato Cisco)

  • Numeri di sistema autonomi privati (ASNs) per la configurazione di indirizzamento BGP del cliente

    • Cisco assegna dall'intervallo di utilizzo privato indicato: Da 64512 a 65534

• eBGP utilizzato per scambiare percorsi tra istanza dedicata e CPE

  • Cisco dividerà la rete assegnata /24 in una da 2/25 per ciascun dc nella relativa regione

  • In Virtual Connect, ogni rete /25 viene pubblicizzato nuovamente a CPE da Cisco sui relativi tunnel VPN punto-punto (collegamento transitorio)

  • CPE deve essere configurato con l'eBGP appropriato. Se si utilizza un CPE, verranno utilizzati due tunnel eBGP, uno che punta a ciascun tunnel remoto. Se si utilizza due CPE, ogni CPE di avrà un eBGP vicino che utilizza il tunnel remoto per il CPE.

  • Il lato Cisco di ogni tunnel TUNNEL (IP interfaccia tunnel) è configurato come BGP vicino su CPE

  • CPE è richiesto per pubblicizzare un route predefinito su ciascun tunnel

  • CPE è ridistribuibile per ridistribuire, come richiesto, gli indirizzamenti appresi all'interno della rete aziendale del cutomer.

• In una condizione di errore del collegamento non di errore, un singolo CPE diserà due tunnel attivi/attivi. Per due nodi CPE, ciascun CPE di avrà un tunnel attivo ed entrambi i nodi CPE devono essere attivi e passano il traffico. In uno scenario non di errore, il traffico deve essere suddiviso in due tunnel andando alle destinazioni /25 corrette, se uno del tunnel è in basso, il tunnel restante può contenere il traffico per entrambi. In tale scenario di errore, quando la rete /25 è in errore, viene utilizzata la rete /24 come percorso di backup. Cisco invierà il traffico dei clienti attraverso la relativa wan interna al controller di dominio 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.

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.

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.

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.