From: Toshiaki Makita <toshiaki.makita1@gmail.com>
To: Atzm Watanabe <atzm@stratosphere.co.jp>
Cc: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>,
netdev@vger.kernel.org,
Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [PATCH net-next v2] vxlan: fix handling of the inner 8021Q tagged frame
Date: Thu, 03 Apr 2014 01:16:36 +0900 [thread overview]
Message-ID: <1396455396.2215.32.camel@localhost.localdomain> (raw)
In-Reply-To: <874n2cszho.wl%atzm@stratosphere.co.jp>
On Wed, 2014-04-02 at 21:10 +0900, Atzm Watanabe wrote:
> Hi Makita-san,
Hi :)
>
> At Wed, 02 Apr 2014 17:30:55 +0900,
> Toshiaki Makita wrote:
> >
> > (2014/04/01 23:27), Atzm Watanabe wrote:
> > > Currently the implementation can forward the 8021Q tagged frame,
> > > but the FDB cannot learn the VID.
> > > So there is a possibility of forwarding the frame to wrong VTEP,
> > > when same LLADDR exists on different VLANs.
> > >
> > > This patch supports only single tagged frame, so the outermost
> > > tag will be used when handling the 8021AD Q-in-Q frame.
> > >
> > > v2: Fix probably unsafe operation on the struct vxlan_key.
> > > The outermost tag will be used when handling the 8021AD
> > > Q-in-Q frame. Based on Stephen Hemminger's comments.
> > >
> > > Signed-off-by: Atzm Watanabe <atzm@stratosphere.co.jp>
> > ...
> > > @@ -1215,8 +1257,18 @@ static void vxlan_rcv(struct vxlan_sock *vs,
> > > #endif
> > > }
> > >
> > > + ether_addr_copy(key.eth_addr, eth_hdr(skb)->h_source);
> > > + switch (ntohs(eth_hdr(skb)->h_proto)) {
> > > + case ETH_P_8021Q:
> > > + case ETH_P_8021AD:
> > > + key.vlan_id = ntohs(vlan_eth_hdr(skb)->h_vlan_TCI) & VLAN_VID_MASK;
> > > + break;
> >
> > It seems that we can't segregate skbs tagged by same vlan id but
> > different vlan protocols.
>
> Yes, but I believe it is better than all vlan protocols are ignored.
>
> Of course it still has problems when multiple protocols (0x8100,
> 0x88a8, 0x9100, ...) are mixed in a network, but I want to fix
> a problem in case of single tagged, at the beginning.
What I'm worried about is the use of the native vlan.
For example, if we are using C-vlan/S-vlan combination and use native
vlan for a certain S-vlan id.
In this case, we may see both double C/S-tagged frames and single
C-tagged frames, and we may treat C-vid as S-vid for single tagged
case...
This causes incorrect delivery of frames.
Maybe we can explicitly set the vlan protocol to be focused on by user
space, but this is just a suggestion.
If you are starting by this implementation, it's maybe better to note
this equating two protocols and the possible problem (in changelog or
somewhere).
Thanks,
Toshiaki Makita
next prev parent reply other threads:[~2014-04-02 16:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-01 14:27 [PATCH net-next v2] vxlan: fix handling of the inner 8021Q tagged frame Atzm Watanabe
2014-04-01 22:19 ` David Miller
2014-04-02 3:03 ` Atzm Watanabe
2014-04-02 8:30 ` Toshiaki Makita
2014-04-02 12:10 ` Atzm Watanabe
2014-04-02 16:16 ` Toshiaki Makita [this message]
2014-04-03 9:42 ` Atzm Watanabe
2014-04-04 15:25 ` Toshiaki Makita
2014-04-07 9:09 ` Atzm Watanabe
2014-04-08 16:28 ` Toshiaki Makita
2014-04-09 11:01 ` Atzm Watanabe
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=1396455396.2215.32.camel@localhost.localdomain \
--to=toshiaki.makita1@gmail.com \
--cc=atzm@stratosphere.co.jp \
--cc=makita.toshiaki@lab.ntt.co.jp \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).