Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Sample NETCONF Session

The following sections describe the sequence of tag elements in a sample NETCONF session with a device running Junos OS. The client application begins by establishing a connection to a NETCONF server.

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 Generate Well-Formed XML Documents. For a detailed discussion of the <hello> tag element, see Start a NETCONF Session.

XML-based NETCONF exchange showing client and server hello messages listing capabilities for protocol compatibility.

Sending an Operational Request

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.

Client Application sends XML request to NETCONF Server for chassis inventory. Server responds with XML including chassis name, serial number, and module details.

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.

Illustration of a NETCONF client sending an XML-based rpc request with a lock operation to a server, receiving an rpc-reply with an ok element.

Changing the Configuration

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.

XML communication between a client and NETCONF server to edit candidate configuration. Client edits login under system with class network-mgmt and permissions configure, snmp, system. Server replies with rpc-reply and ok status.

Committing the Configuration

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.

Client app sends XML `<rpc>` with `<commit/>` to NETCONF server; server replies with `<rpc-reply>` `<ok/>` success, part of network config protocol.

Unlocking the Configuration

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.

Client application sends XML-based rpc request with unlock operation to NETCONF server, which replies with ok in rpc-reply message.

Closing the NETCONF Session

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

Client Application requests session closure using close-session XML tag; NETCONF Server replies with rpc-reply XML message indicating success with ok tag.