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