We are using Open stack Mitaka setup with VXLAN used as a tunnel
between the compute nodes.
Do I need to change the Open stack setup configuration for VXLAN-GPE
or should I mention the same VXLAN port information in the SFF?
Regards
Anirudh
*From:*Brady Allen Johnson [mailto:[email protected]]
*Sent:* Wednesday, November 30, 2016 4:31 PM
*To:* Anirudh Gupta <[email protected]>;
[email protected]
*Cc:* Mohit Gupta <[email protected]>; Lovelesh Pandya
<[email protected]>
*Subject:* Re: [sfc-dev] ODL SFF Creation Issue
You only need to list the vxlan-gpe port.
I forgot to mention previously, you should remove this line from the
ovs-options: "local-ip":"flow"
Here's what I have from a working config:
{
"service-function-forwarders": {
"service-function-forwarder": [
{
"name": "sff1",
"service-function-forwarder-ovs:ovs-bridge": {
"bridge-name": "br-int"
},
"sff-data-plane-locator": [
{
"name": "sff-dpl1",
"data-plane-locator":
{
"ip": "159.107.13.58",
"port": 6633,
"transport": "service-locator:vxlan-gpe"
},
"service-function-forwarder-ovs:ovs-options": {
"key": "flow",
"dst-port": "6633",
"remote-ip": "flow"
}
}
],
"service-function-dictionary": [
{
"name": "sf1",
"sff-sf-data-plane-locator":
{
"sf-dpl-name": "sf-dpl1",
"sff-dpl-name": "sff-dpl1"
}
}
]
}
]
}
}
Brady
On 30/11/16 11:55, Anirudh Gupta wrote:
Thanks for your inputs.
Just a small query, the Data plane Locator we are configuring
while creating SFF(sffdp6) is a dummy data plane locator.
Should we move on with the same SFF, or we need to mention all the
ports of br-int in data plane locator while configuring the SFF?
The REST API for SFF is as follows :-
*URL :*-
http://172.19.53.31:8181/restconf/config/service-function-forwarder:service-function-forwarders/service-function-forwarder/sff6
*Body :*-
{
"service-function-forwarder":{
"name":"sff6",
"sff-data-plane-locator":[
{
"name":"sff6dp6",
"data-plane-locator":{
"port":4789,
"ip":"172.19.53.34",
"transport":"service-locator:vxlan-gpe"
},
"ovs-bridge":{
"bridge-name":"br-int"
},
"ovs-options":{
"local-ip":"flow",
"remote-ip":"flow",
"dst-port":"4789"
}
}
],
"ip-mgmt-address":"172.19.53.34",
"service-function-forwarder-ovs:ovs-bridge":{
"bridge-name":"br-int"
},
"service-function-dictionary":[
{
"sff-sf-data-plane-locator":{
"sf-dpl-name":"sf1dp1",
"sff-dpl-name":"sff6dp6"
},
"sff-interfaces":[
],
"name":"sf1"
}
]
}
}
Regards
Anirudh Gupta
*From:*Brady Allen Johnson [mailto:[email protected]]
*Sent:* Wednesday, November 30, 2016 3:58 PM
*To:* Anirudh Gupta <[email protected]>
<mailto:[email protected]>;
[email protected] <mailto:[email protected]>
*Cc:* Mohit Gupta <[email protected]>
<mailto:[email protected]>; Lovelesh Pandya
<[email protected]> <mailto:[email protected]>
*Subject:* Re: [sfc-dev] ODL SFF Creation Issue
The only way for SFC to work in OpenStack is to also use Netvirt.
This is because there needs to be a classifier in place that maps
subscriber/tenant traffic to service chains. Currently, the only
supported classifier is implemented in Netvirt.
For pure OpenFlow-based SFC, you just need to install these features:
opendaylight-user@root>feature:install
odl-sfc-openflow-renderer odl-sfc-ui odl-ovsdb-openstack
This will in-turn install the rest of the needed SFC features.
Notice the "odl-sfcofl2" feature is deprecated in Boron (still
works though), and has been removed in Carbon. Basically we just
changed the name to "odl-sfc-openflow-renderer".
Im not sure how well the "odl-l2switch-hosttracker" and
"odl-l2switch-arphandler" features will play with SFC due to the
aforementioned Application Coexistence issues. Netvirt will handle
all the tenant VM traffic for you.
I would recommend only installing SFC and Netvirt as listed above.
Dont forget to send the 2 Application Coexistence curl commands
mentioned previously.
Regards,
Brady
On 30/11/16 10:55, Anirudh Gupta wrote:
Hi Brady,
We were configuring the “br-test” just to verify the
functionality as mentioned in the section *Verifying mapping
from SFF to OVS* of Boron User Guide
http://docs.opendaylight.org/en/stable-boron/user-guide/service-function-chaining.html
We are using “br-int” only as mentioned in SFF(sff6).
Initially, we had created the flows without Netvirt only. But
didn’t succeed, so thought of adding the Netvirt Functionality
also.
We just want to create a Service chain (with only one SF) in
Open stack using ODL. For that purpose, we installed below
mentioned packages in ODL (using feature: install in karaf)
but we are not convinced that this is the right mix of
packages required for the service chain to work. Can you
please share a bare minimum set of packages that we need, to
create a service chain in Open stack using ODL ?
oodl-ovsdb-openstack
oodl-dlux-core
oodl-dlux-all
oodl-sfc-ui
oodl-sfc-ovs
oodl-sfc-provider
oodl-sfc-model
oodl-sfc-ui
oodl-openflowplugin-nxm-extensions
oodl-openflowplugin-flow-services
oodl-l2switch-hosttracker
oodl-l2switch-arphandler
oodl-sfcofl2
oodl-netvirt-impl
Regards
Anirudh Gupta
*From:*Brady Allen Johnson
[mailto:[email protected]]
*Sent:* Wednesday, November 30, 2016 2:18 PM
*To:* Anirudh Gupta <[email protected]>
<mailto:[email protected]>;
[email protected]
<mailto:[email protected]>
*Subject:* Re: [sfc-dev] ODL SFF Creation Issue
Anirudh,
A few comments on your setup and attached configuration:
Why do you want to create "br-test"? Normally in an OpenStack
env, the SFF should be on the already created "br-int". I dont
see anywhere in the config any references to "br-test". The
only configured SFF (sff6) is being configured on "br-int".
From the flows you attached:
* There is no Netvirt classifier being configured, which is
on table=11
* There are no SFC flows configured
If you plan to use both SFC and Netvirt on the same bridge,
then the Application Coexistence needs to be configured so
that SFC and Netvirt dont stomp on each other's flows. This
consists of offsetting the SFC flows to its own set of
OpenFlow tables.
Here are the commands we usually use to configure Application
Coexistence for SFC and Netvirt. These commands must be sent
before creating any VMs.
curl -u admin:admin -H 'Content-type: application/json' -X
PUT -d {"netvirt-providers-config":{"table-offset":1}}
http://192.168.0.2:8181/restconf/config/netvirt-providers-config:netvirt-providers-config
curl -u admin:admin -H 'Content-type: application/json' -X
PUT -d
'{"sfc-of-renderer-config":{"sfc-of-table-offset":"150","sfc-of-app-egress-table-offset":"11"}}'http://192.168.0.2:8181/restconf/config/sfc-of-renderer:sfc-of-renderer-config
Regards,
Brady
On 30/11/16 07:44, Anirudh Gupta wrote:
Hi,
We have installed Openvswitch 2.5.90 with NSH patch and
also upgraded our ODL setup to distribution-karaf-0.5.0-Boron.
The following packages have been installed on it :-
oodl-ovsdb-openstack
oodl-dlux-core
oodl-dlux-all
oodl-sfc-ui
oodl-sfc-ovs
oodl-sfc-provider
oodl-sfc-model
oodl-sfc-ui
oodl-openflowplugin-nxm-extensions
oodl-openflowplugin-flow-services
oodl-l2switch-hosttracker
oodl-l2switch-arphandler
oodl-sfcofl2
oodl-netvirt-impl
Still we are facing following issues :-
oif a bridge(br-test) request is POST in the ODL from the
Rest Client, then corresponding SFF for this OVS Bridge
should be configured, which is not happening in our case.
oif a bridge(br-test) is created in Openstack using
ovs-vsctl command, then corresponding SFF for this OVS
Bridge should be configured, which is not happening in our
case.
oAfter configuring the Rendered Service Path, we can
observe the flow drop at table 10.
Please find attached the following :-
oKaraf logs with a log level of DEBUG org.opendaylight.sfc
obr-int dump-flow
oSFF-SF-ACL-CLASSIFIER REST API
oOvs-vswitchd logs
We are kind of stuck in this issue, request you all to
please extend your support in order to resolve it.
Regards
Anirudh Gupta
*From:* Anirudh Gupta
*Sent:* Wednesday, November 23, 2016 12:35 PM
*To:* '[email protected]
<mailto:[email protected]>'
<[email protected]>
<mailto:[email protected]>
*Subject:* ODL SFF Creation Issue
Hi,
We are using ODL Beryllium-SR4 release integrated with
Openstack Mitaka Release having OVS version 2.6.1 and
trying to create SFF by manually creating a bridge in the
compute node.
The following packages are installed in ODL :-
·odl-ovsdb-openstack
·odl-dlux-core
·odl-dlux-all
·odl-sfc-ui
·odl-sfc-ovs
·odl-sfc-provider
·odl-sfc-model
·odl-sfc-ui
·odl-openflowplugin-nxm-extensions
·odl-openflowplugin-flow-services
·odl-l2switch-hosttracker
·odl-l2switch-arphandler
·odl-sfcofl2
As per the Beryllium User
Guidehttps://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxpam5iZmVzY21hZWRhcHxneDoyM2VjNmZmNTg2N2RhMmFh
*, Chapter 25 Section Configuring SFC-OVS*, if a
bridge(br-test) request is POST in the ODL from the shell,
then corresponding SFF for this OVS Bridge should be
configured.
But in our case this is not working.
The bridge details is reaching the ODL karaf.log(attached
in the mail), but SFF creation is not successful.
The same issue is being observed using Boron SR1 Release.
Can someone please help us in resolving the issue.
PFA the karaf.log with a log level of DEBUG
org.opendaylight.sfc
With Regards
Anirudh Gupta
Software Engineer
[email protected]
<mailto:[email protected]> | Extension – 4908
<https://www.aricent.com/>
"DISCLAIMER: This message is proprietary to Aricent and is
intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential
information and should not be circulated or used for any
purpose other than for what it is intended. If you have
received this message in error, please notify the
originator immediately. If you are not the intended
recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing
the contents of this message. Aricent accepts no
responsibility for loss or damage arising from the use of
the information transmitted by this email including damage
from virus."
_______________________________________________
sfc-dev mailing list
[email protected]
<mailto:[email protected]>
https://lists.opendaylight.org/mailman/listinfo/sfc-dev
"DISCLAIMER: This message is proprietary to Aricent and is
intended solely for the use of the individual to whom it is
addressed. It may contain privileged or confidential
information and should not be circulated or used for any
purpose other than for what it is intended. If you have
received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying,
altering, or disclosing the contents of this message. Aricent
accepts no responsibility for loss or damage arising from the
use of the information transmitted by this email including
damage from virus."
"DISCLAIMER: This message is proprietary to Aricent and is
intended solely for the use of the individual to whom it is
addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than
for what it is intended. If you have received this message in
error, please notify the originator immediately. If you are not
the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the
contents of this message. Aricent accepts no responsibility for
loss or damage arising from the use of the information transmitted
by this email including damage from virus."
"DISCLAIMER: This message is proprietary to Aricent and is intended
solely for the use of the individual to whom it is addressed. It may
contain privileged or confidential information and should not be
circulated or used for any purpose other than for what it is intended.
If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying,
altering, or disclosing the contents of this message. Aricent accepts
no responsibility for loss or damage arising from the use of the
information transmitted by this email including damage from virus."
