Cisco Unified Border Element

Document ID: 112095

PDF Downloads Cisco Unified Border Element High Availability (HA) Using HSRP Configuration Example

Feedback

Introduction

The Cisco Unified Border Element (CUBE) provides high availability (HA) via box-to-box redundancy configurations when implemented on a Cisco Integrated Services Router Generation 2 router (ISR G2) platform. CUBE box-to-box redundancy leverages the long available router-based Hot Standby Routing Protocol (HSRP) router technology.

HSRP technology provides high network availability by routing IP traffic from hosts on networks without relying on the availability of any single router. HSRP is used in a group of routers for selecting an Active router and a Standby router. HSRP monitors both the inside and outside interfaces – if any interface goes down, the whole device is considered down, the Standby device becomes active and takes over the responsibilities of the Active router.

Box-to-box redundancy uses the HSRP protocol to form an HSRP Active/Standby pair of routers. The Active/Standby pair share the same virtual IP address and continually exchange status messages. CUBE session information is checkpointed across the Active/Standby pair of routers. This enables the Standby router to immediately take over all CUBE call processing responsibilities if the Active router should go out of service for planned or unplanned reasons.

The CUBE box-to-box redundancy HA implementation supports media preservation over an HSRP switchover of SIP-SIP calls, but no call signaling is preserved. This capability is supported as of Cisco IOS® Software release 15.1.2T. The call signaling preservation is supported in the latest Cisco IOS Software release 15.2.3T.

Note: For more information, refer to Cisco Unified Border Element Protocol-Independent Features and Setup Configuration Guide, Cisco IOS Release 15.2M&T .

Prerequisites

Requirements

Ensure that you meet these requirements before you attempt this configuration:

• Basic knowledge of how to configure and use Cisco IOS Voice

• Basic knowledge of how to configure and use CUBE

• Basic knowledge of how HSRP high availability works on general router platforms

The basic requirements for setting up CUBE ISR G2 box-to-box redundancy include:

• Two identical ISR G2s equipped with the UC Technology Package license (SL-29-UC-K9 or SL-39-UC-K9) installed, 1G DRAM memory, and Cisco IOS Software release 15.1.2T or later

• Both routers must be physically located on the same Ethernet LAN.

• The CUBE configuration of both routers is identical and must be manually copied from one router to the other.

• One router is designated the HSRP Active router, the second is the Standby. There are slight differences in the HSRP configuration between the Active and Standby routers.

• SIP-SIP call flows

Components Used

The information in this document is based on a minimum software release of CUBE 8.5 (Cisco IOS release 15.1.2T), implemented on a Cisco 2900 or 3900 series Integrated Service Router Generation 2 (ISR G2).

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to the Cisco Technical Tips Conventions for more information on document conventions.

Background Information

Box-to-box redundancy requires two identical ISR-G2 platforms: one configured as the Active, the other as the Standby. HSRP is configured on the physical interfaces to form an HSRP group.

If there is a heartbeat failure when the Active router goes down, the second Standby router takes over the IP routing addresses of the first router and continues to forward the same RTP packets that were previously routed to the first router.

The RTP streams of established calls are checkpointed between the Active and Standby routers via the HSRP protocol. Therefore the media streams of established calls are preserved over the HSRP failover from the Active to the Standby routers. Calls in a transient state (calls that are not established yet, or are in the process of being modified with a transfer or hold function) at the time of failover are disconnected. Also, any calls using DSP services such as transcoding are not preserved.

Configure

In this section, you are presented with the information to configure the features described in this document.

The CUBE HSRP configuration follows a specific order of steps, which includes:

1. Enable CUBE and CUBE Redundancy

2. Enable HSRP

3. Configure HSRP Communication Transport

4. Configure HSRP on the Interfaces

5. Configure the HSRP Timers

6. Configure the Media Inactivity Timer

7. Configure SIP Binding to HSRP Address

8. Reload the Routers

9. Point Attached Softswitches to the CUBE HSRP Virtual Address

Reload both the routers after steps 1-5 are completed. A reload is required only when HSRP is configured for the first time on a router.

Note: Use the Command Lookup Tool (registered customers only) to obtain more information on the commands used in this section.

Network Diagram

This diagram shows the topology of an Active/Standby pair of ISR G2 routers used in a SIP trunk deployment between a Cisco Unified Communications Manager (CUCM) and a service provider (SP) SIP trunk for PSTN access.

Step 1: Enable CUBE and CUBE Redundancy

Enable CUBE on both routers:

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

Enable CUBE redundancy and call checkpointing on both routers:

voice service voip 
  redundancy

Step 2: Enable HSRP

Enable router redundancy schemes on both routers, where:

• scheme – redundancy state tracking scheme

• standby – enable standby (HSRP) state tracking scheme

• SB – the HSRP standby group name

redundancy inter-device
  scheme standby SB

Step 3: Configure HSRP Communication Transport

Configure the HSRP Inter-Device Communication Transport as follows:

Active Configuration:

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

Standby Configuration:

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

Note: Exit from the “local-sctp” prompt to configure the remote SCTP parameters as follows:

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

These are the explanation of the fields used in this configuration:

• ipc zone default – Configures the Inter-Device Communication Protocol (IPC) and enters IPC zone configuration mode. Use this command to initiate the communication link between the Active and Standby devices.

• association 1 – Configures an association between the two devices and enters the IPC association configuration mode. Under this, configure the details of the association such as transport protocol, local port, local IP address, remote port and remote IP address. Valid association IDs range from 1 to 255. There are no default association IDs.

• no shutdown – Restarts a disabled association and its associated transport protocol. For any changes to the transport protocol parameters, this association must be shutdown.

• protocol sctp – Configures Stream Control Transmission Protocol (SCTP) as the transport protocol for this association and enables SCTP protocol configuration mode.

• local-port port_num – Defines the local SCTP port number to use to communicate with the redundant peer.

• local-ip ip_addr – Defines the local router’s IP address to use to communicate with the redundant peer. The local IP address must match the remote IP address on the redundant router.

• remote-port port_num – Defines the remote SCTP port number to use to communicate with the redundant peer.

• remote-ip ip_addr – Defines the remote IP address of the peer router used to communicate with the local device. All remote IP addresses must point to the same device.

Note: The local-port and the remote-port must be set to 5000 on the Active and Standby routers.

Step 4: Configure HSRP on the Interfaces

Configure the HSRP Inter-Device Communication Transport as follows:

Active Configuration

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

Standby Configuration

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

This is an explanation of the fields used in this configuration:

• 0 / 6 – Defines the Standby Group Number.

• keepalive – Enables keepalive for HSRP to monitor up/down events.

• standby delay – Delays HSRP initialization until the physical interface is up.

• standby x ip – Defines the virtual IPv4 IP address shared between the Active and Standby devices. This command enables the HSRP on the interface.

• standby x preempt – Allows the router to become the active router when the priority is higher than all other HSRP-configured routers in the hot standby group. If you do not use the standby preempt command in the configuration for a router, that router does not become the active router, even if the priority is higher than all other routers.

• standby x priority – Defines the Hot Standby priority used in choosing the active router. It ranges from 1 to 255 where 1 denotes the lowest priority and 255 the highest priority.

  Note: In cases where the standby priority is the same, the device with the higher IP address assumes the role of the Active router.

• standby x name – Defines the name of the standby group which matches the scheme defined in step 2 (“SB”). For multiple HSRP groups, the same standby name is used as only one standby scheme is allowed in the configurations.

• standby 6 track 1 decrement 10 – Defines priority tracking. For more information on interface tracking, click here.

• bfd interval 500 min_rx 500 multiplier 3 – Defines Bidirectional Forwarding Detection.

To avoid race conditions when a router boots up and an interface comes up to establish contact (“Hello”) between the Active and Standby routers, it is also recommended to configure the following:

interface GigabitEthernet0/0
  standby delay minimum 30 reload 60

For more information on this command, click here.

Step 5: Configure the HSRP Timers

There are two important HSRP timers:

• Hello Timer: The interval between successive HSRP Hello messages from a given router. This timer can be configured in seconds or milliseconds under the HSRP interface. The default value is 3 seconds.

• Hold Timer: The interval between the receipt of a Hello message and the presumption that the sending router has failed. This time can be configured in seconds or milliseconds under the HSRP interface. The default value is 8 seconds.

In the configurations in step 4, the HSRP Hello and Hold Timers are set to their default values. Therefore, they do not show up explicitly in the configurations. The recommended values for the Hello/Hold Timers are the default values.

Note: If you should use non-default values, you must configure each router to use the same Hello time and Hold timer values.

The Hello and Hold timers can be configured under the HSRP interface using the following 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

In the previous configuration, the Hello timer is set to 2 seconds and the Hold timer to 40 milliseconds.

Note: You can lower the timer settings to speed up failover or preemption. However, to avoid increased CPU use and unnecessary standby state flapping, it is recommended not to set the Hello timer at less than 1 second, and the Hold timer at less than 4 seconds.

Step 6: Configure the Media Inactivity Timer

The Media Inactivity Timer enables the Active/Standby router pair to monitor and disconnect calls if no Real-Time Protocol (RTP) packets are received within a configurable time period.

When RTP packets for a call are not received by the Active/Standby router, the SIP Media Inactivity Timer releases the session. This is used to guard against any hung sessions that might have resulted from the failover in the event that a normal call disconnect does not clear the call.

The same duration for the Media Inactivity Timer should be configured on both routers. The default value is 28 seconds. This timer is configured as follows:

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

Step 7: Configure SIP Binding to HSRP Address

Configure the CUBE SIP messaging to use the HSRP virtual address in SIP messaging.

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

Once HSRP is configured under the physical interface and the bind command has been issued, calls to the physical IP address will fail. This is because the SIP listening socket is now bound to the virtual IP address but the signaling packets use the physical IP address, and therefore cannot be handled.

Step 8: Reload the Routers

Once all the above configurations have been completed, the redundancy show output is as follows:

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

Upon reloading the router the HSRP configuration is enabled as follows:

Active Router

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

Standby Router

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

Step 9: Point Attached Softswitches to the CUBE HSRP Virtual Address

The CUCM, IP-PBX, SIP proxy or SP SBCs or SP softswitches that route calls to CUBE must use the HSRP virtual address in their SIP messaging. SIP messages to the CUBE physical IP addresses are not handled with an HSRP configuration.

Full Sample Configurations for Dual-Attached CUBE HSRP Redundancy

Here are complete sample configurations for both the Active and Standby CUBE routers. In these configurations, the HSRP Hello and Hold timers use their default values of 3 and 8 seconds respectively, and are not shown explicitly in the CLI output.

Active Router Configuration

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

Standby Router Configuration

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

Full Sample Configuration for Single-Attached CUBE HSRP Redundancy

While a dual-attached CUBE is the most common configuration, especially for SP SIP trunk connections, it is also possible to configure CUBE HSRP box-to-box redundancy with a single-attached CUBE deployment as given in this section.

Active Router Configuration

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

Standby Router Configuration

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

Removing HA Configurations

Complete these steps in order to remove a previously entered HSRP configuration from a CUBE router:

1. Remove the application level redundancy configuration.

   Router(config)#voice service voip 
   Router(config-voice service voip)#no redundancy

2. Remove the standby scheme configured under the inter-device configuration mode.

   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. Save the configuration changes to memory and reload the router.

   Router(config)#write
   Router#reload

4. After the reload, issue this command to check that HSRP has been disabled:

   Router#show redundancy inter-device
   Redundancy inter-device state: RF_INTERDEV_STATE_INIT
     Scheme: <NOT CONFIGURED>
     Peer present: UNKNOWN
     Security: Not configured
   

5. Disable the association between the two devices and remove the SCTP configuration.

   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. Remove the HSRP configuration from the interface by using “no” forms of the HSRP commands.

   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. Save configuration changes.

   Router(config)#write

Feature Use Notes

• The two router used for an HSRP pair should be identical (to ensure the same performance and call capacity level).

• Box-to-box redundancy configuration support on SIP-SIP calls flows, the SIP transport can be either UDP-UDP or UDP-TCP

• HSRP virtual addresses support only IPv4 addressing.

• The media stream of established calls is preserved over a failover, but signaling is not. Therefore, preserved calls cannot be modified (Hold/Resume, transfer, conference, etc.).

• Calls involving supplementary services such as transcoding, DTMF-interworking, IVR, SIP-TLS, RSVP, STUN, RTP-SRTP conversion, or fax/modem features are not preserved in a failover.

• Video streams are not preserved upon switchover, although the audio stream can be preserved.

• Multiple HSRP groups per router are supported, but only a single HSRP group per physical interface.

• Loopback addresses with HSRP are not supported, the SIP bind command must use the HSRP virtual IP address.

• Configuration synchronization between the Active and Standby router is manual, there is no automation. Configuration changes must be made manually to both routers.

Verify

Use the CLI below to verify the HSRP configuration is correct and working.

The Output Interpreter Tool (registered customers only) (OIT) supports certain show commands. Use the OIT to view an analysis of show command output.

Verify Redundancy State

Verify the redundancy state with the show redundancy inter-device and show redundancy state commands. These commands show the redundancy inter-device information such as the redundancy inter-device states.

Before inter-device configuration is done, the show output is as follows:

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

After the inter-device configuration is done but before the router reload, the show output is as follows:

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

After the router reload, the show output is as follows showing the “Init” state:

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

During a switchover, for example the Active router is down and while the Standby router is switching to becoming the Active, the show output is as follows:

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

After the switchover, but before the routers have exchanged Hello status messages, the show output is as follows:

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

After the exchange of Hello status messages, the show output is as follows:

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

Verify the HSRP State

Verify the HSRP state with the show standby brief command. This command shows the brief output on HSRP including HSRP interfaces, Standby Group Numbers, Priorities, Active and Standby IP addresses as well as virtual IP addresses. The show standby command gives the full, detailed information.

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

Verify Call State after a Switchover

The show voice high-availability summary command is used to verify:

• The checkpointing of calls on the Standby router after a switchover

• The media-inactivity count on the Active when the calls are over

• To check for native and nonnative (for example, preserved) calls when both types of calls are present

• To identify the presence of leaked RTP, HA, SPI sessions

Show the checkpointing of calls on the Standby router after a switchover

In this example, 800 calls were checkpointed from Active to Standby after the 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

Show the media-inactivity count on the Active when the calls are over

In this example, 800 calls are cleared by the media-inactivity timer.

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

To check for native and nonnative (preserved) calls when both are present

The numbers of calls on the system are shown as follows:

• Total number of calls = “Number of calls in HA DB” + “Number of calls in HA sync pending DB”. This is 100 + 50 = 150 in the example output below.

• Total number of preserved (nonnative) calls = “Number of calls in HA preserved session DB”. This is 70 in the example output below.

• Total number of native calls (calls set up since the failover and therefore not preserved over the failover) is the difference in the previous two numbers. In this example, it is 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

To identify the presence of leaked RTP, HA, SPI sessions

The total number of preserved (nonnative) calls cleared by media inactivity is = “Total CREATE received on Standby” – “Total DELETE received on Standby” as the output below shows. Compare this number with the “Media Inactivity event count” as well as the number of media down events shown by the output of the show voip fpi stats command.

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

Verify SIP IP Address Bindings

The show sip-ua status command displays SIP binding status.

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

Verify Current CPU Use

The show process cpu history command is used to verify the CPU utilization percentage at regular intervals.

Check CPU utilization before performing a switchover and proceed with a forced failover only when the CPU utilization is less than 70%. The show process cpu sorted command can also be issued repeatedly to get an idea of the CPU utilization for a particular process.

Verify That Calls are Being Processed During a Switchover

The show sip-ua statistics command is used to verify call drops during the switchover by checking the number of BYE messages. Calls in progress during the switchover are dropped. Only established calls are preserved.

The show interface accounting command is used to verify the media path confirmation during a 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

Check IP “Pkts In” and “Pkts Out” counters – these should be increasing at a reasonable rate. For example, if you are using G.711 20ms packetization and no VAD, you should see the packet counters increase by around 50 every second.

Forcing a Manual Failover for Testing

Box-to-box redundancy using HSRP supports a media-stateful switchover of calls which means the media (RTP) of the calls is preserved, but not the signaling. Therefore, only calls in the active state (media path in “sendrecv” connection mode) are preserved while the calls in the transient state (non-active state, media path not in “sendrecv” connection mode) are not preserved during switchover.

Switchovers occurring in real environments where there is a constant mixture calls in transient (call setup or being modified) and established state, there will always be a certain number of calls dropped during a failover. The overall number of dropped calls expected can be estimated by: (0.3 + HSRP hold-timer) * CPS.

Complete the procedure below to force a manual switchover to check that the configuration and operation is correct.

To ensure smooth forced switchover, do the following:

• Monitor the CPU utilization % on the Active/Standby pair. The Active will have a higher CPU utilization as it is actively handling the calls, while the Standby will show 0 CPU utilization as it is idle until a switchover occurs.

• Ensure a manual switchover is performed when the CPU utilization of the Active router is no more than 70%. All switchovers lead to a spike in CPU utilization.

• Use the show voip rtp connection and show voice high-availability summary commands to make sure existing calls have been synched across the Active/Standby router pair.

An HSRP switchover involves the formerly Active router reloading, while the formerly Standby router takes over and becomes the new Active router processing new calls and maintaining the media streams for preserved calls until they are complete. The new Active router will remain as the Active router until another switchover occurs.

Manual (forced) switchovers can be achieved in any one of these ways:

• Initiate it by the CLI “redundancy switch-activity force” on the Active router.

• Reload of the Active router

• Hard Restart of the Active router

• Pull out the HSRP interface or power cable of the Active router.

• Shutdown the HSRP interface of the Active router.

• A change in any parameter of the HSRP interface of the Active/Standby router without shutting down the association under IPC mode leads to a router reload. Therefore, the interface must be shutdown before any changes are made, unless you are using this as a trigger to force a switchover.

The show voip rtp connections command shows the number of active connections on both the Active and Standby routers after a switchover.

The show call active voice brief command does not show any output on the Standby router after a switchover because the signaling information is not checkpointed.

Steps to Perform and Verify a Single Switchover

Complete these steps:

1. Configure HSRP box-to-box redundancy as per the Configure section in this document.

2. Reload and keep both routers in rommon.

3. Boot up one router. After it is up, issue the show redundancy state command and make sure it shows my state as Active and peer state as Disabled. This can take a while after boot up.

   XFR-2#show redundancy states
   my state = 13 -ACTIVE 
   peer state = 1  -DISABLED

4. Boot up the second router. After it is up, issue the show redundancy state command to make sure it shows my state as Standby-Hot and peer state as Active.

   CUBE_XFR#show redundancy states
   my state = 8  -STANDBY HOT 
   peer state = 13 -ACTIVE

5. Start one or more calls across the system. Issue the show voice high-availability summary and show voip rtp connection commands on both the Active and Standby routers to make sure the calls are up and checkpointed.

6. Test switchover by reloading the Active router. If you are using a phone to make calls, you can listen to the phone to make sure media path is preserved. If you are using test equipment, you can use the packet displays to determine if media for the calls are flowing:

   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. Test media inactivity: Stop the call. Repeat show voip rtp connection. After the media-inactivity timer expiry, there should be no more active RTP connections. You can also check this via the show voice high-availability summary command and look for:

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

   The Media Inactivity event count should show 1.

Screenshots to Verify a Single Call Preserved over a Failover

The display before the failover:

• Active Router (#01)

  

• Standby Router (#02)

  

Reloading the Active router (#01) to force a failover:

The Standby router (#02) takes over as new Active, the call is preserved (Standby = New Active):

The previously Active router (#01) reloads as the new Standby router, and the call is preserved on the new Standby.

• New Standby (#01) router:

  

• New Active (#02) router:

  

Troubleshoot

This section provides information you can use to troubleshoot your configuration.

Note: Refer to Important Information on Debug Commands before you use debug commands.

These show and debug commands are useful during troubleshooting of box-to-box redundancy:

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

Note: Do not turn on a large number of debugs on a system carrying a high volume of active call traffic.

Note: On every switchover, after router reload, the debugs must be re-enabled on the new Standby router.

Each router in an HSRP group participates in the protocol by implementing a simple state machine. All routers begin in the Initial state.

1. Initial: This is the starting state and indicates that HSRP is not running. This state is entered via a configuration change or when an Interface first comes up.

2. Learn: The router has not determined the virtual IP address, and not yet seen an authenticated Hello message from the active router. In this state the router is still waiting to hear from the active router.

3. Listen: The router knows the virtual IP address, but is neither the active or standby router. It listens for Hello messages from those routers.

4. Speak: The router sends periodic Hello messages and is actively participating in the election of the active and/or standby router. A router cannot enter Speak state unless it has the virtual IP address.

5. Standby: The router is a candidate to become the next active router and sends periodic Hello messages. Excluding transient conditions, there MUST be at most one router in the group in Standby state.

6. Active: The router is currently forwarding packets that are sent to the group's virtual MAC/IP address. The router sends periodic Hello messages. Besides transient conditions, there MUST be at most one router in Active state in the group.

Troubleshooting Tip: Why are there two Active routers?

This occurs when both routers fail to see the HSRP Hellos from each other.

• Check if each router can ping the other’s IP interface address. If not, then communications between the routers is down.

• Use the debug standby command to see if the routers are sending and/or receiving HSRP Hello packets. If the peer is sending Hellos, but they are not being received then check show interface or show controller commands to see if the interface is listening to the HSRP multicast address.

Cisco Support Community - Featured Conversations

Related Information

• Voice Technology Support
• Voice and Unified Communications Product Support
• Troubleshooting Cisco IP Telephony
• Technical Support & Documentation - Cisco Systems