- Strona główna
- /
- Artykuł
Local Gateway (LGW) to ekskluzywne rozwiązanie zapewniające lokalnego dostępu PSTN klientom Cisco Webex Calling. W tym dokumencie można skonfigurować bramę lokalną przy użyciu wysokiej dostępności CUBE, z aktywnym lub gotowym CUBE, aby zapewnić przełączanie awaryjne aktywnych połączeń w stanie.
Podstawy
Wymagania wstępne
Przed wdrożeniem Cisco Unified Border Element (CUBE) High Availability (HA) jako lokalnej bramyWebex Calling, upewnij się, że masz dogłębne zrozumienie następujących pojęć:
-
Redundancja typu box to box warstwy 2 z CUBE Enterprise do przechowywania połączeń stanowych
Wytyczne dotyczące konfiguracji przedstawione w tym artykule zakładają dedykowaną platformę bramki lokalnej bez istniejącej konfiguracji głosowej. Jeśli istniejące wdrożenie dla przedsiębiorstw CUBE jest modyfikowane, aby wykorzystywać również funkcję bramki lokalnejCisco Webex Calling, należy zwrócić szczególną uwagę na zastosowaną konfigurację, aby zapewnić, że istniejące przepływy połączeń i funkcjonalności nie zostaną przerwane, i upewnij się, że spełniasz wymagania projektowe CUBE HA.
Komponenty sprzętowe i programowe
CUBE HA jako lokalna brama wymaga systemu IOS-XE w wersji 17.9.1 lub nowszej oraz platformy, na której obsługiwane są zarówno funkcje CUBE HA, jak i LGW.
Polecenia i dzienniki pokazu w tym artykule oparte są na minimalnej wersji oprogramowania Cisco IOS -XE 17.9.1 zaimplementowanej na vCube (CSR 8000v).
Materiał referencyjny
Oto kilka szczegółowych przewodników konfiguracji CUBE HA dla różnych platform:
-
Preferowana architektura Cisco dla Cisco Webex Calling - https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex CallingPrzegląd rozwiązań
Cisco Webex Callingto oferta współpracy, która zapewnia opartą na chmurze alternatywę dla lokalnej usługi telefonicznej PBX z wieloma opcjami PSTN dla klientów.
Wdrożenie lokalnej bramy (przedstawione poniżej) jest przedmiotem tego artykułu. Trunk lokalnej bramy (lokalnej PSTN) Webex Calling umożliwia łączenie się z usługą PSTN należącą do klienta. Zapewnia również łączność z lokalnym wdrożeniem IP PBX, takim jak. Cisco Unified CM Cała komunikacja do i z chmury jest zabezpieczona za pomocą transportu TLS dla SIP i SRTP dla mediów.
Poniższy rysunek przedstawia Webex Calling wdrożenie bez istniejącej centrali IP i ma zastosowanie do wdrożenia pojedynczego lub wielolokalizacyjnego. Konfiguracja opisana w tym artykule opiera się na tym wdrożeniu.
Redundancja typu „pudełko do pudełka” warstwy 2
Redundancja typu box-to-box warstwy 2 CUBE HA wykorzystuje protokół infrastruktury Redundancy Group (RG) do utworzenia pary routerów aktywnych/gotowych. Ta para ma ten sam wirtualny adres IP (VIP) na swoich interfejsach i stale wymienia komunikaty o stanie. Informacje o sesji CUBE są sprawdzane w parze routerów, dzięki czemu router czuwania może natychmiast przejąć wszystkie obowiązki związane z przetwarzaniem połączeń CUBE, jeśli aktywny router przestanie działać, co skutkuje zachowaniem stanu sygnalizacji i nośników.
Kontrolne wskazywanie jest ograniczone do połączeń połączonych z pakietami multimedialnymi. Połączenia tranzytowe nie są zaznaczone (na przykład stan próby lub dzwonienie).
W tym artykule CUBE HA będzie odnosić się do redundancji CUBE High Availability (HA) Layer 2 Box-to-Box (B2B) w celu zachowania połączeń stanowych.
Począwszy od iOS-XE 17.9.1, CUBE HA może być wdrażany jako lokalna brama dla wdrożeń Cisco Webex Calling magistralnych (PSTN oparty na lokalach). W tym artykule omówimy kwestie projektowe i konfiguracje. Rysunek przedstawia typową konfigurację CUBE HA jako lokalną bramę dla wdrożenia Cisco Webex Calling magistralnego.
Infrakomponent grupy redundancji
Komponent Infra Redundancy Group (RG) zapewnia obsługę infrastruktury komunikacyjnej typu box to box między dwoma CUBE i negocjuje ostateczny stan stabilnej redundancji. Ten komponent zapewnia również:
-
Protokół podobny do HSRP, który negocjuje ostateczny stan nadmiarowości dla każdego routera poprzez wymianę komunikatów Keepalive i hello między dwoma CUBE (za pośrednictwem interfejsu sterującego) —GigabiteThernet3 na powyższym rysunku.
-
Mechanizm transportowy do sprawdzania sygnalizacji i stanu mediów dla każdego połączenia z routera aktywnego do trybu gotowości (przez interfejs danych) —GigabiteThernet3 na powyższym rysunku.
-
Konfiguracja i zarządzanie interfejsem Virtual IP (VIP) dla interfejsów ruchu (można skonfigurować wiele interfejsów ruchu przy użyciu tej samej grupy RG) — GigabiteEthernet 1 i 2 są uważane za interfejsy ruchu.
Ten komponent RG musi być specjalnie skonfigurowany do obsługi głosowego B2B HA.
Wirtualne zarządzanie adresami IP (VIP) zarówno dla sygnalizacji, jak i mediów
B2B HA polega na VIP, aby osiągnąć redundancję. Interfejsy VIP i powiązane z nimi interfejsy fizyczne obu CUBE w parze CUBE HA muszą znajdować się w tej samej podsieci LAN. Konfiguracja VIP i powiązanie interfejsu VIP z konkretną aplikacją głosową (SIP) są obowiązkowe w przypadku obsługi głosowej B2B HA. Urządzenia zewnętrzneUnified CM, takie jak Webex Calling dostęp do SBC, dostawca usług lub proxy, używają VIP jako docelowego adresu IP dla połączeń przechodzących przez routery CUBE HA. Stąd, z Webex Calling punktu widzenia, pary CUBE HA działają jak pojedyncza brama lokalna.
Sygnalizacja połączeń i informacje o sesji RTP ustalonych połączeń są sprawdzane z aktywnego routera do routera gotowości. Gdy router Active wyłącza się, router Standby przejmuje kontrolę i kontynuuje przekazywanie strumienia RTP, który był wcześniej kierowany przez pierwszy router.
Połączenia w stanie przejściowym w momencie przełączania awaryjnego nie zostaną zachowane po przełączeniu. Na przykład wywołania, które nie są jeszcze w pełni ustanowione lub są w trakcie modyfikowania za pomocą funkcji transferu lub zatrzymania. Ustanowione połączenia mogą zostać odłączone po przełączeniu.
Istnieją następujące wymagania dotyczące używania CUBE HA jako lokalnej bramy dla stanowego przełączania awaryjnego połączeń:
-
CUBE HA nie może mieć współzlokalizowanych interfejsów TDM lub analogowych
-
Gig1 i Gig2 są określane jako interfejsy ruchu (SIP/RTP), a Gig3 to interfejs sterujący/danych grupy redundancji (RG)
-
Nie więcej niż 2 pary CUBE HA można umieścić w tej samej domenie warstwy 2, jedną z identyfikatorem grupy 1, a drugą z identyfikatorem grupy 2. Jeśli konfigurujesz 2 pary HA z tym samym identyfikatorem grupy, interfejsy RG Control/Data muszą należeć do różnych domen warstwy 2 (vlan, oddzielny przełącznik)
-
Kanał portu jest obsługiwany zarówno dla interfejsów RG Control/Data, jak i interfejsów ruchu
-
Wszystkie sygnały/media są pobierane z/na wirtualny adres IP
-
Za każdym razem, gdy platforma jest przeładowywana w relacji CUBE-HA, zawsze uruchamia się jako tryb gotowości
-
Dolny adres dla wszystkich interfejsów (Gig1, Gig2, Gig3) powinien znajdować się na tej samej platformie
-
Identyfikator interfejsu nadmiarowości, rii powinien być unikalny dla kombinacji pary/interfejsu na tej samej warstwie 2
-
Konfiguracja na obu urządzeniach CUBE musi być identyczna, w tym konfiguracja fizyczna i musi działać na tym samym typie platformy i wersji IOS-XE
-
Interfejsy pętli zwrotnej nie mogą być używane jako bind, ponieważ są zawsze gotowe
-
Interfejsy wielu ruchów (SIP/RTP) (Gig1, Gig2) wymagają konfiguracji śledzenia interfejsu
-
CUBE-HA nie jest obsługiwany przez połączenie kablowe krzyżowe dla łącza RG-Control/Data link (Gig3)
-
Obie platformy muszą być identyczne i być połączone za pomocą fizycznego przełącznika na wszystkich podobnych interfejsach, aby CUBE HA działało, tj. GE0/0/0 CUBE-1 i CUBE-2 musi zakończyć się na tym samym przełączniku i tak dalej.
-
Nie można zakończyć sieci WAN bezpośrednio na CUbes lub Data HA po obu stronach
-
Oba programy Active/Standby muszą znajdować się w tym samym centrum danych
-
Obowiązkowe jest użycie oddzielnego interfejsu L3 do nadmiarowości (RG Control/Data, Gig3). tj. interfejs używany do ruchu nie może być używany do zapisów HA i punktów kontrolnych
-
Po przełączeniu awaryjnym, wcześniej aktywny CUBE przechodzi projektowe przeładowanie, zachowując sygnalizację i media
Skonfiguruj nadmiarowość na obu CUBE
Aby wyświetlić wirtualne adresy IP, należy skonfigurować nadmiarowość box-to-box warstwy 2 na obu CUBE przeznaczonych do użycia w parze HA.
| 1 |
Skonfiguruj śledzenie interfejsu na poziomie globalnym, aby śledzić stan interfejsu.
Track CLI jest używany w RG do śledzenia stanu interfejsu ruchu głosowego, dzięki czemu aktywna trasa będzie aktywna rola po wyłączeniu interfejsu ruchu. | ||
| 2 |
Skonfiguruj RG do użytku z VoIP HA w podtrybie nadmiarowości aplikacji.
Oto wyjaśnienie pól używanych w tej konfiguracji:
| ||
| 3 |
Włącz redundancję box-to-box dla aplikacji CUBE. Skonfiguruj RG z poprzedniego kroku w sekcji
redundancy-group 1 — Dodanie i usunięcie tego polecenia wymaga ponownego załadowania, aby zaktualizowana konfiguracja zaczęła obowiązywać. Ponownie załadujemy platformy po zastosowaniu całej konfiguracji. | ||
| 4 |
Skonfiguruj interfejsy Gig1 i Gig2 z odpowiednimi wirtualnymi adresami IP, jak pokazano poniżej, i zastosuj identyfikator interfejsu nadmiarowego (rii)
Oto wyjaśnienie pól używanych w tej konfiguracji:
| ||
| 5 |
Zapisz konfigurację pierwszego CUBE i załaduj ją ponownie. Platforma do ostatniego przeładowania to zawsze tryb gotowości.
Po całkowit ym uruchomieniu VCUBE-1 zapisz konfigurację VCU BE-2 i załaduj ją ponownie.
| ||
| 6 |
Sprawdź, czy konfiguracja box-to-box działa zgodnie z oczekiwaniami. Odpowiednie dane wyjściowe są podświetlone pogrubioną czcion ką. Przeładowaliśmy VCUBE-2 jako ostatni i zgodnie ze względami projektowymi; platforma do przeładowania ostatniego zawsze będzie gotowa.
Następnie przejdź do konfiguracji lokalnej bramy (opartej na rejestracji lub opartej na certyfikacie) na obu modułach HA CUBE. Zobacz Konfigurowanie bramy lokal Cisco IOS nej na XE Webex Calling. |