|
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.
- 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).
- 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.
- 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).
- 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).
- 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
toggle quoted message
Show quoted text
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.
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
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.
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 ?
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.
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.
+ 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.
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?
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.
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
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.
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 ?
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.
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.
+ 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.
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.
toggle quoted message
Show quoted text
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
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.
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 ?
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.
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.
+ 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.
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@...>
toggle quoted message
Show quoted text
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.
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 ?
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.
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.
+ 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.
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.
toggle quoted message
Show quoted text
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 ?
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.
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.
+ 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.
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
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
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
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
toggle quoted message
Show quoted text
----- 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 ?
toggle quoted message
Show quoted text
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.
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.
+ 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.
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
toggle quoted message
Show quoted text
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.
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.
+ 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.
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.
toggle quoted message
Show quoted text
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.
+ 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.
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.
toggle quoted message
Show quoted text
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.
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?
toggle quoted message
Show quoted text
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. 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
toggle quoted message
Show quoted text
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?
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
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
toggle quoted message
Show quoted text
----- 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
|
|
