Re: anybody else get mail from "Cassel McWaters" (xtracapacity.com) today?
On Thu, Apr 10, 2008 at 05:47:20PM +, Paul Vixie wrote: > i'm trying to keep track of which mailing list is getting scraped by whom, at > least among those who coldcall me. anybody else get one of these today? I noticed one to our NOC address (at a university) - in that case, probably not scraped from this list, but probably scraped from whois. w
Re: SaidCom disconnected by Level 3 (former Telcove property)
On Thu, Mar 15, 2007 at 11:39:49AM -0700, Berkman, Scott wrote: > To me the only part of this that is up for argument is did SaidCom > actually violate the contract and/or terms of use, and I certainly don't > have enough information beyond that one article to make that decision. > If someone else does please share with the group. I will say that I've used Level(3) as a transit provider (not the only one, of course) at 2 different companies (both of which were / are pretty responsive to abuse complaints, in one case because I was the one responding to them), and I have never had an issue like this. However, both of these were content / hosting type setups, not ISPs who provide local Internet access, so the type of complaints (and probably the volume) were different than your typical ISP. I don't think there's any way to know for sure who screwed up here... maybe the small provider wasn't as responsive as they say they are, but are trying to shift the blame to (3). Or maybe (3) was trigger-happy. I don't think anyone from the outside has the information to tell for sure which happened. But Level(3) is a pretty big provider, and if they were just shutting off small competitors willy-nilly, I imagine we'd be hearing about it more. w > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Frank Bulk > Sent: Wednesday, March 14, 2007 10:30 PM > To: nanog@merit.edu > Subject: SaidCom disconnected by Level 3 (former Telcove property) > > > http://www.phillyburbs.com/pb-dyn/articlePrint.cfm?id=1310151 > > Is this a normal thing for Level 3 to do, cut off small, responsive > providers? > > Frank
Re: NOC Personel Question (Possibly OT)
On Thu, Mar 15, 2007 at 09:49:36AM -0400, Donald Stahl wrote: > > > Anyway, I have a friend who used managed to get "Not A Janitor" on his > > business card. > "Rear Admiral" was my favorite business card title if only because that > was also the caller ID on my phone (I managed the PBX at the time). My old work let you pick what was on your old business card... my two favorites were: "Good With his Hands" and "Organ Donor" My boss was the only sysadmin for years, and he has "The Guy Who Keeps the Servers Running" on his business card. w
Re: Cable-Tying with Waxed Twine
On Wed, Jan 24, 2007 at 07:30:06PM -0500, Dan Mahoney, System Admin wrote: [...] > I came back to find all my cat5 cables neatly tied with some sort of > waxed twine, using an interesting looping knot pattern that repeated > every six inches or so using a single piece of string. [...] > I have tried googling for the method, (it's apparently standard, I've > seen it in play elsewhere), and for the type of twine, but had little > luck. The kind my vendor was able to get was flat (not the normal stuff). As far as I know, this stuff is usually surprisingly expensive and / or comes in large cases. You might just see if the people at your colo can give you a roll or two, or ask where they order theirs (last time I asked, they bought it by the case). I believe this is the stuff I have: http://www.edmo.com/index.php?module=products&func=display&prod_id=20352 I got it from a local outfit (Danbru - http://danbru.com - great Socal vendor) at ~ $35/roll, which seemed exorbitant to me. w
Re: SBC RBL
On Tue, Dec 05, 2006 at 01:06:34PM -0800, Crist Clark wrote: > We started getting these, for reasons unknown, for > some pacbell.net email addresses, > > 550 5.0.0 ylpvm35.prodigy.net Access Denied. To request removal, send the > complete error message, including your ip addresses, in an E-mail to [EMAIL > PROTECTED] Interesting... we just started getting a bunch of these too. I wonder if there's a glitch on their side. w
Re: How to stop UltraDNS sales people calling
On Tue, Nov 28, 2006 at 05:48:55PM -0800, Joseph Jackson wrote: > I had ultradns calling also but told them we weren't at a place to use > their product and they said ok and let me be. They were always > professional on the phone. One more on the side of "They call all the time and won't leave us the @#$@ alone, no matter how direct we are". Fortunately, they don't call me (yet), but they have been calling several other folks at our office repeatedly for years, despite being told pretty bluntly to knock it off. w
Re: Data Center Wiring Standards
[ Disclaimer - my experience is as someone who has setup lots of racks, dealt with a number of colocation facilities and cabling contractors. However, I haven't ever run a colo. ] On Fri, Sep 08, 2006 at 05:36:09PM -0700, Rick Kunkel wrote: > Can anyone tell me the standard way to deal with patch panels, racks, > and switches in a data center used for colocation? > Right now, we have a rack filled with nothing but patch panels. We > have some switches in another rack, and colocation customers scattered > around other racks. When a new customer comes in, we run a long wire > from their computer(s) and/or other device(s) to the patch panel. > Then, from the appropriate block connectors on the back of the panel, > we run another wire that terminates in a RJ-45 to plug into the > switch. This way of doing things *can* be done neatly in some cases - it really depends on how you have things setup, your size, and what your customers' needs are. For large carrier neutral places like Equinix, Switch and Data, etc., where each customer usually has a small number of links coming into their cage, and things are pretty non-standard (i.e., customers have stuff other than a few ethernet cables going to their equipment), that's pretty much what they do - run a long cable through overhead cable trough or fiber tray, and terminate it in a patch panel in the customer's rack. > My thoughts go like this: We put a patch panel in each rack. Each of > these patch panels is permanently (more or less) wired to a patch > panel in our main patch cabinet. So, essentially what you've got is a > main patch cabinet with a patch panel that corresponds to a patch > panel in each other cabinet. Making connection is cinchy and only > requires 3-6 foot off-the-shelf cables. This is a better way to do it IF your customers have pretty standard needs. One facility I've worked at has 6 cables bundled together (not 25 pr cable, but similar - 6 cat5 or cat6 cables bundled within some sort of jacket), going into a patch panel. 25 pair or bundled cabling will make things neater, but usually costs more. Obviously, be SUPER anal retentive about labelling, testing, running cables, etc., or it's not worth doing at all. Come up with a scheme for labelling (in our office, it's "a.b.c where a is the rack number, b is the rack position, and c is the port number) and stick to it. Get a labeller designed for cables if you don't already have one (a Brady, industrial P-Touch, Panduit, or something similar). Make sure there is a standard way for everything, and document / enforce the standard. Someone has to be the cable n**i (does that count as a Godwin?) or things will get messy fast. If you're doing a standard setup to each rack, hire someone to do it for you if you can afford it. It will be expensive, but probably worth it unless you're really good (and fast) at terminating cable. Either way, use (in the customer's rack) one of the patch panels that's modular, so you can put a different kind of connector in each slot. That gives you more flexibility later. In terms of whether patch panels / switches should be mixed in the same rack; opinions differ. It's of course difficult to deal with terminating patch panels when there are also big fat switches in the same rack. I've usually done a mix anyway, but for your application, it might be better to alternate, running the connections sideways. Invest in lots of cable management, the bigger, the better. I assume you already have cable management on these racks? I like the Panduit horizontal ones, and either the Panduit vertical ones, or the CPI "MCS" ones. If you're doing a new buildout, or can start a new set of racks, put extra space between them and do 10" wide cable management sections (or bigger). I can give you some suggestions in terms of vendors and cabling outfits, though most of the people I know of are in the Southern California area. > I talked to someone else in the office here, and they believe that > they've seen it done with a switch in each cabinet, although they > couldn't remember is there was a patch panel as well. Ok, so if most of your customers have a full rack or half rack, I would suggest not putting a switch in each rack. In that case, you should charge them a port fee for each uplink, which should encourage them to use their own networking equipment. Now if most of your customers are using < 1/2 rack, and aren't setting up their own network equipment, and you're managing everything for them, then you might want to put 1 48 port / 2 24 port switch in each individual rack, with two uplinks from some central aggregation switches to each. I really don't think you want more than 4-6 cables going to any one rack. Maybe you can clarify your typical customer setup? > Any standards? Best practices? Suggestions? Resources, in the > form of books, web pages, RFCs, or white papers? I think the best thing is just to look around as much as possible, and then see what wo
Re: AOL Mail Problem
On Thu, Jul 27, 2006 at 09:28:24AM -0700, chuck goolsbee wrote: > > I managed to get a whitelist on the domains in > > question, which... unless you classify phpbb notifications as "spam" > > have never been even remotely associated with spamming. > > The fatal flaw in AOL's feedback system is that it is user-generated, > and users will classify virtually anything as "spam". It is actually > quite entertaining to skim the scomp feed... They have a very large user-base, though. In my experience (though I haven't been dealing with this as much in the past year and a half or so), it takes a lot of user complaints to trigger any sort of block, and it's also based on the percentage of complaints to total mail. And that's only just one part of their blocking system. > AOL may have clueless users, but AOL's postmaster group has their > feces amalgamated. I wish I could say the same for Yahoo, Comcast, > MSN/Hotmail, etc etc. Exactly. Keeping in mind that they are not only a huge email provider, but also that their user-base is mostly not exactly tech savvy, I think Carl, Charles et al do a pretty good job over there. AOL was also one of the first big providers to publish their mail acceptance guidelines and to make a really big effort to communicate with mail senders. I remember sending a frustrated email to the AOL postmaster a few years back (when they were first starting to do this) in desparation over something or other (probably backscatter), and being surprised to actually get a response from an intelligent human. Dealing with their postmaster team can still take a while sometimes, but they'll generally respond. w
Re: DS3/OC3 to FE bridge?
On Wed, Mar 15, 2006 at 04:47:32PM -0800, matthew zeier wrote: > I'm looking for something that can take a DS3 or OC3 and "turn" it into > FE. Basically similiar to what http://www.ds3switch.com/ does. Anda makes some boxes that do this. http://www.andanetworks.com/products/ I've had experiences with these (as a user, not an operator), and they seem to work fine. /w
Re: AW: Odd policy question.
On Fri, Jan 13, 2006 at 01:47:48PM -0800, David W. Hankins wrote: > On Fri, Jan 13, 2006 at 10:09:51AM -1000, Randy Bush wrote: > > > it is a best practice to separate authoritative and recursive > > > servers. > > why? > I'm not sure anyone can answer that question. I certainly can't. > Not completely, anyway. There are too many variables and motivations. [...] > Well, RFC2010 section 2.12 hints at cache pollution attacks, and that's > been discussed already. Note that I can't seem to find the same claim > in RFC2870, which obsoletes 2010 (and the direction against recursive > service is still there). In an environment where customers may be able to add zones (such as a web-hosting environment), not separating the two may cause problems when local machines resolve off of the authoritative nameservers. This could be due to someone maliciously or accidentally adding a domain they don't control, or simply to someone setting up their domain prior to changing over the nameservers. w
