在单机配置时代,网络工程师通过命令行直接就搞定了;在网络设备达到数十台、数百台时,而这些设备可能来自不同的厂商时,网络工程师对网络管理的窘境有颇多怨言。作为网络工程师面临的挑战和压力是什么?要维持上万台的设备、数十万的部件和上千条线路。这么多的压力终于在网管的用户体验吐槽大会上爆发,提出了网络管理中的14个问题:
(1).从操作员的角度来看,易用性是任何网络管理技术的关键要求;
(2).必须明确区分配置数据、描述操作状态的数据和统计数据;
(3).需要能够从设备中提取单独的配置数据、操作状态数据和统计数据,并能够在设备之间进行比较;
(4).必须使操作员能够集中于整个网络的配置,而不是逐个设备配置;
(5).支持在多个设备上配置事务,以简化网络配置管理;
(6).假定需要进行配置 a和配置 b,应该能够生成从a到b所需的操作,以便使得状态变化对网络系统产生最小的影响。将配置更改所造成的影响降到最低是很重要的;
(7).备份和恢复配置的机制是操作人员需要的原始操作;
(8).为了在两个配置之间确定变化以及这些配置是否一致,必须很容易地对配置进行一致性检查;
(9).基于文本的配置,如差异化和版本管理工具,如RCS或CVS,可以用来处理配置,这意味着设备不应任意重新排序数据,如访问控制列表;
(10).网络范围的配置通常存储在中央主数据库中,并转换成可被推送到设备的格式,通过生成CLI命令序列或将完整的配置文件推送到设备上。没有共同的数据库模式……尽管各种操作符使用的模型可能非常相似;
(11).区分配置的分布和特定配置的激活是很重要的,设备应该能够容纳多种配置; (12).基于角色的访问控制模型和最小权限原则,其中只能为用户提供执行所需任务所需的最小访问权限;
(13).可以跨设备对访问控制列表进行一致性检查;
(14).SNMP访问控制是面向数据的,而CLI访问控制通常是面向命令(任务)的。 因此,需要支持面向数据和面向任务的访问控制。
为解决上述的问题,历经多年的讨论,最终产生了一系列的标准:
(1).RFC4741- 4744 分别描述了NETCONF在三种不同的传输模式SOAP,BEEP和SSH下是如何工作的。
(2).2008 年7 月推出RFC5277,主要定义了NETCONF的事件通知机制,用于故障管理。
(3).2009 年5 月推出的RFC5539 描述了NETCONF如何保证传输层传输信息的安全机制,加强了NETCONF的安全体系。
(4).2010年,RFC 6020 为NETCONF的YANG建模语言。
(5).2010年,RFC 6021 通用YANG的数据类型。
(6).2011年6月,RFC6241定义NETCONF的安装,操作和删除网络设备配置的机制。RFC6242更新了基于 SSH 的传输模式。NETCONF 协议是完全基于XML 之上的,所有的配置数据和协议消息都用XML 表示。
(7).2011年,RFC6244 使用NETCONF和YANG的网络管理构架。
总的来说,我们重点关注如下几标准:
① RFC6241定义NETCONF的安装,操作和删除网络设备配置的机制。
② RFC6242更新了基于 SSH 的传输模式。NETCONF 协议是完全基于XML 之上的,所有的配置数据和协议消息都用XML 表示。
③ RFC6020指出,YANG是一种数据模型语言(Data Modeling Language),用来描述NETCONF相关的网络配置和网络状态的数据模型、RPC和Notification。
NETCONF协议是网络设备配置的标准协议,用来进行网络设备的配置管理、下发、更改等问题。它划分为4层:安全传输层、消息层、操作层和内容层。如下图所示:
其中,传输层规定传输层必须使用TLS、SSH等带有安全加密的通信协议,其中SSH是当前应用最多的传输层协议;消息层提供 RPC 接口,用于实现远程调用和通知;操作层定义了 edit-config、get-config、delete-config 和 copy-config 等9种操作,用户也可以自定义RPC操作;内容层描述了配置数据和通知数据,但没有标准化数据结构模型,该模型由RFC 6020:YANG建模。YANG的信息存储在NETCONF协议的3个标准概念配置数据库,如下表所示:
类型 | 说明 |
---|---|
Running: 运行配置库 | 目前在设备上运行的生效配置 |
Candidate:备份配置库 | 任何改变都不会马上直接影响网络设备 |
startup初始配置库 | 网络设备启动时所加载的配置库 |
① Client端发起hello消息到Server端并告知对NETCONF的支持能力;
② Server端发起hello消息到Client端并告知对NETCONF的支持能力,完成能力协
商;
③ Client端发起rpc请求消息到Server端,进行设备的配置请求;
元素封装了从客户端到服务器端的协议操作请求。
④ Server端进行操作并将应答消息封装到rpc-reply,回复给Client端。
元素消息是对消息的响应。
![图片](https://mmbiz.qpic.cn/mmbiz_png/prnpGufYiaQLFCAWDk1YTaHzd4Qdb0MeVkiaJVVnCktIpxbNxCTFrDk66eDzAehz51ffDfBkstgGcZyApVAPWMCQ/640?wx_fmt=png&tp=wxpic&wxfrom=5&wx_lazy=1&wx_co=1)
NETCONF配置信息的开发较为简单,即在代码编写“拼接XML字符串,调用rpc接口”的逻辑就可以了,感兴趣的人员可以参考:
https://www.juniper.net/documentation/en_US/junos/topics/task/installation/netconf-java-toolkit-downloading-and-installing.html
NETCONF是网络管理协议,分为安全传输层、消息层、操作层和内容层等4层,而YANG是和NETCONF相伴而生的,可以对操作层和内容层进行建模。但为什么要用YANG呢?我们知道SNMP在请求端使用BER对操作请求和应答进行编码,并在接收端使用BER进行解码。就BER编码(Basic Encoding Rule)来说,其过程是将数据分成TLV三部分并按照TLV的顺序对数据进行编码,生成字节流(T-Tag-类型标识,L-Length-类型的长度,V-Value-数据内容)。在这种情况下,每个字段出现的顺序是预先约定的,其类型和长度是固定的,如果要在新增字段,则意味着协议两端的编解码都要进行修改。而如果将本部分内容通过一个文件来描述或者建模,协议两端根据该文件进行编解码,则与具体的字段解耦了。所以,YANG建模语言就适时而生了(RFC6020:https://tools.ietf.org/html/rfc6020#page-11)。
现在脑补一个场景:需要配置数百上千台设备,并且这些设备来自不同的厂商,那如何实现自动化配置呢?DevOps人员只需做如下步骤:
① 构建自动化配置基础应用程序;
② 加载厂商设备的YANG文件;
③ 使用代码生成工具将YANG文件转化为公共代码模板;
④ 根据业务场景编写RPC和数据逻辑代码;
⑤ 不同厂商重复步骤;
⑥ 部署自动化配置基础应用程序。
经过这些步骤后,你需要做的就是“一键”下发配置,成百上千台设备配置就搞定了。
在现有的网络中,NETCONF和YANG已有了较好的实践。就软件定义网络而言,从OpenDaylight的架构图中,我们可以看到NETCONF即能做北向接口也能做南向接口。同时,不同厂商的控制器也支持NETCONF作为其接口协议。NETCONF作为出色的网络管理协议,将继续发挥其优异的网络配置作用。
全部0条评论
快来发表一下你的评论吧 !