- Home
- /
- Articolo
Grazie per il feedback.
Connessione virtuale a istanza dedicata
In questo articolo
Feedback?Virtual Connect è un'opzione aggiuntiva per la connettività cloud all'istanza dedicata di Webex Calling. Virtual Connect consente ai clienti di estendere in modo sicuro la rete privata su Internet utilizzando tunnel IP VPN da punto a punto. Qui parleremo di come ordinare, attivare e configurare Virtual Connect.
Introduzione
Virtual Connect è un'opzione aggiuntiva per la connettività cloud per istanza dedicata per Webex Calling (istanza dedicata). Virtual Connect consente ai clienti di estendere in modo sicuro la rete privata su Internet utilizzando tunnel IP VPN da punto a punto. Questa opzione di connettività consente di utilizzare rapidamente la connessione alla rete privata utilizzando l'apparecchiatura locale del cliente (CPE) esistente e la connettività Internet.
Cisco ospita, gestisce e assicura i tunnel VPN IP ridondanti e l'accesso a Internet richiesto nelle aree dati dell'istanza dedicata di Cisco in cui è richiesto il servizio. Allo stesso modo, Amministratore è responsabile dei corrispondenti servizi CPE e Internet richiesti per Virtual Connect.
Ciascun ordine Virtual Connect in una determinata regione di istanza dedicata include due tunnel di indirizzamento GENERICI protetti da crittografia IPSec (DISPONIBILI su IPSec), uno per ciascun centro dati di Cisco nella regione selezionata.
Virtual Connect ha un limite di larghezza di banda di 250 Mbps per tunnel ed è consigliato per distribuzioni di dimensioni più ridotte. Poiché vengono utilizzati due tunnel VPN punto-punto, tutto il traffico verso il cloud deve passare attraverso il headend CPE del cliente, quindi potrebbe non essere adatto nei siti remoti. Per altre opzioni di peering, fare riferimento a Connettività cloud.
Prima di inviare la richiesta di peering per Virtual Connect, assicurati che il servizio Istanza dedicata sia attivato nella rispettiva regione.
Prerequisiti
I prerequisiti per stabilire Virtual Connect includono:
-
Il cliente fornisce
-
Connessione Internet con larghezza di banda sufficiente per supportare la distribuzione
-
Indirizzi IP pubblici per due tunnel IPSec
-
Indirizzi IP di trasporto ANCORA DISPONIBILI sul lato cliente per i due tunnel ... ...
-
-
Partner e clienti
-
Collaborare per valutare i requisiti di larghezza di banda
-
Assicurarsi che i dispositivi di rete supportino l'instradamento Border Gateway Protocol (BGP) e un design TUNNEL BLUETOOTH su IPSec
-
-
Partner o cliente forniscono
-
Team di rete con conoscenza delle tecnologie del tunnel VPN sito-sito
-
Team di rete con conoscenza di BGP, eBGP e principi di indirizzamento generali
-
-
Cisco
-
Cisco ha assegnato numeri di sistema automatici privati (ASN) e indirizzamento IP transitorio per interfacce tunnel RES
-
Cisco ha assegnato una rete pubblica ma non indirizzabile a Internet Classe C (/24) per l'indirizzamento cloud a istanza dedicata
-
Se un cliente dispone di solo 1 dispositivo CPE, i 2 tunnel verso i centri dati di Cisco (DC1 e DC2) in ciascuna regione, verranno provenienti da tale dispositivo CPE. Il cliente dispone anche di un'opzione per 2 dispositivi CPE, quindi ciascun dispositivo CPE deve connettersi a 1 tunnel solo ai centri dati di Cisco (DC1 e DC2) in ciascuna regione. È possibile ottenere ulteriore ridondanza terminando ciascun tunnel in un sito/posizione fisica separato all'interno dell'infrastruttura del cliente.
Dettagli tecnici
Modello di distribuzione
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 del modello di distribuzione della connessione virtuale per l'opzione a 2 concentratori 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.
La larghezza di banda per tunnel è limitata a 250 Mbps. Per garantire un failover efficace, il traffico combinato attraverso entrambi i tunnel non deve superare i 250 Mbps, poiché in caso di guasto tutto il traffico verrà instradato attraverso un unico tunnel.
I siti remoti del cliente all'interno della stessa regione, devono connettersi nuovamente ai siti Hub sulla WAN del cliente e non è responsabilità di Cisco per tale connettività.
Ci si aspetta che i partner collaborino a stretto contatto con i clienti, assicurando che venga scelto il percorso più ottimale per la regione del servizio Virtual Connect.
La figura sottostante mostra le regioni di peering della connettività cloud delle istanze dedicate.
Inoltro
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à.
Flusso di traffico di connessione virtuale
Flusso del traffico quando entrambi i tunnel sono in funzione
Questa immagine illustra un'architettura di rete Virtual Connect, che descrive in dettaglio il flusso del traffico quando sono operativi sia i tunnel primari che quelli secondari.
Rappresenta un modello di connettività attiva per consentire a un cliente di accedere alle applicazioni UC ospitate nei data center di Cisco, sfruttando il doppio GRE/IPSEC tunnel su Internet con BGP per lo scambio di rotte.
Definizioni:
- Sede del cliente:
- Rappresenta la rete in loco del cliente, in cui si trovano gli utenti e i loro dispositivi (ad esempio telefoni IP, computer che eseguono client UC).
- Il traffico proveniente da qui deve raggiungere le applicazioni UC ospitate nei data center Cisco.
- Data center Cisco Webex Calling Dedicated Instance (istanza dedicata) (WxC-DI DC-A e WxC-DI DC-B):
- Questi sono i data center di Cisco che ospitano le applicazioni UC.
- DC-A e DC-B sono geograficamente distinti, garantendo ridondanza.
- Ogni data center ha la propria subnet per le applicazioni UC:
- DC-A subnet:X.X.X.0/25
- DC-B subnet:X.X.X.128/25
- GRE/IPsec Gallerie (Tunnel 1 e Tunnel 2):
- Si tratta di connessioni sicure e crittografate tra la sede del clientee il data center Cisco tramite la rete Internet pubblica.
- GRE (incapsulamento del routing generico): Questo protocollo viene utilizzato per incapsulare vari protocolli di livello di rete all'interno di collegamenti virtuali punto-punto. Consente ai protocolli di routing come BGP di operare attraverso il tunnel.
- IPsec (protocollo di sicurezza Internet): Questa serie di protocolli fornisce servizi di sicurezza crittografica (autenticazione, integrità, riservatezza) per le comunicazioni IP. Crittografa il traffico incapsulato in GRE, garantendo una trasmissione sicura dei dati su Internet.
- Protocollo di gateway di confine (BGP):
- BGP è il protocollo di routing utilizzato per scambiare informazioni di routing tra la sede del cliente e i data centerCisco .
Come mostrato nel diagramma sopra, i dispositivi distribuiti presso i locali del cliente devono stabilire due GRE/IPSEC gallerie.
Le convenzioni di denominazione utilizzate di seguito con XX / YY, DC-A DC-B sono generici per tutte le regioni in cui viene offerta l'istanza dedicata. Questi valori saranno unici per ogni regione e i valori effettivi per ogni regione. I valori specifici vengono forniti durante l'attivazione della connessione virtuale.
Sul lato Cisco i tunnel IPSec e GRE verranno terminati su dispositivi diversi. Pertanto il cliente deve assicurarsi di configurare di conseguenza gli IP di destinazione IPSec e GRE sui dispositivi. I clienti possono utilizzare lo stesso IP per GRE e IPSEC se supportato sui loro dispositivi. Fare riferimento allo schema sopra. I valori relativi all'IP vengono forniti durante l'attivazione della connessione virtuale sul portale.
- Tunnel 1: Collega la sede del cliente all'"istanza dedicata DC-A" (Data Center A) tramite Internet. Questo tunnel utilizza BGP AS:64XX1 sul lato cliente e BGP AS:64XX2 sul lato DC-A dell'istanza dedicata. Le configurazioni sorgente del tunnel IPSEC e GRE sono suddivise tra dettagli forniti dal cliente e dettagli forniti da Cisco.
- Tunnel 2: Collega la sede del cliente all'"istanza dedicata DC-B" (Data Center B) tramite Internet. Questo tunnel utilizza BGP AS:64YY1 sul lato cliente e BGP AS:64YY2 sul lato DC-B dell'istanza dedicata. Come per il Tunnel 1, le configurazioni sorgente del tunnel IPSEC e GRE sono condivise tra il cliente e Cisco.
Nel BGP AS:64XX e BGP AS:64YY, XX e YY sono specifici di una determinata regione.
Una volta il GRE/IPSEC vengono stabiliti tunnel verso i data center di istanze dedicate di Webex Calling (A e B), il cliente dovrebbe ricevere i seguenti percorsi pubblicizzati da Cisco sulle sessioni BGP corrispondenti.
- Per DC-A: I percorsi pubblicizzati da Cisco saranno X.X.X.0/25 E X.X.x.0/24. Facoltativamente se IaaS è richiesto e configurato per i percorsi del cliente Y.Y.Y.0/25 E Y.Y.Y.0/24 verrà pubblicizzato da Cisco.
- Per DC-B: I percorsi pubblicizzati da Cisco saranno X.X.X.128/25 E X.X.x.0/24. Facoltativamente se IaaS è richiesto e configurato per i percorsi del cliente Y.Y.Y.128/25 E Y.Y.Y.0/24 verrà pubblicizzato da Cisco.
- Il cliente ha bisogno di pubblicizzare il 0.0.0./0 percorso verso Cisco attraverso entrambe le connessioni (tunnel)
- Il cliente deve seguire il prefisso più lungo (/25) percorsi per inviare traffico a Cisco attraverso i rispettivi tunnel quando entrambi i tunnel sono attivi.
- Cisco restituirà il traffico attraverso gli stessi tunnel per mantenerlo simmetrico.
Flusso del traffico:
- Traffico destinato a "DC-A UC Apps" (X.X.X.0/25) dai locali del cliente scorre attraverso il Tunnel 1.
- Traffico destinato a "DC-B UC Apps" (X.X.X.128/25) dai locali del cliente scorre attraverso il Tunnel 2.
Scenario di failover : flusso del traffico quando uno dei tunnel è inattivo
Come mostrato nel diagramma sopra, quando il tunnel verso DC-A è inattivo, il BGP stabilito tramite il tunnel verso DC-A non sarà attivo.
Impatto su BGP: Quando il Tunnel 1 si interrompe, anche la sessione BGP su quel tunnel si interromperà. Di conseguenza, DC-A non sarà più in grado di pubblicizzare i suoi percorsi (in particolare X.X.X.0/25) al cliente tramite questo percorso. Pertanto il router del cliente rileverà il percorso come irraggiungibile.
Poiché il Tunnel 1 non è disponibile, il router del cliente presso la sede del cliente rimuoverà automaticamente i percorsi appresi tramite il Tunnel 1 dalla propria tabella di routing o li contrassegnerà come non raggiungibili.
- Traffico destinato alla rete UC App (X.X.X.0/24) o la sottorete DC-A (X.X.X.0/25) verrà poi reindirizzato attraverso il tunnel di lavoro verso DC-B che continua a pubblicizzare il X.X.X.0/24 che include il X.X.X.0/25 rete.
- Un comportamento simile si verificherà se il tunnel verso DC-B è inattivo mentre il tunnel verso DC-A è ancora attivo.
Processo di connettività
| 1 | |
| 2 | |
| 3 | |
| 4 |
Passaggio 1: Ordine CCW
Virtual Connect è un componente aggiuntivo per l'istanza dedicata in CCW.
| 1 |
Passare al sito di ordinazione CCW, quindi fare clic su Accedi per accedere al sito: |
| 2 |
Crea stima. |
| 3 |
Aggiungi SKU "A-FLEX-3". |
| 4 |
Selezionare Modifica opzioni. |
| 5 |
Nella scheda sottoscrizione visualizzata, selezionare Opzioni e componenti aggiuntivi. |
| 6 |
In Componenti aggiuntivi, selezionare la casella di controllo accanto a "Connessione virtuale per istanza dedicata". Il nome SKU è "A-FLEX-DI-VC". |
| 7 |
Immettere la quantità e il numero di regioni in cui è necessario Virtual Connect. La quantità di Virtual Connect non deve superare il numero totale di regioni acquistate per l'istanza dedicata. Inoltre, è consentito un solo ordine Virtual Connect per regione. |
| 8 |
Una volta soddisfatti delle selezioni, fare clic su Verifica e salva nella parte superiore destra della pagina. |
| 9 |
Fare clic su Salva e continua per finalizzare l'ordine. L'ordine finalizzato ora viene completato nella griglia dell'ordine. |
Passaggio 2: Attivazione di Virtual Connect in Control Hub
| 1 |
Accedere a Control Hub https://admin.webex.com/login. |
| 2 |
Nella sezione Servizi , andare a Chiamata > instacnce dedicata > connettività Cloud. |
| 3 |
Nella scheda Virtual Connect, viene elencata la quantità acquistata di Virtual Connect. L'amministratore ora può fare clic su Activate (Attiva ) per avviare l'attivazione di Virtual Connect.  Il processo di attivazione può essere attivato solo dagli amministratori con ruolo di "amministratore completo cliente". Mentre un amministratore con ruolo di "amministratore di sola lettura cliente" può solo visualizzare lo stato. |
| 4 |
Facendo clic sul pulsante Activate (Attiva), viene visualizzato il modulo Activate Virtual Connect (Attiva Virtual Connect) che l'amministratore deve fornire all'amministratore per fornire i dettagli tecnici Virtual Connect richiesti per le configurazioni di peering lato Cisco. Il modulo fornisce anche informazioni statiche sul lato Cisco, in base alla regione selezionata. Queste informazioni saranno utili agli amministratori dei clienti per configurare cpe sul proprio lato per stabilire la connettività. |
| 5 |
Fare clic sul pulsante Attiva una volta inseriti tutti i campi obbligatori. |
| 6 |
Dopo aver completato il modulo di attivazione di Virtual Connect per una regione particluar, il cliente può esportare il modulo di attivazione da Control Hub, Calling > Dedicated Instance > Cloud Connectivity (Connettività cloud) e fare clic su Esporta impostazioni.  Per motivi di sicurezza, l'autenticazione e la password BGP non saranno disponibili nel documento esportato, ma l'amministratore può visualizzarle in Control Hub facendo clic su Visualizza impostazioni in Control Hub, Chiamata > Istanza dedicata > Scheda Connettività cloud. |
Passaggio 3: Cisco esegue la configurazione di rete
| 1 |
Una volta completato il modulo di attivazione di Virtual Connect, lo stato verrà aggiornato su Attivazione in corso nella chiamata > istanza dedicata > Cloud Connectivity Virtual Connect. |
| 2 |
Cisco completerà le configurazioni richieste sulle apparecchiature laterali Cisco entro 5 giorni lavorativi. Una volta completato correttamente, lo stato verrà aggiornato su "Attivato" per una determinata regione in Control Hub. |
Passaggio 4: Il cliente esegue la configurazione di rete
|
Lo stato viene modificato in "Attivato" per informare l'amministratore del cliente che il lato della configurazione di Cisco per la connettività IP VPN è stato completato in base agli input forniti dal cliente. Tuttavia, è previsto che l'amministratore del cliente completi il proprio lato delle configurazioni sui CPI e test gli indirizzari di connettività per il tunnel Virtual Connect online. In caso di problemi che possono verificarsi al momento della configurazione o della connettività, il cliente può contattare il Cisco TAC per assistenza. |
Risoluzione dei problemi
Risoluzione dei problemi e convalida della prima fase di IPsec (negoziazione IKEv2)
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. Per prima cosa, emettere 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, le possibili cause 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 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 blocca i pacchetti IKEv2 UDP.
Per prima cosa, controlla i log IPsec per individuare eventuali messaggi che mostrano l'avanzamento della negoziazione del tunnel IKEv2. I registri potrebbero indicare dove si è verificato un problema con la negoziazione IKEv2. L'assenza di messaggi di registrazione potrebbe anche indicare che la sessione IKEv2 non è attivata.
Alcuni errori comuni nella negoziazione IKEv2 sono:
-
Le impostazioni per IKEv2 sul lato CPE non corrispondono al lato Cisco, ricontrollare le impostazioni menzionate:
-
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 utilizzato il cifrario "GCM", il protocollo GCM gestisce l'autenticazione e imposta il parametro di autenticazione su NULL.
-
Verificare l'impostazione della durata.
-
Verificare il gruppo dei moduli di Diffie-Hellman.
-
Verificare le impostazioni della funzione Pseudo Random.
-
-
L'elenco di accesso per la mappa crittografica 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 necessaria l'acquisizione di un pacchetto.
Il lato istanza dedicato potrebbe non sempre avviare lo scambio IKEv2 e talvolta potrebbe aspettarsi 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 di accesso crittografico IPsec per il traffico GRE (protocollo 50) dall'IP di trasporto del tunnel CPE all'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 verrà avvisato perché i keepalive GRE saranno abilitati per impostazione predefinita sul lato dell'istanza dedicata.
-
Assicurarsi che BGP sia abilitato e configurato con l'indirizzo del vicino dell'IP del tunnel dell'istanza dedicata.
Se configurato correttamente, il seguente comando avvia il tunnel IPsec e la negoziazione IKEv2 di prima fase:
-
Keepalive GRE dall'interfaccia del tunnel GRE lato CPE all'interfaccia del tunnel GRE lato istanza dedicata.
-
Sessione TCP del vicino BGP dal vicino BGP lato CPE al vicino BGP lato istanza dedicata.
-
Eseguire il ping dall'indirizzo IP del tunnel laterale CPE all'indirizzo IP del tunnel laterale dell'istanza dedicata.
Il ping non può essere da un IP di trasporto del tunnel a un altro IP di trasporto del tunnel, ma deve essere da un IP del tunnel a un altro IP del tunnel.
Se è necessaria una traccia dei pacchetti per il traffico IKEv2, impostare il filtro per UDP e la porta 500 (quando non è presente alcun dispositivo NAT tra gli endpoint IPsec) oppure la porta 4500 (quando è inserito un dispositivo NAT tra gli endpoint IPsec).
Verificare che i pacchetti IKEv2 UDP con porta 500 o 4500 vengano inviati e ricevuti da e verso l'indirizzo IP IPsec DI.
Il data center dell'istanza dedicata potrebbe non sempre avviare il primo pacchetto IKEv2. Il requisito è che il dispositivo CPE sia in grado di avviare il primo pacchetto IKEv2 verso il lato dell'istanza dedicata.
Se il firewall locale lo consente, provare anche a effettuare un ping all'indirizzo IPsec remoto. Se il ping dall'indirizzo IPsec locale a quello remoto non riesce, eseguire un traceroute per aiutare e determinare dove è stato eliminato il pacchetto.
Alcuni firewall e apparecchiature Internet potrebbero non consentire il traceroute.
Risoluzione dei problemi e convalida della seconda fase di IPsec (negoziazione 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 attiva da più di qualche secondo e che non ci siano rimbalzi. Il tempo di attività della sessione viene visualizzato come "Tempo attivo" della sessione o come valore equivalente nell'output.
Una volta verificata l'attività della sessione IKEv2, esaminare 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 quella 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 eventuali 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 le impostazioni Perfect Forward Secrecy e che corrispondano alle impostazioni sul lato Istanza dedicata.
-
Verificare le impostazioni di durata.
-
Verificare che IPsec sia stato configurato in modalità tunnel.
-
Verificare gli indirizzi IPsec di origine e di destinazione.
Risoluzione dei problemi e convalida dell'interfaccia del tunnel
Quando le sessioni IPsec e IKEv2 vengono verificate come attive, i pacchetti keepalive del tunnel GRE possono fluire tra gli endpoint dell'istanza dedicata e del tunnel CPE. Se l'interfaccia del tunnel non mostra lo stato, ecco alcuni problemi comuni:
-
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 CPE
Se i keepalive non sono supportati sull'apparecchiatura CPE, è necessario avvisare Cisco in modo che vengano disabilitati anche i keepalive predefiniti sul lato istanza dedicata.
Se i keepalive sono supportati, verificare che siano abilitati.
-
La maschera o l'indirizzo IP dell'interfaccia del tunnel non sono corretti e non corrispondono 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 blocca l'invio dei pacchetti GRE nel tunnel IPsec o la loro ricezione dal tunnel IPsec (il tunnel GRE viene trasportato tramite il tunnel IPsec)
Un test ping dovrebbe verificare che l'interfaccia del tunnel locale sia attiva e che la connettività con l'interfaccia del tunnel remoto sia buona. Eseguire il controllo ping dall'IP del tunnel (non l'IP di trasporto) all'IP del tunnel remoto.
L'elenco di accesso crittografico per il tunnel IPsec che trasporta il traffico del tunnel GRE consente l'attraversamento solo ai pacchetti GRE. Di conseguenza, i ping non funzioneranno dall'IP di trasporto del tunnel all'IP di trasporto del tunnel remoto.
Il controllo ping genera un pacchetto GRE che viene 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à costituito dagli IP del tunnel di origine e di destinazione.
Se il test ping non riesce e gli elementi precedenti sono verificati, potrebbe essere necessaria l'acquisizione di un pacchetto per garantire che il ping icmp generi un pacchetto GRE, il quale viene poi incapsulato in un pacchetto IPsec e inviato dall'indirizzo IPsec di origine all'indirizzo IPsec di destinazione. Anche i contatori sull'interfaccia del tunnel GRE e i contatori di sessione IPsec possono aiutare a mostrare se i pacchetti inviati e ricevuti sono in incremento.
Oltre al traffico ping, la cattura dovrebbe mostrare anche i pacchetti GRE keepalive anche durante il traffico inattivo. Infine, se è configurato BGP, i pacchetti BGP keepalive devono essere inviati anche come pacchetti GRE incapsulati in pacchetti IPSEC tramite VPN.
Risoluzione dei problemi e convalida BGP
Sessioni BGP
BGP è richiesto come protocollo di routing sul tunnel VPN IPsec. Il vicino BGP locale dovrebbe stabilire una sessione eBGP con il vicino BGP dell'istanza dedicata. Gli indirizzi IP dei vicini eBGP sono gli stessi degli indirizzi IP del tunnel locale e remoto. Per prima cosa assicurati che la sessione BGP sia attiva, quindi verifica che i percorsi corretti vengano ricevuti dall'istanza dedicata e che il percorso predefinito corretto venga inviato all'istanza dedicata.
Se il tunnel GRE è attivo, verificare che il ping tra l'IP locale e quello remoto del tunnel GRE abbia esito positivo. Se il ping riesce ma la sessione BGP non si avvia, esaminare il registro BGP per individuare eventuali errori di instaurazione BGP.
Alcuni dei problemi più comuni nella negoziazione BGP sono:
-
Il numero AS remoto non corrisponde al numero AS configurato sul lato istanza dedicata. Ricontrollare la configurazione AS del vicino.
-
Il numero AS locale non corrisponde a quanto previsto dal lato istanza dedicata. Verificare che il numero AS locale corrisponda ai parametri previsti per l'istanza dedicata.
-
Un firewall blocca i pacchetti BGP TCP incapsulati nei pacchetti GRE dall'invio al tunnel IPsec o dalla ricezione dal tunnel IPSec
-
L'IP del vicino BGP remoto non corrisponde all'IP del tunnel GRE remoto.
Scambio di rotte BGP
Una volta verificata la sessione BGP per entrambi i tunnel, assicurarsi che vengano inviati e ricevuti i percorsi corretti dal lato dell'istanza dedicata.
La soluzione VPN con istanza dedicata prevede che vengano stabiliti due tunnel dall' customer/partner lato. Il primo tunnel punta al datacenter A dell'istanza dedicata e il secondo tunnel punta al datacenter B dell'istanza dedicata. Entrambi i tunnel devono essere in stato attivo e la soluzione richiede un active/active distribuzione. Ogni data center di istanza dedicata pubblicizzerà la propria istanza locale /25 percorso così come un /24 percorso di backup. Quando si controllano i percorsi BGP in arrivo dall'istanza dedicata, assicurarsi che la sessione BGP associata al tunnel che punta al datacenter A dell'istanza dedicata riceva il datacenter A dell'istanza dedicata /25 percorso locale così come il /24 percorso di backup. Inoltre, assicurarsi che il tunnel che punta al datacenter B dell'istanza dedicata riceva il datacenter B dell'istanza dedicata /25 percorso locale così come il /24 percorso di backup. Nota che il /24 il percorso di backup sarà lo stesso percorso pubblicizzato dal datacenter A dell'istanza dedicata e dal datacenter B dell'istanza dedicata.
La ridondanza viene fornita a un data center di un'istanza dedicata nel caso in cui l'interfaccia del tunnel verso quel data center si interrompa. Se la connettività al datacenter A dell'istanza dedicata viene persa, il traffico verrà inoltrato dal datacenter B dell'istanza dedicata al datacenter A. In questo scenario, il tunnel verso il datacenter B utilizzerà il datacenter B /25 percorso per inviare traffico al datacenter B e il tunnel per il datacenter B utilizzerà il backup /24 percorso per inviare traffico al datacenter A tramite il datacenter B.
È importante che, quando entrambi i tunnel sono attivi, il tunnel del data center A non venga utilizzato per inviare traffico al data center B e viceversa. In questo scenario, se il traffico viene inviato al datacenter A con destinazione il datacenter B, il datacenter A inoltrerà il traffico al datacenter B, il quale tenterà quindi di inviare il traffico alla sorgente tramite il tunnel del datacenter B. Ciò darà luogo a un routing non ottimale e potrebbe anche interrompere il traffico che attraversa i firewall. Pertanto, è importante che entrambi i tunnel siano in un active/active configurazione durante il normale funzionamento.
IL 0.0.0.0/0 il percorso deve essere pubblicizzato dal lato cliente al lato datacenter dell'istanza dedicata. Percorsi più specifici non saranno accettati dal lato Istanza dedicata. Assicurare che il 0.0.0.0/0 il percorso viene pubblicizzato sia dal tunnel A del datacenter dell'istanza dedicata che dal tunnel B del datacenter dell'istanza dedicata.
Configurazione MTU
Sul lato Istanza dedicata, sono abilitate due funzionalità per regolare dinamicamente l'MTU per pacchetti di grandi dimensioni. Il tunnel GRE aggiunge più intestazioni ai pacchetti IP che scorrono attraverso la sessione VPN. Il tunnel IPsec aggiunge intestazioni aggiuntive sopra le intestazioni GRE, riducendo ulteriormente l'MTU massimo consentito sul tunnel.
Il tunnel GRE regola la funzionalità MSS e il percorso del tunnel GRE nella funzionalità di individuazione MTU è abilitato sul lato dell'istanza dedicata. Configurare "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.
