Fundamentos

Requisitos previos

Antes de implementar CUBE HA como puerta de enlace local para Webex Calling, asegúrese de comprender en profundidad los siguientes conceptos:

Las pautas de configuración proporcionadas en este artículo suponen una plataforma de puerta de enlace local exclusiva sin configuración de voz existente. Si se está modificando una implementación empresarial de CUBE existente para utilizar también la función de puerta de enlace local para Cisco Webex Calling, preste atención a la configuración aplicada para asegurarse de que los flujos de llamadas y las funcionalidades existentes no se interrumpan y asegúrese de que esté cumpliendo con los requisitos de diseño de CUBE HA.

Componentes de hardware y software

CUBE HA como puerta de enlace local requiere IOS-XE versión 16.12.2 o posterior y una plataforma en la que se admitan las funciones de CUBE HA y LGW.

Los comandos show y los registros de este artículo se basan en una versión mínima de software de Cisco IOS-XE 16.12.2 implementada en un vCUBE (CSR1000v).

Material de referencia

A continuación, se detallan algunas guías de configuración de CUBE HA para diversas plataformas:

Descripción general de la solución Webex Calling

Cisco Webex Calling es una oferta de colaboración que ofrece una alternativa basada en la nube de varios inquilinos al servicio telefónico PBX local con varias opciones de PSTN para los clientes.

La implementación de la puerta de enlace local (representada a continuación) es el punto central de este artículo. El enlace troncal de la puerta de enlace local (PSTN local) en Webex Calling permite la conectividad a un servicio de PSTN propiedad del cliente. También proporciona conectividad para una implementación de IP PBX local, como Cisco Unified CM. Todas las comunicaciones hacia y desde la nube se protegen mediante el transporte TLS para SIP y SRTP para medios.

La figura a continuación muestra una implementación de Webex Calling sin ninguna IP PBX existente y se aplica a una implementación de uno o varios sitios. La configuración que se describe en este artículo se basa en esta implementación.

Redundancia entre decodificadores de nivel 2

La redundancia entre decodificadores de nivel 2 de CUBE HA utiliza el protocolo de infraestructura del Grupo de redundancia (RG) para formar un par de enrutadores activos/en espera. Este par comparte la misma dirección IP virtual (VIP) en sus respectivas interfaces y continuamente intercambian mensajes de estado. Se comprueba la información de la sesión de CUBE en todo el par de enrutadores, lo que permite que el enrutador en modo de espera asuma todas las responsabilidades del procesamiento de llamadas de CUBE de inmediato si el enrutador activo queda fuera de servicio, lo que genera la preservación de con inspección de estado de la señalización y los medios.

El punto de verificación se limita a llamadas conectadas con paquetes de medios. Las llamadas en tránsito no se verifican por punto (por ejemplo, un estado de intento o de timbre).

En este artículo, CUBE HA hará referencia a la redundancia entre decodificadores (B2B) de nivel 2 de CUBE de alta disponibilidad (HA) para la preservación de llamadas con inspección de estado.

A partir de IOS-XE 16.12.2, CUBE HA se puede implementar como puerta de enlace local para implementaciones del enlace troncal de Cisco Webex Calling (PSTN local), y cubriremos las consideraciones y configuraciones de diseño en este artículo. En esta figura se muestra una configuración típica de CUBE HA como puerta de enlace local para una implementación del enlace troncal de Cisco Webex Calling.

Componente Infra del grupo de redundancia

El componente Infra del grupo de redundancia (RG) proporciona soporte para la infraestructura de comunicación entre decodificadores entre los dos CUBE y negocia el estado de redundancia estable final. Este componente también proporciona:

  • Un protocolo similar a HSRP que negocia el estado de redundancia final para cada enrutador intercambiando mensajes de monitoreo de actividad y bienvenida entre los dos CUBE (a través de la interfaz de control); GigabitEthernet3 en la figura anterior.

  • Un mecanismo de transporte para el punto de control del estado de la señalización y los medios para cada llamada desde el enrutador activo al de modo de espera (a través de la interfaz de datos); GigabitEthernet3 en la figura anterior.

  • Configuración y administración de la interfaz de IP virtual (VIP) para las interfaces de tráfico (varias interfaces de tráfico se pueden configurar con el mismo grupo de RG); GigabitEthernet 1 y 2 se consideran interfaces de tráfico.

Este componente de RG debe configurarse específicamente para admitir B2B HA de voz.

Administración de la dirección IP virtual (VIP) para señalización y medios

B2B HA depende de la VIP para lograr la redundancia. La VIP y las interfaces físicas asociadas en ambos CUBE en el par de CUBE HA deben residir en la misma subred LAN. La configuración de la VIP y la vinculación de la interfaz VIP para una aplicación de voz (SIP) en particular son obligatorias para la compatibilidad con B2B HA de voz. Los dispositivos externos, como Unified CM, el SBC de acceso a Webex Calling, el proveedor de servicios o el proxy, usan la VIP como dirección IP de destino para las llamadas que atraviesan los enrutadores de CUBE HA. Por lo tanto, desde el punto de vista de Webex Calling, los pares de CUBE HA actúan como una única puerta de enlace local.

La información de la sesión de RTP y de señalización de llamadas de las llamadas establecidas se encuentran en punto de control desde el enrutador activo hasta el enrutador de espera. Cuando el enrutador activo se cae, el enrutador de modo de espera toma el control y sigue reenviando el flujo de RTP anteriormente enrutado por el primer enrutador.

Las llamadas en un estado transitorio en el momento de la recuperación de fallas no se conservarán después de la conmutación. Por ejemplo, las llamadas que todavía no están totalmente establecidas o están en proceso de modificación con una función de transferencia o espera. Las llamadas establecidas pueden desconectarse después de la conmutación.

Existen los siguientes requisitos para utilizar CUBE HA como puerta de enlace local para la recuperación de fallas con inspección de estado de las llamadas:

  • CUBE HA no puede tener interfaces TDM o analógicas ubicadas al mismo tiempo

  • A Gig1 y Gig2 se les conoce como interfaces de tráfico (SIP/RTP) y Gig3 es una interfaz de control/datos del grupo de redundancia (RG).

  • No se pueden colocar más de 2 pares de CUBE HA en el mismo dominio de nivel 2, uno con ID de grupo 1 y el otro con ID de grupo 2. Si configura 2 pares de alta disponibilidad con el mismo ID de grupo, las interfaces de control/datos de RG deben pertenecer a dominios de nivel 2 diferentes (vlan, conmutador independiente)

  • El canal de puertos es compatible con las interfaces de control/datos y tráfico de RG

  • Todas la señalización/los medios se traslada desde/hacia la dirección IP virtual

  • Cada vez que se recarga una plataforma en una relación CUBE-HA, siempre arranca en modo de espera

  • La dirección más baja para todas las interfaces (Gig1, Gig2, Gig3) debe estar en la misma plataforma

  • El Identificador de interfaz de redundancia (RII), debe ser único para una combinación de par/interfaz en el mismo nivel 2

  • La configuración en amos CUBE debe ser idéntica, incluida la configuración física, y debe ejecutarse en el mismo tipo de plataforma y versión de IOS-XE

  • Las interfaces de bucle no se pueden utilizar como enlace, ya que siempre están activas

  • Las interfaces de tráfico múltiple (SIP/RTP) (Gig1, Gig2) requieren que se configure el seguimiento de la interfaz

  • CUBE-HA no es compatible con una conexión de cable transversal para el enlace de datos/control de RG (Gig3)

  • Ambas plataformas deben ser idénticas y conectarse a través de un conmutador físico en todas las interfaces similares para que CUBE HA funcione, es decir, GE0/0/0 de CUBE-1 y CUBE-2 deben terminar en el mismo conmutador, y así sucesivamente.

  • WAN no puede terminar en los CUBE directamente ni en la alta disponibilidad de datos en cualquiera de los lados

  • Tanto el enrutador activo como el de espera deben estar en el mismo centro de datos

  • Es obligatorio utilizar una interfaz L3 independiente para la redundancia (control/datos de RG, Gig3). Es decir, la interfaz que se utiliza para el tráfico no se puede utilizar para mantener el monitoreo de actividad y los puntos de control de HA

  • Después de la recuperación de fallas, el CUBE anteriormente activo pasa por una recarga por diseño, preservando la señalización y los medios

Configurar la redundancia en ambos CUBE

Debe configurar la redundancia entre decodificadores de nivel 2 en ambos CUBE que se utilizarán en un par de HA para recupera las IP virtuales.

1

Configure el seguimiento de la interfaz a nivel global para realizar un seguimiento del estado de la interfaz.

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 de seguimiento se utiliza en RG para realizar un seguimiento del estado de la interfaz de tráfico de voz de modo que la ruta activa abandone su rol activo una vez que de desactive la interfaz de tráfico.
2

Configure un RG para utilizar con VoIP HA bajo el modo secundario de redundancia de la aplicación.

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)#

Aquí se ofrece una explicación de los campos utilizados en esta configuración:

  • redundancia: introduce el modo de redundancia

  • redundancia de la aplicación: introduce el modo de configuración de redundancia de la aplicación

  • grupo: introduce el modo de configuración del grupo de aplicaciones de redundancia

  • nombre de puerta de enlace local-HA: define el nombre del grupo de RG

  • prioridad 100 umbral de recuperación de fallas 75: especifica los umbrales iniciales de prioridad y recuperación de fallas para un RG

  • demora de temporizadores 30 recarga 60: configura los dos tiempos para la demora y la recarga

    • Temporizador de demora, que es la cantidad de tiempo para demorar la inicialización y la negociación de funciones del grupo de RG después de que aparece la interfaz: valor predeterminado de 30 segundos. El rango es de 0 a 10 0000 segundos

    • Recarga: esta es la cantidad de tiempo para demorar la inicialización y la negociación de funciones del grupo de RG después de una recarga: valor predeterminado de 60 segundos. El rango es de 0 a 10 0000 segundos

    • Se recomiendan los temporizadores predeterminados, aunque estos temporizadores se pueden ajustar para adaptarse a cualquier demora de convergencia de red adicional que pueda ocurrir durante el arranque/la recarga de los enrutadores, a fin de garantizar que se lleve a cabo la negociación del protocolo de RG después de que el enrutamiento en la red haya convergido a un punto estable. Por ejemplo, si se observa después de la recuperación de fallas que demora hasta 20 segundos para que el nuevo STANDBY vea el primer paquete RG HELLO del nuevo ACTIVE, los temporizadores se deben ajustar a "demora de temporizadores 60 recarga 120" para ajustarse a esta demora.

  • control GigabitEthernet3 protocolo 1: configura la interfaz que se utiliza para intercambiar mensajes de actividad y bienvenida entre los dos CUBE y especifica la instancia del protocolo que se adjuntará a una interfaz de control e introduce el modo de configuración del protocolo de redundancia de la aplicación.

  • GigabitEthernet3 de datos: configura la interfaz que se utiliza para el punto de control del tráfico de datos.

  • seguimiento: seguimiento de interfaces del grupo de RG

  • protocolo 1: especifica la instancia del protocolo que se adjuntará a una interfaz de control e introduce el modo de configuración del protocolo de la aplicación de redundancia

  • bienvenida de temporizadores 3 espera 10: configura los dos temporizadores para la bienvenida y la espera:

    • Bienvenida: intervalo entre mensajes de bienvenida sucesivos (valor predeterminado de 3 segundos). El rango es de 250 milisegundos a 254 segundos

    • Espera: el intervalo entre la recepción de un mensaje de bienvenida y la confirmación de que el enrutador que envía ha fallado. Esta duración debe ser superior al tiempo de bienvenida (valor predeterminado de 10 segundos). El rango es de 750 milisegundos a 255 segundos

      Le recomendamos que configure el temporizador de espera para que sea al menos 3 veces el valor del temporizador de bienvenida.
3

Habilite la redundancia entre decodificadores para la aplicación CUBE. Configure el RG en el paso anterior en voice service voip. Esto permite que la aplicación CUBE controle el proceso de redundancia. 

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

redundancia-grupo 1: para agregar y eliminar este comando, se requiere una recarga a fin de que la configuración actualizada entre en vigencia. Volveremos a cargar las plataformas una vez que se haya aplicado toda la configuración.
4

Configure las interfaces Gig1 y Gig2 con sus respectivas IP virtuales como se muestra a continuación y aplique el identificador de interfaz de redundancia (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

Aquí se ofrece una explicación de los campos utilizados en esta configuración:

  • redundancia rii: configura el identificador de interfaz de redundancia para el grupo de redundancia. Necesario para generar una dirección de MAC virtual (VMAC). Debe usarse el mismo valor de ID de rii en la interfaz de cada enrutador (ACTIVE/STANDBY) que tenga la misma VIP.


     

    Si hay más de un par de B2B en la misma LAN, cada par DEBE tener ID de rii únicos en sus respectivas interfaces (para evitar la colisión). "show redundancy application group all" debe indicar la información local y de pares correcta.

  • grupo de redundancia 1: asocia la interfaz con el grupo de redundancia creado en el paso 2 anterior. Configure el grupo de RG, así como la VIP asignada a esta interfaz física.


     

    Es obligatorio utilizar una interfaz separada para la redundancia, es decir, la interfaz utilizada para el tráfico de voz no se puede utilizar como interfaz de control y datos especificada en el paso 2 anterior. En este ejemplo, la interfaz Gigabit 3 se utiliza para control/datos de RG
5

Guarde la configuración del primer CUBE y vuelva a cargarla.

La última plataforma en volver a cargarse es la de espera.

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

Después de que VCUBE-1 se inicie completamente, guarde la configuración de VCUBE-2 y vuelva a cargarla.

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

Verifique que la configuración entre decodificadores esté funcionando como se esperaba. La salida relevante se resalta en negrita.

Hemos recargado el último VCUBE-2 y, de acuerdo con las consideraciones de diseño, la última plataforma que se volverá a cargar en siempre será la de espera.


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#

Configurar una puerta de enlace local en ambos CUBE

En nuestra configuración de ejemplo, estamos utilizando la siguiente información de enlace troncal de Control Hub para crear la configuración de la puerta de enlace local tanto en las plataformas, VCUBE-1 como VCUBE-2. El nombre de usuario y la contraseña para esta configuración son los siguientes:

  • Usuario: Hussain1076_LGU

  • Contraseña: lOV12MEaZx

1

Asegúrese de que se haya creado una clave de configuración para la contraseña con los comandos show que se muestran a continuación, antes de poder utilizarse en las credenciales o en los secretos compartidos. Las contraseñas del tipo 6 se cifran mediante cifrado AES y esta clave de configuración definida por el usuario.


LocalGateway#conf t
LocalGateway(config)#key config-key password-encrypt Password123
LocalGateway(config)#password encryption aes

A continuación, se muestra la configuración de la puerta de enlace local que se aplicará a ambas plataformas según los parámetros de Control Hub mostrados arriba, guardar y volver a cargar. Las credenciales del Resumen de SIP de Control Hub se resaltan en negrita.


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

Para mostrar la salida del comando show, hemos recargado VCUBE-2 seguido de VCUBE-1, lo que hace que VCUBE-1 sea el CUBE de espera y VCUBE-2 el activo
2

En un momento determinado, solo una plataforma mantendrá una inscripción activa como puerta de enlace local con el SBC de acceso de Webex Calling. Mire los resultados de los siguientes comandos show.

show redundancy application group 1

show sip-ua-register status


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#

A partir de la salida anterior, puede ver que VCUBE-2 es el LGW activo que mantiene la inscripción con el SBC de acceso de Webex Calling, mientras que la salida de "show sip-ua register status" está en blanco en VCUBE-1
3

Ahora habilite las siguientes depuraciones en 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

Simule la recuperación de fallas mediante la emisión del siguiente comando en LGW activo, VCUBE-2 en este caso.


VCUBE-2#redundancy application reload group 1 self

El cambio del LGW ACTIVE a STANDBY ocurre en la siguiente situación, además de la CLI listada anteriormente.

  • Cuando se recarga el enrutador ACTIVE

  • Cuando se apaga y se enciende el enrutador ACTIVE

  • Cuando cualquier interfaz configurada de RG del enrutador ACTIVE para la que está habilitado el seguimiento está apagada
5

Compruebe si VCUBE-1 se ha inscrito en el SBC de acceso de Webex Calling VCUBE-2 ya debería haberse recargado.


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 ahora es el LGW activo.
6

Mire el registro de depuración relevante en VCUBE-1 que envía un SIP REGISTER a Webex Calling a través de la IP virtual y recibe 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