Re: Interesting new spam technique - getting a lot more popular.
On Wed, Jun 14, 2006 at 04:46:31AM +, Christopher L. Morrow wrote: is it really that hard to make your foudry/extreme/cisco l3 switch vlan and subnet??? Is this a education thing or a laziness thing? Is this perhaps covered in a 'bcp' (not even an official IETF thing, just a hosters bible sort of thing) ? 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. 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 ... 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. 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? :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
WSJ: Big tech firms seeking power
Since power consumption was a topic at the last NANOG meeting. subscription required, or buy a copy of the Wall Street Journal from a newstand http://online.wsj.com/article/SB115016534015978590.html Surge in Internet Use, Energy Costs Has Big Tech Firms Seeking Power By KEVIN J. DELANEY and REBECCA SMITH Wall Street Journal June 13, 2006; Page A1 With both Internet services and power costs soaring, big technology companies are scouring the nation to secure enough of the cheap electricity that is vital to their growth. The search is being led by companies including Microsoft Corp., Yahoo Inc. and IAC/InterActiveCorp. Big Internet firms have been adding thousands of computer servers to data centers to handle heavy customer use of their services, including ambitious new offerings such as online video. [...]
RE: Interesting new spam technique - getting a lot more popular.
We end up with customers asking for more IPs too. We just add additional subnets to the interface, perhaps they started with a /30 but now need three more IPs, we just add an additional /29 to the interface leaving both blocks. It is not often that anything needs to be explained to the customer other than the correct subnet mask and gateway for the IPs. This makes our configs look like this for each customer vlan: ip address 2.2.2.9 255.255.255.252 ip address 3.3.2.129 255.255.255.224 secondary That being said, I know at least one of our transit customers does hosting exactly how you are describing. Coincidentally, this customer is also one of the customers that asked if we could give them a class C block. Using this strategy has never been a problem with ARIN for us, in fact I have applied for and received more space at intervals between 6 and 14 months for the last four years without any issue at all. John :) -Ursprüngliche Nachricht- Von: Richard A Steenbergen [mailto:[EMAIL PROTECTED] Gesendet: Wednesday, June 14, 2006 12:18 AM An: Christopher L. Morrow Cc: NANOG Betreff: Re: Interesting new spam technique - getting a lot more popular. On Wed, Jun 14, 2006 at 04:46:31AM +, Christopher L. Morrow wrote: is it really that hard to make your foudry/extreme/cisco l3 switch vlan and subnet??? Is this a education thing or a laziness thing? Is this perhaps covered in a 'bcp' (not even an official IETF thing, just a hosters bible sort of thing) ? 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. 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 ... 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. 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? :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: wrt joao damas' DLV talk on wednesday
actually, in a brilliant demonstration of fair use of copyrighted lyrics, paul was quoting directly from the song about alice's restaurant. well, actually, despite saying so, it's not much about the restaurant at all. and the restaurant is not called alice's restaurant, that's just the name of the song. And this whole discussion about DNSSEC and DLV reminds me of a bunch of 8 x 10 glossy photographs with the circles and arrows and a paragraph on the back of each one. Just another case of American blind justice I suppose. Has anyone ever considered trying to come up with a way that these crypto projects could be explained in plain English? I think a lot of the problem with adoption of DNSSEC stems from the fact that most people who might make a decision to use it, haven't got a clue what it is, how it works, or whether it even works at all. And it's not their fault that they don't understand. It's the fault of a technical community that likes to cloak its discussions in TLAs and twisted jargon. --Michael Dillon
Re: Interesting new spam technique - getting a lot more popular.
On Wed, 14 Jun 2006, Christopher L. Morrow wrote: | how about just mac security on switch ports? limit the number of mac's at | each port to 1 or some number 'valid' ? Hi, Just to be clear, simple L2 mac security doesn't help here. This attack (arp spoofing on a shared subnet) does not involve more than one mac per switch port. Nor are there any changes in switch port / mac associations. You need to watch at the higher layers (arp, ip). Cheers -- Chris Edwards, Glasgow University Computing Service
RE: Interesting new spam technique - getting a lot more popular.
is it really that hard to make your foudry/extreme/cisco l3 switch vlan and subnet??? Is this a education thing or a laziness thing? Is this perhaps covered in a 'bcp' (not even an official IETF thing, just a hosters bible sort of thing) ? Subnets aren't exactly good for address space usage. For Cisco kit, there are numerous nerd knobs that can be deployed that would seemingly mitigate this spam technique. In short, IP Source Guard (stop malicious people from using IP addresses that weren't assigned to them), Port Security (limit # of mac addresses on a given port to X) and Dynamic ARP Inspection (discard bogus arp packets). Combined with things like Private VLANs (allow different customers to share the same subnet but restrict them being able to talk/see one another), there are ways of securing things. Of course, just like everything its up to folks to deploy them. Many of these knobs aren't safe or practical for default settings. I'm sure other vendors have similar features also. Yes, these have been presented on numerous times within Cisco forums (e.g. Networkers) as best practice are typically very well attended. Not necessarily by the all the folk that need to, I guess. :( cheers, lincoln.
Re: Interesting new spam technique - getting a lot more popular.
On Wed, 2006-06-14 at 05:28 +, Edward B. DREGER wrote: CLM Date: Wed, 14 Jun 2006 04:46:31 + (GMT) CLM From: Christopher L. Morrow CLM is it really that hard to make your foudry/extreme/cisco l3 switch vlan CLM and subnet??? Of course not. CLM Is this a education thing or a laziness thing? Both. And in some cases even a nasty fincancial thing. Billing customers extra datatraffic due to a large amount of broadcast traffic (especially when running badly configured Win32 servers) inside a single /23 or even /22 in one large VLAN is sadly still the case for some hosters. -- --- Erik Haagsman Network Architect We Dare BV Tel: +31(0)10-7507008 Fax: +31(0)10-7507005 http://www.we-dare.nl
Re: wrt joao damas' DLV talk on wednesday
Has anyone ever considered trying to come up with a way that these crypto projects could be explained in plain English? yes. I think a lot of the problem with adoption of DNSSEC stems from the fact that most people who might make a decision to use it, haven't got a clue what it is, how it works, or whether it even works at all. then they should go read steve crocker and russ mundy's most excellent www.dnssec-deployment.org. And it's not their fault that they don't understand. It's the fault of a technical community that likes to cloak its discussions in TLAs and twisted jargon. that's just bitterness, though. -- Paul Vixie
Re: wrt joao damas' DLV talk on wednesday
On Tue, 13 Jun 2006, Randy Bush wrote: snip how about cctlds, which are of great interest to me? i suspect that iana will not play, so how would cctlds play in way in which i can bet my bippies? and how it would be rolled would be of interest. key-roll through DLV is no different, from the high level, that key roll through non-DLV. either way you have to instantiate a new key and get it to your registry somehow (either through your registrar or otherwise) before you start using it. how do i enroll NG in a way that third parties can reasonably know is trustable? from the policy and process pov, how will we move it to a new zone set and server set when i get rid of it? along these lines - there seem to be a huge number of smallish tools related to DNSSEC, but I don't find anything that looks like a package with a couple of tools and scripts that would be usable by a small ccTLD - recommendations and good written exercises that step a newbie through the process would be very useful - any pointers? I've already looked at: http://www.dnssec-deployment.org./ http://www.dnssec.net/software http://www.ripe.net/disi/dnssec_howto/ http://www.dnssec-tools.org/ lots of info - but a cheat sheet and some recommendations for basic tools are needed to get this deployed and used. is this the current state-of-the-art? http://www.dnssec-tools.org/docs/step-by-step-dnssec-tools/sbs-dt.pdf similarly, how do i enroll psg.com in a way third parties can trust? how do we handshake in a clearly documented process- and key-wise exchange that gives third parties reason to be confident in the validity of the key isc hands out for psg.com? and anyone whose registrar won't play, will have to follow the procedure outlined on www.isc.org/ops/dlv/, which involves much manual labour, but can be done. (see http://www.isc.org/ops/dlv/#how_register in particular.) says not much about how things will actually be verified. only that isc will vet, i will fly, ... heck, for an org, it does not even state that corp docs of the flavors rirs use for transfers will be needed/used. i suspect that where we may be differing, other than restaurant lore, is that you may be saying the underlying technology is documented, and isc are good folk and if we say it's vetted you can trust us. problem is that, though i may want to trust isc (heck, i run isc's code!), for a security exercise, i should not. an example of some rigor in policy and process needs to be set. randy -- Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774
Re: wrt joao damas' DLV talk on wednesday
At 10:20 +0100 6/14/06, [EMAIL PROTECTED] wrote: Has anyone ever considered trying to come up with a way that these crypto projects could be explained in plain English? I think a lot of Over and over and over and over again. (Not to say we've done enough! but we've done all we can think of.) 1) Google for DNSSEC introduction 2) Look at http://www.dnssec.net/ 3) This has no crypto: http://apricot.net/apricot2005/slides/T11-3.pdf (a discussion of what it means to registries to pull it off) 4) Or this, for a NANOG presentation: (NANOG 32) http://www.nanog.org/mtg-0410/pdf/crocker.pdf If what you see isn't clear, ask the respective presenters. Maybe we haven't been clear enough. But, many have considered...maybe the only beneficiary has been the travel industry (through our buying of tickets/rooms). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain...
Re: wrt joao damas' DLV talk on wednesday
[ dunno to whom you are replying, but they miss the point, imiho ] Has anyone ever considered trying to come up with a way that these crypto projects could be explained in plain English? yes. to the best of my limited knowledge, the crypto has never been an issue with dnssec. it was done well from day zero, and has not changed. how it has been *used*, i.e. key management and use, have been the issues. e.g., the embarrassing deployment show-stopper (everything would have to roll at once) that delegation signer addressed. what still seems to remain poorly addressed is trust anchor management, e.g., roll and revocation of the root key. as far as i can tell, dlv attempts to address this by bypassing the root (from the dnssec aspect only). one half of what we seem to be trying to sort out is that it seems to have actually left the same problem, merely moving it to key management for the dlv servers' trust anchors. i don't know if there is hope for this one in the current design. is it like bogon filters, all who want to play are responsible for keeping abreast of changes and keeping their configs up to date? and dlv seems to add a new problem, needing to understand and feel comfortable with the policies and procedures by which dlv services vet and insert keys into their service. we know the policies of the iana and the root, whether we like them or not. i suspect and hope that this one can be relatively easily addressed, at least as far as isc's proposed service goes, by some specs from isc, joao's jet lag permitting and if the water don't rise (tm sra). dlv also sidesteps the layer 8..42 issues with the iana taking responsibility and authority for signing the root zone. reading drc's posts, this seems to be a wise move, though sad and somewhat embarrassing to see. but it ain't the crypto. never has been. and it is not always easy to explain math in plain english. so let's focus on where work needs to be done. randy
Re: wrt joao damas' DLV talk on wednesday
lurkmodeoffofftopicmodeon Shoes for Industry! - Joe Beets :-) /lurkmodeoff/offtopicmodeon At 01:04 PM 6/12/2006, you wrote: Paul may be special ... nope. we're all just bozos on this bus.
Re: Interesting new spam technique - getting a lot more popular.
* Christopher L. Morrow: On Wed, 14 Jun 2006, Suresh Ramasubramanian wrote: http://thespamdiaries.blogspot.com/2006/02/new-host-cloaking-technique-used-by.html * Monitor your local network for interfaces transmitting ARP responses they shouldn't be. how about just mac security on switch ports? limit the number of mac's at each port to 1 or some number 'valid' ? The attack is not visible at layer 2, so this won't help. You need static ARP tables on relevant hosts, but even that is only a stopgag measure. Better invest into one (virtual) router port per customer host. 8-/
Re: Interesting new spam technique - getting a lot more popular.
* Christopher L. Morrow: is it really that hard to make your foudry/extreme/cisco l3 switch vlan and subnet??? Is this a education thing or a laziness thing? You need those L3 switches before you can do this. Obviously, L2 gear is much cheaper, and will work equally well until it is attacked. Even with L3 switches, adressing it is a bit tricky. Not all vendors support point-to-point adressing on Ethernet interfaces (certainly some host software doesn't). There are universal subscriber gateways that simply override all network configuration on the host, but they aren't marketed at datacenters AFAIK. After all, who would think that a datacenter needs a network security policy similar to that of a hotel offering Internet access in its rooms?
Re: Interesting new spam technique - getting a lot more popular.
Mikael == Mikael Abrahamsson [EMAIL PROTECTED] writes: On Wed, 14 Jun 2006, Christopher L. Morrow wrote: is it really that hard to make your foudry/extreme/cisco l3 switch vlan and subnet??? Is this a education thing or a laziness thing? Is this perhaps covered in a 'bcp' (not even an official IETF thing, just a hosters bible sort of thing) ? Mikael This problem is fixed by following the BCP regarding spoof Mikael filtering, Only if you also filter _OUTGOING_ traffic, by port, to allow only the destination IPs that the customer equipment should be seeing. Filtering the ingress direction (customer equipment - your network) does not help (until _everyone_ does it), since the spammer only needs to _receive_ traffic with the hijacked IP, not send it (that can be done from the other corner of the spammer's triangle route). -- Andrew, Supernews http://www.supernews.com
Re: [nanog] Re: wrt joao damas' DLV talk on wednesday
On Tue, 13 Jun 2006, Randy Bush wrote: I don't profess to speak for ISC here, but it may be worth noting that ISC staff continue to spend a lot of time travelling to operator meetings, workshops, root server installations and RIR and ICANN meetings. Outreach and community participation is one of the core things that ISC does. It's not unreasonable to think that for a lot of zone operators (ccTLD or otherwise), the mountain will eventually come to Mohammed, and travel by the zone operator won't be necessary. can you say does not scale? or how about works poorly when a zone is transferred? Almost anyone on this list would have been at the NANOG meeting -- in my case, I'd spoken with Joao weeks ago about establishing this for my own zone -- suggesting that since I'm in NYC (right near the F-root) that someone should be close. While ISC doesn't have anyone routinely in NYC, that was actually one of his questions are you going to be at NANOG? -- and had it not been for a conflict of vacation time for something I have to attend THIS weekend, I would likely have been there, and this would heva been a done deal, at least on my end. People's PGP keys get signed by people they know and meet in person, but people don't allocate travel budgets to get it done (unless your name was Phil Zimmerman back in the day when PGP was the indespensible sellable product). -Dan i think there is no question that you and isc mean well. but we've entered the the twisty passages of security. randy -- I love you forever eternally. -Connaian Expression Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---
RE: Interesting new spam technique - getting a lot more popular.
Since this technique requires a IPinIP or GRE tunnel, wouldn't blocking these two protocols to/from the hosts be sufficient? Assuming of course the customer's host isn't using that normally. Chuck Netco Government Services has recently acquired Multimax and is changing its name to Multimax Inc. Visit http://www.multimax.com for more information.
Re: Interesting new spam technique - getting a lot more popular.
On Jun 14, 2006, at 1:53 PM, Church, Chuck wrote: Since this technique requires a IPinIP or GRE tunnel, wouldn't blocking these two protocols to/from the hosts be sufficient? Assuming of course the customer's host isn't using that normally. Unfortunately, that probably won't work for very long, if at all. First, it's kinda difficult to guarantee your customers will not use a protocol. Second, unless you have deep packet inspection, what is to stop the spammer from using, say, port 80 for their tunnel? Third, what's to stop them from using SSH tunnels? Etc., etc., etc -- TTFN, patrick
Re: Interesting new spam technique - getting a lot more popular.
On Jun 14, 2006, at 2:18 AM, John van Oppen wrote: That being said, I know at least one of our transit customers does hosting exactly how you are describing. Coincidentally, this customer is also one of the customers that asked if we could give them a class C block. Ok, I KNOW I am going to be slapped by a bunch of people here, but I often refer to a /24 (anywhere in the space) as a class C. I also call the thingie on my digital watch an LCD display, the thing that stops breaks from locking the ABS system and the number I type into the ATM machine my PIN number. Oh yeah, my DLT tape drive is connected to a SCSCI interface. Yup, all of the above are technically incorrect (ok, most of them are just redundant), but I do it anyway, and I am going to carry on doing it, so there! W -- Working the ICANN process is like being nibbled to death by ducks, it takes forever, it doesn't make sense, and in the end we're still dead in the water. -- Tom Galvin, VeriSign's vice president for government relations.
RE: Interesting new spam technique - getting a lot more popular.
On Wed, 14 Jun 2006, Church, Chuck wrote: Since this technique requires a IPinIP or GRE tunnel, wouldn't blocking these two protocols to/from the hosts be sufficient? Assuming of course the customer's host isn't using that normally. sure, but those are probably just convenience things, what happens when they setup an ssl tunnel? or http tunnel or ping tunnel?
on topic?
The effect of Nanog is remarkable. All the hybrid cells became fully converted to embryonic stem cells, said Jose Silva of the University of Edinburgh, Scotland, who reported the findings in the journal Nature. http://news.com.com/Gene+may+mean+adult+cells+can+be+reprogrammed/2100-1008_3-6083878.html?tag=nefd.top
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 PROTECTED] 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
Re: Interesting new spam technique - getting a lot more popular.
On Wed, Jun 14, 2006 at 07:03:10PM -0400, Matt Buford wrote: As a hoster with many customers on large shared VLANs perhaps I can add a bit... Note that if you're reading this list, you have already identified yourself as a non-typical hoster. Go read WHT or GFY for 10 minutes for an example of typical hosters, and if you're not a drooling idiot in need of a brain transplant afterwards consider yourself lucky. :) And don't forget, there are hundreds of hosting networks like the ones I described, a lot of whom are in the 1 - 30Gbps traffic range, with absolutely no clue how to do better. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Interesting new spam technique - getting a lot more popular.
And let me tell you.. inheriting a network like that, knowing a better way to do it, will make you want to put a gun in your mouth. Two /19's worth of address space in VLAN1 (not just in one vlan, but in vlan *1*. Cisco nerds are slapping foreheads or spitting Coke right now.) Trying to migrate customers to their own vlan when they've been alloted IPs, willy nilly, across one of the bajillion /24's secondaried on the vlan interface drives me into an entire new dimension of pissed off. Don't even get me started on allocation and traffic accounting. - billn On Wed, 14 Jun 2006, Richard A Steenbergen wrote: On Wed, Jun 14, 2006 at 07:03:10PM -0400, Matt Buford wrote: As a hoster with many customers on large shared VLANs perhaps I can add a bit... Note that if you're reading this list, you have already identified yourself as a non-typical hoster. Go read WHT or GFY for 10 minutes for an example of typical hosters, and if you're not a drooling idiot in need of a brain transplant afterwards consider yourself lucky. :) And don't forget, there are hundreds of hosting networks like the ones I described, a lot of whom are in the 1 - 30Gbps traffic range, with absolutely no clue how to do better. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
