4、PBR高级配置：基于应用层的策略路由、基于时间段的策略路由、基于报文长度的策略路由
各位，咱们接着聊PBR。基础的路由策略大家应该都玩过了，无非就是根据源IP、目的IP、入接口这些条件来引导流量。但说实话，真正的网络环境哪有这么简单？
我当年在给一家大型企业做网络改造时，就碰到过一个头疼的问题。他们财务部的ERP系统，平时跑得好好的，一到月底结账就卡得要死。查了半天，发现是员工下班后看视频、下载大文件，把出口带宽给挤爆了。你总不能把视频网站全封了吧？人家中午休息也要放松一下。这时候，普通的PBR就抓瞎了。
所以，咱们今天要聊的，就是PBR的三种高级玩法：基于应用层、基于时间段、基于报文长度。说白了，就是让路由器变得更“聪明”，能看懂你的流量是什么、什么时候来的、有多大。
4.1 基于应用层的策略路由
传统的PBR只能看三层和四层的信息，比如IP地址、端口号。但现在的流量，很多都加密了，或者用了动态端口。你光看端口号，根本分不清它是微信视频还是普通的网页浏览。
基于应用层的策略路由，也叫NBAR（Network-Based Application Recognition，网络应用识别）。它能深入分析报文的应用层特征，比如HTTP的Host字段、SSL证书的SNI信息，甚至能识别出具体的应用，比如抖音、腾讯会议、迅雷。
我个人的习惯是，把NBAR和PBR结合起来用。举个例子，我们可以让“腾讯会议”的流量走专线，保证视频会议不卡；让“迅雷下载”的流量走普通宽带，别占用核心资源。
配置上，大致分三步走：
- 定义类（class-map）：匹配特定的应用流量。
- 定义策略（policy-map）：对匹配的流量执行PBR动作。
- 应用策略（service-policy）：在接口上应用。
看个配置片段，你就明白了：
! 第一步：定义类，匹配腾讯会议流量
class-map match-any CMAP-TENCENT-MEETING
match protocol attribute app-name "tencent-meeting"
! 第二步：定义策略，将匹配的流量下一跳指向专线
policy-map PMAP-PBR-APP
class CMAP-TENCENT-MEETING
set ip next-hop 10.1.1.2
class class-default
set ip next-hop 10.2.2.2
! 第三步：在入接口应用
interface GigabitEthernet0/0/0
service-policy input PMAP-PBR-APP
4.2 基于时间段的策略路由
这个就更好理解了。你想想看，公司的网络策略，白天和晚上能一样吗？
白天上班时间，我们要保证OA、ERP、邮件这些办公系统的带宽。晚上下班后，大家想看看视频、打打游戏，只要不违法，其实可以适当放宽限制。
基于时间段的策略路由，就是让PBR策略能根据当前的时间自动切换。它依赖于一个叫“时间范围（time-range）”的东西。
配置思路也很清晰：
- 定义时间范围：比如工作日9:00到18:00。
- 在ACL或class-map中引用：让匹配条件带上时间属性。
- PBR策略中引用这个class-map：实现不同时间走不同路径。
举个例子，我想让上班时间所有流量都走主链路，下班后让P2P下载流量走备份链路：
! 定义上班时间
time-range WORKING-HOURS
periodic weekdays 09:00 to 18:00
! 定义ACL，匹配P2P流量，并且只在上班时间生效
ip access-list extended ACL-P2P-WORK
deny ip any any time-range WORKING-HOURS
permit tcp any any range 6881 6889
permit udp any any range 6881 6889
! 定义类，引用ACL
class-map match-any CMAP-P2P
match access-group name ACL-P2P-WORK
! 定义策略
policy-map PMAP-TIME-PBR
class CMAP-P2P
set ip next-hop 192.168.100.1
class class-default
set ip next-hop 192.168.200.1
! 应用
interface GigabitEthernet0/0/1
service-policy input PMAP-TIME-PBR
periodic是周期性生效，absolute是绝对时间（比如从2025-01-01到2025-12-31）。日常运维，99%的情况用periodic就够了。
4.3 基于报文长度的策略路由
这个功能，说实话，用的人不多，但在某些特定场景下，它简直是神器。
它的逻辑很简单：根据IP报文的总长度（包括IP头和数据部分）来决定走哪条路。
为什么要这么做？我举个例子。VoIP语音报文，通常都很小，几十个字节。而文件下载的报文，通常都是1500字节的大包。我们可以让这些小包走低延迟的专线，大包走高带宽的普通线路。
配置上，它不需要定义复杂的ACL或class-map，直接在route-map里用match length命令就行。
! 定义route-map，匹配报文长度在64到512字节之间的流量
route-map PBR-LENGTH permit 10
match length 64 512
set ip next-hop 10.1.1.2
! 匹配其他流量（大于512字节）
route-map PBR-LENGTH permit 20
set ip next-hop 10.2.2.2
! 在接口应用PBR
interface GigabitEthernet0/0/2
ip policy route-map PBR-LENGTH
核心要点：
match length后面的两个数字，分别是最小值和最大值，单位是字节。- 这个匹配是基于IP报文的总长度，不是TCP/UDP的载荷长度。
- 如果报文经过了分片，那么每个分片都会独立匹配。这一点要特别注意。
嗯，这里要注意一点。基于报文长度的策略路由，它不能区分应用类型。比如，一个64字节的TCP ACK包和一个64字节的VoIP包，它都认为是小包，会一视同仁。所以，它通常需要和其他匹配条件（比如源IP）配合使用，才能达到最佳效果。
4.4 三种高级PBR的对比与选择
说了这么多，这三种技术到底该怎么选？我给大家画个图，一看就明白。
我个人建议，在实际项目中，这三种技术往往不是孤立使用的。比如，你可以先基于时间段，在上班时间启用基于应用层的策略路由，下班后则启用基于报文长度的策略路由。这样组合起来，效果会非常棒。
好了，关于PBR的高级配置，今天就聊到这里。这三种技术，说白了就是让你手里的路由器从“傻大个”变成“智能调度员”。你想想看，一个能看懂应用、知道时间、还能掂量报文大小的网络，是不是比死板的静态路由强太多了？