Voz e comunicações unificadas : Cisco Unified Border Element

Alta disponibilidade do Cisco Unified Border Element (HA) que usa o exemplo da configuração de HSRP

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

O Cisco Unified Border Element (CUBE) fornece alta disponibilidade (HA) através das configurações de redundância de caixa para caixa quando implementado em uma plataforma Cisco Integrated Services Router Generation 2 Router (ISR G2). CUBE a redundância de caixa a caixa leverages a tecnologia roteador-baseada disponível longa do roteador do protocolo de roteamento do standby recente (HSRP).

A tecnologia HSRP fornece a alta disponibilidade de rede distribuindo o tráfego IP dos anfitriões em redes sem confiar na Disponibilidade de todo o roteador único. O HSRP é usado em um grupo de Roteadores selecionando um roteador ativo e um roteador em standby. O HSRP monitora ambas as interfaces internas e externas – se qualquer relação vai para baixo, o dispositivo inteiro está considerado para baixo, o dispositivo à espera torna-se ativo e toma-se sobre as responsabilidades do roteador ativo.

A redundância de caixa a caixa usa o protocolo de HSRP para formar par ativo/à espera HSRP de Roteadores. Pares ativos/à espera compartilham do mesmo endereço IP de Um ou Mais Servidores Cisco ICM NT virtual e trocam continuamente mensagens de status. A informação de sessão do CUBO é checkpointed através pares ativos/à espera de Roteadores. Isto permite o roteador em standby de tomar imediatamente sobre todas as responsabilidades do Processamento de chamadas do CUBO se o roteador ativo for fora de serviço para de planeamento ou motivos não planejados.

A aplicação da redundância de caixa a caixa HA do CUBO apoia a preservação dos media sobre um switchover HSRP de atendimentos SIP-SIP, mas nenhuma sinalização de chamada é preservada. Esta capacidade é apoiada até à data do Software Release 15.1.2T de Cisco IOS�. A preservação da sinalização de chamada é apoiada no Cisco IOS Software Release 15.2.3T o mais atrasado.

Nota: Para mais informação, refira características do protocolo independente do Cisco Unified Border Element e Setup o manual de configuração, o Cisco IOS Release 15.2M&T.

Pré-requisitos

Requisitos

Certifique-se de atender a estes requisitos antes de tentar esta configuração:

  • Conhecimento básico de como configurar e usar a Voz do Cisco IOS

  • Conhecimento básico de como configurar e usar o CUBO

  • Conhecimento básico de como a Alta disponibilidade HSRP trabalha em Plataformas do roteador geral

As requisições básico para estabelecer a redundância de caixa a caixa do CUBO ISR G2 incluem:

  • Dois ISR idêntico G2 equipado com a licença do pacote da tecnologia UC (SL-29-UC-K9 ou SL-39-UC-K9) instalada, a memória DRAM 1G, e o Cisco IOS Software Release 15.1.2T ou Mais Recente

  • Ambo o Roteadores deve fisicamente ser ficado no mesmo LAN de Ethernet.

  • A configuração do CUBO de ambo o Roteadores é idêntica e deve manualmente ser copiada de um roteador ao outro.

  • Um roteador é designado o roteador ativo HSRP, o segundo é o apoio. Há umas pequenas diferenças na configuração de HSRP entre os roteadores ativo e em standby.

  • Fluxos de chamadas SIP-SIP

Componentes Utilizados

A informação neste documento é baseada em um lançamento mínimo de software do CUBO 8.5 (Cisco IOS Release 15.1.2T), executado em uma geração 2 do roteador do serviço integrado do Cisco ou Series (ISR G2).

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Informações de Apoio

A redundância de caixa a caixa exige duas Plataformas ISR-G2 idênticas: um configurado como o Active, o outro como o apoio. O HSRP é configurado nas interfaces física para formar um grupo HSRP.

Se há uma falha de batimento cardíaco quando o roteador ativo vai para baixo, o segundo roteador em standby toma sobre os endereços de Roteamento IP do primeiro roteador e continua a enviar os mesmos pacotes RTP que foram distribuídos previamente ao primeiro roteador.

Os córregos RTP das chamadas estabelecidas são checkpointed entre os roteadores ativo e em standby através do protocolo de HSRP. Consequentemente os fluxos de mídia das chamadas estabelecidas são preservados sobre o failover de HSRP do Active aos roteadores em standby. Os atendimentos em um estado transitório (os atendimentos que não são estabelecidos ainda, ou são em processo da alteração com uma função de transferência ou da posse) na altura do Failover são desligados. Também, algum chama usando serviços DSP tais como transcoding não é preservado.

Configurar

Nesta seção, você encontrará informações para configurar os recursos descritos neste documento.

A configuração de HSRP do CUBO segue uma ordem específica de etapas, que inclua:

  1. Permita a Redundância do CUBO e do CUBO

  2. Permita o HSRP

  3. Configurar o transporte de uma comunicação HSRP

  4. Configurar o HSRP nas relações

  5. Configurar os temporizadores de HSRP

  6. Configurar o temporizador de inatividade dos media

  7. Configurar o SORVO que liga ao endereço hsrp

  8. Recarregue o Roteadores

  9. Aponte Softswitches anexado ao endereço virtual do CUBO HSRP

Recarregue ambo o Roteadores depois que as etapas 1-5 são terminadas. Um reload é exigido somente quando o HSRP é configurado pela primeira vez em um roteador.

Nota: Use a Command Lookup Tool (somente clientes registrados) para obter mais informações sobre os comandos usados nesta seção.

Diagrama de Rede

Este diagrama mostra a topologia par ativo/à espera de Roteadores ISR G2 usado em um desenvolvimento do tronco do SORVO entre um gerente das comunicações unificadas de Cisco (CUCM) e um tronco do SORVO do provedor de serviços (SP) para o acesso PSTN.

http://www.cisco.com/c/dam/en/us/support/docs/voice-unified-communications/unified-border-element/112095-cube-hsrp-config-01.gif

Passo 1: Permita a Redundância do CUBO e do CUBO

Permita o CUBO em ambo o Roteadores:

voice service voip 
  mode border-element
  allow-connections sip to sip

Permita a Redundância do CUBO e chame o checkpointing em ambo o Roteadores:

voice service voip 
  redundancy

Passo 2: Permita o HSRP

Permita esquemas de redundância de roteador em ambo o Roteadores, onde:

  • esquema – esquema de seguimento do estado de redundância

  • à espera – permita o esquema de seguimento do estado (HSRP) à espera

  • SB – o nome do grupo do standby de HSRP

redundancy inter-device
  scheme standby SB

Passo 3: Configurar o transporte de uma comunicação HSRP

Configurar o transporte de uma comunicação do Inter-dispositivo HSRP como segue:

Configuração ativa:

ipc zone default
  association 1
    no shutdown
    protocol sctp
      local-port 5000
        local-ip 10.10.24.14
      remote-port 5000
        remote-ip 10.10.24.13

Configuração à espera:

ipc zone default
  association 1
   no shutdown
   protocol sctp
     local-port 5000
       local-ip 10.10.24.13
     remote-port 5000
       remote-ip 10.10.24.14

Nota: Retire da alerta “local-SCTP” para configurar os parâmetros remotos SCTP como segue:

XFR-2(config)#ipc zone default
XFR-2(config-ipczone)#association 1
XFR-2(config-ipczone-assoc)#protocol sctp 
XFR-2(config-ipc-protocol-sctp)#no sh
XFR-2(config-ipczone-assoc)#protocol sctp
XFR-2(config-ipc-protocol-sctp)#local-port 5000
XFR-2(config-ipc-local-sctp)#local-ip 10.10.24.13
XFR-2(config-ipc-local-sctp)#exit
XFR-2(config-ipc-protocol-sctp)#remote-port 5000
XFR-2(config-ipc-remote-sctp)#remote-ip 10.10.24.14
XFR-2(config-ipc-remote-sctp)#end

Estas são a explicação dos campos usados nesta configuração:

  • padrão da zona ipc – Configura o protocolo de comunicação do Inter-dispositivo (IPC) e incorpora o modo de configuração da zona IPC. Use este comando iniciar o link de comunicação entre os dispositivos ativos e à espera.

  • associação 1 – Configura uma associação entre os dois dispositivos e incorpora o modo de configuração da associação IPC. Sob isto, configurar os detalhes da associação tais como o protocolo de transporte, a porta local, o endereço IP local, a porta remota e o endereço IP remoto. A associação válida ID varia de 1 a 255. Não há nenhuma associação ID do padrão.

  • nenhuma parada programada – Reinicia uma associação deficiente e seu protocolo de transporte associado. Para todas as mudanças aos parâmetros do protocolo de transporte, esta associação deve ser parada programada.

  • sctp do protocolo – Configura o Stream Control Transmission Protocol (SCTP) como o protocolo de transporte para esta associação e permite o modo da configuração de protocolo SCTP.

  • port_num da porta local – Define o número de porta local SCTP para usar-se para comunicar-se com o par redundante.

  • ip_addr do IP local – Define o endereço IP de Um ou Mais Servidores Cisco ICM NT do roteador local para usar-se para comunicar-se com o par redundante. O endereço IP local deve combinar o endereço IP remoto no roteador redundante.

  • port_num da porta remota – Define o número de porta remoto SCTP para usar-se para comunicar-se com o par redundante.

  • ip_addr do IP remoto – Define o endereço IP remoto do roteador de peer usado para comunicar-se com o dispositivo local. Todos os endereços IP remotos devem apontar ao mesmo dispositivo.

Nota: A porta local e a porta remota devem ser ajustadas a 5000 nos roteadores ativo e em standby.

Passo 4: Configurar o HSRP nas relações

Configurar o transporte de uma comunicação do Inter-dispositivo HSRP como segue:

Configuração ativa

interface GigabitEthernet0/0
  ip address 10.10.25.14 255.255.255.0
  duplex auto
  keepalive
  speed auto
  standby delay minimum 30 reload 60
  standby version 2
  standby 0 ip 10.10.25.1
  standby 0 preempt
  standby 0 priority 50
  standby 0 track 2 decrement 10 
  standby 0 name SB
     bfd interval 500 min_rx 500 multiplier 3
!
interface GigabitEthernet0/1
  ip address 10.10.24.14 255.255.255.0
  duplex auto
  speed auto
  media-type rj45
  standby delay minimum 30 reload 60
  standby version 2
  standby 6 ip 10.10.24.1
  standby 6 priority 50
  standby 6 track 1 decrement 10
     bfd interval 500 min_rx 500 multiplier 3

Configuração à espera

interface GigabitEthernet0/0
  ip address 10.10.25.13 255.255.255.0
  duplex auto
  speed auto
  keepalive
  standby delay minimum 30 reload 60
  standby version 2
  standby 0 ip 10.10.25.1
  standby 0 preempt
  standby 0 priority 50
  standby 0 name SB
		standby 0 track 2 decrement 10
     bfd interval 500 min_rx 500 multiplier 3
!
interface GigabitEthernet0/1
  ip address 10.10.24.13 255.255.255.0
  duplex auto
  speed auto
  media-type rj45
  standby delay minimum 30 reload 60
  standby version 2
  standby 6 ip 10.10.24.1
  standby 6 priority 50
		standby 6 preempt		  standby 6 track 1 decrement 10
     bfd interval 500 min_rx 500 multiplier 3

Esta é uma explicação dos campos usados nesta configuração:

  • 0/6 – Define o número de grupo de standby.

  • keepalive – Permite o keepalive para que o HSRP monitore eventos up/down.

  • atraso à espera – Atrasa a iniciação HSRP até que a interface física esteja acima.

  • x à espera IP – Define o endereço IP de Um ou Mais Servidores Cisco ICM NT virtual do IPv4 compartilhado entre os dispositivos ativos e à espera. Este comando permite o HSRP na relação.

  • x à espera cancela – Permite que o roteador transforme-se o roteador ativo quando a prioridade é mais alta do que todo Roteadores HSRP-configurado restante no grupo do standby recente. Se você não usa o comando standby preempt na configuração para um roteador, esse roteador não se transforma o roteador ativo, mesmo se a prioridade é mais alta do que todo Roteadores restante.

  • prioridade à espera x – Define a prioridade do standby recente usada em escolher o roteador ativo. Varia de 1 a 255 onde 1 denota a mais baixa prioridade e 255 a prioridade mais alta.

    Nota: Nos casos onde a prioridade em standby é a mesma, o dispositivo com o endereço IP de Um ou Mais Servidores Cisco ICM NT mais alto supõe o papel do roteador ativo.

  • nome à espera x – Define o nome do grupo de standby que combina o esquema definido em etapa 2 (“SB "). Para grupos hsrp múltiplos, o mesmo nome à espera é usado enquanto somente um esquema à espera é permitido nas configurações.

  • 6 decréscimo à espera 10 da trilha 1 – Define o seguimento da prioridade. Para obter mais informações sobre do acompanhamento de interface, clique aqui.

  • o multiplicador 3 do min_rx 500 do intervalo 500 do bfd – define a detecção bidirecional da transmissão.

Para evitar races condition quando um roteador carreg acima e uma relação vem estabelece até o contato (“olá! ") entre os roteadores ativo e em standby, igualmente recomenda-se configurar o seguinte:

interface GigabitEthernet0/0
  standby delay minimum 30 reload 60

Para obter mais informações sobre deste comando, clique aqui.

Passo 5: Configurar os temporizadores de HSRP

Há dois temporizadores de HSRP importantes:

  • Olá! temporizador: O intervalo entre mensagens de saudação de HSRP sucessivas de um determinado roteador. Este temporizador pode ser configurado nos segundos ou nos milissegundos sob a relação HSRP. O valor padrão é 3 segundos.

  • Temporizador da posse: O intervalo entre o recebimento de uma mensagem de saudação e a suposição de que o roteador de envio falhou. Esta vez pode ser configurada nos segundos ou nos milissegundos sob a relação HSRP. O valor padrão é 8 segundos.

Nas configurações em etapa 4, o HSRP hello e os temporizadores da posse são ajustados a seus valores padrão. Consequentemente, não aparecem explicitamente nas configurações. Os valores recomendados para olá!/temporizadores da posse são os valores padrão.

Nota: Se você usar valores fora de padrão, você deve configurar cada roteador para usar o mesmo tempo de hello e para guardar valores de temporizador.

Os temporizadores de saudação e de espera podem ser configurados sob a relação HSRP usando o seguinte CLI:

Router(config-if)#standby 0 timers ?
  <1-254>  Hello interval in seconds
  msec     Specify hello interval in milliseconds

Router (config-if)#standby 0 timers 2 ?
  <3-255>  Hold time in seconds
  msec     Specify hold interval in milliseconds
Router(config-if)#standby 0 timers 2 msec 40

Na configuração precedente, olá! o temporizador é ajustado a 2 segundos e ao temporizador da posse a 40 milissegundos.

Nota: Você pode abaixar as configurações de temporizador para acelerar o Failover ou a preempção. Contudo, para evitar o uso aumentado CPU e o estado à espera desnecessário que batem, recomenda-se não ajustar olá! o temporizador em menos de 1 segundo, e o temporizador da posse em menos de 4 segundos.

Passo 6: Configurar o temporizador de inatividade dos media

O temporizador de inatividade dos media permite os pares do Active/roteador em standby de monitorar e desligar atendimentos se nenhum pacote do Real-Time Protocol (RTP) é recebido dentro de um período de tempo configurável.

Quando os pacotes RTP para um atendimento não são recebidos pelo Active/roteador em standby, o temporizador de inatividade dos media do SORVO libera a sessão. Isto é usado para guardar contra todas as sessões suspensas que possam ter resultado do Failover caso uma disconexão da chamada normal fizesse não claro o atendimento.

A mesma duração para o temporizador de inatividade dos media deve ser configurada em ambo o Roteadores. O valor padrão é 28 segundos. Este temporizador é configurado como segue:

ip rtcp report interval 3000
gateway
  media-inactivity-criteria all
  timer receive-rtp 86400
  timer receive-rtcp 5

Passo 7: Configurar o SORVO que liga ao endereço hsrp

Configurar a Mensagem do SORVO do CUBO para usar o endereço virtual HSRP na Mensagem do SORVO.

dial-peer voice 100 voip
  description to-SIP
  voice-class sip bind control source-interface GigabitEthernet0/0
  voice-class sip bind media source-interface GigabitEthernet0/0  
!
dial-peer voice 200 voip
  description to-CUCM
  voice-class sip bind control source-interface GigabitEthernet0/1
  voice-class sip bind media source-interface GigabitEthernet0/1

Uma vez que o HSRP está configurado sob a interface física e o comando bind esteve emitido, os atendimentos ao endereço IP de Um ou Mais Servidores Cisco ICM NT físico falharão. Isto é porque o soquete de escuta do SORVO é limitado agora ao endereço IP de Um ou Mais Servidores Cisco ICM NT virtual mas os pacotes da sinalização usam o endereço IP de Um ou Mais Servidores Cisco ICM NT físico, e não pode consequentemente ser segurado.

Passo 8: Recarregue o Roteadores

Uma vez que todas as configurações acima foram terminadas, a saída da mostra da Redundância é como segue:

XFR-2#show redundancy inter-device
Redundancy inter-device state: RF_INTERDEV_STATE_INIT
  Pending Scheme: Standby (Will not take effect until next reload)
      Pending Groupname: b2bha
  Scheme: <NOT CONFIGURED>
  Peer present: UNKNOWN
  Security: Not configured

Em cima de recarregar o roteador a configuração de HSRP é permitida como segue:

roteador ativo

XFR-2#show redundancy inter-device
Redundancy inter-device state: RF_INTERDEV_STATE_ACT
  Scheme: Standby
      Groupname: b2bha Group State: Active
  Peer present: RF_INTERDEV_PEER_COMM
  Security: Not configured

roteador de standby

CUBE_XFR#show redundancy inter-device
Redundancy inter-device state: RF_INTERDEV_STATE_STDBY
  Scheme: Standby
      Groupname: b2bha Group State: Standby
  Peer present: RF_INTERDEV_PEER_COMM
  Security: Not configured

Etapa 9: Softswitches anexado ponto ao endereço virtual do CUBO HSRP

Os SBCs do proxy CUCM, IP-PBX, de SORVO ou SP ou os softswitches SP que distribuem atendimentos PARA CUBAR devem usar o endereço virtual HSRP em sua Mensagem do SORVO. As mensagens do SORVO aos endereços IP de Um ou Mais Servidores Cisco ICM NT físicos do CUBO não são seguradas com uma configuração de HSRP.

As configurações de amostra completas para o dual anexo CUBAM a Redundância HSRP

Estão aqui as configurações de amostra completas para o Roteadores ativo e à espera do CUBO. Nestas configurações, os temporizadores do HSRP hello e da posse usam seus valores padrão de 3 e 8 segundos respectivamente, e não são mostrados explicitamente na saída CLI.

Configuração do roteador ativo

ipc zone default
  association 1
    no shutdown
    protocol sctp
      local-port 5000
        local-ip 10.10.24.14
      remote-port 5000
        remote-ip 10.10.24.13
!
voice service voip
  mode border-element
  allow-connections sip to sip
  redundancy
!
redundancy inter-device
  scheme standby SB
!
redundancy
!
interface GigabitEthernet0/0
  ip address 10.10.25.14 255.255.255.0
  duplex auto
  keepalive
  speed auto
  standby delay minimum 30 reload 60
  standby version 2
  standby 0 ip 10.10.25.1
   standby 0 preempt
  standby 0 priority 50
  standby 0 track 2 decrement 10 
  standby 0 name SB
     bfd interval 500 min_rx 500 multiplier 3
!
interface GigabitEthernet0/1
  ip address 10.10.24.14 255.255.255.0
  duplex auto
  speed auto
  media-type rj45
  standby delay minimum 30 reload 60
  standby version 2
  standby 6 ip 10.10.24.1
  standby 6 priority 50
  standby 6 track 1 decrement 10
     bfd interval 500 min_rx 500 multiplier 3
!
ip rtcp report interval 3000
!
track 1 interface GigabitEthernet0/0 line-protocol 
!
track 2 interface GigabitEthernet0/1 line-protocol  
!
dial-peer voice 100 voip
  description to-SIP
  destination-pattern 9T
  session protocol sipv2
  session target ipv4:x.x.x.x
  voice-class sip bind control source-interface GigabitEthernet0/0
  voice-class sip bind media source-interface GigabitEthernet0/0  
!
dial-peer voice 200 voip
  description to-CUCM
  destination-pattern 555....
  session protocol sipv2
  session target ipv4:y.y.y.y
  voice-class sip bind control source-interface GigabitEthernet0/1
  voice-class sip bind media source-interface GigabitEthernet0/1
!
gateway 
  media-inactivity-criteria all
  timer receive-rtcp 5
  timer receive-rtp 1200

Configuração do roteador em standby

ipc zone default
  association 1
    no shutdown
    protocol sctp
      local-port 5000
        local-ip 10.10.24.13
      remote-port 5000
        remote-ip 10.10.24.14
!
voice service voip
  mode border-element
  allow-connections sip to sip
  redundancy
!
redundancy inter-device
  scheme standby SB
!
redundancy
!
interface GigabitEthernet0/0
  ip address 10.10.25.13 255.255.255.0
  duplex auto
  keepalive
  speed auto
  standby delay minimum 30 reload 60
  standby version 2
  standby 0 ip 10.10.25.1
  standby 0 preempt
  standby 0 priority 50
  standby 0 name SB
		standby 0 track 2 decrement 10
     bfd interval 500 min_rx 500 multiplier 3
!
interface GigabitEthernet0/1
  ip address 10.10.24.13 255.255.255.0
  duplex auto
  speed auto
  media-type rj45
  standby delay minimum 30 reload 60
  standby version 2
  standby 6 ip 10.10.24.1
  standby 6 priority 50
		standby 6 preempt
  standby 6 track 1 decrement 10
     bfd interval 500 min_rx 500 multiplier 3
!
ip rtcp report interval 3000
!
track 1 interface GigabitEthernet0/0 line-protocol 
!
track 2 interface GigabitEthernet0/1 line-protocol  
!
dial-peer voice 100 voip
  description to-SIP
  destination-pattern 9T
  session protocol sipv2
  session target ipv4:x.x.x.x
  voice-class sip bind control source-interface GigabitEthernet0/0
  voice-class sip bind media source-interface GigabitEthernet0/0  
!
dial-peer voice 200 voip
  description to-CUCM
  destination-pattern 555....
  session protocol sipv2
  session target ipv4:y.y.y.y
  voice-class sip bind control source-interface GigabitEthernet0/1
  voice-class sip bind media source-interface GigabitEthernet0/1
!
gateway 
  media-inactivity-criteria all
  timer receive-rtcp 5
  timer receive-rtp 1200

Configuração de exemplo completa para a Redundância Único-anexada do CUBO HSRP

Quando um CUBO do dual anexo for a maioria de configuração comum, especialmente para conexões de tronco do SORVO SP, é igualmente possível configurar a redundância de caixa a caixa do CUBO HSRP com um desenvolvimento único-anexado do CUBO como dada nesta seção.

Configuração do roteador ativo

ipc zone default
  association 1
    no shutdown
    protocol sctp
      local-port 5000
       local-ip 1.2.175.8
     remote-port 5000
       remote-ip 1.2.175.12
!
voice service voip
  mode border-element
  allow-connections sip to sip
  redundancy
  sip
    bind control source-interface GigabitEthernet0/0
    bind media source-interface GigabitEthernet0/0
!
redundancy inter-device
 scheme standby SB
!
redundancy
!
interface GigabitEthernet0/0
  ip address 1.2.175.8 255.255.0.0
  duplex auto
  speed auto
  keepalive
  standby delay minimum 30 reload 60
  standby version 2
  standby 0 ip 1.2.175.100
 standby 0 preempt
  standby 0 priority 50
  standby 0 name SB
  standby 0 track 1 decrement 10
  bfd interval 500 min_rx 500 multiplier 3
!
ip rtcp report interval 3000 
!
dial-peer voice 5 voip
  description to-SIP-application
  destination-pattern 9T
  session protocol sipv2
  session target ipv4:x.x.x.x
!
dial-peer voice 9 voip
  description to-CUCM
  destination-pattern 555....
  session protocol sipv2
  session target ipv4:y.y.y.y
!
gateway 
 media-inactivity-criteria all
 timer receive-rtcp 5
 timer receive-rtp 1200

Configuração do roteador em standby

ipc zone default
  association 1
    no shutdown
    protocol sctp
      local-port 5000
       local-ip 1.2.175.12
     remote-port 5000
       remote-ip 1.2.175.8
!
voice service voip
  mode border-element
  allow-connections sip to sip
  redundancy
  sip
    bind control source-interface GigabitEthernet0/0
    bind media source-interface GigabitEthernet0/0
!
redundancy inter-device
 scheme standby SB
!
redundancy
!
interface GigabitEthernet0/0
  ip address 1.2.175.12 255.255.0.0
  duplex auto
  speed auto
  standby delay minimum 30 reload 60
  standby version 2
  standby 0 ip 1.2.175.100
  standby 0 priority 50
		standby 0 preempt
  standby 0 name SB
  standby 0 track 1 decrement 10
  bfd interval 500 min_rx 500 multiplier 3
!
ip rtcp report interval 3000 
!
dial-peer voice 5 voip
  description to-SIP-application
  destination-pattern 9T
  session protocol sipv2
  session target ipv4:x.x.x.x
!
dial-peer voice 9 voip
  description to-CUCM
  destination-pattern 555....
  session protocol sipv2
  session target ipv4:y.y.y.y
!
gateway 
 media-inactivity-criteria all
 timer receive-rtcp 5
 timer receive-rtp 1200

Removendo as configurações HA

Termine estas etapas a fim remover uma configuração de HSRP previamente incorporada de um roteador do CUBO:

  1. Remova a configuração de redundância do nível do aplicativo.

    Router(config)#voice service voip 
    Router(config-voice service voip)#no redundancy
  2. Remova o esquema à espera configurado sob o modo de configuração do inter-dispositivo.

    Router(config)#redundancy inter-device 
    Router(config-red-interdevice)#no scheme standby b2bha
    % Redundancy interdevice scheme change will not take effect until 
    configuration is saved and device reloaded
  3. Salvar as alterações de configuração à memória e recarregue o roteador.

    Router(config)#write
    Router#reload
  4. Depois que o reload, emite este comando se certificar do HSRP estivesse desabilitado:

    Router#show redundancy inter-device
    Redundancy inter-device state: RF_INTERDEV_STATE_INIT
      Scheme: <NOT CONFIGURED>
      Peer present: UNKNOWN
      Security: Not configured
    
  5. Desabilite a associação entre os dois dispositivos e remova a configuração SCTP.

    Router(config)#ipc zone default
    Router(config-ipczone)#association 1
    Router(config-ipczone-assoc)#shutdown
    Router(config-ipczone-assoc)#no protocol sctp
    Router(config-ipczone-assoc)#no association 1
    Router(config-ipczone)#exit
    Router(config)#no ipc zone default
  6. Remova a configuração de HSRP da relação usando “não” formulários dos comandos HSRP.

    Router(config)#interface gigabitEthernet 0/0
    Router(config-if)#no standby 0 name
    Router(config-if)#no standby 0 priority 
    Router(config-if)#no standby 0 ip
  7. Salvar alterações de configuração.

    Router(config)#write

Caracterize notas do uso

  • O roteador dois usado para um par HSRP deve ser idêntico (para assegurar o mesmos desempenho e capacidade de chamada em nível).

  • O apoio da configuração da redundância de caixa a caixa em atendimentos SIP-SIP flui, o transporte do SORVO pode ser UDP-UDP ou UDP-TCP

  • Os endereços virtuais HSRP apoiam somente o endereçamento do IPv4.

  • O fluxo de mídia das chamadas estabelecidas é preservado sobre um Failover, mas a sinalização não é. Consequentemente, os atendimentos preservados não podem ser alterados (posse/resumo, transferência, conferência, etc.).

  • Os atendimentos que envolvem serviços suplementares tais como transcoding, DTMF-colaborando, IVR, SIP-TLS, RSVP, ATURDEM, conversão RTP-SRTP, ou o fax/recursos de modem não é preservado em um Failover.

  • Os fluxos de vídeo não são preservados em cima do switchover, embora o fluxo de áudio possa ser preservado.

  • Os grupos hsrp múltiplos pelo roteador são apoiados, mas somente um único grupo HSRP pela interface física.

  • Os endereços de loopback com HSRP não são apoiados, o comando bind do SORVO devem usar o endereço IP de Um ou Mais Servidores Cisco ICM NT virtual HSRP.

  • A sincronização de configuração entre o roteador ativo e em standby não é manual, lá é nenhuma automatização. As alterações de configuração devem ser feitas manualmente a ambo o Roteadores.

Verificar

Use o CLI abaixo para verificar que a configuração de HSRP é correta e trabalhar.

A Output Interpreter Tool (apenas para clientes registrados) (OIT) suporta determinados comandos show. Use a OIT para exibir uma análise da saída do comando show.

Verifique o estado de redundância

Verifique o estado de redundância com o inter-dispositivo da Redundância da mostra e mostre comandos do estado de redundância. Estes comandos show que a informação do inter-dispositivo da Redundância tal como o inter-dispositivo da Redundância indica.

Antes que a configuração do inter-dispositivo esteja feita, a saída da mostra é como segue:

XFR-2#show redundancy inter-device
Redundancy inter-device state: RF_INTERDEV_STATE_PNC_NO_HSRP
Scheme: Standby
Groupname: b2bha Group State: Init
Protocol: <NOT CONFIGURED>

XFR-2#show redundancy states
my state = 3  -NEGOTIATION 
peer state = 1  -DISABLED 
Mode = Simplex
Unit ID = 0

Maintenance Mode = Disabled
Manual Swact = disabled (system is simplex (no peer unit))
Communications = Down      Reason: Simplex mode

client count = 14
client_notification_TMR = 30000 milliseconds
RF debug mask = 0x0

Depois que a configuração do inter-dispositivo é feita mas antes do recarregamento de roteador, a saída da mostra é como segue:

XFR-2#show redundancy inter-device
Redundancy inter-device state: RF_INTERDEV_STATE_INIT
Pending Scheme: Standby (Will not take effect until next reload)
Pending Groupname: b2bha
Scheme: <NOT CONFIGURED>
Peer present: UNKNOWN
Security: Not configured

Após o recarregamento de roteador, a saída da mostra é como segue mostrando o estado de “Init”:

CUBE_XFR#show redundancy inter-device
Redundancy inter-device state: RF_INTERDEV_STATE_PNC_NO_HSRP
Scheme: Standby
Groupname: b2bha Group State: Init
Peer present: UNKNOWN
Security: Not configured

CUBE_XFR#show redundancy states 
my state = 3  -NEGOTIATION 
peer state = 13 -ACTIVE 
Mode = Duplex
Unit ID = 0

Maintenance Mode = Disabled
Manual Swact = disabled (this unit is still initializing)
Communications = Up

client count = 14
client_notification_TMR = 30000 milliseconds
RF debug mask = 0x0

Durante um switchover, por exemplo o roteador ativo está para baixo e quando o roteador em standby comutar a se transformar o Active, a saída da mostra é como segue:

CUBE_XFR#show redundancy inter-device
Redundancy inter-device state: RF_INTERDEV_STATE_ACT
Scheme: Standby
Groupname: b2bha Group State: Active
Peer present: RF_INTERDEV_PEER_NO_COMM
Security: Not configured

XFR-2#show redundancy states
my state = 13 -ACTIVE 
peer state = 1  -DISABLED 
Mode = Simplex
Unit ID = 0

Maintenance Mode = Disabled
Manual Swact = disabled (system is simplex (no peer unit))
Communications = Up

client count = 14
client_notification_TMR = 30000 milliseconds
RF debug mask = 0x0

Após o switchover, mas antes que o Roteadores troque olá! mensagens de status, a saída da mostra é como segue:

CUBE_XFR#show redundancy inter-device
Redundancy inter-device state: RF_INTERDEV_STATE_ACT
Scheme: Standby
Groupname: b2bha Group State: Active
Peer present: RF_INTERDEV_PEER_NO_COMM
Security: Not configured

XFR-2#show redundancy inter-device
Redundancy inter-device state: RF_INTERDEV_STATE_HSRP_STDBY_PNC
Scheme: Standby
Groupname: b2bha Group State: Standby
Peer present: RF_INTERDEV_PEER_NO_COMM
Security: Not configured

Depois que a troca olá! de mensagens de status, a saída da mostra é como segue:

XFR-2#show redundancy inter-device
Redundancy inter-device state: RF_INTERDEV_STATE_ACT
Scheme: Standby
Groupname: b2bha Group State: Active
Peer present: RF_INTERDEV_PEER_COMM
Security: Not configured
  
XFR-2#show redundancy states
my state = 13 -ACTIVE 
peer state = 8  -STANDBY HOT 
Mode = Duplex
Unit ID = 0

Maintenance Mode = Disabled
Manual Swact = disabled (peer unit not yet in terminal standby state)
Communications = Up

client count = 14
client_notification_TMR = 30000 milliseconds
RF debug mask = 0x0  
 
CUBE_XFR#show redundancy inter-device
Redundancy inter-device state: RF_INTERDEV_STATE_STDBY
Scheme: Standby
Groupname: b2bha Group State: Standby
Peer present: RF_INTERDEV_PEER_COMM
Security: Not configured
        
CUBE_XFR#show redundancy states
my state = 8  -STANDBY HOT 
peer state = 13 -ACTIVE 
Mode = Duplex
Unit ID = 0

Maintenance Mode = Disabled
Manual Swact = cannot be initiated from this the standby unit
Communications = Up

client count = 14
client_notification_TMR = 30000 milliseconds
RF debug mask = 0x0

Verifique o estado HSRP

Verifique o estado HSRP com o comando show standby brief. Este comando mostra a breve saída no HSRP que inclui relações HSRP, números de grupo de standby, prioridades, Active e endereços IP em standby assim como endereços IP de Um ou Mais Servidores Cisco ICM NT virtuais. O comando show standby dá o completo, informação detalhada.

Router1#show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active     Standby      Virtual IP
Gi0/0       0    50    Active  local      9.13.25.134  9.13.25.22

Router2#show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active       Standby  Virtual IP
Gi0/0       0    50    Standby 9.13.25.133  local    9.13.25.22

Verifique o estado da chamada após um Switchover

O requisito de alta disponibilidade do comando summary da Voz da mostra é usado para verificar:

  • O checkpointing de chama o roteador em standby após um switchover

  • A contagem da media-inatividade no Active quando os atendimentos se acabarem

  • Para verificar para ver se há (por exemplo, preservado) atendimentos nativos e nonnative quando ambos os tipos de atendimentos estarem presente

  • Para identificar a presença de RTP escapado, HA, sessões SPI

Mostre que o checkpointing de chama o roteador em standby após um switchover

Neste exemplo, 800 atendimentos eram checkpointed de ativo ao apoio após o switchover.

CUBE_XFR#show voice high-availability summary
======== Voice HA DB INFO ========
Number of calls in HA DB: 0
Number of calls in HA sync pending DB: 0
Number of calls in HA preserved session DB: 0

-----------------------------
First a few entries in HA DB:
-----------------------------

---------------------------------------
First a few entries in Sync Pending DB:
---------------------------------------

----------------------------

======== Voice HA Process INFO ========
Active process current tick: 3100
Active process number of tick events pending: 0
Active process number of tick events processed: 0
voice service voip is  configured to have redundancy

======== Voice HA RF INFO ========
Voice HA RF Client Name: VOIP RF CLIENT
Voice HA RF Client ID: 1345
My current rf state STANDBY HOT
Peer current rf state ACTIVE
Voice HA Standby is not available.
System has not experienced switchover.

======== Voice HA CF INFO ========
Voice HA CF Client Name: CHKPT VOIP SYMPHONY
Voice HA CF Client ID: 252
Voice HA CF Client Status: Peer NOT READY; TP flow ON.

======== Voice HA COUNTERS ========
Total number of checkpoint requests sent (Active): 0
Total number of checkpoint requested received (Standby): 971
Total CREATE received on Standby: 800
Total MODIFY received on Standby: 0
Total DELETE received on Standby: 800
Media Inactivity event count: 0

Checkpoint CREATE overflow: 0
Checkpoint MODIFY overflow: 0
Checkpoint DELETE overflow: 0
HA DB elememnt pool overrun count: 0
HA DB aux element pool overrun count: 0
HA DB insertion failure count: 0
HA DB deletion failure count: 0
Tick event pool overrun count: 0
Tick event queue overrun count: 0
Checkpoint send failure count: 0
Checkpoint get buffer failure count: 0

Mostre a contagem da media-inatividade no Active quando os atendimentos se acabam

Neste exemplo, 800 atendimentos são cancelados pelo temporizador da media-inatividade.

XFR-2#show voice high-availability summary
======== Voice HA DB INFO ========
Number of calls in HA DB: 0
Number of calls in HA sync pending DB: 0
Number of calls in HA preserved session DB: 0

-----------------------------
First a few entries in HA DB:
-----------------------------

---------------------------------------
First a few entries in Sync Pending DB:
---------------------------------------

----------------------------

======== Voice HA Process INFO ========
Active process current tick: 4213
Active process number of tick events pending: 0
Active process number of tick events processed: 0
voice service voip is  configured to have redundancy

======== Voice HA RF INFO ========
Voice HA RF Client Name: VOIP RF CLIENT
Voice HA RF Client ID: 1345
My current rf state ACTIVE
Peer current rf state STANDBY HOT
Voice HA Active and Standby are in sync.
System has experienced switchover.

======== Voice HA CF INFO ========
Voice HA CF Client Name: CHKPT VOIP SYMPHONY
Voice HA CF Client ID: 252
Voice HA CF Client Status: Peer READY; TP flow ON.

======== Voice HA COUNTERS ========
Total number of checkpoint requests sent (Active): 971
Total number of checkpoint requested received (Standby): 800
Total CREATE received on Standby: 800
Total MODIFY received on Standby: 0
Total DELETE received on Standby: 0
Media Inactivity event count: 800

Checkpoint CREATE overflow: 0
Checkpoint MODIFY overflow: 0
Checkpoint DELETE overflow: 0
HA DB elememnt pool overrun count: 0
HA DB aux element pool overrun count: 0
HA DB insertion failure count: 0
HA DB deletion failure count: 0
Tick event pool overrun count: 0
Tick event queue overrun count: 0
Checkpoint send failure count: 0
   Checkpoint get buffer failure count: 0

Para verificar para ver se há atendimentos (preservados) nativos e nonnative quando ambos estarem presente

Os números de chamam o sistema são mostrados como segue:

  • Número total de atendimentos = “número de atendimentos no número HA DB " + " de atendimentos na sincronização DB pendente HA”. Este é 100 + 50 pés = 150 nas saídas de exemplo abaixo.

  • O número total de preservado (nonnative) chama = “número de atendimentos na sessão preservada HA DB”. Este é 70 nas saídas de exemplo abaixo.

  • O número total de atendimentos do nativo (atendimentos estabelecidos desde que o Failover e consequentemente não preservados sobre o Failover) é a diferença nos dois números precedentes. Neste exemplo, é 150 – 70 = 80.

XFR-2#show voice high-availability summary
======== Voice HA DB INFO ========
Number of calls in HA DB: 100
Number of calls in HA sync pending DB: 50
Number of calls in HA preserved session DB: 70

Para identificar a presença de RTP escapado, HA, sessões SPI

O número total de atendimentos (nonnative) preservados cancelados pela inatividade dos media é = “total CREATE recebida SUPRESSÃO total no apoio” – “recebida no apoio” como a saída abaixo das mostras. Compare este número com dos “a contagem de evento da inatividade media” assim como o número de eventos dos media para baixo mostrados pela saída do comando stats do fpi do voip da mostra.

XFR-2#show voice high-availability summary
======== Voice HA DB INFO ========
Number of calls in HA DB: 0
Number of calls in HA sync pending DB: 0
Number of calls in HA preserved session DB: 0

======== Voice HA COUNTERS ========
Total number of checkpoint requests sent (Active): 971
Total number of checkpoint requested received (Standby): 800
Total CREATE received on Standby: 800
Total MODIFY received on Standby: 0
Total DELETE received on Standby: 0
Media Inactivity event count: 800

Verifique emperramentos do endereço IP de Um ou Mais Servidores Cisco ICM NT do SORVO

Os indicadores do comando status da mostra sorvo-UA SORVEM estado obrigatório.

Router1#show sip-ua status
SIP User Agent Status
SIP User Agent for UDP : ENABLED
SIP User Agent for TCP : ENABLED

SIP User Agent for TLS over TCP : ENABLED
SIP User Agent bind status(signaling): DISABLED
SIP User Agent bind status(media): DISABLED
Snapshot of SIP listen sockets : 2
            Local Address      Listen Port  Secure Listen Port
=============================  ===========  ==================
 10.10.25.14                     5060         5061
 10.10.24.14                     5060         5061
SIP early-media for 180 responses with SDP: ENABLED
SIP max-forwards : 70

Verifique o uso atual CPU

O comando history processador central do processo da mostra é usado verificar em intervalos regulares a porcentagem da utilização CPU.

Verifique a utilização CPU antes de executar um switchover e continue com um Failover forçado somente quando a utilização CPU é menos de 70%. O comando classificado processador central do processo da mostra pode igualmente ser emitido repetidamente para obter uma ideia da utilização CPU para um processo particular.

Verifique que os atendimentos estão sendo processados durante um Switchover

O comando statistics da mostra sorvo-UA é usado verificar gotas do atendimento durante o switchover verificando o número de mensagens do ADEUS. Os atendimentos em andamento durante o switchover são deixados cair. Somente as chamadas estabelecidas são preservadas.

O comando de contabilidade da relação da mostra é usado verificar a confirmação do trajeto dos media durante um switchover.

Router#show interfaces g0/0 accounting
GigabitEthernet0/0 
Protocol  Pkts In   Chars In   Pkts Out   Chars Out
Other     1         58         6          360
IP        406       178841     201        16394
ARP       569       34292      0          0
CDP       116       31672      22         7304

Verifique IP “pacotes em” e os “pacotes para fora” opõem-se – estes devem aumentar em uma taxa razoável. Por exemplo, se você não está usando o empacotamento de G.711 20ms e o nenhum VAD, você deve ver os contadores de pacote de informação aumentar em torno de 50 pés cada segundo.

Forçando um failover manual para testar

A redundância de caixa a caixa que usa o HSRP apoia um switchover do media-stateful dos atendimentos que signifique que o media (RTP) dos atendimentos está preservado, mas não a sinalização. Consequentemente, somente os atendimentos no estado ativo (trajeto dos media no modo de conexão do “sendrecv”) estão preservados quando os atendimentos no estado transitório (estado, trajeto NON-ativos dos media não no modo de conexão do “sendrecv”) não forem preservados durante o switchover.

Os Switchovers que ocorrem nos ambientes reais onde há uns atendimentos constantes de uma mistura no transeunte (configuração de chamada ou sendo alterado) e no estado estabelecido, lá serão sempre um determinado número de atendimentos deixados cair durante um Failover. O número total de chamadas descartada esperadas pode ser calculado por: (0.3 + posse-temporizador HSRP) * CP.

Termine o procedimento abaixo para forçar um switchover manual a certificar-se da configuração e a operação estejam corretas.

Para assegurar o switchover obrigatório liso, faça o seguinte:

  • Monitore a utilização CPU % pares ativos/à espera. O Active terá uma utilização CPU mais alta como está segurando ativamente os atendimentos, quando o apoio mostrará 0 utilizações CPU porque é quietude até que um switchover ocorra.

  • Assegure-se de que um switchover manual esteja executado quando a utilização CPU do roteador ativo for não mais de 70%. Todos os switchovers conduzem a um ponto na utilização CPU.

  • Use o requisito de alta disponibilidade dos comandos summary da Voz da conexão e da mostra do rtp do voip da mostra certificar-se de chamadas existentes ter sido sincronizado através dos pares do Active/roteador em standby.

Um switchover HSRP envolve anteriormente o roteador ativo que recarrega, quando anteriormente o roteador em standby tomar sobre e se transformar o roteador ativo novo que processa atendimentos novos e que mantém os fluxos de mídia para atendimentos preservados até que estejam completos. O roteador ativo novo permanecerá como o roteador ativo até que um outro switchover ocorra.

Os switchovers (forçados) manuais podem ser conseguidos em qualquer destas maneiras:

  • Inicie-o pelo CLI da “força da interruptor-atividade Redundância” no roteador ativo.

  • Reload do roteador ativo

  • Reinício duro do roteador ativo

  • Retire a relação HSRP ou o cabo de potência do roteador ativo.

  • Parada programada a relação HSRP do roteador ativo.

  • Uma mudança em todo o parâmetro da relação HSRP do Active/roteador em standby sem fechar a associação sob o modo IPC conduz a um recarregamento de roteador. Consequentemente, a relação deve ser parada programada antes que todas as mudanças estejam feitas, a menos que você estiver usando este como um disparador para forçar um switchover.

O comando show voip rtp connections mostra o número de conexões ativa em ambos os roteadores ativo e em standby após um switchover.

O comando show call ative voice brief não mostra nenhuma saída no roteador em standby após um switchover porque a informação de sinalização não é checkpointed.

Etapas para executar e verificar um único Switchover

Conclua estes passos:

  1. Configurar a redundância de caixa a caixa HSRP conforme a seção configurar neste documento.

  2. Recarregue e mantenha ambo o Roteadores no rommon.

  3. Carreg acima de um roteador. Depois que está acima, emita o comando do estado de redundância da mostra e certifique-se que mostra meu estado como o estado do Active e do par como enfermos. Isto pode pegar um quando após a bota.

    XFR-2#show redundancy states
    my state = 13 -ACTIVE 
    peer state = 1  -DISABLED
  4. Bota acima do segundo roteador. Depois que está acima, emita o comando do estado de redundância da mostra certificar-se que mostra meu estado como o estado À espera-quente e do par como o Active.

    CUBE_XFR#show redundancy states
    my state = 8  -STANDBY HOT 
    peer state = 13 -ACTIVE
  5. Comece uns ou vários atendimentos através do sistema. Emita o requisito de alta disponibilidade do sumário da Voz da mostra e os comandos connection do rtp do voip da mostra em ambos os roteadores ativo e em standby certificar-se dos atendimentos são ascendentes e checkpointed.

  6. Teste o switchover recarregando o roteador ativo. Se você está usando um telefone para fazer atendimentos, você pode escutar o telefone para certificar-se que trajeto do media está preservado. Se você está usando o equipamento de teste, você pode usar os indicadores do pacote para determinar se os media para os atendimentos estão fluindo:

    Router#show interfaces g0/0 accounting
    GigabitEthernet0/0 
    Protocol  Pkts In   Chars In   Pkts Out   Chars Out
    Other     1         58         6          360
    IP        406       178841     201        16394
    ARP       569       34292      0          0
    CDP       116       31672      22         7304
  7. Inatividade dos media de teste: Pare o atendimento. Repita a conexão do rtp do voip da mostra. Após a expiração de temporizador da media-inatividade, não deve haver não mais conexão RTP ativa. Você pode igualmente verificar este através do requisito de alta disponibilidade do comando summary da Voz da mostra e procurá-lo:

    Router#show voice high-availability summary | include media
    Media Inactivity event count: 1

    A contagem de evento da inatividade dos media deve mostrar 1.

Screenshots para verificar um único atendimento preservado sobre um Failover

O indicador antes do Failover:

  • Roteador ativo (#01)

    http://www.cisco.com/c/dam/en/us/support/docs/voice-unified-communications/unified-border-element/112095-cube-hsrp-config-02.gif

  • Roteador em standby (#02)

    http://www.cisco.com/c/dam/en/us/support/docs/voice-unified-communications/unified-border-element/112095-cube-hsrp-config-03.gif

Recarregando o roteador ativo (#01) para forçar um Failover:

http://www.cisco.com/c/dam/en/us/support/docs/voice-unified-communications/unified-border-element/112095-cube-hsrp-config-04.gif

O roteador em standby (#02) toma sobre como o Active novo, o atendimento é preservado (apoio = Active novo):

http://www.cisco.com/c/dam/en/us/support/docs/voice-unified-communications/unified-border-element/112095-cube-hsrp-config-05.gif

Previamente os reloads do roteador ativo (#01) como o roteador em standby novo, e o atendimento são preservados no apoio novo.

  • Roteador (#01) à espera novo:

    http://www.cisco.com/c/dam/en/us/support/docs/voice-unified-communications/unified-border-element/112095-cube-hsrp-config-06.gif

  • Roteador (#02) ativo novo:

    http://www.cisco.com/c/dam/en/us/support/docs/voice-unified-communications/unified-border-element/112095-cube-hsrp-config-07.gif

Troubleshooting

Esta seção fornece informações que podem ser usadas para o troubleshooting da sua configuração.

Nota: Consulte Informações Importantes sobre Comandos de Depuração antes de usar comandos debug.

Estes comandos show and debug são úteis durante o Troubleshooting da redundância de caixa a caixa:

show redundancy state
show redundancy inter-device
show standby brief
show standby internal
show sip-ua status
show sip-ua statistics
show voice high-availability summary
show voip rtp connection | include connection
show arp
debug voip ccapi all
debug voip ccapi error
debug voip rtp session
debug voip rtcp session
debug voip rtp error
debug voip rtcp error
debug voice high-availability all
debug voice high-availability error
debug ccsip info
debug ccsip messages
debug ccsip media
debug ccsip error
debug standby terse

Nota: Não gire sobre um grande número debuga em um sistema que leva um volume alto do tráfego da chamada ativa.

Nota: Em cada switchover, após o recarregamento de roteador, debuga deve re-ser permitido no roteador em standby novo.

Cada roteador em um grupo HSRP participa no protocolo executando uma máquina de estado simples. Todo o Roteadores começa no estado inicial.

  1. Inicial: Este é o estado começando e indica que o HSRP não está sendo executado. Este estado está incorporado através de uma alteração de configuração ou quando uma relação vier primeiramente acima.

  2. Aprenda: O roteador não determinou o endereço IP de Um ou Mais Servidores Cisco ICM NT virtual, e viu não ainda um mensagem de hello autenticada do roteador ativo. Neste estado o roteador ainda está esperando para ouvir-se do roteador ativo.

  3. Escute: O roteador conhece o endereço IP de Um ou Mais Servidores Cisco ICM NT virtual, mas é nem o active ou roteador em standby. Ele escuta mensagens de saudação daqueles roteadores.

  4. Fale: O roteador envia mensagens de hello periódico e está participando ativamente na eleição do active e/ou do roteador em standby. Um roteador não pode digitar um estado de pico a menos que ele tenha o endereço IP virtual.

  5. Apoio: O roteador é um candidato a transformar-se o roteador ativo seguinte e envia mensagens de hello periódico. Com exclusão das condições transitórias, DEVE haver no máximo um roteador no grupo no estado à espera.

  6. Ativo: O roteador está enviando atualmente os pacotes que são enviados ao endereço IP de Um ou Mais Servidores Cisco ICM NT virtual MAC/do grupo. O roteador envia mensagens de hello periódico. Além das condições transitórias, DEVE haver no máximo um roteador no estado ativo no grupo.

Dica de Troubleshooting: Por que há dois roteadores ativo?

Isto ocorre quando ambo o Roteadores não vê os hellos HSRP de se.

  • Verifique se cada roteador pode sibilar o outro endereço da interface IP. Se não, então as comunicações entre o Roteadores estão para baixo.

  • Use o comando debug standby ver se o Roteadores é de emissão e/ou de recepção pacotes do HSRP hello. Se o par os está enviando hellos, mas não estão sendo recebidos então verificam a relação ou os comandos show controller da mostra ver se a relação está escutando o endereço de multicast HSRP.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 112095