上一讲把MQC组件和设计理念讲透了，这篇直接切实操。评论区催配置的朋友不少，这回来填坑：用两个最常见的落地场景——流量过滤和策略路由分流，把MQC基本配置从头到尾走一遍。演示配置以某主流商用设备厂商的命令行风格为例（下文写作A厂），原理层面各厂商通用。先纠正一个搜资料时容易碰到的迷惑：群里经常看到有人把MQC记成PQC，搜“PQC流量过滤”出来的其实还是同一套模块化QoS命令，别被拼写带偏，本文讲的MQC流量过滤，就是标题里那个PQC流量过滤的完整配置方法。
这篇适合谁看？你只要碰过企业网或者数据中心网络，手里管着出口路由器、核心交换机，想搞清楚“怎么把某些流量拦掉、怎么让指定流量走指定链路、怎么做限速又不破坏原有ACL结构”，这篇就是给你写的。看完你能直接照着敲配置，能看明白display输出，还能避开我实际运维中踩过的那几个坑。
1. MQC到底解决了什么问题：先搞懂它凭什么替代一堆ACL
1.1 三要素结构：分类器、行为、策略
MQC的核心思想可以压缩成一句话：先挑流量，再定动作，最后绑位置。三个要素对应三层配置视图，顺序不能乱。
第一层是traffic classifier，流分类器，干的事就是“挑流量”。它支持按ACL、DSCP、IP优先级、VLAN、接口、MAC、甚至报文长度等条件来匹配。第二层是traffic behavior，流行为，干的事就是“对挑出来的流量做什么”。动作包括放行、丢弃、重定向、限速CAR、重标记报文优先级、进入指定队列等。第三层是traffic policy，流策略，把分类器和行为绑定成一张完整的策略表，再下发到接口的入方向或出方向。
我见过不少朋友第一次看MQC配置直接懵，其实就是把这层关系想复杂了。打个比方：classifier是保安，负责认人；behavior是执行动作，负责放行、请出去、或者带去指定房间；policy是排班表，规定哪个保安执行哪个动作，在哪个门上班。
1.2 和传统ACL硬怼方案对比：到底优势在哪
传统做法里，要实现流量过滤，多数人第一反应是直接在接口上挂ACL，inbound方向来一条deny，完事。流量限速呢，再去配一个car命令，或者用其他独立QoS工具。重定向呢，再去配策略路由。一个问题一套工具，配置分散，后期维护得翻十几个接口的配置片段才能拼出全貌。
MQC的优势在于统一承载。匹配动作和匹配条件解耦，分类器定义一次，行为定义一次，两边分别维护。比如“匹配财务网段到ERP服务器的流量”这个分类器，既能用来做流量过滤（behavior丢包），也能用来做限速（behavior CAR），还能用来做策略路由（behavior重定向），不需要为每个新需求重写一遍匹配规则。
我用一个表格把两种思路摆在一起，区别就很明显了。
| 对比维度 | 传统ACL方案 | MQC方案 |
|---|---|---|
| 配置入口 | ACL、QoS、PBR各管各的 | 统一在traffic policy体系下完成 |
| 匹配条件 | ACL五元组为主 | 五元组、DSCP、VLAN、接口、MAC等 |
| 动作扩展 | 换需求就要换工具 | 同一分类器绑定不同行为即可 |
| 可读性 | 接口配置里一串ACL编号 | 策略命名直观，语义清晰 |
| 统计能力 | 需要额外配置 | 可开statistics按分类器精细统计 |
| 维护成本 | 改动牵一发动全身 | 模块化拆解，改一个模块不影响其他 |
实际上，MQC就是给QoS和策略路由统一搭了个架子。传统场景里做流量过滤，你往往得先想“ACL规则怎么写不会冲突”；MQC场景里你要先想的是“我要匹配哪类流量、我要给它什么动作”，逻辑层次反而更简单。
1.3 为什么叫“模块化”：动作可组合，策略可嵌套
模块化的另一个体现是动作组合。一个traffic behavior下面可以同时配置多个动作，比如既做CAR限速，又做remark重标记优先级；或者既重定向，又开启统计。这些动作在同一策略里叠加执行，不需要其他工具的配合。
还有所谓的嵌套策略，行为里可以直接引用另一张表，实现分层QoS。比如在外层策略匹配到“视频流量”，内层策略再在视频流量内部区分“重要视频”和“普通视频”，分别给不同带宽。这就是MQC灵活度的体现，传统ACL方案要做这种分层，基本靠写死多条规则来硬凑。
理解了这个设计逻辑，你再看后面的配置命令就不会觉得是一堆离散的指令了，它们是一整套分层模型。
2. MQC基本配置三步走：分类器、行为、策略
正式配置前先说清楚，本文演示用的是A厂命令风格，B厂、C厂等主流商用设备的命令字面不同，但三层结构一致。理解了解耦思想，换厂商只是换拼写。
2.1 第一步：定义流分类器，把要处理的流量挑出来
分类器的定义方式很简单，进入traffic classifier视图，起个名字，指定类型，然后写if-match条件。
traffic classifier video if-match dscp ef #这段的意思是创建一个叫video的分类器，匹配DSCP值为ef的报文。DSCP是IP报文头里的差分服务标记，视频会议流量一般会在终端或语音网关打上ef或af41标记，这个分类器就是冲着它们去的。
如果匹配条件复杂，比如要按IP地址和端口，一般配合ACL使用：
acl number 3101 rule 5 permit ip source 192.168.10.0 0.0.0.255 destination 10.1.20.20 0.0.0.0 traffic classifier erp_access if-match acl 3101 #需要注意一个关键点：ACL在这里只负责“挑流量”，它怎么写得看分类需求。如果ACL里写了deny，含义不是要把流量丢掉，而是“不匹配这条分类规则”的意思。很多新手在这里翻车，后面我会专门讲这个坑。
同一个分类器下可以写多个if-match条件，默认多个条件之间是“与”的关系，全部满足才算命中。如果几个条件之间是“或”的关系，那就拆成多个分类器，每个分类器挂不同的行为。还有默认类型和自动顺序的细节，关系到多条分类器同时匹配时执行哪条，我放在第四章详细讲。
2.2 第二步：定义流行为，决定对流量做什么
行为视图是MQC里看起来最“像命令”的部分，每个动作都是一条直接指令。
traffic behavior to_mpls redirect ip-nexthop 10.255.0.2 #这是策略路由的核心动作，把命中的流量重定向到下一跳10.255.0.2。再看几个常见动作。
traffic behavior drop_p2p deny # traffic behavior limit_voice car cir 2048 cbs 256000 ebs 0 # traffic behavior mark_voice remark dscp ef # traffic behavior pass_video permit statistics enable #deny表示丢弃，car表示限速，remark表示重标记，permit表示放行。注意，如果不显式配置动作，部分设备默认行为是放行，但为了配置清晰，建议显式写permit并加上statistics enable，方便后面排查命中情况。
行为可以叠加，比如既做重定向又做remark，同一个behavior下写多条动作命令即可。动作的执行顺序设备会按内部逻辑处理，一般不需要我们操心，但有个原则：丢和放行这类“终结性动作”和重定向、限速这类“控制性动作”不会同时出现在一个行为里。如果真遇到既要限速又要重定向的场景，直接写在同一个行为里就行，比如先redirection再car，设备会同时生效，实际测试验证结果为准。
2.3 第三步：创建流策略，绑定分类器和行为，再下发到接口
前面两步是备料，这一步是真正组装。
traffic policy branch_ingress classifier video behavior to_mpls classifier erp_access behavior pass_video #策略视图里每一行都是一条“分类器+行为”绑定。之后在接口上应用：
interface GigabitEthernet0/0/0 traffic-policy branch_ingress inbound #inbound表示这个策略在接口的入方向生效。方向选错是MQC配置里最常见的问题之一。流量过滤一般在入方向做，流量刚进设备就被拦掉，不浪费后续处理能力；策略路由也多在入方向做，因为路由决策要在转发前生效。
需要记住的是：同一接口、同一方向只能应用一个流策略。如果真想在一张接口上跑多套规则，要么全部并进同一张traffic policy里，要么用嵌套策略在behavior里引子策略，这个后面讲坑时再展开。
2.4 配置后的检查姿势：三张display命令吃透状态
配置完不许走，必须验证。我每次配置MQC之后都会用下面三条命令做检查，几乎成了肌肉记忆。
display traffic classifier display traffic behavior display traffic policy applied-record第一条看分类器定义是否正确，第二条看行为动作是否齐全，第三条看策略有没有正确应用在接口上，以及应用方向是inbound还是outbound。
更关键的是看实际命中情况：
display traffic policy statistics interface GigabitEthernet0/0/0这条命令能按分类器显示命中报文数和字节数。如果策略没生效，这里能看到分类器命中计数为零，直接定位到匹配条件写错还是接口方向挂错。
3. 流量过滤实战：让该走的走、不该走的直接拦掉
3.1 场景设定：财务网段只允许访问ERP服务器
某分支办公室出口路由器上接了财务网段192.168.10.0/24，内部ERP服务器地址是10.1.20.20。需求一句话：财务网段的所有流量，除了访问ERP服务器，其他全部拦掉。这在传统ACL方案里要写两条规则，一条permit到ERP，一条deny其余，还得小心ACL隐式deny的顺序。MQC思路完全不同，我们按“分类器+行为”来拆解。
先拆解需求：需要两类分类器，第一类匹配“财务网段到ERP服务器的流量”，这是需要放行的；第二类匹配“财务网段的其他流量”，这是需要丢弃的。但这里的匹配条件要写清楚，ACL里怎么表达“其他”是个技术活。
3.2 从需求到配置：完整命令逐条拆解
ACL只需要挑出第一类流量，第二类流量用另一个分类器来匹配。
acl number 3101 rule 5 permit ip source 192.168.10.0 0.0.0.255 destination 10.1.20.20 0.0.0.0 # acl number 3102 rule 5 permit ip source 192.168.10.0 0.0.0.255 #3101匹配财务网段访问ERP，3102匹配财务网段所有IP流量。接下来分类器和行为：
traffic classifier erp_access if-match acl 3101 # traffic classifier finance_all if-match acl 3102 # traffic behavior permit_erp permit statistics enable # traffic behavior deny_finance deny statistics enable # traffic policy finance_filter classifier erp_access behavior permit_erp classifier finance_all behavior deny_finance #最后应用到财务网段接入的接口入方向。如果财务网段接在G0/0/1口，配置就是：
interface GigabitEthernet0/0/1 traffic-policy finance_filter inbound #注意策略里分类器的顺序：erp_access必须在finance_all前面。因为finance_all匹配的是财务网段全部流量，包括访问ERP的部分，如果顺序反了，所有流量都会被deny。这个顺序问题我见过太多次了，后面会单独强调。
3.3 一个认知纠偏：ACL的deny不等于流量的deny
这是MQC流量过滤里最容易被误解的点。写分类器时用ACL做匹配条件，ACL里可以同时有permit和deny语句，但它们的意义不是放行或丢弃报文，而是“匹配”或“不匹配”。
举例子，如果ACL 3101里写了一条deny规则，不写permit，那这个分类器永远匹配不到任何流量，因为ACL里deny使该流量不满足匹配条件，根本不是“匹配后丢弃”。MQC真正执行丢弃动作的是behavior里的deny。
很多新手看到ACL里有deny就以为流量会被丢，结果策略根本不生效。记住一句话：在MQC体系里，分类器只用permit规则来表达“我要找什么流量”，丢不丢、放不放、限不限速，全是behavior的事。
3.4 过滤的同时叠加限速：既要拦也要控
实际生产环境里，纯过滤的场景其实不够用。财务网段访问ERP除了要放行，领导往往还要求控制带宽，防止某个终端把出口带宽占满。这时MQC的优势就出来了，同一个分类器，只需要在behavior里加一行CAR配置。
traffic behavior permit_erp permit car cir 4096 cbs 512000 ebs 0 statistics enable #这样财务网段访问ERP的流量被放行，同时被限速在4Mbps（cir 4096 kbps）。限速参数怎么定？cir是承诺速率，一般按业务并发量估算。cbs是承诺突发尺寸，理论上允许瞬间超过cir的字节数，建议按cir乘以200ms到1s折算。比如cir 4096kbps，cbs取512000字节基本够用，追求更平滑可以加大几倍。
同一个分类器，行为里加了car就能限速，加了remark就能改优先级，换了deny就能丢弃。这就是模块化设计在生产环境里最实打实的好处。
4. 策略路由+MQC组合拳：把过滤和分流放进同一个策略
4.1 场景设定：视频会议流量强制走专线，其余流量不动
前面解决了“拦和放”，标题里还有半截是策略路由。一个典型场景：分公司出口有两条链路，一条是到总部的专线，带宽有保障但成本高；一条是普通互联网出口。视频会议流量必须走专线，P2P下载流量必须拦截，其他办公流量走默认路由。
这类需求以前的做法是配传统策略路由，单独一套policy-based-route，再单独配ACL做过滤。现在全都可以并进一个MQC策略里，思路非常顺。
4.2 一个策略搞定三类流量：分类、行为、绑定
视频会议流量一般通过DSCP标记识别，假设它是ef；P2P流量可以用ACL按端口和应用特征匹配。
acl number 3201 rule 5 permit tcp destination-port eq 4662 rule 10 permit tcp destination-port range 6881 6889 # traffic classifier video if-match dscp ef # traffic classifier p2p if-match acl 3201 # traffic behavior to_mpls redirect ip-nexthop 10.255.0.2 statistics enable # traffic behavior drop_p2p deny statistics enable # traffic policy branch_ingress classifier video behavior to_mpls classifier p2p behavior drop_p2p #把策略应用在面向终端用户侧的接口入方向：
interface GigabitEthernet0/0/0 traffic-policy branch_ingress inbound #这段配置同时干了三件事：视频流量进专线，P2P流量直接被丢弃，其他流量没匹配到任何分类器，正常走路由表。第一个分类器命中的流量完全不受路由表影响，硬件直接根据重定向下一跳转发。
这就是策略路由的本质：普通路由表由目的地址决定转发方向，策略路由由流量特征决定转发方向。MQC做的就是把“特征匹配”和“转发动作”用标准框架组织起来。
4.3 匹配顺序与命中优先级：分类器顺序决定命运
多个分类器同时匹配同一股流量时，MQC按什么顺序执行？这是最容易踩坑的地方。两种模式：按配置顺序匹配，或者按优先级自动匹配。
按配置顺序匹配，也就是策略里分类器写的先后顺序，从上到下逐条匹配，命中一条就执行，后续不再看。前面财务网段那个例子里，必须先写erp_access再写finance_all，就是基于这个原理。
按自动匹配，设备会根据分类器里条件的精度自动排优先级，比如精确匹配IP地址的排前面，匹配端口范围的排后面。这个模式用起来省心，但可预测性差，生产环境下我不太推荐。控制力优先，建议在分类器创建时就显式指定匹配优先级：
traffic classifier video type match if-match dscp ef #不同厂商对“自动优先级”的判定逻辑不一样，如果你在两个厂商的设备上做相同配置，排序结果可能完全不同。所以我习惯自己控制顺序，把精确匹配的、业务关键的放前面，宽泛匹配的放后面，宁可靠配置顺序把行为管死，也不赌设备自动排出来的结果。
还有一个需要注意的：如果两条分类器规则都想让同一个流量“先过一道再走下一步”，比如先统计再匹配下一级策略，就得用嵌套策略而不是平铺式写了。平铺式MQC里，命中即终局。
4.4 MQC策略路由与传统策略路由：差异对照
写到这里，把MQC策略路由和传统策略路由的差异说清楚，方便你判断什么场景用哪个。
| 对比维度 | 传统策略路由 | MQC策略路由 |
|---|---|---|
| 配置视图 | policy-based-route独立体系 | traffic policy统一体系 |
| 匹配条件 | ACL为主 | ACL、DSCP、VLAN、接口等均可 |
| 附带动作 | 一般是set next-hop | reroute之外可叠加CAR、remark、deny |
| 统计能力 | 较弱 | 按classifier独立统计 |
| 与QoS联动 | 需要额外工具 | 天然同框架 |
| 适用场景 | 简单分流 | 分流+过滤+限速一体 |
实际选型时，如果只是“目的地址X走某下一跳”，传统策略路由一把梭完全够用，配置短平快。但凡是牵扯到“不同流量不同处理策略”“过滤和分流要同时做”“需要精细统计”，MQC方式明显更合理。现在新建项目我几乎默认MQC方案，因为后期扩展性好，加需求不用推翻重来。
5. 实操避坑实录：配置MQC时我踩过的五个坑
5.1 坑一：接口方向选错，过滤变成形同虚设
某次给一个客户配出口策略，需求是拦住内网访问某些外部地址。我把策略下发在接口的outbound方向，结果一直没生效。查了半天，原因是客户那边内网流量到达出口设备时，已经在入方向完成了大部分处理，等到了出方向再过滤，设备转发路径已经走了大半，部分芯片转发流程里出方向过滤不支持，或者已经查完路由缓存了，策略根本拦不到。
最终把策略挪到内网侧接口的inbound方向，立刻生效。过滤类策略我现在的习惯是全部在入方向做，理由很简单：流量刚进来就处理，省了后续无效消耗，而且方向语义清晰。策略路由同样优先入方向，因为重定向动作必须在查路由表之前生效。
5.2 坑二：把自己管理地址段deny掉，直接断连
这是我最疼的一次经历。有一回在远程设备上调试，写了一个分类器匹配全部目的地址，behavior配了deny，想着“先挂上去再加白名单”。结果策略一应用，自己登录设备的源地址也被匹配进去了，会话直接断开，整个人傻眼。
后来长记性了，所有涉及deny的MQC策略，第一条分类器一定留给自己：匹配管理网段或者本机IP的流量，behavior放行，然后再写deny其他。
traffic classifier manage_allow if-match acl 3000 # traffic behavior pass_admin permit # traffic policy safe_filter classifier manage_allow behavior pass_admin classifier deny_other behavior drop_all #哪怕设备远程管理走的是带外管理接口，也要养成这个习惯。MQC策略如果应用到业务口，控制面流量和业务面流量有时候同接口，保命白名单永远前置。
5.3 坑三：多条分类器顺序写反，规则全被第一条吞掉
流量过滤例子里我已经强调过一次，再展开说说。策略里连续两条规则：erp_access放行ERP流量，finance_all丢弃财务网段所有流量。如果顺序反过来，财务网段任何流量都先命中finance_all，被deny，erp_access永远匹配不到、永远没机会执行。
原理很简单：平铺式策略里，流量按分类器顺序匹配，命中即执行、执行即结束。所以顺序设计不是小事，我总结了一个排序经验：
- 优先放行/重定向的关键业务放前面
- 精确条件排在宽泛条件前面
- deny放后面，除非它的匹配范围比前面的更精确
- 实在拿不准，先在测试环境抓包看命中统计
5.4 坑四：ACL里的deny写顺手了，导致分类器匹配为空
前面说过，MQC分类器里用ACL时，deny规则意思是“不匹配”。实际操作里，很多人直接用现有ACL来当分类器，结果现成ACL里既有permit又有deny，放在MQC里逻辑就乱了。
比如ACL里本来有一条deny用来挡某段地址，在传统接口过滤场景它是对的，但搬进MQC分类器后，deny规则会让这部分流量直接不匹配，自然也就不会进入关联的behavior。你以为策略会丢包，其实策略根本看都没看那包一眼。
解决方案是给MQC单独设计ACL，里面只写permit，专门用来“圈出目标流量”。行为里该deny、该permit、该redirect，都是behavior的事，ACL别越权。
5.5 坑五：策略改了没保存，设备重启一夜回到解放前
这个坑说出来有点丢人，但真的普遍。某次割接，现场把traffic policy反复调了好几版，验证全部通过，收工回家。第二天设备断电重启，所有流量裸奔，因为配置没写入启动配置文件。
MQC策略调试期很容易处于“先用先试”的状态，敲完命令觉得没问题就忘了save。我的习惯是每改完一版策略，验证通过后立即保存，保存前再快速过一遍diff。远程设备操作时，这个习惯能救命。
5.6 厂商差异速查：A厂、B厂、C厂关键区别
MQC思路上各厂一致，命令表达有差异。做个速查表，方便你换设备时快速上手。
| 环节 | A厂风格 | B厂风格 | C厂风格 |
|---|---|---|---|
| 分类器 | traffic classifier | class-map | traffic classifier |
| 行为 | traffic behavior | policy-map | traffic behavior |
| 策略 | traffic policy | policy-map | traffic policy |
| 接口应用 | traffic-policy | service-policy | traffic-policy |
| 匹配命令 | if-match | match | if-match |
| 丢弃动作 | deny | drop（或policy-map中显式行为） | deny |
具体到某一款设备，命令细节还会有差异，比如行为动作的拼写、嵌套策略的写法、统计开关的位置。但三层结构是雷打不动的，你先用A厂思路把方案设计清楚，换到B厂、C厂只是一层翻译工作。
我个人有个习惯：不管在哪个厂商的设备上配MQC，都会在命名上做统一规范。分类器前缀用cl-，行为用bh-，策略用pl-，再加业务名。比如cl_video、bh_to_mpls、pl_branch_ingress。这样在大规模设备上排查配置时，扫一眼就能定位逻辑关系，不用翻完整段配置去猜。
最后再分享一点小经验
MQC这个东西，光看文档容易觉得“不过如此”，一旦上了生产环境，各种交互细节就冒出来了。个人建议你手里有点时间的话，用模拟器或者测试机把这些场景完整跑一遍，重点不在于敲命令，而在于用display命令观察行为。比如同一个流量同时匹配两条规则时实际走哪条，比如deny行为下发后命中计数是否增长，这些手感是文档教不会的。
上面这些配置我都在实际项目里验证过。策略路由-MQC这条线的下一讲，我打算把QoS队列调度和CBQ配置一起讲掉，把限速、重标记和队列调度串成一个完整的带宽保障方案。到时候会把出方向队列策略和入方向过滤策略怎么配合写清楚。点赞收藏不迷路，有具体配置问题直接评论区丢出来，我挑典型的下篇拆解。
