Dans cet article
Principes fondamentaux
Configurer la redondance sur les deux CUBE
10 octobre 2026 | 2848 vue(s) | 1 personnes ont trouvé ceci utile
Mettre en œuvre la haute disponibilité de CUBE en tant que passerelle locale
list-menuDans cet article
list-menuUn commentaire ?

Local Gateway (LGW) est la solution exclusive qui permet de fournir un accès PSTN sur site aux clients Cisco Webex Calling. Ce document vous explique comment configurer une passerelle locale à l'aide de la haute disponibilité de CUBE, avec des CUBE actifs ou en veille pour garantir un basculement automatique des appels actifs.

Principes fondamentaux

Prérequis

Avant de déployer Cisco Unified Border Element (CUBE) High Availability (HA) en tant que passerelle locale pourWebex Calling, assurez-vous de bien comprendre les concepts suivants :

Les instructions de configuration fournies dans cet article supposent qu'il s'agit d'une plateforme de passerelle locale dédiée sans configuration vocale existante. Si un déploiement d'entreprise CUBE existant est modifié pour utiliser également la fonction de passerelle localeCisco Webex Calling, portez une attention particulière à la configuration appliquée afin de ne pas interrompre les flux d'appels et les fonctionnalités existants et assurez-vous de respecter les exigences de conception de CUBE HA.

Composants matériels et logiciels

CUBE HA en tant que passerelle locale nécessite la version 17.9.1 ou ultérieure d'IOS-XE et une plateforme prenant en charge les fonctions CUBE HA et LGW.

Les commandes d'affichage et les journaux de cet article sont basés sur la version logicielle minimale de Cisco IOS -XE 17.9.1 implémentée sur un vCube (CSR 8000v).

Matériel de référence

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

Webex CallingPrésentation de la solution

Cisco Webex Callingest une offre de collaboration qui propose une alternative cloud mutualisée au service téléphonique PBX sur site avec de multiples options PSTN pour les clients.

Le déploiement de Local Gateway (représenté ci-dessous) est au cœur de cet article. Le trunk in de la passerelle locale (PSTN basé sur les locaux) Webex Calling permet de se connecter à un service PSTN appartenant au client. Il fournit également la connectivité à un déploiement de PBX IP sur site, tel que. Cisco Unified CM Toutes les communications depuis et vers le cloud sont sécurisées à l'aide du transport TLS pour le SIP et du SRTP pour les médias.

Local Gateway premises-based PSTN deployment

La figure ci-dessous montre un Webex Calling déploiement sans aucun PBX IP existant et s'applique à un déploiement sur un seul site ou sur plusieurs sites. La configuration décrite dans cet article est basée sur ce déploiement.

Webex Calling deployment without IP PBX

Redondance boîte-à-boîte de couche 2

La redondance boîte-à-boîtier de couche 2 du CUBE HA utilise le protocole d'infrastructure Redundancy Group (RG) pour former une paire de routeurs actif/veille. Ces deux personnes partagent la même adresse IP virtuelle (VIP) sur leurs interfaces respectives et échangent des messages de statut en permanence. Les informations de session CUBE sont contrôlées sur les deux routeurs, ce qui permet au routeur de secours de prendre immédiatement en charge toutes les responsabilités liées au traitement des appels CUBE en cas de panne du routeur actif, ce qui permet de préserver l'état de la signalisation et des médias.

Le point de contrôle est limité aux appels connectés via des paquets multimédia. Les appels en transit ne sont pas contrôlés (par exemple, en cas d'essai ou de sonnerie).

Dans cet article, CUBE HA fera référence à la redondance boîte-à-boîte (B2B) de couche 2 CUBE High Availability (HA) pour la préservation des appels.

À partir d'IOS-XE 17.9.1, CUBE HA peut être déployé en tant que passerelle locale pour les déploiements de lignes principales (Cisco Webex Calling PSTN sur site). Cet article abordera les considérations relatives à la conception et aux configurations. La figure montre une configuration typique de CUBE HA en tant que passerelle locale pour Cisco Webex Calling le déploiement d'un trunk.

A typical CUBE HA setup as Local Gateway for a Cisco Webex Calling trunk deployment

Composant infrarouge du groupe de redondance

Le composant Redundancy Group (RG) Infra fournit le support d'infrastructure de communication boîtier à boîtier entre les deux CUBE 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 de chaque routeur en échangeant des messages keepalive et hello entre les deux CUBE (via l'interface de contrôle). GigabitEthernet3 dans la figure ci-dessus.

  • Un mécanisme de transport permettant de vérifier la signalisation et l'état du média pour chaque appel entre le routeur actif et le routeur de secours (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 à l'aide du même groupe RG) — Les 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 VIP pour assurer la redondance. Le VIP et les interfaces physiques associées des deux CUBE de la paire CUBE HA doivent se trouver 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 le support vocal B2B HA. Les appareils externes tels que Unified CM Webex Calling l'accès SBC, le fournisseur de services ou le proxy utilisent VIP comme adresse IP de destination pour les appels passant par les routeurs CUBE HA. Ainsi, d'un Webex Calling point de vue, les paires CUBE HA agissent comme une passerelle locale unique.

La signalisation des appels et les informations de session RTP des appels établis sont contrôlées entre le routeur actif et le routeur de secours. Lorsque le routeur actif tombe en panne, le routeur de secours prend le relais et continue de transmettre le flux RTP qui était précédemment acheminé par le premier routeur.

Les appels en état transitoire au moment du basculement ne seront pas conservés après le basculement. Par exemple, des appels qui ne sont pas encore complètement établis ou qui sont en cours de modification grâce à une fonction de transfert ou de mise en attente. Les appels établis peuvent être déconnectés après le basculement.

Les conditions suivantes sont requises pour utiliser CUBE HA comme passerelle locale pour le basculement automatique des appels :

  • CUBE HA ne peut pas avoir d'interfaces TDM ou analogiques colocalisées

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

  • Il n'est pas possible de placer plus de 2 paires CUBE HA dans le même domaine de couche 2, l'une avec l'identifiant de groupe 1 et l'autre avec l'identifiant de groupe 2. Si vous configurez 2 paires HA avec le même identifiant de groupe, les interfaces RG Control/Data doivent appartenir à des domaines de couche 2 différents (VLAN, commutateur séparé)

  • Le canal de port est pris en charge à la fois pour les interfaces RG Control/Data et Traffic

  • Toutes les signalisations et tous les supports proviennent depuis/vers l'adresse IP virtuelle

  • Chaque fois qu'une plateforme est rechargée dans le cadre d'une relation CUBE-HA, elle démarre toujours en mode veille

  • L'adresse inférieure pour toutes les interfaces (Gig1, Gig2, Gig3) devrait se trouver sur la même plateforme

  • Identifiant d'interface de redondance, rii doit être propre à une combinaison paire/interface sur la même couche 2

  • La configuration des deux CUBE doit être identique, y compris la configuration physique, et doit fonctionner sur le même type de plateforme et sur la même version IOS-XE

  • Les interfaces Loopback ne peuvent pas être utilisées comme liaison car elles sont toujours actives

  • Plusieurs interfaces de trafic (SIP/RTP) (Gig1, Gig2) nécessitent la configuration du suivi des interfaces

  • CUBE-HA n'est pas pris en charge par un câble croisé pour la liaison RG-Control/Data (Gig3)

  • Les deux plateformes doivent être identiques et connectées via un switch physique à toutes les interfaces similaires pour que CUBE HA fonctionne, c'est-à-dire Les GE0/0/0 de CUBE-1 et CUBE-2 doivent se terminer sur le même switch et ainsi de suite.

  • Impossible de connecter le WAN directement aux CUBES ou à Data HA de chaque côté

  • Active/Standby doivent se trouver dans le même centre de données

  • Il est obligatoire d'utiliser une interface L3 distincte pour des raisons de redondance (RG Control/Data, Gig3). C'est-à-dire que l'interface utilisée pour le trafic ne peut pas être utilisée pour les sauvegardes HA et les points de contrôle

  • En cas de basculement, le CUBE, qui était auparavant actif, est rechargé par conception, afin de préserver la signalisation et les médias

Configurer la redondance sur les deux CUBE

Vous devez configurer la redondance box à box de couche 2 sur les deux CUBES destinés à être utilisés dans une paire HA pour faire apparaître des adresses IP virtuelles.

A typical CUBE HA setup as Local Gateway for a Cisco Webex Calling trunk deployment

1

Configurez le suivi de l'interface au niveau mondial 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

La CLI Track est utilisée dans RG pour suivre l'état de l'interface de trafic vocal afin que l'itinéraire actif reprenne son rôle actif une fois l'interface de trafic hors service.

2

Configurez un RG à utiliser avec la VoIP HA en sous-mode de redondance des applications.

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 : passe en mode redondance

  • redondance des applications : passe en mode de configuration de redondance des applications

  • groupe : passe en mode de configuration du groupe d'applications de redondance

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

  • priorité 100, seuil de basculement 75 : spécifie la priorité initiale et les seuils de basculement pour un RG

  • minuteries, délai 30, rechargement 60 — Configure les deux heures de retard et de rechargement

    • Délai, c'est-à-dire le temps nécessaire pour retarder l'initialisation du groupe RG et la négociation des rôles une fois l'interface ouverte. Par défaut, 30 secondes. La plage est de 0 à 10 000 secondes

    • Recharger : c'est le temps nécessaire pour retarder l'initialisation du groupe RG et la négociation des rôles après un rechargement. Par défaut, 60 secondes. La plage est de 0 à 10 000 secondes

    • Les minuteries par défaut sont recommandées, mais elles peuvent être ajustées pour tenir compte de tout retard de convergence du réseau supplémentaire qui pourrait survenir lors du démarrage/du rechargement des routeurs, afin de garantir que la négociation du protocole RG ait lieu une fois que le routage du réseau aura convergé vers un point stable. Par exemple, si après le basculement, on constate qu'il faut jusqu'à 20 secondes au nouveau STANDBY pour recevoir le premier paquet RG HELLO provenant du nouvel ACTIVE, alors les minuteries doivent être réglées sur « temporisation 60 rechargement 120 » pour tenir compte de ce délai.

  • control GigabitEthernet3 protocol 1 — 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 passe en mode de configuration du protocole d'application de redondance

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

  • track —Suivi des interfaces par groupe RG

  • protocole 1 : spécifie l'instance de protocole qui sera connectée à une interface de contrôle et passe en mode de configuration du protocole d'application de redondance

  • chronomètres hellotime 3 holdtime 10 — Configure les deux chronomètres pour hellotime et holdtime :

    • Hellotime — Intervalle entre les messages de bonjour successifs — 3 secondes par défaut. La plage est de 250 millisecondes à 254 secondes

    • Temps d'attente : intervalle entre la réception d'un message Hello et la présomption de défaillance du routeur expéditeur. Cette durée doit être supérieure à l'heure du bonjour, 10 secondes par défaut. La plage est de 750 millisecondes à 255 secondes

      Nous vous recommandons de configurer le minuteur d'attente de manière à ce qu'il soit au moins 3 fois supérieur à la valeur du minuteur d'accueil.

3

Activez la redondance box to box pour l'application CUBE. Configurez le RG à l'étape précédente. voice service voip Cela 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écessitent un rechargement pour que la configuration mise à jour prenne effet. Nous rechargerons les plateformes une fois que toutes les configurations auront été appliquées.

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)# 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 de l'interface de redondance pour le groupe de redondance. Requis pour générer une adresse MAC virtuelle (VMAC). La même valeur d'ID rii doit être utilisée sur l'interface de chaque routeur (ACTIF/STANDBY) qui possède le même VIP.

    S'il y a plus d'une paire B2B sur le même réseau local, chaque paire DOIT avoir un identifiant Rii unique sur ses interfaces respectives (pour éviter les collisions). La commande show redundancy application group all doit indiquer les bonnes informations locales et homologues.

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

    L'utilisation d'une interface distincte est obligatoire pour des raisons de 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 et les données RG

5

Enregistrez la configuration du premier CUBE et rechargez-le.

La plateforme qui se recharge en dernier est toujours la Standby.

VCUBE-1#wr
Building configuration...
[OK]
VCUBE-1#reload
Proceed with reload? [confirm]

Une fois le VCUBE-1 complètement démarré, enregistrez la configuration de VCUBE-2 et rechargez-le.

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 surlignés en gras.

Nous avons rechargé le VCUBE-2 en dernier et, pour des raisons de conception, la plateforme à recharger en dernier sera toujours Standby. 


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#

Ensuite, passez à la configuration de la passerelle locale (basée sur l'enregistrement ou sur les certificats) sur les deux HA CUBE. Voir Configurer la passerelle locale sur Cisco IOS XE pour Webex Calling.

Cet article était-il utile ?
Cet article était-il utile ?
TarifsApplication WebexMeetingsCallingMessageriePartage d’écran
Webex SuiteCallingMeetingsMessagerieSlidoWebinarsEventsCentre de contactCPaaSSécuritéControl Hub
CasquesCamérasSérie de bureauxSérie RoomSérie BoardSérie PhoneAccessoires
EnseignementSoins de santéGouvernementFinanceSports et loisirsFrontlineBut non lucratifStartupstravail hybride
TéléchargementsRejoindre une réunion testCours en ligneExtensionsAccessibilitéInclusivitéWebinaires en direct et à la demandeCommunauté WebexDéveloppeurs WebexNouveautés et innovations
CiscoContacter l’assistanceContacter le Service commercialWebex BlogWebex Thought LeadershipWebex Merch StoreCarrières
  • X
  • LinkedIn
  • Facebook
  • Youtube
  • Instagram
Conditions généralesDéclaration de confidentialitéCookiesMarques commerciales
©2026 Cisco et/ou ses affiliés. Tous droits réservés.
Conditions généralesDéclaration de confidentialitéCookiesMarques commerciales