Fondamentaux
Prérequis
Avant de déployer CUBE HA en tant que passerelle locale pour Webex Calling, assurez-vous d’avoir une compréhension approfondie des concepts suivants :
Redondance box-à-box layer 2 avec CUBE Enterprise pour les équipes préservation de l’appel
Les instructions de configuration fournies dans cet article supposent une passerelle locale dédiée sans configuration vocale existante. Si un déploiement d’entreprise CUBE existant est en cours de modification pour utiliser également la fonction de la passerelle locale pour Cisco Webex Calling, faites attention attentive à la configuration appliquée pour vous assurer que les flux d’appels et les fonctionnalités existants ne sont pas interrompus et assurez-vous d’avoir accès aux exigences de conception cube de HA.
Composants matériels et logiciels
CUBE HA comme passerelle locale nécessite IOS-XE version 16.12.2 ou ultérieure et est pris en charge sur les plateformes suivantes :
Série ISR4000—4321, 4331, 4351, 4431, 4451, 4461 (IOS-XE 17.2.1r)
Série CSR1000—vCUBE (Configurations 1, 2 et 4 vCPU)
Les commandes et journaux d’afficher dans cet article sont basés sur une version logicielle minimum de Cisco IOS-XE 16.12.2 implémentée sur un vCUBE (CSR1000v). |
Documentation de référence
Voici quelques guides détaillés de configuration CUBE HA pour différentes plateformes :
CSR 1000v (vCUBE)—https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.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 Webex Calling la solution de groupe
Cisco Webex Calling est une offre de collaboration qui offre une alternative multi-tenante sur le Cloud au service téléphonique PBX sur site avec deux options de RTCP pour les clients :
Fournisseur d’accès RTCP cloud
Passerelle locale
Le déploiement de la passerelle locale (représentée ci-dessous) est le focus de cet article. La passerelle locale est l’option RTCP l’accès Cisco Webex Calling en fournissant une connectivité à un service RTCP client. Elle 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 en utilisant le transport TLS pour SIP et SRTP pour les médias.
La figure ci-dessous affiche un déploiement Webex Calling’un déploiement IP PBX existant et s’applique à un déploiement unique ou multis sites. La configuration décrite dans cet article est basée sur ce déploiement.
Redondance box à case couche 2
LA redondance box-à-box CUBE HA layer 2 utilise le protocole d’infrastructure Redondance Group (RG) pour former une paire active/en veille de routeurs. Ce pair partage la même adresse IP virtuelle (VIP) sur leurs interfaces respectives et échange continuellement des messages de statut. Les informations de la session CUBE sont cocher sur les deux routeurs, ce qui permet au routeur de veille d’prendre toutes les responsabilités de traitement des appels CUBE immédiatement si le routeur actif est hors service, ce qui entraîne la préservation publique de la signalisation et du support.
Le point de contrôle se limite aux appels connectés avec des paquets média. Les appels en transit ne sont pas pointés en cours de vérification (par exemple, l’état de tentative ou de sonnerie). Dans cet article, CUBE HA se référera à la redondance CUBE Haute disponibilité (HA) Layer 2 Box-to-box (B2B) pour les conditions préservation de l’appel |
À partir d’IOS-XE 16.12.2, CUBE HA peut être déployé en tant que passerelle locale pour les déploiements de Cisco Webex Calling et nous couvrirons les considérations de conception et les configurations dans cet article. Cette figure affiche une installation CUBE HA typique en tant que passerelle locale pour un Cisco Webex Calling déploiement.
Composant Infra du groupe de redondance
Le composant Infra (Redundancy Group)Infra (Groupe de redondance) fournit la prise en charge de l’infrastructure de communication box-to-box entre les deux CUBE et négocie l’état définitif stable de redondance. Ce composant fournit également :
Un protocole HSRP comme HSRP qui négociera l’état de redondance finale de chaque routeur en échangeant des messages keepalive et bonjour entre les deux CUBE (via l’interface de contrôle)—GigabitEthernet3 dans la figure ci-dessus.
Un mécanisme de transport pour le contrôle de l’état de signalisation et de média pour chaque appel du routeur actif au 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ées comme des interfaces de trafic.
Ce composant RG doit être spécifiquement configuré pour la prise en charge de la voix B2B HA.
Gestion des adresses IP virtuelle (VIP) à la fois pour la signalisation et les médias
B2B HA se base sur l’VIP pour atteindre la redondance. L’vip et les interfaces physiques associées sur les deux CUBE du pair CUBE HA doivent résider sur le même sous-réseau LAN. La configuration de l’interface VIP et de 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, Webex Calling accèdent à SBC, le fournisseur de service, ou le proxy, utilisent l’adresse VIP comme adresse IP de destination pour les appels qui traversent les routeurs CUBE de HA. Par conséquent, à partir Webex Calling point de vue, les paires CUBE HA agit comme une passerelle locale unique.
Les informations de signalisation des appels et de la session RTP des appels établis sont sur point de contrôle du routeur actif vers le routeur de veille. Lorsque le routeur actif est en panne, le routeur veille prend le contrôle et continue de faire suivre le flux RTP qui a été précédemment acheminé par le premier routeur.
Les appels en état de transition au moment du basculement ne seront pas conservé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 de mise en attente. Les appels qui ont été mis en place peuvent être déconnectés après le basculement.
Les exigences suivantes existent pour l’utilisation de CUBE HA comme passerelle locale pour leover (panne d’appel) stateful :
CUBE HA ne peut pas avoir de CTDM ou d’interfaces analogiques co-situées
Gig1 et Gig2 sont appelés des interfaces de trafic (SIP/RTP) et Gig3 est l’interface de contrôle/données de Redondance Group (RG)
Pas plus de 2 paires CUBE HA peuvent être placées dans le même domaine de la couche 2, un avec l’id de groupe 1 et l’autre avec l’id de groupe 2. Si vous configurez 2 pairs AVEC le même id de groupe, les interfaces de contrôle/données RG doivent appartenir à différents domaines de la couche 2 (vlan, commutateur séparé)
La chaine du port est prise en charge à la fois pour le contrôle/données RG et les interfaces de trafic
Tous les médias/signalisations sont provenant/vers l’adresse IP virtuelle
Chaque fois qu’une plateforme est rechargée dans une relation CUBE-HA, elle démarre toujours en tant que Veille
Adresse inférieure pour toutes les interfaces (Gig1, Gig2, Gig3) doit être sur la même plateforme
Identificateur de l’interface de redondance, rii doit être unique à une combinaison pair/interface sur la même couche 2
La configuration sur les deux CUBE doit être identique incluant la configuration physique et doit être en cours d’exécution sur le même type de plateforme et la version IOS-XE
Les interfaces de rappel ne peuvent pas être utilisées comme lier car elles sont toujours au courant
Plusieurs interfaces de trafic (SIP/RTP) (Gig1, Gig2) nécessitent que le suivi de l’interface soit configuré
CUBE-HA n’est pas pris en charge par une connexion par câble cable pour le lien RG-control/data (Gig3)
Les deux plateformes doivent être identiques et être connectées via un Commutateur physique sur toutes les interfaces également pour que CUBE HA fonctionne, par exemple CUBE0/0/0 de CUBE-1 et CUBE-2 doivent se terminer sur le même commutateur et ainsi de suite.
Impossible d’avoir WAN résilié sur les CUBE directement ou la HA de données sur l’un ou l’autre côté
Les deux centres de données Actif/Veille doivent être dans le même centre de données
Il est obligatoire d’utiliser l’interface L3 séparée pour la redondance (Contrôle RG/données, Gig3). par ex. l’interface utilisée pour le trafic ne peut pas être utilisée pour les keepalives ha et le point de contrôle
Lors du cas de panne, le CUBE précédemment actif passe par un rechargement par la conception, préserver la signalisation et le média
Configurer la redondance sur les deux CUBE
Vous devez configurer la redondance box-à-box couche 2 sur les deux CUBE conçus pour être utilisés dans un pair HA pour réunir les IP virtuels.
1 | Configurez le suivi de l’interface à un niveau global pour suivre le statut de l’interface.
Track CLI est utilisé dans RG pour suivre l’état de l’interface de trafic vocal afin que le routeur actif reste son rôle actif lorsque l’interface de trafic est à l’état actif. |
||||||
2 | Configurez un RG pour une utilisation avec VoIP HA sous le sous-mode de redondance de l’application.
Voici une explication des champs utilisés dans cette configuration :
|
||||||
3 | Activer la redondance box-à-box pour l’application CUBE. Configurez le RG de l’étape précédente sous
redondance-groupe 1 —Ajouter et supprimer cette commande nécessite un rechargement pour que laconfiguration mise à jour prenne effet. Nous rechargerons les plateformes lorsque toutes les configurations auront été appliquées. |
||||||
4 | Configurez les interfaces Gig1 et Gig2 avec leurs IP virtuelles respectives comme démontré ci-dessous et appliquez l’identificateur de l’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 plateforme pour recharger le dernier est toujours le veille.
Lorsque VCUBE-1 démarre complètement, enregistrez la configuration de VCUBE-2 et rechargez-la.
|
||||||
6 | Vérifiez que la configuration de la case à case fonctionne comme prévu. Les résultats pertinents sont mis en gras. Nous avons rechargé VCUBE-2 dernier et selon les considérations de conception ; la plateforme pour recharger le dernier sera toujours en veille .
|
Configurer une passerelle locale sur les deux CUBE
Dans notre exemple de configuration, nous utilisons les informations suivantes de Control Hub pour construire la configuration de la passerelle locale à la fois sur les plateformes, VCUBE-1 etVCUBE-2. Le nom d’utilisateur et le mot de passe pour cette installation sont les suivants :
Nom d’utilisateur : Hussain1076_LGU
Mot de passe : lOVA12MEaZx
1 | Assurez-vous qu’une clé de configuration est créée pour le mot de passe, avec les commandes affichées ci-dessous, avant qu’elle puisse être utilisée dans les identifiants ou les partages. Le type 6 mots de passe sont chiffrés à l’aide du chiffrement AES et cette clé de configuration définie par l’utilisateur.
Voici la configuration de la passerelle locale qui s’appliquera aux deux plateformes en fonction des paramètres control Hub affichés ci-dessus, d’enregistrer et de recharger. Les identifiants SIP Digest de Control Hub sont mis en surbrillons engras.
Pour afficher la sortie de commande, nous avons rechargé VCUBE-2 suivi par VCUBE-1 , qui fait deVCUBE-1 le standby CUBE et VCUBE-2 le CUBE actif |
2 | À tout moment donné, une seule plate-forme conservera un enregistrement actif en tant que passerelle locale avec accès Webex Calling SBC. Jetez un coup d’œil à la sortie des commandes d’afficher suivantes. afficher le groupe d’applications de redondance 1 afficher le statut sip-ua-register
À partir de la sortie ci-dessus, vous pouvez voir que VCUBE-2 est le LGW actif conservant l’enregistrement avec accès Webex Calling SBC, alors que la sortie du « afficher le statut d’inscription sip-register » est vide dans VCUBE-1 |
3 | Activez maintenant les débogages suivants sur VCUBE-1
|
4 | Simulez la panne en émettant la commande suivante sur le LGW actif, VCUBE-2 dans ce cas.
Le basculement de L’ACTIF vers le LGW STANDBY se produit dans le scénario suivant ainsi que le CLI listé ci-dessus
|
5 | Vérifiez si VCUBE-1 s’est inscrit avec Webex Calling SBC d’accès. VCUBE-2 se se serait chargé jusqu’à présent.
VCUBE-1 est maintenant le LGW actif. |
6 | Regardez le journal de débogage approprié sur VCUBE-1 en envoyant un ENREGISTREMENT SIP à un Webex Calling VIA l’IP virtuelle et en recevant un OK de 200.
|