Grundlagen

Voraussetzungen

Bevor Sie CUBE HA als lokales Gateway für Webex Calling bereitstellen, müssen Sie die folgenden Konzepte ausführlich verstehen:

Die Konfigurationsrichtlinien in diesem Artikel gehen von einer dedizierten lokalen Gatewayplattform ohne vorhandene Sprachkonfiguration aus. Wenn eine bestehende Cube-Unternehmensbereitstellung geändert wird, um auch die lokale Gateway-Funktion für Cisco Webex Calling zu nutzen, sollten Sie sich genau mit der konfiguration, die angewendet wird, um bestehende Anrufabläufe und Funktionen zu gewährleisten, nicht unterbrochen werden und sicherstellen, dass Sie die Design-Anforderungen von CUBE HA erfüllen.

Hardware- und Softwarekomponenten

CUBE HA als lokales Gateway erfordert IOS-XE Version 16.12.2 oder höher und wird auf folgenden Plattformen unterstützt:

  • ISR4000-Serie—4321, 4331, 4351, 4431, 4451, 4461 (IOS-XE 17.2.1r)

  • Serie CSR1000 – v CUBE (1-, 2- und 4 vCPU-Konfigurationen)

Die Befehle und Protokolle zum Anzeigen dieses Artikels basieren auf einer Software-Mindestversion von Cisco IOS-XE 16.12.2, die auf einer v CUBE (CSR1000v) implementiert wurde.

Referenzmaterial

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

Webex Calling Lösungsübersicht

Cisco Webex Calling Ist ein Zusammenarbeitsangebot, das Multi-Tenant-Cloud-basierte Alternative zu lokalen PBX-Telefon-Services mit zwei PSTN-Optionen für Kunden bietet:

  • Cloud Connected PSTN Provider

  • Lokales Gateway

Die Bereitstellung des lokalen Gateways (unten dargestellt) ist der Schwerpunkt dieses Artikels. Lokales Gateway ist die Bring Your Own PSTN-Option für Cisco Webex Calling, indem Verbindungen mit einem im Besitz eines Kunden befindlichen PSTN werden. Außerdem bietet es Verbindungen mit einer lokalen IP PBX-Bereitstellung, wie Cisco Unified CM. Die gesamte Kommunikation von und zu der 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.

Ebene-2-Box-to-Box-Redundanz

Die BOX-to-Box-Redundanz von CUBE HA Layer 2 nutzt das Infrastrukturprotokoll der Redundanzgruppe (RG), um ein Aktiv-/Standby-Router-Paar zu bilden. Dieses Paar teilt dieselbe virtuelle IP-Adresse (VIP) über die jeweiligen Schnittstellen und austauscht statusmeldungen zu jeder Zeit. Die CUBE-Sitzungsinformationen werden direkt über die routerübergreifenden Router geroutet, sodass der Standby-Router alle Cube-Anrufverarbeitungsaufgaben sofort übernehmen kann, wenn der aktive Router außer Betrieb ist. Dies führt zur Zustandsbewahrung von Signalisierung und Medien.

Die Prüfung ist auf verbundene Anrufe mit Medienpaketen beschränkt. Anrufe während der Übertragung werden nicht überprüft (z. B. ein Versuch oder ein Klingelstatus).

In diesem Artikel bezieht sich CUBE HA auf die Redundanz der CUBE High Availability (HA) Layer 2 Box-to-Box (B2B)-Redundanz für Anruf beibehalten

Ab IOS-XE 16.12.2 kann CUBE HA als lokales Gateway für Cisco Webex Calling-Bereitstellungen bereitgestellt werden. Zudem werden designorientierte Aspekte und Konfigurationen in diesem Artikel behandelt. In dieser Abbildung wird eine typische CUBE HA-Einrichtung als lokales Gateway für eine Cisco Webex Calling dargestellt.

Infra-Komponente der Redundanzgruppe

Die Komponente Redundanzgruppe (RG) Infra stellt die Box-to-Box-Kommunikationsinfrastrukturunterstützung zwischen den beiden CUBEs bereit und verhandeln über den endgültigen stabilen Redundanzzustand. Diese Komponente bietet außerdem:

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

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

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

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 im CUBE HA-Paar müssen sich im selben LAN-Subnetz befinden. Konfiguration der VIP und Bindung der VIP-Schnittstelle an eine bestimmte Sprachanwendung (SIP) sind obligatorisch für den Sprach-B2B-HA-Support. Externe Geräte wie Unified CM, Webex Calling Access SBC, Service Provider oder Proxy, verwenden VIP als Ziel-IP-Adresse für Anrufe, die die CUBE HA-Router durchlaufen. Aus Sicht Webex Calling der CUBE HA-Paare sich als ein einziges lokales Gateway.

Die Anrufsignalisierung und RTP-Sitzungsinformationen zu hergestellten Anrufen werden vom aktiven Router zum Standby-Router über einen Checkpoint geroutet. Wenn der aktive Router abläuft, übernimmt der Standby-Router die Kontrolle und führt weiterhin den RTP-Stream, der zuvor vom ersten Router geroutet wurde.

Anrufe, die sich zum Zeitpunkt des Failovers in einem Übergangszustand verhalten, werden nach dem Umschalten nicht beibehalten. Beispiel: Anrufe, die noch nicht vollständig hergestellt wurden oder gerade mit einer Funktion zum Übertragen oder Halten geändert werden. Bei hergestellten Anrufen kann die Verbindung nach dem Umschalten getrennt werden.

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

  • CUBE HA darf weder TDM noch analoge Schnittstellen gemeinsam befinden

  • Gig1 und Gig2 werden als Datenverkehrsschnittstellen (SIP/RTP) bezeichnet, und Gig3 ist Redundanc Group (RG) Control/Data Interface

  • Nicht mehr als 2 CUBE HA-Paare können in derselben Ebene 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 Ebenen-2-Domänen gehören (Vlan, separater Switch)

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

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

  • Immer wenn eine Plattform in einer CUBE-HA-Beziehung neu geladen wird, wird sie immer als Standby-System hoch gestartet.

  • Niedrigere Adresse für alle Schnittstellen (Gig1, Gig2, Gig3) sollte auf derselben Plattform sein

  • Redundanz Interface Identifier, rii sollte für eine Paar-/Schnittstellenkombination auf demselben Layer 2 eindeutig sein

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

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

  • Für mehrere Datenverkehrsschnittstellen (SIP/RTP) (Gig1, Gig2) muss die Überwachung der Schnittstelle konfiguriert werden.

  • CUBE-HA wird nicht über eine Crossover-Kabelverbindung für die RG-Control/Data link (Gig3) unterstützt.

  • Beide Plattformen müssen identisch sein und über einen physischen Switch verbunden sein, damit CUBE HA funktioniert, d. h. GE0/0/0 von CUBE-1 und CUBE-2 müssen mit demselben Switch beendet werden.

  • Wan kann auf CUBEs direkt oder Data HA auf beiden Seiten nicht beendet werden

  • Sowohl Aktiv als auch Standby müssen sich im selben Rechenzentrum

  • Für Redundanz ist eine separate L3-Schnittstelle erforderlich (RG Control/Data, Gig3). d. h. die Für Datenverkehr verwendete Schnittstelle kann nicht für HA-Keepalives und Checkpoints verwendet werden.

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

Konfigurieren von Redundanz auf beiden CUBEs

Sie müssen die Layer-2-Box-to-Box-Redundanz auf beiden CUBEs konfigurieren, die in einem HA-Paar zum Aufbringen virtueller IPs verwendet werden sollen.

1

Konfigurieren Sie die Oberflächenverfolgung auf globaler Ebene, um den Status der Oberfläche zu überwachen.

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

V CUBE-1#conf t
V CUBE-1(config)#Track 1 Interface GigabitEthernet1 Line-Protocol
V CUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol
VEINSTELLUNGEN-1(config-track)#Beenden
 
V CUBE-2#conf t
V HASHTAG-2(config)#Track 1 Interface GigabitEthernet1 Line-Protocol
V CUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol
VEINSTELLUNGEN-2(config-track)#Beenden

Track CLI wird in RG verwendet, um den Status der Sprachdatenverkehr-Oberfläche zu verfolgen, sodass die aktive Route ihre aktive Rolle übernehmen kann, nachdem die Datenverkehrsschnittstelle nicht aktiv ist.
2

Konfigurieren Sie ein RG zur Verwendung mit VoIP HA im Untermodus der Anwendungsredundanz.

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

V REDUNDANT-1(config)#Redundanz
V REDUNDANT-1(config-red)#Redundanz der Anwendung
VEINSTELLUNGEN-1(config-red-app)#Gruppe 1
VEINSTELLUNGEN-1(config-red-app-grp)#Name LocalGateway-HA
VKW-1(config-red-app-grp)#Priorität 100 Failover-Schwellenwert 75
VEINSTELLUNGEN-1(config-red-app-grp)#GigabitEthernet3-Protokoll 1 steuern
VEINSTELLUNGEN-1(config-red-app-grp)#Daten GigabitEthernet3
VKW-1(config-red-app-grp)#Timer Verzögerung 30 Neuladen 60
VEINSTELLUNGEN-1(config-red-app-grp)#Track 1 Shutdown
VEINSTELLUNGEN-1(config-red-app-grp)#Track 2 Shutdown
VEINSTELLUNGEN-1(config-red-app-grp)#Beenden
VEINSTELLUNGEN-1(config-red-app)#Protokoll 1
VEINSTELLUNGEN-1(config-red-app-prtcl)#Timer Hellotime 3 Holdtime 10
VEINSTELLUNGEN-1(config-red-app-prtcl)#Beenden
VEINSTELLUNGEN-1(config-red-app)#Beenden
VEINSTELLUNGEN-1(config-red)#Beenden
VEINSTELLUNGEN-1(Konfiguration) #
 
V REDUNDANT-2(config)#Redundanz
V REDUNDANT-2(config-red)#Redundanz der Anwendung
VEINSTELLUNGEN-2(config-red-app)#Gruppe 1
VEINSTELLUNGEN-2(config-red-app-grp)#Name LocalGateway-HA
VKW-2(config-red-app-grp)#Priorität 100 Failover-Schwellenwert 75
VEINSTELLUNGEN-2(config-red-app-grp)#GigabitEthernet3-Protokoll 1 steuern
VEINSTELLUNGEN-1(config-red-app-grp)#Daten GigabitEthernet3
VEINSTELLUNGEN-2(config-red-app-grp)#Timer Verzögerung 30 Neuladen 60
VKW-2(config-red-app-grp)#Track 1 Shutdown
VEINSTELLUNGEN-2(config-red-app-grp)#Track 2 Shutdown
VEINSTELLUNGEN-2(config-red-app-grp)#Beenden
VEINSTELLUNGEN-2(config-red-app)#Protokoll 1
VEINSTELLUNGEN-2(config-red-app-prtcl)#Timer Hellotime 3 Holdtime 10
VEINSTELLUNGEN-2(config-red-app-prtcl)#Beenden
VEINSTELLUNGEN-2(config-red-app)#Beenden
VEINSTELLUNGEN-2(config-red)#Beenden
VEINSTELLUNGEN-2(Konfiguration) #

Im Folgenden finden Sie eine Erklärung zu den Feldern, die in dieser Konfiguration verwendet werden:

  • Redundanz– Aktiviert den Redundanzmodus

  • Redundanz derAnwendung – Aktiviert den Konfigurationsmodus für die Anwendungsredundanz

  • Gruppe– Aktiviert den Konfigurationsmodus der Redundanzanwendungsgruppe

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

  • Priorität 100 Failover-Schwellenwert 75 —Gibt die anfängliche Priorität und dieFailover-Schwellenwerte für eine RG an

  • Timer-Verzögerung 30 wird neu geladen 60 – Konfiguriert die zwei Mal fürVerzögerung und Neuladen

    • Verzögerungs-Timer, der die Zeit für die Verzögerung der Initialisierung der RG-Gruppe und die Rollenverhandlung nach dem Start der Schnittstelle beträgt – Standard 30 Sekunden. Bereich ist 0 bis 10000 Sekunden

    • Erneut laden: Dies ist die Zeit, die die Initialisierung der RG-Gruppe und die Rollenverhandlung nach einem erneuten Laden verzögert – standardmäßig 60 Sekunden. Bereich ist 0 bis 10000 Sekunden

    • Es werden Standard-Timer empfohlen, obwohl diese Timer angepasst werden können, um zusätzliche Verzögerungen bei der Netzwerkkonvergenz zu unterstützen, die während bootup/reload der Router auftreten können, um sicherzustellen, dass die Verhandlung des RG-Protokolls stattfindet, nachdem die Weiterleitung im Netzwerk zu einem stabilen Punkt konvergiert ist. Wenn beispielsweise nach einem Failover zu erkennen ist, dass der neue STANDBY-Modus bis zu 20 Sekunden dauert, um das erste RG HELLO-Paket aus dem neuen ACTIVE anzuzeigen, sollten die Timer auf "Timer Delay 60 reload 120" eingestellt werden, um diese Verzögerung zu berücksichtigt.

  • Control GigabitEthernet3 Protokoll 1 – Konfiguriert die Schnittstelle für den Austausch von Keepalive- und Hello-Nachrichten zwischen den beiden CUBEs und legt die Protokollinstanz fest, die an eine Kontrollschnittstelle angehängt wird und in den Konfigurationsmodus des Redundanz-Anwendungsprotokolls eintritt.

  • Data GigabitEthernet3 – Konfiguriert die Schnittstelle, die fürdie Kontrolle des Datenverkehrs verwendet wird.

  • Track– RG-Gruppenverfolgung von Schnittstellen

  • Protokoll 1 – Gibt die Protokollinstanz an, die an eine Kontrollschnittstelle angehängt wird und in den Konfigurationsmodus desRedundanz-Anwendungsprotokolls eintritt.

  • Timer Hellotime 3 Holdtime 10: Konfiguriert die beiden Timer für Hellotime und Holdtime:

    • Hellotime – Intervall zwischen verschiedenen Hallo-Nachrichten – Standard 3 Sekunden. Bereich ist 250 ms bis 254 Sekunden

    • Holdtime—Das Intervall zwischen dem Erhalt der Hallo-Nachricht und dem Intervall, dass der Router fehlgeschlagen ist. Diese Dauer muss länger als die Uhrzeit sein – standardmäßig 10 Sekunden. Bereich ist 750 ms bis 255 Sekunden

      Wir empfehlen, den Holdtime-Timer mindestens dreimal so zu konfigurieren, wie der Hellotime-Timer ist.
3

Aktivieren Sie die 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
VEINSTELLUNGEN-1(config)#Sprachdienst voip
V REDUNDANT-1(config-voi-serv)#Redundanz-Gruppe 1

  % RG 1-Zuordnung mit Voice B2B HA erstellt; Router erneut laden, damit die neue Konfiguration wirksam wird

VEINSTELLUNGEN-1(config-voi-serv)# beenden
 
VEINSTELLUNGEN-2(Konfiguration)#Sprachdienst voip
V REDUNDANT-2(config-voi-serv)#Redundanz-Gruppe 1

  % RG 1-Zuordnung mit Voice B2B HA erstellt; Router erneut laden, damit die neue Konfiguration wirksam wird

VEINSTELLUNGEN-2(config-voi-serv)# beenden

Redundanz-Gruppe 1 – Wenn Sie diesen Befehl hinzufügen und entfernen, muss die aktualisierte Konfigurationerneut geladen werden. Die Plattformen werden neu geladen, nachdem alle Konfigurationen angewendet wurden.
4

Konfigurieren Sie die Gig1- und Gig2-Schnittstellen mit ihren jeweiligen virtuellen IPs wie unten abgebildet und wenden Sie den Redundanz-Interface-Identifikator (rii) an.

VEINSTELLUNGEN-1(config)#Schnittstelle GigabitEthernet1
V REDUNDANT-1(config-if)# Redundanz rii 1
V REDUNDANT-1(config-if)# Redundanz gruppe 1 ip 198.18.1.228 exklusiv
VEINSTELLUNGEN-1(config-if)# Beenden
VEINSTELLUNGEN-1(Konfiguration) #
VEINSTELLUNGEN-1(config)#Schnittstelle GigabitEthernet2
V REDUNDANT-1(config-if)# Redundanz rii 2
V REDUNDANT-1(config-if)# Redundanz Gruppe 1 IP 198.18.133.228 exklusiv
VEINSTELLUNGEN-1(config-if)# Beenden
 
VEINSTELLUNGEN-2(config)#Schnittstelle GigabitEthernet1
V REDUNDANT-2(config-if)# Redundanz rii 1
V REDUNDANT-2(config-if)# Redundanz Gruppe 1 IP 198.18.1.228 exklusiv
VEINSTELLUNGEN-2(config-if)# Beenden
VEINSTELLUNGEN-2(Konfiguration) #
VEINSTELLUNGEN-2(config)#Schnittstelle GigabitEthernet2
V REDUNDANT-2(config-if)# Redundanz rii 2
V REDUNDANT-2(config-if)# Redundanz Gruppe 1 ip 198.18.133.228 exklusiv
VEINSTELLUNGEN-v(config-if)# Beenden

Im Folgenden finden Sie eine Erklärung zu den Feldern, die in dieser Konfiguration verwendet werden:

  • Redundanz-Rii –Konfiguriert den Identifikator der Redundanzschnittstellefür die Redundanzgruppe. Erforderlich zum Generieren einer virtuellen MAC (VMAC)-Adresse. Derselbe Rii-ID-Wert muss auf der Schnittstelle jedes Routers (ACTIVE/STANDBY) mit derselben VIP verwendet werden.


     

    Wenn sich mehr als ein B2B-Paar im gleichen LAN befindet, MUSS jedes Paar über eindeutige Rii-IDs auf den jeweiligen Schnittstellen verfügen (um Kollisionen zu vermeiden). Für die Redundanz-Anwendungsgruppe alle anzeigen müssen die korrekten lokalen und Peer-Informationen angegeben werden.

  • Redundanz Gruppe 1 –Verknüpft die Schnittstelle mit derRedundanzgruppe, die oben in Schritt 2 erstellt wurde. Konfigurieren Sie die RG-Gruppe sowie die VIP, die dieser physischen Schnittstelle zugewiesen ist.


     

    Für Redundanz ist eine separate Schnittstelle erforderlich, d.s., die für den Sprachverkehr verwendete Schnittstelle kann nicht als Steuerungs- und Datenschnittstelle verwendet werden, wie in Schritt 2 oben angegeben. In diesem Beispiel wird Gigabit-Schnittstelle 3 für die RG-Steuerung/-Daten verwendet
5

Speichern Sie die Konfiguration des ersten CUBE und laden Sie ihn erneut.

Die Plattform, die zuletzt neu geladen werden soll, ist immer der Standbymodus.

V EINE 1#WR

  Aufbaukonfiguration...


  [OK]

V CUBE-1#erneut laden

  Mit dem erneuten 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.

V EINE 2#wr

  Aufbaukonfiguration...


  [OK]

V CUBE-2#erneut laden

  Mit dem erneuten Laden fortfahren? [bestätigen]
6

Stellen Sie sicher, dass die Box-to-Box-Konfiguration erwartungsgemäß funktioniert. Die entsprechende Ausgabe wird in Fettdruckmarkiert.

V CUBE-2 wurde zuletzt und je nach Design neu geladen. Die Plattform, die Sie erneut laden möchten, ist immer Standby.


V REDUNDANT-1#zeigen Redundanz Anwendungsgruppe alle Fehler Zustände Gruppen 1 Info:
       Laufzeitpriorität: [100] 
               RG Fehler RG-Status: oben.
                       Gesamtzahl Umschalten aufgrund von Fehlern:           0 
                       Gesamtzahl der Änderungen des Down-/Up-Zustands aufgrund von Fehlern: 0 Gruppen-ID:1 
 Gruppenname:LocalGateway-HA    Administrativer Status: Kein Shutdown 
 Aggregierter Betriebszustand: Meine Rolle übernehmen: ACTIVE 
 Peer-Rolle:  Standby-Peer-Präsenz: Ja 
 Peer-Komma: Ja 
 Peer-Fortschritt gestartet: Ja 
 
 RF-Domäne: btob-one 
         RF-Status: ACTIVE 
         Peer-RF-Status: STANDBY HOT 
 
 RG Protokoll RG 1 
 ------------------ 
 Rolle: Aktive 
        Verhandlung: Aktivierte 
        Priorität: 100-Protokollstatus: Aktiver 
        Ctrl Intf(s)-Status: Up 
        Active Peer (Aktiver Peer): Lokaler         Standby-Peer: Adresse 10.1.1.2, Priorität 100, Intf Gi3         Protokollzähler:
                Ändern der Rolle in "aktiv": 1 
                Rollenwechsel in Standbymodus: 1 
                Ereignisse deaktivieren: rg down state 0, rg shut 0 
                ctrl intf events: up 1, down 0, admin_down 0 
                Ereignisse erneut laden: lokale Anfrage 0, Peer-Anfrage 0 
 
 RG Media Context für RG 1 
 -------------------------- 
 Ctx-Status: Aktive 
        Protokoll-ID: 1 
        Medientyp: Standardsteuerungsschnittstelle: GigabitEthernet3         Aktueller Hello-Timer: 3000 
        Konfigurierter Hello-Timer: 3000, Hold-Timer: 10000 
        Peer Hello Timer: 3000, Peer Hold-Timer: 10.0000 
        Statistiken:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0 
 Authentifizierung nicht konfiguriert Authentifizierungsfehler: 0 
            Peer erneut laden: TX 0, RX 0 
            Zurücktreten: 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-1 #

V REDUNDANT-2#zeigen Redundanz Anwendungsgruppe alle Fehler Zustände Gruppen 1 Info:
       Laufzeitpriorität: [100] 
               RG Fehler RG-Status: oben.
                       Gesamtzahl Umschalten aufgrund von Fehlern:           0 
                       Gesamtzahl der Änderungen des Down-/Up-Zustands aufgrund von Fehlern: 0 Gruppen-ID:1 
 Gruppenname:LocalGateway-HA    Administrativer Status: Kein Shutdown 
 Aggregierter Betriebszustand: Meine Rolle übernehmen: Standby-Peer-Rolle: ACTIVE Peer-Präsenz: Ja 
 Peer-Komma: Ja 
 Peer-Fortschritt gestartet: Ja 
 
 RF-Domäne: btob-one 
         RF-Status: ACTIVE 
         Peer-RF-Status: STANDBY HOT 
 
 RG Protokoll RG 1 
 ------------------ 
 Rolle: Aktive 
        Verhandlung: Aktivierte 
        Priorität: 100-Protokollstatus: Aktiver 
        Ctrl Intf(s)-Status: Up         Active Peer (Aktiver Peer): Adresse 10.1.1.2, Priorität 100, intf Gi3         Standby Peer: Lokale 
        Protokollzähler:
                Ändern der Rolle in "aktiv": 1 
                Rollenwechsel in Standbymodus: 1 
                Ereignisse deaktivieren: rg down state 0, rg shut 0 
                ctrl intf events: up 1, down 0, admin_down 0 
                Ereignisse erneut laden: lokale Anfrage 0, Peer-Anfrage 0 
 
 RG Media Context für RG 1 
 -------------------------- 
 Ctx-Status: Aktive 
        Protokoll-ID: 1 
        Medientyp: Standardsteuerungsschnittstelle: GigabitEthernet3         Aktueller Hello-Timer: 3000 
        Konfigurierter Hello-Timer: 3000, Hold-Timer: 10000 
        Peer Hello Timer: 3000, Peer Hold-Timer: 10.0000 
        Statistiken:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0 
 Authentifizierung nicht konfiguriert Authentifizierungsfehler: 0 
            Peer erneut laden: TX 0, RX 0 
            Zurücktreten: 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 Informationen von Control Hub, um die lokale Gateway-Konfiguration auf beiden Plattformen, V CUBE-1 und V2, zuerstellen. Der Benutzername und das Passwort für diese Einrichtung sind wie folgt:

  • Benutzer: Hussain1076_LGU

  • Kennwort: lOV12MEaZx

1

Stellen Sie sicher, dass ein Konfigurationsschlüssel für das Passwort mit den unten aufgeführten Befehlen erstellt wird, bevor er in den Anmeldeinformationen oder geteilten Informationen verwendet werden kann. Typ 6-Passwörter werden mithilfe einer AES-Verschlüsselung und diesem benutzerdefinierten Konfigurationsschlüssel verschlüsselt.


LocalGateway#conf t 
 LocalGateway(config)#Key config-key password-encrypt Password123 LocalGateway(config)#Passwortverschlüsselung aes

Dies ist die Konfiguration des lokalen Gateways, die basierend auf den oben angezeigten Control Hub-Parametern für beide Plattformen gilt, speichern und erneut laden. SIP Digest-Anmeldedaten aus Control Hub werden fetthervorgehoben.


Konfigurieren Sie terminal 
 kryptonische 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 end http://www.cisco.com/security/pki/trs/ios_core.p7b configure 
 
 
 terminal 
 voice service voip 
 ip address trusted list 
 ipv4 x.x.x.x y.y.yy.y.y beenden 
 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 g711 eine 
 
 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-profile 200 
 rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)" 
 "sip:\1" rule 10 request ANY sip-header To modify " rule<sips:(.*)" "<sip:\1" rule="" 11="" request="" ANY="" sip-header="" From="" modify=""></sip:\1"><sips:(.*)" "<sip:\1" rule="" 12="" request="" ANY="" sip-header="" Contact="" modify=""></sip:\1"><sips:(.*)><sip:\1;transport=tls>13 response ANY sip-header To modify<sips:(.*)" "<sip:\1" rule="" 14="" response="" ANY="" sip-header="" From="" modify=""></sip:\1"><sips:(.*)" "<sip:\1" rule="" 15="" response="" ANY="" sip-header="" Contact="" modify=""></sip:\1"><sips:(.*)"
"<sip:\1" rule="" 20="" request="" ANY="" sip-header="" From="" modify="">"
";otg=<sajan index="1" />hussain1076_lgu<sajan index="2" />>"
  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 <sajan index="3" />" " " 
 ";otg=hussain1076_lgu > 30 anfordern ALLESIP-Header P-Asserted-Identity modifizieren 
 "sips:(.*)" "sip:\1" Voice 
 
 
 Class Codec 99 Codec-Präferenz 
 1 g7111 codec 
 preference 2 g7111 voice 
 class 
 
 srtp-crypto 200 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 dns:40462196.cisco-bcld.com-Schema sips läuft 240 Aktualisierungsverhältnis 
 50 TCP TLS-Anmeldedatennummer Hussain5091_LGU Benutzername Hussain1076_LGU Passwort  0 lOV12MEaZx-Bereich Broadworks Authentifizierung Benutzername Hussain5091_LGU Passwort  0 lOV12MEaZx Realm BroadWorks Authentifizierungs-Benutzername Hussain5091_LGU Passwort  0 lOV12MEaZx-Bereich 40462196.cisco-bcld.com keine     Remote-Party-ID 
 sip-server dns:40462196.cisco-bcld.com   connection-reuse srtp-crypto 200 sitzung transport 
 tcp tls url 
 sips 
 error-passthru 
 asserted-id pai 
 bind control source-interface GigabitEthernet1 
 bind Media Source-Interface GigabitEthernet1 
 no pass-thru Inhalt custom-sdp 
 sip-profile 200 
 outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com   privacy-policy passthru voice class tenant 100 Sitzungstransport 
 
 
 
 UDP URL 
 
 error-passthru bind control 
 source-interface GigabitEthernet2 
 bind media source-interface GigabitEthernet2 
 no pass-thru content custom-sdp 
 
 voice class tenant 300 bind Quellschnittstelle 
 GigabitEthernet2 verbinden 
 Medienquelle-Schnittstelle GigabitEthernet2 keine 
 Pass-Thru-Inhalte custom-sdp 
 
 
 voice class uri uri 100 sip 
 host ipv4:198.18.133.3 Sprachklasse 
 
 uri 200 sip 
 pattern dtg=token gigabitn1076.lgu    dial-peer voice 101 voip 
 beschreibung Outgoing Dial-Peer to IP PSTN 
 Destination-pattern BAD. BAD Sitzungsprotokoll sipv2 Sitzungsziel 
 
 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 Beschreibung Ausgehender 
 Dial-Peer zu Webex Calling 
 Zielmuster BAD. BAD Sitzungsprotokoll sipv2 Sitzungsziel SIP-Server Sprachklasse 
 
 Codec 
 99 
 Sprachklasse Stun-Auslastung 200 kein Sprachklasse SIP Localhost Sprachklasse sip Tenant 
 
 200 
 dtmf-relay rtp-nte 
 srtp no 
 vad Voice Class 
 
 
 dpg 100 
 Beschreibung Eingehendes WebexCalling(DP200) zu IP PSTN(DP101) 
 Dial-Peer 101 Preference 1 
 
 Voice Class dpg 200 Beschreibung Eingehende 
 IP-PSTN(DP100) nach Webex Calling(DP201) 
 Dial-Peer 201 Preference 1 
 
 
 
 
 
 Dial-Peer Voice 100 voIpipation 
 Eingehender Dial-Peer von IP-PSTN-Sitzungsprotokoll 
 sipv2 Ziel 
 dpg 200 
 eingehender URI über 100 
 Sprachklasse-Codec 99 
 Sprachklasse sip tenant 300 
 dtmf-relay rtp-nte 
 no vad 
 
 dial-peer voice 200 voip Beschreibung Eingehender 
 Dial-Peer aus dem 
 Webex Calling-Sitzungsprotokoll sipv2 Ziel 
 dpg 100 eingehende 
 URI-Anfrage 200 
 Sprachklasse-Codec 99 Sprachklasse-Stun-Auslastung 
 200 
 V

Um die Befehlsausgabe anzeigen zu können, haben wir V CUBE-2 gefolgt von V CUBE-1geladen. V CUBE-1 wird zum Standby CUBE und V CUBE-2 zum aktiven CUBE
2

Zu einem bestimmten Zeitpunkt erhält nur eine Plattform eine aktive Registrierung als lokales Gateway mit Webex Calling SBC-Zugriff. Werfen Sie einen Blick auf die Ausgabe der folgenden Show-Befehle.

Redundanz-Anwendungsgruppe 1 anzeigen

sip-ua-register status anzeigen


V REDUNDANT-1#anzeigen Redundanz Anwendungsgruppe 1 Gruppe ID:1 
 Gruppenname:LocalGateway-HA 
 
 Administrativer Status: Kein Shutdown 
 Aggregierter Betriebszustand: Meine Rolle aufschlagen:  Standby-Peer-Rolle: ACTIVE 
 Peer-Präsenz: Ja 
 Peer-Komma: Ja 
 Peer-Fortschritt gestartet: Ja 
 
 RF-Domäne: btob-one 
         RF-Status: STANDBY-HOT-Peer-RF-Status: ACTIVE 
 
 V CUBE-1#show sip-ua register status V CUBE-1 #

V REDUNDANT-2#zeigen Redundanz Anwendungsgruppe 1 Gruppe ID:1 
 Gruppenname:LocalGateway-HA 
 
 Administrative Status: Kein Shutdown 
 Aggregierter Betriebszustand: Meine Rolle aufschlagen: ACTIVE Peer-Rolle: STATUS 
 Peer-Anwesenheit: Ja 
 Peer-Komma: Ja 
 Peer-Fortschritt gestartet: Ja 
 
 RF-Domäne: btob-one 
         RF-Status: ACTIVE 
         Peer-RF-Status: STANDBY HOT 
 
 V STANDBY-2#zeigen sip-ua Registerstatus  Tenant: 200 
 --------------------Registrar-Index 1 --------------------- Line Peer läuft 
 ab (Sek.) reg ab P-Associ-URI 
 "****" "<9> ==*<9> * ** ==** 
 Hussain5091_LGU -1 48 ja normal V 
 CUBE-2 #

Aus der oben aufgeführten Ausgabe wird deutlich, dass VCHECK-2 das aktive LGW ist, das die Registrierung mit Webex Calling Zugriff auf SBC beiträgt, während die Ausgabe des "show sip-ua register status" leer in VSTELLUNG-1 ist.
3

Aktivieren Sie nun folgende Debugs auf V CUBE-1


VEINSTELLUNGEN-1# Debugccsip non-call SIP Out-of-Dialog-Tracing ist 
 aktiviert V CUBE-1# debug ccsip info SIP Call Info Tracing istaktiviert V CUBE-1#debug ccsip message
4

Simulieren Sie ein Failover, indem Sie in diesem Fall den folgenden Befehl auf dem aktiven LGW, V CUBE-2, ausstellen.


V REDUNDANT-2#Redundanzanwendung laden Gruppe 1 sich selbst neu

Der Wechsel vom ACTIVE zum STANDBY LGW erfolgt auch im folgenden Szenario neben der oben aufgeführten CLI.

  • Wenn der ACTIVE-Router neu geladen wird

  • Wenn der AKTIVE Router die Energiezyklen

  • Wenn eine RG-konfigurierte Schnittstelle des ACTIVE-Routers heruntergefahren wird, für die die Verfolgung aktiviert ist
5

Prüfen Sie, ob VCHECK-1 sich für den SBC Webex Calling registriert hat. V CUBE-2 hätte jetzt erneut geladen.


V CUBE-1#zeigen sip-ua register status 
 
 Tenant an: 200 
 --------------------Registrar-Index 1 --------------------- Line Peer läuft 
 ab (Sek.) reg ab P-Associ-URI 
 "****" "<9> ==*<9> * ** ==*" Hussain5091_LGU -1 56 ja normal V CUBE-1 #

V CUBE-1 ist jetzt das aktive LGW.
6

Sehen Sie sich das entsprechende Debugprotokoll auf V CUBE-1 an, das ein SIP REGISTER über die virtuelle IP sendet und ein 200 OK empfängt, Webex Calling.


V MACHEN SIE sich 1#show log 
 
 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: Änderung der RG-ID 1-Rolle von Standby zu Aktiv 
 Januar 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: SWITCHOVER, von STANDBY_HOT zu ACTIVE-Status.
9. Januar 18:37:24.783: -1/xxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Erhaltene Benachrichtigung für aktives 
 
 Rollenereignis 9. Januar 18:37:25.758: -1/xxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Gesendet:
SIP REGISTRIEREN: 40462196.cisco-bcld.com:5061 SIP/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 
 An: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Datum: Do, 9. Januar 2020 18:37:24 
 GMT-Anruf-ID: FFFFFFFFEA0684EF-324511EA-FFFFFF800281CD-FFFFFFFFB5F93B97 
 Benutzer-Agent: Cisco-SIPGateway/IOS-16.12.02 
 Max.-Forwards: 70-Zeitstempel: 1578595044 
 CSeq: 2 Kontakt 
 REGISTRIEREN: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Abläuft: 240 
 werden unterstützt: Pfad 
 Inhalt -Länge: 0

9. Januar 18:37:25.995: -1/00000000000/SIP/Msg/ccsipDisplayMsg:
Erhalten:
SIP/2.0 401 Nicht autorisiert ü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 
 An: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 
 Datum: Do, 9. Januar 2020 18:37:24 
 GMT-Anruf-ID: FFFFFFFFEA0684EF-324511EA-FFFFFF800281CD-FFFFFFFFB5F93B97 
 Zeitstempel: 1578595044 
 CSeq: 2 REGISTRIEREN 
 WWW-Authenticate; DIGEST-Bereich="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5 
 Content-Length: 0

9. Januar 18:37:26.000: -1/xxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Gesendet:
REGISTRIEREN SIP:40462196.cisco-bcld.com:5061 SIP/2.0 Ü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 
 An: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Datum: Do, 9. Januar 2020 18:37:25 
 GMT-Anruf-ID: FFFFFFFFEA0684EF-324511EA-FFFFFF800281CD-FFFFFFFFB5F93B97 
 User-Agent:Cisco-SIPGateway/IOS-16.12.02 
 Max-Forwards: 70-Zeitstempel: 1578595045 
 CSeq: 3 Kontakt 
 REGISTRIEREN: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Abläuft: 240 
 werden unterstützt: Pfadautorisierung: 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/0000000000/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-324511EA-FFFFFF800281CD-FFFFFFFFB5F93B97 
 Zeitstempel: 1578595045 
 CSeq: 3 Kontakt 
 REGISTRIEREN: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 
 Allow-Events: Anruf-Info,Leitung-Aufruf,Dialog,Nachrichten-Zusammenfassung,As-Feature-Event,x-broadworks-hoteling,x-broadworks-call-center-status,Konferenzinhalte-Länge: 0