i just wanted to get an idea of what you guys do for this. basically we have three sites each with thier own Pub and Sub at the moment. we would like to redesign to have all in one cluster. Simply put, we would like all sites to be able to still communicate with each other even though one of the main sites goes down.
my question is more from a WAN prospective. to enable this to happen im assuming that you need multiple paths from either the router to router end or from the carrier end, more like a mesh network.
what do carriers normally provide for this type of situation? would a MPLS type carrier infrastruture fit the requirement ( i know thats a bit general)
MPLS (with proper QOS) is an excellent choice here. There are some general recommendations and considerations from the CCM SRND below;
Clustering over the WAN can support two types of deployments:
â¢Local Failover Deployment Model
Local failover requires that you place the Cisco Unified CallManager subscriber and backup servers at the same site, with no WAN between them. This deployment model is ideal for two to four sites with Cisco Unified CallManager
â¢***Remote Failover Deployment Model
Remote failover allows you to deploy the backup servers over the WAN. Using this deployment model, you may have up to eight sites with Cisco Unified CallManager subscribers being backed up by Cisco Unified CallManager subscribers at another site.
You can also use a combination of the two deployment models to satisfy specific site requirements. For example, two main sites may each have primary and backup subscribers, with another two sites containing only a primary server each and utilizing either shared backups or dedicated backups at the two main sites.
The key advantages of clustering over the WAN are:
â¢Single point of administration for users for all sites within the cluster
â¢Shared line appearances
â¢Extension mobility within the cluster
â¢Unified dial plan
These features make this solution ideal as a disaster recovery plan for business continuance sites or as a single solution for up to eight small or medium sites.
For clustering over the WAN to be successful, you must carefully plan, design, and implement various characteristics of the WAN itself. The Intra-Cluster Communication Signaling (ICCS) between Cisco Unified CallManager servers consists of many traffic types. The following design guidelines apply to the indicated WAN characteristics:
The maximum one-way delay between any Cisco Unified CallManager servers for all priority ICCS traffic should not exceed 20 ms, or 40 ms round-trip time (RTT).
Jitter is the varying delay that packets incur through the network due to processing, queue, buffer, congestion, or path variation delay. Jitter for the IP Precedence 3 ICCS traffic must be minimized using Quality of Service (QoS) features.
â¢Packet loss and errors
The network should be engineered to provide sufficient prioritized bandwidth for all ICCS traffic, especially the priority ICCS traffic. Standard QoS mechanisms must be implemented to avoid congestion and packet loss. If packets are lost due to line errors or other "real world" conditions, the ICCS packet will be retransmitted because it uses the TCP protocol for reliable transmission. The retransmission might result in a call being delayed during setup, disconnect (teardown), or other supplementary services during the call.
Provision the correct amount of bandwidth between each server for the expected call volume, type of devices, and number of devices. This bandwidth is in addition to any other bandwidth for other applications sharing the network, including voice and video traffic between the sites. The bandwidth provisioned must have QoS enabled to provide the prioritization and scheduling for the different classes of traffic. The general rule of thumb for bandwidth is to over-provision and under-subscribe.
â¢Quality of Service
The network infrastructure relies on QoS engineering to provide consistent and predictable end-to-end levels of service for traffic. Neither QoS nor bandwidth alone is the solution; rather, QoS-enabled bandwidth must be engineered into the network infrastructure.
so just to be clear with a transition of Hub/Spoke to MPLS the topology would now change from the previous to a "ring" with all locations being "independent" of each other from a WAN prospective. I.E. there wouldnt be any Main site that every location depends upon now but a series of sites that all other sites can reach.
Also from a strictly IPT propsective. we are looking at Three Main sites but locations connecting to either of the three sites are a total of 20 sites. im seeing that there are some limitations with respect to the amount of locations.
basically, we would have three "main sites" that are in one cluster. then 20 branch sites with SRST configured to register with any available of the three sites.
What version of Communication Manager are you running? and how far apart are these three sites?
Based on your initial description you have 3 clusters at present.
Ideally you should run a distributed cluster interconnected using an MPLS WAN. In this topology you can place the publisher on one site plus a subscriber server at each of the remote sites.
If your running version 6.1 of Communication Manager the round trip latency between servers can be upto 80ms. This will limit the geographic spread of the cluster.
The MPLS provider will be able to offer a Service Level Agreement covering latency, packet loss and jitter so make sure these meet the minimum requirements. Packet loss should be less than 1% and jitter less than 30ms.
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...