traceroute has * in some but not all output 2

[jimfixit]

Okay back to Kindergarten with me...

I was noticing recently in a lab I'm building that when I traceroute from my core switch to a switch across a frame relay, I get the following:

3 10.20.1.2 0 msec * 0 msec

on the last line of the output. The three hops leading to that last line are all fine (as in 0 msec 8 or 9 msec and so on).

I know the "*" is supposed to mean one of two things: timed out or in DOS land, it can mean the device at that point in the loop won't respond to the ICMP for security reasons but does pass the traffic on.

So I figure I got something wrong with my routes but they look okay. Finally I tracerouted to the IP address on the unit itself (as in my switche's IP address is 10.10.1.1 so I pinged from it to 10.10.1.1, even using the extended command in order to force the tracert to source from 10.10.1.1. So, I tracing from an IP to the same IP address and I still get that "*" in the output....

What's up with that?

 

[jimfixit]

well I may be answering part of my own question...

debug ip icmp gives me more details on what is happening...

it says "icmp: dst (x.x.x.x) port unreachable rcv from x.x.x.x


How can a port be unreachable 1 or 2 out of three pings...it can't be an access list denying ICMP because that would deny all the packets....

This is weird.

 

[Minue]

Hello
I think this is the way the traceroute works.Don't remember the exact theory from my CCNA days.It goes like this,to get the router to reply ,packets with a funny time-to-live is sent.
The "port unreachable" could be the reply to dead packet.Will try to read up on this and let you know.
Regards

 

[burtsbees]

Could be a flapping interface...post a "sh int" from the interface of the router that gives you the *

Burt

 

[jimfixit]

Don't think that's it. Posting show int below anyway.

problem is I will get the '*' in the traceroute output even though I'm pinging from the device that the interface is on. Not going across the net at all and will still get at least one '*' in the traceroute output. I don't see that if I tracert the same address from a workstation, only if I do it from a switch/router. Pings don't drop, so I'm inclined to think it's something unique to the way Cisco handles traceroute TTL's, line Minue said earlier...

Vlan1 is up, line protocol is up
Hardware is EtherSVI, address is 0005.74e2.acc0 (bia 0005.74e2.acc0)
Description: Connection to existing VLAN1
Internet address is 10.1.1.1/16
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 2/255, rxload 35/255
Encapsulation ARPA, loopback not set
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 26w0d
Input queue: 0/750/224647/64482 (size/max/drops/flushes); Total output drops:
0
Queueing strategy: fifo
Output queue: 0/500 (size/max)
5 minute input rate 139720000 bits/sec, 22208 packets/sec
5 minute output rate 8186000 bits/sec, 3030 packets/sec
L2 Switched: ucast: 969694654445 pkt, 834460324405120 bytes - mcast: 970253885
pkt, 416817532632 bytes
L3 in Switched: ucast: 188123115660 pkt, 155440671597603 bytes - mcast: 0 pkt,
0 bytes mcast
L3 out Switched: ucast: 26391772790 pkt, 18732247709096 bytes mcast: 0 pkt, 0
bytes
188855525662 packets input, 155724523379596 bytes, 0 no buffer
Received 577226586 broadcasts (24068158 IP multicast)
0 runts, 0 giants, 1628 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
26592060471 packets output, 18761933267460 bytes, 0 underruns
0 output errors, 0 interface resets
0 output buffer failures, 0 output buffers swapped out

 

[Minue]

Hello
Here's a nice easy to read document from Cisco.Lot of interesting stuff on ICMP.
At the bottom of the page you will find details on Traceroute.

http://www.cisco.com/warp/public/63/ping_traceroute.html

Regards

 

[Jsteve]

This happens because the router rate limiting how many icmp unreachables it sends per milisec

this can be adjusted with the following global command,
"ip icmp rate-limit unreachable <msec>". I forgot what the default is but the lower the better. I do not recommend adjusting this in a production network, becasue it helps against smurf attacks.