traceroute timeouts

I have a strange problem. First off, I'm a cisco ios newbie. We have a

2610 that we use as our router with an integrated CSU/DSU. The setup we have now works fine. We can get out to the internet and receive packets no problem. However, running a traceroute from any system timeout on the serial side. We can ping everything directly no problem, just not a traceroute. Here's the config:

Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Router ! enable secret 5 xxxxxxxxxxxxxxxxxxxxxxxxxxxxx ! ip subnet-zero ip name-server 64.65.226.6 ip name-server 64.65.208.6 ! ! ! interface Ethernet0/0 ip address 216.153.219.65 255.255.255.224 no ip directed-broadcast no ip mroute-cache ! interface Serial0/0 no ip address no ip directed-broadcast encapsulation frame-relay IETF no fair-queue frame-relay lmi-type ansi ! interface Serial0/0.1 point-to-point ip address 216.153.152.230 255.255.255.252 no ip directed-broadcast frame-relay interface-dlci 951 ! ip classless ip route 0.0.0.0 0.0.0.0 216.153.152.229 ! access-list 1 permit 216.153.219.66 ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 access-class 1 in exec-timeout 5 0 password xxxxxxxxxxxxxxxxx login ! no scheduler allocate end

This is what a tracert looks like from my systems:

C:\\Program Files\\Support Tools>tracert

formatting link

Tracing route to procooling.com [67.15.116.111] over a maximum of 30 hops:

1 1 ms 1 ms 1 ms gateway.bellingham.image-src.com [172.16.10.1] 2 2 ms 2 ms 3 ms router.image-src.com [216.153.219.65] 3 8 ms * 8 ms host-216-153-152-229.spr.choiceone.net [216.153.152.229] 4 * * * Request timed out. 5 * * * Request timed out. 6 * * * Request timed out.

However, I can ping the server directly:

C:\\Documents and Settings\\Jeff>ping

formatting link

Pinging procooling.com [67.15.116.111] with 32 bytes of data:

Reply from 67.15.116.111: bytes=32 time=59ms TTL=45 Reply from 67.15.116.111: bytes=32 time=60ms TTL=45 Reply from 67.15.116.111: bytes=32 time=60ms TTL=45 Reply from 67.15.116.111: bytes=32 time=61ms TTL=45

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

Also, I can ping 216.153.152.229 and 216.153.152.230 directly without any errors. Any ideas?

Reply to
jefe.graves
Loading thread data ...

Jeff,

But from your tracert output I can see that last router responded is

216.153.152.229 which is next hop after your router. So, It's likely that problem lays on another side. Try to talk with admin of .229 box about tracert failure...

B.R. Igor

Reply to
Igor Mamuzic

Are you using Windows XP ?

Do you have the firewall feature enabled ?

If so disable and retry traceroute

Reply to
Merv

Hi,

I think the router .229 in your network is blocking this. If I do a traceroute to your ethernet ip address it blocks on the .229/.230 router:

5 ge4-0-0-121.gw8.ams6.alter.net (193.67.246.253) 3.368 ms 3.226 ms 3.108 ms 6 427.at-2-0-0.XR2.AMS6.ALTER.NET (212.136.177.57) 3.617 ms 3.632 ms 5.478 ms 7 so-1-1-0.TR1.AMS2.ALTER.NET (146.188.8.86) 5.021 ms 3.499 ms 3.337 ms 8 so-4-0-0.IR1.DCA4.ALTER.NET (146.188.5.197) 85.238 ms 85.320 ms 85.630 ms 9 0.so-0-0-0.IL1.DCA6.ALTER.NET (146.188.13.33) 87.701 ms 85.420 ms 85.644 ms 10 0.so-6-0-0.XL1.IAD8.ALTER.NET (152.63.38.129) 88.278 ms 88.413 ms 88.144 ms 11 POS6-0.GW4.IAD8.ALTER.NET (152.63.41.29) 87.534 ms 87.784 ms 87.400 ms 12 wcgGigE-gw2.customer.alter.net (157.130.30.246) 88.147 ms 87.938 ms 88.143 ms 13 hrndva1wcx2-pos6-0.wcg.net (64.200.240.193) 88.656 ms 88.414 ms 88.893 ms 14 nycmny2wcx2-pos1-0-oc192.wcg.net (64.200.210.177) 95.528 ms 95.483 ms 95.515 ms 15 spfdma1wce1-pos3-0.wcg.net (65.77.95.102) 101.517 ms 99.297 ms 102.762 ms 16 spfdma1wce1-choice1-pos.wcg.net (65.77.95.118) 99.655 ms 99.946 ms 99.883 ms 17 66.202.102.38 (66.202.102.38) 99.674 ms 99.715 ms 99.513 ms 18 host-216-153-152-230.spr.choiceone.net (216.153.152.230) 105.517 ms * 105.759 ms
Reply to
Hans

Jeff,

Had I seen this some months ago, I would immediately suspect that the nodes that were not responding to traceroute were either

a. blocking UDP packets with whatever unlikely port number traceroute is using b. not responding with ICMP "time exceeded"

and, given that all beyond a certain point fail, it was more likely to be a.

However I have learned that traceroute now comes in various forms - mainly to try to dodge firewalls - and I don't know what type of traceroute you might be using. For example, one can also specify a ping option called "route recording" which can provide results similar to traceroute but which requires support in each intermediate router for that router to report it's position on the route.

Assuming you are using a traditional form of traceroute, you should know that you might be able to ping a router - or destination node - without getting a response from traceroute. The reason is that all nodes can be expected to support ping - unless configured deliberately to block ping - whereas traditional traceroute, which uses UDP outbound with increasing TTL values, relies upon each intermediate router bothering to respond to an UDP packet where the TTL value has decremented to 0. It may be that the router implementation never did bother or, again, it may have been configured deliberately to block responding to an UDP packet where the TTL value has decremented to 0

Chris Mas> I have a strange problem. First off, I'm a cisco ios newbie. We have a

Reply to
Chris Mason

Good point ! When I use traceroute -I it works... The -I forces traceroute to use ICMP:

8 ge-5-1-0.mpr3.ams1.nl.above.net (195.69.144.122) 38.154 ms 3.318 ms 3.202 ms 9 64.125.27.222.available.above.net (64.125.27.222) 23.330 ms 17.304 ms 17.191 ms 10 so-7-0-0.cr2.dca2.us.above.net (64.125.27.165) 89.515 ms 90.017 ms 88.922 ms 11 so-5-0-0.cr2.dfw2.us.above.net (64.125.29.145) 117.293 ms 117.447 ms 117.252 ms 12 so-5-1-0.mpr2.iah1.us.above.net (64.125.29.33) 118.056 ms 117.908 ms 118.140 ms 13 so-0-0-0.mpr1.iah1.us.above.net (64.125.31.61) 117.246 ms 117.141 ms 117.116 ms 14 t289.216-200-251-166.iah1.us.above.net (216.200.251.166) 118.757 ms 118.595 ms 118.505 ms 15 gphou-66-98-241-28.ev1.net (66.98.241.28) 118.751 ms 118.709 ms 118.747 ms 16 gphou-66-98-241-125.ev1.net (66.98.241.125) 118.618 ms 118.365 ms 120.869 ms 17 ev1s-67-15-116-17.ev1servers.net (67.15.116.17) 118.385 ms 118.973 ms 118.930 ms 18 ev1s-67-15-116-111.ev1servers.net (67.15.116.111) 118.941 ms 118.626 ms 119.006 ms
Reply to
Hans

Well, that's the problem. The 229 is us I think. I believe that's the IP of the serial side of our router and that 230 is the serial side of our ISP's router. This is an XP box I'm using to run the tracert but the firewall is disabled since we're behind a gateway. I'm using the standard tracert command in XP. I was always under the assumption that tracert uses ICMP. And accoding to the MS website:

formatting link
Tracert Determines the path taken to a destination by sending Internet Control Message Protocol (ICMP) Echo Request messages to the destination with incrementally increasing Time to Live (TTL) field values.

Regardless of what protocol, from your side, it looks like 229 isn't responding, and from our side it looks like 230 isn't responding. Is there anything in my config that looks like it is blocking UDP or ICMP?

Reply to
jefe.graves

I just noticed this:

C:\\Program Files\\Support Tools>ping 216.153.152.229

Pinging 216.153.152.229 with 32 bytes of data:

Reply from 216.153.152.229: bytes=32 time=7ms TTL=62 Reply from 216.153.152.229: bytes=32 time=6ms TTL=62 Reply from 216.153.152.229: bytes=32 time=6ms TTL=62 Reply from 216.153.152.229: bytes=32 time=6ms TTL=62

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

C:\\Program Files\\Support Tools>ping 216.153.152.230

Pinging 216.153.152.230 with 32 bytes of data:

Reply from 216.153.152.230: bytes=32 time=2ms TTL=254 Reply from 216.153.152.230: bytes=32 time=1ms TTL=254 Reply from 216.153.152.230: bytes=32 time=1ms TTL=254 Reply from 216.153.152.230: bytes=32 time=1ms TTL=254

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

Does the TTL of 62 and the TTL of 254 matter?

Reply to
jefe.graves

WINDOWS XP use ICMP for traceroute (some other OSes use UDP).

Do an extended tracerotue form the router to

formatting link
with the source IP address of 216.153.219.65 and post the results

To use extended traceroute just enter the command traceroute at the enable prompt and then respond to the prompts

Reply to
Merv

Different OS's use a different TTL in the echo response - looks like

256 and 64 in this case. It used o be a very simply way to determine a linux box over windows with just ICMP : )
Reply to
jay

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.