Re: MAC address issue

[David Young <dyoung%pobox.com@localhost>]

On Sat, Jan 19, 2008 at 11:18:41AM +0100, Ignatios Souvatzis wrote:
> On Fri, Jan 18, 2008 at 10:54:09PM -0800, jonathan%dsg.stanford.edu@localhost 
> wrote:
> > 
> > In message <20080118170120.GL1868%che.ojctech.com@localhost>David Young 
> > writes
> > 
> > >Let us put aside lladdr preferences, and use only the 'active' flag,
> > >instead.  Only one lladdr may be active at a time, deleting an active
> > >lladdr is not allowed (EBUSY), and setting a second lladdr to 'active'
> > >clears the 'active' state on every other lladdr.
> > 
> > 
> > Huh? What about hardware capable of, and IETF protocols which call
> > for, multiple active link-level addresses on a single interface??
> 
> Do those exist? I wasn't aware of that. Can you name one, so that
> we can consider the exact interface model used? E.g.

The ethernet built into the Atheros SoC has the capability.  Judging by
tlp_filter_setup(), the DEC Tulip does, too.  I'm sure there are others.

> > Are you proposing a user/kernel API which makes those ~impossible?
> 
> I'm actually needing this, because the per-Macaddr-limit in German
> Telekom's PPPoE routers is set to 1, and I'm using two providers
> simultaneously. I'm emulating this using bridge(4) and tap(4). I
> guess this is not desirable in the high performance case.

When a NIC's address filter has more than one slot for unicast addresses,
we should take advantage when that will improve bridge(4) performance.
We should also take advantage of hardware VLAN support such as the
ADM5120 SoC provides.  To get there, we need for bridge(4) and member
interfaces to pass messages indicating when interfaces go up & down, when
they assign new lladdrs, they join & leave multicast groups, they join &
leave the bridge, et cetera.

I really prefer to treat such optimizations in a separate proposal.
They seem orthogonal to the problem at hand.

> But wouldn't sub-interfaces (similar to what Solaris does) be easier
> to use? 

IMO, sub-interfaces are an abomination. :-) Wherever I have dealt
with a system that has "child" interfaces hanging off of a "parent"
interface, it seems either that the parent has become a vestigial or a
second-class interface, or that the parent->child relationship is tenuous:
one interface may as well be a peer/sibling of the other.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933 ext 24