4、CIR（承诺信息速率）深度解析
CIR，承诺信息速率。说白了，就是运营商承诺给你的那条链路，在正常情况下能稳定跑通的带宽。我经常跟刚入行的朋友讲，别把它想得太玄乎，你就当它是你家水龙头的“基础出水量”——不管邻居用不用水，这个流量是保证给你的。
但实际调试中，很多人把CIR和带宽上限搞混了。嗯，这里得掰扯清楚。
4.1 CIR的定义：到底承诺了什么？
CIR不是“最大速率”，而是“保证速率”。它背后对应着一套令牌桶机制。你想想看，运营商凭什么敢承诺你1Mbps？因为他给你配了一个令牌桶，每秒往桶里丢1Mbit的令牌。你发数据，就得消耗令牌。有令牌，数据就走；没令牌，要么等，要么丢。
我在项目中遇到过好几次，客户拿着带宽测试报告来找我，说“你们承诺的100M CIR，怎么我测出来只有80M？”一查，原来是测试工具打的是UDP突发流，瞬间把令牌桶打空了，后面的包全被标记为黄色或红色，要么降级要么丢弃。这不是CIR没给够，是流量模型没对上。
核心要点：CIR = 长期平均速率，不是瞬时峰值。令牌桶的深度（Bc）决定了你能容忍多大的突发。
4.2 如何配置CIR：从设备到策略
配置CIR，不同厂商的命令不一样，但逻辑是通的。我以华为和Cisco为例，给你拆开揉碎了讲。
4.2.1 接口限速（最简单的CIR配置）
这种场景最常见：你只想限制某个接口的总出口带宽。
Cisco IOS 示例：
interface GigabitEthernet0/1
rate-limit output 10000000 1250000 1250000 conform-action transmit exceed-action drop
这里10000000是CIR（10Mbps），后面两个1250000分别是Bc和Be（突发尺寸）。
华为 VRP 示例：
interface GigabitEthernet0/0/1
qos lr cir 10000 cbs 1250000
华为的lr（line rate）就是接口限速，cir单位是kbps，cbs单位是byte。
我的习惯：配置CIR时，Bc不要随便填。一般建议Bc = CIR × 1.5秒。比如CIR 10M，Bc就配15Mbit。太小了容易丢突发，太大了起不到限速效果。
4.2.2 基于流分类的CIR（精细化管控）
光限制接口不够，很多时候你得区分业务。比如视频会议要保证2M，下载业务只能跑5M。
Cisco MQC 配置：
class-map match-any VIDEO
match ip dscp ef
!
policy-map QOS_POLICY
class VIDEO
police cir 2000000 bc 375000
conform-action transmit
exceed-action set-dscp-transmit af41
violate-action drop
class class-default
police cir 5000000 bc 937500
conform-action transmit
exceed-action drop
!
interface GigabitEthernet0/1
service-policy output QOS_POLICY
你看，视频流CIR 2M，超出的打标记但不丢；默认流量CIR 5M，超出的直接丢。这就是差异化。
华为 HQoS 配置：
traffic classifier VIDEO
if-match dscp ef
!
traffic behavior VIDEO
car cir 2000 cbs 37500 green pass yellow pass red discard
!
traffic policy QOS_POLICY
classifier VIDEO behavior VIDEO
classifier class-default behavior DOWNLOAD
!
interface GigabitEthernet0/0/1
traffic-policy QOS_POLICY inbound
我曾经踩过的坑：有一次给客户配CIR，华为设备上忘了配cbs，结果默认cbs只有1500字节。视频流一开，瞬间丢包。后来查了半天才发现，cbs太小，令牌桶根本存不住令牌。记住：CIR和CBS是两口子，缺一个就出事。
4.3 CIR与业务SLA的映射关系
SLA（服务等级协议）里写的那些指标——时延、抖动、丢包率——跟CIR是什么关系？很多人以为CIR高了，时延就低了。其实不是。
我画了一张图，帮你理清这个逻辑。
从图上你能看到：业务类型决定了CIR怎么配，CIR配好了直接影响SLA指标。但这里有个关键点——CIR只保证带宽，不直接保证时延。时延取决于队列调度和网络负载。
举个例子。你给视频配了10M CIR，但中间链路上还有别的流量在抢带宽。即使CIR够了，如果队列调度是FIFO（先入先出），视频包还是得排队，时延照样高。所以CIR必须配合调度算法（比如LLQ、WFQ）才能兑现SLA。
| 业务类型 | 典型CIR配置 | SLA关键指标 | 调度建议 |
|---|---|---|---|
| 语音（EF） | CIR ≥ 编码速率 × 1.3 | 时延 < 30ms，抖动 < 5ms | LLQ（优先队列） |
| 视频（AF） | CIR ≥ 平均码率 × 1.2 | 时延 < 50ms，丢包 < 0.1% | CBWFQ + 带宽保证 |
| 关键数据（AF） | CIR ≥ 业务峰值 | 丢包 < 0.01% | CBWFQ + 最小带宽 |
| 普通数据（BE） | CIR = 尽力而为 | 无严格SLA | 默认队列 |
实战经验：我调试过一个跨国视频会议项目。客户要求CIR 2M，但实际视频码率只有1.5M。按理说够了，但开会时经常卡顿。后来抓包发现，视频流里有大量RTCP控制包和重传包，实际带宽需求接近2.3M。所以配置CIR时，一定要留余量。我个人习惯是：CIR = 业务平均速率 × 1.3 ~ 1.5。
4.4 避坑指南：CIR调试中的常见误区
- 误区一：CIR越大越好。 不对。CIR大了，运营商收费也高。而且如果CIR超过物理带宽，令牌桶永远满，限速形同虚设。
- 误区二：CIR配了，SLA就达标。 我前面说了，CIR只是带宽保证。时延和抖动还得靠队列调度和整形。
- 误区三：CIR和PIR（峰值信息速率）搞混。 CIR是保证值，PIR是允许的最大值。很多设备上PIR默认等于CIR，但你可以配PIR > CIR，允许短时间突发。
我曾经翻过的一个车：给某银行配MPLS VPN的CIR，客户要求每个站点CIR 50M。我直接在PE设备上配了接口限速50M。结果业务高峰期，路由协议Hello包被限速丢了，邻居反复震荡。后来才意识到，控制面流量也得留带宽。建议CIR配置时，至少留5%~10%给控制面和管理流量。
好了，CIR这块就聊到这儿。记住一句话：CIR是承诺，不是上限；是平均，不是瞬时；是带宽，不是时延。搞清楚了这些，你调试流控时就不会再被SLA投诉追着跑了。