| Author |
Message
|
| dingdong |
 Posted: Wed Nov 12, 2008 11:55 am Post subject: MQIPT - binding port to IP address |
 |
|
Novice
Joined: 12 Nov 2008
Posts: 14
|
Hi.
Hope I'm in the right section to ask an MQIPT question. By the way, I'm new at this, so please bear with me.
I'm wondering if, or how, MQIPT can be bound to listen on a specific IP address per port. In inherited this set of servers from someone who is no longer with us, so I can't ask this person.
Initially, I thought "LocalAddress" in the route stanza would accomplish this, but it doesn't seem to be the case.
Here are the ListenerPort and LocalAddress lines from one of the routes:
> ListenerPort=1420
> LocalAddress=192.168.220.28
Looking at the MQIPT process, it's listening on all IP addresses for 1420 and 192.168.220.28:
# netstat -an|grep 1420
tcp 0 0 :::1420 :::* LISTEN
tcp 0 0 ::ffff:192.168.220.28:1420 ::ffff:10.4.143.28:38862 ESTABLISHED
[root@inet23linux mqipt]# lsof|grep 1420
java 12774 root 11u IPv6 645004235 TCP *:1420 (LISTEN)
java 12774 root 38u IPv6 645004239 TCP 192.168.220.28:1420->10.4.143.28:38862 (ESTABLISHED)
[root@inet23linux mqipt]# ps -ef|grep 12774|grep -v grep
root 12774 12771 0 Nov10 ? 00:07:49 java -Dsun.net.inetaddr.ttl=30 -classpath /opt/mqipt/lib/MQipt.jar:/opt/mqipt/lib/guiadmin.jar com.ibm.mq.ipt.IPTController -D ..
We need it to listen only on the IP address that has been assigned for that port.
Anyone have any hints on how to accomplish this? Btw, we're at 1.3.3 for MQIPT with intentions to upgrade soon to 2.0.0.1, if that makes any difference.
Rgds/Kim |
|
| Back to top |
|
 |
| exerk |
| Posted: Thu Nov 13, 2008 1:00 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
There is a section within the MQIPT manual that deals with multi-homed systems, but I'm not sure if that will give you the answer - I know it's in there, but I haven't read it 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| dingdong |
| Posted: Thu Nov 13, 2008 1:07 pm Post subject: |
|
|
Novice
Joined: 12 Nov 2008
Posts: 14
|
Thanks, exerk. It talks about the LocalAddress parameter, which I thought would accomplish what I need, but it appears to only apply to OUTBOUND connections.  Thanks for the suggestion, though.
Kim |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Nov 13, 2008 1:57 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| dingdong wrote: |
Thanks, exerk. It talks about the LocalAddress parameter, which I thought would accomplish what I need, but it appears to only apply to OUTBOUND connections. Thanks for the suggestion, though.
Kim |
Well what did you expect? There is no control over an inbound connection. You either accept it, or not. The firewall can help there in controlling what you receive. When you create the outbound connection, passing this information, will let the other end of the connection know about your restrictions and how to create the correct conversation with you on the TCP/IP level.
Remember that the call to the qmgr from MQIPT is to be considered as and outbound call. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Nov 13, 2008 2:58 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The Listener object in MQ 6.0 has an IPADDR attribue that allows you to specify a particular IP address for the Listener to listen on. An incoming connection to any other IP on the server, even if the port, channel, QM name and everything else is correct will fail. I use this on hardware clusters and put the VIP in IPADDR. This keeps the apps from specifying the physcial server name on theor MQCONN call, which works fine while the cluster group is on Server A, but fails for them when the group slides over to Server B. "The MQ is broken!" No, you aren't using the VIP like I told you too. Using IPADDR prevents this from the start.
I guess Kim wants the same type of thing for MQIPT. I quick scan of the MQIPT 2.0 manual seems to indicate there is no way to do this with MQIPT config settings.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Nov 13, 2008 9:12 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
I guess Kim wants the same type of thing for MQIPT. I quick scan of the MQIPT 2.0 manual seems to indicate there is no way to do this with MQIPT config settings. |
Peter I do not quite follow you.
MQIPT is configured as to which IP/port it will forward the connection to.
This you set up as MQ/MQIPT Admin.
Now if your MQIPT server has multiple cards and you will force the connection to go through a specific card, I guess that would be function of the firewall... That's why the MQIPT server is most often in the DMZ and no connection is setup without SSL...
Also not everybody can connect to the MQIPT box. Only if the calling ip corresponds to your agreed upon partners are you allowed to connect.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Nov 14, 2008 3:11 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
FJ, it is not the function of a firewall to decide what IP address a TCP/IP listener program opens an inbound socket onto. It is only the job of the firewall to determine who can connect to which IP/port combinations from what other ip/port combinations.
I suspect, without having tried it, that MQIPT supports a syntax for the ListenerPort configuration entry that includes an IP address as well as a port number. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Nov 14, 2008 5:58 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If it does, its an undocumented feature. I went through the whole manual yesterday (getting ready to upgrade to MQIPT 2.0.0.1) and didn't see it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| dingdong |
| Posted: Fri Nov 14, 2008 7:16 am Post subject: |
|
|
Novice
Joined: 12 Nov 2008
Posts: 14
|
Hi. Thanks for all of the feedback. And, yes, what Peter described is what I'm trying to accomplish. This was not my design at all. I've inherited it and I'm not happy about it, but that's beside the point. So, we have another proxy application sharing servers with MQIPT. Say, for example, we use port 80 with MQIPT to test connectivity with new customers. It doesn't need to be listening all the time, but it is needed sometimes. The other proxy application uses port 80 "for real". MQIPT grabs port 80 on all IP addresses/interfaces so the other proxy app finds the port in use and can't listen. Rather than stop/start routes "as needed", I'd rather find a way for MQIPT to listen on only the IP address and port combo I specify. Because.. this is just one example. We have customers using odd ports and it's only a matter of time before there is a "real" conflict.
I guess I just didn't explain it all that well initially. I think I'm SOL, but I'm going to try asking IBM.
Kim |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Nov 14, 2008 7:24 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Do you mean to say that when MQIPT is receiving an agreed upon connection request you want it to reply on a restricted IP/port range?
As you address MQIPT as you would a normal MQ Listener I expect that that would be the need of a definition for the channel. (Sender or client).
I am still kind of missing the understanding there.
If my MQIPT machine has 2 cards and I want to force the inbound connection to a specific one I can have the firewall reject connection request to the other one. If I want it to reply only through the one IP that would happen by configuring the routing table accordingly, right?
Or is it that I want one application (MQIPT) to use a specific card/ip for it's outbound connection and a different application to use the other card/ip potentially to the same target machine/network?
Thanks for clarifying.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| dingdong |
| Posted: Fri Nov 14, 2008 8:10 am Post subject: |
|
|
Novice
Joined: 12 Nov 2008
Posts: 14
|
fjb_saper,
It's INBOUND connections that are the issue, whether from customer or internal MQ server.
Say we have a server running MQIPT and another proxy application. Two "service" IP addresses have been allocated:
10.10.10.10 for MQIPT.
10.10.10.20 for other proxy app.
For example purposes, say both applications need to listen on port 80 for inbound calls.
The other proxy app is configured to specifically listen only on IP address 10.10.10.20 port 80, for incoming calls.
MQIPT listens on port 80 for ANY IP address defined on the server, for incoming calls.
Say the MQIPT app is started first. It hogs port 80 for ALL IP addresses defined on the server. So, if customer A calls 10.10.10.10 port 80, he's going to get MQIPT, which is what should happen based on the IP assignment. If customer B calls 10.10.10.20 port 80, he's going to get MQIPT. This is NOT what should happen. He's expecting the other proxy application to answer and proxy his call elsewhere as he's not even an MQ customer. In fact, the other proxy application will not even start in this case because it finds port 80 in use for all configured IP addresses.
It could be argued that MQIPT should live by itself for security reasons, etc, etc, etc. That is completely beyond my control. We're being forced to consolidate hardware and I can't do anything about it. So, the easiest solution, which I don't think is unreasonable (we have plenty of other apps that can bind to an IP address), is to (somehow) configure MQIPT to listen for inbound calls on only the IP addresses that have been allocated for MQIPT.
Hope this makes better sense. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Nov 14, 2008 9:23 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Why do you both have to go after port 80? Why not have MQIPT listen on some other random port, that will be free on either IP address?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Nov 14, 2008 10:07 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Thanks dingdong, this clears it up a lot.
Don't know about that. By default the workaround that Peter suggests is bound to work. Your netscaler or VIP or equivalent could be set up to forward correctly so your outside users don't have to change a thing...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| dingdong |
| Posted: Wed Dec 03, 2008 7:51 am Post subject: |
|
|
Novice
Joined: 12 Nov 2008
Posts: 14
|
In case anyone ever has the same question concerning version 1.3.3 or 2.0.0.1, this functionality does not exist according to IBM. Needs a Design Change Request to have it added.
Rgds/Kim |
|
| Back to top |
|
|
|
|
