From: Jiri Benc <jbenc@redhat.com>
To: pravin shelar <pshelar@ovn.org>
Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>,
Pravin B Shelar <pshelar@nicira.com>, Thomas Graf <tgraf@suug.ch>,
Simon Horman <simon.horman@netronome.com>
Subject: Re: [PATCH net 3/3] gre: receive also TEB packets for lwtunnels
Date: Fri, 22 Apr 2016 23:27:32 +0200 [thread overview]
Message-ID: <20160422232732.7dfd0ec3@griffin> (raw)
In-Reply-To: <CAOrHB_DrFXg=nQAdscOgX8nbUoOC4fMsWiN6R4n907zB5rtD=g@mail.gmail.com>
On Fri, 22 Apr 2016 14:07:01 -0700, pravin shelar wrote:
> On Fri, Apr 22, 2016 at 10:44 AM, Jiri Benc <jbenc@redhat.com> wrote:
> > For ipgre interfaces in collect metadata mode, receive also traffic with
> > encapsulated Ethernet headers. The lwtunnel users are supposed to sort this
> > out correctly. This allows to have mixed Ethernet + L3-only traffic on the
> > same lwtunnel interface.
> >
> How user is suppose to sort out the type of packet? whether it is L2 or L3.
By skb->protocol, of course. Will be ETH_P_TEB if the inner packet was
Ethernet. There's no problem with this, for lwtunnels used with encap
routes, such packets are just discarded (which is the expected
behavior), as there's no protocol handler for ETH_P_TEB. More clever
lwtunnel users (such as openvswitch) can process the packets. This is
important in order to have a single tunnel interface for everything.
> Is it fine to receive L2 packet over L3 device?
> At least ip_tunnel_rcv() is not ready to handle such packet.
I don't see why. Could you please elaborate? Seems safe to me. The
desired result is skb->protocol == htons(ETH_P_TEB), network header(!)
pointing to the start of the Ethernet frame (because we're tunneling
Ethernet via ARPHRD_IPGRE interface, there's no L2 header to have), mac
header not being set.
Jiri
next prev parent reply other threads:[~2016-04-22 21:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-22 17:44 [PATCH net 0/3] ipgre: fix lwtunnel support Jiri Benc
2016-04-22 17:44 ` [PATCH net 1/3] gre: do not assign header_ops in collect metadata mode Jiri Benc
2016-04-22 21:04 ` pravin shelar
2016-04-22 21:20 ` Jiri Benc
2016-04-23 1:41 ` Thomas Graf
2016-04-24 9:31 ` Jiri Benc
2016-04-22 17:44 ` [PATCH net 2/3] gre: build header correctly for collect metadata tunnels Jiri Benc
2016-04-22 21:05 ` pravin shelar
2016-04-23 0:03 ` Simon Horman
2016-04-22 17:44 ` [PATCH net 3/3] gre: receive also TEB packets for lwtunnels Jiri Benc
2016-04-22 21:07 ` pravin shelar
2016-04-22 21:27 ` Jiri Benc [this message]
2016-04-23 3:40 ` pravin shelar
2016-04-24 9:54 ` Jiri Benc
2016-04-23 1:49 ` Thomas Graf
2016-04-23 5:09 ` Simon Horman
2016-04-24 9:38 ` Jiri Benc
2016-04-28 6:49 ` Simon Horman
2016-04-28 8:23 ` Jiri Benc
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=20160422232732.7dfd0ec3@griffin \
--to=jbenc@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pshelar@nicira.com \
--cc=pshelar@ovn.org \
--cc=simon.horman@netronome.com \
--cc=tgraf@suug.ch \
/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).