- Kezdőlap
- /
- Cikk
Köszönjük visszajelzését.
Dedikált Instance-Virtuális Csatlakozás
Ebben a cikkben
Visszajelzés?A Virtual Connect egy további kiegészítő lehetőség a felhőcsatlakozáshoz a Webex Calling dedikált példányhoz. A Virtual Connect lehetővé teszi az ügyfelek számára, hogy biztonságosan bővítsék magánhálózatukat az interneten keresztül a pont-pont IP VPN-alagutak segítségével. Itt megvitatjuk a Virtual Connect megrendelését, aktiválását és konfigurálását.
Bevezetés
A Virtual Connect egy további kiegészítő lehetőség a Cloud Connectivity to Dedicated Instance for Webex Calling (Dedikált példány) számára. A Virtual Connect lehetővé teszi az ügyfelek számára, hogy biztonságosan bővítsék magánhálózatukat az interneten keresztül a pont-pont IP VPN-alagutak segítségével. Ez a csatlakozási lehetőség lehetővé teszi a privát hálózati kapcsolat gyors létrehozását a meglévő ügyfélszolgálati berendezések (CPE) és az internetkapcsolat használatával.
A Cisco a redundáns IP-VPN-alagutakat és a szükséges internet-hozzáférést tárolja, kezeli és biztosítja a Cisco dedikált példányú adatközpont régiójában (i) ben, ahol a szolgáltatás igényelt. Hasonlóképpen, az Administrator felelős a megfelelő CPE- és internetszolgáltatásokért, amelyek a Virtual Connect létrehozásához szükségesek.
Egy adott dedikált példányrégió virtuális csatlakozási sorrendjeiben két általános útválasztási kapszulációs (GRE) alagutat foglal magában, amelyeket IPsec titkosítással (GRE over IPsec) védettek, egyet a Cisco minden egyes adatközpontjához a kiválasztott régióban.
A Virtual Connect sávszélessége alagútonként 250 Mbps, és kisebb telepítéseknél ajánlott. Mivel két pont-pont VPN alagutat használnak fel, a felhőbe érkező összes forgalomnak át kell mennie a CPE-n keresztül, ezért előfordulhat, hogy nem alkalmas ott, ahol sok távoli webhely van. További alternatív peering lehetőségekért lásd: Fel hőkapcsolat.
Mielőtt elküldené a virtuális kapcsolat párkeresését, győződjön meg arról, hogy a Dedikált példány szolgáltatás aktiválva van-e az adott régióban.
Feltételek
A Virtual Connect létrehozásának előfeltételei a következők:
-
Az ügyfél biztosítja
-
Internetkapcsolat elegendő rendelkezésre álló sávszélességgel a telepítés támogatásához
-
Nyilvános IP-cím (ek) két IPsec alagúthoz
-
Ügyfél oldali GRE szállítási IP-címek a két GRE alagúthoz
-
-
Partner és Ügyfél
-
Együtt dolgozzon a sávszélesség igényének értékelésében
-
Gondoskodjon arról, hogy a hálózati eszköz (ok) támogatja a Border Gateway Protocol (BGP) útválasztását és a GRE IPsec alagút kialakítását
-
-
Partner vagy Ügyfél biztosítja
-
Hálózati csapat, aki ismeretekkel rendelkezik webhely-helyre VPN alagút technológiákról
-
Hálózati csapat a BGP, az eBGP és az általános útválasztási elvek ismeretében
-
-
Cisco
-
A Cisco privát autonóm rendszerszámokat (ASN) és átmeneti IP-címzést rendelt GRE alagút interfészekhez
-
A Cisco nyilvános, de nem internetes útválasztható C (/24) osztályú hálózatot rendelt a dedikált példányfelhő-címzéshez
-
Ha egy ügyfélnek csak 1 CPE készüléke van, akkor a Cisco adatközpontjai felé (DC1 és DC2) irányuló 2 alagút az egyes régiókban a CPE eszközről származik. Az ügyfélnek lehetősége van 2 CPE eszközre is, akkor minden CPE eszköznek csak a Cisco adatközpontja (DC1 és DC2) felé kell csatlakoznia 1 alagútba az egyes régiókban. További redundancia érhető el, ha az egyes alagutakat külön fizikai helyszínben/helyszínen lezárjuk az Ügyfél infrastruktúráján belül.
Műszaki részletek
Telepítési modell
A Virtual Connect kétszintű headend architektúrát használ, ahol az útválasztó és a GRE vezérlő síkokat egy eszköz, az IPsec vezérlősíkot pedig egy másik biztosítja.
A Virtual Connect kapcsolat befejezése után két GRE over IPsec alagút jön létre az Ügyfél vállalati hálózata és a Cisco dedicated Instance adatközpontjai között. Egy-egy minden redundáns adatközponthoz az adott régióban. A peeringhez szükséges további hálózati elemeket a Partner vagy az Ügyfél kicseréli a Cisco felé a Control Hub Virtual Connect aktiválási űrlapján keresztül.
Az alábbi ábra a virtuális kapcsolat telepítési modelljének példáját mutatja a 2-koncentrátor opcióhoz az ügyfél oldalon.
Virtuális kapcsolat - VPN egy olyan Hub kialakítás, amelyben az Ügyfél központi webhelyei egy adott régión belüli dedikált példány adatközpontjainak DC1 és DC2-jéhez kapcsolódnak.
A jobb redundancia érdekében két Hub webhely ajánlott, de a két alagúttal rendelkező One Hub webhely szintén támogatott telepítési modell.
Az alagútonkénti sávszélesség 250 Mbps-ra korlátozódik. A hatékony feladatátvétel biztosítása érdekében a két alagút együttes forgalma nem haladhatja meg a 250 Mbps-ot, mivel meghibásod ás esetén az összes forgalom egy alagúton keresztül irányul.
Az Ügyfél ugyanazon régión belüli távoli telephelyeinek vissza kell kapcsolniuk a Hub webhelyéhez az Ügyfél WAN-jén keresztül, és ez nem a Cisco felelőssége a csatlakozásért.
A partnerektől elvárjuk, hogy szorosan együttműködjenek az Ügyfelekkel, biztosítva a Virtual Connect szolgáltatási régió számára a legoptimálisabb útv onalat.
Az alábbi ábra a dedikált példány felhőkapcsolódási peering régióit mutatja be.
Útvonaltervezés
Az Routing for 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üli minden redundáns DC hálózatát hirdeti az Ügyfél CPE-jéhez, és a CPE köteles hirdetni egy alapértelmezett útvonalat a Cisco felé.
-
A Cisco karbantartja és hozzárendeli
-
Alagútinterfész IP-címezése (átmeneti kapcsolat az útválasztáshoz) A Cisco kijelölt megosztott címterületből rendel hozzá (nem nyilvánosan útválasztható)
-
Alagút szállítási igénybevételi címe (Cisco oldala)
-
Privát autonóm rendszerszámok (ASN) az ügyfél BGP útválasztási konfigurációjához
-
A Cisco a kijelölt magánhasználati tartományból rendeli: 64512—65534
-
-
-
Az eBGP a dedikált példány és a CPE közötti útvonalak cseréjére szolgál
-
A Cisco a hozzárendelt /24 hálózatot 2 /25 egyre osztja az adott régió minden egyes DC-jére
-
A Virtual Connect alkalmazásban minden /25 hálózatot a Cisco a CPE-hez hirdeti vissza a megfelelő pont—pont VPN-alagutakon keresztül (átmeneti kapcsolat)
-
A CPE-t a megfelelő eBGP szomszédokkal kell konfigurálni. Ha egy CPE használ, két eBGP szomszédot fogunk használni, egyikük minden távoli alagútra mutat. Ha két CPE-t használ, akkor minden CPE-nek egy eBGP szomszédja lesz, amely a CPE egyetlen távoli alagútjához vezet.
-
Minden GRE alagút Cisco oldala (alagút interfész IP) a CPE BGP szomszédjaként van konfigurálva
-
A CPE szükséges az alapértelmezett útvonalat hirdetéséhez az egyes alagutak felett
-
A CPE válaszolható a megtanult útvonalak igény szerint újraelosztására a vásárló vállalati hálózatán belül.
-
-
Nem hibás kapcsolat meghibásodása esetén egyetlen CPE két aktív/aktív alagúttal rendelkezik. Két CPE csomópont esetében minden CPE egy aktív alagúttal rendelkezik, és mindkét CPE csomópontnak aktívnak és áthaladó forgalomnak kell lennie. Nem meghibásodott forgatókönyv esetén a forgalmat két alagútba kell osztani, amelyek a helyes /25 úti cél felé haladnak, ha az egyik alagút leesik, a fennmaradó alagút mindkettő számára képes szállítani a forgalmat. Ilyen hibaforgatókönyv esetén, ha a /25 hálózat leáll, akkor a /24 hálózat használható biztonsági mentési útvonalként. A Cisco a belső WAN-on keresztül az ügyfélforgalmat továbbítja a DC felé, amely elvesztette a kapcsolatot.
Virtuális csatlakozási forgalom
A forgalom áramlása, ha mindkét alagút felfelé van
Ez a kép egy Virtual Connect hálózati architektúrát szemlélteti, amely részletezi a forgalmi áramlást, amikor mind az elsődleges, mind a másodlagos alagutak működnek.
Aktív csatlakozási modellt jelent az ügyfél számára a Cisco adatközpontjaiban tárolt UC alkalmazásokhoz való hozzáféréshez, és a kettős GRE/IPSEC alagutat használ ki az internet en keresztül a BGP-vel az útvonalcserére.
Fogalommeghatározások:
- Ügyfél helyisé ge:
- Ez az ügyfél helyszíni hálózatát képviseli, ahol a felhasználók és eszközei (pl. IP-telefonok, UC-klienseket futtató számítógépek) találhatók.
- Az innen induló forgalomnak el kell érnie a Cisco adatközpontjaiban tárolt UC alkalmazá sokhoz.
- Cisco Webex CallingD@@ edikált példány (dedikált példány) adatközpontok (WXC-Di
DC-A és WXC-Di D C-B):
- Ezek a Cisco adatközpontjai, amelyek az UC alkalmazásokat tárolják.
- A DC-A és a DC-B földrajzilag különböznek egymástól, redundanciát biztosítva.
- Minden adatközpontnak saját alhálózata van az UC alkalmazásokhoz:
- DC-A alhálózat: X.X.X.0/25
- DC-B alhálózat: X.X.X.128/25
- GRE/IPsec alagutak (1. és 2. alagút):
- Ezek a biztonságos, titkosított kapcsolatok az ügyfélszolgálat és a Cisco adatközpont között a nyilvános interneten keresztül.
- GRE (Általános Routing Encapsulation): Ez a protokoll különféle hálózati réteg-protokollok beágyazására szolgál virtuális pont—pont kapcsolatokon belül. Lehetővé teszi az olyan útválasztási protokollok működését, mint a BGP, az alagút felett.
- IPsec (Internet Protocol Security): Ez a protokoll csomag kriptográfiai biztonsági szolgáltatásokat nyújt (hitelesítés, integritás, titoktartás) az IP-kommunikációhoz. Titkosítja a GRE-kapszulált forgalmat, biztosítva a biztonságos adat átvitelt az interneten keresztül.
- Határátjáró protokoll (BGP):
- A BGP az útválasztási protokoll, amelyet az ügyfélszolgálat és a Cisco adatközpontok közötti útválasz tási információk cseréj ére használnak.
Amint az a fenti ábrán látható, az ügyfél telephelyén telepített eszközöknek két GRE/IPSEC alagutat kell létrehozniuk.
A XX/ YY, DC-A DC-B esetében az alábbiakban használt elnevezési konvenciók általánosak minden olyan régióra vonatkozóan, ahol a dedikált példányt kínálják . Ezek az értékek minden régió esetében egyediek lesznek, és az egyes régiók tényleges értékei. A konkrét értékek a virtuális kapcsolat aktiválása során kerülnek megadásra.
A Cisco oldalon az IPsec és a GRE alagutak különböző eszközökön megszűnnek. Tehát az ügyfélnek meg kell győződnie arról, hogy ennek megfelelően konfigurálja az IPsec cél- és GRE célIP-címeket az eszközökön. Az ügyfelek ugyanazt az IP-címet használhatják a GRE és az IPSEC számára, ha az eszköz ükön támogatott. Lásd a fenti ábrát. Az IP-hez kapcsolódó értékek a portálon történő virtuális kapcsolat aktiválásakor kerülnek megadásra.
- 1. alagút: Az ügyfél helyiségét az interneten keresztül összekapcsolja a „Dedicated Instance DC-A” -hoz (Data Center A). Ez az alagút az ügyfél oldalán a BGP AS:64XX1, a DC-A dedikált példány pedig a BGP AS: 64XX2 értéket használ. Az IPSEC és a GRE alagútforrás-konfigurációk az ügyfél által biztosított és a Cisco által biztosított részletek között vannak felosztva.
- 2. alagút: Az ügyfél helyiségét az interneten keresztül összekapcsolja a „DC-B dedikált példányhoz” ( B adatközpont). Ez az alagút az ügyfél oldalon a BGP AS:64YY1, a DC-B dedikált példány pedig a BGP AS: 64YY2 értéket használ. Az 1. alagúthoz hasonlóan az IPSEC és a GRE alagútforrá s-konfigurációk megoszthatók az ügyfél és a Cisco között.
A BGP AS:64XX és BGP AS:64YY, XX és YY specifikusak egy adott régióra.
Miután a GRE/IPSEC alagutakat létrehozták a Webex Calling dedikált példányú adatközpontokhoz (A és B), az ügyfélnek a következő útvonalakat kell megkapnia a Cisco-tól a megfelelő BGP-munkamenetek során.
- DC-A esetében: A Cisco által hirdetett útvonalak X.X.X.0/25 és X.X.X.0/24 lesznek. Opcionálisan, ha az IaaS kérelme és konfigurálva van az ügyfélútvonalakhoz, a Y.Y.0/25 és Y.Y.0/24 a Cisco hirdetésre kerül.
- DC-B esetében: A Cisco által hirdetett útvonalak X.X.X.128/25 és X.X.X.0/24 lesznek. Opcionálisan, ha az IaaS-t az ügyfélútvonalakhoz kérik és konfigurálják, a Y.Y.Y.128/25 és Y.Y.0/24 a Cisco hirdetésre kerül.
- Az ügyfélnek hirdetnie kell a Cisco 0.0.0./0 útvonalát mindkét csatlakozón keresztül (alagutakon)
- Az ügyfélnek a leghosszabb előtagú (/25) útvonalat kell követnie, hogy a forgalmat a Cisco felé továbbítsa a megfelelő alagutakon keresztül, amikor mindkét alagút fel van kapcsolva.
- A Cisco ugyanazon alagutakon keresztül visszaadja a forgalmat, hogy a forgalom szimmetrikus maradjon.
Forgalmi áramlás:
- A „DC-A UC Apps” (X.X.X.0/25) számára szánt forgalom a vevőhelyiségből az 1-es alagúton halad át.
- A „DC-B UC Apps” (X.X.X.128/25) számára szánt forgalom az ügyfél telephelyéről a 2. alagúton keresztül folyik.
Hibásodási forgatókönyv: a forgalom áramlása, amikor az egyik alagút leáll
Amint azt a fenti ábra mutatja, amikor a DC-A-ba vezető alagút lefelé halad, az alag úton keresztül a DC-A-ig kialakított bgp leesik.
Hatása a BGP- re: Amikor az 1. alagút leesik, az alagút feletti BGP munkamenet is leesik . Következésképpen a DC-A ezen az útvonalon keresztül már nem tudja hirdetni útvonalait (különösen az X.X.X.0/25) az ügyfélnek. Ezért az ügyfélútválasztó elérhetetlennek fogja érzékelni az útv onalat.
Mivel az 1. alagút nem működik, a vevőhelyiségben lévő ügyfélútválasztó automatikusan eltávolítja az 1-es alagúton keresztül megtanult útvonalakat az útválasztási táblázatából, vagy elérhetetlennek jelöli őket.
- Az UC App Network (X.X.X.0/24) vagy a DC-A alhálózatra (X.X.X.0/25) szánt forgalom ezután átirányítjuk a működő alagúton keresztül a DC-B felé, amely továbbra is reklámozza az X.X.X.0/24 hálózatot, amely magában foglalja az X.X.X.0/25 hálózatot.
- Hasonló viselkedés tapasztalható, ha a DC-B alagút le van, míg a DC-A alagút még fent van.
Csatlakozási folyamat
| 1 | |
| 2 | |
| 3 | |
| 4 |
1. lépés: CCW megrendelés
A Virtual Connect a CCW dedikált példányának bővítménye.
| 1 |
Keresse meg a CCW rendelési webhelyét, majd kattintson a Bejelentkezés gombra a webhelyre való bejelentkezéshez: |
| 2 |
Hozzon létre becslést. |
| 3 |
Adja hozzá az „A-FLEX-3" SKU. |
| 4 |
Válassza a Szerkesztési beállítások lehetőséget. |
| 5 |
A megjelenő előfizetés lapon válassza a Beállítások és kiegészítők lehetőséget. |
| 6 |
A További kiegészítők területen jelölje be a „Virtuális kapcsolat dedikált példányhoz” melletti jelölőnégyzetet. A SKU neve „A-FLEX-DI-VC”. |
| 7 |
Adja meg azon régiók számát és számát, amelyekben a Virtual Connect szükséges. A Virtual Connect mennyisége nem haladhatja meg a Dedikált példányhoz vásárolt régiók teljes számát. Ezenkívül régiónként csak egy Virtual Connect megrendelés engedélyezett. |
| 8 |
Ha elégedett a kiválasztásokkal, kattintson az Ellenőrzés és Mentés gombra az oldal jobb felső részén. |
| 9 |
A megrendelés véglegesítéséhez kattintson a Mentés és a Folytatás gombra. A véglegesített megrendelés most megjelenik a megrendelési rácsban. |
2. lépés: A virtuális kapcsolat aktiválása a Control Hubban
| 1 |
Jelentkezzen be a Control Hub https://admin.webex.com/login oldalra. |
| 2 |
A Szolgáltatások szakasz ban keresse meg a Hívás > Dedikált Instacnce > Cloud Connectivity menüpontot. |
| 3 |
A Virtual Connect kártyán a megvásárolt Virtual Connect mennyiség szerepel. A rendszergazda mostantól rákattinthat az Aktiválás gombra a Virtual Connect aktiválásának elindításához. 
Az aktiválási folyamatot csak az „Customer Full admin” szerepkörrel rendelkező rendszergazdák indíthatják el. Míg a „Ügyfél csak olvasható adminisztrátor” szerepkörrel rendelkező rendszergazda csak az állapotot tekintheti meg. |
| 4 |
Az Ak tiválás gombra kattintva megjelenik a Virtuális kapcsolat aktiv álása űrlap, amelyben a rendszergazda megadja a Cisco oldalán lévő peering konfigurációhoz szükséges virtuális kapcsolat műszaki adatait. Az űrlap statikus információkat is tartalmaz a Cisco oldaláról, a kiválasztott régió alapján. Ezek az információk hasznosak lesznek az Ügyféladminisztrátorok számára, hogy konfigurálják a CPE-t az oldalukon a Kapcsolat létrehozásához. |
| 5 |
Kattintson az Aktiválás gombra, miután kitöltötték az összes kötelező mezőt. |
| 6 |
Miután kitöltötték a Virtuális kapcsolat aktiválási űrlapját egy bizonyos régióban, az ügyfél exportálhatja az aktiválási űrlapot a Vezérlőközpontból, Hívás > Dedikált példány > Felhőkapcsolat fülről, majd kattintson a Beállítások exportálása elemre. 
Biztonsági okokból a Hitelesítés és a BGP-jelszó nem lesz elérhető az Exportált dokumentumban, de a rendszergazda ugyanezt megtekintheti a Vezérlőközpontban, a Vezérlőközpont, Hívás > Dedikált példány > Felhőkapcsolat lap Nézet beállítások elemre kattintva. |
3. lépés: A Cisco végrehajtja a hálózati konfigurációt
| 1 |
A Virtual Connect aktiválási űrlap kitöltése után az állapot a Hívás > Dedikált példány > Cloud Connectivity Virtual Connect kártya menüpontban folyamatban lévő aktiv álás menüpontra frissül. |
| 2 |
A Cisco 5 munkanapon belül elvégzi a szükséges konfigurációkat a Cisco oldalsó berendezésein. Sikeres befejezés után az állapot az adott régió „Aktivált” értékre frissül a Control Hub alkalmazásban. |
4. lépés: Az ügyfél végrehajtja a hálózati konfigurációt
|
Az állapot „Aktivált” -ra változik, hogy értesítse az Ügyfél adminisztrátorát arról, hogy a Cisco IP VPN-kapcsolat konfigurációi az Ügyfél által biztosított bemenetek alapján teljesültek. De, az ügyfélrendszergazdától várhatóan befejeznie a CPE-k konfigurációinak oldalát, és tesztelnie kell a Virtual Connect alagút online csatlakozási útvonalait. Ha bármilyen probléma merül fel a konfiguráció vagy a kapcsolat során, az ügyfél segítség Cisco TAC ért fordulhat. |
Hibaelhárítás
IPsec első fázis (IKEv2 tárgyalás) Hibaelhárítás és érvényesítés
Az IPsec alagút tárgyalása két fázisból áll, az IKEv2 fázisból és az IPsec fázisból. Ha az IKEv2 fázisú tárgyalás nem fejeződik be, akkor nincs második IPsec szakasz kezdeményezése. Először adja ki a „show crypto ikev2 sa” parancsot (Cisco eszközön) vagy hasonló parancsot a harmadik féltől származó berendezéseken annak ellenőrzéséhez, hogy az IKEv2 munkamenet aktív-e. Ha az IKEv2 munkamenet nem aktív, a lehetséges okok lehetnek:
-
Az érdekes forgalom nem indítja el az IPsec alagutat.
-
Az IPsec alagút-hozzáférési lista helytelenül van konfigurálva.
-
Nincs kapcsolat az ügyfél és a Dedicated Instance IPsec alagút végpont IP-je között.
-
Az IKEv2 munkamenet paraméterei nem egyeznek meg a Dedikált példány oldal és az ügyféloldal között.
-
A tűzfal blokkolja az IKEv2 UDP csomagokat.
Először ellenőrizze az IPsec naplóit, hogy nincs-e olyan üzenetek, amelyek az IKEv2 alagút-tárgyalások előrehaladását mutatják. A naplók jelezhetik, hogy hol van probléma az IKEv2 tárgyalással kapcsolatban. A naplózási üzenetek hiánya azt is jelezheti, hogy az IKEv2 munkamenet nincs aktiválva.
Az IKEv2 tárgyalások néhány gyakori hibája a következő:
-
A CPE oldalon található IKEv2 beállításai nem egyeznek meg a Cisco oldalával, ellenőrizze újra az említett beállításokat:
-
Ellenőrizze, hogy az IKE verzió 2-es verzió-e.
-
Ellenőrizze, hogy a Titkosítási és Hitelesítési paraméterek megfelelnek-e a Dedikált példány oldalon a várt
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-re állítja.
-
Ellenőrizze az élettartam beállítását.
-
Ellenőrizze a Diffie Hellman moduluscsoportot.
-
Ellenőrizze a Pseudo Random Function beállításait.
-
-
A kriptográfiai térkép hozzáférési listája nincs beállítva:
-
Engedélyezés GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255" (vagy azzal egyenértékű parancs)
A hozzáférési listának kifejezetten a „GRE” protokollhoz kell lennie, és az „IP” protokoll nem fog működni.
-
Ha a naplóüzenetek nem mutatnak tárgyalási tevékenységet az IKEv2 fázisra vonatkozóan, akkor szükség lehet csomagrögzítésre.
Előfordulhat, hogy a dedikált példány oldal nem mindig kezdi meg az IKEv2 cserét, és néha arra számíthat, hogy az ügyfél CPE oldala lesz a kezdeményező.
Ellenőrizze az IKEv2 munkamenet kezdeményezésének következő előfeltételeit a CPE oldalkonfigurációjában:
-
Ellenőrizze az IPsec kriptohozzáférési listát a GRE forgalomhoz (50-es protokoll) a CPE alagút szállítási IP-jétől a Dedicated Instance alagút szállítási IP-jéig.
-
Győződjön meg arról, hogy a GRE alagút interfész engedélyezve van-e a GRE keepalives alkalmazásokhoz. Ha a berendezés nem támogatja a GRE keepalive-okat, akkor a Cisco értesítést kap, mert a GRE keepalives engedélyezve lesz a Dedikált példány oldalon alapértelmezés szerint.
-
Győződjön meg arról, hogy a BGP engedélyezve van és konfigurálva van-e a Dedikált példányalagút IP-címével.
Megfelelő konfigurálás esetén a következőkkel kezdődik az IPsec alagút és az első fázisú IKEv2 tárgyalás:
-
A GRE a CPE oldali GRE alagút interfészről a dedikált példány oldali GRE alagút interfészig tart.
-
BGP szomszédos TCP munkamenet a CPE oldali BGP szomszédtól a dedikált példány oldali BGP szomszédjáig.
-
Ping a CPE oldalsó alagút IP-címéről a Dedicated Instance oldalsó alagút IP-címére.
A Ping nem lehet az alagút szállítási IP-je az alagút szállítási IP-jéig, hanem alagút IP-jének kell lennie az alagút IP-jéig.
Ha az IKEv2 forgalomhoz csomagkövetésre van szükség, állítsa be a szűrőt az UDP-hez, illetve az 500-as porthoz (ha az IPsec végpontok közepén nincs NAT-eszköz) vagy a 4500 portot (ha NAT-eszköz van behelyezve az IPsec végpontok közepére).
Ellenőrizze, hogy az 500 vagy 4500 porttal rendelkező IKEv2 UDP csomagok küldjenek-e és fogadják-e a DI IPsec IP-címre és onnan.
Előfordulhat, hogy a Dedikált példány adatközpont nem mindig indítja el az első IKEv2 csomagot. A követelmény az, hogy a CPE eszköz képes legyen az első IKEv2 csomag elindítására a dedikált példány oldal felé.
Ha a helyi tűzfal engedélyezi, akkor próbáljon meg pingelni a távoli IPsec címre is. Ha a ping nem sikerül a helyi IP-címről távoli IPsec címre, végezzen nyomon követési útvonalat a segítségnyújtáshoz, és határozza meg, hol dobja el a csomag.
Előfordulhat, hogy egyes tűzfalak és internetes berendezések nem teszik lehetővé a nyomkövetési útvonalat.
IPsec második fázis (IPsec tárgyalás) Hibaelhárítás és érvényesítés
Az IPsec második fázisának hibaelhárítása előtt ellenőrizze, hogy az IPsec első fázisa (azaz IKEv2 biztonsági társítás) aktív-e. Végezzen el egy „show crypto ikev2 sa” vagy azzal egyenértékű parancsot az IKEv2 munkamenet ellenőrzéséhez. A kimeneten ellenőrizze, hogy az IKEv2 munkamenet több mint néhány másodpercig leáll-e, és nem pattan-e. A munkamenet üzemideje a kimeneten „Aktív idő” vagy azzal egyenértékű munkamenetként jelenik meg.
Miután az IKEv2 munkamenet beindult és aktív állapotban van, vizsgálja meg az IPsec munkamenetet. Az IKEv2 munkamenethez hasonlóan hajtson végre egy „show crypto ipsec sa” vagy azzal egyenértékű parancsot az IPsec munkamenet ellenőrzéséhez. Mind az IKEv2 munkamenetnek, mind az IPsec munkamenetnek aktívnak kell lennie a GRE alagút létrehozása előtt. Ha az IPsec munkamenet nem jelenik meg aktívnak, ellenőrizze, hogy az IPsec naplókban nincs-e hibaüzenetek vagy tárgyalási hibák.
Az IPsec tárgyalások során felmerülő gyakoribb problémák közül néhány a következő:
A CPE oldalon található beállítások nem egyeznek meg a Dedikált példány oldalával, ellenőrizze újra a beállításokat:
-
Ellenőrizze, hogy a Titkosítási és hitelesítési paraméterek megfelelnek-e a Dedikált példány oldalon található beállí
-
Ellenőrizze a Tökéletes továbbítási titkosság beállításait és a Dedikált példány oldalon található beállítások megegyezését.
-
Ellenőrizze az élettartam beállításait.
-
Ellenőrizze, hogy az IPsec konfigurálva van-e alagút módban.
-
Ellenőrizze a forrás- és célcímeket az IPsec címeket.
Alagútfelület hibaelhárítása és ellenőrzése
Amikor az IPsec és az IKEv2 munkamenetek aktiváltságának ellenőrzése alatt áll, a GRE alagút megőrzi a csomagokat a Dedikált példány és a CPE alagút végpontjai között. Ha az alagút felülete nem jelenik meg állapota, néhány gyakori probléma a következő:
-
Az alagút interfész szállító VRF nem egyezik meg a visszacsatoló interfész VRF-jével (ha az alagút interfészen VRF konfigurációt használnak).
Ha a VRF konfigurációt nem használja az alagút felületén, ezt az ellenőrzést figyelmen kívül lehet hagyni.
-
A CPE oldalsó alagút felületén nincs engedélyezve a Keepalive-ok
Ha a CPE berendezés nem támogatja a keepalive-okat, akkor a Cisco-t értesíteni kell, hogy a Dedikált példány oldalon található alapértelmezett emlékeztetők is le legyenek tiltva.
Ha a keepalives támogatottak, ellenőrizze, hogy a keepalives engedélyezve vannak-e.
-
Az alagút interfész maszkja vagy IP-címe nem megfelelő, és nem felel meg a Dedikált példány várt értékeinek.
-
A forrás- vagy célalagút szállítási címe nem helyes, és nem felel meg a Dedikált példány várható értékeinek.
-
A tűzfal blokkolja a GRE csomagok küldését az IPsec alagútba vagy az IPsec alagútból történő fogadását (a GRE alagút az IPsec alagúton keresztül kerül szállításra)
A ping tesztnek ellenőriznie kell, hogy a helyi alagút interfész be van-e kapcsolva, és a kapcsolat jó-e a távoli alagút interfészhez. Végezze el a ping ellenőrzést az alagút IP-jéről (nem a szállítási IP-ről) a távoli alagút IP-jéig.
A GRE alagút forgalmát hordozó IPsec alagút kriptohozzáférési listája csak a GRE csomagok keresztezését teszi lehetővé. Ennek eredményeként a pingek nem fognak működni az alagútszállítási IP-től a távoli alagútszállítási IP-ig.
A ping ellenőrzés eredményeként egy olyan GRE csomag jön létre, amelyet a forrásalagút szállítási IP-jéből a célalagút szállítási IP-jéig állítanak elő, míg a GRE csomag hasznos terhelése (a belső IP) lesz a forrás- és célalagút IP-je.
Ha a ping teszt nem sikeres, és az előző elemeket ellenőrzik, akkor csomagrögzítésre lehet szükség annak biztosításához, hogy az icmp ping egy GRE csomagot eredményez, amelyet ezután egy IPsec csomagba kapszulálnak, majd a forrás IPsec címből elküldik a célcímre. A GRE alagút interfészén található számlálók és az IPsec munkamenetszámlálók szintén segíthetnek megjeleníteni, ha a küldési és fogadó csomagok növekednek.
A ping forgalom mellett a rögzítésnek még üresjárati forgalom közben is meg kell mutatnia a keepalive GRE csomagokat. Végül, ha a BGP konfigurálva van, a BGP keepalive csomagokat GRE csomagokként is el kell küldeni IPSEC csomagokban, valamint a VPN-en keresztül.
BGP Hibaelhárítás és érvényesítés
BGP ülések
A BGP szükséges, mint útválasztási protokoll a VPN IPsec alagúton. A helyi BGP-szomszédnak eBGP munkamenetet kell létrehoznia a Dedicated Instance BGP szomszédjával. Az eBGP szomszédos IP-címek megegyeznek a helyi és távoli alagút IP-címével. Először győződjön meg arról, hogy a BGP-munkamenet lezárult, majd ellenőrizze, hogy a megfelelő útvonalak érkezik-e a Dedikált példányból, és a helyes alapértelmezett útvonalat elküldte-e a Dedikált példányba
Ha a GRE alagút fel van kapcsolva, ellenőrizze, hogy sikeres-e a ping a helyi és a távoli GRE alagút IP-címe között. Ha a ping sikeres, de a BGP-munkamenet nem jelenik meg, akkor vizsgálja meg a BGP-naplót a BGP-alapítási hibák szempontjából.
Néhány gyakoribb BGP tárgyalási kérdés a következő:
-
A távoli AS-szám nem egyezik meg a Dedikált példány oldalon konfigurált AS-számmal, ellenőrizze újra a szomszédos AS-konfigurációt.
-
A helyi AS-szám nem egyezik meg azzal, amit a Dedictaed példány oldal várt, ellenőrizze, hogy a helyi AS-szám megfelel-e a várt Dedikált példányparamétereknek.
-
A tűzfal megakadályozza a GRE csomagokban beágyazott BGP TCP csomagok küldését az IPsec alagútba vagy az IPSEC alagútból történő fogadását
-
A távoli BGP szomszéd IP-je nem egyezik a távoli GRE alagút IP-jével.
BGP útvonalcsere
Miután a BGP munkamenetet mindkét alagútnál ellenőrizték, győződjön meg arról, hogy a megfelelő útvonalak küldjenek és fogadják-e a Dedikált példány oldalról.
A Dedicated Instance VPN megoldás két alagút létrehozását várja az ügyfél/partner oldalról. Az első alagút az A dedikált példány adatközpontra mutat, a második alagút pedig a B dedikált példány adatközpontra mutat. Mindkét alagútnak aktív állapotban kell lennie, és a megoldás aktív/aktív telepítést igényel. Minden dedikált példányú adatközpont hirdetni fogja a helyi /25 útvonalát, valamint egy /24 mentési útvonalat. A Dedikált példányból bejövő BGP-útvonalak ellenőrzésekor győződjön meg arról, hogy a Dedikált példány adatközpontra mutató alagúthoz társított BGP-munkamenet megkapja a Dedikált példány A/25 helyi útvonalat, valamint a /24 biztonsági mentési útvonalat. Ezenkívül győződjön meg arról, hogy a B dedikált példány adatközpontra mutató alagút megkapja a Dedikált példány adatközpont B /25 helyi útvonalát, valamint a /24 mentési útvonalat. Ne feledje, hogy a /24 biztonsági mentési útvonal ugyanaz az útvonal lesz, amelyet a dedikált példány adatközpontban hirdettek az A és a B dedikált példány adatközpontban.
A redundanciát egy dedikált példányú adatközpont biztosítja, ha az adott adatközpont alagútfelülete leáll. Ha az A dedikált példányú adatközponttal való kapcsolat megszűnik, akkor a forgalom továbbításra kerül a B dedikált példány adatközpontból az A adatközpontba. Ebben a forgatókönyvben a B adatközpontba vezető alagút a B /25 adatközpont útvonalát használja a forgalom B adatközpontba történő elküldéséhez, a B adatközponthoz tartozó alagút pedig a biztonsági mentési /24 útvonalat használja a forgalmat az A adatközpontba a B adatközpontba történő továbbítására.
Fontos, hogy ha mindkét alagút aktív, az A adatközpont alagútját ne használják a B adatközpontba történő forgalom küldésére, és fordítva. Ebben a forgatókönyvben, ha a forgalmat az A adatközpontba küldik, amelynek célja a B adatközpont, az A adatközpont továbbítja a forgalmat a B adatközpontba, majd a B adatközpont megpróbálja visszaküldeni a forgalmat a forráshoz a B adatközpont alagútján keresztül. Ez nem optimális útválasztást eredményez, és megszakíthatja a forgalmat áthaladó tűzfalakat is. Ezért fontos, hogy mindkét alagút aktív/aktív konfigurációban legyen normál működés közben.
A 0.0.0.0/0 útvonalat az ügyfél oldaláról a Dedicated Instance adatközpont oldalára kell hirdetni. A konkrétabb útvonalakat a Dedikált példány oldal nem fogad el. Győződjön meg arról, hogy a 0.0.0.0/0 útvonalat mind a dedikált példány adatközpont A alagútján, mind a dedikált példányú adatközpont B alagútján kívül hirdetik.
MTU konfiguráció
A Dedikált példány oldalon két funkció engedélyezve van az MTU dinamikusan beállításához nagy csomagméretekhez. A GRE alagút további fejléceket ad hozzá a VPN munkameneten keresztül áramló IP-csomagokhoz. Az IPsec alagút hozzáadja a további fejléceket a GRE fejlécek tetejére, tovább csökkenti az alagút felett megengedett legnagyobb MTU-t.
A GRE alagút beállítja az MSS funkciót, és a GRE alagút útja az MTU felderítési funkcióban engedélyezve van a Dedikált példány oldalon. Konfigurálja az „ip tcp ajust-mss 1350" vagy azzal egyenértékű parancsot, valamint az „tunnel path\ u0002mtu-Discovery” vagy azzal egyenértékű parancsot az ügyfél oldalon, hogy segítse a VPN-alagúton keresztüli forgalom MTU dinamikus beállítását.
