All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlad Yasevich <vyasevic@redhat.com>
To: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>,
	David Miller <davem@davemloft.net>,
	or.gerlitz@gmail.com, netdev@vger.kernel.org, mst@redhat.com,
	john.r.fastabend@intel.com
Subject: Re: [PATCH 00/11] Add basic VLAN support to bridges
Date: Sat, 15 Dec 2012 15:52:02 -0500	[thread overview]
Message-ID: <50CCE2F2.6040503@redhat.com> (raw)
In-Reply-To: <50CBA15D.6010805@mojatatu.com>

On 12/14/2012 04:59 PM, Jamal Hadi Salim wrote:
> On 12-12-14 11:50 AM, Vlad Yasevich wrote:
>>
>> Interesting.  But, but how complex would be be to configure a vlan
>> filter for say 10 different vlans,
>
> Shouldnt be hard. At the simple level you need one rule per VLAN.
> I am assuming only one vm per vlan and that you can key on something
> in the header.
>
>> each one of them only permitted
>> to be forwarded to their respective VM.
>
> Again assuming something in the header is going to say "this packet
> is allowed to go to this VM", a MAC address, an IP src/destination
> etc, correct?

The VLAN id in this case is what should decide where the packet is going.

>
>   Oh, and Vlan tags should
>> be stripped when they are being forwarded.
>
> Assuming they are not already stripped at vnetx,
> you could write a very simple action (probably one page of code) to
> strip vlans and do everything at br0;
> Your filter finds them at br0, your action strips them and pipes to
> another action that redirects to the correct device. i.e in unix speak:
> filter at br0 for VMx | strip vlan tag | redirect to vnetx

So you would completely bypass the bridge?  Not sure how much I like 
that since what would happen if 2 VMs are to share VLAN.  In such a 
case, broadcasts/multicasts only should only get forwarded to both of
these VMs.

I guess we could add the filters on the vnetx interfaces (which are just
taps).  Then its 2 filters per vlan (1 ingress 1 egress).  Need to think 
about this a bit.

Thanks
-vlad
>
> At the very minimal you need to identify those packets and that depends
> where you want to deploy the policy.
> If you deploy at the br device, you will see the raw packet i.e the vlan
> header wont be stripped.
> i.e youd have to enter some u32 rule with protocol "protocol 802.1q"
> If you deploy at each vnetx device assuming it is a vlan device, you
> wont see the vlan headers and you'll have to key on something else on
> the header "protocol ip"
>
> cheers,
> jamal
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2012-12-15 20:52 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-12 20:01 [PATCH 00/11] Add basic VLAN support to bridges Vlad Yasevich
2012-12-12 20:01 ` [PATCH 01/11] bridge: Add vlan filtering infrastructure Vlad Yasevich
2012-12-12 20:01 ` [PATCH 02/11] bridge: Validate that vlan is permitted on ingress Vlad Yasevich
2012-12-12 20:01 ` [PATCH 03/11] bridge: Verify that a vlan is allowed to egress on give port Vlad Yasevich
2012-12-12 20:01 ` [PATCH 04/11] bridge: Cache vlan in the cb for faster egress lookup Vlad Yasevich
2012-12-18 17:04   ` Stephen Hemminger
2012-12-18 17:50     ` Vlad Yasevich
2012-12-12 20:01 ` [PATCH 05/11] bridge: Add vlan to unicast fdb entries Vlad Yasevich
2012-12-12 20:01 ` [PATCH 06/11] bridge: Add vlan id to multicast groups Vlad Yasevich
2012-12-12 20:01 ` [PATCH 07/11] bridge: Add netlink interface to configure vlans on bridge ports Vlad Yasevich
2012-12-12 20:01 ` [PATCH 08/11] bridge: Add vlan support to static neighbors Vlad Yasevich
2012-12-12 20:01 ` [PATCH 09/11] bridge: Add the ability to configure untagged vlans Vlad Yasevich
2012-12-12 20:01 ` [PATCH 10/11] bridge: Implement untagged vlan handling Vlad Yasevich
2012-12-12 20:01 ` [PATCH 11/11] bridge: Dump vlan information from a bridge port Vlad Yasevich
2012-12-18 17:03   ` Stephen Hemminger
2012-12-18 17:51     ` Vlad Yasevich
2012-12-12 20:05 ` [PATCH 00/11] Add basic VLAN support to bridges Stephen Hemminger
2012-12-12 20:12   ` Vlad Yasevich
2012-12-12 22:54 ` Or Gerlitz
2012-12-12 23:36   ` Vlad Yasevich
2012-12-13 17:47     ` Stephen Hemminger
2012-12-13 18:53       ` Vlad Yasevich
2012-12-13 19:00       ` David Miller
2012-12-13 19:04         ` Stephen Hemminger
2012-12-13 20:17           ` Jamal Hadi Salim
2012-12-13 22:02             ` Stephen Hemminger
2012-12-13 22:37               ` Jamal Hadi Salim
2012-12-13 22:37                 ` Stephen Hemminger
2012-12-13 22:56                   ` Jamal Hadi Salim
2012-12-14 16:50                     ` Vlad Yasevich
2012-12-14 21:59                       ` Jamal Hadi Salim
2012-12-15 20:52                         ` Vlad Yasevich [this message]
2012-12-15 21:04                           ` Jamal Hadi Salim
2012-12-13 20:28 ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50CCE2F2.6040503@redhat.com \
    --to=vyasevic@redhat.com \
    --cc=davem@davemloft.net \
    --cc=jhs@mojatatu.com \
    --cc=john.r.fastabend@intel.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=or.gerlitz@gmail.com \
    --cc=shemminger@vyatta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.