High Availability on Cisco Integrated Services Routers (ISR-G2)

The High Availability (HA) feature allows you to benefit from the failover capability of Cisco Unified Border Element (CUBE) on two routers, one active and one standby. When the active router goes down for any reason, the standby router takes over seamlessly, preserving and processing your calls.

Figure 1. Cisco CUBE High Availability


About CUBE High Availability on Cisco ISR-G2

CUBE supports Box-to-box redundancy on Cisco Integrated Services Router Generation 2 Router (ISR-G2) and uses Hot Standby Routing Protocol (HSRP) technology to provide High Availability.

Box-to-Box Redundancy

Box-to-box redundancy enables configuring a pair of routers to act as back up for each other. In the router pair, active router is determined based on the failover conditions. The router pair continuously exchange status messages. Cisco UBE session information is checkpointed across the active and standby router. This enables the standby router to immediately take over all Cisco UBE call processing responsibilities when the active router becomes unavailable.

Hot Standby Router Protocol (HSRP)

Hot Standby Router Protocol (HSRP) technology provides high network availability by not relying on any single router for routing IP traffic from hosts on the network.

By sharing an IP address and a MAC (Layer 2) address, two or more routers consist a virtual router group that is called a Standby group or HSRP group. This HSRP group acts as a single virtual router to hosts on the LAN. HSRP is used to select an active router and a standby router in an HSRP group. The active router forwards packets that the host sends to the virtual router group. Active and standby routers continually exchange periodic HSRP messages once the protocol has completed the router selection process.

HSRP monitors both the inside and outside interfaces. If any of the interfaces go down, the whole router is considered down and the standby router takes over the responsibilities of the active router.

The RTP streams of established calls are checkpointed between the active and standby routers through 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 the transient state (calls that are not established yet, or are in the process of being modified with transfer or hold function) at the time of failover are disconnected.


Note

For redundant solutions that use HSRP, CDRs are only generated by the active router.

HSRP Features

  • Preemption—The HSRP preemption feature enables the router with the highest priority to immediately become the active router. Priority is determined as follows.

    1. Priority value that you configure.

    2. IP address.

    In each case, higher value is of a greater priority.

  • Preempt Delay—The preempt delay feature allows you to delay the preemption for a configurable time period. Preempt delay allows the router to populate its routing table before becoming the active router.

  • Interface Tracking—Allows you to specify details of another interface on the router of the HSRP group. Interface tracking helps to monitor the change in the HSRP priority of a given HSRP group.

Network Topology

This section describes how to configure the following dual-attached and single-attached network topology. The dual-attached network topology is the most common configuration, in which an active and standby pair of routers is used in a SIP trunk deployment between a Cisco Unified Communications Manager (Unified CM) and a service provider (SP) SIP trunk for PSTN access. It is also possible to configure CUBE HSRP Box-to-box redundancy with a single-attached network topology.

Figure 2. Dual-Attached Network Topology
Figure 3. Single-Attached Network Topology

In these topologies, both active and standby routers have the same configuration and both platforms are connected through a physical switch across similar interfaces. This is required for Cisco UBE HA to work. For example, the CUBE-1 and CUBE-2 interface towards WAN must terminate on the same switch. Multiple interfaces or sub-interfaces can be used on either LAN or WAN side. Also, one Cisco UBE has a lower IP address across all three interfaces on the same Cisco UBE paltform. This criteria decides the HSRP active state.

We recommend that you keep the following in mind when configuring these topologies:

  • Configure all interfaces of an HSRP group with the same priority.

  • The active and standby router pair, and interface combination on a particular LAN must have a unique HSRP group number.

Configure CUBE High Availability Using HSRP

Before you begin

It is recommened that you have the knowledge of the following topics:

  • How to configure and use Cisco IOS® Voice.

  • How to configure and use CUBE.

  • How HSRP high availability works on general router platforms.

Components used:

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

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

  • SIP-SIP call flows.

SUMMARY STEPS

  1. Enable CUBE and CUBE Redundancy.
  2. Enable HSRP.
  3. Configure HSRP Communication Transport.
  4. Configure HSRP on Interfaces.
  5. Configure HSRP Timers.
  6. Configure Media Inactivity Timer.
  7. Configure SIP Binding to HSRP Address
  8. Reload Routers.
  9. Point Attached Softswitches to CUBE HSRP Virtual Address

DETAILED STEPS

  Command or Action Purpose

Step 1

Enable CUBE and CUBE Redundancy.

Example:
voice service voip 
  mode border-element
  allow-connections sip to sip
Example:
voice service voip 
  redundancy

Enables CUBE on both routers. Also, enables CUBE redundancy and call check pointing on both routers.

Step 2

Enable HSRP.

Example:
redundancy inter-device
  scheme standby SB

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

Step 3

Configure HSRP Communication Transport.

Example:

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 prompts to configure the remote Stream Control Transmission Protocol (SCTP) parameters as follows: 

XFR-2(config)#ipc zone default
XFR-2(config-ipczone)#association 1
XFR-2(config-ipczone-assoc)#no shutdown
XFR-2(config-ipczone-assoc)# protocol sctp
Pod4-3925(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

Enables the HSRP Inter-Device Communication Transport.

  • 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 shut down.

  • protocol sctp — Configures 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 in order to communicate with the redundant peer.

  • local-ip ip_addr — Defines the local router's IP address to use in order 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 in order 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 Interfaces.

Example:

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

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

Configures the HSRP Inter-Device Communication Transport.

  • 0 / 6—Defines the Standby Group Number.

  • keepalive—Enables keepalive for HSRP in order to monitor up/down events.

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

    • minimum—Defines the minimum time in seconds to delay HSRP group initialization after an interface comes up. This minimum delay period applies to all subsequent interface events.

    • reload—Defines the time period to delay after the router is reloaded.

  • 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 order to choose the active router. It ranges from 1 to 255 where 1 denotes the lowest priority and 255 the highest priority. 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.

    In order 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 recommended to configure this: 

    interface GigabitEthernet0/0
  standby delay minimum 30 reload 60

Step 5

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

    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 with this 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, in order 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 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 must 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

Note

 

The media inactivity detection timer is defined with two CLI commands. One command configures the Real-time Transport Control Protocol (RTCP) report interval, and another defines the multiplying factor M (this also identifies the mode of detection with Cisco IOS Release 12.4(4)T). The controlling mechanism is accomplished through the configuration of application CLI.

Media inactive timer = M * ip rtcp report interval

The inactivity detection is supported in two modes based on which timer multiplying factor configuration (M factor) is used:

timer receive-rtcp: Beginning from Cisco IOS Release 12.3(4)T, this mode detects inactivity with the use of no DSP statistics (either an RTP or RTCP packet received is considered active). No explicit enabling is needed. This timer is the default. When this timer is used, the call is disconnected when a silent call is detected. This behavior is not DSP-based, but is the default behavior when no application CLI is configured.

timer media-inactive: This mode is available in Cisco IOS Release 12.4(4)T, where detection is based on DSP statistics (it uses RTP-only mechanism; packets sent or received are considered active). If both directions are absent, it is considered inactive. This timer is enabled or disabled with the use of application CLI, which can also be used in order to control notification.

Step 7

Configure SIP Binding to HSRP Address

Configures the CUBE SIP messaging in order 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 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

When you reload the router, the HSRP configuration is enabled as follows:

Active Router Configuration: 

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 Configuration:

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

Example
Sample Configurations for Dual-Attached CUBE HSRP Redundancy

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

!
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

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

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

Verify Redundancy State

SUMMARY STEPS

  1. Use the show redundancy inter-Router and show redundancy state commands to verify the redundancy state.

DETAILED STEPS

Command or Action Purpose

Use the show redundancy inter-Router and show redundancy state commands to verify the redundancy state.

The following are sample outputs for the commands show redundancy inter-Router and show redundancy state before inter-router configuration: 
XFR-2#show redundancy inter-Router

Redundancy inter-Router 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

The following is a sample output for the command show redundancy inter-Router after the inter-router configuration and before router reload: 

XFR-2#show redundancy inter-Router

Redundancy inter-Router 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

The following are sample outputs for the commands show redundancy inter-Router and show redundancy state after the router reload: 

CUBE_XFR#show redundancy inter-Router

Redundancy inter-Router 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

The following are sample outputs for the commands show redundancy inter-Router and show redundancy state during a switchover: 

CUBE_XFR#show redundancy inter-Router

Redundancy inter-Router 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

The following are sample outputs for the commands show redundancy inter-Router and show redundancy state after a switch over, but before the routers exchange Hello status messages: 

CUBE_XFR#show redundancy inter-Router

Redundancy inter-Router 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-Router

Redundancy inter-Router state: RF_INTERDEV_STATE_HSRP_STDBY_PNC
Scheme: Standby
Groupname: b2bha Group State: Standby
Peer present: RF_INTERDEV_PEER_NO_COMM
Security: Not configured

The following are sample outputs for the commands show redundancy inter-Router and show redundancy state after the exchange of Hello status messages: 

XFR-2#show redundancy inter-Router

Redundancy inter-Router 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-Router

Redundancy inter-Router 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 Call State After a Switchover

Use the show voice high-availability summary command to verify the following:

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

  • The media-inactivity count on the active router 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

Verify checkpointing of calls on the standby router after a switchover

In this example, 800 calls were checkpointed from active to standby after the switchover. 

Router#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
Verify the media-inactivity count on the active router when the calls are over

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

Router#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
Verify native and non-native (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. 

Router#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
Identify the presence of leaked RTP, HA, SPI Sessions

The total number of preserved (non-native) calls cleared by Media Inactivity is equal to the total CREATE received on standby router minus total DELETE received on standby router. Compare this number with the Media Inactivity event count and the number of media down events, as shown in the output of the show voip fpi stats command. 

Router# 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

Considerations and Restrictions

The following is a list of further considerations and restrictions you should know before configuring this topology:

Considerations

  • There are slight differences in the HSRP configuration between active and standby routers.

  • Configuration synchronization between the active and standby router is manual.

  • HSRP virtual addresses support only IPv4 addressing.

  • Only active calls are checkpointed (Calls that are connected with 200 OK or ACK transaction completed).

  • Upon failover, the previously active CUBE reloads by design.

  • Multiple traffic (SIP/RTP) interfaces require Preemption and Interface Tracking.

  • In High Availability deployments, CUBE uses a primary IP address to communicate the Smart Licensing information.

  • Box-to-box redundancy configuration supports only SIP-SIP calls flows, the SIP transport can be either UDP-UDP or UDP-TCP.

  • Port channel interfaces are supported only from Cisco IOS Release 15.6(3)M onwards.

    Figure 4. Additional Supported Options for CUBE HA

Restrictions

  • IPv6 is not supported.

  • All SCCP-based media resources (Conference bridge, Transcoding, Hardware MTP, and Software MTP) are not supported.

  • Cisco Unified Survivable Remote Site Telephony (Unified SRST) or TDM Gateway co-location on Cisco UBE HA is not supported.

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

  • Box-to-box redundancy configuration supports multiple HSRP groups per router, 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.

  • No support for media-flow around or UC Services API (Cisco Unified Communications Manager - Network-Based Recording).

  • WANs cannot terminate directly on the CUBE or on data HSRP on either sides.

  • Call Progress Analysis (CPA) calls (before to being transferred to the agent), SCCP-based media resources, Noise Reduction, Acoustic Shock Protection (ASP), and transrating calls are not checkpointed.

  • Courtesy Callback (CCB) feature is not supported if a callback was registered with Cisco Unified Customer Voice Portal (CVP) and then a switchover was done on CUBE.

How to Configure CUBE High Availability on Cisco ISR-G2

Before You Begin

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

  • Ensure that you have the required licenses for configuring High Availability. For detailed information, see Cisco Unified Border Element Data Sheet.

Configure High Availability

SUMMARY STEPS

  1. Define the redundancy scheme.
  2. Enable CUBE and CUBE redundancy.
  3. Configure Inter-process Communication (IPC) protocol at the HSRP interface.
  4. (Optional) Configure Virtual Route Forwarding (VRF) on the platform.
  5. Configure HSRP on the interfaces.
  6. Configure Interface Tracking.
  7. Bind traffic to the respective interfaces.
  8. Configure Media Inactivity feature.
  9. Reload the routers.
  10. Point the attached devices to the CUBE HSRP Virtual IP (VIP) address.

DETAILED STEPS

Step 1

Define the redundancy scheme.

Example:


Router(config)#redundancy inter-device
Router(config-red-interdevice)#scheme standby SB

The following table provides details of the CLIs used in the configuration.

Keyword

Description

scheme

Redundancy state tracking scheme

standby

Enables standby (HSRP) state tracking scheme

SB

HSRP standby group name

The router enters the interdevice configuration mode and names the redundancy scheme that is used between the two routers. The CLIs listed in the preceding example create interdependency between theCUBE redundancy and HSRP.

Step 2

Enable CUBE and CUBE redundancy.

Example:

Enable CUBE on both routers 

Router(config)#voice service voip 
Router(config-voi-serv)#mode border-element
Router(config-voi-serv)#allow-connections sip to sip

Enables CUBE on the router and allows connections between the specific type of endpoints in a VoIP network.

Example:

Enable the CUBE redundancy and call checkpointing on both routers

Router(config)#voice service voip 
Router(config-voi-serv)#redundancy

Step 3

Configure Inter-process Communication (IPC) protocol at the HSRP interface.

Example:

Active CUBE configuration
CUBE-1(config)#ipc zone default
CUBE-1(config-ipzone)#association 1
CUBE-1(config-ipczone-assoc)#no shutdown
CUBE-1(config-ipczone-assoc)#protocol sctp
CUBE-1(config-ipc-protocol-sctp)#local-port 5000
CUBE-1(config-ipc-local-sctp)#local-ip 203.0.113.10
CUBE-1(config-ipc-local-sctp)#remote-port 5000
CUBE-1(config-ipc-remote-sctp#remote-ip 203.0.113.11

Example:

Standby CUBE configuration

CUBE-2(config)#ipc zone default
CUBE-2(config-ipzone)#association 1
CUBE-2(config-ipczone-assoc)#no shutdown
CUBE-2(config-ipczone-assoc)#protocol sctp
CUBE-2(config-ipc-protocol-sctp)#local-port 5000
CUBE-2(config-ipc-local-sctp)#local-ip 203.0.113.11
CUBE-2(config-ipc-local-sctp)#remote-port 5000
CUBE-2(config-ipc-remote-sctp#remote-ip 203.0.113.10

The following table provides details of the CLIs used in the configuration.

Option Description

ipc zone default

Configures the Inter-process Communication Protocol (IPC) and enters IPC zone configuration mode. Use this command to initiate the communication link between the active and standby routers.

association 1

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

no shutdown

Restarts a disabled association and the associated transport protocol. For any changes to the transport protocol parameters, you must shut down the association.

protocol sctp

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

local-port port_num

Defines the local SCTP port number for communication with the redundant peer.

local-ip ip_addr

Defines the local router's IP address for communication 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 for communication with the redundant peer.

remote-ip ip_addr

Defines the remote IP address for communication with the redundant peer. All remote IP addresses must point to the same router.

Allows the active CUBE to communicate with the standby CUBE about the state of the calls. Configuration must be applied on the LAN side.

Note

 

The local-port and the remote-port must be set to 5000 on the active and standby routers.

Step 4

(Optional) Configure Virtual Route Forwarding (VRF) on the platform.

Example:

VRF configuration on active and standby CUBE
Router(config)#ip vrf LAN-VRF
Router(config)#rd 1:1
Router(config)#ip vrf WAN-VRF
Router(config)#rd 1:1

The following table provides details of the CLIs used in the configuration.

Option Description

ip vrf vrf-name

Creates a VRF with the specified name.

Note

 

Space is not allowed in the VRF name.

rd route-distinguisher

Creates a VRF table by specifying a route distinguisher. Enter either an AS number and an arbitrary number (xxx:y) or an IP address and arbitrary number (A.B.C.D:y).

CUBE High Availability with HSRP supports VRF. Traffic interfaces (SIP/RTP) can have VRFs configured. VRF IDs are checkpointed for the calls before and after the switchover. VRF configurations including VRF-based RTP port range, must be identical on both active and standby routers.

Step 5

Configure HSRP on the interfaces.

  1. Configure the inside interface.

    Example:

    Active CUBE configuration
    CUBE-1(config)#interface GigabitEthernet0/0
CUBE-1(config-if)#description “Enterprise LAN”
CUBE-1(config-if)#ip vrf forwarding LAN-VRF
CUBE-1(config-if)#ip address 203.0.113.10 255.255.255.0
CUBE-1(config-if)#standby version 2
CUBE-1(config-if)#standby 1 ip 203.0.113.12
CUBE-1(config-if)#standby delay minimum 30 reload 60
CUBE-1(config-if)#standby 1 preempt
CUBE-1(config-if)#standby 1 track 2 decrement 10
CUBE-1(config-if)#standby 1 track 3 decrement 10
CUBE-1(config-if)#standby 1 priority 50

    Example:

    Standby CUBE configuration
    
CUBE-2(config)#interface GigabitEthernet0/0
CUBE-2(config-if)#description “Enterprise LAN”
CUBE-2(config-if)#ip vrf forwarding LAN-VRF
CUBE-2(config-if)#ip address 203.0.113.11 255.255.255.0
CUBE-2(config-if)#standby version 2
CUBE-2(config-if)#standby 1 ip 203.0.113.12
CUBE-2(config-if)#standby delay minimum 30 reload 60
CUBE-2(config-if)#standby 1 preempt
CUBE-2(config-if)#standby 1 track 2 decrement 10
CUBE-2(config-if)#standby 1 track 3 decrement 10
CUBE-2(config-if)#standby 1 priority 50

  2. Configure the outside interface.

    Example:

    Active CUBE configuration
    CUBE-1(config)#interface GigabitEthernet0/1
CUBE-1(config-if)#description “Enterprise WAN”
CUBE-1(config-if)#ip vrf forwarding WAN-VRF
CUBE-1(config-if)#ip address 192.0.2.1 255.255.255.0
CUBE-1(config-if)#standby version 2
CUBE-1(config-if)#standby 10 ip 192.0.2.5
CUBE-1(config-if)#standby delay minimum 30 reload 60
CUBE-1(config-if)#standby 10 preempt
CUBE-1(config-if)#standby 10 track 2 decrement 10
CUBE-1(config-if)#standby 10 track 3 decrement 10
CUBE-1(config-if)#standby 10 priority 50

    Example:

    Standby CUBE configuration
    CUBE-2(config)#interface GigabitEthernet0/1
CUBE-2(config-if)#description “Enterprise WAN”
CUBE-2(config-if)#ip vrf forwarding WAN-VRF
CUBE-2(config-if)#ip address 192.0.2.2 255.255.255.0
CUBE-2(config-if)#standby version 2
CUBE-2(config-if)#standby 10 ip 192.0.2.5
CUBE-2(config-if)#standby delay minimum 30 reload 60
CUBE-2(config-if)#standby 10 preempt
CUBE-2(config-if)#standby 10 track 2 decrement 10
CUBE-2(config-if)#standby 10 track 3 decrement 10
CUBE-2(config-if)#standby 10 priority 50

  3. Configure the HSRP interface (between the active and standby CUBE).

    Example:

    Active CUBE configuration
    CUBE-1(config)#interface GigabitEthernet0/2
CUBE-1(config-if)#description “HSRP Interface”
CUBE-1(config-if)#ip address 198.51.100.1 255.255.255.0
CUBE-1(config-if)#standby version 2
CUBE-1(config-if)#standby 100 ip 198.51.100.5
CUBE-1(config-if)#standby delay minimum 30 reload 60
CUBE-1(config-if)#standby 100 preempt
CUBE-1(config-if)#standby 100 name SB
CUBE-1(config-if)#standby 100 track 2 decrement 10
CUBE-1(config-if)#standby 100 track 3 decrement 10
CUBE-1(config-if)#standby 100 priority 50

    Example:

    Standby CUBE configuration
    CUBE-2(config)#interface GigabitEthernet0/2
CUBE-2(config-if)#description “HSRP Interface”
CUBE-2(config-if)#ip address 198.51.100.2 255.255.255.0
CUBE-2(config-if)#standby version 2
CUBE-2(config-if)#standby 100 ip 198.51.100.5
CUBE-2(config-if)#standby delay minimum 30 reload 60
CUBE-2(config-if)#standby 100 preempt
CUBE-2(config-if)#standby 100 name SB
CUBE-2(config-if)#standby 100 track 2 decrement 10
CUBE-2(config-if)#standby 100 track 3 decrement 10
CUBE-2(config-if)#standby 100 priority 50

Note

 

ip vrf forwarding vrf-name is applicable only if you have configured VRF.

The HRSP interface cannot have VRFs associated with it. For a CUBE deployment that has VRFs configured for SIP/RTP interfaces, you must have minimum of three interfaces. Otherwise, you can use any of the LAN interfaces as an HSRP interface.

The following table provides details of the CLIs used in the configuration.

Option Description

interface type number

Configures an interface type and enters the interface configuration mode.

ip address ip_address subnet_mask

Configures an IP address for an interface.

standby version{1|2}

Changes the HSRP version.

standby [group-number] ip [ip_address]

Activates HSRP.

  • If you do not configure a group number, the default group number is 0. The group number range is 0–255 for HSRP version 1 and 0–4095 for HSRP version 2.

  • The value for the ip_address argument is the virtual IP address of the virtual device. For HSRP to elect a designated device, you must configure the virtual IP address for at least one of the devices in the group; it can be learned on the other devices in the group.

standby delay minimum min-seconds reload reload-seconds

Configures the delay period before the initialization of HSRP group.

  • The min-seconds value is the minimum time (in seconds) to delay the HSRP group initialization after an interface comes up. This minimum delay period applies to all subsequent interface events.

  • The reload-seconds value is the time period to delay after the device has reloaded. This delay period applies only to the first interface-up event after the device has reloaded.

Note

 

The recommended min-seconds value is 30 and the recommended reload-seconds value is 60.

standby group-number preempt

Allows the router to become the active router when the priority is higher than all other HSRP-configured routers in the HSRP 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 group-number track track-process-number decrement value

Configures HSRP to track a device and change the HSRP priority on the basis of the state of the device. Decrement value specifies the value by which the HSRP priority of the tracked device is decremented (or incremented) when the device goes down (or becomes available).

standby x priority

Defines the Hot Standby priority that is used in choosing the active router. The range is 1–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.

ip vrf forwarding vrf-name

Associates the specified VRF with the interface.

Step 6

Configure Interface Tracking.

Example:

Active and standby CUBE configuration
Router(config)#track 1 interface Gig0/0 line-protocol 
 Router(config)#track 2 interface Gig0/1 line-protocol
Router(config)#track 3 interface Gig0/2 line-protocol

Create a tracking list to track the line-protocol state of an interface.

The following table provides details of the CLIs used in the configuration.

Option Description

track object-number interface interface-id line-protocol

Enters tracking configuration mode.

  • The object-number identifies the tracked object and the range is 1–500.

  • The interface-id represents the interface that is tracked.

Step 7

Bind traffic to the respective interfaces.

  1. Bind traffic that is destined to the outside (Service Provider (SP) SIP trunk) to the outside physical interface.

    Example:

    Active and standby CUBE configuration
    Router(config)#dial-peer voice 100 voip
Router(config-dial-peer)#description TO SERVICE PROVIDER
Router(config-dial-peer)#destination-pattern 9T
Router(config-dial-peer)#session protocol sipv2
Router(config-dial-peer)#session target ipv4:y.y.y.y
Router(config-dial-peer)#voice-class sip bind control source-interface GigabitEthernet0/1
Router(config-dial-peer)#voice-class sip bind media source-interface GigabitEthernet0/1

  2. Bind traffic that is destined to the inside (Unified CM or IP PBX) to the inside physical interface.

    Example:

    Active and standby CUBE configuration
    CUBE(config)#dial-peer voice 200 voip
CUBE(config-dial-peer)#description TO CUCM
CUBE(config-dial-peer)#destination-pattern 555...
CUBE(config-dial-peer)#session protocol sipv2
CUBE(config-dial-peer)#session target ipv4:203.0.113.1
CUBE(config-dial-peer)#voice-class sip bind control source-interface GigabitEthernet0/0
CUBE(config-dial-peer)#voice-class sip bind media source-interface GigabitEthernet0/0

Binding the traffic to the respective interfaces ensures that all RTP and SIP packets are created with the virtual IP associated with the respective physical interface.

The following table provides details of the CLIs used in the configuration.

Option Description

dial-peer voice number voip

Defines a local dial peer.

  • The number argument identifies the dial peer. Valid entries are 1–2147483647.

description string

Provides a description for the dial-peer group.

destination-pattern string

Defines the phone number that identifies the destination pattern that is associated with the dial-peer.

session-protocol sipv2

Configures SIP as the session protocol type.

session target ip-address

Configures the network address of the remote router to which you want to send a call once a local voice-network dial peer is matched.

voice-class sip bind control source-interface interface-id voice-class sip bind media source-interface interface-id

Sets a source interface for signaling and media packets. The binding applies to the specified interfaces only.

  • control —Binds signaling packets.

  • binds —Binds media packets.

  • source-interface interface-id —Type of interface and its ID.

Step 8

Configure Media Inactivity feature.

Example:

Active and standby CUBE configuration
CUBE(config)#ip rtcp report interval 3000
!
CUBE(config)#gateway
CUBE(config-gateway)#media-inactivity-criteria all
timer receive-rtcp 5
timer receive-rtp 86400

the following table provides details of the CLIs used in the configuration.

Option Description

ip rtcp report interval time in milliseconds

Configures the average reporting interval between subsequent RTCP report transmissions.

gateway

Enters the gateway configuration mode.

media-inactivity-criteria all

Specifies the use of both RTCP and RTP for detecting the silence on a voice call.

timer receive-rtcp timer

Enable the Real-Time Control Protocol (RTCP) timer and configures a multiplication factor for the RTCP timer interval for Session Initiation Protocol (SIP) or H.323.

  • timer—Multiples of the RTCP report transmission interval. Range is 0–1000. Default value is 0. Recommended value is 5.

The Media Inactivity Timer enables the active/standby router pair to monitor and disconnect calls, if the router pair does not receive Real-Time Protocol (RTP) packets within a configurable time period.

When the active or the standby router does not receive RTP packets for a call, the SIP Media Inactivity Timer releases the session. The Media Inactivity Timer guards against any hung sessions resulting from the failover when a normal call disconnect does not clear the call.

You must configure the same duration for the Media Inactivity Timer on both routers.

Step 9

Reload the routers.

After completing all the preceding configuration steps, save and reload both the active and standby router.

Step 10

Point the attached devices to the CUBE HSRP Virtual IP (VIP) address.

The IP-PBX, Cisco Unified SIP Proxy, or service provider must route the calls to CUBE’s virtual IP address. This HA configuration does not handle SIP/H.323 messages to CUBE’s physical IP addresses.

Configuration Examples

Example Configuration for Dual-Attached CUBE HSRP Redundancy

Active Router Configuration

This section provides 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. 

ipc zone default
  association 1
    no shutdown
    protocol sctp
      local-port 5000
        local-ip 203.0.113.10
      remote-port 5000
        remote-ip 203.0.113.11
!
voice service voip
  mode border-element
  allow-connections sip to sip
  redundancy
!
redundancy inter-device
  scheme standby SB
!
redundancy
!
interface GigabitEthernet0/0
  ip address 203.0.113.10 255.255.255.0
  standby version 2
  standby 1 ip 203.0.113.12
  standby delay minimum 30 reload 60
  standby 1 preempt
  standby 1 track 2 decrement 10
  standby 1 track 3 decrement 10
  standby 1 priority 50

!
interface GigabitEthernet0/1
  ip address 192.0.2.1 255.255.255.0
  standby version 2
  standby 10 ip 192.0.2.5
  standby delay minimum 30 reload 60
  standby 10 preempt
  standby 10 track 2 decrement 10
  standby 10 track 3 decrement 10
  standby 10 priority 50
  
!
interface GigabitEthernet0/2
  ip address 198.51.100.1 255.255.255.0
  standby version 2
  standby 100 ip 198.51.100.5
  standby delay minimum 30 reload 60
  standby 100 preempt
  standby 100 name SB
  standby 100 track 2 decrement 10
  standby 100 track 3 decrement 10
  standby 100 priority 50

!
track 1 interface Gig0/0 line-protocol 
track 2 interface Gig0/1 line-protocol 
track 3 interface Gig0/2 line-protocol
!
dial-peer voice 100 voip
  description TO SERVICE PROVIDER
  destination-pattern 9T
  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  
!
dial-peer voice 200 voip
  description TO CUCM
  destination-pattern 555....
  session protocol sipv2
  session target ipv4:203.0.113.1
  voice-class sip bind control source-interface GigabitEthernet0/0
  voice-class sip bind media source-interface GigabitEthernet0/0
!
ip rtcp report interval 3000
!
gateway 
  media-inactivity-criteria all
  timer receive-rtcp 5
  timer receive-rtp 86400

Standby Router Configuration 

ipc zone default
  association 1
    no shutdown
    protocol sctp
      local-port 5000
        local-ip 203.0.113.11
      remote-port 5000
        remote-ip 203.0.113.10
!
voice service voip
  mode border-element
  allow-connections sip to sip
  redundancy
!
redundancy inter-device
  scheme standby SB
!
redundancy
!interface GigabitEthernet0/0
  ip address 203.0.113.11 255.255.255.0
  standby version 2
  standby 1 ip 203.0.113.12
  standby delay minimum 30 reload 60
  standby 1 preempt
  standby 1 track 2 decrement 10
  standby 1 track 3 decrement 10
  standby 1 priority 50

!
interface GigabitEthernet0/1
  ip address 192.0.2.2 255.255.255.0
  standby version 2
  standby 10 ip 192.0.2.5
  standby delay minimum 30 reload 60
  standby 10 preempt
  standby 10 track 2 decrement 10
  standby 10 track 3 decrement 10
  standby 10 priority 50
  
!
interface GigabitEthernet0/2
  ip address 198.51.100.2 255.255.255.0
  standby version 2
  standby 100 ip 198.51.100.5
  standby delay minimum 30 reload 60
  standby 100 preempt
  standby 100 name SB
  standby 100 track 2 decrement 10
  standby 100 track 3 decrement 10
  standby 100 priority 50

!
track 1 interface Gig0/0 line-protocol 
track 2 interface Gig0/1 line-protocol 
track 3 interface Gig0/2 line-protocol
!
dial-peer voice 100 voip
  description TO SERVICE PROVIDER
  destination-pattern 9T
  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  
!
dial-peer voice 200 voip
  description TO CUCM
  destination-pattern 555....
  session protocol sipv2
  session target ipv4:203.0.113.1
  voice-class sip bind control source-interface GigabitEthernet0/0
  voice-class sip bind media source-interface GigabitEthernet0/0
!
ip rtcp report interval 3000
!
gateway 
  media-inactivity-criteria all
  timer receive-rtcp 5
  timer receive-rtp 86400

Example Configuration for Single-Attached CUBE HSRP Redundancy

Active Router Configuration

Although 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. The sample configurations for both the active and standby CUBE routers are as follows: 

ipc zone default
  association 1
    no shutdown
    protocol sctp
      local-port 5000
       local-ip 203.0.113.10
     remote-port 5000
       remote-ip 203.0.113.11
!
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 203.0.113.10 255.255.0.0
  duplex auto
  speed auto
  keepalive
  standby delay minimum 30 reload 60
  standby version 2
  standby 0 ip 203.0.113.12
  standby 0 preempt
  standby 0 priority 50
  standby 0 name SB
  standby 0 track 1 decrement 10

!
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 86400

Standby Router Configuration 

ipc zone default
  association 1
    no shutdown
    protocol sctp
      local-port 5000
       local-ip 203.0.113.11
     remote-port 5000
       remote-ip 203.0.113.10
!
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 203.0.113.11 255.255.0.0
  duplex auto
  speed auto
  standby delay minimum 30 reload 60
  standby version 2
  standby 0 ip 203.0.113.12
  standby 0 priority 50
  standby 0 preempt
  standby 0 name SB
  standby 0 track 1 decrement 10
  
!
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 86400

Verify Your Configurations

Verify SIP IP Address Bindings

Use the show sip-ua status command to verify the SIP binding status. 

Router#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
==============     ===========     ==================
 192.0.2.1             5060               5061
 192.0.2.1             5060               5061
SIP early-media for 180 responses with SDP: ENABLED
SIP max-forwards : 70

Verify Current CPU Use

Use the show process cpu history command 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 used repeatedly to understand the CPU utilization for a particular process.

Verify the Call Processing During a Switchover

Use the show sip-ua statistics command to verify the 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.

Use the show interface accounting command 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

Note

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

Force a Manual Failover for Testing

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

You can expect that switchovers occuring in real environments, where there is a constant mixture of calls in transient (call setup or being modified) and established state, result in some dropped calls during a failover. You can estimate the number of dropped calls by using the following formula: (0.3 + HSRP hold-timer) * CPS.

To check that your configuration is correct, you can force a manual switchover.

You can achieve manual switchovers in various ways:

  • Initiate the manual switchover by using the redundancy switch-activity force command 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.

  • Shut down the HSRP interface of the active router.

  • 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, you must shut down the interface before you make any changes, 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.

Before you begin

Before you start a manual switchover, take note of the following:

  • Monitor the CPU utilization % on the active and standby pair. The active router has a higher CPU utilization as it is actively handling the calls, while the standby router shows 0 CPU utilization as it is idle until a switchover occurs.

  • Ensure that you perform a manual switchover 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 that the existing calls across the active and standby router pair are in sync.

Perform the following steps to configure and verify a single switch over:

SUMMARY STEPS

  1. Configure HSRP Box-to-box redundancy as explained in the Configuration section.
  2. Reload and keep both routers in rommon.
  3. Boot up one router. After the router comes up, execute the show redundancy state command and make sure it displays my state as active and peer state as Disabled. This can take a while after boot up.
  4. Boot up the second router. After the router comes up, execute the show redundancy state command and make sure it displays my state as standby-Hot and peer state as active.
  5. Start one or more calls across the system. Execute the show voice high-availability summary and show voip rtp connection commands on both the active and standby routers to make sure that 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 that the 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.
  7. Test Media Inactivity: Stop the call. Repeat show voip rtp connection . After the media-inactivity timer expiry, there must be no more active RTP connections. You can also check this using the show voice high-availability summary command.

DETAILED STEPS

Step 1

Configure HSRP Box-to-box redundancy as explained in the Configuration section.

Step 2

Reload and keep both routers in rommon.

Step 3

Boot up one router. After the router comes up, execute the show redundancy state command and make sure it displays my state as active and peer state as Disabled. This can take a while after boot up.

Example:

Router#show redundancy states

my state = 13 -ACTIVE 
peer state = 1  -DISABLED

Step 4

Boot up the second router. After the router comes up, execute the show redundancy state command and make sure it displays my state as standby-Hot and peer state as active.

Example:

Router#show redundancy states

my state = 8  -STANDBY HOT 
peer state = 13 -ACTIVE

Step 5

Start one or more calls across the system. Execute the show voice high-availability summary and show voip rtp connection commands on both the active and standby routers to make sure that the calls are up and checkpointed.

Step 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 that the 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.

Example:

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

Step 7

Test Media Inactivity: Stop the call. Repeat show voip rtp connection . After the media-inactivity timer expiry, there must be no more active RTP connections. You can also check this using the show voice high-availability summary command.

Example:

Router#show voice high-availability summary | include media

Media Inactivity event count: 1

Troubleshoot High Availability Issues

Use the following show and debug commands to troubleshoot any issues:

  • 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 high volume of active call traffic.


Note

On every switchover, after router reload, you must re-enable the debugs 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.

The following table illustrates the different router states.

States Description

Initial

This is the starting state and indicates that HSRP is not running. This state is entered through configuration change or when an Interface first comes up.

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.

Listen

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

Speak

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

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.

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 scenario 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 communication between the routers is down.

  • Use the debug standby command to see if the routers are sending and 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.