Netconf配置及其RPC和Notification下发流程解析Netconf配置及其RPC和Notification下发流程解析 最近两个⽉⼀直在捣⿎netconf，现在搞得⼩有成效，因此总结⼀番，以便和⼴⼤⽹友进⾏深⼊探
讨。
在github中有两套libnetconf，⼀套是libnetconf，另外⼀套是libnetconf2。libnetconf2是正在开
发中的版本，还未正式发布。这个版本相⽐于libnetconf会有很⼤变化，⽐如说：libnetconf中编
译yang模型是采⽤外部软件pyang进⾏，⽽到了libnetconf2中会把编译⼯具会集成到libnetconf2 中。从个⼈⾓度来说，还是期待libnetconf2。
⼀、Netconf编译与配置
1.1 编译
移植软件的第⼀步就是编译，如果是交叉编译的话，那份痛苦是不⾔⽽喻的。对于我们项⽬来
说，需要移植到powerpc平台上，因此很多库都需要⾃⼰编译出来（编译libnetconf花了⼀天
半）。这⾥把⼀些必需依赖库编译⽅法以及编译过程中遇到的错误，展⽰出来，免得⼤家多⾛弯
路。
Linux编译三步骤：configure，make，make install。如果不熟悉linux编译的请⾃学。
1.2 设置环境变量
为了编译⽅便，设置⼀下环境变量（其实也可不设置）即设置⼯具链所在位置，具体设置如下：
将这两个⽬录设置到PATH中，避免不必要的错误：
1.3 编译依赖库
由于依赖库⾮常多并且不同的编译环境，编译情况也不尽相同，这⾥只把常见依赖库和编译有困
难的库，给⼤家展⽰出来。
1、libxml2编译
1）configure 创建makefile婆梅氏比重计
2）make 编译最后单元测试编译失败，对于我们使⽤者来说没有影响，因为库⽂件已经⽣成。
四川移动李华
3）make install 安装到指定⽬录中，在上⾯configure过程中已经设置为当前⽬录下
build_install。将编译⽣成的lib和include这两个⽬录，拷贝到⼯具链中。
2、libssh编译
在编译libssh的时候需要编译libz、openssl依赖库，这两个⽐较容易编译出来，因此不再阐述。
Libssh采⽤cmake⽅式编译：
1）修改ake⽂件，打开静态库编译选项，如果不需要静态库则可以忽律此步骤
2）创建mkdir build_install保存编译⽣成的⽂件，进⼊此⽬录执⾏cmake命令，此步骤实则是⽣
成makefile过程，如下图所⽰：
进⼊该⽬录中，然后输⼊cmake .. (此处有两点，即上层⽬录)
3）执⾏make操作，进⾏编译，编译完后如下图所⽰：
4）将include、静态库和动态库拷贝到⼯具链中即可。
常见两种编译⽅式都已介绍，后⾯在编译其他依赖库，基本上都是⼀样的套路。
3、编译libgpg-error
1）这个编译没有任何问题，我们需要把编译⽣成的可执⾏⽂件如gpg-error、gpg-error-cofig拷贝
到⼯具链中，并且以powerpc-603-linux-gun-进⾏重命名。
2）拷贝头⽂件和库到对应的⼯具链中。
4、编译libgcrgpt
编译libgcrgpt时候，如果连接过程中出现错误，⽐如说不到某个函数，原因是在编译过程进⾏了优化，将原始函数定义修改为以下划线开始。此问题修改是configure过程中，增加⼀个参数：—disabled-asm。
5、编译libnetconf
将上⾯⼀些依赖库和其他库都编译完后，再编译libnetconf就⾮常容易了。
1） ./configure --host=powerpc-603-linux-gnu --build=i686-pc-linux-gnu --
prefix=pwd/build_install
2）make
3）make install
这三步⾮常的顺利没有出现任何错误。
6、编译netopeer
Netopeer是libnetconf官⽅提供server，cli以及编译⼯具lnctool。在编译netopeer时候遇到了⽆法解析yang⽂件问题，此处解决的⽅法，升级python并安装pyang。
1.4 ⼯具lnctool
假设经过第⼀步后成功编译出libnetconf和netopeer，这样我们就可以直接运⾏netopeer。netconf默认监听端⼝是830端⼝。
众所周知，netconf协议⽀持⾃定义rpc，因此此步骤需要做的是如何在现有netconf中增加⾃⼰的yang
模型以及执⾏⾃⼰的rpc？？这⾥就需要⽤到这个⼯lnctool。这个⼯具是⽤python实现的，⾥⾯代码也⽐较简单，⽐如说调⽤其他应⽤程序（pyang）或者直接写⽂件。
当我们把rpc函数实现之后，就可以通过另外⼀个⼯具，netopeer-manager安装⾃定义模型，使⽤命令⾏如下：
Java 1
netopeer
-
manager
add
--
name
[
module
纯策略纳什均衡name
]
--
model
[
model
path
]
--
transapi
[
model
share
library
]
--
datastore
[
module
datastore
file
]
如下图所⽰，当然我们也可以不使⽤netopeer-manager，直接修改配置⽂件，下⾯章节我将会介绍。
1.5 修改配置⽂件
【libnetconf之Streams】
众所周知，netconf之前rpc、notification两种操作，其中notification类似server主动发送消息，然⽽它不是简单的主动发送，⽽是⽀持订阅操作。Libnetconf就是通过stream实现 notification（stream其实就是⼀个普通⽂件）。
Streams默认存放路径/var/lib/libnetconf/streams。这个⽬录中⼀般有两个配置⽂
件，NETCONF.event：这个⽂件事件接收者，也就是stream对象。业务层只需要把事件写⼊到这个⽂件中，那么所有的订阅者就能够都接收到这个事件。这个⽂件在后⾯notification篇会详细介绍。
NETCONF.rules：这个⽂件⽬前总是空的。
【netopeer配置⽂件】
Netopeer是官⽅发布的⼀个服务端，但从个⼈⾓度认为这个server写的不是很好，有些内容很凌乱。如果有时间⽇后会重写这个server。
Netopeer默认安装路径是/usr/local/etc/netopeer或者/etc/netopeer/，在这个⽬录中有两个⼦⽬录分别为cfgnetopeer，f.d。
1、cfgnetopeer
这个⽬录是netopeer相关配置，⽂件虽然很多，但是我们只需要关注l⽂件即可。l主要包含三部分（三个datastore）：
说⼀下备选配置：备选配置是即将⽣效的配置，换句话说，⽤户下发的配置⼀般都会保存在备选配置中，等待时机（等待commit消息），将备选配置保存到running中。注：netopeer中实现的datastore是最简单的⽅式，以⽂件⽅式存储配置。对于这种⽅式，性能是最低的，对于⼀些性能要求较⾼的项⽬，请考虑⼀下这个地⽅的⾏问题！！提⽰：这个地⽅datastore可以采⽤数据库，如使⽤no-sql型数据库。
2、f.d
模型配置保存的⽬录，这个⽬录存储的是模型相关配置。⼀说到模型就感觉有点抽象，那好我⽤⼤⽩
话说⼀下：这个⽬录保存的就是yang⽂件定义的module，这次够直⽩了吧
依赖模型：为了实现主模型，往往需要其他模型作为辅助。依赖模型在yang⽂件中的体现是通过import关键字导⼊的。
主模型：yang⽂件中定义的module就是主模型。依赖模型可以有多个，但是主模型只能有⼀个。
Datastore：⽤于存储配置，可以是⽂件，也可以其他任何存储介质。如果在datastore是⼀个⽂件，那么不⽤⼿动创建，netopeer在启动的时候会创建的。
⼩结：在上⾯讲过使⽤netopeer-manager添加新增模型，就是修改或者创建上⾯配置⽂件。因此我们完全可以不使⽤netopeer-manager这个⼯具。
⼆、RPC和Notification下发流程解析
Libnetconf代码⾃⼰只把rpc、notification流程详细看过，像⼀些netconf-session维护，hello消息等没有仔细看。像之前我说过的，libnetconf有些代码⾮常长且source insight⽆法写解析出来，所以有些代码⽚段可能⽐较突兀，请谅解。
2.1 总体流程图
图1：总体流程图
上图是只是最简易流程图，但已经能够描述清楚。如果有⼈⽐较清楚netconf协议，会有⼀些疑问，为什么上图中没有包含hello流程？？难道是在Others⾥⾯吗？？其实不是，在进⼊这个流程之前，hello消息已经处理过了，也就是说进⼊这个流程时netconf-session已经建⽴成功（create_netconf_session处理）。
消息分类：
消息close-session：优雅终⽌netconf-session。
消息kill-session：强制终⽌netconf-session并且释放相关资源。
消息 create-subscription：订阅消息，此消息会在下⼀篇notification中介绍的。
前两种消息类似，都可以达到终⽌会话功能，具体差别可以先阅读以下netconf相关协议以及netopeer中代码。我们分析的重点在othes消息中。
2.2 rpc处理流程
下⾯流程图是ncds_apply_rpc2call函数处理流程。
图2：rpc处理流程图
注：这个函数代码⾏数⾮常多，source insight⽆法正常解析。在这⾥我会分析两个分⽀流程，⼀个edit-config，⼀个unkown。这两个有什么区别呢？？edit-config是协议标准规定的rpc，⽽unkown是⾃定义rpc处理。由于各个⼚商需求不同，可能有的⼚商定义并实现了⾃定义rpc，有的⼚商可能就没有⾃定义，但⾃定义rpc完全可以不出现。
1、edit-config配置流程
图3：代码⽚段1
开始的⼏⾏代码，是从rpc结构中获取相应参数，这个没有什么可解释的。
下⾯的if判断是对edit-config表现形式区分的。Edit-config有两种表现形式，常见表现形式是所有配置项都在edit-config中体现，这种也是标准edit-config，如图4：
图4：标准edit-config格式
另外⼀种edit-config是以url表现的，这种表现形式在协议中也没有样例，具体是什么样⼦，我也不太清楚。
这⾥分析⼀下edit-config处理流程，代码如下：
Java 1
ret
=
ds
->
func
.
editconfig
(
ds
,
session
,
rpc
,
target_ds
,
config
,
nc_rpc_get_defop
(
螺旋槽丝锥rpc
)
,
nc_rpc_get_erropt
(
rpc
)
,
&
e
)
;
这⾥是⼀个回调函数，如果datastore的表现形式是file，则此处的回调函数是：
ncds_file_editconfig。对于这个函数，开始⼀部分是进⾏常规校验，函数处理流程图如下：
补充说明⼀下：
1）file_rollback_store是为了回滚，⾥⾯机制是备份当前datastore全部配置。如果出现错误，并且在下发rpc的时候，下发了rollback-on-error标志，才会进⾏回滚。
2）compact_edit_operations 主要根据下发内容进⾏合并处理。
中国人民解放军军事学院3） edit_operations 下发rpc的时候往往下发操作类型，如果没有下发，默认是replace。操作类型⼀共有replace，create，delete，remove，merge五种。根据操作类型不同，修改对应的datastore。
2、⾃定义rpc处理流程
对于⾃定义的rpc来说，⽐较简单。在上⾯也说过了，⾃定义rpc处理流程是Unkown分⽀中进⾏处理，具体代码如下：
这个回调函数实现在什么地⽅呢？？其实就在我们编译yang模型时候⽣成的.c⽂件中。这个地⽅需要
注意：回调函数中必须返回rpc_reply消息，否则libnetconf会⾃⼰构造⼀个rpc_error消息返回给客户端。
上⾯是rpc整个流程，代码分析不多，⼤部分都是流程图，其实只需要把流程搞通，⾄于代码熟悉度，只是时间问题。上⾯分析的只是rpc消息中edit-config消息，其他消息⽐较简单，需要⾃⼰去看⼀下。下⾯分析⼀下notification消息。
2.3 notification处理流程
在介绍notification之前，先普及⼀下netconf协议⼀点点基础知识。
1）若想实现notification通知消息，客户端必须下发rpc订阅消息即create-subscription
2）在下发订阅消息时候如果参数中没有stream则默认stream是NETCONF。个⼈理解stream是隧道、通道含义。⽤户可以订阅某个隧道下⾯某些事件。事件上报时，流经哪个隧道，这完全取决于业务模块。
3）Netconf协议规定，⼀个netconf-session有且只有⼀个订阅，并且订阅消息⼀旦创建就不允许修改。
4）订阅消息⽀持结束时间stopTime参数，如果没有此参数则订阅功能与netconf-session是具有相同的⽣命周期。
免疫组化技术Netopeer-server中实现rpc订阅消息代码如下，代码⽐较简单，就是创建⼀个线程监听stream对象。
轮询具体实现函数是ncntf_dispatch_send，这个函数是⼀个死循环。但是从命名上来看，感觉不像死循环（所以我吐槽libnetconf代码不友好）。下⾯ncntf_dispatch_send函数具体处理流程：
创建notification事件，可以有以下接⼝，
事件是xml节点⽅式作为⼊参：
Java
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议