交换机block unicast机制

一直以来在一个典型的交换三角网络内，存在这样的一个问题：一台没有接入任何一台服务器二层交换机的两个uplink口的RX方向上竟然存在很大的流量。通过在此交换机上抓这两个uplink口的数据包，发现存在很多unicast的包。而从三层交换机上面通过查找arp表和mac表后证明这些数据包不应该会下发到此交换机上。此问题查找了很久都没有找到原因。今天在某朋友的提示下，查看了block-unicast的命令解释。

Understanding How Unicast Flood Blocking Works

You can enable unicast flood blocking on any Ethernet port on a per-port basis. Unicast flood blocking provides you the option to drop the unicast flood packets on an Ethernet port that has only one host that is connected to the port. All the Ethernet ports on a switch are configured to allow unicast flooding; unicast flood blocking allows you to drop the unicast flood packets before they reach the port.

Caution You must have a static CAM entry that is associated with the Ethernet port before you enable unicast flood blocking. If you do not have a static CAM entry that is associated with the port, you will lose network connectivity if you enable unicast flood blocking. You can verify that a static CAM entry exists by entering the show cam static command.

---摘自

反正此二层交换机下面没有接服务器，于是便在三层交换机的下联此二层交换机的端口上启用了命令：switch block unicast。然后查看二层交换机的端口速率变化，发现很快速率就降到了300K左右，效果非常明显。呵呵，虽然没有从根本上解决上面描述的流量异常转发现象。

然后我通过在此二层交换机下面接入一台服务器（ip=1.1.1.1）来测试启用block-unicast特性的效果。

1，在没有启用block-unicast特性时，在远端长ping 1.1.1.1，然后在三层交换机上面清除此服务器的mac表项，发现根本没有任何丢包；

2，在启用了block-unicast特性后，在远端长ping 1.1.1.1，然后在三层交换机上面清除此服务器的mac表项，发现time-out了，大概丢包15个。

下面来分析一下原因，也即block-unicast特性的处理机制：在端口A上启用了此特性后，所有发给端口A的数据包都要查看一下端口A的相关mac表项，如果此表项有数据包的目的mac地址，就进行转发；否则丢弃。直到此mac相关的arp表项超时，进行arp洪泛后，交换机学习此mac入mac表，才能通信。

总结：在生产网络上，需要谨慎使用此特性，一般不启用，默认也是不启用。