xixihaha
1 Copper

Re: 网络基本功系列:细说网络那些事儿(11月3日更新)

能否详细举例讲一讲?最好能结合实际,比如,杭州某用户访问百度北京机房的www.baidu.com,是怎么路由器的?

0 项奖励
xixihaha
1 Copper

Re: 网络基本功系列:细说网络那些事儿(11月3日更新)

这两天学习了一下OSPF网络。

讲述OSPF优点时,其中有一句“将某一区域网络拓扑变化的影响限制在该区域内,不会影响到整个OSPF网络”。

通过OSPF中area的概念,使区域内的路由信息数据就不会有那么多了?可以这样解释吗?

0 项奖励
Zhang_Jiawen
4 Beryllium

Re: 网络基本功系列:细说网络那些事儿(11月3日更新)

网络基本功(十四):细说诊断工具ping

转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese image001.gif

介绍

ping的工作原理很简单,一台网络设备发送请求等待另一网络设备的回复,并记录下发送时间。接收到回复之后,就可以计算报文传输时间了。只要接收到回复就表示连接是正常的。耗费的时间喻示了路径长度。重复请求响应的一致性也表明了连接质量的可靠性。因此,ping回答了两个基本的问题:是否有连接?连接的质量如何?本文主要讨论这两个问题。


更多信息

正常的ping操作主要是两个特定的ICMP消息,ECHO_REQUESTECHO_REPLY。理论上,所有TCP/IP网络设备都应当通过返回报文来响应ECHO_REQUEST,但实际上并不总是如此。

ping的解析:

大多数操作系统版本,会一直发送ECHO_REQUESTs,直到中断为止。例如:

bsd1# ping www.bay.com

PING www.bay.com (204.80.244.66): 56 data bytes

64 bytes from 204.80.244.66: icmp_seq=0 ttl=112 time=180.974 ms

64 bytes from 204.80.244.66: icmp_seq=1 ttl=112 time=189.810 ms

64 bytes from 204.80.244.66: icmp_seq=2 ttl=112 time=167.653 ms

^C

--- www.bay.com ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max/stddev = 167.653/179.479/189.810/9.107 ms

bsd1#

这一过程被Ctrl-C中断,此时打印出汇总统计。

上述结果中,针对每一个报文的回复给出了报文大小,来源,ICMP sequence numberTTL值,以及往返时间。其中,sequence number和往返时间对于评估基本连接状况来说是最有用的信息。


当发送一个ECHO_REQUEST时,将发送时间记录在报文里,并复制到远端主机相应的ECHO_REPLY报文中。当接收到ECHO_REPLY时,通过比较当前时间与报文时间计算出耗费时间。如果没有收到符合该sequence number的报文,则认为该报文丢失。耗费时间长短以及变化范围取决于中间链路数量,速度,以及链路拥塞情况。


什么值是合理的呢?这一值高度取决于网络以及网络质量。如果是在LAN网络环境下,响应时间还是很快的,通常在十几毫秒范围之内。如果连接到外网则该值会显著增加。如果是远程站点,可能会耗时上百毫秒。


你也可以用ping来粗略计算连接的吞吐量。在外网上发送两个不同大小的报文,通过-s选项来完成。时间长度的差别会反映大报文中额外数据所耗费的时间。例如,假设ping 100字节耗费30msping 1100字节耗费60ms,因此,往返额外花费30ms单程额外花费15ms,多发送1000字节或8000比特。吞吐量近似为每15ms 8000比特或540000bps。两个测量值之间的差异用来扣除开销。当然这一估算是非常粗略的,没有考虑到路径上其他数据流的情况,也没有考虑路径上所有链路的情况。


TTL貌似可以估算一条路径上的跳数,但是这有一些问题。当发送报文时,TTL字段先被初始化接着经过路径上每个路由器都要递减。如果达到0,报文就被丢弃了。从而对所有报文生命周期有一定限制。因而在路由回环的过程中,报文不会无期限存在于网络上。不幸的是,TTL字段可能会,也可能不会被远端设备重置,如果重置,也没有一致性。因此,要使用TTL字段估算路径中的跳数需要知道详细的系统信息。


通常一串稳定的回复意味着健康的连接。如果报文丢失或丢弃,可以在sequence number中看到跳数,以及丢失报文的编号。偶尔丢失一个报文不表示真的有什么问题。特别是跨越多台路由器或拥塞网络时。一个序列中的一个报文丢失或耗费明显更长时间是很正常的,这是因为路径中各条链路需对第一个报文做ARP解析。在ARP数据保存之后,后续报文就不会有这种开销。但是,如果丢失报文比例较大,则有可能路径上有问题。


某些情况下会收到ICMP错误消息。通常来自路由器,这里面包含很有用的信息。例如,下例中,设备尝试访问一个不存在的网络上的设备:

bsd1# ping 172.16.4.1

PING 172.16.4.1 (172.16.4.1): 56 data bytes

36 bytes from 172.16.2.1: Destination Host Unreachable

Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst

4  5  00 5400 5031   0 0000  fe  01 0e49 172.16.2.13  172.16.4.1

36 bytes from 172.16.2.1: Destination Host Unreachable

Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst

4  5  00 5400 5034   0 0000  fe  01 0e46 172.16.2.13  172.16.4.1

^C

--- 172.16.4.1 ping statistics ---

2 packets transmitted, 0 packets received, 100% packet loss


由于路由器没有到达该网络的路径,所以返回ICMP DESTINATION_HOST_UNREACHABLE信息。通常如果问题发生在运行ping命令的设备上,则会收到Destination Host Unreachable告警或 Destination Network Unreachable告警。如果问题发生在转发报文的设备上,则只会收到一条Destination Host Unreachable

下例中,尝试向一台已配置拒绝从源设备接收数据流的路由器发送数据:

bsd1# ping 172.16.3.10

PING 172.16.3.10 (172.16.3.10): 56 data bytes

36 bytes from 172.16.2.1: Communication prohibited by filter

Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst

4  5  00 5400 5618   0 0000  ff  01 0859 172.16.2.13  172.16.3.10

36 bytes from 172.16.2.1: Communication prohibited by filter

Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst

4  5  00 5400 561b   0 0000  ff  01 0856 172.16.2.13  172.16.3.10

^C

--- 172.16.3.10 ping statistics ---

2 packets transmitted, 0 packets received, 100% packet loss


被过滤条件阻止的告警信息表明报文被丢弃。但也有可能过滤条件不显示该告警。

下例中,

bsd1# ping 172.16.3.10

PING 172.16.3.10 (172.16.3.10): 56 data bytes

^C

--- 172.16.3.10 ping statistics ---

6 packets transmitted, 0 packets received, 100% packet loss


路由器上使用同样的过滤条件,但应用于离开网络的数据流,而不作用于inbound数据流。因此,没有消息发送。这时,ping就无法告诉你为什么报文没有收到回复。

ping的选项:

一些选项控制发送报文的速率和数量,-c选项允许用户指定发送报文的数量。例如,ping –c10会发送10个报文然后停止。这一命令在脚本中很有用处。

命令-f-l用于将报文泛洪到网络上。-f选项表明报文发送速率与接收主机能够处理速率相同。这一参数可用于链路压力测试或接口性能比较。

-l选项用于计数,尽可能快的发送该数量报文,然后恢复正常。该命令用于测试处理泛洪的能力,需要root权限执行。

-i选项用于用户在两个连续报文之间指定等待秒数。该命令对于将报文间隔开或用在脚本中非常有用。正常情况下,偶然的ping包对数据流的影响是很小的。但重复报文或报文泛洪影响就很大了。因此,使用以上选项时需谨慎。

-n选项将输出限制为数字形式,这在碰见DNS问题时很有用。-v显示更详尽输出,较少输出为-q-Q

-s选项指定发送数据的大小。但如果设置的太小,小于8,则报文中就没有空间留给时间戳了。设置报文大小能诊断有路径MTU(Maximum Transmission Unit)设置或分段而导致的问题。如果不使用该选项,ping默认是64字节。

参考

Network Troubleshooting Tools

             

0 项奖励
Zhang_Jiawen
4 Beryllium

Re: 网络基本功系列:细说网络那些事儿(11月10日更新)

网络基本功(十五):细说网络性能监测与实例(上)

转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese image001.gif

介绍

网络路径性能检测主要包括三方面的内容:带宽测量能够获知网络的硬件特性,如网络的最大容量,吞吐量测量能够获得网络实际可提供的最大容量,数据流测量能够了解真实占用的网络容量。

本文介绍在评估网络性能是否合理时,需要收集的数据及收集方式。涉及工具包括:ping, pathchar, bing, ttcp, netperf, iperf, netstat


更多信息

带宽测量:

ping

ping这一工具返回的时间,虽然通常被描述为传输延时,实际上是发送,传输,队列延时之和。上一节中,我们通过ping来粗略计算带宽。这一过程可通过如下方式改进:首先计算链路近端的路径行为,然后计算远端路径,然后用两者差异来估算链路带宽。

image002.png

这一过程需要四次使用ping。首先,用两个不同大小报文ping近端链路。减掉传输大报文中额外数据的传输时间以外,时间差可估算传输以及队列延时。接下来,用同样两个报文ping远端链路。再次用大报文和小报文的时间差来估算开销。最后,用两次差值的差值就是在最后一段链路中传输额外数据的时间值。这是一个往返时间,除以2就是额外数据在单向链路传输所用时间。带宽则是额外数据总量除以单向传输时间。

下表是第二跳和第三跳的时间值,报文大小为1001100字节。

image003.png

下表显示了带宽计算结果,用time difference除以2,用8000bit除以这个值,再乘1000(毫秒转换为秒)。结果是bps转换为Mbps

image004.png

pathchar

将上述过程自动话完成的一个工具是pathcharpathchar在路径的一端即能检测各链路的带宽。方法与之前描述的ping相类似,但是pathchar使用各种大小不一的报文。如下例所示:

bsd1# pathchar 165.166.0.2

pathchar to 165.166.0.2 (165.166.0.2)

mtu limited to 1500 bytes at local host

doing 32 probes at each of 45 sizes (64 to 1500 by 32)

0 205.153.60.247 (205.153.60.247)

|   4.3 Mb/s,   1.55 ms (5.88 ms)

1 cisco (205.153.60.2)

|   1.5 Mb/s,   -144 us (13.5 ms)

2 165.166.36.17 (165.166.36.17)

|    10 Mb/s,   242 us (15.2 ms)

3 e0.r01.ia-gnwd.Infoave.Net (165.166.36.33)

|   1.2 Mb/s,   3.86 ms (32.7 ms)

4 165.166.125.165 (165.166.125.165)

|   ?? b/s,   2.56 ms (37.7 ms)

5 165.166.125.106 (165.166.125.106)

|    45 Mb/s,   1.85 ms (41.6 ms),  +q 3.20 ms (18.1 KB) *4

6 atm1-0-5.r01.ncchrl.infoave.net (165.166.126.1)

|    17 Mb/s,   0.94 ms (44.3 ms),  +q 5.83 ms (12.1 KB) *2

7 h10-1-0.r01.ia-chrl.infoave.net (165.166.125.33)

|   ?? b/s,   89 us (44.3 ms),  1% dropped

8 dns1.InfoAve.Net (165.166.0.2)

8 hops, rtt 21.9 ms (44.3 ms), bottleneck 1.2 Mb/s, pipe 10372 bytes

pathchar的运行过程中,首先显示的信息描述探测如何进行。从第三行输出开始,可看到pathchar使用从641500字节的45中不同大小报文。对于每一跳使用32种不同报文组合进行测试。因此,共8跳生成了11520个测试报文加上相应回复信息。

显示中给出了带宽和延时。pathchar也包括了队列延时信息(如本例中56)。如上述信息,pathchar并不总是能成功估算出带宽(如链路47)或是延时(如链路1)。

pathchar运行过程中,每发送一个报文就启动一次倒计时:显示内容如下所示:

1:  31   288   0       3

1指示跳数并且随着路径上后续跳数而增加。下一个数字是倒计时值,给出这一链路剩余的探测组数。第三个值是当前发送报文大小。第二个和第三个值改变都非常迅速。倒数第二个值是目前为止丢弃报文数,最后一个是该链路的平均往返时间。

当一条的探测完成时,这一行内容被带宽,传输延时,往返时间所取代。pathchar使用观测到的最小延时来改进带宽估算值。

bing

pathchar的一个替代工具是bingpathchar估算的是一条路径上各链路的带宽,而bing用来测量点到点的带宽。通常,如果你不知道路径上的各条链路,需要首先执行traceroute命令。之后可以运行bing来指定链路的近端和远端。下例显示了第三跳的带宽:

bsd1# bing -e10 -c1 205.153.60.2 165.166.36.17

BING    205.153.60.2 (205.153.60.2) and 165.166.36.17 (165.166.36.17)

        44 and 108 data bytes

1024 bits in 0.835ms: 1226347bps, 0.000815ms per bit

1024 bits in 0.671ms: 1526080bps, 0.000655ms per bit

1024 bits in 0.664ms: 1542169bps, 0.000648ms per bit

1024 bits in 0.658ms: 1556231bps, 0.000643ms per bit

1024 bits in 0.627ms: 1633174bps, 0.000612ms per bit

1024 bits in 0.682ms: 1501466bps, 0.000666ms per bit

1024 bits in 0.685ms: 1494891bps, 0.000669ms per bit

1024 bits in 0.605ms: 1692562bps, 0.000591ms per bit

1024 bits in 0.618ms: 1656958bps, 0.000604ms per bit

--- 205.153.60.2 statistics ---

bytes   out    in   dup  loss   rtt (ms): min       avg       max

   44    10    10          0%           3.385     3.421     3.551

  108    10    10          0%           3.638     3.684     3.762

--- 165.166.36.17 statistics ---

bytes   out    in   dup  loss   rtt (ms): min       avg       max

   44    10    10          0%           3.926     3.986     4.050

  108    10    10          0%           4.797     4.918     4.986

--- estimated link characteristics ---

estimated throughput 1656958bps

minimum delay per packet 0.116ms (192 bits)

average statistics (experimental) :

packet loss: small 0%, big 0%, total 0%

average throughput 1528358bps

average delay per packet 0.140ms (232 bits)

weighted average throughput 1528358bps

resetting after 10 samples.

输出从地址和报文大小信息开始,之后是探测pair。接下来,返回往返时间和丢失数据。最后,返回一些吞吐量的估测值。

吞吐量测量:

吞吐量不够的原因不仅在于硬件不足,还有可能是网络设计架构的问题。例如,广播域设置得太大,则即使硬件够磅也会造成问题。解决方案是重构网络,在充分理解数据流模式后,将这类域隔离开或是分段。

吞吐量通常是测量大块数据传输延时来完成的。通常需要在链路各端运行软件。一般这类软件运行在应用层,所以它不仅测量网络也测量了软硬件。

一个比较简单粗放的方式是用FTP。用FTP来传输一份文件并且看一下它report的数据。需要将结果转换成比特率,例如,这是文件传输的最后一行:

1294522 bytes received in 1.44 secs (8.8e+02 Kbytes/sec)

1,294,522字节乘8转换成bit之后再除以时间1.44秒。 结果为7,191,789 bps

这种方法的不足在于磁盘访问时间可能对结果造成影响。如果需要提高精度则需要使用一些工具。

ttcp

运行这一程序首先需要在远端设备运行server,通常用-r-s选项。之后运行client,用-t-s选项,以及主机名或地址。数据从client端发送至server端,测量性能之后,在各端返回结果,之后终止client端和server端。例如,server端如下所示:

bsd2# ttcp -r -s

ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp

ttcp-r: socket

ttcp-r: accept from 205.153.60.247

ttcp-r: 16777216 bytes in 18.35 real seconds = 892.71 KB/sec +++

ttcp-r: 11483 I/O calls, msec/call = 1.64, calls/sec = 625.67

ttcp-r: 0.0user 0.9sys 0:18real 5% 15i+291d 176maxrss 0+2pf 11478+28csw

client端如下所示:

bsd1# ttcp -t -s 205.153.63.239

ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp  -> 205.153.63.239

ttcp-t: socket

ttcp-t: connect

ttcp-t: 16777216 bytes in 18.34 real seconds = 893.26 KB/sec +++

ttcp-t: 2048 I/O calls, msec/call = 9.17, calls/sec = 111.66

ttcp-t: 0.0user 0.5sys 0:18real 2% 16i+305d 176maxrss 0+2pf 3397+7csw

该程序报告中显示了信息传输总量,标识了连接的建立,并且给出了结果,包括raw datathroughputI/O call信息,执行时间。最有用的信息应该是transfer rate892.71 KB/sec (or 893.26 KB/sec)

这一数据反映了数据的传输速率,而不是链路的容量。将这一数据转化成带宽可能是有问题的,因为实际上传输了比这一值更多的比特数。这一程序显示18.35秒传送了16,777,216字节,但是这仅仅是数据。以太网报文封装还包括TCPIP,以太网报文头,估算容量时,需要把这些值加上去。

吞吐量低通常意味着拥塞,但也并不总是如此。吞吐量也会取决于配置问题,如连接的TCP窗口大小。如果窗口大小不足,会严重影响到性能。

(未完待续)

参考

Network Troubleshooting Tools

             

0 项奖励
ճС__
1 Copper

Re: 网络基本功系列:细说网络那些事儿(11月24日更新)

我对网络数据传输知识非常感兴趣,但是自己这方面的知识储备太少,您写的网络基本功系列非常棒,但是自己能明白的还是太少,能不能推荐几本入门级别的网络数据传输书籍?还有以后有关于这方面的问题如何像您请教?谢谢!

0 项奖励
Zhang_Jiawen
4 Beryllium

Re: 网络基本功系列:细说网络那些事儿(11月24日更新)

谢谢。其实前五章着重写的就是报文在网络中传播的详细过程,文章看着长内容是比较基本的,基本上没什么复杂的难点。之前也有网友让推荐书,介绍的是英文的看起来有点费劲,我稍后归纳整理一些中文书籍在这个帖子里推荐给大家。

ճС__
1 Copper

Re: 网络基本功系列:细说网络那些事儿(11月24日更新)

期待您的推荐!

0 项奖励
Zhang_Jiawen
4 Beryllium

Re: 网络基本功系列:细说网络那些事儿(11月24日更新)

网络基本功(十六):细说网络性能监测与实例(下)

转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese image001.gif

介绍

网络问题中,性能问题是最复杂的问题之一,解决这样的问题能够透彻的了解整个网络的结构。但通过合适的吞吐量和数据流测试工具,能够帮你快速找到问题所在。本文承接上文,阐述netperfnetstat的用法。


更多信息

吞吐量测量:

(承接上文)

netperf

该程序是由HP创造,该程序免费可用,运行于一些Unix平台,有支持文档,也被移植到Windows平台。虽然不像ttcp那样无处不在,但它的测试范围更加广泛。

ttcp不同,客户端和服务器端是分开的程序。服务器端是netserver,能够单独启动,或通过inetd启动。客户端是netperf。下例中,服务器和客户端启动于同一台机器:

bsd1# netserver

Starting netserver at port 12865

bsd1# netperf

TCP STREAM TEST to localhost : histogram

Recv   Send    Send

Socket Socket  Message  Elapsed

Size   Size    Size     Time     Throughput

bytes  bytes   bytes    secs.    10^6bits/sec

16384  16384  16384    10.00     326.10

测试的是loop-back接口,报告显示吞吐量为326Mbps

下例中,netserver启动于主机:

bsd1# netserver

Starting netserver at port 12865

netperf加上-H选项指定服务器地址:

bsd2# netperf -H 205.153.60.247

TCP STREAM TEST to 205.153.60.247 : histogram

Recv   Send    Send

Socket Socket  Message  Elapsed

Size   Size    Size     Time     Throughput

bytes  bytes   bytes    secs.    10^6bits/sec

16384  16384  16384    10.01       6.86

大致与ttcp所得出的吞吐量相同。netperf还进行了一些额外的测试。以下测试中,还计算了连接的transaction rate

bsd2# netperf -H 205.153.60.247 -tTCP_RR

TCP REQUEST/RESPONSE TEST to 205.153.60.247 : histogram

Local /Remote

Socket Size   Request  Resp.   Elapsed  Trans.

Send   Recv   Size     Size    Time     Rate

bytes  Bytes  bytes    bytes   secs.    per sec

16384  16384  1        1       10.00     655.84

16384  16384

该程序包含一些测试脚本。也可以使用netperf做各种流测试。

iperf

如果ttcpnetperf都不符合你的要求,那么可以考虑iperfiperf也可以用于测试UDP带宽,丢失率,和抖动。Java前端让该工具便于使用。该工具同样移植入windows

下例是运行iperf服务器端:

bsd2# iperf -s -p3000

------------------------------------------------------------

Server listening on TCP port 3000

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

[  4] local 172.16.2.236 port 3000 connected with 205.153.63.30 port 1133

[ ID] Interval       Transfer     Bandwidth

[  4]  0.0-10.0 sec   5.6 MBytes   4.5 Mbits/sec

^C

下例是在windows运行客户端:

C:\>iperf -c205.153.60.236

-p3000

------------------------------------------------------------

Client connecting to 205.153.60.236, TCP port 3000

TCP window size:  8.0 KByte (default)

------------------------------------------------------------

[ 28] local 205.153.63.30 port 1133 connected with 205.153.60.236 port 3000

[ ID] Interval       Transfer     Bandwidth

[ 28]  0.0-10.0 sec   5.6 MBytes   4.5 Mbits/sec

注意使用Ctrl-C来终止服务器端。在TCP模式下,iperf相当于ttcp,所以它可盈用户客户端或服务器。

在研究TCP窗口是否足够大时,使用iperf特别方便。-w选项设置socket buffer大小。对于TCP来说,这就是窗口大小。通过-w选项,用户可以单步调试各种窗口大小来看它们是怎样影响吞吐量的。

其他工具

你也许想要考虑一些相关或类似的工具。treno使用的方法类似于traceroute来计算块容量,路径MTU,以及最小RTP。如下例所示:

bsd2# treno 205.153.63.30

MTU=8166  MTU=4352  MTU=2002  MTU=1492 ..........

Replies were from sloan.lander.edu [205.153.63.30]

    Average rate: 3868.14 kbp/s (3380 pkts in + 42 lost = 1.2%) in 10.07 s

Equilibrium rate:      0 kbp/s (0 pkts in + 0 lost =   0%) in    0 s

Path properties: min RTT was  13.58 ms, path MTU was 1440 bytes

XXX Calibration checks are still under construction, use –v

通常来说,netperfiperftreno提供更加丰富的feature,但ttcp更加容易找到。

通过netstat进行流量测量:

在理想的网络环境下,如果把overhead算在内,吞吐量是很接近于带宽的。但是吞吐量往往低于期望值,这种情况下,你会想要知道差异在哪。如之前所提到的,可能与硬件或软件相关。但通常是由于网络上其他数据流的影响。如果你无法确定原因,下一步就是查看你网络上的数据流。

有三种基本方法可供采用。第一,最快的方法是使用如netstat这样的工具来查看链路行为。或通过抓包来查看数据流。最后,可使用基于SNMP的工具如ntop

要得到网络上数据流的快照,使用-i选项。举例来说:

bsd2# netstat -i

Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll

lp0*  1500  <Link>                               0     0        0     0     0

ep0   1500  <Link>      00.60.97.06.22.22 13971293     0  1223799     1     0

ep0   1500  205.153.63    bsd2            13971293     0  1223799     1     0

tun0* 1500  <Link>                               0     0        0     0     0

sl0*  552   <Link>                               0     0        0     0     0

ppp0* 1500  <Link>                               0     0        0     0     0

lo0   16384 <Link>                             234     0      234     0     0

lo0   16384 127           localhost            234     0      234     0     0

输出显示了自上一次重启以来,各接口所处理的报文数量。在本例中,接口ep0收到13,971,293个没有差错(Ierrs)的报文(Ipkts),发送了1,223,799 个报文(Opkts),有1个差错,没有冲突(Coll)。少量错误通常并不是造成告警的原因,但各错误所占比例应当是维持在较低水平,应该明显低于报文总量的0.1%。冲突可以稍微高一些,但应当少于数据流总量的10%。冲突数量仅包括那些影响接口的。较高数量的冲突喻示着网络负载较高,用户应当考虑分段。冲突只出现在特定媒介上。

如果你只想要单一接口的输出,可以通过-I选项指定,如:

bsd2# netstat -Iep0

Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll

ep0   1500  <Link>      00.60.97.06.22.22 13971838     0  1223818     1     0

ep0   1500  205.153.63    bsd2            13971838     0  1223818     1     0

随着实现的不同,输出可能看起来有些差异,但基本信息是一样的。例如,Linux平台的输出:

lnx1# netstat -i

Kernel Interface table

Iface   MTU Met    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg

eth0   1500   0  7366003      0      0      0    93092      0      0      0 BMRU

eth1   1500   0   289211      0      0      0    18581      0      0      0 BRU

lo     3924   0      123      0      0      0      123      0      0      0 LRU

如上例所示,Linux将丢失报文拆成三个目录:errors, drops,以及overruns

不方便的是,netstat的返回值是系统自上一次重启之后的累计值。我们真正关心的是这些数值最近是怎样变化的,因为问题是在发展的,在它增长到足以显现问题之前会花费相当长的时间。

有时你会对系统做一些压力测试来看错误是否增加,可以使用ping–I选项或spray命令。

首先,运行netstat来得到当前值:

bsd2# netstat -Iep0

Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll

ep0   1500  <Link>      00.60.97.06.22.22 13978296     0  1228137     1     0

ep0   1500  205.153.63    bsd2            13978296     0  1228137     1     0

接下来,发送大量报文到目的地址。本例中,发送了1000UDP报文:

bsd1# spray -c1000 205.153.63.239

sending 1000 packets of lnth 86 to 205.153.63.239 ...

        in 0.09 seconds elapsed time

        464 packets (46.40%) dropped

Sent:   11267 packets/sec, 946.3K bytes/sec

Rcvd:   6039 packets/sec, 507.2K bytes/sec

注意到该测试超出了网络容量,因为464个报文被丢弃了。这可能意味着网络拥塞。更加可能的是,主机正在尝试与一个慢速设备通信。当spray在相反方向运行时,没有报文丢弃。

最后,回到netstat来看看是否存在问题:

bsd2# netstat -Iep0

Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll

ep0   1500  <Link>      00.60.97.06.22.22 13978964     0  1228156     1     0

ep0   1500  205.153.63    bsd2            13978964     0  1228156     1     0

本例显示没有问题。

如果显示有问题,可以通过-s选项来得到。输出数据量可能有点吓人,但可以提供丰富的信息。信息按照协议和错误类型来分段,如bad checksum或报文头不完整。

在某些系统上,两次-s选项显示非零值的总和,如下所示:

bsd2# netstat -s -s

ip:

        255 total packets received

        255 packets for this host

        114 packets sent from this host

icmp:

        ICMP address mask responses are disabled

igmp:

tcp:

        107 packets sent

                81 data packets (8272 bytes)

                26 ack-only packets (25 delayed)

        140 packets received

                77 acks (for 8271 bytes)

                86 packets (153 bytes) received in-sequence

        1 connection accept

        1 connection established (including accepts)

        77 segments updated rtt (of 78 attempts)

        2 correct ACK header predictions

        62 correct data packet header predictions

udp:

        115 datagrams received

        108 broadcast/multicast datagrams dropped due to no socket

        7 delivered

        7 datagrams output

通过-p选项显示某一协议的汇总信息,下例显示TCP非零值的统计信息:

bsd2# netstat -p tcp -s -s

tcp:

        147 packets sent

                121 data packets (10513 bytes)

                26 ack-only packets (25 delayed)

        205 packets received

                116 acks (for 10512 bytes)

                122 packets (191 bytes) received in-sequence

        1 connection accept

        1 connection established (including accepts)

        116 segments updated rtt (of 117 attempts)

        2 correct ACK header predictions

        88 correct data packet header predictions

解释这一结果是需要一些经验的。一开始可以从大量错误信息开始看起。接下来,识别错误类型。通常,input error是由于硬件故障应期的。 Output error是由本地主机的问题造成。Data corruption,例如错误校验和,通常产生于服务器。冲突往往意味着网络拥塞。当然,这只是一般情况。

参考

Network Troubleshooting Tools

             

0 项奖励
Zhang_Jiawen
4 Beryllium

Re: 网络基本功系列:细说网络那些事儿(12月1日更新)

刚看到点击量破了个整数,谢谢大家来看这个帖子。欢迎大家在帖子里留言讨论,我会尽力回复~

Zhang_Jiawen
4 Beryllium

Re: 网络基本功系列:细说网络那些事儿(11月24日更新)

《计算机网络》 谢希仁编著。计算机的专业课本。

《TCP/IP 详解 卷一 》可以对网络中常用的协议有透彻地了解。

另外,思科的CCNA交换与路由也是相当不错的书。

0 项奖励