Uvod

Virtual Connect je dodatna možnost dodatka za povezljivost v oblaku z namenskim primerkom za klicanje Webex (namenski primerek). Virtual Connect omogoča strankam, da varno razširijo svoje zasebno omrežje prek interneta z uporabo IP VPN tunelov od točke do točke. Ta možnost povezljivosti omogoča hitro vzpostavitev povezave z zasebnim omrežjem z uporabo obstoječe opreme za uporabnike (CPE) in internetne povezave.

Cisco gosti, upravlja in zagotavlja odvečne predore IP VPN in zahtevani dostop do interneta v Ciscovih regijah podatkovnih središč namenskih primerkov, kjer je storitev potrebna. Podobno je skrbnik odgovoren za ustrezne CPE in internetne storitve, ki so potrebne za vzpostavitev virtualne povezave.

Vsako naročilo navidezne povezave v določeni regiji namenskega primerka bi vključevalo dva tunela za generično usmerjanje (GRE), zaščitena s šifriranjem IPSec (GRE over IPSec), po enega do vsakega Ciscovega podatkovnega centra 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 predora VPN od točke do točke, mora ves promet v oblak iti skozi CPE na postaji stranke, zato morda ni primeren tam, kjer je veliko oddaljenih mest. Za druge alternativne možnosti peeringa glejte Povezljivostv oblaku.


 

Preden pošljete zahtevo za enakovredno povezavo za navidezno povezavo, se prepričajte, da je storitev namenskega primerka aktivirana v zadevni regiji.

Predpogoji

Predpogoji za vzpostavitev navidezne povezave vključujejo:

  • Stranka zagotavlja

    • Internetna povezava z zadostno pasovno širino, ki je na voljo za podporo uvajanju

    • Javni naslovi IP za dva tunela IPSec

    • Prenosni IP naslovi GRE na strani stranke za dva predora GRE

  • Partner in stranka

    • Sodelujte pri ocenjevanju zahtev glede pasovne širine

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

  • Partner ali stranka zagotavlja

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

    • Mrežna ekipa z poznavanjem BGP, eBGP in splošnih principov usmerjanja

  • Cisco

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

    • Cisco je dodelil javno, vendar ne internetno usmerljivo omrežje razreda C (/24) za naslavljanje namenskega primerka 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 CPE napravi, nato pa se mora vsaka naprava CPE povezati z 1 tunelom samo 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čeni fizični lokaciji / lokaciji znotraj infrastrukture stranke.

Tehnični podatki

Model uvajanja

Virtual Connect uporablja dvostopenjsko arhitekturo glavne postaje, kjer usmerjanje in GRE krmilne ravnine zagotavlja ena naprava, krmilno ravnino IPSec pa druga.

Po zaključku povezljivosti Virtual Connect bosta ustvarjena dva tunela GRE preko IPSec med poslovnim omrežjem stranke in podatkovnimi centri Cisco. Ena za vsako odvečno podatkovno središče v ustrezni regiji. Dodatne omrežne elemente, potrebne za peering, partner ali stranka zamenja s Ciscom prek obrazca za aktivacijo Control Hub Virtual Connect.

Slika 1 prikazuje primer modela uvajanja navidezne povezave za možnost 2 koncentratorja na strani stranke.

Virtual Connect - VPN je zasnova vozlišča, kjer so spletna mesta središča stranke povezana z DC1 in DC2 podatkovnih centrov namenske instance v določeni regiji.

Za boljšo redundanco sta priporočeni dve mesti vozlišča, vendar je podprt model uvajanja tudi eno središče z dvema predoroma.


 

Pasovna širina na predor je omejena na 250 Mbps.


 

Strankina oddaljena mesta v isti regiji bi se morala povezati nazaj s spletnimi mesti vozlišč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 storitve »Virtual Connect«.

Slika 2 prikazuje območja peering povezljivosti v oblaku namenskega primerka.

Usmerjanje

Dodatek Usmerjanje za navidezno povezavo se izvaja z zunanjim BGP (eBGP) med namenskim primerkom in opremo CPE (Customer Premise Equipment). Cisco bo oglaševal svoje omrežje za vsako odvečno enosmerno omrežje v regiji do strankinega CPE, 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 (ki ni javno usmerljivo)

    • Naslov za odstranitev prometa v predoru (Ciscova stran)

    • Zasebne avtonomne sistemske številke (ASN) za konfiguracijo usmerjanja BGP stranke

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

  • eBGP se uporablja za izmenjavo poti med namenskim primerkom in CPE

    • Cisco bo dodeljeno omrežje /24 razdelil na 2/25 za vsak DC v ustrezni regiji

    • V navidezni povezavi Cisco vsako omrežje /25 oglašuje nazaj CPE prek ustreznih tunelov VPN od točke do točke (prehodna povezava)

    • CPE mora biti konfiguriran z ustreznimi sosednjimi eBGP. Če uporabljate en CPE, bosta uporabljena dva soseda eBGP, ena kaže na vsak oddaljeni tunel. Če uporabljate dva CPE, bo vsak CPE imel enega soseda eBGP, ki se bo pridružil enemu oddaljenemu tunelu za CPE.

    • Cisco stran vsakega predora GRE (IP vmesnika tunela) je konfigurirana kot soseda BGP na CPE

    • CPE je potreben za oglaševanje privzete poti v vsakem od predorov

    • CPE je odgovoren za prerazporeditev, kot je potrebno, naučenih poti znotraj podjetniškega omrežja uporabnika.

  • V pogoju brez okvare povezave bo en CPE imel dva aktivna/aktivna tunela. Za dve vozlišči CPE bo vsak CPE imel en aktivni tunel in obe vozlišči CPE morata biti aktivni in prehajati promet. V scenariju brez okvare se mora promet razdeliti na dva predora, ki gredo do pravilnih /25 ciljev, če se eden od predorov pokvari, lahko preostali predor prenese promet za oba. V takšnem scenariju napake, ko omrežje /25 ne deluje, se omrežje /24 uporabi kot varnostna pot. Cisco bo poslal promet strank prek svojega notranjega omrežja WAN proti DC, ki je izgubil povezljivost.

Postopek povezljivosti

V spodnjih korakih na visoki ravni je opisano, kako vzpostavite povezljivost z navidezno povezavo za namenski primerek.
1

Oddaja naročila v Cisco CCW

2

Aktivirajte navidezno povezavo iz nadzornega središča

3

Cisco izvede konfiguracijo omrežja

4

Stranka izvede konfiguracijo omrežja

1. korak: Odredba CCW

Virtual Connect je dodatek za namenski primerek v CCW.

1

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

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

Ustvarite oceno.

3

Dodajte SKU »A-FLEX-3«.

4

Izberite Možnosti urejanja.

5

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

6

V razdelku Dodatni dodatki potrdite polje poleg »Navidezna povezava za namenski primerek«. Ime SKU je »A-FLEX-DI-VC«.

7

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


 
Količina navidezne povezave ne sme presegati skupnega števila regij, kupljenih za namenski primerek. Prav tako je na regijo dovoljeno samo eno naročilo Virtual Connect.
8

Ko ste zadovoljni z izbirami, kliknite Preveri in shrani v zgornjem desnem kotu strani.

9

Kliknite Shrani in nadaljuj, da dokončate naročilo. Vaše končno naročilo se zdaj prikaže v mreži naročil.

2. korak: Aktiviranje navidezne povezave v nadzornem središču

1

Vpišite se v Control Hub https://admin.webex.com/login.

2

V razdelku Storitve se pomaknite do možnosti Klicanje > namenski inštitut > povezljivostv oblaku.

3

Na kartici Virtual Connect je navedena kupljena količina Virtual Connect. Skrbnik lahko zdaj klikne Aktiviraj , da sproži aktivacijo navidezne povezave.


 
Postopek aktiviranja lahko sprožijo samo skrbniki z vlogo »polnega skrbnika stranke«. Skrbnik z vlogo »Skrbnik samo za branje« si lahko ogleda samo stanje.
4

Ko kliknete gumb Aktiviraj , se prikaže obrazec Aktiviraj navidezno povezavo , na katerem lahko skrbnik navede tehnične podrobnosti o navidezni povezavi, ki so potrebne za konfiguracije enakovrednega povezovanja na strani Cisca.


 
Obrazec vsebuje tudi statične informacije na strani Cisco, ki temeljijo na izbrani regiji. Te informacije bodo koristne za skrbnike strank, da konfigurirajo CPE na svoji strani za vzpostavitev povezljivosti.

  1. IP naslovprenosa predora GRE: Stranka mora navesti naslove IP prenosa predora na strani stranke, Cisco pa bo dinamično dodelil naslove IP, ko bo aktivacija končana. IPSec ACL za zanimiv promet bi moral omogočiti lokalni predorski promet IP/32 na oddaljeni predorski promet IP/32. ACL mora določati samo protokol GRE IP.


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

  2. VrstnikiIPSec: Stranka mora navesti izvorne naslove IP predora IPSec, Cisco pa dodeli ciljni naslov IP predora IPSec. Po potrebi je podprt tudi prevod NAT notranjega naslova tunela IPSEC na javni naslov.


     

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


     
    Vse druge statične informacije, ki so na voljo na zaslonu za aktivacijo, so Ciscovi varnostni standardi in standardi šifriranja, ki jih upoštevamo. Te statične konfiguracije ni mogoče prilagoditi ali spremeniti. Za kakršno koli nadaljnjo pomoč v zvezi s statičnimi konfiguracijami na strani Cisca bi se morala stranka obrniti na TAC.
5

Kliknite gumb Aktiviraj , ko so vsa obvezna polja izpolnjena.

6

Ko je obrazec za aktivacijo navidezne povezave izpolnjen za določeno regijo, lahko stranka izvozi obrazec za aktivacijo iz nadzornega središča, zavihka Klicanje > namenski primerek > povezljivost v oblaku in klikne Izvozi nastavitve.


 
Zaradi varnostnih razlogov preverjanje pristnosti in geslo BGP ne bosta na voljo v izvoženem dokumentu, vendar si lahko skrbnik ogleda enako v nadzornem središču tako, da klikne Ogled nastavitev v Control Hub, Klicanje > namenski primerek > zavihek Povezljivost v oblaku.

3. korak: Cisco izvede konfiguracijo omrežja

1

Ko je obrazec za aktivacijo navidezne povezave izpolnjen, bo stanje posodobljeno v Aktivacija v teku v kartici Klicanje > namenski primerek > navidezno povezavo za povezljivost v oblaku.

2

Cisco bo v 5 delovnih dnehdokončal zahtevane konfiguracije na Ciscovi stranski opremi . Po uspešnem zaključku bo stanje posodobljeno na »Aktivirano« za določeno regijo v nadzornem središču.

4. korak: Stranka izvede konfiguracijo omrežja

Stanje se spremeni v »Aktivirano«, da se strankinega skrbnika obvesti, da je Ciscova stran konfiguracij za povezljivost IP VPN dokončana na podlagi vnosov, ki jih je posredovala stranka. Vendar pa se pričakuje, da bo skrbnik stranke dokončal svojo stran konfiguracij na CPE in preizkusil poti povezljivosti za tunel Virtual Connect, da je na spletu. V primeru kakršnih koli težav, s katerimi se srečuje v času konfiguracije ali povezljivosti, se lahko stranka za pomoč obrne na Cisco TAC.

Odpravljanje težav

Odpravljanje težav in preverjanje delovanja prve faze protokola IPsec (pogajanje IKEv2)

Pogajanja v tunelu IPsec vključujejo dve fazi, fazo IKEv2 in fazo IPsec. Če se pogajanja v fazi IKEv2 ne zaključijo, se druga faza IPsec ne začne. Najprej izdajte ukaz »pokaži kripto ikev2 sa« (na opremi Cisco) ali podoben ukaz na opremi drugih proizvajalcev, da preverite, ali je seja IKEv2 aktivna. Če seja IKEv2 ni aktivna, so lahko možni razlogi:

  • Zanimiv promet ne sproži tunela IPsec.

  • Seznam dostopa do tunela IPsec je napačno konfiguriran.

  • Med stranko in IP končne točke tunela IPsec namenskega primerka ni povezave.

  • Parametri seje IKEv2 se ne ujemajo med namenskim primerkom in stranko.

  • Požarni zid blokira pakete UDP IKEv2.

Najprej preverite, ali so v dnevnikih IPsec sporočila, ki prikazujejo napredek pogajanj o tunelu IKEv2. V dnevnikih je lahko navedeno, kje je prišlo do težave s pogajanji IKEv2. Pomanjkanje sporočil o pisanju dnevnika 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 strani Cisco, ponovno preverite omenjene nastavitve:

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

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


       

      Ko je šifra »GCM« v uporabi, protokol GCM obravnava preverjanje pristnosti in nastavi parameter preverjanja pristnosti na NULL.

    • Preverite nastavitev življenjske dobe.

    • Preverite skupino modulov Diffie Hellman.

    • Preverite nastavitve funkcije Pseudo Random.

  • Seznam dostopa za kripto zemljevid ni nastavljen na:

    • Dovoli 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 dnevniška sporočila ne prikazujejo nobene pogajalske dejavnosti za fazo IKEv2, bo morda potreben zajem paketov.


 

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

Preverite konfiguracijo CPE za naslednje zahteve za začetek seje IKEv2:

  • Preverite seznam dostopa do kriptovalut IPsec za promet GRE (protokol 50) od IP-ja za prenos predora CPE do IP prenosa predora namenske instance.

  • Prepričajte se, da je vmesnik predora GRE omogočen za vzdrževanje GRE, če oprema ne podpira vzdrževanja GRE, je Cisco obveščen, ker bodo zadrževalci GRE privzeto omogočeni na strani namenskega primerka.

  • Prepričajte se, da je protokol BGP omogočen in konfiguriran s sosednjim naslovom IP tunela namenskega primerka.

Če je pravilno konfiguriran, se začne tunel IPsec in pogajanja v prvi fazi IKEv2:

  • GRE ohranja od vmesnika predora GRE na strani CPE do vmesnika predora GRE na strani namenske instance.

  • Seja TCP soseda BGP od soseda BGP na strani CPE do soseda BGP na strani namenskega primerka.

  • Ping z naslova IP stranskega predora CPE na naslov IP stranskega predora namenskega primerka.


     

    Ping ne more biti IP prenosa predora do IP prenosa predora, mora biti IP predora do IP predora.

Če je za promet IKEv2 potrebno sledenje paketom, nastavite filter za UDP in vrata 500 (ko nobena naprava NAT ni na sredini končnih točk IPsec) ali vrata 4500 (ko je naprava NAT vstavljena na sredino končnih točk IPsec).

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


 

Podatkovno središče namenskega primerka morda ne bo vedno začelo s prvim paketom IKEv2. Zahteva je, da je naprava CPE sposobna sprožiti prvi paket IKEv2 proti strani namenskega primerka.

Če lokalni požarni zid to dovoljuje, poskusite tudi pingati na oddaljeni naslov IPsec. Če ping ni uspešen z lokalnega na oddaljeni naslov IPsec, izvedite pot sledenja za pomoč in določite, kje je paket spuščen.

Nekateri požarni zidovi in internetna oprema morda ne omogočajo sledenja.

Druga faza protokola IPsec (pogajanje o protokolu IPsec) – odpravljanje težav in preverjanje veljavnosti

Preverite, ali je prva faza IPsec (to je varnostna povezava IKEv2) aktivna, preden odpravite težave z drugo fazo IPsec. Izvedite »pokaži kripto ikev2 sa« ali enakovreden ukaz, da preverite sejo IKEv2. V izhodu preverite, ali je seja IKEv2 vzpostavljena več kot nekaj sekund in ali se ne odbija. Čas delovanja seje je prikazan kot »Aktivni čas« seje ali enakovreden izhodu.

Ko je seja IKEv2 preverjena kot aktivna, raziščite sejo IPsec. Tako kot pri seji IKEv2 izvedite »pokaži kripto ipsec sa« ali enakovreden ukaz, da preverite sejo IPsec. Seja IKEv2 in seja IPsec morata biti aktivna, preden je tunel GRE vzpostavljen. Če seja IPsec ni prikazana kot aktivna, preverite, ali so v dnevnikih IPsec sporočila o napakah ali napake pri pogajanjih.

Nekatera najpogostejša vprašanja, s katerimi se lahko srečamo med pogajanji o IPsec, so:

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

  • Preverite, ali se parametra šifriranja in preverjanja pristnosti ujemata z nastavitvami na strani namenskega primerka.

  • Preverite nastavitve popolne tajnosti posredovanja in nastavitve ujemanja na strani namenskega primerka.

  • Preverite nastavitve življenjske dobe.

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

  • Preverite izvorni in ciljni naslov IPsec.

Odpravljanje težav z vmesnikom tunela in preverjanje veljavnosti

Ko so seje IPsec in IKEv2 preverjene kot aktivne, lahko paketi tunela GRE tečejo med namenskim primerkom in končnimi točkami tunela CPE. Če se stanje vmesnika tunela ne prikaže, so nekatere pogoste težave:

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


     

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

  • Keepalives niso omogočeni na vmesniku stranskega predora CPE


     

    Če vzdrževanje ni podprto na opremi CPE, je treba o tem obvestiti Cisco, da se onemogočijo tudi privzete ohranitve na strani namenskega primerka.

    Če so keepalives podprti, preverite, ali so keepalives omogočeni.

  • Maska ali naslov IP vmesnika tunela ni pravilen in se ne ujema s pričakovanimi vrednostmi namenskega primerka.

  • Izvorni ali ciljni prenosni naslov predora ni pravilen in se ne ujema s pričakovanimi vrednostmi namenskega primerka.

  • Požarni zid blokira pakete GRE, ki so poslani v tunel IPsec ali prejeti iz tunela IPsec (tunel GRE se prenaša prek tunela IPsec)

Test ping mora preveriti, ali je vmesnik lokalnega predora vzpostavljen in ali je povezljivost z oddaljenim vmesnikom tunela dobra. Izvedite preverjanje pinga od IP tunela (ne prenosnega IP-ja) do IP oddaljenega tunela.


 

Seznam kripto dostopa za predor IPsec, ki prenaša promet predora GRE, omogoča prečkanje samo paketov GRE. Posledično pingi ne bodo delovali od IP prenosa predora do IP oddaljenega prenosa predora.

Preverjanje pinga povzroči paket GRE, ki se ustvari iz izvornega prenosnega IP tunela do ciljnega transportnega IP predora, medtem ko bo koristni tovor paketa GRE (notranji IP) izvorni in ciljni IP predora.

Če test ping ni uspešen in so preverjeni prejšnji elementi, je morda potrebno zajemanje paketov, da se zagotovi, da je rezultat pinga icmp paket GRE, ki se nato inkapsulira v paket IPsec in nato pošlje iz izvornega naslova IPsec na ciljni naslov IPsec. Števci na vmesniku predora GRE in števci sej IPsec lahko prav tako pomagajo pri prikazu. če se paketi za pošiljanje in prejemanje povečujejo.

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

Odpravljanje težav in preverjanje veljavnosti protokola BGP

Seje BGP

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

Če je predor GRE navzgor, preverite, ali je ping uspešen med lokalnim in oddaljenim IP-jem predora GRE. Če je ping uspešen, vendar seja BGP ne prihaja, raziščite dnevnik BGP za napake pri vzpostavitvi protokola BGP.

Nekatera najpogostejša vprašanja pogajanj o 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 pričakovanji na strani Določeni primerek, preverite, ali se lokalna številka AS ujema s pričakovanimi parametri namenskega primerka.

  • Požarni zid blokira pošiljanje paketov BGP TCP, ki so zajeti v pakete GRE, v tunel IPsec ali sprejemanje iz tunela IPSEC

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

BGP izmenjava poti

Ko je seja BGP preverjena za oba tunela, se prepričajte, da so s strani namenskega primerka poslane in prejete pravilne poti.

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

Redundanca je zagotovljena podatkovnemu središču namenskega primerka, če vmesnik tunela do tega podatkovnega središča pade. Če se povezava s podatkovnim središčem namenskega primerka A prekine, bo promet posredovan iz podatkovnega središča B namenskega primerka v podatkovno središče A. V tem scenariju bo predor do podatkovnega centra B uporabil pot podatkovnega centra B/25 za pošiljanje prometa v podatkovni center B, predor do podatkovnega centra B pa bo uporabil varnostno kopijo /24 za pošiljanje prometa v podatkovni center A prek podatkovnega centra B.

Pomembno je, da se predor podatkovnega središča A, ko sta oba predora aktivna, ne uporablja za pošiljanje prometa v podatkovno središče B in obratno. Če je v tem primeru 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 prekini promet, ki prečka požarne zidove. Zato je pomembno, da sta oba predora med normalnim delovanjem v aktivni / aktivni konfiguraciji.

Pot 0.0.0.0/0 je treba oglaševati s strani stranke na stran podatkovnega središča namenskega primerka. Bolj specifične poti ne bodo sprejete na strani namenske instance. Prepričajte se, da je pot 0.0.0.0/0 oglaševana iz tunela A podatkovnega središča namenskega primerka in tunela B podatkovnega središča namenskega primerka.

Konfiguracija MTU

Na strani namenskega primerka 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 dodaja dodatne glave na vrhu glav GRE, kar bo še dodatno zmanjšalo največji MTU, ki je dovoljen nad predorom.

Predor GRE prilagodi funkcijo MSS, pot predora GRE v funkciji odkrivanja MTU pa je omogočena na strani namenskega primerka. Konfigurirajte »ip tcp adjust-mss 1350« ali enakovreden ukaz ter »tunnel path\u0002mtu-discovery« ali enakovreden ukaz na strani stranke, da boste pomagali pri dinamičnem prilagajanju MTU prometa skozi tunel VPN.