📑课程信息
- 领域：计算机科学 / 网络自动化（Cisco NSO 网络服务编排器）
📖 知识精讲
本课程系统讲解 Cisco NSO 核心概念、架构组件、CLI 操作、设备管理、服务包开发与 RESTCONF API 使用，结合专家实战经验，帮助学员掌握企业级网络自动化编排的完整工作流。
课程整体介绍与学习路径
-
课程定位：面向网络工程师的 NSO 入门课程，覆盖理论与 5 个实操实验，完成全部内容约需 9 小时。
-
🚩重点：课程核心学习目标包括首次使用 NSO、管理设备清单、配置与排障设备、创建服务包、调用 NSO RESTCONF API。
-
补充说明 ：官方推荐课后访问 https://developer.cisco.com/nso 补充学习 NSO 完整功能。
-
-
技术背景铺垫：传统手动逐台配置或老旧 NMS 已无法适配动态融合的网络环境，自动化编排成为必然趋势，课程将覆盖 Python 可编程性、XML 数据格式、REST API、RESTCONF、NETCONF 等核心技术。
传统网络管理的痛点
-
传统自动化的缺陷：早期设备级自动化缺乏可扩展性，容易产生配置漂移，无法提供全网全局视图。
- 🚩重点：仅具备部分自动化能力的 NMS 会产生多个配置变更来源，导致全网没有单一可信数据源，最终引发配置不一致与配置漂移。
-
单点故障风险：即使是企业级 NMS（如 Cisco Prime、DNA Center）也存在灵活性不足的问题，不同团队通过脚本、模板生成变通方案，甚至直接在设备上手动修改配置，彻底破坏全网配置一致性。
网络编排层的核心价值
-
编排层定位：在企业 IT 管理系统与底层网络之间新增一层功能层，将全网抽象为单一实体，通过统一协议/API 进行可靠操作。
- 🚩重点：编排层消除了直接管理单台设备的需求，接收上层抽象的服务激活请求后，自动将其转化为跨多设备多特性的批量自动化配置变更。
-
NSO 角色匹配：NSO 完全符合编排层定位，是支持任意规模多厂商网络的控制器级管理平台，南向通过设备原生协议通信，北向提供统一数据模型驱动的接口。
Cisco NSO 核心架构
-
南北向接口分层：北向支持 NETCONF、REST、CLI、WebUI、SNMP、Python、Java 多种接入方式，南向通过 NED（网络元素驱动）对接多厂商物理/虚拟网络环境。
- 🚩重点：NSO 典型配置工作流分为 6 步：启动会话获得全网配置草稿 → 编辑候选配置 → 验证候选配置 → 提交事务 → 全部设备成功则全网生效 → 任意设备失败则自动全量回滚。
-
核心组件拆解：包含北向接口代理、服务管理器、设备管理器、映射逻辑层、NED、包管理器、核心引擎、告警管理器等模块，各组件协同完成全网配置的统一管控。
配置数据库（CDB）详解
-
CDB 核心特性：基于 YANG 数据模型的事务型内存分层数据库，采用树状层级结构存储全网设备配置、服务激活请求、系统配置与运行数据。
- 🚩重点：CDB 是 NSO 的单一可信数据源，始终保存 NSO 视角下的完整全网配置视图。
-
核心引擎功能 ：以操作系统守护进程
ncs形式运行，负责 CDB 数据访问、事务执行、变更历史维护、RBAC 权限控制、数据校验、高可用集群数据复制等核心能力。
Device Manager 设备管理器
-
核心职责：将 CDB 中的配置事务可靠下发到物理/虚拟网络设备，实现全网原子一致性操作。
- 🚩重点：设备管理器采用并行下发配置机制，任意设备配置失败则自动触发全网回滚，将网络恢复到事务执行前的一致状态。
-
NED 网络元素驱动：NSO 通过 NED 与不同厂商设备通信，NED 内置设备 YANG 模型、原生协议逻辑与协议转换代码，支持 NETCONF、CLI、SNMP、Generic 四种类型。
Service Manager 服务管理器
-
核心价值：屏蔽厂商设备特性的配置复杂度，将其封装在服务包内部，实现网络服务的抽象化管理。
- 🚩重点：服务管理器通过 FASTMAP 算法对比 CDB 中现有配置与服务变更，计算出最小必要变更集合，大幅提升配置下发效率。
-
映射逻辑：将服务实例数据转化为完整的设备配置变更集合，由 XML 配置模板与可选的 Java/Python 自定义代码两部分组成。
NSO CLI 命令行接口
-
CLI 核心特性：北向统一命令行接口，完全基于 YANG 数据模型驱动，支持 Juniper 风格（默认）与 Cisco XR 风格两种操作模式。
- 🚩重点：CLI 分为操作模式与配置模式，所有配置变更先写入本地候选配置副本，提交后才会生效，避免直接修改设备配置。
-
配置读写逻辑：CLI 展示的配置信息来自 CDB，NSO 按需自动连接设备同步配置；提交变更时自动计算最小差异，并行推送到所有设备。
-
带外变更场景：分为三类：无带外变更（NSO 为唯一可信源）、受控带外变更（不影响 NSO 管理的配置区域）、非受控带外变更（属于运营故障事件）。
-
多用户冲突处理：多个用户可并行启动独立配置会话，提交时若出现配置冲突，用户可选择覆盖变更或中止会话解决冲突。
Device Manager 进阶操作
-
CDB 设备子树结构：包含设备清单、认证组、设备组、设备模板四大核心部分，实现设备的批量管理。
- 🚩重点：设备清单中每台托管设备必须配置逻辑名称、可达性信息、认证组、设备类型与 NED 标识，且需将管理状态从默认的 southbound-locked 解锁才能下发配置。
-
设备组功能：支持嵌套分组，可对整组设备批量执行同步、连接、模板下发等操作，大幅提升批量运维效率。
NetDevOps 集成实战经验
-
NSO 在 NetDevOps 流水线中的定位：原生面向配置管理设计，通过 NED 自动解析设备配置为 JSON/YAML 格式，可直接接入 CI/CD 流水线，实现配置即代码的自动化管理。
- 🚩重点：可通过 NSO Actions 调用 pyATS/Genie、TextFSM 等工具自动解析设备运行数据，在 NSO 内部完成配置下发前后的状态校验。
-
服务包的核心优势：内置服务元数据追踪能力，自动记录所有配置变更与服务关联关系，相比传统纯文本模板更智能，支持数据模型校验与第三方系统（如 IPAM）集成。
-
团队技能要求：无需全员精通 YANG 与 XML，仅核心开发人员掌握即可，其他团队通过 CLI、GUI、REST API 直接消费封装好的服务，屏蔽底层复杂度。
设备管理器高级运维
-
CDB 同步机制 ：设备未同步时提交配置会触发报错，可通过
sync-from从设备拉取配置同步到 CDB，通过sync-to将 CDB 配置推送到设备。- 🚩重点：提交配置时推荐添加标签与备注，便于后续事务回溯与回滚操作。
-
提交命令扩展参数：支持 check（仅校验）、dry-run（预览变更）、no-networking（仅修改 CDB）、no-out-of-sync-check（忽略同步校验）、no-override（粒度同步校验）等多种模式。
-
回滚机制：NSO 自动为每个成功提交的事务生成回滚文件，回滚操作会将全网恢复到指定事务之前的状态，回滚本身会作为新事务记录在提交列表中。
-
设备模板与排障：设备模板用于存储标准化最佳实践配置，支持变量与 replace 标签；流量追踪功能可记录 NED 与设备之间的完整通信日志，用于排障配置下发失败问题。
NSO 服务核心概念
-
服务体系定义：服务是 NSO 的核心，在设备管理器抽象基础上进一步封装，实现服务感知的自动化编排。
- 🚩重点：服务相关核心术语包括服务类型、服务实例、服务模型、服务应用、服务实例生命周期，全部通过 NSO 包管理器进行部署管理。
-
服务包结构 ：包含服务 YANG 模型、XML 配置模板、可选 Java/Python 自定义代码，部署时需先编译再执行
packages reload命令加载激活。
服务包开发实战
-
服务骨架生成：NSO 支持自动生成三种类型的服务骨架：模板型、代码型、代码+模板型，大幅降低开发门槛。
- 🚩重点：YANG 模型中定义的 leaf、leaf-list、container、list 等节点类型，用于精确约束服务参数的数据类型、取值范围与必填属性。
-
模板开发技巧 ：可通过 CLI 执行
commit dry-run out format XML快速生成基础配置模板，将静态值替换为带/{参数名}格式的变量即可完成模板改造。 -
服务实例生命周期管理：创建/修改服务实例时 FASTMAP 自动计算最小变更，仅推送差异配置；删除服务实例时自动清理所有相关设备上的对应配置。
RESTCONF API 使用
-
RESTCONF 协议特性：基于 HTTP 的无状态协议，通过标准 CRUD 方法操作 YANG 定义的数据，推荐使用 XML 作为数据编码格式。
- 🚩重点：NSO 的北向 API 完全动态适配 YANG 数据模型，YANG 模型变更会实时反映到 API 接口中。
-
常用查询参数：支持 depth（控制返回子树深度）、dry-run（预览变更）、no-networking（仅修改 CDB）、no-out-of-sync-check（忽略同步校验）等参数，灵活适配不同操作场景。
课程总结与后续学习
-
完成课程后可掌握 NSO 架构描述、基础 CLI 操作、设备管理、服务包创建、RESTCONF API 调用五大核心能力，通过 5 个实操实验可在模拟网络环境中完成完整自动化编排流程。
-
官方推荐访问 Cisco Network Services Orchestrator (NSO) - Network Services Orchestrator - Cisco DevNet 获取 NSO 完整学习资源。
🖍️ 重点速览
🚩 考点重点
-
课程核心实操目标：5 个 hands-on lab 覆盖从首次使用 NSO 到调用 RESTCONF API 的全流程，是课程考核的核心实践内容。
-
配置漂移根因：多来源配置变更导致全网没有单一可信数据源，是传统 NMS 自动化一致性差的根本原因，属于核心概念考点。
-
NSO 6 步标准工作流：启动会话 → 编辑候选配置 → 验证配置 → 提交事务 → 全部成功则全网生效 → 任意失败则全量回滚，是 NSO 事务机制的必考内容。
-
分布式事务原子性：设备管理器并行下发配置，任意设备失败则全网自动回滚，是 NSO 保障配置一致性的核心机制。
-
FASTMAP 算法作用：计算最小必要变更集合，大幅提升配置下发效率，是服务管理器的核心考点。
-
CLI 操作模式与配置模式差异：操作模式用于查看监控，配置模式修改候选配置，提交后才生效，是 CLI 操作的基础考点。
-
设备添加必填属性：逻辑名称、可达性信息、认证组、设备类型+NED 标识、解锁管理状态，是设备上线的必考操作步骤。
-
RESTCONF 核心特性：基于 HTTP、无状态、CRUD 操作、动态适配 YANG 模型，是北向 API 部分的核心考点。
💡 核心概念
-
NSO 网络编排层：位于上层 IT 管理系统与底层网络之间，将全网抽象为单一实体，通过统一 API 实现自动化配置变更，消除直接管理单台设备的需求。
-
CDB 配置数据库：基于 YANG 的事务型内存分层数据库，是 NSO 的单一可信数据源，存储全网设备配置、服务实例、系统运行数据。
-
NED 网络元素驱动：NSO 南向扩展包，内置设备 YANG 模型、原生协议逻辑与转换代码，支持 NETCONF、CLI、SNMP、Generic 四种类型，实现多厂商设备兼容。
-
服务包：NSO 扩展包，包含服务 YANG 模型、XML 配置模板、可选 Java/Python 自定义代码，实现网络服务的抽象化封装与自动化编排。
-
RESTCONF API：基于 HTTP 的无状态北向接口，通过标准 CRUD 方法操作 YANG 定义的数据，推荐使用 XML 作为配置数据编码格式。
✨ 课堂金句
-
"NSO 让你创建和修改服务使用标准化模型，无需耗时的手动编码，实现 massive scalability。"
-
"服务是 NSO 的灵魂，它自动追踪所有配置变更与服务的关联关系，让你再也不用手动维护全网配置的依赖地图。"
-
"你不需要整个团队都精通 YANG 和 XML，核心开发人员掌握即可，其他团队直接消费封装好的服务，把复杂度藏在黑盒子里。"
-
"分布式事务的原子性是 NSO 最强大的特性之一，再也不用担心配置下发一半失败，全网处于不一致的混乱状态。"
📝 待办事项
-
实验任务：完成课程配套的 5 个 hands-on lab，在模拟多路由器网络环境中练习 NSO 全流程操作。
-
阅读参考 ：访问 Cisco Network Services Orchestrator (NSO) - Network Services Orchestrator - Cisco DevNet 学习 NSO 完整官方文档与扩展资源。
-
复习重点：熟练掌握 NSO 6 步工作流、分布式事务回滚机制、服务包开发流程、RESTCONF 请求结构四大核心考点。
-
实操练习：尝试手动添加设备、创建设备组、开发简单 DNS/SNMP 服务包、通过 curl 调用 RESTCONF API 获取设备配置。
🎯 课程总结
📌 Cisco NSO 概述
-
定义：Cisco Network Services Orchestrator (NSO) 是专为解决网络复杂性而设计的统一编排平台，支持Cisco及第三方网络设备、服务和应用的集中管理。
-
核心价值 ：提供厂商无关的南向接口 （支持非NETCONF/RESTCONF设备）和无缝的北向接口（对接NMS、API及操作人员），实现网络基础设施的自动化配置与编排。
-
课程目标：掌握NSO基础架构、功能及操作，包括首次使用NSO、设备 inventory 管理、配置与排障、服务包创建及RESTCONF API应用。
🔍 传统网络管理的挑战
-
设备级管理缺陷 ：传统方法聚焦单设备配置，存在扩展性不足 、配置漂移 和缺乏全局视图等问题。
-
自动化一致性问题：
-
多源变更：NMS、脚本、手动配置等多种变更来源导致配置不一致。
-
缺乏单一事实源：难以追踪网络配置细节及服务依赖关系，增加变更风险。
-
-
现有NMS局限：如Cisco Prime或DNA Center灵活性不足，依赖特定硬件/拓扑，多厂商设备支持有限。
🚀 网络编排层的作用
-
定位：介于企业IT管理系统与网络设备之间的功能层，将网络抽象为单一实体，通过统一协议/API进行可靠操作。
-
核心功能 ：接收上层服务请求，自动转换为多设备配置变更，实现控制器级管理与自动化。
-
NSO定位：作为多厂商网络的控制器级管理平台，通过设备原生协议实现南向定制化自动化，提供北向数据模型驱动接口。
🏗️ Cisco NSO 架构
- 核心组件：
| 组件 | 功能描述 |
|---|---|
| Core Engine | 管理配置数据库(CDB)，处理事务、会话、认证、RBAC及数据复制，进程名为ncs。 |
| Configuration Database (CDB) | 基于YANG模型的内存数据库，存储设备配置、服务实例及系统数据，支持事务回滚。 |
| Device Manager | 将CDB中的配置变更批量下发至物理/虚拟设备，支持原子化网络操作与自动回滚。 |
| Network Element Drivers (NEDs) | 南向驱动包，含设备YANG模型及协议逻辑，支持NETCONF/CLI/SNMP/Generic类型设备。 |
| Service Manager | 通过服务YANG模型抽象设备配置复杂性，将服务参数转换为设备配置。 |
| Package Manager | 管理NSO扩展包（如服务包）的加载、更新与删除。 |
-
北向接口：支持NETCONF、RESTCONF、CLI、WebUI、SNMP及Python/Java API。
-
南向接口：通过NEDs对接多厂商设备，支持并行配置变更。
🔄 NSO配置工作流
-
会话建立：连接NSO，获取网络配置"草稿区"（类似逻辑设备）。
-
配置编辑：在草稿区创建/修改配置（候选配置）。
-
验证：检查配置约束与依赖关系，预览执行结果。
-
提交：通过事务将配置批量下发至设备。
-
成功确认：所有设备接受配置后，更新为全网运行配置。
-
自动回滚：若任一设备失败，NSO自动回滚所有变更至一致状态。
📊 服务编排与映射逻辑
-
服务抽象：通过服务YANG模型定义核心参数（如IPSec VPN的网关IP、子网、密钥），简化配置复杂度。
-
映射逻辑：将服务实例参数转换为设备配置的规则，通过XML模板+可选Python/Java代码实现。
-
FASTMAP算法：计算网络最小变更集，确保服务配置的一致性与增量更新。
⚡ 关键特性总结
-
事务性配置：支持跨设备原子化操作，确保配置一致性。
-
多厂商支持：通过NEDs实现异构网络设备管理。
-
服务自动化：Service Manager简化端到端服务部署。
-
单一事实源：CDB集中存储网络配置与服务状态，消除信息孤岛。
本课程中一共有5个Lab，其中有些实验似乎有些小bug，演示和官方指导步骤如下：
所有LAB的拓扑图和登录用户名密码都是一致的，信息如下：
Lab-1：
Lab-2：
Lab-3：
Lab-4：
bash
admin@ncs(config-dns-snmp-service-InternalNetwork)# commit dry-run
cli {
local-node {
data devices {
device R1 {
config {
ip {
name-server {
+ # first
+ name-server-list 172.21.1.10;
}
}
access-list {
+ access-list 55 {
+ rule "remark SNMP ACCESS";
+ rule "permit 172.21.1.20";
+ }
}
snmp-server {
+ community c0mmun1t7 {
+ RO;
+ access-list-name 55;
+ }
}
}
}
device R2 {
config {
ip {
name-server {
+ # first
+ name-server-list 172.21.1.10;
}
}
access-list {
+ access-list 55 {
+ rule "remark SNMP ACCESS";
+ rule "permit 172.21.1.20";
+ }
}
snmp-server {
+ community c0mmun1t7 {
+ RO;
+ access-list-name 55;
+ }
}
}
}
device R3 {
config {
ip {
name-server {
+ # first
+ name-server-list 172.21.1.10;
}
}
access-list {
+ access-list 55 {
+ rule "remark SNMP ACCESS";
+ rule "permit 172.21.1.20";
+ }
}
snmp-server {
+ community c0mmun1t7 {
+ RO;
+ access-list-name 55;
+ }
}
}
}
}
+dns-snmp-service InternalNetwork {
+ devices [ R1 R2 R3 ];
+ dns-server 172.21.1.10;
+ snmp-server 172.21.1.20;
+}
}
}
bash
admin@ncs(config-dns-snmp-service-InternalNetwork)# commit dry-run
cli {
local-node {
data devices {
device R1 {
config {
snmp-server {
- community c0mmun1t7 {
- RO;
- access-list-name 55;
- }
+ community c0mmunit789 {
+ RO;
+ access-list-name 55;
+ }
}
}
}
device R2 {
config {
snmp-server {
- community c0mmun1t7 {
- RO;
- access-list-name 55;
- }
+ community c0mmunit789 {
+ RO;
+ access-list-name 55;
+ }
}
}
}
device R3 {
config {
snmp-server {
- community c0mmun1t7 {
- RO;
- access-list-name 55;
- }
+ community c0mmunit789 {
+ RO;
+ access-list-name 55;
+ }
}
}
}
}
dns-snmp-service InternalNetwork {
+ community-string c0mmunit789;
}
}
}
admin@ncs(config-dns-snmp-service-InternalNetwork)#
Lab-5:
XML
<dns-snmp-service xmlns="http://cisco.com/examples/dnssnmpservice" xmlns:dns-snmp-service="http://cisco.com/examples/dnssnmpservice">
<name>DMZ</name>
<devices>R3</devices>
<dns-server>10.1.1.10</dns-server>
<snmp-server>10.1.1.20</snmp-server>
</dns-snmp-service>
