- Startseite
- /
- Artikel
CUBE Hochverfügbarkeit als lokales Gateway implementieren
Das lokale Gateway (LGW) ist die exklusive Lösung für die Bereitstellung eines lokalen PSTN-Zugriffs für Cisco Webex Calling-Kunden. Dieses Dokument führt Sie bei der Konfiguration eines lokalen Gateways mit CUBE-Hochverfügbarkeit mit aktiven oder Standby-CUBEs, um einen zustandsbehafteten Failover von aktiven Anrufen zu gewährleisten.
Grundlagen
Voraussetzungen
Bevor Sie Cisco Unified Border Element (CUBE) High Availability (HA) als lokales Gateway für Webex Calling bereitstellen, sollten Sie über fundierte Kenntnisse der folgenden Konzepte verfügen:
-
Box-to-Box-Redundanz in Schicht 2 mit CUBE Enterprise für zustandsbehaftete Anrufbeibehaltung
Die Konfigurationsrichtlinien in diesem Artikel gehen von einer dedizierten lokalen Gateway-Plattform ohne vorhandene Sprachkonfiguration aus. Wenn eine vorhandene CUBE-Unternehmensbereitstellung geändert wird, um auch die lokale Gateway-Funktion für Cisco Webex Calling zu nutzen, achten Sie sorgfältig 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 Version 17.9.1 oder höher und eine Plattform, auf der sowohl CUBE HA- als auch LGW-Funktionen unterstützt werden.
Die in diesem Artikel angezeigten Befehle und Protokolle basieren auf der minimalen Softwareversion von Cisco IOS-XE 17.9.1, die auf einem vCUBE (CSR 8000v) implementiert ist.
Referenzmaterial
Im Folgenden finden Sie einige detaillierte CUBE HA-Konfigurationsleitfäden für verschiedene Plattformen:
-
Cisco ISR 4K- und Cisco Catalyst 8K-Serie – https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-isr-g3.html
-
CSR 8000v (vCUBE) – https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-csr.html
-
Bevorzugte Cisco-Architektur für Cisco Webex Calling – https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Übersicht über die 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) steht im Mittelpunkt dieses Artikels. Der lokale Gateway-Trunk (lokales PSTN) in Webex Calling ermöglicht die Verbindung mit einem kundeneigenen PSTN-Dienst. Außerdem stellt es eine Verbindung zu einer lokalen IP PBX-Bereitstellung wie Cisco Unified CM bereit. Die gesamte Kommunikation von und zur Cloud wird mit 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 für Einzel- oder Multi-Site-Bereitstellungen verwendet werden. Die in diesem Artikel beschriebene Konfiguration basiert auf dieser Bereitstellung.
Box-to-Box-Redundanz Schicht 2
Die Box-to-Box-Redundanz von CUBE HA in Schicht 2 verwendet das Infrastrukturprotokoll der Redundanzgruppe (RG), um ein Paar von aktiven/Standby-Routern zu bilden. Dieses Paar verwendet dieselbe virtuelle IP-Adresse (VIP) über die jeweiligen Schnittstellen und tauscht fortlaufend Statusmeldungen aus. Die CUBE-Sitzungsinformationen werden über das Routerpaar hinweg durch Prüfpunkte überprüft, sodass der Standby-Router alle Verantwortung für die CUBE-Anrufverarbeitung sofort übernehmen kann, wenn der aktive Router außer Betrieb ist, was zu einer zustandsbehafteten Beibehaltung von Signalisierung und Medien führt.
Die Prüfpunkte sind auf verbundene Anrufe mit Medienpaketen beschränkt. Anrufe während der Übertragung sind kein Prüfpunkt (z. B. ein Versuch- oder Rufton-Status).
In diesem Artikel bezieht sich CUBE HA auf die Box-to-Box-Redundanz (B2B) in CUBE High Availability (HA) Layer 2 für die zustandsbehaftete Anrufbeibehaltung.
Ab IOS-XE 17.9.1 kann CUBE HA als lokales Gateway für Trunk-Bereitstellungen von Cisco Webex Calling (lokales PSTN) bereitgestellt werden. In diesem Artikel werden Designüberlegungen und Konfigurationen behandelt. Die Abbildung zeigt ein typisches CUBE HA-Setup als lokales Gateway für eine Trunk-Bereitstellung von Cisco Webex Calling.
Infra-Komponente der Redundanzgruppe
Die Infra-Komponente der Redundanzgruppe (RG) bietet die Unterstützung der Box-to-Box-Kommunikationsinfrastruktur zwischen den beiden CUBEs 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 Keepalive- und Hello-Nachrichten zwischen den beiden CUBEs ausgetauscht werden (über die Steuerungsschnittstelle) – in der Abbildung oben GigabitEthernet3.
-
Ein Transportmechanismus zum Überprüfen der Signalisierung und des Medienstatus 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 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 Sprach-B2B HA konfiguriert werden.
Verwaltung virtueller IP-Adressen (VIP) für Signalisierung und Medien
B2B HA nutzt VIP, um Redundanz zu erzielen. Die VIP und die zugehörigen physischen Schnittstellen auf beiden CUBEs im CUBE HA-Paar 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 obligatorisch. Externe Geräte wie Unified CM, Zugriffs-SBC von Webex Calling, Dienstanbieter oder Proxy verwenden die VIP-Adresse als Ziel-IP-Adresse für Anrufe, die die CUBE HA-Router durchlaufen. Aus Webex Calling-Sicht fungieren die CUBE HA-Paare als ein einzelnes lokales Gateway.
Die Anrufsignalisierung und RTP-Sitzungsinformationen etablierter Anrufe werden vom aktiven Router zum Standby-Router geprüft. 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 zum Zeitpunkt des Failovers vorübergehend waren, werden nach dem Umschalten nicht beibehalten. Beispiel: Anrufe, die noch nicht vollständig hergestellt wurden oder gerade mit einer Transfer- oder Hold-Funktion geändert werden. Hergestellte Anrufe werden nach dem Umschalten möglicherweise getrennt.
Die folgenden Anforderungen gelten für die Verwendung von CUBE HA als lokales Gateway für den zustandsbehafteten Failover von Anrufen:
-
CUBE HA kann keine TDM oder analoge Schnittstellen nebeneinander haben
-
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 der andere mit der Gruppen-ID 2. Wenn Sie 2 HA-Paare mit derselben Gruppen-ID konfigurieren, müssen die RG-Steuerungs-/Datenschnittstellen zu verschiedenen Schicht-2-Domänen gehören (VLAN, separater Switch).
-
Der Portkanal wird sowohl für RG-Steuerungs-/Daten- als auch für Verkehrsschnittstellen unterstützt.
-
Alle Signalisierungen/Medien werden von/an die virtuelle IP-Adresse gesendet
-
Wenn eine Plattform in einer CUBE-HA-Beziehung neu geladen wird, wird sie immer als Standby-Modus gestartet.
-
Die untere Adresse für alle Schnittstellen (Gig1, Gig2, Gig3) sollte sich auf derselben Plattform befinden
-
ID 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.
-
Für mehrere Verkehrsschnittstellen (SIP/RTP) (Gig1, Gig2) muss die Schnittstellenverfolgung konfiguriert sein
-
CUBE-HA wird nicht über eine Crossover-Kabelverbindung für die RG-Steuerungs-/Datenverbindung (Gig3) unterstützt.
-
Beide Plattformen müssen identisch sein und über einen physischen Switch über alle gleichartigen Schnittstellen hinweg verbunden sein, 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 CUBEs oder Data HA auf beiden Seiten beendet werden
-
Sowohl der aktive als auch der Standby-Modus müssen sich im selben Rechenzentrum befinden.
-
Die Verwendung einer separaten L3-Schnittstelle für Redundanz ist obligatorisch (RG-Steuerung/Daten, Gig3), d. h. die für den Datenverkehr verwendete Schnittstelle kann nicht für HA-Keepalives und Prüfpunkte verwendet werden.
-
Beim Failover durchläuft der zuvor aktive CUBE konstruktionsbedingt ein erneutes Laden, wobei Signalisierung und Medien erhalten bleiben
Redundanz auf beiden CUBEs konfigurieren
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 IPs zu erstellen.
1 |
Konfigurieren Sie die Schnittstellenverfolgung auf globaler Ebene, um den Status der Schnittstelle nachzuverfolgen.
Track CLI wird in RG verwendet, um den Zustand der Sprachverkehrsschnittstelle nachzuverfolgen, sodass die aktive Route ihre aktive Rolle wieder aufnimmt, nachdem die Verkehrsschnittstelle ausgefallen ist. | ||
2 |
Konfigurieren Sie eine RG für die Verwendung mit VoIP HA im Untermodus „Anwendungsredundanz“.
Im Folgenden finden Sie eine Erklärung der in dieser Konfiguration verwendeten Felder:
| ||
3 |
Aktivieren Sie Box-to-Box-Redundanz für die CUBE-Anwendung. Konfigurieren Sie die RG aus dem vorherigen Schritt unter
redundancy-group 1 – Das Hinzufügen und Entfernen dieses Befehls erfordert ein erneutes Laden, damit die aktualisierte Konfiguration wirksam wird. Die Plattformen werden neu geladen, nachdem die gesamte Konfiguration angewendet wurde. | ||
4 |
Konfigurieren Sie die Schnittstellen Gig1 und Gig2 mit ihren jeweiligen virtuellen IPs wie unten gezeigt und wenden Sie den Bezeichner der Redundanzschnittstelle an (RII).
Im Folgenden finden Sie eine Erklärung der in dieser Konfiguration verwendeten Felder:
| ||
5 |
Speichern Sie die Konfiguration des ersten CUBE und laden Sie sie erneut. Die Plattform, die zuletzt neu geladen werden soll, ist immer die Standby-Plattform.
Speichern Sie nach dem vollständigen Start von VCUBE-1 die Konfiguration von VCUBE-2 , und laden Sie sie erneut.
| ||
6 |
Stellen Sie sicher, dass die Box-to-Box-Konfiguration wie erwartet funktioniert. Relevante Ergebnisse sind fett hervorgehoben. Wir haben VCUBE-2 gemäß den Designüberlegungen zuletzt neu geladen. Die Plattform, die zuletzt neu geladen werden soll, ist immer Standby. Fahren Sie als Nächstes mit der Konfiguration des lokalen Gateways (registrierungsbasiert oder zertifikatbasiert) auf beiden HA CUBEs fort. Siehe Lokales Gateway in Cisco IOS XE für Webex Calling konfigurieren. |