Junos Automation Communication Standards
Netconf is a standards-based network configuration protocol. Provides an API on network devices to get and modify configuration and obtain operational data.
Defined in RFC 6241
Implemented by many vendors – not designed by Juniper
It’s architecture is split into four different layers:
Transport: SSH, HTTPS, TLS
Messages: <rpc>, <rpc-reply>, <notification>
Operations: <get-config>, <edit-config>, <commit-config>, custom RPCs
Content: Configuration Data, RPC input/output, Notification content
Messages Layer:
<rpc> encapsulates all RPCs to the NETCONF server. Includes both operational mode RPCs and configuration RPCs (RPCs are XML tagged remote procedure calls)
This is a message that is sent FROM the client (your computer) to the Server (maybe a Router or a switch) – containing operational commands or config changes.
<rpc reply> is a reply to the RPC that encapsulates rpc messages sent FROM the netconf server (Router) to the client (computer) in reply to RPC messages/changes requested in <rpc>. Includes data retrieved and confirmation and messages.
<notification> sent to a client who initiated a subscription. (as the client you can subscribe to events from your netconf server and when events that you subscribe to happen you (or your program) can be alerted.
<create-subscription> is used to subscribe to event notifications.
These are sent from the NETCONF server to the client.
Operations Layer:
Including list of Operations layer commands you can use in Junos since they are kind of hard to find – and what they are for:
- <lock> (lock and unlock the config file for edit exclusive)
- <unlock>
- <get> (both this and get-config are for getting operational info)
- <get-config> (or getting the configuration database)
- <edit-config> (editing the config)
- <copy-config> (copying the config)
- <commit> (committing a configuration change)
- <discard-changes> (discarding our changes same as rollback 0)
- <delete-config> (deleting some configuration)
- <validate> (validating or doing a commit-check)
- <create-subscription> (creating our subscription for notifications)
- <close-session> (for when we want to close our own session)
- <kill-session> (lets us kill another users session, maybe it’s stuck)
Content Layer
Contains the actual request/response payload (along with configuration data) So if you are asking for config changes to be made, this is where that actual information you want applied will be.
Enabling NETCONF
Netconf SSH sessions use TCP port 830 by default
Configured in the [edit system services] configuration hierarchy
You can choose which port you would prefer to use.
root@R1> configure
Entering configuration mode
[edit]
root@R1# edit system services
[edit system services]
root@R1# set netconf ssh
[edit system services]
root@R1# show
ssh {
root-login allow;
}
netconf {
ssh;
}
Netconf termination symbol: ]]>>]]
So as a test, now that has been enabled we can try and run a netconf session from the console and return some information (show chassis inventory):
XML and NETCONF
XML Schema – concepts and notation
XML: eXtensible Markup Language both on box and off box automation. Core to the Junos automation stack. Even at the CLI when we are typing commands the xml is being changed. – XML is a standards based markup language.
Similar to HTML XML has opening and closing tags:
<name> Content </name>
If an element is empy it can be shortened into a single tag:
<name/> == <name></name>
XML uses a heirarchical structure. So there can be tags within tags (e.g. <rpc><get-chassis-inventory/></rpc>) – multiple heirarchical levels can exist with multiple levels at each level.
Element Node: everything in between opening and closing tags (think indented blocks in python). – also known as the document node if it includes the whole xml document.
It’s everything in between any arbitrary opening and closing tag.
Namespaces – XML element nodes should have unique names and this ensures this, multiple namespaces are allowed.
e.g.
<course xmlns=”http://testsite.com/xmlns” xmlns:illustrate=”http://testsite.com/otherthing”>
XSD files: defines the XML file data structure – they determine which nodes are allowed to have what kind of data.
They determine whether these nodes are required or not, and what the rules are for the elements in these nodes.
They allow you to create XML files that are consistent in formatting and in content – essentially creating a standard format using standard tags.
These files are written in XML format.
Junos XML API
How Junos uses XML
When we enter commands in the CLI, the cli converts our commands into XML RPCs. The responses are also recieved in XML and the CLI then converts these responses into plaintext to make it easier for the network engineer to read it. We can see what the XML the request actually looks like by appending the command we are using with | display xml rpc
The XML reply also comes back via the CLI, which converts it into more human readable plaintext on the screen.
Options for interfacing with the Junos XML API
| On-Box Language Options | Off-Box Language Options |
| Python | Python |
| XLST | C (and C derivitives) |
| SLAX | Ruby |
| Perl | |
| Java | |
| Go | |
| PHP | |
| Pretty much any language |
XSLT – eXtensible Stylesheet Language Transformtaions
This is used explicitly for XML to XML transformations. It is a standards based language (w3c) and is used for on box scripting.
Has many of the functions of a standard programming language (If-Then, Loops, Finding specific nodes).
XSLT is often used for commit scripts. It takes an XML input document (usually the candidte configuration as the input document) The XSLT Script is then run by the XSLT engine, and the engine then outputs an alternative XML output document.
SLAX is a Juniper created language, and is a pre-processor to XSLT. SLAX translates directly into XSLT but is written in a different way. It is syntaxically similar to C.
Python – Used for both on-box and off-box scripting
Junos PyEX is preinstalled on some Junos boxes.
Python 2.7 was included on some platforms from Junos OS 18.1R1
Python 3 is included for SRX, EX, QFX, MX, ACX and PTX from 19.4R1
XPath
Navigating XML Documents with XPath
XML Data Model includes different data / node types:
Element Nodes: Everything between an opening tag and a closing tag.
Text Nodes: The data that is within the Element Node
Document Node: Everything within the XML document
Attribute Nodes: Nodes contained within the actual tag of an element node. In Junos we will always see our attribute nodes within the <configuration> tag (e.g. <configuration junos:commit-user”root”>) In this attribute node we can see the last time our config was committed, and who by.
Generally Text nodes are used to store data, and attributes are used for metadata.
XML XPath Language
XPath Axes
Ancestor – This is anything more than one level above self
Parent(..) – One level above self (../../ takes you to the parents parent)
Self(.)
Sibling -nodes at the same hierarchical level (with the same parent)
Child – One level below self
Descendent -More than one level below self
Operators
Logical: AND, OR
Comparators: =, !=, <, >
Arithmetic +, -, *
Node referencing is similar to Unix-Style navigation
If there are multiple nodes that have the same structure (maybe 2 interfaces both with descriptions) you can use square brackets for selection criteria of what you’d like returned. The criteria can be any node.
e.g.:
./interfaces/interface/unit[name==’1′]/description
XML Attributes
An element is something contained in the path, and is referenced by the tag name.
An attribute is something that is inside the actual tag, and are referenced using the @symbol.
attribute ref for commit-user ./configuration/@junos:commit-user
Attributes to remember:
junos:changed refers to an attribute that has been changed in the candidate configuration.
junos:group refers to an attribute that has been inherited from a configuration group.
LAB – Like most Juniper content here these are the notes I have made while studying for this cert using Ben Jacobson’s course (accessible here and well worth the money) – this lab is from him but it’s so useful and such a good base that I’m uploading screenshots of the output here for my personal reference later.
When this code is run without any arguments (in the code if there is no arg then it just puts it to ./ (self)) it returns the whole XML file for the vsrx I’m using.
But when you specify the argument it returns the element node requested and the enclosed Text Node.
And when asking for a particular attribute it can be referenced too from the script.
