Cannot connect to print server. 1

[jheine]

Hi all.

I'm having a strange issue trying to connect to a print server in a remote location. To give a really quick rundown of the topology, we have frame relay connecting multiple sites, local file servers at the sites, printers are on internal or external print servers, application servers are at main location.

I am not able to connect to a particular print server, located on 192.168.60.81/24, from a Windows 2000 server at 192.168.1.152/24. I cannot even ping the print server from this one Windows server. All IPs are static, and I did double check the settings on the server and print server.

Here's the curve ball. From the 192.168.1.152/24 server I am able to ping other PC's and devices, such as another printer at 192.168.60.80/24 and the locations file server at 192.168.60.50/24. The problem server is also a Citrix server and is used by everyone on the .60 subnet. I am alo able to ping the print server in question from other PCs on this subnet, such as from my workstation (192.168.1.104/24) or from another Citrix server (192.168.1.158/24).

I've been banging my head against this for a couple days now and just can't figure it out. Any ideas would be great.

Thanks

Jarrett

 

[John Lewis]

I had to read this a couple of times to make certain I had the facts straight. This certainly is an odd situation and I do hope you will report your resolution.

Perhaps someone will come along with a snap solution, but a few things to try until then.

First, you did not mention the specific response you are receiving to the failed ping command. I will assume that your are getting 4 'request timed out' replies. Also, it may be helpful to know the manufacturer and model of your print server that is behaving badly.

It would seem that there is nothing network wide blocking ICMP (ping) traffic. Also, your print server is configured to respond and the server in question is configured to allow traffic in, as you can ping to and from other devices. That in mind, network traffic between the two devices is either being blocked, lost or redirected.

The first thing to try would be resetting the print server, if you have not done so already. Not a reset to factory defaults, simply power down the device, wait 30 seconds or so and power back up.

The next thought that comes to mind would be firewall software on the W2K server in question. If this particular print server has the W2K server set as a syslog server, there could have been events on the print server that triggered data to be sent to the syslog server. Some firewalls may flag this activity as malicious and block further traffic from the host.

Failing those two items, I would start with another ping attempt with a couple of additional options:

ping -l 1 -w 60000

The -l 1 will set the packet size to 1 byte and the -w 60000 sets the timeout to 60 seconds, so be prepared to wait a bit for those request timed out messages. If something is marginal between the two devices, these options will give the best chance for a response to make it through.

Given your network topology, a tracert may be helpful as well if your hardware is configured to respond to ICMP requests. Try 'tracert 192.168.60.80' followed by 'tracert 192.168.60.81' and compare the two. If your hardware responds to ICMP, you should be able to figure out where the break is taking place.

 

[jheine]

Thanks mhkwood.

Sorry, I am getting 4 time outs between the server and the HP jetDirect 500X print server. This is a working print server, as one of the ports is used by another printer in the office that is not mapped through the local file server. I have had the print server unplugged a couple times to reset it. Also, we are not using software firewalls. We have a Cisco PIX between our WAN and the pipe to the outside. I can't see why it would be plocking pings between these two devices across the frame.

I tried the ping -l 1 -w 6000 on 192.168.60.81 and got back the 4 'Request timed out." messages. 192.168.60.80 (which is a Lexmark T634 with internal print server) came back fine:

Pinging 192.168.60.81 with 1 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.60.81:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

Pinging 192.168.60.80 with 1 bytes of data:

Reply from 192.168.60.80: bytes=1 time=66ms TTL=252
Reply from 192.168.60.80: bytes=1 time=45ms TTL=252
Reply from 192.168.60.80: bytes=1 time=39ms TTL=252
Reply from 192.168.60.80: bytes=1 time=48ms TTL=252

Ping statistics for 192.168.60.80:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 39ms, Maximum = 66ms, Average = 49ms

Tracing route to L006KITNLEXT634 [192.168.60.80]
over a maximum of 30 hops:

1 2 ms 1 ms 1 ms 192.168.1.5
2 41 ms 40 ms 40 ms 172.16.130.2
3 41 ms 42 ms 42 ms L006KITNLEXT634 [192.168.60.80]

Tracing route to 192.168.60.81 over a maximum of 30 hops

1 * * * Request timed out.
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
~
29 * * * Request timed out.
30 * * * Request timed out.

Trace complete.

I also did a traceroute from my workstation to the print server:
Tracing route to 192.168.60.81 over a maximum of 30 hops

1 2 ms 2 ms 2 ms 192.168.1.5
2 41 ms 40 ms 43 ms 172.16.130.2
3 43 ms 42 ms 42 ms 192.168.60.81

Trace complete.

Hope this info helps. In the meantime, I'm setting up a syslog server to see if I can get more info. Thanks again.

Jarrett

 

[John Lewis]

The tracert response would indicate that traffic for 192.168.60.80 is not even leaving the server in question. You should at least get replies from 192.168.1.5 and 172.16.130.2. This being the case, I don't think logging will help.

Try 'ipconfig /all' on the server and make note of anything odd, epecially if you see something on the 192.168.60 subnet.

Also, check the event log on the server. Might be something already logged there.

My next action would be to use a packet sniffer to see if the traffic for 192.168.60.80 is getting out of the server. I use ethereal (

http://www.ethereal.com).

Free and does a good job. Installed on the server, you should be able to see the packets generated and something odd might show up. You will also want it installed on another machine so you can see if the packets are physically leaving the interface. If you are using a switch instead of a hub on the server end, you may need to plug the server and the computer you are using to sniff into a hub and then connect the hub to the switch to make certain the traffic gets to the sniffer. You can also configure most switches to accomodate sniffing, but it is usually quicker to insert the hub.

 

[mattKnight]

Does the print server at 192.168.80.81 respond to a ping from the local Lan.

Is the default gateway for the print server set? i.e. does it have a valid reverse route?

Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[jheine]

Sorry about the wait. It took me a couple days to find time to do this. I am not seeing ICMP info leaving the server when I ping between 192.168.1.152 and 192.168.60.81. All I see when I try to ping is ARP requests. I am seeing ICMP traffic when I ping 192.168.60.80 from 192.168.1.152. I also see the ICMP traffic going between 192.168.60.81 and 192.168.1.104 (my workstation). I am monitoring from 192.168.1.39, which is plugged into a port on our main backbone switch that is set up for monitoring. I am also using Ethereal on 192.168.1.152.

The network configuration looks good. I've probably run 'ipconfig /all' a dozen times now thinking sometheing will jump out at me. I didn't find anything out of the ordinary in the event logs either.

Thanks

Jarrett

 

[GlenJohnson]

Can anybody on your subnet connect to the printer? Also, why are you trying to connect, is there a problem beyond this? Just wondering.

Glen A. Johnson
If you like fun and sun, check out Tek-Tips Florida Forum

 

[jheine]

I tested about 5 PCs/Servers from this subnet and all can ping this print server without a problem. I can also ping other devices/PCs on the .60 subnet with the server in question. I only seem to have a problem between this one server and the print server. I need to install the printers attached to the print server onto the Citrix(Win2K) server that handles that location. Since this is not the only system attaching to this print server, and these are live components, I can't just try another IP address on either side.

Jarrett

 

[John Lewis]

I am not seeing ICMP info leaving the server when I ping between 192.168.1.152 and 192.168.60.81. All I see when I try to ping is ARP requests.

This is interesting. Maybe.

At any given time, there may be ARP requests floating about your network in the form of "Who has 192.168.1.xxx . . . ". These requests are broadcast by an Ethernet device that needs to communicate with another device for which there is no existing cached ethernet address. It is rather unlikely that you should be seeing ARP traffic in direct response to your ping request. Only the 'next hop' in any TCP/IP connection should generate an ARP request, as subsequent hops should be handled by the next device in the chain. ARP entries are cached, so it is rather likely that the router that should be the first hop is already in your ARP table.

Take a closer look at the ARP traffic. Do you see packets with a broadcast destination coming from your machine? To verify that they are coming from your machine, do an 'ipconfig /all' and compare the last 2 or 3 numbers of the physical address to the address listed as the source. What IP address is being requested (directly after 'Who has')? This should be the 'next hop' -- 192.168.1.5 based upon the traceroutes you posted. It should NOT be 192.168.60.81, as the device is not on the same network. Are there any ARP replies (xxx.xxx.xxx.xxx is at xx:xx:xx:xx:xx:xx)?

If you are seeing odd ARP requests coming from your machine, especially ARP requests for TCP/IP address(es) on another network, check the subnet mask on the problem machine, although I can't think of a masking situation that would cause this single address to be a problem.

If the ARP traffic is related to the ping request, it certainly would explain why you are not seeing any ICMP -- your machine does not know where to send it. If the ARP is network noise, then it explains nothing. I would be looking for some kind of a firewall issue on the problem machine.

In any case, please post some more information about the ARP traffic. I will be thinking on this a bit more.

 

[jheine]

Well, I've pretty much given up on this issue. Since I had to go to the remote location today, I tried changing out the print server. It didn't help. I just couldn't put much more time into the problem and hold up that location in a new label printer implememntation. I went ahead and changed the IP address on the print server to 192.168.60.84, and changed the ports the printers were installed to to reflect the change. This has cleared the problem we are having with the 192.168.1.152 server for now.

I am going to put another device on the 192.168.60.81 address to keep testing though. This will haunt me, and others as well, if I don't figure it out. Also, it will probably bite me again six months from now when we have completely forgotten about the issue and try to use that IP again.

Jarrett