In-network programmability we abandoned the CLI in favor of the API, but what transport protocol do we use? In my journey, I have typically utilised REST, Netconf, RESTconf and even a bit of CLI scraping down an SSH connection when needed to. One of the more relatively recent additions to the network programmability party is gNMI.
gNMI is developed on top of Googles open-source gRPC framework. It leverages Googles protobuf messaging format and HTTP2 to achieve speeds 7-10 times faster than a REST transaction.
The following RPC’s are supported as per the gNMI Specification:
- Capabilites – (used to gain understandaing of the targets capabilities)
- Get – (used to retrieve snapshots of the data on the target )
- Set – (used to modify data on a target)
- Subscribe – (used to control subscriptions to the taget, typically used in streaming telemetry)
gNMI is implemented by a number of network vendors across various platforms, I will be looking at Aristas implementation in their containerized EOS platform.
The following configuration enables the gNMI interface over the default Arista port of 6030
In order to gain a list of the capabilities of the target and its supported data models, we can use the gnmic cmdlet directly from bash, we use the insecure flag to indicate that the target is not using TLS transport (as this is a lab)
In the output we can see that the platform supports lots of data models, mainly in the native Arista and Openconfig formats
I have chosen to work with the openconfig format. As this demo will be focusing on working with an ACL, I have chosen the ACL Openconfig model, however, this model will be relative to whatever your use-case is.
One of the things I have learnt about working with YANG, is that in its raw format it isn’t easy on the eye – determining the paths to a resource can be very time consuming without the correct tooling, I recommend the usage of YANG catalog or pyang to get a better feel for the actual model of the path required.
Arista makes their platforms supported YANG models available online and this works a treat with pyang.
pyang is a really useful tool for visualizing YANG models, navigate to the dir of the yang model in question (in our case /openconfig/public/release/models/acl) and issue the command pyang -f tree <model> to view the model in a tree format.
from the above format, we are able to deduce the correct path to our resource by following the hierarchy provided by pyang.
In order to view the source address of sequence number 10 in our ACL ‘test123’ the path would be as follows:
/acl/acl-sets/acl-set[name=test123]/acl-entries/acl-entry[sequence-id=10]/ipv4/config/source-address
Now we know the path, we could use the gnmic command line tool again to pull the data back, however – let’s use the python library pygnmi to create a simple script to return the data we are interested in.
We instantiate a session of gNMIclient by feeding it that data relevant to our target.
We connect to our target by issuing the .connect() method.
Once connected we can issue a ‘get’ RPC (as defined in the gNMI specification) in this RPC we issue the path of the resource we are interested in, as deduced from the chosen YANG model
We get the below data returned from the request (I have leveraged the json standard library to make the original output a bit more readable)
In order to modify the device configuration, we can use the ‘set’ RPC that is defined in the gNMI specification to ‘replace’ or ‘update’ the configuration, the highlighted differences are defined in the specification
In the above script, we are replacing the existing source address with our new source as defined in the variable newsource, we are then getting the source address with a get RPC to validate the change.
We can see the output as below!
Conclusion
gNMI is (relatively) new, fast, and for the most part – pretty well documented, from what I have seen so far. YANG takes a bit of getting used to but with the correct tooling, it isn’t impossible.
Supposedly where gNMI really shines in in streaming telemetry with its subscribe RPC – this is something that I want to look into in a future post along with other network observability technologies.
Key tools for working with gNMI:
- gnmic
- pygnmi (if you are a python dev)
- pyang (for visualising those yang models)
- vendor documentation (Thanks Arista! – I cant comment on other vendors comprehensiveness as of yet…)
RouteDefault: Musings of a Network Engineer 