Juniper Extension Toolkit (JET), an evolution of the Junos SDK, provides a modern programmatic interface that makes programming simple, flexible, and extensible.
gRPC: JET uses interface definition language (IDL)-based frameworks provided by GRPC, which is licensed under a three-clause BSD. By default, gRPC uses protocol buffers based on the IDL used for serializing data. For a detailed overview, refer to the guide here.
MQTT: MQTT (formerly, Message Queue Telemetry Transport) is a publish-subscribe-based “light-weight” messaging protocol for use on top of the TCP/IP protocol.
For more details, see http://mqtt.org/.
Multiple languages (Python, C, C++, Java, Ruby, GO, C#) are supported.
Mosquitto is an open source, BSD-licensed project, which implements MQTT protocol versions 3.1 and 3.1.1.
See http://mosquitto.org/ for more details about Mosquitto.
Ease of use
Support for various deployment models
Junos OS release agnostic
Extensive API documentation is provided in the Juniper TechLIbrary:
JET Client Libraries (Valid Through Junos OS Release 16.1)
The JET client package consists of Python APIs for different services such as Route, Interfaces, Firewall, and Notifications.
Yes. Application developers can choose to directly use Thrift IDL and develop the application in the required programing language that Thrift supports.
However, application developers will need to take care of:
JET IDL Package
JET IDL packages can be found on the Juniper Software download page. On this page, choose the version from the drop-down menu on the right.
JET IDL files are proto definitions of various services that JET offers. Check the gRPC guide to learn more about proto IDLs. These IDLs can be used to generate Python or C++ code, which can be linked by the user to develop applicaitons. More about the generation of applications are available in the videos on this website. More details on the entire workflow can be found here: API Guide.
JET Client APIs
Does JET provide any tracing in client libraries?No. Application developers can choose to use the off-the-shelf Python tracing library for debugging purposes.
Why does JET not provide any event-based programing framework like Twisted in Python or libevent in C?JET is meant to be simple and flexible and to provide the required APIs to program a Juniper Networks device. Application developers are free to choose the required framework for event-based programming.
Can I write my own service and deploy it on a Juniper Networks device?Yes. The JET framework provides the flexibility to add new custom services. View the JET App Store for various examples.
JET Application Build and Packaging
Details on the development environment and workflow are provided at the following links:
An app can be deployed either on a device running Juons (“on-box”) or on an external machine (“off-box”).
To package an app for off-box deployment, the user can use any packaging and installation procedure appropriate for the language used to create the app.
To package an app for on-box deployment, if the app doesn’t have any dependency on C/C++ libraries and if the app need not be signed,use standard python distutils procedure. And it should be installed on Junos device using ‘request system software add <package-name>’ operational command.
Click Requesting Certificate Using the JET IDE for more information.
For 16.1, JET provides APIs which utilize a secured transport channel by establishing an SSL channel between the host running a JET client application and the Juniper Networks device. User-based authentication and authorization are also implemented to invoke service APIs. Refer to the OpenRequestResponseSession API in the documentation to further understand the functionality.
For 16.2, the config to start JET on device, we need to mention the below
set system services extension-service request-response grpc ssl address 0.0.0.0set system services extension-service request-response grpc ssl local-certificate mycertset security certificates local mycert load-key-file <key-file-name>
From application side, use the secure channel with server authentication SSL/TLS as mentioned in this google guide: http://www.grpc.io/docs/guides/auth.html
JET client API – OpenRequestResponseSession provides the abstraction to take care of authentication and authorization. Authentication is ensured by securing the channel through SSL between the Juniper Networks device and the host where the application was run; a valid Junos user with the maintain level is allowed to execute JET APIs. OpenRequestResponseSession is valid only for 16.1 release. From 16.2 release onwards, user will need to do everything from IDL.
Not required. If the JET application developer wants to authenticate a user, the OpenRequestResponseSession API should be the first call with the JET handler created. When the OpenRequestResponseSession call is successful, any subsequent API invokation using that handler does not require any authentication.
Note: Performance of an API differs between a secure and insecure channel, with the latter giving better performance. It is the application developer’s discretion to choose between the two.
For the 16.1 release, if you are using IDL-generated stubs directly for client language bindings other than Python, you should port the OpenRequestResponseSession Python API implementation to the required language bindings. The OpenRequestResponseSession API needs to do the following key processing internally:
For the 16.2 release we need to say the following:
JET applications built on IDL packages from Junos OS Release 16.2R1 onward will continue to work on future releases unless the API signatures undergo critical changes. All these changes will be documented in subsequent IDL package releases.