Tag :: OpenConfig

AAA accounting records can be enabled for OpenConfig gNMI/gNOI RPCs. Accounting records can be logged to the TACACS+ server, RADIUS server, or to syslog.

This feature adds support for gNMI access to the last-configuration-timestamp YANG node in the OpenConfig/Octa agent. When a gNMI set is completed, the last-configuration-timestamp is updated. When the configuration is changed via CLI or some other mechanism, the change eventually propagates to the OpenConfig/Octa agent, which will update the last-configuration-timestamp.

When OpenConfig is enabled, the entire YANG tree is exposed to the client. This allows a client to have read and write access to all parts of the YANG tree. In some cases, it would be preferable to block portions of the YANG tree so that specific part of the tree cannot be modified or read by the client. 

This feature allows exporting IP-in-IP tunnel counters through the OpenConfig AFT YANG models.This exporting IP-in-IP counters feature is supported on all platforms, however counting the IP-in-IP tunnel packets is supported only on DCS-7500R3, DCS-7280R3 and DCS-7800R3 series. 

Traditionally, the OpenConfig gNMI service is based on a dial in model. A client sends a request to the gNMI server and

gNOI (gRPC Network Operations Interface) defines a set of gRPC based microservices for executing operational

gNOI (gRPC Network Operations Interface) defines a set of gRPC based microservices for executing operational

gNOI (gRPC Network Operations Interface) defines a set of gRPC based microservices for executing operational

The candidate configuration feature implements support for a candidate data store as specified in RFC6241.

Octa is a process which combines OpenConfig and certain TerminAttr functionality, primarily with the intent of

We now support configuration diffs to be generated and to be streamed via OpenConfig.  Please note that there are limitations to using this feature to obtain the correct configuration diff of consecutive configuration changes.  Subsequent sections will explain:

This feature adds support to configure the following QoS OpenConfig models via gNMI  QoS Classifiers for classification of incoming traffic. QoS Scheduler Policies for describing scheduling strategies on a port.

For Macro Segmentation Service Group (MSS-G) configurations, if only the segmentation model for OpenConfig is required, then it is possible to disable all other models for OpenConfig. This feature allows access to only the /segmentation path in the OpenConfig YANG tree. This significantly reduces the OpenConfig agent’s memory usage.

This feature provides support for SPIFFE-ID in OpenConfig. The SPIFFE-ID will take precedence over any metadata usernames or common name username found. This username will be used for all AAA operations. 

This feature allows us to obtain system mount points information via OpenConfig.  The information that can be obtained is equivalent to the information that we view by executing the ‘df -k’ linux command.

When this feature is enabled, responses to gNMI get requests as well as NETCONF get-config responses will contain the default values for YANG leafs if those leafs do not have any other value. This means that where a leaf value would normally be returned in a response, its default value (as defined in the YANG model) will be returned if the leaf does not have any other value assigned to it. Before this change, leafs that had a default value would not have been included in gNMI get responses.

This feature allows exporting the route count by protocol, i.e., a summary of routes, in the FIB (Forwarding Information Base) through the OpenConfig AFT YANG model.

gNSI (gRPC Network Security Interface) defines a set of gRPC-based microservices for executing security-related operations on network devices.

4.21.3F release supports reading and streaming various OpenConfig configuration and state models over gNMI (gRPC

4.23.2F release supports reading and streaming various OpenConfig configuration and state models over gNMI (gRPC

4.22.0F release supports reading and streaming various OpenConfig configuration and state models over gNMI (gRPC

These are the release notes and configuration guide for the OpenConfig feature in the 4.21.0F release.

This feature adds support for streaming the output of the following show command in Octa:. The

This supports checking that the value of a given x509 certificate OID matches a user-provided value during the TLS handshake in OpenConfig. If the value does not match, no connection will be established.

This feature introduces a flag to indicate to a gNMI client that the FIB (forwarding information base) or IPv4/IPv6 unicast AFT (abstract forwarding table) have converged and the snapshot is consistent with the device.

This feature allows the export of IP FIB (Forwarding Information Base) through the OpenConfig AFT YANG models.

This feature allows LFIB (Label Forwarding Information Base) & associated counters export through OpenConfig mpls AFT (Abstract Forwarding Tree) YANG model.

This feature allows FDB export through the OpenConfig AFT YANG models. The streaming behavior of mac addresses are  Entries associated with SVI or L3 port have an associated VRF name. The VRF name is used to specify which network instance the FDB entry belongs to. 

This feature allows Octa to act as a collector for IPFIX and sFlow datagrams and to aggregate and stream the collected data in response to a gNMI subscription. Octa is a process in EOS which combines OpenConfig and certain TerminAttr functionality, primarily with the intent of servicing gNMI requests for OpenConfig paths and for "EOS native" paths.