Опубликован: 06.08.2012 | Доступ: свободный | Студентов: 1189 / 25 | Оценка: 5.00 / 5.00 | Длительность: 53:41:00
Лекция 23:

Network debugging

< Лекция 22 || Лекция 23: 1234 || Лекция 24 >

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.

< Лекция 22 || Лекция 23: 1234 || Лекция 24 >