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:[email protected]]
*Sent:* Friday, December 16, 2016 4:47 PM
*To:* Paraskevopoulos Georgios <[email protected]>;
[email protected]; [email protected]
*Cc:* Juan Vidal ALLENDE <[email protected]>
*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:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]] *On Behalf Of
*Paraskevopoulos Georgios
*Sent:* Friday, December 16, 2016 3:24 PM
*To:* [email protected]
<mailto:[email protected]>;
[email protected] <mailto:[email protected]>
*Cc:* Juan Vidal ALLENDE <[email protected]>
<mailto:[email protected]>
*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
https://newoldstamp.com/editor/images/phone_g.png+ 30 210 667 7689
https://newoldstamp.com/editor/images/[email protected]
<mailto:[email protected]>
https://newoldstamp.com/editor/images/address_g.png19.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
[email protected]
https://lists.opendaylight.org/mailman/listinfo/sfc-dev
