Introducere

Virtual Connect este o opțiune suplimentară de add-on pentru Cloud Connectivity la Instanță Dedicată pentru Webex Calling (Instanță Dedicată). Virtual Connect le permite clienților să-și extindă în siguranță rețeaua privată prin internet, utilizând tuneluri VPN IP punct la punct. Această opțiune de conexiune oferă o stabilire rapidă a conexiunii la rețeaua privată prin utilizarea echipamentului clientului existent (CPE) și a conectivității la internet.

Cisco găzduiește, administrează și asigură tuneluri IP VPN redundante și accesul la internet necesar în regiunea (regiunile) centrului de date Instanță dedicată Cisco în care serviciul este necesar. În mod similar, administratorul este responsabil pentru CPE și serviciile de internet corespunzătoare, care sunt necesare pentru stabilirea Virtual Connect.

Fiecare comandă de Virtual Connect dintr-o anumită regiune Dedicated Instance va include două tuneluri GRE (Generic Routing Encapsulation) protejate prin criptare IPSec (GRE over IPSec), câte unul către fiecare centru de date Cisco din regiunea selectată.

Virtual Connect are o limită de lățime de bandă de 250 Mbps per tunel și este recomandată pentru implementări mai mici. Deoarece sunt utilizate două tuneluri VPN punct la punct, întregul trafic către cloud trebuie să treacă prin CPE-ul central al clientului și, prin urmare, este posibil să nu fie adecvat acolo unde există o mulțime de site-uri la distanță. Pentru alte opțiuni alternative de peering, consultați Conectivitate în cloud .

Cerințe preliminare

Cerințele prealabile pentru stabilirea Virtual Connect includ:

  • Clientul oferă

    • Conexiune la internet cu suficientă lățime de bandă disponibilă pentru a susține implementarea

    • Adresă(e) adresă IP publică(e) pentru două tuneluri IPSec

    • Adresele IP de transport GRE la nivelul clientului pentru cele două tuneluri GRE

  • Partener și client

    • Colaborați pentru a evalua cerințele privind lățimea de bandă

    • Asigurați-vă că dispozitiv de rețea acceptă rutare Border Gateway Protocol (BGP) și un design de tunel GRE peste IPSec

  • Partenerul sau Clientul furnizează

    • Echipă de rețea cu cunoștințe despre tehnologiile de tunel VPN site-la-site

    • Echipă de rețea cu cunoștințe BGP, eBGP și principiile generale de rutare

  • Cisco

    • Cisco a atribuit numere private de sistem autonome (ASN) și IP tranzitorii pentru interfețele tunelului GRE

    • Cisco a atribuit o rețea publică de clasă C (/24) care nu poate fi rutată prin internet pentru adresarea în cloud de instanță dedicată


Dacă un client are doar 1 dispozitiv CPE, cele 2 tuneluri către centrele de date Cisco (DC1 și DC2) din fiecare regiune vor fi de pe acel dispozitiv CPE. Clientul are și opțiune pentru 2 dispozitive CPE, apoi fiecare dispozitiv CPE trebuie să se conecteze la un singur tunel către centrele de date Cisco (DC1 și DC2) din fiecare regiune. Redundanță suplimentară poate fi obținută prin terminarea fiecărui tunel într-un site/locație fizică separată din infrastructura Clientului.

Detalii tehnice

Model de implementare

Virtual Connect utilizează o arhitectură de tip headend dual-tier, în care planurile de rutare și control GRE sunt furnizate de un dispozitiv, iar planul de control IPSec este asigurat de altul.

La finalizarea Virtual Connect conectivitate, vor fi create două tuneluri GRE over IPSec între rețeaua enterprise a Clientului și centrele de date Cisco pentru Instanță Dedicată. Câte unul pentru fiecare centru de date redundant din regiunea respectivă. Elementele de rețea suplimentare necesare pentru peering sunt schimbate de partener sau client către Cisco prin intermediul formularului de activare Control Hub Virtual Connect.

Figura 1 prezintă un exemplu de model de dezvoltare Virtual Connect pentru opțiunea cu 2 concentratoare pe partea clientului.

Virtual Connect - VPN este un design Hub, în care site-urile Hub ale Clientului sunt conectate la DC1 și DC2 ale centrelor de date ale Instanței Dedicate dintr-o anumită regiune.

Două site-uri Hub sunt recomandate pentru o mai bună redundanță, dar site-ul One Hub cu două tuneluri este, de asemenea, un model de dezvoltare acceptat .


Lățimea de bandă per tunel este limitată la 250 Mbps.


Site-urile de la distanță ale Clientului din aceeași regiune ar trebui să se conecteze din nou la site-urile Hub prin WAN-ul Clientului și nu este responsabilitatea Cisco pentru acea conectivitate.

Se așteaptă ca partenerii să colaboreze îndeaproape cu clienții, asigurându-se că este aleasă cea mai optimă cale pentru regiunea de servicii „Virtual Connect”.

Figura 2 prezintă regiunile de peering pentru conectivitate cloud pentru instanță dedicată.

Redirecționare

Modulul de add-on de rutare pentru Virtual Connect este implementat folosind BGP extern (eBGP) între instanța dedicată și echipamentul local al clientului (CPE). Cisco își va face publicitate rețelei respective pentru fiecare DC redundant dintr-o regiune către CPE-ul Clientului, iar CPE-ul trebuie să facă publicitate unei rute implicite către Cisco.

  • Cisco întreține și alocă

    • Adresarea IP a interfeței de tunel (legătură tranzitorie pentru rutare) Cisco alocă dintr-un spațiu de adrese partajat desemnat (nedirecționabil public)

    • Adresă de destinație pentru transport în tunel (partea Cisco)

    • Numere private de sistem autonome (ASN) pentru configurația de rutare BGP a clientului

      • Cisco alocă din intervalul de utilizare privată desemnat: 64512 - 65534

  • eBGP utilizat pentru a face schimb de rute între Instanță Dedicată și CPE

    • Cisco va împărți rețeaua /24 alocată în 2 /25 pentru fiecare DC din regiunea respectivă

    • În Virtual Connect, fiecare rețea /25 este anunțată înapoi către CPE de către Cisco prin tunelurile VPN punct la punct respective (legătură tranzitorie)

    • CPE trebuie configurat cu vecinii eBGP corespunzători. Dacă utilizați un CPE, vor fi utilizați doi vecini eBGP, unul indicând fiecare tunel la distanță. Dacă utilizați două CPE, atunci fiecare CPE va avea un vecin eBGP care se adresează unui singur tunel la distanță pentru CPE.

    • Partea Cisco a fiecărui tunel GRE ( IP interfață tunel) este configurată ca vecină BGP pe CPE

    • CPE este necesar pentru a face publicitate unei rute implicite peste fiecare dintre tuneluri

    • CPE este responsabil pentru redistribuirea, după caz, a rutelor învăţate în cadrul reţelei întreprinderii clientului.

  • În condițiile de eroare a legăturii fără eroare, un singur CPE va avea două tuneluri active/active. Pentru două noduri CPE, fiecare CPE va avea un tunel activ, iar ambele noduri CPE trebuie să fie active și trafic în trecere. În scenariul fără eroare, traficul trebuie să se divizeze în două tuneluri care merg la destinațiile corecte /25, dacă unul dintre tuneluri este în jos, tunelul rămas poate transporta traficul pentru ambele. Într-un astfel de scenariu de eroare, atunci când rețeaua /25 este inactivă, rețeaua /24 este utilizată ca rută de rezervă. Cisco va trimite traficul clienților prin WAN-ul său intern către DC care și-a pierdut conectivitatea.

Procesul de conexiune

Următorii pași de nivel înalt descriu modul de stabilire a conectivității cu Virtual Connect pentru instanță dedicată.

1

Efectuați o comandă în Cisco CCW

2

Activați Virtual Connect din Control Hub

3

Cisco efectuează configurarea rețelei

4

Clientul efectuează Configurarea rețelei

Pasul 1: Ordin CCW

Virtual Connect este un add-on pentru instanță dedicată în CCW.

1

Navigați la site-ul de comandă CCW și apoi faceți clic pe Conectare pentru a vă conecta pe site:

2

Creați o estimare.

3

Adăugați SKU „A-FLEX-3”.

4

Selectați Editare opțiuni.

5

În fila Abonament care apare, Selectați Opțiuni și Programe de completare.

6

În Programele de completare suplimentare, casetă de selectare de selectare de lângă „Virtual Connect for Dedicated Instance”. Numele SKU este „A-FLEX-DI-VC”.

7

Introduceți cantitatea și numărul de regiuni în care este necesar Virtual Connect.


 
Cantitatea de Virtual Connect nu trebuie să depășească numărul total de regiuni achiziționate pentru Instanță Dedicată. De asemenea, este permisă o singură comandă Virtual Connect per regiune.
8

Când sunteți mulțumit de selecțiile efectuate, faceți clic pe Verificare și salvare în partea din dreapta sus a paginii.

9

Faceți clic pe Salvați și continuați pentru a finaliza comanda. Comanda dvs. finalizată apare acum în grila de ordine.

Pasul 2: Activarea Virtual Connect în Control Hub

1

Conectați-vă la Control Hubhttps://admin.webex.com/login .

2

În Servicii secțiunea, navigați la Apelare > Instanță dedicată > Conectivitate cloud .

3

Pe cardul Virtual Connect este afișată cantitatea achiziționată pentru Virtual Connect. Administratorul poate acum să facă clic pe Activați pentru a iniția activarea Virtual Connect.


 
Procesul de activare poate fi declanșat numai de administratorii cu Rol de „Administrator complet client”. În timp ce, un administrator cu rolul „Administrator doar pentru citire client” poate vizualiza doar starea.
4

Făcând clic pe Activați buton, Activați Virtual Connect se afișează formularul pentru ca administratorul să furnizeze detaliile tehnice Virtual Connect necesare pentru configurațiile de peering pe partea Cisco.


 
Formularul oferă și informații statice din partea Cisco, în funcție de Regiunea selectată. Aceste informații vor fi utile pentru administratorii clienților pentru a configura CPE-ul de partea lor pentru a stabili conexiunea.
  1. GRE Tunnel Transport adresă IP : Clientul trebuie să furnizeze adresele IP pentru Tunnel Transport laterale ale clientului, iar Cisco va aloca dinamic adresele IP odată ce activarea este finalizată. IPSec ACL pentru trafic interesant ar trebui să permită transportul tunelului local IP/32 la IP de transport tunelului de la distanță /32. ACL trebuie să specifice, de asemenea, numai protocolul GRE IP .


     
    Adresa adresă IP furnizată de client poate fi privată sau publică.
  2. colegi IPSec : Clientul trebuie să furnizeze adresele IP sursă ale tunelului IPSec , iar Cisco alocă adresă IP destinație IPSec . Efectuarea traducerii NAT a unei adrese de tunel IPSEC internă într-o adresă publică este de asemenea acceptată dacă este necesar.


     

    Adresa adresă IP furnizată de client trebuie să fie publică.


     
    Toate celelalte informații statice furnizate în ecranul de activare reprezintă standardele de securitate și criptare de la Cisco respectate. Această configurație statică nu este personalizabilă sau modificabilă. Pentru orice asistență suplimentară privind configurațiile statice din partea Cisco, clientul va trebui să contacteze TAC.
5

Faceți clic pe Activați odată ce toate câmpurile obligatorii au fost completate.

6

După ce formularul de activare Virtual Connect este completat pentru o anumită regiune, clientul poate Exporta formularul de activare din Control Hub, Calling > Dedicated Instance > fila Cloud Connectivity și poate face clic pe Export settings.


 
Din motive de securitate, autentificarea și parola BGP nu vor fi disponibile în documentul exportat, dar administratorul le poate vizualiza în Control Hub făcând clic pe Vizualizare setări în Control Hub, fila Apelare > Instanță dedicată > Conectivitate în cloud.

Pasul 3: Cisco efectuează configurarea rețelei

1

Odată ce formularul de activare Virtual Connect este completat, starea va fi actualizată la Activare în curs de desfășurare în Calling > Dedicated Instance > Cloud Connectivity Virtual Connect card.

2

Cisco va finaliza configurațiile necesare pentru echipamentul lateral Cisco 5 zile lucrătoare . La finalizarea cu succes, starea va fi actualizată la „Activat” pentru regiunea respectivă în Control Hub.

Pasul 4: Clientul efectuează Configurarea rețelei

Starea este schimbată în „Activat” pentru a notifica administratorul Clientului că partea Cisco a configurațiilor pentru conectivitatea IP VPN a fost finalizată pe baza intrărilor furnizate de Client. Însă, administratorul clientului este de așteptat să finalizeze configurațiile CPE-urilor și să testeze rutele de conexiune pentru ca tunelul Virtual Connect să fie Online. În cazul oricăror probleme cu care se confruntă la momentul configurării sau al conectării, clientul poate lua legătura cu Cisco TAC pentru asistență.

Soluționarea problemelor

Prima fază IPsec (negociere IKEv2) depanare și validare

Negocierea tunelului IPsec presupune două faze, faza IKEv2 și faza IPsec. Dacă negocierea fazei IKEv2 nu se finalizează, atunci nu există inițierea unei a doua faze IPsec. Mai întâi, lansați comanda „show crypto ikev2 sa” (pe echipamentul Cisco ) sau o comandă similară pe echipamentul terț pentru a verifica dacă sesiunea IKEv2 este activă. Dacă sesiunea IKEv2 nu este activă, posibilele motive ar putea fi:

  • Traficul interesant nu declanșează tunelul IPsec.

  • listă de acces la tunelul IPsec este configurată greșit.

  • Nu există conectivitate între client și IP-ul punctului final de tunel IPsec al instanței dedicate .

  • Parametrii sesiunii IKEv2 nu se potrivesc între partea Instanță Dedicată și partea client.

  • Un firewall blochează pachetele IKEv2 UDP .

Mai întâi, verificați jurnalele IPsec pentru orice mesaje care arată progresul negocierii tunelului IKEv2. Jurnalele pot indica unde există o problemă cu negocierea IKEv2. Lipsa mesajelor de jurnalizare poate indica, de asemenea, faptul că sesiunea IKEv2 nu este activată.

Unele erori frecvente la negocierea IKEv2 sunt:
  • Setările pentru IKEv2 pe partea CPE nu se potrivesc cu cele pentru Cisco , verificați din nou setările menționate:

    • Verificați dacă versiunea IKE este versiunea 2.

    • Verificați dacă parametrii de criptare și autentificare corespund criptării așteptate din partea instanței dedicate.


      Când cifrul "GCM" este utilizat, protocolul GCM se ocupă de autentificare și setează parametrul de autentificare la NULL.

    • Verificați setarea duratei de viață.

    • Verificați grupul de modul Diffie Hellman.

    • Verificați setările funcției pseudo-aleatorie.

  • listă de acces pentru harta cripto nu este setată la:

    • Permis GRE (local_tunnel_transport_ip ) 255.255.255.255 (remote_tunnel_transport_ip ) 255.255.255.255" (sau comandă echivalentă)


      listă de acces trebuie să fie specifică pentru protocolul „GRE”, iar protocolul „IP” nu va funcționa.

Dacă mesajele de jurnal nu indică activitate de negociere pentru faza IKEv2, atunci poate fi necesară o captură pachet .


Partea Instanță Dedicată nu poate începe întotdeauna schimbul IKEv2 și, uneori, se poate aștepta ca partea CPE a clientului să fie inițiatorul.

Verificați configurația CPE pentru următoarele condiții prealabile pentru inițierea sesiunii IKEv2:

  • Verificați o listă de acces criptografic IPsec pentru traficul GRE (protocol 50) de la IP-ul de transport al tunelului CPE la IP - IP de transport al tunelului Instanță Dedicată .

  • Asigurați-vă că interfața tunelului GRE este activată pentru keepalive GRE; dacă echipamentul nu acceptă keepalive GRE, Cisco este notificat deoarece keepalives GRE vor fi activate implicit pe partea Instanță dedicată.

  • Asigurați-vă că BGP este activat și configurat cu adresa vecină a IP-ului tunelului Instanței Dedicate.

Când este configurat corect, următoarele începe tunelul IPsec și negocierea IKEv2 din prima fază:

  • Keepalives GRE de la interfața tunel GRE din partea CPE la interfața tunel GRE din partea Instanței Dedicate.

  • Sesiune TCP vecină BGP de la vecinul BGP al părții CPE la vecinul BGP al instanței dedicate.

  • Efectuați ping de la adresa IP a tunelului lateral CPE la adresă IP a tunelului lateral al instanței dedicate .


    Ping nu poate fi IP de transport tunel la IP de transport tunel , trebuie să fie IP tunel la IP tunel .

Dacă este necesară o urmărire a pachetelor pentru traficul IKEv2, setați filtrul pentru UDP și fie portul 500 (când niciun dispozitiv NAT nu se află în mijlocul punctelor finale IPsec), fie portul 4500 (când un dispozitiv NAT este introdus în mijlocul punctelor finale IPsec) puncte finale).

Verificați dacă pachetele IKEv2 UDP cu portul 500 sau 4500 sunt trimise și primite către și de la adresă IP DI IPsec .


Este posibil ca centrul de date Instanță Dedicată să nu înceapă întotdeauna primul pachet IKEv2. Cerința este ca dispozitivul CPE să fie capabil să inițieze primul pachet IKEv2 către partea Instanță Dedicată.

Dacă firewall-ul local permite acest lucru, încercați și un ping către adresa IPsec de la distanță. Dacă ping-ul nu reușește de la adresa IPsec locală la adresa IPsec de la distanță, efectuați un traseu de urmărire pentru a vă ajuta și a determina locul în care este abandonat pachetul.

Este posibil ca unele firewall-uri și echipamente de internet să nu permită urmărirea rutei.

A doua fază IPsec (negociere IPsec) depanare și validare

Verificați dacă prima fază IPsec (adică asocierea de securitate IKEv2) este activă înainte de a depana faza a doua IPsec. Efectuați o comandă „show crypto ikev2 sa” sau o comandă echivalentă pentru a verifica sesiunea IKEv2. În ieșire, verificați dacă sesiunea IKEv2 a fost activă pentru mai mult de câteva secunde și că nu se redirecționează. Durata de funcționare a sesiunii este afișată ca sesiune „Timp activ” sau echivalent în ieșire.

Odată ce sesiunea IKEv2 se verifică ca fiind activă și activă, Investigați sesiunea IPsec. Ca și în sesiunea IKEv2, efectuați o comandă „show crypto ipsec sa” sau o comandă echivalentă pentru a verifica sesiunea IPsec. Atât sesiunea IKEv2, cât și sesiunea IPsec trebuie să fie active înainte de stabilirea tunelului GRE. Dacă sesiunea IPsec nu este afișată ca activă, verificați jurnalele IPsec pentru mesaje de eroare sau erori de negociere.

Unele dintre cele mai frecvente probleme care pot fi întâlnite în timpul negocierilor IPsec sunt:

Setările din partea CPE nu corespund cu cele ale Instanței Dedicate, verificați din nou setările:

  • Verificați dacă parametrii de criptare și autentificare corespund setărilor din partea Instanță dedicată.

  • Verificați setările Perfect Forward Secrecy și dacă corespund setărilor din partea Instanță dedicată.

  • Verificați setările pentru durata de viață.

  • Verificați dacă IPsec a fost configurat în modul tunel.

  • Verificați adresele IPsec sursă și destinație.

Depanarea și validarea interfeței tunelului

Când sesiunile IPsec și IKEv2 sunt verificate ca active și active, pachetele keepalive din tunelul GRE pot circula între punctele finale ale Instanței Dedicate și ale tunelului CPE. Dacă interfața tunelului nu afișează starea, unele probleme frecvente sunt:

  • VRF de transport al interfeței tunel nu corespunde cu VRF al interfeței loopback (dacă configurația VRF este utilizată pe interfața tunel).


    Dacă configurația VRF nu este utilizată pe interfața tunelului, această verificare poate fi ignorată.

  • Keepaliverele nu sunt activate în interfața tunelului lateral CPE


    Dacă keepaliver-urile nu sunt acceptate pe echipamentul CPE, atunci Cisco trebuie să fie notificat, astfel încât keepaliver-urile implicite din partea Instanței Dedicate să fie, de asemenea, dezactivate.

    Dacă keepaliver-urile sunt acceptate, verificați dacă keepaliver-urile sunt activate.

  • Masca sau adresă IP a interfeței tunelului nu este corectă și nu corespunde valorilor așteptate ale Instanței Dedicate.

  • Adresa de transport tunelul sursă sau destinație nu este corectă și nu corespunde valorilor așteptate ale Instanței dedicate.

  • Un firewall blochează trimiterea pachetelor GRE în tunelul IPsec sau primite din tunelul IPsec (tunelul GRE este transportat prin tunelul IPsec)

Un test ping trebuie să verifice dacă interfața tunelului local este activă și că conectivitatea la interfața tunelului de la distanță este bună. Efectuați verificarea ping de la IP -ul tunelului (nu IP-ul de transport) la IP- IP tunelului de la distanță.


listă de acces cripto pentru tunelul IPsec care transportă traficul tunelului GRE permite traversarea numai a pachetelor GRE. Drept urmare, ping-urile nu vor funcționa de la IP de transport în tunel la IP de transport la distanță în tunel .

Verificarea ping are ca rezultat un pachet GRE care este generat de la IP-ul de transport tunelul sursă la IP - IP de transport tunelul destinație, în timp ce sarcina utilă a pachetului GRE ( IP-ul interior) va fi IP-ul tunelului sursă și destinație.

Dacă testul ping nu reușește și elementele precedente sunt verificate, atunci poate fi necesară o captură pachet pentru a se asigura că ping-ul icmp are ca rezultat un pachet GRE care este apoi încapsulat într-un pachet IPsec și apoi trimis de la adresa IPsec sursă la adresa IPsec de destinație. Contoarele de pe interfața tunelului GRE și contoarele de sesiune IPsec pot, de asemenea, ajuta la afișare. dacă pachetele de trimitere și primire sunt în creștere.

Pe lângă traficul ping, captura trebuie să afișeze și pachetele GRE keepalive chiar și în timpul traficului inactiv. În cele din urmă, dacă BGP este configurat, pachetele BGP keepalive trebuie trimise și ca pachete GRE încapsulate în pachete IPSEC, precum și prin VPN.

Depanare și validare BGP

Sesiuni BGP

BGP este necesar ca protocol de rutare prin tunelul IPsec VPN . Vecinul BGP local trebuie să stabilească o sesiune eBGP cu vecinul BGP al instanței dedicate. Adresele IP ale vecinilor eBGP sunt identice cu adresele IP ale tunelului local și de la distanță. Asigurați-vă mai întâi că sesiunea BGP este activă, apoi verificați dacă rutele corecte sunt primite de la Instanța Dedicată și că ruta implicită corectă este trimisă către Instanța Dedicată.

Dacă tunelul GRE este activ, verificați dacă ping-ul a reușit între IP-ul tunelului GRE local și cel de la distanță . Dacă ping-ul a reușit, dar sesiunea BGP nu vine, atunci investigați jurnalul BGP pentru erori de stabilire BGP.

Unele dintre cele mai frecvente probleme de negociere BGP sunt:

  • Numărul AS de la distanță nu corespunde numărului AS configurat pe partea instanței dedicate, verificați din nou configurația AS vecin.

  • Numărul AS local nu corespunde cu ceea ce așteaptă partea Instanță Dedicată, verificați dacă numărul AS local corespunde parametrilor așteptați pentru Instanță Dedicată.

  • Un firewall blochează trimiterea pachetelor BGP TCP încapsulate în pachetele GRE pentru a nu fi trimise în tunelul IPsec sau a fi primite din tunelul IPSEC

  • IP -ul vecinului BGP la distanță nu corespunde IP-ului tunelului GRE de la distanță.

Schimb rută BGP

Odată ce sesiunea BGP este verificată pentru ambele tuneluri, asigurați-vă că rutele corecte sunt trimise și primite din partea instanței dedicate.

Soluția Dedicated Instance VPN se așteaptă ca două tuneluri să fie stabilite din partea clientului/partenerului. Primul tunel indică centrul de date Instanță dedicată A, iar al doilea tunel indică centrul de date Instanță dedicată B. Ambele tuneluri trebuie să fie în starea activă, iar soluția necesită o implementare activă/activă. Fiecare centru de date Instanță Dedicată va promova ruta sa locală /25, precum și o rută de rezervă /24. Când verificați rutele BGP de intrare de la Instanță Dedicată, asigurați-vă că sesiunea BGP asociată tunelului care indică către centrul de date Instanță Dedicată A primește rută locală /25 a centrului de date Instanță Dedicată A, precum și ruta de rezervă /24. În plus, asigurați-vă că tunelul care indică către centrul de date Instanță Dedicată B primește rută locală /25 a centrului de date Instanță Dedicată B, precum și ruta de rezervă /24. Rețineți că ruta de rezervă /24 va fi aceeași rută afișată în centrul de date cu instanță dedicată A și din centrul de date cu instanță dedicată B.

Redundanța este furnizată unui centru de date cu instanță dedicată dacă interfața tunelului cu acel centru de date se defectează. Dacă se pierde conexiunea la centrul de date cu instanță dedicată A, traficul va fi redirecționat de la centrul de date cu instanță dedicată B la centrul de date A. În acest scenariu, tunelul către centrul de date B va utiliza ruta centrului de date B /25 pentru a trimite traficul către centrul de date B și tunelul către centrul de date B va utiliza ruta de rezervă /24 pentru a trimite traficul către centrul de date A prin centrul de date B.

Este important ca, atunci când ambele tuneluri sunt active, tunelul din centrul de date A să nu fie utilizat pentru a trimite traficul către centrul de date B și invers. În acest scenariu, dacă traficul este trimis către centrul de date A cu o destinație a centrului de date B, centrul de date A va redirecționa traficul către centrul de date B și apoi centrul de date B va încerca să trimită traficul înapoi la sursă prin tunelul centrului de date B. Acest lucru va duce la o rutare suboptimă și, de asemenea, poate întrerupe traficul care traversează firewall-urile. Prin urmare, este important ca ambele tuneluri să fie într-o configurație activă/activă în timpul funcționării normale.

Ruta 0.0.0.0/0 trebuie să fie anunțată din partea clientului către partea centrului de date Instanță dedicată. Rute mai specifice nu vor fi acceptate de partea Instanță Dedicată. Asigurați-vă că ruta 0.0.0.0/0 este anunțată atât din tunelul A al centrului de date Instanță dedicată, cât și din tunelul B din centrul de date Instanță dedicată.

Configurare MTU

În partea Instanță dedicată, sunt activate două caracteristici pentru a regla dinamic MTU pentru dimensiuni mari de pachete. Tunelul GRE adaugă mai multe anteturi la pachetele IP care circulă prin sesiunea VPN . Tunelul IPsec adaugă anteturi suplimentare peste anteturile GRE va reduce și mai mult cel mai mare MTU permis în tunel.

Tunelul GRE ajustează caracteristica MSS, iar calea tunelului GRE în caracteristica de descoperire MTU este activată în partea Instanță dedicată. Configurați „ip tcp adjust-mss 1350” sau comanda echivalentă, precum și „tunnel path\u0002mtu-discovery” sau comanda echivalentă din partea clientului pentru a ajuta la reglarea dinamică a MTU a traficului prin tunelul VPN .