HPE Networking Comware 5960 Switch Series Telemetry Configuration Guide

Brand: HPE

Model: Networking Comware 5960 Switch Series Telemetry

Category: Networking

Type: Configuration Guide

HPE Networking Comware 5960 Switch Series

Telemetry Configuration Guide

Software

version: Release 9126P01 and later

Document version: 6W100-20230428

The information contained herein is subject to change without notice. The only warranties for Hewlett Packard

Enterprise products and services are set forth in the express warranty statements accompanying such

products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett

Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein.

Confidential computer software. Valid license from Hewlett Packard Enterprise required for possession, use, or

copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software

Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s

standard commercial license.

Links to third-party websites take you outside the Hewlett Packard Enterprise website. Hewlett Packard

Enterprise has no control over and is not responsible for information outside the Hewlett Packard Enterprise

website.

Acknowledgments

Intel®, Itanium®, Pentium®, Intel Inside®, and the Intel Inside logo are trademarks of Intel Corporation in the

United States and other countries.

Microsoft® and Windows® are either registered trademarks or trademarks of Microsoft Corporation in the

United States and/or other countries.

Adobe® and Acrobat® are trademarks of Adobe Systems Incorporated.

Java and Oracle are registered trademarks of Oracle and/or its affiliates.

UNIX® is a registered trademark of The Open Group.

Contents

Configuring gRPC ·························································································· 3

About gRPC ······················································································································································· 3

gRPC protocol stack layers ························································································································ 3

Network architecture ·································································································································· 3

Telemetry technology based on gRPC ······································································································ 4

Telemetry modes ······································································································································· 4

Telemetry data model architectures ··········································································································· 4

Protocols ···················································································································································· 5

Restrictions and guidelines: gRPC configuration ······························································································· 5

Configuring the gRPC dial-in mode···················································································································· 5

gRPC dial-in mode configuration tasks at a glance ··················································································· 5

Configuring the gRPC service ···················································································································· 5

Configuring a gRPC user ··························································································································· 5

Enabling gRPC logging in dial-in mode······································································································ 6

Configuring the gRPC dial-out mode ················································································································· 7

gRPC dial-out mode configuration tasks at a glance ················································································· 7

Enabling the gRPC service ························································································································ 7

Configuring sensors ··································································································································· 7

Configuring collectors ································································································································· 8

Configuring a subscription ·························································································································· 9

Enabling gRPC logging in dial-out mode ································································································· 11

Displaying gRPC information ··························································································································· 11

gRPC configuration examples ························································································································· 11

Example: Configuring the gRPC dial-in mode ·························································································· 11

Example: Configuring the gRPC dial-out mode ······················································································· 12

Protocol buffer code ····················································································· 14

Protocol buffer code format ······························································································································ 14

Proto definition files ·········································································································································· 15

Proto definition files in dial-in mode ········································································································· 15

Proto definition file in dial-out mode ········································································································· 17

Obtaining proto definition files ·················································································································· 19

Example: Developing a gRPC collector-side application ················································································· 20

Prerequisites ············································································································································ 20

Generating the C++ code for the proto definition files·············································································· 20

Developing the collector-side application (dial-in mode) ·········································································· 20

Developing the collector-side application (dial-out mode)········································································ 33

Appendix A Methods and attributes for gNMI operations ···························· 35

Configuring INT ··························································································· 41

About INT ························································································································································· 41

INT network components ························································································································· 41

INT packet formats ··································································································································· 41

How INT works ········································································································································· 41

Restrictions and guidelines: INT configuration ································································································· 42

Configuring common INT ································································································································· 43

Configuring the exit node ························································································································· 43

Configuring the transit node ····················································································································· 43

Configuring the entry node ······················································································································· 44

Configuring flexible INT ···································································································································· 45

Configuring the exit node ························································································································· 45

Configuring the transit node ····················································································································· 46

Configuring the entry node ······················································································································· 46

Enabling global INT packet dropping ··············································································································· 47

Verifying and maintaining INT ·························································································································· 47

INT configuration examples ····························································································································· 48

Example: Configuring common INT ········································································································· 48

Example: Configuring flexible INT ············································································································ 50

Configuring flow groups ··············································································· 53

About flow groups ············································································································································ 53

Restrictions and guidelines: Flow group configuration ····················································································· 53

Procedure························································································································································· 53

Verifying and maintaining flow group ··············································································································· 54

Configuring MOD ························································································· 55

Overview ·························································································································································· 55

Restrictions and guidelines: MOD configuration ······························································································ 55

Configuring common MOD······························································································································· 55

Verifying and maintaining MOD ······················································································································· 56

MOD configuration examples ··························································································································· 56

Example: Configuring common MOD to send packets through UDP ······················································· 56

Configuring telemetry stream ······································································· 59

About telemetry stream ···································································································································· 59

How telemetry stream works ···················································································································· 59

Telemetry stream timestamping ··············································································································· 59

Configuring basic telemetry stream functions ·································································································· 60

Verifying and maintaining telemetry stream ····································································································· 61

Verifying the configuration and running status for ACLs and service loopback groups ··························· 61

Verifying telemetry stream and sampler configuration ············································································· 61

Telemetry stream configuration examples ······································································································· 61

Example: Configuring telemetry stream ··································································································· 61

Document conventions and icons ································································ 64

Conventions ····················································································································································· 64

Network topology icons ···································································································································· 65

Support and other resources ······································································· 66

Accessing Hewlett Packard Enterprise Support······························································································· 66

Accessing updates ··········································································································································· 66

Websites ·················································································································································· 67

Customer self repair ································································································································· 67

Remote support ········································································································································ 67

Documentation feedback ························································································································· 67

Index ············································································································ 69

Configuring gRPC

About gRPC

gRPC is an open source remote procedure call (RPC) system initially developed at Google. It uses

HTTP 2.0 and provides network device configuration and management methods that support

multiple programming languages.

gRPC protocol stack layers

Table 1 describes the gRPC protocol stack layers.

Table 1 gRPC protocol stack layers

Layer

Description

Content layer

Carries encoded service data. This layer supports the following encoding

formats:

• Google Protocol Buffer (GPB)—A highly efficient binary encoding

format. This format uses proto definition files to describe the

structure of data to be serialized. GPB is more efficient in data

transmission than protocols such as JavaScript Object Notation.

• JavaScript Object Notation (JSON)—A lightweight data exchange

format. It uses a text format that is language neutral to store and

represent data, which is easy to read and compile. If service data is

in JSON format, you can use the public proto files to decode the

data without having to use the proto file specific to the service

module.

Make sure the device and collectors use compatible proto files.

gRPC layer Defines the interaction format for RPC calls. Public proto definition files

such as the grpc_dialout.proto file define the public RPC methods.

HTTP 2.0 layer The transport protocol for gRPC. HTTP 2.0 provides enhanced features

such as header field compression, multiplexing requests on a single

connection, and flow control.

Transport layer Provides links to transmit packets. The following protocols are supported:

• TCP—Provides connection-oriented and reliable data links.

• UDP—Provides fast but unreliable connectionless delivery.

Network architecture

As shown in Figure 1, the gRPC network uses the client/server model.

Figure 1 gRPC network architecture

When the device acts as the server, the gRPC mechanism is as follows:

1. The gRPC server listens to connection requests from clients at the gRPC service port.

2. A user runs the gRPC client application to log in to the gRPC server, and uses methods

provided in the .proto file to send requests.

3. The gRPC server responds to requests from the gRPC client.

gRPC server gRPC client

The device can act as the gRPC server or client, which depends on the telemetry mode that the

gRPC client and server use to establish a connection. For more information, see "Telemetry modes."

Telemetry technology based on gRPC

Telemetry is a remote data collection technology for monitoring device performance and operating

status. HPE telemetry technology uses gRPC to push data from the device to the collectors on the

NMSs. As shown in Figure 2, after a gRPC connection is established between the device and NMSs,

the NMSs can subscribe to data of modules on the device.

Figure 2 Telemetry technology based on gRPC

Telemetry modes

The device supports the following telemetry modes:

•

Dial-in mode—The device acts as a gRPC server and the collectors act as gRPC clients. A

collector initiates a gRPC connection to the device to subscribe to device data.

Dial-in mode supports the following types of operations:

 Get—Obtains device status and settings.

 CLI—Executes commands on the device.

 gNMI—Includes the following subtypes of operations:

− gNMI Capabilities—Obtains the capacities of the device.

− gNMI Get—Obtains the status and settings of the device.

− gNMI Set—Deploys settings to the device.

− gNMI Subscribe—Subscribes to data push services provided by the device. The data

might be generated by periodical sampling or event-triggered sampling.

gNMI is a gRPC-based protocol for network device management. It defines a series of RPC

methods to obtain or configure the states of devices. gNMI supports common data models. No

proto files specific to service modules are needed.

•

Dial-out mode—The device acts as a gRPC client and the collectors act as gRPC servers. The

device initiates gRPC connections to the collectors and pushes device data to the collectors as

configured.

Telemetry data model architectures

The device supports the following telemetry data model architectures:

•

Three-layer data model architecture—Contains the following three layers:

 RPC layer—Defined in public proto definition files grpc_dialout.proto and

grpc_dialout_v3.proto. This layer provides public RPC methods such as the message

format.

 Telemetry layer—Defined in the public proto definition file telemetry.proto. This layer

provides data collection-related services.

 Content layer—Carries GPB or JSON encoded service data.

Device

IP network

The RPC and telemetry layers are identical to the gRPC layer in the gRPC protocol stack, as

shown in Table 1.

•

Two-layer data model architecture—Contains the RPC and content layers. Two-layer data

models support only JSON for service data encoding.

Protocols

RFC 7540, Hypertext Transfer Protocol version 2 (HTTP/2)

Restrictions and guidelines: gRPC configuration

Disabling the gRPC service deletes all gRPC settings.

Configuring the gRPC dial-in mode

gRPC dial-in mode configuration tasks at a glance

To configure the gRPC dial-in mode, perform the following tasks:

1. Configuring the gRPC service

2. Configuring a gRPC user

3. (Optional.) Enabling gRPC logging in dial-in mode

Configuring the gRPC service

1. Enter system view.

system-view

2. Enable the gRPC service.

grpc enable

By default, the gRPC service is disabled.

3. (Optional.) Set the gRPC service port number.

grpc port port-number

By default, the gRPC service port number is 50051.

Changing the gRPC service port number reboots the gRPC service and terminates all gRPC

sessions to the gRPC server.

4. (Optional.) Set the gRPC session idle timeout timer.

grpc idle-timeout minutes

By default, the gRPC session idle timeout timer is 5 minutes.

Configuring a gRPC user

About this task

For gRPC clients to establish gRPC sessions with the device, you must configure local users for the

gRPC clients and authorize the local users to use the HTTPS service.

Procedure

1. Enter system view.

system-view

2. Add a local user with the device management right.

local-user user-name [ class manage ]

3. Configure a password for the user.

password [ { hash | simple } password ]

By default, no password is configured for a local user. A non-password-protected user can pass

authentication after providing the correct username and passing attribute checks.

4. Assign user role network-admin to the user.

authorization-attribute user-role user-role

By default, a local user is assigned the network-operator role.

5. Authorize the user to use the HTTPS service.

service-type https

By default, no service types are authorized to a local user.

For more information about the local-user, password, authorization-attribute, and

service-type commands, see AAA configuration in User Access and Authentication Command

Reference.

Enabling gRPC logging in dial-in mode

About this task

To identify gRPC issues, enable gRPC operations logging in dial-in mode.

This feature generates gRPC operation logs in dial-in mode and sends them to the information

center.

With the information center, you can configure log destinations and output rules. For more

information about the information center, see System Management Configuration Guide.

Restrictions and guidelines

gRPC operation logging might degrade device performance if gRPC operations are frequent. As a

best practice, use gRPC operation logging only when necessary and log only gRPC operations of

interest if gRPC operation logging is enabled.

Procedure

1. Enter system view.

system-view

2. Enable gRPC logging in dial-in mode. Choose the options to configure as needed:

 Enable gRPC logging for RPC operations in dial-in mode.

grpc log dial-in rpc { all | { cli | get }* }

By default, gRPC logging is disabled for RPC operations in dial-in mode.

 Enable gRPC logging for gNMI operations in dial-in mode.

grpc log dial-in gnmi { all | { capabilities | get | set |

subscribe }* }

By default, gRPC logging is enabled for gNMI Set operations and disabled for other gNMI

operations in dial-in mode.

Configuring the gRPC dial-out mode

gRPC dial-out mode configuration tasks at a glance

To configure the gRPC dial-out mode, perform the following tasks:

1. Enabling the gRPC service

2. Configuring sensors

3. Configuring collectors

4. Configuring a subscription

5. (Optional.) Enabling gRPC logging in dial-out mode

Enabling the gRPC service

1. Enter system view.

system-view

2. Enable the gRPC service.

grpc enable

By default, the gRPC service is disabled.

3. (Optional.) Specify the architecture of telemetry data models.

grpc data-model { 2-layer | 3-layer }

By default, the device uses two-layer telemetry data models to push data.

With the two-layer telemetry data model architecture, the device can only encode pushed data

in JSON format.

With the three-layer telemetry data model architecture, the device always uses gRPC (TCP) to

transport data, even if you have specified UDP as the transport protocol.

Configuring sensors

About this task

A sensor is a data path from which the device collects data and then pushes the data to a collector.

You can create a sensor group and then specify sensor paths in the group. Sensor groups include

non-gNMI sensor groups and gNMI sensor groups. If the collector uses gNMI, you must create gNMI

sensor groups.

A sensor path supports either event-trigged or periodic data collection.

•

Event-triggered—The device pushes data from the sensor path to the collector when certain

events occur. For information about event-triggered sensor paths, see NETCONF XML API

Event Reference for the module.

•

Periodic—The device pushes data from the sensor path to the collector at intervals. For

information about periodic sensor paths, see the NETCONF XML API references for the

module except for NETCONF XML API Configuration Reference and NETCONF XML API Data

Reference.

•

Condition-triggered—The device checks the data of the sensor path periodically and pushes

the data from the sensor path to the collector when certain conditions are met. For information

about condition-triggered sensor paths, the sensor path check interval, and data push

conditions, contact Hewlett Packard Enterprise Support.

Condition-triggered sensor paths are supported only by gNMI sensor groups.

Restirctions and guidelines

As a best practice for the device to push data from sensor paths, specify sensor paths of the same

type in a sensor group.

Configuring a non-gNMI sensor group

1. Enter system view.

system-view

2. Enter telemetry view.

telemetry

3. Create a sensor group and enter sensor group view.

sensor-group group-name

4. Specify a sensor path. Choose one option as needed:

 Specify a sensor path for periodic data collection:

sensor path path [ selection-nodes node-list | depth depth ]

 Specify a sensor path for event-triggered data collection:

sensor path path [ event-condition conditions ]

To specify multiple sensor paths, execute this command multiple times. If you execute this

command multiple times with the same sensor path specified, the most recent configuration

takes effect.

Configuring a gNMI sensor group

1. Enter system view.

system-view

2. Enter telemetry view.

telemetry

3. Create a gNMI sensor group and enter sensor group view.

sensor-group group-name gnmi

To enter the view of an existing gNMI sensor group, you do not need to specify the gnmi

keyword.

4. Specify a sensor path.

sensor path path [ selection-nodes node-list ]

To specify multiple sensor paths, execute this command multiple times.

Configuring collectors

About this task

Collectors are used to receive sampled data from network devices. For the device to communicate

with collectors, you must create a destination group and add collectors to the destination group.

Restrictions and guidelines

As a best practice, configure a maximum of five destination groups. If you configure too many

destination groups, system performance might degrade.

Procedure

1. Enter system view.

system-view

2. Enter telemetry view.

telemetry

3. Create a destination group and enter destination group view.

destination-group group-name

4. Specify a collector.

IPv4:

ipv4-address ipv4-address [ port port-number ] [ vpn-instance

vpn-instance-name ]

IPv6:

ipv6-address ipv6-address [ port port-number ] [ vpn-instance

vpn-instance-name ]

The IPv6 address of a collector cannot be an IPv6 link-local address. For more information

about IPv6 link-local addresses, see IPv6 basics configuration in Layer 3—IP Services

Configuration Guide.

To specify multiple collectors, execute this command multiple times. One collector must have a

different address, port, or VPN instance than the other collectors.

Configuring a subscription

About this task

A subscription binds sensor groups to destination groups. Then, the device pushes data from the

specified sensors to the collectors.

Subscriptions include non-gNMI subscriptions and gNMI subscriptions. To push data to a collector

that uses gNMI, you must configure a gNMI subscription.

Restrictions and guidelines

For a non-gNMI subscription, specify non-gNMI sensor groups.

For a gNMI subscription, specify gNMI sensor groups.

You cannot use a destination group in both a gRPC subscription and a gNMI subscription.

For the device to correctly push data from sensor paths in a sensor group, make sure the

subscription settings for the sensor paths are compliant with Table 2.

Table 2 Compatibility of sensor path types and subscription settings

Sensor path type Push mode Data push interval Data push

suppression interval

Periodical Default Configured Not configured

Event-triggered Default Not configured Not configured

Condition-triggered Condition-triggered Not configured Configured

Procedure

1. Enter system view.

system-view

2. Enter telemetry view.

telemetry

3. Create a subscription and enter subscription view.

 Create a non-gNMI subscription and enter subscription view.

subscription subscription-name

 Create a gNMI subscription and enter subscription view.

subscription subscription-name gnmi

To enter the view of an existing gNMI subscription, you do not need to specify the

gnmi keyword.

4. (Optional.) Set the data push mode.

push-mode condition-triggered

Perform this step only if a sensor group specified for a subscription contains condition-triggered

sensor paths.

This command is available only for gNMI subscriptions.

By default, the data push mode for a sensor path in a subscription is periodical or

event-triggered.

5. (Optional.) Specify a transport protocol for the device to send packets to collectors.

protocol { grpc | udp }

By default, the device uses gRPC (TCP) as the transport protocol to send packets to collectors.

This command is not available for gNMI subscriptions.

6. (Optional.) Set the DSCP priority of packets sent to collectors.

dscp dscp-value

By default, the DSCP value of packets sent to collectors is 0.

A greater DSCP value represents a higher priority.

7. (Optional.) Specify the source IP address for packets sent to collectors.

source-address { ipv4-address | interface interface-type

interface-number | ipv6 ipv6-address } [ port port-number ]

By default, the device uses the primary IPv4 address of the output interface for the route to the

collectors as the source address.

Changing the source address causes the device to reconnect to the gRPC server.

8. (Optional.) Specify the encoding format for pushed data.

encoding { gpb | json }

By default, the device uses the JSON format to encode pushed data.

The device can use the GPB format to encode pushed data only when it uses three-layer

telemetry data models to push data.

9. (Optional.) Enable per-row time-stamping for JSON-encoded subscription data.

json row-timestamp enable

By default, the device time-stamps JSON-encoded subscription data on a per-message basis.

Per-row subscription data time-stamping is not available for gNMI subscriptions.

10. Specify a sensor group.

sensor-group group-name [ sample-interval [ msec ] interval |

suppress-time suppress-time ]

By default, no sensor groups are specified.

Parameter

Description

sample-interval Data push interval.

Specify this parameter only for periodic sensor paths.

suppress-time Data push suppression interval.

Specify this parameter only for condition-triggered sensor paths.

11. Specify a destination group.

destination-group group-name

Enabling gRPC logging in dial-out mode

About this task

To identify gRPC issues, enable gRPC data collection logging in dial-out mode.

This feature generates gRPC data collection logs in dial-out mode and sends them to the information

center.

With the information center, you can configure log destinations and output rules. For more

information about the information center, see System Management Configuration Guide.

Restrictions and guidelines

gRPC logging in dial-out mode is unavailable for gNMI subscriptions.

Procedure

1. Enter system view.

system-view

2. Enable gRPC logging in dial-out mode.

grpc log dial-out { all | { event | sample }* }

By default, gRPC logging is disabled in dial-out mode.

Displaying gRPC information

To display gRPC information, execute the following command in any view:

display grpc [ verbose ]

gRPC configuration examples

These configuration examples describe only CLI configuration tasks on the device. The collectors

need to run an extra application. For information about collector-side application development, see

"Example: Developing a gRPC collector-side application."

Example: Configuring the gRPC dial-in mode

Network configuration

As shown in Figure 3, configure the gRPC dial-in mode on the device so the device acts as the gRPC

server and the gRPC client can subscribe to LLDP events on the device.

Figure 3 Network diagram

Procedure

1. Assign IP addresses to interfaces on the gRPC server and client and configure routes. Make

sure the server and client can reach each other.

2. Configure the device as the gRPC server:

# Enable the gRPC service.

Device

(gRPC server) Collector

(gRPC client)

<Device> system-view

[Device] grpc enable

# Create a local user named test. Set the password of the user, and assign the network-admin

user role and HTTPS service to the user.

[Device] local-user test

[Device-luser-manage-test] password simple 123456TESTplat&!

[Device-luser-manage-test] authorization-attribute user-role network-admin

[Device-luser-manage-test] service-type https

[Device-luser-manage-test] quit

3. Configure the gRPC client.

a. Prepare a PC and install the gRPC environment on the PC. For more information, see the

user guide for the gRPC environment.

b. Obtain the HPE proto definition file and uses the protocol buffer compiler to generate code

of a specific language, for example, Java, Python, C/C++, or Go.

c. Create a client application to call the generated code.

d. Start the application to log in to the gRPC server.

Verifying the configuration

When an LLDP event occurs on the gRPC server, verify that the gRPC client receives the event.

Example: Configuring the gRPC dial-out mode

Network configuration

As shown in Figure 4, the device is connected to a collector. The collector uses port 50050.

Configure gRPC dial-out mode on the device so the device pushes the device capability information

of its interface module to the collector at 10-second intervals.

Figure 4 Network diagram

Procedure

# Configure IP addresses as required so the device and the collector can reach each other. (Details

not shown.)

# Enable the gRPC service.

<Device> system-view

[Device] grpc enable

# Create a sensor group named test, and add sensor path ifmgr/devicecapabilities/.

[Device] telemetry

[Device-telemetry] sensor-group test

[Device-telemetry-sensor-group-test] sensor path ifmgr/devicecapabilities/

[Device-telemetry-sensor-group-test] quit

# Create a destination group named collector1. Specify a collector that uses IPv4 address

192.168.2.1 and port number 50050.

[Device-telemetry] destination-group collector1

192.168.1.1 192.168.2.1

Device

(gRPC client) Collector

(gRPC server)

[Device-telemetry-destination-group-collector1] ipv4-address 192.168.2.1 port 50050

[Device-telemetry-destination-group-collector1] quit

# Configure a subscription named A to bind sensor group test with destination group collector1. Set

the sampling interval to 10 seconds.

[Device-telemetry] subscription A

[Device-telemetry-subscription-A] sensor-group test sample-interval 10

[Device-telemetry-subscription-A] destination-group collector1

[Device-telemetry-subscription-A] quit

Verifying the configuration

# Verify that the collector receives the device capability information of the interface module from the

device at 10-second intervals. (Details not shown.)

Protocol buffer code

Protocol buffer code format

Google Protocol Buffers provide a flexible mechanism for serializing structured data. Different from

XML code and JSON code, the protocol buffer code is binary and provides higher performance.

However, JSON code is used for service data.

Table 3 compares a protocol buffer code format example and the corresponding JSON code format

example.

Table 3 Protocol buffer and JSON code format examples

Protocol buffer code format example

Corresponding JSON code format example

{

1:“HPE”

2:“HPE”

3:“HPE device_test”

4:“Syslog/LogBuffer”

5:"notification": {

"Syslog": {

"LogBuffer": {

"BufferSize": 512,

"BufferSizeLimit": 1024,

"DroppedLogsCount": 0,

"LogsCount": 100,

"LogsCountPerSeverity": {

"Alert": 0,

"Critical": 1,

"Debug": 0,

"Emergency": 0,

"Error": 3,

"Informational": 80,

"Notice": 15,

"Warning": 1

"OverwrittenLogsCount": 0,

"State": "enable"

}

"Timestamp": "1527206160022"

}

{

"producerName": "HPE",

"deviceName": "HPE",

"deviceModel": "HPE device_test",

"sensorPath": "Syslog/LogBuffer",

"jsonData": {

"notification": {

"Syslog": {

"LogBuffer": {

"BufferSize": 512,

"BufferSizeLimit": 1024,

"DroppedLogsCount": 0,

"LogsCount": 100,

"LogsCountPerSeverity": {

"Alert": 0,

"Critical": 1,

"Debug": 0,

"Emergency": 0,

"Error": 3,

"Informational": 80,

"Notice": 15,

"Warning": 1

"OverwrittenLogsCount": 0,

"State": "enable"

}

"Timestamp": "1527206160022"

}

Proto definition files

You can define data structures in a proto definition file. Then, you can compile the file with utility

protoc to generate code in a programing language such as Java and C++. Using the generated code,

you can develop an application for a collector to communicate with the device.

HPE provides proto definition files for both dial-in mode and dial-out mode.

Proto definition files in dial-in mode

Public proto definition files

Dial-in mode supports the following public proto definition files:

•

grpc_service.proto—Defines the public RPC methods in dial-in mode.

•

gnmi.proto—Defines the public RPC methods for gNMI operations.

•

gnmi_ext.proto—Defines the expanded message structures required by file gnmi.proto.

Files gnmi.proto and gnmi_ext.proto are from Google. For information about the download paths,

see "Obtaining proto definition files."

The grpc_service.proto file is provided by HPE. The following are the contents of the file:

syntax = "proto2";

package grpc_service;

message GetJsonReply { // Reply to the Get method

required string result = 1;

}

message SubscribeReply { // Subscription result

required string result = 1;

}

message ConfigReply { // Configuration result

required string result = 1;

}

message ReportEvent { // Subscribed event

required string token_id = 1; // Login token_id

required string stream_name = 2; // Event stream name

required string event_name = 3; // Event name

required string json_text = 4; // Subscription result, a JSON string

}

message GetReportRequest{ // Obtains the event subscription result

required string token_id = 1; // Returns the token_id upon a successful login

}

message LoginRequest { // Login request parameters

required string user_name = 1; // Username

required string password = 2; // Password

}

message LoginReply { // Reply to a login request

required string token_id = 1; // Returns the token_id upon a successful login

}

message LogoutRequest { // Logout parameter

required string token_id = 1; // token_id

}

message LogoutReply { // Reply to a logout request

required string result = 1; // Logout result

}

message SubscribeRequest { // Event stream name

required string stream_name = 1;

}

message CliConfigArgs { // Sends a configuration command and the parameters to the device

required int64 ReqId = 1; // Request ID of the command

required string cli = 2; // Command line of the configuration command

}

message CliConfigReply { // Reply to a configuration command execution request

required int64 ResReqId = 1; // Request ID, which corresponds to that in CliConfigArgs

required string output = 2; // Output from the command

required string errors = 3; // Command execution result

}

message DisplayCmdArgs { // Sends a display command and the parameters to the device

required int64 ReqId = 1; // Request ID of the command

required string cli = 2; // Command line of the display command

}

message DisplayCmdReply { // Reply to a display command execution request

required int64 ResReqId = 1; // Request ID, which corresponds to that in DisplayCmdArgs

required string output = 2; // Output from the command

required string errors = 3; // Command execution result

}

service GrpcService { // gRPC methods

rpc Login (LoginRequest) returns (LoginReply) {} // Login method

rpc Logout (LogoutRequest) returns (LogoutReply) {} // Logout method

rpc SubscribeByStreamName (SubscribeRequest) returns (SubscribeReply) {} // Event

subscription method

rpc GetEventReport (GetReportRequest) returns (stream ReportEvent) {} // Method for

obtaining the subscribed event

rpc CliConfig (CliConfigArgs) returns (stream CliConfigReply) {} // Method for

executing a configuration command and returning the execution result

rpc DisplayCmdTextOutput(DisplayCmdArgs) returns(stream DisplayCmdReply) {} //

Method for executing a display command and returning the execution result

}

Proto definition files for service modules

The dial-in mode supports proto definition files for the following service modules: Device, Ifmgr,

IPFW, LLDP, and Syslog.

The following are the contents of the Device.proto file, which defines the RPC methods for the

Device module:

syntax = "proto2";

import "grpc_service.proto";

package device;

message DeviceBase { // Structure for obtaining basic device information

optional string HostName = 1; // Device name

optional string HostOid = 2; // sysoid

optional uint32 MaxChassisNum = 3; //Maximum number of chassis

optional uint32 MaxSlotNum = 4; // Maximum number of slots

optional string HostDescription = 5; // Device description

}

message DevicePhysicalEntities { // Structure for obtaining physical entity information

of the device

message Entity {

optional uint32 PhysicalIndex = 1; // Entity index

optional string VendorType = 2; // Vendor type

optional uint32 EntityClass = 3; // Entity class

optional string SoftwareRev = 4; // Software version

optional string SerialNumber = 5; // Serial number

optional string Model = 6; // Model

}

repeated Entity entity = 1;

}

service DeviceService { // RPC methods

rpc GetJsonDeviceBase(DeviceBase) returns (grpc_service.GetJsonReply) {} // Method

for obtaining basic device information

rpc GetJsonDevicePhysicalEntities(DevicePhysicalEntities) returns

(grpc_service.GetJsonReply) {} // Method for obtaining physical entity information of

the device

}

Proto definition file in dial-out mode

Public proto definition files

Dial-out mode supports the following public proto definition files:

•

grpc_dialout.proto—Defines the public RPC methods in dial-out mode.

•

grpc_dialout_v3.proto—Defines the public RPC methods for three-layer telemetry data

models in dial-out mode.

•

telemetry.proto—Defines data sampling parameters for three-layer telemetry data models in

dial-out mode.

•

dial_out.proto—Defines the subscription message formats for gNMI subscriptions in dial-out

mode.

•

gnmi.proto—Defines the public RPC methods in gNMI subscriptions.

•

gnmi_ext.proto—Defines the extended message structures required by file gnmi.proto.

File dial_out.proto is from SONIC, and files gnmi.proto and gnmi_ext.proto are from Google. For

information about the download paths, see "Obtaining proto definition files." The other files are

provided by HPE.

The following are the contents of the grpc_dialout.proto file:

syntax = "proto2";

package grpc_dialout;

message DeviceInfo{ // Pushed device information

required string producerName = 1; // Vendor name

required string deviceName = 2; // Device name

required string deviceModel = 3; // Device model

optional string deviceIpAddr = 4; // Device IP

optional string eventType = 5; // Type of the sensor path

optional string deviceSerialNumber = 6; // Serial number of the device

}

message DialoutMsg{ // Format of the pushed data

required DeviceInfo deviceMsg = 1; // Device information described by DeviceInfo

required string sensorPath = 2; // Sensor path, which corresponds to xpath in NETCONF

required string jsonData = 3; // Sampled data, a JSON string

}

message DialoutResponse{ // Response from the collector. Reserved. The value is not

processed.

required string response = 1;

}

service GRPCDialout { // Data push method

rpc Dialout(stream DialoutMsg) returns (DialoutResponse);

}

The following are the contents of the grpc_dialout_v3.proto file:

syntax = "proto3";

package grpc_dialout_v3;

message DialoutV3Args{

int64 ReqId = 1;// Request ID

bytes data = 2;// Carried data

string errors = 3;// Error description.

int32 totalSize = 4;// Total size of the message when fragmented. Value 0 indicates

that the message is not fragmented.

}

service gRPCDialoutV3{

rpc DialoutV3(stream DialoutV3Args) returns (stream DialoutV3Args) {};

}

The following are the contents of the telemetry.proto file:

syntax = "proto3";

package telemetry;

message Telemetry {

string producer_name = 1;// Vendor name

string node_id_str = 2;// Device name

string product_name = 3;// Product name

string subscription_id_str = 15;// Subscription name

string sensor_path = 16;// Sensor path

uint64 collection_id = 17;// Sampling ID

uint64 collection_start_time = 18;// Start time of the sampling period

uint64 msg_timestamp = 19;// Timestramp when this message was generated

uint64 collection_end_time = 20;// End time of the sampling period

uint32 current_period = 21;// Sampling accuracy

string except_desc = 22;// Error description

enum Encoding {

Encoding_JSON = 0;// GPB encoding format

Encoding_GPB = 1;// JSON encoding format

};

Encoding encoding = 23;// Data encoding format

Page is loading ...

HPE Networking Comware 5960 Switch Series Telemetry Configuration Guide

Brand: HPE

Model: Networking Comware 5960 Switch Series Telemetry

Category: Networking

Type: Configuration Guide

Download PDF

report

HPE Networking Comware 5960 Switch Series Telemetry Configuration Guide

HPE Networking Comware 5960 Switch Series Telemetry Configuration Guide

Related papers

Other documents