📚 课程目录第4章 Catalyst信任边界与策略映射

4. Catalyst信任边界与策略映射

在 Catalyst 交换机的 QoS 部署中，信任边界决定了“谁说的话可以被相信”。如果接入端口对终端送来的 DSCP 或 CoS 无条件信任，一台普通 PC 只要把语音包标记成 EF，就能在拥塞时抢占语音队列；反过来，如果对所有流量一律不信任，又会把 IP 电话、摄像头等已经正确标记的流量降级处理。因此，接入层必须明确区分“可信设备”和“非可信设备”，并在边界处完成一次统一的策略映射。

信任边界的三种基本处理方式

Catalyst 接入端口对入向标记的处理可以归纳为三类：

信任（trust）：直接沿用报文自带的 CoS 或 DSCP，不做修改。适用于 IP 电话、无线 AP、已受控的服务器端口。
不信任（untrust / default）：忽略入向标记，按端口默认值重新标记。适用于普通 PC、打印机、访客端口。
条件信任（conditional trust）：只对特定设备或特定流量信任，其余重标记。典型场景是 IP 电话 + PC 串联到同一端口，电话标记可信，电话下挂 PC 的流量不可信。

配置入口是接口下的 mls qos trust 命令族。常见形式包括：

interface GigabitEthernet1/0/10
 description IP-Phone-Port
 mls qos trust cos
 mls qos cos 0
!
interface GigabitEthernet1/0/20
 description User-PC-Port
 no mls qos trust
 mls qos cos 0
 mls qos dscp 0

其中 mls qos trust cos 表示信任二层 CoS，mls qos trust dscp 表示信任三层 DSCP，mls qos trust device cisco-phone 则启用条件信任：只有通过 CDP/LLDP 识别为 Cisco IP 电话时才信任其标记，电话下挂 PC 的流量按非信任处理。需要注意，mls qos trust cos 与 mls qos trust dscp 在同一端口上通常互斥，选择哪一个取决于该端口所在链路是二层 Trunk 还是三层路由端口，以及上游设备依据 CoS 还是 DSCP 做调度。

非信任流量的重标记：policy-map 与 table-map

当端口不信任入向标记时，需要把流量重新映射到本域认可的标记。Catalyst 提供两种互补手段：policy-map 用于按分类条件重标记，table-map 用于把一种标记体系整体转换为另一种标记体系。

policy-map 的典型用法是在接入端口对非信任流量做分类并设置新 DSCP：

class-map match-any CM-VOICE
 match dscp ef
class-map match-any CM-BULK
 match dscp af11
!
policy-map PM-ACCESS-REMARK
 class CM-VOICE
  set dscp ef
 class CM-BULK
  set dscp af11
 class class-default
  set dscp default
!
interface GigabitEthernet1/0/20
 service-policy input PM-ACCESS-REMARK

这里的关键点是：service-policy input 在入向生效，先于队列调度，因此重标记结果会直接影响后续出向队列的选择。若端口同时配置了 mls qos trust dscp，则 policy-map 中的 set dscp 可能被信任逻辑覆盖，实际部署中应避免在同一端口上既信任又重标记同一字段。

table-map 解决的是“体系转换”问题。例如接入交换机信任 CoS，但核心网只认 DSCP，就需要把 CoS 映射为 DSCP：

mls qos map cos-dscp 0 8 16 24 32 40 48 56
!
interface GigabitEthernet1/0/10
 mls qos trust cos

这条 mls qos map cos-dscp 就是一张 table-map，把 CoS 0～7 依次映射为 DSCP 0、8、16、24、32、40、48、56。类似地还有 mls qos map dscp-cos、mls qos map dscp-mutation 等。table-map 是全局的，作用于所有启用对应信任的端口，因此修改前必须评估对全网的影响。

在 Catalyst 上，mls qos map dscp-mutation 常用于把上游域的非标准 DSCP 值“归一化”到本域标准值，例如把 DSCP 46 之外的语音标记统一改为 EF，避免非标准标记在核心被丢弃或降级。

接入端口信任边界的完整配置示例

下面给出一个接入交换机上同时处理 IP 电话端口和普通 PC 端口的配置片段，展示信任边界如何落地：

! 全局启用 QoS
mls qos

! 定义 CoS 到 DSCP 的映射表
mls qos map cos-dscp 0 8 16 24 32 40 48 56

! 定义非信任流量的重标记策略
class-map match-any CM-USER-DATA
 match dscp af11
class-map match-any CM-USER-VOICE
 match dscp ef
!
policy-map PM-USER-REMARK
 class CM-USER-VOICE
  set dscp ef
 class CM-USER-DATA
  set dscp af11
 class class-default
  set dscp default
!
! IP 电话端口：条件信任
interface GigabitEthernet1/0/10
 mls qos trust device cisco-phone
 mls qos trust cos
!
! 普通 PC 端口：不信任并重标记
interface GigabitEthernet1/0/20
 no mls qos trust
 service-policy input PM-USER-REMARK

验证时可用 show mls qos interface GigabitEthernet1/0/20 查看端口的信任状态和默认 CoS/DSCP，用 show policy-map interface GigabitEthernet1/0/20 input 查看各分类的匹配计数。若发现语音流量被错误重标记为 default，应检查电话是否发送了正确的 DSCP，以及端口是否误配了 no mls qos trust。

部署时的常见判断与排错

信任边界配置完成后，最值得观察的是“入向标记是否被正确保留或改写”。在 IP 电话端口上，如果 show mls qos interface Gi1/0/10 显示 trust state 为 trust cos，但电话语音仍进入 default 队列，通常是因为电话未发送 CoS 5，或中间链路把 CoS 清零。此时应检查电话的 QoS 配置和链路 Trunk 的 mls qos trust cos 是否一致。

在普通 PC 端口上，如果 show policy-map interface Gi1/0/20 input 显示 class-default 匹配计数很高，而 CM-USER-VOICE 计数为 0，说明 PC 流量确实没有携带 EF 标记，重标记策略按预期把其归入 default，这是正常结果。若希望 PC 上的语音软件也能获得优先，应在 PC 侧或接入端口显式标记，而不是依赖信任。

table-map 是全局生效的，修改 mls qos map cos-dscp 会影响所有信任 CoS 的端口。生产环境中建议先在实验室验证映射表，再通过配置回滚窗口实施，避免语音和视频流量在核心被错误降级。

最后需要强调，信任边界不是“越信任越好”，也不是“全部重标记最安全”。合理的做法是：对受控的语音、视频、无线 AP 端口按设备类型给予条件信任，对用户和访客端口一律不信任并统一重标记，再用 table-map 保证跨域标记体系一致。这样既保护了关键业务，又避免了终端伪造标记带来的队列抢占。