Uvod

Virtual Connect je dodatna možnost dodatka za povezljivost v oblaku z namensko instanco za Webex Calling (namenska instanca). Navidezna povezava strankam omogoča varno razširitev njihovega zasebnega omrežja prek interneta z uporabo tunelov IP VPN od točke do točke. Ta možnost povezovanja omogoča hitro vzpostavitev zasebne omrežne povezave z uporabo obstoječe opreme v prostorih stranke (CPE) in internetne povezave.

Cisco gosti, upravlja in zagotavlja redundantne tunele IP VPN in potreben dostop do interneta v regijah podatkovnega središča Ciscove namenske instance, kjer je storitev potrebna. Podobno je skrbnik odgovoren za svoje ustrezne CPE in internetne storitve, ki so potrebne za vzpostavitev virtualne povezave.

Vsako naročilo navidezne povezave v določeni regiji namenske instance bi vključevalo dva tunela za generično usmerjevalno inkapsulacijo (GRE), zaščitena s šifriranjem IPSec (GRE preko IPSec), po enega za vsako Ciscovo podatkovno središče v izbrani regiji.

Virtual Connect ima omejitev pasovne širine 250 Mbps na tunel in je priporočljiva za manjše uvedbe. Ker se uporabljata dva tunela VPN od točke do točke, mora ves promet v oblak potekati prek CPE glavne enote stranke, zato morda ni primeren tam, kjer je veliko oddaljenih mest. Za druge alternativne možnosti peeringa glejte Povezljivost v oblaku.

Preden oddate zahtevo za enakovredno povezovanje za Virtual Connect, se prepričajte, da je storitev Dedicated Instance aktivirana v zadevni regiji.

Predpogoji

Predpogoji za vzpostavitev virtualne povezave vključujejo:

Stranka zagotavlja
- Internetna povezava z dovolj razpoložljive pasovne širine za podporo uvajanja
- Javni naslov(-i) IP za dva tunela IPSec
- IP-naslovi GRE za prenos GRE za dva tunela GRE
Partner in kupec
- Sodelujte pri oceni zahtev glede pasovne širine
- Zagotovite, da omrežne naprave podpirajo usmerjanje BGP (Border Gateway Protocol) in zasnovo tunela GRE prek IPSec
zagotavlja partner ali stranka
- Omrežna ekipa z znanjem o tehnologijah tunelov VPN od mesta do mesta
- Omrežna ekipa z znanjem o BGP, eBGP in splošnih načelih usmerjanja
Cisco
- Cisco je dodelil zasebne avtonomne sistemske številke (ASN) in prehodno naslavljanje IP za vmesnike tunela GRE
- Cisco je dodelil javno, a ne internetno usmerjevalno omrežje razreda C (/24) za naslavljanje namenskih primerkov v oblaku

Če ima stranka samo 1 napravo CPE, bosta 2 tunela proti Ciscovim podatkovnim centrom (DC1 in DC2) v vsaki regiji iz te naprave CPE. Stranka ima tudi možnost za 2 napravi CPE, potem se mora vsaka naprava CPE povezati samo z 1 tunelom proti Ciscovim podatkovnim središčem (DC1 in DC2) v vsaki regiji. Dodatno redundanco je mogoče doseči z zaključkom vsakega tunela na ločenem fizičnem mestu/lokaciji znotraj naročnikove infrastrukture.

Tehnične podrobnosti

Model uvajanja

Virtual Connect uporablja dvonivojsko glavno enoto, kjer usmerjanje in nadzorne ravnine GRE zagotavlja ena naprava, nadzorno ravnino IPSec pa druga.

Po zaključku Virtualna povezava povezljivosti bosta ustvarjena dva tunela GRE preko IPSec med naročnikovim poslovnim omrežjem in namenskimi primerki Ciscovih podatkovnih centrov. Ena za vsako redundantno podatkovno središče v zadevni regiji. Dodatne omrežne elemente, potrebne za enakovredno povezovanje, partner ali stranka izmenja s Cisco prek aktivacijskega obrazca Control Hub Virtual Connect.

Slika 1 prikazuje primer modela uvajanja Virtual Connect za možnost 2-koncentratorja na strani stranke.

Navidezna povezava – VPN je zasnova vozlišča, kjer so strankina mesta vozlišča povezana z DC1 in DC2 podatkovnih centrov namenske instance znotraj določene regije.

Za boljšo redundanco sta priporočljivi dve mesti vozlišča, vendar je podprt model uvajanja tudi eno mesto vozlišča z dvema tuneloma.

Pasovna širina na tunel je omejena na 250 Mbps.

Strankina oddaljena mesta znotraj iste regije bi se morala povezati nazaj na stran(-a) središča prek strankinega omrežja WAN in Cisco ni odgovoren za to povezljivost.

Od partnerjev se pričakuje, da bodo tesno sodelovali s strankami in zagotovili izbiro najbolj optimalne poti za regijo storitev 'Virtual Connect'.

Slika 2 prikazuje enakovredne regije Dedicated Instance Cloud Connectivity.

Usmerjanje

Usmerjanje za dodatek Virtual Connect se izvaja z uporabo zunanjega BGP (eBGP) med namensko instanco in opremo naročnika (CPE). Cisco bo naročnikovemu CPE oglaševal svoje zadevno omrežje za vsak redundantni DC znotraj regije, CPE pa mora oglaševati privzeto pot do Cisca.

Cisco vzdržuje in dodeljuje
- Naslavljanje IP vmesnika tunela (prehodna povezava za usmerjanje) Cisco dodeli iz določenega naslovnega prostora v skupni rabi (nejavno usmerjevalno)
- Ciljni naslov prevoza v predoru (na Ciscovi strani)
- Številke zasebnega avtonomnega sistema (ASN) za konfiguracijo usmerjanja strank BGP
  - Cisco dodeli 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 za vsak DC v zadevni regiji
- V Virtual Connect vsako omrežje /25 Cisco oglašuje nazaj CPE prek ustreznih tunelov VPN od točke do točke (prehodna povezava)
- CPE mora biti konfiguriran z ustreznimi sosedi eBGP. Če uporabljate en CPE, bosta uporabljena dva soseda eBGP, eden kaže na vsak oddaljeni tunel. Če uporabljate dva CPE, bo vsak CPE imel enega soseda eBGP, ki kaže na en sam oddaljeni tunel za CPE.
- Ciscova stran vsakega tunela GRE (IP vmesnika tunela) je konfigurirana kot sosed BGP na CPE
- CPE je potreben za oglaševanje privzete poti v vsakem tunelu
- CPE je odgovoren za redistribucijo, kot je potrebno, naučenih poti znotraj naročnikovega poslovnega omrežja.
Pod pogojem okvare povezave brez napak bo imel en sam CPE dva aktivna/aktivna tunela. Za dve vozlišči CPE bo imelo vsako CPE en aktiven tunel in obe vozlišči CPE morata biti aktivni in prepuščati promet. Po scenariju brez napak se mora promet razdeliti na dva predora, ki vodita do pravilnih /25 ciljev; če eden od predorov zaide, lahko preostali predor prenaša promet za oba. Pri takšnem scenariju napake, ko omrežje /25 ne deluje, se omrežje /24 uporabi kot rezervna pot. Cisco bo poslal promet strank prek svojega notranjega omrežja WAN proti DC-ju, ki je izgubil povezavo.

Postopek povezovanja

Naslednji koraki na visoki ravni opisujejo, kako vzpostaviti povezljivost z virtualno povezavo za namenski primerek.

1	Oddajte naročilo v Cisco CCW
2	Aktivirajte Virtual Connect iz Control Huba
3	Cisco izvaja konfiguracijo omrežja
4	Stranka izvede konfiguracijo omrežja

Korak 1: CCW ukaz

Virtual Connect je dodatek za namenski primerek v CCW.

Pojdite na spletno mesto za naročanje CCW in kliknite Prijava, da se prijavite na spletno mesto:

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

Ustvari oceno.

Dodajte SKU "A-FLEX-3".

Izberite možnosti urejanja.

V zavihku za naročnine, ki se prikaže, izberite Možnosti in dodatki.

V razdelku Dodatni dodatki izberite potrditveno polje poleg možnosti »Navidezna povezava za namenski primerek«. Ime SKU je "A-FLEX-DI-VC".

Vnesite količino in število regij, v katerih je potrebna navidezna povezava.

Količina Virtual Connect ne sme preseči skupnega števila regij, kupljenih za Dedicated Instance. Prav tako je dovoljeno samo eno naročilo za navidezno povezovanje na regijo.

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

Za dokončanje naročila kliknite Shrani in nadaljuj. Vaše dokončano naročilo se zdaj prikaže v mreži naročil.

2. korak: Aktivacija Virtual Connect v Control Hub

Prijavite se v Control Hub https://admin.webex.com/login.

V Storitve razdelek, pojdite na Klicanje > Namenska instanca > Povezljivost v oblaku.

Na kartici Virtual Connect je navedena količina kupljenega Virtual Connecta. Skrbnik lahko zdaj klikne Aktiviraj za začetek aktivacije Virtual Connect.

Postopek aktivacije lahko sprožijo samo skrbniki z vlogo »Customer Full admin«. Medtem ko lahko skrbnik z vlogo »skrbnik samo za branje stranke« samo vidi stanje.

Ob kliku na Aktiviraj gumb, Aktivirajte Virtual Connect se prikaže obrazec za skrbnika, da zagotovi tehnične podrobnosti o virtualni povezavi, ki so potrebne za konfiguracije enakovrednih povezav na strani Cisca.

Obrazec zagotavlja tudi statične informacije na strani Cisca glede na izbrano regijo. Te informacije bodo uporabne za skrbnike strank pri konfiguraciji CPE na njihovi strani za vzpostavitev povezljivosti.

GRE Tunnel Transport IP naslov: Stranka mora zagotoviti IP-naslove Tunnel Transport na strankini strani in Cisco bo dinamično dodelil IP-naslove, ko bo aktivacija končana. IPSec ACL za zanimiv promet bi moral omogočati lokalni tunelski transport IP/32 na oddaljeni tunelski transport IP/32. ACL mora prav tako določati samo protokol GRE IP.

Naslov IP, ki ga posreduje stranka, je lahko zaseben ali javen.

vrstniki IPSec: Stranka mora zagotoviti izvorne naslove IP za predor IPSec, Cisco pa dodeli ciljni naslov IP IPSec. Po potrebi je podprto tudi prevajanje NAT notranjega naslova tunela IPSEC v javni naslov.

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

Vse druge statične informacije na aktivacijskem zaslonu so Ciscovi stranski standardi varnosti in šifriranja. Te statične konfiguracije ni mogoče prilagoditi ali spremeniti. Za kakršno koli dodatno pomoč v zvezi s statičnimi konfiguracijami na Ciscovi strani bi se morala stranka obrniti na TAC.

Kliknite na Aktiviraj ko so izpolnjena vsa obvezna polja.

Ko je aktivacijski obrazec za navidezno povezavo izpolnjen za določeno regijo, lahko stranka izvozi aktivacijski obrazec iz Nadzornega središča, Klicanje > Namenski primerek > zavihek Povezljivost v oblaku in klikne Izvozi nastavitve.

Zaradi varnostnih razlogov avtentikacija in geslo BGP ne bosta na voljo v izvoženem dokumentu, vendar si ju lahko skrbnik ogleda v središču Control Hub s klikom na Ogled nastavitev pod Control Hub, Klicanje > Namenski primerek > zavihek Povezljivost v oblaku.

3. korak: Cisco izvaja konfiguracijo omrežja

1	Ko je obrazec za aktivacijo virtualne povezave izpolnjen, bo stanje posodobljeno na Aktivacija v teku v razdelku Klicanje > Namenski primerek > Kartica Virtual Connect Connectivity v oblaku.
2	Cisco bo dokončal zahtevane konfiguracije na Ciscovi stranski opremi znotraj 5 delovnih dni. Po uspešnem zaključku bo stanje posodobljeno na »Aktivirano« za določeno regijo v Control Hubu.

4. korak: Stranka izvede konfiguracijo omrežja

Status se spremeni v »Aktivirano«, da se strankin skrbnik obvesti, da so konfiguracije Ciscove strani za povezljivost IP VPN dokončane na podlagi vnosov, ki jih je zagotovila stranka. Toda od skrbnika stranke se pričakuje, da bo dokončal svojo stran konfiguracij na CPE in preizkusil povezovalne poti, da bo tunel Virtual Connect na spletu. V primeru kakršnih koli težav, s katerimi se sooča med konfiguracijo ali povezljivostjo, se lahko stranka za pomoč obrne na Cisco TAC.

Odpravljanje težav

IPsec prva faza (IKEv2 Negotiation) odpravljanje težav in preverjanje veljavnosti

Pogajanje o tunelu IPsec vključuje dve fazi, fazo IKEv2 in fazo IPsec. Če se pogajanja o fazi IKEv2 ne zaključijo, potem ni začetka druge faze IPsec. Najprej izdajte ukaz "show crypto ikev2 sa" (na opremi Cisco) ali podoben ukaz na opremi drugega proizvajalca, da preverite, ali je seja IKEv2 aktivna. Če seja IKEv2 ni aktivna, so možni razlogi lahko:

Zanimiv promet ne sproži tunela IPsec.
Seznam dostopa do tunela IPsec je napačno konfiguriran.
Med stranko in IP končno točko tunela IPsec za namenski primerek ni povezave.
Parametri seje IKEv2 se ne ujemajo med stranjo namenske instance in stranjo stranke.
Požarni zid blokira pakete UDP IKEv2.

Najprej v dnevnikih IPsec preverite morebitna sporočila, ki prikazujejo napredek pogajanj o tunelu IKEv2. Dnevniki lahko nakazujejo, kje je težava s pogajanji IKEv2. Pomanjkanje sporočil za beleženje lahko tudi pomeni, da seja IKEv2 ni aktivirana.

Nekatere pogoste napake pri pogajanjih IKEv2 so:

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

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

Preverite, ali se parametra šifriranja in avtentikacije ujemata s pričakovanim šifriranjem na strani namenskega primerka.

Ko je šifra "GCM" v uporabi, protokol GCM obravnava avtentikacijo in nastavi parameter avtentikacije na NULL.

Preverite nastavitev življenjske dobe.
Preverite skupino modulov Diffie Hellman.
Preverite nastavitve psevdonaključne funkcije.

Seznam dostopov za kripto zemljevid ni nastavljen na:

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

Seznam dostopov mora biti posebej za protokol "GRE" in protokol "IP" ne bo deloval.

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

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

Preverite konfiguracijo strani CPE za naslednje predpogoje za začetek seje IKEv2:

Preverite seznam kripto dostopa IPsec za promet GRE (protokol 50) od IP-ja za prenos tunela CPE do IP-ja za prenos tunela Dedicated Instance.
Prepričajte se, da je vmesnik tunela GRE omogočen za vzdrževanje GRE. Če oprema ne podpira vzdrževanja GRE, je Cisco obveščen, ker bo vzdrževanje GRE privzeto omogočeno na strani namenske instance.
Prepričajte se, da je BGP omogočen in konfiguriran s sosednjim naslovom IP tunela namenske instance.

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

Ohranjanje GRE od vmesnika tunela GRE na strani CPE do vmesnika tunela GRE na strani namenske instance.
Seja TCP soseda BGP od soseda BGP na strani CPE do soseda BGP na strani namenske instance.

Ping z naslova IP tunela strani CPE na naslov IP tunela strani namenske instance.

Ping ne more biti IP transporta tunela do IP transporta tunela, mora biti IP tunela do IP tunela.

Če je za promet IKEv2 potrebna sled paketa, nastavite filter za UDP in vrata 500 (če na sredini končnih točk IPsec ni nobene naprave NAT) ali vrata 4500 (ko je naprava NAT vstavljena na sredino IPsec končne točke).

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

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

Če lokalni požarni zid to dovoljuje, poskusite tudi ping na oddaljeni naslov IPsec. Če ping od lokalnega do oddaljenega naslova IPsec ni uspešen, izvedite sledenje poti za pomoč in ugotovite, kam je bil paket odložen.

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

Odpravljanje težav in preverjanje IPsec v drugi fazi (pogajanje IPsec).

Preverite, ali je prva faza IPsec (to je varnostna povezava IKEv2) aktivna, preden začnete odpravljati težave z drugo fazo IPsec. Izvedite "show crypto ikev2 sa" ali enakovreden ukaz, da preverite sejo IKEv2. V izhodu preverite, ali je seja IKEv2 vzpostavljena več kot nekaj sekund in da ne odskoči. Čas delovanja seje je prikazan kot "aktivni čas" seje ali enakovredno v izhodu.

Ko se potrdi, da je seja IKEv2 vzpostavljena in aktivna, raziščite sejo IPsec. Tako kot pri seji IKEv2 izvedite "show crypto ipsec sa" ali enakovreden ukaz, da preverite sejo IPsec. Tako seja IKEv2 kot seja IPsec morata biti aktivni, preden se vzpostavi tunel GRE. Če seja IPsec ni prikazana kot aktivna, preverite, ali so v dnevnikih IPsec sporočila o napakah ali napake pri pogajanjih.

Nekatere pogostejše težave, na katere lahko naletite med pogajanji IPsec, so:

Nastavitve na strani CPE se ne ujemajo s stranjo namenske instance, znova preverite nastavitve:

Preverite, ali se parametra šifriranja in overjanja ujemata z nastavitvami na strani namenskega primerka.
Preverite nastavitve Perfect Forward Secrecy in ali se ujemajo z nastavitvami na strani namenske instance.
Preverite nastavitve življenjske dobe.
Preverite, ali je bil IPsec konfiguriran v tunelskem načinu.
Preverite izvorni in ciljni naslov IPsec.

Odpravljanje težav in validacija vmesnika tunela

Ko sta seji IPsec in IKEv2 preverjeni kot vzpostavljeni in aktivni, lahko paketi za vzdrževanje tunela GRE tečejo med namensko instanco in končnimi točkami tunela CPE. Če vmesnik tunela ne prikazuje statusa, je nekaj pogostih težav:

VRF prenosa vmesnika tunela se ne ujema z VRF vmesnika povratne zanke (če je konfiguracija VRF uporabljena na vmesniku tunela).

Če konfiguracija VRF ni uporabljena na vmesniku tunela, lahko to preverjanje prezrete.

Keepalive niso omogočene na vmesniku stranskega tunela CPE

Če oprema CPE ne podpira vzdrževalnih dejstev, je treba o tem obvestiti Cisco, tako da so onemogočene tudi privzete vzdrževalne aktivnosti na strani namenske instance.

Če so vzdrževalna sporočila podprta, preverite, ali so vzdrževanja omogočena.

Maska ali naslov IP vmesnika tunela ni pravilen in se ne ujema s pričakovanimi vrednostmi namenske instance.
Izvorni ali ciljni transportni naslov tunela ni pravilen in se ne ujema s pričakovanimi vrednostmi namenske instance.
Požarni zid blokira pakete GRE, poslane v tunel IPsec ali prejete iz tunela IPsec (tunel GRE se prenaša prek tunela IPsec)

Test ping bi moral preveriti, ali lokalni vmesnik tunela deluje in je povezljivost z oddaljenim vmesnikom tunela dobra. Izvedite preverjanje pinga iz IP-ja tunela (ne transportnega IP-ja) na IP oddaljenega tunela.

Seznam kripto dostopa za tunel IPsec, ki prenaša promet tunela GRE, dovoljuje prehod samo paketom GRE. Posledično pingi ne bodo delovali od IP-ja prenosa tunela do IP-ja oddaljenega transporta tunela.

Rezultat preverjanja pinga je paket GRE, ki je ustvarjen od izvornega IP-ja za transport tunela do IP-ja ciljnega tunela za transport, medtem ko bo koristni tovor paketa GRE (notranji IP) izvorni in ciljni IP tunela.

Če preizkus pinga ni uspešen in so prejšnji elementi preverjeni, bo morda potreben zajem paketa, da se zagotovi, da rezultat pinga icmp je paket GRE, ki je nato enkapsuliran v paket IPsec in nato poslan z izvornega naslova IPsec na ciljni naslov IPsec. Pri prikazu lahko pomagajo tudi števci na vmesniku tunela GRE in števci sej IPsec. če se paketi za pošiljanje in prejemanje povečujejo.

Poleg prometa ping bi moral zajem prikazati tudi pakete GRE keepalive tudi med mirovanjem prometa. Nazadnje, če je BGP konfiguriran, je treba pakete BGP keepalive poslati tudi kot pakete GRE, inkapsulirane v pakete IPSEC, prav tako prek VPN.

Odpravljanje težav in preverjanje BGP

Seje BGP

BGP je potreben kot usmerjevalni protokol prek tunela VPN IPsec. Lokalni sosed BGP mora vzpostaviti sejo eBGP s sosedom namenskega primerka BGP. Naslovi IP sosedov eBGP so enaki naslovom IP lokalnega in oddaljenega tunela. Najprej zagotovite, da je seja BGP vzpostavljena, nato pa preverite, ali so iz namenske instance prejete pravilne poti in da je namenski instanci poslana pravilna privzeta pot.

Če je tunel GRE odprt, preverite, ali je ping uspešen med lokalnim in oddaljenim IP-jem tunela GRE. Če je ping uspešen, vendar seja BGP ne pride, potem preiščite dnevnik BGP za napake pri vzpostavitvi BGP.

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

Številka oddaljenega AS se ne ujema s številko AS, ki je konfigurirana na strani namenskega primerka, znova preverite konfiguracijo sosednjega AS.
Lokalna številka AS se ne ujema s tem, kar pričakuje stran namenske instance, preverite, ali se lokalna številka AS ujema s pričakovanimi parametri namenske instance.
Požarni zid preprečuje, da bi bili paketi BGP TCP, enkapsulirani v pakete GRE, poslani v tunel IPsec ali prejeti iz tunela IPSEC
IP oddaljenega soseda BGP se ne ujema z IP oddaljenim tunelom GRE.

Izmenjava poti BGP

Ko je seja BGP preverjena za oba tunela, zagotovite, da se s strani namenske instance pošiljajo in prejemajo pravilne poti.

Rešitev Dedicated Instance VPN pričakuje, da bosta s strani stranke/partnerja vzpostavljena dva tunela. Prvi tunel kaže na namensko podatkovno središče primerka A, drugi tunel pa kaže na namensko podatkovno središče primerka B. Oba tunela morata biti v aktivnem stanju in rešitev zahteva aktivno/aktivno uvedbo. Vsak podatkovni center namenske instance bo oglaševal svojo lokalno pot /25 kot tudi rezervno pot /24. Ko preverjate dohodne poti BGP iz namenskega primerka, zagotovite, da seja BGP, povezana s tunelom, ki kaže na namensko podatkovno središče primerka A, prejme lokalno pot namenskega primerka podatkovnega središča A /25 kot tudi varnostno pot /24. Poleg tega zagotovite, da tunel, ki kaže na namensko podatkovno središče primerka B, prejme lokalno pot namenskega podatkovnega središča primerka B /25 kot tudi varnostno pot /24. Upoštevajte, da bo varnostna pot /24 ista pot, oglaševana iz podatkovnega središča namenske instance A in namenskega podatkovnega središča primerka B.

Redundanca je zagotovljena podatkovnemu centru namenske instance, če vmesnik tunela do tega podatkovnega centra preneha delovati. Če se povezljivost s podatkovnim središčem namenske instance A izgubi, bo promet posredovan iz podatkovnega središča namenske instance B v podatkovno središče A. V tem scenariju bo tunel do podatkovnega središča B uporabil pot podatkovnega središča B /25 za pošiljanje prometa v podatkovno središče B in tunel v podatkovno središče B bo uporabil rezervno pot /24 za pošiljanje prometa v podatkovno središče A prek podatkovnega središča B.

Ko sta oba tunela aktivna, je pomembno, da se tunel podatkovnega središča A ne uporablja za pošiljanje prometa v podatkovno središče B in obratno. Če je v tem scenariju promet poslan v podatkovno središče A s ciljem podatkovnega središča B, bo podatkovno središče A posredovalo promet v podatkovno središče B, nato pa bo podatkovno središče B poskušalo poslati promet nazaj v vir prek tunela podatkovnega središča B. To bo povzročilo neoptimalno usmerjanje in lahko tudi prekine požarne zidove, ki prečkajo promet. Zato je pomembno, da sta med normalnim delovanjem oba tunela v konfiguraciji aktivno/aktivno.

Pot 0.0.0.0/0 mora biti oglaševana s strani stranke na stran podatkovnega središča namenske instance. Stran namenske instance ne bo sprejela bolj specifičnih poti. Prepričajte se, da je pot 0.0.0.0/0 oglaševana tako iz tunela namenskega podatkovnega središča primerka A kot tudi iz tunela namenskega podatkovnega središča B primerka.

Konfiguracija MTU

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

Tunel GRE prilagodi funkcijo MSS in pot tunela GRE v funkciji odkrivanja MTU je omogočena na strani namenskega primerka. Konfigurirajte »ip tcp adjust-mss 1350« ali enakovreden ukaz kot tudi »tunnel path\u0002mtu-discovery« ali enakovreden ukaz na strani stranke za pomoč pri dinamičnem prilagajanju MTU prometa skozi tunel VPN.