Running a Traceroute to my default gateway returns "request timed out"

I'm running a traceroute from my workstation to the ip address of my default gateway. On the first hop I get a * * * Request timed out and then on the second hop I get a response of 2ms. When I run the command from another machine in the same subnet I get on the first hop a response from the gateway.  Both machines have the firewall disabled and I don't see any difference in the way their ports are configured on the switch (Enterasys).
joshuasandersAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
Are you able to ping the gateway on both machines?
0
joshuasandersAuthor Commented:
yes, sorry, I didn't add that part.  I am able to ping them with no problems.
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
Then I would recommend a network capture (WireShark or alike) on the machine not getting replies, with ICMP and ARP filter.
0
The Five Tenets of the Most Secure Backup

Data loss can hit a business in any number of ways. In reality, companies should expect to lose data at some point. The challenge is having a plan to recover from such an event.

joshuasandersAuthor Commented:
It'll take me awhile to do that.  It's been awhile since I've used Wireshark.  I'll get back to you.
0
joshuasandersAuthor Commented:
alright, I think I did this right. How do you want the information?  I'm getting 3 destination unreachable (port unreachable) entries, then I get 9 ping request/reply entries and then 3 more destination unreachable entries. The unreachable entries all have the gateway as the source and the computer as the destination.
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
Port unreachable??? Just a second, have to compare ...
You should get a packet like this:
+ Frame ...+ Ethernet II ...+ Internet Protocol ...- Internet Control Message Protocol  Type 11 (Time-to-live exceeded)  Code 0 (Time to live exceeded in transit  ...
Are we talking about Windows or Linux client?
0
joshuasandersAuthor Commented:
yea, the port unreachable is under Internet Control Message Protocol.  This is a Windows Server tracerouting a Enterasys (very Cisco-like) switch.

Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 3 (Port unreachable)
Checksum: 0x1261 [correct]
    Internet Protocol, Src: 192.168..20.1 (192.168.20.1), Dst: 192.168.20.23 (192.168.20.23)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Time to live: 1






0
joshuasandersAuthor Commented:
Finally figured out how to export data from wireshark.  Here is the whole packet after running the trace from my server.  The last one I believe is when I ran the trace from the router.

b.txt
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
Interesting. The router is not sending the correct answer. What is the other machine's OS? Could you do a capture there, too, and compare if the router sends the same answer (it should)?

My guess is, assuming the router sends the same ICMP Dest. unreachable/Port unreachable, that the different (Windows) OS does interpet the reply different. TCP settings in registry might be different, too, in particular Black Hole detection, PMTU discovery and the like.
0
joshuasandersAuthor Commented:
All I'm pinging is the router.  There is no second machine involved.
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
I referred to "... When I run the command from another machine ...". The one where traceroute shows the expected behaviour.
0
joshuasandersAuthor Commented:
oh, gotcha, give me a second.
0
joshuasandersAuthor Commented:
that goes off without a hitch. 3 icmp requests all followed by corresponding replies.
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
And the replies are not the same as with the first machine?
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
(The exact ICMP reply is important - TTL exceeded, port unreachable, whatsoever).
0
joshuasandersAuthor Commented:
here is one of the replies from the router.
c.txt
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
Ah, I see. The first machine uses UDP port 137 (NetBIOS Name Service = WINS or NetBIOS name broadcast) to test, the second ICMP. The router has no WINS, and hence answers with ICMP "port unreachable".
0
joshuasandersAuthor Commented:
I'm just using windows tracert on both machines, why would it be different?
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
Are you using ftrace, or a UNIX-like traceroute, instead of tracert? Because I do not know of any option for tracert to let it try with UDP, it always uses ICMP.
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
There has to be a difference. Maybe the tracert has been replaced by another exe. Is it the same Windows OS on both machines?
0
joshuasandersAuthor Commented:
that's what I'm talking about!  I'm only using windows tracert.
0
joshuasandersAuthor Commented:
hmmmm, one of them is server 2003 (not working) and other is windows xp (working)
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
Double-checked with my W2003 Server. TraceRt still uses ICMP, as it should for Windows (see e.g. http://www.inetdaemon.com/tutorials/troubleshooting/tools/traceroute/definition.shtml). Look if the tracert is really the windows executable, and not replaced. You can do that e.g. in a DOS box with:
for %A in (traceroute.exe) do @echo %~$PATH:A
And then try to force-use  %windir%\system32\tracert.exe.
0
joshuasandersAuthor Commented:
same thing.
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
That is, the FOR is using %windir%\system32\tracert?
0
joshuasandersAuthor Commented:
yes
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
I have asked for advice of some W2003 specialists.

If you do not get a response in the next 24 hours, I recommend to request attention, so a Moderator will add W2003 to the zones and sent out a call for (more) Experts.
0
joshuasandersAuthor Commented:
ok, I'm going offline until tomorrow anyway, thanks for the help.
0
joshuasandersAuthor Commented:
quomodo? I've been told to delete my question and repost. If I do that all the troubleshooting that went into trying to resolve my question goes away. Can the question be bumped to the top of the queue or can I just close this question so I can still refer to it by link?
0
Steve KnightIT ConsultancyCommented:
Might be worth looking at the binding order and protocol orders, though have never checked how windows handles those with a tracert they can cause some bizarre issues sometimes:

I n network settings, advanced menu, advanced settings,

Check the order of connections and bump your lan connection to the top and check the bindings against the card in the box below.  Then in the provider order make sure the order includes MS windows at the top.
Steve
0
Steve KnightIT ConsultancyCommented:
Curious too, what does pathping report instead?  This UDP stuff is odd as I too wasnt aware thar tracert did / could use UDP on  Windows.... havent looked at the captures in detail but aside from some issue like I mentioned before could there be a difference in name resolution too, does it to any different if using -d? to not resolve names?

Steve
0
joshuasandersAuthor Commented:
dragon-it, I checked and "local connection #2" which is what I'm using was listed second so I bumped it up to the top stop and also elevated MS Windows network to the top. After a reboot, I get the same behavior. Also, no difference using the -d switch.  Same behavior.
pathping reports 0 the local computer and 1 as * * *
I'm going offline until tomorrow am PST.
0
Steve KnightIT ConsultancyCommented:
Fair enough, only a hunch. Intteresting one!
0
Keith AlabasterEnterprise ArchitectCommented:
please provide an ipconfig /all from both the pc and the server from which you want to run the tracert.
Also please provide the output from a route print from the same server and the workstation.

0
gemartiCommented:
Always start by looking at your physical network.....

In your first text file b.txt the source in 192.168.20.1  and the destination is 192.168.20.23. You get no response on the first hop.

In your second text file c.txt the source is 192.168.20.1 and the destination is 192.168.20.22. You are showing the second hop.

192.168.20.23 is your workstation; correct?
192.168.20.22 is some other workstation on the same subnet in a different location of the network; correct?


I'm curious about how your network is layed out; one reason I can think of for the *** response on the first hop is your workstation is encountering collisions; I'm not saying it is, I'm just saying this is a possibility. Are you familiar with your physical network? How many  "physical" devices are there between your workstation and the gateway router? In other words....Is your workstation connected directly to a switch or are there any devices (hubs) between the server and the switch? If there is a hub connected to your workstation between it and the switch are there any other devices connected to that hub?

Just trying to get an idea of how your network is layed out; the fact that your first hop comes up with a "request timed out" message and then your second hop returns a response indicates there isn't a connectivity issue but; to me it suggests some sort of congestion on the network; a lot of chatter, or collisions. If all of your hops returned "request timed out" then YES you do have a connectivity issue but this doesn't appear to be the case.




0
joshuasandersAuthor Commented:
keith, I'm putting that information together.

gemarti, Both hosts (.23 & .22) are plugged directly into the same layer 3 switch which is the gateway in question. The only difference that (.22) has is it's located in another room other than the data center and makes a couple of connections (layer1) to come back into the data center.  22 is however the machine that is working.
0
joshuasandersAuthor Commented:
Here is the information for you keith. The only difference I see is nodetype. I wonder why it's unknown.

C:\>ipconfig /all

Windows IP Configuration

        Host Name . . . . . . . . . . . . : srvaphone01
        Primary Dns Suffix  . . . . . . . : wm
        Node Type . . . . . . . . . . . . : Hybrid
        IP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No
        DNS Suffix Search List. . . . . . : wm

Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . :
        Description . . . . . . . . . . . : Broadcom NetXtreme Gigabit Ethernet
        Physical Address. . . . . . . . . : 00-1A-A0-26-0D-E6
        Dhcp Enabled. . . . . . . . . . . : No
        IP Address. . . . . . . . . . . . : 192.168.20.22
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.168.20.1
        DNS Servers . . . . . . . . . . . : 192.168.20.21
                                            192.168.120.20

C:\>route print
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 1a a0 26 0d e6 ...... Broadcom NetXtreme Gigabit Ethernet - Packet Sch
eduler Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0        192.168.20.1      192.168.20.22       10
        192.168.20.0    255.255.255.0       192.168.20.22      192.168.20.22       10
       192.168.20.22  255.255.255.255        127.0.0.1       127.0.0.1       10
   192.168.20.255  255.255.255.255       192.168.20.22      192.168.20.22       10
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
        224.0.0.0        240.0.0.0       192.168.20.22      192.168.20.22       10
  255.255.255.255  255.255.255.255       192.168.20.22      192.168.20.22       1
Default Gateway:         192.168.20.1
===========================================================================
Persistent Routes:
  None

C:\>


C:\>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : srvaphone02
   Primary Dns Suffix  . . . . . . . : wm
   Node Type . . . . . . . . . . . . : Unknown
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : wm

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Broadcom BCM5708C NetXtreme II GigE (NDIS
 VBD Client)
   Physical Address. . . . . . . . . : 00-24-E8-6C-4A-B6
   DHCP Enabled. . . . . . . . . . . : No
   IP Address. . . . . . . . . . . . : 192.168.20.23
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.20.1
   DNS Servers . . . . . . . . . . . : 192.168.20.21
                                       192.168.120.20

C:\>route print

IPv4 Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x10003 ...00 24 e8 6c 4a b6 ...... Broadcom BCM5708C NetXtreme II GigE (NDIS VB
D Client)
===========================================================================
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0        192.168.20.1       192.168.20.23     10
        192.168.20.0    255.255.255.0       192.168.20.23       192.168.20.23     10
       192.168.20.23  255.255.255.255        127.0.0.1        127.0.0.1     10
   192.168.20.255  255.255.255.255       192.168.20.23       192.168.20.23     10
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1      1
        224.0.0.0        240.0.0.0       192.168.20.23       192.168.20.23     10
  255.255.255.255  255.255.255.255       192.168.20.23       192.168.20.23      1
Default Gateway:         192.168.20.1
===========================================================================
Persistent Routes:
  None

C:\>
0
gemartiCommented:
The node type = unknown is the result of a incorrect registry entry.

Do the following:

REG QUERY HKLM\System\CurrentControlSet\Services\Netbt\Parameters\ /v EnableProxy

If EnableProxy <> 0 or 1 then try setting the value to 0 or 1 testing after each change (You may need to reboot the system for the change to take effect).

To make the change:

REG ADD HKLM\System\CurrentControlSet\Services\Netbt\Parameters\ /v EnableProxy /d 0
or
REG ADD HKLM\System\CurrentControlSet\Services\Netbt\Parameters\ /v EnableProxy /d 1

Test your TRACERT again to determine if this was the problem....I don't think it will make a difference.

Back to your original problem:

As I stated I don't think this is a connectivity issue (See article: http://www.wurd.com/misc_tracert.php) since the second hop gets a response from the router.
You may want to try the each of the following, one step at a time,  to resolve the delayed response from the router ( Only make one change at a time except for steps 1 and 2; in this case you want to make sure that the network speed is the same on the NIC and the Layer 3 device's port):

1. Verify NIC on .23 is set to Auto/1000/100/or 10 depending on your network's capabilities (auto should be fine)
2. Verify the Port on the Layer 3 device has the same port speed as the NIC on .23.
3. Upgrade Layer 3 device's firmware (if you can do so without disrupting your network users).
4. Reboot your Layer 3 device (If you can do so without disrupting your network users).


0
gemartiCommented:
The REG commands I mentoin above should be run from the command line....
0
joshuasandersAuthor Commented:
Gemarti,
yea, I already found the MS article on the subject and the reg key wasn't even there. I put it in myself with both values but it didn't change anything. I didn't think it would be an issue either, just thought I'd mention the difference.
verified that auto is setup for the triple speed port. The firmware and reboots will have to take place later. the switch is our core switch at the center of the network.

0
gemartiCommented:
The article I posted was a discussion on tracert. What article are you talking about?
0
joshuasandersAuthor Commented:
on the unknown node type, nevermind, bad tangent on my part.
0
greg wardSystems EngineerCommented:
a quick shot in the dark!
Are you using UDP instead of ICMP because ICMP is already in use
Is there another program which could be using this?
 
Greg
0
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
It would be worth a try to use a different traceroute utility, like ftrace (http://www.r1ch.net/stuff/ftrace/), to try if that one uses ICMP ...
0
joshuasandersAuthor Commented:
deepdraw - well, I'm seeing these symptoms on a lot of machines so if I'm running that phantom ICMP program, then I'm running it everywhere.
Qlemo - I'll download that and try it.
0
joshuasandersAuthor Commented:
Qlemo - I get the same behavior with ftrace. The first hop times out and then everything else comes out golden. The same thing happens if I use a -u for udp.
-J
0
ChiefITCommented:
This is just a thought:

With the Hybrid node type, the first thing it's going to look for is a WINS server. Then it will resort to a netbios broadcast.

Ping, like all other ICMP echo reply utilities can be used in different ways. It can be used with netbios name, IP address, and fully qualified domain (FQDN).

Since there is no wins server a node with the node type of H will time out on the first hop.

Now, if you perform a tracert to a www address, your first hop should be the DNS server redirecting you to the router/gateway ip address because the DNS server is not authoritative for that www address.

So, the ***** you see, means there is NO WINS server to redirect you because the WINS server doesn't have that particular node.

If you changed your node type to mixed mode, it will review all broadcast before looking for a WINS server, (when nothing is there, you will be redirected to the router).
0
joshuasandersAuthor Commented:
   Except for the fact that I'm not even pinging hostnames at this point, but IP addresses, I would normally agree with you. However, just for grins, I ran a tracert to www.google.com and got the same behavior.
    The first hop that get's the **** is my core switch, so I ssh'ed into the unit and ran a trace from it and received the same behavior. I beginning to think the problem lies there and not with my client OSes.
-J
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
I have to agree to that conclusion. Though I don't know why.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Networking Protocols

From novice to tech pro — start learning today.