A Virtual Connect kétszintű fejállomási architektúrát használ, ahol az útválasztási és GRE vezérlősíkokat az egyik eszköz, az IPSec vezérlősíkot pedig egy másik eszköz biztosítja.

Befejezése után a Virtuális kapcsolat kapcsolat esetén két GRE over IPSec alagút jön létre az Ügyfél nagyvállalati hálózata és a dedikált példány Cisco adatközpontjai között. A megfelelő Régión belül minden egyes redundáns adatközponthoz egyet. A társviszony-létesítéshez szükséges további hálózati elemeket a Partner vagy az Ügyfél a Control Hub Virtual Connect aktiválási űrlapján keresztül küldi el a Cisco felé.

Az 1. ábra a Virtual Connect üzembehelyezési modell mutat példát a 2 koncentrátoros opcióhoz az ügyfél oldalon.

Virtuális kapcsolat – A VPN egy Hub kialakítás, ahol az Ügyfél hub-helyszínei a dedikált példányok adatközpontjainak DC1 és DC2-jéhez csatlakoznak egy adott régión belül.

A redundancia javítása érdekében két Hub-webhely javasolt, de a két alagúttal rendelkező egy hubhely is támogatott üzembehelyezési modell.

Az alagútonkénti sávszélesség 250 Mbps-ra van korlátozva.

Az Ügyfél ugyanazon a régión belüli távoli telephelyeinek vissza kell kapcsolódniuk a Hub telephelye(i)hez az Ügyfél WAN-ján keresztül, és ez nem a Cisco felelőssége ezért a kapcsolatért.

A partnerektől elvárható, hogy szorosan együttműködjenek az Ügyfelekkel, így biztosítva, hogy a „Virtuális kapcsolat” szolgáltatási régió számára a legoptimálisabb útvonal kerüljön kiválasztásra.

A 2. ábra a dedikált példány-felhőkapcsolati társviszony-létesítési régiókat mutatja be.

Az útválasztás a Virtual Connect bővítmény külső BGP (eBGP) segítségével valósul meg a dedikált példány és a Customer Premise Equipment (CPE) között. A Cisco egy régión belül minden egyes redundáns DC-hez meghirdeti a megfelelő hálózatát az Ügyfél CPE-je számára, a CPE-nek pedig egy alapértelmezett útvonal meghirdetéséhez a Cisco felé.

• A Cisco karbantartja és hozzárendeli

  • Alagútinterfész IP -címzés (tranziens hivatkozás az útválasztáshoz) A Cisco egy kijelölt (nem nyilvánosan továbbítható) megosztott címtérből rendel hozzá

  • Alagút szállítási célcím címe (Cisco oldalán)

  • Privát autonóm rendszerszámok (ASN) az ügyfél BGP-útválasztási konfigurációjához

    • A Cisco a kijelölt privát felhasználási tartományból rendeli hozzá: 64512-65534

• Az eBGP a dedikált példány és a CPE közötti útvonalcserére szolgál

  • A Cisco a hozzárendelt /24-es hálózatot 2/25-1-re osztja az egyes DC-k számára a megfelelő régióban

  • A Virtual Connect alkalmazásban a Cisco minden /25-ös hálózatot visszahirdet a CPE-nek a megfelelő pont-pont VPN -alagutakon keresztül (tranziens kapcsolat).

  • A CPE-t a megfelelő eBGP-szomszédokkal kell konfigurálni. Ha egy CPE-t használ, akkor két eBGP-szomszéd lesz használatban, amelyek közül egy mindegyik távoli alagútra mutat. Ha két CPE-t használ, akkor mindegyik CPE-nek lesz egy eBGP-szomszédja, amely a CPE egyetlen távoli alagútjához mutat.

  • Az egyes GRE-alagutak (alagútinterfész IP -címe) Cisco oldala BGP-szomszédként van beállítva a CPE-n.

  • CPE szükséges ahhoz, hogy minden alagutakon alapértelmezett útvonalat hirdessenek

  • A CPE felelős a tanult útvonalak igény szerinti újraelosztásáért az ügyfél vállalati hálózatán belül.

• Hibamentes kapcsolathiba esetén egyetlen CPE-nek két aktív/aktív alagútja lesz. Két CPE-csomópont esetén mindegyik CPE-nek egy aktív alagútja lesz, és mindkét CPE-csomópontnak aktívnak és átmenő forgalmúnak kell lennie. Hibamentes forgatókönyv esetén a forgalmat két alagútra kell felosztani, amelyek a megfelelő /25 úticélok felé haladnak, ha pedig az egyik alagút lezuhan, a fennmaradó alagút továbbíthatja mindkettő forgalmát. Ilyen hiba esetén, amikor a /25-ös hálózat nem működik, a /24-es hálózat lesz tartalék útvonal. A Cisco a belső WAN-on keresztül továbbítja az ügyfélforgalmat a kapcsolatot elvesztő DC felé.

Az IPsec alagút egyeztetés két fázisból áll, az IKEv2 fázisból és az IPsec fázisból. Ha az IKEv2-fázis-egyeztetés nem fejeződik be, akkor nincs második IPsec-fázis kezdeményezése. Először adja ki a „show crypto ikev2 sa” ( Cisco berendezéseken) vagy hasonló parancsot a külső gyártótól származó eszközön annak ellenőrzésére, hogy az IKEv2 munkamenet aktív-e. Ha az IKEv2-munkamenet nem aktív, a lehetséges okok a következők lehetnek:

• Az érdekes forgalom nem váltja ki az IPsec alagutat.

• Az IPsec-alagút- hozzáférési lista helytelenül van konfigurálva.

• Nincs kapcsolat az ügyfél és a dedikált példány IPsec alagútvégpont IP-címe között.

• Az IKEv2 munkamenet paraméterei nem egyeznek meg a dedikált példány oldal és az ügyfél oldal között.

• Egy tűzfal blokkolja az IKEv2 UDP -csomagokat.

Először ellenőrizze az IPsec-naplókat, hogy vannak-e olyan üzenetek, amelyek az IKEv2 alagútegyeztetés előrehaladását mutatják. A naplók jelezhetik, hogy hol van probléma az IKEv2-egyeztetéssel. A naplózási üzenetek hiánya azt is jelezheti, hogy az IKEv2-munkamenet nincs aktiválva.

Az IKEv2 egyeztetés néhány gyakori hibája:

• Az IKEv2 CPE oldali beállításai nem egyeznek meg a Cisco oldallal, ellenőrizze újra az említett beállításokat:

  • Ellenőrizze, hogy az IKE verziója a 2-es verziójú-e.

  • Ellenőrizze, hogy a Titkosítás és a Hitelesítés paraméterek egyeznek-e a dedikált példány oldalon várt titkosítással.

    Amikor a „GCM” titkosítás használatban van, a GCM protokoll kezeli a hitelesítést, és a hitelesítési paramétert NULL-ra állítja.

  • Ellenőrizze az élettartam-beállítást.

  • Ellenőrizze a Diffie Hellman moduluscsoportot.

  • Ellenőrizze a pszeudo véletlen függvény beállításait.

• A titkosítási leképezés hozzáférési lista nincs beállítva a következőre:

  • Engedélyezés GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (vagy ezzel egyenértékű parancs)

    A hozzáférési lista kifejezetten a „GRE” protokollhoz kell tartoznia, és az „IP” protokoll nem fog működni.

Ha a naplóüzenetek nem mutatnak egyeztetési tevékenységet az IKEv2 fázisra, akkor csomagrögzítés lehet szükség.

Előfordulhat, hogy a dedikált példány oldal nem mindig kezdi el az IKEv2 cserét, és néha elvárhatja, hogy az ügyfél CPE oldal legyen a kezdeményező. Ellenőrizze a CPE-oldali konfigurációban az IKEv2-munkamenet kezdeményezésének alábbi előfeltételeit: Keressen IPsec-titkosítási hozzáférési lista a GRE-forgalomhoz (50-es protokoll) a CPE alagút szállítási IP -címétől a dedikált példány alagúttovábbítási IP-címéig. Gondoskodjon arról, hogy a GRE alagút interfész engedélyezve legyen a GRE Keepalives számára. Ha a berendezés nem támogatja a GRE Keepalives funkciót, akkor a Cisco értesítést kap, mert a GRE alagút interfész alapértelmezés szerint a dedikált példány oldalon lesz engedélyezve. Győződjön meg arról, hogy a BGP engedélyezve van, és a dedikált példány alagút IP-jének szomszédos címével van konfigurálva.

Ha megfelelően van konfigurálva, a következő elindítja az IPsec-alagutat és az első fázisú IKEv2-egyeztetést:

• A GRE folyamatosan működik a CPE oldali GRE alagút felületről a dedikált példány oldali GRE alagút felületre.

• BGP-szomszéd TCP -munkamenet a CPE-oldali BGP-szomszédtól a dedikált példány-oldali BGP-szomszédig.

• Pingelés a CPE oldali alagút IP-cím a dedikált példány oldali alagút IP-cím.

  A Ping nem lehet az alagút szállítási IP -címe alagút szállítási IP-címbe, hanem alagút IP -címe alagút IP-címe lehet.

Ha csomagnyomkövetésre van szükség az IKEv2-forgalomhoz, állítsa be a szűrőt az UDP -re és vagy az 500-as portra (amikor nincs NAT-eszköz az IPsec-végpontok közepén) vagy a 4500-as portra (ha egy NAT-eszközt helyeznek be az IPsec közepébe végpontok).

Ellenőrizze , hogy az 500 - as vagy 4500 - as porttal rendelkező IKEv2 UDP - csomagok a DI IPsec IP-cím, illetve onnan érkeznek - e és fogadják - e .

Előfordulhat, hogy a dedikált példány adatközpont nem mindig kezdi el az első IKEv2-csomagot. A követelmény az, hogy a CPE eszköz képes legyen kezdeményezni az első IKEv2 csomagot a dedikált példány oldal felé. Ha a helyi tűzfal engedélyezi, akkor próbáljon meg egy pinget a távoli IPsec-címre is. Ha a ping nem sikeres a helyi IPsec-címről a távoli IPsec-címre, akkor végezzen nyomkövetési útvonalat a segítségnyújtás érdekében, és határozza meg, hová került a csomag. Előfordulhat, hogy egyes tűzfalak és internetes berendezések nem engedélyezik az útvonal nyomon követését.

Az IPsec második fázisának hibaelhárítása előtt ellenőrizze, hogy az IPsec első fázisa (vagyis az IKEv2 biztonsági társítás) aktív-e. Adjon ki egy „show crypto ikev2 sa” vagy ezzel egyenértékű parancsot az IKEv2 munkamenet ellenőrzéséhez. A kimenetben ellenőrizze, hogy az IKEv2-munkamenet néhány másodpercnél tovább működik-e, és hogy nem pattan-e. A munkamenet rendelkezésre állási ideje a munkamenet „Aktív ideje” vagy ennek megfelelőjeként jelenik meg a kimenetben.

Miután az IKEv2-munkamenet bebizonyosodott, hogy működőképes és aktív, vizsgálja meg az IPsec-munkamenetet. Az IKEv2-munkamenethez hasonlóan hajtson végre egy „show crypto ipsec sa” vagy azzal egyenértékű paranccsal az IPsec-munkamenet ellenőrzéséhez. Az IKEv2-munkamenetnek és az IPsec-munkamenetnek is aktívnak kell lennie a GRE-alagút létrehozása előtt. Ha az IPsec-munkamenet nem aktívként jelenik meg, ellenőrizze az IPsec-naplókat, hogy vannak-e hibaüzenetek vagy egyeztetési hibák.

Az IPsec-tárgyalások során felmerülő gyakoribb problémák a következők:

A CPE oldal beállításai nem egyeznek meg a Dedikált példány oldallal, ellenőrizze újra a beállításokat:

• Ellenőrizze, hogy a Titkosítás és a Hitelesítés paraméterek egyeznek-e a Dedikált példány oldalon lévő beállításokkal.

• Ellenőrizze a Perfect Forward Secrecy (Tökéletes továbbítási titok) beállításokat, és azt, hogy a Dedikált példány oldalon egyeznek-e a beállítások.

• Ellenőrizze az élettartamra vonatkozó beállításokat.

• Ellenőrizze, hogy az IPsec alagút módban van-e konfigurálva.

• Ellenőrizze a forrás és a cél IPsec-címét.

Ha az IPsec- és IKEv2-munkamenetek működőképesek és aktívak, a GRE-alagút életben tartó csomagjai képesek folyni a dedikált példány és a CPE alagútvégpontok között. Ha az alagút felületének állapota nem jelenik meg, néhány gyakori probléma a következő:

• Az alagút interfész szállítási VRF nem egyezik meg a visszahurkolási interfész VRF-jével (ha VRF konfigurációt használnak az alagút interfészen).

  Ha nem a VRF konfigurációt használják az alagút interfészen, akkor ez az ellenőrzés figyelmen kívül hagyható.

• Az életben tartás nem engedélyezett a CPE oldali alagút felületen

  Ha a CPE berendezés nem támogatja az életmentesítést, akkor értesítenie kell a Cisco -t, hogy a dedikált példány oldalon az alapértelmezett Keepalive funkció is le legyen tiltva. Ha a fenntartó funkciók támogatottak, ellenőrizze, hogy azok engedélyezve vannak-e.

• Az alagútinterfész maszkja vagy IP-cím nem megfelelő, és nem egyezik meg a dedikált példány várható értékeivel.

• A forrás vagy a cél alagút szállítási címe nem megfelelő, és nem egyezik meg a dedikált példány várható értékeivel.

• Egy tűzfal megakadályozza, hogy a GRE-csomagok az IPsec-alagútba küldjenek vagy az IPsec-alagútból fogadjanak (a GRE-alagút az IPsec-alagúton keresztül kerül továbbításra)

A ping tesztnek ellenőriznie kell, hogy a helyi alagútinterfész működik-e, és hogy megfelelő-e a kapcsolat a távoli alagútinterfészhez. Végezze el a ping-ellenőrzést az alagút IP -címéről (nem a szállítási IP-címről) a távoli alagút IP-címére.

A GRE alagút forgalmat továbbító IPsec alagút titkosítási hozzáférési lista csak GRE csomagok keresztezését engedélyezi. Emiatt a ping nem fog működni az alagút szállítási IP -címről a távoli alagúttovábbítási IP-címre.

A ping ellenőrzés egy GRE csomagot eredményez, amely a forrás alagút szállítási IP -címtől a cél alagút szállítási IP -címig generálódik, míg a GRE csomag hasznos terhelése (a belső IP) lesz a forrás és a cél alagút IP-címe.

Ha a ping teszt nem sikeres, és az előző tételek ellenőrzésre kerülnek, akkor csomagrögzítés lehet szükség annak biztosítására, hogy az icmp ping egy GRE csomagot eredményezzen, amelyet azután egy IPsec-csomagba zárnak, majd elküldik a forrás IPsec-címről a a cél IPsec-címét. A GRE alagút felület számlálói és az IPsec munkamenet számlálók is segíthetnek a megjelenítésben. ha a küldési és fogadási csomagok száma növekszik.

A ping forgalom mellett a rögzítésnek a folyamatosan életben lévő GRE csomagokat is mutatnia kell, még tétlen forgalom esetén is. Végül, ha a BGP be van állítva, a BGP Keepalive csomagokat GRE-csomagokként is el kell küldeni IPSEC-csomagokba zárva, valamint a VPN-en keresztül.

A Dedikált példány oldalon két funkció engedélyezve van az MTU dinamikus beállításához nagy csomagméretekhez. A GRE alagút további fejlécekkel látja el a VPN -munkameneten átfolyó IP -csomagokat. Az IPsec-alagút további fejlécek hozzáadása a GRE fejlécekhez tovább csökkenti az alagútban megengedett legnagyobb MTU-értéket.

A GRE alagút beállítja az MSS funkciót, és a GRE alagútútvonal az MTU-felfedezés szolgáltatásban engedélyezett a dedikált példány oldalon. Konfigurálja az "ip tcp adapt-mss 1350" vagy azzal egyenértékű parancsot, valamint az "tunnel path\u0002mtu-discovery" vagy ezzel egyenértékű parancsot az ügyfél oldalon, hogy segítse a VPN alagúton keresztül érkező forgalom MTU dinamikus beállítását.