Virtual Connect využíva dvojúrovňovú architektúru headend, kde smerovacie a riadiace ro viny GRE poskytujú jedno zariadenie a riadiacu rovinu IPsec poskytuje iné.

Po dokončení pripojenia Virtual Connect sa vytvoria dva tunely GRE over IPsec medzi podnikovou sieťou zákazníka a dátovými centrami Cisco s dedikovanou inštanciou. Jeden do každého nadbytočného dátového centra v príslušnom regióne. Ďalšie sieťové prvky potrebné pre peering si Partner alebo Zákazník vymieňa spoločnosti Cisco prostredníctvom aktivačného formulára Control Hub Virtual Connect.

Nasledujúci obrázok ukazuje príklad modelu nasadenia virtuálneho pripojenia pre možnosť 2-koncentrátora na strane zákazníka.

Virtual Connect - VPN je dizajn Hub, kde sú stránky zákazníckeho centra pripojené k DC1 a DC2 dátových centier dedikovanej inštancie v rámci konkrétneho regiónu.

Pre lepšiu redundanciu sa odporúčajú dve lokality Hub, ale One Hub site s dvoma tunelmi je tiež podporovaným modelom nasadenia.

Od partnerov sa očakáva, že budú úzko spolupracovať so zákazníkmi a zabezpečiť, aby bola zvol ená najoptimálnejšia cesta pre oblasť služieb Virtual Connect.

Nasledujúci obrázok zobrazuje partnerské oblasti cloudového pripojenia k dedikovanej inštancii.

Doplnok Routing for Virtual Connect je implementovaný pomocou externého BGP (eBGP) medzi dedikovanou inštanciou a zariadením Customer Premise Equipment (CPE). Spoločnosť Cisco bude inzerovať svoju príslušnú sieť pre každý redundantný DC v rámci regiónu CPE zákazníka a CPE je povinný inzerovať predvolenú trasu do spoločnosti Cisco.

• Cisco udržiava a priraďuje

  • Adresovanie IP tunelového rozhrania (prechodné prepojenie na smerovanie) Cisco priraďuje z určeného zdieľaného adresného priestoru (nie je verejne smerovateľné)

  • Adresa želania dopravy tunelov (strana spoločnosti Cisco)

  • Súkromné autonómne systémové čísla (ASN) pre zákaznícku konfiguráciu smerovania BGP

    • Spoločnosť Cisco priraďuje z určeného rozsahu súkromného použitia: 64512 až 65534

• eBGP používaný na výmenu trás medzi dedikovanou inštanciou a CPE

  • Cisco rozdelí priradenú sieť /24 na 2 /25 pre každý DC v príslušnom regióne

  • Vo Virtual Connect je každá sieť /25 inzerovaná späť do CPE spoločnosťou Cisco prostredníctvom príslušných tunelov VPN typu point-to-point (prechodné spojenie)

  • CPE musí byť nakonfigurovaný s príslušnými susedmi eBGP. Ak použijete jeden CPE, použijú sa dvaja susedia eBGP, jeden smeruje na každý vzdialený tunel. Ak používate dva CPE, potom každý CPE bude mať jedného suseda eBGP, ktorý sa nachádza na jedinom vzdialenom tuneli pre CPE.

  • Cisco strana každého tunela GRE (tunelové rozhranie IP) je nakonfigurovaná ako suseda BGP na CPE

  • CPE je povinný inzerovať predvolenú trasu cez každý z tunelov

  • CPE je možné odpovedať na prerozdeľovanie naučených trás podľa potreby v rámci podnikovej siete zákazníka.

• V podmienkach poruchy spojenia bez poruchy bude mať jeden CPE dva aktívne/aktívne tunely. Pre dva uzly CPE bude mať každý CPE jeden aktívny tunel a oba uzly CPE by mali byť aktívne a prechádzajúce premávky. Podľa scenára bez zlyhania sa doprava musí rozdeliť do dvoch tunelov smerujúcich do správnych /25 cieľov, ak jeden z tunelov klesne, zostávajúci tunel môže viesť dopravu pre obe. Pri takomto zlyhaní, keď je sieť /25 prerušená, potom sa sieť /24 použije ako záložná trasa. Cisco bude posielať zákaznícky prenos prostredníctvom svojej internej WAN smerom k DC, ktorý stratil pripojenie.

Rokovania o tuneli IPsec zahŕňajú dve fázy, fázu IKEv2 a fázu IPsec. Ak sa rokovania o fáze IKEv2 nedokončia, nedôjde k iniciácii druhej fázy IPsec. Najprv vydajte príkaz „show crypto ikev2 sa“ (na zariadení Cisco) alebo podobný príkaz na zariadení tretej strany, aby ste overili, či je relácia IKEv2 aktívna. Ak relácia IKEv2 nie je aktívna, možné dôvody môžu byť:

• Zaujímavá prevádzka nespúšťa tunel IPsec.

• Zoznam prístupových tunelov IPsec je nesprávne nakonfigurovaný.

• Neexistuje žiadna konektivita medzi zákazníkom a IP koncového bodu tunela IPsec pre dedikovanú inštanciu.

• Parametre relácie IKEv2 sa nezhodujú medzi stranou vyhradenej inštancie a stranou zákazníka.

• Firewall blokuje pakety IKEv2 UDP.

Najprv skontrolujte protokoly IPsec, či neobsahujú správy, ktoré ukazujú priebeh rokovaní o tuneli IKEv2. Protokoly môžu naznačovať, kde sa vyskytol problém s rokovaním IKEv2. Nedostatok hlásených správ môže tiež naznačovať, že relácia IKEv2 nie je aktivovaná.

Niektoré bežné chyby pri vyjednávaní IKEv2 sú:

• Nastavenia IKEv2 na strane CPE sa nezhodujú so stranou Cisco, znova skontrolujte uvedené nastavenia:

  • Skontrolujte, či je verzia IKE verzia 2.

  • Skontrolujte, či parametre šifrovania a autentifikácie zodpovedajú očakávanému šifrovaniu na strane vyhradenej inštancie.

    Keď sa používa šifra „GCM“, protokol GCM spracuje autentifikáciu a nastaví parameter autentifikácie na NULL.

  • Skontrolujte nastavenie životnosti.

  • Overte skupinu modulov Diffie Hellman.

  • Skontrolujte nastavenia Pseudo Random Function.

• Prístupový zoznam pre krypto mapu nie je nastavený na:

  • Povolenie GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255" (alebo ekvivalentný príkaz)

    Zoznam prístupov musí byť špeciálne pre protokol „GRE“ a protokol „IP“ nebude fungovať.

Ak správy denníka nezobrazujú žiadnu rokovaciu činnosť pre fázu IKEv2, môže byť potrebné zachytenie paketov.

Po správnom nakonfigurovaní sa spustí tunel IPsec a prvá fáza rokovania IKEv2:

• GRE prechádza z rozhrania tunela GRE bočného CPE po bočné rozhranie tunela GRE na strane dedikovanej inštancie.

• Relácia TCP suseda BGP od suseda BGP na strane CPE k susedovi BGP na strane dedikovanej inštancie.

• Ping z IP adresy bočného tunela CPE na adresu IP bočného tunela vyhradenej inštancie.

  Ping nemôže byť IP prenosu tunela do tunelovej dopravy IP, musí to byť tunelová IP na tunelovú IP.

Ak je potrebné sledovanie paketov pre prenos IKEv2, nastavte filter pre UDP a buď port 500 (ak nie je v strede koncových bodov IPsec žiadne zariadenie NAT) alebo port 4500 (keď je do stredu koncových bodov IPsec vložené zariadenie NAT).

Overte, či sú IKEv2 UDP pakety s portom 500 alebo 4500 odosielané a prijímané na IP adresu DI IPsec a z nej.

Pred riešením problémov s druhou fázou IPsec skontrolujte, či je aktívna prvá fáza IPsec (to znamená asociácia zabezpečenia IKEv2). Vykonajte príkaz „show crypto ikev2 sa“ alebo ekvivalentný príkaz na overenie relácie IKEv2. Na výstupe skontrolujte, či relácia IKEv2 bola spustená dlhšie ako niekoľko sekúnd a či sa neodskakuje. Doba prevádzkyschopnosti relácie sa zobrazuje ako relácia „Aktívny čas“ alebo ekvivalent vo výstupe.

Akonáhle sa relácia IKEv2 overí, že je spustená a aktívna, Preskúmajte reláciu IPsec. Rovnako ako v prípade relácie IKEv2 vykonajte príkaz „show crypto ipsec sa“ alebo ekvivalentný príkaz na overenie relácie IPsec. Pred vytvorením tunela GRE musia byť aktívne relácia IKEv2 aj relácia IPsec. Ak sa relácia IPsec nezobrazuje ako aktívna, skontrolujte chybové hlásenia alebo chyby vyjednávania v protokoloch IPsec.

Niektoré z najčastejších problémov, ktoré sa môžu vyskytnúť počas rokovaní o IPsec, sú:

Nastavenia na strane CPE sa nezhodujú so stranou vyhradenej inštancie, znova skontrolujte nastavenia:

• Skontrolujte, či parametre šifrovania a autentifikácie zodpovedajú nastaveniam na strane vyhradenej inštancie.

• Skontrolujte nastavenia Perfect Forward Secretity a či sa nastavenia zhodujú na strane vyhradenej inštancie.

• Overte nastavenia životnosti.

• Skontrolujte, či bol protokol IPsec nakonfigurovaný v tunelovom režime.

• Overte zdrojovú a cieľovú adresu IPsec.

Keď sú relácie IPsec a IKEv2 overené ako otvorené a aktívne, tunel GRE udržuje aktívne pakety schopné prúdiť medzi koncovými bodmi Dedikovanou inštanciou a CPE tunelom. Ak sa stav rozhrania tunela nezobrazuje, niektoré bežné problémy sú:

• VRF pre transport tunelového rozhrania sa nezhoduje s VRF spätného rozhrania (ak sa na tunelovom rozhraní používa konfigurácia VRF).

  Ak sa konfigurácia VRF nepoužíva na rozhraní tunela, túto kontrolu je možné ignorovať.

• Keepalives nie sú povolené na rozhraní bočného tunela CPE

  Ak nie sú na zariadení CPE podporované pamäťové súbory, musí byť Cisco upozornený, aby boli zakázané aj predvolené pamätníky na strane Dedikovanej inštancie.

  Ak sú podporované pamätníky, skontrolujte, či sú pamätníky povolené.

• Maska alebo adresa IP rozhrania tunela nie je správna a nezodpovedá očakávaným hodnotám vyhradenej inštancie.

• Zdrojová alebo cieľová adresa prepravy tunela nie je správna a nezodpovedá očakávaným hodnotám vyhradenej inštancie.

• Firewall blokuje odosielanie paketov GRE do tunela IPsec alebo prijímanie z tunela IPsec (tunel GRE sa prepravuje cez tunel IPsec)

Test ping by mal overiť, či je rozhranie miestneho tunela funkčné a či je pripojenie dobré k rozhraniu vzdialeného tunela. Vykonajte kontrolu ping z IP tunela (nie prepravnej IP) na IP vzdialeného tunela.

Výsledkom kontroly ping je paket GRE, ktorý sa generuje z IP dopravy zdrojového tunela do IP prepravy cieľového tunela, zatiaľ čo užitočná záťaž paketu GRE (vnútorná IP) bude zdrojovou a cieľovou tunelovou IP.

Ak test ping nie je úspešný a predchádzajúce položky sú overené, môže byť potrebné zachytenie paketov, aby sa zabezpečilo, že icmp ping vedie k GRE paketu, ktorý je potom zapuzdrený do paketu IPsec a potom odoslaný zo zdrojovej adresy IPsec na cieľovú adresu IPsec. Počítadlá na rozhraní tunela GRE a počítadlá relácií IPsec môžu tiež pomôcť zobraziť, ak sa zvyšujú pakety odosielania a prijímania.

Okrem prenosu ping by snímanie malo zobrazovať aj pakety Keepalive GRE aj počas nečinnej prevádzky. Nakoniec, ak je nakonfigurovaný BGP, pakety BGP keepalive by sa mali posielať aj ako pakety GRE zapuzdrené v paketoch IPSEC, ako aj cez VPN.

Na strane Dedikovanej inštancie sú povolené dve funkcie na dynamické nastavenie MTU pre veľké veľkosti paketov. Tunel GRE pridáva ďalšie hlavičky do paketov IP pretekajúcich cez reláciu VPN. Tunel IPsec pridáva ďalšie hlavičky na vrch hlavičiek GRE, čo ešte viac zníži najväčší MTU povolený nad tunelom.

Tunel GRE upravuje funkciu MSS a cesta tunela GRE v funkcii zisťovania MTU je povolená na strane dedikovanej inštancie. Nakonfigurujte „ip tcp ajust-mss 1350" alebo ekvivalentný príkaz, ako aj „tunnel path\ u0002mtu-Discovery“ alebo ekvivalentný príkaz na strane zákazníka, aby ste pomohli s dynamickým nastavením MTU prevádzky cez tunel VPN.