Ask is moving to Stack Overflow and Serverfault.com! Please use the "opendaylight" tag on either of these sites. This site is now in Read-Only mode

ph0tek's profile - activity

2016-02-04 00:05:05 -0700 commented answer Managing Pica8 switch using ovsdb

Mine already seems to be working with OF1.3, since the command ovs-vsctl get Bridge br0 protocols produces: ["OpenFlow13"]. But thanks for the input.

2016-02-04 00:04:03 -0700 received badge  Famous Question (source)
2016-01-15 13:06:17 -0700 commented answer Managing Pica8 switch using ovsdb

I received information from Pica8 support that they arent able to set up the manager connection either, using ODL, but also not using Ryu, so it seems that the problem lies at Pica8. They created a bug report, and will work on this. So for the moment I will wait for their progress.

2016-01-07 09:08:53 -0700 received badge  Notable Question (source)
2016-01-07 03:37:03 -0700 answered a question Managing Pica8 switch using ovsdb

jamoluhrsen, I appreciate the effort,

Here are some replies:

  • I am not intentionally doing any REST calls, which would trigger these WebAppPublisher exceptions.

  • I deinstalled the odl-ovsdb-plugin feature, because of a compatibility issue that I was facing. Please see: https://ask.opendaylight.org/question... and https://wiki.opendaylight.org/view/Op...

  • Mostly I added the required features for Openstack support, according to the manual: http://go.linuxfoundation.org/l/6342/... (feature:install odl-base-all odl-aaa-authn odl-restconf odl-nsf-all odl-adsal-northbound odl-mdsal-apidocs odl-ovsdb-openstack odl-ovsdb-northbound odl-dlux-core) Also I might have installed some additional features to get Yang-UI working, and the l2switch feature.

  • Now I tried to only install odl-ovsdb-southbound-impl-rest, on a fresh install of Lithium-SR1 with only the initial features installed. This has the same result. server OVS instances are connected, but the Pica8 still is not. I pasted my karaf.log at http://pasted.co/59160277 (when I only have the Pica8 connected using set-manager) , and the used feature-list at: http://pasted.co/5d4b6672

Hope this helps.

2016-01-04 15:26:41 -0700 received badge  Popular Question (source)
2015-12-24 04:56:11 -0700 commented question Managing Pica8 switch using ovsdb

karaf.log: http://pasted.co/65e95a51 see timestamp 2015-12-24 12:17:58,177 for pica8 connection (not much info...), packet capture from pica8: http://pasted.co/cfbd1696 , ODL feature list: http://pasted.co/71940e77 , hope this helps.

2015-12-23 06:47:16 -0700 commented question Managing Pica8 switch using ovsdb

packet capture shows a lot of echo, and update messages (ovsdb) , so there is exchange of traffic. I cannot find any indication why the connection would not be established.

2015-12-14 07:49:10 -0700 commented question Managing Pica8 switch using ovsdb

I am using the pre-built package from the website (distribution-karaf-0.3.1-Lithium-SR1). The newer SR2 version I had some other issues. SR1 works better for me. I am not sure what to look for in karaf.log. I enabled some logging options for OVSDB, but I didnt see any relevant error messages.

2015-12-11 06:52:23 -0700 asked a question Managing Pica8 switch using ovsdb

Hi,

I am trying to manage a Pica8 switch (192.168.15.250) through ovsdb southbound protocol. The switch is running a ovsdb server on port 6640

Currently I do have a working OpenFlow connection through port 6633, and I see my node in the inventory and flow topology tables of ODL (at 192.168.15.246)

I already managed to add other OVS instances of openstack nodes through the same ODL controller using OVSDB, these are working and visible in the ovsdb topology table.

However I do not see my Pica8 node in the ovsdb topology when doing a GET at: http://localhost:8181/restconf/operat...

For the Pica8 I added the ovs-vsctl set-manager "tcp:192.168.15.246:6640" command. This is the output of ovs-vsctl show

admin@PicOS-OVS$ovs-vsctl show     
a429f99b-0540-47d2-ac3d-c753d14d0343
    Manager "tcp:192.168.15.246:6640"
    Bridge "br0"
        Controller "tcp:192.168.15.246:6633"
            is_connected: true
        Port "ge-1/1/2"
            tag: 1
            Interface "ge-1/1/2"
                type: "pica8"
        Port "ge-1/1/1"
            tag: 1
            Interface "ge-1/1/1"
                type: "pica8"
        Port "br0"
            Interface "br0"
                type: internal
    ovs_version: "2.3.0"

I do see an established TCP session between the ODL controller and the switch on port 6640:

admin@PicOS-OVS$netstat -anp | grep 6640
tcp        0      0 192.168.15.250:6640     0.0.0.0:*               LISTEN      8717/ovsdb-server
tcp        0      0 192.168.15.250:50610    192.168.15.246:6640     ESTABLISHED 8717/ovsdb-server

But still it is not connected according to openvswitch, and ODL does not see it either.

If I do an ovsdb-client dump tcp:192.168.15.250:6440 command this works fine.

Does any one have any idea why the manager connection is not established? Are there some criteria that are not met for ODL / OVS to set up the connection?

Thanks in advance for your feedback.

2015-12-11 03:28:09 -0700 received badge  Famous Question (source)
2015-10-21 04:37:46 -0700 received badge  Notable Question (source)
2015-10-13 02:08:14 -0700 received badge  Popular Question (source)
2015-10-05 02:56:13 -0700 answered a question node not added to OVSDB MD-SAL data store

Found the solution myself:

odl-ovsdb-plugin and odl-ovsdb-southbound-impl cannot run together.

I disabled odl-ovsdb-plugin using: feature:uninstall odl-ovsdb-plugin

After a restart, the ovsdb topology became visible.

Also see: https://wiki.opendaylight.org/view/OpenDaylightOVSDB:LithiumIntegration_Test#Incompatibilities

2015-10-02 03:55:25 -0700 asked a question node not added to OVSDB MD-SAL data store

Hi,

I am using the distribution-karaf-0.3.1-Lithium-SR1 package, to try out hte OVSDB southbound interface, together with mininet.

I have manage to install all features:

opendaylight-user@root>feature:list | grep ovsdb
odl-ovsdb-all                                 | 1.1.1-Lithium-SR1   | x         | ovsdb-1.1.1-Lithium-SR1                    | OpenDaylight :: OVSDB :: all                      
odl-ovsdb-library                             | 1.1.1-Lithium-SR1   | x         | ovsdb-1.1.1-Lithium-SR1                    | OVSDB :: Library                                  
odl-ovsdb-schema-openvswitch                  | 1.1.1-Lithium-SR1   | x         | ovsdb-1.1.1-Lithium-SR1                    | OVSDB :: Schema :: Open_vSwitch                   
odl-ovsdb-schema-hardwarevtep                 | 1.1.1-Lithium-SR1   | x         | ovsdb-1.1.1-Lithium-SR1                    | OVSDB :: Schema :: hardware_vtep                  
odl-ovsdb-plugin                              | 1.1.1-Lithium-SR1   | x         | ovsdb-1.1.1-Lithium-SR1                    | OpenDaylight :: OVSDB :: Plugin                   
odl-ovsdb-northbound                          | 0.7.1-Lithium-SR1   | x         | ovsdb-1.1.1-Lithium-SR1                    | OpenDaylight :: OVSDB :: Northbound               
odl-ovsdb-compatibility-layer                 | 1.1.1-Lithium-SR1   |           | ovsdb-1.1.1-Lithium-SR1                    | OpenDaylight :: OVSDB :: Plugin Compatibility Laye
odl-ovsdb-openstack                           | 1.1.1-Lithium-SR1   |           | ovsdb-1.1.1-Lithium-SR1                    | OpenDaylight :: OVSDB :: OpenStack Network Virtual
odl-ovsdb-southbound-api                      | 1.1.1-Lithium-SR1   | x         | odl-ovsdb-southbound-1.1.1-Lithium-SR1     | OpenDaylight :: southbound :: api                 
odl-ovsdb-southbound-impl                     | 1.1.1-Lithium-SR1   | x         | odl-ovsdb-southbound-1.1.1-Lithium-SR1     | OpenDaylight :: southbound :: impl                
odl-ovsdb-southbound-impl-rest                | 1.1.1-Lithium-SR1   | x         | odl-ovsdb-southbound-1.1.1-Lithium-SR1     | OpenDaylight :: southbound :: impl :: REST        
odl-ovsdb-southbound-impl-ui                  | 1.1.1-Lithium-SR1   | x         | odl-ovsdb-southbound-1.1.1-Lithium-SR1     | OpenDaylight :: southbound :: impl :: UI

start-up mininet: sudo mn --controller=remote,ip=127.0.0.1 --topo=linear,3 --switch ovsk,protocols=OpenFlow13 (pingall is working fine)

and set the manager address for ODL.

OVS looks correctly configured, ovs-vsctl show output:

0b69db46-c2b5-401b-8630-cfb7e0405afb
    Manager "tcp:127.0.0.1:6640"
        is_connected: true
    Bridge "s3"
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port "s3-eth1"
            Interface "s3-eth1"
        Port "s3"
            Interface "s3"
                type: internal
        Port "s3-eth2"
            Interface "s3-eth2"
    Bridge "s1"
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port "s1-eth1"
            Interface "s1-eth1"
        Port "s1"
            Interface "s1"
                type: internal
        Port "s1-eth2"
            Interface "s1-eth2"
    Bridge "s2"
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port "s2-eth3"
            Interface "s2-eth3"
        Port "s2"
            Interface "s2"
                type: internal
        Port "s2-eth1"
            Interface "s2-eth1"
        Port "s2-eth2"
            Interface "s2-eth2"
    ovs_version: "2.3.2"

However, when querying the md-sal operational datastore, using :

http://localhost:8181/restconf/operational/network-topology:network-topology/

the ovsdb:1 topology stays empty. But the flow:1 topology is filled normally.

The ovsdb part is limited to (not to list the complete RESTCONF output):

<topology>
   <topology-id>ovsdb:1</topology-id>
</topology>

I would expect at least my local OVS node here.

Is there something that I am doing wrong?

Thanks for your support.

2015-09-27 22:45:34 -0700 received badge  Taxonomist
2015-07-04 20:05:08 -0700 received badge  Notable Question (source)
2015-07-04 20:05:08 -0700 received badge  Famous Question (source)
2015-06-29 10:08:03 -0700 received badge  Popular Question (source)
2015-06-26 03:19:09 -0700 asked a question AAA features in ODL

Hi,

I am interested to know something more about AAA in Opendaylight. In how far is this currently a working module? What features does is currently provide? I am looking for a solution where I can assign policies for users to manage specific parts of the RESTconf functionality, especially for NETCONF operated devices, like legacy (non-openflow) switches and routers. The functionality that I am looking for, is to allow some users to configure certain aspects of some specific switch port (vlan tagging, interface naming, administrative status etc), while others should be allowed to also create VLANs or aggregated links. In short, I am looking for a method to granularly assign authorization policies to devices managed by ODL through the northbound interface.

Is this available, will this be available?

Thanks in advance for your feedback.

2015-03-20 07:12:59 -0700 received badge  Editor (source)
2015-02-20 04:41:24 -0700 commented answer Error accessing NETCONF device using custom Yang schema

Currently I am suffering from the fact that the Junos <hello> does not include a namespace. While I did manage to establish a netconf connection earlier. See similar issue for Cisco: https://ask.opendaylight.org/question/1532/setting-up-netconf-for-cisco-switch/ . I am hoping to tweak this soon.

2015-02-11 01:16:37 -0700 received badge  Famous Question (source)
2015-02-02 02:49:07 -0700 received badge  Notable Question (source)
2015-02-02 02:49:07 -0700 received badge  Popular Question (source)
2015-01-15 12:37:21 -0700 answered a question Running dlux via grunt live

I had the same issue. What helped in my case was adjusting the /dlux-web/config/development.json file.

I replaced "baseURL": "http://localhost:", with the actual hostname or ip address of my node.

Then, when restarting with grunt live, I was able to log in.

2015-01-14 02:29:46 -0700 answered a question Remote Netconf Server Initialization Failed : Disconnecting from device

Hi,

I think you also should specify your Yang files in the netconf connector xml file using:

<yang-module-capabilities xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
  <capability xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
    urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&revision=2010-09-24
  </capability>
</yang-module-capabilities>

(And adjust this to your own Yang files)

2015-01-14 02:21:59 -0700 asked a question Error accessing NETCONF device using custom Yang schema

I am trying to comunicate with a Juniper Device through NETCONF in ODL Helium. I configured the netconf-connector, and obtained a Yang file (which I stored in cache/schema), since the device does not support netconf-monitoring.

I also added

<yang-module-capabilities xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
  <capability xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
    urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&revision=2010-09-24
  </capability>
  <capability xmlns="urn:opendaylight:params:xml:ns:yang:controller:md:sal:connector:netconf">
    urn:ietf:params:xml:ns:yang:junos-yang-module-14.2R1.9?module=junos-yang-module-14.2R1.9&revision=2015-01-14
  </capability>

</yang-module-capabilities>

to the netconf-connector definition for the device, to specify the Yang modules.

The device seems to be working, since I see the log message:

2015-01-14 10:03:09,681 | INFO  | ssing-executor-4 | NetconfDevice                    | 376 - org.opendaylight.controller.sal-netconf-connector - 1.1.1.Helium-SR1 | RemoteDevice{sw-opennaas-1}: Netconf connector initialized successfully

But when I try to access the configuration of the device using restconf url: http://localhost:8181/restconf/config/opendaylight-inventory:nodes/opendaylight-inventory:node/sw-opennaas-1/yang-ext:mount/

It gives me an error:

2015-01-14 10:48:30,673 | ERROR | oupCloseable-4-2 | NetconfDeviceReadOnlyTx          | 376 - org.opendaylight.controller.sal-netconf-connector - 1.1.1.Helium-SR1 | RemoteDevice{sw-opennaas-1}: Unable to normalize data for /, data: Node[ImmutableCompositeNode], qName[data], modify[n/a], children.size = 1
java.lang.IllegalArgumentException: Failed to get child operation for Node[ImmutableCompositeNode], qName[data], modify[n/a], children.size = 1
    at org.opendaylight.controller.md.sal.common.impl.util.compat.DataNormalizer.toNormalized(DataNormalizer.java:113)[162:org.opendaylight.controller.sal-common-impl:1.1.1.Helium-SR1]
    at org.opendaylight.controller.sal.connect.netconf.sal.tx.NetconfDeviceReadOnlyTx.transform(NetconfDeviceReadOnlyTx.java:91)[376:org.opendaylight.controller.sal-netconf-connector:1.1.1.Helium-SR1]
    at org.opendaylight.controller.sal.connect.netconf.sal.tx.NetconfDeviceReadOnlyTx.access$100(NetconfDeviceReadOnlyTx.java:41)[376:org.opendaylight.controller.sal-netconf-connector:1.1.1.Helium-SR1]
    at org.opendaylight.controller.sal.connect.netconf.sal.tx.NetconfDeviceReadOnlyTx$1.apply(NetconfDeviceReadOnlyTx.java:68)[376:org.opendaylight.controller.sal-netconf-connector:1.1.1.Helium-SR1]
    at org.opendaylight.controller.sal.connect.netconf.sal.tx.NetconfDeviceReadOnlyTx$1.apply(NetconfDeviceReadOnlyTx.java:60)[376:org.opendaylight.controller.sal-netconf-connector:1.1.1.Helium-SR1]
    at com.google.common.util.concurrent.Futures$1.apply(Futures.java:720)[132:com.google.guava:14.0.1]
    at com.google.common.util.concurrent.Futures$ChainingListenableFuture.run(Futures.java:859)[132:com.google.guava:14.0.1]
    at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:293)[132:com.google.guava:14.0.1]
    at com.google.common.util.concurrent.ExecutionList$RunnableExecutorPair.execute(ExecutionList.java:150)[132:com.google.guava:14.0.1]
    at com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:135)[132:com.google.guava:14.0.1]
    at com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185)[132:com.google.guava:14.0.1]
    at com.google.common.util.concurrent.Futures$ChainingListenableFuture$1.run(Futures.java:873)[132:com.google.guava:14.0.1]
    at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors ...
(more)
2015-01-08 13:34:57 -0700 received badge  Famous Question (source)
2014-12-17 04:14:41 -0700 received badge  Enthusiast
2014-12-16 00:16:52 -0700 commented answer Setting up NETCONF for Cisco switch

That's correct, however there are some examples in the document which show <rpc> and <rpc-reply> tags with the namespace included. When testing I noticed this as well. For the notification or other tags, I haven't tested.

2014-12-15 08:30:41 -0700 marked best answer Setting up NETCONF for Cisco switch

Has anyone been successful in setting up NETCONF for Cisco devices?

I managed some part of the way, at least it logs in and authenticates, so my config seems okay. I followed the guidelines on: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf

But when exchanging <hello> messages, both ODL and Cisco IOS don't understand each other. ODL receives the hello from the Cisco device with the following info:</hello>

2014-12-09 20:07:31,211 | INFO  | upCloseable-4-13 | AbstractSessionNegotiator        | 185 - org.opendaylight.controller.protocol-framework - 0.5.1.Helium-SR1 | Unexpected error during negotiation
io.netty.handler.codec.DecoderException: java.lang.IllegalStateException: Hello message not received, instead received: <hello>
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:capability:writeable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:startup:1.0</capability>
<capability>urn:ietf:params:netconf:capability:url:1.0</capability>
<capability>urn:cisco:params:netconf:capability:pi-data-model:1.0</capability>
<capability>urn:cisco:params:netconf:capability:notification:1.0</capability>
</capabilities>
<session-id>88204996</session-id>
</hello>

It looks like what I have some seen from other posts, that the issue might be that the hello message lacks a xml namespace. Is there anyway to make ODL less specific and accept the hello, or find out why it fails exactly?

If anyone has managed to get NETCONF working for Cisco devices, I would be happy to hear about it.

Thanks in advance.

2014-12-13 12:37:45 -0700 received badge  Famous Question (source)
2014-12-13 02:50:07 -0700 received badge  Nice Question (source)
2014-12-13 02:48:37 -0700 marked best answer Connecting to ODL console using SSH

Is it possible to connect to a running OpenDaylight Karaf instance using SSH? For instance, when ODL was started using ./karaf server &?

I tried ssh localhost -p 8101, but don't know the correct username / password. Is this the correct approach? If so, how can I find or configure the correct credentials?

2014-12-12 15:08:46 -0700 received badge  Notable Question (source)
2014-12-12 12:17:11 -0700 received badge  Popular Question (source)