All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Patrick McHardy <kaber@trash.net>,
	netdev@vger.kernel.org, shemminger@linux-foundation.org,
	davem@davemloft.net, jeff@garzik.org
Subject: Re: [RFC NET 00/02]: Secondary unicast address support
Date: Fri, 22 Jun 2007 05:08:14 -0700	[thread overview]
Message-ID: <467BBBAE.40901@candelatech.com> (raw)
In-Reply-To: <m1bqf8ehku.fsf@ebiederm.dsl.xmission.com>

Eric W. Biederman wrote:
> Ben Greear <greearb@candelatech.com> writes:
> 
>> Patrick McHardy wrote:
>>> Eric W. Biederman wrote:
>>>> For the macvlan code do we need to do anything special if we transmit
>>>> to a mac we would normally receive?  Another unicast mac of the same
>>>> nic for example.
>>> That doesn't happen under normal circumstances. I don't believe
>>> it would work.
>> Assuming you mean you want to send between two mac-vlans on the same physical
>> nic...
>>
>> This can work if your mac-vlans are on different subnets and you are
>> routing between them (and if you have my send-to-self patch or have
>> another way to let a system send packets to itself).
> 
> Ok.  I didn't know if you could trigger this case without without
> having then endpoints in separate namespaces.  I was suspecting
> the routing code would realize what we were doing realize the
> route is local and route through lo.

The routing code will short-circuit by default.  It takes quite
a bit of effort to make them _not_ short circuit..that is what I
was talking about.  Mac-vlans will be just like any
other ethernet nics as far as routing goes.

> 
>> A normal ethernet switch will NOT turn a packet around on the same
>> interface it was received, so that is why you must have them on different
>> subnets and have a router in between.
> 
> Yes.  That is essentially the configuration I was wondering about.
> 
>> For sending directly to yourself, something like the 'veth' driver
>> is probably more useful.
> 
> True.  And I think it has a place.  However the common case with
> the tunnel devices is to just hook them all up to an ethernet
> bridge as well as a real ethernet device.
> 
> The far ends of the ethernet tunnels are dropped into different namespaces.
> 
> Which gets a very similar effect to the mac vlan code.
> 
> I'm just wondering if I can not setup an ethernet tunnel device
> when my primary purpose is to talk to the outside world, but occasionally
> want a little in the box traffic.

mac-vlans should work on veth devices just fine, and the veths will also
short-circuit route (at least if they are in the same namespace).

I'm not sure I understand what you are trying to do..but in general
both veth and mac-vlans should act like ethernet nics..so if you can
find some way that does _not_ hold, please let us know.

Thanks,
Ben


> 
> Eric
> -
> 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


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


  reply	other threads:[~2007-06-22 12:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-20 18:00 [RFC NET 00/02]: Secondary unicast address support Patrick McHardy
2007-06-20 18:00 ` [RFC NET 01/02]: " Patrick McHardy
2007-06-20 18:00 ` [RFC E1000 02/02]: " Patrick McHardy
2007-06-21 19:08 ` [RFC NET 00/02]: " Eric W. Biederman
2007-06-21 19:13   ` David Miller
2007-06-21 21:11     ` Caitlin Bestler
2007-06-21 19:13   ` Patrick McHardy
2007-06-21 20:31     ` Eric W. Biederman
2007-06-22  0:08       ` Patrick McHardy
2007-06-22  3:30         ` Ben Greear
2007-06-22  4:30           ` Eric W. Biederman
2007-06-22 12:08             ` Ben Greear [this message]
2007-06-22  1:56       ` Patrick McHardy
2007-06-22  3:21         ` Ben Greear
2007-06-22 11:36           ` Patrick McHardy

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=467BBBAE.40901@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=jeff@garzik.org \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@linux-foundation.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 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.