交换机端口限速实战：从令牌桶原理到配置排查

先坦白讲，我折腾交换机少说也有七八年了，但真正让我把“端口限速”彻底吃透的，不是哪一本官方手册，而是一次让整个办公室都炸毛的周一早晨：某部门几台机器同时拉下载，语音网关和视频会议全部掉线。我当时的第一反应是链路拥塞，结果一查核心交换机，发现根本没有任何限速策略——接入层那几台设备对上行流量完全放养。从那天起我就认了一个理：端口限速不是“网管给自己加戏”，而是多租户、多业务混跑场景下最基础也最有效的带宽治理手段。所以这篇专题，我想把端口限速从概念到部署再到排查，完完整整讲一遍，适合刚上手网管端口配置的运维新人，也适合需要给园区网做带宽规划的集成商朋友参考。

1. 先搞明白端口限速到底限的是什么

1.1 从一次断网事故理解限速的“边界”

先回到开头那个场景。某公司有两条办公网专线，一条给办公用户，一条给视频会议和语音。周一一早，行政部有台电脑挂着下载工具跑了一整夜，把接入交换机到汇聚交换机之间的那条千兆链路直接吃满。视频会议终端虽然在同一台接入交换机上，但它的流量要和下载流量挤同一条链路，结果就是音频断断续续、画面模糊得像马赛克。

问题的根源不是带宽本身不够，而是没有在接入层把不同业务的流量“隔开”。端口限速做的正是这件事：它把一个物理端口能通过的流量限制在一个预设速率以内，超过部分要么丢弃、要么缓存、要么标记后降级处理。这等同于在每个房间门口装了独立水表——每个房间可以同时用水，但任何一个房间都不能把总水管的水全部抽走。你限的不是“某台电脑能不能上网”，而是“这个端口最多能占用多少链路资源”。

1.2 入方向和出方向：限速必须分清楚的两个维度

端口限速的第一个陷阱，就是方向。交换机的每个端口都有两个独立的方向：

• 出方向（Egress）：从交换机这个端口发出去的数据，比如接入交换机向终端电脑转发数据。
• 入方向（Ingress）：从外部收进来的数据，比如终端电脑上传到交换机。

绝大多数场景下，我们需要限制的是出方向。比如限制某个下载服务，真正占用带宽的是交换机向客户端方向推送的数据；但如果要控制一堆摄像头同时向视频平台推流，那就要限制入方向的带宽，因为推流是摄像头往交换机方向灌数据。

有些新手在做端口限速时只在下发策略里填了一个速率，也不管方向，结果限了个寂寞。我在给某园区做改造时就遇到过：接入交换机限制了下行速率，但用户看视频走的是上行链路，测速依然跑满，最后排查才发现两头方向写反了。

1.3 Mbps、MB/s与“真实速率”的换算

另一个高频坑是单位。端口限速配置里的单位通常是 Mbps（兆比特每秒），但应用层和测速工具显示的是 MB/s（兆字节每秒），两者相差8倍。比如你想把某个端口的下载速度限制在20MB/s，那配置值应该是160Mbps，而不是20Mbps。换算公式很简单：

限制值（Mbps）= 期望速度（MB/s）× 8

实操中还要留约10%的余量。如果你把端口速率配置得和实际线路的物理带宽恰好相等，交换机的转发效率和TCP重传会拦住一部分吞吐，表现出来就是“明明配置了1000Mbps，跑出来却只有850Mbps”，然后一堆人开始怀疑限速策略是不是有Bug。

结合上面三点，端口限速的本质其实是一句话：在正确的方向上、用正确的速率单位、对合理的对象（单台终端、VLAN、网段）做带宽约束。这句话听起来简单，但真正落到组网里，背后还牵涉到交换机内部的队列与令牌桶机制，这些决定了限速之后用户的真实体验，下一章详细拆。

2. 令牌桶机制：为什么限速之后还能允许“短暂超速”

2.1 令牌桶不是玄学，是个水桶

很多文档在讲端口限速时，会直接丢出“CIR”“PIR”“Bc”“Be”这些缩写，看得人一头雾水。其实这些参数全都在描述同一个东西：令牌桶。我解释的时候喜欢打一个比方：令牌桶就是一个带出口的水池，水池里不停以固定速率进水（令牌生成），每次数据包要过闸门就得从池里舀走相当于自身大小的一瓢水，池里没水了，包就得等或者丢。

这里的固定进水速率就是 CIR（承诺信息速率），也就是我们口中常说的“限速值”。但那问题来了：如果水池容量是0，那突发一个数据包都会被卡；所以还要给一个池子的容量，这个容量就是 Tc（令牌桶容量）或者通常说的 Bc（承诺突发尺寸）。只要池子里的令牌没被舀干，哪怕瞬间来了超过CIR的流量，交换机也照样让它们过去——这个“短时间内的超速放行量”，就是突发流量允许存在的根源。

2.2 单桶双桶：从“只限平均”到“同时管住峰值”

低端或者老旧的限速实现，可能只有一个桶。这种单速率限速只管住了平均速率，却对瞬时峰值没做约束。比如CIR设为100Mbps、Tc设为10MB，那么在一个很小的窗口内，数据包可以把10MB的令牌池一口气全部用完，瞬间速率冲到1000Mbps，然后后续流量全部被丢——视频会议的抖动就是这么来的。

所以主流交换机的端口限速都采用“双速率双令牌桶”模型：除了CIR和Tc之外，还会配置 PIR（峰值信息速率）和 Pe（峰值突发尺寸）。CIR管的是“保证你能得到的带宽”，PIR管的是“上限绝对不能超过的带宽”，两个桶串联工作。只要流量速率在CIR以内，走CIR桶；超过CIR、但没超过PIR的，走PIR桶；超过PIR的，直接丢弃或标记。这样做的好处是既允许适度突发，又不让突发彻底失控。

2.3 突发参数设大设小，体验天差地别

这里我想给一个具体的配置经验：很多人在交换机上配限速，只填了速率，Bc和Be全部用默认值。默认值通常很小，比如几KB到几十KB。这在普通网页浏览场景没太大问题，但对视频流和文件传输就是灾难——视频流的码率本身是波动的，瞬时峰值远大于平均值，如果用了小突发桶，可能每秒要丢几十上百个帧，画面就不断卡顿。

我给某直播平台做机房交换机调优时，把下连口限速10Mbps，Bc从默认32KB调到1MB，卡顿率直接下降了一个量级。核心依据是TCP和视频的窗口特性：它们需要一定的突发余量来平滑拥塞窗口的波动，完全削平突发等于阉割了传输协议本身的效率。

所以合理的做法是：

• 限速值较小（比如1Mbps以下）时，Bc可设为限速值的1~2秒流量。
• 限速值较大（比如100Mbps）时，Bc可设为100~200MB，避开瞬时尖峰。

如果你用的是配置界面里只有“平均速率”和“峰值速率”两个选项的傻瓜设备，那“峰值速率”建议设为平均速率的两倍左右，它承担的就是PIR的角色。

理解令牌桶之后，你会发现端口限速根本不是“一刀切把速度压死”，而是在“允许突发”和“控制带宽占用”之间找平衡。接下来要解决的下一个问题是：这套限速机制，在不同的层级到底该怎么部署、谁先谁后。

3. 接入、汇聚、核心：限速策略到底该放在哪一层

3.1 三层组网中各层的角色差异

一张典型的园区网可以简化成三层结构：接入层负责让终端设备接入，汇聚层负责汇总接入层的流量并进行策略控制，核心层负责高速转发和出口互联。端口限速策略放在哪一层，效果和灵活性完全不一样。先看一张我经常用来给客户讲方案的对比表：

3.2 普通办公用户：限接入层端口最省事

对办公网用户来说，我的首选是接入层端口限速。因为每个工位对应一个物理端口，直接在端口上做一个出方向限速，比如下行20Mbps，就能保证任何一个员工下载都不会把整台接入交换机的上联带宽挤爆。这种做法的配置逻辑最清晰：交换机G0/0/1对应工位1，G0/0/2对应工位2，出问题后对应关系一目了然。

很多老工程师觉得逐端口配置很繁琐，其实可以用接口范围批量下发。把一排端口选出来，一次性应用同样的限速策略，工作量并没有想象中那么大。而且接入层设备通常功能简单、性能较弱，如果接入层交能支持双速率令牌桶，做基础的CIR/PIR限速完全够用。

3.3 摄像头和IPTV这类批量设备：汇聚层统一限速

但如果终端是一批摄像头或IP电话，情况就不同了。几十路摄像头分布在不同接入交换机上，如果逐端口去配置限速，增设一台监控点位就要改一台交换机，维护成本极高。更合理的做法是在汇聚交换机上对摄像头对应的VLAN或IP网段做整体限速。

举例：某园区新装64路摄像头，每路码流为8Mbps，加起来是512Mbps。汇聚层用一个限速策略，匹配摄像头VLAN的全部流量，限制到600Mbps左右，并允许一定突发。这样无论摄像头接在哪台接入交换机，只要VLAN不变，策略自动生效。后续新增摄像头，也只涉及总带宽是否超限的问题，不需要跑到每台接入设备上改配置。

3.4 出口总带宽：核心层做最后一堵墙

有些单位有几十个VLAN共用一条外网专线，各部门都在抢占出口带宽。这时虽然接入层和汇聚层都做了端口限速，但仍可能出现整体出口拥塞。核心层就适合做一道“总阀门”：对出口方向配置总限速，比如专线带宽是1000Mbps，就把核心交换机的出方向限速设为950Mbps，留出余量给路由和协议报文。

需要注意，核心层限速尽量用硬件队列调度而不是简单的端口整形，因为核心层转发压力大，纯软件丢包会对所有业务产生连锁影响。好的做法是配合 PQ/CBWFQ 这类队列调度，把语音和关键业务放进高优先级队列，普通下载流量进低优先级队列，再配合总带宽限制。

这层的部署原则可以总结成一句：接入层管人、汇聚层管网段、核心层管出口。三条线各管各的，互不干扰。但仅仅知道“在哪一层限”还不够，真正落地时你会遇到一个更现实的问题——“限速命令到底怎么写才有效”。

4. 真实配置：接入交换机上的端口限速脚本与参数解析

4.1 最基本的下行限速：一个CAR矩阵就够了

现在以某主流品牌交换机的配置界面为例，它的端口限速底层用的是CAR（承诺访问速率）机制。我们要限制接入端口GE0/0/1的下行速度不超过20Mbps，允许突发4MB，可以这样写：

code复制<SW> system-view
[SW] interface gigabitethernet 0/0/1
[SW-GigabitEthernet0/0/1] undo portswitch
[SW-GigabitEthernet0/0/1] qos car outbound car-1 cir 20000 pir 40000 cbs 4000 pbs 8000
[SW-GigabitEthernet0/0/1] quit

拆开解释一下：

• cir 20000：CIR设为20000kbps，也就是20Mbps，这是承诺给该端口的平均带宽。
• pir 40000：PIR设为40000kbps，即40Mbps，允许瞬时峰值最高到40Mbps。
• cbs 4000：Bc设为4000KB，约4MB，这是CIR桶的容量。
• pbs 8000：Be设为8000KB，约8MB，这是PIR桶的容量。

这条命令下发后，交换机会在硬件层面直接对出方向的流量做令牌桶测量，超过PIR的报文直接丢。相比某些家用路由器上用软件做带宽控制，这种硬件CAR的延迟和CPU开销都非常小，所以很适合接入层批量部署。

4.2 用队列调度的限速：既要限速还要保关键业务

如果单纯限一个速率，用户视频会议和质量不好的体验还是可能出现。因为端口限速只是“给流量设了个上限”，并没有规定“在带宽不够时怎么排队”。高级一点的做法是把限速和队列绑定，比如把数据流分为两个优先级，让语音和高清视频优先过，普通下载流量在限速范围内排队。

配置思路示意：

code复制[SW] traffic classifier voice
[SW-classifier-voice] if-match dscp ef
[SW] traffic behavior voice
[SW-behavior-voice] car cir 5000 pir 10000 cbs 2000 pbs 4000
[SW] qos policy my-policy
[SW-qospolicy-my-policy] classifier voice behavior voice precedence 1

这段配置的意思是：把DSCP标记为EF（语音业务常用标记）的流量单独识别出来，给它5Mbps的保证带宽和10Mbps的峰值突发上限。余下流量可以再用一个classifier匹配全部流量，限制在15Mbps以内。这样总出口虽然只有20Mbps，但语音流量永远优先得到资源，下载只能使用剩余的带宽。

这种“限速+排队”的组合方案，比单纯在端口上扔一个CAR值要复杂，但效果天差地别。尤其当同一个端口下既有摄像头又有视频会议终端时，不做队列调度的限速，几乎等同于“大家一起堵，谁先谁运气好”。

4.3 配置后如何验证限速是否生效

配置写完之后，不能只看状态里显示“OK”就算完事。我习惯在配置端口的交换机上查看限速统计：

code复制[SW] display qos car statistics interface gigabitethernet 0/0/1

重点看两列：Passed Packets（通过报文数）和 Discarded Packets（丢弃报文数）。如果持续丢包，说明瓶颈确实在该速率附近；如果丢包数为零且流量远低于CIR，那要么是限速值设太高了，要么是策略没匹配到目标流量。

还有一个很实用的验证方法：在终端上开一个测速网站，连续测三次，观察是否稳定在配置速率换算后的数值附近。同时到交换机上看端口实时速率：

code复制[SW] display interface gigabitethernet 0/0/1

如果端口出方向速率长时间顶着配置速率跑，且持续有丢包统计，那说明限速策略是真的在起作用，而且该用户确实是大流量消耗者，可以考虑单独扩容或有线与无线的负载均衡。

不过实话说，理论与实践之间永远隔着一条叫“排查”的河。配置命令写对了，限速策略也可能不生效，甚至让网络变得更卡。下一章就专门讲我这几年踩过的那些坑。

5. 限速不生效或越限越卡：一份实战排查清单

5.1 方向搞反是最常见的“隐形Bug”

有一次同事反馈某台服务器“下载很快但上传卡死”，我上去把服务器接入端口的入方向和出方向限速都用查看命令调出来，发现当初配置时把上传限制在了2Mbps，下载反而是50Mbps。结果就是这台服务器作为备份节点，向外传输备份数据时疯狂卡在2Mbps上。修改成“出方向限速2Mbps、入方向限速50Mbps”后立刻恢复正常。

这个问题在大型网络里尤其隐蔽，因为配置人员在不同设备上看到的“入/出”参照系不一样：有些设备的入方向指的是“进入交换机方向”，有些产品的语义里“inbound”指的是“进入端口方向”，二者虽然多数一致，但遇到三层口和二层口混用时，容易让经验不足的运维看岔。排查时先把拓扑图画清楚，对着端口箭头确认方向，再去看策略。

5.2 限速值单位错了：你以为的100Mbps，其实是12.5MB/s

前面提过单位换算，但在实际故障里还是会看到有人把“100Mbps”写成“100MB/s”这种乌龙。特别是从网管系统里照抄配置时，系统软件里填的单位是MB/s，交换机底层用的是Mbps，中间差8倍。我曾经在一个项目里检查过一批配置模板，有几台设备的限速值明显比其他同型号设备小一个数量级，查下来就是填写人把单位搞混了。

建议：写配置模板的时候，在注释里直接写“限速值(单位：Mbps) = 期望值(MB/s) × 8”，并且保存一份单位换算表放在运维文档里，避免每次都要临时算。

5.3 突发桶太小：限速完成后延迟反而飙升

这个是最反直觉的坑。有些时候限速配置看似生效，但业务端到端延迟比不限速时还高。原因是突发参数（Bc/Be）设置过小，令牌桶瞬间被清空，后续大量数据包必须排队等待令牌生成，交换机缓冲队列被填满，每个包都在经历“排队-等待-放行”的循环，延迟自然飙升。

这种情况最容易出现在两类流量上：一是TCP大窗口传输，二是监控视频码流波动明显。排查时可以降低限速速率测试，如果延迟跟着降下来，说明令牌桶基本被打满；如果延迟仍然居高不下，那就是突发桶容量的问题，把Bc值调大1~2个数量级试试。

5.4 策略匹配顺序：先匹配了放行，后匹配的限速等于没限

交换机的流策略是按顺序匹配的，如果前面有一条permit（放行）的流分类规则，后面的限速规则根本不会执行。我在配置摄像头网段限速时遇到过：先建了一条“匹配网段并放行”的引流策略，再建“匹配同一网段并限速”的策略，结果限速一直不生效。把限速策略的优先级调高或者合并到一个策略里，问题才解决。

查看策略匹配顺序的命令因厂商而异，但思路一致：一条一条看当前生效策略的命中计数，如果命中计数不做增长，说明前面的策略把流量“抢走”了。

下面把这几个常见问题整理成一张速查表：

5.5 特殊现象：为什么限速后，瞬时流量能看到限速值的两倍

不少人在做完限速后用网管软件看历史流量曲线，会发现某个端口出现了“限速值两倍”的尖峰，于是怀疑交换机限速失效。这个现象的原因要分两类看：

一类是双工链路和流量统计时间粒度导致。流量统计是按秒甚至按5分钟为周期采样的，如果采样周期内的瞬时速率曾经超过CIR但又被迅速丢包，平均值仍然可能超过CIR。另一类是厂商实现中PIR本身就允许突发到峰值的两倍，部分简化实现的交换机在令牌桶耗尽后，只是把超限数据包标记成可丢弃（Yellow），并没有立刻全部丢弃，而是让它们在队列里等待转发。所以在统计面板上看到小幅超速是正常的，只要不是持续超速，一般不用大惊小怪。

排查到这里，你已经能把大部分限速故障解决了。但我在实际项目中体会最深的一点是，限速参数的“最优解”不是固定的，它跟业务模型强相关。所以最后一章，我想给出一组不同业务场景的参考参数，以及一些我踩过板子后的个人建议。

6. 不同场景的限速参数参考与几个收尾建议

6.1 常用业务场景的参数参考表

下表是我在多个项目里结合设备默认参数和业务特性总结出的初始值，实际操作应按实际情况微调：

这个表格里的PIR并不是“必须给用户”的带宽，而是“允许用户短时间冲到多少”的上限。给PIR留空间，是为了TCP和各类交互式应用能平稳运行；但PIR也不能设置得比物理带宽还高，否则就没有任何意义了。

6.2 把限速和业务分级放在一起做，而不是单独做限速

我处理过不少“限速后客户仍不满意”的项目，后来发现真正的问题在于：客户以为限速是“给每个人分一块固定带宽”，但实际场景是有人要开视频会议、有人在做大文件传输、有人在刷监控，这些业务对延迟和带宽的需求完全不一样。如果只用端口限速一刀切，必然有人觉得卡。

更合理的方式是把“限速”和“优先级标记”配合使用：在接入层先把语音、视频、关键业务的DSCP标记好，汇聚层再做基于优先级的队列调度，最后对用户总带宽做一个上限约束。这样每个用户能用的带宽有上限，同时重要业务的带宽又被保护住了。相当于“每人每天用水有额度，但消防用水永远优先”。

6.3 最后再分享一个小技巧：限速策略上线前先小范围灰度

无论配置模板写得多么严谨，我都建议先拿一到两个测试端口验证，观察24小时，再看核心业务的延迟和丢包率是否有异常。灰度验证期间盯三个指标：端口速率曲线、丢包计数器、应用层体验（如语音编码评分）。没问题再批量下发到全网络设备上。

我之前有一次在监控网段做批量限速，因为Bc值只按一路摄像头的常见码流为基准计算，结果64路同时上线时，汇聚交换机短时间丢弃了大量报文，导致平台端视频存储出现空洞。后来重新按“总码流+突发余量”重新计算Bc值，才恢复稳定。从那以后，凡是涉及多路并发流量的限速，我都会先按最坏情况算一遍突发桶，绝不用默认值直接上线。

端口限速这东西，说到底不是“把速度掐住”的技术，而是“在有限的带宽资源里，让该快的业务快起来、让贪吃的业务不失控”的手段。设低了，业务体验受损；设高了，链路拥塞依旧。每次看到有人问“限速到底设为多少合适”，我给的建议都是：先搞清楚业务模型，再填参数；先小范围验证，再全面铺开。网络的痛感往往不在速率数值上，而在你看不到的排队和丢弃细节里。希望这篇从原理到实战的记录，能让你下次配置端口限速时少走些弯路。