Interesting new spam technique - getting a lot more popular.
Matt Buford
matt at overloaded.net
Wed Jun 14 23:03:10 UTC 2006
As a hoster with many customers on large shared VLANs perhaps I can add a
bit...
"Richard A Steenbergen" <ras at e-gerbil.net> wrote:
> 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.
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.
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.
> Incase you've never seen hoster configs, they generally look a little
> something like this:
>
> ip address 1.1.1.1 255.255.255.0
> ip address 1.1.2.1 255.255.255.0 secondary
> ip address 1.1.3.1 255.255.255.0 secondary
> ip address 1.1.4.1 255.255.255.0 secondary
> ip address 1.1.5.1 255.255.255.0 secondary
Yep, the ip address section typically looks like that, plus all the usual
stuff like GLBP, policy routing, etc...
> 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.
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.
> 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? :)
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...
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.
More information about the NANOG
mailing list