|
Home > Archive > 70-210 > January 2002 > Smiling Joe's real life question #2
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Smiling Joe's real life question #2
|
|
| Joe Blacke 2002-01-22, 2:59 pm |
| Everybody loves troubleshooting, don't they?
This is a real life problem that was escalated to me by our second level helpdesk. Let's see you answers!
You have a remote location on your WAN. At this location, you have a Unix server and 10 unix clients who connect only to the Unix server. You also have 1 Windows 2000 professional workstation at this location. This location also has 1 network printer.
The Windows 2000 box, does not use a designated print server. It prints directly to the printer, over the network. The unix clients use the Unix server as their print server.
PROBLEM:
The Windows 2000 workstation cannot print. When the help desk connected to the workstation via PCAnywhere, they could not ping the printer from the workstation. When the helpdesk pinged any other address from the Windows 2000 workstation, all pings were returned. When the helpdesk pinged the network address of the printer from their own workstations, the printer was pingable. All the unix clients can print without any problems.
ADDITIONAL INFO:
The remote location uses only a single IP subnet. The unix server is never rebooted, unless necessary. The unix clients and Windows 2000 workstation are rebooted nightly. (I may have just made it too easy).
Your task, should you choose to accept it, is to tell me what is the cause. Additional credit will be given if you can provide a fix for the problem, in addition you will be scorned by those who can't believe they didn't figure it out.
I told you it was real life. | |
| nettech 2002-01-22, 5:07 pm |
| I'll take a stab at this.
Seems like the printer may have a different subnet mask (is that possible) than the rest of the network. Assuming the printer is on and functional. | |
| Joe Blacke 2002-01-22, 5:08 pm |
| Nope, it's not an addressing problem.
The Windows 2000 workstation could print fine, then one day it couldn't.
Remember all other workstation have no trouble printing. Only the Windows 2k box. The Windows 2k box can't ping the printer, but it can ping everything else (by name or by address). The printer is pingable from a workstation that is outside the subnet. | |
| Joe Blacke 2002-01-22, 6:33 pm |
| Man, almost 50 views and only 1 person has offered a suggestion.
You might have to think a bit, but it isn't that hard. | |
| chodan 2002-01-22, 8:41 pm |
| Was there any boot messages from the workstation about services not starting when it was rebooted?
I think we can rule out
layers one 2 and 3 on this as they have been tested out with the pings and the statement that addressing was not involved.
Other than an ACL on the nic in the workstation I`m not sure.
Hm this is a good one. | |
| Joe Blacke 2002-01-22, 10:03 pm |
| Nope. No error messages on the workstation.
If it helps you any, the printer is in constant use throughout the day by the Unix clients. | |
| chodan 2002-01-23, 6:45 am |
| Quote
"If it helps you any, the printer is in constant use throughout the day by the Unix clients."
I don`t see how that could affect the ability of the workstatikon to ping it.
Well I suppose the win2K workstation could have and erroneous entry in its ARP table.
You could try the "arp inet_addr" command
and try to resolve it.
hehe "stab in the dark" | |
| Joe Blacke 2002-01-23, 8:13 am |
| quote:
Originally posted by chodan
Quote
Well I suppose the win2K workstation could have and erroneous entry in its ARP table.
You could try the "arp inet_addr" command
and try to resolve it.
hehe "stab in the dark"
Dang, you almost got it.
Let me add this. Before they escalated the issue to me, they reinstalled the OS on the Workstation. It didn't fix anything. | |
| chodan 2002-01-23, 8:39 am |
| Did they recently change any hardware on the Workstation? | |
| Joe Blacke 2002-01-23, 9:22 am |
| Nope.
You were on the right track when you realized how two hosts on the same subnet communicate. They need mac addresses. | |
| chodan 2002-01-23, 9:31 am |
| Thats why I asked about the hardware changes
If a new nic was added to the workstation the there could be a MAC address conflict,
but Mac address conflicts don`t just appear without reason, and it is unlikely a printer nic would conflict with a pc nic, but I guess that could be the problem???? | |
| Joe Blacke 2002-01-23, 9:43 am |
| quote:
Originally posted by chodan
Thats why I asked about the hardware changes
If a new nic was added to the workstation the there could be a MAC address conflict,
but Mac address conflicts don`t just appear without reason, and it is unlikely a printer nic would conflict with a pc nic, but I guess that could be the problem????
It's practically impossible to have a MAC address conflict. So, we can rule out a conflict as the cause.
Try this. If you have any other hosts on your current subnet, bring up your ARP table and clear all dynamic entries.. Ping any of the hosts on your subnet. Reload your ARP table. What has changed?
Did that help you any? | |
| chodan 2002-01-23, 11:20 am |
| I`ve seen MAC conflicts twice in the last year.
Very rare but very possible.
You said it was not an addressing problem but does that exclude a static IP address conflicting with a dynamically learned IP address from the dhcp server, that is the static address wasn`t excluded from the DHCP scope. | |
| Joe Blacke 2002-01-23, 11:54 am |
| In order for a MAC conflict to occur, the same MAC address would have to be issued to 2 seperate NIC's. Both of those NICS would have to be placed in devices that are on the same subnet. Either that, or you would have to have a NIC that would allow you to change the MAC address.
Our particular network, covers the entire North American continent. We have literally over a million hosts. The chances of 2 NIC'S being issued the same MAC number, and both of those NIC's being placed on the same subnet (out of thousands of possible subnets) is very small.
I can guarantee you that it is not an addressing problem. All addresses are assigned staticly, and have to follow a strict addressing structure.
It IS an ARP problem, though.
If you think it through, what are the steps for a host to communicate with another host on the same subnet?
(summarized)
The originating host determines if the receiving host is on the same subnet.
If the host is not on the same subnet, the originating host will forward the packet to the router (using the routers MAC address).
If the receiving host is on the same subnet, the client will check it's ARP table to see if it has an entry for the specified address. If it does, it routes the packet to the MAC address of the destination host. If it does not, it issues an ARP broadcast and waits for the receiving host to respond.
Now, remember the additional info. The Unix clients use the Unix server as their print server. Meaning, this server is constantly getting requests to send packets to the printer. It has no trouble printing, because it has the MAC address of the printer in it's ARP table. Since the Unix server is never rebooted, and also has a constant stream of print jobs, it never discards the dynamic entry for the printer.
The Windows 2000 box cannot communicate with the printer. It CAN communicate with any other host on the subnet. If you cleared the ARP cache of the workstation, and then pinged any host other than the printer, it would update it's ARP table with the dynamic entries from all the hosts that respond to the ARP broadcast.
Do you see where the problem is now?
If you do, can you explain why the printer is pingable from a host that is outside of the subnet? Think back to the Unix server, and you will get your answer. | |
| sfled 2002-01-23, 12:30 pm |
| Joe, I'm glad you aren't writing questions for my 210 exam. I'd have to study 'til next Christmas. :-))
I had a printing problem on a mixed network and was stumped. I installed AppleTalk on the W2K box, it saw the printer, and that was that. Weird.
Can't wait to see how the hardcore guys solve your puzzler. | |
| chodan 2002-01-23, 1:02 pm |
| I`m stumped for now.
Is the server set up to route packets?
As for the duplicate mac addresses it really was a fluke we had a consultant come in and as soon as he plugged in he and a user on our network got a message that a duplicate Mac address had been detected.
upon further examination "using ipconfig on oneand winipcfg on the other "the addresses were identical, I didn`t think I would live to see that happen, then a few months later it happened again with a salesman and our IS manager. | |
| Joe Blacke 2002-01-23, 1:35 pm |
| Okay, this isn't a Windows 2000 Problem.
This is a NETWORKING problem, though.
The hard part is that the problem would indicate a problem with the Windows 2000 workstation.
So what is the problem? It's the Printer. More specifically, it's the NIC in the printer.
The Windows 2000 box is rebooted every night, so when it is rebooted, it clears out the ARP entries. When it did that, it lost the dynamic entries it had for the printer.
Sometime since the workstation was rebooted, and the next print job was sent to the printer, the NIC in the printer refused to respond to ARP requests. It handled all other traffic fine, though.
Since the Unix server was always sending print jobs, it had stop sending out ARP broadcasts. It already had the MAC address of the printer, so there was no need. Had the Unix server been rebooted, or the ARP entries timed out, then the Unix server wouldn't be able to send print jobs to the printer either.
Chodan was on the right track. He thought of network connectivity issues, and networking protocols. Just looked in the wrong direction, though.
How do we know it wasn't the Windows workstation? Well, the only connectivity problem the workstation had was with the printer. It could ping all other hosts without any problem. To prove that it wasn't the workstation, I had the helpdesk PCAnywhere into the workstation, and bring up the ARP table. I then had them clear all dynamic entries and ping another host on the subnet. When the workstation needed to ping the host, it needed the MAC. It sent out an ARP broadcast, and it receive an ARP reply. It then updated it's table properly and routed the ICMP packets to the proper host. I then had them clear out the ARP table again, and ping the printer. This time, there were no dynamic entries for the printer. Next, I had them add a static entry for the MAC address of the printer in the table. All ping were now being returned without a problem, and the print jobs were being printed.
However, if you rebooted, or even logged off, you lost the static entry. You were then back to sqaure one.
Management was convinced it was a problem with the workstation. They even had it reimaged a second time after they talked to me. Didn't fix the problem. I spent two days taling to over a dozen people, and each one I had to physically sit them in front of a monitor as I connected to the workstation, and entered the ARP entry for the printer, before they would believe me. I even had to do this when the tech went onsite, cause he refused to look at the printer and kept telling the helpdesks that the problem had to be with the workstation.
At that point, I got fed up and wrote a simple batch file to update the ARP table. I put it on the desktop for all users to run each time they needed to print. The only problem is that because of Windows 2000 policies, they were restricted from running anything that wasn't in their start menu. They didn't have the ability to change their start menu either. Management refused to incorporate the batch file into part of the script, or assign it as part of a GPO. I wasn't about to go through the hassle of talking to a dozen people again, so that is when I got interested in learning how to break Group Policies.
Management knew that I could get the workstation to print. However, because I had to enter the entry into the workstations ARP table and the printer was pingable from outside the subnet, it convinced them even more that the problem was with the workstation. I finally had to use a tool that management could understand; money. I told them that they could spend another grand to replace the PC and reload the os, only to continue to have the same problem, or they could replace the $20 NIC in the printer. They relented only because it was CHEAPER to replace the NIC than the PC.
Replaced the NIC, and badda boom, badda bing, everything is hunky dory.
Worked out good for me, though. I got a 50% raise, and only have to work 14 days a month.
I would NEVER put this type of a question on a test. Besides, it would have to be multiple choice, so statiscally, some poeple would get it right. This type of problem is practically unheard of. I honestly have never heard of a NIC refusing to respond to ARP broadcasts until now. I aksed a question that was probably as close to impossible as you will ever see.
Now, can anyone explain why the printer was pingable for outside the subnet? Think of the route a packet would take: Host, Router, printer. Then remember, that this is a NETWORK printer. | |
| chodan 2002-01-23, 1:53 pm |
| The router probably had its mac address in its arp table. | |
| Joe Blacke 2002-01-23, 2:14 pm |
| It did. It's the only way it could be pingable from outside the subnet.
The printer has it's own IP address. Anyone with the appropriate rights on their workstation can set up a printer to print to this print device. Just be sure to use the appropriate drivers. You don't always have to use a seperate print server.
Also if you had ANY network connectivity with the printer, even just pinging it, from outside the subnet, the router would perform an ARP broadast. At one point or another, the printer had replied, and the entry had been added to the routers ARP table. | |
| nettech 2002-01-23, 2:25 pm |
| Im curious as to what type of NIC was this? is this specific to this particular NIC or the manufacturer? | |
| Joe Blacke 2002-01-23, 2:52 pm |
| Don't have a clue.
Printer was a Lexmark, though.
Whoever we bought the printers from, also sold us a service agreement/warranty. They are the people that actually have to work on the printers.
Most of our workstations use Intel 3Comm NIC's. | |
|
| Have you thought of enabling netbios over tcp/ip to propagate a broadcast over a router. This is most times an easy fix when a rebooted client loses network connetivity it had yesterday.
Is this using a netport for printing and what model if so?
-Jay | |
| tlabastidas 2002-01-30, 5:39 pm |
| Is than an HP printer? Are they using DLC on the Win2k box to connect to it? This could be how to work out the problem.
As the Unix stations are printing fine (so they are using the IP link on the Jetdirect card) it can tells us that the problem is not related to the IP config on the printer itself. The subnets explanation could be another thing to check also. Of course, now that they reinstalled the software on the Win2k box (bad bad idea) they left you wondering if it's a MAC problem (not so on my opinion, as the Win2K box is seeing the Unix stations).
Comments? | |
| chodan 2002-01-30, 7:33 pm |
| Uh he already gave the solution.
The old nic on the printer was not responding to arp broadcasts. |
|
|
|
|