3. 流量分类与标记

QoS能否生效，第一步不在队列，而在“识别”。如果接入层没有把语音、视频、ERP、备份、访客上网这些流量区分开，后续所有队列、限速、拥塞管理都会作用在错误的流量上。Catalyst接入交换机的分类与标记，本质上是在数据包进入网络的第一跳，把“这是什么业务”翻译成“网络内部统一的优先级标签”。

一、先理解三种标记字段与它们的位置

在Catalyst接入层，最常打交道的标记字段有三个：二层CoS、三层IP Precedence、三层DSCP。它们不是互相替代，而是位于不同封装层次、服务不同转发环节。

• CoS（Class of Service）：位于802.1Q标签内的3 bit字段，取值0～7，共8个等级。它只在Trunk链路上存在，交换机内部转发、以及交换机到交换机的二层链路主要看CoS。
• IP Precedence（IP优先级）：位于IPv4 ToS字节的高3 bit，取值0～7，是DSCP的前身。老设备或旧配置中仍可能看到，新部署应统一用DSCP。
• DSCP（Differentiated Services Code Point）：位于IPv4 ToS字节的高6 bit，取值0～63，是当前企业QoS的事实标准。它比IP Precedence多3 bit，能表达更细的等级，同时兼容IP Precedence（DSCP高3位等于IP Precedence）。

关键关系是：一个带802.1Q标签的IP包，可以同时拥有CoS和DSCP。二层设备看CoS，三层设备看DSCP。接入层要做的是让两者在边界处保持一致，避免“二层高、三层低”或反之造成优先级断裂。

二、识别手段：ACL、NBAR与端口信任

识别流量有三类常用手段，选择取决于“能否看到特征”和“是否值得信任终端”。

ACL分类是最基础的方式，基于源/目的IP、协议、端口号匹配。例如把到语音网关UDP 5060/2000的流量识别为语音信令，把TCP 443到ERP服务器的流量识别为关键业务。ACL的优点是确定、可预测、开销低；缺点是端口变化、加密流量、动态端口就无能为力。

NBAR（Network-Based Application Recognition）能深入识别应用层特征，包括HTTP URL、Host头、甚至部分加密流量的元数据。它适合识别“端口不固定”的应用，例如Web会议、SaaS办公、视频流。NBAR比ACL更智能，但需要设备支持、消耗一定CPU，且对全新加密协议仍可能识别失败。

端口信任是接入层最省事的做法：如果IP电话已经按规范打好了DSCP，交换机就信任它，不再重标记。但PC、访客终端不可信任，必须由交换机强制重标记，否则任何人都能把自己的流量标成EF。

三、在Catalyst接入层完成标记的典型逻辑

接入层分类标记的推荐顺序是：先信任已知可信设备，再对不可信流量按ACL/NBAR匹配，最后给未匹配流量一个默认低优先级。下面是一段Catalyst 9000系列上的示例配置，用于说明结构，参数为教学示例，实际部署需按现场地址和业务调整。

! 定义分类ACL
ip access-list extended VOICE-SIG
 permit udp any any range 5060 5061
ip access-list extended VOICE-RTP
 permit udp any any range 16384 32767
ip access-list extended BIZ-ERP
 permit tcp any host 10.20.30.40 eq 443

! 定义类映射
class-map match-any CM-VOICE
 match access-group name VOICE-SIG
 match access-group name VOICE-RTP
class-map match-any CM-ERP
 match access-group name BIZ-ERP
class-map match-any CM-BULK
 match protocol ftp
 match protocol smb

! 定义策略映射并打标
policy-map PM-ACCESS-MARK
 class CM-VOICE
  set dscp ef
 class CM-ERP
  set dscp af31
 class CM-BULK
  set dscp af11
 class class-default
  set dscp default

! 应用到接入端口
interface GigabitEthernet1/0/10
 switchport mode access
 service-policy input PM-ACCESS-MARK

这段配置的核心不是命令本身，而是“匹配—打标—默认兜底”的闭环。语音信令和RTP被标为EF，ERP被标为AF31，批量传输被压到AF11，其余流量落到Default。这样后续在汇聚、核心、WAN出口，所有设备都能基于同一套DSCP做队列和限速。

四、企业DSCP命名规范设计

DSCP有64个值，但企业不需要用满。真正重要的是“命名规范”让所有人对同一个数字有同一个含义。推荐按业务类别划分，而不是按部门划分，因为部门会变，业务类别相对稳定。

业务类别	DSCP名称	DSCP值	CoS	典型流量
语音承载	EF	46	5	VoIP RTP
语音信令	CS3	24	3	SIP、H.323
交互视频	AF41	34	4	视频会议
关键业务	AF31	26	3	ERP、数据库
事务型业务	AF21	18	2	OA、邮件
批量传输	AF11	10	1	备份、文件同步
尽力而为	Default	0	0	互联网浏览
背景/低优	CS1	8	1	软件更新、日志

命名规范一旦确定，就要写成文档并贯穿全网：接入层打标、汇聚层信任、核心层排队、WAN出口整形，全部引用同一张表。任何新增业务，先问“它属于哪一类”，再决定DSCP，而不是临时拍一个数字。

五、标记边界与一致性检查

接入层标记最容易出问题的地方是“边界不一致”。例如IP电话在语音VLAN里打了EF，但上行Trunk没有信任CoS，交换机把CoS重置为0，到了汇聚层EF就丢了。因此需要在Trunk口显式配置信任：

interface GigabitEthernet1/0/1
 switchport mode trunk
 mls qos trust cos

另一个常见问题是“终端乱标”。如果接入端口配置了mls qos trust dscp，而连接的是普通PC，用户可以把所有流量标成EF，直接破坏QoS。正确做法是：电话端口信任DSCP，PC端口不信任并强制重标记，访客端口统一压到Default或CS1。

验证时，可以在接入交换机上查看分类计数，确认匹配命中；在汇聚或核心抓包，确认DSCP在跨设备后仍然保持；在WAN出口查看队列统计，确认高优先级队列有出队、低优先级队列被整形。只有这三层都一致，分类标记才算真正落地。

把这张图记在脑子里：左边是“谁在说话”，中间是“怎么识别和打标”，右边是“打成什么标准”，底部是“标签必须一路传下去”。接入层做对了，后面的QoS才有意义；接入层做错了，后面越努力越浪费。