Network troubleshooting almost always begins with ping. Ping tells you if the path is there; in other words, whether packets can travel from the local system to a remote node. The traceroute and tracepath utilities tell you what the path is—how the packets are getting from here to there.
The traceroute command has been around for a very long time, and it's a powerful tool. However, the tracepath utility receives a lot of attention. How are they different?
Most documentation simply states that tracepath does not require root privileges to run, and traceroute does (or some traceroute options require root). But what's the real difference, why might root be needed, and which tool should you select?
What is traceroute?
The power of the traceroute command lies in its flexibility and ability to initiate custom network tests using various protocols. In fact, traceroute can directly manipulate network packets—and there's the problem. Doing so requires root privileges because malformed or malicious packets are a danger to the network.
The traceroute command can also send Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Control Message Protocol (ICMP) packets. In theory, ICMP packets could be part of a DDoS attack and are therefore restricted. It can also pass IPv4 or IPv6 packets.
These features make traceroute more robust than tracepath, but at the cost of sometimes requiring root authentication.
Other traceroute features rely on the sockets API, which does not need root privileges. In other words, standard users may be able to use the traceroute command, but if they try anything too complex, they'll be challenged for credentials.
[ Free cheat sheet: Get a list of Linux utilities and commands for managing servers and networks. ]
traceroute's syntax is straightforward; just issue the command and point it to an IP address or name (assuming name resolution is in place):
$ traceroute 192.168.1.101
However, more advanced features require the use of sudo:
$ sudo traceroute [-OPTIONS] 192.168.1.101
How to interpret traceroute's output
The first column in traceroute's output is the hop number (hops refer to the router). If it takes five hops to get to the destination, there will be five lines in the output. The second column is the resolved name or IP address of the router traceroute is passing through. The final group of three columns are round-trip times (RTT) from the host to the router, and they're tested three times.
What is tracepath?
The tracepath tool lacks the more advanced features of its fellow application. More specifically, its features rely only on the sockets API, use UDP, and cannot manipulate packets. It does not require root privileges and is a great option for gathering basic network information. In most troubleshooting scenarios, tracepath should provide plenty of capability. Like traceroute, tracepath relies on the -6 option to send IPv6 packets exclusively.
The tracepath syntax is simple. For a basic trace to server01 on a remote segment, type:
$ tracepath server01
There are a few interesting tracepath options. To set a specific initial destination port, type:
$ tracepath -p 8080 server01
Or to define the maximum number of hops, run:
$ tracepath -m 42 server01
Finally, to disable name resolution for the hosts along the path, enter:
$ tracepath -n server01
How to interpret tracepath's output
The first column is the hop number. The second column displays the router's resolved name or IP address. The final column shows the RTT (only once, whereas traceroute tested with three packets). The output also displays Message Transfer Unit (MTU) size.
Wrap up
I've found that most uses of network tracing are pretty straightforward and don't require the advanced features that traceroute offers. Therefore, tracepath is probably good enough for most instances.
It's nice to be able to send a network troubleshooter to a workstation to check network connectivity without granting root privileges. I suggest getting in the habit of using tracepath most of the time and showing your fellow Linux users and basic network techs its simplicity.
저자 소개
Damon Garn owns Cogspinner Coaction, LLC, a technical writing, editing, and IT project company based in Colorado Springs, CO. Damon authored many CompTIA Official Instructor and Student Guides (Linux+, Cloud+, Cloud Essentials+, Server+) and developed a broad library of interactive, scored labs. He regularly contributes to Enable Sysadmin, SearchNetworking, and CompTIA article repositories. Damon has 20 years of experience as a technical trainer covering Linux, Windows Server, and security content. He is a former sysadmin for US Figure Skating. He lives in Colorado Springs with his family and is a writer, musician, and amateur genealogist.
유사한 검색 결과
Bridging the gap: Red Hat Academy shaping open source talent in APAC
From banking to tech: Bradley's Red Hat journey
Should Managers Code? | Compiler
The Web Developer And The Presence | Compiler: Re:Role
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
가상화
온프레미스와 클라우드 환경에서 워크로드를 유연하게 운영하기 위한 엔터프라이즈 가상화의 미래