Virtual Connect korzysta z podwójnej architektury nagłówka, w której samoloty sterujące trasowaniem i GRE są dostarczane przez jedno urządzenie, a płaszczyzna sterująca IPSec jest dostarczana przez inne.

Po zakończeniu połączenia Virtual Connect zostaną utworzone dwa tunele GRE over IPSec między siecią firmową klienta a centrum danych dedykowanego wystąpienia firmy Cisco. Jeden do każdego zbędnego centrum danych w danym Regionie. Dodatkowe elementy sieci niezbędne do nawiązywania połączeń są wymieniane przez Partnera lub Klienta na Cisco za pośrednictwem formularza aktywacyjnego Control Hub Virtual Connect.

Na rysunku 1 przedstawiono przykład modelu wdrożenia usługi Virtual Connect dla opcji 2-koncentratora po stronie klienta.

Virtual Connect — VPN to projekt Hub, w którym witryny Hub Klienta są połączone z DC1 i DC2 centrów danych dedykowanego wystąpienia w danym regionie.

Dla lepszej redundancji zalecane są dwie witryny Hub, ale jedna witryna Hub z dwoma tunelami jest również obsługiwanym modelem wdrażania.

Przepustowość jednego tunelu jest ograniczona do 250 Mb/s.

Zdalne witryny Klienta w tym samym regionie musiałyby połączyć się z witryną Hub za pośrednictwem sieci WAN Klienta i nie jest to odpowiedzialność firmy Cisco za tę łączność.

Oczekuje się, że partnerzy będą ściśle współpracować z Klientami, zapewniając wybór najbardziej optymalnej ścieżki dla regionu usług „Virtual Connect”.

Rysunek 2 przedstawia regiony peering dedykowanego wystąpienia Cloud Connectivity.

Routing dla dodatku Virtual Connect jest wdrażany przy użyciu zewnętrznego BGP (eBGP) między dedykowanym wystąpieniem a urządzeniem premisyjnym klienta (CPE). Firma Cisco będzie reklamować swoją sieć dla każdego zbędnego prądu stałego w regionie w CPE Klienta, a CPE jest wymagane do reklamowania domyślnej trasy do firmy Cisco.

• Cisco utrzymuje i przypisuje

  • Adresowanie IP interfejsu tunelu (przejściowe łącze do trasowania) Przypisywanie Cisco z wyznaczonego obszaru udostępnionego adresu (niepublicznego routingu)

  • Adres dezynfekcji transportu tunelu (po stronie Cisco)

  • Prywatne autonomiczne numery systemu (ASN) dla konfiguracji trasowania BGP klienta

    • Cisco przypisuje z wyznaczonego zakresu zastosowań prywatnych: 64512 do 65534

• eBGP używane do wymiany tras między dedykowanym wystąpieniem a CPE

  • Cisco rozdzieli przypisaną sieć /24 na 2/25 dla każdego prądu stałego w danym regionie

  • W Virtual Connect każda sieć /25 jest reklamowana z powrotem do CPE przez firmę Cisco za pośrednictwem odpowiednich tuneli VPN typu punkt-punkt (łącze przejściowe)

  • CPE musi być skonfigurowany z odpowiednimi sąsiadami eBGP. W przypadku korzystania z jednego CPE, będą używane dwa sąsiedzi eBGP, jeden wskazujący na każdy zdalny tunel. W przypadku korzystania z dwóch CPE, każdy CPE będzie miał jednego sąsiada eBGP ponawiając do pojedynczego tunelu zdalnego dla CPE.

  • Strona Cisco każdego tunelu GRE (interfejs IP tunelu) jest skonfigurowana jako sąsiad BGP w CPE

  • Protokół CPE jest wymagany do reklamowania domyślnej trasy nad każdym z tuneli

  • CPE odpowiada za redystrybucję, zgodnie z wymaganiami, wyuczonych tras w sieci korporacyjnej cutomera.

• W przypadku braku nieudanego połączenia pojedynczy moduł CPE będzie wyposażony w dwa aktywne/aktywne tunele. W przypadku dwóch węzłów CPE każdy węzeł CPE będzie miał jeden aktywny tunel, a oba węzły CPE powinny być aktywne i ruch mijania. Zgodnie ze scenariuszem braku awarii ruch musi zostać podzielony na dwa tunele zmierzające do właściwych /25 miejsc docelowych, jeśli jeden z tuneli schodzi w dół, pozostały tunel może przewozić ruch dla obu. W przypadku takiego scenariusza awarii, gdy sieć /25 jest wyłączona, wtedy sieć /24 jest używana jako trasa rezerwowa. Firma Cisco będzie wysyłać ruch klientów za pośrednictwem wewnętrznego sieci WAN do centrum dystrybucji, które utraciło łączność.

Negocjacje w tunelu IPsec obejmują dwie fazy: fazę IKEv2 i fazę IPsec. Jeśli negocjacje fazy IKEv2 nie zakończą się, nie zostanie rozpoczęta druga faza IPsec. Najpierw wydaj polecenie „Pokaż krypto ikev2 sa” (na urządzeniach Cisco) lub podobne polecenie na urządzeniach innych firm w celu sprawdzenia, czy sesja IKEv2 jest aktywna. Jeśli sesja IKEv2 nie jest aktywna, potencjalne przyczyny mogą być następujące:

• Ciekawy ruch nie uruchamia tunelu IPsec.

• Lista dostępu do tunelu IPsec jest nieprawidłowo skonfigurowana.

• Nie ma połączenia między klientem a interfejsem IP tunelu IPsec dedykowanego wystąpienia.

• Parametry sesji IKEv2 nie są zgodne między stroną dedykowanego wystąpienia a stroną klienta.

• Zapora blokuje pakiety IKEv2 UDP.

Najpierw sprawdź dzienniki IPsec dla wszelkich komunikatów pokazujących postęp negocjacji tunelu IKEv2. Dzienniki mogą wskazywać, gdzie występuje problem z negocjacjami IKEv2. Brak wiadomości logowania może również wskazywać, że sesja IKEv2 nie jest aktywowana.

Niektóre typowe błędy podczas negocjacji IKEv2 to:

• Ustawienia IKEv2 po stronie CPE nie są zgodne z ustawieniami Cisco. Sprawdź ponownie wymienione ustawienia:

  • Sprawdź, czy wersja IKE to wersja 2.

  • Sprawdź, czy parametry szyfrowania i uwierzytelniania są zgodne z oczekiwanym szyfrowaniem po stronie dedykowanego wystąpienia.

    Gdy jest używany szyfr "GCM", protokół GCM obsługuje uwierzytelnianie i ustawia parametr uwierzytelniania na NULL.

  • Sprawdź ustawienie żywotności.

  • Zweryfikuj grupę modułową Diffie Hellman.

  • Sprawdź ustawienia funkcji losowej Pseudo.

• Lista dostępu do mapy kryptograficznej nie jest ustawiona na:

  • Zezwolenie GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (lub równoważne polecenie)

    Lista dostępu musi być przeznaczona specjalnie dla protokołu „GRE”, a protokół „IP” nie będzie działać.

Jeśli komunikaty dziennika nie pokazują żadnej aktywności negocjacyjnej dla fazy IKEv2, może być konieczne przechwytywanie pakietów.

Strona dedykowanego wystąpienia nie zawsze może rozpocząć wymianę IKEv2 i czasami może oczekiwać, że strona CPE klienta będzie inicjatorem. Sprawdź konfigurację boczną CPE pod kątem następujących warunków wstępnych inicjowania sesji IKEv2: Sprawdź listę dostępu do krypto protokołu IPsec dla ruchu GRE (protokół 50) od IP transportu tunelowego CPE do IP transportu tunelowego dedykowanego wystąpienia. Upewnij się, że interfejs tunelu GRE jest włączony dla keepalives GRE, jeśli urządzenie nie obsługuje keepalives GRE, to Cisco jest powiadamiany, ponieważ keepalives GRE będą włączone po stronie dedykowanego wystąpienia domyślnie. Upewnij się, że BGP jest włączone i skonfigurowane z adresem sąsiednim tunelu dedykowanego wystąpienia IP.

Po prawidłowym skonfigurowaniu rozpoczyna się tunel IPsec i pierwsza faza negocjacji IKEv2:

• Keepalives GRE z interfejsu tunelu GRE po stronie CPE do interfejsu tunelu GRE po stronie dedykowanego wystąpienia.

• Sąsiad BGP Sesja TCP od sąsiada BGP po stronie CPE do sąsiada BGP po stronie dedykowanego wystąpienia.

• Ping z adresu IP tunelu bocznego CPE do adresu IP tunelu bocznego dedykowanego wystąpienia.

  Ping nie może być transport tunelu IP do transportu tunelu IP, musi być tunel IP do tunelu IP.

Jeśli dla ruchu IKEv2 potrzebny jest ślad pakietów, ustaw filtr UDP i albo port 500 (gdy żadne urządzenie NAT nie znajduje się w środku punktów końcowych IPsec), albo port 4500 (gdy urządzenie NAT jest umieszczone w środku punktów końcowych IPsec).

Sprawdź, czy pakiety UDP IKEv2 z portem 500 lub 4500 są wysyłane i odbierane z adresu IP protokołu DI IPsec.

Podmiot danych dedykowanego wystąpienia nie zawsze może rozpocząć pierwszy pakiet IKEv2. Wymaganiem jest, aby urządzenie CPE mogło zainicjować pierwszy pakiet IKEv2 w kierunku strony dedykowanego wystąpienia. Jeśli lokalna zapora na to zezwala, wykonaj również próbę ping na zdalny adres IPsec. Jeśli ping nie odniesie sukcesu z adresu lokalnego do zdalnego IPsec, wykonaj trasę śledzenia, aby pomóc i określ, gdzie pakiet jest upuszczany. Niektóre zapory i sprzęt internetowy mogą nie zezwalać na trasę śladu.

Sprawdź, czy pierwsza faza protokołu IPsec (czyli stowarzyszenie zabezpieczeń IKEv2) jest aktywna przed rozwiązaniem problemu z drugą fazą protokołu IPsec. Wykonaj polecenie „Pokaż krypto ikev2 sa” lub równoważne, aby zweryfikować sesję IKEv2. Na wyjściu sprawdź, czy sesja IKEv2 trwa dłużej niż kilka sekund i że nie odbija się. Czas trwania sesji jest wyświetlany jako sesja „Aktywny czas” lub równoważny w wyjściu.

Po zweryfikowaniu i uaktywnieniu sesji IKEv2 należy Zbadać sesję IPsec. Podobnie jak w przypadku sesji IKEv2 wykonaj polecenie „Pokaż krypto ipsec sa” lub równoważne, aby zweryfikować sesję IPsec. Zarówno sesja IKEv2, jak i sesja IPsec muszą być aktywne przed utworzeniem tunelu GRE. Jeśli sesja IPsec nie jest wyświetlana jako aktywna, sprawdź dzienniki IPsec pod kątem komunikatów o błędach lub błędów negocjacyjnych.

Niektóre z bardziej powszechnych problemów, z którymi można się spotkać podczas negocjacji protokołu IPsec, to:

Ustawienia po stronie CPE nie są zgodne ze stroną dedykowanego wystąpienia. Sprawdź ponownie ustawienia:

• Sprawdź, czy parametry szyfrowania i uwierzytelniania są zgodne z ustawieniami po stronie dedykowanego wystąpienia.

• Zweryfikuj ustawienia Perfect Forward Secrecy i dopasuj ustawienia po stronie Dedykowane wystąpienie.

• Sprawdź ustawienia żywotności.

• Sprawdź, czy protokół IPsec został skonfigurowany w trybie tunelu.

• Sprawdź adresy IPsec źródła i miejsca docelowego.

Gdy sesje IPsec i IKEv2 zostaną zweryfikowane jako aktywne, pakiety GRE keepalive tunelu mogą przepływać między dedykowanym wystąpieniem a punktami końcowymi tunelu CPE. Jeśli interfejs tunelu nie jest wyświetlany stan, do niektórych typowych problemów należą:

• Transport interfejsu tunelu VRF nie odpowiada VRF interfejsu loopback (jeśli konfiguracja VRF jest używana w interfejsie tunelu).

  Jeśli konfiguracja VRF nie jest używana w interfejsie tunelu, sprawdzenie to można zignorować.

• Keepalives nie są włączone w interfejsie tunelu bocznego CPE

  Jeśli w sprzęcie CPE nie są obsługiwane keepalify, należy powiadomić o tym firmę Cisco, aby również wyłączone były domyślne keepalify po stronie dedykowanego wystąpienia. Jeśli obsługiwane są keepalives, sprawdź, czy są włączone keepalives.

• Maska lub adres IP interfejsu tunelu jest nieprawidłowy i nie odpowiada oczekiwanym wartościom dedykowanego wystąpienia.

• Adres transportu tunelu źródłowego lub docelowego jest nieprawidłowy i nie odpowiada oczekiwanym wartościom Dedykowanego wystąpienia.

• Zapora blokuje pakiety GRE przed wysłaniem do tunelu IPsec lub odebraniem z tunelu IPsec (tunel GRE jest transportowany przez tunel IPsec)

Test ping powinien sprawdzić, czy lokalny interfejs tunelu jest w górze, a łączność jest dobra w zdalnym interfejsie tunelu. Przeprowadź kontrolę ping z IP tunelu (nie IP transportu) do zdalnego IP tunelu.

Lista dostępu do krypto dla tunelu IPsec, który przewozi ruch tunelu GRE, umożliwia tylko przesyłanie pakietów GRE. W rezultacie pings nie będzie działać od transportu tunelowego IP do zdalnego transportu tunelowego IP.

Kontrola ping powoduje, że pakiet GRE jest generowany z transportu tunelu źródłowego IP do transportu tunelu docelowego IP, podczas gdy ładunek pakietu GRE (wewnętrznego IP) będzie źródłem i docelowym IP tunelu.

Jeśli test ping nie powiódł się, a poprzednie elementy zostaną zweryfikowane, może być wymagane przechwytywanie pakietów, aby upewnić się, że w wyniku odrywania pakietów GRE zostanie wbudowany pakiet IPsec, a następnie wysłany ze źródłowego adresu IPsec do docelowego adresu IPsec. Liczniki na interfejsie tunelu GRE i liczniki sesji IPsec mogą również pomóc w wyświetleniu. jeśli pakiety wysyłania i odbierania są przyrostowe.

Oprócz ruchu ping, przechwytywanie powinno również pokazać keepalive pakiety GRE nawet podczas ruchu bezczynnego. Wreszcie, jeśli skonfigurowano BGP, pakiety keepalive BGP powinny być również wysyłane jako pakiety GRE zamknięte w pakietach IPSEC, a także przez VPN.

Po stronie dedykowanego wystąpienia dwie funkcje umożliwiają dynamiczną regulację MTU dla dużych rozmiarów pakietów. Tunel GRE dodaje więcej nagłówków do pakietów IP przepływających przez sesję VPN. Tunel IPsec dodaje dodatkowe nagłówki na górze nagłówków GRE jeszcze bardziej zmniejszy największy MTU dozwolony przez tunel.

Tunel GRE dostosowuje funkcję MSS i ścieżka tunelu GRE w funkcji wykrywania MTU jest włączona po stronie dedykowanego wystąpienia. Skonfiguruj "ip tcp adjust-mss 1350" lub równoważne polecenie, a także "ścieżka tunelu\u0002mtu-discovery" lub równoważne polecenie po stronie klienta, aby pomóc w dynamicznej regulacji ruchu MTU przez tunel VPN.