Neste artigo
Fundamentos
Configure a redundância em ambos os CUBEs
Implemente a alta disponibilidade do CUBE como gateway local
list-menuNeste artigo
list-menuComentários?

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:

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:

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.

Local Gateway premises-based PSTN deployment

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.

Webex Calling deployment without IP PBX

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.

A typical CUBE HA setup as Local Gateway for a Cisco Webex Calling trunk deployment

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.

A typical CUBE HA setup as Local Gateway for a Cisco Webex Calling trunk deployment

1

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

conf t
 track 1 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit

VCUBE-1#conf t
VCUBE-1(config)#track 1 interface GigabitEthernet1 line-protocol
VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol
VCUBE-1(config-track)#exit
VCUBE-2#conf t
VCUBE-2(config)#track 1 interface GigabitEthernet1 line-protocol
VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol
VCUBE-2(config-track)#exit

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.

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 1
    data GigabitEthernet3
    timers delay 30 reload 60
    track 1 shutdown
    track 2 shutdown
    exit
   protocol 1
    timers hellotime 3 holdtime 10
   exit
  exit
 exit


VCUBE-1(config)#redundancy
VCUBE-1(config-red)#application redundancy
VCUBE-1(config-red-app)#group 1
VCUBE-1(config-red-app-grp)#name LocalGateway-HA
VCUBE-1(config-red-app-grp)#priority 100 failover threshold 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 delay 30 reload 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)#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(config)#

VCUBE-2(config)#redundancy
VCUBE-2(config-red)#application redundancy
VCUBE-2(config-red-app)#group 1
VCUBE-2(config-red-app-grp)#name LocalGateway-HA
VCUBE-2(config-red-app-grp)#priority 100 failover threshold 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 delay 30 reload 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)#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(config)#

Aqui está uma explicação dos campos usados nessa 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 — Entra no modo de configuração do grupo de aplicativos de redundância

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

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

  • temporizadores delay 30 reload 60 — Configura os dois tempos para atraso e recarga

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

    • Recarregar — Esse é o tempo necessário para atrasar a inicialização do grupo RG e a negociação de funções após uma recarga — Padrão 60 segundos. O intervalo é de 0 a 10000 segundos

    • Os temporizadores padrão são recomendados, embora esses temporizadores 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 após o roteamento na rede ter convergido para um ponto estável. Por exemplo, se for observado após o failover que leva até 20 segundos para que o novo STANDBY veja o primeiro pacote RG HELLO do novo ACTIVE, os temporizadores devem ser ajustados para 'timers delay 60 reload 120' para considerar esse atraso.

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

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

  • track — Rastreamento de interfaces por grupo RG

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

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

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

    • Tempo de espera — O intervalo entre o recebimento de uma mensagem de saudação e a presunção de que o roteador de envio falhou. Essa duração deve ser maior do que o hellotime — padrão de 10 segundos. O intervalo é de 750 milissegundos a 255 segundos

      Recomendamos que você configure o temporizador de tempo de espera para ser pelo menos 3 vezes o valor do cronômetro hellotime.

3

Ative a redundância de caixa a caixa para o aplicativo CUBE. Configure o RG a partir da etapa anterior abaixo voice service voip. Isso permite que o aplicativo CUBE controle o processo de redundância.

voice service voip
   redundancy-group 1
   exit

VCUBE-1(config)#voice service voip
VCUBE-1(config-voi-serv)#redundancy-group 1
% Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
VCUBE-1(config-voi-serv)# exit
VCUBE-2(config)#voice service voip
VCUBE-2(config-voi-serv)#redundancy-group 1
% Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
VCUBE-2(config-voi-serv)# exit

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)

VCUBE-1(config)#interface GigabitEthernet1
VCUBE-1(config-if)# redundancy rii 1
VCUBE-1(config-if)# redundancy group 1 ip 198.18.1.228 exclusive
VCUBE-1(config-if)# exit
VCUBE-1(config)#
VCUBE-1(config)#interface GigabitEthernet2
VCUBE-1(config-if)# redundancy rii 2
VCUBE-1(config-if)# redundancy group 1 ip 198.18.133.228 exclusive
VCUBE-1(config-if)# exit
VCUBE-2(config)#interface GigabitEthernet1
VCUBE-2(config-if)# redundancy rii 1
VCUBE-2(config-if)# redundancy group 1 ip 198.18.1.228 exclusive
VCUBE-2(config-if)# exit
VCUBE-2(config)#
VCUBE-2(config)#interface GigabitEthernet2
VCUBE-2(config-if)# redundancy rii 2
VCUBE-2(config-if)# redundancy group 1 ip 198.18.133.228 exclusive
VCUBE-v(config-if)# exit

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

  • redundancy 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 rii ID deve ser usado na interface de cada roteador (ATIVO/STANDBY) que tenha 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 evitar colisões). O comando show redundancy application group all deve indicar as informações locais e de pares corretas.

  • grupo de redundância 1 — Associa a interface ao grupo de redundância criado na Etapa 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 tráfego de voz não pode ser usada 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 Standby.

VCUBE-1#wr
Building configuration...
[OK]
VCUBE-1#reload
Proceed with reload? [confirm]

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

VCUBE-2#wr
Building configuration...
[OK]
VCUBE-2#reload
Proceed with reload? [confirm]
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.


VCUBE-1#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: ACTIVE
Peer Role: STANDBY
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: Local
        Standby Peer: address 10.1.1.2, priority 100, intf Gi3
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-1#

VCUBE-2#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: STANDBY
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: address 10.1.1.2, priority 100, intf Gi3
        Standby Peer: Local
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-2#

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.

Este artigo foi útil?
Este artigo foi útil?