Úvod

Virtual Connect je další možnost doplňku pro připojení cloudu k vyhrazené instanci pro volání Webex (vyhrazená instance). Služba Virtual Connect umožňuje zákazníkům bezpečně rozšířit privátní síť přes internet pomocí tunelů VPN typu point-to-point IP. Tato možnost připojení poskytuje rychlé navázání připojení k privátní síti pomocí stávajícího zařízení CPE (Customer Premise Equipment) a připojení k internetu.

Společnost Cisco hostuje, spravuje a zajišťuje redundantní tunely IP VPN a požadovaný přístup k Internetu v oblastech datacentra vyhrazené instance společnosti Cisco, kde je služba vyžadována. Podobně je administrátor zodpovědný za odpovídající CPE a internetové služby, které jsou vyžadovány pro zřízení Virtual Connect.

Každá objednávka virtuálního připojení v konkrétní oblasti vyhrazené instance by zahrnovala dva tunely GRE (Generic Routing Encapsulation) chráněné šifrováním IPSec (GRE over IPSec), jeden do každého datacentra společnosti Cisco ve vybrané oblasti.

Virtual Connect má limit šířky pásma 250 Mb/s na tunel a doporučuje se pro menší nasazení. Vzhledem k tomu, že se používají dva tunely VPN typu point-to-point, veškerý provoz do cloudu musí projít zákaznickým headendem CPE, a proto nemusí být vhodný tam, kde je mnoho vzdálených míst. Další alternativní možnosti partnerského vztahu najdete v tématu připojení ke cloudu.

Před odesláním požadavku na peeringové připojení pro virtuální připojení se ujistěte, že je v dané oblasti aktivována služba vyhrazené instance.

Požadavky

Mezi předpoklady pro vytvoření služby Virtual Connect patří:

  • Zákazník poskytuje

    • Připojení k Internetu s dostatečnou dostupnou šířkou pásma pro podporu nasazení

    • Veřejné IP adresy pro dva tunely IPSec

    • IP adresy GRE pro přenos na straně zákazníka pro dva tunely GRE

  • Partner a zákazník

    • Spolupráce při vyhodnocování požadavků na šířku pásma

    • Zajistěte, aby síťová zařízení podporovala směrování protokolu BGP (Border Gateway Protocol) a návrh tunelového propojení GRE přes IPSec

  • Partner nebo zákazník poskytuje

    • Síťový tým se znalostí technologií VPN tunelů typu site-to-site

    • Síťový tým se znalostí BGP, eBGP a obecných principů směrování

  • Cisco

    • Společnost Cisco přiřadila rozhraní tunelového propojení GRE privátní čísla automatických systémů (ASN) a přechodné adresování IP

    • Společnost Cisco přiřadila veřejnou, ale ne internetovou směrovatelnou síť třídy C (/24) pro adresování dedicated Instance Cloud

Pokud má zákazník pouze 1 zařízení CPE, budou 2 tunely směrem k datovým centrům společnosti Cisco (DC1 a DC2) v každé oblasti z tohoto zařízení CPE. Zákazník má také možnost pro 2 zařízení CPE, pak by se každé zařízení CPE mělo připojit k 1 tunelu pouze směrem k datovým centrům společnosti Cisco (DC1 a DC2) v každé oblasti. Další redundance lze dosáhnout ukončením každého tunelu v samostatné fyzické lokalitě/umístění v rámci infrastruktury zákazníka.

Technické údaje

Model nasazení

Virtual Connect používá dvouvrstvou architekturu předávacího objektu, kde směrovací a řídicí roviny GRE jsou poskytovány jedním zařízením a řídicí rovina protokolu IPSec je poskytována jiným zařízením.

Po dokončení připojení Virtual Connect budou vytvořeny dva tunely GRE přes IPSec mezi podnikovou sítí zákazníka a vyhrazenou instancí datových center Cisco. Jedno pro každé redundantní datové centrum v rámci příslušné oblasti. Další síťové prvky potřebné pro partnerský vztah vyměňuje partner nebo zákazník společnosti Cisco prostřednictvím aktivačního formuláře Control Hub Virtual Connect.

Na následujícím obrázku je znázorněn příklad modelu nasazení virtuálního připojení pro možnost 2-koncentrátoru na straně zákazníka.

Virtual Connect - VPN je návrh rozbočovače, kde jsou lokality rozbočovače zákazníka připojeny k DC1 a DC2 datových center vyhrazené instance v rámci konkrétní oblasti.

Pro lepší redundanci se doporučují dvě centrální lokality, ale jedna centrální lokalita se dvěma tunely je také podporovaným modelem nasazení.

Šířka pásma na tunel je omezena na 250 Mb/s.

Vzdálená pracoviště zákazníka ve stejné oblasti by se musela připojit zpět k lokalitám centra přes síť WAN zákazníka a za toto připojení není odpovědná společnost Cisco.

Očekává se, že partneři budou úzce spolupracovat se zákazníky a že pro oblast služby Virtual Connect bude zvolena nejoptimálnější cesta.

Na následujícím obrázku jsou znázorněny peeringové oblasti připojení ke cloudu vyhrazené instance.

Oblasti virtuálního připojení

Směrování

Směrování pro doplněk Virtual Connect je implementováno pomocí externího protokolu BGP (eBGP) mezi vyhrazenou instancí a zařízením CPE (Customer Premise Equipment). Společnost Cisco bude inzerovat svou příslušnou síť pro každý redundantní řadič domény v rámci oblasti CPE zákazníka a CPE je povinna inzerovat výchozí trasu do společnosti Cisco.

  • Společnost Cisco udržuje a přiřazuje

    • Ip adresování tunelového rozhraní (přechodná linka pro směrování) Cisco přiřazuje z určeného sdíleného adresního prostoru (neveřejně směrovatelného)

    • Adresa pro popisování tunelového přenosu (strana Cisco)

    • Čísla privátních autonomních systémů (ASN) pro konfiguraci směrování protokolu BGP zákazníka

      • Společnost Cisco přiřazuje z určeného rozsahu soukromého použití: 64512 až 65534

  • eBGP používaný k výměně tras mezi vyhrazenou instancí a CPE

    • Cisco rozdělí přiřazenou síť /24 na 2 /25 pro každý řadič domény v příslušné oblasti

    • Ve službě Virtual Connect je každá síť /25 inzerována zpět do CPE společností Cisco prostřednictvím příslušných tunelů VPN typu point-to-point (přechodná linka)

    • CPE musí být nakonfigurován s příslušnými sousedy eBGP. Pokud používáte jeden CPE, použijí se dva sousedé eBGP, z nichž jeden ukazuje na každý vzdálený tunel. Pokud používáte dva CPE, pak každý CPE bude mít jednoho souseda eBGP, který se připojí k jedinému vzdálenému tunelu pro CPE.

    • Cisco strana každého tunelu GRE (IP rozhraní tunelového propojení) je nakonfigurována jako soused protokolu BGP na CPE

    • CPE je vyžadováno k inzerci výchozí trasy přes každý z tunelů

    • CPE je zodpovědná za redistribuci naučených tras v rámci podnikové sítě cutomeru podle potřeby.

  • V případě selhání linky bez selhání bude mít jeden CPE dva aktivní/aktivní tunely. Pro dva uzly CPE bude mít každý CPE jeden aktivní tunel a oba uzly CPE by měly být aktivní a předávající provoz. Ve scénáři bez selhání musí být provoz rozdělen do dvou tunelů směřujících do správných cílů /25, pokud jeden z tunelů klesne, zbývající tunel může přenášet provoz pro oba. V takovém scénáři selhání, když je síť /25 mimo provoz, pak se síť /24 použije jako záložní trasa. Cisco bude posílat zákaznický provoz prostřednictvím své interní wan směrem k řadiči domény, který ztratil připojení.

Proces připojení

Následující kroky vysoké úrovně popisují, jak vytvořit připojení pomocí virtuálního připojení pro vyhrazenou instanci.
1

Zadat objednávku v Cisco CCW

2

Aktivace služby Virtual Connect z Control Hubu

3

Cisco provádí konfiguraci sítě

4

Zákazník provádí konfiguraci sítě

Krok 1: Objednávka CCW

Virtual Connect je doplněk pro Dedicated Instance v CCW.

1

Přejděte na objednávkový web CCW a kliknutím na tlačítko Přihlásit se přihlaste k webu:

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

Vytvořit odhad.

3

Přidejte SKU "A-FLEX-3".

4

Vyberte Možnosti úprav.

5

Na kartě předplatného, která se zobrazí, vyberte Možnosti a Doplňky.

6

V části Další doplňky zaškrtněte políčko vedle položky "Virtual Connect for Dedicated Instance". Název SKU je "A-FLEX-DI-VC".

7

Zadejte množství a počet oblastí, ve kterých je služba Virtual Connect vyžadována.

Množství Služby Virtual Connect by nemělo překročit celkový počet oblastí zakoupených pro vyhrazenou instanci. V každé oblasti je také povolena pouze jedna objednávka služby Virtual Connect.
8

Až budete s výběrem spokojeni, klikněte na Ověřit a uložit v pravé horní části stránky.

9

Kliknutím na tlačítko Uložit a pokračovat dokončete objednávku. Vaše dokončená objednávka se nyní nachází v mřížce objednávek.

Krok 2: Aktivace Virtual Connect v Control Hubu

1

Přihlaste se k Centru řízení https://admin.webex.com/login.

2

V části Služby přejděte na Volání > Vyhrazené připojení instacnce > cloudu.

3

Na kartě Virtual Connect je uvedeno zakoupené množství Virtual Connect. Správce nyní může kliknutím na tlačítko Aktivovat zahájit aktivaci Virtual Connect.

Proces aktivace mohou aktivovat pouze správci s rolí "Úplný správce zákazníka". Zatímco správce s rolí "Správce jen pro čtení zákazníka" může zobrazit pouze stav.
4

Po kliknutí na tlačítko Aktivovat se zobrazí formulář Aktivovat virtual Connect , ve kterém správce poskytne technické podrobnosti o virtual Connect vyžadované pro konfigurace partnerského vztahu na straně společnosti Cisco.

Formulář také poskytuje statické informace na straně společnosti Cisco na základě vybrané oblasti. Tyto informace budou užitečné pro správce zákazníků při konfiguraci CPE na jejich straně pro navázání připojení.

  1. IP adresa tunelového přenosu GRE: Zákazník je povinen poskytnout ADRESy IP adresy tunnel transportu na straně zákazníka a společnost Cisco dynamicky přidělí ADRESY IP po dokončení aktivace. Seznam IPSec ACL pro zajímavý provoz by měl umožnit místní přenos tunelu IP/32 na vzdálený přenos tunelu IP/32. Seznam ACL by měl také specifikovat pouze protokol GRE IP.

    IP adresa poskytnutá zákazníkem může být soukromá nebo veřejná.

  2. Vrstevníci IPSec: Zákazník je povinen zadat zdrojové adresy IP tunelu IPSec a společnost Cisco přidělí cílovou adresu IPSec. V případě potřeby je také podporováno provedení překladu interní adresy tunelového propojení IPSEC na veřejnou adresu.

    IP adresa poskytnutá zákazníkem by měla být veřejná.

    Všechny ostatní statické informace uvedené na aktivační obrazovce jsou dodržovány bezpečnostní a šifrovací standardy společnosti Cisco. Tato statická konfigurace není přizpůsobitelná ani upravitelná. Pro jakoukoli další pomoc týkající se statických konfigurací na straně společnosti Cisco by se zákazník musel obrátit na TAC.
5

Po vyplnění všech povinných polí klikněte na tlačítko Aktivovat .

6

Po vyplnění formuláře Aktivace služby Virtual Connect pro oblast particluar může zákazník exportovat aktivační formulář z Control Hubu, volání > vyhrazenou instanci > kartu Připojení ke cloudu a kliknout na nastavení exportu.

Z bezpečnostních důvodů nebudou v exportovaném dokumentu funkce Ověřování a heslo BGP k dispozici, ale správce si to může zobrazit v prostředí Control Hub, a to kliknutím na možnost Zobrazit nastavení v kartě Control Hub, Volání > Vyhrazená instance > Připojení ke cloudu.

Krok 3: Cisco provádí konfiguraci sítě

1

Po dokončení formuláře Aktivace služby Virtual Connect se stav aktualizuje na Probíhá aktivace při volání > vyhrazené instance > karta Virtual Connect připojení ke cloudu.

2

Společnost Cisco dokončí požadované konfigurace na bočním zařízení společnosti Cisco do 5 pracovních dnů. Po úspěšném dokončení bude stav aktualizován na "Aktivováno" pro danou oblast v Centru řízení.

Krok 4: Zákazník provádí konfiguraci sítě

Stav se změní na "Aktivováno", aby byl správce zákazníka upozorněn, že konfigurace společnosti Cisco pro připojení IP VPN byla dokončena na základě vstupů poskytnutých zákazníkem. Očekává se však, že správce zákazníka dokončí svou stranu konfigurací na CPE a otestuje trasy připojení pro tunel Virtual Connect, aby byl online. V případě jakýchkoli problémů, kterým se zákazník potýká v době konfigurace nebo připojení, se může obrátit na Cisco TAC s žádostí o pomoc.

Řešení potíží

Řešení problémů a ověřování IPsec First Phase (vyjednávání IKEv2)

Vyjednávání tunelu IPsec zahrnuje dvě fáze, fázi IKEv2 a fázi IPsec. Pokud nebude vyjednávání fáze IKEv2 dokončeno, pak nedojde k zahájení druhé fáze IPsec. Nejprve vydejte příkaz „show crypto ikev2 sa“ (v zařízení Cisco) nebo podobný příkaz na zařízení třetí strany k ověření, zda je relace IKEv2 aktivní. Pokud relace IKEv2 není aktivní, mohou být tyto potenciální důvody:

  • Zajímavý provoz nespouští IPsec tunel.

  • Seznam přístupu k tunelu IPsec je nesprávně nakonfigurovaný.

  • Mezi zákazníkem a IP koncovým bodem tunelu IPsec vyhrazené instance není žádné připojení.

  • Parametry relace IKEv2 neodpovídají straně vyhrazené instance a straně zákazníka.

  • Brána firewall blokuje pakety UDP IKEv2.

Nejprve zkontrolujte protokoly IPsec pro všechny zprávy, které ukazují průběh vyjednávání tunelu IKEv2. Protokoly mohou uvádět, kde je problém s vyjednáváním IKEv2. Nedostatek protokolování zpráv může také znamenat, že relace IKEv2 není aktivována.

Některé běžné chyby při vyjednávání IKEv2 jsou:

  • Nastavení pro IKEv2 na straně CPE neodpovídá nastavení Cisco, znovu zkontrolujte uvedená nastavení:

    • Zkontrolujte, zda verze IKE je verze 2.

    • Ověřte, že parametry šifrování a ověřování odpovídají očekávanému šifrování na straně vyhrazené instance.

      Při použití šifrování „GCM“ zpracovává protokol GCM ověřování a nastavuje parametr ověřování na hodnotu NULL.

    • Ověřte nastavení životnosti.

    • Ověřte Diffle Hellmanovu modulovou skupinu.

    • Ověřte nastavení pseudonáhodných funkcí.

  • Seznam přístupu k šifrovací mapě není nastaven na:

    • Permit GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (nebo ekvivalentní příkaz)

      Seznam přístupu musí být specifický pro protokol „GRE“ a protokol „IP“ nebude fungovat.

Pokud zprávy protokolu neukazují pro fázi IKEv2 žádnou vyjednávací aktivitu, může být potřeba zachycení paketů.

Strana vyhrazené instance nemusí vždy zahájit výměnu IKEv2 a někdy může očekávat, že iniciátorem bude strana CPE zákazníka.

Zkontrolujte konfiguraci na straně CPE, zda existují následující předpoklady pro zahájení relace IKEv2:

  • Zkontrolujte přístupový seznam IPsec pro provoz GRE (protokol 50) z IP tunelového přenosu CPE na IP tunelový přenos vyhrazené instance.

  • Ujistěte se, že je pro keepalive GRE povoleno rozhraní tunelu GRE, pokud zařízení nepodporuje keepalive GRE, bude společnost Cisco upozorněna, protože keepalive GRE budou ve výchozím nastavení povoleny na straně vyhrazené instance.

  • Ujistěte se, že je povolen a nakonfigurován protokol BGP s adresou IP tunelu vyhrazené instance.

Při správné konfiguraci začíná tunel IPsec a první fáze vyjednávání IKEv2:

  • Keepalivy GRE z tunelového rozhraní GRE na straně CPE do tunelového rozhraní GRE na straně vyhrazené instance.

  • Relace TCP sousedního serveru BGP od sousedního serveru CPE k sousedovi vyhrazené instance BGP.

  • Příkaz ping z IP adresy tunelu na straně CPE na IP adresu tunelu na straně vyhrazené instance.

    Ping nemůže být IP přenos tunelu na IP přenos tunelu, musí to být IP tunelu na IP přenos.

Pokud je pro provoz IKEv2 potřeba sledování paketů, nastavte filtr pro UDP a port 500 (pokud není uprostřed koncových bodů IPsec žádné zařízení NAT) nebo port 4500 (pokud je uprostřed koncových bodů IPsec vloženo zařízení NAT).

Ověřte, zda jsou pakety UDP IKEv2 s portem 500 nebo 4500 odesílány a přijímány na IPsec IP adresu DI.

Datové centrum vyhrazené instance nemusí vždy začínat první paket IKEv2. Požadavkem je, aby zařízení CPE bylo schopno inicializovat první paket IKEv2 na stranu vyhrazené instance.

Pokud to místní brána firewall umožňuje, zkuste také vyslat příkaz ping na vzdálenou adresu IPsec. Pokud příkaz ping není z místní na vzdálenou adresu IPsec úspěšný, proveďte trasu a určete, kam paket spadl.

Některé firewally a internetové zařízení nemusí umožňovat trasovací trasu.

Druhá fáze řešení problémů a ověřování protokolu IPsec (vyjednávání protokolu IPsec)

Před řešením problémů s druhou fází IPsec ověřte, zda je aktivní první fáze IPsec (tj. přidružení zabezpečení IKEv2). Proveďte příkaz "show crypto ikev2 sa" nebo ekvivalentní příkaz pro ověření relace IKEv2. Na výstupu ověřte, že relace IKEv2 trvá déle než několik sekund a že se nevrací. Doba provozu relace se zobrazí jako „Aktivní čas“ relace nebo její ekvivalent.

Jakmile je relace IKEv2 ověřena jako aktivní a aktivní, prošetřte relaci IPsec. Stejně jako u IKEv2 relace proveďte příkaz "show crypto ipsec sa" nebo ekvivalentní k ověření relace IPsec. Před vytvořením tunelu GRE musí být aktivní relace IKEv2 i IPsec. Pokud se relace IPsec nezobrazí jako aktivní, zkontrolujte, zda neobsahují chybové zprávy a chyby vyjednávání v protokolech IPsec.

Některé z nejčastějších problémů, které se mohou vyskytnout během vyjednávání IPsec, jsou:

Nastavení na straně CPE neodpovídají straně Vyhrazené instance, znovu zkontrolujte nastavení:

  • Ověřte, že parametry šifrování a ověřování odpovídají nastavení na straně vyhrazené instance.

  • Ověřte nastavení Dokonalé přesměrování tajnosti a shoduje se nastavení na straně vyhrazené instance.

  • Ověřte nastavení životnosti.

  • Ověřte, zda byl protokol IPsec nakonfigurován v tunelovém režimu.

  • Ověřte zdrojovou a cílovou adresu IPsec.

Řešení potíží a ověření tunelového rozhraní

Když jsou relace IPsec a IKEv2 ověřeny jako aktivní a aktivní, pakety keepalive tunelu GRE schopné toku mezi koncovými body tunelu vyhrazené instance a CPE. Pokud se v tunelovém rozhraní nezobrazuje stav, jsou zde některé běžné problémy:

  • Přenosový VRF tunelového rozhraní neodpovídá VRF smyčkového rozhraní (pokud je v tunelovém rozhraní použita konfigurace VRF).

    Pokud se konfigurace VRF nepoužívá v tunelovém rozhraní, může být tato kontrola ignorována.

  • V tunelovém rozhraní na straně CPE nejsou povoleny funkce Keefuel

    Pokud funkce keealive nejsou na zařízení CPE podporována, musí být společnost Cisco informována, aby byla zakázána také výchozí funkce keealive na straně vyhrazené instance.

    Pokud jsou podporovány proměnné keepalivy, ověřte, že jsou povoleny.

  • Maska nebo IP adresa tunelového rozhraní není správná a neodpovídá očekávaným hodnotám vyhrazené instance.

  • Adresa zdrojového nebo cílového tunelu není správná a neodpovídá očekávaným hodnotám vyhrazené instance.

  • Brána firewall blokuje pakety GRE odeslané do tunelu IPsec nebo přijaté z tunelu IPsec (tunel GRE je transportován přes tunel IPsec).

Test příkazu ping by měl ověřit, zda je místní tunelové rozhraní zapnuté a zda je připojení dobré pro vzdálené tunelové rozhraní. Proveďte kontrolu ping z IP tunelu (nikoliv IP přenosové) na IP vzdáleného tunelu.

Seznam přístupu k šifrování pro tunel IPsec, který přenáší tunelový provoz GRE, umožňuje křížení pouze paketů GRE. V důsledku toho nebudou funkce pings fungovat z IP tunelového přenosu na IP vzdáleného tunelového přenosu.

Kontrola ping results in a GRE packet, který je generován z IP zdrojového tunelového přenosu na IP cílového tunelu, zatímco payload paketu GRE (vnitřní IP) bude zdrojová a cílová IP adresa tunelu.

Pokud test příkazu ping neproběhne úspěšně a předchozí položky jsou ověřeny, může být vyžadováno zachycení paketu, aby se zajistilo, že příkaz icmp ping je výsledkem paketu GRE, který je pak zapouzdřen do paketu IPsec a odeslán ze zdrojové adresy IPsec na cílovou adresu IPsec. Počítadla v tunelovém rozhraní GRE a počítadla relací IPsec mohou také pomoci zobrazit, zda se inkrementují odesílané a přijímané pakety.

Kromě provozu ping by záznam měl zobrazovat také keepalive pakety GRE i během provozu při nečinnosti. Pokud je konfigurován protokol BGP, pakety keepalive BGP by měly být také odesílány jako pakety GRE zapouzdřené v paketech IPSEC i přes síť VPN.

Řešení potíží a ověřování protokolu BGP

Relace protokolu BGP

BGP je vyžadován jako směrovací protokol přes tunel IPsec sítě VPN. Místní soused protokolu BGP by měl vytvořit relaci eBGP se sousedem vyhrazené instance. Adresy IP sousedů eBGP jsou stejné jako adresy IP místního a vzdáleného tunelu. Nejprve se ujistěte, že je relace BGP spuštěna, a poté ověřte, že jsou ze vyhrazené instance přijaty správné trasy a že je vyhrazené instanci odeslána správná výchozí trasa.

Pokud je tunel GRE nahoře, ověřte, zda je mezi IP místního a vzdáleného tunelu GRE úspěšný příkaz ping. Pokud příkaz ping proběhne úspěšně, ale relace protokolu BGP se neobjeví, prošetřte protokol protokolu BGP kvůli chybám při zřizování protokolu BGP.

Některé z nejčastějších problémů při vyjednávání BGP jsou:

  • Číslo vzdáleného AS neodpovídá číslu AS, které je nakonfigurováno na straně vyhrazené instance, znovu zkontrolujte konfiguraci AS sousedního zařízení.

  • Místní číslo AS neodpovídá očekáváním strany vyhrazené instance. Ověřte, zda místní číslo AS odpovídá očekávaným parametrům vyhrazené instance.

  • Brána firewall blokuje odesílání paketů BGP TCP zapouzdřených v paketech GRE do tunelu IPsec nebo příjem z tunelu IPSEC.

  • Adresa IP vzdáleného souseda protokolu BGP neodpovídá adrese IP vzdáleného tunelu GRE.

Výměna směrování BGP

Po ověření relace BGP pro oba tunely se ujistěte, že jsou ze strany vyhrazené instance odesílány a přijímány správné trasy.

Řešení VPN vyhrazené instance očekává, že ze strany zákazníka/partnera budou zřízeny dva tunely. První tunel ukazuje na datové centrum vyhrazené instance A a druhý tunel ukazuje na datové centrum vyhrazené instance B. Oba tunely musí být v aktivním stavu a řešení vyžaduje aktivní/aktivní nasazení. Každé datové centrum vyhrazené instance bude inzerovat místní trasu /25 a záložní trasu /24. Při kontrole příchozích tras protokolu BGP ze vyhrazené instance se ujistěte, že relace protokolu BGP přidružená k tunelu odkazující na datové centrum vyhrazené instance A obdrží místní trasu datového centra vyhrazené instance A /25 a také záložní trasu /24. Kromě toho zajistěte, aby tunel ukazující na datové centrum vyhrazené instance B obdržel místní trasu datového centra vyhrazené instance B /25 a záložní trasu /24. Povšimněte si, že záložní trasa /24 bude stejná trasa oznámená z datového centra vyhrazené instance A a datového centra vyhrazené instance B.

Pokud tunelové rozhraní k datovému centru vyhrazené instance klesne, je redundance zajištěna. Pokud dojde ke ztrátě připojení k datovému centru vyhrazené instance A, bude provoz přesměrován z datového centra vyhrazené instance B do datového centra A. V tomto scénáři bude tunel do datového centra B používat trasu B /25 k odesílání provozu do datového centra B a tunel do datového centra B použije záložní trasu /24 k odesílání provozu do datového centra A prostřednictvím datového centra B.

Je důležité, aby v případě, že jsou oba tunely aktivní, se tunel A nepoužívá k odesílání provozu do datového centra B a naopak. V tomto scénáři, pokud je provoz odesílán do datového centra A s cílem datového centra B, datové centrum A přesměruje provoz do datového centra B a poté se datové centrum B pokusí odeslat provoz zpět ke zdroji prostřednictvím datového centra B. To povede k špatnému směrování a může také přerušit provoz procházející firewally. Proto je důležité, aby oba tunely byly během normálního provozu v aktivní/aktivní konfiguraci.

Trasa 0.0.0.0/0 musí být oznamována ze strany zákazníka na stranu datového centra vyhrazené instance. Strana vyhrazené instance nebudou přijaty konkrétnější trasy. Zajistěte, aby byla trasa 0.0.0.0/0 oznamována jak z tunelu datového centra vyhrazené instance A, tak z tunelu datového centra vyhrazené instance B.

Nastavení MTU

Na straně vyhrazené instance jsou povoleny dvě funkce, které dynamicky upravují nastavení MTU pro velké velikosti paketů. Tunel GRE přidává další záhlaví do paketů IP procházejících relací sítě VPN. Tunel IPsec přidá další záhlaví k záhlavím GRE, čímž se dále sníží největší hodnota MTU povolená přes tunel.

Tunel GRE upravuje funkci MSS a cesta tunelu GRE v funkci zjišťování MTU je na straně vyhrazené instance povolena. Nakonfigurujte příkaz „ip tcp adjust-mss 1350“ nebo ekvivalentní příkaz a také „tunelová cesta\u0002mtu-discovery“ nebo ekvivalentní příkaz na straně zákazníka, abyste pomohli s dynamickou úpravou MTU provozu tunelem VPN.