Bases

Conditions requises

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.

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 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 :

  • redondance–Entre dans le mode de redondance

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

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

  • nommer la passerelle locale-HD–Définit le nom du groupe RG

  • seuil de secours de priorité 75–Spécifie la priorité initiale et les seuils de basculement d’un RG.

  • timers delay 30 reload 60–Configure les deux délais de retard et de rechargement.

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

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

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

  • Contrôle du protocole Gigabit Ethernet 3–Configure l’interface utilisée pour échanger des messages keepalive et hello entre les deux CUBE, et spécifie l’instance de protocole qui sera attachée à une interface de contrôle et saisit le mode de configuration du protocole d’application de la redondance.

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

  • suivi–Suivi des interfaces par les groupes de RG

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

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

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

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

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

3

Activez la redondance boîte à boîte pour l’application CUBE. Configurez le RG de l’étape précédente sous voice service voip. Ceci permet à l’application CUBE de contrôler le processus de redondance. 

voice service voip
   redundancy-group 1
   exit

VCUBE-1(config)#voice service voip

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


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

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

VCUBE-2(config)#voice service voip

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


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

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

redundancy-group 1–L’ajout et la suppression de cette commande nécessite un rechargement pour que la configuration mise à jour prenne effet. Nous rechargerons les plateformes après que toute la configuration ait été appliquée.

4

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

VCUBE-1(config)#interface GigabitEthernet1

VCUBE-1(config-if)# 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 :

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

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

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

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

5

Enregistrez la configuration du premier CUBE et rechargez-le.

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

VCUBE-1#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-1#reload


                        Proceed with reload? [confirm]

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

VCUBE-2#wr


                        Building configuration...
                      


                        [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:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: ACTIVE
Peer Role: STANDBY
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: Local
        Standby Peer: address 10.1.1.2, priority 100, intf Gi3
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 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:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: STANDBY
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: address 10.1.1.2, priority 100, intf Gi3
        Standby Peer: Local
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 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 Control Hub affichés ci-dessus, enregistrez et rechargez. Les informations d’identification SIP Digest de Control Hub sont mises en évidence 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 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)

afficher le statut du registre sip-ua


VCUBE-1#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: Standby
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: STANDBY HOT
         Peer RF state: 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 : Up
My Role: ACTIVE
Peer Role: STATUS
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

VCUBE-2#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          48          yes normal
VCUBE-2#

Dans le résultat ci-dessus, vous pouvez voir que VCUBE-2 est la LGC active qui maintient l’enregistrement avec le SBC d’accès à l’appel Webex, alors que le résultat de la commande « afficher le statut d’inscription sip-ua » 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 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: RG id 1 Hello Time Expired.
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:
Sent:
REGISTER 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: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent: Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595044
CSeq: 2 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expires: 240
Supported: path
Content-Length: 0


Jan 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
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: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595044
CSeq: 2 REGISTER
WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5
Content-Length: 0


Jan 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER 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: Thu, 09 Jan 2020 18:37:25 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent:Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expires: 240
Supported: path
Authorization: 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:

Received:
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-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference
Content-Length: 0