Bases

Conditions préalables

Avant de déployer CUBE HA comme passerelle locale pour Webex Calling, assurez-vous d’avoir une compréhension approfondie des concepts suivants :

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 adhérez aux exigences de conception de CUBE HA.

Composants matériels et logiciels

CUBE HA en tant que passerelle locale nécessite IOS-XE version 16.12.2 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 minimale de Cisco IOS-XE 16.12.2 mise en œuvre sur un vCUBE (CSR1000v).

Matériel de référence

Voici quelques guides de configuration détaillés de CUBE HA pour diverses plateformes :

Présentation de la solution Webex Calling

Cisco Webex Calling est une offre de collaboration qui fournit une alternative multi-tenant 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 tronc de la passerelle locale (RTCP sur site) dans Webex Calling permet la connectivité à un service RTCP appartenant au client. Elle permet également la connectivité à un déploiement PBX IP 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 présente 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 de boite à boite de niveau 2

La redondance boite à boite de niveau 2 de CUBE HA utilise le protocole d’infrastructure Redundancy Group (RG) pour former une paire de routeurs actifs/de secours. Cette paire partage la même adresse IP virtuelle (VIP) sur leurs interfaces respectives et échange continuellement des messages d’état. Les informations de la session CUBE sont mises en correspondance entre les deux routeurs, ce qui permet au routeur de réserve de prendre immédiatement en charge toutes les responsabilités de traitement des appels CUBE si le routeur actif est hors service, ce qui permet de préserver la signalisation et les médias.

Le contrôle 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 fait 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.

Depuis IOS-XE 16.12.2, 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) et nous aborderons les questions de conception et de configuration dans cet article. Cette figure montre une configuration typique de CUBE HA en tant que passerelle locale pour un déploiement de la ligne auxiliaire Cisco Webex Calling.

Composant d’infrastructure 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 CUBEs 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 le point de contrôle de l’état de la signalisation et du média pour chaque appel du routeur actif au routeur de secours (via l’interface de données)–GigabitEthernet3 dans la figure ci-dessus.

  • Configuration et gestion de l’interface Virtual IP (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 le VIP pour réaliser 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 par 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 attente. Lorsque le routeur actif tombe en panne, le routeur en veille prend le relais et continue à acheminer 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 train d’être modifiés par une fonction de transfert ou de mise en attente. Les appels établis peuvent être déconnectés après le basculement.

Les exigences suivantes s’appliquent à l’utilisation de CUBE HA comme passerelle locale pour le basculement des appels :

  • le 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, l’une avec l’D de groupe 1 et l’autre avec l’ID de groupe 2. Si vous configurez 2 paires HA avec le même identifiant 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 pour les interfaces de contrôle/données et de trafic du RG.

  • 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 de toutes les interfaces (Gig1, Gig2, Gig3) doit se trouver sur la même plateforme.

  • L’identifiant d’interface de redondance, rii, doit être unique pour une combinaison paire/interface sur la même couche 2.

  • La configuration des deux CUBEs doit être identique, y compris la configuration physique, et ils doivent fonctionner sur le même type de plateforme et la même version d’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 supporté 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 les GE0/0/0 de CUBE-1 et CUBE-2 doivent se terminer sur le même commutateur et ainsi de suite.

  • Le réseau étendu ne peut pas se terminer directement sur les CUBE ou sur le Data HA d’un côté ou de l’autre.

  • Les systèmes actifs et de secours 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.

  • En cas de basculement, le CUBE précédemment actif subit un rechargement par défaut, préservant la signalisation et les médias.

Configurer la redondance sur les deux CUBEs

Vous devez configurer la redondance boite à boite de niveau 2 sur les deux CUBE destinés à être utilisés dans une paire HD pour mettre en place les IP virtuelles.

1

Configurez le suivi d’interface à un niveau global pour suivre l’état de l’interface.

conf t 
 track 1 interface GigabitEthernet1 line-protocol 
 track 2 interface GigabitEthernet2 line-protocol 
 exit 

VCUBE-1#conf t

Interface VCUBE-1(config)#piste 1 Protocole de ligne GigabitEthernet1

Interface VCUBE-1(config-track)#piste 2 Protocole de ligne GigabitEthernet2

VCUBE-1(config-track)#quitter

VCUBE-2#conf t

Interface VCUBE-2(config)#piste 1 Protocole de ligne GigabitEthernet1

VCUBE-2(config-track)#Protocole de ligne d'interface GigabitEthernet2 de la piste 2

VCUBE-2(config-track)#quitter

Le suivi de l’interface 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 l’utiliser avec la VoIP HD sous le sous-mode de redondance d’application.

redondance de l’application groupe 1 nom 
 
 
    LocalGateway-HA priorité 
    100 failover threshold 75 
    contrôle GigabitEthernet3 protocole 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)#redondance

VCUBE-1(config-red)#redondance de l'application

VCUBE-1(config-red-app)#groupe 1

VCUBE-1(config-red-app-grp)#nom Passerelle locale-HA

VCUBE-1(config-red-app-grp)#seuil de basculement de la priorité 100 75

VCUBE-1(config-red-app-grp)#contrôler le protocole GigabitEthernet3 1

VCUBE-1(config-red-app-grp)#données GigabitEthernet3

VCUBE-1(config-red-app-grp)#timers délai 30 rechargement 60

VCUBE-1(config-red-app-grp)#arrêt de la piste 1

VCUBE-1(config-red-app-grp)#arrêt de la piste 2

VCUBE-1(config-red-app-grp)#quitter

VCUBE-1(config-red-app)#protocole 1

VCUBE-1(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-1(config-red-app-prtcl)#quitter

VCUBE-1(config-red-app)#quitter

VCUBE-1(red-config)#quitter

VCUBE-1 (config) #

VCUBE-2(config)#redondance

VCUBE-2(config-red)#redondance de l'application

VCUBE-2(config-red-app)#groupe 1

VCUBE-2(config-red-app-grp)#nom Passerelle locale-HA

VCUBE-2(config-red-app-grp)#seuil de basculement de la priorité 100 75

VCUBE-2(config-red-app-grp)#contrôler le protocole GigabitEthernet3 1

VCUBE-1(config-red-app-grp)#données GigabitEthernet3

VCUBE-2(config-red-app-grp)#timers délai 30 rechargement 60

VCUBE-2(config-red-app-grp)#arrêt de la piste 1

VCUBE-2(config-red-app-grp)#arrêt de la piste 2

VCUBE-2(config-red-app-grp)#quitter

VCUBE-2(config-red-app)#protocole 1

VCUBE-2(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-2(config-red-app-prtcl)#quitter

VCUBE-2(config-red-app)#quitter

VCUBE-2(red-config)#quitter

VCUBE-2 (config) #

Voici une explication des champs utilisés dans cette configuration :

  • redondance–Entre en mode redondance

  • redondance de l'application–Saisit le mode de configuration de la redondance de l'application

  • groupe–Saisit le mode de configuration du groupe d’applications de redondance

  • nom de la passerelle locale-HA–Définit le nom du groupe RG

  • seuil de basculement de la priorité 100 75—Spécifie la priorité initiale et les seuils de basculement pour un RG

  • timers delay 30 reload 60–Configure les deux fois de retard et de rechargement

    • Temporisateur de retard qui est la quantité de temps pour retarder l’initialisation du groupe RG et la négociation de rôle après que l’interface soit ouverte – Pae défaut 30 secondes. La plage est de 0 à 10 000 secondes.

    • Rechargement – Il s’agit du temps nécessaire pour retarder l’initialisation du groupe RG et la négociation des rôles après un rechargement – Valeur par défaut : 60 secondes. La plage est de 0 à 10 000 secondes.

    • Les temporisations par défaut sont recommandées, bien que ces temporisations puissent être ajustées pour tenir compte de tout délai supplémentaire de convergence du réseau qui peut se produire pendant le démarrage/le rechargement des routeurs, afin de garantir que la négociation du protocole RG a lieu après que le routage dans le réseau a convergé vers un point stable. Par exemple, si l’on constate après un basculement qu’il faut jusqu’à 20 secondes au nouveau STANDBY pour voir le premier paquet RG HELLO du nouvel ACTIVE, les temporisateurs doivent être ajustés à « timers delay 60 reload 120 » pour prendre en compte ce délai.

  • contrôler le protocole 1 GigabitEthernet3–Configure l’interface utilisée pour échanger des messages keepalive et hello entre les deux CUBEs, et spécifie l’instance de protocole qui sera attachée à une interface de contrôle et entre le mode de configuration du protocole d’application de redondance

  • data GigabitEthernet3–Configure l'interface utilisée pour le contrôle du trafic de données

  • suivi—Suivi des interfaces par le groupe RG

  • protocole 1–Spécifie l'instance de protocole qui sera attachée à une interface de contrôle et saisit le mode de configuration du protocole d'application de redondance

  • timers hellotime 3 holdtime 10–Configure les deux temporisateurs pour le temps d’accueil et le temps de rétention :

    • Heure d’appel–Intervalle entre les messages d’appel successifs - Valeur par défaut : 3 secondes. La plage est de 250 millisecondes à 254 secondes.

    • Holdtime- L’intervalle entre la réception d’un message d’accueil et la présomption que le routeur émetteur a échoué. Cette durée doit être supérieure à la durée du message d’accueil - Par défaut 10 secondes. La plage est de 750 millisecondes à 255 secondes.

      Nous vous recommandons de configurer l’heure de maintien (holdtime) pour qu’il soit au moins 3 fois supérieur à la valeur de l’heure d’accueil (hello-time).

3

Activez la redondance boîte à boîte pour l’application CUBE. Configurez le RG de l’étape précédente sous Voix sur IP (Voip) du servicevocal. Ceci permet à l’application CUBE de contrôler le processus de redondance.

service vocal voip 
   redondance-groupe 1 
   sortie

VCUBE-1(config)#Service vocal VoIP

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

 % a créé l’association RG 1 avec voix B2B HA ; recharger le routeur pour que la nouvelle configuration prenne effet 

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

VCUBE-2(config)#Service vocal VoIP

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

 % a créé l’association RG 1 avec voix B2B HA ; recharger le routeur pour que la nouvelle configuration prenne effet 

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

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 après que toute la configuration ait é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).

VCUBE-1(config)#interface GigabitEthernet1

VCUBE-1(config-if)# redondance rii 1

VCUBE-1(config-if)# groupe de redondance 1 ip 198.18.1.228 exclusif

VCUBE-1(config-if)# sortie

VCUBE-1 (config) #

VCUBE-1(config)#interface GigabitEthernet2

VCUBE-1(config-if)# redondance rii 2

VCUBE-1(config-if)# groupe de redondance 1 ip 198.18.133.228 exclusif

VCUBE-1(config-if)# sortie

VCUBE-2(config)#interface GigabitEthernet1

VCUBE-2(config-if)# redondance rii 1

VCUBE-2(config-if)# groupe de redondance 1 ip 198.18.1.228 exclusif

VCUBE-2(config-if)# sortie

VCUBE-2 (config) #

VCUBE-2(config)#interface GigabitEthernet2

VCUBE-2(config-if)# redondance rii 2

VCUBE-2(config-if)# groupe de redondance 1 ip 198.18.133.228 exclusif

VCUBE-v(config-if)# sortie

Voici une explication des champs utilisés dans cette configuration :

  • redundancy rii–Configure l’identifiant de l’interface de redondance pour le groupe de redondance. Requis pour générer une adresse MAC virtuelle (VMAC). La même valeur d’ID rii doit être utilisée sur l’interface de chaque routeur (ACTIF/STANDBY) qui a le même VIP.

    S’il y a plus d’une paire B2B sur le même réseau local, chaque paire DOIT avoir des ID rii uniques sur leurs interfaces respectives (pour éviter les collisions). « show redundancy application group all » devrait indiquer les informations locales et les informations sur les pairs.

  • groupe de redondance 1–Associe l’interface au groupe de redondance créé à l’étape 2 ci-dessus. Configurez le groupe RG, ainsi que le VIP attribué à cette interface physique.

    Il est obligatoire d’utiliser une interface séparée pour la redondance, c’est-à-dire que l’interface utilisée pour le trafic vocal ne peut pas être utilisée comme interface de contrôle et de données spécifiée à l’étape 2 ci-dessus. Dans cet exemple, l’interface Gigabit 3 est utilisée pour le contrôle/données RG

5

Enregistrez la configuration du premier CUBE et rechargez-le.

La plateforme à recharger en dernier est toujours celle en attente.

VCUBE-1#wr

 Configuration du bâtiment... 

 [OK] 

VCUBE-1#recharger

 Procéder au rechargement ? [confirmer]

Lorsque VCUBE-1 démarre complètement, enregistrez la configuration de VCUBE-2 et rechargez-la.

VCUBE-2#wr

 Configuration du bâtiment... 

 [OK] 

VCUBE-2#recharger

 Procéder au rechargement ? [confirmer]

6

Vérifiez que la configuration box-to-box 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 plate-forme à recharger en dernier sera toujours Standby (Veille). 

 VCUBE-1#afficher l’application de redondance groupe tous les États de défauts Informations du groupe 1 :        Priorité de l’runtime : [100] RG Faults État du RG : En haut.                        Nombre total de basculements en raison de pannes :  0 nombre total de modifications de l’État en cas de panne : 0 ID du groupe : 1 nom du groupe : LocalGateway- État administratif HD : Aucun état opérationnel global d’arrêt :  Mon rôle : Rôle d’homologue actif : Présence de l' homologue de secours : Oui comm pair : Oui la progression de l’homologue a démarré : Oui domaine RF : BtoB-un État RF : État RF pair actif : Rôle de l'------------------du protocole RG 1 de secours Négociation active : Priorité activée : État du protocole 100 : État actif de la Ctrl INTF (s) : Pair actif : Homologue de secours local : adresse 10.1.1.2, priorité 100, INTF Gi3 journaux compteurs :                 changement de rôle par actif : 1 changement de rôle en mode veille : 1 désactiver les événements : RG Down État 0, RG arrêter 0 Ctrl INTF Events : haut 1, bas 0, admin_down 0 événements de rechargement : demande locale 0, demande d’homologue 0 RG Context média pour RG 1--------------------------État CTX : ID du protocole actif : 1 type de média : Interface de contrôle par défaut : GigabitEthernet3 minuteur de salutation actuel : 3000 minuteur de salutation configuré : 3000, Durée d’attente : 10000 de l’horloge Hello de l’homologue : 3000, Temps d’attente du pair : 10000 statistiques :             Paquets 1509, octets 93558, HD seq 0, Seq Number 1509, PKT perte 0 authentification non configurée échec de l’authentification : 0 recharger l’homologue : TX 0, RX 0 abandonner : TX 0, RX 0 pair de la stand : Présent. Délai d’attente : 10000 Pkts 61, Octets 2074, HA Seq 0, Seq Number 69, Pkt Loss 0 VCUBE-1#
 VCUBE-2#afficher la redondance application groupe tous États de défauts Informations sur le groupe 1 :        Priorité de l’runtime : [100] RG Faults État du RG : En haut.                        Nombre total de basculements en raison de pannes :  0 nombre total de modifications de l’État en cas de panne : 0 ID du groupe : 1 nom du groupe : LocalGateway- État administratif HD : Aucun état opérationnel global d’arrêt : Mon rôle : Rôle d’homologue de secours : Présence de l' homologue actif : Oui comm pair : Oui la progression de l’homologue a démarré : Oui domaine RF : BtoB-un État RF : État RF pair actif : Rôle de l'------------------du protocole RG 1 de secours Négociation active : Priorité activée : État du protocole 100 : État actif de la Ctrl INTF (s) : Pair actif : adresse 10.1.1.2, priorité 100, INTF Gi3 homologue de secours : Compteurs du journal local :                 changement de rôle par actif : 1 changement de rôle en mode veille : 1 désactiver les événements : RG Down État 0, RG arrêter 0 Ctrl INTF Events : haut 1, bas 0, admin_down 0 événements de rechargement : demande locale 0, demande d’homologue 0 RG Context média pour RG 1--------------------------État CTX : ID du protocole actif : 1 type de média : Interface de contrôle par défaut : GigabitEthernet3 minuteur de salutation actuel : 3000 minuteur de salutation configuré : 3000, Durée d’attente : 10000 de l’horloge Hello de l’homologue : 3000, Temps d’attente du pair : 10000 statistiques :             Paquets 1509, octets 93558, HD seq 0, Seq Number 1509, PKT perte 0 authentification non configurée échec de l’authentification : 0 recharger l’homologue : TX 0, RX 0 abandonner : TX 0, RX 0 pair de la stand : Présent. Délai d’attente : 10000 
 Pkts 61, Octets 2074, HA Seq 0, Numéro 69 Séq, Pkt Perte 0 
 
 VCUBE-2 #

Configurer une passerelle locale sur les deux CUBEs

Dans notre configuration d’exemple, nous utilisons les informations suivantes du tronc du Control Hub pour construire la configuration de la passerelle locale sur les deux plateformes, VCUBE-1 et VCUBE-2. Le nom d’utilisateur et le mot de passe pour cette configuration sont les suivants :

  • Nom d’utilisateur : Hussain1076LGU_

  • Mot de passe : lOV12MEaZx

1

Assurez-vous qu’une clé de configuration est créée pour le mot de passe, avec les commandes indiquées ci-dessous, avant qu’il ne puisse être utilisé dans les informations d’identification ou les secrets partagés. Les mots de passe de type 6 sont cryptés à l’aide du chiffrement AES et de cette clé de configuration définie par l’utilisateur. 

 LocalGateway#conf t LocalGateway(config)#key config-key password-encrypt Password123 LocalGateway(config)#mot de passe de chiffrement aes

Voici la configuration de la passerelle locale qui s’appliquera aux deux plateformes en fonction des paramètres du Hub de contrôle affichés ci-dessus, enregistrer et recharger. Les informations d’identification SIP Digest du Control Hub sont mises en surbrillance en gras.

 configure terminal crypto pki trustpoint dummyTp revocation-check crl exit sip-ua crypto signalisation par défaut 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 liste de confiance 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 Mot de passe123 ! sip g729 annexb-all early-offer forced end configure terminal class voice sip-profiles 200 règle 9 demande ANY sip-en-tête SIP-Req-URI modifier "sips:(.*)" "" ";otg=hussain1076_lgu>" règle 30 demande TOUT sip-en-tête P-Asserted-Identity modifier "sips:(.*)" "sip:\1" classe vocale codec 99 codec préférence 1 g711ulaw codec préférence 2 g711ulaw sortie classe vocale srtp-crypto 200 crypto 1 AES_cm_128_mac_sha1_80 sortie de la classe vocale stun-usage 200 stun usage firewall-traversée flowdata sortie tenant de la classe vocale 200 registraire dns : 40462196.cisco-bcld.com schéma sips expire 240 rapport d'actualisation 50 informations d'authentification tcp tls Hussain5091_lgu nom d'utilisateur Hussain1076_Mot de passe LGU 0 OV12MEaZx nom d’utilisateur d’authentification Broadworks du domaine Hussain5091_lgu mot de passe 0 OV12MEaZx nom d'utilisateur d'authentification BroadWorks du domaine Hussain5091_lgu mot de passe 0 OV12MEaZx royaume 40462196.cisco-bcld.com pas de serveur sip distant-party-id dns : 40462196.cisco-bcld.com connexion-réutiliser srtp-crypto 200 session transport tcp tls url sips erreur-passthru asserted-id pai bind source-interface contrôle GigabitEthernet1 bind source-interface média GigabitEthernet1 pas de contenu pass-thru personnalisé-sdp sip-profiles 200 sortant-proxy dns : la01.sipconnect-us10.cisco-bcld.com politique de confidentialité passthru class vocale tenant 100 session transport udp url sip erreur-passthru bind control source-interface GigabitEthernet2 bind source-interface média GigabitEthernet2 aucun contenu passe-thru custom-sdp class vocale tenant 300 bind control source-interface GigabitEthernet2 bind source-interface média GigabitEthernet2 aucun contenu passe-thru custom-sdp class vocale uri 100 sip hôte ipv4:198.18.133.3 classe vocale uri 200 sip pattern dtg=hussain1076.lgu voix de numérotation 101 description de la voip Numérotation sortante vers le modèle de destination IP RTCP BAD.BAD protocole de session sipv2 session cible ipv4:198.18.133.3 codec de classe vocale 99 tenant sip de classe vocale 100 dtmf-relay rtp-nte pas de vad dial-peer voix 201 description de la voip Numérotation sortante vers le modèle de destination Webex Calling BAD.BAD protocole de session sipv2 cible de la session sip-serveur codec 99 classe vocale stun-usage 200 pas de classe vocale sip localhost 200 dtmf-relay rtp-nte srtp pas de vad classe vocale dpg 100 description WebexCalling entrant(DP200) vers IP RTCP(DP101) numérotation 101 préférence 1 classe vocale dpg 200 description IP RTCP entrant(DP100) vers Webex Calling(DP201) numérotation 201 préférence 1 voix de numérotation 100 voix desription Numérotation entrante du protocole de session IP RTCP sipv2 destination dpg 200 uri entrante via 100 codec de classe vocale 99 tenant sip de classe vocale 300 dtmf-relay rtp-nte pas de vad demande d’uri entrante 200 codec de classe vocale 99 classe vocale st

Pour afficher la sortie de la commande show, nous avons rechargé VCUBE-2 suivi de VCUBE-1, faisant de VCUBE-1 le CUBE de secours et de VCUBE-2 le CUBE actif.

2

À tout moment, une seule plate-forme maintiendra un enregistrement actif en tant que passerelle locale avec le SBC d’accès à l’appel Webex. Regardez la sortie des commandes suivantes.

Afficher l’application de redondance de groupe 1 (redundancy application group 1)

afficher le statut du registre sip-ua 

 VCUBE-1#afficher l’application de redondance groupe 1 ID de groupe : 1 Nom de groupe : passerelle locale-HA État administratif : Aucun état opérationnel agrégé d'arrêt : Mon rôle :  Rôle d’homologue de secours : Présence de l’homologue actif : Oui comm pair : Oui la progression de l’homologue a démarré : Oui domaine RF : BtoB-un État RF : État RF de l’homologue HOT-STANDBY : VCUBE-1 ACTIF#afficher le statut du registre sip-ua VCUBE-1#

 VCUBE-2#afficher l’application de redondance groupe 1 ID de groupe : 1 Nom de groupe : passerelle locale-HA État administratif : Aucun état opérationnel agrégé d'arrêt : Mon rôle :  Rôle d’homologue actif : STATUT de présence de l’homologue : Oui comm pair : Oui la progression de l’homologue a démarré : Oui domaine RF : BtoB-un État RF : État RF pair actif : SECOURS VCUBE-2 #Show SIP-UA Register statut client : 200 --------------------Registraire-Index  1 pair de --------------------- ligne expire(s) reg survie P-Associ-URI ============================== ========== ============ ============= ============ Hussain5091_LGU -1 48 oui normal VCUBE-2#

À partir de la sortie ci-dessus, vous pouvez voir que VCUBE-2 est la LGW active qui maintient l’enregistrement avec le SBC d’accès à Webex Calling, alors que la sortie de « afficher le statut d’enregistrement sip-ua » est vide dans VCUBE-1

3

Activez maintenant les débogages suivants sur VCUBE-1

 VCUBE-1#debug ccsip non-appel SIP Out-of-Dialog suivi est activé VCUBE-1#debug ccsip info Le suivi des informations d'appel SIP est activé VCUBE-1#debug ccsip message

4

Simulez le basculement en émettant la commande suivante sur la LGC active, VCUBE-2 dans ce cas.

 VCUBE-2#redondance de l’application recharger le groupe 1 lui-même

Le basculement de la LGC ACTIVE vers la LGC EN ATTENTE se produit dans le scénario suivant, en plus de la CLI listée ci-dessus.

  • Lorsque le routeur ACTIF se recharge

  • Lorsque le routeur ACTIF effectue un cycle d’alimentation

  • Lorsqu’une interface configurée RG du routeur ACTIF est arrêtée et que le suivi est activé.

5

Vérifiez que VCUBE-1 s’est enregistré auprès du SBC d’accès à l’appel Webex. VCUBE-2 aurait déjà été rechargé.

 VCUBE-1#afficher le statut d’inscription du tenant sip-ua : 200 --------------------Registraire-Index  1 --------------------- Ligne pair expires(s) reg survie reg P-Associ-URI ============================== ========== ============================================================================================================================================================================================================================================================================================ Hussain5091_LGU -1 56 oui normal vcube-1#

VCUBE-1 est maintenant la LGC active.

6

Regardez le journal de débogage pertinent sur VCUBE-1 envoyant un SIP REGISTER à Webex Calling via l’IP virtuelle et recevant un 200 OK.

 VCUBE-1#afficher le journal 9 janvier 18:37:24.769 : %RG_MEDIA-3-TIMEREXPIRED : L’id RG 1 Bonjour a expiré.9  janvier 18:37:24.771 : %RG_PROTCOL-5-ROLECHANGE : Changement du rôle RG id 1 de la veille à actif 9 janvier 18:37:24.783 : %VOICE_HA-2-SWITCHOVER_IND : Basculement, de l'état VEILLE_CHAUD à l'état ACTIF. 9 janvier 18:37:24.783 : //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event : Réception de la notification d'événement de rôle actif le 9 janvier 18:37:25.758 : //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg : Envoyé : ENREGISTRER SIP : 40462196.cisco-bcld.com :5061 SIP/2.0 via : SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374 De : <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 À : <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Date : Jeu, 09 Jan 2020 18:37:24 GMT-ID d’appel : FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 utilisateur-agent : Cisco-SIPGateway/IOS-16.12.02 Max-transfert : 70 horodateur : 1578595044 CSeq : 2 S’INSCRIRE Contact : <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expire : 240 pris en charge : Longueur du contenu du chemin : 0 

9 janv 18:37:25.995 : //-1/000000000000/SIP/Msg/ccsipDisplayMsg : Reçu: SIP/2.0 401 non autorisé via : SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742 De : <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 À : <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 Date : Jeu, 09 Jan 2020 18:37:24 GMT-ID d’appel : FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 timestamp : 1578595044 CSeq : 2 enregistrez l’authentification Web ; DIGEST Realm = "BroadWorks", QoP = "auth", nonce = "BroadWorksXk572qd01Ti58zliBW", algorithme = longueur de contenu MD5 : 0 

9 janv 18:37:26.000 : //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg : Envoyé : ENREGISTRER SIP : 40462196. Cisco-bcld.com :5061 SIP/2.0 via : SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC De : <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 À : <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Date : Jeu, 09 Jan 2020 18:37:25 GMT-ID d’appel : FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 utilisateur-agent : Cisco-SIPGateway/IOS-16.12.02 Max-transferts : 70 horodateur : 1578595045 CSeq : 3 ENREGISTRER le contact : <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expire : 240 pris en charge : Autorisation du chemin : 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 Longueur du contenu : 0 

9 janv 18:37:26.190 : //1/000000000000/SIP/Msg/ccsipDisplayMsg :  Reçu: SIP/2.0 200 OK Via : SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742 De : <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 À : <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 ID d’appel : FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 timestamp : 1578595045 CSeq : 3 S’INSCRIRE Contact : <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 Autoriser-Events : Call-infos, saisie de ligne, dialogue, message-résumé, en tant que fonctionnalité-événement, x-BroadWorks-hôtel, x-BroadWorks-Call-Center-statut, contenu de la Conférence-longueur : 0