Cube Redundancy overview

The Cisco Unified Border Element platforms support different models (central, distributed or hybrid) to match different cost, scalability & redundancy requirements.

The following basic models exist:

A special case is to front-end the above with a SIP Proxy (CUSP) for more complex routing or if no load balancing is provided by the service provider.

The following mechanisms can be used to create redundancy and scalability:

Depending on the platform and mechanism choosen you’ll have support for media preservation and/or call signaling preservation. HSRP typically supports media preservation. The following table gives you the redundancy mechanisms per platform.

The most common implementations are based on HSRP.

Note that in case of the ASR platform a additional separate connection  between the platforms is needed (IPC).

For a good redundancy a  split over 2 datacenters is advised. At the same time the loadbalancing mechanisms can be used to increase the capacities.

Making  use of the sw/hw versatility off the Cisco IOS Routers, the BRI/PRI network can be used as an alternative backup.

Multiple failure scenario’s can exist and need to take into account.

1. CUBE Reaches Capacity

–Design for CAC and alternate routing

2. CUBE Router (HW, SW, power…) Failure

–Use CUBE HSRP or Inbox redundancy schemes as well as load balancing, clustering and alternate routing

3. CUBE-SP Connectivity Down

–Use SIP trunk monitoring mechanisms to trigger alternate routing (SIP OOD options ping)

4. CUBE-Enterprise-call-agent Connectivity Down

–Use SIP trunk monitoring mechanisms to trigger alternate routing

Hope this gave you a good overview on some of the redundancy mechanisms you could use.

As allways for info on Cisco CUBE goto

%d bloggers like this: