North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Interesting new spam technique - getting a lot more popular.
As a hoster with many customers on large shared VLANs perhaps I can add a bit...
"Richard A Steenbergen" <email@example.com> wrote:
I'm not sure documentation is really THAT much of it. I mean, we have subnets behind firewalls and manage subnet allocations there. It is a hassle compared to the simplicity of large shared VLANs, but we're certainly capable of tracking it. The problem is more for the customers with only a few servers or even just a single server. They tend to have no idea about future IP requirements. Ask any hoster CEO who isn't a hands-on networking person what his expectations are for near-future IPs and he'll generally give you some wild answer like "up to 50,000" because he wouldn't be CEO if he didn't expect his business to explode overnight. :) In general, customers with larger firewalled solutions (and thus a private subnet and private behind-firewall VLAN) tend to have a better handle on this.Simple: Subnets are hard, customers are stupid, and ARIN is not exactly a hosters best friend. When a hosting customer asks for 5 IPs today and 25 IPs tomorrow, it is infinitely easier for the hosting folks to just slap them into /24s and say "ok uhm you are now .69-.94" than to try and explain subnets, cidr, reserving IP space in cidr sized blocks etc to the customer. Hosters are also generally under-equipped in the paperwork and detailed documentation department, so they tend to run their IP allocations into the ground while attempting to explain their need for more space. CIDR allocations are "wasteful" to them, especially when a customer needs to expand from 30 IPs to 35 IPs and crosses a new boundry.
Also, have a requirement that I must be able to accept a customer server plugging into my network anywhere. If a customer buys 1 server today, then another server 6 months from now, that second server may be on a different floor of the datacenter, or even a few miles away in a nearby datacenter. A few months after setting these servers up, the customer might want to migrate a single IP from one server to another. So, since I must carry every VLAN everywhere, that can get tricky (not impossible, but messy) when you have thousands of customers, with say 2-5 VLANs each. With MSTP the spanning tree limit of a 6500 is 50,000 logical interfaces (ports*vlans). At 5000 VLANs that would mean I'm only allowed to use 10 all-vlan-carrying tagged ports on a 6500, which wouldn't make for a very efficient core.
There is also strong demand among web hosting customers to scatter sites across multiple /24's due to search engine optimization. This is trivial to satisfy in the large shared subnet model.
Finally, as we all know, there is the efficiency issue. Of course, as long as ARIN lets people get away with it, it isn't that big of a deal (other than being good netizens) so I won't go into this one much.
Yep, the ip address section typically looks like that, plus all the usual stuff like GLBP, policy routing, etc...Incase you've never seen hoster configs, they generally look a little something like this: ip address 18.104.22.168 255.255.255.0 ip address 22.214.171.124 255.255.255.0 secondary ip address 126.96.36.199 255.255.255.0 secondary ip address 188.8.131.52 255.255.255.0 secondary ip address 184.108.40.206 255.255.255.0 secondary
I can't speak for other hosters, but for me it is more about different customer bases (some customers have no idea what their requirements are) and different business requirements. I think we are quite aware of the issues either way, and know exactly what the advantages and disadvantages are. If anything, I'd say we're very much experts in the field of large layer 2 networks. Oh, and there are no chains of 3548's here. All 6500s, each one directly attached to at least 2 cores.Anything else is quite honestly beyond 99% of hosters out there, they're still blissfully calling these things "class c's". I've seen some truly godawful thins configured by hosters, like chains of 3548s all linking back to a single router interface in ways you can't even imagine.
We use pvlans successfully (though it has been a long bug-ridden journey). This mitigates just about all of the disadvantages of the big shared VLAN while maintaining all the advantages. The one disadvantage that pvlans does not mitigate is unused IPs. Thus, I have been lobbying Cisco since 2002 to fix all the pvlan bugs (almost done there!) and for the ability to add bulk static arps and stop even supporting dynamic ARPing for customer IPs (no real progress on this front). For now we have to settle with detecting unused address hijacks. Oh, and for those of you out there saying static arps are already implemented, you try putting 30,000+ in your config and see what happens...If you made it dirt simple for them they would probably be doing something better (I usually point folks who ask to pvlans, then take the opportunity to make a hasty retreat while they are distracted), but otherwise they don't see the benefit in it. Why bother configuring your router better when you can just send your $5/hr monkey over with a redhat cd and have them reinstall, right? :)
As for monkeys, there is certainly a business case for simplifying. If I can do some hard back-end planning and setup one time to make the future everyday tasks easier, I see that as an advantage. People ask how do I move a single secondary IP between servers that got set up in different datacenters in the same city. I respond just change them on the servers, click "clear arp" on the web interface, see it ping, then update the documentation to record the change. If a monkey can figure out how to handle adds/moves/changes without danger of breaking anything else on the network then I see that as doing something right. Not everything should require a network engineer to accomplish.
Oh, and you will only hear me say "class C" in cases where I am responding to a customer (or salesperson) who asked about a "class c". If they use the terminology, I'll use it back at them to avoid confusion.