首页 / 资讯中心 / 文章详情

MQC配置实战:策略路由与流量过滤全解析

MQC配置实战:策略路由与流量过滤全解析 ★ FEATURED ARTICLE
上一篇我把MQC模块化QoS命令的工作机制拆开讲了很多朋友留言说概念好懂一到命令行就懵——class-map、policy-map、service-policy这三个单词在设备上敲下去到底谁先谁后动作写在哪里为什么挂了策略以后流量纹丝不动这篇我们直接开干先把MQC基本配置从头到尾跑一遍再用两个真实场景把配置落地一个是大家问得最多的MQC策略路由让指定流量走指定出口另一个是标题里提到的PQC流量过滤——其实不用被这个缩写绕住PQC指的就是MQC策略对流量做放行或丢弃的过滤动作本质还是同一套框架。读完这篇你既能照着命令敲出一份可用的配置也能在策略不生效的时候知道去哪查问题。1. MQC整体架构回顾先搞清楚三个拼图的咬合关系1.1 class-map、policy-map、service-policy各自的角色很多人在敲MQC命令之前没有先在脑子里把三个核心对象的职责分清楚结果就是命令敲得飞快排错排到怀疑人生。class-map负责“认人”它就是分类器你告诉设备哪些流量算一类比如“来自192.168.10.0/24的流量”、“TOS字段是EF的流量”、“目的端口是80的TCP流量”。policy-map负责“下指令”它把某个class-map和一组动作绑在一起比如“对刚才那类流量重定向到10.0.0.1”或“直接丢弃”。service-policy负责“选址”它把整份policy-map挂到某个接口的某个方向上从这一刻起策略才真正在数据通路上生效。这三个东西的关系可以拿快递分拣线打比方class-map是分拣规则什么样的包裹走哪条线policy-map是分拣动作推入A通道还是B通道service-policy是分拣线装在哪个分拣口。你单独给分拣员讲清楚规则或单独装好传送带包裹都不会自己流动起来必须三者串好才有效。很多配置不生效原因恰恰是只写了其中一两个环节或者把动作写错了层级。1.2 为什么说MQC是ACL和PBR的“升级版”传统ACL能做匹配但匹配完只能permit/deny没有更多动作。传统策略路由PBR能做重定向但没法同时做标记、限速和统计。MQC等于把“匹配”和“动作”彻底解耦一个class-map能被多个policy-map引用如果你有十台设备要下发同样的分类逻辑改一处就行policy-map里的动作也不是死板的可以组合remark、drop、redirect、car限速、queue队列调度。更关键的是MQC天生带统计计数你可以直接查看某个class命中了多少包、多少字节这对排障是极大的便利。传统ACL想统计命中次数还得靠counter或debug累人。我在现场排查时只要看到某个class的计数一直在涨基本就能锁定流量确实被这条策略处理了剩下的只是判断处理结果是否符合预期。1.3 四条命令完成框架MQC基本配置只有四步顺序不能反。第一步用class-map定义“谁”即流量分类。第二步在策略里定义“做什么”即动作。有些厂商把这步拆成独立的traffic behavior但概念一致。第三步用policy-map把“谁”和“做什么”组对。第四步在接口上service-policy落地指定方向。记住这个顺序命令就能围绕一个目标组织起来而不是东敲一句西敲一句。2. MQC基本配置从零跑通最小可用实例2.1 定义流分类class-map的匹配语法先看最核心的分类器。通用语法是class-map match-all CM_OFFICEmatch-all表示所有条件都满足才算命中match-any是任一条件满足就算命中。下面一行接着写match语句比如match access-group 2000引用ACL编号、match dscp ef、match ip precedence、match protocol http。我建议刚上手的朋友统一用ACL作为匹配载体因为ACL只看包头的五元组最直观。match dscp这类条件适合做QoS标记流但在流量过滤场景里容易误伤比如你以为只有视频流量打了EF结果发现一堆应用都打EF。另外要注意不同厂商的分类器命名不同。有的叫class-map有的叫traffic classifier表达的意思完全一样。你要是习惯某厂商的命令体系把关键字替换过来就行后面的结构逻辑通用。2.2 定义流行为policy-map里的动作组合在MQC里动作不能单独存在它必须挂在class下面。你先定义好policy-map然后进入class子节点再写动作。常用动作有remark dscp重新标记优先级、drop丢弃、redirect ip-nexthop X.X.X.X重定向到某个下一跳、car限速、queue队列调度。拿最常用的QoS标记举例如果你希望办公流量进入核心设备前被打上EF标记就在policy里写remark dscp ef。注意remark动作对某些老设备只在出方向生效具体看设备文档这是个常见的坑。我一开始也吃过亏在入口给流量打标记结果到对端一看DSCP纹丝不动查了文档才发现这台设备的remark动作只支持出方向。2.3 定义策略把class和行为绑定的policy-map策略本身不产生作用它只是分类器和动作的表单。进入policy-map后用class CM_OFFICE进入这个类的子节点然后写具体动作。一个policy-map下可以有多个class节点设备会按顺序逐一匹配被前面class命中的流量不会再被后面的class处理所以顺序敏感。经验是先写范围小的、精确的匹配条件再写范围大的、兜底的。最容易漏的点是class-default它是默认类所有没被任何class匹配的流量都会落到这里。class-default的默认动作通常是pass放行如果做白名单过滤记得把它的动作改成drop。很多“策略不生效”的现场其实不是策略没生效而是默认类把流量全放走了。2.4 挂载与方向service-policy写在哪一侧最后一步是挂载。在接口视图下执行service-policy input PM_MARK或service-policy output PM_MARK。挂哪侧要看你希望流量在查表前还是查表后被处理。通常入方向适合做过滤、标记、重定向因为这时还没决定从哪个接口出去。出方向适合做限速和队列调度因为这时转发路径已经定下来了。注意一个接口的一个方向只能挂一份policy-map。想加新策略就并存不了只能改原策略或重新设计分类。很多人在接口上反复执行service-policy后一条不会叠加而是直接覆盖前一条敲之前一定要看清楚。2.5 最小实例打标记跑通全流程下面给一个能直接抄作业的最小配置。场景一台三层交换机做办公网出口要求把来自192.168.10.0/24办公网的流量重新标记为EF其他流量保持默认。先写ACL抓办公网段再定义class再定义policy做remark最后挂在入口。acl number 2000 rule 5 permit source 192.168.10.0 0.0.0.255 class-map CM_OFFICE match access-group 2000 policy-map PM_MARK class CM_OFFICE remark dscp ef class class-default pass用service-policy input PM_MARK挂到接办公网的接口上。验证时在接口抓包或者查看匹配统计正常能看到CM_OFFICE的匹配包数在涨。如果你发现匹配数为零先回头查ACL编号引用对不对这是半数以上问题的根源。3. MQC策略路由实战让指定流量走指定的下一跳3.1 为什么用MQC做策略路由传统策略路由PBR通过route-map配置也能重定向流量但有个痛点route-map是单独一套语法调试还不带统计。MQC做策略路由是把redirect动作包在policy-map里你可以顺便加remark和car一份策略同时解决路径选择、优先级、限速三个问题。我在实际项目里更愿意用MQC做PBR还有个原因是MQC的策略层次清晰。接手的人打开配置看到class CM_OFFICE下面写着redirect ip-nexthop 10.0.0.1一眼就明白意图。换成route-map里的set ip next-hop光是对着几十条set语句就头疼。3.2 场景拆解办公网段走专线其他流量走默认出口假设公司网关出口有两根链路一条专线连总部一条连接互联网的默认出口。需求是让办公网段192.168.10.0/24的所有流量都走专线到10.0.0.1其余流量按路由表正常走默认。这个场景在分支机构很常见外部业务系统访问需要经过专线普通上网流量不需要。传统做法是写一条静态路由指向专线但静态路由管不了“特定源地址”这种条件。如果你在出口设备上做策略路由就用MQC的方式ACL抓源地址class-map匹配ACLpolicy里重定向到专线侧下一跳。3.3 配置全过程ACL class-map policy 挂载还是那个熟悉四步。先定义ACL 2000只放行源为办公网段的流量再定义class CM_OFFICEmatch access-group 2000然后定义policy PM_PBRclass CM_OFFICE的动作写redirect ip-nexthop 10.0.0.1最后在入口接口挂载service-policy input。acl number 2000 rule 5 permit source 192.168.10.0 0.0.0.255 class-map CM_OFFICE match access-group 2000 policy-map PM_PBR class CM_OFFICE redirect ip-nexthop 10.0.0.1 class class-default pass interface GigabitEthernet0/0/1 service-policy input PM_PBR我特意把class-default也写了pass这是安全习惯策略只影响指定流量其他流量绝对不能被牵连。如果你不写class-default不同设备默认行为不同有的放行有的丢弃经验不够的话很容易上线后才发现非办公网段全断了。3.4 验证技巧与回程路由的坑配置完成后的验证不能只ping一下因为ping不一定走了你期望的路径。正确做法是在办公网段内的一台机器上traceroute到总部业务服务器看第一跳是不是10.0.0.1。如果第一跳还是默认网关说明策略根本没命中。还有一个特别容易翻车的点只重定向了去程忘了回程路由。专线到达总部之后总部返回办公网段的数据包如果查路由表发现没有指向办公网段的路由就会丢包。很多新手配完策略路由发现单向通就是这个原因。所以在做策略路由前要先确认专线两端的路由都能互相指。另外redirect ip-nexthop这个动作本身不参与路由递归查找它直接改写转发下一跳但前提是这一跳的接口是up的。如果对端路由器接口down了重定向就不会生效策略会自然失败回落到正常路由转发这反而是一个可用的逃生机制。4. MQC流量过滤PQC实战白名单模式与黑名单模式4.1 三类典型的流量过滤诉求标题里说的PQC流量过滤我理解就是MQC策略对流量做放行pass或丢弃drop的动作不少资料里用PQCPolicy-based QoS Control泛指这套基于策略的流量控制。无论缩写怎么变核心思路一样你希望某些流量被拦掉。实际运维里流量过滤的诉求大概有三种。第一种是白名单模式某个网段只允许访问HTTP/HTTPS/DNS其他一律丢弃常用于服务器区、访客网络。第二种是黑名单模式只拦截某些高风险端口或已知攻击流量其余放行适合已经上线很久、不敢大动干戈的业务网络。第三种是审计模式流量先统计后决定是否拦截MQC的统计能力做这个很好用。4.2 设计要点先决定默认动作再决定过滤名单做流量过滤最忌讳上来就写drop规则一定要先想清楚默认策略。白名单模式的默认策略是“除名单外全部丢”class-default必须改成drop黑名单模式的默认策略是“除名单外全部放”class-default保持pass。很多配置问题的根源就是默认动作没想清楚。你在白名单模式下忘了改class-default的动作结果过滤规则挂上去后不该通的全通了还以为策略有问题。反过来黑名单模式下不小心把class-default改成drop那是妥妥的生产事故。我见过一次夜班同事本来只拦一个异常端口结果把默认类写成drop整段业务全断排查了大半夜。4.3 配置示例给访客网段开一个白名单过滤实战一个白名单场景访客网段192.168.20.0/24只允许访问TCP 80/443和UDP 53其他流量全部丢弃。先定义ACL 3000放行上述端口再定义class-map引用它policy里给这个class写passclass-default写drop最后挂在访客网络的入口。acl number 3000 rule 5 permit tcp destination-port eq 80 rule 10 permit tcp destination-port eq 443 rule 15 permit udp destination-port eq 53 class-map CM_VISITOR_OK match access-group 3000 policy-map PM_FILTER class CM_VISITOR_OK pass class class-default drop interface GigabitEthernet0/0/2 service-policy input PM_FILTER注意ACL里只写了目的端口没有写源地址。如果你只在这个网段接口上应用策略那没问题如果这个策略同时挂在别的接口那就误杀了。建议在ACL里再叠加source 192.168.20.0 0.0.0.255让匹配条件更严格防止策略复用到其他接口时出问题。4.4 MQC过滤和纯ACL过滤怎么选很多新同学会问既然ACL也能deny为什么要绕一圈用MQC我的建议是规则少、不关心统计用ACL规则多、要排障、要组合动作用MQC。MQC的价值在于每个class都有计数器设备被过滤掉的流量是哪些、命中多少包用查看命令一目了然。ACL也带计数器但没法像MQC这样把一组ACL加动作显式地绑定展示。MQC的代价是配置量更大、对老设备的转发性能有额外开销。如果你在老旧核心设备上做几百条过滤规则CPU蹭蹭涨那就要权衡是否拆到边界防火墙上处理。另外MQC的过滤在转发层面做对已建立会话的流量仍然会逐包判断不像防火墙有会话机制遇到长连接大流量时要关注设备性能。5. 常见问题与排查技巧实录5.1 策略不生效先查挂载位置和方向排MQC问题有一个固定顺序先看策略挂没挂对接口再看方向对不对再看class有没有匹配上最后看动作有没有写错。很多人一上来就看class结果发现service-policy根本没挂到正确的接口上白忙一场。接口方向这个坑非常普遍。过滤和重定向通常挂在入口也就是流量进来的那个接口。如果你接的是内网侧那入口就是内网接口如果你放在外网侧出口对于出方向的流量来说它进入设备时走的是内网接口而不是外网接口。方向搞反了策略当然不生效。查看命令上用show service-policy interface或display qos policy interface能看到这个接口上有没有挂策略、每个class命中多少包。如果想看class和policy的定义用show class-map和show policy-map。5.2 class-map里ACL引用错了匹配数为零我排过的MQC问题里比例最高的是ACL编号引用错误。有人ACL定义的是2000class-map里写成了2001设备不会报错就是一直不匹配。还有ACL规划时rule没写够比如源地址写成了192.168.10.0 0.0.0.0那是精确匹配单台主机自然谁也匹配不上。排查时先show access-list看ACL本身的计数器有没有涨。如果ACL计数涨了、class计数不涨说明class-map的match语句写得有问题如果ACL计数就是零问题在ACL规划本身。5.3 match-all和match-any选错分类器的匹配逻辑只有两种match-all要求所有match条件都满足match-any只要满足任意一条就算。很多新手把多个match条件堆在一个class-map里以为会按“或”处理结果默认是match-all两条条件一会都满足流量永远匹配不上。一个典型例子你想匹配“来自192.168.10.0/24的流量”或“目的端口是8080的流量”如果你用match-all那必须是“来自办公网段且目的8080”的流量才命中跟你的意图完全相反。这时候应该用match-any或者拆成两个class-map分别处理。5.4 重定向黑洞与递归路由策略路由的redirect动作有个特性它不查路由表直接把下一跳写死。这个特性带来两个隐患。第一如果你把下一跳写成了对端不存在的地址匹配流量会被发往一个没有出口的黑洞。第二如果对端路由器和本机之间没有直连路由数据包也送不出去。所以在执行redirect命令之前先用show ip route确认下一跳可达。我还习惯给重定向策略留一个“逃生通道”把class-default显式写成pass并且保证正常路由表有默认路由。这样即使专线断了办公网段流量会回落到默认出口业务不会完全中断只是路径与预期不符至少比全断强。5.5 白名单过滤上线后的误杀回放白名单过滤最容易翻车的时刻是上线后业务报障。你做完了class-default drop第二天业务系统说“ERP访问不了了”排查路径很清晰用查看命令看class的统计发现ERP流量命中了class-default被drop。原因往往是ACL里没放行ERP使用的端口或者端口在非标端口上。我的做法是上线前先抓一段实际流量看看目标网段的访问端口有哪些整理一份端口清单再写进白名单ACL。宁可先多放行一个端口稳定一周后再收窄也别一上来就卡死。运维圈有一句老话策略越紧晚上电话越多。这个经验在流量过滤上特别适用。5.6 常用查看与排错命令速查表最后把我在现场最常用的命令整理成一个速查表方便贴在手边。想确认的事情通用查看命令说明接口上挂了哪些策略show service-policy interface / display qos policy interface会列出接口方向、策略名和各class计数策略定义是否正确show policy-map / display qos policy查看policy里各class的动作class的匹配条件show class-map / display traffic classifier确认match语句ACL匹配计数show access-list / display acl判断是ACL没匹配还是class没引用某类流量命中情况show policy-map class XX / display qos policy class XX看这个class的包数和字节数增长这些命令在不同厂商设备上名称略有差异但你能看到的字段基本就是接口方向、分类名、匹配包数、动作类型。养成挂策略三分钟后看一眼计数的习惯能少踩一半的坑。最后再说一点我在长期维护里的体会。MQC这套框架真正难的不是命令而是“先分类、后动作”的思维方式。很多配置混乱都是因为人一开始没想清楚流量该怎么分直接在policy里堆条件改到最后连自己都绕进去了。我现在的习惯是不管多大的项目先在纸上把所有流量类别列成一张表每一类写清楚它的源、目的、走哪条路、要不要标记、要不要限速、要不要丢弃然后才动手敲class-map和policy-map。分类表定下来了配置只是把它翻译成MQC语法而已。你下次遇到策略路由或流量过滤的活不妨也试一下先列表后敲命令真的能省下很多排障时间。
阅读完成 · 觉得有帮助?
咨询建站