On Thu, 15 Jun 2006, Mikael Abrahamsson wrote:
advice when they first started to attempt to migrate), or supporting super/sub-VLANs in an operational environment. Customers hated both, but at least they saw better performance once the hosting network was broken up per-customer VLANs.
Why would customers hate it? We have deployed super/subvlan for residential DSL (1 static IP address per residential user) and we have no complaints afaik. Yes, if you want more flexiblity to put any IP in any vlan in any or alike, the implementation is lacking. Customers hated it because of some very serious operational flaws. Some stuff was to be expected, like seeing broadcast traffic in all subs under a super-VLAN. Some stuff was truly flawed, like having some small percentage of packets leaking across sub-VLANs. Residential customers don't mind, and probably would never notice. Large corporate clients who are putting important servers in a hosting environment get rather concerned when you start seeing traffic (including cleartext login info) from their neighbors on their interfaces. Trying to convince your vendor that this (and other) flaw exists when you're the only client using it in production, and you're pushing several orders of magnitude more traffic than their labs, can be slightly frustrating. I personally felt that this was a solution in search of a problem. The enterprise hosting division on an RBOC was probably not the best place to deploy it. The current low-end hosting environment is a problem that fits pretty well, but based on my experience in that segment, there is a much bigger return on investment in paying a couple of engineers well enough to manage your VLAN allocations correctly and use existing (generally secondary market) hardware and tools. Jeremiah