close

keyboard_arrow_left

Table of Contents Expand all

play_arrow Overview
- play_arrow NETCONF XML Management Protocol Overview
  - NETCONF XML Management Protocol and Junos XML API Overview
  - Advantages of Using the NETCONF XML Management Protocol and Junos XML API
- play_arrow NETCONF and Junos XML Tags Overview
play_arrow Manage NETCONF Sessions
- play_arrow NETCONF Session Overview
- play_arrow Manage NETCONF Sessions
- play_arrow NETCONF Tracing Operations
  - NETCONF and Junos XML Protocol Tracing Operations Overview
  - Example: Trace NETCONF and Junos XML Protocol Session Operations
- play_arrow NETCONF Protocol Operations and Attributes
- play_arrow NETCONF Request and Response Tags
- play_arrow Junos XML Protocol Elements Supported in NETCONF Sessions
- play_arrow Junos XML Protocol Element Attributes Supported in NETCONF Sessions
play_arrow Manage Configurations Using NETCONF
play_arrow Request Operational and Configuration Information Using NETCONF
- play_arrow Request Operational Information Using NETCONF
  - Request Operational Information Using NETCONF
  - Specify the Output Format for Operational Information Requests in a NETCONF Session
- play_arrow Request Configuration Information Using NETCONF
play_arrow NETCONF Utilities
- play_arrow NETCONF Perl Client
  - Understanding the NETCONF Perl Client and Sample Scripts
  - Install the NETCONF Perl Client
- play_arrow Develop NETCONF Perl Client Applications
play_arrow YANG
- play_arrow YANG Overview
- play_arrow Create and Use Non-Native YANG Modules
play_arrow OpenDaylight Integration
- play_arrow Configure OpenDaylight Integration
  - Configure Interoperability Between MX Series Routers and OpenDaylight
play_arrow Configuration Statements and Operational Commands
- Junos CLI Reference Overview

list Table of Contents

English

NETCONF Call Home Sessions

date_range 23-May-24

arrow_backward

arrow_forward

NETCONF Call Home enables a NETCONF server to initiate a secure connection to a NETCONF client. The NETCONF client can then establish an SSH session and NETCONF session with the server.

NETCONF Call Home enables a NETCONF client to remotely manage Junos devices in cases where the client cannot initiate a connection to the network device. The Junos device that is acting as the NETCONF server initiates and maintains secure connections to a predefined set of NETCONF clients. The following sections discuss the NETCONF Call Home feature.

NETCONF Call Home Overview

For normal NETCONF sessions over SSH, the NETCONF client first initiates a TCP connection to the Junos device that is acting as the NETCONF server. The client then starts the SSH session followed by the NETCONF session. In a NETCONF call home scenario, the roles of the TCP server and client are reversed. The NETCONF server initiates the TCP connection to the NETCONF client. After the connection is established, the NETCONF client then starts the SSH session and NETCONF session as normal.

NETCONF Call Home enables you to remotely manage Junos devices that might not be otherwise accessible. This might happen, for example, if the device is behind a firewall, and the firewall or another security tool restricts management access to the device or implements Network Address Translation (NAT). In such cases, the NETCONF client might not be able to initiate the connection with the Junos device. However, you can configure the Junos device to initiate, establish, and maintain a connection with a predefined set of network management systems.

You can use NETCONF Call Home in the following scenarios:

Initial deployment
General device management

Figure 1 outlines the call home sequence. In a NETCONF call home scenario, the network management system (NMS) is the TCP server, and the Junos device is the TCP client. You configure the TCP server to listen for connection requests on a specified port. The NETCONF Call Home standard port is 4334, but you can configure any valid port number that does not conflict with another service. You configure the Junos device to connect to one or more predefined network management systems on the specified port. After the devices establish a TCP connection, the NMS assumes its role as SSH client and NETCONF client.

Figure 1: NETCONF Call Home Connection

The NETCONF client initiates an SSH session over the TCP connection. During SSH session establishment, the NETCONF client must authenticate the server by validating the server's presented host key or certificate. The NETCONF server must also authenticate the client. The client can choose any SSH authentication method supported by the server. The server first checks certificate-based authentication, then key-based authentication, and finally password-based authentication.

We recommend using SSH certificate-based authentication for users and hosts. Certificate-based authentication enables you to set up SSH access to a device with password-less login for users and gives the capability to trust hosts without the need to verify key fingerprints. Additionally, you can define the length of time that a given certificate is valid. For certificate-based authentication, the server and client each send their SSH certificate. You must configure the client with the CA public key that verifies the server's certificate. Similarly, you must configure the server with the CA public key that verifies the client's certificate.

For more information about NETCONF Call Home, see RFC 8071, NETCONF Call Home and RESTCONF Call Home.

Benefits of NETCONF Call Home

NETCONF Call Home can streamline the initial deployment of devices.
NETCONF Call Home using certificate-based authentication can simplify the management and scaling of authentication keys and offer stronger security compared to traditional password-based approaches.

How to Set Up NETCONF Call Home

To configure NETCONF Call Home, perform the steps described in the following sections:

Configure the Junos User Account
Configure SSH Authentication
Enable the NETCONF Service
Configure the Junos Device to Connect to the NETCONF Call Home Client

Configure the Junos User Account

For all SSH authentication methods, the NETCONF client needs a local user account or user template account on each device where it establishes a NETCONF session.

To create a local user template account:

Configure the user statement at the [edit system login] hierarchy level and specify a username. Include the class statement, and specify a login class that has the permissions required for all actions to be performed by the user.
```
[edit system login]
user@host# set user username class class-name 
```
Commit the configuration
```
[edit]
user@host# commit 
```
Repeat the preceding steps on each Junos device where the client application establishes NETCONF sessions.

Configure SSH Authentication

During SSH session establishment, the NETCONF client authenticates the server by validating the server's presented host key or certificate. Similarly, the NETCONF server authenticates the client. The server first checks certificate-based authentication, then key-based authentication, and finally password-based authentication. You must configure the server and client for whichever authentication method you choose. The SSH authentication methods are described in the following sections:

Configure Password-Based Authentication
Configure Key-Based Authentication
Configure Certificate-Based Authentication

Configure Password-Based Authentication

If the NETCONF client uses password-based authentication, configure the Junos user account with a password.

To create a text-based password:

Include the plain-text-password or encrypted-password statement for the user account.
- To enter a password as text, issue the following command. You are prompted for the password, which is encrypted before being stored.
```
[edit system login user username authentication]
user@host# set plain-text-password 
New password: password 
Retype new password: password
```
  To store a pre-encrypted password, for example, a password that you previously created and hashed using Message Digest 5 (MD5), issue the following command:
```
[edit system login user username authentication]
user@host# set encrypted-password "password"
```
Commit the configuration.
```
[edit system login user username authentication]
user@host# commit 
```
Repeat the preceding steps on each Junos device where the client application establishes NETCONF sessions using password-based authentication.

Configure Key-Based Authentication

If the NETCONF client uses key-based authentication, first generate the user's SSH key pair on the configuration management server. Then configure the public key under the corresponding user account on the Junos device.

To configure key-based authentication for the NETCONF client:

Generate the SSH key pair for the given user.

On the network management system, issue the ssh-keygen command and provide the appropriate arguments.
```
user@nms:~$ ssh-keygen options
```
For example:
```
netconf-user@nms:~$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/netconf-user/.ssh/id_rsa): 
Created directory '/home/netconf-user/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/netconf-user/.ssh/id_rsa
Your public key has been saved in /home/netconf-user/.ssh/id_rsa.pub
...
```
By default, the ssh-keygen command stores the public and private keys in files in the .ssh subdirectory of the user home directory; the filename depends on the encoding and SSH version. See the ssh-keygen manual page for more information about the command options.
On the Junos device, associate the public key with the Junos login account for that user.
```
[edit system login user username authentication]
user@host# set load-key-file URL
```
Junos OS copies the contents of the specified file onto the device running Junos OS. URL is the path to the file that contains one or more public keys. For information about specifying URLs, see the CLI User Guide.

Note:
Alternatively, you can configure the public key by including the ssh-rsa or equivalent statement at the [edit system login user username authentication] hierarchy level.
Commit the configuration.
```
[edit]
user@host# commit 
```
Repeat the steps for configuring the public key on each Junos device where the client application establishes a NETCONF session.

During the initialization of the SSH connection, the client can authenticate the identity of the NETCONF server by using the server's public key. You can either install the server's public key on the network management system, or you can pass in the key during session initialization.

Configure Certificate-Based Authentication

NETCONF Call Home supports using SSH certificates for authentication. An SSH certificate comprises an SSH public key that has been signed by a certificate authority (CA). A CA private key (signing key) signs the host public key to generate the host certificate. Similarly a CA private key signs the user public key to generate the user certificate. The host certificate authenticates the host to users, and the user certificate authenticates the user to hosts.

You can use OpenSSH to create SSH certificates and the associated CA infrastructure. The OpenSSH certificate specifies a public key, identity information, and validity constraints. To use SSH certificates for authentication you must:

Create the certificate authorities and generate the CA signing keys.
Generate the user's SSH key pair.
Generate the user and host certificates by using the CA private key to sign the user public key and host public key.
Configure the CA public key as trusted on the Junos device and the network management system.
Configure the authorized principals on the Junos device.

By default, generated certificates are valid for all users. To limit the user certificate to a specific set of users (principals), you must specify the authorized principals when you generate the certificate. Junos devices require certificates that specify one or more authorized principals. You must also configure the list of authorized principals on the Junos device. If any authorized principal configured on the device matches an authorized principal in the certificate, the device authenticates the certificate. The connecting user is authorized even if they are not explicitly configured as an authorized principal in the certificate or on the device.

To configure certificate-based authentication, perform the following steps:

Generate the Certificate Authorities
Generate the User Certificate
Generate the Host Certificate
Configure the Authorized Principals

Generate the Certificate Authorities

On any Linux/FreeBSD system, generate the certificate authority signing keys.

content_copy zoom_out_map
user@nms:~$ ssh-keygen -t type -f output-key-file -N passphrase -b bits

For example, the following commands create separate CA signing keys for signing the user and host certificates.

content_copy zoom_out_map
user@nms:~$ sudo ssh-keygen -t rsa -f /root/.ssh/user_ca -N "" -b 4096
Generating public/private rsa key pair.
Your identification has been saved in /root/.ssh/user_ca
Your public key has been saved in /root/.ssh/user_ca.pub
The key fingerprint is:
SHA256:0GbR/Lar1eH3/lULO66XSikD+gSwbibgTtFdnHNwlKg root@nms
...

content_copy zoom_out_map
user@nms:~$ sudo ssh-keygen -t rsa -f /root/.ssh/host_ca -N "" -b 4096
Generating public/private rsa key pair.
Your identification has been saved in /root/.ssh/host_ca
Your public key has been saved in /root/.ssh/host_ca.pub
The key fingerprint is:
SHA256:Aps80CYHqK8jRaMt2BNkjS1SrJpuEcgF7QTlBoB/ygI root@nms
...

Configure the network management system to trust the host CA.

Copy the contents of the host CA public key and add it to the global or user's SSH known hosts file to mark it as a trusted CA. In the following example, we copy the host CA public key contents and add @cert-authority * host-ca-public-key to the user's known_hosts file.
```
user@nms:~$ sudo cat /root/.ssh/host_ca.pub
ssh-rsa AAAAB3Nz...
```
```
user@nms:~$ cat ~/.ssh/known_hosts
@cert-authority * ssh-rsa AAAAB3Nz...
```
Note:
The NMS uses the host CA public key to verify the host certificate. To trust the certificate for only specific hosts or domains, replace the wildcard (*) with the appropriate host or domain names.
Copy the user CA public key to the Junos device.
```
user@nms:~$ scp path-to-user-CA-public-key user@device-ip:/var/tmp/
```
For example:
```
user@nms:~$ sudo scp /root/.ssh/user_ca.pub user@198.51.100.1:/var/tmp/
```
On the Junos device, configure the user CA public key as a trusted CA key.
```
[edit system services ssh]
user@host# set trusted-user-ca-key-file path-to-user-CA-public-key
```
The following example adds the CA public key that is stored in the user_ca.pub file as a trusted user CA key.
```
[edit system services ssh]
user@host# set trusted-user-ca-key-file /var/tmp/user_ca.pub
user#host# commit
```
When you configure this statement, the device adds the user CA public key to the /var/etc/ssh_trusted_user_ca.pub file. The Junos device uses the user CA public key to verify the user certificate during SSH session establishment.

Generate the User Certificate

To generate the SSH certificate for the NETCONF client:

On the client NMS, generate an SSH key pair for the user.

content_copy zoom_out_map
user@nms:~$ ssh-keygen -t (rsa | ecdsa | ed25519) -f output-key-file -N passphrase -b bits

For example:

content_copy zoom_out_map
lab@nms:~$ ssh-keygen -t rsa -f ~/.ssh/id_rsa -N "" -b 4096
Generating public/private rsa key pair.
Your identification has been saved in /home/lab/.ssh/id_rsa
Your public key has been saved in /home/lab/.ssh/id_rsa.pub
...

Copy the user's public key to the CA server that has the CA signing keys, if the devices are different.
Generate the user certificate.

Use the user CA private key to sign the user's public key, and specify the list of authorized principals (users) that can access the Junos device using this certificate.
```
user@nms:~$ ssh-keygen -s path-to-user-ca-private-key -I key-identity -n principal1,principal2,principal3 -V validity-interval path-to-user-public-key
```
The following command uses the CA private key stored in user_ca to sign the user's public key stored in id_rsa.pub. The certificate is valid for two principals: lab and netconf-user.
```
user@nms:~$ sudo ssh-keygen -s /root/.ssh/user_ca -I netconfusers -n lab,netconf-user -V +52w6d /home/lab/.ssh/id_rsa.pub
Signed user key /home/user/.ssh/id_rsa-cert.pub: id "netconfusers" serial 0 for lab,netconf-user valid from 2024-04-11T17:47:00 to 2025-04-16T17:48:20
```

Verify that the user certificate is created.

content_copy zoom_out_map
user@nms:~$ ssh-keygen -Lf path-to-user-cert

For the previous step, the command creates the id_rsa-cert.pub file.

content_copy zoom_out_map
lab@nms:~$ ssh-keygen -Lf /home/lab/.ssh/id_rsa-cert.pub
/home/lab/.ssh/id_rsa-cert.pub:
        Type: ssh-rsa-cert-v01@openssh.com user certificate
        Public key: RSA-CERT SHA256:SMInnJm8SXfsYLm7NvQZqcaGpuXc9QuraKZSsewdFKM
        Signing CA: RSA SHA256:0GbR/Lar1eH3/lULO66XSikD+gSwbibgTtFdnHNwlKg (using rsa-sha2-512)
        Key ID: "netconfusers"
        Serial: 0
        Valid: from 2024-04-11T17:51:00 to 2025-04-16T17:52:45
        Principals: 
                lab
                netconf-user
        Critical Options: (none)
        Extensions: 
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

Copy the user certificate to the network management system, if the devices are different.
```
$ scp path-to-user-cert user@nms-ip:/home/user/.ssh
```

Ensure the user certificate file owner and permissions are correct.

content_copy zoom_out_map
user@nms:~$ sudo chown user:group /home/user/.ssh/id_rsa-cert.pub
user@nms:~$ sudo chmod 644 /home/user/.ssh/id_rsa-cert.pub

Add the SSH key and certificate identities to the ssh-agent application, if they are not added automatically. For example:
```
lab@nms:~$ ssh-add
Identity added: /home/lab/.ssh/id_rsa (lab@nms)
Certificate added: /home/lab/.ssh/id_rsa-cert.pub (netconfusers)
```

Generate the Host Certificate

The Junos device stores SSH keys in the /etc/ssh directory. To generate the host certificate, first copy the host's public key to the CA server, and then use the host CA private key to sign the host public key.

On the Junos device, verify the host public keys.

content_copy zoom_out_map
user@host> file list /etc/ssh/*.pub
/etc/ssh/ssh_host_ec_p384_key.pub
/etc/ssh/ssh_host_ec_p521_key.pub
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key.pub

Copy the Junos device's public key to the CA server that has the CA signing keys.
```
user@host> scp /etc/ssh/ssh_host_rsa_key.pub user@ca-server-ip:/var/tmp/
```
Generate the host certificate.

Use the host CA private key to sign the host's public key, and specify the -h option to create a host certificate.
```
user@nms:~$ ssh-keygen -s path-to-host-CA-private-key -I key-identity -h path-to-host-public-key
```
The following command uses the CA private key stored in host_ca to sign the host's public key stored in ssh_host_rsa_key.pub.
```
user@nms:~$ sudo ssh-keygen -s /root/.ssh/host_ca -I ssh_server -h /var/tmp/ssh_host_rsa_key.pub
Signed host key /var/tmp/ssh_host_rsa_key-cert.pub: id "ssh_server" serial 0 valid forever
```
Verify that the host certificate is created.
```
user@nms:~$ ls path-to-host-certificate
```
For the previous step, the command creates the ssh_host_rsa_key-cert.pub file.
```
user@nms:~$ ls /var/tmp/ssh_host_rsa_key-cert.pub
/var/tmp/ssh_host_rsa_key-cert.pub
```
Copy the host certificate to the Junos device.
```
user@nms:~$ scp path-to-host-certificate user@device-ip:/var/tmp/
```
For example:
```
user@nms:~$ scp /var/tmp/ssh_host_rsa_key-cert.pub user@198.51.100.1:/var/tmp/
```
On the Junos device, configure the host certificate.
```
[edit system services ssh]
user@host# set host-certificate-file /var/tmp/ssh_host_rsa_key-cert.pub
user#host# commit
```
When you configure this statement, the device adds the host certificate to the /var/etc/ssh_host_ca.pub file.

Configure the Authorized Principals

User certificates can be tied to specific users, or principals. Junos devices require that the user certificate specify one or more authorized principals. You must also configure authorized principals on the Junos device. The Junos device authenticates the certificate if at least one of the authorized principals configured on the device matches an authorized principal in the certificate.

You can configure the list of authorized principals using several methods. You can load a file that contains the list of authorized principals, each on a separate line. You can also configure the authorized principal list directly in the configuration.

To configure the authorized principals:

(Optional) Create the authorized principals file and copy it to the Junos device.
```
user@host> file show /var/tmp/auth_principals_list
lab
netconf-user
```
Configure the authorized principals that can access the system using SSH certificates.
- To load a file containing the authorized principals, configure the authorized-principals-file statement and specify the path of the file to load.
```
[edit system services ssh]
user@router# set authorized-principals-file filepath
```
  For example:
```
[edit system services ssh]
user@router# set authorized-principals-file /var/tmp/auth_principals_list
```
- To configure one or more authorized principals directly in the configuration, use the authorized-principals statement and specify a principal name or a list of principal names.
```
[edit system services ssh]
user@host# set authorized-principals principal
user@host# set authorized-principals [principal1 principal2 principal3]
```
  For example:
```
[edit system services ssh]
user@host# set authorized-principals [lab netconf-user]
```
Commit the configuration.
```
[edit]
user@host# commit 
```
When you configure authorized principals, the device adds the list of authorized principals to the /var/etc/ssh_authorized_principals file.

Enable the NETCONF Service

To configure the NETCONF service for NETCONF Call Home on the Junos device:

Enable the NETCONF service on either the default NETCONF port (830) or a user-defined port.
- To use the default NETCONF port (830), do not specify a port number.
  [edit system services] user@host# set netconf ssh
- To use a specific port, configure the port number.
  
  The port can range from 1 through 65535, however, you should avoid configuring access on a port that is normally assigned for another service .
  [edit system services] user@host# set netconf ssh port port-number
Configure RFC-compliant NETCONF sessions.
```
[edit system services]
user@host# set netconf rfc-compliant 
```
Configure YANG-compliant NETCONF sessions.
```
[edit system services]
user@host# set netconf yang-compliant 
```
Commit the configuration:
```
[edit system services]
user@host# commit
```

Configure the Junos Device to Connect to the NETCONF Call Home Client

In a NETCONF call home scenario, the roles of the TCP server and client are reversed. You configure the Junos device to initiate, establish, and maintain a connection with a predefined set of network management systems. NETCONF Call Home uses outbound SSH to connect to the specified NETCONF clients.

Before you begin:

If you use SSH certificates for authentication, configure the user CA certificates, the host certificate, and the authorized principals.

Note:

The NETCONF call home client configuration registers the SSH certificate configuration at the time that you commit the client configuration. You must configure the host certificate and at least one user CA certificate and one authorized principal at the time that you commit the client configuration. If you add these initial values later, you must deactivate and commit the client configuration and then activate and commit the client configuration for the values to take effect. If the initial values are configured when you first activate the client configuration, then the client configuration will automatically register any updates to the existing values.

To configure a NETCONF Call Home client on the Junos device:

At the [edit system services ssh] hierarchy level, set the SSH version to v2.
```
[edit system services ssh]
user@host# set protocol-version v2
```
Navigate to the outbound SSH client hierarchy, and define an identifier that uniquely identifies the NETCONF Call Home client.
```
[edit]
user@host# edit system services outbound-ssh client client-id
```
For example:
```
[edit]
user@host# edit system services outbound-ssh client nms1
```
Configure the hostname or the IPv4 or IPv6 address for the NETCONF client. Additionally, specify the port on which the NETCONF client (acting as the TCP server) is listening for connection requests.
```
[edit system services outbound-ssh client nms1]
user@host# set address port port
```
For example:
```
[edit system services outbound-ssh client nms1]
user@host# set 198.51.100.10 port 4334
```
Define the device identifier, which is a user-defined string that identifies the Junos device to the client during the initiation sequence.
```
[edit system services outbound-ssh client nms1]
user@host# set device-id device-id
```
For example:
```
[edit system services outbound-ssh client nms1]
user@host# set device-id router1
```
Define the method used to reestablish a disconnected outbound SSH connection as sticky or in-order.
```
[edit system services outbound-ssh client nms1]
user@host# set reconnect-strategy in-order
```

Configure the NETCONF service for the session.

content_copy zoom_out_map
[edit system services outbound-ssh client nms1]
user@host# set services netconf

(Optional) Configure the Junos device to send keepalive messages to the management server.
```
[edit system services outbound-ssh client nms1]
user@host# set keep-alive retry num timeout seconds
```
For example, the following configuration sends a keepalive signal every 15 seconds (the default), and terminates the SSH connection after sending 3 messages (the default) that do not receive a response.
```
[edit system services outbound-ssh client nms1]
user@host# set keep-alive timeout 15 retry 3
```
(Optional) Configure the secret statement if you want pass the device's public key to the management server during session initialization.
```
[edit system services outbound-ssh client nms1]
user@host# set secret password
```
When you configure this statement, the device passes its public key along with a SHA1 hash derived in part from the secret statement to the management server during session initialization. The client application can use the shared secret and hash to verify whether the presented host key is from the device identified by the device-id statement.
Repeat the preceding steps for each NETCONF Call Home client that will manage the Junos device.

Commit the configuration.

content_copy zoom_out_map
[edit system services outbound-ssh client nms1]
user@R0# commit and-quit

After you configure the device to connect to the NETCONF Call Home client and commit the configuration, the device attempts to initiate a TCP/IP connection with the client. The device continues to create this connection until successful or until the NETCONF call home client configuration is deleted or deactivated.

Each time the Junos device establishes an outbound SSH connection, it sends an initiation sequence that identifies the device to the client. Within this transmission is the value of device-id. When you do not configure the secret statement, the initiation sequence is:

content_copy zoom_out_map
MSG-ID: DEVICE-CONN-INFO\r\n
MSG-VER: V1\r\n
DEVICE-ID: <device-id>\r\n

If you configure the secret statement, the initiation sequence includes the Junos device's public key, and a SHA1 hash derived in part from the secret statement. The client can compute the expected hash value and compare it to the HMAC value to verify that the presented host key is from the device identified by the device-id statement.

content_copy zoom_out_map
MSG-ID: DEVICE-CONN-INFO\r\n
MSG-VER: V1\r\n
DEVICE-ID: <device-id>\r\n
HOST-KEY: <public-host-key>\r\n
HMAC:<HMAC(pub-SSH-host-key, <secret>)>\r\n

The client authenticates the Junos device by validating the presented host key or certificate. Similarly, the NETCONF server authenticates the client. The server first checks certificate-based authentication, then key-based authentication, and finally password-based authentication. After the SSH session is established, the client starts the NETCONF session.

arrow_backward PREVIOUS NETCONF Sessions over Outbound HTTPS

NEXT arrow_forward NETCONF Sessions

NETCONF XML Management Protocol Developer Guide

ON THIS PAGE