| Узбекистан, Бухара, Бухарский институт высоких технологий, 2013 |
Инспектор
Вы можете этот курс.
Опубликован: 06.08.2012 | Уровень: специалист | Доступ: платный
Лекция 23:
Network debugging
Network layer problems
Once we know the link layer is working correctly, we can 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, how much is getting through. But what if your local network checks out just fine, and you can't reach a remote network? Or if you're losing 40% of your packets to http://foo.bar.org, and the remaining ones are taking up to 5 seconds to get through. Where's the 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's net. How can you find out?
As we saw while investigating the link layer, a complete failure is often easier to fix than a partial failure. If nothing at all is getting through, you probably have a routing problem. Check the routing table with netstat. On bumble, 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 0 xl0 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 UHLW 1 403 xl0
The default route is via gw, which is correct. The first thing is to ensure that you can ping gw; that's a link level issue, so we'll assume that you can. But what if you try to ping a remote system and you see something like this?
# 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 4 5 00 6800 c5da 0 0000 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 4 5 00 6800 c5e7 0 0000 fe 01 2460 223.147.37.2 207.170.123.194 ^C --- rider.fc.net ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss
These are ICMP messages from gw indicating that it does not know where to send the data. This is almost certainly a routing problem; on gw you might see something like:
$ 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 0 ppp0 223.147.37 link#1 UC 11 0 dc0 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 3 51246373 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 "Configuring the local network" , page 309, for more details, including how to ensure that the routes will be added automatically at boot time.
But what if the routes look right, you don't get any ICMP messages, and no data gets through? You don't always get ICMP messages when the data can't get through. The logical next place to look is free-gw.example.net, but there's a problem with that: as the administrator of example.org, you don't have access to example.net’s machines. You can call them up, of course, but before you do you should be reasonably sure it's their problem. You can find out more information with traceroute.
