Some ciscos can do this as well (recent IOS). IP unnumbered and static routes towards vlan interfaces means you can put customers in their own vlan and still have them be part of a larger IP subnet spanning several vlans.
Since it was Extreme that filed RFC3069 I seriously doubt Cisco will ever implement it straight up.
Some ciscos can do this as well (recent IOS). IP unnumbered and static
routes towards vlan interfaces means you can put customers in their own
vlan and still have them be part of a larger IP subnet spanning several
vlans.
Since it was Extreme that filed RFC3069 I seriously doubt Cisco will
ever
implement it straight up.
I don't think it was Extreme that filed it, or at least they didn't
write it. It was the good folks at Qwest engineering who came up with
the idea, which was implemented (for some low value of implemented) by
Extreme. The authors had moved on by the time the RFC was published,
but they were certainly Qwesties (and probably CSN before that). I
*think* the same idea was floated to Cisco at the same time; their PVLAN
was offered in beta not long after Extreme moved super/sub-VLANs into
public release.
Unfortunately for those of us who had to actually implement said
abomination, it didn't quite work as well as promised. In fact I was
just trying to decide which was more painful, taking over a hosting
network with 90% of their hosts in one VLAN (VLAN2, they asked for free
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.
Jeremiah
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.
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
I hear this line of thinking often, but to me it sounds like bulls^X^X^X^X^X... um, "folklore". When our customers/salesdroids ask for it, I (politely) refuse. We acquired a hosting operation in 2004 that had blown a full /20 on literally a rack and a half of hardware, and I was aghast at what a nightmare that was. We're still untangling that mess.
Anyway, if somebody could enlighten me to definitive proof, or stated policy by Goo... er "search engines", that confirms this "search engine result optimization by blatant abuse of IP addresses" I'd appreciate it. I for one believe it is bunk dreamt up by somebody trying to sell something. If it is true though, I would have to say that it "is evil" and I would imagine many folks here (and not to mention ARIN, RIPE, et al) would agree.
--chuck
Is it true? I don't know, but a quick google search returns everyone talking about it as if it is true.
If it is true, is it sort of gaming the system? Yes, I suppose so.
Instead of pulling 1 block of 30 from your IP allocation tool, you have to pull 30 blocks of 1. This is more administrative work and I can completely understand why someone might refuse to do it just because it is a silly hassle.
But how could this possibly be IP abuse or evil (except perhaps in the eyes of the search engines)? What difference does it make to ARIN if I give a customer 30 IPs from a single /24 or 30 IPs from 30 different /24s? It makes little difference to me and is trivial to do in my topology since I already have 30+ /24s on the interface. So, I do so simply because I can't think of any reason not to. It is slightly more work to document the IPs since they each have to be put into my database instead of a single range, but this is handled by the server people.
I think you're 100% right. AFAIK it *is* just folklore. But
unfortunately, SEO's have to make their money somehow and all too often
it seems they make their money making up crap like this. Then all the
sheep that lap up every word that comes out of their favorite SEO's
mouth start demanding whatever the latest craze in SEO is. This creates
opposing pressures between the need to maintain a secure, reliable
infrastructure and your salesdroids begging for whatever the clients are
requesting. It's a tough balance to strike...best practices are all
well and good, but rigid inflexibility is unlikely to win you many
clients. (Especially when you consider that the vast majority of the
webhosting clients out there couldn't care less about security until it
affects them.) It's a shame, but the reality is I think market forces
pressure most of us into making technology decisions against our better
judgement from time to time.
So does it surprise me in the least that there are datacenters out there
running hundreds of customers out of one giant subnet? No, not one bit.
Will it eventually come back to bite them, causing countless hours and
$$$ to clean up the situation when it does? Inevitably. But I don't
believe it's done out of ignorance in most cases. I honestly can't
believe there is that much rampant incompetence out there. To me it's
more likely to be a bunch of network geeks *who know better* kowtowing
to pressures from management to deliver what customers are demanding,
security risks be damned.
But maybe that just highlights a niche market just waiting to be
exploited. I imagine there's money to be made marketing security
devices that allow for the convenience of being able to assign IP's on a
one-by-one basis while still protecting against the various nonsense
that can create, all with an easily manageable interface. Doesn't seem
to far-fetched. The tools and technology already exist, just a matter
of putting them all together and making it easy.
Andrew Cruse
That's the way we are using now... works very well...
With a subscriber management equipment, you can put each customer in
their own vlan. Each vlan is bound to a subscriber which has its ip
addresses. When more addresses are requested, just add some to the
subscriber.
Thanks,
Richard
But how could this possibly be IP abuse or evil (except perhaps in the eyes of the search engines)? What difference does it make to ARIN if I give a customer 30 IPs from a single /24 or 30 IPs from 30 different /24s?
How is that customer using those IPs? If the IPs are on a single server used for webhosting, it is in violation of ARIN's IPv4 allocation policy.
In every case where we've seen people asking for outrageous amounts of IP space for webhosting it is either because:
* They are trying to game the search engines due to this pervasive folklore.
or
* They lacked sufficient clue to grok name-based virtual hosting.
The latter can be fixed quite easily. I wish I had some way of debunking the former.
It makes little difference to me and is trivial to do in my topology since I already have 30+ /24s on the interface.
Just becasue you can, doesn't mean that you should. But hey, your network, your rules I guess.
It is slightly more work to document the IPs since they each have to be put into my database instead of a single range, but this is handled by the server people.
I prefer to have our 'server people' and our 'network people' working together without annoying each other too much.
While my use of the word "evil" was a smirking poke at the dominant search engine, I don't really think this behavior is malice so much as disregard for the ecosystem. We've done our best to be very conservative in our IP allocations to our customers, if nothing else to remain good neighbors to the rest of the Network.
I wasn't even aware of this bizarre SEO/IP scheme until we made that acquisition two years ago. Now I look around and see operations a fraction of our size consuming large allocations for small installations. The pursuit of a page rank seems a pretty selfish reason to consume a limited resource.
--chuck
Once upon a time, chuck goolsbee <chucklist@forest.net> said:
* They lacked sufficient clue to grok name-based virtual hosting.
Name-based virtual hosting is not a cure-all. Think about SSL and
anonymous FTP uploads for starters.
I don't think it was Extreme that filed it, or at least they didn't
write it. It was the good folks at Qwest engineering who came up with
the idea, which was implemented (for some low value of implemented) by
Extreme. The authors had moved on by the time the RFC was published,
but they were certainly Qwesties (and probably CSN before that).
Nope, not at all CSN..
I
*think* the same idea was floated to Cisco at the same time; their PVLAN
was offered in beta not long after Extreme moved super/sub-VLANs into
public release.
Yep, pointer here, for folks interested in the current state of that
work within the IETF:
http://www.ietf.org/internet-drafts/draft-sanjib-private-vlan-05.txt
Unfortunately for those of us who had to actually implement said
abomination, it didn't quite work as well as promised. In fact I was
just trying to decide which was more painful, taking over a hosting
network with 90% of their hosts in one VLAN (VLAN2, they asked for free
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.
Indeed, as there's a discernible gap there from concept to implementation,
implementation to network engineering, beta/EFT, and from network
engineering & beta/EFT to deployment & operationalizing any such
technology. If you disregard any of these phases, for whatever reason,
it'll likely to come back to bite you.
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.
As with any new technology, some amount of education is often
required when change occurs. In this case, a reasonable response
would be to first ask if anything was broken as a result, and if not,
then to explain the benefits such a service model provides from
a billing, Internet address conservation and security perspective.
Customers hating something simply because they liked and are no
longer seeing broadcast traffic seems a bit intractable to me. This
is the perfect example where a small amount of education can go
a long way.
Now, if something is broken, OTOH, that's different.
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.
Indeed, and this is clearly an implementation bug, and potentially,
a security vulnerability, if an attacker could determine how to elicit
such a behavior.
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.
Again, this is why it's important to be able to clearly articulate
such a problem, and why phases 2 & 3 above are so critical,
and why each new application of such a mechanism requires
revisiting the entire process.
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.
IIRC, the "enterprise hosting solution of an RBOC" wasn't the
intended initial application, though I do suspect such a solution
would provide considerable advantages in a deployment such as
that - again, assuming it was engineered and operationalized
appropriately.
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.
While I'm not sure about any of the deployment details beyond the
initial problem set, which falls pretty much squarely within your "that
fits pretty well" category, I would be interested in hearing what your
solution to such a problem is? Certainly, some amount of engineering
needs to be applied, and customers that justify their own IP subnets
should be handled as such, but in this day and age, I'd hope that
most folks separate customers into different Link layer broadcast
domains, and employ some bit of cognition WRT Internet address
space conversation.
-danny