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

 

[DrGreen26]

OK, I am going to assume you know something about IP and ARP tables??&nbsp;&nbsp;If not, this may be difficult to resolve.&nbsp;&nbsp;First off, since you do not have a DNS server and are only pinging the devices, the workstations and servers must either a) be on the same segment and the subnetwork must be identicle, or b) have a default gateway specified in order for ARP to work if the devices are on separate subnetworks.&nbsp;&nbsp;In your statement, you mention that there is no router??&nbsp;&nbsp;So my next question would be to you is the following:&nbsp;&nbsp;You have two segments, what is an IP Address of one of your workstations and the subnet mask, and what is the IP address of the segment in which the servers reside with its corresponding subnet mask?<br><br>IP Addressing 101 basics:<br><br>Example: 192.168.0.1 with a subnet mask of 255.255.255.0&nbsp;&nbsp;this means the the sub network number is 192.168.0.0&nbsp;&nbsp;in either case, both servers need to be on the same sub network number or they will not work.&nbsp;&nbsp;Since you have no router or default gateway specified, the workstations would also have to be on this same sub-network, or they to will not be able to communicate with the servers.<br><br>You mentioned that you have 2 separate segments, and no router or default gateway, thats fine in the IPX world with Novell 4.x, but with NT and NW 5, its an IP realm, and no two sub-networks can exist on the same wire.&nbsp;&nbsp;This would require a router in between the two in order to work.<br><br>Example:&nbsp;&nbsp;192.168.0.1 for Novell and 192.168.0.5 for the NT (This will allow both servers to communicate because they both reside on the 192.168.0.0 sub network, please note that the workstations would also have to be on the same sub-network as well in order to communicate with the servers via IP.&nbsp;&nbsp;&nbsp;If by chance you decided to do something like:<br><br>192.168.0.1 for novell and 192.168.1.1 for nt and had them both plugged into the same segment with the 255.255.255.0 subnet mask, guess what?&nbsp;&nbsp;No Talky!!&nbsp;&nbsp;Why:&nbsp;&nbsp;because the novell server would be on the 192.168.0.0 subnet and the NT server would be on the 192.168.1.0 subnet and in order for two different subnets to talk they need a ROUTER in between them.&nbsp;&nbsp;That would more than likely explain why the server would work when it is moved to the other segment although it does not explain why your pc's can't see it and how it is routing from segment a to segment b and vice versa.&nbsp;&nbsp;So if you know about IP, then I hope I did not regurgitate something you already knew, if not, then consider this lesson 101 basic IP addressing.<br><br><br>Your 192.168.0.x with a subnets mask of 255.255.255.0 breaks down like this:<br><br>IP Address&nbsp;&nbsp;&nbsp;&nbsp;192&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;168&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;X<br>Subnet Mask 255&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;255&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;255&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0<br>Subnetwork&nbsp;&nbsp;&nbsp;192&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;168&nbsp;&nbsp;&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0<br>Broadcast&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;192&nbsp;&nbsp;&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;168&nbsp;&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;255<br>Low Host&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;192&nbsp;&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;168&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1<br>High Host&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;192&nbsp;&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;168 .&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;254 <br><br><br>I would move to an IP Addressing scheme that is like this.<br><br>192.168.x.x where x is your host number and use a subnet mask of 255.255.0.0 this would make your sub-network number 192.168.0.0 and it would allow for you to have more hosts.<br><br>Example:<br><br>IP Address&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;192.168.0.1<br>Subnet Mask&nbsp;&nbsp;&nbsp;&nbsp;255.255.0.0<br>Subnetwork&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;192.168.0.0<br>Broadcast&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;192.168.255.255<br>Low Host&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;192.168.0.1<br>High Host&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;192.168.255.254<br><br>This way you could specify your addressing something like this<br><br>192.168.1.X&nbsp;&nbsp;&nbsp;&nbsp;For 95/98 Machines<br>192.168.2.x&nbsp;&nbsp;&nbsp;&nbsp;For NT Machines<br>192.168.6.X&nbsp;&nbsp;&nbsp;&nbsp;For Novell Servers<br>192.168.7.X&nbsp;&nbsp;&nbsp;&nbsp;For NT Servers<br><br>and it would allow for growth etc.&nbsp;&nbsp;Please, take this only as advice, since I am not familiar with your IP environment and its actual configuration.&nbsp;&nbsp;These are just scenarios that may help with troubleshooting the problem you are currently dealing with.<br><br>I have seen a similar situation on our test network, and it had to do with the IP addressing, and having two different sub network numbers, once I ironed this out, and got rid of the default gateway stuff, everything worked. Our test environment at the time, had one hub and no router.<br><br>I would also encourage you to become familiar with ARP, from the workstation you can do ARP -a which will display the IP addrs and mac addresses of the devices it resolves.&nbsp;&nbsp;This would also apply to the NT server.&nbsp;&nbsp;On the Novell server, you need to load TCPCON, and I believe you need to select TCP/IP and address resolution???&nbsp;&nbsp;Dont hold me to this, I know it is tcpcon, but not sure about the menu selection.&nbsp;&nbsp;You can look at support.novell.com and search for tcpcon and arp.<br><br>How ARP works, first, when the device try's to communicate with another device, it checks its arp cache to see if the IP/Mac address exists.&nbsp;&nbsp;If it does, it knows how to reach the host.&nbsp;&nbsp;if it does not contain this information, an ARP Broadcast goes out, this is where the boradcast address and subnetwork number come into play.&nbsp;&nbsp;The arp broad cast is generated and basically asks &quot;Does anyone on this &quot;sub-network&quot; have the IP address of x.x.x.x?&quot;&nbsp;&nbsp;Notice I said sub-network, if no one on the sub-network replies, then the asking device looks to see if it has a default gateway, in which case you do not, if you did, the request would go there, and the DG would resolve the ip to mac host and respond back to the requesting device.<br><br>For testing, you can delete each entry in the arp table and when you ping the IP address of the device, the ARP tabe will update itself with the proper IP/Mac addr of the device you are pinging.<br><br>Thats about all I can offer for now...feel free to email me with more detailed information and I will try to offer any additional help if needed.<br><br><br>Also, if you want to manage your NT server via NWadmin, consider investing in NDS for NT, it makes life easier and you don't have to deal with trust relationships.<br><br> <p>Mark C. Greenwood, Certified N<br><a href=mailto:m_jgreenwood@yahoo.com>m_jgreenwood@yahoo.com</a><br><a href= > </a><br> I have been working in the industry for a little more than 10 years. I hold a current CNE certification for Intranetware 4.11<br>
I will be achieving my CNE 5 in the near future, hopefully before Novell's CCR deadline. I also have my Bachelors<br>
of S

 

[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. I think that we are on the same page already, but here goes. 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.<br><br>*( 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, 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. 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 address was intercepting ping packets and not alowing the NT box to respond. Or so I concluded. So I looked at the 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. Curious. So I began getting creative with my internal IP addressing. I tried different submasks, of course making the 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 to the 38.208.66.x addressing, not expecting to work, but I only had a few strands of hair left and I wasn't quite ready to pull them out yet. <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 never had to do anything special other than make sure the IP addressing was correct. I've never encountered anything like this. What blows my sosks off is that you can ping internally at any random time, and it will respond like gangbusters, then it will time out and act like network? what network?<br><br>I'll try your suggestion in detail, but I think I've already covered it in my troubleshooting.&nbsp;&nbsp;But I'll try it again to be sure. 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: 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

 

[DrGreen26]

Sorry it took me so long to get back to you.&nbsp;&nbsp;After reviewing your IP addressing scheme, it is definately the problem.&nbsp;&nbsp;With the IP addressing you are using, you have three sub-networks running on 2 segments.&nbsp;&nbsp;Bad thing to do.&nbsp;&nbsp;What you might want to try doing is one of the following:<br><br>a)&nbsp;&nbsp;Set the IP address of the SQL Server to something like 38.208.66.10 this would put it on the same segment as the Novell servers.&nbsp;&nbsp;Also, the workstations must be in the same sub-network.&nbsp;&nbsp;So they to musty start out with 38.208.66.##&nbsp;&nbsp;If you were to use a subnet mask of 255.255.0.0 or 255.255.224.0, you would have more than enough hosts for the sub-network, and you would also have the ability to designate the third octet for specific platforms as in an earlier reply to this.&nbsp;&nbsp;For now, since you have different sub-networks on the same segment, the devices will not be able to find (or even access via IP) each other.&nbsp;&nbsp;<br><br>ARP first checks its ARP cache to see if the Host exists.&nbsp;&nbsp;If it is in the arp cache, it can find it.&nbsp;&nbsp;Devices that reside here are always on the same sub-network.&nbsp;&nbsp;If the device is not in the ARP cache, it will in turn do an ARP Broadcast to see if the device is on the same sub-network via the Broadcast address.&nbsp;&nbsp;If no reply, then by default, it would look at the default gateway if one is specified.&nbsp;&nbsp;<br><br>You can email me directly if you need more help, or you may call me if necessary...seems were both on the same track, now its time for a resolution if you have not already implemented one.<br><br> <p>Mark C. Greenwood, Certified N<br><a href=mailto:m_jgreenwood@yahoo.com>m_jgreenwood@yahoo.com</a><br><a href= > </a><br> I have been working in the industry for a little more than 10 years. I hold a current CNE certification for Intranetware 4.11<br>
I will be achieving my CNE 5 in the near future, hopefully before Novell's CCR deadline. I also have my Bachelors<br>
of S

 

[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