Podstawy

Warunki wstępne

Przed wdrożeniem CUBE HA jako bramy lokalnej dla Webex Calling upewnij się, że masz dogłębne zrozumienie następujących pojęć:

Wskazówki dotyczące konfiguracji podane w tym artykule zakładają, że dedykowana platforma bramy lokalnej bez istniejącej konfiguracji głosowej. Jeśli istniejące wdrożenie CUBE enterprise jest modyfikowane w celu wykorzystania funkcji bramy lokalnej dla Cisco Webex Calling, zwróć szczególną uwagę na konfigurację zastosowaną w celu zapewnienia, że istniejące przepływy połączeń i funkcje nie zostaną przerwane i upewnij się, że przestrzegasz wymagań projektowych CUBE HA.

Komponenty sprzętowe i programowe

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

Polecenia pokazu i dzienniki w tym artykule są oparte na minimalnej wersji oprogramowania Cisco IOS-XE 16.12.2 zaimplementowanej na vCUBE (CSR1000v).

Materiał referencyjny

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

Omówienie rozwiązania Webex Calling

Cisco Webex Calling to oferta współpracy, która stanowi opartą na chmurze dla wielu dzierżawców chmurową alternatywę dla lokalnej usługi telefonicznej PBX z wieloma opcjami PSTN dla klientów.

Wdrożenie bramy lokalnej (reprezentowane poniżej) jest głównym tematem tego artykułu. Magistrala bramy lokalnej (lokalna sieć PSTN) w Webex Calling umożliwia łączność z usługą PSTN należącą do klienta. Zapewnia również łączność z lokalnym wdrożeniem centrali 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 nośników.

Na poniższym rysunku przedstawiono wdrożenie Webex Calling bez istniejącej centrali IP PBX i ma ono zastosowanie do wdrożenia pojedynczego lub w wielu lokalizacjach. Konfiguracja opisana w tym artykule jest oparta na tym wdrożeniu.

Nadmiarowość warstwy 2 Box-to-Box

Redundancja CUBE HA warstwa 2 box-to-box wykorzystuje protokół infrastruktury Redundancy Group (RG) do utworzenia aktywnej/rezerwowej pary routerów. Ta para dzieli ten sam wirtualny adres IP (VIP) w swoich interfejsach i stale wymienia komunikaty o stanie. Informacje o sesji CUBE są sprawdzane na parze routerów, dzięki czemu router rezerwowy może natychmiast przejąć wszystkie obowiązki związane z przetwarzaniem połączeń CUBE, jeśli aktywny router przestanie działać, co powoduje zachowanie sygnalizacji i nośników.

Wskazywanie kontrolne jest ograniczone do połączeń połączonych z pakietami multimedialnymi. Połączenia w tranzycie nie są zaznaczone (na przykład stan próby lub dzwonienia).

W tym artykule CUBE HA odniesie się do redundancji CUBE High Availability (HA) Layer 2 Box-to-box (B2B) w celu zachowania wywołań stanowych

Począwszy od IOS-XE 16.12.2, CUBE HA może być wdrażany jako brama lokalna dla wdrożeń Cisco Webex Calling Trunk (Premises-based PSTN), a w tym artykule omówimy zagadnienia projektowe i konfiguracje. Na tym rysunku przedstawiono typową konfigurację CUBE HA jako bramę lokalną dla wdrożenia magistrali Cisco Webex Calling.

Składnik infrastruktury grupy nadmiarowej

Komponent Redundancy Group (RG) Infra zapewnia obsługę infrastruktury komunikacyjnej box-to-box między dwoma KUBE i negocjuje ostateczny stabilny stan nadmiarowości. Ten komponent zapewnia również:

  • Protokół podobny do HSRP, który negocjuje ostateczny stan nadmiarowości dla każdego routera, wymieniając komunikaty keepalive i hello między dwoma CUBA (za pośrednictwem interfejsu sterowania) - GigabitEthernet3 na powyższym rysunku.

  • Mechanizm transportowy do sprawdzania stanu sygnalizacji i nośnika dla każdego połączenia z aktywnego do rezerwowego routera (za pośrednictwem interfejsu danych) — GigabitEthernet3 na powyższym rysunku.

  • Konfiguracja i zarządzanie interfejsem Virtual 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.

Wirtualne zarządzanie adresami IP (VIP) zarówno dla sygnalizacji, jak i nośników

B2B HA polega na VIP, aby osiągnąć redundancję. Interfejs VIP i powiązane interfejsy fizyczne w obu KUBE 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 dla obsługi głosowej B2B HA. Urządzenia zewnętrzne, takie jak Unified CM, Webex Calling access SBC, usługodawca lub proxy, używają VIP jako docelowego adresu IP dla połączeń przechodzących przez routery CUBE HA. W związku z tym, z punktu widzenia Webex Calling, pary CUBE HA działają jako pojedyncza brama lokalna.

Sygnalizacja połączeń i informacje o sesji RTP ustalonych połączeń są wskazywane od aktywnego routera do routera rezerwowego. Gdy aktywny router ulegnie awarii, router rezerwowy przejmie kontrolę i kontynuuje przekazywanie strumienia RTP, który był wcześniej kierowany przez pierwszy router.

Wywołania w stanie przejściowym w momencie pracy awaryjnej nie będą zachowywane 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 wstrzymania. Ustanowione połączenia mogą zostać rozłączone po przełączeniu.

Istnieją następujące wymagania dotyczące używania CUBE HA jako bramy lokalnej do stanowego przełączania awaryjnego wywołań:

  • CUBE HA nie może mieć interfejsów TDM lub analogowych

  • Gig1 i Gig2 są określane jako interfejsy ruchu (SIP / RTP), a Gig3 to interfejs sterowania / danych Grupy Nadmiarowości (RG)

  • W tej samej domenie warstwy 2 można umieścić nie więcej niż 2 pary CUBE HA, jedna o identyfikatorze grupy 1, a druga o identyfikatorze grupy 2. Jeśli konfigurujesz 2 HA par z tym samym identyfikatorem grupy, interfejsy RG Control/Data muszą należeć do różnych domen warstwy 2 (vlan, oddzielny przełącznik)

  • Kanał portowy jest obsługiwany zarówno dla interfejsów RG Control/data, jak i traffic

  • Cała sygnalizacja/nośniki są pozyskiwane z/do wirtualnego adresu 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 redundancji, rii powinien być unikalny dla kombinacji pary/interfejsu na tej samej warstwie 2

  • Konfiguracja na obu KUBE musi być identyczna, w tym konfiguracja fizyczna i musi być uruchomiona na tym samym typie platformy i wersji IOS-XE

  • Interfejsy sprzężenia zwrotnego nie mogą być używane jako powiązania, ponieważ zawsze są w górę

  • Interfejsy wieloobsługowe (SIP/RTP) (Gig1, Gig2) wymagają skonfigurowania śledzenia interfejsu

  • CUBE-HA nie jest obsługiwany przez połączenie krosowego dla łącza sterowania RG/danych (Gig3)

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

  • Nie można zakończyć sieci WAN bezpośrednio w CUBA lub Data HA po obu stronach

  • Oba aktywne/rezerwowe muszą znajdować się w tym samym centrum danych

  • Obowiązkowe jest użycie oddzielnego interfejsu L3 dla redundancji (RG Control/data, Gig3). tj. interfejs używany do ruchu nie może być używany do utrzymywania HA i punktów kontrolnych

  • Po przełączeniu awaryjnym poprzednio aktywny moduł CUBE przechodzi ponowne załadowanie zgodnie z projektem, zachowując sygnalizację i nośniki

Konfigurowanie nadmiarowości w obu JEDNOSTKACH CUBE

Należy skonfigurować nadmiarowość warstwy 2 box-to-box w obu KUBE przeznaczonych do użycia w parze HA w celu wywołania wirtualnych adresów IP.

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 dość aktywna 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:

  • redundancy—Enters redundancy mode

  • application redundancy—Enters application redundancy configuration mode

  • group—Enters redundancy application group configuration mode

  • name LocalGateway-HA—Defines the name of the RG group

  • priority 100 failover threshold 75—Specifies the initial priority and failover thresholds for an RG

  • timers delay 30 reload 60—Configures the two times for delay and reload

    • Timer opóźnienia, który jest czasem opóźnienia inicjalizacji grupy RG i negocjacji ról po pojawieniu się interfejsu - domyślnie 30 sekund. Zakres: 0-10000 sekund

    • Ponowne ładowanie — jest to czas potrzebny na opóźnienie inicjowania grupy RG i negocjacji ról po ponownym załadowaniu — domyślnie 60 sekund. Zakres: 0-10000 sekund

    • Zalecane są domyślne timery, chociaż czasomierze te można dostosować do wszelkich dodatkowych opóźnień konwergencji sieci, które mogą wystąpić podczas uruchamiania / przeładowywania routerów, w celu zagwarantowania, że negocjacja protokołu RG odbywa się po zbieżności routingu w sieci do punktu stabilnego. Na przykład, jeśli po przejściu w tryb failover widać, że nowy STANDBY potrzebuje do 20 sekund, aby zobaczyć pierwszy pakiet RG HELLO z nowego ACTIVE, wówczas timery powinny być dostosowane do "timerów opóźniających 60 przeładowania 120", aby uwzględnić to opóźnienie.

  • control GigabitEthernet3 protocol 1—Configures the interface used to exchange keepalive and hello messages between the two CUBEs, and specifies the protocol instance that will be attached to a control interface and enters redundancy application protocol configuration mode

  • data GigabitEthernet3—Configures the interface used for checkpointing of data traffic

  • track—RG group tracking of interfaces

  • protocol 1—Specifies the protocol instance that will be attached to a control interface and enters redundancy application protocol configuration mode

  • timers hellotime 3 holdtime 10—Configures the two timers for hellotime and holdtime:

    • Hellotime — Interwał między kolejnymi wiadomościami powitalnymi — Domyślnie 3 sekundy. Zakres: 250 milisekund -254 sekundy

    • Czas oczekiwania — przerwa między odebraniem wiadomości powitalnej a założeniem, że router wysyłający uległ awarii. Czas ten musi być dłuższy niż czas powitania - Domyślnie 10 sekund. Zakres: 750 milisekund - 255 sekund

      Zaleca się skonfigurowanie czasomierza blokady tak, aby był co najmniej 3 razy większy od wartości czasomierza powitania.

3

Włącz nadmiarowość box-to-box dla aplikacji CUBE. Configure the RG from the previous step under voice service voip. Umożliwia to aplikacji CUBE kontrolowanie procesu 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—Adding and removing this command requires a reload for the updated configuration to take effect. Przeładujemy platformy po zastosowaniu całej konfiguracji.

4

Skonfiguruj interfejsy Gig1 i Gig2 z ich odpowiednimi wirtualnymi adresami IP, jak pokazano poniżej, i zastosuj identyfikator interfejsu nadmiarowości (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:

  • redundancy rii—Configures the redundancy interface identifier for the redundancy group. Wymagane do wygenerowania 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.

    If there is more than one B2B pair on the same LAN, each pair MUST have unique rii IDs on their respective interfaces (to prevent collision). ‘show redundancy application group all’ should indicate the correct local and peer information.

  • redundancy group 1—Associates the interface with the redundancy group created in Step 2 above. Skonfiguruj grupę RG, a także VIP przypisany do tego interfejsu fizycznego.

    Obowiązkowe jest użycie oddzielnego interfejsu dla redundancji, 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 modułu CUBE i załaduj go ponownie.

Platformą do przeładowania jako ostatni jest zawsze Tryb 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 box-to-box działa zgodnie z oczekiwaniami. Odpowiednie dane wyjściowe są wyróżnione pogrubioną czcionką.

Przeładowaliśmy VCUBE-2 jako ostatni i zgodnie z rozważaniami projektowymi; platforma do przeładowania ostatnia zawsze będzie w trybie gotowości. 

 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#

Konfigurowanie bramy lokalnej w obu kubeciach

W naszej przykładowej konfiguracji używamy następujących informacji magistrali z Control Hub do zbudowania konfiguracji bramy lokalnej na obu platformach, VCUBE-1 i VCUBE-2. Nazwa użytkownika i hasło dla tej konfiguracji są następujące:

  • Nazwa użytkownika: Hussain1076_LGU

  • Hasło: lOV12MEaZx

1

Upewnij się, że dla hasła został utworzony klucz konfiguracji z poleceniami pokazanymi poniżej, zanim będzie można go użyć w poświadczeniach lub wspólnych wpisach tajnych. Hasła typu 6 są szyfrowane przy użyciu szyfru AES i tego zdefiniowanego przez użytkownika klucza konfiguracji. 

 LocalGateway#conf t LocalGateway(config)#key config-key password-encrypt Password123 LocalGateway(config)#password encryption aes

Oto konfiguracja bramy lokalnej, która będzie miała zastosowanie do obu platform w oparciu o parametry Control Hub wyświetlane powyżej, zapisz i przeładuj. SIP Digest credentials from Control Hub are highlighted in bold.

 configure terminal crypto pki trustpoint dummyTp revocation-check crl exit sip-ua crypto signaling default trustpoint dummyTp cn-san-validate server transport tcp tls v1.2 end configure terminal crypto pki trustpool import clean url http://www.cisco.com/security/pki/trs/ios_core.p7b end configure terminal voice service voip ip address trusted list ipv4 x.x.x.x y.y.y.y exit allow-connections sip to sip media statistics media bulk-stats no supplementary-service sip refer no supplementary-service sip handle-replaces fax protocol pass-through g711ulaw stun stun flowdata agent-id 1 boot-count 4 stun flowdata shared-secret 0 Password123! sip g729 annexb-all early-offer forced end configure terminal voice class sip-profiles 200 rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)" "sip:\1" rule 10 request ANY sip-header To modify "<sips:(.*)" "<sip:\1" rule 11 request ANY sip-header From modify "<sips:(.*)" "<sip:\1" rule 12 request ANY sip-header Contact modify "<sips:(.*)>" "<sip:\1;transport=tls>" rule 13 response ANY sip-header To modify "<sips:(.*)" "<sip:\1" rule 14 response ANY sip-header From modify "<sips:(.*)" "<sip:\1" rule 15 response ANY sip-header Contact modify "<sips:(.*)" "<sip:\1" rule 20 request ANY sip-header From modify ">" ";otg=hussain1076_lgu>" rule 30 request ANY sip-header P-Asserted-Identity modify "sips:(.*)" "sip:\1" voice class codec 99 codec preference 1 g711ulaw codec preference 2 g711ulaw exit voice class srtp-crypto 200 crypto 1 AES_CM_128_HMAC_SHA1_80 exit voice class stun-usage 200 stun usage firewall-traversal flowdata exit voice class tenant 200 registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tls credentials number Hussain5091_LGU username Hussain1076_LGU password 0 lOV12MEaZx realm Broadworks authentication username Hussain5091_LGU password 0 lOV12MEaZx realm BroadWorks authentication username Hussain5091_LGU password 0 lOV12MEaZx realm 40462196.cisco-bcld.com no remote-party-id sip-server dns:40462196.cisco-bcld.com connection-reuse srtp-crypto 200 session transport tcp tls url sips error-passthru asserted-id pai bind control source-interface GigabitEthernet1 bind media source-interface GigabitEthernet1 no pass-thru content custom-sdp sip-profiles 200 outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com privacy-policy passthru voice class tenant 100 session transport udp url sip error-passthru bind control source-interface GigabitEthernet2 bind media source-interface GigabitEthernet2 no pass-thru content custom-sdp voice class tenant 300 bind control source-interface GigabitEthernet2 bind media source-interface GigabitEthernet2 no pass-thru content custom-sdp voice class uri 100 sip host ipv4:198.18.133.3 voice class uri 200 sip pattern dtg=hussain1076.lgu dial-peer voice 101 voip description Outgoing dial-peer to IP PSTN destination-pattern BAD.BAD session protocol sipv2 session target ipv4:198.18.133.3 voice-class codec 99 voice-class sip tenant 100 dtmf-relay rtp-nte no vad dial-peer voice 201 voip description Outgoing dial-peer to Webex Calling destination-pattern BAD.BAD session protocol sipv2 session target sip-server voice-class codec 99 voice-class stun-usage 200 no voice-class sip localhost voice-class sip tenant 200 dtmf-relay rtp-nte srtp no vad voice class dpg 100 description Incoming WebexCalling(DP200) to IP PSTN(DP101) dial-peer 101 preference 1 voice class dpg 200 description Incoming IP PSTN(DP100) to Webex Calling(DP201) dial-peer 201 preference 1 dial-peer voice 100 voip desription Incoming dial-peer from IP PSTN session protocol sipv2 destination dpg 200 incoming uri via 100 voice-class codec 99 voice-class sip tenant 300 dtmf-relay rtp-nte no vad dial-peer voice 200 voip description Incoming dial-peer from Webex Calling session protocol sipv2 destination dpg 100 incoming uri request 200 voice-class codec 99 voice-class stun-usage 200 voice-class sip tenant 200 dtmf-relay rtp-nte srtp no vad end copy run start

Aby wyświetlić dane wyjściowe polecenia show, ponownie załadowaliśmy VCUBE-2 , a następnie VCUBE-1, czyniąc VCUBE-1 standby CUBE i VCUBE-2 aktywnym CUBE

2

W danym momencie tylko jedna platforma będzie utrzymywać aktywną rejestrację jako brama lokalna z dostępem Webex Calling SBC. Spójrz na dane wyjściowe następujących poleceń pokazu.

pokaż grupę aplikacji redundancji 1

show sip-ua register status 

 VCUBE-1#show redundancy application group 1 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: STANDBY HOT Peer RF state: ACTIVE VCUBE-1#show sip-ua register status VCUBE-1#

 VCUBE-2#show redundancy application group 1 Group ID:1 Group Name:LocalGateway-HA Administrative State: No Shutdown Aggregate operational state : Up My Role: ACTIVE Peer Role: STATUS Peer Presence: Yes Peer Comm: Yes Peer Progression Started: Yes RF Domain: btob-one RF state: ACTIVE Peer RF state: STANDBY HOT VCUBE-2#show sip-ua register status Tenant: 200 --------------------Registrar-Index  1 --------------------- Line peer expires(sec) reg survival P-Associ-URI ============================== ========== ============ === ======== ============ Hussain5091_LGU -1 48 yes normal VCUBE-2#

From the output above, you can see that VCUBE-2 is the active LGW maintaining the registration with Webex Calling access SBC, whereas the output of the “show sip-ua register status” is blank in VCUBE-1

3

Teraz włącz następujące debugowanie na VCUBE-1

 VCUBE-1#debug ccsip non-call SIP Out-of-Dialog tracing is enabled VCUBE-1#debug ccsip info SIP Call info tracing is enabled VCUBE-1#debug ccsip message

4

Symuluj przełączanie awaryjne, wydając następujące polecenie na aktywnym LGW, vCUBE-2 w tym przypadku.

 VCUBE-2#redundancy application reload group 1 self

Przejście z ACTIVE na STANDBY LGW następuje w następującym scenariuszu, a także oprócz interfejsu wiersza polecenia wymienionego powyżej

  • Po ponownym załadowaniu routera ACTIVE

  • Gdy router ACTIVE przełącza się w trybie zasilania

  • Gdy dowolny interfejs routera ACTIVE skonfigurowany w RG jest zamykany, dla którego włączone jest śledzenie

5

Sprawdź, czy VCUBE-1 zarejestrował się w Webex Calling access SBC. VCUBE-2 już by się przeładował.

 VCUBE-1#show sip-ua register status Tenant: 200 --------------------Registrar-Index  1 --------------------- Line peer expires(sec) reg survival P-Associ-URI ============================== ========== ============ === ======== ============ Hussain5091_LGU -1 56 yes normal VCUBE-1#

VCUBE-1 jest teraz aktywnym LGW.

6

Spójrz na odpowiedni dziennik debugowania na VCUBE-1 wysyłając SIP REGISTER do Webex Wywołując VIA wirtualny adres IP i odbierając 200 OK.

 VCUBE-1#show log Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG id 1 Hello Time Expired. Jan 9 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG id 1 role change from Standby to Active Jan 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: SWITCHOVER, from STANDBY_HOT to ACTIVE state. Jan 9 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Received notify active role event Jan 9 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: REGISTER sip: 40462196.cisco-bcld.com:5061 SIP/2.0 Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Date: Thu, 09 Jan 2020 18:37:24 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 User-Agent: Cisco-SIPGateway/IOS-16.12.02 Max-Forwards: 70 Timestamp: 1578595044 CSeq: 2 REGISTER Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expires: 240 Supported: path Content-Length: 0 

Jan 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 Date: Thu, 09 Jan 2020 18:37:24 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Timestamp: 1578595044 CSeq: 2 REGISTER WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5 Content-Length: 0 

Jan 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: REGISTER sip:40462196.cisco-bcld.com:5061 SIP/2.0 Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Date: Thu, 09 Jan 2020 18:37:25 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 User-Agent:Cisco-SIPGateway/IOS-16.12.02 Max-Forwards: 70 Timestamp: 1578595045 CSeq: 3 REGISTER Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expires: 240 Supported: path Authorization: Digest username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001 Content-Length: 0 

Jan 9 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:  Received: SIP/2.0 200 OK Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Timestamp: 1578595045 CSeq: 3 REGISTER Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 Allow-Events: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference Content-Length: 0