Using Junos PyEZ to Retrieve a Configuration

To retrieve the complete candidate configuration from a Junos device, execute the get_config() RPC. The default output format is XML. For example:

When a Junos PyEZ application uses the get_config() RPC to retrieve configuration information from a Junos device, by default, the server returns data from the candidate configuration database. A Junos PyEZ application can also retrieve configuration data from the committed configuration database or the ephemeral configuration database.

Candidate Configuration Database

To retrieve data from the candidate configuration database, execute the get_config() RPC, and optionally include any additional arguments.

Committed Configuration Database

To retrieve data from the committed configuration database, include the options argument with 'database':'committed' in the get_config() RPC call.

Ephemeral Configuration Database

Junos PyEZ supports operations on the ephemeral configuration database on devices that support this database. When you retrieve configuration data from the shared configuration database, by default, the results do not include data from the ephemeral configuration database.

Note:

The ephemeral database is an alternate configuration database that provides a fast programmatic interface for performing configuration updates on Junos devices. The ephemeral configuration database is an advanced feature which if used incorrectly can have a serious negative impact on the operation of the device. For more information, see Understanding the Ephemeral Configuration Database.

To retrieve data from the default instance of the ephemeral configuration database, first open the default ephemeral instance and then request the data. To open the default instance, use a context manager to create the Config instance, and include the mode='ephemeral' argument. For example:

To retrieve data from a specific instance of the ephemeral configuration database, first open the ephemeral instance and then request the data. To open a user-defined instance of the ephemeral configuration database, use a context manager to create the Config instance, include the mode='ephemeral' argument, and set the ephemeral_instance argument to the name of the ephemeral instance.

In addition to retrieving the complete Junos OS configuration, a Junos PyEZ application can retrieve specific portions of the configuration by invoking the get_config() RPC with the filter_xml argument. The filter_xml parameter takes a string containing the subtree filter that selects the configuration statements to return. The subtree filter returns the configuration data that matches the selection criteria.

To request multiple hierarchies, the filter_xml string must include the <configuration> root element. Otherwise, the value of filter_xml must represent all levels of the configuration hierarchy starting just under the root <configuration> element down to the hierarchy to display. To select a subtree, include the empty tag for that hierarchy level. To return a specific object, include a content match node that defines the element and value to match.

The following Junos PyEZ application retrieves and prints the configuration at the [edit interfaces] and [edit protocols] hierarchy levels in the candidate configuration:

The following example retrieves and prints the configuration at the [edit system services] hierarchy level using different but equivalent values for the filter_xml argument:

The following example retrieves the <name> element for each <interface> element under the <interfaces> hierarchy in the post-inheritance candidate configuration:

The following example retrieves the subtree for the ge-1/0/1 interface:

The Junos PyEZ get_config() RPC invokes the Junos XML protocol <get-configuration> operation, which can return Junos OS configuration data as Junos XML elements, CLI configuration statements, Junos OS set commands, or JavaScript Object Notation (JSON). By default, the get_config() RPC returns configuration data as XML.

To specify the format in which to return the configuration data, the Junos PyEZ application includes the options dictionary with 'format':'format' in the get_config() argument list. To request CLI configuration statements, Junos OS set commands, or JSON format, set the format value to text, set, or json, respectively.

As in NETCONF and Junos XML protocol sessions, Junos PyEZ returns the configuration data in the expected format enclosed within the appropriate XML element for that format. The RPC reply encloses configuration data in XML, text, or set command formats in <configuration>, <configuration-text>, and <configuration-set> elements, respectively.

Note:

Depending on the version of Python and the format of the output, you might need to modify the print statement to display more human-readable output.

You can load standardized or custom YANG modules onto Junos devices to add data models that are not natively supported by Junos OS but can be supported by translation. You configure nonnative data models in the candidate configuration using the syntax defined for those models. When you commit the configuration, the data model’s translation scripts translate that data and commit the corresponding Junos OS configuration as a transient change in the checkout configuration.

The candidate and active configurations contain the configuration data for nonnative YANG data models in the syntax defined by those models. Junos PyEZ applications can retrieve configuration data for standard and custom YANG data models in addition to retrieving the native Junos OS configuration by including the appropriate arguments in the get_config() RPC. By default, nonnative configuration data is not included in the get_config() RPC reply.

To retrieve configuration data that is defined by a nonnative YANG data model in addition to retrieving the Junos OS configuration, execute the get_config() RPC with the model argument, and include the namespace argument when appropriate. The model argument takes one of the following values:

• custom—Retrieve configuration data that is defined by custom YANG data models. You must include the namespace argument when retrieving data for custom YANG data models.

• ietf—Retrieve configuration data that is defined by IETF YANG data models.

• openconfig—Retrieve configuration data that is defined by OpenConfig YANG data models.

• True—Retrieve all configuration data, including the complete Junos OS configuration and data from any YANG data models.

If you specify the ietf or openconfig value for the model argument, Junos PyEZ automatically uses the appropriate namespace. If you retrieve data for a custom YANG data model by using model='custom', you must also include the namespace argument with the corresponding namespace.

If you include the model argument with the value custom, ietf, or openconfig and also include the filter_xml argument to return a specific XML subtree, Junos OS only returns the matching hierarchy from the nonnative data model. If the Junos OS configuration contains a hierarchy of the same name, for example "interfaces", it is not included in the reply. The filter_xml option is not supported when using model=True.

In the following example, the get_config() RPC retrieves the OpenConfig bgp configuration hierarchy from the candidate configuration on the device. If you omit the filter_xml argument, the RPC returns the complete Junos OS and OpenConfig candidate configurations.

The following RPC retrieves the interfaces configuration hierarchy from the candidate configuration for an IETF YANG data model:

The following RPC retrieves the l2vpn configuration hierarchy from the candidate configuration for a custom YANG data model with the given namespace:

The following RPC retrieves the complete Junos OS candidate configuration as well as the configuration data for other YANG data models that have been added to the device:

When you use the Junos PyEZ get_config() RPC to retrieve the configuration, it invokes the Junos XML protocol <get-configuration> operation. The RPC supports the options argument, which enables you to include a dictionary of key/value pairs of any attributes supported by the <get-configuration> operation. For the complete list of attributes supported by the Junos XML protocol <get-configuration> operation, see <get-configuration>.

For example, the get_config() RPC retrieves data from the pre-inheritance configuration, in which the <groups>, <apply-groups>, <apply-groups-except>, and <interface-range> tags are separate elements in the configuration output. To retrieve data from the post-inheritance configuration, which displays statements that are inherited from user-defined groups and ranges as children of the inheriting statements, you can include the options argument with 'inherit':'inherit'.

For example, the following code retrieves the configuration at the [edit system services] hierarchy level from the post-inheritance candidate configuration. In this case, if the configuration also contains statements configured at the [edit groups global system services] hierarchy level, those statements would be inherited under the [edit system services] hierarchy in the post-inheritance configuration and returned in the retrieved configuration data.

The Junos PyEZ get_config() RPC, by default, strips out any namespaces in the returned configuration data. Junos PyEZ applications can retain the namespace in the returned configuration data, which enables you to load the data back onto a device, such as when you want to quickly modify the existing configuration.

To retain namespaces in the configuration data, include the remove_ns=False argument in the get_config() argument list. For example:

In the following truncated output, the <bgp> element retains the xmlns attribute that defines the namespace:

If the get_config() remove_ns=False argument is omitted, the namespace is not included in the output.