Hello,
On Mon, Jun 05, 2000 at 05:35:33AM -0700, Mitchell Blank Jr wrote:
[snip]
> Now, using this form of analysis, at what level is an ethernet VLAN?
> Well, what can a VLAN do? Well, it can implement the SIOC[GS]* ioctls
> (i.e. it can be taken up or down), it can keep a net_dev_stats,
> it can have entries in the ARP table (or AARP for that matter),
> it can participate in a bridge group (net_bridge_port->dev),
> it can report seperate statistics via SNMP (and thus should have
> its own dev->ifindex), it can want different settings in
> /proc/sys/net/ipv4/{neigh,conf}/DEV/, can have seperate IPv6
> networks with different autoconfiguration (see ipv6/addrconf.c),
> it could have IPX networks of different ipx_dlink_type's, we
> could want to bind an AF_PACKET socket to it (tcpdump, etc),
> we could want to make filtering or policy route decisions based
> on incoming VLAN, etc.
>
> In short, a VLAN can do just about anything a "real" ethernet interface
> can do - the only exceptions are that it probably shouldn't be split
> into another level of VLAN's (well, it could, but what other switch or
> OS would support such a thing? :-), and it needs to coordinate with the
[snip]
On Wed, Jun 07, 2000 at 04:59:36AM -0700, Mitchell Blank Jr wrote:
[snip]
> OK, explain how. I've enumerated a dozen or more places either in
> protocol support or in the user-kernel interface where the
> configuration or functionality depends on a named device per individual
> vlan. You keep ignoring them when I point them out, but they are
> still there. For instance, if both the VLANs are called "eth0", how
> do I set individual settings in /proc/sys/net/ipv4/conf/ for the two
> different VLANs? Or any of the other ones I pointed out - take your
> pick.
The majority of the enumerated points is just a matter of saving time for
adjusting user-level tools. The fact that something is able provide SNMP
statistic doesn't make it a network device, it's ridiculous!
Bridging between VLANs is not a problem, it's the question of who calls whom.
The logic determining VLAN id may call bridge procedures instead of vice
versa.
The only point that really needs to be addressed by kernel is /proc/sys/net/
tuning. Per-device IPv4 parameters (like redirect and forwarding policy) fit
into netfilter implementation well, but neighbour discovery parameters is a
more difficult point.
I'm not against VLANs or even against their implementation as netdevices.
But we should agree that it's an unnatural way to do things (from kernel
perspective, certainly), and we decide to do it this way only because we
follow the way of least resistance.
Regards
Andrey V.
Savochkin
|