📚 课程目录第4章 Nexus基础配置交付基线

4. Nexus基础配置交付基线

在Nexus交换机完成上架、加电和初始console接入之后，真正决定设备能否被纳入统一运维体系、能否被监控、能否被审计、能否被安全登录的，是一组看似零散但彼此关联的基础配置。这些配置构成了设备的“交付基线”——它们不是业务功能，却是所有业务功能得以稳定运行和可管理的前提。本节围绕管理IP、带外管理、AAA、NTP、Syslog、SNMP、SSH、Banner、时钟与域名等要素，说明如何形成一套标准化、可复现、可验收的基础配置交付基线。

为什么基础配置需要“基线化”

单台设备手工配置管理地址和SNMP并不困难，但当项目涉及数十台甚至上百台Nexus时，问题就出现了：不同工程师配置的NTP服务器不一致、Syslog级别不统一、AAA认证顺序有差异、SSH版本和超时时间各不相同。这些差异在故障排查时会显著增加成本，也会让验收方难以判断“配置是否完整”。因此，基础配置交付基线的核心不是“配了什么”，而是“所有设备是否按同一套标准配了同样的东西”。

基线通常包含两类内容：一类是必须存在的配置项（如管理IP、默认网关、AAA、NTP、Syslog、SNMP、SSH、Banner、时钟、域名），另一类是这些配置项必须满足的参数约束（如NTP必须同步到指定源、Syslog必须指向两台采集器、SSH必须禁用v1、Banner必须包含未授权访问警告）。验收时，前者通过配置比对确认，后者通过状态命令确认。

管理IP与带外管理

Nexus的管理访问通常分为带内管理和带外管理两条路径。带内管理通过业务接口或管理接口所在的VRF（通常是management VRF）提供，带外管理则通过独立的MGMT接口和专用管理网络提供。交付基线中必须明确：管理接口属于哪个VRF、使用哪个地址段、默认网关指向哪里、是否允许带内与带外同时可达。

以Nexus 9000为例，典型配置如下：

interface mgmt0
  vrf member management
  ip address 10.10.10.21/24
  no shutdown

vrf context management
  ip route 0.0.0.0/0 10.10.10.1

这里的关键判断点是：管理接口必须绑定到management VRF，默认路由也必须在该VRF内配置，否则会出现“接口有地址但无法跨网段访问”的典型问题。验收时使用 show ip route vrf management 确认默认路由存在，使用 ping 10.10.10.1 vrf management 确认网关可达。

AAA、SSH与Banner

AAA决定了“谁能登录、登录后能做什么、操作是否被记录”。交付基线中通常要求使用TACACS+或RADIUS作为认证源，本地用户仅作为fallback。认证顺序、授权方式和记账方式必须统一。例如：

aaa group server tacacs+ TACACS-GRP
  server 10.20.1.11
  server 10.20.1.12

aaa authentication login default group TACACS-GRP local
aaa authorization console
aaa authorization exec default group TACACS-GRP local
aaa accounting default group TACACS-GRP

SSH方面，基线通常要求禁用SSH v1、限制登录超时、启用强加密算法，并只允许特定源地址访问。Banner则用于法律告知，必须在登录前显示，内容应包含“未经授权禁止访问”的声明。验收时使用 show ssh server 确认版本和超时，使用 show running-config | include banner 确认Banner存在。

NTP、时钟与Syslog

时间同步是日志关联和故障排查的基础。Nexus应配置至少两个NTP服务器，并指定优先源。时钟时区必须统一，通常使用UTC或项目规定的本地时区。Syslog应指向两台采集器，日志级别和源接口需明确。例如：

ntp server 10.30.1.10 prefer
ntp server 10.30.1.11
clock timezone CST 8 0
logging server 10.40.1.20 6 use-vrf management
logging server 10.40.1.21 6 use-vrf management
logging source-interface mgmt0

验收时使用 show ntp status 确认时钟已同步（显示“Clock is synchronized”），使用 show logging server 确认Syslog服务器状态为“active”。如果NTP未同步，Syslog时间戳将不可信，后续审计和排障都会受到影响。

SNMP与域名

SNMP用于监控平台采集设备性能与状态。基线中应明确SNMP版本（通常v2c或v3）、团体字或用户认证方式、Trap目标地址。v3比v2c更安全，但配置复杂度更高。域名则用于设备标识和部分功能（如DNS解析、证书），通常配置为项目统一域名。例如：

snmp-server community NEXUS-RO-2024 ro
snmp-server host 10.50.1.30 traps version 2c NEXUS-RO-2024
snmp-server enable traps
ip domain-name corp.example.com
ip name-server 10.60.1.40

验收时使用 show snmp community 确认团体字，使用 show snmp host 确认Trap目标，使用 show ip domain-name 确认域名。

标准化交付的落地方式

要让上述配置真正成为“基线”，建议在项目中使用配置模板或自动化工具（如Ansible、NX-OS API）批量下发，并在交付前执行一次基线核查。核查可以按配置域逐项进行，也可以编写脚本自动比对。对于验收方而言，最直接的证据是：每台设备的 show running-config 中相关段落与基线模板一致，且状态命令输出符合预期。

交付提示：基础配置基线应在项目启动阶段就确定并冻结，避免在交付后期反复修改。所有设备配置完成后，建议导出配置文件并归档，作为验收材料的一部分。

常见问题：管理接口未绑定management VRF、NTP未同步导致日志时间错乱、SNMP团体字使用默认值、SSH未禁用v1，是Nexus基础配置交付中最常见的四类问题，验收时应重点检查。

基础配置交付基线不是一次性任务，而是设备全生命周期管理的起点。只有管理IP可达、AAA可控、时间可信、日志可查、监控可采，后续的业务配置和故障排查才有可靠的基础。在验收文档中，建议将本节涉及的配置项和验收命令整理成检查表，逐台设备确认，确保交付质量可追溯、可复核。