Hi Juanma, The Legacy Netvirt handles the port_securioty_enabled attribute. We will test the same and come back early next week.
Regards, Venkat G From: Aswin Suryanarayanan [mailto:[email protected]] Sent: Thursday, February 2, 2017 4:59 AM To: Sam Hague <[email protected]> Cc: Juan Manuel Fernandez <[email protected]>; Venkatrangan G - ERS, HCL Tech <[email protected]>; OPNFV Tech <[email protected]>; sfc-dev opendaylight <[email protected]>; [email protected] Subject: Re: [sfc-dev] [SFC] [SDNVPN] ETSI NFV Plugtest - Netvirt outcome Juanma, In new netvirt you can disable port security, completely, at network level and at port level. Disabling the port security after spawning a vm is supported as well. Besides you have the option of adding the extra ip/mac pairs [1] to the port so that that traffic with the added ip/mac pair will be considered legitimate. In old netvirt option to disable port security after spawning a vm should be available. Not sure whether there is a regression. @Venkat, do you have any update regarding this. [1]https://specs.openstack.org/openstack/neutron-specs/specs/api/allowed_address_pairs.html Thanks Aswin On Thu, Feb 2, 2017 at 5:42 PM, Sam Hague <[email protected]<mailto:[email protected]>> wrote: Adding Aswin and Venkat. On Feb 2, 2017 4:37 AM, "Juan Manuel Fernandez" <[email protected]<mailto:[email protected]>> wrote: Hi, Some of the people working for OPNFV in Madrid are involved in the ETSI NFV Plugtest where interoperability among different MANO orchestrators, NFVis and VNFs is being tested. There we have brought an OPNFV Colorado environment configured to deploy Service Chaining (including Openstack + Openstack Tacker + ODL Boron), however most of the requirements are related to basic connectivity to be provided by ODL as a Neutron backend. In our case, and given we are using SFC module the Neutron back-end is old Netvirt, since integration with new Netvirt is not finished. I don’t know how the final results of the Plugtest will be published by ETSI, but in general I would say tests have gone quite well for OPNFV, but we have found some issues we have not been able to solve and we wonder if you guys are thinking on solving them (or are already solved) in new Netvirt or maybe we have done something wrong and not taken something into account: 1. Attach to flat provider network: We are not completely sure, whether this is provided by ODL, but it seems not to be provided by Networking ODL in Openstack yet. Please, see the following proposed change in Networking ODL (not approved yet): https://review.openstack.org/#/c/425246/ 2. Some VNFs were working as a pure bump in the wire, re-injecting traffic received from a user, including a MAC/IP different than the VM’s (i.e. not doing MAC re-writing). In these situations, Openstack port security was preventing from what it is considering an anti-spoofing attack. In that sense we considered three different options: - Disable completely port security in /etc/neutron/plugins/ml2/ml2_conf.ini, by setting port_security_enabled to false. This solution is too wide and unsecure, so we did not apply it. On the other hand, we already had some other VMs running with security groups associated, so we were not sure if that might be a problem. - Disable port security in the network to be used. Unfortunately, this possibility that is available from Mitaka (included in August) was not still available in the Mirantis Openstack version (https://review.openstack.org/#/c/306470/) we were using, but we wonder if this is supported by ODL-Netvirt (old and new). The neutron command would be the following: o neutron net-create <whatever_network> --port_security_enabled=False - Finally, the last option we saw, was disabling port security and security groups in each and every port. The VM is attached to a network without disabling security groups, but as a next step, port security is disabled in the port using the following commands: o neutron port-update --no-security-groups PORT_ID o neutron port-update --port-security-enabled=False This option was crashing in ODL throwing a java exception, is that supported in new Netvirt? So, to sum up, are you aware of these issues in old Netvirt? Are they really issues? Is there a workaround? And the most important thing, in case they are real issues, are they already solved in new netvirt or will they be solved? My apologies if you have received this e-mail twice, I already sent it some minutes ago, but I’m not sure if was properly sent Thanks and best regards, Juanma [Ericsson]<http://www.ericsson.com/> JUAN MANUEL FERNANDEZ SDN System Engineer Ericsson Via de los Poblados 13 28043, Spain Phone +34 913392408<tel:+34%20913%2039%2024%2008> Mobile +34 618837205<tel:+34%20618%2083%2072%2005> Office 8402408 [email protected]<mailto:[email protected]> www.ericsson.com<http://www.ericsson.com> Legal entity: Ericsson España, S.A., registered office in Madrid. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer> _______________________________________________ sfc-dev mailing list [email protected]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/sfc-dev ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ----------------------------------------------------------------------------------------------------------------------------------------------------
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
