You're working the help desk and get a call that a user can't access the UNIX host at 150.150.32.157. You are on the same subnet as the user and the UNIX host, and try to ping the UNIX host. You can successfully do so. You can also ping the user's workstation. when you ask the user to enter ping 150.150.32.157, all they get is a series of Destination Unreachable messages. What is the problem? What should you do to solve the user's problem? :dead: (note:- the problem seems to be very funny..how such problem can exist? Everything seems to be correct but still the workstation cannot ping 150.150.32.157)
Make a small correctn..In the middle of the questn ip address is written 150.150.31.157..Actually it will be 150.150.32.157 throughout..The mistake is implicit i thnk..
The host 150.150.32.157 may be dropping all the ICMP requests from the machine from which you are ping-ing. To solve this problem, remove that firewall setting in the host so that your machine can ping the host.
I think it is a gateway problem. The user's machine doesn't have the default gateway set in his PC. to resolve this add the default gateway. In GNU/Linux the command wil be route add default gw <ip> <interface>
If the host is dropping the the ICMP packets then how the help desk is able to ping the host?? :thinking:
If there is a gateway problem then how the help desk is getting reply from the workstation on ping-ing the workstation of the user??:crazy:
We can drop all the ICMP requests that comes from a particular IP address using the firewall settings. So there is a possibility of the host dropping the ICMP requests from the pinging machine and responding to other machines.
let me explain you some points:- 1) as per my question the user has called up a help desk. Someone calls a help desk only when the person is unable to access a computer or service and was able to do that before. 2) If the user access to the host computer had been restricted then the help desk would have informed the user that the user has been restricted to access that computer. But instead the help desk is trying to help out the user. Mind it the help desk is belonging to the same subnet so it better knows which users has what access. 3) you point is correct that ICMP packets can be dropped based on the IP address. But you know very well that IP address verification is done in the third layer of the network that is the network layer. The devices that works in the network layer are routers, L3 switches and the computer configured with firewalls,NATing and routing. But my dear frnd the computers are belonging to a subnet. Here it is no point in doing such IP verifications. You can set logic to L2 swithches,rather, for the purpose. But in that case it is not IP, it is MAC address..nd my 1st point clearly indicates that the user is noway restricted by host computer..
answer is:- from the problem workstation, enter arp -a to refresh the ARP cache list. explaination:- the "arp" command supports the ARP service of the TCP/IP protocol suite. It enables an administration to view the ARP cache and add or delete cache entries. Any added entry becomes permanent until it is deleted or the machine is shut down. e.g:- Code: c:/>arp -a interface: 192.168.1.200 ---- 0X2 Internet address Physical Address Type 192.168.1.25 00-aa-00-62-c5-09 static 192.168.1.50 00-60-08-cd-34-54 dyanamic 192.168.1.51 00-60-08-cd-34-52 dyanamic Now, suppose the situation is such that the host might have been removed from the network for a few minutes and the arp cache list of the user has no MAC address info for the host computer. Then the user wud not be able to access the host. Such arp cache problem occurs most of the time while working in a network. In such situation the user needs to run the "arp -a" command to refresh the cache list untill he is getting the info about the destined host. (note:- reply me if anyone has any sort of confusion. I know the question is very tricky and only network experts are expected to ans) :nice:
