Date   

OpenDaylight OVSDB Developer Getting Started (Video)

Brent Salisbury
 


Hi all, we are working on getting more videos out there to assist folks getting started. Here was one we recorded today with OVSDBs resident controller all-star Madhu. The resolution is up to 720p so it looks pretty good. If anyone wants to join us to record (warning crazy hours :-) or do some yourself please don't hesitate. It would be great to have QA sessions recorded also so we try and capture the beginnings of an FAQ.

OpenDaylight OVSDB Developer Getting Started (Video)

Thanks!
-Brent


Re: [controller-dev] How to use the OpenStack Neutron ML2 MechanismDriver with OpenDaylight

Kyle Mestery (kmestery) <kmestery@...>
 

FYI:

For all those who tried this, I should have mentioned this is currently
work in progress. The intent below is to show all the Neutron APIs
being handled by the ODL NeutronAPIService. There is still work to
do around port_binding, and hooking up something like OVSDB
northbound into the NeutronAPIService in ODL before this becomes
useable.

I'll give a larger update in the TWS call Monday.

Thanks,
Kyle

On Nov 13, 2013, at 9:19 PM, Kyle Mestery (kmestery) <kmestery@...> wrote:

All:

After returning from the OpenStack Summit in Hong Kong last week, I've spent some time working on the Neutron ML2 MechanismDriver for ODL. The good news is that after plenty of help from Ryan Moats, I've got it working now! Instructions on how to use it are below. The next steps are to integrate this with something which plugs into the NeutronAPIService APIs I'm using in ODL now. For the OVSDB integration efforts there, we will also require some possible API calls to alert ODL about hosts as the come online.

To test out the plugin (including devstack support), try the following instructions:

Here are some very brief instructions on using the (fresh off the presses) OpenStack Neutron ML2 MechanismDriver with ODL:

• Setup a fresh VM running either Fedora (preferably 19) or Ubuntu (12.04 or newer).
• Checkout a devstack tree from here:
• git clone https://github.com/CiscoSystems/devstack.git
• git checkout opendaylight
• Now, setup your local.conf [1] files. This file should go into the root of your devstack directory. You can copy/paste the example below and modify the sections as the next section indicates:
• Make the following changes per the example below:
• SERVICE_HOST should be the IP of the host you're running devstack on.
• In the ml2_odl section, the "url" should have the IP of the host running ODL.
• Once modified, now stack:
• ./stack.sh
• Once this is complete, you should now have a setup which is sending Neutron API requests to ODL.

NOTE: This assumes you have a working ODL running somewhere.

The code to look at the OpenDaylight ML2 MechanismDriver is located here:

https://github.com/CiscoSystems/neutron/tree/odl_ml2

If you have any questions, please let me know and reach out to me.

Thanks!
Kyle

[1] local.conf file:
[[local|localrc]]
LOGFILE=stack.sh.log
#OFFLINE=True
RECLONE=yes

disable_service n-net
enable_service q-svc
#enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta
enable_service neutron

# ODL WITH ML2
#enable_service odl
Q_PLUGIN=ml2
#Q_AGENT=
Q_ML2_PLUGIN_MECHANISM_DRIVERS=opendaylight,logger
NEUTRON_REPO=https://github.com/CiscoSystems/neutron.git
NEUTRON_BRANCH=odl_ml2
Q_HOST=$SERVICE_HOST

disable_service rabbit
enable_service qpid

HOST_NAME=$(hostname)
SERVICE_HOST_NAME=${HOST_NAME}
SERVICE_HOST=192.168.56.101

FLOATING_RANGE=192.168.100.0/24
MYSQL_HOST=$SERVICE_HOST
RABBIT_HOST=$SERVICE_HOST
GLANCE_HOSTPORT=$SERVICE_HOST:9292
KEYSTONE_AUTH_HOST=$SERVICE_HOST
KEYSTONE_SERVICE_HOST=$SERVICE_HOST

MYSQL_PASSWORD=mysql
RABBIT_PASSWORD=rabbit
SERVICE_TOKEN=service
SERVICE_PASSWORD=admin
ADMIN_PASSWORD=admin

[[post-config|/etc/neutron/plugins/ml2/ml2_conf.ini]]
[ml2_odl]
url=http://192.168.56.1:8080/controller/nb/v2/neutron
username=admin
password=admin

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


Re: [controller-dev] How to use the OpenStack Neutron ML2 MechanismDriver with OpenDaylight

Hideyuki Tai <h-tai@...>
 

Hi kyle,

 

Thank you for sharing this information!

 

I checked out the devstack tree from here.

   git clone https://github.com/CiscoSystems/devstack.git

And, setup my local.conf and run stack.sh.

However, I got the error " ERROR: Unauthorized (HTTP 401)"

 

[odp-dev:~/work/devstack] $ ./stack.sh

(snip)

++ ALT_USERNAME=alt_demo

++ ALT_TENANT_NAME=alt_demo

++ [[ -z '' ]]

++ nova flavor-create m1.nano 42 64 0 1

ERROR: Unauthorized (HTTP 401)

+ clean

+ local r=1

++ jobs -p

+ kill

[odp-dev:~/work/devstack] $

 

And I also saw other error messages in output of stack.sh like this:

 

ERROR: Invalid OpenStack Nova credentials.

 

What am I missing here?

 

Regards,

Hideyuki Tai

 

 

From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Kyle Mestery (kmestery)
Sent: Thursday, November 14, 2013 12:19 PM
To: controller-dev@...
Cc: ovsdb-dev@...
Subject: [controller-dev] How to use the OpenStack Neutron ML2 MechanismDriver with OpenDaylight

 

All:

 

After returning from the OpenStack Summit in Hong Kong last week, I've spent some time working on the Neutron ML2 MechanismDriver for ODL. The good news is that after plenty of help from Ryan Moats, I've got it working now! Instructions on how to use it are below. The next steps are to integrate this with something which plugs into the NeutronAPIService APIs I'm using in ODL now. For the OVSDB integration efforts there, we will also require some possible API calls to alert ODL about hosts as the come online.

 

To test out the plugin (including devstack support), try the following instructions:

 

Here are some very brief instructions on using the (fresh off the presses) OpenStack Neutron ML2 MechanismDriver with ODL:

 

  1. Setup a fresh VM running either Fedora (preferably 19) or Ubuntu (12.04 or newer).
  2. Checkout a devstack tree from here:
    1. git clone https://github.com/CiscoSystems/devstack.git
    2. git checkout opendaylight
  1. Now, setup your local.conf [1] files. This file should go into the root of your devstack directory. You can copy/paste the example below and modify the sections as the next section indicates:
    1. Make the following changes per the example below:
      1. SERVICE_HOST should be the IP of the host you're running devstack on.
      2. In the ml2_odl section, the "url" should have the IP of the host running ODL.
  1. Once modified, now stack:
    1. ./stack.sh
  1. Once this is complete, you should now have a setup which is sending Neutron API requests to ODL.

 

NOTE: This assumes you have a working ODL running somewhere.

 

The code to look at the OpenDaylight ML2 MechanismDriver is located here:

 

 

If you have any questions, please let me know and reach out to me.

 

Thanks!

Kyle

 

[1] local.conf file:

[[local|localrc]]

LOGFILE=stack.sh.log

#OFFLINE=True

RECLONE=yes

 

disable_service n-net

enable_service q-svc

#enable_service q-agt

enable_service q-dhcp

enable_service q-l3

enable_service q-meta

enable_service neutron

 

# ODL WITH ML2

#enable_service odl

Q_PLUGIN=ml2

#Q_AGENT=

Q_ML2_PLUGIN_MECHANISM_DRIVERS=opendaylight,logger

NEUTRON_BRANCH=odl_ml2

Q_HOST=$SERVICE_HOST

 

disable_service rabbit

enable_service qpid

 

HOST_NAME=$(hostname)

SERVICE_HOST_NAME=${HOST_NAME}

SERVICE_HOST=192.168.56.101

 

FLOATING_RANGE=192.168.100.0/24

MYSQL_HOST=$SERVICE_HOST

RABBIT_HOST=$SERVICE_HOST

GLANCE_HOSTPORT=$SERVICE_HOST:9292

KEYSTONE_AUTH_HOST=$SERVICE_HOST

KEYSTONE_SERVICE_HOST=$SERVICE_HOST

 

MYSQL_PASSWORD=mysql

RABBIT_PASSWORD=rabbit

SERVICE_TOKEN=service

SERVICE_PASSWORD=admin

ADMIN_PASSWORD=admin

 

[[post-config|/etc/neutron/plugins/ml2/ml2_conf.ini]]

[ml2_odl]

username=admin

password=admin

 


Re: [controller-dev] How to use the OpenStack Neutron ML2 MechanismDriver with OpenDaylight

Kyle Mestery (kmestery) <kmestery@...>
 

Hi Hideyuki:

Is this a fresh Ubuntu/Fedora box? Do you have a firewall
enabled? Looks like your credentials are wrong. Make sure
you have updated the IP addresses in the localrc file before
running stack.sh.

Thanks,
Kyle

On Nov 21, 2013, at 8:30 AM, Hideyuki Tai <h-tai@...> wrote:

Hi kyle,

Thank you for sharing this information!

I checked out the devstack tree from here.
git clone https://github.com/CiscoSystems/devstack.git
And, setup my local.conf and run stack.sh.
However, I got the error " ERROR: Unauthorized (HTTP 401)"

[odp-dev:~/work/devstack] $ ./stack.sh
(snip)
++ ALT_USERNAME=alt_demo
++ ALT_TENANT_NAME=alt_demo
++ [[ -z '' ]]
++ nova flavor-create m1.nano 42 64 0 1
ERROR: Unauthorized (HTTP 401)
+ clean
+ local r=1
++ jobs -p
+ kill
[odp-dev:~/work/devstack] $

And I also saw other error messages in output of stack.sh like this:

ERROR: Invalid OpenStack Nova credentials.

What am I missing here?

Regards,
Hideyuki Tai


From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Kyle Mestery (kmestery)
Sent: Thursday, November 14, 2013 12:19 PM
To: controller-dev@...
Cc: ovsdb-dev@...
Subject: [controller-dev] How to use the OpenStack Neutron ML2 MechanismDriver with OpenDaylight

All:

After returning from the OpenStack Summit in Hong Kong last week, I've spent some time working on the Neutron ML2 MechanismDriver for ODL. The good news is that after plenty of help from Ryan Moats, I've got it working now! Instructions on how to use it are below. The next steps are to integrate this with something which plugs into the NeutronAPIService APIs I'm using in ODL now. For the OVSDB integration efforts there, we will also require some possible API calls to alert ODL about hosts as the come online.

To test out the plugin (including devstack support), try the following instructions:

Here are some very brief instructions on using the (fresh off the presses) OpenStack Neutron ML2 MechanismDriver with ODL:

• Setup a fresh VM running either Fedora (preferably 19) or Ubuntu (12.04 or newer).
• Checkout a devstack tree from here:
• git clone https://github.com/CiscoSystems/devstack.git
• git checkout opendaylight
• Now, setup your local.conf [1] files. This file should go into the root of your devstack directory. You can copy/paste the example below and modify the sections as the next section indicates:
• Make the following changes per the example below:
• SERVICE_HOST should be the IP of the host you're running devstack on.
• In the ml2_odl section, the "url" should have the IP of the host running ODL.
• Once modified, now stack:
• ./stack.sh
• Once this is complete, you should now have a setup which is sending Neutron API requests to ODL.

NOTE: This assumes you have a working ODL running somewhere.

The code to look at the OpenDaylight ML2 MechanismDriver is located here:

https://github.com/CiscoSystems/neutron/tree/odl_ml2

If you have any questions, please let me know and reach out to me.

Thanks!
Kyle

[1] local.conf file:
[[local|localrc]]
LOGFILE=stack.sh.log
#OFFLINE=True
RECLONE=yes

disable_service n-net
enable_service q-svc
#enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta
enable_service neutron

# ODL WITH ML2
#enable_service odl
Q_PLUGIN=ml2
#Q_AGENT=
Q_ML2_PLUGIN_MECHANISM_DRIVERS=opendaylight,logger
NEUTRON_REPO=https://github.com/CiscoSystems/neutron.git
NEUTRON_BRANCH=odl_ml2
Q_HOST=$SERVICE_HOST

disable_service rabbit
enable_service qpid

HOST_NAME=$(hostname)
SERVICE_HOST_NAME=${HOST_NAME}
SERVICE_HOST=192.168.56.101

FLOATING_RANGE=192.168.100.0/24
MYSQL_HOST=$SERVICE_HOST
RABBIT_HOST=$SERVICE_HOST
GLANCE_HOSTPORT=$SERVICE_HOST:9292
KEYSTONE_AUTH_HOST=$SERVICE_HOST
KEYSTONE_SERVICE_HOST=$SERVICE_HOST

MYSQL_PASSWORD=mysql
RABBIT_PASSWORD=rabbit
SERVICE_TOKEN=service
SERVICE_PASSWORD=admin
ADMIN_PASSWORD=admin

[[post-config|/etc/neutron/plugins/ml2/ml2_conf.ini]]
[ml2_odl]
url=http://192.168.56.1:8080/controller/nb/v2/neutron
username=admin
password=admin


Virtuailization addition and affinity service

Anees A Shaikh <aashaikh@...>
 

Unfortunately, I couldn't attend the last TSC call where the issue of
conflicting services in the virtualization edition was discussed further.
But in reading Dave's notes, it seems there was some expectation that the
current approach would need to be revisited: "big piece of post-release
work to do on finding the proper abstractions under which all three
projects can complement each other", referring to VTN/OpenDOVE/Affinity.

While we may need a way to support multiple virtualization implementations
simultaneously, this problem applies to the current VTN/OpenDOVE/OVSDB
projects and not the affinity project in my view. Affinity metadata
service should never conflict with any of these implementations, because
it provides a database of user-specified affinities / policies, not an
additional virtualization implementation -- i.e., it should not touch the
network (unless its scope is changing significantly).

If folks from these projects, have a different view, let's discuss it
further.

thanks.

-- Anees


OVSDB system test

Luis Gomez <luis.gomez@...>
 

Hi folks,

 

Just started writing system test plan for OVSDB and I found one issue, one possible improvement and one general question.

 

1) Lets starts with the issue: with a controller with 2 IP interfaces (like the one we use for system test) connected to mininet OVS switch in passive mode (sudo ovs-vsctl set-manager ptcp:6640), when I add a bridge using:

 

POST http://10.125.136.52:8080/controller/nb/v2/networkconfig/bridgedomain/bridge/OVS/MINI1/s3

 

this one gets configured with the 2 IP addresses of the controller:

 

    Bridge "s3"

        Controller "tcp:10.125.136.38:6633"

        Controller "tcp:10.125.136.52:6633"

            is_connected: true

        Port "s3"

            Interface "s3"

                type: internal

 

and this generates some instability in the controller (it adds and deletes the switch all the time):

 

2013-11-24 18:49:17.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 is connected to the Controller

2013-11-24 18:49:17.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:17.896 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:17.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 is connected to the Controller

2013-11-24 18:49:18.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.898 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:18.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33820 is connected to the Controller

2013-11-24 18:49:19.893 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33820 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.894 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:19.896 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

…..

 

And same behavior is observed when I start mininet with “sudo mn --controller=remote,ip=10.125.136.52 --topo linear,2” and then I make the connection to the OVS switch: both OF switches try to connect to both controller interfaces.

 

The solution would be to configure only the IP of the controller that is used (by linux routing) to reach the mininet VM? In this example 10.125.136.52.

 

Also this is not a strange scenario, I think the controller in a normal deployment will have at least 2 interfaces (operation and traffic) so it is good to fix this behavior.

 

 

2) The improvement is on the BridgeDomain NB API, if Ilook at the different methods available: I can add (POST) and remove (DELETE) bridge and ports configuration, but I do not see any method to list (GET) bridge/configuration. It would be nice to get a view of the bridge/port configuration from the controller NB.

 

 

3) And finally the question: The BridgeDomain POST method has a request body that it says it is documented under wiki.opendaylight.org project pages https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial, however this page is not yet finished. Can you please share some examples of custom values for this field?

 

 

Thanks/Luis

 


Re: OVSDB system test

Brent Salisbury
 

Hi Luis,

Thanks so much for the feedback, this is really awesome! I threw in some thoughts, Im sure the others have additional input due to their better knowledge of the core controller but here are some starters.

Since we automatically connect the OVS bridge instance to the controller we currently add all of the interfaces on the controller to the set-controller target until we decided the best way to tackle this. We just chatted about this in IRC (#opendaylight-ovsdb) over the weekend and we concluded a reasonable plan is to choose the interface on the controller containing the hosts default route and set the default target to that iface for each OVS bridge. It is on my list to code this evening so it will be patched shortly. The other would be a behavior if there was not a default route on the interface. It will likely be a random choice at that point since as you pointed out it gets very squirrely with multiples :) Please let us know if you have any other suggestions.

- In the meantime we have recommended explicitly setting the interface to bind in the config.ini file.

### config.ini path/location ###
distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/configuration/config.ini
### config.ini file ###
# Open Flow related system parameters
# TCP port on which the controller is listening (default 6633)
# of.listenPort=6633
# IP address of the controller (default: wild card)  <== Uncomment and add the desired address for socket binding.
# of.address = 

--Adjust that entry to an address you can bind to your host:
### config.ini file ###
of.address = 172.16.58.1 <==  I need to test this and see if it will accept a list also. 

2. The following methods for example are wired from the IPluginInBridgeDomainConfigService. Modifying ports/bridges is still yet to be implemented. I was looking at it last night and 

        help.append("---OVSDB CLI---\n");
        help.append("\t ovsconnect <ConnectionName> <ip-address>                        - Connect to OVSDB\n");
        help.append("\t addBridge <Node> <BridgeName>                                   - Add Bridge\n");
        help.append("\t getBridgeDomains <Node>                                         - Get Bridges\n");
        help.append("\t deleteBridgeDomain <Node> <BridgeName>                          - Delete a Bridge\n");
        help.append("\t addPort <Node> <BridgeName> <PortName> <type> <options pairs>   - Add Port\n");
        help.append("\t deletePort <Node> <BridgeName> <PortName>                       - Delete Port\n");
        help.append("\t addPortVlan <Node> <BridgeName> <PortName> <vlan>               - Add Port, Vlan\n");
        help.append("\t addTunnel <Node> <Bridge> <Port> <tunnel-type> <remote-ip>      - Add Tunnel\n");
        help.append(" printCache <Node>   

- On the configuration options we need to hash them out on how to match OVSDB specific or attributes not addressed by the ConfigConstants enum. Just putting them all into a CUSTOM object is sort of cantankerous. But I have not had a chance to get advice on this from the team. For example probably a bad idea but just pseudo code:

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getController());
                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_id());
                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getExternal_ids());
                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getFail_mode());
                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getOther_config());
                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getPorts());
                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStatus());
                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStp_enable());
                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_type());

3. Thanks a bunch for pointing out the page. I just updated the Postman collection. I also linked a screen capture below to how it looks in the raw postman view. We will work on more documentation in coming days.


- Its ironic you mentioned the get ports for a given bridge. I coded list bridges for the "NodeConnector" method last night thinking it was just that. But then I asked Madhu and got clarity that the method is in fact for listing the connection between two nodes (per javadoc: Returns a NodeConnector mapped to a Port (if available) that is created using addPort). So maybe the best route is to just list them in the 

- I am also a bit confused on the method getBridgeDomainNode.  The Javadoc for getBridgeDomainNode says "Returns a Node dedicated to a Bridge Domain (if available) that is created using createBridgeDomain.". I could probably think of a couple of things that could be but clarity on datapath, logical isolation and what not would help.

- Please let me know if you have any time this week to review some more of this and it would be great if you had a little time to walk through some of your questions or potential issues you see with us. It is super helpful for us being heads down in code to get such awesome feedback from you!

Regards,
-Brent


From: Luis Gomez <luis.gomez@...>
Date: Sunday, November 24, 2013 10:40 PM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: [ovsdb-dev] OVSDB system test

Hi folks,

 

Just started writing system test plan for OVSDB and I found one issue, one possible improvement and one general question.

 

1) Lets starts with the issue: with a controller with 2 IP interfaces (like the one we use for system test) connected to mininet OVS switch in passive mode (sudo ovs-vsctl set-manager ptcp:6640), when I add a bridge using:

 

POST http://10.125.136.52:8080/controller/nb/v2/networkconfig/bridgedomain/bridge/OVS/MINI1/s3

 

this one gets configured with the 2 IP addresses of the controller:

 

    Bridge "s3"

        Controller "tcp:10.125.136.38:6633"

        Controller "tcp:10.125.136.52:6633"

            is_connected: true

        Port "s3"

            Interface "s3"

                type: internal

 

and this generates some instability in the controller (it adds and deletes the switch all the time):

 

2013-11-24 18:49:17.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 is connected to the Controller

2013-11-24 18:49:17.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:17.896 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:17.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 is connected to the Controller

2013-11-24 18:49:18.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.898 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:18.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33820 is connected to the Controller

2013-11-24 18:49:19.893 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33820 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.894 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:19.896 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

…..

 

And same behavior is observed when I start mininet with “sudo mn --controller=remote,ip=10.125.136.52 --topo linear,2” and then I make the connection to the OVS switch: both OF switches try to connect to both controller interfaces.

 

The solution would be to configure only the IP of the controller that is used (by linux routing) to reach the mininet VM? In this example 10.125.136.52.

 

Also this is not a strange scenario, I think the controller in a normal deployment will have at least 2 interfaces (operation and traffic) so it is good to fix this behavior.

 


2) The improvement is on the BridgeDomain NB API, if Ilook at the different methods available: I can add (POST) and remove (DELETE) bridge and ports configuration, but I do not see any method to list (GET) bridge/configuration. It would be nice to get a view of the bridge/port configuration from the controller NB.

 


3) And finally the question: The BridgeDomain POST method has a request body that it says it is documented under wiki.opendaylight.org project pages https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial, however this page is not yet finished. Can you please share some examples of custom values for this field?

 

 

Thanks/Luis

 

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


Re: OVSDB system test

Luis Gomez <luis.gomez@...>
 

Hi Brent,

 

Thanks for your quick answer. I will try the examples from Postman and let you know. For the question about which controller IP should be configured in the OVS bridge, I still think ideally it should be the IP address of the interface the controller uses to reach the OVS node, this is to be consistent with the idea of sending and receiving on the same interface. But maybe this is difficult to code and in that case the config.ini file seems a good workaround as well.

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Sunday, November 24, 2013 8:49 PM
To: Luis Gomez; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [ovsdb-dev] OVSDB system test

 

Hi Luis,

 

Thanks so much for the feedback, this is really awesome! I threw in some thoughts, Im sure the others have additional input due to their better knowledge of the core controller but here are some starters.

 

Since we automatically connect the OVS bridge instance to the controller we currently add all of the interfaces on the controller to the set-controller target until we decided the best way to tackle this. We just chatted about this in IRC (#opendaylight-ovsdb) over the weekend and we concluded a reasonable plan is to choose the interface on the controller containing the hosts default route and set the default target to that iface for each OVS bridge. It is on my list to code this evening so it will be patched shortly. The other would be a behavior if there was not a default route on the interface. It will likely be a random choice at that point since as you pointed out it gets very squirrely with multiples :) Please let us know if you have any other suggestions.

 

- In the meantime we have recommended explicitly setting the interface to bind in the config.ini file.

 

### config.ini path/location ###

distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/configuration/config.ini

### config.ini file ###

# Open Flow related system parameters

# TCP port on which the controller is listening (default 6633)

# of.listenPort=6633

# IP address of the controller (default: wild card)  <== Uncomment and add the desired address for socket binding.

# of.address = 

 

--Adjust that entry to an address you can bind to your host:

### config.ini file ###

of.address = 172.16.58.1 <==  I need to test this and see if it will accept a list also. 

 

2. The following methods for example are wired from the IPluginInBridgeDomainConfigService. Modifying ports/bridges is still yet to be implemented. I was looking at it last night and 

 

        help.append("---OVSDB CLI---\n");

        help.append("\t ovsconnect <ConnectionName> <ip-address>                        - Connect to OVSDB\n");

        help.append("\t addBridge <Node> <BridgeName>                                   - Add Bridge\n");

        help.append("\t getBridgeDomains <Node>                                         - Get Bridges\n");

        help.append("\t deleteBridgeDomain <Node> <BridgeName>                          - Delete a Bridge\n");

        help.append("\t addPort <Node> <BridgeName> <PortName> <type> <options pairs>   - Add Port\n");

        help.append("\t deletePort <Node> <BridgeName> <PortName>                       - Delete Port\n");

        help.append("\t addPortVlan <Node> <BridgeName> <PortName> <vlan>               - Add Port, Vlan\n");

        help.append("\t addTunnel <Node> <Bridge> <Port> <tunnel-type> <remote-ip>      - Add Tunnel\n");

        help.append("          printCache <Node>   

 

- On the configuration options we need to hash them out on how to match OVSDB specific or attributes not addressed by the ConfigConstants enum. Just putting them all into a CUSTOM object is sort of cantankerous. But I have not had a chance to get advice on this from the team. For example probably a bad idea but just pseudo code:

 

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getController());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_id());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getExternal_ids());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getFail_mode());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getOther_config());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getPorts());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStatus());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStp_enable());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_type());

 

3. Thanks a bunch for pointing out the page. I just updated the Postman collection. I also linked a screen capture below to how it looks in the raw postman view. We will work on more documentation in coming days.

 

 

- Its ironic you mentioned the get ports for a given bridge. I coded list bridges for the "NodeConnector" method last night thinking it was just that. But then I asked Madhu and got clarity that the method is in fact for listing the connection between two nodes (per javadoc: Returns a NodeConnector mapped to a Port (if available) that is created using addPort). So maybe the best route is to just list them in the 

 

- I am also a bit confused on the method getBridgeDomainNode.  The Javadoc for getBridgeDomainNode says "Returns a Node dedicated to a Bridge Domain (if available) that is created using createBridgeDomain.". I could probably think of a couple of things that could be but clarity on datapath, logical isolation and what not would help.

 

- Please let me know if you have any time this week to review some more of this and it would be great if you had a little time to walk through some of your questions or potential issues you see with us. It is super helpful for us being heads down in code to get such awesome feedback from you!

 

Regards,

-Brent

 

 

From: Luis Gomez <luis.gomez@...>
Date: Sunday, November 24, 2013 10:40 PM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: [ovsdb-dev] OVSDB system test

 

Hi folks,

 

Just started writing system test plan for OVSDB and I found one issue, one possible improvement and one general question.

 

1) Lets starts with the issue: with a controller with 2 IP interfaces (like the one we use for system test) connected to mininet OVS switch in passive mode (sudo ovs-vsctl set-manager ptcp:6640), when I add a bridge using:

 

POST http://10.125.136.52:8080/controller/nb/v2/networkconfig/bridgedomain/bridge/OVS/MINI1/s3

 

this one gets configured with the 2 IP addresses of the controller:

 

    Bridge "s3"

        Controller "tcp:10.125.136.38:6633"

        Controller "tcp:10.125.136.52:6633"

            is_connected: true

        Port "s3"

            Interface "s3"

                type: internal

 

and this generates some instability in the controller (it adds and deletes the switch all the time):

 

2013-11-24 18:49:17.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 is connected to the Controller

2013-11-24 18:49:17.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:17.896 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:17.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 is connected to the Controller

2013-11-24 18:49:18.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.898 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:18.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33820 is connected to the Controller

2013-11-24 18:49:19.893 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33820 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.894 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:19.896 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

…..

 

And same behavior is observed when I start mininet with “sudo mn --controller=remote,ip=10.125.136.52 --topo linear,2” and then I make the connection to the OVS switch: both OF switches try to connect to both controller interfaces.

 

The solution would be to configure only the IP of the controller that is used (by linux routing) to reach the mininet VM? In this example 10.125.136.52.

 

Also this is not a strange scenario, I think the controller in a normal deployment will have at least 2 interfaces (operation and traffic) so it is good to fix this behavior.

 

 

2) The improvement is on the BridgeDomain NB API, if Ilook at the different methods available: I can add (POST) and remove (DELETE) bridge and ports configuration, but I do not see any method to list (GET) bridge/configuration. It would be nice to get a view of the bridge/port configuration from the controller NB.

 

 

3) And finally the question: The BridgeDomain POST method has a request body that it says it is documented under wiki.opendaylight.org project pages https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial, however this page is not yet finished. Can you please share some examples of custom values for this field?

 

 

Thanks/Luis

 

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


Re: [integration-dev] OVSDB system test

Madhu Venugopal
 

Hi Luis,

Exactly. The correct solution is to identify the appropriate Controller-ip-address to set based on the reachability information
towards the switch via OVSDB. And as Brent suggested, this is work in progress.

Please use the config.ini in the meanwhile.

I will also add some points later to Brent's on the original email.

Thanks,
Madhu

On 11/24/13, 10:25 PM, Luis Gomez wrote:

Hi Brent,

 

Thanks for your quick answer. I will try the examples from Postman and let you know. For the question about which controller IP should be configured in the OVS bridge, I still think ideally it should be the IP address of the interface the controller uses to reach the OVS node, this is to be consistent with the idea of sending and receiving on the same interface. But maybe this is difficult to code and in that case the config.ini file seems a good workaround as well.

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Sunday, November 24, 2013 8:49 PM
To: Luis Gomez; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [ovsdb-dev] OVSDB system test

 

Hi Luis,

 

Thanks so much for the feedback, this is really awesome! I threw in some thoughts, Im sure the others have additional input due to their better knowledge of the core controller but here are some starters.

 

Since we automatically connect the OVS bridge instance to the controller we currently add all of the interfaces on the controller to the set-controller target until we decided the best way to tackle this. We just chatted about this in IRC (#opendaylight-ovsdb) over the weekend and we concluded a reasonable plan is to choose the interface on the controller containing the hosts default route and set the default target to that iface for each OVS bridge. It is on my list to code this evening so it will be patched shortly. The other would be a behavior if there was not a default route on the interface. It will likely be a random choice at that point since as you pointed out it gets very squirrely with multiples :) Please let us know if you have any other suggestions.

 

- In the meantime we have recommended explicitly setting the interface to bind in the config.ini file.

 

### config.ini path/location ###

distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/configuration/config.ini

### config.ini file ###

# Open Flow related system parameters

# TCP port on which the controller is listening (default 6633)

# of.listenPort=6633

# IP address of the controller (default: wild card)  <== Uncomment and add the desired address for socket binding.

# of.address = 

 

--Adjust that entry to an address you can bind to your host:

### config.ini file ###

of.address = 172.16.58.1 <==  I need to test this and see if it will accept a list also. 

 

2. The following methods for example are wired from the IPluginInBridgeDomainConfigService. Modifying ports/bridges is still yet to be implemented. I was looking at it last night and 

 

        help.append("---OVSDB CLI---\n");

        help.append("\t ovsconnect <ConnectionName> <ip-address>                        - Connect to OVSDB\n");

        help.append("\t addBridge <Node> <BridgeName>                                   - Add Bridge\n");

        help.append("\t getBridgeDomains <Node>                                         - Get Bridges\n");

        help.append("\t deleteBridgeDomain <Node> <BridgeName>                          - Delete a Bridge\n");

        help.append("\t addPort <Node> <BridgeName> <PortName> <type> <options pairs>   - Add Port\n");

        help.append("\t deletePort <Node> <BridgeName> <PortName>                       - Delete Port\n");

        help.append("\t addPortVlan <Node> <BridgeName> <PortName> <vlan>               - Add Port, Vlan\n");

        help.append("\t addTunnel <Node> <Bridge> <Port> <tunnel-type> <remote-ip>      - Add Tunnel\n");

        help.append("          printCache <Node>   

 

- On the configuration options we need to hash them out on how to match OVSDB specific or attributes not addressed by the ConfigConstants enum. Just putting them all into a CUSTOM object is sort of cantankerous. But I have not had a chance to get advice on this from the team. For example probably a bad idea but just pseudo code:

 

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getController());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_id());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getExternal_ids());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getFail_mode());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getOther_config());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getPorts());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStatus());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStp_enable());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_type());

 

3. Thanks a bunch for pointing out the page. I just updated the Postman collection. I also linked a screen capture below to how it looks in the raw postman view. We will work on more documentation in coming days.

 

 

- Its ironic you mentioned the get ports for a given bridge. I coded list bridges for the "NodeConnector" method last night thinking it was just that. But then I asked Madhu and got clarity that the method is in fact for listing the connection between two nodes (per javadoc: Returns a NodeConnector mapped to a Port (if available) that is created using addPort). So maybe the best route is to just list them in the 

 

- I am also a bit confused on the method getBridgeDomainNode.  The Javadoc for getBridgeDomainNode says "Returns a Node dedicated to a Bridge Domain (if available) that is created using createBridgeDomain.". I could probably think of a couple of things that could be but clarity on datapath, logical isolation and what not would help.

 

- Please let me know if you have any time this week to review some more of this and it would be great if you had a little time to walk through some of your questions or potential issues you see with us. It is super helpful for us being heads down in code to get such awesome feedback from you!

 

Regards,

-Brent

 

 

From: Luis Gomez <luis.gomez@...>
Date: Sunday, November 24, 2013 10:40 PM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: [ovsdb-dev] OVSDB system test

 

Hi folks,

 

Just started writing system test plan for OVSDB and I found one issue, one possible improvement and one general question.

 

1) Lets starts with the issue: with a controller with 2 IP interfaces (like the one we use for system test) connected to mininet OVS switch in passive mode (sudo ovs-vsctl set-manager ptcp:6640), when I add a bridge using:

 

POST http://10.125.136.52:8080/controller/nb/v2/networkconfig/bridgedomain/bridge/OVS/MINI1/s3

 

this one gets configured with the 2 IP addresses of the controller:

 

    Bridge "s3"

        Controller "tcp:10.125.136.38:6633"

        Controller "tcp:10.125.136.52:6633"

            is_connected: true

        Port "s3"

            Interface "s3"

                type: internal

 

and this generates some instability in the controller (it adds and deletes the switch all the time):

 

2013-11-24 18:49:17.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 is connected to the Controller

2013-11-24 18:49:17.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:17.896 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:17.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 is connected to the Controller

2013-11-24 18:49:18.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.898 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:18.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33820 is connected to the Controller

2013-11-24 18:49:19.893 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33820 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.894 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:19.896 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

…..

 

And same behavior is observed when I start mininet with “sudo mn --controller=remote,ip=10.125.136.52 --topo linear,2” and then I make the connection to the OVS switch: both OF switches try to connect to both controller interfaces.

 

The solution would be to configure only the IP of the controller that is used (by linux routing) to reach the mininet VM? In this example 10.125.136.52.

 

Also this is not a strange scenario, I think the controller in a normal deployment will have at least 2 interfaces (operation and traffic) so it is good to fix this behavior.

 

 

2) The improvement is on the BridgeDomain NB API, if Ilook at the different methods available: I can add (POST) and remove (DELETE) bridge and ports configuration, but I do not see any method to list (GET) bridge/configuration. It would be nice to get a view of the bridge/port configuration from the controller NB.

 

 

3) And finally the question: The BridgeDomain POST method has a request body that it says it is documented under wiki.opendaylight.org project pages https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial, however this page is not yet finished. Can you please share some examples of custom values for this field?

 

 

Thanks/Luis

 

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



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


Re: [OpenDaylight Discuss] Virtuailization addition and affinity service

Benny Rochwerger <BennyR@...>
 

Anees,

I have to disagree with you on the need for the Affinity Service to touch the network. Yes, we do not need yet another virtualization implementation, but this is not about virtualization is about abstraction. As you may recall in the original Defense4All proposal we talked about the need to have controller services that provide an abstraction of the network and give higher level applications (L4-7, Security) the capability of monitoring and controlling the network without needing to fully understand the L2-3 topology. These is what at the time we called the "Traffic Redirection" and "Statistics Collection" services. After presenting our requirements, we were told that these type of network abstraction services is exactly with Affinity is all about and after a few discussions with the Affinity team we agreed that with some minor changes (mainly syntactic) we can rely on Affinity to do the low level network control for us (the slide set that describes these changes is attached).

The need for a network abstraction is orthogonal to network virtualization, our application for example works both in physical networks and in virtualized networks (in fact all the deployed PoCs we have up to now are physical), so it will be wrong in my opinion to look at something like affinity only in the context of virtual networks. Having said that, I do believe that when virtual network are deployed, affinity (or similar) should leverage the network virtualization service, i.e., in that case instead of touching the network directly it should ask the network virtulization to do it.

Benny

-----Original Message-----
From: discuss-bounces@... [mailto:discuss-bounces@...] On Behalf Of Anees A Shaikh
Sent: Saturday, November 23, 2013 5:05 PM
To: discuss@...
Cc: <affinity-dev@...>; ovsdb-dev@...; opendove-dev@...; <vtn-dev@...>
Subject: [OpenDaylight Discuss] Virtuailization addition and affinity service

Unfortunately, I couldn't attend the last TSC call where the issue of conflicting services in the virtualization edition was discussed further.
But in reading Dave's notes, it seems there was some expectation that the current approach would need to be revisited: "big piece of post-release work to do on finding the proper abstractions under which all three projects can complement each other", referring to VTN/OpenDOVE/Affinity.

While we may need a way to support multiple virtualization implementations simultaneously, this problem applies to the current VTN/OpenDOVE/OVSDB projects and not the affinity project in my view. Affinity metadata service should never conflict with any of these implementations, because it provides a database of user-specified affinities / policies, not an additional virtualization implementation -- i.e., it should not touch the network (unless its scope is changing significantly).

If folks from these projects, have a different view, let's discuss it further.

thanks.

-- Anees

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss


Re: [OpenDaylight Discuss] Virtualization addition and affinity service

Benny Rochwerger <BennyR@...>
 

Resending with a link instead of an attachment
----

Anees,

I have to disagree with you on the need for the Affinity Service to touch the network. Yes, we do not need yet another virtualization implementation, but this is not about virtualization is about abstraction. As you may recall in the original Defense4All proposal we talked about the need to have controller services that provide an abstraction of the network and give higher level applications (L4-7, Security) the capability of monitoring and controlling the network without needing to fully understand the L2-3 topology. These is what at the time we called the "Traffic Redirection" and "Statistics Collection" services. After presenting our requirements, we were told that these type of network abstraction services is exactly with Affinity is all about and after a few discussions with the Affinity team we agreed that with some minor changes (mainly syntactic) we can rely on Affinity to do the low level network control for us (the slide set that describes these changes can be found in the wiki at: https://wiki.opendaylight.org/view/File:Defense4All_Proposal_Overview_-_130903_-_Plexxi.pdf).

The need for a network abstraction is orthogonal to network virtualization, our application for example works both in physical networks and in virtualized networks (in fact all the deployed PoCs we have up to now are physical), so it will be wrong in my opinion to look at something like affinity only in the context of virtual networks. Having said that, I do believe that when virtual network are deployed, affinity (or similar) should leverage the network virtualization service, i.e., in that case instead of touching the network directly it should ask the network virtulization to do it.

Benny

-----Original Message-----
From: discuss-bounces@... [mailto:discuss-bounces@...] On Behalf Of Anees A Shaikh
Sent: Saturday, November 23, 2013 5:05 PM
To: discuss@...
Cc: <affinity-dev@...>; ovsdb-dev@...; opendove-dev@...; <vtn-dev@...>
Subject: [OpenDaylight Discuss] Virtuailization addition and affinity service

Unfortunately, I couldn't attend the last TSC call where the issue of conflicting services in the virtualization edition was discussed further.
But in reading Dave's notes, it seems there was some expectation that the current approach would need to be revisited: "big piece of post-release work to do on finding the proper abstractions under which all three projects can complement each other", referring to VTN/OpenDOVE/Affinity.

While we may need a way to support multiple virtualization implementations simultaneously, this problem applies to the current VTN/OpenDOVE/OVSDB projects and not the affinity project in my view. Affinity metadata service should never conflict with any of these implementations, because it provides a database of user-specified affinities / policies, not an additional virtualization implementation -- i.e., it should not touch the network (unless its scope is changing significantly).

If folks from these projects, have a different view, let's discuss it further.

thanks.

-- Anees

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss


Re: [OpenDaylight Discuss] Virtuailization addition and affinity service

Anees A Shaikh <aashaikh@...>
 

Benny, your last sentence is what I am getting at -- so I don't think
there is any disagreement. I'm not arguing that we don't need network
abstractions separate from network virtualization. And I agree that
affinity and other services could apply beyond the virtualization edition.

But in the context of the virtualization edition, we have implementations
managing the network. Affinity and other such services should be
providing information about user intent to these implementations -- not
providing their own manipulation of the network, which we've seen
interferes with what the network virtualization services are trying to do.

thanks.

-- Anees

Benny Rochwerger <BennyR@...> wrote on 11/25/2013 02:46:42 AM:

From: Benny Rochwerger <BennyR@...>
To: Anees A Shaikh/Watson/IBM@IBMUS,
"discuss@..." <discuss@...>,
Cc: "<affinity-dev@...>" <affinity-
dev@...>, "ovsdb-dev@..."
<ovsdb-dev@...>, "opendove-
dev@..." <opendove-dev@...>,
"<vtn-dev@...>" <vtn-dev@...>
Date: 11/25/2013 02:47 AM
Subject: RE: [OpenDaylight Discuss] Virtuailization addition and
affinity service

Anees,

I have to disagree with you on the need for the Affinity Service to
touch the network. Yes, we do not need yet another virtualization
implementation, but this is not about virtualization is about
abstraction. As you may recall in the original Defense4All proposal
we talked about the need to have controller services that provide an
abstraction of the network and give higher level applications (L4-7,
Security) the capability of monitoring and controlling the network
without needing to fully understand the L2-3 topology. These is what
at the time we called the "Traffic Redirection" and "Statistics
Collection" services. After presenting our requirements, we were
told that these type of network abstraction services is exactly with
Affinity is all about and after a few discussions with the Affinity
team we agreed that with some minor changes (mainly syntactic) we
can rely on Affinity to do the low level network control for us (the
slide set that describes these changes is attached).

The need for a network abstraction is orthogonal to network
virtualization, our application for example works both in physical
networks and in virtualized networks (in fact all the deployed PoCs
we have up to now are physical), so it will be wrong in my opinion
to look at something like affinity only in the context of virtual
networks. Having said that, I do believe that when virtual network
are deployed, affinity (or similar) should leverage the network
virtualization service, i.e., in that case instead of touching the
network directly it should ask the network virtulization to do it.

Benny

-----Original Message-----
From: discuss-bounces@... [mailto:discuss-
bounces@...] On Behalf Of Anees A Shaikh
Sent: Saturday, November 23, 2013 5:05 PM
To: discuss@...
Cc: <affinity-dev@...>; ovsdb-
dev@...; opendove-dev@...;
<vtn-dev@...>
Subject: [OpenDaylight Discuss] Virtuailization addition and affinity
service

Unfortunately, I couldn't attend the last TSC call where the issue
of conflicting services in the virtualization edition was discussed
further.
But in reading Dave's notes, it seems there was some expectation
that the current approach would need to be revisited: "big piece of
post-release work to do on finding the proper abstractions under
which all three projects can complement each other", referring to
VTN/OpenDOVE/Affinity.

While we may need a way to support multiple virtualization
implementations simultaneously, this problem applies to the current
VTN/OpenDOVE/OVSDB projects and not the affinity project in my view.
Affinity metadata service should never conflict with any of these
implementations, because it provides a database of user-specified
affinities / policies, not an additional virtualization
implementation -- i.e., it should not touch the network (unless its
scope is changing significantly).

If folks from these projects, have a different view, let's discuss it
further.

thanks.

-- Anees

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
[attachment "Defense4All Proposal Overview - 130903 - Plexxi.pdf"
deleted by Anees A Shaikh/Watson/IBM]


Re: [OpenDaylight Discuss] Virtuailization addition and affinity service

Benny Rochwerger <BennyR@...>
 

Anees,

In that case I remove my disagreement, however from our point of view it is the affinity service that is providing the abstraction and the enforcement, whether affinity touches the network directly or thru a network virtualization layer should transparent applications the network abstraction API (I.e. affinity in our case)

Benny

Anees A Shaikh <aashaikh@...> wrote:


Benny, your last sentence is what I am getting at -- so I don't think
there is any disagreement. I'm not arguing that we don't need network
abstractions separate from network virtualization. And I agree that
affinity and other services could apply beyond the virtualization edition.

But in the context of the virtualization edition, we have implementations
managing the network. Affinity and other such services should be
providing information about user intent to these implementations -- not
providing their own manipulation of the network, which we've seen
interferes with what the network virtualization services are trying to do.

thanks.

-- Anees

Benny Rochwerger <BennyR@...> wrote on 11/25/2013 02:46:42 AM:

From: Benny Rochwerger <BennyR@...>
To: Anees A Shaikh/Watson/IBM@IBMUS,
"discuss@..." <discuss@...>,
Cc: "<affinity-dev@...>" <affinity-
dev@...>, "ovsdb-dev@..."
<ovsdb-dev@...>, "opendove-
dev@..." <opendove-dev@...>,
"<vtn-dev@...>" <vtn-dev@...>
Date: 11/25/2013 02:47 AM
Subject: RE: [OpenDaylight Discuss] Virtuailization addition and
affinity service

Anees,

I have to disagree with you on the need for the Affinity Service to
touch the network. Yes, we do not need yet another virtualization
implementation, but this is not about virtualization is about
abstraction. As you may recall in the original Defense4All proposal
we talked about the need to have controller services that provide an
abstraction of the network and give higher level applications (L4-7,
Security) the capability of monitoring and controlling the network
without needing to fully understand the L2-3 topology. These is what
at the time we called the "Traffic Redirection" and "Statistics
Collection" services. After presenting our requirements, we were
told that these type of network abstraction services is exactly with
Affinity is all about and after a few discussions with the Affinity
team we agreed that with some minor changes (mainly syntactic) we
can rely on Affinity to do the low level network control for us (the
slide set that describes these changes is attached).

The need for a network abstraction is orthogonal to network
virtualization, our application for example works both in physical
networks and in virtualized networks (in fact all the deployed PoCs
we have up to now are physical), so it will be wrong in my opinion
to look at something like affinity only in the context of virtual
networks. Having said that, I do believe that when virtual network
are deployed, affinity (or similar) should leverage the network
virtualization service, i.e., in that case instead of touching the
network directly it should ask the network virtulization to do it.

Benny

-----Original Message-----
From: discuss-bounces@... [mailto:discuss-
bounces@...] On Behalf Of Anees A Shaikh
Sent: Saturday, November 23, 2013 5:05 PM
To: discuss@...
Cc: <affinity-dev@...>; ovsdb-
dev@...; opendove-dev@...;
<vtn-dev@...>
Subject: [OpenDaylight Discuss] Virtuailization addition and affinity
service

Unfortunately, I couldn't attend the last TSC call where the issue
of conflicting services in the virtualization edition was discussed
further.
But in reading Dave's notes, it seems there was some expectation
that the current approach would need to be revisited: "big piece of
post-release work to do on finding the proper abstractions under
which all three projects can complement each other", referring to
VTN/OpenDOVE/Affinity.

While we may need a way to support multiple virtualization
implementations simultaneously, this problem applies to the current
VTN/OpenDOVE/OVSDB projects and not the affinity project in my view.
Affinity metadata service should never conflict with any of these
implementations, because it provides a database of user-specified
affinities / policies, not an additional virtualization
implementation -- i.e., it should not touch the network (unless its
scope is changing significantly).

If folks from these projects, have a different view, let's discuss it
further.

thanks.

-- Anees

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
[attachment "Defense4All Proposal Overview - 130903 - Plexxi.pdf"
deleted by Anees A Shaikh/Watson/IBM]


Re: [integration-dev] OVSDB system test

Luis Gomez <luis.gomez@...>
 

OK, thanks to the Postman examples I have the system test nailed down with the steps below:

 

- Configure mininet in passive mode (sudo ovs-vsctl set-manager ptcp:6640)

- Start mininet with topology tree,2 (the standard we use in system test): h1,h2 – s2 – s1 – s3 – h3,h4

- Controller connects to OVS node in mininet VM

- We create a new bridge s4

- We delete s1 ports s1-eth1 and s1-eth2

- We add s4 ports s4-eth1 and s4-eth2 replacing s1 connections

- We delete s1

- We ping and everything works!

So the test will fully replace switch s1 by new switch s4.

 

Thanks very much for your support.

 

BR/Luis

 

 

 

From: Madhu Venguopal [mailto:mavenugo@...]
Sent: Sunday, November 24, 2013 10:39 PM
To: Luis Gomez; Brent Salisbury; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Hi Luis,

Exactly. The correct solution is to identify the appropriate Controller-ip-address to set based on the reachability information
towards the switch via OVSDB. And as Brent suggested, this is work in progress.

Please use the config.ini in the meanwhile.

I will also add some points later to Brent's on the original email.

Thanks,
Madhu

On 11/24/13, 10:25 PM, Luis Gomez wrote:

Hi Brent,

 

Thanks for your quick answer. I will try the examples from Postman and let you know. For the question about which controller IP should be configured in the OVS bridge, I still think ideally it should be the IP address of the interface the controller uses to reach the OVS node, this is to be consistent with the idea of sending and receiving on the same interface. But maybe this is difficult to code and in that case the config.ini file seems a good workaround as well.

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Sunday, November 24, 2013 8:49 PM
To: Luis Gomez; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [ovsdb-dev] OVSDB system test

 

Hi Luis,

 

Thanks so much for the feedback, this is really awesome! I threw in some thoughts, Im sure the others have additional input due to their better knowledge of the core controller but here are some starters.

 

Since we automatically connect the OVS bridge instance to the controller we currently add all of the interfaces on the controller to the set-controller target until we decided the best way to tackle this. We just chatted about this in IRC (#opendaylight-ovsdb) over the weekend and we concluded a reasonable plan is to choose the interface on the controller containing the hosts default route and set the default target to that iface for each OVS bridge. It is on my list to code this evening so it will be patched shortly. The other would be a behavior if there was not a default route on the interface. It will likely be a random choice at that point since as you pointed out it gets very squirrely with multiples :) Please let us know if you have any other suggestions.

 

- In the meantime we have recommended explicitly setting the interface to bind in the config.ini file.

 

### config.ini path/location ###

distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/configuration/config.ini

### config.ini file ###

# Open Flow related system parameters

# TCP port on which the controller is listening (default 6633)

# of.listenPort=6633

# IP address of the controller (default: wild card)  <== Uncomment and add the desired address for socket binding.

# of.address = 

 

--Adjust that entry to an address you can bind to your host:

### config.ini file ###

of.address = 172.16.58.1 <==  I need to test this and see if it will accept a list also. 

 

2. The following methods for example are wired from the IPluginInBridgeDomainConfigService. Modifying ports/bridges is still yet to be implemented. I was looking at it last night and 

 

        help.append("---OVSDB CLI---\n");

        help.append("\t ovsconnect <ConnectionName> <ip-address>                        - Connect to OVSDB\n");

        help.append("\t addBridge <Node> <BridgeName>                                   - Add Bridge\n");

        help.append("\t getBridgeDomains <Node>                                         - Get Bridges\n");

        help.append("\t deleteBridgeDomain <Node> <BridgeName>                          - Delete a Bridge\n");

        help.append("\t addPort <Node> <BridgeName> <PortName> <type> <options pairs>   - Add Port\n");

        help.append("\t deletePort <Node> <BridgeName> <PortName>                       - Delete Port\n");

        help.append("\t addPortVlan <Node> <BridgeName> <PortName> <vlan>               - Add Port, Vlan\n");

        help.append("\t addTunnel <Node> <Bridge> <Port> <tunnel-type> <remote-ip>      - Add Tunnel\n");

        help.append("          printCache <Node>   

 

- On the configuration options we need to hash them out on how to match OVSDB specific or attributes not addressed by the ConfigConstants enum. Just putting them all into a CUSTOM object is sort of cantankerous. But I have not had a chance to get advice on this from the team. For example probably a bad idea but just pseudo code:

 

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getController());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_id());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getExternal_ids());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getFail_mode());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getOther_config());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getPorts());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStatus());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStp_enable());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_type());

 

3. Thanks a bunch for pointing out the page. I just updated the Postman collection. I also linked a screen capture below to how it looks in the raw postman view. We will work on more documentation in coming days.

 

 

- Its ironic you mentioned the get ports for a given bridge. I coded list bridges for the "NodeConnector" method last night thinking it was just that. But then I asked Madhu and got clarity that the method is in fact for listing the connection between two nodes (per javadoc: Returns a NodeConnector mapped to a Port (if available) that is created using addPort). So maybe the best route is to just list them in the 

 

- I am also a bit confused on the method getBridgeDomainNode.  The Javadoc for getBridgeDomainNode says "Returns a Node dedicated to a Bridge Domain (if available) that is created using createBridgeDomain.". I could probably think of a couple of things that could be but clarity on datapath, logical isolation and what not would help.

 

- Please let me know if you have any time this week to review some more of this and it would be great if you had a little time to walk through some of your questions or potential issues you see with us. It is super helpful for us being heads down in code to get such awesome feedback from you!

 

Regards,

-Brent

 

 

From: Luis Gomez <luis.gomez@...>
Date: Sunday, November 24, 2013 10:40 PM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: [ovsdb-dev] OVSDB system test

 

Hi folks,

 

Just started writing system test plan for OVSDB and I found one issue, one possible improvement and one general question.

 

1) Lets starts with the issue: with a controller with 2 IP interfaces (like the one we use for system test) connected to mininet OVS switch in passive mode (sudo ovs-vsctl set-manager ptcp:6640), when I add a bridge using:

 

POST http://10.125.136.52:8080/controller/nb/v2/networkconfig/bridgedomain/bridge/OVS/MINI1/s3

 

this one gets configured with the 2 IP addresses of the controller:

 

    Bridge "s3"

        Controller "tcp:10.125.136.38:6633"

        Controller "tcp:10.125.136.52:6633"

            is_connected: true

        Port "s3"

            Interface "s3"

                type: internal

 

and this generates some instability in the controller (it adds and deletes the switch all the time):

 

2013-11-24 18:49:17.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 is connected to the Controller

2013-11-24 18:49:17.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:17.896 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:17.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 is connected to the Controller

2013-11-24 18:49:18.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.898 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:18.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33820 is connected to the Controller

2013-11-24 18:49:19.893 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33820 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.894 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:19.896 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

…..

 

And same behavior is observed when I start mininet with “sudo mn --controller=remote,ip=10.125.136.52 --topo linear,2” and then I make the connection to the OVS switch: both OF switches try to connect to both controller interfaces.

 

The solution would be to configure only the IP of the controller that is used (by linux routing) to reach the mininet VM? In this example 10.125.136.52.

 

Also this is not a strange scenario, I think the controller in a normal deployment will have at least 2 interfaces (operation and traffic) so it is good to fix this behavior.

 

 

2) The improvement is on the BridgeDomain NB API, if Ilook at the different methods available: I can add (POST) and remove (DELETE) bridge and ports configuration, but I do not see any method to list (GET) bridge/configuration. It would be nice to get a view of the bridge/port configuration from the controller NB.

 

 

3) And finally the question: The BridgeDomain POST method has a request body that it says it is documented under wiki.opendaylight.org project pages https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial, however this page is not yet finished. Can you please share some examples of custom values for this field?

 

 

Thanks/Luis

 

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




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

 


Re: [integration-dev] OVSDB system test

Madhu Venugopal
 


Excellent. Thanks Luis.

Thanks,
Madhu

On 11/25/13, 1:02 PM, Luis Gomez wrote:

OK, thanks to the Postman examples I have the system test nailed down with the steps below:

 

- Configure mininet in passive mode (sudo ovs-vsctl set-manager ptcp:6640)

- Start mininet with topology tree,2 (the standard we use in system test): h1,h2 – s2 – s1 – s3 – h3,h4

- Controller connects to OVS node in mininet VM

- We create a new bridge s4

- We delete s1 ports s1-eth1 and s1-eth2

- We add s4 ports s4-eth1 and s4-eth2 replacing s1 connections

- We delete s1

- We ping and everything works!

So the test will fully replace switch s1 by new switch s4.

 

Thanks very much for your support.

 

BR/Luis

 

 

 

From: Madhu Venguopal [mailto:mavenugo@...]
Sent: Sunday, November 24, 2013 10:39 PM
To: Luis Gomez; Brent Salisbury; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Hi Luis,

Exactly. The correct solution is to identify the appropriate Controller-ip-address to set based on the reachability information
towards the switch via OVSDB. And as Brent suggested, this is work in progress.

Please use the config.ini in the meanwhile.

I will also add some points later to Brent's on the original email.

Thanks,
Madhu

On 11/24/13, 10:25 PM, Luis Gomez wrote:

Hi Brent,

 

Thanks for your quick answer. I will try the examples from Postman and let you know. For the question about which controller IP should be configured in the OVS bridge, I still think ideally it should be the IP address of the interface the controller uses to reach the OVS node, this is to be consistent with the idea of sending and receiving on the same interface. But maybe this is difficult to code and in that case the config.ini file seems a good workaround as well.

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Sunday, November 24, 2013 8:49 PM
To: Luis Gomez; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [ovsdb-dev] OVSDB system test

 

Hi Luis,

 

Thanks so much for the feedback, this is really awesome! I threw in some thoughts, Im sure the others have additional input due to their better knowledge of the core controller but here are some starters.

 

Since we automatically connect the OVS bridge instance to the controller we currently add all of the interfaces on the controller to the set-controller target until we decided the best way to tackle this. We just chatted about this in IRC (#opendaylight-ovsdb) over the weekend and we concluded a reasonable plan is to choose the interface on the controller containing the hosts default route and set the default target to that iface for each OVS bridge. It is on my list to code this evening so it will be patched shortly. The other would be a behavior if there was not a default route on the interface. It will likely be a random choice at that point since as you pointed out it gets very squirrely with multiples :) Please let us know if you have any other suggestions.

 

- In the meantime we have recommended explicitly setting the interface to bind in the config.ini file.

 

### config.ini path/location ###

distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/configuration/config.ini

### config.ini file ###

# Open Flow related system parameters

# TCP port on which the controller is listening (default 6633)

# of.listenPort=6633

# IP address of the controller (default: wild card)  <== Uncomment and add the desired address for socket binding.

# of.address = 

 

--Adjust that entry to an address you can bind to your host:

### config.ini file ###

of.address = 172.16.58.1 <==  I need to test this and see if it will accept a list also. 

 

2. The following methods for example are wired from the IPluginInBridgeDomainConfigService. Modifying ports/bridges is still yet to be implemented. I was looking at it last night and 

 

        help.append("---OVSDB CLI---\n");

        help.append("\t ovsconnect <ConnectionName> <ip-address>                        - Connect to OVSDB\n");

        help.append("\t addBridge <Node> <BridgeName>                                   - Add Bridge\n");

        help.append("\t getBridgeDomains <Node>                                         - Get Bridges\n");

        help.append("\t deleteBridgeDomain <Node> <BridgeName>                          - Delete a Bridge\n");

        help.append("\t addPort <Node> <BridgeName> <PortName> <type> <options pairs>   - Add Port\n");

        help.append("\t deletePort <Node> <BridgeName> <PortName>                       - Delete Port\n");

        help.append("\t addPortVlan <Node> <BridgeName> <PortName> <vlan>               - Add Port, Vlan\n");

        help.append("\t addTunnel <Node> <Bridge> <Port> <tunnel-type> <remote-ip>      - Add Tunnel\n");

        help.append("          printCache <Node>   

 

- On the configuration options we need to hash them out on how to match OVSDB specific or attributes not addressed by the ConfigConstants enum. Just putting them all into a CUSTOM object is sort of cantankerous. But I have not had a chance to get advice on this from the team. For example probably a bad idea but just pseudo code:

 

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getController());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_id());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getExternal_ids());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getFail_mode());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getOther_config());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getPorts());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStatus());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStp_enable());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_type());

 

3. Thanks a bunch for pointing out the page. I just updated the Postman collection. I also linked a screen capture below to how it looks in the raw postman view. We will work on more documentation in coming days.

 

 

- Its ironic you mentioned the get ports for a given bridge. I coded list bridges for the "NodeConnector" method last night thinking it was just that. But then I asked Madhu and got clarity that the method is in fact for listing the connection between two nodes (per javadoc: Returns a NodeConnector mapped to a Port (if available) that is created using addPort). So maybe the best route is to just list them in the 

 

- I am also a bit confused on the method getBridgeDomainNode.  The Javadoc for getBridgeDomainNode says "Returns a Node dedicated to a Bridge Domain (if available) that is created using createBridgeDomain.". I could probably think of a couple of things that could be but clarity on datapath, logical isolation and what not would help.

 

- Please let me know if you have any time this week to review some more of this and it would be great if you had a little time to walk through some of your questions or potential issues you see with us. It is super helpful for us being heads down in code to get such awesome feedback from you!

 

Regards,

-Brent

 

 

From: Luis Gomez <luis.gomez@...>
Date: Sunday, November 24, 2013 10:40 PM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: [ovsdb-dev] OVSDB system test

 

Hi folks,

 

Just started writing system test plan for OVSDB and I found one issue, one possible improvement and one general question.

 

1) Lets starts with the issue: with a controller with 2 IP interfaces (like the one we use for system test) connected to mininet OVS switch in passive mode (sudo ovs-vsctl set-manager ptcp:6640), when I add a bridge using:

 

POST http://10.125.136.52:8080/controller/nb/v2/networkconfig/bridgedomain/bridge/OVS/MINI1/s3

 

this one gets configured with the 2 IP addresses of the controller:

 

    Bridge "s3"

        Controller "tcp:10.125.136.38:6633"

        Controller "tcp:10.125.136.52:6633"

            is_connected: true

        Port "s3"

            Interface "s3"

                type: internal

 

and this generates some instability in the controller (it adds and deletes the switch all the time):

 

2013-11-24 18:49:17.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 is connected to the Controller

2013-11-24 18:49:17.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:17.896 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:17.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 is connected to the Controller

2013-11-24 18:49:18.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.898 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:18.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33820 is connected to the Controller

2013-11-24 18:49:19.893 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33820 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.894 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:19.896 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

…..

 

And same behavior is observed when I start mininet with “sudo mn --controller=remote,ip=10.125.136.52 --topo linear,2” and then I make the connection to the OVS switch: both OF switches try to connect to both controller interfaces.

 

The solution would be to configure only the IP of the controller that is used (by linux routing) to reach the mininet VM? In this example 10.125.136.52.

 

Also this is not a strange scenario, I think the controller in a normal deployment will have at least 2 interfaces (operation and traffic) so it is good to fix this behavior.

 

 

2) The improvement is on the BridgeDomain NB API, if Ilook at the different methods available: I can add (POST) and remove (DELETE) bridge and ports configuration, but I do not see any method to list (GET) bridge/configuration. It would be nice to get a view of the bridge/port configuration from the controller NB.

 

 

3) And finally the question: The BridgeDomain POST method has a request body that it says it is documented under wiki.opendaylight.org project pages https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial, however this page is not yet finished. Can you please share some examples of custom values for this field?

 

 

Thanks/Luis

 

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




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

 



Re: [integration-dev] OVSDB system test

Brent Salisbury
 

Luis, you are the man buddy. We will get you more docs and functions in coming days sir.

Thanks,
-Brent


From: Madhu Venugopal <mavenugo@...>
Date: Monday, November 25, 2013 5:43 PM
To: Luis Gomez <luis.gomez@...>, brent <brent.salisbury@...>, "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test


Excellent. Thanks Luis.

Thanks,
Madhu

On 11/25/13, 1:02 PM, Luis Gomez wrote:

OK, thanks to the Postman examples I have the system test nailed down with the steps below:

 

- Configure mininet in passive mode (sudo ovs-vsctl set-manager ptcp:6640)

- Start mininet with topology tree,2 (the standard we use in system test): h1,h2 – s2 – s1 – s3 – h3,h4

- Controller connects to OVS node in mininet VM

- We create a new bridge s4

- We delete s1 ports s1-eth1 and s1-eth2

- We add s4 ports s4-eth1 and s4-eth2 replacing s1 connections

- We delete s1

- We ping and everything works!

So the test will fully replace switch s1 by new switch s4.

 

Thanks very much for your support.

 

BR/Luis

 

 

 

From: Madhu Venguopal [mailto:mavenugo@...]
Sent: Sunday, November 24, 2013 10:39 PM
To: Luis Gomez; Brent Salisbury; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Hi Luis,

Exactly. The correct solution is to identify the appropriate Controller-ip-address to set based on the reachability information
towards the switch via OVSDB. And as Brent suggested, this is work in progress.

Please use the config.ini in the meanwhile.

I will also add some points later to Brent's on the original email.

Thanks,
Madhu

On 11/24/13, 10:25 PM, Luis Gomez wrote:

Hi Brent,

 

Thanks for your quick answer. I will try the examples from Postman and let you know. For the question about which controller IP should be configured in the OVS bridge, I still think ideally it should be the IP address of the interface the controller uses to reach the OVS node, this is to be consistent with the idea of sending and receiving on the same interface. But maybe this is difficult to code and in that case the config.ini file seems a good workaround as well.

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Sunday, November 24, 2013 8:49 PM
To: Luis Gomez; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [ovsdb-dev] OVSDB system test

 

Hi Luis,

 

Thanks so much for the feedback, this is really awesome! I threw in some thoughts, Im sure the others have additional input due to their better knowledge of the core controller but here are some starters.

 

Since we automatically connect the OVS bridge instance to the controller we currently add all of the interfaces on the controller to the set-controller target until we decided the best way to tackle this. We just chatted about this in IRC (#opendaylight-ovsdb) over the weekend and we concluded a reasonable plan is to choose the interface on the controller containing the hosts default route and set the default target to that iface for each OVS bridge. It is on my list to code this evening so it will be patched shortly. The other would be a behavior if there was not a default route on the interface. It will likely be a random choice at that point since as you pointed out it gets very squirrely with multiples :) Please let us know if you have any other suggestions.

 

- In the meantime we have recommended explicitly setting the interface to bind in the config.ini file.

 

### config.ini path/location ###

distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/configuration/config.ini

### config.ini file ###

# Open Flow related system parameters

# TCP port on which the controller is listening (default 6633)

# of.listenPort=6633

# IP address of the controller (default: wild card)  <== Uncomment and add the desired address for socket binding.

# of.address = 

 

--Adjust that entry to an address you can bind to your host:

### config.ini file ###

of.address = 172.16.58.1 <==  I need to test this and see if it will accept a list also. 

 

2. The following methods for example are wired from the IPluginInBridgeDomainConfigService. Modifying ports/bridges is still yet to be implemented. I was looking at it last night and 

 

        help.append("---OVSDB CLI---\n");

        help.append("\t ovsconnect <ConnectionName> <ip-address>                        - Connect to OVSDB\n");

        help.append("\t addBridge <Node> <BridgeName>                                   - Add Bridge\n");

        help.append("\t getBridgeDomains <Node>                                         - Get Bridges\n");

        help.append("\t deleteBridgeDomain <Node> <BridgeName>                          - Delete a Bridge\n");

        help.append("\t addPort <Node> <BridgeName> <PortName> <type> <options pairs>   - Add Port\n");

        help.append("\t deletePort <Node> <BridgeName> <PortName>                       - Delete Port\n");

        help.append("\t addPortVlan <Node> <BridgeName> <PortName> <vlan>               - Add Port, Vlan\n");

        help.append("\t addTunnel <Node> <Bridge> <Port> <tunnel-type> <remote-ip>      - Add Tunnel\n");

        help.append("          printCache <Node>   

 

- On the configuration options we need to hash them out on how to match OVSDB specific or attributes not addressed by the ConfigConstants enum. Just putting them all into a CUSTOM object is sort of cantankerous. But I have not had a chance to get advice on this from the team. For example probably a bad idea but just pseudo code:

 

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getController());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_id());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getExternal_ids());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getFail_mode());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getOther_config());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getPorts());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStatus());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStp_enable());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_type());

 

3. Thanks a bunch for pointing out the page. I just updated the Postman collection. I also linked a screen capture below to how it looks in the raw postman view. We will work on more documentation in coming days.

 

 

- Its ironic you mentioned the get ports for a given bridge. I coded list bridges for the "NodeConnector" method last night thinking it was just that. But then I asked Madhu and got clarity that the method is in fact for listing the connection between two nodes (per javadoc: Returns a NodeConnector mapped to a Port (if available) that is created using addPort). So maybe the best route is to just list them in the 

 

- I am also a bit confused on the method getBridgeDomainNode.  The Javadoc for getBridgeDomainNode says "Returns a Node dedicated to a Bridge Domain (if available) that is created using createBridgeDomain.". I could probably think of a couple of things that could be but clarity on datapath, logical isolation and what not would help.

 

- Please let me know if you have any time this week to review some more of this and it would be great if you had a little time to walk through some of your questions or potential issues you see with us. It is super helpful for us being heads down in code to get such awesome feedback from you!

 

Regards,

-Brent

 

 

From: Luis Gomez <luis.gomez@...>
Date: Sunday, November 24, 2013 10:40 PM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: [ovsdb-dev] OVSDB system test

 

Hi folks,

 

Just started writing system test plan for OVSDB and I found one issue, one possible improvement and one general question.

 

1) Lets starts with the issue: with a controller with 2 IP interfaces (like the one we use for system test) connected to mininet OVS switch in passive mode (sudo ovs-vsctl set-manager ptcp:6640), when I add a bridge using:

 

POST http://10.125.136.52:8080/controller/nb/v2/networkconfig/bridgedomain/bridge/OVS/MINI1/s3

 

this one gets configured with the 2 IP addresses of the controller:

 

    Bridge "s3"

        Controller "tcp:10.125.136.38:6633"

        Controller "tcp:10.125.136.52:6633"

            is_connected: true

        Port "s3"

            Interface "s3"

                type: internal

 

and this generates some instability in the controller (it adds and deletes the switch all the time):

 

2013-11-24 18:49:17.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 is connected to the Controller

2013-11-24 18:49:17.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:17.896 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:17.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 is connected to the Controller

2013-11-24 18:49:18.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.898 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:18.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33820 is connected to the Controller

2013-11-24 18:49:19.893 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33820 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.894 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:19.896 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

…..

 

And same behavior is observed when I start mininet with “sudo mn --controller=remote,ip=10.125.136.52 --topo linear,2” and then I make the connection to the OVS switch: both OF switches try to connect to both controller interfaces.

 

The solution would be to configure only the IP of the controller that is used (by linux routing) to reach the mininet VM? In this example 10.125.136.52.

 

Also this is not a strange scenario, I think the controller in a normal deployment will have at least 2 interfaces (operation and traffic) so it is good to fix this behavior.

 

 

2) The improvement is on the BridgeDomain NB API, if Ilook at the different methods available: I can add (POST) and remove (DELETE) bridge and ports configuration, but I do not see any method to list (GET) bridge/configuration. It would be nice to get a view of the bridge/port configuration from the controller NB.

 

 

3) And finally the question: The BridgeDomain POST method has a request body that it says it is documented under wiki.opendaylight.org project pages https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial, however this page is not yet finished. Can you please share some examples of custom values for this field?

 

 

Thanks/Luis

 

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




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

 



Re: [integration-dev] OVSDB system test

Luis Gomez <luis.gomez@...>
 

Actually I was too fast on the test cases, the ping after replacing one switch by another does not work but I think it is an issue in simple forwarding app. Have you also seen this behavior?

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Monday, November 25, 2013 2:46 PM
To: Madhu Venguopal; Luis Gomez; ovsdb-dev@...; Aswin Nair
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Luis, you are the man buddy. We will get you more docs and functions in coming days sir.

 

Thanks,

-Brent

 

 

From: Madhu Venugopal <mavenugo@...>
Date: Monday, November 25, 2013 5:43 PM
To: Luis Gomez <luis.gomez@...>, brent <brent.salisbury@...>, "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 


Excellent. Thanks Luis.

Thanks,
Madhu

On 11/25/13, 1:02 PM, Luis Gomez wrote:

OK, thanks to the Postman examples I have the system test nailed down with the steps below:

 

- Configure mininet in passive mode (sudo ovs-vsctl set-manager ptcp:6640)

- Start mininet with topology tree,2 (the standard we use in system test): h1,h2 – s2 – s1 – s3 – h3,h4

- Controller connects to OVS node in mininet VM

- We create a new bridge s4

- We delete s1 ports s1-eth1 and s1-eth2

- We add s4 ports s4-eth1 and s4-eth2 replacing s1 connections

- We delete s1

- We ping and everything works!

So the test will fully replace switch s1 by new switch s4.

 

Thanks very much for your support.

 

BR/Luis

 

 

 

From: Madhu Venguopal [mailto:mavenugo@...]
Sent: Sunday, November 24, 2013 10:39 PM
To: Luis Gomez; Brent Salisbury; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Hi Luis,

Exactly. The correct solution is to identify the appropriate Controller-ip-address to set based on the reachability information
towards the switch via OVSDB. And as Brent suggested, this is work in progress.

Please use the config.ini in the meanwhile.

I will also add some points later to Brent's on the original email.

Thanks,
Madhu

On 11/24/13, 10:25 PM, Luis Gomez wrote:

Hi Brent,

 

Thanks for your quick answer. I will try the examples from Postman and let you know. For the question about which controller IP should be configured in the OVS bridge, I still think ideally it should be the IP address of the interface the controller uses to reach the OVS node, this is to be consistent with the idea of sending and receiving on the same interface. But maybe this is difficult to code and in that case the config.ini file seems a good workaround as well.

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Sunday, November 24, 2013 8:49 PM
To: Luis Gomez; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [ovsdb-dev] OVSDB system test

 

Hi Luis,

 

Thanks so much for the feedback, this is really awesome! I threw in some thoughts, Im sure the others have additional input due to their better knowledge of the core controller but here are some starters.

 

Since we automatically connect the OVS bridge instance to the controller we currently add all of the interfaces on the controller to the set-controller target until we decided the best way to tackle this. We just chatted about this in IRC (#opendaylight-ovsdb) over the weekend and we concluded a reasonable plan is to choose the interface on the controller containing the hosts default route and set the default target to that iface for each OVS bridge. It is on my list to code this evening so it will be patched shortly. The other would be a behavior if there was not a default route on the interface. It will likely be a random choice at that point since as you pointed out it gets very squirrely with multiples :) Please let us know if you have any other suggestions.

 

- In the meantime we have recommended explicitly setting the interface to bind in the config.ini file.

 

### config.ini path/location ###

distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/configuration/config.ini

### config.ini file ###

# Open Flow related system parameters

# TCP port on which the controller is listening (default 6633)

# of.listenPort=6633

# IP address of the controller (default: wild card)  <== Uncomment and add the desired address for socket binding.

# of.address = 

 

--Adjust that entry to an address you can bind to your host:

### config.ini file ###

of.address = 172.16.58.1 <==  I need to test this and see if it will accept a list also. 

 

2. The following methods for example are wired from the IPluginInBridgeDomainConfigService. Modifying ports/bridges is still yet to be implemented. I was looking at it last night and 

 

        help.append("---OVSDB CLI---\n");

        help.append("\t ovsconnect <ConnectionName> <ip-address>                        - Connect to OVSDB\n");

        help.append("\t addBridge <Node> <BridgeName>                                   - Add Bridge\n");

        help.append("\t getBridgeDomains <Node>                                         - Get Bridges\n");

        help.append("\t deleteBridgeDomain <Node> <BridgeName>                          - Delete a Bridge\n");

        help.append("\t addPort <Node> <BridgeName> <PortName> <type> <options pairs>   - Add Port\n");

        help.append("\t deletePort <Node> <BridgeName> <PortName>                       - Delete Port\n");

        help.append("\t addPortVlan <Node> <BridgeName> <PortName> <vlan>               - Add Port, Vlan\n");

        help.append("\t addTunnel <Node> <Bridge> <Port> <tunnel-type> <remote-ip>      - Add Tunnel\n");

        help.append("          printCache <Node>   

 

- On the configuration options we need to hash them out on how to match OVSDB specific or attributes not addressed by the ConfigConstants enum. Just putting them all into a CUSTOM object is sort of cantankerous. But I have not had a chance to get advice on this from the team. For example probably a bad idea but just pseudo code:

 

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getController());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_id());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getExternal_ids());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getFail_mode());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getOther_config());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getPorts());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStatus());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStp_enable());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_type());

 

3. Thanks a bunch for pointing out the page. I just updated the Postman collection. I also linked a screen capture below to how it looks in the raw postman view. We will work on more documentation in coming days.

 

 

- Its ironic you mentioned the get ports for a given bridge. I coded list bridges for the "NodeConnector" method last night thinking it was just that. But then I asked Madhu and got clarity that the method is in fact for listing the connection between two nodes (per javadoc: Returns a NodeConnector mapped to a Port (if available) that is created using addPort). So maybe the best route is to just list them in the 

 

- I am also a bit confused on the method getBridgeDomainNode.  The Javadoc for getBridgeDomainNode says "Returns a Node dedicated to a Bridge Domain (if available) that is created using createBridgeDomain.". I could probably think of a couple of things that could be but clarity on datapath, logical isolation and what not would help.

 

- Please let me know if you have any time this week to review some more of this and it would be great if you had a little time to walk through some of your questions or potential issues you see with us. It is super helpful for us being heads down in code to get such awesome feedback from you!

 

Regards,

-Brent

 

 

From: Luis Gomez <luis.gomez@...>
Date: Sunday, November 24, 2013 10:40 PM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: [ovsdb-dev] OVSDB system test

 

Hi folks,

 

Just started writing system test plan for OVSDB and I found one issue, one possible improvement and one general question.

 

1) Lets starts with the issue: with a controller with 2 IP interfaces (like the one we use for system test) connected to mininet OVS switch in passive mode (sudo ovs-vsctl set-manager ptcp:6640), when I add a bridge using:

 

POST http://10.125.136.52:8080/controller/nb/v2/networkconfig/bridgedomain/bridge/OVS/MINI1/s3

 

this one gets configured with the 2 IP addresses of the controller:

 

    Bridge "s3"

        Controller "tcp:10.125.136.38:6633"

        Controller "tcp:10.125.136.52:6633"

            is_connected: true

        Port "s3"

            Interface "s3"

                type: internal

 

and this generates some instability in the controller (it adds and deletes the switch all the time):

 

2013-11-24 18:49:17.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 is connected to the Controller

2013-11-24 18:49:17.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:17.896 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:17.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 is connected to the Controller

2013-11-24 18:49:18.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.898 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:18.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33820 is connected to the Controller

2013-11-24 18:49:19.893 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33820 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.894 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:19.896 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

…..

 

And same behavior is observed when I start mininet with “sudo mn --controller=remote,ip=10.125.136.52 --topo linear,2” and then I make the connection to the OVS switch: both OF switches try to connect to both controller interfaces.

 

The solution would be to configure only the IP of the controller that is used (by linux routing) to reach the mininet VM? In this example 10.125.136.52.

 

Also this is not a strange scenario, I think the controller in a normal deployment will have at least 2 interfaces (operation and traffic) so it is good to fix this behavior.

 

 

2) The improvement is on the BridgeDomain NB API, if Ilook at the different methods available: I can add (POST) and remove (DELETE) bridge and ports configuration, but I do not see any method to list (GET) bridge/configuration. It would be nice to get a view of the bridge/port configuration from the controller NB.

 

 

3) And finally the question: The BridgeDomain POST method has a request body that it says it is documented under wiki.opendaylight.org project pages https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial, however this page is not yet finished. Can you please share some examples of custom values for this field?

 

 

Thanks/Luis

 

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





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

 

 


Re: [integration-dev] OVSDB system test

Luis Gomez <luis.gomez@...>
 

Sorry again, it does actually work, I just remembered the patches have to be bidirectional!

 

 

From: integration-dev-bounces@... [mailto:integration-dev-bounces@...] On Behalf Of Luis Gomez
Sent: Monday, November 25, 2013 5:45 PM
To: Brent Salisbury; Madhu Venguopal; ovsdb-dev@...; Aswin Nair
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Actually I was too fast on the test cases, the ping after replacing one switch by another does not work but I think it is an issue in simple forwarding app. Have you also seen this behavior?

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Monday, November 25, 2013 2:46 PM
To: Madhu Venguopal; Luis Gomez; ovsdb-dev@...; Aswin Nair
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Luis, you are the man buddy. We will get you more docs and functions in coming days sir.

 

Thanks,

-Brent

 

 

From: Madhu Venugopal <mavenugo@...>
Date: Monday, November 25, 2013 5:43 PM
To: Luis Gomez <luis.gomez@...>, brent <brent.salisbury@...>, "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 


Excellent. Thanks Luis.

Thanks,
Madhu

On 11/25/13, 1:02 PM, Luis Gomez wrote:

OK, thanks to the Postman examples I have the system test nailed down with the steps below:

 

- Configure mininet in passive mode (sudo ovs-vsctl set-manager ptcp:6640)

- Start mininet with topology tree,2 (the standard we use in system test): h1,h2 – s2 – s1 – s3 – h3,h4

- Controller connects to OVS node in mininet VM

- We create a new bridge s4

- We delete s1 ports s1-eth1 and s1-eth2

- We add s4 ports s4-eth1 and s4-eth2 replacing s1 connections

- We delete s1

- We ping and everything works!

So the test will fully replace switch s1 by new switch s4.

 

Thanks very much for your support.

 

BR/Luis

 

 

 

From: Madhu Venguopal [mailto:mavenugo@...]
Sent: Sunday, November 24, 2013 10:39 PM
To: Luis Gomez; Brent Salisbury; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Hi Luis,

Exactly. The correct solution is to identify the appropriate Controller-ip-address to set based on the reachability information
towards the switch via OVSDB. And as Brent suggested, this is work in progress.

Please use the config.ini in the meanwhile.

I will also add some points later to Brent's on the original email.

Thanks,
Madhu

On 11/24/13, 10:25 PM, Luis Gomez wrote:

Hi Brent,

 

Thanks for your quick answer. I will try the examples from Postman and let you know. For the question about which controller IP should be configured in the OVS bridge, I still think ideally it should be the IP address of the interface the controller uses to reach the OVS node, this is to be consistent with the idea of sending and receiving on the same interface. But maybe this is difficult to code and in that case the config.ini file seems a good workaround as well.

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Sunday, November 24, 2013 8:49 PM
To: Luis Gomez; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [ovsdb-dev] OVSDB system test

 

Hi Luis,

 

Thanks so much for the feedback, this is really awesome! I threw in some thoughts, Im sure the others have additional input due to their better knowledge of the core controller but here are some starters.

 

Since we automatically connect the OVS bridge instance to the controller we currently add all of the interfaces on the controller to the set-controller target until we decided the best way to tackle this. We just chatted about this in IRC (#opendaylight-ovsdb) over the weekend and we concluded a reasonable plan is to choose the interface on the controller containing the hosts default route and set the default target to that iface for each OVS bridge. It is on my list to code this evening so it will be patched shortly. The other would be a behavior if there was not a default route on the interface. It will likely be a random choice at that point since as you pointed out it gets very squirrely with multiples :) Please let us know if you have any other suggestions.

 

- In the meantime we have recommended explicitly setting the interface to bind in the config.ini file.

 

### config.ini path/location ###

distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/configuration/config.ini

### config.ini file ###

# Open Flow related system parameters

# TCP port on which the controller is listening (default 6633)

# of.listenPort=6633

# IP address of the controller (default: wild card)  <== Uncomment and add the desired address for socket binding.

# of.address = 

 

--Adjust that entry to an address you can bind to your host:

### config.ini file ###

of.address = 172.16.58.1 <==  I need to test this and see if it will accept a list also. 

 

2. The following methods for example are wired from the IPluginInBridgeDomainConfigService. Modifying ports/bridges is still yet to be implemented. I was looking at it last night and 

 

        help.append("---OVSDB CLI---\n");

        help.append("\t ovsconnect <ConnectionName> <ip-address>                        - Connect to OVSDB\n");

        help.append("\t addBridge <Node> <BridgeName>                                   - Add Bridge\n");

        help.append("\t getBridgeDomains <Node>                                         - Get Bridges\n");

        help.append("\t deleteBridgeDomain <Node> <BridgeName>                          - Delete a Bridge\n");

        help.append("\t addPort <Node> <BridgeName> <PortName> <type> <options pairs>   - Add Port\n");

        help.append("\t deletePort <Node> <BridgeName> <PortName>                       - Delete Port\n");

        help.append("\t addPortVlan <Node> <BridgeName> <PortName> <vlan>               - Add Port, Vlan\n");

        help.append("\t addTunnel <Node> <Bridge> <Port> <tunnel-type> <remote-ip>      - Add Tunnel\n");

        help.append("          printCache <Node>   

 

- On the configuration options we need to hash them out on how to match OVSDB specific or attributes not addressed by the ConfigConstants enum. Just putting them all into a CUSTOM object is sort of cantankerous. But I have not had a chance to get advice on this from the team. For example probably a bad idea but just pseudo code:

 

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getController());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_id());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getExternal_ids());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getFail_mode());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getOther_config());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getPorts());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStatus());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStp_enable());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_type());

 

3. Thanks a bunch for pointing out the page. I just updated the Postman collection. I also linked a screen capture below to how it looks in the raw postman view. We will work on more documentation in coming days.

 

 

- Its ironic you mentioned the get ports for a given bridge. I coded list bridges for the "NodeConnector" method last night thinking it was just that. But then I asked Madhu and got clarity that the method is in fact for listing the connection between two nodes (per javadoc: Returns a NodeConnector mapped to a Port (if available) that is created using addPort). So maybe the best route is to just list them in the 

 

- I am also a bit confused on the method getBridgeDomainNode.  The Javadoc for getBridgeDomainNode says "Returns a Node dedicated to a Bridge Domain (if available) that is created using createBridgeDomain.". I could probably think of a couple of things that could be but clarity on datapath, logical isolation and what not would help.

 

- Please let me know if you have any time this week to review some more of this and it would be great if you had a little time to walk through some of your questions or potential issues you see with us. It is super helpful for us being heads down in code to get such awesome feedback from you!

 

Regards,

-Brent

 

 

From: Luis Gomez <luis.gomez@...>
Date: Sunday, November 24, 2013 10:40 PM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: [ovsdb-dev] OVSDB system test

 

Hi folks,

 

Just started writing system test plan for OVSDB and I found one issue, one possible improvement and one general question.

 

1) Lets starts with the issue: with a controller with 2 IP interfaces (like the one we use for system test) connected to mininet OVS switch in passive mode (sudo ovs-vsctl set-manager ptcp:6640), when I add a bridge using:

 

POST http://10.125.136.52:8080/controller/nb/v2/networkconfig/bridgedomain/bridge/OVS/MINI1/s3

 

this one gets configured with the 2 IP addresses of the controller:

 

    Bridge "s3"

        Controller "tcp:10.125.136.38:6633"

        Controller "tcp:10.125.136.52:6633"

            is_connected: true

        Port "s3"

            Interface "s3"

                type: internal

 

and this generates some instability in the controller (it adds and deletes the switch all the time):

 

2013-11-24 18:49:17.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 is connected to the Controller

2013-11-24 18:49:17.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:17.896 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:17.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 is connected to the Controller

2013-11-24 18:49:18.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.898 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:18.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33820 is connected to the Controller

2013-11-24 18:49:19.893 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33820 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.894 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:19.896 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

…..

 

And same behavior is observed when I start mininet with “sudo mn --controller=remote,ip=10.125.136.52 --topo linear,2” and then I make the connection to the OVS switch: both OF switches try to connect to both controller interfaces.

 

The solution would be to configure only the IP of the controller that is used (by linux routing) to reach the mininet VM? In this example 10.125.136.52.

 

Also this is not a strange scenario, I think the controller in a normal deployment will have at least 2 interfaces (operation and traffic) so it is good to fix this behavior.

 

 

2) The improvement is on the BridgeDomain NB API, if Ilook at the different methods available: I can add (POST) and remove (DELETE) bridge and ports configuration, but I do not see any method to list (GET) bridge/configuration. It would be nice to get a view of the bridge/port configuration from the controller NB.

 

 

3) And finally the question: The BridgeDomain POST method has a request body that it says it is documented under wiki.opendaylight.org project pages https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial, however this page is not yet finished. Can you please share some examples of custom values for this field?

 

 

Thanks/Luis

 

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




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

 

 


Re: [integration-dev] OVSDB system test

Luis Gomez <luis.gomez@...>
 

Hi Brent, here is the collection I created for system test:

 

https://www.getpostman.com/collections/cb05d301b45c5b8a0554

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Monday, November 25, 2013 2:46 PM
To: Madhu Venguopal; Luis Gomez; ovsdb-dev@...; Aswin Nair
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Luis, you are the man buddy. We will get you more docs and functions in coming days sir.

 

Thanks,

-Brent

 

 

From: Madhu Venugopal <mavenugo@...>
Date: Monday, November 25, 2013 5:43 PM
To: Luis Gomez <luis.gomez@...>, brent <brent.salisbury@...>, "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 


Excellent. Thanks Luis.

Thanks,
Madhu

On 11/25/13, 1:02 PM, Luis Gomez wrote:

OK, thanks to the Postman examples I have the system test nailed down with the steps below:

 

- Configure mininet in passive mode (sudo ovs-vsctl set-manager ptcp:6640)

- Start mininet with topology tree,2 (the standard we use in system test): h1,h2 – s2 – s1 – s3 – h3,h4

- Controller connects to OVS node in mininet VM

- We create a new bridge s4

- We delete s1 ports s1-eth1 and s1-eth2

- We add s4 ports s4-eth1 and s4-eth2 replacing s1 connections

- We delete s1

- We ping and everything works!

So the test will fully replace switch s1 by new switch s4.

 

Thanks very much for your support.

 

BR/Luis

 

 

 

From: Madhu Venguopal [mailto:mavenugo@...]
Sent: Sunday, November 24, 2013 10:39 PM
To: Luis Gomez; Brent Salisbury; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Hi Luis,

Exactly. The correct solution is to identify the appropriate Controller-ip-address to set based on the reachability information
towards the switch via OVSDB. And as Brent suggested, this is work in progress.

Please use the config.ini in the meanwhile.

I will also add some points later to Brent's on the original email.

Thanks,
Madhu

On 11/24/13, 10:25 PM, Luis Gomez wrote:

Hi Brent,

 

Thanks for your quick answer. I will try the examples from Postman and let you know. For the question about which controller IP should be configured in the OVS bridge, I still think ideally it should be the IP address of the interface the controller uses to reach the OVS node, this is to be consistent with the idea of sending and receiving on the same interface. But maybe this is difficult to code and in that case the config.ini file seems a good workaround as well.

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Sunday, November 24, 2013 8:49 PM
To: Luis Gomez; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [ovsdb-dev] OVSDB system test

 

Hi Luis,

 

Thanks so much for the feedback, this is really awesome! I threw in some thoughts, Im sure the others have additional input due to their better knowledge of the core controller but here are some starters.

 

Since we automatically connect the OVS bridge instance to the controller we currently add all of the interfaces on the controller to the set-controller target until we decided the best way to tackle this. We just chatted about this in IRC (#opendaylight-ovsdb) over the weekend and we concluded a reasonable plan is to choose the interface on the controller containing the hosts default route and set the default target to that iface for each OVS bridge. It is on my list to code this evening so it will be patched shortly. The other would be a behavior if there was not a default route on the interface. It will likely be a random choice at that point since as you pointed out it gets very squirrely with multiples :) Please let us know if you have any other suggestions.

 

- In the meantime we have recommended explicitly setting the interface to bind in the config.ini file.

 

### config.ini path/location ###

distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/configuration/config.ini

### config.ini file ###

# Open Flow related system parameters

# TCP port on which the controller is listening (default 6633)

# of.listenPort=6633

# IP address of the controller (default: wild card)  <== Uncomment and add the desired address for socket binding.

# of.address = 

 

--Adjust that entry to an address you can bind to your host:

### config.ini file ###

of.address = 172.16.58.1 <==  I need to test this and see if it will accept a list also. 

 

2. The following methods for example are wired from the IPluginInBridgeDomainConfigService. Modifying ports/bridges is still yet to be implemented. I was looking at it last night and 

 

        help.append("---OVSDB CLI---\n");

        help.append("\t ovsconnect <ConnectionName> <ip-address>                        - Connect to OVSDB\n");

        help.append("\t addBridge <Node> <BridgeName>                                   - Add Bridge\n");

        help.append("\t getBridgeDomains <Node>                                         - Get Bridges\n");

        help.append("\t deleteBridgeDomain <Node> <BridgeName>                          - Delete a Bridge\n");

        help.append("\t addPort <Node> <BridgeName> <PortName> <type> <options pairs>   - Add Port\n");

        help.append("\t deletePort <Node> <BridgeName> <PortName>                       - Delete Port\n");

        help.append("\t addPortVlan <Node> <BridgeName> <PortName> <vlan>               - Add Port, Vlan\n");

        help.append("\t addTunnel <Node> <Bridge> <Port> <tunnel-type> <remote-ip>      - Add Tunnel\n");

        help.append("          printCache <Node>   

 

- On the configuration options we need to hash them out on how to match OVSDB specific or attributes not addressed by the ConfigConstants enum. Just putting them all into a CUSTOM object is sort of cantankerous. But I have not had a chance to get advice on this from the team. For example probably a bad idea but just pseudo code:

 

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getController());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_id());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getExternal_ids());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getFail_mode());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getOther_config());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getPorts());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStatus());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStp_enable());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_type());

 

3. Thanks a bunch for pointing out the page. I just updated the Postman collection. I also linked a screen capture below to how it looks in the raw postman view. We will work on more documentation in coming days.

 

 

- Its ironic you mentioned the get ports for a given bridge. I coded list bridges for the "NodeConnector" method last night thinking it was just that. But then I asked Madhu and got clarity that the method is in fact for listing the connection between two nodes (per javadoc: Returns a NodeConnector mapped to a Port (if available) that is created using addPort). So maybe the best route is to just list them in the 

 

- I am also a bit confused on the method getBridgeDomainNode.  The Javadoc for getBridgeDomainNode says "Returns a Node dedicated to a Bridge Domain (if available) that is created using createBridgeDomain.". I could probably think of a couple of things that could be but clarity on datapath, logical isolation and what not would help.

 

- Please let me know if you have any time this week to review some more of this and it would be great if you had a little time to walk through some of your questions or potential issues you see with us. It is super helpful for us being heads down in code to get such awesome feedback from you!

 

Regards,

-Brent

 

 

From: Luis Gomez <luis.gomez@...>
Date: Sunday, November 24, 2013 10:40 PM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: [ovsdb-dev] OVSDB system test

 

Hi folks,

 

Just started writing system test plan for OVSDB and I found one issue, one possible improvement and one general question.

 

1) Lets starts with the issue: with a controller with 2 IP interfaces (like the one we use for system test) connected to mininet OVS switch in passive mode (sudo ovs-vsctl set-manager ptcp:6640), when I add a bridge using:

 

POST http://10.125.136.52:8080/controller/nb/v2/networkconfig/bridgedomain/bridge/OVS/MINI1/s3

 

this one gets configured with the 2 IP addresses of the controller:

 

    Bridge "s3"

        Controller "tcp:10.125.136.38:6633"

        Controller "tcp:10.125.136.52:6633"

            is_connected: true

        Port "s3"

            Interface "s3"

                type: internal

 

and this generates some instability in the controller (it adds and deletes the switch all the time):

 

2013-11-24 18:49:17.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 is connected to the Controller

2013-11-24 18:49:17.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:17.896 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:17.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 is connected to the Controller

2013-11-24 18:49:18.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.898 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:18.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33820 is connected to the Controller

2013-11-24 18:49:19.893 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33820 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.894 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:19.896 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

…..

 

And same behavior is observed when I start mininet with “sudo mn --controller=remote,ip=10.125.136.52 --topo linear,2” and then I make the connection to the OVS switch: both OF switches try to connect to both controller interfaces.

 

The solution would be to configure only the IP of the controller that is used (by linux routing) to reach the mininet VM? In this example 10.125.136.52.

 

Also this is not a strange scenario, I think the controller in a normal deployment will have at least 2 interfaces (operation and traffic) so it is good to fix this behavior.

 

 

2) The improvement is on the BridgeDomain NB API, if Ilook at the different methods available: I can add (POST) and remove (DELETE) bridge and ports configuration, but I do not see any method to list (GET) bridge/configuration. It would be nice to get a view of the bridge/port configuration from the controller NB.

 

 

3) And finally the question: The BridgeDomain POST method has a request body that it says it is documented under wiki.opendaylight.org project pages https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial, however this page is not yet finished. Can you please share some examples of custom values for this field?

 

 

Thanks/Luis

 

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





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

 

 


Re: [integration-dev] OVSDB system test

Brent Salisbury
 

That’s awesome, thanks Luis. We were thinking about keeping a running collection in a directory in the project so this is much appreciated.

Thanks,
-Brent


From: Luis Gomez <luis.gomez@...>
Date: Monday, November 25, 2013 9:09 PM
To: brent <brent.salisbury@...>, Madhu Venugopal <mavenugo@...>, "ovsdb-dev@..." <ovsdb-dev@...>, Aswin Nair <aswinnair@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: RE: [integration-dev] [ovsdb-dev] OVSDB system test

Hi Brent, here is the collection I created for system test:

 

https://www.getpostman.com/collections/cb05d301b45c5b8a0554

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Monday, November 25, 2013 2:46 PM
To: Madhu Venguopal; Luis Gomez; ovsdb-dev@...; Aswin Nair
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Luis, you are the man buddy. We will get you more docs and functions in coming days sir.

 

Thanks,

-Brent

 

 

From: Madhu Venugopal <mavenugo@...>
Date: Monday, November 25, 2013 5:43 PM
To: Luis Gomez <luis.gomez@...>, brent <brent.salisbury@...>, "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 


Excellent. Thanks Luis.

Thanks,
Madhu

On 11/25/13, 1:02 PM, Luis Gomez wrote:

OK, thanks to the Postman examples I have the system test nailed down with the steps below:

 

- Configure mininet in passive mode (sudo ovs-vsctl set-manager ptcp:6640)

- Start mininet with topology tree,2 (the standard we use in system test): h1,h2 – s2 – s1 – s3 – h3,h4

- Controller connects to OVS node in mininet VM

- We create a new bridge s4

- We delete s1 ports s1-eth1 and s1-eth2

- We add s4 ports s4-eth1 and s4-eth2 replacing s1 connections

- We delete s1

- We ping and everything works!

So the test will fully replace switch s1 by new switch s4.

 

Thanks very much for your support.

 

BR/Luis

 

 

 

From: Madhu Venguopal [mailto:mavenugo@...]
Sent: Sunday, November 24, 2013 10:39 PM
To: Luis Gomez; Brent Salisbury; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [integration-dev] [ovsdb-dev] OVSDB system test

 

Hi Luis,

Exactly. The correct solution is to identify the appropriate Controller-ip-address to set based on the reachability information
towards the switch via OVSDB. And as Brent suggested, this is work in progress.

Please use the config.ini in the meanwhile.

I will also add some points later to Brent's on the original email.

Thanks,
Madhu

On 11/24/13, 10:25 PM, Luis Gomez wrote:

Hi Brent,

 

Thanks for your quick answer. I will try the examples from Postman and let you know. For the question about which controller IP should be configured in the OVS bridge, I still think ideally it should be the IP address of the interface the controller uses to reach the OVS node, this is to be consistent with the idea of sending and receiving on the same interface. But maybe this is difficult to code and in that case the config.ini file seems a good workaround as well.

 

BR/Luis

 

 

From: Brent Salisbury [mailto:brent.salisbury@...]
Sent: Sunday, November 24, 2013 8:49 PM
To: Luis Gomez; ovsdb-dev@...
Cc: 'integration-dev@...'
Subject: Re: [ovsdb-dev] OVSDB system test

 

Hi Luis,

 

Thanks so much for the feedback, this is really awesome! I threw in some thoughts, Im sure the others have additional input due to their better knowledge of the core controller but here are some starters.

 

Since we automatically connect the OVS bridge instance to the controller we currently add all of the interfaces on the controller to the set-controller target until we decided the best way to tackle this. We just chatted about this in IRC (#opendaylight-ovsdb) over the weekend and we concluded a reasonable plan is to choose the interface on the controller containing the hosts default route and set the default target to that iface for each OVS bridge. It is on my list to code this evening so it will be patched shortly. The other would be a behavior if there was not a default route on the interface. It will likely be a random choice at that point since as you pointed out it gets very squirrely with multiples :) Please let us know if you have any other suggestions.

 

- In the meantime we have recommended explicitly setting the interface to bind in the config.ini file.

 

### config.ini path/location ###

distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/configuration/config.ini

### config.ini file ###

# Open Flow related system parameters

# TCP port on which the controller is listening (default 6633)

# of.listenPort=6633

# IP address of the controller (default: wild card)  <== Uncomment and add the desired address for socket binding.

# of.address = 

 

--Adjust that entry to an address you can bind to your host:

### config.ini file ###

of.address = 172.16.58.1 <==  I need to test this and see if it will accept a list also. 

 

2. The following methods for example are wired from the IPluginInBridgeDomainConfigService. Modifying ports/bridges is still yet to be implemented. I was looking at it last night and 

 

        help.append("---OVSDB CLI---\n");

        help.append("\t ovsconnect <ConnectionName> <ip-address>                        - Connect to OVSDB\n");

        help.append("\t addBridge <Node> <BridgeName>                                   - Add Bridge\n");

        help.append("\t getBridgeDomains <Node>                                         - Get Bridges\n");

        help.append("\t deleteBridgeDomain <Node> <BridgeName>                          - Delete a Bridge\n");

        help.append("\t addPort <Node> <BridgeName> <PortName> <type> <options pairs>   - Add Port\n");

        help.append("\t deletePort <Node> <BridgeName> <PortName>                       - Delete Port\n");

        help.append("\t addPortVlan <Node> <BridgeName> <PortName> <vlan>               - Add Port, Vlan\n");

        help.append("\t addTunnel <Node> <Bridge> <Port> <tunnel-type> <remote-ip>      - Add Tunnel\n");

        help.append("          printCache <Node>   

 

- On the configuration options we need to hash them out on how to match OVSDB specific or attributes not addressed by the ConfigConstants enum. Just putting them all into a CUSTOM object is sort of cantankerous. But I have not had a chance to get advice on this from the team. For example probably a bad idea but just pseudo code:

 

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getController());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_id());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getExternal_ids());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getFail_mode());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getOther_config());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getPorts());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStatus());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getStp_enable());

                bridgeConfigs.put(ConfigConstants.CUSTOM, bridge.getDatapath_type());

 

3. Thanks a bunch for pointing out the page. I just updated the Postman collection. I also linked a screen capture below to how it looks in the raw postman view. We will work on more documentation in coming days.

 

 

- Its ironic you mentioned the get ports for a given bridge. I coded list bridges for the "NodeConnector" method last night thinking it was just that. But then I asked Madhu and got clarity that the method is in fact for listing the connection between two nodes (per javadoc: Returns a NodeConnector mapped to a Port (if available) that is created using addPort). So maybe the best route is to just list them in the 

 

- I am also a bit confused on the method getBridgeDomainNode.  The Javadoc for getBridgeDomainNode says "Returns a Node dedicated to a Bridge Domain (if available) that is created using createBridgeDomain.". I could probably think of a couple of things that could be but clarity on datapath, logical isolation and what not would help.

 

- Please let me know if you have any time this week to review some more of this and it would be great if you had a little time to walk through some of your questions or potential issues you see with us. It is super helpful for us being heads down in code to get such awesome feedback from you!

 

Regards,

-Brent

 

 

From: Luis Gomez <luis.gomez@...>
Date: Sunday, November 24, 2013 10:40 PM
To: "ovsdb-dev@..." <ovsdb-dev@...>
Cc: "'integration-dev@...'" <integration-dev@...>
Subject: [ovsdb-dev] OVSDB system test

 

Hi folks,

 

Just started writing system test plan for OVSDB and I found one issue, one possible improvement and one general question.

 

1) Lets starts with the issue: with a controller with 2 IP interfaces (like the one we use for system test) connected to mininet OVS switch in passive mode (sudo ovs-vsctl set-manager ptcp:6640), when I add a bridge using:

 

POST http://10.125.136.52:8080/controller/nb/v2/networkconfig/bridgedomain/bridge/OVS/MINI1/s3

 

this one gets configured with the 2 IP addresses of the controller:

 

    Bridge "s3"

        Controller "tcp:10.125.136.38:6633"

        Controller "tcp:10.125.136.52:6633"

            is_connected: true

        Port "s3"

            Interface "s3"

                type: internal

 

and this generates some instability in the controller (it adds and deletes the switch all the time):

 

2013-11-24 18:49:17.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 is connected to the Controller

2013-11-24 18:49:17.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:17.896 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52330 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:17.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 is connected to the Controller

2013-11-24 18:49:18.895 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:18.898 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33818 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:18.900 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.890 PST [ControllerI/O Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.53:33820 is connected to the Controller

2013-11-24 18:49:19.893 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Replacing existing Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b with New Switch:10.125.136.53:33820 SWID:00:00:aa:e7:9a:2f:71:4b

2013-11-24 18:49:19.894 PST [SwitchEvent Thread] INFO  o.o.c.p.o.core.internal.Controller - Switch:10.125.136.39:52332 SWID:00:00:aa:e7:9a:2f:71:4b is removed

2013-11-24 18:49:19.896 PST [FRM EventHandler Collector] INFO  o.o.c.f.i.ForwardingRulesManager - Cleaning Flow database for Node OF|00:00:aa:e7:9a:2f:71:4b

…..

 

And same behavior is observed when I start mininet with “sudo mn --controller=remote,ip=10.125.136.52 --topo linear,2” and then I make the connection to the OVS switch: both OF switches try to connect to both controller interfaces.

 

The solution would be to configure only the IP of the controller that is used (by linux routing) to reach the mininet VM? In this example 10.125.136.52.

 

Also this is not a strange scenario, I think the controller in a normal deployment will have at least 2 interfaces (operation and traffic) so it is good to fix this behavior.

 

 

2) The improvement is on the BridgeDomain NB API, if Ilook at the different methods available: I can add (POST) and remove (DELETE) bridge and ports configuration, but I do not see any method to list (GET) bridge/configuration. It would be nice to get a view of the bridge/port configuration from the controller NB.

 

 

3) And finally the question: The BridgeDomain POST method has a request body that it says it is documented under wiki.opendaylight.org project pages https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial, however this page is not yet finished. Can you please share some examples of custom values for this field?

 

 

Thanks/Luis

 

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





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

 

 

81 - 100 of 4855