link layer aliases (on ethernet, at least)
Daniel Hagerty
than one ethernet address. Doing this seems requisite to a reasonable
vrrp or hsrp implementation.
I've got a roughly functioning first draft, but I'm running into
some questions of what the user interface for it all should look like.
Is there any interest in me getting this code to a reasonable
state? In that case, there are API and probably some implementation
questions to work out.
I'll also note that someone was asking questions about setting
ethernet addresses from userland, which has some overlap with the code
I'm presently smashing on.
In the first pass, I used SIOC{A,D}LIFADDR for pushing sockaddr_dl
between the kernel and userland through a socket(AF_LINK,SOCK_RAW),
which seems to be a reasonable semantic match my needs. I also
implemented a quick SIOCGLIFADDR as a generic get link layer addr
operation. However, there doesn't seem to be a SIOCSLIFADDR however,
which seems what would be needed for the set operation. Am I missing
something? There's SIOCSLIFPHYADDR, but that doesn't seem correct
given the physical it's talking about.
More open ended questions revolve around the interactions with
neighbor discovery protocols like arp and v6nd; I have no clue what
the API should look like ("my UI is the debugger" was easy enough).
There's also a garbage collection issue hiding in here; what's the
preferred behavior when the user does something like deleting a link
layer alias that a neighbor discovery protocol is holding a reference
to? Saying no, or deleting these for the user?
The draft code assumes that promiscuous mode is required to do
this; this isn't actually true on all cards. I have the vague idea of
something like ETHERCAP_UNICAST_RXFILTER or some such but haven't
actually gotten here yet.
This code will doubtless have some interactions with at least vlan
and bridging code; probably more. I don't see any outrageous issues,
but I haven't done much looking inside yet.
Some pieces of userland will raise their eyebrows at the idea of
more than one AF_LINK address being returned from things like
SIOCGIFCONF. dhclient brought itself to my attention pretty rapidly.
Michael Richardson
>>>>> "Daniel" == Daniel Hagerty <h...@linnaean.org> writes:
Daniel> I've been twiddling with getting my netbsd box to listen on more
Daniel> than one ethernet address. Doing this seems requisite to a
Daniel> reasonable vrrp or hsrp implementation.
Sure.
Daniel> In the first pass, I used SIOC{A,D}LIFADDR for pushing
Daniel> sockaddr_dl between the kernel and userland through a
Daniel> socket(AF_LINK,SOCK_RAW), which seems to be a reasonable semantic
Daniel> match my needs. I also implemented a quick SIOCGLIFADDR as a
Daniel> generic get link layer addr operation. However, there doesn't
Daniel> seem to be a SIOCSLIFADDR however, which seems what would be
Daniel> needed for the set operation. Am I missing something? There's
Daniel> SIOCSLIFPHYADDR, but that doesn't seem correct given the physical
Daniel> it's talking about.
So, you are adding ethernet aliases, in a manner similar to how we do
IP aliases - as a list of addresses on an interface. (As opposed to how
Linux and some other OSes do IP aliases, with unique, virtual interfaces
per alias). I say this because it might be that multiple ethernet addresses
would be better handled with vlan-like interfaces.
Daniel> deleting a link layer alias that a neighbor discovery protocol is
Daniel> holding a reference to? Saying no, or deleting these for the
Daniel> user?
I'd say you delete them.
That's what happens when I ifconfig an interface down, or remove the
cardbus adapter.
Daniel> The draft code assumes that promiscuous mode is required to do
Daniel> this; this isn't actually true on all cards. I have the vague
Daniel> idea of something like ETHERCAP_UNICAST_RXFILTER or some such but
Daniel> haven't actually gotten here yet.
Some cards have multiple MAC address filters, and on others, you can
use the multicast filters to do the right thing.
Daniel> This code will doubtless have some interactions with at least
Daniel> vlan and bridging code; probably more. I don't see any
Daniel> outrageous issues, but I haven't done much looking inside yet.
I'd say that new ethernet addresses should *be* a kind of bridge :-)
You bridge the frames to the new device.
Daniel> Some pieces of userland will raise their eyebrows at the idea of
Daniel> more than one AF_LINK address being returned from things like
Daniel> SIOCGIFCONF. dhclient brought itself to my attention pretty
Daniel> rapidly.
Yes.
One reason to have multiple interfaces might so that one can run dhclient
on some, but not all of the interfaces.
] Out and about in Ottawa. hmmm... beer. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat
iQCVAwUBPyaNeIqHRg3pndX9AQEPwgP/brZlM9/CulQD7dlvUKe8Bcj0QiEWq1Ci
wlhk8R/jL239fWV4bfyVW3zx2q29kH/qW2Q9/WBtuCS8T+Ccizgce2gTvZsySv27
7eId+NeFR9/WVF7NG0CoQDbloloQZsycJq9tPEvPMcQEW+uDGzdkeZ37fQXDygKf
qf6r8s1FzPM=
=qIsz
-----END PGP SIGNATURE-----
Daniel Hagerty
> So, you are adding ethernet aliases, in a manner similar to how we do
> IP aliases - as a list of addresses on an interface. (As opposed to how
> Linux and some other OSes do IP aliases, with unique, virtual interfaces
> per alias). I say this because it might be that multiple ethernet addresses
> would be better handled with vlan-like interfaces.
Yes, like ip aliases. I'm not so sure the "whole other ifnet"
approach will work for what I have in mind; there are a bunch of
ambiguity cases that arise. It doesn't strike me as terribly
dis-similar to using two physical ethernet cards attached to the same
link layer.
The big issues seem to revolve around routing; how and why do I
pick one interface over the other?
This would be a big problem for ??rp implementations; typically,
the system has a management ip address/burned in mac, and advertises
services attached to a service ip address on the same network, but
with a virtual link layer name associated with that service ip
address. The ??rp implementation only transmits a select few frames
using the virtual address; namely arp replies and ??rp announcements
for the sake of programming learning bridge mac tables.
Disregarding that issue, I see no reason why a seperate ifnet
isn't tractible. It's probably even doable to have both; the ifnet
based version seems to have similar requisites to having them within
one. I'll certainly keep the approach in mind.
> I'd say you delete them.
> That's what happens when I ifconfig an interface down, or remove the
> cardbus adapter.
In a proper implementation, gc may be more difficult than I think;
why does the ethernet layer know about all of these random protocol's
neighbor discovery mechanics? I'll see what my actual issues are soon
when I start trying to make arp handle what I need better.
> Some cards have multiple MAC address filters, and on others, you can
> use the multicast filters to do the right thing.
As I've seen; the exact mechanics strike me as a detail that can
be hidden by the driver layer (although I'm thinking that questions
like the perfectness of the filter will be handled stupidly, that is,
assume you must always check dest addresses).
> I'd say that new ethernet addresses should *be* a kind of bridge :-)
> You bridge the frames to the new device.
You're thinking of a second ethernet address as a full first class
citizen it seems. I'm not (at least not until you suggested it); it
isn't needed for ??rp.
> Yes.
> One reason to have multiple interfaces might so that one can run dhclient
> on some, but not all of the interfaces.
There are ways in which that brings up ambiguity questions again,
but depending on what you're actually trying to do, I can dimly
imagine ways in which the capability may be handy. I just hope I
don't run into the real world situation; I'm rarely amused when that
happens.
Michael Richardson
>>>>> "Daniel" == Daniel Hagerty <h...@linnaean.org> writes:
Daniel> You're thinking of a second ethernet address as a full first
Daniel> class citizen it seems. I'm not (at least not until you
Daniel> suggested it); it isn't needed for ??rp.
I agree that ??rp doesn't need it.
It might even be more confusing for it.
But, it does make it useful for people who might want to attach
experimental or emulated (vmware, user-mode-bsd, etc.) protocol stacks
to a different network than the primary system.
Daniel> There are ways in which that brings up ambiguity questions
Daniel> again,
Daniel> but depending on what you're actually trying to do, I can dimly
Daniel> imagine ways in which the capability may be handy. I just hope I
Daniel> don't run into the real world situation; I'm rarely amused when
Daniel> that happens.
I'd see this as primarily being useful in experiments myself.
] Out and about in Ottawa. hmmm... beer. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat
iQCVAwUBPybVOIqHRg3pndX9AQExeQQA3VlDlLIcQ4u34Xr9zVW8piDZoRwRrl4Z
L7wDYEzmffs4fqi6bFgXAd51L2m1/idA1F+znWa1vK4znPDxe1eUixFTslcKA4bs
FVoCuPx9QCjz3aULUzlJ72pAvDDescI8FAEg647AYdvZZnq89c2630fOUkQw2yH5
+6i0rWUd8JU=
=7t39
-----END PGP SIGNATURE-----
Hideki ONO
I implemented it with the "whole other ifnet" approach for my vrrp6
implementation. It has been committed to KAME tree.
http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/net/if_vrrp.c
> Yes, like ip aliases. I'm not so sure the "whole other ifnet"
> approach will work for what I have in mind; there are a bunch of
> ambiguity cases that arise. It doesn't strike me as terribly
> dis-similar to using two physical ethernet cards attached to the same
> link layer.
>
> The big issues seem to revolve around routing; how and why do I
> pick one interface over the other?
>
> This would be a big problem for ??rp implementations; typically,
> the system has a management ip address/burned in mac, and advertises
> services attached to a service ip address on the same network, but
> with a virtual link layer name associated with that service ip
> address. The ??rp implementation only transmits a select few frames
> using the virtual address; namely arp replies and ??rp announcements
> for the sake of programming learning bridge mac tables.
>
>
> Disregarding that issue, I see no reason why a seperate ifnet
> isn't tractible. It's probably even doable to have both; the ifnet
> based version seems to have similar requisites to having them within
> one. I'll certainly keep the approach in mind.
--
Hideki ONO
Daniel Hagerty
> implementation. It has been committed to KAME tree.
Cool.
How do you deal with "multiple interfaces attached to the same
layer 3 network" routing problem?
Daniel Hagerty
> layer 3 network" routing problem?
Oh, I see. Just don't tell routing about it. This makes life
much simpler than how I was proceeding was going.
So I suppose this changes my focus; I haven't gotten to fiddling
with ethernet receivers yet. I'll play with slashing up something
between the ethernet interface drivers and the ethersubr layer. If I
come up with anything, I'll say something here.
Jonathan Stone
Just out of curiosity, whats the Intellectual Property status of vrrp6?
Is vrrp6 (or even vrrpv2) committable to the NetBSD tree?
Daniel Hagerty
> Just out of curiosity, whats the Intellectual Property status of vrrp6?
>
> Is vrrp6 (or even vrrpv2) committable to the NetBSD tree?
I believe cisco holds patents on the concept behind using a
virtual mac address shared between multiple systems to provide a
single service. Don't quote me on the exact language or consequences,
but I believe the reasonably binary, correct statement is "yes, there
are some intellectual property issues behind vrrp".
der Mouse
> mac address shared between multiple systems to provide a single
> service.
For what it may be worth, I saw a presentation from Auspex (a past
workplace of mine was a customer of theirs at the time) that described
one of their hot-failover setups as using a multicast MAC address as
the MAC address for a server.
I don't know whether they licensed, or decided cisco's patent was
invalid and told them to take a long walk off a short pier, or this was
before the patent was issued, or what. Perhaps even the description
was mistaken; I never actually played with it myself, only heard/saw it
described.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B