Hi Brady,
I created a bug report in https://bugs.opendaylight.org/show_bug.cgi?id=7548 BR, George From: Brady Allen Johnson [mailto:brady.allen.john...@ericsson.com] Sent: Friday, January 13, 2017 3:24 PM To: Paraskevopoulos Georgios <geo...@intracom-telecom.com>; netvirt-...@lists.opendaylight.org; sfc-dev@lists.opendaylight.org Cc: Juan Vidal ALLENDE <juan.vidal.alle...@ericsson.com> Subject: Re: Leftover vxgpe port after SF deletion George, I investigated this and have a fix for SFC Carbon that I will submit. The fix for Boron will be slightly different, and I'll need a Bugzilla [0] created to be able to submit the patch. Can you create one, please. Thanks, Brady [0] https://bugs.opendaylight.org/enter_bug.cgi?product=sfc On 19/12/16 09:41, Paraskevopoulos Georgios wrote: Hi Brady, I tried to list the SFFs and you were right, there was an SFF that was not deleted. I deleted it through the REST API and it was removed successfully, but the vxgpe port was still there on the compute node (logs in [0-3]). 1. It seems that the OVS state is not properly cleaned when an SFF is removed. Could someone investigate this? 2. Shouldn't the SFF be implicitly removed when the SF is deleted? Many users will utilize the tacker API, which does not expose the SFF entities. PS: Some info I didn't mention (better late than never): 1. This test is run using Boron SR1 2. This may be obvious, but all the VNFs are booted in the same CH where the leftover port is located. [0]: SFF list before delete: http://pastebin.com/wvBMvA9p [1]: SFF list after delete: http://pastebin.com/iyE8SVJi [2]: ovs-vsctl show AFTER delete: http://pastebin.com/GzKeRMSj [3]: dump-flows AFTER delete: http://pastebin.com/QkNQknUX Thanks, George From: Brady Allen Johnson [mailto:brady.allen.john...@ericsson.com] Sent: Friday, December 16, 2016 5:05 PM To: Paraskevopoulos Georgios <mailto:geo...@intracom-telecom.com> <geo...@intracom-telecom.com>; netvirt-...@lists.opendaylight.org <mailto:netvirt-...@lists.opendaylight.org> ; sfc-dev@lists.opendaylight.org <mailto:sfc-dev@lists.opendaylight.org> Cc: Juan Vidal ALLENDE <mailto:juan.vidal.alle...@ericsson.com> <juan.vidal.alle...@ericsson.com> Subject: Re: Leftover vxgpe port after SF deletion Here's the curl command to list all SFFs: curl -H "Content-Type: application/json" -X GET --user admin:admin http://localhost:8181/restconf/config/service-function-forwarder:service-function-forwarders/ | python -m json.tool And this should delete an SFF called SFF1: curl -H "Content-Type: application/json" -X DELETE --user admin:admin http://localhost:8181/restconf/config/service-function-forwarder:service-function-forwarders/service-function-forwarder/SFF1 For the localhost I used above in the URLs, you'll need to figure out the IP ODL is binding to on the controller, since if you try to send the message to localhost it wont work. Just do a "netstat -alnp | grep 8181" on the controller and you should see the correct IP. Thanks, Brady On 16/12/16 15:54, Paraskevopoulos Georgios wrote: Thanks Brady, I'm using the tacker API to delete everything and it has the following calls: - vnf-delete - sfc-delete (sff should be deleted here) - sfc-classifier-delete If you can provide me the ODL REST API endpoints I can hit to list/delete the SFFs after these operations it would be great! BR, George From: Brady Allen Johnson [mailto:brady.allen.john...@ericsson.com] Sent: Friday, December 16, 2016 4:47 PM To: Paraskevopoulos Georgios <mailto:geo...@intracom-telecom.com> <geo...@intracom-telecom.com>; netvirt-...@lists.opendaylight.org <mailto:netvirt-...@lists.opendaylight.org> ; sfc-dev@lists.opendaylight.org <mailto:sfc-dev@lists.opendaylight.org> Cc: Juan Vidal ALLENDE <mailto:juan.vidal.alle...@ericsson.com> <juan.vidal.alle...@ericsson.com> Subject: Re: Leftover vxgpe port after SF deletion George, This is a great test case! The flow in table=11 is the Netvirt classifier flow, so I dont know so much about why its not deleted when the classifier is deleted, but it definitely should be. As for the vxgpe port, that gets created when the SFC SFF is created, and should be deleted when the SFF is deleted. I noticed below you didnt mention anything about deleting the SFF, is that a step in your testing? Regards, Brady On 16/12/16 14:26, Paraskevopoulos Georgios wrote: Fixed typo. From: netvirt-dev-boun...@lists.opendaylight.org <mailto:netvirt-dev-boun...@lists.opendaylight.org> [mailto:netvirt-dev-boun...@lists.opendaylight.org] On Behalf Of Paraskevopoulos Georgios Sent: Friday, December 16, 2016 3:24 PM To: netvirt-...@lists.opendaylight.org <mailto:netvirt-...@lists.opendaylight.org> ; sfc-dev@lists.opendaylight.org <mailto:sfc-dev@lists.opendaylight.org> Cc: Juan Vidal ALLENDE <mailto:juan.vidal.alle...@ericsson.com> <juan.vidal.alle...@ericsson.com> Subject: [netvirt-dev] Leftover vxgpe port after SF deletion Hi all, I'm testing if the ODL does a proper cleanup in the OVS for different operations and I found one issue. Specifically I'm doing the following operations: 1. Create a network N1 2. Create a security group S1 and add rules for icmp, ssh and dhcp 3. Create 2 instances on N1 and add them to S1 4. Create 2 VNFs, 2 SFs and 2 classifiers After each step I delete everything and compare the ovs state after deletion to the default ovs state. *For steps 1-3 everything looks fine* If I delete everything after step 4 though, I get a leftover flow in table 11 on one of my compute nodes cookie=0x1110010000020255, duration=1172.279s, table=11, n_packets=0, n_bytes=0, tcp,reg0=0x1,tp_dst=80 actions=move:NXM_NX_TUN_ID[0..31]->NXM_NX_NSH_C2[],push_nsh,load:0x1->NXM_NX_NSH_MDTYPE[],load:0x3->NXM_NX_NSH_NP[],load:0xc0a80035->NXM_NX_NSH_C1[],load:0x2->NXM_NX_NSP[0..23],load:0xff->NXM_NX_NSI[],load:0xb000005->NXM_NX_TUN_IPV4_DST[],load:0x2->NXM_NX_TUN_ID[0..31],resubmit(,0) Running ovs-vsctl show, yields that one vxgpe port was not removed: Port vxgpe Interface vxgpe 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} Port "vxlan-192.168.2.53" Interface "vxlan-192.168.2.53" type: vxlan options: {key=flow, local_ip="192.168.2.51", remote_ip="192.168.2.53"} Any ideas on why this port/flow are not deleted? Thanks, George Paraskevopoulos George Paraskevopoulos Software Engineer (SDN/NFV), INTRACOM-TELECOM + 30 210 667 7689 geo...@intracom-telecom.com <mailto:geo...@intracom-telecom.com> 19.7 km Markopoulou Ave 19002 Peania, Athens, Greece The information in this e-mail message and any attachments are intended only for the individual or entity to whom it is addressed and may be confidential. If you have received this transmission in error, and you are not an intended recipient, be aware that any copying, disclosure, distribution or use of this transmission or its contents is prohibited. INTRACOM TELECOM and the sender accept no liability for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this email. Views or opinions expressed in this message may be those of the author and may not necessarily represent those of INTRACOM TELECOM.
_______________________________________________ sfc-dev mailing list sfc-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/sfc-dev
