4. 迁移升级前的现状评估

在 Nexus 数据中心迁移与升级工程中，现状评估是决定后续方案可行性的关键一步。很多项目失败并非因为目标架构设计得不好，而是因为对现网“家底”掌握不清：漏掉一条 VPC 对等链路、误判某个 vPC 域的双活状态、低估了东西向流量的峰值，都会在割接窗口内演变成业务中断。本节围绕四个动作展开——物理拓扑发现、逻辑配置采集、流量基线分析、性能瓶颈与风险识别，并给出可落地的采集方法与判断依据。

一、物理拓扑发现：先看清“线怎么连”

物理拓扑发现的目标是得到一张可信的设备—端口—链路映射表，包含设备型号、角色（Spine/Leaf/边界/服务节点）、管理 IP、软件版本、端口速率与光模块类型。推荐以 CDP/LLDP 邻居表为起点，再用 show interface 与 show inventory 交叉校验，避免只依赖单一来源。

# 采集邻居关系（逐台执行，输出重定向到文件）
show cdp neighbors detail
show lldp neighbors detail
# 端口与光模块
show interface status | include connected
show interface transceiver details
# 设备清单与版本
show inventory
show version | include "system: version|NXOS"

实操中要特别关注三类“隐性连接”：一是跨机柜的 MTP/MPO 主干，端口编号与配线架标签常不一致；二是带外管理链路，迁移时若遗漏会导致设备失联；三是存储与服务器侧的绑定关系，例如 FCoE 或 SAN Boot 的 HBA 与交换机端口对应。建议把采集结果整理成“设备—端口—对端设备—对端端口—速率—用途”六列清单，作为后续割接顺序的依据。

二、逻辑配置采集：还原“业务怎么跑”

逻辑配置决定业务可达性，重点采集 VLAN/VXLAN 映射、vPC 域、HSRP/VRRP、路由协议、ACL 与 QoS。Nexus 环境建议使用 show running-config 分段导出，并配合 show vpc、show vlan、show ip route 等命令验证运行态与配置态是否一致。

show vpc brief
show vpc consistency-parameters global
show vlan brief
show vrf
show ip route vrf all summary
show running-config | section "feature|interface|router"

采集时要建立“配置—业务”对应关系：哪些 VLAN 承载生产、哪些承载管理、哪些是隔离区；vPC 域中 peer-link 与 peer-keepalive 的物理路径是否分离；路由协议的邻居与计时器是否与对端匹配。一个常见风险是配置态显示 vPC 正常，但 peer-link 与业务链路共用同一物理板卡，一旦板卡故障会同时失效。因此逻辑采集必须与物理拓扑对照，才能发现这类“逻辑正常、物理脆弱”的问题。

三、流量基线分析：量化“跑多少、往哪跑”

流量基线用于回答三个问题：峰值带宽、流量方向、突发特征。采集周期建议覆盖至少一个完整业务周期（如 7 天），采样间隔 1～5 分钟。可用 SNMP 轮询接口计数器，或通过 Nexus 的 sFlow/NetFlow 获取流级信息。

# 接口速率与错包（示例）
show interface Ethernet1/1 | include "rate|input errors|output errors"
# 流采样配置（示例）
feature sflow
sflow agent-ip 10.0.0.1
sflow collector-ip 10.0.0.100
sflow data-source interface Ethernet1/1

分析时不要只看平均值。以某 Leaf 上行 40G 链路为例，日均利用率 35%，但每日 09:00—10:00 出现 82% 的 5 分钟峰值，且伴随微突发（microburst）。若迁移后新链路按 40G 规划，峰值余量仅 18%，遇到存储备份叠加就会拥塞。因此基线报告应包含：峰值利用率、95 分位利用率、错包/丢弃计数、Top N 会话与方向。判断依据可设为：峰值利用率持续超过 70% 即视为需要扩容或调整路径。

四、性能瓶颈与风险识别：把问题变成可执行清单

瓶颈通常出现在四个位置：上行链路、vPC peer-link、控制平面 CPU、以及跨 Pod 的 Spine 转发。识别方法是对照基线数据与硬件规格：若某 Leaf 上行峰值已达 82%，而 peer-link 同时承载跨 Leaf 流量，则 peer-link 可能先于上行饱和。控制平面方面，检查 show processes cpu history 与 show system resources，若 BGP/ARP 进程在收敛时 CPU 超过 80%，迁移后规模扩大将加剧震荡。

风险识别建议按“发生概率 × 影响范围”分级，并给出缓解动作。例如：单板卡承载 peer-link 与业务链路——概率中、影响大——缓解为迁移前拆分物理路径；软件版本存在已知 Bug——概率低、影响大——缓解为升级到目标版本前先查 Cisco Bug 数据库；未采集带外管理链路——概率高、影响中——缓解为补录并纳入割接检查表。

五、把评估结果变成可执行的迁移输入

完成上述采集后，应形成四份可直接使用的交付物：物理拓扑与端口映射表、逻辑配置与业务对应表、流量基线报告、风险台账。它们不是文档摆设，而是后续割接顺序、回退方案和验收标准的输入。例如，端口映射表决定先割接哪些 Leaf；流量基线决定维护窗口是否足够；风险台账决定哪些问题必须在割接前解决、哪些可以带风险上线并准备回退。

最后需要强调：现状评估的深度应与迁移风险成正比。对于核心生产区，建议做到端口级和会话级；对于测试或非关键区，可适当简化。但无论范围如何，物理、逻辑、流量、风险四个维度都应覆盖，否则割接窗口内出现意外时，团队将缺少判断依据和回退抓手。