📚 课程目录第4章 Catalyst Center资产库存管理

4. Catalyst Center资产库存管理

Catalyst Center的资产库存（Inventory）是整套自动化能力的起点。设备没有被正确纳管，后续的模板下发、合规检查、软件镜像升级、AI网络分析都无从谈起。本节围绕“设备添加—分组—标签—站点分配—生命周期跟踪”这条主线，讲清在界面和API两条路径上分别怎么做，以及每一步在库存数据模型中留下的痕迹。

一、库存数据模型：先理解对象，再谈操作

Catalyst Center库存中的每台设备都是一条记录，其核心字段包括：管理IP地址、设备主机名、平台型号（PID）、软件版本、序列号、MAC地址、设备角色（Access/Distribution/Core/Fabric Edge等）、站点归属、标签集合、纳管状态（Managed/Unmanaged/Error）以及生命周期状态（如已发现、已纳管、已认证、已加入站点、已退役）。

设备添加的本质，是让Catalyst Center通过SNMP、NETCONF、SSH等协议与设备建立可信连接，并把上述字段写入库存数据库。分组、标签、站点分配则是在这条记录上附加组织维度，让后续的策略下发可以按“组/标签/站点”批量命中目标设备，而不必逐台选择。

二、界面路径：从Discovery到站点分配

在Catalyst Center界面中，最常用的入口是 Provision > Inventory。点击“Add Device”可以手动添加单台设备，需要填写管理IP、SNMP RO/RW团体字、NETCONF端口（默认830）、CLI用户名密码。提交后，Catalyst Center会依次尝试SNMP探测、SSH/NETCONF连接，成功则设备状态变为Managed，失败则在Inventory中显示Error并给出原因（如“SNMP timeout”或“Authentication failed”）。

批量场景更适合用 Discovery：指定一个IP范围（例如 10.10.20.0/24）和一组凭据，Catalyst Center会并发扫描并自动纳管响应设备。Discovery任务完成后，可以在任务详情中看到每台设备的发现结果，未成功的设备会标注失败原因，便于针对性排查。

设备纳管后，进入 Provision > Inventory > Device Groups 创建分组。分组是层级树结构，例如可以建“总部/核心层”“分支/接入层”这样的父子组。把设备拖入分组后，后续的模板、策略、软件升级都可以直接以组为目标下发。

标签（Tag）在 Provision > Inventory > Tags 中管理。标签是键值对形式，例如 env:production、owner:netops、compliance:pci。一台设备可以打多个标签，标签与分组是正交的：分组表达“设备在组织中的位置”，标签表达“设备具备的属性”。例如“所有生产环境且需要PCI合规的接入交换机”这个集合，就是通过标签组合筛选出来的，而不是靠分组层级。

站点分配在 Provision > Inventory > Sites 中完成。站点是物理位置层级：区域（Area）→楼栋（Building）→楼层（Floor）。把设备分配到具体楼层后，Catalyst Center的地图视图才能正确定位设备，基于位置的合规策略（如“所有位于上海园区的设备必须运行指定版本”）也才能生效。

三、API路径：批量与自动化的正确姿势

当设备数量达到数百台，或者需要把纳管流程嵌入CI/CD、工单系统时，界面操作就不够用了。Catalyst Center提供Intent API，核心端点包括：

# 添加设备（单台）
POST /dna/intent/api/v1/network-device
{
  "ipAddress": ["10.10.20.11"],
  "snmpROCommunity": "ro_community",
  "snmpRWCommunity": "rw_community",
  "netconfPort": "830",
  "cliTransport": "ssh",
  "userName": "admin",
  "password": "C1sco12345",
  "type": "NETWORK_DEVICE"
}

# 查询库存设备
GET /dna/intent/api/v1/network-device?managementIpAddress=10.10.20.11

# 创建设备分组
POST /dna/intent/api/v1/group
{
  "name": "Branch-Access",
  "groupType": "SITE",
  "parentGroupId": "<parent-uuid>"
}

# 给设备打标签
POST /dna/intent/api/v1/tag
{
  "name": "env:production",
  "resourceIds": ["<device-uuid>"]
}

# 分配站点
POST /dna/intent/api/v1/site/{siteId}/device
{
  "deviceIds": ["<device-uuid>"]
}

实际使用中，建议先用 GET /dna/intent/api/v1/network-device 拉取全量库存，用返回的 id 字段作为后续分组、标签、站点操作的资源标识。批量添加时，可以把设备列表拆成每批50台并发提交，避免单次请求过大导致超时。每次操作后通过 GET /dna/intent/api/v1/task/{taskId} 查询任务状态，确认成功后再进入下一步。

四、生命周期跟踪：状态迁移与异常处理

资产生命周期不是静态的。一台设备从“已发现”到“已纳管”，再到“已分组/打标”“已分配站点”，最后可能因为替换或下线进入“已退役”。每次状态迁移都应该有明确的触发条件和记录。

常见的异常场景包括：设备更换了管理IP但库存中仍是旧IP，导致状态变为Unreachable；SNMP团体字被修改后Catalyst Center无法再采集信息，设备显示为Partial Collection Failure；设备被手动从库存删除但未在物理上退役，造成“幽灵资产”。处理这些问题的通用方法是：先用 GET /dna/intent/api/v1/network-device?managementIpAddress=... 确认当前库存记录，再决定是更新凭据、重新同步还是执行退役操作。

退役（Decommission）与删除（Delete）不同：退役会保留设备的历史数据（如配置变更记录、合规检查结果），只是将其标记为不再参与策略下发；删除则会从库存中彻底移除记录。生产环境中建议优先使用退役，保留审计线索。

五、一个可复用的纳管检查清单

无论走界面还是API，纳管一台设备后建议逐项确认以下内容，确保库存数据完整可用：

检查项	预期结果	验证方式
管理IP可达	ping通，SNMP响应正常	Inventory中状态为Managed
设备角色正确	Access/Distribution/Core等与实际一致	设备详情页Role字段
软件版本已采集	显示实际运行的IOS-XE版本	设备详情页Software Version
已加入正确分组	分组路径与网络架构一致	Device Groups视图
标签完整	env、owner、compliance等关键标签已打	Tags视图按设备筛选
站点已分配	区域/楼栋/楼层与实际位置一致	Sites视图或地图定位
生命周期状态	处于Managed且无Error标记	Inventory列表状态列

把这套流程固化下来，库存就不再是一张“设备清单”，而是后续所有自动化动作的可信数据源。设备添加、分组、标签、站点分配、生命周期跟踪这五步，本质上是在为每一台设备建立一份可被程序读取的“身份档案”，档案越完整，自动化能做的事情就越多。