Fundamentos
Pré-requisitos
Antes de implantar o CUBE HA como um gateway local para o Webex Calling, certifique-se de ter uma compreensão mais profunda dos seguintes conceitos:
Redundância box-to-box da camada 2 com o CUBE Enterprise para um preservação da chamada
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 empresarial do CUBE existente estiver sendo modificada para utilizar também a função de gateway local do Cisco Webex Calling, preste atenção à configuração aplicada para garantir que os fluxos e funcionalidades de chamada existentes não sejam interrompidos e certifique-se de que você esteja aderindo aos requisitos de projeto CUBE HA.
Componentes de hardware e software
CUBE HA como gateway local exige o IOS-XE versão 16.12.2 ou posterior e é suportado nas seguintes plataformas:
Série ISR4000—4321, 4331, 4351, 4431, 4451, 4461 (IOS-XE 17.2.1r)
Séries CSR1000—vCUBE (configurações 1, 2 e 4 vCPU)
Os comandos e os registros de apresentação neste artigo baseiam-se em uma versão mínima de software do 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:
Séries ISR 4K—https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
CSR 1000v (vCUBE)—https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
Arquitetura preferida da Cisco para Cisco Webex Calling—https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex Calling geral da solução
Cisco Webex Calling é uma oferta de colaboração que fornece alternativa baseada em nuvem para vários locatários ao serviço telefônico PBX no local, com duas PSTN para clientes:
Provedor de serviços PSTN conectado em nuvem
Gateway local
A implantação do Gateway local (representado abaixo) é o foco deste artigo. O gateway local é a opção Trazer PSTN para o Cisco Webex Calling, fornecendo conectividade a um serviço de PSTN cliente. Ele também fornece conectividade para uma implantação de PBX de IP no local, como o Cisco Unified CM. Toda a comunicação para e da nuvem é protegida usando o transporte TLS para SIP e SRTP para mídia.
A figura abaixo exibe uma implantação Webex Calling sistema sem qualquer PBX de IP existente e é aplicável a uma única ou várias implantações de sites. Configuração descrita neste artigo é baseada nesta implantação.
Redundância caixa a caixa da camada 2
A redundância box-to-box do CUBE HA layer 2 usa o protocolo de infraestrutura de Grupo de Redundância (RG) para formar um par de roteadores ativos/em espera. Este par compartilha o mesmo endereço de IP virtual (VIP) em suas respectivas interfaces e trocam continuamente mensagens de status. As informações da sessão do CUBE são retaladas pelo par de roteadores permitindo que o roteador em espera leve todas as responsabilidades de processamento de chamada do CUBE imediatamente se o roteador ativo sair do serviço, resultando em preservação estado da sinalização e da mídia.
A verificação apontando está limitada a chamadas conectadas com pacotes de mídia. As chamadas em trânsito não são marque a consulta (por exemplo, um estado de tentativa ou toque). Neste artigo, CUBE HA irá se referir à Redundância Box-to-box (HA) CUBE High Availability (HA) para redundância preservação da chamada |
A partir do IOS-XE 16.12.2, o CUBE HA pode ser implantado como Gateway local para implantações Cisco Webex Calling e cobriremos considerações e configurações do projeto neste artigo. Esta figura exibe uma configuração TÍPICA DO CUBE HA como Gateway Local para uma Cisco Webex Calling implantação.
Componente Infra do Grupo de Redundância
O componente Infra do Grupo de Redundância (RG) fornece o suporte à infraestrutura de comunicação box-a-box entre os dois CUBEs e negociará o estado de redundância final estável. Este componente também fornece:
Um protocolo em forma HSRP que negociará o estado de redundância final para cada roteador, trocando mensagens de mantenha-se ativos e olá entre os dois CUBES (através da interface de controle)—GigabitEthernet3 na figura acima.
Um mecanismo de transporte para o controle do estado de sinalização e mídia para cada chamada dos ativos para o roteador de espera (através 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) - GigabitEthernet 1 e 2 são considerados interfaces de tráfego.
Este componente RG tem que ser configurado especificamente para suportar ha de voz B2B.
Gerenciamento de endereços IP virtual (VIP) para sinalização e mídia
A HA B2B depende do VIP para alcançar a redundância. As interfaces físicas VIP e associadas em ambos OS CUBEs no par HA do CUBE devem residir na mesma sub-rede LAN. A configuração do VIP e a associação da interface VIP para um aplicativo de voz específico (SIP) são obrigatórias para o suporte ha B2B de voz. Dispositivos externos como Unified CM, Webex Calling acesso SBC, provedor de serviços ou proxy, use VIP como endereço de IP de destino para as chamadas que atravessam os roteadores CUBE HA. Portanto, a partir Webex Calling ponto de vista, os pares CUBE HA atua como um único gateway local.
A sinalização de chamadas e as informações da sessão RTP das chamadas estabelecidas são pontos de controle a partir do roteador ativo para o roteador em espera. Quando o roteador Ativo cair, o roteador Em espera assume o controle e continua a encaminhar o fluxo RTP que foi previamente roteado pelo primeiro roteador.
As chamadas em um estado transitório no momento do failover não serão preservadas após a mudança. Por exemplo, chamadas que ainda não estão totalmente estabelecidas ou estão em processo de ser modificadas com uma função de transferência ou espera. As chamadas estabelecidas podem ser desconectadas após a mudança.
Os seguintes requisitos existem para usar o CUBE HA como um gateway local para failover estado de chamadas:
CUBE HA não pode ter TDM ou interfaces analógicos co-localizadas
Gig1 e Gig2 são referidos como interfaces de tráfego (SIP/RTP) e Gig3 é interface de controle/dados do Grupo de redundância (RG)
Não mais do que 2 pares DE CUBE HA podem ser colocados no mesmo domínio da camada 2, um com ID de grupo 1 e o outro com ID de grupo 2. Se configurar 2 pares HA com a mesma ID de grupo, as interfaces de controle RG/dados precisarão pertencer a diferentes domínios da camada 2 (vlan, comutamento separado)
O canal da porta é suportado para as interfaces de controle/dados e tráfego RG
Toda sinalização/mídia é fonte de/para o endereço ip virtual
A qualquer momento, uma plataforma é recarregada em uma relação CUBE-HA, ela sempre inicializa como Modo de espera
O endereço mais baixo para todas as interfaces (Gig1, Gig2, Gig3) deve estar na mesma plataforma
Identificador da interface de redundância, o rii deve ser exclusivo para uma combinação de emparelhamento/interface na mesma camada 2
A configuração no CUBEs deve ser idêntica, incluindo a configuração física e deve estar executando no mesmo tipo de plataforma e da versão IOS-XE
As interfaces de retorno de loop não podem ser usadas como vincular, uma vez que estão sempre atualizadas
As interfaces de múltiplos tráfegos (SIP/RTP) (Gig1, Gig2) requerem o rastreamento da interface para serem configuradas
CUBE-HA não é suportado por uma conexão de cabo remoto para o link de controle/dados RG (Gig3)
Ambas as plataformas devem ser idênticas e estar conectadas através de um Switch físico em todas as interfaces da mesma forma para que a CUBE HA funcione, ou seja, GE0/0/0 de CUBE-1 e CUBE-2 deve terminar no mesmo interruptor e assim por diante.
Não é possível ter WAN encerrado no CUBEs diretamente ou Data HA de um dos lados
Ambos ativos/em espera devem estar no mesmo centro de dados
É obrigatório usar a interface L3 separada para redundância (Controle RG/dados, Gig3). ou seja, a interface usada para o tráfego não pode ser usada para keep infra-calendários e verificação de controle de HA
Após o failover, o CUBE anteriormente ativo passa por uma recarregação pelo design, preservando a sinalização e a mídia
Configurar a redundância em ambos OS CUBEs
Você deve configurar a redundância caixa a caixa 2 em ambos OS CUBEs destinados a ser usados em um par HA para trazer IPs virtuais.
1 | Configure o rastreamento da interface em um nível global para rastrear o status da interface.
ClI da faixa é usada no RG para rastrear o estado da interface do tráfego de voz de modo que a rota ativa terá sua função ativa após a interface do tráfego estar inativa. |
||||||
2 | Configure um RG para uso com VoIP HA no sub-modo de redundância de aplicativos.
Aqui está uma explicação dos campos usados nesta configuração:
|
||||||
3 | Ative a redundância box-to-box para o aplicativo CUBE. Configure o RG a partir da etapa anterior em
redundância-grupo 1 — Adicionar e remover este comando requer umarecarga para que a configuração atualizada entre em vigor. Recarregaremos as plataformas depois que todas as configurações já foram aplicadas. |
||||||
4 | Configure as interfaces Gig1 e Gig2 com seus respectivos IPs virtuais, conforme mostrado abaixo, e aplique o identificador da interface deredundância (rii)
Aqui está uma explicação dos campos usados nesta configuração:
|
||||||
5 | Salve a configuração do primeiro CUBE e recarregue-o. A plataforma para recarregar por último é sempre a de Espera.
Depois que o VCUBE-1 inicializar completamente, salve a configuração do VCUBE-2 e recarregue-o.
|
||||||
6 | Verifique se a configuração box a box está funcionando conforme o esperado. Saída relevante é destacada em negrito. Nós recarregou o VCUBE-2 por último e, de acordo com as considerações do projeto, a plataforma a ser recarregada por último sempre estará em espera.
|
Configurar um gateway local em ambos OS CUBEs
No nosso exemplo de configuração, estamos usando as seguintes informações do Control Hub para construir a configuração do Gateway Local em ambas as plataformas, VCUBE-1 eVCUBE-2. O nome de usuário e a senha para esta configuração são os seguinte:
Nome de usuário: Hussain1076_LGU
Senha: iOV12MEaZx
1 | Certifique-se de que uma chave de configuração seja criada para a senha, com os comandos mostrados abaixo antes de poder ser usado nas credenciais ou na chave compartilhada. As senhas do tipo 6 são criptografadas usando uma codificação AES e essa chave de configuração definida pelo usuário.
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, salvar e recarregar. As credenciais do SIP Digest do Control Hub são realçadas em negrito.
Para exibir a saída do comando, recarregou o VCUBE-2 seguido peloVCUBE-1, tornando o VCUBE-1 o CUBE em espera eVCUBE-2 o CUBE ativo |
2 | A qualquer momento, apenas uma plataforma manterá um registro ativo como o Gateway local com o acesso Webex Calling SBC. Dê uma olhada na saída dos comandos de exibição a seguir. mostrar grupo de aplicativos de redundância 1 mostrar status do registro sip-ua
A partir da saída acima, você pode ver que VCUBE-2 é a ativa LGW mantendo o registro com acesso Webex Calling SBC, enquanto a saída do "mostrar status de registro sip-ua" está em branco no VCUBE-1 |
3 | Agora habilita as seguintes depurações no VCUBE-1
|
4 | Simule o failover em emissão do seguinte comando no LGW ativo, VCUBE-2 neste caso.
Alternar do ATIVO para o LGW EM ESPERA ocorre no seguinte cenário, além do CLI listado acima
|
5 | Verifique se o VCUBE-1 se registrou com Webex Calling acesso A SBC. VCUBE-2 já seria recarregado.
VCUBE-1 agora é o LGW ativo. |
6 | Veja o relevante registro de depuração no VCUBE-1 enviando um SIP REGISTER para Webex Calling VIA IP virtual e recebendo um 200 OK.
|