Sample NETCONF Session

After the client application establishes a connection to a NETCONF server, the two exchange <hello> tag elements, as shown in the following example. For legibility, the example places the client application’s <hello> tag element below the NETCONF server’s. The two parties can actually emit their <hello> tag elements at the same time. For information about the ]]>]]> character sequence used in this and the following examples, see Generate Well-Formed XML Documents. For a detailed discussion of the <hello> tag element, see Start a NETCONF Session.

The client application emits the <get-chassis-inventory> tag element to request information about the device’s chassis hardware. The NETCONF server returns the requested information in the <chassis-inventory> tag element.

The client application then prepares to incorporate a change into the candidate configuration by emitting the <lock/> tag to prevent any other users or applications from altering the candidate configuration at the same time. To confirm that the candidate configuration is locked, the NETCONF server returns an <ok/> tag in an <rpc-reply> tag element.

The client application now emits tag elements to create a new Junos OS login class called network-mgmt at the [edit system login class] hierarchy level in the candidate configuration. To confirm that the load operation was successful, the NETCONF server returns an <ok/> tag in an <rpc-reply> tag element.

The client application then commits the candidate configuration. To confirm that the commit operation was successful, the NETCONF server returns an <ok/> tag in an <rpc-reply> tag element.

The client application unlocks (and by implication closes) the candidate configuration. To confirm that the unlock operation was successful, the NETCONF server returns an <ok/> tag in an <rpc-reply> tag element.

The client application closes the NETCONF session by emitting the <close-session> tag.