[Contents] [Prev] [Next] [Index] [Report an Error]

# 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
- Sending an Operational Request
- Locking the Configuration
- Changing the Configuration
- Committing the Configuration
- Unlocking the Configuration
- Closing the NETCONF Session

## 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.

NETCONF Server | Client Application
--- | ---
<hello> <capabilities> <capability>urn:ietf:params:xml:ns:netconf:base:1.0</capability> <capability>urn:ietf:params:xml:ns:netconf:capability:candidate:1.0</capability> <capability>urn:ietf:params:xml:ns:netconf:capability:url:1.0?candidate:1.0</capability> <capability>http://xml.juniper.net/netconf/junos/1.0</capability> <capability>http://xml.juniper.net/netconf/junos/sdx/1.0</capability> </capabilities> <session-id>3911</session-id> </hello> ]]>]]>
| <hello> <capabilities> <capability>urn:ietf:params:xml:ns:netconf:base:1.0</capability> <capability>urn:ietf:params:xml:ns:netconf:capability:candidate:1.0</capability> <capability>urn:ietf:params:xml:ns:netconf:capability:url:1.0?candidate:1.0</capability> <capability>http://xml.juniper.net/netconf/junos/1.0</capability> <capability>http://xml.juniper.net/netconf/junos/sdx/1.0</capability> </capabilities> </hello> ]]>]]>

## Sending an Operational Request

The client application now emits the <get-system-info> tag element to request information about the C Series Controller’s chassis hardware. The NETCONF server returns the requested information in the <system-info> tag element.

Client Application | NETCONF Server
--- | ---
<rpc> <get-system-info/> </rpc> ]]>]]> |
| <rpc-reply xmlns=”URN” xmlns:sdx=”URL” > <system-info> <cpu> <!-- other tags for <cpu> --> </cpu> <!-- other tags for <system-info> --> </system-info> </rpc-reply> ]]>]]>

## 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 about locking the configuration, see Locking the Candidate Configuration.

Client Application | NETCONF Server
--- | ---
<rpc> <lock> <target> <candidate/> </target> </lock> </rpc> ]]>]]> |
| <rpc-reply xmlns=”URN” xmlns:sdx=”URL” > <ok/> </rpc-reply> ]]>]]>

## Changing the Configuration

The client application now emits tag elements to create a new 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.)

Client Application | NETCONF Server
--- | ---
<rpc> <edit-config> <target> <candidate/> </target> <config> <configuration> <system> <login> <class> <name>network-mgmt</name> <permissions>configure</permissions> <permissions>snmp</permissions> <permissions>system</permissions> </class> </login> </system> </configuration> </config> </edit-config> </rpc> ]]>]]> |
| <rpc-reply xmlns=”URN” xmlns:sdx=”URL” > <ok/> </rpc-reply> ]]>]]>

## 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 a Configuration.

Client Application | NETCONF Server
--- | ---
<rpc> <commit/> </rpc> ]]>]]> |
| <rpc-reply xmlns=”URN” xmlns:sdx=”URL” > <ok/> </rpc-reply> ]]>]]>

## 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 the configuration, see Unlocking the Candidate Configuration.

Client Application | NETCONF Server
--- | ---
<rpc> <unlock> <target> <candidate/> </target> </unlock> </rpc> ]]>]]> |
| <rpc-reply xmlns=”URN” xmlns:sdx=”URL” > <ok/> </rpc-reply> ]]>]]>

## 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.

Client Application | NETCONF Server
--- | ---
<rpc> <close-session/> </rpc> ]]>]]> |
| <rpc-reply xmlns=” URN ” xmlns:sdx=” URL ” > <ok/> </rpc-reply> ]]>]]>

[Contents] [Prev] [Next] [Index] [Report an Error]