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

După finalizarea conectivității Virtual Connect, vor fi create două tuneluri GRE peste IPsec între rețeaua de întreprindere a Clientului și centrele de date Cisco pentru instanță dedicată. Unul pentru fiecare centru de date redundant din regiunea respectivă. Elementele suplimentare de rețea necesare pentru peering sunt schimbate de către Par tener sau Client către Cisco prin intermediul formularului de activare Control Hub Virtual Connect.

Figura de mai jos prezintă exemplul modelului de implementare a conexiunii virtuale pentru opțiunea 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 într-o anumită regiune.

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

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 de mai jos prezintă regiunile de coeziune pentru conectivitate cloud pentru instanță dedicată.

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

• Cisco întreține și atribuie

  • Adresare IP a interfeței tunelului (legătură tranzitorie pentru rutare) Cisco atribuie dintr-un spațiu de adrese partajat desemnat (rutabil nepublic)

  • Adresa de desitinare a transportului tunelului (partea Cisco)

  • Numere de sistem autonom privat (ASN) pentru configurarea rutării BGP a clientului

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

• EBGP utilizat pentru schimbul de rute între instanța dedicată și CPE

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

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

  • CPE trebuie să fie 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 referă la singurul tunel la distanță pentru CPE.

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

  • CPE este obligat să promoveze o rută implicită peste fiecare tunel

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

• În condiții de defecțiune a legăturii fără defecțiune, 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 fără eșec, traficul trebuie împărțit în două tuneluri care merg către destinațiile corecte /25, dacă 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 întreruptă, atunci rețeaua /24 este utilizată ca rută de rezervă. Cisco va trimite traficul clienților prin WAN intern către DC care a pierdut conectivitatea.

Negocierea tunelului IPsec implică 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, emiteți comanda „show crypto ikev2 sa” (pe echipamentele Cisco) sau o 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 declanșează tunelul IPsec.

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

• Nu există conectivitate între client și IP-ul final al tunelului IPsec pentru instanță dedicată.

• Parametrii sesiunii IKEv2 nu se potrivesc î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 negocierii tunelului IKEv2. Jurnalele pot indica unde există o problemă cu negocierea IKEv2. Lipsa mesajelor de înregistrare poate indica, de asemenea, că sesiunea IKEv2 nu este activată.

Unele erori comune cu negocierea IKEv2 sunt:

• Setările pentru IKEv2 din 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 se potrivesc cu criptarea așteptată din partea instanței dedicate.

    Când cifrul „GCM” este utilizat, protocolul GCM gestionează autentificarea și setează parametrul de autentificare la NULL.

  • Verificați setarea duratei de viață.

  • Verificați grupul modulului Diffie Hellman.

  • Verificați setările funcției pseudo aleatoare.

• Lista de acces pentru harta criptografică 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ă)

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

Dacă mesajele jurnal nu arată nicio activitate de negociere pentru faza IKEv2, atunci poate fi necesară o captare de pachete.

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

• GRE păstrează de la interfața tunelului GRE laterală CPE la interfața tunelului GRE laterală a instanței dedicate.

• BGP vecină 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 al instanței dedicate.

  Ping nu poate fi IP-ul de transport tunel la IP de transport tunel, trebuie să fie IP tunel către 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 portul 500 sau 4500 sunt trimise și primite către și de la adresa IP DI IPsec.

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 comandă „show crypto ikev2 sa” sau echivalentă pentru a verifica sesiunea IKEv2. În ieșire, verificați dacă sesiunea IKEv2 a fost activată mai mult de câteva secunde și că nu sare. Timpul de funcționare al sesiunii se afișează ca sesiune „Timp activ” sau echivalent în ieșire.

După ce sesiunea IKEv2 este verificată ca activă, Investigați sesiunea IPsec. Ca și în cazul sesiunii IKEv2, efectuați o comandă „show crypto ipsec sa” sau 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 problemele mai frecvente care pot fi întâlnite în timpul negocierilor IPsec sunt:

Setările din partea CPE nu se potrivesc cu partea instanței dedicate, verificați din nou setările:

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

• Verificați setările Perfect Forward Secrecy și dacă setările se potrivesc din 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.

Când sesiunile IPSec și IKEv2 sunt verificate ca active și active, pachetele tunelului GRE keepalive capabile să curgă între instanța dedicată și punctele finale ale tunelului CPE. Dacă interfața tunelului nu afișează starea, unele probleme comune sunt:

• VRF pentru transportul interfeței tunelului nu se potrivește cu VRF-ul interfeței loopback (dacă configurația VRF este utilizată pe interfața tunelului).

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

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

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

  Dacă keepalives sunt acceptate, verificați dacă keepalives sunt activate.

• Masca sau adresa IP a interfeței tunelului nu este corectă și nu se potrivește cu valorile așteptate ale instanței dedicate.

• Adresa de transport a tunelului sursă sau de destinație nu este corectă și nu se potrivește cu valorile 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 funcționată și conectivitatea este bună la interfața tunelului de la distanță. Efectuați verificarea ping de la IP-ul tunelului (nu IP-ul de transport) la IP-ul tunelului de la distanță.

Verificarea ping are ca rezultat un pachet GRE care este generat de la IP-ul de transport al tunelului sursă la IP-ul de transport al tunelului de 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 are succes și elementele precedente sunt verificate, atunci poate fi necesară o captare de pachete 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 sesiuni IPsec pot ajuta, de asemenea, la afișare. dacă pachetele de trimitere și primire sunt incrementate.

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

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

Tunelul GRE ajustează caracteristica MSS și calea tunelului GRE în caracteristica de descoperire MTU este activată pe partea instanței dedicate. Configurați „ip tcp just-mss 1350" sau comanda echivalentă, precum și „calea tunelului\ u0002mtu-discovery” sau o comandă echivalentă din partea clientului pentru a ajuta la ajustarea dinamică a MTU a traficului prin tunelul VPN.