Fundamentos

Pré-requisitos

Antes de implantar o CUBE HA como um gateway local no Webex Calling, certifique-se de ter um conhecimento profundo dos seguintes conceitos:

As diretrizes de configuração fornecidas neste artigo assumem uma plataforma de gateway local dedicada sem configuração de voz existente. Se uma implantação existente de CUBE Enterprise estiver sendo modificada para também usar a função de gateway local do Cisco Webex Calling, preste muita atenção à configuração aplicada para garantir que os fluxos de chamadas e funcionalidades existentes não sejam interrompidos e certifique-se de que você esteja cumprindo os requisitos de design do CUBE HA.

Componentes de hardware e software

O CUBE HA como gateway local requer o IOS-XE versão 16.12.2 ou posterior e uma plataforma na qual as funções de CUBE HA e LGW sejam compatíveis.

Os registros e comandos show neste artigo são baseados na versão mínima do software Cisco IOS-XE 16.12.2 implementado em um vCUBE (CSR1000v).

Material de referência

Aqui estão alguns guias detalhados de configuração do CUBE HA para várias plataformas:

Visão geral da solução do Webex Calling

O Cisco Webex Calling é uma oferta de colaboração que fornece uma alternativa de vários locatários baseada em nuvem ao serviço telefônico PBX local com várias opções de PSTN para os clientes.

A implantação do Gateway Local (representada abaixo) é o foco deste artigo. O tronco do gateway local (PSTN com base no local) no Webex Calling permite a conectividade com um serviço PSTN de propriedade do cliente. Ele também fornece conectividade para uma implantação de IP PBX local, como Cisco Unified CM. Todas as comunicações de e para a nuvem são protegidas usando transporte TLS para SIP e SRTP para mídia.

A figura abaixo exibe uma implantação do Webex Calling sem qualquer IP PBX existente e é aplicável a uma implantação em um único ou em vários sites. A configuração descrita neste artigo é baseada nesta implantação.

Redundância box-to-box de camada 2

A redundância box-to-box de camada 2 com CUBE HA usa o protocolo de infraestrutura do Grupo de redundância (RG) para formar um par de roteadores ativo/em espera. Este par compartilha o mesmo endereço IP virtual (VIP) em suas respectivas interfaces e troca mensagens de status continuamente. As informações da sessão CUBE são verificadas no par de roteadores, permitindo que o roteador em espera assuma todas as responsabilidades de processamento de chamadas CUBE imediatamente se o roteador ativo ficar fora de serviço, resultando na preservação stateful da sinalização e da mídia.

A verificação é limitada a chamadas conectadas com pacotes de mídia. As chamadas em trânsito não são apontadas para verificação (por exemplo, um estado de tentativa ou toque).

Neste artigo, CUBE HA se referirá à redundância box-to-box (B2B) de camada 2 com CUBE de alta disponibilidade (HA) para preservação de chamadas stateful

A partir do IOS-XE 16.12.2, o CUBE HA poderá ser implantado como um Gateway local para implantações de tronco Cisco Webex Calling (PSTN com base no local) e abordaremos configurações e considerações de design neste artigo. Esta figura exibe uma configuração típica do CUBE HA como Gateway local para uma implantação de tronco Cisco Webex Calling.

Componente de infraestrutura do grupo de redundância

O componente de infraestrutura do Grupo de redundância (RG) fornece o suporte de infraestrutura para comunicação box-to-box entre os dois CUBEs e negocia o estado de redundância estável final. Este componente também fornece:

  • Um protocolo semelhante ao HSRP que negocia o estado final de redundância de cada roteador, trocando mensagens keepalive e hello entre os dois CUBEs (por meio da interface de controle) —GigabitEthernet3 na figura acima.

  • Um mecanismo de transporte para verificar a sinalização e o estado da mídia de cada chamada do roteador ativo para o em espera (por meio da interface de dados)—GigabitEthernet3 na figura acima.

  • Configuração e gerenciamento da interface IP Virtual (VIP) para as interfaces de tráfego (várias interfaces de tráfego podem ser configuradas usando o mesmo grupo RG)—Os GigabitEthernet 1 e 2 são considerados interfaces de tráfego.

Este componente RG deve ser configurado especificamente para suportar voz B2B HA.

Gerenciamento de endereços IP Virtual (VIP) para sinalização e mídia

O B2B HÁ depende do VIP para obter redundância. As interfaces VIP e físicas associadas em ambos os CUBEs do par de CUBE HA devem residir na mesma subrede LAN. A configuração do VIP e a vinculação da interface VIP a um determinado aplicativo de voz (SIP) são obrigatórias para o suporte de voz B2B HA. Dispositivos externos, como Unified CM, Webex Calling Access SBC, provedor de serviços ou proxy, usam VIP como o endereço IP de destino para as chamadas que passam pelos roteadores CUBE HA. Portanto, do ponto de vista do Webex Calling, os pares CUBE HA atuam como um único gateway local.

A sinalização de chamadas e as informações da sessão RTP das chamadas estabelecidas são verificadas do roteador ativo para o roteador em espera. Quando o roteador Ativo cai, o roteador Em espera assume e continua encaminhando o fluxo RTP que foi encaminhado anteriormente pelo primeiro roteador.

As chamadas em um estado transitório no momento do failover não serão preservadas após a alternância. Por exemplo, chamadas que ainda não foram totalmente estabelecidas ou que estão em processo de modificação com uma função de transferência ou em espera. As chamadas estabelecidas poderão ser desconectadas após a transição.

Existem os seguintes requisitos para usar o CUBE HA como um gateway local em caso de failover stateful de chamadas:

  • O CUBE HA não pode ter TDM ou interfaces analógicas colocalizadas

  • Gig1 e Gig2 são referenciados como interfaces de tráfego (SIP/RTP) e Gig3 é a interface de controle/dados do Grupo de redundância (RG)

  • Não mais do que 2 pares CUBE HA podem ser colocados no mesmo domínio da camada 2, um com ID de grupo 1 e outro com ID de grupo 2. Se estiver configurando 2 pares de HA com a mesma ID de grupo, as interfaces de controle/dados RG precisam pertencer a domínios diferentes de camada 2 (vlan, switch separado)

  • O canal de porta é compatível com interfaces de tráfego e controle/dados RG

  • Toda a sinalização/mídia é fornecida de/para o endereço IP virtual

  • Sempre que uma plataforma é recarregada em uma relação CUBE-HA, ela inicializa como Em espera

  • O endereço inferior de todas as interfaces (Gig1, Gig2, Gig3) deve estar na mesma plataforma

  • O Identificador da interface redundante (RII) deve ser exclusivo em uma combinação de par/interface na mesma Camada 2

  • A configuração em ambos os CUBEs deve ser idêntica, incluindo a configuração física e deve estar em execução no mesmo tipo de plataforma e versão IOS-XE

  • As interfaces de loopback não podem ser usadas como ligação, pois estão sempre ativas

  • As interfaces de múltiplos tráfegos (SIP/RTP) (Gig1, Gig2) requerem que o rastreamento de interface seja configurado

  • O CUBE-HA não é compatível com uma conexão de cabo cruzado no link de controle/dados RG (Gig3)

  • Ambas as plataformas devem ser idênticas e estar conectadas por meio de um switch físico em todas as interfaces semelhantes para que o CUBE HA funcione, ou seja, o GE0/0/0 do CUBE-1 e do CUBE-2 deve terminar no mesmo switch e assim por diante.

  • O WAN não pode ser terminado diretamente nos CUBEs ou nos dados HA em qualquer um dos lados

  • Ambos Ativo/Em espera devem estar no mesmo data center

  • É obrigatório usar a interface L3 separada para redundância (Controle RG/dados, Gig3), ou seja, a interface usada para tráfego não pode ser usada para manutenção de atividade e verificação de HA

  • Após o failover, o CUBE previamente ativo passa por uma recarga por design, preservando a sinalização e a mídia

Configurar a redundância em ambos os CUBEs

Você deve configurar a redundância box-to-box da camada 2 em ambos os CUBEs destinados a serem usados em um par de HA para ativar IPs virtuais.

1

Configure o rastreamento de interface em um nível global para rastrear o status da interface.

track t track 1 interface GigabitEthernet1 faixa de protocolo de linha 
 
 2 interface GigabitEthernet2 saída de protocolo de linha 

VCUBE-1#conf t

 VCUBE-1(config)# faixa 1 interface GigabitEthernet1 linha-protocolo 

 VCUBE-1(config-track)# track 2 interface GigabitEthernet2 line-protocol 

 VCUBE-1(config-track)# exit 

VCUBE-2#conf t

 VCUBE-2(config)# faixa 1 interface GigabitEthernet1 linha-protocolo 

 VCUBE-2(config-track)# track 2 interface GigabitEthernet2 line-protocol 

 VCUBE-2(config-track)# exit

O CLI de rastreamento é usado no RG para rastrear o estado da interface de tráfego de voz, de modo que a rota ativa cumpra sua função ativa depois que a interface de tráfego for desativada.

2

Configure um RG para uso com VoIP HA no submodo de redundância do aplicativo.

redundância do aplicativo de redundância grupo 
 
 
    1 nome LocalGateway-HA prioridade 
    100 failover limiar 75 controle 
    GigabitEthernet3 protocolo 1 data GigabitEthernet3 temporizadores de atraso 30 recarregam 60 faixa 1 de desligamento 2 desligamento protocolo de saída 
 
 
 
 
 
   1 
    temporizadores hellotime 3 holdtime 10 
 
 
 sair sair 

 VCUBE-1(config)# redundância 

 VCUBE-1 (vermelho-config)# redundância do aplicativo 

 VCUBE-1(config-red-app)# group 1 

 VCUBE-1(config-red-app-grp)# nome LocalGateway-HA 

 VCUBE-1 (config-red-app-grp)# Prioridade 100 limite de failover 75 

 VCUBE-1 (config-red-app-grp)# control GigabitEthernet3 protocol 1 

 VCUBE-1 (config-red-app-grp)# dados GigabitEthernet3 

 VCUBE-1 (config-red-app-grp)# timers atraso 30 recarregar 60 

 VCUBE-1 (config-red-app-grp)# faixa 1 desligamento 

 VCUBE-1 (config-red-app-grp)# faixa 2 desligamento 

 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(configuração) #

 VCUBE-2(config)# redundância 

 VCUBE-2(vermelho-config)# redundância do aplicativo 

 VCUBE-2(config-red-app)# grupo 1 

 VCUBE-2(config-red-app-grp)# nome LocalGateway-HA 

 VCUBE-2(config-red-app-grp)# Prioridade 100 limite de failover 75 

 VCUBE-2(config-red-app-grp)# control GigabitEthernet3 protocol 1 

 VCUBE-1 (config-red-app-grp)# dados GigabitEthernet3 

 VCUBE-2(config-red-app-grp)# timers delay 30 reload 60 

 VCUBE-2(config-red-app-grp)# faixa 1 desligamento 

 VCUBE-2 (config-red-app-grp)# faixa 2 desligamento 

 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(configuração) #

Aqui está uma explicação dos campos usados nesta configuração:

  • redundância —Entra no modo de redundância

  • redundância de aplicativos —Entra no modo de configuração de redundância de aplicativos

  • group —Entra no modo de configuração do grupo de aplicativos de redundância

  • name LocalGateway-HA — Define o nome do grupo RG

  • priority 100 failover threshold 75 — Especifica a prioridade inicial e os limites de failover de um RG

  • timers delay 30 reload 60 — Configura as duas vezes para atraso e recarregamento

    • Temporizador de atraso, que é a quantidade de tempo para atrasar a inicialização do grupo RG e a negociação da função depois que a interface é ativada – Padrão de 30 segundos. O intervalo é de 0 a 10000 segundos

    • Recarregar—Esta é a quantidade de tempo para atrasar a inicialização do grupo RG e a negociação da função após um recarregamento – Padrão de 60 segundos. O intervalo é de 0 a 10000 segundos

    • Temporizadores padrão são recomendados, embora esses temporizadores possam ser ajustados para acomodar qualquer atraso adicional de convergência da rede que possa ocorrer durante a inicialização/recarregamento dos roteadores, a fim de garantir que a negociação do protocolo RG ocorra após o roteamento na rede convergir para um ponto estável. Por exemplo, se for visto após o failover que o novo EM ESPERA leva até 20 segundos para ver o primeiro pacote RG HELLO do novo ATIVO, os temporizadores deverão ser ajustados para "temporizadores de atraso 60 recarregamento 120" para considerar este atraso.

  • control GigabitEthernet3 protocol 1 — Configura a interface usada para trocar mensagens keepalive e hello entre os dois CUBEs e especifica a ocorrência do protocolo que será anexada a uma interface de controle e entra no modo de configuração do protocolo de aplicativos de redundância

  • data GigabitEthernet3 — Configura a interface usada para a verificação do tráfego de dados

  • track — Rastreamento de interfaces do grupo RG

  • protocol 1 —Especifica a ocorrência do protocolo que será anexada a uma interface de controle e entra no modo de configuração do protocolo de aplicativos de redundância

  • timers hellotime 3 holdtime 10 — Configura os dois temporizadores para hellotime e holdtime:

    • Hellotime—Intervalo entre mensagens sucessivas de saudação – Padrão de 3 segundos. O intervalo é de 250 milissegundos a 254 segundos

    • Holdtime—O intervalo entre o recebimento de uma mensagem Hello e a suposição de que o roteador de envio falhou. Essa duração deve ser maior que o tempo de hello – Padrão de 10 segundos. O intervalo é de 750 milissegundos a 255 segundos

      Recomendamos que você configure o temporizador de holdtime para que seja pelo menos 3 vezes o valor do temporizador de hellotime.

3

Habilite a redundância box-to-box para o aplicativo CUBE. Configure o RG a partir da etapa anterior em voip de serviço devoz. Isto permite que o aplicativo CUBE controle o processo de redundância.

voip serviço de voz 
   redundância-grupo 1 
   sair

 VCUBE-1(config.) voip de serviço de voz 

 VCUBE-1(config-voi-serv)# redundância-grupo 1 

 % Criado RG 1 associação com voz B2B HA; recarregar o roteador para que a nova configuração entre em vigor 

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

 VCUBE-2(config.) voip de serviço de voz 

 VCUBE-2(config-voi-serv)# redundância-grupo 1 

 % Criado RG 1 associação com voz B2B HA; recarregar o roteador para que a nova configuração entre em vigor 

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

redundancy-group 1 —Adicionar e remover este comando requer uma recarga para que a configuração atualizada tenha efeito. Recarregaremos as plataformas depois que toda a configuração for aplicada.

4

Configure as interfaces Gig1 e Gig2 com seus respectivos IPs virtuais conforme mostrado abaixo e aplique o identificador de interface redundante (RII)

 VCUBE-1(config)# interface GigabitEthernet1 

 VCUBE-1 (config-if)#  redundância rii 1 

 VCUBE-1 (config-if)#  grupo de redundância 1 IP 198.18.1.228 exclusivo 

 VCUBE-1(config-if)#  exit 

VCUBE-1(configuração) #

 VCUBE-1(config)# interface GigabitEthernet2 

 VCUBE-1 (config-if)#  redundância rii 2 

 VCUBE-1 (config-if)#  grupo de redundância 1 IP 198.18.133.228 exclusivo 

 VCUBE-1(config-if)#  exit 

 VCUBE-2(config)# interface GigabitEthernet1 

 VCUBE-2(config-if)#  redundância rii 1 

 VCUBE-2(config-if)#  grupo de redundância 1 ip 198.18.1.228 exclusivo 

 VCUBE-2(config-if)#  exit 

VCUBE-2(configuração) #

 VCUBE-2(config)# interface GigabitEthernet2 

 VCUBE-2(config-if)#  redundância rii 2 

 VCUBE-2 (config-if)#  grupo de redundância 1 IP 198.18.133.228 exclusivo 

 VCUBE-v(config-if)#  exit

Aqui está uma explicação dos campos usados nesta configuração:

  • redundancy rii — Configura o identificador de interface redundante para o grupo de redundância. Necessário para gerar um endereço MAC Virtual (VMAC). O mesmo valor de ID do RII deve ser usado na interface de cada roteador (ATIVO/EM ESPERA) que possui o mesmo VIP.

    Se houver mais de um par B2B na mesma LAN, cada par DEVE ter IDs rii exclusivas em suas respectivas interfaces (para evitar colisão). "mostrar todos os grupos de aplicativos de redundância" deve indicar as informações corretas locais e de pares.

  • redundancy group 1 — Associa a interface com o grupo de redundância criado na Etapa 2 acima. Configure o grupo RG, bem como o VIP atribuído a esta interface física.

    É obrigatório o uso de uma interface separada para redundância, ou seja, a interface utilizada para tráfego de voz não pode ser utilizada como interface de controle e dados especificada na Etapa 2 acima. Neste exemplo, a interface Gigabit 3 é usada para controle/dados RG

5

Salve a configuração do primeiro CUBE e recarregue-o.

A plataforma a ser recarregada por último é sempre a Em espera.

 VCUBE-1# wr 

 Configuração de edifício... 

 [OK] 

 VCUBE-1# recarregar 

 Prosseguir com recarga? [confirmar]

Depois que o VCUBE-1 inicializar completamente, salve a configuração do VCUBE-2 e recarregue-o.

 VCUBE-2# wr 

 Configuração de edifício... 

 [OK] 

 VCUBE-2# recarregar 

 Prosseguir com recarga? [confirmar]

6

Verifique se a configuração box-to-box está funcionando conforme o esperado. A saída relevante é destacada em negrito.

Recarregamos o VCUBE-2 por último e de acordo com as considerações de design; a plataforma a ser recarregada por último sempre estará em Em espera. 

 VCUBE-1# mostrar o grupo de aplicativos de redundância todos  Estados de falhas Informações do grupo 1:        Prioridade de tempo de execução: [100] estado RG de falhas RG: Para cima.                        Nº total de comovers devido a falhas:  0 n º total de alterações de estado inativo/máximo devido a falhas: 0 ID do Grupo: 1 nome do Grupo: LocalGateway-ha estado administrativo: Nenhum estado operacional agregado de desligamento:  Minha função: Função de pares ativo: Presença de pares em espera : Sim de mesmo nível de comunicação: A pregressão do par Sim foi iniciada: Sim domínio RF: BtoB-um estado RF: Estado RF ativo do peer: Protocolo RG do HOT RG de espera 1------------------função: Negociação ativa: Prioridade ativada: Estado do protocolo 100: Ativo CTRL INTF (s) Estado: Par ativo: Nível de espera local: Endereço 10.1.1.2, prioridade 100, INTF Gi3 contadores do registro:                 alteração de função para ativa: 1 alteração de função para espera: 1 desativar eventos: RG baixo estado 0, RG desligado 0 CTRL INTF eventos: eventos de recarga para cima 1, para baixo 0, admin_down 0: solicitação local 0, contexto de mídia de solicitação de par 0 para RG 1--------------------------estado de CTX: ID do protocolo ativo: 1 tipo de mídia: Interface de controle padrão:  Temporizador de saudação atual do GigabitEthernet3: 3000 timer de saudação configurado: 3000, Temporizador de espera: 10000 cronômetro de saudação de ponto: 3000, temporizador de espera de pares: Estatísticas 10000:             Pacotes 1509, bytes 93558, HA Seq 0, SEQ número 1509, pacotes de perda de PCT 0 não configurada falha de autenticação: 0 recarregar par: TX 0, RX 0 desistir: TX 0, RX 0 par de discagem: Presente. Temporizador de espera: 10000 Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0 VCUBE-1#
 VCUBE-2# show redundância aplicativo group all  Faults states Group 1 info:        Prioridade de tempo de execução: [100] estado RG de falhas RG: Para cima.                        Nº total de comovers devido a falhas:  0 n º total de alterações de estado inativo/máximo devido a falhas: 0 ID do Grupo: 1 nome do Grupo: LocalGateway-ha estado administrativo: Nenhum estado operacional agregado de desligamento: Minha função: Função de pares em espera:  Presença de pares ativo: Sim de mesmo nível de comunicação: A pregressão do par Sim foi iniciada: Sim domínio RF: BtoB-um estado RF: Estado RF ativo do peer: Protocolo RG do HOT RG de espera 1------------------função: Negociação ativa: Prioridade ativada: Estado do protocolo 100: Ativo CTRL INTF (s) Estado: Par ativo: Endereço 10.1.1.2, prioridade 100, INTF Gi3 par em espera: Contadores do Registro local:                 alteração de função para ativa: 1 alteração de função para espera: 1 desativar eventos: RG baixo estado 0, RG desligado 0 CTRL INTF eventos: eventos de recarga para cima 1, para baixo 0, admin_down 0: solicitação local 0, contexto de mídia de solicitação de par 0 para RG 1--------------------------estado de CTX: ID do protocolo ativo: 1 tipo de mídia: Interface de controle padrão:  Temporizador de saudação atual do GigabitEthernet3: 3000 timer de saudação configurado: 3000, Temporizador de espera: 10000 cronômetro de saudação de ponto: 3000, temporizador de espera de pares: Estatísticas 10000:             Pacotes 1509, bytes 93558, HA Seq 0, SEQ número 1509, pacotes de perda de PCT 0 não configurada falha de autenticação: 0 recarregar par: TX 0, RX 0 desistir: TX 0, RX 0 par de discagem: Presente. Temporizador de espera: 10000 
 Pkts 61, Bytes 2074, seq 0 de HA, seqr número 69, perda Pkt 0 
 
 VCUBE-2 #

Configurar um gateway local em ambos os CUBEs

Em nossa configuração de exemplo, estamos usando as seguintes informações de tronco do Control Hub para criar a configuração do Gateway local em ambas as plataformas, VCUBE-1 e VCUBE-2. O nome de usuário e a senha nesta configuração são os seguintes:

  • Nome de usuário: Hussain1076 LGU_

  • Senha: lOV12MEaZx

1

Certifique-se de que uma chave de configuração seja criada para a senha, com os comandos mostrados abaixo, antes que ela possa ser usada nas credenciais ou códigos compartilhados. As senhas do tipo 6 são criptografadas usando a cifra AES e esta chave de configuração definida pelo usuário. 

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

Aqui está a configuração do gateway local que será aplicada a ambas as plataformas com base nos parâmetros do Control Hub exibidos acima, salve e recarregue. As credenciais do SIP Digest do Control Hub são destacadas em bold .

 configure a criptografia terminal 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 Endereço IP Lista confiável ipv4 x.x.x.x y.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:(.*)" "" "" "" rule 13 response ANY sip-header To modify "<sips:(.*)" "<siphussain1076_lgu>" regra 30 solicite QUALQUER sip-header P-Asserted-Identity modifique "sips:(.*)" "sip:\1" classe de voz codec 99 codec preference 1 g711ulaw codec preference 2 g711ulaw exit voice class srtp-crypto 200 crypto 1 AES_CM_128_HMAC_SHA1_80 saída de classe de voz stun-use 200 stun use firewall-traversal flowdata saída de classe de voz inquilino 200 registrador dns:40462196.cisco-bcld.com o esquema sips expira a taxa de atualização de 240 50 tcp tls credenciais de número Hussain5091_LGU nome de usuário Hussain1076_Senha LGU 0 lOV12MEaZx nome de usuário de autenticação do realm Broadworks Hussain5091_LGU senha 0 lOV12MEaZx nome de usuário de autenticação BroadWorks do domínio Hussain5091_LGU senha 0 lOV12MEaZx reino 40462196.cisco-bcld.com nenhum servidor SIP de ID de interlocutor remoto dns:40462196.cisco-bcld.com conexão-reutilização srtp-criptografia 200 transporte de sessão tcp tls url sips error-passthru asserted-id pai vincular interface de origem de controle GigabitEthernet1 vincular interface de fonte de mídia GigabitEthernet1 sem pass-thru conteúdo personalizado-sdp sip-perfis 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 dial-peer de saída para IP PSTN padrão de destino 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-peer 100 dtmf-relay rtp-nte session-peer 200 dtmf-relay voice-class sip tenant 200 dtmf-relay rtp-nte rtp no vad voice class dpg 100 description dial-peer de entrada IP PSTN(DP100) to Webex Calling(DP201) dial-peer 101 preference 1 voice class dpg 200 description dial-peer de entrada IP PSTN (DP100) to Webex Calling(DP201) dial-peer 201 preference 1 dial-peer voice 100 voip destination dpg 200 URI de entrada codec de classe de voz 300 dtmf-relay rtp-nte no vad dial-peer voice-peer 300 dtmf-relay rtp-nte no vad dial-peer voice-peer 300 d

Para exibir a saída do comando show, recarregamos VCUBE-2 seguido por VCUBE-1, tornando VCUBE-1 o CUBE em espera e VCUBE-2 o CUBE ativo

2

A qualquer momento, apenas uma plataforma manterá um registro ativo como o Gateway local com o Webex Calling Acess SBC. Dê uma olhada na saída dos seguintes comandos show.

show redundancy application group 1

mostrar status de registro SIP-ua 

 VCUBE-1# mostrar grupo de aplicativos de redundância 1  ID do grupo:1 Nome do grupo:LocalGateway-HA Estado administrativo: Nenhum estado operacional agregado de desligamento: Minha função: Função de pares em espera : Presença de pares ativo: Sim de mesmo nível de comunicação: A pregressão do par Sim foi iniciada: Sim domínio RF: BtoB-um estado RF: Estado de RF do HOT peer de espera: ACTIVE VCUBE-1# show sip-ua status de registro  VCUBE-1#

 VCUBE-2# mostrar o grupo de aplicativos de redundância 1  ID do grupo:1 Nome do grupo:LocalGateway-HA Estado administrativo: Nenhum estado operacional agregado de desligamento: Minha função:  Função de pares ativo: STATUS do ponto de presença: Sim de mesmo nível de comunicação: A pregressão do par Sim foi iniciada: Sim domínio RF: BtoB-um estado RF: Estado RF ativo do peer: HOT VCUBE-2 #Mostrar locatário do status do registro SIP-UA : 200 -------------------- Registrar-Índice  1 --------------------- Par de linha expira (seg) sobrevivência reg P-Associ-URI ============================== ========== ========== ============ ========= ============ Hussain5091 _ LGU -1 48 sim normal VCUBE-2#

Na saída acima, você pode ver que VCUBE-2 é o LGW ativo que mantém o registro com o Webex Calling Access SBC, enquanto a saída do "show sip-ua register status" está em branco no VCUBE-1

3

Agora habilite as seguintes depurações no VCUBE-1

 VCUBE-1# debug ccsip não-chamada  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 o failover emitindo o seguinte comando no LGW ativo, o VCUBE-2 neste caso.

 Grupo de recarga do aplicativo de redundância VCUBE-2# 1 auto-

A alternância do LGW ATIVO para EM ESPERA ocorre no seguinte cenário, além do CLI listado acima

  • Quando o roteador ATIVO recarrega

  • Quando o roteador ATIVO é ligado e desligado

  • Quando qualquer interface RG configurada do roteador ATIVO é desligada para a qual o rastreamento está habilitado

5

Verifique se o VCUBE-1 foi registrado no Webex Calling Access SBC. O VCUBE-2 já deve ter recarregado.

  VCUBE-1# show sip-ua status de registro Locatário: 200 -------------------- Registrar-Índice  1 --------------------- Par de linha expira (seg) sobrevida de reg P-Associ-URI ============================== ========== ========== =========================================== ============  Hussain5091 _ LGU -1 56 sim normal  VCUBE-1#

O VCUBE-1 agora é o LGW ativo.

6

Veja o registro de depuração relevante no VCUBE-1 enviando um SIP REGISTER ao Webex Calling VIA o IP virtual e recebendo um 200 OK.

 Registro do VCUBE-1#show Jan 9 18:37:24.769: %RG _ MEDIA-3-TIMEREXPIRED: ID RG 1 Olá Hora expirada. Jan 9 18:37:24.771: %RG _ PROTCOL-5-ROLECHANGE: Alteração da função RG id 1 do modo de espera para Ativo 9 de janeiro 18:37:24.783: %VOICE _ HA-2-SWITCHOVER _ IND: SWITCHOVER, de STANDBY _ HOT ao estado ATIVO. 9 de janeiro 18:37:24.783: //-1/xxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Recebido notificar evento de função ativa 9 de janeiro 18:37:25.758: //-1/xxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Enviado: REGISTRAR sip: 40462196.cisco-bcld.com:5061 SIP/2.0 via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374 De: <sip:Hussain5091 _ LGU@40462196.cisco-bcld.com;otg=hussain1076 _lgu>;tag=8D573-189 a: <sip:Hussain5091 _ LGU@40462196.cisco-bcld.com> Data: Qui, 09 Jan 2020 18:37:24 GMT-ID da chamada: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 User-Agent: Cisco-SIPGateway/IOS-16.12.02 Max-Forwards: 70 timestamp: 1578595044 CSeq: 2 REGISTER Contato: <sip:Hussain5091 _ LGU@198.18.1.228:5061;transport=tls> expira: 240 suportado: Comprimento do conteúdo do caminho: 0 

Jan 9 18:37:25.995: //-1/00000000000/SIP/Msg/ccsipDisplayMsg: Recebido: SIP/2.0 401 não autorizado através de: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742 De: <sip:Hussain5091 _ LGU@40462196.cisco-bcld.com;otg=hussain1076 _lgu>;tag=8D573-189 A: <sip:Hussain5091 _ LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 Data: Qui, 09 Jan 2020 18:37:24 GMT-ID da chamada: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-carimbo de data e hora de FFFFFFFFB5F93B97: 1578595044 CSeq: 2 registrar WWW-Authenticate; DIGEST domínio = "BroadWorks", QoP = "auth", nonce = "BroadWorksXk572qd01Ti58zliBW", Algorithm = Content-Length MD5: 0 

9 de janeiro 18:37:26.000: //-1/xxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Enviado: REGISTRAR SIP: 40462196. Cisco-bcld.com:5061 SIP/2.0 via: SIP/2.0/TLS  198.18.1.228 :5061;branch=z9hG4bK16DC De: <sip:Hussain5091 _ LGU@40462196.cisco-bcld.com;otg=hussain1076 _lgu>;tag=8D573-189 A: <sip:Hussain5091 _ LGU@40462196.cisco-bcld.com> Data: Qui, 09 Jan 2020 18:37:25 GMT-ID da chamada: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 User-Agent: Cisco-SIPGateway/IOS-16.12.02 Max-Forwards: 70 timestamp: 1578595045 CSeq: 3 REGISTER Contato: <sip:Hussain5091 _ LGU@198.18.1.228:5061;transport=tls> expira: 240 suportado: Autorização de caminho: Nome de usuário Digest="Hussain1076 _ LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c54f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algoritthm=MD5,nc=00000001 Comprimento do conteúdo: 0 

Jan 9 18:37:26.190: //1/00000000000/SIP/Msg/ccsipDisplayMsg:  Recebido: SIP/2.0 200 OK  Via: SIP/2.0/TLS  198.18.1.228 :5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742 De: <sip:Hussain5091 _ LGU@40462196.cisco-bcld.com;otg=hussain1076 _lgu>;tag=8D573-189 A: <sip:Hussain5091 _ LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-carimbo de data e hora de FFFFFFFFB5F93B97: 1578595045 CSeq: 3 REGISTER Contato: <sip:Hussain5091 _ LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 Allow-Events: chamada-informações, linha-captura, diálogo, mensagem-resumo, como-Feature-Event, x-broadworks-Hotéis, x-broadworks-Call-Center-status, conteúdo de conferência-comprimento: 0