Inter-Cluster Trunk (Non-Gateway Controlled) won't register

[philip-cr]

I figured out a workaround for this issue, but found it very curious. My Inter-Cluster Trunk only registers to my Subscriber Nodes. If I change the IP in the trunk to either of my Publisher Nodes then it no longer routes calls through it.

Any ideas as to what could cause a Publisher to not be registered for this? The SIP trunks work fine.

It's a test environment and I have an extremely basic setup:

[Elliot Dierksen]

Are the services required for that trunk to work on the publisher enabled there? Is the trunk associated with a call manager group that includes the publisher? If not, is the 'run on all nodes' checkbox available?

[philip-cr]

I'm unsure of what services, but in serviceability everything is running. Yes the call manager group includes the whole cluster on both clusters. Run on all nodes is also checked.

[Roger Kallberg]

I wonder what you mean by this “If I change the IP in the trunk to either of my Publisher Nodes”? There can only be one Publisher and you’re referring to it in plural. Is that a typo?

[philip-cr]

I have 2 Clusters, I'm making an ICT non-gateway between the two clusters. So if I point the ICT's at the other cluster's Subscriber Node then it works, but if I point them at the other cluster's Publisher Node then it fails.

[philip-cr]

I've narrowed it down even more:

ICT-A (run on all nodes) ---> cucm-pub-b.abc.inc  &   ICT-B (run on all nodes) ---> cucm-pub-a.abc.inc === DEAD
ICT-A (run on all nodes) ---> cucm-sub-b.abc.inc  &   ICT-B (run on all nodes) ---> cucm-sub-a.abc.inc === WORKS
ICT-A (run on all nodes) ---> cucm-pub-b.abc.inc  &   ICT-B (run on all nodes) ---> cucm-sub-a.abc.inc === A to B WORKS, B to A DEAD.
ICT-A (run on all nodes) ---> cucm-sub-b.abc.inc  &   ICT-B (run on all nodes) ---> cucm-pub-a.abc.inc === B to A WORKS, A to B DEAD.


It's like if the recipient is pointing to the Publisher then the call fails...

[philip-cr]

This is the last situation I listed above: ICT-A (run on all nodes) ---> cucm-sub-b.abc.inc  &   ICT-B (run on all nodes) ---> cucm-pub-a.abc.inc === B to A WORKS, A to B DEAD.

Phones registered to Cluster B can call Cluster A, but not vice versa.

      

[Jonathan Schulenberg · Accepted solution]

Please reconsider and stick to SIP. With the appropriate SIP Trunk Security Profile, SIP Profile, and trunk settings it's capable of everything a legacy ICT is - and more. Setting up a new H.323 trunk in the year 2025 is crazy IMO; that's a CCM 3.x feature from 20+ years ago. It will also necessitate protocol interworking between H.323 and SIP - all current generation IP Phones, CUBE or other SBC to the PSTN, CUC SIP integration, etc. - which often creates problems, especially between H.323 fast/slow start and SIP early/delay offer/media. H.323 is dead to Cisco.

If this is some sort of lab exercise, I guess you could also check DNS hostname resolution from each side to confirm that's working (does utils network host from one pub successfully resolve the other pub?) - or configure by IPv4 address instead. And failing that, you'd need to pull CCM SDL traces from both sides to see what's happening; maybe a PCAP.

[Roger Kallberg · Accepted solution]

Totally agree with @Jonathan Schulenberg on that using a legacy ICT trunk, that is using H.323, is not recommended. A SIP trunk between the two CM clusters is a much better choice for all the reasons Jonathan listed and a bunch more. @philip-cr Is there a specific reason for why you’re setting up a legacy inter-cluster trunk?

[philip-cr]

It is only for my CCNP course that I'm doing it in a lab environment.

[Roger Kallberg]

It’s been years since I did any CCNP training, but if it includes legacy ICT trunks I’d be quite surprised as it’s not been a thing seen in wild life deployments in many years. Cisco as a whole is moving off H.323 and even deprecating the protocol as a whole in IOS. It won’t be a big leap of mind to expect this being deprecated in CM as well.

[philip-cr]

This is a lab environment, no DNS issues involved, they all resolve. I tried IPv4 instead and still the same results. Only the Subscriber works.

[Roger Kallberg]

Is the Call Manager service activated and running on the Publisher nodes?

[philip-cr]

Yes Call Manager is running on all nodes it is also in the Call Manager Group. (I tried putting Publisher on top and still the same result)

[Marco Rojas Abarca · Accepted solution]

Dear Philip-cr,

I suspect a configuration issue here. I have had tons of cases with similar symptoms over the years. If my memory serves right, the destination IP Addresses of each trunk need to match the order of servers configured in CM Group of the Device Pool set in the ICT of the opposite site.

So, after looking at the pictures you shared, here is what you have:

From ICT A --> ICT B you have the following configured:

Device Pool: Avengers HQ
Destination: cucm-sub-b.abc.inc

From ICT B --> ICT A you have the following configured:

Device Pool: Main Base
Destination: cucm-pub-a.abc.inc

You need to go and check the CM Group of both Avengers HQ and Main Base and take note of the order configured of each other.

Then, in ICT A Server IP Address/Hostname section, you need to add servers in the the same order as configured in the CM Group of Device Pool Main Base.

Finally, in ICT B Server IP Address/Hostname section, you need to add servers in the the same order as configured in the CM Group of Device Pool Avengers HQ.

Hope this information helps,
Sincerely,
Marco R.