- Página inicial
- /
- Artigo
O Local Gateway (LGW) é a solução exclusiva para fornecer acesso PSTN local aos clientes Cisco Webex Calling. Este documento orienta você na configuração de um gateway local usando a alta disponibilidade do CUBE, com CUBes ativos ou em espera para garantir o failover contínuo das chamadas ativas.
Fundamentos
Pré-requisitos
Antes de implantar Cisco Unified Border Element a Alta Disponibilidade (HA) do (CUBE) como um gateway local paraWebex Calling, certifique-se de ter uma compreensão profunda dos seguintes conceitos:
-
Redundância de caixa a caixa de camada 2 com CUBE Enterprise para preservação de chamadas com estado
As diretrizes de configuração fornecidas neste artigo pressupõem uma plataforma de gateway local dedicada sem nenhuma configuração de voz existente. Se uma implantação corporativa existente do CUBE estiver sendo modificada para também utilizar a função de gateway localCisco Webex Calling, preste muita atenção à configuração aplicada para garantir que os fluxos de chamadas e as funcionalidades existentes não sejam interrompidos e verifique se você está cumprindo os requisitos de design do CUBE HA.
Componentes de hardware e software
O CUBE HA como gateway local requer a versão 17.9.1 ou posterior do IOS-XE e uma plataforma na qual as funções CUBE HA e LGW sejam suportadas.
Os comandos e registros show neste artigo são baseados na versão mínima de software do Cisco IOS -XE 17.9.1 implementada em um vCube (CSR 8000v).
Material de referência
Aqui estão alguns guias de configuração detalhados do CUBE HA para várias plataformas:
-
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 CallingVisão geral da solução
Cisco Webex Callingé uma oferta de colaboração que fornece uma alternativa multilocatária baseada em nuvem ao serviço telefônico PBX local com várias opções de PSTN para os clientes.
A implantação do Local Gateway (representada abaixo) é o foco deste artigo. A entrada de tronco do gateway local (PSTN baseada no local) Webex Calling permite a conectividade com um serviço PSTN de propriedade do cliente. Ele também fornece conectividade a uma implantação de PBX IP local, como. Cisco Unified CM Toda a comunicação de e para a nuvem é protegida usando transporte TLS para SIP e SRTP para mídia.
A figura abaixo mostra uma Webex Calling implantação sem nenhum PBX IP existente e é aplicável a uma implantação em um único local ou em vários locais. A configuração descrita neste artigo é baseada nessa implantação.
Redundância caixa a caixa de camada 2
A redundância caixa a caixa da camada 2 do CUBE HA usa o protocolo de infraestrutura de Grupo de Redundância (RG) para formar um par de roteadores ativo/em espera. Esse 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 do CUBE são verificadas no par de roteadores, permitindo que o roteador em espera assuma imediatamente todas as responsabilidades de processamento de chamadas do CUBE se o roteador ativo sair de serviço, resultando na preservação contínua da sinalização e da mídia.
O apontamento de verificação é limitado às chamadas conectadas com pacotes de mídia. As chamadas em trânsito não são verificadas (por exemplo, um estado de alerta ou de toque).
Neste artigo, CUBE HA se referirá à redundância de caixa a caixa (B2B) de camada 2 do CUBE High Availability (HA) para preservação de chamadas com estado.
A partir do IOS-XE 17.9.1, o CUBE HA pode ser implantado como um gateway local para implantações de Cisco Webex Calling tronco (PSTN baseado no local). Este artigo discutirá as considerações e configurações de design. A figura mostra uma configuração típica do CUBE HA como gateway local para uma implantação de Cisco Webex Calling tronco.
Componente infravermelho do grupo de redundância
O componente Redundancy Group (RG) Infra fornece suporte à infraestrutura de comunicação box-to-box entre os dois CUBEs e negocia o estado final de redundância estável. Esse componente também fornece:
-
Um protocolo semelhante ao HSRP que negocia o estado final de redundância de cada roteador trocando mensagens de manutenção de vida e saudação 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 para 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) — GigabitEthernet 1 e 2 são consideradas interfaces de tráfego.
Esse componente RG deve ser configurado especificamente para suportar voz B2B HA.
Gerenciamento de endereços IP virtuais (VIP) para sinalização e mídia
O B2B HA depende do VIP para obter redundância. O VIP e as interfaces físicas associadas em ambos os CUBEs no par CUBE HA devem residir na mesma sub-rede de LAN. A configuração do VIP e a vinculação da interface VIP a um aplicativo de voz específico (SIP) são obrigatórias para o suporte de voz B2B HA. Dispositivos externosUnified CM, Webex Calling como SBC, provedor de serviços ou proxy, usam VIP como endereço IP de destino para as chamadas que passam pelos roteadores CUBE HA. Portanto, do Webex Calling ponto de vista, os pares CUBE HA atuam como um único gateway local.
A sinalização de chamada 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 fica inativo, o roteador em espera assume o controle e continua a encaminhar 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 transição. 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 retenção. As chamadas estabelecidas podem ser desconectadas após a transição.
Existem os seguintes requisitos para usar o CUBE HA como um gateway local para o failover de chamadas com status:
-
O CUBE HA não pode ter interfaces TDM ou analógicas co-localizadas
-
Gig1 e Gig2 são chamadas de interfaces de tráfego (SIP/RTP) e Gig3 é interface de controle/dados de grupo de redundância (RG)
-
Não mais do que 2 pares CUBE HA podem ser colocados no mesmo domínio de camada 2, um com id de grupo 1 e outro com id de grupo 2. Se configurar 2 pares HA com o mesmo ID de grupo, as interfaces RG Control/Data precisam pertencer a diferentes domínios de camada 2 (vlan, switch separado)
-
O canal portuário é suportado para interfaces de controle/dados e tráfego RG
-
Toda sinalização/mídia é originada de/para o endereço IP virtual
-
Sempre que uma plataforma é recarregada em um relacionamento CUBE-HA, ela sempre é inicializada como Standby
-
O endereço inferior de todas as interfaces (Gig1, Gig2, Gig3) deve estar na mesma plataforma
-
O identificador de interface de redundância, rii deve ser exclusivo para uma combinação de pares/interface na mesma camada 2
-
A configuração em ambos os CUBEs deve ser idêntica, incluindo a configuração física, e deve ser executada no mesmo tipo de plataforma e versão IOS-XE
-
As interfaces de loopback não podem ser usadas como vinculativas, pois estão sempre ativas
-
Várias interfaces de tráfego (SIP/RTP) (Gig1, Gig2) exigem que o rastreamento de interface seja configurado
-
O CUBE-HA não é suportado por meio de uma conexão de cabo cruzado para o RG-Control/Data Link (Gig3)
-
Ambas as plataformas devem ser idênticas e conectadas por meio de um Switch físico em todas as interfaces iguais 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.
-
Não é possível ter a WAN terminada diretamente no CUBEs ou o Data HA em nenhum dos lados
-
Tanto o Active/Standby devem estar no mesmo data center
-
É obrigatório usar uma interface L3 separada para redundância (RG Control/Data, Gig3). Ou seja, a interface usada para tráfego não pode ser usada para keepalives e checkpoints de HA
-
Após o failover, o CUBE anteriormente ativo passa por uma recarga por design, preservando a sinalização e a mídia
Configure a redundância em ambos os CUBEs
Você deve configurar a redundância caixa a caixa da camada 2 em ambos os CUBEs destinados a serem usados em um par HA para ativar IPs virtuais.
| 1 |
Configure o rastreamento da interface em nível global para rastrear o status da interface.
O Track CLI é usado no RG para rastrear o estado da interface de tráfego de voz, de forma que a rota ativa mantenha sua função ativa após a interface de tráfego ficar inativa. | ||
| 2 |
Configure um RG para uso com VoIP HA no submodo de redundância de aplicativos.
Aqui está uma explicação dos campos usados nessa configuração:
| ||
| 3 |
Ative a redundância de caixa a caixa para o aplicativo CUBE. Configure o RG a partir da etapa anterior abaixo
redundancy-group 1 — Adicionar e remover esse comando requer uma recarga para que a configuração atualizada tenha efeito. Vamos recarregar 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 de redundância (rii)
Aqui está uma explicação dos campos usados nessa configuração:
| ||
| 5 |
Salve a configuração do primeiro CUBE e recarregue-o. A plataforma a ser recarregada por último é sempre a Standby.
Depois que o VCUBE-1 inicializar completamente, salve a configuração do VCUBE-2 e recarregue-o.
| ||
| 6 |
Verifique se a configuração de caixa a caixa 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, continue com a configuração do gateway local (baseada em registro ou baseada em certificado) em ambos os HA CUBes. Consulte Configurar o gateway local no Cisco IOS XE para Webex Calling. |