Virtual Connect utilizează o arhitectură cu capete de nivel dublu, în care avioanele de dirijare și de control GRE sunt furnizate de un dispozitiv, iar planul de control IPSec este furnizat de un alt dispozitiv.

La finalizarea conectivității Virtual Connect , se vor crea două GRE prin tuneluri IPSec între rețeaua de întreprinderi a clientului și centrele de date Cisco ale instanței dedicate. Unul pentru fiecare centru de date redundant din regiunea respectivă. Elementele suplimentare de rețea necesare pentru împerechere sunt schimbate de partener sau de client la Cisco prin intermediul formularului de activare Control Hub Virtual Connect.

Figura 1 arată un exemplu al modelului de implementare Virtual Connect pentru opțiunea 2-concentrator de 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 într-o anumită regiune.

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

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

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

Se așteaptă ca partenerii să colaboreze îndeaproape cu Clienții, asigurându-se că se alege calea cea mai optimă pentru regiunea de servicii „Conectare virtuală”.

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

Rutarea pentru add-on-ul Connect virtual este implementată utilizând BGP extern (eBGP) între instanța dedicată și echipamentul local al clientului (CPE). Cisco va face publicitate rețelei lor respective pentru fiecare DC redundant dintr-o regiune către CPE al Achizitorului, iar CPE trebuie să facă publicitate unei rute implicite către Cisco.

• Cisco menține și alocă

  • Adresarea IP a interfeței de tunel (link tranzitoriu pentru rutare) Cisco atribuie dintr-un spațiu de adrese partajate desemnat (care nu poate fi dirijat public)

  • Adresă de desitinizare a transportului în tunel (partea Cisco)

  • Numere de sistem autonom privat (ASN) pentru configurația de rutare BGP a clientului

    • Cisco alocă din gama de utilizare privată desemnată: 64512 până la 65534

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

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

  • În Virtual Connect, fiecare rețea /25 este anunțată înapoi la CPE de Cisco prin tunelurile VPN punct-la-punct respective (link tranzitoriu)

  • CPE trebuie să fie configurat cu vecinii eBGP corespunzători. Dacă se utilizează un CPE, se vor utiliza doi vecini eBGP, unul care indică fiecare tunel de la distanță. În cazul în care se utilizează două CPE, fiecare CPE va avea un vecin eBGP care pune la tunelul de la distanță unic pentru CPE.

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

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

  • CPE este răspunzător pentru redistribuirea, după cum este necesar, a rutelor învățate în cadrul rețelei de întreprinderi a cutomerului.

• În condiții de eșec al legăturii, 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 să treacă prin trafic. Conform scenariului de non-eșec, traficul trebuie împărțit în două tuneluri care merg la destinațiile corecte /25, în cazul în care unul dintre tuneluri coboară, tunelul rămas poate transporta traficul pentru ambele. Într-un astfel de scenariu de eșec, atunci când rețeaua /25 este în jos, atunci rețeaua /24 este utilizată ca o rută de rezervă. Cisco va trimite traficul clienților prin intermediul WAN-ului său intern către DC care și-a pierdut conectivitatea.

Negocierea tunelului IPsec implică două faze, faza IKEv2 și faza IPsec. În cazul în care negocierea fazei IKEv2 nu este finalizată, atunci nu există nici o inițiere a unei a doua faze IPsec. În primul rând, emiteți comanda „afișați cripto ikev2 sa” (pe echipamentul Cisco) sau comandă similară pe echipamentul terț pentru a verifica dacă sesiunea IKEv2 este activă. Dacă sesiunea IKEv2 nu este activă, motivele potențiale ar putea fi:

• Traficul interesant nu declanseaza tunelul IPsec.

• Lista de acces la tunelul IPsec este neconfigurată.

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

• Parametrii sesiunii IKEv2 nu corespund între partea instanței dedicate și partea clientului.

• Un firewall blochează pachetele UDP IKEv2.

În primul rând, verificați jurnalele IPsec pentru orice mesaje care arată progresul negocierilor tunelului IKEv2. Jurnalele pot indica dacă există o problemă cu negocierea IKEv2. Lipsa mesajelor de conectare poate indica, de asemenea, că sesiunea IKEv2 nu este activată.

Unele erori comune cu negocierea IKEv2 sunt:

• Setările pentru IKEv2 pe partea CPE nu corespund cu partea Cisco, redirecționați 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 este utilizat cipher-ul „GCM”, protocolul GCM gestionează autentificarea și setează parametrul de autentificare la NULL.

  • Verificați setarea duratei de viață.

  • Verificați grupul de module Diffie Hellman.

  • Verificați setările funcției aleatorii Pseudo.

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

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

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

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

Partea dedicată instanței nu poate începe întotdeauna schimbul IKEv2 și se poate aștepta uneori ca partea CPE a clientului să fie inițiatorul. Verificați configurația laterală CPE pentru următoarele condiții prealabile pentru inițierea sesiunii IKEv2: Verificați o listă de acces cripto IPsec pentru traficul GRE (protocol 50) de la IP-ul de transport al tunelului CPE la IP-ul de transport al tunelului instanței dedicate. Asigurați-vă că interfața tunelului GRE este activată pentru keepalives GRE, dacă echipamentul nu acceptă keepalives GRE, atunci Cisco este notificat deoarece keepalives GRE vor fi activate în partea instanță dedicată în mod implicit. Asigurați-vă că BGP este activat și configurat cu adresa vecină a IP-ului tunelului instanță dedicată.

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

• GrE keepalives de la interfața de tunel GRE partea CPE la interfața de tunel GRE partea instanță dedicată.

• Sesiune TCP de la vecinul BGP din partea CPE la vecinul BGP din partea instanței dedicate.

• Ping de la adresa IP a tunelului lateral CPE la adresa IP a tunelului lateral instanță dedicată.

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

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

Verificați dacă pachetele UDP IKEv2 cu port 500 sau 4500 sunt trimise și primite la și de la adresa IP IPsec DI.

Centrul de date al instanței dedicate nu poate începe întotdeauna primul pachet IKEv2. Cerința este că dispozitivul CPE este capabil să inițieze primul pachet IKEv2 spre partea Instanță dedicată. Dacă firewall-ul local permite, apoi încercați, de asemenea, un ping la adresa IPsec de la distanță. În cazul în care ping-ul nu este de succes de la adresa IPsec locală la distanță, apoi efectuați un traseu de urmărire pentru a ajuta, și de a determina în cazul în care pachetul este abandonat. Este posibil ca unele firewall-uri și echipamente de internet să nu permită traseul de urmărire.

Verificați dacă prima fază IPsec (adică asocierea de securitate IKEv2) este activă înainte de depanarea celei de-a doua faze IPsec. Efectuați o „afișare ikev2 sa cripto” sau o comandă echivalentă pentru a verifica sesiunea IKEv2. În ieșire, verificați dacă sesiunea IKEv2 a fost ridicată pentru mai mult de câteva secunde și că nu se estompează. Ora de actualizare a sesiunii arată ca sesiunea „Timp activ” sau echivalent în ieșire.

După ce sesiunea IKEv2 este verificată ca în sus și activă, Investigați sesiunea IPsec. Ca și în cazul sesiunii IKEv2, efectuați o „afișare cripto 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 apare 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 de pe partea CPE nu corespund cu partea Instanței dedicate, redirecționați setările:

• Verificați dacă parametrii de criptare și autentificare corespund cu setările din partea instanței dedicate.

• Verificați setările Perfecte de redirecționare a secretului și că setările de potrivire sunt pe partea Instanță dedicată.

• Verificați setările duratei de viață.

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

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

Când sesiunile IPsec și IKEv2 sunt verificate ca în sus și active, tunelul GRE este capabil să curgă între punctele finale ale tunelului Instance Dedicated și CPE. În cazul în care interfața tunel nu afișează starea, unele probleme comune sunt:

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

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

• Keepalives nu sunt activate pe interfața tunel lateral CPE

  Dacă Keepalives nu sunt acceptate pe echipamentul CPE, atunci Cisco trebuie notificat, astfel încât și keepalives implicite din partea instanței dedicate să fie dezactivate. Dacă Keepalives sunt acceptate, verificați dacă Keepalives sunt activate.

• Masca sau adresa IP a interfeței tunelului nu este corectă și nu corespunde valorilor așteptate ale instanței dedicate.

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

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

Un test ping ar trebui să verifice dacă interfața tunelului local este în sus și conectivitatea este bună la interfața tunelului la distanță. Efectuați verificarea ping de la tunelul IP (nu IP de transport) la tunelul IP de la distanță.

Lista de acces cripto pentru tunelul IPsec care transportă traficul tunelului GRE permite doar pachetele GRE să traverseze. Ca urmare, pinii nu vor funcționa de la transportul prin tunel IP la transportul prin tunel la distanță IP.

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

În cazul în care testul de ping nu este de succes și elementele anterioare sunt verificate, atunci poate fi necesară o captură de 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 destinație. Contoarele de pe interfața tunel GRE și contoarele de sesiune IPsec pot, de asemenea, ajuta la afișare. dacă pachetele de trimitere și primire sunt în creștere.

În plus față de traficul de ping, captura ar trebui să arate, de asemenea, pachetele GRE keepalive chiar și în timpul traficului inactiv. În cele din urmă, dacă BGP este configurat, pachetele BGP keepalive trebuie, de asemenea, trimise ca pachete GRE încapsulate în pachete IPSEC, precum și prin VPN.

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

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