Migrating a queue manager to IPv6

 

This section deals with migrating a queue manager when you are thinking of installing WebSphere MQ V6.0 on an IPv6 network.

The IPv6 protocol can only be utilized by WebSphere MQ V6.0 or later. In order to make use of the IPv6 protocol, WebSphere MQ must be installed on a system that is IPv6 capable.

The preferred IP version that two systems use for communicating (if both IPv4 and IPv6 are available) is determined by a new queue manager attribute IPADDRV. This parameter only has an effect if the hostname resolves ambiguously to both an IPv4 address and an IPv6 address.

To migrate a queue manager to use the IPv6 protocol:

  1. Configure dual IPv4 and IPv6 protocols on the system where the queue manager to be migrated resides.

  2. Install WebSphere MQ V6.0.

  3. Add an entry to the DNS to resolve the hostname of the system that is to be migrated, to both an IPv4 address and an IPv6 address.

  4. Set the IPADDRV parameter to IPv6 (or set the LOCLADDR parameter to resolve to an IPv6 address).
    CAUTION:
    Not all IPv6 software can interpret an IPv4 mapped IPv6 address. If the combination of CONNAME and LOCLADDR results in an IPv4 mapped IPv6 address, ensure that the system hosting the target queue manager is capable of handling this.

    Using mapped addresses can require protocol translators in the IP network.

 

Migration scenarios (non-cluster topology)

It is possible to come up with a number of different interconnection possibilities, and the following sections aim to help you understand how WebSphere MQ will work in each case.

Non-cluster migration scenario 1

Three systems exist that are IPv4 only capable. Each system hosts a queue manager (QM1, QM2, and QM3) and each queue manager connects to the other two. All CONNAMEs in the cluster channel definitions are made using DNS names rather than IP addresses.

Enable QM1 to be able to use channels running over IPv6 as follows

  1. Upgrade the host system to have dual IPv4 and IPv6 stacks.
    Important: A listener is required for each IP stack.

  2. Install WebSphere MQ V6.0.

  3. Update the DNS table so that it has two entries for the system running QM1; one entry for its IPv4 address and one for its IPv6 address. This enables a DNS name request to return both IPv4 and IPv6 addresses for this host.

  4. Set the queue manager IPADDRV attribute to IPv6.

Even with these changes made to support IPv6 addressing, QM1 will still be able to communicate with queue managers (both existing and new ones) that are only IPv4 capable.

Enable QM2 to be able to use channels running over IPv6 as for QM1 above.

  • Communications between QM1 and QM2 will now be over IPv6.

  • Communications between QM1 and QM3 will still be over IPv4.

  • Communications between QM2 and QM3 will still be over IPv4.

With the queue manager IPADDRV attribute set to IPv6, the preference has been set for the queue manager to connect using the IPv6 protocol. If a channel from QM1 to QM3 has LOCLADDR set to a host name which resolves to an IPv6 address, or both IPv4 and IPv6 addresses (with the IPADDRV attribute set to IPv6, the IPv6 address will be returned as that is the preference), this channel will attempt to use the IPv6 protocol. If the IPv6 protocol installed on the QM1 host system is capable of using a mapped address then QM1 will communicate with QM3 over IPv6. Otherwise, the channel will fail to resolve CONNAME.

While QM3 remains a WebSphere MQ V5.3 or earlier queue manager, you will need to check that all CONNAMEs used to start a channel to QM3 do not resolve to an IPv6 address or dual IPv4 and IPv6 addresses where the IPv6 address could be returned. This would cause QM1 to attempt to start the channel over IPv6 which would fail, as it would be unable to resolve the CONNAME.

It is possible to upgrade a system to have dual IPv4 and IPv6 capability and still run a WebSphere MQ V5.3 or earlier queue manager on the system. While it is not recommended to run this type of configuration, as long as the addresses that are returned to this level of queue manager are either IPv4 or an IPv4 mapped version of an IPv6 address, this should work.

Non-cluster migration scenario 2

Three systems exist that are IPv4 only capable. Each system hosts a queue manager (QM1, QM2, and QM3) and each queue manager connects to the other two. All CONNAMEs in the cluster channel definitions are made using IP addresses.

Because addresses have been specified instead of DNS names, to allow a queue manager to connect to another using the IPv6 protocol you will need to duplicate the definitions that use IPv4 addresses between them and provide them with IPv6 addresses instead. The original definitions that use IPv4 addresses will continue to work, but if you intend to take advantage of the IPv6 protocol, you will need to connect using the new definitions.

Enable QM1 to be able to use channels running over IPv6 as follows

  1. Upgrade the host system to have dual IPv4 and IPv6 stacks.
    Important: A listener is required for each IP stack.

  2. Install WebSphere MQ V6.0.

  3. Duplicate the channel, transmission queue and, where applicable, any process definitions using IPv6 addresses where required.

Even with these changes made to support IPv6 addressing, QM1 will still be able to communicate with existing queue managers that are only IPv4 capable.

Enable QM2 to be able to use channels running over IPv6 as for QM1 above.

  1. Upgrade the host system to have dual IPv4 and IPv6 stacks.
    Important: A listener is required for each IP stack.

  2. Install WebSphere MQ V6.0.

  3. Where necessary amend applications to write to the new remote queue (created above for QM1 with the IPv6 addresses).

  4. Verify the channels can be started.

The queue managers can now connect as follows:

  • QM1 can now connect with QM2 over either IPv4 or IPv6 depending on the channel the application writes its messages to.

  • QM1 still connects with QM3 over IPv4 using the original definitions.

 

Parent topic:

Internet Protocol V6 (IPv6) migration


mi10210_