Troubleshooting, Auditing, and Reporting

By Erdem posted 08-06-2015 05:01



Retrieving operational and configuration data in tables and views.



Extracting data from the network is necessary for common troubleshooting, reporting, and auditing automation tasks.  Often these tasks involve examining both the configuration of one or more devices as well as the running state (operational data).  Junos PyEZ attempts to make this extraction process as easy as possible so that the user can focus on the task at hand, and not on the device-specific implementation details.


Operational Data and Configuration

Operational data, sometimes called "run-state" data, refers to the current running conditions of the device, and not its configuration. For example, you might configure an interface to use OSPF, but the neighbor connection status is operational data. From the Junos OS CLI, operational data is displayed using show commands, for example, show ospf neighbor.


You will often need to correlate both the configuration and operational state when performing such tasks.  For example, you might need a list of the configured OSPF interfaces to determine if the operational state is complete or correct.  In these workflows (use-cases), you are accessing the Junos OS configuration in a read-only  way.


Junos PyEZ has been optimized to make the extraction of both configuration and operational information as easy as possible.  This is done though the use of tables and views.





The concept of a table is nothing new, taking it from the world of databases. So if you think of the Junos OS as having an "operational database," then that database contains a collection of tables.


For example the show route command could provide the route table and theshow interfaces media [fgx]e* command could provide the Ethernet port table.


Each table has a collection of items (database records). Each item has a unique key (name). The item data can be examined as a view.



Think of a view in the same way you would think of the Junos OS CLI display-options of brief,terse,detail, and extensive. The underlying data (table record) that Junos OS uses is the same (XML). The Junos OS CLI simply applies a different view to that data and renders the data in human readable form (in CLI output).


The purpose of a view in the Junos PyEZ library is to present the table item fields in a native Python syntax. By doing this, the user does not need to know anything specific about Junos OS or the underlying Junos OS XML API.



The following Python shell output illustrates using the EthPortTable Table and View widgets.  These Table and View widgets are defined in YAML so there is no actual coding required to create these widgets.


01 >>> from jnpr.junos.op.ethport import EthPortTable
02 >>> eths = EthPortTable(dev)
03 >>> eths.get()
04 EthPortTable:jnpr-dc-fw: 3 items
05 >>> eths.keys()
06 ['ge-0/0/0', 'ge-0/0/1', 'ge-0/0/2']
07 >>> e1 = eths['ge-0/0/1']
08 >>> pp( e1.keys() )
09 ['oper',
10  'rx_packets',
11  'macaddr',
12  'rx_bytes',
13  'admin',
14  'mtu',
15  'running',
16  'link_mode',
17  'tx_bytes',
18  'tx_packets',
19  'present']
20 >>> pp( e1.items() )
21 [('oper', 'up'),
22  ('rx_packets', '9670'),
23  ('macaddr', '00:0c:29:eb:a2:c1'),
24  ('rx_bytes', '1103939'),
25  ('admin', 'up'),
26  ('mtu', 1518),
27  ('running', True),
28  ('link_mode', 'Full-duplex'),
29  ('tx_bytes', '0'),
30  ('tx_packets', '0'),
31  ('present', True)]
32 >>> e1.macaddr
33 '00:0c:29:eb:a2:c1'
34 >>> e1.oper
35 'up'