8 Traceroute program
8.1 Introduction The TraceRoute program written by Van Jacobson is a tool that can explore the TCP / IP protocol. Although it is not guaranteed to have the same route from two consecutive IP datagrams from the source to the destination, most of the cases are like this. The Traceroute program allows us to see the route passed from one host to another host. The Traceroute program also allows us to use IP source routing options.
(Below is the original book P.971 translation) The manual says: "The program is proposed by Steve Deering, implemented by Van Jacobson, and many others according to C. Philip Wood, Tim Seaver and Ken ADELMAN et al. Advocacy suggestions or supplementary comments for debugging. "
8.2 TraceRoute program Operation in Section 7.3, we describe the IP Record Routing Options (RR). Why don't you use this option to develop a new application? There are three reasons. First, it is not that all routers support record routing options, so this option cannot be used on some paths. (Traceroute programs do not require intermediate routers with any special or optional features.) Second, recording routing is generally one-way options. The sender sets this option, then the receiving end has to extract all the information from the received IP header and then returns to the sender. In Section 7.3, we see that most PING server implementation (ICMP echo answering function in the kernel) returns the received RR list, but this makes the recorded IP address doubled (one time) This will be subject to some restrictions, which we discussed next to. (Traceroute programs only need to operate a UDP module - Others do not require any special server applications.) The last reason is the most important reason is that the space left to the option in the IP head is limited, and the current big Most paths. Only 9 IP addresses can only be stored in the IP header option field. This is enough in the original Arpanet, but it is not enough for it now. The Traceroute program uses the TTL field in ICMP packets and IP headers. The TTL field (survival cycle) is initially set by the sender to an 8 bit field. The recommended initial value is specified by allocating digital RFC, and the current value is 64. The older version of the system is often initialized to 15 or 32. In some PING program examples in Chapter 7, we can see that TTL is often set to the maximum value 255 when sending ICMP returns an answer. Each router that handles the datagram requires minimizing the value of the TTL 1 or subtract the number of seconds that the datagram stays in the router. Since most router forwarding datagrams are less than 1 second, TTL eventually becomes a counter, and each router has dropped by one.
(Below is the original book P.981) RFC 1009 [Braden and Postel 1987] pointed out that if the router forwarded the datagram, it will subtract the TTL value subtract the time (second number of seconds). But few routers are so real. New Router Demand Document RFC [Almquist 1993] Specifies it to this to select the selectable function, allowing TTL to see a jump station counter.
The purpose of the TTL field is to prevent datagrams from flowing in the network when routing. For example, when a router is paralyzed or connected between the two routers, the routing protocol sometimes detects the lost route and proceeds. During this time, the datagram may be terminated in the loop circuit. The TTL field is a datagram in these loops plus a survival limit. When the router receives an IP datagram, if its TTL field is 0 or 1, the router does not forward the datagram. (The destination host that receives this datagram can give it to the application because it does not need to forward the datagram. However, in general, the system should not receive a Data report for the TTL field 0.) Conversely, The router discards the datagram and gives a source of ICMP "timeout" information. The key to the Traceroute program is that the source address of the IP packet containing this ICMP information is the IP address of the router. We can now guess the operation of the Traceroute program. It sends a TTL field to 1 IP data report to the destination host. Processing the first router of this datagram minus the TTL value by 1, discard the datagram, and send back a timeout ICMP message. This gives the address of the first router in the path. The TraceRoute program is then sent a data report for a TTL value of 2 so that we can get the address of the second router. Continue this process until the datagram has arrived at the host. But even the IP datagram, which is a TTL value of 1, does not discard the datagram and generate a timeout ICMP packet, because the duplicate report has reached its final destination. So how do we judge that the host has arrived? The TraceRoute program sends a UDP data report to the destination host, but it selects an impossible value as a UDP port number (greater than 30,000), making any application of the destination host to use this port. Because, when the data is reported, the UDP module of the host will generate a "port is not available" error (see Section 6.5) ICMP packets. In this way, the TraceRoute program is to do is that the received ICMP information is timeout or the port is not arrived to determine when it ends. (The following is the original book P.991) The Traceroute program must set the TTL field for the transmitted datagram. Not all procedures with TCP / IP interface support this feature, not all implementations support this capability, but most systems support this feature and can run the TraceRoute program. This program interface typically requires users to have superuser privileges, which means that it may require special permissions to run the program on your host.
8.3 LAN Output We have now running the TraceRoute program and observes its output. We will use simple interconnects from SVR4 to SLIP, via router BSDI (see the inner cover). BSDI and SLIP are 9600 b / s SLIP links.
(See the original book P.99 2)
The first unburred number of outputs gives the destination hostname and its IP address, indicating that the maximum TTL field value of the Traceroute program is 30.40 bytes contains 20-byte IP headers, 8-bytes of UDP headers and 12 User data of bytes. (12-byte user data contains the serial number of each of the datagrams, which gives the TTL copy and the time to send the datagram.) The back of the output is started with TTL, and next is the host or router name, and it IP address. For each TTL value, three datots are sent. Each time ICMP packet is received, the round trip time is calculated and printed. If there is still no response from 3 datagrams in 5 seconds, you will print an asterisk and send the next datagram. In the above output, the ICMP packets of the top three datagrams of the TTL field are received at 20, 10 and 10 Ms, respectively. The ICMP packets of 3 datagrams for the TTL field 2 are received after 120 ms. Since the TTL field is 2 to reach the final destination host, the program stops. The round trip time is calculated by the TraceRoute program of the sending host. It refers to the total round trip from the Traceroute program to the router. If we are interested in each path, you can subtract the TTL field as N to N 1 with the TTL field. Figure 8.1 shows the run output of TCPDUMP. As we expected, the first round trip time sent to BSDI's probe data is 20 ms and the back two datagrams circops and trip times are 10 ms. The ARP exchange is happened. TCPDUMP results confirm that this is true. The destination host UDP port number starts to be set to 33435, and each time a data is sent 1. You can change the starting port number by command line option. The UDP datagram contains 12 bytes of user data, and we have described it in the 40-byte datagram output from the previous Traceroute program. The back TCPDUMP prints the annotation of the IP datag report for the TTL field 1 [TTL 1]. When the TTL value is 0 or 1, TCPDUMP prints out this information to prompt our datagram, some are not very unusual. Here we can foresee the TTL value of 1, and in other applications, it can warn our datagram may not be able to reach its final destination host. We cannot see a router to transmit a TTL value of 0, unless the router that is reported is already crashing. Figure 8.1 TCPDUMP output results from the TraceRoute program example of SVR4 to SLIP
Because the BSDI router minus the TTL value to 0, we expect it to send back "Transfer Timeout" ICMP packets. Even if this discarded IP packet is sent to SLIP, the router will also send back ICMP packets. There are two different ICMP "Timeout" packets (see Figure 6.3 of P.71), and the Code fields in their ICMP packets are different. Figure 8.2 shows the format of this ICMP error message.
Figure 8.2 ICMP Time:
The ICMP packets we have discussed are generated when the TTL value is equal to 0, and its Code field is 0. The host may take timeout when assembling fragmentation, at this time, it will send a "assembled message timeout" ICMP packet. (We will discuss fractional and assembly at Section 11.5.) This error message sets the Code field 1. Figure 9-14 of Figure 9-14 corresponds to 3 dataps of TTL 2. These three messages arrive at the final destination host and generate an ICMP port that cannot be reached. Calculating the round trip time of the SLIP link is meaningful, just like the PING example we play in Section 7.2, set the link value to 1200 b / s. Send an outward UDP datagna total 42 bytes, including 12-bytes of data, 8-byte UDP head, 20-byte IP headers, and (at least) 2 bytes of SLIP frame (Section 2.4). But in different pings, the returned data report size is changing. As can be seen from Figure 6.9, the returned ICMP packet contains an IP header of a datagram that occurs, and 8-byte data followed by the IP header (in the TraceRoute program, the UDP header). In this way, the total is 20 8 20 8 2, that is, 58 bytes. In the case where the data rate is 960 b / s, the estimated RTT is (42 58/960), ie 104 ms. This value is consistent with 110 ms estimated on SVR4. The source port number (42804) in Figure 8.1 looks great. The TraceRoute program sets the source port number of the UDP datagram to the UNIX process number and 32768. For situations where the TraceRoute program is run multiple times on the same host, each process checks the source port number returned by the ICMP and only processes those packets that send answers to themselves. There are some things that must be pointed out about the Traceroute program. First, it is not possible to ensure that the routing is also the route to be used in the future, or even two consecutive IP datagrams may adopt different routes. If the routing changes when running the program, you will observe this change because of a given TTL, if its routing changes, the Traceroute program will print out new IP addresses. Second, it cannot guarantee the path of the ICMP packet and the UDP datagram file sent by the TraceRoute program to use the same route. This indicates that the printed round trip time may not actually reflect the time difference of the datagram issued and returned. (If the UDP datagram is 1 second from the source to the router, and the ICMP message uses another routing to return the source for 3 seconds, the printed round trip time is 4 seconds.) Third, return ICMP The source IP address in the packet is the IP address of the router interface arrived by the UDP datagna. This is different from the IP Record Routing Option (Section 7.3), and the recorded IP address refers to the send interface address. Since each defined router has 2 or more interfaces, the results obtained from the A host to the B host and run the TraceRoute program from the B host to a host may be different. In fact, if we run the TraceRoute program from the SLIP host to SVR4, its output is turned: (see the original book P.101 1)
The IP address of this print-out BSDI host is 140.252.13.66, corresponding to the SLIP interface, and the last address is 140.252.13.35, which is an Ethernet interface address. Since the TraceRoute program also prints the host name related to the IP address, the host name may also change. (In our example, both interfaces on BSDI use the same name.) Consider the situation of Figure 8.3. It gives the case where two local area networks are connected by a router. The two routers are connected by a point-to-point link. If we run the Traceroute program on a host on the left LAN, it will find that the IP address of the router is IF1 and IF3. But in another case, it will find that the printed IP address is IF4 and IF2. IF2 and IF3 have the same network number, while the other two interfaces have different network numbers. Figure 8.3 Interface ID printed by the Traceroute program
Finally, in the case of a wide area network, if the output of the Traceroute program is a readable domain name, not the IP address form, it will be better understood. However, because the Traceroute program receives the ICMP packet, the unique information it gets is an IP address, so it is a "reverse domain name view" work to obtain a domain name when a given IP address is given. This requires the administrator of the router or host correctly configures its reverse domain name view function (not all cases). We will describe how to use DNS to convert an IP address into domain name.
8.4 WAN Output The output example of the small interconnection given above is sufficient for the viewing protocol running process, but for large interconnects like global interconnects, there is a more practical thing that applies Traceroute programs. Figure 8.4 is the case from the Sun host to the NIC (Network Information Center).
Figure 8.4 Traceroute program from Sun host to nic.ddn.mil
Since this example is running, NIC has been transferred from nic.ddn.mil from nic.ddn.mil, namely new "internic". Once the datagram leaves the Tuc. Noao.edu network, they have entered the Telcom.arizona.edu network. Then these datagrams enters NASA Science Internet, NSN.NASA.GOV. The TTL field is 6 and 7 routers located on JPL (Jet ProPulsion Laboratory). The TTL field is located on the Sura.NET network output on the Southeastern Universities Research Association Network. The TTL field is 12 domain name GSI is the operator of Government Systems, Inc., and NIC. The second RTT (590) of the TTL field is almost twice the other two RTT values (234 and 262). It indicates dynamic changes in IP routes. An event that slowed down quickly between sending a host and the router. Similarly, we can't distinguish between datagrams or returned ICMP error messages being intercepted. The first RTT probe value (204) of the TTL field is 3 is smaller than the first detection value (233) value of the TTL field 2. Since each printing RTT value is a total time from the transmitter to the router, this is likely to occur. Examples of Figure 8.5 are the operation example from the Sun host to the author publisher.
Figure 8.5 TraceRoute program from sun.tuc.noao.edu host to aw.com
In this example, there is a regional network WESTNET.NET (TTL field value 6 and 7) after the data is left to the Telcom.arizona.edu network. Then, the NSFNET main network operated by Advanced Network & Services, t3.ans.Net, (T3 is generally abbreviation for the 45 MB / S telephone line adopted by the main network.) The last network is alter.net, ie AW. COM with the connection point of the interconnection network. 8.5 IP Source Station Lift Options Usually IP routing is dynamic, that is, each router must determine which router should be forwarded below. The application does not control this, and it is often not concerned about routing. It uses tools similar to Traceroute programs to discover actual routing. The idea of Source Routing is the specified route by the sender. It can take the following two forms: · Strict source routing selection. The transmitting end specifies the exact route that the IP datagram must be employed. If a router discovers the next router specified by the source routing, it is not on the network directly connected, then it returns a "source routing failed" ICMP error message. Loose source selection. The sender specifies a list of IP addresses through a datagram, but the datagram can pass other routers between any two addresses specified on the list. The Traceroute program provides us with a way to view the source station selection, we can refer to the source station route in the option, and then check its operation.
(Translation of the original book P.1041) Some public TRACEROUTE Source Codes contains patches that indicate loose source selection. But this is usually not included in the standard version. The explanation of these patches is "the original Traceroute program (1988 spring) of Van Jacobson supports this feature, but he later removing this feature because some people will make the gateway to crash." For the examples given in this chapter, the author will put these patches Install and set them to allow loose source selection and rigorous source station selection.
Figure 8.6 shows the format of the source station routing option.
Figure 8.6 General Format of IP Source Station Routing Options
This format is basically consistent with the record routing option format shown in Figure 7.3. But the difference is that for the source selection, we must populate the IP address list before sending an IP datagram, and for the log routing option, we need to assign and empty some space for the IP address list, and let the router populate the list. All. At the same time, for the source station selection, we only assign space for the number of IP addresses required, and usually there is less than 9. For recording routing options, we must allocate space as much as possible to achieve 9 addresses. For loose source selection, the value of the Code field is 0x83, and the value is 0x89 for a strict source station. The Len and PTR fields are the same as we described in Section 7.3. The actual call of the source station route is "Source Station and Record Routing" (for loose source selection and strict source selection, using LSRR and SSRR), this is because in the route transmission process in the data report , Update the IP address list. The following is its running process: • Send a host from the application receiver routing list, remove the first item (it is the final destination address of the datagram), move the remaining items into one item (as shown in Figure 8.6) ), And the original destination address is the last item of the list. The pointer still points to the first item of the list (ie, the value of the pointer is 4). · The router for each processing datagram checks whether it is the end address of the datagram. If not, the datagram is forwarded normally. (In this case, you must specify the loose source station, otherwise we cannot receive the datagram.) • If the router is the ultimate goal, the pointer is not greater than the length of the path, then (1) is specified by the PTR The next address in the list is the final destination address of the datagram, and (2) replaces the source address that is just used by the ip address corresponding to the outgoing interface, then, (3) pointer plus 4. The above process can be explained well with the following example. In Figure 8.7, we assume that the sending application on the host S sends a data report to D, the specified source routing is R1, R2, and R3. Figure 8.7 IP source routing example
In the figure, # represents the pointer field, and its values are 4, 8, 12, and 16, respectively. Length field is 15 (three IP addresses plus three bytes headers). It can be seen that the destination address in each hip IP datagram changes. When an application receives data by the trusted route, when the answer is sent, the received routing value should be read and the reverse route is provided.
(Below is the original book P.1051) Host Requirements RFC indicates that the TCP customer must refer to the source station route selection, and the TCP server must be able to receive source routing selection, and all reports of the TCP connection can be Use reverse route. If the TCP server receives a different source routing, then the new source routing will replace the old source route.
The TraceRoute program example of loose source selection uses the -g option of the Traceroute program, we can specify some intermediate nodes for loose source selection. This option can specify up to 8 intermediate routing. (The number is 8 instead of 9 is that the programming interface used requires the last expression to be destination host.) In Figure 8.4, the route to NIC, NIC.DDN.MIL has passed Nasa Science Internet. In Figure 8.8, we enforce datagramia by specifying router ENSS142.UT.WESTNET.NET (192.31.39.21) as an intermediate router to pass NSFNET: Figure 8.8 Using loose source station to pass NSFNET to NIC.DDN.MIL TraceRoute program
In this case, it seems that there is a total of 16 hops in the path, and the average RTT is approximately 350 ms, while the usual routing of Figure 8.4 is only 13 hops, and the average RTT is approximately 322 ms. The default path looks better. (Some factors are required (some factors must be considered. Some factors must consider are organizational and political factors included in the network.) Before we said that there were 16 jumps, this is because of our output results with us According to an example of NSFNET (Fig. 8.5), it was found that 3 routers were selected in this case with a loose source route. (This may be because the router has some error on the source station selection data report to generate ICMP timeout error messages.) The Gateway.tuc.noao.du router between Netb and Butch routers is lost, at the same time, in Gabby and ENSS142 The two routers of the .utgate.telcom.arizona.edu and uu-ua.az.westNet.NET.Telcom.Az.westNet.Net. Problems related to the receiving loose source selection option datagram may occur on these lost routers. In fact, when using NSFNET, the path between the source and the NIC has 19 jumps. This chapter exercise 8.5 continues to discuss these lost routers. This example also points out another problem. In the command line, we must specify the dot decimal IP address of the router ENSS142.UT.WestNet.Net, and cannot be replaced by its domain name. This is because the reverse domain name analysis (return domain named through the IP address described in Section 14.5) is associated with the IP address, but the forward parsing (ie, returning an IP address to the domain name) will not be done. In DNS (Domain Name System, Domain Name System), forward mapping and reverse mapping are two separate files, rather than all managers have these two files. Therefore, in one direction, it is normal and the other direction failed. There is also a situation we have not encountered before, in the case where the TTL field is 8, for the first RTT, print an asterisk (*). This suggests that timeout, the answer signal is not received in this probe within 5 seconds. Compared with Figure 8.4, we can also conclude that routers NS-FIX-pe.sura.net is connected to NSFNET and NASA Science Internet.
Strict source station selection Traceroute examples In the author's Traceroute version, the -g parameter is exactly the same as the -g parameters described above, but it is a strict source station to select the path rather than a loose source station. Selection. We can use this parameter to observe what the result will be like when the strict source station is selected. From Figure 8.5, it can be seen that the normal router sequence from the data report from the author's subnet to NSFNET is Netb, Gateway, Butch, and Gabby. (For easy viewing, we will omit the domain name suffix .tuc.noao.edu and .telcom.arizona.edu.) We specify a strict source route to try to send datagrans from Gateway. To gabby, but omitted the BUTCH. We can guess that the result will be failed, as shown in Figure 8.9. Figure 8.9 TraceRoute programs that use strict source routing failure
The key here is that the TTL field is 3 output line, and the RTT is behind! This indicates that the Traceroute program has received an error message for ICMP "source routing": Type field in Figure 6.3 is 3, and the Code field is 5. The asterisk of the second RTT position of the TTL field is 3 indicates that the answer is not received. As we guess, Gateway is not possible to send data directly to Gabby because there is no direct connection between them. The results of the TTL fields are 2 and 3 come from Gateway, and the answer from the TTL field is 2 from Gateway because the Gateway receives a datagram that is 1 TTL field. Before it checks (invalid) strict source selection, it is found that TTL has expired, so send it back to ICMP Timechup. The TTL field is equal to 3, and its TTL field is 2 when entering GATEWAY, and therefore, it views a strict source selection, and it is invalid, so it is invalid, so it is sent back to the ICMP source station selection failure error message. Figure 8.10 shows the TCPDUMP output results corresponding to this example. The output is fear on the SLIP link between Sun and NetB. We must specify the -v option in tcpdump to display the source station routing information. In this way, some of our unwanted results like the datagonal ID will be output, and we delete these unwanted results in the results. Similarly, we use SSRR to express "strict source and recording routing".
Figure 8.10 Failure strict source station selection TraceRoute program TCPDUMP output results
First, it is noted that the destination address of each UDP datag report sent by Sun is Netb, not a destination host (Westgate). This can be explained by examples of Figure 8.7. Similarly, the other two routers specified by -g parameters (GATEWAY and GABBY), and the final destination becomes the SSRR option of the first hop. From this output result, we can also see that the timing time (time difference between the 15th and 16 lines) used by the TraceRoute program is 5 seconds.
Loose source selection TraceRoute program The round-trip route we have said before, from the path from A to B. It is not necessarily exactly the same as the path from b to a. It is difficult to find that the two paths are different unless they are logged in and running the TraceRoute program on each terminal. However, using loose source selection, we can determine the path in both directions. The trick here is to specify a loose source route, which is the same as the destination of the route, but the transmitting end is the destination host. For example, on the Sun host, we can find that the results from Bruno.cs.coloraDO.edu are shown in Figure 8.11.
Figure 8.11 showing the Traceroute program of the asymmetric path
The result of the issuance path (TTL field is 1-11) is different from the return path (TTL field is 11-21), which is well explained on the Internet, routing options may be asymmetrical. This output also describes the issues we discussed in Figure 8.3. Compare the output of the TTL fields 2 and 19: They are both router Gateway.Tuc.Noao.edu, but two IP addresses are different. Since the Traceroute program is used as its identifier, and we pass the router from two different directions, one is the issuing path (TTL field 2), and the other is the return path (TTL field is 19), so we can guess This result. By comparing the results of the TTL fields 3 and 18, 4 and 17, we can see the same result. 8.6 Summary In a TCP / IP network, Traceroute programs are indispensable tools. Its operation is simple: a TTL field is a UDP datagram that is started, and then the TTL field is added each time 1 to determine each router in the path. Each router returns an ICMP Time-Time Bill 2 when discarding the UDP datagram, and the final destination host generates a message that ICMP port is not available. We give examples of running TraceRoute programs on LAN and WANs and use it to examine the IP source station selection. We use loose source selection to detect whether the route to the target host is the same as the route returned from the destination host.
