All blogs selected for migration to be found here: https://community.ibm.com/community/user/imwuc/communities/community-home/librarydocuments?LibraryKey=7aaf3c23-2c83-47ba-9906-539bef972b48&CommunityKey=183ec850-4947-49c8-9a2e-8e7c7fc46c64&defaultview=folder&libraryfolderkey=98172f7b-459a-43da-b961-c9d51b9f7d74
MQdev Blog - moved to Messaging on Developerworks!
This article looks at some basic best practices and TCP/IP networking tips. If you’re looking for some more advanced guidance on areas such as segmenting queue managers into separate network domains, see http://ibm.biz/imqa_networks
As you’re probably aware, one of the strengths of the MQ Appliance that it puts everything you need to get MQ up and running in one place – often all under the control of the MQ administrator for the first time! We are frequently seeing that users find this is one of the biggest benefits of the appliance compared to traditional platforms (no more dealing with separate storage, networking, security, OS teams to handle what should be simple maintenance operations!) However, it can sometimes also look daunting at first. One of the places we’ve discovered this can be the case is in setting up a good initial network configuration for the system.
You can get going with the appliance by just configuring one management interface and a default gateway to enable connectivity to the outside world (you’ve probably already done this through the initialization wizard if you’re reading this article). However, because the appliance has many network interfaces, it is important to understand several things before going onto to configure all of the others.
The answer to question 1 (very, very simplistically), is that whenever the TCP stack (in the appliance or most other platforms for that matter) needs to route to a host it will go hunting along the lines of
and at each tier, if there are multiple options select more or less randomly. The ‘show route’ command in the CLI gives you the current information available to the appliance in making these decisions.
You will need to answer questions 2 and 3 for your specific environment (maybe this is the last conversation you need to have with your networking team – fingers crossed2).
Generally, an aim in setting up your network interfaces should be to avoid any ambiguity or uncertainty in what routes traffic should take between systems. Ambiguity can cause problems for some network operations - for example, when 'ping'ing an appliance, you may see no response if the return path is different to the request. This can also interfere with the HA and DR functionality of the appliance. The precise best layout will depend on your answers to 2 and 3 above, but we can give some good general guidelines and best practice suggestions to achieve this:
I hope this gives you enough to feel confident creating a basic ‘tidy’ networking configuration for the MQ Appliance – as we enhance the product and continue to work with our users we’ll keep updating the product documentation and posting here on MQDev with best practices, tips and recommendations. So please do feed back via the comments or email if you have anything you’d like to see expanded on (or corrected) as part of that.
1Static routes are managed by editing an interface definition (UI or CLI) and defining an ip-route (giving the 'next hop' for a subnet or specific IP address). The subnet is defined in CIDR notation, so e.g. 192.168.1.0/24, or 192.168.1.42/32 - the next hop may either be the target address, if on the same subnet, or the gateway which should be used to reach that target.
2 No, honestly, I have nothing against network engineers. Please, please don’t cut my internet connectivity when I post this.
3An Exception to this is in cases where a floating IP is assigned to an interface (certain HA configurations), in which case it will/must be on the same subnet as the physical IP address associated with that interface.