Fondamentaux

Prérequis

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

Les instructions de configuration fournies dans cet article supposent une passerelle locale dédiée sans configuration vocale existante. Si un déploiement d’entreprise CUBE existant est en cours de modification pour utiliser également la fonction de la passerelle locale pour Cisco Webex Calling, faites attention attentive à la configuration appliquée pour vous assurer que les flux d’appels et les fonctionnalités existants ne sont pas interrompus et assurez-vous d’avoir accès aux exigences de conception cube de HA.

Composants matériels et logiciels

CUBE HA comme passerelle locale nécessite IOS-XE version 16.12.2 ou ultérieure et est pris en charge sur les plateformes suivantes :

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

  • Série CSR1000—vCUBE (Configurations 1, 2 et 4 vCPU)

Les commandes et journaux d’afficher dans cet article sont basés sur une version logicielle minimum de Cisco IOS-XE 16.12.2 implémentée sur un vCUBE (CSR1000v).

Documentation de référence

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

Présentation Webex Calling la solution de groupe

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

  • Fournisseur d’accès RTCP cloud

  • Passerelle locale

Le déploiement de la passerelle locale (représentée ci-dessous) est le focus de cet article. La passerelle locale est l’option RTCP l’accès Cisco Webex Calling en fournissant une connectivité à un service RTCP client. Elle fournit également une connectivité à un déploiement IP PBX sur site, tel que Cisco Unified CM. Toutes les communications vers et depuis le cloud sont sécurisées en utilisant le transport TLS pour SIP et SRTP pour les médias.

La figure ci-dessous affiche un déploiement Webex Calling’un déploiement IP PBX existant et s’applique à un déploiement unique ou multis sites. La configuration décrite dans cet article est basée sur ce déploiement.

Redondance box à case couche 2

LA redondance box-à-box CUBE HA layer 2 utilise le protocole d’infrastructure Redondance Group (RG) pour former une paire active/en veille de routeurs. Ce pair partage la même adresse IP virtuelle (VIP) sur leurs interfaces respectives et échange continuellement des messages de statut. Les informations de la session CUBE sont cocher sur les deux routeurs, ce qui permet au routeur de veille d’prendre toutes les responsabilités de traitement des appels CUBE immédiatement si le routeur actif est hors service, ce qui entraîne la préservation publique de la signalisation et du support.

Le point de contrôle se limite aux appels connectés avec des paquets média. Les appels en transit ne sont pas pointés en cours de vérification (par exemple, l’état de tentative ou de sonnerie).

Dans cet article, CUBE HA se référera à la redondance CUBE Haute disponibilité (HA) Layer 2 Box-to-box (B2B) pour les conditions préservation de l’appel

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

Composant Infra du groupe de redondance

Le composant Infra (Redundancy Group)Infra (Groupe de redondance) fournit la prise en charge de l’infrastructure de communication box-to-box entre les deux CUBE et négocie l’état définitif stable de redondance. Ce composant fournit également :

  • Un protocole HSRP comme HSRP qui négociera l’état de redondance finale de chaque routeur en échangeant des messages keepalive et bonjour entre les deux CUBE (via l’interface de contrôle)—GigabitEthernet3 dans la figure ci-dessus.

  • Un mécanisme de transport pour le contrôle de l’état de signalisation et de média pour chaque appel du routeur actif au veille (via l’interface de données)—GigabitEthernet3 dans la figure ci-dessus.

  • Configuration et gestion de l’interface IP virtuelle (VIP) pour les interfaces de trafic (plusieurs interfaces de trafic peuvent être configurées en utilisant le même groupe RG) – GigabitEthernet 1 et 2 sont considérées comme des interfaces de trafic.

Ce composant RG doit être spécifiquement configuré pour la prise en charge de la voix B2B HA.

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

B2B HA se base sur l’VIP pour atteindre la redondance. L’vip et les interfaces physiques associées sur les deux CUBE du pair CUBE HA doivent résider sur le même sous-réseau LAN. La configuration de l’interface VIP et de liaison de l’interface VIP à une application vocale particulière (SIP) sont obligatoires pour la prise en charge de la voix B2B HA. Les périphériques externes tels qu’Unified CM, Webex Calling accèdent à SBC, le fournisseur de service, ou le proxy, utilisent l’adresse VIP comme adresse IP de destination pour les appels qui traversent les routeurs CUBE de HA. Par conséquent, à partir Webex Calling point de vue, les paires CUBE HA agit comme une passerelle locale unique.

Les informations de signalisation des appels et de la session RTP des appels établis sont sur point de contrôle du routeur actif vers le routeur de veille. Lorsque le routeur actif est en panne, le routeur veille prend le contrôle et continue de faire suivre le flux RTP qui a été précédemment acheminé par le premier routeur.

Les appels en état de transition au moment du basculement ne seront pas conservés après le basculement. Par exemple, les appels qui ne sont pas encore complètement établis ou qui sont en cours de modification avec une fonction de transfert ou de mise en attente. Les appels qui ont été mis en place peuvent être déconnectés après le basculement.

Les exigences suivantes existent pour l’utilisation de CUBE HA comme passerelle locale pour leover (panne d’appel) stateful :

  • CUBE HA ne peut pas avoir de CTDM ou d’interfaces analogiques co-situées

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

  • Pas plus de 2 paires CUBE HA peuvent être placées dans le même domaine de la couche 2, un avec l’id de groupe 1 et l’autre avec l’id de groupe 2. Si vous configurez 2 pairs AVEC le même id de groupe, les interfaces de contrôle/données RG doivent appartenir à différents domaines de la couche 2 (vlan, commutateur séparé)

  • La chaine du port est prise en charge à la fois pour le contrôle/données RG et les interfaces de trafic

  • Tous les médias/signalisations sont provenant/vers l’adresse IP virtuelle

  • Chaque fois qu’une plateforme est rechargée dans une relation CUBE-HA, elle démarre toujours en tant que Veille

  • Adresse inférieure pour toutes les interfaces (Gig1, Gig2, Gig3) doit être sur la même plateforme

  • Identificateur de l’interface de redondance, rii doit être unique à une combinaison pair/interface sur la même couche 2

  • La configuration sur les deux CUBE doit être identique incluant la configuration physique et doit être en cours d’exécution sur le même type de plateforme et la version IOS-XE

  • Les interfaces de rappel ne peuvent pas être utilisées comme lier car elles sont toujours au courant

  • Plusieurs interfaces de trafic (SIP/RTP) (Gig1, Gig2) nécessitent que le suivi de l’interface soit configuré

  • CUBE-HA n’est pas pris en charge par une connexion par câble cable pour le lien RG-control/data (Gig3)

  • Les deux plateformes doivent être identiques et être connectées via un Commutateur physique sur toutes les interfaces également pour que CUBE HA fonctionne, par exemple CUBE0/0/0 de CUBE-1 et CUBE-2 doivent se terminer sur le même commutateur et ainsi de suite.

  • Impossible d’avoir WAN résilié sur les CUBE directement ou la HA de données sur l’un ou l’autre côté

  • Les deux centres de données Actif/Veille doivent être dans le même centre de données

  • Il est obligatoire d’utiliser l’interface L3 séparée pour la redondance (Contrôle RG/données, Gig3). par ex. l’interface utilisée pour le trafic ne peut pas être utilisée pour les keepalives ha et le point de contrôle

  • Lors du cas de panne, le CUBE précédemment actif passe par un rechargement par la conception, préserver la signalisation et le média

Configurer la redondance sur les deux CUBE

Vous devez configurer la redondance box-à-box couche 2 sur les deux CUBE conçus pour être utilisés dans un pair HA pour réunir les IP virtuels.

1

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

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

VCUBE-1#conf t
VCUBE-1(config)#interface 1 interface GigabitEthernet1 ligne-protocol
VCUBE-1(config-track)#track 2 interface GigabitEthernet2 ligne-protocol
VCUBE-1(config-track)#quitter
 
VCUBE-2#conf t
VCUBE-2(config)#interface 1 interface GigabitEthernet1 ligne-protocol
VCUBE-2(config-track)#track 2 interface GigabitEthernet2 ligne-protocol
VCUBE-2(config-track)#quitter

Track CLI est utilisé dans RG pour suivre l’état de l’interface de trafic vocal afin que le routeur actif reste son rôle actif lorsque l’interface de trafic est à l’état actif.
2

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

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

VCUBE-1(config)#redondance
VCUBE-1(config-rouge)#redondance de l’application
VCUBE-1(config-red-app)#groupe 1
VCUBE-1(config-red-app-grp)#nom LocalGateway-HA
VCUBE-1(config-red-app-grp)# priorité 100 seuil de panne75
VCUBE-1(config-red-app-grp)#contrôle GigabitEthernet3 protocole 1
VCUBE-1(config-red-app-grp)#données GigabitEthernet3
VCUBE-1(config-red-app-grp)# délais de30 rechargement 60
VCUBE-1(config-red-app-grp)#suivi 1 arrêt
VCUBE-1(config-red-app-grp)#suivi 2 arrêt
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(config-red)#quitter
VCUBE-1 (config) #
 
VCUBE-2(config)#redondance
VCUBE-2(config-rouge)#redondance de l’application
VCUBE-2(config-red-app)#groupe 1
VCUBE-2(config-red-app-grp)#nom LocalGateway-HA
VCUBE-2(config-red-app-grp)#priorité 100 seuil de panne 75
VCUBE-2(config-red-app-grp)#contrôle GigabitEthernet3 protocole 1
VCUBE-1(config-red-app-grp)#données GigabitEthernet3
VCUBE-2(config-red-app-grp)# délais de30 rechargement 60
VCUBE-2(config-red-app-grp)#suivi 1 arrêt
VCUBE-2(config-red-app-grp)#suivi 2 arrêt
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(config-red)#quitter
VCUBE-2 (config) #

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

  • redondance—Entre le mode de redondance

  • redondance del’application —Entre le mode de configuration de redondance de l’application

  • groupe—Entre en mode de configuration de la redondance du groupe d’applications

  • Nom LocalGateway-HA—Définit le nom du groupe RG

  • priorité 100 seuil de panne 75 —Indique la priorité initiale et les seuils de pannepour un RG

  • retard des timers 30 recharger 60 —Configure les deux fois pour le délaiet le rechargement

    • Minuteur de délai qui est la durée du délai d’initialisation du groupe RG et de la négociation du rôle lorsque l’interface arrive – Par défaut 30 secondes. La plage est de 0-10000 secondes

    • Recharger—Ceci est la durée de délai d’initialisation et de négociation du rôle du groupe RG après un rechargement – Par défaut 60 secondes. La plage est de 0-10000 secondes

    • Les timers par défaut sont recommandés, bien que ces délais soient ajustés pour s’adapter au retard supplémentaire de convergence du réseau qui peut se produire au cours du démarrage/rechargement des routeurs, pour garantir que la négociation du protocole RG s’est déroulée après le routage dans le réseau a convergé vers un point stable. Par exemple, s’il est vu après une panne qu’il faut jusqu’à 20 sec pour le nouveau VEILLE pour voir le premier paquet RG HELLO du nouveau paquet ACTIF, alors les minutes doivent être ajustées sur « retard de 60 secondes du chargement 120 » pour tenir compte de ce délai.

  • contrôle GigabitEthernet3 protocole 1 —Configure l’interface utilisée pour échanger les messages keepalive et bonjour entre les deux CUBEE, et spécifie l’instance de protocole qui sera attachée à une interface de contrôle et entre le mode de configuration du protocole de redondancede l’application

  • données GigabitEthernet3 —Configure l’interface utilisée pour le point de contrôledu trafic de données

  • suivi—Suivi des interfaces des groupes RG

  • protocole 1 — Spécifie l’instance de protocole qui sera attachée à une interface de contrôle et entre en mode de configuration du protocole deredondance de l’application

  • timers hellotime 3 holdtime 10 —Configure les deux temps d’attente pourhellotime et holdtime :

    • Bonjour—Intervalle entre les messages bonjour successifs – Par défaut 3 secondes. La plage est de 250 millisecondes-254 secondes

    • Attente—L’intervalle entre la réception d’un message Bonjour et l’invité de l’échec du routeur d’envoi. Cette durée doit être supérieure au bonjour-temps – Par défaut 10 secondes. La plage est de 750 millisecondes-255 secondes

      Nous vous recommandons de configurer le temps d’attente pour qu’il soit au moins trois fois la valeur du bonjour.
3

Activer la redondance box-à-box pour l’application CUBE. Configurez le RG de l’étape précédente sous voip (Voix sur IP) du servicevocal. Ceci permet à l’application CUBE de contrôler le processus de redondance.

service vocal voip 
   redondance-groupe 1 
   sortie
VCUBE-1(config)#voix sur IP
VCUBE-1(config-voi-serv)#redondance-groupe 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)# quitter
 
VCUBE-2(config)#voix sur IP
VCUBE-2(config-voi-serv)#redondance-groupe 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)# quitter

redondance-groupe 1 —Ajouter et supprimer cette commande nécessite un rechargement pour que laconfiguration mise à jour prenne effet. Nous rechargerons les plateformes lorsque toutes les configurations auront été appliquées.
4

Configurez les interfaces Gig1 et Gig2 avec leurs IP virtuelles respectives comme démontré ci-dessous et appliquez l’identificateur de l’interface de redondance(rii)

VCUBE-1(config)#interface GigabitEthernet1
VCUBE-1(config-if)# redondance rii 1
VCUBE-1(config-if)# redondance groupe 1 ip 198.18.1.228 exclusif
VCUBE-1(config-if)# quitter
VCUBE-1 (config) #
VCUBE-1(config)#interface GigabitEthernet2
VCUBE-1(config-if)# redondance rii 2
VCUBE-1(config-if)# redondance groupe 1 ip 198.18.133.228 exclusif
VCUBE-1(config-if)# quitter
 
VCUBE-2(config)#interface GigabitEthernet1
VCUBE-2(config-if)# redondance rii 1
VCUBE-2(config-if)# redondance groupe 1 ip 198.18.1.228 exclusif
VCUBE-2(config-if)# quitter
VCUBE-2 (config) #
VCUBE-2(config)#interface GigabitEthernet2
VCUBE-2(config-if)# redondance rii 2
VCUBE-2(config-if)# redondance groupe 1 ip 198.18.133.228 exclusif
VCUBE-v(config-if)# quitter

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

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


     

    S’il y a plus d’un pair B2B sur le même LAN, chaque pair DOIT avoir des ID rii uniques sur leurs interfaces respectives (pour empêcher toute situation de problèmes). « afficher tous les groupes d’applications de redondance » doit indiquer les informations locales et pairs correctes.

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

Enregistrez la configuration du premier CUBE et rechargez-le.

La plateforme pour recharger le dernier est toujours le veille.

VCUBE-1#wr

  Configuration du bâtiment...


  [OK]

Rechargez VCUBE-1#

  Continuer le 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]

Rechargez VCUBE-2#

  Continuer le rechargement ? [confirmer]
6

Vérifiez que la configuration de la case à case fonctionne comme prévu. Les résultats pertinents sont mis en gras.

Nous avons rechargé VCUBE-2 dernier et selon les considérations de conception ; la plateforme pour recharger le dernier sera toujours en veille .


VCUBE-1#afficher le groupe d’applications de redondance tous les défauts états Groupe 1 infos :
       Priorité de l’runtime : [100] 
               Défauts RG État de RG : En haut.
                       Nombre total de basculements en raison de pannes :           0 
                       Total # de modifications d’état en raison de pannes : 0 Nom du groupe ID :1 
 :LocalGateway-HA    État administratif : Aucun état 
 d’arrêt agrégé opérationnel : Up My Role (Mon rôle) : Rôle 
 actif du pair : Présence du pair EN VEILLE : OuiComm. du pair : Oui 
 La progression du pair a démarré : Oui 
 
 Domaine RF : btob-one 
         RF état : État RF 
         du pair ACTIF : VEILLE HOT 
 
 RG Protocol RG 1 
 ------------------ rôle 
 : Négociation 
        active : Priorité 
        activée : État du protocole 100 
        : État 
        actif des Intf(s) Ctrl : Peer 
        actif actif : Pair         de veille local : adresse 10.1.1.2, priorité 100, compteurs des journaux Intf Gi3         :
                changement de rôle par actif : 1 
                rôle change en veille : 1 
                désactiver les événements : rg down state 0, rg shut 0 
                ctrl événements intf : up 1, down 0, admin_down 0 
                recharger les événements : demande locale 0, demande de pair 0 Contexte média RG pour le 
 
 RG 1 
 -------------------------- 
 l’État Ctx : ID du protocole actif : 1 
        type de média : Interface         de contrôle par défaut : GigabitEthernet3         Heure actuelle de bonjour : 3000 
        Paramétrateur Bonjour : 3000, Durée d’attente : 10000 Heure 
        de bonjour aux pairs : 3000, Temps d’attente du pair : Stats 10000 
        :
            Pkts 1509, Octets 93558, HA Seq 0, Numéro deq 1509, Perte de Pkt 0 0 Authentification non configurée Échec d’authentification 
 
            : 0 
            Recharger le pair : TX 0, RX 0 Renoncer 
            : Pair stand TX 0, RX 0 
    : Présent. Délai d’attente : 10000 
 Pkts 61, Octets 2074, HA Séq 0, Numéro deq 69, Pkt Perte 0 
 
 VCUBE-1 #

VCUBE-2#afficher le groupe d’applications de redondance tous les défauts états Groupe 1 infos :
       Priorité de l’runtime : [100] 
               Défauts RG État de RG : En haut.
                       Nombre total de basculements en raison de pannes :           0 
                       Total # de modifications d’état en raison de pannes : 0 Nom du groupe ID :1 
 :LocalGateway-HA    État administratif : Aucun état 
 d’arrêt agrégé opérationnel : Up My Role (Mon rôle) : Rôle du 
 pair DE VEILLE : Présence active du pair : OuiComm. du pair : Oui 
 La progression du pair a démarré : Oui 
 
 Domaine RF : btob-one 
         RF état : État RF 
         du pair ACTIF : VEILLE HOT 
 
 RG Protocol RG 1 
 ------------------ rôle 
 : Négociation 
        active : Priorité 
        activée : État du protocole 100 
        : État 
        actif des Intf(s) Ctrl : Peer         actif actif : adresse 10.1.1.2, priorité 100, pair de veille intf Gi3         : Compteurs 
        de journaux locaux :
                changement de rôle par actif : 1 
                rôle change en veille : 1 
                désactiver les événements : rg down state 0, rg shut 0 
                ctrl événements intf : up 1, down 0, admin_down 0 
                recharger les événements : demande locale 0, demande de pair 0 Contexte média RG pour le 
 
 RG 1 
 -------------------------- 
 l’État Ctx : ID du protocole actif : 1 
        type de média : Interface         de contrôle par défaut : GigabitEthernet3         Heure actuelle de bonjour : 3000 
        Paramétrateur Bonjour : 3000, Durée d’attente : 10000 Heure 
        de bonjour aux pairs : 3000, Temps d’attente du pair : Stats 10000 
        :
            Pkts 1509, Octets 93558, HA Seq 0, Numéro deq 1509, Perte de Pkt 0 0 Authentification non configurée Échec d’authentification 
 
            : 0 
            Recharger le pair : TX 0, RX 0 Renoncer 
            : Pair stand TX 0, RX 0 
    : 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 CUBE

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

  • Nom d’utilisateur : Hussain1076_LGU

  • Mot de passe : lOVA12MEaZx

1

Assurez-vous qu’une clé de configuration est créée pour le mot de passe, avec les commandes affichées ci-dessous, avant qu’elle puisse être utilisée dans les identifiants ou les partages. Le type 6 mots de passe sont chiffrés à l’aide du chiffrement AES et cette clé de configuration définie par l’utilisateur.


LocalGateway#conf t 
 LocalGateway(config)# cléconfig-key password-encrypt Password123 LocalGateway(config)# accès au cryptage du motde passe

Voici la configuration de la passerelle locale qui s’appliquera aux deux plateformes en fonction des paramètres control Hub affichés ci-dessus, d’enregistrer et de recharger. Les identifiants SIP Digest de Control Hub sont mis en surbrillons engras.


configurer la révocation 
 dpccur trustpoint cryptographique 
 pki-check crl 
 exit 
 sip-cryptograph 
 crypto signaling default trustpoint d facticeTp cn-san-validate server transport tcp tls v1.2 fin configure terminal crypto pki trust url clean end configure terminal voice service voip ip address trusted list ipv4 x.x y.y .y.y quitter autoriser les connexions sip aux statistiques sip média statistiques média en nombre-stats aucun supplémentaire-service sip ne reporte pas de gestion sip supplémentaire service remplace le protocole fax passer par http://www.cisco.com/security/pki/trs/ios_core.p7b g711ulaw 
 
 stun flowdata agent-id 1 boot-count 4 
 stun flowdata partagé-secret 0 
 Mot de passe123 !  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=""></sip:\1"><sips:(.*)" "<sip:\1" rule="" 12="" request="" ANY="" sip-header="" Contact="" modify=""></sip:\1"><sips:(.*)>rule<sip:\1;transport=tls>13 response ANY sip-header to modify<sips:(.*)" "<sip:\1" rule="" 14="" response="" ANY="" sip-header="" From="" modify=""></sip:\1"><sips:(.*)" "<sip:\1" rule="" 15="" response="" ANY="" sip-header="" Contact="" modify=""></sip:\1"><sips:(.*)"
"<sip:\1" rule="" 20="" request="" ANY="" sip-header="" From="" modify="">"
";otg=<sajan index="1" />hussain1076_lgu<sajan index="2" />>"
  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 <sajan index="3" />" 
 « ;otg= hussain1076_lgu > » règle30 requête 
 SIP-en-tête P-Asserted-Identity modifier 
 « sips:(.*) » « sip:\1 » 
 
 
 codec 99 
 codec préférences 1 g711ulaw codec préférences 2 g711ulaw quitter la classe vocale 
 
 
 
 srtp-crypto 200 crypto 1 AES_CM_128_HMAC_SHA1_80 sortie classe vocale stun-usage 200 stun utilisation pare-feu-traversée flux données quitter voix classe 
 
 
 
 
 tenant 
 
 
 
 
 
 
 
 200 inscription dns:40462196.cisco-bcld.com scheme sips expire 240 refresh-ratio 50 tcp tcp tls numéro Hussain5091_LGU username Hussain1076_LGU mot de passe 0 lIELLE12MEaZx realm Broadworks authentification Hussain5091_LGU mot de passe      0 lIELLE12MEaZx realm BroadWorks authentification username Hussain5091_LGU mot de passe   0 l URL12MEaZx realm 40462196.cisco-bcld.com pas de connexion     sip-id sip-server dns:40462196.cisco-bcld.com   connection-reuse srtp-crypto 200 
 session transport tcp tls 
 url sips 
 error-passthrued-id 
 bind control 
 source-interface GigabitEthernet1 
 bind media source-interface GigabitEthernet1 aucun contenu 
 personnalisé-sdp profils 
 sip 200 
 proxy sortants dns:la01.sipconnect-us10.cisco-bcld.com classe vocale passthru de politique de confidentialité   tenant 
 
 
 100 session transport url 
 udp 
 sip 
 error-passthru 
 lier source-interface GigabitEthernet2 média lier 
 source-interface média GigabitEthernet2 aucune passer-à contenu personnalisé classe vocale 
 client 
 
 300 
 lier control source-interface GigabitEthernet2 lie media source-interface GigabitEthernet2 aucun contenu passer-à du contenu personnalisé classe vocale 
 
 
 
 
 uri 100 sip organisateur 
 ipv4:198.18.13 3.3 classe vocale 
 
 uri 200 sip 
 pattern dtg=hussain1076.lgu    dial-peer voice 101 voip 
 description sortante dial-peer to IP RTCP 
 destination pattern BAD. MAUVAIS protocole 
 de session sipv2 
 cible session ipv4:198.18.133.3 codec de la classe vocale 
 99 
 voix sip tenant 100 
 dtmf-relay rtp-nte 
 no vad 
 
 dial-peer voice 201 description voip Sortant 
 
 de composition du pair vers Webex Calling destination-schéma MAUVAIS. PROTOCOLE DE SESSION MAUVAIS protocole sipv2 session cible sip-serveur codec de la classe vocale 
 
 
 99 
 voix stun-usage 200 aucune 
 voix-classe sip localhost 
 voix-classe sip tenant sip 200 
 dtmf-relay rtp-nte srtp non vad voix classe 
 
 
 
 
 dpg 100 
 description entrante Appel Webex (DP200) à IP RTCP(DP101) 
 dial-peer 101 préférence 1 classe vocale 
 
 dpg 200 
 description IP entrante RTCP(DP100) vers Webex Calling(DP201) 
 dial-peer 201 préférence 1 
 
 
 
 
 
 dial-peer voice 10 0 voip desription Entrante dial-peer à partir du protocole 
 de session RTCP IP protocole 
 sipv2 
 destination dpg 200 uri entrant via 100 codec de la classe vocale 
 99 voix sip tenant sip 300 dtmf-relay rtp-nte aucune description de la voix voIP de 200 numéros de téléphone Appel-peer entrant du protocole Webex Calling session sipv2 destinat

Pour afficher la sortie de commande, nous avons rechargé VCUBE-2 suivi par VCUBE-1 , qui fait deVCUBE-1 le standby CUBE et VCUBE-2 le CUBE actif
2

À tout moment donné, une seule plate-forme conservera un enregistrement actif en tant que passerelle locale avec accès Webex Calling SBC. Jetez un coup d’œil à la sortie des commandes d’afficher suivantes.

afficher le groupe d’applications de redondance 1

afficher le statut sip-ua-register


VCUBE-1# afficher l’état administratif du groupe d’applications de redondance 1 Groupe ID :1 Nom du groupe :LocalGateway-HA 
 
 État administratif : Aucun état 
 d’arrêt agrégé opérationnel : Up My Role : Rôle du pair de veille : Présence 
 active du pair : OuiComm. du pair : Oui 
 La progression du pair a démarré : Oui 
 
 Domaine RF : btob-one 
         RF état : STANDBY HOT 
         Peer RF état : ACTIVE 
 
 VCUBE-1#afficher sip-enregistré statut VCUBE-1 #

VCUBE-2# afficher l’état administratif du groupe d’applications de redondance 1 Groupe ID :1 Nom du groupe :LocalGateway-HA 
 
 État administratif : Aucun état 
 d’arrêt agrégé opérationnel : Up My Role : Rôle actif du pair : Statut 
 de présence du pair : OuiComm. du pair : Oui 
 La progression du pair a démarré : Oui 
 
 Domaine RF : btob-one 
         RF état : État RF 
         du pair ACTIF : STANDBY HOT 
 
 VCUBE-2#afficher sip-register statut  Tenant : 200 
 --------------------Registrar-Index 1 --------------------- Line peer 
 expire(sec) reg reg P-Associ-URI 
 == === 
 =Hussain5091_LGU 1 48 oui 
 vcUBE-2 #

À partir de la sortie ci-dessus, vous pouvez voir que VCUBE-2 est le LGW actif conservant l’enregistrement avec accès Webex Calling SBC, alors que la sortie du « afficher le statut d’inscription sip-register » est vide dans VCUBE-1
3

Activez maintenant les débogages suivants sur VCUBE-1


VCUBE-1#debug ccsip non-call SIP Out-of-Dialog est traçage est activé VCUBE-1# debug ccsip infos SIP Appel traçage est activé VCUBE-1#message ccsip de débogage
4

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


VCUBE-2#application de redondance recharger le groupe 1 auto

Le basculement de L’ACTIF vers le LGW STANDBY se produit dans le scénario suivant ainsi que le CLI listé ci-dessus

  • Lorsque le routeur ACTIF se recharge

  • Lorsque les cycles de puissance du routeur ACTIF

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

Vérifiez si VCUBE-1 s’est inscrit avec Webex Calling SBC d’accès. VCUBE-2 se se serait chargé jusqu’à présent.


VCUBE-1#afficher sip-système d’enregistrement 
 
 Tenant : 200 
 --------------------Registrar-Index 1 --------------------- Line peer 
 expire(sec) reg reg P-Associ-URI 
 === === =Hussain5091_LGU 1 56 = 1 56 oui VCUBE-1 #

VCUBE-1 est maintenant le LGW actif.
6

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


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 : RG id 1 rôle change de veille à Actif 
 9 Janvier 18:37:24.783 : %VOICE_HA-2-SWITCHOVER_IND : BASCULEMENT, du STANDBY_HOT au mode ACTIF.
9 janvier 18:37:24.783 : -1/xxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event : Réception d’une notification sur 
 
 l’événement à rôle actif 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 
 à partir de : <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 
 Pour : <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Date : Jeu 09 jan 2020 18:37:24 GMT 
 Appel-ID : FFFFFFFFEA0684EF-324511EA-FFFFFF800281CD-FFFFFFB5F93B97 
 Agent utilisateur : Cisco-SIPGateway/IOS-16.12.02 
 Max-Forwards : 70 
 timestamp: 1578595044 
 CSeq : 2 Contact 
 S’INSCRIRE : <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expire: 240 Pris 
 en charge : chemin 
 Longueur du contenu : 0

9 janvier 18:37:25.995 : -1/00000000000/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 
 Pour : <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 
 Date : Jeu 09 jan 2020 18:37:24 GMT 
 Appel-ID : FFFFFFFFEA0684EF-324511EA-FFFFFF800281CD-FFFFFFB5F93B97 
 Timestamp : 1578595044 
 CSeq : 2 
 S’INSCRIRE À WWW-Authentifier ; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5 
 Content-Length: 0

9 janvier 18:37:26.000 : -1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg :
Envoyé :
ENREGISTREZ sip:40462196.cisco-bcld.com:5061 SIP/2.0 Via : SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC 
 À partir de : <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 
 Pour : <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Date : Jeu 9 jan 2020 18:37:25 GMT 
 Appel-ID : FFFFFFFFEA0684EF-324511EA-FFFFFF800281CD-FFFFFFF5F93B97 
 Utilisateur-Agent :Cisco-SIPGateway/IOS-16.12.02 
 Max-Forwards : 70 
 timestamp: 1578595045 
 CSeq : 3 Contact 
 S’INSCRIRE : <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=0000001 
 Content-Length: 0

9 janvier 18:37:26.190 : 1/00000000000/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 
 Pour : <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 
 ID d’appel : FFFFFFFFEA0684EF-324511EA-FFFFFF800281CD-FFFFFFB5F93B97 
 Timestamp : 1578595045 
 CSeq : 3 Contact 
 S’INSCRIRE : <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 
 Autoriser les événements : appeler-infos,ligne-saisir,dialogue,message-résumé,en tant qu'-fonctionnalité-événement,x-broadworks-hoteling,x-broadworks-call-center-status,contenu de la 
 conférence-Longueur : 0