include::nemo/odl-nemo-engine-user.adoc[NEMO]
+include::controller/netconf/odl-netconf-user.adoc[]
+
include::netide/odl-netide-user-guide.adoc[NetIDE]
include::nic/nic-user.adoc[NIC]
include::vtn/vtn-user.adoc[]
-include::controller/netconf/odl-netconf-user.adoc[]
-
include::yangide/yangide-user.adoc[]
include::yang-push/odl-yang-push-user.adoc[YANG-PUSH]
=== Northbound (NETCONF servers)
OpenDaylight provides 2 types of NETCONF servers:
-* *NETCONF server for config-subsystem(listening by default on port
+* *NETCONF server for config-subsystem (listening by default on port
1830)*
** Serves as a default interface for config-subsystem and allows
- users to spawn/reconfigure/destroy modules(or applications) in OpenDaylight
-* *NETCONF server for MD-SAL(listening by default on port 2830)*
+ users to spawn/reconfigure/destroy modules (or applications) in OpenDaylight
+* *NETCONF server for MD-SAL (listening by default on port 2830)*
** Serves as an alternative interface for MD-SAL (besides RESTCONF)
and allows users to read/write data from MD-SAL's datastore and to
invoke its rpcs (NETCONF notifications are not available in the
- Lithium release of OpenDaylight)
+ Beryllium release of OpenDaylight)
NOTE: The reason for having 2 NETCONF servers is that config-subsystem and
MD-SAL are 2 different components of OpenDaylight and require different
In terms of RFCs, these are supported:
-* http://tools.ietf.org/html/rfc6241[RFC-6241],
-* https://tools.ietf.org/html/rfc5277[RFC-5277],
+* http://tools.ietf.org/html/rfc6241[RFC-6241]
+* https://tools.ietf.org/html/rfc5277[RFC-5277]
* https://tools.ietf.org/html/rfc6470[RFC-6470]
** (partially, only the
- schema-change notification is available in Lithium release)
-* https://tools.ietf.org/html/rfc6022[RFC-6022],
+ schema-change notification is available in Beryllium release)
+* https://tools.ietf.org/html/rfc6022[RFC-6022]
For regular users it is recommended to use RESTCONF + the
controller-config loopback mountpoint instead of using pure NETCONF.
How to do that is spesific for each component/module/application
-in OpenDaylight and can be found in their dedicated user guides
+in OpenDaylight and can be found in their dedicated user guides.
==== NETCONF server for MD-SAL
This NETCONF server is just a generic interface to MD-SAL in OpenDaylight.
In terms of RFCs, these are supported:
-* http://tools.ietf.org/html/rfc6241[RFC-6241],
-* https://tools.ietf.org/html/rfc6022[RFC-6022],
+* http://tools.ietf.org/html/rfc6241[RFC-6241]
+* https://tools.ietf.org/html/rfc6022[RFC-6022]
-Notifications over NETCONF are not supported in the Lithium release.
+Notifications over NETCONF are not supported in the Beryllium release.
TIP: Install NETCONF northbound for MD-SAL by installing feature:
+odl-netconf-mdsal+ in karaf. Default binding port is *2830*.
separately.
===== Verifying MD-SAL's NETCONF server
-After the NETCONF server is available it can be examined by e.g. a
+After the NETCONF server is available it can be examined by a
command line ssh tool:
----
----
The server will respond by sending its HELLO message and can be used
-as a regular NETCONF server from now on.
+as a regular NETCONF server from then on.
===== Mounting the MD-SAL's NETCONF server
To perform this operation, just spawn a new netconf-connector as described in
=== Southbound (netconf-connector)
-NETCONF southbound plugin is capable of connecting to remote NETCONF
-devices and expose their configuration/operational datastores, rpcs and
+The NETCONF southbound plugin is capable of connecting to remote NETCONF
+devices and exposing their configuration/operational datastores, RPCs and
notifications as MD-SAL mount points. These mount points allow
applications and remote users (over RESTCONF) to interact with the
mounted devices.
In terms of RFCs, the connector supports:
-* http://tools.ietf.org/html/rfc6241[RFC-6241],
-* https://tools.ietf.org/html/rfc5277[RFC-5277],
-* https://tools.ietf.org/html/rfc6022[RFC-6022],
+* http://tools.ietf.org/html/rfc6241[RFC-6241]
+* https://tools.ietf.org/html/rfc5277[RFC-5277]
+* https://tools.ietf.org/html/rfc6022[RFC-6022]
-*Netconf-connector is fully model driven (utilising YANG modeling language) so in addition to
+*Netconf-connector is fully model-driven (utilizing the YANG modeling language) so in addition to
the above RFCs, it supports any data/RPC/notifications described by a
YANG model that is implemented by the device.*
+odl-netconf-connector-all+ Karaf feature.
==== Netconf-connector configuration
-There are 2 ways for configuring netconf-connector (as is for any
-other module) NETCONF or RESTCONF. This guide focuses on using RESTCONF.
+There are 2 ways for configuring netconf-connector:
+NETCONF or RESTCONF. This guide focuses on using RESTCONF.
===== Default configuration
The default configuration contains all the necessary dependencies
. OpenDaylight is running
. In Karaf, you must have the netconf-connector installed (at the
- Karaf prompt, type: feature:install odl-netconf-connector-all); the
+ Karaf prompt, type: `feature:install odl-netconf-connector-all`); the
loopback NETCONF mountpoint will be automatically configured and
activated
. Wait until log displays following entry:
POST http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules
-*Headers*:
-Accept application/xml
-Content-Type application/xml
+Headers:
+
+* Accept application/xml
+* Content-Type application/xml
----
<module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
GET http://localhost:8181/restconf/operational/network-topology:network-topology/
-Information about connection status, device capabilities etc. can be
+Information about connection status, device capabilities, etc. can be
found there.
===== Connecting to a device not supporting NETCONF monitoring
attribute, it is possible to override the "yang-module-based"
capabilities reported in HELLO message of the device. To do this, we
need to modify the configuration of netconf-connector by adding this
-xml (It needs to be added next to the address, port, username etc.
+XML (It needs to be added next to the address, port, username etc.
configuration elements):
----
*sal-netconf-connector* and name *new-netconf-device*). The type and name
are actually the keys of the module list.
-==== Netconf-connector utilisation
-Once the connector is up and running, users can utilize the new Mount
+==== Netconf-connector configuration with MD-SAL
+It is also possible to configure new NETCONF connectors directly through MD-SAL
+with the usage of the network-topology model. You can configure new NETCONF
+connectors both through the NETCONF server for MD-SAL (port 2830) or RESTCONF.
+This guide focuses on RESTCONF.
+
+TIP: To enable NETCONF connector configuration through MD-SAL install either
+the +odl-netconf-topology+ or +odl-netconf-clustered-topology+ feature.
+We will explain the difference between these features later.
+
+===== Preconditions
+
+. OpenDaylight is running
+. In Karaf, you must have the +odl-netconf-topology+ or +odl-netconf-clustered-topology+
+feature installed.
+. Feature +odl-restconf+ must be installed
+. Wait until log displays following entry:
++
+----
+Successfully pushed configuration snapshot 02-netconf-topology.xml(odl-netconf-topology,odl-netconf-topology)
+----
++
+or until
++
+----
+GET http://localhost:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/
+----
++
+returns a non-empty response, for example:
++
+----
+<topology xmlns="urn:TBD:params:xml:ns:yang:network-topology">
+ <topology-id>topology-netconf</topology-id>
+</topology>
+----
+
+===== Spawning new NETCONF connectors
+To create a new NETCONF connector you need to send the following request to RESTCONF:
+
+ PUT http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/new-netconf-device
+
+Headers:
+
+* Accept: application/xml
+* Content-Type: application/xml
+
+Payload:
+----
+<node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
+ <node-id>new-netconf-device</node-id>
+ <host xmlns="urn:opendaylight:netconf-node-topology">127.0.0.1</host>
+ <port xmlns="urn:opendaylight:netconf-node-topology">17830</port>
+ <username xmlns="urn:opendaylight:netconf-node-topology">admin</username>
+ <password xmlns="urn:opendaylight:netconf-node-topology">admin</password>
+ <tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only>
+ <!-- non-mandatory fields with default values, you can safely remove these if you do not wish to override any of these values-->
+ <reconnect-on-changed-schema xmlns="urn:opendaylight:netconf-node-topology">false</reconnect-on-changed-schema>
+ <connection-timeout-millis xmlns="urn:opendaylight:netconf-node-topology">20000</connection-timeout-millis>
+ <max-connection-attempts xmlns="urn:opendaylight:netconf-node-topology">0</max-connection-attempts>
+ <between-attempts-timeout-millis xmlns="urn:opendaylight:netconf-node-topology">2000</between-attempts-timeout-millis>
+ <sleep-factor xmlns="urn:opendaylight:netconf-node-topology">1.5</sleep-factor>
+ <!-- keepalive-delay set to 0 turns off keepalives-->
+ <keepalive-delay xmlns="urn:opendaylight:netconf-node-topology">120</keepalive-delay>
+</node>
+----
+
+Note that the device name in <node-id> element must match the last element of the restconf URL.
+
+===== Reconfiguring an existing connector
+The steps to reconfigure an existing connector are exactly the same as when spawning
+a new connector. The old connection will be disconnected and a new connector with
+the new configuration will be created.
+
+===== Deleting an existing connector
+To remove an already configured NETCONF connector you need to send the following:
+
+ DELETE http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/new-netconf-device
+
+==== Clustered NETCONF connector
+To spawn NETCONF connectors that are cluster-aware you need to install the
++odl-netconf-clustered-topology+ karaf feature.
+
+WARNING: The +odl-netconf-topology+ and +odl-netconf-clustered-topology+ features
+are considered *INCOMPATIBLE*. They both manage the same space in the datastore and
+would issue conflicting writes if installed together.
+
+Configuration of clustered NETCONF connectors works the same as the configuration
+through the topology model in the previous section.
+
+When a new clustered connector is configured the configuration gets distributed among
+the member nodes and a NETCONF connector is spawned on each node. From these nodes
+a master is chosen which handles the schema download from the device and all the
+communication with the device. You will be able to read/write to/from the device
+from all slave nodes due to the proxy data brokers implemented.
+
+You can use the +odl-netconf-clustered-topology+ feature in a single node scenario
+as well but the code that uses akka will be used, so for a scenario where only a
+single node is used, +odl-netconf-topology+ might be preferred.
+
+==== Netconf-connector utilization
+Once the connector is up and running, users can utilize the new mount
point instance. By using RESTCONF or from their application code. This
chapter deals with using RESTCONF and more information for app
developers can be found in the developers guide or in the official
tutorial application *ncmount* that can be found in the coretutorials project:
-* https://github.com/opendaylight/coretutorials/tree/stable/lithium/ncmount
+* https://github.com/opendaylight/coretutorials/tree/stable/beryllum/ncmount
===== Reading data from the device
Just invoke (no body needed):
testing/exploring NETCONF southbound in OpenDaylight.
===== Netopeer installation
-https://www.docker.com/[Docker] container with netopeer will be used
-in this guid. To install docker and start the
+A https://www.docker.com/[Docker] container with netopeer will be used
+in this guide. To install Docker and start the
https://index.docker.io/u/dockeruser/netopeer/[netopeer image] perform
following steps:
Now just follow the chapter:
<<_spawning_additional_netconf_connectors_while_the_controller_is_running, Spawning netconf-connector>>. In the payload change the:
-* name to e.g. netopeer
-* usernam/password to your system credentials
+* name, e.g., to netopeer
+* username/password to your system credentials
* ip to localhost
* port to 1831.
=== NETCONF testtool
*NETCONF testtool is a set of standalone runnable jars that can:*
-* Simulate NETCONF devices(suitable for scale testing)
+* Simulate NETCONF devices (suitable for scale testing)
* Stress/Performance test NETCONF devices
* Stress/Performance test RESTCONF devices
These jars are part of OpenDaylight's controller project and are built from the
NETCONF codebase in OpenDaylight.
-TIP: Download testtool from OpenDaylight Nexus at: http://nexus.opendaylight.org/#nexus-search;quick~netconf-testtool
+TIP: Download testtool from OpenDaylight Nexus at: https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/netconf/netconf-testtool/1.0.2-Beryllium-SR2/
*Nexus contains 3 executable tools:*
<name-of-the-tool.jar> --help+
==== NETCONF device simulator
-Detailed information for NETCONF device simulator can be found at: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Netconf:Testtool
-////
-TODO migrate the guide from wiki here
-////
+
+NETCONF testtool (or NETCONF device simulator) is a tool that
+
+* Simulates 1 or more NETCONF devices
+* Is suitable for scale, performance or crud testing
+* Uses core implementation of NETCONF server from OpenDaylight
+* Generates configuration files for controller so that the OpenDaylight distribution (Karaf) can easily connect to all simulated devices
+* Provides broad configuration options
+* Can start a fully fledged MD-SAL datastore
+* Supports notifications
+
+===== Building testtool
+
+. Check out latest NETCONF repository from https://git.opendaylight.org/gerrit/#/admin/projects/netconf[git]
+. Move into the `opendaylight/netconf/tools/netconf-testtool/` folder
+. Build testtool using the `mvn clean install` command
+
+===== Downloading testtool
+
+Netconf-testtool is now part of default maven build profile for controller and
+can be also downloaded from nexus. The executable jar for testtool can be found at:
+https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/netconf/netconf-testtool/1.0.2-Beryllium-SR2/[nexus-artifacts]
+
+===== Running testtool
+
+. After successfully building or downloading, move into the `opendaylight/netconf/tools/netconf-testtool/target/` folder and there is file `netconf-testtool-1.1.0-SNAPSHOT-executable.jar` (or if downloaded from nexus just take that jar file)
+. Execute this file using, e.g.:
++
+ java -jar netconf-testtool-1.1.0-SNAPSHOT-executable.jar
++
+This execution runs the testtool with default for all parameters and you should see this log output from the testtool :
++
+ 10:31:08.206 [main] INFO o.o.c.n.t.t.NetconfDeviceSimulator - Starting 1, SSH simulated devices starting on port 17830
+ 10:31:08.675 [main] INFO o.o.c.n.t.t.NetconfDeviceSimulator - All simulated devices started successfully from port 17830 to 17830
+
+====== Default Parameters
+
+The default parameters for testtool are:
+
+* Use SSH
+* Run 1 simulated device
+* Device port is 17830
+* YANG modules used by device are only: ietf-netconf-monitoring, ietf-yang-types, ietf-inet-types (these modules are required for device in order to support NETCONF monitoring and are included in the netconf-testtool)
+* Connection timeout is set to 30 minutes (quite high, but when testing with 10000 devices it might take some time for all of them to fully establish a connection)
+* Debug level is set to false
+* No distribution is modified to connect automatically to the NETCONF testtool
+
+===== Verifying testtool
+
+To verify that the simulated device is up and running, we can try to connect to
+it using command line ssh tool. Execute this command to connect to the device:
+
+ ssh admin@localhost -p 17830 -s netconf
+
+Just accept the server with yes (if required) and provide any password (testtool
+accepts all users with all passwords). You should see the hello message sent by simulated device.
+
+===== Testtool help
+
+----
+usage: netconf testool [-h] [--device-count DEVICES-COUNT] [--devices-per-port DEVICES-PER-PORT] [--schemas-dir SCHEMAS-DIR] [--notification-file NOTIFICATION-FILE]
+ [--initial-config-xml-file INITIAL-CONFIG-XML-FILE] [--starting-port STARTING-PORT] [--generate-config-connection-timeout GENERATE-CONFIG-CONNECTION-TIMEOUT]
+ [--generate-config-address GENERATE-CONFIG-ADDRESS] [--generate-configs-batch-size GENERATE-CONFIGS-BATCH-SIZE] [--distribution-folder DISTRO-FOLDER] [--ssh SSH] [--exi EXI]
+ [--debug DEBUG] [--md-sal MD-SAL]
+
+NETCONF device simulator. Detailed info can be found at https://wiki.opendaylight.org/view/OpenDaylight_Controller:Netconf:Testtool#Building_testtool
+
+optional arguments:
+ -h, --help show this help message and exit
+ --device-count DEVICES-COUNT
+ Number of simulated netconf devices to spin. This is the number of actual ports open for the devices.
+ --devices-per-port DEVICES-PER-PORT
+ Amount of config files generated per port to spoof more devices then are actually running
+ --schemas-dir SCHEMAS-DIR
+ Directory containing yang schemas to describe simulated devices. Some schemas e.g. netconf monitoring and inet types are included by default
+ --notification-file NOTIFICATION-FILE
+ Xml file containing notifications that should be sent to clients after create subscription is called
+ --initial-config-xml-file INITIAL-CONFIG-XML-FILE
+ Xml file containing initial simulatted configuration to be returned via get-config rpc
+ --starting-port STARTING-PORT
+ First port for simulated device. Each other device will have previous+1 port number
+ --generate-config-connection-timeout GENERATE-CONFIG-CONNECTION-TIMEOUT
+ Timeout to be generated in initial config files
+ --generate-config-address GENERATE-CONFIG-ADDRESS
+ Address to be placed in generated configs
+ --generate-configs-batch-size GENERATE-CONFIGS-BATCH-SIZE
+ Number of connector configs per generated file
+ --distribution-folder DISTRO-FOLDER
+ Directory where the karaf distribution for controller is located
+ --ssh SSH Whether to use ssh for transport or just pure tcp
+ --exi EXI Whether to use exi to transport xml content
+ --debug DEBUG Whether to use debug log level instead of INFO
+ --md-sal MD-SAL Whether to use md-sal datastore instead of default simulated datastore.
+----
+
+===== Supported operations
+
+Testtool default simple datastore supported operations:
+
+get-schema:: returns YANG schemas loaded from user specified directory,
+edit-config:: always returns OK and stores the XML from the input in a local variable available for get-config and get RPC. Every edit-config replaces the previous data,
+commit:: always returns OK, but does not actually commit the data,
+get-config:: returns local XML stored by edit-config,
+get:: returns local XML stored by edit-config with netconf-state subtree, but also supports filtering.
+(un)lock:: returns always OK with no lock guarantee
+create-subscription:: returns always OK and after the operation is triggered, provided NETCONF notifications (if any) are fed to the client. No filtering or stream recognition is supported.
+
+Note: when operation="delete" is present in the payload for edit-config, it will wipe its local store to simulate the removal of data.
+
+When using the MD-SAL datastore testtool behaves more like normal NETCONF server
+and is suitable for crud testing. create-subscription is not supported when
+testtool is running with the MD-SAL datastore.
+
+===== Notification support
+
+Testtool supports notifications via the --notification-file switch. To trigger the notification feed, create-subscription operation has to be invoked.
+The XML file provided should look like this example file:
+
+----
+<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
+<notifications>
+
+<!-- Notifications are processed in the order they are defined in XML -->
+
+<!-- Notification that is sent only once right after create-subscription is called -->
+<notification>
+ <!-- Content of each notification entry must contain the entire notification with event time. Event time can be hardcoded, or generated by testtool if XXXX is set as eventtime in this XML -->
+ <content><![CDATA[
+ <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
+ <eventTime>2011-01-04T12:30:46</eventTime>
+ <random-notification xmlns="http://www.opendaylight.org/netconf/event:1.0">
+ <random-content>single no delay</random-content>
+ </random-notification>
+ </notification>
+ ]]></content>
+</notification>
+
+<!-- Repeated Notification that is sent 5 times with 2 second delay inbetween -->
+<notification>
+ <!-- Delay in seconds from previous notification -->
+ <delay>2</delay>
+ <!-- Number of times this notification should be repeated -->
+ <times>5</times>
+ <content><![CDATA[
+ <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
+ <eventTime>XXXX</eventTime>
+ <random-notification xmlns="http://www.opendaylight.org/netconf/event:1.0">
+ <random-content>scheduled 5 times 10 seconds each</random-content>
+ </random-notification>
+ </notification>
+ ]]></content>
+</notification>
+
+<!-- Single notification that is sent only once right after the previous notification -->
+<notification>
+ <delay>2</delay>
+ <content><![CDATA[
+ <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
+ <eventTime>XXXX</eventTime>
+ <random-notification xmlns="http://www.opendaylight.org/netconf/event:1.0">
+ <random-content>single with delay</random-content>
+ </random-notification>
+ </notification>
+ ]]></content>
+</notification>
+
+</notifications>
+----
+
+===== Connecting testtool with controller Karaf distribution
+
+====== Auto connect to OpenDaylight
+
+It is possible to make OpenDaylight auto connect to the simulated
+devices spawned by testtool (so user does not have to post a configuration for
+every NETCONF connector via RESTCONF). The testtool is able to modify the OpenDaylight
+distribution to auto connect to the simulated devices after feature
++odl-netconf-connector-all+ is installed.
+When running testtool, issue this command (just point the testool to the distribution:
+
+ java -jar netconf-testtool-1.1.0-SNAPSHOT-executable.jar --device-count 10 --distribution-folder ~/distribution-karaf-0.4.0-SNAPSHOT/ --debug true
+
+With the distribution-folder parameter, the testtool will modify the distribution
+to include configuration for netconf-connector to connect to all simulated devices.
+So there is no need to spawn netconf-connectors via RESTCONF.
+
+====== Running testtool and OpenDaylight on different machines
+
+The testtool binds by default to 0.0.0.0 so it should be accessible from remote
+machines. However you need to set the parameter "generate-config-address"
+(when using autoconnect) to the address of machine where testtool will be run
+so OpenDaylight can connect. The default value is localhost.
+
+===== Executing operations via RESTCONF on a mounted simulated device
+
+Simulated devices support basic RPCs for editing their config. This part shows how to edit data for simulated device via RESTCONF.
+
+====== Test YANG schema
+
+The controller and RESTCONF assume that the data that can be manipulated for
+mounted device is described by a YANG schema. For demonstration, we will define
+a simple YANG model:
+
+----
+module test {
+ yang-version 1;
+ namespace "urn:opendaylight:test";
+ prefix "tt";
+
+ revision "2014-10-17";
+
+
+ container cont {
+
+ leaf l {
+ type string;
+ }
+ }
+}
+----
+
+Save this schema in file called test@2014-10-17.yang and store it a directory called test-schemas/, e.g., your home folder.
+
+====== Editing data for simulated device
+
+* Start the device with following command:
+
+ java -jar netconf-testtool-1.1.0-SNAPSHOT-executable.jar --device-count 10 --distribution-folder ~/distribution-karaf-0.4.0-SNAPSHOT/ --debug true --schemas-dir ~/test-schemas/
+
+* Start OpenDaylight
+* Install odl-netconf-connector-all feature
+* Install odl-restconf feature
+* Check that you can see config data for simulated device by executing GET request to
++
+ http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/17830-sim-device/yang-ext:mount/
++
+* The data should be just and empty data container
+* Now execute edit-config request by executing a POST request to:
++
+ http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/17830-sim-device/yang-ext:mount
++
+with headers:
++
+ Accept application/xml
+ Content-Type application/xml
++
+and payload:
++
+----
+<cont xmlns="urn:opendaylight:test">
+ <l>Content</l>
+</cont>
+----
+
+* Check that you can see modified config data for simulated device by executing GET request to
+
+ http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/17830-sim-device/yang-ext:mount/
+
+* Check that you can see the same modified data in operational for simulated device by executing GET request to
+
+ http://localhost:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/node/17830-sim-device/yang-ext:mount/
+
+WARNING: Data will be mirrored in operational datastore only when using the default
+simple datastore.
+
+===== Known problems
+
+====== Slow creation of devices on virtual machines
+
+When testtool seems to take unusually long time to create the devices use this flag when running it:
+
+ -Dorg.apache.sshd.registerBouncyCastle=false
+
+====== Too many files open
+
+When testtool or OpenDaylight starts to fail with TooManyFilesOpen exception, you need to increase the limit of open files in your OS. To find out the limit in linux execute:
+
+ ulimit -a
+
+Example sufficient configuration in linux:
+
+----
+core file size (blocks, -c) 0
+data seg size (kbytes, -d) unlimited
+scheduling priority (-e) 0
+file size (blocks, -f) unlimited
+pending signals (-i) 63338
+max locked memory (kbytes, -l) 64
+max memory size (kbytes, -m) unlimited
+open files (-n) 500000
+pipe size (512 bytes, -p) 8
+POSIX message queues (bytes, -q) 819200
+real-time priority (-r) 0
+stack size (kbytes, -s) 8192
+cpu time (seconds, -t) unlimited
+max user processes (-u) 63338
+virtual memory (kbytes, -v) unlimited
+file locks (-x) unlimited
+----
+
+To set these limits edit file: /etc/security/limits.conf, for example:
+
+----
+* hard nofile 500000
+* soft nofile 500000
+root hard nofile 500000
+root soft nofile 500000
+----
+
+====== "Killed"
+
+The testtool might end unexpectedly with a simple message: "Killed". This means
+that the OS killed the tool due to too much memory consumed or too many threads
+spawned. To find out the reason on linux you can use following command:
+
+ dmesg | egrep -i -B100 'killed process'
+
+Also take a look at this file: /proc/sys/kernel/threads-max. It limits the
+number of threads spawned by a process. Sufficient (but probably much more than
+enough) value is, e.g., 126676
==== NETCONF stress/performance measuring tool
This is basically a NETCONF client that puts NETCONF servers under
== NETCONF User Guide
=== Overview
-NETCONF is an XML based protocol used for configuration and monitoring
-of devices in the network. The base NETCONF protocol is described in
+NETCONF is an XML-based protocol used for configuration and monitoring
+devices in the network. The base NETCONF protocol is described in
http://tools.ietf.org/html/rfc6241[RFC-6241].
.NETCONF in OpenDaylight:
-OpenDaylight controller supports NETCONF protocol as a northbound server
-as well as a southbound plugin.
+OpenDaylight supports the NETCONF protocol as a northbound server
+as well as a southbound plugin. It also includes a set of test tools
+for simulating NETCONF devices and clients.
include::odl-netconf-southbound-user.adoc[]
Code Review / docs.git / commitdiff