-
Beginning with Cisco NX-OS Release 9.3(5), Get and Set are supported.
-
gNMI queries do not support wildcards in paths.
-
When you enable gRPC on both the management VRF and default VRF and later disable on the default VRF, the gNMI notifications
on the management VRF stop working.
As a workaround, disable gRPC completely by entering the no feature grpc command and reprovision it by entering the feature grpc command and any existing gRPC configuration commands. For example, grpc certificate or grpc port . You must also resubscribe to any existing notifications on the management VRF.
-
When you attempt to subscribe an OpenConfig routing policy with a preexisting CLI configuration like the following, it returns
empty values due to the current implementation of the OpenConfig model.
ip prefix-list bgp_v4_drop seq 5 deny 125.2.0.0/16 le 32
ipv6 prefix-list bgp_v6_drop seq 5 deny cafe:125:2::/48 le 128
using the xpath
openconfig-routing-policy:/routing-policy/defined-sets/prefix-sets/prefix-set[name=bgp_v4_drop]/config
openconfig-routing-policy:/routing-policy/defined-sets/prefix-sets/prefix-set[name=bgp_v6_drop]/config
-
Only server certificate authentication takes place. The client certificate is not authenticated by the server.
-
If the gRPC certificate is explicitly configured, after a reload with the saved startup configuration to a prior Cisco NX-OS
9.3(x) image, the gRPC feature does not accept connections. To confirm this issue, enter the show grpc gnmi service statistics command and the status line displays an error like the following:
Status: Not running - Initializing...Port not available or certificate invalid.
Unconfigure and configure the proper certificate command to restore the service.
-
Beginning with Cisco NX-OS Release 9.3(3), if you have configured a custom gRPC certificate, upon entering the reload ascii command the configuration is lost. It reverts to the default day-1 certificate. After entering the reload ascii command, the switch reloads. Once the switch is up again, you must reconfigure the gRPC custom certificate.
Note
|
This applies when entering the grpc certificate command.
|
-
Use of origin, use_models, or both, is optional for gNMI subscriptions.
-
gNMI Subscription supports Cisco DME and Device YANG data models. Beginning with Cisco NX-OS Release 9.3(3), Subscribe supports
the OpenConfig model.
-
For Cisco NX-OS prior to 9.3(x), information about supported platforms, see
Platform Support for Programmability Features in the guide for
that release. Starting with Cisco NX-OS release
9.3(x), for information about supported platforms, see the Nexus Switch Platform Matrix.
-
The feature supports JSON and gnmi.proto encoding. The feature does not support protobuf.any encoding.
-
Each gNMI message has a maximum size of 12 MB. If the amount of collected data exceeds the 12 MB maximum, the collected data
is dropped. Applies to gNMI ON_CHANGE mode only.
You can avoid this situation by creating more focused subscriptions that handle smaller, more granular data-collection sets.
So, instead of subscribing to one higher-level path, create multiple subscriptions for different, lower-level parts of the
path.
-
Across all subscriptions, there is support of up to 150K aggregate MOs. Subscribing to more MOs can lead to collection data
drops.
-
The feature does not support a path prefix in the Subscription request, but the Subscription can contain an empty prefix field.
-
The gRPC process that supports gNMI uses the HIGH_PRIO control group, which limits the CPU usage to 75% of CPU and memory
to 1.5 GB.
-
The
show grpc gnmi
command has the following considerations:
-
The gRPC agent retains gNMI calls for a maximum of one hour after the call has ended.
-
If the total number of calls exceeds 2000, the gRPC agent purges ended calls based on the internal cleanup routine.
The gRPC server runs in the management VRF. As a result, the gRPC process communicates only in this VRF forcing the management
interface to support all gRPC calls.
gRPC functionality now includes the default VRF for a total of two gRPC servers on each switch. You can run one gRPC server
in each VRF, or run only one gRPC server in the management VRF. Supporting a gRPC in the default VRF adds flexibility to offload
processing gRPC calls from the management VRF, where significant traffic load is not desirable.
フィードバック