案例-抓包验证IOS BUG的案例.docxVIP

验证IOS Bug 问题描述：某电厂生产系统使用cisco3750堆叠交换机作为控制数据的转发交换机。在进行业务试运行时发现堆叠交换机的member 上联到cisco4500的端口出现数据间歇性转发的问题：从网管系统上看到该端口每10秒集中转发一次数据，而10秒空闲内没有任何数据包转发，10秒后将10秒内累积的所有数据包一次性转发，形成了明显的波状数据流。 网管人员登录到该交换机，查看该端口后发现该端口的进出流量数据包统计确实是每10秒钟统计一次。而电厂网管人员反映这种情况导致了其中一些处理交互数据的程控机的死机，导致一些业务的运行出现问题，必须尽快解决。 问题思考：电厂网管人员认为数据处理的程控机死机是因为这种间歇性转发造成的。10秒的流量积累下来，进行短时间内的瞬时转发，使得程控机无法处理大量的数据而造成死机。而管理人员确认，他们的数据交换应该是平滑的，每秒都会有数据，而且每秒钟的数据都相差不大，不会出现这种10秒的波峰现象。那么根据反映我们可以初步判断这个可能是一个IOS BUG。那么究竟是不是BUG呢，我们可以使用抓包来验证。看下数据包的流出和流入情况。 抓包验证：12/6日下午，在该电厂生产网络针对3750堆叠问题进行抓包分析。镜像3750 member的上联到cisco4500的端口。镜像采用全镜像，RX,TX三种方式进行抓包。 1. 首先在转发正常的master进行抓包，看其通信数据转发情况。抓包5分钟后，我们发现master的转发比较平滑，没有出现转发的中断和流量突发，如图为科来回溯分析系统看到的流量趋势图： 2. 在转发出现异常的member上 镜像 member上联到cisco4500端口 采集both流量。此时通过网管软件看到的该端口的转发是间歇性的转发，10秒钟一个峰值，而其他时间的流量为0。通过登录到交换机查看端口的out，in的流量统计也验证了网管软件看到的情况。因此该端口的转发情况存在明显的异常。 但通过抓包分析我们看到该端口的流量是平滑的，并未有流量的的波动。如图可以看到回溯分析的流量趋势图： 此后 又再次镜像该端口的 RX，TX流量。可以看到数据依然是平滑的。 （RX流量镜像趋势图） （TX流量趋势图） TX流量出现一些流量的峰值，经过时间对比，和网管人员确认，是正常现象。因为TX流量基线比较小，正常只有120Kbps，而峰值出现也没超过400kbps。而且并未出现流量为0的情况。 综上所述 我们看到无论采用哪种抓包方式，都可以看到流量是平滑的，没有出现过流量的波动较大的情况，而且没有出现流量转发中断的情况。与网管软件和SW端口看到的情况完全不一样。出现这种情况我们可以判断这种现象应该是一种bug。 交换机镜像技术本身是一门很底层的技术，在芯片级别实现的。在流量进出IOS处理之前就已经完成了流量的镜像。因此通过镜像我们可以看到流量在进出该端口的底层数据上是平滑的，与交换机的统计完全不一致，那么这种情况肯定是IOS的bug。 此外，本次抓包的流量本身比较怪异，流量没有单播数据。流量的转发全部为广播包，这种现象在网络中比较异常。经过询问得知，控制系统在设计的时候就采用的是全网广播的形式进行数据的交互，因此大量的广播包很正常。 事件处理：通过抓包验证了该版本的IOS的系统在处理全网广播的数据的时候会出现bug。后经过与cisco沟通，提交了抓包数据和现场情况描述，cisco确认这是一个 IOS的计数bug，即端口的统计数据包不是实时统计，而是10秒统计一次，而网管系统读取的是交换机的端口信息，那么同样会出现每10秒一次的波形图。 通过抓包了解到数据的转发是正常的，是平滑的，没有出现网管系统中的波形图。随后排除了流量过载影响程控机死机的可能性。至于程控机死机现象由什么引起，还需要网管人员进行其他排查方法。