zz:NETCONF協議詳解

隨著SDN的大熱，一個誕生了十年之久的協議煥發了第二春，它就是Netconf協議。如果你在兩年前去搜索Netconf協議，基本得到的信息都是“這個協議是一個網管協議，主要目的是彌補SNMP協議的不足，希望可以取代SNMP協議”。SNMP有哪些不足，而NETCONF是否真的能夠彌補，這都不是重點，重點是NETCONF誕生至今SNMP依舊活的好好的。所以如果我們還是把NETCONF當做一個網管協議的話，估計它會在冷板凳上一直坐下去，而如果我們換一個角度去看待NETCONF協議，你會發現也許它是最適合SDN的一個協議。

0. 概述

NETCONF = The?Network?Configuration Protocol

SDN = Software Define?Network

從文字含義上就覺得NETCONF和SDN可以在一起搞事情，搞什么事情？ 搞Network啊。

SDN要用軟件去定義網絡，如何定義？簡單就是要用軟件去配置網絡，有人說”配置網絡太空泛了，能不能具體點？”，但我真的沒法說的具體，因為網絡能配置的東西太多了，網絡的設備類型多種多樣，業務類型更是成百上千了，但SDN就是想在這么復雜的網絡上開辟一番新的天地，NETCONF可以說是其不二的選擇。

接下來就對NETCONF1.1(RFC6241)版本進行詳細分析。

1. NETCONF1.1協議詳解

NETCONF采用的是C/S的模式：

從上圖中可以看出NETCONF協議內部分為4層，由下至上分別是安全傳輸層，消息層，操作層和內容層。

在詳細介紹這四層之前，需要提前建立一個概念，NETCONF認為網絡的模型數據可以分為兩大類，即狀態數據和配置數據。狀態數據一般指server（設備）的固有屬性數據和當前運行的狀態數據等，這類數據僅能查詢。而配置數據則是指由用戶（以某種方式）配置到server上的數據。而配置數據本身又可以存在多個數據庫，標準中提到了庫用于保存當前已經生效的配置；用于保存可以提交為生效的數據；以及用于保存啟動時的配置數據。

1.1. 安全傳輸層

NETCONF的第一大優勢就是其從協議層面就已經規定其傳輸層必須使用帶有安全加密的通信協議，例如SSH，TLS等。相比與其它也允許明文傳輸的協議來說其在協議層面就已經對數據安全做了第一道守護。由于NETCONF協議規定必須要支持SSH，所以目前SSH是NETCONF使用最廣泛的傳輸層協議。

NETCONF的協議內容是承載在安全傳輸層之上的，所以NETCONF本身是一個應用層協議，所以NETCONF協議中并沒有規定建鏈和保活相關的內容。

1.2. 消息層

NETCONF中定義了三種消息類型，分別是hello， rpc和rpc-reply, notification。

1.2.1.

僅用于回話剛剛建立時netconf-server和netconf-client之間進行能力交換。

server和client需要在回話建立后互相發送消息，并在消息中攜帶自身支持的能力，以及支持的netconf協議的版本號，server和client根據自身和對方的能力信息協商使用的netconf版本。

一般來說，C/S雙方互發且協商版本成功后，認為netconf會話建立成功。

(1) XPath Capability

該能力表示client可以在filter中使用XPath表達式作為過濾條件

Capability Identifier:

urn:ietf:params:netconf:capability:xpath:1.0

(2) Writable-Running Capability

該能力表示server支持直接對庫進行修改操作。

Capability Identifier:

urn:ietf:params:netconf:capability:writable-running:1.0

(3) Candidate Configuration Capability

該能力表示server具有一個candidate數據庫，并且可以將candidate數據庫中的配置提交生效并更新running數據庫

Capability Identifier:

urn:ietf:params:netconf:capability:candidate:1.0

(４) Rollback-on-Error Capability

該能力表示server在執行client發送的配置數據出錯后可以進行回滾

Capability Identifier:

urn:ietf:params:netconf:capability:rollback-on-error:1.0

(５) Validate Capability

該能力表示server可以校驗client發送的配置數據是否正確

Capability Identifier:

urn:ietf:params:netconf:capability:validate:1.1

(６) Distinct startup Capability

該能力表示server有一個startup數據庫，用于保存啟動配置

Capability Identifier:

urn:ietf:params:netconf:capability:startup:1.0

1.2.2. 和

是由netconf-client發起的發送到netconf-server的消息。用于client請求server執行某項具體的操作。

包含一個強制屬性”message-id”，這個id是一個單調遞增的正整數，同一會話內不能重復。該id用于和的配對。

是有netconf-server發送給netconf-client的rpc響應。不能主動發起，僅能在收到之后回復，切必須攜帶與收到的rpc相同的message-id。

在定義了兩種默認的元素分別是和。表示未定義響應內容的rpc執行成功，而表示rpc執行失敗。

關于RPC最重要的一點： 原文如下：

NETCONFrequests MUST be processed serially by the managed device. Additionalrequests MAY be sent before previous ones have been completed. The managed device MUST send responses only in the order the requests were received.

個人對這段話的理解是這樣的：

1. netconf-client必須保證server收到的rpc請求的順序和message-id的順序是一致的。

2. netconf-server在能保證數據不沖突的前提下可以并行處理收到的rpc請求。

3. netconf-server在發送時必須嚴格按照收到的的順序。

1.2.3.

在netconf的1.0版本中還沒有加入Notification相關的內容，而在1.1版本已經將RFC5277(NETCONF Event Notifications)囊落在內了。支持Notification上報的netconf-server需在能力交換時上報能力：

“urn:ietf:params:netconf:capability:notification:1.0”

幾個關鍵的知識點：

1. Netconf的通知采用的是訂閱發布機制，server僅會向發送過訂閱請求的client發送通知。

2. Netconf的通知是以Stream進行分類的，不同類的Stream以不同的stream-name進行區分。netconf-server默認需要支持的stream-name是”NETCONF”。

3. client不能重復下發訂閱，即同一Stream的訂閱不能重復下發，也不能同時訂閱多個Stream，訂閱可以設置定時取消，如果沒有設置終止時間，取消訂閱需要使用close-session或者kill-session。定時取消的訂閱netconf的會話還是激活的，而使用close-session或者kill-session來取消的話，netconf會話會關閉。

Stream發現：

例如：

???? ???????? ???????????? ???????????????? ???????????? ???????? ???? ???? ???????? ???????????? ???????????????? ????????????????????NETCONF ????????????????????default?NETCONF?event?stream ????????????????????true ????????????????????2007-07-08T00:00:00Z ???????????????? ???????????????? ????????????????????SNMP ????????????????????SNMP?notifications ????????????????????false ???????????????? ???????????????? ????????????????????syslog-critical ????????????????????Critical?and?higher?severity ????????????????????true ????????????????????2007-07-01T00:00:00Z ???????????????? ???????????? ???????? ????

發起訂閱：

???? ????????SNMP ???? ????

通知內容舉例:

????2007-07-08T00:10:00Z ???? ????????state ???????? ????????????Ethernet0 ???????? ????????enabled ????

1.3. 操作層

操作層僅承載在僅和消息上，和消息無操作層。

NETCONF協議規定了9種簡單的rpc操作，同時也支持用戶自定義rpc操作。有關自定義操作的內容放到內容層來講。

1.3.1.

用于查詢狀態數據，另外如果server支持能力：urn:ietf:params:netconf:capability:xpath:1.0則還可以使用filter進行條件查詢，例如：

???? ???????? ???????????? ???????????????? ???????????????????? ????????????????????????eth0 ???????????????????? ???????????????? ???????????? ???????? ???? ???? ???????? ???????????? ???????????????? ????????????????????eth0 ????????????????????45621 ????????????????????774344 ???????????????? ???????????? ???????? ????

1.3.2.

用于查詢配置數據，可以通過 來指定不同的配置庫，例如：

???? ???????? ???????????? ???????? ???????? ???????????? ???????????????? ???????????? ???????? ???? ???? ???????? ???????????? ???????????????? ????????????????????root ????????????????????superuser ????????????????????Charlie?Root ???????????????????? ????????????????????????1 ????????????????????????1 ???????????????????? ???????????????? ???????????????? ???????????? ???????? ????

1.3.3.

用于對指定配置數據庫的內容進行修改，支持以下幾種操作：

merge:?合并操作，此操作為默認操作。

replace:?替換操作，如果對象已經存在則替換，不存在則創建。

create:?創建操作，如果對象已經存在，則報錯誤“data-exists”。

delete:?刪除操作，如果對象存在則刪除，不存在則報錯 “data-missing”。

remove:?刪除操作，如果對象存在則刪除，不存在則忽略。

舉例：

???? ???????? ???????????? ???????? ???????? ???????????? ???????????????? ????????????????????Ethernet0/0 ????????????????????1500 ????????????????????