With NETCONF-over-SSH happily configured on our network of JUNOS OS devices, we can now connect over the network and make RPCs in order to inspect the operational status of the device. Lets look at a couple of examples to learn the fundamentals of how the JUNOS OS XML RPCs work.

Ensure you've completed the JUNOS NETCONF-over-SSH setup recipe previously and have a working JUNOS OS device with a NETCONF interface in place. It doesn't necessarily matter what the configuration of that device is.

The steps for making NETCONF RPC requests and replies are as follows:

1. Connect to the NETCONF-over-SSH server in a similar manner to the previous recipe:

      unix$ ssh -i JUNOS_auto_id_rsa [email protected] netconf

2. Query the system ARP table by connecting to the NETCONF-over-SSH session in a similar manner to the previous recipe and issuing the appropriate RPC:

      <rpc><get-arp-table-information/></rpc>
      <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"    
      xmlns:JUNOS="http://xml.juniper.net/JUNOS/15.1F6/JUNOS">
      <arp-table-information    
      xmlns="http://xml.juniper.net/JUNOS/15.1F6/JUNOS-arp"    
      JUNOS:style="normal">
      <arp-table-entry>
      <mac-address> 
      0a:00:27:00:00:00
      </mac-address>
      <ip-address>
      10.0.201.1
      </ip-address>
      <hostname>
      adamc-mac
      </hostname>
      <interface-name>
      em0.0
      </interface-name>
      <arp-table-entry-flags>
      <none/>
      </arp-table-entry-flags>
      </arp-table-entry>
      </arp-table-information>
      </rpc-reply>
      ]]>]]>

3. Repeat the query, but use the format tag to modify the output to be a plain text:

      <rpc><get-arp-table-information format="text"/></rpc>
      <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"      
      xmlns:JUNOS="http://xml.juniper.net/JUNOS/15.1F6/JUNOS">
      <output> 
      MAC Address Address Name Interface Flags
      0a:00:27:00:00:00 10.0.201.1 adamc-mac em0.0 none
      </output>
      </rpc-reply>
      ]]>]]>

4. Use an option to the ARP table RPC in order to disable the name resolution:

   <rpc><get-arp-table-information format="text"><no-resolve/></get-   
   arp-table-information></rpc>
   <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"    
   xmlns:JUNOS="http://xml.juniper.net/JUNOS/15.1F6/JUNOS">
   <output>
   MAC Address Address Interface Flags
   0a:00:27:00:00:00 10.0.201.1 em0.0 none
   </output>
   </rpc-reply>
   ]]>]]>

5. Query the system routing table and inspect the output:

   <rpc><get-route-information/></rpc>
   [...]

6. Repeat the system routing table query, but apply an argument for a particular destination:

   <rpc><get-route-information>  
   <destination>10.0.201.201</destination></get-route-information>  
   </rpc>
   [...]

In steps 1 and step 2, we connected and issued a simple RPC to query the ARP table from the router. The rather verbose XML response encodes structure that is the machine-readable version of what we see in the CLI when we issue the show arp command. Each data atom is enclosed hierarchically within XML tags indicating its type and any associated properties. This structured output format lends itself particularly well for machine-to-machine automation applications.

In step 3, we issued the same RPC, but requested JUNOS OS to give us the plain text output so that we could compare the difference. In almost all cases, the plain text output seen when we use the format="text" modifier to the RPC is identical to what we would see in the CLI.

In step 4, we see how options to the CLI commands are encoded within the XML RPC format. In this case the show arp no-resolve option is typically used to prevent any name resolution of IP addresses. It's simply an XML subtag to the main <get-arp-table-information> tag.

Steps 5 and 6 go a step further looking at the RPC that implements the show route command. In step 5, we show how arguments are added to the RPC.

Looking at these example RPCs and the XML format within, we can see two clear styles. One pairs together the opening and closing tags in a strict manner, allowing the inclusion of options and arguments. The other allows an abbreviation of an otherwise empty pair of tags by simply using a leading slash. Compare the following two RPCs, which are identically supported by the JUNOS OS XML NETCONF interpreter:

<rpc><get-route-information/></rpc>
<rpc><get-route-information></get-route-information></rpc>