[ovs-dev] [PATCH 2/2] FAQ: Mention packet filter incompatibility

YAMAMOTO Takashi yamamoto at valinux.co.jp
Tue May 6 23:32:35 UTC 2014


> On Wed, May 07, 2014 at 08:09:08AM +0900, YAMAMOTO Takashi wrote:
>> > On Tue, May 06, 2014 at 09:02:06AM +0900, YAMAMOTO Takashi wrote:
>> >> > On Mon, May 05, 2014 at 09:13:53AM +0900, YAMAMOTO Takashi wrote:
>> >> >> +Q: Open vSwitch does not seem to obey my packet filter rules.
>> >> >> +
>> >> >> +A: It's by design.  Open vSwitch interacts with packets at a lower layer
>> >> >> +   than typical packet-filter implementations like iptables.
>> >> >> +   For simple filtering rules, it might be possible to achieve similar
>> >> >> +   by installing appropriate OpenFlow flows instead.
>> >> >> +
>> >> >> +   If the use of a particular packet filter software is essential,
>> >> >> +   Open vSwitch might not be the best choice for you.  On Linux, you might
>> >> >> +   want to consider to use Linux Bridge, which works with iptables.
>> >> >> +   On NetBSD, you might want to consider to use bridge(4) with BRIDGE_IPF
>> >> >> +   option.
>> >> > 
>> >> > Hmm.  Open vSwitch works OK with iptables on Linux.  You can use it, for
>> >> > example, to firewall or filter particular L4 ports on your bridge
>> >> > "internal" ports.  XenServer has used iptables with Open vSwitch this
>> >> > way from the very beginning, and it's always worked fine.
>> >> > 
>> >> > Open vSwitch doesn't work with Linux bridge-specific filtering
>> >> > mechanisms, like ebtables, but that makes perfect sense since Open
>> >> > vSwitch replaces the bridge instead of supplementing it.
>> >> 
>> >> filtering on internal ports (and its associated IP stack) might work
>> >> as it's ordinary interface in the POV of filters.
>> >> 
>> >> however, what people is often interested in is filtering on
>> >> interfaces which are used for l2 forwarding of packets.  It's
>> >> what i wanted to explain in this change.  iirc, OpenStack folks
>> >> invented the infamous "hybrid interface" hack to workaround this
>> >> incompatibility.  are you referring to this sort of things by
>> >> "Linux bridge-specific filtering"?
>> > 
>> > I really was just talking about ebtables.
>> > 
>> > I agree that it is a good idea to cover this in the FAQ, as long as it's
>> > clear.  Do you have a suggested wording, that doesn't say that Open
>> > vSwitch doesn't work at all with iptables?  (I can't say to what extent
>> > packet filtering works with Open vSwitch on NetBSD, since I have not
>> > used it on NetBSD.)
>> 
>> how about this?
>> 
>> From 5472bec967ecc4a858db23bd1e4f572ddc8a5cb3 Mon Sep 17 00:00:00 2001
>> From: YAMAMOTO Takashi <yamamoto at valinux.co.jp>
>> Date: Mon, 5 May 2014 09:11:07 +0900
>> Subject: [PATCH] FAQ: Mention packet filter incompatibility
>> 
>> Signed-off-by: YAMAMOTO Takashi <yamamoto at valinux.co.jp>
>> ---
>>  FAQ | 25 +++++++++++++++++++++++++
>>  1 file changed, 25 insertions(+)
>> 
>> diff --git a/FAQ b/FAQ
>> index fc21af4..f225061 100644
>> --- a/FAQ
>> +++ b/FAQ
>> @@ -676,6 +676,31 @@ A: On Linux kernels before 3.11, the OVS GRE module and Linux GRE module
>>     can then reload the OVS module following the directions in INSTALL,
>>     which will ensure that dependencies are satisfied.
>>  
>> +Q: Open vSwitch does not seem to obey my packet filter rules.
>> +
>> +A: It depends on mechanisms and configurations you want to use.
>> +
>> +   Typical packet filters like iptables do not work on interfaces attached
>> +   to Open vSwitch in the sense of "ovs-vsctl add-port" with type=system
>> +   because Open vSwitch forwards packets at a lower layer than typical
>> +   packet-filter implementations install their hooks.
>> +
>> +   ebtables is a Linux Bridge specific mechansim and does not work with
>> +   Open vSwitch.
>> +
>> +   You can use packet filters on the host OS side of local ports as they
>> +   are mostly ordinary interfaces in the point of view of packet filters.
>> +   XenServer uses iptables with Open vSwitch this way.
>> +
>> +   For simple filtering rules, it might be possible to achieve similar
>> +   by installing appropriate OpenFlow flows instead.
>> +
>> +   If the use of a particular packet filter setup is essential,
>> +   Open vSwitch might not be the best choice for you.  On Linux, you might
>> +   want to consider to use Linux Bridge, which works with iptables and
>> +   ebtables.  On NetBSD, you might want to consider to use bridge(4)
>> +   with BRIDGE_IPF option.
>> +
> 
> How about this?

looks good to me.
("usefully use" sounds a little weird but i'm not an english speaker)

YAMAMOTO Takashi

> 
> Q: Open vSwitch does not seem to obey my packet filter rules.
> 
> A: It depends on mechanisms and configurations you want to use.
> 
>    You cannot usefully use typical packet filters, like iptables, on
>    physical Ethernet ports that you add to an Open vSwitch bridge.
>    This is because Open vSwitch captures packets from the interface at
>    a layer lower below where typical packet-filter implementations
>    install their hooks.  (This actually applies to any interface of
>    type "system" that you might add to an Open vSwitch bridge.)
> 
>    You can usefully use typical packet filters on Open vSwitch
>    internal ports as they are mostly ordinary interfaces from the point
>    of view of packet filters.
> 
>    For example, suppose you create a bridge br0 and add Ethernet port
>    eth0 to it.  Then you can usefully add iptables rules to affect the
>    internal interface br0, but not the physical interface eth0.  (br0
>    is also where you would add an IP address, as discussed elsewhere
>    in the FAQ.)
>        
>    For simple filtering rules, it might be possible to achieve similar
>    by installing appropriate OpenFlow flows instead.
> 
>    If the use of a particular packet filter setup is essential, Open
>    vSwitch might not be the best choice for you.  On Linux, you might
>    want to consider to use Linux Bridge.  (This is the only choice if
>    you want to use ebtables rules.)  On NetBSD, you might want to
>    consider to use bridge(4) with BRIDGE_IPF option.



More information about the dev mailing list