ADDC6.0纳管设备修改sysname有啥影响？

核心结论：ADDC6.0 设备纳管唯一标识是 SN + 管理 IP，不是 sysname。业务转发、VLAN、IRF、隧道、自动化基线下发本身不会中断；但有平台侧展示、运维脚本、拓扑、基线预配置等关联风险；区分手工上线设备、自动化上线设备风险差异。

一、自动上线设备（DHCP 零配置开局上线）风险点

1. 开局阶段依赖 sysname 匹配配置文件（历史 autocfg 机制） 设备空配置上电自动开局时，TFTP 服务器 network.cfg 通过 sysname 匹配.cfg 配置文件。已经纳管上线成功之后，再修改 sysname 不会影响现有业务；但如果后续设备重启、重新触发 autocfg 自动配置，会去匹配新 sysname 对应的配置文件，找不到就会加载通用模板，造成配置错乱。

规避：已上线设备，关闭 autocfg 自动配置，undo autocfg，避免重启再次触发自动开局。

2. ADDC 平台内部识别：上线完成后，平台以 SN 作为主键识别设备，sysname 仅作为展示名称，不会因为 sysname 变更导致设备脱管、代理断开、采集中断。

二、手工上线纳管设备风险点

手工添加（SN 录入方式）的设备，上线完成后修改 sysname 对平台纳管、业务转发无直接冲击，风险更多是外部关联系统 / 运维资产台账不一致。

三、通用风险（自动、手工上线设备全部适用）

1. 拓扑视图、资产台账、报表名称不同步 仅在设备命令行sysname xxx修改，ADDC 平台设备名称不会自动刷新。拓扑、资产清单、告警日志里依然显示旧名称；告警、Trap 日志、syslog 日志内设备主机名变成新名字，平台展示名和日志名称不一致，排障容易混淆。 ✅正确操作：改完设备 sysname，在 ADDC 设备管理页面手动同步 / 修改平台内的设备显示名称，两边保持一致。
2. 基线、预配置模板、策略内硬编码引用旧 sysname 如果基线模板、CLI 策略、自动化脚本、运维自动化（巡检 / 备份脚本、堡垒机、监控平台）写死旧 sysname，会导致备份、巡检、脚本执行失败。

重点：ADDC 基线是按设备角色 / 型号下发，正常基线不硬写 sysname；客户自定义脚本、外部对接系统最容易踩坑。

3. IRF 堆叠场景特殊风险 IRF 组内修改成员 sysname不影响 IRF 堆叠协议；但如果 ADDC 拓扑、IRF 模板、运维脚本绑定了旧 sysname，拓扑展示异常，IRF 信息采集展示错乱。建议 IRF 成员统一修改，同步更新平台 IRF 组名称。
4. 命名字符限制：sysname 不支持空格、特殊符号，否则会造成 Trap、日志、采集解析异常。

四、推荐操作步骤（变更窗口执行）

1. 变更前：设备配置备份；核查 ADDC 基线 / 自定义脚本 / 外部监控堡垒机是否写死旧 sysname；记录旧名称。
2. 设备上修改 sysname，save保存配置。
3. ADDC 平台【设备管理】，编辑设备信息，同步修改平台侧设备显示名称，与设备 sysname 保持一致。
4. 验证：设备在线状态、采集、拓扑、告警上报、基线校验是否正常；查看 syslog/Trap 日志主机名是否更新。
5. 自动上线设备额外操作：undo autocfg关闭自动配置，防止设备重启后重新触发 autocfg 匹配错误配置文件。

五、禁止操作

不要只在 ADDC 平台页面改展示名，不同步修改设备侧真实 sysname，会造成平台名称和设备实际名称永久不一致，日志排障混乱。

小结

ADDC6.0 以 SN 作为纳管主键，已纳管设备修改 sysname 不会直接断业务、不会自动脱管。 风险主要集中：①自动上线设备重启触发 autocfg 配置匹配异常；②平台资产拓扑名称和设备真实 sysname 不一致；③自定义运维脚本、外部监控堡垒机硬编码旧名称失效。修改后务必在 ADDC 平台同步更新设备显示名；自动上线设备需要关闭 autocfg。

需要精简简短知了提交版吗？