| Author |
Message
|
| hal |
 Posted: Tue Oct 17, 2006 7:43 am Post subject: LOCLADDR and virtual IP |
 |
|
Acolyte
Joined: 07 Dec 2005
Posts: 67
Location: New York City, New York
|
Can sender channel LOCLADDR attributes be assigned with a VIP?
I am running WebSphere MQ V6 on a Sun Solaris high availability active/passive cluster (not a WebSphere MQ cluster.) There are two machines in the HA cluster and a VIP that points to the active server. There is one queue manager. I am attempting to facilitate TCP-IP sender/receiver channel startups during failover scenarios when the local IP changes. The channels cross firewalls. The sender channels are triggered via transmission queues. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Tue Oct 17, 2006 5:36 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
One thing I have learned when dealing with Microsoft Hardware clusters and firewalls is that for connections going TO the hardware cluster, you specify the VIP as the destination IP. For connections LEAVING either of the 2 nodes in the hardware cluster, the source IP is NOT the VIP, but the IP of the actual server the channel happens to be running on.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 18, 2006 3:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Peter, I assume you aren't using LOCALADDR in that case?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 18, 2006 3:36 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Correct. I don't have a need for LOCALADDR. But the firewall rules I requested were wrong because I didn't realize the the source IP of an outgoing MQ connection will be the physical box, whereas incoming connections would refer to the VIP as the destination.
Based on my experience with that, I would bet that you could not put a VIP into the LOCALADDR field of a SNDR channel. Maybe worth a quick test, but don't be surprised if it doesn't work.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 18, 2006 4:48 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
My guess is that LOCALADDR will work.
This is the kind of thing I would expect it is designed for.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hal |
| Posted: Thu Oct 19, 2006 7:19 am Post subject: |
|
|
Acolyte
Joined: 07 Dec 2005
Posts: 67
Location: New York City, New York
|
IBM support told me that they were not aware of anyone using sender channel LOCLADDR attributes to specify VIPs and that LOCLADDR is being used mainly to restrict port ranges.
I am working with an external vendor (CHIPS, the Clearing House Interbank Payments System) who is requiring us to implement secondary WebSphere MQ channels for our failover and disaster recovery scenarios. They want us to stop our primary channels and start the auxiliary channels during our internal failovers. This does not make any sense to me because failovers are supposed to be seamless. The external vendor is using our VIP in their sender channel CONNAME attributes.
From the WebSphere MQ V6 Information Center:
| Quote: |
| When a LOCLADDR value is specified, a channel that is stopped and then restarted continues to use the TCP/IP address specified in LOCLADDR. In recovery scenarios, this could be useful when the channel is communicating through a firewall, because it removes problems caused by the channel restarting with a different IP address, specified by the TCP/IP stack to which it is connected. |
|
|
| Back to top |
|
|
| pcelari |
| Posted: Thu Mar 04, 2021 6:16 am Post subject: Re: LOCLADDR and virtual IP - thread still very relevant |
|
|
Chevalier
Joined: 31 Mar 2006
Posts: 411
Location: New York
|
| hal wrote: |
Can sender channel LOCLADDR attributes be assigned with a VIP?
|
This 15-year old thread seems to match exactly what we're trying to do, i.e. route the outbound point-to-point channel session through VIP. In our case, an F5 load balancer.
It's unlikely such need is an exception, esp. for MQ. Has anyone been successful with such an arrangement? Or found a way to accomplish the same result?
Ultimately, it is about replacing the stand-alone world-facing Gateway QM with a F5-QM pair, without having to go through all the FW process - by using the same IP address.
Anyone can share a success story?
_________________
pcelari
-----------------------------------------
- a master of always being a newbie |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Mar 04, 2021 6:51 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Look in MQ installation file system both errors directories for relevant error messages. Post the error message(s) here.
What problem-determination steps have you taken? What were the results?
I'm going to guess (predict?) that it's a firewall issue. MQ is agnostic to IP addresses.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| pcelari |
| Posted: Thu Mar 04, 2021 9:40 am Post subject: |
|
|
Chevalier
Joined: 31 Mar 2006
Posts: 411
Location: New York
|
| bruce2359 wrote: |
| ... I'm going to guess (predict?) that it's a firewall issue. MQ is agnostic to IP addresses. |
Wow! Thank you for that highly encouraging statement! So I must have done something wrong, somewhere...
What I did was populating the locladdr field with IP of the F5 device. there is no firewall between the MIQM and F5. Here's the entry from the error log.
AMQ9248E: The program could not bind to a TCP/IP socket.
EXPLANATION:
The attempt to bind to socket 'a.b.c.d(0)' failed with return
code 99. The failing TCP/IP call was 'bind'. The most likely cause of this
problem is incorrect configuration of the TCP/IP local address or incorrect
start and end port parameters.
ACTION:
Contact the system administrator. If the problem persists save any generated output files and use either the MQ Support site:
https://www.ibm.com/support/home/, or IBM Support Assistant (ISA):
https://www.ibm.com/support/home/product/C100515X13178X21/other_software/ibm_support_assistant, to see whether a solution is already available. If you are unable to find a match, contact your IBM support center. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Mar 04, 2021 10:45 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| pcelari wrote: |
EXPLANATION:
The attempt to bind to socket 'a.b.c.d(0)' failed with return ... |
Did you explicitly code a.b.c.d(0)?
Specifically, did you explicitly code port zero? If memory serves, port zero is used to request a dynamic port allocation. A network specialist will be along shortly ...
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Last edited by bruce2359 on Thu Mar 04, 2021 2:35 pm; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Mar 04, 2021 11:32 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You can't bind your channel or listener to an IP on another system. Its just not going to work. The MQ object will search the local O/S for the IP you told it to use. If your local O/S doesn't own/control/use that IP there is no way the MQ object can bind to it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| pcelari |
| Posted: Thu Mar 04, 2021 12:49 pm Post subject: |
|
|
Chevalier
Joined: 31 Mar 2006
Posts: 411
Location: New York
|
| bruce2359 wrote: |
Did you explicitly code a.b.c.d(0)?
Specifically, did you explicitly code port zero? If memory serves, port zero is used to request a dynamic port allocation. A network specialist will be along shortly ... |
No, I didn't include a port (0). that apparently got added by the channel itself.
I'm not knowledgeable with how VIPs operate. But I do know MQ appliance has a build-in VIP that has a different IP than the hosts, and that were specified in the locladdr field. How does that work regardless which host is active?
Also I can hardly imagine no one has fronted a multi-instance QM with a F5 and make it behave just like a VIP in a MQAppliance configuration. So it seems I must have missed something... |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Mar 04, 2021 2:36 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
What exactly did you code for LOCADDR? Please post the entire channel definition here.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Mar 04, 2021 4:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you want to use an F5 as load balancer in front of an MI, you need to front the F5 with MQIPT. So you can route to the qmgr from MQIPT through F5 and directly (in case MQIPT is being on the outgoing leg). As the other side would then send to MQIPT and back through the F5...
Kind of crazy kinky...
The other way I know of would be to create a reverse proxy (potentially on the F5 ?) 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| pcelari |
| Posted: Fri Mar 05, 2021 9:15 am Post subject: |
|
|
Chevalier
Joined: 31 Mar 2006
Posts: 411
Location: New York
|
| bruce2359 wrote: |
| What exactly did you code for LOCADDR? Please post the entire channel definition here. |
Here's the SDR channel definition, of course with fake IP:
DEFINE CHANNEL('SOURCE.TARGET') +
CHLTYPE(SDR) +
CONNAME('123.45.67.89(2414)') +
LOCLADDR('mqf5-vip') +
MCAUSER('mqm') +
TRPTYPE(TCP) +
XMITQ('TARGET') +
REPLACE
So if F5 can handle only one-directional traffic sessions, a second F5 might be needed for outbound sessions. Using MQIPT is not an option for us.
_________________
pcelari
-----------------------------------------
- a master of always being a newbie |
|
| Back to top |
|
|
|
|
