W tym artykule
Podstawy
Skonfiguruj nadmiarowość na obu CUBE
Zaimplementuj CUBE high availability jako lokalną bramę
list-menuW tym artykule
list-menuOpinia?

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ęć:

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:

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.

Local Gateway premises-based PSTN deployment

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.

Webex Calling deployment without IP PBX

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.

A typical CUBE HA setup as Local Gateway for a Cisco Webex Calling trunk deployment

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.

A typical CUBE HA setup as Local Gateway for a Cisco Webex Calling trunk deployment

1

Skonfiguruj śledzenie interfejsu na poziomie globalnym, aby śledzić 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

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.

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)#

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

  • Redundancja — przechodzi w tryb redundancji

  • Redundancja aplikacji — W chodzi w tryb konfiguracji nadmiarowości aplikacji

  • grupa —W chodzi w tryb konfiguracji grupy aplikacji nadmiarowych

  • nazwa LocalGateway-HA —Definiuje nazwę grupy RG

  • priorytet 100 próg przełączania awaryjnego 75 —Określa początkowy priorytet i progi przełączania awaryjnego dla RG

  • opóźnienie timerów 30 przeładuj 60 —Konfiguruje dwa razy opóźnienia i przeładowania

    • Timer opóźnienia, czyli czas opóźnienia inicjalizacji grupy RG i negocjacji ról po pojawieniu się interfejsu - domyślnie 30 sekund. Zasięg wynosi 0-10000 sekund

    • Przeładowanie — jest to czas opóźnienia inicjalizacji grupy RG i negocjacji ról po przeładowaniu — domyślnie 60 sekund. Zasięg wynosi 0-10000 sekund

    • Zalecane są domyślne timery, chociaż te timery można dostosować tak, aby uwzględnić wszelkie dodatkowe opóźnienia konwergencji sieci, które mogą wystąpić podczas uruchamiania/przeładowania routerów, aby zagwarantować, że negocjowanie protokołu RG odbywa się po zbieżności routingu w sieci do punktu stabilnego. Na przykład, jeśli po przełączeniu awaryjnym okaże się, że zobaczenie pierwszego pakietu RG HELLO z nowego ACTIVE przez nowy STANDBY zajmuje do 20 sekund, wówczas timery powinny być dostosowane do „timers delay 60 reload 120”, aby uwzględnić to opóźnienie.

  • ster@@ owanie protokołem GigabiteThernet3 1 — Konfiguruje interfejs używany do wymiany komunikatów Keepalive i hello między dwoma CUBE i określa instancję protokołu, która zostanie dołączona do interfejsu sterującego i przechodzi w tryb konfiguracji protokołu aplikacji redundantnej

  • data GigaBiteThernet3 — Konfigurowanie interfejsu służącego do kontroli ruchu danych

  • śle dzenie interfejsów grupowych — RG

  • protokół 1 — Określa instancję protokołu, która zostanie dołączona do interfejsu sterującego i przechodzi w tryb konfiguracji protokołu aplikacji nadmiarowej

  • timery hellotime 3 holdtime 10 —Konfiguruje dwa timery dla hellotime i holdtime:

    • Hellotime - Odstęp między kolejnymi wiadomościami witania - Domyślnie 3 sekundy. Zasięg wynosi 250 milisekund - 254 sekund

    • Czas wstrzymania — przerwa między otrzymaniem wiadomości Hello a założeniem, że router wysyłający zawiódł. Czas ten musi być dłuższy niż czas piekielny — domyślnie 10 sekund. Zasięg wynosi 750 milisekund - 255 sekund

      Zalecamy skonfigurowanie czasomierza zatrzymania, aby był co najmniej 3 razy większy od wartości zegara hellotime.

3

Włącz redundancję box-to-box 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 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)

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

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

  • rii nadmiarow ości — Konfiguruje identyfikator interfejsu nadmiarowości dla grupy nadmiarowości. Wymagane do generowania wirtualnego adresu MAC (VMAC). Ta sama wartość identyfikatora rii musi być użyta na interfejsie każdego routera (ACTIVE/STANDBY), który ma ten sam VIP.

    Jeśli w tej samej sieci LAN znajduje się więcej niż jedna para B2B, każda para MUSI mieć unikalne identyfikatory rii na swoich interfejsach (aby zapobiec kolizji). Polecenie show redundancy application group all powinno wskazywać prawidłowe informacje lokalne i równorzędne.

  • grupa redundancji 1 — ko jarzy interfejs z grupą nadmiarowości utworzoną w kroku 2 powyżej. Skonfiguruj grupę RG, a także VIP przypisany do tego fizycznego interfejsu.

    Obowiązkowe jest użycie oddzielnego interfejsu do nadmiarowości, to znaczy interfejs używany do ruchu głosowego nie może być używany jako interfejs sterowania i danych określony w kroku 2 powyżej. W tym przykładzie interfejs Gigabit 3 jest używany do sterowania/danych RG

5

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

Platforma do ostatniego przeładowania to zawsze tryb gotowości.

VCUBE-1#wr
Building configuration...
[OK]
VCUBE-1#reload
Proceed with reload? [confirm]

Po całkowit ym uruchomieniu VCUBE-1 zapisz konfigurację VCU BE-2 i załaduj ją ponownie.

VCUBE-2#wr
Building configuration...
[OK]
VCUBE-2#reload
Proceed with reload? [confirm]
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.


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 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.

Czy ten artykuł był pomocny?
Czy ten artykuł był pomocny?