The OpenDaylight’s Netconf Southbound Plugin can talk with netconf 1.0,1.1 compatible devices and supports netconf over ssh, chunking and eom framing as defined in https://tools.ietf.org/html/rfc6242#section-4.1.
To connecting to an external netconf server using opendaylight netconf plugin, create “04-netconf-devices.xml” in following location:
\\odl-controller\opendaylight\distribution\opendaylight\target\distribution.opendaylight-osgipackage\opendaylight\configuration\initial
Note: If there is already a file with number 04, create with 05 and so on.
Edit 04-netconf-devices.xml and paste following text in it:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
<snapshot> <configuration> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <modules xmlns="urn:opendaylight:params:xml:ns:yang:controller:config"> <module> <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">prefix:sal-netconf-connector</type> <name>CHANGE_NAME</name> <port xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">CHANGE_PORT</port> <username xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">CHANGE_USERNAME</username> <worker-thread-group xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf"> <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:netty">prefix:netty-threadgroup</type> <name>global-worker-group</name> </worker-thread-group> <address xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">CHANGE_IP_ADDRESS</address> <tcp-only xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">false</tcp-only> <event-executor xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf"> <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:netty">prefix:netty-event-executor</type> <name>global-event-executor</name> </event-executor> <password xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">CHANGE_PASSWORD</password> <boss-thread-group xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf"> <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:netty">prefix:netty-threadgroup</type> <name>global-boss-group</name> </boss-thread-group> <dom-registry xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf"> <type xmlns:prefix="urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom">prefix:dom-broker-osgi-registry</type> <name>dom-broker</name> </dom-registry> </module> </modules> </data> </configuration> <required-capabilities> <![CDATA[urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf?module=odl-sal-netconf-connector-cfg&revision=2013-10-28]]> </required-capabilities> </snapshot> |
Now you need to update following information with your device details in above xml:
- CHANGE_NAME (at line 7)
- CHANGE_PORT (at line 8)
- CHANGE_USERNAME (at line 9)
- CHANGE_IP_ADDRESS (at line 14)
- CHANGE_PASSWORD (at line 20)
Note: There has been a change in configuration subsystem as per this email thread. We need to make corresponding changes to above xml. I haven’t tried it yet – once I will do that, I will update it here. Or if you have given it a try, feel free to provide the updated XML in comments below.
Once this is done, start the opendaylight controller. Using below RESTCONF URL, you should be able to view the device details in inventory:
http://localhost:8080/restconf/operational/opendaylight-inventory:nodes
If you want to add more devices to configuration file, copy paste the module information from line 5 to 29 under <modules> tag and update the device information (name, port, username, ip address, password) as done above.
You can also perform get-config on the device and view the configuration data using below RESTCONF URL:
http://localhost:8080/restconf/config/opendaylight-inventory:nodes/opendaylight-inventory:node/libnetconfd/yang-ext:mount/
Thanks a lot for your response – when i tried “http://localhost:8080/restconf/config/opendaylight-inventory:nodes/opendaylight-inventory:node/libnetconfd/yang-ext:mount/”, I got “Mount point does not exist.” on the browser … Im new to this ODL environment and hence may be these dumb Q’s
Thanks once again
Hi Adi, did you replace libnetconfd with your node name?
Hello admin
I did it this time – and i got the below error
“Mount point does not contain any schema with modules.”
Regards
Adi
My goal: I would like to make my network device [with netconf] be able to show up on ODL GUI – just the way, the nodes from mini net gets discovered.
I would really appreciate if I can get the requirements and flow to do this – a procedure … I do see lots of documentation and am reading them but these are scattered everywhere when it comes to my objective …
Once I’m able to discover my device and communicate … I can build more features upon that
Thanks a lot in advance
Regards
Adi
Hi Adi,
Were you able to see any data using this RESTCONF API?
http://localhost:8080/restconf/operational/opendaylight-inventory:nodes
-Kanika
Also just an information, there is a bug in MD-SAL and you will not be able to invoke any netconf RPC on your device to add new functionality:
https://bugs.opendaylight.org/show_bug.cgi?id=560
Having said that, of course first step is to discover the device, lets get that done
Hello Kanika
Yes I was able to do so but not sure what was exactly expected. Wish there was a way I could have sent you the page I got back.
First I got an error “This XML file does not appear to have any style information associated with it. The document tree is shown below.
” and then below that, it printed an xml file with the capabilities – not sure. Below, Im pasting what i got
http://tail-f.com/ns/mibs/IPV6-TC/199812010000Z?module=IPV6-TC&revision=1998-12-01http://btisystems.com/ns/atlas-conditions?module=atlas-conditions&revision=2013-02-19http://btisystems.com/ns/atlas?module=atlas&revision=2012-06-25urn:ietf:params:netconf:capability:confirmed-commit:1.0urn:ietf:params:netconf:capability:confirmed-commit:1.1urn:ietf:params:xml:ns:yang:ietf-yang-smiv2?module=ietf-yang-smiv2&revision=2011-11-25urn:ietf:params:xml:ns:yang:iana-if-type?module=iana-if-type&revision=2012-06-05urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?module=ietf-netconf-monitoring&revision=2010-10-04urn:ietf:params:xml:ns:yang:ietf-interfaces?module=ietf-interfaces&revision=2012-07-14&features=snmp-if-mibhttp://tail-f.com/ns/aaa/1.1?module=atlas-aaa&revision=2011-09-22urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults?revision=2011-06-01&module=ietf-netconf-with-defaultshttp://tail-f.com/ns/mibs/SNMP-NOTIFICATION-MIB/200210140000Z?module=SNMP-NOTIFICATION-MIB&revision=2002-10-14urn:ietf:params:xml:ns:yang:ietf-system?module=ietf-system&revision=2012-06-30&features=timezone-location,ntp,local-users,crypt-hash-md5,authentication,radius,crypt-hash-sha-512,radius-authentication,crypt-hash-sha-256urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&revision=2010-09-24http://tail-f.com/yang/netconf-monitoring?module=tailf-netconf-monitoring&revision=2012-06-14urn:ietf:params:netconf:capability:validate:1.1urn:ietf:params:netconf:capability:notification:1.0http://tail-f.com/ns/mibs/TRANSPORT-ADDRESS-MIB/200211010000Z?module=TRANSPORT-ADDRESS-MIB&revision=2002-11-01urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=explicit&also-supported=report-all-taggedurn:ietf:params:netconf:capability:validate:1.0urn:ietf:params:netconf:base:1.0http://tail-f.com/yang/confd-monitoring?module=tailf-confd-monitoring&revision=2012-11-08http://tail-f.com/ns/mibs/SNMPv2-TC/1.0?module=SNMPv2-TCurn:ietf:params:netconf:base:1.1http://tail-f.com/ns/mibs/SNMPv2-MIB/200210160000Z?module=SNMPv2-MIB&revision=2002-10-16http://tail-f.com/ns/mibs/SNMP-VIEW-BASED-ACM-MIB/200210160000Z?module=SNMP-VIEW-BASED-ACM-MIB&revision=2002-10-16urn:ietf:params:netconf:capability:xpath:1.0http://tail-f.com/ns/mibs/SNMP-TARGET-MIB/200210140000Z?module=SNMP-TARGET-MIB&revision=2002-10-14http://tail-f.com/ns/mibs/SNMP-FRAMEWORK-MIB/200210140000Z?module=SNMP-FRAMEWORK-MIB&revision=2002-10-14http://btisystems.com/ns/atlas-internal?module=atlas-internal&revision=2013-05-24http://btisystems.com/ns/atlas-types?module=atlas-types&revision=2012-06-25urn:ietf:params:netconf:capability:writable-running:1.0http://tail-f.com/ns/mibs/SNMP-USER-BASED-SM-MIB/200210160000Z?module=SNMP-USER-BASED-SM-MIB&revision=2002-10-16http://tail-f.com/ns/netconf/actions/1.0urn:ietf:params:netconf:capability:candidate:1.0http://tail-f.com/ns/mibs/SNMP-COMMUNITY-MIB/200308060000Z?module=SNMP-COMMUNITY-MIB&revision=2003-08-06http://btisystems.com/ns/atlas-interfaces?module=atlas-interfaces&revision=2013-10-18urn:ietf:params:xml:ns:yang:ietf-netconf-notifications?module=ietf-netconf-notifications&revision=2012-02-06http://tail-f.com/ns/mibs/SNMP-MPD-MIB/200210140000Z?module=SNMP-MPD-MIB&revision=2002-10-14http://tail-f.com/ns/mibs/ATLAS-NOTIFICATIONS-MIB/201401230000Z?module=ATLAS-NOTIFICATIONS-MIB&revision=2014-01-23urn:ietf:params:netconf:capability:rollback-on-error:1.0urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-types&revision=2010-09-24http://tail-f.com/yang/common-monitoring?module=tailf-common-monitoring&revision=2012-11-08urn:ietf:params:netconf:capability:url:1.0?scheme=ftp,sftp,filehttp://btisystems.com/ns/atlas-products?module=atlas-productshttp://tail-f.com/ns/mibs/SNMPv2-SMI/1.0?module=SNMPv2-SMIAtlas_7800_Adi1true
Hello Kanika
I agree with you and appreciate your help.
Let us get the discover part working
Thanks and Regards
Adi
Hello Kanika
Any breakthrough?
Thanks
Adi
Hi Adi,
As per the output you have posted above, your netconf device is discovered in controller. You should be able to see it in your controller gui now (http://localhost:8080/)
Also you can use postman in chrome to see restconf output in json format.
-Kanika
Hello Kanika
I tried going to http://:8080 as Im not on localhost but i was not able to see the discovered node.
Is there any way we can get on a chat/email so that we can resolve this faster?
Appreciate all your help
Adi
i ment http://:8080
for some reason it is removing the ip-address …
I enabled debug logging for netconf and below is a snippet of the same. I’m still not seeing the node in the GUI
&revision=2014-01-23, urn:ietf:params:netconf:capability:rollback-on-error:1.0, urn:ietf:params:xml:ns:yang:ietf-yang-types?m
odule=ietf-yang-types&revision=2010-09-24, http://tail-f.com/yang/common-monitoring?module=tailf-common-monitoring&revision=2
012-11-08, urn:ietf:params:netconf:capability:url:1.0?scheme=ftp,sftp,file, http://btisystems.com/ns/atlas-products?module=at
las-products, http://tail-f.com/ns/mibs/SNMPv2-SMI/1.0?module=SNMPv2-SMI
2014-05-16 10:00:19.517 EDT [pool-29-thread-1] DEBUG o.o.c.s.c.n.NetconfDevice#Atlas7800Adi1 – Update device state transactio
n DOM-2 putting operational data started.
2014-05-16 10:00:19.517 EDT [pool-29-thread-1] DEBUG o.o.c.s.c.n.NetconfDevice#Atlas7800Adi1 – Update device state transactio
n DOM-2 putting operational data ended.
2014-05-16 10:00:19.520 EDT [pool-29-thread-1] DEBUG o.o.c.s.c.n.NetconfDevice#Atlas7800Adi1 – Update device state transactio
n DOM-2 SUCCESSFUL.
2014-05-16 10:00:44.663 EDT [http-bio-8080-exec-1] INFO o.o.c.u.internal.UserManager – Local Authentication Succeeded for Us
er: “admin”
2014-05-16 10:00:44.665 EDT [http-bio-8080-exec-1] INFO o.o.c.u.internal.UserManager – User “admin” authorized for the follo
wing role(s): [Network-Admin]
Also, on the browser, when I go to
http://10.128.4.210:8080/restconf/config/opendaylight-inventory:nodes/opendaylight-inventory:node/Atlas7800Adi1/yang-ext:mount/
I get,
Mount point does not contain any schema with modules.
Hi Adi,
Your device is there in MD-SAL but why controller gui is not showing it I am not sure. I am not sure if some bug has been introduced in latest controller version, I would suggest you to post your issues either on mailing list or ask.opendaylight.org – there is a wider audience to resolve your queries.
-Kanika
OK – thanks for your help so far. Will post a new question.
That will be great
It is gathered that opendaylight’s gui shows only flow capable devices and not netconf devices.
HI kanika / Adi
I would also like to simulate the same, can you please let me know the netconf server which you guys are using ? Are you using any virtual devices which run netconf server ?
Regards
phani
Hi Phani,
I used a netconf enabled device and seems Adi also had a device on which netconf was running.
If you do not have such a device – look at below link:
https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Using_netopeer_netconf_server_instead_of_a_real_device
-Kanika
Thanks for the prompt reply kanika..
Have learnt a lot about SDN,ODL from your blog..The tutorials are very informative .
Will definitely try netopeer and check how it works..
Which Network devices are netconf enabled ?, I mean real devices supporting (yang/netconf) .
Regards
phani
Thanks phani, glad to hear that tutorials could be of any help
Let me know how it goes with netopeer. Well there are couple of vendor specific devices which support netconf.
-Kanika
@Adi
Did your issue get resolved? If it was resolved could you please share how did you do it.
Hi Vignesh,
Have a look at follow up conversation here:
https://ask.opendaylight.org/question/82/yang-extmount-not-working/
-Kanika
HI
I could connect the ODL controller to the Netconf server by following the below link .
https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf
And was able to get the config/operational data from the device through the RESTCONF API’s using yang-ext:mount module in RESTCONF URL
How does the APPS running on the ODL access the Device yang data , IS there a way for which MD-SAL would generate the JAVA interfaces for the Yang models learnt from the device , so that Applications running on the ODL could access the device yang data by implementing the auto generated java classes..
Does MD-SAL save the device yang models data on any local data store on the controller ?
Would like to understand the role played by MD_SAL in providing the services for the Applications running on the ODL to access the device yang data..
Your help is very much appreciated…
Thanks & Regards
Phani
Hi,
I am trying to connect remote netconf server to ODL and facing the below issue:
2014-08-21 12:39:19.114 IST [remote-connector-processing-executor-2] ERROR o.o.c.s.c.netconf.NetconfDevice – RemoteDevice{sachi}: Initialization in sal failed, disconnecting from device
java.lang.NullPointerException: null
at org.opendaylight.controller.sal.connect.netconf.NetconfStateSchemas.create(NetconfStateSchemas.java:128) ~[na:na]
at org.opendaylight.controller.sal.connect.netconf.NetconfStateSchemas.create(NetconfStateSchemas.java:118) ~[na:na]
at org.opendaylight.controller.sal.connect.netconf.NetconfStateSchemas.access$000(NetconfStateSchemas.java:35) ~[na:na]
at org.opendaylight.controller.sal.connect.netconf.NetconfStateSchemas$NetconfStateSchemasResolverImpl.resolve(NetconfStateSchemas.java:53) ~[na:na]
at org.opendaylight.controller.sal.connect.netconf.NetconfDevice$DeviceSourcesResolver.call(NetconfDevice.java:222) ~[na:na]
at org.opendaylight.controller.sal.connect.netconf.NetconfDevice$DeviceSourcesResolver.call(NetconfDevice.java:202) ~[na:na]
at java.util.concurrent.FutureTask.run(FutureTask.java:262) ~[na:1.7.0_55]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_55]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_55]
at java.lang.Thread.run(Thread.java:744) [na:1.7.0_55]
2014-08-21 12:39:19.115 IST [remote-connector-processing-executor-2] WARN o.o.c.s.c.n.l.NetconfDeviceCommunicator – RemoteDevice{sachi}: Session terminated Session closed
Hi,in place of name,port,USERNAME,IP_ADDRESS,PASSWORD I made changes and have run the controller.But there was a error
Unrecognised elements [XmlElement{name='worker-thread-group', namespace='urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf'}, XmlElement{name='boss-thread-group', namespace='urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf'}] in XmlElement{name=’module’, namespace=’urn:opendaylight:params:xml:ns:yang:controller:config’}, errorType=application, errorTag=invalid_value, errorSeverity=error, errorInfo={}}
So,could you please tell me the port here indicates the port on which controller is running or something else.And is the name mentioned here should be also given to netconf server?.So please tell me what are these parameters i.e name,port,username,ip address,password.
Thanks and Regards,
Jayasree
Hi All,
A very well written blog.
I am using Lithium release of ODL (Karaf distribution) and am trying to play with my Netconf Server from ODL’s Netconf Connector.
For this, I have created Netconf Server from Docker image and Netconf Connector as mentioned in this link : http://sdnhub.org/tutorials/opendaylight-tutorial/experimenting-with-netconf-connector-in-opendaylight/
Being said that, in this blog, you have mentioned that “You can also perform get-config on the device and view the configuration data using below RESTCONF URL:
http://localhost:8080/restconf/config/opendaylight-inventory:nodes/opendaylight-inventory:node//yang-ext:mount/”
But, using this I am not able to do get-config, edit-config (and other Netconf operations).
Please, do let us know how to do these Netconf operations using RESTCONF URLs.
Do RESTCONF have such URLs, if yes then what are they,or I have to use NETCONF itself ?
Thanks and Regards,
Girija Sharan Singh
Hello Kanika ,
I found this community very interactive and impressive. And I am the new one to get stuck in this netconf stuff. In hope of getting some suggestion, I am posting this with overview and my target.
Target : connect ODL to remote netconf server over SSH using dlux UI
I am trying to connect ODL to remote NECTCONF server named confd with IP 212.51.104.200 over port 830, query its capabilities and fetch some data using some of those capabilities using dlux gui
Created a VM with Ubuntu 16.04 platform and using ODL-Beryllium as SDN controller
Steps taken:
1)Installed Java 8 with “export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64″ appended to ” $ nano .profile”
2)I installed ODL-Be with odl-netconf-connector-all,odl-restconfall,odl-netconf-connector-ssh,odl-dlux-all feature installed and activated successfully
3)created ssh keys. Public ssh key is installed in confd server( please note that the ODL intends to connect to remote server via netconf over ssh, for the same public key of ODL is installed in the remote server)
mkdir ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t rsa
Results/verficiation :
athapa@ubuntu:~$ ssh -v -p 830 212.51.104.200
I get connected succesfully
athapa@ubuntu:~$ ssh -s -p 830 212.51.104.200 netconf
all the capabilities of remote device is listed
But, when I try to spawn a new connector via dlux, with following URL in http://localhost:8181/apidoc/explorer/index.html (under mounted resources, in network-topology:network-topology/topology/topology-netconf/node/controller-config/ :
POST
http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-xt:mount/config:modules
with sript:
{
“module”: [
{
"type": "odl-sal-netconf-connector-cfg:sal-netconf-connector",
"name": "confd",
"odl-sal-netconf-connector-cfg:address": "212.51.104.200",
"odl-sal-netconf-connector-cfg:port": 830,
"odl-sal-netconf-connector-cfg:username": false,
"odl-sal-netconf-connector-cfg:password": false,
"odl-sal-netconf-connector-cfg:tcp-only": false,
"odl-sal-netconf-connector-cfg:event-executor": {
"name": "global-event-executor",
"type": "netty:netty-event-executor"
},
"odl-sal-netconf-connector-cfg:binding-registry": {
"name": "binding-osgi-broker",
"type": "opendaylight-md-sal-binding:binding-broker-osgi-registry"
},
"odl-sal-netconf-connector-cfg:dom-registry": {
"name": "dom-broker",
"type": "opendaylight-md-sal-dom:dom-broker-osgi-registry"
},
"odl-sal-netconf-connector-cfg:client-dispatcher": {
"name": "global-netconf-dispatcher",
"type": "odl-netconf-cfg:netconf-client-dispatcher"
},
"odl-sal-netconf-connector-cfg:processing-executor": {
"name": "global-netconf-processing-executor",
"type": "threadpool:threadpool"
},
"odl-sal-netconf-connector-cfg:keepalive-executor": {
"name": "global-netconf-ssh-scheduled-executor",
"type": "threadpool:scheduled-threadpool"
},
"odl-sal-netconf-connector-cfg:reconnect-on-changed-schema": true
}
]
}
The code executes successfully and I can see confd node in UI of dulx.But in the topology tab nothing is seen yet
But when I check in http://localhost:8181/apidoc/explorer/index.html , under controller resources tab, in network topology 2013-07-21, then use following url :
GET http://localhost:8181/restconf/operational/network-topology:network-topology
I get following respionse:
{
“node-id”: “confd”,
“netconf-node-topology:host”: “212.51.104.200″,
“netconf-node-topology:port”: 830,
“netconf-node-topology:connection-status”: “connecting”
}
]
},
{
“topology-id”: “flow:1″
}
As you can see the status is connecting when I try to connect remote NETCONF via dlux. This is on my nerves from a week now and I have tired everything.
Kindly suggest.
Hi Kanika,
Do you have any documentation on “How To Connect To Netconf Server Using OpenDaylight Netconf Plugin using java apis”
I have to thank you for the efforts you’ve put in writing
this site. I am hoping to see the same high-grade blog posts from you later on as well.
In fact, your creative writing abilities has encouraged me to get my own blog now
Definitely imagine that which you said. Your fazvourite justification appeared to be on the net
the easiest factor to be aware of. I say to you, I certainly get annoyed at
the same time as other folks consiuder worries that they just don’t recognise about.
You controlled to hit the nail upin the highest and defined out the entire
thing without having side-effects , folks could take
a signal. Will probably be back to get more.
Thanks
Oh wow that’s so easy hahaha jeeez