Bevezetés

A Virtual Connect egy kiegészítő bővítmény a Cloud Connectivity to Dedikált példányhoz a Webex Calling (dedikált példány) számára. A Virtual Connect lehetővé teszi az ügyfelek számára, hogy biztonságosan kiterjesszék privát hálózatukat az interneten keresztül, pont-pont IP VPN -alagutak segítségével. Ez a kapcsolódási lehetőség gyors magánhálózati kapcsolat létrehozását teszi lehetővé a meglévő Customer Premise Equipment (CPE) és internetkapcsolat használatával.

A redundáns IP VPN alagutakat és a szükséges internet-hozzáférést a Cisco üzemelteti, kezeli és biztosítja a Cisco dedikált példány adatközponti régiójában, ahol a szolgáltatásra szükség van. Ehhez hasonlóan a rendszergazda felelős a hozzájuk tartozó CPE és internetes szolgáltatásokért, amelyek a Virtuális kapcsolat létrehozásához szükségesek.

Egy adott dedikált példány-régióban minden egyes Virtual Connect-rendelés két IPSec -titkosítással (GRE over IPSec) védett általános útválasztási beágyazó (GRE) alagutat tartalmazna, egyet a kiválasztott Régióban lévő Cisco adatközpontjaihoz.

A Virtual Connect sávszélességi korlátja alagútonként 250 Mbps, és kisebb telepítésekhez ajánlott. Mivel két pont-pont VPN alagutat használnak, a felhő felé irányuló összes forgalomnak az ügyfél fejállomási CPE-n keresztül kell haladnia, ezért előfordulhat, hogy nem megfelelő ott, ahol sok a távoli hely. Az egyéb alternatív társ-létesítési lehetőségekről lásd: Felhőkapcsolat .


 

Mielőtt elküldi a virtuális kapcsolat társviszony-létesítési kérelmét, győződjön meg arról, hogy a dedikált példány szolgáltatás aktiválva van az adott régióban.

Előfeltételek

A Virtuális kapcsolat 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éloldali GRE szállítási IP -címek a két GRE alagúthoz

  • Partner és Ügyfél

    • Dolgozzon együtt a sávszélesség-szükségletek felmérésén

    • Gondoskodjon arról, hogy a hálózati eszköz(ek) támogassák a Border Gateway Protocol (BGP) útválasztást és a GRE over IPSec alagút kialakítását

  • Partner vagy Ügyfél biztosítja

    • A helyek közötti VPN alagút technológiákat ismerő hálózati csapat

    • A BGP, eBGP és általános útválasztási elvek ismeretében dolgozó hálózati csapat

  • Cisco

    • A Cisco privát autonóm rendszerszámokat (ASN) és tranziens IP -címeket rendelt a GRE alagútinterfészekhez

    • A Cisco nyilvános, de nem interneten átirányítható C osztályú (/24) hálózatot rendelt a dedikált példányfelhő-címzéshez


 

Ha egy ügyfél csak 1 CPE-eszközzel rendelkezik, akkor az egyes régiókban a Cisco adatközpontjai felé vezető 2 alagút (DC1 és DC2) az adott CPE-eszköztől lesz. Az ügyfélnek 2 CPE eszközre is van lehetősége, ekkor minden CPE eszköz csak 1 alagúthoz csatlakozzon a Cisco Datacenterek (DC1 és DC2) felé minden régióban. További redundancia érhető el, ha az egyes alagutakat az Ügyfél infrastruktúráján belül külön fizikai helyszínen/helyszínen zárják le.

Műszaki adatok

Telepítési modell

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.

Hívásátirányítás

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é.

Kapcsolódási folyamat

A következő magas szintű lépések ismertetik, hogyan lehet kapcsolatot létesíteni a virtuális Connect for Dedicated Instance alkalmazással.
1

Adjon le megrendelést a Cisco CCW-n

2

Aktiválja a Virtuális kapcsolatot a Control Hubról

3

A Cisco elvégzi a hálózati konfigurációt

4

Az Ügyfél elvégzi a Hálózati konfigurációt

1. lépés: CCW-megrendelés

A Virtual Connect egy bővítmény a CCW dedikált példányaihoz.

1

Keresse meg a CCW rendelési oldalt, majd kattintson a Bejelentkezés gombra az oldalra való bejelentkezéshez:

2

Becslés létrehozása.

3

Adja hozzá az „A-FLEX-3” cikkszámot.

4

Válassza a Beállítások szerkesztése lehetőséget.

5

A megjelenő előfizetés lapon válassza a Beállítások és a kiegészítők lehetőséget.

6

A További bővítmények területen jelölje be a „Virtuális kapcsolat dedikált példányhoz” jelölőnégyzet . Az SKU neve „A-FLEX-DI-VC”.

7

Adja meg azoknak a régióknak a mennyiségét és számát, ahol szükséges a Virtuális kapcsolat.


 
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 Virtuális kapcsolat-rendelés engedélyezett.
8

Ha elégedett a választásával, kattintson az Ellenőrzés és Mentés lehetőségre az oldal jobb felső sarkában.

9

Kattintson a Mentés és folytatás gombra a megrendelés véglegesítéséhez. A véglegesített megrendelése mostantól megjelenik a rendelésrácsban.

2. lépés: A Virtuális kapcsolat aktiválása a Control Hubban

1

Jelentkezzen be a Control Hub rendszerébe https://admin.webex.com/login .

2

A Szolgáltatások lehetőségre szakaszhoz navigáljon Hívás > Dedikált példány > Felhőkapcsolat .

3

A Virtual Connect kártyán a vásárolt Virtuális kapcsolat mennyiség szerepel. A rendszergazda most rákattinthat Aktiválás hogy kezdeményezze a Virtuális kapcsolat aktiválását.


 
Az aktiválási folyamatot csak „Teljes ügyfél adminisztrátori” szerepkörrel rendelkező rendszergazdák indíthatják el. Míg az „Ügyfél csak olvasási rendszergazda” szerepkörrel rendelkező rendszergazda csak az állapotot tekintheti meg.
4

Ha rákattint a Aktiválás gomb, Virtuális kapcsolat aktiválása Az űrlap jelenik meg a rendszergazda számára, hogy megadja a virtuális kapcsolat műszaki adatait, amelyek a Cisco oldalán lévő peering konfigurációkhoz szükségesek.


 
Az űrlap statikus információkat is közöl a Cisco oldalán, a kiválasztott Régió alapján. Ezek az információk hasznosak lesznek az Ügyfél rendszergazdái számára a CPE konfigurálásához az oldalukon a kapcsolat létrehozása érdekében.
  1. GRE Tunnel Transport IP-cím : Az ügyfélnek meg kell adnia az ügyféloldali Tunnel Transport IP -címeket, és a Cisco dinamikusan kiosztja az IP -címeket az aktiválás befejezése után. Az Interest Traffic IPSec ACL-nek engedélyeznie kell a /32 helyi alagúttovábbítási IP-címet a /32 távoli alagúttovábbítási IP-címbe. Az ACL-nek is csak a GRE IP protokollt kell megadnia.


     
    Az ügyfél által megadott IP-cím lehet privát vagy nyilvános.
  2. IPSec társak : Az ügyfélnek meg kell adnia az IPSec -alagút forrás IP -címét, és a Cisco kiosztja az IPSec célhelyszín IP-címe. Szükség esetén a belső IPSEC alagútcímek NAT-os fordítása is támogatott nyilvános címké.​


     

    Az ügyfél által megadott IP-cím nyilvánosnak kell lennie.


     
    Az aktiválási képernyőn megjelenő összes többi statikus információ a Cisco oldali biztonsági és titkosítási szabványaira vonatkozik. Ez a statikus konfiguráció nem testre szabható vagy módosítható. A Cisco oldalán lévő statikus konfigurációkkal kapcsolatos további segítségért az ügyfélnek fel kell vennie a kapcsolatot a TAC-vel.
5

Kattintson a lehetőségre Aktiválás gombra, miután az összes kötelező mezőt kitöltötte.

6

Miután egy adott régióra elkészült a Virtuális kapcsolat aktiválási űrlapja, az ügyfél exportálhatja az aktiválási űrlapot a Control Hub Hívás > Dedikált példánya > Felhőalapú kapcsolat lapon, majd rákattinthat a Beállítások exportálása lehetőségre.


 
Biztonsági okokból a hitelesítés és a BGP jelszó nem lesz elérhető az Exportált dokumentumban, de a rendszergazda megtekintheti azokat a Control Hubban, ha rákattint a Beállítások megtekintése a Control Hub, Hívás > Dedikált példány > Cloud Connectivity fülön.

3. lépés: A Cisco elvégzi a hálózati konfigurációt

1

A Virtuális kapcsolat aktiválási űrlapjának kitöltése után az állapot frissül a következőre: Aktiválás folyamatban a Hívás > Dedikált példány > Cloud Connectivity Virtual Connect kártyán.

2

A Cisco a szükséges konfigurációkat a Cisco oldalsó berendezésein belül végzi el 5 munkanap . Sikeres befejezés esetén az állapot „Aktivált” értékre frissül az adott régióra a Control Hubban.

4. lépés: Az Ügyfél elvégzi a Hálózati konfigurációt

Az állapot „Aktivált” értékre változik, hogy értesítse az Ügyfél adminisztrátorát arról, hogy az IP VPN -kapcsolat konfigurációinak Cisco oldala elkészült az Ügyfél által megadott adatok alapján. Az ügyfél rendszergazdájának azonban el kell végeznie a konfigurációt a CPE-ken, és tesztelnie kell a kapcsolati útvonalakat ahhoz, hogy a Virtuális kapcsolat alagút online legyen. A konfiguráció vagy a kapcsolódás során felmerülő problémák esetén az ügyfél a Cisco TAC -hoz fordulhat segítségért.

Hibaelhárítás

IPsec First Phase (IKEv2 Negotiation) hibaelhárítás és érvényesítés

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.

IPsec Second Phase (IPsec Negotiation) 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 (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.

Alagútinterfész hibaelhárítás és érvényesítés

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.

BGP hibaelhárítás és érvényesítés

BGP-foglalkozások

A BGP protokoll szükséges útválasztási protokollként a VPN IPsec alagúton keresztül. A helyi BGP-szomszédnak eBGP-munkamenetet kell létrehoznia a dedikált példány BGP-szomszédjával. Az eBGP szomszédos IP -címek megegyeznek a helyi és a távoli alagút IP -címekkel. Először győződjön meg arról, hogy a BGP-munkamenet működik, majd ellenőrizze, hogy a megfelelő útvonalak érkeztek-e a dedikált példányból, és a megfelelő alapértelmezett útvonalat küldték-e a dedikált példánynak.

Ha a GRE alagút működik, ellenőrizze, hogy a ping sikeres volt-e a helyi és a távoli GRE alagút IP-címe között. Ha a ping sikeres, de a BGP-munkamenet nem érkezik meg, akkor vizsgálja meg a BGP-naplót, hogy vannak-e BGP-létesítési hibák.

A BGP-egyeztetéssel kapcsolatos leggyakoribb problémák a következők:

  • 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 dedikált példány oldal vár. Ellenőrizze, hogy a helyi AS-szám megegyezik-e a várt dedikált példány paraméterekkel.

  • Egy tűzfal megakadályozza, hogy a GRE csomagokba burkolt BGP TCP -csomagok elküldésre kerüljenek az IPsec-alagútba vagy fogadhassanak az IPSEC-alagútból.

  • A távoli BGP szomszéd IP -címe nem egyezik meg a távoli GRE alagút IP-címével.

BGP Route Exchange

Miután ellenőrizte a BGP-munkamenetet mindkét alagút esetében, győződjön meg arról, hogy a megfelelő útvonalakat küldi és fogadja a dedikált példány oldalról.

A dedikált példány VPN -megoldás két alagút kialakítását várja az ügyfél/partner oldalról. Az első alagút az A dedikált példány adatközpontjára mutat, a második alagút a B dedikált példány adatközpontra. Mindkét alagútnak aktív állapotban kell lennie, és a megoldáshoz aktív/aktív központi telepítésre van szükség. Minden dedikált példány adatközpont meghirdeti a saját helyi /25 útvonalát, valamint egy /24 tartalék útvonalat. A dedikált példányból bejövő BGP-útvonalak ellenőrzésekor győződjön meg arról, hogy az A dedikált példány adatközpontjára mutató alagúthoz társított BGP-munkamenet kapja az A dedikált példány adatközpontjának /25 helyi útvonal , 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 fogadja a B dedikált példány adatközpontjának /25 helyi útvonal , valamint a /24 biztonsági mentési útvonalat. Ne feledje, hogy a /24 biztonsági mentési útvonal ugyanaz az útvonal lesz, mint az A dedikált példány adatközpontban és a B dedikált példány adatközpontjában meghirdetett útvonal.

A redundancia egy dedikált példány adatközpont számára biztosított, ha az adott adatközponthoz vezető alagútinterfész megszűnik. Ha megszakad a kapcsolat az A dedikált példány adatközpontjával, akkor a forgalom a B dedikált példány adatközpontjából az A adatközpontba kerül továbbításra. Ebben a forgatókönyvben a B dedikált példányhoz vezető alagút a B adatközpont /25 útvonalon továbbítja a forgalmat a B adatközpontba és az alagútba. A B adatközpontba a /24-es biztonsági mentési útvonalat használja a forgalom B adatközponton keresztül történő továbbítására az A adatközpontba.

Fontos, hogy amikor mindkét alagút aktív, akkor az A adatközpont alagút ne használja a forgalmat a B adatközpont felé és fordítva. Ebben a forgatókönyvben, ha a forgalmat az A adatközpontba küldik B adatközpont célállomással, az A adatközpont a B adatközpont felé továbbítja a forgalmat, majd a B adatközpont a B adatközpont alagútján keresztül kísérli meg visszaküldeni a forgalmat a forráshoz. Ez nem optimális útválasztást eredményez, és megszakíthatja a tűzfalakat áthaladó forgalmat. Ezért fontos, hogy mindkét alagút aktív/aktív konfigurációban legyen a normál működés során.

A 0.0.0.0/0 útvonalat az ügyféloldalról a dedikált példány adatközpont oldalára kell hirdetni. A konkrétabb útvonalakat a Dedikált példány oldal nem fogadja el. Gondoskodjon arról, hogy a 0.0.0.0/0 útvonal az A dedikált példány adatközpont alagútján és a B dedikált példány adatközpont alagútján kívül is legyen hirdetve.

MTU konfiguráció

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.