Opcja Virtual Connect pomaga w bezpiecznym rozszerzeniu ich prywatnej sieci przez Internet za pomocą tuneli IP VPN punkt-punkt.
Wprowadzenie
Virtual Connect to dodatkowa opcja dla usługi Łączność w chmurze z wystąpieniem dedykowanym dla Webex Calling (wystąpienie dedykowane). Virtual Connect umożliwia klientom bezpieczne rozszerzenie ich sieci prywatnej przez Internet za pomocą tuneli IP VPN typu punkt-punkt. Ta opcja połączenia umożliwia szybkie nawiązanie połączenia z siecią prywatną przy użyciu istniejącego sprzętu CPE i połączenia internetowego.
Cisco hostuje, zarządza i zapewnia nadmiarowe tunele IP VPN oraz wymagany dostęp do Internetu w regionach centrum danych Cisco Dedicated Instance, w których jest wymagana usługa. Podobnie administrator jest odpowiedzialny za odpowiednie usługi CPE i internetowe, które są wymagane do ustanowienia usługi Virtual Connect.
Każde zamówienie usługi Virtual Connect w konkretnym regionie dedykowanego wystąpienia będzie obejmować dwa tunele GRE (generycznej enkapsulacji routingu) chronione przez szyfrowanie IPSec (GRE over IPSec), po jednym do każdego centrum danych Cisco w wybranym regionie.
Virtual Connect ma limit przepustowości 250 Mb/s na tunel i jest zalecany w przypadku mniejszych wdrożeń. Ponieważ używane są dwa tunele VPN typu punkt-punkt, cały ruch do chmury musi przechodzić przez CPE stacji czołowej klienta, dlatego może nie być odpowiedni w przypadku wielu zdalnych lokalizacji. Aby uzyskać informacje o innych alternatywnych opcjach komunikacji równorzędnej, zobacz Łączność z chmurą .
Wymagania wstępne
Wymagania wstępne dotyczące ustanowienia połączenia wirtualnego obejmują:
Klient zapewnia
Połączenie internetowe o przepustowości wystarczającej do obsługi wdrożenia
Publiczne IP dla dwóch tuneli IPSec
Adresy IP transportu GRE po stronie klienta dla dwóch tuneli GRE
Partner i klient
Współpracuj, aby ocenić wymagania dotyczące przepustowości
Upewnij się, że urządzenia sieciowe obsługują routing Border Gateway Protocol (BGP) i projekt tunelu GRE przez IPSec
Partner lub Klient zapewnia
Zespół sieciowy posiadający wiedzę na temat technologii tunelowania VPN typu site-to-site
Zespół sieciowy ze znajomością BGP, eBGP i ogólnych zasad routingu
Cisco
Prywatne numery systemów autonomicznych (ASN) i tymczasowe adresowanie IP dla interfejsów tuneli GRE przypisywane przez firmę Cisco
Publiczna, ale nieroutowalna sieć klasy C (/24) przypisana przez Cisco na potrzeby adresowania w chmurze Dedicated Instance
Jeśli klient ma tylko 1 urządzenie CPE, 2 tunele prowadzące do centrów danych Cisco (DC1 i DC2) w każdym regionie będą pochodzić z tego urządzenia CPE. Klient ma również opcję dla 2 urządzeń CPE, a następnie każde urządzenie CPE powinno łączyć się tylko z 1 tunelem w kierunku centrów danych Cisco (DC1 i DC2) w każdym regionie. Dodatkową nadmiarowość można uzyskać, kończąc każdy tunel w oddzielnej fizycznej lokalizacji/lokalizacji w infrastrukturze Klienta. |
Szczegóły techniczne
Model wdrożenia
Virtual Connect korzysta z dwuwarstwowej architektury stacji czołowej, w której płaszczyzny sterowania routingiem i GRE są dostarczane przez jedno urządzenie, a płaszczyzna sterowania IPSec jest zapewniana przez inne.
Po zakończeniu Połączenie wirtualne Pomiędzy siecią korporacyjną klienta a dedykowanymi centrami danych Cisco zostaną utworzone dwa tunele GRE over IPSec . Po jednym na każde nadmiarowe centrum danych w odpowiednim regionie. Dodatkowe elementy sieciowe wymagane do komunikacji równorzędnej są wymieniane przez partnera lub klienta z Cisco za pośrednictwem formularza aktywacji usługi Control Hub Virtual Connect.
Rysunek 1 przedstawia przykład modelu wdrażania Virtual Connect dla opcji 2 koncentratorów po stronie klienta.

Połączenie wirtualne — VPN to projekt koncentratora, w którym lokalizacje koncentratora klienta są połączone z centrami danych DC1 i DC2 dedykowanego wystąpienia w określonym regionie.
Dla lepszej nadmiarowości zalecane są dwie lokacje centralne, ale jedna lokacja centralna z dwoma tunelami jest również obsługiwanym modelem wdrażania.
Przepustowość na tunel jest ograniczona do 250 Mb/s. |
Zdalne lokalizacje Klienta w tym samym regionie musiałyby ponownie połączyć się z lokalizacjami centralnymi za pośrednictwem sieci WAN Klienta, a firma Cisco nie ponosi odpowiedzialności za tę łączność. |
Od partnerów oczekuje się ścisłej współpracy z klientami, aby zapewnić wybór najbardziej optymalnej ścieżki dla regionu usługi „Virtual Connect”.
Rysunek 2 przedstawia regiony komunikacji równorzędnej usługi Dedicated Instance Cloud Connectivity.

Przekierowanie
Dodatek Routing dla Virtual Connect jest implementowany przy użyciu zewnętrznego protokołu BGP (eBGP) między dedykowanym wystąpieniem a urządzeniem klienta (CPE). Cisco ogłosi odpowiednią sieć dla każdego nadmiarowego kontrolera domeny w regionie na urządzeniu CPE klienta, a urządzenie CPE musi zaanonsować trasę domyślną do Cisco.
Cisco utrzymuje i przypisuje
Adresowanie IP interfejsu tunelu (przejściowe łącze do routingu) przypisywane przez firmę Cisco z wyznaczonej współużytkowanej przestrzeni adresowej (niedostępnej publicznie)
Adres docelowy transportu tunelowego (po stronie Cisco)
Prywatne numery systemów autonomicznych (ASN) do konfiguracji routingu BGP klienta
Cisco przypisuje z wyznaczonego zakresu użytku prywatnego: od 64512 do 65534
Protokół eBGP używany do wymiany tras między wystąpieniem dedykowanym a urządzeniem CPE
Cisco podzieli przypisaną sieć /24 na 2 /25 jedną dla każdego kontrolera domeny w odpowiednim regionie
W Virtual Connect każda sieć /25 jest anonsowana z powrotem do CPE by Cisco przez odpowiednie tunele VPN typu punkt-punkt (łącze przejściowe)
Urządzenie CPE musi być skonfigurowane z odpowiednimi sąsiadami eBGP. W przypadku korzystania z jednego urządzenia CPE zostanie użytych dwóch sąsiadów eBGP, z których jeden wskazuje każdy zdalny tunel. Jeśli używane są dwa urządzenia CPE, każdy CPE będzie miał jednego sąsiada eBGP kierującego do pojedynczego zdalnego tunelu dla urządzenia CPE.
Strona Cisco każdego tunelu GRE ( IP interfejsu tunelu) jest skonfigurowana jako sąsiad BGP na urządzeniu CPE
Urządzenie CPE jest wymagane do anonsowania trasy domyślnej przez każdy z tuneli
CPE jest odpowiedzialne za redystrybucję, zgodnie z wymaganiami, poznanych tras w sieci korporacyjnej klienta.
W warunkach bezawaryjnej awarii łącza pojedynczy sprzęt CPE będzie miał dwa aktywne/aktywne tunele. W przypadku dwóch węzłów CPE każdy CPE będzie miał jeden aktywny tunel, a oba węzły CPE powinny być aktywne i przepuszczać ruch. W scenariuszu bez awarii ruch musi zostać podzielony na dwa tunele prowadzące do właściwych miejsc docelowych /25. Jeśli jeden z tuneli ulegnie awarii, pozostały tunel może przenosić ruch dla obu. W takim scenariuszu awarii, gdy sieć /25 nie działa, sieć /24 jest używana jako trasa zapasowa. Cisco będzie przesyłać ruch klientów przez wewnętrzną sieć WAN do kontrolera domeny, który utracił łączność.
Proces połączenia
1 | |
2 | |
3 | |
4 |
Krok 1: Polecenie CCW
Virtual Connect to dodatek dla wystąpienia dedykowanego w CCW.
1 | Przejdź do witryny zamawiania CCW, a następnie kliknij przycisk Zaloguj, aby zalogować się do witryny: |
||
2 | Utwórz oszacowanie. |
||
3 | Dodaj jednostkę SKU „A-FLEX-3”. |
||
4 | Wybierz pozycję Edytuj opcje. |
||
5 | Na wyświetlonej karcie subskrypcji wybierz opcje i dodatki. |
||
6 | W obszarze Dodatkowe dodatki zaznacz pole wyboru obok opcji „Połączenie wirtualne dla wystąpienia dedykowanego”. Nazwa SKU to „A-FLEX-DI-VC”. |
||
7 | Wprowadź liczbę i liczbę regionów, w których wymagane jest połączenie wirtualne.
|
||
8 | Po dokonaniu wyboru kliknij opcję Zweryfikuj i zapisz w prawej górnej części strony. |
||
9 | Kliknij przycisk Zapisz i kontynuuj, aby sfinalizować zamówienie. Sfinalizowane zamówienie pojawi się teraz w siatce zamówień. |
Krok 2: Aktywacja Virtual Connect w Control Hub
1 | Zaloguj się do Control Hubhttps://admin.webex.com/login . |
||
2 | W Usługi sekcja, przejdź do Nawiązywanie połączeń > Wydzielone wystąpienie > Łączność z chmurą . |
||
3 | Na karcie Virtual Connect wymieniona jest zakupiona liczba Virtual Connect. Administrator może teraz kliknąć Aktywuj aby zainicjować aktywację usługi Virtual Connect. ![]()
|
||
4 | Po kliknięciu przycisku Aktywuj przycisk, Aktywuj połączenie wirtualne Zostanie wyświetlony formularz, aby administrator mógł podać szczegóły techniczne Virtual Connect wymagane do konfiguracji komunikacji równorzędnej po stronie Cisco.
|
||
5 | Kliknij przycisk Aktywuj po wypełnieniu wszystkich obowiązkowych pól. |
||
6 | Po wypełnieniu formularza aktywacji połączenia wirtualnego dla określonego regionu, klient może wyeksportować formularz aktywacji z Control Hub na karcie Połączenia > Dedykowane wystąpienie > Łączność z chmurą i kliknąć Ustawienia eksportu. ![]()
|
Krok 3: Cisco przeprowadza konfigurację sieci
1 | Po wypełnieniu formularza aktywacji usługi Virtual Connect stan zostanie zaktualizowany do Aktywacja w toku na karcie Połączenia > Wydzielone wystąpienie > Cloud Connectivity Virtual Connect card. |
2 | Cisco ukończy wymagane konfiguracje na sprzęcie firmy Cisco w ciągu 5 dni roboczych . Po pomyślnym zakończeniu stan zostanie zaktualizowany do „Aktywowany” dla tego konkretnego regionu w Control Hub. |
Krok 4: Klient przeprowadza konfigurację sieci
Stan zostanie zmieniony na „Aktywowany”, aby powiadomić administratora Klienta, że konfiguracja połączeń IP VPN po stronie firmy Cisco została zakończona na podstawie danych wejściowych dostarczonych przez Klienta. Oczekuje się jednak, że administrator klienta dokończy konfiguracje na urządzeniach CPE i przetestuje trasy łączności dla tunelu Virtual Connect, aby był w trybie online. W przypadku jakichkolwiek problemów napotkanych podczas konfiguracji lub połączenia, klient może skontaktować się z Cisco TAC w celu uzyskania pomocy. |
Rozwiązywanie problemów
Rozwiązywanie problemów z pierwszą fazą protokołu IPsec (negocjacja protokołu IKEv2) i sprawdzanie poprawności
Negocjacja tunelu IPsec obejmuje dwie fazy: fazę IKEv2 i fazę IPsec. Jeśli negocjowanie fazy protokołu IKEv2 nie zostanie ukończone, oznacza to, że nie ma inicjacji drugiej fazy protokołu IPsec. Najpierw wydaj polecenie „show crypto ikev2 sa” (na sprzęcie Cisco ) lub podobne polecenie na sprzęcie innej firmy, aby sprawdzić, czy sesja IKEv2 jest aktywna. Jeśli sesja IKEv2 nie jest aktywna, możliwe przyczyny mogą być następujące:
Zainteresowany ruch nie wyzwala tunelu IPsec.
Lista dostępu tuneli IPsec jest nieprawidłowo skonfigurowana.
Nie ma połączenia między klientem a adresem IP punktu końcowego tunelu IPsec dedykowanego wystąpienia.
Parametry sesji IKEv2 nie są zgodne między po stronie wystąpienia dedykowanego i po stronie klienta.
Zapora blokuje pakiety UDP IKEv2.
Najpierw sprawdź, czy w dziennikach protokołu IPsec nie ma komunikatów pokazujących postęp negocjacji tunelu IKEv2. Dzienniki mogą wskazywać, gdzie występuje problem z negocjacją protokołu IKEv2. Brak komunikatów rejestrowania może również wskazywać, że sesja IKEv2 nie jest aktywowana.
Ustawienia protokołu IKEv2 po stronie CPE nie są zgodne z ustawieniami po stronie 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 wystąpienia dedykowanego.
Gdy szyfr „GCM” jest używany, protokół GCM obsługuje uwierzytelnianie i ustawia parametr uwierzytelniania na NULL.
Sprawdź ustawienie okresu istnienia.
Sprawdź grupę modułu Diffie Hellman.
Sprawdź ustawienia funkcji pseudolosowej.
Lista kontroli dostępu dla mapy kryptograficznej nie jest ustawiona na:
Zezwól GRE (local_tunnel_transport_ip ) 255.255.255.255 (remote_tunnel_transport_ip ) 255.255.255.255" (lub równoważne polecenie)
Lista kontroli dostępu musi dotyczyć protokołu „GRE”, a protokół „IP” nie będzie działał.
Jeśli komunikaty dziennika nie pokazują żadnych działań negocjacyjnych dla fazy IKEv2, może być konieczne przechwycenie pakietów.
Dedykowana strona wystąpienia może nie zawsze rozpoczynać wymianę IKEv2 i czasami może oczekiwać, że inicjatorem będzie strona CPE klienta. Sprawdź konfigurację po stronie CPE pod kątem następujących wymagań wstępnych dotyczących inicjowania sesji IKEv2:
|
Po prawidłowym skonfigurowaniu tunel IPsec i negocjacja protokołu IKEv2 w pierwszej fazie rozpoczynają się od następujących czynności:
Utrzymywanie aktywności GRE z interfejsu tunelu GRE po stronie CPE do interfejsu tunelu GRE po stronie wystąpienia dedykowanego.
Sesja TCP z sąsiadem BGP od sąsiada BGP po stronie CPE do sąsiada BGP po stronie dedykowanego wystąpienia.
Wykonaj polecenie ping z adresu IP tunelu po stronie urządzenia CPE do adresu IP tunelu po stronie dedykowanego wystąpienia.
Polecenie Ping nie może być adresem IP transportu tunelu do adresu IP transportu tunelu. Musi to być IP tunelu do IP tunelu.
Jeśli śledzenie pakietów jest wymagane dla ruchu IKEv2, ustaw filtr dla UDP i portu 500 (gdy żadne urządzenie NAT nie znajduje się w środku punktów końcowych protokołu IPsec) lub portu 4500 (gdy urządzenie NAT jest włożone w środku protokołu IPsec punkty końcowe).
Sprawdź, czy pakiety IKEv2 UDP z portem 500 lub 4500 są wysyłane i odbierane z adresu IP IPsec urządzenia DI.
Centrum danych wystąpienia dedykowanego może nie zawsze rozpoczynać pierwszy pakiet IKEv2. Wymagane jest, aby urządzenie CPE było w stanie zainicjować pierwszy pakiet IKEv2 w kierunku wystąpienia dedykowanego. Jeśli zezwala na to lokalna zapora, spróbuj również wysłać polecenie ping do zdalnego adresu IPsec. Jeśli polecenie ping z lokalnego do zdalnego adresu IPsec nie powiedzie się, wykonaj trasę śledzenia, aby pomóc i określić, gdzie pakiet został porzucony. Niektóre zapory i urządzenia internetowe mogą nie zezwalać na śledzenie trasy. |
Rozwiązywanie problemów z drugą fazą protokołu IPsec (negocjacja protokołu IPsec) i sprawdzanie poprawności
Przed przystąpieniem do rozwiązywania problemów z drugą fazą protokołu IPsec sprawdź, czy pierwsza faza protokołu IPsec (czyli skojarzenie zabezpieczeń protokołu IKEv2) jest aktywna. Wykonaj polecenie „show crypto ikev2 sa” lub równoważne, aby zweryfikować sesję IKEv2. W danych wyjściowych sprawdź, czy sesja IKEv2 trwa dłużej niż kilka sekund i nie jest odbijana. Czas działania sesji jest wyświetlany jako „Czas aktywności” sesji lub jego odpowiednik w danych wyjściowych.
Gdy sesja IKEv2 zostanie zweryfikowana jako aktywna i aktywna, zbadaj sesję IPsec. Podobnie jak w przypadku sesji IKEv2, wykonaj polecenie „show crypto ipsec sa” lub równoważne, aby zweryfikować sesję IPsec. Zarówno sesja IKEv2, jak i sesja IPsec muszą być aktywne przed ustanowieniem 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 negocjacji.
Niektóre z najczęstszych problemów, które mogą wystąpić podczas negocjacji protokołu IPsec, to:
Ustawienia po stronie urządzenia CPE nie są zgodne po stronie wystąpienia dedykowanego, sprawdź ponownie ustawienia:
Sprawdź, czy parametry Szyfrowanie i Uwierzytelnianie są zgodne z ustawieniami po stronie wystąpienia dedykowanego.
Sprawdź, czy ustawienia Perfect Forward Secrecy są zgodne z ustawieniami po stronie Dedicated Instance.
Sprawdź ustawienia okresu istnienia.
Sprawdź, czy protokół IPsec został skonfigurowany w trybie tunelowania.
Sprawdź źródłowy i docelowy adres IPsec.
Rozwiązywanie problemów z interfejsem tunelu i sprawdzanie poprawności
Gdy sesje IPsec i IKEv2 zostaną zweryfikowane jako włączone i aktywne, pakiety utrzymywania aktywności tunelu GRE mogą przepływać między punktami końcowymi tunelu wystąpienia dedykowanego i CPE. Jeśli interfejs tunelu nie wyświetla stanu, niektóre typowe problemy to:
VRF transportu interfejsu tunelu nie jest zgodny z VRF interfejsu pętli zwrotnej (jeśli konfiguracja VRF jest używana na interfejsie tunelu).
Jeśli konfiguracja VRF nie jest używana w interfejsie tunelu, to sprawdzenie można zignorować.
Podtrzymywanie aktywności nie jest włączone w interfejsie tunelu bocznego CPE
Jeśli urządzenia CPE nie obsługują funkcji utrzymywania aktywności, należy o tym powiadomić firmę Cisco , aby wyłączyć również domyślne podtrzymywanie aktywności po stronie wystąpienia dedykowanego.
Jeśli utrzymywanie aktywności jest obsługiwane, sprawdź, czy utrzymywanie aktywności jest włączone.
Maska lub adres IP interfejsu tunelu jest niepoprawny i nie jest zgodny z oczekiwanymi wartościami wystąpienia dedykowanego.
Źródłowy lub docelowy adres transportowy tunelu jest niepoprawny i nie jest zgodny z oczekiwanymi wartościami wystąpienia dedykowanego.
Zapora blokuje wysyłanie pakietów GRE do tunelu IPsec lub odbieranie z tunelu IPsec (tunel GRE jest przesyłany przez tunel IPsec)
Test ping powinien sprawdzić, czy interfejs lokalnego tunelu działa, a łączność ze zdalnym interfejsem tunelu jest dobra. Wykonaj test ping z IP tunelu (nie IP transportu ) do IP zdalnego tunelu .
Lista dostępu kryptograficznego dla tunelu IPsec, który przenosi ruch w tunelu GRE, zezwala na przechodzenie tylko pakietów GRE. W rezultacie pakiety ping nie będą działać z adresu IP transportu tunelowego do IP IP transportu zdalnego tunelu . |
Test ping powoduje wygenerowanie pakietu GRE ze źródłowego IP transportu tunelu do docelowego IP transportu tunelu, podczas gdy ładunek pakietu GRE (wewnętrzny IP) będzie źródłowym i docelowym adresem IP tunelu.
Jeśli test ping nie powiedzie się, a powyższe elementy zostaną zweryfikowane, może być wymagane przechwycenie pakietu, aby upewnić się, że polecenie icmp ping spowoduje powstanie pakietu GRE, który jest następnie hermetyzowany w pakiet IPsec, a następnie wysyłany ze źródłowego adresu IPsec do docelowy adres IPsec. Pomocne w wyświetlaniu mogą być również liczniki w interfejsie tunelu GRE i liczniki sesji IPsec. jeśli pakiety wysyłania i odbierania są zwiększane.
Oprócz ruchu ping w przechwytywaniu powinny być również widoczne pakiety GRE z utrzymywaniem aktywności nawet podczas bezczynności ruchu. Na koniec, jeśli skonfigurowano protokół BGP, pakiety utrzymywania aktywności BGP powinny być również wysyłane jako pakiety GRE hermetyzowane w pakietach IPSEC, a także przez VPN.
Rozwiązywanie problemów i sprawdzanie poprawności protokołu BGP
Sesje BGP
Protokół BGP jest wymagany jako protokół routingu w tunelu VPN IPsec. Lokalny sąsiad BGP powinien nawiązać sesję eBGP z sąsiadem protokołu Dedicated Instance BGP. Adresy IP sąsiadów eBGP są takie same, jak adresy IP tuneli lokalnych i zdalnych. Najpierw upewnij się, że sesja BGP jest uruchomiona, a następnie sprawdź, czy prawidłowe trasy są odbierane z wystąpienia dedykowanego, a poprawna trasa domyślna jest wysyłana do wystąpienia dedykowanego.
Jeśli tunel GRE działa, sprawdź, czy ping między lokalnym a zdalnym adresem IP tunelu GRE powiodło się. Jeśli polecenie ping się powiedzie, ale sesja BGP nie nawiązuje połączenia, sprawdź dziennik BGP pod kątem błędów ustanawiania protokołu BGP.
Niektóre z najczęstszych problemów z negocjacjami protokołu BGP to:
Numer zdalnego serwera AS nie jest zgodny z numerem AS skonfigurowanym po stronie wystąpienia dedykowanego. Sprawdź ponownie konfigurację sąsiedniego systemu AS.
Lokalny numer AS nie jest zgodny z oczekiwanym po stronie wystąpienia dedykowanego. Sprawdź, czy lokalny numer AS jest zgodny z oczekiwanymi parametrami wystąpienia dedykowanego.
Zapora blokuje wysyłanie pakietów BGP TCP zawartych w pakietach GRE do tunelu IPsec lub ich odbieranie z tunelu IPSEC
Adres IP zdalnego sąsiada IP BGP nie odpowiada adresowi IP zdalnego tunelu GRE.
Wymiana tras BGP
Po zweryfikowaniu sesji protokołu BGP dla obu tuneli upewnij się, że po stronie wystąpienia dedykowanego są wysyłane i odbierane prawidłowe trasy.
Rozwiązanie Dedicated Instance VPN oczekuje, że po stronie klienta/partnera zostaną ustanowione dwa tunele. Pierwszy tunel wskazuje centrum danych A wystąpienia dedykowanego, a drugi tunel — centrum danych B wystąpienia dedykowanego. Oba tunele muszą być w stanie aktywnym, a rozwiązanie wymaga wdrożenia aktywnego/aktywnego. Każde centrum danych wystąpienia dedykowanego anonsuje swoją trasę lokalną /25 oraz trasę kopii zapasowej /24. Podczas sprawdzania przychodzących tras protokołu BGP z wystąpienia dedykowanego upewnij się, że sesja protokołu BGP skojarzona z tunelem wskazującym centrum danych A wystąpienia dedykowane otrzymuje trasę lokalną centrum danych A /25 wystąpienia dedykowanego oraz trasę zapasową /24. Ponadto należy się upewnić, że tunel wskazujący centrum danych B wystąpienia dedykowanego odbiera trasę lokalną centrum danych B /25 wystąpienia dedykowanego oraz trasę kopii zapasowej /24. Należy pamiętać, że trasa kopii zapasowej /24 będzie tą samą trasą anonsowaną z centrum danych A wystąpienia dedykowanego i centrum danych B wystąpienia dedykowanego.
Nadmiarowość jest zapewniana centrum danych wystąpienia dedykowanego, jeśli interfejs tunelu do tego centrum danych ulegnie awarii. W przypadku utraty połączenia z centrum danych A wystąpienia dedykowanego ruch będzie przekierowywany z centrum danych B wystąpienia dedykowanego do centrum danych A. W tym scenariuszu tunel do centrum danych B użyje trasy centrum danych B/25 w celu wysłania ruchu do centrum danych B i tunelu do centrum danych B użyje trasy kopii zapasowej /24 w celu wysłania ruchu do centrum danych A przez centrum danych B.
Jeśli oba tunele są aktywne, tunel centrum danych A nie jest używany do wysyłania ruchu do centrum danych B i odwrotnie. W tym scenariuszu, jeśli ruch jest wysyłany do centrum danych A z miejscem docelowym centrum danych B, centrum danych A przekieruje ruch do centrum danych B, a następnie centrum danych B podejmie próbę odesłania ruchu z powrotem do źródła za pośrednictwem tunelu centrum danych B. Spowoduje to nieoptymalne kierowanie i może również spowodować przerwanie ruchu przechodzącego przez zapory sieciowe. Dlatego ważne jest, aby podczas normalnej pracy oba tunele znajdowały się w konfiguracji aktywny/aktywny.
Trasa 0.0.0.0/0 musi być anonsowana od strony klienta do centrum danych wystąpienia dedykowanego. Bardziej szczegółowe trasy nie będą akceptowane przez stronę Dedicated Instance. Upewnij się, że trasa 0.0.0.0/0 jest anonsowana zarówno z tunelu A centrum danych dedykowanego wystąpienia, jak i tunelu B centrum danych wystąpienia dedykowanego.
Konfiguracja jednostki MTU
Po stronie wystąpienia dedykowanego dostępne są dwie funkcje dynamicznego dostosowywania jednostki MTU do pakietów o dużych rozmiarach. Tunel GRE dodaje więcej nagłówków do pakietów IP przepływających przez sesję VPN . Tunel IPsec dodaje dodatkowe nagłówki nad nagłówkami GRE, co jeszcze bardziej zmniejszy największą jednostkę MTU dozwoloną w tunelu.
Tunel GRE dostosowuje funkcję MSS, a ścieżka tunelu GRE w funkcji wykrywania jednostek MTU jest włączona po stronie wystąpienia dedykowanego. Skonfiguruj polecenia „ip tcp adjust-mss 1350” lub równoważne oraz „tunnel path\u0002mtu-discovery” lub równoważne polecenie po stronie klienta, aby pomóc w dynamicznym dostosowywaniu jednostki MTU ruchu przez tunel VPN .