Solved: Issues with double clustering with Cisco ICT and Gatekeeper controlled trunk.

rodmont74 · ‎04-23-2010

Hi, my company has deployed several clusters across the globe and as is piloting some integration and call forwarding between them. So far there are 3 clusters interconnected with Cisco ICT in South America working fine with a dial plan that intercepts regular international dialing numbers, translate them into a working number for the trunks and it's transparent for end users.

In Europe there are some clusters interconnected with a gatekeeper and routes are dialed using a specific prefix containing asterisks followed by country code and extension number.

In order to test calls between South America and Europe, a new gatekeeper was deployed in South America on where 3 trunks were set up for each one the clusters and the gatekeeper has proper routes to them and to the Europe gatekeeper.

All calls between South America and Europe work back and forth but call between South America clusters in gatekeeper routes fail. It looks like there is a know issue about having two trunks (one using gatekeeper and another without it).

Does someone know a work around to it or has any suggestions? I've simplified the scenario, there are other details I can breakout if needed/interested.

thanks

Robert Thomas · ‎04-26-2010

Rod,

I have run into the issue you are having. The CUCM basically used the source IP to match againt the IP configured on the trunks. Because both trunks have the same source IP, they will "bump" against each other. If you gather a trace what I run into most ofter is having a no potential matches exist, because the CUCM is trying to match the 1# style call in the regular NON-ICT trunk. It doesn't even get to perform a digit analysis. And you will see the GK doing ACF all day long without issues.

So far I have had to get rid of one of the two in the past to get calls going. It would be nice to see if someone has a known workaround.

Cheers,

View solution in original post

Robert Thomas · ‎04-27-2010

Rod,

In the end, in a production environment you will have either a GK ICT or NON-GK ICT, because having both will just bypass the CAC implementation. You should have a very specific reason to have both. Redundancy in a GK ICT will come in the form of HSRP with GK or GK clustering.

Most of the time you will find this issue on a lab environment or a "test for concept" but on a live network the NON GK ICT will bypass your CAC controls.

Cheers,

View solution in original post

Robert Thomas · ‎04-26-2010

Rod,

I have run into the issue you are having. The CUCM basically used the source IP to match againt the IP configured on the trunks. Because both trunks have the same source IP, they will "bump" against each other. If you gather a trace what I run into most ofter is having a no potential matches exist, because the CUCM is trying to match the 1# style call in the regular NON-ICT trunk. It doesn't even get to perform a digit analysis. And you will see the GK doing ACF all day long without issues.

So far I have had to get rid of one of the two in the past to get calls going. It would be nice to see if someone has a known workaround.

Cheers,

rodmont74 · ‎04-27-2010

Thanks a lot. I had opportunity to retry GK calls by shutting down ICT between both clusters and call worked fine. In the end of the day, we probably going to decide in one of the solutions.

rgds

Robert Thomas · ‎04-27-2010

Rod,

In the end, in a production environment you will have either a GK ICT or NON-GK ICT, because having both will just bypass the CAC implementation. You should have a very specific reason to have both. Redundancy in a GK ICT will come in the form of HSRP with GK or GK clustering.

Most of the time you will find this issue on a lab environment or a "test for concept" but on a live network the NON GK ICT will bypass your CAC controls.

Cheers,

rodmont74 · ‎04-27-2010

Thanks for the info, that's the way expect it's going to be handled. Right now pure ICT to a Global Routing Cluster is used and is in production in Americas region while GK is deployed EU. Either we move GK trunks to this GRC (it's cluster tasked in forwarding call setups between other clusters like a hub configuration) or use a single GK trunk from Americas GRC to EU GK so no two trunks are deployed to same clusters pairs.

It's all a working in progress, South America clusters are ICTed against each other while they are all in turn ICTed against GRC which is not prepared yet to route calls between South America clusters. Most results of non global integration at the time they were depeloyed. Canada recently migrated its Nortel infrastructure to 100% IP so it's going to stay for a very long time, which gives an excuse to research on SIP trunks. EU countries have large Alcatel deployments which adds one more setup chalenge to integration!

Rgds