Fundamentos

Pré-requisitos

Antes de implantar a HA do cubo como um gateway local para Webex Calling, certifique-se de que você tenha uma compreensão profunda 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 de um cubo corporativo existente estiver sendo modificado para também utilizar a função de gateway local para Cisco Webex Calling, preste muita atenção à configuração aplicada para garantir que os fluxos de chamada e funcionalidades existentes não sejam interrompidos e certifique-se de que esteja cumprindo os requisitos de design de HA de cubo.

Componentes de hardware e software

A HA do cubo como gateway local requer IOS-XE versão 16.12.2 ou posterior e é suportada nas seguintes plataformas:

  • Série ISR4000 — 4321, 4331, 4351, 4431, 4451, 4461 (IOS-XE 17.2.1 r)

  • Série CSR1000 — vCUBE (1, 2 e 4 vCPU configurações)

Os comandos show e logs neste artigo baseiam-se em uma versão mínima do software do Cisco IOS-XE 16.12.2 implementada em um vCUBE (CSR1000v).

Material de referência

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

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

Cisco Webex Calling é uma oferta de colaboração que fornece alternativa baseada em nuvem de vários locatários para o serviço de telefone PBX no local com duas opções de PSTN para clientes:

  • Provedor de PSTN conectado em nuvem
  • Gateway local

A implantação do gateway local (representada abaixo) é o foco deste artigo. Gateway local é a opção traga sua própria PSTN para Cisco Webex Calling fornecendo conectividade a um serviço de PSTN de Propriedade do cliente. Ele também fornece conectividade a uma implantação de PBX IP no local, como Cisco Unified CM. Toda a comunicação de e para a nuvem é protegida usando o transporte TLS para SIP e SRTP para mídia.

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

Redundância na caixa de entrada de camada 2

A redundância da caixa-a-entrada do cubo da camada 2 usa o protocolo de infraestrutura do grupo de redundância (RG) para formar um par ativo/standby de roteadores. Este par compartilha o mesmo endereço de IP virtual (VIP) em suas respectivas interfaces e troca contínua de mensagens de status. As informações da sessão de cubo são verificadas ao longo do par de roteadores, permitindo que o roteador standby leve todas as responsabilidades de processamento de chamadas de cubo imediatamente se o roteador ativo sair do serviço, resultando na preservação stateful de sinalização e mídia.


A opção marcar como apontador é limitada a chamadas conectadas com pacotes de mídia. As chamadas em trânsito não são verificadas (por exemplo, um estado de experimentação ou de toque).

Neste artigo, a HA do cubo fará referência à redundância de caixa de entrada (B2B) da camada 2 do cubo de alta disponibilidade para preservação da chamada stateful

A partir do IOS-XE 16.12.2, o CUBE HA pode ser implantado como gateway local para Cisco Webex Calling implantações e cobriremos as considerações de design e configurações neste artigo. Esta figura exibe uma configuração típica de HA de cubo como gateway local para uma implantação de Cisco Webex Calling.

Componente de infra-estrutura de grupo de redundância

O componente de infra-estrutura de grupo de redundância (RG) fornece suporte à infraestrutura de comunicação de caixa de entrada entre os dois cubos e negocia o estado final de redundância estável. Este componente também fornece:

  • Um protocolo semelhante ao HSRP que negocia o estado de redundância final para cada roteador, trocando KeepAlive e mensagens de saudação entre os dois cubos (através da interface de controle) — GigabitEthernet3 na figura acima.

  • Um mecanismo de transporte para fazer o ponto de verificação do estado de sinalização e de mídia para cada chamada do roteador ativo para o standby (através da interface de dados) — GigabitEthernet3 na figura acima.

  • Configuração e gerenciamento da interface de 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 tem que ser configurado especificamente para suportar a HA B2B de voz.

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

A B2B de alta disponibilidade depende do VIP para obter redundância. O VIP e as interfaces físicas associadas em ambos os cubos no par do cubo HA devem residir na mesma sub-rede da LAN. A configuração do VIP e a associação da interface VIP a um aplicativo de voz específico (SIP) são obrigatórias para suporte a ligação de voz Dispositivos externos, como Unified CM, Webex Calling Access SBC, provedor de serviços ou proxy, usam VIP como o endereço de IP de destino para as chamadas atravessando os roteadores HA do cubo. Portanto, a partir de um ponto de vista de Webex Calling, os pares de CUBOs HA atuam como um único gateway local.

A sinalização de chamadas e as informações da sessão RTP de chamadas estabelecidas são verificadas do roteador ativo para o roteador standby. Quando o roteador ativo for desligado, o roteador standby assumirá e continuará a encaminhar o fluxo RTP que foi previamente circulado 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, as chamadas que ainda não foram totalmente estabelecidas ou estão em processo de modificação com uma função de transferência ou de espera. As chamadas estabelecidas podem ser desconectadas após a alternância.

Os seguintes requisitos existem para usar a HA do cubo como um gateway local para o failover stateful de chamadas:

  • A HA do cubo não pode ter interfaces de TDM ou analógicas colocalizadas

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

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

  • O canal de porta é suportado para o controle RG/dados e interfaces de tráfego

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

  • A qualquer momento em que uma plataforma é recarregada em uma relação de cubo-HA, ela sempre Inicializa como standby

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

  • Identificador de interface de redundância, o RII deve ser exclusivo para uma combinação de par/interface na mesma camada 2

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

  • As interfaces de auto-retorno não podem ser usadas como BIND porque estão sempre ativas

  • Interfaces de múltiplos tráfego (SIP/RTP) (Gig1, Gig2) exigem que o rastreamento de interface seja configurado

  • CUBE-HA não é suportado através de uma conexão de cabo crossover para o RG-controle/link de dados (Gig3)

  • As duas plataformas devem ser idênticas e conectadas por meio de um comutador físico em todas as interfaces da mesma forma que a ha do cubo funciona, ou seja, GE0/0/0 de Cube-1 e Cube-2 devem terminar no mesmo switch e assim por diante.

  • Não é possível ter o WAN encerrado nos cubos diretamente ou no data HA em nenhum dos lados

  • Ativo/standby deve estar no mesmo centro de dados

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

  • Após o failover, o cubo ativo anteriormente passará por uma recarga por design, preservando a sinalização e a mídia

Configurar a redundância em ambos os cubos

Você deve configurar a redundância da caixa de entrada da camada 2 em ambos os cubos que devem ser usados em um par de HA para abrir o IPs virtual.

1

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

conf a interface t Track 1 GigabitEthernet1 line-Protocol Track 2 interface GigabitEthernet2 de linha-protocolo saída
VCUBE-1 # conf t
VCUBE-1 (config) #Track 1 interface GigabitEthernet1-protocolo de linha
VCUBE-1 (config-Track) #Track 2 interface GigabitEthernet2 line-Protocol
VCUBE-1 (config-Track) #sair
 
VCUBE-2 # conf t
VCUBE-2 (config) #Track 1 interface GigabitEthernet1-protocolo de linha
VCUBE-2 (config-Track) #Track 2 interface GigabitEthernet2 line-Protocol
VCUBE-2 (config-Track) #sair

A Control ILC é usada no RG para rastrear o estado da interface de tráfego de voz para que a rota ativa seja completamente sua função de atividade depois que a interface de tráfego estiver inativa.

2

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

redundância aplicativo redundância grupo 1 nome LocalGateway-prioridade de HA 100 limite de failover 75 controle GigabitEthernet3 protocolo 1 dados GigabitEthernet3 temporizadores atraso 30 recarregar 60 Track 1 Shutdown Track 2 desligamento saída protocolo 1 cronômetros hellotime 3 holdtime 10 sair sair
VCUBE-1 (config) #redundância
VCUBE-1 (config-Red) #redundância de aplicativos
VCUBE-1 (config-Red-app) #grupo 1
VCUBE-1 (config-Red-app-GRP) #Name LocalGateway-ha
VCUBE-1 (config-Red-app-GRP) #priority 100 Threshold de failover 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 demora 30 recarregar 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) #protocolo 1
VCUBE-1 (config-Red-app-prtcl) #cronômetros Olá a 3 holdtime 10
VCUBE-1 (config-Red-app-prtcl) #Exit
VCUBE-1 (config-Red-app) #Exit
VCUBE-1 (config-vermelho) #sair
VCUBE-1 (config) #
 
VCUBE-2 (config) #redundância
VCUBE-2 (config-Red) #redundância de aplicativo
VCUBE-2 (config-Red-app) #grupo 1
VCUBE-2 (config-Red-app-GRP) #Name LocalGateway-ha
VCUBE-2 (config-Red-app-GRP) #priority 100 Threshold de failover 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 demora 30 recarregar 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) #protocolo 1
VCUBE-2 (config-Red-app-prtcl) #cronômetros Olá a 3 holdtime 10
VCUBE-2 (config-Red-app-prtcl) #sair
VCUBE-2 (config-Red-app) #Exit
VCUBE-2 (config-vermelho) #sair
VCUBE-2 (config) #

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

  • grupo— insere o modo de configuração do grupo de aplicativos de redundância

  • nome LocalGateway-HA— define o nome do grupo RG

  • prioridade 100 limite de failover 75— especifica a prioridade inicial e os limites de failover para um RG

  • Os cronômetros atrasam 30 recarregar 60— configura as duas vezes para atrasar e recarregar

    • Cronômetro de retardo, que é o tempo para atrasar a inicialização e a negociação de funções do grupo RG depois que a interface é exibida – padrão 30 segundos. A faixa é de 0-10000 segundos

    • Recarregar — essa é a quantidade de tempo para atrasar a inicialização do grupo RG e a negociação de função após uma recarga – padrão de 60 segundos. A faixa é de 0-10000 segundos

    • Os cronômetros padrão são recomendados, embora esses cronômetros possam ser ajustados para acomodar qualquer atraso adicional de convergência de rede que possa ocorrer durante a inicialização/recarga dos roteadores, a fim de garantir que a negociação do protocolo RG ocorra depois que o roteamento na rede tiver convergido para um ponto estável. Por exemplo, se for visto após o failover que leva até 20 s para o novo STANDBY para ver o primeiro pacote de SAUDAção RG a partir do novo ativo, então os cronômetros devem ser ajustados para ' timers Delay 60 reload 120 ' para fatorar neste atraso.

  • Control GigabitEthernet3 Protocol 1— configura a interface usada para trocar peratividade e mensagens de saudação entre os dois cubos e especifica a ocorrência de protocolo que será anexada a uma interface de controle e insere o modo de configuração do protocolo de aplicação de redundância

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

  • faixa— controle RG sobre o grupo de interfaces

  • Protocolo 1— especifica a ocorrência de protocolo que será anexada a uma interface de controle e insere o modo de configuração do protocolo de aplicação de redundância

  • cronômetros de saudação 3 holdtime 10— configura os dois cronômetros para hellotime e holdtime:

    • Hellotime — intervalo entre mensagens sucessivas de saudação-padrão de 3 segundos. A faixa é de 250 milissegundos-254 segundos

    • Holdtime — o intervalo entre o recebimento de uma mensagem de saudação e a pretomada que o roteador de envio falhou. Esta duração deve ser maior do que o tempo de saudação-padrão de 10 segundos. A faixa é de 750 milissegundos-255 segundos

      Recomendamos que você configure o cronômetro de holdtime para ser pelo menos 3 vezes o valor do cronômetro de saudação.
3

Habilite a redundância de caixas a caixa para o aplicativo de cubo. Configure o RG a partir da etapa anterior em VoIP do serviço de voz. Isso permite que o aplicativo de cubo controle o processo de redundância. 

redundância VoIP do serviço de voz-grupo 1 sair
VCUBE-1 (config) #Voice Service VoIP
VCUBE-1 (config-voi-serv) #redundância-grupo 1
% Criou RG 1 associatiation com voz B2B do Voice; Recarregue o roteador para que a nova configuração tenha efeito
VCUBE-1 (config-voi-serv) # sair
 
VCUBE-2 (config) #Voice Service VoIP
VCUBE-2 (config-voi-serv) #redundância-grupo 1
% Criou RG 1 associatiation com voz B2B do Voice; Recarregue o roteador para que a nova configuração tenha efeito
VCUBE-2 (config-voi-serv) # sair

redundância-grupo 1— Adicionar e remover este comando requer uma recarga para que a configuração atualizada entre em vigor. Recarregaremos as plataformas depois que toda a configuração tiver sido aplicada.

4

Configurar as interfaces Gig1 e Gig2 com seus respectivos IPs virtuais, conforme mostrado abaixo e aplicar o identificador de interface de redundância (RII) 

VCUBE-1 (config) #interface GigabitEthernet1
VCUBE-1 (config-se) # redundância RII 1
VCUBE-1 (config-se) # redundância grupo 1 IP 198.18.1.228 exclusiva
VCUBE-1 (configuração) # sair
VCUBE-1 (config) #
VCUBE-1 (config) #interface GigabitEthernet2
VCUBE-1 (config-se) # redundância RII 2
VCUBE-1 (config-se) # redundância grupo 1 IP 198.18.133.228 exclusiva
VCUBE-1 (configuração) # sair
 
VCUBE-2 (config) #interface GigabitEthernet1
VCUBE-2 (config-se) # redundância RII 1
VCUBE-2 (config-se) # redundância grupo 1 IP 198.18.1.228 exclusiva
VCUBE-2 (config-se) # sair
VCUBE-2 (config) #
VCUBE-2 (config) #interface GigabitEthernet2
VCUBE-2 (config-se) # redundância RII 2
VCUBE-2 (config-se) # redundância grupo 1 IP 198.18.133.228 exclusiva
VCUBE-v (config-se) # sair

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

  • redundância RII— configura o identificador da interface de redundância para o grupo de redundância. Necessário para gerar um endereço MAC virtual (VMAC). O mesmo valor de ID de RII deve ser usado na interface de cada roteador (ativo/STANDBY) que tem o mesmo VIP.


     

    Se houver mais de um par B2B na mesma LAN, cada par deve ter IDs RII exclusivos em suas respectivas interfaces (para impedir a colisão). ' Mostrar grupo de aplicativos de redundância ' todos ' deve indicar as informações corretas locais e de mesmo nível.

  • redundância grupo 1— associa a interface com o grupo de redundância criado no passo 2 acima. Configure o grupo RG, bem como o VIP atribuído a essa interface física.


     

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

5

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

A plataforma a ser carregada por último é sempre o standby.

VCUBE-1 #WR
Criando configuração...
Ok
VCUBE-1 #recarregar
Continuar com a recarga? se

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

VCUBE-2 #WR
Criando configuração...
Ok
VCUBE-2 #recarregar
Continuar com a recarga? se
6

Verifique se a configuração de caixa a caixa está funcionando conforme o esperado. A saída relevante é realçada em negrito.

Recarregamos o VCUBE-2 por último e de acordo com as considerações de design; a plataforma para recarregar a última vez será sempre em espera. 

VCUBE-1 #Mostrar redundância grupo de aplicativos todas as falhas Estados do grupo 1 informações: Prioridade de tempo de execução: [100] estado RG de falhas RG: Disca. N º total de comutadores 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 ativo: 1 alteração de função para espera: 1 desativar eventos: RG baixo estado 0, RG desligado 0 CTRL INTF eventos: 1, para baixo 0, admin_down 0 recarregar eventos: 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 do peer Hold: 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. Timer de espera: 10000 pacotes 61, bytes 2074, HA Seq 0, SEQ número 69, perda de PKT 0 VCUBE-1 #
VCUBE-2 #Mostrar redundância grupo de aplicativos todas as falhas Estados do grupo 1 informações: Prioridade de tempo de execução: [100] estado RG de falhas RG: Disca. N º total de comutadores 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 ativo: 1 alteração de função para espera: 1 desativar eventos: RG baixo estado 0, RG desligado 0 CTRL INTF eventos: 1, para baixo 0, admin_down 0 recarregar eventos: 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 do peer Hold: 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. Timer de espera: 10000 pacotes 61, bytes 2074, HA Seq 0, SEQ número 69, perda de PKT 0 VCUBE-2 #

Configurar um gateway local em ambos os cubos

Na nossa configuração de exemplo, estamos usando as seguintes informações do Webex Control Hub para criar a configuração do gateway local nas duas plataformas, VCUBE-1 e VCUBE-2. O nome de usuário e a senha para esta configuração são os seguintes:

  • Nome de usuário: Hussain1076_LGU

  • Senha: lOV12MEaZx

1

Certifique-se de que uma chave mestre esteja pré-configurada para a senha com os comandos mostrados abaixo antes de poder ser usado nas credenciais ou segredos compartilhados. As senhas de tipo 6 são criptografadas usando a codificação AES e a chave mestra definida pelo usuário. 

LocalGateway # conf t LocalGateway (config) #chave config-Key password-Encrypt Password123 LocalGateway (config) #criptografia de senha 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 de síntese do SIP do Control Jub são realçadas em negrito. 

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 85.119.56.128 255.255.255.192 ipv4 85.119.57.128 255.255.255.192 ipv4 185.115.196.0 255.255.255.128 ipv4 185.115.197.0 255.255.255.128 ipv4 199.59.64.0 255.255.255.128 ipv4 199.59.65.0 255.255.255.128 ipv4 199.59.66.0 255.255.255.128 ipv4 199.59.67.0 255.255.255.128 ipv4 199.59.70.0 255.255.255.128 ipv4 199.59.71.0 255.255.255.128 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 "<sip:(.*)" "<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 codec preference 3 g729r8 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:1a01.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 exibir a saída do comando show, recarregamos o VCUBE-2 seguido por VCUBE-1, fazendo VCUBE-1 o cubo standby e VCUBE-2 o cubo ativo

2

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

Mostrar redundância grupo de aplicativos 1

mostrar o status do registro SIP-UA

VCUBE-1 #Mostrar redundância grupo de aplicativo 1 ID do Grupo: 1 nome do Grupo: LocalGateway-estado administrativo de ha: Nenhum estado operacional agregado de desligamento: a 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: VCUBE ativo-1 #Mostrar status do registro SIP-UA VCUBE-1 #
VCUBE-2 #Mostrar redundância grupo de aplicativo 1 ID do Grupo: 1 nome do Grupo: LocalGateway-estado administrativo de ha: Nenhum estado operacional agregado de desligamento: a 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---------------------o peer da linha expira (seg) reg sobrevivência P-Associ-URI = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =-1 48 yes normal VCUBE-2 Hussain5091_LGU #

Da saída acima, você pode ver que VCUBE-2 é o ativo LGW manter o registro com 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 o rastreamento fora de chamada de entrada SIP está habilitado VCUBE-1 #debug ccsip info informações de chamada SIP o rastreamento está ativado VCUBE-1 #debug ccsip Message
4

Simule o failover emitindo o seguinte comando no Active LGW, VCUBE-2 neste caso.

VCUBE-2 #aplicativo de redundância recarrega o grupo 1

A alternância do ativo para o LGW em STANDBY ocorre no cenário a seguir, bem como na CLI listada acima

  • Quando o roteador ativo é recarregado
  • Quando os ciclos de energia do roteador ativo
  • Quando qualquer interface de RG configurada do roteador ativo é desligada para a qual o rastreamento está habilitado
5

Verifique se VCUBE-1 se registrou com Webex Calling Access SBC. VCUBE-2 teria recarregado agora.

VCUBE-1 #Mostrar locatário do status do registro SIP-UA: 200--------------------registrar-índice 1---------------------o peer da linha expira (seg) reg sobrevivência P-Associ-URI = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =- 1 56 Yes normal VCUBE -1 Hussain5091_LGU #

VCUBE-1 agora é o LGW ativo.
6

Verifique o registro de depuração relevante no VCUBE-1 enviando um registro SIP para Webex Calling através do IP virtual e recebendo um 200 OK. 

VCUBE-1 # Exibir registro 9 de janeiro de 18:37:24.769: % RG_MEDIA -3-TIMEREXPIRED: O tempo de saudação da ID RG 1 expirou. 9 de janeiro de 18:37:24.771: % RG_PROTCOL -5-ROLECHANGE: ID RG 1 alterar a função de standby para ativo 9 Jan 18:37:24.783: % VOICE_HA-2-SWITCHOVER_IND: COMUTAção, de STANDBY_HOT para estado ativo. 9 de janeiro de 18:37:24.783: -1/xxxxxxxxxxxx/SIP/info/info/4096/sip_ha_notify_active_role_event: Recebida notificação do evento de função ativo em 9 de janeiro de 18:37:25.758: -1/xxxxxxxxxxxx/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: <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 registrar contato: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expira: 240 suportado: Comprimento do conteúdo do caminho: 0
9 de janeiro de 18:37:25.995: -1/000000000000/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: <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 de 18:37:26.000: -1/xxxxxxxxxxxx/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: <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 registrar contato: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expira: 240 suportado: Autorização de caminho: 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
9 de janeiro de 18:37:26.190: 1/000000000000/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: <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 registrar contato: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>; expira = 120; q = 1,25 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