3. 资产信息建模与标准化

在 Catalyst 网络资产与自动化配置平台中，资产信息建模是连接“设备发现”与“自动化配置”的关键中间层。设备被扫描或纳管后，平台拿到的往往是一堆原始字段：主机名、管理 IP、MAC、序列号、型号、IOS 版本、所在交换机端口等。这些字段来源不同、格式不一，如果不做统一建模与标准化，后续的合规检查、配置模板下发、拓扑还原都会因为“同一台设备在不同模块里叫法不同”而失败。本节围绕资产属性定义、设备角色分类、位置信息、序列号与软件版本等字段，讲清采集与规范化的具体做法。

一、资产属性模型：先定义字段，再谈采集

资产建模的第一步不是写采集脚本，而是定义一张“资产属性字典”。字典要明确每个字段的名称、数据类型、是否必填、取值来源和规范化规则。以 Catalyst 环境为例，建议至少覆盖以下字段：

• 标识类：asset_id（平台内部唯一 ID）、hostname、management_ip、serial_number、mac_address。
• 硬件类：model（如 C9300-48P）、product_family（Catalyst 9000）、stack_member_count、power_supply_type。
• 软件类：ios_version（如 17.09.04a）、ios_image_name、license_level（Network Essentials / Advantage）。
• 角色类：device_role（core / distribution / access / wlc / firewall）、role_source（人工标注或自动推断）。
• 位置类：site、building、floor、room、rack、rack_unit、patch_panel_port。
• 管理类：management_protocol（SSH/SNMP/NETCONF）、reachability_status、last_seen_time。

字段定义完成后，采集才有目标。例如 serial_number 必须来自 show inventory 或 show version 的实体序列号，而不是接口 MAC；management_ip 必须来自管理 VRF 或 SVI，而不是任意可达地址。这一步决定了后续数据是否可信。

二、设备角色分类：从“是什么”到“干什么”

设备角色不是简单按型号划分，而是按它在网络中的功能定位划分。同一台 C9300 既可能是接入交换机，也可能是小型汇聚。角色分类建议采用“规则推断 + 人工确认”的方式：

1. 先根据 CDP/LLDP 邻居关系判断层级：如果一台设备的上联邻居是核心，且下联大量终端，则推断为 access。
2. 再根据路由能力判断：运行 OSPF/BGP 且连接多个网段的，推断为 distribution 或 core。
3. 最后根据端口密度和堆叠数量修正：堆叠成员多、端口密度高的接入层设备，角色保持 access。

角色字段一旦确定，就会直接影响配置模板的选择。例如 access 角色下发端口安全与 DHCP Snooping，core 角色下发路由与 QoS 策略。角色错分会导致模板误下发，因此平台应保留 role_source 字段，记录该角色是自动推断还是人工确认，便于审计。

三、位置信息：把设备放进物理空间

位置信息是资产建模中最容易被忽视、但在排障和现场维护中最有价值的部分。建议采用“站点—楼宇—楼层—机房—机柜—U 位”的六级结构，每一级用独立字段存储，而不是拼成一个长字符串。这样平台可以按任意层级聚合查询，例如“列出 A 栋 3 楼所有接入交换机”。

位置采集有三种来源：一是 CMDB 或工单系统导入；二是通过 LLDP 邻居的 chassis name 和 port description 反推；三是现场扫码或人工录入。实际项目中，建议以 CMDB 为准，LLDP 作为校验。如果 LLDP 显示的上联端口与 CMDB 记录的机柜 U 位矛盾，就应触发位置复核工单。

四、序列号与软件版本：唯一性与合规性的基础

序列号是资产的“身份证”，必须保证全局唯一。Catalyst 堆叠环境下，每台成员交换机都有独立序列号，平台应把堆叠整体作为一个资产，同时保留成员序列号列表。采集命令示例：

show inventory | include NAME|PID|SN
show version | include Cisco IOS|System image|uptime
show switch detail | include Switch|MAC address|Role

软件版本字段需要规范化。不同命令输出的版本格式可能不同，例如 17.09.04a、17.9.4a、IOS-XE 17.9.4a，平台应统一转换为“主版本.次版本.补丁”三段式，并保留原始字符串。版本规范化的目的是支持合规比对：例如企业基线要求“不低于 17.09.04a”，平台就能自动判断哪些设备需要升级。

五、数据质量校验：让模型可信

标准化完成后，必须做一轮数据质量校验，否则错误数据会一路传递到自动化执行环节。建议至少设置四条校验规则：

• 唯一性校验：serial_number 在资产库中不能重复；堆叠成员序列号必须与堆叠整体关联。
• 可达性校验：management_ip 必须能通过 SSH 或 SNMP 在超时时间内响应，否则标记为 unreachable。
• 一致性校验：device_role 与 LLDP 邻居层级、端口密度是否匹配，不匹配则进入人工复核队列。
• 合规性校验：ios_version 是否满足企业最低版本要求，不满足则生成升级建议。

校验结果应写入资产记录的状态字段，例如 validation_status: passed / warning / failed，并保留最近一次校验时间。这样运维人员打开资产详情页时，能一眼看出哪些字段可信、哪些需要复核。

六、一个可落地的资产字段模板

下面给出一份可直接参考的资产字段模板，字段名和示例值均属于教学示例，实际部署时应根据企业 CMDB 字段命名调整：

资产信息建模与标准化的价值，不在于字段多，而在于每个字段都有明确的来源、格式和校验规则。当序列号、版本、角色、位置这些字段被统一后，平台才能真正做到“按角色下发配置、按版本判断合规、按位置定位设备”。这一步做扎实，后续的自动化配置和合规审计才有可靠的数据基础。