Podstawy

Wymagania wstępne

Zanim wdrożysz CUBE HA jako lokalną bramę dla połączeń Webex, upewnij się, że masz dogłębne zrozumienie następujących pojęć:

Wskazówki dotyczące konfiguracji przedstawione w tym artykule zakładają dedykowaną platformę bramy lokalnej bez istniejącej konfiguracji głosowej. Jeśli istniejące wdrożenie CUBE w przedsiębiorstwie jest modyfikowane w celu wykorzystania również funkcji bramy lokalnej dla 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 przestrzegasz wymagań projektowych CUBE HA .

Składniki 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 show i dzienniki w tym artykule są oparte na minimalnej wersji oprogramowania Cisco IOS-XE 16.12.2 zaimplementowanej na vCUBE (CSR1000v).

Materiał referencyjny

Oto szczegółowe instrukcje konfiguracji CUBE HA dla różnych platform:

Omówienie rozwiązania telefonicznego Webex

Cisco Webex Calling to oferta współpracy oferująca wielu dzierżawcom opartą na chmurze alternatywę dla lokalnej usługi telefonicznej PBX z wieloma opcjami PSTN dla klientów.

W tym artykule skupiono się na wdrażaniu bramy lokalnej (przedstawionej poniżej). Lokalna brama (PSTN oparta na siedzibie) trunk w usłudze Webex Calling umożliwia łączność z usługą PSTN należącą do klienta. Zapewnia również łączność z lokalnymi wdrożeniami IP PBX, takimi jak Cisco Unified CM. Cała komunikacja do iz chmury jest zabezpieczona przy użyciu transportu TLS dla SIP i SRTP dla mediów.

Poniższy rysunek przedstawia wdrożenie Webex Calling bez żadnej istniejącej centrali IP PBX i ma zastosowanie do pojedynczego lub wielu lokalizacji. Konfiguracja opisana w tym artykule jest oparta na tym wdrożeniu.

Nadmiarowość między skrzynkami w warstwie 2

Nadmiarowość CUBE HA w warstwie 2 typu box-to-box wykorzystuje protokół infrastruktury Redundancy Group (RG) do utworzenia pary routerów aktywna / w gotowości. Ta para ma ten sam wirtualny adres IP (VIP) na swoich odpowiednich interfejsach i stale wymienia komunikaty o stanie. Informacje o sesji CUBE są kontrolowane przez parę routerów, co umożliwia routerowi rezerwowemu natychmiastowe przejęcie wszystkich obowiązków związanych z przetwarzaniem połączeń CUBE, jeśli aktywny router przestanie działać, co skutkuje zachowaniem stanu sygnalizacji i mediów.


Wskazanie kontrolne jest ograniczone do połączonych połączeń z pakietami multimedialnymi. Połączenia w drodze nie są oznaczane (na przykład stan próbujący lub dzwoniący).

W tym artykule CUBE HA będzie odnosić się do nadmiarowości CUBE High Availability (HA) Layer 2 Box-to-box (B2B) w celu zachowania stanu połączeń

Począwszy od IOS-XE 16.12.2, CUBE HA można wdrożyć jako bramę lokalną dla wdrożeń łącza trunkingowego Cisco Webex Calling (PSTN w siedzibie). W tym artykule omówimy zagadnienia projektowe i konfiguracje. Ten rysunek przedstawia typową konfigurację CUBE HA jako bramy lokalnej dla wdrożenia łącza trunk Cisco Webex Calling.

Komponent Infra grupy redundancji

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

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

  • Mechanizm transportowy dla punktów kontrolnych sygnalizacji i stanu mediów dla każdego połączenia z routera aktywnego do rezerwowego (przez interfejs 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ą traktowane jako 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 mediów

B2B HA opiera się na VIP, aby osiągnąć redundancję. VIP i powiązane fizyczne interfejsy 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 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 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 pojedyncza brama lokalna.

Sygnalizacja połączenia i informacje o sesji RTP nawiązanych połączeń są punktami kontrolnymi od aktywnego routera do routera rezerwowego. Gdy router aktywny przestaje działać, router w trybie gotowości 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łączenia awaryjnego nie zostaną zachowane 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 transferu lub wstrzymania. Nawiązane 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 połączeń:

  • CUBE HA nie może mieć równoległych interfejsów TDM lub analogowych

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

  • Nie więcej niż 2 pary CUBE HA mogą być umieszczone w tej samej domenie warstwy 2, jedna o identyfikatorze grupy 1, a druga o identyfikatorze grupy 2. W przypadku konfigurowania 2 par 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 RG Control / danych, jak i interfejsów ruchu

  • Cała sygnalizacja / media są pobierane z / do wirtualnego adresu IP

  • Za każdym razem, gdy platforma jest ponownie ładowana w relacji CUBE-HA, zawsze uruchamia się w trybie gotowości

  • Niższy 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 w tej samej warstwie 2

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

  • Interfejsy Loopback nie mogą być używane jako bind, ponieważ zawsze działają

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

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

  • Obie platformy muszą być identyczny i być połączony za pośrednictwem fizyczny przełącznik na wszystkich interfejsach, aby CUBE HA działał, tj. GE0 / 0/0 CUBE-1 i CUBE-2 musi kończyć się tym samym przełącznikiem i tak dalej.

  • Nie można zakończyć WAN bezpośrednio na CUBE lub danych HA po obu stronach

  • Zarówno tryb aktywny, jak i tryb gotowości muszą znajdować się w tym samym centrum danych

  • Konieczne jest użycie oddzielnego interfejsu L3 w celu zapewnienia redundancji (RG Control / data, Gig3). tj. interfejs używany do ruchu nie może być używany do utrzymywania aktywności HA i punktów kontrolnych

  • Po przełączeniu awaryjnym poprzednio aktywny CUBE przechodzi ponowne ładowanie zgodnie z projektem, zachowując sygnalizację i media

Skonfiguruj nadmiarowość na obu modułach CUBE

Aby wywołać wirtualne adresy IP, należy skonfigurować nadmiarowość warstwy 2 typu box-to-box na obu modułach CUBE, które mają być używane 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

Śledzenie CLI jest używane w RG do śledzenia stanu interfejsu ruchu głosowego, dzięki czemu aktywna trasa będzie pełniła swoją aktywną rolę po wyłączeniu interfejsu ruchu.

2

Skonfiguruj RG do użytku z VoIP HA w trybie podrzędnym 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żywanych w tej konfiguracji:

  • nadmierność—Tryb redundancji wejść

  • nadmiarowość aplikacji—Włącza tryb konfiguracji nadmiarowości aplikacji

  • Grupa—Włącza tryb konfiguracji grupy aplikacji z redundancją

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

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

  • timery opóźnienie 30 przeładowanie 60—Konfiguruje dwa czasy opóźnienia i ponownego załadowania

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

    • Przeładowanie - jest to ilość czasu do opóźnienia inicjalizacji grupy RG i negocjacji ról po przeładowaniu - domyślnie 60 sekund. Zakres wynosi 0-10000 sekund

    • Zalecane są domyślne timery, chociaż te timery mogą być regulowane w celu uwzględnienia wszelkich dodatkowych opóźnień zbieżności sieci, które mogą wystąpić podczas rozruchu / ponownego ładowania routerów, aby zagwarantować, że negocjacja protokołu RG ma miejsce po osiągnięciu przez routing w sieci stabilnego punkt. Na przykład, jeśli po przełączeniu awaryjnym okaże się, że nowy pakiet STANDBY potrzebuje do 20 sekund, aby zobaczyć pierwszy pakiet RG HELLO z nowego ACTIVE, wówczas zegary powinny być ustawione na `` timers delay 60 reload 120 '', aby uwzględnić to opóźnienie.

  • sterowanie protokołem GigabitEthernet3 1—Konfiguruje interfejs używany do wymiany wiadomości utrzymywania aktywności i powitania między dwoma modułami CUBE oraz określa instancję protokołu, która zostanie dołączona do interfejsu sterującego i przechodzi w tryb konfiguracji protokołu aplikacji nadmiarowości

  • dane GigabitEthernet3—Konfiguruje interfejs używany do kontrolowania ruchu danych

  • tor—RG grupowe śledzenie interfejsów

  • protokół 1—Określa instancję protokołu, która zostanie dołączona do interfejsu sterującego i przejdzie do trybu konfiguracji protokołu aplikacji nadmiarowości

  • timery hellotime 3 holdtime 10—Konfiguruje dwa liczniki czasu hellotime i holdtime:

    • Hellotime - odstęp czasu między kolejnymi wiadomościami hello - domyślnie 3 sekundy. Zakres wynosi od 250 milisekund do 254 sekund

    • Holdtime - odstęp czasu między odebraniem wiadomości Hello a założeniem, że router wysyłający nie powiódł się. Ten czas trwania musi być dłuższy niż czas powitania - domyślnie 10 sekund. Zakres wynosi 750 milisekund-255 sekund

      Zalecamy skonfigurowanie licznika czasu przetrzymania na co najmniej trzykrotną wartość licznika czasu hellotime.

3

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

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

grupa redundancyjna 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 ich odpowiednimi wirtualnymi adresami 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żywanych w tej konfiguracji:

  • redundancja rii—Konfiguruje identyfikator interfejsu nadmiarowości dla grupy nadmiarowości. Wymagane do generowania adresu Virtual MAC (VMAC). Ta sama wartość rii ID musi być użyta w interfejsie każdego routera (AKTYWNY / GOTOWOŚĆ), który ma ten sam adres VIP.


     

    Jeśli w tej samej sieci LAN znajduje się więcej niż jedna para B2B, każda para MUSI mieć unikalne identyfikatory rii ID na swoich odpowiednich interfejsach (aby zapobiec kolizjom). „Pokaż grupę aplikacji nadmiarowości wszystkie” powinno wskazywać poprawne informacje lokalne i równorzędne.

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


     

    Konieczne jest użycie oddzielnego interfejsu w celu zapewnienia redundancji, co oznacza, że 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.

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 VCUBE-1 uruchamia się całkowicie, zapisz konfigurację VCUBE-2 i załaduj 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 są wyróżnione w pogrubienie.

Ponownie załadowaliśmy VCUBE-2 ostatni i zgodnie z rozważaniami projektowymi; platforma do przeładowania jako ostatnia zawsze będzie Czekaj.


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#

Skonfiguruj bramę lokalną na obu modułach CUBE

W naszej przykładowej konfiguracji używamy następujących informacji o łączu trunkingowym z Control Hub do tworzenia 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 klucz konfiguracyjny został utworzony dla hasła za pomocą poleceń pokazanych poniżej, zanim będzie można go użyć w poświadczeniach lub wspólnych hasłach. Hasła typu 6 są szyfrowane przy użyciu 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 Control Hub parametry wyświetlone powyżej, zapisz i załaduj ponownie. Poświadczenia SIP Digest z Control Hub są wyróżnione w pogrubienie.


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, załadowaliśmy ponownie VCUBE-2 śledzony przez VCUBE-1, robiąc VCUBE-1 w trybie gotowości CUBE i VCUBE-2 aktywny CUBE

2

W danym momencie tylko jedna platforma będzie utrzymywać aktywną rejestrację jako Brama Lokalna z dostępem do usługi Webex Calling SBC. Przyjrzyj się wynikom następujących poleceń show.

pokaż grupę aplikacyjną 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 wyniku widać to VCUBE-2 jest aktywną LGW utrzymującą rejestrację z dostępem do usługi Webex Calling SBC, podczas gdy wyjście „show sip-ua register status” jest puste w 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, w tym przypadku VCUBE-2.


VCUBE-2#redundancy application reload group 1 self

Przełączenie z AKTYWNEGO na STANDBY LGW ma miejsce również w następującym scenariuszu oprócz CLI wymienionego powyżej

  • Po ponownym załadowaniu routera ACTIVE

  • Gdy router ACTIVE włącza się ponownie

  • Gdy którykolwiek interfejs routera ACTIVE skonfigurowany jako RG zostanie wyłączony, dla którego włączone jest śledzenie

5

Sprawdź, czy VCUBE-1 zarejestrował się w usłudze Webex Calling access SBC. VCUBE-2 już by się zał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ący SIP REGISTER do Webex Wywołując wirtualny adres IP i otrzymują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