★ FEATURED ARTICLE 做网络运维这些年我越来越觉得MQC模块化QoS命令行是被低估的一套工具。很多人一提QoS就想到限速一提过滤就想到ACL但实际上把MQC吃透之后流量过滤、优先级标记、限速、重定向这些需求都可以用同一套分类-行为-策略框架统一解决配置逻辑非常清爽。这篇是MQC系列的第二篇重点是基本配置和流量过滤从原理讲到命令再到我在现网上排错时真实踩过的几个坑尽量一次讲透。适合正在学数通基础、准备设备认证或者需要在组网里做精细化流量控制的同行参考。先说一个很多人没想明白的点MQC不是某个具体功能而是一种配置组织方式。它把复杂策略拆成三个独立部件——流分类、流行为、流策略然后再把策略绑定到接口上。好处是你可以在多个接口复用同一套策略也能在不改动ACL的情况下单独调整某类流量的动作。下面我按自己实际配置的顺序把整个过程展开。1. 先把MQC三要素拆开分类、行为、策略到底在配置什么1.1 三要素的职责边界MQC的整套逻辑可以压缩成三段式先定义哪些流量再定义拿这些流量怎么办最后把两者组合起来并绑定到接口。对应到命令上就是三类配置块traffic classifier流分类负责描述报文的匹配条件例如源地址、目的地址、端口号、DSCP值、VLAN、甚至上下行接口。traffic behavior流行为负责定义动作。最常见的是permit、deny也就是流量过滤里的放行和丢弃后续还可以叠加限速、重标记、重定向。traffic policy流策略把分类器和行为绑定在一起并给每个分支设置优先级最后整体应用到接口的入方向或出方向。类比一下生活场景分类器像门禁的识别规则行为像保安的执行动作策略像整套门禁方案接口绑定则是把这套方案装到某一扇门上。这样拆开之后新增一种流量的过滤规则时完全不需要动其他部分。1.2 和传统ACL接口政策的差异早期配置流量过滤通常是直接在接口下写ACL或者把ACL套到接口的traffic-filter上。这种方式在小规模场景里够用但问题很明显多个接口要做相同过滤时配置冗余想调整某一类流量的动作时只能删掉整个ACL重新写ACL和动作绑定得太死没法灵活组合。MQC则把匹配条件和动作彻底解耦。同一套ACL可以被不同流分类引用同一个流行为也可以被多个流策略复用。举个我在某园区网络里的例子出口路由器上既要过滤内网访问某个高风险端口段的流量又要对视频流量做DSCP重标记还要限制P2P下载带宽。若用传统方式三个需求就要在接口上写三套ACL策略互相穿插排错时根本分不清哪条规则管哪部分。用MQC拆开后每个需求各自独立策略之间互不干扰。需要留意的是MQC的本质是基于类的策略框架它本身不产生新的QoS能力而是把ACL、队列、限速等底层机制组织得更清晰。理解了这一点后面配置时你对每条命令的意图就会很明确。1.3 和策略路由有什么关系标题里的策略路由和MQC并不矛盾。策略路由的核心是根据策略决定报文下一跳而MQC是承载这个策略的框架之一。实际配置中流行为可以包含redirect ip-nexthop这类动作把匹配到的流量引到其他路径。也就是说MQC既可以做流量过滤deny/permit也可以变相实现策略路由这取决于你给行为块定义什么动作。本篇以过滤为主线最后我会专门讲一下如何扩展成重定向和限速。2. 一个我能复现的过滤场景拓扑、地址和过滤目标怎么定2.1 先说清楚过滤什么动手配置前最重要的事情不是敲命令而是把过滤目标写下来。我给自己设计了一个可复现的实验场景一台充当网关的路由器连接了两个网段一侧是办公终端所在的VLAN 10地址段为192.168.10.0/24另一侧是服务器所在VLAN 20地址段为192.168.20.0/24。业务需求有两条办公网段只允许访问服务器的TCP 80/443端口其他访问一律丢弃。办公网段内部允许互相访问但禁止访问服务器网段里一个测试用的高危端口段TCP 20000-20100。这个场景非常典型既要基于五元组做细粒度匹配又要对不同目的地址执行不同动作。用MQC实现时我会把它拆成两个流分类、两个流行为、一个流策略。2.2 接口和地址规划实验拓扑很简单可以用模拟器也可以用两台物理设备串联。我这里以一台三层设备为例接口规划如下接口用途地址GE0/0/1接入办公网段192.168.10.254/24GE0/0/2接入服务器网段192.168.20.254/24设备上先确保两个接口物理状态正常直连地址能互相ping通路由表里有对应直连路由。我习惯在配置策略前先做一轮基础连通性测试避免后面策略不生效时还要分心排查基础故障。2.3 配置思路的提前规划明确了需求之后我通常画一个简单的匹配决策表把每条流量对应到具体分类器和行为流量特征分类器名称行为名称动作目的TCP 80/443classifier_webbehavior_allowpermit目的TCP 20000-20100classifier_test_portbehavior_denydeny其他所有流量不匹配任何分类器默认放行permit这里有个细节MQC流策略默认对未匹配流量执行放行所以只要把需要丢弃的流量单独区分出来即可。如果你的需求是默认拒绝一切、只放行白名单就需要额外加一个匹配所有报文的分类器行为设为deny并把它放在策略的最低优先级。这个规划阶段看似麻烦却是我每次少走弯路的关键。到了命令行下面思路已经定了配置只是把表格翻译成命令而已。3. MQC流量过滤配置全流程从ACL匹配到接口绑定3.1 用ACL定义流分类的匹配条件MQC的流分类支持多种匹配方式比如if-match acl、if-match dscp、if-match vlan-id、if-match ip next-hop等。流量过滤场景下最常用的是匹配ACL因为ACL能表达五元组级别的精细条件。acl number 3001 rule 5 permit tcp destination-port eq 80 rule 10 permit tcp destination-port eq 443 acl number 3002 rule 5 permit tcp destination-port range 20000 20100注意ACL编号的含义2000-2999是基本ACL只能匹配源地址等简单字段3000-3999是高级ACL可以匹配协议、源目地址、端口号等。我的两个过滤条件都需要匹配目的端口所以都用高级ACL。定义完ACL后在系统视图下创建流分类并挂接ACLtraffic classifier classifier_web operator or if-match acl 3001 traffic classifier classifier_test_port operator or if-match acl 3002这里有一个经常被忽略的点operator or表示分类器内多个匹配条件之间是或关系只要命中任意一条就算匹配如果写成operator and则所有条件必须同时满足。我这两个分类器里都只引用一个ACL所以or/and效果一样但后续如果你要叠加多个匹配条件一定要提前想清楚逻辑关系。3.2 定义流行为过滤就是permit和deny流行为块里的permit和deny对应到流量过滤就是放行和丢弃。traffic behavior behavior_allow permit traffic behavior behavior_deny deny不少新手看到permit会下意识以为这是ACL里的permit把两边混淆。实际上这两层是独立生效的ACL里的permit只是让报文被这个分类器选中真正决定报文最终是通过还是丢弃的是流行为里的动作。ACL如果写deny那么这条流压根不会进入分类器后续的permit/deny动作都不会执行这会导致策略表现莫名其妙地不匹配。我在第4节会专门展开这个坑。3.3 组策略并在接口上生效有了分类器和行为接下来用流策略把它们串起来traffic policy policy_filter classifier classifier_web behavior behavior_allow precedence 10 classifier classifier_test_port behavior behavior_deny precedence 20precedence是策略内部的匹配优先级数字越小越先匹配。报文进入策略后先和优先级最高的分类器比对匹配就执行对应行为不再往下匹配。我上面之所以把classifier_web设为10、classifier_test_port设为20主要考虑到web放行是正常业务流量应优先处理。然后绑定到接口interface GigabitEthernet0/0/1 traffic-policy policy_filter inbound在GE0/0/1的入方向应用意味着从办公网段进入设备的所有报文都要经过该策略过滤。方向选择非常关键办公终端访问服务器流量从办公网段进入设备所以在GE0/0/1的inbound方向应用如果需求是限制从服务器方向进入办公网段的流量则应该绑定到GE0/0/2的inbound或GE0/0/1的outbound。方向搞反是MQC配置失败最常见的原因之一。3.4 验证配置和实际效果配置完成后先查看策略是否成功挂载display traffic policy applied record确认接口、方向、策略名都正确。然后测试办公终端访问服务器的80端口和20000端口同时用设备侧统计观察命中次数display traffic policy statistics interface GigabitEthernet0/0/1 inbound理想结果是访问80/443命中behavior_allow分支访问20000端口命中behavior_deny分支丢弃计数增长。到这一步最基础的MQC流量过滤已经跑通了。实际网络环境里可能还会碰到策略不生效、误伤正常流量、设备CPU占用上升等问题下面重点讲排查思路。4. 策略不生效的排错链路我实际遇到的三类问题4.1 坑一ACL的permit/deny和多层动作叠加搞混有次现场反馈说办公网段的终端访问服务器端口全部不通但配置明明是按白名单放行的。我登进设备一看ACL 3001里写的是acl number 3001 rule 5 deny tcp destination-port eq 80 rule 10 permit tcp destination-port eq 443第一眼很难发现问题因为这组ACL挂在classifier_web下面而流行为是permit。按很多人的直觉ACL deny了80端口那80端口就被拒了这没错但问题在于ACL deny掉的流量根本不会进入分类器所以流行为里的permit对这条ACL规则完全不起作用。最终表现就是所有目的端口为80的报文在分类器这一层就被排除了看上去像被过滤实际上是被ACL拒绝而不是被流行为处理。ACL在MQC里的角色是选择器它负责决定哪些报文进入分类器而不是直接决定报文生死。正确的做法是ACL规则全部写成permit只描述匹配特征真正的放行或丢弃交给流行为。用deny写ACL只会让报文失去后续处理机会。4.2 坑二接口方向选错导致策略静默失效另一个常见问题是策略绑定到了错误方向。某次客户在出口路由器上做了入方向的流量过滤要求过滤内网访问外网某端口的流量配置完成后测试发现完全不生效。我检查发现策略被绑定在了出接口的outbound方向而内网流量到达出接口时已经被路由处理完了出方向策略实际上针对的是即将从该接口发出的报文和内网访问外网的流量方向相反。判断方向时我习惯先画一条流量路径源终端 - 源接口入方向 - 设备转发 - 目的接口出方向 - 目的终端。要过滤的是哪一段路径上的流量就绑定到对应接口的对应方向。对于网关设备过滤进入的流量一般用入接口的inbound过滤发往某个方向的流量则用出接口的outbound。4.3 坑三策略内优先级顺序导致误匹配优先级问题往往在复杂策略里出现。假设策略里有两条分类器classifier_a匹配目的端口8080动作是denyclassifier_b匹配目的地址192.168.20.0/24动作是deny如果classifier_b的优先级是5classifier_a的优先级是10那么访问服务器8080端口的报文会先匹配classifier_b并被deny而classifier_a的逻辑根本不会执行到。从结果看访问8080端口确实不通但你无法判断是a规则生效还是b规则生效排错信息就会很混乱。更危险的是如果某条宽泛匹配的分类器优先级过高它可能吃掉后面所有更精细化分类器的流量导致后者的deny/permit完全不生效。我现在的习惯是越具体的匹配条件优先级越高precedence数字越小宽泛条件放在后面兜底。每次修改策略后用统计命令确认每个分支的命中计数是否符合预期而不是只看通不通。4.4 排错工具的使用顺序遇到策略不生效我建议按以下顺序排查不要一上来就怀疑设备有bug确认策略已正确应用display traffic policy applied record重点看接口名、方向、策略名。确认流量确实经过了该接口方向用display interface看接口流量计数是否增长。确认分类器命中情况display traffic policy statistics看哪个classifier匹配次数是0。若所有分类器匹配次数都是0多半是ACL条件写错了或者ACL里用了deny导致报文进不了分类器。若匹配次数在增长但业务还是不通重点看流行为动作以及后续是否有其他策略或路由策略覆盖了结果。这套链路我每次都能定位到问题根因基本没有落空过。5. 从过滤到QoS全家桶限速、重标记和策略路由联动5.1 用MQC做限速流量过滤只是MQC的入门动作。在同一个框架下把流行为改成限速也很简单traffic behavior behavior_limit car cir 8000 pir 10000cir是承诺信息速率单位通常为kbpspir是峰值信息速率。理解上可以类比水管CIR是保证流量PIR是允许突发的水量上限。把行为绑定到指定流量后就能实现只对某类流量限速其余流量不限制的精细化QoS。相比在接口上做整体限速MQC的优势在于可以区分用户、业务和目的网段。5.2 用MQC重标记报文优先级另一个常用动作是重标记DSCP或802.1p优先级traffic behavior behavior_remark remark dscp ef匹配到的流量被标记为EF后下游设备就可以依据这个标记做队列调度实现端到端的差分服务。这个场景非常实用内网视频会议流量从终端发出时优先级较低穿过中间设备时可能被普通流量挤占在入口设备上用MQC识别视频流并重标记后面的转发设备就能识别并优先处理。5.3 扩展成策略路由redirect到其他下一跳回到标题里的策略路由。在MQC流行为中可以直接指定报文的下一跳或出接口traffic behavior behavior_redirect redirect ip-nexthop 10.1.1.2 traffic policy policy_pbr classifier classifier_special behavior behavior_redirect precedence 5这样匹配到的流量会被强制引导到10.1.1.2而不是根据路由表正常转发。这时候MQC实际上承担了策略路由的工作且策略的匹配条件比传统PBR更丰富能叠加ACL、DSCP、VLAN等维度。我通常建议把MQC重定向当作策略路由的一种灵活实现方式特别是在分类器条件较多的组网里比单纯写PBR策略更易维护。5.4 配置规模与性能边界MQC虽好但不是没有代价。每增加一个策略分支设备在转发面上就需要多维护一条匹配规则分类器越多匹配耗时越长。在低端盒式设备上我曾经把流策略扩展到几十条分类器结果发现接口转发性能明显下降ping时延抖动。后来我把匹配项合并能用一条ACL描述的就不拆成多个分类器同时把策略应用下沉到接入层设备分散匹配压力问题才解决。另外不同厂商对MQC的层次和调度算法有差异迁移配置时要先核对语法和特性支持情况不要想当然照搬。6. 一些关于MQC配置顺序与维护的小习惯6.1 配置前先备份修改前先看统计我在现网上凡是涉及MQC变更都坚持先备份配置文件并对现有策略做一次display traffic policy statistics快照。这样做的好处是改完后可以通过计数对比快速判断新策略是否真的生效以及是否误伤其他流量。6.2 命名规范和注释意识MQC配置多了以后最难维护的不是命令而是当时为什么这么写。给分类器、行为、策略起名时我会加入业务语义比如classifier_video_conf、behavior_limit_p2p而不是classifier1、behavior1。同时我会在配置关键节点用备注说明流量来源、业务归属和联系人。别觉得这是形式主义半年后回头看配置时清晰命名能省下大量沟通成本。6.3 小步变更逐步验证一次性把过滤、限速、重标记、重定向全部加进同一个策略出问题后很难隔离。我的做法是一条业务需求对应一个分支配置完立即用测试流量验证确认无误后再加下一个分支。正验证负验证都要做既测试应该放行的流量也测试应该丢弃的流量两边都符合预期才算真的配置正确。我自己在多次MQC调试后最大的体会是这套框架的价值不在于单个功能有多强而在于它让你把匹配和动作分开思考逼迫你在配置前就把流量模型理清楚。只要前期规划到位后面无论过滤、限速还是策略路由都只是往行为块里加动作而已。希望这篇记录对正在折腾MQC的你有实际帮助。
阅读完成 · 觉得有帮助？
