Date   

L2gw with ODL

Kamat, Maruti Haridas <maruti.kamat@...>
 

Hi Everyone,
 
  I would like to shed some light on why l2gw logic in OpenStack neutron cannot be a part of the ODL ML2 mechanism driver.
 
  1. The core plugin (today also called ML2 plugin) is designed to handle NB REST APIs only for the core resources (network, subnet and ports). Whenever a CUD operation is performed on these core resources, the core ML2 plugin  invokes the configured mechanism drivers (including the ODL mech driver).
  2. As the L2gw resources (logical l2-gateway and l2-gateway-connections) are not core resources, we introduced a new service plugin in Neutron in Kilo release. Neutron allows core plugin and service plugin to co-exist.
  3. The L2gw service plugin implements NB REST APIs for the logical l2-gateway and l2-gateway-connection resources. These calls do not land in the core plugin (the ODL ML2 plugin).
  4. Today, the L2gw service plugin is implemented (tight coupling) in such a way that it assumes that it has to communicate with an L2gw agent over the RabbitMQ message bus. I am trying to modularize this code to put it in a service plugin’s provider driver (like how LBaaS, or VPNaaS does). The reason: the user can configure the ODL provider driver for the l2gw service plugin so that this driver will proxy the NB calls into ODL REST calls (without needing RabbitMQ bus and the l2gw agent).
  5. The existing ODL mechanism driver for the ODL ML2 plugin will only handle port CUD operations to be sent to the ODL controller.
 
Please let me know if you have any questions, or need any further clarifications.
 
Thanks,
Maruti
 


Re: [integration-dev] showOvsdbMdsal.py tool available

Jamo Luhrsen <jluhrsen@...>
 

Flavio,

this looks like it could be very useful for CI.  Thanks for the work :)


Is there anyone in OVSDB land doing tests that could make use of this?  If
so, I'm wondering if a better place to keep this is in the integration repo
under test/tools/  ?


JamO




On 07/15/2015 01:42 PM, Flavio Fernandes wrote:
Hi folks,

After getting cross eyed from staring at postman outputs [1] to debug ovsdb net-virt, I decided to write
a tool to dump mdsal info related to ovsdb and its netvirt (including high level flows). I placed this tool
in the ‘resources’ dir in the ovsdb project [2]. Gerrit is here [3].

With that, we can narrow into that is available in either config or operational trees. Usage is below [5].
See [4] for an example output.

Hope this is useful to folks playing with ovsdb netvirt.

Best,

— flavio





[5]:

    Add showOvsdbMdsal.py tool

    This tool can provide useful info in regards to ovsdb's mdsal structures.
    It looks at the operational or config trees in mdsal, depending on the
    parameter '--config':

    $ ./showOvsdbMdsal.py -h
    Usage: showOvsdbMdsal.py [options]

    Options:
      --version             show program's version number and exit
      -h, --help            show this help message and exit
      -d, --debug           Verbosity. Can be provided multiple times for more
                            debug.
      -n, --noalias         Do not map nodeId of bridges to an alias
      -i ODLIP, --ip=ODLIP  opendaylights ip address
      -t ODLPORT, --port=ODLPORT
                            opendaylights listening tcp port on restconf
                            northbound
      -u ODLUSERNAME, --user=ODLUSERNAME
                            opendaylight restconf username
      -p ODLPASSWORD, --password=ODLPASSWORD
                            opendaylight restconf password
      -c, --config          parse mdsal restconf config tree instead of
                            operational tree
      -f, --hide-flows      hide flows





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


Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

Yang, Yi Y <yi.y.yang@...>
 

Soory I can’t, because it is 0:00 am next day for me

 

From: Abhijit Kumbhare [mailto:abhijitkoss@...]
Sent: Monday, July 20, 2015 3:09 PM
To: Yang, Yi Y
Cc: Prem sankar G; Hema Gopalkrishnan; Hariharan_Sethuraman@...; lacp-dev@...; sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

We can start some discussions around this in today (Monday) 9 am Pacific OpenFlow plugin meeting - which you should be able to attend remotely. Of course we have other topics to cover regarding Beryllium & Helium SR 4.

 

On Sun, Jul 19, 2015 at 11:59 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Ok, thanks, I can’t attend that in person, but we will have some representatives to attend.

 

From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Monday, July 20, 2015 2:42 PM
To: Yang, Yi Y; Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: RE: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi, Abhijit,

  I have created a placeholder for this topic during ODL design discussion summit -

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution

  We can use this slot for further brainstorming around this topic.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Sunday, July 19, 2015 8:45 PM
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N


Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Hema, good point, we need to fix the conflict before a flow is written to MDSAL data store, but this won’t impact we add this middle layer into openflowplugin, the reason to put it to openflowplugin is openflowplugin is a good hosting place for such middle layer. You can consider it is a component of openflowplugin, all the projects will call APIs from this component to program openflow tables and flows.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

I feel that the openflow plugin may not the place to detect the flow / table conflict. When the flow / table request reaches the openflow plugin, the NSFs / application would have already configured the flows and tables in the Config datastore of md-sal. So, taking any corrective action may be difficult.

 

We had proposed that conflict detection to be done even before the NSFs /application write to the config datastore. Any thoughts ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

I’m very glad to hear many guys have realized this issue, Prem Sankar created this wiki page https://wiki.opendaylight.org/view/OF_pipeline, this is a start point, please add other projects which used openflowplugin so that we can know how urgent this issue is. As Abhijit Kumbhare (openflowplugin project lead) commented, I think openflowplugin is the best place to implement this, I strongly suggest Abhijit Kumbhare can help make this become reality as early as possible, I want to work on it, but I need to hear your ideas if you have better ideas.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Hi Yi / Abhijit,

 

   We had proposed an idea in the ODL India forum on similar lines of Flow Conflict Prevention. Here is the link to the presentation.

 

We are interested in any discussion on this topic.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

This is a good topic - and OpenFlow plugin will likely be a good place for this. Are you planning to work on this? Why don't you join the next OpenFlow plugin meeting (at least for part of the meeting) to discuss more?

 

As you mention probably some kind of a flow conflict detection and resolution module is needed.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

Maybe some of you know several projects in ODL have implemented their own openflow writers for programming openflow rules, the end part of the mail are some info I collected. My question is how they work together if we install all of them? Every writer will create table 0, can it work normally? How can we fix it if not? The most important issue is they are duplicating efforts, what if we can provide a good middle layer in openflowplugin or in a separate project in order that all the operations are synchronized and coordinated? I kick off this discussion here is to let all the developers discuss it in open mind.

 

I think we can consolidate these unnecessary duplicate efforts into a separate project or part of openflowplugin, it is very necessary to provide only one entry to program openflow tables and rules, these operations must be efficiently synchronized and managed and coordinated, the direct benefits are as below:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

Table 0: Port Security, Ingress

Table 1: Ingress NAT Mapper

Table 2: Source Mapper

Table 3: Destination Mapper

Table 4: Policy Enforcer

Table 5: Egress NAT Mapper

Table 6: External Mapper

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

Table 0: Classifier

Table 10: Director

Table 20: Distributed ARP Responder

Table 30: DNAT for inbound floating-ip traffic

Table 40: Egress Acces-control

Table 50: Distributed LBaaS

Table 60: Distributed Virtual Routing (DVR)

Table 70: Layer 3 forwarding/lookup service

Table 80: Layer2 rewrite service

Table 90: Ingress Acces-control

Table 100: SNAT for traffic accessing external network

Table 110: Layer2 mac,vlan based forwarding


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

 

 


Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

Abhijit Kumbhare
 

We can start some discussions around this in today (Monday) 9 am Pacific OpenFlow plugin meeting - which you should be able to attend remotely. Of course we have other topics to cover regarding Beryllium & Helium SR 4.

On Sun, Jul 19, 2015 at 11:59 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Ok, thanks, I can’t attend that in person, but we will have some representatives to attend.

 

From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Monday, July 20, 2015 2:42 PM
To: Yang, Yi Y; Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: RE: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi, Abhijit,

  I have created a placeholder for this topic during ODL design discussion summit -

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution

  We can use this slot for further brainstorming around this topic.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Sunday, July 19, 2015 8:45 PM
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N


Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Hema, good point, we need to fix the conflict before a flow is written to MDSAL data store, but this won’t impact we add this middle layer into openflowplugin, the reason to put it to openflowplugin is openflowplugin is a good hosting place for such middle layer. You can consider it is a component of openflowplugin, all the projects will call APIs from this component to program openflow tables and flows.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

I feel that the openflow plugin may not the place to detect the flow / table conflict. When the flow / table request reaches the openflow plugin, the NSFs / application would have already configured the flows and tables in the Config datastore of md-sal. So, taking any corrective action may be difficult.

 

We had proposed that conflict detection to be done even before the NSFs /application write to the config datastore. Any thoughts ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

I’m very glad to hear many guys have realized this issue, Prem Sankar created this wiki page https://wiki.opendaylight.org/view/OF_pipeline, this is a start point, please add other projects which used openflowplugin so that we can know how urgent this issue is. As Abhijit Kumbhare (openflowplugin project lead) commented, I think openflowplugin is the best place to implement this, I strongly suggest Abhijit Kumbhare can help make this become reality as early as possible, I want to work on it, but I need to hear your ideas if you have better ideas.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Hi Yi / Abhijit,

 

   We had proposed an idea in the ODL India forum on similar lines of Flow Conflict Prevention. Here is the link to the presentation.

 

We are interested in any discussion on this topic.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

This is a good topic - and OpenFlow plugin will likely be a good place for this. Are you planning to work on this? Why don't you join the next OpenFlow plugin meeting (at least for part of the meeting) to discuss more?

 

As you mention probably some kind of a flow conflict detection and resolution module is needed.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

Maybe some of you know several projects in ODL have implemented their own openflow writers for programming openflow rules, the end part of the mail are some info I collected. My question is how they work together if we install all of them? Every writer will create table 0, can it work normally? How can we fix it if not? The most important issue is they are duplicating efforts, what if we can provide a good middle layer in openflowplugin or in a separate project in order that all the operations are synchronized and coordinated? I kick off this discussion here is to let all the developers discuss it in open mind.

 

I think we can consolidate these unnecessary duplicate efforts into a separate project or part of openflowplugin, it is very necessary to provide only one entry to program openflow tables and rules, these operations must be efficiently synchronized and managed and coordinated, the direct benefits are as below:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

Table 0: Port Security, Ingress

Table 1: Ingress NAT Mapper

Table 2: Source Mapper

Table 3: Destination Mapper

Table 4: Policy Enforcer

Table 5: Egress NAT Mapper

Table 6: External Mapper

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

Table 0: Classifier

Table 10: Director

Table 20: Distributed ARP Responder

Table 30: DNAT for inbound floating-ip traffic

Table 40: Egress Acces-control

Table 50: Distributed LBaaS

Table 60: Distributed Virtual Routing (DVR)

Table 70: Layer 3 forwarding/lookup service

Table 80: Layer2 rewrite service

Table 90: Ingress Acces-control

Table 100: SNAT for traffic accessing external network

Table 110: Layer2 mac,vlan based forwarding


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

 



Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

Yang, Yi Y <yi.y.yang@...>
 

Ok, thanks, I can’t attend that in person, but we will have some representatives to attend.

 

From: Prem sankar G [mailto:prem.sankar.g@...]
Sent: Monday, July 20, 2015 2:42 PM
To: Yang, Yi Y; Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: RE: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi, Abhijit,

  I have created a placeholder for this topic during ODL design discussion summit -

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution

  We can use this slot for further brainstorming around this topic.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Sunday, July 19, 2015 8:45 PM
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Hema, good point, we need to fix the conflict before a flow is written to MDSAL data store, but this won’t impact we add this middle layer into openflowplugin, the reason to put it to openflowplugin is openflowplugin is a good hosting place for such middle layer. You can consider it is a component of openflowplugin, all the projects will call APIs from this component to program openflow tables and flows.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

I feel that the openflow plugin may not the place to detect the flow / table conflict. When the flow / table request reaches the openflow plugin, the NSFs / application would have already configured the flows and tables in the Config datastore of md-sal. So, taking any corrective action may be difficult.

 

We had proposed that conflict detection to be done even before the NSFs /application write to the config datastore. Any thoughts ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

I’m very glad to hear many guys have realized this issue, Prem Sankar created this wiki page https://wiki.opendaylight.org/view/OF_pipeline, this is a start point, please add other projects which used openflowplugin so that we can know how urgent this issue is. As Abhijit Kumbhare (openflowplugin project lead) commented, I think openflowplugin is the best place to implement this, I strongly suggest Abhijit Kumbhare can help make this become reality as early as possible, I want to work on it, but I need to hear your ideas if you have better ideas.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Hi Yi / Abhijit,

 

   We had proposed an idea in the ODL India forum on similar lines of Flow Conflict Prevention. Here is the link to the presentation.

 

We are interested in any discussion on this topic.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

This is a good topic - and OpenFlow plugin will likely be a good place for this. Are you planning to work on this? Why don't you join the next OpenFlow plugin meeting (at least for part of the meeting) to discuss more?

 

As you mention probably some kind of a flow conflict detection and resolution module is needed.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

Maybe some of you know several projects in ODL have implemented their own openflow writers for programming openflow rules, the end part of the mail are some info I collected. My question is how they work together if we install all of them? Every writer will create table 0, can it work normally? How can we fix it if not? The most important issue is they are duplicating efforts, what if we can provide a good middle layer in openflowplugin or in a separate project in order that all the operations are synchronized and coordinated? I kick off this discussion here is to let all the developers discuss it in open mind.

 

I think we can consolidate these unnecessary duplicate efforts into a separate project or part of openflowplugin, it is very necessary to provide only one entry to program openflow tables and rules, these operations must be efficiently synchronized and managed and coordinated, the direct benefits are as below:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

Table 0: Port Security, Ingress

Table 1: Ingress NAT Mapper

Table 2: Source Mapper

Table 3: Destination Mapper

Table 4: Policy Enforcer

Table 5: Egress NAT Mapper

Table 6: External Mapper

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

Table 0: Classifier

Table 10: Director

Table 20: Distributed ARP Responder

Table 30: DNAT for inbound floating-ip traffic

Table 40: Egress Acces-control

Table 50: Distributed LBaaS

Table 60: Distributed Virtual Routing (DVR)

Table 70: Layer 3 forwarding/lookup service

Table 80: Layer2 rewrite service

Table 90: Ingress Acces-control

Table 100: SNAT for traffic accessing external network

Table 110: Layer2 mac,vlan based forwarding


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

 


Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

Prem sankar G <prem.sankar.g@...>
 

Yi, Abhijit,

  I have created a placeholder for this topic during ODL design discussion summit -

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum#OF_Pipeline_Conflict_resolution

  We can use this slot for further brainstorming around this topic.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Sunday, July 19, 2015 8:45 PM
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; Gaurav Bhagwani; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: Re: [groupbasedpolicy-dev] [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Hema, good point, we need to fix the conflict before a flow is written to MDSAL data store, but this won’t impact we add this middle layer into openflowplugin, the reason to put it to openflowplugin is openflowplugin is a good hosting place for such middle layer. You can consider it is a component of openflowplugin, all the projects will call APIs from this component to program openflow tables and flows.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

I feel that the openflow plugin may not the place to detect the flow / table conflict. When the flow / table request reaches the openflow plugin, the NSFs / application would have already configured the flows and tables in the Config datastore of md-sal. So, taking any corrective action may be difficult.

 

We had proposed that conflict detection to be done even before the NSFs /application write to the config datastore. Any thoughts ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

I’m very glad to hear many guys have realized this issue, Prem Sankar created this wiki page https://wiki.opendaylight.org/view/OF_pipeline, this is a start point, please add other projects which used openflowplugin so that we can know how urgent this issue is. As Abhijit Kumbhare (openflowplugin project lead) commented, I think openflowplugin is the best place to implement this, I strongly suggest Abhijit Kumbhare can help make this become reality as early as possible, I want to work on it, but I need to hear your ideas if you have better ideas.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Hi Yi / Abhijit,

 

   We had proposed an idea in the ODL India forum on similar lines of Flow Conflict Prevention. Here is the link to the presentation.

 

We are interested in any discussion on this topic.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

This is a good topic - and OpenFlow plugin will likely be a good place for this. Are you planning to work on this? Why don't you join the next OpenFlow plugin meeting (at least for part of the meeting) to discuss more?

 

As you mention probably some kind of a flow conflict detection and resolution module is needed.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

Maybe some of you know several projects in ODL have implemented their own openflow writers for programming openflow rules, the end part of the mail are some info I collected. My question is how they work together if we install all of them? Every writer will create table 0, can it work normally? How can we fix it if not? The most important issue is they are duplicating efforts, what if we can provide a good middle layer in openflowplugin or in a separate project in order that all the operations are synchronized and coordinated? I kick off this discussion here is to let all the developers discuss it in open mind.

 

I think we can consolidate these unnecessary duplicate efforts into a separate project or part of openflowplugin, it is very necessary to provide only one entry to program openflow tables and rules, these operations must be efficiently synchronized and managed and coordinated, the direct benefits are as below:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

Table 0: Port Security, Ingress

Table 1: Ingress NAT Mapper

Table 2: Source Mapper

Table 3: Destination Mapper

Table 4: Policy Enforcer

Table 5: Egress NAT Mapper

Table 6: External Mapper

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

Table 0: Classifier

Table 10: Director

Table 20: Distributed ARP Responder

Table 30: DNAT for inbound floating-ip traffic

Table 40: Egress Acces-control

Table 50: Distributed LBaaS

Table 60: Distributed Virtual Routing (DVR)

Table 70: Layer 3 forwarding/lookup service

Table 80: Layer2 rewrite service

Table 90: Ingress Acces-control

Table 100: SNAT for traffic accessing external network

Table 110: Layer2 mac,vlan based forwarding


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

 


Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

Yang, Yi Y <yi.y.yang@...>
 

Hema, good point, we need to fix the conflict before a flow is written to MDSAL data store, but this won’t impact we add this middle layer into openflowplugin, the reason to put it to openflowplugin is openflowplugin is a good hosting place for such middle layer. You can consider it is a component of openflowplugin, all the projects will call APIs from this component to program openflow tables and flows.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 7:00 PM
To: Yang, Yi Y; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

I feel that the openflow plugin may not the place to detect the flow / table conflict. When the flow / table request reaches the openflow plugin, the NSFs / application would have already configured the flows and tables in the Config datastore of md-sal. So, taking any corrective action may be difficult.

 

We had proposed that conflict detection to be done even before the NSFs /application write to the config datastore. Any thoughts ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

I’m very glad to hear many guys have realized this issue, Prem Sankar created this wiki page https://wiki.opendaylight.org/view/OF_pipeline, this is a start point, please add other projects which used openflowplugin so that we can know how urgent this issue is. As Abhijit Kumbhare (openflowplugin project lead) commented, I think openflowplugin is the best place to implement this, I strongly suggest Abhijit Kumbhare can help make this become reality as early as possible, I want to work on it, but I need to hear your ideas if you have better ideas.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Hi Yi / Abhijit,

 

   We had proposed an idea in the ODL India forum on similar lines of Flow Conflict Prevention. Here is the link to the presentation.

 

We are interested in any discussion on this topic.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

This is a good topic - and OpenFlow plugin will likely be a good place for this. Are you planning to work on this? Why don't you join the next OpenFlow plugin meeting (at least for part of the meeting) to discuss more?

 

As you mention probably some kind of a flow conflict detection and resolution module is needed.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

Maybe some of you know several projects in ODL have implemented their own openflow writers for programming openflow rules, the end part of the mail are some info I collected. My question is how they work together if we install all of them? Every writer will create table 0, can it work normally? How can we fix it if not? The most important issue is they are duplicating efforts, what if we can provide a good middle layer in openflowplugin or in a separate project in order that all the operations are synchronized and coordinated? I kick off this discussion here is to let all the developers discuss it in open mind.

 

I think we can consolidate these unnecessary duplicate efforts into a separate project or part of openflowplugin, it is very necessary to provide only one entry to program openflow tables and rules, these operations must be efficiently synchronized and managed and coordinated, the direct benefits are as below:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

Table 0: Port Security, Ingress

Table 1: Ingress NAT Mapper

Table 2: Source Mapper

Table 3: Destination Mapper

Table 4: Policy Enforcer

Table 5: Egress NAT Mapper

Table 6: External Mapper

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

Table 0: Classifier

Table 10: Director

Table 20: Distributed ARP Responder

Table 30: DNAT for inbound floating-ip traffic

Table 40: Egress Acces-control

Table 50: Distributed LBaaS

Table 60: Distributed Virtual Routing (DVR)

Table 70: Layer 3 forwarding/lookup service

Table 80: Layer2 rewrite service

Table 90: Ingress Acces-control

Table 100: SNAT for traffic accessing external network

Table 110: Layer2 mac,vlan based forwarding


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

 


Re: example of mapping ovs interfaces of tenant vm to neutron port, subnet, tenant id

Richard Woo <richardwoo2003@...>
 

Thanks, Flavio, I tried it. These tools are awesome! 

On Thu, Jul 16, 2015 at 10:45 PM, Flavio Fernandes <ffernand@...> wrote:
Hi folks,

I was asked for an example dump of an openstack config on ovsdb netvirt and how one can piece mail the ovs ports
to the overlay network that goes with it.

For that, I ‘devstacked' 3 nodes using my one trick pony github [1] repo. ;)

Then, I created 2 tenants with 2 internal subnets and put 2 vms in each with floating ips.

The output of operational tree using my handy tool [3] looked like this [4] ([5] with flows).

The output from neutron’s rest interface gave me this [6].

Pulling the string for a tenant port in openstack compute node 192.168.50.22 —as an example-- you can see that:

* lines 14, 15, 30, 31, 37 and 40 from [4] represent the tunnel ports that interconnect the openstack nodes

* line 42 from [4] is:  of:6   tapbd8efa88-36   mac:fa:16:3e:fb:d9:bf   ifaceId:bd8efa88-3665-409a-a7fa-47663a9089b2.
 So, the tenant vm that owns that port is in compute node 192.168.50.22. 

  br-int in that node is aka openflow:191757013640004 (charlie)

  If you search for ‘47663a9089b2’ in [6], you will find it belongs to neutron port that has address 10.20.0.3 and
  belongs to subnet id 8daa2590-67d9-45c1-b956-f820aa5dba43. That is on line 691 of [6].

  Furthermore you can see that it belongs to tenant 33d676feac934d98a809eadfd8e5e985, mentioned in line 702.
 
* with that, you can connect the dots and find all neutron ports that belong to a certain subnet / tenant, as well as the bridge
  and openstack nodes they are located.

These where the curl commands that dumped me the crud tables in neutron northbound [7]. I’m pretty sure that can be obtained
via mdsal’s restconf too, but I am not too familiar with that yet.

Hope this helps. :)

— flavio









===

$ ./showOvsdbMdsal.py -f
aliasMap:
alpha -> openflow:50647211443526
bravo -> openflow:8796758886516
charlie -> openflow:191757013640004
delta -> openflow:8796757453186
echo -> openflow:68498488746567
foxtrot -> openflow:8796764052230
 
ovsdbNode:192.168.50.20:47988 mgr:192.168.50.1:6640 version:2.3.2
alpha:br-int
of:1 tap165bbfcf-50 mac:fa:16:3e:43:d0:5f ifaceId:165bbfcf-50ec-4e33-b978-5e2310097403
of:2 patch-ext
of:3 vxlan-192.168.50.21
of:4 vxlan-192.168.50.22
of:5 tap207df591-ca mac:fa:16:3e:97:c3:a5 ifaceId:207df591-ca7f-4da3-b156-5af408b14ac7
of:6 tapce6a55b8-6f mac:fa:16:3e:bd:aa:21 ifaceId:ce6a55b8-6f6b-419a-814c-7075f22d0fe3
of:7 tap79cb76bd-d9 mac:fa:16:3e:b3:52:57 ifaceId:79cb76bd-d959-44bf-b203-1af6f55def8d
of:8 tap412bb62b-48 mac:fa:16:3e:8a:5c:3b ifaceId:412bb62b-48ba-454e-b370-207fd550f12b
of:9 tap5f960323-fc mac:fa:16:3e:b8:26:17 ifaceId:5f960323-fcaa-4b6a-aea7-f25c579fa909
of:10 tape713da3b-5e mac:fa:16:3e:83:11:af ifaceId:e713da3b-5e04-4496-b5a4-14aa8ebcd5f9
bravo:br-ex
of:1 eth2
of:2 patch-int
ovsdbNode:192.168.50.21:51445 mgr:192.168.50.1:6640 version:2.3.2
delta:br-ex
of:1 eth2
of:2 patch-int
echo:br-int
of:1 vxlan-192.168.50.20
of:2 vxlan-192.168.50.22
of:3 tap055b988d-4e mac:fa:16:3e:50:48:1c ifaceId:055b988d-4e4c-48f9-a479-50b725c10655
of:4 patch-ext
of:5 tap70290b63-bc mac:fa:16:3e:18:1c:64 ifaceId:70290b63-bc50-4191-bf00-55f1b9794ef8
ovsdbNode:192.168.50.22:52843 mgr:192.168.50.1:6640 version:2.3.2
charlie:br-int
of:1 vxlan-192.168.50.20
of:2 tapbce1a32b-3b mac:fa:16:3e:92:06:83 ifaceId:bce1a32b-3b4b-4ba1-a05b-b157989abccb
of:3 patch-ext
of:4 vxlan-192.168.50.21
of:5 tap2c38c301-52 mac:fa:16:3e:2c:6b:e0 ifaceId:2c38c301-526a-49b0-b4d6-5c74cb7e5c22
of:6 tapbd8efa88-36 mac:fa:16:3e:fb:d9:bf ifaceId:bd8efa88-3665-409a-a7fa-47663a9089b2
foxtrot:br-ex
of:1 eth2
of:2 patch-int
 
ofLinks (discover via lldp):
charlie:1 <-> alpha:4
charlie:3 <-> foxtrot:2
charlie:4 <-> echo:2
alpha:2 <-> bravo:2
alpha:3 <-> echo:1
echo:4 <-> delta:2
delta:1 -> bravo:1
bravo:1 <-> foxtrot:1




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



example of mapping ovs interfaces of tenant vm to neutron port, subnet, tenant id

Flavio Fernandes <ffernand@...>
 

Hi folks,

I was asked for an example dump of an openstack config on ovsdb netvirt and how one can piece mail the ovs ports
to the overlay network that goes with it.

For that, I ‘devstacked' 3 nodes using my one trick pony github [1] repo. ;)

Then, I created 2 tenants with 2 internal subnets and put 2 vms in each with floating ips.

The output of operational tree using my handy tool [3] looked like this [4] ([5] with flows).

The output from neutron’s rest interface gave me this [6].

Pulling the string for a tenant port in openstack compute node 192.168.50.22 —as an example-- you can see that:

* lines 14, 15, 30, 31, 37 and 40 from [4] represent the tunnel ports that interconnect the openstack nodes

* line 42 from [4] is:  of:6   tapbd8efa88-36   mac:fa:16:3e:fb:d9:bf   ifaceId:bd8efa88-3665-409a-a7fa-47663a9089b2.
 So, the tenant vm that owns that port is in compute node 192.168.50.22. 

  br-int in that node is aka openflow:191757013640004 (charlie)

  If you search for ‘47663a9089b2’ in [6], you will find it belongs to neutron port that has address 10.20.0.3 and
  belongs to subnet id 8daa2590-67d9-45c1-b956-f820aa5dba43. That is on line 691 of [6].

  Furthermore you can see that it belongs to tenant 33d676feac934d98a809eadfd8e5e985, mentioned in line 702.
 
* with that, you can connect the dots and find all neutron ports that belong to a certain subnet / tenant, as well as the bridge
  and openstack nodes they are located.

These where the curl commands that dumped me the crud tables in neutron northbound [7]. I’m pretty sure that can be obtained
via mdsal’s restconf too, but I am not too familiar with that yet.

Hope this helps. :)

— flavio









===

$ ./showOvsdbMdsal.py -f
aliasMap:
alpha -> openflow:50647211443526
bravo -> openflow:8796758886516
charlie -> openflow:191757013640004
delta -> openflow:8796757453186
echo -> openflow:68498488746567
foxtrot -> openflow:8796764052230
 
ovsdbNode:192.168.50.20:47988 mgr:192.168.50.1:6640 version:2.3.2
alpha:br-int
of:1 tap165bbfcf-50 mac:fa:16:3e:43:d0:5f ifaceId:165bbfcf-50ec-4e33-b978-5e2310097403
of:2 patch-ext
of:3 vxlan-192.168.50.21
of:4 vxlan-192.168.50.22
of:5 tap207df591-ca mac:fa:16:3e:97:c3:a5 ifaceId:207df591-ca7f-4da3-b156-5af408b14ac7
of:6 tapce6a55b8-6f mac:fa:16:3e:bd:aa:21 ifaceId:ce6a55b8-6f6b-419a-814c-7075f22d0fe3
of:7 tap79cb76bd-d9 mac:fa:16:3e:b3:52:57 ifaceId:79cb76bd-d959-44bf-b203-1af6f55def8d
of:8 tap412bb62b-48 mac:fa:16:3e:8a:5c:3b ifaceId:412bb62b-48ba-454e-b370-207fd550f12b
of:9 tap5f960323-fc mac:fa:16:3e:b8:26:17 ifaceId:5f960323-fcaa-4b6a-aea7-f25c579fa909
of:10 tape713da3b-5e mac:fa:16:3e:83:11:af ifaceId:e713da3b-5e04-4496-b5a4-14aa8ebcd5f9
bravo:br-ex
of:1 eth2
of:2 patch-int
ovsdbNode:192.168.50.21:51445 mgr:192.168.50.1:6640 version:2.3.2
delta:br-ex
of:1 eth2
of:2 patch-int
echo:br-int
of:1 vxlan-192.168.50.20
of:2 vxlan-192.168.50.22
of:3 tap055b988d-4e mac:fa:16:3e:50:48:1c ifaceId:055b988d-4e4c-48f9-a479-50b725c10655
of:4 patch-ext
of:5 tap70290b63-bc mac:fa:16:3e:18:1c:64 ifaceId:70290b63-bc50-4191-bf00-55f1b9794ef8
ovsdbNode:192.168.50.22:52843 mgr:192.168.50.1:6640 version:2.3.2
charlie:br-int
of:1 vxlan-192.168.50.20
of:2 tapbce1a32b-3b mac:fa:16:3e:92:06:83 ifaceId:bce1a32b-3b4b-4ba1-a05b-b157989abccb
of:3 patch-ext
of:4 vxlan-192.168.50.21
of:5 tap2c38c301-52 mac:fa:16:3e:2c:6b:e0 ifaceId:2c38c301-526a-49b0-b4d6-5c74cb7e5c22
of:6 tapbd8efa88-36 mac:fa:16:3e:fb:d9:bf ifaceId:bd8efa88-3665-409a-a7fa-47663a9089b2
foxtrot:br-ex
of:1 eth2
of:2 patch-int
 
ofLinks (discover via lldp):
charlie:1 <-> alpha:4
charlie:3 <-> foxtrot:2
charlie:4 <-> echo:2
alpha:2 <-> bravo:2
alpha:3 <-> echo:1
echo:4 <-> delta:2
delta:1 -> bravo:1
bravo:1 <-> foxtrot:1




Re: openstack neutron ovsdb port creation

Sam Hague
 

----- Original Message -----
From: "Baudinot Denis Gerold (badi)" <badi@...>
To: "Sam Hague" <shague@...>
Cc: ovsdb-dev@...
Sent: Thursday, July 16, 2015 10:46:18 AM
Subject: AW: [ovsdb-dev] openstack neutron ovsdb port creation

Hi again

I'am trying to understand the relation you mentioned here:

6. odl ovsdb will relate the neutron events to the ovsdb events and build
tunnels and push flows as needed.
I can't figure this out in the case of a neutron port creation. The neutron
port creation gets passed to the PortHandler.

But the NetworkingProvider which is responsible for pushing l2 forwarding
flows onto the bridge is neither notified by a southbound event nor the
mentioned neutron event. The southbound event ADD for port creation is
empty. Only UPDATE seems to pass on the creation to the NetworkingProvider.
Where can I see the relation between the southbound port creation and
neutron port creation?

What confuses me on the side is the fact that the southbound events require
to retrieve a NeutronNetwork from the neutron cache. What happens if the
neutron event happens after the southbound event?
The SouthboundHandler is where the ovs port updates come in. Both the add and update are mapped to a processPortUpdate() since we want to do the same thing for both events. As you saw int he code the PortHandler really doesn't do much. That code is really just there so that the neutron northbound will not reply negatively to neutron rest calls - something is required int he backend to satisfy the request.

So when the ovs port is updated we can then go to program the flows in the handleinterfaceUpdate() method. I don't recall everything that comes in for the port add and update but we can't do anything until the external_ids column is filled with the neutron port iface-id so that we know how to program the flows for the requested network. That is the link between the neutron port and the ovs port.

It always works out that eventually the neutron port stuff comes in followed by a ovs port update. Sometimes there are ovs port add/updates before the neutron port comes in, but in all cases there is a subsequent ovs port update. So eventually you get an ovs update and the neutron cache is there for use.


Thank you *very* much again

Denis
________________________________________
Von: Sam Hague [shague@...]
Gesendet: Donnerstag, 9. Juli 2015 14:45
An: Baudinot Denis Gerold (badi)
Cc: ovsdb-dev@...
Betreff: Re: [ovsdb-dev] openstack neutron ovsdb port creation

----- Original Message -----
From: "Baudinot Denis Gerold (badi)" <badi@...>
To: ovsdb-dev@...
Sent: Thursday, July 9, 2015 5:04:23 AM
Subject: [ovsdb-dev] openstack neutron ovsdb port creation

Hi,

I have read through ovsdb / openstack (helium), but I have issues
identifiying the actual ovs port creation.

Following from PortHandler.neutronPortCreated the only output I found is
flow
programming related. But what I want to see is where ovs ports are created
through ovsdb.

To be more specific I would like to see the part where the ovs ports and
ovs
interfaces are created by ovsdb, which are attached to tap devices to
enable
connectivity to VM instances in an openstack environment.
Baudinot,

the ovsdb project will only add patch and tunnel ports as needed. The VM
ports are added via the libvirt agent on the openstack compute nodes. The
flow is like this:

Network creation:
1. User creates a network via openstack
2. neutron agents add ports to bridges for routers and dhcp namespaces -
these are the tap ports you mention above
3. neutron and ovsdb port updates go to odl
4. neutron events passed to odl ovsdb project - not much happens here
5. ovsdb port events go directly to the odl ovsdb
6. odl ovsdb will relate the neutron events to the ovsdb events and build
tunnels and push flows as needed.

VM Creation:
1. User creates VM's via openstack
2. nova calls libvirt to create VM
3. libvirt calls will allocate VM ports and add them to the br-int - these
are the tap ports you mention above
4. Same as 3-6 above.


I assume that the opendaylight.neutron bundle itself is only responsible
for
the northbound API to the neutron ml2 plugin and opendaylight.ovsdb does
all
the work regarding to ovs.
yes, odl.neutron receives the incoming neutron rest APIs. And then
effectively passes them through to odl.ovsdb to do the work.

Thank you

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


Re: openstack neutron ovsdb port creation

Baudinot Denis Gerold (badi) <badi@...>
 

Hi again

I'am trying to understand the relation you mentioned here:

6. odl ovsdb will relate the neutron events to the ovsdb events and build tunnels and push flows as needed.
I can't figure this out in the case of a neutron port creation. The neutron port creation gets passed to the PortHandler.

But the NetworkingProvider which is responsible for pushing l2 forwarding flows onto the bridge is neither notified by a southbound event nor the mentioned neutron event. The southbound event ADD for port creation is empty. Only UPDATE seems to pass on the creation to the NetworkingProvider. Where can I see the relation between the southbound port creation and neutron port creation?

What confuses me on the side is the fact that the southbound events require to retrieve a NeutronNetwork from the neutron cache. What happens if the neutron event happens after the southbound event?

Thank you *very* much again

Denis
________________________________________
Von: Sam Hague [shague@...]
Gesendet: Donnerstag, 9. Juli 2015 14:45
An: Baudinot Denis Gerold (badi)
Cc: ovsdb-dev@...
Betreff: Re: [ovsdb-dev] openstack neutron ovsdb port creation

----- Original Message -----
From: "Baudinot Denis Gerold (badi)" <badi@...>
To: ovsdb-dev@...
Sent: Thursday, July 9, 2015 5:04:23 AM
Subject: [ovsdb-dev] openstack neutron ovsdb port creation

Hi,

I have read through ovsdb / openstack (helium), but I have issues
identifiying the actual ovs port creation.

Following from PortHandler.neutronPortCreated the only output I found is flow
programming related. But what I want to see is where ovs ports are created
through ovsdb.

To be more specific I would like to see the part where the ovs ports and ovs
interfaces are created by ovsdb, which are attached to tap devices to enable
connectivity to VM instances in an openstack environment.
Baudinot,

the ovsdb project will only add patch and tunnel ports as needed. The VM ports are added via the libvirt agent on the openstack compute nodes. The flow is like this:

Network creation:
1. User creates a network via openstack
2. neutron agents add ports to bridges for routers and dhcp namespaces - these are the tap ports you mention above
3. neutron and ovsdb port updates go to odl
4. neutron events passed to odl ovsdb project - not much happens here
5. ovsdb port events go directly to the odl ovsdb
6. odl ovsdb will relate the neutron events to the ovsdb events and build tunnels and push flows as needed.

VM Creation:
1. User creates VM's via openstack
2. nova calls libvirt to create VM
3. libvirt calls will allocate VM ports and add them to the br-int - these are the tap ports you mention above
4. Same as 3-6 above.


I assume that the opendaylight.neutron bundle itself is only responsible for
the northbound API to the neutron ml2 plugin and opendaylight.ovsdb does all
the work regarding to ovs.
yes, odl.neutron receives the incoming neutron rest APIs. And then effectively passes them through to odl.ovsdb to do the work.

Thank you

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


Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

Hema Gopalkrishnan <hema.gopalkrishnan@...>
 

I feel that the openflow plugin may not the place to detect the flow / table conflict. When the flow / table request reaches the openflow plugin, the NSFs / application would have already configured the flows and tables in the Config datastore of md-sal. So, taking any corrective action may be difficult.

 

We had proposed that conflict detection to be done even before the NSFs /application write to the config datastore. Any thoughts ?

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

I’m very glad to hear many guys have realized this issue, Prem Sankar created this wiki page https://wiki.opendaylight.org/view/OF_pipeline, this is a start point, please add other projects which used openflowplugin so that we can know how urgent this issue is. As Abhijit Kumbhare (openflowplugin project lead) commented, I think openflowplugin is the best place to implement this, I strongly suggest Abhijit Kumbhare can help make this become reality as early as possible, I want to work on it, but I need to hear your ideas if you have better ideas.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Hi Yi / Abhijit,

 

   We had proposed an idea in the ODL India forum on similar lines of Flow Conflict Prevention. Here is the link to the presentation.

 

We are interested in any discussion on this topic.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

This is a good topic - and OpenFlow plugin will likely be a good place for this. Are you planning to work on this? Why don't you join the next OpenFlow plugin meeting (at least for part of the meeting) to discuss more?

 

As you mention probably some kind of a flow conflict detection and resolution module is needed.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

Maybe some of you know several projects in ODL have implemented their own openflow writers for programming openflow rules, the end part of the mail are some info I collected. My question is how they work together if we install all of them? Every writer will create table 0, can it work normally? How can we fix it if not? The most important issue is they are duplicating efforts, what if we can provide a good middle layer in openflowplugin or in a separate project in order that all the operations are synchronized and coordinated? I kick off this discussion here is to let all the developers discuss it in open mind.

 

I think we can consolidate these unnecessary duplicate efforts into a separate project or part of openflowplugin, it is very necessary to provide only one entry to program openflow tables and rules, these operations must be efficiently synchronized and managed and coordinated, the direct benefits are as below:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

Table 0: Port Security, Ingress

Table 1: Ingress NAT Mapper

Table 2: Source Mapper

Table 3: Destination Mapper

Table 4: Policy Enforcer

Table 5: Egress NAT Mapper

Table 6: External Mapper

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

Table 0: Classifier

Table 10: Director

Table 20: Distributed ARP Responder

Table 30: DNAT for inbound floating-ip traffic

Table 40: Egress Acces-control

Table 50: Distributed LBaaS

Table 60: Distributed Virtual Routing (DVR)

Table 70: Layer 3 forwarding/lookup service

Table 80: Layer2 rewrite service

Table 90: Ingress Acces-control

Table 100: SNAT for traffic accessing external network

Table 110: Layer2 mac,vlan based forwarding


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

 


Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

Vishal Thapar <vishal.thapar@...>
 

This sounds like a good candidate for Beryllium Developer Forum at the Summit.

 

https://wiki.opendaylight.org/view/Events:Be_Dev_Forum

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: 16 July 2015 14:51
To: Hema Gopalkrishnan; Hariharan_Sethuraman@...; abhijitkoss@...; lacp-dev@...
Cc: sfc-dev@...; C_Venkataraghavan@...; openflowplugin-dev@...; Manohar SL; ovsdb-dev@...; groupbasedpolicy-dev@...; Prakash N N
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

I’m very glad to hear many guys have realized this issue, Prem Sankar created this wiki page https://wiki.opendaylight.org/view/OF_pipeline, this is a start point, please add other projects which used openflowplugin so that we can know how urgent this issue is. As Abhijit Kumbhare (openflowplugin project lead) commented, I think openflowplugin is the best place to implement this, I strongly suggest Abhijit Kumbhare can help make this become reality as early as possible, I want to work on it, but I need to hear your ideas if you have better ideas.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Hi Yi / Abhijit,

 

   We had proposed an idea in the ODL India forum on similar lines of Flow Conflict Prevention. Here is the link to the presentation.

 

We are interested in any discussion on this topic.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

This is a good topic - and OpenFlow plugin will likely be a good place for this. Are you planning to work on this? Why don't you join the next OpenFlow plugin meeting (at least for part of the meeting) to discuss more?

 

As you mention probably some kind of a flow conflict detection and resolution module is needed.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

Maybe some of you know several projects in ODL have implemented their own openflow writers for programming openflow rules, the end part of the mail are some info I collected. My question is how they work together if we install all of them? Every writer will create table 0, can it work normally? How can we fix it if not? The most important issue is they are duplicating efforts, what if we can provide a good middle layer in openflowplugin or in a separate project in order that all the operations are synchronized and coordinated? I kick off this discussion here is to let all the developers discuss it in open mind.

 

I think we can consolidate these unnecessary duplicate efforts into a separate project or part of openflowplugin, it is very necessary to provide only one entry to program openflow tables and rules, these operations must be efficiently synchronized and managed and coordinated, the direct benefits are as below:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

Table 0: Port Security, Ingress

Table 1: Ingress NAT Mapper

Table 2: Source Mapper

Table 3: Destination Mapper

Table 4: Policy Enforcer

Table 5: Egress NAT Mapper

Table 6: External Mapper

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

Table 0: Classifier

Table 10: Director

Table 20: Distributed ARP Responder

Table 30: DNAT for inbound floating-ip traffic

Table 40: Egress Acces-control

Table 50: Distributed LBaaS

Table 60: Distributed Virtual Routing (DVR)

Table 70: Layer 3 forwarding/lookup service

Table 80: Layer2 rewrite service

Table 90: Ingress Acces-control

Table 100: SNAT for traffic accessing external network

Table 110: Layer2 mac,vlan based forwarding


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

 


Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

Yang, Yi Y <yi.y.yang@...>
 

I’m very glad to hear many guys have realized this issue, Prem Sankar created this wiki page https://wiki.opendaylight.org/view/OF_pipeline, this is a start point, please add other projects which used openflowplugin so that we can know how urgent this issue is. As Abhijit Kumbhare (openflowplugin project lead) commented, I think openflowplugin is the best place to implement this, I strongly suggest Abhijit Kumbhare can help make this become reality as early as possible, I want to work on it, but I need to hear your ideas if you have better ideas.

 

From: Hema Gopalkrishnan [mailto:hema.gopalkrishnan@...]
Sent: Thursday, July 16, 2015 4:51 PM
To: Hariharan_Sethuraman@...; abhijitkoss@...; Yang, Yi Y; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...; Gaurav Bhagwani; Manohar SL; Prakash N N
Subject: RE: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Hi Yi / Abhijit,

 

   We had proposed an idea in the ODL India forum on similar lines of Flow Conflict Prevention. Here is the link to the presentation.

 

We are interested in any discussion on this topic.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To:
abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc:
C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc:
ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

This is a good topic - and OpenFlow plugin will likely be a good place for this. Are you planning to work on this? Why don't you join the next OpenFlow plugin meeting (at least for part of the meeting) to discuss more?

 

As you mention probably some kind of a flow conflict detection and resolution module is needed.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

Maybe some of you know several projects in ODL have implemented their own openflow writers for programming openflow rules, the end part of the mail are some info I collected. My question is how they work together if we install all of them? Every writer will create table 0, can it work normally? How can we fix it if not? The most important issue is they are duplicating efforts, what if we can provide a good middle layer in openflowplugin or in a separate project in order that all the operations are synchronized and coordinated? I kick off this discussion here is to let all the developers discuss it in open mind.

 

I think we can consolidate these unnecessary duplicate efforts into a separate project or part of openflowplugin, it is very necessary to provide only one entry to program openflow tables and rules, these operations must be efficiently synchronized and managed and coordinated, the direct benefits are as below:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

Table 0: Port Security, Ingress

Table 1: Ingress NAT Mapper

Table 2: Source Mapper

Table 3: Destination Mapper

Table 4: Policy Enforcer

Table 5: Egress NAT Mapper

Table 6: External Mapper

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

Table 0: Classifier

Table 10: Director

Table 20: Distributed ARP Responder

Table 30: DNAT for inbound floating-ip traffic

Table 40: Egress Acces-control

Table 50: Distributed LBaaS

Table 60: Distributed Virtual Routing (DVR)

Table 70: Layer 3 forwarding/lookup service

Table 80: Layer2 rewrite service

Table 90: Ingress Acces-control

Table 100: SNAT for traffic accessing external network

Table 110: Layer2 mac,vlan based forwarding


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

 


Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

Hema Gopalkrishnan <hema.gopalkrishnan@...>
 

Hi Yi / Abhijit,

 

   We had proposed an idea in the ODL India forum on similar lines of Flow Conflict Prevention. Here is the link to the presentation.

 

We are interested in any discussion on this topic.

 

Regards,

Hema.

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Hariharan_Sethuraman@...
Sent: 16 July 2015 11:47
To: abhijitkoss@...; yi.y.yang@...; lacp-dev@...
Cc: C_Venkataraghavan@...; ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc: ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

This is a good topic - and OpenFlow plugin will likely be a good place for this. Are you planning to work on this? Why don't you join the next OpenFlow plugin meeting (at least for part of the meeting) to discuss more?

 

As you mention probably some kind of a flow conflict detection and resolution module is needed.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

Maybe some of you know several projects in ODL have implemented their own openflow writers for programming openflow rules, the end part of the mail are some info I collected. My question is how they work together if we install all of them? Every writer will create table 0, can it work normally? How can we fix it if not? The most important issue is they are duplicating efforts, what if we can provide a good middle layer in openflowplugin or in a separate project in order that all the operations are synchronized and coordinated? I kick off this discussion here is to let all the developers discuss it in open mind.

 

I think we can consolidate these unnecessary duplicate efforts into a separate project or part of openflowplugin, it is very necessary to provide only one entry to program openflow tables and rules, these operations must be efficiently synchronized and managed and coordinated, the direct benefits are as below:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

Table 0: Port Security, Ingress

Table 1: Ingress NAT Mapper

Table 2: Source Mapper

Table 3: Destination Mapper

Table 4: Policy Enforcer

Table 5: Egress NAT Mapper

Table 6: External Mapper

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

Table 0: Classifier

Table 10: Director

Table 20: Distributed ARP Responder

Table 30: DNAT for inbound floating-ip traffic

Table 40: Egress Acces-control

Table 50: Distributed LBaaS

Table 60: Distributed Virtual Routing (DVR)

Table 70: Layer 3 forwarding/lookup service

Table 80: Layer2 rewrite service

Table 90: Ingress Acces-control

Table 100: SNAT for traffic accessing external network

Table 110: Layer2 mac,vlan based forwarding


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

 


Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

Hariharan_Sethuraman@...
 

+ lacp-dev

 

From: openflowplugin-dev-bounces@... [mailto:openflowplugin-dev-bounces@...] On Behalf Of Abhijit Kumbhare
Sent: Wednesday, July 15, 2015 8:03 PM
To: Yang, Yi Y
Cc: ovsdb-dev@...; groupbasedpolicy-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

 

Yi,

 

This is a good topic - and OpenFlow plugin will likely be a good place for this. Are you planning to work on this? Why don't you join the next OpenFlow plugin meeting (at least for part of the meeting) to discuss more?

 

As you mention probably some kind of a flow conflict detection and resolution module is needed.

 

Thanks,

Abhijit

 

 

On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

Maybe some of you know several projects in ODL have implemented their own openflow writers for programming openflow rules, the end part of the mail are some info I collected. My question is how they work together if we install all of them? Every writer will create table 0, can it work normally? How can we fix it if not? The most important issue is they are duplicating efforts, what if we can provide a good middle layer in openflowplugin or in a separate project in order that all the operations are synchronized and coordinated? I kick off this discussion here is to let all the developers discuss it in open mind.

 

I think we can consolidate these unnecessary duplicate efforts into a separate project or part of openflowplugin, it is very necessary to provide only one entry to program openflow tables and rules, these operations must be efficiently synchronized and managed and coordinated, the direct benefits are as below:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

Table 0: Port Security, Ingress

Table 1: Ingress NAT Mapper

Table 2: Source Mapper

Table 3: Destination Mapper

Table 4: Policy Enforcer

Table 5: Egress NAT Mapper

Table 6: External Mapper

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

Table 0: Classifier

Table 10: Director

Table 20: Distributed ARP Responder

Table 30: DNAT for inbound floating-ip traffic

Table 40: Egress Acces-control

Table 50: Distributed LBaaS

Table 60: Distributed Virtual Routing (DVR)

Table 70: Layer 3 forwarding/lookup service

Table 80: Layer2 rewrite service

Table 90: Ingress Acces-control

Table 100: SNAT for traffic accessing external network

Table 110: Layer2 mac,vlan based forwarding


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

 


showOvsdbMdsal.py tool available

Flavio Fernandes <ffernand@...>
 

Hi folks,

After getting cross eyed from staring at postman outputs [1] to debug ovsdb net-virt, I decided to write
a tool to dump mdsal info related to ovsdb and its netvirt (including high level flows). I placed this tool
in the ‘resources’ dir in the ovsdb project [2]. Gerrit is here [3].

With that, we can narrow into that is available in either config or operational trees. Usage is below [5].
See [4] for an example output.

Hope this is useful to folks playing with ovsdb netvirt.

Best,

— flavio





[5]:

    Add showOvsdbMdsal.py tool

    This tool can provide useful info in regards to ovsdb's mdsal structures.
    It looks at the operational or config trees in mdsal, depending on the
    parameter '--config':

    $ ./showOvsdbMdsal.py -h
    Usage: showOvsdbMdsal.py [options]

    Options:
      --version             show program's version number and exit
      -h, --help            show this help message and exit
      -d, --debug           Verbosity. Can be provided multiple times for more
                            debug.
      -n, --noalias         Do not map nodeId of bridges to an alias
      -i ODLIP, --ip=ODLIP  opendaylights ip address
      -t ODLPORT, --port=ODLPORT
                            opendaylights listening tcp port on restconf
                            northbound
      -u ODLUSERNAME, --user=ODLUSERNAME
                            opendaylight restconf username
      -p ODLPASSWORD, --password=ODLPASSWORD
                            opendaylight restconf password
      -c, --config          parse mdsal restconf config tree instead of
                            operational tree
      -f, --hide-flows      hide flows




Re: [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?

Prem sankar G <prem.sankar.g@...>
 

Hi Yi Yang,

  Agree with you, very good points and we were also thinking on similar lines about creating small framework that can detect conflicts/provide conflict resolution.

 Also, I had brought this issue during our last ODL hackfest.  The suggestion from community was - as an interim, to create a wiki for documenting the pipeline information being used by various applications/NSFs (as a reference so that developers are cautioned about conflicts) and later address it programmatically.   I have created a draft wiki page based on your list and added VPNService table information  –

https://wiki.opendaylight.org/view/OF_pipeline

 Based on the community acceptance/TSC approval, we can formalize and request others to update this page.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Tuesday, July 14, 2015 8:24 PM
To: groupbasedpolicy-dev@...
Cc: ovsdb-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?
Importance: High

 

Hi, All

 

Maybe some of you know several projects in ODL have implemented their own openflow writers for programming openflow rules, the end part of the mail are some info I collected. My question is how they work together if we install all of them? Every writer will create table 0, can it work normally? How can we fix it if not? The most important issue is they are duplicating efforts, what if we can provide a good middle layer in openflowplugin or in a separate project in order that all the operations are synchronized and coordinated? I kick off this discussion here is to let all the developers discuss it in open mind.

 

I think we can consolidate these unnecessary duplicate efforts into a separate project or part of openflowplugin, it is very necessary to provide only one entry to program openflow tables and rules, these operations must be efficiently synchronized and managed and coordinated, the direct benefits are as below:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

Table 0: Port Security, Ingress

Table 1: Ingress NAT Mapper

Table 2: Source Mapper

Table 3: Destination Mapper

Table 4: Policy Enforcer

Table 5: Egress NAT Mapper

Table 6: External Mapper

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

Table 0: Classifier

Table 10: Director

Table 20: Distributed ARP Responder

Table 30: DNAT for inbound floating-ip traffic

Table 40: Egress Acces-control

Table 50: Distributed LBaaS

Table 60: Distributed Virtual Routing (DVR)

Table 70: Layer 3 forwarding/lookup service

Table 80: Layer2 rewrite service

Table 90: Ingress Acces-control

Table 100: SNAT for traffic accessing external network

Table 110: Layer2 mac,vlan based forwarding


Re: [openflowplugin-dev] How can we fix multiple masters issue better for openflowplugin?

Abhijit Kumbhare
 

Yi,

This is a good topic - and OpenFlow plugin will likely be a good place for this. Are you planning to work on this? Why don't you join the next OpenFlow plugin meeting (at least for part of the meeting) to discuss more?

As you mention probably some kind of a flow conflict detection and resolution module is needed.

Thanks,
Abhijit


On Tue, Jul 14, 2015 at 8:24 PM, Yang, Yi Y <yi.y.yang@...> wrote:

Hi, All

 

Maybe some of you know several projects in ODL have implemented their own openflow writers for programming openflow rules, the end part of the mail are some info I collected. My question is how they work together if we install all of them? Every writer will create table 0, can it work normally? How can we fix it if not? The most important issue is they are duplicating efforts, what if we can provide a good middle layer in openflowplugin or in a separate project in order that all the operations are synchronized and coordinated? I kick off this discussion here is to let all the developers discuss it in open mind.

 

I think we can consolidate these unnecessary duplicate efforts into a separate project or part of openflowplugin, it is very necessary to provide only one entry to program openflow tables and rules, these operations must be efficiently synchronized and managed and coordinated, the direct benefits are as below:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

Table 0: Port Security, Ingress

Table 1: Ingress NAT Mapper

Table 2: Source Mapper

Table 3: Destination Mapper

Table 4: Policy Enforcer

Table 5: Egress NAT Mapper

Table 6: External Mapper

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

Table 0: Classifier

Table 10: Director

Table 20: Distributed ARP Responder

Table 30: DNAT for inbound floating-ip traffic

Table 40: Egress Acces-control

Table 50: Distributed LBaaS

Table 60: Distributed Virtual Routing (DVR)

Table 70: Layer 3 forwarding/lookup service

Table 80: Layer2 rewrite service

Table 90: Ingress Acces-control

Table 100: SNAT for traffic accessing external network

Table 110: Layer2 mac,vlan based forwarding


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



Re: [ovsdb-users] Assigning IP Address to a switch

Sam Hague
 

Vikram,

I don't know of anything in the ovsdb or openflow protocols to assign addresses so that won't help.

I have cc'ed the controller-dev alias to see if there is something else in odl that can assign ip address to ports.

Sam

----- Original Message -----
From: "Vikram Darsi" <vikram.darsi@...>
To: ovsdb-dev@..., ovsdb-users@...
Sent: Wednesday, July 15, 2015 9:48:16 AM
Subject: [ovsdb-users] Assigning IP Address to a switch



Hi



Using OVSDB plugin, I am able to create a bridge and adding ports, setting
controller to it etc. Now I wanted to assign IP Address to the bridge. Is
there any way in opendaylight to assign the ipAddress to a created switch?



ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev
ovs-vsctl add-port br0 dpdk2 -- set Interface dpdk2 type=dpdk
ovs-vsctl add-port br0 dpdk3 -- set Interface dpdk3 type=dpdk
ovs-vsctl set interface dpdk2 ofport_request=1
ovs-vsctl set interface dpdk3 ofport_request=2



The above configurations are done



How to perform the below configurations using opendaylight?



ip addr add 10.10.10.221/24 dev br0

ip link set br0 up
ifconfig br0 arp






Thanks

Vikram


This email and attachments may contain privileged or confidential information
intended only for the addressee(s) indicated. The sender does not waive any
of its rights, privileges or protections respecting this information. If you
are not the named addressee, an employee, or agent responsible for sending
this message to the named addressee (or this message was received by
mistake), you are not authorized to read, print, retain, copy or disseminate
this message or any part of it. If received in error, please notify us
immediately by e-mail, discard any paper copies and delete all electronic
files of the email.

Computer viruses can be transmitted via email. The recipient should check
this email and any attachments for viruses. Email transmission cannot be
guaranteed to be secured or error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
The sender accepts no liability for any damage caused by any transmitted
viruses or errors or omissions in the contents of this message.

Overture Networks, Inc. 637 Davis Drive, Morrisville, NC USA 27560
www.overturenetworks.com

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

3141 - 3160 of 4855