Operation mode plumbing in the Junos system
Understanding management system internals and operational command flow.
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.
Learn faster. Dig deeper. See farther.
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.
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 CLI command) is a prototypical example of the
authorization
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.
Note
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.