MQ

Hello,

let me have an other cluster-related question. I didn't find any answer in the documentation.

In out cluster, we have 2 cluster full repositories (DISP_T5A and DISP_T5B) with the following-like cluster sender and receiver channels. They have SSL parameters:

On QM DISP_T5A:
------------------
ALTER QMGR REPOS(T5_CLUSTER)
DEFINE CHANNEL(T5_CLUSTER.DISP_T5B) CHLTYPE(CLUSSDR) CLUSTER(T5_CLUSTER) CONNAME('disp-t5b(1414)') TRPTYPE(TCP) SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA256) 
DEFINE CHANNEL(T5_CLUSTER.DISP_T5A) CHLTYPE(CLUSRCVR) CLUSTER(T5_CLUSTER) CONNAME('disp-t5a(1414)') TRPTYPE(TCP) SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA256) 

In my understanding, if anybody (a partial repository) wants to join this full repository QM, a copy of "T5_CLUSTER.DISP_T5C" channel will be automatically created on its side. 
What if this new partial QM cannot (or doesn't want) to use SSL, so cannot use this channel? Or when it wants to use a different cipherspec?
Can I make multiple CLUSRCVR channels on the full repository, and will the full repo check which definition to give to the new QM?
How can I control/setup a cluster, where the CLUSSDR/CLUSRCVR channels can have multiple parameters (mainly speaking of SSL paramters)?

Greetings,
Robert

Hi Robert

There are a few things to 'unpack' in that question.

Firstly, your understanding is correct - although the initial CLUSSDR channel to a Full Repository is created manually, after that in general all cluster sender channels will be autodefined based off the remote receiver definition (and use whatever attributes are defined for that channel at the target queue manager).  Technically it is possible to influence the channel definition autodefined using an exit, but that's probably not relevant here.

While slightly unusual, it is possible to have multiple CLUSRCVR channels defined on any queue manager for the same CLUSTER.  Typical reasons for doing this might be routing via different networks for increased reliability, and you can influence which channel is chosen under what circumstances (e.g. usually prefer network A, if unavailable then use network B), using workload balancing options such as NETPRTY.

However, using this functionality in the way you are suggesting to have 'TLS' and 'Non-TLS' routes into each queue manager would be questionable and potentially dangerous.  Essentially at that point you risk all traffic in the cluster going via 'non-TLS' routes, and perhaps queue managers joining the cluster which are not intended to have access.  You could potentially lock this down with careful use of CHLAUTH rules, firewalling, etc. but I am not sure anyone would want to do this in practice - though perhaps others here will disagree!

The only common scenario I am aware of where you might do this is when 'transitioning' a cluster from non-TLS to TLS - this actually used to be recommended practice, but for various reasons we don't advise this approach today in the documentation (though I'm sure some customers still successfully use this approach).  This would be a temporary state until the non-TLS channels were decommissioned once all cluster members had the required certificates/channel updates.

To accommodate different requirements/availability/preferences of cipher spec, recent versions of MQ support 'Alias' Cipherspecs such as 'ANY_TLS12_OR_HIGHER'.  This would be a preferable way to allow negotiation while maintaining security of the cluster.

Do you have a specific scenario in mind where you would want to allow one 'insecure' member to join a cluster that is otherwise secured throughout with TLS?

Regards
Anthony

Hello,

let me have an other cluster-related question. I didn't find any answer in the documentation.

In out cluster, we have 2 cluster full repositories (DISP_T5A and DISP_T5B) with the following-like cluster sender and receiver channels. They have SSL parameters:

On QM DISP_T5A:
------------------
ALTER QMGR REPOS(T5_CLUSTER)
DEFINE CHANNEL(T5_CLUSTER.DISP_T5B) CHLTYPE(CLUSSDR) CLUSTER(T5_CLUSTER) CONNAME('disp-t5b(1414)') TRPTYPE(TCP) SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA256) 
DEFINE CHANNEL(T5_CLUSTER.DISP_T5A) CHLTYPE(CLUSRCVR) CLUSTER(T5_CLUSTER) CONNAME('disp-t5a(1414)') TRPTYPE(TCP) SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA256) 

In my understanding, if anybody (a partial repository) wants to join this full repository QM, a copy of "T5_CLUSTER.DISP_T5C" channel will be automatically created on its side. 
What if this new partial QM cannot (or doesn't want) to use SSL, so cannot use this channel? Or when it wants to use a different cipherspec?
Can I make multiple CLUSRCVR channels on the full repository, and will the full repo check which definition to give to the new QM?
How can I control/setup a cluster, where the CLUSSDR/CLUSRCVR channels can have multiple parameters (mainly speaking of SSL paramters)?

Greetings,
Robert