Virtual Connect používá dvouvrstvou architekturu headend, kde směrování a řídicí roviny GRE jsou poskytovány jedním zařízením a řídicí rovina 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 datovými centry Cisco Ded icated Instance. Jeden do každého redundantního datového centra v rámci příslušného regionu. Další síťové prvky potřebné pro peering jsou partnerem nebo zákazníkem vyměněny společností Cisco prostřednictvím aktivačního formuláře Control Hub Virtual Connect.

Níže uvedený obrázek ukazuje příklad modelu nasazení virtuálního připojení pro možnost 2-koncentrátoru na straně zákazníka.

Virtual Connect - VPN je design centra, kde jsou Hubové stránky zákazníka připojeny k DC1 a DC2 datových center dedikované instance v určité oblasti.

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

Očekává se, že partneři budou úzce spolupracovat se zákazníky a zajistit, aby byla vybr ána nejoptimálnější cesta pro oblast služeb Virtual Connect.

Níže uvedený obrázek ukazuje oblasti peering cloudového připojení Dedicated Instance.

Směrování pro doplněk Virtual Connect je implementováno pomocí externího BGP (eBGP) mezi Dedicated Instance a Customer Premise Equipment (CPE). Společnost Cisco bude inzerovat svou příslušnou síť pro každý redundantní DC v rámci regionu na CPE zákazníka a CPE je povinen inzerovat výchozí trasu do společnosti Cisco.

• Cisco udržuje a přiřazuje

  • Adresování IP rozhraní tunelu (přechodné spojení pro směrování) Cisco přiřadí z určeného sdíleného adresního prostoru (neveřejně směrovatelný)

  • Desitinační adresa pro tunelovou dopravu (strana Cisco)

  • Privátní autonomní systémová čísla (ASN) pro konfiguraci směrování BGP zákazníka

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

• EBGP slouží k výměně tras mezi dedikovanou instancí a CPE

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

  • Ve Virtual Connect je každá síť /25 inzerována zpět na CPE společností Cisco přes příslušné tunely VPN point-to-point (přechodné spojení)

  • 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, jeden směřující ke každému vzdálenému tunelu. Pokud používáte dva CPE, pak každý CPE bude mít jednoho souseda eBGP, který se připojuje k jedinému vzdálenému tunelu pro CPE.

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

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

  • CPE je podle potřeby odpovědný za přerozdělování naučených tras v podnikové síti zákazníka.

• V případě selhání spojení bez selhání bude mít jeden CPE dva aktivní/aktivní tunely. U dvou uzlů CPE bude mít každý CPE jeden aktivní tunel a oba uzly CPE by měly být aktivní a procházející provozem. Při scénáři bez selhání se provoz musí rozdělit na dva tunely směřující ke správným cílům /25, pokud jeden z tunelů spadne, zbývající tunel může nést provoz pro oba. V takovém scénáři selhání, když je síť /25 mimo provoz, použije se síť /24 jako záložní cesta. Cisco posílá zákaznický provoz prostřednictvím své interní sítě WAN směrem k DC, který ztratil konektivitu.

Vyjednávání tunelu IPsec zahrnuje dvě fáze, fázi IKEv2 a fázi IPsec. Pokud se vyjednávání fáze IKEv2 nedokončí, nedojde k zahájení druhé fáze IPsec. Nejprve vydejte 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 nespustí tunel IPsec.

• Seznam přístupu k tunelu IPsec je nesprávně nakonfigurován.

• Mezi zákazníkem a IP koncového bodu tunelu IPsec dedikované instance neexistuje žádná konektivita.

• Parametry relace IKEv2 se neshodují mezi stranou vyhrazené instance a stranou zákazníka.

• Firewall blokuje pakety UDP IKEv2.

Nejprve zkontrolujte protokoly IPsec, zda neobsahují zprávy, které ukazují průběh vyjednávání tunelu IKEv2. Protokoly mohou naznačovat, kde je problém s vyjednáváním IKEv2. Nedostatek protokolovacích 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í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ž se používá šifra „GCM“, protokol GCM zpracovává autentizaci a nastaví parametr ověřování na NULL.

  • Ověřte nastavení životnosti.

  • Ověřte skupinu modulů Diffie Hellmana.

  • Ověřte nastavení Pseudo Random Function.

• Přístupový seznam pro krypto mapu 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)

    Přístupový seznam musí být specificky pro protokol „GRE“ a protokol „IP“ nebude fungovat.

Pokud zprávy protokolu nezobrazují žádnou vyjednávací aktivitu pro fázi IKEv2, pak může být zapotřebí zachycení paketů.

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

• GRE se pohybuje od rozhraní tunelu GRE na straně CPE do rozhraní tunelu GRE na straně vyhrazené instance.

• Relace TCP sousedního BGP od souseda BGP na straně CPE k sousedovi BGP na straně Dedicated Instance.

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

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

Pokud je pro přenos IKEv2 zapotřebí trasování paketů, nastavte filtr pro UDP a buď port 500 (pokud není uprostřed koncových bodů protokolu IPsec žádné zařízení NAT), nebo port 4500 (když je zařízení NAT vloženo uprostřed koncových bodů IPsec).

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

Před řešením potíží s druhou fází protokolu 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 k ověření relace IKEv2. Ve výstupu ověřte, zda relace IKEv2 byla spuštěna déle než několik sekund a že se neodráží. Provozní doba relace se ve výstupu zobrazuje jako „Aktivní čas“ relace nebo ekvivalent relace.

Jakmile se relace IKEv2 ověří jako aktivní, prozkoumejte relaci IPsec. Stejně jako u relace IKEv2 proveďte příkaz „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 protokoly IPsec, zda neobsahují chybové zprávy nebo chyby vyjednávání.

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

Nastavení na straně CPE neodpovídají straně Dedicated Instance, znovu zkontrolujte nastavení:

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

• Ověřte nastavení Perfect Forward Secrecy a zda se shodují nastavení na straně Dedicated Instance.

• Ověřte nastavení životnosti.

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

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

Když jsou relace IPSec a IKEv2 ověřeny jako aktivní, pakety tunelu GRE keepalive mohou proudit mezi koncovými body tunelu Dedicated Instance a CPE tunelu. Pokud rozhraní tunelu nezobrazuje stav, některé běžné problémy jsou následující:

• VRF přenosu rozhraní tunelu neodpovídá VRF rozhraní zpětné smyčky (pokud je na rozhraní tunelu použita konfigurace VRF).

  Pokud není v rozhraní tunelu použita konfigurace VRF, lze tuto kontrolu ignorovat.

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

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

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

• 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 pakety GRE odeslané 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 rozhraní místního tunelu v provozu a zda je připojení k rozhraní vzdáleného tunelu dobré. Proveďte kontrolu ping z IP tunelu (nikoli přenosové IP) na vzdálenou IP tunelu.

Výsledkem kontroly ping je paket GRE, který je generován z IP přenosu zdrojového tunelu do IP přenosu cílového tunelu, zatímco užitečným zatížením paketu GRE (vnitřní IP) bude zdrojová a cílová IP tunelu.

Pokud test ping není úspěšný a předchozí položky jsou ověřeny, pak může být vyžadováno zachycení paketu, aby se zajistilo, že ping icmp vede k paketu GRE, který je poté 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 jsou pakety odesílání a přijímání přírůstků.

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

Na straně Dedicated Instance jsou povoleny dvě funkce, které dynamicky upravují MTU pro velké velikosti paketů. Tunel GRE přidává další hlavičky k paketům IP protékajícím relací VPN. Tunel IPsec přidává další záhlaví na záhlaví GRE, což dále sníží největší povolenou MTU nad tunelem.

Tunel GRE upravuje funkci MSS a cesta tunelu GRE ve funkci zjišťování MTU je povolena na straně Dedicated Instance. Nakonfigurujte „ip tcp just-mss 1350" nebo ekvivalentní příkaz, jakož i „tunnel path\ u0002mtu-discovery“ nebo ekvivalentní příkaz na straně zákazníka, abyste pomohli s dynamickým nastavením MTU provozu tunelem VPN.