Bases

Prérequis

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

VCUBE-1(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-1(config-track)#exit

VCUBE-2#conf t

VCUBE-2(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-2(config-track)#exit

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)#redundancy

VCUBE-1(config-red)#application redundancy

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

VCUBE-1(config-red-app-grp)#name LocalGateway-HA

VCUBE-1(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-1(config-red-app-grp)#timers delay 30 reload 60

VCUBE-1(config-red-app-grp)#track 1 shutdown

VCUBE-1(config-red-app-grp)#track 2 shutdown

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

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

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

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

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

VCUBE-1(config-red)#exit

VCUBE-1 (config) #

VCUBE-2(config)#redundancy

VCUBE-2(config-red)#application redundancy

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

VCUBE-2(config-red-app-grp)#name LocalGateway-HA

VCUBE-2(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-2(config-red-app-grp)#timers delay 30 reload 60

VCUBE-2(config-red-app-grp)#track 1 shutdown

VCUBE-2(config-red-app-grp)#track 2 shutdown

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

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

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

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

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

VCUBE-2(config-red)#exit

VCUBE-2 (config) #

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

  • redundancy—Enters redundancy mode

  • application redundancy—Enters application redundancy configuration mode

  • group—Enters redundancy application group configuration mode

  • name LocalGateway-HA—Defines the name of the RG group

  • priority 100 failover threshold 75—Specifies the initial priority and failover thresholds for an RG

  • timers delay 30 reload 60—Configures the two times for delay and reload

    • 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.

  • control GigabitEthernet3 protocol 1—Configures the interface used to exchange keepalive and hello messages between the two CUBEs, and specifies the protocol instance that will be attached to a control interface and enters redundancy application protocol configuration mode

  • data GigabitEthernet3—Configures the interface used for checkpointing of data traffic

  • track—RG group tracking of interfaces

  • protocol 1—Specifies the protocol instance that will be attached to a control interface and enters redundancy application protocol configuration mode

  • timers hellotime 3 holdtime 10—Configures the two timers for hellotime and holdtime:

    • 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)#voice service 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)# exit

VCUBE-2(config)#voice service 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)# exit

redundancy-group 1—Adding and removing this command requires a reload for the updated configuration to take effect. 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)# redundancy rii 1

VCUBE-1(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-1 (config) #

VCUBE-1(config)#interface GigabitEthernet2

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

VCUBE-1(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-2(config)#interface GigabitEthernet1

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

VCUBE-2(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-2(config-if)# exit

VCUBE-2 (config) #

VCUBE-2(config)#interface GigabitEthernet2

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

VCUBE-2(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-v(config-if)# exit

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

  • redundancy rii—Configures the redundancy interface identifier for the redundancy group. 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.

    If there is more than one B2B pair on the same LAN, each pair MUST have unique rii IDs on their respective interfaces (to prevent collision). ‘show redundancy application group all’ should indicate the correct local and peer information.

  • redundancy group 1—Associates the interface with the redundancy group created in Step 2 above. 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#reload

 Proceed with reload? [confirm]

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#reload

 Proceed with reload? [confirm]

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#show redundancy application group all Faults states Group 1 info:        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 : up 1, down 0, admin_down 0 reload events: 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, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0 VCUBE-1#
 VCUBE-2#show redundancy application group all Faults states Group 1 info:        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 : up 1, down 0, admin_down 0 reload events: 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 : Hussain1076_LGU

  • 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)#password encryption 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. SIP Digest credentials from Control Hub are highlighted in bold.

 configure terminal crypto pki trustpoint dummyTp revocation-check crl exit sip-ua crypto signaling default 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 address trusted list 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 Password123! sip g729 annexb-all early-offer forced end configure terminal voice class sip-profiles 200 rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)" "sip:\1" rule 10 request ANY sip-header To modify "<sips:(.*)" "<sip:\1" rule 11 request ANY sip-header From modify "<sips:(.*)" "<sip:\1" rule 12 request ANY sip-header Contact modify "<sips:(.*)>" "<sip:\1;transport=tls>" rule 13 response ANY sip-header To modify "<sips:(.*)" "<sip:\1" rule 14 response ANY sip-header From modify "<sips:(.*)" "<sip:\1" rule 15 response ANY sip-header Contact modify "<sips:(.*)" "<sip:\1" rule 20 request ANY sip-header From modify ">" ";otg=hussain1076_lgu>" rule 30 request ANY sip-header P-Asserted-Identity modify "sips:(.*)" "sip:\1" voice class codec 99 codec preference 1 g711ulaw codec preference 2 g711ulaw exit voice class srtp-crypto 200 crypto 1 AES_CM_128_HMAC_SHA1_80 exit voice class stun-usage 200 stun usage firewall-traversal flowdata exit voice class tenant 200 registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tls credentials number Hussain5091_LGU username Hussain1076_LGU password 0 lOV12MEaZx realm Broadworks authentication username Hussain5091_LGU password 0 lOV12MEaZx realm BroadWorks authentication username Hussain5091_LGU password 0 lOV12MEaZx realm 40462196.cisco-bcld.com no remote-party-id sip-server dns:40462196.cisco-bcld.com connection-reuse srtp-crypto 200 session transport tcp tls url sips error-passthru asserted-id pai bind control source-interface GigabitEthernet1 bind media source-interface GigabitEthernet1 no pass-thru content custom-sdp sip-profiles 200 outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com privacy-policy passthru voice class tenant 100 session transport udp url sip error-passthru bind control source-interface GigabitEthernet2 bind media source-interface GigabitEthernet2 no pass-thru content custom-sdp voice class tenant 300 bind control source-interface GigabitEthernet2 bind media source-interface GigabitEthernet2 no pass-thru content custom-sdp voice class uri 100 sip host ipv4:198.18.133.3 voice class uri 200 sip pattern dtg=hussain1076.lgu dial-peer voice 101 voip description Outgoing dial-peer to IP PSTN destination-pattern BAD.BAD session protocol sipv2 session target ipv4:198.18.133.3 voice-class codec 99 voice-class sip tenant 100 dtmf-relay rtp-nte no vad dial-peer voice 201 voip description Outgoing dial-peer to Webex Calling destination-pattern BAD.BAD session protocol sipv2 session target sip-server voice-class codec 99 voice-class stun-usage 200 no voice-class sip localhost voice-class sip tenant 200 dtmf-relay rtp-nte srtp no vad voice class dpg 100 description Incoming WebexCalling(DP200) to IP PSTN(DP101) dial-peer 101 preference 1 voice class dpg 200 description Incoming IP PSTN(DP100) to Webex Calling(DP201) dial-peer 201 preference 1 dial-peer voice 100 voip desription Incoming dial-peer from IP PSTN session protocol sipv2 destination dpg 200 incoming uri via 100 voice-class codec 99 voice-class sip tenant 300 dtmf-relay rtp-nte no vad dial-peer voice 200 voip description Incoming dial-peer from Webex Calling session protocol sipv2 destination dpg 100 incoming uri request 200 voice-class codec 99 voice-class stun-usage 200 voice-class sip tenant 200 dtmf-relay rtp-nte srtp no vad end copy run start

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)

show sip-ua register status 

 VCUBE-1#show redundancy application group 1 Group ID:1 Group Name:LocalGateway-HA Administrative State: No Shutdown Aggregate operational state : 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 : ACTIVE VCUBE-1#show sip-ua register status VCUBE-1#

 VCUBE-2#show redundancy application group 1 Group ID:1 Group Name:LocalGateway-HA Administrative State: No Shutdown Aggregate operational state : 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 --------------------Registrar-Index  1 --------------------- Line peer expires(sec) reg survival P-Associ-URI ============================== ========== ============ === ======== ============ Hussain5091_LGU -1 48 yes normal VCUBE-2#

From the output above, you can see that VCUBE-2 is the active LGW maintaining the registration with Webex Calling access SBC, whereas the output of the “show sip-ua register status” is blank in VCUBE-1

3

Activez maintenant les débogages suivants sur VCUBE-1

 VCUBE-1#debug ccsip non-call SIP Out-of-Dialog tracing is enabled VCUBE-1#debug ccsip info SIP Call info tracing is enabled 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#redundancy application reload group 1 self

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#show sip-ua register status Tenant: 200 --------------------Registrar-Index  1 --------------------- Line peer expires(sec) reg survival P-Associ-URI ============================== ========== ============ === ======== ============ Hussain5091_LGU -1 56 yes 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#show log Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: L’id RG 1 Bonjour a expiré. Jan 9 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG id 1 role change from Standby to Active Jan 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: SWITCHOVER, from STANDBY_HOT to ACTIVE state. Jan 9 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Received notify active role event Jan 9 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 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <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 REGISTER Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expires: 240 pris en charge : Longueur du contenu du chemin : 0 

Jan 9 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 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <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 

Jan 9 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 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <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 REGISTER Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expires: 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 Content-Length: 0 

Jan 9 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 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 timestamp : 1578595045 CSeq : 3 REGISTER Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 Allow-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