Example of a NETCONF Session

This section describes the sequence of tag elements in a sample NETCONF session. The client application begins by establishing a connection to a NETCONF server. See the following sections:

Exchanging Initialization Tag Elements

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 Generating Well-Formed XML Documents. For a detailed discussion of the <hello> tag element, see Exchanging <hello> Tag Elements.

Sending an Operational Request

The client application now 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.

Locking the Configuration

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. For more information and locking the configuration, see Locking the Candidate Configuration.

Changing the Configuration

The client application now emits tag elements to create a new Junos login class called network-mgmt at the [edit system login class] hierarchy level in the candidate configuration. To confirm that it incorporated the changes, the NETCONF server returns an <ok/> tag in an <rpc-reply> tag element. (Understanding the meaning of these tag elements is not necessary for the purposes of this example, but for information about them, see Changing Configuration Information.)

Committing the Configuration

The client application commits the candidate configuration. To confirm that it committed the candidate configuration, the NETCONF server returns an <ok/> tag in an <rpc-reply> tag element. For more information about the commit operation, see Committing the Candidate Configuration.

Unlocking the Configuration

The client application unlocks (and by implication closes) the candidate configuration. To confirm that it unlocked the candidate configuration, the NETCONF server returns an <ok/> tag in an <rpc-reply> tag element. For more information about unlocking a configuration, see Unlocking the Candidate Configuration.

Closing the NETCONF Session

The client application closes the NETCONF session. For more information about closing the session, see Ending a NETCONF Session and Closing the Connection.