CUBE for CAC

[Rafael Chavantes]

I was reading the CUCM 7 SRND for CAC and got to the following cenario:

- Multiple clusters with intercluster trunk gatekeeper controlled and for SRND they recommend to use Gatekeeper for dial plan and CUBE for RSVP accross the WAN.

The question is is CUBE really necessary?

Can I just use a Gatekeeper and RSVP agent to do the bandwidth reservation? On the cenario they use RSVP Agent for doing bandwidth reservation for remote offices within the cluster.

I want your opnion about that and if I can do this without Cube, what is the benefits of using CUBE?

Thanks in advance

Ps: I have attached the Design from SRND I'm talking about

[asandborgh]

Hi Rafael,

Actually the CUCM 8.0 SRND has a better write up in it about this subject, even if you are running 7.X.  Beyond that you need the CUBE because this is inter-cluster and the RSVP agent arrangement only works on intra-cluster calls.

I did this for a three cluster global implementation way back with CCM 5.1 and the documentation was not nearly as good as it is today, but it is still a bit intimidating.  We used 6 CUBEs  (three redundant sets - one set for each cluster - a bit overkill, but durable) with via-zone gatekeepers.  The CUBEs were also PSTN gateways and DSPfarms so they were not dedicated just to IP to IP gateway duties.

They have built some nice additions into it since then so that it traverses the carrier MPLS sections (where the IP addresses are not visible) much better.

HTH,

Art

[Rafael Chavantes]

Art thanks for your reply.

You last question that i would like to make is:

If I use just Gatekeepers in intercluster trunks for CAC and dial-plan management what are the disadvantages when comparing to a solution using cube for CAC and gatekeeper for dial plan?

[asandborgh]

Hi Rafael,

Well, first I have to thank you for keeping me straight.  Attached is an image from the CUCM 5.X SRND.  At that time they required an IPtoIP Gateway (now called CUBE) for RSVP across the WAN.  Apparently since then they have changed that and it is no longer required - Sorry for misleading you!  Please note that if you don't have multiple WAN/MPLS links arriving at any location (if they are all single links) you don't need RSVP, and if your dial plan is simple you really don't need gatekeepers.  Some of the global dialplans are so simple that they can be handled in each CUCM by region> If you have a standard on-net prefix (leading 8 for instance) then next digit may indicate which cluster for example - all Americas numbers begin with 1,2,3 - EMEA begins 4,5,6, - APAC starts 7,8,9. and then you could have 2 digits for an office code - (netting 300 offices in each region) and 4 digits for a subscriber.

At any rate here are the current recommendations from the 8.X SRND on CAC:

The following recommendations apply to deployments with multiple Unified CM clusters:

• For simple hub-and-spoke topologies with no dual links, use Cisco IOS gatekeeper zones between sites where Unified CM clusters reside.

• For two-tier hub-and-spoke topologies with no dual links where Unified CM clusters are located at the first and second level hub sites, use Cisco IOS gatekeeper zones for the links between first- and second-level hub sites and use Unified CM static locations for the links between second-level hub sites and spoke sites.

• For MPLS topologies with no dual links, use Unified CM static locations, with every site in a location and with no gatekeeper zones. Leave intercluster trunks in the Hub_None location unless an MTP is required. You may use a gatekeeper for intercluster call routing, but it is not needed for call admission control.

• For any other topology, use RSVP.

Sorry again about the misinformation!

Art

[Rafael Chavantes]

Art,

Don't worry about the information as Cisco changes recomendations and new technologies are arriving all the time, always will be something new and what we thought was the best way to do will be old.

Now, I have some doubts about MPLS topology "dual links", what they wnat to say when they say dual links?

My topology is 4 Major sites conected to a MPLS link and for backup links we use internet using VPN, there are minor sites conected to the major sites using direct links. There are also cases where a minor site that uses CUCM from a major site and that minor site is connected over the MPLS cloud.

Hope you understand, basically major sites are the CUCM clusters and minor sites uses those clusters. Minor sites can be connected using direct links to the major sites or directly to the MPLS cloud.

What we want to do is conected those clusters using trunk, we are going to use Gatekeepers for dial plan, the question is on the RSVP side.

[asandborgh]

Hi Rafael,

From what you describe you have multiple paths in and out of the larger sites, so you probably want to use RSVP for CAC (unless NO voice will ever use the backup links and you only have ONE MPLS circuit).  Dual links means dual physical/logical circuit paths where one may go down.  If you set CAC to a static amount  - say the combined bandwidth of both links and loose one then you oversubscribe the other.  If you set it to just the bandwidth of one link then you will not be using the full bandwidth you are paying for.  RSVP is topology aware so it will determine during the reservation whethere bandwidth for the call is available.

HTH,

Art

[Rafael Chavantes]

I got it now Art.

Having this said some new questions came up:

1- The backup links have a smaller bandwidth there is a way of configuring so the system know we are running on the backup link and allocated less bandwidth for calls? Or if I don't allow calls on the backup link CUCM will "know" that and re-route calls over the second route group (PSTN Gateway) on the route list?

2- In case of a minor site place a call to another cluster. How can we guarantee that the link between the minor site and the major site will not have oversubscription?

[asandborgh · Accepted solution]

Both cases are perfect examples of why you should use RSVP in your case - it should gracefully

handle CAC for both.  The 8.0 SRND really does have an excellent write up on how it works.  It is a bit intimidating to set up the first time but it does work well.  Be sure to read the section about "Previous Hop Overwrite" - a common issue with MPLS - it caused me all kinds of pain.

Art