新华三出链路负载均衡问题

华三出链路负载均衡：5 种链路选择方式优先级解析
官方文档给出顺序：持续性 > ACL 策略 > ISP 选路 > 就近性 > 调度算法
你的疑问：ACL、ISP 明明是在【流量特征】里面做匹配，由 match‑id 控制匹配顺序，为什么又多出一套全局内置优先级？
核心区分两个完全不同概念：
match‑id：流量特征内部的报文匹配顺序 → 用来识别这是什么流量（分类）
5 种链路选择方式的内置优先级：选路决策逻辑的执行顺序 → 流量识别完成之后，用哪一套规则去选出口链路。
match‑id 只管 “识别流量”；识别完流量之后，再按这套内置优先级，选用对应的选路逻辑。二者不冲突，属于前后两个处理阶段。
名词解释 5 种选择方式
持续性（会话保持）
最高优先级。同一个五元组会话，后续报文强制沿用第一次选出来的链路，跳过后面所有选路逻辑。只要命中持续性表项，直接走老链路，不再跑 ACL/ISP/ 就近性 / 调度算法。
作用：保证同一个会话不会跨链路来回跳，防止 NAT 会话异常。
ACL 策略（自定义流量特征策略）
就是你配置的流量特征 + IPv4 选路策略。通过 ACL / 源目 IP / 应用等 match‑id 匹配流量，人为指定这条流量必须走某一条 / 某一组链路。
例如：内网 192.168.1.0/24 全部走联通链路。
✅match‑id 在这里起作用：在 ACL 策略内部，按 match‑id 从小到大匹配，命中即停止；一旦某条流量命中一条自定义策略，直接按该策略指定链路转发，不再往下执行 ISP 选路、就近性、调度算法。
ISP 选路（运营商地址库选路）
流量没有命中上面持续性、ACL 自定义策略，才走到 ISP 选路。
拿报文目的 IP 和内置 ISP 地址库比对：访问电信网段就走电信链路，访问联通网段就走联通链路。
ISP 选路是系统内置目的地址库匹配，不是你手工配置的流量特征 match‑id。命中 ISP，则直接选对应运营商链路，不再往下走就近性、调度算法。
就近性（动态就近性）
流量未命中持续性、ACL 策略、ISP 选路，才执行就近性。
设备 NQA 探测各个链路访问目标 IP 的时延 RTT，选延迟最小的链路；生成就近性表项。
调度算法（加权轮转、带宽、最小连接等）
最低优先级兜底。前面全部规则都没有命中，才使用链路组的调度算法做负载分担。普通默认流量就走到这里。
通俗完整流程（报文处理流水线）
plaintext
新连接报文进入设备
↓
1、查询持续性会话表：有表项？→直接复用旧链路，选路结束（最高）
↓（无持续性表项）
2、执行【ACL策略】：按match‑id顺序匹配流量特征，命中自定义策略？→按策略指定链路转发，结束
↓（没有命中任何自定义ACL策略）
3、执行ISP选路：目的IP匹配ISP地址库？→选择对应运营商链路，结束
↓（不在ISP地址库）
4、执行就近性：探测RTT，选时延最优链路？→选路结束
↓（就近性无可用表项/探测失败）
5、调度算法兜底：按链路组算法（带宽/轮转）选链路，结束
关键点回答你的困惑
“ACL 策略和 ISP 选路，不都可以在流量特征里面做流量匹配吗？”
ACL 策略：是用户自定义策略，你写流量特征、match‑id、ACL，人为指定流量走哪个链路；这部分逻辑属于第二阶。match‑id只在这一层内部用来区分不同自定义策略的先后顺序。
ISP 选路：是设备内置独立模块。你也可以在流量特征里面写一条 match 规则类型 = ISP，但那只是把 ISP 作为流量分类条件；真正的全局 ISP 选路，不需要你配置任何流量特征，直接拿目的 IP 和内置地址库比对，属于独立第三阶逻辑。
举个例子：
你写了 match‑id 10，匹配 ISP = 电信，动作走联通链路。
这属于ACL 策略（第二阶），因为 match‑id=10 优先级高，报文进来，在第二步就被你的自定义策略命中，强制走联通；不会再走到第三步系统内置 ISP 选路。
这正好体现：ACL 策略优先级高于 ISP 选路。用户自定义策略优先级高于系统内置 ISP 规则。
容易踩坑的场景
如果你配置了自定义 ACL 策略，哪怕匹配条件是 ISP 网段，会优先执行你的策略，系统 ISP 选路被跳过。
持续性表项一旦生成，所有策略全部不生效，老会话沿用旧链路；新建连接才重新跑整套选路逻辑。
ISP 选路只看目的 IP，不需要配置流量特征，是独立模块；就近性需要开启链路组下dynamic‑topology。
简短小结