Juniper: how to grow a juniper at home. How to write a mock server for Juniper switches

My name is Dmitriy, and I am a software developer of DCImanager — the equipment management panel by ISPsystem. I spent a long time on the team developing switch management software. Together we have experienced ups and downs: from development of hardware management services to failure of the office network and hours-long “dates” in the server room hoping not to lose your loved ones.

DCImanager supports different equipment types: switches, PDUs, and servers. The panel currently supports four switch handlers. Two handlers working via SNMP (Cisco Catalyst and snmp common) and two more via NETCONF (Juniper with and without ELS support).

All activities with equipment are heavily covered with testing. Using actual equipment for automatic testing does not work: tests are launched at each push to repository and run in parallel. Therefore, we try to use emulators.

We were able to cover the SNMP protocol handlers with tests by using the SNMP Agent Simulator library. But in case of Juniper, we ran into problems. After looking for ready-made solutions, we chose a couple of libraries, but one of them did not start, and the other was not doing the right thing — I actually spent more time trying to bring that little wonder to life.

So, the question was how to emulate Juniper switches? Juniper runs on NETCONF, which, runs over SSH. The idea of writing a small service that would work over SSH and emulate the switch came to mind. Accordingly, we needed the service itself as well as a Juniper "snapshot" for data emulation.

We are now actively developing a whole “zoo” of handlers for different switches. Soon we will have new switch handlers, but not all of them will be covered with ready-made testing solutions. However, we can try to write a base architecture of the service that will simulate different devices on different protocols.

In the simplest case — a factory, which depending on the protocol and the handler (some switches can run on several protocols), will return the switch object, in which all logic of its behavior will already be implemented. In the case of Juniper, it is a small query parser. Depending on the incoming rpc query with parameters, it will perform the necessary actions.

Important restriction: we will not be able to fully simulate operation of the switch. It will take a long time to describe all the logic, while if we add new functionality to the actual switch handler, we will also have to adjust the switch's mock server.

Our eye fell on paramiko library that provides a convenient interface for working via SSH. To begin with, we wanted to check the basic things, such as connection and some simple query, instead of breaking down the architecture. We are doing research here, after all. So, we did not concern ourselves with authorization: a combination of simple ServerInterface and a socket server gave us something like a working option:

When the client connects to the server, the latter should respond with a list of its capabilities. For example:

In case you wondered, the code is unstable. This implementation has the problem of socket closure. I was able to find a couple of registered issues in paramiko with this problem. We put this option aside, and decided to check the remaining opportunity.

The ace up our sleeve was Twisted. This is a network application development framework, which supports a large number of protocols. It has extensive documentation and the fantastic Cred module that would help us.

Credis an authentication mechanism that allows different network protocols to connect to the system depending on your requirements.

To organize the entire logic, Realm was used — the part of the application responsible for business logic and access to its objects. However, first things first.

The core of the system login is Portal. If we want to write a service on top of the network protocol, we need to define the standard Portal. It already includes methods:

A Realm object is used to connect the business logic to the authentication system. Since the client is already authorized, the logic of our service over the SSH starts here. This interface has only one requestAvatar method, which is requested upon successful authorization in Portal and returns the main object - SwitchProtocolAvatar:

Special objects — Avatars — are in charge of managing the business logic. In our case, the service over the SSH starts here. When a query is sent, the data are brought into SwitchProtocolAvatar, which checks the query subsystem and updates the configuration:

Speaking of protocols. While bearing in mind that we are working with NETCONF, we proceed with execution. To write services on top of existing protocols and to implement our logic we use Protocol. The interface of this class is simple:

Here we start to wrap the layers of our nesting doll. Since we use a service on over SSH, we need to implement the SSH server logic. In it, we will specify keys for the server and processing modules for SSH services. Our interest in implementation of this class is limited, since the authorization will be password-based:

For SSH server to work it is necessary to determine the logic of sessions, which operates regardless of the protocol we decide to use or what interface is requested:

I have nearly forgotten about the switch handler itself. After all checks and authorizations, the logic moves on to the object that emulates the switch. Here you can set the query processing logic: receiving or editing interfaces, device configuration etc.

And finally we join it all together. The session adapter is registered (which describes the behavior upon connection), the connection method by username and password is defined, the Portal is configured and our service is launched:

The query result is provided below. We have successfully established the connection and the server delivered us the list of its capabilities:

This solution has its pros and cons. On the one hand, we spend a lot of time on implementation and description of the whole logic of query processing. On the other hand, we gain flexible configuration and behavior emulation. However, the key advantage is scalability. The Twisted framework has rich functionality and supports a large number of protocols, so you can easily describe new switch handlers’ interfaces. And if you think everything through well enough, this architecture can be used not only for working with switches, but also for other equipment.

Feedback from readers would be strongly appreciated. Have you done anything similar and if so, what technologies were used and how did you set up the testing process?