traceroute not complete

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-12-2011 04:18 PM - edited 03-07-2019 02:46 AM
Hi
i have some wierd problem in my network.
from a desktop/workstation/laptop i am able to traceroute to external IP addresses.the tracroute is complete. this desktop is directly connected to a layer switch . when i login to the layer 3 switch and try a traceroute any external IP address the trace is in complete. i am able to ping external IP address from the switch sucessfully but traceroute is incomplete for some reason. can any one give me some suggestion
thanks
Karthik
- Labels:
-
Other Switching
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-12-2011 06:46 PM
Hello,
SO I understand it in a following way:
- ping from host to eternal ip working
- trace from host to ext-ip working
- ping/trace is going thrugh L3 switch
Next from L3 switch in turn
- ping to ext-ip - working
- trace - not working
So as trace is doing actual ping just increaseing TTL one by one to reach each hop in turn. This means that we are reaching some node and the ping to the node from switch ip address is blocked. At the same time - passing by packets (ping from switch and host) are handled in HW - so no problem. The reason why trace from host work on that node - possibly host ip is not blocked there - or choosing other way. There is a chance that you do trace from switch by default from different ip subnet (from host).
So I would check this:
- try to do ping/trace from switch using same subnet where host is in
- Check the device where trace stopped for any ACL or CoPP blocking the switch ip
Nik,
Niko
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-13-2011 10:01 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-13-2011 10:09 AM
Hi
Below is complete traceroute details from the host
U:\>tracert jupitergrades.com
Tracing route to jupitergrades.com
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 172.16.0.1
2 9 ms 1 ms 1 ms c-26.oe450.dc0.bhgov.net
3 4 ms 1 ms 1 ms 12.118.130.29
4 36 ms 35 ms 35 ms cr84.la2ca.ip.att.net
5 36 ms 38 ms 36 ms cr2.la2ca.ip.att.net
6 38 ms 37 ms 35 ms cr2.dlstx.ip.att.net
7 36 ms 34 ms 35 ms gar6.dlstx.ip.att.net
8 36 ms 35 ms 34 ms 12.90.228.14
9 35 ms 34 ms 37 ms border2.ge2-1-bbnet2.ext1a.dal.pnap.net [216.52.
191.85]
10 39 ms 36 ms 36 ms rackmanaged-3.border2.ext1a.dal.pnap.net [63.251
.32.50]
11 63 ms 36 ms 40 ms vlan901.core1.dfw1.rackspace.com
12 40 ms 36 ms 39 ms aggr128a.dfw1.rackspace.net
13 38 ms 36 ms 37 ms jupitered.com
Trace complete.
Below is the trace route details from my layer 3 switch where this host is connected to and trace is for the same IP address
CORE-DO-C6509E-1#traceroute 67.192.47.227
Type escape sequence to abort.
Tracing the route to 67.192.47.227
1 12.164.240.129 4 msec 0 msec 40 msec
2 12.118.130.29 8 msec 4 msec 8 msec
3 12.122.129.50 40 msec 36 msec 36 msec
4 12.123.30.250 40 msec 36 msec 40 msec
5 12.122.28.177 40 msec 40 msec 40 msec
6 12.122.100.65 40 msec 36 msec 40 msec
7 12.90.228.14 40 msec 36 msec 36 msec
8 216.52.191.25 40 msec
216.52.191.85 40 msec
216.52.191.25 40 msec
9 63.251.32.50 40 msec 40 msec 40 msec
10 72.3.128.21 40 msec 44 msec 40 msec
11 72.3.129.157 40 msec 40 msec 40 msec
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-13-2011 10:41 AM
Hi,
Cisco devices are doing UDP traceroute vs windows hosts which do ICMP traceroute so if the host you are tracerouting to is filtering those UDP packets you'll get the result you have.Usually it's the other way, as hosts filter ICMP but not UDP.Just try a traceroute from a Linux/Unix host(which do UDP traceroute too) and if it fails again then you'll know this was the reason.
Regards.
Alain.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-13-2011 01:54 PM
You are right I logged in to Cisco ASA firewall and I use the command traceroute x.x.x.x use-icmp and the traceroute was complete. In the switch I don’t have any option to use icmp
DistASA5520# traceroute 67.192.47.227 numeric
Type escape sequence to abort.
Tracing the route to 67.192.47.227
1 12.164.240.129 0 msec 10 msec 0 msec
2 12.118.130.29 0 msec 0 msec 0 msec
3 12.122.129.50 40 msec 30 msec 40 msec
4 12.123.30.250 30 msec 40 msec 30 msec
5 12.122.28.177 40 msec 30 msec *
6 12.122.100.65 30 msec 30 msec 40 msec
7 12.90.228.14 30 msec 40 msec 30 msec
8 216.52.191.85 40 msec
216.52.191.25 30 msec 40 msec
9 63.251.32.50 30 msec 40 msec 40 msec
10 72.3.128.21 30 msec 40 msec 30 msec
11 72.3.129.157 40 msec 40 msec 30 msec
12 * * *
13 * * *
14 * *
DistASA5520# traceroute 67.192.47.227 use-icmp
Type escape sequence to abort.
Tracing the route to 67.192.47.227
1 c-26.oe450.dc0.bhgov.net (12.164.240.129) 0 msec 0 msec 10 msec
2 12.118.130.29 0 msec * 0 msec
3 cr84.la2ca.ip.att.net (12.122.129.50) 60 msec 30 msec 40 msec
4 cr2.la2ca.ip.att.net (12.123.30.250) 30 msec 40 msec 30 msec
5 cr2.dlstx.ip.att.net (12.122.28.177) 40 msec 30 msec 40 msec
6 gar6.dlstx.ip.att.net (12.122.100.65) 30 msec 40 msec 30 msec
7 12.90.228.14 40 msec 30 msec 40 msec
8 border2.ge2-1-bbnet2.ext1a.dal.pnap.net (216.52.191.85) 30 msec 40 msec 30 msec
9 rackmanaged-3.border2.ext1a.dal.pnap.net (63.251.32.50) 40 msec 30 msec 40 msec
10 vlan901.core1.dfw1.rackspace.com (72.3.128.21) 30 msec 40 msec 40 msec
11 aggr128a.dfw1.rackspace.net (72.3.129.157) 30 msec 40 msec 30 msec
12 jupitered.com (67.192.47.227) 40 msec 30 msec *
DistASA5520#
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-13-2011 11:28 AM
Try doing an extended traceroute from your router and change the "numeric display" default option. Will prevent router from trying to resolve domain-name for devices. See if this changes your results.
CISCO#traceroute
Protocol [ip]:
Target IP address: 67.192.47.227
Source address: 12.164.240.129
Numeric display [n]: y
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Another option is to change the Port Number that traceroute uses by default.
Jonathan,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-13-2011 07:18 PM
But first try to understand one thing. These all said above we can see that particular traffic (source ip, dest ip, source port, dest port, protocol) is blocked on the router of final destination.
See the working trace:
12 40 ms 36 ms 39 ms aggr128a.dfw1.rackspace.net 72.3.129.157
13 38 ms 36 ms 37 ms jupitered.com 67.192.47.227
This is the non-working one:
11 72.3.129.157 40 msec 40 msec 30 msec
12 * * *
So it stops one hop before destination. That means that actual traceroute packet is sent to final hop (the TTL field just increased to reach it). But final hop not answering back. The fact that ICMP traceroute works says that final router knows the route back - it is not a problem. So it blocking the previous trace by protocol/port. So you can check the ACL on the interface with that ip (or any other incoming int) on the router of final destination to see any blocking string.
Nik
Niko
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-13-2018 06:26 AM
Even if ICPM can be inspected and you can ping to the internet but when you do a trace to the same IP as you ping the firewall will block the returning traffic, I had the same problem until I allow icmp from any to the internal IPs as traffic hit the outside interface then everything worked.
