Pipes (source: Dyanap via Pixabay)

It is helpful to have a good understanding of the way "management data" usually flows through the Junos system. Some examples of the types of management data that may flow through a system include configuration information, operational commands, and statistics. Having a good understanding of this management data flow will help you understand the distinctions between various methods of accessing this data.

As we look at the flow of management data, you will see that the management daemon (MGD) is a central hub of activity. Most management data flows through MGD. The Junos software accepts management connections through a variety of mechanisms; however, most eventually turn into Junoscript or NETCONF sessions that connect to MGD. MGD has three primary mechanisms for interacting with daemons: a management socket (which it uses to pass along operational command requests and responses), the shared configuration database, and Unix signals.

Accessing the Management System

Let's start with ways of accessing the management system. Here, all roads lead to MGD.

All CLI sessions invoke a binary (coincidentally, named cli) that is a Junoscript client. The CLI binary opens a Junoscript session with MGD and exchanges information with MGD in an XML format.

It is also possible for a user to interact with the Junos software using a NETCONF or Junoscript session. These sessions also connect to MGD.

Additionally, a user can interact with the Junos software using the REST API. As described in not available, these sessions are piped through some extra plumbing, but eventually reach MGD.

Finally, it is possible for a user to interact with the Junos software using PyEZ, or to have op, commit, or event scripts launch remote procedure calls (RPCs). In all of these cases, a Junoscript or NETCONF session is used to connect to the software. Again, these Junoscript or NETCONF sessions all terminate with MGD.

Figure 1-1 illustrates how these various connection mechanisms all eventually wind up as sessions connected to MGD.

Figure 1-1. Figure 1-1. Various management connections that connect to MGD

Operational Command Flow

Operational commands arrive at MGD over one of the connection methods just described. When MGD receives the operational commands, it can either satisfy them itself, pass them along to other daemons to satisfy the requests, or invoke other tools to satisfy the requests.

For example, the get-authorization-information RPC (which is equivalent to the show cli authorization CLI command) is a prototypical example of the kind of request MGD fulfills itself. With this command, the user is asking for information about her authorization level. This is information that MGD maintains for each session, and it is easy for MGD to satisfy this request itself. (Another prototypical example in this category is the get-configuration RPC, or the show configuration CLI command. Again, this request is asking for information that MGD maintains internally.)

Two classic examples of the kinds of operational commands that are passed on to a daemon are the get-route-information RPC (equivalent to the show route CLI command) and the clear-bgp-neighbor RPC (equivalent to the clear bgp neighbor CLI command). In both cases, the routing protocol daemon (RPD) is the daemon that satisfies this request. It is the daemon that maintains information on the routing table (also known as the routing information base, or RIB); therefore, it is the daemon that can authoritatively answer a request for route information. Likewise, RPD is the daemon that maintains BGP neighbor relationships; therefore, it is the daemon that handles a request to reset one of those relationships. In these cases, MGD serves as a two-way pipe, passing the request from the user to RPD and passing the response from RPD to the user. Figure 1-2 illustrates this data flow. To support this communication, MGD maintains a management socket with most daemons. Operational requests and responses flow over this management socket.

In a few cases, MGD invokes tools to satisfy requests. One example is the Junos upgrade process, which requires more complex handling than a normal CLI command. MGD invokes an external tool to conduct part of the upgrade. Another example is op and commit scripts, which are actually run by the CSCRIPT utility. This process is all transparent to the user, and is just included here for the sake of completeness.


As Figure 1-2 illustrates, some requests must go all the way to the packet forwarding engine (PFE) to be satisfied. Interface statistics are an example of this type of request. To gather interface statistics, MGD invokes ifinfo, which queries the kernel. The kernel often needs to query a PFE to obtain these statistics. In this way, operational commands sometimes have important impacts on the system.

Figure 1-2. Figure 1-2. Data flow between a user and a daemon
Article image: Pipes (source: Dyanap via Pixabay).