对于云环境里，如果是租户私有资源，同一广播域里出现大量广播包也不会对其他租户产生影响，因为相互隔离，而对于flat网络比如外网来说，由于是公用资源，假如出现持续广播报文，那么对同一广播域里其它用户的使用就会带来影响，比如出现以下报文
23:17:50.701992 fa:17:00:00:00:0a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 1000: 117.127.137.234.9 > 0.0.0.0.9: UDP, length 958 23:17:50.751983 fa:17:00:00:00:0a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 1000: 117.127.137.234.9 > 0.0.0.0.9: UDP, length 958 23:17:50.801973 fa:17:00:00:00:0a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 1000: 117.127.137.234.9 > 0.0.0.0.9: UDP, length 958 23:17:50.852005 fa:17:00:00:00:0a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 1000: 117.127.137.234.9 > 0.0.0.0.9: UDP, length 958 23:17:50.901989 fa:17:00:00:00:0a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 1000: 117.127.137.234.9 > 0.0.0.0.9: UDP, length 958 23:17:50.951969 fa:17:00:00:00:0a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 1000: 117.127.137.234.9 > 0.0.0.0.9: UDP, length 958 23:17:51.002001 fa:17:00:00:00:0a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 1000: 117.127.137.234.9 > 0.0.0.0.9: UDP, length 958 23:17:51.052061 fa:17:00:00:00:0a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 1000: 117.127.137.234.9 > 0.0.0.0.9: UDP, length 958 23:17:51.102070 fa:17:00:00:00:0a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 1000: 117.127.137.234.9 > 0.0.0.0.9: UDP, length 958 23:17:51.152042 fa:17:00:00:00:0a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 1000: 117.127.137.234.9 > 0.0.0.0.9: UDP, length 958 23:17:51.202019 fa:17:00:00:00:0a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 1000: 117.127.137.234.9 > 0.0.0.0.9: UDP, length 958 23:17:51.252029 fa:17:00:00:00:0a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 1000: 117.127.137.234.9 > 0.0.0.0.9: UDP, length 958 23:17:51.302033 fa:17:00:00:00:0a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 1000: 117.127.137.234.9 > 0.0.0.0.9: UDP, length 958 23:17:51.352061 fa:17:00:00:00:0a > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 1000: 117.127.137.234.9 > 0.0.0.0.9: UDP, length 958
此时假如234这个主机提高发包速度，那么就将对其它主机的网络带宽造成很大的影响，因此要对这种行为进行限速，减少攻击行为
这里的做法可以在TAP设备上对broadcast和multicase报文进行rate limiting
这里限速100kb/s，发包的速率如果超过了这个限制，TAP设备这里TC规则将超过的部分丢掉，使得广播报文速度达到稳定可控
这里可以做下简单的测试，验证限速正确性，比如就用pktgen来发平均包长1000B的广播包，最好发包速度超过限定rate一倍，这样容易观察
测试数据：
ave pkt length：1000B
pps：20pkt/s
这样每秒的数据：1000 * 8 * 20 = 160kb > 100kb（废话）
或者这么看，每秒20个包，因此每秒超出被丢掉的有：（1000 * 20 * 8 – 100kb）/1000/8 = 8~10pps
下面通过pktgen来进行验证，每秒20个包，设置好delay，这里单位是10^-9秒，因此这里应该是50 000 000
基本如下：
#!/bin/bash echo "rem_device_all" > /proc/net/pktgen/kpktgend_0 echo "add_device eth1" > /proc/net/pktgen/kpktgend_0 echo "pkt_size 1000" > /proc/net/pktgen/eth1 echo "count 100000000000" > /proc/net/pktgen/eth1 echo "delay 50000000" > /proc/net/pktgen/eth1 echo "src 117.127.137.234" > /proc/net/pktgen/eth1 echo "dst_mac ff:ff:ff:ff:ff:ff" > /proc/net/pktgen/eth1 echo "start" > /proc/net/pktgen/pgctrl
直接进行发送广播包，然后再节点机上监控流量，分别带上TAP设备和外网出口
######################################################################################################################## 2016-12-12 00:02:03tap47d59ad5-22| rx bps: 156.2 K bits/s | rx packets: 20.0 pkts/s | rx dropped: 0.0 pkts/s 2016-12-12 00:02:03tap47d59ad5-22| tx bps: 3.5 K bits/s | tx packets: 8.0 pkts/s | tx dropped: 0.0 pkts/s 2016-12-12 00:02:03 eth2 | rx bps: 28.8 K bits/s | rx packets: 49.0 pkts/s | rx dropped: 0.0 pkts/s 2016-12-12 00:02:03 eth2 | tx bps: 100.0 K bits/s | tx packets: 25.0 pkts/s | tx dropped: 0.0 pkts/s ######################################################################################################################## 2016-12-12 00:02:04tap47d59ad5-22| rx bps: 156.2 K bits/s | rx packets: 20.0 pkts/s | rx dropped: 0.0 pkts/s 2016-12-12 00:02:04tap47d59ad5-22| tx bps: 5.8 K bits/s | tx packets: 13.0 pkts/s | tx dropped: 0.0 pkts/s 2016-12-12 00:02:04 eth2 | rx bps: 19.8 K bits/s | rx packets: 36.0 pkts/s | rx dropped: 0.0 pkts/s 2016-12-12 00:02:04 eth2 | tx bps: 92.9 K bits/s | tx packets: 19.0 pkts/s | tx dropped: 0.0 pkts/s ######################################################################################################################## 2016-12-12 00:02:05tap47d59ad5-22| rx bps: 156.2 K bits/s | rx packets: 20.0 pkts/s | rx dropped: 0.0 pkts/s 2016-12-12 00:02:05tap47d59ad5-22| tx bps: 3.1 K bits/s | tx packets: 7.0 pkts/s | tx dropped: 0.0 pkts/s 2016-12-12 00:02:05 eth2 | rx bps: 21.5 K bits/s | rx packets: 38.0 pkts/s | rx dropped: 0.0 pkts/s 2016-12-12 00:02:05 eth2 | tx bps: 100.3 K bits/s | tx packets: 24.0 pkts/s | tx dropped: 0.0 pkts/s ######################################################################################################################## 2016-12-12 00:02:06tap47d59ad5-22| rx bps: 156.2 K bits/s | rx packets: 20.0 pkts/s | rx dropped: 0.0 pkts/s 2016-12-12 00:02:06tap47d59ad5-22| tx bps: 3.0 K bits/s | tx packets: 7.0 pkts/s | tx dropped: 0.0 pkts/s 2016-12-12 00:02:06 eth2 | rx bps: 19.8 K bits/s | rx packets: 35.0 pkts/s | rx dropped: 0.0 pkts/s 2016-12-12 00:02:06 eth2 | tx bps: 101.7 K bits/s | tx packets: 24.0 pkts/s | tx dropped: 0.0 pkts/s ########################################################################################################################
这里可以看到TAP设备每秒包数是对的，20pps，但是流量却比限速100K bps大，原因是抓包在规则限制之前，因此从下面eth2可以看到，限速之后的流量的确在100K bps左右
顺便查看下TAP设备丢包情况，是否与上面预期相符
直接通过TC命令查看TAP设备丢包情况
#!/bin/bash
while true; do
/sbin/tc -s filter show dev tap47d59ad5-22 parent ffff: | grep dropped | sed -n "1p"
sleep 1
done
执行结果，每秒丢10个包左右，符合预期
~$ sh drop.sh Sent 114594048 bytes 84422 pkt (dropped 66752, overlimits 66752 requeues 0) Sent 114594048 bytes 84422 pkt (dropped 66752, overlimits 66752 requeues 0) Sent 114594048 bytes 84422 pkt (dropped 66752, overlimits 66752 requeues 0) Sent 114594048 bytes 84422 pkt (dropped 66752, overlimits 66752 requeues 0) Sent 114594048 bytes 84422 pkt (dropped 66752, overlimits 66752 requeues 0) Sent 114604288 bytes 84430 pkt (dropped 66752, overlimits 66752 requeues 0) Sent 114631168 bytes 84451 pkt (dropped 66752, overlimits 66752 requeues 0) Sent 114656768 bytes 84471 pkt (dropped 66752, overlimits 66752 requeues 0) Sent 114682368 bytes 84491 pkt (dropped 66752, overlimits 66752 requeues 0) Sent 114707968 bytes 84511 pkt (dropped 66752, overlimits 66752 requeues 0) Sent 114733568 bytes 84531 pkt (dropped 66758, overlimits 66758 requeues 0) Sent 114759168 bytes 84551 pkt (dropped 66768, overlimits 66768 requeues 0) Sent 114784768 bytes 84571 pkt (dropped 66778, overlimits 66778 requeues 0) Sent 114810368 bytes 84591 pkt (dropped 66788, overlimits 66788 requeues 0) Sent 114835968 bytes 84611 pkt (dropped 66798, overlimits 66798 requeues 0) Sent 114861568 bytes 84631 pkt (dropped 66808, overlimits 66808 requeues 0) Sent 114887168 bytes 84651 pkt (dropped 66818, overlimits 66818 requeues 0) Sent 114914048 bytes 84672 pkt (dropped 66828, overlimits 66828 requeues 0) Sent 114939648 bytes 84692 pkt (dropped 66838, overlimits 66838 requeues 0) Sent 114965248 bytes 84712 pkt (dropped 66848, overlimits 66848 requeues 0) Sent 114990848 bytes 84732 pkt (dropped 66858, overlimits 66858 requeues 0) Sent 115016448 bytes 84752 pkt (dropped 66868, overlimits 66868 requeues 0) Sent 115035648 bytes 84767 pkt (dropped 66876, overlimits 66876 requeues 0) Sent 115035648 bytes 84767 pkt (dropped 66876, overlimits 66876 requeues 0)
