Introduzione

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

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

La figura 1 mostra un esempio del modello di distribuzione di Virtual Connect per l'opzione a 2 concentratori sul lato cliente.

Connessione virtuale - VPN è un progetto di hub, in cui i siti hub del cliente sono connessi a DC1 e DC2 dei centri dati di istanza dedicata all'interno di una determinata regione.

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

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

I siti remoti 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à.

I partner devono lavorare a stretto contatto con i clienti, assicurandosi che venga scelto il percorso più ottimale per la regione di servizio 'Virtual Connect'.

La figura 2 mostra le regioni di peering della connettività cloud istanza dedicata.

Il routing per il componente aggiuntivo Virtual Connect viene implementato utilizzando BGP esterno (eBGP) tra l'istanza dedicata e CPE (Customer Premise Equipment). Cisco pubblicizzerà la rispettiva rete per ciascun controller di dominio ridondante all'interno di una regione fino al CPE del cliente e il CPE è tenuto a pubblicizzare un indirizzamento predefinito a Cisco.

• Cisco gestisce e assegna

  • Indirizzamento IP interfaccia tunnel (collegamento transitorio per l'instradamento) Cisco assegnato da uno spazio indirizzi condiviso designato (non indirizzabile pubblicamente)

  • Indirizzo di destinazione trasporto tunnel (lato Cisco)

  • Numeri di sistema autonomi privati (ASN) per la configurazione dell'instradamento BGP del cliente

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

• eBGP utilizzato per scambiare i percorsi tra istanza dedicata e CPE

  • Cisco dividerà la rete /24 assegnata in 2 /25 una per ciascun controller di dominio nella rispettiva regione

  • In Virtual Connect ciascuna rete /25 viene restituita a CPE da Cisco tramite i rispettivi tunnel VPN point-to-point (collegamento transitorio)

  • È necessario configurare CPE con i dispositivi adiacenti eBGP appropriati. Se si utilizza un CPE, verranno utilizzati due elementi adiacenti eBGP, uno che punta a ciascun tunnel remoto. Se si utilizzano due CPE, ciascun CPE avrà un vicino eBGP che indirizza al singolo tunnel remoto per il CPE.

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

  • È obbligatorio CPE per pubblicizzare un indirizzamento predefinito su ciascuno dei tunnel

  • CPE è responsabile della ridistribuzione, come richiesto, dei percorsi appresi all'interno della rete aziendale del cliente.

• In una condizione di guasto del collegamento non di errore, un singolo CPE avrà due tunnel attivi/attivi. Per due nodi CPE, ciascun CPE avrà un tunnel attivo ed entrambi i nodi CPE devono essere attivi e passare traffico. In uno scenario di non errore, il traffico deve essere suddiviso in due tunnel diretti alle destinazioni corrette /25; se uno dei tunnel scende, il tunnel rimanente può trasportare il traffico di entrambi. In uno scenario di errore di questo tipo, quando la rete /25 è inattiva, la rete /24 viene utilizzata come route di backup. Cisco invierà il traffico del cliente tramite la sua 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 viene avviata una seconda fase IPsec. In primo luogo, eseguire il comando "show crypto ikev2 sa" (su apparecchiature Cisco ) o un comando simile su apparecchiature di terze parti per verificare se la sessione IKEv2 è attiva. Se la sessione IKEv2 non è attiva, i possibili motivi potrebbero essere:

• Traffico interessante non attiva il tunnel IPsec.

• L' elenco accessi del tunnel IPsec è configurato in modo errato.

• Non esiste 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 istanza dedicata e il lato cliente.

• Un firewall sta bloccando i pacchetti IKEv2 UDP .

In primo luogo, controllare i registri IPsec per eventuali messaggi che mostrano l'avanzamento della negoziazione del tunnel IKEv2. I registri possono indicare dove si verifica un problema con la negoziazione IKEv2. Una mancanza di messaggi di registrazione può anche indicare che la sessione IKEv2 non viene attivata.

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

Il lato istanza dedicato potrebbe non iniziare sempre lo scambio IKEv2 e talvolta potrebbe essere previsto che il lato CPE del cliente sia l'iniziatore. Controllare la configurazione lato CPE per i seguenti prerequisiti per l'avvio della sessione IKEv2: Verificare la presenza di un elenco accessi di crittografia IPsec per il traffico GRE (protocollo 50) IP di trasporto del tunnel CPE IP di trasporto del tunnel dell'istanza dedicata . Assicurarsi che l'interfaccia del tunnel GRE sia abilitata per i keepalive GRE; se l'apparecchiatura non supporta i keepalive GRE, Cisco riceve una notifica poiché i keepalive GRE sono abilitati sul lato istanza dedicata per impostazione predefinita. Assicurarsi che BGP sia abilitato e configurato con l'indirizzo adiacente IP del tunnel istanza dedicato.

Se configurata correttamente, la procedura seguente avvia il tunnel IPsec e la negoziazione IKEv2 della prima fase:

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

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

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

  Il pinging non può essere l'IP di trasporto da tunnel a IP IP IP .

Se è necessaria una traccia di pacchetto per il traffico IKEv2, impostare il filtro per UDP e la porta 500 (quando nessun dispositivo NAT è in mezzo agli endpoint IPsec) o la porta 4500 (quando un dispositivo NAT viene inserito nel mezzo di IPsec endpoint).

Verificare che i pacchetti IKEv2 UDP con la 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 con 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, tentare anche di eseguire un pinging all'indirizzo IPsec remoto. Se il pinging non viene eseguito correttamente dall'indirizzo IPsec locale a quello remoto, eseguire un tracciamento della route per determinare il punto in cui il pacchetto viene abbandonato. Alcuni firewall e apparecchiature Internet potrebbero non consentire il routing di traccia.

Verificare che la prima fase IPSec (ossia, l'associazione di sicurezza IKEv2) sia attiva prima della risoluzione dei 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 attiva da più di qualche secondo e che non rimbalzi. Il tempo di attività della sessione viene visualizzato come "tempo di attività" o equivalente nell'output.

Quando la sessione IKEv2 è stata verificata come attiva e attiva, esaminare 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 stabilito il tunnel GRE. Se la sessione IPsec non viene visualizzata come attiva, controllare i registri IPsec per individuare messaggi di errore o 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 istanza dedicata, ricontrollare le impostazioni:

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

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

• Verificare le impostazioni della durata.

• Verificare che 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 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 di loopback (se si utilizza la configurazione VRF 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 del tunnel laterale CPE

  Se i keepalive non sono supportati sull'apparecchiatura CPE, è necessario Cisco in modo che anche i keepalive predefiniti sull'istanza dedicata siano disabilitati. Se sono supportati i keepalive, 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 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 da inviare al tunnel IPSec o ricevuti dal tunnel IPSec (il tunnel GRE viene trasportato sul tunnel IPSec)

Un test pinging deve verificare che l'interfaccia del tunnel locale sia attiva e che la connettività con l'interfaccia del tunnel remoto sia adeguata. Eseguire il controllo pinging IP del tunnel (non IP di trasporto) IP del tunnel remoto .

L' elenco accessi crittografico per il tunnel IPSec che trasporta il traffico del tunnel GRE consente l'incrocio solo di pacchetti GRE. Di conseguenza, i pinging non funzioneranno IP di trasporto del tunnel IP di trasporto del tunnel remoto .

Il controllo pinging produce un pacchetto GRE generato IP di trasporto del tunnel di origine 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 pinging non viene eseguito correttamente e gli elementi precedenti vengono verificati, potrebbe essere necessaria acquisizione pacchetti per garantire che il pinging icmp abbia come risultato un pacchetto GRE che viene quindi incapsulato in un pacchetto IPsec e quindi inviato dall'indirizzo IPsec di origine a l'indirizzo IPsec di destinazione. Può essere utile mostrare anche i contatori sull'interfaccia del tunnel GRE e sui contatori della sessione IPsec. se i pacchetti di invio e ricezione sono in aumento.

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

Nell'istanza dedicata, due funzioni sono abilitate per regolare in modo dinamico l'MTU per pacchetti di grandi dimensioni. Il tunnel GRE aggiunge più intestazioni ai pacchetti IP che attraversano la sessione VPN . L'aggiunta di tunnel IPsec alle intestazioni aggiuntive sopra le intestazioni GRE ridurrà ulteriormente l'MTU più grande consentito sul 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 il comando "ip tcp adjust-mss 1350" o equivalente nonché il "percorso tunnel\u0002mtu-discovery" o il comando equivalente sul lato cliente per facilitare la regolazione dinamica dell'MTU del traffico attraverso il tunnel VPN .