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:

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:

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.

Implantação PSTN com base no local do gateway local

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.

Implantação do Webex Calling sem IP PBX

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.

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.

Uma configuração típica do CUBE HA como Gateway local para uma implantação de tronco Cisco Webex Calling

1

Configure o rastreamento de interface em um 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

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.

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 nesta configuração:

  • redundancy—Entra no modo de redundância

  • application redundancy—Entra no modo de configuração de redundância do aplicativo

  • grupo—Entra no modo de configuração de grupo de aplicativos de redundância

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

  • priority 100 failover threshold 75—Especifica a prioridade inicial e os limites de failover para um RG

  • Timers delay 30 reload 60—Configura as duas vezes para atraso e reload

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

    • Recarregar — Esta é a quantidade de tempo para atrasar a inicialização do grupo RG e a negociação da função após um recarregamento – Padrão de 60 segundos. O intervalo é de 0 a 10000 segundos

    • 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/recarregamento 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 visto após o failover que o novo EM ESPERA leva até 20 segundos para ver o primeiro pacote RG HELLO do novo ATIVO, os temporizadores deverão ser ajustados para "temporizadores de atraso 60 recarregamento 120" para considerar esse atraso.

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

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

  • rastrear—Rastreamento de interfaces de grupo RG

  • protocol 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 aplicativos de redundância

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

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

    • Holdtime — O intervalo entre o recebimento de uma mensagem Hello e a presunção de que o roteador de envio falhou. Essa duração deve ser maior que o tempo de olá – Padrão de 10 segundos. O intervalo é de 750 milissegundos a 255 segundos

      Recomendamos que você configure o temporizador de holdtime para ser pelo menos 3 vezes o valor do temporizador de hellotime.

3

Habilite a redundância box-to-box para o aplicativo CUBE. Configure o RG da etapa anterior em 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 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)

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 nesta configuração:

  • redundancy rii—Configura o identificador de 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/EM ESPERA) que tenha o mesmo VIP.

    Se houver mais de um par B2B na mesma LAN, cada par DEVERÁ ter IDs de RII exclusivas em suas respectivas interfaces (para evitar a colisão). O comando mostrar grupo de aplicativos de redundância todos deve indicar as informações corretas locais e pares.

  • redundância grupo 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 esta 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 em espera.

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 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. 


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, 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.