Re: [openstack-dev] [Neutron] Security Groups OVS conntrack support

[Tapio Tallgren]

Thanks! I got it now: OpenStack already allows all "related" connections,
and you need connection tracking for that. This was not very clear to me
from the documentation...

-Tapio

On Mon, Nov 23, 2015 at 10:14 PM Russell Bryant  wrote:

> On 11/23/2015 02:16 PM, Kevin Benton wrote:
> > Security groups already use connection tracking. It's just done via a
> > linux bridge right now because the versions of OVS shipped with most
> > distros have no native conntrack support.
>
> This post discusses it in the context of OVN, but gets down to showing
> what the flows look like.  It also includes a link to a presentation
> about ovs+conntrack given at the OpenStack Summit in Vancouver.
>
>
> http://blog.russellbryant.net/2015/10/22/openstack-security-groups-using-ovn-acls/
>
> The most recent talk on this topic was "The State of Stateful Services"
> at the OVS Conference last week:
>
> http://openvswitch.org/support/ovscon2015/16/1620-stringer.pdf
> https://www.youtube.com/watch?v=PV2rxxb6lwQ
>
> --
> Russell Bryant
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Security Groups OVS conntrack support

[Tapio Tallgren]

Hi,

Sorry for the stupid question, but how will I use the connection tracking
in security groups? Is there an extension to the Neutron API call "add
security group rule" that allows for connection tracking, or this for FWaaS
only?

-Tapio

On Mon, Nov 23, 2015 at 12:39 PM Fawad Khaliq  wrote:

> On Mon, Nov 23, 2015 at 3:08 PM, Jakub Libosvar 
> wrote:
>
>> On 11/22/2015 07:28 PM, Gal Sagie wrote:
>> > Hi Fawad,
>> >
>> > From what i could understand from Miguel Angel Ajo, someone is working
>> > on this integration and it
>> > is suppose to be delivered as part of Mitaka.
>> > I don't remember the person name, Miguel will sure update shortly.
>> >
>> > Gal.
>>
>> Hi Fawad, Gal,
>>
>> I'm the person working on ovs firewall. There is reported an rfe bug [1]
>> to tracking it.
>>
>
> Hi Kuba,
>
> Great. We (Kuryr team) wanted insight into the plans for this support.
> Thanks for the note and link to the bug. I think we are all set to take the
> discussions further.
>
> Fawad
>
>
>> Kuba
>>
>> [1] https://bugs.launchpad.net/neutron/+bug/1461000
>> >
>> > On Sun, Nov 22, 2015 at 7:05 PM, Fawad Khaliq > > > wrote:
>> >
>> > Folks,
>> >
>> > Is there a plan to add conntrack support to the security groups for
>> > the OVS driver in Mitaka cycle?
>> >
>> > My understanding is that it is being actively worked on for
>> > networking-ovn but no concrete plan for support in the OVS Neutron
>> > driver yet.
>> >
>> > Thanks,
>> > Fawad Khaliq
>> >
>> >
>> >
>>  __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > <
>> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> > --
>> > Best Regards ,
>> >
>> > The G.
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] How does instance's tap device macaddress generate?

[Tapio Tallgren]

On 11.06.2015 18:52, Andreas Scheuring wrote:

Maybe this helps (taken from [1])

Actually there is one way that the MAC address of the tap device
affects
proper operation of guest networking - if you happen to set the tap
device's MAC identical to the MAC used by the guest, you will get errors
from the kernel similar to this:


   kernel: vnet9: received packet with own address as source address



[1] http://www.redhat.com/archives/libvir-list/2012-July/msg00984.html
I was wondering the same question myself one day and found this 
explanation from the same mail list:


vnet0 is the backend of the guest NIC, and its MAC addr
is more or less irrelevant to functioning of the guest
itself, since traffic does not originate on this NIC.
The only important thing is that this TAP device must
have a high value MAC address, to avoid the bridge
device using the TAP device's MAC as its own. Hence
when creating the TAP Device  libvirt takes the guest
MAC addr and simply sets the top byte to 0xFE

http://www.redhat.com/archives/libvir-list/2012-June/msg01330.html



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] OpenFlow security groups (pre-benchmarking plan)

[Tapio Tallgren]

Hi,

The RFC2544 with near zero packet loss is a pretty standard performance
benchmark. It is also used in the OPNFV project (
https://wiki.opnfv.org/characterize_vswitch_performance_for_telco_nfv_use_cases
).

Does this mean that OpenStack will have stateful firewalls (or security
groups)? Any other ideas planned, like ebtables type filtering?

-Tapio

On Wed, Feb 25, 2015 at 5:07 PM, Rick Jones rick.jon...@hp.com wrote:

 On 02/25/2015 05:52 AM, Miguel Ángel Ajo wrote:

 I’m writing a plan/script to benchmark OVS+OF(CT) vs
 OVS+LB+iptables+ipsets,
 so we can make sure there’s a real difference before jumping into any
 OpenFlow security group filters when we have connection tracking in OVS.

 The plan is to keep all of it in a single multicore host, and make
 all the measures within it, to make sure we just measure the
 difference due to the software layers.

 Suggestions or ideas on what to measure are welcome, there’s an initial
 draft here:

 https://github.com/mangelajo/ovs-experiments/tree/master/ovs-ct


 Conditions to be benchmarked

 Initial connection establishment time
 Max throughput on the same CPU

 Large MTUs and stateless offloads can mask a multitude of path-length
 sins.  And there is a great deal more to performance than Mbit/s. While
 some of that may be covered by the first item via the likes of say netperf
 TCP_CRR or TCP_CC testing, I would suggest that in addition to a focus on
 Mbit/s (which I assume is the focus of the second item) there is something
 for packet per second performance.  Something like netperf TCP_RR and
 perhaps aggregate TCP_RR or UDP_RR testing.

 Doesn't have to be netperf, that is simply the hammer I wield :)

 What follows may be a bit of perfect being the enemy of the good, or
 mission creep...

 On the same CPU would certainly simplify things, but it will almost
 certainly exhibit different processor data cache behaviour than actually
 going through a physical network with a multi-core system.  Physical NICs
 will possibly (probably?) have RSS going, which may cause cache lines to be
 pulled around.  The way packets will be buffered will differ as well.  Etc
 etc.  How well the different solutions scale with cores is definitely a
 difference of interest between the two sofware layers.

 rick


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
-Tapio
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Core pinning

[Tapio Tallgren]

Hi,

The use cases fro CPU pinning are exactly like discussed above: (1)
lowering guest scheduling latencies and (2) improving networking latencies
by pinning the SR-IOV IRQ's to specific cores. There is also a third use
case, (3) avoiding long latencies with spinlocks.

 On Wed, Nov 13, 2013 at 8:20 PM, Jiang, Yunhong yunhong.ji...@intel.com
 wrote:


 Similarly, once you start talking about doing SR-IOV networking I/O
 passthrough into a guest (for SDN/NFV stuff) for optimum efficiency it
 is beneficial to be able to steer interrupts on the physical host to the
 specific cpus on which the guest will be running.  This implies some
 form of pinning.

 Still, I think hypervisor should achieve this, instead of openstack.

How would this work? As a solution, this would be much better since then
OpenStack would have much less low-level work to do.

-Tapio
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev