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 seguente mostra l'esempio di modello di distribuzione della connessione virtuale per l'opzione 2 concentratore 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 devono 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 connettività cloud dell'istanza dedicata.

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 si avvia una seconda fase IPsec. Innanzitutto, eseguire 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:

• Traffico interessante non attiva il tunnel IPsec.

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

• Non esiste connettività tra il cliente e l'IP dell'endpoint 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 tunnel IKEv2. I registri possono indicare se si verifica un problema con la negoziazione IKEv2. La mancanza di messaggi di registrazione può 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 menzionate:

  • Verificare che la versione di IKE sia la versione 2.

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

    Quando la crittografia "GCM" è in uso, il protocollo GCM gestisce l'autenticazione e imposta il parametro di autenticazione su NULL.

  • Verificare l'impostazione Durata.

  • Verificare il gruppo del modulo Diffie Hellman.

  • Verificare le impostazioni della funzione pseudo casuale.

• L'elenco di accesso per la mappa della 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 di registro non mostrano alcuna attività di negoziazione per la fase IKEv2, potrebbe essere necessario un'acquisizione di pacchetti.

Se configurato correttamente, inizia il tunnel IPsec e la negoziazione IKEv2 nella prima fase:

• Keepalive GRE dall'interfaccia tunnel GRE lato CPE all'interfaccia tunnel GRE lato istanza dedicata.

• Sessione TCP adiacente di BGP dal BGP lato CPE adiacente al BGP lato istanza dedicata.

• Eseguire il ping dall'indirizzo IP del tunnel lato CPE all'indirizzo IP del tunnel lato istanza dedicata.

  Il ping non può essere da IP di trasporto tunnel a IP di trasporto tunnel, deve essere da IP tunnel a IP.

Se è necessaria una traccia di pacchetto 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 è inserito al centro degli endpoint IPsec).

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

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

Una volta che la sessione IKEv2 viene verificata come attivata e attivata, ricercare La sessione IPsec. Come con 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 che venga creato il tunnel GRE. Se la sessione IPsec non viene visualizzata come attiva, controllare nei registri IPsec la presenza di messaggi di errore o errori di negoziazione.

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

Le impostazioni sul lato CPE non corrispondono al lato dell'istanza dedicata; controllare nuovamente le impostazioni:

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

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

• Verificare le impostazioni del 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 tunnel GRE in grado di scorrere tra l'istanza dedicata e gli endpoint tunnel CPE. Se l'interfaccia tunnel non visualizza 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 tunnel, questo controllo può essere ignorato.

• I keepalive non sono abilitati sull'interfaccia tunnel lato CPE

  Se i keepalive non sono supportati sull'apparecchiatura CPE, è necessario inviare una notifica a Cisco in modo che anche i keepalive predefiniti sul lato dell'istanza dedicata siano disabilitati.

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

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

• L'indirizzo di trasporto 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 sul tunnel IPsec)

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

Il controllo ping determina un pacchetto GRE generato dall'IP di trasporto tunnel di origine all'IP di trasporto 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, può essere necessaria una acquisizione di pacchetti per assicurare che il ping icmp risulti in un pacchetto GRE che viene poi incapsulato in un pacchetto IPsec e inviato dall'indirizzo IPsec di origine all'indirizzo IPsec di destinazione. Anche i contatori nell'interfaccia tunnel GRE e i contatori di sessione IPsec possono essere di aiuto nella visualizzazione. Se i pacchetti di invio e ricezione sono in aumento.

Oltre al traffico ping, l'acquisizione deve anche mostrare i pacchetti GRE keepalive 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é tramite la VPN.

Nel lato Istanza dedicata, due funzioni sono abilitate per regolare in modo dinamico MTU per pacchetti di grandi dimensioni. Il tunnel GRE aggiunge più 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 sul tunnel.

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