Re: Akamai wierdness
On Mon, Mar 23, 2009 at 10:18 AM, Paul Wall wrote: > I would end the email there, but it really gets me how someone that is > in-house doesn't realize that n...@akamai is a black hole. I am pleased hear that Akamai has remedied this situation, most likely by having Mr. Gilmore attend to the matter personally. Drive Slow, Paul Wall
Re: Akamai wierdness
I usually just call their toll free support number when their are occasional issues. This is from a content provider perspective (using Akamai as a CDN for the sites I support). Never had an issue getting a hold of anyone and getting the issue resolved (two times I have called them, it was issues on our side anyway). Paul Stewart wrote: Not to add to a potential "peeing" contest here but we have Akamai equipment in our network - it's a very important component to our service delivery. If/when there is ever a problem (quite rare in our experience other than the odd hardware failure that has no impact anyways due to the cluster configuration) we send an email to n...@akamai.com. Typical response times on a 24X7 basis never normally exceed 20 minutes at most. I can remember one time where it might have been an hour. That's a long ways from "blackhole" based on our experience... Paul Stewart -Original Message- From: JC Dill [mailto:jcdill.li...@gmail.com] Sent: Monday, March 23, 2009 5:03 PM Cc: NANOG list Subject: Re: Akamai wierdness Paul Wall wrote: Patrick Gilmore wrote [context inserted]: Perhaps using the RFC required address [...@akamai] would be more productive than e-mailing 10k strangers? Normally I see emails like this and, if it's Not In My Back Yard, and the Internet is not going nutz, the delete key explains how worried i am. Back to your email: using the RFC required address The correct catty response to the Akamai question is : cc...@akamai.com. That's C as in "Customer", Care as in "they actually care". I would end the email there, but it really gets me how someone that is in-house doesn't realize that n...@akamai is a black hole. Paul, you might want to test a theory of this nature before you post about it to more than a thousand of your colleagues. This morning I sent email to n...@akamai.com and received a personalized (non-autoresponder) reply 17 minutes later. jc "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
RE: Akamai wierdness
Not to add to a potential "peeing" contest here but we have Akamai equipment in our network - it's a very important component to our service delivery. If/when there is ever a problem (quite rare in our experience other than the odd hardware failure that has no impact anyways due to the cluster configuration) we send an email to n...@akamai.com. Typical response times on a 24X7 basis never normally exceed 20 minutes at most. I can remember one time where it might have been an hour. That's a long ways from "blackhole" based on our experience... Paul Stewart -Original Message- From: JC Dill [mailto:jcdill.li...@gmail.com] Sent: Monday, March 23, 2009 5:03 PM Cc: NANOG list Subject: Re: Akamai wierdness Paul Wall wrote: > Patrick Gilmore wrote [context inserted]: > >> Perhaps using the RFC required address [...@akamai] would be more >> > productive than e-mailing 10k strangers? > > Normally I see emails like this and, if it's Not In My Back Yard, and the > Internet is not going nutz, the delete key explains how worried i am. > > Back to your email: > > >> using the RFC required address >> > > The correct catty response to the Akamai question is : cc...@akamai.com. > That's C as in "Customer", Care as in "they actually care". > > I would end the email there, but it really gets me how someone that is > in-house doesn't realize that n...@akamai is a black hole. Paul, you might want to test a theory of this nature before you post about it to more than a thousand of your colleagues. This morning I sent email to n...@akamai.com and received a personalized (non-autoresponder) reply 17 minutes later. jc "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
Re: Akamai wierdness
Paul Wall wrote: Patrick Gilmore wrote [context inserted]: Perhaps using the RFC required address [...@akamai] would be more productive than e-mailing 10k strangers? Normally I see emails like this and, if it's Not In My Back Yard, and the Internet is not going nutz, the delete key explains how worried i am. Back to your email: using the RFC required address The correct catty response to the Akamai question is : cc...@akamai.com. That's C as in "Customer", Care as in "they actually care". I would end the email there, but it really gets me how someone that is in-house doesn't realize that n...@akamai is a black hole. Paul, you might want to test a theory of this nature before you post about it to more than a thousand of your colleagues. This morning I sent email to n...@akamai.com and received a personalized (non-autoresponder) reply 17 minutes later. jc
Re: REVERSE DNS Practices.
on Sat, Mar 21, 2009 at 12:44:15PM -0500, Frank Bulk wrote: > The recommendations in this draft proposal have worked for me: > http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt Also: http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06 http://tools.ietf.org/html/draft-ietf-dnsop-inaddr-required-07 In any case, it depends on whether those IPs will house legitimate sources of mail; I *strongly* recommend indicating whether an IP is dynamically or statically assigned, and (ideally) what sort of tech is in use (dialup? DSL? cable? wifi? etc) so that mail admins can make decisions about whether or not to allow mail from those hosts. (Hrm, do I want mail from a dynamic wifi IP? not so much; static generic dsl? okay, maybe for now). If you want to be friendly to folks who don't necessarily want to have to use regexes to match your dynamics, make sure that if you do use some sort of topology- or geography-based naming, that you put the "dynamic" or "static" token as far to the right as possible, so that you end up with rdu-1-2-3-4.cable.dynamic.example.net instead of dyn-1-2-3-4.cable.rdu.example.net because it's a lot easier for mail admins to block 'dynamic.example.net' than to have to have local access.db entries for every last geography you're serving, or have to use regexes. And please don't mix dynamics and statics under the same naming conventions. Finally, if you *do* intend for these IPs to house legit mail servers (or mail sources, for that matter), whether yours or your clients', for the love of all that is good and holy, give them /custom/ PTRs that indicate the actual domain of the responsible party, rather than just giving them generic names in your domain, unless you really want to act as an abuse report gateway for your clients. HTH, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
Re: Akamai wierdness
Patrick Gilmore wrote [context inserted]: > Perhaps using the RFC required address [...@akamai] would be more productive than e-mailing 10k strangers? Normally I see emails like this and, if it's Not In My Back Yard, and the Internet is not going nutz, the delete key explains how worried i am. Back to your email: > using the RFC required address The correct catty response to the Akamai question is : cc...@akamai.com. That's C as in "Customer", Care as in "they actually care". I would end the email there, but it really gets me how someone that is in-house doesn't realize that n...@akamai is a black hole. Drive Slow, -paul
Re: Redundant AS's
Lyndon Nerenberg writes: >> Autonomous systems will be assigned 16-bit identification >> numbers (in much the same ways as network and protocol numbers >> are now assigned), and every EGP message header contains one word >> for this number. > > Was that a 36-bit word? 16-bit "word" in the sense of a PDP-11 or DG Nova, not 36-bit "word" in the sense of a Univac-1100 or DECSYSTEM-20. Be glad that it wasn't a 12-bit "word" in the sense of a PDP-8. (page 33, same RFC) -r
Re: AS path weirdness
On 21 Mar 2009, at 02:48, Jason Lewis wrote: I'm not entirely sure what I'm looking at. The reserved AS, 65490 appears in parentheses and I've never seen that in MRT formatted data and not sure why it's happening. This has been observed when a vendor runs 32-bit AS aware code on part of their edge, and non-32-bit AS aware code on a different part of their edge. I'm also not clear on why I see 23456 *and* a 32 bit AS in the path. Is anyone else seeing this or is it something wacky at RRC04? 91.207.218.0/23|29222 6830 (65490) 3356 35320 3.21 23456 There's some history with this prefix. http://www.andyd.net/media/talks/asn4_breaks_network.pdf [from nanog45] Andy
