Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ntpd doesn't plan well with vlans?
On Sun, Jun 08, 2014 at 10:56:50PM +1000, Darren Reed wrote:
>
> ... and of course the reason is a bit obvious:
>
> cas0: flags=8a63<UP,BROADCAST,NOTRAILERS,RUNNING,ALLMULTI,SIMPLEX>cas0:
> flags=8a63<MULTICAST> mtu 1500
> ec_capabilities=1<VLAN_MTU>
> ec_enabled=1<VLAN_MTU>
> address: 00:03:ba:34:a1:f5
This is a problem all of its own when stacking vlan on top. There
should be a way to get the underlying interface up without any IPv6
address lest a trivial switch misconfiguration sending untagged frames
to the port turn into a major security issue.
> inet6 fe80::203:baff:fe34:a1f5%cas0 prefixlen 64 scopeid 0x6
> vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> vlan: 200 parent: cas0
> address: 00:03:ba:34:a1:f5
> ...
> vlan1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> vlan: 201 parent: cas0
> address: 00:03:ba:34:a1:f5
>
> I've got three interfaces with the same MAC address!
This is correct. It is an error to connect two vlan interfaces on the
same underlying physical network to the same layer 2 network. So the
MAC address being the same can't cause problems.
In general (we don't get to pick and choose our underlying hardware like
Oracle does) there's no guarantee at all that we can support a different
MAC address on the same underlying physical MAC on a per-vlan basis, and
even where we can, sometimes it's with performance-destroying consequences.
Since you'd have to be ~crazy to configure things so this would be required
(for example, you'd have to build something like the following ASCII art,
which is nutz) I don't think it's worth any effort to support this:
+----+ +------+
|HOST|wm0====TRUNKED: VLANs X,Y====ge0/0|SWITCH|
+----+ | |
+-access, vlan X-ge0/1| |
| | |
| | |
+-access, vlan Y-ge0/2| |
+------+
(Yes, this picture has ge0/0
and ge0/1 on the switch
configured untagged for two
different vlans and plugged
into each other. I told you
it was nutz.)
> Reminds me of SunOS 4 days...!
Except there you had separate physical interfaces. Note that the
pathological case where you configure two vlan interfaces on the same
physical interface with the _same_ vlanif, simulating dual-attach to the
same physical LAN in the SunOS 4 case (which is where that was problematic)
is also insane -- it's easy enough to work out why.
> However there appear to be some other issues.
>
> First up, vlan interfaces are created without a link local IPv6 address
> assigned to them automatically...?
That's either a bug (in that it's inconsistent with what happens with the
physical interfaces and, worse, basically breaks link-local IPv6 if you
are running a normal, tagged-only config rather than a crazy, mixed
tagged/untagged one) or a feature if you think like I do that you should
have to do something to cause IPv6 to come up on the link to avoid
security issues (in which case it's the physical interface case that has
the bug).
On balance I'd say this is a bug and should be fixed. It has to be
consistent with what the physical interfaces do, right?
> Next is that all of the VLAN interfaces have the same MAC address as
> the parent. Could get interesting if you put more than one VLAN interface
> in the same VLAN!
See above. Can't see spending any effort to fix this.
Thor
Home |
Main Index |
Thread Index |
Old Index