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

Než odešlete peeringovou žádost o virtuální připojení, ujistěte se, ž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.

Obrázek 1 ukazuje příklad modelu nasazení Virtual Connect pro možnost 2 koncentrátorů 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 zajistí, aby byla zvolena nejoptimálnější cesta pro oblast služby "Virtual Connect".

Obrázek 2 ukazuje oblasti partnerského vztahu cloudového připojení vyhrazených instancí.

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. Kolegové z 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í protokolu IPSEC v první fázi (vyjednávání IKEv2)

Jednání o tunelu IPSEC zahrnuje dvě fáze, fázi IKEv2 a fázi IPSEC. Pokud vyjednávání fáze IKEv2 není dokončeno, pak není zahájena druhá fáze IPSEC. Nejprve zadejte příkaz "show crypto ikev2 sa" (na zařízení Cisco) nebo podobný příkaz na zařízení třetí strany, abyste ověřili, zda je relace IKEV2 aktivní. Pokud relace IKEv2 není aktivní, potenciální důvody mohou být:

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

  • Seznam přístupu k tunelu IPSEC je špatně nakonfigurován.

  • Mezi zákazníkem a IP tunelového koncového bodu IPSEC vyhrazené instance není připojení.

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

  • Firewall blokuje IKEv2 UDP pakety.

Nejprve si v protokolech IPSEC prohlédněte všechny zprávy, které ukazují průběh vyjednávání tunelu IKEv2. Protokoly mohou naznačovat, kde je problém s jednáním IKEv2. Nedostatek protokolovacích zpráv může také naznačovat, ž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ídají straně Cisco, znovu zkontrolujte uvedená nastavení:

    • Zkontrolujte, zda je verze IKE verze 2.

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

      Když je používána šifra „GCM“, protokol GCM zpracovává ověřování a nastavuje parametr ověřování na hodnotu NULL.

    • Ověřte nastavení životnosti.

    • Ověřte skupinu modulů Diffie Hellman.

    • Ověřte nastavení pseudo náhodné funkce.

  • Seznam přístupu pro mapu šifrování není nastaven na:

    • Povolit 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 určen konkrétně pro protokol GRE a protokol IP nebude fungovat.

Pokud zprávy protokolu nezobrazují žádnou vyjednávací aktivitu pro fázi IKEv2, může být zapotřebí 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 strany CPE pro následující předpoklady pro zahájení relace IKEv2:

  • Zkontrolujte seznam přístupu k šifrování IPSEC pro provoz GRE (protokol 50) z IP tunelového přenosu CPE do IP tunelového přenosu vyhrazené instance.

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

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

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

  • GRE keepalives z CPE bočního tunelového rozhraní GRE na straně vyhrazené instance.

  • Relace TCP souseda protokolu BGP ze souseda protokolu BGP na straně CPE souseda protokolu BGP na straně vyhrazené instance.

  • Ping z adresy IP bočního tunelu CPE na adresu IP bočního tunelu vyhrazené instance.

    Ping nemůže být tunelový transport IP na tunelový transport IP, musí to být tunel IP na tunel IP.

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

Ověřte, že pakety IKEV2 UDP s portem 500 nebo 4500 jsou odesílány a přijímány na adresu IP a z ní DI IPSEC.

Datové centrum vyhrazené instance nemusí vždy spustit první paket IKEV2. Požadavek je, aby zařízení CPE bylo schopno iniciovat první paket IKEV2 směrem ke straně vyhrazené instance.

Pokud to místní firewall umožňuje, zkuste také příkaz ping na vzdálenou adresu IPSEC. Pokud příkaz ping neproběhne z místní adresy na vzdálenou IPSEC, proveďte trasování, abyste pomohli, a určete, kde je paket upuštěn.

Některé brány firewall a internetové vybavení nemusí umožňovat sledování trasy.

Řešení problémů a ověřování protokolu IPSEC ve druhé fázi (vyjednávání protokolu IPSEC)

Před řešením potíží s druhou fází IPSEC ověřte, zda je aktivní první fáze IPSEC (tj. bezpečnostní asociace IKEv2). Proveďte "show crypto ikev2 sa" nebo ekvivalentní příkaz k ověření relace IKEV2. Ve výstupu ověřte, že relace IKEv2 byla na více než několik sekund a že není skákání. Doba provozuschopnosti relace se zobrazí ve výstupu jako „aktivní čas“ relace nebo ekvivalent.

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

Některé z nejčastějších problémů, se kterými se mohou během jednání IPSEC setkat, jsou:

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

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

  • Ověřte nastavení Perfect Forward Secrecy a shodu nastavení na straně vyhrazené instance.

  • Ověřte nastavení životnosti.

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

  • Ověřte zdrojové a cílové adresy IPSEC.

Řešení potíží s tunelovým rozhraním a ověření

Když jsou relace IPSEC a IKEv2 ověřeny jako aktivní a aktivní, pakety tunelu GRE mohou proudit mezi koncovými body vyhrazené instance a tunelu CPE. Pokud se rozhraní tunelu nezobrazuje stav, jsou některé běžné problémy:

  • Transportní VRF tunelového rozhraní neodpovídá VRF rozhraní loopback (pokud je v tunelovém rozhraní použita konfigurace VRF).

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

  • Keepalives nejsou povoleny na rozhraní bočního tunelu CPE

    Pokud keepalives nejsou podporovány na zařízení CPE, musí být upozorněna společnost Cisco, aby byly zakázány také výchozí keepalives na straně vyhrazené instance.

    Pokud jsou keepalives podporovány, ověřte, zda jsou keepalives povoleny.

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

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

  • Firewall blokuje GRE pakety odesílané do tunelu IPSEC nebo přijaté z tunelu IPSEC (tunel GRE je přenášen přes tunel IPSEC)

Test ping by měl ověřit, zda je místní rozhraní tunelu funkční a zda je dobré připojení ke vzdálenému rozhraní tunelu. Proveďte kontrolu ping z IP tunelu (ne transportní IP) do vzdálené IP tunelu.

Seznam přístupu k šifrování pro tunel IPSEC, který nese tunelový provoz GRE, umožňuje křížení pouze paketů GRE. V důsledku toho nebudou pingy fungovat od IP tunelového přenosu do IP vzdáleného tunelového přenosu.

Výsledkem kontroly ping je GRE paket, který je generován ze zdrojové IP tunelové transportní IP do cílové IP tunelové transportní IP, zatímco payload GRE paketu (vnitřní IP) bude IP zdrojové a cílové tunelové IP.

Pokud test ping není úspěšný a předchozí položky jsou ověřeny, pak může být vyžadován záznam paketu, aby bylo zajištěno, že icmp ping vede k GRE paketu, který je pak zapouzdřen do paketu IPSEC a poté odeslán ze zdrojové adresy IPSEC na cílovou adresu IPSEC. Čítače na rozhraní tunelu GRE a čítače relací IPSEC mohou také pomoci zobrazit. pokud se zvyšují odesílání a příjem paketů.

Kromě ping provozu, zachycení by mělo také ukázat keepalive GRE pakety i během nečinného provozu. Nakonec, pokud je nakonfigurován protokol BGP, pakety BGP keepalive by měly být také odesílány jako pakety GRE zapouzdřené v paketech IPSEC i přes VPN.

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

Relace BGP

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

Pokud je tunel GRE nahoře, ověřte, zda je mezi místní a vzdálenou IP tunel úspěšný ping. Pokud je ping úspěšný, ale relace BGP se neobjeví, prošetřte protokol BGP pro chyby při založení BGP.

Některé z běžnějších otázek vyjednávání BGP jsou:

  • Vzdálené číslo AS neodpovídá číslu AS nakonfigurovanému na straně vyhrazené instance. Znovu zkontrolujte konfiguraci AS souseda.

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

  • Brána firewall blokuje pakety BGP TCP zapouzdřené v paketech GRE z odesílání do tunelu IPSEC nebo příjmu z tunelu IPSEC

  • Vzdálená IP souseda protokolu BGP neodpovídá vzdálené IP tunelu GRE.

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

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

Řešení VPN vyhrazené instance očekává vytvoření dvou tunelů ze strany zákazníka/partnera. První tunel ukazuje na datové centrum vyhrazené instance A a druhý tunel 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 BGP z vyhrazené instance se ujistěte, že relace BGP přidružená k tunelu ukazujícímu na datové centrum vyhrazené instance A obdrží místní trasu vyhrazené instance A /25 a také záložní trasu /24. Kromě toho se ujistěte, že tunel ukazující na datové centrum vyhrazené instance B obdrží místní trasu datového centra vyhrazené instance B /25 a také záložní trasu /24. Všimněte si, že trasa zálohování /24 bude stejná trasa inzerovaná z datového centra vyhrazené instance A a datového centra vyhrazené instance B.

Pokud rozhraní tunelu s tímto datovým centrem klesne, je datacentru vyhrazené instance poskytnuta redundance. 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 odeslání provozu do datového centra B a tunel do datového centra B použije záložní trasu /24 k odeslá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í, nepoužívalo se datové centrum A tunel k přenosu provozu do datového centra B a naopak. V tomto scénáři, pokud je provoz odeslán do datacentra A s cílem datacentra B, datacentrum A předá provoz do datacentra B a poté se datacentrum B pokusí poslat provoz zpět do zdroje prostřednictvím tunelu datacentra B. To bude mít za následek suboptimální směrování a může také naruš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 inzerována ze strany zákazníka na stranu datového centra vyhrazené instance. Konkrétnější trasy nebudou na straně vyhrazené instance přijaty. Ujistěte se, že trasa 0.0.0/0 je inzerována jak z tunelu vyhrazené instance A, tak z tunelu vyhrazené instance B.

Nastavení MTU

Na straně vyhrazené instance jsou povoleny dvě funkce pro dynamickou úpravu MTU pro velké velikosti paketů. Tunel GRE přidává do paketů IP, které procházejí relací VPN, další záhlaví. Tunel IPSEC přidá další záhlaví nad GRE záhlaví a dále sníží největší MTU povolenou nad tunelem.

Tunel GRE upravuje funkci MSS a cesta tunelu GRE ve funkci zjišťování MTU je povolena na straně vyhrazené instance. Nakonfigurujte "ip tcp adjust-mss 1350" nebo ekvivalentní příkaz, stejně jako "tunel path\u0002mtu-discovery" nebo ekvivalentní příkaz na straně zákazníka, aby pomohl s dynamickým nastavením MTU provozu tunelem VPN.