我在企业网络踩过的坑：出口带宽限速策略的实战部署指南

大家好，我是33blog的运维老司机。今天想和大家聊聊企业网络管理中那个让人又爱又恨的话题——出口带宽限速。上周我们公司视频会议卡成PPT的惨案，让我不得不重新梳理了整套限速策略，这里把踩坑经验和解决方案都分享给大家。

为什么我们需要限速策略？

记得刚入职时，我觉得限速就是简单的”一刀切”。直到某天市场部全员直播时，财务部的ERP系统完全瘫痪…这才明白，合理的带宽分配就像交通管制，得让救护车(关键业务)优先通行。

常见的需求场景包括：

• 防止P2P下载拖垮全网
• 保障视频会议质量
• 避免某个部门独占带宽
• 满足等保合规要求

硬件方案：防火墙限速

我们公司用的是FortiGate防火墙，配置起来还算直观。分享个实际在用的配置片段：

config firewall shaper traffic-shaper
    edit "VIP_Limit"
        set maximum-bandwidth 20000  # 单位Kbps
        set priority medium
    next
end

config firewall shaper per-ip-shaper
    edit "User_Limit"
        set max-bandwidth 5000
    next
end

注意坑点：硬件厂商的带宽单位可能不同，有次我把Kbps当成Mbps配，结果全公司网速慢如蜗牛…

软件方案：Linux TC 流量控制

对于预算有限的公司，用Linux自带的TC工具是不错的选择。这是我为分公司写的限速脚本：

#!/bin/bash
# 限制eth0出口总带宽为100Mbps
tc qdisc add dev eth0 root handle 1: htb default 10
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit

# 为视频会议保留30%带宽
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 70mbit ceil 100mbit
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 30mbit ceil 30mbit

# 使用SFQ防止单个连接独占带宽
tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10

提醒：TC的学习曲线比较陡峭，建议先在测试环境练习。我当初把parent和handle的关系搞错，导致整个VPN隧道异常…

云服务商的带宽限制

现在很多企业业务上云，以AWS为例，可以通过以下方式控制出口流量：

1. 在EC2安全组设置出站规则限速
2. 使用NAT网关的带宽限制功能
3. 通过VPC终端节点策略控制

特别提醒：云服务的流量费用可能产生天价账单！我们曾有个开发环境忘记限速，一周跑了20TB流量…

我的限速策略设计心得

经过多次踩坑，总结出几个原则：

• 分层限速：先全局总限速，再按部门/应用细分
• 弹性预留：不要卡死上限，保留20%突发余量
• 监控调整：用Zabbix+Smokeping持续观察效果
• 白名单机制：CEO的电脑还是别限了(苦笑)

最后说句大实话：没有完美的限速方案，只有不断调整的策略。每次业务变更都可能打破原有平衡，这就是我们运维的日常啊！