Bases

Prérequis

Avant de déployer Cisco Unified Border Element (CUBE) High Availability (HA) en tant que 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 respectez les exigences de conception de CUBE HA.

Composants matériels et logiciels

CUBE HA en tant que passerelle locale nécessite IOS-XE version 17.9.1 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 minimum 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 :

Présentation de la solution Webex Calling

Cisco Webex Calling est une offre de collaboration qui fournit une alternative multi-locataire 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 trunk de la passerelle locale (RTCP sur site) dans Webex Calling permet la connectivité à un service RTCP appartenant au client. Il 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 à l’aide du transport TLS pour SIP et SRTP pour les médias.

Déploiement RTCP sur site de la passerelle locale

La figure ci-dessous montre 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.

Déploiement de Webex Calling sans PBX IP

Redondance boîte à boîte de couche 2

La redondance boite à boite de couche 2 de CUBE HA utilise le protocole d’infrastructure Redundancy Group (RG) pour former une paire de routeurs actifs/en attente. Cette paire partage la même adresse IP virtuelle (VIP) sur leurs interfaces respectives et échange continuellement des messages d'état. Les informations de session CUBE sont vérifiées sur la paire de routeurs, ce qui permet au routeur en veille de prendre immédiatement en charge toutes les responsabilités de traitement des appels CUBE si le routeur actif est hors service, ce qui entraîne la préservation de l'état de la signalisation et des médias.

Le pointage de vérification 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 fera 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.

À partir d’IOS-XE 17.9.1, 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). Cet article traitera des considérations de conception et des configurations. La figure montre une configuration typique de CUBE HA en tant que passerelle locale pour un déploiement de trunk Cisco Webex Calling.

Une configuration typique de CUBE HA en tant que passerelle locale pour un déploiement de trunk Cisco Webex Calling

Composant infra 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 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 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 vérifier l'état de la signalisation et du média pour chaque appel du routeur actif vers le routeur en 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é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 atteindre 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 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 veille. Lorsque le routeur actif tombe en panne, le routeur en veille prend le relais et continue à transférer 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 cours de modification avec une fonction de transfert ou d'attente. Les appels établis peuvent être déconnectés après le basculement.

Les exigences suivantes existent pour l'utilisation de CUBE HA comme passerelle locale pour le basculement dynamique des appels :

  • 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, une avec l’ID de groupe 1 et l’autre avec l’identifiant de groupe 2. Si vous configurez 2 paires HA avec le même ID 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 à la fois pour les interfaces de contrôle/données RG et de trafic

  • 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 pour toutes les interfaces (Gig1, Gig2, Gig3) doit être sur la même plateforme

  • L’identificateur d’interface de redondance, rii, doit être unique pour une combinaison paire/interface sur la même couche 2

  • La configuration sur les deux CUBEs doit être identique, y compris la configuration physique, et doit s’exécuter sur le même type de plateforme et la même version 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 pris en charge 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 GE0/0/0 de CUBE-1 et CUBE-2 doivent se terminer sur le même commutateur et ainsi de suite.

  • Impossible que le réseau étendu (WAN) se termine directement sur les CUBEs ou sur Data HA de chaque côté

  • Les deux fonctions Active/Standby 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

  • Lors du basculement, le CUBE précédemment actif subit un rechargement par sa conception, préservant la signalisation et les médias

Configurer la redondance sur les deux CUBEs

Vous devez configurer la redondance boite à boite de couche 2 sur les deux CUBE destinés à être utilisés dans une paire HD pour faire apparaître les IP virtuelles.

Une configuration typique de CUBE HA en tant que passerelle locale pour un déploiement de trunk Cisco Webex Calling

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

Track CLI 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 une utilisation 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 en mode redondance

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

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

  • nom de la passerelle locale-HA–Définit le nom du groupe RG

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

  • timers delay 30 reload 60–Configure les deux fois de retard et de rechargement

    • Minuteur de délai qui est la durée de temporisation de l’initialisation du groupe RG et de la négociation de rôle après l’apparition de l’interface – Par défaut 30 secondes. La plage est comprise entre 0 et 10 000 secondes

    • Recharger : il s’agit du délai 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 comprise entre 0 et 10 000 secondes

    • Les délais par défaut sont recommandés, bien que ces délais puissent être ajustés 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, s’il est constaté après le basculement qu’il faut jusqu’à 20 secondes au nouveau STANDBY pour voir le premier paquet RG HELLO du nouveau ACTIVE, les temporisateurs doivent être ajustés à « timers delay 60 reload 120 » pour prendre en compte ce délai.

  • contrôle du protocole GigabitEthernet3 1–Configure l’interface utilisée pour échanger des messages keepalive et hello entre les deux CUBEs, et spécifie l’instance de protocole qui sera attachée à une interface de contrôle et entre le 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

  • suivi—Suivi des interfaces par le groupe RG

  • protocole 1–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 redondance

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

    • Heure d’appel—Intervalle entre les messages d’appel successifs – 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 d’accueil – Par défaut 10 secondes. La plage est de 750 millisecondes à 255 secondes

      Nous vous recommandons de configurer le temporisateur de durée d’attente pour qu’il soit au moins 3 fois supérieur à la valeur du temporisateur d’accueil.

3

Activez la redondance boîte à boîte pour l’application CUBE. Configurez le RG à partir de l’étape précédente sous 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écessite un rechargement pour que la configuration mise à jour prenne effet. Nous rechargerons les plateformes une fois que toute la configuration aura été appliquée.

4

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

VCUBE-1(config)#interface GigabitEthernet1

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

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

VCUBE-1(config-if)# exit

VCUBE-1(config)#

VCUBE-1(config)#interface GigabitEthernet2

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

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

VCUBE-1(config-if)# exit

VCUBE-2(config)#interface GigabitEthernet1

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

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

VCUBE-2(config-if)# exit

VCUBE-2(config)#

VCUBE-2(config)#interface GigabitEthernet2

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

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

VCUBE-v(config-if)# exit

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

  • redundancy rii–Configure l’identifiant de l’interface de redondance pour le groupe de redondance. Nécessaire 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/EN VEILLE) 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). La commande show redundancy application group all doit indiquer les informations locales et sur les 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’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 voix 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 la mise en veille.

VCUBE-1#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-1#reload


                        Proceed with reload? [confirm]
                      

Après le démarrage complet de VCUBE-1 , enregistrez 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 boîte à boîte 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 plateforme à recharger en dernier sera toujours 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#

Ensuite, procédez à la configuration de la passerelle locale (basée sur l’enregistrement ou sur le certificat) sur les deux CUBE DE HD. Voir Configurer la passerelle locale sur Cisco IOS XE pour Webex Calling.