Cisco Unified Border Element (CUBE) has been traditionally supported as an installation on physical routers such as Cisco
Aggregation Services Router Series (ASR) and Cisco Integration Services Router Series (ISR). From Cisco IOS XE 3.15S release
onwards, the CUBE feature set is supported on the Cisco CSR 1000V Series Cloud Services Routers (Cisco CSR 1000V) in a virtualized
form factor. Virtual CUBE (vCUBE) enables the traditional CUBE feature set to be deployed in cloud-based data center deployments.
Information for Virtual CUBE
The following table provides release information about the feature or features described in this module. This table lists
only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise,
subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco
Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Table 1. Feature
Information for Virtual CUBE Support
CUBE Feature Support
XE Release 3.15S
support for virtual CUBE on Cisco Cloud Services Router, Cisco CSR 1000V
Prerequisites for Virtual CUBE
The Virtual CUBE (vCUBE) feature set is bundled as part of the Cisco CSR 1000V Series and is supported on VMware's ESXi hypervisor
and Cisco UCS servers (UCS-C and UCS-E series). For more information on the Cisco CSR1000V series and their supported ESXi
versions, see Installing the Cisco CSR 1000v in VMware ESXi Environments.
For Cisco IOS XE Gibraltar 16.10 and later releases, VMware ESXi 6.5 update 1 is the recommended VMware version. For more
information on supported hypervisors, see Product Specifications.
We recommend that you disable hyper threading while configuring Virtual CUBE on Cisco UCS. For more information on the best
practices for setting BIOS parameters for performance, see BIOS Settings.
A minimum of two
network interfaces are required for configuring Virtual CUBE.
relevant license for the Cisco CSR 1000V router. For details on the licensing
package support, see
Licensing Package Support.
appropriate Cisco IOS image on the Cisco CSR 1000V router and configure a
working VoIP network. For details on installation, see
For details on the ESXi hypervisor support, see the section on
with Virtual CUBE
Virtual CUBE supports most of the features available in CUBE. However, any feature that manages the media plane is not expected
to work in the Cisco CSR 1000V router. The following features are not supported in virtual CUBE:
All DSP based
Progress Analysis (CPA)
Reduction (NR), Acoustic Shock Protection (ASP), and Audio Gain
Class Codec (VCC) support
supported on peer leg will be included in offer. Other codecs will be filtered
Software MTP is not supported on Virtual CUBE.
All caveats, restrictions, and limitations of Cisco ASR IOS-XE 3.15 and later releases are applicable to Virtual CUBE.
Virtual CUBE Support on Cisco CSR 1000V Series Routers
Virtual CUBE uses Redundancy Group infrastructure for High Availability (HA). For High Availability, the two virtual CUBE
CSR instances must be running on the same host or across different hosts that are connected through a switch. Geographic stateful
switchover is not supported.
On the Cisco CSR 1000V, the box-to-box redundancy option uses the Redundancy Group (RG) Infrastructure to form an Active and
Standby pair of routers. The Active and Standby pair share the same virtual IP address (VIP) and continually exchange status
messages. Virtual CUBE session information is check-pointed across the Active and Standby pair of routers enabling the Standby
router to take over all Virtual CUBE call processing responsibilities if the Active router should go out of service. The Standby
router sends and receives all redundancy-related traffic (protocol packets, configuration data, keepalives, and peer status).
Calls in the transient state at the time of failover are disconnected.
Introduction of CSR 1000V
Network Interfaces for HA Interaction
Cisco CSR 1000V can run on the VMware ESXi hypervisor. Install the Cisco CSR 1000V .iso file on your host and manually create
the virtual machine (VM) using your hypervisor software. VMware ESXi runs on servers with x86-based CPUs. You can use the
same hypervisor to run several VMs. The ESXi host is connected to a port on the physical switch. In this environment, VMware
ESXi provides the virtual switch (vSwitch) functionality that routes traffic internally between virtual machines and links
to external networks.
Stateful Switchover for
Stateful switchover (SSO) occurs when the Cisco CSR 1000V Active router crashes and reload happens. A switchover from the
active to the standby router occurs when the active Route Processor fails, or when the keepalive messages between the Active
and Standby router is lost. In a usual scenario, the Standby router sends RG Infra keepalive message to the Active router
and expects an acknowledgment within 100 msec as per the default timer. If there is no acknowledgment of keepalive within
100 msec, the Standby router immediately sends a message to the Active router to check the HA status. If there is no keepalive
message response, the Standby router declares the Active router (it goes into reload state) is dead and assumes the role of
the Active router.
Key Considerations for
Deploying HA on Virtual CUBE
The following are
some of the key points to consider while deploying a Virtual CUBE instance in
HA mode on the Cisco CSR 1000V router:
Virtual CUBE stateful switchover occurs only due to software failures—The Active router reload when the Cisco CSR 1000V crashes
due to software faults. When a software fault causes the active router to go to the reload state, the Standby router assumes
the role of the new Active router.
Virtual CUBE tracks only the next vSwitch interface—Virtual CUBE HA supports tracking of only the interface link status. In
the case of virtual CUBE, the interface is always connected to the vSwitch of the hypervisor. The interface link status of
the Virtual CUBE shows that it is up even when the physical link of the server is down as the vSwitch link is still active.
It may be possible to configure the hypervisor vSwitch to propagate the physical link status to the Virtual CUBE interface.
Here, the interface tracking accurately reflects the status of the physical interface. Refer to the software documentation
of the hypervisor you are using.
In a scenario where the physical switch is down, both the Active and Standby routers become the Active router. Here, the
Active router is still up and running whereas the Standby router assumes that the Active router has gone down as it does not
receive any keepalive messages or peer information from the Active router. Hence, the Standby Router also turns to the Active
router. Though Virtual CUBE continues to maintain existing calls and also receive new calls while both routers are active,
HA checkpointing fails.
Virtual CUBE does not track uplink failures—You must not use switches that are used to connect non-networking end devices
or must not track LAN for determining uplink failures. Basically, switches used in the aggregation layers are not tracked.
Implementation of High Availability is same for the physical CUBE and
Virtual CUBE on IOS XE platforms. For more information on High Availability,
High Availability Overview.
Configuration Example for High Availability on Virtual CUBE
Configuration on both the Virtual CUBEs must have identical physical
configuration and must be running on the same type of platform and the IOS XE
version. Anytime a platform is reloaded in a Virtual CUBE high availability
implementation, it always boots up as the standby router.
Router# configure terminal
priority 100 failover threshold 75
control GigabitEthernet 0/0/2 protocol 1
data GigabitEthernet 0/0/2
timers delay 30 reload 60
voice service voip
allow-connections sip to sip
ip rtcp report interval 3000
timer receive-rtcp 5
timer receive-rtp 86400
Virtual CUBE media performance depends on the underlying VM platform consistently providing packet switching latency of less
than 5 ms. Latency and jitter values observed on a virtual CUBE are same as the values obtained on CUBE running on a hardware
platform with recommended hardware configuration and identical software configuration, under the same network conditions.
Virtual CUBE is
enabled with the APPX and AX license packages. The AX license package provides
access to all features supported in virtual CUBE. When the license is
installed, the virtual CUBE related CLI commands such as voice and dial-peer
configurations are visible. Also, relevant CUBE processes are instantiated.
The following table
details the license package support for a virtual CUBE.