无需索引
本文来自网络
tcpdump 命令语法
tcpdump 采用命令行方式，它的命令格式为：
tcpdump [-选项] [表达式]
tcpdump 的常见选项介绍 (tcpdump --help)
-d 将匹配信息包的代码以编译后人们能够理解的格式给出；
-dd 将匹配信息包的代码以c语言程序段的格式给出；
-ddd 将匹配信息包的代码以十进制的形式给出；
-e 打印出数据链路层的头部信息；
-f 将外部的Internet地址以数字的形式打印出来；
-n 不把网络地址转换成名字；
-t 在输出的每一行不打印时间戳；
-v 输出一个稍微详细的信息，例如在ip包中可以包括ttl和服务类型的信息；
-vv 输出详细的报文信息；
-c 在收到指定的包的数目后，tcpdump就会停止；
-F 从指定的文件中读取表达式,忽略其它的表达式；
-i 指定监听的网络接口；
-r 从指定的文件中读取包(这些包一般通过-w选项产生)；
-w 直接将包写入文件中，并不分析和打印出来；
-T 将监听到的包直接解释为指定的类型的报文，常见的类型有rpc和snmp
tcpdump 表达式介绍
表达式是一个正则表达式，tcpdump 利用它作为过滤报文的条件，如果一个报文满足表达式的条件，则这个报文将会被捕获。如果没有给出任何条件，则网络上所有的信息包将会被截获。
在表达式中一般如下几种类型的关键字。
第一种是关于类型的关键字，主要包括 host, net, port。例如 host 210.27.48.2，指明 210.27.48.2 是一台主机，net 202.0.0.0 指明 202.0.0.0 是一个网络地址，port 23 指明端口号是 23。如果没有指定类型，缺省的类型是host。
第二种是确定传输方向的关键字，主要包括src, dst, dst or src, dst and src。这些关键字指明了传输的方向。举例说明，src 210.27.48.2，指明 ip 包中源地址是 210.27.48.2，dst net 202.0.0.0 指明目的网络地址是 202.0.0.0。如果没有指明方向关键字，则缺省是 src or dst 关键字。
第三种是协议的关键字，主要包括 fddi, ip ,arp, rarp, tcp, udp 等类型。fddi 指明是在 FDDI(分布式光纤数据接口网络)上的特定的网络协议，实际上它是 "ether" 的别名，fddi 和 ether 具有类似的源地址和目的地址，所以可以将 fddi 协议包当作 ether 的包进行处理和分析。其他的几个关键字就是指明了监听的包的协议内容。如果没有指定任何协议，则 tcpdump 将会监听所有协议的信息包。
除了这三种类型的关键字之外，其他重要的关键字如下：gateway, broadcast, less, greater。
还有三种逻辑运算，非运算是 'not', '!'; 与运算是'and', '&&'; 或运算是'or', '||’。
tcpdump数据包过滤实例
(1)抓取成 Wireshark 能识别的文件
#tcpdump -i en8 host 10.103.0.13 -w ecif.pcap
#tcpdump -i en8 -w cbs.pcap(2)截获主机210.27.48.1收到和发出的所有的数据包：
#tcpdump host 210.27.48.1(3) 截获主机210.27.48.1和主机210.27.48.2或210.27.48.3的通信：
#tcpdump host 210.27.48.1 and \(210.27.48.2 or 210.27.48.3 \)(4)获取主机210.27.48.1除了和主机210.27.48.2之外所有主机通信的ip包
#tcpdump ip host 210.27.48.1 and !210.27.48.2(5)获取主机210.27.48.1接收或发出的smtp包：
#tcpdump tcp port 25 and host 210.27.48.1(6)如果怀疑系统正受到拒绝服务(DoS)攻击,网络管理员可以通过截获发往本机的所有ICMP包,来确实目前是否有大量的ping指令流向服务器:
#tcpmdump -n -i eth0 icmptcpdump 的输出结果介绍
下面我们介绍几种典型的tcpdump命令的输出信息。
(1)数据链路层头信息
ice是一台装有linux的主机，MAC地址是0:90:27:58:af:1a；
h219是一台装有SOLARIC的SUN工作站，MAC地址是8:0:20:79:5b:46；
#tcpdump -e host ice
21:50:12.847509 eth0 < 8:0:20:79:5b:46 0:90:27:58:af:1a ip 60: h219.33357 > ice. telnet 0:0(0) ack 22535 win 8760 (DF)
分析：
21:50:12 显示的时间
847509 ID号
eth0 < 表示从网络接口eth0接受该数据包
eth0 > 表示从网络接口eth0发送该数据包
8:0:20:79:5b:46 主机h219的MAC地址,它表明是从源地址H219发来的数据包
0:90:27:58:af:1a 主机ice的MAC地址,表示该数据包的目的地址是ice
ip 表明该数据包是IP数据包
60 数据包的长度
h219.33357 > ice.telnet 表明该数据包是从主机h219的33357端口发往主机ice的TELNET(23)端口
ack 22535 表明对序列号是222535的包进行响应
win 8760 表明发送窗口的大小是8760(2)ARP包的TCPDUMP输出信息
#tcpdump arp
22:32:42.802509 eth0 > arp who-has route tell ice (0:90:27:58:af:1a)
22:32:42.802902 eth0 < arp reply route is-at 0:90:27:12:10:66 (0:90:27:58:af:1a)
分析:
22:32:42 时间戳
802509 ID号
eth0 > 表明从主机发出该数据包
arp 表明是ARP请求包
who-has route tell ice 表明是主机ICE请求主机ROUTE的MAC地址。 (3) TCP包的输出信息
用TCPDUMP捕获的TCP包的一般输出信息是:
src > dst: flags data-seqno ack window urgent options
src > dst 表明从源地址到目的地址,
flags 是TCP包中的标志信息,S 是SYN标志, F (FIN), P (PUSH) , R (RST) "." (没有标记),
data-seqno 是数据包中的数据的顺序号,
ack 是下次期望的顺序号,
window 是接收缓存的窗口大小,
urgent 表明数据包中是否有紧急指针,
Options 是选项.(4) UDP包的输出信息
用TCPDUMP捕获的UDP包的一般输出信息是：
route.port1 > ice.port2: udp lenth
UDP十分简单，这儿表明从主机ROUTE的port1端口发出的一个到主机ICE的port2端口的数据包，类型是UDP，包的长度是lenth案例分析
在管理实践中，灵活运用tcpdump这个管理工具可以帮助我们解决不少问题。
1).邮件服务器的网络故障分析
对干管理员来说，邮件服务器是一个很容易出现问题的管理对象。我们来看看一个比较典型的故障现象。
在某单位的局域网内有一台邮件服务器，邮件服务器收发邮件等基本功能正常，但在使用中发现一个普遍的怪现象：在PC机上发邮件时，连接邮件服务器后，要等待很长时间才能开始工作。从检测来看，网络连接没有问题，邮件服务器和PC性能都没有问题，问题可能出在哪里呢？
为了查找问题的所在，可以采用以下的测试方法。
首先，我们在PC机上发送邮件， 同时在邮件服务器上使用tcpdump对这个Client的数据包进行捕获分析，如下：
server# tcpdump host client
tcpdump: listening on hme0
23:41:30.040578 client.1065 ＞ server.smtp: S 1087965815:1087965815(0) win 64240 (DF)
23:41:30.040613 server.smtp ＞ client.1065: S 99285900:99285900(0) ack 1087965816 win 10136 (DF)
23:41:30.040960 client.1065 ＞ server.smtp: . ack 1 win 64240 (DF)然后，通过分析数据，我们看到双方顺利的完成了会话。也就是说，到目前为止，整个状态正常。
沿着这个思路，我们往下看。
23:41:30.048862 server.33152 ＞ client.113: S 99370916:99370916(0) win 8760 (DF)
23:41:33.411006 server.33152 ＞ client.113: S 99370916:99370916(0) win 8760 (DF)
23:41:40.161052 server.33152 ＞ client.113: S 99370916:99370916(0) win 8760 (DF)
23:41:56.061130 server.33152 ＞ client.113: R 99370917:99370917(0) win 8760 (DF)
23:41:56.070108 server.smtp ＞ client.1065: P 1:109(108) ack 1 win 10136 (DF)通过分析 我们就可以判断问题所在了。原来，问题在于我们看Server端试图连接Client的113 端口，要求认证，然而没有收到Client端的回应，Server端重复尝试了3 次，费时26 秒后才放弃认证请求，并主动发送了reset标志的数据包。开始push后面的数据，而正是在这个过程中所花费的26秒时间造成了发送邮件时漫长的等待情况。
问题找到了就可以修改了，我们通过修改服务器端的qmail配置。使它不再进行113端口的认证。经过修改，再次测试，看到邮件服务器不再进行113端口的认证尝试。而是在三次检测后直接push数据，问题得到完美的解决。
2.)ARP协议网络故障
ARP的全称是地址解析协议，在局域网中，网络中实际传输的是“帧”。帧里面是有目标主机的MAC地址的。在以太网中，一个主机要和另一个主机进行直接通信必须要知道目标主机的MAC地址，但这个目标MAC地址是如何获得的呢？它就是通过地址解析协议来获取的。所谓地址解析，就是主机在发送帧前将目标IP地址转换成目标MAC地址的过程。ARP协议的基本功能就是通过目标设备的IP地址查询目标设备的MAC地址以保证通信的顺利进行。
下面，我们来看一个ARP协议的故障现象，局域网中，有一台采用Solaris操作系统的服务器BSERVER。现在网络连接不正常，从任意主机上都无法ping通该服务器。出现故障后，首先检查系统，发现系统本身工作正常，没有特殊进程运行。CPU内存利用率正常。无挂接任何形式的防火墙，网线也正常。问题在哪里呢？我们借助tcpdump来进行故障定位。
首先我们将从B-CLIENT主机上执行ping命令，发送icmp数据包给B-SERVER，如下
[root@B-CLIENT log]# ping B-SERVER
PING A-SERVER from B-CLIENT : 56(84) bytes of data.此时在B-SERVER启动tcpdump，对来自主机B-CLIENT的数据包进行捕获
B-SERVER# tcpdump host B-CLIENT
tcpdump: listening on hme0
16:32:32.611251 arp who-has B-SERVER tell B-CLIENT
16:32:33.611425 arp who-has B-SERVER tell B-CLIENT
16:32:34.611623 arp who-has B-SERVER tell B-CLIENT我们看到，没有收到预料中的ICMP报文。反而捕获到了B-CLIENT发送的arp广播包。由于主机B-CLIENT无法利用arp得到服务器B-SERVER的地址，因此反复询问B-SERVER的MAC地址。由此看来，高层出问题的可能性不大，很可能在链路层有些问题，先来查查主机B-SERVER的arp表
B-SERVER# arp -a
Net to Media Table
Device IP Address Mask Flags Phys Addr
------ -------------------- --------------- ----- ---------------
hme0 netgate 255.255.255.255 00:90:6d:f2:24:00
hme0 B-SERVER 255.255.255.255 S 00:03:ba:08:b2:83
hme0 BASE-ADDRESS.MCAST.NET 240.0.0.0 SM 01:00:5e:00:00:00请注意BSERVER的Flags位置，我们看到了只有S标志。我们知道，solaris操作系统在arp实现中，arp的Flags需要设置P标志，才能响应ARP requests。手工增加p位
B-SERVER# arp -s B-SERVER 00:03:ba:08:b2:83 pub此时再调用arp -a看看
A-SERVER# arp -a
Net to Media Table
Device IP Address Mask Flags Phys Addr
------ -------------------- --------------- ----- ---------------
hme0 netgate 255.255.255.255 00:90:6d:f2:24:00
hme0 A-SERVER 255.255.255.255 SP 00:03:ba:08:b2:83
hme0 BASE-ADDRESS.MCAST.NET 240.0.0.0 SM 01:00:5e:00:00:00我们看到本机已经有了SP标志，此时再测试系统的网络连接恢复正常，问题得到解决。
3.)流量软件的网络故障分析
Cisco路由和交换平台中的NetFlow服务可提供内置在快速、最优和CEF交换路径之中的网络数据流统计功能。NetFlow服务可利用网络中数据流创造价值，并可在最大限度减小对路由器／交换机性能的影响的前提下，提供详细的数据流统计信息。特别是作为其交换功能的一部分，它能够为企业提供网络的容量规划、趋势分析以及数据优先级等方面的信息。这些统计信息包括用户、协议、 端口和服务类型等。
先看故障现象：在新装的网管工作站上安装Cisco NetFlow软件对路由设备流量等进行分析， 路由器按照要求配置完毕，本地工作上软件安装正常。没有报错的信息，但启动NetFlow后，却收不到任何路由器上发出的流量信息，导致该软件失效。排除过程中，反复检查路由和软件，配置无误。
采用逐步分析的方法。首先先要定位出有问题的设备，是路由器根本没有发送流量信息还是本地系统接收出现了问题。突然想到在路由器上我们定义了接收的Cient端由UDP端口9995接收数据,可以通过监视这个端口来看路由器是否确实发送了UDP数据。如果系统能够接收到来自路由的数据包，那么路由方面的问题可能行不大，反之亦然。
现在，在网管工作站上使用tcpdump来看看
nms#tcpdump port 9995
tcpdump: listening on hme0
18:15:34.373435 routea ＞ nms.9995: udp 1464
18:15:34.373829 routea.50111 ＞ nms.9995: udp 1464
18:15:34.374100 routea.50111 ＞ nms.9995: udp 1464现在，我们就可以看到数据包确实从路由器上发过来了，问题出在路由器的可能性基本排除。 重新核查系统。果然，网营工作站上安装了防火墙，UDP端口9995是被屏蔽的，调整工作站上的防火墙配置,NetFlow工作恢复正常，故障得排除。
通过这些例子，我们不难发现，用好tcpdmmp这样的包分析软件配台其它的管理工具对系统管理员快速准确定位网络故障、分析网络问题有不可替代的作用。在市场上销售的专用网络分析设备虽然功能强大但价格昂贵，没有相当的说服力，很难通过单位管理层的批准，而且操作也不一定方便。通过熟悉本文所介绍的tcpdump并掌握其中的一些技巧，网络管理员就可以很轻松对复杂网络进行管理了。
