TCP/IP Problems 1

[dpellegrini]

Our network is a Novell based network with 2 separate segements. The internal is IPX only. We are implementing an NT/SQL TCP/IP server on the internal segment. The problem we are having is that everytime we ping to or from the server or workstation, we get a single reply and then it times out. We have very basic config. IP Address of server 192.168.0.1, subnet 255.255.255.0. We have tried different configs, look at Tech Docs from MS, Novell, anywhere else. We cannot identify what the problem is. If we put the NT on the external TCP/IP segment, we have no problem, but the workstations don't see it because MS TCP/IP is only communicating on the internal. Anyone have any ideas? No DNS, no DHCP. The workstations and the NT server are the only IP hardware on the inside. No gateway, switches or routers on the inside. Help!!

 

[dpellegrini]

Thanks for the suggestion. tried both but neither worked. Any other hints would be appreciated. We are thinking that the primary novell server is grabbing the packets erroneously. When we do a netstat-a from the workstations, it lists the primary servers name and 0.0.0.0, which is the address that our sniffer shows when the timeouts occur. Could a hostfile and/or a reference in the primary servers routing table be the couse? our routing table is pretty clean- default to router, 38.0.0.0 to router, and 38.xxx.xxx.0 to server. All the ip's are in the same range with a 255.255.255.0 mask. Pretty much set itself up by default. This is the route for the external ip segment. I can't explain how or why the external segment is capturing ip communications on the separate internal segment.

 

[chgwhat]

It is a routing problem, try typing in dos route add 192.168.1.0 mask 255.255.255.0 (workstation ip) or check tracert 192.168.0.1 to see who get the trace. The workstations default route points to the internet gateway, the gateway doesn't know the 192.168 segment is internal and sends it out. either add the route to the workstation or move the server to a valid internal address.

 

[dpellegrini]

Thanks for the info. Let me clarify our config for you for a better picture, and I'll tell you in more detail the things I've tried.<br><br>&nbsp;We have 3 NW servers *(see note) with 2 nics each. One NIC IPX & IP. This is to provide connectivity to our remote site. This is segment #1. This external segment does have a router, 38.208.66.1 (I know I shouldn't give these addresses out, but it's easier for now). the servers are 38.208.66.3, 66.4, and 66.10. On the 2 NIC's for the internal LAN, they are bound to only IPX. *( 2 NW4.11 and 1 NW 5) (a side note, we have had this problem before the 5.x box was installed) <br><br>All workstations are using client 32. Internet access is achieve via NW IPX-IP gateway (where this may seem relevent,&nbsp;&nbsp;I don't believe it is, I have 1 PC that I tried to communicate with that doesn't have any of novell's clients and only IP and it has the same problem.)<br><br>Enter the NT SQLserver. 1 NIC bound to tcp/ip-196.168.0.1&nbsp;&nbsp;255.255.255.0<br><br>MS tcp/ip was installed on my workstation. 196.168.0.6 255.255.255.0, no gateway, we didn't feel it was necessary, the workstations only had to communicate tcp/ip directly with the NT box, although I haven't ruled the possibility out.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;When pinging we get an immediate response from the NT server and immediate time-outs after that. So I then put a sniffer on the network from a laptop I have for just such an emergency. No Novell client on it, only IP.The sniffer showed the server and the workstation (and itself, the laptop), but also a curious anomoly. it showed 0.0.0.0. This&nbsp;&nbsp;address was intercepting ping packets and not alowing the NT box to respond. Or so I concluded. So I looked at the&nbsp;&nbsp;arp tables on the server and workstations, the nbtstats and finally the netstat. netstat was the most revealing it showed 0.0.0.0 AND the name of the primary NW4 fileservers name, which is set in it's host files list to 38.208.66.3.So I began getting creative with my internal IP addressing. I tried different submasks, of course making the&nbsp;&nbsp;appropriate changes at the workstation. I tried adding various gateways (192.168.0.1 or 38.208.66.3). I tried referencing the 38.208.66.3 in the host table on the nt and or the workstation. Nothing worked. I tried changing the internal range&nbsp;&nbsp;to the 38.208.66.x addressing, not expecting to work.<br><br>I'm not really well versed in tcp/ip, but I tried everything I know. I got onto the internet and looked at Novells TID's, Microsofts support, and searched for advanced TCP/IP troubleshooting. Everything was vague, like &quot;if you've tried this, you have a problem&quot; or told me to do what I have already done at the beginning stages. We don't have a router, gateway or switch on the internal segment. As far as the network goes, neither segment knows the other exsists, unless there is config file I'm missing. I've put pleny of NT TCP/IP boxed on Novell routed and nonrouted networks. I've&nbsp;&nbsp;never had to do anything special other than make sure the IP addressing was correct. I've never encountered anything like this. You can ping internally at any random time, and it will respond like&nbsp;&nbsp;gangbusters, then it will time out and act like network? what network?<br><br>I'll try your suggestion and see what happens. If you have any other advise I would be very happy to receive it. I've even looked at the physical layer of the internal, ie:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;hubs and nics. I can't identify anything that would cause this. And the packet capture I did with the sniffer only gave the infomation that ICMP responded HOST NOT FOUND. <br><br>Thanks again and I hope to hear back.<br>Dom

 

[chgwhat]

I would try just the workstation and server nothing else. This would rule out these two boxes. A test with a simple crossover cable would do it. If you still have a problem I would start checking or fresh install of these two boxes. Can you confirm that the workstation has no novell client's install.

P.S. The 0.0.0.0 that you see on the sniffer are broadcast packets, Generated by all ip routing boxes and MS file shares.....

 

[dpellegrini]

This weekend we stripped the network down. We are using 4 stacked hubs (10/100). We downed all of the servers. Only the NT box was running. We tried 3 PC's (2 desktops w/ Client 32 and TCP/IP, 1 Laptop TCP/IP only). We got connectivity through each hub and combination of hub stacks on every workstation we tried. By the way we disconnected all other patches to the hubs.We also tried this same routine with the Novell servers on the network (again in mixed and single hub connections). Our thought was to rule out hubs, nic's, wiring, etc). We were able to get 100% connectivity with every configuration. We plugged all of the patch cables back into the hubs, and again tested connectivity. We lost our connectivity. But this doesn't make sense to me because we turned off every PC, printer or device on the network. All we did was plug the cables back in. There are only 50 connections, so this was easy to manange. So now we have ruled out server/workstation config, hubs, and hardware, unless I'm missing something. The only thing left is the cabling in the building. However 2 years ago, troubleshooting tcp/ip connectivity, they hired a cable company to test for any cabling problems. Nothing was reported. In the past, they have also tried using switches and different brands of hubs to get IP working. I'm suspecting that the is something causing interference in the cabling. Any other idea's or suggestions? I've run out clues and idea's.<br>Thanks,<br>Dom

 

[2ffat]

&nbsp;&nbsp;&nbsp;&nbsp;You're going to laugh at this idea but it <u>might</u> point you in the right direction. We put all our wiring into the walls before the masonite was put up. We tested everything with no problems. A couple of years later, someone put a picture on the wall. The connection for that room when down. We found out that when they put the picture up, they put a nail through our cable. :-(<br><br>&nbsp;&nbsp;&nbsp;&nbsp;It sounds like you eliminated the PCs and hubs. Can you track back which connection you made that caused the problem? Maybe a &quot;rat&quot; gnawed through a cable. <p>James P. Cottingham<br><a href=mailto: > </a><br><a href=

http://www.ivcusa.com>International

Veneer Co., Inc.</a><br>All opinions are mine alone and do not necessarily reflect those of my employer.

 

[dpellegrini]

Well here is an update.<br>We have solved the mystery. It was a modem pool Novell 3.11 server locked away in a closet. It didn't have TCP/IP bound to anything. But the MicroTek application running on the server, which is the program for modem pooling, was running tcp/ip routing. We discovered this device when we started looking at Mac addresses in Sniffer and Lanalyzer, and then traced the connection one by one on the patch panel. Once we disabled tcp/ip in the application, our tco/ip problems disappeared. None of us had suspected an application to be causing this kind of problem. Only one person even knew about this computer. Well the mystery is solved and a good lesson learned.<br>Thanks for all you help!<br>Domenick Pellegrini