Hi Ben,

On Sun, 08 Mar 2009 09:54:02 -0700
Ben Greear <greearb@candelatech.com> wrote:

quoted text
> Mark Smith wrote:
> > On Sat, 07 Mar 2009 10:13:16 -0800
> > ebiederm@xmission.com (Eric W. Biederman) wrote:
> >
> >   
> >> Ben Greear <greearb@candelatech.com> writes:
> >>
> >>     
> >>> Mark Smith wrote:
> >>>       
> >>>> Hi,
> >>>>
> >>>> Ben said,
> >>>>   
> >>>>         
> >>>>> I wouldn't deny sending with wrong source mac..ethernet interfaces can do
> >>>>> this,
> >>>>> and mac-vlan should look as much like ethernet is possible.
> >>>>>     
> >>>>>           
> >>>> I agree, however there's further things that mac-vlans aren't
> >>>> currently doing as virtual ethernet interfaces that real ones do.
> >>>> Unicast ethernet traffic sent out one mac-vlan interface with a
> >>>> destination address of another mac-vlan interface on the same host
> >>>> isn't delivered. mac-vlan interfaces, even though they're conceptually
> >>>> located on the same ethernet segment, are currently isolated from each
> >>>> other for unicast traffic.
> >>>>   

<snip for brevity>

quoted text
> > So then, my question is, what are mac-vlans for i.e. what is their
> > common use case?
> >
> > The problem I was trying to solve was to run up an arbitrary
> > number of PPPoE servers on a single LAN segment. I could do that
> > with physical interfaces, however I only had a maximum of 4 ethernet
> > interfaces in the host. Using mac-vlans seemed to be the obvious way to
> > eliminate the physical constraints of the host. I did expect though that
> > the mac-vlan virtual interfaces would work the same real interfaces, so
> > I was expecting that I could bridge them and that unicast traffic
> > between them would work.
> >   
> Doesn't pppoe always talk to an upstream box (the pppoe-server)?  If 
> that is so,
> why would the local mac-vlans ever need to communicate directly to 
> eachother?
> 

That's true, and in that sense, I was 'lucky' that I didn't encounter
this limitation in my test environment, but it was only because of my
test environment (i.e. protocol), didn't require unicast communication
between the mac-vlan interfaces on the same host. If I'd been testing
some other protocol that did require unicast communications between
macvlan interfaces, I would have been scratching my head, wondering
why things weren't working correctly, and may have spent a lot of time
thinking that my test setup was the thing that had failed, rather than
being caused by missing functionality that I assumed was there.

I think the "truth in advertising" or "principle of least surprise"
should hold - if mac-vlans are to be seen by their users as virtual
ethernet network cards, then they should function no differently to real
network cards, or alternatively, if they aren't going to function that
way, there needs to be quite obvious documentation somewhere (other
than this thread) about their limitations, and a corresponding
recommendation that you use bridged veth interfaces if you can't afford
those limitations. 

quoted text
> We've used pppoe on mac-vlans, and it *seemed* to work, but perhaps we 
> were missing
> something...
> 
> I think they might also be useful for adding a more realistic 'virtual 
> ip' to an interface, perhaps
> for interesting routing setups.
> 
> Thanks,
> Ben
> 
> -- 
> Ben Greear <greearb@candelatech.com> 
> Candela Technologies Inc  http://www.candelatech.com
> 
> 
--
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