netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Philip Craig <philipc@snapgear.com>
To: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: Stephen Hemminger <shemminger@osdl.org>, netdev@vger.kernel.org
Subject: Re: [RFC] gre: transparent ethernet bridging
Date: Fri, 04 Aug 2006 11:00:55 +1000	[thread overview]
Message-ID: <44D29C47.6080407@snapgear.com> (raw)
In-Reply-To: <20060803194016.GC527@xi.wantstofly.org>

Lennert Buytenhek wrote:
> On Thu, Aug 03, 2006 at 07:14:59PM +1000, Philip Craig wrote:
> 
>>> So now you _need_ bridging in the middle to send ethernet traffic over
>>> a GRE tunnel?  Ugh.
>> Agreed that would not be nice.  What is the usage scenario for this?
>> At least one end of the tunnel will be bridged?
> 
> For example for VPN purposes, I could imagine that you wouldn't want
> to use bridging.

What is the purpose of including the ethernet header if it only exists
on the tunnel?  I have used GRE tunnels for VPNs, but they have always
needed bridging.  If I don't need bridging, then the VPN is only passing
IP traffic and I just send that without GRE at all.

>>> If you really want to send ethernet and non-ethernet traffic over the
>>> same tunnel, can't you make multiple devices?
>> Do you mean make multiple GRE devices, where one has an ethernet mode set?
> 
> For example.  If you want to send ethernet-encapsulated and other-protocol-
> encapsulated traffic over the same GRE tunnel, that would seem like the
> cleanest solution to me.

It is fine for sending, but when receiving, which packets go to which
device?  Does a packet appear on only one device when sending, but both
devices when receiving?  Or does the operation of the non-ethernet device
change based on whether an ethernet device exists?  Modifying GRE to handle
multiple GRE tunnels that are actually the same does not seem clean.

This seems cleaner to me:
The GRE tunnel receives a packet of any protocol (ethernet included),
and adds the IP/GRE header.  Anything else is done above GRE.
Whatever needs the ethernet header should add it.

And then the decision is, how do we add the ethernet header?
- an option to GRE to always add the ethernet header
- a new virtual device
- as part of bridging

Any of these will work for me.

> Hmm, so it depends on the device whether BPDUs are sent with or without
> an ethernet header?  Do the devices that send BPDUs without ethernet
> header at least accept a BPDU with an ethernet header (and vice versa),
> or aren't the two modes compatible at all?

I don't have any to test with currently, but we only had complaints about
us not receiving them, and only at some sites.  So I assume that devices
can accept either format.


  reply	other threads:[~2006-08-04  1:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-31 10:06 [RFC] gre: transparent ethernet bridging Philip Craig
2006-07-31 16:14 ` Stephen Hemminger
2006-08-01  1:15   ` Philip Craig
2006-08-01  5:08     ` Stephen Hemminger
2006-08-01  9:29       ` Philip Craig
2006-08-02  6:17         ` Philip Craig
2006-08-02 17:23           ` Stephen Hemminger
2006-08-03  1:08             ` Philip Craig
2006-08-02  7:42       ` Lennert Buytenhek
2006-08-03  1:33         ` Philip Craig
2006-08-03  7:33           ` Lennert Buytenhek
2006-08-03  9:14             ` Philip Craig
2006-08-03 19:40               ` Lennert Buytenhek
2006-08-04  1:00                 ` Philip Craig [this message]
2006-08-04  8:02                   ` Lennert Buytenhek
2006-08-07  1:55                     ` Philip Craig
2006-08-10 13:09                       ` Lennert Buytenhek

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=44D29C47.6080407@snapgear.com \
    --to=philipc@snapgear.com \
    --cc=buytenh@wantstofly.org \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@osdl.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).