Virtual Connect utilizează o arhitectură de tip headend cu două niveluri, în care planurile de rutare și control GRE sunt furnizate de un dispozitiv, iar planul de control IPSec este furnizat de altul.

La finalizarea conexiunii Virtual Connect, vor fi create două tuneluri GRE prin IPSec între rețeaua de întreprindere 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 de mai jos prezintă exemplul modelului de implementare a conectării virtuale pentru opțiunea cu 2 concentrator, din 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 implementare acceptat.

Partenerii trebuie să colaboreze îndeaproape cu Clienții, asigurându-se că se alege calea cea mai optimă pentru regiunea de servicii Conectare virtuală .

Figura de mai jos prezintă regiunile de peering pentru conexiunea cloud a instanței dedicate.

Suplimentul de rutare pentru Virtual Connect este implementat folosind BGP extern (eBGP) între Instanța Dedicată și Echipamentul 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 atribuie

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

  • Adresa de destinație a transportului în tunel (partea Cisco)

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

    • Cisco atribuie din intervalul de utilizare privat desemnat: 64512 până la 65534

• eBGP folosit pentru a schimba rute între Instanța Dedicată și CPE

  • Cisco va împărți rețeaua /24 alocată în 2/25 câte una 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ă se utilizează un CPE, vor fi folosiț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ță de 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ă cum este necesar, a rutelor învățate în cadrul rețelei de întreprindere a clientului.

• În condiția de eroare a legăturii fără eșec, un singur CPE va avea două tuneluri active/active. Pentru două noduri CPE, fiecare CPE va avea un tunel activ și ambele noduri CPE ar trebui să fie active și să treacă trafic. În scenariul de non-eșec, traficul trebuie să fie împărțit în două tuneluri care merg către destinațiile corecte /25, dacă unul dintre tuneluri scade, tunelul rămas poate transporta traficul pentru ambele. Într-un astfel de scenariu de eșec, când rețeaua /25 este oprită, atunci 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 implică două faze, faza IKEv2 și faza IPsec. Dacă negocierea etapei IKEv2 nu se finalizează, nu se inițiază o a doua fază IPsec. În primul rând, efectuați comanda „afișare cripto ikev2 sa” (pe echipamentul Cisco) sau comanda 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 declanșează tunelul IPsec.

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

• Nu există nicio conexiune între client și IPsec terminal tunel pentru instanța dedicată.

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

• Un firewall blochează pachetele UDP IKEv2.

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

Unele erori comune la negocierea IKEv2 sunt:

• Setările pentru IKEv2 pe partea CPE nu se potrivesc cu partea 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 în uz, 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 pseudo-aleatoare.

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

  • GRE permisiune (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, este posibil să fie necesară o captură de pachet.

Atunci când este configurat corect, începe tunelul IPsec și prima fază de negociere IKEv2:

• GRE păstrează conexiunile de la interfața de tunel GRE din partea CPE la interfața de tunel GRE din partea instanței dedicate.

• Sesiune TCP vecină BGP de la vecină BGP de la CPE la vecină BGP de la instanță dedicată.

• Ping de la adresa IP a tunelului din partea CPE la adresa IP a tunelului din partea instanței dedicate.

  Ping nu poate fi IP transport tunel - IP transport tunel, trebuie să fie IP tunel - 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).

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

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

După ce sesiunea IKEv2 se verifică ca activă ș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 cea 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; verificați din nou setările:

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

• Verificați setările de secretizare perfectă pentru redirecționare și dacă setările corespund de pe partea Instanței dedicate.

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

Atunci când sesiunile IPsec și IKEv2 sunt verificate ca active și active, pachetele de tunel GRE rămân active și pot circula între instanța dedicată și terminalele de tunel CPE. Dacă interfața de tunel nu este afișată starea, unele probleme comune sunt:

• VRF transport interfață tunel nu corespunde 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 de tunel, această verificare poate fi ignorată.

• Conexiunile persistente nu sunt activate în interfața de tunel din partea CPE

  Dacă conexiunile persistente nu sunt acceptate pe echipamentul CPE, atunci Cisco trebuie notificat, astfel încât conexiunile persistente implicite de pe partea instanței dedicate să fie dezactivate.

  Dacă conexiunile persistente sunt acceptate, verificați dacă conexiunile persistente sunt activate.

• Masca sau adresa IP a interfeței de tunel nu este corectă și nu corespunde valorilor așteptate pentru instanța dedicată.

• Adresa de transport tunel sursă sau de destinație nu este corectă și nu corespunde valorilor așteptate pentru instanța dedicată.

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

Un test de ping ar trebui să verifice dacă interfața de tunel locală este pornită și dacă conectivitatea este bună pentru interfața de tunel de la distanță. Efectuați verificarea ping de la IP-ul tunelului (nu și IP-ul de transport) la IP-ul tunelului la distanță.

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

Dacă testul ping nu reușește și elementele anterioare sunt verificate, este posibil să fie necesară o captură de pachet pentru a vă 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 GRE tunnel și contoarele de sesiune IPsec vă pot ajuta, de asemenea, să afișați. dacă pachetele de trimitere și primire cresc.

În plus față de traficul ping, captura ar trebui să prezinte, de asemenea, pachete GRE care rămân active chiar și în timpul traficului inactiv. În cele din urmă, dacă BGP este configurat, pachetele BGP păstrate ar trebui trimise și ca pachete GRE încapsulate în pachete IPSEC, precum și prin VPN.

În partea Instanță dedicată, două caracteristici sunt activate pentru a ajusta dinamic MTU pentru dimensiuni mari de pachete. Tunelul GRE adaugă mai multe antete pachetelor IP care trec prin sesiunea VPN. Tunelul IPsec adaugă anteturile suplimentare în plus față de anteturile GRE vor reduce și mai mult MTU maxim permis în tunel.

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