Virtual Connect uporablja dvostopenjsko arhitekturo glavnega konca, kjer ravnine usmerjanja in krmilne ravnine GRE zagotavljata ena naprava, krmilno ravnino IPsec pa druga.

Po zaključku povezljivosti Virtual Connect bosta ustvarjena dva predora GRE prek IPsec med podjetniškim omrežjem stranke in Ciscojevim podatkovnim centrom namen ske primere. Po en za vsak odvečni podatkovni center znotraj ustrezne regije. Dodatne mrežne elemente, potrebne za peering, partner ali stranka izmenjuje Cisco prek aktivacijskega obrazca Control Hub Virtual Connect.

Spodnja slika prikazuje primer modela uvajanja virtualne povezave za možnost 2-koncentratorja na strani stranke.

Virtual Connect - VPN je zasnova središča, kjer so spletna mesta strank povezana z DC1 in DC2 podatkovnih centrov namenske instance znotraj določene regije.

Za boljšo redundanco priporočamo dve lokaciji Hub, vendar je mesto One Hub z dvema predoroma tudi podprt model uvajanja.

Od partnerjev se pričakuje, da bodo tesno sodelovali s strankami in tako zagotovili, da je izbrana najbolj optimalna pot za regi jo storitev Virtual Connect.

Spodnja slika prikazuje medsebojne regije povezljivosti v oblaku namenskih primerkov.

Dodatek Routing for Virtual Connect se izvaja z uporabo zunanjega BGP (eBGP) med namenskim primerkom in opremo kupcev (CPE). Cisco bo za vsak odvečni DC znotraj regije oglaševal svoje omrežje CPE stranke, CPE pa mora oglaševati privzeto pot Cisco.

• Cisco vzdržuje in dodeljuje

  • Naslov IP vmesnika tunel (prehodna povezava za usmerjanje) Cisco dodeli iz določenega naslovnega prostora v skupni rabi (javno usmerljiv)

  • Naslov želitve prevoza v predoru (Ciscova stran)

  • Zasebne avtonomne sistemske številke (ASN) za konfiguracijo usmerjanja BGP strank

    • Cisco dodeli iz določenega območja zasebne uporabe: 64512 do 65534

• eBGP se uporablja za izmenjavo poti med namenskim instancem in CPE

  • Cisco bo dodeljeno omrežje /24 razdelil na 2 /25 enega za vsak DC v ustrezni regiji

  • V programu Virtual Connect vsako omrežje /25 oglašuje nazaj v CPE s strani Cisco prek ustreznih predorov VPN od točke do točke (prehodna povezava)

  • CPE mora biti konfiguriran z ustreznimi sosedi eBGP. Če uporabljate en CPE, bosta uporabljena dva soseda eBGP, eden kaže na vsak oddaljeni predor. Če uporabljate dva CPE, bo vsak CPE imel enega soseda eBGP, ki se pridruži enemu oddaljenemu predoru za CPE.

  • Ciscova stran vsakega predora GRE (predorski vmesnik IP) je konfigurirana kot sosed BGP na CPE

  • CPE mora oglaševati privzeto pot po vsakem od predorov

  • CPE je mogoče odgovoriti za prerazporeditev naučenih poti po potrebi znotraj poslovnega omrežja kupca.

• V pogojih okvare povezave brez okvare bo en sam CPE imel dva aktivna/aktivna predora. Za dve CPE vozlišči bo vsak CPE imel en aktivni predor in obe vozlišči CPE morata biti aktivna in prehodna prometa. V scenariju brez okvare se mora promet razdeliti na dva predora, ki gredo do pravilnih /25 ciljev, če se eden od predorov spusti, lahko preostali predor prepelje promet za oba. V takšnem scenariju okvare, ko je omrežje /25 izključeno, se omrežje /24 uporablja kot varnostna pot. Cisco bo prek notranjega omrežja WAN pošiljal promet strank proti enosmernemu omrežju, ki je izgubil povezljivost.

Pogajanja o predoru IPsec vključujejo dve fazi, fazo IKEv2 in fazo IPsec. Če se pogajanja o fazi IKEv2 ne zaključijo, potem ne pride do začetka druge faze IPsec. Najprej izdajte ukaz »show crypto ikev2 sa« (na Ciscovi opremi) ali podoben ukaz na opremi tretje osebe, da preverite, ali je seja IKEv2 aktivna. Če seja IKEv2 ni aktivna, so možni razlogi lahko naslednji:

• Zanimiv promet ne sproži predora IPsec.

• Seznam dostopa do predora IPsec je napačno konfiguriran.

• Med stranko in IP končne točke predora IPsec namenske instance ni povezljivosti.

• Parametri seje IKEv2 se ne ujemajo med stranjo namenskega primerka in stranko stranko.

• Požarni zid blokira pakete IKEv2 UDP.

Najprej preverite dnevnike IPsec za vsa sporočila, ki kažejo napredek pogajanj o predoru IKEv2. Dnevniki lahko kažejo, kje je težava pri pogajanjih IKEv2. Pomanjkanje sporočil za beleženje lahko pomeni tudi, da seja IKEv2 ni aktivirana.

Nekatere pogoste napake pri pogajanjih IKEv2 so:

• Nastavitve IKEv2 na strani CPE se ne ujemajo s strani Cisco, ponovno preverite omenjene nastavitve:

  • Preverite, ali je različica IKE različica 2.

  • Preverite, ali se parametri šifriranja in preverjanja pristnosti ujemajo s pričakovanim šifriranjem na strani namenskega primerka.

    Ko je šifra »GCM« v uporabi, protokol GCM obravnava preverjanje pristnosti in parameter preverjanja pristnosti nastavi na NULL.

  • Preverite nastavitev življenjske dobe.

  • Preverite skupino modula Diffie Hellman.

  • Preverite nastavitve psevdo naključne funkcije.

• Seznam dostopa za kripto zemljevid ni nastavljen na:

  • Dovoljenje GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255" (ali enakovreden ukaz)

    Seznam dostopa mora biti posebej za protokol »GRE« in protokol »IP« ne bo deloval.

Če dnevniška sporočila ne kažejo nobene pogajalske dejavnosti za fazo IKEv2, bo morda potreben zajem paketov.

Ko je pravilno konfiguriran, se začne predor IPsec in prva faza pogajanj IKEv2:

• GRE se ohranja od stranskega vmesnika predora GRE CPE do vmesnika predora GRE na strani namenskega instanca.

• BGP sosednja seja TCP od soseda BGP strani CPE do soseda BGP na strani namenske instance.

• Ping iz naslova IP stranskega predora CPE na naslov IP predora na stranski predor namenske instance.

  Ping ne more biti IP prevoza predora do IP prevoza v predor, temveč mora biti IP tunela do IP tunela.

Če je za promet IKEv2 potrebna sledenja paketov, nastavite filter za UDP in vrata 500 (kadar nobena naprava NAT ni na sredini končnih točk IPsec) ali vrata 4500 (ko je naprava NAT vstavljena na sredino končnih točk IPsec).

Preverite, ali so paketi IKEv2 UDP s vrati 500 ali 4500 poslani in prejeti na IP naslov DI IPsec in z njega.

Pred odpravljanjem težav z drugo fazo IPsec preverite, ali je prva faza IPsec (to je varnostna povezava IKEv2) aktivna. Izvedite »show crypto ikev2 sa« ali enakovreden ukaz, da preverite sejo IKEv2. V izhodu preverite, ali je seja IKEv2 potekala več kot nekaj sekund in da ne odskakuje. Čas delovanja seje je prikazan kot seja »Aktivni čas« ali enakovreden v izhodu.

Ko se seja IKEv2 preveri, da je odprta in aktivna, raziščite sejo IPsec. Tako kot pri seji IKEv2 izvedite »show crypto ipsec sa« ali enakovreden ukaz za preverjanje seje IPsec. Tako seja IKEv2 kot seja IPsec morata biti aktivna, preden se vzpostavi predor GRE. Če se seja IPsec ne prikaže kot aktivna, v dnevnikih IPsec preverite sporočila o napakah ali napake pri pogajanjih.

Nekatera najpogostejša vprašanja, s katerimi se lahko srečamo med pogajanji o IPsec, so:

Nastavitve na strani CPE se ne ujemajo s strani namenskega primerka, ponovno preverite nastavitve:

• Preverite, ali se parametri šifriranja in preverjanja pristnosti ujemajo z nastavitvami na strani namenskega primerka.

• Preverite nastavitve Perfect Forward Secretity in ali se nastavitve ujemajo na strani namenskega primerka.

• Preverite nastavitve življenjske dobe.

• Preverite, ali je IPsec konfiguriran v predorskem načinu.

• Preverite izvorne in ciljne naslove IPsec.

Ko se seji IPsec in IKEv2 preverita, da so odprte in aktivne, lahko paketi tunela GRE ohranijo žive med končnimi točkami namenskega instanca in predora CPE. Če se vmesnik predora ne prikazuje stanja, so nekatere pogoste težave:

• VRF transportnega vmesnika v predoru se ne ujema z VRF vmesnika za povratno zanko (če se na vmesniku tunela uporablja konfiguracija VRF).

  Če konfiguracija VRF ni uporabljena na vmesniku tunela, je to preverjanje mogoče prezreti.

• Na vmesniku stranskega predora CPE niso omogočeni Keepalives

  Če oprema CPE ni podprta, morate o tem obvestiti Cisco, tako da so privzeti pomnilniki na strani namenskega primerka onemogočeni.

  Če so pomnilniki podprti, preverite, ali so pomnilniki omogočeni.

• Maska ali naslov IP vmesnika predora nista pravilna in se ne ujema s pričakovanimi vrednostmi namenskega primerka.

• Naslov za prevoz izvornega ali ciljnega predora ni pravilen in se ne ujema s pričakovanimi vrednostmi namenskega primerka.

• Požarni zid blokira pošiljanje paketov GRE v predor IPsec ali prejem iz predora IPsec (predor GRE se prevaža čez predor IPsec)

Test ping mora preveriti, ali je lokalni vmesnik predora vklopljen in da je povezljivost dobra z oddaljenim vmesnikom predora. Izvedite preverjanje ping od IP predora (ne transportnega IP) do IP oddaljenega predora.

Preverjanje ping ima za posledico paket GRE, ki se ustvari iz IP prevoza izvornega predora do IP prevoza ciljnega predora, medtem ko bo koristna obremenitev paketa GRE (notranji IP) izvorni in ciljni tunel IP.

Če ping test ni uspešen in so prejšnji elementi preverjeni, bo morda potreben zajem paketov, da se zagotovi, da icmp ping povzroči paket GRE, ki se nato inkapsulira v paket IPsec in nato pošlje iz izvornega naslova IPsec na ciljni naslov IPsec. Tudi števci na vmesniku tunela GRE in števci sej IPsec lahko pomagajo prikazati, če se paketi za pošiljanje in prejem povečujejo.

Poleg ping prometa bi moral zajem prikazovati tudi pakete Keepalive GRE tudi med prometom v prostem teku. Končno, če je konfiguriran BGP, je treba pakete BGP keepalive poslati tudi kot pakete GRE, kapsulirane v pakete IPSEC, pa tudi prek VPN.

Na strani namenskega primerka sta omogočeni dve funkciji za dinamično prilagajanje MTU za velike velikosti paketov. Predor GRE doda več glav paketom IP, ki tečejo skozi sejo VPN. Predor IPsec doda dodatne glave na vrhu glave GRE, kar bo še dodatno zmanjšalo največji dovoljeni MTU nad predorom.

Predor GRE prilagaja funkcijo MSS in pot predora GRE v funkciji odkrivanja MTU je omogočena na strani namenskega primerka. Konfigurirajte »ip tcp ajust-mss 1350" ali enakovreden ukaz ter »tunnel path\ u0002mtu-Discovery« ali enakovreden ukaz na strani stranke za pomoč pri dinamičnem prilagajanju MTU prometa skozi tunel VPN.