Uvod

Virtual Connect je dodatna dodatna možnost za povezljivost v oblaku z namensko različico za klicanje Webex (namenska različica). Virtual Connect strankam omogoča varno razširitev zasebnega omrežja prek interneta z uporabo tunelov IP VPN od točke do točke. Ta možnost povezovanja omogoča hitro vzpostavitev povezave zasebnega omrežja z uporabo obstoječe opreme za prostore stranke (CPE) in internetne povezljivosti.

Cisco gosti, upravlja in zagotavlja redundantne tunele IP VPN in potreben dostop do interneta v Ciscovem namenskem podatkovnem središču v regiji(-ah), kjer je storitev potrebna. Prav tako je skrbnik odgovoren za ustrezne CPE in internetne storitve, ki so potrebne za vzpostavitev virtualnega priključka.

Vsako naročilo za virtualni priključek v določeni regiji namenskih različic bo vključevalo dva generična usmerjevalna enkapsulacijska tunela (GRE), zaščitena s šifriranjem IPSec (GRE over IPSec), po enega v vsak Ciscov podatkovni center v izbrani regiji.

Virtual Connect ima omejitev pasovne širine 250 Mb/s na tunel in je priporočljiv za manjše namestitve. Ker se uporabljata dva tunela VPN od točke do točke, mora ves promet v oblak potekati prek glavnega CPE stranke, zato morda ni primeren, če je veliko oddaljenih lokacij. Za druge alternativne možnosti povezovanja glejte Povezljivost v oblaku.

Pred oddajo zahteve za enakovredno povezovanje za Virtual Connect se prepričajte, da je storitev Dedicated Instance aktivirana v zadevni regiji.

Predpogoji

Predpogoji za vzpostavitev povezave Virtual Connect vključujejo:

  • Stranka zagotovi

    • internetna povezava z zadostno razpoložljivo pasovno širino za podporo uvajanju.

    • Javni naslovi IP za dva tunela IPSec

    • naslovi IP za prenos GRE na strani stranke za dva tunela GRE

  • Partner in stranka

    • Sodelujte pri ocenjevanju zahtev glede pasovne širine.

    • Zagotovite, da omrežne naprave podpirajo usmerjanje s protokolom BGP (Border Gateway Protocol) in zasnovo predora GRE prek IPSec.

  • Partner ali stranka zagotavlja

    • Omrežna ekipa z znanjem o tehnologijah tunelov VPN od spletnega mesta do spletnega mesta

    • Omrežna ekipa z znanjem o BGP, eBGP in splošnih načelih usmerjanja

  • Cisco

    • Cisco je dodelil zasebne samodejne sistemske številke (ASN) in prehodno naslavljanje IP za vmesnike predora GRE

    • Cisco dodelil javno omrežje razreda C (/24), ki ga ni mogoče usmerjati prek interneta, za naslavljanje namenskih instanc v oblaku.

Če ima stranka samo eno napravo CPE, potem bosta 2 tunela proti Ciscovim podatkovnim centrom (DC1 in DC2) v vsaki regiji potekala iz te naprave CPE. Stranka ima na voljo tudi možnost za 2 napravi CPE, pri čemer se mora vsaka naprava CPE povezati samo z enim tunelom proti Ciscovim podatkovnim centrom (DC1 in DC2) v vsaki regiji. Dodatno redundanco je mogoče doseči tako, da se vsak predor zaključi na ločenem fizičnem mestu/lokaciji v infrastrukturi stranke.

Tehnične podrobnosti

Model uvajanja

Virtual Connect uporablja dvotirno arhitekturo glavnega mesta, pri čemer usmerjevalno in nadzorno ravnino GRE zagotavlja ena naprava, nadzorno ravnino IPSec pa druga.

Po dokončanju povezljivosti Virtual Connect bosta ustvarjena dva tunela GRE prek IPSec med naročnikovim podjetniškim omrežjem in podatkovnimi centri namenske različice Cisco. Po enega za vsak redundantni podatkovni center v zadevni regiji. Dodatne omrežne elemente, potrebne za povezovanje, partner ali stranka izmenja s Ciscom prek aktivacijskega obrazca Control Hub Virtual Connect.

Slika 1 prikazuje primer modela namestitve Virtual Connect za možnost z dvema koncentratorjema na strani stranke.

Virtual Connect - VPN je zasnova vozlišča, pri kateri so naročnikova vozlišča povezana z DC1 in DC2 podatkovnih centrov namenske različice v določeni regiji.

Zaradi boljše redundance sta priporočeni dve vozliščni lokaciji, vendar je podprt tudi model namestitve z eno vozliščno lokacijo z dvema tuneloma.

Pasovna širina na predor je omejena na 250 Mb/s.

Strankina oddaljena spletna mesta v isti regiji se morajo povezati nazaj v vozlišče prek strankinega omrežja WAN, Cisco pa za to povezljivost ni odgovoren.

Partnerji morajo tesno sodelovati s strankami in zagotoviti, da se za regijo storitev "Virtual Connect" izbere najbolj optimalna pot.

Na sliki 2 so prikazane regije povezovanja v oblaku z namenskimi instancami.

Usmerjanje

Usmerjanje za dodatek Virtual Connect se izvaja z uporabo zunanjega protokola BGP (eBGP) med namensko instanco in naročniško opremo (CPE). Cisco bo svoje omrežje za vsak redundantni DC v regiji oglaševal strankinemu CPE, CPE pa mora Ciscu oglaševati privzeto pot.

  • Cisco vzdržuje in dodeljuje

    • Naslavljanje IP vmesnika predora (prehodna povezava za usmerjanje) Cisco dodeljuje iz določenega skupnega naslovnega prostora (ni javno usmerljiv)

    • Naslov za destinacijo prenosa predora (Ciscova stran)

    • Zasebne številke avtonomnih sistemov (ASN) za konfiguracijo usmerjanja BGP za stranke

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

  • eBGP se uporablja za izmenjavo poti med namensko instanco in CPE

    • Cisco bo dodeljeno omrežje /24 razdelil na 2 /25, po enega za vsak DC v zadevni regiji.

    • V Virtual Connect Cisco vsako omrežje /25 oglašuje nazaj v CPE prek ustreznih tunelov VPN točka-točka (prehodna povezava).

    • CPE mora biti konfiguriran z ustreznimi sosedi eBGP. Če uporabljate en CPE, bosta uporabljena dva soseda eBGP, od katerih bo eden usmerjen na vsak oddaljeni predor. Če uporabljate dve napravi CPE, bo imela vsaka naprava CPE enega soseda eBGP, ki bo ponujal en sam oddaljeni predor za napravo CPE.

    • Cisco stran vsakega tunela GRE (vmesnik tunela IP) je konfigurirana kot sosed BGP na CPE.

    • CPE mora oglaševati privzeto pot v vsakem od tunelov.

    • CPE je odgovoren za prerazporeditev naučenih poti v omrežju podjetja uporabnika, če je to potrebno.

  • V stanju brez odpovedi povezave ima en CPE dva aktivna/aktivna tunela. Pri dveh vozliščih CPE ima vsako vozlišče CPE en aktiven predor, obe vozlišči CPE pa morata biti aktivni in prenašati promet. Po scenariju brez odpovedi se mora promet razdeliti v dva tunela, ki vodita do pravilnih destinacij /25. Če eden od tunelov odpove, lahko preostali tunel prenaša promet za oba. Če je omrežje /25 v okvari, se v takem scenariju okvare kot rezervna pot uporabi omrežje /24. Cisco bo poslal promet strank prek svojega notranjega omrežja WAN proti DC, ki je izgubil povezavo.

Postopek povezovanja

Naslednji koraki na visoki ravni opisujejo, kako vzpostaviti povezljivost z virtualnim programom Connect for Dedicated Instance.
1

Naročite v Cisco CCW

2

Aktivacija programa Virtual Connect iz nadzornega vozlišča

3

Cisco izvaja konfiguracijo omrežja

4

Stranka izvede konfiguracijo omrežja

1. korak: Naročilo CCW

Virtual Connect je dodatek za namenski strežnik v CCW.

1

Pojdite na spletno mesto za naročanje CCW in se s klikom na Prijava prijavite na spletno mesto:

https://apps.cisco.com/Commerce/guest.
2

Ustvarite oceno.

3

Dodajte "A-FLEX-3" SKU.

4

Izberite Uredi možnosti.

5

V prikazanem zavihku naročnine izberite Možnosti in Dodatki.

6

V razdelku Dodatni dodatki izberite potrditveno polje poleg možnosti "Virtual Connect for Dedicated Instance". Ime SKU je "A-FLEX-DI-VC".

7

Vnesite količino in število regij, v katerih se zahteva Virtual Connect.

Količina Virtual Connect ne sme presegati skupnega števila regij, kupljenih za Dedicated Instance. Prav tako je v posamezni regiji dovoljeno samo eno naročilo Virtual Connect.
8

Ko ste z izbiro zadovoljni, kliknite Preveri in shrani v zgornjem desnem delu strani.

9

Kliknite Shrani in nadaljuj, da dokončate naročilo. Dokončano naročilo je zdaj prikazano v mreži naročil.

2. korak: Aktivacija funkcije Virtual Connect v nadzornem vozlišču

1

Prijavite se v https://admin.webex.com/loginControl Hub .

2

V razdelku Services (Storitve) pojdite na Calling > Dedicated Instacnce > Cloud Connectivity (Povezljivost v oblaku).

3

Na kartici Virtual Connect je navedena kupljena količina programa Virtual Connect. Upravitelj lahko zdaj klikne na Activate , da sproži aktivacijo programa Virtual Connect.

Postopek aktivacije lahko sprožijo samo administratorji z vlogo "Customer Full admin". Upravitelj z vlogo "Customer read-only admin" lahko le pregleduje stanje.
4

Ob kliku na gumb Activate se prikaže obrazec Activate Virtual Connect , v katerem mora skrbnik navesti tehnične podatke o omrežju Virtual Connect, ki so potrebni za konfiguracijo enakovrednega povezovanja na Ciscovi strani.

Obrazec zagotavlja tudi statične informacije na Ciscovi strani glede na izbrano regijo. Te informacije bodo uporabne za skrbnike strank, da konfigurirajo CPE na svoji strani za vzpostavitev povezljivosti.

  1. GRE Tunel Transportni IP naslov: Stranka mora zagotoviti naslove IP za prenos predora na strani stranke, Cisco pa bo naslove IP dinamično dodelil po končani aktivaciji. IPSec ACL za zanimiv promet mora dovoliti lokalni predor IP/32 do oddaljenega predora IP/32. V seznamu ACL je treba navesti tudi samo protokol GRE IP.

    Naslov IP, ki ga zagotovi stranka, je lahko zasebni ali javni.

  2. Vrstniki IPSec: Stranka mora zagotoviti izvorne naslove IP predora IPSec, Cisco pa dodeli ciljni naslov IP IPSec. Po potrebi je podprto tudi prevajanje NAT notranjega naslova predora IPSEC na javni naslov.

    Naslov IP, ki ga zagotovi stranka, mora biti javen.

    Vse druge statične informacije, ki so navedene v aktivacijskem zaslonu, so upoštevani varnostni in šifrirni standardi Ciscove strani. Te statične konfiguracije ni mogoče prilagoditi ali spremeniti. Za nadaljnjo pomoč v zvezi s statičnimi konfiguracijami na Ciscovi strani se mora stranka obrniti na oddelek TAC.
5

Ko so izpolnjena vsa obvezna polja, kliknite gumb Activate .

6

Ko je obrazec za aktivacijo Virtual Connect izpolnjen za določeno regijo, lahko stranka izvozi obrazec za aktivacijo iz Control Hub, Calling > Dedicated Instance > Cloud Connectivity tab in klikne na Export settings.

Zaradi varnostnih razlogov avtentikacija in geslo BGP ne bosta na voljo v izvoženem dokumentu, vendar si ju lahko skrbnik ogleda v vozlišču Control Hub tako, da klikne na View Settings v Control Hub, Calling > Dedicated Instance > Cloud Connectivity tab.

3. korak: Cisco izvaja konfiguracijo omrežja

1

Ko je obrazec za aktivacijo virtualne povezave izpolnjen, se stanje posodobi na Aktivacija v teku v razdelku Klicanje > Namenska zmogljivost > Kartica virtualne povezave v oblaku.

2

Cisco bo dokončal zahtevane konfiguracije na opremi na Ciscovi strani v 5 delovnih dneh. Po uspešnem zaključku se stanje za določeno regijo v vozlišču Control Hub posodobi na "Aktivirano".

4. korak: Stranka izvede konfiguracijo omrežja

Stanje se spremeni v "Aktivirano", da se skrbnik stranke obvesti, da so bile Ciscove konfiguracije za povezljivost IP VPN dokončane na podlagi vhodnih podatkov, ki jih je zagotovila stranka. Vendar se od skrbnika stranke pričakuje, da bo dokončal svoje konfiguracije na napravah CPE in preizkusil poti povezljivosti za predor Virtual Connect, da bo predor Online. V primeru kakršnih koli težav pri konfiguraciji ali povezljivosti se lahko stranka za pomoč obrne na Cisco TAC.

Odpravljanje težav

Odpravljanje težav in potrjevanje prve faze IPsec (pogajanja IKEv2)

Pogajanja o predoru IPsec vključujejo dve fazi, in sicer fazo IKEv2 in fazo IPsec. Če se pogajanja v fazi IKEv2 ne zaključijo, se druga faza IPsec ne začne. Najprej izdate ukaz "show crypto ikev2 sa" (na opremi Cisco) ali podoben ukaz na opremi tretje osebe, da preverite, ali je seja IKEv2 aktivna. Če seja IKEv2 ni aktivna, so možni razlogi naslednji:

  • Zanimiv promet ne sproži predora IPsec.

  • Seznam za dostop do predora IPsec je napačno konfiguriran.

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

  • Parametri seje IKEv2 se ne ujemajo med stranjo namenske instance in stranko.

  • Požarni zid blokira pakete IKEv2 UDP.

Najprej v dnevnikih IPsec poiščite sporočila, ki prikazujejo potek pogajanj o predoru IKEv2. V dnevnikih je lahko navedeno, kje je težava pri pogajanjih IKEv2. Pomanjkanje sporočil za beleženje lahko pomeni tudi, da seja IKEv2 ni aktivirana.

Pogoste napake pri pogajanjih IKEv2 so:

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

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

    • Preverite, ali se parametri šifriranja in avtentikacije ujemajo s pričakovanim šifriranjem na strani namenske instance.

      Kadar se uporablja šifra "GCM", protokol GCM poskrbi za preverjanje pristnosti in nastavi parameter preverjanja pristnosti na NULL.

    • Preverite nastavitev življenjske dobe.

    • Preverite skupino modulov Diffie Hellman.

    • Preverite nastavitve psevdonaključne funkcije.

  • Seznam dostopa za kripto mapo ni nastavljen na:

    • Permit GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255.255" (ali enakovreden ukaz)

      Seznam dostopa mora biti posebej namenjen protokolu "GRE", protokol "IP" ne bo deloval.

Če sporočila dnevnika ne prikazujejo nobene dejavnosti pogajanj za fazo IKEv2, bo morda potreben zajem paketov.

Namenska stran instanc morda ne bo vedno začela izmenjave IKEv2 in lahko včasih pričakuje, da bo pobudnik stran CPE stranke.

Preverite, ali so v konfiguraciji na strani CPE izpolnjeni naslednji predpogoji za začetek seje IKEv2:

  • Preverite, ali je za promet GRE (protokol 50) s transportnega IP predora CPE na transportni IP predora Dedicated Instance vzpostavljen seznam za dostop do kriptografskega protokola IPsec.

  • Prepričajte se, da je vmesnik tunela GRE omogočen za ohranitev ohranitev GRE, če oprema ne podpira ohranitve GRE, je Cisco o tem obveščen, saj bo ohranitev GRE privzeto omogočena na strani namenske instance.

  • Prepričajte se, da je BGP omogočen in konfiguriran s sosednjim naslovom IP predora namenske instance.

Če je pravilno konfiguriran, se v nadaljevanju začneta predor IPsec in prva faza pogajanj IKEv2:

  • GRE keepalives iz vmesnika GRE tunela na strani CPE v vmesnik GRE tunela na strani namenske instance.

  • Sosed BGP Seja TCP od soseda BGP na strani CPE do soseda BGP na strani Dedicated Instance.

  • Ping od IP naslova tunela na strani CPE do IP naslova tunela na strani namenske instance.

    Ping ne more biti prenosni IP tunela na prenosni IP tunela, ampak mora biti prenosni IP tunela na IP tunela.

Če je za promet IKEv2 potrebno sledenje paketov, nastavite filter za UDP in vrata 500 (če med končnimi točkami IPsec ni naprave NAT) ali vrata 4500 (če je med končnimi točkami IPsec vstavljena naprava NAT).

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

Podatkovni center namenske instance morda ne bo vedno začel prvega paketa IKEv2. Zahteva je, da lahko naprava CPE sproži prvi paket IKEv2 na strani namenske instance.

Če lokalni požarni zid to dovoljuje, poskusite tudi s pingom na oddaljeni naslov IPsec. Če ping ni uspešen od lokalnega do oddaljenega naslova IPsec, si pomagajte s sledenjem poti in ugotovite, kje je paket zavrnjen.

Nekateri požarni zidovi in internetna oprema morda ne bodo dovolili poti sledenja.

Druga faza IPsec (pogajanja IPsec) Odpravljanje težav in potrjevanje

Pred odpravljanjem težav z drugo fazo IPsec preverite, ali je prva faza IPsec (tj. varnostno združenje IKEv2) aktivna. Izvedite ukaz "show crypto ikev2 sa" ali enakovreden ukaz za preverjanje seje IKEv2. V izpisu preverite, ali je seja IKEv2 vzpostavljena že več kot nekaj sekund in ali se ne odbija. Čas delovanja seje se prikaže kot "aktivni čas" seje ali enakovredno v izpisu.

Ko preverite, da je seja IKEv2 vzpostavljena in aktivna, raziščite sejo IPsec. Tako kot pri seji IKEv2 preverite sejo IPsec z ukazom "show crypto ipsec sa" ali enakovrednim ukazom. Pred vzpostavitvijo predora GRE morata biti aktivni seja IKEv2 in seja IPsec. Če seja IPsec ni prikazana kot aktivna, v dnevnikih IPsec poiščite sporočila o napakah ali napake pri pogajanjih.

Med pogajanji IPsec se lahko pojavijo nekatere najpogostejše težave:

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

  • Preverite, ali se parametri šifriranja in avtentikacije ujemajo z nastavitvami na strani namenske instance.

  • Preverite nastavitve Perfect Forward Secrecy in ali se ujemajo z nastavitvami na strani namenske instance.

  • Preverite nastavitve življenjske dobe.

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

  • Preverite izvorni in ciljni naslov IPsec.

Odpravljanje težav in potrjevanje vmesnika predora

Ko sta seji IPsec in IKEv2 preverjeni kot vzpostavljeni in aktivni, lahko med končnima točkama predora Dedicated Instance in CPE tečejo ohranitveni paketi predora GRE. Če vmesnik predora ne prikazuje statusa, so nekatere pogoste težave naslednje:

  • VRF transportnega vmesnika tunela se ne ujema z VRF vmesnika povratne zanke (če se na vmesniku tunela uporablja konfiguracija VRF).

    Če se konfiguracija VRF na vmesniku predora ne uporablja, tega preverjanja ne upoštevajte.

  • Vmesnik tunela na strani CPE ni omogočen.

    Če oprema CPE ne podpira ohranjanja trajanja, je treba obvestiti Cisco, da se onemogoči tudi privzeto ohranjanje trajanja na strani namenskega primerka.

    Če so podprte funkcije keepalives, preverite, ali so te omogočene.

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

  • Izvorni ali ciljni transportni naslov 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 prejemanje iz predora IPsec (predor GRE se prenaša prek predora IPsec).

S testom ping je treba preveriti, ali je lokalni vmesnik predora vzpostavljen in ali je povezljivost z oddaljenim vmesnikom predora dobra. Izvedite preverjanje ping z IP-ja predora (ne transportnega IP-ja) do oddaljenega IP-ja predora.

Seznam dostopa za kriptografijo za tunel IPsec, ki prenaša promet tunela GRE, dovoljuje prehod samo paketom GRE. Zaradi tega se ne bodo izvajali klici s transportnega IP predora na oddaljeni transportni IP predora.

Rezultat preverjanja ping je paket GRE, ki se ustvari od izvornega IP-ja za prenos predora do ciljnega IP-ja za prenos predora, pri čemer je koristni tovor paketa GRE (notranji IP) izvorni in ciljni IP predora.

Če preskus ping ni uspešen in so prejšnji elementi preverjeni, bo morda potreben zajem paketov, da se zagotovi, da ping icmp povzroči paket GRE, ki je nato enkapsuliran v paket IPsec in poslan z izvornega naslova IPsec na ciljni naslov IPsec. Če se paketi za pošiljanje in sprejemanje povečujejo, lahko pomagajo tudi števci na vmesniku predora GRE in števci seje IPsec.

Poleg prometa ping mora zajem prikazati tudi vzdrževalne pakete GRE, tudi med neaktivnim prometom. Če je konfiguriran protokol BGP, je treba prek omrežja VPN pošiljati tudi vzdrževalne pakete BGP kot pakete GRE, enkapsulirane v pakete IPSEC.

Odpravljanje težav in potrjevanje BGP

Seje BGP

BGP je potreben kot usmerjevalni protokol v predoru VPN IPsec. Lokalni sosed BGP mora vzpostaviti sejo eBGP s sosedom Dedicated Instance BGP. IP-naslovi sosedov eBGP so enaki IP-naslovom lokalnega in oddaljenega predora. Najprej se prepričajte, da je seja BGP vzpostavljena, nato pa preverite, ali se od namenske instance prejemajo pravilne poti in ali se v namensko instanco pošilja pravilna privzeta pot.

Če je predor GRE vzpostavljen, preverite, ali je ping med lokalnim in oddaljenim IP-jem predora GRE uspešen. Če je ping uspešen, vendar se seja BGP ne vzpostavi, v dnevniku BGP poiščite napake pri vzpostavitvi BGP.

Nekatere pogostejše težave pri pogajanjih BGP so:

  • Oddaljena številka AS se ne ujema s številko AS, ki je konfigurirana na strani namenske različice, ponovno preverite konfiguracijo sosednjega AS.

  • Lokalna številka AS se ne ujema s pričakovanji strani namenskega vmesnika, preverite, ali se lokalna številka AS ujema s pričakovanimi parametri namenskega vmesnika.

  • Požarni zid blokira pošiljanje paketov BGP TCP, enkapsuliranih v pakete GRE, v predor IPsec ali njihovo prejemanje iz predora IPSEC.

  • IP oddaljenega soseda BGP se ne ujema z IP oddaljenega tunela GRE.

Izmenjava poti BGP

Ko preverite sejo BGP za oba tunela, preverite, ali se s strani namenske instance pošiljajo in prejemajo pravilne poti.

Rešitev Dedicated Instance VPN pričakuje vzpostavitev dveh tunelov na strani stranke/partnerja. Prvi tunel kaže na podatkovni center A namenske instance, drugi tunel pa na podatkovni center B namenske instance.Oba tunela morata biti v aktivnem stanju, rešitev pa zahteva aktivno/aktivno namestitev. Vsak podatkovni center za namenske instance bo oglaševal svojo lokalno pot /25 in rezervno pot /24. Pri preverjanju dohodnih poti BGP iz namenske instance zagotovite, da seja BGP, povezana s predorom, ki kaže na podatkovni center A namenske instance, prejme lokalno pot /25 podatkovnega centra A namenske instance in rezervno pot /24. Poleg tega zagotovite, da predor, ki kaže na podatkovni center B namenske instance, prejme lokalno pot /25 podatkovnega centra B namenske instance in rezervno pot /24. Upoštevajte, da bo rezervna pot /24 enaka poti, ki se oglašuje iz podatkovnega centra A in podatkovnega centra B namenske instance.

Če vmesnik predora do tega podatkovnega središča odpove delovanje, je podatkovnemu središču namenske instance zagotovljena redundanca. Če se povezljivost z namensko zmogljivostjo podatkovnega centra A izgubi, se promet iz namenske zmogljivosti podatkovnega centra B posreduje v podatkovni center A. V tem scenariju bo predor do podatkovnega centra B za pošiljanje prometa v podatkovni center B uporabil pot /25 podatkovnega centra B, predor do podatkovnega centra B pa bo za pošiljanje prometa v podatkovni center A prek podatkovnega centra B uporabil rezervno pot /24.

Pomembno je, da ko sta oba tunela aktivna, se tunel podatkovnega centra A ne uporablja za pošiljanje prometa v podatkovni center B in obratno. Če je v tem scenariju promet poslan v podatkovni center A z namembnim krajem v podatkovnem centru B, bo podatkovni center A posredoval promet v podatkovni center B, nato pa bo podatkovni center B poskušal poslati promet nazaj v vir prek predora podatkovnega centra B. To bo povzročilo neoptimalno usmerjanje in lahko povzroči tudi prekinitev prometa, ki prečka požarne zidove. Zato je pomembno, da sta oba tunela med običajnim delovanjem v konfiguraciji aktivni/aktivni.

Pot 0.0.0.0.0/0 mora biti oglaševana s strani stranke na stran podatkovnega centra namenske instance. Stran namenskega primerka ne bo sprejela bolj specifičnih poti. Zagotovite, da se pot 0.0.0.0.0/0 oglašuje iz tunela namenske instance podatkovnega centra A in tunela namenske instance podatkovnega centra B.

Konfiguracija MTU

Na strani namenske različice sta omogočeni dve funkciji za dinamično prilagajanje MTU za velike velikosti paketov. Predor GRE doda več glave paketom IP, ki tečejo skozi sejo VPN. Predor IPsec doda dodatne glave na glave GRE, kar še dodatno zmanjša največjo dovoljeno MTU v predoru.

Na strani namenske instance je omogočena funkcija GRE tunnel adjusts MSS in GRE tunnel path in the MTU discovery. Konfigurirajte ukaz "ip tcp adjust-mss 1350" ali enakovreden ukaz ter ukaz "tunnel path\u0002mtu-discovery" ali enakovreden ukaz na strani stranke, ki pomaga pri dinamičnem prilagajanju MTU prometa skozi tunel VPN.