Podstawy

Wymagania wstępne

Przed wdrożeniem Cisco Unified Border Element (CUBE) High Availability (HA) jako bramy lokalnej dla usługi Webex Calling upewnij się, że znasz następujące koncepcje:

Wytyczne dotyczące konfiguracji zawarte w tym artykule zakładają dedykowaną platformę bramy lokalnej bez istniejącej konfiguracji głosowej. Jeśli istniejące wdrożenie przedsiębiorstwa CUBE jest modyfikowane w celu korzystania również z funkcji bramy lokalnej dla usługi Cisco Webex Calling, należy zwrócić szczególną uwagę na zastosowaną konfigurację, aby zapewnić, że istniejące przepływy połączeń i funkcje nie są przerywane, oraz upewnić się, że przestrzegasz wymagań projektowych CUBE dla wysokiej dostępności.

Komponenty sprzętu i oprogramowania

CUBE HA jako brama lokalna wymaga systemu IOS-XE w wersji 17.9.1 lub nowszej oraz platformy, na której obsługiwane są funkcje CUBE HA i LGW.

Polecenia wyświetlania i dzienniki w tym artykule opierają się na minimalnej wersji oprogramowania Cisco IOS-XE 17.9.1 wdrożonej na vCUBE (CSR 8000v).

Materiał referencyjny

Oto kilka szczegółowych przewodników konfiguracji modułu CUBE HA dla różnych platform:

Przegląd rozwiązania Webex Calling

Cisco Webex Calling to oferta współpracy, która zapewnia oparte na chmurze rozwiązanie alternatywne dla lokalnej usługi telefonicznej PBX z wieloma opcjami PSTN dla klientów.

W tym artykule skupiono się na wdrożeniu bramy lokalnej (przedstawionej poniżej). Łącze magistralowe bramy lokalnej (lokalne PSTN) w usłudze Webex Calling umożliwia łączność z usługą PSTN należącą do klienta. Zapewnia również łączność z wdrożeniem lokalnej centrali PBX IP, takiej jak Cisco Unified CM. Cała komunikacja do i z chmury jest zabezpieczona przy użyciu transportu TLS dla SIP i SRTP dla multimediów.

Wdrożenie lokalnej bramy PSTN

Na poniższym rysunku przedstawiono wdrożenie usługi Webex Calling bez żadnej istniejącej centrali PBX IP i dotyczy pojedynczego wdrożenia lub wdrożenia wielu witryn. Konfiguracja opisana w tym artykule jest oparta na tym wdrożeniu.

Wdrożenie usługi Webex Calling bez centrali PBX IP

Redundancja między skrzynkami w warstwie 2

Nadmiarowość skrzynki CUBE HA warstwy 2 wykorzystuje protokół infrastruktury Redundancy Group (RG) w celu utworzenia pary routerów aktywnych/rezerwowych. Para ta korzysta z tego samego wirtualnego adresu IP (VIP) we wszystkich swoich interfejsach i stale wymienia komunikaty o stanie. Informacje o sesji CUBE są sprawdzane przez parę routerów, dzięki czemu router rezerwowy może natychmiast przejąć wszystkie obowiązki przetwarzania połączeń CUBE, jeśli aktywny router przestanie działać, co powoduje statyczne zachowanie sygnalizacji i multimediów.

Sprawdzanie wskazywania jest ograniczone do połączeń z pakietami multimediów. Połączenia w trakcie tranzytu nie są kierowane znakami sprawdzania (na przykład są to stan próby lub dzwonienia).

W tym artykule CUBE HA będzie odnosić się do redundancji CUBE High Availability (HA) Layer 2 Box-to-Box (B2B) w celu statycznego zachowywania połączeń.

Od wersji IOS-XE 17.9.1 CUBE HA może być wdrożony jako brama lokalna dla wdrożeń łącza magistralowego Cisco Webex Calling (lokalne PSTN). W tym artykule zostaną omówione kwestie projektowe i konfiguracje. Na rysunku przedstawiono typową konfigurację CUBE dla wysokiej dostępności jako bramę lokalną dla wdrożenia łącza magistralowego Cisco Webex Calling.

Typowa konfiguracja CUBE dla wysokiej dostępności jako brama lokalna dla wdrożenia łącza magistralowego Cisco Webex Calling

Składnik podrzędny grupy redundancji

Składnik Infrastruktura grupy redundancji (RG) zapewnia obsługę infrastruktury komunikacji typu „box-to-box” między dwoma modułami CUBE i negocjuje ostateczny stabilny stan redundancji. Składnik ten zapewnia również:

  • Protokół podobny do HSRP, który negocjuje ostateczny stan redundancji dla każdego routera poprzez wymianę komunikatów podtrzymania łączności i powitania między dwoma modułami CUBE (za pośrednictwem interfejsu kontrolnego) — GigabitEthernet3 na powyższym rysunku.

  • Mechanizm transportowy do sprawdzania wskazywania stanu sygnalizacji i multimediów dla każdego połączenia z aktywnego na router czuwania (za pośrednictwem interfejsu danych) — GigabitEthernet3 na powyższym rysunku.

  • Konfiguracja i zarządzanie wirtualnym interfejsem IP (VIP) dla interfejsów ruchu (wiele interfejsów ruchu można skonfigurować przy użyciu tej samej grupy RG) – GigabitEthernet 1 i 2 są uważane za interfejsy ruchu.

Ten komponent RG musi być specjalnie skonfigurowany do obsługi głosu B2B HA.

Zarządzanie wirtualnymi adresami IP (VIP) zarówno dla sygnalizacji, jak i multimediów

B2B HA polega na VIP, aby osiągnąć redundancję. Interfejs VIP i powiązane interfejsy fizyczne na obu modułach CUBE w parze CUBE HA muszą znajdować się w tej samej podsieci LAN. Konfiguracja VIP i powiązanie interfejsu VIP z określoną aplikacją głosową (SIP) są obowiązkowe w przypadku obsługi głosowej B2B HA. Urządzenia zewnętrzne, takie jak Unified CM, serwer SBC dostępu Webex Calling, dostawca usług lub serwer proxy, używają VIP jako docelowego adresu IP dla połączeń przechodzących przez routery CUBE HA. Dlatego z punktu widzenia Webex Calling pary CUBE HA działają jak jedna brama lokalna.

Informacje o sygnalizacji połączeń i sesjach RTP ustalonych połączeń są sprawdzane z aktywnego routera do routera czuwania. Gdy aktywny router schodzi w dół, router czuwania przejmuje kontrolę i kontynuuje przekazywanie strumienia RTP, który był wcześniej trasowany przez pierwszy router.

Połączenia w stanie przejściowym w czasie przełączania awaryjnego nie będą zachowywane po przełączeniu. Na przykład połączenia, które nie są jeszcze w pełni ustanowione lub są w trakcie modyfikowania za pomocą funkcji przekazywania lub wstrzymywania. Nawiązane połączenia mogą być rozłączane po przełączeniu.

Istnieją następujące wymagania dotyczące używania modułu CUBE HA jako lokalnej bramy dla stacjonarnego przełączenia połączeń:

  • Moduł CUBE HA nie może mieć współzlokalizowanych interfejsów TDM ani analogowych

  • Gig1 i Gig2 są nazywane interfejsami ruchu (SIP/RTP), a Gig3 to interfejs kontroli/danych grupy redundancji (RG)

  • W tej samej domenie warstwy 2, jednej z identyfikatorem grupy, nie można umieścić więcej niż 2 par CUBE HA 1 i drugi 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ł portów jest obsługiwany zarówno dla interfejsów sterowania RG/danych, jak i ruchu

  • Wszystkie sygnały/multimedia są pozyskiwane z/do wirtualnego adresu IP

  • Za każdym razem, gdy platforma jest ponownie ładowana w relacji CUBE-HA, zawsze uruchamia się jako tryb czuwania

  • Dolny adres dla wszystkich interfejsów (Gig1, Gig2, Gig3) powinien znajdować się na tej samej platformie

  • Identyfikator interfejsu nadmiarowego, rii powinien być unikatowy dla kombinacji pary/interfejsu na tej samej warstwie 2

  • Konfiguracja na obu modułach CUBE musi być identyczna, w tym konfiguracja fizyczna i musi działać na tym samym typie platformy i w wersji IOS-XE

  • Interfejsy typu loopback nie mogą być używane jako powiązane, ponieważ są zawsze włączone

  • Wiele interfejsów ruchu (SIP/RTP) (Gig1, Gig2) wymaga skonfigurowania funkcji śledzenia interfejsu

  • Moduł CUBE-HA nie jest obsługiwany przez złącze kabla krzyżowego dla łącza RG-control/data (Gig3)

  • Obie platformy muszą być identyczne i połączone za pomocą przełącznika fizycznego we wszystkich podobnie interfejsach, aby CUBE HA działał, tj. GE0/0/0 z CUBE-1 i CUBE-2 muszą kończyć się na tym samym przełączniku itd.

  • Nie może mieć terminowanej sieci WAN na modułach CUBE bezpośrednio lub Dane HA po obu stronach

  • Obie parametry Aktywne/Rezerwowe muszą znajdować się w tym samym centrum danych

  • Wymagane jest użycie oddzielnego interfejsu L3 dla redundancji (RG Control/data, Gig3), tzn. interfejsu używanego dla ruchu nie można używać do utrzymywania HA i zaznaczania.

  • Po przełączeniu awaryjnym wcześniej aktywny moduł CUBE przechodzi przez ponowne załadowanie według projektu, zachowując sygnalizację i multimedia

Konfigurowanie redundancji na obu CUBE

Należy skonfigurować redundancję warstwy 2 między skrzynkami na obu modułach CUBE, które mają być używane w parze HA w celu generowania wirtualnych adresów IP.

Typowa konfiguracja CUBE dla wysokiej dostępności jako brama lokalna dla wdrożenia łącza magistralowego Cisco Webex Calling

1

Skonfiguruj śledzenie interfejsu na poziomie globalnym, aby monitorować stan interfejsu.

conf t
 track 1 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit


VCUBE-1#conf t

VCUBE-1(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-1(config-track)#exit

VCUBE-2#conf t

VCUBE-2(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-2(config-track)#exit

Funkcja CLI śledzenia jest używana w RG do śledzenia stanu interfejsu ruchu głosowego, dzięki czemu aktywna trasa będzie dość aktywna po wyłączeniu interfejsu ruchu.

2

Skonfiguruj RG, który ma być używany z VoIP HA w podtrybie redundancji aplikacji.

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 1
    data GigabitEthernet3
    timers delay 30 reload 60
    track 1 shutdown
    track 2 shutdown
    exit
   protocol 1
    timers hellotime 3 holdtime 10
   exit
  exit
 exit


VCUBE-1(config)#redundancy

VCUBE-1(config-red)#application redundancy

VCUBE-1(config-red-app)#group 1

VCUBE-1(config-red-app-grp)#name LocalGateway-HA

VCUBE-1(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-1(config-red-app-grp)#timers delay 30 reload 60

VCUBE-1(config-red-app-grp)#track 1 shutdown

VCUBE-1(config-red-app-grp)#track 2 shutdown

VCUBE-1(config-red-app-grp)#exit

VCUBE-1(config-red-app)#protocol 1

VCUBE-1(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-1(config-red-app-prtcl)#exit

VCUBE-1(config-red-app)#exit

VCUBE-1(config-red)#exit

VCUBE-1(config)#

VCUBE-2(config)#redundancy

VCUBE-2(config-red)#application redundancy

VCUBE-2(config-red-app)#group 1

VCUBE-2(config-red-app-grp)#name LocalGateway-HA

VCUBE-2(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-2(config-red-app-grp)#timers delay 30 reload 60

VCUBE-2(config-red-app-grp)#track 1 shutdown

VCUBE-2(config-red-app-grp)#track 2 shutdown

VCUBE-2(config-red-app-grp)#exit

VCUBE-2(config-red-app)#protocol 1

VCUBE-2(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-2(config-red-app-prtcl)#exit

VCUBE-2(config-red-app)#exit

VCUBE-2(config-red)#exit

VCUBE-2(config)#

Wyjaśnienie pól używanych w tej konfiguracji:

  • nadmiarowość — przechodzi w tryb nadmiarowości

  • nadmiarowość aplikacji — przechodzi w tryb konfiguracji nadmiarowości aplikacji

  • grupa — wprowadza tryb konfiguracji grupy aplikacji redundancji

  • nazwa LocalGateway-HA — określa nazwę grupy RG

  • Próg 75 przełączenia awaryjnego według priorytetu 100 — określa początkowe progi priorytetu i przełączenia awaryjnego dla RG

  • timers delay 30 reload 60— ustawia dwukrotne opóźnienie i reload

    • Czasomierz opóźnienia, czyli czas do opóźnienia inicjacji grupy RG i negocjacji roli po uruchomieniu interfejsu — domyślnie 30 sekund. Zakres wynosi 0–10000 s

    • Ponowne załadowanie — określa czas opóźnienia w inicjowaniu grupy RG i negocjowaniu ról po ponownym załadowaniu — domyślnie 60 sekund. Zakres wynosi 0–10000 s

    • Zaleca się stosowanie zegarów domyślnych, chociaż można je wyregulować w celu uwzględnienia wszelkich dodatkowych opóźnień konwergencji sieci, które mogą wystąpić podczas uruchamiania/ponownego ładowania routerów, w celu zagwarantowania, że negocjowanie protokołu RG nastąpi po przejściu trasowania w sieci do punktu stabilnego. Na przykład, jeśli po przełączeniu awaryjnym zostanie wyświetlony pierwszy pakiet RG HELLO z nowego urządzenia ACTIVE, po czym czasomierz należy ustawić na „opóźnienie czasomierza 60 reload 120”, aby uwzględnić to opóźnienie.

  • kontrola protokołu GigabitEthernet3 1 — konfiguruje interfejs używany do wymiany komunikatów podtrzymania łączności i powitania między dwoma modułami CUBE oraz określa wystąpienie protokołu, które zostanie dołączone do interfejsu kontrolnego i przechodzi w tryb konfiguracji protokołu aplikacji nadmiarowej

  • Dane GigabitEthernet3 — konfiguruje interfejs używany do wskazywania ruchu danych

  • śledzenie— śledzenie grup RG interfejsów

  • protokół 1 — określa wystąpienie protokołu, które zostanie dołączone do interfejsu kontrolnego i przechodzi w tryb konfiguracji protokołu aplikacji redundancji

  • timers hellotime 3 holdtime 10 — konfiguruje dwa timers dla hellotime i holdtime:

    • Hellotime — odstęp między kolejnymi wiadomościami hello — domyślnie 3 sekundy. Zakres wynosi 250 milisekund–254 sekundy

    • Czas oczekiwania — odstęp czasu między odebraniem wiadomości powitalnej a domniemaniem niepowodzenia wysyłania routera. Ten czas trwania musi być dłuższy niż czas powitania — domyślnie 10 sekund. Zakres wynosi 750 milisekund–255 sekund

      Zalecamy skonfigurowanie czasomierza czasu oczekiwania na co najmniej 3-krotność wartości czasomierza czasu oczekiwania.

3

Włącz redundancję między skrzynkami dla aplikacji CUBE. Skonfiguruj RG z poprzedniego kroku w sekcji voice service voip. Dzięki temu aplikacja CUBE może kontrolować proces nadmiarowości.

voice service voip
   redundancy-group 1
   exit

VCUBE-1(config)#voice service voip

VCUBE-1(config-voi-serv)#redundancy-group 1


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

VCUBE-1(config-voi-serv)# exit

VCUBE-2(config)#voice service voip

VCUBE-2(config-voi-serv)#redundancy-group 1


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

VCUBE-2(config-voi-serv)# exit

redundancy-group 1 — dodanie i usunięcie tego polecenia wymaga ponownego załadowania, aby zaktualizowana konfiguracja została uwzględniona. Po zastosowaniu całej konfiguracji załadujemy ponownie platformy.

4

Skonfiguruj interfejsy Gig1 i Gig2 z odpowiednimi wirtualnymi adresami IP w sposób przedstawiony poniżej i zastosuj identyfikator interfejsu redundancji (rii)

VCUBE-1(config)#interface GigabitEthernet1

VCUBE-1(config-if)# redundancy rii 1

VCUBE-1(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-1(config)#

VCUBE-1(config)#interface GigabitEthernet2

VCUBE-1(config-if)# redundancy rii 2

VCUBE-1(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-2(config)#interface GigabitEthernet1

VCUBE-2(config-if)# redundancy rii 1

VCUBE-2(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-2(config-if)# exit

VCUBE-2(config)#

VCUBE-2(config)#interface GigabitEthernet2

VCUBE-2(config-if)# redundancy rii 2

VCUBE-2(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-v(config-if)# exit

Wyjaśnienie pól używanych w tej konfiguracji:

  • rii redundancji — konfiguruje identyfikator interfejsu redundancji dla grupy redundancji. Wymagane do wygenerowania adresu wirtualnego MAC (VMAC). Ta sama wartość identyfikatora rii musi być używana na interfejsie każdego routera (AKTYWNEGO/CZUWANIA), który ma ten sam VIP.

    Jeśli w tej samej sieci LAN jest więcej niż jedna para B2B, każda para MUSI mieć unikatowe identyfikatory RII w odpowiednich interfejsach (aby zapobiec kolizjom). Polecenie Show redundancy application group all (Pokaż grupę aplikacji redundancji all) powinno wskazywać prawidłowe informacje lokalne i informacje równorzędne.

  • grupa redundancji 1 — powoduje powiązanie interfejsu z grupą redundancji utworzoną w kroku 2 powyżej. Skonfiguruj grupę RG oraz VIP przypisane do tego fizycznego interfejsu.

    W celu zapewnienia redundancji należy obowiązkowo używać oddzielnego interfejsu, tzn. interfejsu używanego do ruchu głosowego nie można używać jako interfejsu sterowania ani do przesyłania danych określonych w kroku 2 powyżej. W tym przykładzie interfejs gigabitowy 3 jest używany do kontroli/danych RG

5

Zapisz konfigurację pierwszego modułu CUBE i załaduj ją ponownie.

Platforma do ostatniego ponownego załadowania jest zawsze w trybie gotowości.

VCUBE-1#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-1#reload


                        Proceed with reload? [confirm]

Po całkowitym uruchomieniu VCUBE-1 zapisz konfigurację VCUBE-2 i załaduj ją ponownie.

VCUBE-2#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-2#reload


                        Proceed with reload? [confirm]

6

Sprawdź, czy konfiguracja „skrzynka do skrzynki” działa zgodnie z oczekiwaniami. Odpowiedni wynik jest oznaczony pogrubioną czcionką.

Ostatnio załadowaliśmy ponownie VCUBE-2 zgodnie z wymaganiami projektowymi; ostatnim załadowaniem platformy będzie zawsze Tryb czuwania. 


VCUBE-1#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: ACTIVE
Peer Role: STANDBY
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: Local
        Standby Peer: address 10.1.1.2, priority 100, intf Gi3
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-1#

VCUBE-2#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: STANDBY
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: address 10.1.1.2, priority 100, intf Gi3
        Standby Peer: Local
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-2#

Następnie przejdź do konfiguracji bramy lokalnej (na podstawie rejestracji lub na podstawie certyfikatu) na obu modułach HA CUBE. Zobacz Konfigurowanie bramy lokalnej w systemie Cisco IOS XE dla usługi Webex Calling.