January 22nd, 2013, 12:19 PM
Multiple NICs, same subnet
I am working on a Java web application deployed in Tomcat 7 in a Windows Server 2008 environment. One requirement we were recently given was to configure the server with multiple NICs, so as to support communication with some legacy applications that require my server to have specific IP addresses (all IPs on the same subnet).
So, currently, my server is set up with NICs with the following addresses: 10.0.0.20, 10.0.0.21, 10.0.0.22. Tomcat is configured to listen on all interfaces, and any web service requests made to my application are handled and given a response. That's good.
However, I am getting some reports that my app is not playing nicely with some of these legacy apps. Specifically, if legacy app A sends a web service request to 10.0.0.21, it expects to get a response from 10.0.0.21. However, according to reports, the responses actually come back over another interface, presumably determined by the Windows network stack. I'm guessing what happens is that since the client and all of the server's IPs are on the same subnet, Windows could use any of the three interfaces and just chooses one based on the routing tables.
I am still in the process of setting up a test server and client to test this behavior. However, it seems to me (and maybe I'm naive) that this is part of the HTTP specification. The server shouldn't open up any new connections - it's supposed to just respond over the same connection initiated by the client. Is this behavior even possible?
If it is possible, how can I configure my server (again, Windows Server 2008) to respond over the same interface on which a request was received?
It doesn't appear to be any sort of Tomcat or Java configuration. I could create a static route in the routing table (not sure it works this way, though) to try to force the use of a specific interface when routing somewhere. However, all of the legacy apps are sitting on the same box, so any static route would only solve the problem for a specific app...
January 22nd, 2013, 01:16 PM
Well, from a physical perspective it's possible, but from a software perspective it doesn't seem very likely. It shouldn't really be very hard to test the theory, just install a packet sniffer like WireShark on the server and see what packets it's sending. I'd be interested to learn whether or not it's actually doing that.
January 22nd, 2013, 02:02 PM
Agreed. That's what I'm trying to set up... Only my test machines are currently tied up with something else at the moment. Will be sure to let you know.
Originally Posted by E-Oreo
January 23rd, 2013, 04:51 PM
Ok, as an update, I tried to test this in my lab. Specifically, I set up the server with 3 NICs, and deployed the web application. Then, from a client, I made web service SOAP requests (via SoapUI) to each of the 3 IP addresses.
Simultaneously, I had wireshark running, sniffing the packets going back and forth to and from the server. In every case, the SOAP responses were returned over the same interface to which the request was made.
Next, I created a route in the server's routing table such that interface X should always be used when sending a packet to the client's IP address.
Even with this route in place, I could not get the SOAP responses to arrive at the client from a different address than the one where I sent the requests.
So... it looks like something altogether different must be going on.
January 23rd, 2013, 07:49 PM