- Página inicial
- /
- Artigo
Implementar o CUBE de alta disponibilidade como Gateway local
O Gateway local (LGW) é a solução exclusiva para fornecer acesso PSTN local a clientes do Cisco Webex Calling. Este documento o orienta na configuração de um Gateway local usando CUBE de alta disponibilidade, com CUBEs ativos ou em espera para garantir o failover stateful de chamadas ativas.
Princípios básicos
Pré-requisitos
Antes de implantar o Cisco Unified Border Element (CUBE) de alta disponibilidade (HA) como um gateway local do Webex Calling, certifique-se de ter um entendimento aprofundado dos seguintes conceitos:
-
Redundância box-to-box de camada 2 com CUBE Enterprise para preservação de chamadas stateful
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 do CUBE Enterprise estiver sendo modificada para também utilizar 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 aderindo aos requisitos de design do CUBE HA.
Componentes de hardware e software
O CUBE HA como gateway local requer o IOS-XE versão 17.9.1 ou posterior e uma plataforma na qual as funções de CUBE HA e LGW são compatíveis.
Os comandos show e os registros neste artigo são baseados na versão mínima de software do Cisco IOS-XE 17.9.1 implementado em um vCUBE (CSR 8000v).
Material de referência
Aqui estão alguns guias detalhados de configuração do CUBE HA para várias plataformas:
-
Cisco ISR 4K e Cisco Catalyst 8K — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-isr-g3.html
-
CSR 8000v (vCUBE)— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-csr.html
-
Arquitetura preferida da Cisco para o Cisco Webex Calling— https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
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 conectividade com um serviço PSTN de propriedade do cliente. Ele também fornece conectividade para uma implantação de IP PBX local, como o 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 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 do 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 sair de serviço, resultando na preservação stateful da sinalização e da mídia.
A verificação está 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 do CUBE de alta disponibilidade (HA) para preservação de chamadas stateful.
A partir do IOS-XE 17.9.1, O CUBE HA pode ser implantado como um Gateway local para implantações de tronco do Cisco Webex Calling (PSTN com base no local). Este artigo discutirá considerações e configurações de design. A 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 de 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 de 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 consideradas 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 HA depende do VIP para obter redundância. As interfaces VIP e físicas associadas em ambos os CUBEs no par CUBE HA devem residir na mesma sub-rede 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 de 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 roteado 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 estão totalmente estabelecidas ou estão em processo de modificação com uma função de transferência ou espera. As chamadas estabelecidas podem ser desconectadas após a alternância.
Existem os seguintes requisitos para usar o CUBE HA como um gateway local para failover stateful de chamadas:
-
O CUBE HA não pode ter interfaces TDM ou analógicas colocalizadas
-
Gig1 e Gig2 são chamados de 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 de CUBE HA podem ser colocados no mesmo domínio de camada 2, um com ID de grupo 1 e o outro com ID do 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 sempre inicializa como Em espera
-
O endereço inferior de todas as interfaces (Gig1, Gig2, Gig3) deve estar na mesma plataforma
-
O identificador de interface redundante, o RII deve ser exclusivo para 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 tráfego múltiplo (SIP/RTP) (Gig1, Gig2) exigem que o rastreamento de interface seja configurado
-
O CUBE-HA não é suportado por uma conexão de cabo cruzado para o 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 encerrado em CUBEs diretamente ou os dados HA em qualquer um dos lados
-
Ambos os 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 tráfego não pode ser usada para manutenções e pontos de verificação de HA
-
Após o failover, o CUBE anteriormente ativo passa por uma recarga por design, preservando a sinalização e a mídia
Configurar redundância em ambos os CUBEs
Você deve configurar a redundância box-to-box de camada 2 em ambos os CUBEs destinados a serem usados em um par de HA para abrir IPs virtuais.
1 |
Configure o rastreamento de interface em um nível global para rastrear o status da interface.
A CLI de rastreamento é usada 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.
Aqui está uma explicação dos campos usados nesta configuração:
| ||
3 |
Habilite a redundância box-to-box para o aplicativo CUBE. Configure o RG da etapa anterior em
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)
Aqui está uma explicação dos campos usados nesta configuração:
| ||
5 |
Salve a configuração do primeiro CUBE e recarregue-o. A plataforma a ser recarregada por último é sempre a em 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-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 espera. Em seguida, prossiga com a configuração do gateway local (baseada em registro ou baseada em certificado) em ambos os CUBEs de HA. Consulte Configurar gateway local no Cisco IOS XE para Webex Calling. |