Wing

Appearance

SONiC Telemetry/gNMI 探究 ​

SONiC Telemetry 是 SONiC 的遥测服务，其原分支位于GitHub - sonic-net/sonic-telemetry

但是该分支已经在2022年8月被归档

新的分支位于 GitHub - sonic-net/sonic-gnmi

从代码结构上看，两者代码和功能相同，最大的区别是从 Azure/sonic-telemetry 转移到了 sonic-net/sonic-gnmi

前置知识：什么是gNMI，它和gRPC是什么关系 ​

gNMI是一套基于gRPC的标准化网络管理接口

gRPC是由google研发的RPC消息框架

RPC是远程过程调用的简称，gRPC通过在不同的应用程序之间内置gRPC Server和 gRPC Stub完成通信

gRPC架构，来自其官网

ProtoBuf是一套灵活的接口定义语言，其可以通过 potoc 方便的生成各种语言的接口

如有以下内容的Protobuf文件

protobuf
syntax = "proto3";

// The greeter service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

该定义声明了一个SayHello接口，并定义了当传递字符量name的HelloRequest时，返回字符量message的Response.

通过protoc工具，则可以通过生成其在各种语言中的调用方法

text
#生成C++中的protobuf调用
protoc --cpp_out=cpp_out/  hello.proto

#生成Python中的protobuf调用
protoc --python_out=cpp_out/  hello.proto

扩展: 为什么纯C没有Protobuf的官方支持？ ​

并不是说C完全没有Protobuf的支持，仍然有C的网络项目提供了Protobuf样例，例如FRR。

但是gRPC官方推荐的通信手段是HTTP/2，C语言本身没有HTTP/2标准库，而不同平台上移植HTTP/2附加的TLS、其他加密压缩、流控特性也是不同的，故而protoc没有提供标准的C代码生成

但通过C代码结合第三方库去实现一个gRPC服务端/客户端是完全可行的

主线：gNMI？ ​

在了解前置知识以后，回到gNMI本身，

gNMI是来自openconfig的开源网络管理接口(Network Management Interface)

一般作为接口，那么必然（或者在遥远的未来必然）会有相应的实现。

而gNMI官方便提供了一个相应的实现

该如何使用它？

text
官方的说明是
go get -u github.com/openconfig/gnmi/cmd/gnmi_cli
但该方法在最新的golang上面实测已经不可用

#应当使用
go install github.com/openconfig/gnmi/cmd/gnmi_cli@latest
来安装

Q: 为什么我安装以后仍然找不到该文件

对于go而言，其安装是编译可执行文件并拷贝到 GOPATH 中的 bin 目录，通常这种情况是没有将GOPATH加入到PATH环境变量中，可以使用该方法找到文件

text
moxi@Morxi-workstation:~$ go env | grep GOPATH
GOPATH="/home/moxi/go"
moxi@Morxi-workstation:~$ cd /home/moxi/go
moxi@Morxi-workstation:~/go$ ls
bin  pkg
moxi@Morxi-workstation:~/go$ cd bin/
moxi@Morxi-workstation:~/go/bin$ ls
gnmi_cli

gnmi_cli提供的功能可以很方便的在这里找到，

gnmi/cmd/gnmi_cli/gnmi_cli.go at master · openconfig/gnmi · GitHub

是不是一直没出场：SONiC Telemetry/SONiC-gNMI ​

在上一章节引入了 gNMI CLI , 那么对应的 gNMI Server 呢 ?

OpenConfig自己又不生产网络设备，这事就轮到了SONiC，SONiC提供了一个框架，供厂商去实现

来自其项目首页

左边的 gNMI server 和 gNMIDiaout Publish service 便是 gNMI 在SONiC中的实现

说白了就是可以从机器上的各种模块把数据取出来，但是分成了两个服务端。一个服务端对外是被动的，被链接以后会主动的发数据，另一个服务端对外是主动的，会主动连接外部的服务端去发送数据

SONiC-gNMi往gNMI里面添加了一些patch，和openconfig的gNMI有略微区别，它在README里面讲到了这些差异 gnmi_cli is updated with following args

gNOI ​

在 gNMI 的 test_server 里面，有一套 gNOI 的依赖

gNOI是OpenConfig的一套接口，用于在网络设备上面执行特定的命令，

SONiC也给了相应的实现，其提供了如下功能

text
service SonicService {
  rpc ShowTechsupport (TechsupportRequest) returns (TechsupportResponse) {}
  rpc CopyConfig(CopyConfigRequest) returns (CopyConfigResponse) {}
  rpc ImageInstall(ImageInstallRequest) returns (ImageInstallResponse) {}
  rpc ImageRemove(ImageRemoveRequest) returns (ImageRemoveResponse) {}
  rpc ImageDefault(ImageDefaultRequest) returns (ImageDefaultResponse) {}
  rpc ClearNeighbors(ClearNeighborsRequest) returns (ClearNeighborsResponse) {}
}

把它跑起来： ​

text
Dial_in模式的Server
./telemetry --port 8080 -insecure true  --allow_no_client_auth --logtostderr
Dial_in模式的下面通过gnmi_get获取数据
./gnmi_get -xpath_target COUNTERS_DB -xpath COUNTERS_PORT_NAME_MAP -target_addr 10.2.2.2:8080 -alsologtostderr -insecure true



#在设备上面启动服务
root@sonic:/# /usr/sbin/dialout_client_cli  -insecure -logtostderr -v 1
#在一个外部服务其上面启动server
root@ASW:/tmp# ./dialout_server_cli -allow_no_client_auth -logtostderr -port 8081 -insecure -v 2

其中，insecure是不进行CA加密，这个在本地测试的时候比较有用，市场环境下务必部署证书
也可以直接在sonic上面本地登录然后启动验证，开两个SSH就行

这篇只是简单的梳理一下最近想到的一个模块，后续会逐步的将自己的实验环境整理好发出

Powered by Morxi/Moxi