Re: vlans and netbsd-current

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 09 Jun 2014 02:45:19 +1000
    From:        Darren Reed <darrenr%netbsd.org@localhost>
    Message-ID:  <5394931F.3020201%netbsd.org@localhost>

  | I think you're wrong here.

No, Thor was right.

  | For example, what if I were to create two chroot environments on my
  | NetBSD box and I wanted to use a dedicated NIC and IP address for each?
  | And if I want each NIC to be its own vlan interface?

Doesn't work the way you're thinking it might, even if it was a rational
think to do ... all chroot does is modify filesystem naming.  Everything else
in the system is untouched, including internace (and all networking) access
(which is one reason why attempting to use chroot as a security measure
is not nearly as effective as people think it is.)

  | Or what if I want to do virtual networking inside of NetBSD and create
  | a vwire between two vlan interfaces?

vlans are the wrong software interface for that, use taps & bridge.

  | Or connect both vlan interfaces to a virtual switch inside the kernel?

I have absolutely no idea what that would even mean, it certainly
doesn't seem to be useful.

As I said in my non-list reply, none of this is relevant to your original
problem with ntp, or the IPv6 LL autoconfig issue.

  | FWIW, Solaris does this by
  | Neither of these depend on special hardware.

It does, most NIC cards (particularly older ones) don't allow multiple
MAC addresses (ignoring vlans temporarily, the demand for that has only
really been created by the use of virtual systems).  And while promisc mode
kind of works, it means filtering every packet in software - and while you
might believe that switches have already filtered out all the noise, they don't,
you still get everything that's transmitted to any unknown MAC addr (unknown
by the switch, which often includes a lot of multicast).

vlans were never intended for the kinds of things you're proposing they be
used for, they weren't designed to support them, and it is no surprise
that things don't work they way you hope they might.   This part of the
system shoudl be left alone (just fix whatever the issue is with NTP, and
make the IPv6 startup rational.)

kre