UNIX for Dummies Questions & Answers

i know this is used in tracking down network problems. the problem is how is it helpful?? what should I look for when using traceroute?? i have looked on the internet but the information given isn't quite helpful as it as the same as the one in the man page.

the question here is, i have a network problem i chose to use the traceroute command, what do I do with the command? using the traceroute command, how do i identify which gateway is discarding my packets or causeing the network performance problems???

A quick google search turned up a number of useful-looking links, including this one: Using Traceroute.

remember i think the hop limit is 30. then your packet is dead in the water.

well lets think about it logical.

you have a network problem.... (is it slow? is it spikey? is it working?)

1) ping the end machine (how long does it take? does it reach the destination?)
2) traceroute (see any thing takeing a bit longer then the rest of the results?)
3) netstat (you can use it to do a bunch of stuff like see how much traffic is flowing)


there are various performance tuneing articles out there. try google groups and see if you can pick up a hint or something to search into. remember netwrok issue happen to all os's so dont limit yourslef to a group for your OS.

traceroute is a nifty utility that sends out a UDP packet to a remote IP address with a time-to-live (TTL) of 1 (or zero, forgot which, but off the top of my head 'think' it is one). When the packet is received at the next hop the TTL is decremented by one and an ICMP error (destination unreachable, as I recall) is generated and returned to the source and the round-trip-time is recorded.

Then, the TTL is incremented by one and the UDP packet will go one more hop before the ICMP error is generated and the error returned to the source. This process is repeated again and again until the packet reaches its final destination.

Many people find this little utility one of the most important tools in a network admin's toolbox. I use it everytime there is a problem on the network.

So, to answer what I thought your question was, traceroute is very useful and the more you use it, the more you will understand how valuable of a tool it is. Just like any tool, the more experienced the user, the more useful the tool.

For example, a hammer in the hands of a very skilled carpenter is a better tool than in the hands of a novice carpenter. The same holds true for networking tools.

Neo

my original question was partially answer by Optimus_P. What I wanted to know is how do I make use of the traceroute command?? Yes, I do know traceroute is quite useful but how do I put its usefulness to work?? just like vmstat. if you want to know whats goin on with the memory, you look at the po and free colums to make sure things aren't out of the ordinary. Same thing with traceroute but what I dont know is that exact thing I'm supposed to be checking for using the traceroute command.

Optimus_P or anyone else with deeper knowledge and experience on this, please, reply. I really dont want to go through the crazy task of scrolling thru unwanted info provided by the links mentioned.

By the way, NEO, I really dont understand why traceroute can be of so much usefulness like you say when it sends out UDP packets. Isn't UDP packets supposed to be unreliable or something? (I may be wrong but I read somewhere it is unreliable, thats why TCP is preferred)

I use traceroute mainly to see where the link is broken or where the delay is.

For example, if you can't ping a system, use traceroute and it will show you the last node in the network it can get to. This may not be helpful if you don't know the network inbetween point A and point B, but if you do you can tell exactly where the problem is. If you don't know the topology, at least you can tell if the problem is on your end or theirs.

If you have strange network delays, traceroute will show you the time to get from one point to the next along the route. You can then track down the machine with the problem and correct the issue, or if you don't own the machine you can change your route to avoid it, contact the owner, or just wait until it gets fixed (which may never happen).

Truest,

You are confusing connectionless protocols with connection-oriented protocols. You are also confusing a protocol used in a network troubleshooting utility with end-to-end transmission control requirements for the Internet protocol.

Careful You could get way over your head and ahead of the required background knowledge in networking to tackle these complex subjects.

As I stated before, the use of network utilities, and their usefulness, is based upon the mastry of the user. My advise would be to focus on understanding TCP/IP first. That subject alone can take months or years to master.