Expect脚本在SDN异构网络自动化运维中的实践

1. 项目背景与痛点分析

在网络自动化运维领域，OpenDaylight（ODL）作为主流SDN控制器，常被用于大规模网络设备的集中管控。但在实际生产环境中，我们经常会遇到一个棘手问题：当需要通过ODL向网络设备下发复杂配置（如OSPF/BGP/SRv6等高级路由协议）时，传统NETCONF/YANG方式往往会因为设备厂商实现差异、模型映射不全等问题导致配置失败。

我在某运营商广域网改造项目中就遇到了类似情况：需要在300多台异构设备（华为/思科/中兴混合组网）上批量部署SRv6策略。ODL的标准南向接口对这些设备的支持参差不齐，特别是针对不同厂商设备的OSPFv3扩展字段和SRv6 SID分配逻辑存在兼容性问题。更麻烦的是，部分老旧设备甚至没有完整的NETCONF实现，只能依赖CLI进行配置。

2. 技术选型与方案设计

2.1 主流方案对比

面对这种场景，通常有几种技术路线可选：

1. ODL原生适配：开发定制化的YANG模型和驱动插件
   • 优点：符合SDN最佳实践
   • 缺点：开发周期长，需针对不同厂商单独适配
2. Ansible剧本：通过厂商提供的模块批量执行CLI
   • 优点：利用现有工具链
   • 缺点：对交互式配置支持有限，错误处理复杂
3. Expect脚本：模拟人工SSH操作过程
   • 优点：兼容所有支持SSH的设备，可处理任意CLI交互
   • 缺点：需要编写精确的交互逻辑

2.2 Expect方案核心优势

选择Expect脚本作为补充方案，主要基于以下考量：

• 100%设备兼容性：只要设备开放SSH，就能实现配置下发
• 即时生效：绕过ODL的模型转换层，直接使用设备原生CLI
• 灵活应对异常：可以捕获(y/n)?等交互提示
• 轻量级部署：无需在设备端安装额外组件

典型应用场景包括：

• 厂商私有CLI命令的批量执行
• 需要确认提示的配置变更（如路由协议重置）
• 设备启动阶段的初始化配置（此时NETCONF服务可能未就绪）

3. Expect脚本开发详解

3.1 基础框架搭建

一个健壮的Expect脚本应包含以下模块：

bash复制#!/usr/bin/expect -f
# 1. 参数