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

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.

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.

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.

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.

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