2. Nexus配置基线建立

配置基线不是把一台“运行正常”的Nexus交换机配置原样导出，而是把业务意图、安全要求与平台约束三者收敛成一组可验证、可复用、可审计的配置规则。黄金配置（Golden Config）是这套规则的参考实现，基线模板是它的参数化骨架，合规策略则是把规则翻译成可自动判定的检查项。三者关系可以概括为：黄金配置回答“正确长什么样”，基线模板回答“不同角色怎么套用”，合规策略回答“偏离多少算违规”。

建立基线前必须先明确适用范围。Nexus平台差异很大：Nexus 9000系列以NX-OS为主，支持VXLAN EVPN、vPC、FEX等特性；Nexus 3000偏接入；Nexus 7000偏核心。同一份黄金配置不可能同时适配Spine、Leaf、Border Leaf和OOB管理交换机。因此第一步是按角色（Role）划分设备族，例如：Spine-Leaf架构中的Spine、Leaf、Border Leaf、管理接入交换机。每个角色对应一份基线模板，模板中固定的是安全与管理类配置，可变的是接口、VLAN、路由邻居等业务参数。

黄金配置的内容通常分为五类。第一类是身份与访问控制：TACACS+/RADIUS服务器、本地fallback账号、AAA认证授权、SSH v2、ACL限制管理源、禁用Telnet和HTTP。第二类是系统与高可用：NTP服务器、时区、日志服务器、SNMPv3、vPC域、STP模式、BFD。第三类是二层与三层基础：VLAN范围、SVI、HSRP/VRRP、OSPF/BGP/IS-IS邻居、MTU、QoS信任边界。第四类是安全加固：CoPP、控制平面ACL、端口安全、DHCP Snooping、动态ARP检测、IP Source Guard。第五类是可运维性：接口描述规范、SNMP位置、NetFlow/sFlow、配置归档与回滚点。

下面给出一个Leaf角色的黄金配置片段示例，参数为教学假设值，实际部署需按环境替换：

hostname LEAF-01
feature bgp
feature interface-vlan
feature vpc
feature nxapi
feature lldp

ntp server 10.10.10.20 use-vrf management
clock timezone CST 8 0
logging server 10.10.10.30 6 use-vrf management
snmp-server user netops network-admin auth sha AuthPass123 priv aes-128 PrivPass123
snmp-server host 10.10.10.30 use-vrf management version 3 auth netops

aaa group server tacacs+ TAC-GRP
  server 10.10.10.40
  source-interface mgmt0
aaa authentication login default group TAC-GRP local
aaa authorization commands default group TAC-GRP local
aaa accounting default group TAC-GRP local

ip access-list MGMT-ACL
  10 permit tcp 10.10.20.0/24 any eq 22
  20 permit tcp 10.10.20.0/24 any eq 443
  30 deny ip any any log
interface mgmt0
  ip address 10.10.30.11/24
  ip access-group MGMT-ACL in

vpc domain 10
  peer-switch
  peer-keepalive destination 10.10.40.2 source 10.10.40.1 vrf management
  role priority 1000
  system-priority 2000
  peer-gateway
  auto-recovery reload-delay 240

interface Ethernet1/1
  description UPLINK-TO-SPINE-01
  no switchport
  mtu 9216
  ip address 10.0.1.1/30
  no shutdown

这段配置体现了黄金配置的几个关键原则：管理面与业务面分离（mgmt0 + management VRF）、AAA先TACACS+后本地、管理ACL默认拒绝并记录、vPC使用独立keepalive链路、接口描述采用统一命名规范。这些规则在模板中应作为不可变段（Immutable Block），而接口IP、VLAN ID、BGP AS号等作为可变参数（Variable）。

基线模板的落地方式有三种常见选择。第一种是纯文本模板 + 变量替换，适合小规模、变更频率低的场景，用Python或Ansible的template模块渲染。第二种是Ansible/NX-OS模块，用nxos_config、nxos_vlan、nxos_bgp等模块声明式下发，天然支持幂等。第三种是Nexus Dashboard / NDFC，把基线作为Fabric策略的一部分，由控制器保证一致性。无论哪种方式，模板都应纳入Git版本管理，每次变更走Pull Request评审，保留diff和审批记录。

合规策略是把黄金配置转成可判定的规则。规则分三类：存在性检查（如必须存在NTP server）、值检查（如SSH版本必须为2）、否定性检查（如不得存在Telnet、不得使用默认SNMP community）。每条规则要有唯一ID、严重级别、检查命令和期望结果。例如：

合规检查的执行方式有两种：离线比对和在线巡检。离线比对是把设备当前配置导出，与黄金配置做结构化diff，适合变更前后验证。在线巡检是通过NX-API或SSH定期执行检查命令，把结果写入合规数据库，适合持续监控。建议两者结合：变更窗口用离线比对做门禁，日常用在线巡检做漂移检测。

基线建立后必须处理例外管理。现实中总会有设备因为硬件限制、临时业务需求或历史遗留而偏离基线。例外不能口头批准，而应记录为带过期时间的豁免单，包含设备、规则ID、原因、批准人和失效日期。合规系统在计算合规率时应区分“已豁免偏离”和“未豁免偏离”，否则合规率会失真。

最后需要强调，基线不是一次性文档，而是活的资产。每次安全事件、架构变更或审计发现都应触发基线评审。建议每季度做一次全量合规扫描，每月抽查10%设备，每次变更后对涉及设备做即时比对。合规率目标可以设为：高优先级规则100%合规，中优先级≥95%，低优先级≥90%。低于阈值时，不是简单“整改”，而要回溯是模板缺陷、执行遗漏还是例外未登记，分别修正模板、补执行或补豁免。只有把基线、模板、策略和例外管理串成闭环，Nexus配置治理才真正可落地。