CUBE Active/Active Config with internal route link detection
I have 2 x Cisco cubes 4451 both linking to the same ITSP and they give us a 50/50 load of calls to the 2 different cubes in 2 different DC's.
My question here is, is the Cisco Cube capable if for some reason the external link to the ITSP is up so their SIP Ping options returns that the cube is up but the internal part for example is down (due to a firewall or switch) can the cubes be configured to re-route the calls between them with say a "direct" link between them when detected the internal interface is down?
This this at all possible to monitor the different loopback interfaces and should it be detected that one is down to a PABX to re-route the call via the other CUBE is can reach this PABX for example?
This is not possible out of the box. You can use object tracking to detect failures (for example ping failure to loop back or bgp route disappearing) and accordingly shutdown interfaces on the active cube. This can trigger box-to-box failover for the standby cube to start serving calls.
Having that said, box-to-box failover is supported for cubes in the same DC. It can work on cubes in different DCs with L2 WAN such as OTV or VPLS but not supported by Cisco.
Thank you for the reply, this is actually very shocking that Cisco don't support such a feature on their CUBES, if I am not mistaken Oracle SBCs for example has the capability to detect links down and re-route traffic on a different interface to a different DC for example.
We have ping option configured but the ITSP sees the external interface that is up and return the ping options but now your internal interface linking to a FW or a switch is down, so the physical cube interface is not down but your route is down and one would have thought you could configure maybe a re-route traffic to a different interface on an SIP error 5XX or unavailable message from the internal side of the network.
An the ITSP won't re-route to the other DC as the error is not on the external leg of the call but the internal leg of the call so it will just keep on trying.
Cisco Finesse Not Ready - Call Overlap status is very a very common issue seen on Finesse desktop. Agents miss two calls and they are put in Not Ready - Call Overlap status. This is very likely related to CVP server and it's unreachabl...
Lab 1: Cisco Meeting Server Standalone CertificatesLab 2: Cisco Meeting Server Cluster Certificates with Multi-SANLab 3: Multiple Certificates with Multiple CA ServersLab 4: Cisco Meeting Server Cluster Certificates Advanced ScenarioLab 5: Streamer Servic...
Certificates are the first step to deploy Cisco Meeting Server, preparing certificate are very important to enable different services. As a VOIP administrator, mastering the concept of certificates is unavoidable
Using multiple CA servers, instead of a si...
I just finished to write a comprehensive certificates preparation for Cisco Meeting Server Clustering. Through 60 pages I explained in detail, how to create certificates for database cluster, callbridge cluster, certificate chain for webbridge3, certifica...