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
