Tài liệu Chapter-23-Network debugging docx

2Apr il 2003, 17:00:47 The Complete FreeBSD (netdebug.mm), page 401 23 Network debugging In this chapter: • Howtoapproach networ k problems • Link layerproblems • Networ k layer problems • traceroute • tcpdump • Tr anspor t and application layers • Ethereal In this chapter: • Howtoapproach networ k problems • Link layerproblems • Networ k layer problems • traceroute • tcpdump • Tr anspor t and application layers • Ethereal The chances are quite good that you’ll have some problems somewhere when you set up your network. FreeBSD givesyou a large number of tools with which to find and solve the problem. In this chapter,we’ll consider a methodology of debugging network problems. In the process, we’ll look at the programs that help debugging. It will help to have your finger in Chapter 16 while reading this section. Howtoapproachnetwork problems Recall from Chapter 16 that network software and hardware operate on at least four layers. If one layer doesn’twork, the ones above won’teither.When solving problems, it obviously makes sense to start at the bottom and work up. Most people understand this up to a point. Nobody expects a PPP connection to the Internet to work if the modem can’tdial the ISP.Onthe other hand, a large number of messages to the FreeBSD-questions mailing list showthat manypeople seem to think that once this connection has been established, everything else will work automatically. If it doesn’t, they’re puzzled. Unfortunately,the Net isn’tthat simple. In fact, it’stoo complicated to give a hard-and- fast methodology at all. Much network debugging can look more likemagic than anything rational. Nevertheless, a surprising number of network problems can be solved by using the steps below. Eveniftheydon’tsolveyour problem, read through them. Theymight give you some ideas about where to look. netdebug.mm,v v4.15 (2003/04/02 03:23:15) 401 Howtoapproach networ k problems 402 2April 2003, 17:00:47 The Complete FreeBSD ( /tools/tmac.Mn), page 402 Link layerproblems To test your link layer,start with ping. ping is a relatively simple program that sends an ICMP echo packet to a specific IP address and checks the reply. ICMP,isthe Internet Control Message Protocol,isused for error reporting and testing. See TCP/IP Illustrated,byRichard Stevens, for more information. Atypical ping output might look like: $ ping bumble PING bumble.example.org (223.147.37.156): 56 data bytes 64 bytes from 223.147.37.156: icmp_seq=0 ttl=255 time=1.137 ms 64 bytes from 223.147.37.156: icmp_seq=1 ttl=255 time=0.640 ms 64 bytes from 223.147.37.156: icmp_seq=2 ttl=255 time=0.671 ms 64 bytes from 223.147.37.156: icmp_seq=3 ttl=255 time=0.612 ms ˆC --- bumble.example.org ping statistics --- 4packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.612/0.765/1.137/0.216 ms In this case, we are sending the messages to the system bumble.example.org.Bydefault, ping sends messages of 56 bytes. With the IP header,this makes packets of 64 bytes. By default, ping continues until you stop it—notice the ˆC indicating that this invocation wasstopped by pressing Ctrl-C. The information that ping givesyou isn’tmuch, but it’suseful: • It tells you howlong it takes for each packet to get to its destination and back. • It tells you howmanypackets didn’tmakeit. • It also prints a summary of packet statistics. But what if this doesn’twork? You enter your ping command, and all you get is: $ ping wait PING wait.example.org (223.147.37.4): 56 data bytes ˆC --- wait.example.org ping statistics --- 5packets transmitted, 0 packets received, 100% packet loss Obviously,something’swrong here. We’lllook at it in more detail below. This is very different, however, from this situation: $ ping presto ˆC In the second case, evenafter waiting a reasonable amount of time, nothing happened at all. ping didn’tprint the PING message, and when we hit Ctrl-C there was no further output. This is indicative ofaname resolution problem: ping can’tprint the first line (PING presto .)until it has found the IP address of the system, in other words, until it has performed a DNS lookup. If we wait long enough, it will time out, and we get the message ping: cannot resolve presto: Unknown host.Ifthis happens, use the IP address instead of the name. DNS is an application, so we won’teventry to debug it netdebug.mm,v v4.15 (2003/04/02 03:23:15) 403 Chapter 23: Networ k debugging 2April 2003, 17:00:47 The Complete FreeBSD ( /tools/tmac.Mn), page 403 until we’ve debugged the link and network layers. If things don’twork out, there are twopossibilities: • If both systems are on the same network, it’salink layer problem. We’lllook at that first. • If the systems are on twodifferent networks, it might be a network layer problem. That’smore complicated: we don’tknowwhich network to look at. It could be either of the networks on which the systems are located, or it could also be a problem with one of the networks on the way.How doyou find out where your packets get lost? First you check the link layer.Ifitchecks out OK, and the problem still exists, continue with the network layer on page 405. So what can cause link layer problems? There are a number of possibilities: • One of the interfaces (source or destination) could be misconfigured. Theyshould both have onthe same range of network addresses. Forexample, the following two interface configurations cannot talk to each other directly,evenifthey’re on the same physical network: machine 1 dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 223.147.37.81 netmask 0xffffff00 broadcast 223.147.37.255 machine 2 xl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 options=3<RXCSUM,TXCSUM> inet 192.168.27.1 netmask 0xffffff00 broadcast 192.168.27.255 • If you see something likethis on an Ethernet interface, it’spretty clear that it has a cabling problem: xl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 options=3<RXCSUM,TXCSUM> inet 192.168.27.1 netmask 0xffffff00 broadcast 192.168.27.255 media: Ethernet autoselect (none) status: no carrier In this case, check the physical connections. If you’re using UTP,check that you have the right kind of cable, normally a ‘‘straight-through’’cable. If you accidentally use a crossovercable where you need a straight-through cable, or vice versa, you will not get anyconnection. Also, manyhubs and switches have a ‘‘crossover’’switch that achievesthe same result. • If you’re on an RG-58 thin Ethernet, the most likely problem is a break in the cabling. Youcan check the static resistance between the central pin and the external part of the connector with a multimeter.Itshould be approximately 25Ω.Ifit’s50Ω,it indicates that there is a break in the cable, or that one of the terminators has been disconnected. • If your interface is configured correctly,and you’re using a 10 Mb/s card, check whether you are using the correct connection to the network. Some older Ethernet boards support multiple physical connections (for example, both BNC and UTP). For netdebug.mm,v v4.15 (2003/04/02 03:23:15) Link layerproblems 404 2April 2003, 17:00:47 The Complete FreeBSD ( /tools/tmac.Mn), page 404 example, if your network runs on RG58 thin Ethernet, and your interface is set to AUI, you may still be able to send data on the RG58, but you won’tbeable to receive any. The method of setting the connection depends on the board you are using. PCI boards are not normally a problem, because the drivercan set the parameters directly, butISA boards can drive you crazy.Inthe case of very old boards, such as the Western Digital 8003, you may need to set jumpers. In others, you may need to run the setup utility under DOS, and with others you can set it with the link flags to ifconfig.For example, on a 3Com 3c509 ‘‘combo’’board, you can set the connection likethis: # ifconfig ep0 -link0 set BNC # ifconfig ep0 link0 -link1 set AUI # ifconfig ep0 link0 link1 set UTP This example is correct for the ep driver, but not necessarily for other Ethernet boards: each board has its own flags. Read the man page for the board for the correct flags. • If your interface looks OK, the next thing to do is to see whether you can send data to other machines on the network. If so, of course, you should continue your search on the machine that isn’tresponding. If none are working, you probably have a cabling problem. On a wireless network, you need to check for a number of additional problems. ifconfig should showsomething likethis: wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::202:2dff:fe04:93a%wi0 prefixlen 64 scopeid 0x3 inet 192.168.27.17 netmask 0xffffff00 broadcast 192.168.27.255 ether 00:02:2d:21:54:4c media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) status: associated ssid "FreeBSD IBSS" 1:"" stationname "FreeBSD WaveLAN/IEEE node" channel 3 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 wepkey 2:64-bit 0x123456789a 3:128-bit 0x123456789abcdef123456789ab There are manythings to check here: • Do you have the same operating mode? This example shows a card operating in BSS or IBSS mode. By contrast, you might see this: media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps <adhoc, flag0>) In this case, the interface is operating in so-called ‘‘Lucent demo ad-hoc’’mode, which is not the same thing as ‘‘ad-hoc’’mode (which in turn is better called IBSS mode). IBSS mode (‘‘ad-hoc’’) and BSS mode are compatible. IBSS mode and ‘‘Lucent demo ad-hoc’’mode are not. See Chapter 17, page 306 for further details. netdebug.mm,v v4.15 (2003/04/02 03:23:15) 405 Chapter 23: Networ k debugging 2April 2003, 17:00:47 The Complete FreeBSD ( /tools/tmac.Mn), page 405 • Is the status associated?The alternative is no carrier.Some cards, including this one, show no carrier when communicating with a station operating in IBSS mode, but theynev ershow associated unless theyare really associated. • If the card is not associated, check the frequencies and the network name. • Check the WEP (encryption) parameters to ensure that theymatch. Note that ifconfig does not display the WEP key unless you are root. Your card may show associated ev enifthe WEP key doesn’tmatch. In such a case, it knows about the network, but it can’tcommunicate with it. After checking all these things, you should have a connection. But you may not be home yet: • If you have a connection, check if all packets got there. Lost packets could mean line quality problems. That’snot very likely on an Ethernet, but it’svery possible on a PPP or DSL link. There’sanuncertainty about dropped packets: you might hit Ctrl- C after the last packet went out, but before it came back. If the line is very slow, you might lose multiple packets. Compare the sequence number of the last packet that returns with the total number returned. If it’sone less, all the packets except the ones at the end made it. • Check that each packet comes back only once. If not, there’sdefinitely something wrong, or you have been pinging a broadcast address. That looks likethis: $ ping 223.147.37.255 PING 223.147.37.255 (223.147.37.255): 56 data bytes 64 bytes from 223.147.37.1: icmp_seq=0 ttl=255 time=0.428 ms 64 bytes from 223.147.37.88: icmp_seq=0 ttl=255 time=0.785 ms (DUP!) 64 bytes from 223.147.37.65: icmp_seq=0 ttl=64 time=1.818 ms (DUP!) 64 bytes from 223.147.37.1: icmp_seq=1 ttl=255 time=0.426 ms 64 bytes from 223.147.37.88: icmp_seq=1 ttl=255 time=0.442 ms (DUP!) 64 bytes from 223.147.37.65: icmp_seq=1 ttl=64 time=1.099 ms (DUP!) 64 bytes from 223.147.37.126: icmp_seq=1 ttl=255 time=45.781 ms (DUP!) FreeBSD systems do not respond to broadcast pings, but most other systems do, so this effectively counts the number of non-BSD machines on a network. • Check the times. A ping across an Ethernet should takebetween about 0.2 and 2 ms, a ping across a wireless connection should takebetween 2 and 12 ms, a ping across an ISDN connection should takeabout 30 ms, a ping across a 56 kb/s analogue connection should takeabout 100 ms, and a ping across a satellite connection should takeabout 250 ms in each direction. All of these times are for idle lines, and the time can go up to over5seconds for a slowline transferring large blocks of data across a serial line (for example, ftping a file). In this example, some line traffic delayed the response to individual pings. netdebug.mm,v v4.15 (2003/04/02 03:23:15) Link layerproblems 406 2April 2003, 17:00:47 The Complete FreeBSD ( /tools/tmac.Mn), page 406 Network layerproblems Once we knowthe link layer is working correctly,wecan turn our attention to the next layer up, the network layer.Well, first we should check if the problem is still with us. We need additional tools for the network layer. ping is a useful tool for telling you whether data is getting through to the destination, and if so, howmuch is getting through. But what if your local network checks out just fine, and you can’treach a remote network? Or if you’re losing 40% of your packets to foo.bar.org,and the remaining ones are taking up to 5 seconds to get through. Where’sthe problem? Based on the recent ‘‘upgrade’’your ISP performed, and the fact that you’ve had trouble getting to other sites, you suspect that the performance problems might be occurring in the ISP’snet. Howcan you find out? As we sawwhile investigating the link layer,acomplete failure is often easier to fix than apartial failure. If nothing at all is getting through, you probably have a routing problem. Check the routing table with netstat.Onbumble,you might see: $ netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default gw UGSc 0 8 xl0 localhost localhost UH 2 525 lo0 223.147.37 link#1 UC 6 0xl0 sat-gw 00:80:c6:f9:d3:fa UHLW 0 0 xl0 1150 bumble 00:50:da:cf:17:d3 UHLW 0 24 lo0 presto 00:80:c6:f9:a6:c8 UHLW 0 5 xl0 1200 freebie 00:50:da:cf:07:35 UHLW 6 760334 xl0 1159 223.147.37.255 ff:ff:ff:ff:ff:ff UHLWb 1 403 xl0 The default route is via gw,which is correct. The first thing is to ensure that you can ping gw;that’salink levelissue, so we’ll assume that you can. But what if you try to ping aremote system and you see something likethis? # ping rider.fc.net PING rider.fc.net (207.170.123.194): 56 data bytes 36 bytes from gw.example.org (223.147.37.5): Destination Host Unreachable Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 45006800 c5da 00000 fe 01 246d 223.147.37.2 207.170.123.194 36 bytes from gw.example.org (223.147.37.5): Destination Host Unreachable Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 45006800 c5e7 00000 fe 01 2460 223.147.37.2 207.170.123.194 ˆC --- rider.fc.net ping statistics --- 2packets transmitted, 0 packets received, 100% packet loss These are ICMP messages from gw indicating that it does not knowwhere to send the data. This is almost certainly a routing problem; on gw you might see something like: netdebug.mm,v v4.15 (2003/04/02 03:23:15) 407 Chapter 23: Networ k debugging 2April 2003, 17:00:47 The Complete FreeBSD ( /tools/tmac.Mn), page 407 $ netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire localhost localhost UH 1 123 lo0 free-gw.example.ne exorg-gw.example. UH 23 0ppp0 223.147.37 link#1 UC 11 0dc0 sat-gw 00:80:c6:f9:d3:fa UHLW 5 1295329 dc0 1027 bumble 00:50:da:cf:17:d3 UHLW 2 760207 dc0 802 flame 08:00:20:76:6c:7b UHLW 2 426341 dc0 532 wantadilla 00:02:44:17:f8:da UHLW 36 19778224 dc0 1073 presto 00:80:c6:f9:a6:c8 UHLW 1 1122321 dc0 742 freebie 00:50:da:cf:07:35 UHLW 24 3279563 lo0 air-gw 00:00:b4:33:6d:a2 UHLW 4 2484 dc0 653 kimchi 00:00:21:ca:6e:f1 UHLW 0 1 dc0 829 223.147.37.127 link#1 UHLW 0 5 dc0 fumble link#1 UHLW 351246373 dc0 The problem here is that there is no default route. Add it with the route command: # route add default free-gw.example.net # netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default free-gw.example.ne UGSc 24 5724 ppp0 localhost localhost UH 1 123 lo0 .etc See Chapter 17, page 310, for more details, including howtoensure that the routes will be added automatically at boot time. But what if the routes look right, you don’tget anyICMP messages, and no data gets through? You don’talways get ICMP messages when the data can’tget through. The logical next place to look is free-gw.example.net,but there’saproblem with that: as the administrator of example.org,you don’thav e access to example.net’s machines. You can call them up, of course, but before you do you should be reasonably sure it’stheir problem. You can find out more information with traceroute. traceroute traceroute sends UDP packets to the destination, but it modifies the time-to-live field in the IP header (see page 280) so that, initially at anyrate, theydon’tget there. As we saw there, the time-to-live field specifies the number of hops that a packet can go before it is discarded. When it is, the system that discards it should send back an ICMP destination unreachable message. traceroute uses this feature and sends out packets with time-to- live set first to one, then to two, and so on. It prints the IP address of the system that sends the ‘‘destination unreachable’’message and the time it took, thus giving something likeatwo-dimensional ping.Here’sanexample to hub.FreeBSD.org: netdebug.mm,v v4.15 (2003/04/02 03:23:15) traceroute 408 2April 2003, 17:00:47 The Complete FreeBSD ( /tools/tmac.Mn), page 408 $ traceroute hub.freebsd.org traceroute to hub.freebsd.org (204.216.27.18), 30 hops max, 40 byte packets 1gw(223.147.37.5) 1.138 ms 0.811 ms 0.800 ms 2free-gw.example.net (139.130.136.129) 131.913 ms 122.231 ms 134.694 ms 3Ethernet1-0.way1.Adelaide.example.net (139.130.237.65) 118.229 ms 120.040 ms 118.723 ms 4Fddi0-0.way-core1.Adelaide.example.net (139.130.237.226) 171.590 ms 117.911 ms 123.513 ms 5Serial5-0.lon-core1.Melbourne.example.net (139.130.239.21) 129.267 ms 226.927 ms 125.547 ms 6Fddi0-0.lon5.Melbourne.example.net (139.130.239.231) 144.372 ms 133.998 ms 13 6.699 ms 7borderx2-hssi3-0.Bloomington.mci.net (204.70.208.121) 962.258 ms 482.393 ms 7 54.989 ms 8core2-fddi-1.Bloomington.mci.net (204.70.208.65) 821.636 ms * 701.920 ms 9bordercore3-loopback.SanFrancisco.mci.net (166.48.16.1) 424.254 ms 884.033 ms 645.302 ms 10 pb-nap.crl.net (198.32.128.20) 435.907 ms 438.933 ms 451.173 ms 11 E0-CRL-SFO-02-E0X0.US.CRL.NET (165.113.55.2) 440.425 ms 430.049 ms 447.340 ms 12 T1-CDROM-00-EX.US.CRL.NET (165.113.118.2) 553.624 ms 460.116 ms * 13 hub.FreeBSD.ORG (204.216.27.18) 642.032 ms 463.661 ms 432.976 ms By default, traceroute tries each hop three times and prints out the times as theyhappen, so if the reponse time is more than about 300 ms, you’ll notice it as it happens. If there is no reply after a timeout period (default 5 seconds), traceroute prints an asterisk (*). You’ll also occasionally notice a significant delay at the beginning of a line, although the response time seems reasonable. In this case, the delay is probably caused by a DNS reverse lookup for the name of the system. If this becomes a problem (maybe because the global DNS servers aren’treachable), you can turn offDNS reverse lookup using the -n flag. If you look more carefully at the times in the example above,you’ll see three groups of times: 1. The times to gw are round 1 ms. This is typical of an Ethernet network. 2. The times for hops 2 to 6 are in the order of 100 to 150 ms. This indicates that the link between gw.example.org and free-gw.example.net is running PPP overa telephone line. The delay between free-gw.example.net and Fddi0-0.lon5.Mel- bourne.example.net is negligible compared to the delay across the PPP link, so you don’tsee much difference. 3. The times from borderx2-hssi3-0.Bloomington.mci.net to hub.FreeBSD.ORG are significantly higher,between 400 and 1000 ms. We also note a couple of dropped packets. This indicates that the line between Fddi0-0.lon5.Melbourne.example.net and borderx2-hssi3-0.Bloomington.mci.net is overloaded. The length of the link (about 13,000 km) also plays a role: that’satotal distance of 26,000 km, which take about 85 ms to transfer.Ifthis were a satellite connection, things would be much slower: the total distance from ground station to satellite and back to the ground is 72,000 km, which takes a total of 240 ms to propagate. Back to our problem. If we see something likethe output in the previous example, we knowthat there’snoreason to call up the people at example.net:it’snot their problem. This might just be overloading on the global Internet. On the other hand, what about this? netdebug.mm,v v4.15 (2003/04/02 03:23:15) 409 Chapter 23: Networ k debugging 2April 2003, 17:00:47 The Complete FreeBSD ( /tools/tmac.Mn), page 409 $ traceroute hub.freebsd.org traceroute to hub.freebsd.org (204.216.27.18), 30 hops max, 40 byte packets 1gw(223.147.37.5) 1.138 ms 0.811 ms 0.800 ms 2*** 3*** ˆC You’ve fixedyour routing problems, but you still can’tget data offthe system. There are anumber of possibilities here: • The link to the next system may be down. The solution’sobvious: bring it up and try again. • gw may not be configured as a gateway. You can check this with: $ sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 1 Forarouter,this value should be 1.Ifit’s0,change it with: # sysctl -w net.inet.ip.forwarding=1 net.inet.ip.forwarding: 0 -> 1 See page 313 for further details, including howtoensure that this sysctl is set correctly when the system starts. • Youmay be trying to use a non-routable IP address such as those in the range 192.168.x.x.You can’tdothat. If you don’thav e enough globally visible IP address, you’ll need to run some kind of aliasing package, such as NAT . See Chapter 22, page 393, for further details. • Maybe there is something wrong with routing to your network. This is a difficult one to check, but in the case of the reference network, one possibility is to repeat the traceroute from the machine gw: gw’s external address on the tun0 interface is 139.130.136.133,which is on the ISP’snetwork. As aresult, theyare not affected by a routing problem for network 223.147.37.x.Ifthis provestobethe case, contact your ISP to solveit. • Maybe there is something wrong with the other end; if everything else fails, you may have tocall the admins at example.net ev enifyou have nohard evidence that it’s their problem. But maybe the data gets one hop further: $ traceroute hub.freebsd.org traceroute to hub.freebsd.org (204.216.27.18), 30 hops max, 40 byte packets 1gw(223.147.37.5) 1.138 ms 0.811 ms 0.800 ms 2free-gw.example.net (139.130.136.129) 131.913 ms 122.231 ms 134.694 ms 3*** 4*** ˆC In this case, there is almost certainly a problem at example.net.This would be the correct time to use the telephone. netdebug.mm,v v4.15 (2003/04/02 03:23:15) traceroute 410 2April 2003, 17:00:47 The Complete FreeBSD ( /tools/tmac.Mn), page 410 High packet loss But maybe data is getting through. Well, some data, anyway.Consider this ping session: $ ping freefall.FreeBSD.org PING freefall.FreeBSD.org (216.136.204.21): 56 data bytes 64 bytes from 216.136.204.21: icmp_seq=0 ttl=244 time=496.426 ms 64 bytes from 216.136.204.21: icmp_seq=1 ttl=244 time=491.334 ms 64 bytes from 216.136.204.21: icmp_seq=2 ttl=244 time=479.077 ms 64 bytes from 216.136.204.21: icmp_seq=3 ttl=244 time=473.774 ms 64 bytes from 216.136.204.21: icmp_seq=4 ttl=244 time=733.429 ms 64 bytes from 216.136.204.21: icmp_seq=5 ttl=244 time=644.726 ms 64 bytes from 216.136.204.21: icmp_seq=7 ttl=244 time=490.331 ms 64 bytes from 216.136.204.21: icmp_seq=8 ttl=244 time=839.671 ms 64 bytes from 216.136.204.21: icmp_seq=9 ttl=244 time=773.764 ms 64 bytes from 216.136.204.21: icmp_seq=10 ttl=244 time=553.067 ms 64 bytes from 216.136.204.21: icmp_seq=11 ttl=244 time=454.707 ms 64 bytes from 216.136.204.21: icmp_seq=12 ttl=244 time=472.212 ms 64 bytes from 216.136.204.21: icmp_seq=13 ttl=244 time=448.322 ms 64 bytes from 216.136.204.21: icmp_seq=14 ttl=244 time=441.352 ms 64 bytes from 216.136.204.21: icmp_seq=15 ttl=244 time=455.595 ms 64 bytes from 216.136.204.21: icmp_seq=16 ttl=244 time=460.040 ms 64 bytes from 216.136.204.21: icmp_seq=17 ttl=244 time=476.943 ms 64 bytes from 216.136.204.21: icmp_seq=18 ttl=244 time=514.615 ms 64 bytes from 216.136.204.21: icmp_seq=23 ttl=244 time=538.232 ms 64 bytes from 216.136.204.21: icmp_seq=24 ttl=244 time=444.123 ms 64 bytes from 216.136.204.21: icmp_seq=25 ttl=244 time=449.075 ms ˆC --- 216.136.204.21 ping statistics --- 27 packets transmitted, 21 packets received, 22% packet loss round-trip min/avg/max/stddev = 441.352/530.039/839.671/113.674 ms In this case, we have a connection. But look carefully at those sequence numbers. At one point, four packets in a row(sequence 19 to 22) get lost. Howhigh a packet drop rate is still acceptable? 1% or 2% is probably still (barely) acceptable. By the time you get to 10%, though, things look a lot worse. 10% packet drop rate doesn’tmean that your connection slows down by 10%. Forevery dropped packet, you have a minimum delay of one second until TCP retries it. If that retried packet gets dropped too—which it will ev ery 10 dropped packets if you have a 10% drop rate—the second retry takes another three seconds. If you’re transmitting packets of 64 bytes overa33.6 kb/s link, you can normally get about 60 packets through per second. With 10% packet loss, the time to get these packets through is about eight seconds, a throughput loss of 87.5%. With 20% packet loss, the results are evenmore dramatic. Now12ofthe 60 packets have to be retried, and 2.4 of them will be retried a second time (for three seconds delay), and 0.48 of them will be retried a third time (six seconds delay). This makes a total of 22 seconds delay,athroughput degradation of nearly 96%. Theoretically,you might think that the degradation would not be as bad for big packets, such as you might have with file transfers with ftp.Infact, the situation is worse then: in most cases the packet drop rate rises sharply with the packet size, and it’scommon enough that ftp times out completely before it can transfer a file. To get a better overviewofwhat’sgoing on, let’slook at another program, tcpdump. netdebug.mm,v v4.15 (2003/04/02 03:23:15) [...]...2 April 2003, 17:00:47 The Complete FreeBSD ( /tools/tmac.Mn), page 411 411 Chapter 23: Network debugging tcpdump tcpdump is a program that monitors a network interface and displays selected information that passes through it It uses the Berkeley Packet Filter (bpf ), an optional component of the... win 17520 win 17520 (DF) win 17520 win 17520 (DF) (DF) (DF) (DF) netdebug.mm,v v4.15 (2003/04/02 03:23:15) 2 April 2003, 17:00:47 The Complete FreeBSD ( /tools/tmac.Mn), page 413 413 Chapter 23: Network debugging The first line shows freebie sending bytes 20 to 40 of the stream to bub, and also acknowledging receipt of everything up to byte 77 of the stream from hub On the next line, hub sends bytes 77... (/usr/ports/net/ethereal) that displays the data in much more detail: netdebug.mm,v v4.15 (2003/04/02 03:23:15) 2 April 2003, 17:00:47 The Complete FreeBSD ( /tools/tmac.Mn), page 415 415 Chapter 23: Network debugging Figure 23-1: ethereal display The screen is divided into three windows: • The top part shows individual packets (numbered 51 to 54 in this example) The line in inverse video has been selected . chapter,we’ll consider a methodology of debugging network problems. In the process, we’ll look at the programs that help debugging. It will help to have your. 2Apr il 2003, 17:00:47 The Complete FreeBSD (netdebug.mm), page 401 23 Network debugging In this chapter: • Howtoapproach networ k problems • Link layerproblems