Fondamentaux

Prérequis

Avant de déployer le CUBE HD en tant que passerelle locale pour Webex Calling, assurez-vous d’avoir une connaissance approfondie des concepts suivants :

Les instructions de configuration fournies dans cet article supposent une plateforme de passerelle locale dédiée sans configuration vocale existante. Si un déploiement d’entreprise existant d’un CUBE est en cours de modification pour utiliser également la fonction de passerelle locale pour Cisco Webex Calling, soyez attentif à la configuration appliquée pour garantir que les flux d’appels existants et les fonctionnalités ne sont pas interrompues et vérifiez que vous respectez les exigences de conception de CUBE HD.

Composants matériels et logiciels

Le CUBE HD en tant que passerelle locale nécessite IOS-XE version 16.12.2 ou plus récente et est pris en charge sur les plateformes suivantes :

  • Série ISR4000 — 4321, 4331, 4351, 4431, 4451, 4461 (IOS-XE 17.2.1 r)

  • Série CSR1000 — vCUBE (1, 2 et 4 configurations de CPU)

Les commandes Show et les journaux 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 de la HD du CUBE pour différentes plateformes :

Présentation de la solution Webex Calling

Cisco Webex Calling est une offre de collaboration qui fournit une alternative multi-client sur le Cloud au service téléphonique PBX sur site avec deux options de RTCP pour les clients :

  • Connexion du Cloud RTCP fournisseur
  • Passerelle locale

Le déploiement de la passerelle locale (représenté ci-dessous) est le point de vue de cet article. La passerelle locale est l’option donner votre propre RTCP pour Cisco Webex Calling en permettant la connectivité à un service RTCP appartenant à un client. Il fournit é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 via le transport TLS pour SIP et SRTP pour le média.

L’illustration ci-dessous affiche un déploiement Webex Calling sans PBX IP existant et est applicable à un déploiement individuel ou à plusieurs sites. La configuration décrite dans cet article est basée sur ce déploiement.

Redondance de la zone à boîte de Layer 2

La redondance Box-to-Box de la couche 2 de CUBE HD utilise le protocole d’infrastructure de groupe de redondance (RG) pour former un pair de routeurs actif/en attente. Cette paire partage la même adresse IP virtuelle (VIP) sur leurs interfaces respectives et échange continuellement les messages d’État. Les informations de la session de CUBE sont cochées dans le pair des routeurs permettant au routeur de secours de prendre toutes les responsabilités de traitement des appels de CUBE immédiatement si le routeur actif est hors service, provoquant ainsi une préservation dynamique de la signalisation et des médias.


La vérification du pointage est limitée aux appels connectés avec des paquets multimédias. Les appels en transit ne sont pas cochés (par exemple, un état d’essai ou de sonnerie).

Dans cet article, CUBE HD se réfère à la redondance Box-to-Box (B2B) Layer 2 de la haute disponibilité des CUBEs pour les préservation de l’appel d’État

À partir d’IOS-XE 16.12.2, CUBE HD peut être déployé en tant que passerelle locale pour les déploiements Cisco Webex Calling et nous aborderons les considérations de conception et les configurations dans cet article. Cette figure affiche une configuration typique du CUBE HD comme passerelle locale pour un déploiement Cisco Webex Calling.

Composant de groupe de redondance infra

Le composant de groupe de redondance (RG) fournit la prise en charge de l’infrastructure de communication Box-to-Box entre les deux CUBEs et négocie l’état de la redondance finale stable. Ce composant fournit également :

  • Un protocole HSRP qui négocie l’état de redondance finale pour chaque routeur en échangeant les 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 la signalisation et de l’état des médias pour chaque appel du routeur actif/de 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 (les interfaces de trafic multiples peuvent être configurées en utilisant le même groupe de groupes de routage) – les GigabitEthernet 1 et 2 sont considérées comme des interfaces de trafic.

Ce composant RG doit être spécifiquement configuré pour prendre en charge la HD VoIP.

Gestion des adresses IP virtuelles (VIP) à la fois pour la signalisation et les médias

La HD B2B repose sur l’adresse VIP pour atteindre la redondance. L’adresse VIP et les interfaces physiques associées sur les deux CUBEs de la paire de HA du CUBE doivent se trouver sur le même sous-réseau LAN. La configuration de l’adresse VIP et la liaison de l’interface VIP à une application vocale particulière (SIP) sont obligatoires pour la prise en charge de la HD Audio B2B. Les périphériques externes tels que Unified CM, Webex Calling Access SBC, fournisseur de service ou proxy, utilisent VIP comme adresse IP de destination pour les appels traversant les routeurs HD du CUBE. Par conséquent, d’un point de vue Webex Calling, les paires CUBE HD agissent en tant que passerelle locale unique.

Les informations de signalisation d’appel et de session RTP des appels établis sont repointées du routeur actif vers le routeur de secours. Lorsque le routeur actif tombe en panne, le routeur de secours prend le contrôle et continue de transférer le flux RTP qui a été précédemment routé par le premier routeur.

Les appels en état transitoire au moment du basculement ne seront pas préservés après avoir été prébasculé. Par exemple, les appels qui ne sont pas encore entièrement établis ou qui sont en cours de modification avec une fonction de transfert ou de mise en attente. Les appels établis peuvent être déconnectés après le basculement.

Les exigences suivantes existent pour l’utilisation de CUBE HD en tant que passerelle locale pour le basculement dynamique des appels :

  • Le CUBE HD ne peut pas avoir des interfaces TDM ou analogiques co-localisées

  • Gig1 et Gig2 sont appelés interfaces de trafic (SIP/RTP) et Gig3 est le contrôle/l’interface de données du groupe de redondance (RG)

  • Il n’est pas possible de placer plus de 2 paires de HD CUBE dans le même domaine de couche 2, l’un avec l’ID de groupe 1 et l’autre avec l’ID de groupe 2. Si vous configurez 2 paires de HD avec le même identifiant de groupe, les interfaces de contrôle/données RG doivent appartenir à différents domaines de couche 2 (VLAN, commutateur séparé)

  • Le canal du port est pris en charge à la fois pour les interfaces de contrôle/données et de trafic RG

  • Tous les signaux/supports sont pris en source de/vers l’adresse IP virtuelle

  • Chaque fois qu’une plateforme est rechargée dans une relation de haute disponibilité CUBE, elle démarre toujours en mode veille

  • L’adresse la plus basse pour toutes les interfaces (Gig1, Gig2, Gig3) doit être sur la même plate-forme

  • 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 CUBEs doit être identique à 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 bouclage ne peuvent pas être utilisées comme liaisons car elles sont toujours en place

  • Les interfaces de trafic multiple (SIP/RTP) (Gig1, Gig2) exigent que le suivi de l’interface soit configuré

  • Le CUBE-HD n’est pas pris en charge sur une connexion par câble de raccordement pour la liaison RG-Control/Data (Gig3)

  • Les deux plateformes doivent être identiques et être connectées via un commutateur physique pour toutes les interfaces de la HD du cube, par exemple GE0/0/0 du cube-1 et cube-2 doit se terminer sur le même commutateur et ainsi de suite.

  • Le WAN ne peut pas se terminer sur les CUBEs directement ou les données HD de chaque côté

  • Les deux actifs/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/données RG, Gig3). l’interface utilisée pour le trafic ne peut pas être utilisée pour les KeepAlive et le point de contrôle de la HD

  • Lors du basculement, le CUBE précédemment actif passe en mode de chargement par conception, préservant la signalisation et les médias

Configurer la redondance sur les deux CUBEs

Vous devez configurer la redondance de la couche 2 Box-à-Box sur les deux CUBEs destinés à être utilisés dans une paire de HD pour afficher les adresses IP virtuelles.

1

Configurez le suivi de l’interface à un niveau global pour suivre le statut de l’interface.

conf t suivi 1 interface GigabitEthernet1 ligne-protocole suivi 2 interface GigabitEthernet2 ligne-protocole sortie
VCUBE-1 # CONF
VCUBE-1 (config) #suivi 1 interface GigabitEthernet1 ligne-protocole
VCUBE-1 (config-Track) #suivi 2 interface GigabitEthernet2 ligne-protocole
VCUBE-1 (config-Track) #quitter
 
VCUBE-2 # CONF
VCUBE-2 (config) #suivi 1 interface GigabitEthernet1 ligne-protocole
VCUBE-2 (config-Track) #suivi 2 interface GigabitEthernet2 ligne-protocole
VCUBE-2 (config-Track) #quitter

La CLI de suivi est utilisée dans RG pour suivre l’état de l’interface de trafic vocal afin que l’itinéraire actif soit son rôle actif lorsque l’interface de trafic est inactive.

2

Configurez un RG pour une utilisation avec VoIP HD sous le sous-mode de redondance de l’application.

redondance d’application redondante groupe 1 nom LocalGateway-haute disponibilité 100 seuil de basculement 75 contrôle GigabitEthernet3 protocole 1 données GigabitEthernet3 timers retard 30 recharger 60 suivi 1 arrêter suivi 2 arrêt sortie protocole 1 minuteurs hellotime 3 Holdtime 10 quitter quitter sortie
VCUBE-1 (config) #redondance
VCUBE-1 (config-Red) #redondance de l’application
VCUBE-1 (config-Red-App) #groupe 1
VCUBE-1 (config-Red-GRP) #Name LocalGateway-HD
VCUBE-1 (config-rouge-application-GRP) #priority 100 seuil de basculement 75
VCUBE-1 (config-Red-GRP APP) #Control GigabitEthernet3 protocole 1
VCUBE-1 (config-rouge-application-GRP) #données GigabitEthernet3
VCUBE-1 (configuration-rouge-groupe d’applications) #minuteurs retardez 30 recharger 60
VCUBE-1 (config-Red-GRP APP) #suivi 1 arrêt
VCUBE-1 (config-Red-GRP APP) #suivi 2 arrêt
VCUBE-1 (config-Red-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 (config-rouge) #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-GRP) #Name LocalGateway-HD
VCUBE-2 (config-rouge-application-GRP) #priority 100 seuil de basculement 75
VCUBE-2 (configuration-rouge-GRP APP) #Control GigabitEthernet3 protocole 1
VCUBE-1 (config-rouge-application-GRP) #données GigabitEthernet3
VCUBE-2 (configuration-rouge-groupe d’applications) #délais retardent 30 recharger 60
VCUBE-2 (config-Red-GRP APP) #suivi 1 arrêt
VCUBE-2 (config-Red-GRP APP) #suivi 2 arrêt
VCUBE-2 (config-Red-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 (config-rouge) #quitter
VCUBE-2 (config) #

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

  • redondance— entre en mode de redondance

  • redondance de l’application — entre le mode de configuration de la redondance de l'application

  • groupe— entre le mode de configuration du groupe d’applications redondantes

  • nom LocalGateway-HD— définit le nom du groupe RG

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

  • les temporisations retardent 30 recharger 60— configure les deux heures pour retarder et recharger

    • Minuteur de délai qui est le délai de retard de l’initialisation et de la négociation du rôle du groupe de routage après l’affichage de l’interface – 30 secondes par défaut. La plage est de 0-10000 secondes

    • Recharger — il s’agit de la durée de retard de l’initialisation du groupe RG et de la négociation des rôles après un rechargement – par défaut 60 secondes. La plage est de 0-10000 secondes

    • Les temporisations par défaut sont recommandées, bien que ces timers puissent être ajustés pour prendre en charge 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 du RG soit effectuée après que le routage dans le réseau ait convergé vers un point stable. Par exemple, s’il est vu après un basculement sur incident qu’il prend jusqu’à 20 secondes pour que le nouveau mode veille voit le premier paquet RG de la part du nouveau actif, alors les timers doivent être ajustés sur « temporisation Delay 60 recharger 120 » pour un facteur de ce délai.

  • contrôler le protocole GigabitEthernet3 1— configure l’interface utilisée pour échanger les messages keepalive et Hello entre les deux cubes et spécifie l’instance de protocole qui sera jointe à une interface de contrôle et entre en mode de configuration du protocole de redondance d’application

  • données GigabitEthernet3: configure l’interface utilisée pour le contrôle du trafic des données

  • piste— suivi de groupe RG des interfaces

  • Protocole 1— spécifie l’instance de protocole qui sera jointe à une interface de contrôle et entre en mode de configuration du protocole de redondance d’application

  • timers hellotime 3 Holdtime 10– configure les deux timers pour hellotime et Holdtime :

    • Hellotime — intervalle entre les messages de salutation successifs – par défaut 3 secondes. La plage est de 250 millisecondes-254 secondes

    • Holdtime — l’intervalle entre la réception d’un message de salutation et la présomption que le routeur émetteur a échoué. Cette durée doit être supérieure à la période de salutation – par défaut de 10 secondes. La plage est de 750 millisecondes-255 secondes

      Nous vous recommandons de configurer le minuteur Holdtime pour qu’il soit au moins 3 fois la valeur du minuteur hellotime.
3

Activer la redondance Box-à-Box pour l’application CUBE. Configurez le RG à partir de l’étape précédente sous VoIP du service vocal. Ceci permet à l’application CUBE de contrôler le processus de redondance. 

service vocal redondance de la VoIP-groupe 1 sortie
VCUBE-1 (config) #VoIP du service vocal
VCUBE-1 (config-voi-serv) #redondance-groupe 1
% A créé le RG 1 associatiation avec voix B2B HD ; Rechargez le routeur pour que la nouvelle configuration prenne effet
VCUBE-1 (config-voi-serv) # quitter
 
VCUBE-2 (config) #VoIP du service vocal
VCUBE-2 (config-voi-serv) #redondance-groupe 1
% A créé le RG 1 associatiation avec voix B2B HD ; Rechargez le routeur pour que la nouvelle configuration prenne effet
VCUBE-2 (config-voi-serv) # quitter

redondance-groupe 1— Ajouter et supprimer cette commande nécessite un rechargement pour que la configuration mise à jour prenne effet. Nous allons recharger les plateformes après que toute la configuration ait été appliquée.

4

Configurez les interfaces Gig1 et Gig2 avec leurs adresses IP virtuelles respectives comme indiqué ci-dessous et appliquez l’identifiant de l’interface de redondance (RII) 

VCUBE-1 (config) #interface GigabitEthernet1
VCUBE-1 (Config-if) # redondance RII 1
VCUBE-1 (Config-if) # redondance groupe 1 198.18.1.228 IP 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) # redondance groupe 1 198.18.133.228 IP exclusif
VCUBE-1 (Config-if) # sortie
 
VCUBE-2 (config) #interface GigabitEthernet1
VCUBE-2 (Config-if) # redondance RII 1
VCUBE-2 (Config-if) # redondance groupe 1 198.18.1.228 IP 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) # redondance groupe 1 198.18.133.228 IP exclusif
VCUBE-v (Config-if) # quitter

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

  • redondance RII: configure l’identificateur de l’interface de redondance pour le groupe de redondance. Requis pour générer une adresse virtuelle MAC (VMAC). La même valeur ID RII doit être utilisée sur l’interface de chaque routeur (actif/veille) qui a le même VIP.


     

    S’il y a plus d’une paire B2B sur le même réseau local (LAN), chaque paire doit avoir des identifiants RII uniques sur leurs interfaces respectives (pour empêcher toute collision). « afficher le groupe d’applications redondantes tout » doit indiquer les informations locales et d’homologues appropriées.

  • Groupe de redondance 1— associe l’interface au groupe de redondance créé à l’étape 2 ci-dessus. Configurez le groupe RG, ainsi que l’adresse VIP attribuée à 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/les données RG

5

Enregistrez la configuration du premier CUBE et rechargez-le.

La plate-forme à recharger en dernier est toujours le secours.

VCUBE-1 #WR
Configuration du bâtiment...
CORRECT
VCUBE-1 #recharger
Continuer avec le rechargement ? confirmer

Après le démarrage complet de VCUBE-1, enregistrez la configuration de VCUBE-2 et rechargez-la. 

VCUBE-2 #WR
Configuration du bâtiment...
CORRECT
VCUBE-2 #recharger
Continuer avec le rechargement ? confirmer
6

Vérifiez que la configuration Box-à-Box fonctionne comme prévu. La sortie appropriée est en surbrillance en gras.

Nous avons rechargé VCUBE-2 Last et selon les considérations de design ; la plateforme à recharger en dernier sera toujours mise en veille. 

VCUBE-1 #afficher le groupe d’applications de redondance tous les États des erreurs groupe 1 infos : Priorité d’exécution : [100] RG Faults État du RG : Haut. Nombre total de basculements dus à des 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 sur 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 recharger les événements : 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, minuteur de mise en attente : 10000 de l’horloge Hello de l’homologue : 3000, minuteur d’attente pairée : 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. Minuteur de mise en attente : 10000 paquets 61, octets 2074, HD seq 0, Seq numéro 69, perte PKT 0 VCUBE-1 #
VCUBE-2 #afficher le groupe d’applications de redondance tous les États des erreurs groupe 1 infos : Priorité d’exécution : [100] RG Faults État du RG : Haut. Nombre total de basculements dus à des 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 sur 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 recharger les événements : 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, minuteur de mise en attente : 10000 de l’horloge Hello de l’homologue : 3000, minuteur d’attente pairée : 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. Minuteur de mise en attente : 10000 paquets 61, octets 2074, HD seq 0, Seq numéro 69, perte PKT 0 VCUBE-2 #

Configurer une passerelle locale sur les deux CUBEs

Dans notre exemple de configuration, nous utilisons les informations suivantes de Webex Control Hub pour créer 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 installation sont les suivants :

  • Nom utilisateur: Hussain1076_LGU

  • Mot de passe : lOV12MEaZx

1

Assurez-vous qu’une clé principale est pré-configurée pour le mot de passe avec les commandes indiquées ci-dessous avant qu’elle puisse être utilisée dans les identifiants ou les secrets partagés. Les mots de passe de type 6 sont chiffrés en utilisant le chiffrement AES et la clé principale définie par l’utilisateur. 

LocalGateway # conf t LocalGateway (config) #touche configuration-clé mot de passe-chiffrer Password123 LocalGateway (config) #mot de passe 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 identifiants SIP Digest de Control jub sont surlignés en gras. 

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 85.119.56.128 255.255.255.192 ipv4 85.119.57.128 255.255.255.192 ipv4 185.115.196.0 255.255.255.128 ipv4 185.115.197.0 255.255.255.128 ipv4 199.59.64.0 255.255.255.128 ipv4 199.59.65.0 255.255.255.128 ipv4 199.59.66.0 255.255.255.128 ipv4 199.59.67.0 255.255.255.128 ipv4 199.59.70.0 255.255.255.128 ipv4 199.59.71.0 255.255.255.128 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 "<sip:(.*)" "<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 codec preference 3 g729r8 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:1a01.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, en faisant de VCUBE-1 le cube de secours et VCUBE-2 le cube actif

2

À tout moment donné, une seule plateforme conservera une inscription active en tant que passerelle locale avec le Webex Calling accéder au SBC. Jetez un coup d’œil à la sortie des commandes Show suivantes.

afficher le groupe d’applications de redondance 1

afficher le statut SIP-UA-enregistrer

VCUBE-1 #afficher le groupe d’applications de redondance 1 ID du groupe : 1 nom du groupe : LocalGateway-État administratif de la HD : Aucun état opérationnel total 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 : ACTIF VCUBE-1 #afficher le statut du Registre SIP-UA VCUBE-1 #
VCUBE-2 #afficher le groupe d’applications de redondance 1 ID du groupe : 1 nom du groupe : LocalGateway-État administratif de la HD : Aucun état opérationnel total 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--------------------Registrar-index 1---------------------l’homologue de la ligne expire (sec) reg survie P-Assoc-URI = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = VCUBE = = = = = = = = = = = = = = = = Hussain5091_LGU-1 48 Oui normal de l’est...-2... #

À partir de la sortie ci-dessus, vous pouvez voir que VCUBE-2 est le LGW actif qui conserve l’inscription avec Webex Calling SBC, alors que la sortie de l’État « afficher le statut SIP-UA Register » est vide dans VCUBE-1
3

Maintenant activer les débogues suivants sur VCUBE-1

VCUBE-1 #débogage CCSIP SIP sans appel le suivi de la boite de dialogue est activé VCUBE-1 # informations sur ledébogage CCSIP le traçage des infos d’appel SIP est activé VCUBE-1 #message de débogage CCSIP
4

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

VCUBE-2 #application de redondance recharger groupe 1 Self

Le basculement du LGW actif vers le mode de veille se produit dans le scénario suivant également en plus de la CLI listée ci-dessus

  • Lors du rechargement du routeur actif
  • Lorsque le routeur actif est en mode de marche
  • Lorsqu’une interface configurée par le RG du routeur actif est arrêtée pour laquelle le suivi est activé
5

Vérifiez si VCUBE-1 s’est inscrit avec Webex Calling accès SBC. VCUBE-2 aurait maintenant été rechargée.

VCUBE-1 #afficher le statut de l’inscription SIP-UA du client : 200--------------------Registrar-index 1---------------------l’homologue de la ligne expire (sec) reg survie P-Assoc-URI = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = VCUBE = = = = = = = = = = = = = = = = Hussain5091_LGU-1 56 Oui normal de l’est... -1... #

VCUBE-1 est maintenant la LGW active.
6

Consultez le journal de débogage approprié sur VCUBE-1 en envoyant un registre SIP à Webex Calling VIA l’IP virtuelle et en recevant un 200 OK. 

VCUBE-1 # afficher le journal 19 Jan 9 18:37:24.769 : % RG_MEDIA-3-TIMEREXPIRED : L’ID RG 1 heure de salutation a expiré. 9 janvier 18:37:24.771 : % RG_PROTCOL-5-ROLECHANGE : Changement du rôle de RG ID 1 du mode veille à actif 9 18:37:24.783 : % VOICE_HA-2-SWITCHOVER_IND : BASCULement, du STANDBY_HOT à l’état actif. 9 janvier 18:37:24.783 : -1/xxxxxxxxxxxx/SIP/info/info/4096/sip_ha_notify_active_role_event : Reçu notifier le rôle actif événement Jan 9 18:37:25.758 : -1/xxxxxxxxxxxx/SIP/MSG/ccsipDisplayMsg : Envoyé : ENREGISTRER le SIP : 40462196.cisco-bcld.com :5061 SIP/2.0 via : SIP/2.0/TLS 198.18.1.228:5061 ; branche = z9hG4bK0374 à partir 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 enregistrez le contact : <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expire: 240 pris en charge : Longueur du contenu du chemin : 0
9 janvier 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 à partir 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 janvier 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 ; branche = Z9hG4bK16DC à partir 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 enregistrez 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, algorithme = MD5, NC = 00000001 Content-Length : 0
9 janvier 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 à partir 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-ID d’appel 46184 : FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 timestamp : 1578595045 CSeq : 3 enregistrez le contact : <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>; Expires = 120 ; q = 0,5 autoriser-événements : 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