首先，讓我們假想一個(gè)場(chǎng)景：
由于業(yè)務(wù)發(fā)生變更，需要為一個(gè) POD 里面的幾十臺(tái)交換機(jī)修改 QoS 配置。作為網(wǎng)絡(luò)運(yùn)維人員，應(yīng)該怎樣處理這項(xiàng)工作呢？
如果需要變更的對(duì)象是整個(gè)數(shù)據(jù)中心幾百臺(tái)甚至幾千臺(tái)交換機(jī)，又該怎樣處理這項(xiàng)工作呢？
當(dāng)下，互聯(lián)網(wǎng)行業(yè)已經(jīng)普遍采用 DevOps 的體系流程�？咳肆θヒ慌_(tái)設(shè)備一臺(tái)設(shè)備的更改配置，已經(jīng)不再是正確的思維方式。原因不僅僅是浪費(fèi)時(shí)間 —— 要知道，人如果要長(zhǎng)時(shí)間保持注意力集中，大腦需要耗費(fèi)大量的能量，很難保證不出現(xiàn)遺漏或者錯(cuò)誤。而機(jī)器卻不會(huì)。
因此，正確的方法是利用 DevOps 的流程，讓機(jī)器來完成這項(xiàng)工作。例如采用基于 Python 的 SSH 庫(kù) Paramiko 或 Netmiko，以及 Ansible 或 SaltStack 等自動(dòng)化工具編寫運(yùn)維腳本。
Netmiko 庫(kù)和 Ansible 等運(yùn)維工具雖然可以通過程序化的腳本對(duì)網(wǎng)絡(luò)設(shè)備實(shí)現(xiàn)批量管理，但仍然需要運(yùn)維工程師對(duì)網(wǎng)絡(luò)設(shè)備的 CLI 很熟悉，預(yù)先在腳本中建立需要被執(zhí)行的 Command 列表。
CLI
CLI 最大的問題就是在不同廠商的設(shè)備之間，甚至在不同版本之間存在較大差異。比如在某 C 廠商交換機(jī)上配置邊緣端口，不同的 OS 版本命令并不相同：而對(duì)于另一些廠商，配置命令則差異更大。例如在某 E 品牌 交換機(jī)上配置邊緣端口的命令為：這意味著：如果設(shè)備版本升級(jí)，就可能需要更改運(yùn)維腳本的代碼。為了避免廠商綁定，網(wǎng)絡(luò)內(nèi)通常也會(huì)同時(shí)存在多個(gè)廠商的設(shè)備，相應(yīng)地，也可能需要準(zhǔn)備多種運(yùn)維腳本或者讓運(yùn)維腳本變得很復(fù)雜 —— 先判斷設(shè)備型號(hào)和版本號(hào)，再運(yùn)行相應(yīng)的 Command-list。
所以 CLI 并不適合用來作為一種 API。雖然采用自動(dòng)化工具處理 Commands 可以節(jié)省網(wǎng)絡(luò)運(yùn)維人員的工作量，但是技術(shù)門檻和維護(hù)成本都比較高。SNMP 似乎是一種更好的選擇。
SNMP 的歷史很悠久，第 1 個(gè)與之相關(guān)的 RFC 1065 發(fā)布于 1988 年，距今已有 30 年。在 SNMP 架構(gòu)中，一個(gè)網(wǎng)絡(luò)設(shè)備以守護(hù)進(jìn)程的方式運(yùn)行 SNMP Agent，而 NMS（網(wǎng)絡(luò)管理系統(tǒng)）和網(wǎng)絡(luò)運(yùn)維人員所使用的各種 SNMP 管理工具則稱為 SNMP Manager。SNMP Agent 能夠響應(yīng)來自 SNMP Manager 的各種請(qǐng)求信息。
SNMP Agent 會(huì)維護(hù)一個(gè) MIB（管理信息庫(kù)），里面保存著大量的 OID （對(duì)象標(biāo)識(shí)符）。一個(gè) OID 是一對(duì)唯一的 Key-Value，SNMP Manager 向 SNMP Agent 查詢或修改若干 Key 所對(duì)應(yīng)的 Value，就可以實(shí)現(xiàn)信息采集或者網(wǎng)絡(luò)設(shè)備的配置修改。
上圖是一個(gè) MIB 示例，請(qǐng)注意標(biāo)黃色的部分。OID 1.3.6.1.2.1.2.2.1.5 用來以 bps 為單位評(píng)估接口流量，它屬于 RFC 1213 標(biāo)準(zhǔn) MIB，名稱為 ifSpeed，只讀。因?yàn)檫@個(gè) MIB 并不是我從正在運(yùn)行的設(shè)備上取下來的，所以當(dāng)前的 Value 為空。
需要注意的是，SNMP Manager 側(cè)的 MIB 并不是必需的。如果使用數(shù)字 OID 1.3.6.1.2.1.2.2.1.5，SNMP Manager 可以直接從 SNMP Agent get 接口流量帶寬，而不需要安裝完整的 MIB。
現(xiàn)在 SNMP 在網(wǎng)絡(luò)監(jiān)控領(lǐng)域已經(jīng)被廣泛使用，利用 Zabbix、Nagios、Cacti 等開源的 SNMP 管理工具采集網(wǎng)絡(luò)設(shè)備接口流量帶寬和其他設(shè)備信息，同時(shí)也有大量的基于 Python 的 SNMP 庫(kù)用來實(shí)現(xiàn)運(yùn)維開發(fā)，例如 PySNMP、 EasySNMP、 Net-SNMP等等，并且它們都可以集成到 Ansible 和 SaltStack 等自動(dòng)化運(yùn)維工具上。
看上去還不錯(cuò)，但實(shí)際上 SNMP 仍然不是一個(gè)合適的 API，因?yàn)樗嬖趲讉�(gè)問題：
○太古老，并發(fā)性能不好
○基于 UDP 協(xié)議傳輸，比較不可靠。雖然在應(yīng)用層有 Response 機(jī)制保證丟包之后的重復(fù) get/ set，但代價(jià)就是性能和運(yùn)行時(shí)間都受到影響
○最致命的問題是，各廠商都大量的使用私有 MIB，卻不存在一個(gè)可以自動(dòng)發(fā)現(xiàn)網(wǎng)絡(luò)設(shè)備當(dāng)前所采用的 MIB 的機(jī)制。網(wǎng)絡(luò)運(yùn)維人員必須分別向設(shè)備廠商索取網(wǎng)絡(luò)設(shè)備的 MIB，耗費(fèi)大量的時(shí)間整理自己需要的 OID，再手工導(dǎo)入到自動(dòng)化運(yùn)維平臺(tái)或者腳本當(dāng)中
所以 SNMP 仍然只適合用來做信息采集，提供告警和可視化報(bào)表，但自動(dòng)化運(yùn)維的 API 則需要考慮其他的選項(xiàng)。站在網(wǎng)絡(luò)運(yùn)維人員的角度，這個(gè) API 應(yīng)該滿足以下要求：
○容易使用 —— Usability 是所有產(chǎn)品的核心價(jià)值
○需要能夠清晰地區(qū)分“配置數(shù)據(jù)”，“設(shè)備運(yùn)行狀態(tài)數(shù)據(jù)”和“統(tǒng)計(jì)數(shù)據(jù)”
○需要能夠分別從各個(gè)網(wǎng)絡(luò)設(shè)備獲取上述 3 種數(shù)據(jù)，并且可以方便地對(duì)比不同設(shè)備的數(shù)據(jù)
○可以讓網(wǎng)絡(luò)運(yùn)維人員統(tǒng)一地管理整個(gè)網(wǎng)絡(luò)的所有設(shè)備，而不是一臺(tái)一臺(tái)的單獨(dú)管理
○對(duì)不同廠商的設(shè)備都能夠使用同一種配置方法
○配置變更對(duì)網(wǎng)絡(luò)業(yè)務(wù)的影響要盡可能的小
○能夠提供一個(gè)標(biāo)準(zhǔn)化的，對(duì)設(shè)備 Pulling 和 Pushing 配置文件的流程，以滿足對(duì)設(shè)備配置的備份和恢復(fù)的業(yè)務(wù)需求
○能夠很方便地，持續(xù)地，檢查設(shè)備配置文件的一致性
○能夠提供基于文本的配置方式，并且不會(huì)導(dǎo)致配置的亂序，例如不能攪亂 ACL 規(guī)則的順序
能夠滿足這些要求的網(wǎng)絡(luò)設(shè)備的北向 API 接口就是 Netconf。
Netconf 是 IETF 發(fā)布的標(biāo)準(zhǔn)協(xié)議，它的全稱是 Network Configuration Protocal。從名字就可以看出來，Netconf 的作用是基于網(wǎng)絡(luò)來安裝、操作和刪除設(shè)備的配置。在 Netconf 的架構(gòu)中，網(wǎng)絡(luò)設(shè)備充當(dāng) Netconf Server 的角色，而運(yùn)維人員的這一側(cè)則是 Netconf Client。此外，和 OSI 標(biāo)準(zhǔn)模型一樣，Netconf 也是分層結(jié)構(gòu)。
它有 4 個(gè)層次，從下到上依次為：
●安全傳輸層
安全傳輸層在 Netconf Client 和 Netconf Server 之間提供安全的端到端連接。與 SNMP 采用非面向連接的 UDP 協(xié)議不同，Netconf 采用面向連接的 TCP 協(xié)議，通常是 SSH 協(xié)議，保證連接的可靠性和安全性。
●消息層
消息層也稱為 RPC（遠(yuǎn)程過程調(diào)用）層。Netconf Server（網(wǎng)絡(luò)設(shè)備）上面部署了 Netconf 應(yīng)用，Netconf Client 需要調(diào)用 Server 上的應(yīng)用所提供的函數(shù)/方法，但由于 Client 和 Server 不在同一個(gè)內(nèi)存空間，無法直接調(diào)用，所以需要通過網(wǎng)絡(luò)來表達(dá)調(diào)用的語義，并傳達(dá)調(diào)用的數(shù)據(jù)。這個(gè)過程，稱為 RPC。它提供了一個(gè)簡(jiǎn)單的，與安全傳輸層無關(guān)的機(jī)制來封裝操作層和內(nèi)容層的數(shù)據(jù)：
○RPC 調(diào)用： 元素所封裝的消息
○RPC 結(jié)果： 元素所封裝的消息
○事件通知： 元素所封裝的消息
●操作層
操作層定義了如圖所示的 9 種基礎(chǔ)操作集，其中：
用來對(duì)設(shè)備進(jìn)行取值操作
用于配置設(shè)備參數(shù)
和是在對(duì)設(shè)備進(jìn)行操作時(shí)，為防止并發(fā)產(chǎn)生混亂的鎖行為和用于結(jié)束一個(gè)會(huì)話操作
●內(nèi)容層
顧名思義，內(nèi)容層就是用來表達(dá)配置數(shù)據(jù)和狀態(tài)數(shù)據(jù)，網(wǎng)絡(luò)運(yùn)維人員只需要關(guān)注數(shù)據(jù)本身，而不需要去關(guān)注設(shè)備的相關(guān)命令�；A(chǔ)網(wǎng)絡(luò)設(shè)備在內(nèi)容層所采用的數(shù)據(jù)格式通常是 XML，但也有廠商的數(shù)據(jù)格式采用了 JSON。
雖然網(wǎng)絡(luò)運(yùn)維人員不再需要關(guān)注設(shè)備的相關(guān)命令了，但仍然無法直接使用 Netconf 配置設(shè)備，還需要考慮配置結(jié)構(gòu)。
什么叫“配置結(jié)構(gòu)”呢？
假如我們現(xiàn)在要將交換機(jī)的 10# 端口劃入 VLAN 20。從上面兩個(gè)配置示例可以發(fā)現(xiàn)銳捷交換機(jī)和 H 品牌交換機(jī)的配置結(jié)構(gòu)有明顯差異，所以無法直接使用 XML 或者 JSON 修改它們的設(shè)備配置。
為了解決配置結(jié)構(gòu)的問題，需要將 XML 和 JSON 數(shù)據(jù)格式抽象成一個(gè)統(tǒng)一的標(biāo)準(zhǔn)的模型，這就是 YANG。YANG 的全稱是 Yet Another Next Generation，沒有恰當(dāng)?shù)闹形膩矸g它。通俗的講，YANG 是表達(dá) Netconf 所操作的配置數(shù)據(jù)和狀態(tài)數(shù)據(jù)的模板，它描述什么才是符合設(shè)備期望的數(shù)據(jù)。有了 YANG Model，配置結(jié)構(gòu)就交給它去處理，網(wǎng)絡(luò)運(yùn)維人員就只需要做一個(gè)完形填空即可。
這個(gè)過程在邏輯上，與向 SNMP 的 OID 填充/讀取 Value 差不多。
Netconf 和 YANG Model 的出現(xiàn)，為網(wǎng)絡(luò)自動(dòng)化帶來了極大的便利。配合自動(dòng)化的程序，可以實(shí)現(xiàn)動(dòng)態(tài)向網(wǎng)絡(luò)設(shè)備下發(fā)配置，將數(shù)據(jù)面和控制面分離，組成軟件定義的網(wǎng)絡(luò)。事實(shí)上，Netconf 也是 OpenDayLight 等開源 SDN Controller 所廣泛使用的南向接口之一。 此外，Ansible 也集成了 Netconf 的 Module，并且可以通過 Python 來擴(kuò)展 ncclient 和 nxpy 等庫(kù)，實(shí)現(xiàn)功能擴(kuò)展。
但 Netconf 就是我們?cè)趯ふ业睦硐氲?API 嗎？
站在網(wǎng)絡(luò)運(yùn)維者的角度，答案卻是否定的。
原因在于很多廠商雖然支持 Netconf，但有一些 Key-Value 卻存在差異。比如為了表達(dá)“端口”，有些廠商用 intf 作為 Key，但另外一些廠商卻用 interface 作為 Key。另一個(gè)例子就是 Uptime，設(shè)備運(yùn)行時(shí)間，各家廠商的設(shè)備返回的時(shí)間格式更是五花八門。這為網(wǎng)絡(luò)運(yùn)維人員處理數(shù)據(jù)的工作造成了很大的麻煩，不得不耗費(fèi)大量的時(shí)間和精力去閱讀設(shè)備廠商的 Netconf 文檔，去編寫大量的正則表達(dá)式。
還有，雖然主流的 SDN Controller 的南向接口都支持 Netconf，但是在實(shí)際部署時(shí)，卻無法用單一的 Controller 去控制多廠商的網(wǎng)絡(luò)設(shè)備。通常都是各個(gè)廠商使用自己的 SDN Controller 控制自己的設(shè)備，然后再用 REST API 與用戶的 SDN Controller 對(duì)接。
上文所提到的網(wǎng)絡(luò)運(yùn)維人員所關(guān)心的 9 大問題，Netconf 幾乎都能滿足，但距離完全滿足還有一些差距。
有一個(gè)解決辦法，就是利用 NAPALM。
NAPALM
NAPALM 是一個(gè) Python 庫(kù)，它的全稱是 Network Automation and Programmability Abstraction Layer with Multivendor support，多廠商支持的網(wǎng)絡(luò)自動(dòng)化和可編程抽象層。
目前 Ansible 集成了 3 個(gè) NAPALM 模塊，分別是：
○napalm_parse_yang：用于從設(shè)備或文件中解析配置/狀態(tài)數(shù)據(jù)
○napalm_diff_yang：用于比較 2 個(gè) YANG 對(duì)象的差異
○napalm_translate_yang：用于將 YANG 對(duì)象轉(zhuǎn)譯成設(shè)備原始的配置
從設(shè)備取出原始配置數(shù)據(jù)/狀態(tài)數(shù)據(jù)之后，可以使用 NAPALM 將其翻譯成標(biāo)準(zhǔn)格式的 NAPALM 數(shù)據(jù)。反之，也可以將標(biāo)準(zhǔn)格式的 NAPALM 數(shù)據(jù)翻譯成設(shè)備原始配置數(shù)據(jù)，并 Push 到網(wǎng)絡(luò)設(shè)備里面，以修改設(shè)備的配置文件。
讀到這里，也許您已經(jīng)猜到我將要說什么了……
是的，NAPALM 還是不能徹底解決網(wǎng)絡(luò)自動(dòng)化所面臨的問題。
因?yàn)楦鲝S商 Netconf 的數(shù)據(jù)表達(dá)存在很多差異，所以 NAPALM 必須要依賴第三方的 Module 來完成原始數(shù)據(jù)的解析和翻譯。如果要解析廠商 A 的某個(gè) OS 系統(tǒng)的配置，就需要一個(gè) OSA_Module；如果要解析廠商 B 的某個(gè) OS 系統(tǒng)的配置，則需要 OSB_Module。所以目前 NAPALM 支持的 OS 類型還比較少，僅限于某幾個(gè)國(guó)外品牌廠商的 OS 系統(tǒng)。
即使是這幾個(gè)國(guó)外品牌廠商，NAPALM 目前也無法實(shí)現(xiàn)完整的功能集。所以 Google 等網(wǎng)絡(luò)設(shè)備的大用戶一直在致力于推廣一個(gè)能夠替代 Netconf 的標(biāo)準(zhǔn)化接口： OpenConfig。
IETF 已經(jīng)為 Netconf 和 YANG Model 發(fā)布了很多 RFC，從 2006 年的 Netconf RFC 4741，2010 年的 YANG Model RFC 6020，到現(xiàn)在已經(jīng)超過 10 年。而最新的一個(gè) RFC 在什么時(shí)候呢？就在幾天之前的 2018 年 4 月 3 日，3 家設(shè)備廠商聯(lián)合提交了一個(gè) OSPF YANG Model 的草案 —— 標(biāo)準(zhǔn)化的進(jìn)展太慢了。
也許，這就是問題所在 —— Netconf 標(biāo)準(zhǔn)是由網(wǎng)絡(luò)設(shè)備廠商推動(dòng)的，內(nèi)耗太大。各個(gè)設(shè)備廠商都希望在軟件定義網(wǎng)絡(luò)的時(shí)代繼續(xù)保持硬件設(shè)備的重要性，并且能夠體現(xiàn)自己公司產(chǎn)品的差異化優(yōu)勢(shì)。
但是從網(wǎng)絡(luò)運(yùn)維者的角度考慮，這顯然不合理，因?yàn)樵O(shè)備廠商所推動(dòng)的 Netconf 標(biāo)準(zhǔn)并不是他們真正想要的。所以 Google，AT&T，British Telecom，F(xiàn)acebook，Apple，Microsoft 等互聯(lián)網(wǎng)服務(wù)提供商成立了 OpenConfig 工作組，希望提供一個(gè)中立于設(shè)備廠商的標(biāo)準(zhǔn) API。目前國(guó)內(nèi)的騰訊、百度和阿里等互聯(lián)網(wǎng)服務(wù)提供商也已經(jīng)加入了 OpenConfig 工作組。
OpenConfig 沿用了 Netconf 的協(xié)議框架，但是它不太關(guān)注底層的數(shù)據(jù)傳輸，而是更關(guān)注上層的數(shù)據(jù)表達(dá)和數(shù)據(jù)建模。這意味著：不管是 A 廠還是 B 廠，所有的數(shù)據(jù)都必須符合 OpenConfig YANG Model，并且 Key-Value 都必須是 OpenConfig 所規(guī)定的標(biāo)準(zhǔn)格式！
OpenConfig 的另外一個(gè)核心要點(diǎn)是：雖然網(wǎng)絡(luò)設(shè)備可能支持豐富的功能特性，甚至是設(shè)備廠商私有的功能特性，但是 OpenConfig 只關(guān)心與互聯(lián)網(wǎng)行業(yè)用戶通用的運(yùn)維工作和網(wǎng)絡(luò)設(shè)計(jì)工作相關(guān)的功能，例如 BGP、OpenFlow、Telemetry 等等。OpenConfig 不會(huì)為設(shè)備廠商的私有特性定義 YANG Model，也不會(huì)為設(shè)備廠商所特有的 Key-Value 做定義，所以不會(huì)出現(xiàn)不兼容的情況。
但反過來講，OpenConfig 也不會(huì)為了兼容某些設(shè)備廠商而讓 YANG Model 過于簡(jiǎn)單，所以設(shè)備廠商需要讓自己的功能滿足 OpenConfig YANG Model 的要求，具備 Model 所定義的所有的 Key，并且能夠?yàn)樗械?Key 提供對(duì)應(yīng)的 Value。
在 Key-Value 格式固定之后，網(wǎng)絡(luò)運(yùn)維人員對(duì)數(shù)據(jù)的解析工作就非常方便了。只要網(wǎng)絡(luò)設(shè)備支持標(biāo)準(zhǔn)的 OpenConfig YANG，NAPALM 就可以對(duì)原始數(shù)據(jù)進(jìn)行解析，不再依賴第三方 Module 就可以管理多廠商多 OS 的網(wǎng)絡(luò)，進(jìn)而實(shí)現(xiàn)真正的網(wǎng)絡(luò)自動(dòng)化。
使用 OpenConfig 的另一個(gè)好處就是可以簡(jiǎn)化 SDN 網(wǎng)絡(luò)架構(gòu)，用戶使用一個(gè)控制器集群就可以同時(shí)控制多個(gè)廠商的網(wǎng)絡(luò)設(shè)備，不再需要使用設(shè)備廠商的商用控制器做中繼。
OpenConfig 工作組在 2015 年已經(jīng)向 IETF 提交了 2 個(gè) YANG 標(biāo)準(zhǔn)草案，雖然目前還沒有標(biāo)準(zhǔn)的 RFC 發(fā)布，但是它現(xiàn)已成為網(wǎng)絡(luò)自動(dòng)化技術(shù)的發(fā)展趨勢(shì)，因此各大網(wǎng)絡(luò)設(shè)備廠商都開始了 OpenConfig 的開發(fā)工作。銳捷的數(shù)據(jù)中心交換機(jī)支持 Netconf YANG 和 OpenConfig YANG，目前正在國(guó)內(nèi)配合公有云提供商進(jìn)行標(biāo)準(zhǔn)化 SDN 的測(cè)試工作。
