Podstawy

Wymagania wstępne

Przed wdrożeniem CUBE HA jako bramy lokalnej Webex Calling upewnij się, że masz dogłębną wiedzę na temat następujących pojęć:

Wskazówki dotyczące konfiguracji podane w tym artykule zakładają dedykowaną platformę bramy lokalnej bez istniejącej konfiguracji głosu. Jeśli istniejące wdrożenie w przedsiębiorstwie CUBE jest modyfikowane w celu wykorzystania również lokalnej funkcji bramy dla usługi Cisco Webex Calling, zwróć szczególną uwagę na zastosowaną konfigurację, aby zapewnić, że istniejące przepływy połączeń i funkcje nie zostaną przerwane i upewnij się, że spełniasz wymagania projektowe CUBE HA.

Elementy sprzętu i oprogramowania

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

Polecenia i dzienniki pokazu w tym artykule są oparte na minimalnej wersji oprogramowania Cisco IOS-XE 16.12.2 wdrożonej na vCUBE (CSR141 v).

Materiał referencyjny

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

Przegląd rozwiązania Webex Calling

Cisco Webex Calling to oferta współpracy, która stanowi alternatywę dla lokalnych usług telefonicznych centrali PBX z wieloma opcjami PSTN dla klientów.

W tym artykule skupiono się na wdrożeniu bramy lokalnej (przedstawionej poniżej). Lokalne łącze magistralowe bramy (PSTN oparte na lokalizacjach) w usłudze Webex Calling umożliwia połączenie z usługą PSTN należącą do klienta. Zapewnia również łączność z lokalnymi wdrożeniami centrali PBX IP, takimi jak Cisco Unified CM. Cała komunikacja do i z chmury jest zabezpieczona za pomocą transportu TLS dla mediów SIP i SRTP.

Poniższa ilustracja wyświetla wdrożenie usługi Webex Calling bez żadnej istniejącej centrali PBX IP i dotyczy wdrożenia pojedynczego lub wieloplatformowego. Konfiguracja opisana w tym artykule opiera się na tym wdrożeniu.

Warstwa 2 Skrzynka do skrzynki Redundancy

Zwolnienie typu box-to-box w warstwie CUBE HA 2 wykorzystuje protokół infrastruktury Redundancy Group (RG), aby utworzyć aktywną/gotową parę routerów. Ta para udostępnia ten sam wirtualny adres IP (VIP) poprzez odpowiednie interfejsy i stale wymienia komunikaty o stanie. Informacje o sesji CUBE są sprawdzane w parze routerów, umożliwiając router standby przejąć wszystkie obowiązki przetwarzania połączeń CUBE natychmiast, jeśli aktywny router wychodzi z usługi, co skutkuje stateful konserwacji sygnalizacji i mediów.

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

W tym artykule CUBE HA będzie odnosić się do CUBE High Availability (HA) Layer 2 Box-to-box (B2B) redundancja dla stateful call preservation

Od IOS-XE 16.12.2 CUBE HA może być wdrożony jako brama lokalna dla wdrożeń Cisco Webex Calling trunk (Lokalna sieć PSTN), a w tym artykule omówimy kwestie projektowe i konfiguracje. Na tej ilustracji jest wyświetlana typowa konfiguracja CUBE HA jako bramy lokalnej dla wdrażania magistrali Cisco Webex Calling.

Komponent Infra Grupy Redundancy

Element Redundancy Group (RG) Infra zapewnia obsługę infrastruktury komunikacyjnej box-to-box między dwoma CUBEs i negocjuje ostateczny stabilny stan redundancji. Element ten zawiera również:

  • Protokół podobny do HSRP, który negocjuje ostateczny stan zwolnienia dla każdego routera poprzez wymianę wiadomości keepalive i hello między dwoma CUBEs (za pośrednictwem interfejsu sterowania) — GigabitEthernet3 na powyższej ilustracji.

  • Mechanizm transportu służący do sprawdzania stanu sygnalizacji i multimediów dla każdego połączenia z aktywnego routera czuwania (za pośrednictwem interfejsu danych) — GigabitEthernet3 na powyższej ilustracji.

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

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

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

B2B HA polega na VIP do osiągnięcia redundancji. VIP i powiązane interfejsy fizyczne na obu CUBEs w CUBE HA para musi mieszkać na tej samej podsieci LAN. Konfiguracja interfejsu 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, dostęp do SBC, dostawca usług lub serwer 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 jedna brama lokalna.

Informacje o sygnalizacji połączeń i sesji RTP nawiązanych połączeń są zaznaczane z aktywnego routera do routera czuwania. Gdy router Active schodzi w dół, router Standby przejmuje i kontynuuje przekazywanie strumienia RTP, który wcześniej był kierowany przez pierwszy router.

Połączenia w stanie przejściowym w czasie przełączenia awaryjnego nie zostaną zachowane po przełączeniu. Na przykład połączenia, które nie zostały jeszcze w pełni nawiązane lub są w trakcie modyfikowania za pomocą funkcji przekazywania lub wstrzymywania. Połączenia nawiązane mogą być odłączane po przełączeniu.

Następujące wymagania dotyczą korzystania z CUBE HA jako bramy lokalnej do stanowego przekierowywania połączeń:

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

  • Gig1 i Gig2 są określane jako interfejsy ruchu (SIP/RTP), a Gig3 to Redundancy Group (RG) Control/data interface

  • Nie więcej niż 2 pary CUBE HA mogą być umieszczone w tej samej domenie warstwy 2, jedna z identyfikatorem grupy 1, a druga z identyfikatorem grupy 2. Jeśli konfiguracja 2 par HA z tym samym identyfikatorem grupy, interfejsy RG Control/Data muszą należeć do różnych domen warstwy 2 (vlan, osobny przełącznik)

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

  • Wszystkie sygnały/nośniki są pozyskiwane z/do wirtualnego adresu IP

  • Za każdym razem platforma jest ponownie załadowana w związku CUBE-HA, zawsze uruchamia się jako Standby

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

  • Redundancy Interface Identifier, rii powinien być unikalny dla kombinacji para / interfejs na tej samej Warstwie 2

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

  • Interfejsy Loopback nie mogą być używane jako złącze, ponieważ są zawsze aktywne

  • Interfejsy wielokrotnego ruchu (SIP/RTP) (Gig1, Gig2) wymagają skonfigurowania śledzenia interfejsu

  • CUBE-HA nie jest obsługiwana przez przewód zwrotnicy dla łącza RG-control/data (Gig3)

  • Obie platformy muszą być identyczne i muszą być połączone za pośrednictwem Wyłącznik fizyczny we wszystkich podobnych interfejsach dla CUBE HA do pracy, tj. GE0/0/0 CUBE-1 i CUBE-2 musi zakończyć na tym samym przełączniku i tak dalej.

  • Nie można zamknąć sieci WAN bezpośrednio na CUBEs lub Dane HA po obu stronach

  • Zarówno Active/Standby musi znajdować się w tym samym centrum danych

  • Niezbędne jest używanie oddzielnego interfejsu L3 dla nadmiarowości (RG Control/data, Gig3), tzn. interfejs używany do ruchu nie może być używany do keepalives HA i kontrolowania

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

Konfigurowanie Redundancy na Obu CUBEACH

Aby wywołać wirtualne adresy IP, należy skonfigurować nadmiarowość warstwy 2 w przypadku obu CUBEs przeznaczonych do użycia w parze HA.

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 tak, że aktywna trasa będzie dość jego aktywną rolę po interfejs ruchu jest w dół.

2

Skonfiguruj RG do użycia 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)#

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

  • nadmiarowość— wprowadza tryb nadmiarowości

  • redundancja aplikacji— wprowadza tryb konfiguracji redundancji aplikacji

  • grupa— wprowadza tryb konfiguracji grupy aplikacji redundancji

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

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

  • opóźnienie 30 ponownego obciążenia 60— konfiguruje dwa razy opóźnienie i ponowne obciążenie

    • Czas opóźnienia, który jest czasem opóźnienia inicjowania i negocjowania ról grupy RG po pojawieniu się interfejsu – Domyślne 30 sekund. Zasięg wynosi 0-10000 sekund

    • Załaduj ponownie — jest to czas na opóźnienie inicjalizacji grupy RG i negocjacji ról po ponownym załadowaniu — domyślnie 60 sekund. Zasięg wynosi 0-10000 sekund

    • Zalecane są domyślne czasomierze, chociaż czasomierze te można dostosować tak, aby uwzględnić wszelkie dodatkowe opóźnienie konwergencji sieci, które może wystąpić podczas uruchamiania/ponownego ładowania routerów, w celu zagwarantowania, że negocjacje protokołu RG odbywają się po osiągnięciu stabilnego punktu przekierowania w sieci. Na przykład, jeśli po przełączeniu awaryjnym okaże się, że pierwsze pakiety RG HELLO z nowego AKTYWNEGO urządzenia STANDBY będą widoczne dopiero po 20 sek., timery powinny zostać wyregulowane tak, aby „timers delay 60 reload 120” uwzględniało to opóźnienie.

  • sterowanie protokołem GigabitEthernet3 1 — konfiguruje interfejs używany do wymiany wiadomości keepalive i hello między dwoma CUBEs oraz określa wystąpienie protokołu, które zostanie dołączone do interfejsu sterowania i przejdzie w tryb konfiguracji protokołu aplikacji redundancji

  • dane GigabitEthernet3— konfiguruje interfejs używany do sprawdzania ruchu danych

  • śledzenie — śledzenie interfejsów w grupie RG

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

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

    • Hellotime — interwał między kolejnymi wiadomościami powitalnymi — domyślnie 3 sekundy. Zakres wynosi 250 milisekund-254 sekundy

    • Holdtime — Odstęp między otrzymaniem wiadomości Hello a domniemaniem, że wysyłający router nie powiódł się. Czas ten musi być dłuższy niż czas przywitania – domyślnie 10 sekund. Zasięg to 750 milisekund-255 sekund

      Zalecamy skonfigurowanie czasomierza holdtime jako co najmniej 3-krotnej wartości czasomierza hellotime.

3

Włącz redundancję typu box-to-box dla aplikacji CUBE. Skonfiguruj RG z poprzedniego kroku pod voice service voip. Umożliwia to aplikacji CUBE sterowanie procesem 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

redundancja-grupa 1 — dodanie i usunięcie tego polecenia wymaga ponownego załadowania, aby zaktualizowana konfiguracja zaczęła działać. Po zastosowaniu całej konfiguracji ponownie załadujemy platformy.

4

Skonfiguruj interfejsy Gig1 i Gig2 z ich odpowiednimi wirtualnymi IP, jak pokazano 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

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

  • redundancja rii— konfiguruje identyfikator interfejsu redundancji dla grupy redundancji. Wymagane do wygenerowania wirtualnego adresu MAC (VMAC). Ta sama wartość ID rii musi być używana w interfejsie każdego routera (ACTIVE/STANDBY), który ma tego samego VIP.

    Jeśli w tej samej sieci LAN jest więcej niż jedna para B2B, każda para MUSI mieć unikalne identyfikatory rii na swoich interfejsach (aby zapobiec kolizji). „pokaż wszystkie grupy aplikacji nadmiarowych” powinny wskazywać prawidłowe informacje lokalne i informacje równorzędne.

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

    Obowiązkowe jest używanie oddzielnego interfejsu dla nadmiarowości, czyli interfejsu używanego do przesyłania głosu nie można używać jako interfejsu sterowania i transmisji danych określonego 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 przeładowania ostatni jest zawsze Standby.

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 wyniki zostały podkreślone pogrubioną czcionką.

Przeładowaliśmy ostatnio VCUBE-2 i zgodnie z założeniami projektowymi, platforma do ponownego załadunku będzie zawsze czuwana.


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 na Obu CUBEach

W naszej przykładowej konfiguracji korzystamy z następujących informacji magistrali z Control Hub, aby zbudować konfigurację bramy lokalnej zarówno na platformach VCUBE-1, jak i VCUBE-2. Nazwa użytkownika i hasło tej konfiguracji są następujące:

  • Nazwa użytkownika: Hussain1076_LGU

  • Hasło: lOV12MEaZx

1

Upewnij się, że dla hasła został utworzony klucz konfiguracyjny z pokazanymi poniżej poleceniami, zanim będzie można go użyć w poświadczeniach lub udostępnionych tajemnicach. Hasła typu 6 są szyfrowane za pomocą szyfru AES i tego klucza konfiguracyjnego zdefiniowanego przez użytkownika.


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, zapisywanie i przeładowywanie. Poświadczenia SIP Digest z Control Hub są wyróżnione pogrubioną czcionką.


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ć wyjście polecenia pokazu, ponownie załadowaliśmy VCUBE-2 , a następnie VCUBE-1, dzięki czemu VCUBE-1 jest w stanie gotowości CUBE, a VCUBE-2 jest aktywnym CUBE

2

W danym momencie tylko jedna platforma będzie utrzymywać aktywną rejestrację jako brama lokalna z dostępem do usługi SBC usługi Webex Calling. Zapoznaj się z wynikami następujących poleceń pokazu.

pokazać grupę aplikacji redundancji 1

Pokaż status rejestru sip-ua


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#

Z powyższego wyjścia można zobaczyć, że VCUBE-2 jest aktywnym LGW utrzymującym rejestrację w usłudze SBC dostępu Webex Calling, podczas gdy wyjście „show sip-ua register status” jest puste w VCUBE-1

3

Teraz włącz następujące debugowanie w 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 błąd, wydając następujące polecenie na aktywnym LGW, VCUBE-2 w tym przypadku.


VCUBE-2#redundancy application reload group 1 self

Przełączenie z AKTYWNEGO na STANDBY LGW następuje w następującym scenariuszu, a także poza wyżej wymienionym CLI

  • Podczas ponownego ładowania AKTYWNEGO routera

  • Gdy AKTYWNE cykle zasilania routera

  • Gdy dowolny skonfigurowany interfejs RG routera AKTYWNEGO jest wyłączony, dla którego śledzenie jest włączone

5

Sprawdź, czy VCUBE-1 zarejestrowała się w usłudze SBC dostępu Webex Calling. 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

Zapoznaj się z odpowiednim dziennikiem debugowania na VCUBE-1 wysyłającym REJESTR SIP do Webex Calling ZA POŚREDNICTWEM wirtualnego IP i odbierającym 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