Aruba JH391A Configuration Guide

Brand: Aruba

Model: JH391A

Category: Networking

Type: Configuration Guide

HPE FlexFabric 5940 Switch Series

Telemetry Configuration Guide

Software version: Release 671x and later

Document version: 6W100-20230822

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 ·························································································· 1

About gRPC ······················································································································································· 1

gRPC protocol stack layers ························································································································ 1

Network architecture ·································································································································· 1

Telemetry technology based on gRPC ······································································································ 1

Telemetry modes ······································································································································· 2

gNMI ··························································································································································· 2

Protocols ···················································································································································· 2

FIPS compliance ················································································································································ 2

Restrictions and guidelines: gRPC configuration ······························································································· 3

gRPC configuration tasks at a glance ················································································································ 3

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

Configuring the gRPC service ···················································································································· 3

Configuring a gRPC user ··························································································································· 4

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

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

Enabling the gRPC service ························································································································ 5

Configuring sensors ··································································································································· 5

Configuring collectors ································································································································· 6

Configuring a subscription ·························································································································· 7

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

Specifying the PKI domain for secure communication with collectors ······························································· 9

Setting the maximum CPU usage for gRPC ···································································································· 10

Display and maintenance commands for gRPC ······························································································ 10

gRPC configuration examples ························································································································· 10

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

Example: Configuring event-triggered telemetry in gRPC dial-out 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 for dial-in mode ········································································································ 15

Proto definition files for dial-out mode ······································································································ 17

Obtaining proto definition files ·················································································································· 18

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

Prerequisites ············································································································································ 18

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

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

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

Appendix: Methods and attributes for gNMI operations ··········································································· 32

Document conventions and icons ································································ 40

Conventions ····················································································································································· 40

Network topology icons ···································································································································· 41

Support and other resources ······································································· 42

Accessing Hewlett Packard Enterprise Support······························································································· 42

Accessing updates ··········································································································································· 42

Websites ·················································································································································· 43

Customer self repair ································································································································· 43

Remote support ········································································································································ 43

Documentation feedback ························································································································· 43

Index ············································································································ 45

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 Defines the data of the service module.

Two peers must notify each other of the data models that they are using.

Protocol buffer encoding layer Encodes data by using the protocol buffer code format.

gRPC layer Defines the protocol interaction format for remote procedure calls.

HTTP 2.0 layer Carries gRPC.

TCP layer Provides connection-oriented reliable data links.

Network architecture

As shown in Figure 1, the gRPC network uses the client/server model. It uses HTTP 2.0 for packet

transport.

Figure 1 gRPC network architecture

The gRPC network uses the following mechanism:

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.

The device can act as the gRPC server or client.

Telemetry technology based on gRPC

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

status. Hewlett Packard Enterprise 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.

gRPC server gRPC client

HTTP 2.0

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 operations:

 Get—Obtains device status and settings.

 CLI—Executes commands on the device.

 gNMI—gRPC Network Management Interface operations, which include 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 data collection or event-triggered data collection.

•

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.

gNMI

gRPC Network Management Interface (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.

The device supports gNMI and non-gNMI subscriptions for pushing data to a collector.

Protocols

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

FIPS compliance

The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for

features, commands, and parameters might differ in FIPS mode and non-FIPS mode. For more

information about FIPS mode, see Security Configuration Guide.

gRPC is not supported in FIPS mode.

Device

IP network

Restrictions and guidelines: gRPC configuration

Disabling the gRPC service deletes all gRPC-related settings.

gRPC configuration tasks at a glance

Configure gRPC dial-in and dial-out modes as needed:

1. Configuring the gRPC dial-in mode

Configure gRPC dial-in when the device acts as a gRPC server to communicate with collectors

that act as gRPC clients.

a. Configuring the gRPC service

b. Configuring a gRPC user

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

2. Configuring the gRPC dial-out mode

Configure gRPC dial-out when the device acts as a gRPC client to communicate with collectors

that act as gRPC servers.

a. Enabling the gRPC service

b. Configuring sensors

c. Configuring collectors

d. Configuring a subscription

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

3. (Optional.) Specifying the PKI domain for secure communication with collectors

4. (Optional.) Setting the maximum CPU usage for gRPC

Configuring the gRPC 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.

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.

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 commands in Security Command Reference.

Enabling gRPC logging in dial-in mode

About this task

To identify issues with gRPC in dial-in mode, 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 Network Management and Monitoring 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

Enabling the gRPC service

1. Enter system view.

system-view

2. Enable the gRPC service.

grpc enable

By default, the gRPC service is disabled.

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.

Restrictions 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 non-gNMI sensor group and enter sensor group view.

sensor-group group-name

4. Specify a sensor path.

sensor path path [ selection-nodes node-list ]

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 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.

You can add collectors to a destination group by their IP addresses or domain names. When you

specify collectors by their domain names, use the following restrictions and guidelines:

•

You must configure DNS to make sure the device can translate the domain names of the

collectors to IP addresses. For more information about DNS, see Layer 3—IP Services

Configuration Guide.

•

To view domain name and IP address mappings, use the display dns host command. If a

domain name maps to multiple IP addresses, the device will push data to the first reachable IP

address.

To encrypt the gRPC connections between the device and the target collector, use one of the

following methods:

•

Enable TLS encryption globally for all gRPC connections by executing the grpc pki domain

command in system view. The device uses the TLS certificates in the specified PKI domain for

encryption.

•

Enable collector-specific TLS encryption by specifying the tls keyword when you add a

collector to a destination group. The device uses one root TLS certificate that came with it to

encrypt the gRPC connection to the specified collector.

For a collector, the setting in system view has higher priority than the collector-specific setting.

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.

Prerequisites

To configure a collector that resides in a VPN instance, configure the VPN instance first. For more

information about VPN instance configuration, see MPLS L3VPN configuration in MPLS

Configuration Guide.

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. Add a collector to the destination group by its IP address.

IPv4:

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

vpn-instance-name ] [ tls ]

IPv6:

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

vpn-instance-name ] [ tls ]

The IPv6 address cannot be a link-local address. For more information about link-local

addresses, see IPv6 basics configuration in Layer 3—IP Services Configuration Guide.

To add multiple collectors, repeat this command. A collector is uniquely identified by a

three-tuple of IP address, port number, and VPN instance name. One collector must have a

different IP address, port number, or VPN instance name than the other collectors in the

destination group.

5. Add a collector to the destination group by its domain name.

IPv4:

domain-name domain-name [ port port-number ] [ vpn-instance

vpn-instance-name ] [ tls ]

IPv6:

ipv6 domain-name domain-name [ port port-number ] [ vpn-instance

vpn-instance-name ] [ tls ]

To add multiple collectors, repeat this command. A collector is uniquely identified by a

three-tuple of domain name, port number, and VPN instance name. One collector must have a

different domain name, port number, or VPN instance name than the other collectors in the

destination group.

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 in the destination groups.

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.) Set the DSCP value for packets sent to collectors.

dscp dscp-value

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

A greater DSCP value represents a higher priority.

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

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

interface-number | ipv6 ipv6-address }

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 IP address for packets sent to collectors causes the device to re-establish

the connection to the gRPC server.

7. (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.

8. 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.

9. Specify a destination group.

destination-group group-name

By default, no destination groups are specified.

Enabling gRPC logging in dial-out mode

About this task

To identify issues with gRPC in dial-out mode, 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 Network Management and Monitoring 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.

Specifying the PKI domain for secure

communication with collectors

About this task

By default, the gRPC connection between the device and a collector does not provide data

encryption service or require authentication. After you specify a PKI domain, the device and the

collector will use TLS for data encryption and bidirectional certificate-based authentication to

improve communication security.

Restrictions and guidelines

The specified PKI domain must already exist and has correct certificate and key settings. For more

information about PKI domains, see PKI configuration in Security Configuration Guide.

After you specify the PKI domain, the gRPC function will reboot, closing the connections to collectors.

In dial-in mode, the collectors must re-initiate the connections. In dial-out mode, the device will

automatically re-initiate the connections.

Procedure

1. Enter system view.

system-view

2. Specify the PKI domain for secure communication with collectors.

grpc pki domain domain-name

By default, no PKI domain is specified for secure communication with collectors.

Setting the maximum CPU usage for gRPC

About this task

gRPC data sampling is CPU intensive. To prevent gRPC from negatively affecting other services,

limit its maximum CPU usage. If the specified maximum CPU usage is exceeded during data

sampling, gRPC suspends data sampling until after its CPU usage drops below the specified limit.

Procedure

1. Enter system view.

system-view

2. Specify the PKI domain for secure communication with collectors.

grpc cpu-usage max-percent percentage

By default, No CPU usage limit is set for gRPC.

Display and maintenance commands for gRPC

Execute display commands in any view.

Task

Command

Display gRPC information.

display grpc [ verbose

]

Display periodic sensor paths that have the

minimum sampling interval. display telemetry sensor-path

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

"Developing the 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> system-view

[Device] grpc enable

# Create a local user named test. Set the password of the user, and assign user role

network-admin and the 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 Hewlett Packard Enterprise 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 event-triggered telemetry in gRPC

dial-out mode

Network configuration

As shown in Figure 4, the device acts as a gRPC client and connects to the telemetry data collector

(a gRPC server). The collector receives data on port 50050.

Configure the device to operate in dial-out mode to push interface event data to the collector.

Figure 4 Network diagram

Device

(gRPC server)Collector

(gRPC client)

192.168.1.1 192.168.2.1

Device

(gRPC client) Collector

(gRPC server)

Restrictions and guidelines

When you execute the sensor-group command in subscription view to specify a sensor group

that contains event-triggered sensor paths for a subscription, do not use the sample-interval to

set a data push interval.

NOTE:

An event-triggered sensor path typically contains a string of event in its path name.

Procedure

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

not shown.)

# Enable gRPC.

<Device> system-view

[Device] grpc enable

# Create a sensor group named Test, and add sensor path ifmgr/interfaceevent to it.

[Device] telemetry

[Device-telemetry] sensor-group Test

[Device-telemetry-sensor-group-Test] sensor path ifmgr/interfaceevent

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

# Create a destination group named collector1 and add a collector to the group. In this example, the

collector receives data on port 50050 at IPv4 address 192.168.2.1.

[Device-telemetry] destination-group collector1

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

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

# Configure a subscription named B to bind sensor group Test with destination group collector1.

[Device-telemetry] subscription B

[Device-telemetry-subscription-B] sensor-group Test

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

[Device-telemetry-subscription-B] quit

Verifying the configuration

Access the collector and verify that the collector can receive the interface event data pushed by the

device. (Details not shown.)

Example: Configuring the gRPC dial-out mode

Network configuration

As shown in Figure 5, 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 5 Network diagram

192.168.1.1 192.168.2.1

Device

(gRPC client) Collector

(gRPC server)

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

[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 data push 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.

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.

Hewlett Packard Enterprise provides proto definition files for both dial-in mode and dial-out mode.

Proto definition files for 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 extended 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 Hewlett Packard Enterprise. 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; // Command request ID

required string cli = 2; // Command string

}

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; // Command request ID

required string cli = 2; // Command string

}

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 files for 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.

•

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 grpc_dialout.proto file is provided by Hewlett Packard Enterprise. The following are the

contents of the 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

}

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

Page is loading ...

Aruba JH391A Configuration Guide

Brand: Aruba

Model: JH391A

Category: Networking

Type: Configuration Guide

Download PDF

report

Aruba JH391A Configuration Guide

Aruba JH391A Configuration Guide

Related papers

Other documents