SDSM结束了，但无法控制的写作欲望依然存在。

多年来，我们的兄弟一直在做例行公事，在上班前交叉手指，并且由于夜间回滚而缺乏睡眠。
但黑暗时代即将结束。

通过这篇文章，我将开始一系列关于如何 我 可见自动化。
在此过程中，我们将了解自动化、存储变量、形式化设计、RestAPI、NETCONF、YANG、YDK 的各个阶段，并且我们将进行大量编程。
我 意味着a）它不是一个客观事实，b）它不是无条件的最佳方法，c）我的观点，即使在从第一篇文章到最后一篇文章的过程中，也可以改变 - 说实话，从草案阶段到出版后，我将所有内容完全重写了两次。

内容

1. 目标
   1. 网络就像一个单一的有机体
   2. 配置测试
   3. 版本控制
   4. 服务的监控和自我修复

2. 资金
   1. 库存系统
   2. IP空间管理系统
   3. 网络服务描述系统
   4. 设备初始化机制
   5. 与供应商无关的配置模型
   6. 供应商特定的驱动程序接口
   7. 向设备下发配置的机制
   8. CI / CD
   9. 备份和搜索偏差的机制
   10. 监视系统

3. 结论

我将尝试以与 SDSM 略有不同的格式进行 ADSM。 大型、详细、编号的文章将继续出现，在它们之间我将发表日常经验的小笔记。 我会在这里努力与完美主义作斗争，而不是舔他们每一个人。

多么有趣的是，第二次你还要走同样的路。

起初我不得不自己写一些关于网络的文章，因为它们不在 RuNet 上。

现在我找不到一个全面的文档来系统化自动化方法并使用简单的实际示例来分析上述技术。

我可能是错的，所以请提供有用资源的链接。 不过，这不会改变我写作的决心，因为主要目标是自己学习一些东西，让别人的生活更轻松是一个令人愉快的奖励，抚摸着分享经验的基因。

我们会尝试以一个中型LAN DC数据中心为例，制定整个自动化方案。
我几乎是第一次和你一起做一些事情。

我不会在此处描述的想法和工具中具有原创性。 德米特里·菲戈尔有着出色的表现 有关此主题的频道.
这些文章在很多方面都会与它们重叠。

LAN DC 有 4 个 DC、大约 250 个交换机、六台路由器和几个防火墙。
不是 Facebook，但足以让你深入思考自动化。
然而，有一种观点认为，如果您拥有超过 1 台设备，则已经需要自动化。
事实上，很难想象现在任何人都可以在没有至少一套膝盖脚本的情况下生活。
虽然我听说有些办公室的IP地址保存在Excel中，并且成千上万的网络设备中的每一个都是手动配置的，并且都有自己独特的配置。 这当然可以被冒充为现代艺术，但工程师的感情肯定会受到冒犯。

目标

现在我们将设定最抽象的目标：

• 网络就像一个单一的有机体
• 配置测试
• 网络状态版本控制
• 服务的监控和自我修复

在本文后面，我们将讨论我们将使用什么手段，在下文中，我们将详细介绍目标和手段。

网络就像一个单一的有机体

该系列的定义短语，尽管乍一看似乎并不那么重要： 我们将配置网络，而不是单个设备.
近年来，我们看到重点转向将网络视为单个实体，因此 软件定义的网络, 意图驱动网络 и 自治网络.
毕竟，应用程序在全局范围内需要网络提供什么：A 点和 B 点（有时是 +B-Z）之间的连接以及与其他应用程序和用户的隔离。

所以我们这个系列的任务是 建立一个系统，维持当前配置 全网，它已经根据其角色和位置分解为每个设备上的实际配置。
系统 网络管理意味着要进行更改，我们需要联系它，而它反过来会计算每个设备的所需状态并对其进行配置。
通过这种方式，我们将对 CLI 的手动访问减少到几乎为零 - 设备设置或网络设计的任何更改都必须正式化和记录 - 然后才推广到必要的网络元素。

也就是说，例如，如果我们决定从现在开始喀山的机架交换机应该宣布两个网络而不是一个，我们

1. 首先我们记录系统的变化
2. 生成所有网络设备的目标配置
3. 我们启动网络配置更新程序，该程序计算每个节点上需要删除的内容、添加的内容，并使节点达到所需的状态。

同时，我们只在第一步手动进行更改。

配置测试

已知80% 的问题发生在配置更改期间 - 间接证据是新年假期期间一切通常都很平静。
我亲眼目睹了数十起因人为错误导致的全球宕机：错误的命令、在错误的分支执行配置、社区忘记、MPLS在路由器上被全局拆除、配置了五块硬件，但错误却没有第六天注意到，另一个人所做的旧更改被进行了。 有很多场景。

自动化将使我们能够减少犯错误，但犯的错误规模会更大。 通过这种方式，您不仅可以对一台设备进行砖块化，还可以一次对整个网络进行砖块化。

从远古时代起，我们的祖父们就用敏锐的眼睛、钢球和网络推出后的功能来检查所做的更改的正确性。
那些因工作导致停机和灾难性损失的祖父留下的后代更少，并且应该随着时间的推移而灭绝，但进化是一个缓慢的过程，因此并不是每个人都首先在实验室中测试变化。
然而，处于进步前沿的是那些自动化测试配置及其在网络中的进一步应用的过程的人。 换句话说，我借用了 CI/CD 程序（持续集成、持续部署）来自开发商。
在其中一个部分中，我们将研究如何使用版本控制系统（可能是 Github）来实现这一点。

一旦你习惯了网络 CI/CD 的想法，一夜之间，通过将配置应用于生产网络来检查配置的方法就会显得像是中世纪早期的无知。 有点像用锤子敲击弹头。

理念的有机延续 系统 网络管理和 CI/CD 成为配置的完整版本。

版本控制

我们假设，随着任何变化，即使是最微小的变化，即使是在一台不引人注目的设备上，整个网络也会从一种状态转变为另一种状态。
我们总是不在设备上执行命令，而是更改网络状态。
那么我们称这些状态为版本吗？

假设当前版本是 1.0.0。
其中一台 ToR 上的 Loopback 接口的 IP 地址是否已更改？ 这是一个次要版本，编号为 1.0.1。
我们修改了将路由导入 BGP 的策略 - 更认真一点 - 已经是 1.1.0
我们决定摆脱 IGP 并仅改用 BGP - 这已经是一个根本性的设计变更 - 2.0.0。

同时，不同的DC可能有不同的版本——网络正在开发，新设备正在安装，新级别的主干正在某处添加，而不是在其他地方添加，等等。

Про 语义版本控制 我们将在另一篇文章中讨论它。

我重复一遍 - 任何更改（调试命令除外）都是版本更新。 必须通知管理员与当前版本的任何偏差。

这同样适用于回滚更改 - 这不是取消最后的命令，这不是使用设备操作系统的回滚 - 这是将整个网络带到新（旧）版本。

服务的监控和自我修复

这个不言而喻的任务在现代网络中已经达到了一个新的水平。
通常，大型服务提供商采取的方法是需要快速修复失败的服务并提出新的服务，而不是弄清楚发生了什么。
“非常”意味着你需要在各个方面进行大量的监控，几秒钟之内就能检测到与标准最轻微的偏差。
在这里，通常的指标，例如接口加载或节点可用性，已经不够了。 由值班人员进行手动监控也是不够的。
对于很多事情来说应该有 自我修复 ——监控灯变红了，我们自己去把车前草涂在受伤的地方。

而且这里我们监控的不仅仅是单个设备，还有整个网络的健康状况，既有相对容易理解的白盒，也有比较复杂的黑盒。

实施如此雄心勃勃的计划我们需要什么？

• 拥有网络上所有设备及其位置、角色、型号、软件版本的列表。
  kazan-leaf-1.lmu.net，喀山，叶，瞻博网络 QFX 5120，R18.3。
• 拥有一个描述网络服务的系统。
  IGP、BGP、L2/3VPN、策略、ACL、NTP、SSH。
• 能够初始化设备。
  主机名、管理 IP、管理路由、用户、RSA 密钥、LLDP、NETCONF
• 配置设备并将配置设置为所需的（包括旧的）版本。
• 测试配置
• 定期检查所有设备的状态是否与当前状态有偏差，并向相关人员报告。
  一夜之间，有人悄悄给ACL添加了一条规则.
• 监控性能。

资金

听起来很复杂，需要开始将项目分解为组件。

其中将有十个：

1. 库存系统
2. IP空间管理系统
3. 网络服务描述系统
4. 设备初始化机制
5. 与供应商无关的配置模型
6. 供应商特定的驱动程序接口
7. 向设备下发配置的机制
8. CI / CD
9. 备份和搜索偏差的机制
10. 监视系统

顺便说一句，这是对周期目标的看法如何改变的一个例子——草案中有 4 个组成部分。

在插图中，我描绘了所有组件和设备本身。
相交的组件相互作用。
块越大，这个组件就越需要关注。

组件一：库存系统

显然，我们想知道什么设备位于何处，连接到什么。
库存系统是任何企业不可或缺的一部分。
大多数情况下，企业有一个单独的网络设备库存系统，可以解决更具体的问题。
作为本系列文章的一部分，我们将其称为 DCIM——数据中心基础设施管理。 尽管 DCIM 一词本身严格来说包含更多内容。

出于我们的目的，我们将在其中存储有关设备的以下信息：

• 库存编号
• 标题描述
• 模型 （华为CE12800、Juniper QFX5120等)
• 特性参数（板卡、接口等)
• 角色 （Leaf、Spine、边界路由器等)
• 地点 （地区、城市、数据中心、机架、单位)
• 设备之间的互连
• 网络拓扑结构

很明显，我们自己想知道这一切。
但这对自动化有帮助吗？
当然可以。
例如，我们知道在Leaf交换机上的给定数据中心中，如果是华为，则应在VLAN上应用过滤某些流量的ACL，如果是Juniper，则应在物理接口的单元0上应用。
或者您需要在该区域的所有边界部署新的 Syslog 服务器。

我们将在其中存储虚拟网络设备，例如虚拟路由器或根反射器。 我们可以添加 DNS 服务器、NTP、Syslog 以及以某种方式与网络相关的所有内容。

组件2：IP空间管理系统

是的，现在有一些团队在 Excel 文件中跟踪前缀和 IP 地址。 但现代方法仍然是数据库，带有 nginx/apache 前端、API 和用于记录 IP 地址和划分为 VRF 的网络的广泛功能。
IPAM - IP 地址管理。

出于我们的目的，我们将在其中存储以下信息：

• VLAN
• VRF
• 网络/子网
• IP地址
• 将地址绑定到设备、将网络绑定到位置和 VLAN 编号

同样，很明显，我们希望确保当我们为 ToR 环回分配新的 IP 地址时，我们不会发现它已经分配给某人了。 或者我们在网络的不同端使用相同的前缀两次。
但这对自动化有何帮助？
容易。
我们在具有 Loopbacks 角色的系统中请求一个前缀，其中包含可用于分配的 IP 地址 - 如果找到，我们分配该地址，如果没有，我们请求创建一个新的前缀。
或者在创建设备配置时，我们可以从同一系统中找出接口应位于哪个 VRF 中。
当启动新服务器时，脚本会登录系统，找出服务器所在的交换机、分配给该接口的端口和子网 - 并从中分配服务器地址。

这表明希望将 DCIM 和 IPAM 合并到一个系统中，以免功能重复，也不会为两个相似的实体提供服务。
这就是我们要做的。

组件 3. 描述网络服务的系统

如果前两个系统存储仍需要以某种方式使用的变量，则第三个系统描述了每个设备角色应如何配置。
值得区分两种不同类型的网络服务：

• 基础设施
• 客户。

前者旨在提供基本连接和设备控制。 其中包括 VTY、SNMP、NTP、Syslog、AAA、路由协议、CoPP 等。
后者为客户端组织服务：MPLS L2/L3VPN、GRE、VXLAN、VLAN、L2TP等。
当然，也有一些边界情况——哪里包含MPLS LDP、BGP？ 是的，路由协议可用于客户端。 但这并不重要。

两种类型的服务都分解为配置原语：

• 物理和逻辑接口（tag/anteg、mtu）
• IP 地址和 VRF（IP、IPv6、VRF）
• ACL和流量处理策略
• 协议（IGP、BGP、MPLS）
• 路由策略（前缀列表、社区、ASN 过滤器）。
• 实用服务（SSH、NTP、LLDP、Syslog...）
• 等等。

我们具体要如何做到这一点，我还不知道。 我们将在另一篇文章中对此进行研究。

如果贴近生活一点的话，我们可以这样描述
Leaf 交换机必须与所有连接的 Spine 交换机建立 BGP 会话，将连接的网络导入到进程中，并且仅接受来自 Spine 交换机的来自特定前缀的网络。 将 CoPP IPv6 ND 限制为 10 pps 等。
反过来，脊椎与所有连接的线索举行会话，充当根反射器，并只接受来自它们的特定长度和特定社区的路线。

组件4：设备初始化机制

在这个标题下，我结合了许多必须发生的操作，以便设备出现在雷达上并被远程访问。

1. 在库存系统中输入设备。
2. 选择管理IP地址。
3. 设置对其的基本访问权限：
   主机名、管理 IP 地址、管理网络路由、用户、SSH 密钥、协议 - telnet/SSH/NETCONF

有以下三种方法：

• 一切都是完全手动的。 该设备被带到展台上，普通人员将其输入系统，连接到控制台并进行配置。 可以在小型静态网络上工作。
• ZTP - 零接触配置。 硬件到达、启动、通过 DHCP 接收地址、转到特殊服务器并自行配置。
• 控制台服务器的基础设施，其中初始配置通过控制台端口以自动模式进行。

我们将在另一篇文章中讨论这三个问题。

组件 5：与供应商无关的配置模型

到目前为止，所有系统都是不同的补丁，提供变量以及我们希望在网络上看到的内容的声明性描述。 但迟早，你将不得不处理具体细节。
在此阶段，对于每个特定设备，原语、服务和变量被组合成一个配置模型，该模型仅以供应商中立的方式实际描述特定设备的完整配置。
这一步有什么作用呢？ 为什么不立即创建一个可以简单上传的设备配置？
事实上，这解决了三个问题：

1. 不要适应特定的接口来与设备交互。 无论是 CLI、NETCONF、RESTCONF、SNMP，模型都是相同的。
2. 不要根据网络上供应商的数量来保留模板/脚本的数量，如果设计发生变化，请在多个地方更改相同的内容。
3. 从设备（备份）加载配置，将其放入完全相同的模型中，然后直接将目标配置与现有配置进行比较，以计算增量并准备一个配置补丁，该补丁将仅更改那些必要的部分或识别偏差。

此阶段的结果是，我们获得了独立于供应商的配置。

组件 6. 供应商特定的驱动程序接口

您不应该沾沾自喜地希望有一天能够以与 Juniper 完全相同的方式配置 ciska，只需向它们发送完全相同的调用即可。 尽管白盒越来越流行，并且出现了对NETCONF、RESTCONF、OpenConfig的支持，但这些协议提供的具体内容因供应商而异，这是他们不会轻易放弃的竞争差异之一。
这与 OpenContrail 和 OpenStack 大致相同，它们以 RestAPI 作为其 NorthBound 接口，期望完全不同的调用。

因此，在第五步中，独立于供应商的模型必须采用进入硬件的形式。
这里所有的方法都是好的（不是）：CLI、NETCONF、RESTCONF、SNMP。

因此，我们需要一个驱动程序，将上一步的结果转换为特定供应商所需的格式：一组 CLI 命令、一个 XML 结构。

组件7.向设备下发配置的机制

我们已经生成了配置，但仍然需要将其交付给设备 - 显然，不是手工交付。
首先，我们面临着我们将使用什么交通工具的问题？ 今天的选择不再小：

• CLI（远程登录、SSH）
• SNMP
• 网络会议
• 休息会议
• REST API
• OpenFlow（尽管它是一个异常值，因为它是传递 FIB 的一种方式，而不是设置）

让我们在这里点 t。 CLI 是遗留的。 SNMP...咳咳。
RESTCONF 仍然是一种未知的动物；几乎没有人支持 REST API。 因此，本系列我们将重点关注NETCONF。

事实上，正如读者已经理解的那样，此时我们已经决定了接口 - 上一步的结果已经以所选接口的格式呈现。

其次，我们将使用什么工具来做到这一点？
这里还有一个很大的选择：

• 自写脚本或平台。 让我们用 ncclient 和 asyncIO 武装自己，然后自己做所有事情。 从头开始构建一个部署系统需要花费多少成本？
• Ansible 拥有丰富的网络模块库。
• 盐与网络和凝固汽油弹的联系微薄。
• 实际上是凝固汽油弹，它认识几个供应商，仅此而已，再见。
• 诺尼尔是我们将来要解剖的另一种动物。

这里尚未选择最喜欢的 - 我们将进行搜索。

这里还有什么重要的呢？ 应用配置的后果。
成功与否。 是否仍然可以访问硬件？
看来提交将有助于确认和验证下载到设备的内容。
这与 NETCONF 的正确实现相结合，显着缩小了合适设备的范围 - 没有多少制造商支持正常提交。 但这只是其中的先决条件之一 RFP。 最终，没有人担心没有一家俄罗斯厂商会遵守32*100GE接口条件。 还是他担心？

组件 8. CI/CD

至此，我们已经准备好所有网络设备的配置。
我写“适用于一切”是因为我们正在讨论网络状态的版本控制。 即使您只需要更改一台交换机的设置，也会计算整个网络的更改。 显然，对于大多数节点来说它们可以为零。

但是，正如上面已经说过的，我们并不是想要将所有东西直接投入生产的野蛮人。
生成的配置首先要经过Pipeline CI/CD。

CI/CD 代表持续集成、持续部署。 在这种方法中，团队不仅每六个月推出一个新的主要版本，完全取代旧版本，而且定期以小部分增量实现（部署）新功能，每个功能都经过兼容性、安全性和兼容性方面的全面测试。性能（集成）。

为此，我们有一个监视配置更改的版本控制系统，一个检查客户端服务是否损坏的实验室，一个检查这一事实的监视系统，最后一步是将更改推广到生产网络。

除了调试命令之外，网络上的所有更改绝对必须经过 CI/CD Pipeline - 这是我们平静的生活和长久、幸福的职业的保证。

组件 9. 备份和异常检测系统

好了，备份的事就不用再谈了。
我们只需将它们添加到顶部或在 git 中更改配置即可。

但第二部分更有趣——有人应该关注这些备份。 在某些情况下，这个人必须去扭转一切，而在其他情况下，必须向某人发出喵喵声，告诉某人出了什么问题。
例如，如果出现了未在变量中注册的新用户，您需要将其从黑客中删除。 而如果最好不要碰新的防火墙规则，也许有人刚刚打开了调试，或者也许新服务，一个笨蛋，没有按照规定注册，但人们已经加入了。

尽管有自动化系统和钢铁般的管理之手，但我们仍然无法逃脱整个网络规模的一些小三角洲。 为了调试问题，无论如何没有人会向系统添加配置。 而且，它们甚至可能不包含在配置模型中。

例如，用于计算每个特定 IP 的数据包数量以定位问题的防火墙规则是完全普通的临时配置。

组件 10. 监控系统

起初我不打算讨论监控这个话题——它仍然是一个浩繁、有争议且复杂的话题。 但随着事情的进展，事实证明这是自动化不可或缺的一部分。 即使没有练习，也不可能绕过它。

不断发展的思想是 CI/CD 过程的有机组成部分。 将配置部署到网络后，我们需要能够确定现在是否一切正常。
我们谈论的不仅仅是接口使用计划或节点可用性，而是更多微妙的事情 - 必要路由的存在、路由属性、BGP 会话数量、OSPF 邻居、端到端性能的叠加服务。
到外部服务器的系统日志是否停止添加，或者 SFlow 代理是否崩溃，或者队列中的丢弃数是否开始增长，或者某些前缀对之间的连接是否中断？

我们将在另一篇文章中对此进行反思。

结论

作为基础，我选择了一种现代数据中心网络设计 - 以 BGP 作为路由协议的 L3 Clos Fabric。
这次我们将在Juniper上构建网络，因为现在JunOs接口是vanlove。

让我们只使用开源工具和多供应商网络来让我们的生活变得更加困难 - 所以除了瞻博网络之外，我还会选择一个更幸运的人。

即将出版的出版物的计划是这样的：
首先我要谈谈虚拟网络。 首先是因为我想，其次是因为没有这个，基础设施网络的设计就不会很清晰。
然后是网络设计本身：拓扑、路由、策略。
让我们组装一个实验室支架。
让我们考虑一下，也许练习一下在网络上初始化设备。
然后详细介绍每个组件。

是的，我不承诺用现成的解决方案优雅地结束这个周期。 🙂

有用的链接

• 在深入研究该系列之前，值得阅读 Natasha Samoilenko 的书 网络工程师的Python。 也许会通过 课程.
• 阅读也会很有用 RFC 关于 Peter Lapukhov 的 Facebook 数据中心工厂设计。
• 架构文档将让您了解 Overlay SDN 的工作原理。 钨丝布 （以前称为开放轨迹）。

谢谢

罗马峡谷。 用于评论和编辑。
阿尔乔姆·切尔诺贝伊。 对于KDPV。

来源： habr.com