Date   

Netconf with LINC switch

Madhusudhan Kandadai <madhusudhan.opendaylight@...>
 

Hello,

I am working on Netconf using LINC switch. (For tracking purpose, bug 606 is created)

1.  I am able to create netconf session between client and server using LINC openflow switch. I got hello message from netconf server:

ssh -v -p 1830 -l linc -s 10.125.136.44 netconf
<?xml version="1.0" encoding="UTF-8"?><hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><capabilities><capability>urn:ietf:params:netconf:base:1.1</capability><capability>urn:ietf:params:netconf:capability:startup:1.0</capability><capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability></capabilities><session-id>3</session-id></hello>]]>]]>

2. When I do GET response 


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<nodes 
    xmlns="urn:opendaylight:inventory">
    <node>
        <initial-capability 
            xmlns="urn:opendaylight:netconf-node-inventory">urn:ietf:params:netconf:capability:writable-running:1.0
        </initial-capability>
        <initial-capability 
            xmlns="urn:opendaylight:netconf-node-inventory">urn:ietf:params:netconf:capability:startup:1.0
        </initial-capability>
        <initial-capability 
            xmlns="urn:opendaylight:netconf-node-inventory">urn:ietf:params:netconf:base:1.1
        </initial-capability>
        <id>libnetconfd</id>
        <connected 
            xmlns="urn:opendaylight:netconf-node-inventory">true
        </connected>
    </node>
</nodes>

3. I am currently in the process of LINC integration with Mininet, so I can get both the topology information as well as netconf configuration.

4. I would like to do the following basic netconf operations: 

(a) get Netconf session details 
(b) retrieve running configuration and device state configuration
(c) how to copy/delete the configuration
(d) close and kill the netconf session

I am not sure how to do it. Can someone shed some light on this?

Thanks,
Madhusudhan


Re: Testing BGP in controller with exabgp

FREEMAN, BRIAN D <bf1936@...>
 

Moiz,

 

I got ODL bgpcep to talk to exabgp in my environment. I was using a git clone of the bgpcep tree not the Hydrogen release snapshot.

 

Couple of things that I tripped over.

 

1.       As you confirmed, the IP addresses  in step 3 and 4 were reversed. This might help folks going forward for how to update their files.

41-bgp-example.xml:                    <host>EXABGP_IP_ADDRESS</host>

41-bgp-example.xml:                    <bgp-id>ODL_IP_ADDRESS</bgp-id>

single-neighbor.txt:neighbor ODL_IP_ADDRESS{

single-neighbor.txt:    router-id EXABGP_IP_ADDRESS;

single-neighbor.txt:    local-address EXABGP_IP_ADDRESS;

 

2.       ODL is not listening , it only initiates sessions,   and Exabgp is not listening by default.

a.       If in wireshark you see SYN<->RST,ACK from both side then check to make sure the Exabgp was started to listen on its IP address.

b.      The environment “exabgp.tcp.bind” needs to be set to have Exabgp listen (as indicated in your  instructions)

env exabgp.tcp.bind="EXABGP_IP_ADDRESS" exabgp.tcp.port=179 exabgp.log.all=true exabgp single-neighbor.txt
Note: env bgp.tcp.bind=… is wrong and since its an environment variable Exabgp won’t complain about the typo of leaving off the leading “exa”  
J.

 

3.       I tried some RESTCONF API to view the information but wasn’t able to see any data but I probably didn’t understand the right syntax to view the routes learned from Exabgp

a.       For example: http://xxxx:8080/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/

4.       I tried to create an LSP via the RESTCONF API
http://xxxx:8080/restconf/operations/network-topology-pcep:add-lsp (with xml) and got an Unsent message back.

osgi> 2014-04-04 20:00:45.397 GMT+00:00 [pool-14-thread-1] DEBUG o.o.b.p.t.p.ServerSessionManager - Session for node Uri [_value=pcc://yyyy] not found

I assume that because we don’t have a PCC session setup to Exabgp (and not sure it can terminate a PCC session anyway).

 

Thanks for the BGP-LS and Exabgp setup !

 

Brian

 

 

From: Moiz Raja (moraja) [mailto:moraja@...]
Sent: Monday, March 31, 2014 4:35 PM
To: FREEMAN, BRIAN D; Lakshman Mukkamalla (lmukkama)
Cc: integration-dev@...
Subject: Testing BGP in controller with exabgp

 

Hi Brian and Lakshman,

 

Here are my notes on how to setup controller and exabgp for testing. Please try it out and let me know if you run into any issues.

 

Regards,

-Moiz

 

-------------------------

 

 

Assumptions

 

1. You are using the open daylight test VM (https://wiki.opendaylight.org/view/CrossProject:Integration_Group:Test_VMs)

2. The open daylight test VM has python version 2.74

3. The IP address of the open daylight test VM is 192.168.56.99

4.The IP address of the machine running the opendaylight controller is 192.168.56.101

 

 

Setup a test with exabgp

 

(1) Install exabgp on the opendaylight test VM. This is not required but it is pretty convenient.

 

> wget https://github.com/Exa-Networks/exabgp/archive/3.3.2.tar.gz
> tar zxvf 3.3.2.tar.gz
> cd exabgp-3.3.2
> python setup.py install

 

(2) Download the latest service provider distribution from here

 

 

 

 

(4) Copy the attached single-neighbour.txt to the mininet machine

 

(5) Copy the attached 41-bgp-example.xml.txt to <opendaylight directory>/configuration/initial/41-bgp-example.xml

 

(6) Run exabgp like so,

 

     env exabgp.tcp.bind=192.168.56.101 exabgp.tcp.port=179 exabgp single-neighbor.txt

 

(7) Run controller like so,

 

     ./run.sh

 

(8) Wait for a minute or two.

 

(9) Now using rest conf you should be able to the see the bgp topology show up.

 

 

 

 


LISP SNAPSHOT version for distrbution

Luis Gomez
 


Hi devs,

The automatic adjust version job in Integration Jenkins has bumped the LISP SNAPSHOT version a few times lately, can you please tell which LISP version has to be used for SP distribution?


 <!-- lispflowmapping -->
397         <dependency>
398       <groupId>org.opendaylight.lispflowmapping</groupId>
399       <artifactId>mappingservice.yangmodel</artifactId>
400       <version>1.1.5-SNAPSHOT</version>
401     </dependency>
403     <dependency>
404       <groupId>org.opendaylight.lispflowmapping</groupId>
405       <artifactId>mappingservice.api</artifactId>
406       <version>1.1.5-SNAPSHOT</version>
407     </dependency>
408     
409     <dependency>
410       <groupId>org.opendaylight.lispflowmapping</groupId>
411       <artifactId>mappingservice.config</artifactId>
412       <version>1.1.5-SNAPSHOT</version>
413     </dependency>
415     <dependency>
416       <groupId>org.opendaylight.lispflowmapping</groupId>
417       <artifactId>mappingservice.implementation</artifactId>
418       <version>1.1.5-SNAPSHOT</version>
419     </dependency>
421     <dependency>
422       <groupId>org.opendaylight.lispflowmapping</groupId>
423       <artifactId>mappingservice.northbound</artifactId>
424       <version>1.1.5-SNAPSHOT</version>
425     </dependency>
427     <dependency>
428       <groupId>org.opendaylight.lispflowmapping</groupId>
429       <artifactId>mappingservice.southbound</artifactId>
430       <version>1.1.5-SNAPSHOT</version>
431     </dependency>


Cisco submits code to opendaylight

Punal Patel
 


Re: [controller-dev] Netconf plugin testing

Madhusudhan Kandadai <madhusudhan.opendaylight@...>
 

Thank you Reinaldo. Presently, I have LINC switch, docker image for netopeer installed in VM. Anyways the responses from RESTAPI is found to be perfect. Looks like using docker image is working fine. But the problem at the OSGi command line is because of another configuration somewhere in my machine. 

Anyways I will see if there is any chance of getting another VM or clear all the configuration present in my machine so I can try to initiate netconf using LINC switch.Also, I have attached GET responses for your ready reference. Can you please let me know if I am missing something else?
 
Thanks,
Madhusudhan

On Tuesday, April 1, 2014 10:29 PM, Reinaldo Penno <rapenno@...> wrote:
Your errors seems a network problem. Maybe you have another configuration somewhere? I looked at "public abstract class AbstractNetconfSessionNegotiator" and the change in state happens when the Netconf session can not be established.

A breakpoint in the start() method will probably tell you what is going on

   private void start() {
        final NetconfMessage helloMessage = this.sessionPreferences.getHelloMessage();
        logger.debug("Session negotiation started with hello message {}", XmlUtil.toString(helloMessage.getDocument()));

        channel.pipeline().addLast(NAME_OF_EXCEPTION_HANDLER, new ExceptionHandlingInboundChannelHandler());

        timeout = this.timer.newTimeout(new TimerTask() {
            @Override
            public void run(final Timeout timeout) {
                synchronized (this) {
                    if (state != State.ESTABLISHED) {
                        logger.debug("Connection timeout after {}, session is in state {}", timeout, state);
                        final IllegalStateException cause = new IllegalStateException(
                                "Session was not established after " + timeout);
                        negotiationFailed(cause);
                        changeState(State.FAILED);
                    } else if(channel.isOpen()) {
                        channel.pipeline().remove(NAME_OF_EXCEPTION_HANDLER);
                    }
                }
            }
        }, connectionTimeoutMillis, TimeUnit.MILLISECONDS);

        // FIXME, make sessionPreferences return HelloMessage, move NetconfHelloMessage to API
        sendMessage((NetconfHelloMessage)helloMessage);
        changeState(State.OPEN_WAIT);
    }

Anyway

Just tested it. I did not see such an error.

GET http://127.0.0.1:8080/restconf/operational/opendaylight-inventory:nodes/node/libnetconfd/yang-ext:mount

{
    "data": {
        "toaster": {
            "toasterManufacturer": "CESNET, z.s.p.o.",
            "toasterModelNumber": "toaster",
            "toasterStatus": "down"
        },
        "netconf-state": {
            "datastores": {
                "datastore": [
                    {
                        "name": "running"
                    },
                    {
                        "name": "startup"
                    },
                    {
                        "name": "candidate"
                    }
                ]
            },
            "sessions": {
                "session": [
                    {
                        "session-id": 2529,
                        "transport": "netconf-ssh",
                        "username": "repenno",
                        "source-host": "10.0.1.14",
                        "login-time": "2014-04-02T05:13:47Z",
                        "in-rpcs": 14,
                        "in-bad-rpcs": 0,
                        "out-rpc-errors": 0,
                        "out-notifications": 0
                    }
                ]
            },
            "schemas": {
                "schema": [
                    {
                        "identifier": "toaster",
                        "version": "2009-11-20",
                        "format": "yin",
                        "namespace": "http://netconfcentral.org/ns/toaster",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "toaster",
                        "version": "2009-11-20",
                        "format": "yang",
                        "namespace": "http://netconfcentral.org/ns/toaster",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf-acm",
                        "version": "2012-02-22",
                        "format": "yin",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-netconf-acm",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf-acm",
                        "version": "2012-02-22",
                        "format": "yang",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-netconf-acm",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf-with-defaults",
                        "version": "2010-06-09",
                        "format": "yin",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf-with-defaults",
                        "version": "2010-06-09",
                        "format": "yang",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "notifications",
                        "version": "2008-07-14",
                        "format": "yin",
                        "namespace": "urn:ietf:params:xml:ns:netconf:notification:1.0",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "notifications",
                        "version": "2008-07-14",
                        "format": "yang",
                        "namespace": "urn:ietf:params:xml:ns:netconf:notification:1.0",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "nc-notifications",
                        "version": "2008-07-14",
                        "format": "yin",
                        "namespace": "urn:ietf:params:xml:ns:netmod:notification",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "nc-notifications",
                        "version": "2008-07-14",
                        "format": "yang",
                        "namespace": "urn:ietf:params:xml:ns:netmod:notification",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf-notifications",
                        "version": "2011-08-07",
                        "format": "yin",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-netconf-notifications",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf-notifications",
                        "version": "2011-08-07",
                        "format": "yang",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-netconf-notifications",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf-monitoring",
                        "version": "2010-10-04",
                        "format": "yin",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf-monitoring",
                        "version": "2010-10-04",
                        "format": "yang",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf",
                        "version": "2011-03-08",
                        "format": "yin",
                        "namespace": "urn:ietf:params:xml:ns:netconf:base:1.0",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf",
                        "version": "2011-03-08",
                        "format": "yang",
                        "namespace": "urn:ietf:params:xml:ns:netconf:base:1.0",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-yang-types",
                        "version": "2010-09-24",
                        "format": "yin",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-yang-types",
                        "version": "2010-09-24",
                        "format": "yang",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-inet-types",
                        "version": "2010-09-24",
                        "format": "yin",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-inet-types",
                        "version": "2010-09-24",
                        "format": "yang",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
                        "location": [
                            "NETCONF"
                        ]
                    }
                ]
            },
            "statistics": {
                "netconf-start-time": "2014-04-02T05:13:47Z",
                "in-bad-hellos": 0,
                "in-sessions": 1,
                "dropped-sessions": 0,
                "in-rpcs": 14,
                "in-bad-rpcs": 0,
                "out-rpc-errors": 0,
                "out-notifications": 0
            }
        },
        "netconf": {
            "streams": {
                "stream": [
                    {
                        "name": "NETCONF",
                        "description": "NETCONF Base Notifications",
                        "replaySupport": true,
                        "replayLogCreationTime": "2014-03-25T01:18:06Z"
                    }
                ]
            }
        },
        "nacm": {
            "denied-operations": 0,
            "denied-data-writes": 0,
            "denied-notifications": 0
        }
    }
}


On Tue, Apr 1, 2014 at 5:49 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Reinaldo,

I figured out my problem just now. That is because of incorrect port mentioned in 04-libnetconfd.xml. As I installed netopeer using docker and it uses port 1831:830 for talking to netconf server. So, I used port# 1831 in that xml, username & pwd as "root". Then, I am able to get the correct GET request as mentioned in the wiki. Have attached the response for your kind reference.

In the meanwhile, I am getting the error in OSGi command line: Did you face this error before:

2014-04-01 17:44:52.624 PDT [pool-39-thread-1] DEBUG o.o.c.n.u.AbstractNetconfSessionNegotiator - Connection timeout after HashedWheelTimeout(deadline: 1198888 ms ago, ), session is in state OPEN_WAIT
2014-04-01 17:44:52.632 PDT [pool-34-thread-2] ERROR o.o.c.s.c.n.NetconfDevice#libnetconfd - Netconf client NOT started. 
java.lang.IllegalStateException: Unable to create NetconfClient{label=libnetconfd, sessionId=0}
at org.opendaylight.controller.netconf.client.NetconfClient.get(NetconfClient.java:73) ~[na:na]
at org.opendaylight.controller.netconf.client.NetconfClient.<init>(NetconfClient.java:105) ~[na:na]
at org.opendaylight.controller.netconf.client.NetconfClient.clientFor(NetconfClient.java:83) ~[na:na]
at org.opendaylight.controller.sal.connect.netconf.NetconfDevice$3.run(NetconfDevice.java:268) ~[na:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_51]
at java.util.concurrent.FutureTask.run(FutureTask.java:262) [na:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: Session was not established after HashedWheelTimeout(deadline: 1483740 ms ago, )
at io.netty.util.concurrent.AbstractFuture.get(AbstractFuture.java:37) ~[na:na]
at org.opendaylight.controller.netconf.client.NetconfClient.get(NetconfClient.java:69) ~[na:na]
... 8 common frames omitted
Caused by: java.lang.IllegalStateException: Session was not established after HashedWheelTimeout(deadline: 1483740 ms ago, )
at org.opendaylight.controller.netconf.util.AbstractNetconfSessionNegotiator$2.run(AbstractNetconfSessionNegotiator.java:115) ~[na:na]
at io.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:542) ~[na:na]
at io.netty.util.HashedWheelTimer$Worker.notifyExpiredTimeouts(HashedWheelTimer.java:440) ~[na:na]
at io.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:381) ~[na:na]
... 1 common frames omitted
2014-04-01 17:44:52.633 PDT [pool-39-thread-1] DEBUG o.o.c.n.u.AbstractNetconfSessionNegotiator - Changing state from : OPEN_WAIT to : FAILED

Thanks,
Madhusudhan
On Tuesday, April 1, 2014 5:24 PM, Reinaldo Penno <rapenno@...> wrote:
I will test again later today and get back to you.

In the meantime, can you test something simple? Change header to <Accept: application/xml> and perform GET again.  I seem to remember an issue around that.

The error below seem network related. I will retest anyway.




On Tue, Apr 1, 2014 at 3:59 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Thanks Reinaldo.

I installed docker image mentioned at https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Docker_image and I am able to see the response sent by server in XML after doing "ssh root@localhost -p 1831 -s netconf."

I have created an xml mentioned at https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Editing_Netconf_Client_Configuration_by_Creating_Initial_Controller_Config_File and named it as "04-libnetconfd.xml". Have enabled the logs at logback.xml. After restarting the controller, when I issue GET request "http://localhost:8080/restconf/operational/opendaylight-inventory:nodes" I do get the following response:

{
    "nodes": {
        "node": [
            {
                "id": "libnetconfd"
            }
        ]
    }
}


Sorry for my repeated question.

Thanks,
Madhusudhan
On Friday, March 28, 2014 6:38 PM, Reinaldo Penno <rapenno@...> wrote:


On Fri, Mar 28, 2014 at 2:45 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Thanks Reinaldo. I have two scenarios in testing netconf SB plugin:

(a) Have LINC switch in another VM which actually runs netconf code. I tried to make it work in testing netconf plugin by starting LINC switch in another VM. Have changed IP address, username,port(I used 830 for ssh and put"false" in tcp-only), enabled the log. Unable to recollect where I got stuck. I am still refining it to get more details about this

(b) Have configured netopeer in another VM and followed the steps mentioned at https://groups.google.com/forum/#!topic/libnetconf/sVaj8tYYZC0. While doing make && make install for netopeer - server, 

I got this error: .obj/src/server_comm_dbus.o: In function `comm_loop':
server_comm_dbus.c:(.text+0xee3): undefined reference to `server_sessions_get_by_ncid'. This is similar to the one : http://pastebin.com/vcvZp4bm. I could not find any resolution there.

Just checking whether anyone working/worked on this netconf plugin faced this error before? If yes, could you advise on how to overcome this error?

Thanks,
Madhusudhan

On Tuesday, March 25, 2014 6:04 PM, Reinaldo Penno <rapenno@...> wrote:
okay, there seems a confusion.

ODL has an internal Netconf server. This server is used for configuration of internal ODL stuff. 

In order to test the Netconf SB plug-in you need an _external_ Netconf server device - outside ODL. This can be a number of devices or a stand-alone daemon like netopeer running Netconf Server code.










On Tue, Mar 25, 2014 at 4:42 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Hi Reinaldo,

I believe netconf server will be started automatically after starting the controller. Here is the following lines called from config.ini. (Please correct me if I am wrong)
 
# Netconf startup configuration
netconf.tcp.address=127.0.0.1
netconf.tcp.port=8383

netconf.tcp.client.address=127.0.0.1
netconf.tcp.client.port=8383

netconf.ssh.address=0.0.0.0
netconf.ssh.port=1830
netconf.ssh.pk.path = ./configuration/RSA.pk


so, do you think I have to change the ip address, port#, which are defined at 02-libnetconfd.xml according to the one mentioned above? If not, can you please shed some light on this ? Sorry if this is a basic question.

Thanks,
Madhusudhan

On Monday, March 24, 2014 8:20 PM, Reinaldo Penno <rapenno@...> wrote:
Which device are you using as a netconf server? You have to substitute the IP address on the example by the IP address of your  netconf device. You need to make sure netconf is running on the device, etc.




On Mon, Mar 24, 2014 at 7:52 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Thanks Reinaldo. I actually took the latest controller from wget https://jenkins.opendaylight.org/integration/job/integration-project-centralized-integration/lastSuccessfulBuild/artifact/distributions/base/target/distributions-base-0.1.2-SNAPSHOT-osgipackage.zip, created a file named "04-libnetconfd.xml" in opendaylight/configuration/initial

Then started the controller using of13 plugin, but I could not see any notification like this:

2014-02-12 04:42:10.043 PST [pool-23-thread-1] INFO  o.o.c.s.c.n.NetconfDevice#libnetconfd - Starting Netconf Client on: /10.0.1.27:830

Am I doing something wrong?

Thanks,
Madhusudhan


On Monday, March 24, 2014 7:37 PM, Reinaldo Penno <rapenno@...> wrote:
If the file is correct, nothing else is needed and a netconf session will be established between ODL and netconf server (device)
 


On Mon, Mar 24, 2014 at 4:45 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Hello,

I am interested in performing testing on netconf plugin. I have netconf server and just want to configure ODL. I have gone through the below links on how to test netconf plugin: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf and https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf:Example_Configuration

If I understand correctly:

1. Should I need to configure yumapro-13.04. If yes, I found the documentation at https://github.com/pikagrue/test-repository-2/tree/master/yumapro-13.04. I am trying hard to install yumapro-13.04 and can you point me the right link for installing the same.
2. Once done with the above step, I *think* I can go to this step https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Connecting_to_the_Controller_Configuration_Server and follow the sequence in order.

Does anybody worked on testing netconf plugin, so I need to ask the sequence to get familiar in testing netconf plugin.

Thanks in advance!

Madhusudhan

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev




















Errors in OSGi console

Luis Gomez
 


Re: Sonar reporting

Luis Gomez
 

Thanks Andy,

I think the first step is to identify what needs to be done by the committers as I did not finding any wiki explaining this. This is why we need you.

Second is to contact the project committers, ask them to include the Sonar scan and come up with some sort of agreement for a recommended code coverage. This is why we need people from integration or other ODL group to drive this.

BR/Luis

On Apr 2, 2014, at 7:49 AM, Andrew Grimberg <agrimberg@...> wrote:

On Tue, 2014-04-01 at 20:58 -0700, Luis Gomez wrote:
We did have some discussion around Sonar code coverage reporting
during the past Hackfest. Is anybody in the group interested to work
with Andy on what is needed for reporting and also work later on a
recommendation proposal for all projects contributing in ODL?
It's not really working with me but with the projects that don't
currently do sonar scans. It's at the job level. Yes, I can modify any
job in the system, but it really should be the committers from a given
project doing the changes.

-Andy-

--
Andrew J Grimberg
Systems Administrator
The Linux Foundation


Re: Sonar reporting

Andrew Grimberg
 

On Tue, 2014-04-01 at 20:58 -0700, Luis Gomez wrote:
We did have some discussion around Sonar code coverage reporting
during the past Hackfest. Is anybody in the group interested to work
with Andy on what is needed for reporting and also work later on a
recommendation proposal for all projects contributing in ODL?
It's not really working with me but with the projects that don't
currently do sonar scans. It's at the job level. Yes, I can modify any
job in the system, but it really should be the committers from a given
project doing the changes.

-Andy-

--
Andrew J Grimberg
Systems Administrator
The Linux Foundation


Re: [controller-dev] Netconf plugin testing

Reinaldo Penno <rapenno@...>
 

Your errors seems a network problem. Maybe you have another configuration somewhere? I looked at "public abstract class AbstractNetconfSessionNegotiator" and the change in state happens when the Netconf session can not be established.

A breakpoint in the start() method will probably tell you what is going on

   private void start() {
        final NetconfMessage helloMessage = this.sessionPreferences.getHelloMessage();
        logger.debug("Session negotiation started with hello message {}", XmlUtil.toString(helloMessage.getDocument()));

        channel.pipeline().addLast(NAME_OF_EXCEPTION_HANDLER, new ExceptionHandlingInboundChannelHandler());

        timeout = this.timer.newTimeout(new TimerTask() {
            @Override
            public void run(final Timeout timeout) {
                synchronized (this) {
                    if (state != State.ESTABLISHED) {
                        logger.debug("Connection timeout after {}, session is in state {}", timeout, state);
                        final IllegalStateException cause = new IllegalStateException(
                                "Session was not established after " + timeout);
                        negotiationFailed(cause);
                        changeState(State.FAILED);
                    } else if(channel.isOpen()) {
                        channel.pipeline().remove(NAME_OF_EXCEPTION_HANDLER);
                    }
                }
            }
        }, connectionTimeoutMillis, TimeUnit.MILLISECONDS);

        // FIXME, make sessionPreferences return HelloMessage, move NetconfHelloMessage to API
        sendMessage((NetconfHelloMessage)helloMessage);
        changeState(State.OPEN_WAIT);
    }

Anyway

Just tested it. I did not see such an error.

GET http://127.0.0.1:8080/restconf/operational/opendaylight-inventory:nodes/node/libnetconfd/yang-ext:mount

{
    "data": {
        "toaster": {
            "toasterManufacturer": "CESNET, z.s.p.o.",
            "toasterModelNumber": "toaster",
            "toasterStatus": "down"
        },
        "netconf-state": {
            "datastores": {
                "datastore": [
                    {
                        "name": "running"
                    },
                    {
                        "name": "startup"
                    },
                    {
                        "name": "candidate"
                    }
                ]
            },
            "sessions": {
                "session": [
                    {
                        "session-id": 2529,
                        "transport": "netconf-ssh",
                        "username": "repenno",
                        "source-host": "10.0.1.14",
                        "login-time": "2014-04-02T05:13:47Z",
                        "in-rpcs": 14,
                        "in-bad-rpcs": 0,
                        "out-rpc-errors": 0,
                        "out-notifications": 0
                    }
                ]
            },
            "schemas": {
                "schema": [
                    {
                        "identifier": "toaster",
                        "version": "2009-11-20",
                        "format": "yin",
                        "namespace": "http://netconfcentral.org/ns/toaster",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "toaster",
                        "version": "2009-11-20",
                        "format": "yang",
                        "namespace": "http://netconfcentral.org/ns/toaster",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf-acm",
                        "version": "2012-02-22",
                        "format": "yin",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-netconf-acm",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf-acm",
                        "version": "2012-02-22",
                        "format": "yang",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-netconf-acm",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf-with-defaults",
                        "version": "2010-06-09",
                        "format": "yin",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf-with-defaults",
                        "version": "2010-06-09",
                        "format": "yang",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "notifications",
                        "version": "2008-07-14",
                        "format": "yin",
                        "namespace": "urn:ietf:params:xml:ns:netconf:notification:1.0",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "notifications",
                        "version": "2008-07-14",
                        "format": "yang",
                        "namespace": "urn:ietf:params:xml:ns:netconf:notification:1.0",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "nc-notifications",
                        "version": "2008-07-14",
                        "format": "yin",
                        "namespace": "urn:ietf:params:xml:ns:netmod:notification",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "nc-notifications",
                        "version": "2008-07-14",
                        "format": "yang",
                        "namespace": "urn:ietf:params:xml:ns:netmod:notification",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf-notifications",
                        "version": "2011-08-07",
                        "format": "yin",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-netconf-notifications",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf-notifications",
                        "version": "2011-08-07",
                        "format": "yang",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-netconf-notifications",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf-monitoring",
                        "version": "2010-10-04",
                        "format": "yin",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf-monitoring",
                        "version": "2010-10-04",
                        "format": "yang",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf",
                        "version": "2011-03-08",
                        "format": "yin",
                        "namespace": "urn:ietf:params:xml:ns:netconf:base:1.0",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-netconf",
                        "version": "2011-03-08",
                        "format": "yang",
                        "namespace": "urn:ietf:params:xml:ns:netconf:base:1.0",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-yang-types",
                        "version": "2010-09-24",
                        "format": "yin",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-yang-types",
                        "version": "2010-09-24",
                        "format": "yang",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-inet-types",
                        "version": "2010-09-24",
                        "format": "yin",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
                        "location": [
                            "NETCONF"
                        ]
                    },
                    {
                        "identifier": "ietf-inet-types",
                        "version": "2010-09-24",
                        "format": "yang",
                        "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
                        "location": [
                            "NETCONF"
                        ]
                    }
                ]
            },
            "statistics": {
                "netconf-start-time": "2014-04-02T05:13:47Z",
                "in-bad-hellos": 0,
                "in-sessions": 1,
                "dropped-sessions": 0,
                "in-rpcs": 14,
                "in-bad-rpcs": 0,
                "out-rpc-errors": 0,
                "out-notifications": 0
            }
        },
        "netconf": {
            "streams": {
                "stream": [
                    {
                        "name": "NETCONF",
                        "description": "NETCONF Base Notifications",
                        "replaySupport": true,
                        "replayLogCreationTime": "2014-03-25T01:18:06Z"
                    }
                ]
            }
        },
        "nacm": {
            "denied-operations": 0,
            "denied-data-writes": 0,
            "denied-notifications": 0
        }
    }
}


On Tue, Apr 1, 2014 at 5:49 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Reinaldo,

I figured out my problem just now. That is because of incorrect port mentioned in 04-libnetconfd.xml. As I installed netopeer using docker and it uses port 1831:830 for talking to netconf server. So, I used port# 1831 in that xml, username & pwd as "root". Then, I am able to get the correct GET request as mentioned in the wiki. Have attached the response for your kind reference.

In the meanwhile, I am getting the error in OSGi command line: Did you face this error before:

2014-04-01 17:44:52.624 PDT [pool-39-thread-1] DEBUG o.o.c.n.u.AbstractNetconfSessionNegotiator - Connection timeout after HashedWheelTimeout(deadline: 1198888 ms ago, ), session is in state OPEN_WAIT
2014-04-01 17:44:52.632 PDT [pool-34-thread-2] ERROR o.o.c.s.c.n.NetconfDevice#libnetconfd - Netconf client NOT started. 
java.lang.IllegalStateException: Unable to create NetconfClient{label=libnetconfd, sessionId=0}
at org.opendaylight.controller.netconf.client.NetconfClient.get(NetconfClient.java:73) ~[na:na]
at org.opendaylight.controller.netconf.client.NetconfClient.<init>(NetconfClient.java:105) ~[na:na]
at org.opendaylight.controller.netconf.client.NetconfClient.clientFor(NetconfClient.java:83) ~[na:na]
at org.opendaylight.controller.sal.connect.netconf.NetconfDevice$3.run(NetconfDevice.java:268) ~[na:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_51]
at java.util.concurrent.FutureTask.run(FutureTask.java:262) [na:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: Session was not established after HashedWheelTimeout(deadline: 1483740 ms ago, )
at io.netty.util.concurrent.AbstractFuture.get(AbstractFuture.java:37) ~[na:na]
at org.opendaylight.controller.netconf.client.NetconfClient.get(NetconfClient.java:69) ~[na:na]
... 8 common frames omitted
Caused by: java.lang.IllegalStateException: Session was not established after HashedWheelTimeout(deadline: 1483740 ms ago, )
at org.opendaylight.controller.netconf.util.AbstractNetconfSessionNegotiator$2.run(AbstractNetconfSessionNegotiator.java:115) ~[na:na]
at io.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:542) ~[na:na]
at io.netty.util.HashedWheelTimer$Worker.notifyExpiredTimeouts(HashedWheelTimer.java:440) ~[na:na]
at io.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:381) ~[na:na]
... 1 common frames omitted
2014-04-01 17:44:52.633 PDT [pool-39-thread-1] DEBUG o.o.c.n.u.AbstractNetconfSessionNegotiator - Changing state from : OPEN_WAIT to : FAILED

Thanks,
Madhusudhan
On Tuesday, April 1, 2014 5:24 PM, Reinaldo Penno <rapenno@...> wrote:
I will test again later today and get back to you.

In the meantime, can you test something simple? Change header to <Accept: application/xml> and perform GET again.  I seem to remember an issue around that.

The error below seem network related. I will retest anyway.




On Tue, Apr 1, 2014 at 3:59 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Thanks Reinaldo.

I installed docker image mentioned at https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Docker_image and I am able to see the response sent by server in XML after doing "ssh root@localhost -p 1831 -s netconf."

I have created an xml mentioned at https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Editing_Netconf_Client_Configuration_by_Creating_Initial_Controller_Config_File and named it as "04-libnetconfd.xml". Have enabled the logs at logback.xml. After restarting the controller, when I issue GET request "http://localhost:8080/restconf/operational/opendaylight-inventory:nodes" I do get the following response:

{
    "nodes": {
        "node": [
            {
                "id": "libnetconfd"
            }
        ]
    }
}


Sorry for my repeated question.

Thanks,
Madhusudhan
On Friday, March 28, 2014 6:38 PM, Reinaldo Penno <rapenno@...> wrote:


On Fri, Mar 28, 2014 at 2:45 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Thanks Reinaldo. I have two scenarios in testing netconf SB plugin:

(a) Have LINC switch in another VM which actually runs netconf code. I tried to make it work in testing netconf plugin by starting LINC switch in another VM. Have changed IP address, username,port(I used 830 for ssh and put"false" in tcp-only), enabled the log. Unable to recollect where I got stuck. I am still refining it to get more details about this

(b) Have configured netopeer in another VM and followed the steps mentioned at https://groups.google.com/forum/#!topic/libnetconf/sVaj8tYYZC0. While doing make && make install for netopeer - server, 

I got this error: .obj/src/server_comm_dbus.o: In function `comm_loop':
server_comm_dbus.c:(.text+0xee3): undefined reference to `server_sessions_get_by_ncid'. This is similar to the one : http://pastebin.com/vcvZp4bm. I could not find any resolution there.

Just checking whether anyone working/worked on this netconf plugin faced this error before? If yes, could you advise on how to overcome this error?

Thanks,
Madhusudhan

On Tuesday, March 25, 2014 6:04 PM, Reinaldo Penno <rapenno@...> wrote:
okay, there seems a confusion.

ODL has an internal Netconf server. This server is used for configuration of internal ODL stuff. 

In order to test the Netconf SB plug-in you need an _external_ Netconf server device - outside ODL. This can be a number of devices or a stand-alone daemon like netopeer running Netconf Server code.










On Tue, Mar 25, 2014 at 4:42 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Hi Reinaldo,

I believe netconf server will be started automatically after starting the controller. Here is the following lines called from config.ini. (Please correct me if I am wrong)
 
# Netconf startup configuration
netconf.tcp.address=127.0.0.1
netconf.tcp.port=8383

netconf.tcp.client.address=127.0.0.1
netconf.tcp.client.port=8383

netconf.ssh.address=0.0.0.0
netconf.ssh.port=1830
netconf.ssh.pk.path = ./configuration/RSA.pk


so, do you think I have to change the ip address, port#, which are defined at 02-libnetconfd.xml according to the one mentioned above? If not, can you please shed some light on this ? Sorry if this is a basic question.

Thanks,
Madhusudhan

On Monday, March 24, 2014 8:20 PM, Reinaldo Penno <rapenno@...> wrote:
Which device are you using as a netconf server? You have to substitute the IP address on the example by the IP address of your  netconf device. You need to make sure netconf is running on the device, etc.




On Mon, Mar 24, 2014 at 7:52 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Thanks Reinaldo. I actually took the latest controller from wget https://jenkins.opendaylight.org/integration/job/integration-project-centralized-integration/lastSuccessfulBuild/artifact/distributions/base/target/distributions-base-0.1.2-SNAPSHOT-osgipackage.zip, created a file named "04-libnetconfd.xml" in opendaylight/configuration/initial

Then started the controller using of13 plugin, but I could not see any notification like this:

2014-02-12 04:42:10.043 PST [pool-23-thread-1] INFO  o.o.c.s.c.n.NetconfDevice#libnetconfd - Starting Netconf Client on: /10.0.1.27:830

Am I doing something wrong?

Thanks,
Madhusudhan


On Monday, March 24, 2014 7:37 PM, Reinaldo Penno <rapenno@...> wrote:
If the file is correct, nothing else is needed and a netconf session will be established between ODL and netconf server (device)
 


On Mon, Mar 24, 2014 at 4:45 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Hello,

I am interested in performing testing on netconf plugin. I have netconf server and just want to configure ODL. I have gone through the below links on how to test netconf plugin: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf and https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf:Example_Configuration

If I understand correctly:

1. Should I need to configure yumapro-13.04. If yes, I found the documentation at https://github.com/pikagrue/test-repository-2/tree/master/yumapro-13.04. I am trying hard to install yumapro-13.04 and can you point me the right link for installing the same.
2. Once done with the above step, I *think* I can go to this step https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Connecting_to_the_Controller_Configuration_Server and follow the sequence in order.

Does anybody worked on testing netconf plugin, so I need to ask the sequence to get familiar in testing netconf plugin.

Thanks in advance!

Madhusudhan

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev


















Sonar reporting

Luis Gomez
 

Hi all,

We did have some discussion around Sonar code coverage reporting during the past Hackfest. Is anybody in the group interested to work with Andy on what is needed for reporting and also work later on a recommendation proposal for all projects contributing in ODL?

https://sonar.opendaylight.org

Thanks/Luis


Re: Bridge domain API broken?

Luis Gomez
 

OK, it looks like all is back to normal now. I only bumped the LISP version number as otherwise the SP edition cannot be built.

BR/Luis



On Apr 1, 2014, at 4:25 PM, Madhu Venugopal <mavenugo@...> wrote:

Thanks Luis. Please revert just the OVSDB bundle versions.

FYI, we are currently re-architecting the code in a different branch topic/schema and we have bumped up the versions.
The Versions plugin has pulled in the LATEST higher SNAPSHOT version automatically and has caused this recent issue.
If you rollback to the previous version, we have reverted it to the master branch which is the working version.

-Madhu

On 4/1/14, 4:09 PM, Luis Gomez wrote:
OK Madhu, I can take care of these changes. I am almost sure I had to commit this automatic patch from jenkins because the editions build was failing. Anyway, I will do according to your recommendation and will contact you if something fails.

BR/Luis


On Apr 1, 2014, at 3:43 PM, Madhu Venugopal <mavenugo@...> wrote:

Hi Luis,

Thats because of this :

commit 9ad9918a8144e5a5ea83ed85f5a81e3d3cfcbca9
Author: jenkins-integration <jekins-integration@...>
Date:   Tue Apr 1 16:00:34 2014 +0000

    Update to new version of the artifacts proposed by jenkins-integration-version-changes-20
   
    Change-Id: Ie2b24f667efdab264abb9f7bb33e1c7bd2d64a41
    Signed-off-by: jenkins-integration <jekins-integration@...>

we have to revert back the pom.xml in the base/virt/sp editions to the previous versions.
Have attached the diff effected by the above commit.

-Madhu

On 4/1/14, 3:30 PM, Luis Gomez Palacios wrote:
Hi Madhu,

Still fails, please check the latest OSGi console when base edition starts and also when we try to create bridge through BD API:
 

 
BR/Luis



On Apr 1, 2014, at 4:53 AM, Madhu Venugopal <mavenugo@...> wrote:

Hi Luis,

Unless you are using an older version of OVS in your testbed, this IPFIX change should not impact you.
But, I realized that our new topic branch could have caused this issue. We have a re-architecture work
in progress for the ovsdb library. We forgot to bump up the bundle version. Most likely this version
conflict would have caused this issue. I took care of it now by following semantic versioning.

Can you kindly re-trigger the integration tests ?

Thanks,
-Madhu

On 3/31/14, 9:35 PM, Luis Gomez wrote:
Thanks Madhu ;)

On Mar 31, 2014, at 9:31 PM, Madhu Venugopal <mavenugo@...> wrote:

Hi Luis,

We modified the code to include IPFIX. Not sure if that is causing this issue.
I will look into it and get back to you.

Thanks,
-Madhu

On 3/31/14, 9:25 PM, Luis Gomez wrote:
Hi Devs,

Since today we have problems in the base edition system test like it is not possible to create a bridge using Bridge Domain API. Have you changed anything that could impact this functionality?

https://jenkins.opendaylight.org/integration/job/integration-csit-base/

Thanks/Luis

_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev



<revert_back_ovsdb.diff>




Re: [controller-dev] Netconf plugin testing

Madhusudhan Kandadai <madhusudhan.opendaylight@...>
 

Reinaldo,

I figured out my problem just now. That is because of incorrect port mentioned in 04-libnetconfd.xml. As I installed netopeer using docker and it uses port 1831:830 for talking to netconf server. So, I used port# 1831 in that xml, username & pwd as "root". Then, I am able to get the correct GET request as mentioned in the wiki. Have attached the response for your kind reference.

In the meanwhile, I am getting the error in OSGi command line: Did you face this error before:

2014-04-01 17:44:52.624 PDT [pool-39-thread-1] DEBUG o.o.c.n.u.AbstractNetconfSessionNegotiator - Connection timeout after HashedWheelTimeout(deadline: 1198888 ms ago, ), session is in state OPEN_WAIT
2014-04-01 17:44:52.632 PDT [pool-34-thread-2] ERROR o.o.c.s.c.n.NetconfDevice#libnetconfd - Netconf client NOT started. 
java.lang.IllegalStateException: Unable to create NetconfClient{label=libnetconfd, sessionId=0}
at org.opendaylight.controller.netconf.client.NetconfClient.get(NetconfClient.java:73) ~[na:na]
at org.opendaylight.controller.netconf.client.NetconfClient.<init>(NetconfClient.java:105) ~[na:na]
at org.opendaylight.controller.netconf.client.NetconfClient.clientFor(NetconfClient.java:83) ~[na:na]
at org.opendaylight.controller.sal.connect.netconf.NetconfDevice$3.run(NetconfDevice.java:268) ~[na:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_51]
at java.util.concurrent.FutureTask.run(FutureTask.java:262) [na:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: Session was not established after HashedWheelTimeout(deadline: 1483740 ms ago, )
at io.netty.util.concurrent.AbstractFuture.get(AbstractFuture.java:37) ~[na:na]
at org.opendaylight.controller.netconf.client.NetconfClient.get(NetconfClient.java:69) ~[na:na]
... 8 common frames omitted
Caused by: java.lang.IllegalStateException: Session was not established after HashedWheelTimeout(deadline: 1483740 ms ago, )
at org.opendaylight.controller.netconf.util.AbstractNetconfSessionNegotiator$2.run(AbstractNetconfSessionNegotiator.java:115) ~[na:na]
at io.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:542) ~[na:na]
at io.netty.util.HashedWheelTimer$Worker.notifyExpiredTimeouts(HashedWheelTimer.java:440) ~[na:na]
at io.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:381) ~[na:na]
... 1 common frames omitted
2014-04-01 17:44:52.633 PDT [pool-39-thread-1] DEBUG o.o.c.n.u.AbstractNetconfSessionNegotiator - Changing state from : OPEN_WAIT to : FAILED

Thanks,
Madhusudhan

On Tuesday, April 1, 2014 5:24 PM, Reinaldo Penno <rapenno@...> wrote:
I will test again later today and get back to you.

In the meantime, can you test something simple? Change header to <Accept: application/xml> and perform GET again.  I seem to remember an issue around that.

The error below seem network related. I will retest anyway.




On Tue, Apr 1, 2014 at 3:59 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Thanks Reinaldo.

I installed docker image mentioned at https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Docker_image and I am able to see the response sent by server in XML after doing "ssh root@localhost -p 1831 -s netconf."

I have created an xml mentioned at https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Editing_Netconf_Client_Configuration_by_Creating_Initial_Controller_Config_File and named it as "04-libnetconfd.xml". Have enabled the logs at logback.xml. After restarting the controller, when I issue GET request "http://localhost:8080/restconf/operational/opendaylight-inventory:nodes" I do get the following response:

{
    "nodes": {
        "node": [
            {
                "id": "libnetconfd"
            }
        ]
    }
}


Sorry for my repeated question.

Thanks,
Madhusudhan
On Friday, March 28, 2014 6:38 PM, Reinaldo Penno <rapenno@...> wrote:


On Fri, Mar 28, 2014 at 2:45 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Thanks Reinaldo. I have two scenarios in testing netconf SB plugin:

(a) Have LINC switch in another VM which actually runs netconf code. I tried to make it work in testing netconf plugin by starting LINC switch in another VM. Have changed IP address, username,port(I used 830 for ssh and put"false" in tcp-only), enabled the log. Unable to recollect where I got stuck. I am still refining it to get more details about this

(b) Have configured netopeer in another VM and followed the steps mentioned at https://groups.google.com/forum/#!topic/libnetconf/sVaj8tYYZC0. While doing make && make install for netopeer - server, 

I got this error: .obj/src/server_comm_dbus.o: In function `comm_loop':
server_comm_dbus.c:(.text+0xee3): undefined reference to `server_sessions_get_by_ncid'. This is similar to the one : http://pastebin.com/vcvZp4bm. I could not find any resolution there.

Just checking whether anyone working/worked on this netconf plugin faced this error before? If yes, could you advise on how to overcome this error?

Thanks,
Madhusudhan

On Tuesday, March 25, 2014 6:04 PM, Reinaldo Penno <rapenno@...> wrote:
okay, there seems a confusion.

ODL has an internal Netconf server. This server is used for configuration of internal ODL stuff. 

In order to test the Netconf SB plug-in you need an _external_ Netconf server device - outside ODL. This can be a number of devices or a stand-alone daemon like netopeer running Netconf Server code.










On Tue, Mar 25, 2014 at 4:42 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Hi Reinaldo,

I believe netconf server will be started automatically after starting the controller. Here is the following lines called from config.ini. (Please correct me if I am wrong)
 
# Netconf startup configuration
netconf.tcp.address=127.0.0.1
netconf.tcp.port=8383

netconf.tcp.client.address=127.0.0.1
netconf.tcp.client.port=8383

netconf.ssh.address=0.0.0.0
netconf.ssh.port=1830
netconf.ssh.pk.path = ./configuration/RSA.pk


so, do you think I have to change the ip address, port#, which are defined at 02-libnetconfd.xml according to the one mentioned above? If not, can you please shed some light on this ? Sorry if this is a basic question.

Thanks,
Madhusudhan

On Monday, March 24, 2014 8:20 PM, Reinaldo Penno <rapenno@...> wrote:
Which device are you using as a netconf server? You have to substitute the IP address on the example by the IP address of your  netconf device. You need to make sure netconf is running on the device, etc.




On Mon, Mar 24, 2014 at 7:52 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Thanks Reinaldo. I actually took the latest controller from wget https://jenkins.opendaylight.org/integration/job/integration-project-centralized-integration/lastSuccessfulBuild/artifact/distributions/base/target/distributions-base-0.1.2-SNAPSHOT-osgipackage.zip, created a file named "04-libnetconfd.xml" in opendaylight/configuration/initial

Then started the controller using of13 plugin, but I could not see any notification like this:

2014-02-12 04:42:10.043 PST [pool-23-thread-1] INFO  o.o.c.s.c.n.NetconfDevice#libnetconfd - Starting Netconf Client on: /10.0.1.27:830

Am I doing something wrong?

Thanks,
Madhusudhan


On Monday, March 24, 2014 7:37 PM, Reinaldo Penno <rapenno@...> wrote:
If the file is correct, nothing else is needed and a netconf session will be established between ODL and netconf server (device)
 


On Mon, Mar 24, 2014 at 4:45 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Hello,

I am interested in performing testing on netconf plugin. I have netconf server and just want to configure ODL. I have gone through the below links on how to test netconf plugin: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf and https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf:Example_Configuration

If I understand correctly:

1. Should I need to configure yumapro-13.04. If yes, I found the documentation at https://github.com/pikagrue/test-repository-2/tree/master/yumapro-13.04. I am trying hard to install yumapro-13.04 and can you point me the right link for installing the same.
2. Once done with the above step, I *think* I can go to this step https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Connecting_to_the_Controller_Configuration_Server and follow the sequence in order.

Does anybody worked on testing netconf plugin, so I need to ask the sequence to get familiar in testing netconf plugin.

Thanks in advance!

Madhusudhan

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

















Re: [controller-dev] Netconf plugin testing

Reinaldo Penno <rapenno@...>
 

I will test again later today and get back to you.

In the meantime, can you test something simple? Change header to <Accept: application/xml> and perform GET again.  I seem to remember an issue around that.

The error below seem network related. I will retest anyway.




On Tue, Apr 1, 2014 at 3:59 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Thanks Reinaldo.

I installed docker image mentioned at https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Docker_image and I am able to see the response sent by server in XML after doing "ssh root@localhost -p 1831 -s netconf."

I have created an xml mentioned at https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Editing_Netconf_Client_Configuration_by_Creating_Initial_Controller_Config_File and named it as "04-libnetconfd.xml". Have enabled the logs at logback.xml. After restarting the controller, when I issue GET request "http://localhost:8080/restconf/operational/opendaylight-inventory:nodes" I do get the following response:

{
    "nodes": {
        "node": [
            {
                "id": "libnetconfd"
            }
        ]
    }
}


Sorry for my repeated question.

Thanks,
Madhusudhan
On Friday, March 28, 2014 6:38 PM, Reinaldo Penno <rapenno@...> wrote:


On Fri, Mar 28, 2014 at 2:45 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Thanks Reinaldo. I have two scenarios in testing netconf SB plugin:

(a) Have LINC switch in another VM which actually runs netconf code. I tried to make it work in testing netconf plugin by starting LINC switch in another VM. Have changed IP address, username,port(I used 830 for ssh and put"false" in tcp-only), enabled the log. Unable to recollect where I got stuck. I am still refining it to get more details about this

(b) Have configured netopeer in another VM and followed the steps mentioned at https://groups.google.com/forum/#!topic/libnetconf/sVaj8tYYZC0. While doing make && make install for netopeer - server, 

I got this error: .obj/src/server_comm_dbus.o: In function `comm_loop':
server_comm_dbus.c:(.text+0xee3): undefined reference to `server_sessions_get_by_ncid'. This is similar to the one : http://pastebin.com/vcvZp4bm. I could not find any resolution there.

Just checking whether anyone working/worked on this netconf plugin faced this error before? If yes, could you advise on how to overcome this error?

Thanks,
Madhusudhan

On Tuesday, March 25, 2014 6:04 PM, Reinaldo Penno <rapenno@...> wrote:
okay, there seems a confusion.

ODL has an internal Netconf server. This server is used for configuration of internal ODL stuff. 

In order to test the Netconf SB plug-in you need an _external_ Netconf server device - outside ODL. This can be a number of devices or a stand-alone daemon like netopeer running Netconf Server code.










On Tue, Mar 25, 2014 at 4:42 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Hi Reinaldo,

I believe netconf server will be started automatically after starting the controller. Here is the following lines called from config.ini. (Please correct me if I am wrong)
 
# Netconf startup configuration
netconf.tcp.address=127.0.0.1
netconf.tcp.port=8383

netconf.tcp.client.address=127.0.0.1
netconf.tcp.client.port=8383

netconf.ssh.address=0.0.0.0
netconf.ssh.port=1830
netconf.ssh.pk.path = ./configuration/RSA.pk


so, do you think I have to change the ip address, port#, which are defined at 02-libnetconfd.xml according to the one mentioned above? If not, can you please shed some light on this ? Sorry if this is a basic question.

Thanks,
Madhusudhan

On Monday, March 24, 2014 8:20 PM, Reinaldo Penno <rapenno@...> wrote:
Which device are you using as a netconf server? You have to substitute the IP address on the example by the IP address of your  netconf device. You need to make sure netconf is running on the device, etc.




On Mon, Mar 24, 2014 at 7:52 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Thanks Reinaldo. I actually took the latest controller from wget https://jenkins.opendaylight.org/integration/job/integration-project-centralized-integration/lastSuccessfulBuild/artifact/distributions/base/target/distributions-base-0.1.2-SNAPSHOT-osgipackage.zip, created a file named "04-libnetconfd.xml" in opendaylight/configuration/initial

Then started the controller using of13 plugin, but I could not see any notification like this:

2014-02-12 04:42:10.043 PST [pool-23-thread-1] INFO  o.o.c.s.c.n.NetconfDevice#libnetconfd - Starting Netconf Client on: /10.0.1.27:830

Am I doing something wrong?

Thanks,
Madhusudhan


On Monday, March 24, 2014 7:37 PM, Reinaldo Penno <rapenno@...> wrote:
If the file is correct, nothing else is needed and a netconf session will be established between ODL and netconf server (device)
 


On Mon, Mar 24, 2014 at 4:45 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Hello,

I am interested in performing testing on netconf plugin. I have netconf server and just want to configure ODL. I have gone through the below links on how to test netconf plugin: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf and https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf:Example_Configuration

If I understand correctly:

1. Should I need to configure yumapro-13.04. If yes, I found the documentation at https://github.com/pikagrue/test-repository-2/tree/master/yumapro-13.04. I am trying hard to install yumapro-13.04 and can you point me the right link for installing the same.
2. Once done with the above step, I *think* I can go to this step https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Connecting_to_the_Controller_Configuration_Server and follow the sequence in order.

Does anybody worked on testing netconf plugin, so I need to ask the sequence to get familiar in testing netconf plugin.

Thanks in advance!

Madhusudhan

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev















Re: Bridge domain API broken?

Madhu Venugopal
 

Thanks Luis. Please revert just the OVSDB bundle versions.

FYI, we are currently re-architecting the code in a different branch topic/schema and we have bumped up the versions.
The Versions plugin has pulled in the LATEST higher SNAPSHOT version automatically and has caused this recent issue.
If you rollback to the previous version, we have reverted it to the master branch which is the working version.

-Madhu

On 4/1/14, 4:09 PM, Luis Gomez wrote:
OK Madhu, I can take care of these changes. I am almost sure I had to commit this automatic patch from jenkins because the editions build was failing. Anyway, I will do according to your recommendation and will contact you if something fails.

BR/Luis


On Apr 1, 2014, at 3:43 PM, Madhu Venugopal <mavenugo@...> wrote:

Hi Luis,

Thats because of this :

commit 9ad9918a8144e5a5ea83ed85f5a81e3d3cfcbca9
Author: jenkins-integration <jekins-integration@...>
Date:   Tue Apr 1 16:00:34 2014 +0000

    Update to new version of the artifacts proposed by jenkins-integration-version-changes-20
   
    Change-Id: Ie2b24f667efdab264abb9f7bb33e1c7bd2d64a41
    Signed-off-by: jenkins-integration <jekins-integration@...>

we have to revert back the pom.xml in the base/virt/sp editions to the previous versions.
Have attached the diff effected by the above commit.

-Madhu

On 4/1/14, 3:30 PM, Luis Gomez Palacios wrote:
Hi Madhu,

Still fails, please check the latest OSGi console when base edition starts and also when we try to create bridge through BD API:
 

 
BR/Luis



On Apr 1, 2014, at 4:53 AM, Madhu Venugopal <mavenugo@...> wrote:

Hi Luis,

Unless you are using an older version of OVS in your testbed, this IPFIX change should not impact you.
But, I realized that our new topic branch could have caused this issue. We have a re-architecture work
in progress for the ovsdb library. We forgot to bump up the bundle version. Most likely this version
conflict would have caused this issue. I took care of it now by following semantic versioning.

Can you kindly re-trigger the integration tests ?

Thanks,
-Madhu

On 3/31/14, 9:35 PM, Luis Gomez wrote:
Thanks Madhu ;)

On Mar 31, 2014, at 9:31 PM, Madhu Venugopal <mavenugo@...> wrote:

Hi Luis,

We modified the code to include IPFIX. Not sure if that is causing this issue.
I will look into it and get back to you.

Thanks,
-Madhu

On 3/31/14, 9:25 PM, Luis Gomez wrote:
Hi Devs,

Since today we have problems in the base edition system test like it is not possible to create a bridge using Bridge Domain API. Have you changed anything that could impact this functionality?

https://jenkins.opendaylight.org/integration/job/integration-csit-base/

Thanks/Luis

_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev



<revert_back_ovsdb.diff>



Issue with restconf -

Christopher O'SHEA <christopher.o.shea@...>
 

Hi All,

I’m not sure if this is normal but it seem to look odd to me.
When I use the restconf to put the f1.xml flow to the controller the flows looks fine on the OVS switch.

But when I try to view the flow via restconfig I see a double up on “instructions” and “match”  see attached flow.json

Thanks
Chris  


Re: Bridge domain API broken?

Luis Gomez
 

OK Madhu, I can take care of these changes. I am almost sure I had to commit this automatic patch from jenkins because the editions build was failing. Anyway, I will do according to your recommendation and will contact you if something fails.

BR/Luis


On Apr 1, 2014, at 3:43 PM, Madhu Venugopal <mavenugo@...> wrote:

Hi Luis,

Thats because of this :

commit 9ad9918a8144e5a5ea83ed85f5a81e3d3cfcbca9
Author: jenkins-integration <jekins-integration@...>
Date:   Tue Apr 1 16:00:34 2014 +0000

    Update to new version of the artifacts proposed by jenkins-integration-version-changes-20
   
    Change-Id: Ie2b24f667efdab264abb9f7bb33e1c7bd2d64a41
    Signed-off-by: jenkins-integration <jekins-integration@...>

we have to revert back the pom.xml in the base/virt/sp editions to the previous versions.
Have attached the diff effected by the above commit.

-Madhu

On 4/1/14, 3:30 PM, Luis Gomez Palacios wrote:
Hi Madhu,

Still fails, please check the latest OSGi console when base edition starts and also when we try to create bridge through BD API:
 

 
BR/Luis



On Apr 1, 2014, at 4:53 AM, Madhu Venugopal <mavenugo@...> wrote:

Hi Luis,

Unless you are using an older version of OVS in your testbed, this IPFIX change should not impact you.
But, I realized that our new topic branch could have caused this issue. We have a re-architecture work
in progress for the ovsdb library. We forgot to bump up the bundle version. Most likely this version
conflict would have caused this issue. I took care of it now by following semantic versioning.

Can you kindly re-trigger the integration tests ?

Thanks,
-Madhu

On 3/31/14, 9:35 PM, Luis Gomez wrote:
Thanks Madhu ;)

On Mar 31, 2014, at 9:31 PM, Madhu Venugopal <mavenugo@...> wrote:

Hi Luis,

We modified the code to include IPFIX. Not sure if that is causing this issue.
I will look into it and get back to you.

Thanks,
-Madhu

On 3/31/14, 9:25 PM, Luis Gomez wrote:
Hi Devs,

Since today we have problems in the base edition system test like it is not possible to create a bridge using Bridge Domain API. Have you changed anything that could impact this functionality?

https://jenkins.opendaylight.org/integration/job/integration-csit-base/

Thanks/Luis

_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev



<revert_back_ovsdb.diff>


Re: [controller-dev] Netconf plugin testing

Madhusudhan Kandadai <madhusudhan.opendaylight@...>
 

This is the exact error I get in OSGi command line:

2014-04-01 15:49:21.307 PDT [pool-34-thread-1] ERROR o.o.c.s.c.n.NetconfDevice#libnetconfd - Netconf client NOT started. 
java.lang.IllegalStateException: Unable to create NetconfClient{label=libnetconfd, sessionId=0}
at org.opendaylight.controller.netconf.client.NetconfClient.get(NetconfClient.java:73) ~[na:na]
at org.opendaylight.controller.netconf.client.NetconfClient.<init>(NetconfClient.java:105) ~[na:na]
at org.opendaylight.controller.netconf.client.NetconfClient.clientFor(NetconfClient.java:83) ~[na:na]
at org.opendaylight.controller.sal.connect.netconf.NetconfDevice$3.run(NetconfDevice.java:268) ~[na:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_51]
at java.util.concurrent.FutureTask.run(FutureTask.java:262) [na:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: Session was not established after HashedWheelTimeout(deadline: 3231001 ms ago, )
at io.netty.util.concurrent.AbstractFuture.get(AbstractFuture.java:37) ~[na:na]
at org.opendaylight.controller.netconf.client.NetconfClient.get(NetconfClient.java:69) ~[na:na]
... 8 common frames omitted
Caused by: java.lang.IllegalStateException: Session was not established after HashedWheelTimeout(deadline: 3231001 ms ago, )
at org.opendaylight.controller.netconf.util.AbstractNetconfSessionNegotiator$2.run(AbstractNetconfSessionNegotiator.java:115) ~[na:na]
at io.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:542) ~[na:na]
at io.netty.util.HashedWheelTimer$Worker.notifyExpiredTimeouts(HashedWheelTimer.java:440) ~[na:na]
at io.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:381) ~[na:na]
... 1 common frames omitted
2014-04-01 15:49:22.047 PDT [pool-39-thread-1] DEBUG o.o.c.n.u.AbstractNetconfSessionNegotiator - Connection timeout after HashedWheelTimeout(deadline: 1156294 ms ago, ), session is in state OPEN_WAIT
2014-04-01 15:49:22.050 PDT [pool-39-thread-1] DEBUG o.o.c.n.u.AbstractNetconfSessionNegotiator - Changing state from : OPEN_WAIT to : FAILED

 
Thanks,
Madhusudhan

On Tuesday, April 1, 2014 3:59 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Thanks Reinaldo.

I installed docker image mentioned at https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Docker_image and I am able to see the response sent by server in XML after doing "ssh root@localhost -p 1831 -s netconf."

I have created an xml mentioned at https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Editing_Netconf_Client_Configuration_by_Creating_Initial_Controller_Config_File and named it as "04-libnetconfd.xml". Have enabled the logs at logback.xml. After restarting the controller, when I issue GET request "http://localhost:8080/restconf/operational/opendaylight-inventory:nodes" I do get the following response:

{
    "nodes": {
        "node": [
            {
                "id": "libnetconfd"
            }
        ]
    }
}

Could you please suggest in-order to get the correct response mentioned at https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Editing_Netconf_Client_Configuration_by_Creating_Initial_Controller_Config_File

Sorry for my repeated question.

Thanks,
Madhusudhan
On Friday, March 28, 2014 6:38 PM, Reinaldo Penno <rapenno@...> wrote:


On Fri, Mar 28, 2014 at 2:45 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Thanks Reinaldo. I have two scenarios in testing netconf SB plugin:

(a) Have LINC switch in another VM which actually runs netconf code. I tried to make it work in testing netconf plugin by starting LINC switch in another VM. Have changed IP address, username,port(I used 830 for ssh and put"false" in tcp-only), enabled the log. Unable to recollect where I got stuck. I am still refining it to get more details about this

(b) Have configured netopeer in another VM and followed the steps mentioned at https://groups.google.com/forum/#!topic/libnetconf/sVaj8tYYZC0. While doing make && make install for netopeer - server, 

I got this error: .obj/src/server_comm_dbus.o: In function `comm_loop':
server_comm_dbus.c:(.text+0xee3): undefined reference to `server_sessions_get_by_ncid'. This is similar to the one : http://pastebin.com/vcvZp4bm. I could not find any resolution there.

Just checking whether anyone working/worked on this netconf plugin faced this error before? If yes, could you advise on how to overcome this error?

Thanks,
Madhusudhan

On Tuesday, March 25, 2014 6:04 PM, Reinaldo Penno <rapenno@...> wrote:
okay, there seems a confusion.

ODL has an internal Netconf server. This server is used for configuration of internal ODL stuff. 

In order to test the Netconf SB plug-in you need an _external_ Netconf server device - outside ODL. This can be a number of devices or a stand-alone daemon like netopeer running Netconf Server code.










On Tue, Mar 25, 2014 at 4:42 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Hi Reinaldo,

I believe netconf server will be started automatically after starting the controller. Here is the following lines called from config.ini. (Please correct me if I am wrong)
 
# Netconf startup configuration
netconf.tcp.address=127.0.0.1
netconf.tcp.port=8383

netconf.tcp.client.address=127.0.0.1
netconf.tcp.client.port=8383

netconf.ssh.address=0.0.0.0
netconf.ssh.port=1830
netconf.ssh.pk.path = ./configuration/RSA.pk


so, do you think I have to change the ip address, port#, which are defined at 02-libnetconfd.xml according to the one mentioned above? If not, can you please shed some light on this ? Sorry if this is a basic question.

Thanks,
Madhusudhan

On Monday, March 24, 2014 8:20 PM, Reinaldo Penno <rapenno@...> wrote:
Which device are you using as a netconf server? You have to substitute the IP address on the example by the IP address of your  netconf device. You need to make sure netconf is running on the device, etc.




On Mon, Mar 24, 2014 at 7:52 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Thanks Reinaldo. I actually took the latest controller from wget https://jenkins.opendaylight.org/integration/job/integration-project-centralized-integration/lastSuccessfulBuild/artifact/distributions/base/target/distributions-base-0.1.2-SNAPSHOT-osgipackage.zip, created a file named "04-libnetconfd.xml" in opendaylight/configuration/initial

Then started the controller using of13 plugin, but I could not see any notification like this:

2014-02-12 04:42:10.043 PST [pool-23-thread-1] INFO  o.o.c.s.c.n.NetconfDevice#libnetconfd - Starting Netconf Client on: /10.0.1.27:830

Am I doing something wrong?

Thanks,
Madhusudhan


On Monday, March 24, 2014 7:37 PM, Reinaldo Penno <rapenno@...> wrote:
If the file is correct, nothing else is needed and a netconf session will be established between ODL and netconf server (device)
 


On Mon, Mar 24, 2014 at 4:45 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Hello,

I am interested in performing testing on netconf plugin. I have netconf server and just want to configure ODL. I have gone through the below links on how to test netconf plugin: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf and https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf:Example_Configuration

If I understand correctly:

1. Should I need to configure yumapro-13.04. If yes, I found the documentation at https://github.com/pikagrue/test-repository-2/tree/master/yumapro-13.04. I am trying hard to install yumapro-13.04 and can you point me the right link for installing the same.
2. Once done with the above step, I *think* I can go to this step https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Connecting_to_the_Controller_Configuration_Server and follow the sequence in order.

Does anybody worked on testing netconf plugin, so I need to ask the sequence to get familiar in testing netconf plugin.

Thanks in advance!

Madhusudhan

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev














_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev



Re: [controller-dev] Netconf plugin testing

Madhusudhan Kandadai <madhusudhan.opendaylight@...>
 

Thanks Reinaldo.

I installed docker image mentioned at https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Docker_image and I am able to see the response sent by server in XML after doing "ssh root@localhost -p 1831 -s netconf."

I have created an xml mentioned at https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Editing_Netconf_Client_Configuration_by_Creating_Initial_Controller_Config_File and named it as "04-libnetconfd.xml". Have enabled the logs at logback.xml. After restarting the controller, when I issue GET request "http://localhost:8080/restconf/operational/opendaylight-inventory:nodes" I do get the following response:

{
    "nodes": {
        "node": [
            {
                "id": "libnetconfd"
            }
        ]
    }
}

Could you please suggest in-order to get the correct response mentioned at https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Editing_Netconf_Client_Configuration_by_Creating_Initial_Controller_Config_File

Sorry for my repeated question.

Thanks,
Madhusudhan

On Friday, March 28, 2014 6:38 PM, Reinaldo Penno <rapenno@...> wrote:


On Fri, Mar 28, 2014 at 2:45 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Thanks Reinaldo. I have two scenarios in testing netconf SB plugin:

(a) Have LINC switch in another VM which actually runs netconf code. I tried to make it work in testing netconf plugin by starting LINC switch in another VM. Have changed IP address, username,port(I used 830 for ssh and put"false" in tcp-only), enabled the log. Unable to recollect where I got stuck. I am still refining it to get more details about this

(b) Have configured netopeer in another VM and followed the steps mentioned at https://groups.google.com/forum/#!topic/libnetconf/sVaj8tYYZC0. While doing make && make install for netopeer - server, 

I got this error: .obj/src/server_comm_dbus.o: In function `comm_loop':
server_comm_dbus.c:(.text+0xee3): undefined reference to `server_sessions_get_by_ncid'. This is similar to the one : http://pastebin.com/vcvZp4bm. I could not find any resolution there.

Just checking whether anyone working/worked on this netconf plugin faced this error before? If yes, could you advise on how to overcome this error?

Thanks,
Madhusudhan

On Tuesday, March 25, 2014 6:04 PM, Reinaldo Penno <rapenno@...> wrote:
okay, there seems a confusion.

ODL has an internal Netconf server. This server is used for configuration of internal ODL stuff. 

In order to test the Netconf SB plug-in you need an _external_ Netconf server device - outside ODL. This can be a number of devices or a stand-alone daemon like netopeer running Netconf Server code.










On Tue, Mar 25, 2014 at 4:42 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Hi Reinaldo,

I believe netconf server will be started automatically after starting the controller. Here is the following lines called from config.ini. (Please correct me if I am wrong)
 
# Netconf startup configuration
netconf.tcp.address=127.0.0.1
netconf.tcp.port=8383

netconf.tcp.client.address=127.0.0.1
netconf.tcp.client.port=8383

netconf.ssh.address=0.0.0.0
netconf.ssh.port=1830
netconf.ssh.pk.path = ./configuration/RSA.pk


so, do you think I have to change the ip address, port#, which are defined at 02-libnetconfd.xml according to the one mentioned above? If not, can you please shed some light on this ? Sorry if this is a basic question.

Thanks,
Madhusudhan

On Monday, March 24, 2014 8:20 PM, Reinaldo Penno <rapenno@...> wrote:
Which device are you using as a netconf server? You have to substitute the IP address on the example by the IP address of your  netconf device. You need to make sure netconf is running on the device, etc.




On Mon, Mar 24, 2014 at 7:52 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Thanks Reinaldo. I actually took the latest controller from wget https://jenkins.opendaylight.org/integration/job/integration-project-centralized-integration/lastSuccessfulBuild/artifact/distributions/base/target/distributions-base-0.1.2-SNAPSHOT-osgipackage.zip, created a file named "04-libnetconfd.xml" in opendaylight/configuration/initial

Then started the controller using of13 plugin, but I could not see any notification like this:

2014-02-12 04:42:10.043 PST [pool-23-thread-1] INFO  o.o.c.s.c.n.NetconfDevice#libnetconfd - Starting Netconf Client on: /10.0.1.27:830

Am I doing something wrong?

Thanks,
Madhusudhan


On Monday, March 24, 2014 7:37 PM, Reinaldo Penno <rapenno@...> wrote:
If the file is correct, nothing else is needed and a netconf session will be established between ODL and netconf server (device)
 


On Mon, Mar 24, 2014 at 4:45 PM, Madhusudhan Kandadai <madhusudhan.opendaylight@...> wrote:
Hello,

I am interested in performing testing on netconf plugin. I have netconf server and just want to configure ODL. I have gone through the below links on how to test netconf plugin: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf and https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf:Example_Configuration

If I understand correctly:

1. Should I need to configure yumapro-13.04. If yes, I found the documentation at https://github.com/pikagrue/test-repository-2/tree/master/yumapro-13.04. I am trying hard to install yumapro-13.04 and can you point me the right link for installing the same.
2. Once done with the above step, I *think* I can go to this step https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Connecting_to_the_Controller_Configuration_Server and follow the sequence in order.

Does anybody worked on testing netconf plugin, so I need to ask the sequence to get familiar in testing netconf plugin.

Thanks in advance!

Madhusudhan

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev














Re: Bridge domain API broken?

Madhu Venugopal
 

Hi Luis,

Thats because of this :

commit 9ad9918a8144e5a5ea83ed85f5a81e3d3cfcbca9
Author: jenkins-integration <jekins-integration@...>
Date:   Tue Apr 1 16:00:34 2014 +0000

    Update to new version of the artifacts proposed by jenkins-integration-version-changes-20
   
    Change-Id: Ie2b24f667efdab264abb9f7bb33e1c7bd2d64a41
    Signed-off-by: jenkins-integration <jekins-integration@...>

we have to revert back the pom.xml in the base/virt/sp editions to the previous versions.
Have attached the diff effected by the above commit.

-Madhu

On 4/1/14, 3:30 PM, Luis Gomez Palacios wrote:
Hi Madhu,

Still fails, please check the latest OSGi console when base edition starts and also when we try to create bridge through BD API:
 

 
BR/Luis



On Apr 1, 2014, at 4:53 AM, Madhu Venugopal <mavenugo@...> wrote:

Hi Luis,

Unless you are using an older version of OVS in your testbed, this IPFIX change should not impact you.
But, I realized that our new topic branch could have caused this issue. We have a re-architecture work
in progress for the ovsdb library. We forgot to bump up the bundle version. Most likely this version
conflict would have caused this issue. I took care of it now by following semantic versioning.

Can you kindly re-trigger the integration tests ?

Thanks,
-Madhu

On 3/31/14, 9:35 PM, Luis Gomez wrote:
Thanks Madhu ;)

On Mar 31, 2014, at 9:31 PM, Madhu Venugopal <mavenugo@...> wrote:

Hi Luis,

We modified the code to include IPFIX. Not sure if that is causing this issue.
I will look into it and get back to you.

Thanks,
-Madhu

On 3/31/14, 9:25 PM, Luis Gomez wrote:
Hi Devs,

Since today we have problems in the base edition system test like it is not possible to create a bridge using Bridge Domain API. Have you changed anything that could impact this functionality?

https://jenkins.opendaylight.org/integration/job/integration-csit-base/

Thanks/Luis

_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev




Re: Bridge domain API broken?

Luis Gomez
 

Hi Madhu,

Still fails, please check the latest OSGi console when base edition starts and also when we try to create bridge through BD API:
 

 
BR/Luis



On Apr 1, 2014, at 4:53 AM, Madhu Venugopal <mavenugo@...> wrote:

Hi Luis,

Unless you are using an older version of OVS in your testbed, this IPFIX change should not impact you.
But, I realized that our new topic branch could have caused this issue. We have a re-architecture work
in progress for the ovsdb library. We forgot to bump up the bundle version. Most likely this version
conflict would have caused this issue. I took care of it now by following semantic versioning.

Can you kindly re-trigger the integration tests ?

Thanks,
-Madhu

On 3/31/14, 9:35 PM, Luis Gomez wrote:
Thanks Madhu ;)

On Mar 31, 2014, at 9:31 PM, Madhu Venugopal <mavenugo@...> wrote:

Hi Luis,

We modified the code to include IPFIX. Not sure if that is causing this issue.
I will look into it and get back to you.

Thanks,
-Madhu

On 3/31/14, 9:25 PM, Luis Gomez wrote:
Hi Devs,

Since today we have problems in the base edition system test like it is not possible to create a bridge using Bridge Domain API. Have you changed anything that could impact this functionality?

https://jenkins.opendaylight.org/integration/job/integration-csit-base/

Thanks/Luis

_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev


13761 - 13780 of 14658