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.

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 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.


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


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à.

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.

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à.

Processo di connettività

Di seguito viene descritto come stabilire la connettività con La connessione virtuale per istanza dedicata.

1

Estrae un ordine in Cisco CCW

2

Attiva Virtual Connect da Control Hub

3

Cisco esegue la configurazione di rete

4

Il cliente esegue la configurazione di rete

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.

Passo 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à.
  1. INDIRIZZO IP di trasporto TUNNEL TUNNEL TUNNEL:Il cliente deve fornire gli indirizzi IP di trasporto tunnel lato cliente e Cisco alloca dinamicamente gli indirizzi IP una volta completata l'attivazione.L'ACL IPSec per traffico interessanti deve consentire l'IP di trasporto tunnel locale/32 all'IP di trasporto del tunnel remoto/32.L'ACL deve anche specificare solo il protocollo IP DISPONIBILI.


     
    L'indirizzo IP fornito dal cliente può essere privato o pubblico.
  2. PeerIPSec:Il cliente deve fornire gli indirizzi IP di origine del tunnel IPSec e Cisco alloca l'indirizzo IP di destinazione IPSec.È supportata anche la conversione NAT di un indirizzo tunnel IPSEC interno in un indirizzo pubblico.


     

    L'indirizzo IP fornito dal cliente deve essere pubblico.


     
    Tutte le altre informazioni statiche fornite nella schermata di attivazione sono gli standard di sicurezza e crittografia lato Cisco seguiti.Questa configurazione statica non è personalizzabile o modificabile.Per ulteriore assistenza relativa alle configurazioni statiche sul lato Cisco, il cliente deve contattare il Tac.
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ò visualizzare lo stesso in Control Hub facendo clic su Visualizza impostazioni in Control Hub, Chiamata > istanza dedicata > 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 sull'apparecchiatura lato Cisco entro 4 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 di prima fase (IKEv2 Negoziazione IKEv2)

La negoziazione del tunnel IPsec prevede due fasi, la fase IKEv2 e la fase IPsec.Se la negoziazione di fase IKEv2 non viene completata, non viene avviata una seconda fase IPsec.In primo luogo, eseguire il comando "show crypto ikev2 sa" (su 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 potenziali motivi potrebbero essere:

  • Traffico interessanti non attiva il tunnel IPsec.

  • L'elenco di accesso al tunnel IPsec non è configurato correttamente.

  • Non esiste connettività tra il cliente e l'IP dell'endpoint tunnel IPsec dedicato.

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

  • Un firewall sta bloccando i pacchetti IKEv2 UDP.

Innanzitutto, controllare i registri IPsec per qualsiasi messaggio che mostra l'avanzamento della negoziazione tunnel IKEv2.I registri potrebbero indicare qual è un problema con la negoziazione IKEv2.La mancanza di messaggi di registrazione può anche indicare che la sessione IKEv2 non viene attivata.

Alcuni errori comuni con la negoziazione IKEv2 sono:
  • Le impostazioni per il proxy 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 la crittografia "GCM" è in uso, il protocollo GCM gestisce l'autenticazione e imposta il parametro di autenticazione su NULL.

    • Verificare l'impostazione della durata di vita.

    • Verificare il gruppo di modulus Diffie Hellman.

    • Verificare le impostazioni della funzione casuale Sistema casuale.

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

    • CONSENTI PIÙ () 255.255.255.255 (local_tunnel_transport_ipremote_tunnel_transport_ip) 255.255.255.255" (o comando equivalente)


      L'elenco di accesso deve essere specifico per il protocollo "GR" e il protocollo "IP" non funzionerà.

Se i messaggi del log non mostrano attività di negoziazione per la fase IKEv2, potrebbe essere necessaria un'acquisizione del pacchetto.


Il lato istanza dedicata potrebbe non iniziare sempre lo scambio di IKEv2 e prevedere che il lato CPE del cliente sia l'iniziatore.

Controllare la configurazione lato CPE per i seguenti prerequisiti per l'avvio della sessione IKEv2:

  • Controllare un elenco di accesso crittografico IPsec per il traffico VPN (protocollo 50) dall'IP di trasporto tunnel CPE all'IP di trasporto tunnel dell'istanza dedicata.

  • Assicurarsi che l'interfaccia tunnel DISPONIBILI sia abilitata per LE manerci, se l'apparecchiatura non supporta il keepalives RES, quindi Cisco viene informato perché il keepalialives INAS viene abilitato sul lato istanza dedicata per impostazione predefinita.

  • Assicurarsi che BGP sia abilitato e configurato con l'indirizzo vicino dell'IP tunnel dell'istanza dedicata.

Se configurato correttamente, il tunnel IPsec e la negoziazione IKEv2 della prima fase iniziano il tunnel IPsec2:

  • RE keepalialive dall'interfaccia tunnel CPE SIDE SIA ALL'interfaccia tunnel SQL lato Dedicato.

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

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


    Il ping non può essere l'IP di trasporto tunnel verso l'IP di trasporto tunnel; deve essere un indirizzo IP tunnel-IP tunnel.

Se è necessaria una traccia di pacchetto per il traffico IKEv2, impostare il filtro per UDP e la porta 500 (se non si trova alcun 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 IKEv2 UDP con porta 500 o 4500 siano inviati e ricevuti da e verso l'indirizzo IP DI IPsec.


Il centro dati per 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 dell'istanza dedicata.

Se il firewall locale, provare a effettuare un ping all'indirizzo IPsec remoto.Se il ping non riesce da locale a indirizzo IPsec remoto, eseguire una traccia di indirizzamento per assistenza e determinare dove viene eliminato il pacchetto.

Alcuni firewall e apparecchiature Internet potrebbero non consentire traccia di route.

Risoluzione dei problemi e convalida di seconda fase (negoziazione IPsec) IPsec

Verificare che la prima fase di IPsec (ovvero, 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 per più di alcuni secondi e che non sia in corso la ricerca.Il tempo di attività della sessione viene visualizzato come "Tempo attivo" o equivalente nell'output.

Una volta che la sessione IKEv2 verifica come attiva e attiva, ricercare la sessione IPsec.In modo come per la sessione IKEv2, eseguire un comando "show crypto ipsec sa" o equivalente per verificare la sessione IPsec.Entrambe la sessione IKEv2 e la sessione IPsec devono essere attive prima di stabilire il tunnel KPI.Se la sessione IPsec non viene mostrata come attiva, controllare nei registri IPsec la presenza di messaggi di errore o di errori di negoziazione.

Di seguito alcuni dei problemi più comuni che possono essere riscontrati durante l'esecuzione di IPsec:

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 della Protezione in avanti perfetta e che le impostazioni corrispondano sul lato Istanza dedicata.

  • Verificare le impostazioni della durata di vita.

  • 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 tunnel

Quando le sessioni IPsec e IKEv2 sono state verificate come attive e attivo, i pacchetti keepalive del tunnel KPI possono passare tra l'istanza dedicata e gli endpoint tunnel CPE.Se l'interfaccia tunnel non mostra lo stato, si verificano alcuni problemi comuni:

  • Il trasporto dell'interfaccia tunnel MEGAF non corrisponde al MEGAF dell'interfaccia di loopback (se la configurazione MEGAF viene utilizzata sull'interfaccia tunnel).


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

  • Gli keep-alias non sono abilitati sull'interfaccia tunnel laterale CPE


    Se i keepalives non sono supportati sull'apparecchiatura CPE, è necessario notificare Cisco in modo che anche gli keepalidi predefiniti sul lato istanza dedicata siano disabilitati.

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

  • La mask o l'indirizzo IP dell'interfaccia tunnel non è corretta e non corrisponde 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 sta bloccando i pacchetti CUI vengono inviati nel tunnel IPsec o ricevuti dal tunnel IPsec (il tunnel KPI viene trasportato sul tunnel IPsec)

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


L'elenco di accesso crittografico per il tunnel IPsec che porta il traffico tunnel KPI consente solo l'attraversatura di pacchettiRERE.Di conseguenza, i ping non funzionano da IP di trasporto del tunnel a IP di trasporto del tunnel remoto.

Il controllo ping determina un pacchetto CONTEMPO generato dall'IP di trasporto del tunnel di origine all'IP di trasporto del tunnel di destinazione mentre il carico utile del pacchetto CONTEMPO (indirizzo IP interno) sarà l'IP del tunnel di origine e di destinazione.

Se il test del ping non viene eseguito correttamente e i precedenti elementi vengono verificati, è possibile che venga richiesto l'acquisizione di un pacchetto per garantire che il ping icmp venga risultante in un pacchetto KPI che viene poi inserito in un pacchetto IPsec, quindi inviato dall'indirizzo IPsec di origine all'indirizzo IPsec di destinazione.Anche i contatori sull'interfaccia tunnel KPI e i contatori di sessione IPsec possono aiutare a visualizzare. se i pacchetti di invio e ricezione sono incrementi.

Oltre al traffico ping, l'acquisizione deve anche mostrare pacchetti keepalive STANDBY anche durante il traffico inattivo.Infine, se è configurato il BGP, i pacchetti keep-live BGP devono essere inviati anche come pacchetti DISPONIBILI IN pacchetti IPSEC e su VPN.

Risoluzione dei problemi e convalida BGP

Sessioni BGP

BGP è richiesto come protocollo di routing sul tunnel IPsec VPN.Il vicino BGP locale deve stabilire una sessione eBGP con l'istanza BGP dedicata vicina.Gli indirizzi IP vicini eBGP sono gli stessi indirizzi IP del tunnel locale e remoto.Assicurarsi innanzitutto che la sessione BGP sia attiva, quindi verificare che gli indirizzati corretti vengano ricevuti dall'istanza dedicata e che venga inviato l'indirizzato predefinito corretto all'istanza dedicata.

Se il tunnel ANCORA è in alto, verificare che sia stato eseguito un ping tra l'IP tunnel TUNNEL LOCALE e il tunnel RES REMOTO.Se il ping ha esito positivo ma la sessione BGP non si sta avvicinando, ricercare il registro BGP degli errori dell'applicazione BGP.

Di seguito alcuni dei problemi di negoziazione BGP più comuni:

  • Il numero AS remoto non corrisponde al numero AS configurato sul lato istanza dedicata, controllare nuovamente la configurazione AS vicina.

  • Il numero AS locale non corrisponde al lato Istanza dedicata, verificare che il numero AS locale corrisponda ai parametri dell'istanza dedicata previsti.

  • Un firewall sta bloccando i pacchetti TCP BGP trasmessi nei pacchetti VPN dall'invio nel tunnel IPsec o da ricevere dal tunnel IPSEC

  • L'IP del BGP remoto vicino non corrisponde all'IP tunnelRERE remoto.

Scambio di route BGP

Una volta verificata la sessione BGP per entrambi i tunnel, assicurarsi che gli indirizzamenti corretti siano inviati e ricevuti dal lato istanza dedicata.

La soluzione VPN per istanza dedicata prevede due tunnel da stabilire dal lato cliente/partner.Il primo tunnel punta al centro dati A dell'istanza dedicata e il secondo tunnel punta al centro dati istanza dedicata B. Entrambi i tunnel devono essere in stato attivo e la soluzione richiede un'installazione attiva/attiva.Ogni centro dati per istanza dedicata annuncia la sua route locale /25 e /24 di backup.Quando si controllano gli indirizzamenti BGP in ingresso da Istanza dedicata, assicurarsi che la sessione BGP associata al tunnel che punta al centro dati istanza dedicata A riceva il centro dati a istanza dedicata A /25 e l'indirizzamento di backup /24.Inoltre, assicurarsi che il tunnel che punta al centro dati istanza dedicata B riconoca l'instradamento locale del centro dati istanza dedicata B /25 e l'instradamento di backup /24.Tenere presente che l'instradare di backup /24 sarà lo stesso route annunciato dal centro dati A e dal centro dati istanza dedicata B.

Ridondanza fornita a un centro dati istanza dedicata se l'interfaccia tunnel a tale centro dati è in errore.Se la connettività al centro dati istanza dedicata A viene persa, il traffico viene inoltrato dal centro dati istanza dedicato B al centro dati A. In questo scenario, il tunnel al centro dati B utilizzerà il centro dati B /25 per inviare il traffico al centro dati B e il tunnel al centro dati B utilizzerà l'instradato di backup /24 per inviare traffico al centro dati A tramite il centro dati B.

È importante che, quando entrambi i tunnel sono attivi, il tunnel del centro dati Un tunnel non viene utilizzato per inviare traffico al centro dati B e viceversa.In questo scenario, se il traffico viene inviato al centro dati A con una destinazione del centro dati B, il centro dati A inoltra il traffico al centro dati B, quindi il centro dati B tenta di inviare nuovamente il traffico all'origine tramite il tunnel del centro dati B.Di conseguenza, l'instradamento potrebbe non risultare ottimale e potrebbe anche interrompere il traffico che attraversa i firewall.Pertanto, è importante che entrambi i tunnel siano in una configurazione attiva/attiva durante il normale funzionamento.

L'route 0.0.0.0/0 deve essere annunciata dal lato cliente al lato centro dati dell'istanza dedicata.Percorsi più specifici non verranno accettati dal lato Istanza dedicata.Assicurarsi che l'instradare 0.0.0.0/0 sia pubblicizzato fuori sia dal tunnel di istanza dedicata A tunnel che dal tunnel del centro dati B per istanza dedicata.

Configurazione MTU

Nel lato Istanza dedicata, sono abilitate due funzioni per regolare dinamicamente il MTU per le grandi dimensioni di pacchetti.Il tunnel VPN aggiunge più intestazioni ai pacchetti IP che passano attraverso la sessione VPN.Il tunnel IPsec aggiunge ulteriori intestazioni sulla parte superiore delle intestazioni DISPONIBILI e riduce ulteriormente l'MTU maggiore consentito sul tunnel.

Il tunnel COLLATERAL regola la funzione MSS e il percorso tunnel RES nella funzione di rilevamento MTU è abilitato sul lato istanza dedicata.Configurare "ip tcp adjust-mss 1350" o un comando equivalente, "percorso tunnel\u0002mtu-discovery" o comando equivalente sul lato cliente per consentire il regolazione dinamico del traffico MTU attraverso il tunnel VPN.