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.
- 1 General Overview of Cisco CUBE HA
- 2 Cisco CUBE HA Configuration
- 3 Configuration for the Second Router
- 4 Verification and Testing
- 5 Cisco CUBE HA Testing configuration
- 6 UC Pros Community
Build pro IOS configs. FAST.
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:
- 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.
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
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.
timers delay 30 reload 60
control GigabitEthernet3 protocol 1
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
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.
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
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
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.
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.
IP address 10.10.1.2 255.255.255.0
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: YesRF 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”
Build pro IOS configs. FAST.
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!