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. 

1. How does TCP/IP network routing function (at a fairly high level)
2. What does the network environment I’m connecting into look like?
3. Why am I setting up multiple connections anyway (Is it for performance?  Redundancy? Security?)

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

• do I already have any interfaces on that subnet
• do I have static routes to that particular host¹
• do I have any static routes to that subnet (most specific first)
• do I have a default gateway

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 crossed²).  

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:

• Avoid ever having multiple IP addresses on a system on the same subnet.³  If this is intended to provide redundancy, consider using a ‘link aggregation’ where possible (this will present a single IP address to the outside world).
• For HA or DR links which are direct connections, put them onto completely dedicated private subnets (these could just be 192.168. style).  Giving each its own subnet will completely remove any potential issues for clashes.  They also do not need gateways or routes of any kind, since all traffic on these direct connections will be peer to peer only within that subnet.
• If they are not direct, still give HA/DR interfaces dedicated/discrete subnets if possible.  If not, define static routes to the equivalent interfaces on the partner appliance for each of the eth13/17/20/21 interfaces.
• Consider defining static separate routes to hosts or subnets for specific MQ and management traffic.  For example, if you know that all of your management traffic should be coming to and from 192.168 addresses, define static routes on mgt0 and/or mgt1 to ensure that traffic back to these systems takes a known route and does not interfere with other (e.g. application) traffic.
• Avoid ever having multiple default gateways defined.  Defining a default gateway on any given interface is completely optional (the startup wizard can sometimes confuse people here).  By defining multiple interfaces as having a default gateway, you are saying ‘if you’re not sure, send the packet down either of these’, leading to unpredictability.
• Finally, the default gateway really should be just that, an 'anything else' route.  It probably makes sense for this to be defined on one of the interfaces you expect 'outgoing' MQ connections to use, as this will make it easy for queue managers to route outwards to any IP that doesn't have a more specific route defined.

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.

¹Static 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.

² No, honestly, I have nothing against network engineers.  Please, please don’t cut my internet connectivity when I post this.

³An 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.