North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Interesting new spam technique - getting a lot more popular.
- From: Matt Buford
- Date: Wed Jun 14 19:04:23 2006
As a hoster with many customers on large shared VLANs perhaps I can add a
"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 220.127.116.11 255.255.255.0
ip address 18.104.22.168 255.255.255.0 secondary
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
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
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.