How To Properly Configure Cisco CUBE HA

Cisco CUBE HA is becoming more prevalent with the CSR1000 or vCUBE, therefore with its popularity, learning how to configure Cisco CUBE HA has become an essential skill that UC engineers should have.

General Overview of Cisco CUBE HA

Cisco CUBE HA provides preservation of:

• Transcoded calls
• Media and Signaling for Active Calls
• Calls in Process where media has not been established yet

However, Cisco CUBE HA does not support the following:

• IPv6
• SRST
• SCCP based media resources such as conference bridges, transcoders, mtp, etc.

Cisco CUBE HA is similar in configuration to HSRP.

Similarly, it is specifically designed for the newest Cisco Unified Border Element routers, and for maintaining calls in the event one of the routers fails.

Phone calls are stable without any disruption.

The diagram below shows a Call established with an active router of an HA pair.

When the active router becomes unavailable, therefore, the standby becomes available.

 At the same time, a Virtual IP Address is used and all routing is transferred to the standby routers Virtual IP (this virtual IP address is the same as the active router).

The media and signaling of the call continue on the standby router as if there were no interruption.

In other words, the two CUBE routers should be of the same hardware and/or IOS version.

For Example:
You cannot have a 3900 router with an ISR 4K router as the configuration is different. In the ISR-G2 routers, HA is accomplished using the Hot Standby Routing Protocol (HSRP).

HSRP will be covered in another blog post.

For now, we shall be exploring ASR 1000, ISR 4K, and CSR1000 routers, using Redundancy Group Infrastructure configuration.

Cisco CUBE HA Configuration

In this blog post, we are going to go over each configuration and see how it fits in the overall picture. After that, we’ll go over their verification, configuration, and testing process.

Similarly, the configuration we shall use assumes that we have an internal and external interface.

In addition, there will also be an interface for the checkpointing configuration which will be explained.

By the way, here’s a network topology of what we will be working with

Enterprise Network                                           Carrier Network

Monitoring Configuration

Firstly, monitor the status of the internal and external interfaces of vCUBE- this is Gig1 and Gig2.

Monitoring the line-protocol status of the interfaces allows the redundancy application to determine when a resource has gone offline.

track 1 interface GigabitEthernet1 line-protocol
track 2 interface GigabitEthernet2 line-protocol

Redundancy Application Configuration

Secondly, we will configure the redundancy options.

redundancy
application redundancy
group 1
name cubha
priority 101
timers delay 30 reload 60
control GigabitEthernet3 protocol 1
data GigabitEthernet3
track 1 shutdown
track 2 shutdown

The default priority is 100. The router with the highest priority will be the active router.

At the same time, if something happens to either the active router or the standby router, the priority of the router is decremented by the decrement value.

This can be configured.

However, if the priority of the active router goes below the standby router, the standby router becomes the active router in the switchover.

Which means that other circumstances which will cause a switchover:

• Reload or loss of power on the active router.
• The command “redundancy application reload group rg-number self” is issued to manually reload the active router.

Timers– timers delay 30 reload 60
Delay
The amount of time to delay the RG group’s initialization and role negotiation after the interface comes up – Default 30 seconds and Range is 0-10000 seconds.

Reload
Take note that the amount of time to delay RG group initialization and role-negotiation after a reload – Default 60 seconds, and Range is 0-10000 seconds

Checkpointing Configuration

Data GigabitEthernet3
This command configures the interface used for check-pointing. In other words, “Check-pointing refers to the facility or architecture to implement state-full switchover (SSO).

Similarly, it provides the mechanisms that help synchronize state data between active and standby route processors or chassis in a consistent, repeatable, and well-ordered manner.”

Control GigabitEthernet3 protocol 1
On the other hand, this command configures the interface to exchange keepalive messages between the two routers.

track 1 shutdown
track 2 shutdown

In short, these commands correlate to if Gig1 and Gig2 line protocol go down- which will trigger the failover process.

Voice service voip Configuration

Let’s now turn on CUBE redundancy – I am assuming other configurations such as interface IP addressing and voice service VoIP configuration have been done.

voice service voip
redundancy-group 1

Therefore, this command prompts for you to reload the router.  This can be done now or after you have configured the rest. 

However, a reload must happen for the HA configuration settings to take effect.

Interface Configuration

Next, we configure the internal and external interfaces of the router.

We will also need to configure Gig3 which will be used for the check-pointing or keepalives between the two routers.

interface GigabitEthernet1
redundancy rii 1
redundancy group 1 IP 172.16.10.1 exclusive (the same virtual IP address will be used on the second CUBE)
interface GigabitEthernet2
redundancy rii 2
redundancy group 1 IP 10.10.10.1 exclusive (the same virtual IP address will be used on the second CUBE)

The Command “redundancy rii” (Redundant Interface Identifier) is used for generating a Virtual MAC (VMAC).

For instance, using the same rii ID value on each interface of each CUBE router that has the same Virtual IP Address (VIP). The RG group number that was configured in the redundancy configuration is used when assigning the Virtual IP Address (VIP).

The exclusive command means that the interface that is associated with an active redundancy group exclusively owns the VIP Address and the Virtual MAC.

When a failover occurs, the ownership of the VIP and Virtual MAC changes.

After that, the interface associated with the now active redundancy group programs the interface’s Ethernet controller to accept the packets going to the Virtual MAC.

The checkpointing interface only needs the IP address. 
No other configuration is necessary.

Both CUBE routers must be connected to the same switch and be configured with an IP Address on the same subnet.

interface GigabitEthernet3
IP address 10.10.1.2 255.255.255.0
no shut

Configuration for the Second Router

Most of the configuration on the second router will be exactly the same. 

However, the interface IP addresses will be different.

The priority in the redundancy application will be lower than the desired active router, but, the virtual IP address will always be the same.

All dial-peers, voice translations, etc. will all be the same so that all functionalities will be the same upon failover.

track 1 interface GigabitEthernet1 line-protocol
track 2 interface GigabitEthernet2 line-protocol
!
redundancy
application redundancy
group 1
name cubeha
priority 100 (Must be a lower value than the first CUBE)
timers delay 30 reload 60
control GigabitEthernet3 protocol 1
data GigabitEthernet3
track 1 shutdown
track 2 shutdown
!
voice service VoIP
redundancy-group 1 ß Again, this will prompt for reloading
!
interface GigabitEthernet1
redundancy rii 1
redundancy group 1 ip172.16.10.1exclusive
!
interface GigabitEthernet2
redundancy rii 2
redundancy group 1 ip10.10.10.1exclusive
!
interface GigabitEthernet3
ip address 10.10.1.1 255.255.255.0
no shut

Therefore, save the configuration on both routers and reload, regardless if you had reloaded before when prompted.

Verification and Testing

Now let’s verify the configuration.

CUBE1#sh redundancy application group 1
Group ID:1
Group Name:cubeha

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: ACTIVE (Shows the role of this router which means CUBE 1 is active)

Peer Role: STANDBYß Shows the role of the second router which means CUBE 2 is in Standby

Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

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

CUBE2#sh redundancy application group 1

Group ID:1
Group Name:cubeha

Administrative State: No Shutdown
Aggregate operational state: Up
My Role: STANDBY
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

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

Cisco CUBE HA Testing configuration

This process requires a call to go through the CUBE router.

Enter the following command:

vCUBE1#redundancy application reload group 1 self

This can also be done on the secondary router by putting in “peer” at the end of the command instead of “self”.

In conclusion, this will reload the router, and you will see that the call has transferred over to CUBE2. 

Therefore, you can verify this by entering

“show sip call”

UC Pros Community

By the way, would you like to be a part of like-minded UC Engineers, interact, ask questions, and learn from one another?

Join this FORUM and meet UC Engineers from different parts of the world!