最近有时间，并且陆续又有人报告网络存在问题，于是又开始继续折腾这个问题。


抛开错包的问题不谈，来看一下广播流量是怎么产生的。

一开始的假设是某个或某些地址不停地进行全网扫描造成的。这可以解释为什么新建一个网段并没有出现错包增多的情况。按照这个思路来理解，这个发出扫描地址一定能够访问到这个网关的地址才可以。

根据防火墙的规则，我可以把这个范围缩小，在这个范围内抓包就可以定位到问题源头。

我决定在交换机管理网段抓包来证明我这个猜测的理论。因为能够访问这个网段的地址并不多，如果确实没什么流量，就证明了我的假设可能是正确的。

另外，由于交换机管理网段vlan是基本上所有交换机的公共vlan，在大范围内出现广播问题的时候，这是第一个满足特征的vlan。


抓包的结果让我吃惊，交换机管理网段存在着大量的arp包。wireshark统计，每秒钟在400多个arp。

再仔细观察，发现这部分arp主要分为两种，一种是gratuitous arp，另外一种是对全网扫描的arp包。每秒钟都会扫几轮。这些发出扫描的arp包的源地址有一个共同特点，就是他们都来自新采购的h3c 3100v2-ei交换机。

只好打h3c的售后咨询一下这是什么情况。

h3c的工程师的答复是可能是stp tc引起的arp表清除导致的。

我感到很奇怪，因为标准的stp协议在收到tc报文后，为了防止产生环路，应该清除的是端口下的mac地址缓存，而不是arp表。清除arp表这种行为从原理角度上来讲并没有意义，stp是一个纯粹的二层协议。

不过不管怎样，我还是决定试一下，我把stp 协议关掉，看看是不是有改善。

果然，扫描停止了。

于是我又联系h3c的工程师问问究竟是怎么回事。

得到的答复是在3100v2里面，arp表的数据结构里面含有端口信息，因此拓扑改变一定要清除arp表。我猜测这也是为了优化三层向二层的转发速度所采取的一种方法。

靠，原来如此。

一般来说，这样并不符合数据库设计第三范式，会有不少数据冗余。不说这个，按照这个做法，对于一个有n台设备的网络，只要其中一个设备产生一个tc报文，那么对于剩余的每台设备都会产生n-1条arp request，总计流量是(n-1)^2，也就是说报文数量对于网络规模呈平方增长。 假设这个网络内有101台设备，（这是一个不算过分的值）就是会产生10000条的广播流量，每条60bytes，就是每个端口600kByte的流量。如果tc报文数量增长，报文总数也会随之呈线性增长。这样设计真的没问题么？

好在h3c里面还有tc-protection功能，可以限制刷新的次数。本来这是我们的默认配置，这批新货可能疏忽了，有些并没有配置上。同时根据核心上的tc 报文接受数排序，对整个网络进行了一次检查，把边缘端口都加上去了。

交换机管理网段的广播问题得到了遏制。

下一步，要追踪用户抱怨地比较多的网段的问题。。