Hi John,
Well, there's nothing to stop us reverting to using the QMID in the future.
This is all getting pretty hazy but I do vaguely remember a discussion
about using the QMID. The problem with the QMID is that it is *too* unique
:-) There may well be occasions when one wishes to recreate a Queue Manager
and have the other system pick-up where it left off. If you used the QMID
the 'other' Queue Manager would *always* view you as someone different.
This would mean that, over time, you would collect saved channel status
records to Queue Managers which used to exist but don't now nor ever will.
The other problem is that sometimes, in high availability situations, it
is useful to have two physical Queue Managers which present the same
logical picture to the rest of the network. In other words you want
everyone else to treat them the same. If you used the QMID you would only
be able to do this with shared logs etc. ie. they really are the same queue
manager just running on different hardware.
Having said all that you may have though of a gotcha that we didn't. Was
there any particular benefit you were thinking of for using QMID rather
than just the Queue manager name ?
Cheers,
P.
Paul G Clarke
WebSphere Messaging Clients
IBM Hursley
John Scott
<[EMAIL PROTECTED]
.CO.UK> To
Sent by: MQSeries [email protected]
List cc
<[EMAIL PROTECTED]
V.MEDUNIWIEN.AC.A Subject
T> Re: Starting a Requestor Channel
through a Firewall.
11/04/2005 16:03
Please respond to
MQSeries List
I'm surprised you didn't use the QMID rather than the plain old queue
manager name...
Regards
John Scott
IBM Certified Specialist - MQSeries
ARG Infrastructure Services - Middleware
-----Original Message-----
From: Paul Clarke [mailto:[EMAIL PROTECTED]
Sent: 11 April 2005 15:59
To: [email protected]
Subject: Re: Starting a Requestor Channel through a Firewall.
Phil,
Many moons ago MQ used to use the connection address (IP address or
whatever) as part of the key in order to resolve channels. However, this
causes problems in high availability scenarios where the IP address is not
taken and even causes problems in quite mundane DHCP situations with mobile
machines. So, a number of releases ago the channels were changed to use the
remote Queue Manager name as the 'address'. In other words, when a channel
connects it will use the remote queue manager name to determine whether it
has talked to this queue manager before. The up side of this is that you
should not need to worry about the IP address you use to get there; the
down side is that customers need to be certain that they don't ever talk to
to two logically different Queue Managers of the same name using the same
channel (but no one would do that would they :-) )
You can verify what I'm saying by doing a DIS CHS(*) SAVED ALL. You should
see the CONNAME field is actually the remote queue manager name not the
actual connection name.
Cheers,
P.
Paul G Clarke
WebSphere Messaging Clients
IBM Hursley
MQSeries List <[email protected]> wrote on 11/04/2005
15:04:40:
> In our situation, we must use a Server channel without the CONNAME
defined.
> The whole point is to remove the remote ends need to know "where" we are.
> Turns out we are already using a security exit, so the Requester/Server
> method would seem to work well. The issue here is that we want to be
> able to use a second firewall at our location to contact the remote end
> when/if our first firewall becomes inaccessible. Of course, our side of
> the conversation would see them from a different IP address. That is,
the
> IP seen is that of our firewall. Two firewalls, therefore two different
IP
> addresses.
>
>
> This brings up the question of INDOUBT channels. In this scenario, both
> queue managers are assumed to have survived, but the network routing had
> failed. When the channels are restated, (through the alternate
firewall),
> will MQ be able to properly resolve the channel ? Since the IP
addresses
> would be different, does this imply the unit of work ID would also be
> different ? I think so, therefore, it is likely, I believe, it be
> necessary to RESOLVE the channel. Actually, I believe it would be
prudent
> to "resolve backout" to ensure any in-flight messages are resent. (Dups
are
> no problem).
>
>
> What would be nice, of course, is if the second firewall identified its
IP
> address, as the IP address of the first firewall. It that possible ?
>
>
> Any thoughts ? Thank you all !
>
>
> Phil
>
>
>
>
>
> |---------+------------------------------------>
> | | "David C. Partridge" |
> | | <[EMAIL PROTECTED]|
> | | COM> |
> | | Sent by: MQSeries List |
> | | <[EMAIL PROTECTED]|
> | | wien.ac.at> |
> | | |
> | | |
> | | 04/11/2005 08:55 AM |
> | | Please respond to |
> | | MQSeries List |
> | | |
> |---------+------------------------------------>
>
>
>---------------------------------------------------------------------------
--------------------------------------------
> |
> |
|
> | To: [email protected]
|
> | cc:
|
> | Subject: Re: Starting a Requestor Channel through a
> Firewall. |
>
>
>---------------------------------------------------------------------------
--------------------------------------------
> |
>
>
>
>
> If you get them to use a Sender channel, and you use a Requestor channel,
> then there shouldn't be that security exposure (at least as far as the IP
> addresses that are used)
>
> The Sender will be kicked into life on receipt of the "Request" and will
> try
> to connect to the address in the Connection Name - if that points to you
> then all should be well.
>
> Dave
> -----Original Message-----
> From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf
> Of
> [EMAIL PROTECTED]
> Sent: 08 April 2005 14:44
> To: [email protected]
> Subject: Re: Starting a Requestor Channel through a Firewall.
>
> Paul and Mr. T,
>
>
> Thank you both for your responses. You both imply that using
> Requestor/Server is possible through a firewall, but Paul's response
gives
> me cause for concern. The staff administering the Server side refuses to
> implement either SSL or a Security Exit.
>
>
> The background is this. We have a concern that the remote end may not be
> able to "see" our firewall (some rather large disaster). When this
occurs,
> we want them to use a different firewall at our firm. Unfortunately, MQ
> does not permit the sender's CONNAME to have a list of possible
addresses.
> That is, if the connection to the first firewall fails, then it would
> choose
> the second (I'm not so sure this would be a good idea anyway).
> So, I thought, why not use Requestor/Server channels. Well now I know
why
> this is not such a good idea (the security problem).
>
>
> The only alternative, that I can see, is to have a second set of channels
> that can be used if our first firewall is inaccessible.
>
>
> Thanks again,
>
>
> Phil
>
>
>
>
>
>
> Paul Clarke
> <[EMAIL PROTECTED]> To:
> [email protected]
> Sent by: MQSeries List cc:
> <[EMAIL PROTECTED] Subject: Re:
> Starting a Requestor Channel through a Firewall.
> wien.ac.at>
>
>
> 04/08/2005 08:38 AM
> Please respond to
> MQSeries List
>
>
>
>
>
>
> Phil,
>
> In the case of a REQUESTER/SERVER there is only ever one socket, the only
> difference between it and a normal SENDER/RECEIVER is that the channel is
> started from the receviing end. Essentially when a REQUESTER makes
contact
> with the SERVER the server responds and says "ok - I'll start sending you
> messages then". This is why it is recommended that you use SSL or
Security
> Exits on a SERVER channel to prevent just anyone from taking your
messages.
> It is also why we implemented the 'callback' mechanism of
REQUESTER/SENDER.
> However, in REQUESTER/SERVER there is no callback.
>
> Does this answer your point ?
> Cheers,
> P.
>
> Paul G Clarke
> WebSphere Messaging Clients
> IBM Hursley
>
>
>
> MQSeries List <[email protected]> wrote on 08/04/2005
> 13:16:02:
>
> > Phil,
> >
> > I am able to start most of my external-facing requestor channels just
> > fine. If the remote side is using SDR channels, they simply connect
> > to whatever is in their CONNAME so it doesn't matter if there's a
> > discrepancy between your actual and apparent IP address.
> > If the remote side is a SVR, I *believe* it connects to the address in
> > the socket signature which is managed by the firewall or proxy, as
> > opposed to MQ's perception of the address. But the exact behavior of
> > a SVR in this instance is really a Paul Clarke question if you want an
> > authoritative answer.
> >
> > The caveat is that the firewall rules need to be set up to allow
> > initiation of the channel from both sides. In most cases where I
> > cannot start my external-facing RQSTR I have confirmed it is the
> > vendor's firewall rules and not MQ that stops me.
> >
> > Cluster channels are a whole different story. They actually do rely
> > in MQ's perception of it's own addresses and require the address to be
> > known at both ends (or an exit to fix it).
> >
> > -- T.Rob
> >
> > -----Original Message-----
> > From: MQSeries List [mailto:[EMAIL PROTECTED]
> > Behalf Of [EMAIL PROTECTED]
> > Sent: Friday, April 08, 2005 8:04 AM
> > To: [email protected]
> > Subject: Starting a Requestor Channel through a Firewall.
> >
> >
> > Does this work ? I think it should, but I'm concerned about the
firewall
> > translations. I know that MQ Sends (from the requestor) it's IP
address
> > to the Server channel, that then starts the channel back to the
> requestor.
> > What I'm concerned about is the IP address sent. Is it sent using the
> > IP stack or is MQ actually sending the IP address? If the latter,
> > then I would not believe the channel could start since the requestors
> > IP is
> behind
> > the firewall, and clearly, a different address then that know to the
> remote
> > firewall.
> >
> >
> > Anyway, I thing you all got the jist of this problem.
> >
> >
> > Thanks !
> >
> >
> > Phil
> >
> > Instructions for managing your mailing list subscription are provided
> > in the Listserv General Users Guide available at http://www.lsoft.com
> > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
> >
> > Instructions for managing your mailing list subscription are provided
> > in the Listserv General Users Guide available at http://www.lsoft.com
> > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
>
> Instructions for managing your mailing list subscription are provided in
> the
> Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
>
> Instructions for managing your mailing list subscription are provided in
> the
> Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
- --------------------------------------------------------------
Check our latest prices and full range at http://www.argos.co.uk
The information contained in this message or any of its attachments may be
privileged and/or confidential, and is intended exclusively for the
addressee. Unauthorised disclosure, copying or distribution of the contents
is strictly prohibited.
The views expressed may not be official policy, but the personal views of
the originator.
If you have received this message in error, please advise the sender by
using the reply facility in your e-mail software.
All messages sent and received by Argos Ltd are monitored for viruses,
high-risk file extensions, and inappropriate content.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
