案例1：用户在业务高峰期无法访问3g portal
分析过程：
流量负载与突发流量、包尺寸均无异常。
TCP连接中大量是通过TCP RST结束连接；根据三次握手分析服务器端到捕获端、客户端到捕获端的RTT，web portal端时延小，排除服务器导致连接失败；查看RST的时延，判断为出口路由器的故障。结论：路由器bug。
案例2：无法发送大附件邮件
分析过程：
抓包发现重传很多，90s后，邮件服务器认定连接异常，发送重置数据包；
分别在防火墙和路由器后端进行抓包，界定为路由器问题；
原因：网络中存在GRE通道，用于SMTP。GRE需要24字节的额外负载，原来1500byte的负荷变成了1524，而路由器的缺省MTU为1500，且本网络中SMTP不准分片，因此丢弃。
解决方案：1、取消GRE通道配置；2、修改GRE通道的MTU，使其保证能通过1518byte的数据包；3、SMTP服务器设置为准许邮件数据包分片。
案例3：ping大包丢包
分析过程：网络拓扑为光纤相连，中间设备只有光电转换器。分析时在光电转换器与路由器之间串联一个交换机，利用交换机的端口镜像功能。
原因：大包超过MTU，分片，中途丢包，导致数据包重组超时。
案例4：LIMS系统导致ERP系统缓慢
分析过程：在服务器与接入交换机之间串入hub，接入分析工具抓包，发现有几次连接过程，且最后一次的响应时间太慢。TCP急迫位被置为1，导致ERP系统打破了处理调度顺序，ERP资源不足时演变为故障。
解决方案：修改LIMS端的应用层控制。
案例5：无法访问总部的网站，网页打不开，但ping ok，且除了该网段地址外，其他网段都访问OK。
分析过程：ping ok，因此连通性无问题，可能是中间设备未转发请求的数据包导致包丢失从而连接失败。用防火墙内置的抓包功能看到防火墙的端口转发数据OK，但回应的端口由80变成了135，确定故障应是防火墙前段的设备。
结论：加速器的加速功能开启时访问异常，加速功能关闭时访问OK。
案例6：不定时出现网络延迟故障。
分析过程：抓包分析流量并不大，但某时有突发流量，且均为UDP协议，大小均为固定的112字节，经查源主机感染蠕虫病毒。
案例7：VOIP通信受干扰，有爆音和背噪
分析过程：抓包显示呼叫的建立和拆除信令完整。有声音，因此RTP包没有被丢弃（RTP封装在UDP包中）。抓包观察ping延迟的差异，平均抖动基本平稳，不会影响通话质量。VOIP属于实时应用，要求数据尽力快速传输，未采取重传和防伪造机制。但抓包发现有IPID值相同且按规律出现的数据包。
结论：运营商插入了用于干扰的RTP包，产生爆音和背噪，影响通话质量。由于RTP包具有明显的特征，可以在网络边界设备上识别和过滤；也可以在PBX上使用NDIS驱动过滤。
案例8：网络通讯阻塞，访问网络速度缓慢，ping网关偶有中断
分析过程 ：登陆交换机查看CPU和内存利用率，均正常。在核心上做镜像抓包，短时间内有大量TCP connection refused包，定位发现有感染病毒的主机。后再抓包，设置网关IP为过滤条件，发现两个不同MAC。但核心交换机到网关再无其他设备，因此排查为有计算机错误设置为了网关的IP。
案例9：网络丢包分析
造成丢包的主要原因：硬件故障（网卡、端口故障）、软件故障（错误的静态路由、主机默认网关配置错误）、网络拥塞（带宽过小或存在异常流量时，如ARP攻击/P2P等）、MTU配置不当（以太网：1500字节、IEEE 802.3/802.2 1492字节）。
排查方法：分段捕获。推荐利用率不高于15%，网络利用率高于30%时，就会产生1%的丢包。
案例10：瘦客户端故障
案例11：防火墙阻挡ospf组播协议包
结果：核心和路由器上开启了OSPF，但ospf协议寻找动态邻居时，需要以组播方式向网络发hello包，但硬件防火墙默认状态不容许组播数据包通过，会阻碍核心从路由器学到动态路由。配置合适的访问规则后，访问OK。