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 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit


VCUBE-1#conf t

VCUBE-1(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-1(config-track)#exit

VCUBE-2#conf t

VCUBE-2(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-2(config-track)#exit

Track CLI 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.

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)#

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

  • redundancy – Ruft den Redundanzmodus auf

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

  • group – Wechselt in den Konfigurationsmodus der 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 Timer 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.

  • control GigabitEthernet3 protocol 1 – Konfiguriert die Schnittstelle, die zum Austausch von Keepalive- und Hallo-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 die Überwachung des Datenverkehrs durch Prüfpunkte verwendet wird.

  • track – RG-Gruppennachverfolgung von Schnittstellen

  • protocol 1 – Legt die Protokollinstanz fest, 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 voice service voip. Dies ermöglicht es der CUBE-Anwendung, den Redundanzprozess zu steuern. 

voice service voip
   redundancy-group 1
   exit

VCUBE-1(config)#voice service voip

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


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

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

VCUBE-2(config)#voice service voip

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


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

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

redundancy-group 1 – 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)#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

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

  • redundancy rii – Konfiguriert den Bezeichner der Redundanzschnittstelle 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 es mehr als ein B2B-Paar im selben LAN gibt, MUSS jedes Paar eindeutige RII-IDs auf ihrer jeweiligen Schnittstelle haben (um Kollisionen zu vermeiden). 'show redundancy application group all' sollte die korrekten lokalen und Peer-Informationen anzeigen.

  • redundancy group 1 – Verknüpft die Schnittstelle mit der in Schritt 2 weiter 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


                        Building configuration...
                      


                        [OK]
                      

VCUBE-1#reload


                        Proceed with reload? [confirm]

Speichern Sie die Konfiguration von VCUBE-2 nach dem abgeschlossenen Neustart von VCUBE-1, und laden Sie sie neu.

VCUBE-2#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-2#reload


                        Proceed with reload? [confirm]
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
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#

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

Dies ist die Konfiguration des lokalen Gateways, die für beide Plattformen gilt und auf den oben angezeigten Control-Hub-Parametern basiert. Speichern Sie sie, und laden Sie sie neu. SIP-Digest-Anmeldeinformationen von Control Hub sind fett hervorgehoben.


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

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
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#

Aus der obigen Ausgabe können Sie ersehen, 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 is enabled
VCUBE-1#debug ccsip info
SIP Call info tracing is enabled
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#redundancy application reload group 1 self

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
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          56          yes 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#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