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

 

[rlewisii]

I tried the IP address that you have in your e-mail and I got simular results.  When I changed to an IP address of 192.168.1.6 I could ping things around the network again.  I think you want to keep your IP addresses between 192.168.1.1 and 192.168.1.254 with your submask.

 

[dpellegrini]

Thanks,<br>I'll give it a try. We've tried everything else, troubleshot everything else and even combined the segements into 1, used a single IP range and subnet and still can't consistantly ping on the network. But I don't think we've tried this yet. I'll let you know how it works. You can get more history on this problem by looking in the postings for Netware 4, Windows NT 4.0, and TCP/IP forums. <br>Thanks, <br>Domenick

 

[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

 

[FredWagner]

For what it's worth, I had a similar problem once, but the culprit was a firewall. I was using IPX at the workstation for the servers, and IP to get to the internet through an Elron firewall. I also had an accounting system running on IP over the same network. On the firewall, I defined the address ranges for the workstations and specified them for Network Address Translation, and they all worked, but the comunication with the accounting server would fail. It turned out that the firewall SUPPRESSED any packets coming from&nbsp;&nbsp;addresses it had not had expressly defined to it. Very secure! BUT you have to tell it about every address on your system (by ranges) even if they are NOT going to be part of the NAT operation. IP is solid, but you have to be careful and specific. <p>Fred Wagner<br><a href=mailto:frwagne@ci.long-beach.ca.us>frwagne@ci.long-beach.ca.us</a><br><a href= > </a><br>

 

[dpellegrini]

Yeah, this really through us off. IP just isn't that complicated. We had tools that gave us the answer to the problem, but we weren't looking in the right direction. We had a great many people stumped on this one. We even had others read our packet captures and there was nothing pointing to the root of the problem.