先从一个让我印象特别深的组网现场说起。两条运营商链路同时摆在面前领导问得很简单内网的核心业务走A线普通上网走B线语音流量要在A线上优先转发。听起来就是一个策略路由policy-based-routing加上QoS重标记能搞定的事但真上手做的时候才发现这里牵扯到两套完全不同的路由控制工具一类是策略路由另一类是以流分类、流行为、流策略为核心的MQC三板斧。这两套工具看起来都能“改变流量走向”但原理、配置方式和排查方法完全不一样。这篇文章我就从实际配置的角度把这两套东西掰开揉碎讲清楚给正在学数通或者刚接手企业网维护的朋友一份能直接落地的参考。1. 路由表说了算为什么还要策略路由1.1 一个看起来“路由正确”却完全不可用的例子很多人刚接触网络时脑子里只有一个模型路由器查路由表路由表里有哪条就走哪条。这个模型没错但它只解决了“这个目的地址下一跳是谁”的问题完全没有考虑“这个流量是哪来的”“这个流量是什么应用”“这个流量要不要加密送到指定出口”这类更细的业务诉求。举个例子。公司有一条默认路由指向A运营商A运营商链路带宽高但访问某银行系统的延迟抖动比较严重B运营商链路带宽一般但到银行系统恰好延迟很低。从路由表角度看所有上网流量都匹配默认路由下一跳固定走A没毛病。可业务部门立刻投诉说财务系统打开极慢必须走B线路。这时候你怎么办在路由表里给某个目的地址写一条更精确的静态路由当然是一种办法但如果你根本不知道目标网段会怎么变只知道“来源是财务网段”就要求走B线路静态路由就不好使了因为它只能按目的地址匹配不能按源地址匹配。这时候策略路由的意义就出来了它跳过了“先查路由表”这个顺序而是按照你定义的规则先去看流量特征命中规则就直接指定下一跳、出接口甚至隧道不命中才是按路由表正常转发。可以把它理解成在公司门口加了一个人工引导员不管车辆的总目的地是哪只要是“财务部派出来的车”统一引导到B门走。1.2 策略路由的工作原理抢在路由表之前做决定策略路由在数据面里的处理位置通常位于路由表查询之前或者说是“优先于普通路由查询”的强制路径选择机制。设备收到一个报文后会先用策略路由里配置的匹配条件去比对条件可以基于ACL、报文长度、DSCP优先级、入接口等。如果匹配上就执行动作比如把下一跳改成指定地址、指定出接口、设置报文优先级等。需要注意策略路由不是一个单独的路由协议也不产生路由表项它只是路由器转发流程中的一个“岔路口”。我一般跟学员这么比喻路由表是城市的主干道导航按目的地给你算一条路策略路由是路口的交警指挥哪怕导航说直行交警让你右转你得听交警的。交警指挥完的范围之外才是导航说了算。这也是策略路由最重要的特性它不修改路由表只影响匹配到的报文。所以做策略路由时路由表本身往往还是原来的样子默认路由、静态路由、动态路由该怎么写还是怎么写策略路由只是给特定流量“加塞”了一条特殊路径。1.3 和路由策略(route-policy)的区别别再把名字搞混这是面试里特别爱问的一个点也是实际排错中经常让人晕菜的坑策略路由和控制层面的路由策略是两码事。路由策略route-policy主要工作在协议层面比如BGP、OSPF、IS-IS发布或接收路由时用route-policy对路由条目本身做过滤、改下一跳、改MED、改Local Preference等。它管的是“路由表里到底有哪些路由”“这些路由的参数是什么”不直接决定具体报文走哪条路。而策略路由管的是“报文转发的那一刻走哪条路”属于转发层面的控制。说一个最直观的区别你用route-policy把某条路由过滤掉相关目的地址的路由就没了设备自然不可达你用策略路由把流量指向一个看似“错误”的下一跳即使路由表里根本没有这个目的地址的精确路由只要下一跳是直连且可达报文依然能发出去。理解了这个区别后面配置时你就不会拿着一堆route-policy命令去试图改变流量走向了。2. 策略路由的基本盘接口、本地、全局三类落地位置2.1 三类下发位置分别管谁策略路由配置到设备上以后必须有一个“生效位置”。生产环境里最常见的生效位置是接口其次是本地local部分平台还支持全局策略。接口策略路由是最常用的作用在某个接口的某个方向上。比如在连接内网的接口上对inbound方向的流量做策略路由那么从该接口进来的流量就会先被策略路由处理。它只管业务报文不管路由器自己发出的协议报文。本地策略路由管的是路由器本机发出的流量比如ping、traceroute、OSPF报文、SNMP告警等。因为这类流量不是从某个物理接口“进来”的而是设备CPU自己产生的接口策略路由根本看不到它们。想让自己发的管理流量也走指定链路就得用本地策略路由。全局策略路由则是把策略应用成一种全局兜底规则对所有接口转发的流量生效。它的覆盖范围大优先级和实现方式在不同厂商、不同产品上有差异所以如果你不需要“全设备统一选路”我建议先别用全局策略避免把管理流量和业务流量一起带到沟里去。实际组网中接口策略和本地策略用得最多先把这两个搞清楚就能解决绝大多数问题。2.2 策略路由的配置骨架以华为VRP平台为例一个最基础的基于源地址的策略路由配置通常包含三块先写ACL框出目标流量再写policy-based-route定义策略节点最后应用到接口上。# 1. ACL定义只匹配来源是192.168.10.0/24的流量 acl number 3001 rule 5 permit ip source 192.168.10.0 0.0.0.255 # 2. 策略路由节点10先匹配ACL再指定下一跳 policy-based-route PBR_CORP permit node 10 if-match acl 3001 apply ip-next-hop 10.0.1.2 # 3. 接口应用从内网进来的流量先走策略路由 interface GigabitEthernet0/0/1 ip address 192.168.10.1 255.255.255.0 ip policy-based-route PBR_CORP这段配置里最核心的是apply ip-next-hop 10.0.1.2。它的意思是所有来自192.168.10.0/24的报文下一跳强行指定为10.0.1.2。注意这里不是把路由表改成下一跳10.0.1.2而是每条匹配的报文在转发时都直接被“引导”到10.0.1.2。2.3 下一跳、出接口和缺省下发的选择策略路由的动作可以有很多但选路相关的核心动作无非三种指定下一跳、指定出接口、指定缺省行为。指定下一跳apply ip-next-hop是最稳妥、最常用的方式。只要下一跳地址是设备直连且可达流量就能走。指定出接口apply output-interface看起来直观但如果出接口是个以太网口并连接了多台设备实际转发效果会依赖ARP或邻居状态反而不稳定。非点对点链路我一般不推荐直接绑出接口。缺省策略路由node默认后面没有匹配条件可以当成兜底比如“所有没被前面节点匹配的流量都改下一跳”。但这里有个容易误解的地方如果策略路由节点配置成permit但没有匹配条件那就等于匹配所有流量这种节点一旦存在默认路由很可能完全“没机会生效”。所以缺省兜底要慎用除非你确实想接管全流量。还有一点在华为平台上策略路由节点标识node后面有permit和deny。permit节点匹配后“执行动作并结束”deny节点匹配后“不执行动作、不继续匹配后续节点直接走普通路由表”这个语义一定不能搞反。3. MQC三板斧流分类、流行为、流策略是怎么组合的3.1 流分类学会“挑人”MQC是Modular QoS Command-Line模块化QoS命令行的缩写最初是从QoS配置里演化出来的。它的核心思想非常朴素先把流量分门别类再对每一类流量施加动作。分类这件事在MQC里就是流分类。流分类最常用的工具是ACL但不仅仅限于ACL。你可以按源IP、目的IP、协议号、TCP/UDP端口、DSCP/IP优先级、802.1p优先级、甚至入接口来分类。比如acl number 3002 rule 5 permit tcp destination-port eq 80 rule 10 permit tcp destination-port eq 443 traffic classifier C_WEB if-match acl 3002这段定义了一个名叫C_WEB的流分类匹配目的端口是80和443的TCP流量。写流分类时尤其要注意分类器内部多个if-match条件之间在华为平台默认是“或”OR关系也就是说只要命中其中一个条件就算命中。如果需要“与”AND关系需要手动指定if-match之间的逻辑不是所有平台都默认一致配置前最好查一下当前设备的匹配逻辑。3.2 流行为决定“怎么对待”分类只是把人挑出来下一步是给这些人安排“待遇”这就是流行为。流行为可以做的动作非常多改下一跳、改出接口、重标记DSCP/802.1p、设置报文优先级、限速、流量镜像、丢弃、统计计数等。正因为能做的动作多MQC不只是QoS专用它也经常被拿来做基于应用的选路和报文标记。还是接着上面的例子我希望把Web流量导到B运营商traffic behavior B_WEB redirect ip-nexthop 10.0.2.2redirect ip-nexthop在MQC里承担了类似策略路由“指定下一跳”的功能。也就是说MQC也能实现策略路由核心动作。很多初学者看到这里会懵既然MQC也能改下一跳那它和策略路由有什么区别区别在于编排方式和适用场景。策略路由就是一张扁平的策略表节点依次匹配MQC则是把分类和行为解耦开分类可以复用行为可以复用策略只是把两者绑到一起的组合件。需要精细到多类流量、多套动作时MQC的工程化优势更明显。3.3 流策略把分类和行为绑到“出入口”有了流分类有了流行为还差最后一步把两者组合成策略并应用到接口上。组合出来的东西就是流策略。traffic policy POLICY_WEB classifier C_WEB behavior B_WEB这条命令里的语义很清晰在策略POLICY_WEB里面凡是命中C_WEB的流量都执行B_WEB行为。一个策略下面可以绑定多个“分类-行为”对不同的流量享受不同的处理。最后要把策略应用到接口interface GigabitEthernet0/0/2 traffic-policy POLICY_WEB inbound应用方向也有讲究。inbound是“这个接口收进来的流量”outbound是“要从这个接口发出去的流量”。做选路类动作时通常是inbound因为流量一旦已经进了设备你需要在转发决策之前就拦截住它。但做限速、队列调度时outbound更常见因为流量要出接口时才能排队。方向选错策略看似配上了实际却什么都不触发这是新手最容易踩的坑。为了看清这套关系我把三者整理成了一张对照表MQC组件配置关键词解决什么问题类比流分类traffic classifier识别出“哪些流量”门禁名单流行为traffic behavior决定“怎么处理”放行、引导、标记、限速流策略traffic policy把分类和行为组合并应用在具体出入口装上的规则集4. 一个把PBR和MQC合体使用的完整案例4.1 需求与拓扑背景我的建议是生产环境里尽量不要在同一个接口的同一个方向上同时挂PBR和MQC去抢“改下一跳”这个职责。因为PBR和MQC两套引擎的执行顺序在不同版本、不同硬件平台上并不完全一致规则一旦重叠排错会非常痛苦。更务实的做法是按VLAN或物理接口把流量边界切开各管一摊。假设这样一个组网一台企业出口路由器R连接了一个内部三层交换机同时接了两家运营商ISP-A的下一跳是10.0.1.2ISP-B的下一跳是10.0.2.2。内部有两个VLANVLAN 10研发网段192.168.10.0/24要求所有出网流量走ISP-A保证低延迟链路优先。VLAN 20办公网段192.168.20.0/24要求HTTP/HTTPS普通上网走ISP-B视频语音流量UDP高端口走ISP-A并打DSCP EF标记。我在路由器上划了两个子接口VLAN 10用PBR实现VLAN 20用MQC实现。这样虽然在一台设备上同时出现了两套技术但作用域互不干扰。4.2 关键配置逐段讲解先看VLAN 10对应的PBR部分acl number 3001 rule 5 permit ip source 192.168.10.0 0.0.0.255 policy-based-route PBR_RND permit node 10 if-match acl 3001 apply ip-next-hop 10.0.1.2 interface GigabitEthernet0/0/1.10 dot1q termination vid 10 ip address 192.168.10.1 255.255.255.0 ip policy-based-route PBR_RND这段配置的逻辑很直接不需要额外解释路由表研发网段过来的报文直接指向ISP-A。这里我特意用了dot1q termination vid 10子接口一是为了和VLAN 20在逻辑上隔离二是将来如果研发网段有其他分类需求可以在子接口单独叠加。如果你现场是物理接口分开的那直接在物理接口上应用也一样。再来看VLAN 20对应的MQC部分acl number 3002 rule 5 permit tcp destination-port eq 80 rule 10 permit tcp destination-port eq 443 acl number 3003 rule 5 permit udp destination-port range 16384 32767 traffic classifier C_WEB if-match acl 3002 traffic classifier C_VOICE if-match acl 3003 traffic behavior B_WEB redirect ip-nexthop 10.0.2.2 traffic behavior B_VOICE redirect ip-nexthop 10.0.1.2 remark dscp ef traffic policy POLICY_OFFICE classifier C_WEB behavior B_WEB classifier C_VOICE behavior B_VOICE interface GigabitEthernet0/0/1.20 dot1q termination vid 20 ip address 192.168.20.1 255.255.255.0 traffic-policy POLICY_OFFICE inbound这套配置里办公网段进来的流量先经过MQC策略普通Web流量被引导到ISP-B语音流量被引导到ISP-A并且被打上DSCP EF标记。两条分类都在同一个策略里但行为完全不同。如果还想加一个限制比如视频流量超过100Mbps就丢弃直接在流行为里加限速动作即可不需要重新设计选路方案这就是MQC三板斧模式化的好处。4.3 验证与结果确认配置完不是立刻收工验证环节很关键。我常用的验证命令分三层display policy-based-route display traffic policy display traffic-policy applied-record第一层先查看设备上配置的策略路由和流策略是否都已创建成功。第二层看策略在接口上的应用状态是不是显示为“active”。第三层看统计计数比如classifier C_WEB原来的命中次数是不是在增长如果一直是0说明ACL写的方向很可能不对。实际用测试机验证时可以先从研发网段PC发起一个到公网的ping或traceroute观察第一跳是不是10.0.1.2再从办公网段PC访问一个网站观察第一跳是否到了10.0.2.2。如果第一跳不符合预期先别急着怀疑策略用display ip routing-table确认直连路由和默认路由本身是正常的再回头检查接口应用方向。4.4 如果换一条链路、换一组IP怎么复用这套配置复用起来很快。换链路时只要把流行为或策略路由里的apply ip-next-hop和redirect ip-nexthop改成新下一跳即可。换网段时改ACL里的source或destination策略名称和接口绑定关系通常不用动。这也是我先用ACL把流量“抽象”出来、而不是直接在流分类里写死IP的原因。真正规范的策略配置应该是ACL负责“识别对象”策略只负责“编排动作”两者解耦后续调整成本会低很多。如果你需要新增一个业务分类比如办公网段里的视频会议走某条专线操作就三步写新ACL、加一个新流分类和流行为、在流策略里绑定一条新规则。老旧策略不用推翻重来。5. 实操踩坑记录这些细节比配置命令更值钱5.1 下一跳可达性的坑策略路由的下一跳不是随便填的。如果apply ip-next-hop 10.0.1.2这个地址本身不是路由器的直连网段部分平台不会做递归查找或者做了递归查找后依赖的路由不稳定流量就会悄悄掉到黑洞里。我的习惯是策略路由里的下一跳必须能够在display ip routing-table里找到一条去往该地址的活动路由而且最好就是直连路由。如果下一跳是通过静态路由或动态路由学到的间接地址一旦上游路由抖动PBR就会失效但你在策略配置里看到的内容还是好好的。这种“配置正确但流量中断”的情况排查起来比配置错误还麻烦。5.2 硬件转发与软件转发的行为差异中高端框式交换机或路由器上策略路由和MQC这类转发策略通常由硬件转发芯片执行。这就带来一个很实际的问题你改了策略配置软件层面已经“成功”了但硬件表项可能还没刷新或者表项老化了。尤其是老一些的设备改了ACL或者策略后即使接口显示应用成功新流量仍然走旧路径。碰到这种情况我会先看设备的会话表或硬件转发表有没有更新必要时在维护窗口里执行清转发缓存或重新应用策略。现在很多新平台已经能做到配置自动下发但“自动”不等于“完全零延迟”改完策略后做一次实时业务验证永远是最稳的。5.3 策略应用方向、默认放通和平台差异流分类里的ACL建议只写需要特殊处理的流量不要写一条“deny ip any any”放在前面。因为很多设备对未匹配的流量默认放通走普通路由转发并不需要额外deny。写了deny之后部分平台可能直接把匹配的报文丢弃而不是“不匹配这个分类继续下一条”这会让你的业务网络断得一干二净。接口方向也是高频出错点。inbound和outbound的语义在PBR和MQC里都一样inbound是指流量进入该接口的方向。做选路改造绝大部分场景应该在“流量进入路由器”的接口上应用策略因为要在路由决策前拦住它。如果策略挂在出接口outbound那路由已经查完了你再去改下一跳部分平台的转发流水线根本不支持。另外不同厂商甚至同一厂商不同产品线的MQC命令会有差异。比如有些平台用redirect ip-nexthop有些版本用redirect ip-next-hop思科平台则是set ip next-hop。如果你在商用设备上配置时命令敲不下去不要硬背先去问设备的问号帮助或查对应版本文档这比在通用示例里猜更靠谱。5.4 一套顺手好用的排错命令最后分享一套我平时排错直接用到的命令流程。先确认策略本身有没有问题再看接口方向最后看统计数据display policy-based-route display traffic classifier display traffic behavior display traffic policy display traffic-policy applied-record display session statistics如果命中次数一直在涨但业务还是不通重点查两个地方一是策略里的下一跳是否可达二是路由表里是否有黑洞路由或更精确但错误的路由。实际工作中我发现策略路由配好后业务不通相当一部分是默认路由或某条精确静态路由把流量引到了别处而不是策略本身没生效。网络排错讲究“从数据面看事实”配置只是预期统计和traceroute才是事实。我自己在项目和排障里反复用过这两套工具之后最大的体会是策略路由胜在简单直接适合“少数几条规则、目标明确”的场景MQC三板斧胜在可编排、可复用适合“流量类型多、动作组合复杂”的场景。真正的高手不是把命令背得多熟而是知道在什么边界条件下用哪套工具、规则叠多了怎么避免互相打架。你可以先从我今天给出的案例开始练在一个子接口上用PBR、另一个子接口上用MQC把验证命令跑熟再逐步把两类策略放到同一个复杂业务场景里去磨合。 策略路由与MQC：企业组网流量调度实战指南
先从一个让我印象特别深的组网现场说起。两条运营商链路同时摆在面前领导问得很简单内网的核心业务走A线普通上网走B线语音流量要在A线上优先转发。听起来就是一个策略路由policy-based-routing加上QoS重标记能搞定的事但真上手做的时候才发现这里牵扯到两套完全不同的路由控制工具一类是策略路由另一类是以流分类、流行为、流策略为核心的MQC三板斧。这两套工具看起来都能“改变流量走向”但原理、配置方式和排查方法完全不一样。这篇文章我就从实际配置的角度把这两套东西掰开揉碎讲清楚给正在学数通或者刚接手企业网维护的朋友一份能直接落地的参考。1. 路由表说了算为什么还要策略路由1.1 一个看起来“路由正确”却完全不可用的例子很多人刚接触网络时脑子里只有一个模型路由器查路由表路由表里有哪条就走哪条。这个模型没错但它只解决了“这个目的地址下一跳是谁”的问题完全没有考虑“这个流量是哪来的”“这个流量是什么应用”“这个流量要不要加密送到指定出口”这类更细的业务诉求。举个例子。公司有一条默认路由指向A运营商A运营商链路带宽高但访问某银行系统的延迟抖动比较严重B运营商链路带宽一般但到银行系统恰好延迟很低。从路由表角度看所有上网流量都匹配默认路由下一跳固定走A没毛病。可业务部门立刻投诉说财务系统打开极慢必须走B线路。这时候你怎么办在路由表里给某个目的地址写一条更精确的静态路由当然是一种办法但如果你根本不知道目标网段会怎么变只知道“来源是财务网段”就要求走B线路静态路由就不好使了因为它只能按目的地址匹配不能按源地址匹配。这时候策略路由的意义就出来了它跳过了“先查路由表”这个顺序而是按照你定义的规则先去看流量特征命中规则就直接指定下一跳、出接口甚至隧道不命中才是按路由表正常转发。可以把它理解成在公司门口加了一个人工引导员不管车辆的总目的地是哪只要是“财务部派出来的车”统一引导到B门走。1.2 策略路由的工作原理抢在路由表之前做决定策略路由在数据面里的处理位置通常位于路由表查询之前或者说是“优先于普通路由查询”的强制路径选择机制。设备收到一个报文后会先用策略路由里配置的匹配条件去比对条件可以基于ACL、报文长度、DSCP优先级、入接口等。如果匹配上就执行动作比如把下一跳改成指定地址、指定出接口、设置报文优先级等。需要注意策略路由不是一个单独的路由协议也不产生路由表项它只是路由器转发流程中的一个“岔路口”。我一般跟学员这么比喻路由表是城市的主干道导航按目的地给你算一条路策略路由是路口的交警指挥哪怕导航说直行交警让你右转你得听交警的。交警指挥完的范围之外才是导航说了算。这也是策略路由最重要的特性它不修改路由表只影响匹配到的报文。所以做策略路由时路由表本身往往还是原来的样子默认路由、静态路由、动态路由该怎么写还是怎么写策略路由只是给特定流量“加塞”了一条特殊路径。1.3 和路由策略(route-policy)的区别别再把名字搞混这是面试里特别爱问的一个点也是实际排错中经常让人晕菜的坑策略路由和控制层面的路由策略是两码事。路由策略route-policy主要工作在协议层面比如BGP、OSPF、IS-IS发布或接收路由时用route-policy对路由条目本身做过滤、改下一跳、改MED、改Local Preference等。它管的是“路由表里到底有哪些路由”“这些路由的参数是什么”不直接决定具体报文走哪条路。而策略路由管的是“报文转发的那一刻走哪条路”属于转发层面的控制。说一个最直观的区别你用route-policy把某条路由过滤掉相关目的地址的路由就没了设备自然不可达你用策略路由把流量指向一个看似“错误”的下一跳即使路由表里根本没有这个目的地址的精确路由只要下一跳是直连且可达报文依然能发出去。理解了这个区别后面配置时你就不会拿着一堆route-policy命令去试图改变流量走向了。2. 策略路由的基本盘接口、本地、全局三类落地位置2.1 三类下发位置分别管谁策略路由配置到设备上以后必须有一个“生效位置”。生产环境里最常见的生效位置是接口其次是本地local部分平台还支持全局策略。接口策略路由是最常用的作用在某个接口的某个方向上。比如在连接内网的接口上对inbound方向的流量做策略路由那么从该接口进来的流量就会先被策略路由处理。它只管业务报文不管路由器自己发出的协议报文。本地策略路由管的是路由器本机发出的流量比如ping、traceroute、OSPF报文、SNMP告警等。因为这类流量不是从某个物理接口“进来”的而是设备CPU自己产生的接口策略路由根本看不到它们。想让自己发的管理流量也走指定链路就得用本地策略路由。全局策略路由则是把策略应用成一种全局兜底规则对所有接口转发的流量生效。它的覆盖范围大优先级和实现方式在不同厂商、不同产品上有差异所以如果你不需要“全设备统一选路”我建议先别用全局策略避免把管理流量和业务流量一起带到沟里去。实际组网中接口策略和本地策略用得最多先把这两个搞清楚就能解决绝大多数问题。2.2 策略路由的配置骨架以华为VRP平台为例一个最基础的基于源地址的策略路由配置通常包含三块先写ACL框出目标流量再写policy-based-route定义策略节点最后应用到接口上。# 1. ACL定义只匹配来源是192.168.10.0/24的流量 acl number 3001 rule 5 permit ip source 192.168.10.0 0.0.0.255 # 2. 策略路由节点10先匹配ACL再指定下一跳 policy-based-route PBR_CORP permit node 10 if-match acl 3001 apply ip-next-hop 10.0.1.2 # 3. 接口应用从内网进来的流量先走策略路由 interface GigabitEthernet0/0/1 ip address 192.168.10.1 255.255.255.0 ip policy-based-route PBR_CORP这段配置里最核心的是apply ip-next-hop 10.0.1.2。它的意思是所有来自192.168.10.0/24的报文下一跳强行指定为10.0.1.2。注意这里不是把路由表改成下一跳10.0.1.2而是每条匹配的报文在转发时都直接被“引导”到10.0.1.2。2.3 下一跳、出接口和缺省下发的选择策略路由的动作可以有很多但选路相关的核心动作无非三种指定下一跳、指定出接口、指定缺省行为。指定下一跳apply ip-next-hop是最稳妥、最常用的方式。只要下一跳地址是设备直连且可达流量就能走。指定出接口apply output-interface看起来直观但如果出接口是个以太网口并连接了多台设备实际转发效果会依赖ARP或邻居状态反而不稳定。非点对点链路我一般不推荐直接绑出接口。缺省策略路由node默认后面没有匹配条件可以当成兜底比如“所有没被前面节点匹配的流量都改下一跳”。但这里有个容易误解的地方如果策略路由节点配置成permit但没有匹配条件那就等于匹配所有流量这种节点一旦存在默认路由很可能完全“没机会生效”。所以缺省兜底要慎用除非你确实想接管全流量。还有一点在华为平台上策略路由节点标识node后面有permit和deny。permit节点匹配后“执行动作并结束”deny节点匹配后“不执行动作、不继续匹配后续节点直接走普通路由表”这个语义一定不能搞反。3. MQC三板斧流分类、流行为、流策略是怎么组合的3.1 流分类学会“挑人”MQC是Modular QoS Command-Line模块化QoS命令行的缩写最初是从QoS配置里演化出来的。它的核心思想非常朴素先把流量分门别类再对每一类流量施加动作。分类这件事在MQC里就是流分类。流分类最常用的工具是ACL但不仅仅限于ACL。你可以按源IP、目的IP、协议号、TCP/UDP端口、DSCP/IP优先级、802.1p优先级、甚至入接口来分类。比如acl number 3002 rule 5 permit tcp destination-port eq 80 rule 10 permit tcp destination-port eq 443 traffic classifier C_WEB if-match acl 3002这段定义了一个名叫C_WEB的流分类匹配目的端口是80和443的TCP流量。写流分类时尤其要注意分类器内部多个if-match条件之间在华为平台默认是“或”OR关系也就是说只要命中其中一个条件就算命中。如果需要“与”AND关系需要手动指定if-match之间的逻辑不是所有平台都默认一致配置前最好查一下当前设备的匹配逻辑。3.2 流行为决定“怎么对待”分类只是把人挑出来下一步是给这些人安排“待遇”这就是流行为。流行为可以做的动作非常多改下一跳、改出接口、重标记DSCP/802.1p、设置报文优先级、限速、流量镜像、丢弃、统计计数等。正因为能做的动作多MQC不只是QoS专用它也经常被拿来做基于应用的选路和报文标记。还是接着上面的例子我希望把Web流量导到B运营商traffic behavior B_WEB redirect ip-nexthop 10.0.2.2redirect ip-nexthop在MQC里承担了类似策略路由“指定下一跳”的功能。也就是说MQC也能实现策略路由核心动作。很多初学者看到这里会懵既然MQC也能改下一跳那它和策略路由有什么区别区别在于编排方式和适用场景。策略路由就是一张扁平的策略表节点依次匹配MQC则是把分类和行为解耦开分类可以复用行为可以复用策略只是把两者绑到一起的组合件。需要精细到多类流量、多套动作时MQC的工程化优势更明显。3.3 流策略把分类和行为绑到“出入口”有了流分类有了流行为还差最后一步把两者组合成策略并应用到接口上。组合出来的东西就是流策略。traffic policy POLICY_WEB classifier C_WEB behavior B_WEB这条命令里的语义很清晰在策略POLICY_WEB里面凡是命中C_WEB的流量都执行B_WEB行为。一个策略下面可以绑定多个“分类-行为”对不同的流量享受不同的处理。最后要把策略应用到接口interface GigabitEthernet0/0/2 traffic-policy POLICY_WEB inbound应用方向也有讲究。inbound是“这个接口收进来的流量”outbound是“要从这个接口发出去的流量”。做选路类动作时通常是inbound因为流量一旦已经进了设备你需要在转发决策之前就拦截住它。但做限速、队列调度时outbound更常见因为流量要出接口时才能排队。方向选错策略看似配上了实际却什么都不触发这是新手最容易踩的坑。为了看清这套关系我把三者整理成了一张对照表MQC组件配置关键词解决什么问题类比流分类traffic classifier识别出“哪些流量”门禁名单流行为traffic behavior决定“怎么处理”放行、引导、标记、限速流策略traffic policy把分类和行为组合并应用在具体出入口装上的规则集4. 一个把PBR和MQC合体使用的完整案例4.1 需求与拓扑背景我的建议是生产环境里尽量不要在同一个接口的同一个方向上同时挂PBR和MQC去抢“改下一跳”这个职责。因为PBR和MQC两套引擎的执行顺序在不同版本、不同硬件平台上并不完全一致规则一旦重叠排错会非常痛苦。更务实的做法是按VLAN或物理接口把流量边界切开各管一摊。假设这样一个组网一台企业出口路由器R连接了一个内部三层交换机同时接了两家运营商ISP-A的下一跳是10.0.1.2ISP-B的下一跳是10.0.2.2。内部有两个VLANVLAN 10研发网段192.168.10.0/24要求所有出网流量走ISP-A保证低延迟链路优先。VLAN 20办公网段192.168.20.0/24要求HTTP/HTTPS普通上网走ISP-B视频语音流量UDP高端口走ISP-A并打DSCP EF标记。我在路由器上划了两个子接口VLAN 10用PBR实现VLAN 20用MQC实现。这样虽然在一台设备上同时出现了两套技术但作用域互不干扰。4.2 关键配置逐段讲解先看VLAN 10对应的PBR部分acl number 3001 rule 5 permit ip source 192.168.10.0 0.0.0.255 policy-based-route PBR_RND permit node 10 if-match acl 3001 apply ip-next-hop 10.0.1.2 interface GigabitEthernet0/0/1.10 dot1q termination vid 10 ip address 192.168.10.1 255.255.255.0 ip policy-based-route PBR_RND这段配置的逻辑很直接不需要额外解释路由表研发网段过来的报文直接指向ISP-A。这里我特意用了dot1q termination vid 10子接口一是为了和VLAN 20在逻辑上隔离二是将来如果研发网段有其他分类需求可以在子接口单独叠加。如果你现场是物理接口分开的那直接在物理接口上应用也一样。再来看VLAN 20对应的MQC部分acl number 3002 rule 5 permit tcp destination-port eq 80 rule 10 permit tcp destination-port eq 443 acl number 3003 rule 5 permit udp destination-port range 16384 32767 traffic classifier C_WEB if-match acl 3002 traffic classifier C_VOICE if-match acl 3003 traffic behavior B_WEB redirect ip-nexthop 10.0.2.2 traffic behavior B_VOICE redirect ip-nexthop 10.0.1.2 remark dscp ef traffic policy POLICY_OFFICE classifier C_WEB behavior B_WEB classifier C_VOICE behavior B_VOICE interface GigabitEthernet0/0/1.20 dot1q termination vid 20 ip address 192.168.20.1 255.255.255.0 traffic-policy POLICY_OFFICE inbound这套配置里办公网段进来的流量先经过MQC策略普通Web流量被引导到ISP-B语音流量被引导到ISP-A并且被打上DSCP EF标记。两条分类都在同一个策略里但行为完全不同。如果还想加一个限制比如视频流量超过100Mbps就丢弃直接在流行为里加限速动作即可不需要重新设计选路方案这就是MQC三板斧模式化的好处。4.3 验证与结果确认配置完不是立刻收工验证环节很关键。我常用的验证命令分三层display policy-based-route display traffic policy display traffic-policy applied-record第一层先查看设备上配置的策略路由和流策略是否都已创建成功。第二层看策略在接口上的应用状态是不是显示为“active”。第三层看统计计数比如classifier C_WEB原来的命中次数是不是在增长如果一直是0说明ACL写的方向很可能不对。实际用测试机验证时可以先从研发网段PC发起一个到公网的ping或traceroute观察第一跳是不是10.0.1.2再从办公网段PC访问一个网站观察第一跳是否到了10.0.2.2。如果第一跳不符合预期先别急着怀疑策略用display ip routing-table确认直连路由和默认路由本身是正常的再回头检查接口应用方向。4.4 如果换一条链路、换一组IP怎么复用这套配置复用起来很快。换链路时只要把流行为或策略路由里的apply ip-next-hop和redirect ip-nexthop改成新下一跳即可。换网段时改ACL里的source或destination策略名称和接口绑定关系通常不用动。这也是我先用ACL把流量“抽象”出来、而不是直接在流分类里写死IP的原因。真正规范的策略配置应该是ACL负责“识别对象”策略只负责“编排动作”两者解耦后续调整成本会低很多。如果你需要新增一个业务分类比如办公网段里的视频会议走某条专线操作就三步写新ACL、加一个新流分类和流行为、在流策略里绑定一条新规则。老旧策略不用推翻重来。5. 实操踩坑记录这些细节比配置命令更值钱5.1 下一跳可达性的坑策略路由的下一跳不是随便填的。如果apply ip-next-hop 10.0.1.2这个地址本身不是路由器的直连网段部分平台不会做递归查找或者做了递归查找后依赖的路由不稳定流量就会悄悄掉到黑洞里。我的习惯是策略路由里的下一跳必须能够在display ip routing-table里找到一条去往该地址的活动路由而且最好就是直连路由。如果下一跳是通过静态路由或动态路由学到的间接地址一旦上游路由抖动PBR就会失效但你在策略配置里看到的内容还是好好的。这种“配置正确但流量中断”的情况排查起来比配置错误还麻烦。5.2 硬件转发与软件转发的行为差异中高端框式交换机或路由器上策略路由和MQC这类转发策略通常由硬件转发芯片执行。这就带来一个很实际的问题你改了策略配置软件层面已经“成功”了但硬件表项可能还没刷新或者表项老化了。尤其是老一些的设备改了ACL或者策略后即使接口显示应用成功新流量仍然走旧路径。碰到这种情况我会先看设备的会话表或硬件转发表有没有更新必要时在维护窗口里执行清转发缓存或重新应用策略。现在很多新平台已经能做到配置自动下发但“自动”不等于“完全零延迟”改完策略后做一次实时业务验证永远是最稳的。5.3 策略应用方向、默认放通和平台差异流分类里的ACL建议只写需要特殊处理的流量不要写一条“deny ip any any”放在前面。因为很多设备对未匹配的流量默认放通走普通路由转发并不需要额外deny。写了deny之后部分平台可能直接把匹配的报文丢弃而不是“不匹配这个分类继续下一条”这会让你的业务网络断得一干二净。接口方向也是高频出错点。inbound和outbound的语义在PBR和MQC里都一样inbound是指流量进入该接口的方向。做选路改造绝大部分场景应该在“流量进入路由器”的接口上应用策略因为要在路由决策前拦住它。如果策略挂在出接口outbound那路由已经查完了你再去改下一跳部分平台的转发流水线根本不支持。另外不同厂商甚至同一厂商不同产品线的MQC命令会有差异。比如有些平台用redirect ip-nexthop有些版本用redirect ip-next-hop思科平台则是set ip next-hop。如果你在商用设备上配置时命令敲不下去不要硬背先去问设备的问号帮助或查对应版本文档这比在通用示例里猜更靠谱。5.4 一套顺手好用的排错命令最后分享一套我平时排错直接用到的命令流程。先确认策略本身有没有问题再看接口方向最后看统计数据display policy-based-route display traffic classifier display traffic behavior display traffic policy display traffic-policy applied-record display session statistics如果命中次数一直在涨但业务还是不通重点查两个地方一是策略里的下一跳是否可达二是路由表里是否有黑洞路由或更精确但错误的路由。实际工作中我发现策略路由配好后业务不通相当一部分是默认路由或某条精确静态路由把流量引到了别处而不是策略本身没生效。网络排错讲究“从数据面看事实”配置只是预期统计和traceroute才是事实。我自己在项目和排障里反复用过这两套工具之后最大的体会是策略路由胜在简单直接适合“少数几条规则、目标明确”的场景MQC三板斧胜在可编排、可复用适合“流量类型多、动作组合复杂”的场景。真正的高手不是把命令背得多熟而是知道在什么边界条件下用哪套工具、规则叠多了怎么避免互相打架。你可以先从我今天给出的案例开始练在一个子接口上用PBR、另一个子接口上用MQC把验证命令跑熟再逐步把两类策略放到同一个复杂业务场景里去磨合。