Here's the scenario:
1. Windows MMIII Server running IIS, multi-homed with 2 NICs, some web sites running on IP Addresses on one NIC, others running on IP Addresses on the other. This was originally set up so that password-protected web sites could be authenticated through a WebSense LDAP call. This server hosts our Intranet web sites.
2. No longer using WebSense and the Networking group wants to replace and get rid of old routers and switches.
3. The server will now run all web sites through one NIC.
Here's what I did:
1. Deleted the IP Address of the NIC which was routed through WebSense. After doing that, I deactivated the NIC.
2. Entered the IP Addresses from the now-deactivated NIC onto the other.
3. Changed the subnet mask and the default router on the one working NIC. Turned off Routing and Remote Access because the static routes that service handled were no longer needed.
4. Restarted the Server.
At this point, I expected everything to route where it was supposed to and we could call it a night after 15 minutes work. Ah, but that was not to be. Computers in the same subnet as the server could access the web sites correctly. But, those which were in other subnets (across the router) could not get the web sites.
I went through and double-checked the IP Addresses, subnet mask, and default gateway on the server. All was correct. I also ran route print to make sure there wasn't anything hanging on from the old routing. There wasn't. I also restarted the server numerous times. (Microsoft Troubleshooting Lesson 1: Always reboot first before doing anything else.)
The networking guys checked, rechecked and checked again all the routing info in the routers and switches which the server's traffic would have to cross.
The interesting twist on this, by the way, was that the server's non HTTP traffic going across the router worked just fine. It could get its dynamic content from the 2 database servers which are each in a different subnet, and it could make the AD LDAP calls for authentication.
Total mystery.
We spend the better part of 2 1/2 hours checking, rechecking, adjusting and changing settings trying to get this server to give it's web pages to everyone needing access to them. No luck.
Finally, one of the networking guys, who was very frustrated, suggest we remove all the IP Addresses off the working NIC and reenter them.
I did that and everything started working. I didn't even have to restart the server again.
So, if anyone out there needs to "un-multi-home" a Windows server, don't just enter the old IP Addresses on the other NIC, remove all the IP Addresses and start over.
One more piece of advice: Remember which was the first IP address you entered on the working NIC and don't take that one off. In our scenario, that was the only IP address which seemed able to communicate across routers. There is something about the first NIC and the first IP Address entered on that NIC that's magical. I'm thinking about my other experience with that IP/NIC problem.
Showing posts with label NIC. Show all posts
Showing posts with label NIC. Show all posts
Thursday, July 12, 2007
Thursday, October 05, 2006
Infor's SXAPI Problem and Solution
For those of you who are not technically inclined computer-geek types, you might want to pass this post up. However, if you happened to stumble upon it while looking for a solution to a similar problem with Infor's SXAPI, please read on and I hope it helps.
The company I work for has a dozen or so regional offices. As a service to our customers, we have a secure proxy to our Regional Sales System so they can check stock at their convenience without having to call and wait for a sales rep to get to them. It's a good system for our customers and for us.
We are in the process of changing to Infor's system for our regional offices. We, of course, want to offer the same stock-checking service to our customers via our Business-to-Business (B2B) web site. Infor has an API to facilitate writing ASP.NET web applications which will allow us to do just that. They call it SXAPI.
In our development environment, the SXAPI worked like a charm. We could hook into the sales system and query stock levels to our hearts' content. We were really jazzed about being able to give our customers an easy to use and powerful system to help them do business with us better and easier.
That was, until we tried to set the SXAPI on our production server for testing. We have our B2B in a DMZ between firewalls going out to the WWW and in to our network. I arranged with our network admin to make the proper adjustments to the firewall and I thought we were all set. Boy was I wrong.
When it came time to install the SXAPI it took forever. First off, in order for it to install itself there must be a web site in IIS called "Default Web Site." If there is no such web site, the install will bomb. Of course, on a public-facing web site, we don't keep anything "default." It took the tech support guy at Infor a little while to figure this out.
Once we got the SXAPI installed and configured I ran their "Canary Test" program to check the connection to our back end Infor server. The Canary Test is a cute little app with a picture of a canary on a perch. When you do the test, if it succeeds the canary stays on its perch and you get the "success" message. If the connection doesn't succeed, the canary "dies" and the picture changes to a canary on its side with an "x" over its eyes. Unfortunately, the canary kept "dying."
For two weeks I went back and forth with my Infor tech support contact. He had no ideas why it wouldn't work. I sent him error messages, reports from the Infor server confirming I was trying to connect to the correct IP Addresses and ports, and other information. In between emails and phone calls I worked with two of our network admins checking for messages in the firewall logs and running sniffer traces to see if we could diagnose the problem. I even went and gave my Infor tech contact all the details of our network configuration so he could replicate it and try to diagnose the problem.
The production B2B server has 2 NICs; one goes out to the WWW and the other only connects to a SQL Server we run for dynamic content - both are on different IP subnets. Even though we have static routes in the B2B server to send the traffic in the right direction, for some reason the packets the SXAPI generated were trying to go through the NIC for the SQL server, which is in a non-routable address segment. No matter how we tweaked the static routes or messed around with the settings on the server, we couldn't get the traffic to go out the correct NIC to our Infor server. Our tech contact at Infor didn't seem to understand the problem, and finally told us he was punting to a developer to see if any light could be shed on the problem. He even told us at one point that the canary test probably wouldn't work through a firewall since it did more than just test for a good connection.
In the meantime, I've got a lot of people who want to have this API working (most of all me, 'cause I've got a lot of other things to do) so our customers can take advantage of the ASP.NET inventory query app we wrote. Nothing seemed to work at all. There was no documentation on this kind of issue, no solution coming from Infor tech support, no Usenet or other tech groups, nothing. It was very frustrating.
While I was talking out the problem with one of the network admins, he suggested I disable the NIC the SXAPI was sending its traffic through to see if it would be "smart" enough to route the traffic through the other NIC. I was ready to try this, but thought there might be another solution.
This morning while I was getting ready for work, mulling over this issue, something hit me. When putting IP Addresses in a Windows server, when you route traffic out and don't specify which IP Address it should go through, Windows defaults to the first IP Address you entered. I started to think, what if the SXAPI was looking at the registry and routing its traffic through the first NIC installed instead of the one the Windows routing table was telling it to go through. Instead of letting Windows handle the network and routing, I wondered if it was handling the routing itself. I happened to remember the NIC handling the SQL Server traffic was built in and the one handling the WWW traffic was a PCI card I installed. The NIC with the SQL was installed first.
To that end, I swapped IP Addresses in the 2 NICs installed on the server and swapped the cables so they'd go through the correct routers - and behold - the canary didn't die when I did the test.
So, if you happen to stumble on this looking for answers to routing issues with Infor's SXAPI and you have 2 NICs, take a look at the order the NICs were installed.
The company I work for has a dozen or so regional offices. As a service to our customers, we have a secure proxy to our Regional Sales System so they can check stock at their convenience without having to call and wait for a sales rep to get to them. It's a good system for our customers and for us.
We are in the process of changing to Infor's system for our regional offices. We, of course, want to offer the same stock-checking service to our customers via our Business-to-Business (B2B) web site. Infor has an API to facilitate writing ASP.NET web applications which will allow us to do just that. They call it SXAPI.
In our development environment, the SXAPI worked like a charm. We could hook into the sales system and query stock levels to our hearts' content. We were really jazzed about being able to give our customers an easy to use and powerful system to help them do business with us better and easier.
That was, until we tried to set the SXAPI on our production server for testing. We have our B2B in a DMZ between firewalls going out to the WWW and in to our network. I arranged with our network admin to make the proper adjustments to the firewall and I thought we were all set. Boy was I wrong.
When it came time to install the SXAPI it took forever. First off, in order for it to install itself there must be a web site in IIS called "Default Web Site." If there is no such web site, the install will bomb. Of course, on a public-facing web site, we don't keep anything "default." It took the tech support guy at Infor a little while to figure this out.
Once we got the SXAPI installed and configured I ran their "Canary Test" program to check the connection to our back end Infor server. The Canary Test is a cute little app with a picture of a canary on a perch. When you do the test, if it succeeds the canary stays on its perch and you get the "success" message. If the connection doesn't succeed, the canary "dies" and the picture changes to a canary on its side with an "x" over its eyes. Unfortunately, the canary kept "dying."
For two weeks I went back and forth with my Infor tech support contact. He had no ideas why it wouldn't work. I sent him error messages, reports from the Infor server confirming I was trying to connect to the correct IP Addresses and ports, and other information. In between emails and phone calls I worked with two of our network admins checking for messages in the firewall logs and running sniffer traces to see if we could diagnose the problem. I even went and gave my Infor tech contact all the details of our network configuration so he could replicate it and try to diagnose the problem.
The production B2B server has 2 NICs; one goes out to the WWW and the other only connects to a SQL Server we run for dynamic content - both are on different IP subnets. Even though we have static routes in the B2B server to send the traffic in the right direction, for some reason the packets the SXAPI generated were trying to go through the NIC for the SQL server, which is in a non-routable address segment. No matter how we tweaked the static routes or messed around with the settings on the server, we couldn't get the traffic to go out the correct NIC to our Infor server. Our tech contact at Infor didn't seem to understand the problem, and finally told us he was punting to a developer to see if any light could be shed on the problem. He even told us at one point that the canary test probably wouldn't work through a firewall since it did more than just test for a good connection.
In the meantime, I've got a lot of people who want to have this API working (most of all me, 'cause I've got a lot of other things to do) so our customers can take advantage of the ASP.NET inventory query app we wrote. Nothing seemed to work at all. There was no documentation on this kind of issue, no solution coming from Infor tech support, no Usenet or other tech groups, nothing. It was very frustrating.
While I was talking out the problem with one of the network admins, he suggested I disable the NIC the SXAPI was sending its traffic through to see if it would be "smart" enough to route the traffic through the other NIC. I was ready to try this, but thought there might be another solution.
This morning while I was getting ready for work, mulling over this issue, something hit me. When putting IP Addresses in a Windows server, when you route traffic out and don't specify which IP Address it should go through, Windows defaults to the first IP Address you entered. I started to think, what if the SXAPI was looking at the registry and routing its traffic through the first NIC installed instead of the one the Windows routing table was telling it to go through. Instead of letting Windows handle the network and routing, I wondered if it was handling the routing itself. I happened to remember the NIC handling the SQL Server traffic was built in and the one handling the WWW traffic was a PCI card I installed. The NIC with the SQL was installed first.
To that end, I swapped IP Addresses in the 2 NICs installed on the server and swapped the cables so they'd go through the correct routers - and behold - the canary didn't die when I did the test.
So, if you happen to stumble on this looking for answers to routing issues with Infor's SXAPI and you have 2 NICs, take a look at the order the NICs were installed.
Subscribe to:
Posts (Atom)
