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 1 prezintă un exemplu de model de implementare Virtual Connect pentru opțiunea cu 2 concentratoare 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 sunt așteptați să lucreze îndeaproape cu Clienții, asigurându-se că este aleasă calea cea mai optimă pentru regiunea de servicii „Virtual Connect”.

Figura 2 arată regiunile de peering pentru conectivitate în cloud de instanță dedicată.

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 fazei IKEv2 nu este finalizată, atunci nu există nicio 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:

  • Permite GRE (local_tunnel_transport_ip) 255.255.255.255 remote_tunnel_transport_ip() 255.255.255.255" (sau comanda 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.

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.

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.

Atunci când sesiunile IPsec și IKEv2 sunt verificate ca sus și activ, tunelul GRE este capabil să curgă între punctele finale ale tunelului Instanță dedicată ș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ță.

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 reglarea dinamică a MTU a traficului prin tunelul VPN.