Grundlagen

Voraussetzungen

Bevor Sie CUBE HA als lokales Gateway für Webex Calling bereitstellen, sollten Sie über fundierte Kenntnisse der folgenden Konzepte verfügen:

Die Konfigurationsrichtlinien in diesem Artikel gehen von einer dedizierten lokalen Gateway-Plattform ohne vorhandene Sprachkonfiguration aus. Wenn eine bestehende CUBE Enterprise-Bereitstellung geändert wird, um auch die lokale Gateway-Funktion für Cisco Webex Calling zu nutzen, achten Sie auf die angewendete Konfiguration, um sicherzustellen, dass vorhandene Anrufverläufe und Funktionen nicht unterbrochen werden, und stellen Sie sicher, dass Sie die Designanforderungen von CUBE HA erfüllen.

Hardware- und Softwarekomponenten

CUBE HA als lokales Gateway erfordert IOS-XE in der Version 16.12.2 oder höher sowie eine Plattform, auf der sowohl CUBE HA- als auch LGW-Funktionen unterstützt werden.

Die angezeigten Befehle und Protokolle in diesem Artikel basieren auf der Mindest-Softwareversion Cisco IOS-XE 16.12.2, die auf einem vCUBE (CSR1000v) implementiert wurde.

Referenzmaterial

Hier sind einige ausführliche Konfigurationsleitfäden für CUBE HA für verschiedene Plattformen:

Übersicht der Webex Calling-Lösung

Cisco Webex Calling ist ein Zusammenarbeitsangebot, das eine Cloud-basierte Multi-Tenant-Alternative zu lokalen PBX-Telefondiensten mit mehreren PSTN-Optionen für Kunden bietet.

Die Bereitstellung des lokalen Gateways (siehe unten) ist der Schwerpunkt dieses Artikels. Der lokale Gateway-Trunk (lokales PSTN) in Webex Calling ermöglicht die Verbindung mit einem kundenseitigen PSTN-Dienst. Außerdem stellt er die Verbindung zu einer lokalen IP-PBX-Bereitstellung her, wie Cisco Unified CM. Die gesamte Kommunikation von und zur Cloud ist durch den TLS-Transport für SIP und SRTP für Medien gesichert.

Die folgende Abbildung zeigt eine Webex Calling-Bereitstellung ohne vorhandene IP-PBX und kann bei Einzel- oder Multisite-Bereitstellungen verwendet werden. Die Konfiguration, die in diesem Artikel beschrieben wird, basiert auf dieser Bereitstellung.

Box-to-Box-Redundanz Schicht 2

Die Box-to-Box-Redundanz von CUBE HA in Schicht 2 nutzt das Infrastrukturprotokoll der Redundanzgruppe (RG), um ein Paar aus aktivem und Standby-Router zu bilden. Dieses Paar hat eine gemeinsame virtuelle IP-Adresse (VIP) über die jeweiligen Schnittstellen hinweg und tauscht kontinuierlich Statusmeldungen aus. Die CUBE-Sitzungsinformationen durchlaufen Prüfpunkte des Routerpaares, so dass der Standby-Router die Verantwortung für die gesamte CUBE-Anrufverarbeitung sofort übernehmen kann, wenn der aktive Router ausfällt. Dies führt zur zustandsbehafteten Erhaltung von Signalisierung und Medien.

Die Prüfpunkte sind auf verbundene Anrufe mit Medienpaketen beschränkt. Transitanrufe durchlaufen den Prüfpunkt nicht (beispielsweise ein Anrufversuch oder Ruftonstatus).

In diesem Artikel bezieht sich CUBE HA auf die Box-to-Box-Redundanz (B2B) von CUBE High Availability (HA) in Schicht 2 für die zustandsbehaftete Anrufbeibehaltung.

Ab IOS-XE 16.12.2 kann CUBE HA als lokales Gateway für Trunk-Bereitstellung von Cisco Webex Calling (lokales PSTN) bereitgestellt werden, und in diesem Artikel gehen wir auf Designüberlegungen und Konfigurationen ein. Die folgende Abbildung zeigt eine typische CUBE HA-Einrichtung als lokales Gateway für eine Trunk-Bereitstellung von Cisco Webex Calling.

Infra-Komponente der Redundanzgruppe

Die Infra-Komponente der Redundanzgruppe (RG) stellt die Unterstützung für die Box-to-Box-Kommunikationsinfrastruktur zwischen den beiden CUBEs bereit und handelt den endgültigen stabilen Redundanzstatus aus. Diese Komponente bietet außerdem:

  • Ein HSRP-ähnliches Protokoll, das den endgültigen Redundanzstatus für jeden Router aushandelt, indem zwischen den beiden CUBEs (über die Steuerungsschnittstelle) Keepalive- und Hello-Nachrichten ausgetauscht werden (in der Abbildung oben GigabitEthernet3).

  • Ein Transportmechanismus zur Kontrolle der Signalisierung und des Medienstatus durch Prüfpunkte für jeden Anruf vom aktiven zum Standby-Router (über die Datenschnittstelle) (in der Abbildung oben GigabitEthernet3).

  • Konfiguration und Verwaltung der virtuellen IP(VIP)-Schnittstelle für die Datenverkehrsschnittstellen (mehrere Schnittstellen können mit derselben RG-Gruppe konfiguriert werden). GigabitEthernet 1 und 2 werden als Verkehrsschnittstellen betrachtet.

Diese RG-Komponente muss speziell für die Unterstützung von Voice B2B HA konfiguriert werden.

Verwaltung von virtuellen IP-Adressen (VIP) für Signalisierung und Medien

B2B HA nutzt VIP, um Redundanz zu erzielen. Die VIP und die dazugehörigen physischen Schnittstellen in beiden CUBEs des CUBE HA-Paares müssen sich im selben LAN-Subnetz befinden. Die Konfiguration der VIP und die Bindung der VIP-Schnittstelle an eine bestimmte Sprachanwendung (SIP) sind für die Unterstützung von Sprach-B2B-HA zwingend erforderlich. Externe Geräte wie Unified CM, Zugriffs-SBC von Webex Calling, Dienstleister oder Proxy verwenden die VIP-Adresse als Ziel-IP-Adresse für Anrufe, die die CUBE HA-Router passieren. Aus Sicht von Webex Calling fungiert das CUBE HA-Paar als ein lokales Gateway.

Die Anrufsignalisierung und RTP-Sitzungsinformationen von hergestellten Anrufen werden über einen Prüfpunkt vom aktiven Router zum Standby-Router geleitet. Wenn der aktive Router ausfällt, übernimmt der Standby-Router und leitet den RTP-Stream weiter, der zuvor vom ersten Router geroutet wurde.

Anrufe, die sich zum Zeitpunkt des Failovers in einem Übergangszustand befanden, bleiben nach dem Umschalten nicht erhalten. Beispiel: Anrufe, die noch nicht vollständig hergestellt waren oder gerade mit einer Funktion zur Übergabe oder zum Halten geändert wurden. Hergestellte Anrufverbindungen werden nach dem Umschalten möglicherweise getrennt.

Für die Verwendung von CUBE HA als lokales Gateway für den zustandsbehafteten Failover von Anrufen gelten die folgenden Anforderungen:

  • CUBE HA kann weder mit TDM noch analogen Schnittstellen zusammengestellt werden.

  • Gig1 und Gig2 werden als Datenverkehrsschnittstellen (SIP/RTP) und Gig3 als Steuerungs-/Datenschnittstelle der Redundanzgruppe (RG) bezeichnet.

  • Es können nicht mehr als 2 CUBE HA-Paare in derselben Schicht-2-Domäne platziert werden, eines mit der Gruppen-ID 1 und das andere mit der Gruppen-ID 2. Wenn 2 HA-Paare mit derselben Gruppen-ID konfiguriert werden, müssen die RG-Steuerungs-/Datenschnittstellen zu unterschiedlichen Schicht-2-Domänen gehören (VLAN, separater Switch).

  • Portkanal wird sowohl für die RG-Steuerung-/Datenschnittstellen als auch für Datenverkehrsschnittstellen unterstützt.

  • Alle Signalisierungen/Medien werden von/an die virtuelle IP-Adresse gesendet.

  • Wann immer eine Plattform in einer CUBE-HA-Beziehung neu geladen wird, startet sie als Standby-System.

  • Der untere Adressteil für alle Schnittstellen (Gig1, Gig2, Gig3) sollte auf derselben Plattform sein.

  • Der Bezeichner der Redundanzschnittstelle (RII) sollte für eine Paar-/Schnittstellenkombination auf derselben Schicht 2 eindeutig sein.

  • Die Konfiguration auf beiden CUBEs muss identisch sein, einschließlich der physischen Konfiguration, und muss auf derselben Art von Plattform und derselben IOS-XE-Version ausgeführt werden.

  • Loopback-Schnittstellen können nicht als Bindung verwendet werden, da sie immer aktiv sind.

  • Mehrere Verkehrsschnittstellen (SIP/RTP, Gig1, Gig2) erfordern das Konfigurieren von Schnittstellennachverfolgung.

  • CUBE-HA wird nicht über eine Crossover-Kabelverbindung für den RG-Steuerungs-/Datenlink (Gig3) überstützt.

  • Beide Plattformen müssen identisch sein und über einen physischen Switch über alle ähnlichen Schnittstellen verbunden werden, damit CUBE HA funktioniert, d. h. GE0/0/0 von CUBE-1 und CUBE-2 muss auf demselben Switch enden usw.

  • WAN kann nicht direkt auf den CUBEs oder Data HA auf einer der Seiten enden.

  • Sowohl der aktive als auch der Standby-Router müssen im selben Rechenzentrum sein.

  • Für Redundanz ist die Verwendung einer separaten L3-Schnittstelle erforderlich (RG-Steuerungs-/Datenschnittstelle, Gig3), d. h. die für Datenverkehr verwendete Schnittstelle kann nicht für HA-Keepalives und Prüfpunkte verwendet werden.

  • Beim Failover durchläuft der zuvor aktive CUBE designbedingt ein erneutes Laden, wobei Signalisierung und Medien beibehalten werden.

Konfigurieren von Redundanz auf beiden CUBEs

Sie müssen die Box-to-Box-Redundanz der Schicht 2 auf beiden CUBEs konfigurieren, die in einem HA-Paar verwendet werden sollen, um virtuelle IP-Adressen zu erstellen.

1

Konfigurieren Sie die Schnittstellennachverfolgung auf globaler Ebene, um den Status der Schnittstelle zu überwachen.

Conf t 
 Track 1 Schnittstelle GigabitEthernet1 Line-Protocol 
 Track 2 Schnittstelle GigabitEthernet2 Line-Protocol-Exit 

V CUBE-1#conf t

VCUBE-1(config)#track 1-Schnittstelle GigabitEthernet1-Leitungsprotokoll

VCUBE-1(config-track)#track 2-Schnittstelle GigabitEthernet2-Leitungsprotokoll

VCUBE-1(config-track)#beenden

V CUBE-2#conf t

VCUBE-2(config)#track 1-Schnittstelle GigabitEthernet1-Leitungsprotokoll

VCUBE-2(config-track)#track 2-Schnittstelle GigabitEthernet2-Leitungsprotokoll

VCUBE-2(config-track)#beenden

Track CLI wird in RG verwendet, um den Zustand der Sprachverkehrsschnittstelle zu verfolgen, damit die aktive Route ihre aktive Rolle aufgibt, nachdem die Verkehrsschnittstelle ausgefallen ist.

2

Konfigurieren Sie eine RG für die Verwendung mit VoIP HA im Untermodus der Applikationsredundanz.

Redundanz-Anwendung Redundanz Gruppe 
 
   1 
    Name LocalGateway-HA Priorität 100 Ausfallsicherungs-Schwellenwert 
    75 
    Control GigabitEthernet3 Protokoll 1 
    Daten GigabitEthernet3 Timer Verzögerung 30 Neuladen 60 Track 1 Shutdown Track 2 Shutdown Exit Protocol 
 
 
 
 
   1 
    Timer Hellotime 3 Holdtime 10 
   Beenden 
 
 Beenden 

VCUBE-1(config)#Redundanz

VCUBE-1(config-red)#Anwendungsredundanz

VCUBE-1(config-red-app)#Gruppe 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)#steuern GigabitEthernet3-Protokoll 1

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

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

VCUBE-1(config-red-app-grp)#Herunterfahren von Track 1

VCUBE-1(config-red-app-grp)#Herunterfahren von Track 2

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

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

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

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

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

VCUBE-1(config-red)#beenden

VEINSTELLUNGEN-1(Konfiguration) #

VCUBE-2(config)#Redundanz

VCUBE-2(config-red)#Anwendungsredundanz

VCUBE-2(config-red-app)#Gruppe 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)#steuern GigabitEthernet3-Protokoll 1

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

VCUBE-2(config-red-app-grp)#Timer-Verzögerung 30 Neuladen 60

VCUBE-2(config-red-app-grp)#Herunterfahren von Track 1

VCUBE-2(config-red-app-grp)#Herunterfahren von Track 2

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

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

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

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

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

VCUBE-2(config-red)#beenden

VEINSTELLUNGEN-2(Konfiguration) #

Hier eine Erklärung der in dieser Konfiguration verwendeten Felder:

  • redundancy – Wechselt in den Redundanzmodus

  • application redundancy – Wechselt in den Konfigurationsmodus für die Anwendungsredundanz

  • group – Wechselt in den Konfigurationsmodus für die Anwendungsgruppe für die Redundanz

  • name LocalGateway-HA – Definiert den Namen der RG-Gruppe

  • priority 100 failover threshold 75 – Gibt die anfängliche Priorität und Failover-Schwellenwerte für eine RG an

  • timers delay 30 reload 60 – Konfiguriert die beiden Male für die Verzögerung und das erneute Laden

    • Der Verzögerungstimer gibt die Zeitspanne an, um die die Initialisierung der RG-Gruppe und die Rollenaushandlung nach der Aktivierung der Schnittstelle verzögert wird – Standardwert 30 Sekunden. Der Bereich ist 0–10.000 Sekunden.

    • Reload – Dies ist die Zeitspanne, um die die Initialisierung der RG-Gruppe und die Rollenaushandlung nach einem erneuten Laden verzögert wird – Standardwert 60 Sekunden. Der Bereich ist 0–10.000 Sekunden.

    • Es werden Standardtimer empfohlen. Diese Timer können jedoch angepasst werden, um eine zusätzliche Verzögerung in der Netzwerkkonvergenz auszugleichen, die während des Hochfahrens/Neuladens der Router auftreten kann, um zu gewährleisten, dass die RG-Protokollaushandlung stattfindet, nachdem das Routing im Netzwerk zu einem stabilen Punkt konvergiert ist. Beispiel: Wenn nach einem Failover festgestellt wird, dass es bis zu 20 Sekunden dauert, bis der neue STANDBY das erste RG-HELLO-Paket vom neuen ACTIVE sieht, dann sollten die Timer auf 'timers delay 60 reload 120' eingestellt werden, um diese Verzögerung zu berücksichtigen.

  • GigabitEthernet3-Protokoll 1 steuern – Konfiguriert die Schnittstelle, die zum Austausch von Keepalive- und Hello-Nachrichten zwischen den beiden CUBEs verwendet wird, gibt die Protokollinstanz an, die an eine Steuerungsschnittstelle angehängt wird, und wechselt in den Konfigurationsmodus für das Redundanzanwendungsprotokoll

  • data GigabitEthernet3 – Konfiguriert die Schnittstelle, die für Prüfpunkte des Datenverkehrs verwendet wird

  • track – RG-Gruppenverfolgung von Schnittstellen

  • protocol 1 – Gibt die Protokollinstanz an, die an eine Steuerungsschnittstelle angehängt wird, und wechselt in den Konfigurationsmodus für das Redundanzanwendungsprotokoll

  • timers hellotime 3 holdtime 10 – Konfiguriert die beiden Timer für hellotime und holdtime:

    • Hellotime – Intervall zwischen aufeinanderfolgenden Hello-Nachrichten – Standardwert 3 Sekunden. Der Bereich liegt bei 250 Millisekunden bis 254 Sekunden.

    • Holdtime – Das Intervall zwischen dem Empfang einer Hello-Nachricht und der Vermutung, dass der sendende Router ausgefallen ist. Diese Dauer muss länger sein als die hellotime – Standardwert 10 Sekunden. Der Bereich liegt bei 750 Millisekunden bis 255 Sekunden.

      Wir empfehlen, den Timer für holdtime auf einen mindestens 3-mal so hohen Wert wie den für hellotime zu konfigurieren.

3

Aktivieren Sie Box-to-Box-Redundanz für die CUBE-Anwendung. Konfigurieren Sie die RG aus dem vorherigen Schritt unter Sprachdienst voip. Dies ermöglicht der CUBE-Anwendung, den Redundanzprozess zu steuern.

Sprachdienst 
   VoIP-Redundanz -Gruppe 1 
   Beenden

VCUBE-1(config)#SprachdienstvoIP

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

 % RG 1-Zuordnung mit Voice B2B HA erstellt; Laden Sie den Router neu, damit die neue Konfiguration wirksam wird 

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

VCUBE-2(config)#SprachdienstvoIP

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

 % RG 1-Zuordnung mit Voice B2B HA erstellt; Laden Sie den Router neu, damit die neue Konfiguration wirksam wird 

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

redundancy-group 1 – Das Hinzufügen und Entfernen dieses Befehls erfordert ein erneutes Laden, damit die aktualisierte Konfiguration wirksam wird. Die Plattformen müssen neu geladen werden, nachdem die gesamte Konfiguration angewendet wurde.

4

Konfigurieren Sie die Schnittstellen Gig1 und Gig2 mit ihren virtuellen IP-Adressen (siehe unten), und wenden Sie den Bezeichner der Redundanzschnittstelle an (RII)

VCUBE-1(config)#Schnittstelle GigabitEthernet1

VCUBE-1(config-if)# Redundanz RII 1

VCUBE-1(config-if)# Redundanzgruppe 1 ip 198.18.1.228 exklusiv

VCUBE-1(config-if)# Beenden

VEINSTELLUNGEN-1(Konfiguration) #

VCUBE-1(config)#Schnittstelle GigabitEthernet2

VCUBE-1(config-if)# Redundanz RII 2

VCUBE-1(config-if)# Redundanzgruppe 1 ip 198.18.133.228 exklusiv

VCUBE-1(config-if)# Beenden

VCUBE-2(config)#Schnittstelle GigabitEthernet1

VCUBE-2(config-if)# Redundanz RII 1

VCUBE-2(config-if)# Redundanzgruppe 1 ip 198.18.1.228 exklusiv

VCUBE-2(config-if)# Beenden

VEINSTELLUNGEN-2(Konfiguration) #

VCUBE-2(config)#Schnittstelle GigabitEthernet2

VCUBE-2(config-if)# Redundanz RII 2

VCUBE-2(config-if)# Redundanzgruppe 1 ip 198.18.133.228 exklusiv

VCUBE-v(config-if)# Beenden

Hier eine Erklärung der in dieser Konfiguration verwendeten Felder:

  • redundancy rii – Konfiguriert die Redundanzschnittstellenkennung für die Redundanzgruppe. Erforderlich für die Generierung einer virtuellen MAC-Adresse (VMAC). Der gleiche RII-ID-Wert muss auf der Schnittstelle jedes Routers (ACTIVE/STANDBY) verwendet werden, der die gleiche VIP-Adresse hat.

    Wenn mehr als ein B2B-Paar im selben LAN vorhanden ist, MUSS jedes Paar eindeutige RII-IDs auf ihren jeweiligen Schnittstellen haben (um Kollisionen zu vermeiden). „show redundancy application group all“ (Redundanzanwendungsgruppe alle anzeigen) sollte die korrekten lokalen und Peer-Informationen anzeigen.

  • redundancy group 1 – Verknüpft die Schnittstelle mit der in Schritt 2 oben erstellten Redundanzgruppe. Konfigurieren Sie die RG-Gruppe sowie die dieser physischen Schnittstelle zugewiesene VIP-Adresse.

    Es ist zwingend erforderlich, eine separate Schnittstelle für die Redundanz zu verwenden, d. h. die für den Sprachverkehr verwendete Schnittstelle kann nicht als die in Schritt 2 weiter oben angegebene Steuerungs- und Datenschnittstelle verwendet werden. In diesem Beispiel wird die Gigabit-Schnittstelle 3 für die RG-Steuerung/-Daten verwendet.

5

Speichern Sie die Konfiguration des ersten CUBEs, und laden Sie sie neu.

Als Letztes wird immer die Standby-Plattform neu geladen.

VCUBE-1#wr

 Aufbaukonfiguration... 

 [OK] 

VCUBE-1#neu laden

 Mit erneutem Laden fortfahren? [bestätigen]

Nachdem VEINSTELLUNGEN-1 vollständig hoch gestartet wurde, speichern Sie die Konfiguration von V CUBE-2 und laden Sie sie erneut hoch.

VCUBE-2#wr

 Aufbaukonfiguration... 

 [OK] 

VCUBE-2#neu laden

 Mit erneutem Laden fortfahren? [bestätigen]

6

Vergewissern Sie sich, dass die Box-to-Box-Konfiguration wie erwartet funktioniert. Relevante Ausgaben sind fett hervorgehoben.

VCUBE-2 wurde gemäß den Designüberlegungen zuletzt neu geladen. Als Letztes wird immer die Standby-Plattform neu geladen. 

 VCUBE-1#show redundancy application group all Fehlerstatus Gruppe 1 info:        Laufzeitpriorität: [100] RG Fehler RG State: oben.                        Gesamtzahl Switchovers aufgrund von Fehlern:  0 insgesamt # Anzahl der nach unten/oben festgelegten Änderungen aufgrund von Fehlern: 0 Gruppenausweis: 1 Gruppenname: LokalGateway-ha Administrative State: Kein Abschaltungen des Gesamtbetriebsstatus:  Meine Rolle: Aktive Peer Rolle: Standby Peer Presence: Ja: Yes Peer Progression wurde gestartet: Yes RF Domäne: BToB-One RF State: Active Peer RF State: Standby Hot RG Protokoll RG 1------------------Rolle: Aktive Verhandlungen: Aktivierte Priorität: 100 Protokollzustand: Active STRG Insef (s) State: Aktiver Peer: Lokale Standby Peer: Adresse 10.1.1.2, Priorität 100, Gi3 Protokollzähler:                 Ändern der Rolle in "aktiv": 1 Rollenänderung in Standby: 1 Events deaktivieren: RG Down State 0, RG schließen 0 STRG InWF Events: up 1, down 0, admin_down 0 Ereignisse neu laden: Lokale Anfrage 0, Peer Request 0 RG Medienkontext für RG 1--------------------------ctx State: Active Protocol ID: 1 Medientyp: Standardsteuerungsoberfläche: GigabitEthernet3 Aktueller Hallo Timer: 3000 konfigurierter Hallo Timer: 3000, Hold-Timer: 10000 Peer Hallo Timer: 3000, Peer Hold-Timer: 10000 stats:             PKTS 1509, Bytes 93558, ha SEQ 0, Seq Nummer 1509, Pkt Loss 0 Authentifizierung nicht konfigurierter Authentifizierungsfehler: 0 neu laden: TX 0, RX 0 Rücktritt: TX 0, RX 0 Standy Peer: Präsentieren. Halten-Timer: 10000 Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0 VCUBE-1#
 VCUBE-2#show redundancy application group all Fehlerstatus Gruppe 1 info:        Laufzeitpriorität: [100] RG Fehler RG State: oben.                        Gesamtzahl Switchovers aufgrund von Fehlern:  0 insgesamt # Anzahl der nach unten/oben festgelegten Änderungen aufgrund von Fehlern: 0 Gruppenausweis: 1 Gruppenname: LokalGateway-ha Administrative State: Kein Abschaltungen des Gesamtbetriebsstatus: Meine Rolle: Standby Peer Rolle: Aktive Peer Presence: Ja: Yes Peer Progression wurde gestartet: Yes RF Domäne: BToB-One RF State: Active Peer RF State: Standby Hot RG Protokoll RG 1------------------Rolle: Aktive Verhandlungen: Aktivierte Priorität: 100 Protokollzustand: Active STRG Insef (s) State: Aktiver Peer: Adresse 10.1.1.2, Priorität 100, Gi3 : Lokale Protokollzähler:                 Ändern der Rolle in "aktiv": 1 Rollenänderung in Standby: 1 Events deaktivieren: RG Down State 0, RG schließen 0 STRG InWF Events: up 1, down 0, admin_down 0 Ereignisse neu laden: Lokale Anfrage 0, Peer Request 0 RG Medienkontext für RG 1--------------------------ctx State: Active Protocol ID: 1 Medientyp: Standardsteuerungsoberfläche: GigabitEthernet3 Aktueller Hallo Timer: 3000 konfigurierter Hallo Timer: 3000, Hold-Timer: 10000 Peer Hallo Timer: 3000, Peer Hold-Timer: 10000 stats:             PKTS 1509, Bytes 93558, ha SEQ 0, Seq Nummer 1509, Pkt Loss 0 Authentifizierung nicht konfigurierter Authentifizierungsfehler: 0 neu laden: TX 0, RX 0 Rücktritt: TX 0, RX 0 Standy Peer: Präsentieren. Halten-Timer: 10000 
 Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0 
 
 V CUBE-2 #

Konfigurieren eines lokalen Gateways auf beiden CUBEs

In unserer Beispielkonfiguration verwenden wir die folgenden Trunk-Informationen von Control Hub, um die lokale Gateway-Konfiguration auf beiden Plattformen, VCUBE-1 und VCUBE-2, zu erstellen. Der Benutzername und das Passwort für diese Einrichtung lauten wie folgt:

  • Benutzername: Hussain1076 LGU_

  • Passwort: lOV12MEaZx

1

Stellen Sie sicher, dass mit den unten gezeigten Befehlen ein Konfigurationsschlüssel für das Passwort erstellt wird, bevor es in den Anmeldeinformationen oder gemeinsamen geheimen Schlüsseln verwendet werden kann. Passwörter vom Typ 6 werden mit AES-Verschlüsselung und diesem benutzerdefinierten Konfigurationsschlüssel verschlüsselt. 

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

Hier ist die lokale Gateway Konfiguration, die auf beide Plattformen basierend auf den oben angezeigten Control Hub Parametern, speichern und Nachladen, gilt. SIP-Digest-Anmeldeinformationen von Control Hub sind fett hervorgehoben.

 konfigurieren 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 konfigurieren 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 From 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" rule 13 response ANY sip-header From modify "<sips:(.*)" "<sip:\1" rule 14 response ANY sip-header From modify "<sips:(.*)" "<sip:\1" rule 15 response ANY sipHussain1076_lgu>" Regel 30 Anforderung ANY SIP-HEADER P-Asserted-Identity Änderung "sips:(.*)" "sip:\1" Sprachklasse Codec 99 Codec Präferenz 1 g711ulaw Codec Präferenz 2 g711ulaw Exit Sprachklasse srtp-crypto 200 crypto 1 AES_cm_128_HMAC_SHA1_80 Sprachklasse verlassen stun-usage 200 stun-usage firewall-traversal flowdata verlassen sprachklasse tenant 200 registrar dns:40462196.cisco-bcld.com Schema-SIPS läuft ab 240 Refresh-Ratio 50 TCP TLS-Anmeldeinformationen-Nummer Hussain5091_LGU Benutzername Hussain1076_LGU-Passwort 0 lOV12MEaZx Benutzername für BroadWorks-Authentifizierung im Bereich Hussain5091_LGU Passwort 0 lOV12MEaZx Benutzername für BroadWorks-Authentifizierung Hussain5091_LGU Passwort 0 lOV12MEaZx Bereich 40462196.cisco-bcld.com kein SIP-Server mit Remote-Teilnehmer-ID 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 Ausgehendes dial-peer zu 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 Ausgehendes dial-peer zu Webex Calling-Zielmuster 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 Eingehender WebexCalling(DP200) zu IP PSTN(DP101) dial-peer 101 preference 1 voice class dpg 200 description Eingehender IP PSTN(DP100) zu Webex Calling(DP201) dial-peer 201 preference 1 dial-peer voice 100 voip desription Eingehender dial-peer vom IP-PSTN-Sitzungsprotokoll 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

Um die Ausgabe des Befehls „show“ anzuzeigen, haben wir erst VCUBE-2 und dann VCUBE-1 neu geladen, wodurch VCUBE-1 zum Standby-CUBE und VCUBE-2 zum aktiven CUBE wurde.

2

Zu jedem Zeitpunkt hat jeweils nur eine Plattform eine aktive Registrierung als lokales Gateway beim Zugriffs-SBC von Webex Calling. Schauen Sie sich die Ausgabe der folgenden „show“-Befehle an.

show redundancy application group 1

sip-ua-Registrierungsstatus anzeigen 

 VCUBE-1#show redundancy application group 1 Gruppen-ID:1 Gruppenname:LocalGateway-HA Administrationsstatus: Betriebsstatus „Kein Herunterfahren“: Meine Rolle: Standby Peer Rolle: Aktive Peer Presence: Ja: Yes Peer Progression wurde gestartet: Yes RF Domäne: 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 Gruppen-ID:1 Gruppenname:LocalGateway-HA Administrationsstatus: Betriebsstatus „Kein Herunterfahren“: Meine Rolle: Aktive Peer Rolle: Status Peer Presence: Ja: Yes Peer Progression wurde gestartet: Yes RF Domäne: BToB-One RF State: Active Peer RF State: Standby Hot Vcube-2 #SIP-UA registrieren Statusmieter: 200 --------------------Registerstellenindex  1 --------------------- Line Peer expires(sec) reg survival P-Associ-URI ============================== ========== ======================= ============ Hussain5091_LGU -1 48 ja normal VCUBE-2#

Aus der obigen Ausgabe können Sie sehen, dass VCUBE-2 das aktive LGW ist und die Registrierung beim Zugriffs-SBC von Webex Calling aufrechterhält, während die Ausgabe von „show sip-ua register status“ in VCUBE-1 leer ist.

3

Aktivieren Sie jetzt die folgenden Fehlersuchen auf VCUBE-1.

 VCUBE-1#debug ccsip non-call SIP Out-of-Dialog Tracing ist aktiviert VCUBE-1#debug ccsip info SIP Call Info Tracing ist aktiviert VCUBE-1#debug ccsip message

4

Simulieren Sie die Ausfallsicherung, indem Sie den folgenden Befehl auf dem aktiven LGW, in diesem Fall VCUBE-2, eingeben.

 VCUBE-2#Redundanzanwendung neu laden Gruppe 1 selbst

Die Umschaltung vom ACTIVE- zum STANDBY-LGW erfolgt neben der oben aufgeführten CLI auch in den folgenden Szenarien:

  • Wenn der ACTIVE-Router neu lädt;

  • Wenn der ACTIVE-Router sich aus- und wieder einschaltet;

  • Wenn eine beliebige RG-konfigurierte Schnittstelle des ACTIVE-Routers heruntergefahren wird, für die die Nachverfolgung aktiviert ist.

5

Überprüfen Sie, ob sich VCUBE-1 beim Zugangs-SBC von Webex Calling registriert hat. VCUBE-2 müsste inzwischen neu geladen haben.

 VCUBE-1#show sip-ua register status tenant: 200 --------------------Registerstellenindex  1 --------------------- Line Peer expires(sec) reg survival P-Associ-URI ============================== ========== ========================= ============ Hussain5091_LGU -1 56 ja normal VCUBE-1#

VCUBE-1 ist jetzt das aktive LGW.

6

Schauen Sie sich das entsprechende Debug-Protokoll von VCUBE-1 an, der ein SIP REGISTER über die virtuelle IP-Adresse an Webex Calling sendet und ein 200 OK erhält.

 VCUBE-1#Protokoll anzeigen 9. Januar 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG ID 1 Hallo Zeit abgelaufen. 9. Januar, 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG-id 1 Rollenänderung von Standby zu Aktiv 9. Januar 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: UMSCHALTEN vom Status „STANDBY_HOT“ in den Status „AKTIV“. 9. Januar 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Benachrichtigungs-Event für aktive Rolle empfangen 9. Jan. 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Gesendet: SIP REGISTRIEREN: 40462196.Cisco-bcld.com:5061/2.0 über: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374 Von: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 Bis: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Datum: Do, 09. Jan 2020 18:37:24 GMT Einwahlausweis: FFFFFFFFEA0684EF 324511FFFFFFFF800281CD FFFFFFFFB5F93B97-Benutzer: Cisco-SiteGateway/16.12.02 Max-vorwärts: 70 Zeitstempel: 1578595044 CSeq: 2 Kontakt REGISTRIEREN: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Läuft ab: 240 unterstützt: Weinhalt-Länge: 0 

9. Januar 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg: Erhalten: SIP/2.0 401 unberechtigt über: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742 Von: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 Bis: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 Datum: Do, 09. Jan 2020 18:37:24 GMT Einwahlausweis: FFFFFFFFEA0684EF 324511FFFFFFFF800281CD FFFFFFFFB5F93B97 Zeitstempel: 1578595044 CSeq: 2 www registrieren-authentifizieren; Digest Realm = "Broadworks", QoP = "auth", Nonce = "BroadWorksXk572qd01Ti58zliBW", Algorithmus = MD5 Inhalt-Länge: 0 

9. Januar 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Gesendet: Anmelden: 40462196. CIP/bcld.com:5061 über: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC Von: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 Bis: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Datum: Do, 09. Jan 2020 18:37:25 GMT Einwahlausweis: FFFFFFFFEA0684EF 324511FFFFFFFF800281CD FFFFFFFFB5F93B97: Cisco-sipGateway/IOS-16.12.02 Max-vorwärts: 70 Zeitstempel: 1578595045 CSeq: 3 Kontakt REGISTRIEREN: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Läuft ab: 240 unterstützt: Wedeautorisierung: 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 

9. Januar 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:  Erhalten: SIP/2.0 200 OK Über: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742 Von: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 An: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 Anruf-ID: FFFFFFFFEA0684EF 324511FFFFFFFF800281CD FFFFFFFFB5F93B97 Zeitstempel: 1578595045 CSeq: 3 KONTAKT REGISTRIEREN: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 Allow-Events: Anrufinformationen, Linienbeschlagung, Dialogfeld, Nachrichtenübersicht, als-Funktion-Event, X-Broadworks-HotelING, X-Broadworks-Call-Center-Status, Konferenzinhalt-Länge: 0