- Accueil
- /
- Article
Implémenter la haute disponibilité de CUBE en tant que passerelle locale
La passerelle locale (LGW) est la solution exclusive pour fournir un accès RTCP sur site aux clients de Cisco Webex Calling. Ce document vous guide dans la configuration d’une passerelle locale en utilisant la haute disponibilité de CUBE, avec des CUBE actifs ou en attente pour assurer le basculement de l’état des appels actifs.
Bases
Prérequis
Avant de déployer Cisco Unified Border Element (CUBE) High Availability (HA) en tant que passerelle locale pour Webex Calling, assurez-vous d’avoir une compréhension approfondie des concepts suivants :
-
Redondance boîte à boîte de couche 2 avec CUBE Enterprise pour la préservation des appels avec état
Les directives de configuration fournies dans cet article supposent une plateforme de passerelle locale dédiée sans configuration vocale existante. Si un déploiement existant de CUBE Enterprise est modifié pour utiliser également la fonction de passerelle locale pour Cisco Webex Calling, prêtez une attention particulière à la configuration appliquée pour vous assurer que les flux d’appels et les fonctionnalités existants ne sont pas interrompus et que vous respectez les exigences de conception de CUBE HA.
Composants matériels et logiciels
CUBE HA en tant que passerelle locale nécessite IOS-XE version 17.9.1 ou ultérieure et une plateforme sur laquelle les fonctions CUBE HA et LGW sont prises en charge.
Les commandes d’affichage et les journaux dans cet article sont basés sur la version logicielle minimum de Cisco IOS-XE 17.9.1 implémentée sur un vCUBE (CSR 8000v).
Matériel de référence
Voici quelques guides de configuration détaillés de CUBE HA pour différentes plateformes :
-
Cisco ISR 4K et Cisco Catalyst série 8K : 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
-
Architecture préférée de Cisco pour Cisco Webex Calling— https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Présentation de la solution Webex Calling
Cisco Webex Calling est une offre de collaboration qui fournit une alternative multi-locataire basée sur le cloud au service téléphonique PBX sur site avec plusieurs options RTCP pour les clients.
Le déploiement de la passerelle locale (représentée ci-dessous) est au centre de cet article. Le trunk de la passerelle locale (RTCP sur site) dans Webex Calling permet la connectivité à un service RTCP appartenant au client. Il fournit également une connectivité à un déploiement IP PBX sur site, tel que Cisco Unified CM. Toutes les communications vers et depuis le Cloud sont sécurisées à l’aide du transport TLS pour SIP et SRTP pour les médias.
La figure ci-dessous montre un déploiement de Webex Calling sans PBX IP existant et s’applique à un déploiement sur un ou plusieurs sites. La configuration décrite dans cet article est basée sur ce déploiement.
Redondance boîte à boîte de couche 2
La redondance boite à boite de couche 2 de CUBE HA utilise le protocole d’infrastructure Redundancy Group (RG) pour former une paire de routeurs actifs/en attente. Cette paire partage la même adresse IP virtuelle (VIP) sur leurs interfaces respectives et échange continuellement des messages d'état. Les informations de session CUBE sont vérifiées sur la paire de routeurs, ce qui permet au routeur en veille de prendre immédiatement en charge toutes les responsabilités de traitement des appels CUBE si le routeur actif est hors service, ce qui entraîne la préservation de l'état de la signalisation et des médias.
Le pointage de vérification est limité aux appels connectés avec des paquets de média. Les appels en transit ne sont pas contrôlés (par exemple, un état d’essai ou de sonnerie).
Dans cet article, CUBE HA fera référence à la redondance de couche 2 Box-to-Box (B2B) de CUBE High Availability (HA) (Haute disponibilité) pour la préservation de l’état des appels.
À partir d’IOS-XE 17.9.1, CUBE HA peut être déployé en tant que passerelle locale pour les déploiements de la ligne auxiliaire Cisco Webex Calling (RTCP sur site). Cet article traitera des considérations de conception et des configurations. La figure montre une configuration typique de CUBE HA en tant que passerelle locale pour un déploiement de trunk Cisco Webex Calling.
Composant infra du groupe de redondance
Le composant Infra du groupe de redondance (RG) fournit le support de l’infrastructure de communication boîte à boîte entre les deux CUBE et négocie l’état de redondance stable final. Ce composant fournit également :
-
Un protocole de type HSRP qui négocie l'état de redondance final pour chaque routeur en échangeant des messages keepalive et hello entre les deux CUBEs (via l'interface de contrôle)—GigabitEthernet3 dans la figure ci-dessus.
-
Un mécanisme de transport pour vérifier l'état de la signalisation et du média pour chaque appel du routeur actif vers le routeur en veille (via l'interface de données)—GigabitEthernet3 dans la figure ci-dessus.
-
Configuration et gestion de l’interface IP virtuelle (VIP) pour les interfaces de trafic (plusieurs interfaces de trafic peuvent être configurées en utilisant le même groupe RG) – GigabitEthernet 1 et 2 sont considérés comme des interfaces de trafic.
Ce composant RG doit être spécifiquement configuré pour prendre en charge la voix B2B HA.
Gestion des adresses IP virtuelles (VIP) pour la signalisation et les médias
B2B HA s’appuie sur VIP pour atteindre la redondance. Le VIP et les interfaces physiques associées sur les deux CUBEs de la paire CUBE HA doivent résider sur le même sous-réseau LAN. La configuration du VIP et la liaison de l'interface VIP à une application vocale particulière (SIP) sont obligatoires pour la prise en charge de la voix B2B HA. Les périphériques externes tels qu’Unified CM, le SBC d’accès à Webex Calling, le fournisseur de services ou le proxy, utilisent la VIP comme adresse IP de destination pour les appels traversant les routeurs CUBE HA. Par conséquent, du point de vue de Webex Calling, les paires CUBE HA agissent comme une passerelle locale unique.
La signalisation d'appel et les informations de session RTP des appels établis sont transférées du routeur actif au routeur en veille. Lorsque le routeur actif tombe en panne, le routeur en veille prend le relais et continue à transférer le flux RTP qui était précédemment acheminé par le premier routeur.
Les appels dans un état transitoire au moment du basculement ne seront pas préservés après le basculement. Par exemple, les appels qui ne sont pas encore complètement établis ou qui sont en cours de modification avec une fonction de transfert ou d'attente. Les appels établis peuvent être déconnectés après le basculement.
Les exigences suivantes existent pour l'utilisation de CUBE HA comme passerelle locale pour le basculement dynamique des appels :
-
CUBE HA ne peut pas avoir d’interfaces TDM ou analogiques co-localisées
-
Gig1 et Gig2 sont des interfaces de trafic (SIP/RTP) et Gig3 est l’interface de contrôle/données du groupe de redondance (RG)
-
Pas plus de 2 paires CUBE HA ne peuvent être placées dans le même domaine de couche 2, une avec l’ID de groupe 1 et l’autre avec l’identifiant de groupe 2. Si vous configurez 2 paires HA avec le même ID de groupe, les interfaces de contrôle/données RG doivent appartenir à des domaines de couche 2 différents (vlan, commutateur séparé)
-
Le canal de port est pris en charge à la fois pour les interfaces de contrôle/données RG et de trafic
-
Tous les signaux/médias proviennent de/vers l’adresse IP virtuelle
-
Chaque fois qu’une plate-forme est rechargée dans une relation CUBE-HA, elle démarre toujours en tant que veille
-
L’adresse inférieure pour toutes les interfaces (Gig1, Gig2, Gig3) doit être sur la même plateforme
-
L’identificateur d’interface de redondance, rii, doit être unique pour une combinaison paire/interface sur la même couche 2
-
La configuration sur les deux CUBEs doit être identique, y compris la configuration physique, et doit s’exécuter sur le même type de plateforme et la même version IOS-XE
-
Les interfaces de bouclage ne peuvent pas être utilisées comme liaison car elles sont toujours actives.
-
Les interfaces à trafic multiple (SIP/RTP) (Gig1, Gig2) nécessitent la configuration d'un suivi d'interface
-
CUBE-HA n’est pas pris en charge sur une connexion par câble croisé pour la liaison RG-control/données (Gig3)
-
Les deux plateformes doivent être identiques et être connectées via un commutateur physique sur toutes les interfaces similaires pour que CUBE HA fonctionne, c’est-à-dire que GE0/0/0 de CUBE-1 et CUBE-2 doivent se terminer sur le même commutateur et ainsi de suite.
-
Impossible que le réseau étendu (WAN) se termine directement sur les CUBEs ou sur Data HA de chaque côté
-
Les deux fonctions Active/Standby doivent se trouver dans le même centre de données
-
Il est obligatoire d’utiliser une interface L3 distincte pour la redondance (RG Control/data, Gig3), c’est-à-dire que l’interface utilisée pour le trafic ne peut pas être utilisée pour les keepalives HA et le contrôle
-
Lors du basculement, le CUBE précédemment actif subit un rechargement par sa conception, préservant la signalisation et les médias
Configurer la redondance sur les deux CUBEs
Vous devez configurer la redondance boite à boite de couche 2 sur les deux CUBE destinés à être utilisés dans une paire HD pour faire apparaître les IP virtuelles.
1 |
Configurez le suivi d’interface à un niveau global pour suivre l’état de l’interface.
Track CLI est utilisé dans RG pour suivre l’état de l’interface de trafic vocal afin que la route active reprenne son rôle actif après l’arrêt de l’interface de trafic. | ||
2 |
Configurez un RG pour une utilisation avec la VoIP HD sous le sous-mode de redondance d’application.
Voici une explication des champs utilisés dans cette configuration :
| ||
3 |
Activez la redondance boîte à boîte pour l’application CUBE. Configurez le RG à partir de l’étape précédente sous
redundancy-group 1–L’ajout et la suppression de cette commande nécessite un rechargement pour que la configuration mise à jour prenne effet. Nous rechargerons les plateformes une fois que toute la configuration aura été appliquée. | ||
4 |
Configurez les interfaces Gig1 et Gig2 avec leurs IP virtuelles respectives comme indiqué ci-dessous et appliquez l’identifiant d’interface de redondance (rii)
Voici une explication des champs utilisés dans cette configuration :
| ||
5 |
Enregistrez la configuration du premier CUBE et rechargez-le. La plate-forme à recharger en dernier est toujours la mise en veille.
Après le démarrage complet de VCUBE-1 , enregistrez la configuration de VCUBE-2 et rechargez-la.
| ||
6 |
Vérifiez que la configuration boîte à boîte fonctionne comme prévu. Les résultats pertinents sont mis en évidence en gras. Nous avons rechargé VCUBE-2 en dernier et conformément aux considérations de conception ; la plateforme à recharger en dernier sera toujours Veille. Ensuite, procédez à la configuration de la passerelle locale (basée sur l’enregistrement ou sur le certificat) sur les deux CUBE DE HD. Voir Configurer la passerelle locale sur Cisco IOS XE pour Webex Calling. |