Victor,
Its possible to have different VX-GPE ports on an SFF, and thus
multiple ports for SFs. This can be achieved by creating multiple SFF
DataPlaneLocators (DPLs), and setting the SFF and SF DPLs to use in
the SFF ServiceFunctionDictionary.
As an example, lets define 1 SFF (sff1) and 2 SFs (sf1 and sf2). Both
SFs will be connected to sff1 but use different VX-GPE ports.
sff1 will have 2 VX-GPE ports: 6633 and 6666
sf1 will connect using 6633
sf2 will connect using 6666
Here is the JSON config:
{
"service-function-forwarders": {
"service-function-forwarder": [
{
"name": "sff1",
"service-function-forwarder-ovs:ovs-bridge": {
"bridge-name": "br1" },
"sff-data-plane-locator": [
{
"name": "sff-dpl1",
"data-plane-locator": {
"ip": "159.107.12.233",
"port": 6633,
"transport": "service-locator:vxlan-gpe"
},
"service-function-forwarder-ovs:ovs-options": {
"nsp": "flow",
"nshc4": "flow",
"nshc3": "flow",
"nshc2": "flow",
"nshc1": "flow",
"key": "flow",
"dst-port": "6633",
"nsi": "flow",
"remote-ip": "flow"
}
},
{
"name": "sff-dpl2",
"data-plane-locator": {
"ip": "159.107.12.233",
"port": 6666,
"transport": "service-locator:vxlan-gpe"
},
"service-function-forwarder-ovs:ovs-options": {
"nsp": "flow",
"nshc4": "flow",
"nshc3": "flow",
"nshc2": "flow",
"nshc1": "flow",
"key": "flow",
"dst-port": "6666",
"nsi": "flow",
"remote-ip": "flow"
}
}
],
"service-function-dictionary": [
{
"name": "sf1",
"sff-sf-data-plane-locator":
{
"sf-dpl-name": "sf1-dpl1",
"sff-dpl-name": "sff-dpl1"
}
},
{
"name": "sf2",
"sff-sf-data-plane-locator":
{
"sf-dpl-name": "sf2-dpl1",
"sff-dpl-name": "sff-dpl2"
}
}
]
}
]
}
}
{
"service-functions": {
"service-function": [
{
"name": "sf1",
"type": "http-header-enrichment",
"nsh-aware": true,
"sf-data-plane-locator": [
{
"name": "sf1-dpl1",
"ip": "191.168.56.110",
"port": 6633,
"transport": "service-locator:vxlan-gpe",
"service-function-forwarder": "sff1"
}
]
},
{
"name": "sf2",
"type": "dpi",
"nsh-aware": true,
"sf-data-plane-locator": [
{
"name": "sf2-dpl1",
"ip": "191.168.56.110",
"port": 6666,
"transport": "service-locator:vxlan-gpe",
"service-function-forwarder": "sff1"
}
]
}
]
}
}
Let me know if this is what you're looking for.
Regards,
Brady
On 08/11/16 09:22, Yang, Yi Y wrote:
As I said, we have no way to set this for ovs,
sf-data-plane-locator:port is just for sfc, not for ovs.
*From:*VictorVu [mailto:[email protected]]
*Sent:* Tuesday, November 8, 2016 3:55 PM
*To:* Yang, Yi Y <[email protected]>; Brady Johnson
<[email protected]>
*Cc:* sfc-dev opendaylight <[email protected]>
*Subject:* Re: [sfc-dev] SF dataplane set port bug
Ok, but how about we have multiple SFs in a VM. I still think we
should have more flexibility for setting SF endpoint. Right now, the
sf-data-plane-locator:port parameter has no meaning.
On 11/8/16 4:29 PM, Yang, Yi Y wrote:
IANA has assigned it, other services or applications can’t abuse it.
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=86
*From:*VictorVu [mailto:[email protected]]
*Sent:* Tuesday, November 8, 2016 3:22 PM
*To:* Yang, Yi Y <[email protected]>
<mailto:[email protected]>; Brady Johnson
<[email protected]> <mailto:[email protected]>
*Cc:* sfc-dev opendaylight <[email protected]>
<mailto:[email protected]>
*Subject:* Re: [sfc-dev] SF dataplane set port bug
Hi,
Yes, every SF should have different IP, but its port is
restricted to the "dst_port" of its attached SFF. If that port on
the SF VM has already been used by another application, the SF
listening port must be changed, then does the SFF dst_port and
other SFs attached to the same SFF.
Regards,
Victor
On 11/8/16 3:33 PM, Yang, Yi Y wrote:
Why is it inconvenient? Every SF should have different IP.
*From:*VictorVu [mailto:[email protected]]
*Sent:* Tuesday, November 8, 2016 2:21 PM
*To:* Yang, Yi Y <[email protected]>
<mailto:[email protected]>; Brady Johnson
<[email protected]>
<mailto:[email protected]>
*Cc:* sfc-dev opendaylight <[email protected]>
<mailto:[email protected]>
*Subject:* Re: [sfc-dev] SF dataplane set port bug
Yang,
I see, so this is an OVS limitation. Does it mean all SFs
attached to an SFF have to listen to a same port? It seems
inconvenient.
Thank you.
On 11/8/16 9:21 AM, Yang, Yi Y wrote:
Victor, thank you for your test, when OVS sends a VxLAN
packet, it doesn’t know destination UDP port, nobody will
tell OVS, so it only can use dst_port in vxlan port
options, your test also confirmed this.
*From:*VictorVu [mailto:[email protected]]
*Sent:* Tuesday, November 8, 2016 5:46 AM
*To:* Yang, Yi Y <[email protected]>
<mailto:[email protected]>; Brady Johnson
<[email protected]>
<mailto:[email protected]>
*Cc:* sfc-dev opendaylight
<[email protected]>
<mailto:[email protected]>
*Subject:* Re: [sfc-dev] SF dataplane set port bug
Hi Yang,
I don't think the problem is within the SF/sfc-agent,
because as you can see in the pcap file, the SFF always
sends to SF's 6633 port, no matter which port the SF is
listening to. I tried to change all 6633 ports in the
configuration file to 6666 and it worked, but if I only
change SF's configuration it didn't.
Regards,
On 11/7/16 11:25 AM, Yang, Yi Y wrote:
Hi, Victor
Try this one patch.
*From:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]] *On
Behalf Of *VictorVu
*Sent:* Sunday, November 6, 2016 12:38 PM
*To:* Brady Johnson <[email protected]>
<mailto:[email protected]>
*Cc:* sfc-dev opendaylight
<[email protected]>
<mailto:[email protected]>
*Subject:* Re: [sfc-dev] SF dataplane set port bug
Hi,
Sorry for the delayed response. I reproduced the
sfc103 demo for testing. This is the config file:
https://dl.dropboxusercontent.com/u/43016963/ODL%20shared%20config/setup_sfc.py
The dumpflow of sff1:
https://dl.dropboxusercontent.com/u/43016963/ODL%20shared%20config/sff1%20dumpflow.txt
sudo ovs-vsctl show
06321d10-c7b5-47ea-8b5f-48c034a843cb
Manager "tcp:192.168.1.5:6640"
is_connected: true
Bridge br-sfc
Controller "tcp:192.168.1.5:6653"
is_connected: true
Port br-sfc
Interface br-sfc
type: internal
Port "sff1-dpl"
Interface "sff1-dpl"
type: vxlan
options: {dst_port="6633", exts=gpe,
key=flow, "nshc1"=flow, "nshc2"=flow, "nshc3"=flow,
"nshc4"=flow, nsi=flow, nsp=flow, remote_ip=flow}
ovs_version: "2.5.90"
I'm not quite understand the meaning of the above
option "dst_port".
And this is the packet capturing results:
https://dl.dropboxusercontent.com/u/43016963/ODL%20shared%20config/mycap.pcap
Thank you very much,
Victor
On 11/6/16 3:05 AM, Brady Johnson wrote:
Victor,
Could you also send us the sff configuration, a
dump of the flows, and the result of the
following command:
sudo ovs-vsctl show
Thanks,
Brady
On Nov 5, 2016 18:48, "VictorVu"
<[email protected]
<mailto:[email protected]>> wrote:
Hi Brady,
I have just tried the master branch (commit
f65065b19516a750b73262c63ba269fca2365e23),
still the same problem. The configuration is
like this:
"service-function": [
{
"ip-mgmt-address": "170.10.0.5",
"name": "dpi-1",
"nsh-aware": "true",
"rest-uri":
"http://170.10.0.5:5000";
<http://170.10.0.5:5000>,
"sf-data-plane-locator": [
{
"ip": "170.10.0.5",
"name": "dpi-1-dpl",
"port": 6666,
"service-function-forwarder": "SFF1",
"transport":
"service-locator:vxlan-gpe"
}
],
"type": "dpi"
},
Thank you,
Victor
On 11/6/16 2:32 AM, Brady Johnson wrote:
Victor,
What version of odl are you using?
Thanks,
Brady
On Nov 5, 2016 18:15, "VictorVu"
<[email protected]
<mailto:[email protected]>> wrote:
Hi.
Recently I have tried to set SF
dataplane locator port to other
values than 6633 and it did not work.
SFFs still send packet to port 6633
of the SF ip address. Has anyone
encountered this problem? Is it a bug
in current version?
Best regards.
Victor
_______________________________________________
sfc-dev mailing list
[email protected]
<mailto:[email protected]>
https://lists.opendaylight.org/mailman/listinfo/sfc-dev
_______________________________________________
sfc-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/sfc-dev
