TCP/IP Troubles

[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!!

 

[hnd]

First thing you should do:<br>Try on both parts a local ping to 127.0.0.1<br><br>If that works each basic local configuration is ok and then it may be a problem of the network hardware or a mistake in the global network configuration.<br><br>May be a double IP address wrong netmask..... <p>hnd<br><a href=mailto:hasso55@yahoo.com>hasso55@yahoo.com</a><br><a href= > </a><br>

 

[dpellegrini]

Each work station can ping itself and the loopback address. The masks are ok. I put the server on the External IP segment and it communicates fine. I want to agree with you about the global network config, but I don't know what to identify. When running sniffer and looking at the network map, it appears that evey time the ping times out, the address of 0.0.0.0 is displayed and it seems to be stealing the packets, not allowing a response from the destination address. The would indicate a routing problem, however there is no router on the segment having the trouble. When running the netstat -a command, the primary server (novell) (2nics, IP for external, ipx for internal) is displayed as the local address, and the foreign address of 0.0.0.0. This shouldn't be happening. I looked at the routing tables on the primary server, and they are very basic. I checked for NAT, SNMP, etc, they are not running. I don't know if this gives you anymore info to work with. <br>Thanks for the help.

 

[dpellegrini]

Also, we don't thinks it's a client issue. I've tried TCP/IP only, along with our standard client 32, on the workstations. The server is only running TCP/IP.

 

[Puffin]

1.&nbsp;&nbsp;What version of Novell are you using?<br><br>2.&nbsp;&nbsp;What are the Workstations?&nbsp;&nbsp;(95, 98, NT)<br><br>3.&nbsp;&nbsp;In the sniffer trace when you see the 0.0.0.0 trace is it an ARP packet?<br><br>4.&nbsp;&nbsp;What type of Frame are you using at the workstation?&nbsp;&nbsp;<br>&nbsp;&nbsp;&nbsp;&nbsp;(If set to AUTO and not using 3.1x manually set it to 802.2)&nbsp;&nbsp;If the client does not <br>&nbsp;&nbsp;&nbsp;&nbsp;know it's network address it will send a packet on the 0.0.0.0 address to see if it<br>&nbsp;&nbsp;&nbsp;&nbsp;gets a reply to discover it's network's address.&nbsp;&nbsp;So you could see an up to the 4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;different Ethernet frame types be polled.&nbsp;&nbsp;Your TTL could be expiring on you IP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;packet while this is going on.<br><br>5.&nbsp;&nbsp;Is this a 10baseT or 100baseT network?<br><br>6.&nbsp;&nbsp;Have you tried a Tracert &lt;IP&gt; and seen what you get?<br><br>7.&nbsp;&nbsp;Do you seen any ICMP errors in the Sniffer Trace?&nbsp;&nbsp;If so what are they and what&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;are their codes ( if they have one)<br><br>Sorry, I'm not more help but I needed more information about your network.

 

[dpellegrini]

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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&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<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;communicate with that doesn't have any of novell's clients and only IP and it has the same problem.)<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Enter the NT SQLserver. 1 NIC bound to tcp/ip-196.168.0.1&nbsp;&nbsp;255.255.255.0<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(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<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;range&nbsp;&nbsp;to the 38.208.66.x addressing, not expecting to work.<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;like network? what network?<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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&nbsp;&nbsp;&nbsp;HOST NOT FOUND. <br>Sorry for the breakup of the text, I have another thread goin for the same problem on a different forum. So I suta an paste. I've tried auto frame and 802.2, I've changed the TTL. We have 10/100 hubs and we are running 100 from the workstations and servers nics. Tracert gives host not found or invalid IP error. Above you will see the ICMP error. No error code though. I hope this explains better. <br>Thanks for the help.<br>Dom

 

[Puffin]

Ok,&nbsp;&nbsp;I have a better idea now.&nbsp;&nbsp;<br><br>First what does&nbsp;&nbsp;netstat -s -p IP show you?<br><br>Have you tried to ARP your NT server's IP?&nbsp;&nbsp;( arp -a 192.168.0.1)&nbsp;&nbsp;does it know the MAC for the server?<br><br>Have you tried ipconfig on the NT Server and Winipcfg on the 9x workstation?&nbsp;&nbsp;Do they both have a valid Ip on the same network?<br><br>Refresh the NBTstat tables by entering&nbsp;&nbsp;nbtstat -RR.&nbsp;&nbsp;(Release and refresh)&nbsp;&nbsp;This should rebuild the netbios to ip tables.<br><br>Have you thought about setting up DNS or WINS on the NT Server?&nbsp;&nbsp;How about setting up the NW 5 DNS & DHCP servers for the segment?<br><br>The other thing I wanted to point out is that you used both 192.x.x.x and 196.x.x.x in your message.&nbsp;&nbsp;I took that as a slip of the finger on the keyboard.&nbsp;&nbsp;But you do have all the computers in this segment on the same Network correct?<br><br>The only other thing I can offer is to check your cables and make sure that they are wired correctly.&nbsp;&nbsp;I once saw where they were wired not using the twisted pairs.&nbsp;&nbsp;Pins 3 and 6 were on two different pairs and this only caused a problem when you went past 50 feet.&nbsp;&nbsp;But it brought the network down.&nbsp;&nbsp;Of course this did not become a problem until we moved them from 10baseT to 100baseT.&nbsp;&nbsp;You might want to check that.&nbsp;&nbsp;It's a long shot at best.&nbsp;&nbsp;<br><br>Doug<br><br>

 

[dpellegrini]

Thanks for pointing out my typo. The range is definitely 192.168.x.x with SNM of 255.255.255.0. I checked the subnets and ip's on the workstations and servers. I will have to try the netstat -s -p and the nbtstat -RR. ARP does show the correct MAC. Running LANALYZER, it shows the TCP/IP and Netware communication on the network, yet at the same time the TCP/IP machines won't respond to pinging. I inquired about the nature of the cabling. When initialy installed it was tested and certified, however I think that we need to retest it. We checked each hub separately and in stacks. There are only 4 stacked hubs, but we spent 7+ hours trying many different configs and scenerios to see if they can be the point of failure. There was no conclusive evidence that points to them. I will check what you recommend today, and see what the info says. Thanks for the feedback. We've had 2 engineers look at this and check with a number of forums and noone has been able to put a finger on the source of the problem. We have researched and tried every troubleshooting technique recommended, over and over again. But I think we are starting to narrow it down, thanks to everyone responding. <br>Thanks again,<br>Dom

 

[Puffin]

Dom,<br><br>Did the ARP show the correct IP with the MAC?&nbsp;&nbsp;<br><br>Here is what I would like you to try.<br><br>0.&nbsp;&nbsp;On both the NT Server and the Test Workstation I would like you to ping 127.0.0.1.&nbsp;&nbsp;Make sure you get three replys back.&nbsp;&nbsp;Then Ping &lt;IP&gt; of the station.&nbsp;&nbsp;Did you get the 3 packets again?&nbsp;&nbsp;This will verify the IP stack and that we can get out through the NIC.&nbsp;&nbsp;I'm sure you have done this it is to just verify that nothing has changed.&nbsp;&nbsp;Were all three times to live = 128?&nbsp;&nbsp;Was the value of the TIME about the same around 10?<br><br>1.&nbsp;&nbsp;From a different workstation start a Packet capture.<br><br>2.&nbsp;&nbsp;From the Test Workstation&nbsp;&nbsp;Ping 192.168.0.1 (NT Sql Svr)<br><br>3.&nbsp;&nbsp;After pinging run NETSTAT -s ¦more&nbsp;&nbsp;.&nbsp;&nbsp;This will return the stats on the protocols.&nbsp;&nbsp;Look carefully at the IP and the ICMP stats and let me know if you get any errors.<br><br>4.&nbsp;&nbsp;Next type ARP -a&nbsp;&nbsp;and make sure that the IP and the MAC for the NT server are listed.<br><br>5.&nbsp;&nbsp;Now move to the NT Server and repeat steps 2 thru 4 making the appropriate changes to the IPs and what not..&nbsp;&nbsp;<br><br>6.&nbsp;&nbsp;Stop the Packet capture and review it for ICMP errors.&nbsp;&nbsp;If you can save the capture will you email it to me?&nbsp;&nbsp;&nbsp;<A HREF="mailto:daschultz@mindspring.com">daschultz@mindspring.com</A>&nbsp;&nbsp;I think it should be an ASCII file that I can open or import into my analyzer.&nbsp;&nbsp;I'll take a look and see if I can see a trend or smoking gun.<br><br>Doug<br><br><br>

 

[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