«

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 www.procooling.com

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 www.procooling.com

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?

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



<> wrote in message
news: oups.com...
>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 www.procooling.com
>
> 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 www.procooling.com
>
> 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?
>

Are you using Windows XP ?

Do you have the firewall feature enabled ?

If so disable and retry traceroute

<> wrote:

Hi,

> 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.

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.11 99.655 ms 99.946 ms 99.883 ms
17 66.202.102.38 (66.202.102.3 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

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 Mason

wrote:
> 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 www.procooling.com
>
> 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 www.procooling.com
>
> 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?

Chris Mason <> wrote:

> 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

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.2 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

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:

http://www.microsoft.com/resources/d....mspx?mfr=true

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?

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?

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

Do an extended tracerotue form the router to www.procooling.com 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

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 : )