Grundlagen
Voraussetzungen
Bevor Sie CUBE HA als lokales Gateway für Webex Calling bereitstellen, müssen Sie die folgenden Konzepte ausführlich verstehen:
Layer-2-Box-To-Box-Redundanz mit CUBE Enterprise für Anruf beibehalten
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:
ISR 4K-Serie –https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
CSR 1000v (v CUBE) –https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
Cisco Preferred Architecture für Cisco Webex Calling -https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
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.
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.
Im Folgenden finden Sie eine Erklärung zu den Feldern, die in dieser Konfiguration verwendet werden:
|
||||||
3 | Aktivieren Sie die Box-to-Box-Redundanz für die CUBE-Anwendung. Konfigurieren Sie die RG aus dem vorherigen Schritt unter
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.
Im Folgenden finden Sie eine Erklärung zu den Feldern, die in dieser Konfiguration verwendet werden:
|
||||||
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.
Nachdem VEINSTELLUNGEN-1 vollständig hoch gestartet wurde, speichern Sie die Konfiguration von V CUBE-2 und laden Sie sie erneut hoch.
|
||||||
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.
|
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.
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.
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
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
|
4 | Simulieren Sie ein Failover, indem Sie in diesem Fall den folgenden Befehl auf dem aktiven LGW, V CUBE-2, ausstellen.
Der Wechsel vom ACTIVE zum STANDBY LGW erfolgt auch im folgenden Szenario neben der oben aufgeführten CLI.
|
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 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.
|