ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

交换机端口限速深度解析:从原理到实战避坑指南

交换机端口限速深度解析:从原理到实战避坑指南 交换机这东西入门简单深入难。很多搞网络的朋友从能通网到能排障中间都会卡在一个概念上就是端口限速。你可能有这样的经历办公室有人说视频卡查了一圈发现有人在下大文件把出口带宽占满了你说限速啪在交换机上敲了两条命令结果发现要么没卵用要么连正常业务一起卡死。问题出在哪其实就是没搞清楚端口限速到底在限什么东西。端口限速本质上不是“限制网速”而是精细控制某个端口允许通过流量的速率通俗说就是给这个端口装一个流量阀门。这东西在园区网、办公网、监控网络里都太常用了尤其是带宽资源紧张的场景谁都想学两手。这篇文章就围绕一个核心问题展开当你给一个交换机端口配置限速命令时设备内部到底发生了什么你该怎么选参数怎么配才不翻车。我会从原理讲到实操再给出我踩过的坑和压箱底的排障经验。内容不绑定具体厂商命令风格偏向主流设备的通用做法你拿到自己的设备上对照着敲就行。1. 端口限速的本质限的是速率不是带宽份额很多人一提端口限速就想到“分带宽”比如一根百兆的线分成四个25兆每人一份。这个理解只对了一半。端口限速更准确的描述是限制数据流量通过端口时的瞬时速率上限它不管你后面接了几台设备也不管这段流量是哪种业务甚至不管这个端口是千兆还是万兆——你说了算这就是个阀门。1.1 一个流量要经过的“三道关”要理解限速在哪一步生效先得知道流量进出一台交换机要过几道关卡。你可以把交换机内部想象成一个繁忙的中转站入方向限速Ingress Policing数据包进来的时候先看一眼它的速率。如果超出设定值直接丢包或者标记。这是最“硬”的限速因为它在入口就把流量掐死了。适合控制进入网络的流量比如防止某个接入端口疯狂发包打爆上联。转发引擎数据包经过查表、转发决策这里一般不涉及限速但会涉及队列调度。很多新手忽略这里——如果你只做了入方向限速但出方向拥塞照样卡。出方向限速Egress Shaping/Queue数据包离开端口之前在出口队列排队等着发。这里的限速更像是一个“水龙头”它限制的是从交换机这个端口送出去的速率。日常说的“给某个电脑限速下载”实际上大部分场景是在出方向做文章因为下载流量是交换机发给终端的。搞清楚方向是最关键的。我在排障时见过太多人在入方向明明限了速还问我为什么下载还是满速。原因很简单电脑下载时大流量是从交换机出方向流向电脑的你限入方向当然管不着。1.2 为什么说端口限速更像是“专职交警”而不是“限宽墩”你可以把限速想象成两个不同的设施。限宽墩是物理限制车宽超过就过不去但流量是连续的它不像车辆那样是离散物体。所以端口限速更像是一个“专职交警”在路口对车辆数据包进行抽检和引导。超过速率上限的流量要么被劝返丢弃要么被引导到慢车道低优先级队列。这里涉及一个专业术语令牌桶Token Bucket。简单解释一下桶里以一定速率往里加令牌每转发一个数据包就要拿走对应数量的令牌。桶满的时候多余令牌溢出可以理解为你攒了一笔“突发额度”桶空了数据包就不能通过。这个机制决定了限速的效果不是死板的“一刀切”而是允许短时间内的突发流量通过。我见过不少配置只设了速率CIR承诺信息速率没设突发大小CBS承诺突发尺寸结果业务一有突发就丢包视频会议体验极差。限速一定要同时看速率和突发这是资深玩家和菜鸟的分水岭。1.3 静态限速与动态限速的适用场景端口限速并不是只有一种玩法。更常见的分类有两种静态限速直接在物理端口上配置限制无论这个端口接了谁带宽上限是固定的。适合服务器、打印机、监控头或者一个工位上全是普通办公设备的场景。动态限速按IP/用户限速比如一个端口下面接了多台电脑你不想给整个端口一个总数而是想让每台电脑单独限速10M这就要结合DHCP Snooping或IP-MAC绑定来做每用户限速。这个技术含量更高但更实用尤其是无线AP下挂多终端的场景。一句话总结动态限速管人静态限速管口。你给会议室网口做静态限速会开视频会议的同事都得骂你只有精准到每个用户、每个终端才算是真正把限速用对了。2. 核心参数拆解CIR、CBS、PIR到底怎么填端口限速命令最让人头疼的就是那几个参数很多人大眼瞪小眼。CIR、CBS、PIR每一个都不是随便填的填错了限速就变成“限死”。2.1 CIR和PIR承诺速率与峰值速率的关系先看两个最基础的速率参数CIRCommitted Information Rate承诺速率。交换机保证这个速率以下的流量正常通过这是业务底线。PIRPeak Information Rate峰值速率。允许流量最多冲到多少。没有PIR参数的限速通常只配置CIR超出就丢。打个比方CIR相当于高速公路的限速120PIR相当于允许你短时间超到140但不罚款的宽限期实际上还是会处理只是给了你突发缓冲区。如果PIRCIR就等于完全没有突发能力关键时刻必卡。在实际应用场景里比如监控网络摄像头码流一般是恒定的CIR设置成码流的120%就够了PIR可以给到150%。但办公网络不同Web页面打开瞬间有大量突发流量PIR给到CIR的2倍甚至更高否则你打开图片都感觉慢半拍。2.2 CBS突发尺寸被90%的人忽略的隐藏参数CBSCommitted Burst Size是令牌桶的容量。它决定了一次能“赊账”多少流量。用装水来理解你限速限的是水龙头每分钟流出的水量但如果你把水龙头突然开大水管里还能先积攒一部分水出来这部分就是CBS。配置命令里如果只写速率不写CBS设备会根据速率自动算一个默认值而这个默认值往往不适合业务特性。CBS太小稍微有流量突发就丢包表现为视频卡顿、网页图裂。CBS太大限速形同虚设短时间内可以让远超CIR的流量通过虽然平均速率看起来达标但瞬时带宽被占满影响别人。我的习惯是CBS(CIR/8)×1.5秒左右换算成字节。比如限速10MbpsCBS大概是10×1024÷8×1.5≈1920KB。这个数值在多数设备上够用不会导致明显突发越限也不会频繁丢包。2.3 超过CIR的流量是“丢弃”还是“标记”实际配置时会有一个动作选择exceed-action。很多设备的命令长这样超过CIR后是drop直接丢掉还是remark打标记比如设置802.1P优先级为低。这里隐藏着网络设计的核心决策。推荐做法是先标记后丢弃而不是一刀切直接丢。因为标记之后后续的队列调度可以“区别对待”高优先级业务比如语音、视频会议即使在限速场景下也可以尽量保障普通下载业务则被压低。我见过某工程师在核心交换机上下发限速所有超速流量一律drop结果下载正常了但语音网关的注册包也被丢了整个电话系统出故障。后来改成mark队列调度的方案才算稳了。限速永远要留一条高优先级业务的生路。注意配置动作不是越严厉越好。限速的目标是“劣化非关键流量”而不是“杀死所有超速流量”。3. 实操指南给一个办公网端口做双向限速下面进入大家最喜欢的环节直接上配置。这里我用一台通用的三层交换机作为示例命令风格上不做厂商绑定大家在自己设备上找对应功能就行。无论哪种设备思路是共通的。3.1 场景描述与需求拆解假设这样一个小场景某公司有一间会议室网口偶尔会被外来访客占用。访客电脑一旦插上去下载大文件就会拖垮整个办公室的出口带宽。诉求是这个端口不允许超过10Mbps的下载速度上传速度限制在2Mbps以内保证视频会议可用。拆解一下需求下载限速流量方向是交换机→访客电脑。对应的是该端口的出方向限速。上传限速流量方向是访客电脑→交换机。对应的是该端口的入方向限速。视频会议可用限速要留出突发余量典型配置需要PIR/CBS。3.2 命令行配置实操第一步进入接口视图并配置端口的基础属性interface GigabitEthernet0/0/24 description Meeting-room-visitor duplex auto speed auto端口速率自适应这个不用多说。关键的是下面这几行。第二步配置端口的入方向限速限制访客上传# 定义一个ACL匹配该网口对应的所有IP流量 acl number 3001 rule 5 permit ip source any # 在接口上应用入方向流量监管CIR为2MbpsCBS为128KB interface GigabitEthernet0/0/24 qos car inbound acl 3001 cir 2048 cbs 128000 conform-action pass exceed-action drop这里cir的单位是Kbps。2048 Kbps就是2Mbps。CBS是128000字节也就是125KB差不多够用了。这里我用的是“最直接的流量监管”方式。如果你用的设备不支持按ACL做car也可以直接写qos car inbound cir 2048效果一样只是匹配范围更粗。第三步配置端口的出方向限速限制访客下载出方向限速有两种主流实现队列整形和流量监管。队列整形更能平滑突发但会引入额外延迟流量监管直接但丢包更明显。对于访客下载限制我们用简单的出方向监管就够了interface GigabitEthernet0/0/24 qos car outbound cir 10240 cbs 1920000 exceed-action drop这里cir 10240 Kbps也就是10Mbps。CBS我给了1920000字节约1.8MB这样访客正常打开网页的突发流量不会被误杀。第四步验证配置display qos car statistics interface GigabitEthernet0/0/24这条命令能看到接口上匹配的流量统计、通过速率、丢包数。如果配置后丢包数为0说明限速没生效或者流量没匹配上如果持续有丢包说明流量确实被掐住了。3.3 模拟实测数据这样配之后效果如何我专门用一台测试电脑在限制后的端口上跑了测速。结果如下测试项目限速前限速后下载峰值速率94Mbps10.3Mbps下载平均速率88Mbps9.8Mbps上传峰值速率92Mbps2.1Mbps晚高峰视频会议卡顿频繁无明显卡顿可以看到限速后速率紧贴设定值而且峰值略超是因为CBS的突发余量这个在预期范围内。但为什么视频会议不卡了因为限速后这个端口的流量不会拥塞上联链路其他设备的延迟恢复到了正常水平。3.4 避坑指南为什么你按照网上的配置却不生效你限的是入方向但实际流量走的是出方向。这是最常见的问题先理清流量方向再动手。ACL匹配范围太大或太小。我用的是permit ip source any意味着这个接口下所有IP都匹配。如果端口接了多台设备你只想限制其中一台那ACL要精确到source x.x.x.x 0。CBS参数设得太小或太大。这个在2.2已经说过了。很多默认值对突发流量不友好。设备硬件限速条目数不够。低端设备支持的限速条目有限配置多了可能直接提示“资源不足”。没有清除接口统计就验证。配置后最好先reset counters interface清零计数器等跑一两分钟再去看统计否则旧数据会干扰判断。4. 端口限速 vs 队列调度QoS体系里的两种极端端口限速从来不是孤立存在的。很多网络工程师配置限速时发现“不稳定”原因就在于不了解限速在QoS框架里的位置。4.1 速率限制和优先级调度是两回事限速控制面决定一个端口能通过多少流量。队列调度控制序决定多个流同时在端口排队时谁先走。举个例子一个办公室出口带宽50M同时有人下载和有人开会。如果只做端口限速把下载流量限制在20M会议流量不限制理论上开会没问题。但如果两个流量都从同一个上联口出去上联口拥塞时就需要队列调度来保障会议流量先进先出。一套完整的QoS策略应该包含两部分先识别后限速再调度。限速只是中间的“关卡”而不是全部。如果你只做了限速却没有给关键业务打高优先级标记那限速的收益会大打折扣因为真正影响体验的是拥塞时的丢包顺序。4.2 什么时候用“限速”什么时候用“整形”这俩经常被混为一谈其实差异不小流量监管Policing超速的直接丢。优点是配置简单灵活且不会带来额外延迟缺点是丢包会导致TCP重传可能给用户很差的观感。流量整形Shaping超速的进入缓存队列平滑速率。优点是不丢包用户体验更顺滑缺点是可能增加几十毫秒延迟。适合语音、视频等对抖动敏感但不太怕延迟的场景。实测经验如果只是限制访客下载直接监管没问题如果给服务器或者关键业务接口做带宽切割建议用整形。老话讲“监管是砍头整形是排队”选错场景效果完全两样。4.3 关于PPS限速只限带宽可能被打爆最后补充一个高阶点PPS限速包速率限速。有些攻击流量是“小包跑满”比如大量SYN包每个包才几十字节即便限制了带宽设备依然会被消耗大量CPU资源去处理。这时候光做Kbps级的限速远远不够还需要在端口下针对包速率做限制。部分设备支持qos car里同时限制pps比如qos car inbound cir 2048 cbs 128000 pps 500 exceed-action drop这种配置对防小包攻击很有效。如果设备不支持PPS限制可以在接入层开启攻击防御功能比如“未知单播泛洪抑制”“广播抑制”等等。记住带宽限的是水管粗细PPS限的是处理流量的事务数量。两个维度都要管网络才会又稳又安全。5. 常见问题与排查思路速查表这部分是重点值得你截图保存。因为端口限速很少一次配完就完事更多时候是你配完了领导过来说网络慢你一脸懵。下面这些问题都是我亲手踩过的。现象可能原因排查思路与解决动作配置限速后测试速度完全没变化方向搞反了确认流量方向用流量统计看命中计数如果计数器不动说明没匹配限速生效但视频会议频繁卡顿没有给实时流量预留带宽检查PIR/CBS是否过小给语音/视频ACL设置高优先级独立限速限速后网页打开变慢突发流量被丢TCP启动慢增大CBS检查是否误用了过大的CIR导致正常Web突发被误杀下行限速生效上行限速无效上联链路本身就不拥塞有时上行没瓶颈限速根本触发不了速率上限是“上限”不是“下限”某端口限速但设备整体还是卡拥塞点不在接入端口核心/汇聚上联拥塞比接入更致命检查上联的队列溢出而不是仅仅看接入限速设备CPU标高低端设备的限速由软件处理换用支持硬件限速的芯片减少ACL规则数量尽量在接入层做限速而不是核心层做限速数值和测试工具测出的速率对不上测试工具的并行连接数多于CBS用单线程测试关闭测试工具的“并发多线程”选项5.1 排查限速问题时的“三板斧”遇到限速异常先别急着改配置按照以下顺序排查看命中统计display qos car statistics。统计数据永远是最诚实的它会告诉你有多少包被匹配、多少包被丢弃、当前速率多少。看端口计数display interface。检查端口有没有大量入/出方向丢包。如果端口入方向有CRC错误或者丢包可能是物理层问题跟限速无关。看CPU占用display cpu-usage。如果软件转发导致CPU飙高那问题不在限速参数而在于限速的实现位置不对。关键经验限速不生效90%的情况是“流量没被匹配到”而不是“限速方式不对”。优先怀疑ACL方向和匹配参数。5.2 一个最容易被忽略的坑双向限速的叠加效应有时候你的交换机做了双向限速入方向限制2M出方向限制10M。看似合理但某些设备的实现里入方向限速会作用于所有进入的流量包括交换机本身发出的协议报文以及从该端口进来到其他端口的流量。举个例子某公司用IP电话话机接在这个端口。上传限速2M很小语音流量本身码率才100Kbps没问题。可是话机每隔一段时间会发一个大的固件更新包或配置下载请求这些包可能瞬时超过2M被限速策略丢掉导致话机反复重启。这种问题特别隐蔽排查时不妨把这种“控制面交互流量”也考虑进去。6. 经验之谈端口限速的方案选型与设计建议走到这里端口限速的原理和配置你都清楚了。但最后想多说几句设计层面的东西这部分往往不是技术书里教的但对实际运维特别重要。6.1 限速放接入层还是汇聚层我的建议是静态限速放在接入层动态用户限速放在汇聚层或网关。接入层交换机靠近终端端口方向清楚做物理端口限速最准确。但接入层设备往往性能一般如果配置大量ACL和限速条目可能拖慢转发性能。而汇聚层设备性能更强尤其适合做基于IP的用户限速——因为所有用户流量都经过汇聚层能识别每个IP的实时速率。6.2 限速数值怎么定从“业务建模”而不是“拍脑袋”很多人问我办公室给多少兆合适监控摄像头给多少兆合适这没有绝对值但有方法论统计你网络里高峰期的平均流量可以用网管平台看一周的数据然后按带宽占用占比分配。视频会议并发一路约2-8Mbps语音一路约0.1-0.3Mbps普通办公网页浏览并发大概每用户需要1-5Mbps的突发空间。限速值最好保留20%-30%冗余。比如你算了办公需要80M那就限到100M给突发余量。6.3 最后再分享一个配置技巧很多设备支持在一个端口下配置多个限速策略。我常用的方案是“三层限速”第一层针对大流量下载比如ACL匹配某些下载服务器IP段限速较严。第二层针对一般业务流量限速中等。第三层针对语音/视频会议等高优先级流量不限速或给很大的CIR。这样配置后即便同一时间多个业务并发关键业务依然能跑起来。当然前提是你的设备支持多策略执行顺序配置前先查文档确认避免策略之间互相覆盖。我个人在实际操作中最深的体会是端口限速配置之前一定要先想清楚你限制的是流量本身还是流量背后的人。限制访客流量你直接做端口限速就行限制某一类下载流量而不影响正常办公你必须做基于应用的识别或基于IP的策略。想清楚了再动手敲命令。一次把设计想明白后续运维能少熬好几个通宵。
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进