Using Tracert

Hello,

I used Tracert -d <ip Address> to see the route to the target address. After running Tracert, I noticed that the first IP address was 192.168.4.1. The first IP address is my router. There are about 10 entries (hops) listed after executing my tracert command. After the router, the hops are displayed and then the 10th entry is the IP address of the destination.

While looking at the list of hops, I noticed that the 9th entry has 192.168.1.82 listed as the IP address. Why would an IP address like this, a non-routable IP address, show up on the list of hops? It would make sense to me if the IP pattern was similar to the subnet pattern for my router but it is slightly different in the 3rd octet. Do you have an idea why this IP address would appear prior to my destination IP address, and especially if it looks like it is an internal non-routable IP address? Where would it come from?

Thanks.
LVL 1
jhiebAsked:
Who is Participating?
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.

Giovanni HewardCommented:
RFC1918 addresses (10/8, 172.16/12 and 192.168/16) should not appear in global routing tables, as they're designed to be used within "a single enterprise". However, it makes sense, to some extent, using RFC1918 addresses for your point-to-point links within your core, even if the traffic going across those links are for "globally routable" IP address ranges, as this conserves a slightly scarce resource.

The reason it shows up in the traceroute is that the TTL of an IP frame expired on an interface with 192.168.1.82 as its interface IP. The down-side of doing this is that it gets harder to ping the interface and do some troubleshooting on the issue, but there is no guarantee that you should be able to do that anyway.

So, I'd say that it may be a bit unusual, but it's certainly not unheard of.
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
jhiebAuthor Commented:
This kind of makes sense. I am not an expert at IP addresses and routing so I need the answer explained to me in more simpler terms. However, I also like your answer because it sounds right and I know I can rely on it.

It sounds like you are saying that the TTL of the packet issued by tracert was longer than usual and therefore it expired? Since it expired, tracert grabbed an IP address from the internal network somehow and then finally was able to get to the destination on the next hop? Is this what happened? Since the IP address in question is has a different range, I am not sure where it came from.
0
jhiebAuthor Commented:
x66_x72_x65_x65,

I have someone else looking at this too, and I am referred to the following link:
http://serverfault.com/questions/59516/traceroute-includes-un-routable-ip

It sounds like the problem might be similar to response #3. What is your impression that a router could be sending ICMP responses with a private IP that was bound to the management interface? Does this make sense to you?

Thanks.
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
TCP/IP

From novice to tech pro — start learning today.