From mpetach at netflight.com Fri Apr 1 00:07:55 2011 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 31 Mar 2011 22:07:55 -0700 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: <8CACADAD-19A2-4EF7-8649-E91D1BA08A9A@the-watsons.org> References: <49839.1301618784@tristatelogic.com> <8CACADAD-19A2-4EF7-8649-E91D1BA08A9A@the-watsons.org> Message-ID: On Thu, Mar 31, 2011 at 6:04 PM, Brett Watson wrote: > > On Mar 31, 2011, at 5:46 PM, Ronald F. Guilmette wrote: > >> (Sorry, but I can't help snickering a bit at your _prior_ employment. >> As I feel sure you are already painfully aware, having that on your >> resume does not exactly inspire a whole lotta confidence in the notion >> that you are a straight shooter. ?The words ``cover up'' are the ones >> that come most immediately to mind.) > > Awww, that makes me "not a straight shooter"? I was at EBS, I just happened to join a company who's management weren't straight shooters. > > And what all these accusations and attacks have to do with the thread, I have no idea. Apparently it has to do with the fact that you can only pay for IP service via check; credit card billing has been abolished. If you don't pay by check, you're a criminal--that's all there is to it. Matt From grobe0ba at gmail.com Fri Apr 1 00:36:55 2011 From: grobe0ba at gmail.com (Atticus) Date: Fri, 1 Apr 2011 01:36:55 -0400 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? Message-ID: This OT, and for those of you with virgin ears, don't read more. This is specifically to Ronald: Maybe, if you didn't act like a flaming douchebag, and were polite to people, they would be more interested in helping you out. Learn to use some fucking manners. Every single message I've seen from you has been condescending. I agree, this entire situation and situations like it are fucked up. That doesn't give you the right to start demanding answers from people, and in general treating everyone else like we are your personal servants, and are responsible for making sure your every whim is carried out. That being said, I'm probably going to get banned for that, but I feel it needed to be said. Grobe From brent at servuhome.net Fri Apr 1 00:54:01 2011 From: brent at servuhome.net (Brent Jones) Date: Thu, 31 Mar 2011 22:54:01 -0700 Subject: Final step of .com DNSSEC deployment In-Reply-To: <20110331200519.GX30164@DUL1MLARSON-M2.labs.vrsn.com> References: <20110331200519.GX30164@DUL1MLARSON-M2.labs.vrsn.com> Message-ID: On Thu, Mar 31, 2011 at 1:05 PM, Matt Larson wrote: > As part of the deployment of DNSSEC in .com, the zone has been signed > and in a "deliberately unvalidatable" state for several weeks. ?Late > last week the .com key material was unobscured and the actual keys > have been visible in the zone since March 24. > > The final step in the deployment was publishing the .com zone's DS > record in the root zone. > > I am pleased to report that the root zone including a DS record for > .com was published at approximately 1500 UTC today, March 31. > > Matt Larson, on behalf of the many people at Verisign who made this > deployment possible > > Nice work! Congrats! /me goes to signing some things -- Brent Jones brent at servuhome.net From jvanoppen at spectrumnet.us Fri Apr 1 01:00:54 2011 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Fri, 1 Apr 2011 06:00:54 +0000 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: <49839.1301618784@tristatelogic.com> References: <49839.1301618784@tristatelogic.com> Message-ID: Why does it matter what his position is? Sounds like they had a forged LOA from the customer and that they fixed the issue when they found out about it. I am not sure you can ask too much more from a network operator, the best thing we can hope for are companies that will cancel customers if they are abuse sources, that is exactly what happened here. Lots of people are posting on nanog with outside email addresses because they don't want to be tied too closely to the corporation for which they work, it seems totally reasonable to me especially given the mix of personal and professional ties a lot of us have in this community. The main issue here is getting results and it sounds like that happened here pretty quickly. Most technical types are good people and for the most part will work though their corporate BS to get abuse issues solved as quickly as they can. I know we do try to resolve abuse quickly and people who are nice and provide data up front just help expedite the process further, acting like a jerk is by far the least productive way to engage people in the nanog community. John -----Original Message----- From: Ronald F. Guilmette [mailto:rfg at tristatelogic.com] Sent: Thursday, March 31, 2011 5:46 PM To: nanog at nanog.org Subject: Re: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In message , rr wrote: >Hmm, thought it was a NANOG prerequisite to be able to do a google >search. Should be pretty easy to find this info with that tool in your >handbag. Which info is that, exactly? Your title at Integra Telecom? Umm... well... yes.... I guess this is you, right? http://www.linkedin.com/pub/randy-rooney/6/9ab/22a So, are you THE Engineering Manager, or merely AN Engineering Manager at Integra Telecom? I'm guessing that it is a big enough outfit that you probably have more than one. (Sorry, but I can't help snickering a bit at your _prior_ employment. As I feel sure you are already painfully aware, having that on your resume does not exactly inspire a whole lotta confidence in the notion that you are a straight shooter. The words ``cover up'' are the ones that come most immediately to mind.) >With the above tool I've got your phone # and would be happy to call >you if you'd like clarification on our process. No thanks. I didn't ask for "clarification" of your "process" (whatever the hell THAT might mean), and frankly it doesn't interest me. Your process is... well... your process. Whatever it may be, it belongs to you and you should probably keep it to yourself. (Who knows? Since business processes are now patentable, maybe someday you can get a patent on it!) I did however ask for the name of the crook whose name was on the check that paid for the hijacked space routing. Is that something you can respond to, or no? If not, why not? Was Integra Telecom _actually_ defrauded? If so, who defrauded you? Did your customer, Circle Internet defraud you? If you are claining that THEY are also an innocent party in this, then who defrauded them? Whose name was on the check that THEY cashed? It really is a rather simple question, and doesn't require an elaborate, convoluted, or lengthy digression into the details of your "process". Ya know, maybe it's just me, but it would seem to me that that if either you or your customer, Circle Internet, were in fact defrauded in this case, that both of you would be altogether ready, willing, and indeed eager to ``out'' the actual crooked perpetrator... you know... instead of, like, hiding the perp's identity and thus helping him to cover his tracks. But I guess that's just me. (When somebody cheats _me_, I am not myself in the habit of then going out of my way to protect him.) Don't misunderstand me. If your company was in fact dedrauded, then allow me to express my sincere condolences for your loss. Or would it be more accurate to say your gain? You DID cash the check right? I mean your company does NOT have a policy of granting everybody three months of free service, right? >Please just reply to me off-list. No thanks. As Jodie Foster said in the movie Contact, ``This isn't a person to person call.'' Crooks, hijacking, and mass spamming affect everybody on the whole Internet. I didn't ask for the name of the crook who signed the check just for my private or personal edification. Other ISPs should know who they need to be on the lookout for. I can assure you that just because YOU have now stopped routing space for this crook, that doesn't mean that he's going to just fold up his tent and slink quietly away into oblivion. In fact I already have evidence in hand that he's still got both IP space and snowshoe spamming domains located elsewhere (including elsewhere on Circle Internet, see below) that he is continuing to use, even as we speak. On the other hand, of course, if Integra and/or Circle Internet were in fact ``in on the game'' from the get-go, then in that case I could well and truly understand why both of your companies might now be reluctant to give up your cohort. Regards, rfg P.S. I gather that nobody at your place even so much as raised an eyebrow when tiny little Circle Internet, a company whose biggest _legitimate_ IP block prior to this incident was a mere /21, suddenly showed up on your doorstep asking to have an entire fresh new /16, belonging to an major, internationally known chemical company routed for them, correct? P.P.S. OK, so you are reluctant to give up the actual hijacker. So let's just skip that for now. Instead how about if you just tell us who owns the followng domain names which are all getting DNS from Circle Internet IP space, even as we speak. And no, I _do not_ want you to just regurgitate the fradulent bull puckey that's present within the relevant WHOIS records. (To paraphrase Red Riding Hood "My my grandma! What a lot of domains you have!" Odd that all of them were created so recently, and that none of them seem even have associated web sites. But again, I'm sure that I'm the only one in the Universe who finds any of that odd. Yea.) 208.85.32.114 dns2.virtualcheck.info pinkcreditscore.info pinkcreditreport.info pinkcreditdeals.info orangereports.info orangeoffers.info orangegifts.info orangecreditsco.info orangecreditreport.info orangecreditdeals.info onlinecredit-check.info myfreecredtiscore.info knowyourself.info healthsample.info happinessonline.info freecreditscore360.info doctors-orders.info creditscorealerts.info 208.85.32.246 ns2.rockboys1a.com yesimprove.info withoutinvestigate.info withoutcritique.info withinfocus.info withenable.info visionconsolidate.info versuscoordinate.info validateinstruct.info untilreview.info untilfocus.info unforgettableidea.info underneathunlikemeasure.info underneathunlike.info uncommonsuggestion.info uncommonguidance.info unbelievableguidance.info trumpenforce.info totutor.info topconvert.info tipsproduce.info timesenable.info throughreview.info throughoutcompare.info thansurvey.info terrificexplain.info surveydelegate.info supremeteach.info supplyindividualize.info submitteach.info submitinstruct.info strikingtrust.info strikingproposal.info staggeringlearn.info sincesurvey.info searchrecommend.info searchproduce.info searchprioritize.info retrievelive.info retrievechic.info reserveenable.info researchgrow.info remarkablesubject.info registersimulate.info registeradvise.info reducequick.info recordteach.info recordinstruct.info recordenable.info reconcilelearn.info reconcilefresh.info raresubject.info quickhandle.info projectmaxi.info projectabc.info phenomenalmentor.info pastexperiment.info outstandingprove.info orderinstil.info orderevaluate.info operateinstil.info operateevaluate.info ontostimulate.info ontoexperiment.info ontoadvise.info offconduct.info noteworthyeducation.info nearbyinvestigate.info nearbyindividualize.info moremanage.info measurenavigate.info measurecontract.info marvellousteach.info marvellousintroduce.info magnificienttell.info locatemerge.info locateimprove.info locatehire.info locatedelegate.info likesurvey.info keyinspect.info investigatereview.info investigateinspect.info inexamine.info hotappoint.info groovyrecommend.info forsimulate.info followingteach.info flexlead.info flexconsider.info filecoordinate.info fantasticlearn.info failingevaluate.info extraordinarysuggestion.info extraordinaryproposal.info extraordinarylearn.info extractterminate.info extractapprove.info experimentsecure.info executeenable.info excludingdetect.info exceptionalwisdom.info exceptionaltutor.info exceptionalinfo.info examinelead.info estimateok.info estimatedouble.info dreamsupervise.info downmeasure.info distributefocus.info determineup.info detectlead.info despiteinstruct.info dealsstrengthen.info dayinspect.info critiqueattain.info cooloversee.info conservemax.info conductimprove.info conducthandle.info conducteliminate.info concerningfocus.info concerning.info computefind.info completehire.info compiletutor.info compileevaluate.info codesimulate.info coachstimulate.info classifytrain.info classifycoordinate.info circainform.info butindividualize.info budgetover.info budgetgrow.info besthandle.info besideevaluate.info beneathsimulate.info belowexamine.info behindsimulate.info barringcoordinate.info atopsurvey.info atopextract.info atenable.info atcompare.info assistindividualize.info answersimulate.info amongextract.info againstsimulate.info advocateevaluate.info abovemotivate.info finelovewithme.com whosthefarest.com rockboys1b.com rockboys1a.com leanbackfront.com ns1.rockboys1a.com 155 yesimprove.info withoutinvestigate.info withoutcritique.info withinfocus.info withenable.info visionconsolidate.info versuscoordinate.info validateinstruct.info untilreview.info untilfocus.info unforgettableidea.info underneathunlikemeasure.info underneathunlike.info uncommonsuggestion.info uncommonguidance.info unbelievableguidance.info trumpenforce.info totutor.info topconvert.info tipsproduce.info timesenable.info throughreview.info throughoutcompare.info thansurvey.info terrificexplain.info surveydelegate.info supremeteach.info supplyindividualize.info submitteach.info submitinstruct.info strikingtrust.info strikingproposal.info staggeringlearn.info sincesurvey.info searchrecommend.info searchproduce.info searchprioritize.info retrievelive.info retrievechic.info reserveenable.info researchgrow.info remarkablesubject.info registersimulate.info registeradvise.info reducequick.info recordteach.info recordinstruct.info recordenable.info reconcilelearn.info reconcilefresh.info raresubject.info quickhandle.info projectmaxi.info projectabc.info phenomenalmentor.info pastexperiment.info outstandingprove.info orderinstil.info orderevaluate.info operateinstil.info operateevaluate.info ontostimulate.info ontoexperiment.info ontoadvise.info offconduct.info noteworthyeducation.info nearbyinvestigate.info nearbyindividualize.info moremanage.info measurenavigate.info measurecontract.info marvellousteach.info marvellousintroduce.info magnificienttell.info locatemerge.info locateimprove.info locatehire.info locatedelegate.info likesurvey.info keyinspect.info investigatereview.info investigateinspect.info inexamine.info hotappoint.info groovyrecommend.info forsimulate.info followingteach.info flexlead.info flexconsider.info filecoordinate.info fantasticlearn.info failingevaluate.info extraordinarysuggestion.info extraordinaryproposal.info extraordinarylearn.info extractterminate.info extractapprove.info experimentsecure.info executeenable.info excludingdetect.info exceptionalwisdom.info exceptionaltutor.info exceptionalinfo.info examinelead.info estimateok.info estimatedouble.info dreamsupervise.info downmeasure.info distributefocus.info determineup.info detectlead.info despiteinstruct.info dealsstrengthen.info dayinspect.info critiqueattain.info cooloversee.info conservemax.info conductimprove.info conducthandle.info conducteliminate.info concerningfocus.info concerning.info computefind.info completehire.info compiletutor.info compileevaluate.info codesimulate.info coachstimulate.info classifytrain.info classifycoordinate.info circainform.info butindividualize.info budgetover.info budgetgrow.info besthandle.info besideevaluate.info beneathsimulate.info belowexamine.info behindsimulate.info barringcoordinate.info atopsurvey.info atopextract.info atenable.info atcompare.info assistindividualize.info answersimulate.info amongextract.info againstsimulate.info advocateevaluate.info abovemotivate.info finelovewithme.com whosthefarest.com rockboys1b.com rockboys1a.com leanbackfront.com From rfg at tristatelogic.com Fri Apr 1 04:13:36 2011 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 01 Apr 2011 02:13:36 -0700 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: Message-ID: <54723.1301649216@tristatelogic.com> In message , John van Oppen wrote: >Why does it matter what his position is? Well, if he was, you know, just the janitor or something, then I think that we could all safely assume that his opinions are...well.. his opinions, and that they should not be improperly or unfairly construed as official statements on behalf of the company. Wouldn't you agree? I, for one, certainly don't want to unfairly interpret some personal comment on the part of some worker bee as being the equivalent of an official company pronouncement. Do you? >Sounds like they had a forged LOA from the customer... And they provided service for free?? For three months?? All just on the basis of a sheet of paper that any fool could trivially manufacture in 15 minutes or less at the local Kinkos? Sorry. No. I think not. Money was paid. Money changed hands. Which hands did it come from? From the hijacker crook, obviously. But which one? (There are so many different crooks on the Internet these days.) What was this one's name? Not the phony blaoney name that was on the LOA. That really doesn't matter. The name on the check. >...and that they fixed the issue... I'm sorry to disagree, but no, actually, it didn't. As I pointed out in the very message that you are responding to, nothing here is ``fixed'', nothing here is ``resolved'', and the evidence seems to indi- cate that the exact same snowshoe spammer who was spamming out of the hijacked block that was getting connectivity from Circle Internet and also, indirectly, from Integra Telecom is still very much alive and well and still operating within the UN-hijacked portion of Circle Internet's IP space. I understand that now that the _hijacking_ part of this tiny drama has been terminated, some folks, here and elsewhere, would prefer now to just roll over and go back to sleep. That's your choice and you're welcome to it. I, however, would sort-of still like to see the perp being escorted to the exit of the entire Internet, along with a swift kick in the ass and an admonition never to come back again. That clearly hasn't happened yet, and what with all the corporate CYA going on it doesn't even look probable any time soon. >I am not sure you can ask too much more from a network operator Yea. Gee, I guess you're right. Expecting honesty, courtesy, forthrightness, and enough information to make sure that other networks will not be similarly tainted in the future is just completely out of the question. That's apparently far too much care and compassion for one's community and one's fellow man to expect from any CORPORTATION, after all. Please excuse me for harboring patently ridiculous hopes and/or expectations. >the best thing we can hope for are companies that will cancel customers if >they are abuse sources... That may be the best that _you_ are capable of hoping for. Me personally? I set my sights a little higher. Maybe someday... perhaps not in my lifetime, but someday... when there is a lot less corporate CYA and just a little bit more civic responsibility, then maybe we really could get these kinds of crooks off the Internet in a way so that they don't just reappear someplace else a month or two down the road, when things have quieted down. Look, here's two scenarios. See if you can fit them both together in a way that makes sense. I can't. If I go into Macy's, charge a pair of shoes on my Macy's credit card, and then, when I get my monthy charge account bill, I simply don't pay it, then within 30 days, Equifax, Experian and TransUnion will all know about that, and they will go around blabbing to every other merchant in the world, and pretty soon I won't be able to buy even a stick of bubble gum on credit. (Note that _Macy's_ apparently has no trouble ratting out _it's_ less than savory customers.) If however I collude with some friendly and/or greedy ISP/NSP or two on the Internet, hijack a /16 or two, get caught, and get publically outted, then I can be reasonably assured that all of the greedy companies, all the way up and down the entire networking food chain will instantly clam up, you know, just to avoid having to admit that they profited from my scheme too. So I can also be reasonably sure, going in, that even if I'm caught, not only will I not be punished in any way, but better still, I'll be able to just wait a few weeks and then just go down the street to the next greedy ISP/NSP and pull the exact same scam all over again. And nobody except the companies that I've paid off will ever even know my name. If this all makes sense to anybody, then please do explain it to me, because I'm not seeing it. All I see is a sure-fire recipie for an endless cavalcade of IP hijacking incidents. For the perp, there is simply no downside whatso- ever, even if he gets caught, so he's just gonna do it over and over and over again. Which part of this is either non-clear or non-obvious? Regards, rfg From rsk at gsp.org Fri Apr 1 07:38:04 2011 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 1 Apr 2011 08:38:04 -0400 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: References: Message-ID: <20110401123804.GA5883@gsp.org> On Fri, Apr 01, 2011 at 01:36:55AM -0400, Atticus wrote: > Maybe, if you didn't act like a flaming douchebag, and were polite to > people, they would be more interested in helping you out. And were it ten or fifteen years ago, I might agree with you. But it's not. By now, everyone knows, or darn well should know, that abuse of all descriptions has long since passed the threshold of "epidemic" and is approaching "pervasive". With that in mind, everyone should also realize that it's their obligation to do anything/everything they can to assist the collaborative network community in (a) identifying abusers and (b) denying them services -- permanently. Which means that if, for example, an entity is identified as being involved in network hijacking or phishing or spamming or whatever, that everything known about them should be published -- including scans of any paper documents involved. There is no reason to protect filth like this, and every reason to out them. They flourish, in large part, precisely because that *doesn't* happen. And while Ron's bedside manner might be a little abrasive from time to time (and so's mine, so I'm not criticizing), he's a cupcake compared to kind of sociopaths we're up against. If you can't handle a few mildly toasty comments from him, then you're no match at all for them. So the hell with his prose: focus on the matter at hand. Let's find out what happened here and how, who's responsible, and what it'll take to stop them from doing it again and again. Because they will. ---rsk From marcus.sachs at verizon.com Fri Apr 1 07:41:11 2011 From: marcus.sachs at verizon.com (Sachs, Marcus Hans (Marc)) Date: Fri, 1 Apr 2011 08:41:11 -0400 Subject: v6 Avian Carriers? Message-ID: I was wondering which April 1st this would happen on. Now I know. So if a v6 carrier swallows a v4 datagram does that count as packet loss or tunneling? http://datatracker.ietf.org/doc/rfc6214/ Marc From jeffw at he.net Fri Apr 1 07:45:13 2011 From: jeffw at he.net (Jeff Walter) Date: Fri, 01 Apr 2011 05:45:13 -0700 Subject: v6 Avian Carriers? In-Reply-To: References: Message-ID: <4D95C8D9.4020201@he.net> On 4/1/2011 5:41 AM, Sachs, Marcus Hans (Marc) wrote: > I was wondering which April 1st this would happen on. Now I know. So if a v6 carrier swallows a v4 datagram does that count as packet loss or tunneling? > > http://datatracker.ietf.org/doc/rfc6214/ Depending on whether or not the packet arrived at its destination determines if it is loss or tunneling. In the event it is tunneled, please be certain to filter the packet as de-encapsulation is a bit... messy. -------------- next part -------------- A non-text attachment was scrubbed... Name: jeffw.vcf Type: text/x-vcard Size: 314 bytes Desc: not available URL: From jlarsen at richweb.com Fri Apr 1 08:50:47 2011 From: jlarsen at richweb.com (C. Jon Larsen) Date: Fri, 1 Apr 2011 09:50:47 -0400 (EDT) Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: <20110401123804.GA5883@gsp.org> References: <20110401123804.GA5883@gsp.org> Message-ID: > So the hell with his prose: focus on the matter at hand. Let's find out > what happened here and how, who's responsible, and what it'll take to stop > them from doing it again and again. Well put. -- This message has been scanned for viruses and dangerous content by the Richweb.com outgoing MailScanner and is believed to be clean. From swm at emanon.com Fri Apr 1 09:01:21 2011 From: swm at emanon.com (Scott Morris) Date: Fri, 01 Apr 2011 16:01:21 +0200 Subject: v6 Avian Carriers? In-Reply-To: References: Message-ID: <4D95DAB1.7070706@emanon.com> Mmm... Good question. Would it actually come back OUT in a recognizable (de-encapsulated) manner? I'll vote with packet loss, 'cause tunneling seems pretty gross. ;) Scott On 4/1/11 2:41 PM, Sachs, Marcus Hans (Marc) wrote: > I was wondering which April 1st this would happen on. Now I know. So if a v6 carrier swallows a v4 datagram does that count as packet loss or tunneling? > > http://datatracker.ietf.org/doc/rfc6214/ > > > Marc > > > From graham at g-rock.net Fri Apr 1 09:30:45 2011 From: graham at g-rock.net (=?utf-8?B?R1AgV29vZGVu?=) Date: Fri, 01 Apr 2011 09:30:45 -0500 Subject: =?utf-8?B?UmU6IHY2IEF2aWFuIENhcnJpZXJzPw==?= Message-ID: I wonder on the carrier would survive a DoS attack ... ----- Reply message ----- From: "Scott Morris" Date: Fri, Apr 1, 2011 9:01 am Subject: v6 Avian Carriers? To: Mmm... Good question. Would it actually come back OUT in a recognizable (de-encapsulated) manner? I'll vote with packet loss, 'cause tunneling seems pretty gross. ;) Scott On 4/1/11 2:41 PM, Sachs, Marcus Hans (Marc) wrote: > I was wondering which April 1st this would happen on. Now I know. So if a v6 carrier swallows a v4 datagram does that count as packet loss or tunneling? > > http://datatracker.ietf.org/doc/rfc6214/ > > > Marc > > > From Valdis.Kletnieks at vt.edu Fri Apr 1 10:01:42 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 01 Apr 2011 11:01:42 -0400 Subject: =?utf-8?B?UmU6IHY2IEF2aWFuIENhcnJpZXJzPw==?= In-Reply-To: Your message of "Fri, 01 Apr 2011 09:30:45 CDT." References: Message-ID: <6402.1301670102@localhost> On Fri, 01 Apr 2011 09:30:45 CDT, =?utf-8?B?R1AgV29vZGVu?= said: > wonder on the carrier would survive a DoS attack ... RFC1149 says: Avian carriers can provide high delay, low throughput, and low altitude service. The connection topology is limited to a single point-to-point path for each carrier, used with standard carriers, but many carriers can be used without significant interference with each other, outside of early spring. This is because of the 3D ether space available to the carriers, in contrast to the 1D ether used by IEEE802.3. The carriers have an intrinsic collision avoidance system, which increases availability. The carriers are also (over time) self-regenerating in case one gets lost or corrupted due to collision or interception... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From hank at efes.iucc.ac.il Fri Apr 1 10:03:17 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 1 Apr 2011 18:03:17 +0300 (IDT) Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: <20110401123804.GA5883@gsp.org> References: <20110401123804.GA5883@gsp.org> Message-ID: On Fri, 1 Apr 2011, Rich Kulawiec wrote: > On Fri, Apr 01, 2011 at 01:36:55AM -0400, Atticus wrote: >> Maybe, if you didn't act like a flaming douchebag, and were polite to >> people, they would be more interested in helping you out. > > And were it ten or fifteen years ago, I might agree with you. > > But it's not. By now, everyone knows, or darn well should know, that abuse > of all descriptions has long since passed the threshold of "epidemic" and > is approaching "pervasive". With that in mind, everyone should also realize > that it's their obligation to do anything/everything they can to assist the > collaborative network community in (a) identifying abusers and (b) denying > them services -- permanently. > > Which means that if, for example, an entity is identified as being > involved in network hijacking or phishing or spamming or whatever, that > everything known about them should be published -- including scans of any > paper documents involved. There is no reason to protect filth like this, > and every reason to out them. They flourish, in large part, precisely > because that *doesn't* happen. > > And while Ron's bedside manner might be a little abrasive from time to > time (and so's mine, so I'm not criticizing), he's a cupcake compared to > kind of sociopaths we're up against. If you can't handle a few mildly > toasty comments from him, then you're no match at all for them. > > So the hell with his prose: focus on the matter at hand. Let's find out > what happened here and how, who's responsible, and what it'll take to stop > them from doing it again and again. > > Because they will. > > ---rsk Well put, but falling on deaf ears. "Oh, we are not the police" mantra is either an excuse for being an idiot or too anal to see what should be done. But when gov'ts will step in to make sure this type of issue is fixed in thye future, those same talking heads will be crying about how the Internet is now ruined. I've been down this path all too often to know you are tilting at windmills. Live with it. I do. -Hank From gbonser at seven.com Fri Apr 1 10:44:35 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 1 Apr 2011 08:44:35 -0700 Subject: IPv4 Address Exhaustion Effects on the Earth In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E2BAE@RWC-EX1.corp.seven.com> > From: Joao C. Mendes Ogawa > Sent: Thursday, March 31, 2011 6:14 PM > Subject: Fwd: IPv4 Address Exhaustion Effects on the Earth > > FYI > > --Jonny Ogawa > > ----- Forwarded message from Stephen H. Inden ----- > Dang, I was hoping to see an RFC on Bufferbloat in Avian Carriers and how tail-drop is a messy solution that is to be avoided. Oh well. From bross at pobox.com Fri Apr 1 11:19:21 2011 From: bross at pobox.com (Brandon Ross) Date: Fri, 1 Apr 2011 12:19:21 -0400 (EDT) Subject: =?utf-8?B?UmU6IHY2IEF2aWFuIENhcnJpZXJzPw==?= In-Reply-To: References: Message-ID: On Fri, 1 Apr 2011, GP Wooden wrote: > I wonder on the carrier would survive a DoS attack ... I'm not sure about that, but we know that, if a Sullenberger unit has been installed, a large aircraft can survive a DoS attack perpetrated by the avian carrier. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From grobe0ba at gmail.com Fri Apr 1 11:31:09 2011 From: grobe0ba at gmail.com (Atticus) Date: Fri, 1 Apr 2011 12:31:09 -0400 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: References: <20110401123804.GA5883@gsp.org> Message-ID: Please note, I'm not arguing against fixing the problem. I just think we should show each other some professional respect, and use some manners. From dorn at hetzel.org Fri Apr 1 11:47:58 2011 From: dorn at hetzel.org (Dorn Hetzel) Date: Fri, 1 Apr 2011 12:47:58 -0400 Subject: v6 Avian Carriers? In-Reply-To: References: Message-ID: I was thinking today would be a good day to write an RFC for "fractional DHCP" where end-users can get issued say 1/64 of an v4 IP, say 155.229.10.20:1024-2047. Other users on the same DSLAM, etc behind the carrier NAT would have other shares of the same public IP. :) On Fri, Apr 1, 2011 at 12:19 PM, Brandon Ross wrote: > On Fri, 1 Apr 2011, GP Wooden wrote: > > I wonder on the carrier would survive a DoS attack ... >> > > I'm not sure about that, but we know that, if a Sullenberger unit has been > installed, a large aircraft can survive a DoS attack perpetrated by the > avian carrier. > > -- > Brandon Ross AIM: > BrandonNRoss > ICQ: 2269442 > Skype: brandonross Yahoo: BrandonNRoss > > From streiner at cluebyfour.org Fri Apr 1 12:08:46 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 1 Apr 2011 13:08:46 -0400 (EDT) Subject: v6 Avian Carriers? In-Reply-To: References: Message-ID: On Fri, 1 Apr 2011, Dorn Hetzel wrote: > I was thinking today would be a good day to write an RFC for "fractional > DHCP" where end-users can get issued say 1/64 of an v4 IP, say > 155.229.10.20:1024-2047. Other users on the same DSLAM, etc behind the > carrier NAT would have other shares of the same public IP. :) Would the end-user get both the TCP and UDP ports from their assigned range? Also, how would you handle ICMP/ESP/etc... or would those be 'free with the purchase of..."? jms From dorn at hetzel.org Fri Apr 1 12:28:55 2011 From: dorn at hetzel.org (Dorn Hetzel) Date: Fri, 1 Apr 2011 13:28:55 -0400 Subject: v6 Avian Carriers? In-Reply-To: References: Message-ID: I'm thinking both TCP and UDP, and for ICMP don't NAT's use the sequence number field to keep them separate ? On Fri, Apr 1, 2011 at 1:08 PM, Justin M. Streiner wrote: > On Fri, 1 Apr 2011, Dorn Hetzel wrote: > > I was thinking today would be a good day to write an RFC for "fractional >> DHCP" where end-users can get issued say 1/64 of an v4 IP, say >> 155.229.10.20:1024-2047. Other users on the same DSLAM, etc behind the >> carrier NAT would have other shares of the same public IP. :) >> > > Would the end-user get both the TCP and UDP ports from their assigned > range? Also, how would you handle ICMP/ESP/etc... or would those be 'free > with the purchase of..."? > > jms > > From andy at nosignal.org Fri Apr 1 12:42:07 2011 From: andy at nosignal.org (Andy Davidson) Date: Fri, 1 Apr 2011 18:42:07 +0100 Subject: v6 Avian Carriers? In-Reply-To: References: Message-ID: On 1 Apr 2011, at 17:47, Dorn Hetzel wrote: > I was thinking today would be a good day to write an RFC for "fractional DHCP" where end-users can get issued say 1/64 of an v4 IP, say 155.229.10.20:1024-2047. Other users on the same DSLAM, etc behind the carrier NAT would have other shares of the same public IP. :) Hi, I'm not sure if this is an attempt at a continuation of the April Fools meme, or a serious idea, but this has kind already been thought of. :-) https://mice.cs.columbia.edu/getTechreport.php?techreportID=560 It's a nice illustration that the only idea which doesn't suck post exhaustion[0], is IPv6. Andy [0] i.e., now. From smb at cs.columbia.edu Fri Apr 1 12:45:54 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 1 Apr 2011 13:45:54 -0400 Subject: v6 Avian Carriers? In-Reply-To: References: Message-ID: <872325B0-BD3D-4211-8474-EFAE6BDC6F9E@cs.columbia.edu> On Apr 1, 2011, at 8:41 11AM, Sachs, Marcus Hans (Marc) wrote: > I was wondering which April 1st this would happen on. Now I know. So if a v6 carrier swallows a v4 datagram does that count as packet loss or tunneling? > > http://datatracker.ietf.org/doc/rfc6214/ > I was disappointed in this RFC -- Section 3.1 didn't include the proper discussion of the difference between African and European avian carriers, and we know what happens if that question is asked at the wrong time. > --Steve Bellovin, https://www.cs.columbia.edu/~smb From EricMo at BarrettXplore.com Fri Apr 1 12:47:22 2011 From: EricMo at BarrettXplore.com (Eric Morin) Date: Fri, 1 Apr 2011 14:47:22 -0300 Subject: WiMAX Multihost CPE/MS MTU enforcement Message-ID: Hi Anyone out there deploying multihost CPE/MS with 16e WiMAX? Do your CPEs enforce a specific MTU (1400) for upstream traffic? I would like to hear from anyone (offline) that is dealing with MTU challenges with mulithost 16e deployments. Thanks! Eric Morin From tony at lavanauts.org Fri Apr 1 12:57:53 2011 From: tony at lavanauts.org (Antonio Querubin) Date: Fri, 1 Apr 2011 07:57:53 -1000 (HST) Subject: v6 Avian Carriers? In-Reply-To: <872325B0-BD3D-4211-8474-EFAE6BDC6F9E@cs.columbia.edu> References: <872325B0-BD3D-4211-8474-EFAE6BDC6F9E@cs.columbia.edu> Message-ID: On Fri, 1 Apr 2011, Steven Bellovin wrote: > I was disappointed in this RFC -- Section 3.1 didn't include the proper > discussion of the difference between African and European avian > carriers, and we know what happens if that question is asked at the > wrong time. That discussion would be out of scope for the document's purpose as I believe African and European carriers are currently IP version agnostic. However, rapid genetic changes arising from the increased environmental radiation in the northern hemisphere vs that in the southern hemisphere due to the global circulation of the Japanese radioactive plume may require we revisit this issue in a few years. Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From cscora at apnic.net Fri Apr 1 13:39:22 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 2 Apr 2011 04:39:22 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201104011839.p31IdMmI028804@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 02 Apr, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 351604 Prefixes after maximum aggregation: 159727 Deaggregation factor: 2.20 Unique aggregates announced to Internet: 174049 Total ASes present in the Internet Routing Table: 37146 Prefixes per ASN: 9.47 Origin-only ASes present in the Internet Routing Table: 31182 Origin ASes announcing only one prefix: 15020 Transit ASes present in the Internet Routing Table: 5019 Transit-only ASes present in the Internet Routing Table: 133 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 24 Max AS path prepend of ASN (36992) 22 Prefixes from unregistered ASNs in the Routing Table: 516 Unregistered ASNs in the Routing Table: 226 Number of 32-bit ASNs allocated by the RIRs: 1247 Number of 32-bit ASNs visible in the Routing Table: 945 Prefixes from 32-bit ASNs in the Routing Table: 2086 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 194 Number of addresses announced to Internet: 2393096992 Equivalent to 142 /8s, 163 /16s and 195 /24s Percentage of available address space announced: 64.6 Percentage of allocated address space announced: 64.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 90.1 Total number of prefixes smaller than registry allocations: 145654 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 87503 Total APNIC prefixes after maximum aggregation: 29875 APNIC Deaggregation factor: 2.93 Prefixes being announced from the APNIC address blocks: 84414 Unique aggregates announced from the APNIC address blocks: 36682 APNIC Region origin ASes present in the Internet Routing Table: 4385 APNIC Prefixes per ASN: 19.25 APNIC Region origin ASes announcing only one prefix: 1219 APNIC Region transit ASes present in the Internet Routing Table: 696 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 20 Number of APNIC region 32-bit ASNs visible in the Routing Table: 45 Number of APNIC addresses announced to Internet: 601819680 Equivalent to 35 /8s, 223 /16s and 10 /24s Percentage of available APNIC address space announced: 76.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 138612 Total ARIN prefixes after maximum aggregation: 70802 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 111113 Unique aggregates announced from the ARIN address blocks: 45000 ARIN Region origin ASes present in the Internet Routing Table: 14282 ARIN Prefixes per ASN: 7.78 ARIN Region origin ASes announcing only one prefix: 5446 ARIN Region transit ASes present in the Internet Routing Table: 1486 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 10 Number of ARIN addresses announced to Internet: 797373184 Equivalent to 47 /8s, 134 /16s and 243 /24s Percentage of available ARIN address space announced: 63.4 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 83154 Total RIPE prefixes after maximum aggregation: 47505 RIPE Deaggregation factor: 1.75 Prefixes being announced from the RIPE address blocks: 76419 Unique aggregates announced from the RIPE address blocks: 50301 RIPE Region origin ASes present in the Internet Routing Table: 15463 RIPE Prefixes per ASN: 4.94 RIPE Region origin ASes announcing only one prefix: 7788 RIPE Region transit ASes present in the Internet Routing Table: 2418 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 23 Number of RIPE region 32-bit ASNs visible in the Routing Table: 698 Number of RIPE addresses announced to Internet: 465539072 Equivalent to 27 /8s, 191 /16s and 144 /24s Percentage of available RIPE address space announced: 75.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 32380 Total LACNIC prefixes after maximum aggregation: 7383 LACNIC Deaggregation factor: 4.39 Prefixes being announced from the LACNIC address blocks: 31277 Unique aggregates announced from the LACNIC address blocks: 16289 LACNIC Region origin ASes present in the Internet Routing Table: 1442 LACNIC Prefixes per ASN: 21.69 LACNIC Region origin ASes announcing only one prefix: 436 LACNIC Region transit ASes present in the Internet Routing Table: 264 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 187 Number of LACNIC addresses announced to Internet: 81603200 Equivalent to 4 /8s, 221 /16s and 42 /24s Percentage of available LACNIC address space announced: 54.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7606 Total AfriNIC prefixes after maximum aggregation: 1823 AfriNIC Deaggregation factor: 4.17 Prefixes being announced from the AfriNIC address blocks: 5989 Unique aggregates announced from the AfriNIC address blocks: 1872 AfriNIC Region origin ASes present in the Internet Routing Table: 440 AfriNIC Prefixes per ASN: 13.61 AfriNIC Region origin ASes announcing only one prefix: 131 AfriNIC Region transit ASes present in the Internet Routing Table: 98 Average AfriNIC Region AS path length visible: 5.1 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 5 Number of AfriNIC addresses announced to Internet: 22723328 Equivalent to 1 /8s, 90 /16s and 187 /24s Percentage of available AfriNIC address space announced: 33.9 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2431 9514 905 Korea Telecom (KIX) 7545 1543 301 83 TPG Internet Pty Ltd 17974 1445 480 33 PT TELEKOMUNIKASI INDONESIA 4755 1435 634 167 TATA Communications formerly 24560 1135 322 204 Bharti Airtel Ltd., Telemedia 9583 1055 77 494 Sify Limited 4808 1024 2100 290 CNCGROUP IP network: China169 9829 1006 869 51 BSNL National Internet Backbo 17488 940 162 98 Hathway IP Over Cable Interne 18101 935 116 139 Reliance Infocom Ltd Internet Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3670 3838 257 bellsouth.net, inc. 4323 2559 1090 396 Time Warner Telecom 1785 1787 681 131 PaeTec Communications, Inc. 18566 1606 331 195 Covad Communications 6478 1591 304 44 AT&T Worldnet Services 20115 1532 1541 641 Charter Communications 19262 1489 4935 303 Verizon Global Networks 7018 1356 6785 882 AT&T WorldNet Services 11492 1327 240 15 Cable One 22773 1292 2865 84 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6830 514 1780 318 UPC Distribution Services 34984 484 97 186 BILISIM TELEKOM 3292 454 2013 391 TDC Tele Danmark 8866 446 134 26 Bulgarian Telecommunication C 20940 428 108 330 Akamai Technologies European 9198 424 267 15 Kazakhtelecom Data Network Ad 3320 413 7604 359 Deutsche Telekom AG 8551 403 353 46 Bezeq International 12479 398 577 6 Uni2 Autonomous System 702 395 1800 308 UUNET - Commercial IP service Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1405 262 152 TVCABLE BOGOTA 28573 1259 969 84 NET Servicos de Comunicao S.A 8151 1248 2680 372 UniNet S.A. de C.V. 6503 1116 354 72 AVANTEL, S.A. 7303 925 465 147 Telecom Argentina Stet-France 14420 642 52 91 CORPORACION NACIONAL DE TELEC 22047 567 310 15 VTR PUNTO NET S.A. 3816 515 225 98 Empresa Nacional de Telecomun 11172 486 83 79 Servicios Alestra S.A de C.V 27947 480 53 53 Telconet S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 839 445 11 TEDATA 24863 774 147 39 LINKdotNET AS number 15475 421 90 8 Nile Online 36992 292 271 14 Etisalat MISR 3741 265 985 227 The Internet Solution 24835 232 78 10 RAYA Telecom - Egypt 6713 231 215 12 Itissalat Al-MAGHRIB 33776 227 13 5 Starcomms Nigeria Limited 29571 192 17 11 Ci Telecom Autonomous system 16637 146 441 85 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3670 3838 257 bellsouth.net, inc. 4323 2559 1090 396 Time Warner Telecom 4766 2431 9514 905 Korea Telecom (KIX) 23456 2086 503 1120 32-bit ASN transition 1785 1787 681 131 PaeTec Communications, Inc. 18566 1606 331 195 Covad Communications 6478 1591 304 44 AT&T Worldnet Services 7545 1543 301 83 TPG Internet Pty Ltd 20115 1532 1541 641 Charter Communications 19262 1489 4935 303 Verizon Global Networks Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2559 2163 Time Warner Telecom 1785 1787 1656 PaeTec Communications, Inc. 6478 1591 1547 AT&T Worldnet Services 4766 2431 1526 Korea Telecom (KIX) 7545 1543 1460 TPG Internet Pty Ltd 17974 1445 1412 PT TELEKOMUNIKASI INDONESIA 18566 1606 1411 Covad Communications 11492 1327 1312 Cable One 4755 1435 1268 TATA Communications formerly 10620 1405 1253 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 1.3.0.0/16 38639 NTT Communications Corporatio 2.56.0.0/16 44559 E-Rent LLC 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 31.170.224.0/19 29049 AzerSat LLC. 31.171.0.0/17 29049 AzerSat LLC. Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:11 /10:26 /11:74 /12:218 /13:448 /14:769 /15:1375 /16:11576 /17:5715 /18:9422 /19:19073 /20:24863 /21:25322 /22:33630 /23:32170 /24:183709 /25:1139 /26:1280 /27:708 /28:40 /29:9 /30:2 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2264 3670 bellsouth.net, inc. 18566 1585 1606 Covad Communications 6478 1545 1591 AT&T Worldnet Services 4323 1377 2559 Time Warner Telecom 10620 1295 1405 TVCABLE BOGOTA 11492 1276 1327 Cable One 23456 1108 2086 32-bit ASN transition 7011 1064 1164 Citizens Utilities 1785 1056 1787 PaeTec Communications, Inc. 6503 900 1116 AVANTEL, S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:296 2:54 4:14 5:1 8:347 12:2014 13:1 14:430 15:15 16:3 17:8 20:9 23:5 24:1597 27:710 31:53 32:60 33:3 34:2 37:1 38:751 39:1 40:101 41:2370 42:1 44:3 46:791 47:4 49:141 50:139 52:13 55:7 56:2 57:30 58:827 59:487 60:387 61:1142 62:1008 63:1909 64:3876 65:2337 66:4321 67:1809 68:1079 69:2906 70:697 71:343 72:1895 73:1 74:2328 75:285 76:336 77:851 78:694 79:451 80:1080 81:820 82:507 83:464 84:646 85:1032 86:555 87:762 88:339 89:1555 90:174 91:3652 92:510 93:1040 94:1232 95:785 96:459 97:253 98:817 99:35 101:49 106:1 107:4 108:80 109:927 110:518 111:680 112:324 113:385 114:508 115:669 116:934 117:678 118:767 119:1130 120:287 121:710 122:1611 123:1057 124:1286 125:1249 128:265 129:174 130:172 131:561 132:109 133:20 134:216 135:49 136:212 137:142 138:300 139:105 140:486 141:173 142:378 143:390 144:483 145:52 146:442 147:202 148:639 149:271 150:166 151:187 152:298 153:180 154:3 155:390 156:187 157:349 158:131 159:381 160:317 161:211 162:277 163:166 164:493 165:349 166:503 167:414 168:722 169:154 170:784 171:74 172:2 173:1260 174:531 175:351 177:70 178:784 180:799 181:4 182:407 183:197 184:237 185:1 186:1117 187:905 188:925 189:1038 190:4807 192:5768 193:4796 194:3479 195:2942 196:1204 197:15 198:3594 199:3879 200:5570 201:1485 202:8366 203:8452 204:4129 205:2321 206:2647 207:3023 208:3914 209:3504 210:2720 211:1366 212:1970 213:1707 214:758 215:66 216:4849 217:1630 218:557 219:373 220:1194 221:480 222:318 223:104 End of report From dedelman at iname.com Fri Apr 1 15:34:48 2011 From: dedelman at iname.com (Dave Edelman) Date: Fri, 1 Apr 2011 16:34:48 -0400 Subject: v6 Avian Carriers? In-Reply-To: References: Message-ID: <013A3D42-2BE0-446C-9D62-F2969BF740B8@iname.com> I believe that the Sullenberger unit effected the loss of the avian carriers requiring regeneration and retransmission. Dave Edelman On Apr 1, 2011, at 12:19, Brandon Ross wrote: > On Fri, 1 Apr 2011, GP Wooden wrote: > >> I wonder on the carrier would survive a DoS attack ... > > I'm not sure about that, but we know that, if a Sullenberger unit has been installed, a large aircraft can survive a DoS attack perpetrated by the avian carrier. > > -- > Brandon Ross AIM: BrandonNRoss > ICQ: 2269442 > Skype: brandonross Yahoo: BrandonNRoss > From james.cutler at consultant.com Fri Apr 1 15:44:54 2011 From: james.cutler at consultant.com (Cutler James R) Date: Fri, 1 Apr 2011 16:44:54 -0400 Subject: v6 Avian Carriers? In-Reply-To: References: Message-ID: <1A098CD1-EBD5-4764-9376-B74BD09DEC31@consultant.com> On Apr 1, 2011, at 1:28 PM, Dorn Hetzel wrote: > I'm thinking both TCP and UDP, and for ICMP don't NAT's use the sequence > number field to keep them separate ? > In my experience, the Avian Carriers usually eat the NATs. James R. Cutler james.cutler at consultant.com From richard.barnes at gmail.com Fri Apr 1 15:45:49 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Fri, 1 Apr 2011 22:45:49 +0200 Subject: v6 Avian Carriers? In-Reply-To: References: Message-ID: Be careful what you wish for: On Fri, Apr 1, 2011 at 6:47 PM, Dorn Hetzel wrote: > I was thinking today would be a good day to write an RFC for "fractional > DHCP" where end-users can get issued say 1/64 of an v4 IP, say > 155.229.10.20:1024-2047. ?Other users on the same DSLAM, etc behind the > carrier NAT would have other shares of the same public IP. ? :) > > On Fri, Apr 1, 2011 at 12:19 PM, Brandon Ross wrote: > >> On Fri, 1 Apr 2011, GP Wooden wrote: >> >> ?I wonder on the carrier would survive a DoS attack ... >>> >> >> I'm not sure about that, but we know that, if a Sullenberger unit has been >> installed, a large aircraft can survive a DoS attack perpetrated by the >> avian carrier. >> >> -- >> Brandon Ross ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?AIM: >> ?BrandonNRoss >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ICQ: ?2269442 >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Skype: ?brandonross ?Yahoo: ?BrandonNRoss >> >> > From cidr-report at potaroo.net Fri Apr 1 17:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 Apr 2011 22:00:01 GMT Subject: BGP Update Report Message-ID: <201104012200.p31M01nN096412@wattle.apnic.net> BGP Update Report Interval: 24-Mar-11 -to- 31-Mar-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS19743 34999 1.7% 4999.9 -- 2 - AS9829 26736 1.3% 26.6 -- BSNL-NIB National Internet Backbone 3 - AS4230 26664 1.3% 410.2 -- Embratel 4 - AS11492 20928 1.0% 15.7 -- CABLEONE - CABLE ONE, INC. 5 - AS1785 19164 0.9% 10.6 -- AS-PAETEC-NET - PaeTec Communications, Inc. 6 - AS32528 18507 0.9% 2313.4 -- ABBOTT Abbot Labs 7 - AS35931 13922 0.7% 2320.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - AS27738 13691 0.7% 40.4 -- Ecuadortelecom S.A. 9 - AS44609 13408 0.7% 4469.3 -- FNA Fars News Agency Cultural Arts Institute 10 - AS17974 12580 0.6% 8.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 11 - AS6389 11461 0.6% 3.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 12 - AS9498 10309 0.5% 13.1 -- BBIL-AP BHARTI Airtel Ltd. 13 - AS25220 10035 0.5% 716.8 -- GLOBALNOC-AS Averbo GmbH 14 - AS20115 9533 0.5% 6.0 -- CHARTER-NET-HKY-NC - Charter Communications 15 - AS4583 9329 0.5% 345.5 -- WESTPUB-A - West Publishing Corporation 16 - AS28519 8906 0.4% 2968.7 -- Universidad Autonoma de Guadalajara, A.C. 17 - AS7491 8762 0.4% 94.2 -- PI-PH-AS-AP PI-PHILIPINES 18 - AS31148 8457 0.4% 22.8 -- FREENET-AS FreeNet ISP 19 - AS12175 8294 0.4% 202.3 -- YELMNET - Yelm Telephone Company 20 - AS33475 7989 0.4% 37.2 -- RSN-1 - RockSolid Network, Inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS51280 6055 0.3% 6055.0 -- AS51280 Parsian Electronic Commerce Company 2 - AS19743 34999 1.7% 4999.9 -- 3 - AS44609 13408 0.7% 4469.3 -- FNA Fars News Agency Cultural Arts Institute 4 - AS27771 6726 0.3% 3363.0 -- Instituto Venezolano de Investigaciones Cientificas 5 - AS28519 8906 0.4% 2968.7 -- Universidad Autonoma de Guadalajara, A.C. 6 - AS35931 13922 0.7% 2320.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 7 - AS32528 18507 0.9% 2313.4 -- ABBOTT Abbot Labs 8 - AS49600 1514 0.1% 1514.0 -- LASEDA La Seda de Barcelona, S.A 9 - AS25911 1035 0.1% 1035.0 -- TALISMAN-CH3 - TALISMAN ENERGY INC. 10 - AS13168 871 0.0% 871.0 -- SANOSTRA-AS AS de la Caja de ahorros y monte de piedad de las Baleares 11 - AS25220 10035 0.5% 716.8 -- GLOBALNOC-AS Averbo GmbH 12 - AS19984 522 0.0% 522.0 -- VSECU-ASN - Vermont State Employees Credit Union 13 - AS22288 507 0.0% 507.0 -- RFBKCORP - Republic First Bancorp, Inc. 14 - AS22060 497 0.0% 497.0 -- NETSPECTRUM - Netspectrum Wireless Internet Solutions 15 - AS12103 972 0.1% 486.0 -- KEYNOTE - Keynote Systems, Inc. 16 - AS27582 2711 0.1% 451.8 -- PTC-OKC-ASN - Perimeter Technology Center, LLC 17 - AS32514 1806 0.1% 451.5 -- COMEDCOM - CoMedia Communications, Inc. 18 - AS20094 1296 0.1% 432.0 -- MIDWEST-TEL - Midwest Telnet 19 - AS51983 862 0.0% 431.0 -- PROEVOLUTION PROEVOLUTION SRL 20 - AS27573 423 0.0% 423.0 -- OSLA-AS-1 - OKLAHOMA STUDENT LOAN AUTHORITY TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 85.197.100.0/22 9977 0.5% AS25220 -- GLOBALNOC-AS Averbo GmbH 2 - 130.36.34.0/24 9245 0.4% AS32528 -- ABBOTT Abbot Labs 3 - 130.36.35.0/24 9245 0.4% AS32528 -- ABBOTT Abbot Labs 4 - 63.211.68.0/22 8037 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - 221.121.96.0/19 6906 0.3% AS7491 -- PI-PH-AS-AP PI-PHILIPINES 6 - 178.22.79.0/24 6779 0.3% AS44609 -- FNA Fars News Agency Cultural Arts Institute 7 - 65.122.196.0/24 6654 0.3% AS19743 -- 8 - 178.22.72.0/21 6618 0.3% AS44609 -- FNA Fars News Agency Cultural Arts Institute 9 - 212.80.25.0/24 6055 0.3% AS51280 -- AS51280 Parsian Electronic Commerce Company 10 - 72.164.144.0/24 5684 0.3% AS19743 -- 11 - 65.162.204.0/24 5665 0.3% AS19743 -- 12 - 65.163.182.0/24 5665 0.3% AS19743 -- 13 - 66.238.91.0/24 5665 0.3% AS19743 -- 14 - 66.89.98.0/24 5665 0.3% AS19743 -- 15 - 198.140.43.0/24 5575 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 16 - 202.92.235.0/24 5286 0.2% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 17 - 68.65.152.0/22 3653 0.2% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 18 - 202.153.174.0/24 3566 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 19 - 192.65.152.0/24 3367 0.2% AS27771 -- Instituto Venezolano de Investigaciones Cientificas 20 - 190.170.128.0/18 3359 0.2% AS27771 -- Instituto Venezolano de Investigaciones Cientificas Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Apr 1 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 Apr 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201104012200.p31M00Jt096406@wattle.apnic.net> This report has been generated at Fri Apr 1 21:12:20 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 25-03-11 354537 207782 26-03-11 354465 207768 27-03-11 354472 207904 28-03-11 354508 208231 29-03-11 354730 208127 30-03-11 354720 207889 31-03-11 355112 208078 01-04-11 354967 207765 AS Summary 37242 Number of ASes in routing system 15683 Number of ASes announcing only one prefix 3669 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 109515264 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 01Apr11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 354805 207776 147029 41.4% All ASes AS6389 3669 262 3407 92.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2545 400 2145 84.3% TWTC - tw telecom holdings, inc. AS4766 2431 917 1514 62.3% KIXS-AS-KR Korea Telecom AS6478 1591 183 1408 88.5% ATT-INTERNET3 - AT&T Services, Inc. AS22773 1292 93 1199 92.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS19262 1489 303 1186 79.7% VZGNI-TRANSIT - Verizon Online LLC AS10620 1405 289 1116 79.4% Telmex Colombia S.A. AS4755 1437 358 1079 75.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1790 768 1022 57.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS18566 1606 628 978 60.9% COVAD - Covad Communications Co. AS28573 1263 325 938 74.3% NET Servicos de Comunicao S.A. AS6503 1117 324 793 71.0% Axtel, S.A.B. de C.V. AS24560 1135 346 789 69.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7545 1545 760 785 50.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 935 151 784 83.9% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS7303 923 192 731 79.2% Telecom Argentina S.A. AS4808 1036 325 711 68.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS8151 1250 540 710 56.8% Uninet S.A. de C.V. AS3356 1177 488 689 58.5% LEVEL3 Level 3 Communications AS11492 1325 649 676 51.0% CABLEONE - CABLE ONE, INC. AS17488 940 290 650 69.1% HATHWAY-NET-AP Hathway IP Over Cable Internet AS17676 659 70 589 89.4% GIGAINFRA Softbank BB Corp. AS855 632 57 575 91.0% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS3549 923 383 540 58.5% GBLX Global Crossing Ltd. AS14420 642 103 539 84.0% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS7552 636 100 536 84.3% VIETEL-AS-AP Vietel Corporation AS22047 567 31 536 94.5% VTR BANDA ANCHA S.A. AS22561 861 331 530 61.6% DIGITAL-TELEPORT - Digital Teleport Inc. AS4780 717 210 507 70.7% SEEDNET Digital United Inc. AS9443 570 74 496 87.0% INTERNETPRIMUS-AS-AP Primus Telecommunications Total 38108 9950 28158 73.9% Top 30 total Possible Bogus Routes 1.3.0.0/16 AS38639 HANABI NTT Communications Corporation 2.56.0.0/16 AS44559 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 24.48.0.0/14 AS5769 VIDEOTRON - Videotron Telecom Ltee 24.225.128.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/23 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.224.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.237.0/24 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.248.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 31.172.0.0/17 AS39138 OPENAP-WIRELESS-NETWORKS-AS rrbone UG (haftungsbeschraenkt) 41.57.192.0/18 AS22750 BCSNET 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 45.127.0.0/16 AS13767 DBANK - DataBank Holdings, Ltd. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.207.192.0/24 AS30304 64.207.193.0/24 AS30304 64.207.194.0/24 AS30304 64.207.195.0/24 AS30304 64.207.196.0/24 AS30304 64.207.197.0/24 AS30304 64.207.198.0/24 AS30304 64.207.200.0/24 AS30304 64.207.201.0/24 AS30304 64.207.202.0/24 AS30304 64.207.203.0/24 AS30304 64.207.204.0/24 AS30304 64.207.205.0/24 AS30304 64.207.206.0/24 AS30304 64.207.208.0/20 AS30304 66.171.32.0/20 AS16626 GNAXNET-AS - Global Net Access, LLC 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 148.163.0.0/20 AS3356 LEVEL3 Level 3 Communications 148.163.64.0/20 AS3356 LEVEL3 Level 3 Communications 148.163.224.0/19 AS3356 LEVEL3 Level 3 Communications 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.33.69.0/24 AS36992 ETISALAT-MISR 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.145.251.0/24 AS10026 PACNET Pacnet Global Ltd 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.33.84.0/22 AS9911 CONNECTPLUS-AP Singapore Telecom 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.73.0/24 AS26061 Equant Colombia 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.20.108.0/23 AS17885 JKTXLNET-AS-AP PT Excelcomindo Pratama 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.22.78.0/24 AS18117 HARBOURMSP-AU-AP Harbour MSP Pty. Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.27.123.0/24 AS4739 INTERNODE-AS Internode Pty Ltd 203.30.26.0/23 AS3491 BTN-ASN - Beyond The Network America, Inc. 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.64.240.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.241.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.242.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.243.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.244.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.247.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.67.240.0/21 AS27325 CORENAP-AS - Core NAP, L.P. 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.105.192.0/23 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.105.196.0/23 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.105.200.0/21 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From ospfisisis at gmail.com Fri Apr 1 19:14:41 2011 From: ospfisisis at gmail.com (Mark Wall) Date: Fri, 1 Apr 2011 20:14:41 -0400 Subject: Embratel or GVT contact Message-ID: Is there anyone from GVT or Embratel with a clue willing to help me with a BGP route issue we are seeing? Thanks From aoxomoxoa at sunlightdata.com Fri Apr 1 19:46:48 2011 From: aoxomoxoa at sunlightdata.com (Fred Heutte) Date: Fri, 1 Apr 2011 17:46:48 -0700 Subject: v6 Avian Carriers? Message-ID: <201104020046.p320kofT046192@stark.hevanet.com> which reminds me.... ---------------- Mr. ENGINEER: (yelling and hitting the send button repeatedly) 'ELLO NOC!!!!! Testing! Testing! Testing! Testing! This is your nine o'clock customer call! (Takes RFC 791 out of the binder and thumps it on the counter. Throws it up in the air and watches it plummet to the floor.) Mr. ENGINEER: Now that's what I call a dead protocol. NETWORK OPERATOR FROM HELL: No, no.....No, 'e's truncated! Mr. ENGINEER: TRUNCATED!? NOFH: Yeah! You truncated him, just as he was bein' refactored! Datagrams truncate easily, major. Mr. ENGINEER: Um...now look...now look, mate, I've definitely 'ad enough of this. That packet is definitely deceased, and when I deployed it not 'alf an hour ago, you assured me that its total lack of throughput was due to it bein' tired and shagged out following a prolonged reroute. NOFH: Well, he's...he's, ah...probably pining for the big iron. Mr. ENGINEER: PININ' for the BIG IRON?!?!?!? What kind of talk is that?, look, why did he fall flat on his back the moment I got 'im through the router? NOFH: The 4-byte prefers keepin' on it's back! Remarkable protocol, id'nit, squire? Lovely octets! Mr. ENGINEER: Look, I took the liberty of examining that packet when I dispatched it, and I discovered the only reason that it had been sitting in its queue in the first place was that it had been SWAPPED there. (pause) NOFH: Well, o'course it was swapped there! If I hadn't swapped that packet, it would have nuzzled up to that DMZ, bent it apart with its handshake, and VOOM! Feeweeweewee! Mr. ENGINEER: "VOOM"?!? Mate, this packet wouldn't "voom" if you put four million hop counts on it! 'E's bleedin' demised! NOFH: No no! 'E's pining! Mr. ENGINEER: 'E's not pinin'! 'E's passed on! This packet is no more! He has ceased to be! 'E's expired and gone to meet 'is archive! 'E's a null set! Bereft of destination, 'e rests in /dev/null! If you hadn't swapped 'im to the top of the queue 'e'd be pushing off the stack! 'Is traceroutes are now 'istory! 'E's off the wire! 'E's kicked the bit bucket, 'e's shuffled off the interwebs, run 'init 0' and joined the bleedin' choir deprecated!! THIS IS AN EX-PACKET!! ----------------- > >On Apr 1, 2011, at 8:41 11AM, Sachs, Marcus Hans (Marc) wrote: > >> I was wondering which April 1st this would happen on. Now I know. So if a v6 carrier swallows a v4 datagram does that count as packet loss or tunneling? >> >> http://datatracker.ietf.org/doc/rfc6214/ >> > >I was disappointed in this RFC -- Section 3.1 didn't include the proper discussion of the difference between African and European avian carriers, and we know what happens if that question is asked at the wrong time. >> > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > > From owen at delong.com Fri Apr 1 20:07:09 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Apr 2011 18:07:09 -0700 Subject: v6 Avian Carriers? In-Reply-To: References: Message-ID: <58DA218F-4F30-4AFB-B42B-73040501E887@delong.com> It's also especially sensitive to icing induced packet loss. Owen On Apr 1, 2011, at 7:30 AM, GP Wooden wrote: > I wonder on the carrier would survive a DoS attack ... > > ----- Reply message ----- > From: "Scott Morris" > Date: Fri, Apr 1, 2011 9:01 am > Subject: v6 Avian Carriers? > To: > > Mmm... Good question. Would it actually come back OUT in a > recognizable (de-encapsulated) manner? > > I'll vote with packet loss, 'cause tunneling seems pretty gross. ;) > > Scott > > > On 4/1/11 2:41 PM, Sachs, Marcus Hans (Marc) wrote: >> I was wondering which April 1st this would happen on. Now I know. So if a v6 carrier swallows a v4 datagram does that count as packet loss or tunneling? >> >> http://datatracker.ietf.org/doc/rfc6214/ >> >> >> Marc >> >> >> > > From mksmith at adhost.com Fri Apr 1 20:26:59 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Sat, 2 Apr 2011 01:26:59 +0000 Subject: v6 Avian Carriers? In-Reply-To: <58DA218F-4F30-4AFB-B42B-73040501E887@delong.com> Message-ID: I thought iced-over fiber was a little bit like muffler-bearings. Great excuse if they buy it. Mike On 4/1/11 6:07 PM, "Owen DeLong" wrote: >It's also especially sensitive to icing induced packet loss. > >Owen > >On Apr 1, 2011, at 7:30 AM, GP Wooden wrote: > >> I wonder on the carrier would survive a DoS attack ... >> >> ----- Reply message ----- >> From: "Scott Morris" >> Date: Fri, Apr 1, 2011 9:01 am >> Subject: v6 Avian Carriers? >> To: >> >> Mmm... Good question. Would it actually come back OUT in a >> recognizable (de-encapsulated) manner? >> >> I'll vote with packet loss, 'cause tunneling seems pretty gross. ;) >> >> Scott >> >> >> On 4/1/11 2:41 PM, Sachs, Marcus Hans (Marc) wrote: >>> I was wondering which April 1st this would happen on. Now I know. >>>So if a v6 carrier swallows a v4 datagram does that count as packet >>>loss or tunneling? >>> >>> http://datatracker.ietf.org/doc/rfc6214/ >>> >>> >>> Marc >>> >>> >>> >> >> > > From owen at delong.com Fri Apr 1 20:24:00 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Apr 2011 18:24:00 -0700 Subject: v6 Avian Carriers? In-Reply-To: References: Message-ID: <29DF17B0-5D47-4196-938C-893358D9B96B@delong.com> On Apr 1, 2011, at 9:19 AM, Brandon Ross wrote: > On Fri, 1 Apr 2011, GP Wooden wrote: > >> I wonder on the carrier would survive a DoS attack ... > > I'm not sure about that, but we know that, if a Sullenberger unit has been installed, a large aircraft can survive a DoS attack perpetrated by the avian carrier. > > -- > Brandon Ross AIM: BrandonNRoss > ICQ: 2269442 > Skype: brandonross Yahoo: BrandonNRoss Not true. The occupants of the aircraft survived. The aircraft did not. Owen From owen at delong.com Fri Apr 1 20:27:23 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Apr 2011 18:27:23 -0700 Subject: v6 Avian Carriers? In-Reply-To: <872325B0-BD3D-4211-8474-EFAE6BDC6F9E@cs.columbia.edu> References: <872325B0-BD3D-4211-8474-EFAE6BDC6F9E@cs.columbia.edu> Message-ID: <5823114E-7E5F-4874-85C1-947F58AB0937@delong.com> On Apr 1, 2011, at 10:45 AM, Steven Bellovin wrote: > > On Apr 1, 2011, at 8:41 11AM, Sachs, Marcus Hans (Marc) wrote: > >> I was wondering which April 1st this would happen on. Now I know. So if a v6 carrier swallows a v4 datagram does that count as packet loss or tunneling? >> >> http://datatracker.ietf.org/doc/rfc6214/ >> > > I was disappointed in this RFC -- Section 3.1 didn't include the proper discussion of the difference between African and European avian carriers, and we know what happens if that question is asked at the wrong time. >> > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > That applies to swallows. I'm not sure pidgeons pose the same issue. I think in general, swallows provide poor platforms for avian transport of IP datagrams. Owen From nanog at thedaileyplanet.com Fri Apr 1 20:34:52 2011 From: nanog at thedaileyplanet.com (Chad Dailey) Date: Fri, 1 Apr 2011 20:34:52 -0500 Subject: v6 Avian Carriers? In-Reply-To: <5823114E-7E5F-4874-85C1-947F58AB0937@delong.com> References: <872325B0-BD3D-4211-8474-EFAE6BDC6F9E@cs.columbia.edu> <5823114E-7E5F-4874-85C1-947F58AB0937@delong.com> Message-ID: Swallows have MTU issues. On Fri, Apr 1, 2011 at 8:27 PM, Owen DeLong wrote: > > On Apr 1, 2011, at 10:45 AM, Steven Bellovin wrote: > > > > > On Apr 1, 2011, at 8:41 11AM, Sachs, Marcus Hans (Marc) wrote: > > > >> I was wondering which April 1st this would happen on. Now I know. So > if a v6 carrier swallows a v4 datagram does that count as packet loss or > tunneling? > >> > >> http://datatracker.ietf.org/doc/rfc6214/ > >> > > > > I was disappointed in this RFC -- Section 3.1 didn't include the proper > discussion of the difference between African and European avian carriers, > and we know what happens if that question is asked at the wrong time. > >> > > > > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > > > > > > That applies to swallows. I'm not sure pidgeons pose the same issue. I > think in general, swallows > provide poor platforms for avian transport of IP datagrams. > > > Owen > > > > From owen at delong.com Fri Apr 1 20:49:28 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Apr 2011 18:49:28 -0700 Subject: v6 Avian Carriers? In-Reply-To: References: <872325B0-BD3D-4211-8474-EFAE6BDC6F9E@cs.columbia.edu> <5823114E-7E5F-4874-85C1-947F58AB0937@delong.com> Message-ID: <8527CE4A-FD55-4963-BCA8-36865C47B2FA@delong.com> Which? African or European Swallows? (Watches Chad fly over the cliff edge) ;-) Owen On Apr 1, 2011, at 6:34 PM, Chad Dailey wrote: > Swallows have MTU issues. > > On Fri, Apr 1, 2011 at 8:27 PM, Owen DeLong wrote: > > On Apr 1, 2011, at 10:45 AM, Steven Bellovin wrote: > > > > > On Apr 1, 2011, at 8:41 11AM, Sachs, Marcus Hans (Marc) wrote: > > > >> I was wondering which April 1st this would happen on. Now I know. So if a v6 carrier swallows a v4 datagram does that count as packet loss or tunneling? > >> > >> http://datatracker.ietf.org/doc/rfc6214/ > >> > > > > I was disappointed in this RFC -- Section 3.1 didn't include the proper discussion of the difference between African and European avian carriers, and we know what happens if that question is asked at the wrong time. > >> > > > > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > > > > > > That applies to swallows. I'm not sure pidgeons pose the same issue. I think in general, swallows > provide poor platforms for avian transport of IP datagrams. > > > Owen > > > > From bross at pobox.com Fri Apr 1 20:53:21 2011 From: bross at pobox.com (Brandon Ross) Date: Fri, 1 Apr 2011 21:53:21 -0400 (EDT) Subject: v6 Avian Carriers? In-Reply-To: <29DF17B0-5D47-4196-938C-893358D9B96B@delong.com> References: <29DF17B0-5D47-4196-938C-893358D9B96B@delong.com> Message-ID: On Fri, 1 Apr 2011, Owen DeLong wrote: > Not true. > > The occupants of the aircraft survived. The aircraft did not. Hm, in my recollection the payload made it to the destination. Perhaps the route was a bit unexpected though. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From smb at cs.columbia.edu Fri Apr 1 20:57:17 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 1 Apr 2011 21:57:17 -0400 Subject: v6 Avian Carriers? In-Reply-To: <8527CE4A-FD55-4963-BCA8-36865C47B2FA@delong.com> References: <872325B0-BD3D-4211-8474-EFAE6BDC6F9E@cs.columbia.edu> <5823114E-7E5F-4874-85C1-947F58AB0937@delong.com> <8527CE4A-FD55-4963-BCA8-36865C47B2FA@delong.com> Message-ID: On Apr 1, 2011, at 9:49 PM, Owen DeLong wrote: > Which? African or European Swallows? > > (Watches Chad fly over the cliff edge) ;-) So the RFC needed more text in it's Security Considerations section, too... > > > Owen > > On Apr 1, 2011, at 6:34 PM, Chad Dailey wrote: > >> Swallows have MTU issues. >> >> On Fri, Apr 1, 2011 at 8:27 PM, Owen DeLong wrote: >> >> On Apr 1, 2011, at 10:45 AM, Steven Bellovin wrote: >> >> > >> > On Apr 1, 2011, at 8:41 11AM, Sachs, Marcus Hans (Marc) wrote: >> > >> >> I was wondering which April 1st this would happen on. Now I know. So if a v6 carrier swallows a v4 datagram does that count as packet loss or tunneling? >> >> >> >> http://datatracker.ietf.org/doc/rfc6214/ >> >> >> > >> > I was disappointed in this RFC -- Section 3.1 didn't include the proper discussion of the difference between African and European avian carriers, and we know what happens if that question is asked at the wrong time. >> >> >> > >> > >> > --Steve Bellovin, https://www.cs.columbia.edu/~smb >> > >> > >> > >> > >> > >> That applies to swallows. I'm not sure pidgeons pose the same issue. I think in general, swallows >> provide poor platforms for avian transport of IP datagrams. >> >> >> Owen >> >> >> >> > From outsider at scarynet.org Fri Apr 1 21:18:00 2011 From: outsider at scarynet.org (Alexander Maassen) Date: Sat, 02 Apr 2011 04:18:00 +0200 Subject: IPv4 Address Exhaustion Effects on the Earth In-Reply-To: References: Message-ID: <4D968758.5000501@scarynet.org> wil, maybe after all this time you got the router, it gained 7lbs of all the dust in it ? Op 1-4-2011 3:26, Wil Schultz schreef: > On Mar 31, 2011, at 6:14 PM, "Joao C. Mendes Ogawa" wrote: > >> FYI >> >> --Jonny Ogawa >> >> ----- Forwarded message from Stephen H. Inden ----- >> >> From: Stephen H. Inden >> Subject: IPv4 Address Exhaustion Effects on the Earth >> Date: Fri, 1 Apr 2011 00:19:08 +0200 >> To: Global Environment Watch (GEW) mailing list >> X-Mailer: Apple Mail (2.1084) >> X-Mailman-Version: 2.1.9 >> List-Id: "GEW mailing list." >> >> >> IPv4 Address Exhaustion Effects on the Earth >> >> By Stephen H. Inden >> April 1, 2011 >> >> At a ceremony held on February 3, 2011 the Internet Assigned Numbers >> Authority (IANA) allocated the remaining last five /8s of IPv4 address >> space to the Regional Internet Registries (RIRs). With this action, >> the free pool of available IPv4 addresses was completely depleted. >> >> Since then, several scientists have been studying the effects of this >> massive IPv4 usage (now at its peak) on the Earth. >> >> While measuring electromagnetic fields emanating from the world's >> largest IPv4 Tier-1 backbones, NASA scientists calculated how the IPv4 >> exhaustion is affecting the Earth's rotation, length of day and >> planet's shape. >> >> Dr. Ron F. Stevens, of NASA's Goddard Space Flight Center, said all >> packet switching based communications have some effect on the Earth's >> rotation. It's just they are usually barely noticeable. Until now. >> >> "Every packet affects the Earth's rotation, from a small ping to a >> huge multi-terabyte download. The problem with IPv4 is its variable >> length header and tiny address space that can cause an electromagnetic >> unbalance on transmission lines. The widespread adoption of Network >> Address Translation (NAT) on IPv4 networks is making the problem even >> worse, since it concentrates the electromagnetic unbalance. This >> problem is not noticeable with IPv6 because of its fixed header size >> and bigger 128 bits address space", Dr. Stevens said. >> >> Over the past few years, Dr. Stevens has been measuring the IPv4 >> growing effects in changing the Earth's rotation in both length of >> day, as well as gravitational field. When IPv4 allocation reached its >> peak, last February, he found out that the length of day decreased by >> 2.128 microseconds. The electromagnetic unbalance is also affecting >> the Earth's shape -- the Earth's oblateness (flattening on the top and >> bulging at the Equator) is decreasing by a small amount every year >> because of the increasing IPv4 usage. >> >> The researcher concluded that IPv4 usage has reached its peak and is >> causing harmful effects on the Earth: >> >> "IPv4 is, indeed, harmful. Not only 32 bits for its address space has >> proven too small and prone to inadequate solutions like NAT, it is now >> clear that its electromagnetic effects on the Earth are real and >> measurable." >> >> The solution? >> >> "I'm convinced that the only permanent solution is to adopt IPv6 as >> fast as we can", says Dr. Stevens. >> >> -- >> > It's all true. > > Alse I've been weighing my router and it's 7 lbs heavier with the addition of all these new ip addresses in it's routing table. > > -wil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From bonomi at mail.r-bonomi.com Fri Apr 1 22:23:29 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 1 Apr 2011 22:23:29 -0500 (CDT) Subject: v6 Avian Carriers? In-Reply-To: Message-ID: <201104020323.p323NTnV086245@mail.r-bonomi.com> > Date: Fri, 1 Apr 2011 20:34:52 -0500 > Subject: Re: v6 Avian Carriers? > From: Chad Dailey > > Swallows have MTU issues. No swallows? Oh, spit. From bonomi at mail.r-bonomi.com Fri Apr 1 22:30:02 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 1 Apr 2011 22:30:02 -0500 (CDT) Subject: IPv4 Address Exhaustion Effects on the Earth In-Reply-To: <4D968758.5000501@scarynet.org> Message-ID: <201104020330.p323U2j5086276@mail.r-bonomi.com> > Date: Sat, 02 Apr 2011 04:18:00 +0200 > From: Alexander Maassen > Subject: Re: IPv4 Address Exhaustion Effects on the Earth > > wil, > maybe after all this time you got the router, it gained 7lbs of all the > dust in it ? Consider what happens if the carrier encounters a route reflector -- flipping the bird?? From swm at emanon.com Fri Apr 1 22:19:20 2011 From: swm at emanon.com (Scott Morris) Date: Sat, 02 Apr 2011 05:19:20 +0200 Subject: v6 Avian Carriers? In-Reply-To: References: <872325B0-BD3D-4211-8474-EFAE6BDC6F9E@cs.columbia.edu> <5823114E-7E5F-4874-85C1-947F58AB0937@delong.com> Message-ID: <4D9695B8.2080205@emanon.com> Isn't that what the uvula is for? Oh... never mind.... wrong swallow. ;) On 4/2/11 3:34 AM, Chad Dailey wrote: > Swallows have MTU issues. > > On Fri, Apr 1, 2011 at 8:27 PM, Owen DeLong wrote: > >> On Apr 1, 2011, at 10:45 AM, Steven Bellovin wrote: >> >>> On Apr 1, 2011, at 8:41 11AM, Sachs, Marcus Hans (Marc) wrote: >>> >>>> I was wondering which April 1st this would happen on. Now I know. So >> if a v6 carrier swallows a v4 datagram does that count as packet loss or >> tunneling? >>>> http://datatracker.ietf.org/doc/rfc6214/ >>>> >>> I was disappointed in this RFC -- Section 3.1 didn't include the proper >> discussion of the difference between African and European avian carriers, >> and we know what happens if that question is asked at the wrong time. >>> >>> --Steve Bellovin, https://www.cs.columbia.edu/~smb >>> >>> >>> >>> >>> >> That applies to swallows. I'm not sure pidgeons pose the same issue. I >> think in general, swallows >> provide poor platforms for avian transport of IP datagrams. >> >> >> Owen >> >> >> >> > From swm at emanon.com Fri Apr 1 22:20:24 2011 From: swm at emanon.com (Scott Morris) Date: Sat, 02 Apr 2011 05:20:24 +0200 Subject: v6 Avian Carriers? In-Reply-To: References: <29DF17B0-5D47-4196-938C-893358D9B96B@delong.com> Message-ID: <4D9695F8.6090208@emanon.com> Random re-encapsulation. Now there's an interesting protocol! On 4/2/11 3:53 AM, Brandon Ross wrote: On Fri, 1 Apr 2011, Owen DeLong wrote: Not true. The occupants of the aircraft survived. The aircraft did not. Hm, in my recollection the payload made it to the destination. Perhaps the route was a bit unexpected though. From mrz at velvet.org Fri Apr 1 23:47:38 2011 From: mrz at velvet.org (matthew zeier) Date: Fri, 1 Apr 2011 21:47:38 -0700 Subject: comcast dns admin, help needed Message-ID: <2A6458A2-F168-4B22-ADC9-C25964EEA804@velvet.org> Trying to track down someone at Comcast who maintains DNS. I'm having a number of Comcast users who are unable to resolve mozilla.org hosts. https://bugzilla.mozilla.org/show_bug.cgi?id=647254 Tried using other channels to find contacts but am running dry. Email offline or comment in that bug. - mrz at mozilla.com From shoshon at shoshon.ro Sat Apr 2 06:32:52 2011 From: shoshon at shoshon.ro (Bogdan) Date: Sat, 02 Apr 2011 14:32:52 +0300 Subject: as-set members Message-ID: <4D970964.8080403@shoshon.ro> hello i have an as-set that has some members, other as-sets. can i exclude some members from my as-set members? as-set: me members: as-set-1, as-set-2, as-set-3 as-set-3 has some members that i want to exlude; let's say as-set-xxx, is a member of as-set as-set-3 is there something like members: as-set-1, as-set-2, as-set-3 and not as-set-xxx ? thanks From sfouant at shortestpathfirst.net Sat Apr 2 07:47:20 2011 From: sfouant at shortestpathfirst.net (=?utf-8?B?U3RlZmFuIEZvdWFudA==?=) Date: Sat, 02 Apr 2011 08:47:20 -0400 Subject: =?utf-8?B?UmU6IGFzLXNldCBtZW1iZXJz?= Message-ID: Hi Bogdan, If you are on Cisco, you can accomplish this using the attribute-map argument to the as-set statement. On Juniper, this is fairly easy to accomplish with routing policy (learning RegEx will make your life easier). HTHs. Stefan (sorry for the top post, I'm on my mobile...) ----- Reply message ----- From: "Bogdan" Date: Sat, Apr 2, 2011 7:32 am Subject: as-set members To: hello i have an as-set that has some members, other as-sets. can i exclude some members from my as-set members? as-set: me members: as-set-1, as-set-2, as-set-3 as-set-3 has some members that i want to exlude; let's say as-set-xxx, is a member of as-set as-set-3 is there something like members: as-set-1, as-set-2, as-set-3 and not as-set-xxx ? thanks From shoshon at shoshon.ro Sat Apr 2 10:12:45 2011 From: shoshon at shoshon.ro (Bogdan) Date: Sat, 02 Apr 2011 18:12:45 +0300 Subject: as-set members In-Reply-To: <20110402124719.B9E431E6010A@smtp2.ines.ro> References: <20110402124719.B9E431E6010A@smtp2.ines.ro> Message-ID: <4D973CED.4020203@shoshon.ro> hi i am using cisco and rtconfig. On 02.04.2011 15:47, Stefan Fouant wrote: > Hi Bogdan, > > If you are on Cisco, you can accomplish this using the attribute-map > argument to the as-set statement. On Juniper, this is fairly easy to > accomplish with routing policy (learning RegEx will make your life easier). > > HTHs. > > Stefan > > (sorry for the top post, I'm on my mobile...) > > ----- Reply message ----- > From: "Bogdan" > Date: Sat, Apr 2, 2011 7:32 am > Subject: as-set members > To: > > hello > > i have an as-set that has some members, other as-sets. > can i exclude some members from my as-set members? > > > as-set: me > members: as-set-1, as-set-2, as-set-3 > > as-set-3 has some members that i want to exlude; let's say as-set-xxx, > is a member of as-set as-set-3 > > is there something like > members: as-set-1, as-set-2, as-set-3 and not as-set-xxx ? > > thanks > > > From nick at foobar.org Sat Apr 2 11:41:10 2011 From: nick at foobar.org (Nick Hilliard) Date: Sat, 02 Apr 2011 17:41:10 +0100 Subject: as-set members In-Reply-To: <4D970964.8080403@shoshon.ro> References: <4D970964.8080403@shoshon.ro> Message-ID: <4D9751A6.7000705@foobar.org> On 02/04/2011 12:32, Bogdan wrote: > as-set-3 has some members that i want to exlude; let's say as-set-xxx, > is a member of as-set as-set-3 > > is there something like > members: as-set-1, as-set-2, as-set-3 and not as-set-xxx ? No, you can't do this in an as-set definition. What you can do is specify it in your routing policy definition in your aut-num object. So you could say, for example: import: from AS65234 accept AS-ME and not AS-SET-XXX Nick From shoshon at shoshon.ro Sat Apr 2 13:26:24 2011 From: shoshon at shoshon.ro (Bogdan) Date: Sat, 02 Apr 2011 21:26:24 +0300 Subject: as-set members In-Reply-To: <4D9751A6.7000705@foobar.org> References: <4D970964.8080403@shoshon.ro> <4D9751A6.7000705@foobar.org> Message-ID: <4D976A50.8040505@shoshon.ro> On 02.04.2011 19:41, Nick Hilliard wrote: > On 02/04/2011 12:32, Bogdan wrote: >> as-set-3 has some members that i want to exlude; let's say as-set-xxx, >> is a member of as-set as-set-3 >> >> is there something like >> members: as-set-1, as-set-2, as-set-3 and not as-set-xxx ? > > No, you can't do this in an as-set definition. What you can do is > specify it in your routing policy definition in your aut-num object. So > you could say, for example: > > import: from AS65234 accept AS-ME and not AS-SET-XXX > > Nick > got it thanks From alessandro.martins at gmail.com Sat Apr 2 13:46:31 2011 From: alessandro.martins at gmail.com (Alessandro Fernandes Martins) Date: Sat, 2 Apr 2011 15:46:31 -0300 Subject: Embratel or GVT contact In-Reply-To: References: Message-ID: Hello, Regarding Embratel contacts, you can use: bgp at embratel.net.br and netadmin at embratel.net.br. Regards, Alessandro Martins On Fri, Apr 1, 2011 at 21:14, Mark Wall wrote: > Is there anyone from GVT or Embratel with a clue willing to help me with a > BGP route issue we are seeing? > > Thanks > From francois at menards.ca Sat Apr 2 15:00:30 2011 From: francois at menards.ca (Francois Menard) Date: Sat, 2 Apr 2011 16:00:30 -0400 Subject: State of QoS peering in Nanog Message-ID: Folks, The Canadian telecommunications regulator, the CRTC, has just launched a public notice with possible worldwide implications IMHO, Telecom Notice of Consultation CRTC 2011-206: http://www.crtc.gc.ca/eng/archive/2011/2011-206.htm I think this is the very first regulatory inquiry into IP to IP interconnection for PSTN local interconnection. One of the postulates that I intend to defend, is that in the PSTN today, in addition to interconnecting for the purpose of exchanging voice calls, it is possible to LOCALLY (at the Local Interconnection Region, roughly a US LATA) interconnect with guaranteed QoS for ISDN video conferencing. In other words, there is more to PSTN interconnection than the support of the G.711 CODEC. Other CODECs are supported, such as H.320. This brings me to a point. Why should we loose this important feature of the PSTN, support for multiple CODECs, as we carelessly bottom level IP-IP interconnection to G.711 only. Video conferencing on the Internet, particularly at high resolution, is not a reality today to say the least, foregoing of guessing what the future will hold. Why not consider HD audio ? Therefore: A) I want to capture all instances where this issue has been addressed worldwide. B) I also want to understand what is going on, insofar as enabling guaranteed QoS peering across BGP-4 interconnections in the Nanog community. C) I also want to understand whether there is inter-service-provider RSVP or other per-session QoS establishment protocols. I call upon the Nanog community to consider this proceeding as very important and contribute to this thread. And I will try to provide a forum for discussing this outside of Nanog when required. Regards, -=Francois=- From mpetach at netflight.com Sat Apr 2 16:40:58 2011 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 2 Apr 2011 14:40:58 -0700 Subject: Ping - APAC Region In-Reply-To: <20110329181716.GE28381@hezmatt.org> References: <20110329181716.GE28381@hezmatt.org> Message-ID: On Tue, Mar 29, 2011 at 11:17 AM, Matthew Palmer wrote: > On Tue, Mar 29, 2011 at 06:33:07PM +0100, Robert Lusby wrote: >> Looking at hosting some servers in Hong Kong, to serve the APAC region. Our >> client is worried that this may slow things down in their Australia region, >> and are wondering whether hosting the servers in an Australian data-centre >> would be a better option. >> >> Does anyone have any statistics on this? > > No formal statistics, just a lot of experience. ?You may be unsurprised to > learn that serving into Australia from outside Australia is slower than > serving from within Australia. ?That being said, there's a fair bit less > distance for the light to travel from Hong Kong or anywhere in the region > than from the US. Given that the bulk of the population density in Australia is on the eastern coast near Sydney, and the *only* fiber path going anywhere near Asia from Sydney does so via Guam, the light path traveled from Sydney to Guam to La Union (PH) to Hong Kong isn't appreciably shorter than the light path from Sydney to Hawaii to the US--which is covered by roughly 6x as many fiber runs as the Guam pathway, and is thus somewhat cheaper to get onto--you might as well host on the west coast of the US as in Hong Kong. (and *that* was a horrific run-on sentence!) If I look at average data for the past five years between Sydney and Hong Kong, San Jose, Singapore, and Los Angeles, on average it's better to serve Sydney from Los Angeles than Hong Kong or Singapore: mpetach at netops:/home/mrtg/public_html/performance> ~/tmp/avgperf.pl AUE HKI total daily data files read: 1559 AUE to HKI latency (min/avg/max): 134.216/173.273/1052.158 mpetach at netops:/home/mrtg/public_html/performance> ~/tmp/avgperf.pl AUE SJC total daily data files read: 1558 AUE to SJC latency (min/avg/max): 149.829/176.674/308.637 mpetach at netops:/home/mrtg/public_html/performance> ~/tmp/avgperf.pl AUE SG1 total daily data files read: 1558 AUE to SG1 latency (min/avg/max): 101.871/204.485/999 mpetach at netops:/home/mrtg/public_html/performance> ~/tmp/avgperf.pl AUE LAX total daily data files read: 931 AUE to LAX latency (min/avg/max): 157.603/166.720/999 mpetach at netops:/home/mrtg/public_html/performance> > That is predicated on having good direct links, which is > eye-wateringly expensive if you're used to US data costs (data going from > China to Australia via San Jose... ?aaargh). ?Then again, hosting within > Australia is similarly expensive, so splitting your presence isn't going to > help you any from a cost PoV. It's not really a matter of eye-wateringly expensive, so much as simple basic existence; there's no direct Sydney to southern Asia fiber, at the moment; the best you can do is hop through Papua New Guinea to Guam, and then back across into southern Asia. (or overshoot up to Japan, and then bounce your way back down from there). Matt From bicknell at ufp.org Sat Apr 2 16:56:07 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 2 Apr 2011 14:56:07 -0700 Subject: State of QoS peering in Nanog In-Reply-To: References: Message-ID: <20110402215607.GA86553@ussenterprise.ufp.org> In a message written on Sat, Apr 02, 2011 at 04:00:30PM -0400, Francois Menard wrote: > One of the postulates that I intend to defend, is that in the > PSTN today, in addition to interconnecting for the purpose of > exchanging voice calls, it is possible to LOCALLY (at the Local > Interconnection Region, roughly a US LATA) interconnect with > guaranteed QoS for ISDN video conferencing. The PSTN "features" fixed, known bandwidth. QoS isn't really the right term. When I nail up a BRI, I know I have 128kb of bandwidth, never more, never less. There is no function on that channel similar to IP QoS. When talking about IP QoS people like to talk about guaranteed, or reserved bandwidth for particular applications. The reality is though that's not how IP QoS works. IP QoS is really about identifying which traffic can be thrown away first in th face of congestion. Guaranteeing 128kb for a video call really means making sure all other traffic is thrown away first, in the face of congestion. > In other words, there is more to PSTN interconnection than the > support of the G.711 CODEC. Other CODECs are supported, such as > H.320. > > This brings me to a point. Why should we loose this important > feature of the PSTN, support for multiple CODECs, as we carelessly > bottom level IP-IP interconnection to G.711 only. IP networks can't tell the difference between G.711, H.320, and the SMTP packets used to deliver this e-mail. IP networks know nothing about CODECs, and operate entirely on IP address and port information. > B) I also want to understand what is going on, insofar as enabling > guaranteed QoS peering across BGP-4 interconnections in the Nanog > community. You're looking at the wrong point in the network. In my experience, full peering circuits are very much the exception, not the rule. While almost all the exceptions hit NANOG and are the subject of fun and lively discussion, the reality is they are rare. When there is no congestion, there is no reason to drop a packet. A QoS policy would go unused, or if you want to look from the other direction everything has 100% bandwidth across that link. In an IP network, the bandwidth constraints are almost always across an administrative boundary. This means in the majority of the case across transit circuits, not peering. 80-90% of the packet loss in the network happens at the end user access port, inbound or outbound. Another 5-10% occurs where regional or non-transit free providers buy transit. Lastly, 3-5% occurs where there are geographic or geopolitical issues (oceans to cross, country boarders with restrictive governments to cross). Basically, you could mandate QoS on every peering link in the Internet and I suspect 99% of the end users would never notice any change. If you want to advocate for useful changes to end users that provide a better network experience, you need to focus your efforts in three areas: 1) Fight bufferbloat. http://en.wikipedia.org/wiki/Bufferbloat http://arstechnica.com/tech-policy/news/2011/01/understanding-bufferbloat-and-the-network-buffer-arms-race.ars http://www.bufferbloat.net/ 2) Get access ISPs to offer QoS on customer access ports, ideally in some user configurable way. 3) Get ISP's who purchase transit further up the line to implement QoS with their transit provider for their customers traffic, if they are going to run those links at full. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From jsw at inconcepts.biz Sat Apr 2 18:00:52 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sat, 2 Apr 2011 19:00:52 -0400 Subject: State of QoS peering in Nanog In-Reply-To: <20110402215607.GA86553@ussenterprise.ufp.org> References: <20110402215607.GA86553@ussenterprise.ufp.org> Message-ID: On Sat, Apr 2, 2011 at 5:56 PM, Leo Bicknell wrote: > The PSTN "features" fixed, known bandwidth. ?QoS isn't really the > right term. ?When I nail up a BRI, I know I have 128kb of bandwidth, > never more, never less. ?There is no function on that channel similar > to IP QoS. The PSTN also has exactly one unidirectional flow per access port. This is not true of IP networks, where an end-user access port may have dozens of flows going at once for common web browsing, and perhaps hundreds of flows when using P2P file sharing applications, etc. The lifetime of these flows may be several hours (streaming movie) or under a second (web browser.) Where the PSTN has channels between two access ports (which might be packetized within the backbone) and a relatively complex control plane for establishing flows, the IP network has little or no knowledge of flows, and if it does have any knowledge of them, it's not because a control plane exists to establish them, it's because punting from the data plane to the control plane allows flow state to be established for things like NAT. > Basically, you could mandate QoS on every peering link in the > Internet and I suspect 99% of the end users would never notice any > change. I don't agree with this. IMO all DDoS traffic would suddenly be marked into the highest priority forwarding class that doesn't have an absurdly low policer for the DDoS source's access port, and as a result, DDoS would more easily cripple the network, either from hitting policers on the higher-priority traffic and killing streaming movies/voip/etc, or in the absence of policers, it would more easily cause significant packet loss to best-effort traffic. I think end-users would notice because their ISP would suddenly grind to a halt anytime a clever DDoS was directed their way. We will no sooner see a practical solution to this than we will one for large-scale multicast in backbone and subscriber access networks. The limitations are similar: to be effective, you need a lot more state for multicast. For a truly good QoS implementation, you need a lot more hardware counters and policers (more state.) If you don't have this, all your QoS setup will do, deployed across a large Internet subscriber access network, is work a little better under ideal conditions, and probably a lot worse when subjected to malicious traffic. > 2) Get access ISPs to offer QoS on customer access ports, ideally in > ? some user configurable way. I do agree that QoS should be available to end-users across access links, but I don't agree with pushing it further towards the core unless per-subscriber policers are available beyond those on access routers. Otherwise, all someone has to do to be mean to Netflix is send a short-term, high-volume DoS attack that looks like Netflix traffic towards an end-user IP, which would interrupt movie-viewing for a potentially larger number of users, or at least as many end-users as the same DoS would in the absence of any QoS. The case of per-subscriber policers pushed further towards the ISP core fares better. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jason at thebaughers.com Sat Apr 2 18:09:22 2011 From: jason at thebaughers.com (Jason Baugher) Date: Sat, 02 Apr 2011 18:09:22 -0500 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: References: <20110401123804.GA5883@gsp.org> Message-ID: <4D97ACA2.8000702@thebaughers.com> I may regret wading into this one.... Regarding posting from a Gmail account, I'm also posting from a non-work account, for two reasons. One, our company policy is to tag an annoying legal disclaimer onto every outbound message, and two, I don't want anything I say on this list to come back on the company I work for. I'm not authorized to speak for them, so I won't. When it comes to abuse complaints, we investigate and act to protect our customers and our network when we determine that abuse is indeed happening. Only after we deal with the immediate threat do we contact our customer to let them know. Although there are cases of intentional abuse, the majority of the time the customer has no idea what we're talking about. They have to get their tech people or an outside support company to look into the problem, and then they call us back when they have it fixed. Sometimes we work directly with their tech people to help them identify the source. We would NEVER "out" the customer to the public, even if we felt the abuse was intentional. My CEO and our lawyers would blow a gasket if we were to potentially libel a customer. There have been plenty of times when I was every bit as frustrated as some of the people on this list, but to start naming names without proof? Won't happen. Jason On 4/1/2011 11:31 AM, Atticus wrote: > Please note, I'm not arguing against fixing the problem. I just think we > should show each other some professional respect, and use some manners. > From fmartin at linkedin.com Sat Apr 2 18:12:19 2011 From: fmartin at linkedin.com (Franck Martin) Date: Sat, 2 Apr 2011 23:12:19 +0000 Subject: Ping - APAC Region In-Reply-To: Message-ID: Also remember, you would be serving Australia only from Australia. if I'm not mistaken, the Australia backbone is more or less volume based cahrged... http://www.aarnet.edu.au/services/aarnet-charging.aspx "AARNet3 charges are different for Shareholders (Members) and for Non Shareholders (Associates and Affiliates). Billing On Net and Off Net subscriptions are calculated in October each year, and invoices must be delivered soon after to allow sufficient time for customers to pay in advance for the following calendar year. For those invoices not paid in full and in advance, On Net and Off Net Subscriptions, and Access Charges are invoiced by quarter and in advance. All Usage charges, including Excess Traffic, are invoiced retrospectively after each quarter. " On 4/3/11 9:40 , "Matthew Petach" wrote: >On Tue, Mar 29, 2011 at 11:17 AM, Matthew Palmer >wrote: >> On Tue, Mar 29, 2011 at 06:33:07PM +0100, Robert Lusby wrote: >>> Looking at hosting some servers in Hong Kong, to serve the APAC >>>region. Our >>> client is worried that this may slow things down in their Australia >>>region, >>> and are wondering whether hosting the servers in an Australian >>>data-centre >>> would be a better option. >>> >>> Does anyone have any statistics on this? >> >> No formal statistics, just a lot of experience. You may be unsurprised >>to >> learn that serving into Australia from outside Australia is slower than >> serving from within Australia. That being said, there's a fair bit less >> distance for the light to travel from Hong Kong or anywhere in the >>region >> than from the US. > >Given that the bulk of the population density in Australia is on the >eastern coast near Sydney, and the *only* fiber path going anywhere >near Asia from Sydney does so via Guam, the light path traveled from >Sydney to Guam to La Union (PH) to Hong Kong isn't appreciably >shorter than the light path from Sydney to Hawaii to the US--which is >covered by roughly 6x as many fiber runs as the Guam pathway, and >is thus somewhat cheaper to get onto--you might as well host on the >west coast of the US as in Hong Kong. (and *that* was a horrific >run-on sentence!) > >If I look at average data for the past five years between Sydney and >Hong Kong, San Jose, Singapore, and Los Angeles, on average it's >better to serve Sydney from Los Angeles than Hong Kong or Singapore: > >mpetach at netops:/home/mrtg/public_html/performance> ~/tmp/avgperf.pl AUE >HKI >total daily data files read: 1559 >AUE to HKI latency (min/avg/max): 134.216/173.273/1052.158 >mpetach at netops:/home/mrtg/public_html/performance> ~/tmp/avgperf.pl AUE >SJC >total daily data files read: 1558 >AUE to SJC latency (min/avg/max): 149.829/176.674/308.637 >mpetach at netops:/home/mrtg/public_html/performance> ~/tmp/avgperf.pl AUE >SG1 >total daily data files read: 1558 >AUE to SG1 latency (min/avg/max): 101.871/204.485/999 >mpetach at netops:/home/mrtg/public_html/performance> ~/tmp/avgperf.pl AUE >LAX >total daily data files read: 931 >AUE to LAX latency (min/avg/max): 157.603/166.720/999 >mpetach at netops:/home/mrtg/public_html/performance> > > >> That is predicated on having good direct links, which is >> eye-wateringly expensive if you're used to US data costs (data going >>from >> China to Australia via San Jose... aaargh). Then again, hosting within >> Australia is similarly expensive, so splitting your presence isn't >>going to >> help you any from a cost PoV. > >It's not really a matter of eye-wateringly expensive, so much as simple >basic existence; there's no direct Sydney to southern Asia fiber, at the >moment; the best you can do is hop through Papua New Guinea to >Guam, and then back across into southern Asia. (or overshoot up to >Japan, and then bounce your way back down from there). > >Matt > From mmc at internode.com.au Sat Apr 2 18:49:05 2011 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 2 Apr 2011 23:49:05 +0000 Subject: Ping - APAC Region In-Reply-To: References: Message-ID: On 03/04/2011, at 8:42 AM, Franck Martin wrote: Also remember, you would be serving Australia only from Australia. if I'm not mistaken, the Australia backbone is more or less volume based cahrged... AARNET is the Academic and Research Network, it's not "THE" backbone. (Note: in previous incarnations many years ago it was). Australia is an island, approximately the same size as continental USA but with only about 22M people. It's not really on the way anywhere, so the submarine capacity is pretty much limited to what is needed to serve Australia. There exist various submarine cables which go North to Guam and beyond (AJC/PPC1) and East from Sydney (SCCN, Endeavour) as well as SMW3 from Perth to Singapore. SMW3 is a great path into Singapore, except it's old and capacity is limited. Another cable is meant to being built on that path - many people have tried, let's hope the next attempt will work. Connecting these we have really only four sets of land based networks (Telstra, Optus, AAPT, NextGen - not all of these have complete coverage and/or rely on others for redundancy). We're very like Canada in some ways - small population along and edge (Canada is the US border, we're along the Southern and Eastern coasts). Various providers have capacity on different sets of cables. It's difficult to generalise as, for instance, some providers use the cable into Asia to provide business customers with good connectivity but don't generalise that to residential customers. The kinds of connectivity at the end of those cables varies as well. If you want to get content into Australia then generally to get the best delivery: a) Put it on the West Coast of the USA - LA or San Jose - everyone has good connectivity to those places. Look for places you can easily get content into AS4637, AS7473/7474, AS4826 and AS4739. AS4648 for NZ and some of AU as well. (AS4739 will peer with you there :-) (*) b) Deliver it domestically in Australia in Sydney. Equinix Sydney is a good place to start. You can get domestic transit as well as good peering to most providers. It's also close to the large population centres on the East Coast (SYD, MEL). c) Failing that - try Japan first, then Hong Kong then Singapore. But you will need to combine with a) or b) to give good connectivity to all providers. Consider various acceleration things like CDNs - especially LLNW, AKAM and EdgeCast who all have delivery capability in AU already. If anyone has any specific AU questions then I'm happy to try and answer off list. (I work for AS4739 and am responsible for peering and transit so have reasonable interest in delivery of content to customers in AU - we're keen to have GOOD connectivity). (*) AS4637 has AS1221 behind it, AS7473 has AS7474 (their customers are in AS4804) - they have around 50% of the market together in terms of traffic delivered to the AU market. Tools like peeringdb.com and bgp.he.net will tell you how everyone's connected. MMC -- Matthew Moyle-Croft Peering Manager and Team Lead - Commercial and DSLAMs Internode /Agile Level 5, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net From bicknell at ufp.org Sat Apr 2 21:23:45 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 2 Apr 2011 19:23:45 -0700 Subject: State of QoS peering in Nanog In-Reply-To: References: <20110402215607.GA86553@ussenterprise.ufp.org> Message-ID: <20110403022345.GA94165@ussenterprise.ufp.org> In a message written on Sat, Apr 02, 2011 at 07:00:52PM -0400, Jeff Wheeler wrote: > I don't agree with this. IMO all DDoS traffic would suddenly be > marked into the highest priority forwarding class that doesn't have an > absurdly low policer for the DDoS source's access port, and as a > result, DDoS would more easily cripple the network, either from > hitting policers on the higher-priority traffic and killing streaming > movies/voip/etc, or in the absence of policers, it would more easily > cause significant packet loss to best-effort traffic. Agree in part, and disagree in part. No doubt DDoS programs will try and masquerade as "high priority" traffic. This will create a new set of problems, and require some new solutions. Let's separate the problem into two parts. The first is "best effort" traffic. Provided the QoS policy only prioritizes a fraction of the bandwidth (20 to maybe 40%), the impact of a DDoS that came in prioritized would only be a few percentage points worse than a standard DDoS. Today it takes about 10x link speed to make a link "completely unusable" (although YMMV, and it depends a lot on your traffic mix and definition of unusable). Witha 25% priority queue, and the DDoS hitting it that may drop to 8x. I think it is both statistically interesting, but also relatively minor. The second problem is what happens to priority traffic. You are correct that if DDoS traffic can come in prioritized then you only need fill the priority queue 2x-4x to generate issues (as streaming traffic is more sensitive), assuming traffic over the limit is not dropped but rather allowed best effort. This is likely a lower threshold than filling the entire link 5x-10x, and thus easier for the attacker. But it also only affects priority queue traffic. I realize I'm making a value judgment, but many customers under DDoS would find things vastly improved if their video conferencing went down, but everything else continued to work (if slowly), compared to today when everything goes down. In closing, I want to push folks back to the buffer bloat issue though. More than once I've been asked to configure QoS on the network to support VoIP, Video Conferencing or the like. These things were deployed and failed to work properly. I went into the network and _reduced_ the buffer sizes, and _increased_ packet drops. Magically these applications worked fine, with no QoS. Video conferencing can tolerate a 1% packet drop, but can't tolerate a 4 second buffer delay. Many people today who want QoS are actually suffering from buffer bloat. :( This is very hard to explain, while people on NANOG might get it 99% of the network engineers in the world think minimizing packet loss is the goal. It is very much an uphill battle to make them understand higher packet loss often _increases_ end user performance on full links. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From jra at baylink.com Sun Apr 3 08:37:03 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 3 Apr 2011 09:37:03 -0400 (EDT) Subject: v6 Avian Carriers? In-Reply-To: Message-ID: <26233124.1750.1301837823074.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Steven Bellovin" > > Which? African or European Swallows? > > > > (Watches Chad fly over the cliff edge) ;-) > > So the RFC needed more text in it's Security Considerations section, > too... People just don't put enough *thought* into their April 1 RFCs anymore... Cheers, -- jra From sfouant at shortestpathfirst.net Sun Apr 3 11:40:14 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Sun, 3 Apr 2011 12:40:14 -0400 Subject: State of QoS peering in Nanog In-Reply-To: <20110402215607.GA86553@ussenterprise.ufp.org> References: <20110402215607.GA86553@ussenterprise.ufp.org> Message-ID: <020601cbf21d$cf44d840$6dce88c0$@net> > -----Original Message----- > From: Leo Bicknell [mailto:bicknell at ufp.org] > Sent: Saturday, April 02, 2011 5:56 PM > > In an IP network, the bandwidth constraints are almost always across an > administrative boundary. This means in the majority of the case across > transit circuits, not peering. 80-90% of the packet loss in the > network happens at the end user access port, inbound or outbound. > Another 5-10% occurs where regional or non-transit free providers buy > transit. Lastly, 3-5% occurs where there are geographic or > geopolitical issues (oceans to cross, country boarders with restrictive > governments to cross). Hi Leo, I think you bring up some interesting points here, and my experience and observations largely lend credence to what you are saying. I'd like to know however, just for my own personal knowledge, are the numbers you are using above based on some broad analysis or study of multiple providers, or are you deriving these numbers likewise you're your own personal observations? Thanks, Stefan Fouant From sfouant at shortestpathfirst.net Sun Apr 3 11:50:45 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Sun, 3 Apr 2011 12:50:45 -0400 Subject: State of QoS peering in Nanog In-Reply-To: <20110403022345.GA94165@ussenterprise.ufp.org> References: <20110402215607.GA86553@ussenterprise.ufp.org> <20110403022345.GA94165@ussenterprise.ufp.org> Message-ID: <020901cbf21f$47462b40$d5d281c0$@net> > -----Original Message----- > From: Leo Bicknell [mailto:bicknell at ufp.org] > Sent: Saturday, April 02, 2011 10:24 PM > > But it also only affects priority queue traffic. I realize I'm making > a value judgment, but many customers under DDoS would find things > vastly improved if their video conferencing went down, but everything > else continued to work (if slowly), compared to today when everything > goes down. I'd like to observe that discussion when the Netflix guys come calling on the support line - "Hey Netflix, yeah you're under attack and your subscribers can't watch videos at the moment, but the good news is that all other apps running on our network are currently unaffected". ;> > In closing, I want to push folks back to the buffer bloat issue though. > More than once I've been asked to configure QoS on the network to > support VoIP, Video Conferencing or the like. These things were > deployed and failed to work properly. I went into the network and > _reduced_ the buffer sizes, and _increased_ packet drops. Magically > these applications worked fine, with no QoS. > > Video conferencing can tolerate a 1% packet drop, but can't tolerate a > 4 second buffer delay. Many people today who want QoS are actually > suffering from buffer bloat. :( Concur 100%. In my experience, I've gotten much better performance w/ VoIP/Video Conferencing and other delay-intolerant applications when setting buffer sizes to a temporal value rather than based on a _fixed_ number of packets. Stefan Fouant From emruden at gmail.com Sun Apr 3 12:29:10 2011 From: emruden at gmail.com (emmy mkos) Date: Sun, 3 Apr 2011 20:29:10 +0300 Subject: Submission Message-ID: I thank you for all the ideas that we get to exploit from this site... From jg at freedesktop.org Sun Apr 3 13:53:24 2011 From: jg at freedesktop.org (Jim Gettys) Date: Sun, 03 Apr 2011 14:53:24 -0400 Subject: IPv4 Address Exhaustion Effects on the Earth In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E2BAE@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0C9E2BAE@RWC-EX1.corp.seven.com> Message-ID: <4D98C224.1090906@freedesktop.org> On 04/01/2011 11:44 AM, George Bonser wrote: >> From: Joao C. Mendes Ogawa >> Sent: Thursday, March 31, 2011 6:14 PM >> Subject: Fwd: IPv4 Address Exhaustion Effects on the Earth >> >> FYI >> >> --Jonny Ogawa >> >> ----- Forwarded message from Stephen H. Inden ----- >> > Dang, I was hoping to see an RFC on Bufferbloat in Avian Carriers and > how tail-drop is a messy solution that is to be avoided. > Sigh... A major opportunity missed. Unfortunately the bufferbloat problem isn't a laughing matter, though I do wish I had thought of this idea in time for my talk. I will include this joke as some levity about the mess we're in as I repeat the talk going forward, and would tie in very nicely with one of the amusing reasons that "RED in a different light" has never been published. I really hate giving such bad news without some levity as it can be a real downer both for me and the audience. For those of you who missed my IETF talk, you can find the latest version (tweaked since IETF) at: http://mirrors.bufferbloat.net/Talks/PragueIETF/ I suspect audio is some place on the net as well; I presented at the transport area meeting. The questions after my talk are also very worth listening to. Time was precious in that venue, so I did feel rushed and hope to get a better opportunity in a month or two for that. It's a shorter version of my first talk given at Murray Hill http://mirrors.bufferbloat.net/Talks/BellLabs01192011/ which does have additional information impossible to fit in that short a time slot. - Jim From cdel at firsthand.net Sun Apr 3 14:59:30 2011 From: cdel at firsthand.net (Christian de Larrinaga) Date: Sun, 3 Apr 2011 21:59:30 +0200 Subject: IPv4 Address Exhaustion Effects on the Earth In-Reply-To: <4D98C224.1090906@freedesktop.org> References: <5A6D953473350C4B9995546AFE9939EE0C9E2BAE@RWC-EX1.corp.seven.com> <4D98C224.1090906@freedesktop.org> Message-ID: <6A961A56-2ACC-4B53-BB25-4C00FE203ADC@firsthand.net> The audio I found at http://ietf80streaming.dnsalias.net/ietf80/ietf80-ch4-wed-am.mp3 Christian On 3 Apr 2011, at 20:53, Jim Gettys wrote: > On 04/01/2011 11:44 AM, George Bonser wrote: >>> From: Joao C. Mendes Ogawa >>> Sent: Thursday, March 31, 2011 6:14 PM >>> Subject: Fwd: IPv4 Address Exhaustion Effects on the Earth >>> >>> FYI >>> >>> --Jonny Ogawa >>> >>> ----- Forwarded message from Stephen H. Inden ----- >>> >> Dang, I was hoping to see an RFC on Bufferbloat in Avian Carriers and >> how tail-drop is a messy solution that is to be avoided. >> > > Sigh... A major opportunity missed. > > Unfortunately the bufferbloat problem isn't a laughing matter, though I do wish I had thought of this idea in time for my talk. I will include this joke as some levity about the mess we're in as I repeat the talk going forward, and would tie in very nicely with one of the amusing reasons that "RED in a different light" has never been published. I really hate giving such bad news without some levity as it can be a real downer both for me and the audience. > > For those of you who missed my IETF talk, you can find the latest version (tweaked since IETF) at: http://mirrors.bufferbloat.net/Talks/PragueIETF/ > > I suspect audio is some place on the net as well; I presented at the transport area meeting. The questions after my talk are also very worth listening to. Time was precious in that venue, so I did feel rushed and hope to get a better opportunity in a month or two for that. It's a shorter version of my first talk given at Murray Hill http://mirrors.bufferbloat.net/Talks/BellLabs01192011/ which does have additional information impossible to fit in that short a time slot. > - Jim > > > > From gbonser at seven.com Sun Apr 3 21:04:47 2011 From: gbonser at seven.com (George Bonser) Date: Sun, 3 Apr 2011 19:04:47 -0700 Subject: IPv4 Address Exhaustion Effects on the Earth In-Reply-To: <4D98C224.1090906@freedesktop.org> References: <5A6D953473350C4B9995546AFE9939EE0C9E2BAE@RWC-EX1.corp.seven.com> <4D98C224.1090906@freedesktop.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E2BDA@RWC-EX1.corp.seven.com> > > Sigh... A major opportunity missed. > > Unfortunately the bufferbloat problem isn't a laughing matter, though I > do wish I had thought of this idea in time for my talk. I will include > this joke as some levity about the mess we're in as I repeat the talk > going forward, and would tie in very nicely with one of the amusing > reasons that "RED in a different light" has never been published. I > really hate giving such bad news without some levity as it can be a > real > downer both for me and the audience. Speaking of Van's paper, has that ever been located/revived? Is it available beyond that one earlier draft that is available on the Internet? George From scubacuda at gmail.com Mon Apr 4 10:07:47 2011 From: scubacuda at gmail.com (Rogelio) Date: Mon, 4 Apr 2011 08:07:47 -0700 Subject: recommendation on vendor for 8 Cisco 7201 routers? Message-ID: Anyone have any recommendations for a US Cisco shop that can sell me 8 new Cisco 7201 routers? If so, please email me the best person to contact. Thanks -- Also on LinkedIn?? Feel free to connect if you too are an open networker: scubacuda at gmail.com From andrew.wallace at rocketmail.com Mon Apr 4 10:46:22 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Mon, 4 Apr 2011 08:46:22 -0700 (PDT) Subject: 0day Windows Network Interception Configuration Vulnerability Message-ID: <21466.42267.qm@web59615.mail.ac4.yahoo.com> Someone has recently post to a mailing list: http://lists.grok.org.uk/pipermail/full-disclosure/2011-April/080096.html Andrew From trelane at trelane.net Mon Apr 4 10:56:40 2011 From: trelane at trelane.net (Andrew Kirch) Date: Mon, 04 Apr 2011 11:56:40 -0400 Subject: 0day Windows Network Interception Configuration Vulnerability In-Reply-To: <21466.42267.qm@web59615.mail.ac4.yahoo.com> References: <21466.42267.qm@web59615.mail.ac4.yahoo.com> Message-ID: <4D99EA38.70407@trelane.net> On 4/4/11 11:46 AM, andrew.wallace wrote: > Someone has recently post to a mailing list: http://lists.grok.org.uk/pipermail/full-disclosure/2011-April/080096.html > > Andrew > And users of that list certainly have it. Why is it being reposted here? request for admin action From Valdis.Kletnieks at vt.edu Mon Apr 4 11:14:56 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 04 Apr 2011 12:14:56 -0400 Subject: 0day Windows Network Interception Configuration Vulnerability In-Reply-To: Your message of "Mon, 04 Apr 2011 08:46:22 PDT." <21466.42267.qm@web59615.mail.ac4.yahoo.com> References: <21466.42267.qm@web59615.mail.ac4.yahoo.com> Message-ID: <10470.1301933696@localhost> On Mon, 04 Apr 2011 08:46:22 PDT, "andrew.wallace" said: > Someone has recently post to a mailing list: http://lists.grok.org.uk/pipermail/full-disclosure/2011-April/080096.html *yawn* No news, move along, nothing to see. RFC4862, section 6: The use of stateless address autoconfiguration and Duplicate Address Detection opens up the possibility of several denial-of-service attacks. For example, any node can respond to Neighbor Solicitations for a tentative address, causing the other node to reject the address as a duplicate. A separate document [RFC3756] discusses details about these attacks, which can be addressed with the Secure Neighbor Discovery protocol [RFC3971]. It should also be noted that [RFC3756] points out that the use of IP security is not always feasible depending on network environments. Note that similar text was present in RFC2462, all the way back in Dec 1998. So somebody's 13 years late to the party. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From iain.t.morris at gmail.com Mon Apr 4 11:20:14 2011 From: iain.t.morris at gmail.com (Iain Morris) Date: Mon, 4 Apr 2011 09:20:14 -0700 Subject: Time Warner DNS Message-ID: Apologies in advance if this is directed to the wrong folks, but is there someone at TWC I could talk to about a DNS issue on their servers? Users in NY, HI, and CA are not able to access a chunk of websites because of it. If anything, just a way for me to contact Time Warner ISP services that does not black hole my request because I'm not a customer would be very helpful. Thanks, -Iain -- -- - Iain Morris iain.t.morris at gmail.com From sparctacus at gmail.com Mon Apr 4 11:31:07 2011 From: sparctacus at gmail.com (Bryan Irvine) Date: Mon, 4 Apr 2011 09:31:07 -0700 Subject: IPv4 Address Exhaustion Effects on the Earth In-Reply-To: <201104020330.p323U2j5086276@mail.r-bonomi.com> References: <4D968758.5000501@scarynet.org> <201104020330.p323U2j5086276@mail.r-bonomi.com> Message-ID: On Fri, Apr 1, 2011 at 8:30 PM, Robert Bonomi wrote: > >> Date: Sat, 02 Apr 2011 04:18:00 +0200 >> From: Alexander Maassen >> Subject: Re: IPv4 Address Exhaustion Effects on the Earth >> >> wil, >> maybe after all this time you got the router, it gained 7lbs of all the >> dust in it ? > > Consider what happens if the carrier encounters a route reflector -- > flipping the bird?? Also how port mirrors will cause a collision and the bird will die. From dwhite at olp.net Mon Apr 4 11:41:17 2011 From: dwhite at olp.net (Dan White) Date: Mon, 4 Apr 2011 11:41:17 -0500 Subject: 0day Windows Network Interception Configuration Vulnerability In-Reply-To: <10470.1301933696@localhost> References: <21466.42267.qm@web59615.mail.ac4.yahoo.com> <10470.1301933696@localhost> Message-ID: <20110404164116.GA5641@dan.olp.net> On 04/04/11?12:14?-0400, Valdis.Kletnieks at vt.edu wrote: >On Mon, 04 Apr 2011 08:46:22 PDT, "andrew.wallace" said: >> Someone has recently post to a mailing list: http://lists.grok.org.uk/pipermail/full-disclosure/2011-April/080096.html > >*yawn* No news, move along, nothing to see. RFC4862, section 6: > > The use of stateless address autoconfiguration and Duplicate Address > Detection opens up the possibility of several denial-of-service > attacks. For example, any node can respond to Neighbor Solicitations > for a tentative address, causing the other node to reject the address > as a duplicate. A separate document [RFC3756] discusses details > about these attacks, which can be addressed with the Secure Neighbor > Discovery protocol [RFC3971]. It should also be noted that [RFC3756] > points out that the use of IP security is not always feasible > depending on network environments. > >Note that similar text was present in RFC2462, all the way back in Dec 1998. > >So somebody's 13 years late to the party. For more information, see RFC 6104 for a comprehensive problem statement (rogue routers), and RFC 6105 for a proposed solution. -- Dan White From jeroen at utwente.nl Mon Apr 4 11:46:03 2011 From: jeroen at utwente.nl (Jeroen van Ingen) Date: Mon, 04 Apr 2011 18:46:03 +0200 Subject: 0day Windows Network Interception Configuration Vulnerability In-Reply-To: <10470.1301933696@localhost> References: <21466.42267.qm@web59615.mail.ac4.yahoo.com> <10470.1301933696@localhost> Message-ID: <1301935563.8859.179.camel@icts-sp-039> On Mon, 2011-04-04 at 12:14 -0400, Valdis.Kletnieks at vt.edu wrote: > On Mon, 04 Apr 2011 08:46:22 PDT, "andrew.wallace" said: > > Someone has recently post to a mailing list: http://lists.grok.org.uk/pipermail/full-disclosure/2011-April/080096.html > > *yawn* No news, move along, nothing to see. RFC4862, section 6: I think the article is important: since a lot of systems and network admins still bury their heads in the sand when it comes to IPv6, they don't realize that it can be an attack vector in several ways... All recent operating systems have IPv6 enabled by default and prefer it over IPv4; this article clearly shows how easy it is to set up a MITM for IPv4 traffic when IPv6 hasn't been configured or properly secured on a network yet. I believe this attack will work on most networks out there, simply because IPv6 is enabled on hosts and rogue RA filtering hasn't been implemented on most switches yet. Regards, Jeroen van Ingen ICT Service Centre University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands From tsison at gmail.com Mon Apr 4 12:22:57 2011 From: tsison at gmail.com (=?utf-8?B?VGhlbyBTaXNvbg==?=) Date: Mon, 04 Apr 2011 11:22:57 -0600 Subject: =?utf-8?B?UmU6IHJlY29tbWVuZGF0aW9uIG9uIHZlbmRvciBmb3IgOCBDaXNjbyA3MjAxIHJvdXRlcnM/?= Message-ID: <4d99fe63.0431640a.49ff.08f8@mx.google.com> what city will you be deploying your routers? ----- Reply message ----- From: "Rogelio" Date: Mon, Apr 4, 2011 9:07 am Subject: recommendation on vendor for 8 Cisco 7201 routers? To: Anyone have any recommendations for a US Cisco shop that can sell me 8 new Cisco 7201 routers? If so, please email me the best person to contact. Thanks -- Also on LinkedIn?? Feel free to connect if you too are an open networker: scubacuda at gmail.com From swmike at swm.pp.se Mon Apr 4 12:46:32 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 4 Apr 2011 19:46:32 +0200 (CEST) Subject: 0day Windows Network Interception Configuration Vulnerability In-Reply-To: <1301935563.8859.179.camel@icts-sp-039> References: <21466.42267.qm@web59615.mail.ac4.yahoo.com> <10470.1301933696@localhost> <1301935563.8859.179.camel@icts-sp-039> Message-ID: On Mon, 4 Apr 2011, Jeroen van Ingen wrote: > a network yet. I believe this attack will work on most networks out > there, simply because IPv6 is enabled on hosts and rogue RA filtering > hasn't been implemented on most switches yet. Any responsible ISP will block this kind of L2 "unknown" traffic between customers. We see this happening unwittingly in the wild as of several years ago with Windows ICS announcing RA to both WAN and LAN because it (or thinks it) has 6to4 connectivity and wants to share it. Nothing new here, but the wider it's known the better. -- Mikael Abrahamsson email: swmike at swm.pp.se From nick at foobar.org Mon Apr 4 12:53:42 2011 From: nick at foobar.org (Nick Hilliard) Date: Mon, 04 Apr 2011 18:53:42 +0100 Subject: 0day Windows Network Interception Configuration Vulnerability In-Reply-To: <21466.42267.qm@web59615.mail.ac4.yahoo.com> References: <21466.42267.qm@web59615.mail.ac4.yahoo.com> Message-ID: <4D9A05A6.6010909@foobar.org> On 04/04/2011 16:46, andrew.wallace wrote: > Someone has recently post to a mailing list: > http://lists.grok.org.uk/pipermail/full-disclosure/2011-April/080096.html There's a serious vulnerability in the default ipv4 configuration too: Windows will accept a reply from any DHCP server which replies. The fix right now is for Microsoft to disable IPv4 by default. I think I'm the first person in the world to notice this, so can you cross-post this to full-disclosure as a critical 0day? kthx, Nick From rsk at gsp.org Mon Apr 4 13:04:10 2011 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 4 Apr 2011 14:04:10 -0400 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: <4D97ACA2.8000702@thebaughers.com> References: <20110401123804.GA5883@gsp.org> <4D97ACA2.8000702@thebaughers.com> Message-ID: <20110404180410.GA4394@gsp.org> On Sat, Apr 02, 2011 at 06:09:22PM -0500, Jason Baugher wrote: > We would NEVER "out" the customer to the public, even if we felt the > abuse was intentional. My CEO and our lawyers would blow a gasket if > we were to potentially libel a customer. And this why we (the community) find ourselves where we do, because nearly everyone has this policy or one quite similar to it. Until this changes -- which will require CEOs with spines and lawyers who craft ToS agreements that stipulate full disclosure in abuse cases -- there will always be one more place for The Bad Guys to go. And they will: even if they *could* stop, and clearly many of them are sociopaths who can't, why should they? It's too lucrative and the chances they'll endure any meaningful sanction are tiny, doubly so if they have any talent for the usual shuffle. (Which is: agree to a pathetic settlement, promise not to do it again, dissolve the company, start a new company, do it again.) ---rsk From bygg at cafax.se Mon Apr 4 20:22:25 2011 From: bygg at cafax.se (Johnny Eriksson) Date: Mon, 4 Apr 2011 20:22:25 WET DST Subject: 0day Windows Network Interception Configuration Vulnerability In-Reply-To: Your message of Mon, 04 Apr 2011 18:53:42 +0100 Message-ID: Nick Hilliard wrote: > The fix right now is for Microsoft to disable IPv4 by default. Yes, please. That would put a serious dent in most botnets... > Nick --Johnny From jeroen at utwente.nl Mon Apr 4 14:00:10 2011 From: jeroen at utwente.nl (Jeroen van Ingen) Date: Mon, 04 Apr 2011 21:00:10 +0200 Subject: 0day Windows Network Interception Configuration Vulnerability In-Reply-To: References: <21466.42267.qm@web59615.mail.ac4.yahoo.com> <10470.1301933696@localhost> <1301935563.8859.179.camel@icts-sp-039> Message-ID: <1301943610.2302.30.camel@ambion> On Mon, 2011-04-04 at 19:46 +0200, Mikael Abrahamsson wrote: > > I believe this attack will work on most networks out > > there, simply because IPv6 is enabled on hosts and rogue RA filtering > > hasn't been implemented on most switches yet. > > Any responsible ISP will block this kind of L2 "unknown" traffic between > customers. I fully agree, but not all networks are run by ISPs (let alone by "responsible" persons/entities). Perhaps not the main audience for Nanog, but there will be enough enterprises, small ISPs or colo facilities, schools / edu networks etc where this attack is currently possible. > We see this happening unwittingly in the wild as of several years ago with > Windows ICS announcing RA to both WAN and LAN because it (or thinks it) > has 6to4 connectivity and wants to share it. It's almost the same, but not quite: the same in the sense that it might result in MITM for traffic and rogue RAs are involved; different because with the attack described, *virtually all* traffic can be intercepted with the addition of NAT-PT including modified DNS responses (eg returning quad-A RRs for (originally) IPv4-only services. That's not the same as some ICS box which usually doesn't even properly forward the v6 traffic, and if it does, only sees the traffic for the small percentage of v6-enabled services with both an A and quad-A resource record in DNS. > Nothing new here, but the wider it's known the better. To me the NAT-PT part was new, but I don't work for an ISP and perhaps you wouldn't consider me to be a responsible network admin... even though our University has been running RA monitors on all segments for a long time (and will continue to do so until we can properly filter rogue RA on all edge ports etc). I don't know *everything* there is to know in networking, nor will I believe anyone who claims he/she does. The main reason I responded was the "blah blah old news" attitude in one of the reactions, while I doubt that the possibilities with the combination of methods as described are that widely known. But if I'm the only (security) ignorant person on this list, please forgive me ;) Regards, Jeroen van Ingen ICT Service Centre University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands From jason at thebaughers.com Mon Apr 4 14:30:41 2011 From: jason at thebaughers.com (Jason Baugher) Date: Mon, 04 Apr 2011 14:30:41 -0500 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: <20110404180410.GA4394@gsp.org> References: <20110401123804.GA5883@gsp.org> <4D97ACA2.8000702@thebaughers.com> <20110404180410.GA4394@gsp.org> Message-ID: <4D9A1C61.6070401@thebaughers.com> On 4/4/2011 1:04 PM, Rich Kulawiec wrote: > On Sat, Apr 02, 2011 at 06:09:22PM -0500, Jason Baugher wrote: >> We would NEVER "out" the customer to the public, even if we felt the >> abuse was intentional. My CEO and our lawyers would blow a gasket if >> we were to potentially libel a customer. > And this why we (the community) find ourselves where we do, because > nearly everyone has this policy or one quite similar to it. Until > this changes -- which will require CEOs with spines and lawyers who > craft ToS agreements that stipulate full disclosure in abuse cases -- > there will always be one more place for The Bad Guys to go. > Full disclosure in abuse is not necessarily equivalent to full disclosure in -suspected- abuse. The earlier comments in this thread were more or less demands for disclosure when the vendor had not yet been able to speak with the customer to determine if there was indeed abuse and if it was intentional. I suppose theoretically that a ToS could be crafted that would allow the vendor to release customer information in the case of ANY suspected abuse, but do you really think that would make a difference to "The Bad Guys"? Jason Jason From mruiz at lstfinancial.com Mon Apr 4 14:36:20 2011 From: mruiz at lstfinancial.com (Michael Ruiz) Date: Mon, 4 Apr 2011 19:36:20 +0000 Subject: recommendation on vendor for 8 Cisco 7201 routers? Message-ID: <690D7D20D2507C44BA8066926B2009890867EB@ES1002.ic-sa.com> Hello All, I am looking for some good reading material to get a better understanding of IPV6. I know how to convert HEX into decimal format. What I am looking for is how to under the CIDR notation and break them out into subnets. Thank you in advance. MAR. From Valdis.Kletnieks at vt.edu Mon Apr 4 14:43:24 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 04 Apr 2011 15:43:24 -0400 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: Your message of "Mon, 04 Apr 2011 14:30:41 CDT." <4D9A1C61.6070401@thebaughers.com> References: <20110401123804.GA5883@gsp.org> <4D97ACA2.8000702@thebaughers.com> <20110404180410.GA4394@gsp.org> <4D9A1C61.6070401@thebaughers.com> Message-ID: <21506.1301946204@localhost> On Mon, 04 Apr 2011 14:30:41 CDT, Jason Baugher said: > I suppose theoretically that a ToS could be crafted that would allow the > vendor to release customer information in the case of ANY suspected > abuse, but do you really think that would make a difference to "The Bad > Guys"? A better question - would it make a difference to The Bad Guys if the ToS included a "Name and Shame" clause, where if they were terminated for cause the fact *would* be publicized? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mruiz at lstfinancial.com Mon Apr 4 14:47:52 2011 From: mruiz at lstfinancial.com (Michael Ruiz) Date: Mon, 4 Apr 2011 19:47:52 +0000 Subject: IPv4 Address Exhaustion Effects on the Earth Message-ID: <690D7D20D2507C44BA8066926B200989086876@ES1002.ic-sa.com> On Fri, Apr 1, 2011 at 8:30 PM, Robert Bonomi > wrote: > >> Date: Sat, 02 Apr 2011 04:18:00 +0200 >> From: Alexander Maassen > >> Subject: Re: IPv4 Address Exhaustion Effects on the Earth >> >> wil, >> maybe after all this time you got the router, it gained 7lbs of all the >> dust in it ? > > Consider what happens if the carrier encounters a route reflector -- > flipping the bird?? >Also how port mirrors will cause a collision and the bird will die. Speaking of birds and electromagnetic field, I wonder if birds are going to crashing into things like they did in the core. Now that would be pretty interesting. MAR. From davidd at corp.nac.net Mon Apr 4 14:48:40 2011 From: davidd at corp.nac.net (David DiGiacomo) Date: Mon, 4 Apr 2011 15:48:40 -0400 Subject: recommendation on vendor for 8 Cisco 7201 routers? In-Reply-To: <690D7D20D2507C44BA8066926B2009890867EB@ES1002.ic-sa.com> References: <690D7D20D2507C44BA8066926B2009890867EB@ES1002.ic-sa.com> Message-ID: Michael, I have had excellent service from OSI Hardware, they sell new & used at a pretty good price. They have 18 month warranties and I've had stuff ship same day and on my doorstep first thing in the morning. The guy I deal with is Stephen Craig, scraig at osihardware.com , (214) 267-8519 Good luck Dave D ____________________ Dave Joel DiGiacomo "davidd at corp.nac.net" Network Engineer / Peering Coordinator Net Access Corp Network Operations Center 973-590-5050 -----Original Message----- From: Michael Ruiz [mailto:mruiz at lstfinancial.com] Sent: Monday, April 04, 2011 3:36 PM To: nanog at nanog.org Subject: recommendation on vendor for 8 Cisco 7201 routers? References: <690D7D20D2507C44BA8066926B2009890867EB@ES1002.ic-sa.com> Message-ID: <690D7D20D2507C44BA8066926B2009890868A3@ES1002.ic-sa.com> Cool How is their service? Do they Telecom equipment. For example, Adtran and Fujitsu equipment? -----Original Message----- From: David DiGiacomo [mailto:davidd at corp.nac.net] Sent: Monday, April 04, 2011 2:49 PM To: Michael Ruiz; nanog at nanog.org Subject: RE: recommendation on vendor for 8 Cisco 7201 routers? Michael, I have had excellent service from OSI Hardware, they sell new & used at a pretty good price. They have 18 month warranties and I've had stuff ship same day and on my doorstep first thing in the morning. The guy I deal with is Stephen Craig, scraig at osihardware.com , (214) 267-8519 Good luck Dave D ____________________ Dave Joel DiGiacomo "davidd at corp.nac.net" Network Engineer / Peering Coordinator Net Access Corp Network Operations Center 973-590-5050 -----Original Message----- From: Michael Ruiz [mailto:mruiz at lstfinancial.com] Sent: Monday, April 04, 2011 3:36 PM To: nanog at nanog.org Subject: recommendation on vendor for 8 Cisco 7201 routers? References: <690D7D20D2507C44BA8066926B2009890867EB@ES1002.ic-sa.com> <690D7D20D2507C44BA8066926B2009890868A3@ES1002.ic-sa.com> Message-ID: We have been dealing with them for close to a year now and the service has been pretty astonishing thus far. I can usually get a price quote within an hour, their prices are usually lower than my other vendors and I can get orders shipped the same day. They back everything with an 18 month warranty and I have never had to use it yet (knock on wood). I can tell you I trust them and they have not let me down yet. They do sell optics for Adtran and Fujitsu but they do not stock hardware for that equipment. ____________________ Dave Joel DiGiacomo "davidd at corp.nac.net" Network Engineer / Peering Coordinator Net Access Corp Network Operations Center 973-590-5050 -----Original Message----- From: Michael Ruiz [mailto:mruiz at lstfinancial.com] Sent: Monday, April 04, 2011 3:52 PM To: David DiGiacomo; nanog at nanog.org Subject: RE: recommendation on vendor for 8 Cisco 7201 routers? Cool How is their service? Do they Telecom equipment. For example, Adtran and Fujitsu equipment? -----Original Message----- From: David DiGiacomo [mailto:davidd at corp.nac.net] Sent: Monday, April 04, 2011 2:49 PM To: Michael Ruiz; nanog at nanog.org Subject: RE: recommendation on vendor for 8 Cisco 7201 routers? Michael, I have had excellent service from OSI Hardware, they sell new & used at a pretty good price. They have 18 month warranties and I've had stuff ship same day and on my doorstep first thing in the morning. The guy I deal with is Stephen Craig, scraig at osihardware.com , (214) 267-8519 Good luck Dave D ____________________ Dave Joel DiGiacomo "davidd at corp.nac.net" Network Engineer / Peering Coordinator Net Access Corp Network Operations Center 973-590-5050 -----Original Message----- From: Michael Ruiz [mailto:mruiz at lstfinancial.com] Sent: Monday, April 04, 2011 3:36 PM To: nanog at nanog.org Subject: recommendation on vendor for 8 Cisco 7201 routers? References: <690D7D20D2507C44BA8066926B2009890867EB@ES1002.ic-sa.com> <690D7D20D2507C44BA8066926B2009890868A3@ES1002.ic-sa.com> Message-ID: <690D7D20D2507C44BA8066926B20098908690A@ES1002.ic-sa.com> Ok cool. I will keep them mind for Cisco equipment. Thank you sir for your reply. -----Original Message----- From: David DiGiacomo [mailto:davidd at corp.nac.net] Sent: Monday, April 04, 2011 3:06 PM To: Michael Ruiz; nanog at nanog.org Subject: RE: recommendation on vendor for 8 Cisco 7201 routers? We have been dealing with them for close to a year now and the service has been pretty astonishing thus far. I can usually get a price quote within an hour, their prices are usually lower than my other vendors and I can get orders shipped the same day. They back everything with an 18 month warranty and I have never had to use it yet (knock on wood). I can tell you I trust them and they have not let me down yet. They do sell optics for Adtran and Fujitsu but they do not stock hardware for that equipment. ____________________ Dave Joel DiGiacomo "davidd at corp.nac.net" Network Engineer / Peering Coordinator Net Access Corp Network Operations Center 973-590-5050 -----Original Message----- From: Michael Ruiz [mailto:mruiz at lstfinancial.com] Sent: Monday, April 04, 2011 3:52 PM To: David DiGiacomo; nanog at nanog.org Subject: RE: recommendation on vendor for 8 Cisco 7201 routers? Cool How is their service? Do they Telecom equipment. For example, Adtran and Fujitsu equipment? -----Original Message----- From: David DiGiacomo [mailto:davidd at corp.nac.net] Sent: Monday, April 04, 2011 2:49 PM To: Michael Ruiz; nanog at nanog.org Subject: RE: recommendation on vendor for 8 Cisco 7201 routers? Michael, I have had excellent service from OSI Hardware, they sell new & used at a pretty good price. They have 18 month warranties and I've had stuff ship same day and on my doorstep first thing in the morning. The guy I deal with is Stephen Craig, scraig at osihardware.com , (214) 267-8519 Good luck Dave D ____________________ Dave Joel DiGiacomo "davidd at corp.nac.net" Network Engineer / Peering Coordinator Net Access Corp Network Operations Center 973-590-5050 -----Original Message----- From: Michael Ruiz [mailto:mruiz at lstfinancial.com] Sent: Monday, April 04, 2011 3:36 PM To: nanog at nanog.org Subject: recommendation on vendor for 8 Cisco 7201 routers? References: <690D7D20D2507C44BA8066926B2009890867FA@ES1002.ic-sa.com> Message-ID: <4D9A2826.7010502@gmail.com> On 2011-04-04 21:43, Michael Ruiz wrote: > Hello All, > > I am looking for some good reading material to get a better understanding of IPV6. I know how to convert HEX into decimal format. What I am looking for is how to under the CIDR notation and break them out into subnets. Thank you in advance. > > MAR. > Hi! While not a IPv6 exclusive book, the TCP/IP Guide by Charles M. Kozierok has an overview of most topics related to TCP/IP. It might not be very detailed, but it is usually detailed enough. The book can be found online here http://www.tcpipguide.com/free/index.htm , so as long as you don't mind sitting by the computer and reading, you don't need to buy it. The following section http://www.tcpipguide.com/free/t_InternetProtocolVersion6IPv6IPNextGenerationIPng.htm talks about IPv6, and amongst other things the addressing scheme. HTH! -- Niclas From sfouant at shortestpathfirst.net Mon Apr 4 15:23:02 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 4 Apr 2011 16:23:02 -0400 Subject: IPV6 Training Books In-Reply-To: <690D7D20D2507C44BA8066926B2009890867FA@ES1002.ic-sa.com> References: <690D7D20D2507C44BA8066926B2009890867FA@ES1002.ic-sa.com> Message-ID: <00cc01cbf306$1989b680$4c9d2380$@net> > -----Original Message----- > From: Michael Ruiz [mailto:mruiz at lstfinancial.com] > Sent: Monday, April 04, 2011 3:43 PM > To: nanog at nanog.org > Subject: IPV6 Training Books > > Hello All, > > I am looking for some good reading material to get a > better understanding of IPV6. I know how to convert HEX into decimal > format. What I am looking for is how to under the CIDR notation and > break them out into subnets. Thank you in advance. I recommend 'Running IPv6' by Iljitsch van Beijnum or 'IPv6 Essentials' by Silvia Hagen. Also Chris Grundemann wrote a Day One Guide for Juniper entitled "Exploring IPv6" which you can download for free at http://forums.juniper.net/t5/Day-One-Books/Day-One-Book-Exploring-IPv6/ba-p/ 52402 - Chapter 1 in the Day One guide has a lot of really good information on understanding IPv6 addressing formats, subnetting, etc. Either one of those should be able to answer most of your questions. Stefan Fouant From jg at freedesktop.org Mon Apr 4 15:30:56 2011 From: jg at freedesktop.org (Jim Gettys) Date: Mon, 04 Apr 2011 16:30:56 -0400 Subject: IPv4 Address Exhaustion Effects on the Earth In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E2BDA@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0C9E2BAE@RWC-EX1.corp.seven.com> <4D98C224.1090906@freedesktop.org> <5A6D953473350C4B9995546AFE9939EE0C9E2BDA@RWC-EX1.corp.seven.com> Message-ID: <4D9A2A80.2060903@freedesktop.org> On 04/03/2011 10:04 PM, George Bonser wrote: >> Sigh... A major opportunity missed. >> >> Unfortunately the bufferbloat problem isn't a laughing matter, though > I >> do wish I had thought of this idea in time for my talk. I will > include >> this joke as some levity about the mess we're in as I repeat the talk >> going forward, and would tie in very nicely with one of the amusing >> reasons that "RED in a different light" has never been published. I >> really hate giving such bad news without some levity as it can be a >> real >> downer both for me and the audience. > Speaking of Van's paper, has that ever been located/revived? Is it > available beyond that one earlier draft that is available on the > Internet? Van and Kathie managed to get a later version off a disk image and get it out of Framemaker. Unfortunately, the paper was only half edited when the second attempt at publication failed due to the circumstances I blogged about at: http://gettys.wordpress.com/2011/01/06/a-committee-is-a-life-form-with-six-or-more-legs-and-no-brain-lazarus-long/ Right now, they are concentrating on trying to get a consistent description of the proposed RED Light algorithm captured correctly, so we can code it up and try it. Then they will work on finishing up the rest of the text for publication sometime this summer. What I have in hand from Kathie at the moment is not internally consistent, though much longer. In the mean while, we've started work on various AQM and buffer management systems, at www.bufferbloat.net. SFB (Stochastic Fair Blue) went upstream into Linux to aid testing last month, and we have an implementation of eBDP as well with which we are experimenting. Wireless is much more of a challenge than the classic internet router case. Please come help. Note that the paper "Characterizing Residential Broadband Networks" by Dischinger, et. al. indicates that a large fraction (in their 2 year old sample, 30% or so) of broadband head ends are running without RED, and should be doing so if at all possible; alternatives are years out by the time they are tested and deployed, and operators running without it in congested systems are inflicting pain on their customers. - Jim From mruiz at lstfinancial.com Mon Apr 4 15:34:06 2011 From: mruiz at lstfinancial.com (Michael Ruiz) Date: Mon, 4 Apr 2011 20:34:06 +0000 Subject: IPV6 Training Books In-Reply-To: <00cc01cbf306$1989b680$4c9d2380$@net> References: <690D7D20D2507C44BA8066926B2009890867FA@ES1002.ic-sa.com> <00cc01cbf306$1989b680$4c9d2380$@net> Message-ID: <690D7D20D2507C44BA8066926B200989086BCA@ES1002.ic-sa.com> Thank you all for replying. -----Original Message----- From: Stefan Fouant [mailto:sfouant at shortestpathfirst.net] Sent: Monday, April 04, 2011 3:23 PM To: Michael Ruiz; nanog at nanog.org Subject: RE: IPV6 Training Books > -----Original Message----- > From: Michael Ruiz [mailto:mruiz at lstfinancial.com] > Sent: Monday, April 04, 2011 3:43 PM > To: nanog at nanog.org > Subject: IPV6 Training Books > > Hello All, > > I am looking for some good reading material to get a > better understanding of IPV6. I know how to convert HEX into decimal > format. What I am looking for is how to under the CIDR notation and > break them out into subnets. Thank you in advance. I recommend 'Running IPv6' by Iljitsch van Beijnum or 'IPv6 Essentials' by Silvia Hagen. Also Chris Grundemann wrote a Day One Guide for Juniper entitled "Exploring IPv6" which you can download for free at http://forums.juniper.net/t5/Day-One-Books/Day-One-Book-Exploring-IPv6/ba-p/ 52402 - Chapter 1 in the Day One guide has a lot of really good information on understanding IPv6 addressing formats, subnetting, etc. Either one of those should be able to answer most of your questions. Stefan Fouant From jason at thebaughers.com Mon Apr 4 15:50:37 2011 From: jason at thebaughers.com (Jason Baugher) Date: Mon, 04 Apr 2011 15:50:37 -0500 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: <21506.1301946204@localhost> References: <20110401123804.GA5883@gsp.org> <4D97ACA2.8000702@thebaughers.com> <20110404180410.GA4394@gsp.org> <4D9A1C61.6070401@thebaughers.com> <21506.1301946204@localhost> Message-ID: <4D9A2F1D.1060300@thebaughers.com> On 4/4/2011 2:43 PM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 04 Apr 2011 14:30:41 CDT, Jason Baugher said: > >> I suppose theoretically that a ToS could be crafted that would allow the >> vendor to release customer information in the case of ANY suspected >> abuse, but do you really think that would make a difference to "The Bad >> Guys"? > A better question - would it make a difference to The Bad Guys if the ToS > included a "Name and Shame" clause, where if they were terminated for cause the > fact *would* be publicized? > I doubt it. The kind of person who perpetrates mass abuse probably doesn't have a conscience. From jg at freedesktop.org Mon Apr 4 15:55:26 2011 From: jg at freedesktop.org (Jim Gettys) Date: Mon, 04 Apr 2011 16:55:26 -0400 Subject: State of QoS peering in Nanog In-Reply-To: <020901cbf21f$47462b40$d5d281c0$@net> References: <20110402215607.GA86553@ussenterprise.ufp.org> <20110403022345.GA94165@ussenterprise.ufp.org> <020901cbf21f$47462b40$d5d281c0$@net> Message-ID: <4D9A303E.40900@freedesktop.org> On 04/03/2011 12:50 PM, Stefan Fouant wrote: >> -----Original Message----- >> From: Leo Bicknell [mailto:bicknell at ufp.org] >> Sent: Saturday, April 02, 2011 10:24 PM >> >> But it also only affects priority queue traffic. I realize I'm making >> a value judgment, but many customers under DDoS would find things >> vastly improved if their video conferencing went down, but everything >> else continued to work (if slowly), compared to today when everything >> goes down. > I'd like to observe that discussion when the Netflix guys come calling on > the support line - "Hey Netflix, yeah you're under attack and your > subscribers can't watch videos at the moment, but the good news is that all > other apps running on our network are currently unaffected". ;> > >> In closing, I want to push folks back to the buffer bloat issue though. >> More than once I've been asked to configure QoS on the network to >> support VoIP, Video Conferencing or the like. These things were >> deployed and failed to work properly. I went into the network and >> _reduced_ the buffer sizes, and _increased_ packet drops. Magically >> these applications worked fine, with no QoS. >> >> Video conferencing can tolerate a 1% packet drop, but can't tolerate a >> 4 second buffer delay. Many people today who want QoS are actually >> suffering from buffer bloat. :( > Concur 100%. In my experience, I've gotten much better performance w/ > VoIP/Video Conferencing and other delay-intolerant applications when setting > buffer sizes to a temporal value rather than based on a _fixed_ number of > packets. > There is no magic here at all. There are dark buffers all over the Internet; some network operators run routers and broadband without RED enabled, our broadband gear suffers from excessive buffering, as does our home routers and hosts. What is happening, as I outlined at the transport area meeting at the IETF in Prague, is that by putting in excessive buffers everywhere in the name of avoiding packet loss, we've destroyed TCP congestion avoidance and badly damaged slow start while adding terrible latency and jitter. Tail drop with long buffers delays notification of congestion to TCP, and defeats the algorithms. Even without this additional problem (which causes further havoc), TCP will always fill buffers on either side of your bottleneck link in your path. So your large buffers add latency, and when a link is saturated, the buffers on either side of the saturated links fill, and stay so (most commonly in the broadband gear, but often also in the hosts/home routers over 802.11 links). By running with AQM (or small buffers), you reduce the need for QOS (which doesn't yet exist seriously in the network edge). See my talk in http://mirrors.bufferbloat.net/Talks/PragueIETF/ (slightly updated since the Prague IETF) and you can listen to it at http://ietf80streaming.dnsalias.net/ietf80/ietf80-ch4-wed-am.mp3 A longer version of that talk is at:http://mirrors.bufferbloat.net/Talks/BellLabs01192011/ Note that there is a lot you can do immediately to reduce your personal suffering, by using bandwidth shaping to reduce/eliminate the buffer problem in your home broadband gear, and by ensuring that your 802.11 wireless bandwidth is always greater than your home broadband bandwidth (since the bloat in current home routers can be even worse than in the broadband gear). See http://gettys.wordpress.com for more detail. Please come help fix this mess at bufferbloat.net. The bloat mailing list is bloat at lists.bufferbloat.net. We're all in this bloat together. - Jim From unclepieman at gmail.com Mon Apr 4 19:17:46 2011 From: unclepieman at gmail.com (Payam Chychi) Date: Mon, 4 Apr 2011 17:17:46 -0700 Subject: LAGing backbone links Message-ID: Hello All, I was wondering if anyone had any thoughts as to the best practices of running multiple backbone links between 2 routers. In the past we've added additional links as needed, then simply enabled IS-IS when they were good to go. I'd then let IS-IS handle load balancing the traffic over the two links. But I know that others out there would setup a LAG once they had more than one link between two routers. Is there a best practice? Does it matter? Any implications to a MPLS setup? Thanks From marka at isc.org Mon Apr 4 19:59:31 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 05 Apr 2011 10:59:31 +1000 Subject: IPV6 Training Books In-Reply-To: Your message of "Mon, 04 Apr 2011 19:43:09 GMT." <690D7D20D2507C44BA8066926B2009890867FA@ES1002.ic-sa.com> References: <690D7D20D2507C44BA8066926B2009890867FA@ES1002.ic-sa.com> Message-ID: <20110405005931.4DF3FDC811D@drugs.dv.isc.org> In message <690D7D20D2507C44BA8066926B2009890867FA at ES1002.ic-sa.com>, Michael R uiz writes: > Hello All, > > I am looking for some good reading material to get a better= > understanding of IPV6. I know how to convert HEX into decimal format. Wh= > at I am looking for is how to under the CIDR notation and break them out in= > to subnets. Thank you in advance. If you think in hex its straight forward to do CIDR in IPv6. There are only three groupings on a non nibble boundaries. You also display the entire 128 bits with the least significant bits set to zero. The :: notation is used to shorten the displayed address. e.g for a /57, /58 and /59 with leading bits of 2001:23bc:fe8d:b200::/56 you would have. /57 {0,1,2,3,4,5,6,7} {8,9,a,b,c,d,e,f} 2001:23bc:fe8d:b200::/57 2001:23bc:fe8d:b280::/57 /58 {0,1,2,3} {4,5,6,7} {8,9,a,b} {c,d,e,f} 2001:23bc:fe8d:b200::/58 2001:23bc:fe8d:b240::/58 2001:23bc:fe8d:b280::/58 2001:23bc:fe8d:b2c0::/58 /59 {0,1} {2,3} {4,5} {6,7} {8,9} {a,b} {c,d} {e,f} 2001:23bc:fe8d:b200::/59 2001:23bc:fe8d:b220::/59 2001:23bc:fe8d:b240::/59 2001:23bc:fe8d:b260::/59 2001:23bc:fe8d:b280::/59 2001:23bc:fe8d:b2a0::/59 2001:23bc:fe8d:b2c0::/59 2001:23bc:fe8d:b2e0::/59 Note the last nibble before the :: is 0 and is there so that the final bits are all zeros. The following all represent the same cidr block. 2001:23bc:fe8d:b2e0::/59 2001:23bc:fe8d:b2e0:0000:0000:0000:0000/59 2001:23bc:fe8d:b2e0:0:0:0:0/59 Normally you just assign /64 subnets and delegate address blocks on nibble boundaries to end customers, e.g. /48, /52, /56 or /60. This means that end customers don't need do deal with cidr block if they don't want to. They can just route individual /64. > MAR. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nurul at apnic.net Mon Apr 4 20:07:13 2011 From: nurul at apnic.net (Roman) Date: Tue, 05 Apr 2011 11:07:13 +1000 Subject: IPV6 Training Books In-Reply-To: <20110405005931.4DF3FDC811D@drugs.dv.isc.org> References: <690D7D20D2507C44BA8066926B2009890867FA@ES1002.ic-sa.com> <20110405005931.4DF3FDC811D@drugs.dv.isc.org> Message-ID: <4D9A6B41.6070209@apnic.net> Best book on IPv6 (My personal opinion) http://www.amazon.com/Migrating-IPv6-Practical-Implementing-Networks/dp/0471498920/ref=sr_1_16?ie=UTF8&qid=1301965365&sr=8-16 Roman On 5/04/11 10:59 AM, Mark Andrews wrote: > In message<690D7D20D2507C44BA8066926B2009890867FA at ES1002.ic-sa.com>, Michael R > uiz writes: >> Hello All, >> >> I am looking for some good reading material to get a better= >> understanding of IPV6. I know how to convert HEX into decimal format. Wh= >> at I am looking for is how to under the CIDR notation and break them out in= >> to subnets. Thank you in advance. > > If you think in hex its straight forward to do CIDR in IPv6. There > are only three groupings on a non nibble boundaries. You also > display the entire 128 bits with the least significant bits set to > zero. The :: notation is used to shorten the displayed address. > > e.g for a /57, /58 and /59 with leading bits of 2001:23bc:fe8d:b200::/56 > you would have. > > /57 {0,1,2,3,4,5,6,7} {8,9,a,b,c,d,e,f} > 2001:23bc:fe8d:b200::/57 > 2001:23bc:fe8d:b280::/57 > /58 {0,1,2,3} {4,5,6,7} {8,9,a,b} {c,d,e,f} > 2001:23bc:fe8d:b200::/58 > 2001:23bc:fe8d:b240::/58 > 2001:23bc:fe8d:b280::/58 > 2001:23bc:fe8d:b2c0::/58 > /59 {0,1} {2,3} {4,5} {6,7} {8,9} {a,b} {c,d} {e,f} > 2001:23bc:fe8d:b200::/59 > 2001:23bc:fe8d:b220::/59 > 2001:23bc:fe8d:b240::/59 > 2001:23bc:fe8d:b260::/59 > 2001:23bc:fe8d:b280::/59 > 2001:23bc:fe8d:b2a0::/59 > 2001:23bc:fe8d:b2c0::/59 > 2001:23bc:fe8d:b2e0::/59 > > Note the last nibble before the :: is 0 and is there so that the > final bits are all zeros. The following all represent the same > cidr block. > > 2001:23bc:fe8d:b2e0::/59 > 2001:23bc:fe8d:b2e0:0000:0000:0000:0000/59 > 2001:23bc:fe8d:b2e0:0:0:0:0/59 > > Normally you just assign /64 subnets and delegate address blocks > on nibble boundaries to end customers, e.g. /48, /52, /56 or /60. > This means that end customers don't need do deal with cidr block > if they don't want to. They can just route individual /64. > >> MAR. >> -- ---------------------------------------------------------------------- Nurul Islam Roman email: nurul at apnic.net Internet Resource Analyst, APNIC sip: nurul at voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 direct: +61 7 3858 3190 From owen at delong.com Mon Apr 4 20:52:22 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Apr 2011 18:52:22 -0700 Subject: IPV6 Training Books In-Reply-To: <20110405005931.4DF3FDC811D@drugs.dv.isc.org> References: <690D7D20D2507C44BA8066926B2009890867FA@ES1002.ic-sa.com> <20110405005931.4DF3FDC811D@drugs.dv.isc.org> Message-ID: More ideally, you give every end site a /48 if they want more than one network. Owen On Apr 4, 2011, at 5:59 PM, Mark Andrews wrote: > > In message <690D7D20D2507C44BA8066926B2009890867FA at ES1002.ic-sa.com>, Michael R > uiz writes: >> Hello All, >> >> I am looking for some good reading material to get a better= >> understanding of IPV6. I know how to convert HEX into decimal format. Wh= >> at I am looking for is how to under the CIDR notation and break them out in= >> to subnets. Thank you in advance. > > If you think in hex its straight forward to do CIDR in IPv6. There > are only three groupings on a non nibble boundaries. You also > display the entire 128 bits with the least significant bits set to > zero. The :: notation is used to shorten the displayed address. > > e.g for a /57, /58 and /59 with leading bits of 2001:23bc:fe8d:b200::/56 > you would have. > > /57 {0,1,2,3,4,5,6,7} {8,9,a,b,c,d,e,f} > 2001:23bc:fe8d:b200::/57 > 2001:23bc:fe8d:b280::/57 > /58 {0,1,2,3} {4,5,6,7} {8,9,a,b} {c,d,e,f} > 2001:23bc:fe8d:b200::/58 > 2001:23bc:fe8d:b240::/58 > 2001:23bc:fe8d:b280::/58 > 2001:23bc:fe8d:b2c0::/58 > /59 {0,1} {2,3} {4,5} {6,7} {8,9} {a,b} {c,d} {e,f} > 2001:23bc:fe8d:b200::/59 > 2001:23bc:fe8d:b220::/59 > 2001:23bc:fe8d:b240::/59 > 2001:23bc:fe8d:b260::/59 > 2001:23bc:fe8d:b280::/59 > 2001:23bc:fe8d:b2a0::/59 > 2001:23bc:fe8d:b2c0::/59 > 2001:23bc:fe8d:b2e0::/59 > > Note the last nibble before the :: is 0 and is there so that the > final bits are all zeros. The following all represent the same > cidr block. > > 2001:23bc:fe8d:b2e0::/59 > 2001:23bc:fe8d:b2e0:0000:0000:0000:0000/59 > 2001:23bc:fe8d:b2e0:0:0:0:0/59 > > Normally you just assign /64 subnets and delegate address blocks > on nibble boundaries to end customers, e.g. /48, /52, /56 or /60. > This means that end customers don't need do deal with cidr block > if they don't want to. They can just route individual /64. > >> MAR. >> > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From gbonser at seven.com Mon Apr 4 21:24:29 2011 From: gbonser at seven.com (George Bonser) Date: Mon, 4 Apr 2011 19:24:29 -0700 Subject: IPv4 Address Exhaustion Effects on the Earth In-Reply-To: <4D9A2A80.2060903@freedesktop.org> References: <5A6D953473350C4B9995546AFE9939EE0C9E2BAE@RWC-EX1.corp.seven.com> <4D98C224.1090906@freedesktop.org> <5A6D953473350C4B9995546AFE9939EE0C9E2BDA@RWC-EX1.corp.seven.com> <4D9A2A80.2060903@freedesktop.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E2C13@RWC-EX1.corp.seven.com> > In the mean while, we've started work on various AQM and buffer > management systems, at www.bufferbloat.net. SFB (Stochastic Fair Blue) > went upstream into Linux to aid testing last month, and we have an > implementation of eBDP as well with which we are experimenting. > Wireless is much more of a challenge than the classic internet router > case. Please come help. > In my context "Wireless" means "mobile" and the challenge there is that "I lost a packet" doesn't mean "there is congestion". It most likely means the user walked in front of a pole, the signal faded briefly, they dropped a packet and are perfectly fine now. So in that context, tcp/ip behaves as if it is seeing congestion when it is really seeing a momentary loss of connectivity that comes right back as soon as the end node moves 5 feet to the left. The right answer there might be ubiquitous support of ECN and treating packet loss in the absence of ECN as a connectivity issue and not a congestion issue but we are a long way from proper ECN support. I will have another look at the site, it has been a while since I was there last. George From jra at baylink.com Mon Apr 4 21:48:11 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 4 Apr 2011 22:48:11 -0400 (EDT) Subject: IPv4 Address Exhaustion Effects on the Earth In-Reply-To: <4D9A2A80.2060903@freedesktop.org> Message-ID: <3385331.1817.1301971691957.JavaMail.root@benjamin.baylink.com> > Note that the paper "Characterizing Residential Broadband Networks" by > Dischinger, et. al. indicates that a large fraction (in their 2 year > old > sample, 30% or so) of broadband head ends are running without RED, and > should be doing so if at all possible; alternatives are years out by > the > time they are tested and deployed, and operators running without it in > congested systems are inflicting pain on their customers. So, who's your contact at Google for KCK? Cheers, -- jra From jg at freedesktop.org Tue Apr 5 06:00:17 2011 From: jg at freedesktop.org (Jim Gettys) Date: Tue, 05 Apr 2011 07:00:17 -0400 Subject: IPv4 Address Exhaustion Effects on the Earth In-Reply-To: <3385331.1817.1301971691957.JavaMail.root@benjamin.baylink.com> References: <3385331.1817.1301971691957.JavaMail.root@benjamin.baylink.com> Message-ID: <4D9AF641.1000301@freedesktop.org> On 04/04/2011 10:48 PM, Jay Ashworth wrote: >> Note that the paper "Characterizing Residential Broadband Networks" by >> Dischinger, et. al. indicates that a large fraction (in their 2 year >> old >> sample, 30% or so) of broadband head ends are running without RED, and >> should be doing so if at all possible; alternatives are years out by >> the >> time they are tested and deployed, and operators running without it in >> congested systems are inflicting pain on their customers. > So, who's your contact at Google for KCK? > Vint ;-). - Jim From BECHA at ripe.net Tue Apr 5 06:52:24 2011 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 05 Apr 2011 13:52:24 +0200 Subject: IPV6 Training _links_ In-Reply-To: <690D7D20D2507C44BA8066926B2009890867FA@ES1002.ic-sa.com> References: <690D7D20D2507C44BA8066926B2009890867FA@ES1002.ic-sa.com> Message-ID: <4D9B0278.6030401@ripe.net> Hi Michael, On 4/4/11 9:43 PM, Michael Ruiz wrote: > Hello All, > > I am looking for some good reading material to get a better > understanding of IPV6. For "big picture", try http://ipv6actnow.org For technical details: http://getipv6.info > I know how to convert HEX into decimal > format. What I am looking for is how to under the CIDR notation and > break them out into subnets. Here's a short reference subnetting: http://www.ripe.net/lir-services/resource-management/ipv6/ipv6-subnetting-card & CIDR: http://www.ripe.net/images/cidr_working41.jpg (from this page: http://www.ripe.net/internet-coordination/press-centre/understanding-ip-addressing ) (if you want physical cards, we can send you some - please reply off-list) This can be useful, too: http://www.ripe.net/lir-services/resource-management/ipv6/ipv6-address-types Vesna Manojlovic RIPE NCC Trainer & Lecturer From shane at castlepoint.net Tue Apr 5 10:30:47 2011 From: shane at castlepoint.net (Shane Amante) Date: Tue, 5 Apr 2011 09:30:47 -0600 Subject: LAGing backbone links In-Reply-To: References: Message-ID: <96CD3DAF-2EB7-42A2-B3AD-32F1F41BB588@castlepoint.net> Payam, On Apr 4, 2011, at 18:17 MDT, Payam Chychi wrote: > Hello All, > > I was wondering if anyone had any thoughts as to the best practices of > running multiple backbone links between 2 routers. In the past we've added > additional links as needed, then simply enabled IS-IS when they were good to > go. I'd then let IS-IS handle load balancing the traffic over the two > links. But I know that others out there would setup a LAG once they had > more than one link between two routers. Is there a best practice? Does it > matter? Any implications to a MPLS setup? In general, if you're using relatively modern, medium- to higher-end equipment, it should "just work". Some things to watch out for in order of importance: 1) Be mindful of the number of component-links you can put into a single LAG. This varies by platform. In general, for higher-end routers/switches the minimum number of component-links in a single LAG is 16. More recently, in the last couple of years, several vendors are shipping equipment and/or software that will take this up to 64x component-links in a single LAG. (Depending on platform, LAG's may allow you to build larger virtual-links between adjacent devices compared to ECMP which may be limited to 8x component-links in a single ECMP ... but, again, that all depends on the platform type). 2) The distribution of flows across the component-links in a single LAG could vary, dramatically, depending on the type of traffic you're pushing. Specifically, for /Internet/ (IPv4 or IPv6) over MPLS traffic, you will most likely very get good load distribution given the pseudo-randomness of IP addresses and Layer-4 port information, (in particular source port's from a client toward a server). OTOH, if you have traffic in [very large] PW's, then typically LSR's/switches/routers can't look past the MPLS labels and inner Layer-2 encapsulation to find granular input keys used for the load-balancing hash. Thus, the load-balancing hash result will cause all traffic for a single PW VC to non-deterministically be placed on a single component-link in the LAG. The good news is that there is hope on the horizon in the form of: http://tools.ietf.org/html/draft-ietf-pwe3-fat-pw-05 ... which, in short, expects the ingress PE to [try to] find granular input keys from the incoming traffic, (e.g.: find input keys from an IP header contained within an Ethernet frame that will be transported as a PW VC over your MPLS core), and create a hash of that that will get placed into a "FAT PW" label that sits below the PW VC label. The idea is that Core LSR's would still load-balance based on the bottom-most to top-most MPLS labels, which should result in more even load-distribution of PW VC flows over component-links in a LAG. This feature is just starting to appear in one vendor's equipment and will hopefully show up in others soon, as well. (Please bug your vendors for this! ;-) 3) Depending on the vendor, you may specifically have to configure the device to do load-balancing over LAG's or ECMP paths, (e.g.: Juniper & Brocade, possibly others). Generally, you have to configure the device what input keys to look for and/or what # of MPLS labels to look past for those input-keys, e.g.: in Juniper you configure forwarding-options -> hash-key -> family mpls -> labels-1, label-2, payload -> ip, etc. Some other things to look out for: 4) Some vendor's may use different hash algorithms for LAG vs. ECMP, so you may get "better" load-balancing from one compared to the other. Ask your vendor for details as this may not be obvious from Lab testing. 5) Some vendors may have a limit, of the maximum number of MPLS labels that they can look past to find, say, an IP payload that can be used as input-keys for the load hashing algorithm. This used to be a concern several years ago, but in general most medium- to high-end equipment can look past /at least/ 3 MPLS labels, which should cover you in the more common cases where either: a) You have IP/LDP/RSVP/RSVP-FRR, where the outermost label is a RSVP Bypass Label when you're [briefly] running on a Bypass; or, b) You have VPN-label/LDP/RSVP, where you're moving IPVPN or 6PE, etc. traffic and using LDP over RSVP tunneling. Anyway, HTH, -shane From boards1_88 at yahoo.com Tue Apr 5 10:54:29 2011 From: boards1_88 at yahoo.com (Jason Pope) Date: Tue, 5 Apr 2011 08:54:29 -0700 (PDT) Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? Message-ID: <719963.71974.qm@web110112.mail.gq1.yahoo.com> All, WRT the below route object, DataBank does announce IP space for Hoechst Celanese Corporation as they are a direct customer of ours: > $ whois -h whois.radb.net 148.163.0.0 > route: 148.163.0.0/16 > descr: /16 for Celanese > origin: AS13767 > mnt-by: DBANK-MNT > changed: jpope at databank.com 20090818 > source: LEVEL3 > Currently, we only announce/originate the following prefixes via BGP: 148.163.178.0/24 148.163.179.0/24 via our providers, Level3 and Sprint. We asked our providers to relax their filters for the whole /16, since Celanese owns that IP space. That may or may not be a good idea, depending on your view of network management. We did this in case our customer needed to announce new networks which would save us the time/work of placing more/new route objects in the registry. We have the appropriate LOA for this network which is validated through face-to-face meetings with their network engineers and representatives. DataBank is very sensitive to network abuse; we have an AUP in place with all of our customers and will always work hard to enforce it to prevent network abuse. I apologize that I didn't respond sooner, but I have gotten behind on my NANOG reading. Thank you, Jason Pope DataBank Holdings 214.720.2266 office From drew.weaver at thenap.com Tue Apr 5 11:57:59 2011 From: drew.weaver at thenap.com (Drew Weaver) Date: Tue, 5 Apr 2011 12:57:59 -0400 Subject: Dark Fiber or Wavelength providers whom serve central Ohio Message-ID: Has anyone had any luck finding carriers who provide Dark Fiber and/or Wavelength services (10G+) around Columbus, OH? Currently I am looking for a 10G wave from Columbus to Ashburn, VA and I am having some trouble getting it done. If anyone has any suggestions please hit me off-list. Thanks, -Drew From jblaum02 at gmail.com Tue Apr 5 13:33:04 2011 From: jblaum02 at gmail.com (Jeff Blaum) Date: Tue, 5 Apr 2011 11:33:04 -0700 Subject: Alternatives to GSLB ? Message-ID: Greetings, my company has application servers in several strategic locations throughout the globe. We're currently doing GSLB with a handful of BIND DNS servers, that return the A records of the closest server(s), based off of the IP address of the resolver doing the lookup for the client. GSLB obviously has caveats in this regard, and we are looking for ideas on how to 1) ensure clients are routed to the closest geographical server 2) ensure the client hits the server(s) with the shortest path. Any feedback would be appreciated. Thanks! Jeff From nick at foobar.org Tue Apr 5 14:05:59 2011 From: nick at foobar.org (Nick Hilliard) Date: Tue, 05 Apr 2011 20:05:59 +0100 Subject: LAGing backbone links In-Reply-To: <96CD3DAF-2EB7-42A2-B3AD-32F1F41BB588@castlepoint.net> References: <96CD3DAF-2EB7-42A2-B3AD-32F1F41BB588@castlepoint.net> Message-ID: <4D9B6817.6060708@foobar.org> On 05/04/2011 16:30, Shane Amante wrote: > 1) Be mindful of the number of component-links you can put into a > single LAG. This varies by platform. In general, for higher-end > routers/switches the minimum number of component-links in a single > LAG is 16. Some older equipment will unequally prefer certain links over others, depending on the number of members in the LAG. I.e. a 2-member LAG might load balance equally under ideal conditions, but a 3-member LAG might naturally load balance 2:2:1. This is particularly a problem if you have, say an 8-member LAG and you lose a single member, which could drop your overall throughput to the total of 4 members. Nick From jack at crepinc.com Tue Apr 5 14:17:29 2011 From: jack at crepinc.com (Jack Carrozzo) Date: Tue, 5 Apr 2011 15:17:29 -0400 Subject: Alternatives to GSLB ? In-Reply-To: References: Message-ID: Anycast works. [...] we are looking for ideas on > how to 1) ensure clients are routed to the closest geographical server 2) > ensure the client hits the server(s) with the shortest path. > No need to deal with that yourself when BGP eats that problem for breakfast lunch and dinner. -Jack Carrozzo From lists at mtin.net Tue Apr 5 14:51:48 2011 From: lists at mtin.net (Justin Wilson) Date: Tue, 05 Apr 2011 15:51:48 -0400 Subject: IPV6 Training _links_ In-Reply-To: <4D9B0278.6030401@ripe.net> Message-ID: I believe Butch Evans & Scott Reed are doing some training coming up soon. Maybe if they are on this list they can comment. -- Justin Wilson Aol & Yahoo IM: j2sw http://www.mtin.net/blog ? xISP News http://www.twitter.com/j2sw ? Follow me on Twitter Wisp Consulting ? Tower Climbing ? Network Support On 4/5/11 7:52 AM, "Vesna Manojlovic" wrote: >Hi Michael, > >On 4/4/11 9:43 PM, Michael Ruiz wrote: >> Hello All, >> >> I am looking for some good reading material to get a better >> understanding of IPV6. > >For "big picture", try http://ipv6actnow.org >For technical details: http://getipv6.info > >> I know how to convert HEX into decimal >> format. What I am looking for is how to under the CIDR notation and >> break them out into subnets. > >Here's a short reference subnetting: >http://www.ripe.net/lir-services/resource-management/ipv6/ipv6-subnetting- >card > >& CIDR: >http://www.ripe.net/images/cidr_working41.jpg >(from this page: >http://www.ripe.net/internet-coordination/press-centre/understanding-ip-ad >dressing >) > >(if you want physical cards, we can send you some - please reply off-list) > >This can be useful, too: >http://www.ripe.net/lir-services/resource-management/ipv6/ipv6-address-typ >es > >Vesna Manojlovic >RIPE NCC Trainer & Lecturer > From mpetach at netflight.com Tue Apr 5 15:01:54 2011 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 5 Apr 2011 13:01:54 -0700 Subject: Alternatives to GSLB ? In-Reply-To: References: Message-ID: On Tue, Apr 5, 2011 at 12:17 PM, Jack Carrozzo wrote: > Anycast works. > ...with some caveats. > [...] we are looking for ideas on >> how to 1) ensure clients are routed to the closest geographical server 2) >> ensure the client hits the server(s) with the shortest path. >> > > No need to deal with that yourself when BGP eats that problem for breakfast > lunch and dinner. > > -Jack Carrozzo Note that anycast can and will bite you in the ass repeatedly as you deploy it over wider and wider scopes, unless you take careful steps to overcome the differences in policies and coverage areas with different networks. Classic problem: You peer with network X in the US. You buy transit from network Y in Asia. Network Y buys transit from network X in the US. Network X localprefers customer routes over peer routes. Your anycast traffic from network X in the US is suddenly being served from your Asia nodes behind network Y, because network X prefers the path to your anycast subnet heard through their customer instead of the peer-learned path directly from you. Not saying it won't work; it just takes careful planning, judicious use of BGP communities to limit route propagation, and constant monitoring and adjusting as networks change who they purchase connectivity from over time. Matt From george.herbert at gmail.com Tue Apr 5 15:12:18 2011 From: george.herbert at gmail.com (George Herbert) Date: Tue, 5 Apr 2011 13:12:18 -0700 Subject: Alternatives to GSLB ? In-Reply-To: References: Message-ID: On Tue, Apr 5, 2011 at 1:01 PM, Matthew Petach wrote: > On Tue, Apr 5, 2011 at 12:17 PM, Jack Carrozzo wrote: >> Anycast works. >> > > ...with some caveats. > >> [...] we are looking for ideas on >>> how to 1) ensure clients are routed to the closest geographical server 2) >>> ensure the client hits the server(s) with the shortest path. >>> >> >> No need to deal with that yourself when BGP eats that problem for breakfast >> lunch and dinner. >> >> -Jack Carrozzo > > Note that anycast can and will bite you in the ass > repeatedly as you deploy it over wider and wider > scopes, unless you take careful steps to overcome > the differences in policies and coverage areas with > different networks. > > Classic problem: > > You peer with network X in the US. > You buy transit from network Y in Asia. > Network Y buys transit from network X in the US. > > Network X localprefers customer routes over peer routes. > > Your anycast traffic from network X in the US is > suddenly being served from your Asia nodes behind > network Y, because network X prefers the path to your > anycast subnet heard through their customer instead > of the peer-learned path directly from you. > > Not saying it won't work; it just takes careful planning, > judicious use of BGP communities to limit route > propagation, and constant monitoring and adjusting > as networks change who they purchase connectivity > from over time. > > Matt I've seen that with clients. It seems like there's a promised anycast land, out where Akamai is (where you really do have "local" nearly everywhere globally, so even strange routing foo doesn't mismatch the path too badly). Between small GSLB optimal solutions and the promised land, there be dragons, due to the actual one-way routing dynamics. I noodled for a while on a mixed anycast-local solution for a particularly insane client website requirement (never got built, thank god), with each installation answering both a local GSLB-like address and the anycast. Had a layer of smart in front of the anycast load balancer ports to see if routing had done something insane, and to generate a redirect to the local address closest to the point of origin. Never got code working, and talked the client out of the business requirement, but it might be more practical than moderately complex anycast's actual practical management problems. -- -george william herbert george.herbert at gmail.com From jared at puck.nether.net Tue Apr 5 16:38:22 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 5 Apr 2011 17:38:22 -0400 Subject: IPv4 Address Exhaustion Effects on the Earth In-Reply-To: <4D9A2A80.2060903@freedesktop.org> References: <5A6D953473350C4B9995546AFE9939EE0C9E2BAE@RWC-EX1.corp.seven.com> <4D98C224.1090906@freedesktop.org> <5A6D953473350C4B9995546AFE9939EE0C9E2BDA@RWC-EX1.corp.seven.com> <4D9A2A80.2060903@freedesktop.org> Message-ID: <4E3AB9A4-9C60-40BA-B6D2-28DD0CD48557@puck.nether.net> On Apr 4, 2011, at 4:30 PM, Jim Gettys wrote: > Note that the paper "Characterizing Residential Broadband Networks" by Dischinger, et. al. indicates that a large fraction (in their 2 year old sample, 30% or so) of broadband head ends are running without RED, and should be doing so if at all possible; alternatives are years out by the time they are tested and deployed, and operators running without it in congested systems are inflicting pain on their customers. Something I've observed is if you are sending data 'upstream' on the cable modem setup i have (16 down/ 2 up) and you saturate the upstream, the buffering destroys any downstream capability at the same time. I'm not even sure where to start diagnosing to explaining this to the carrier involved, as this isn't the desired behavior of a "business class" service. - Jared From patrick at ianai.net Tue Apr 5 16:54:43 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 5 Apr 2011 17:54:43 -0400 Subject: Alternatives to GSLB ? In-Reply-To: References: Message-ID: On Apr 5, 2011, at 4:12 PM, George Herbert wrote: > I've seen that with clients. It seems like there's a promised anycast > land, out where Akamai is (where you really do have "local" nearly > everywhere globally, so even strange routing foo doesn't mismatch the > path too badly). No Akamai traffic is directed via anycast. Some of the name server IP addresses are anycasted, but that is for redundancy / capacity / name resolution performance, not to direct end users to web servers. -- TTFN, patrick From mike at jellydonut.org Tue Apr 5 16:59:31 2011 From: mike at jellydonut.org (Michael Proto) Date: Tue, 5 Apr 2011 17:59:31 -0400 Subject: IPv4 Address Exhaustion Effects on the Earth In-Reply-To: <4E3AB9A4-9C60-40BA-B6D2-28DD0CD48557@puck.nether.net> References: <5A6D953473350C4B9995546AFE9939EE0C9E2BAE@RWC-EX1.corp.seven.com> <4D98C224.1090906@freedesktop.org> <5A6D953473350C4B9995546AFE9939EE0C9E2BDA@RWC-EX1.corp.seven.com> <4D9A2A80.2060903@freedesktop.org> <4E3AB9A4-9C60-40BA-B6D2-28DD0CD48557@puck.nether.net> Message-ID: On Tue, Apr 5, 2011 at 5:38 PM, Jared Mauch wrote: > > On Apr 4, 2011, at 4:30 PM, Jim Gettys wrote: > >> Note that the paper "Characterizing Residential Broadband Networks" by Dischinger, et. al. indicates that a large fraction (in their 2 year old sample, 30% or so) of broadband head ends are running without RED, and should be doing so if at all possible; alternatives are years out by the time they are tested and deployed, and operators running without it in congested systems are inflicting pain on their customers. > > Something I've observed is if you are sending data 'upstream' on the cable modem setup i have (16 down/ 2 up) and you saturate the upstream, the buffering destroys any downstream capability at the same time. ?I'm not even sure where to start diagnosing to explaining this to the carrier involved, as this isn't the desired behavior of a "business class" service. > > - Jared > Isn't this just a case or prioritizing outbound ACKs? http://www.benzedrine.cx/ackpri.html -Proto From jg at freedesktop.org Tue Apr 5 17:07:21 2011 From: jg at freedesktop.org (Jim Gettys) Date: Tue, 05 Apr 2011 18:07:21 -0400 Subject: IPv4 Address Exhaustion Effects on the Earth In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0C9E2BAE@RWC-EX1.corp.seven.com> <4D98C224.1090906@freedesktop.org> <5A6D953473350C4B9995546AFE9939EE0C9E2BDA@RWC-EX1.corp.seven.com> <4D9A2A80.2060903@freedesktop.org> <4E3AB9A4-9C60-40BA-B6D2-28DD0CD48557@puck.nether.net> Message-ID: <4D9B9299.4080808@freedesktop.org> On 04/05/2011 05:59 PM, Michael Proto wrote: > On Tue, Apr 5, 2011 at 5:38 PM, Jared Mauch wrote: >> On Apr 4, 2011, at 4:30 PM, Jim Gettys wrote: >> >>> Note that the paper "Characterizing Residential Broadband Networks" by Dischinger, et. al. indicates that a large fraction (in their 2 year old sample, 30% or so) of broadband head ends are running without RED, and should be doing so if at all possible; alternatives are years out by the time they are tested and deployed, and operators running without it in congested systems are inflicting pain on their customers. >> Something I've observed is if you are sending data 'upstream' on the cable modem setup i have (16 down/ 2 up) and you saturate the upstream, the buffering destroys any downstream capability at the same time. I'm not even sure where to start diagnosing to explaining this to the carrier involved, as this isn't the desired behavior of a "business class" service. >> >> - Jared >> > Isn't this just a case or prioritizing outbound ACKs? > > http://www.benzedrine.cx/ackpri.html > Nope. Your acks get delayed to what you are sending upstream, behind the downstream traffic. Bufferbloat hurts both directions, once saturation occurs and your latencies start to go up. Note that on many of these links, the RTT becomes (literally) as though you are half way (or further than) the moon. - Jim From george.herbert at gmail.com Tue Apr 5 17:13:12 2011 From: george.herbert at gmail.com (George Herbert) Date: Tue, 5 Apr 2011 15:13:12 -0700 Subject: Alternatives to GSLB ? In-Reply-To: References: Message-ID: On Tue, Apr 5, 2011 at 2:54 PM, Patrick W. Gilmore wrote: > On Apr 5, 2011, at 4:12 PM, George Herbert wrote: > >> I've seen that with clients. ?It seems like there's a promised anycast >> land, out where Akamai is (where you really do have "local" nearly >> everywhere globally, so even strange routing foo doesn't mismatch the >> path too badly). > > No Akamai traffic is directed via anycast. > > Some of the name server IP addresses are anycasted, but that is for redundancy / capacity / name resolution performance, not to direct end users to web servers. Sorry, didn't mean to imply that. It was suggested in the dark past that Akamai could or should do that; they didn't. It was tangental to the point I was making and I simplified wrongly. -- -george william herbert george.herbert at gmail.com From jared at puck.nether.net Tue Apr 5 17:17:56 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 5 Apr 2011 18:17:56 -0400 Subject: IPv4 Address Exhaustion Effects on the Earth In-Reply-To: <4D9B9299.4080808@freedesktop.org> References: <5A6D953473350C4B9995546AFE9939EE0C9E2BAE@RWC-EX1.corp.seven.com> <4D98C224.1090906@freedesktop.org> <5A6D953473350C4B9995546AFE9939EE0C9E2BDA@RWC-EX1.corp.seven.com> <4D9A2A80.2060903@freedesktop.org> <4E3AB9A4-9C60-40BA-B6D2-28DD0CD48557@puck.nether.net> <4D9B9299.4080808@freedesktop.org> Message-ID: <5F5B1760-1763-4F0F-99D0-E258F2886FF7@puck.nether.net> On Apr 5, 2011, at 6:07 PM, Jim Gettys wrote: > On 04/05/2011 05:59 PM, Michael Proto wrote: >> On Tue, Apr 5, 2011 at 5:38 PM, Jared Mauch wrote: >>> On Apr 4, 2011, at 4:30 PM, Jim Gettys wrote: >>> >>>> Note that the paper "Characterizing Residential Broadband Networks" by Dischinger, et. al. indicates that a large fraction (in their 2 year old sample, 30% or so) of broadband head ends are running without RED, and should be doing so if at all possible; alternatives are years out by the time they are tested and deployed, and operators running without it in congested systems are inflicting pain on their customers. >>> Something I've observed is if you are sending data 'upstream' on the cable modem setup i have (16 down/ 2 up) and you saturate the upstream, the buffering destroys any downstream capability at the same time. I'm not even sure where to start diagnosing to explaining this to the carrier involved, as this isn't the desired behavior of a "business class" service. >>> >>> - Jared >>> >> Isn't this just a case or prioritizing outbound ACKs? >> >> http://www.benzedrine.cx/ackpri.html >> > > Nope. Your acks get delayed to what you are sending upstream, behind the downstream traffic. > > Bufferbloat hurts both directions, once saturation occurs and your latencies start to go up. > > Note that on many of these links, the RTT becomes (literally) as though you are half way (or further than) the moon. > I sent a private reply, but I guess i'll post some of it here: 1) there are no ways to identify the devices doing the buffering and/or drop counts 2) I can obviously feed the cable modem much faster on the lan vs what it can send upstream Doing things like rate-limiting/QoS are merely just papering over the problem. I would take a T1 and rate-limit it to 1.2Mb/s for TCP to allow VoIP to work. Junipers can buffer up to 1 second on these low-speed interfaces, which obviously creates the problems you describe. There are a lot more problems with the gateway devices, such as the forcible dns proxy that exists. - Jared From trelane at trelane.net Tue Apr 5 18:21:47 2011 From: trelane at trelane.net (Andrew Kirch) Date: Tue, 05 Apr 2011 19:21:47 -0400 Subject: twitter is serving up errors Message-ID: <4D9BA40B.4080702@trelane.net> expect nothing of technical relevance in this thread, but as this might generate some phonecalls to some people. From jna at retina.net Tue Apr 5 18:23:34 2011 From: jna at retina.net (John Adams) Date: Tue, 5 Apr 2011 16:23:34 -0700 Subject: twitter is serving up errors In-Reply-To: <4D9BA40B.4080702@trelane.net> References: <4D9BA40B.4080702@trelane.net> Message-ID: On Tue, Apr 5, 2011 at 4:21 PM, Andrew Kirch wrote: > expect nothing of technical relevance in this thread, but as this might > generate some phonecalls to some people. > > Known issue, we're on it. This is not a nanog issue. fwiw. -- John Adams Twitter From jra at baylink.com Tue Apr 5 22:43:33 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 5 Apr 2011 23:43:33 -0400 (EDT) Subject: twitter is serving up errors In-Reply-To: Message-ID: <20997215.1905.1302061413497.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Adams" > On Tue, Apr 5, 2011 at 4:21 PM, Andrew Kirch > wrote: > > expect nothing of technical relevance in this thread, but as this > > might generate some phonecalls to some people. > > > Known issue, we're on it. This is not a nanog issue. fwiw. No; it's probably better suited to outages at outages.org. What, you mean you're not subscribed to that? Cheers, -- jr 'Hell, we're RFC 2549 compliant and everything' a From standalone.sysadmin at gmail.com Wed Apr 6 06:54:05 2011 From: standalone.sysadmin at gmail.com (Matt Simmons) Date: Wed, 6 Apr 2011 07:54:05 -0400 Subject: PICC'11 NJ SysAdmin Conf - Early Bird Savings Extended! Message-ID: Hello, I'm Matt Simmons, the PICC'11 (http://www.picconf.org) Conference chair, and I wanted to give you some exciting news about our community conference. First, if you haven't checked out our schedule, you should: http://bit.ly/PICC11-overview - We've got classes on Documentation, Python, Perl, Powershell, IPv6, and much much more. The opening keynote will be presented by Theo Schlossnagle from OmniTI. Second, because this is short notice, we're extending the $125 early-bird savings for one week, until Tuesday, April 12th. This discount, which is taken off immediately when you register, more than saves you the price of the hotel room. You definitely want to book now. If you need to talk to your boss to get this approved, we've even got a letter to help: http://bit.ly/PICC11-justification Also, don't worry about getting to the conference. We're located in the Hyatt Regency, New Brunswick, which is within easy walking distance from the AmTrak station, which is also serviced by NJ-Transit. We're simple to get to. We really want you to come to the conference. We think you'll have a great time, we know you'll be surrounded with people you can learn from, and if last year's is any indication, it's going to be a blast. You can get to our registration page here: http://bit.ly/PICC11-reg Again, I'm the chair of the conference, so if you have any questions, just click reply and let me know. I'm happy to answer any questions at all. Thanks for your time, and I'll see you at PICC'11! --Matt -- LITTLE GIRL: But which cookie will you eat FIRST? COOKIE MONSTER: Me think you have misconception of cookie-eating process. From martin at airwire.ie Wed Apr 6 13:30:39 2011 From: martin at airwire.ie (Martin List-Petersen) Date: Wed, 06 Apr 2011 19:30:39 +0100 Subject: twitter is serving up errors In-Reply-To: <20997215.1905.1302061413497.JavaMail.root@benjamin.baylink.com> References: <20997215.1905.1302061413497.JavaMail.root@benjamin.baylink.com> Message-ID: <4D9CB14F.2040407@airwire.ie> On 06/04/11 04:43, Jay Ashworth wrote: > ----- Original Message ----- >> From: "John Adams" > >> On Tue, Apr 5, 2011 at 4:21 PM, Andrew Kirch >> wrote: >>> expect nothing of technical relevance in this thread, but as this >>> might generate some phonecalls to some people. >>> >> Known issue, we're on it. This is not a nanog issue. fwiw. > > No; it's probably better suited to outages at outages.org. > > What, you mean you're not subscribed to that? > Ah well, you'd better have a LOT of storage space for your mailbox, if you subscribe to that :) Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From mwoliver at gmail.com Wed Apr 6 13:44:27 2011 From: mwoliver at gmail.com (Mike Oliver) Date: Wed, 6 Apr 2011 14:44:27 -0400 Subject: IPV6 Training _links_ In-Reply-To: <4D9B0278.6030401@ripe.net> References: <690D7D20D2507C44BA8066926B2009890867FA@ES1002.ic-sa.com> <4D9B0278.6030401@ripe.net> Message-ID: On Tue, Apr 5, 2011 at 07:52, Vesna Manojlovic wrote: > Hi Michael, > > ... > > Here's a short reference subnetting: > http://www.ripe.net/lir-services/resource-management/ipv6/ipv6-subnetting-card Perhaps these can also be useful: http://testmyipv6.com/ipv6_subnet_calc.html http://v6.testmyipv6.com/ipv6_prefixes.html (IPv6 only, bonus for those who can get to it) -- Mike Oliver, KT2T +1-863-738-2334 kt2t at arrl.net -or- mwoliver at gmail.com Twitter: @mwoliver From Valdis.Kletnieks at vt.edu Wed Apr 6 13:46:36 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 06 Apr 2011 14:46:36 -0400 Subject: twitter is serving up errors In-Reply-To: Your message of "Wed, 06 Apr 2011 19:30:39 BST." <4D9CB14F.2040407@airwire.ie> References: <20997215.1905.1302061413497.JavaMail.root@benjamin.baylink.com> <4D9CB14F.2040407@airwire.ie> Message-ID: <13913.1302115596@localhost> On Wed, 06 Apr 2011 19:30:39 BST, Martin List-Petersen said: > Ah well, you'd better have a LOT of storage space for your mailbox, if > you subscribe to that :) Odd. I get more traffic on NANOG than on Outages. Now if you want a firehose list, go read linux-kernel. *that* will chew some storage at 400+ postings a day. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dr at cluenet.de Wed Apr 6 17:17:01 2011 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 7 Apr 2011 00:17:01 +0200 Subject: LAGing backbone links In-Reply-To: <4D9B6817.6060708@foobar.org> References: <96CD3DAF-2EB7-42A2-B3AD-32F1F41BB588@castlepoint.net> <4D9B6817.6060708@foobar.org> Message-ID: <20110406221701.GA14747@srv03.cluenet.de> On Tue, Apr 05, 2011 at 08:05:59PM +0100, Nick Hilliard wrote: > Some older equipment will unequally prefer certain links over others, > depending on the number of members in the LAG. I.e. a 2-member LAG might > load balance equally under ideal conditions, but a 3-member LAG might > naturally load balance 2:2:1. Even newer gear does that. TurboIron 24X for example. Some Force10 switch model(s) as well, no clue how old though. LAGs have one big advantage over ECMP: with gear implementing "minimum-links" feature, you can make sure your LAG bandwidth doesn't fall below a certain capacity before being removed from IGP topology so you can make sure redundant (full!) capacity elsewhere can automatically kick in. With ECMP traffic engineering and capacity/redundancy planning becomes... "interesting". Aside of all the operational problems regarding troubleshooting (traceroutes/mtr do love such ECMP hells) and operational consequences of having a lot of adjacencies and links. For all those reasons, I usually prefer LAGs (with LACP) above ECMP, even when that means "more bugs" (vendors tend to not properly test all their features on LAGs too). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jg at freedesktop.org Wed Apr 6 17:43:30 2011 From: jg at freedesktop.org (Jim Gettys) Date: Wed, 06 Apr 2011 18:43:30 -0400 Subject: IPv4 Address Exhaustion Effects on the Earth In-Reply-To: <5F5B1760-1763-4F0F-99D0-E258F2886FF7@puck.nether.net> References: <5A6D953473350C4B9995546AFE9939EE0C9E2BAE@RWC-EX1.corp.seven.com> <4D98C224.1090906@freedesktop.org> <5A6D953473350C4B9995546AFE9939EE0C9E2BDA@RWC-EX1.corp.seven.com> <4D9A2A80.2060903@freedesktop.org> <4E3AB9A4-9C60-40BA-B6D2-28DD0CD48557@puck.nether.net> <4D9B9299.4080808@freedesktop.org> <5F5B1760-1763-4F0F-99D0-E258F2886FF7@puck.nether.net> Message-ID: <4D9CEC92.4090006@freedesktop.org> On 04/05/2011 06:17 PM, Jared Mauch wrote: > On Apr 5, 2011, at 6:07 PM, Jim Gettys wrote: > >> On 04/05/2011 05:59 PM, Michael Proto wrote: >>> On Tue, Apr 5, 2011 at 5:38 PM, Jared Mauch wrote: >>>> On Apr 4, 2011, at 4:30 PM, Jim Gettys wrote: >>>> >>>>> Note that the paper "Characterizing Residential Broadband Networks" by Dischinger, et. al. indicates that a large fraction (in their 2 year old sample, 30% or so) of broadband head ends are running without RED, and should be doing so if at all possible; alternatives are years out by the time they are tested and deployed, and operators running without it in congested systems are inflicting pain on their customers. >>>> Something I've observed is if you are sending data 'upstream' on the cable modem setup i have (16 down/ 2 up) and you saturate the upstream, the buffering destroys any downstream capability at the same time. I'm not even sure where to start diagnosing to explaining this to the carrier involved, as this isn't the desired behavior of a "business class" service. >>>> >>>> - Jared >>>> >>> Isn't this just a case or prioritizing outbound ACKs? >>> >>> http://www.benzedrine.cx/ackpri.html >>> >> Nope. Your acks get delayed to what you are sending upstream, behind the downstream traffic. >> >> Bufferbloat hurts both directions, once saturation occurs and your latencies start to go up. >> >> Note that on many of these links, the RTT becomes (literally) as though you are half way (or further than) the moon. >> > I sent a private reply, but I guess i'll post some of it here: > > 1) there are no ways to identify the devices doing the buffering and/or drop counts This isn't really true: you basically do "ping" combined with "traceroute" while saturating a path. The hop where there is unexpected additional latency not present when the you don't saturate the path is the culprit. You can't easily figure out where inside a bottleneck the buffering is, unless you have some way to monitor or control the buffering inside it (e.g. twist the transmit queue or transmit rings in Linux, as an example). > 2) I can obviously feed the cable modem much faster on the lan vs what it can send upstream > > Doing things like rate-limiting/QoS are merely just papering over the problem. Papering over the problem isn't all bad, if it allows you to hide egregious size buffers in a bottleneck link over which you'd otherwise have no control. It allows me to take my latency/jitter on my home cable service from about 400ms down to 10ms (at some cost in bandwidth). This means I actually can have voip or other latency sensitive applications work (so long as I ensure that the broadband link is the bottleneck; if you home wireless network's effective bandwidth drops below that of your broadband, then the bottleneck becomes the 802.11 hop, and you'll see queues in your host and home router, rather than in the broadband hop. Notice that this means with symmetric 25/25 FIOS service, you get bufferbloat in your host and wireless router, as I did (actual data transfer rates of 802.11g is only about 20Mbps, not the 54 signalling rate marketed). > I would take a T1 and rate-limit it to 1.2Mb/s for TCP to allow VoIP to work. Junipers can buffer up to 1 second on these low-speed interfaces, which obviously creates the problems you describe. Bufferbloat is (nearly) everywhere. You'd better see if you can run RED or some AQM. The issues with RED revolve around the fact that it is a flawed algorithm that requires proper tuning to be effective, and it can't handle situations such as wireless or broadband with time variable behaviour such as Comcast's Powerboost. It is exactly the fact that RED requires tuning that means that it is often not enabled when it should be: but it is often the only tool we've got right now. > There are a lot more problems with the gateway devices, such as the forcible dns proxy that exists. > Right now, the home router market is a cesspool of scum and villainy. Our best hope is the rebel alliance; I think we'll get OpenWRT straightened out long before the commercial vendors do. - Jim From ops.lists at gmail.com Wed Apr 6 21:05:24 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 7 Apr 2011 07:35:24 +0530 Subject: Bubba is a 75 year old woman looking to make some extra cash Message-ID: http://www.guardian.co.uk/world/2011/apr/06/georgian-woman-cuts-web-access -- Suresh Ramasubramanian (ops.lists at gmail.com) From rmacharia at gmail.com Wed Apr 6 22:04:10 2011 From: rmacharia at gmail.com (Raymond Macharia) Date: Thu, 7 Apr 2011 06:04:10 +0300 Subject: Bubba is a 75 year old woman looking to make some extra cash Message-ID: Back hoes, tsunamis, earth quakes, ship anchors and now 75 year old women with spades. Moral of the story....have another cable and not next to the one that the old lady will get to. It's interesting that the article indicates that the cable is heavily protected but apparently not from "spade hackers" Raymond Macharia On 7 Apr 2011 05:05, "Suresh Ramasubramanian" wrote: From nick at foobar.org Thu Apr 7 01:45:20 2011 From: nick at foobar.org (Nick Hilliard) Date: Thu, 7 Apr 2011 07:45:20 +0100 Subject: LAGing backbone links In-Reply-To: <20110406221701.GA14747@srv03.cluenet.de> References: <96CD3DAF-2EB7-42A2-B3AD-32F1F41BB588@castlepoint.net> <4D9B6817.6060708@foobar.org> <20110406221701.GA14747@srv03.cluenet.de> Message-ID: On 6 Apr 2011, at 23:17, Daniel Roesen wrote: > On Tue, Apr 05, 2011 at 08:05:59PM +0100, Nick Hilliard wrote: >> Some older equipment will unequally prefer certain links over others, >> depending on the number of members in the LAG. I.e. a 2-member LAG might >> load balance equally under ideal conditions, but a 3-member LAG might >> naturally load balance 2:2:1. > > Even newer gear does that. TurboIron 24X for example. I believe this has been fixed on s/w version 4.2.00 on the turboiron, and that it can now support arbitrary numbers of lag members. Haven't tested it though... Nick From vikassharmas at gmail.com Thu Apr 7 03:18:33 2011 From: vikassharmas at gmail.com (Vikas Sharma) Date: Thu, 7 Apr 2011 13:48:33 +0530 Subject: link-local address calculation Message-ID: Hi, How to get link-local address from BIA. I have seen some information on Internet but it is not working for all. ============= The BIA in this case is cc00.0bfc.0000. The rules for the modified EUI-64 addressing are: ?FFFE will be put in between the vendor-id (3 most significant bytes) and the extension-id (3 least significant bytes), which will lead to cc00.0bFF.FEfc.0000 ?Thereafter the seventh bit, known as universal/local bit, gets inverted. So first change the cc00 from hex to binary, which leads to 110011 0 000000000 and then invert the seventh bit (here a 0): 110011 1 000000000. Moved back to hex this will give CE00 ?At last, change all points ?.? to colons ?:? and delete all leading zeros, then you got your link-local IPv6 address: FE80::CE00:BFF:FEFC:0 ============ So if your BIA is 0008.209a.081b (bia 0008.209a.081b), how link-local be calculated. This is the link-local on router => IPv6 is enabled, link-local address is FE80::208:20FF:FE9A:81B Also on XR below is the link local address Loopback6 is Up, ipv6 protocol is Up, Vrfid is default (0x60000000) IPv6 is enabled, link-local address is fe80::884c:2dff:fe84:8d75 I can not see any interface with BIA ending with 75 ... Can someone explain me this? Regards, Vikas From dr at cluenet.de Thu Apr 7 03:49:23 2011 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 7 Apr 2011 10:49:23 +0200 Subject: LAGing backbone links In-Reply-To: References: <96CD3DAF-2EB7-42A2-B3AD-32F1F41BB588@castlepoint.net> <4D9B6817.6060708@foobar.org> <20110406221701.GA14747@srv03.cluenet.de> Message-ID: <20110407084923.GA26868@srv03.cluenet.de> On Thu, Apr 07, 2011 at 07:45:20AM +0100, Nick Hilliard wrote: > >> I.e. a 2-member LAG might load balance equally under ideal conditions, > >> but a 3-member LAG might naturally load balance 2:2:1. > > > > Even newer gear does that. TurboIron 24X for example. > > I believe this has been fixed on s/w version 4.2.00 on the turboiron, Interesting, as Fou^WBrocade's statement was that this is unfixable due to a chipset (which is Broadcom) limitation. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dstickney at optilian.com Thu Apr 7 04:27:01 2011 From: dstickney at optilian.com (Daniel STICKNEY) Date: Thu, 07 Apr 2011 11:27:01 +0200 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites Message-ID: <4D9D8365.9060202@optilian.com> Hello all, I'm investigating how to setup multihoming for IPv6 over two DSL lines (different ISPs), and I wanted to see if this wheel has already been invented. Has anyone already set this up or tested it ? In my research into the proposed solutions I came across this document "IEEE Communications Surveys - 2nd Quarter 2006, Volume 8, No. 2" (http://www.shim6.org/path-to-mh.pdf) which seems quite thorough. It compares routing methods, middle-box methods, and host-centric methods. It mentions "During the last years, the IETF has made several explicit or implicit architectural decisions regarding IPv6 multihoming. The main decision is to go down the path of developing the host-centric approaches" as well as "Host-centric multihoming, the approach promoted by the IETF for IPv6 multihoming, [...]". After the comparison of all host-centric methods it adds " [...], the IETF has decided by the end of 2004 to foster the SHIM approach." This approach looks interesting to me after all the comparisons, though I'm less familiar with it. I'm interested to hear your real-world experiences on this topic. Thanks, Daniel From isabeldias1 at yahoo.com Thu Apr 7 04:54:21 2011 From: isabeldias1 at yahoo.com (isabel dias) Date: Thu, 7 Apr 2011 02:54:21 -0700 (PDT) Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <4D9D8365.9060202@optilian.com> References: <4D9D8365.9060202@optilian.com> Message-ID: <84612.96416.qm@web121620.mail.ne1.yahoo.com> why would you do that for? ----- Original Message ---- From: Daniel STICKNEY To: nanog at nanog.org Sent: Thu, April 7, 2011 10:27:01 AM Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites Hello all, I'm investigating how to setup multihoming for IPv6 over two DSL lines (different ISPs), and I wanted to see if this wheel has already been invented. Has anyone already set this up or tested it ? In my research into the proposed solutions I came across this document "IEEE Communications Surveys - 2nd Quarter 2006, Volume 8, No. 2" (http://www.shim6.org/path-to-mh.pdf) which seems quite thorough. It compares routing methods, middle-box methods, and host-centric methods. It mentions "During the last years, the IETF has made several explicit or implicit architectural decisions regarding IPv6 multihoming. The main decision is to go down the path of developing the host-centric approaches" as well as "Host-centric multihoming, the approach promoted by the IETF for IPv6 multihoming, [...]". After the comparison of all host-centric methods it adds " [...], the IETF has decided by the end of 2004 to foster the SHIM approach." This approach looks interesting to me after all the comparisons, though I'm less familiar with it. I'm interested to hear your real-world experiences on this topic. Thanks, Daniel From nick at foobar.org Thu Apr 7 04:56:16 2011 From: nick at foobar.org (Nick Hilliard) Date: Thu, 07 Apr 2011 10:56:16 +0100 Subject: LAGing backbone links In-Reply-To: <20110407084923.GA26868@srv03.cluenet.de> References: <96CD3DAF-2EB7-42A2-B3AD-32F1F41BB588@castlepoint.net> <4D9B6817.6060708@foobar.org> <20110406221701.GA14747@srv03.cluenet.de> <20110407084923.GA26868@srv03.cluenet.de> Message-ID: <4D9D8A40.9060908@foobar.org> On 07/04/2011 09:49, Daniel Roesen wrote: > Interesting, as Fou^WBrocade's statement was that this is unfixable due > to a chipset (which is Broadcom) limitation. I asked them about this exact point, but my SE said it was a software restriction which was fixed as of 4.2. Nick From isabeldias1 at yahoo.com Thu Apr 7 04:57:29 2011 From: isabeldias1 at yahoo.com (isabel dias) Date: Thu, 7 Apr 2011 02:57:29 -0700 (PDT) Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <4D9D8365.9060202@optilian.com> References: <4D9D8365.9060202@optilian.com> Message-ID: <676627.48357.qm@web121602.mail.ne1.yahoo.com> how many ip addresses do you have ? ----- Original Message ---- From: Daniel STICKNEY To: nanog at nanog.org Sent: Thu, April 7, 2011 10:27:01 AM Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites Hello all, I'm investigating how to setup multihoming for IPv6 over two DSL lines (different ISPs), and I wanted to see if this wheel has already been invented. Has anyone already set this up or tested it ? In my research into the proposed solutions I came across this document "IEEE Communications Surveys - 2nd Quarter 2006, Volume 8, No. 2" (http://www.shim6.org/path-to-mh.pdf) which seems quite thorough. It compares routing methods, middle-box methods, and host-centric methods. It mentions "During the last years, the IETF has made several explicit or implicit architectural decisions regarding IPv6 multihoming. The main decision is to go down the path of developing the host-centric approaches" as well as "Host-centric multihoming, the approach promoted by the IETF for IPv6 multihoming, [...]". After the comparison of all host-centric methods it adds " [...], the IETF has decided by the end of 2004 to foster the SHIM approach." This approach looks interesting to me after all the comparisons, though I'm less familiar with it. I'm interested to hear your real-world experiences on this topic. Thanks, Daniel From isabeldias1 at yahoo.com Thu Apr 7 04:58:30 2011 From: isabeldias1 at yahoo.com (isabel dias) Date: Thu, 7 Apr 2011 02:58:30 -0700 (PDT) Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <4D9D8365.9060202@optilian.com> References: <4D9D8365.9060202@optilian.com> Message-ID: <897661.3824.qm@web121620.mail.ne1.yahoo.com> have you thought about taking a Cisco training course? ----- Original Message ---- From: Daniel STICKNEY To: nanog at nanog.org Sent: Thu, April 7, 2011 10:27:01 AM Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites Hello all, I'm investigating how to setup multihoming for IPv6 over two DSL lines (different ISPs), and I wanted to see if this wheel has already been invented. Has anyone already set this up or tested it ? In my research into the proposed solutions I came across this document "IEEE Communications Surveys - 2nd Quarter 2006, Volume 8, No. 2" (http://www.shim6.org/path-to-mh.pdf) which seems quite thorough. It compares routing methods, middle-box methods, and host-centric methods. It mentions "During the last years, the IETF has made several explicit or implicit architectural decisions regarding IPv6 multihoming. The main decision is to go down the path of developing the host-centric approaches" as well as "Host-centric multihoming, the approach promoted by the IETF for IPv6 multihoming, [...]". After the comparison of all host-centric methods it adds " [...], the IETF has decided by the end of 2004 to foster the SHIM approach." This approach looks interesting to me after all the comparisons, though I'm less familiar with it. I'm interested to hear your real-world experiences on this topic. Thanks, Daniel From owen at delong.com Thu Apr 7 07:48:50 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Apr 2011 05:48:50 -0700 Subject: link-local address calculation In-Reply-To: References: Message-ID: <7FA17DC7-E269-4925-B6B4-82DD09609C44@delong.com> On Apr 7, 2011, at 1:18 AM, Vikas Sharma wrote: > Hi, > > How to get link-local address from BIA. I have seen some information > on Internet but it is not working for all. > Pretty simple: Split the BIA into two 24 bit chunks: cc000b / fc0000 Then insert fffe in the middle: cc000b fffe fc0000 Now invert the 0x02 bit of the first octet: ce000b fffe fc0000 Prefix with fe80:: fe80::ce00:0bff:fefc:0000 Which if you shorten it becomes: fe80::ce00:bff:fefc:0 > ============= > The BIA in this case is cc00.0bfc.0000. The rules for the modified > EUI-64 addressing are: > > ?FFFE will be put in between the vendor-id (3 most significant bytes) > and the extension-id (3 least significant bytes), which will lead to > cc00.0bFF.FEfc.0000 > ?Thereafter the seventh bit, known as universal/local bit, gets > inverted. So first change the cc00 from hex to binary, which leads to > 110011 0 000000000 and then invert the seventh bit (here a 0): 110011 > 1 000000000. Moved back to hex this will give CE00 > ?At last, change all points ?.? to colons ?:? and delete all leading > zeros, then you got your link-local IPv6 address: > FE80::CE00:BFF:FEFC:0 > ============ > > So if your BIA is 0008.209a.081b (bia 0008.209a.081b), how link-local > be calculated. This is the link-local on router => > IPv6 is enabled, link-local address is FE80::208:20FF:FE9A:81B > > Also on XR below is the link local address > > Loopback6 is Up, ipv6 protocol is Up, Vrfid is default (0x60000000) > IPv6 is enabled, link-local address is fe80::884c:2dff:fe84:8d75 > > I can not see any interface with BIA ending with 75 ... > Have you looked for the BIA on the loopback interface? While it's not a hardware interface, per se, the device is obviously assigning a BIA of 8a:4c:2d:84:8d:75 to the loopback6 interface. > Can someone explain me this? > I think I just did. ;-) Owen From tpoder at cis.vutbr.cz Thu Apr 7 08:51:07 2011 From: tpoder at cis.vutbr.cz (Tomas Podermanski) Date: Thu, 07 Apr 2011 15:51:07 +0200 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <897661.3824.qm@web121620.mail.ne1.yahoo.com> References: <4D9D8365.9060202@optilian.com> <897661.3824.qm@web121620.mail.ne1.yahoo.com> Message-ID: <4D9DC14B.8090308@cis.vutbr.cz> Hi Daniel, all IPv6 multihoming ideas are very theoretical today. None of them is ready to use. Shim6 looks very good, but it requires support on both a client and a server side. As you can guess, there is only experimental support for some operating systems. Microsoft and Apple doesn't support it. A one possible solution I have found is based on a network prefix translation (NPTv6 http://tools.ietf.org/html/draft-mrw-nat66-12). Using NPTv6 you can do multihoming that is very similar to multihoming based on IPv4 NAT. I haven't found any commercial product that supports it, but you can use an implementation for Linux (map66 http://sourceforge.net/projects/map66/). Assembling map66 with some other scripts (to detect link failure) you can have what are you looking for. On 4/7/11 11:58 AM, isabel dias wrote: > have you thought about taking a Cisco training course? I wonder if that kind of knowledge can be learned in any Cisco course today. I don't think so. Tomas > ----- Original Message ---- > From: Daniel STICKNEY > To: nanog at nanog.org > Sent: Thu, April 7, 2011 10:27:01 AM > Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites > > Hello all, > > I'm investigating how to setup multihoming for IPv6 over two DSL lines > (different ISPs), and I wanted to see if this wheel has already been > invented. Has anyone already set this up or tested it ? > > In my research into the proposed solutions I came across this document > "IEEE Communications Surveys - 2nd Quarter 2006, Volume 8, No. 2" > (http://www.shim6.org/path-to-mh.pdf) which seems quite thorough. It > compares routing methods, middle-box methods, and host-centric methods. > It mentions "During the last years, the IETF has made several explicit > or implicit architectural decisions regarding IPv6 multihoming. The main > decision is to go down the path of developing the host-centric > approaches" as well as "Host-centric multihoming, the approach promoted > by the IETF for IPv6 multihoming, [...]". After the comparison of all > host-centric methods it adds " [...], the IETF has decided by the end of > 2004 to foster the SHIM approach." > > This approach looks interesting to me after all the comparisons, though > I'm less familiar with it. I'm interested to hear your real-world > experiences on this topic. > > Thanks, > Daniel > From owen at delong.com Thu Apr 7 09:04:25 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Apr 2011 07:04:25 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <4D9DC14B.8090308@cis.vutbr.cz> References: <4D9D8365.9060202@optilian.com> <897661.3824.qm@web121620.mail.ne1.yahoo.com> <4D9DC14B.8090308@cis.vutbr.cz> Message-ID: <145AC4DF-2DBB-4818-9BBB-8E325CCB56E7@delong.com> On Apr 7, 2011, at 6:51 AM, Tomas Podermanski wrote: > Hi Daniel, > all IPv6 multihoming ideas are very theoretical today. None of them > is ready to use. Shim6 looks very good, but it requires support on both > a client and a server side. As you can guess, there is only experimental > support for some operating systems. Microsoft and Apple doesn't support it. > Well, BGP multihoming works today quite well. It's no different from IPv4 and is a perfectly viable technology. > A one possible solution I have found is based on a network prefix > translation (NPTv6 http://tools.ietf.org/html/draft-mrw-nat66-12). Using > NPTv6 you can do multihoming that is very similar to multihoming based > on IPv4 NAT. > You can also use thumb cuffs to suspend yourself from a rafter, but, I don't recommend it unless you are into pain. Owen From andrew.wallace at rocketmail.com Thu Apr 7 10:14:02 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 7 Apr 2011 08:14:02 -0700 (PDT) Subject: Tsunami warning for north-east Japan Message-ID: <448134.50783.qm@web59616.mail.ac4.yahoo.com> A tsunami warning is issued for north-eastern Japan after an earthquake with a magnitude of 7.4 hits the region. Andrew From myamanis at japan-telecom.com Thu Apr 7 11:49:42 2011 From: myamanis at japan-telecom.com (Masato YAMANISHI) Date: Thu, 7 Apr 2011 09:49:42 -0700 Subject: Tsunami warning for north-east Japan In-Reply-To: <448134.50783.qm@web59616.mail.ac4.yahoo.com> References: <448134.50783.qm@web59616.mail.ac4.yahoo.com> Message-ID: <2C409913F7A04C5F8756CF7194A47D6A@bb.local> The warning was released at 3:55PM in GMT, but local news says several number of people is injured again. Masato > -----Original Message----- > From: andrew.wallace [mailto:andrew.wallace at rocketmail.com] > Sent: Thursday, April 07, 2011 8:14 AM > To: nanog at nanog.org > Subject: Tsunami warning for north-east Japan > > A tsunami warning is issued for north-eastern Japan after an > earthquake with a magnitude of 7.4 hits the region. > > > Andrew > > From sethm at rollernet.us Thu Apr 7 13:38:24 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 07 Apr 2011 11:38:24 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <4D9D8365.9060202@optilian.com> References: <4D9D8365.9060202@optilian.com> Message-ID: <4D9E04A0.6030304@rollernet.us> On 4/7/2011 02:27, Daniel STICKNEY wrote: > Hello all, > > I'm investigating how to setup multihoming for IPv6 over two DSL lines > (different ISPs), and I wanted to see if this wheel has already been > invented. Has anyone already set this up or tested it ? > > In my research into the proposed solutions I came across this document > "IEEE Communications Surveys - 2nd Quarter 2006, Volume 8, No. 2" > (http://www.shim6.org/path-to-mh.pdf) which seems quite thorough. It > compares routing methods, middle-box methods, and host-centric methods. > It mentions "During the last years, the IETF has made several explicit > or implicit architectural decisions regarding IPv6 multihoming. The main > decision is to go down the path of developing the host-centric > approaches" as well as "Host-centric multihoming, the approach promoted > by the IETF for IPv6 multihoming, [...]". After the comparison of all > host-centric methods it adds " [...], the IETF has decided by the end of > 2004 to foster the SHIM approach." > > This approach looks interesting to me after all the comparisons, though > I'm less familiar with it. I'm interested to hear your real-world > experiences on this topic. > It doesn't exist in practice; real world is BGP multihoming. Everything else is still just an academic exercise. ~Seth From jeroen at mompl.net Thu Apr 7 13:54:21 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 07 Apr 2011 11:54:21 -0700 Subject: Bubba is a 75 year old woman looking to make some extra cash In-Reply-To: References: Message-ID: <4D9E085D.3010608@mompl.net> Suresh Ramasubramanian wrote: > http://www.guardian.co.uk/world/2011/apr/06/georgian-woman-cuts-web-access Babushkas can be quite mean, though mostly it's shopping bags that are their preferred tools of assault. ;-) From TA: "The cable is owned by the Georgian railway network. It is heavily protected" I don't think that's true, you can't really heavily guard every stretch of cable since it spans such a long distance. There will always be weak spots. From TA: "Pulling up unused copper cables for scrap is a common means of making money in the former Soviet Union." This is common in the Netherlands too nowadays and other countries too I am sure. Because copper has gone up in price considerably. In the Netherlands especially copper lines along railroad tracks are removed, disabling alert systems with obvious dangerous results. Regards, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From mike at mtcc.com Thu Apr 7 14:07:09 2011 From: mike at mtcc.com (Michael Thomas) Date: Thu, 07 Apr 2011 12:07:09 -0700 Subject: Bubba is a 75 year old woman looking to make some extra cash In-Reply-To: <4D9E085D.3010608@mompl.net> References: <4D9E085D.3010608@mompl.net> Message-ID: <4D9E0B5D.7050309@mtcc.com> On 04/07/2011 11:54 AM, Jeroen van Aart wrote: > This is common in the Netherlands too nowadays and other countries too > I am sure. Because copper has gone up in price considerably. In the > Netherlands especially copper lines along railroad tracks are removed, > disabling alert systems with obvious dangerous results. Say now, that might be one way to force the issue of FTTH. Mike From owen at delong.com Thu Apr 7 14:16:19 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Apr 2011 14:16:19 -0500 Subject: Bubba is a 75 year old woman looking to make some extra cash In-Reply-To: <4D9E085D.3010608@mompl.net> References: <4D9E085D.3010608@mompl.net> Message-ID: Sent from my iPad On Apr 7, 2011, at 1:54 PM, Jeroen van Aart wrote: > Suresh Ramasubramanian wrote: >> http://www.guardian.co.uk/world/2011/apr/06/georgian-woman-cuts-web-access > > Babushkas can be quite mean, though mostly it's shopping bags that are their preferred tools of assault. ;-) > As the recipient of a number of umbrella tips while trying to catch up to my fiancee (at the time, ex-wife now) in a meat shop in Moscow, I have to differ with you here. They seem quite adept at the use of an umbrella rather than a shopping bag as an effective weapon. Once we finally got out of the shop (I was a full 10 minutes delayed behind my fiancee), we figured out that her effort to move efficiently through the crowd (which virtually parted before her) combined with my effort to keep up (or catch up as rapidly became the case) had been interpreted by the babushkas as her trying to get away from my unwanted attentions. I must say, they were impressively effective and well coordinated in impeding my progress while expediting hers considering it was a random crowd of seemingly unconnected people. Owen From jeroen at mompl.net Thu Apr 7 14:23:12 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 07 Apr 2011 12:23:12 -0700 Subject: v6 Avian Carriers? In-Reply-To: References: Message-ID: <4D9E0F20.1090004@mompl.net> Sachs, Marcus Hans (Marc) wrote: > http://datatracker.ietf.org/doc/rfc6214/ That RFC is the opposite of funny (to me). Just because rfc1149 is funny that doesn't mean that repetitions of it are funny too. Quite the contrary. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From d.nostra at gmail.com Thu Apr 7 14:30:58 2011 From: d.nostra at gmail.com (Michel de Nostredame) Date: Thu, 7 Apr 2011 12:30:58 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <4D9D8365.9060202@optilian.com> References: <4D9D8365.9060202@optilian.com> Message-ID: On Thu, Apr 7, 2011 at 2:27 AM, Daniel STICKNEY wrote: > I'm investigating how to setup multihoming for IPv6 over two DSL lines > (different ISPs), and I wanted to see if this wheel has already been > invented. Has anyone already set this up or tested it ? When you talking about "two DSL lines", I assume this is mainly for office / residential environment to have redundancy and/or increase uplink availability. In this environment, BGP exchanges with uplink ISPs for multihoming usually is not an option. One reason maybe cost, another reason maybe ISP doesn't like to setup BGP with a DSL customer. At least in my case, reason #2 always prevent my customers to setup BGP with uplink ISPs. As Seth pointed out SHIM6 is still an academic exercise, my experiences to resolve this needs at this moment is leveraging NAT66, as what we did in IPv4 world. I use FreeBSD+PF and Juniper NetScreen/SSG to do NAT66 in several different locations, and they all works as expected so far. Some people don't like NAT especially NAT66, but to be realistic that does work, and works well in terms of providing redundancy over two DSL lines for office / residential needs. -- Michel~ From Valdis.Kletnieks at vt.edu Thu Apr 7 14:35:53 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 07 Apr 2011 15:35:53 -0400 Subject: v6 Avian Carriers? In-Reply-To: Your message of "Thu, 07 Apr 2011 12:23:12 PDT." <4D9E0F20.1090004@mompl.net> References: <4D9E0F20.1090004@mompl.net> Message-ID: <19358.1302204953@localhost> On Thu, 07 Apr 2011 12:23:12 PDT, Jeroen van Aart said: > Sachs, Marcus Hans (Marc) wrote: > > http://datatracker.ietf.org/doc/rfc6214/ > > That RFC is the opposite of funny (to me). Just because rfc1149 is funny > that doesn't mean that repetitions of it are funny too. Quite the contrary. Yes, but I bet many providers recognize rfc1149 now. rfc6214 gives us a new brown M&M to put into the contracts... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From scott.brim at gmail.com Thu Apr 7 14:39:03 2011 From: scott.brim at gmail.com (Scott Brim) Date: Thu, 7 Apr 2011 15:39:03 -0400 Subject: v6 Avian Carriers? In-Reply-To: <19358.1302204953@localhost> References: <4D9E0F20.1090004@mompl.net> <19358.1302204953@localhost> Message-ID: On Thu, Apr 7, 2011 at 15:35, wrote: > On Thu, 07 Apr 2011 12:23:12 PDT, Jeroen van Aart said: > > Sachs, Marcus Hans (Marc) wrote: > > > http://datatracker.ietf.org/doc/rfc6214/ > > > > That RFC is the opposite of funny (to me). Just because rfc1149 is funny > > that doesn't mean that repetitions of it are funny too. Quite the > contrary. > > Yes, but I bet many providers recognize rfc1149 now. rfc6214 gives us a > new > brown M&M to put into the contracts... > You need to specify "tail drop" behavior. From jeroen at mompl.net Thu Apr 7 14:58:38 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 07 Apr 2011 12:58:38 -0700 Subject: twitter is serving up errors In-Reply-To: <13913.1302115596@localhost> References: <20997215.1905.1302061413497.JavaMail.root@benjamin.baylink.com> <4D9CB14F.2040407@airwire.ie> <13913.1302115596@localhost> Message-ID: <4D9E176E.8050103@mompl.net> Valdis.Kletnieks at vt.edu wrote: > On Wed, 06 Apr 2011 19:30:39 BST, Martin List-Petersen said: > >> Ah well, you'd better have a LOT of storage space for your mailbox, if >> you subscribe to that :) > > Odd. I get more traffic on NANOG than on Outages. Now if you want > a firehose list, go read linux-kernel. *that* will chew some storage at 400+ > postings a day. ;) Yeah nanog is far more busy than outages, I think he meant the outages discussion list, which I can imagine may have high traffic and heated debates. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From bicknell at ufp.org Thu Apr 7 15:00:48 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 7 Apr 2011 13:00:48 -0700 Subject: v6 Avian Carriers? In-Reply-To: References: <4D9E0F20.1090004@mompl.net> <19358.1302204953@localhost> Message-ID: <20110407200048.GA75492@ussenterprise.ufp.org> In a message written on Thu, Apr 07, 2011 at 03:39:03PM -0400, Scott Brim wrote: > You need to specify "tail drop" behavior. It may be a Eurasian Hobby to make such silly statements, but to me it just seems like an Imperial Shag, and a waste of everyone's time. A Brown Kiwi once told me that the Cardinal rule of mailing lists was to wait your Tern, and not cause any ruffled feathers. However, many folks seem to be Superb Parrots, repeating the same discussion over and over. Others are too Chicken to join in. Eventually this can become the Swan song for a mailing list. Once the Common Nighthawks take over, it's done. A Swift decline will occur, for sure, which is often hard to Swallow. But, I posted this on a Lark. Not to Crow about it, but I think I did quite a bit better than a Common Babbler, and Warbled my way to a fun to read post, a hoot if you will. Hopefully folks don't think this was a Fowl. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From achatz at forthnet.gr Thu Apr 7 16:07:49 2011 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Fri, 08 Apr 2011 00:07:49 +0300 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: References: <4D9D8365.9060202@optilian.com> Message-ID: <4D9E27A5.3040108@forthnet.gr> Michel de Nostredame wrote on 07/04/2011 22:30: > On Thu, Apr 7, 2011 at 2:27 AM, Daniel STICKNEY wrote: > >> I'm investigating how to setup multihoming for IPv6 over two DSL lines >> (different ISPs), and I wanted to see if this wheel has already been >> invented. Has anyone already set this up or tested it ? >> > When you talking about "two DSL lines", I assume this is mainly for > office / residential environment to have redundancy and/or increase > uplink availability. > > In this environment, BGP exchanges with uplink ISPs for multihoming > usually is not an option. One reason maybe cost, another reason maybe > ISP doesn't like to setup BGP with a DSL customer. At least in my > case, reason #2 always prevent my customers to setup BGP with uplink > ISPs. > > As Seth pointed out SHIM6 is still an academic exercise, my > experiences to resolve this needs at this moment is leveraging NAT66, > as what we did in IPv4 world. I use FreeBSD+PF and Juniper > NetScreen/SSG to do NAT66 in several different locations, and they all > works as expected so far. > > Some people don't like NAT especially NAT66, but to be realistic that > does work, and works well in terms of providing redundancy over two > DSL lines for office / residential needs. > > -- > Michel~ > > > Although i generally hate NAT, multihoming must be the only (or at least the most important) reason why NAT66 has to be standardized. Otherwise some kind of routing must be implemented on hosts. -- Tassos From streiner at cluebyfour.org Thu Apr 7 16:20:33 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 7 Apr 2011 17:20:33 -0400 (EDT) Subject: Bubba is a 75 year old woman looking to make some extra cash In-Reply-To: <4D9E0B5D.7050309@mtcc.com> References: <4D9E085D.3010608@mompl.net> <4D9E0B5D.7050309@mtcc.com> Message-ID: On Thu, 7 Apr 2011, Michael Thomas wrote: > On 04/07/2011 11:54 AM, Jeroen van Aart wrote: >> This is common in the Netherlands too nowadays and other countries too I >> am sure. Because copper has gone up in price considerably. In the >> Netherlands especially copper lines along railroad tracks are removed, >> disabling alert systems with obvious dangerous results. > > Say now, that might be one way to force the issue of FTTH. That won't prevent outages due to cable cuts. I've heard of people cutting spans of fiber, thinking it was copper, and then throwing by the wayside once they realized there was nothing in there that a recycler would pay for. jms From jason at thebaughers.com Thu Apr 7 17:14:31 2011 From: jason at thebaughers.com (Jason Baugher) Date: Thu, 07 Apr 2011 17:14:31 -0500 Subject: Bubba is a 75 year old woman looking to make some extra cash In-Reply-To: <4D9E085D.3010608@mompl.net> References: <4D9E085D.3010608@mompl.net> Message-ID: <4D9E3747.9090108@thebaughers.com> We had someone come into a cell site and strip out all the outside ground leads. Oddly enough they left the ground bars themselves, which would have been much more worthwhile. Maybe they came unprepared and only had clippers. Also, several years ago a building in our area was being renovated, and someone snuck in during the night and stripped the wires from the main service panel. I wouldn't think the amount of copper there would be worth the time, but some people aren't too bright. We also had a 180' monopole that we replaced, and the crew laid the old monopole down on the ground with all the equipment still in place. We didn't get to it to remove our antennas for a few weeks, and when we did, we found that someone had stripped out 3 runs of 1 5/8" coax from inside the tower. Needless to say, all of our copper reels are locked up to keep them from walking off during the night. I'd think that unless someone could get access to a LOT of copper all at one place, and fairly easy to get to, that it wouldn't be worth the time and effort. Jason On 4/7/2011 1:54 PM, Jeroen van Aart wrote: > Suresh Ramasubramanian wrote: >> http://www.guardian.co.uk/world/2011/apr/06/georgian-woman-cuts-web-access >> > > Babushkas can be quite mean, though mostly it's shopping bags that are > their preferred tools of assault. ;-) > > From TA: > "The cable is owned by the Georgian railway network. It is heavily > protected" > > I don't think that's true, you can't really heavily guard every > stretch of cable since it spans such a long distance. There will > always be weak spots. > > From TA: > "Pulling up unused copper cables for scrap is a common means of making > money in the former Soviet Union." > > This is common in the Netherlands too nowadays and other countries too > I am sure. Because copper has gone up in price considerably. In the > Netherlands especially copper lines along railroad tracks are removed, > disabling alert systems with obvious dangerous results. > > Regards, > Jeroen > From jra at baylink.com Thu Apr 7 17:56:47 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 7 Apr 2011 18:56:47 -0400 (EDT) Subject: v6 Avian Carriers? In-Reply-To: <19358.1302204953@localhost> Message-ID: <31263762.1989.1302217007865.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > On Thu, 07 Apr 2011 12:23:12 PDT, Jeroen van Aart said: > > Sachs, Marcus Hans (Marc) wrote: > > > http://datatracker.ietf.org/doc/rfc6214/ > > > > That RFC is the opposite of funny (to me). Just because rfc1149 is > > funny > > that doesn't mean that repetitions of it are funny too. Quite the > > contrary. > > Yes, but I bet many providers recognize rfc1149 now. rfc6214 gives us > a new brown M&M to put into the contracts... I wonder what NYC paramedic David Roth would think, to find out that he'd coined a bit of technical jargon, quite by accident. Cheers, -- jra From marka at isc.org Thu Apr 7 20:34:37 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 08 Apr 2011 11:34:37 +1000 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: Your message of "Fri, 08 Apr 2011 00:07:49 +0300." <4D9E27A5.3040108@forthnet.gr> References: <4D9D8365.9060202@optilian.com> <4D9E27A5.3040108@forthnet.gr> Message-ID: <20110408013437.87FFEDEEF6D@drugs.dv.isc.org> In message <4D9E27A5.3040108 at forthnet.gr>, Tassos Chatzithomaoglou writes: > > Michel de Nostredame wrote on 07/04/2011 22:30: > > On Thu, Apr 7, 2011 at 2:27 AM, Daniel STICKNEY wr > ote: > > > >> I'm investigating how to setup multihoming for IPv6 over two DSL lines > >> (different ISPs), and I wanted to see if this wheel has already been > >> invented. Has anyone already set this up or tested it ? > >> > > When you talking about "two DSL lines", I assume this is mainly for > > office / residential environment to have redundancy and/or increase > > uplink availability. > > > > In this environment, BGP exchanges with uplink ISPs for multihoming > > usually is not an option. One reason maybe cost, another reason maybe > > ISP doesn't like to setup BGP with a DSL customer. At least in my > > case, reason #2 always prevent my customers to setup BGP with uplink > > ISPs. > > > > As Seth pointed out SHIM6 is still an academic exercise, my > > experiences to resolve this needs at this moment is leveraging NAT66, > > as what we did in IPv4 world. I use FreeBSD+PF and Juniper > > NetScreen/SSG to do NAT66 in several different locations, and they all > > works as expected so far. > > > > Some people don't like NAT especially NAT66, but to be realistic that > > does work, and works well in terms of providing redundancy over two > > DSL lines for office / residential needs. > > > > -- > > Michel~ > > > > > > > Although i generally hate NAT, multihoming must be the only (or at least > the most important) reason why NAT66 has to be standardized. > Otherwise some kind of routing must be implemented on hosts. And what's wrong with routing on hosts? If a router advertises a prefix it should know where to send traffic that originates from that prefix. You just choose the next hop by looking at which routers are advertising the prefix for the source address for this packet and choosing between them. It's a touch more state to be kept with every address. It would also be useful for filtering out rouge RAs. You look at the address you learnt the prefix from then filter out that router / prefix. > -- > Tassos > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jabley at hopcount.ca Thu Apr 7 20:39:07 2011 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 7 Apr 2011 21:39:07 -0400 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <4D9E27A5.3040108@forthnet.gr> References: <4D9D8365.9060202@optilian.com> <4D9E27A5.3040108@forthnet.gr> Message-ID: On 2011-04-07, at 17:07, Tassos Chatzithomaoglou wrote: > Otherwise some kind of routing must be implemented on hosts. Some kind of routing is already implemented on hosts. Joe From nanog at jima.tk Thu Apr 7 20:43:17 2011 From: nanog at jima.tk (Jima) Date: Thu, 07 Apr 2011 20:43:17 -0500 Subject: Bubba is a 75 year old woman looking to make some extra cash In-Reply-To: References: <4D9E085D.3010608@mompl.net> Message-ID: <4D9E6835.5060406@jima.tk> On 4/7/2011 2:16 PM, Owen DeLong wrote: > On Apr 7, 2011, at 1:54 PM, Jeroen van Aart wrote: >> Babushkas can be quite mean, though mostly it's shopping bags that are their preferred tools of assault. ;-) >> > As the recipient of a number of umbrella tips while trying to catch up to my fiancee (at the time, ex-wife now) in a meat shop in Moscow, I have to differ with you here. They seem quite adept at the use of an umbrella rather than a shopping bag as an effective weapon. I guess we have another gem for DeLongFacts.com (in the vein of SchneierFacts.com): He is one of the few natural enemies of the Babushka. Jima From streiner at cluebyfour.org Thu Apr 7 20:57:47 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 7 Apr 2011 21:57:47 -0400 (EDT) Subject: Bubba is a 75 year old woman looking to make some extra cash In-Reply-To: <4D9E3747.9090108@thebaughers.com> References: <4D9E085D.3010608@mompl.net> <4D9E3747.9090108@thebaughers.com> Message-ID: On Thu, 7 Apr 2011, Jason Baugher wrote: > We had someone come into a cell site and strip out all the outside ground > leads. Oddly enough they left the ground bars themselves, which would have > been much more worthwhile. Maybe they came unprepared and only had clippers. Every once in awhile there is also a story about either a disgruntled (former) employee or an outsider managing to get into a CO or other technical space and electrocuting themselves when they try to cut out live power cables. One group does it for salvage value - the other (presumably) does it to make some kind of statement or cause their (former) employer headaches. Neither is particularly bright.... jms From randy at psg.com Thu Apr 7 21:53:33 2011 From: randy at psg.com (Randy Bush) Date: Thu, 07 Apr 2011 19:53:33 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: References: <4D9D8365.9060202@optilian.com> <4D9E27A5.3040108@forthnet.gr> Message-ID: >> Otherwise some kind of routing must be implemented on hosts. > Some kind of routing is already implemented on hosts. honto??? From owen at delong.com Thu Apr 7 21:51:47 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Apr 2011 19:51:47 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <4D9E27A5.3040108@forthnet.gr> References: <4D9D8365.9060202@optilian.com> <4D9E27A5.3040108@forthnet.gr> Message-ID: <01B5D224-9A81-47DC-A145-53E887928898@delong.com> Sent from my iPad On Apr 7, 2011, at 2:07 PM, Tassos Chatzithomaoglou wrote: > > Michel de Nostredame wrote on 07/04/2011 22:30: >> On Thu, Apr 7, 2011 at 2:27 AM, Daniel STICKNEY wrote: >> >>> I'm investigating how to setup multihoming for IPv6 over two DSL lines >>> (different ISPs), and I wanted to see if this wheel has already been >>> invented. Has anyone already set this up or tested it ? >>> >> When you talking about "two DSL lines", I assume this is mainly for >> office / residential environment to have redundancy and/or increase >> uplink availability. >> >> In this environment, BGP exchanges with uplink ISPs for multihoming >> usually is not an option. One reason maybe cost, another reason maybe >> ISP doesn't like to setup BGP with a DSL customer. At least in my >> case, reason #2 always prevent my customers to setup BGP with uplink >> ISPs. >> >> As Seth pointed out SHIM6 is still an academic exercise, my >> experiences to resolve this needs at this moment is leveraging NAT66, >> as what we did in IPv4 world. I use FreeBSD+PF and Juniper >> NetScreen/SSG to do NAT66 in several different locations, and they all >> works as expected so far. >> >> Some people don't like NAT especially NAT66, but to be realistic that >> does work, and works well in terms of providing redundancy over two >> DSL lines for office / residential needs. >> >> -- >> Michel~ >> >> >> > Although i generally hate NAT, multihoming must be the only (or at least the most important) reason why NAT66 has to be standardized. > Otherwise some kind of routing must be implemented on hosts. > There is no need for NAT in order to multiple-home. BGP is every bit as effective and much simpler. Owen > -- > Tassos > From gbonser at seven.com Thu Apr 7 22:04:19 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 7 Apr 2011 20:04:19 -0700 Subject: Bubba is a 75 year old woman looking to make some extra cash In-Reply-To: <4D9E3747.9090108@thebaughers.com> References: <4D9E085D.3010608@mompl.net> <4D9E3747.9090108@thebaughers.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E2CAD@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Jason Baugher [mailto:jason at thebaughers.com] > Sent: Thursday, April 07, 2011 3:15 PM > To: nanog at nanog.org > Subject: Re: Bubba is a 75 year old woman looking to make some extra > cash > > We had someone come into a cell site and strip out all the outside > ground leads. Oddly enough they left the ground bars themselves, which > would have been much more worthwhile. Maybe they came unprepared and > only had clippers. A nearby city that also serves as the local electric often has to go to the local metal recycler to buy their own cable back. From yintochu at gmail.com Thu Apr 7 22:08:36 2011 From: yintochu at gmail.com (Yin To Chu) Date: Fri, 8 Apr 2011 13:08:36 +1000 Subject: l Message-ID: From yintochu at gmail.com Thu Apr 7 22:12:07 2011 From: yintochu at gmail.com (Yin To Chu) Date: Fri, 8 Apr 2011 13:12:07 +1000 Subject: No subject Message-ID: From tal at whatexit.org Thu Apr 7 22:13:42 2011 From: tal at whatexit.org (Tom Limoncelli) Date: Thu, 7 Apr 2011 23:13:42 -0400 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <01B5D224-9A81-47DC-A145-53E887928898@delong.com> References: <4D9D8365.9060202@optilian.com> <4D9E27A5.3040108@forthnet.gr> <01B5D224-9A81-47DC-A145-53E887928898@delong.com> Message-ID: On Thu, Apr 7, 2011 at 10:51 PM, Owen DeLong wrote: > There is no need for NAT in order to multiple-home. BGP is every bit as effective and much simpler. > I know a lot of small businesses with one FiOS link and one Comcast link and I don't think they're going to be able to do BGP. Their providers won't do it and their prem equipment doesn't support it and the local IT person doesn't have the know-how to do it. I know that the typical NANOG member isn't in this category, but this is a use-case that is very common and outnumbers NANOG members. Tom -- Sign up for my new class "Advanced Time Mgmt: Team Efficiency" at PICC! April 29-30, New Jersey, LOPSA PICC: www.picconf.org "Call for papers and talk proposals" open at LISA! Write your paper today! Dec 4-9, Boston, Usenix LISA, www.usenix.org/event/lisa11 From joelja at bogus.com Thu Apr 7 22:13:44 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 07 Apr 2011 20:13:44 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: References: <4D9D8365.9060202@optilian.com> <4D9E27A5.3040108@forthnet.gr> Message-ID: <4D9E7D68.2000903@bogus.com> On 4/7/11 7:53 PM, Randy Bush wrote: >>> Otherwise some kind of routing must be implemented on hosts. >> Some kind of routing is already implemented on hosts. > > honto??? > your mobile phone is multihomed, as is this laptop I'm typing on. From joelja at bogus.com Thu Apr 7 22:26:25 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 07 Apr 2011 20:26:25 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: References: <4D9D8365.9060202@optilian.com> <4D9E27A5.3040108@forthnet.gr> <01B5D224-9A81-47DC-A145-53E887928898@delong.com> Message-ID: <4D9E8061.6090804@bogus.com> On 4/7/11 8:13 PM, Tom Limoncelli wrote: > On Thu, Apr 7, 2011 at 10:51 PM, Owen DeLong wrote: >> There is no need for NAT in order to multiple-home. BGP is every bit as effective and much simpler. >> > > I know a lot of small businesses with one FiOS link and one Comcast > link and I don't think they're going to be able to do BGP. Their > providers won't do it and their prem equipment doesn't support it and > the local IT person doesn't have the know-how to do it. I know that > the typical NANOG member isn't in this category, but this is a > use-case that is very common and outnumbers NANOG members. building a cpe that can do something useful with two ip addresses and two default routes to two consumer isps isn't really that hard, had a cisco 2500 circa 1995 that did dial on demand for backup... heck, today you can get a cradlepoint with 3 x 3g/4g wireless cards attached. > Tom > From randy at psg.com Thu Apr 7 22:30:00 2011 From: randy at psg.com (Randy Bush) Date: Thu, 07 Apr 2011 20:30:00 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <4D9E7D68.2000903@bogus.com> References: <4D9D8365.9060202@optilian.com> <4D9E27A5.3040108@forthnet.gr> <4D9E7D68.2000903@bogus.com> Message-ID: >>>> Otherwise some kind of routing must be implemented on hosts. >>> Some kind of routing is already implemented on hosts. >> honto??? > your mobile phone is multihomed, as is this laptop I'm typing on. routing != multihomed try rfc 1812 randy From joelja at bogus.com Fri Apr 8 01:54:01 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 07 Apr 2011 23:54:01 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: References: <4D9D8365.9060202@optilian.com> <4D9E27A5.3040108@forthnet.gr> <4D9E7D68.2000903@bogus.com> Message-ID: <4D9EB109.3020006@bogus.com> On 4/7/11 8:30 PM, Randy Bush wrote: >>>>> Otherwise some kind of routing must be implemented on hosts. >>>> Some kind of routing is already implemented on hosts. >>> honto??? >> your mobile phone is multihomed, as is this laptop I'm typing on. > > routing != multihomed it's not an autonomous system it's embedded inside one or more of them... it most definitely makes a forwarding decision which in this case also requires address selection. > try rfc 1812 A router connects to two or more logical interfaces, represented by IP subnets or unnumbered point to point lines (discussed in section [2.2.7]). Thus, it has at least one physical interface. Forwarding an IP datagram generally requires the router to choose the address and relevant interface of the next-hop router or (for the final hop) the destination host. This choice, called relaying or forwarding depends upon a route database within the router. The route database is also called a routing table or forwarding table. The term "router" derives from the process of building this route database; routing protocols and configuration interact in a process called routing. > randy > From owen at delong.com Fri Apr 8 02:22:11 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Apr 2011 00:22:11 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: References: <4D9D8365.9060202@optilian.com> <4D9E27A5.3040108@forthnet.gr> Message-ID: <9D71B79D-C8F2-4898-B9FD-DF7C8AE7E872@delong.com> On Apr 7, 2011, at 7:53 PM, Randy Bush wrote: >>> Otherwise some kind of routing must be implemented on hosts. >> Some kind of routing is already implemented on hosts. > > honto??? (I think you meant honto desu ka??). hai. Honto desu. Owen From owen at delong.com Fri Apr 8 02:25:42 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Apr 2011 00:25:42 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: References: <4D9D8365.9060202@optilian.com> <4D9E27A5.3040108@forthnet.gr> <4D9E7D68.2000903@bogus.com> Message-ID: On Apr 7, 2011, at 8:30 PM, Randy Bush wrote: >>>>> Otherwise some kind of routing must be implemented on hosts. >>>> Some kind of routing is already implemented on hosts. >>> honto??? >> your mobile phone is multihomed, as is this laptop I'm typing on. > > routing != multihomed > > try rfc 1812 > > randy Many of my hosts have more than one interface and will forward packets received on one to hosts connected on others. That's routing. Next? Owen From owen at delong.com Fri Apr 8 02:27:12 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Apr 2011 00:27:12 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: References: <4D9D8365.9060202@optilian.com> <4D9E27A5.3040108@forthnet.gr> <01B5D224-9A81-47DC-A145-53E887928898@delong.com> Message-ID: <37F0E004-6596-4761-A0FE-E619EDCC89F0@delong.com> On Apr 7, 2011, at 8:13 PM, Tom Limoncelli wrote: > On Thu, Apr 7, 2011 at 10:51 PM, Owen DeLong wrote: >> There is no need for NAT in order to multiple-home. BGP is every bit as effective and much simpler. >> > > I know a lot of small businesses with one FiOS link and one Comcast > link and I don't think they're going to be able to do BGP. Their > providers won't do it and their prem equipment doesn't support it and > the local IT person doesn't have the know-how to do it. I know that > the typical NANOG member isn't in this category, but this is a > use-case that is very common and outnumbers NANOG members. > I have one DSL and one Cable. Neither the DSL provider nor Comcast will do BGP. I do BGP just fine without them doing BGP. Owen From tim at pelican.org Fri Apr 8 03:36:33 2011 From: tim at pelican.org (Tim Franklin) Date: Fri, 08 Apr 2011 09:36:33 +0100 (BST) Subject: Bubba is a 75 year old woman looking to make some extra cash In-Reply-To: <4D9E6835.5060406@jima.tk> Message-ID: > I guess we have another gem for DeLongFacts.com (in the vein of > SchneierFacts.com): He is one of the few natural enemies of the > Babushka. Did anyone else suddenly have flashbacks to the VMS Wombat? From randy at psg.com Fri Apr 8 04:47:08 2011 From: randy at psg.com (Randy Bush) Date: Fri, 08 Apr 2011 02:47:08 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <4D9EB109.3020006@bogus.com> References: <4D9D8365.9060202@optilian.com> <4D9E27A5.3040108@forthnet.gr> <4D9E7D68.2000903@bogus.com> <4D9EB109.3020006@bogus.com> Message-ID: check out these things called routing protocols. randy From jmaimon at ttec.com Fri Apr 8 08:54:39 2011 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 08 Apr 2011 09:54:39 -0400 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <37F0E004-6596-4761-A0FE-E619EDCC89F0@delong.com> References: <4D9D8365.9060202@optilian.com> <4D9E27A5.3040108@forthnet.gr> <01B5D224-9A81-47DC-A145-53E887928898@delong.com> <37F0E004-6596-4761-A0FE-E619EDCC89F0@delong.com> Message-ID: <4D9F139F.6090804@ttec.com> Owen DeLong wrote: > > On Apr 7, 2011, at 8:13 PM, Tom Limoncelli wrote: > >> On Thu, Apr 7, 2011 at 10:51 PM, Owen DeLong wrote: >>> There is no need for NAT in order to multiple-home. BGP is every bit as effective and much simpler. >>> >> >> I know a lot of small businesses with one FiOS link and one Comcast >> link and I don't think they're going to be able to do BGP. Their >> providers won't do it and their prem equipment doesn't support it and >> the local IT person doesn't have the know-how to do it. I know that >> the typical NANOG member isn't in this category, but this is a >> use-case that is very common and outnumbers NANOG members. >> > I have one DSL and one Cable. Neither the DSL provider nor Comcast > will do BGP. I do BGP just fine without them doing BGP. > > Owen > Your use case requires at minimum a triangle, ideally a rectangle. Along for the ride comes encapsulation, overhead, additional bottlenecks and failure scenarios. The payoff has to be worth it and that usually means something more than the elimination of napt on outbound internet access, such as inbound access to bring-your-own-ip. For anyone to do this requires beyond basic know-how and a willing 3rd point. I'll do it for a customer, but it is by no means readily available, or even ideal, so lets stop hyping it. Joe From jsw at inconcepts.biz Fri Apr 8 10:04:30 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Fri, 8 Apr 2011 11:04:30 -0400 Subject: [torix-ops] Fabric Issues Update In-Reply-To: <38EEA802-C6CE-4B00-82C5-40771F133282@torix.net> References: <38EEA802-C6CE-4B00-82C5-40771F133282@torix.net> Message-ID: Netelligent's sessions are also down to allow for troubleshooting without disrupting customer traffic, and we'll turn back up once TORIX indicates everything is okay. For any members who might have a usage-based billing for carrier transport to TORIX, it is worth mentioning that if you see extra "junk" traffic coming to your port, it is likely your transport provider would bill you for this traffic even though it is not bound for your router. For example, I see about 350Mbps of "junk" right now with our BGP sessions down, so if we had to pay per-Megabit for backhaul it would push that figure up for the month. If a member in this situation wanted to avoid a larger bill they would need to turn down their port in order to avoid being charged for the traffic, as deactivating BGP obviously only affects your "good" ingress and not the "junk." -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From job at instituut.net Fri Apr 8 10:31:02 2011 From: job at instituut.net (Job Snijders) Date: Fri, 8 Apr 2011 17:31:02 +0200 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: References: <4D9D8365.9060202@optilian.com> Message-ID: <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> Dear Michel, On 7 Apr 2011, at 21:30, Michel de Nostredame wrote: > On Thu, Apr 7, 2011 at 2:27 AM, Daniel STICKNEY wrote: >> I'm investigating how to setup multihoming for IPv6 over two DSL lines >> (different ISPs), and I wanted to see if this wheel has already been >> invented. Has anyone already set this up or tested it ? > > In this environment, BGP exchanges with uplink ISPs for multihoming > usually is not an option. One reason maybe cost, another reason maybe > ISP doesn't like to setup BGP with a DSL customer. At least in my > case, reason #2 always prevent my customers to setup BGP with uplink > ISPs. Agreed. Very common situation. > As Seth pointed out SHIM6 is still an academic exercise Another Locator / ID separator protocol is LISP. The advantage is that you don't need to change the host but only the CPE. I've been using it to multi-home my house and it works fine. I'm multihoming my IPv6 /48 over a v6-only DSL and a v4-only FTTH connection. More information about LISP be found here: http://www.lisp4.net/ Kind regards, Job Snijders From owen at delong.com Fri Apr 8 11:20:22 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Apr 2011 09:20:22 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <4D9F139F.6090804@ttec.com> References: <4D9D8365.9060202@optilian.com> <4D9E27A5.3040108@forthnet.gr> <01B5D224-9A81-47DC-A145-53E887928898@delong.com> <37F0E004-6596-4761-A0FE-E619EDCC89F0@delong.com> <4D9F139F.6090804@ttec.com> Message-ID: On Apr 8, 2011, at 6:54 AM, Joe Maimon wrote: > > > Owen DeLong wrote: >> >> On Apr 7, 2011, at 8:13 PM, Tom Limoncelli wrote: >> >>> On Thu, Apr 7, 2011 at 10:51 PM, Owen DeLong wrote: >>>> There is no need for NAT in order to multiple-home. BGP is every bit as effective and much simpler. >>>> >>> >>> I know a lot of small businesses with one FiOS link and one Comcast >>> link and I don't think they're going to be able to do BGP. Their >>> providers won't do it and their prem equipment doesn't support it and >>> the local IT person doesn't have the know-how to do it. I know that >>> the typical NANOG member isn't in this category, but this is a >>> use-case that is very common and outnumbers NANOG members. >>> >> I have one DSL and one Cable. Neither the DSL provider nor Comcast >> will do BGP. I do BGP just fine without them doing BGP. >> >> Owen >> > > Your use case requires at minimum a triangle, ideally a rectangle. > I'm not sure what you mean by traingle/rectangle other than the same thing that would be required for any actual multi-homing scenario. > Along for the ride comes encapsulation, overhead, additional bottlenecks and failure scenarios. The payoff has to be worth it and that usually means something more than the elimination of napt on outbound internet access, such as inbound access to bring-your-own-ip. > The encapsulation and overhead is small. In general, all of the failures experienced to date have been the result of the underlying DSL or Cable provider. I guess the value of eliminating the damage caused by NAT/NAPT/PAT/whatever you want to call the abysmal hack so many people choose to live with because they perceive a lack of options is a value each organization has to determine in their environment. In my environment, this is a very low overhead and very low cost way to solve the issue and get reliable multihoming with portable accessible addresses and avoid having to involve silly third parties in things like making a VNC connection back to one of my hosts from the road. > For anyone to do this requires beyond basic know-how and a willing 3rd point. I'll do it for a customer, but it is by no means readily available, or even ideal, so lets stop hyping it. > We can agree to disagree. I think it is readily available and I think it is a significantly better solution than NAT. Ideal? no. Ideal would be when access providers start offering cost-effective services that include dynamic routing. However, until that happens, this is the next best thing. Owen From sethm at rollernet.us Fri Apr 8 11:30:04 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 08 Apr 2011 09:30:04 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> Message-ID: <4D9F380C.30007@rollernet.us> On 4/8/11 8:31 AM, Job Snijders wrote: > >> As Seth pointed out SHIM6 is still an academic exercise > > Another Locator / ID separator protocol is LISP. The advantage is that you don't need to > change the host but only the CPE. I've been using it to multi-home my house and it works > fine. I'm multihoming my IPv6 /48 over a v6-only DSL and a v4-only FTTH connection. > > More information about LISP be found here: http://www.lisp4.net/ > Ah, I completely forgot about LISP, which reminds me, I'd wanted to set it up for fun and learning. ~Seth From owen at delong.com Fri Apr 8 11:39:19 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Apr 2011 09:39:19 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <4D9F380C.30007@rollernet.us> References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> Message-ID: <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> On Apr 8, 2011, at 9:30 AM, Seth Mattinen wrote: > On 4/8/11 8:31 AM, Job Snijders wrote: >> >>> As Seth pointed out SHIM6 is still an academic exercise >> >> Another Locator / ID separator protocol is LISP. The advantage is that you don't need to >> change the host but only the CPE. I've been using it to multi-home my house and it works >> fine. I'm multihoming my IPv6 /48 over a v6-only DSL and a v4-only FTTH connection. >> >> More information about LISP be found here: http://www.lisp4.net/ >> > > Ah, I completely forgot about LISP, which reminds me, I'd wanted to set > it up for fun and learning. > > ~Seth LISP can also be a good option. Comes with slightly more overhead in terms of encapsulation/etc. than the GRE tunnels I use and has limited (if any) functionality for IPv4 (which GRE supports nicely). Owen From ljakab at ac.upc.edu Fri Apr 8 12:34:06 2011 From: ljakab at ac.upc.edu (Lori Jakab) Date: Fri, 08 Apr 2011 19:34:06 +0200 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> Message-ID: <4D9F470E.6040904@ac.upc.edu> On 04/08/2011 06:39 PM, Owen DeLong wrote: > On Apr 8, 2011, at 9:30 AM, Seth Mattinen wrote: > >> On 4/8/11 8:31 AM, Job Snijders wrote: >>>> As Seth pointed out SHIM6 is still an academic exercise >>> Another Locator / ID separator protocol is LISP. The advantage is that you don't need to >>> change the host but only the CPE. I've been using it to multi-home my house and it works >>> fine. I'm multihoming my IPv6 /48 over a v6-only DSL and a v4-only FTTH connection. >>> >>> More information about LISP be found here: http://www.lisp4.net/ >>> >> Ah, I completely forgot about LISP, which reminds me, I'd wanted to set >> it up for fun and learning. >> >> ~Seth > LISP can also be a good option. Comes with slightly more overhead in terms of > encapsulation/etc. than the GRE tunnels I use and has limited (if any) functionality > for IPv4 (which GRE supports nicely). Maybe you meant ILNP here? AFAIK, IPv4 and IPv6 are equal citizens for LISP. Regards, -Lori Jakab > Owen > From hectorh at pobox.com Fri Apr 8 13:24:01 2011 From: hectorh at pobox.com (Hector Herrera) Date: Fri, 8 Apr 2011 11:24:01 -0700 Subject: MTS contact Message-ID: Could somebody with MTS please contact me off-list? I am not getting anywhere with their level 1 support and they won't escalate. Thanks, -- Hector Herrera Network Engineering PlayFullScreen Internet Broadcasting From cscora at apnic.net Fri Apr 8 13:39:53 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 9 Apr 2011 04:39:53 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201104081839.p38Idrxk016978@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 09 Apr, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 352501 Prefixes after maximum aggregation: 160116 Deaggregation factor: 2.20 Unique aggregates announced to Internet: 174726 Total ASes present in the Internet Routing Table: 37229 Prefixes per ASN: 9.47 Origin-only ASes present in the Internet Routing Table: 31242 Origin ASes announcing only one prefix: 15033 Transit ASes present in the Internet Routing Table: 5011 Transit-only ASes present in the Internet Routing Table: 131 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 36 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 554 Unregistered ASNs in the Routing Table: 244 Number of 32-bit ASNs allocated by the RIRs: 1270 Number of 32-bit ASNs visible in the Routing Table: 976 Prefixes from 32-bit ASNs in the Routing Table: 2181 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 179 Number of addresses announced to Internet: 2404831680 Equivalent to 143 /8s, 86 /16s and 209 /24s Percentage of available address space announced: 64.9 Percentage of allocated address space announced: 64.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 90.3 Total number of prefixes smaller than registry allocations: 145944 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 87803 Total APNIC prefixes after maximum aggregation: 29890 APNIC Deaggregation factor: 2.94 Prefixes being announced from the APNIC address blocks: 84782 Unique aggregates announced from the APNIC address blocks: 36887 APNIC Region origin ASes present in the Internet Routing Table: 4397 APNIC Prefixes per ASN: 19.28 APNIC Region origin ASes announcing only one prefix: 1218 APNIC Region transit ASes present in the Internet Routing Table: 698 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 20 Number of APNIC region 32-bit ASNs visible in the Routing Table: 47 Number of APNIC addresses announced to Internet: 605565472 Equivalent to 36 /8s, 24 /16s and 50 /24s Percentage of available APNIC address space announced: 76.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 138983 Total ARIN prefixes after maximum aggregation: 70940 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 111475 Unique aggregates announced from the ARIN address blocks: 45128 ARIN Region origin ASes present in the Internet Routing Table: 14304 ARIN Prefixes per ASN: 7.79 ARIN Region origin ASes announcing only one prefix: 5465 ARIN Region transit ASes present in the Internet Routing Table: 1487 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 11 Number of ARIN addresses announced to Internet: 797692928 Equivalent to 47 /8s, 139 /16s and 212 /24s Percentage of available ARIN address space announced: 63.4 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 83363 Total RIPE prefixes after maximum aggregation: 47605 RIPE Deaggregation factor: 1.75 Prefixes being announced from the RIPE address blocks: 76622 Unique aggregates announced from the RIPE address blocks: 50561 RIPE Region origin ASes present in the Internet Routing Table: 15488 RIPE Prefixes per ASN: 4.95 RIPE Region origin ASes announcing only one prefix: 7790 RIPE Region transit ASes present in the Internet Routing Table: 2419 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 721 Number of RIPE addresses announced to Internet: 464002432 Equivalent to 27 /8s, 168 /16s and 29 /24s Percentage of available RIPE address space announced: 74.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 32267 Total LACNIC prefixes after maximum aggregation: 7402 LACNIC Deaggregation factor: 4.36 Prefixes being announced from the LACNIC address blocks: 31330 Unique aggregates announced from the LACNIC address blocks: 16335 LACNIC Region origin ASes present in the Internet Routing Table: 1434 LACNIC Prefixes per ASN: 21.85 LACNIC Region origin ASes announcing only one prefix: 430 LACNIC Region transit ASes present in the Internet Routing Table: 259 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 192 Number of LACNIC addresses announced to Internet: 81775488 Equivalent to 4 /8s, 223 /16s and 203 /24s Percentage of available LACNIC address space announced: 54.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7630 Total AfriNIC prefixes after maximum aggregation: 1820 AfriNIC Deaggregation factor: 4.19 Prefixes being announced from the AfriNIC address blocks: 6000 Unique aggregates announced from the AfriNIC address blocks: 1858 AfriNIC Region origin ASes present in the Internet Routing Table: 442 AfriNIC Prefixes per ASN: 13.57 AfriNIC Region origin ASes announcing only one prefix: 130 AfriNIC Region transit ASes present in the Internet Routing Table: 99 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 5 Number of AfriNIC addresses announced to Internet: 22693120 Equivalent to 1 /8s, 90 /16s and 69 /24s Percentage of available AfriNIC address space announced: 33.8 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2440 9515 909 Korea Telecom (KIX) 7545 1547 301 83 TPG Internet Pty Ltd 17974 1458 480 33 PT TELEKOMUNIKASI INDONESIA 4755 1443 634 167 TATA Communications formerly 24560 1137 322 203 Bharti Airtel Ltd., Telemedia 4808 1063 2140 293 CNCGROUP IP network: China169 9583 1055 77 494 Sify Limited 9829 1003 867 56 BSNL National Internet Backbo 17488 942 162 98 Hathway IP Over Cable Interne 18101 935 116 139 Reliance Infocom Ltd Internet Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3666 3822 255 bellsouth.net, inc. 4323 2541 1090 396 Time Warner Telecom 1785 1791 681 131 PaeTec Communications, Inc. 18566 1642 335 197 Covad Communications 6478 1607 305 36 AT&T Worldnet Services 20115 1536 1551 641 Charter Communications 19262 1494 4949 297 Verizon Global Networks 7018 1354 6801 880 AT&T WorldNet Services 22773 1294 2865 84 Cox Communications, Inc. 2386 1281 538 924 AT&T Data Communications Serv Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6830 515 1780 319 UPC Distribution Services 34984 495 97 188 BILISIM TELEKOM 29049 463 34 34 AzerSat LLC. 3292 455 2013 392 TDC Tele Danmark 8866 446 134 26 Bulgarian Telecommunication C 20940 441 127 338 Akamai Technologies European 3320 419 7607 365 Deutsche Telekom AG 8551 403 353 46 Bezeq International 12479 403 577 6 Uni2 Autonomous System 702 394 1800 307 UUNET - Commercial IP service Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1417 263 156 TVCABLE BOGOTA 28573 1271 972 86 NET Servicos de Comunicao S.A 8151 1241 2679 367 UniNet S.A. de C.V. 6503 1112 354 72 AVANTEL, S.A. 7303 900 464 136 Telecom Argentina Stet-France 14420 645 52 89 CORPORACION NACIONAL DE TELEC 22047 567 310 15 VTR PUNTO NET S.A. 3816 514 225 98 Empresa Nacional de Telecomun 11172 487 99 81 Servicios Alestra S.A de C.V 27947 481 53 54 Telconet S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 839 445 11 TEDATA 24863 771 147 37 LINKdotNET AS number 15475 420 90 8 Nile Online 36992 295 287 12 Etisalat MISR 3741 266 985 227 The Internet Solution 24835 232 78 10 RAYA Telecom - Egypt 6713 231 215 12 Itissalat Al-MAGHRIB 33776 210 13 5 Starcomms Nigeria Limited 29571 191 17 11 Ci Telecom Autonomous system 16637 148 441 86 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3666 3822 255 bellsouth.net, inc. 4323 2541 1090 396 Time Warner Telecom 4766 2440 9515 909 Korea Telecom (KIX) 23456 2181 634 1179 32-bit ASN transition 1785 1791 681 131 PaeTec Communications, Inc. 18566 1642 335 197 Covad Communications 6478 1607 305 36 AT&T Worldnet Services 7545 1547 301 83 TPG Internet Pty Ltd 20115 1536 1551 641 Charter Communications 19262 1494 4949 297 Verizon Global Networks Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2541 2145 Time Warner Telecom 1785 1791 1660 PaeTec Communications, Inc. 6478 1607 1571 AT&T Worldnet Services 4766 2440 1531 Korea Telecom (KIX) 7545 1547 1464 TPG Internet Pty Ltd 18566 1642 1445 Covad Communications 17974 1458 1425 PT TELEKOMUNIKASI INDONESIA 4755 1443 1276 TATA Communications formerly 10620 1417 1261 TVCABLE BOGOTA 11492 1267 1252 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 1.3.0.0/16 38639 NTT Communications Corporatio 2.56.0.0/16 44559 E-Rent LLC 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 31.3.80.0/21 23456 32-bit ASN transition 31.3.96.0/21 35470 XL Network Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:12 /10:26 /11:74 /12:219 /13:448 /14:770 /15:1373 /16:11583 /17:5730 /18:9448 /19:19121 /20:25018 /21:25421 /22:33575 /23:32209 /24:184373 /25:1096 /26:1257 /27:683 /28:30 /29:8 /30:2 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2263 3666 bellsouth.net, inc. 18566 1620 1642 Covad Communications 6478 1561 1607 AT&T Worldnet Services 4323 1362 2541 Time Warner Telecom 10620 1307 1417 TVCABLE BOGOTA 11492 1216 1267 Cable One 23456 1127 2181 32-bit ASN transition 7011 1061 1161 Citizens Utilities 1785 1057 1791 PaeTec Communications, Inc. 6503 897 1112 AVANTEL, S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:296 2:55 4:14 5:1 8:350 12:2004 13:1 14:434 15:15 16:3 17:8 20:9 23:5 24:1601 27:702 31:213 32:60 33:3 34:2 37:1 38:752 39:1 40:101 41:2371 42:1 44:3 46:793 47:4 49:171 50:219 52:13 55:4 56:2 57:27 58:845 59:489 60:387 61:1164 62:1002 63:1921 64:3893 65:2336 66:4312 67:1805 68:1080 69:2934 70:702 71:343 72:1900 73:1 74:2327 75:284 76:336 77:852 78:688 79:458 80:1087 81:822 82:508 83:458 84:648 85:1041 86:556 87:761 88:340 89:1584 90:178 91:3678 92:497 93:1046 94:1258 95:776 96:448 97:252 98:821 99:35 101:61 106:2 107:4 108:78 109:936 110:531 111:679 112:324 113:385 114:511 115:700 116:932 117:674 118:774 119:1137 120:289 121:712 122:1621 123:1055 124:1282 125:1258 128:265 129:167 130:172 131:565 132:100 133:20 134:216 135:49 136:212 137:142 138:301 139:104 140:486 141:173 142:377 143:388 144:480 145:53 146:441 147:202 148:629 149:273 150:169 151:187 152:300 153:180 154:3 155:392 156:189 157:325 158:132 159:381 160:317 161:242 162:277 163:164 164:489 165:350 166:510 167:418 168:723 169:154 170:774 171:74 172:1 173:1257 174:535 175:349 177:77 178:834 180:806 181:7 182:416 183:200 184:240 185:1 186:1124 187:914 188:933 189:1041 190:4810 192:5776 193:4808 194:3471 195:2948 196:1206 197:17 198:3577 199:3906 200:5546 201:1474 202:8377 203:8466 204:4128 205:2323 206:2648 207:2999 208:3920 209:3505 210:2722 211:1365 212:1978 213:1717 214:732 215:66 216:4867 217:1640 218:556 219:386 220:1193 221:480 222:312 223:117 End of report From cidr-report at potaroo.net Fri Apr 8 17:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 Apr 2011 22:00:01 GMT Subject: BGP Update Report Message-ID: <201104082200.p38M0142034782@wattle.apnic.net> BGP Update Report Interval: 31-Mar-11 -to- 07-Apr-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS1785 96412 2.5% 66.9 -- AS-PAETEC-NET - PaeTec Communications, Inc. 2 - AS18566 82205 2.1% 50.0 -- COVAD - Covad Communications Co. 3 - AS47331 67869 1.7% 21.1 -- TTNET TTNet A.S. 4 - AS4323 60574 1.6% 23.6 -- TWTC - tw telecom holdings, inc. 5 - AS20115 40602 1.0% 25.6 -- CHARTER-NET-HKY-NC - Charter Communications 6 - AS11492 37284 0.9% 29.4 -- CABLEONE - CABLE ONE, INC. 7 - AS19743 33849 0.9% 4835.6 -- 8 - AS22773 31337 0.8% 24.3 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 9 - AS7011 30992 0.8% 26.4 -- FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. 10 - AS7029 27490 0.7% 16.7 -- WINDSTREAM - Windstream Communications Inc 11 - AS9498 24165 0.6% 31.2 -- BBIL-AP BHARTI Airtel Ltd. 12 - AS33475 23418 0.6% 108.9 -- RSN-1 - RockSolid Network, Inc. 13 - AS8866 23225 0.6% 45.7 -- BTC-AS Bulgarian Telecommunication Company Plc. 14 - AS852 23174 0.6% 48.3 -- ASN852 - Telus Advanced Communications 15 - AS9829 20534 0.5% 34.6 -- BSNL-NIB National Internet Backbone 16 - AS32528 17100 0.4% 2442.9 -- ABBOTT Abbot Labs 17 - AS17974 16497 0.4% 14.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 18 - AS35819 15438 0.4% 39.8 -- MOBILY-AS Etihad Etisalat Company (Mobily) 19 - AS14522 13226 0.3% 30.3 -- Satnet 20 - AS44609 13161 0.3% 4387.0 -- FNA Fars News Agency Cultural Arts Institute TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS51280 5356 0.1% 5356.0 -- AS51280 Parsian Electronic Commerce Company 2 - AS19743 33849 0.9% 4835.6 -- 3 - AS44609 13161 0.3% 4387.0 -- FNA Fars News Agency Cultural Arts Institute 4 - AS32528 17100 0.4% 2442.9 -- ABBOTT Abbot Labs 5 - AS35931 12790 0.3% 2131.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - AS27771 3497 0.1% 1748.5 -- Instituto Venezolano de Investigaciones Cientificas 7 - AS34899 1698 0.0% 1698.0 -- COASTMEDIA-NET Coast Media Network, Coast Media GmbH 8 - AS17408 3330 0.1% 1665.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 9 - AS49600 1380 0.0% 1380.0 -- LASEDA La Seda de Barcelona, S.A 10 - AS28519 2982 0.1% 994.0 -- Universidad Autonoma de Guadalajara, A.C. 11 - AS45757 3902 0.1% 975.5 -- PLX-AS-AP ASN for anycast services 12 - AS25220 10645 0.3% 887.1 -- GLOBALNOC-AS Averbo GmbH 13 - AS32050 811 0.0% 811.0 -- CUST_AS_001 Customer AS 14 - AS22206 702 0.0% 702.0 -- GOOD-SAM - Evangelical Lutheran Good Samaritan Society 15 - AS34655 1322 0.0% 661.0 -- DOCLER-AS Docler Networks Autonomus System 16 - AS9476 589 0.0% 589.0 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd. 17 - AS45310 512 0.0% 512.0 -- PISHON-SMARTNET-AS-ID SMARTNET - Broadband Internet Service. 18 - AS39079 483 0.0% 483.0 -- SFR-SI Autonomous System pour SFR SI 19 - AS13168 464 0.0% 464.0 -- SANOSTRA-AS AS de la Caja de ahorros y monte de piedad de las Baleares 20 - AS3 453 0.0% 735.0 -- APPNET-AS ApplicationNet b.v. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 85.197.100.0/22 10094 0.2% AS25220 -- GLOBALNOC-AS Averbo GmbH 2 - 202.92.235.0/24 9621 0.2% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 3 - 130.36.34.0/24 8538 0.2% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 8534 0.2% AS32528 -- ABBOTT Abbot Labs 5 - 63.211.68.0/22 7323 0.2% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - 178.22.79.0/24 6608 0.2% AS44609 -- FNA Fars News Agency Cultural Arts Institute 7 - 65.122.196.0/24 6566 0.2% AS19743 -- 8 - 178.22.72.0/21 6539 0.2% AS44609 -- FNA Fars News Agency Cultural Arts Institute 9 - 221.121.96.0/19 5777 0.1% AS7491 -- PI-PH-AS-AP PI-PHILIPINES 10 - 72.164.144.0/24 5478 0.1% AS19743 -- 11 - 66.238.91.0/24 5450 0.1% AS19743 -- 12 - 65.163.182.0/24 5450 0.1% AS19743 -- 13 - 65.162.204.0/24 5449 0.1% AS19743 -- 14 - 66.89.98.0/24 5449 0.1% AS19743 -- 15 - 212.80.25.0/24 5356 0.1% AS51280 -- AS51280 Parsian Electronic Commerce Company 16 - 198.140.43.0/24 5230 0.1% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 17 - 68.65.152.0/22 3499 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 18 - 202.153.174.0/24 3325 0.1% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 19 - 206.184.16.0/24 3317 0.1% AS174 -- COGENT Cogent/PSI 20 - 65.181.194.0/23 2846 0.1% AS11492 -- CABLEONE - CABLE ONE, INC. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Apr 8 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 Apr 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201104082200.p38M00Lv034776@wattle.apnic.net> This report has been generated at Fri Apr 8 21:12:05 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 01-04-11 354967 207769 02-04-11 354547 207833 03-04-11 354712 207935 04-04-11 354673 207973 05-04-11 354793 208485 06-04-11 355164 208933 07-04-11 355801 208937 08-04-11 355531 209315 AS Summary 37328 Number of ASes in routing system 15733 Number of ASes announcing only one prefix 3666 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 110564096 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 08Apr11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 355982 209285 146697 41.2% All ASes AS6389 3666 260 3406 92.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2532 400 2132 84.2% TWTC - tw telecom holdings, inc. AS4766 2440 921 1519 62.3% KIXS-AS-KR Korea Telecom AS6478 1607 190 1417 88.2% ATT-INTERNET3 - AT&T Services, Inc. AS22773 1294 93 1201 92.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS19262 1494 297 1197 80.1% VZGNI-TRANSIT - Verizon Online LLC AS4755 1445 358 1087 75.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1794 768 1026 57.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS18566 1642 630 1012 61.6% COVAD - Covad Communications Co. AS28573 1271 332 939 73.9% NET Servicos de Comunicao S.A. AS10620 1417 491 926 65.3% Telmex Colombia S.A. AS6503 1113 314 799 71.8% Axtel, S.A.B. de C.V. AS24560 1137 346 791 69.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7545 1549 765 784 50.6% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 936 152 784 83.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1067 325 742 69.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS8151 1241 522 719 57.9% Uninet S.A. de C.V. AS3356 1153 480 673 58.4% LEVEL3 Level 3 Communications AS7303 924 254 670 72.5% Telecom Argentina S.A. AS11492 1267 607 660 52.1% CABLEONE - CABLE ONE, INC. AS17488 942 296 646 68.6% HATHWAY-NET-AP Hathway IP Over Cable Internet AS17676 659 70 589 89.4% GIGAINFRA Softbank BB Corp. AS855 632 57 575 91.0% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS3549 936 390 546 58.3% GBLX Global Crossing Ltd. AS7552 668 124 544 81.4% VIETEL-AS-AP Vietel Corporation AS14420 645 102 543 84.2% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS22047 567 30 537 94.7% VTR BANDA ANCHA S.A. AS22561 863 334 529 61.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS17974 1458 944 514 35.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4780 716 213 503 70.3% SEEDNET Digital United Inc. Total 39075 11065 28010 71.7% Top 30 total Possible Bogus Routes 1.3.0.0/16 AS38639 HANABI NTT Communications Corporation 2.56.0.0/16 AS44559 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 24.48.0.0/14 AS5769 VIDEOTRON - Videotron Telecom Ltee 24.225.128.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/23 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.224.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.237.0/24 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.248.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 31.3.96.0/21 AS35470 XL-AS XL Network 31.3.120.0/21 AS31577 PRORED ProRed Comunicaciones Autonomous System 41.57.192.0/18 AS22750 BCSNET 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 45.127.0.0/16 AS13767 DBANK - DataBank Holdings, Ltd. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS16626 GNAXNET-AS - Global Net Access, LLC 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 148.163.0.0/20 AS3356 LEVEL3 Level 3 Communications 148.163.64.0/20 AS3356 LEVEL3 Level 3 Communications 148.163.224.0/19 AS3356 LEVEL3 Level 3 Communications 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 181.82.15.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.16.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.17.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 181.82.18.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.145.251.0/24 AS10026 PACNET Pacnet Global Ltd 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.162.200.0/22 AS39726 TRKMIR-AS Teleradiocompany MIR Ltd 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.33.84.0/22 AS9911 CONNECTPLUS-AP Singapore Telecom 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.73.0/24 AS26061 Equant Colombia 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.20.108.0/23 AS17885 JKTXLNET-AS-AP PT Excelcomindo Pratama 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.22.78.0/24 AS18117 HARBOURMSP-AU-AP Harbour MSP Pty. Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.27.123.0/24 AS4739 INTERNODE-AS Internode Pty Ltd 203.30.26.0/23 AS3491 BTN-ASN - Beyond The Network America, Inc. 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.64.240.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.241.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.242.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.243.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.244.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.247.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.105.192.0/23 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.105.196.0/23 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.105.200.0/21 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From nanog2 at adns.net Fri Apr 8 22:51:27 2011 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Fri, 8 Apr 2011 22:51:27 -0500 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? Message-ID: OK, its been a year since my Barracuda subscription expired. The unit still stops some spam. I figured that I would go and see what they would do if I tried to renew my subscription EXACTLY one year after it expired. Would their renewal website say "Oh, you are at your anniversary date", and renew me for a year? No such luck: They want me to PAY FOR AN ENTIRE YEAR for which I did NOT receive service and then for the current (upcoming year). Sorry - I don't allow myself to be ripped off like that. Sorry Barracuda - you get no money from me and I'll tell everyone I know about this policy of yours. I posted an article about this unscrupulous practice on my blog last year at http://www.john-palmer.net/wordpress/?p=46 My question is - does anyone have any suggestions for another e-mail appliance like the Barracuda Spam Firewall that doesn't try to charge their customers for time not used. I should be able to shut off the unit for a year or whatever and simply renew from the point that I re-activate the unit instead of having to pay for back-years that I didn't use. Thanks From nanog2 at adns.net Fri Apr 8 22:52:20 2011 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Fri, 8 Apr 2011 22:52:20 -0500 Subject: MTS contact References: Message-ID: <3A603DCE35E541A685B751B627779678@TAKA> MTS? Michigan Terminal System? ----- Original Message ----- From: "Hector Herrera" To: "NANOG list" Sent: Friday, April 08, 2011 1:24 PM Subject: MTS contact > Could somebody with MTS please contact me off-list? > > I am not getting anywhere with their level 1 support and they won't escalate. > > Thanks, > > -- > Hector Herrera > Network Engineering > PlayFullScreen Internet Broadcasting > > From rdobbins at arbor.net Fri Apr 8 22:56:06 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 9 Apr 2011 03:56:06 +0000 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: <240CD93A-64BF-4533-84A1-278CB3FDFBBB@arbor.net> On Apr 9, 2011, at 10:51 AM, John Palmer (NANOG Acct) wrote: > My question is - does anyone have any suggestions for another e-mail appliance like the Barracuda Spam Firewall that doesn't try to charge their customers for time not used ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From leviathan at darktech.org Fri Apr 8 23:42:23 2011 From: leviathan at darktech.org (Justin Scott) Date: Sat, 9 Apr 2011 00:42:23 -0400 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: > No such luck: They want me to PAY FOR AN ENTIRE YEAR for > which I did NOT receive service and then for the current (upcoming > year). Sorry - I don't allow myself to be ripped off like that. Hi John, this is actually a pretty common practice for service subscription models where the software and its components (spam filter rules in this case) are being continually updated. Essentially the way Barracuda sees it is that you bought the product and paid for a service contract for X period of time and they provided software and filter updates during that period. You chose not to renew, so they stopped providing updates. Now you want to renew again from today forward which means you're going to get the same benefits as customers who kept their contracts current (i.e. all the software upgrades and updated filters) without contributing to their development. Granted you didn't get them at the time they came out, but you're going to benefit NOW from work that was done at that time (the un-paid period) AND all the future updates that come out during your new renewal period. Basically, what they're saying is that if you want to get those benefits, you have to pay for them by renewing from the point where you lapsed. If a NEW customer signed on right now, they have to make an initial purchase which contributes both to the original development and potentially covers their service plan for some period as well. They're not trying to rip you off, they're just making sure everyone pays their share for those accrued benefits. You just have to look at it from the standpoint of whether it is cheaper for you to renew your service versus the initial purchase cost for a new customer with new service. Some companies won't let you renew your service at all if it's been expired for some period and force you to sign up as a new customer again, so at least they're giving you that option. Look at it from the provider's point of view and ask yourself how you would run the business and what you're trying to do will suddenly look like a potential loophole that could be abused and needs to be addressed. -Justin From jeffrey.lyon at blacklotus.net Sat Apr 9 02:19:51 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 9 Apr 2011 03:19:51 -0400 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: Juniper does this also. Jeff On Fri, Apr 8, 2011 at 11:51 PM, John Palmer (NANOG Acct) wrote: > OK, its been a year since my Barracuda subscription expired. The unit still > stops some spam. I figured that I would go and see what they would do if I > tried to renew my subscription EXACTLY one year after it expired. Would > their renewal website say "Oh, you are at your anniversary date", and renew > me for a year? > > No such luck: They want me to PAY FOR AN ENTIRE YEAR for which I did NOT > receive service and then for the current (upcoming year). Sorry - I don't > allow myself to be ripped off like that. Sorry Barracuda - you get no money > from me and I'll tell everyone I know about this policy of yours. > > I posted an article about this unscrupulous practice on my blog last year at > http://www.john-palmer.net/wordpress/?p=46 > > My question is - does anyone have any suggestions for another e-mail > appliance like the Barracuda Spam Firewall that doesn't try to charge their > customers for time not used. I should be able to shut off the unit for a > year or whatever and simply renew from the point that I re-activate the unit > instead of having to pay for back-years that I didn't use. > > Thanks > > > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From tjc at ecs.soton.ac.uk Sat Apr 9 04:30:56 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Sat, 9 Apr 2011 10:30:56 +0100 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: <240CD93A-64BF-4533-84A1-278CB3FDFBBB@arbor.net> References: <240CD93A-64BF-4533-84A1-278CB3FDFBBB@arbor.net> <31526775-F3E1-4054-8F3F-130114438051@ecs.soton.ac.uk> Message-ID: On 9 Apr 2011, at 04:56, Dobbins, Roland wrote: > > On Apr 9, 2011, at 10:51 AM, John Palmer (NANOG Acct) wrote: > >> My question is - does anyone have any suggestions for another e-mail appliance like the Barracuda Spam Firewall that doesn't try to charge their customers for time not used > > > I don't know quite how high a performance you need. If it's just email spam/viruses you are concerned with, you can run MailScanner for free, see http://www.mailscanner.info. It's been around for 10 years now and used by a lot of big organisations, many of which are listed on the web site. Written by a colleague here at University of Southampton, hence the plug. If you install and run it yourself, there's a good community mail list for support and tips. If you want a commercial version then Fort Systems (http://www.fsl.com) can do that, and they also have a companion product BarricadeMX that's a pretty decent pre-filter system. Tim From sparctacus at gmail.com Sat Apr 9 04:37:14 2011 From: sparctacus at gmail.com (Bryan Irvine) Date: Sat, 9 Apr 2011 02:37:14 -0700 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: <385CE1B4-5D95-4B01-93B5-F655CBB2624F@gmail.com> As do some states with automotive registration. It's a quite normal practice. -B On Apr 9, 2011, at 12:19 AM, Jeffrey Lyon wrote: > Juniper does this also. > > Jeff > > On Fri, Apr 8, 2011 at 11:51 PM, John Palmer (NANOG Acct) > wrote: >> OK, its been a year since my Barracuda subscription expired. The unit still >> stops some spam. I figured that I would go and see what they would do if I >> tried to renew my subscription EXACTLY one year after it expired. Would >> their renewal website say "Oh, you are at your anniversary date", and renew >> me for a year? >> >> No such luck: They want me to PAY FOR AN ENTIRE YEAR for which I did NOT >> receive service and then for the current (upcoming year). Sorry - I don't >> allow myself to be ripped off like that. Sorry Barracuda - you get no money >> from me and I'll tell everyone I know about this policy of yours. >> >> I posted an article about this unscrupulous practice on my blog last year at >> http://www.john-palmer.net/wordpress/?p=46 >> >> My question is - does anyone have any suggestions for another e-mail >> appliance like the Barracuda Spam Firewall that doesn't try to charge their >> customers for time not used. I should be able to shut off the unit for a >> year or whatever and simply renew from the point that I re-activate the unit >> instead of having to pay for back-years that I didn't use. >> >> Thanks >> >> >> >> >> >> > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions > From regnauld at nsrc.org Sat Apr 9 04:38:50 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Sat, 9 Apr 2011 09:38:50 +0000 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: <240CD93A-64BF-4533-84A1-278CB3FDFBBB@arbor.net> <31526775-F3E1-4054-8F3F-130114438051@ecs.soton.ac.uk> Message-ID: <20110409093850.GA82833@macbook.catpipe.net> Tim Chown (tjc) writes: > > I don't know quite how high a performance you need. If it's just email > spam/viruses you are concerned with, you can run MailScanner for free, > see http://www.mailscanner.info. It's been around for 10 years now and > used by a lot of big organisations, many of which are listed on the > web site. Written by a colleague here at University of Southampton, > hence the plug. If you install and run it yourself, there's a good > community mail list for support and tips. ... or just run amavisd. MailScanner used to do Bad Things with the Postfix queue, but since then I think they have fixed that, but I will admit to not having any experience with it. As to amavisd: http://www.ijs.si/software/amavisd/ Have been using it on 1 million mails / day with satisfaction From job at instituut.net Sat Apr 9 06:31:16 2011 From: job at instituut.net (Job Snijders) Date: Sat, 9 Apr 2011 13:31:16 +0200 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <4D9F470E.6040904@ac.upc.edu> References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> Message-ID: <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> Dear All, On 8 Apr 2011, at 19:34, Lori Jakab wrote: > On 04/08/2011 06:39 PM, Owen DeLong wrote: >> LISP can also be a good option. Comes with slightly more overhead in terms of >> encapsulation/etc. than the GRE tunnels I use and has limited (if any) functionality >> for IPv4 (which GRE supports nicely). > > Maybe you meant ILNP here? AFAIK, IPv4 and IPv6 are equal citizens for LISP. Comparing GRE with LISP is like comparing /etc/hosts with the global DNS system. ;-) I don't understand the comments about LISP and IPv4. IPv4 works just excellent with LISP. I have a IPv4 block at home which I multi-home over my IPv6-only DSL and IPv4-only FTTH line. LISP is pretty address family agnostic: IPv4 over IPv4, IPv4 over IPv6, IPv6 over IPv4, IPv6 over IPv6, all work without problems. Kind regards, Job From jra at baylink.com Sat Apr 9 07:36:10 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 9 Apr 2011 08:36:10 -0400 (EDT) Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: Message-ID: <14371001.2059.1302352570502.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jeffrey Lyon" [ Charging back rent on your appliance ] > Juniper does this also. To pick a slightly different milieu, the Zimbra email system does not; if you let your support contract lapse, you simply aren't entitled to support while it's inactive. Or at least, that's how it was while I cared. :-) Cheers, -- jra From rsk at gsp.org Sat Apr 9 07:40:31 2011 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 9 Apr 2011 08:40:31 -0400 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: <20110409124031.GA6488@gsp.org> It's quite easy to build your own [out of open-source components] that easily outperforms any appliance on the market. (Which isn't saying much: none of them are very good, and all of them are way overpriced. The bar is thus set quite low.) It will not have all the superfluous bells and whistles that marketing departments are so fond of hyping, but it will work, it will be cheap, it will be scalable, and it will be far more secure. I've discussed this at some length on mailop and am in the process of reducing it to near-cookbook form. If you're interested, contact me offlist and I'll outline it for you. ---rsk From tshaw at oitc.com Sat Apr 9 07:41:31 2011 From: tshaw at oitc.com (TR Shaw) Date: Sat, 9 Apr 2011 08:41:31 -0400 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: On Apr 8, 2011, at 11:51 PM, John Palmer (NANOG Acct) wrote: > OK, its been a year since my Barracuda subscription expired. The unit still stops some spam. I figured that I would go and see what they would do if I tried to renew my subscription EXACTLY one year after it expired. Would their renewal website say "Oh, you are at your anniversary date", and renew me for a year? > > No such luck: They want me to PAY FOR AN ENTIRE YEAR for which I did NOT receive service and then for the current (upcoming year). Sorry - I don't allow myself to be ripped off like that. Sorry Barracuda - you get no money from me and I'll tell everyone I know about this policy of yours. > > I posted an article about this unscrupulous practice on my blog last year at http://www.john-palmer.net/wordpress/?p=46 > > My question is - does anyone have any suggestions for another e-mail appliance like the Barracuda Spam Firewall that doesn't try to charge their customers for time not used. I should be able to shut off the unit for a year or whatever and simply renew from the point that I re-activate the unit instead of having to pay for back-years that I didn't use. Get a linux box or whatever and roll your own. ASSP, DSPAM, Spamassin, or other open source Tom From owen at delong.com Sat Apr 9 09:00:18 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 9 Apr 2011 07:00:18 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> Message-ID: <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> Sent from my iPad On Apr 9, 2011, at 4:31 AM, Job Snijders wrote: > Dear All, > > On 8 Apr 2011, at 19:34, Lori Jakab wrote: > >> On 04/08/2011 06:39 PM, Owen DeLong wrote: > >>> LISP can also be a good option. Comes with slightly more overhead in terms of >>> encapsulation/etc. than the GRE tunnels I use and has limited (if any) functionality >>> for IPv4 (which GRE supports nicely). >> >> Maybe you meant ILNP here? AFAIK, IPv4 and IPv6 are equal citizens for LISP. > > Comparing GRE with LISP is like comparing /etc/hosts with the global DNS system. ;-) > > I don't understand the comments about LISP and IPv4. IPv4 works just excellent with LISP. I have a IPv4 block at home which I multi-home over my IPv6-only DSL and IPv4-only FTTH line. > > LISP is pretty address family agnostic: IPv4 over IPv4, IPv4 over IPv6, IPv6 over IPv4, IPv6 over IPv6, all work without problems. > > Kind regards, > > Job Doing IPv4 LISP on any kind of scale requires significant additional prefixes which at this time doesn't seem so practical to me. Owen From trelane at trelane.net Sat Apr 9 09:39:10 2011 From: trelane at trelane.net (Andrew Kirch) Date: Sat, 09 Apr 2011 10:39:10 -0400 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: <4DA06F8E.6080200@trelane.net> John, My suggestion isn't _QUITE_ an appliance, but it works very well and I've been exceptionally happy with it. It's a distribution of linux controlled via a web interface that does far more than just mail filtering (at which it is both flexible and adept). Take a look at http://www.clearfoundation.com/Software/overview.html. The hardware requirements shouldn't be too insane, and the rules updates/subscriptions for the various services are all month to month, and not a bucket of insane. Andrew On 4/8/2011 11:51 PM, John Palmer (NANOG Acct) wrote: > OK, its been a year since my Barracuda subscription expired. The unit > still stops some spam. I figured that I would go and see what they > would do if I tried to renew my subscription EXACTLY one year after it > expired. Would their renewal website say "Oh, you are at your > anniversary date", and renew me for a year? > > No such luck: They want me to PAY FOR AN ENTIRE YEAR for which I did > NOT receive service and then for the current (upcoming year). Sorry - > I don't allow myself to be ripped off like that. Sorry Barracuda - you > get no money from me and I'll tell everyone I know about this policy > of yours. > > I posted an article about this unscrupulous practice on my blog last > year at http://www.john-palmer.net/wordpress/?p=46 > > My question is - does anyone have any suggestions for another e-mail > appliance like the Barracuda Spam Firewall that doesn't try to charge > their customers for time not used. I should be able to shut off the > unit for a year or whatever and simply renew from the point that I > re-activate the unit instead of having to pay for back-years that I > didn't use. > > Thanks > > > > > From proth at cnsny.net Sat Apr 9 10:55:52 2011 From: proth at cnsny.net (=?utf-8?B?cHJvdGhAY25zbnkubmV0?=) Date: Sat, 09 Apr 2011 11:55:52 -0400 Subject: =?utf-8?B?UmU6IEJhcnJhY3VkYSBOZXR3b3JrcyBpcyBhdCBpdCBhZ2FpbjogQW55IFN1Z2dlc3Rpb25zIGFzIHRvCWFuCUFsdGVybmF0aXZlPw==?= Message-ID: Andrew, We use and offer Postini - a front end service. Postini is a anti virus and spam filter, and can spool mail if your circuits are down. Postini is a Google company and works like a charm. If you need more information please contact me offline proth at cnsny.net Paul Sent from my Verizon Wireless Phone ----- Reply message ----- From: "Andrew Kirch" Date: Sat, Apr 9, 2011 10:39 am Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? To: "John Palmer (NANOG Acct)" , John, My suggestion isn't _QUITE_ an appliance, but it works very well and I've been exceptionally happy with it. It's a distribution of linux controlled via a web interface that does far more than just mail filtering (at which it is both flexible and adept). Take a look at http://www.clearfoundation.com/Software/overview.html. The hardware requirements shouldn't be too insane, and the rules updates/subscriptions for the various services are all month to month, and not a bucket of insane. Andrew On 4/8/2011 11:51 PM, John Palmer (NANOG Acct) wrote: > OK, its been a year since my Barracuda subscription expired. The unit > still stops some spam. I figured that I would go and see what they > would do if I tried to renew my subscription EXACTLY one year after it > expired. Would their renewal website say "Oh, you are at your > anniversary date", and renew me for a year? > > No such luck: They want me to PAY FOR AN ENTIRE YEAR for which I did > NOT receive service and then for the current (upcoming year). Sorry - > I don't allow myself to be ripped off like that. Sorry Barracuda - you > get no money from me and I'll tell everyone I know about this policy > of yours. > > I posted an article about this unscrupulous practice on my blog last > year at http://www.john-palmer.net/wordpress/?p=46 > > My question is - does anyone have any suggestions for another e-mail > appliance like the Barracuda Spam Firewall that doesn't try to charge > their customers for time not used. I should be able to shut off the > unit for a year or whatever and simply renew from the point that I > re-activate the unit instead of having to pay for back-years that I > didn't use. > > Thanks > > > > > From richih.mailinglist at gmail.com Sat Apr 9 11:32:44 2011 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sat, 9 Apr 2011 18:32:44 +0200 Subject: Introducing draft-hartmann-6man-addresspartnaming (was: draft-denog-v6ops-addresspartnaming) Message-ID: Dear all, you might still remember draft-denog-v6ops-addresspartnaming [1] being announced on this list [2]. After an extensive period of gathering feedback and both a change in name and IETF Working Group, I am pleased to announce the new draft-hartmann-6man-addresspartnaming [3]. Taking the broad consensus into account, we are reasonably expecting hextet to come out as the only option. The only remaining questions are: 1) MAY 'quibble' be allowed as an optional name? I think not, but we were not 100% in agreement and thus decided to pop the question to the IETF and operator communities at large. 2) MUST or SHOULD 'hextet" be used in all written documentation? 3) Is this a Proposed Standard or already a Best Current Practice, given that a lot of people swtiched, already? I am looking forward to any and all feedback, either on this or the 6man list [4]. Thanks, Richard [1] http://tools.ietf.org/html/draft-denog-v6ops-addresspartnaming [2] http://mailman.nanog.org/pipermail/nanog/2010-November/027920.html [3] http://tools.ietf.org/html/draft-hartmann-6man-addresspartnaming [4] http://www.ietf.org/mail-archive/web/ipv6/current/msg13805.html From MRunkel at untangle.com Sat Apr 9 11:46:30 2011 From: MRunkel at untangle.com (Marc Runkel) Date: Sat, 9 Apr 2011 09:46:30 -0700 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: <48A405A1-AD7D-4A36-978B-8087B930F2DA@untangle.com> Ok, shameless plug here, but I invite you to check out our product @ www.untangle.com. Base product (including anti-spam) is free. If you want support/web filtering/ or better spam rules they are available as premium add-ons. Marc Runkel Untangle, Inc. Director, Technical Operations (650) 425-3333 direct (650) 345-3788 fax On Apr 8, 2011, at 8:51 PM, John Palmer (NANOG Acct) wrote: OK, its been a year since my Barracuda subscription expired. The unit still stops some spam. I figured that I would go and see what they would do if I tried to renew my subscription EXACTLY one year after it expired. Would their renewal website say "Oh, you are at your anniversary date", and renew me for a year? No such luck: They want me to PAY FOR AN ENTIRE YEAR for which I did NOT receive service and then for the current (upcoming year). Sorry - I don't allow myself to be ripped off like that. Sorry Barracuda - you get no money from me and I'll tell everyone I know about this policy of yours. I posted an article about this unscrupulous practice on my blog last year at http://www.john-palmer.net/wordpress/?p=46 My question is - does anyone have any suggestions for another e-mail appliance like the Barracuda Spam Firewall that doesn't try to charge their customers for time not used. I should be able to shut off the unit for a year or whatever and simply renew from the point that I re-activate the unit instead of having to pay for back-years that I didn't use. Thanks From mwelch at tallshorts.com Sun Apr 10 01:02:10 2011 From: mwelch at tallshorts.com (Matthew Welch) Date: Sun, 10 Apr 2011 01:02:10 -0500 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: <48A405A1-AD7D-4A36-978B-8087B930F2DA@untangle.com> References: <48A405A1-AD7D-4A36-978B-8087B930F2DA@untangle.com> Message-ID: At Sunflower, we use Ironports for our mail filtering. Have been really happy with the product. The reason you explained is a reason we didn't go with Barracuda. On Sat, Apr 9, 2011 at 11:46 AM, Marc Runkel wrote: > Ok, shameless plug here, but I invite you to check out our product @ > www.untangle.com. Base product (including > anti-spam) is free. If you want support/web filtering/ or better spam > rules they are available as premium add-ons. > > Marc Runkel > Untangle, Inc. > Director, Technical Operations > > (650) 425-3333 direct > (650) 345-3788 fax > > On Apr 8, 2011, at 8:51 PM, John Palmer (NANOG Acct) wrote: > > OK, its been a year since my Barracuda subscription expired. The unit still > stops some spam. I figured that I would go and see what > they would do if I tried to renew my subscription EXACTLY one year after it > expired. Would their renewal website say "Oh, you are at > your anniversary date", and renew me for a year? > > No such luck: They want me to PAY FOR AN ENTIRE YEAR for which I did NOT > receive service and then for the current (upcoming year). > Sorry - I don't allow myself to be ripped off like that. Sorry Barracuda - > you get no money from me and I'll tell everyone I know > about this policy of yours. > > I posted an article about this unscrupulous practice on my blog last year > at http://www.john-palmer.net/wordpress/?p=46 > > My question is - does anyone have any suggestions for another e-mail > appliance like the Barracuda Spam Firewall that doesn't try to > charge their customers for time not used. I should be able to shut off the > unit for a year or whatever and simply renew from the > point that I re-activate the unit instead of having to pay for back-years > that I didn't use. > > Thanks > > > > > > > From esavage at digitalrage.org Sun Apr 10 07:46:11 2011 From: esavage at digitalrage.org (Elijah Savage) Date: Sun, 10 Apr 2011 08:46:11 -0400 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: FreeBSD, Postfix, Amavisd, Spamassassin, Clamav and TLS I have seen and deployed this combination as a mail relay to exchange both in and out of large organizations 35,000 plus hosting multiple domains as well as small organizations. With a few scripts it is essentially self containing very little maintenance. On Apr 8, 2011, at 11:51 PM, John Palmer (NANOG Acct) wrote: > OK, its been a year since my Barracuda subscription expired. The unit still stops some spam. I figured that I would go and see what they would do if I tried to renew my subscription EXACTLY one year after it expired. Would their renewal website say "Oh, you are at your anniversary date", and renew me for a year? > > No such luck: They want me to PAY FOR AN ENTIRE YEAR for which I did NOT receive service and then for the current (upcoming year). Sorry - I don't allow myself to be ripped off like that. Sorry Barracuda - you get no money from me and I'll tell everyone I know about this policy of yours. > > I posted an article about this unscrupulous practice on my blog last year at http://www.john-palmer.net/wordpress/?p=46 > > My question is - does anyone have any suggestions for another e-mail appliance like the Barracuda Spam Firewall that doesn't try to charge their customers for time not used. I should be able to shut off the unit for a year or whatever and simply renew from the point that I re-activate the unit instead of having to pay for back-years that I didn't use. > > Thanks > > > > > From fredr at geexology.org Sun Apr 10 07:58:47 2011 From: fredr at geexology.org (Fred Richards) Date: Sun, 10 Apr 2011 08:58:47 -0400 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: <20cf3071ce10681f2504a08ff92a@google.com> References: <20cf3071ce10681f2504a08ff92a@google.com> Message-ID: Because I don't need any of the cute and fluffy features like a quarantine spambox, I just use the barracuda rbl along with a few others. You get their filtering power for free and don't have to deal with the hardware, if you don't particularly like it. http://www.barracudacentral.org/ -- ? ? ? ? ? ? ? ? ? ? ? Fred From Joel.Snyder at Opus1.COM Sun Apr 10 07:59:43 2011 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Sun, 10 Apr 2011 14:59:43 +0200 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: <4DA1A9BF.6070109@opus1.com> > It's quite easy to build your own [out of open-source components] that > easily outperforms any appliance on the market. (Which isn't saying > much: none of them are very good, and all of them are way overpriced. > The bar is thus set quite low.) It will not have all the superfluous > bells and whistles that marketing departments are so fond of hyping, > but it will work, it will be cheap, it will be scalable, and it will be > far more secure. Is there any aspect of this screed that you can support with data, preferably data published this decade? Of course, I understand that "overpriced" and "superfluous bells and whistles" and "far more secure" are fairly subjective criteria, but numbers such as efficacy and specificity are easy to compare. I'd also be interested in hearing about any cases where someone compromised a production Barracuda, Ironport, or similar appliance--or does your definition of "far more secure" include other substantive components that matter more? > I've discussed this at some length on mailop and am in the process of > reducing it to near-cookbook form. If you're interested, contact me > offlist and I'll outline it for you. I'd be interested in seeing you put your money where your mouth is regarding catch rate and false positive rate. Contact me off-list with a place where I can FTP a VM of one of your appliances. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From tom at dyn.com Sun Apr 10 08:24:39 2011 From: tom at dyn.com (Tom Daly) Date: Sun, 10 Apr 2011 09:24:39 -0400 (EDT) Subject: [NANOG-announce] NANOG 52 CFP Reminder: Slides due 4/11 Message-ID: <16402180.37.1302441878760.JavaMail.tom@Tom-Dalys-MacBook-Pro.local> NANOG'ers, On Thursday, 4/14, the NANOG Program Committee will meet to review submissions for NANOG 52. In an effort to get a topic list our the community as early as requested (tentative for 4/15), we do need to have all abstracts and slide submissions in as soon as possible. A quick review of the PC tool indicates that we don't have enough content for the meeting yet, so please submit your work ASAP! You can submit your abstract, or upload your slides at https://pc.nanog.org. Have a good weekend, Tom Daly, for the NANOG PC _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From gbonser at seven.com Sun Apr 10 16:44:53 2011 From: gbonser at seven.com (George Bonser) Date: Sun, 10 Apr 2011 14:44:53 -0700 Subject: GMail contact needed Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E2CE1@RWC-EX1.corp.seven.com> I am having an ongoing operational issue with imap.gmail.com that began at 1250 PDT It appears that connectivity has been blocked from certain of our operational IPs and IMAPs returns "Service Forbidden" for all connection attempts and we have some other issues on other protocols (pop3s, imaps) that started at exactly that time . Offlist response appreciated. From joshua.klubi at gmail.com Sun Apr 10 17:07:06 2011 From: joshua.klubi at gmail.com (Joshua Klubi) Date: Sun, 10 Apr 2011 22:07:06 +0000 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: The best of them is A.S.S.P. and it works wonder I have deployed a couple and I love it Sent from my iPhone On Apr 10, 2011, at 12:46, Elijah Savage wrote: > FreeBSD, Postfix, Amavisd, Spamassassin, Clamav and TLS > > I have seen and deployed this combination as a mail relay to exchange both in and out of large organizations 35,000 plus hosting multiple domains as well as small organizations. With a few scripts it is essentially self containing very little maintenance. > > On Apr 8, 2011, at 11:51 PM, John Palmer (NANOG Acct) wrote: > >> OK, its been a year since my Barracuda subscription expired. The unit still stops some spam. I figured that I would go and see what they would do if I tried to renew my subscription EXACTLY one year after it expired. Would their renewal website say "Oh, you are at your anniversary date", and renew me for a year? >> >> No such luck: They want me to PAY FOR AN ENTIRE YEAR for which I did NOT receive service and then for the current (upcoming year). Sorry - I don't allow myself to be ripped off like that. Sorry Barracuda - you get no money from me and I'll tell everyone I know about this policy of yours. >> >> I posted an article about this unscrupulous practice on my blog last year at http://www.john-palmer.net/wordpress/?p=46 >> >> My question is - does anyone have any suggestions for another e-mail appliance like the Barracuda Spam Firewall that doesn't try to charge their customers for time not used. I should be able to shut off the unit for a year or whatever and simply renew from the point that I re-activate the unit instead of having to pay for back-years that I didn't use. >> >> Thanks >> >> >> >> >> > > From tshaw at oitc.com Sun Apr 10 17:32:50 2011 From: tshaw at oitc.com (TR Shaw) Date: Sun, 10 Apr 2011 18:32:50 -0400 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: <5478EA55-BFF1-41AB-8CF2-EEFA1D703E93@oitc.com> I agree. Simple clean perl proxy. Lots of GUI config. Can use ClamAV and other AV systems. Easy to deploy. Is no brainer to manage. Comes in single and multithreaded. Your call. I get a lot of email through the single thread version. Handles TLS and more. http://sourceforge.net/projects/assp/files/ On Apr 10, 2011, at 6:07 PM, Joshua Klubi wrote: > The best of them is A.S.S.P. and it works wonder I have deployed a couple and I love it > > Sent from my iPhone > > On Apr 10, 2011, at 12:46, Elijah Savage wrote: > >> FreeBSD, Postfix, Amavisd, Spamassassin, Clamav and TLS >> >> I have seen and deployed this combination as a mail relay to exchange both in and out of large organizations 35,000 plus hosting multiple domains as well as small organizations. With a few scripts it is essentially self containing very little maintenance. >> >> On Apr 8, 2011, at 11:51 PM, John Palmer (NANOG Acct) wrote: >> >>> OK, its been a year since my Barracuda subscription expired. The unit still stops some spam. I figured that I would go and see what they would do if I tried to renew my subscription EXACTLY one year after it expired. Would their renewal website say "Oh, you are at your anniversary date", and renew me for a year? >>> >>> No such luck: They want me to PAY FOR AN ENTIRE YEAR for which I did NOT receive service and then for the current (upcoming year). Sorry - I don't allow myself to be ripped off like that. Sorry Barracuda - you get no money from me and I'll tell everyone I know about this policy of yours. >>> >>> I posted an article about this unscrupulous practice on my blog last year at http://www.john-palmer.net/wordpress/?p=46 >>> >>> My question is - does anyone have any suggestions for another e-mail appliance like the Barracuda Spam Firewall that doesn't try to charge their customers for time not used. I should be able to shut off the unit for a year or whatever and simply renew from the point that I re-activate the unit instead of having to pay for back-years that I didn't use. >>> >>> Thanks >>> >>> >>> >>> >>> >> >> > From hescominsoon at emmanuelcomputerconsulting.com Sun Apr 10 19:24:16 2011 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Sun, 10 Apr 2011 20:24:16 -0400 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: <48A405A1-AD7D-4A36-978B-8087B930F2DA@untangle.com> References: <48A405A1-AD7D-4A36-978B-8087B930F2DA@untangle.com> Message-ID: <4DA24A30.7000101@emmanuelcomputerconsulting.com> On 4/9/2011 12:46 PM, Marc Runkel wrote: > Ok, shameless plug here, but I invite you to check out our product @ www.untangle.com. Base product (including anti-spam) is free. If you want support/web filtering/ or better spam rules they are available as premium add-ons. > > Marc Runkel > Untangle, Inc. > Director, Technical Operations > > (650) 425-3333 direct > (650) 345-3788 fax > > On Apr 8, 2011, at 8:51 PM, John Palmer (NANOG Acct) wrote: > > OK, its been a year since my Barracuda subscription expired. The unit still stops some spam. I figured that I would go and see what > they would do if I tried to renew my subscription EXACTLY one year after it expired. Would their renewal website say "Oh, you are at > your anniversary date", and renew me for a year? > > No such luck: They want me to PAY FOR AN ENTIRE YEAR for which I did NOT receive service and then for the current (upcoming year). > Sorry - I don't allow myself to be ripped off like that. Sorry Barracuda - you get no money from me and I'll tell everyone I know > about this policy of yours. > > I posted an article about this unscrupulous practice on my blog last year at http://www.john-palmer.net/wordpress/?p=46 > > My question is - does anyone have any suggestions for another e-mail appliance like the Barracuda Spam Firewall that doesn't try to > charge their customers for time not used. I should be able to shut off the unit for a year or whatever and simply renew from the > point that I re-activate the unit instead of having to pay for back-years that I didn't use. > > Thanks > > > > > > Untangle's free version...isn't worth the bandwidth. The paid version is ok..but it's a resource hog. From gbonser at seven.com Sun Apr 10 19:27:12 2011 From: gbonser at seven.com (George Bonser) Date: Sun, 10 Apr 2011 17:27:12 -0700 Subject: GMail contact needed In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E2CE1@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0C9E2CE1@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E2CE5@RWC-EX1.corp.seven.com> > > I am having an ongoing operational issue with imap.gmail.com that began > at 1250 PDT > > It appears that connectivity has been blocked from certain of our > operational IPs and IMAPs returns "Service Forbidden" for all > connection > attempts and we have some other issues on other protocols (pop3s, > imaps) > that started at exactly that time . > > Offlist response appreciated. Issue cleared at 1650 PDT, never did hear anything from Google. From jra at baylink.com Sun Apr 10 19:35:24 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 10 Apr 2011 20:35:24 -0400 (EDT) Subject: GMail contact needed In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E2CE5@RWC-EX1.corp.seven.com> Message-ID: <33132703.2157.1302482124399.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "George Bonser" > > I am having an ongoing operational issue with imap.gmail.com that began > > at 1250 PDT > > > > It appears that connectivity has been blocked from certain of our > > operational IPs and IMAPs returns "Service Forbidden" for all > > connection attempts and we have some other issues on other protocols (pop3s, > > imaps) that started at exactly that time . > > > > Offlist response appreciated. > > Issue cleared at 1650 PDT, never did hear anything from Google. "The trouble's leaving here fine!" Cheers, -- jra From cmaurand at xyonet.com Sun Apr 10 22:25:11 2011 From: cmaurand at xyonet.com (Curtis Maurand) Date: Sun, 10 Apr 2011 23:25:11 -0400 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: <4DA24A30.7000101@emmanuelcomputerconsulting.com> References: <48A405A1-AD7D-4A36-978B-8087B930F2DA@untangle.com> <4DA24A30.7000101@emmanuelcomputerconsulting.com> Message-ID: <4DA27497.8030502@xyonet.com> A barracuda appliance uses postfix, amavisd-new, spamassassin with fuzzyOCR and clamav. I've built a couple of these boxes for customers. I use their dnsbl as well as spamhaus. It works pretty well, not much gets through. --Curtis On 4/10/2011 8:24 PM, William Warren wrote: > On 4/9/2011 12:46 PM, Marc Runkel wrote: >> Ok, shameless plug here, but I invite you to check out our product @ >> www.untangle.com. Base product (including >> anti-spam) is free. If you want support/web filtering/ or better >> spam rules they are available as premium add-ons. >> >> Marc Runkel >> Untangle, Inc. >> Director, Technical Operations >> >> (650) 425-3333 direct >> (650) 345-3788 fax >> >> On Apr 8, 2011, at 8:51 PM, John Palmer (NANOG Acct) wrote: >> >> OK, its been a year since my Barracuda subscription expired. The unit >> still stops some spam. I figured that I would go and see what >> they would do if I tried to renew my subscription EXACTLY one year >> after it expired. Would their renewal website say "Oh, you are at >> your anniversary date", and renew me for a year? >> >> No such luck: They want me to PAY FOR AN ENTIRE YEAR for which I did >> NOT receive service and then for the current (upcoming year). >> Sorry - I don't allow myself to be ripped off like that. Sorry >> Barracuda - you get no money from me and I'll tell everyone I know >> about this policy of yours. >> >> I posted an article about this unscrupulous practice on my blog last >> year at http://www.john-palmer.net/wordpress/?p=46 >> >> My question is - does anyone have any suggestions for another e-mail >> appliance like the Barracuda Spam Firewall that doesn't try to >> charge their customers for time not used. I should be able to shut >> off the unit for a year or whatever and simply renew from the >> point that I re-activate the unit instead of having to pay for >> back-years that I didn't use. >> >> Thanks >> >> >> >> >> >> > Untangle's free version...isn't worth the bandwidth. The paid version > is ok..but it's a resource hog. > From rcorbin at traffiq.com Mon Apr 11 00:21:43 2011 From: rcorbin at traffiq.com (Ray Corbin) Date: Mon, 11 Apr 2011 00:21:43 -0500 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: <4101EDF67E13AB49BA5564A8E7E2C03C12CAE3DBBB@34093-MBX-C18.mex07a.mlsrvr.com> I also use postini and it works really well for my current needs. I had experience with Barracuda as outbound anti-spam filters for a very large hosting provider and I won't use Barracuda again. Some of their methods for blocking spam are a tad extreme. At one point they decided to block both yahoo.com and google.com in their domain filters because neither company responded timely to their complaint emails and wanted their attention...not to mention their buggy 'spam engine' that died many times causing mail to error with 'failure to connect to 127.0.0.1'... I especially loved their tier 1's response of how the issue is on the recipients end because they couldn't telnet to mail.domain.com from their workstation...I had to first explain how mail.domain.com wasn?t the MX record for domain.com (it ironically was a postini MX record) and that it was obvious when thousands of messages sit in the inbound queue saying 'failure to connect to 127.0.0.1' meant their engine died and their 'watchdog' process failed to restart it. To me their Tier 1 unable to do the basics was pretty unacceptable. -r -----Original Message----- From: proth at cnsny.net [mailto:proth at cnsny.net] Sent: Saturday, April 09, 2011 11:56 AM To: Andrew Kirch; John Palmer (NANOG Acct); nanog at nanog.org Subject: Re: Barracuda Networks is at it again: Any Suggestions as to an Alternative? Andrew, We use and offer Postini - a front end service. Postini is a anti virus and spam filter, and can spool mail if your circuits are down. Postini is a Google company and works like a charm. If you need more information please contact me offline proth at cnsny.net Paul Sent from my Verizon Wireless Phone ----- Reply message ----- From: "Andrew Kirch" Date: Sat, Apr 9, 2011 10:39 am Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? To: "John Palmer (NANOG Acct)" , John, My suggestion isn't _QUITE_ an appliance, but it works very well and I've been exceptionally happy with it. It's a distribution of linux controlled via a web interface that does far more than just mail filtering (at which it is both flexible and adept). Take a look at http://www.clearfoundation.com/Software/overview.html. The hardware requirements shouldn't be too insane, and the rules updates/subscriptions for the various services are all month to month, and not a bucket of insane. Andrew On 4/8/2011 11:51 PM, John Palmer (NANOG Acct) wrote: > OK, its been a year since my Barracuda subscription expired. The unit > still stops some spam. I figured that I would go and see what they > would do if I tried to renew my subscription EXACTLY one year after it > expired. Would their renewal website say "Oh, you are at your > anniversary date", and renew me for a year? > > No such luck: They want me to PAY FOR AN ENTIRE YEAR for which I did > NOT receive service and then for the current (upcoming year). Sorry - > I don't allow myself to be ripped off like that. Sorry Barracuda - you > get no money from me and I'll tell everyone I know about this policy > of yours. > > I posted an article about this unscrupulous practice on my blog last > year at http://www.john-palmer.net/wordpress/?p=46 > > My question is - does anyone have any suggestions for another e-mail > appliance like the Barracuda Spam Firewall that doesn't try to charge > their customers for time not used. I should be able to shut off the > unit for a year or whatever and simply renew from the point that I > re-activate the unit instead of having to pay for back-years that I > didn't use. > > Thanks > > > > > From Joel.Snyder at Opus1.COM Mon Apr 11 01:16:36 2011 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Mon, 11 Apr 2011 08:16:36 +0200 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative In-Reply-To: References: Message-ID: <4DA29CC4.6020704@opus1.com> > You get their filtering power for free and don't have to deal with the > hardware, if you don't particularly like it. > > http://www.barracudacentral.org/ That's not completely true; the Barracuda appliance uses both block-lists and content-based filtering. The block-list is free for anyone who wants it, but the content-based filtering is not. However, the block-list *is* now one of the best ones out there. They had a rocky start, but in the last year they have consistently outperformed most of the other no-charge block-lists both in terms of catch rate and false positive rate. Spamhaus has long been one of my favorites for its performance, but I am now seeing Barracuda beat them each month in catch rate, sometimes by a nice margin. (FP rate for both lists is about the same; VERY close to zero.) If you like Spamhaus, you should try Barracuda block-list and see if it helps in your mail stream. (Every stream is different, so my results may not match your results.) jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From gordslater at ieee.org Mon Apr 11 03:37:05 2011 From: gordslater at ieee.org (gord) Date: Mon, 11 Apr 2011 09:37:05 +0100 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: <4101EDF67E13AB49BA5564A8E7E2C03C12CAE3DBBB@34093-MBX-C18.mex07a.mlsrvr.com> References: <4101EDF67E13AB49BA5564A8E7E2C03C12CAE3DBBB@34093-MBX-C18.mex07a.mlsrvr.com> Message-ID: <1302511025.1423.7.camel@g2> I wonder if there's a filter for top-postings in list that have a bottom-posting rule? This thread is very operationally interesting to me but I've lost the plot :( http://www.nanog.org/mailinglist/listfaqs/generalfaq.php?qt=convent refers. PS: I know that some devices actually prevent bottom-posting by default. Workarounds are possible and are evident in other recent posts to this list. Additionally, may I suggest you file a bug report with your vendors or switch to a device that you can control properly :) -- CTRL-d From tvhawaii at shaka.com Mon Apr 11 04:11:44 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Sun, 10 Apr 2011 23:11:44 -1000 Subject: Barracuda Networks is at it again: Any Suggestions as to anAlternative? References: <4101EDF67E13AB49BA5564A8E7E2C03C12CAE3DBBB@34093-MBX-C18.mex07a.mlsrvr.com> <1302511025.1423.7.camel@g2> Message-ID: <2C81C7AD62B2450DACAC1ADB88CF4226@DELL16> gord wrote: > I wonder if there's a filter for top-postings in list that have a > bottom-posting rule? > This thread is very operationally interesting to me but I've lost the > plot :( > > http://www.nanog.org/mailinglist/listfaqs/generalfaq.php?qt=convent > refers. > > PS: I know that some devices actually prevent bottom-posting by default. > Workarounds are possible and are evident in other recent posts to this > list. > Additionally, may I suggest you file a bug report with your vendors or > switch to a device that you can control properly :) It makes the thread very hard to follow. > Why not? >> Please don't top post! I used to have this available for a 'signature', but, with a few exceptions, it seems to fall on blind eyes these days. From unix at 64bit.co.za Mon Apr 11 05:10:28 2011 From: unix at 64bit.co.za (Gabriel Marais) Date: Mon, 11 Apr 2011 12:10:28 +0200 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: <20110409093850.GA82833@macbook.catpipe.net> References: <240CD93A-64BF-4533-84A1-278CB3FDFBBB@arbor.net> <31526775-F3E1-4054-8F3F-130114438051@ecs.soton.ac.uk> <20110409093850.GA82833@macbook.catpipe.net> Message-ID: <4DA2D394.5030308@64bit.co.za> On 2011/04/09 11:38 AM, Phil Regnauld wrote: > Tim Chown (tjc) writes: >> >> I don't know quite how high a performance you need. If it's just email >> spam/viruses you are concerned with, you can run MailScanner for free, >> see http://www.mailscanner.info. It's been around for 10 years now and >> used by a lot of big organisations, many of which are listed on the >> web site. Written by a colleague here at University of Southampton, >> hence the plug. If you install and run it yourself, there's a good >> community mail list for support and tips. > > ... or just run amavisd. MailScanner used to do Bad Things with the > Postfix queue, but since then I think they have fixed that, but I will > admit to not having any experience with it. I have 6 MailScanner servers in production running with Postfix, not had any 'real' issues in the last few years. > > As to amavisd: > > http://www.ijs.si/software/amavisd/ > > Have been using it on 1 million mails / day with satisfaction > > > From jlewis at lewis.org Mon Apr 11 06:55:51 2011 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 11 Apr 2011 07:55:51 -0400 (EDT) Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: <4101EDF67E13AB49BA5564A8E7E2C03C12CAE3DBBB@34093-MBX-C18.mex07a.mlsrvr.com> References: <4101EDF67E13AB49BA5564A8E7E2C03C12CAE3DBBB@34093-MBX-C18.mex07a.mlsrvr.com> Message-ID: On Mon, 11 Apr 2011, Ray Corbin wrote: > I had experience with Barracuda as outbound anti-spam filters for > a very large hosting provider and I won't use Barracuda again. Some of > their methods for blocking spam are a tad extreme. At one point they > decided to block both yahoo.com and google.com in their domain filters > because neither company responded timely to their complaint emails and > wanted their attention. Those both have pretty poor reputations for handling outgoing spam and other abuse issues. Yahoo is notorious for the "the message in your complaint did not come from our servers" response, when any idiot who can read headers can see that it clearly did come from their servers. They've gone a step beyond this recently by refusing to accept spam complaints to abuse at yahoo.com unless they're in ARF format. That raises the bar high enough that unless you have the skills to easily turn yahoo spam into ARF-compliant reports, you can no longer send them complaints when you receive spam from their servers. Google (gmail.com) is the only free-mail provider I'm aware of that hides the spammer's originating IP. All sorts of abuses seem to be tolerated there for much longer spans of time than you'd think it would take "the brightest of the brightest" to lock things down. i.e. URL redirectors used by spammers for months, phishing collectors reported to Google security, and nothing apparently done about them. Sometimes, the only way to get an appropriate reaction from an org that just doesn't seem to care about its abuse issues is to make those abuse issues cause them some pain. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From rcorbin at traffiq.com Mon Apr 11 07:07:55 2011 From: rcorbin at traffiq.com (Ray Corbin) Date: Mon, 11 Apr 2011 07:07:55 -0500 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: <4101EDF67E13AB49BA5564A8E7E2C03C12CAE3DBBB@34093-MBX-C18.mex07a.mlsrvr.com> Message-ID: <4101EDF67E13AB49BA5564A8E7E2C03C12CAE3DC16@34093-MBX-C18.mex07a.mlsrvr.com> I don't think they had blocked mail coming/going from yahoo.com/google.com which would have been more careless to their subscribers (especially when our outbound units were processing a few million emails a day from our customers). They blocked the domains so you couldn't have a link to google/yahoo in the body and then set that as an update for all of their devices. I believe it was something about a URL redirect on each site that spammers were using..but this was a several years ago so I don't recall exactly. -r -----Original Message----- From: Jon Lewis [mailto:jlewis at lewis.org] Sent: Monday, April 11, 2011 7:56 AM To: Ray Corbin Cc: nanog at nanog.org Subject: RE: Barracuda Networks is at it again: Any Suggestions as to an Alternative? On Mon, 11 Apr 2011, Ray Corbin wrote: > I had experience with Barracuda as outbound anti-spam filters for > a very large hosting provider and I won't use Barracuda again. Some of > their methods for blocking spam are a tad extreme. At one point they > decided to block both yahoo.com and google.com in their domain filters > because neither company responded timely to their complaint emails and > wanted their attention. Those both have pretty poor reputations for handling outgoing spam and other abuse issues. Yahoo is notorious for the "the message in your complaint did not come from our servers" response, when any idiot who can read headers can see that it clearly did come from their servers. They've gone a step beyond this recently by refusing to accept spam complaints to abuse at yahoo.com unless they're in ARF format. That raises the bar high enough that unless you have the skills to easily turn yahoo spam into ARF-compliant reports, you can no longer send them complaints when you receive spam from their servers. Google (gmail.com) is the only free-mail provider I'm aware of that hides the spammer's originating IP. All sorts of abuses seem to be tolerated there for much longer spans of time than you'd think it would take "the brightest of the brightest" to lock things down. i.e. URL redirectors used by spammers for months, phishing collectors reported to Google security, and nothing apparently done about them. Sometimes, the only way to get an appropriate reaction from an org that just doesn't seem to care about its abuse issues is to make those abuse issues cause them some pain. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From luigi at net.t-labs.tu-berlin.de Mon Apr 11 07:12:39 2011 From: luigi at net.t-labs.tu-berlin.de (Luigi Iannone) Date: Mon, 11 Apr 2011 14:12:39 +0200 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> Message-ID: <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> On 9, Apr, 2011, at 16:00 , Owen DeLong wrote: > > > Sent from my iPad > > On Apr 9, 2011, at 4:31 AM, Job Snijders wrote: > >> Dear All, >> >> On 8 Apr 2011, at 19:34, Lori Jakab wrote: >> >>> On 04/08/2011 06:39 PM, Owen DeLong wrote: >> >>>> LISP can also be a good option. Comes with slightly more overhead in terms of >>>> encapsulation/etc. than the GRE tunnels I use and has limited (if any) functionality >>>> for IPv4 (which GRE supports nicely). >>> >>> Maybe you meant ILNP here? AFAIK, IPv4 and IPv6 are equal citizens for LISP. >> >> Comparing GRE with LISP is like comparing /etc/hosts with the global DNS system. ;-) >> >> I don't understand the comments about LISP and IPv4. IPv4 works just excellent with LISP. I have a IPv4 block at home which I multi-home over my IPv6-only DSL and IPv4-only FTTH line. >> >> LISP is pretty address family agnostic: IPv4 over IPv4, IPv4 over IPv6, IPv6 over IPv4, IPv6 over IPv6, all work without problems. >> >> Kind regards, >> >> Job > > Doing IPv4 LISP on any kind of scale requires significant additional prefixes which at this time doesn't seem so practical to me. This is not accurate IMO. To inject prefixes in the BGP is needed only to make non-LISP sites talk to LISP sites. Even there you can aggressively aggregate, as explained in draft-ietf-lisp-interworking. As long as the LISP deployment progress you can even withdraw some prefixes from the BGP infrastructure and advertise only a larger aggregate in order for legacy site to reach the new LISP site. Luigi > > Owen > > From tom at ninjabadger.net Mon Apr 11 07:32:27 2011 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 11 Apr 2011 13:32:27 +0100 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: <4DA2D394.5030308@64bit.co.za> References: <240CD93A-64BF-4533-84A1-278CB3FDFBBB@arbor.net> <31526775-F3E1-4054-8F3F-130114438051@ecs.soton.ac.uk> <20110409093850.GA82833@macbook.catpipe.net> <4DA2D394.5030308@64bit.co.za> Message-ID: <1302525147.1992.12.camel@teh-desktop> On Mon, 2011-04-11 at 12:10 +0200, Gabriel Marais wrote: > I have 6 MailScanner servers in production running with Postfix, not > had any 'real' issues in the last few years. We have just as many -- and yes, it's great. The only thing I'd prefer would be Exim over Postfix, but Mailscanner does make things very pleasant to use. Tom From chris at nifry.com Mon Apr 11 07:40:33 2011 From: chris at nifry.com (Chris Russell) Date: Mon, 11 Apr 2011 13:40:33 +0100 Subject: Barracuda Networks is at it again: Any Suggestions as to an =?UTF-8?Q?Alternative=3F?= In-Reply-To: <1302525147.1992.12.camel@teh-desktop> References: <240CD93A-64BF-4533-84A1-278CB3FDFBBB@arbor.net> <31526775-F3E1-4054-8F3F-130114438051@ecs.soton.ac.uk> <20110409093850.GA82833@macbook.catpipe.net> <4DA2D394.5030308@64bit.co.za> <1302525147.1992.12.camel@teh-desktop> Message-ID: > We have just as many -- and yes, it's great. > > The only thing I'd prefer would be Exim over Postfix, but Mailscanner > does make things very pleasant to use. +1 for Exim, although development stalled for a while when Philip Hazel retired its now back on track. Also not happy with Barracuda, have a couple of hosts which are blocked by their blocking list and they've refused to tell me why. Chris From owen at delong.com Mon Apr 11 08:17:30 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2011 06:17:30 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> Message-ID: <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> On Apr 11, 2011, at 5:12 AM, Luigi Iannone wrote: > > On 9, Apr, 2011, at 16:00 , Owen DeLong wrote: > >> >> >> Sent from my iPad >> >> On Apr 9, 2011, at 4:31 AM, Job Snijders wrote: >> >>> Dear All, >>> >>> On 8 Apr 2011, at 19:34, Lori Jakab wrote: >>> >>>> On 04/08/2011 06:39 PM, Owen DeLong wrote: >>> >>>>> LISP can also be a good option. Comes with slightly more overhead in terms of >>>>> encapsulation/etc. than the GRE tunnels I use and has limited (if any) functionality >>>>> for IPv4 (which GRE supports nicely). >>>> >>>> Maybe you meant ILNP here? AFAIK, IPv4 and IPv6 are equal citizens for LISP. >>> >>> Comparing GRE with LISP is like comparing /etc/hosts with the global DNS system. ;-) >>> >>> I don't understand the comments about LISP and IPv4. IPv4 works just excellent with LISP. I have a IPv4 block at home which I multi-home over my IPv6-only DSL and IPv4-only FTTH line. >>> >>> LISP is pretty address family agnostic: IPv4 over IPv4, IPv4 over IPv6, IPv6 over IPv4, IPv6 over IPv6, all work without problems. >>> >>> Kind regards, >>> >>> Job >> >> Doing IPv4 LISP on any kind of scale requires significant additional prefixes which at this time doesn't seem so practical to me. > > This is not accurate IMO. To inject prefixes in the BGP is needed only to make non-LISP sites talk to LISP sites. Even there you can aggressively aggregate, as explained in draft-ietf-lisp-interworking. > > As long as the LISP deployment progress you can even withdraw some prefixes from the BGP infrastructure and advertise only a larger aggregate in order for legacy site to reach the new LISP site. > > Luigi > Who said anything about BGP? I was talking about the amount of additional IP space needed vs. the amount of IPv4 free space remaining. Owen From luigi at net.t-labs.tu-berlin.de Mon Apr 11 08:30:32 2011 From: luigi at net.t-labs.tu-berlin.de (Luigi Iannone) Date: Mon, 11 Apr 2011 15:30:32 +0200 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> Message-ID: <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> On 11, Apr, 2011, at 15:17 , Owen DeLong wrote: [snip] >>> >>> Doing IPv4 LISP on any kind of scale requires significant additional prefixes which at this time doesn't seem so practical to me. >> >> This is not accurate IMO. To inject prefixes in the BGP is needed only to make non-LISP sites talk to LISP sites. Even there you can aggressively aggregate, as explained in draft-ietf-lisp-interworking. >> >> As long as the LISP deployment progress you can even withdraw some prefixes from the BGP infrastructure and advertise only a larger aggregate in order for legacy site to reach the new LISP site. >> >> Luigi >> > Who said anything about BGP? I was talking about the amount of additional IP space needed vs. the > amount of IPv4 free space remaining. > Sorry. I misunderstood. But can you explain better? Why should LISP require more IP space than normal IPv4 deployment? If you are a new site, you ask for an IP block. This is independent from whether or not you will use LISP. If you are an existing site and you want to switch to LISP why you need more space? you can re-use what you have? Or I missed the point again? thanks Luigi > Owen > From jlewis at lewis.org Mon Apr 11 08:41:53 2011 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 11 Apr 2011 09:41:53 -0400 (EDT) Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: <1302525147.1992.12.camel@teh-desktop> References: <240CD93A-64BF-4533-84A1-278CB3FDFBBB@arbor.net> <31526775-F3E1-4054-8F3F-130114438051@ecs.soton.ac.uk> <20110409093850.GA82833@macbook.catpipe.net> <4DA2D394.5030308@64bit.co.za> <1302525147.1992.12.camel@teh-desktop> Message-ID: On Mon, 11 Apr 2011, Tom Hill wrote: > On Mon, 2011-04-11 at 12:10 +0200, Gabriel Marais wrote: >> I have 6 MailScanner servers in production running with Postfix, not >> had any 'real' issues in the last few years. > > We have just as many -- and yes, it's great. > > The only thing I'd prefer would be Exim over Postfix, but Mailscanner > does make things very pleasant to use. I think you guys are missing the point, which is that Barracuda and similar products are marketed primarily to people who don't know what qmail, postfix, exim, clamav, mailscanner, etc. are and certainly don't have any experience installing or maintaining them. Some places just want a black box where you have a web GUI to configure it, and then it mostly takes care of itself...and if it breaks, you call tech support. Sure, you can probably get most of the functionality and better filtering with roll your own solutions and careful DNSBL selection...but not everyone is capable or has the man power to devote to it. To most of us on this list, sure, it's an overpriced piece of commodity x86 hardware with someone else's roll your own stuff on it, backed by an ill-defined DNSBL of questionable quality and integrity, but it must work well enough as it's kept them in business and I even know a few people who've owned them and been happy with them. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From owen at delong.com Mon Apr 11 08:37:41 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2011 06:37:41 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> Message-ID: <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> On Apr 11, 2011, at 6:30 AM, Luigi Iannone wrote: > > On 11, Apr, 2011, at 15:17 , Owen DeLong wrote: > > [snip] >>>> >>>> Doing IPv4 LISP on any kind of scale requires significant additional prefixes which at this time doesn't seem so practical to me. >>> >>> This is not accurate IMO. To inject prefixes in the BGP is needed only to make non-LISP sites talk to LISP sites. Even there you can aggressively aggregate, as explained in draft-ietf-lisp-interworking. >>> >>> As long as the LISP deployment progress you can even withdraw some prefixes from the BGP infrastructure and advertise only a larger aggregate in order for legacy site to reach the new LISP site. >>> >>> Luigi >>> >> Who said anything about BGP? I was talking about the amount of additional IP space needed vs. the >> amount of IPv4 free space remaining. >> > > Sorry. I misunderstood. > > But can you explain better? Why should LISP require more IP space than normal IPv4 deployment? > > If you are a new site, you ask for an IP block. This is independent from whether or not you will use LISP. > Sure, but, if you also need locators, don't you need additional IP space to use for locators? > If you are an existing site and you want to switch to LISP why you need more space? you can re-use what you have? > Perhaps I misunderstand LISP, but, I though you needed space to use for locators and space to use for IDs if you are an independently routed multi-homed site. If you are not an independently routed multi-homed site, then, don't you need a set of host IDs to go with each of your upstream locators? As I understand LISP, it's basically a dynamic tunneling system where you have two discrete, but non-overlapping address spaces, one inside the tunnels and one outside. If that's the case, then, I believe it leads to at least some amount of duplicate consumption of IP numbers. > Or I missed the point again? > Or perhaps the complexity of LISP in the details still confuses me, despite people's insistence that it is not complex. Owen > thanks > > Luigi > > > >> Owen >> > From william.allen.simpson at gmail.com Mon Apr 11 09:13:49 2011 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Mon, 11 Apr 2011 10:13:49 -0400 Subject: Level 3 Agrees to Purchase Global Crossing Message-ID: <4DA30C9D.107@gmail.com> http://www.bloomberg.com/news/print/2011-04-11/level-3-agrees-to-acquire-global-crossing-in-deal-valued-at-1-9-billion.html The deal will combine two unprofitable companies with total revenue of $6.26 billion as of last year, and cut annualized capital spending by about $40 million, according to the statement. It will also help reduce the pressure on prices, which have declined by as much as 30 percent a year in the industry, said Donna Jaegers, an analyst at DA Davidson & Co. ?This is what telecom has needed for a long time,? said Denver-based Jaegers, who recommends buying both stocks. ?You have way too many players.? From jra at baylink.com Mon Apr 11 09:22:11 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 11 Apr 2011 10:22:11 -0400 (EDT) Subject: Level 3 Agrees to Purchase Global Crossing In-Reply-To: <4DA30C9D.107@gmail.com> Message-ID: <6799205.2193.1302531731480.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Allen Simpson" > http://www.bloomberg.com/news/print/2011-04-11/level-3-agrees-to-acquire-global-crossing-in-deal-valued-at-1-9-billion.html > > The deal will combine two unprofitable companies with total revenue of > $6.26 billion as of last year, and cut annualized capital spending by > about $40 million, according to the statement. It will also help > reduce > the pressure on prices, which have declined by as much as 30 percent a > year in the industry, said Donna Jaegers, an analyst at DA Davidson & > Co. Let me see if I have that straight. We're *admitting* in public that the result will be to make prices go up for customers? Wow... Justice is going to have a field day with that. Cheers, -- jra From dorn at hetzel.org Mon Apr 11 09:26:10 2011 From: dorn at hetzel.org (Dorn Hetzel) Date: Mon, 11 Apr 2011 10:26:10 -0400 Subject: Level 3 Agrees to Purchase Global Crossing In-Reply-To: <6799205.2193.1302531731480.JavaMail.root@benjamin.baylink.com> References: <4DA30C9D.107@gmail.com> <6799205.2193.1302531731480.JavaMail.root@benjamin.baylink.com> Message-ID: On Mon, Apr 11, 2011 at 10:22 AM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "William Allen Simpson" > > > > http://www.bloomberg.com/news/print/2011-04-11/level-3-agrees-to-acquire-global-crossing-in-deal-valued-at-1-9-billion.html > > > > The deal will combine two unprofitable companies with total revenue of > > $6.26 billion as of last year, and cut annualized capital spending by > > about $40 million, according to the statement. It will also help > > reduce > > the pressure on prices, which have declined by as much as 30 percent a > > year in the industry, said Donna Jaegers, an analyst at DA Davidson & > > Co. > > Let me see if I have that straight. > > We're *admitting* in public that the result will be to make prices go up > for > customers? Wow... Justice is going to have a field day with that. > > Cheers, > -- jra > > Well, maybe they're just admitting it will slow the rate at which prices go down :) From jra at baylink.com Mon Apr 11 09:27:44 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 11 Apr 2011 10:27:44 -0400 (EDT) Subject: Level 3 Agrees to Purchase Global Crossing In-Reply-To: Message-ID: <16975162.2197.1302532064855.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Dorn Hetzel" > Well, maybe they're just admitting it will slow the rate at which > prices go down :) Cause L3 and GBLX are Too Big To Fail, right? Furrfu. Cheers, -- jra From ekim.ittag at gmail.com Mon Apr 11 09:34:25 2011 From: ekim.ittag at gmail.com (Mike Gatti) Date: Mon, 11 Apr 2011 10:34:25 -0400 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: Not an appliance but a really amazing job at stopping spam, www.messagelabs.com (purchased by Symantec). We went from messagelabs service to barracuda appliance and the difference is astronomical, whereas before i might get one or two spams a day using MessageLabs now with the barracuda I get an average of 25 to 30. -- Michael Gatti cell.703.347.4412 ekim.ittag at gmail.com On Apr 8, 2011, at 11:51 PM, John Palmer (NANOG Acct) wrote: > OK, its been a year since my Barracuda subscription expired. The unit still stops some spam. I figured that I would go and see what they would do if I tried to renew my subscription EXACTLY one year after it expired. Would their renewal website say "Oh, you are at your anniversary date", and renew me for a year? > > No such luck: They want me to PAY FOR AN ENTIRE YEAR for which I did NOT receive service and then for the current (upcoming year). Sorry - I don't allow myself to be ripped off like that. Sorry Barracuda - you get no money from me and I'll tell everyone I know about this policy of yours. > > I posted an article about this unscrupulous practice on my blog last year at http://www.john-palmer.net/wordpress/?p=46 > > My question is - does anyone have any suggestions for another e-mail appliance like the Barracuda Spam Firewall that doesn't try to charge their customers for time not used. I should be able to shut off the unit for a year or whatever and simply renew from the point that I re-activate the unit instead of having to pay for back-years that I didn't use. > > Thanks > > > > > From mwalter at 3z.net Mon Apr 11 09:41:18 2011 From: mwalter at 3z.net (Mike Walter) Date: Mon, 11 Apr 2011 14:41:18 +0000 Subject: Level 3 Agrees to Purchase Global Crossing In-Reply-To: References: <4DA30C9D.107@gmail.com> <6799205.2193.1302531731480.JavaMail.root@benjamin.baylink.com> Message-ID: I find it amusing that the article says - "The deal will combine two unprofitable companies...". So I guess the thinking is that two negatives make a positive? -Mike -----Original Message----- From: Dorn Hetzel [mailto:dorn at hetzel.org] Sent: Monday, April 11, 2011 10:26 AM To: Jay Ashworth Cc: NANOG Subject: Re: Level 3 Agrees to Purchase Global Crossing On Mon, Apr 11, 2011 at 10:22 AM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "William Allen Simpson" > > > > http://www.bloomberg.com/news/print/2011-04-11/level-3-agrees-to-acquire-global-crossing-in-deal-valued-at-1-9-billion.html > > > > The deal will combine two unprofitable companies with total revenue of > > $6.26 billion as of last year, and cut annualized capital spending by > > about $40 million, according to the statement. It will also help > > reduce > > the pressure on prices, which have declined by as much as 30 percent a > > year in the industry, said Donna Jaegers, an analyst at DA Davidson & > > Co. > > Let me see if I have that straight. > > We're *admitting* in public that the result will be to make prices go up > for > customers? Wow... Justice is going to have a field day with that. > > Cheers, > -- jra > > Well, maybe they're just admitting it will slow the rate at which prices go down :) From david at davidcoulson.net Mon Apr 11 09:46:06 2011 From: david at davidcoulson.net (David Coulson) Date: Mon, 11 Apr 2011 10:46:06 -0400 Subject: Level 3 Agrees to Purchase Global Crossing In-Reply-To: References: <4DA30C9D.107@gmail.com> <6799205.2193.1302531731480.JavaMail.root@benjamin.baylink.com> Message-ID: <4DA3142E.6090202@davidcoulson.net> On 4/11/11 10:41 AM, Mike Walter wrote: > I find it amusing that the article says - "The deal will combine two unprofitable companies...". > > So I guess the thinking is that two negatives make a positive? > > -Mike Since they will be saving a whole $40mm annually, profitability is pretty much guaranteed - right? ;-) Wasn't there a telco CEO who would blow that much in strip clubs? Savvis springs to mind, but I don't remember. David From harbor235 at gmail.com Mon Apr 11 09:48:47 2011 From: harbor235 at gmail.com (harbor235) Date: Mon, 11 Apr 2011 10:48:47 -0400 Subject: Level 3 Agrees to Purchase Global Crossing In-Reply-To: References: <4DA30C9D.107@gmail.com> <6799205.2193.1302531731480.JavaMail.root@benjamin.baylink.com> Message-ID: combining the companies will allow them to maximize efficeinecies by the elimination of overlapping functions, hopefully paving the way to profitability. Job cuts here we come ........ Mike On Mon, Apr 11, 2011 at 10:41 AM, Mike Walter wrote: > I find it amusing that the article says - "The deal will combine two > unprofitable companies...". > > So I guess the thinking is that two negatives make a positive? > > -Mike > > -----Original Message----- > From: Dorn Hetzel [mailto:dorn at hetzel.org] > Sent: Monday, April 11, 2011 10:26 AM > To: Jay Ashworth > Cc: NANOG > Subject: Re: Level 3 Agrees to Purchase Global Crossing > > On Mon, Apr 11, 2011 at 10:22 AM, Jay Ashworth wrote: > > > ----- Original Message ----- > > > From: "William Allen Simpson" > > > > > > > > http://www.bloomberg.com/news/print/2011-04-11/level-3-agrees-to-acquire-global-crossing-in-deal-valued-at-1-9-billion.html > > > > > > The deal will combine two unprofitable companies with total revenue of > > > $6.26 billion as of last year, and cut annualized capital spending by > > > about $40 million, according to the statement. It will also help > > > reduce > > > the pressure on prices, which have declined by as much as 30 percent a > > > year in the industry, said Donna Jaegers, an analyst at DA Davidson & > > > Co. > > > > Let me see if I have that straight. > > > > We're *admitting* in public that the result will be to make prices go up > > for > > customers? Wow... Justice is going to have a field day with that. > > > > Cheers, > > -- jra > > > > Well, maybe they're just admitting it will slow the rate at which prices > go > down :) > > From cklam at ias.edu Mon Apr 11 09:49:25 2011 From: cklam at ias.edu (Christina Klam) Date: Mon, 11 Apr 2011 10:49:25 -0400 Subject: LISP Message-ID: <8CB341D4-06DF-43F9-9A7F-32F80A76DB73@ias.edu> All, One of our ISP is planning to do a LISP deployment. (1) Does anyone know if Sprint uses LISP? (2) Does anyone know of any good guides/documentation of LISP? Thank you, Christina Klam From mikea at mikea.ath.cx Mon Apr 11 09:49:28 2011 From: mikea at mikea.ath.cx (mikea) Date: Mon, 11 Apr 2011 09:49:28 -0500 Subject: Level 3 Agrees to Purchase Global Crossing In-Reply-To: References: <4DA30C9D.107@gmail.com> <6799205.2193.1302531731480.JavaMail.root@benjamin.baylink.com> Message-ID: <20110411144928.GA53619@mikea.ath.cx> On Mon, Apr 11, 2011 at 02:41:18PM +0000, Mike Walter wrote: > I find it amusing that the article says - "The deal will combine two unprofitable companies...". > > So I guess the thinking is that two negatives make a positive? They may lose on every subscriber, but now they'll make it up in volume. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From harbor235 at gmail.com Mon Apr 11 10:02:56 2011 From: harbor235 at gmail.com (harbor235) Date: Mon, 11 Apr 2011 11:02:56 -0400 Subject: LISP In-Reply-To: <8CB341D4-06DF-43F9-9A7F-32F80A76DB73@ias.edu> References: <8CB341D4-06DF-43F9-9A7F-32F80A76DB73@ias.edu> Message-ID: http://www.lisp4.net/ Mike On Mon, Apr 11, 2011 at 10:49 AM, Christina Klam wrote: > All, > > One of our ISP is planning to do a LISP deployment. (1) Does anyone know > if Sprint uses LISP? (2) Does anyone know of any good guides/documentation > of LISP? > > Thank you, > Christina Klam > > > > > > From bortzmeyer at nic.fr Mon Apr 11 10:03:14 2011 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 11 Apr 2011 17:03:14 +0200 Subject: LISP In-Reply-To: <8CB341D4-06DF-43F9-9A7F-32F80A76DB73@ias.edu> References: <8CB341D4-06DF-43F9-9A7F-32F80A76DB73@ias.edu> Message-ID: <20110411150314.GA5825@nic.fr> On Mon, Apr 11, 2011 at 10:49:25AM -0400, Christina Klam wrote a message of 12 lines which said: > (1) Does anyone know if Sprint uses LISP? It is too early, IMHO, to have production deployments of LISP (testing is OK). > (2) Does anyone know of any good guides/documentation of LISP? For Cisco users, I like From ljakab at ac.upc.edu Mon Apr 11 10:06:59 2011 From: ljakab at ac.upc.edu (Lori Jakab) Date: Mon, 11 Apr 2011 17:06:59 +0200 Subject: LISP In-Reply-To: References: <8CB341D4-06DF-43F9-9A7F-32F80A76DB73@ias.edu> Message-ID: <4DA31913.8050303@ac.upc.edu> On 04/11/2011 05:02 PM, harbor235 wrote: > http://www.lisp4.net/ Agreed, this is the best starting point. I'm working on a draft about LISP deployment, feedback is always welcome: http://tools.ietf.org/html/draft-jakab-lisp-deployment -Lori > Mike > > On Mon, Apr 11, 2011 at 10:49 AM, Christina Klam wrote: > >> All, >> >> One of our ISP is planning to do a LISP deployment. (1) Does anyone know >> if Sprint uses LISP? (2) Does anyone know of any good guides/documentation >> of LISP? >> >> Thank you, >> Christina Klam From luigi at net.t-labs.tu-berlin.de Mon Apr 11 10:07:26 2011 From: luigi at net.t-labs.tu-berlin.de (Luigi Iannone) Date: Mon, 11 Apr 2011 17:07:26 +0200 Subject: LISP In-Reply-To: <8CB341D4-06DF-43F9-9A7F-32F80A76DB73@ias.edu> References: <8CB341D4-06DF-43F9-9A7F-32F80A76DB73@ias.edu> Message-ID: <4EA7508E-3B63-467E-A61F-8CFF034CE245@net.t-labs.tu-berlin.de> Hi, I think that the best repository of documentation is lisp4.net. I would also have a look to https://datatracker.ietf.org/doc/draft-jakab-lisp-deployment/ Luigi On 11, Apr, 2011, at 16:49 , Christina Klam wrote: > All, > > One of our ISP is planning to do a LISP deployment. (1) Does anyone know if Sprint uses LISP? (2) Does anyone know of any good guides/documentation of LISP? > > Thank you, > Christina Klam > > > > > From cklam at ias.edu Mon Apr 11 10:14:10 2011 From: cklam at ias.edu (Christina Klam) Date: Mon, 11 Apr 2011 11:14:10 -0400 Subject: LISP In-Reply-To: <4EA7508E-3B63-467E-A61F-8CFF034CE245@net.t-labs.tu-berlin.de> References: <8CB341D4-06DF-43F9-9A7F-32F80A76DB73@ias.edu> <4EA7508E-3B63-467E-A61F-8CFF034CE245@net.t-labs.tu-berlin.de> Message-ID: <541208DD-93CB-4E00-A66C-882FCF384D2E@ias.edu> Thank you all. On Apr 11, 2011, at 11:07 AM, Luigi Iannone wrote: > Hi, > > I think that the best repository of documentation is lisp4.net. > > I would also have a look to > https://datatracker.ietf.org/doc/draft-jakab-lisp-deployment/ > > Luigi > > On 11, Apr, 2011, at 16:49 , Christina Klam wrote: > >> All, >> >> One of our ISP is planning to do a LISP deployment. (1) Does anyone know if Sprint uses LISP? (2) Does anyone know of any good guides/documentation of LISP? >> >> Thank you, >> Christina Klam >> >> >> >> >> > Christina Klam Network Administrator Institute for Advanced Study Email: cklam at ias.edu Einstein Drive Telephone: 609-734-8154 Princeton, NJ 08540 Fax: 609-951-4418 From luigi at net.t-labs.tu-berlin.de Mon Apr 11 10:15:59 2011 From: luigi at net.t-labs.tu-berlin.de (Luigi Iannone) Date: Mon, 11 Apr 2011 17:15:59 +0200 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> Message-ID: <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> On 11, Apr, 2011, at 15:37 , Owen DeLong wrote: > > On Apr 11, 2011, at 6:30 AM, Luigi Iannone wrote: > >> >> On 11, Apr, 2011, at 15:17 , Owen DeLong wrote: >> >> [snip] >>>>> >>>>> Doing IPv4 LISP on any kind of scale requires significant additional prefixes which at this time doesn't seem so practical to me. >>>> >>>> This is not accurate IMO. To inject prefixes in the BGP is needed only to make non-LISP sites talk to LISP sites. Even there you can aggressively aggregate, as explained in draft-ietf-lisp-interworking. >>>> >>>> As long as the LISP deployment progress you can even withdraw some prefixes from the BGP infrastructure and advertise only a larger aggregate in order for legacy site to reach the new LISP site. >>>> >>>> Luigi >>>> >>> Who said anything about BGP? I was talking about the amount of additional IP space needed vs. the >>> amount of IPv4 free space remaining. >>> >> >> Sorry. I misunderstood. >> >> But can you explain better? Why should LISP require more IP space than normal IPv4 deployment? >> >> If you are a new site, you ask for an IP block. This is independent from whether or not you will use LISP. >> > Sure, but, if you also need locators, don't you need additional IP space to use for locators? No, those are the IP address that you provider gives to your border router. > >> If you are an existing site and you want to switch to LISP why you need more space? you can re-use what you have? >> > Perhaps I misunderstand LISP, but, I though you needed space to use for locators and space > to use for IDs if you are an independently routed multi-homed site. Not exactly. You do not need more space. You re-use what you have. > > If you are not an independently routed multi-homed site, then, don't you need a set of host IDs > to go with each of your upstream locators? > > As I understand LISP, it's basically a dynamic tunneling system where you have two discrete, > but non-overlapping address spaces, one inside the tunnels and one outside. > > If that's the case, then, I believe it leads to at least some amount of duplicate consumption of > IP numbers. > No true. I ask for a PI block that I will use as EID-Prefix, then the locators are part of the address space of my providers. There is no duplication. >> Or I missed the point again? >> > Or perhaps the complexity of LISP in the details still confuses me, despite people's insistence > that it is not complex. > IMHO it is very simple. As any new technology there is just a learning curve to follow, but for LISP it is not steep ;-) Luigi > Owen > >> thanks >> >> Luigi >> >> >> >>> Owen >>> >> > From oberman at es.net Mon Apr 11 10:21:00 2011 From: oberman at es.net (Kevin Oberman) Date: Mon, 11 Apr 2011 08:21:00 -0700 Subject: Top-posting (was: Barracuda Networks is at it again: Any Suggestions as to anAlternative? ) In-Reply-To: Your message of "Sun, 10 Apr 2011 23:11:44 -1000." <2C81C7AD62B2450DACAC1ADB88CF4226@DELL16> Message-ID: <20110411152100.A6B6D1CC0F@ptavv.es.net> > From: "Michael Painter" > Date: Sun, 10 Apr 2011 23:11:44 -1000 > > gord wrote: > > I wonder if there's a filter for top-postings in list that have a > > bottom-posting rule? > > This thread is very operationally interesting to me but I've lost the > > plot :( > > > > http://www.nanog.org/mailinglist/listfaqs/generalfaq.php?qt=convent > > refers. > > > > PS: I know that some devices actually prevent bottom-posting by default. > > Workarounds are possible and are evident in other recent posts to this > > list. > > Additionally, may I suggest you file a bug report with your vendors or > > switch to a device that you can control properly :) > > > It makes the thread very hard to follow. > > Why not? > >> Please don't top post! > > I used to have this available for a 'signature', but, with a few exceptions, it seems to fall on blind eyes these > days. I put nearly identical text in response to top-posted messages and, if it was not too difficult, move the top-posted response to the end, before my response. Of late I have started to get responses from people (not even the person who top-posted) saying that I should f*** off and that they would post however they wanted. Very hostile and even threatening. I even manage to bottom post from my iPod. With cut and paste, it's really not hard, but I guess it's just beyond the capacities of some and somehow offensive to others. **Sigh** -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owen at delong.com Mon Apr 11 10:26:32 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2011 08:26:32 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> Message-ID: <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> On Apr 11, 2011, at 8:15 AM, Luigi Iannone wrote: > > On 11, Apr, 2011, at 15:37 , Owen DeLong wrote: > >> >> On Apr 11, 2011, at 6:30 AM, Luigi Iannone wrote: >> >>> >>> On 11, Apr, 2011, at 15:17 , Owen DeLong wrote: >>> >>> [snip] >>>>>> >>>>>> Doing IPv4 LISP on any kind of scale requires significant additional prefixes which at this time doesn't seem so practical to me. >>>>> >>>>> This is not accurate IMO. To inject prefixes in the BGP is needed only to make non-LISP sites talk to LISP sites. Even there you can aggressively aggregate, as explained in draft-ietf-lisp-interworking. >>>>> >>>>> As long as the LISP deployment progress you can even withdraw some prefixes from the BGP infrastructure and advertise only a larger aggregate in order for legacy site to reach the new LISP site. >>>>> >>>>> Luigi >>>>> >>>> Who said anything about BGP? I was talking about the amount of additional IP space needed vs. the >>>> amount of IPv4 free space remaining. >>>> >>> >>> Sorry. I misunderstood. >>> >>> But can you explain better? Why should LISP require more IP space than normal IPv4 deployment? >>> >>> If you are a new site, you ask for an IP block. This is independent from whether or not you will use LISP. >>> >> Sure, but, if you also need locators, don't you need additional IP space to use for locators? > > No, those are the IP address that you provider gives to your border router. > Right... In addition to my provider independent addresses... That's more address space than is required if I am not using LISP. >> >>> If you are an existing site and you want to switch to LISP why you need more space? you can re-use what you have? >>> >> Perhaps I misunderstand LISP, but, I though you needed space to use for locators and space >> to use for IDs if you are an independently routed multi-homed site. > > Not exactly. You do not need more space. You re-use what you have. > Still confused, then. This seems antithetical to what you said above and below... >> >> If you are not an independently routed multi-homed site, then, don't you need a set of host IDs >> to go with each of your upstream locators? >> >> As I understand LISP, it's basically a dynamic tunneling system where you have two discrete, >> but non-overlapping address spaces, one inside the tunnels and one outside. >> >> If that's the case, then, I believe it leads to at least some amount of duplicate consumption of >> IP numbers. >> > > No true. I ask for a PI block that I will use as EID-Prefix, then the locators are part of the address space of my providers. > There is no duplication. > > Right... Ordinarily, without LISP, I get a PI block and use that for EID and the routing is based on the EID prefix. With LISP, the EID prefix is PI and I use additional PA resources to do the routing locators. That's what I meant by duplication. There are additional PA resources required on top of the PI in order to make LISP work. >>> Or I missed the point again? >>> >> Or perhaps the complexity of LISP in the details still confuses me, despite people's insistence >> that it is not complex. >> > > IMHO it is very simple. As any new technology there is just a learning curve to follow, but for LISP it is not steep ;-) > I'd agree with you if it weren't for the fact I keep thinking I just about understand LISP and then get told that my understanding is incorrect (repeatedly). Owen > Luigi > > >> Owen >> >>> thanks >>> >>> Luigi >>> >>> >>> >>>> Owen >>>> >>> >> > From job at instituut.net Mon Apr 11 10:33:50 2011 From: job at instituut.net (Job Snijders) Date: Mon, 11 Apr 2011 17:33:50 +0200 Subject: LISP In-Reply-To: <8CB341D4-06DF-43F9-9A7F-32F80A76DB73@ias.edu> References: <8CB341D4-06DF-43F9-9A7F-32F80A76DB73@ias.edu> Message-ID: Dear Christina, On 11 Apr 2011, at 16:49, Christina Klam wrote: > One of our ISP is planning to do a LISP deployment. (1) Does anyone know if Sprint uses LISP? (2) Does anyone know of any good guides/documentation of LISP? I cannot answer question 1. But I do work for an ISP that's rolling out LISP. :-) Here is some links that might help answer questions 2: Some of the following links are slightly dated because some LISP implementations have been actively developed the last year. This is a multi-organisation website, to coordinate the LISP beta network and provide general information: http://www.lisp4.net/ Here is cisco's configuration guide: http://www.cisco.com/en/US/docs/ios/lisp/configuration/guide LISP_configuration_guide.pdf Here are some nice blogposts that cover various subjects: http://blog.fryguy.net/2011/04/07/lisp-locator-identifier-separation-protocol-say-what/ http://blog.fryguy.net/2011/04/08/more-lisp-using-it-to-enable-ipv6-over-ipv4/ http://blog.pattincon.com/lisp-data-plane http://blog.pattincon.com/practical-lisp-basic-control-plane http://blog.pattincon.com/lisp http://blog.snijders-it.nl/2010/11/lisp-getvpn-as-alternative-for.html http://blog.ine.com/2010/07/05/a-high-level-overview-of-lisp/ Kind regards, Job From mark at noc.mainstreet.net Mon Apr 11 10:41:13 2011 From: mark at noc.mainstreet.net (Mark Kent) Date: Mon, 11 Apr 2011 08:41:13 -0700 (PDT) Subject: Level 3 Agrees to Purchase Global Crossing In-Reply-To: (nanog-request@nanog.org) References: Message-ID: <201104111541.p3BFfDIS008994@mainstreet.net> Well, this will be the third time that Level3 has purchased my primary upstream provider. Maybe this will be different than with Genuity and Wiltel, but Level3 needs to either stop using the word "legacy" or educate their employees so they know that "legacy" is good and not bad. -mark From gbonser at seven.com Mon Apr 11 10:55:05 2011 From: gbonser at seven.com (George Bonser) Date: Mon, 11 Apr 2011 08:55:05 -0700 Subject: Level 3 Agrees to Purchase Global Crossing In-Reply-To: <6799205.2193.1302531731480.JavaMail.root@benjamin.baylink.com> References: <4DA30C9D.107@gmail.com> <6799205.2193.1302531731480.JavaMail.root@benjamin.baylink.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E2CF0@RWC-EX1.corp.seven.com> > Let me see if I have that straight. > > We're *admitting* in public that the result will be to make prices go > up for > customers? Wow... Justice is going to have a field day with that. > > Cheers, > -- jra I don't think it means so much that prices will go up, just that it will slow the decline. But having said that, it appears that we are in for a spate of inflation generally and the prices of everything are going to rise fairly quickly, starting about now. That would be across the economy as a whole and not anything specific to the telecommunications sector. From jsw at inconcepts.biz Mon Apr 11 11:19:54 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Mon, 11 Apr 2011 12:19:54 -0400 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> Message-ID: On Mon, Apr 11, 2011 at 11:26 AM, Owen DeLong wrote: > I'd agree with you if it weren't for the fact I keep thinking I just about understand LISP and then get told > that my understanding is incorrect (repeatedly). I agree it is not simple. At a conceptual level, we can think of existing multi-homing practices as falling into one of three broad categories: 1) more state in DFZ -- end-site injects a route into BGP 2) triangular routing -- tunnel/circuits/etc to one or more upstream routers while not injecting anything to DFZ 3) added work/complexity on end-host -- SCTP and friends LISP is a compromise of all these things, except #3 happens on a router which does tunneling, not the end-host. Whether you think it's "the best of both [three?] worlds," or the worst of them, is up to you. I personally believe LISP is a horrible idea that will have trouble scaling up, because a large table of LISP mappings is not any easier to store in FIB than a larger DFZ. The "solution" the LISP folks think works for this is a side-chain mapping service which the router can query to setup encapsulation next-hops on-demand, which means if your FIB isn't big enough to hold every mapping entry, you are essentially doing flow-based routing, but with "flows" defined as being toward a remotely-defined end-site rather than toward an individual IP address (so not quite as bad as "flow-based routing" of the past, but still bad.) Maybe I also don't understand LISP and need to RTFM more, but my current understanding is that it is a dead-end technology without the ability to dramatically scale up the number of multi-homed end-sites in a cheaper manner than what is done today with BGP. I think we would be better off with more work on things like SCTP. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From streiner at cluebyfour.org Mon Apr 11 11:24:15 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 11 Apr 2011 12:24:15 -0400 (EDT) Subject: Level 3 Agrees to Purchase Global Crossing In-Reply-To: <4DA3142E.6090202@davidcoulson.net> References: <4DA30C9D.107@gmail.com> <6799205.2193.1302531731480.JavaMail.root@benjamin.baylink.com> <4DA3142E.6090202@davidcoulson.net> Message-ID: On Mon, 11 Apr 2011, David Coulson wrote: > Wasn't there a telco CEO who would blow that much in strip clubs? Savvis > springs to mind, but I don't remember. I seem to recall several dot-com-era CxOs spending very lavishly on themselves, or getting their employers to give them large 'loans' that were never paid back. Ken Lay, Jeff Skilling, Bernie Ebbers, Gary Winnick, Joe Nacchio, etc... The story of former Tyco CEO Dennis Kozlowski spending $2 million on his wife's 40th birthday party springs to mind... Tyco paid for half of it, under the guise of the party being a shareholder meeting... jms From web at typo.org Mon Apr 11 11:29:07 2011 From: web at typo.org (Wayne E. Bouchard) Date: Mon, 11 Apr 2011 09:29:07 -0700 Subject: Level 3 Agrees to Purchase Global Crossing In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E2CF0@RWC-EX1.corp.seven.com> References: <4DA30C9D.107@gmail.com> <6799205.2193.1302531731480.JavaMail.root@benjamin.baylink.com> <5A6D953473350C4B9995546AFE9939EE0C9E2CF0@RWC-EX1.corp.seven.com> Message-ID: <20110411162907.GA43166@typo.org> On Mon, Apr 11, 2011 at 08:55:05AM -0700, George Bonser wrote: > > Let me see if I have that straight. > > > > We're *admitting* in public that the result will be to make prices go > > up for > > customers? Wow... Justice is going to have a field day with that. > > > > Cheers, > > -- jra > > I don't think it means so much that prices will go up, just that it will slow the decline. Oh, trust me. I fully believe it will make prices go up. Anytime you take a major competitor out of the ball game, the negotiations shift towards center mass. That's just the way things go. The only saving grace may be that it opens the door for one of the little guys to get a bit bigger and start drawing cash away from the behemoths out there. -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From david at davidcoulson.net Mon Apr 11 11:34:05 2011 From: david at davidcoulson.net (David Coulson) Date: Mon, 11 Apr 2011 12:34:05 -0400 Subject: Level 3 Agrees to Purchase Global Crossing In-Reply-To: References: <4DA30C9D.107@gmail.com> <6799205.2193.1302531731480.JavaMail.root@benjamin.baylink.com> <4DA3142E.6090202@davidcoulson.net> Message-ID: <4DA32D7D.5040805@davidcoulson.net> On 4/11/11 12:24 PM, Justin M. Streiner wrote: > I seem to recall several dot-com-era CxOs spending very lavishly on > themselves, or getting their employers to give them large 'loans' that > were never paid back. Ken Lay, Jeff Skilling, Bernie Ebbers, Gary > Winnick, Joe Nacchio, etc... > This is what I was thinking of - Awesome photo too. http://www.msnbc.msn.com/id/9750948/ns/business-small_business/ > The story of former Tyco CEO Dennis Kozlowski spending $2 million on > his wife's 40th birthday party springs to mind... Tyco paid for half > of it, under the guise of the party being a shareholder meeting... Wish I could have been a fly on the wall during the meeting when someone suggested that idea. David From cb.list6 at gmail.com Mon Apr 11 12:09:20 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 11 Apr 2011 10:09:20 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> Message-ID: On Mon, Apr 11, 2011 at 9:19 AM, Jeff Wheeler wrote: > On Mon, Apr 11, 2011 at 11:26 AM, Owen DeLong wrote: >> I'd agree with you if it weren't for the fact I keep thinking I just about understand LISP and then get told >> that my understanding is incorrect (repeatedly). > > I agree it is not simple. > > At a conceptual level, we can think of existing multi-homing practices > as falling into one of three broad categories: > 1) more state in DFZ -- end-site injects a route into BGP > > 2) triangular routing -- tunnel/circuits/etc to one or more upstream > routers while not injecting anything to DFZ > > 3) added work/complexity on end-host -- SCTP and friends > > LISP is a compromise of all these things, except #3 happens on a > router which does tunneling, not the end-host. ?Whether you think it's > "the best of both [three?] worlds," or the worst of them, is up to > you. > > I personally believe LISP is a horrible idea that will have trouble Yep. > scaling up, because a large table of LISP mappings is not any easier > to store in FIB than a larger DFZ. ?The "solution" the LISP folks > think works for this is a side-chain mapping service which the router > can query to setup encapsulation next-hops on-demand, which means if > your FIB isn't big enough to hold every mapping entry, you are > essentially doing flow-based routing, but with "flows" defined as > being toward a remotely-defined end-site rather than toward an > individual IP address (so not quite as bad as "flow-based routing" of > the past, but still bad.) > > Maybe I also don't understand LISP and need to RTFM more, but my > current understanding is that it is a dead-end technology without the > ability to dramatically scale up the number of multi-homed end-sites > in a cheaper manner than what is done today with BGP. > > I think we would be better off with more work on things like SCTP. > +1 SCTP and IPv6, then ILNP. > -- > Jeff S Wheeler > Sr Network Operator? /? Innovative Network Concepts > > From owen at delong.com Mon Apr 11 13:03:11 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2011 11:03:11 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> Message-ID: On Apr 11, 2011, at 9:19 AM, Jeff Wheeler wrote: > On Mon, Apr 11, 2011 at 11:26 AM, Owen DeLong wrote: >> I'd agree with you if it weren't for the fact I keep thinking I just about understand LISP and then get told >> that my understanding is incorrect (repeatedly). > > I agree it is not simple. > > At a conceptual level, we can think of existing multi-homing practices > as falling into one of three broad categories: > 1) more state in DFZ -- end-site injects a route into BGP > Yep... This is clearly the best currently available mechanism. > 2) triangular routing -- tunnel/circuits/etc to one or more upstream > routers while not injecting anything to DFZ > I think what I am currently doing is a form of 1.5 for lack of a better term. I have multiple tunnels to multiple providers over multiple other connections. > 3) added work/complexity on end-host -- SCTP and friends > Ah, yes, I think SHIM6 shows up here, too, no? > LISP is a compromise of all these things, except #3 happens on a > router which does tunneling, not the end-host. Whether you think it's > "the best of both [three?] worlds," or the worst of them, is up to > you. > I'm not convinced one way or the other yet since I haven't been able to wrap my (admittedly perhaps limited) brain around LISP well enough to become convinced I understand it enough to make said call. I do tend to think that any technology sufficiently confusing that I cannot understand it well after reasonable effort is of questionable value for wide deployment. > I personally believe LISP is a horrible idea that will have trouble > scaling up, because a large table of LISP mappings is not any easier > to store in FIB than a larger DFZ. The "solution" the LISP folks > think works for this is a side-chain mapping service which the router > can query to setup encapsulation next-hops on-demand, which means if > your FIB isn't big enough to hold every mapping entry, you are > essentially doing flow-based routing, but with "flows" defined as > being toward a remotely-defined end-site rather than toward an > individual IP address (so not quite as bad as "flow-based routing" of > the past, but still bad.) > This is one of the few parts of LISP I do understand and I'm not entirely convinced that it is all that bad because you don't have to do this on core routers, you can push it out pretty close to the customer edge, possibly even on the customer side of said edge. > Maybe I also don't understand LISP and need to RTFM more, but my > current understanding is that it is a dead-end technology without the > ability to dramatically scale up the number of multi-homed end-sites > in a cheaper manner than what is done today with BGP. > I'm not 100% convinced of that. > I think we would be better off with more work on things like SCTP. > I'm not a fan of SCTP, and I think getting enough application level support for it is going to be a bigger uphill battle between chickens and eggs than the IPv6 deployment efforts of the last 5 years. Owen From tlyons at ivenue.com Mon Apr 11 13:11:40 2011 From: tlyons at ivenue.com (Todd Lyons) Date: Mon, 11 Apr 2011 11:11:40 -0700 Subject: Top-posting (was: Barracuda Networks is at it again: Any Suggestions as to anAlternative? ) In-Reply-To: <20110411152100.A6B6D1CC0F@ptavv.es.net> References: <2C81C7AD62B2450DACAC1ADB88CF4226@DELL16> <20110411152100.A6B6D1CC0F@ptavv.es.net> Message-ID: On Mon, Apr 11, 2011 at 8:21 AM, Kevin Oberman wrote: > Of late I have started to get responses from people (not even the person > who top-posted) saying that I should f*** off and that they would post > however they wanted. Very hostile and even threatening. My wife complained once that my responses are hard to read and that I should "just put at the top like the rest of the Internet." I fear I have been passed by... -- Regards...? ? ? Todd "It is the nature of the human species to reject what is true but unpleasant and to embrace what is obviously false but comforting." "You might be a skeptic if you have pedantically argued the topic of pedantry." From johnl at iecc.com Mon Apr 11 13:15:33 2011 From: johnl at iecc.com (John Levine) Date: 11 Apr 2011 18:15:33 -0000 Subject: Top-posting (was: Barracuda Networks is at it again: Any Suggestions as to anAlternative? ) In-Reply-To: Message-ID: <20110411181533.46782.qmail@joyce.lan> It's really impressive how insular a bunch of old timers can be. Coming up next: rants about HTML mail! R's, John In article you write: >On Mon, Apr 11, 2011 at 8:21 AM, Kevin Oberman wrote: >> Of late I have started to get responses from people (not even the person >> who top-posted) saying that I should f*** off and that they would post >> however they wanted. Very hostile and even threatening. > >My wife complained once that my responses are hard to read and that I >should "just put at the top like the rest of the Internet." I fear I >have been passed by... From bret at getjive.com Mon Apr 11 13:46:34 2011 From: bret at getjive.com (Bret Palsson) Date: Mon, 11 Apr 2011 12:46:34 -0600 Subject: altdb Message-ID: I'm trying to register my maintainor object to altdb. Is there any documentation on how to do this? Here is what I sent to auto-dbm at altdb.net mntner: MAINT-JIVE descr: Jive Communications, Inc. admin-c: BEP7-ARIN tech-c: BEP7-ARIN upd-to: routing at getjive.com mnt-nfy: routing at getjive.com auth: MD5-PW 2a930d2ac634aa45e4224e575d2a1bdb mnt-by: MAINT-JIVE changed: routing at getjive.com 20110411 source: ALTDB Thanks, Bret From jra at baylink.com Mon Apr 11 14:08:43 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 11 Apr 2011 15:08:43 -0400 (EDT) Subject: LISP In-Reply-To: Message-ID: <5893631.2231.1302548923892.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "harbor235" > http://www.lisp4.net/ So, for The Rest Of Us, LISP is an attempt to reduce the impact of PI space on router tables in the DFZ? WADR, to hell with them; they have a *lot* more money than I do. :-) Cheers, -- jra From jra at baylink.com Mon Apr 11 14:11:15 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 11 Apr 2011 15:11:15 -0400 (EDT) Subject: Top-posting (was: Barracuda Networks is at it again: Any Suggestions as to anAlternative? ) In-Reply-To: <20110411152100.A6B6D1CC0F@ptavv.es.net> Message-ID: <8801640.2233.1302549075408.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Kevin Oberman" > Subject: Re: Top-posting > Of late I have started to get responses from people (not even the person > who top-posted) saying that I should f*** off and that they would post > however they wanted. Very hostile and even threatening. > > I even manage to bottom post from my iPod. With cut and paste, it's > really not hard, but I guess it's just beyond the capacities of some > and somehow offensive to others. Standard threaded (IE: not top-posted) replies have been the standard for technical mailing lists on the net since I first joined one. In 1983. Anyone who has a problem with it can, in short, go bugger off. Really. (And like you, Keith, because my current MUA, Zimbra, is moronic, I too have to rethread myself by hand, quite a lot of the time. And I do it, because -- like you -- I believe in The Commons) Cheers, -- jra From jra at baylink.com Mon Apr 11 14:14:28 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 11 Apr 2011 15:14:28 -0400 (EDT) Subject: Top-posting (was: Barracuda Networks is at it again: Any Suggestions as to anAlternative? ) In-Reply-To: <20110411181533.46782.qmail@joyce.lan> Message-ID: <5346435.2239.1302549268630.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Levine" > It's really impressive how insular a bunch of old timers can be. > > Coming up next: rants about HTML mail! I never thought I'd say this about John, but PDFTT, folks. :-) Cheers, -- jra From jeroen at mompl.net Mon Apr 11 15:10:13 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 11 Apr 2011 13:10:13 -0700 Subject: internet probe can track you within 690 m Message-ID: <4DA36025.8070709@mompl.net> http://www.newscientist.com/article/dn20336-internet-probe-can-track-you-down-to-within-690-metres.html "The new method zooms in through three stages to locate a target computer. The first stage measures the time it takes to send a data packet to the target and converts it into a distance ? a common geolocation technique that narrows the target's possible location to a radius of around 200 kilometres. (..) Finally, they repeat the landmark search at this more fine-grained level: comparing delay times once more, they establish which landmark server is closest to the target. The result can never be entirely accurate, but it's much better than trying to determine a location by converting the initial delay into a distance or the next best IP-based method. On average their method gets to within 690 metres of the target and can be as close as 100 metres ? good enough to identify the target computer's location to within a few streets." It seems to me to be a rather flaky way of finding out your estimated location. But I guess it could be helpful when the objective is just to create some global database of demographics for marketing and privacy invasion purposes, where specifics of an individual's exact location don't really matter. Besides the latter can always be subpoenaed. ;-) One more reason to use VPN and other such techniques to hide your location. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From swm at emanon.com Mon Apr 11 15:25:47 2011 From: swm at emanon.com (Scott Morris) Date: Mon, 11 Apr 2011 16:25:47 -0400 Subject: internet probe can track you within 690 m In-Reply-To: <4DA36025.8070709@mompl.net> References: <4DA36025.8070709@mompl.net> Message-ID: <4DA363CB.2030509@emanon.com> Aren't they already confused enough when any time I use my EVDO or 3G Tether that someone believes I've been magically transported to New Jersey or wherever the handoff is? ;) Understand the logic behind it, but you probably statistically have just as much chance of being correct as you do incorrect. Scott On 4/11/11 4:10 PM, Jeroen van Aart wrote: [1]http://www.newscientist.com/article/dn20336-internet-probe-can-tr ack-you-down-to-within-690-metres.html "The new method zooms in through three stages to locate a target computer. The first stage measures the time it takes to send a data packet to the target and converts it into a distance - a common geolocation technique that narrows the target's possible location to a radius of around 200 kilometres. (..) Finally, they repeat the landmark search at this more fine-grained level: comparing delay times once more, they establish which landmark server is closest to the target. The result can never be entirely accurate, but it's much better than trying to determine a location by converting the initial delay into a distance or the next best IP-based method. On average their method gets to within 690 metres of the target and can be as close as 100 metres - good enough to identify the target computer's location to within a few streets." It seems to me to be a rather flaky way of finding out your estimated location. But I guess it could be helpful when the objective is just to create some global database of demographics for marketing and privacy invasion purposes, where specifics of an individual's exact location don't really matter. Besides the latter can always be subpoenaed. ;-) One more reason to use VPN and other such techniques to hide your location. Greetings, Jeroen References 1. http://www.newscientist.com/article/dn20336-internet-probe-can-track-you-down-to-within-690-metres.html From mmzinyi at yahoo.com Mon Apr 11 15:31:41 2011 From: mmzinyi at yahoo.com (jacob miller) Date: Mon, 11 Apr 2011 13:31:41 -0700 (PDT) Subject: Bharti Airtel Contact Message-ID: <553858.23090.qm@web39502.mail.mud.yahoo.com> Anyone with a Technical Contact for Bharti Airtel kindly contact me off list. I have been having BGP flaps for much of the day on a link to London. Regards, Jacob From patrick at ianai.net Mon Apr 11 15:36:18 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 11 Apr 2011 16:36:18 -0400 Subject: internet probe can track you within 690 m In-Reply-To: <4DA363CB.2030509@emanon.com> References: <4DA36025.8070709@mompl.net> <4DA363CB.2030509@emanon.com> Message-ID: On Apr 11, 2011, at 4:25 PM, Scott Morris wrote: > Aren't they already confused enough when any time I use my EVDO or 3G > Tether that someone believes I've been magically transported to New > Jersey or wherever the handoff is? ;) > Understand the logic behind it, but you probably statistically have > just as much chance of being correct as you do incorrect. Just like the old days with AOL & their proxies. There are not as many 3G or proxy / VPN users are there are standard users. Therefore, it works - mostly. (Or can work, I have no idea if the particular company / tool under discussion is actually useful.) Data is data. It can be misinterpreted, but it is still data. -- TTFN, patrick > On 4/11/11 4:10 PM, Jeroen van Aart wrote: > > [1]http://www.newscientist.com/article/dn20336-internet-probe-can-tr > ack-you-down-to-within-690-metres.html > "The new method zooms in through three stages to locate a target > computer. The first stage measures the time it takes to send a data > packet to the target and converts it into a distance - a common > geolocation technique that narrows the target's possible location to > a radius of around 200 kilometres. > (..) > Finally, they repeat the landmark search at this more fine-grained > level: comparing delay times once more, they establish which > landmark server is closest to the target. The result can never be > entirely accurate, but it's much better than trying to determine a > location by converting the initial delay into a distance or the next > best IP-based method. On average their method gets to within 690 > metres of the target and can be as close as 100 metres - good enough > to identify the target computer's location to within a few streets." > It seems to me to be a rather flaky way of finding out your > estimated location. But I guess it could be helpful when the > objective is just to create some global database of demographics for > marketing and privacy invasion purposes, where specifics of an > individual's exact location don't really matter. > Besides the latter can always be subpoenaed. ;-) > One more reason to use VPN and other such techniques to hide your > location. > Greetings, > Jeroen > > References > > 1. http://www.newscientist.com/article/dn20336-internet-probe-can-track-you-down-to-within-690-metres.html > From tme at americafree.tv Mon Apr 11 16:29:30 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Mon, 11 Apr 2011 17:29:30 -0400 Subject: internet probe can track you within 690 m In-Reply-To: <4DA36025.8070709@mompl.net> References: <4DA36025.8070709@mompl.net> Message-ID: <0137CB93-D268-463D-9102-EEBD257B3B51@americafree.tv> On Apr 11, 2011, at 4:10 PM, Jeroen van Aart wrote: > http://www.newscientist.com/article/dn20336-internet-probe-can-track-you-down-to-within-690-metres.html > "The new method zooms in through three stages to locate a target computer. The first stage measures the time it takes to send a data packet to the target and converts it into a distance ? a common geolocation technique that narrows the target's possible location to a radius of around 200 kilometres. > (..) > Finally, they repeat the landmark search at this more fine-grained level: comparing delay times once more, they establish which landmark server is closest to the target. The result can never be entirely accurate, but it's much better than trying to determine a location by converting the initial delay into a distance or the next best IP-based method. On average their method gets to within 690 metres of the target and can be as close as 100 metres ? good enough to identify the target computer's location to within a few streets." > > It seems to me to be a rather flaky way of finding out your estimated location. But I guess it could be helpful when the objective is just to create some global database of demographics for marketing and privacy invasion purposes, where specifics of an individual's exact location don't really matter. The idea is to have finer and finer grained locations based on RTTs and a dense mesh of "landmark routers." Of course, if you were using a tunnel or proxy that took N msec of delay, the best they could say is that you were N msec from the tunnel endpoint. It would also be easy to institute something like the old GPS selective availability, with a software tunnel randomly adding a variable delay (say, varying by up to 50 msec every 100 seconds). Regards Marshall > > Besides the latter can always be subpoenaed. ;-) > > One more reason to use VPN and other such techniques to hide your location. > > Greetings, > Jeroen > > -- > http://goldmark.org/jeff/stupid-disclaimers/ > http://linuxmafia.com/~rick/faq/plural-of-virus.html > > From fmartin at linkedin.com Mon Apr 11 16:36:57 2011 From: fmartin at linkedin.com (Franck Martin) Date: Mon, 11 Apr 2011 21:36:57 +0000 Subject: internet probe can track you within 690 m In-Reply-To: <4DA36025.8070709@mompl.net> Message-ID: Don't forget the use for 911 type services. On 4/12/11 8:10 , "Jeroen van Aart" wrote: >http://www.newscientist.com/article/dn20336-internet-probe-can-track-you-d >own-to-within-690-metres.html >"The new method zooms in through three stages to locate a target >computer. The first stage measures the time it takes to send a data >packet to the target and converts it into a distance ? a common >geolocation technique that narrows the target's possible location to a >radius of around 200 kilometres. >(..) >Finally, they repeat the landmark search at this more fine-grained >level: comparing delay times once more, they establish which landmark >server is closest to the target. The result can never be entirely >accurate, but it's much better than trying to determine a location by >converting the initial delay into a distance or the next best IP-based >method. On average their method gets to within 690 metres of the target >and can be as close as 100 metres ? good enough to identify the target >computer's location to within a few streets." > >It seems to me to be a rather flaky way of finding out your estimated >locat From jsw at inconcepts.biz Mon Apr 11 16:53:40 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Mon, 11 Apr 2011 17:53:40 -0400 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> Message-ID: On Mon, Apr 11, 2011 at 2:03 PM, Owen DeLong wrote: > I do tend to think that any technology sufficiently confusing that I cannot > understand it well after reasonable effort is of questionable value > for wide deployment. The secret is to ignore all the crazy acronyms and boil it down to this -- LISP sets up tunnels to remote end-points based on what it learns from a mapping server, and these tunnels may be used by one or more end-to-end flows. >> I personally believe LISP is a horrible idea that will have trouble >> scaling up, because a large table of LISP mappings is not any easier >> to store in FIB than a larger DFZ. ?The "solution" the LISP folks > This is one of the few parts of LISP I do understand and I'm not entirely > convinced that it is all that bad because you don't have to do this on > core routers, you can push it out pretty close to the customer edge, > possibly even on the customer side of said edge. We already have this in the core today, thanks to MPLS. The problem with LISP is the router that does encapsulation, which you can think of as conceptually identical to a PE router, must have a large enough FIB for all simultaneous flows out of the customers behind that PE router. This may be a very large number for an end-user PE router with a bunch of subscribers behind it running P2P file sharing, and may also be very large for a hosting shop with end-users from all over the globe downloading content. In the case of a CDN, one distributed CDN node may have far fewer active flows (installed in FIB) than the size of the DFZ, since the CDN would intend to direct end-users to a geographically-local CDN node. As you know, I like to think of what happens when you receive a DDoS. In the case of LISP, if there are a huge number of source addresses sending just one packet to you that generates some kind of reply, your PE router will query its mapping server, install a new tunnel/next-hop, and transmit the reply packet. If the FIB is not large enough to install every flow, it will churn, creating a DoS condition essentially identical to what we saw with older flow-cache based routers when they were subjected to traffic to/from a very large number of hosts. Like you, I am not 100% sure of my position on LISP, but I do think I understand it has a very serious design limit that probably doesn't make things look any better than "polluting" the DFZ from the perspective of content providers or end-user ISPs. It does have benefits from the carrier perspective because, as you say, it can move the "PE router" into the customer's network and move state information from the carrier to the edge; but I think this comes at a high complexity cost and might result in overall more work/cost for everyone. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From bret at getjive.com Mon Apr 11 17:43:06 2011 From: bret at getjive.com (Bret Palsson) Date: Mon, 11 Apr 2011 16:43:06 -0600 Subject: altdb.net: password length Message-ID: <05FEE0B2-C05A-4B48-A405-0906BF29CEBB@getjive.com> Is there a limit of 8 characters for the CRYPT-PW? -Bret From jeroen at mompl.net Mon Apr 11 17:48:32 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 11 Apr 2011 15:48:32 -0700 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: <4DA38540.4000602@mompl.net> TR Shaw wrote: > Get a linux box or whatever and roll your own. ASSP, DSPAM, Spamassin, or other open source ASSP + exim, on Debian, for sure. BUT, ASSP as of now does not support IPv6 so I am not able to hang my spamfilter on an IPv6 address. :-( Contacting the maintainers is met with utter silence. Another proof there's still a long way to go to get people to change... Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From dholmes at mwdh2o.com Mon Apr 11 17:49:43 2011 From: dholmes at mwdh2o.com (Holmes,David A) Date: Mon, 11 Apr 2011 15:49:43 -0700 Subject: Level 3 Agrees to Purchase Global Crossing In-Reply-To: <4DA30C9D.107@gmail.com> References: <4DA30C9D.107@gmail.com> Message-ID: <922ACC42D498884AA02B3565688AF99531DE256692@USEXMBS01.mwd.h2o> "Way too many players ..." means that the telecom marketplace is good for the consumer, with competition keeping prices low. Many network users feel that prices are still way too high, particularly for high speed circuits and dark fiber, areas in which Level 3 and Global Crossing have specialized. -----Original Message----- From: William Allen Simpson [mailto:william.allen.simpson at gmail.com] Sent: Monday, April 11, 2011 7:14 AM To: NANOG list Subject: Level 3 Agrees to Purchase Global Crossing http://www.bloomberg.com/news/print/2011-04-11/level-3-agrees-to-acquire-global-crossing-in-deal-valued-at-1-9-billion.html The deal will combine two unprofitable companies with total revenue of $6.26 billion as of last year, and cut annualized capital spending by about $40 million, according to the statement. It will also help reduce the pressure on prices, which have declined by as much as 30 percent a year in the industry, said Donna Jaegers, an analyst at DA Davidson & Co. "This is what telecom has needed for a long time," said Denver-based Jaegers, who recommends buying both stocks. "You have way too many players." This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. From mpetach at netflight.com Mon Apr 11 18:08:21 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 11 Apr 2011 16:08:21 -0700 Subject: internet probe can track you within 690 m In-Reply-To: <0137CB93-D268-463D-9102-EEBD257B3B51@americafree.tv> References: <4DA36025.8070709@mompl.net> <0137CB93-D268-463D-9102-EEBD257B3B51@americafree.tv> Message-ID: On Mon, Apr 11, 2011 at 2:29 PM, Marshall Eubanks wrote: > ... > It would also be easy to institute something like the old GPS selective availability, with a software tunnel randomly adding a variable > delay (say, varying by up to 50 msec every 100 seconds). > > Regards > Marshall > Heck...with the amount of buffer bloat in place, I just keep a few torrents running on my T1, and the buffer bloat ensures there's always a nice 100-200msec of extra variability on the RTTs, no extra tunnels needed. ;-) Matt From ras at e-gerbil.net Mon Apr 11 18:24:18 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 11 Apr 2011 18:24:18 -0500 Subject: Level 3 Agrees to Purchase Global Crossing In-Reply-To: <922ACC42D498884AA02B3565688AF99531DE256692@USEXMBS01.mwd.h2o> References: <4DA30C9D.107@gmail.com> <922ACC42D498884AA02B3565688AF99531DE256692@USEXMBS01.mwd.h2o> Message-ID: <20110411232418.GV68199@gerbil.cluepon.net> On Mon, Apr 11, 2011 at 03:49:43PM -0700, Holmes,David A wrote: > "Way too many players ..." means that the telecom marketplace is good > for the consumer, with competition keeping prices low. Many network > users feel that prices are still way too high, particularly for high > speed circuits and dark fiber, areas in which Level 3 and Global > Crossing have specialized. Cute theory, but unfortunately this has no basis in reality. Users can "feel" any way they'd like, but the truth is that the current market prices for wholesale IP transit, in which Level 3 and Global Crossing specialize, are far below cost and are impossible for any carrier to sustain long term. I'm not saying that either L3 or GX runs a completely optimal network (infact I'd say that GX may well be a case study in failure to do so :P), but a simple analysis of the costs of routers, colo, power, crossconnects, optical gear, etc, makes it abundantly clear that the current "rush to the bottom" pricing cannot possibly be supported even under optimal conditions and ignoring other overhead. The situation isn't significantly different for high-speed longhaul capacity, the revenue these these circuits generate at current market prices is barely offsetting their capex on the optical gear at this point. Anyone who told you that there is a cash cow in this particular market is woefully mistaken, any serious money to be had is coming from enterprise customers who can only be reached via unique metro assets. I have no doubt that there will be some modest reduction in competition following the acquisition, but I honestly don't think it is anything to get too worried about. Unlike L3's previous acquisitions (such as Wiltel, Telcove, Looking Glass, etc), it isn't really possible for them to "disappear" the assets from the market following the purchase. GX's longhaul fiber footprint is mostly still owned and operated by Qwest, they were never a big player in IRU dark sales to begin with, and they don't have much in the way of metro fiber assets to speak of. The two companies also not really in any danger of being able to stop the current tide of market transit prices, since this are being driven by many other companies. And L3 has already learned what happens to their market share when they try to alter market pricing by themselves, which is what led to their current Comcast debacle in the first place. The best case scenario that I see here is L3 being able to provide some technical leadership to significantly reduce GX's overhead, and hopefully fix some of their other problem areas too. But personally I'm not convinced that L3 is the technical or market force they used to be, and thus I question whether they'll be able to get it right themselves. Remember, it taks a LOT of work for a big telco to put all the pieces in place correctly, and any mistakes on their part will open the door for smaller carriers to show off the advantages of being nimble. If there is any significant reduction in competition that comes to either carrier, it will do exactly that. Infact, I encourage them to try, it will probably be good for my business. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From jblaum02 at gmail.com Mon Apr 11 18:34:27 2011 From: jblaum02 at gmail.com (Jeff Blaum) Date: Mon, 11 Apr 2011 16:34:27 -0700 Subject: Alternatives to GSLB ? In-Reply-To: References: Message-ID: Just wanted to thank everyone who replied to my question on the list and off-list. Cheers, Jeff On Tue, Apr 5, 2011 at 12:31 PM, Paul W. Roach III wrote: > The downside of anycast for TCP services require state to be replicated in > realtime across all app servers to prevent crappy user experience in the > case where I switch servers mid-transaction. > > On Tue, Apr 5, 2011 at 3:17 PM, Jack Carrozzo wrote: > >> Anycast works. >> >> [...] we are looking for ideas on >> > how to 1) ensure clients are routed to the closest geographical server >> 2) >> > ensure the client hits the server(s) with the shortest path. >> > >> >> No need to deal with that yourself when BGP eats that problem for >> breakfast >> lunch and dinner. >> >> -Jack Carrozzo >> > > From DStaal at usa.net Mon Apr 11 18:39:50 2011 From: DStaal at usa.net (Daniel Staal) Date: Mon, 11 Apr 2011 19:39:50 -0400 Subject: Top-posting In-Reply-To: <8801640.2233.1302549075408.JavaMail.root@benjamin.baylink.com> References: <8801640.2233.1302549075408.JavaMail.root@benjamin.baylink.com> Message-ID: <2EAB3B167507DEE08418E7C9@Mac-Pro.local> --As of April 11, 2011 3:11:15 PM -0400, Jay Ashworth is alleged to have said: >> Of late I have started to get responses from people (not even the person >> who top-posted) saying that I should f*** off and that they would post >> however they wanted. Very hostile and even threatening. >> >> I even manage to bottom post from my iPod. With cut and paste, it's >> really not hard, but I guess it's just beyond the capacities of some >> and somehow offensive to others. > > Standard threaded (IE: not top-posted) replies have been the standard for > technical mailing lists on the net since I first joined one. > > In 1983. > > Anyone who has a problem with it can, in short, go bugger off. Really. --As for the rest, it is mine. I've found my mail has fallen into three basic categories over time: 1) Mailing list, technical or otherwise. 2) Personal discussions. 3) 'Official' work email, of one form or another. Of the three, #1 almost always is either bottom posted, or fully intermixed. #2 I often introduce people to the idea, but once they get it they like it. In both of these it is more important what is replying to what, and what the *current state* of the conversation is. Either one I can rely on the other participants to have the history (or at least have access to it). Top-posting in either context is non-helpful. #3, is always top-posted, and I've grown to like that in that context. The most current post serves as a 'this is where we are right now, and what needs to be done', while the rest tends to preserve the *entire* history, including any parts I was not a part of initially. (For instance: A user sends an email to their boss, who emails the helpdesk, who emails back for clarification, and then forwards on that reply to me. At that point it's often nice to know what the original issue was, or to be able to reach the user directly instead of through several layers of intermediary.) It has different strengths and weaknesses, and can be useful in it's place. Mailing lists are not top-posting's place. ;) Daniel T. Staal (As for HTML email... I've yet to meet an actual human who routinely used HTML-only emails. They are a sure sign of a marketing department's involvement.) --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --------------------------------------------------------------- From jsw at inconcepts.biz Mon Apr 11 18:56:44 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Mon, 11 Apr 2011 19:56:44 -0400 Subject: Level 3 Agrees to Purchase Global Crossing In-Reply-To: <20110411232418.GV68199@gerbil.cluepon.net> References: <4DA30C9D.107@gmail.com> <922ACC42D498884AA02B3565688AF99531DE256692@USEXMBS01.mwd.h2o> <20110411232418.GV68199@gerbil.cluepon.net> Message-ID: If I were a large tier-2 with SFI to one, but not both, of Level3 and GBLX, I would see this acquisition as an opportunity to squeeze peering out of the other network, or eventual combination of both, in trade for not stirring the pot with regulators. Perhaps AS3356 will carry AS6939 IPv6 routes soon, etc. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From williams.bruce at gmail.com Mon Apr 11 19:06:21 2011 From: williams.bruce at gmail.com (Bruce Williams) Date: Mon, 11 Apr 2011 17:06:21 -0700 Subject: Facebook Opens Up Its Hardware Secrets Message-ID: FYI Just weeks before switching on a massive, super-efficient data center in rural Oregon, Facebook is giving away the designs and specifications to the whole thing online. In doing so, the company is breaking a long-established unwritten rule for Web companies: don't share the secrets of your server-stuffed data warehouses http://www.technologyreview.com/computing/37317/?a=f Bruce Williams Concepts, like individuals, have their histories and are just as incapable of withstanding the ravages of time as are individuals. But in and through all this they retain a kind of homesickness for the scenes of their childhood. Soren Kierkegaard From jra at baylink.com Mon Apr 11 19:05:51 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 11 Apr 2011 20:05:51 -0400 (EDT) Subject: Top-posting In-Reply-To: <2EAB3B167507DEE08418E7C9@Mac-Pro.local> Message-ID: <5962062.2285.1302566750987.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Daniel Staal" > --As of April 11, 2011 3:11:15 PM -0400, Jay Ashworth is alleged to > have said: Nope; I really said it. :-) > > Standard threaded (IE: not top-posted) replies have been the standard for > > technical mailing lists on the net since I first joined one. > > > > In 1983. Footnote: Maybe that was more Usenet, that early. :-) > > Anyone who has a problem with it can, in short, go bugger off. > > Really. > > --As for the rest, it is mine. > > I've found my mail has fallen into three basic categories over time: > > 1) Mailing list, technical or otherwise. > 2) Personal discussions. > 3) 'Official' work email, of one form or another. > > Of the three, #1 almost always is either bottom posted, or fully > intermixed. #2 I often introduce people to the idea, but once they get > it they like it. In both of these it is more important what is replying > to what, and what the *current state* of the conversation is. Either one > I can rely on the other participants to have the history (or at least > have access to it). Top-posting in either context is non-helpful. Well put. > #3, is always top-posted, and I've grown to like that in that context. > The most current post serves as a 'this is where we are right now, and > what needs to be done', while the rest tends to preserve the *entire* > history, including any parts I was not a part of initially. (For instance: A > user sends an email to their boss, who emails the helpdesk, who emails back > for clarification, and then forwards on that reply to me. At that point > it's often nice to know what the original issue was, or to be able to reach > the user directly instead of through several layers of intermediary.) I sorely hate to admit it, but you're right. I tried doing traditional quoting on emails in my last position (as IT director in a call center), and everyone else's heads came off and rolled around on the floor; my boss, the controller, actually *asked me to stop*. > It has different strengths and weaknesses, and can be useful in it's > place. Mailing lists are not top-posting's place. ;) We clearly agree, here. Hopefully, we've clarified the reasons why, for anyone who was on the fence. > (As for HTML email... I've yet to meet an actual human who routinely > used HTML-only emails. They are a sure sign of a marketing department's > involvement.) I have. No, not necessarily. Cheers, -- jra From xenophage at godshell.com Mon Apr 11 19:12:17 2011 From: xenophage at godshell.com (Jason Frisvold) Date: Mon, 11 Apr 2011 20:12:17 -0400 Subject: [Nanog] Re: LISP In-Reply-To: References: <8CB341D4-06DF-43F9-9A7F-32F80A76DB73@ias.edu> Message-ID: <4E6F1A42-1845-4EAB-B589-9E5AE1AFC87A@godshell.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 11, 2011, at 11:02 AM, harbor235 wrote: > http://www.lisp4.net/ This sounds a lot like LNP in the telco world. Is the goal here to make IP's "portable" ? Or is this a viable way to access IPv6 from either an IPv4 host or an IPv6 host unfortunate enough to not have full IPv6 tables? And do all of the networks you pass through have to be LISP enabled? > Mike > > On Mon, Apr 11, 2011 at 10:49 AM, Christina Klam wrote: - - --------------------------- Jason 'XenoPhage' Frisvold xenophage at godshell.com - - --------------------------- "Any sufficiently advanced magic is indistinguishable from technology." - - - Niven's Inverse of Clarke's Third Law - -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) iEYEARECAAYFAk2jl6UACgkQ8CjzPZyTUTSmRACeJWp4KxPgZAgIJJBHOXwmPybS Nb0An1KzzLMxBqHP7Yu4pgW4tcA5EcoK =HJL5 - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) iEYEARECAAYFAk2jmOEACgkQ8CjzPZyTUTS6lwCfRmo+6dRqPA7wUgFCAIBB9Xym joEAoIy7OK17bRKN+dfKNwzRcFmpRmSN =lqbk -----END PGP SIGNATURE----- From bmanning at vacation.karoshi.com Mon Apr 11 19:12:30 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 12 Apr 2011 00:12:30 +0000 Subject: Top-posting In-Reply-To: <5962062.2285.1302566750987.JavaMail.root@benjamin.baylink.com> References: <2EAB3B167507DEE08418E7C9@Mac-Pro.local> <5962062.2285.1302566750987.JavaMail.root@benjamin.baylink.com> Message-ID: <20110412001230.GB30891@vacation.karoshi.com.> interleaved posting is considered harmful. /bill On Mon, Apr 11, 2011 at 08:05:51PM -0400, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Daniel Staal" > > > --As of April 11, 2011 3:11:15 PM -0400, Jay Ashworth is alleged to > > have said: > > Nope; I really said it. :-) > > > > Standard threaded (IE: not top-posted) replies have been the standard for > > > technical mailing lists on the net since I first joined one. > > > > > > In 1983. > > Footnote: Maybe that was more Usenet, that early. :-) > > > > Anyone who has a problem with it can, in short, go bugger off. > > > Really. > > > > --As for the rest, it is mine. > > > > I've found my mail has fallen into three basic categories over time: > > > > 1) Mailing list, technical or otherwise. > > 2) Personal discussions. > > 3) 'Official' work email, of one form or another. > > > > Of the three, #1 almost always is either bottom posted, or fully > > intermixed. #2 I often introduce people to the idea, but once they get > > it they like it. In both of these it is more important what is replying > > to what, and what the *current state* of the conversation is. Either one > > I can rely on the other participants to have the history (or at least > > have access to it). Top-posting in either context is non-helpful. > > Well put. > > > #3, is always top-posted, and I've grown to like that in that context. > > The most current post serves as a 'this is where we are right now, and > > what needs to be done', while the rest tends to preserve the *entire* > > history, including any parts I was not a part of initially. (For instance: A > > user sends an email to their boss, who emails the helpdesk, who emails back > > for clarification, and then forwards on that reply to me. At that point > > it's often nice to know what the original issue was, or to be able to reach > > the user directly instead of through several layers of intermediary.) > > I sorely hate to admit it, but you're right. I tried doing traditional > quoting on emails in my last position (as IT director in a call center), > and everyone else's heads came off and rolled around on the floor; my boss, > the controller, actually *asked me to stop*. > > > It has different strengths and weaknesses, and can be useful in it's > > place. Mailing lists are not top-posting's place. ;) > > We clearly agree, here. Hopefully, we've clarified the reasons why, > for anyone who was on the fence. > > > (As for HTML email... I've yet to meet an actual human who routinely > > used HTML-only emails. They are a sure sign of a marketing department's > > involvement.) > > I have. No, not necessarily. > > Cheers, > -- jra From bret at getjive.com Mon Apr 11 19:20:42 2011 From: bret at getjive.com (Bret Palsson) Date: Mon, 11 Apr 2011 18:20:42 -0600 Subject: altdb.net: password length In-Reply-To: References: <05FEE0B2-C05A-4B48-A405-0906BF29CEBB@getjive.com> Message-ID: <7991A393-E217-4385-BAC2-7D7AC795CDF0@getjive.com> Yep! It sure did. Phew I don't need to re-submit. Thanks guys! I received many responses. -Bret On Apr 11, 2011, at 5:22 PM, Andrew Jones wrote: > My understanding is that the implementation of the DES algorithm used > ignores any characters after the first 8, so basically yes. > -Jonesy > > On Mon, 11 Apr 2011 16:43:06 -0600, Bret Palsson wrote: >> Is there a limit of 8 characters for the CRYPT-PW? >> >> -Bret From Valdis.Kletnieks at vt.edu Mon Apr 11 20:14:14 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 11 Apr 2011 21:14:14 -0400 Subject: Level 3 Agrees to Purchase Global Crossing In-Reply-To: Your message of "Mon, 11 Apr 2011 10:27:44 EDT." <16975162.2197.1302532064855.JavaMail.root@benjamin.baylink.com> References: <16975162.2197.1302532064855.JavaMail.root@benjamin.baylink.com> Message-ID: <13158.1302570854@localhost> On Mon, 11 Apr 2011 10:27:44 EDT, Jay Ashworth said: > ----- Original Message ----- > > From: "Dorn Hetzel" > > > Well, maybe they're just admitting it will slow the rate at which > > prices go down :) > > Cause L3 and GBLX are Too Big To Fail, right? Yes, but the *real* question is - will they be able to depeer Cogent? ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rgolodner at infratection.com Mon Apr 11 20:22:23 2011 From: rgolodner at infratection.com (Richard Golodner) Date: Mon, 11 Apr 2011 20:22:23 -0500 Subject: Top-posting In-Reply-To: <2EAB3B167507DEE08418E7C9@Mac-Pro.local> References: <8801640.2233.1302549075408.JavaMail.root@benjamin.baylink.com> <2EAB3B167507DEE08418E7C9@Mac-Pro.local> Message-ID: <1302571343.1732.19.camel@Andromeda> On Mon, 2011-04-11 at 19:39 -0400, Daniel Staal wrote: > Of late I have started to get responses from people (not even the > person > >> who top-posted) saying that I should f*** off and that they would > post > >> however they wanted. Very hostile and even threatening. Too many Outlook users. With just about any other email client it is very easy to bottom post. To those who wish to post as they want demonstrates a certain something about being a professional and an additional personality component that need not be mentioned. Richard Golodner From Valdis.Kletnieks at vt.edu Mon Apr 11 20:28:41 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 11 Apr 2011 21:28:41 -0400 Subject: Top-posting (was: Barracuda Networks is at it again: Any Suggestions as to anAlternative? ) In-Reply-To: Your message of "Mon, 11 Apr 2011 18:15:33 -0000." <20110411181533.46782.qmail@joyce.lan> References: <20110411181533.46782.qmail@joyce.lan> Message-ID: <13754.1302571721@localhost> On Mon, 11 Apr 2011 18:15:33 -0000, John Levine said: > It's really impressive how insular a bunch of old timers can be. > > Coming up next: rants about HTML mail! Vern Schryver once pointed out that a multipart/alternative with a text/plain and text/html was *always* incorrect - if the semantic content was the same, the html coipy was superfluous and shouldn't have been sent, and if the semantic content was different because the html added to it, the text/plain was therefor misleading and shouldn't have been sent. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nccariaga at stluke.com.ph Mon Apr 11 21:36:20 2011 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Tue, 12 Apr 2011 10:36:20 +0800 Subject: Yahoo! Mail Technical Contact Message-ID: <4DA3BAA4.5090206@stluke.com.ph> Hi All, Is there by any chance a Yahoo! Mail Technical Contact is subscribed in this mailing list? Please reply directly to my email. Thank you very much. -nathan From Bryan at bryanfields.net Mon Apr 11 21:58:11 2011 From: Bryan at bryanfields.net (Bryan Fields) Date: Mon, 11 Apr 2011 22:58:11 -0400 Subject: Top-posting In-Reply-To: <1302571343.1732.19.camel@Andromeda> References: <8801640.2233.1302549075408.JavaMail.root@benjamin.baylink.com> <2EAB3B167507DEE08418E7C9@Mac-Pro.local> <1302571343.1732.19.camel@Andromeda> Message-ID: <4DA3BFC3.7000700@bryanfields.net> On 4/11/2011 21:22, Richard Golodner wrote: > Too many Outlook users. With just about any other email client it is > very easy to bottom post. > To those who wish to post as they want demonstrates a certain something > about being a professional and an additional personality component that > need not be mentioned. The issue with outlook/exchange is there is no way to use another client with it. I cannot even force plain text to the internet, the server send it as quoted printable even if I strip all formatting. The outlook email client does not support wrapping text at a given line length either. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From bret at getjive.com Mon Apr 11 22:18:26 2011 From: bret at getjive.com (Bret Palsson) Date: Mon, 11 Apr 2011 21:18:26 -0600 Subject: Top-posting In-Reply-To: <4DA3BFC3.7000700@bryanfields.net> References: <8801640.2233.1302549075408.JavaMail.root@benjamin.baylink.com> <2EAB3B167507DEE08418E7C9@Mac-Pro.local> <1302571343.1732.19.camel@Andromeda> <4DA3BFC3.7000700@bryanfields.net> Message-ID: <2727100896207734757@unknownmsgid> On Apr 11, 2011, at 8:59 PM, Bryan Fields wrote: > On 4/11/2011 21:22, Richard Golodner wrote: >> Too many Outlook users. With just about any other email client it is >> very easy to bottom post. >> To those who wish to post as they want demonstrates a certain something >> about being a professional and an additional personality component that >> need not be mentioned. > > The issue with outlook/exchange is there is no way to use another client with > it. I cannot even force plain text to the internet, the server send it as > quoted printable even if I strip all formatting. > > The outlook email client does not support wrapping text at a given line length > either. > -- > Bryan Fields > > 727-409-1194 - Voice > 727-214-2508 - Fax > http://bryanfields.net > Ewe bad memmories. Can we clean up our language on this list a bit. Throwing words out like Exchange and Outlook make my teeth grind. Thanks for considering my request. From Valdis.Kletnieks at vt.edu Mon Apr 11 22:39:33 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 11 Apr 2011 23:39:33 -0400 Subject: Top-posting In-Reply-To: Your message of "Mon, 11 Apr 2011 22:58:11 EDT." <4DA3BFC3.7000700@bryanfields.net> References: <8801640.2233.1302549075408.JavaMail.root@benjamin.baylink.com> <2EAB3B167507DEE08418E7C9@Mac-Pro.local> <1302571343.1732.19.camel@Andromeda> <4DA3BFC3.7000700@bryanfields.net> Message-ID: <18710.1302579573@localhost> On Mon, 11 Apr 2011 22:58:11 EDT, Bryan Fields said: > The issue with outlook/exchange is there is no way to use another client with > it. I cannot even force plain text to the internet, the server send it as > quoted printable even if I strip all formatting. If the entire body part is expressible in US-ASCII, then the case can be made that using quoted-printable *anyhow* is a bug because it's using an un-necessary encoding.. > The outlook email client does not support wrapping text at a given line length > either. Except for RFC2045, section 6.7, which addresses this: A body which is entirely US-ASCII may also be encoded in Quoted-Printable to ensure the integrity of the data should the message pass through a character-translating, and/or line-wrapping gateway. In other words, "since we can't wrap at anyplace sane, we're worried that a line pretending to be a paragraph will hit the 998-octet SMTP linelength limit." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mpetach at netflight.com Mon Apr 11 23:13:18 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 11 Apr 2011 21:13:18 -0700 Subject: Yahoo! Mail Technical Contact In-Reply-To: <4DA3BAA4.5090206@stluke.com.ph> References: <4DA3BAA4.5090206@stluke.com.ph> Message-ID: On Mon, Apr 11, 2011 at 7:36 PM, Nathanael C. Cariaga wrote: > Hi All, > > Is there by any chance a Yahoo! Mail Technical Contact is subscribed in this > mailing list? ?Please reply directly to my email. > > Thank you very much. > > -nathan Aww...now see, this is the North American *NETWORK* operator's guild list... why couldn't you have asked a networking question? :/ Matt From nccariaga at stluke.com.ph Mon Apr 11 23:28:01 2011 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Tue, 12 Apr 2011 12:28:01 +0800 Subject: Yahoo! Mail Issue Message-ID: <4DA3D4D1.3020002@stluke.com.ph> Hi All, It seems that we're having some problems receiving emails from selected Yahoo! Mail Accounts. I noticed that there is a commonality between the accounts that fails when sending an email to our domain (see email header below) From: "MAILER-DAEMON at nm1.bullet.mail.sg1.yahoo.com" To: *-*-*-*-*a at yahoo.com Sent: Fri, April 8, 2011 6:26:08 PM Subject: Failure Notice Sorry, we were unable to deliver your message to the following address. : Mail server for "stluke.com.ph" unreachable for too long --- Below this line is a copy of the message. Received: from [115.178.12.220] by nm1.bullet.mail.sg1.yahoo.com with NNFMP; 06 Apr 2011 10:19:19 -0000 Received: from [115.178.12.229] by tm1.bullet.mail.sg1.yahoo.com with NNFMP; 06 Apr 2011 10:19:19 -0000 Received: from [127.0.0.1] by omp1006.mail.sg1.yahoo.com with NNFMP; 06 Apr 2011 10:19:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 233210.48944.bm at omp1006.mail.sg1.yahoo.com Received: (qmail 90809 invoked by uid 60001); 6 Apr 2011 10:19:19 -0000 From: "MAILER-DAEMON at nm7.bullet.mail.sg1.yahoo.com" To: *-*-*-*-*r at yahoo.com Sent: Saturday, April 9, 2011 3:28:47 PM Subject: Failure Notice Sorry, we were unable to deliver your message to the following address. <*-*-*-*-*@stluke.com.ph>: Mail server for "stluke.com.ph" unreachable for too long --- Below this line is a copy of the message. Received: from [115.178.12.220] by nm7.bullet.mail.sg1.yahoo.com with NNFMP; 07 Apr 2011 07:22:41 -0000 Received: from [115.178.12.217] by tm1.bullet.mail.sg1.yahoo.com with NNFMP; 07 Apr 2011 07:22:41 -0000 Received: from [127.0.0.1] by omp1002.mail.sg1.yahoo.com with NNFMP; 07 Apr 2011 07:22:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 714595.68144.bm at omp1002.mail.sg1.yahoo.com Received: (qmail 6504 invoked by uid 60001); 7 Apr 2011 07:22:41 -0000 Any comment from Yahoo off the list would be greatly appreciated. Thank you. -nathan From mpetach at netflight.com Mon Apr 11 23:47:55 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 11 Apr 2011 21:47:55 -0700 Subject: Yahoo! Mail Issue In-Reply-To: <4DA3D4D1.3020002@stluke.com.ph> References: <4DA3D4D1.3020002@stluke.com.ph> Message-ID: On Mon, Apr 11, 2011 at 9:28 PM, Nathanael C. Cariaga wrote: > Hi All, > > It seems that we're having some problems receiving emails from selected > Yahoo! Mail Accounts. ?I noticed that there is a commonality between the > accounts that fails when sending an email to our domain (see email header > below) > > From: "MAILER-DAEMON at nm1.bullet.mail.sg1.yahoo.com" > > To: *-*-*-*-*a at yahoo.com > Sent: Fri, April 8, 2011 6:26:08 PM > Subject: Failure Notice > > Sorry, we were unable to deliver your message to the following address. > > : > Mail server for "stluke.com.ph" unreachable for too long Um...it might be easier to get mail, if your host didn't close the connection with a 5xx error. :/ mpetach at hinotori:~> host -t mx stluke.com.ph stluke.com.ph mail is handled by 20 qc.stluke.com.ph. stluke.com.ph mail is handled by 20 mx1.stluke.com.ph. stluke.com.ph mail is handled by 40 gc.stluke.com.ph. mpetach at hinotori:~> nslookup qc.stluke.com.ph. Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: qc.stluke.com.ph Address: 219.90.94.56 mpetach at hinotori:~> mpetach at opstools1:~> telnet 219.90.94.56 25 Trying 219.90.94.56... Connected to static-host-219-90-94-56.tri.ph. Escape character is '^]'. ehlo yahoo.com 554 SMTP synchronization error Connection closed by foreign host. mpetach at opstools1:~> I imagine when port 25 stops giving 5xx failure message back, mail reception might improve. ^_^; Matt From bruns at 2mbit.com Mon Apr 11 23:54:01 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Mon, 11 Apr 2011 22:54:01 -0600 Subject: Yahoo! Mail Issue In-Reply-To: References: <4DA3D4D1.3020002@stluke.com.ph> Message-ID: <4DA3DAE9.9020708@2mbit.com> On 4/11/11 10:47 PM, Matthew Petach wrote: > > > mpetach at opstools1:~> telnet 219.90.94.56 25 > Trying 219.90.94.56... > Connected to static-host-219-90-94-56.tri.ph. > Escape character is '^]'. > ehlo yahoo.com > 554 SMTP synchronization error > Connection closed by foreign host. > mpetach at opstools1:~> > > > I imagine when port 25 stops giving 5xx > failure message back, mail reception > might improve. ^_^; Works fine for me, your getting an error because your trying to send a command before receiving the first 220, aka RFC violation. As long as you connect, wait a moment without trying to send a command, your fine. telnet 219.90.94.56 25 Trying 219.90.94.56... Connected to static-host-219-90-94-56.tri.ph. Escape character is '^]'. 220 stluke.com.ph ESMTP MailCleaner (Community Edition 2010 beta 3) Tue, 12 Apr 2011 12:51:38 +0800 My systems do it too if you try to send a command before waiting for the 220s to finish: telnet mail.sosdg.org 25 Trying 2620:64:0:1::2... Connected to mail.sosdg.org. Escape character is '^]'. 554 SMTP synchronization error Connection closed by foreign host. Its an effective antispam method, because bots rarely bother to wait. They just blast away -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From mpetach at netflight.com Tue Apr 12 00:17:12 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 11 Apr 2011 22:17:12 -0700 Subject: Yahoo! Mail Issue In-Reply-To: <4DA3DAE9.9020708@2mbit.com> References: <4DA3D4D1.3020002@stluke.com.ph> <4DA3DAE9.9020708@2mbit.com> Message-ID: On Mon, Apr 11, 2011 at 9:54 PM, Brielle Bruns wrote: > On 4/11/11 10:47 PM, Matthew Petach wrote: >> mpetach at opstools1:~> ?telnet 219.90.94.56 25 >> Trying 219.90.94.56... >> Connected to static-host-219-90-94-56.tri.ph. >> Escape character is '^]'. >> ehlo yahoo.com >> 554 SMTP synchronization error >> Connection closed by foreign host. >> mpetach at opstools1:~> >> >> >> I imagine when port 25 stops giving 5xx >> failure message back, mail reception >> might improve. ? ^_^; > > > Works fine for me, your getting an error because your trying to send a > command before receiving the first 220, aka RFC violation. ?As long as you > connect, wait a moment without trying to send a command, your fine. Doh! See, that's what happens when you ask networking people to try to troubleshoot mail issues. ^_^;; Sorry about that. :( Matt From nccariaga at stluke.com.ph Tue Apr 12 00:29:19 2011 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Tue, 12 Apr 2011 13:29:19 +0800 Subject: Yahoo! Mail Issue In-Reply-To: References: <4DA3D4D1.3020002@stluke.com.ph> <4DA3DAE9.9020708@2mbit.com> Message-ID: <4DA3E32F.6050907@stluke.com.ph> Thanks anyway. I just find this issue intriguing since not all Yahoo mail accounts are affected. In addition, incoming mails from other domain doesn't seem to be affected. That is why I want to check if it is a network issue :) -nathan On 4/12/2011 1:17 PM, Matthew Petach wrote: > On Mon, Apr 11, 2011 at 9:54 PM, Brielle Bruns wrote: >> On 4/11/11 10:47 PM, Matthew Petach wrote: >>> mpetach at opstools1:~> telnet 219.90.94.56 25 >>> Trying 219.90.94.56... >>> Connected to static-host-219-90-94-56.tri.ph. >>> Escape character is '^]'. >>> ehlo yahoo.com >>> 554 SMTP synchronization error >>> Connection closed by foreign host. >>> mpetach at opstools1:~> >>> >>> >>> I imagine when port 25 stops giving 5xx >>> failure message back, mail reception >>> might improve. ^_^; >> >> >> Works fine for me, your getting an error because your trying to send a >> command before receiving the first 220, aka RFC violation. As long as you >> connect, wait a moment without trying to send a command, your fine. > > Doh! > > See, that's what happens when you ask networking people > to try to troubleshoot mail issues. ^_^;; > > Sorry about that. :( > > Matt > > -- Nathanael C. Cariaga Network & Security Administrator St Luke's Medical Center Tel (QC) : +63 2 723 0101 ext 5520 / 4206 Tel (GC) : +63 2 789 7700 ext 6035 / 6036 Tel : +63 2 356 5686 Mobile : +63 922 8735686 EMail : nccariaga at stluke.com.ph From owen at delong.com Tue Apr 12 00:23:24 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2011 22:23:24 -0700 Subject: Top-posting In-Reply-To: <20110412001230.GB30891@vacation.karoshi.com.> References: <2EAB3B167507DEE08418E7C9@Mac-Pro.local> <5962062.2285.1302566750987.JavaMail.root@benjamin.baylink.com> <20110412001230.GB30891@vacation.karoshi.com.> Message-ID: <5FDFC491-6548-42A3-BE6F-72C7594C14E1@delong.com> I sincerely On Apr 11, 2011, at 5:12 PM, bmanning at vacation.karoshi.com wrote: > interleaved posting is considered harmful. > Disagree. Owen > /bill > > > On Mon, Apr 11, 2011 at 08:05:51PM -0400, Jay Ashworth wrote: >> ----- Original Message ----- >>> From: "Daniel Staal" >> >>> --As of April 11, 2011 3:11:15 PM -0400, Jay Ashworth is alleged to >>> have said: >> >> Nope; I really said it. :-) >> >>>> Standard threaded (IE: not top-posted) replies have been the standard for >>>> technical mailing lists on the net since I first joined one. >>>> >>>> In 1983. >> >> Footnote: Maybe that was more Usenet, that early. :-) >> >>>> Anyone who has a problem with it can, in short, go bugger off. >>>> Really. >>> >>> --As for the rest, it is mine. >>> >>> I've found my mail has fallen into three basic categories over time: >>> >>> 1) Mailing list, technical or otherwise. >>> 2) Personal discussions. >>> 3) 'Official' work email, of one form or another. >>> >>> Of the three, #1 almost always is either bottom posted, or fully >>> intermixed. #2 I often introduce people to the idea, but once they get >>> it they like it. In both of these it is more important what is replying >>> to what, and what the *current state* of the conversation is. Either one >>> I can rely on the other participants to have the history (or at least >>> have access to it). Top-posting in either context is non-helpful. >> >> Well put. >> >>> #3, is always top-posted, and I've grown to like that in that context. >>> The most current post serves as a 'this is where we are right now, and >>> what needs to be done', while the rest tends to preserve the *entire* >>> history, including any parts I was not a part of initially. (For instance: A >>> user sends an email to their boss, who emails the helpdesk, who emails back >>> for clarification, and then forwards on that reply to me. At that point >>> it's often nice to know what the original issue was, or to be able to reach >>> the user directly instead of through several layers of intermediary.) >> >> I sorely hate to admit it, but you're right. I tried doing traditional >> quoting on emails in my last position (as IT director in a call center), >> and everyone else's heads came off and rolled around on the floor; my boss, >> the controller, actually *asked me to stop*. >> >>> It has different strengths and weaknesses, and can be useful in it's >>> place. Mailing lists are not top-posting's place. ;) >> >> We clearly agree, here. Hopefully, we've clarified the reasons why, >> for anyone who was on the fence. >> >>> (As for HTML email... I've yet to meet an actual human who routinely >>> used HTML-only emails. They are a sure sign of a marketing department's >>> involvement.) >> >> I have. No, not necessarily. >> >> Cheers, >> -- jra From owen at delong.com Tue Apr 12 00:42:13 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2011 22:42:13 -0700 Subject: Top-posting In-Reply-To: <4DA3BFC3.7000700@bryanfields.net> References: <8801640.2233.1302549075408.JavaMail.root@benjamin.baylink.com> <2EAB3B167507DEE08418E7C9@Mac-Pro.local> <1302571343.1732.19.camel@Andromeda> <4DA3BFC3.7000700@bryanfields.net> Message-ID: <820F763F-E4EE-4FF1-A54C-200F62C12562@delong.com> On Apr 11, 2011, at 7:58 PM, Bryan Fields wrote: > On 4/11/2011 21:22, Richard Golodner wrote: >> Too many Outlook users. With just about any other email client it is >> very easy to bottom post. >> To those who wish to post as they want demonstrates a certain something >> about being a professional and an additional personality component that >> need not be mentioned. > > The issue with outlook/exchange is there is no way to use another client with > it. I cannot even force plain text to the internet, the server send it as > quoted printable even if I strip all formatting. > I have used Evolution and IMAP with exchange servers in the past, so, I'm not convinced this is an entirely accurate statement. > The outlook email client does not support wrapping text at a given line length > either. I'll skip the obvious conclusion about the quality of the product in question. Owen From rdobbins at arbor.net Tue Apr 12 00:55:00 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 12 Apr 2011 05:55:00 +0000 Subject: Top-posting In-Reply-To: <820F763F-E4EE-4FF1-A54C-200F62C12562@delong.com> References: <8801640.2233.1302549075408.JavaMail.root@benjamin.baylink.com> <2EAB3B167507DEE08418E7C9@Mac-Pro.local> <1302571343.1732.19.camel@Andromeda> <4DA3BFC3.7000700@bryanfields.net> <820F763F-E4EE-4FF1-A54C-200F62C12562@delong.com> Message-ID: <38887F67-6315-4BEB-ADF0-2AA95347BEB2@arbor.net> On Apr 12, 2011, at 12:42 PM, Owen DeLong wrote: > I have used Evolution and IMAP with exchange servers in the past, so, I'm not convinced this is an entirely accurate statement. And in fact, I'm posting this message in plain-text via the OSX Mail.app connected via native Exchange protocols to an Exchange server. There's even a plug-in for Mail.app in order to make inline posting easier. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From fergdawgster at gmail.com Tue Apr 12 01:06:10 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Mon, 11 Apr 2011 23:06:10 -0700 Subject: Top-posting In-Reply-To: <38887F67-6315-4BEB-ADF0-2AA95347BEB2@arbor.net> References: <8801640.2233.1302549075408.JavaMail.root@benjamin.baylink.com> <2EAB3B167507DEE08418E7C9@Mac-Pro.local> <1302571343.1732.19.camel@Andromeda> <4DA3BFC3.7000700@bryanfields.net> <820F763F-E4EE-4FF1-A54C-200F62C12562@delong.com> <38887F67-6315-4BEB-ADF0-2AA95347BEB2@arbor.net> Message-ID: I am top-posting to show that this entire thread is retarded. I certainly could have bottom-posted, because I don't use Outlook for this list, but the point here is -- is this what the NANOG list has really become? Really? So sad. - ferg On Mon, Apr 11, 2011 at 10:55 PM, Dobbins, Roland wrote: > > On Apr 12, 2011, at 12:42 PM, Owen DeLong wrote: > >> I have used Evolution and IMAP with exchange servers in the past, so, I'm not convinced this is an entirely accurate statement. > > > And in fact, I'm posting this message in plain-text via the OSX Mail.app connected via native Exchange protocols to an Exchange server. > > There's even a plug-in for Mail.app in order to make inline posting easier. > -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From nanog at deman.com Tue Apr 12 01:33:59 2011 From: nanog at deman.com (Michael DeMan) Date: Mon, 11 Apr 2011 23:33:59 -0700 Subject: Top-posting (was: Barracuda Networks is at it again: Any Suggestions as to anAlternative? ) In-Reply-To: <20110411181533.46782.qmail@joyce.lan> References: <20110411181533.46782.qmail@joyce.lan> Message-ID: <9991D851-8B15-4362-9AB1-4FF498347F49@deman.com> Call me and old 'hard case' - but I prefer that when I get information via email, that if possible, the relevant information show up immediately. Call me lazy I guess - but I would expect that most folks on this list have also understood good user interface design, and that the least amount of work that needs to be done for the receiver to be able to get their information is frequently the best solution. On the other hand - I must admit that I do often top post and note 'see inline' with heavy use of snipping in order to shorten what has turned into a long topic in order to make it a shorter and more concise topic. I absolutely agree with anybody (or everybody), that wants mailing list archives to be readable. Fortunately we have things called 'computers' that do that quite well - and reorganize the email correspondence on mailing lists back into standard chronological order. I am also not adverse to changing formats - I just think that it is just inefficient. - mike On Apr 11, 2011, at 11:15 AM, John Levine wrote: > It's really impressive how insular a bunch of old timers can be. > > Coming up next: rants about HTML mail! > > R's, > John > > In article you write: >> On Mon, Apr 11, 2011 at 8:21 AM, Kevin Oberman wrote: >>> Of late I have started to get responses from people (not even the person >>> who top-posted) saying that I should f*** off and that they would post >>> however they wanted. Very hostile and even threatening. >> >> My wife complained once that my responses are hard to read and that I >> should "just put at the top like the rest of the Internet." I fear I >> have been passed by... > From joshua.klubi at gmail.com Tue Apr 12 01:41:45 2011 From: joshua.klubi at gmail.com (Joshua William Klubi) Date: Tue, 12 Apr 2011 06:41:45 +0000 Subject: Yahoo! Mail Issue In-Reply-To: References: <4DA3D4D1.3020002@stluke.com.ph> Message-ID: Well yahoo's mx tend to do that a lot. i used to have a lot of bounced emails to yahoo until i implemented dkim, domainkeys and spf then all my yahoo problems disappeared , I just want to know if you have implemented any of these technologies dkim,domainkeys and spf, other wise you would have all those problems Joshua On Tue, Apr 12, 2011 at 4:47 AM, Matthew Petach wrote: > On Mon, Apr 11, 2011 at 9:28 PM, Nathanael C. Cariaga > wrote: > > Hi All, > > > > It seems that we're having some problems receiving emails from selected > > Yahoo! Mail Accounts. I noticed that there is a commonality between the > > accounts that fails when sending an email to our domain (see email header > > below) > > > > From: "MAILER-DAEMON at nm1.bullet.mail.sg1.yahoo.com" > > > > To: *-*-*-*-*a at yahoo.com > > Sent: Fri, April 8, 2011 6:26:08 PM > > Subject: Failure Notice > > > > Sorry, we were unable to deliver your message to the following address. > > > > : > > Mail server for "stluke.com.ph" unreachable for too long > > > Um...it might be easier to get mail, if your host didn't close > the connection with a 5xx error. :/ > > mpetach at hinotori:~> host -t mx stluke.com.ph > stluke.com.ph mail is handled by 20 qc.stluke.com.ph. > stluke.com.ph mail is handled by 20 mx1.stluke.com.ph. > stluke.com.ph mail is handled by 40 gc.stluke.com.ph. > mpetach at hinotori:~> nslookup qc.stluke.com.ph. > Server: 127.0.0.1 > Address: 127.0.0.1#53 > > Non-authoritative answer: > Name: qc.stluke.com.ph > Address: 219.90.94.56 > > mpetach at hinotori:~> > > > > mpetach at opstools1:~> telnet 219.90.94.56 25 > Trying 219.90.94.56... > Connected to static-host-219-90-94-56.tri.ph. > Escape character is '^]'. > ehlo yahoo.com > 554 SMTP synchronization error > Connection closed by foreign host. > mpetach at opstools1:~> > > > I imagine when port 25 stops giving 5xx > failure message back, mail reception > might improve. ^_^; > > Matt > > From nanog at deman.com Tue Apr 12 01:45:52 2011 From: nanog at deman.com (Michael DeMan) Date: Mon, 11 Apr 2011 23:45:52 -0700 Subject: Top-posting In-Reply-To: References: <8801640.2233.1302549075408.JavaMail.root@benjamin.baylink.com> <2EAB3B167507DEE08418E7C9@Mac-Pro.local> <1302571343.1732.19.camel@Andromeda> <4DA3BFC3.7000700@bryanfields.net> <820F763F-E4EE-4FF1-A54C-200F62C12562@delong.com> <38887F67-6315-4BEB-ADF0-2AA95347BEB2@arbor.net> Message-ID: <3EF6EE2E-412C-40DE-BCCF-D516F3175DAF@deman.com> Hi Paul, Your point is taken - but actually this is a bit of a conundrum, at least for me. Generally what I see is that younger people who grew up using email when they were children desire to bottom post or post inline whereas folks that originally utilized email primarily to communicate technical information only generally prefer to top-post. I believe that top-posting is fine and that have also found use for (what do they call it, reverse-hugarian or reverse-polish) notation for doing things like naming and structuring software packages to also be immensely useful. Either way, I ultimately agree with you - except with the possible exception that possibly if the NaNog list really care - they could setup a survey of all list members, have everybody vote, then we know on this list that when we ask questions where we expect timely answers we can expect the answers to possibly be buried in a myriad of text. Another problem with bottom-posting is the of anything above, etc. Cheers - and sorry for having a little late night fun bothering everybody with noting something that I have seen mostly as a social change on how people communicate via email over the past 30 years. - Mike P.S. - meanwhile, for an email list like NaNog - I am still hoping that most folks want efficiency on answers to questions - and if the need old data are clever enough to realize that there are plenty of ways via HTTP to find those 'weirdo top-post commentors' listed with their posts in chronological and/or relevance level - with prior commentary properly sorted. - mfd On Apr 11, 2011, at 11:06 PM, Paul Ferguson wrote: > I am top-posting to show that this entire thread is retarded. > > I certainly could have bottom-posted, because I don't use Outlook for > this list, but the point here is -- is this what the NANOG list has > really become? Really? > > So sad. > > - ferg > > > On Mon, Apr 11, 2011 at 10:55 PM, Dobbins, Roland wrote: > >> >> On Apr 12, 2011, at 12:42 PM, Owen DeLong wrote: >> >>> I have used Evolution and IMAP with exchange servers in the past, so, I'm not convinced this is an entirely accurate statement. >> >> >> And in fact, I'm posting this message in plain-text via the OSX Mail.app connected via native Exchange protocols to an Exchange server. >> >> There's even a plug-in for Mail.app in order to make inline posting easier. >> > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawgster(at)gmail.com > ferg's tech blog: http://fergdawg.blogspot.com/ > From tjc at ecs.soton.ac.uk Tue Apr 12 01:49:17 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Tue, 12 Apr 2011 07:49:17 +0100 Subject: Top-posting (was: Barracuda Networks is at it again: Any Suggestions as to anAlternative? ) In-Reply-To: <9991D851-8B15-4362-9AB1-4FF498347F49@deman.com> References: <20110411181533.46782.qmail@joyce.lan> <9991D851-8B15-4362-9AB1-4FF498347F49@deman.com> Message-ID: On 12 Apr 2011, at 07:33, Michael DeMan wrote: > Call me and old 'hard case' - but I prefer that when I get information via email, that if possible, the relevant information show up immediately. > > Call me lazy I guess - but I would expect that most folks on this list have also understood good user interface design, and that the least amount of work that needs to be done for the receiver to be able to get their information is frequently the best solution. Well indeed, top-posting is just so much more efficient given the volumes of email most of us probably see each day. Back when receiving an email was an event, and your xbiff flag popping up was a cause for excitement, taking time to scroll/page down to the new bottom-posted content in the reply was part of the enjoyment of the whole 'You have new mail' process. But I'm afraid times have changed; bottom-posted email is now an annoyance to most just as a slow-loading web page would be. Tim From nccariaga at stluke.com.ph Tue Apr 12 01:53:53 2011 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Tue, 12 Apr 2011 14:53:53 +0800 Subject: Yahoo! Mail Issue In-Reply-To: References: <4DA3D4D1.3020002@stluke.com.ph> Message-ID: <4DA3F701.6010109@stluke.com.ph> Just to clarify, the problem we are encountering is that emails sent from yahoo does not seem to reach our mail server (even any of our MX records / anti-spam servers). We have neither implemented any of the items you have said (still in the process of doing so). I tried to interview our email users regarding this issue. They said that it was working perfectly before March. Then we started to have this isolated problem since then. On 4/12/2011 2:41 PM, Joshua William Klubi wrote: > Well yahoo's mx tend to do that a lot. i used to have a lot of bounced > emails to yahoo until i implemented dkim, domainkeys and spf then all my > yahoo problems disappeared , > > I just want to know if you have implemented any of > these technologies dkim,domainkeys and spf, other wise you would have > all those problems > > Joshua > > On Tue, Apr 12, 2011 at 4:47 AM, Matthew Petach > wrote: > > On Mon, Apr 11, 2011 at 9:28 PM, Nathanael C. Cariaga > > wrote: > > Hi All, > > > > It seems that we're having some problems receiving emails from > selected > > Yahoo! Mail Accounts. I noticed that there is a commonality > between the > > accounts that fails when sending an email to our domain (see > email header > > below) > > > > From: "MAILER-DAEMON at nm1.bullet.mail.sg1.yahoo.com > " > > > > > To: *-*-*-*-*a at yahoo.com > > Sent: Fri, April 8, 2011 6:26:08 PM > > Subject: Failure Notice > > > > Sorry, we were unable to deliver your message to the following > address. > > > > >: > > Mail server for "stluke.com.ph " > unreachable for too long > > > Um...it might be easier to get mail, if your host didn't close > the connection with a 5xx error. :/ > > mpetach at hinotori:~> host -t mx stluke.com.ph > stluke.com.ph mail is handled by 20 > qc.stluke.com.ph . > stluke.com.ph mail is handled by 20 > mx1.stluke.com.ph . > stluke.com.ph mail is handled by 40 > gc.stluke.com.ph . > mpetach at hinotori:~> nslookup qc.stluke.com.ph . > Server: 127.0.0.1 > Address: 127.0.0.1#53 > > Non-authoritative answer: > Name: qc.stluke.com.ph > Address: 219.90.94.56 > > mpetach at hinotori:~> > > > > mpetach at opstools1:~> telnet 219.90.94.56 25 > Trying 219.90.94.56... > Connected to static-host-219-90-94-56.tri.ph > . > Escape character is '^]'. > ehlo yahoo.com > 554 SMTP synchronization error > Connection closed by foreign host. > mpetach at opstools1:~> > > > I imagine when port 25 stops giving 5xx > failure message back, mail reception > might improve. ^_^; > > Matt > > -- Nathanael C. Cariaga Network & Security Administrator St Luke's Medical Center Tel (QC) : +63 2 723 0101 ext 5520 / 4206 Tel (GC) : +63 2 789 7700 ext 6035 / 6036 Tel : +63 2 356 5686 Mobile : +63 922 8735686 EMail : nccariaga at stluke.com.ph From chris at team.dcsi.net.au Tue Apr 12 02:04:56 2011 From: chris at team.dcsi.net.au (Christopher Balmain) Date: Tue, 12 Apr 2011 17:04:56 +1000 Subject: Yahoo! Mail Issue In-Reply-To: <4DA3E32F.6050907@stluke.com.ph> References: <4DA3D4D1.3020002@stluke.com.ph> <4DA3DAE9.9020708@2mbit.com> <4DA3E32F.6050907@stluke.com.ph> Message-ID: <1302591896.2158.94.camel@chris-laptop> We had a lot of issues delivering mail to yahoo.com.sg about a year ago (just the .sg domain, plain .com was fine). Could establish connection but it'd die halfway through transferring mail. A static route to drop the MTU (for their subnet only) to 1000 fixed the problem right up. Not sure if pmtud was/is broken or what. - Chris On Tue, 2011-04-12 at 15:29 +1000, Nathanael C. Cariaga wrote: > Thanks anyway. I just find this issue intriguing since not all Yahoo > mail accounts are affected. In addition, incoming mails from other > domain doesn't seem to be affected. That is why I want to check if it > is a network issue :) > > -nathan > > On 4/12/2011 1:17 PM, Matthew Petach wrote: > > On Mon, Apr 11, 2011 at 9:54 PM, Brielle Bruns wrote: > >> On 4/11/11 10:47 PM, Matthew Petach wrote: > >>> mpetach at opstools1:~> telnet 219.90.94.56 25 > >>> Trying 219.90.94.56... > >>> Connected to static-host-219-90-94-56.tri.ph. > >>> Escape character is '^]'. > >>> ehlo yahoo.com > >>> 554 SMTP synchronization error > >>> Connection closed by foreign host. > >>> mpetach at opstools1:~> > >>> > >>> > >>> I imagine when port 25 stops giving 5xx > >>> failure message back, mail reception > >>> might improve. ^_^; > >> > >> > >> Works fine for me, your getting an error because your trying to send a > >> command before receiving the first 220, aka RFC violation. As long as you > >> connect, wait a moment without trying to send a command, your fine. > > > > Doh! > > > > See, that's what happens when you ask networking people > > to try to troubleshoot mail issues. ^_^;; > > > > Sorry about that. :( > > > > Matt > > > > > From nccariaga at stluke.com.ph Tue Apr 12 02:12:29 2011 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Tue, 12 Apr 2011 15:12:29 +0800 Subject: Yahoo! Mail Issue In-Reply-To: <1302591896.2158.94.camel@chris-laptop> References: <4DA3D4D1.3020002@stluke.com.ph> <4DA3DAE9.9020708@2mbit.com> <4DA3E32F.6050907@stluke.com.ph> <1302591896.2158.94.camel@chris-laptop> Message-ID: <4DA3FB5D.5040505@stluke.com.ph> Strangely though I noticed that the email accounts that seems to be affected by our concern seems to be related to the Yahoo SG servers..... On 4/12/2011 3:04 PM, Christopher Balmain wrote: > We had a lot of issues delivering mail to yahoo.com.sg about a year ago > (just the .sg domain, plain .com was fine). Could establish connection > but it'd die halfway through transferring mail. A static route to drop > the MTU (for their subnet only) to 1000 fixed the problem right up. > > Not sure if pmtud was/is broken or what. > > - Chris > > On Tue, 2011-04-12 at 15:29 +1000, Nathanael C. Cariaga wrote: >> Thanks anyway. I just find this issue intriguing since not all Yahoo >> mail accounts are affected. In addition, incoming mails from other >> domain doesn't seem to be affected. That is why I want to check if it >> is a network issue :) >> >> -nathan >> >> On 4/12/2011 1:17 PM, Matthew Petach wrote: >>> On Mon, Apr 11, 2011 at 9:54 PM, Brielle Bruns wrote: >>>> On 4/11/11 10:47 PM, Matthew Petach wrote: >>>>> mpetach at opstools1:~> telnet 219.90.94.56 25 >>>>> Trying 219.90.94.56... >>>>> Connected to static-host-219-90-94-56.tri.ph. >>>>> Escape character is '^]'. >>>>> ehlo yahoo.com >>>>> 554 SMTP synchronization error >>>>> Connection closed by foreign host. >>>>> mpetach at opstools1:~> >>>>> >>>>> >>>>> I imagine when port 25 stops giving 5xx >>>>> failure message back, mail reception >>>>> might improve. ^_^; >>>> >>>> >>>> Works fine for me, your getting an error because your trying to send a >>>> command before receiving the first 220, aka RFC violation. As long as you >>>> connect, wait a moment without trying to send a command, your fine. >>> >>> Doh! >>> >>> See, that's what happens when you ask networking people >>> to try to troubleshoot mail issues. ^_^;; >>> >>> Sorry about that. :( >>> >>> Matt >>> >>> >> > > -- Nathanael C. Cariaga Network & Security Administrator St Luke's Medical Center Tel (QC) : +63 2 723 0101 ext 5520 / 4206 Tel (GC) : +63 2 789 7700 ext 6035 / 6036 Tel : +63 2 356 5686 Mobile : +63 922 8735686 EMail : nccariaga at stluke.com.ph From nanog at deman.com Tue Apr 12 02:08:56 2011 From: nanog at deman.com (Michael DeMan) Date: Tue, 12 Apr 2011 00:08:56 -0700 Subject: Top-posting (was: Barracuda Networks is at it again: Any Suggestions as to anAlternative? ) In-Reply-To: References: <20110411181533.46782.qmail@joyce.lan> <9991D851-8B15-4362-9AB1-4FF498347F49@deman.com> Message-ID: <023D7C80-512B-420D-BD9C-12F96E1FF752@deman.com> I really don't think anybody is concerned about how fast the email downloads anymore. Rather it is more of a matter of how long it takes us humans to process the incredible volume of information we are expected to process. I have no problem either 'top posting' or 'bottom posting' - but I agree it would be good for the NaNog list to decide on a policy. I say we all vote. The ultimate question on email etiquette is naturally how to properly identify inline commentary. Top-post is definitely the most efficient for that. For instance, if I have a lengthy correspondence with a peer who may or may not speed English, the top-post is always respected, and from there it is quite easy (because it is in the top) to note that other commentary is inline - and (as I mentioned before) - to remove unnecessary material while leaving short portions of material relevant. To get back on topic about using email efficiently and get away from peoples personal preferences, I will say the following. #1) I have no disagreement about whether to top-post or bottom-post on this list or any other - given that there is a policy in place. Maintaing communications is the most important thing. #2) I still do not understand how 'bottom posters' reference material from prior e-mails in their replies? Perhaps I am just ignorant. I often have lengthy business and technical communications which some times require a bit of snipping here and there - the best way to notify somebody you have the prior conversation is to say it right up front? #3) These kinds of things become even more important when working with non-native English speakers. #4) I still seem to believe (maybe I am wrong) - that 'bottom posters' thing that an individual email to list is supposed to be an 'archive' - I wholly disagree. On Apr 11, 2011, at 11:49 PM, Tim Chown wrote: > > On 12 Apr 2011, at 07:33, Michael DeMan wrote: > >> Call me and old 'hard case' - but I prefer that when I get information via email, that if possible, the relevant information show up immediately. >> >> Call me lazy I guess - but I would expect that most folks on this list have also understood good user interface design, and that the least amount of work that needs to be done for the receiver to be able to get their information is frequently the best solution. > > Well indeed, top-posting is just so much more efficient given the volumes of email most of us probably see each day. > > Back when receiving an email was an event, and your xbiff flag popping up was a cause for excitement, taking time to scroll/page down to the new bottom-posted content in the reply was part of the enjoyment of the whole 'You have new mail' process. But I'm afraid times have changed; bottom-posted email is now an annoyance to most just as a slow-loading web page would be. > > Tim From mpetach at netflight.com Tue Apr 12 02:33:05 2011 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 12 Apr 2011 00:33:05 -0700 Subject: Yahoo! Mail Issue In-Reply-To: <4DA3FB5D.5040505@stluke.com.ph> References: <4DA3D4D1.3020002@stluke.com.ph> <4DA3DAE9.9020708@2mbit.com> <4DA3E32F.6050907@stluke.com.ph> <1302591896.2158.94.camel@chris-laptop> <4DA3FB5D.5040505@stluke.com.ph> Message-ID: On Tue, Apr 12, 2011 at 12:12 AM, Nathanael C. Cariaga wrote: > Strangely though I noticed that the email accounts that seems to be affected > by our concern seems to be related to the Yahoo SG servers..... > Oh. You don't seem to want to accept connections from the singapore servers at all: -bash-3.2$ telnet qc.stluke.com.ph 25 Trying 219.90.94.56... Connected to qc.stluke.com.ph. Escape character is '^]'. 550 Blacklisted: Blocked - see http://www.spamcop.net/bl.shtml?115.178.12.223 Connection closed by foreign host. -bash-3.2$ So, they really can't send mail to your users--but it's your machine rejecting the connection. :/ Matt > On 4/12/2011 3:04 PM, Christopher Balmain wrote: >> >> We had a lot of issues delivering mail to yahoo.com.sg about a year ago >> (just the .sg domain, plain .com was fine). Could establish connection >> but it'd die halfway through transferring mail. A static route to drop >> the MTU (for their subnet only) to 1000 fixed the problem right up. >> >> Not sure if pmtud was/is broken or what. >> >> - Chris >> >> On Tue, 2011-04-12 at 15:29 +1000, Nathanael C. Cariaga wrote: >>> >>> Thanks anyway. ?I just find this issue intriguing since not all Yahoo >>> mail accounts are affected. ?In addition, incoming mails from other >>> domain doesn't seem to be affected. ?That is why I want to check if it >>> is a network issue :) >>> >>> -nathan >>> >>> On 4/12/2011 1:17 PM, Matthew Petach wrote: >>>> >>>> On Mon, Apr 11, 2011 at 9:54 PM, Brielle Bruns ? wrote: >>>>> >>>>> On 4/11/11 10:47 PM, Matthew Petach wrote: >>>>>> >>>>>> mpetach at opstools1:~> ? ? telnet 219.90.94.56 25 >>>>>> Trying 219.90.94.56... >>>>>> Connected to static-host-219-90-94-56.tri.ph. >>>>>> Escape character is '^]'. >>>>>> ehlo yahoo.com >>>>>> 554 SMTP synchronization error >>>>>> Connection closed by foreign host. >>>>>> mpetach at opstools1:~> >>>>>> >>>>>> >>>>>> I imagine when port 25 stops giving 5xx >>>>>> failure message back, mail reception >>>>>> might improve. ? ^_^; >>>>> >>>>> >>>>> Works fine for me, your getting an error because your trying to send a >>>>> command before receiving the first 220, aka RFC violation. ?As long as >>>>> you >>>>> connect, wait a moment without trying to send a command, your fine. >>>> >>>> Doh! >>>> >>>> See, that's what happens when you ask networking people >>>> to try to troubleshoot mail issues. ?^_^;; >>>> >>>> Sorry about that. ?:( >>>> >>>> Matt >>>> >>>> >>> >> >> > > -- > Nathanael C. Cariaga > Network & Security Administrator > St Luke's Medical Center > > Tel (QC) : ?+63 2 723 0101 ext 5520 / 4206 > Tel (GC) : ?+63 2 789 7700 ext 6035 / 6036 > Tel ? ? ?: ?+63 2 356 5686 > Mobile ? : ?+63 922 8735686 > EMail ? ?: ?nccariaga at stluke.com.ph > > From swmike at swm.pp.se Tue Apr 12 02:50:04 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 12 Apr 2011 09:50:04 +0200 (CEST) Subject: Top-posting (was: Barracuda Networks is at it again: Any Suggestions as to anAlternative? ) In-Reply-To: <023D7C80-512B-420D-BD9C-12F96E1FF752@deman.com> References: <20110411181533.46782.qmail@joyce.lan> <9991D851-8B15-4362-9AB1-4FF498347F49@deman.com> <023D7C80-512B-420D-BD9C-12F96E1FF752@deman.com> Message-ID: On Tue, 12 Apr 2011, Michael DeMan wrote: > The ultimate question on email etiquette is naturally how to properly > identify inline commentary. It's not a problem. Inline is done by trimming lines that are not needed and quoted text is prefaced by a > sign. So if the email you're reading doesn't have a few lines of > followed by text, the sender doesn't know how to properly quote/trim and answer inline and most of the time their text is not worth reading anyway. -- Mikael Abrahamsson email: swmike at swm.pp.se From tvhawaii at shaka.com Tue Apr 12 03:22:23 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Mon, 11 Apr 2011 22:22:23 -1000 Subject: Top-posting (was: Barracuda Networks is at it again: AnySuggestions as to anAlternative? ) References: <20110411181533.46782.qmail@joyce.lan><9991D851-8B15-4362-9AB1-4FF498347F49@deman.com> Message-ID: <858CD73035FD4F07A1E73376B162D169@DELL16> Tim Chown wrote: > Well indeed, top-posting is just so much more efficient given the volumes of email most of us probably see each day. Top posting works in conversations you are having with someone, usually just one person, because you are aware of what's been said. If one comes into a conversation with many people and reads the top post, there is no reference to what that applies to unless you've been following the conversation from the beginning. I wonder if anyone actually took the time to read the relevant links on the NANOG page gord referred to? http://www.tux.org/lkml/#s3-9 From fweimer at bfk.de Tue Apr 12 03:34:43 2011 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 12 Apr 2011 08:34:43 +0000 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: (Justin Scott's message of "Sat\, 9 Apr 2011 00\:42\:23 -0400") References: Message-ID: <82r597zx3w.fsf@mid.bfk.de> * Justin Scott: >> No such luck: They want me to PAY FOR AN ENTIRE YEAR for >> which I did NOT receive service and then for the current (upcoming >> year). Sorry - I don't allow myself to be ripped off like that. > > Hi John, this is actually a pretty common practice for service > subscription models where the software and its components (spam filter > rules in this case) are being continually updated. But it's not been updated during the sabbatical. In this regard, it's very different from crisis support services, where such a model is still obnoxious, but at least makes some sense. > but you're going to benefit NOW from work that was done at that time > (the un-paid period) AND all the future updates that come out during > your new renewal period. Seems doubtful, given the volatility of filtering rules. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From luigi at net.t-labs.tu-berlin.de Tue Apr 12 03:52:10 2011 From: luigi at net.t-labs.tu-berlin.de (Luigi Iannone) Date: Tue, 12 Apr 2011 10:52:10 +0200 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> Message-ID: <9C25CBDD-0AA5-499C-93FB-83859455AE65@net.t-labs.tu-berlin.de> On 11, Apr, 2011, at 17:26 , Owen DeLong wrote: >>>> >>>> But can you explain better? Why should LISP require more IP space than normal IPv4 deployment? >>>> >>>> If you are a new site, you ask for an IP block. This is independent from whether or not you will use LISP. >>>> >>> Sure, but, if you also need locators, don't you need additional IP space to use for locators? >> >> No, those are the IP address that you provider gives to your border router. >> > Right... In addition to my provider independent addresses... That's more address space than is required > if I am not using LISP. > No, you just use the IP addresses of the interface to your upstream as "locators". Those addresses are there anyway, right? So using LISP is not adding anything. >> >> No true. I ask for a PI block that I will use as EID-Prefix, then the locators are part of the address space of my providers. >> There is no duplication. >> >> > Right... Ordinarily, without LISP, I get a PI block and use that for EID and the routing is based on the > EID prefix. With LISP, the EID prefix is PI and I use additional PA resources to do the routing locators. > That's what I meant by duplication. There are additional PA resources required on top of the PI in order > to make LISP work. I still do not see this duplication (may be I need more coffee this morning..) You do not need to modify anything in the PA space of your provider. Those resources are there and are used to make your block reachable also without LISP. Luigi From luigi at net.t-labs.tu-berlin.de Tue Apr 12 03:59:32 2011 From: luigi at net.t-labs.tu-berlin.de (Luigi Iannone) Date: Tue, 12 Apr 2011 10:59:32 +0200 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> Message-ID: <768DDE65-C091-4A48-97E4-92F3E51D6042@net.t-labs.tu-berlin.de> On 11, Apr, 2011, at 23:53 , Jeff Wheeler wrote: > On Mon, Apr 11, 2011 at 2:03 PM, Owen DeLong wrote: >> I do tend to think that any technology sufficiently confusing that I cannot >> understand it well after reasonable effort is of questionable value >> for wide deployment. > > The secret is to ignore all the crazy acronyms and boil it down to > this -- LISP sets up tunnels to remote end-points based on what it > learns from a mapping server, and these tunnels may be used by one or > more end-to-end flows. > >>> I personally believe LISP is a horrible idea that will have trouble >>> scaling up, because a large table of LISP mappings is not any easier >>> to store in FIB than a larger DFZ. The "solution" the LISP folks >> This is one of the few parts of LISP I do understand and I'm not entirely >> convinced that it is all that bad because you don't have to do this on >> core routers, you can push it out pretty close to the customer edge, >> possibly even on the customer side of said edge. > > We already have this in the core today, thanks to MPLS. The problem > with LISP is the router that does encapsulation, which you can think > of as conceptually identical to a PE router, must have a large enough > FIB for all simultaneous flows out of the customers behind that PE > router. This may be a very large number for an end-user PE router > with a bunch of subscribers behind it running P2P file sharing, and > may also be very large for a hosting shop with end-users from all over > the globe downloading content. This is not true. There are several works out there showing that the FIB will not grow as you are saying. Luigi > In the case of a CDN, one distributed > CDN node may have far fewer active flows (installed in FIB) than the > size of the DFZ, since the CDN would intend to direct end-users to a > geographically-local CDN node. > > As you know, I like to think of what happens when you receive a DDoS. > In the case of LISP, if there are a huge number of source addresses > sending just one packet to you that generates some kind of reply, your > PE router will query its mapping server, install a new > tunnel/next-hop, and transmit the reply packet. If the FIB is not > large enough to install every flow, it will churn, creating a DoS > condition essentially identical to what we saw with older flow-cache > based routers when they were subjected to traffic to/from a very large > number of hosts. > > Like you, I am not 100% sure of my position on LISP, but I do think I > understand it has a very serious design limit that probably doesn't > make things look any better than "polluting" the DFZ from the > perspective of content providers or end-user ISPs. It does have > benefits from the carrier perspective because, as you say, it can move > the "PE router" into the customer's network and move state information > from the carrier to the edge; but I think this comes at a high > complexity cost and might result in overall more work/cost for > everyone. > > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > From nccariaga at stluke.com.ph Tue Apr 12 04:22:24 2011 From: nccariaga at stluke.com.ph (Nathanael C. Cariaga) Date: Tue, 12 Apr 2011 17:22:24 +0800 Subject: Yahoo! Mail Issue In-Reply-To: References: <4DA3D4D1.3020002@stluke.com.ph> <4DA3DAE9.9020708@2mbit.com> <4DA3E32F.6050907@stluke.com.ph> <1302591896.2158.94.camel@chris-laptop> <4DA3FB5D.5040505@stluke.com.ph> Message-ID: <4DA419D0.8050708@stluke.com.ph> Oh well... Just have to inform our users :( Thanks! =) ps. I'm just wondering why yahoo doesn't inform their users that the email that they sent was blocked because of their servers were listed in a blocklist (inspite that the server is able to return a correct reject code 550) On 4/12/2011 3:33 PM, Matthew Petach wrote: > -bash-3.2$ telnet qc.stluke.com.ph 25 > Trying 219.90.94.56... > Connected to qc.stluke.com.ph. > Escape character is '^]'. > 550 Blacklisted: Blocked - seehttp://www.spamcop.net/bl.shtml?115.178.12.223 > Connection closed by foreign host. > -bash-3.2$ > -- From ops.lists at gmail.com Tue Apr 12 05:06:09 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 12 Apr 2011 15:36:09 +0530 Subject: Yahoo! Mail Issue In-Reply-To: <4DA419D0.8050708@stluke.com.ph> References: <4DA3D4D1.3020002@stluke.com.ph> <4DA3DAE9.9020708@2mbit.com> <4DA3E32F.6050907@stluke.com.ph> <1302591896.2158.94.camel@chris-laptop> <4DA3FB5D.5040505@stluke.com.ph> <4DA419D0.8050708@stluke.com.ph> Message-ID: Tell you the truth, you shouldnt be dropping the connection right at the smtp banner with a 5xx - return it after RCPT TO. On Tue, Apr 12, 2011 at 2:52 PM, Nathanael C. Cariaga wrote: > Oh well... Just have to inform our users :( > > Thanks! =) > > > ps. ?I'm just wondering why yahoo doesn't inform their users that the email > that they sent was blocked because of their servers were listed in a > blocklist (inspite that the server is able to return a correct reject code > 550) -- Suresh Ramasubramanian (ops.lists at gmail.com) From arnold at nipper.de Tue Apr 12 05:13:09 2011 From: arnold at nipper.de (Arnold Nipper) Date: Tue, 12 Apr 2011 12:13:09 +0200 Subject: Top-posting In-Reply-To: <3EF6EE2E-412C-40DE-BCCF-D516F3175DAF@deman.com> References: <8801640.2233.1302549075408.JavaMail.root@benjamin.baylink.com> <2EAB3B167507DEE08418E7C9@Mac-Pro.local> <1302571343.1732.19.camel@Andromeda> <4DA3BFC3.7000700@bryanfields.net> <820F763F-E4EE-4FF1-A54C-200F62C12562@delong.com> <38887F67-6315-4BEB-ADF0-2AA95347BEB2@arbor.net> <3EF6EE2E-412C-40DE-BCCF-D516F3175DAF@deman.com> Message-ID: <4DA425B5.4060905@nipper.de> on 12.04.2011 08:45 Michael DeMan wrote: > Generally what I see is that younger people who grew up using email > when they were children desire to bottom post or post inline whereas > folks that originally utilized email primarily to communicate > technical information only generally prefer to top-post. > I would say, it's just the other way round. Just my .02? Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 9259 299 mobile: +49 152 53717690 fax: +49 6224 9259 333 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From darcy at druid.net Tue Apr 12 06:12:41 2011 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Tue, 12 Apr 2011 07:12:41 -0400 Subject: Top-posting (was: Barracuda Networks is at it again: Any Suggestions as to anAlternative? ) In-Reply-To: References: <20110411181533.46782.qmail@joyce.lan> <9991D851-8B15-4362-9AB1-4FF498347F49@deman.com> Message-ID: <20110412071241.3ae87cd8.darcy@druid.net> On Tue, 12 Apr 2011 07:49:17 +0100 Tim Chown wrote: >> Call me and old 'hard case' - but I prefer that when I get information >> via email, that if possible, the relevant information show up >> immediately. Right. And the most relevant information is the snippet being replied to in that email - or that part of the email. > Well indeed, top-posting is just so much more efficient given the > volumes of email most of us probably see each day. Indeed. It lets us filter out people who don't understand the protocol and probably have less useful information for us. > Back when receiving an email was an event, and your xbiff flag > popping up was a cause for excitement, taking time to scroll/page down Back then we also trimmed the text so that we didn't have to page down a few screens to see the reply. Then, like now, if someone can't be bothered to compose a message properly I just move on. Also back then we still read lots of messages. We just used Usenet instead of email. Now that email has supplanted Usenet for many discussion groups (a good thing IMHO) we get more mail. I find that the amount of time spent reading discussions has been pretty steady over the years. It's just the number of groups that has decreased as has the medium. The way I see it, I read many orders of magnitude more messages than I send. That tells me that the bulk of the work involved should be in composing. The work composing is multiplied by 1. The work reading can be multiplied by many thousands. > changed; bottom-posted email is now an annoyance to most just as a > slow-loading web page would be. It's only an annoyance if you try to repeat the entire thread in each message. The basic rule is not "you must bottom post." It is "you must trim and bottom post." For more detail we have archives. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From ljakab at ac.upc.edu Tue Apr 12 06:15:15 2011 From: ljakab at ac.upc.edu (Lori Jakab) Date: Tue, 12 Apr 2011 13:15:15 +0200 Subject: [Nanog] Re: LISP In-Reply-To: <4E6F1A42-1845-4EAB-B589-9E5AE1AFC87A@godshell.com> References: <8CB341D4-06DF-43F9-9A7F-32F80A76DB73@ias.edu> <4E6F1A42-1845-4EAB-B589-9E5AE1AFC87A@godshell.com> Message-ID: <4DA43443.7060906@ac.upc.edu> On 04/12/2011 02:12 AM, Jason Frisvold wrote: > On Apr 11, 2011, at 11:02 AM, harbor235 wrote: > > http://www.lisp4.net/ > > This sounds a lot like LNP in the telco world. Is the goal here to > make IP's "portable" ? One of the goals, yes. > Or is this a viable way to access IPv6 from either an IPv4 host or an > IPv6 host unfortunate enough to not have full IPv6 tables? LISP will not do translation for you, so an IPv6-only host will not be able to talk to an IPv4-only host by just using LISP. However, solving the problem of not having full IPv6 tables is possible in two ways: 1) you use IPv4 locators so basically tunnel the traffic over IPv4; or 2) use a proxy tunnel router that does have access to full IPv6 tables. > > And do all of the networks you pass through have to be LISP enabled? Ideally, the source and destination networks both have to be LISP enabled, the core doesn't have to know anything about LISP. It is however possible for LISP enabled sites to communicate with sites not deploying LISP, using proxy tunnel routers deployed by third parties. For more discussion about how this might be deployed see Section 4 of the LISP deployment document: http://tools.ietf.org/html/draft-jakab-lisp-deployment-03#section-4 Regards, -- Lori Jakab UPC Advanced Broadband Communications Center From gordslater at ieee.org Tue Apr 12 06:17:54 2011 From: gordslater at ieee.org (gord) Date: Tue, 12 Apr 2011 12:17:54 +0100 Subject: =?US-ASCII?Q?Re=3A_Top-posting_=28was=3A_Barracuda_Networks_is_at_?= =?US-ASCII?Q?it_again=3A_Any=09Suggestions_as_to_anAlternative=3F_=29?= In-Reply-To: <023D7C80-512B-420D-BD9C-12F96E1FF752@deman.com> References: <20110411181533.46782.qmail@joyce.lan> <9991D851-8B15-4362-9AB1-4FF498347F49@deman.com> <023D7C80-512B-420D-BD9C-12F96E1FF752@deman.com> Message-ID: On Tue, 2011-04-12 at 00:08 -0700, Michael DeMan wrote: Rather it is more of a matter of how long it takes us humans to process the incredible volume of information we are expected to process. > > I have no problem either 'top posting' or 'bottom posting' - but I agree it would be good for the NaNog list to decide on a policy. > There is a policy already in place - in the NANOG General Mailing List Posting Convention. I linked to it when I first commented that I couldn't follow the flow about filtering ops for large-scale mail queues. For anyone has trouble accessing the internet at http://www.nanog.org/mailinglist/listfaqs/generalfaq.php?qt=convent here's what it says.. "Format When posting to the NANOG list please avoid: 1. Top-posting, i.e., putting your reply right on top of the message you're responding to ....." Pedants will note, before it causes yet another war, that I haven't quoted it with " > " because it is a body of text not a previous email contribution to the list. Sadly, my initial observation in the thread has prompted 3 rather obnoxious off-list emails. Those ASs can now whistle if they expect anything from us, operationally or otherwise. Sad. I found the thread particularly hard to follow once top-posting had started because I scan the NANOG list for operational issues and requests, not spamtools, so I was unfamiliar with some of the sales terms passed about, even though I have run BSD-based systems for several high-volume streams in a ISP environment myself. I wasn't pedantic or impolite enough to suggest that it was off-topic here (which, technically, it is), simply saying that it was doing my head in (because of the top posting breaking the flow) to follow it all when I could only give it 10 seconds (max) per post. gord -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From nick at foobar.org Tue Apr 12 06:31:08 2011 From: nick at foobar.org (Nick Hilliard) Date: Tue, 12 Apr 2011 12:31:08 +0100 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: <385CE1B4-5D95-4B01-93B5-F655CBB2624F@gmail.com> References: <385CE1B4-5D95-4B01-93B5-F655CBB2624F@gmail.com> Message-ID: <4DA437FC.9050800@foobar.org> On 09/04/2011 10:37, Bryan Irvine wrote: > As do some states with automotive registration. It's a quite normal practice. If you're in a monopoly or near-monopoly position, you can get away with screwing over your customer base. If you're in a competitive market, practices like support catch-up fees depend on a company's ability to trade on their customers' ignorance about what products are available in the market. Who knows, it may well work for this quarter or the next - but as a long term business proposition, it's quite corrosive to customer loyalty. Nick From darcy at druid.net Tue Apr 12 06:58:16 2011 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Tue, 12 Apr 2011 07:58:16 -0400 Subject: Top-posting (was: Barracuda Networks is at it again: Any Suggestions as to anAlternative? ) In-Reply-To: References: <20110411181533.46782.qmail@joyce.lan> <9991D851-8B15-4362-9AB1-4FF498347F49@deman.com> <023D7C80-512B-420D-BD9C-12F96E1FF752@deman.com> Message-ID: <20110412075816.4854ff66.darcy@druid.net> On Tue, 12 Apr 2011 12:17:54 +0100 gord wrote: > I wasn't pedantic or impolite enough to suggest that it was off-topic > here (which, technically, it is), simply saying that it was doing my Actually, I don't think it is off-topic. Meta-discussions about the list are considered on-topic for the list. This is a discussion about whether the rules for the list should be changed and so is on-topic. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From gordslater at ieee.org Tue Apr 12 07:45:36 2011 From: gordslater at ieee.org (gord) Date: Tue, 12 Apr 2011 13:45:36 +0100 Subject: Top-posting (was: Barracuda Networks is at it again: Any Suggestions as to anAlternative? ) In-Reply-To: <20110412075816.4854ff66.darcy@druid.net> References: <20110411181533.46782.qmail@joyce.lan> <9991D851-8B15-4362-9AB1-4FF498347F49@deman.com> <023D7C80-512B-420D-BD9C-12F96E1FF752@deman.com> <20110412075816.4854ff66.darcy@druid.net> Message-ID: <1302612336.18782.12.camel@g2> On Tue, 2011-04-12 at 07:58 -0400, D'Arcy J.M. Cain wrote: > On Tue, 12 Apr 2011 12:17:54 +0100 > gord wrote: > > I wasn't pedantic or impolite enough to suggest that it was off-topic > > here (which, technically, it is), simply saying that it was doing my > > Actually, I don't think it is off-topic. Meta-discussions about the > list are considered on-topic for the list. This is a discussion about > whether the rules for the list should be changed and so is on-topic. > I was referring to my initial post/comment that started all of this, _that_ thread was technically off-topic when referring to software methods, though that's largely irrelevant and I personally couldn't give a hoot. http://www.nanog.org/mailinglist/listfaqs/topicfaq.php?qt=offtopic&q=all refers. Now I sound like a bookthumper :) What I was originally saying was "I'm confused - this is a bottom-post list by the list convention, but top-posting is happening to my detriment" Stepping back from it, I think I'll take a break from this for a weeks - contact by phone/irc and noc@ only please. If you don't have the numbers, well, tough. gord -- From rdobbins at arbor.net Tue Apr 12 08:16:10 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 12 Apr 2011 13:16:10 +0000 Subject: Facebook Opens Up Its Hardware Secrets In-Reply-To: References: Message-ID: On Apr 12, 2011, at 7:06 AM, Bruce Williams wrote: > In doing so, the company is breaking a long-established unwritten rule for Web companies: don't share the secrets of your server-stuffed data warehouses (currently the topmost article in the 'electronics' category; article permalink doesn't work) ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From bill at herrin.us Tue Apr 12 08:47:35 2011 From: bill at herrin.us (William Herrin) Date: Tue, 12 Apr 2011 09:47:35 -0400 Subject: Top-posting (was: Barracuda Networks is at it again: Any Suggestions as to anAlternative? ) In-Reply-To: References: <20110411181533.46782.qmail@joyce.lan> <9991D851-8B15-4362-9AB1-4FF498347F49@deman.com> Message-ID: On Tue, Apr 12, 2011 at 2:49 AM, Tim Chown wrote: > Well indeed, top-posting is just so much more efficient given the >volumes of email most of us probably see each day. That's true... if you're adding a trivial thought to an already concise thread. If you're adding complex argument or information, or if the thread has wandered into a wide topic, a top-posted message is often incomprehensible. Without the context provided by posting inline, the reader can't immediately tell what point or points you're responding to. That's why in lists like this one we intermix new thoughts with the information they're responsive to. More, bottom-posting is just a subset of inline posting in which we're only responding to one element. > But I'm afraid times have changed; bottom-posted email is now an annoyance >to most just as a slow-loading web page would be. Then you're doing it wrong. You're supposed to trim the original down to just the context that clarifies your response. That's the other problem with top-posters... nobody trims, so if I want to understand what they're attempting to say I have to scroll down, read all the previous messages and then guess which part they're replying to. Usually the lazy top-poster hasn't said anything worth that much effort. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Tue Apr 12 10:18:30 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 12 Apr 2011 11:18:30 -0400 Subject: Top-posting (was: Barracuda Networks is at it again: Any Suggestions as to anAlternative? ) In-Reply-To: Your message of "Tue, 12 Apr 2011 07:49:17 BST." References: <20110411181533.46782.qmail@joyce.lan> <9991D851-8B15-4362-9AB1-4FF498347F49@deman.com> Message-ID: <58598.1302621510@localhost> On Tue, 12 Apr 2011 07:49:17 BST, Tim Chown said: > Well indeed, top-posting is just so much more efficient given the > volumes of email most of us probably see each day. http://marc.info/?l=linux-kernel&m=129565913825601&w=2 Go read that thread. 115 messages and counting. Read *all* of them. Then think how much longer it would have taken if everybody had top posted. Second note in the thread - new text is: RIP to this guy, won't be missed :) You *really* want to have read the context on that before reading the comment. If top-posted, it leaves you thinking something entirely different ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jcdill.lists at gmail.com Tue Apr 12 10:22:34 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 12 Apr 2011 08:22:34 -0700 Subject: Top-posting (was: Barracuda Networks is at it again: Any Suggestions as to anAlternative? ) In-Reply-To: References: <20110411181533.46782.qmail@joyce.lan> <9991D851-8B15-4362-9AB1-4FF498347F49@deman.com> Message-ID: <4DA46E3A.107@gmail.com> On 12/04/11 6:47 AM, William Herrin wrote: > On Tue, Apr 12, 2011 at 2:49 AM, Tim Chown wrote: >> But I'm afraid times have changed; bottom-posted email is now an annoyance >> to most just as a slow-loading web page would be. > Then you're doing it wrong. You're supposed to trim the original down > to just the context that clarifies your response. That's the other > problem with top-posters... nobody trims, so if I want to understand > what they're attempting to say I have to scroll down, read all the > previous messages and then guess which part they're replying to. > > Usually the lazy top-poster hasn't said anything worth that much effort. An even bigger problem is that the lazy top-poster often misses critical issues that either clarify the post they are replying to (making their reply irrelevant) or forgets to reply to something critical in the quoted text. I run into this often at $dayjob, where I can't ask more than one question in an email because the top-posted reply generally only addresses the first question. The people who top post see this as a feature - they get their reply composed and sent off faster and can then move on to other things. They don't understand why they fail to thrive in their jobs as co-workers start to route discussions around them and then ultimately they are the first to be laid off because they aren't seen as an essential part of the team. jc From ml at kenweb.org Tue Apr 12 19:38:40 2011 From: ml at kenweb.org (ML) Date: Tue, 12 Apr 2011 20:38:40 -0400 Subject: Level 3 Agrees to Purchase Global Crossing In-Reply-To: <4DA30C9D.107@gmail.com> References: <4DA30C9D.107@gmail.com> Message-ID: <4DA4F090.6080900@kenweb.org> On 4/11/2011 10:13 AM, William Allen Simpson wrote: > http://www.bloomberg.com/news/print/2011-04-11/level-3-agrees-to-acquire-global-crossing-in-deal-valued-at-1-9-billion.html > > > The deal will combine two unprofitable companies with total revenue of > $6.26 billion as of last year, and cut annualized capital spending by > about $40 million, according to the statement. It will also help reduce > the pressure on prices, which have declined by as much as 30 percent a > year in the industry, said Donna Jaegers, an analyst at DA Davidson & > Co. > > ?This is what telecom has needed for a long time,? said Denver-based > Jaegers, who recommends buying both stocks. ?You have way too many > players.? > > If L3 merges GBLX in as well as they did Broadwing...the little guy stands to do pretty well. From jra at baylink.com Tue Apr 12 20:22:32 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 12 Apr 2011 21:22:32 -0400 (EDT) Subject: Yahoo! Mail Issue In-Reply-To: <4DA3E32F.6050907@stluke.com.ph> Message-ID: <6206233.2383.1302657752481.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Nathanael C. Cariaga" > Thanks anyway. I just find this issue intriguing since not all Yahoo > mail accounts are affected. In addition, incoming mails from other > domain doesn't seem to be affected. That is why I want to check if it > is a network issue :) It only happens when the sending server is less than 600 miles from you. Cheers, -- jra From eugen at leitl.org Wed Apr 13 08:11:15 2011 From: eugen at leitl.org (Eugen Leitl) Date: Wed, 13 Apr 2011 15:11:15 +0200 Subject: Syngenta space Message-ID: <20110413131115.GG23560@leitl.org> Hi, sorry for the noise, but my contact at Syngenta says they have 147.0.0.0/8 168.0.0.0/8 and 172.0.0.0/8, which is obviously bogus. They do have a 168.246.0.0/16 however. Any tool to look the other two up quickly, without having to iterate through the entire second octet? Thanks! -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From nanog at armoredpackets.com Wed Apr 13 09:22:47 2011 From: nanog at armoredpackets.com (AP NANOG) Date: Wed, 13 Apr 2011 10:22:47 -0400 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: <4DA5B1B7.7050608@armoredpackets.com> I would look into Asatro, they have a solid product and good support. If you want a contact person let me know and I will email you directly. On 4/9/11 11:55 AM, proth at cnsny.net wrote: > Andrew, > We use and offer Postini - a front end service. Postini is a anti virus and spam filter, and can spool mail if your circuits are down. Postini is a Google company and works like a charm. If you need more information please contact me offline proth at cnsny.net > > Paul > > Sent from my Verizon Wireless Phone > > ----- Reply message ----- > From: "Andrew Kirch" > Date: Sat, Apr 9, 2011 10:39 am > Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? > To: "John Palmer (NANOG Acct)", > > John, > > My suggestion isn't _QUITE_ an appliance, but it works very well and > I've been exceptionally happy with it. It's a distribution of linux > controlled via a web interface that does far more than just mail > filtering (at which it is both flexible and adept). Take a look at > http://www.clearfoundation.com/Software/overview.html. The hardware > requirements shouldn't be too insane, and the rules > updates/subscriptions for the various services are all month to month, > and not a bucket of insane. > > Andrew > > > On 4/8/2011 11:51 PM, John Palmer (NANOG Acct) wrote: >> OK, its been a year since my Barracuda subscription expired. The unit >> still stops some spam. I figured that I would go and see what they >> would do if I tried to renew my subscription EXACTLY one year after it >> expired. Would their renewal website say "Oh, you are at your >> anniversary date", and renew me for a year? >> >> No such luck: They want me to PAY FOR AN ENTIRE YEAR for which I did >> NOT receive service and then for the current (upcoming year). Sorry - >> I don't allow myself to be ripped off like that. Sorry Barracuda - you >> get no money from me and I'll tell everyone I know about this policy >> of yours. >> >> I posted an article about this unscrupulous practice on my blog last >> year at http://www.john-palmer.net/wordpress/?p=46 >> >> My question is - does anyone have any suggestions for another e-mail >> appliance like the Barracuda Spam Firewall that doesn't try to charge >> their customers for time not used. I should be able to shut off the >> unit for a year or whatever and simply renew from the point that I >> re-activate the unit instead of having to pay for back-years that I >> didn't use. >> >> Thanks >> >> >> >> >> > From mksmith at adhost.com Wed Apr 13 09:27:27 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 13 Apr 2011 14:27:27 +0000 Subject: Syngenta space In-Reply-To: <20110413131115.GG23560@leitl.org> References: <20110413131115.GG23560@leitl.org> Message-ID: > -----Original Message----- > From: Eugen Leitl [mailto:eugen at leitl.org] > Sent: Wednesday, April 13, 2011 6:11 AM > To: NANOG list > Subject: Syngenta space > > Hi, > > sorry for the noise, but my contact at Syngenta says > they have 147.0.0.0/8 168.0.0.0/8 and 172.0.0.0/8, > which is obviously bogus. They do have a 168.246.0.0/16 > however. > > Any tool to look the other two up quickly, without having to > iterate through the entire second octet? Thanks! > I just scraped the BGP output from one of my border routers and came up with discrete more specific routes and AS's in all three blocks. Given that Sygenta doesn't appear to have an AS, we can assume they are not amongst them. Regards, Mike From lorenzo.rossi at iit.cnr.it Wed Apr 13 10:36:45 2011 From: lorenzo.rossi at iit.cnr.it (Lorenzo Rossi) Date: Wed, 13 Apr 2011 17:36:45 +0200 Subject: SDH 1+1 protected circuit and OSPF minimal setup on a single Juniper platform. Message-ID: <4DA5C30D.9070204@iit.cnr.it> Hi, I have some doubts about the minimal configuration to handle an SDH 1+1 protected circuit with OSPF on a single Juniper router platform (one interface as the Working Circuit and another interface as the Protect Circuit). Reading the JunOS documentation, for instance the 9.4 JunOS version: http://www.juniper.net/techpubs/software/junos/junos94/swconfig-network-interfaces/interfaces-configuring-sonet-sdh-physical-interface-properties.html#id-12712165 and using the various configuration snippet I tried to link together various pieces of configuration and the result is below: so-0/2/0 { framing { sdh; } sonet-options { aps { working-circuit bayward; authentication-key blarney; } } unit 0 { family inet { address 10.100.100.1/24; } } } so-1/3/0 { framing { sdh; } sonet-options { aps { protect-circuit bayward; authentication-key blarney; } } unit 0 { family inet { address 10.100.200.1/24; } } } lab at r1# show protocols ospf area 0.0.0.0 { interface so-0/2/0.0; interface so-1/3/0.0; } } If I'm not wrong the APS/MSP signaling protocol router implementation should set one of the two sonet interfaces as Up and the other as Down, so the OSPF should install in routing table only the IP network related to the Up interface. Am I wrong? Do you think I forgot some configuration pieces? Thanks and regards, Lorenzo From copraphage at gmail.com Wed Apr 13 10:56:14 2011 From: copraphage at gmail.com (Chris McDonald) Date: Wed, 13 Apr 2011 11:56:14 -0400 Subject: historical pricing data Message-ID: This may be the wrong place to ask but maybe one of you could point me in a direction. I'm looking for [ideally] historical market pricing for mpls/ipl between as many as possible city pairs [with a focus toward Asia] as well as ip maybe 5 year back. Thanks, Chris From jsw at inconcepts.biz Wed Apr 13 14:13:46 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 13 Apr 2011 15:13:46 -0400 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <768DDE65-C091-4A48-97E4-92F3E51D6042@net.t-labs.tu-berlin.de> References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> <768DDE65-C091-4A48-97E4-92F3E51D6042@net.t-labs.tu-berlin.de> Message-ID: On Tue, Apr 12, 2011 at 4:59 AM, Luigi Iannone wrote: > This is not true. There are several works out there showing that the FIB will not grow as you are saying. Having taken some time to discuss this off-list with Luigi. I'd already read the paper he had in mind, which does not address DoS or prefix growth as the number of multi-homed sites, or single-homed sites with "PI blocks," increases. In effect, that paper and other works on this subject fail to consider what happens when one of LISP's goals actually becomes true: more wide-spread adoption of its technology to enable branch offices and other end-users to become multi-homed, or avoid renumbering. Plain and simple, it does not scale up any better than injecting more routes into the DFZ, unless you 1) accept macro-flow-based routing; or 2) scale up the size of your FIB along with the much larger number of prefixes which would be introduced by lowering the barrier-to-entry for multi-homing and provider-independent addressing. However, LISP does have non-Internet applications which are interesting. You can potentially have multi-homed connectivity between your own branch offices, using one or more public Internet connections at each branch, and your own private mapping servers which know the state of reachability from one branch to the others. In effect, it can become "poor man's L3VPN." Beyond non-Internet applications such as this, I think LISP is useful largely as a case study for what happens when a bunch of engineers get together and "solve" some problems they do not understand -- DFZ size/growth being chief among them. Like others, I still leave room for the possibility that I am wrong about this. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From randy at psg.com Wed Apr 13 14:44:19 2011 From: randy at psg.com (Randy Bush) Date: Thu, 14 Apr 2011 04:44:19 +0900 Subject: Syngenta space In-Reply-To: <20110413131115.GG23560@leitl.org> References: <20110413131115.GG23560@leitl.org> Message-ID: > sorry for the noise, but my contact at Syngenta says > they have 147.0.0.0/8 168.0.0.0/8 and 172.0.0.0/8, and pigs fly From morrowc.lists at gmail.com Wed Apr 13 14:48:36 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 13 Apr 2011 21:48:36 +0200 Subject: Syngenta space In-Reply-To: References: <20110413131115.GG23560@leitl.org> Message-ID: On Wed, Apr 13, 2011 at 9:44 PM, Randy Bush wrote: >> sorry for the noise, but my contact at Syngenta says >> they have 147.0.0.0/8 168.0.0.0/8 and 172.0.0.0/8, > > and pigs fly indeed, an impressive claim, how much for it all? From randy at psg.com Wed Apr 13 14:51:44 2011 From: randy at psg.com (Randy Bush) Date: Thu, 14 Apr 2011 04:51:44 +0900 Subject: Syngenta space In-Reply-To: References: <20110413131115.GG23560@leitl.org> Message-ID: >>> sorry for the noise, but my contact at Syngenta says >>> they have 147.0.0.0/8 168.0.0.0/8 and 172.0.0.0/8, >> and pigs fly > indeed, an impressive claim, how much for it all? i am particularly impressed by the annexation of some of the rfc1918 space. randy From paul at paulgraydon.co.uk Wed Apr 13 14:53:02 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Wed, 13 Apr 2011 09:53:02 -1000 Subject: Syngenta space In-Reply-To: References: <20110413131115.GG23560@leitl.org> Message-ID: <4DA5FF1E.9060403@paulgraydon.co.uk> On 04/13/2011 09:48 AM, Christopher Morrow wrote: > On Wed, Apr 13, 2011 at 9:44 PM, Randy Bush wrote: >>> sorry for the noise, but my contact at Syngenta says >>> they have 147.0.0.0/8 168.0.0.0/8 and 172.0.0.0/8, >> and pigs fly > indeed, an impressive claim, how much for it all? > *checks pockets* $5 and some lint? From Don.DuQuette at fngp.com Wed Apr 13 14:58:14 2011 From: Don.DuQuette at fngp.com (Don.DuQuette at fngp.com) Date: Wed, 13 Apr 2011 15:58:14 -0400 Subject: Syngenta space In-Reply-To: <4DA5FF1E.9060403@paulgraydon.co.uk> References: <20110413131115.GG23560@leitl.org> <4DA5FF1E.9060403@paulgraydon.co.uk> Message-ID: Ill throw in 10.0.0.0 /8 for just the lint, but it better be really good lint From: Paul Graydon To: nanog at nanog.org Date: 04/13/2011 03:54 PM Subject: Re: Syngenta space On 04/13/2011 09:48 AM, Christopher Morrow wrote: > On Wed, Apr 13, 2011 at 9:44 PM, Randy Bush wrote: >>> sorry for the noise, but my contact at Syngenta says >>> they have 147.0.0.0/8 168.0.0.0/8 and 172.0.0.0/8, >> and pigs fly > indeed, an impressive claim, how much for it all? > *checks pockets* $5 and some lint? From leigh.porter at ukbroadband.com Wed Apr 13 15:00:12 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 13 Apr 2011 21:00:12 +0100 Subject: Syngenta space In-Reply-To: References: <20110413131115.GG23560@leitl.org> Message-ID: <4E462909-5458-43EB-A168-7DF1B5DB0AB5@ukbroadband.com> On 13 Apr 2011, at 20:44, Randy Bush wrote: >> sorry for the noise, but my contact at Syngenta says >> they have 147.0.0.0/8 168.0.0.0/8 and 172.0.0.0/8, > > and pigs fly > You can make almost anything fly if you put enough oomph behind it.. -- Leigh ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From dougb at dougbarton.us Wed Apr 13 15:01:35 2011 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 13 Apr 2011 13:01:35 -0700 Subject: Syngenta space In-Reply-To: References: <20110413131115.GG23560@leitl.org> Message-ID: <4DA6011F.5050003@dougbarton.us> On 04/13/2011 12:44, Randy Bush wrote: >> sorry for the noise, but my contact at Syngenta says >> they have 147.0.0.0/8 168.0.0.0/8 and 172.0.0.0/8, > > and pigs fly /me pops open the kevlar umbrella (thanks for the warning!) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From Valdis.Kletnieks at vt.edu Wed Apr 13 15:02:28 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 13 Apr 2011 16:02:28 -0400 Subject: Syngenta space In-Reply-To: Your message of "Thu, 14 Apr 2011 04:44:19 +0900." References: <20110413131115.GG23560@leitl.org> Message-ID: <20239.1302724948@localhost> On Thu, 14 Apr 2011 04:44:19 +0900, Randy Bush said: > > sorry for the noise, but my contact at Syngenta says > > they have 147.0.0.0/8 168.0.0.0/8 and 172.0.0.0/8, > > and pigs fly Only if they're RFC1925 compliant. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From lyndon at orthanc.ca Wed Apr 13 15:04:13 2011 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Wed, 13 Apr 2011 13:04:13 -0700 (PDT) Subject: Syngenta space In-Reply-To: References: <20110413131115.GG23560@leitl.org> Message-ID: >>> sorry for the noise, but my contact at Syngenta says >>> they have 147.0.0.0/8 168.0.0.0/8 and 172.0.0.0/8, Bugger. Now I have to renumber out of my 172.16/12 subnets :-( From joelja at bogus.com Wed Apr 13 15:22:34 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 13 Apr 2011 13:22:34 -0700 Subject: Syngenta space In-Reply-To: <20110413131115.GG23560@leitl.org> References: <20110413131115.GG23560@leitl.org> Message-ID: <4DA6060A.2070700@bogus.com> On 4/13/11 6:11 AM, Eugen Leitl wrote: > Hi, > > sorry for the noise, but my contact at Syngenta says > they have 147.0.0.0/8 168.0.0.0/8 and 172.0.0.0/8, > which is obviously bogus. They do have a 168.246.0.0/16 > however. > > Any tool to look the other two up quickly, without having to > iterate through the entire second octet? Thanks! > 23173jjaeggli:~ jjaeggli$ ssh rviews at route-views.routeviews.org route-views> show bgp ipv4 unicast 147.0.0.0/8 longer-prefixes ... route-views>show bgp ipv4 unicast 168.246.0.0/16 longer-prefixes route-views> From shrdlu at deaddrop.org Wed Apr 13 15:29:16 2011 From: shrdlu at deaddrop.org (Lynda) Date: Wed, 13 Apr 2011 13:29:16 -0700 Subject: Syngenta space In-Reply-To: References: <20110413131115.GG23560@leitl.org> Message-ID: <4DA6079C.2080103@deaddrop.org> On 4/13/2011 12:44 PM, Randy Bush wrote: >> sorry for the noise, but my contact at Syngenta says >> they have 147.0.0.0/8 168.0.0.0/8 and 172.0.0.0/8, > > and pigs fly Well, sometimes they do. http://wardsci.com/product.asp_Q_pn_E_IG0035229 [Flying Pig: Unforgettable Fun with Physics] -- "The person becomes vulnerable to all manner of fads, such as astrology, superstitions, economics, and tarot-card reading." The Black Swan, by Nassim Nicholas Taleb From malayter at gmail.com Wed Apr 13 15:41:38 2011 From: malayter at gmail.com (Ryan Malayter) Date: Wed, 13 Apr 2011 13:41:38 -0700 (PDT) Subject: Syngenta space In-Reply-To: References: <20110413131115.GG23560@leitl.org> Message-ID: On Apr 13, 2:44?pm, Randy Bush wrote: > > sorry for the noise, but my contact at Syngenta says > > they have 147.0.0.0/8 168.0.0.0/8 and 172.0.0.0/8, > > and pigs fly And to think, Google manages to get by with the equivalents of a few / 16 or smaller. From lyndon at orthanc.ca Wed Apr 13 15:45:10 2011 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Wed, 13 Apr 2011 13:45:10 -0700 (PDT) Subject: Syngenta space In-Reply-To: <4DA6079C.2080103@deaddrop.org> References: <20110413131115.GG23560@leitl.org> <4DA6079C.2080103@deaddrop.org> Message-ID: >> and pigs fly > Well, sometimes they do. There underlying problem here is flying sheep: http://www.youtube.com/watch?v=Vkw2DdoskPY Note the accurate summarization of the entire issue. From leigh.porter at ukbroadband.com Wed Apr 13 15:50:53 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 13 Apr 2011 21:50:53 +0100 Subject: Syngenta space In-Reply-To: References: <20110413131115.GG23560@leitl.org> <4DA6079C.2080103@deaddrop.org> Message-ID: <1906E918-9499-4B63-BA12-C23C49213EAD@ukbroadband.com> On 13 Apr 2011, at 21:45, Lyndon Nerenberg wrote: >>> and pigs fly >> Well, sometimes they do. > > There underlying problem here is flying sheep: > > http://www.youtube.com/watch?v=Vkw2DdoskPY > > Note the accurate summarization of the entire issue. > Yes that's it. 172/8 is nesting. Perhaps if 172/8 and 168/8 get together and mate they will produce lots of little /16s and .... -- Leigh ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From trelane at trelane.net Wed Apr 13 15:56:53 2011 From: trelane at trelane.net (Andrew D Kirch) Date: Wed, 13 Apr 2011 16:56:53 -0400 Subject: Syngenta space In-Reply-To: <1906E918-9499-4B63-BA12-C23C49213EAD@ukbroadband.com> References: <20110413131115.GG23560@leitl.org> <4DA6079C.2080103@deaddrop.org> <1906E918-9499-4B63-BA12-C23C49213EAD@ukbroadband.com> Message-ID: <4DA60E15.6050201@trelane.net> On 4/13/11 4:50 PM, Leigh Porter wrote: > On 13 Apr 2011, at 21:45, Lyndon Nerenberg wrote: > >>>> and pigs fly >>> Well, sometimes they do. >> There underlying problem here is flying sheep: >> >> http://www.youtube.com/watch?v=Vkw2DdoskPY >> >> Note the accurate summarization of the entire issue. >> > Yes that's it. 172/8 is nesting. Perhaps if 172/8 and 168/8 get together and mate they will produce lots of little /16s and .... > We won't have to implement IPv6 What a MASSIVE time savings. VACATION HERE I COME! From nanog at thedaileyplanet.com Wed Apr 13 16:08:29 2011 From: nanog at thedaileyplanet.com (Chad Dailey) Date: Wed, 13 Apr 2011 16:08:29 -0500 Subject: Syngenta space In-Reply-To: <4DA6079C.2080103@deaddrop.org> References: <20110413131115.GG23560@leitl.org> <4DA6079C.2080103@deaddrop.org> Message-ID: Sometimes with alternate propulsion: http://img24.imagevenue.com/img.php?loc=loc188&image=ab44c_incroyable.jpg On Wed, Apr 13, 2011 at 3:29 PM, Lynda wrote: > On 4/13/2011 12:44 PM, Randy Bush wrote: > >> sorry for the noise, but my contact at Syngenta says >>> they have 147.0.0.0/8 168.0.0.0/8 and 172.0.0.0/8, >>> >> >> and pigs fly >> > > Well, sometimes they do. > > http://wardsci.com/product.asp_Q_pn_E_IG0035229 > > [Flying Pig: Unforgettable Fun with Physics] > > -- > "The person becomes vulnerable to all manner of fads, such as > astrology, superstitions, economics, and tarot-card reading." > > The Black Swan, by Nassim Nicholas Taleb > > From mark at viviotech.net Wed Apr 13 19:24:58 2011 From: mark at viviotech.net (Mark Keymer) Date: Wed, 13 Apr 2011 17:24:58 -0700 Subject: Looking for Postmaster contact for js.pentagon.mil Message-ID: <4DA63EDA.1070100@viviotech.net> We have a client that we resent moved to some new address space (We have had the the space for a couple of years now) However it looks like the mail server for js.pentagon.mil are droping all packet to them. :( If anyone had some leads on a way to contact them. Please contact me off-list. We did try the number in the whois for the IP. The phone rang and rang. :( Thank you all. Sincerely, Mark Keymer From graham at apolix.co.za Thu Apr 14 01:19:54 2011 From: graham at apolix.co.za (Graham Beneke) Date: Thu, 14 Apr 2011 08:19:54 +0200 Subject: How is IPv6 deployment going in the APNIC region? Message-ID: <4DA6920A.1060803@apolix.co.za> Only 0.3 of a /8 left[1] before the rationing policy kicks in. I hope everyone is ready :-) [1] http://www.apnic.net/community/ipv4-exhaustion/graphical-information -- Graham Beneke From tore.anderson at redpill-linpro.com Thu Apr 14 01:33:34 2011 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 14 Apr 2011 08:33:34 +0200 Subject: How is IPv6 deployment going in the APNIC region? In-Reply-To: <4DA6920A.1060803@apolix.co.za> References: <4DA6920A.1060803@apolix.co.za> Message-ID: <4DA6953E.6010109@redpill-linpro.com> * Graham Beneke > Only 0.3 of a /8 left[1] before the rationing policy kicks in. Hi, Actually, they're already empty. Chinanet Fujian Province Network allocated 498432 addresses today, spread out over 1102(!) individual prefixes in the range /21-/24. Unless any resources has been returned to the free pool today, there's nothing left in the APNIC pool outside of the 103/8 block, which is the one set aside for the final /8 policy. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From iljitsch at muada.com Thu Apr 14 06:02:39 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 14 Apr 2011 13:02:39 +0200 Subject: How is IPv6 deployment going in the APNIC region? In-Reply-To: <4DA6953E.6010109@redpill-linpro.com> References: <4DA6920A.1060803@apolix.co.za> <4DA6953E.6010109@redpill-linpro.com> Message-ID: <84200D01-23CF-4BD4-AD32-B2DE4F39948A@muada.com> On 14 apr 2011, at 8:33, Tore Anderson wrote: > Actually, they're already empty. Chinanet Fujian Province Network > allocated 498432 addresses today, spread out over 1102(!) individual > prefixes in the range /21-/24. Where do you see this? On ftp.apnic.net I see delegated-apnic-20110414 which only contains info upto the 13th and has a timestamp of Apr 13 15:15. Based on that file, APNIC still has 17.57 million regular + 2.27 M legacy = 19.84 M total address space, so another 0.5 M wouldn't deplete what's left. I also don't get what they did two days ago: inetnum: 39.192.0.0 - 39.255.255.255 netname: Debogon-prefix descr: APNIC Debogon Project This is address space that's now marked as delegated and removed from the pile of unused address space for no obvious reason. From rfg at tristatelogic.com Thu Apr 14 06:22:06 2011 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 14 Apr 2011 04:22:06 -0700 Subject: New hijacks, and lots of them Message-ID: <5824.1302780126@tristatelogic.com> One particular large and well-distributed snowshoe spamming operation became the subject of my special scrutiny recently. After seeing all of the the various apparently hijacked IP blocks that this particular snowshoe spamming operation seemed to be relying upon for much of its IP space, it seemed like the right thing to do for me to report on the whole mess here. To begin with here are a couple of files which show the full extent of this particular rather vast snowshoe operation (including both hijacked and non-hijacked parts). By my count we are talking in excess of 6,300 separate second-level gTLD domain names. http://www.47-usc-230c2.org/20110414-snowshoe-1.txt http://www.47-usc-230c2.org/20110414-snowshoe-2.txt Dredging into this operation more deeply led me to the following con- clusions... Based upon information and belief, the following number resources have been hijacked, i.e. they either are now, or were in the recent past being used without proper authorization by a party or parties to whom these resources were not assigned by any RiR. (Unless otherwise specified below, these are all ARIN-assigned number resources.) AS8143 (1) AS29987 (2) AS11756 (3) (4) AS47024 (5) AS27906 (6)(7) 198.23.32.0/20 - NET-198-23-32-0-1 (8) 198.57.64.0/20 - NET-198-57-64-0-1 (9) 199.88.32.0/20 - NET-199-88-32-0-1 (10) 199.192.16.0/20 - NET-199-192-16-0-1 (11) 199.196.192.0/19 - NET-199-196-192-0-1 (12) 200.107.216.0/21 - GT-AGSA1-LACNIC (13) 204.147.240.0/20 - NET-204-147-240-0-1 (14) 207.22.224.0/19 - (NET-207-22-192-0-1) (15) (16) Notes ----- (1) Probable fradulent falsification of JD47-ORG-ARIN - 2010-11-22 (2) Probable fradulent falsification of AS29987 & IPADM448-ARIN - 2010-11-04 (3) Probable fradulent falsification of AS11756 - 2011-03-15 (4) Probable fradulent falsification of JR1271-ARIN - 2010-07-08 (5) ARIN unable to validate contact NOC3622-ARIN since 2010-06-19 (6) LACNIC assigned AS (7) Contact record ERJ3 modified - 2011-04-06 (falsified?) (8) Probable fradulent falsification of NET-199-88-32-0-1 & SH174-ARIN - 2010-11-03 (9) ARIN unable to valiadate contact GW449-ARIN since 2010-07-18 (10) ARIN unable to valiadate contact DM126-ARIN since 2010-07-16 (11) ARIN unable to valiadate contact RP56-ARIN since 2010-07-22 (12) ARIN unable to valiadate contact FB43-ARIN since 2010-07-17 (13) LACNIC assigned IPv4 block (14) ARIN unable to valiadate contact LT127-ORG-ARIN since 2010-07-20 (15) Only the 207.22.224.0/19 portion of 207.22.192.0/18 is being routed (16) ARIN unable to valiadate contact MH521-ARIN since 2010-07-12 Discussion ---------- The entire scope of this particular spamming operation spans both the aforementioned (hijacked) IP ranges and also a number of IP ranges that are clearly NOT hijacked. I have attempted to list below all ranges that either are now in use by this operation, or that have been in use by this operation, in the relatively recent past. The various IP blocks listed below are connected, in one way or another, to several entities that have been caught doing IP block hijacking in the past, in particular: *) Joytel Wireless of Florida... which apparently has some significant connection to an entity called "GoRack", also of South Florida, and *) Xeex aka AS27524 aka Nishant Ramachandran, and *) last but by no means least, Media Breakaway, LLC aka JKS Media, LLC, aka Dynamic Dolphin (ICANN Accredited Registrar) aka "OptInRealBig" aka the notorious Scott Richter. (Essentially all of the domains of this operation are, apparently, registered anonymously with Dynamic Dophin, and as noted below, A portion of them are also being routed by JKS Media, and a subset of those are either hosted in and/or are getting DNS service from IP blocks registered to Media Breakaway.) As you will see below, a few of the ranges that I have identified as having been hijacked were already/previously blacklisted by Spamhaus some months ago. Also, in at least one case, Spamhaus records indicate that they too believe that the block in question was indeed hijacked. (It is always nice to have a second, confirming opinion.) I could speculate on the identity of the person or company which might most accurately be said to be "behind" all this, but I actually do not feel the need to do so in this instance. The data speaks for itself, and I do believe that any diligent researcher who really wants to dredge into it all will likely reach what I consider to be the proper conclusion(s). =========================================================================== All IP ranges containing assets of this specific snowshoe operation: -------------------------------------------------------------------- 8.24.248.0/21 - via AS19844 (gorack.net) 66.115.166.0/24 - NET-66-115-166-0-1 - via AS22384 (nationalnet.com) 66.115.167.0/24 - NET-66-115-167-0-1 - via AS22384 (nationalnet.com) 66.115.168.0/24 - NET-66-115-168-0-1 - via AS22384 (nationalnet.com) 66.115.172.0/24 - NET-66-115-172-0-1 - via AS22384 (nationalnet.com) 66.232.42.0/23 - via AS21510 (tristarcorp.net) 66.232.44.0/24 - via AS21510 (tristarcorp.net) 66.232.46.0/23 - via AS21510 (tristarcorp.net) 66.232.48.0/23 - via AS21510 (tristarcorp.net) 67.55.111.0/24 - "Masterly International S.A."[1] - via AS27257 (webair.com) 67.220.69.0/24 - via AS17048 (awknet.com) 69.6.29.0/24 - NET-69-6-29-0-1 - Media Breakaway - via AS32311 (jksmedia.net) 69.6.31.0/24 - NET-69-6-31-0-1 RRM LLC - via AS32311 (jksmedia.net) 69.6.36.0/24 - NET-69-6-36-0-1 - Media Breakaway - via AS32311 (jksmedia.net) 69.6.42.0/24 - via AS32311 (jksmedia.net) 69.6.43.0/24 - via AS32311 (jksmedia.net) 69.6.49.0/24 - NET-69-6-49-0-1 - Media Breakaway - via AS32311 (jksmedia.net) 69.6.56.0/24 - via AS32311 (jksmedia.net) 69.42.77.64/28 - "Masterly International S.A."[1] - via AS27257 (webair.com) 74.202.216.0/21 - Joytel Wireless - via AS4323 (twtelecom.net) 91.90.192.0/19 - via AS41331 (moda-ua.net/Ukraine) 93.171.64.0/21 - via AS27257 (webair.com) 173.239.8.0/24 - "Masterly International S.A."[1] - via AS27257 (webair.com) 173.239.9.0/24 - "Masterly International S.A."[1] - via AS27257 (webair.com) 198.23.32.0/20 - NET-198-23-32-0-1 - Was Hijacked - via AS11756 [5] (BitStorm) http://www.spamhaus.org/sbl/sbl.lasso?query=SBL101186 05-Jan-2011 22:17 GMT | SR22 198.57.64.0/20 - NET-198-57-64-0-1 - Was Hijacked (AS?) http://www.spamhaus.org/sbl/sbl.lasso?query=SBL101250 07-Jan-2011 21:28 GMT | SR03 199.88.32.0/20 - NET-199-88-32-0-1 - Hijacked - via AS29987 [3] 199.192.16.0/20 - NET-199-192-16-0-1 - Was hijacked (AS?) http://www.spamhaus.org/sbl/sbl.lasso?query=SBL101188 05-Jan-2011 22:08 GMT | SR22 199.196.192.0/19 - NET-199-196-192-0-1 - Hijacked - via AS8143 [2] 200.107.216.0/21 - GT-AGSA1-LACNIC - Hijacked - via AS27906 [7] 204.147.240.0/20 - NET-204-147-240-0-1 - Hijacked - via AS47024 [6] 206.246.104.0/22 - via AS11194 (nni.com) 207.22.224.0/19 - (NET-207-22-192-0-1) Hijacked - via AS8143 [2] [4] 207.178.179.0/24 - NET-207-178-179-0-1 - Prime Directive - via AS5033 207.178.191.0/24 - NET-207-178-191-0-1 - Prime Directive - via AS5033 207.178.192.0/24 - NET-207-178-192-0-1 - Prime Directive - via AS5033 207.199.128.0/18 - via AS11194 (nni.com) 207.231.96.0/21 - NET-207-231-96-0-1 - via AS11194 (nni.com) 209.141.0.0/20 - NET-209-141-0-0-1 - via AS12124 (thorn.net) 209.147.86.0/23 - via AS11194 (nni.com) 209.147.88.0/21 - via AS11194 (nni.com) 209.200.23.128/28 - "Masterly International S.A."[1] - via AS27257 (webair.com) Notes: ====== [1] "Masterly International S.A." -- Identified as snowshoer 2005-06-01 by rfg [2] AS8143 hijacked; JD47-ORG-ARIN revised 2010-11-22 4publicom.com - newly registered 2010-11-22 AS8143 is connected to the net only via AS19844 (gorack.com) [3] AS29987 hijacked; IPADM448-ARIN revised 2010-11-04; braziliancomputing.com - newly registered 2010-10-07 AS29987 is connected to the net only via AS3257 (tiscali.net) [4] Not currently inhabited [5] AS11756 hijacked; JR1271-ARIN revised 2010-07-08 jandamy.com - newly registered 2010-11-03 Company declared dead as of 09/22/2000: http://www.sunbiz.org/scripts/cordet.exe?action=DETFIL&inq_doc_number=P96000102349&inq_came_from=NAMFWD&cor_web_names_seq_number=0000&names_name_ind=N&names_cor_number=&names_name_seq=&names_name_ind=&names_comp_name=BITSTORM&names_filing_type= AS11756 currently has -zero- peers (according to www.robtex.com) [6] AS47024 hijacked; NOC3622-ARIN - ARIN unable to validate since 2010-06-19 No company web site; 909-941-8100 - reassigned; 909-743-6182 - disconnected; intiumservices.com newly (re-)registered - 2010-11-04 AS47024 currenly connected only via AS3257 (tiscali.net) [7] AS27906 currently only routed via AS27524 (Xeex) according to robtex.com =========================================================================== As you can see, there is a large volume of material here, and a large amount of research went into it all. I have tried diligently to ensure the complete accuracy of all of the above information, however it is certainly possible that I may have made a mistake or two, here or there, or that circumstances and facts may have changed since I first began compiling this information two days ago. Certainly, no one should rely in any way upon the above information in the absence of your own independent due diligence. I hereby disavow any and all responsibility for any errors or omissions. The above information may only be used at the reader's own risk. This information is being published in accordance with 47 USC 230(c)(2)(B), to enable or make available to information content providers or others the technical means to restrict access to material described in 47 USC 230(c)(1). Via con dios, rfg P.S. ARIN's attempts, during July of last year, to validate various con- tacts that were the responsible parties for various IP allocations was a good and noble effort on ARIN's part. In the present context however it does seem a pity that more was not done with the various negative results from that valiant effort. From tore.anderson at redpill-linpro.com Thu Apr 14 06:50:20 2011 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 14 Apr 2011 13:50:20 +0200 Subject: How is IPv6 deployment going in the APNIC region? In-Reply-To: <84200D01-23CF-4BD4-AD32-B2DE4F39948A@muada.com> References: <4DA6920A.1060803@apolix.co.za> <4DA6953E.6010109@redpill-linpro.com> <84200D01-23CF-4BD4-AD32-B2DE4F39948A@muada.com> Message-ID: <4DA6DF7C.7040704@redpill-linpro.com> * Iljitsch van Beijnum > On 14 apr 2011, at 8:33, Tore Anderson wrote: > >> Actually, they're already empty. Chinanet Fujian Province Network >> allocated 498432 addresses today, spread out over 1102(!) >> individual prefixes in the range /21-/24. > > Where do you see this? On ftp.apnic.net I see > delegated-apnic-20110414 which only contains info upto the 13th and > has a timestamp of Apr 13 15:15. > > Based on that file, APNIC still has 17.57 million regular + 2.27 M > legacy = 19.84 M total address space, so another 0.5 M wouldn't > deplete what's left. Hi, APNIC has for some time now made available an extended version of the delegated file that explicitly says which blocks are available: ftp://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-extended-latest Disregarding 103/8, there were 1104 remaining available prefixes before APNIC's offices opened today. Now they're closed, and by looking in whois.apnic.net I can tell that every single one of the prefixes that were marked in the delegated-extended file as available is now allocated - 1102 of them to Chinanet Fujian Province Network, and two (106.0.32.0/19 and 116.90.0.0/18) to the APNIC Debogon Project. So unless some new blocks (for example returned space) has made it into the free pool today, they are down to their last /8. Actually, they're a bit under one /8, as there's been some assignments made to the Debogon Project in 103/8 already. > I also don't get what they did two days ago: > > inetnum: 39.192.0.0 - 39.255.255.255 > netname: Debogon-prefix > descr: APNIC Debogon Project > > This is address space that's now marked as delegated and removed from > the pile of unused address space for no obvious reason. I believe they are using those prefixes for research. According to the APNIC whois database, 53 individual assignments have been made to the Debogon Project (including the three we've mentioned). In any case, when looking at the graph at http://www.apnic.net/community/ipv4-exhaustion/graphical-information and the delegated-extended file, it appears that these prefixes do count as assigned space like any other assignment. I would assume that when the research project is over, they will be returned to the free pool and assigned under the last /8 policy just like any other space that enters the pool after the last /8 policy has been implemented. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From iljitsch at muada.com Thu Apr 14 07:47:22 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 14 Apr 2011 14:47:22 +0200 Subject: How is IPv6 deployment going in the APNIC region? In-Reply-To: <4DA6DF7C.7040704@redpill-linpro.com> References: <4DA6920A.1060803@apolix.co.za> <4DA6953E.6010109@redpill-linpro.com> <84200D01-23CF-4BD4-AD32-B2DE4F39948A@muada.com> <4DA6DF7C.7040704@redpill-linpro.com> Message-ID: <6198BBAE-7A30-4311-A2F1-6E8ED991FEF7@muada.com> On 14 apr 2011, at 13:50, Tore Anderson wrote: >> This is address space that's now marked as delegated and removed from >> the pile of unused address space for no obvious reason. > I believe they are using those prefixes for research. > and the delegated-extended file, it appears that these prefixes do count > as assigned space like any other assignment. I would assume that when > the research project is over, they will be returned to the free pool and > assigned under the last /8 policy That is extremely curious. How can they justify taking 4 million addresses for research two days before running out of regularly allocatable address space? They could have taken that /10 out of the final /8 rather than taking it from the last scraps of regular space if they really need a /10 for research, which is already dubious in and of itself. Of course they didn't bother to respond to my request for information about all of this. From rubensk at gmail.com Thu Apr 14 07:56:13 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Thu, 14 Apr 2011 09:56:13 -0300 Subject: How is IPv6 deployment going in the APNIC region? In-Reply-To: <6198BBAE-7A30-4311-A2F1-6E8ED991FEF7@muada.com> References: <4DA6920A.1060803@apolix.co.za> <4DA6953E.6010109@redpill-linpro.com> <84200D01-23CF-4BD4-AD32-B2DE4F39948A@muada.com> <4DA6DF7C.7040704@redpill-linpro.com> <6198BBAE-7A30-4311-A2F1-6E8ED991FEF7@muada.com> Message-ID: > That is extremely curious. How can they justify taking 4 million addresses for research two days before running out of regularly allocatable address space? They could have taken that /10 out of the final /8 rather than taking it from the last scraps of regular space if they really need a /10 for research, which is already dubious in and of itself. Debogon usually means they will establish beacons to detect networks that will incorrectly filter that block, and is an indication that such block will soon start being distributed to LIRs. Rubens From owen at delong.com Thu Apr 14 07:59:57 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Apr 2011 05:59:57 -0700 Subject: How is IPv6 deployment going in the APNIC region? In-Reply-To: <6198BBAE-7A30-4311-A2F1-6E8ED991FEF7@muada.com> References: <4DA6920A.1060803@apolix.co.za> <4DA6953E.6010109@redpill-linpro.com> <84200D01-23CF-4BD4-AD32-B2DE4F39948A@muada.com> <4DA6DF7C.7040704@redpill-linpro.com> <6198BBAE-7A30-4311-A2F1-6E8ED991FEF7@muada.com> Message-ID: On Apr 14, 2011, at 5:47 AM, Iljitsch van Beijnum wrote: > On 14 apr 2011, at 13:50, Tore Anderson wrote: > >>> This is address space that's now marked as delegated and removed from >>> the pile of unused address space for no obvious reason. > >> I believe they are using those prefixes for research. > >> and the delegated-extended file, it appears that these prefixes do count >> as assigned space like any other assignment. I would assume that when >> the research project is over, they will be returned to the free pool and >> assigned under the last /8 policy > > That is extremely curious. How can they justify taking 4 million addresses for research two days before running out of regularly allocatable address space? They could have taken that /10 out of the final /8 rather than taking it from the last scraps of regular space if they really need a /10 for research, which is already dubious in and of itself. > > Of course they didn't bother to respond to my request for information about all of this. > I believe that rather than research, those are prefixes which are particularly "dirty" and they have allocated them to the project to try and get them cleaned up so that they can be subsequently issued. Owen From deric.kwok2000 at gmail.com Thu Apr 14 08:47:32 2011 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Thu, 14 Apr 2011 09:47:32 -0400 Subject: switch networking help Message-ID: Hello I would like to ask general question about switch speed experience. How can I increase speed in switch port? ls it to combine more than one port? Any other solution? In combing ports, what are the advantages and disadvantages? Any info and experience. Thank you for your sharing. From tad1214 at gmail.com Thu Apr 14 12:06:59 2011 From: tad1214 at gmail.com (Thomas Donnelly) Date: Thu, 14 Apr 2011 12:06:59 -0500 Subject: switch networking help In-Reply-To: References: Message-ID: On Thu, 14 Apr 2011 08:47:32 -0500, Deric Kwok wrote: > Hello > > I would like to ask general question about switch speed experience. > > How can I increase speed in switch port? The speed of the switch port is limited by the hardware. Make sure you are running a nic capable of the maximum switchport speed and that they are configured to be the maximum speed either by negotiation or manually. Most switches now days are 100mbps or 1000mbps. If it is too slow for you, try upgrading both the end point and replacing the switch to 10G. If you give us a make/model number, it is much easier to tell you what your switch can do. > > ls it to combine more than one port? Any other solution? Yes, there are a few ways and they vary by vendor, but the most common way is LACP etherchannel. http://en.wikipedia.org/wiki/Link_aggregation#Link_Aggregation_Control_Protocol > > In combing ports, what are the advantages and disadvantages? The advantage is increased bandwidth (naturally), also increased redundancy. Unfortunately LACP does not give a true "2gbps" capability, it simply load balances between the two links based on various factors. So a single connection will only go up to 1gbps, even if the nic connecting it to the switch is a 10gbps connection. However for switch uplinks this is rarely a problem (so long as the correct load balancing algorithm is selected) as multiple hosts are connected at 1gbps trying to go upstream. > > Any info and experience. Thank you for your sharing. > This is a 60 second overview and there is much more to this topic than I have said, but hopefully this will get you on your feet. -=Tom Donnelly -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From iljitsch at muada.com Thu Apr 14 16:01:46 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 14 Apr 2011 23:01:46 +0200 Subject: How is IPv6 deployment going in the APNIC region? In-Reply-To: <84200D01-23CF-4BD4-AD32-B2DE4F39948A@muada.com> References: <4DA6920A.1060803@apolix.co.za> <4DA6953E.6010109@redpill-linpro.com> <84200D01-23CF-4BD4-AD32-B2DE4F39948A@muada.com> Message-ID: <09FA6D12-B4AE-4B8C-AAA0-0902367A7A99@muada.com> On 14 apr 2011, at 13:02, Iljitsch van Beijnum wrote: > Based on that file, APNIC still has 17.57 million regular + 2.27 M legacy = 19.84 M total address space, so another 0.5 M wouldn't deplete what's left. I just got the 15 apr file which has the info for 14 apr (sigh...) and indeed 1100 blocks adding up to 0.52 million addresses were given out today. And that still leaves 2.27 million legacy addresses available, including all of 43.224.0.0/11 except 43.244 and 43.253, as well as 0.34 million non-legacy, non-103/8 addresses. 103/8 is apparently going to be the special final /8. It's still wide open except a /16, a /22 and a /24 that are registered to the debogon project (as of a week and a half ago). From fmartin at linkedin.com Thu Apr 14 16:15:55 2011 From: fmartin at linkedin.com (Franck Martin) Date: Thu, 14 Apr 2011 21:15:55 +0000 Subject: How is IPv6 deployment going in the APNIC region? In-Reply-To: <09FA6D12-B4AE-4B8C-AAA0-0902367A7A99@muada.com> Message-ID: Recently, Microsoft Australia has been refused a temp allocation (like they had every year) for one of their conferences. On 4/15/11 9:01 , "Iljitsch van Beijnum" wrote: >On 14 apr 2011, at 13:02, Iljitsch van Beijnum wrote: > >> Based on that file, APNIC still has 17.57 million regular + 2.27 M >>legacy = 19.84 M total address space, so another 0.5 M wouldn't deplete >>what's left. > >I just got the 15 apr file which has the info for 14 apr (sigh...) and >indeed 1100 blocks adding up to 0.52 million addresses were given out >today. And that still leaves 2.27 million legacy addresses available, >including all of 43.224.0.0/11 except 43.244 and 43.253, as well as 0.34 >million non-legacy, non-103/8 addresses. > >103/8 is apparently going to be the special final /8. It's still wide >open except a /16, a /22 and a /24 that are registered to the debogon >project (as of a week and a half ago). From nathan at atlasnetworks.us Thu Apr 14 16:21:09 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Thu, 14 Apr 2011 21:21:09 +0000 Subject: Contact for City of Panama City Beach, FL? Message-ID: <8C26A4FDAE599041A13EB499117D3C286B413E22@ex-mb-1.corp.atlasnetworks.us> Could someone from the IT department for the City of Panama City Beach, Florida please contact me off-list? Best Regards, Nathan Eisenberg From DanD at Harsch.com Thu Apr 14 17:02:36 2011 From: DanD at Harsch.com (Dan Dill) Date: Thu, 14 Apr 2011 15:02:36 -0700 Subject: Contact for City of Panama City Beach, FL? In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B413E22@ex-mb-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C286B413E22@ex-mb-1.corp.atlasnetworks.us> Message-ID: <7FC2D4C244E2EA4F812C6B77AA83821532540540A6@PDX-BE.harsch.com> http://www.pcbgov.com/city_directory.htm Seems like it wouldn't be hard to track down that information... -----Original Message----- From: Nathan Eisenberg [mailto:nathan at atlasnetworks.us] Sent: Thursday, April 14, 2011 2:21 PM To: nanog at nanog.org Subject: Contact for City of Panama City Beach, FL? Could someone from the IT department for the City of Panama City Beach, Florida please contact me off-list? Best Regards, Nathan Eisenberg From Skeeve at eintellego.net Thu Apr 14 17:04:20 2011 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Thu, 14 Apr 2011 22:04:20 +0000 Subject: How is IPv6 deployment going in the APNIC region? In-Reply-To: <09FA6D12-B4AE-4B8C-AAA0-0902367A7A99@muada.com> Message-ID: All? as of early this morning, APNIC is empty. Last /8 Policy is now in effect. ...Skeeve -- Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego or eintellego at facebook.com twitter.com/networkceoau ; www.linkedin.com/in/skeeve PO Box 7726, Baulkham Hills, NSW 1755 Australia -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis On 15/04/11 7:01 AM, "Iljitsch van Beijnum" > wrote: On 14 apr 2011, at 13:02, Iljitsch van Beijnum wrote: Based on that file, APNIC still has 17.57 million regular + 2.27 M legacy = 19.84 M total address space, so another 0.5 M wouldn't deplete what's left. I just got the 15 apr file which has the info for 14 apr (sigh...) and indeed 1100 blocks adding up to 0.52 million addresses were given out today. And that still leaves 2.27 million legacy addresses available, including all of 43.224.0.0/11 except 43.244 and 43.253, as well as 0.34 million non-legacy, non-103/8 addresses. 103/8 is apparently going to be the special final /8. It's still wide open except a /16, a /22 and a /24 that are registered to the debogon project (as of a week and a half ago). From iljitsch at muada.com Thu Apr 14 17:09:43 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 15 Apr 2011 00:09:43 +0200 Subject: How is IPv6 deployment going in the APNIC region? In-Reply-To: References: Message-ID: On 15 apr 2011, at 0:04, Skeeve Stevens wrote: > All? as of early this morning, APNIC is empty. Why do you say that? Do you have information that contradicts my numbers? From Skeeve at eintellego.net Thu Apr 14 17:17:48 2011 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Thu, 14 Apr 2011 22:17:48 +0000 Subject: How is IPv6 deployment going in the APNIC region? In-Reply-To: Message-ID: Just an email from APNIC 3 hours ago to all regional mailing lists. Kinda authoritative I would say. --- On 15/04/11 6:25 AM, "APNIC Secretariat" > wrote: _______________________________________________________________________ APNIC IPv4 Address Pool Reaches Final /8 _______________________________________________________________________ Dear APNIC community We are writing to inform you that as of Friday, 15 April 2011, the APNIC pool reached the Final /8 IPv4 address block, bringing us to Stage Three of IPv4 exhaustion in the Asia Pacific. For more information about Stage Three, please refer to: http://www.apnic.net/ipv4-exhaustion/stages Last /8 address policy ---------------------- IPv4 requests will now be assessed under section 9.10 in "Policies for IPv4 address space management in the Asia Pacific region": http://www.apnic.net/policy/add-manage-policy#9.10 APNIC's objective during Stage Three is to provide IPv4 address space for new entrants to the market and for those deploying IPv6. http://www.apnic.net/ipv4-stage3-faq >From now, all new and existing APNIC account holders will be entitled to receive a maximum allocation of a /22 from the Final /8 address space. For more details on the eligibility criteria according to the Final /8 policy, please refer to: http://www.apnic.net/criteria Act NOW on IPv6 --------------- We encourage Asia Pacific Internet community members to deploy IPv6 within their organizations. You can refer to APNIC for information regarding IPv6 deployment, statistics, training, and related regional policies at: http://www.apnic.net/ipv6 To apply for IPv6 addresses now, please visit: http://www.apnic.net/kickstart _______________________________________________________________________ APNIC Secretariat secretariat at apnic.net Asia Pacific NetworkInformation Centre (APNIC) Tel: +61 7 3858 3100 PO Box 3646 South Brisbane, QLD 4101 Australia Fax: +61 7 3858 3199 6 Cordelia Street, South Brisbane, QLD http://www.apnic.net _______________________________________________________________________ * Sent by email to save paper. Print only if necessary. --- ...Skeeve -- Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego or eintellego at facebook.com twitter.com/networkceoau ; www.linkedin.com/in/skeeve PO Box 7726, Baulkham Hills, NSW 1755 Australia -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis On 15/04/11 8:09 AM, "Iljitsch van Beijnum" > wrote: On 15 apr 2011, at 0:04, Skeeve Stevens wrote: All? as of early this morning, APNIC is empty. Why do you say that? Do you have information that contradicts my numbers? From nathan at atlasnetworks.us Thu Apr 14 17:37:02 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Thu, 14 Apr 2011 22:37:02 +0000 Subject: Contact for City of Panama City Beach, FL? In-Reply-To: <7FC2D4C244E2EA4F812C6B77AA83821532540540A6@PDX-BE.harsch.com> References: <8C26A4FDAE599041A13EB499117D3C286B413E22@ex-mb-1.corp.atlasnetworks.us> <7FC2D4C244E2EA4F812C6B77AA83821532540540A6@PDX-BE.harsch.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B41407F@ex-mb-1.corp.atlasnetworks.us> > -----Original Message----- > From: Dan Dill [mailto:DanD at Harsch.com] > Sent: Thursday, April 14, 2011 3:03 PM > To: Nathan Eisenberg; nanog at nanog.org > Subject: RE: Contact for City of Panama City Beach, FL? > > http://www.pcbgov.com/city_directory.htm > > Seems like it wouldn't be hard to track down that information... I did utilize that page prior to posting to NANOG - sorry for not stating that explicitly. Thanks Dan! From nenolod at systeminplace.net Thu Apr 14 19:50:02 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 14 Apr 2011 19:50:02 -0500 Subject: Contact for City of Panama City Beach, FL? In-Reply-To: <7FC2D4C244E2EA4F812C6B77AA83821532540540A6@PDX-BE.harsch.com> References: <8C26A4FDAE599041A13EB499117D3C286B413E22@ex-mb-1.corp.atlasnetworks.us> <7FC2D4C244E2EA4F812C6B77AA83821532540540A6@PDX-BE.harsch.com> Message-ID: <20110414195002.2d4dfecf@petrie> On Thu, 14 Apr 2011 15:02:36 -0700 Dan Dill wrote: > http://www.pcbgov.com/city_directory.htm > > Seems like it wouldn't be hard to track down that information... Can you identify where on that page it lists a contact for the IT department of the Panama City government? I can't, because it does not list such a contact. William From jra at baylink.com Thu Apr 14 19:53:26 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 14 Apr 2011 20:53:26 -0400 (EDT) Subject: Contact for City of Panama City Beach, FL? In-Reply-To: <20110414195002.2d4dfecf@petrie> Message-ID: <31819842.2601.1302828806381.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Pitcock" > On Thu, 14 Apr 2011 15:02:36 -0700 > Dan Dill wrote: > > http://www.pcbgov.com/city_directory.htm > > > > Seems like it wouldn't be hard to track down that information... > > Can you identify where on that page it lists a contact for the IT > department of the Panama City government? > > I can't, because it does not list such a contact. Aw, c'mon, guys... We just *finished* "Please don't top post; it's annoying" a day or two ago; is it really time for "why can't people just pick up the phone and call" *already*? :-) Cheers, -- jra From nathan at atlasnetworks.us Thu Apr 14 20:32:10 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Fri, 15 Apr 2011 01:32:10 +0000 Subject: Contact for va.gov Message-ID: <8C26A4FDAE599041A13EB499117D3C286B41467C@ex-mb-1.corp.atlasnetworks.us> Yes, two in one day. Wholesalers don't wipe device configs, apparently. Anyways, would a technical contact for va.gov please contact me off-list? Best Regards, Nathan Eisenberg From bret at getjive.com Thu Apr 14 20:45:48 2011 From: bret at getjive.com (Bret Palsson) Date: Thu, 14 Apr 2011 19:45:48 -0600 Subject: Contact for va.gov In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B41467C@ex-mb-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C286B41467C@ex-mb-1.corp.atlasnetworks.us> Message-ID: <5658788450403469030@unknownmsgid> Wouldn't the world be a better place if the ARIN contact information was correct and usable. It would be nice to have an easy place for these types of requests. I guess maybe this list is that place. Sent from my iPhone On Apr 14, 2011, at 7:33 PM, Nathan Eisenberg wrote: > Yes, two in one day. Wholesalers don't wipe device configs, apparently. > > Anyways, would a technical contact for va.gov please contact me off-list? > > Best Regards, > Nathan Eisenberg > > From Josh.Stephens at solarwinds.com Thu Apr 14 21:09:05 2011 From: Josh.Stephens at solarwinds.com (Stephens, Josh) Date: Fri, 15 Apr 2011 02:09:05 +0000 Subject: Contact for va.gov In-Reply-To: <5658788450403469030@unknownmsgid> References: <8C26A4FDAE599041A13EB499117D3C286B41467C@ex-mb-1.corp.atlasnetworks.us> <5658788450403469030@unknownmsgid> Message-ID: <7715397372EE344E96F03DBEA1E8894E3BD548@ADF-MBX-01.tul.solarwinds.net> I pinged a buddy of mine at the VA. No word yet and I'm working from Sydney this week so a bit delayed anyhow... Josh -----Original Message----- From: Bret Palsson [mailto:bret at getjive.com] Sent: Friday, April 15, 2011 11:46 AM To: Nathan Eisenberg Cc: nanog at nanog.org Subject: Re: Contact for va.gov Wouldn't the world be a better place if the ARIN contact information was correct and usable. It would be nice to have an easy place for these types of requests. I guess maybe this list is that place. Sent from my iPhone On Apr 14, 2011, at 7:33 PM, Nathan Eisenberg wrote: > Yes, two in one day. Wholesalers don't wipe device configs, apparently. > > Anyways, would a technical contact for va.gov please contact me off-list? > > Best Regards, > Nathan Eisenberg > > From jda at tapodi.net Thu Apr 14 21:16:20 2011 From: jda at tapodi.net (Jon Auer) Date: Thu, 14 Apr 2011 21:16:20 -0500 Subject: Contact for va.gov In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B41467C@ex-mb-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C286B41467C@ex-mb-1.corp.atlasnetworks.us> Message-ID: On Thu, Apr 14, 2011 at 8:32 PM, Nathan Eisenberg wrote: > Yes, two in one day. ?Wholesalers don't wipe device configs, apparently. > > Anyways, would a technical contact for va.gov please contact me off-list? > > Best Regards, > Nathan Eisenberg > Is tracking down the original user and letting them know about the config leak a standard practice, necessary or "the right thing to do"? I've always just wiped flash and carried on. From jduncan at juniper.net Thu Apr 14 21:23:52 2011 From: jduncan at juniper.net (Jim Duncan) Date: Thu, 14 Apr 2011 22:23:52 -0400 Subject: Contact for va.gov In-Reply-To: <5658788450403469030@unknownmsgid> Message-ID: It would be far more effective if more organizations set up and maintained a slash-security page (see the NIAC Vulnerability Disclosure Framework for details). This is _exactly_ the kind of information that should be posted there. Jim -- James N. Duncan, CISSP Manager, Juniper Networks Security Incident Response Team (Juniper SIRT) E-mail: jduncan at juniper.net Mobile: +1 919 608 0748 PGP key fingerprint: E09E EA55 DA28 1399 75EB D6A2 7092 9A9C 6DC3 1821 ----- Original Message ----- From: Bret Palsson [mailto:bret at getjive.com] Sent: Thursday, April 14, 2011 09:45 PM To: Nathan Eisenberg Cc: nanog at nanog.org Subject: Re: Contact for va.gov Wouldn't the world be a better place if the ARIN contact information was correct and usable. It would be nice to have an easy place for these types of requests. I guess maybe this list is that place. Sent from my iPhone On Apr 14, 2011, at 7:33 PM, Nathan Eisenberg wrote: > Yes, two in one day. Wholesalers don't wipe device configs, apparently. > > Anyways, would a technical contact for va.gov please contact me off-list? > > Best Regards, > Nathan Eisenberg > > From nathan at atlasnetworks.us Thu Apr 14 21:54:15 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Fri, 15 Apr 2011 02:54:15 +0000 Subject: Contact for va.gov In-Reply-To: References: <8C26A4FDAE599041A13EB499117D3C286B41467C@ex-mb-1.corp.atlasnetworks.us> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B414806@ex-mb-1.corp.atlasnetworks.us> > Is tracking down the original user and letting them know about the > config leak a standard practice, necessary or "the right thing to do"? Municipal networks often provide some emergency services, and we all know what the VA provides. Once you know whose gear it is, I guess you have to decide if you'd be willing to have a little bit of that organization's (or their patrons) blood on your hands. Especially in the case of the VA, for me, the answer is 'hell no'. If it was "Joes defunct sprocket startup", I'd likely just format flash: and move on. Nathan From mike-nanog at tiedyenetworks.com Thu Apr 14 22:28:00 2011 From: mike-nanog at tiedyenetworks.com (Mike) Date: Thu, 14 Apr 2011 20:28:00 -0700 Subject: Contact for va.gov In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B414806@ex-mb-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C286B41467C@ex-mb-1.corp.atlasnetworks.us> <8C26A4FDAE599041A13EB499117D3C286B414806@ex-mb-1.corp.atlasnetworks.us> Message-ID: <4DA7BB40.6060700@tiedyenetworks.com> On 04/14/2011 07:54 PM, Nathan Eisenberg wrote: >> Is tracking down the original user and letting them know about the >> config leak a standard practice, necessary or "the right thing to do"? > > Municipal networks often provide some emergency services, and we all know what the VA provides. Once you know whose gear it is, I guess you have to decide if you'd be willing to have a little bit of that organization's (or their patrons) blood on your hands. > > Especially in the case of the VA, for me, the answer is 'hell no'. If it was "Joes defunct sprocket startup", I'd likely just format flash: and move on. > > A few months back I had exactly this situation - I bought a switch off ebay that was still loaded with it's config, and it had come from yahoo.com. Now, I am the good netizen and I flagged them about this and was able to help them find the source which I assume they 'fixed' this leak. The data in the fig file could have been (mis)used to yahoo's network security disadvantage and wherever you stand I think we all can agree that cluing them in was the right thing to do. But for someone else's startup, probably would not have bothered. Mike- From gih at apnic.net Fri Apr 15 05:21:05 2011 From: gih at apnic.net (Geoff Huston) Date: Fri, 15 Apr 2011 20:21:05 +1000 Subject: How is IPv6 deployment going in the APNIC region? In-Reply-To: <6198BBAE-7A30-4311-A2F1-6E8ED991FEF7@muada.com> References: <4DA6920A.1060803@apolix.co.za> <4DA6953E.6010109@redpill-linpro.com> <84200D01-23CF-4BD4-AD32-B2DE4F39948A@muada.com> <4DA6DF7C.7040704@redpill-linpro.com> <6198BBAE-7A30-4311-A2F1-6E8ED991FEF7@muada.com> Message-ID: <82972B9A-801E-4278-9921-F2CAAE93B168@apnic.net> On 14/04/2011, at 10:47 PM, Iljitsch van Beijnum wrote: > On 14 apr 2011, at 13:50, Tore Anderson wrote: > >>> This is address space that's now marked as delegated and removed from >>> the pile of unused address space for no obvious reason. > >> I believe they are using those prefixes for research. > >> and the delegated-extended file, it appears that these prefixes do count >> as assigned space like any other assignment. I would assume that when >> the research project is over, they will be returned to the free pool and >> assigned under the last /8 policy > > That is extremely curious. How can they justify taking 4 million addresses for research two days before running out of regularly allocatable address space? They could have taken that /10 out of the final /8 rather than taking it from the last scraps of regular space if they really need a /10 for research, which is already dubious in and of itself. > > Of course they didn't bother to respond to my request for information about all of this. > > The addresses were "in flight" to the recipient and got caught up in a set of scripted processes that inappropriately assigned them into the debogon project for a couple of days while some related administrative processes were underway. Our apologies for the temporary confusion -- and we promise do better next time! :-) And yes, APNIC is indeed down to the last /8 - contains the announcement Also, our apologies for not getting back to Iljitsch's request for information sooner - we have been somewhat busy in the last few days! thanks, Geoff From iljitsch at muada.com Fri Apr 15 06:18:44 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 15 Apr 2011 13:18:44 +0200 Subject: How is IPv6 deployment going in the APNIC region? In-Reply-To: <82972B9A-801E-4278-9921-F2CAAE93B168@apnic.net> References: <4DA6920A.1060803@apolix.co.za> <4DA6953E.6010109@redpill-linpro.com> <84200D01-23CF-4BD4-AD32-B2DE4F39948A@muada.com> <4DA6DF7C.7040704@redpill-linpro.com> <6198BBAE-7A30-4311-A2F1-6E8ED991FEF7@muada.com> <82972B9A-801E-4278-9921-F2CAAE93B168@apnic.net> Message-ID: <45A3AAB3-10B3-44DD-89A4-32B6ACB90DA6@muada.com> On 15 apr 2011, at 12:21, Geoff Huston wrote: > The addresses were "in flight" to the recipient and got caught up in a set of scripted processes that inappropriately assigned them into the debogon project for a couple of days while some related administrative processes were underway. > Our apologies for the temporary confusion -- and we promise do better next time! :-) Thanks for the clarification. But I hope you're not planning on running out of IPv6 anytime soon... Or maybe you're getting at 16-bit AS numbers? > And yes, APNIC is indeed down to the last /8 Hm, I still see 2.27 million legacy addresses as free, mostly 43.224.0.0/11 except 43.244 and 43.253, as well as 0.34 million non-legacy. Why don't these count and/or what will happen to them? Iljitsch From harbor235 at gmail.com Fri Apr 15 08:14:05 2011 From: harbor235 at gmail.com (harbor235) Date: Fri, 15 Apr 2011 09:14:05 -0400 Subject: 365x24x7 Message-ID: If I were going to provide a 365x24x7 NOC, how many teams of personnel do I need to fully cover operations? I assume minimally you need 3 teams to cover the required 24 hr coverage, but there is off time and schedule rotation? thoughts, experience? Mike From rfg at tristatelogic.com Fri Apr 15 08:17:06 2011 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 15 Apr 2011 06:17:06 -0700 Subject: New hijacks, and lots of them In-Reply-To: <5824.1302780126@tristatelogic.com> Message-ID: <2971.1302873426@tristatelogic.com> In message <5824.1302780126 at tristatelogic.com>, I wrote: > http://www.47-usc-230c2.org/20110414-snowshoe-1.txt > http://www.47-usc-230c2.org/20110414-snowshoe-2.txt My apologies to anyone and everyone who tried to get at these files. It seems that my provider may perhaps have recently developed some rather odd ideas about packet filtering for static broadband lines. Until I can get the problem worked out, the following alternative URLs ought to do instead: ftp://ftp.47-usc-230c2.org/pub/20110414-snowshoe-1.txt ftp://ftp.47-usc-230c2.org/pub/20110414-snowshoe-2.txt From peter.hicks at poggs.co.uk Fri Apr 15 08:17:48 2011 From: peter.hicks at poggs.co.uk (Peter Hicks) Date: Fri, 15 Apr 2011 14:17:48 +0100 Subject: 365x24x7 In-Reply-To: References: Message-ID: <066F653E-C0F8-4026-9FE0-3A8899378D0C@poggs.co.uk> On 15 Apr 2011, at 14:14, harbor235 wrote: > If I were going to provide a 365x24x7 NOC, how many teams of personnel do I > need to fully cover operations? I assume minimally you need 3 teams to cover the > required 24 hr coverage, but there is off time and schedule rotation? Although more geared up for on-call, http://blog.hinterlands.org/2010/07/running-an-oncall-rota/ is a very useful resource. Peter From w3yni1 at gmail.com Fri Apr 15 08:25:02 2011 From: w3yni1 at gmail.com (Charles Mills) Date: Fri, 15 Apr 2011 09:25:02 -0400 Subject: 365x24x7 In-Reply-To: References: Message-ID: I've had it done in places where I work where you'll have 3 rotations working 12 hour shifts. In a 2 week pay period they get their 80 hours in a blend 36 one week and 44 the next. It gives some nice consecutive days off time which also doubles as a retention tool for some employees. You might have to get creative to have all the days work out but it can be done. On Fri, Apr 15, 2011 at 9:14 AM, harbor235 wrote: > If I were going to provide a 365x24x7 NOC, how many teams of personnel do I > need > to fully cover operations? I assume minimally you need 3 teams to cover the > required > 24 hr coverage, but there is off time and schedule rotation? > > thoughts, experience? > > Mike > -- ===================================== Charles L. Mills Email: w3yni1 at gmail.com ===================================== Need server hosting, DR or colocation services?? See me! From mooregr at greenms.com Fri Apr 15 08:37:54 2011 From: mooregr at greenms.com (Greg Moore) Date: Fri, 15 Apr 2011 09:37:54 -0400 Subject: 365x24x7 Message-ID: When I did this years ago I found 5 was really a minimum so that I could cover weekends and then had extra coverage as needed during the week. I did find it was good to swap out the graveyard shift every 6 months or so. -----Original Message----- From: harbor235 Sent: Friday, April 15, 2011 9:14 AM To: NANOG list Subject: 365x24x7 If I were going to provide a 365x24x7 NOC, how many teams of personnel do I need to fully cover operations? I assume minimally you need 3 teams to cover the required 24 hr coverage, but there is off time and schedule rotation? thoughts, experience? Mike From sclark at netwolves.com Fri Apr 15 08:48:42 2011 From: sclark at netwolves.com (Steve Clark) Date: Fri, 15 Apr 2011 09:48:42 -0400 Subject: 365x24x7 In-Reply-To: References: Message-ID: <4DA84CBA.5030409@netwolves.com> On 04/15/2011 09:25 AM, Charles Mills wrote: > I've had it done in places where I work where you'll have 3 rotations > working 12 hour shifts. > > In a 2 week pay period they get their 80 hours in a blend 36 one week > and 44 the next. It gives some nice consecutive days off time which > also doubles as a retention tool for some employees. You might have > to get creative to have all the days work out but it can be done. > > On Fri, Apr 15, 2011 at 9:14 AM, harbor235 wrote: >> If I were going to provide a 365x24x7 NOC, how many teams of personnel do I >> need >> to fully cover operations? I assume minimally you need 3 teams to cover the >> required >> 24 hr coverage, but there is off time and schedule rotation? >> >> thoughts, experience? >> >> Mike >> > > I worked once in a production plant. They had 4 crews a,b,c,d and worked 6 days on 2 off. It was rotating shifts. As an example crew A worked 6 days 8-4 was off 2 days then started the next shift on 4-midnight, then midnight to 8. So at any one day 3 of the 4 crews were working and the other crew was off. -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com From tme at americafree.tv Fri Apr 15 08:52:11 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 15 Apr 2011 09:52:11 -0400 Subject: 365x24x7 In-Reply-To: References: Message-ID: On Apr 15, 2011, at 9:37 AM, Greg Moore wrote: > When I did this years ago I found 5 was really a minimum so that I could cover weekends and then had extra coverage as needed during the week. > > I did find it was good to swap out the graveyard shift every 6 months or so. > When I worked with NASA and the Navy on remote locations that needed full time staffing, the rule of thumb was 5 people and 4 shifts was the absolute minimum, and the people had to be motivated enough to pull 12 hour shifts on a regular basis (i.e., this was very bare bones). The 4th shift was needed during the weekends. Anything less, and you would have uncovered periods if, say, 2 people got sick simultaneously. Regards Marshall > -----Original Message----- > From: harbor235 > Sent: Friday, April 15, 2011 9:14 AM > To: NANOG list > Subject: 365x24x7 > > If I were going to provide a 365x24x7 NOC, how many teams of personnel do I > need > to fully cover operations? I assume minimally you need 3 teams to cover the > required > 24 hr coverage, but there is off time and schedule rotation? > > thoughts, experience? > > Mike > > > From askoorb+nanog at gmail.com Fri Apr 15 09:27:32 2011 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Fri, 15 Apr 2011 15:27:32 +0100 Subject: 365x24x7 In-Reply-To: References: Message-ID: On Fri, Apr 15, 2011 at 2:14 PM, harbor235 wrote: > If I were going to provide a 365x24x7 NOC, how many teams of personnel do I > need > to fully cover operations? I assume minimally you need 3 teams to cover the > required > 24 hr coverage, but there is off time and schedule rotation? Well, if you feel like being "nice" to your employees, or want to stop them from making mistakes a few months/years in to shift work, (or if you're having to set something up abroad), the Working Time Directive can be a useful guideline. (Full details at http://en.wikipedia.org/wiki/Working_Time_Directive and http://www.businesslink.gov.uk/bdotg/action/layer?topicId=1073858926 if you're board, ignore the silly bits) But basically, in general, workers aged 18 and over are entitled to: - work no more than six days out of every seven, or 12 out of every 14 - take a 20-minute break if their shift lasts for more than six hours - work a maximum 48-hour average week And in general, night workers: - should not work more than an average of eight hours in a 24-hour period, averaged over a reference period of 17 weeks If you're an employer, be glad you're in North America :-) HTH, Alex From Randall.K.Sanders at xo.com Fri Apr 15 09:31:48 2011 From: Randall.K.Sanders at xo.com (Sanders, Randall K) Date: Fri, 15 Apr 2011 09:31:48 -0500 Subject: 365x24x7 In-Reply-To: References: Message-ID: Have you taken into account number of alarms per hour, inbound call volume for repairs, and how much repair is done at the first tier level? Bare minimum staffing in a busy environment? Randy Sanders -----Original Message----- From: Alex Brooks [mailto:askoorb+nanog at gmail.com] Sent: Friday, April 15, 2011 9:28 AM To: nanog Subject: Re: 365x24x7 On Fri, Apr 15, 2011 at 2:14 PM, harbor235 wrote: > If I were going to provide a 365x24x7 NOC, how many teams of personnel do I > need > to fully cover operations? I assume minimally you need 3 teams to cover the > required > 24 hr coverage, but there is off time and schedule rotation? Well, if you feel like being "nice" to your employees, or want to stop them from making mistakes a few months/years in to shift work, (or if you're having to set something up abroad), the Working Time Directive can be a useful guideline. (Full details at http://en.wikipedia.org/wiki/Working_Time_Directive and http://www.businesslink.gov.uk/bdotg/action/layer?topicId=1073858926 if you're board, ignore the silly bits) But basically, in general, workers aged 18 and over are entitled to: - work no more than six days out of every seven, or 12 out of every 14 - take a 20-minute break if their shift lasts for more than six hours - work a maximum 48-hour average week And in general, night workers: - should not work more than an average of eight hours in a 24-hour period, averaged over a reference period of 17 weeks If you're an employer, be glad you're in North America :-) HTH, Alex From dot at dotat.at Fri Apr 15 09:36:35 2011 From: dot at dotat.at (Tony Finch) Date: Fri, 15 Apr 2011 15:36:35 +0100 Subject: 365x24x7 In-Reply-To: References: Message-ID: harbor235 wrote: > If I were going to provide a 365x24x7 NOC, how many teams of personnel > do I need to fully cover operations? Hours in the working year = 8 * 5 * 48 = 1920 Hours in the calendar year = 24 * 7 * 52 = 8736 Ratio = 4.55 Tony. -- f.anthony.n.finch http://dotat.at/ Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5 or 6 later. Rough or very rough. Occasional rain. Moderate or good, occasionally poor. From harbor235 at gmail.com Fri Apr 15 09:52:02 2011 From: harbor235 at gmail.com (harbor235) Date: Fri, 15 Apr 2011 10:52:02 -0400 Subject: 365x24x7 In-Reply-To: References: Message-ID: Guys, Thanx alot, there is some great stuff here, also some stuff I had not thought of. thanx again, Mike On Fri, Apr 15, 2011 at 10:36 AM, Tony Finch wrote: > harbor235 wrote: > > > If I were going to provide a 365x24x7 NOC, how many teams of personnel > > do I need to fully cover operations? > > Hours in the working year = 8 * 5 * 48 = 1920 > Hours in the calendar year = 24 * 7 * 52 = 8736 > Ratio = 4.55 > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in > Rockall and Malin, veering west or northwest 4 or 5, then backing southwest > 5 > or 6 later. Rough or very rough. Occasional rain. Moderate or good, > occasionally poor. > From paul at paulgraydon.co.uk Fri Apr 15 10:52:13 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Fri, 15 Apr 2011 05:52:13 -1000 Subject: 365x24x7 In-Reply-To: References: Message-ID: <4DA869AD.9070202@paulgraydon.co.uk> On 4/15/2011 3:14 AM, harbor235 wrote: > If I were going to provide a 365x24x7 NOC, how many teams of personnel do I > need > to fully cover operations? I assume minimally you need 3 teams to cover the > required > 24 hr coverage, but there is off time and schedule rotation? > > thoughts, experience? > > Mike > For what it's worth, was part of a datacenter operations department that had a 24x7 team. 4 shifts, 4 staff on each shift (1 was supervisor who did same work as the rest, 1 'point of contact' who stayed in the office). 4 days on, 4 days off, 12 hour shifts, 8-8. Shift teams would alternate between day and night (so 4 day, 4 off, 4 night, 4 off, repeat ad infinitum). During the day that was bolstered by 6 day-staff, Monday to Friday, who would have a staggered start through the day (IIRC 2 start at 8, 2 at 9, 2 at 11) From ktm200exc at hotmail.com Fri Apr 15 11:44:47 2011 From: ktm200exc at hotmail.com (Mark Green) Date: Fri, 15 Apr 2011 09:44:47 -0700 Subject: 365x24x7 (sleep patterns) In-Reply-To: References: Message-ID: Suggestion; once on the 'night shift' stay put for at least three months... Sleep patterns take time to adjust. Jumping between day and night shifts will burn out even the most motivated employee. Mark Green > From: nanog-request at nanog.org > Subject: NANOG Digest, Vol 39, Issue 46 > To: nanog at nanog.org > Date: Fri, 15 Apr 2011 15:52:19 +0000 > > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. 365x24x7 (harbor235) > 2. Re: New hijacks, and lots of them (Ronald F. Guilmette) > 3. Re: 365x24x7 (Peter Hicks) > 4. Re: 365x24x7 (Charles Mills) > 5. RE: 365x24x7 (Greg Moore) > 6. Re: 365x24x7 (Steve Clark) > 7. Re: 365x24x7 (Marshall Eubanks) > 8. Re: 365x24x7 (Alex Brooks) > 9. RE: 365x24x7 (Sanders, Randall K) > 10. Re: 365x24x7 (Tony Finch) > 11. Re: 365x24x7 (harbor235) > 12. Re: 365x24x7 (Paul Graydon) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 15 Apr 2011 09:14:05 -0400 > From: harbor235 > Subject: 365x24x7 > To: NANOG list > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > If I were going to provide a 365x24x7 NOC, how many teams of personnel do I > need > to fully cover operations? I assume minimally you need 3 teams to cover the > required > 24 hr coverage, but there is off time and schedule rotation? > > thoughts, experience? > > Mike > > > ------------------------------ > > Message: 2 > Date: Fri, 15 Apr 2011 06:17:06 -0700 > From: "Ronald F. Guilmette" > Subject: Re: New hijacks, and lots of them > To: nanog at nanog.org > Message-ID: <2971.1302873426 at tristatelogic.com> > > > In message <5824.1302780126 at tristatelogic.com>, I wrote: > > > http://www.47-usc-230c2.org/20110414-snowshoe-1.txt > > http://www.47-usc-230c2.org/20110414-snowshoe-2.txt > > My apologies to anyone and everyone who tried to get at these files. > It seems that my provider may perhaps have recently developed some > rather odd ideas about packet filtering for static broadband lines. > Until I can get the problem worked out, the following alternative URLs > ought to do instead: > > ftp://ftp.47-usc-230c2.org/pub/20110414-snowshoe-1.txt > ftp://ftp.47-usc-230c2.org/pub/20110414-snowshoe-2.txt > > > > > ------------------------------ > > Message: 3 > Date: Fri, 15 Apr 2011 14:17:48 +0100 > From: Peter Hicks > Subject: Re: 365x24x7 > To: harbor235 > Cc: NANOG list > Message-ID: <066F653E-C0F8-4026-9FE0-3A8899378D0C at poggs.co.uk> > Content-Type: text/plain; charset=us-ascii > > > On 15 Apr 2011, at 14:14, harbor235 wrote: > > > If I were going to provide a 365x24x7 NOC, how many teams of personnel do I > > need to fully cover operations? I assume minimally you need 3 teams to cover the > > required 24 hr coverage, but there is off time and schedule rotation? > > > Although more geared up for on-call, http://blog.hinterlands.org/2010/07/running-an-oncall-rota/ is a very useful resource. > > > Peter > > > > ------------------------------ > > Message: 4 > Date: Fri, 15 Apr 2011 09:25:02 -0400 > From: Charles Mills > Subject: Re: 365x24x7 > To: harbor235 , NANOG list > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > I've had it done in places where I work where you'll have 3 rotations > working 12 hour shifts. > > In a 2 week pay period they get their 80 hours in a blend 36 one week > and 44 the next. It gives some nice consecutive days off time which > also doubles as a retention tool for some employees. You might have > to get creative to have all the days work out but it can be done. > > On Fri, Apr 15, 2011 at 9:14 AM, harbor235 wrote: > > If I were going to provide a 365x24x7 NOC, how many teams of personnel do I > > need > > to fully cover operations? I assume minimally you need 3 teams to cover the > > required > > 24 hr coverage, but there is off time and schedule rotation? > > > > thoughts, experience? > > > > Mike > > > > > > -- > ===================================== > Charles L. Mills > Email: w3yni1 at gmail.com > ===================================== > Need server hosting, DR or colocation services?? See me! > > > > ------------------------------ > > Message: 5 > Date: Fri, 15 Apr 2011 09:37:54 -0400 > From: Greg Moore > Subject: RE: 365x24x7 > To: harbor235 , NANOG list > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > When I did this years ago I found 5 was really a minimum so that I could cover weekends and then had extra coverage as needed during the week. > > I did find it was good to swap out the graveyard shift every 6 months or so. > > -----Original Message----- > From: harbor235 > Sent: Friday, April 15, 2011 9:14 AM > To: NANOG list > Subject: 365x24x7 > > If I were going to provide a 365x24x7 NOC, how many teams of personnel do I > need > to fully cover operations? I assume minimally you need 3 teams to cover the > required > 24 hr coverage, but there is off time and schedule rotation? > > thoughts, experience? > > Mike > > > > > ------------------------------ > > Message: 6 > Date: Fri, 15 Apr 2011 09:48:42 -0400 > From: Steve Clark > Subject: Re: 365x24x7 > To: Charles Mills > Cc: NANOG list > Message-ID: <4DA84CBA.5030409 at netwolves.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 04/15/2011 09:25 AM, Charles Mills wrote: > > I've had it done in places where I work where you'll have 3 rotations > > working 12 hour shifts. > > > > In a 2 week pay period they get their 80 hours in a blend 36 one week > > and 44 the next. It gives some nice consecutive days off time which > > also doubles as a retention tool for some employees. You might have > > to get creative to have all the days work out but it can be done. > > > > On Fri, Apr 15, 2011 at 9:14 AM, harbor235 wrote: > >> If I were going to provide a 365x24x7 NOC, how many teams of personnel do I > >> need > >> to fully cover operations? I assume minimally you need 3 teams to cover the > >> required > >> 24 hr coverage, but there is off time and schedule rotation? > >> > >> thoughts, experience? > >> > >> Mike > >> > > > > > I worked once in a production plant. They had 4 crews a,b,c,d and worked 6 days on 2 off. It was rotating shifts. As an example crew A worked 6 > days 8-4 was off 2 days then started the next shift on 4-midnight, then midnight to 8. So at any one day 3 of the 4 crews were working and the other > crew was off. > > -- > Stephen Clark > *NetWolves* > Sr. Software Engineer III > Phone: 813-579-3200 > Fax: 813-882-0209 > Email: steve.clark at netwolves.com > http://www.netwolves.com > > > ------------------------------ > > Message: 7 > Date: Fri, 15 Apr 2011 09:52:11 -0400 > From: Marshall Eubanks > Subject: Re: 365x24x7 > To: Greg Moore > Cc: NANOG list > Message-ID: > Content-Type: text/plain; charset=us-ascii > > > > On Apr 15, 2011, at 9:37 AM, Greg Moore wrote: > > > When I did this years ago I found 5 was really a minimum so that I could cover weekends and then had extra coverage as needed during the week. > > > > I did find it was good to swap out the graveyard shift every 6 months or so. > > > > When I worked with NASA and the Navy on remote locations that needed full time staffing, the rule of thumb was > 5 people and 4 shifts was the absolute minimum, and the people had to be motivated enough to pull 12 hour shifts on a regular basis (i.e., this > was very bare bones). The 4th shift was needed during the weekends. > > Anything less, and you would have uncovered periods if, say, 2 people got sick simultaneously. > > Regards > Marshall > > > > -----Original Message----- > > From: harbor235 > > Sent: Friday, April 15, 2011 9:14 AM > > To: NANOG list > > Subject: 365x24x7 > > > > If I were going to provide a 365x24x7 NOC, how many teams of personnel do I > > need > > to fully cover operations? I assume minimally you need 3 teams to cover the > > required > > 24 hr coverage, but there is off time and schedule rotation? > > > > thoughts, experience? > > > > Mike > > > > > > > > > > > ------------------------------ > > Message: 8 > Date: Fri, 15 Apr 2011 15:27:32 +0100 > From: Alex Brooks > Subject: Re: 365x24x7 > To: nanog > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > On Fri, Apr 15, 2011 at 2:14 PM, harbor235 wrote: > > If I were going to provide a 365x24x7 NOC, how many teams of personnel do I > > need > > to fully cover operations? I assume minimally you need 3 teams to cover the > > required > > 24 hr coverage, but there is off time and schedule rotation? > > Well, if you feel like being "nice" to your employees, or want to stop > them from making mistakes a few months/years in to shift work, (or if > you're having to set something up abroad), the Working Time Directive > can be a useful guideline. > > (Full details at http://en.wikipedia.org/wiki/Working_Time_Directive > and http://www.businesslink.gov.uk/bdotg/action/layer?topicId=1073858926 > if you're board, ignore the silly bits) > > But basically, in general, workers aged 18 and over are entitled to: > > - work no more than six days out of every seven, or 12 out of every 14 > - take a 20-minute break if their shift lasts for more than six hours > - work a maximum 48-hour average week > > And in general, night workers: > > - should not work more than an average of eight hours in a 24-hour > period, averaged over a reference period of 17 weeks > > If you're an employer, be glad you're in North America :-) > > HTH, > > Alex > > > > ------------------------------ > > Message: 9 > Date: Fri, 15 Apr 2011 09:31:48 -0500 > From: "Sanders, Randall K" > Subject: RE: 365x24x7 > To: nanog > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > Have you taken into account number of alarms per hour, inbound call volume for repairs, and how much repair is done at the first tier level? Bare minimum staffing in a busy environment? > > Randy Sanders > > -----Original Message----- > From: Alex Brooks [mailto:askoorb+nanog at gmail.com] > Sent: Friday, April 15, 2011 9:28 AM > To: nanog > Subject: Re: 365x24x7 > > On Fri, Apr 15, 2011 at 2:14 PM, harbor235 wrote: > > If I were going to provide a 365x24x7 NOC, how many teams of personnel do I > > need > > to fully cover operations? I assume minimally you need 3 teams to cover the > > required > > 24 hr coverage, but there is off time and schedule rotation? > > Well, if you feel like being "nice" to your employees, or want to stop > them from making mistakes a few months/years in to shift work, (or if > you're having to set something up abroad), the Working Time Directive > can be a useful guideline. > > (Full details at http://en.wikipedia.org/wiki/Working_Time_Directive > and http://www.businesslink.gov.uk/bdotg/action/layer?topicId=1073858926 > if you're board, ignore the silly bits) > > But basically, in general, workers aged 18 and over are entitled to: > > - work no more than six days out of every seven, or 12 out of every 14 > - take a 20-minute break if their shift lasts for more than six hours > - work a maximum 48-hour average week > > And in general, night workers: > > - should not work more than an average of eight hours in a 24-hour > period, averaged over a reference period of 17 weeks > > If you're an employer, be glad you're in North America :-) > > HTH, > > Alex > > > > > > > ------------------------------ > > Message: 10 > Date: Fri, 15 Apr 2011 15:36:35 +0100 > From: Tony Finch > Subject: Re: 365x24x7 > To: harbor235 > Cc: NANOG list > Message-ID: > > Content-Type: TEXT/PLAIN; charset=US-ASCII > > harbor235 wrote: > > > If I were going to provide a 365x24x7 NOC, how many teams of personnel > > do I need to fully cover operations? > > Hours in the working year = 8 * 5 * 48 = 1920 > Hours in the calendar year = 24 * 7 * 52 = 8736 > Ratio = 4.55 > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in > Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5 > or 6 later. Rough or very rough. Occasional rain. Moderate or good, > occasionally poor. > > > > ------------------------------ > > Message: 11 > Date: Fri, 15 Apr 2011 10:52:02 -0400 > From: harbor235 > Subject: Re: 365x24x7 > To: NANOG list > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > Guys, > > Thanx alot, there is some great stuff here, also some stuff I had not > thought of. > > thanx again, > > Mike > > On Fri, Apr 15, 2011 at 10:36 AM, Tony Finch wrote: > > > harbor235 wrote: > > > > > If I were going to provide a 365x24x7 NOC, how many teams of personnel > > > do I need to fully cover operations? > > > > Hours in the working year = 8 * 5 * 48 = 1920 > > Hours in the calendar year = 24 * 7 * 52 = 8736 > > Ratio = 4.55 > > > > Tony. > > -- > > f.anthony.n.finch http://dotat.at/ > > Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in > > Rockall and Malin, veering west or northwest 4 or 5, then backing southwest > > 5 > > or 6 later. Rough or very rough. Occasional rain. Moderate or good, > > occasionally poor. > > > > > ------------------------------ > > Message: 12 > Date: Fri, 15 Apr 2011 05:52:13 -1000 > From: Paul Graydon > Subject: Re: 365x24x7 > To: nanog at nanog.org > Message-ID: <4DA869AD.9070202 at paulgraydon.co.uk> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 4/15/2011 3:14 AM, harbor235 wrote: > > If I were going to provide a 365x24x7 NOC, how many teams of personnel do I > > need > > to fully cover operations? I assume minimally you need 3 teams to cover the > > required > > 24 hr coverage, but there is off time and schedule rotation? > > > > thoughts, experience? > > > > Mike > > > For what it's worth, was part of a datacenter operations department that > had a 24x7 team. 4 shifts, 4 staff on each shift (1 was supervisor who > did same work as the rest, 1 'point of contact' who stayed in the office). > 4 days on, 4 days off, 12 hour shifts, 8-8. Shift teams would alternate > between day and night (so 4 day, 4 off, 4 night, 4 off, repeat ad > infinitum). During the day that was bolstered by 6 day-staff, Monday to > Friday, who would have a staggered start through the day (IIRC 2 start > at 8, 2 at 9, 2 at 11) > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 39, Issue 46 > ************************************* From george.herbert at gmail.com Fri Apr 15 11:50:32 2011 From: george.herbert at gmail.com (George Herbert) Date: Fri, 15 Apr 2011 09:50:32 -0700 Subject: 365x24x7 In-Reply-To: References: Message-ID: On Fri, Apr 15, 2011 at 6:52 AM, Marshall Eubanks wrote: > > > On Apr 15, 2011, at 9:37 AM, Greg Moore wrote: > >> When I did this years ago I found 5 was really a minimum so that I could cover weekends and then had extra coverage as needed during the week. >> >> I did find it was good to swap out the graveyard shift every 6 months or so. >> > > When I worked with NASA and the Navy on remote locations that needed full time staffing, the rule of thumb was > 5 people and 4 shifts was the absolute minimum, and the people had to be motivated enough to pull 12 hour shifts on a regular basis (i.e., this > was very bare bones). The 4th shift was needed during the weekends. > > Anything less, and you would have uncovered periods if, say, 2 people got sick simultaneously. I believe that for ongoing long term operations, NASA and DOD standards are 6 shifts worth of people, however you juggle the particular shift lengths / schedules. I.e., NORAD, NASA ISS / Moon mission mission control, etc. You can do it with 5, but people need time to get sick, take vacations, go to training, etc. -- -george william herbert george.herbert at gmail.com From nanog at thedaileyplanet.com Fri Apr 15 11:53:47 2011 From: nanog at thedaileyplanet.com (Chad Dailey) Date: Fri, 15 Apr 2011 11:53:47 -0500 Subject: 365x24x7 (sleep patterns) In-Reply-To: References: Message-ID: +1. I'd go to six months, having been the night shift bitch. Flipping shifts around damn near killed me. On Fri, Apr 15, 2011 at 11:44 AM, Mark Green wrote: > > Suggestion; once on the 'night shift' stay put for at least three months... > Sleep patterns take time to adjust. Jumping between day and night shifts > will burn out even the most motivated employee. > > Mark Green > > > > ..snip.. From mikea at mikea.ath.cx Fri Apr 15 12:11:45 2011 From: mikea at mikea.ath.cx (mikea) Date: Fri, 15 Apr 2011 12:11:45 -0500 Subject: 365x24x7 (sleep patterns) In-Reply-To: References: Message-ID: <20110415171145.GA57757@mikea.ath.cx> On Fri, Apr 15, 2011 at 11:53:47AM -0500, Chad Dailey wrote: > +1. I'd go to six months, having been the night shift bitch. Flipping > shifts around damn near killed me. > On Fri, Apr 15, 2011 at 11:44 AM, Mark Green wrote: > > Suggestion; once on the 'night shift' stay put for at least three months... > > Sleep patterns take time to adjust. Jumping between day and night shifts > > will burn out even the most motivated employee. Amen. There is evidence that, other things being relatively equal, people working rotating shifts have shorter life expectancies and that the faster the rotation, the shorter the expectancy gets. There also is some evidence that people working rotating shifts are more likely to get cancer. My experience: 6 on, 2 off, 8 hours, rotating to the next later shift: I never, ever got enough sleep -- for 2 years. 6 on, 2 off, 12 hours, straight mids, no rotation: much less bad. 5 on, 2 off, 8 hours, straight mids: quite tolerable. 5 on, 2 off, 8 hours, straight swings (1600-0000): out of phase with the world. YMMV; I expect it to. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From vinny at abellohome.net Fri Apr 15 12:24:45 2011 From: vinny at abellohome.net (Vinny Abello) Date: Fri, 15 Apr 2011 13:24:45 -0400 Subject: 365x24x7 (sleep patterns) In-Reply-To: References: Message-ID: In a past work life, there was a short experimental run where it was believed that the company I worked for could achieve 24/7 coverage through individuals being on-call throughout the entire weekend AND doing overnight maintenance during the week in 12 hour daily shifts from 8PM to 8AM. Needless to say, coming from a daytime schedule one week, covering all pages on a weekend which prevented you from getting much sleep, working 5 12 hour shifts in the following week on shortened sleep cycles (over 100 hours in total with the on-call and 12 hour shifts), then switching back to daytime hours the next week took a toll on me rather quickly. I think we got an extra week day off in there somewhere to recover the following week, but it was basically like running a person into the ground until they were almost dead, then letting them recover while the same thing was done to the next person. There were only 4 people to abuse like this at the time so it happened once a month. Luckily everyone came to their senses and realized this wasn't sustainable and it didn't last for more than a few months total. Moral of the story, don't do this to people unless you're into torture. :) -Vinny On Fri, 15 Apr 2011 11:53:47 -0500, Chad Dailey wrote: > +1. I'd go to six months, having been the night shift bitch. > Flipping > shifts around damn near killed me. > > On Fri, Apr 15, 2011 at 11:44 AM, Mark Green > wrote: > >> >> Suggestion; once on the 'night shift' stay put for at least three >> months... >> Sleep patterns take time to adjust. Jumping between day and night >> shifts >> will burn out even the most motivated employee. >> >> Mark Green >> >> >> >> > ..snip.. From tme at americafree.tv Fri Apr 15 12:41:26 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 15 Apr 2011 13:41:26 -0400 Subject: 365x24x7 (sleep patterns) In-Reply-To: References: Message-ID: On Apr 15, 2011, at 12:44 PM, Mark Green wrote: > > Suggestion; once on the 'night shift' stay put for at least three months... Sleep patterns take time to adjust. Jumping between day and night shifts will burn out even the most motivated employee. > What we found was that we would find people who wanted to be on the night shift, and would NOT like to be changed, at all. Some people like night work, or have family situations where it is ideal for them. Regards Marshall > Mark Green > > > > > > >> From: nanog-request at nanog.org >> Subject: NANOG Digest, Vol 39, Issue 46 >> To: nanog at nanog.org >> Date: Fri, 15 Apr 2011 15:52:19 +0000 >> >> Send NANOG mailing list submissions to >> nanog at nanog.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://mailman.nanog.org/mailman/listinfo/nanog >> or, via email, send a message with subject or body 'help' to >> nanog-request at nanog.org >> >> You can reach the person managing the list at >> nanog-owner at nanog.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of NANOG digest..." >> >> >> Today's Topics: >> >> 1. 365x24x7 (harbor235) >> 2. Re: New hijacks, and lots of them (Ronald F. Guilmette) >> 3. Re: 365x24x7 (Peter Hicks) >> 4. Re: 365x24x7 (Charles Mills) >> 5. RE: 365x24x7 (Greg Moore) >> 6. Re: 365x24x7 (Steve Clark) >> 7. Re: 365x24x7 (Marshall Eubanks) >> 8. Re: 365x24x7 (Alex Brooks) >> 9. RE: 365x24x7 (Sanders, Randall K) >> 10. Re: 365x24x7 (Tony Finch) >> 11. Re: 365x24x7 (harbor235) >> 12. Re: 365x24x7 (Paul Graydon) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 15 Apr 2011 09:14:05 -0400 >> From: harbor235 >> Subject: 365x24x7 >> To: NANOG list >> Message-ID: >> Content-Type: text/plain; charset=ISO-8859-1 >> >> If I were going to provide a 365x24x7 NOC, how many teams of personnel do I >> need >> to fully cover operations? I assume minimally you need 3 teams to cover the >> required >> 24 hr coverage, but there is off time and schedule rotation? >> >> thoughts, experience? >> >> Mike >> >> >> ------------------------------ >> >> Message: 2 >> Date: Fri, 15 Apr 2011 06:17:06 -0700 >> From: "Ronald F. Guilmette" >> Subject: Re: New hijacks, and lots of them >> To: nanog at nanog.org >> Message-ID: <2971.1302873426 at tristatelogic.com> >> >> >> In message <5824.1302780126 at tristatelogic.com>, I wrote: >> >>> http://www.47-usc-230c2.org/20110414-snowshoe-1.txt >>> http://www.47-usc-230c2.org/20110414-snowshoe-2.txt >> >> My apologies to anyone and everyone who tried to get at these files. >> It seems that my provider may perhaps have recently developed some >> rather odd ideas about packet filtering for static broadband lines. >> Until I can get the problem worked out, the following alternative URLs >> ought to do instead: >> >> ftp://ftp.47-usc-230c2.org/pub/20110414-snowshoe-1.txt >> ftp://ftp.47-usc-230c2.org/pub/20110414-snowshoe-2.txt >> >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Fri, 15 Apr 2011 14:17:48 +0100 >> From: Peter Hicks >> Subject: Re: 365x24x7 >> To: harbor235 >> Cc: NANOG list >> Message-ID: <066F653E-C0F8-4026-9FE0-3A8899378D0C at poggs.co.uk> >> Content-Type: text/plain; charset=us-ascii >> >> >> On 15 Apr 2011, at 14:14, harbor235 wrote: >> >>> If I were going to provide a 365x24x7 NOC, how many teams of personnel do I >>> need to fully cover operations? I assume minimally you need 3 teams to cover the >>> required 24 hr coverage, but there is off time and schedule rotation? >> >> >> Although more geared up for on-call, http://blog.hinterlands.org/2010/07/running-an-oncall-rota/ is a very useful resource. >> >> >> Peter >> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Fri, 15 Apr 2011 09:25:02 -0400 >> From: Charles Mills >> Subject: Re: 365x24x7 >> To: harbor235 , NANOG list >> Message-ID: >> Content-Type: text/plain; charset=ISO-8859-1 >> >> I've had it done in places where I work where you'll have 3 rotations >> working 12 hour shifts. >> >> In a 2 week pay period they get their 80 hours in a blend 36 one week >> and 44 the next. It gives some nice consecutive days off time which >> also doubles as a retention tool for some employees. You might have >> to get creative to have all the days work out but it can be done. >> >> On Fri, Apr 15, 2011 at 9:14 AM, harbor235 wrote: >>> If I were going to provide a 365x24x7 NOC, how many teams of personnel do I >>> need >>> to fully cover operations? I assume minimally you need 3 teams to cover the >>> required >>> 24 hr coverage, but there is off time and schedule rotation? >>> >>> thoughts, experience? >>> >>> Mike >>> >> >> >> >> -- >> ===================================== >> Charles L. Mills >> Email: w3yni1 at gmail.com >> ===================================== >> Need server hosting, DR or colocation services?? See me! >> >> >> >> ------------------------------ >> >> Message: 5 >> Date: Fri, 15 Apr 2011 09:37:54 -0400 >> From: Greg Moore >> Subject: RE: 365x24x7 >> To: harbor235 , NANOG list >> Message-ID: >> Content-Type: text/plain; charset="iso-8859-1" >> >> When I did this years ago I found 5 was really a minimum so that I could cover weekends and then had extra coverage as needed during the week. >> >> I did find it was good to swap out the graveyard shift every 6 months or so. >> >> -----Original Message----- >> From: harbor235 >> Sent: Friday, April 15, 2011 9:14 AM >> To: NANOG list >> Subject: 365x24x7 >> >> If I were going to provide a 365x24x7 NOC, how many teams of personnel do I >> need >> to fully cover operations? I assume minimally you need 3 teams to cover the >> required >> 24 hr coverage, but there is off time and schedule rotation? >> >> thoughts, experience? >> >> Mike >> >> >> >> >> ------------------------------ >> >> Message: 6 >> Date: Fri, 15 Apr 2011 09:48:42 -0400 >> From: Steve Clark >> Subject: Re: 365x24x7 >> To: Charles Mills >> Cc: NANOG list >> Message-ID: <4DA84CBA.5030409 at netwolves.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> On 04/15/2011 09:25 AM, Charles Mills wrote: >>> I've had it done in places where I work where you'll have 3 rotations >>> working 12 hour shifts. >>> >>> In a 2 week pay period they get their 80 hours in a blend 36 one week >>> and 44 the next. It gives some nice consecutive days off time which >>> also doubles as a retention tool for some employees. You might have >>> to get creative to have all the days work out but it can be done. >>> >>> On Fri, Apr 15, 2011 at 9:14 AM, harbor235 wrote: >>>> If I were going to provide a 365x24x7 NOC, how many teams of personnel do I >>>> need >>>> to fully cover operations? I assume minimally you need 3 teams to cover the >>>> required >>>> 24 hr coverage, but there is off time and schedule rotation? >>>> >>>> thoughts, experience? >>>> >>>> Mike >>>> >>> >>> >> I worked once in a production plant. They had 4 crews a,b,c,d and worked 6 days on 2 off. It was rotating shifts. As an example crew A worked 6 >> days 8-4 was off 2 days then started the next shift on 4-midnight, then midnight to 8. So at any one day 3 of the 4 crews were working and the other >> crew was off. >> >> -- >> Stephen Clark >> *NetWolves* >> Sr. Software Engineer III >> Phone: 813-579-3200 >> Fax: 813-882-0209 >> Email: steve.clark at netwolves.com >> http://www.netwolves.com >> >> >> ------------------------------ >> >> Message: 7 >> Date: Fri, 15 Apr 2011 09:52:11 -0400 >> From: Marshall Eubanks >> Subject: Re: 365x24x7 >> To: Greg Moore >> Cc: NANOG list >> Message-ID: >> Content-Type: text/plain; charset=us-ascii >> >> >> >> On Apr 15, 2011, at 9:37 AM, Greg Moore wrote: >> >>> When I did this years ago I found 5 was really a minimum so that I could cover weekends and then had extra coverage as needed during the week. >>> >>> I did find it was good to swap out the graveyard shift every 6 months or so. >>> >> >> When I worked with NASA and the Navy on remote locations that needed full time staffing, the rule of thumb was >> 5 people and 4 shifts was the absolute minimum, and the people had to be motivated enough to pull 12 hour shifts on a regular basis (i.e., this >> was very bare bones). The 4th shift was needed during the weekends. >> >> Anything less, and you would have uncovered periods if, say, 2 people got sick simultaneously. >> >> Regards >> Marshall >> >> >>> -----Original Message----- >>> From: harbor235 >>> Sent: Friday, April 15, 2011 9:14 AM >>> To: NANOG list >>> Subject: 365x24x7 >>> >>> If I were going to provide a 365x24x7 NOC, how many teams of personnel do I >>> need >>> to fully cover operations? I assume minimally you need 3 teams to cover the >>> required >>> 24 hr coverage, but there is off time and schedule rotation? >>> >>> thoughts, experience? >>> >>> Mike >>> >>> >>> >> >> >> >> >> ------------------------------ >> >> Message: 8 >> Date: Fri, 15 Apr 2011 15:27:32 +0100 >> From: Alex Brooks >> Subject: Re: 365x24x7 >> To: nanog >> Message-ID: >> Content-Type: text/plain; charset=ISO-8859-1 >> >> On Fri, Apr 15, 2011 at 2:14 PM, harbor235 wrote: >>> If I were going to provide a 365x24x7 NOC, how many teams of personnel do I >>> need >>> to fully cover operations? I assume minimally you need 3 teams to cover the >>> required >>> 24 hr coverage, but there is off time and schedule rotation? >> >> Well, if you feel like being "nice" to your employees, or want to stop >> them from making mistakes a few months/years in to shift work, (or if >> you're having to set something up abroad), the Working Time Directive >> can be a useful guideline. >> >> (Full details at http://en.wikipedia.org/wiki/Working_Time_Directive >> and http://www.businesslink.gov.uk/bdotg/action/layer?topicId=1073858926 >> if you're board, ignore the silly bits) >> >> But basically, in general, workers aged 18 and over are entitled to: >> >> - work no more than six days out of every seven, or 12 out of every 14 >> - take a 20-minute break if their shift lasts for more than six hours >> - work a maximum 48-hour average week >> >> And in general, night workers: >> >> - should not work more than an average of eight hours in a 24-hour >> period, averaged over a reference period of 17 weeks >> >> If you're an employer, be glad you're in North America :-) >> >> HTH, >> >> Alex >> >> >> >> ------------------------------ >> >> Message: 9 >> Date: Fri, 15 Apr 2011 09:31:48 -0500 >> From: "Sanders, Randall K" >> Subject: RE: 365x24x7 >> To: nanog >> Message-ID: >> >> >> Content-Type: text/plain; charset="us-ascii" >> >> Have you taken into account number of alarms per hour, inbound call volume for repairs, and how much repair is done at the first tier level? Bare minimum staffing in a busy environment? >> >> Randy Sanders >> >> -----Original Message----- >> From: Alex Brooks [mailto:askoorb+nanog at gmail.com] >> Sent: Friday, April 15, 2011 9:28 AM >> To: nanog >> Subject: Re: 365x24x7 >> >> On Fri, Apr 15, 2011 at 2:14 PM, harbor235 wrote: >>> If I were going to provide a 365x24x7 NOC, how many teams of personnel do I >>> need >>> to fully cover operations? I assume minimally you need 3 teams to cover the >>> required >>> 24 hr coverage, but there is off time and schedule rotation? >> >> Well, if you feel like being "nice" to your employees, or want to stop >> them from making mistakes a few months/years in to shift work, (or if >> you're having to set something up abroad), the Working Time Directive >> can be a useful guideline. >> >> (Full details at http://en.wikipedia.org/wiki/Working_Time_Directive >> and http://www.businesslink.gov.uk/bdotg/action/layer?topicId=1073858926 >> if you're board, ignore the silly bits) >> >> But basically, in general, workers aged 18 and over are entitled to: >> >> - work no more than six days out of every seven, or 12 out of every 14 >> - take a 20-minute break if their shift lasts for more than six hours >> - work a maximum 48-hour average week >> >> And in general, night workers: >> >> - should not work more than an average of eight hours in a 24-hour >> period, averaged over a reference period of 17 weeks >> >> If you're an employer, be glad you're in North America :-) >> >> HTH, >> >> Alex >> >> >> >> >> >> >> ------------------------------ >> >> Message: 10 >> Date: Fri, 15 Apr 2011 15:36:35 +0100 >> From: Tony Finch >> Subject: Re: 365x24x7 >> To: harbor235 >> Cc: NANOG list >> Message-ID: >> >> Content-Type: TEXT/PLAIN; charset=US-ASCII >> >> harbor235 wrote: >> >>> If I were going to provide a 365x24x7 NOC, how many teams of personnel >>> do I need to fully cover operations? >> >> Hours in the working year = 8 * 5 * 48 = 1920 >> Hours in the calendar year = 24 * 7 * 52 = 8736 >> Ratio = 4.55 >> >> Tony. >> -- >> f.anthony.n.finch http://dotat.at/ >> Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in >> Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5 >> or 6 later. Rough or very rough. Occasional rain. Moderate or good, >> occasionally poor. >> >> >> >> ------------------------------ >> >> Message: 11 >> Date: Fri, 15 Apr 2011 10:52:02 -0400 >> From: harbor235 >> Subject: Re: 365x24x7 >> To: NANOG list >> Message-ID: >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Guys, >> >> Thanx alot, there is some great stuff here, also some stuff I had not >> thought of. >> >> thanx again, >> >> Mike >> >> On Fri, Apr 15, 2011 at 10:36 AM, Tony Finch wrote: >> >>> harbor235 wrote: >>> >>>> If I were going to provide a 365x24x7 NOC, how many teams of personnel >>>> do I need to fully cover operations? >>> >>> Hours in the working year = 8 * 5 * 48 = 1920 >>> Hours in the calendar year = 24 * 7 * 52 = 8736 >>> Ratio = 4.55 >>> >>> Tony. >>> -- >>> f.anthony.n.finch http://dotat.at/ >>> Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in >>> Rockall and Malin, veering west or northwest 4 or 5, then backing southwest >>> 5 >>> or 6 later. Rough or very rough. Occasional rain. Moderate or good, >>> occasionally poor. >>> >> >> >> ------------------------------ >> >> Message: 12 >> Date: Fri, 15 Apr 2011 05:52:13 -1000 >> From: Paul Graydon >> Subject: Re: 365x24x7 >> To: nanog at nanog.org >> Message-ID: <4DA869AD.9070202 at paulgraydon.co.uk> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> On 4/15/2011 3:14 AM, harbor235 wrote: >>> If I were going to provide a 365x24x7 NOC, how many teams of personnel do I >>> need >>> to fully cover operations? I assume minimally you need 3 teams to cover the >>> required >>> 24 hr coverage, but there is off time and schedule rotation? >>> >>> thoughts, experience? >>> >>> Mike >>> >> For what it's worth, was part of a datacenter operations department that >> had a 24x7 team. 4 shifts, 4 staff on each shift (1 was supervisor who >> did same work as the rest, 1 'point of contact' who stayed in the office). >> 4 days on, 4 days off, 12 hour shifts, 8-8. Shift teams would alternate >> between day and night (so 4 day, 4 off, 4 night, 4 off, repeat ad >> infinitum). During the day that was bolstered by 6 day-staff, Monday to >> Friday, who would have a staggered start through the day (IIRC 2 start >> at 8, 2 at 9, 2 at 11) >> >> >> >> ------------------------------ >> >> _______________________________________________ >> NANOG mailing list >> NANOG at nanog.org >> https://mailman.nanog.org/mailman/listinfo/nanog >> >> End of NANOG Digest, Vol 39, Issue 46 >> ************************************* > From smb at cs.columbia.edu Fri Apr 15 12:43:54 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 15 Apr 2011 13:43:54 -0400 Subject: 365x24x7 (sleep patterns) In-Reply-To: References: Message-ID: On Apr 15, 2011, at 1:41 26PM, Marshall Eubanks wrote: > > On Apr 15, 2011, at 12:44 PM, Mark Green wrote: > >> >> Suggestion; once on the 'night shift' stay put for at least three months... Sleep patterns take time to adjust. Jumping between day and night shifts will burn out even the most motivated employee. >> > > What we found was that we would find people who wanted to be on the night shift, and would NOT like to be changed, at all. Some people like night > work, or have family situations where it is ideal for them. > Yah. Read the current news coverage about sleeping U.S. air traffic controllers, especially the articles about how hard it is to switch shifts, and very especially if you do it often. --Steve Bellovin, https://www.cs.columbia.edu/~smb From tme at americafree.tv Fri Apr 15 12:51:29 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 15 Apr 2011 13:51:29 -0400 Subject: 365x24x7 In-Reply-To: References: Message-ID: <41784056-0266-4E36-905C-61C66695DD29@americafree.tv> On Apr 15, 2011, at 12:50 PM, George Herbert wrote: > On Fri, Apr 15, 2011 at 6:52 AM, Marshall Eubanks wrote: >> >> >> On Apr 15, 2011, at 9:37 AM, Greg Moore wrote: >> >>> When I did this years ago I found 5 was really a minimum so that I could cover weekends and then had extra coverage as needed during the week. >>> >>> I did find it was good to swap out the graveyard shift every 6 months or so. >>> >> >> When I worked with NASA and the Navy on remote locations that needed full time staffing, the rule of thumb was >> 5 people and 4 shifts was the absolute minimum, and the people had to be motivated enough to pull 12 hour shifts on a regular basis (i.e., this >> was very bare bones). The 4th shift was needed during the weekends. >> >> Anything less, and you would have uncovered periods if, say, 2 people got sick simultaneously. > > I believe that for ongoing long term operations, NASA and DOD > standards are 6 shifts worth of people, however you juggle the > particular shift lengths / schedules. I.e., NORAD, NASA ISS / Moon > mission mission control, etc. > > You can do it with 5, but people need time to get sick, take > vacations, go to training, etc. It can be done with 5, with some stretch. There are gotcha's, and you need to run for a while to make sure that you have accounted for them. For example, with a barebones 5 person staffing there would never be more than 2 people on site at a time, except briefly during shift changes. If equipment maintenance + normal operation requires 3 people, say 2 manhandling gear and one watching operations, you can't do it in normal operations. At one site I worked with, that got to be bad enough that they hired an extra person specifically to address that hole in the schedule. (That site was remote enough that they couldn't get a temp to come in and fill the gap.) The Apollo program ran their ground stations with 6 shifts, fully staffed on all 6. But, they had lots of money. Regards Marshall > > > -- > -george william herbert > george.herbert at gmail.com > From gbonser at seven.com Fri Apr 15 12:53:45 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 15 Apr 2011 10:53:45 -0700 Subject: 365x24x7 (sleep patterns) In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E2D9D@RWC-EX1.corp.seven.com> > > > > What we found was that we would find people who wanted to be on the > night shift, and would NOT like to be changed, at all. Some people like > night > work, or have family situations where it is ideal for them. > > Regards > Marshall +1 I would start by first taking an audit of skills. Some people are just really good troubleshooters above and beyond average in that respect. You want at least one of those on each shift. Some other people are really great at attention to every little detail in documentation. You want at least one of those, too, on each shift. Sometimes those skills overlap but my experience is that they are rooted in different personality traits and the two complement each other and are only rarely found in the same person. Everyone else will be pretty much average in both respects. Then look at family situations. Married with children will probably not much care for swing shift if their kids are school age as they will never see them except on their days off. Mids are difficult for people with a toddler at home (ever try to sleep with a toddler in the house?) but work well with school-aged kids (parent can sleep while child is at school). Single parents are going to hate mids and swings. Look at individual preferences. Some people are natural night owls, some are natural morning people. Don't try to work against that if you can avoid it. So you might have a swing shift loaded up with single people, mids with people who like working those hours and maybe married with school-aged children. Day shift with single parents and higher level supervisory rolls. But the extent to which you take into account people's natural preferences, natural strengths and weaknesses, and their situation at home can make a huge difference in a harmonious situation on the job. From bonomi at mail.r-bonomi.com Fri Apr 15 13:23:48 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 15 Apr 2011 13:23:48 -0500 (CDT) Subject: 365x24x7 In-Reply-To: Message-ID: <201104151823.p3FINmbQ097624@mail.r-bonomi.com> > Date: Fri, 15 Apr 2011 09:14:05 -0400 > Subject: 365x24x7 > From: harbor235 > To: NANOG list > > If I were going to provide a 365x24x7 NOC, how many teams of personnel do I > need > to fully cover operations? I assume minimally you need 3 teams to cover the > required > 24 hr coverage, but there is off time and schedule rotation? > > thoughts, experience? You haven't done the math right. You're not even *close* to 'real world' requirements. 3 people only provide 24-hour coverage for *five* days/week. *before* considering any the "stuff" mentioned below. 7x24 requires _4-1/5_ persons per position, assuming 40-hr work week, _before_ allowing for vacations, etc.. Scheduled vacation time adds another 5-8% to the manpower requirement. Don't forget "holidays", 'sick days', and 'personal time'. that's another 5-10%, or so. Do you intend to allow any participation in 'professional' activities, conferences, etc. and/or any on-going training? Another 5% easily. Now, don't foreget about 'in-house' "overhead" actitivites. e.g. 'staff meetings'. 3-5% (i.e., 1-2 hours/week) is a not-unreasonable estimate. These things push the total requirment to just over 5 people per position, but 'shift scheduling' is a *bitch*. Lastly, you have to consider meal-breaks and such _during_ the shift. This means 'n+1' people per shift, to ensure 'n' on duty at all times. Take your minimum required NOC positions, add one person (for the n+1 completeness), then multiply by 5 and you've got a realistic estimate of the *minimum* manpower requirement. Note: You'll probably want 'above minimum' staffing on 1st shift (and possibly some on 2nd) to handle 'routine'/'non-essential' activities. From Greg.Whynott at oicr.on.ca Fri Apr 15 13:31:27 2011 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Fri, 15 Apr 2011 14:31:27 -0400 Subject: FTP is 40 years old today. Message-ID: <437CF7DE-5465-41A9-BE6E-5A061FB431E7@oicr.on.ca> Sorry, its not operationally related but probably of interest to a few. I cant' believe its been that long, time flys. RFC 114! http://www.bit-tech.net/news/hardware/2011/04/15/ftp-is-40-years-old/ -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From cscora at apnic.net Fri Apr 15 13:40:28 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 16 Apr 2011 04:40:28 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201104151840.p3FIeSaU001337@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 16 Apr, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 354448 Prefixes after maximum aggregation: 160446 Deaggregation factor: 2.21 Unique aggregates announced to Internet: 175187 Total ASes present in the Internet Routing Table: 37330 Prefixes per ASN: 9.49 Origin-only ASes present in the Internet Routing Table: 31290 Origin ASes announcing only one prefix: 15055 Transit ASes present in the Internet Routing Table: 5039 Transit-only ASes present in the Internet Routing Table: 133 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 36 Max AS path prepend of ASN (36992) 29 Prefixes from unregistered ASNs in the Routing Table: 598 Unregistered ASNs in the Routing Table: 263 Number of 32-bit ASNs allocated by the RIRs: 1295 Number of 32-bit ASNs visible in the Routing Table: 1001 Prefixes from 32-bit ASNs in the Routing Table: 2210 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 154 Number of addresses announced to Internet: 2411560512 Equivalent to 143 /8s, 189 /16s and 126 /24s Percentage of available address space announced: 65.1 Percentage of allocated address space announced: 65.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 90.5 Total number of prefixes smaller than registry allocations: 147006 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 88171 Total APNIC prefixes after maximum aggregation: 29869 APNIC Deaggregation factor: 2.95 Prefixes being announced from the APNIC address blocks: 85167 Unique aggregates announced from the APNIC address blocks: 37065 APNIC Region origin ASes present in the Internet Routing Table: 4407 APNIC Prefixes per ASN: 19.33 APNIC Region origin ASes announcing only one prefix: 1227 APNIC Region transit ASes present in the Internet Routing Table: 699 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 20 Number of APNIC region 32-bit ASNs visible in the Routing Table: 48 Number of APNIC addresses announced to Internet: 609096480 Equivalent to 36 /8s, 78 /16s and 19 /24s Percentage of available APNIC address space announced: 77.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 139725 Total ARIN prefixes after maximum aggregation: 71044 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 112194 Unique aggregates announced from the ARIN address blocks: 45081 ARIN Region origin ASes present in the Internet Routing Table: 14325 ARIN Prefixes per ASN: 7.83 ARIN Region origin ASes announcing only one prefix: 5472 ARIN Region transit ASes present in the Internet Routing Table: 1489 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 11 Number of ARIN addresses announced to Internet: 797865344 Equivalent to 47 /8s, 142 /16s and 117 /24s Percentage of available ARIN address space announced: 63.4 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 83950 Total RIPE prefixes after maximum aggregation: 47756 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 77071 Unique aggregates announced from the RIPE address blocks: 50757 RIPE Region origin ASes present in the Internet Routing Table: 15521 RIPE Prefixes per ASN: 4.97 RIPE Region origin ASes announcing only one prefix: 7794 RIPE Region transit ASes present in the Internet Routing Table: 2431 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 744 Number of RIPE addresses announced to Internet: 466827392 Equivalent to 27 /8s, 211 /16s and 56 /24s Percentage of available RIPE address space announced: 75.2 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 32396 Total LACNIC prefixes after maximum aggregation: 7436 LACNIC Deaggregation factor: 4.36 Prefixes being announced from the LACNIC address blocks: 31349 Unique aggregates announced from the LACNIC address blocks: 16421 LACNIC Region origin ASes present in the Internet Routing Table: 1439 LACNIC Prefixes per ASN: 21.79 LACNIC Region origin ASes announcing only one prefix: 429 LACNIC Region transit ASes present in the Internet Routing Table: 261 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 193 Number of LACNIC addresses announced to Internet: 81899648 Equivalent to 4 /8s, 225 /16s and 176 /24s Percentage of available LACNIC address space announced: 54.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7714 Total AfriNIC prefixes after maximum aggregation: 1829 AfriNIC Deaggregation factor: 4.22 Prefixes being announced from the AfriNIC address blocks: 6082 Unique aggregates announced from the AfriNIC address blocks: 1881 AfriNIC Region origin ASes present in the Internet Routing Table: 448 AfriNIC Prefixes per ASN: 13.58 AfriNIC Region origin ASes announcing only one prefix: 133 AfriNIC Region transit ASes present in the Internet Routing Table: 99 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 31 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 5 Number of AfriNIC addresses announced to Internet: 22753536 Equivalent to 1 /8s, 91 /16s and 49 /24s Percentage of available AfriNIC address space announced: 33.9 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2433 9484 902 Korea Telecom (KIX) 17974 1813 515 29 PT TELEKOMUNIKASI INDONESIA 7545 1543 300 80 TPG Internet Pty Ltd 4755 1445 638 166 TATA Communications formerly 24560 1137 322 203 Bharti Airtel Ltd., Telemedia 4808 1064 2140 293 CNCGROUP IP network: China169 9583 1055 77 496 Sify Limited 9829 1008 870 50 BSNL National Internet Backbo 17488 942 162 98 Hathway IP Over Cable Interne 18101 934 116 139 Reliance Infocom Ltd Internet Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3662 3822 255 bellsouth.net, inc. 4323 2661 1090 396 Time Warner Telecom 1785 1788 681 128 PaeTec Communications, Inc. 18566 1759 349 229 Covad Communications 6478 1623 307 37 AT&T Worldnet Services 20115 1535 1552 639 Charter Communications 19262 1495 4949 298 Verizon Global Networks 7018 1350 6801 878 AT&T WorldNet Services 22773 1298 2865 84 Cox Communications, Inc. 2386 1269 536 912 AT&T Data Communications Serv Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6830 518 1780 320 UPC Distribution Services 34984 505 98 183 BILISIM TELEKOM 29049 467 33 34 AzerSat LLC. 3292 454 1997 391 TDC Tele Danmark 8866 446 134 26 Bulgarian Telecommunication C 20940 436 126 335 Akamai Technologies European 3320 418 7607 364 Deutsche Telekom AG 12479 406 577 6 Uni2 Autonomous System 8551 403 353 46 Bezeq International 8402 401 320 11 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1426 265 157 TVCABLE BOGOTA 28573 1274 972 86 NET Servicos de Comunicao S.A 8151 1252 2686 374 UniNet S.A. de C.V. 7303 924 465 147 Telecom Argentina Stet-France 6503 901 354 72 AVANTEL, S.A. 14420 663 53 91 CORPORACION NACIONAL DE TELEC 22047 568 310 15 VTR PUNTO NET S.A. 3816 516 225 98 Empresa Nacional de Telecomun 11172 487 99 81 Servicios Alestra S.A de C.V 27947 480 53 53 Telconet S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 840 445 11 TEDATA 24863 778 147 39 LINKdotNET AS number 15475 422 90 8 Nile Online 36992 295 287 12 Etisalat MISR 3741 266 985 227 The Internet Solution 6713 235 215 13 Itissalat Al-MAGHRIB 33776 227 13 5 Starcomms Nigeria Limited 24835 222 78 10 RAYA Telecom - Egypt 29571 161 17 11 Ci Telecom Autonomous system 16637 148 441 86 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3662 3822 255 bellsouth.net, inc. 4323 2661 1090 396 Time Warner Telecom 4766 2433 9484 902 Korea Telecom (KIX) 23456 2210 644 1206 32-bit ASN transition 17974 1813 515 29 PT TELEKOMUNIKASI INDONESIA 1785 1788 681 128 PaeTec Communications, Inc. 18566 1759 349 229 Covad Communications 6478 1623 307 37 AT&T Worldnet Services 7545 1543 300 80 TPG Internet Pty Ltd 20115 1535 1552 639 Charter Communications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2661 2265 Time Warner Telecom 17974 1813 1784 PT TELEKOMUNIKASI INDONESIA 1785 1788 1660 PaeTec Communications, Inc. 6478 1623 1586 AT&T Worldnet Services 4766 2433 1531 Korea Telecom (KIX) 18566 1759 1530 Covad Communications 7545 1543 1463 TPG Internet Pty Ltd 4755 1445 1279 TATA Communications formerly 10620 1426 1269 TVCABLE BOGOTA 11492 1262 1247 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 45083 UNALLOCATED 1.45.0.0/16 4808 CNCGROUP IP network: 45083 UNALLOCATED 1.45.92.0/22 4808 CNCGROUP IP network: 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 31.7.168.0/21 48057 Company for interactive techn 31.10.32.0/20 42004 Unlimited Group 31.10.56.0/21 23456 32-bit ASN transition 31.134.48.0/20 48559 Infomex Sp. z o.o. Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:12 /10:26 /11:76 /12:219 /13:452 /14:774 /15:1376 /16:11604 /17:5737 /18:9469 /19:19145 /20:25180 /21:25557 /22:33681 /23:32570 /24:185400 /25:1120 /26:1274 /27:701 /28:40 /29:8 /30:2 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2259 3662 bellsouth.net, inc. 18566 1727 1759 Covad Communications 6478 1577 1623 AT&T Worldnet Services 4323 1356 2661 Time Warner Telecom 10620 1316 1426 TVCABLE BOGOTA 11492 1211 1262 Cable One 23456 1143 2210 32-bit ASN transition 7011 1062 1161 Citizens Utilities 1785 1058 1788 PaeTec Communications, Inc. 22773 842 1298 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:256 2:62 4:14 5:1 8:347 12:2000 13:1 14:436 15:15 16:3 17:8 20:9 23:5 24:1604 27:721 31:220 32:60 33:3 34:2 37:1 38:764 40:101 41:2402 42:1 44:3 46:851 47:4 49:173 50:358 52:13 55:7 56:2 57:27 58:844 59:478 60:387 61:1238 62:1008 63:1920 64:3916 65:2325 66:4350 67:1814 68:1082 69:2956 70:700 71:345 72:1906 73:1 74:2337 75:299 76:337 77:840 78:688 79:460 80:1088 81:828 82:505 83:455 84:646 85:1067 86:564 87:761 88:339 89:1584 90:181 91:3711 92:513 93:1053 94:1257 95:792 96:453 97:250 98:821 99:35 101:62 103:1 106:1 107:4 108:80 109:954 110:543 111:694 112:325 113:389 114:524 115:681 116:940 117:675 118:805 119:1137 120:290 121:675 122:1631 123:1062 124:1247 125:1266 128:265 129:164 130:172 131:562 132:113 133:20 134:217 135:49 136:213 137:142 138:301 139:103 140:487 141:174 142:398 143:394 144:484 145:53 146:440 147:204 148:597 149:243 150:171 151:187 152:307 153:180 154:3 155:394 156:190 157:354 158:132 159:382 160:315 161:245 162:277 163:164 164:488 165:350 166:514 167:419 168:725 169:154 170:780 171:75 172:1 173:1492 174:530 175:356 177:71 178:852 180:815 181:7 182:419 183:196 184:243 185:1 186:1139 187:807 188:988 189:1001 190:4841 192:5784 193:4816 194:3468 195:2966 196:1208 197:16 198:3568 199:3919 200:5531 201:1500 202:8347 203:8452 204:4140 205:2323 206:2730 207:3027 208:3951 209:3501 210:2728 211:1361 212:1977 213:1719 214:732 215:67 216:4863 217:1659 218:556 219:385 220:1195 221:479 222:341 223:137 End of report From dhc2 at dcrocker.net Fri Apr 15 15:28:20 2011 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Fri, 15 Apr 2011 13:28:20 -0700 Subject: 365x24x7 In-Reply-To: References: Message-ID: <4DA8AA64.2060403@dcrocker.net> On 4/15/2011 6:14 AM, harbor235 wrote: > If I were going to provide a 365x24x7 NOC, how many teams of personnel do I > need to fully cover operations? I assume minimally you need 3 teams to cover > the required 24 hr coverage, but there is off time and schedule rotation? What is the work distribution? Do you have stable patterns of more-vs-less activity? If things are busy daytime and quiet nighttime, obviously you need different-sized teams. Variable scheduling of staff is often deemed more fair, but I think it makes things less stable. People are constantly having to change their life. A simple model has 3 teams over weekdays/nights, leaving you with weekends, holidays and vacations. I was a part-time operator during college. Full-timer shifts were 3 people; maybe 2 for graveyard. There were 3-5 of us covering things for that added time. But, then, the major operations were purely daytime, during the week. Graveyard shift was quiet enough that we surreptitiously bought a cot... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jeffshultz at wvi.com Fri Apr 15 15:38:53 2011 From: jeffshultz at wvi.com (Jeff Shultz) Date: Fri, 15 Apr 2011 13:38:53 -0700 Subject: 365x24x7 (sleep patterns) In-Reply-To: <20110415171145.GA57757@mikea.ath.cx> References: <20110415171145.GA57757@mikea.ath.cx> Message-ID: <4DA8ACDD.6050706@wvi.com> On 4/15/2011 10:11 AM, mikea wrote: > My experience: > > 6 on, 2 off, 8 hours, rotating to the next later shift: I never, ever got > enough sleep -- for 2 years. > > 6 on, 2 off, 12 hours, straight mids, no rotation: much less bad. > > 5 on, 2 off, 8 hours, straight mids: quite tolerable. > > 5 on, 2 off, 8 hours, straight swings (1600-0000): out of phase with the > world. > I've done all of the above but the 12 hour shift and can add 5 on, 2 off, 8 hours, rotating between swings and mids. They sucked. I'm in general agreement with Mike's judgments as well. If you want to be fair to your people and help keep their morale up, straight shifts is the way to go - or at least fix the mids shift and make the swing/mids switch at 2200 (10pm). Changing sleep times is the quickest way to get zombies for employees. If you try to do a 6 and 2 style rotation, eventually some smart person is going to figure out that they're getting screwed out of a lot of weekend and holiday time as opposed to the "daybeggers." My recommendation, based on 10 years of this nonsense in the Army, is minimum 2 people per shift, 5 on, 2 off, stagger the weekends so that someone gets Fri-Sat, the other Sun-Mon. If they can decide which wants which weekend between themselves, so much the better. As the FAA has lately demonstrated, single person night shifts is generally a bad thing if you actually want them to stay awake. -- Jeff Shultz From gbonser at seven.com Fri Apr 15 16:08:26 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 15 Apr 2011 14:08:26 -0700 Subject: 365x24x7 (sleep patterns) In-Reply-To: <4DA8ACDD.6050706@wvi.com> References: <20110415171145.GA57757@mikea.ath.cx> <4DA8ACDD.6050706@wvi.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E2DAA@RWC-EX1.corp.seven.com> > > As the FAA has lately demonstrated, single person night shifts is > generally a bad thing if you actually want them to stay awake. > > -- > Jeff Shultz > Jeff, there are other reasons for not having a single individual on an overnight shift. A person can have an unexpected medical emergency at any time or experience an accident. Getting help to them quickly can make a difference between life and death. Even choking on a meal can have a completely different outcome if there is another person available. Having only one person in a facility overnight by themselves just isn't a good idea, in my opinion. From blakjak at blakjak.net Fri Apr 15 16:47:02 2011 From: blakjak at blakjak.net (Mark Foster) Date: Sat, 16 Apr 2011 09:47:02 +1200 (NZST) Subject: 365x24x7 (sleep patterns) In-Reply-To: <4DA8ACDD.6050706@wvi.com> References: <20110415171145.GA57757@mikea.ath.cx> <4DA8ACDD.6050706@wvi.com> Message-ID: On Fri, 15 Apr 2011, Jeff Shultz wrote: > On 4/15/2011 10:11 AM, mikea wrote: > >> My experience: >> >> 6 on, 2 off, 8 hours, rotating to the next later shift: I never, ever got >> enough sleep -- for 2 years. >> >> 6 on, 2 off, 12 hours, straight mids, no rotation: much less bad. >> >> 5 on, 2 off, 8 hours, straight mids: quite tolerable. >> >> 5 on, 2 off, 8 hours, straight swings (1600-0000): out of phase with the >> world. >> > > I've done all of the above but the 12 hour shift and can add 5 on, 2 off, 8 > hours, rotating between swings and mids. They sucked. I'm in general > agreement with Mike's judgments as well. > > If you want to be fair to your people and help keep their morale up, straight > shifts is the way to go - or at least fix the mids shift and make the > swing/mids switch at 2200 (10pm). Changing sleep times is the quickest way to > get zombies for employees. > Local emergency services[1] operate '2 days, 2 nights, 4 off'. Dayshifts are 10 hour 8am-6pm. Nightshift is 6pm until 8am. This creates a 4-watch rotation. The day shifts are relatively normal working hours, and the 4 consecutive days off are handy, and as it's an 8 day cycle it slowly rotates so that you can wind up with weekends or weekdays off over time (which in itself can be handy). The guys employed this way are often given a little handbook with their year printed on it so they can plan their lives. Mark. [1] Fire and Ambulance services operate this way to my knowledge, Police is different depending on the part of the country you're in... From cidr-report at potaroo.net Fri Apr 15 17:00:02 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 Apr 2011 22:00:02 GMT Subject: BGP Update Report Message-ID: <201104152200.p3FM02iu080100@wattle.apnic.net> BGP Update Report Interval: 07-Apr-11 -to- 14-Apr-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS17224 36610 2.5% 1926.8 -- ATT-CERFNET-BLOCK - AT&T Enhanced Network Services 2 - AS19743 30570 2.1% 5095.0 -- 3 - AS9829 23902 1.7% 44.3 -- BSNL-NIB National Internet Backbone 4 - AS11492 20804 1.4% 20.9 -- CABLEONE - CABLE ONE, INC. 5 - AS32528 17914 1.2% 2559.1 -- ABBOTT Abbot Labs 6 - AS14420 16549 1.1% 25.0 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 7 - AS44609 13135 0.9% 6567.5 -- FNA Fars News Agency Cultural Arts Institute 8 - AS35931 12061 0.8% 4020.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 9 - AS8151 11476 0.8% 13.3 -- Uninet S.A. de C.V. 10 - AS45595 11180 0.8% 58.8 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 11 - AS14522 11041 0.8% 29.2 -- Satnet 12 - AS9498 10942 0.8% 21.2 -- BBIL-AP BHARTI Airtel Ltd. 13 - AS17974 10628 0.7% 9.8 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 14 - AS7491 10241 0.7% 99.4 -- PI-PH-AS-AP PI-PHILIPINES 15 - AS28573 9729 0.7% 6.9 -- NET Servicos de Comunicao S.A. 16 - AS24757 9149 0.6% 247.3 -- EthioNet-AS 17 - AS27738 8229 0.6% 24.3 -- Ecuadortelecom S.A. 18 - AS9737 7751 0.5% 55.8 -- TOTNET-TH-AS-AP TOT Public Company Limited 19 - AS17488 7617 0.5% 17.9 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 20 - AS27747 6930 0.5% 28.2 -- Telecentro S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS44609 13135 0.9% 6567.5 -- FNA Fars News Agency Cultural Arts Institute 2 - AS19743 30570 2.1% 5095.0 -- 3 - AS35931 12061 0.8% 4020.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - AS11915 3664 0.3% 3664.0 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 5 - AS17408 3409 0.2% 3409.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 6 - AS32528 17914 1.2% 2559.1 -- ABBOTT Abbot Labs 7 - AS17225 2277 0.2% 2277.0 -- ATT-CERFNET-BLOCK - AT&T Enhanced Network Services 8 - AS17224 36610 2.5% 1926.8 -- ATT-CERFNET-BLOCK - AT&T Enhanced Network Services 9 - AS22206 1616 0.1% 1616.0 -- GOOD-SAM - Evangelical Lutheran Good Samaritan Society 10 - AS49600 1523 0.1% 1523.0 -- LASEDA La Seda de Barcelona, S.A 11 - AS13168 1438 0.1% 1438.0 -- SANOSTRA-AS AS de la Caja de ahorros y monte de piedad de las Baleares 12 - AS45310 686 0.1% 686.0 -- PISHON-SMARTNET-AS-ID SMARTNET - Broadband Internet Service. 13 - AS36907 1263 0.1% 631.5 -- TVCABO_ASN 14 - AS45828 541 0.0% 541.0 -- DIVERSIT-AU-AS-AP DiversIT AS 15 - AS9476 522 0.0% 522.0 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd. 16 - AS10445 2310 0.2% 462.0 -- HTG - Huntleigh Telcom 17 - AS3 384 0.0% 735.0 -- ARKTIKA-AS Trade and logistics facility ARKTIKA Ltd 18 - AS55477 357 0.0% 357.0 -- ADMU-AS-PH Loyola Heights 19 - AS49392 342 0.0% 342.0 -- AM-BRIDGENET-AS Bridgenet JVC Autonomous System Yerevan, Armenia 20 - AS48068 335 0.0% 335.0 -- VISONIC Visonic Ltd TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 130.36.34.0/24 8952 0.6% AS32528 -- ABBOTT Abbot Labs 2 - 130.36.35.0/24 8948 0.6% AS32528 -- ABBOTT Abbot Labs 3 - 221.121.96.0/19 8051 0.5% AS7491 -- PI-PH-AS-AP PI-PHILIPINES 4 - 202.92.235.0/24 7964 0.5% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 5 - 63.211.68.0/22 7035 0.5% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - 178.22.79.0/24 6588 0.4% AS44609 -- FNA Fars News Agency Cultural Arts Institute 7 - 178.22.72.0/21 6547 0.4% AS44609 -- FNA Fars News Agency Cultural Arts Institute 8 - 65.122.196.0/24 5974 0.4% AS19743 -- 9 - 72.164.144.0/24 4945 0.3% AS19743 -- 10 - 66.238.91.0/24 4913 0.3% AS19743 -- 11 - 65.162.204.0/24 4913 0.3% AS19743 -- 12 - 66.89.98.0/24 4913 0.3% AS19743 -- 13 - 65.163.182.0/24 4912 0.3% AS19743 -- 14 - 198.140.43.0/24 4728 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 15 - 68.65.152.0/22 3664 0.2% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 16 - 206.184.16.0/24 3455 0.2% AS174 -- COGENT Cogent/PSI 17 - 202.153.174.0/24 3409 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 18 - 213.55.75.0/24 2901 0.2% AS24757 -- EthioNet-AS 19 - 213.55.74.0/24 2899 0.2% AS24757 -- EthioNet-AS 20 - 213.55.64.0/24 2614 0.2% AS24757 -- EthioNet-AS Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Apr 15 17:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 Apr 2011 22:00:01 GMT Subject: The Cidr Report Message-ID: <201104152200.p3FM01bA080094@wattle.apnic.net> This report has been generated at Fri Apr 15 21:12:09 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 08-04-11 355531 209305 09-04-11 355950 209193 10-04-11 355565 209367 11-04-11 355807 209745 12-04-11 356163 209730 13-04-11 355878 210150 14-04-11 356506 210802 15-04-11 357492 209955 AS Summary 37433 Number of ASes in routing system 15770 Number of ASes announcing only one prefix 3662 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 110564352 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 15Apr11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 357652 209929 147723 41.3% All ASes AS6389 3662 260 3402 92.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2652 400 2252 84.9% TWTC - tw telecom holdings, inc. AS4766 2433 914 1519 62.4% KIXS-AS-KR Korea Telecom AS6478 1623 205 1418 87.4% ATT-INTERNET3 - AT&T Services, Inc. AS10620 1426 181 1245 87.3% Telmex Colombia S.A. AS22773 1298 93 1205 92.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS19262 1495 298 1197 80.1% VZGNI-TRANSIT - Verizon Online LLC AS18566 1759 662 1097 62.4% COVAD - Covad Communications Co. AS4755 1446 369 1077 74.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1791 764 1027 57.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1279 332 947 74.0% NET Servicos de Comunicao S.A. AS7545 1546 760 786 50.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 935 152 783 83.7% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1068 325 743 69.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS8151 1231 507 724 58.8% Uninet S.A. de C.V. AS3356 1151 481 670 58.2% LEVEL3 Level 3 Communications AS7303 928 263 665 71.7% Telecom Argentina S.A. AS11492 1263 609 654 51.8% CABLEONE - CABLE ONE, INC. AS17488 942 300 642 68.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS6503 902 280 622 69.0% Axtel, S.A.B. de C.V. AS17676 656 70 586 89.3% GIGAINFRA Softbank BB Corp. AS24560 1137 561 576 50.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS855 631 56 575 91.1% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS14420 663 104 559 84.3% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS7552 673 124 549 81.6% VIETEL-AS-AP Vietel Corporation AS3549 942 394 548 58.2% GBLX Global Crossing Ltd. AS22047 568 30 538 94.7% VTR BANDA ANCHA S.A. AS22561 864 338 526 60.9% DIGITAL-TELEPORT - Digital Teleport Inc. AS4780 718 215 503 70.1% SEEDNET Digital United Inc. AS17974 1812 1314 498 27.5% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia Total 39494 11361 28133 71.2% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 24.48.0.0/14 AS5769 VIDEOTRON - Videotron Telecom Ltee 24.225.128.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/23 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.224.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.237.0/24 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.248.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 41.57.192.0/18 AS22750 BCSNET 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 45.127.0.0/16 AS13767 DBANK - DataBank Holdings, Ltd. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS16626 GNAXNET-AS - Global Net Access, LLC 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 148.163.0.0/20 AS3356 LEVEL3 Level 3 Communications 148.163.64.0/20 AS3356 LEVEL3 Level 3 Communications 148.163.224.0/19 AS3356 LEVEL3 Level 3 Communications 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 181.82.15.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.16.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.17.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 181.82.18.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.145.251.0/24 AS10026 PACNET Pacnet Global Ltd 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.33.84.0/22 AS9911 CONNECTPLUS-AP Singapore Telecom 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.73.0/24 AS26061 Equant Colombia 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 203.190.32.0/22 AS24564 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.64.240.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.241.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.242.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.243.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.244.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.247.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.105.192.0/23 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.105.196.0/23 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.105.200.0/21 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From kleanchap at tanucoo.com Sat Apr 16 02:39:39 2011 From: kleanchap at tanucoo.com (Subba Rao) Date: Sat, 16 Apr 2011 09:39:39 +0200 Subject: Configuration Compliance tools?? Message-ID: <4DA947BB.6070604@tanucoo.com> Hi, I am tasked to analyze the configuration of several Layer 2 Switches for compliance. Most of these switches are from Foundry (now Brocade). What tools are available to perform this task? I could write up a Perl script to parse thru the configuration files. I was wondering if there are some already out there for use. Any information appreciated. Thank you in advance. Subba Rao From dennis at justipit.com Sat Apr 16 09:05:04 2011 From: dennis at justipit.com (Dennis Usle) Date: Sat, 16 Apr 2011 10:05:04 -0400 Subject: Configuration Compliance tools?? Message-ID: <9286CA235869442883EC4ADBE55F9731@eip.local> Try nipper configuration assessment tool. It provides some very detailed output for many devices though is lacking Juniper support right now. Hopefully Nipper 2 will support JunOS. I haven't used it for Foundry/Brocade yet but they are on the supported device list. http://www.titania.co.uk/index.php?option=com_content&view=article&id=52&Itemid=58 Regards, Dennis Usle -----Original Message----- From: Subba Rao Sent: Saturday, April 16, 2011 3:39 AM To: nanog at nanog.org Subject: Configuration Compliance tools?? Hi, I am tasked to analyze the configuration of several Layer 2 Switches for compliance. Most of these switches are from Foundry (now Brocade). What tools are available to perform this task? I could write up a Perl script to parse thru the configuration files. I was wondering if there are some already out there for use. Any information appreciated. Thank you in advance. Subba Rao From ml at kenweb.org Sat Apr 16 09:51:52 2011 From: ml at kenweb.org (ML) Date: Sat, 16 Apr 2011 10:51:52 -0400 Subject: Configuration Compliance tools?? In-Reply-To: <4DA947BB.6070604@tanucoo.com> References: <4DA947BB.6070604@tanucoo.com> Message-ID: <4DA9AD08.10108@kenweb.org> On 4/16/2011 3:39 AM, Subba Rao wrote: > Hi, > > I am tasked to analyze the configuration of several Layer 2 Switches for > compliance. Most of these switches are from Foundry (now Brocade). > What tools are available to perform this task? I could write up a Perl > script to parse thru the configuration files. I was wondering if there > are some already out there for use. > > Any information appreciated. > > Thank you in advance. > > Subba Rao > If you can grab the configs with RANCID you can make a few scripts to parse your configs. From scott at doc.net.au Sat Apr 16 16:09:46 2011 From: scott at doc.net.au (Scott Howard) Date: Sat, 16 Apr 2011 14:09:46 -0700 Subject: [v6z] Re: Yahoo! Mail Issue In-Reply-To: <4DA419D0.8050708@stluke.com.ph> References: <4DA3D4D1.3020002@stluke.com.ph> <4DA3DAE9.9020708@2mbit.com> <4DA3E32F.6050907@stluke.com.ph> <1302591896.2158.94.camel@chris-laptop> <4DA3FB5D.5040505@stluke.com.ph> <4DA419D0.8050708@stluke.com.ph> Message-ID: On Tue, Apr 12, 2011 at 2:22 AM, Nathanael C. Cariaga < nccariaga at stluke.com.ph> wrote: > ps. I'm just wondering why yahoo doesn't inform their users that the email > that they sent was blocked because of their servers were listed in a > blocklist (inspite that the server is able to return a correct reject code > 550) Because 550 is NOT a valid response code at that stage in the conversation. According to the RFC, the only two valid responses to an initial connection are a 220 or a 554. Even then, RFC 2821 doesn't make it clear if a 554 on initial connection should be considered a fatal error at the message level, and as a result most mail servers will consider it a temporary failure and will re-try to send the message multiple times even after getting a 554 (and especially after getting an invalid 550). As someone else has already pointed out, the solution is to return the 5xx response after the rcpt to, not at the initial connection. On 4/12/2011 3:33 PM, Matthew Petach wrote: > >> -bash-3.2$ telnet qc.stluke.com.ph 25 >> Trying 219.90.94.56... >> Connected to qc.stluke.com.ph. >> Escape character is '^]'. >> 550 Blacklisted: Blocked - seehttp:// >> www.spamcop.net/bl.shtml?115.178.12.223 >> >> Connection closed by foreign host. >> > Closing the connection immediately after sending the 5xx is also not RFC compliant. You "MUST" give the client the opportunity to close down the connection with a quit command. Scott From tvhawaii at shaka.com Sat Apr 16 18:24:53 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Sat, 16 Apr 2011 13:24:53 -1000 Subject: Easily confused... Message-ID: <325E2CC5233D44F284AA51726E6261EE@DELL16> Was trying to determine where this 'honolulu' speedtest was hosted: Tracing route to honolulu.speedtest.net [74.209.160.12] over a maximum of 30 hops: 1 22 ms * * 123.87.93.224 2 27 ms 29 ms 25 ms hawaiian-telcom-inc.gigabitethernet2-17.core1.lax2.he.net [184.105.134.170] 3 84 ms 90 ms 84 ms gige-g2-17.core1.lax2.he.net [184.105.134.169] 4 92 ms 98 ms 99 ms 10gigabitethernet7-3.core1.sjc2.he.net [184.105.213.5] 5 112 ms 114 ms 112 ms 10gigabitethernet4-3.core1.sea1.he.net [72.52.92.158] 6 113 ms 113 ms 114 ms six.netriver.net [206.81.80.160] 7 113 ms 113 ms 113 ms static-74-209-160-12.lynnwood.netriver.net [74.209.160.12] Trace complete. 123.87.93.224? inetnum: 123.64.0.0 - 123.95.255.255 netname: CTTNET country: CN descr: China TieTong Telecommunications Corporation From mksmith at adhost.com Sat Apr 16 18:43:07 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Sat, 16 Apr 2011 23:43:07 +0000 Subject: Easily confused... In-Reply-To: <325E2CC5233D44F284AA51726E6261EE@DELL16> Message-ID: On 4/16/11 4:24 PM, "Michael Painter" wrote: >Was trying to determine where this 'honolulu' speedtest was hosted: > >Tracing route to honolulu.speedtest.net [74.209.160.12] >over a maximum of 30 hops: > 1 22 ms * * 123.87.93.224 > 2 27 ms 29 ms 25 ms >hawaiian-telcom-inc.gigabitethernet2-17.core1.lax2.he.net >[184.105.134.170] > 3 84 ms 90 ms 84 ms gige-g2-17.core1.lax2.he.net >[184.105.134.169] > 4 92 ms 98 ms 99 ms 10gigabitethernet7-3.core1.sjc2.he.net >[184.105.213.5] > 5 112 ms 114 ms 112 ms 10gigabitethernet4-3.core1.sea1.he.net >[72.52.92.158] > 6 113 ms 113 ms 114 ms six.netriver.net [206.81.80.160] > 7 113 ms 113 ms 113 ms >static-74-209-160-12.lynnwood.netriver.net [74.209.160.12] >Trace complete. > >123.87.93.224? > >inetnum: 123.64.0.0 - 123.95.255.255 >netname: CTTNET >country: CN >descr: China TieTong Telecommunications Corporation > Well, the DNS name is for a colocation facility in Lynnwood, WA via the Seattle Internet Exchange. I can confirm that the 6th hop actually does traverse the SIX, in as much as that IP is correct. Regards, Mike > From tvhawaii at shaka.com Sat Apr 16 19:03:29 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Sat, 16 Apr 2011 14:03:29 -1000 Subject: Easily confused... References: Message-ID: <286CCF3D546D4C6C9A25A16F7474B7C7@DELL16> Michael K. Smith - Adhost wrote: > On 4/16/11 4:24 PM, "Michael Painter" wrote: > >> Was trying to determine where this 'honolulu' speedtest was hosted: >> >> Tracing route to honolulu.speedtest.net [74.209.160.12] >> over a maximum of 30 hops: >> 1 22 ms * * 123.87.93.224 >> 2 27 ms 29 ms 25 ms >> hawaiian-telcom-inc.gigabitethernet2-17.core1.lax2.he.net >> [184.105.134.170] >> 3 84 ms 90 ms 84 ms gige-g2-17.core1.lax2.he.net >> [184.105.134.169] >> 4 92 ms 98 ms 99 ms 10gigabitethernet7-3.core1.sjc2.he.net >> [184.105.213.5] >> 5 112 ms 114 ms 112 ms 10gigabitethernet4-3.core1.sea1.he.net >> [72.52.92.158] >> 6 113 ms 113 ms 114 ms six.netriver.net [206.81.80.160] >> 7 113 ms 113 ms 113 ms >> static-74-209-160-12.lynnwood.netriver.net [74.209.160.12] >> Trace complete. >> >> 123.87.93.224? >> >> inetnum: 123.64.0.0 - 123.95.255.255 >> netname: CTTNET >> country: CN >> descr: China TieTong Telecommunications Corporation >> > Well, the DNS name is for a colocation facility in Lynnwood, WA via the > Seattle Internet Exchange. I can confirm that the 6th hop actually does > traverse the SIX, in as much as that IP is correct. > > Regards, > > Mike Thanks. What concerned me was the first hop...22ms. is ~ the distance from Maui to Oahu, but why the Chinese IP? Cruel joke? I"m using Hawaiian Telcom's ADSL service and that first hop has always been their gateway IP address. Another TCP trace shows the first hop as 123.74.62.128...another CN address. From bruns at 2mbit.com Sat Apr 16 19:08:07 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Sat, 16 Apr 2011 18:08:07 -0600 Subject: Easily confused... In-Reply-To: <286CCF3D546D4C6C9A25A16F7474B7C7@DELL16> References: <286CCF3D546D4C6C9A25A16F7474B7C7@DELL16> Message-ID: <4DAA2F67.4070207@2mbit.com> On 4/16/11 6:03 PM, Michael Painter wrote: > > > Thanks. What concerned me was the first hop...22ms. is ~ the distance > from Maui to Oahu, but why the Chinese IP? Cruel joke? > I"m using Hawaiian Telcom's ADSL service and that first hop has always > been their gateway IP address. > Another TCP trace shows the first hop as 123.74.62.128...another CN > address. I'm assuming your provider's network engineers (stupidly) assumed 123.x.x.x was a good idea for use in a private setup because it hadn't been assigned from the global pool (yet). Wouldn't be the first provider or service to not use proper RFC assigned private IP space for their internal networking setup. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From tvhawaii at shaka.com Sat Apr 16 19:26:40 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Sat, 16 Apr 2011 14:26:40 -1000 Subject: Easily confused... References: <286CCF3D546D4C6C9A25A16F7474B7C7@DELL16> <4DAA2F67.4070207@2mbit.com> Message-ID: Brielle Bruns wrote: > On 4/16/11 6:03 PM, Michael Painter wrote: >> >> >> Thanks. What concerned me was the first hop...22ms. is ~ the distance >> from Maui to Oahu, but why the Chinese IP? Cruel joke? >> I"m using Hawaiian Telcom's ADSL service and that first hop has always >> been their gateway IP address. >> Another TCP trace shows the first hop as 123.74.62.128...another CN >> address. > > > I'm assuming your provider's network engineers (stupidly) assumed > 123.x.x.x was a good idea for use in a private setup because it hadn't > been assigned from the global pool (yet). > > Wouldn't be the first provider or service to not use proper RFC assigned > private IP space for their internal networking setup. Well, in the 7-8 years I've been with them, they've never used Private IP space. IPConfig shows: Connection-specific DNS Suffix . : hawaiiantel.net Description . . . . . . . . . . . : CNet PRO200WL PCI Fast Ethernet Adapter Physical Address. . . . . . . . . : 00-08-A1-01-0E-29 Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 72.234.20x.x Subnet Mask . . . . . . . . . . . : 255.255.254.0 Default Gateway . . . . . . . . . : 72.234.206.1 DHCP Server . . . . . . . . . . . : 72.235.80.4 DNS Servers . . . . . . . . . . . : 72.235.80.12 72.235.80.4 From tvhawaii at shaka.com Sat Apr 16 20:06:20 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Sat, 16 Apr 2011 15:06:20 -1000 Subject: Easily confused... References: <286CCF3D546D4C6C9A25A16F7474B7C7@DELL16> <4DAA2F67.4070207@2mbit.com> Message-ID: Brielle Bruns wrote: > On 4/16/11 6:03 PM, Michael Painter wrote: >> >> >> Thanks. What concerned me was the first hop...22ms. is ~ the distance >> from Maui to Oahu, but why the Chinese IP? Cruel joke? >> I"m using Hawaiian Telcom's ADSL service and that first hop has always >> been their gateway IP address. >> Another TCP trace shows the first hop as 123.74.62.128...another CN >> address. > > > I'm assuming your provider's network engineers (stupidly) assumed > 123.x.x.x was a good idea for use in a private setup because it hadn't > been assigned from the global pool (yet). > > Wouldn't be the first provider or service to not use proper RFC assigned > private IP space for their internal networking setup. Apologies...missed operative word 'internal'. They are testing IPTV on Oahu in preperation for roll-out, so maybe they renumbered in order to more easily identify the segments.(?) From joelja at bogus.com Sat Apr 16 20:16:37 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 16 Apr 2011 18:16:37 -0700 Subject: Easily confused... In-Reply-To: References: <286CCF3D546D4C6C9A25A16F7474B7C7@DELL16> <4DAA2F67.4070207@2mbit.com> Message-ID: <4DAA3F75.7040903@bogus.com> On 4/16/11 6:06 PM, Michael Painter wrote: > They are testing IPTV on Oahu in preperation for roll-out, so maybe they > renumbered in order to more easily identify the segments.(?) by squating on address space that is or will be in use. joel From nanog at jima.tk Sat Apr 16 20:18:50 2011 From: nanog at jima.tk (Jima) Date: Sat, 16 Apr 2011 20:18:50 -0500 Subject: Easily confused... In-Reply-To: References: <286CCF3D546D4C6C9A25A16F7474B7C7@DELL16> <4DAA2F67.4070207@2mbit.com> Message-ID: <4DAA3FFA.3000608@jima.tk> On 2011-04-16 20:06, Michael Painter wrote: > Brielle Bruns wrote: >> I'm assuming your provider's network engineers (stupidly) assumed >> 123.x.x.x was a good idea for use in a private setup because it hadn't >> been assigned from the global pool (yet). >> >> Wouldn't be the first provider or service to not use proper RFC assigned >> private IP space for their internal networking setup. > > Apologies...missed operative word 'internal'. I was about to reply pointing that out. FWIW, they're not announcing that space, so I definitely agree with the poorly-thought-out private infrastructure theory. http://bgp.he.net/AS36149#_prefixes FWIW. > They are testing IPTV on Oahu in preperation for roll-out, so maybe they > renumbered in order to more easily identify the segments.(?) Really, I'd have hoped they'd use their two-year-old 2607:f9a0::/32 for anything that ambitious...but I might be wishing for too much. (Also, that 123 block seems to have been allocated in 2006, so it'd be even more unprofessional to start projects with that space since then.) Jima From jlewis at lewis.org Sat Apr 16 21:04:22 2011 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 16 Apr 2011 22:04:22 -0400 (EDT) Subject: Easily confused... In-Reply-To: <4DAA3FFA.3000608@jima.tk> References: <286CCF3D546D4C6C9A25A16F7474B7C7@DELL16> <4DAA2F67.4070207@2mbit.com> <4DAA3FFA.3000608@jima.tk> Message-ID: On Sat, 16 Apr 2011, Jima wrote: > I was about to reply pointing that out. FWIW, they're not announcing that > space, so I definitely agree with the poorly-thought-out private > infrastructure theory. http://bgp.he.net/AS36149#_prefixes FWIW. Poorly thought out private IP space? Nah...it's part of their security measures. It keeps those pesky Chinese from communicating with their network. Bots, bulletproof spammer hosting, who needs to talk to that? :) ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From nonobvious at gmail.com Sun Apr 17 02:29:19 2011 From: nonobvious at gmail.com (Bill Stewart) Date: Sun, 17 Apr 2011 00:29:19 -0700 Subject: 365x24x7 In-Reply-To: <4DA8AA64.2060403@dcrocker.net> References: <4DA8AA64.2060403@dcrocker.net> Message-ID: > Variable scheduling of staff is often deemed more fair, but I think it makes > things less stable. ?People are constantly having to change their life. Rotating shifts between daytime and nighttime is a horrible thing to do to your workers, both for their health and their attention span. Full-time night work isn't great, but rotating work is even worse. Apes are generally diurnal, not nocturnal or crepuscular. Shuffling who has to work which days is annoying enough. ---- ? ? ? ? ? ?? Thanks;? ?? Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From ghira at mistral.co.uk Sun Apr 17 04:09:48 2011 From: ghira at mistral.co.uk (Adam Atkinson) Date: Sun, 17 Apr 2011 10:09:48 +0100 Subject: 365x24x7 In-Reply-To: References: <4DA8AA64.2060403@dcrocker.net> Message-ID: <4DAAAE5C.4040503@mistral.co.uk> Bill Stewart wrote: > Rotating shifts between daytime and nighttime is a horrible thing to > do to your workers, both for their health and their attention span. > Full-time night work isn't great, but rotating work is even worse. > Apes are generally diurnal, not nocturnal or crepuscular. Shuffling > who has to work which days is annoying enough. I spent several months working in a place with rotating shifts. One week 10pm to 7am, then the next week 2pm to 10pm then the week after 7am to 2pm and then repeat. I never understood why they were different lengths either. It was pretty grim and I'd much prefer to have had shifts change ever few months. Some people claimed they'd have preferred it if we'd changed to the _following_ shift rater than the preceding shift each week but never having tried that I don't know how it would be. From linkconnect at googlemail.com Sun Apr 17 06:34:25 2011 From: linkconnect at googlemail.com (Wayne Lee) Date: Sun, 17 Apr 2011 12:34:25 +0100 Subject: 365x24x7 In-Reply-To: <4DAAAE5C.4040503@mistral.co.uk> References: <4DA8AA64.2060403@dcrocker.net> <4DAAAE5C.4040503@mistral.co.uk> Message-ID: > Rotating shifts between daytime and nighttime is a horrible thing to > do to your workers, both for their health and their attention span. One of the places I worked had the following pattern. It was horrible 2 days/shifts of 6am till 6pm 2 days/shifts of 6pm till 6am 4 days off Wayne From Skeeve at eintellego.net Sun Apr 17 07:33:32 2011 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Sun, 17 Apr 2011 12:33:32 +0000 Subject: 365x24x7 In-Reply-To: Message-ID: I was offered a similar role? but more painful (Imho) 4 days 8am till 8pm 4 days off 4 days 8pm till 8am 4 days off Rinse and repeat. ...Skeeve -- Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego or eintellego at facebook.com twitter.com/networkceoau ; www.linkedin.com/in/skeeve PO Box 7726, Baulkham Hills, NSW 1755 Australia -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis On 17/04/11 9:34 PM, "Wayne Lee" > wrote: Rotating shifts between daytime and nighttime is a horrible thing to do to your workers, both for their health and their attention span. One of the places I worked had the following pattern. It was horrible 2 days/shifts of 6am till 6pm 2 days/shifts of 6pm till 6am 4 days off Wayne From coy.hile at coyhile.com Sun Apr 17 08:24:40 2011 From: coy.hile at coyhile.com (Coy Hile) Date: Sun, 17 Apr 2011 13:24:40 +0000 Subject: NANOG Digest, Vol 39, Issue 52 In-Reply-To: References: Message-ID: > >> Rotating shifts between daytime and nighttime is a horrible thing to >> do to your workers, both for their health and their attention span. > I wonder how well something like the following would work (seen in paid fire/EMS circles): 24 on, 48 off. But staff those 24 shifts with maybe 20% more than actually needed to provide minimum coverage. Of course, that all assumes that you can trust your guys to work out the dynamics of "hey, you watch for the next 30 while I take a break". -c From Valdis.Kletnieks at vt.edu Sun Apr 17 09:52:51 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 17 Apr 2011 10:52:51 -0400 Subject: NANOG Digest, Vol 39, Issue 52 In-Reply-To: Your message of "Sun, 17 Apr 2011 13:24:40 -0000." References: Message-ID: <134084.1303051971@localhost> On Sun, 17 Apr 2011 13:24:40 -0000, Coy Hile said: > I wonder how well something like the following would work (seen in > paid fire/EMS circles): > > 24 on, 48 off. Note that for much of those 24 on, the people are actually on downtime on site in case the buzzer goes off. Heck, the station even has enough beds in it for half the crew to be asleep. ;) So probably *not* applicable to NOC scheduling. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jra at baylink.com Sun Apr 17 10:00:43 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 17 Apr 2011 11:00:43 -0400 (EDT) Subject: 365x24x7 In-Reply-To: Message-ID: <23204495.2659.1303052443474.JavaMail.root@benjamin.baylink.com> > If I were going to provide a 365x24x7 NOC, how many teams of personnel > do I need to fully cover operations? I assume minimally you need 3 teams to > cover the required 24 hr coverage, but there is off time and schedule rotation? > > thoughts, experience? It depends a lot on how you structure your shifts; the problem is getting everyone 40 hours without unnecessary overlap. The TV master control facility in which I'm working presently does it by doing overlapping 10 hour shifts; it takes 10 people to have 2 on-shift at all times. You work 6 hours with one person, and 4 with the other. Your 3 teams estimate is, I suspect, derived from dividing 24 hrs/day by 8/hrs shift... but that doesn't take weekends into account, and you don't necessarily want to have 3 more teams who only work 2 days a week. I don't think there's *any* way to do it that guarantees you'll always have the same people working together; fortunately, I also don't think that's all that necessary in that environment. Cheers, -- jra From jra at baylink.com Sun Apr 17 10:06:42 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 17 Apr 2011 11:06:42 -0400 (EDT) Subject: 365x24x7 In-Reply-To: <4DA869AD.9070202@paulgraydon.co.uk> Message-ID: <5954218.2663.1303052802400.JavaMail.root@benjamin.baylink.com> > For what it's worth, was part of a datacenter operations department > that > had a 24x7 team. 4 shifts, 4 staff on each shift (1 was supervisor who > did same work as the rest, 1 'point of contact' who stayed in the > office). > 4 days on, 4 days off, 12 hour shifts, 8-8. Shift teams would > alternate > between day and night (so 4 day, 4 off, 4 night, 4 off, repeat ad > infinitum). During the day that was bolstered by 6 day-staff, Monday > to > Friday, who would have a staggered start through the day (IIRC 2 start > at 8, 2 at 9, 2 at 11) And also for what it's worth, my understanding of body circadian rhythm research suggests that "every 8 days" is *WAY* too short a period to be flipping people's shifts from day to night; every 6 months is more reasonable. Cheers, -- jra From bonomi at mail.r-bonomi.com Sun Apr 17 10:12:02 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sun, 17 Apr 2011 10:12:02 -0500 (CDT) Subject: NANOG Digest, Vol 39, Issue 52 In-Reply-To: Message-ID: <201104171512.p3HFC2iG010270@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Sun Apr 17 08:25:23 2011 > Date: Sun, 17 Apr 2011 13:24:40 +0000 > Subject: Re: NANOG Digest, Vol 39, Issue 52 > From: Coy Hile > To: nanog at nanog.org > > > > >> Rotating shifts between daytime and nighttime is a horrible thing to > >> do to your workers, both for their health and their attention span. > > > > I wonder how well something like the following would work (seen in > paid fire/EMS circles): > > 24 on, 48 off. > > But staff those 24 shifts with maybe 20% more than actually needed to > provide minimum coverage. That kind of schedule works well *ONLY* where the primary activity is 'sit and wait for something to happen'. Where it is OK to sleep on the job, as long as you come fully awake when the alarm goes off. From jra at baylink.com Sun Apr 17 10:19:30 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 17 Apr 2011 11:19:30 -0400 (EDT) Subject: 365x24x7 In-Reply-To: <4DA8AA64.2060403@dcrocker.net> Message-ID: <16223434.2665.1303053570686.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Dave CROCKER" > There were 3-5 of us covering things for that added time. But, then, > the major operations were purely daytime, during the week. Graveyard shift was > quiet enough that we surreptitiously bought a cot... You didn't work for the FAA, Dave, did you? Cheers, -- jra From jra at baylink.com Sun Apr 17 10:22:50 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 17 Apr 2011 11:22:50 -0400 (EDT) Subject: 365x24x7 (sleep patterns) In-Reply-To: Message-ID: <4639894.2667.1303053770608.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Foster" > Local emergency services[1] operate '2 days, 2 nights, 4 off'. > > Dayshifts are 10 hour 8am-6pm. Nightshift is 6pm until 8am. This > creates > a 4-watch rotation. I dunno from Ambulance -- they're load driven... by my understanding is that around here, the fire people are 3 days on, and 4 days off, or something similar to that. Since they sleep in, they're effectively on-call at all times, and they've got enough people on a shift that they can do internal rotations as to who goes, unless it's a big enough call that they all need to roll, which is a small enough percentage of calls to make it work. Cheers, - jra From johnl at iecc.com Sun Apr 17 11:18:29 2011 From: johnl at iecc.com (John Levine) Date: 17 Apr 2011 16:18:29 -0000 Subject: 365x24x7 In-Reply-To: <4DAAAE5C.4040503@mistral.co.uk> Message-ID: <20110417161829.31826.qmail@joyce.lan> >Some people claimed they'd have preferred it if we'd changed to the >_following_ shift rater than the preceding shift each week but never >having tried that I don't know how it would be. I've read stuff that confirms that changing to a later shift is much easier than changing to an earlier one. It certainly matches my experience that the jet lag flying to Europe, where I have to get up six hours earlier, is much worse than flying back. It also makes the obvious point that fewer shift changes are easier on the employees than more. R's, John From bzs at world.std.com Sun Apr 17 11:37:22 2011 From: bzs at world.std.com (Barry Shein) Date: Sun, 17 Apr 2011 12:37:22 -0400 Subject: 365x24x7 In-Reply-To: References: <4DA8AA64.2060403@dcrocker.net> <4DAAAE5C.4040503@mistral.co.uk> Message-ID: <19883.5954.56117.312760@world.std.com> Having done this for quite a few years my advice is that once you get past the basic arithmetic of people-hour-equivalents etc what you need is a middle manager who is a good "horse trader" because it quickly becomes a market of "I can do grave shift Tuesday if you'll take my Saturday AM, I've got a wedding I have to be at, XXX says he'll take your Friday night if you take the Saturday but if you still want Sunday off you're going to have to find someone to cover that and Monday morning unless..." And that manager has to be responsible so such shuffling really ends up with necessary coverage because people make mistakes, often in their favor (OOPS!), and that can get complicated. Regular-hours life goes on despite peoples' shifts and they're forever having to be at jury duty, doctor's appointments, social engagements, govt offices, religion, dog kennels, kids' school meetings, etc etc etc which are fixed in the assumption that people work roughly 9AM-5PM M-F. Yeah some of that is actually easier for people who work odd hours and even the attraction of odd hour work but a lot of it isn't and comes up only once in a while per employee which means, for the manager, once or twice a week. Another practicality is policies about people "hanging out" during non-work hours because you'll find overnight people are night people even on their days off and often have nothing better to do than come in and use your higher bandwidth etc, or just get out of the house, they'll become friendly with overnight co-workers, which might be fine by itself until someone brings in a couple of six-packs because hey they're not working and there won't be a boss around after 1AM and...again, maybe not a problem until they decide to share their fun a little too much with people on duty who are nearby... The other problem is food, overnight people get hungry and depending on location and facilities for bringing and preparing food opportunities for a 3AM lunch can be limited in many locations and if you don't solve it somewhat employees may come up with suboptimal solutions like deciding it's only fair that they get an extra 20 minutes travel each way for an hour lunch, or cooking mess, etc. And of course who to call when something goes very wrong at 4AM or they'll call you every time, for some value of "you", or worse they'll call the police (for example) when you prefer they hadn't (or the police or other LEO will call them)...you need some procedures and training to anticipate such things, power problems, building management calling at 5AM that they need whoever is on to let some people in to knock down all the walls, they're waiting outside... Finally, a weird thing? If there's overnight telephone support people (some of whom are customers!) will find it, sometimes lonely people who want to hear a human voice at 4AM and sometimes completely crazy people who, well, want to hear a human voice at 4AM, some of them are very good at manipulating whoever will answer the phone, "our little secret please don't hang up please don't hang up really please!", you need policies and training if that's a possibility. Gak, I could tell stories... -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From ghira at mistral.co.uk Sun Apr 17 12:24:34 2011 From: ghira at mistral.co.uk (Adam Atkinson) Date: Sun, 17 Apr 2011 18:24:34 +0100 Subject: 365x24x7 In-Reply-To: <20110417161829.31826.qmail@joyce.lan> References: <20110417161829.31826.qmail@joyce.lan> Message-ID: <4DAB2252.40506@mistral.co.uk> John Levine wrote: > I've read stuff that confirms that changing to a later shift is much > easier than changing to an earlier one. It certainly matches my > experience that the jet lag flying to Europe, where I have to get up > six hours earlier, is much worse than flying back. Last time I went to the US I stayed on something pretty close to my usual timetable while there. So I went to bed at about 6pm US time and got up in the very early morning US time. Fortunately, this was fine for the 4-day event I was attending. I think I will do this in future if I can. > It also makes the obvious point that fewer shift changes are easier on > the employees than more. One of my sisters-in-law is a nurse and her shifts seem to be all over the place from day to day. I don't understand how she copes. From dhc2 at dcrocker.net Sun Apr 17 13:15:19 2011 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Sun, 17 Apr 2011 11:15:19 -0700 Subject: 365x24x7 In-Reply-To: <16223434.2665.1303053570686.JavaMail.root@benjamin.baylink.com> References: <16223434.2665.1303053570686.JavaMail.root@benjamin.baylink.com> Message-ID: <4DAB2E37.7030102@dcrocker.net> On 4/17/2011 8:19 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Dave CROCKER" > >> There were 3-5 of us covering things for that added time. But, then, >> the major operations were purely daytime, during the week. Graveyard shift was >> quiet enough that we surreptitiously bought a cot... > > You didn't work for the FAA, Dave, did you? No, or we would have gotten more sleep. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From michael at mwyoung.ca Sun Apr 17 13:17:25 2011 From: michael at mwyoung.ca (Michael Young) Date: Sun, 17 Apr 2011 14:17:25 -0400 Subject: 365x24x7 In-Reply-To: <20110417161829.31826.qmail@joyce.lan> References: <20110417161829.31826.qmail@joyce.lan> Message-ID: <8FFCC290-93D4-4BBE-8526-1F18C390C3C9@mwyoung.ca> Having run 24/7 NOC, customer care and tier 3 engineering/dev support, for 20 years, my two cents are: 1) You need to rotate shifts and have overlap between shifts for training and communication purposes 2) Always rotate forward, due sleep cycles 3) If you want to retain staff and not burn them out, do not rotate more than one a month, I've tried from 2 week to 12 week rotations. Longer rotations mean more staff, when you try various shift schedules you will see why, but they work best. You make your cost on the extra staff by lowering turnover which is expensive to deal with. 4) Take your staff opinions in on schedule but you make the call, someone will always dislike the schedule no matter how hard you try,....... 5) make sure you support shift swapping within reason, so people can deal with personal schedule conflicts Good luck! Michael Young M:647-289-1220 On 2011-04-17, at 12:18, "John Levine" wrote: >> Some people claimed they'd have preferred it if we'd changed to the >> _following_ shift rater than the preceding shift each week but never >> having tried that I don't know how it would be. > > I've read stuff that confirms that changing to a later shift is much > easier than changing to an earlier one. It certainly matches my > experience that the jet lag flying to Europe, where I have to get up > six hours earlier, is much worse than flying back. > > It also makes the obvious point that fewer shift changes are easier on > the employees than more. > > R's, > John > > > > From jim at reptiles.org Sun Apr 17 13:49:00 2011 From: jim at reptiles.org (Jim Mercer) Date: Sun, 17 Apr 2011 14:49:00 -0400 Subject: mail admin contacts within gc.ca ? Message-ID: <20110417184900.GF66695@reptiles.org> anyone have a method of determining who to contact about DNS/email issues within gc.ca? i tried emailing postmaster at pco.gc.ca, but got a bounce back saying i was not on the 'approved list'. (pco.gc.ca being the group i need to contact) -- Jim Mercer jim at reptiles.org +1 416 410-5633 You are more likely to be arrested as a terrorist than you are to be blown up by one. -- Dianora From johnl at iecc.com Sun Apr 17 16:43:21 2011 From: johnl at iecc.com (John Levine) Date: 17 Apr 2011 21:43:21 -0000 Subject: mail admin contacts within gc.ca ? In-Reply-To: <20110417184900.GF66695@reptiles.org> Message-ID: <20110417214321.61205.qmail@joyce.lan> In article <20110417184900.GF66695 at reptiles.org> you write: > >anyone have a method of determining who to contact about DNS/email issues >within gc.ca? > >i tried emailing postmaster at pco.gc.ca, but got a bounce back saying i was >not on the 'approved list'. (pco.gc.ca being the group i need to contact) A little poking around on their web site found their electronic directory, which found this list of their IT security people. Give them a call on Monday: http://sage-geds.tpsgc-pwgsc.gc.ca/cgi-bin/direct500/eng/XEou%3dITS-STI%2cou%3dITSD-DIST%2cou%3dCORPSERV-SERVMIN%2cou%3dPCO-BCP%2co%3dGC%2cc%3dCA Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From nanog2 at adns.net Sun Apr 17 17:16:53 2011 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Sun, 17 Apr 2011 17:16:53 -0500 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? References: <4DA5B1B7.7050608@armoredpackets.com> Message-ID: <468FF6CE4532454F80965EFD4795D148@TAKA> Thanks to all for your suggestions. We've had several other problems with our Barracuda box as well including the fact that it is very under-powered and that the web interface for admin stuff seems to freeze up and only send partial http responses back after log queries. Think will probably move on to something else and abandon Barracuda Networks. I certainly would warn others away from their products based on my unpleasant experience. From joelja at bogus.com Sun Apr 17 21:00:36 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 17 Apr 2011 19:00:36 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <145AC4DF-2DBB-4818-9BBB-8E325CCB56E7@delong.com> References: <4D9D8365.9060202@optilian.com> <897661.3824.qm@web121620.mail.ne1.yahoo.com> <4D9DC14B.8090308@cis.vutbr.cz> <145AC4DF-2DBB-4818-9BBB-8E325CCB56E7@delong.com> Message-ID: <4DAB9B44.5000406@bogus.com> On 4/7/11 7:04 AM, Owen DeLong wrote: > > On Apr 7, 2011, at 6:51 AM, Tomas Podermanski wrote: > >> Hi Daniel, >> all IPv6 multihoming ideas are very theoretical today. None of them >> is ready to use. Shim6 looks very good, but it requires support on both >> a client and a server side. As you can guess, there is only experimental >> support for some operating systems. Microsoft and Apple doesn't support it. >> > Well, BGP multihoming works today quite well. It's no different from IPv4 > and is a perfectly viable technology. to reiterate, if you are multihoming in ipv4, you likely have a pi assigned prefix or one that you have permission to advertise from an upstream. If you obtain a pi v6 prefix via the same channel you obtained the v4 one it is likely that you simply advertise to 1 or more upstreams and you are done. I have done this too good effect in three different organizations that I've had the privilege of working with so far. I'd go so far as to say that the experience was exactly the same. >> A one possible solution I have found is based on a network prefix >> translation (NPTv6 http://tools.ietf.org/html/draft-mrw-nat66-12). Using >> NPTv6 you can do multihoming that is very similar to multihoming based >> on IPv4 NAT. >> > You can also use thumb cuffs to suspend yourself from a rafter, but, I don't > recommend it unless you are into pain. > > Owen > > From frnkblk at iname.com Sun Apr 17 22:47:20 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 17 Apr 2011 22:47:20 -0500 Subject: 365x24x7 In-Reply-To: <4DAB2E37.7030102@dcrocker.net> References: <16223434.2665.1303053570686.JavaMail.root@benjamin.baylink.com> <4DAB2E37.7030102@dcrocker.net> Message-ID: <005101cbfd7b$51a4f140$f4eed3c0$@iname.com> Timely article on the FAA's involvement with sleep schedules: http://www.ajc.com/news/air-traffic-controller-scheduling-913244.html "Union spokesman Doug Church said up to now, 25 percent of the nation's air traffic controllers work what he called a "2-2-1? schedule, working afternoon to night the first two days, followed by a mandatory minimum of eight hours for rest before starting two morning-to-afternoon shifts, another eight or more hours for sleep, then a final shift starting between 10 p.m. to midnight. "Maybe we need to work in more time for rest," Church said. "You?re forcing yourself to work at a time when the body is used to sleeping." Frank -----Original Message----- From: Dave CROCKER [mailto:dhc2 at dcrocker.net] Sent: Sunday, April 17, 2011 1:15 PM To: Jay Ashworth Cc: NANOG Subject: Re: 365x24x7 On 4/17/2011 8:19 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Dave CROCKER" > >> There were 3-5 of us covering things for that added time. But, then, >> the major operations were purely daytime, during the week. Graveyard shift was >> quiet enough that we surreptitiously bought a cot... > > You didn't work for the FAA, Dave, did you? No, or we would have gotten more sleep. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From smb at cs.columbia.edu Sun Apr 17 23:12:04 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 18 Apr 2011 00:12:04 -0400 Subject: 365x24x7 In-Reply-To: <005101cbfd7b$51a4f140$f4eed3c0$@iname.com> References: <16223434.2665.1303053570686.JavaMail.root@benjamin.baylink.com> <4DAB2E37.7030102@dcrocker.net> <005101cbfd7b$51a4f140$f4eed3c0$@iname.com> Message-ID: On Apr 17, 2011, at 11:47 20PM, Frank Bulk wrote: > Timely article on the FAA's involvement with sleep schedules: > http://www.ajc.com/news/air-traffic-controller-scheduling-913244.html > "Union spokesman Doug Church said up to now, 25 percent of > the nation's air traffic controllers work what he called a > "2-2-1? schedule, working afternoon to night the first two > days, followed by a mandatory minimum of eight hours for > rest before starting two morning-to-afternoon shifts, > another eight or more hours for sleep, then a final shift > starting between 10 p.m. to midnight. > > "Maybe we need to work in more time for rest," Church said. > "You?re forcing yourself to work at a time when the body is > used to sleeping." Also see http://www.google.com/hostednews/ap/article/ALeqM5hstTegGafIYTakRavF4WEEPblz-Q?docId=f174db27ddb44dadbcad8419dfe138a7 "People who change shifts every few days are going to have all kinds of problems related to memory and learning, Fishbein said. This kind of schedule especially affects what he called relational memories, which involve the ability to understand how one thing is related to another. ... "Controllers are often scheduled for a week of midnight shifts followed by a week of morning shifts and then a week on swing shifts. This pattern, sleep scientists say, interrupts the body's natural sleep cycles." --Steve Bellovin, https://www.cs.columbia.edu/~smb From joelja at bogus.com Mon Apr 18 00:52:09 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 17 Apr 2011 22:52:09 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> <768DDE65-C091-4A48-97E4-92F3E51D6042@net.t-labs.tu-berlin.de> Message-ID: <4DABD189.4060201@bogus.com> On 4/13/11 12:13 PM, Jeff Wheeler wrote: > However, LISP does have non-Internet applications which are > interesting. You can potentially have multi-homed connectivity > between your own branch offices, using one or more public Internet > connections at each branch, and your own private mapping servers which > know the state of reachability from one branch to the others. In > effect, it can become "poor man's L3VPN." > > Beyond non-Internet applications such as this, I think LISP is useful > largely as a case study for what happens when a bunch of engineers get > together and "solve" some problems they do not understand -- DFZ > size/growth being chief among them. They moved the problem along, that's what indirection does. to borrow from david wheeler: "All problems in computer science can be solved by another level of indirection... Except for the problem of too many layers of indirection." It could be that ultimately what passes for end-system/network multihoming moved up the stack to application layer overlays that already incur the overhead associated with building such a topology. > Like others, I still leave room for the possibility that I am wrong about this. > From aaron at wholesaleinternet.net Mon Apr 18 07:59:21 2011 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Mon, 18 Apr 2011 07:59:21 -0500 Subject: 365x24x7 In-Reply-To: References: <16223434.2665.1303053570686.JavaMail.root@benjamin.baylink.com> <4DAB2E37.7030102@dcrocker.net> <005101cbfd7b$51a4f140$f4eed3c0$@iname.com> Message-ID: My guys work 12 hour shifts. 2 days on, 2 days off, 3 days on, 2 days off, 2 on 3 off. The three days on is always friday-sunday so every other weekend they either have a 3 day weekend or 3 days of work. In a pay period, with 30 minute lunch per shift it comes to 80.5 hours. I keep my guys on the same shifts for consistancy. Aaron Sent via DROID on Verizon Wireless -----Original message----- From: Steven Bellovin To: frnkblk at iname.com Cc: NANOG , dcrocker at bbiw.net Sent: Mon, Apr 18, 2011 04:12:04 GMT+00:00 Subject: Re: 365x24x7 On Apr 17, 2011, at 11:47 20PM, Frank Bulk wrote: > Timely article on the FAA's involvement with sleep schedules: > http://www.ajc.com/news/air-traffic-controller-scheduling-913244.html > "Union spokesman Doug Church said up to now, 25 percent of > the nation's air traffic controllers work what he called a > "2-2-1? schedule, working afternoon to night the first two > days, followed by a mandatory minimum of eight hours for > rest before starting two morning-to-afternoon shifts, > another eight or more hours for sleep, then a final shift > starting between 10 p.m. to midnight. > > "Maybe we need to work in more time for rest," Church said. > "You?re forcing yourself to work at a time when the body is > used to sleeping." Also see http://www.google.com/hostednews/ap/article/ALeqM5hstTegGafIYTakRavF4WEEPblz-Q?docId=f174db27ddb44dadbcad8419dfe138a7 "People who change shifts every few days are going to have all kinds of problems related to memory and learning, Fishbein said. This kind of schedule especially affects what he called relational memories, which involve the ability to understand how one thing is related to another. ... "Controllers are often scheduled for a week of midnight shifts followed by a week of morning shifts and then a week on swing shifts. This pattern, sleep scientists say, interrupts the body's natural sleep cycles." --Steve Bellovin, https://www.cs.columbia.edu/~smb From andyring at inebraska.com Mon Apr 18 08:58:12 2011 From: andyring at inebraska.com (Andy Ringsmuth) Date: Mon, 18 Apr 2011 08:58:12 -0500 Subject: 365x24x7 In-Reply-To: References: <16223434.2665.1303053570686.JavaMail.root@benjamin.baylink.com> <4DAB2E37.7030102@dcrocker.net> <005101cbfd7b$51a4f140$f4eed3c0$@iname.com> Message-ID: <0CEE7A8A-F418-43F3-87D1-9098529E3778@inebraska.com> \On Apr 18, 2011, at 7:59 AM, Aaron Wendel wrote: > My guys work 12 hour shifts. 2 days on, 2 days off, 3 days on, 2 days off, 2 on 3 off. The three days on is always friday-sunday so every other weekend they either have a 3 day weekend or 3 days of work. > > In a pay period, with 30 minute lunch per shift it comes to 80.5 hours. I keep my guys on the same shifts for consistancy. > > Aaron My wife is a nurse working second shift, 12-hour shifts, 7p-7a (actually 6:45p to 7:15a to allow for a little overlap). Her hospital has it worked out on a 6-week schedule, with Wednesdays being the new pay week. Nurses there work 3 days a week, for 36 hours. Here's how they do it (these are calendar weeks) Week 1 - Su M T F Sa Su Week 2 - W Week 3 - M T W Week 4 - M T F Sa Su Week 5 - Th Week 6 - M T I know this is also a decades-long struggle in the railroad industry too (My business does a lot of contract work with that industry). In particular locomotive engineers and conductors. 100 percent on-call, maximum 12-hours on duty with 10 off (recently changed from 8). Fatigue is quite critical there too, you don't want an engineer falling asleep pulling a train full of HazMat. For datacenter work, I'd think a schedule like the above would be doable. You end up working every third weekend, and yes, weeks 1 and 4 aren't pleasant, it's followed by a 1-day week so you've got plenty of time to recover. -Andy From jmkeller at houseofzen.org Mon Apr 18 09:46:25 2011 From: jmkeller at houseofzen.org (James M Keller) Date: Mon, 18 Apr 2011 10:46:25 -0400 Subject: 365x24x7 In-Reply-To: References: <16223434.2665.1303053570686.JavaMail.root@benjamin.baylink.com> <4DAB2E37.7030102@dcrocker.net> <005101cbfd7b$51a4f140$f4eed3c0$@iname.com> Message-ID: <4DAC4EC1.2050006@houseofzen.org> In my previous life at a large backbone provider's managed security services SOC/NOC we had the following: Shifts where divided into front and back half with 10 hour days. Front and back half segments of the shift where also split with half working Sun-Wed and half working Mon-Thur alternating. That had them alternating weekend coverage but also alternating 4 day and 2 day 'weekends'. One shift lead did M-F 8 hour days and was primary escalation for their reports during off hours/weekends, with the lead having to fill any emergency schedule holes. This provided shift overlap to cover issue hand offs and had everyone in the office Tue-Thur to cover meetings, training, any large projects, etc. At min the shifts where 9 staff (4 front half, 4 back half, and the team lead). So 27 min staffing. We normally had some additional folks per shift and they would do M-F 8 hours like the lead or fill a gap on weekends and flex the overages during the week during the mid week overlap. We did do the 30 day rotation of changing to the next shift (ie Morning -> Days -> Midnight -> Morning) but once we got beyond staffing with 20 year old single guys it was basically impossible to keep someone very long who was willing to do that as it kills any outside activities like taking classes, kids schedules, etc.) -- --- James M Keller From owen at delong.com Mon Apr 18 10:53:04 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Apr 2011 08:53:04 -0700 Subject: 365x24x7 In-Reply-To: <0CEE7A8A-F418-43F3-87D1-9098529E3778@inebraska.com> References: <16223434.2665.1303053570686.JavaMail.root@benjamin.baylink.com> <4DAB2E37.7030102@dcrocker.net> <005101cbfd7b$51a4f140$f4eed3c0$@iname.com> <0CEE7A8A-F418-43F3-87D1-9098529E3778@inebraska.com> Message-ID: The best schedule I ever worked for this was divided into essentially 2 teams: SMTW and WTFS There were 3 shifts on each team, though, that could be load adjusted by creating additional time slots. The nice thing about the SMTW/WTFS structure was that we always had overlap on Wednesday which we would take advantage of for training, maintenance, or other "crew-heavy" things that occasionally needed to get done. Training would take 2 weeks with the A-shfit one week and the B shift the following week (or vice versa). We ran 10-hour shifts (there's a provision for 4 10 hour shifts not involving overtime pay if agreed ahead of time). Shifts ran 9p-8a, 6a-5p, and 11a-10p with the crews staggering their lunches. Owen From lukasz at bromirski.net Mon Apr 18 13:44:03 2011 From: lukasz at bromirski.net (Lukasz Bromirski) Date: Mon, 18 Apr 2011 20:44:03 +0200 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> <768DDE65-C091-4A48-97E4-92F3E51D6042@net.t-labs.tu-berlin.de> Message-ID: <4DAC8673.5070906@bromirski.net> On 2011-04-13 21:13, Jeff Wheeler wrote: > Plain and simple, it does not scale up any better than injecting more > routes into the DFZ, unless you 1) accept macro-flow-based routing; or > 2) scale up the size of your FIB along with the much larger number of > prefixes which would be introduced by lowering the barrier-to-entry > for multi-homing and provider-independent addressing. LISP scales better, because with introduction of *location* prefix, you're at the same time (or ideally you would) withdraw the original aggregate prefix. And as no matter how you count it, the number of *locations* will be somewhat limited vs number of *PI* address spaces that everyone wants do drag around the world and advertise in a number of places, specially with IPv6. And that's exactly what LISP had in mind - to prevent massive explosion of FIB for IPv6. For IPv4 the battle was lost somewhat already - and even for that, with LISP you can actually reverse the trend, by moving back with the allocations. As the control plane of the whole system is moved off the edge routers into potentially very capable servers, you also have the extra potential of actually shaping the policies for traffic engineering dynamically without affecting routing nodes. We may of course argue that the current routers are pretty capable in terms of processing power for control-plane, but the convergence times for exchanging and calculating prefixes for VPNs in a large (1-2-3-5M+) L3VPN deployments are counted in tens of minutes, not in seconds. Calculating them offsite and just dumping per-router-calculated table would be more efficient and faster. > However, LISP does have non-Internet applications which are > interesting. You can potentially have multi-homed connectivity > between your own branch offices. If the LISP is deployed by commercial entities, just as Google and Facebook are experimenting right now, LISP would also mean multihoming, load-balancing and trafic engineering options that are today not available with BGP or highly limited in the accuracy. > Beyond non-Internet applications such as this, I think LISP is useful > largely as a case study for what happens when a bunch of engineers get > together and "solve" some problems they do not understand -- DFZ > size/growth being chief among them. Can't comment on that. I personally find Vince Fuller, Dino Farinacci, Dave Meyer and Darrel Lewis quite knowledgeable in routing and proficient in explaining why the LISP was created in the first place, but you of course may know better. -- "There's no sense in being precise when | ?ukasz Bromirski you don't know what you're talking | jid:lbromirski at jabber.org about." John von Neumann | http://lukasz.bromirski.net From surfer at mauigateway.com Mon Apr 18 13:53:56 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 18 Apr 2011 11:53:56 -0700 Subject: Easily confused... Message-ID: <20110418115356.3A69747F@resin06.mta.everyone.net> --- nanog at jima.tk wrote: From: Jima On 2011-04-16 20:06, Michael Painter wrote: > Brielle Bruns wrote: >> I'm assuming your provider's network engineers (stupidly) assumed >> 123.x.x.x was a good idea for use in a private setup because it hadn't >> been assigned from the global pool (yet). >> >> Wouldn't be the first provider or service to not use proper RFC assigned >> private IP space for their internal networking setup. > > Apologies...missed operative word 'internal'. I was about to reply pointing that out. FWIW, they're not announcing that space, so I definitely agree with the poorly-thought-out private infrastructure theory. http://bgp.he.net/AS36149#_prefixes FWIW. ----------------------------------------------------------------------- When I was last there there was a definite lack of folks with hands-on experience managing that size of address space: a /15 and two /16s plus some swamp. Further there're a lot of companies that contract to them that suggest these things and the contractor's advice is always faithfully followed, so any blame will go to the vendor if trouble happens due to design flaws. Making waves by saying this or that is wrong definitely gets one into hot water... ;-) ----------------------------------------------------------- > They are testing IPTV on Oahu in preperation for roll-out, so maybe they > renumbered in order to more easily identify the segments.(?) Really, I'd have hoped they'd use their two-year-old 2607:f9a0::/32 for anything that ambitious...but I might be wishing for too much. (Also, that 123 block seems to have been allocated in 2006, so it'd be even more unprofessional to start projects with that space since then.) -------------------------------------------------------- I'm the one that got this space for them, but allocation of folks to IPv6 roll out was minimal due the the upcoming IPTV roll out. I was the lone IPv6 voice in the company for a long time, but when I left there was gaining interest in IPv6 strategies. Not enough netgeeks and too many projects rolling out. scott From jsw at inconcepts.biz Mon Apr 18 14:18:46 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Mon, 18 Apr 2011 15:18:46 -0400 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <4DAC8673.5070906@bromirski.net> References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> <768DDE65-C091-4A48-97E4-92F3E51D6042@net.t-labs.tu-berlin.de> <4DAC8673.5070906@bromirski.net> Message-ID: 2011/4/18 Lukasz Bromirski : > LISP scales better, because with introduction of *location* > prefix, you're at the same time (or ideally you would) > withdraw the original aggregate prefix. And as no matter how > you count it, the number of *locations* will be somewhat > limited vs number of *PI* address spaces that everyone wants I strongly disagree with the assumption that the number of locations/sites would remain static. This is the basic issue that many folks gloss over: dramatically decreasing the barrier-to-entry for multi-homing or provider-independent addressing will, without question, dramatically increase the number of multi-homed or provider-independent sites. LISP "solves" this problem by using the router's FIB as a macro-flow-cache. That's good except that a site with a large number of outgoing macro-flows (either because it's a busy site, responding to an external DoS attack, or actually originating a DoS attack from a compromised host) will cripple that site's ITR. In addition, the current negative mapping cache scheme is far from ideal. I've written a couple of folks with a provably superior scheme (compared to existing work), and have received zero feedback. This is not good. > We may of course argue that the current routers are pretty > capable in terms of processing power for control-plane, but We agree that the ability to move tasks from the router to an external control plane is good. BGP may get better at this as time goes on, too. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From lukasz at bromirski.net Mon Apr 18 14:27:59 2011 From: lukasz at bromirski.net (Lukasz Bromirski) Date: Mon, 18 Apr 2011 21:27:59 +0200 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: References: <4D9D8365.9060202@optilian.com> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> <768DDE65-C091-4A48-97E4-92F3E51D6042@net.t-labs.tu-berlin.de> <4DAC8673.5070906@bromirski.net> Message-ID: <4DAC90BF.9020907@bromirski.net> On 2011-04-18 21:18, Jeff Wheeler wrote: > I strongly disagree with the assumption that the number of > locations/sites would remain static. It would grow, nobody said it would remain static. But still - it will grow slower than the number of new "full" allocations - covering both location *and* id. > LISP "solves" this problem by using the router's FIB as a > macro-flow-cache. That's good except that a site with a large number > of outgoing macro-flows (either because it's a busy site, responding > to an external DoS attack, or actually originating a DoS attack from a > compromised host) will cripple that site's ITR. Scalability is one of the points traditionally left for the end, but that's hardly different from any protocol that was designed and then put into mainstream use. Second - you actually don't know that for sure - the mix of "from LISP" and "from normal IP" traffic would change in time, and the natural grow of the capabilities with the higher adoption would propably also affect ITR/ETR scalability numbers. > In addition, the current negative mapping cache scheme is far from > ideal. I've written a couple of folks with a provably superior scheme > (compared to existing work), and have received zero feedback. This is > not good. You mean LISP authors? -- "There's no sense in being precise when | ?ukasz Bromirski you don't know what you're talking | jid:lbromirski at jabber.org about." John von Neumann | http://lukasz.bromirski.net From bicknell at ufp.org Mon Apr 18 14:50:26 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 18 Apr 2011 12:50:26 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <4DAC8673.5070906@bromirski.net> References: <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> <768DDE65-C091-4A48-97E4-92F3E51D6042@net.t-labs.tu-berlin.de> <4DAC8673.5070906@bromirski.net> Message-ID: <20110418195026.GA33393@ussenterprise.ufp.org> In a message written on Mon, Apr 18, 2011 at 08:44:03PM +0200, Lukasz Bromirski wrote: > LISP scales better, because with introduction of *location* > prefix, you're at the same time (or ideally you would) > withdraw the original aggregate prefix. And as no matter how > you count it, the number of *locations* will be somewhat > limited vs number of *PI* address spaces that everyone wants > do drag around the world and advertise in a number of places, > specially with IPv6. And that's exactly what LISP had in > mind - to prevent massive explosion of FIB for IPv6. I would agree with this statement if and only if you qualified it with "for the default free zone (DFZ)". LISP reduces the number of routes in the DFZ by making each route represent a "location". However, like the proverbal balloon, when squeezed on one end the other side gets larger. LISP does this by introducing an entirely new infrastructure, the mapping servers. These must now scale to meet the demands that will be placed on them. LISP also does this by making the edge box responsible for looking up and caching information on the flows going through it. In this way LISP, on a worldwide basis, very closely resembles a Cisco 7500 Chassis circa 1996 with "flow caching". The mapping servers are the RP, the DFZ is the backplane, and the edge boxes are the linecards. In both designs when the first packet comes in a lookup is made to the central authority, and a cache entry is placed down at the entry processor. The backplane is dumb and fast. Anyone familar with then enviornments where a 7500 performed poorly should be able to immediately detect where a LISP architecture will perform poorly. Any events which invalidate the cache will result in a period of extremely high usage on the mapping servers likely with extremely high packet loss until all entries are resolved. Any edges which talk to a significant number of other networks will have to cache a significant portion of the Internet, which will actually lead to edge boxes having to be larger than they are now. It is the last point I find most interesting about LISP. Today someone who wants to route their own address space at 10G can buy any number of cheap L3 devices with enough RAM and CPU to hold the internal routes and a default pointed at their provider. The provider's boxes keep the full table and move the packets to where they need to go. In a LISP world that edge box would be set up to do map/encap, and thus would need to keep cache entries for all active addresses, which for a busy site is potentially the entire table. The service provider box now no longer needs to know about all destinations, and thus can have a smaller table or be upgraded less often. [Note, while I describe the edge here as customer owned, it's entirely possible it may be ISP owned and managed for the customer, a cost of which I'm sure they would fully pass on.] To my mind then, LISP moves these tables from a few thousand DFZ routers managed (generally) by well staffed engineering teams to tens or hundreds of thousands of edge boxes, in many cases managed by the clueless. Many edge proponents will say it's easier to upgrade the edge than the core, so this is a win. Vendors may like the idea of 100,000 boxes needing the resources to hold most of a table, rather than 1,000. If the Internet had started out with a LISP design from scratch I'm not sure it would be any better, or worse than our current configuration. Back to the balloon, it trades cost and complexity in one area for cost and complexity in another area. In that sense I am neither against it nor for it, it's just 'different'. The problem is we don't live in a LISP world. To go there now would be a wholesale conversion from what we are doing. Granted, the LISP folks have designed something that is relatively easy to convert to, so they are making an effort. Still, to justify a conversion and the engineering time and business risk it would have to be significantly better. Like 2x-4x better, and preferably an order of magnitude. That's where I'm just not seeing it with LISP, yet. I hope the LISP guys keep working on this, they are at the moment the only credible alternative I've seen to our current system in my lifetime. It's just not good enough to justify a switch based on the current world conditions and state of the solution; at least to me. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From owen at delong.com Mon Apr 18 15:09:11 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Apr 2011 13:09:11 -0700 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> <768DDE65-C091-4A48-97E4-92F3E51D6042@net.t-labs.tu-berlin.de> <4DAC8673.50709! 06@bromirski.net> Message-ID: On Apr 18, 2011, at 12:18 PM, Jeff Wheeler wrote: > 2011/4/18 Lukasz Bromirski : >> LISP scales better, because with introduction of *location* >> prefix, you're at the same time (or ideally you would) >> withdraw the original aggregate prefix. And as no matter how >> you count it, the number of *locations* will be somewhat >> limited vs number of *PI* address spaces that everyone wants > > I strongly disagree with the assumption that the number of > locations/sites would remain static. This is the basic issue that > many folks gloss over: dramatically decreasing the barrier-to-entry > for multi-homing or provider-independent addressing will, without > question, dramatically increase the number of multi-homed or > provider-independent sites. > Done properly, a multi-homed end-site does not need to have its own locator ID, but, could, instead, use the locator IDs of all directly proximate Transit ASNs. I don't know if LISP particularly facilitates this, but, I think it would be possible generically in a Locator/ID based system. > LISP "solves" this problem by using the router's FIB as a > macro-flow-cache. That's good except that a site with a large number > of outgoing macro-flows (either because it's a busy site, responding > to an external DoS attack, or actually originating a DoS attack from a > compromised host) will cripple that site's ITR. > The closer you move the ITRs to the edge, the less of an issue this becomes. > Owen From khomyakov.andrey at gmail.com Mon Apr 18 16:08:43 2011 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Mon, 18 Apr 2011 17:08:43 -0400 Subject: eigrp set next hop Message-ID: Hi nanog I need to advertise EIGRP route with a different next-hop value than self Due to how the connections are setup, I have to run BGP between two peers that are 3 hops away from each other. router1--router2--firewall--router3 I'm running EBGP between router1 and router3 router1 is redistributing into EIGRP that's running with router2 The problem is that now router2 thinks that router3 routes are reachable via router1 so I have myself a route loop. Is there a way to advertise an EIGRP route with next hop of router3 (or firewall for that matter) rather than router1 which is what EIGRP does by default Thank you in advance for advice. -- Andrey Khomyakov [khomyakov.andrey at gmail.com] From lukasz at bromirski.net Mon Apr 18 17:37:43 2011 From: lukasz at bromirski.net (Lukasz Bromirski) Date: Tue, 19 Apr 2011 00:37:43 +0200 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <20110418195026.GA33393@ussenterprise.ufp.org> References: <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> <768DDE65-C091-4A48-97E4-92F3E51D6042@net.t-labs.tu-berlin.de> <4DAC8673.5070906@bromirski.net> <20110418195026.GA33393@ussenterprise.ufp.org> Message-ID: <4DACBD37.5010205@bromirski.net> On 2011-04-18 21:50, Leo Bicknell wrote: > To my mind then, LISP moves these tables from a few thousand DFZ > routers managed (generally) by well staffed engineering teams to > tens or hundreds of thousands of edge boxes, in many cases managed > by the clueless. This is something out of practical world that would have to be considered obviously. OTOH it is the prefix originating site that controls who and how will see the prefixes, not the traffic source site. Having control over what and to whom you advertise, you have the capability to "not being announced" to the "clueless". > The problem is we don't live in a LISP world. To go there now would > be a wholesale conversion from what we are doing. Granted, the > LISP folks have designed something that is relatively easy to convert > to, so they are making an effort. The LISP adventure is not as simple as "go from A to Z" - it may end up today if the test network decides to disband with no hurt to anyone. It may decide to go on and convert only the sites willing, which is actually what happens right now - giving benefits to users, and normal service for anyone else. -- "There's no sense in being precise when | ?ukasz Bromirski you don't know what you're talking | jid:lbromirski at jabber.org about." John von Neumann | http://lukasz.bromirski.net From surfer at mauigateway.com Mon Apr 18 17:57:09 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 18 Apr 2011 15:57:09 -0700 Subject: IPv4 address exchange Message-ID: <20110418155709.3785099F@resin16.mta.everyone.net> Has this been discussed here? I did a quickie search and saw nothing. Other than spam to a technical mailing list, do you guys care, or is it a non-issue? scott --- Begin forwarded message: From: "Martin v. L?wis" To: apnic-talk at lists.apnic.net Subject: [apnic-talk] IPv4 address exchange Date: Mon, 18 Apr 2011 22:07:59 +0200 With the address pool exhausted in APNIC for regular allocations, service providers will need a way to acquire additional address blocks for deployment; by discovering resources that are currently unused (or can be released by the current user with sufficient effort). In order to promote such address transfers, we are offering the Asia-Pacific region a platform, at http://tradeipv4.com/ While this platform is designed to ultimately allow transfer of addresses within and across all regions of the world, we expect that interest within the APNIC community will be largest, hence this announcement. Kind regards, Martin v. L?wis _______________________________________________ apnic-talk mailing list apnic-talk at lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-talk From owen at delong.com Mon Apr 18 18:10:44 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Apr 2011 16:10:44 -0700 Subject: IPv4 address exchange In-Reply-To: <20110418155709.3785099F@resin16.mta.everyone.net> References: <20110418155709.3785099F@resin16.mta.everyone.net> Message-ID: <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> Yes... See ARIN NRPM 8.3 and Simplified Transfer Listing Service (STLS). http://www.arin.net If you want to see changes to these, suggest submitting policy via ARIN PPML or suggestions via the ARIN Consultation and Suggestion Process (ACSP). Both are documented at the above web site. Owen On Apr 18, 2011, at 3:57 PM, Scott Weeks wrote: > > > Has this been discussed here? I did a quickie search and saw nothing. Other than spam to a technical mailing list, do you guys care, or is it a non-issue? > > scott > > > > --- Begin forwarded message: > > From: "Martin v. L?wis" > To: apnic-talk at lists.apnic.net > Subject: [apnic-talk] IPv4 address exchange > Date: Mon, 18 Apr 2011 22:07:59 +0200 > > With the address pool exhausted in APNIC for regular allocations, > service providers will need a way to acquire additional address blocks > for deployment; by discovering resources that are currently unused > (or can be released by the current user with sufficient effort). > > In order to promote such address transfers, we are offering the > Asia-Pacific region a platform, at > > http://tradeipv4.com/ > > While this platform is designed to ultimately allow transfer of > addresses within and across all regions of the world, we expect > that interest within the APNIC community will be largest, hence > this announcement. > > Kind regards, > Martin v. L?wis > _______________________________________________ > apnic-talk mailing list > apnic-talk at lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/apnic-talk > > > > From drc at virtualized.org Mon Apr 18 18:20:04 2011 From: drc at virtualized.org (David Conrad) Date: Mon, 18 Apr 2011 16:20:04 -0700 Subject: IPv4 address exchange In-Reply-To: <20110418155709.3785099F@resin16.mta.everyone.net> References: <20110418155709.3785099F@resin16.mta.everyone.net> Message-ID: <3837F4B3-6834-48C5-B737-70C8FF477C62@virtualized.org> On Apr 18, 2011, at 3:57 PM, Scott Weeks wrote: > Has this been discussed here? Not yet for this particular instance. > I did a quickie search and saw nothing. Other than spam to a technical mailing list, do you guys care, or is it a non-issue? Unfortunately, it's an issue. It's a painfully obvious outcome of the laws of supply and demand and the inability of the RIRs to effectively evolve to meet the changing environment. As with any disruptive event (which the exhaustion of the IPv4 free pool clearly is), there will be a bit of chaos as things settle down into new patterns. On the positive side, I figure it means it will be more likely that allocated-but-unused IPv4 address space will be put back into play (since there is now a financial incentive to do so). An explicit cost for obtaining IPv4 should also help justify IPv6 deployment (since the (fixed) cost of IPv6 deployment will be able to be compared against the unpredictable but likely increasing cost of obtaining IPv4 addresses). Operationally, there are concerns, specifically how ISPs determine whether the addresses presented to them are owned by the presenter (if they care), but I understand that's already a problem (as demonstrated by Ron's postings). Interesting times. Regards, -drc From drc at virtualized.org Mon Apr 18 18:33:11 2011 From: drc at virtualized.org (David Conrad) Date: Mon, 18 Apr 2011 16:33:11 -0700 Subject: IPv4 address exchange In-Reply-To: <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> Message-ID: On Apr 18, 2011, at 4:10 PM, Owen DeLong wrote: > Yes... See ARIN NRPM 8.3 and Simplified Transfer Listing Service (STLS). ARIN allows the listing of non-ARIN blocks on their listing service? Also, doesn't the Microsoft-Nortel transaction violate NPRM 8.3 in that according to the court documents I've seen, Microsoft appears to have signed an LRSA (not an RSA as would seem to be required by the NPRM and as mentioned on ARIN's press release) and there doesn't appear to be anything suggesting Nortel entered into any agreement with ARIN (RSA or LRSA, however I will admit I haven't looked too closely)? > If you want to see changes to these, suggest submitting policy via ARIN PPML > or suggestions via the ARIN Consultation and Suggestion Process (ACSP). As far as I can tell, the participants in ARIN's processes are more interested in trying to be a regulator than in being a registry. Given ARIN is not a government body and it does not have full buy-in from those who they would try to regulate, I suspect this will directly result in a proliferation of folks like tradeipv4.com, depository.net, etc. Unfortunately, I figure this will have negative repercussions for network operations (unless someone steps in and provides a definitive "address titles registry"). Regards, -drc From bensons at queuefull.net Mon Apr 18 19:03:15 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Mon, 18 Apr 2011 19:03:15 -0500 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> Message-ID: <3754AD69-B30F-4ABB-A0AC-E537372C902B@queuefull.net> On Apr 18, 2011, at 6:33 PM, David Conrad wrote: > Also, doesn't the Microsoft-Nortel transaction violate NPRM 8.3 in that according to the court documents I've seen, John Curran has stated unambiguously (on the ARIN PPML mailing list) that NRPM policy *was* followed. While I may disagree, at present I'm rather focused on understanding how he interprets and implements this policy. Here are my understandings at this time: > Microsoft appears to have signed an LRSA (not an RSA as would seem to be required by the NPRM and as mentioned on ARIN's press release) Court documents show that "a LRSA" has been agreed rather than "the RSA". As you point out, the actual text of NRPM requires RSA. Thus I assume that ARIN staff procedure will accept any form of RSA as satisfying this requirement, including the standard LRSA or a negotiated LRSA. (This latter possibility makes me wonder about what MSFT actually agreed to, in their version of the LRSA, and whether it will be fairly offered to all parties...) > and there doesn't appear to be anything suggesting Nortel entered into any agreement with ARIN (RSA or LRSA, however I will admit I haven't looked too closely)? The court documents do not indicate that Nortel has agreed anything with ARIN. This brings to question, how were the blocks "released" to ARIN for transfer? In answer, John Curran has stated that the court filings satisfy this requirement without any further agreement with Nortel. Thus I assume that ARIN will accept any legal document confirming ownership and the desire to transfer. There is another aspect of NRPM 8.3 (specified transfer policy) that appears, to an outside observer, to have been ignored by this Nortel/Microsoft transfer: needs justification. However, John Curran has stated that it did occur. Somehow, according to him, Microsoft has demonstrated a need for 666,624 IPv4 addresses in the form of the exact block(s) that are being transferred. (For what it's worth, I think "needs justification" is bad policy for a market. My only concern here is whether ARIN follows community developed policy, as John says they have.) Cheers, -Benson From bensons at queuefull.net Mon Apr 18 19:12:17 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Mon, 18 Apr 2011 19:12:17 -0500 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> Message-ID: <97B23376-3BC0-49C7-BE8D-C7C06EB0FABC@queuefull.net> On Apr 18, 2011, at 6:33 PM, David Conrad wrote: > As far as I can tell, the participants in ARIN's processes are more interested in trying to be a regulator than in being a registry. Given ARIN is not a government body and it does not have full buy-in from those who they would try to regulate, I suspect this will directly result in a proliferation of folks like tradeipv4.com, depository.net, etc. Unfortunately, I figure this will have negative repercussions for network operations (unless someone steps in and provides a definitive "address titles registry"). I agree completely with this concern. Against good advice of friends (who said I would be wasting my time), I tried to do something about it: I introduced several policy proposals to ARIN that deal with the question of authority and ownership. At John Curran's advice, the ARIN Advisory Council abandoned my proposals. Two of them are now in "petition" for further discussion, including ARIN-prop-134 which outlines how to identify a "legitimate address holder" and ARIN-prop-136 which allows a Legacy holder to "opt-out" of ARIN's services. The idea is to make it possible for legacy holders (who don't have a contract with ARIN) to disarm ARIN's whois weapon. If anybody on NANOG supports these concepts, please express your support to PPML so that the proposals can move forward. Please see these links for more info: > http://lists.arin.net/pipermail/arin-ppml/2011-April/020604.html > http://lists.arin.net/pipermail/arin-ppml/2011-April/020605.html Cheers, -Benson From owen at delong.com Mon Apr 18 19:25:20 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Apr 2011 17:25:20 -0700 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> Message-ID: <1D882C3E-CBF5-4D22-93D1-AD8478968D9E@delong.com> On Apr 18, 2011, at 4:33 PM, David Conrad wrote: > On Apr 18, 2011, at 4:10 PM, Owen DeLong wrote: >> Yes... See ARIN NRPM 8.3 and Simplified Transfer Listing Service (STLS). > > ARIN allows the listing of non-ARIN blocks on their listing service? > No. If you're talking about inter-RIR transfers, then, that would be subject to draft policy 2011-1 which was reviewed at the recent Public Policy meeting in San Juan, PR and will be discussed by the AC again in May. > Also, doesn't the Microsoft-Nortel transaction violate NPRM 8.3 in that according to the court documents I've seen, Microsoft appears to have signed an LRSA (not an RSA as would seem to be required by the NPRM and as mentioned on ARIN's press release) and there doesn't appear to be anything suggesting Nortel entered into any agreement with ARIN (RSA or LRSA, however I will admit I haven't looked too closely)? > At the request of counsel, I am not going to comment on this. I do not have enough data available to me at this time to make any such judgment one way or the other. >> If you want to see changes to these, suggest submitting policy via ARIN PPML >> or suggestions via the ARIN Consultation and Suggestion Process (ACSP). > > As far as I can tell, the participants in ARIN's processes are more interested in trying to be a regulator than in being a registry. Given ARIN is not a government body and it does not have full buy-in from those who they would try to regulate, I suspect this will directly result in a proliferation of folks like tradeipv4.com, depository.net, etc. Unfortunately, I figure this will have negative repercussions for network operations (unless someone steps in and provides a definitive "address titles registry"). > We have, on multiple occasions agreed to disagree about this, so, it should not come as a surprise that I continue to disagree with you. Owen From owen at delong.com Mon Apr 18 19:59:13 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Apr 2011 17:59:13 -0700 Subject: IPv4 address exchange In-Reply-To: <97B23376-3BC0-49C7-BE8D-C7C06EB0FABC@queuefull.net> References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <97B23376-3BC0-49C7-BE8D-C7C06EB0FABC@queuefull.net> Message-ID: <0029F32A-D4A1-457A-97DD-160546781EA4@delong.com> > > At John Curran's advice, the ARIN Advisory Council abandoned my proposals. Two of them are now in "petition" for further discussion, including ARIN-prop-134 which outlines how to identify a "legitimate address holder" and ARIN-prop-136 which allows a Legacy holder to "opt-out" of ARIN's services. The idea is to make it possible for legacy holders (who don't have a contract with ARIN) to disarm ARIN's whois weapon. > I don't agree with this characterization of our actions. I did not feel that John Curran advised us to act in any particular direction. Yes, he did raise some concerns about the outcome of the policy proposals being adopted, but, many of us already had those concerns in mind before John said anything. I believe that if the AC felt that your proposals were in the best interests of the community and/or had the broad support of the community, we would have placed them on the docket with or without the concerns expressed by Mr. Curran. I am speaking here only of my own personal perspective, but, I can assure you that my vote in favor of abandoning your proposals was based entirely on the lack of community support for the proposals and the nature of the proposals themselves being contrary to what I believed was the good of the community. Owen From jsw at inconcepts.biz Mon Apr 18 20:15:25 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Mon, 18 Apr 2011 21:15:25 -0400 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> Message-ID: On Mon, Apr 18, 2011 at 7:33 PM, David Conrad wrote: > [ARIN] does not have full buy-in from those who they would try to regulate ARIN has all the buy-in they need: No transit network will (except by act of omission/mistake) allow you to announce IPs that aren't registered to you in an RIR database, or delegated to you by the registrant of those IPs. I am unapologetic when it comes to ARIN. They are very bad at a lot of things, and they allow themselves to be railroaded by organizations that have out-sized budgets / influence (see my post a few years ago regarding Verizon Wireless.) My list of "ARIN gripes" is as long as the day, but I'll spare you the details. If we didn't have ARIN, we would probably have one of two things: 1) no "regulator" at all, thus BGP anarchy (we came surprisingly close to that in the 1990s at least once) 2) a worse "regulator" who is totally uninterested in the small ISP / hosting shop / Fortune 50,000, as opposed to the Fortune 500 If ARIN's primary benefit to us is to protect us from these two unarguably worse evils, they are doing a fine job. Even from my outsider's perspective, I understand that ARIN is sometimes forced to make significant compromises, which we may find objectionable, to prevent us from being truly thrown to the wolves. Would I like ARIN to function better? Sure, in plenty of ways. I do not think it would function better if it were "just a WHOIS database." -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From david at davidswafford.com Mon Apr 18 20:25:05 2011 From: david at davidswafford.com (David Swafford) Date: Mon, 18 Apr 2011 21:25:05 -0400 Subject: eigrp set next hop In-Reply-To: References: Message-ID: What's the real goal behind this? What your describing sounds like a horrible band-aid.... David. On Mon, Apr 18, 2011 at 5:08 PM, Andrey Khomyakov < khomyakov.andrey at gmail.com> wrote: > Hi nanog > > I need to advertise EIGRP route with a different next-hop value than self > > Due to how the connections are setup, I have to run BGP between two peers > that are 3 hops away from each other. > > router1--router2--firewall--router3 > I'm running EBGP between router1 and router3 > router1 is redistributing into EIGRP that's running with router2 > > The problem is that now router2 thinks that router3 routes are reachable > via > router1 so I have myself a route loop. > > Is there a way to advertise an EIGRP route with next hop of router3 (or > firewall for that matter) rather than router1 which is what EIGRP does by > default > > Thank you in advance for advice. > > -- > Andrey Khomyakov > [khomyakov.andrey at gmail.com] > From randy at psg.com Mon Apr 18 21:20:08 2011 From: randy at psg.com (Randy Bush) Date: Tue, 19 Apr 2011 11:20:08 +0900 Subject: IPv4 address exchange In-Reply-To: <97B23376-3BC0-49C7-BE8D-C7C06EB0FABC@queuefull.net> References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <97B23376-3BC0-49C7-BE8D-C7C06EB0FABC@queuefull.net> Message-ID: > I introduced several policy proposals to ARIN that deal with the > question of authority and ownership. > ... > If anybody on NANOG supports these concepts, please express your > support to PPML so that the proposals can move forward. perhaps, if you are seeking support for commercial activity, you should make your employment more clear and declare any conflicts of interest. randy From drc at virtualized.org Mon Apr 18 21:35:34 2011 From: drc at virtualized.org (David Conrad) Date: Mon, 18 Apr 2011 19:35:34 -0700 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> Message-ID: <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> Jeff, On Apr 18, 2011, at 6:15 PM, Jeff Wheeler wrote: > ARIN has all the buy-in they need: No transit network will (except by > act of omission/mistake) allow you to announce IPs that aren't > registered to you in an RIR database, or delegated to you by the > registrant of those IPs. And yet, Ron has recently raged on this list about hijacked prefixes used for spamming, so clearly "no transit network" is inaccurate. Regardless, for sake of argument, let's assume ARIN refused to recognize the Microsoft/Nortel sale and Microsoft deploys a few prefixes of those 666K addresses for (say) new MSN services. Do you think ISPs, particularly the larger ones, all over the world would refuse to accept those announcements (especially when their call centers start getting calls from irate customers who aren't able to gain access to MSN services)? > If we didn't have ARIN, we would probably have one of two things: Just to be clear, I don't believe the suggestion is that ARIN goes away, rather that "post allocation services" (e.g., reverse DNS, registration maintenance, etc.) for IPv4 no longer be a geographical monopoly. However, taking the bait: > 1) no "regulator" at all, thus BGP anarchy (we came surprisingly close to that in the 1990s at least once) And the solution to that "BGP anarchy" (by which I assume you mean a flood of long prefixes) in the 1990s was some ISPs deploying prefix length filters to protect their own infrastructures. Been there, got several t-shirts. Yes, over time, the sales/marketing folks will force the network engineers to remove the filters once hardware has been upgraded, but once established, minimum prefix lengths (at least the perception of them) seem to have a long half-life. It's also true that ARIN (at least currently, before RPKI is deployed) has no control over routing policy so suggesting that they regulate BGP anarchy may not be accurate. > 2) a worse "regulator" who is totally uninterested in the small ISP / hosting shop / Fortune 50,000, as opposed to the Fortune 500 We're talking about IPv4 addresses which will (soon) be unavailable from the RIRs because the free pool has been exhausted. The small ISP/hosting shop/Fortune 50,000 who have not already taken steps to adjust to this new reality will simply be screwed regardless of what ARIN or the other RIRs do. Even if alternative "post allocation services" providers didn't exist, the Fortune 500 are going to be able to pay more to the folks with allocated-but-unused addresses than the 'all but Fortune 500' and I have no doubt that the Fortune 500 will be able to justify "need" (to any level of detail) just as well as the 'all but Fortune 500'. Or do you believe ARIN et al. will be establishing price caps and establishing who among the various requesters for the same block deserves to get the SLS seller's blocks? What a bunch of folks seem to have gotten their panties in a bunch about is the idea that without our Benevolent RIR Overlords, Enron-wannabes are going to go around and buy up all the unused IPv4 address space and make a killing selling it to the highest bidder. I'm afraid I haven't been able to get worked up about this: the only difference between the world with the BRO and without I can see is who gets the money (and this is ignoring the debate as to whether speculators can encourage bringing more addresses into play since their sitting on lost opportunity cost of they simply hoard IPv4 addresses). I find the whole discussion quite odd: laws of economics are pretty clear about situations with limited supply and increased demand and the reality is that ARIN is not a regulator and has essentially no enforcement mechanisms outside of contractual relationships. It is a 501(c)(6) consisting of 3865 members, of which a couple of hundred technical folks participate in policy definition processes that affect tens of millions of people, the vast majority of which have never heard of ARIN. As long as the policies ARIN defined by the technical folk don't affect folks with money/power in negative ways, everything is fine. That time is just about over. People really need to adjust. > I do not think it would function better if it were "just a WHOIS database." To try to bring this back to NANOG (instead of PPML-light), the issue is that since at least two alternative registries have apparently been established, how are network operators going to deal with the fact that the currently execrable "whois database" is almost certainly going to get worse? Regards, -drc From bensons at queuefull.net Mon Apr 18 21:40:29 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Mon, 18 Apr 2011 21:40:29 -0500 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <97B23376-3BC0-49C7-BE8D-C7C06EB0FABC@queuefull.net> Message-ID: Hi, Randy. On Apr 18, 2011, at 9:20 PM, Randy Bush wrote: >> I introduced several policy proposals to ARIN that deal with the >> question of authority and ownership. >> ... >> If anybody on NANOG supports these concepts, please express your >> support to PPML so that the proposals can move forward. > > perhaps, if you are seeking support for commercial activity, you should > make your employment more clear and declare any conflicts of interest. Fair enough. I am employed by Cisco Systems, but all of my statements are my own and I do not represent my employer. I believe that my employer may benefit from any policy that makes IP addresses more available to more of our customers - we can perhaps sell more routers if more people have addresses - but nobody from Cisco has encouraged me to work in this topic. Otherwise, I have no commercial interest in the outcome of the policy proposals that I've made. The proposals that I've put forward are an honest attempt to motivate conversation. If anybody has any doubts and/or I can clarify anything about my interests, let me know. Cheers, -Benson From matt.newsom at RACKSPACE.COM Mon Apr 18 21:43:23 2011 From: matt.newsom at RACKSPACE.COM (Matt Newsom) Date: Tue, 19 Apr 2011 02:43:23 +0000 Subject: eigrp set next hop In-Reply-To: References: , Message-ID: <15681_1303181009_p3J2hOIY024956_498294AE-E3A5-45BC-8F5F-D3275EF20D42@RACKSPACE.COM> How many bgp prefixes do you have? Can you just put statics on router 2? On Apr 18, 2011, at 8:26 PM, "David Swafford" wrote: > What's the real goal behind this? What your describing sounds like a > horrible band-aid.... > > David. > > On Mon, Apr 18, 2011 at 5:08 PM, Andrey Khomyakov < > khomyakov.andrey at gmail.com> wrote: > >> Hi nanog >> >> I need to advertise EIGRP route with a different next-hop value than self >> >> Due to how the connections are setup, I have to run BGP between two peers >> that are 3 hops away from each other. >> >> router1--router2--firewall--router3 >> I'm running EBGP between router1 and router3 >> router1 is redistributing into EIGRP that's running with router2 >> >> The problem is that now router2 thinks that router3 routes are reachable >> via >> router1 so I have myself a route loop. >> >> Is there a way to advertise an EIGRP route with next hop of router3 (or >> firewall for that matter) rather than router1 which is what EIGRP does by >> default >> >> Thank you in advance for advice. >> >> -- >> Andrey Khomyakov >> [khomyakov.andrey at gmail.com] >> Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From khomyakov.andrey at gmail.com Mon Apr 18 21:57:39 2011 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Mon, 18 Apr 2011 22:57:39 -0400 Subject: eigrp set next hop In-Reply-To: References: Message-ID: The goal is to withdraw the prefixes should any part of the connection go down. Unfortunately router1--router2--firewall is part of a production setup and not easily changed. The idea is really to have something like this (ideally without router2): router1-router2-firewall-router3 | | router4-firewall-router5 I just wanted to check if I'm missing some knowledge about redistributing BGP into EIGRP. It appears that there is really no way to manipulate next-hop value. (no ip next-hop-self eigrp 1 is not really an option because there are many more prefixes coming from other routers that are being redistributed to router2 from router1) I will see if the network will allow BGP on router2. That seems to be the only clean solution for this. On Mon, Apr 18, 2011 at 9:25 PM, David Swafford wrote: > What's the real goal behind this? What your describing sounds like a > horrible band-aid.... > > David. > > > On Mon, Apr 18, 2011 at 5:08 PM, Andrey Khomyakov < > khomyakov.andrey at gmail.com> wrote: > >> Hi nanog >> >> I need to advertise EIGRP route with a different next-hop value than self >> >> Due to how the connections are setup, I have to run BGP between two peers >> that are 3 hops away from each other. >> >> router1--router2--firewall--router3 >> I'm running EBGP between router1 and router3 >> router1 is redistributing into EIGRP that's running with router2 >> >> The problem is that now router2 thinks that router3 routes are reachable >> via >> router1 so I have myself a route loop. >> >> Is there a way to advertise an EIGRP route with next hop of router3 (or >> firewall for that matter) rather than router1 which is what EIGRP does by >> default >> >> Thank you in advance for advice. >> >> -- >> Andrey Khomyakov >> [khomyakov.andrey at gmail.com] >> > > -- Andrey Khomyakov [khomyakov.andrey at gmail.com] From rubensk at gmail.com Mon Apr 18 22:06:10 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 19 Apr 2011 00:06:10 -0300 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <97B23376-3BC0-49C7-BE8D-C7C06EB0FABC@queuefull.net> Message-ID: >> perhaps, if you are seeking support for commercial activity, you should >> make your employment more clear and declare any conflicts of interest. > > Fair enough. > > I am employed by Cisco Systems, but all of my statements are my own and I do not represent my employer. ?I believe that my employer may benefit from any policy that makes IP addresses more available to more of our customers - we can perhaps sell more routers if more people have addresses - but nobody from Cisco has encouraged me to work in this topic. ?Otherwise, I have no commercial interest in the outcome of the policy proposals that I've made. ?The proposals that I've put forward are an honest attempt to motivate conversation. > On the contrary, I believe router vendors including but not limited to Cisco benefits more from IPv4 address exhaustion, as it's an opportunity to sell new gear that can do hardware forwarding of IPv6 packets, or sell software upgrades to CPU-based platforms (either due to lack of IPv6 altogether or lack of support of newer IPv6 features). That doesn't mean that router vendors are promoting address exhaustion chaos to get new business. That would be a nice conspiracy theory, though... Rubens From randy at psg.com Mon Apr 18 22:08:51 2011 From: randy at psg.com (Randy Bush) Date: Tue, 19 Apr 2011 12:08:51 +0900 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <97B23376-3BC0-49C7-BE8D-C7C06EB0FABC@queuefull.net> Message-ID: > If anybody has any doubts and/or I can clarify anything about my > interests, let me know. could you please clarify your relationship to depository.com? randy From bensons at queuefull.net Mon Apr 18 22:16:08 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Mon, 18 Apr 2011 22:16:08 -0500 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <97B23376-3BC0-49C7-BE8D-C7C06EB0FABC@queuefull.net> Message-ID: <7DBBB6F4-3362-4EEB-875E-B45A7FCE6DEC@queuefull.net> On Apr 18, 2011, at 10:08 PM, Randy Bush wrote: >> If anybody has any doubts and/or I can clarify anything about my >> interests, let me know. > > could you please clarify your relationship to depository.com? I know some of the people involved in Depository, and I have spoken with them about what they're trying to do. I might go so far as to call some of them friends. But to my knowledge I have no formal relationship with Depository or any affiliated company. Cheers, -Benson From jsw at inconcepts.biz Mon Apr 18 22:47:31 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Mon, 18 Apr 2011 23:47:31 -0400 Subject: IPv4 address exchange In-Reply-To: <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> Message-ID: On Mon, Apr 18, 2011 at 10:35 PM, David Conrad wrote: > And yet, Ron has recently raged on this list about hijacked prefixes used for spamming, so clearly "no transit network" is inaccurate. I try to qualify my remarks when necessary. In this case, I wrote "except by act of omission/mistake," and you evidently did not read that carefully, or have construed "transit network" to mean any two-bit ISP with one BGP customer (or shell company downstream of them), rather than serious, global networks. > Regardless, for sake of argument, let's assume ARIN refused to recognize the Microsoft/Nortel sale and Microsoft deploys a few prefixes of those 666K addresses for (say) new MSN services. Do you think ISPs, particularly the larger ones, all over the world would refuse to accept those announcements (especially when their call centers start getting calls from irate customers who aren't able to gain access to MSN services)? ARIN has very carefully allowed our industry to largely avoid this choice, as InterNIC did before. Their methods have sometimes been objectionable, but the devil we know is better than the devil we don't. >> 1) no "regulator" at all, thus BGP anarchy (we came surprisingly close to that in the 1990s at least once) > > And the solution to that "BGP anarchy" (by which I assume you mean a flood of long prefixes) No, I mean if ARIN had lost its perceived or actual legitimacy, and networks really were able to "permanently hijack" whatever IPs they decided to claim for themselves, we would have had anarchy at worst, or more likely, transit-free ISPs with commercial interest in customers not having portable address space controlling all allocations of portable addresses. This almost happened. > We're talking about IPv4 addresses which will (soon) be unavailable I'm not confused about that. If it were up to me, I would simply freeze all IPv4 allocations immediately. I do not think the current sale-and-transfer scheme is good. I also don't *care* that much, because the more screwed up the "legacy IPv4 Internet" becomes, and the faster it gets there, the better it is for my business. I'm pretty sure I am not alone in this thinking. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From cgrundemann at gmail.com Mon Apr 18 22:50:44 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 18 Apr 2011 21:50:44 -0600 Subject: IPv4 address exchange In-Reply-To: <0029F32A-D4A1-457A-97DD-160546781EA4@delong.com> References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <97B23376-3BC0-49C7-BE8D-C7C06EB0FABC@queuefull.net> <0029F32A-D4A1-457A-97DD-160546781EA4@delong.com> Message-ID: On Mon, Apr 18, 2011 at 18:59, Owen DeLong wrote: >> >> At John Curran's advice, the ARIN Advisory Council abandoned my proposals. ?Two of them are now in "petition" for further discussion, including ARIN-prop-134 which outlines how to identify a "legitimate address holder" and ARIN-prop-136 which allows a Legacy holder to "opt-out" of ARIN's services. ?The idea is to make it possible for legacy holders (who don't have a contract with ARIN) to disarm ARIN's whois weapon. >> > I don't agree with this characterization of our actions. Nor do I. Those that wish to understand the ARIN Advisory Council's actions in earnest can find the results of the AC meeting in question here: [http://lists.arin.net/pipermail/arin-ppml/2011-March/020373.html] and the minutes from that meeting, here: [https://www.arin.net/about_us/ac/ac2011_0317.html]. You are also welcome to ping me off-list (or on arin-ppml) if you are interested in a further explanation of my own reasons for voting to abandon the proposals in question. Cheers, ~Chris > I did not feel that John Curran advised us to act in any particular direction. Yes, he did raise some concerns > about the outcome of the policy proposals being adopted, but, many of us already had those concerns in > mind before John said anything. > > I believe that if the AC felt that your proposals were in the best interests of the community and/or had the > broad support of the community, we would have placed them on the docket with or without the concerns > expressed by Mr. Curran. > > I am speaking here only of my own personal perspective, but, I can assure you that my vote in favor > of abandoning your proposals was based entirely on the lack of community support for the proposals > and the nature of the proposals themselves being contrary to what I believed was the good of the > community. > > Owen > > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From jcdill.lists at gmail.com Mon Apr 18 23:35:19 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Mon, 18 Apr 2011 21:35:19 -0700 Subject: 365x24x7 In-Reply-To: References: Message-ID: <4DAD1107.6020201@gmail.com> On 15/04/11 6:14 AM, harbor235 wrote: > If I were going to provide a 365x24x7 NOC, how many teams of personnel do I > need > to fully cover operations? I assume minimally you need 3 teams to cover the > required > 24 hr coverage, but there is off time and schedule rotation? > > thoughts, experience? There have been a lot of comments that talk about the operational issues, and about how well it works or doesn't work to rotate schedules. In my experience, the most important thing to do is to decide how you are going to setup the schedules BEFORE you hire. Then advertise for the exact work schedule(s) you need to fill, and pay an appropriate shift differential so that you get people who are happy to work the worst shifts for slightly better pay. People don't like being treated like slaves, expected to just shut up and work a crappy schedule. You will have a much more reliable team if you treat the staff like valued members of your company, don't try to trick them or over work them, or expect them to disrupt their lives over and over as your shifts change. Some people are naturally night-owls - find them and hire THEM for the swing and night shifts. Also, don't forget that your 24x7x365 staff will have to work holidays, and be sure to work in an appropriate holiday bonus pay schedule as well. Otherwise expect to eventually have a bad case of the blue flu someday and end up having to call managers (directors/ VPs, YOU) away from their holiday with their family to keep your NOC staffed. jc From nonobvious at gmail.com Mon Apr 18 23:37:51 2011 From: nonobvious at gmail.com (Bill Stewart) Date: Mon, 18 Apr 2011 21:37:51 -0700 Subject: 365x24x7 In-Reply-To: <23204495.2659.1303052443474.JavaMail.root@benjamin.baylink.com> References: <23204495.2659.1303052443474.JavaMail.root@benjamin.baylink.com> Message-ID: On Sun, Apr 17, 2011 at 8:00 AM, Jay Ashworth wrote: > The TV master control facility in which I'm working presently does it > by doing overlapping 10 hour shifts; it takes 10 people to have 2 on-shift > at all times. ?You work 6 hours with one person, and 4 with the other. My brother-in-law once had a job tending a TV relay station; the shift was drive up the mountain, work 48 hours, drive back, but unless something was broken he only had to read meters every three hours and could nap in between. ---- ? ? ? ? ? ?? Thanks;? ?? Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From rzheng at gmail.com Tue Apr 19 01:58:45 2011 From: rzheng at gmail.com (Richard Zheng) Date: Mon, 18 Apr 2011 20:58:45 -1000 Subject: NEBS compliant Server Message-ID: Hi, We are looking for some NEBS compliant servers. What do you use for DC powered servers colocated in CO? Thanks, Richard From ml at kenweb.org Tue Apr 19 05:30:10 2011 From: ml at kenweb.org (ML) Date: Tue, 19 Apr 2011 06:30:10 -0400 Subject: Easily confused... In-Reply-To: <20110418115356.3A69747F@resin06.mta.everyone.net> References: <20110418115356.3A69747F@resin06.mta.everyone.net> Message-ID: <4DAD6432.2050709@kenweb.org> On 4/18/2011 2:53 PM, Scott Weeks wrote: > ----------------------------------------------------------- >> They are testing IPTV on Oahu in preperation for roll-out, so maybe they >> renumbered in order to more easily identify the segments.(?) > > Really, I'd have hoped they'd use their two-year-old 2607:f9a0::/32 > for anything that ambitious...but I might be wishing for too much. > (Also, that 123 block seems to have been allocated in 2006, so it'd be > even more unprofessional to start projects with that space since then.) > -------------------------------------------------------- > > I'm the one that got this space for them, but allocation of folks to IPv6 roll out was minimal due the the upcoming IPTV roll out. I was the lone IPv6 voice in the company for a long time, but when I left there was gaining interest in IPv6 strategies. Not enough netgeeks and too many projects rolling out. > > scott With the crudiness of the IPTV middleware aimed for smaller deployments, I'd expect nothing less than blank stares if you mention IPv6 multicast. Not to mention it would probably not work for 5 years. From jcurran at istaff.org Tue Apr 19 05:46:49 2011 From: jcurran at istaff.org (John Curran) Date: Tue, 19 Apr 2011 06:46:49 -0400 Subject: IPv4 address exchange In-Reply-To: <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> Message-ID: <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> On Apr 18, 2011, at 10:35 PM, David Conrad wrote: > To try to bring this back to NANOG (instead of PPML-light), the issue is that since at least two alternative registries have apparently been established, how are network operators going to deal with the fact that the currently execrable "whois database" is almost certainly going to get worse? David - Does it have to get worse simply because there is change? I see no particular reason that the Internet number registry system can't evolve into something with multiple registries including overlapping service regions and competition if that's what folks actually want. We've seen this in the DNS space and I can't say that it necessarily worse or better than what resulted from the prior single registry model. However, it's definitely true that what occurred in the DNS space is clearly documented, has a complete fabric of contractual agreements, and was part of a multi-year discussion regarding goals of the overall system and various proposals on how it should best change. Now, Internet number resources are different in many ways, including the fact that network operators must have reliable access to the information in order to keep things running. Registrants may have exclusive use of their numbers, but the network operators also have a right to know the registration of any given piece of address space. As you know, multiple IP registries would definitely pose some coordination challenges in being able to reliably account for all of the address space at any given moment. What we lack is any meaningful proposals on how to restructure the Internet number registry system, including what are the goals of doing such, how are those goals and the existing requirements are met, and what protections are needed for integrity of the system. It's possible if this were discussed by the global community, it might be obvious how to best proceed or not. Personally, I do not see it as inevitable that "alternative registries" must have a detrimental impact to the WHOIS database, unless they are introduced in an uncoordinated manner and without global discussion of the actual goals. /John From jra at baylink.com Tue Apr 19 08:23:53 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 19 Apr 2011 09:23:53 -0400 (EDT) Subject: NEBS compliant Server In-Reply-To: Message-ID: <29911217.2823.1303219433626.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Richard Zheng" > We are looking for some NEBS compliant servers. What do you use for DC > powered servers colocated in CO? Do you need NEBS *compliant*, or NEBS *certified* servers? 19" or 23"? -48V isn't hard to come by; lots of people make power supplies for that. They tend to cost 3-4 times what 120V ones do... Cheers, -- jra From luigi at net.t-labs.tu-berlin.de Tue Apr 19 10:30:58 2011 From: luigi at net.t-labs.tu-berlin.de (Luigi Iannone) Date: Tue, 19 Apr 2011 17:30:58 +0200 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: References: <4D9D8365.9060202@optilian.com> <64391E30-977A-4730-AFFB-6F14ED12828E@instituut.net> <4D9F380C.30007@rollernet.us> <3C3276EF-C012-4167-97D4-C482F68B586D@delong.com> <4D9F470E.6040904@ac.upc.edu> <58B0B53C-39B1-4D8B-BAB2-C791D5DE5D9C@instituut.net> <759FF622-AE3D-419F-952D-416BD0E99594@delong.com> <3065A2EB-804F-452C-A21D-0E0A0994C506@net.t-labs.tu-berlin.de> <61FCD6EF-FB57-4835-980D-4BF0CB1F32D7@delong.com> <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> <768DDE65-C091-4A48-97E4-92F3E51D6042@net.t-labs.tu-berlin.de> <4DAC8673.50709! 06@bromirski.net> Message-ID: <8E78D538-1918-47BC-A79E-7866B00D6E30@net.t-labs.tu-berlin.de> On Apr 18, 2011, at 10:09 PM, Owen DeLong wrote: > > On Apr 18, 2011, at 12:18 PM, Jeff Wheeler wrote: > >> 2011/4/18 Lukasz Bromirski : >>> LISP scales better, because with introduction of *location* >>> prefix, you're at the same time (or ideally you would) >>> withdraw the original aggregate prefix. And as no matter how >>> you count it, the number of *locations* will be somewhat >>> limited vs number of *PI* address spaces that everyone wants >> >> I strongly disagree with the assumption that the number of >> locations/sites would remain static. This is the basic issue that >> many folks gloss over: dramatically decreasing the barrier-to-entry >> for multi-homing or provider-independent addressing will, without >> question, dramatically increase the number of multi-homed or >> provider-independent sites. >> > Done properly, a multi-homed end-site does not need to have > its own locator ID, but, could, instead, use the locator IDs of > all directly proximate Transit ASNs. > This is exactly what LISP suggests. Your locators are provided by your provider. Luigi > I don't know if LISP particularly facilitates this, but, I think it > would be possible generically in a Locator/ID based system. > >> LISP "solves" this problem by using the router's FIB as a >> macro-flow-cache. That's good except that a site with a large number >> of outgoing macro-flows (either because it's a busy site, responding >> to an external DoS attack, or actually originating a DoS attack from a >> compromised host) will cripple that site's ITR. >> > The closer you move the ITRs to the edge, the less of an issue this becomes. >> > > Owen > > > From joelja at bogus.com Tue Apr 19 10:34:05 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 19 Apr 2011 08:34:05 -0700 Subject: Easily confused... In-Reply-To: <4DAD6432.2050709@kenweb.org> References: <20110418115356.3A69747F@resin06.mta.everyone.net> <4DAD6432.2050709@kenweb.org> Message-ID: <4DADAB6D.5090505@bogus.com> On 4/19/11 3:30 AM, ML wrote: > > > With the crudiness of the IPTV middleware aimed for smaller deployments, > I'd expect nothing less than blank stares if you mention IPv6 multicast. > Not to mention it would probably not work for 5 years. NTT's deployment of globally scoped but not internet connected v6 addresses in support v6 multicast has been breaking my v6 connectivity in some residential settings on trips to japan since at least 2007, they appear to have the television part nailed however. From luigi at net.t-labs.tu-berlin.de Tue Apr 19 10:36:05 2011 From: luigi at net.t-labs.tu-berlin.de (Luigi Iannone) Date: Tue, 19 Apr 2011 17:36:05 +0200 Subject: Implementations/suggestions for Multihoming IPv6 for DSL sites In-Reply-To: <20110418195026.GA33393@ussenterprise.ufp.org> References: <8353E89E-90A2-4F08-A774-D8CE24A98066@net.t-labs.tu-berlin.de> <0E79A6C8-E45A-4EC8-92C3-EC7993EF6C4B@delong.com> <6AA59EBF-FCE1-4D04-9F86-171602B9426B@net.t-labs.tu-berlin.de> <4F92E49F-35D3-46F9-9F86-1D2E6D081309@delong.com> <768DDE65-C091-4A48-97E4-92F3E51D6042@net.t-labs.tu-berlin.de> <4DAC8673.5070906@bromirski.net> <20110418195026.GA33393@ussenterprise.ufp.org> Message-ID: <385A3126-3BA0-4F5A-8B8A-A947F58169F5@net.t-labs.tu-berlin.de> On Apr 18, 2011, at 9:50 PM, Leo Bicknell wrote: > > Any edges which talk to a significant number of other networks will > have to cache a significant portion of the Internet, which will > actually lead to edge boxes having to be larger than they are now. > This is not accurate. For networks with more than 20K users you can have a lisp cache as small as 15K entries. (http://www.net.t-labs.tu-berlin.de/research/publications/Publi//KIF-LMDDILCWISKAI-10-eng.html) Luigi From drc at virtualized.org Tue Apr 19 11:16:35 2011 From: drc at virtualized.org (David Conrad) Date: Tue, 19 Apr 2011 09:16:35 -0700 Subject: IPv4 address exchange In-Reply-To: <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> Message-ID: John, On Apr 19, 2011, at 3:46 AM, John Curran wrote: > Does it have to get worse simply because there is change? Have to? No. However, historically, entropy has generally increased. > I see no particular > reason that the Internet number registry system can't evolve into something > with multiple registries including overlapping service regions and competition > if that's what folks actually want. We already have multiple registries, albeit with arbitrary (and increasingly unjustifiable and unsustainable) geographical service area monopolies. This actually points to one of the symptoms of the underlying problem: a near terminal case of NIH syndrome. For example, just for fun, compare/contrast the results of the following 5 commands (to pick a prefix at semi-random): % whois -h whois.afrinic.net 128.8.10.5 % whois -h whois.apnic.net 128.8.10.5 % whois -h whois.arin.net 128.8.10.5 % whois -h whois.lacnic.net 128.8.10.5 % whois -h whois.ripe.net 128.8.10.5 Note the wildly differing response structure/schemas/tags/values/etc. Being objective, doesn't this strike you as insane? Even ignoring the simple brokenness of everybody having their own registry data schema/response, I keep hearing from anti-spam folks, law enforcement, network operators, etc., that the quality of the data actually returned is simply abysmal. And soon, network operators are going to be asked to make routing decisions on this data not just at customer acceptance time. However, as far as I can tell, multiple registries isn't what is implicitly being proposed. What appears to be eing proposed is something a bit like the registry/registrar split, where there is a _single_ IPv4 registry and multiple competing 'post-allocation services' providers. A single registry with a single database schema and data representation would seem to me to be infinitely better than what we have now (and what it looks like we're moving towards). I personally don't have a strong opinion on the competitive address registrar idea as long as there is a consistent set of registration requirements, but in my experience (reasonably regulated) competition tends to bring higher quality/lower prices vs. monopolies. > Registrants may have exclusive use of their > numbers, but the network operators also have a right to know the registration > of any given piece of address space. I'm not sure I see that there should be a difference in the operational requirements for the DNS registration data, but that's a separate topic. > As you know, multiple IP registries > would definitely pose some coordination challenges in being able to reliably > account for all of the address space at any given moment. Which is exactly my point. Given that market forces are driving the establishment of (presumably) competitive "address registrars", of which the first two now apparently exist, how are network operators going to deal with the proliferation of whois databases they're going to need to query to establish 'ownership' of prefixes? > What we lack is any meaningful proposals on how to restructure the Internet > number registry system, including what are the goals of doing such, how are > those goals and the existing requirements are met, and what protections are > needed for integrity of the system. Unfortunately, I suspect we are past the time in which a well thought out, global consultative action (even assuming an agreeable venue for such a consultation can be identified) would result in a plan of action before being overtaken by events. There are already two "address registrars" and at least 5 (6 if you count IANA) address whois databases. I expect there to be more in the future, particularly now there is an existence proof that you can sell addresses and the Internet doesn't explode. Hoever, perhaps I'm being too pessimistic. What venue do you propose for a global consultative action to be taken in an open, transparent, an unbiased manner? > Personally, I do not see it as inevitable that "alternative registries" must > have a detrimental impact to the WHOIS database, unless they are introduced > in an uncoordinated manner and without global discussion of the actual goals. This coming from the CEO of the RIR that decided to come up with their own (and yet another) completely new replacement for the whois protocol (maybe the 5th attempt will be the charm)... Regards, -drc From jcurran at istaff.org Tue Apr 19 11:36:38 2011 From: jcurran at istaff.org (John Curran) Date: Tue, 19 Apr 2011 12:36:38 -0400 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> Message-ID: <1056555D-F387-4D14-8901-D6E2FA3D5994@istaff.org> On Apr 19, 2011, at 12:16 PM, David Conrad wrote: > However, as far as I can tell, multiple registries isn't what is implicitly being proposed. What appears to be eing proposed is something a bit like the registry/registrar split, where there is a _single_ IPv4 registry and multiple competing 'post-allocation services' providers. A single registry with a single database schema and data representation would seem to me to be infinitely better than what we have now (and what it looks like we're moving towards). I personally don't have a strong opinion on the competitive address registrar idea as long as there is a consistent set of registration requirements, but in my experience (reasonably regulated) competition tends to bring higher quality/lower prices vs. monopolies. Alas, you seem to have better perception skills, since I can't find any proposal containing any of what you outlined above. >> What we lack is any meaningful proposals on how to restructure the Internet >> number registry system, including what are the goals of doing such, how are >> those goals and the existing requirements are met, and what protections are >> needed for integrity of the system. > > Unfortunately, I suspect we are past the time in which a well thought out, global consultative action (even assuming an agreeable venue for such a consultation can be identified) would result in a plan of action before being overtaken by events. There are already two "address registrars" and at least 5 (6 if you count IANA) address whois databases. I expect there to be more in the future, particularly now there is an existence proof that you can sell addresses and the Internet doesn't explode. How does transfer of number resources within a region imply additional whois databases? > Hoever, perhaps I'm being too pessimistic. What venue do you propose for a global consultative action to be taken in an open, transparent, an unbiased manner? I've suggested ICANN, IGF, or the RIRs... (I include the last one specifically for Mr. Mueller, since he observed "One comes away with the conviction that the so-called bottom up policymaking .. is actually (more or less) seriously pursued here." and "I really liked the way nearly all ARIN discussions are in plenary and decisions are actually made. " ) FYI, /John From jsw at inconcepts.biz Tue Apr 19 12:19:46 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Tue, 19 Apr 2011 13:19:46 -0400 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> Message-ID: On Tue, Apr 19, 2011 at 12:16 PM, David Conrad wrote: > However, as far as I can tell, multiple registries isn't what is implicitly being proposed. ?What appears to be eing proposed is something a bit like the registry/registrar split, where there is a _single_ IPv4 registry and multiple competing 'post-allocation services' providers. Are you saying there are people who advocate creating a new ecosystem of service providers for supplying several things that the RIRs exclusively supply today? IN-ADDR delegation, WHOIS registration, and ... that's pretty much it, right? People want to separate the DNS and WHOIS database from ARIN and create new businesses to charge new fees for providing that? Sign me up. As a vendor. I'd love to over-charge for the dead simple task of using an API to push DNS delegation updates to the IN-ADDR servers, and running a whois server. What a great business! I'm sure GoDaddy.com would be happy to add this service to their portfolio. Where is the value for stakeholders? If you really want WHOIS output with a common, unified structure, you can do that. Bulk access to RIR data is available today. Maybe I'm missing something, but I don't see how a bunch of different entities providing fragmented "post-allocation services" is of any benefit. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jcurran at arin.net Tue Apr 19 13:37:07 2011 From: jcurran at arin.net (John Curran) Date: Tue, 19 Apr 2011 18:37:07 +0000 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> Message-ID: On Apr 19, 2011, at 1:19 PM, Jeff Wheeler wrote: > Maybe I'm missing something, but I don't see how a bunch of different > entities providing fragmented "post-allocation services" is of any > benefit. Jeff - Imagine for a moment that you had quite a few unneeded addresses and the upheaval also meant no pesky policy constraints on your monetization efforts - would you then view it as having some benefit? You just might not have the right perspective to appreciate the potential up$ide... /John John Curran President and CEO ARIN From jsw at inconcepts.biz Tue Apr 19 14:07:32 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Tue, 19 Apr 2011 15:07:32 -0400 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> Message-ID: On Tue, Apr 19, 2011 at 2:37 PM, John Curran wrote: > ? ?Imagine for a moment that you had quite a few > unneeded addresses and the upheaval also meant > no pesky policy constraints on your monetization efforts - > would you then view it as having some benefit? ?You just > might not have the right perspective to appreciate the > potential up$ide... In this view, then, the "benefit" of independent, fragmented WHOIS databases and API access to IN-ADDR DNS zones is that addresses could be traded outside of RIR policy. It seems to me that RIR policy would need to change to allow such third-party databases to publish delgation data to DNS/WHOIS. Since this is the case, end-user advocates of such system should simply argue in favor of eliminating any justification for transfer recipients. In this case, ARIN would naturally supply the same DNS and WHOIS service they do to allocation-holders today. I still see no tangible benefit to third-party DNS/WHOIS databases, except to the operators of those databases. The up$ide seems to be entirely in favor of new database operators, not existing stakeholders. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From drc at virtualized.org Tue Apr 19 14:29:11 2011 From: drc at virtualized.org (David Conrad) Date: Tue, 19 Apr 2011 12:29:11 -0700 Subject: IPv4 address exchange In-Reply-To: <1056555D-F387-4D14-8901-D6E2FA3D5994@istaff.org> References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> <1056555D-F387-4D14-8901-D6E2FA3D5994@istaff.org> Message-ID: <44826AB7-0CE7-4082-85FE-EF9EAA950362@virtualized.org> John, On Apr 19, 2011, at 9:36 AM, John Curran wrote: >> There are already two "address registrars" and at least 5 (6 if you count IANA) address whois databases. I expect there to be more in the future, particularly now there is an existence proof that you can sell addresses and the Internet doesn't explode. > How does transfer of number resources within a region imply additional whois databases? Hint: Add % whois -h whois.depository.net 128.8.10.5 to the list I provided you in the previous message. Or are you implying that ARIN and the other RIRs are committing to synchronizing their databases with alternative address registrars as they become established? >> What venue do you propose for a global consultative action to be taken in an open, transparent, an unbiased manner? > I've suggested ICANN, IGF, or the RIRs... I find ARIN's new found interests in engaging in ICANN-related processes heartwarming given my past experiences, but I suspect both the ICANN and RIR venues would be somewhat biased against changing the status quo. As for the IGF, my perhaps mistaken perception is that it has a slightly different focus than dealing with the operational implications of the proliferation of alternative address registrars. The main problem is one of timeliness. I doubt the market is going to wait for IGF, ICANN, or even RIR processes. But we'll see. Regards, -drc From drc at virtualized.org Tue Apr 19 14:56:22 2011 From: drc at virtualized.org (David Conrad) Date: Tue, 19 Apr 2011 12:56:22 -0700 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> Message-ID: Jeff, On Apr 19, 2011, at 10:19 AM, Jeff Wheeler wrote: > Are you saying there are people who advocate creating a new ecosystem > of service providers for supplying several things that the RIRs > exclusively supply today? Yes. > Sign me up. As a vendor. I'd love to over-charge for the dead simple > task of using an API to push DNS delegation updates to the IN-ADDR > servers, and running a whois server. My guess is that lacking a monopoly, if you over-charge you won't have many customers. > If you really want WHOIS output > with a common, unified structure, you can do that. Bulk access to RIR > data is available today. So your solution is for everyone interested in a common database structure to download the entirety of all the RIR databases and write code to convert the various (changing) formats into a 'common, unified structure'? In any event, such a use would appear to be in violation of ARIN's Bulk Whois AUP (According to http://www.icann.org/en/correspondence/curran-to-beckstrom-02mar11-en.pdf, ARIN denied bulk whois access for the stated use of "directory mirroring"). > Maybe I'm missing something, but I don't see how a bunch of different > entities providing fragmented "post-allocation services" is of any > benefit. Some folks find competition in service providers beneficial. Regards, -drc From jcurran at arin.net Tue Apr 19 15:07:27 2011 From: jcurran at arin.net (John Curran) Date: Tue, 19 Apr 2011 20:07:27 +0000 Subject: IPv4 address exchange In-Reply-To: <44826AB7-0CE7-4082-85FE-EF9EAA950362@virtualized.org> References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> <1056555D-F387-4D14-8901-D6E2FA3D5994@istaff.org> <44826AB7-0CE7-4082-85FE-EF9EAA950362@virtualized.org> Message-ID: On Apr 19, 2011, at 3:29 PM, David Conrad wrote: > to the list I provided you in the previous message. Or are you implying that ARIN and the other RIRs are committing to synchronizing their databases with alternative address registrars as they become established? If by "established", you mean as a result of global policy established by multi-stakeholder, private sector led, bottom-up policy development model? Quite likely, as ARIN has committed to such principles and has an excellent track record of supporting Internet registry changes that result (e.g. the establishment and recognition of LACNIC and AfriNIC) >>> What venue do you propose for a global consultative action to be taken in an open, transparent, an unbiased manner? >> I've suggested ICANN, IGF, or the RIRs... > > I find ARIN's new found interests in engaging in ICANN-related processes heartwarming given my past experiences, but I suspect both the ICANN and RIR venues would be somewhat biased against changing the status quo. As for the IGF, my perhaps mistaken perception is that it has a slightly different focus than dealing with the operational implications of the proliferation of alternative address registrars. The main problem is one of timeliness. I doubt the market is going to wait for IGF, ICANN, or even RIR processes. But we'll see. Quite true... it's very hard to complete in a timely manner something that hasn't yet been started. /John John Curran President and CEO ARIN From bensons at queuefull.net Tue Apr 19 15:14:04 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 19 Apr 2011 15:14:04 -0500 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> Message-ID: <05669BC6-5DCE-4ECB-B75B-2C66F07B3ECA@queuefull.net> On Apr 19, 2011, at 2:56 PM, David Conrad wrote: > On Apr 19, 2011, at 10:19 AM, Jeff Wheeler wrote: >> Are you saying there are people who advocate creating a new ecosystem >> of service providers for supplying several things that the RIRs >> exclusively supply today? > > Yes. > >> Sign me up. As a vendor. I'd love to over-charge for the dead simple >> task of using an API to push DNS delegation updates to the IN-ADDR >> servers, and running a whois server. > > My guess is that lacking a monopoly, if you over-charge you won't have many customers. Meanwhile, under the current system, ARIN has managed to accumulate a >$25M cash reserve despite an increasing budget. (see https://www.arin.net/participate/meetings/reports/ARIN_XXVII/PDF/Wednesday/andersen_treasurer.pdf) Cheers, -Benson From jcurran at istaff.org Tue Apr 19 15:15:36 2011 From: jcurran at istaff.org (John Curran) Date: Tue, 19 Apr 2011 16:15:36 -0400 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> Message-ID: On Apr 19, 2011, at 3:56 PM, David Conrad wrote: > On Apr 19, 2011, at 10:19 AM, Jeff Wheeler wrote: >> >> Maybe I'm missing something, but I don't see how a bunch of different >> entities providing fragmented "post-allocation services" is of any >> benefit. > > Some folks find competition in service providers beneficial. I agree that competition can be quite useful and the result doesn't necessarily have to be be fragmented; it's quite possible to provide transparent referrals to make the services appear as a consistent whole. This requires understanding where the competition is being introduced; is it a single registry and multiple registrars, or multiple registries and synchronization, or some other model? Is there an architecture for this future model, or perhaps even a starting set of goals to work towards agreement on? David - can you share more about what you believe is being proposed? /John From drc at virtualized.org Tue Apr 19 15:45:57 2011 From: drc at virtualized.org (David Conrad) Date: Tue, 19 Apr 2011 13:45:57 -0700 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> Message-ID: <96ECE6C7-9542-4002-8CD6-D2B5484FE201@virtualized.org> John, Given ARIN's STLS, it would seem even ARIN has the 'right perspective' to see the "up$ide". It's more about the implication of folks having increasing financial incentive to go outside the existing mechanisms (e.g., Nortel/Microsoft) and the implications that has on network operations. Since it would seem we have an impedance mismatch on this topic, I'll not bore NANOG with further discussion. Regards, -drc On Apr 19, 2011, at 11:37 AM, John Curran wrote: > On Apr 19, 2011, at 1:19 PM, Jeff Wheeler wrote: >> Maybe I'm missing something, but I don't see how a bunch of different >> entities providing fragmented "post-allocation services" is of any >> benefit. > > Jeff - > > Imagine for a moment that you had quite a few > unneeded addresses and the upheaval also meant > no pesky policy constraints on your monetization efforts - > would you then view it as having some benefit? You just > might not have the right perspective to appreciate the > potential up$ide... > > /John > > John Curran > President and CEO > ARIN > > From jsw at inconcepts.biz Tue Apr 19 15:46:39 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Tue, 19 Apr 2011 16:46:39 -0400 Subject: IPv4 address exchange In-Reply-To: <05669BC6-5DCE-4ECB-B75B-2C66F07B3ECA@queuefull.net> References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> <05669BC6-5DCE-4ECB-B75B-2C66F07B3ECA@queuefull.net> Message-ID: On Tue, Apr 19, 2011 at 4:14 PM, Benson Schliesser wrote: > Meanwhile, under the current system, ARIN has managed to accumulate a >$25M cash reserve despite an increasing budget. (see https://www.arin.net/participate/meetings/reports/ARIN_XXVII/PDF/Wednesday/andersen_treasurer.pdf) If you want ARIN to reduce its fees, you can propose that. The fiduciaries at ARIN may say, "you're right, we do have more money than we need or foresee to need to operate," and recommend that fees be reduced. They may provide justification for this "war chest," such as the possibility of legal battles over address transfers. Who knows? Is your problem that ARIN spends its money poorly? I believe it does in some ways, but the community generally does not care enough to try to improve this. I questioned ARIN's travel budget a few years ago and was essentially flamed for doing so. You seem to think the difference between ARIN's expenditures and revenues is too large, resulting in a large cash reserve. Okay, if that's important to you, there is a forum for that discussion. I don't think anything will be done about it through a discussion on NANOG, but you can certainly bring it up on the various ARIN mailing lists, or ask ARIN board/staff to share their thoughts with you. I really don't think the cost of ARIN fees for IP address and ASN allocations are all that important to ARIN members. In my position as a senior technical resource for numerous ARIN members, I am much more interested in ARIN providing more services to members, or improving upon existing ones (IRR), than I am in any reduction of fees. Again, my position is reflected clearly in my public mailing list posts on this subject. Note that one of the things I think ARIN should improve upon, which ARIN has committed to improve, is its IRR database. There are already alternatives available, I'm glad ARIN has decided to increase the usefulness and quality of its IRR database. If they don't, you can still choose to use a third-party database. I don't share your view that a fragmented WHOIS/DNS ecosystem would be all that beneficial to stakeholders. In the absence of ARIN members flocking to PPML to complain about ARIN's travel budget or its increasing cash reserve, I don't think ARIN members are particularly concerned about reducing ARIN's fees. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From John_Brzozowski at Cable.Comcast.com Tue Apr 19 15:44:15 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Tue, 19 Apr 2011 20:44:15 +0000 Subject: Comcast's 6to4 Relays Message-ID: Folks, Since deploying our 6to4 relays, Comcast has observed a substantial reduction in the latency associated with the use of 6to4. As such we are contemplating further opening our relays for use by others. The availability of our 6to4 relays should improve the experience of others using 6to4 as a means to access content and services over IPv6. We have been open about our IPv6 activities and wanted to follow suit by reaching out to the community and soliciting feedback before moving forward. As always we wish to continue to advocate and support the universal deployment of IPv6. Please send any comments or questions to the list or if you wish to me directly. John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From jeffrey.lyon at blacklotus.net Tue Apr 19 16:11:51 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 19 Apr 2011 17:11:51 -0400 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> <05669BC6-5DCE-4ECB-B75B-2C66F07B3ECA@queuefull.net> Message-ID: On Tue, Apr 19, 2011 at 4:46 PM, Jeff Wheeler wrote: > On Tue, Apr 19, 2011 at 4:14 PM, Benson Schliesser > wrote: >> Meanwhile, under the current system, ARIN has managed to accumulate a >$25M cash reserve despite an increasing budget. (see https://www.arin.net/participate/meetings/reports/ARIN_XXVII/PDF/Wednesday/andersen_treasurer.pdf) > > If you want ARIN to reduce its fees, you can propose that. ?The > fiduciaries at ARIN may say, "you're right, we do have more money than > we need or foresee to need to operate," and recommend that fees be > reduced. ?They may provide justification for this "war chest," such as > the possibility of legal battles over address transfers. ?Who knows? > > Is your problem that ARIN spends its money poorly? ?I believe it does > in some ways, but the community generally does not care enough to try > to improve this. ?I questioned ARIN's travel budget a few years ago > and was essentially flamed for doing so. > > You seem to think the difference between ARIN's expenditures and > revenues is too large, resulting in a large cash reserve. ?Okay, if > that's important to you, there is a forum for that discussion. ?I > don't think anything will be done about it through a discussion on > NANOG, but you can certainly bring it up on the various ARIN mailing > lists, or ask ARIN board/staff to share their thoughts with you. > > I really don't think the cost of ARIN fees for IP address and ASN > allocations are all that important to ARIN members. ?In my position as > a senior technical resource for numerous ARIN members, I am much more > interested in ARIN providing more services to members, or improving > upon existing ones (IRR), than I am in any reduction of fees. ?Again, > my position is reflected clearly in my public mailing list posts on > this subject. > > Note that one of the things I think ARIN should improve upon, which > ARIN has committed to improve, is its IRR database. ?There are already > alternatives available, I'm glad ARIN has decided to increase the > usefulness and quality of its IRR database. ?If they don't, you can > still choose to use a third-party database. > > I don't share your view that a fragmented WHOIS/DNS ecosystem would be > all that beneficial to stakeholders. ?In the absence of ARIN members > flocking to PPML to complain about ARIN's travel budget or its > increasing cash reserve, I don't think ARIN members are particularly > concerned about reducing ARIN's fees. > > -- > Jeff S Wheeler > Sr Network Operator? /? Innovative Network Concepts > > I recall supporting your objective to ARIN's budget, to include travel and conventions. If memory serves, Mr. Curran simply stated that this is what the community wants and they see value in having ARIN travel all over the region. On the subject of an IPv4 market place, would it be feasible to suggest that ARIN allow pure market economy and then broker the deals, collecting a commission on sales rather than annual maintenance fees? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From bensons at queuefull.net Tue Apr 19 16:16:21 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 19 Apr 2011 16:16:21 -0500 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> <05669BC6-5DCE-4ECB-B75B-2C66F07B3ECA@queuefull.net> Message-ID: On Apr 19, 2011, at 3:46 PM, Jeff Wheeler wrote: > On Tue, Apr 19, 2011 at 4:14 PM, Benson Schliesser > wrote: >> Meanwhile, under the current system, ARIN has managed to accumulate a >$25M cash reserve despite an increasing budget. (see https://www.arin.net/participate/meetings/reports/ARIN_XXVII/PDF/Wednesday/andersen_treasurer.pdf) > ... > Is your problem that ARIN spends its money poorly? I believe it does > in some ways, but the community generally does not care enough to try > to improve this. I questioned ARIN's travel budget a few years ago > and was essentially flamed for doing so. I might agree that ARIN wastes money, but that wasn't my point. The context of my comment was your original message, which argued that a competitive registry system would enable vendors to "over-charge". Without defining what an optimal cost might be, my comment was intended to show that our current baseline already results in a surplus. And I agree with DRC's comment that competition might improve / optimize costs, rather than inflate them. Cheers, -Benson From jcurran at arin.net Tue Apr 19 16:18:24 2011 From: jcurran at arin.net (John Curran) Date: Tue, 19 Apr 2011 21:18:24 +0000 Subject: IPv4 address exchange In-Reply-To: <96ECE6C7-9542-4002-8CD6-D2B5484FE201@virtualized.org> References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> <96ECE6C7-9542-4002-8CD6-D2B5484FE201@virtualized.org> Message-ID: <1713A8DA-8DAC-4694-A595-4DE42B554B09@arin.net> On Apr 19, 2011, at 4:45 PM, David Conrad wrote: > Given ARIN's STLS, it would seem even ARIN has the 'right perspective' > to see the "up$ide". To be clear, the listing service is simply so that those who want to be contacted because they need address space can identify themselves, along with those who might have some available, or parties that want to act as a broker. ARIN serves non of these roles, doesn't match up parties, and charges a minimal fee ($100) for those who wish to make use of it. Note that providing it for free would have put the cost burden unfairly on the rest of the ARIN community, so we charge. This doesn't compare in the least to parties that wish to introduce unspecified changes to the global Internet number registry system under the theory of unstated benefits for the community, while also serving to directly financially benefit. There may be nothing wrong with that, per se, but those in the community asking for the changes and perceived benefits to be more clearly stated are being quite reasonable under the circumstances. /John John Curran President and CEO ARIN From jsw at inconcepts.biz Tue Apr 19 16:26:59 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Tue, 19 Apr 2011 17:26:59 -0400 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> <05669BC6-5DCE-4ECB-B75B-2C66F07B3ECA@queuefull.net> Message-ID: On Tue, Apr 19, 2011 at 5:16 PM, Benson Schliesser wrote: > Without defining what an optimal cost might be, my comment was intended to show that our current baseline already results in a surplus. I don't think the cost of IPv4 addresses has anywhere to go but up. This mysterious Nortel/Microsoft transaction would seem to give credibility to an assumption of increasing cost. Therefore, it stands to reason that the cost of "database services" associated with being a holder of IP addresses will be inconsequential. If I wanted to own www.abc.com, I could do that for a pretty low cost of < $20/year through the various dot-com registries. I am pretty sure ABC would not sell it to me for any price I could afford. Thus, the cost of that domain name lies not with the database services but with the unique string. If anyone thinks that won't be true for IP addresses, by all means, let that person propose to overhaul the IN-ADDR system and possibly the WHOIS database. I do not think stakeholders will agree with their views. IP addresses are finite, and the cost of acquiring them will, in all likelihood, dwarf the cost of publishing ownership/custodial information or operational DNS records. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From dougb at dougbarton.us Tue Apr 19 16:50:14 2011 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 19 Apr 2011 14:50:14 -0700 Subject: Comcast's 6to4 Relays In-Reply-To: References: Message-ID: <4DAE0396.7050409@dougbarton.us> On 04/19/2011 13:44, Brzozowski, John wrote: > Folks, > > Since deploying our 6to4 relays, Comcast has observed a substantial > reduction in the latency associated with the use of 6to4. As such we are > contemplating further opening our relays for use by others. The > availability of our 6to4 relays should improve the experience of others > using 6to4 as a means to access content and services over IPv6. > > We have been open about our IPv6 activities and wanted to follow suit by > reaching out to the community and soliciting feedback before moving > forward. As always we wish to continue to advocate and support the > universal deployment of IPv6. > > Please send any comments or questions to the list or if you wish to me > directly. Presumably you(pl.) are aware of the following 2 drafts, which are in WGLC now, and seem likely to be adopted (at least in some form): http://tools.ietf.org/html/draft-ietf-v6ops-6to4-advisory http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic At minimum one would hope that you're heeding the warnings in the first. Another view (one that I personally hold) is that any effort you might be putting into making 6to4 work better would be better placed in deploying real IPv6 instead; and that the world would be a better place generally if all of the so-called "transition mechanisms" just went away. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From jared at puck.nether.net Tue Apr 19 16:52:32 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 19 Apr 2011 17:52:32 -0400 Subject: Comcast's 6to4 Relays In-Reply-To: <4DAE0396.7050409@dougbarton.us> References: <4DAE0396.7050409@dougbarton.us> Message-ID: On Apr 19, 2011, at 5:50 PM, Doug Barton wrote: > At minimum one would hope that you're heeding the warnings in the first. Another view (one that I personally hold) is that any effort you might be putting into making 6to4 work better would be better placed in deploying real IPv6 instead; and that the world would be a better place generally if all of the so-called "transition mechanisms" just went away. I certainly feel that the lawful-intercept requirements and data retention necessary in a CGN/6to4 environment likely mean the barrier is high enough to suggest moving to IPv6, but the CPE situation is still mostly missing. - Jared From swmike at swm.pp.se Tue Apr 19 16:55:33 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 19 Apr 2011 23:55:33 +0200 (CEST) Subject: Comcast's 6to4 Relays In-Reply-To: <4DAE0396.7050409@dougbarton.us> References: <4DAE0396.7050409@dougbarton.us> Message-ID: On Tue, 19 Apr 2011, Doug Barton wrote: > Another view (one that I personally hold) is that any effort you might > be putting into making 6to4 work better would be better placed in > deploying real IPv6 instead; and that the world would be a better place > generally if all of the so-called "transition mechanisms" just went > away. I am all for getting fewer people to use 6to4, especially without them actually making a decision to use it, but giving more people access to high quality (I hope they are) 6to4 relays is seldom a downside. The drafts you mention make special notes that operators should NOT start to shut down relays, first of all we need to get fewer people to use 6to4, THEN we start to remove the relays. Starting at the relay end is bad, mmkay. -- Mikael Abrahamsson email: swmike at swm.pp.se From bensons at queuefull.net Tue Apr 19 17:13:16 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 19 Apr 2011 17:13:16 -0500 Subject: IPv4 address exchange In-Reply-To: References: <20110418155709.3785099F@resin16.mta.everyone.net> <4D7BBC15-2C19-4D63-ABAB-F85410363B6F@delong.com> <1696CE1C-B1CE-42AD-9F65-2CF715F2A919@virtualized.org> <2F4BCAD2-CA18-4121-95AA-3947AD1DE714@istaff.org> <05669BC6-5DCE-4ECB-B75B-2C66F07B3ECA@queuefull.net> Message-ID: On Apr 19, 2011, at 4:26 PM, Jeff Wheeler wrote: > I don't think the cost of IPv4 addresses has anywhere to go but up. > This mysterious Nortel/Microsoft transaction would seem to give > credibility to an assumption of increasing cost. I think we can agree on this. It is the natural result of exhaustion - scarce supply, ongoing demand. It is important to note, however, that this is orthogonal to the registry management structure; we could have increased IPv4 acquisition costs with ARIN, or increased IPv4 acquisition costs with somebody else. > Therefore, it stands > to reason that the cost of "database services" associated with being a > holder of IP addresses will be inconsequential. ... > If anyone thinks that won't be true for IP addresses, by all means, > let that person propose to overhaul the IN-ADDR system and possibly > the WHOIS database. I do not think stakeholders will agree with their > views. IP addresses are finite, and the cost of acquiring them will, > in all likelihood, dwarf the cost of publishing ownership/custodial > information or operational DNS records. As I agreed above, acquisition costs will go up regardless. The real question is total cost, which is (basically) the acquisition price plus the ongoing registry maintenance costs. As one possibility, an overhaul might result in less expensive (or even "free") registry services being provided by brokers. Assuming market prices aren't affected by the overhaul, the total cost might thus be lower with a broker versus ARIN. Perhaps this is a small impact, but it's real. More importantly, an overhaul to the registry system that facilitates liquidity in the market may introduce additional benefits. (e.g. more predictable and/or lower acquisition costs) I'm not an economist and I'm open to contrary arguments, but I see potential upsides to an overhaul that don't exist with the status quo. Cheers, -Benson From cb.list6 at gmail.com Tue Apr 19 18:47:11 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 19 Apr 2011 16:47:11 -0700 Subject: Comcast's 6to4 Relays In-Reply-To: References: <4DAE0396.7050409@dougbarton.us> Message-ID: On Apr 19, 2011 2:56 PM, "Mikael Abrahamsson" wrote: > > On Tue, 19 Apr 2011, Doug Barton wrote: > >> Another view (one that I personally hold) is that any effort you might be putting into making 6to4 work better would be better placed in deploying real IPv6 instead; and that the world would be a better place generally if all of the so-called "transition mechanisms" just went away. > > > I am all for getting fewer people to use 6to4, especially without them actually making a decision to use it, but giving more people access to high quality (I hope they are) 6to4 relays is seldom a downside. > > The drafts you mention make special notes that operators should NOT start to shut down relays, first of all we need to get fewer people to use 6to4, THEN we start to remove the relays. Starting at the relay end is bad, mmkay. > +1. 6to4 is very bad and should be off my default, but unfortunately many end users unwittingly have it on and this may provide them some relief. More ipv6 leadership from the Comcast camp. Keep it up. Cb > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From millnert at gmail.com Tue Apr 19 19:22:06 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 19 Apr 2011 20:22:06 -0400 Subject: Comcast's 6to4 Relays In-Reply-To: References: Message-ID: John, On Tue, Apr 19, 2011 at 4:44 PM, Brzozowski, John wrote: > Folks, > > Since deploying our 6to4 relays, Comcast has observed a substantial > reduction in the latency associated with the use of 6to4. As such we are > contemplating further opening our relays for use by others. The > availability of our 6to4 relays should improve the experience of others > using 6to4 as a means to access content and services over IPv6. I think it is a correct and welcome move on the north american internet market and that it will improve 6to4 performance there as 6to4 is phased out. Regards, Martin From butche at butchevans.com Tue Apr 19 19:52:07 2011 From: butche at butchevans.com (Butch Evans) Date: Tue, 19 Apr 2011 19:52:07 -0500 Subject: Comcast's 6to4 Relays In-Reply-To: References: <4DAE0396.7050409@dougbarton.us> Message-ID: <1303260727.3885.32.camel@butchlaptop.butchevans.com> On Tue, 2011-04-19 at 16:47 -0700, Cameron Byrne wrote: > On Apr 19, 2011 2:56 PM, "Mikael Abrahamsson" wrote: > > > +1. 6to4 is very bad and should be off my default, but unfortunately many > end users unwittingly have it on and this may provide them some relief. So am I to understand that services like Toredo client (which is what I PRESUME is being discussed) is on automatically in some Windows desktop systems? The drafts I saw posted earlier were discussing what is essentially toredo services (anycast tunnel) at least. If this is on by default, then that is only bad (in my opinion) IF there is no native IPv6 support on the LAN side of these networks. Maybe I am missing something, but this is my take. > More ipv6 leadership from the Comcast camp. Keep it up. Seems to me that if Comcast has "announced IPv6 support" and it is not NATIVE IPV6 support, then that is certainly a problem. Either way, there certainly IS a place in networks for Toredo services, since SO MANY devices for the CPE end of the connectivity equation still have zero support for IPv6. It's not the best solution for sure, but the fact remains that most networks will be dual-stacked at least initially at the core, but the endpoints (customer networks) are outside of our administrative control and often are behind devices that we do not control/own. Maybe I'm missing something... -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://store.wispgear.net/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * * NOTE MY NEW NUMBER: 702-537-0979 * ******************************************************************** From peter.thimmesch at depository.net Tue Apr 19 20:08:42 2011 From: peter.thimmesch at depository.net (Peter Thimmesch) Date: Tue, 19 Apr 2011 21:08:42 -0400 Subject: IPv4 address exchange Message-ID: <001701cbfef7$7dd5c550$79814ff0$@depository.net> John, Please note that we have filed our proposal for accreditation of IP address registrars with ICANN over a month ago. (Please see ICANN's Correspondence Page, Letters from David Holtzman to David Olive and John Jeffrey, filed 2 March 2011, Proposed Statement of IP Policy) In addition we pointed out, in our opinion, that the current process for reviewing and approving a Global Policy is somewhat skewed towards the Regional Internet Registries. Hence we requested that due to this obvious and readily apparent Conflict-of-Interest (yes, I expect you will disagree with even this, which is so clear that to debate this would be simply too much even by the new standards that you have set recently in your online arguments with Prof. Mueller) we explore other forums to have the merits of the proposal aired. Regards, Peter Thimmesch Chairman From ops.lists at gmail.com Tue Apr 19 20:27:03 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 20 Apr 2011 06:57:03 +0530 Subject: IPv4 address exchange In-Reply-To: <001701cbfef7$7dd5c550$79814ff0$@depository.net> References: <001701cbfef7$7dd5c550$79814ff0$@depository.net> Message-ID: It is going to be hard to constructively debate the merits of a proposal that begins with a rather condescending ad hominem attack. There are multiple ways to bring a policy discussion in front of a larger / different audience than whatever group or stakeholder community you seek to raise it in, but I seriously doubt if the way you've done this is going to be all that effective. thanks --srs On Wed, Apr 20, 2011 at 6:38 AM, Peter Thimmesch wrote: > John, > > > > Please note that we have filed our proposal for accreditation of IP address > registrars with ICANN over a month ago. (Please see ICANN's Correspondence > Page, Letters from David Holtzman to David Olive and John Jeffrey, filed 2 > March 2011, Proposed Statement of IP Policy) > ditation-policy-31mar11-en.pdf > > > > > In addition we pointed out, in our opinion, that the current process for > reviewing and approving a Global Policy is somewhat skewed towards the > Regional Internet Registries. Hence we requested that due to this obvious > and readily apparent Conflict-of-Interest (yes, I expect you will disagree > with even this, which is so clear that to debate this would be simply too > much even by the new standards that you have set recently in your online > arguments with Prof. Mueller) we explore other forums to have the merits of > the proposal aired. > > > > Regards, > > > > Peter Thimmesch > > Chairman > > > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From millnert at gmail.com Tue Apr 19 20:43:48 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 19 Apr 2011 21:43:48 -0400 Subject: Comcast's 6to4 Relays In-Reply-To: <1303260727.3885.32.camel@butchlaptop.butchevans.com> References: <4DAE0396.7050409@dougbarton.us> <1303260727.3885.32.camel@butchlaptop.butchevans.com> Message-ID: Butch, On Tue, Apr 19, 2011 at 8:52 PM, Butch Evans wrote: > The drafts I saw posted earlier were discussing what is > essentially toredo services (anycast tunnel) at least. 6to4 is significantly different from Teredo, since it: a) it does not hurt web deployments using DNS records for their resources (src/dst addr selection, and more) b) it works from behind a NAT, >?If this is on by default, then that is only bad (in my opinion) IF there is no native > IPv6 support on the LAN side of these networks. ?Maybe I am missing > something, but this is my take. In the case of 6to4, this is only true if your source/destination address selection works properly. Teredo adds extra safety to really make it a ipv4->ipv6 connection mechanism of last resort. > Either way, there certainly IS a place in networks for Toredo services, since SO > MANY devices for the CPE end of the connectivity equation still have > zero support for IPv6. I must point you to Geoff Hustons most recent ISP posting: http://www.potaroo.net/ispcol/2011-04/teredo.html It gives a very good picture of the Teredo support out in the wild. It also makes it abundantly clear that Teredo is not a reliable auto-tunneling mechanism (if such a mechanism ever can exist): 6to4 looks like flawlessness in comparison with Teredo when it comes to connection success ratios. Yet, virtually nobody has so far been complaining over issues caused by Teredo being active on their hosts. And there are some situations where it is OK that only 2 out of 3 connections succeed, if it means your system can work better: Notably, peer-to-peer applications can make use of this to establish connections in a cloud, using DHT instead of DNS for peer propagation, and Teredo relays as the rendezvous mechanism. I would, however, not want to rely on this for calls in Skype, for example. My (current) personal opinion on the situation is that application developers who do not want to use the last-resort NAT-"trespassing" method of establishing connectivity that Teredo supplies, must decide in their code not to use it. Some peer-to-peer applications have been known for years to come with a "Enable IPv6"-button, because it improved the applications performance to do so. So, in a world where some applications will enable it, other applications will have to *not use it*, else the applications will end-up in a race-condition on whether the protocol is enabled or not. > It's not the best solution for sure, but the > fact remains that most networks will be dual-stacked at least initially > at the core, but the endpoints (customer networks) are outside of our > administrative control and often are behind devices that we do not > control/own. ?Maybe I'm missing something... AFAIK, there's ongoing work in IETF to address this. I think one of the wg's is "softwire", http://tools.ietf.org/wg/softwire/ , but I have not followed this at all. Regards, Martin From jcurran at arin.net Tue Apr 19 20:53:31 2011 From: jcurran at arin.net (John Curran) Date: Wed, 20 Apr 2011 01:53:31 +0000 Subject: IPv4 address exchange In-Reply-To: <001701cbfef7$7dd5c550$79814ff0$@depository.net> References: <001701cbfef7$7dd5c550$79814ff0$@depository.net> Message-ID: <2DE79C21-DF90-4907-80E8-9627E174DC19@arin.net> On Apr 19, 2011, at 9:08 PM, Peter Thimmesch wrote: > John, > > Please note that we have filed our proposal for accreditation of IP address > registrars with ICANN over a month ago. (Please see ICANN's Correspondence > Page, Letters from David Holtzman to David Olive and John Jeffrey, filed 2 > March 2011, Proposed Statement of IP Policy) > ditation-policy-31mar11-en.pdf> Excellent. Thanks for pointing that out to the Nanog community. > In addition we pointed out, in our opinion, that the current process for > reviewing and approving a Global Policy is somewhat skewed towards the > Regional Internet Registries. Hence we requested that due to this obvious > and readily apparent Conflict-of-Interest (yes, I expect you will disagree > with even this, which is so clear that to debate this would be simply too > much even by the new standards that you have set recently in your online > arguments with Prof. Mueller) we explore other forums to have the merits of > the proposal aired. I'm certain that such forums will support multi-stakeholder, private sector led, bottom-up policy development, so that this community can participate in consideration of the merits. Perhaps you can elaborate how the Nanog community can get involved and provide feedback on the proposal? Thanks! /John John Curran President and CEO ARIN From fred at cisco.com Tue Apr 19 20:57:37 2011 From: fred at cisco.com (Fred Baker) Date: Tue, 19 Apr 2011 18:57:37 -0700 Subject: Comcast's 6to4 Relays In-Reply-To: <1303260727.3885.32.camel@butchlaptop.butchevans.com> References: <4DAE0396.7050409@dougbarton.us> <1303260727.3885.32.camel@butchlaptop.butchevans.com> Message-ID: On Apr 19, 2011, at 5:52 PM, Butch Evans wrote: >> +1. 6to4 is very bad and should be off my default, but unfortunately many >> end users unwittingly have it on and this may provide them some relief. > > So am I to understand that services like Toredo client (which is what I > PRESUME is being discussed) is on automatically in some Windows desktop > systems? No. 6to4 is RFC 3056/3068, and Teredo is a proprietary Microsoft technology documented in RFC 4380 with its updates. John and Cameron are talking about 6to4. From bhoomij at india.com Tue Apr 19 21:26:44 2011 From: bhoomij at india.com (Bhoomi Jain) Date: Wed, 20 Apr 2011 04:26:44 +0200 (CEST) Subject: Comcast's 6to4 Relays In-Reply-To: References: Message-ID: <20110420022657.6E18311C5@smtp02.zmail.com> Mr. John, I thank you for asking the advice of the community. As our colleagues suggest, having 6to4 relays inside the network helps to reduce the latency. Opening up your generous services to a larger Internet community by advertising the 192.88.99.0/24 BGP prefix outside the network could have extreme and unintended consequences. To give you an idea, a lot of the Internet in India depends on the service of the Tata companies, with international routing coming from Tata Communications AS 6453. Announcing 192.88.99.0/24 to 6453 as a customer, I would worry about its treatment as BGP best-path, in place of closer 6to4 relays. As you understand, these circuits are very far away, and also very full. This is not something I would recommend. Sincerely, Bhoomi Jain At 19 Apr 2011 22:51:24 +0200 (CEST) from "Brzozowski, John" : > >Folks, >Since deploying our 6to4 relays, Comcast has observed a substantial >reduction in the latency associated with the use of 6to4. As such we are >contemplating further opening our relays for use by others. The >availability of our 6to4 relays should improve the experience of others >using 6to4 as a means to access content and services over IPv6. >We have been open about our IPv6 activities and wanted to follow suit by >reaching out to the community and soliciting feedback before moving >forward. As always we wish to continue to advocate and support the >universal deployment of IPv6. >Please send any comments or questions to the list or if you wish to me >directly. >John >========================================= >John Jason Brzozowski >Comcast Cable >e) mailto:john_brzozowski@[cable.comcast.com] >o) 609-377-6594 >m) 484-962-0060 >w) [http://www.comcast6.net] >========================================= > > > From mpetach at netflight.com Tue Apr 19 22:00:53 2011 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 19 Apr 2011 20:00:53 -0700 Subject: Comcast's 6to4 Relays In-Reply-To: <20110420022657.6E18311C5@smtp02.zmail.com> References: <20110420022657.6E18311C5@smtp02.zmail.com> Message-ID: On Tue, Apr 19, 2011 at 7:26 PM, Bhoomi Jain wrote: > Mr. John, > > I thank you for asking the advice of the community. > > As our colleagues suggest, having 6to4 relays inside the network helps to reduce the latency. ?Opening up your generous services to a larger Internet community by advertising the 192.88.99.0/24 BGP prefix outside the network could have extreme and unintended consequences. > > To give you an idea, a lot of the Internet in India depends on the service of the Tata companies, with international routing coming from Tata Communications AS 6453. ?Announcing 192.88.99.0/24 to 6453 as a customer, I would worry about its treatment as BGP best-path, in place of closer 6to4 relays. ?As you understand, these circuits are very far away, and also very full. ?This is not something I would recommend. > > Sincerely, > Bhoomi Jain On the contrary; I think Comcast announcing their 6to4 relays through TATA could be just the incentive the Internet needs to kick the 6to4 habit completely, and decide once and for all the only sane option is dual-stack native. ;-) Matt From tony at lavanauts.org Tue Apr 19 22:53:48 2011 From: tony at lavanauts.org (Antonio Querubin) Date: Tue, 19 Apr 2011 17:53:48 -1000 (HST) Subject: Comcast's 6to4 Relays In-Reply-To: <20110420022657.6E18311C5@smtp02.zmail.com> References: <20110420022657.6E18311C5@smtp02.zmail.com> Message-ID: On Wed, 20 Apr 2011, Bhoomi Jain wrote: > To give you an idea, a lot of the Internet in India depends on the > service of the Tata companies, with international routing coming from > Tata Communications AS 6453. Announcing 192.88.99.0/24 to 6453 as a > customer, I would worry about its treatment as BGP best-path, in place > of closer 6to4 relays. As you understand, these circuits are very far > away, and also very full. This is not something I would recommend. Perhaps you should try convincing Tata to setup their own 6to4 relay so they can provide a better experience for their own customers who, for whatever reason, may not be able to get or use native IPv6 for quite some time. -- Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From alexb at ripe.net Wed Apr 20 03:55:26 2011 From: alexb at ripe.net (Alex Band) Date: Wed, 20 Apr 2011 10:55:26 +0200 Subject: RPKI in the real world: using MaxLength Message-ID: The RIPE NCC is running their Resource Certification system for a couple of months now, and we've got quite a number of prefixes covered by ROAs in the repository by now. So I decided to have a look at how people are creating their ROAs and in particular how the 'Maximum Length' feature is used, which authorises the AS to deaggregate the prefix to the specified point. We compared the repository to the prefixes seen by our RIS route collectors. It gives a good indication how people are using this option, and what the effects are when people base routing decisions on validation results. You can read the article here: https://labs.ripe.net/Members/AlexBand/using-the-maximum-length-option-in-roas I'm interested to hear if you think we should change our implementation, and what choice you think is the best. -Alex From david at davidswafford.com Wed Apr 20 04:58:59 2011 From: david at davidswafford.com (David Swafford) Date: Wed, 20 Apr 2011 05:58:59 -0400 Subject: eigrp set next hop In-Reply-To: References: Message-ID: If the number of prefixes are small, and your on Cisco gear, take a look at IP SLA as an option for manipulating static routes. Basically it'll allow you to setup a probe, and based on the result of the probe, dynamically populate a given static route in the routing table or not. David. On Mon, Apr 18, 2011 at 10:57 PM, Andrey Khomyakov < khomyakov.andrey at gmail.com> wrote: > The goal is to withdraw the prefixes should any part of the connection go > down. > Unfortunately router1--router2--firewall is part of a production setup and > not easily changed. The idea is really to have something like this (ideally > without router2): > > router1-router2-firewall-router3 > | | > router4-firewall-router5 > > I just wanted to check if I'm missing some knowledge about redistributing > BGP into EIGRP. It appears that there is really no way to manipulate > next-hop value. (no ip next-hop-self eigrp 1 is not really an option > because > there are many more prefixes coming from other routers that are being > redistributed to router2 from router1) > > I will see if the network will allow BGP on router2. That seems to be the > only clean solution for this. > > > > On Mon, Apr 18, 2011 at 9:25 PM, David Swafford >wrote: > > > What's the real goal behind this? What your describing sounds like a > > horrible band-aid.... > > > > David. > > > > > > On Mon, Apr 18, 2011 at 5:08 PM, Andrey Khomyakov < > > khomyakov.andrey at gmail.com> wrote: > > > >> Hi nanog > >> > >> I need to advertise EIGRP route with a different next-hop value than > self > >> > >> Due to how the connections are setup, I have to run BGP between two > peers > >> that are 3 hops away from each other. > >> > >> router1--router2--firewall--router3 > >> I'm running EBGP between router1 and router3 > >> router1 is redistributing into EIGRP that's running with router2 > >> > >> The problem is that now router2 thinks that router3 routes are reachable > >> via > >> router1 so I have myself a route loop. > >> > >> Is there a way to advertise an EIGRP route with next hop of router3 (or > >> firewall for that matter) rather than router1 which is what EIGRP does > by > >> default > >> > >> Thank you in advance for advice. > >> > >> -- > >> Andrey Khomyakov > >> [khomyakov.andrey at gmail.com] > >> > > > > > > > -- > Andrey Khomyakov > [khomyakov.andrey at gmail.com] > From gih at apnic.net Wed Apr 20 06:25:01 2011 From: gih at apnic.net (Geoff Huston) Date: Wed, 20 Apr 2011 21:25:01 +1000 Subject: Comcast's 6to4 Relays In-Reply-To: References: <4DAE0396.7050409@dougbarton.us> <1303260727.3885.32.camel@butchlaptop.butchevans.com> Message-ID: <93538607-170D-4DCB-805E-97BC83D2ECCA@apnic.net> On 20/04/2011, at 11:43 AM, Martin Millnert wrote: > >> Either way, there certainly IS a place in networks for Toredo services, since SO >> MANY devices for the CPE end of the connectivity equation still have >> zero support for IPv6. If you are prepared to tolerate a connection failure rate in the order of 37% or so, then I could agree with you, but that's a pretty impressive failure rate! > > I must point you to Geoff Hustons most recent ISP posting: > http://www.potaroo.net/ispcol/2011-04/teredo.html > > ... > And there are some situations where it is OK that only 2 out of 3 > connections succeed, if it means your system can work better: Notably, > peer-to-peer applications can make use of this to establish > connections in a cloud, using DHT instead of DNS for peer propagation, > and Teredo relays as the rendezvous mechanism. In my opinion any service that runs at a 37% failure rate of connections is a disservice. The peer-to-peer folk can tolerate its miserable reliability and lousy performance because of the massive redundancy in the peer-to-peer environment that means that that a peer-to-peer player can just ignore the connections that fail. But do we need to head to use applications that build in huge margins of oversupply in their communications model just to tolerate the unreliability of Teredo? Geoff From owen at delong.com Wed Apr 20 07:47:00 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Apr 2011 08:47:00 -0400 Subject: Comcast's 6to4 Relays In-Reply-To: <20110420022657.6E18311C5@smtp02.zmail.com> References: <20110420022657.6E18311C5@smtp02.zmail.com> Message-ID: The better solution to that problem is to get additional 6to4 relays deployed closer to India. Perhaps encouraging Tata to take some leadership in that area, for example. I do not believe that the opening of the Comcast relays will harm BGP best path selection for the 6to4 prefix except in rather broken and/or pathological cases of BGP best path selection. Those cases should be relatively easy to identify and correct locally without preventing Comcast from significantly improving the 6to4 situation for the areas they serve by opening their relays. I applaud John for his leadership in this area and I think the IPv6 work being done by Comcast sets a good example for the community. As a Comcast customer, praising Comcast does not come easy to me, but, in this area, they are doing excellent things and should be commended. Owen Sent from my iPad On Apr 19, 2011, at 10:26 PM, Bhoomi Jain wrote: > Mr. John, > > I thank you for asking the advice of the community. > > As our colleagues suggest, having 6to4 relays inside the network helps to reduce the latency. Opening up your generous services to a larger Internet community by advertising the 192.88.99.0/24 BGP prefix outside the network could have extreme and unintended consequences. > > To give you an idea, a lot of the Internet in India depends on the service of the Tata companies, with international routing coming from Tata Communications AS 6453. Announcing 192.88.99.0/24 to 6453 as a customer, I would worry about its treatment as BGP best-path, in place of closer 6to4 relays. As you understand, these circuits are very far away, and also very full. This is not something I would recommend. > > Sincerely, > Bhoomi Jain > > At 19 Apr 2011 22:51:24 +0200 (CEST) from "Brzozowski, John" : > >> >> Folks, >> Since deploying our 6to4 relays, Comcast has observed a substantial >> reduction in the latency associated with the use of 6to4. As such we are >> contemplating further opening our relays for use by others. The >> availability of our 6to4 relays should improve the experience of others >> using 6to4 as a means to access content and services over IPv6. >> We have been open about our IPv6 activities and wanted to follow suit by >> reaching out to the community and soliciting feedback before moving >> forward. As always we wish to continue to advocate and support the >> universal deployment of IPv6. >> Please send any comments or questions to the list or if you wish to me >> directly. >> John >> ========================================= >> John Jason Brzozowski >> Comcast Cable >> e) mailto:john_brzozowski@[cable.comcast.com] >> o) 609-377-6594 >> m) 484-962-0060 >> w) [http://www.comcast6.net] >> ========================================= >> >> >> From eric at eparsonage.com Wed Apr 20 09:20:24 2011 From: eric at eparsonage.com (Eric Parsonage) Date: Wed, 20 Apr 2011 23:50:24 +0930 Subject: CIsco IOS bug info request In-Reply-To: <1303260727.3885.32.camel@butchlaptop.butchevans.com> References: <4DAE0396.7050409@dougbarton.us> <1303260727.3885.32.camel@butchlaptop.butchevans.com> Message-ID: <65DD3DFF-6E8F-4044-AC92-8523D7F6764B@eparsonage.com> Hi All, Can anybody point me to a documented case where a bug in Cisco IOS has taken a whole network down ? Regards and thanks in advance Eric Parsonage From bret at getjive.com Wed Apr 20 09:23:11 2011 From: bret at getjive.com (Bret Palsson) Date: Wed, 20 Apr 2011 08:23:11 -0600 Subject: Anyone still maintaining altdb.net? Message-ID: <7FE72FAB-94EB-4C6E-860B-C92260608A7B@getjive.com> I submitted my objects April 11. the mtrner object needs to be created by the db-admin. I realize this is a volunteer thing. Could I help out or could the people that are helping out look at adding my record? I need to setup some peering relationships. I'd prefer to support open communities rather than paying and am willing to help out if need be. Thanks, Bret Below are the objects that were submitted: mntner: MAINT-JIVE descr: Jive Communications, Inc. admin-c: BEP7-ARIN tech-c: BEP7-ARIN upd-to: routing at getjive.com mnt-nfy: routing at getjive.com auth: CRYPT-PW jiCdjGQviTmYo mnt-by: MAINT-JIVE changed: routing at getjive.com 20110411 source: ALTDB aut-num: AS6643 as-name: JIVE descr: Jive Communications, Inc. admin-c: BEP7-ARIN tech-c: BEP7-ARIN mnt-by: MAINT-JIVE changed: routing at getjive.com 20110411 source: ALTDB as-set: AS-JIVE descr: Jive Communications, Inc. admin-c: BEP7-ARIN tech-c: BEP7-ARIN mnt-by: MAINT-JIVE changed: routing at getjive.com 20110411 source: ALTDB route: 199.36.248.0/24 descr: Jive Communications, Inc. origin: AS6643 mnt-by: MAINT-JIVE changed: routing at getjive.com 20110411 source: ALTDB route: 199.36.249.0/24 descr: Jive Communications, Inc. origin: AS6643 mnt-by: MAINT-JIVE changed: routing at getjive.com 20110411 source: ALTDB route: 199.36.250.0/24 descr: Jive Communications, Inc. origin: AS6643 mnt-by: MAINT-JIVE changed: routing at getjive.com 20110411 source: ALTDB route: 199.36.251.0/24 descr: Jive Communications, Inc. origin: AS6643 mnt-by: MAINT-JIVE changed: routing at getjive.com 20110411 source: ALTDB From jlewis at lewis.org Wed Apr 20 09:30:44 2011 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 20 Apr 2011 10:30:44 -0400 (EDT) Subject: Anyone still maintaining altdb.net? In-Reply-To: <7FE72FAB-94EB-4C6E-860B-C92260608A7B@getjive.com> References: <7FE72FAB-94EB-4C6E-860B-C92260608A7B@getjive.com> Message-ID: On Wed, 20 Apr 2011, Bret Palsson wrote: > I submitted my objects April 11. the mtrner object needs to be created by the db-admin. I realize this is a volunteer thing. Could I help out or could the people that are helping out look at adding my record? I need to setup some peering relationships. I'd prefer to support open communities rather than paying and am willing to help out if need be. If you're just getting started, it might make sense to look at another db. IIRC, RIPE's routing registry is free to use, supports md5crypt and PGP/GPG auth, and isn't a volunteer one-man show. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From dmm at 1-4-5.net Wed Apr 20 09:35:44 2011 From: dmm at 1-4-5.net (David Meyer) Date: Wed, 20 Apr 2011 07:35:44 -0700 Subject: [NANOG-announce] NANOG 52 Early Bird Registration ends 04/23/2011 -- Register now! In-Reply-To: References: Message-ID: Looking forward to seeing you all in Denver. Dave (for the NANOG PC) _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From ebais at a2b-internet.com Wed Apr 20 09:55:44 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 20 Apr 2011 16:55:44 +0200 Subject: CIsco IOS bug info request In-Reply-To: <65DD3DFF-6E8F-4044-AC92-8523D7F6764B@eparsonage.com> References: <4DAE0396.7050409@dougbarton.us> <1303260727.3885.32.camel@butchlaptop.butchevans.com> <65DD3DFF-6E8F-4044-AC92-8523D7F6764B@eparsonage.com> Message-ID: <00a301cbff6b$0662c170$13284450$@com> Hi Eric, You might want to read up on : http://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experimen t The cisco case involved : http://www.cisco.com/en/US/products/products_security_advisory09186a0080b441 1f.shtml Short detail from the Cisco site: This vulnerability affects Cisco IOS XR devices running affected software versions and configured with the BGP routing feature. The vulnerability manifests itself when a BGP peer announces a prefix with a specific, valid but unrecognized transitive attribute. On receipt of this prefix, the Cisco IOS XR device will corrupt the attribute before sending it to the neighboring devices. Neighboring devices that receive this corrupted update may reset the BGP peering session. Could you provide insight in why you are specifically looking for a Cisco IOS bug that has taken down a network ? Regards, Erik Bais From andyring at inebraska.com Wed Apr 20 10:03:31 2011 From: andyring at inebraska.com (Andy Ringsmuth) Date: Wed, 20 Apr 2011 10:03:31 -0500 Subject: dishnetwork.com down? Message-ID: <8B7E8238-9454-4D89-B6A1-48D6412E6112@inebraska.com> Anyone know what's up with dishnetwork.com? www.downforeveryoneorjustme.com also reports it as being down. --- Andy Ringsmuth 7215 Dorchester Court Lincoln, NE 68521 (402) 304-0083 andyring at inebraska.com From cschmitt at onlinetech.com Wed Apr 20 10:05:11 2011 From: cschmitt at onlinetech.com (Christopher Schmitt) Date: Wed, 20 Apr 2011 11:05:11 -0400 Subject: dishnetwork.com down? In-Reply-To: <8B7E8238-9454-4D89-B6A1-48D6412E6112@inebraska.com> References: <8B7E8238-9454-4D89-B6A1-48D6412E6112@inebraska.com> Message-ID: <4A8E4546FCA2354CA9EE44594703B7FE72DDE758E6@otfntmsexch.onlinetech.com> It's up for me (Michigan). -----Original Message----- From: Andy Ringsmuth [mailto:andyring at inebraska.com] Sent: Wednesday, April 20, 2011 11:04 AM To: outages; NANOG list Subject: dishnetwork.com down? Anyone know what's up with dishnetwork.com? www.downforeveryoneorjustme.com also reports it as being down. --- Andy Ringsmuth 7215 Dorchester Court Lincoln, NE 68521 (402) 304-0083 andyring at inebraska.com From ras at e-gerbil.net Wed Apr 20 10:05:42 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 20 Apr 2011 10:05:42 -0500 Subject: Anyone still maintaining altdb.net? In-Reply-To: References: <7FE72FAB-94EB-4C6E-860B-C92260608A7B@getjive.com> Message-ID: <20110420150542.GL68199@gerbil.cluepon.net> On Wed, Apr 20, 2011 at 10:30:44AM -0400, Jon Lewis wrote: > On Wed, 20 Apr 2011, Bret Palsson wrote: > > > I submitted my objects April 11. the mtrner object needs to be > > created by the db-admin. I realize this is a volunteer thing. Could > > I help out or could the people that are helping out look at adding > > my record? I need to setup some peering relationships. I'd prefer to > > support open communities rather than paying and am willing to help > > out if need be. > > If you're just getting started, it might make sense to look at another db. > IIRC, RIPE's routing registry is free to use, supports md5crypt and > PGP/GPG auth, and isn't a volunteer one-man show. One of the premises of AltDB is that no support is provided. For example, a lot of people send email asking "how do I use this", and the unfortunate answer has to be "sorry we can't help you". If you need support, then by all means pay the money to someone like RADB and let them help walk you through the process. Of course after the initial mntner creation everything is pretty much automated anyways, so if you know what you're doing AltDB provides a free method to maintain your IRR entries with very little sacrificied over a commercial solution. There is infact more than 1 person volunteering for AltDB, but from what I can see of this April 11th email, it falls into the "please provide support" category. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From andyring at inebraska.com Wed Apr 20 10:06:36 2011 From: andyring at inebraska.com (Andy Ringsmuth) Date: Wed, 20 Apr 2011 10:06:36 -0500 Subject: dishnetwork.com down? In-Reply-To: <4A8E4546FCA2354CA9EE44594703B7FE72DDE758E6@otfntmsexch.onlinetech.com> References: <8B7E8238-9454-4D89-B6A1-48D6412E6112@inebraska.com> <4A8E4546FCA2354CA9EE44594703B7FE72DDE758E6@otfntmsexch.onlinetech.com> Message-ID: <7922DA4E-FDAE-4B82-8BE1-291AA5C1E168@inebraska.com> Go figure. Haven't been able to access it for several hours and then within a minute or two of sending that e-mail, it's fixed. :) --- Andy Ringsmuth 7215 Dorchester Court Lincoln, NE 68521 (402) 304-0083 andyring at inebraska.com On Apr 20, 2011, at 10:05 AM, Christopher Schmitt wrote: > It's up for me (Michigan). > > -----Original Message----- > From: Andy Ringsmuth [mailto:andyring at inebraska.com] > Sent: Wednesday, April 20, 2011 11:04 AM > To: outages; NANOG list > Subject: dishnetwork.com down? > > Anyone know what's up with dishnetwork.com? www.downforeveryoneorjustme.com also reports it as being down. > > --- > Andy Ringsmuth > 7215 Dorchester Court > Lincoln, NE 68521 > (402) 304-0083 > andyring at inebraska.com > > From m.hallgren at free.fr Wed Apr 20 10:31:00 2011 From: m.hallgren at free.fr (Michael Hallgren) Date: Wed, 20 Apr 2011 17:31:00 +0200 Subject: Anyone still maintaining altdb.net? In-Reply-To: <20110420150542.GL68199@gerbil.cluepon.net> References: <7FE72FAB-94EB-4C6E-860B-C92260608A7B@getjive.com> <20110420150542.GL68199@gerbil.cluepon.net> Message-ID: <1303313460.3072.6.camel@home> Le mercredi 20 avril 2011 ? 10:05 -0500, Richard A Steenbergen a ?crit : > On Wed, Apr 20, 2011 at 10:30:44AM -0400, Jon Lewis wrote: > > On Wed, 20 Apr 2011, Bret Palsson wrote: > > > > > I submitted my objects April 11. the mtrner object needs to be > > > created by the db-admin. I realize this is a volunteer thing. Could > > > I help out or could the people that are helping out look at adding > > > my record? I need to setup some peering relationships. I'd prefer to > > > support open communities rather than paying and am willing to help > > > out if need be. > > > > If you're just getting started, it might make sense to look at another db. > > IIRC, RIPE's routing registry is free to use, supports md5crypt and > > PGP/GPG auth, and isn't a volunteer one-man show. > > One of the premises of AltDB is that no support is provided. For > example, a lot of people send email asking "how do I use this", and the > unfortunate answer has to be "sorry we can't help you". If you need > support, then by all means pay the money to someone like RADB and let > them help walk you through the process. Of course after the initial > mntner creation everything is pretty much automated anyways, so if you > know what you're doing AltDB provides a free method to maintain your IRR > entries with very little sacrificied over a commercial solution. I believe that RIPE still provide training sessions (as well as quite extensive documentation), mailing lists, etc, etc mh > > There is infact more than 1 person volunteering for AltDB, but from what > I can see of this April 11th email, it falls into the "please provide > support" category. :) > From andreas at sbin.se Wed Apr 20 10:40:38 2011 From: andreas at sbin.se (Andreas Petersson) Date: Wed, 20 Apr 2011 17:40:38 +0200 Subject: YOU-TUBE-IN.edge2.SanJose1.Level3.net Message-ID: <20110420174038.06df8c17@hetzer> Hi, Not sure this is the right place to ask, but I see lots of pl to www.google.com from my servers. Anyone else that have the same problem? Host Loss% Snt Last Avg Best Wrst StDev 6. ae-92-92.csw4.SanJose1.Level3.net 0.0% 7 1.3 1.1 1.1 1.3 0.1 7. ae-4-90.edge2.SanJose1.Level3.net 0.0% 7 1.1 17.3 1.1 67.9 25.0 8. YOU-TUBE-IN.edge2.SanJose1.Level3.net 42.9% 7 2.1 2.2 2.1 2.3 0.1 9. 72.14.232.136 66.7% 6 2.7 5.0 2.7 7.2 3.1 10. 64.233.174.15 60.0% 6 2.8 2.8 2.8 2.9 0.1 11. 74.125.224.49 60.0% 6 3.2 5.8 3.2 8.4 3.7 BR Andreas Petersson From bret at getjive.com Wed Apr 20 10:51:30 2011 From: bret at getjive.com (Bret Palsson) Date: Wed, 20 Apr 2011 09:51:30 -0600 Subject: Anyone still maintaining altdb.net? In-Reply-To: <20110420150542.GL68199@gerbil.cluepon.net> References: <7FE72FAB-94EB-4C6E-860B-C92260608A7B@getjive.com> <20110420150542.GL68199@gerbil.cluepon.net> Message-ID: <9E0363A5-9582-4724-8AD7-382B765FD54F@getjive.com> Really... Please provide support? Below is the response I got on April 11. I don't need a tutorial on how to use the service... "#ERROR: New maintainers must be added by a DB administrator. Forwarding new request to db-admin at altdb.net" If it takes weeks for a maintainer record to be added, the service really isn't helping people which is why I offered to be part of that service a volunteer. Frankly I am shocked you would make such comments as: > There is infact more than 1 person volunteering for AltDB, but from what > I can see of this April 11th email, it falls into the "please provide > support" category. :) I really was requesting: Please do what you signed up to do and add my object. If you need more people to help with this process, I'm available and would be more than happy to help out, as I do in every position I volunteer in. I've waited 9 days which isn't a lot compared to others I've talked with who have waited many weeks or have had no response at all. I also realize people have lives and can't do things on demand when they are a volunteer. However for a service to be a service responsibility must lie with someone. If no one takes responsibility the service becomes unusable and actually becomes a disservice. I appreciate Jon Lewis's response it was much more helpful to know of other free services that I can support vs. the non-helpful response I got from you. I only posted to nanog about altdb.net becaus altdb was created by nanog members. I like to support nanog and the services the community provides. ---- Actual results below ----- Your transaction has been processed by the IRRd routing registry system. Diagnostic output: ------------------------------------------------------------ The submission contained the following mail headers: - From: routing at getjive.com - Subject: Please add mntner object. - Date: Wed, 20 Apr 2011 08:24:09 -0600 - Msg-Id: ADD FAILED: [mntner] MAINT-JIVE mntner: MAINT-JIVE descr: Jive Communications, Inc. admin-c: BEP7-ARIN tech-c: BEP7-ARIN upd-to: routing at getjive.com mnt-nfy: routing at getjive.com auth: CRYPT-PW jiCdjGQviTmYo mnt-by: MAINT-JIVE changed: routing at getjive.com 20110411 source: ALTDB #ERROR: New maintainers must be added by a DB administrator. Forwarding new request to db-admin at altdb.net On Apr 20, 2011, at 9:05 AM, Richard A Steenbergen wrote: > On Wed, Apr 20, 2011 at 10:30:44AM -0400, Jon Lewis wrote: >> On Wed, 20 Apr 2011, Bret Palsson wrote: >> >>> I submitted my objects April 11. the mtrner object needs to be >>> created by the db-admin. I realize this is a volunteer thing. Could >>> I help out or could the people that are helping out look at adding >>> my record? I need to setup some peering relationships. I'd prefer to >>> support open communities rather than paying and am willing to help >>> out if need be. >> >> If you're just getting started, it might make sense to look at another db. >> IIRC, RIPE's routing registry is free to use, supports md5crypt and >> PGP/GPG auth, and isn't a volunteer one-man show. > > One of the premises of AltDB is that no support is provided. For > example, a lot of people send email asking "how do I use this", and the > unfortunate answer has to be "sorry we can't help you". If you need > support, then by all means pay the money to someone like RADB and let > them help walk you through the process. Of course after the initial > mntner creation everything is pretty much automated anyways, so if you > know what you're doing AltDB provides a free method to maintain your IRR > entries with very little sacrificied over a commercial solution. > > There is infact more than 1 person volunteering for AltDB, but from what > I can see of this April 11th email, it falls into the "please provide > support" category. :) > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From ccariffe at gmail.com Wed Apr 20 11:04:38 2011 From: ccariffe at gmail.com (Chris Cariffe) Date: Wed, 20 Apr 2011 12:04:38 -0400 Subject: YOU-TUBE-IN.edge2.SanJose1.Level3.net In-Reply-To: <20110420174038.06df8c17@hetzer> References: <20110420174038.06df8c17@hetzer> Message-ID: yes, from SF - Postini and Google. On Wed, Apr 20, 2011 at 11:40 AM, Andreas Petersson wrote: > Hi, > > Not sure this is the right place to ask, but I see lots of pl to > www.google.com from my servers. Anyone else that have the same problem? > > Host Loss% > Snt Last Avg Best Wrst StDev > > 6. ae-92-92.csw4.SanJose1.Level3.net 0.0% > 7 1.3 1.1 1.1 1.3 0.1 7. > ae-4-90.edge2.SanJose1.Level3.net 0.0% 7 > 1.1 17.3 1.1 67.9 25.0 8. > YOU-TUBE-IN.edge2.SanJose1.Level3.net 42.9% 7 > 2.1 2.2 2.1 2.3 0.1 9. > 72.14.232.136 66.7% 6 > 2.7 5.0 2.7 7.2 3.1 10. > 64.233.174.15 60.0% 6 > 2.8 2.8 2.8 2.9 0.1 11. > 74.125.224.49 60.0% 6 > 3.2 5.8 3.2 8.4 3.7 > > > BR > Andreas Petersson > > From scg at gibbard.org Wed Apr 20 11:08:38 2011 From: scg at gibbard.org (Steve Gibbard) Date: Wed, 20 Apr 2011 09:08:38 -0700 Subject: [NANOG-announce] NANOG Membership Update Message-ID: <0BAE5241-4EA2-4BDF-BD5B-3F6E708ECC3C@gibbard.org> NANOG Community, As many of you know, NANOG has been taken over by a new membership-based non-profit corporation, NewNOG, Inc. Things are going well so far. The NANOG Intellectual Property transfer is moving along nicely. We've been signing up lots of sponsors for the Denver meeting coming up in June, and are getting lots of interest in sponsorship for next fall's Philadelphia meeting. We expect to have great programs for those meetings as well. We began signing up members during the Miami NANOG meeting at the end of January, and are now up to 160 members. In addition to providing some of the organization's financial support, the membership makes the decisions on how the organization is run. In effect, the membership is NANOG. The current list of members is at https://newnog.org/members.php. The membership policy is at https://newnog.org/membership-policy.php. For those of you who haven't joined yet, we'd like to once again ask you to become members. Membership is $100 per year, with a 10% discount for pre-paying for three or more years. Student membership is $50 per year. Members receive a $25 per meeting registration discount. You can join at https://newnog.org/join.php. We will also have a membership table set up at NANOG52 in Denver, which you can visit for information or assistance. For those of you who were having trouble with our PayPal sign-up process, or for those outside the United States, we are now also accepting credit card payments via Google Checkout. Thanks for your support, Steve Gibbard NANOG Membership Chair NANOG Development Committee _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From chris at weebly.com Wed Apr 20 11:21:10 2011 From: chris at weebly.com (Chris Fanini) Date: Wed, 20 Apr 2011 09:21:10 -0700 Subject: YOU-TUBE-IN.edge2.SanJose1.Level3.net In-Reply-To: <20110420174038.06df8c17@hetzer> References: <20110420174038.06df8c17@hetzer> Message-ID: We're seeing the same packet loss from SF. 1. ge-0-3.core1.sf2p.weebly.net 0.0% 0.3 3.9 0.3 186.5 19.4 2. vlan118.car2.SanFrancisco1.Level3.net 0.7% 1.1 12.9 0.5 184.4 35.3 3. ae-2-4.bar2.SanFrancisco1.Level3.net 0.0% 27.5 3.9 0.4 63.2 11.8 4. 4.69.140.154 0.0% 1.2 1.7 1.2 24.7 2.0 5. ae-72-72.csw2.SanJose1.Level3.net 0.0% 9.8 3.1 1.3 56.6 6.7 6. ae-2-70.edge2.SanJose1.Level3.net 0.0% 54.3 4.3 1.3 64.9 10.5 7. YOU-TUBE-IN.edge2.SanJose1.Level3.net 59.8% 66.8 10.2 2.9 97.1 19.4 8. 72.14.232.136 61.7% 2.9 5.3 2.9 46.2 7.6 9. 64.233.174.15 61.4% 3.2 3.7 3.0 16.2 1.9 10. 74.125.224.48 56.8% 3.3 3.1 2.8 3.9 0.2 On Wed, Apr 20, 2011 at 8:40 AM, Andreas Petersson wrote: > Hi, > > Not sure this is the right place to ask, but I see lots of pl to > www.google.com from my servers. Anyone else that have the same problem? > > Host Loss% > Snt Last Avg Best Wrst StDev > > 6. ae-92-92.csw4.SanJose1.Level3.net 0.0% > 7 1.3 1.1 1.1 1.3 0.1 7. > ae-4-90.edge2.SanJose1.Level3.net 0.0% 7 > 1.1 17.3 1.1 67.9 25.0 8. > YOU-TUBE-IN.edge2.SanJose1.Level3.net 42.9% 7 > 2.1 2.2 2.1 2.3 0.1 9. > 72.14.232.136 66.7% 6 > 2.7 5.0 2.7 7.2 3.1 10. > 64.233.174.15 60.0% 6 > 2.8 2.8 2.8 2.9 0.1 11. > 74.125.224.49 60.0% 6 > 3.2 5.8 3.2 8.4 3.7 > > > BR > Andreas Petersson > > From bhoomij at india.com Wed Apr 20 11:33:26 2011 From: bhoomij at india.com (Bhoomi Jain) Date: Wed, 20 Apr 2011 18:33:26 +0200 (CEST) Subject: Comcast's 6to4 Relays In-Reply-To: References: <20110420022657.6E18311C5@smtp02.zmail.com>, Message-ID: <20110420163320.E4B9D4389C@smtp03.zmail.com> Mr. Delong, I am simply trying to explain that running a 6to4 on your network is a good idea, however advertising the anycast prefix to other networks has some risk, especially if you're experiencing problems with your Internet peerings. Hopefully Comcast will upgrade its capacity soon. I appreciate Mr. John's continued leadership and contribution to the IPv6. Sincerely, Bhoomi Jain At 20 Apr 2011 14:51:48 +0200 (CEST) from Owen DeLong : > >The better solution to that problem is to get additional 6to4 relays deployed closer to India. Perhaps encouraging Tata to take some leadership in that area, for example. >I do not believe that the opening of the Comcast relays will harm BGP best path selection for the 6to4 prefix except in rather broken and/or pathological cases of BGP best path selection. Those cases should be relatively easy to identify and correct locally without preventing Comcast from significantly improving the 6to4 situation for the areas they serve by opening their relays. >I applaud John for his leadership in this area and I think the IPv6 work being done by Comcast sets a good example for the community. As a Comcast customer, praising Comcast does not come easy to me, but, in this area, they are doing excellent things and should be commended. >Owen > >Sent from my iPad >On Apr 19, 2011, at 10:26 PM, Bhoomi Jain wrote: >> Mr. John, >> >> I thank you for asking the advice of the community. >> >> As our colleagues suggest, having 6to4 relays inside the network helps to reduce the latency. Opening up your generous services to a larger Internet community by advertising the 192.88.99.0/24 BGP prefix outside the network could have extreme and unintended consequences. >> >> To give you an idea, a lot of the Internet in India depends on the service of the Tata companies, with international routing coming from Tata Communications AS 6453. Announcing 192.88.99.0/24 to 6453 as a customer, I would worry about its treatment as BGP best-path, in place of closer 6to4 relays. As you understand, these circuits are very far away, and also very full. This is not something I would recommend. >> >> Sincerely, >> Bhoomi Jain >> >> At 19 Apr 2011 22:51:24 +0200 (CEST) from "Brzozowski, John" : >> >>> >>> Folks, >>> Since deploying our 6to4 relays, Comcast has observed a substantial >>> reduction in the latency associated with the use of 6to4. As such we are >>> contemplating further opening our relays for use by others. The >>> availability of our 6to4 relays should improve the experience of others >>> using 6to4 as a means to access content and services over IPv6. >>> We have been open about our IPv6 activities and wanted to follow suit by >>> reaching out to the community and soliciting feedback before moving >>> forward. As always we wish to continue to advocate and support the >>> universal deployment of IPv6. >>> Please send any comments or questions to the list or if you wish to me >>> directly. >>> John >>> ========================================= >>> John Jason Brzozowski >>> Comcast Cable >>> e) mailto:john_brzozowski@[[cable.comcast.com]] >>> o) 609-377-6594 >>> m) 484-962-0060 >>> w) [[http://www.comcast6.net]] >>> ========================================= >>> >>> >>> > > From ser at tch.org Wed Apr 20 12:28:45 2011 From: ser at tch.org (Steve Rubin) Date: Wed, 20 Apr 2011 10:28:45 -0700 Subject: Anyone still maintaining altdb.net? In-Reply-To: <9E0363A5-9582-4724-8AD7-382B765FD54F@getjive.com> References: <7FE72FAB-94EB-4C6E-860B-C92260608A7B@getjive.com> <20110420150542.GL68199@gerbil.cluepon.net> <9E0363A5-9582-4724-8AD7-382B765FD54F@getjive.com> Message-ID: > > I've waited 9 days which isn't a lot compared to others I've talked with who have waited many weeks or have had no response at all. > > I also realize people have lives and can't do things on demand when they are a volunteer. However for a service to be a service responsibility must lie with someone. If no one takes responsibility the service becomes unusable and actually becomes a disservice. As I have been known to suggest in the past. I recommend this link for faster service: http://www.nanog.org/scholarships/abha.php -- Steve ALTDB Customer Service From eschoedler at viavale.com.br Wed Apr 20 12:42:47 2011 From: eschoedler at viavale.com.br (Eduardo Schoedler) Date: Wed, 20 Apr 2011 14:42:47 -0300 Subject: RES: Anyone still maintaining altdb.net? In-Reply-To: <7FE72FAB-94EB-4C6E-860B-C92260608A7B@getjive.com> References: <7FE72FAB-94EB-4C6E-860B-C92260608A7B@getjive.com> Message-ID: <00b101cbff82$5c7a9580$156fc080$@com.br> On Wed, 20 Apr 2011, Bret Palsson wrote: > I submitted my objects April 11. the mtrner object needs to be created > by the db-admin. I realize this is a volunteer thing. Could I help out > or could the people that are helping out look at adding my record? I > need to setup some peering relationships. I'd prefer to support open > communities rather than paying and am willing to help out if need be. Bret, You can try the SCW IRR [1]. It's free, but is in Portuguese. Reference: [1] http://whois.scw.net.br/ -- Eduardo Schoedler -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6422 bytes Desc: not available URL: From John_Brzozowski at Cable.Comcast.com Wed Apr 20 12:54:49 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Wed, 20 Apr 2011 17:54:49 +0000 Subject: Comcast's 6to4 Relays In-Reply-To: Message-ID: Doug, I am aware of the drafts you cited earlier, as Mikael mentions below the existence of the same will not result in 6to4 being turned off automatically or immediately. This process will likely take years. Please note the goal here is not to make 6to4 great, like many others we hope to see 6to4 use diminish over time. Thanks, John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= On 4/19/11 5:55 PM, "Mikael Abrahamsson" wrote: >On Tue, 19 Apr 2011, Doug Barton wrote: > >> Another view (one that I personally hold) is that any effort you might >> be putting into making 6to4 work better would be better placed in >> deploying real IPv6 instead; and that the world would be a better place >> generally if all of the so-called "transition mechanisms" just went >> away. > >I am all for getting fewer people to use 6to4, especially without them >actually making a decision to use it, but giving more people access to >high quality (I hope they are) 6to4 relays is seldom a downside. > >The drafts you mention make special notes that operators should NOT start >to shut down relays, first of all we need to get fewer people to use >6to4, >THEN we start to remove the relays. Starting at the relay end is bad, >mmkay. > >-- >Mikael Abrahamsson email: swmike at swm.pp.se From if at xip.at Wed Apr 20 13:15:50 2011 From: if at xip.at (Ingo Flaschberger) Date: Wed, 20 Apr 2011 20:15:50 +0200 (CEST) Subject: CIsco IOS bug info request In-Reply-To: <65DD3DFF-6E8F-4044-AC92-8523D7F6764B@eparsonage.com> References: <4DAE0396.7050409@dougbarton.us> <1303260727.3885.32.camel@butchlaptop.butchevans.com> <65DD3DFF-6E8F-4044-AC92-8523D7F6764B@eparsonage.com> Message-ID: Dear Eric, > Can anybody point me to a documented case where a bug in Cisco IOS has taken a whole network down ? The ripe experiment is really a great one. A "little" bit older one, but bigger - took down the whole internet: 1) http://markmail.org/message/nmlyif7oycohcr22 2) http://www.atm.tut.fi/list-archive/nanog/msg04507.html Kind regards, Ingo Flaschberger From dougb at dougbarton.us Wed Apr 20 13:25:43 2011 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 20 Apr 2011 11:25:43 -0700 Subject: Comcast's 6to4 Relays In-Reply-To: References: Message-ID: <4DAF2527.5090609@dougbarton.us> On 04/20/2011 10:54, Brzozowski, John wrote: > Doug, > > I am aware of the drafts you cited earlier, as Mikael mentions below the > existence of the same will not result in 6to4 being turned off > automatically or immediately. This process will likely take years. I was going to let this go, but after so many responses in the same vein I feel compelled to clarify. *I personally* believe that the answer to 6to4 is to just turn it off. These things have long tails because we insist that they do, not because they have to. *However,* I am realistic enough to know that it isn't going to happen, regardless of how disappointed I may be about that. :) > Please note the goal here is not to make 6to4 great, like many others we > hope to see 6to4 use diminish over time. "Hope is not a plan." Meanwhile, my main goal in posting was to make sure that to the extent that you(Comcast) intend to make changes to your 6to4 infrastructure that you take into account the current thinking about that, and I'm very pleased to hear that you have. best regards, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owen at delong.com Wed Apr 20 14:32:50 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Apr 2011 12:32:50 -0700 Subject: Comcast's 6to4 Relays In-Reply-To: <20110420163320.E4B9D4389C@smtp03.zmail.com> References: <20110420022657.6E18311C5@smtp02.zmail.com>, <20110420163320.E4B9D4389C@smtp03.zmail.com> Message-ID: <5C5402A0-AF54-4AF5-A759-3EC63F79514D@delong.com> 1. Yes. 2. Perhaps, but, it's minimal internal risk and the risk it poses to others can be mitigated by those others installing appropriate services on their own networks. 3. We agree here as well. Owen On Apr 20, 2011, at 9:33 AM, Bhoomi Jain wrote: > Mr. Delong, > > I am simply trying to explain that running a 6to4 on your network is a good idea, however advertising the anycast prefix to other networks has some risk, especially if you're experiencing problems with your Internet peerings. Hopefully Comcast will upgrade its capacity soon. I appreciate Mr. John's continued leadership and contribution to the IPv6. > > Sincerely, > Bhoomi Jain > > At 20 Apr 2011 14:51:48 +0200 (CEST) from Owen DeLong : > >> >> The better solution to that problem is to get additional 6to4 relays deployed closer to India. Perhaps encouraging Tata to take some leadership in that area, for example. >> I do not believe that the opening of the Comcast relays will harm BGP best path selection for the 6to4 prefix except in rather broken and/or pathological cases of BGP best path selection. Those cases should be relatively easy to identify and correct locally without preventing Comcast from significantly improving the 6to4 situation for the areas they serve by opening their relays. >> I applaud John for his leadership in this area and I think the IPv6 work being done by Comcast sets a good example for the community. As a Comcast customer, praising Comcast does not come easy to me, but, in this area, they are doing excellent things and should be commended. >> Owen >> >> Sent from my iPad >> On Apr 19, 2011, at 10:26 PM, Bhoomi Jain wrote: >>> Mr. John, >>> >>> I thank you for asking the advice of the community. >>> >>> As our colleagues suggest, having 6to4 relays inside the network helps to reduce the latency. Opening up your generous services to a larger Internet community by advertising the 192.88.99.0/24 BGP prefix outside the network could have extreme and unintended consequences. >>> >>> To give you an idea, a lot of the Internet in India depends on the service of the Tata companies, with international routing coming from Tata Communications AS 6453. Announcing 192.88.99.0/24 to 6453 as a customer, I would worry about its treatment as BGP best-path, in place of closer 6to4 relays. As you understand, these circuits are very far away, and also very full. This is not something I would recommend. >>> >>> Sincerely, >>> Bhoomi Jain >>> >>> At 19 Apr 2011 22:51:24 +0200 (CEST) from "Brzozowski, John" : >>> >>>> >>>> Folks, >>>> Since deploying our 6to4 relays, Comcast has observed a substantial >>>> reduction in the latency associated with the use of 6to4. As such we are >>>> contemplating further opening our relays for use by others. The >>>> availability of our 6to4 relays should improve the experience of others >>>> using 6to4 as a means to access content and services over IPv6. >>>> We have been open about our IPv6 activities and wanted to follow suit by >>>> reaching out to the community and soliciting feedback before moving >>>> forward. As always we wish to continue to advocate and support the >>>> universal deployment of IPv6. >>>> Please send any comments or questions to the list or if you wish to me >>>> directly. >>>> John >>>> ========================================= >>>> John Jason Brzozowski >>>> Comcast Cable >>>> e) mailto:john_brzozowski@[[cable.comcast.com]] >>>> o) 609-377-6594 >>>> m) 484-962-0060 >>>> w) [[http://www.comcast6.net]] >>>> ========================================= >>>> >>>> >>>> >> >> From owen at delong.com Wed Apr 20 14:50:03 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Apr 2011 12:50:03 -0700 Subject: Comcast's 6to4 Relays In-Reply-To: <4DAF2527.5090609@dougbarton.us> References: <4DAF2527.5090609@dougbarton.us> Message-ID: On Apr 20, 2011, at 11:25 AM, Doug Barton wrote: > On 04/20/2011 10:54, Brzozowski, John wrote: >> Doug, >> >> I am aware of the drafts you cited earlier, as Mikael mentions below the >> existence of the same will not result in 6to4 being turned off >> automatically or immediately. This process will likely take years. > > I was going to let this go, but after so many responses in the same vein I feel compelled to clarify. *I personally* believe that the answer to 6to4 is to just turn it off. These things have long tails because we insist that they do, not because they have to. *However,* I am realistic enough to know that it isn't going to happen, regardless of how disappointed I may be about that. :) > Turnning off the servers will not reduce the brokenness of 6to4, it will increase it. The best way to get rid of 6to4 is to deploy native IPv6. The best way to improve 6to4 behavior until that time is to deploy more, not less 6to4 relays. Hurricane Electric has proven this. Comcast has proven this. Every provider that has deployed more 6to4 relays has proven this. >> Please note the goal here is not to make 6to4 great, like many others we >> hope to see 6to4 use diminish over time. > > "Hope is not a plan." Meanwhile, my main goal in posting was to make sure that to the extent that you(Comcast) intend to make changes to your 6to4 infrastructure that you take into account the current thinking about that, and I'm very pleased to hear that you have. > The best way to make 6to4 diminish has always been and still remains: Deploy Native IPv6 Now. That's a plan and a necessity at this point, but, execution is still somewhat lagging. Owen From smb at cs.columbia.edu Wed Apr 20 15:02:21 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 20 Apr 2011 16:02:21 -0400 Subject: Comcast's 6to4 Relays In-Reply-To: References: <4DAF2527.5090609@dougbarton.us> Message-ID: <9D35C650-3D89-4859-91C7-900CA9406B57@cs.columbia.edu> On Apr 20, 2011, at 3:50 03PM, Owen DeLong wrote: > > On Apr 20, 2011, at 11:25 AM, Doug Barton wrote: > >> On 04/20/2011 10:54, Brzozowski, John wrote: >>> Doug, >>> >>> I am aware of the drafts you cited earlier, as Mikael mentions below the >>> existence of the same will not result in 6to4 being turned off >>> automatically or immediately. This process will likely take years. >> >> I was going to let this go, but after so many responses in the same vein I feel compelled to clarify. *I personally* believe that the answer to 6to4 is to just turn it off. These things have long tails because we insist that they do, not because they have to. *However,* I am realistic enough to know that it isn't going to happen, regardless of how disappointed I may be about that. :) >> > Turnning off the servers will not reduce the brokenness of 6to4, it will increase it. > > The best way to get rid of 6to4 is to deploy native IPv6. > The best way to improve 6to4 behavior until that time is to deploy more, not less 6to4 relays. > Hurricane Electric has proven this. > Comcast has proven this. > Every provider that has deployed more 6to4 relays has proven this. > >>> Please note the goal here is not to make 6to4 great, like many others we >>> hope to see 6to4 use diminish over time. >> >> "Hope is not a plan." Meanwhile, my main goal in posting was to make sure that to the extent that you(Comcast) intend to make changes to your 6to4 infrastructure that you take into account the current thinking about that, and I'm very pleased to hear that you have. >> > The best way to make 6to4 diminish has always been and still remains: > > Deploy Native IPv6 Now. > > That's a plan and a necessity at this point, but, execution is still somewhat lagging. > Of course, Comcast *is* deploying native IPv6; see, for example, http://mailman.nanog.org/pipermail/nanog/2011-January/031624.html It just takes a while -- and a non-trivial number of zorkmids -- to do things like replacing all of the non-v6 CPE. --Steve Bellovin, https://www.cs.columbia.edu/~smb From dougb at dougbarton.us Wed Apr 20 15:09:51 2011 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 20 Apr 2011 13:09:51 -0700 Subject: Comcast's 6to4 Relays In-Reply-To: References: <4DAF2527.5090609@dougbarton.us> Message-ID: <4DAF3D8F.4020703@dougbarton.us> On 04/20/2011 12:50, Owen DeLong wrote: > Turnning off the servers will not reduce the brokenness of 6to4, it will increase it. Depends on your definitions of "increase" and "broken." If all the relays disappeared tomorrow then the failure rate would be 100%, sure. But that would mean a single, (more or less) instant, deterministic failure that any modern OS ought to be able to handle intelligently; rather than the myriad of ways that 6to4 can half-succeed now. To me, that's a win. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owen at delong.com Wed Apr 20 15:41:51 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Apr 2011 16:41:51 -0400 Subject: Comcast's 6to4 Relays In-Reply-To: <4DAF3D8F.4020703@dougbarton.us> References: <4DAF2527.5090609@dougbarton.us> <4DAF3D8F.4020703@dougbarton.us> Message-ID: <57ACAC61-235A-42C1-80B2-1257AE2507E4@delong.com> Sent from my iPad On Apr 20, 2011, at 4:09 PM, Doug Barton wrote: > On 04/20/2011 12:50, Owen DeLong wrote: >> Turnning off the servers will not reduce the brokenness of 6to4, it will increase it. > > Depends on your definitions of "increase" and "broken." If all the relays disappeared tomorrow then the failure rate would be 100%, sure. But that would mean a single, (more or less) instant, deterministic failure that any modern OS ought to be able to handle intelligently; rather than the myriad of ways that 6to4 can half-succeed now. To me, that's a win. > > Uh, no. It would, indeed, be a single deterministic failure. However, most OS are coded that if there isn't native, they'll try 6to4 if it's turned on. Many OS have it turned on by default. As such, it would simply be a 100% failure, not one that was automatically dealt with in a rational or useful manner. It would require manual intervention on a large number of hosts. To me, that's not a win. That's a loss. The success rate for 6to4 today in most environments is close to 90%. There are many environments in widespread use today (hotel networks and airports come to mind) where IPv4 does not enjoy that level of success. Owen > From owen at delong.com Wed Apr 20 15:44:10 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Apr 2011 16:44:10 -0400 Subject: Comcast's 6to4 Relays In-Reply-To: <9D35C650-3D89-4859-91C7-900CA9406B57@cs.columbia.edu> References: <4DAF2527.5090609@dougbarton.us> <9D35C650-3D89-4859-91C7-900CA9406B57@cs.columbia.edu> Message-ID: <099F0108-18C8-4FBC-A0F7-F1C03B63579F@delong.com> >>> >> The best way to make 6to4 diminish has always been and still remains: >> >> Deploy Native IPv6 Now. >> >> That's a plan and a necessity at this point, but, execution is still somewhat lagging. >> > > Of course, Comcast *is* deploying native IPv6; see, for example, > http://mailman.nanog.org/pipermail/nanog/2011-January/031624.html > It just takes a while -- and a non-trivial number of zorkmids -- to > do things like replacing all of the non-v6 CPE. > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > Comcast was not the target of my comment... The networks saying Comcast shouldn't help the rest of the net by providing open 6to4 relays were the ones I was referring to. I again applaud Comcast's leadership on IPv6 to the end user, even if they haven't gotten it to me yet. ;-) Owen From randy at psg.com Wed Apr 20 16:02:15 2011 From: randy at psg.com (Randy Bush) Date: Thu, 21 Apr 2011 06:02:15 +0900 Subject: CIsco IOS bug info request In-Reply-To: References: <4DAE0396.7050409@dougbarton.us> <1303260727.3885.32.camel@butchlaptop.butchevans.com> <65DD3DFF-6E8F-4044-AC92-8523D7F6764B@eparsonage.com> Message-ID: > A "little" bit older one, but bigger - took down the whole internet: for a small value of "whole internet" same for ripe/duke experiment gone bad randy From jg at freedesktop.org Wed Apr 20 16:26:26 2011 From: jg at freedesktop.org (Jim Gettys) Date: Wed, 20 Apr 2011 17:26:26 -0400 Subject: Comcast's 6to4 Relays In-Reply-To: <099F0108-18C8-4FBC-A0F7-F1C03B63579F@delong.com> References: <4DAF2527.5090609@dougbarton.us> <9D35C650-3D89-4859-91C7-900CA9406B57@cs.columbia.edu> <099F0108-18C8-4FBC-A0F7-F1C03B63579F@delong.com> Message-ID: <4DAF4F82.3030201@freedesktop.org> On 04/20/2011 04:44 PM, Owen DeLong wrote: >>> The best way to make 6to4 diminish has always been and still remains: >>> >>> Deploy Native IPv6 Now. >>> >>> That's a plan and a necessity at this point, but, execution is still somewhat lagging. >>> >> Of course, Comcast *is* deploying native IPv6; see, for example, >> http://mailman.nanog.org/pipermail/nanog/2011-January/031624.html >> It just takes a while -- and a non-trivial number of zorkmids -- to >> do things like replacing all of the non-v6 CPE. >> >> >> --Steve Bellovin, https://www.cs.columbia.edu/~smb > Comcast was not the target of my comment... The networks saying Comcast shouldn't help the rest of the net by providing open 6to4 relays were the ones I was referring to. > > I again applaud Comcast's leadership on IPv6 to the end user, even if they haven't gotten > it to me yet. ;-) > They already have if you can run either 6rd or 6to4 and are a Comcast customer, even if you didn't happen to know they had. (Though they do plan to turn off the 6rd hack they were using this summer; their native trial and 6to4 work well enough to not need yet another transition mechanism). Their kind offer is to extend availability of their 6to4 relays to others who aren't even Comcast customers... (Says this reasonably happy participant in Comcast's IPv6 trial; my unhappiness is the state of CPE firmware, not with how well Comcast's end of things work; I plan to ditch commercial firmware on my home router for OpenWRT momentarily...) - Jim From owen at delong.com Wed Apr 20 18:55:02 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Apr 2011 18:55:02 -0500 Subject: Comcast's 6to4 Relays In-Reply-To: <4DAF4F82.3030201@freedesktop.org> References: <4DAF2527.5090609@dougbarton.us> <9D35C650-3D89-4859-91C7-900CA9406B57@cs.columbia.edu> <099F0108-18C8-4FBC-A0F7-F1C03B63579F@delong.com> <4DAF4F82.3030201@freedesktop.org> Message-ID: Sent from my iPad On Apr 20, 2011, at 4:26 PM, Jim Gettys wrote: > On 04/20/2011 04:44 PM, Owen DeLong wrote: >>>> The best way to make 6to4 diminish has always been and still remains: >>>> >>>> Deploy Native IPv6 Now. >>>> >>>> That's a plan and a necessity at this point, but, execution is still somewhat lagging. >>>> >>> Of course, Comcast *is* deploying native IPv6; see, for example, >>> http://mailman.nanog.org/pipermail/nanog/2011-January/031624.html >>> It just takes a while -- and a non-trivial number of zorkmids -- to >>> do things like replacing all of the non-v6 CPE. >>> >>> >>> --Steve Bellovin, https://www.cs.columbia.edu/~smb >> Comcast was not the target of my comment... The networks saying Comcast shouldn't help the rest of the net by providing open 6to4 relays were the ones I was referring to. >> >> I again applaud Comcast's leadership on IPv6 to the end user, even if they haven't gotten >> it to me yet. ;-) >> > > They already have if you can run either 6rd or 6to4 and are a Comcast customer, even if you didn't happen to know they had. (Though they do plan to turn off the 6rd hack they were using this summer; their native trial and 6to4 work well enough to not need yet another transition mechanism). > I'm already running IPv6 over 6in4 tunnels to my cool routers. 6rd is not an improvement. I'm looking forward to the day when Comcast can deliver straight native IPv6 to me. > Their kind offer is to extend availability of their 6to4 relays to others who aren't even Comcast customers... > > (Says this reasonably happy participant in Comcast's IPv6 trial; my unhappiness is the state of CPE firmware, not with how well Comcast's end of things work; I plan to ditch commercial firmware on my home router for OpenWRT momentarily...) > - Jim > > lol... The commercial JunOS on my home gateway seems to be working OK. Owen From trejrco at gmail.com Wed Apr 20 19:57:23 2011 From: trejrco at gmail.com (TJ) Date: Wed, 20 Apr 2011 20:57:23 -0400 Subject: Comcast's 6to4 Relays In-Reply-To: <4DAF3D8F.4020703@dougbarton.us> References: <4DAF2527.5090609@dougbarton.us> <4DAF3D8F.4020703@dougbarton.us> Message-ID: On Wed, Apr 20, 2011 at 16:09, Doug Barton wrote: > On 04/20/2011 12:50, Owen DeLong wrote: > >> Turnning off the servers will not reduce the brokenness of 6to4, it will >> increase it. >> > > Depends on your definitions of "increase" and "broken." If all the relays > disappeared tomorrow then the failure rate would be 100%, sure. But that > would mean a single, (more or less) instant, deterministic failure that any > modern OS ought to be able to handle intelligently; rather than the myriad > of ways that 6to4 can half-succeed now. To me, that's a win. While I can appreciate that 6to4 is far from perfect, and can create broken situations - I will also admit to using 6to4 on more than an occasional basis ... whether that be because: - my aircard gets a public IPv4 address, and thus 6to4 spins up automatically - my Linksys CPE, out of the box, does 6to4 (SLAAC-advertising a prefix) - thus all of my home PCs do it as well (Win*, Ubuntu, etc.) I find 6to4 to be far superior to no IPv6 connectivity, far easier than launching a TSP client (which I also have, just in case) ... and, in fact, to largely "just work" for all of my machines. More relays will do nothing but make this better, and as native IPv6 becomes available I will happily (and automatically!) move to that instead. /TJ ... also a happy Comcast 6RD-beta user right now, so technically I am not using 6to4 at home *right now* (but will be using 6to4 again after June 30th, when the 6RD trial ends). From David.Curran at windstream.com Wed Apr 20 20:35:22 2011 From: David.Curran at windstream.com (Curran, David) Date: Wed, 20 Apr 2011 20:35:22 -0500 Subject: Bandwidth growth Message-ID: I'm interested in any evidence (even anecdotal) that general Internet usage (and more importantly, link utilization) has increased at higher rates in the last 6-12 months than in previous periods. Any graphs or otherwise would be greatly appreciated. The purpose is for an internal research project and this data will only be used internally and will not be shared, nor will the sources. Thanks in advance, David Curran I New Technology Planning I Windstream O-864.331.7132 I C-864.905.0522 I david.curran at windstream.com *************************************************************************************** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. From patrick at ianai.net Wed Apr 20 20:55:30 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 20 Apr 2011 21:55:30 -0400 Subject: Bandwidth growth In-Reply-To: References: Message-ID: <2AE1BD67-2C59-4333-A5D1-9FE9B61EA438@ianai.net> On Apr 20, 2011, at 9:35 PM, Curran, David wrote: > I'm interested in any evidence (even anecdotal) that general Internet usage (and more importantly, link utilization) has increased at higher rates in the last 6-12 months than in previous periods. Any graphs or otherwise would be greatly appreciated. The purpose is for an internal research project and this data will only be used internally and will not be shared, nor will the sources. Etc. I don't know if that proves your theory. And one could argue public IX stats are actually not representative of growth, since many networks move peers to private connections as they grow. But it is data, and it is available. -- TTFN, patrick From adrian at creative.net.au Wed Apr 20 21:36:54 2011 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 21 Apr 2011 10:36:54 +0800 Subject: Bandwidth growth In-Reply-To: <2AE1BD67-2C59-4333-A5D1-9FE9B61EA438@ianai.net> References: <2AE1BD67-2C59-4333-A5D1-9FE9B61EA438@ianai.net> Message-ID: <20110421023654.GE13776@skywalker.creative.net.au> If it's a true research project, wouldn't you really be interested in both evidence for/against? :-) Just my 2c here, Adrian On Wed, Apr 20, 2011, Patrick W. Gilmore wrote: > On Apr 20, 2011, at 9:35 PM, Curran, David wrote: > > > I'm interested in any evidence (even anecdotal) that general Internet usage (and more importantly, link utilization) has increased at higher rates in the last 6-12 months than in previous periods. Any graphs or otherwise would be greatly appreciated. The purpose is for an internal research project and this data will only be used internally and will not be shared, nor will the sources. > > > > > > > > Etc. > > I don't know if that proves your theory. And one could argue public IX stats are actually not representative of growth, since many networks move peers to private connections as they grow. But it is data, and it is available. > > -- > TTFN, > patrick > -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From millnert at gmail.com Wed Apr 20 21:13:24 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 20 Apr 2011 22:13:24 -0400 Subject: Bandwidth growth In-Reply-To: <2AE1BD67-2C59-4333-A5D1-9FE9B61EA438@ianai.net> References: <2AE1BD67-2C59-4333-A5D1-9FE9B61EA438@ianai.net> Message-ID: On Wed, Apr 20, 2011 at 9:55 PM, Patrick W. Gilmore wrote: > On Apr 20, 2011, at 9:35 PM, Curran, David wrote: > >> I'm interested in any evidence (even anecdotal) that general Internet usage (and more importantly, link utilization) has increased at higher rates in the last 6-12 months than in previous periods. ?Any graphs or otherwise would be greatly appreciated. ?The purpose is for an internal research project and this data will only be used internally and will not be shared, nor will the sources. > > > > > > Growth unsurprisingly also varies by region: http://www.msk-ix.ru/eng/traffic.html It has seen plenty of growth recently. If any MSK-IX staff reads this, a 3-, 5- or all-year graph would be an interesting add! > I don't know if that proves your theory. ?And one could argue public IX stats are actually not representative of growth, since many networks move peers to private connections as they grow. ?But it is data, and it is available. Aggregate IX statistics also fail to identify what part of the growth is due to people moving traffic onto IX:es, from private connections (transits). It is certainly data, aggregate data. I wouldn't hang my heart-lung machine off of it's accuracy in predicting individual networks short-term traffic developments though, so to speak. :) Regards, Martin From jess.petty at gmail.com Wed Apr 20 23:32:47 2011 From: jess.petty at gmail.com (Jess Petty) Date: Wed, 20 Apr 2011 21:32:47 -0700 Subject: NEBS compliant Server In-Reply-To: <29911217.2823.1303219433626.JavaMail.root@benjamin.baylink.com> References: <29911217.2823.1303219433626.JavaMail.root@benjamin.baylink.com> Message-ID: > > We use Sun Netra. > Thanks, Jess From savyasachi.choudhary at gmail.com Thu Apr 21 01:35:54 2011 From: savyasachi.choudhary at gmail.com (Savyasachi Choudhary) Date: Thu, 21 Apr 2011 12:05:54 +0530 Subject: NANOG Digest, Vol 37, Issue 121 In-Reply-To: References: Message-ID: I have a doubt in ISIS. While redistributing routes from other protocols, how the metric is decided? OSPF has deccribed this in RFC 2328 Section 16.4 : '4) Let X be the cost specified by the preferred routing table entry for the ASBR/forwarding address, and Y the cost specified in the LSA. X is in terms of the link state metric, and Y is a type 1 or 2 external metric. (5) Look up the routing table entry for the destination N. If no entry exists for N, install the AS external path to N, with next hop equal to the list of next hops to the forwarding address, and advertising router equal to ASBR. If the external metric type is 1, then the path-type is set to type 1 external and the cost is equal to X+Y. If the external metric type is 2, the path-type is set to type 2 external, the link state component of the route's cost is X, and the type 2 cost is Y.' What is the behavior in ISIS? Regards, Savyasachi 7676077879 On Thu, Feb 10, 2011 at 6:01 AM, wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: Looking for an IPv6 naysayer... (Jack Bates) > 2. Re: Looking for an IPv6 naysayer... (Mark Andrews) > 3. Re: Looking for an IPv6 naysayer... (Jack Bates) > 4. Re: Looking for an IPv6 naysayer... (Mark Andrews) > 5. Re: Looking for an IPv6 naysayer... (Joel Jaeggli) > 6. Re: Looking for an IPv6 naysayer... (Owen DeLong) > 7. Re: Looking for an IPv6 naysayer... (Mark Andrews) > 8. Re: Looking for an IPv6 naysayer... (Matthew Kaufman) > 9. Re: IPv6 - a noobs prespective (Joel Jaeggli) > 10. Re: Looking for an IPv6 naysayer... (Jack Bates) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 09 Feb 2011 18:00:19 -0600 > From: Jack Bates > Subject: Re: Looking for an IPv6 naysayer... > To: George Bonser > Cc: nanog at nanog.org > Message-ID: <4D532A93.50504 at brightok.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2/9/2011 5:47 PM, George Bonser wrote: > > I have yet to see a broadband provider that configures a network so that > > individual nodes in the home network get global IPs. > Bridge only CPE's given off this node. > > 1043 IP addresses handed out > 1024 Unique interfaces > > Looks like customers aren't always big on more than 1 IP. :) > > > Jack > > > > > ------------------------------ > > Message: 2 > Date: Thu, 10 Feb 2011 11:00:45 +1100 > From: Mark Andrews > Subject: Re: Looking for an IPv6 naysayer... > To: david raistrick > Cc: nanog at nanog.org > Message-ID: <20110210000045.EA41D9DCA79 at drugs.dv.isc.org> > > > In message , > david rai > strick writes: > > On Wed, 9 Feb 2011, Jens Link wrote: > > > > > Scott Helms writes: > > > > > >> IPv6 for some ISPs will be extraordinarily painful because of legacy > > >> layer 2 gear > > > > > > I don't feel sorry for them. We know that IPv6 is coming for how long? > > > 15years? 10year? 5years? Well if you only read the mainstream media you > > > > And at what point during that time did they have any vendor gear they > > could purchase that -would- support v6? At -best- during the last 5 > > years, but I'd put money on that even today they can't purchase gear with > > adequate v6 support. > > And who's fault is that? The ISP's and the vendors. The ISP's > could have been requesting IPv6 support. The ISP's could have been > running trials and providing feedback to the vendors. The vendors > could have asked the ISP's to trail their IPv6 products. > > We have been saying for years "make sure you are ready". That means > buying and testing equipment. Lots of those that tested went on to > production years ago. > > As a vendor we like feedback on our products, good or bad. It's > hard to work in a vacuum. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > ------------------------------ > > Message: 3 > Date: Wed, 09 Feb 2011 18:01:46 -0600 > From: Jack Bates > Subject: Re: Looking for an IPv6 naysayer... > To: "Robert E. Seastrom" > Cc: nanog at nanog.org > Message-ID: <4D532AEA.2090505 at brightok.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2/9/2011 5:56 PM, Robert E. Seastrom wrote: > > Or 6rd and go native on their permanent prefix as the forklift upgrade > > schedule allows. Oh well, it's better than nothing or Crummier Grade > NAT. > > ds-lite tends to be friendlier LSN from various tests, and is native v6. > > > Jack > > > > ------------------------------ > > Message: 4 > Date: Thu, 10 Feb 2011 11:07:26 +1100 > From: Mark Andrews > Subject: Re: Looking for an IPv6 naysayer... > To: "George Bonser" > Cc: nanog at nanog.org > Message-ID: <20110210000726.3CABE9DCC09 at drugs.dv.isc.org> > > > In message < > 5A6D953473350C4B9995546AFE9939EE0BC1397D at RWC-EX1.corp.seven.com>, " > George Bonser" writes: > > > Cost's might be lower but service will be worse. NAT breaks a lot of > > > applications file sharing will not work properly and running your own > > > web server at home will not work properly. Well you always get what > > you > > > pay for and people will buy any crap if it is cheap enough. > > >=20 > > > Jens > > > > While that is true, it is no worse than the situation right now. In the > > US, the vast majority of users are already behind a NAT (I would say > > over 90% of them are) so they are already experiencing this breakage. =20 > > But for the most part they can work around breakages with a single NAT. > Double NAT prevents most of the work arounds working. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > ------------------------------ > > Message: 5 > Date: Wed, 09 Feb 2011 16:08:10 -0800 > From: Joel Jaeggli > Subject: Re: Looking for an IPv6 naysayer... > To: George Bonser > Cc: nanog at nanog.org > Message-ID: <4D532C6A.20209 at bogus.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 2/9/11 3:43 PM, George Bonser wrote: > >> Almost none of the broadband providers in the US NAT their customers. > > > > Well, I suppose I have been unlucky then because every single one I have > > had has NATed me. I had a "real" IP when I had dialup, but I got NAT > > when I went broadband. I have a friend that has another service and she > > is NATed too. Boot up in her network and you get 192.168.1.x > > The the cpe... In all likelihood it has a public ip on the outside. > > > > > > > > > > > > ------------------------------ > > Message: 6 > Date: Wed, 9 Feb 2011 16:10:46 -0800 > From: Owen DeLong > Subject: Re: Looking for an IPv6 naysayer... > To: david raistrick > Cc: nanog at nanog.org > Message-ID: <582356A9-5ADC-4244-8BA0-EE1F2F3EF388 at delong.com> > Content-Type: text/plain; charset=us-ascii > > > On Feb 9, 2011, at 3:16 PM, david raistrick wrote: > > > On Wed, 9 Feb 2011, Owen DeLong wrote: > > > >>>> I don't feel sorry for them. We know that IPv6 is coming for how long? > >>>> 15years? 10year? 5years? Well if you only read the mainstream media > you > >>> > >>> And at what point during that time did they have any vendor gear they > could purchase that -would- support v6? At -best- during the last 5 years, > but I'd put money on that even today they can't purchase gear with adequate > v6 support. > >>> > >> This is largely the result of the fact that they did not demand it from > their > >> vendors during that time. > > > > > > I was purchasing for and building small SP networks during that time. > > > > Requiring v6 of our vendors would have meant we just never got anything, > so we'd have never provided service. Come to think if it, maybe it -would- > have been better for everyone involved (except those of us who just got > paychecks and experience out of it) to just simply not do it - but we didn't > know that at the time 15 years ago! > > > Requiring it delivered day one, sure. Putting in a requirement for "Will > support" so that they are required to provide an upgrade path, OTOH, to me > seemed like it was basic good business sense. It worked out pretty well for > the organizations I was working for back then. We got upgradeable hardware > and the vendors got awareness of the demand. Admittedly, I wasn't working in > the last mile arena. However, pressuring vendors is possible without > sacrificing immediate needs. > > > > > Vendor C and J don't provide gear that fits into all network topologies > (WISPs, MTU DSL, and smallish ADSL roll outs come to mind, certain during > the time period in question. Sure, they eventually bought products in those > markets...but even still, I had sub 6 figure budgets to build with - I > certainly had no leverage). > > > I don't think that networks with sub-6-figure buildouts are the ones we're > too worried about right now. > They can probably upgrade for sub-6-figure amounts. > > Owen > > > > > ------------------------------ > > Message: 7 > Date: Thu, 10 Feb 2011 11:22:31 +1100 > From: Mark Andrews > Subject: Re: Looking for an IPv6 naysayer... > To: Scott Helms > Cc: nanog at nanog.org > Message-ID: <20110210002231.23F0E9DCFDD at drugs.dv.isc.org> > > > In message <4D531B52.70404 at ispalliance.net>, Scott Helms writes: > > On 2/9/2011 5:48 PM, Owen DeLong wrote: > > > On Feb 9, 2011, at 12:00 PM, david raistrick wrote: > > > > > >> On Wed, 9 Feb 2011, Jens Link wrote: > > >> > > >>> Scott Helms writes: > > >>> > > >>>> IPv6 for some ISPs will be extraordinarily painful because of legacy > > >>>> layer 2 gear > > >>> I don't feel sorry for them. We know that IPv6 is coming for how > long? > > >>> 15years? 10year? 5years? Well if you only read the mainstream media > you > > >> And at what point during that time did they have any vendor gear they > coul > > d purchase that -would- support v6? At -best- during the last 5 years, > but > > I'd put money on that even today they can't purchase gear with adequate > v6 su > > pport. > > >> > > > This is largely the result of the fact that they did not demand it from > the > > ir > > > vendors during that time. > > > > > > Owen > > > > > > > > > > > Absolutely, just as the ISPs didn't see demand, and don't today, from > > their users and thus the circle of blame is complete :) > > And some of their customers have been asking for IPv6 all along. > > I started asking my ISP at home in 2003. I suspect if all the ISPs > here were honest they would say that they have had a trickle of > IPv6 requests for the last 8 years. > > Mark > > Date: Mon, 16 Jun 2003 09:54:05 +1000 > To: Mark_Andrews at isc.org > From: cablesupport at optusnet.com.au > Subject: Re: [TT#6556559] HELPDESK Feedback Form - Mon Jun 16 09:52:50 2003 > > Return-Path: nobody at pts.optusnet.com.au > Delivery-Date: Mon Jun 16 10:00:00 2003 > Return-Path: > X-Original-To: marka at farside.isc.org > Delivered-To: marka at farside.isc.org > X-Loop: pts > Reply-To: cablesupport at optusnet.com.au > > Hello, > > Thank you for your email regarding the OptusNet Cable service. > > At the moment there are no plans for any IPv6 deployment, when this is due > to happen we will notify all customers. > > Regards, > Alex > OptusNet Cable Technical Support > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > ------------------------------ > > Message: 8 > Date: Wed, 09 Feb 2011 16:27:51 -0800 > From: Matthew Kaufman > Subject: Re: Looking for an IPv6 naysayer... > To: Jack Bates > Cc: nanog at nanog.org > Message-ID: <4D533107.5010202 at matthew.at> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2/9/2011 4:00 PM, Jack Bates wrote: > > On 2/9/2011 5:47 PM, George Bonser wrote: > >> I have yet to see a broadband provider that configures a network so that > >> individual nodes in the home network get global IPs. > > Bridge only CPE's given off this node. > > > > 1043 IP addresses handed out > > 1024 Unique interfaces > > > > Looks like customers aren't always big on more than 1 IP. :) > > > > > > Jack > > > > > And meanwhile Comcast has announced one /64-per-household service for > IPv6... guess they didn't get the memo from Owen about how every class > of home appliances will need its own subnet. > > Matthew Kaufman > > > > ------------------------------ > > Message: 9 > Date: Wed, 09 Feb 2011 16:29:54 -0800 > From: Joel Jaeggli > Subject: Re: IPv6 - a noobs prespective > To: Owen DeLong > Cc: nanog at nanog.org > Message-ID: <4D533182.6020505 at bogus.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 2/9/11 2:22 PM, Owen DeLong wrote: > > There have been IPv6 for dummies sessions at many past NANOGs. > > > > If NANOG is willing to provide time and space for them at future events, > I will > > be happy to conduct the tutorial sessions. > > program committee would no doubt love to hear from you. > > > > Owen > > > > On Feb 9, 2011, at 10:30 AM, Mike Lyon wrote: > > > >> With the recent allocation of the last existing IPv4 /8s (which now kind > of > >> puts pressure on going v6), it would be wonderful if at the next couple > of > >> NANOGs if there could be an IPv6 for dummies session or two :) > >> > >> -Mike > >> > >> > >> On Wed, Feb 9, 2011 at 10:22 AM, Jack Bates > wrote: > >> > >>> On 2/9/2011 12:03 PM, William Herrin wrote: > >>> > >>>> The thing that terrifies me about deploying IPv6 is that apps > >>>> compatible with both are programmed to attempt IPv6 before IPv4. This > >>>> means my first not-quite-correct IPv6 deployments are going to break > >>>> my apps that are used to not having and therefore not trying IPv6. But > >>>> that's not the worst part... as the folks my customers interact with > >>>> over the next couple of years make their first not-quite-correct IPv6 > >>>> deployments, my access to them is going to break again. And again. And > >>>> again. And I won't have the foggiest idea who's next until I get the > >>>> call that such-and-such isn't working right. > >>>> > >>> > >>> What scares me most is that every time I upgrade a router to support > needed > >>> hardware or some badly needed IPv6 feature, something else breaks. > Sometimes > >>> it's just the router crashes on a specific IPv6 command entered at CLI > (C) > >>> or as nasty as NSR constantly crashing the slave (J); the fixes > generally > >>> requiring me to upgrade again to the latest cutting edge releases which > >>> everyone hates (where I'm sure I'll find MORE bugs). > >>> > >>> The worst is when you're the first to find the bug(which I'm not even > sure > >>> how it's possible given how simplistic my configs are, isis > multitopology, > >>> iBGP, NSR, a few acls and route-maps/policies), it takes 3-6 months or > so to > >>> track it down, and then it's put only in the next upcoming release (not > out > >>> yet) and backported to the last release. > >>> > >>> > >>> Jack (hates all routers equally, doesn't matter who makes it) > >>> > >>> > > > > > > > > > > > ------------------------------ > > Message: 10 > Date: Wed, 09 Feb 2011 18:30:46 -0600 > From: Jack Bates > Subject: Re: Looking for an IPv6 naysayer... > To: matthew at matthew.at > Cc: nanog at nanog.org > Message-ID: <4D5331B6.60902 at brightok.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2/9/2011 6:27 PM, Matthew Kaufman wrote: > > > > And meanwhile Comcast has announced one /64-per-household service for > > IPv6... guess they didn't get the memo from Owen about how every class > > of home appliances will need its own subnet. > > I wonder if their RIR justification was for /64 to household or /48. :) > > Jack > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 37, Issue 121 > ************************************** > From savyasachi.choudhary at gmail.com Thu Apr 21 01:55:51 2011 From: savyasachi.choudhary at gmail.com (Savyasachi Choudhary) Date: Thu, 21 Apr 2011 12:25:51 +0530 Subject: Doubt in ISIS Message-ID: I have a doubt in ISIS. While redistributing routes from other protocols, how the metric is decided? OSPF has deccribed this in RFC 2328 Section 16.4 : '4) Let X be the cost specified by the preferred routing table entry for the ASBR/forwarding address, and Y the cost specified in the LSA. X is in terms of the link state metric, and Y is a type 1 or 2 external metric. (5) Look up the routing table entry for the destination N. If no entry exists for N, install the AS external path to N, with next hop equal to the list of next hops to the forwarding address, and advertising router equal to ASBR. If the external metric type is 1, then the path-type is set to type 1 external and the cost is equal to X+Y. If the external metric type is 2, the path-type is set to type 2 external, the link state component of the route's cost is X, and the type 2 cost is Y.' What is the behavior in ISIS? Regards, Savyasachi 7676077879 On Thu, Apr 21, 2011 at 12:07 PM, wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: CIsco IOS bug info request (Randy Bush) > 2. Re: Comcast's 6to4 Relays (Jim Gettys) > 3. Re: Comcast's 6to4 Relays (Owen DeLong) > 4. Re: Comcast's 6to4 Relays (TJ) > 5. Bandwidth growth (Curran, David) > 6. Re: Bandwidth growth (Patrick W. Gilmore) > 7. Re: Bandwidth growth (Adrian Chadd) > 8. Re: Bandwidth growth (Martin Millnert) > 9. Re: NEBS compliant Server (Jess Petty) > 10. Re: NANOG Digest, Vol 37, Issue 121 (Savyasachi Choudhary) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 21 Apr 2011 06:02:15 +0900 > From: Randy Bush > Subject: Re: CIsco IOS bug info request > To: Ingo Flaschberger > Cc: nanog at nanog.org > Message-ID: > Content-Type: text/plain; charset=US-ASCII > > > A "little" bit older one, but bigger - took down the whole internet: > > for a small value of "whole internet" > > same for ripe/duke experiment gone bad > > randy > > > > ------------------------------ > > Message: 2 > Date: Wed, 20 Apr 2011 17:26:26 -0400 > From: Jim Gettys > Subject: Re: Comcast's 6to4 Relays > To: nanog at nanog.org > Message-ID: <4DAF4F82.3030201 at freedesktop.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 04/20/2011 04:44 PM, Owen DeLong wrote: > >>> The best way to make 6to4 diminish has always been and still remains: > >>> > >>> Deploy Native IPv6 Now. > >>> > >>> That's a plan and a necessity at this point, but, execution is still > somewhat lagging. > >>> > >> Of course, Comcast *is* deploying native IPv6; see, for example, > >> http://mailman.nanog.org/pipermail/nanog/2011-January/031624.html > >> It just takes a while -- and a non-trivial number of zorkmids -- to > >> do things like replacing all of the non-v6 CPE. > >> > >> > >> --Steve Bellovin, https://www.cs.columbia.edu/~smb > > Comcast was not the target of my comment... The networks saying Comcast > shouldn't help the rest of the net by providing open 6to4 relays were the > ones I was referring to. > > > > I again applaud Comcast's leadership on IPv6 to the end user, even if > they haven't gotten > > it to me yet. ;-) > > > > They already have if you can run either 6rd or 6to4 and are a Comcast > customer, even if you didn't happen to know they had. (Though they do > plan to turn off the 6rd hack they were using this summer; their native > trial and 6to4 work well enough to not need yet another transition > mechanism). > > Their kind offer is to extend availability of their 6to4 relays to > others who aren't even Comcast customers... > > (Says this reasonably happy participant in Comcast's IPv6 trial; my > unhappiness is the state of CPE firmware, not with how well Comcast's > end of things work; I plan to ditch commercial firmware on my home > router for OpenWRT momentarily...) > - Jim > > > > > > ------------------------------ > > Message: 3 > Date: Wed, 20 Apr 2011 18:55:02 -0500 > From: Owen DeLong > Subject: Re: Comcast's 6to4 Relays > To: Jim Gettys > Cc: "nanog at nanog.org" > Message-ID: > Content-Type: text/plain; charset=us-ascii > > > > Sent from my iPad > > On Apr 20, 2011, at 4:26 PM, Jim Gettys wrote: > > > On 04/20/2011 04:44 PM, Owen DeLong wrote: > >>>> The best way to make 6to4 diminish has always been and still remains: > >>>> > >>>> Deploy Native IPv6 Now. > >>>> > >>>> That's a plan and a necessity at this point, but, execution is still > somewhat lagging. > >>>> > >>> Of course, Comcast *is* deploying native IPv6; see, for example, > >>> http://mailman.nanog.org/pipermail/nanog/2011-January/031624.html > >>> It just takes a while -- and a non-trivial number of zorkmids -- to > >>> do things like replacing all of the non-v6 CPE. > >>> > >>> > >>> --Steve Bellovin, https://www.cs.columbia.edu/~smb > >> Comcast was not the target of my comment... The networks saying Comcast > shouldn't help the rest of the net by providing open 6to4 relays were the > ones I was referring to. > >> > >> I again applaud Comcast's leadership on IPv6 to the end user, even if > they haven't gotten > >> it to me yet. ;-) > >> > > > > They already have if you can run either 6rd or 6to4 and are a Comcast > customer, even if you didn't happen to know they had. (Though they do plan > to turn off the 6rd hack they were using this summer; their native trial and > 6to4 work well enough to not need yet another transition mechanism). > > > I'm already running IPv6 over 6in4 tunnels to my cool routers. 6rd is not > an improvement. > > I'm looking forward to the day when Comcast can deliver straight native > IPv6 to me. > > > Their kind offer is to extend availability of their 6to4 relays to others > who aren't even Comcast customers... > > > > (Says this reasonably happy participant in Comcast's IPv6 trial; my > unhappiness is the state of CPE firmware, not with how well Comcast's end of > things work; I plan to ditch commercial firmware on my home router for > OpenWRT momentarily...) > > - Jim > > > > > lol... The commercial JunOS on my home gateway seems to be working OK. > > Owen > > > > > ------------------------------ > > Message: 4 > Date: Wed, 20 Apr 2011 20:57:23 -0400 > From: TJ > Subject: Re: Comcast's 6to4 Relays > To: nanog at nanog.org > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, Apr 20, 2011 at 16:09, Doug Barton wrote: > > > On 04/20/2011 12:50, Owen DeLong wrote: > > > >> Turnning off the servers will not reduce the brokenness of 6to4, it will > >> increase it. > >> > > > > Depends on your definitions of "increase" and "broken." If all the relays > > disappeared tomorrow then the failure rate would be 100%, sure. But that > > would mean a single, (more or less) instant, deterministic failure that > any > > modern OS ought to be able to handle intelligently; rather than the > myriad > > of ways that 6to4 can half-succeed now. To me, that's a win. > > > > While I can appreciate that 6to4 is far from perfect, and can create broken > situations - I will also admit to using 6to4 on more than an occasional > basis ... whether that be because: > > - my aircard gets a public IPv4 address, and thus 6to4 spins up > automatically > - my Linksys CPE, out of the box, does 6to4 (SLAAC-advertising a prefix) > - thus all of my home PCs do it as well (Win*, Ubuntu, etc.) > > I find 6to4 to be far superior to no IPv6 connectivity, far easier than > launching a TSP client (which I also have, just in case) ... and, in fact, > to largely "just work" for all of my machines. More relays will do nothing > but make this better, and as native IPv6 becomes available I will happily > (and automatically!) move to that instead. > > > /TJ ... also a happy Comcast 6RD-beta user right now, so technically I am > not using 6to4 at home *right now* (but will be using 6to4 again after June > 30th, when the 6RD trial ends). > > > ------------------------------ > > Message: 5 > Date: Wed, 20 Apr 2011 20:35:22 -0500 > From: "Curran, David" > Subject: Bandwidth growth > To: "nanog at nanog.org" > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > I'm interested in any evidence (even anecdotal) that general Internet usage > (and more importantly, link utilization) has increased at higher rates in > the last 6-12 months than in previous periods. Any graphs or otherwise > would be greatly appreciated. The purpose is for an internal research > project and this data will only be used internally and will not be shared, > nor will the sources. > > Thanks in advance, > > David Curran I New Technology Planning I Windstream > O-864.331.7132 I C-864.905.0522 I david.curran at windstream.com david.curran at windstream.com> > > *************************************************************************************** > The information contained in this message, including attachments, may > contain > privileged or confidential information that is intended to be delivered > only to the > person identified above. If you are not the intended recipient, or the > person > responsible for delivering this message to the intended recipient, > Windstream requests > that you immediately notify the sender and asks that you do not read the > message or its > attachments, and that you delete them without copying or sending them to > anyone else. > > ------------------------------ > > Message: 6 > Date: Wed, 20 Apr 2011 21:55:30 -0400 > From: "Patrick W. Gilmore" > Subject: Re: Bandwidth growth > To: NANOG list > Message-ID: <2AE1BD67-2C59-4333-A5D1-9FE9B61EA438 at ianai.net> > Content-Type: text/plain; charset=us-ascii > > On Apr 20, 2011, at 9:35 PM, Curran, David wrote: > > > I'm interested in any evidence (even anecdotal) that general Internet > usage (and more importantly, link utilization) has increased at higher rates > in the last 6-12 months than in previous periods. Any graphs or otherwise > would be greatly appreciated. The purpose is for an internal research > project and this data will only be used internally and will not be shared, > nor will the sources. > > > > > > > > Etc. > > I don't know if that proves your theory. And one could argue public IX > stats are actually not representative of growth, since many networks move > peers to private connections as they grow. But it is data, and it is > available. > > -- > TTFN, > patrick > > > > > ------------------------------ > > Message: 7 > Date: Thu, 21 Apr 2011 10:36:54 +0800 > From: Adrian Chadd > Subject: Re: Bandwidth growth > To: "Patrick W. Gilmore" > Cc: NANOG list > Message-ID: <20110421023654.GE13776 at skywalker.creative.net.au> > Content-Type: text/plain; charset=us-ascii > > If it's a true research project, wouldn't you really be interested in both > evidence for/against? :-) > > Just my 2c here, > > > Adrian > > On Wed, Apr 20, 2011, Patrick W. Gilmore wrote: > > On Apr 20, 2011, at 9:35 PM, Curran, David wrote: > > > > > I'm interested in any evidence (even anecdotal) that general Internet > usage (and more importantly, link utilization) has increased at higher rates > in the last 6-12 months than in previous periods. Any graphs or otherwise > would be greatly appreciated. The purpose is for an internal research > project and this data will only be used internally and will not be shared, > nor will the sources. > > > > > > > > > > > > > > > > Etc. > > > > I don't know if that proves your theory. And one could argue public IX > stats are actually not representative of growth, since many networks move > peers to private connections as they grow. But it is data, and it is > available. > > > > -- > > TTFN, > > patrick > > > > -- > - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid > Support - > - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA > - > > > > ------------------------------ > > Message: 8 > Date: Wed, 20 Apr 2011 22:13:24 -0400 > From: Martin Millnert > Subject: Re: Bandwidth growth > To: "Patrick W. Gilmore" > Cc: NANOG list > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, Apr 20, 2011 at 9:55 PM, Patrick W. Gilmore > wrote: > > On Apr 20, 2011, at 9:35 PM, Curran, David wrote: > > > >> I'm interested in any evidence (even anecdotal) that general Internet > usage (and more importantly, link utilization) has increased at higher rates > in the last 6-12 months than in previous periods. ?Any graphs or otherwise > would be greatly appreciated. ?The purpose is for an internal research > project and this data will only be used internally and will not be shared, > nor will the sources. > > > > > > > > > > > > > > Growth unsurprisingly also varies by region: > http://www.msk-ix.ru/eng/traffic.html > It has seen plenty of growth recently. > > If any MSK-IX staff reads this, a 3-, 5- or all-year graph would be an > interesting add! > > > I don't know if that proves your theory. ?And one could argue public IX > stats are actually not representative of growth, since many networks move > peers to private connections as they grow. ?But it is data, and it is > available. > > Aggregate IX statistics also fail to identify what part of the growth > is due to people moving traffic onto IX:es, from private connections > (transits). It is certainly data, aggregate data. I wouldn't hang my > heart-lung machine off of it's accuracy in predicting individual > networks short-term traffic developments though, so to speak. :) > > Regards, > Martin > > > > ------------------------------ > > Message: 9 > Date: Wed, 20 Apr 2011 21:32:47 -0700 > From: Jess Petty > Subject: Re: NEBS compliant Server > To: NANOG > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > > > > We use Sun Netra. > > > Thanks, > Jess > > > ------------------------------ > > Message: 10 > Date: Thu, 21 Apr 2011 12:05:54 +0530 > From: Savyasachi Choudhary > Subject: Re: NANOG Digest, Vol 37, Issue 121 > To: nanog at nanog.org > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > I have a doubt in ISIS. > While redistributing routes from other protocols, how the metric is > decided? > OSPF has deccribed this in RFC 2328 Section 16.4 : > > '4) Let X be the cost specified by the preferred routing > table > > entry for the ASBR/forwarding address, and Y the cost > specified in the LSA. X is in terms of the link state > metric, and Y is a type 1 or 2 external metric. > > (5) Look up the routing table entry for the destination N. If > no entry exists for N, install the AS external path to N, > with next hop equal to the list of next hops to the > forwarding address, and advertising router equal to ASBR. > If the external metric type is 1, then the path-type is set > to type 1 external and the cost is equal to X+Y. If the > external metric type is 2, the path-type is set to type 2 > external, the link state component of the route's cost is X, > > and the type 2 cost is Y.' > > What is the behavior in ISIS? > > Regards, > Savyasachi > 7676077879 > > > On Thu, Feb 10, 2011 at 6:01 AM, wrote: > > > Send NANOG mailing list submissions to > > nanog at nanog.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://mailman.nanog.org/mailman/listinfo/nanog > > or, via email, send a message with subject or body 'help' to > > nanog-request at nanog.org > > > > You can reach the person managing the list at > > nanog-owner at nanog.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of NANOG digest..." > > > > > > Today's Topics: > > > > 1. Re: Looking for an IPv6 naysayer... (Jack Bates) > > 2. Re: Looking for an IPv6 naysayer... (Mark Andrews) > > 3. Re: Looking for an IPv6 naysayer... (Jack Bates) > > 4. Re: Looking for an IPv6 naysayer... (Mark Andrews) > > 5. Re: Looking for an IPv6 naysayer... (Joel Jaeggli) > > 6. Re: Looking for an IPv6 naysayer... (Owen DeLong) > > 7. Re: Looking for an IPv6 naysayer... (Mark Andrews) > > 8. Re: Looking for an IPv6 naysayer... (Matthew Kaufman) > > 9. Re: IPv6 - a noobs prespective (Joel Jaeggli) > > 10. Re: Looking for an IPv6 naysayer... (Jack Bates) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Wed, 09 Feb 2011 18:00:19 -0600 > > From: Jack Bates > > Subject: Re: Looking for an IPv6 naysayer... > > To: George Bonser > > Cc: nanog at nanog.org > > Message-ID: <4D532A93.50504 at brightok.net> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > On 2/9/2011 5:47 PM, George Bonser wrote: > > > I have yet to see a broadband provider that configures a network so > that > > > individual nodes in the home network get global IPs. > > Bridge only CPE's given off this node. > > > > 1043 IP addresses handed out > > 1024 Unique interfaces > > > > Looks like customers aren't always big on more than 1 IP. :) > > > > > > Jack > > > > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Thu, 10 Feb 2011 11:00:45 +1100 > > From: Mark Andrews > > Subject: Re: Looking for an IPv6 naysayer... > > To: david raistrick > > Cc: nanog at nanog.org > > Message-ID: <20110210000045.EA41D9DCA79 at drugs.dv.isc.org> > > > > > > In message , > > david rai > > strick writes: > > > On Wed, 9 Feb 2011, Jens Link wrote: > > > > > > > Scott Helms writes: > > > > > > > >> IPv6 for some ISPs will be extraordinarily painful because of legacy > > > >> layer 2 gear > > > > > > > > I don't feel sorry for them. We know that IPv6 is coming for how > long? > > > > 15years? 10year? 5years? Well if you only read the mainstream media > you > > > > > > And at what point during that time did they have any vendor gear they > > > could purchase that -would- support v6? At -best- during the last 5 > > > years, but I'd put money on that even today they can't purchase gear > with > > > adequate v6 support. > > > > And who's fault is that? The ISP's and the vendors. The ISP's > > could have been requesting IPv6 support. The ISP's could have been > > running trials and providing feedback to the vendors. The vendors > > could have asked the ISP's to trail their IPv6 products. > > > > We have been saying for years "make sure you are ready". That means > > buying and testing equipment. Lots of those that tested went on to > > production years ago. > > > > As a vendor we like feedback on our products, good or bad. It's > > hard to work in a vacuum. > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > > > > > ------------------------------ > > > > Message: 3 > > Date: Wed, 09 Feb 2011 18:01:46 -0600 > > From: Jack Bates > > Subject: Re: Looking for an IPv6 naysayer... > > To: "Robert E. Seastrom" > > Cc: nanog at nanog.org > > Message-ID: <4D532AEA.2090505 at brightok.net> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > On 2/9/2011 5:56 PM, Robert E. Seastrom wrote: > > > Or 6rd and go native on their permanent prefix as the forklift upgrade > > > schedule allows. Oh well, it's better than nothing or Crummier Grade > > NAT. > > > > ds-lite tends to be friendlier LSN from various tests, and is native v6. > > > > > > Jack > > > > > > > > ------------------------------ > > > > Message: 4 > > Date: Thu, 10 Feb 2011 11:07:26 +1100 > > From: Mark Andrews > > Subject: Re: Looking for an IPv6 naysayer... > > To: "George Bonser" > > Cc: nanog at nanog.org > > Message-ID: <20110210000726.3CABE9DCC09 at drugs.dv.isc.org> > > > > > > In message < > > 5A6D953473350C4B9995546AFE9939EE0BC1397D at RWC-EX1.corp.seven.com>, " > > George Bonser" writes: > > > > Cost's might be lower but service will be worse. NAT breaks a lot of > > > > applications file sharing will not work properly and running your own > > > > web server at home will not work properly. Well you always get what > > > you > > > > pay for and people will buy any crap if it is cheap enough. > > > >=20 > > > > Jens > > > > > > While that is true, it is no worse than the situation right now. In > the > > > US, the vast majority of users are already behind a NAT (I would say > > > over 90% of them are) so they are already experiencing this breakage. > =20 > > > > But for the most part they can work around breakages with a single NAT. > > Double NAT prevents most of the work arounds working. > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > > > > > ------------------------------ > > > > Message: 5 > > Date: Wed, 09 Feb 2011 16:08:10 -0800 > > From: Joel Jaeggli > > Subject: Re: Looking for an IPv6 naysayer... > > To: George Bonser > > Cc: nanog at nanog.org > > Message-ID: <4D532C6A.20209 at bogus.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > On 2/9/11 3:43 PM, George Bonser wrote: > > >> Almost none of the broadband providers in the US NAT their customers. > > > > > > Well, I suppose I have been unlucky then because every single one I > have > > > had has NATed me. I had a "real" IP when I had dialup, but I got NAT > > > when I went broadband. I have a friend that has another service and > she > > > is NATed too. Boot up in her network and you get 192.168.1.x > > > > The the cpe... In all likelihood it has a public ip on the outside. > > > > > > > > > > > > > > > > > > > > > ------------------------------ > > > > Message: 6 > > Date: Wed, 9 Feb 2011 16:10:46 -0800 > > From: Owen DeLong > > Subject: Re: Looking for an IPv6 naysayer... > > To: david raistrick > > Cc: nanog at nanog.org > > Message-ID: <582356A9-5ADC-4244-8BA0-EE1F2F3EF388 at delong.com> > > Content-Type: text/plain; charset=us-ascii > > > > > > On Feb 9, 2011, at 3:16 PM, david raistrick wrote: > > > > > On Wed, 9 Feb 2011, Owen DeLong wrote: > > > > > >>>> I don't feel sorry for them. We know that IPv6 is coming for how > long? > > >>>> 15years? 10year? 5years? Well if you only read the mainstream media > > you > > >>> > > >>> And at what point during that time did they have any vendor gear they > > could purchase that -would- support v6? At -best- during the last 5 > years, > > but I'd put money on that even today they can't purchase gear with > adequate > > v6 support. > > >>> > > >> This is largely the result of the fact that they did not demand it > from > > their > > >> vendors during that time. > > > > > > > > > I was purchasing for and building small SP networks during that time. > > > > > > Requiring v6 of our vendors would have meant we just never got > anything, > > so we'd have never provided service. Come to think if it, maybe it > -would- > > have been better for everyone involved (except those of us who just got > > paychecks and experience out of it) to just simply not do it - but we > didn't > > know that at the time 15 years ago! > > > > > Requiring it delivered day one, sure. Putting in a requirement for "Will > > support" so that they are required to provide an upgrade path, OTOH, to > me > > seemed like it was basic good business sense. It worked out pretty well > for > > the organizations I was working for back then. We got upgradeable > hardware > > and the vendors got awareness of the demand. Admittedly, I wasn't working > in > > the last mile arena. However, pressuring vendors is possible without > > sacrificing immediate needs. > > > > > > > > Vendor C and J don't provide gear that fits into all network topologies > > (WISPs, MTU DSL, and smallish ADSL roll outs come to mind, certain during > > the time period in question. Sure, they eventually bought products in > those > > markets...but even still, I had sub 6 figure budgets to build with - I > > certainly had no leverage). > > > > > I don't think that networks with sub-6-figure buildouts are the ones > we're > > too worried about right now. > > They can probably upgrade for sub-6-figure amounts. > > > > Owen > > > > > > > > > > ------------------------------ > > > > Message: 7 > > Date: Thu, 10 Feb 2011 11:22:31 +1100 > > From: Mark Andrews > > Subject: Re: Looking for an IPv6 naysayer... > > To: Scott Helms > > Cc: nanog at nanog.org > > Message-ID: <20110210002231.23F0E9DCFDD at drugs.dv.isc.org> > > > > > > In message <4D531B52.70404 at ispalliance.net>, Scott Helms writes: > > > On 2/9/2011 5:48 PM, Owen DeLong wrote: > > > > On Feb 9, 2011, at 12:00 PM, david raistrick wrote: > > > > > > > >> On Wed, 9 Feb 2011, Jens Link wrote: > > > >> > > > >>> Scott Helms writes: > > > >>> > > > >>>> IPv6 for some ISPs will be extraordinarily painful because of > legacy > > > >>>> layer 2 gear > > > >>> I don't feel sorry for them. We know that IPv6 is coming for how > > long? > > > >>> 15years? 10year? 5years? Well if you only read the mainstream media > > you > > > >> And at what point during that time did they have any vendor gear > they > > coul > > > d purchase that -would- support v6? At -best- during the last 5 > years, > > but > > > I'd put money on that even today they can't purchase gear with adequate > > v6 su > > > pport. > > > >> > > > > This is largely the result of the fact that they did not demand it > from > > the > > > ir > > > > vendors during that time. > > > > > > > > Owen > > > > > > > > > > > > > > > Absolutely, just as the ISPs didn't see demand, and don't today, from > > > their users and thus the circle of blame is complete :) > > > > And some of their customers have been asking for IPv6 all along. > > > > I started asking my ISP at home in 2003. I suspect if all the ISPs > > here were honest they would say that they have had a trickle of > > IPv6 requests for the last 8 years. > > > > Mark > > > > Date: Mon, 16 Jun 2003 09:54:05 +1000 > > To: Mark_Andrews at isc.org > > From: cablesupport at optusnet.com.au > > Subject: Re: [TT#6556559] HELPDESK Feedback Form - Mon Jun 16 09:52:50 > 2003 > > > > Return-Path: nobody at pts.optusnet.com.au > > Delivery-Date: Mon Jun 16 10:00:00 2003 > > Return-Path: > > X-Original-To: marka at farside.isc.org > > Delivered-To: marka at farside.isc.org > > X-Loop: pts > > Reply-To: cablesupport at optusnet.com.au > > > > Hello, > > > > Thank you for your email regarding the OptusNet Cable service. > > > > At the moment there are no plans for any IPv6 deployment, when this is > due > > to happen we will notify all customers. > > > > Regards, > > Alex > > OptusNet Cable Technical Support > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > > > > > ------------------------------ > > > > Message: 8 > > Date: Wed, 09 Feb 2011 16:27:51 -0800 > > From: Matthew Kaufman > > Subject: Re: Looking for an IPv6 naysayer... > > To: Jack Bates > > Cc: nanog at nanog.org > > Message-ID: <4D533107.5010202 at matthew.at> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > On 2/9/2011 4:00 PM, Jack Bates wrote: > > > On 2/9/2011 5:47 PM, George Bonser wrote: > > >> I have yet to see a broadband provider that configures a network so > that > > >> individual nodes in the home network get global IPs. > > > Bridge only CPE's given off this node. > > > > > > 1043 IP addresses handed out > > > 1024 Unique interfaces > > > > > > Looks like customers aren't always big on more than 1 IP. :) > > > > > > > > > Jack > > > > > > > > And meanwhile Comcast has announced one /64-per-household service for > > IPv6... guess they didn't get the memo from Owen about how every class > > of home appliances will need its own subnet. > > > > Matthew Kaufman > > > > > > > > ------------------------------ > > > > Message: 9 > > Date: Wed, 09 Feb 2011 16:29:54 -0800 > > From: Joel Jaeggli > > Subject: Re: IPv6 - a noobs prespective > > To: Owen DeLong > > Cc: nanog at nanog.org > > Message-ID: <4D533182.6020505 at bogus.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > On 2/9/11 2:22 PM, Owen DeLong wrote: > > > There have been IPv6 for dummies sessions at many past NANOGs. > > > > > > If NANOG is willing to provide time and space for them at future > events, > > I will > > > be happy to conduct the tutorial sessions. > > > > program committee would no doubt love to hear from you. > > > > > > > Owen > > > > > > On Feb 9, 2011, at 10:30 AM, Mike Lyon wrote: > > > > > >> With the recent allocation of the last existing IPv4 /8s (which now > kind > > of > > >> puts pressure on going v6), it would be wonderful if at the next > couple > > of > > >> NANOGs if there could be an IPv6 for dummies session or two :) > > >> > > >> -Mike > > >> > > >> > > >> On Wed, Feb 9, 2011 at 10:22 AM, Jack Bates > > wrote: > > >> > > >>> On 2/9/2011 12:03 PM, William Herrin wrote: > > >>> > > >>>> The thing that terrifies me about deploying IPv6 is that apps > > >>>> compatible with both are programmed to attempt IPv6 before IPv4. > This > > >>>> means my first not-quite-correct IPv6 deployments are going to break > > >>>> my apps that are used to not having and therefore not trying IPv6. > But > > >>>> that's not the worst part... as the folks my customers interact with > > >>>> over the next couple of years make their first not-quite-correct > IPv6 > > >>>> deployments, my access to them is going to break again. And again. > And > > >>>> again. And I won't have the foggiest idea who's next until I get the > > >>>> call that such-and-such isn't working right. > > >>>> > > >>> > > >>> What scares me most is that every time I upgrade a router to support > > needed > > >>> hardware or some badly needed IPv6 feature, something else breaks. > > Sometimes > > >>> it's just the router crashes on a specific IPv6 command entered at > CLI > > (C) > > >>> or as nasty as NSR constantly crashing the slave (J); the fixes > > generally > > >>> requiring me to upgrade again to the latest cutting edge releases > which > > >>> everyone hates (where I'm sure I'll find MORE bugs). > > >>> > > >>> The worst is when you're the first to find the bug(which I'm not even > > sure > > >>> how it's possible given how simplistic my configs are, isis > > multitopology, > > >>> iBGP, NSR, a few acls and route-maps/policies), it takes 3-6 months > or > > so to > > >>> track it down, and then it's put only in the next upcoming release > (not > > out > > >>> yet) and backported to the last release. > > >>> > > >>> > > >>> Jack (hates all routers equally, doesn't matter who makes it) > > >>> > > >>> > > > > > > > > > > > > > > > > > > > ------------------------------ > > > > Message: 10 > > Date: Wed, 09 Feb 2011 18:30:46 -0600 > > From: Jack Bates > > Subject: Re: Looking for an IPv6 naysayer... > > To: matthew at matthew.at > > Cc: nanog at nanog.org > > Message-ID: <4D5331B6.60902 at brightok.net> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > On 2/9/2011 6:27 PM, Matthew Kaufman wrote: > > > > > > And meanwhile Comcast has announced one /64-per-household service for > > > IPv6... guess they didn't get the memo from Owen about how every class > > > of home appliances will need its own subnet. > > > > I wonder if their RIR justification was for /64 to household or /48. :) > > > > Jack > > > > > > > > ------------------------------ > > > > _______________________________________________ > > NANOG mailing list > > NANOG at nanog.org > > https://mailman.nanog.org/mailman/listinfo/nanog > > > > End of NANOG Digest, Vol 37, Issue 121 > > ************************************** > > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 39, Issue 68 > ************************************* > From santino.codispoti at gmail.com Thu Apr 21 02:35:30 2011 From: santino.codispoti at gmail.com (Santino Codispoti) Date: Thu, 21 Apr 2011 03:35:30 -0400 Subject: Voice Peering? Message-ID: I know a few years ago some Vo/IP peering points where started. Are they still around today? I am looking for a solution to hand-off outbound voice calls to mobile operators From santino.codispoti at gmail.com Thu Apr 21 03:52:05 2011 From: santino.codispoti at gmail.com (Santino Codispoti) Date: Thu, 21 Apr 2011 04:52:05 -0400 Subject: Voice Peering? In-Reply-To: <5CC7D3ED-41F7-4305-9688-45D1BDFAB270@A2B-Internet.com> References: <5CC7D3ED-41F7-4305-9688-45D1BDFAB270@A2B-Internet.com> Message-ID: Thank you I will look into AMS-IX. I was thinking the GRX platforms where for SMS and Data only. On Thu, Apr 21, 2011 at 4:45 AM, Erik Bais wrote: > Hi Santino, > > ?Did you had a look at AMS-IX ? They have a grx offering for that. > > Regards, > Erik Bais > A2B Internet > > Verstuurd vanaf mijn iPad > > Op Apr 21, 2011 om 9:35 heeft Santino Codispoti het volgende geschreven: > >> I know a few years ago some Vo/IP peering points where started. ?Are >> they still around today? ? I am looking for a solution to hand-off >> outbound voice calls to mobile operators >> > From remco at signet.nl Thu Apr 21 03:58:04 2011 From: remco at signet.nl (Remco Bressers) Date: Thu, 21 Apr 2011 10:58:04 +0200 Subject: Voice Peering? In-Reply-To: References: <5CC7D3ED-41F7-4305-9688-45D1BDFAB270@A2B-Internet.com> Message-ID: <4DAFF19C.4090701@signet.nl> I also thought GRX peering was only data and sms. There's a SIP peering point on the NL-IX though. Look at http://www.nl-ix.net/solutions/voice-peering/ for more. Regards, Remco Bressers Signet B.V. AS28878 On 04/21/2011 10:52 AM, Santino Codispoti wrote: > Thank you I will look into AMS-IX. I was thinking the GRX platforms > where for SMS and Data only. > > On Thu, Apr 21, 2011 at 4:45 AM, Erik Bais wrote: >> Hi Santino, >> >> Did you had a look at AMS-IX ? They have a grx offering for that. >> >> Regards, >> Erik Bais >> A2B Internet >> >> Verstuurd vanaf mijn iPad >> >> Op Apr 21, 2011 om 9:35 heeft Santino Codispoti het volgende geschreven: >> >>> I know a few years ago some Vo/IP peering points where started. Are >>> they still around today? I am looking for a solution to hand-off >>> outbound voice calls to mobile operators >>> >> > From savyasachi.choudhary at gmail.com Thu Apr 21 04:16:15 2011 From: savyasachi.choudhary at gmail.com (Savyasachi Choudhary) Date: Thu, 21 Apr 2011 14:46:15 +0530 Subject: Doubt in ISIS In-Reply-To: References: Message-ID: > Thank you for the response. Its very detailed, and I am yet to understand > it completely. > > Following is the problem I am facing on Ericsson Routers. > > (static route) > Router1---------------------------------------------------------------------Router2 > ip route 202.1.1.0/24 null0 cost 9 > > In this 2 router topology, I have imported a static route 202.1.1.0/24 > with cost 9. > > And I am giving the following redistribute command on Router1, and later > observe show ip route command on Router2 > > PROTOCOL COMMAND (in Router1) > COST (Router2) OBSERVATION > > ISIS #redistribute static > 10 > default > #redistribute static metric 7 mertic-type external > 17 > configured in redist + 10 > #redistribute static metric 7 mertic-type internal > 17 > configured in redist + 10 > > What is observed is, it completely ignores the cost (9) that is configured > with the static route. In case of OSPF, they consider cost 9 also. > So, I have a doubt, whether ISIS RFC describes to ignore the route cost? Or > it is just implementation dependent. > > > Regards, > Savyasachi > 7676077879 > > > > On Thu, Apr 21, 2011 at 2:14 PM, Vitkovsky, Adam wrote: > >> Isis doesn't have type-1 and type-2 external routes >> It has something similar though >> Metric of a prefix can be marked as internal metric or external metric >> >> These are my isis notes section regarding internal and external: >> >> the metric type for ext(redistributed) routes can be set as int/ext >> -by default internal metric is asigned during redistribution >> if nothing is specified >> >> ext metric has the I/E bit set -bit 7 >> => higher metric value +64 >> -------------------------------------- >> but cisto doesn't set bit 7 but bit 8 >> -when narrow metric is used bit 8 of the metric field is set by cisco >> => external metric than appears to be increased by 128 >> -------------------------------------- >> _____________________________________________________________________ >> Narrow metric: >> 8th bit is S-bit -support for qos metrics (only 0 is supported) >> 7th bit is the internal/external bit >> And the remaining 8 bits are for the metric >> >> 1b 1b 6bits => max 63 values >> 0 i/e default metric value >> 1 i/e delay metric value >> 1 i/e expense metric value >> 1 i/e error metric value >> -------neighbor ID-------- >> >> Internal is default on cisco >> If you set external the bit 7 is set -thus the metric appears to be +64 >> higher compared to the same route redistributed as internal >> >> >> ______________________________________________ >> TLV specified by ISO 10589 contain metric info: >> ES neighbor type 2 >> IS neigh tyep 3 >> prefix neigh type 5 >> >> ______________________________________________ >> TLV specified by RFC 1195 contain metric info: >> ip internal reachability type 128 >> ip external reachability type 130 >> >> >> >> __________________________________________________________ >> ISIS metric extensions >> >> extended IS reachability tlv type 22 >> extended ip reachability tlv type 135 >> and >> trafic engineering rotuer ID tlv type 134 >> >> >> -the borrowed the metric fields for delay, expense, error >> -as they are not used >> >> -but the first S-bit and the I/E-bit remained >> So the same apply to the extended metric as well >> >> >> >> These are my notes form the labs: >> _____________________________________________________________ >> R1 >> route-map static-routes permit 10 >> match ip address prefix-list static-routes >> ! >> router isis 1 >> redistribute static ip route-map static-routes metric-type external >> level-1 >> >> -everything explicitely set in the redistribute cmd >> _____________________________________________________________ >> R2 >> route-map static-routes permit 10 >> match interface Null0 >> set metric-type external >> set level level-1 >> ! >> router isis 1 >> redistribute static ip route-map static-routes >> >> -everything set in the route-map used during the redistribution >> _____________________________________________________________ >> >> R7#sh isis dat ver >> >> IS-IS Level-1 Link State Database: >> LSPID LSP Seq Num LSP Checksum LSP Holdtime >> ATT/P/OL >> R1.00-00 0x00000007 0x23CA 642 1/0/0 >> Area Address: 49.0001 >> NLPID: 0xCC >> Hostname: R1 >> IP Address: 1.1.1.1 >> Metric: 10 IP 13.0.0.0 255.255.255.0 >> Metric: 10 IP 17.0.0.0 255.255.255.0 >> Metric: 0 IP 1.1.1.1 255.255.255.255 >> Metric: 10 IS R7.00 >> Metric: 0 IP-External 200.10.0.0 255.255.255.0 >> Metric: 0 IP-External 200.20.0.0 255.255.255.0 >> Metric: 0 IP-External 200.30.0.0 255.255.255.0 >> R2.00-00 0x00000015 0x5DA2 1049 1/0/0 >> Area Address: 49.0001 >> NLPID: 0xCC >> Hostname: R2 >> IP Address: 2.2.2.2 >> Metric: 10 IP 24.0.0.0 255.255.255.0 >> Metric: 10 IP 27.0.0.0 255.255.255.0 >> Metric: 0 IP 2.2.2.2 255.255.255.255 >> Metric: 10 IS R7.00 >> Metric: 64 IP-External 200.10.0.0 255.255.255.0 >> Metric: 64 IP-External 200.20.0.0 255.255.255.0 >> Metric: 64 IP-External 200.30.0.0 255.255.255.0 >> >> >> -so definition of external metric in redistribution cmd >> did not touch the metric -not sure how come it's still marked as ext >> -as the bit 7 or 8 should have been set >> >> -and definition of external metric in route-map >> did set the bit 7 of the metric -thus we see increase in metric of 64 >> >> -but none of the cmds have set the bit 8 as stated in the book :) >> >> >> >> >> adam >> >> -----Original Message----- >> From: Savyasachi Choudhary [mailto:savyasachi.choudhary at gmail.com] >> Sent: Thursday, April 21, 2011 8:56 AM >> To: nanog at nanog.org >> Subject: Doubt in ISIS >> >> I have a doubt in ISIS. >> While redistributing routes from other protocols, how the metric is >> decided? >> OSPF has deccribed this in RFC 2328 Section 16.4 : >> >> '4) Let X be the cost specified by the preferred routing >> table >> >> entry for the ASBR/forwarding address, and Y the cost >> specified in the LSA. X is in terms of the link state >> metric, and Y is a type 1 or 2 external metric. >> >> (5) Look up the routing table entry for the destination N. If >> no entry exists for N, install the AS external path to N, >> with next hop equal to the list of next hops to the >> forwarding address, and advertising router equal to ASBR. >> If the external metric type is 1, then the path-type is set >> to type 1 external and the cost is equal to X+Y. If the >> external metric type is 2, the path-type is set to type 2 >> external, the link state component of the route's cost is X, >> >> and the type 2 cost is Y.' >> >> What is the behavior in ISIS? >> Regards, >> Savyasachi >> 7676077879 >> >> From David.Curran at windstream.com Thu Apr 21 07:52:29 2011 From: David.Curran at windstream.com (Curran, David) Date: Thu, 21 Apr 2011 07:52:29 -0500 Subject: Bandwidth Growth Message-ID: > Date: Thu, 21 Apr 2011 10:36:54 +0800 > From: Adrian Chadd > Subject: Re: Bandwidth growth > To: "Patrick W. Gilmore" > Cc: NANOG list > Message-ID: <20110421023654.GE13776 at skywalker.creative.net.au> > Content-Type: text/plain; charset=us-ascii > > If it's a true research project, wouldn't you really be interested in both > evidence for/against? :-) > > Just my 2c here, > > > Adrian Touche. Fortunately not being in the academic world allows me to be completely biased! :) But your point is well taken, and I'll take evidence for either side. I appreciate all of the responses I've received thus far. Especially the links to the IX graphs. While I agree you can't account for peering/de-peering, it also strikes me that on the aggregate the graphs do indeed show a significant increase around the "holidays" (the US ones anyway). The LINX, TORIX, and SIX graphs provided earlier, for example, seem relatively flat until the Nov. timeframe at which point they seem to seek a new higher "normal". Could just be my lack of sleep and my biased opinion though. As one might infer, I'm trying to find evidence corroborating my own experiences. My theory being that all of those cool Internet connected toys (Blue Ray, TVs, Ipads, etc) that hit the market this past year have lead to a substantial increase in residential Internet traffic. If that were true, I guess I'd expect that enterprise oriented service providers would not see the same uptick as residential providers. Thanks again to all have responded (and anyone else that might still). David *************************************************************************************** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. From jloiacon at csc.com Thu Apr 21 08:49:01 2011 From: jloiacon at csc.com (Joe Loiacono) Date: Thu, 21 Apr 2011 09:49:01 -0400 Subject: Bandwidth Growth In-Reply-To: References: Message-ID: "Curran, David" wrote on 04/21/2011 08:52:29 AM: > ... it also strikes me that on the aggregate > the graphs do indeed show a significant increase around the "holidays" > (the US ones anyway). Another bias? :-) Seems Internet participants took some time off for Christmas: https://stats.linx.net/aggregate.html http://www.seattleix.net/agg.htm Joe From skhosla at neutraldata.com Thu Apr 21 09:09:31 2011 From: skhosla at neutraldata.com (Sameer Khosla) Date: Thu, 21 Apr 2011 10:09:31 -0400 Subject: Bandwidth Growth In-Reply-To: References: Message-ID: <3CDAFF22BE6DAF43B7EA263F6707D28935C72A@mail.neutraldata.com> -----Original Message----- From: Curran, David [mailto:David.Curran at windstream.com] > The LINX, TORIX, and SIX graphs provided earlier, for example, seem > relatively flat until the Nov. timeframe at which point they seem to seek > a new higher "normal". Could just be my lack of sleep and my biased > opinion though. As one might infer, I'm trying to find evidence > corroborating my own experiences. My theory being that all of those cool > Internet connected toys (Blue Ray, TVs, Ipads, etc) that hit the market > this past year have lead to a substantial increase in residential Internet > traffic. If that were true, I guess I'd expect that enterprise oriented > service providers would not see the same uptick as residential providers. > > Thanks again to all have responded (and anyone else that might still). > > David David, you may also want to try to correlate the addition of participants to the peering fabric to bandwidth growth. I know TorIX shows on their main page the date when new participants joined the exchange. http://www.torix.net/ For example, Microsoft jointed on 9/3/10. You may be able to see a rise in usage shortly after. Thanks Sameer From cb.list6 at gmail.com Thu Apr 21 09:23:34 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 21 Apr 2011 07:23:34 -0700 Subject: Voice Peering? In-Reply-To: <4DAFF19C.4090701@signet.nl> References: <5CC7D3ED-41F7-4305-9688-45D1BDFAB270@A2B-Internet.com> <4DAFF19C.4090701@signet.nl> Message-ID: On Apr 21, 2011 1:59 AM, "Remco Bressers" wrote: > > I also thought GRX peering was only data and sms. > There's a SIP peering point on the NL-IX though. Grx is data only. IPX in theory does voice too but I don't think the take rate is very high. Cb > Look at http://www.nl-ix.net/solutions/voice-peering/ for more. > > Regards, > > Remco Bressers > Signet B.V. > AS28878 > > > On 04/21/2011 10:52 AM, Santino Codispoti wrote: > > Thank you I will look into AMS-IX. I was thinking the GRX platforms > > where for SMS and Data only. > > > > On Thu, Apr 21, 2011 at 4:45 AM, Erik Bais wrote: > >> Hi Santino, > >> > >> Did you had a look at AMS-IX ? They have a grx offering for that. > >> > >> Regards, > >> Erik Bais > >> A2B Internet > >> > >> Verstuurd vanaf mijn iPad > >> > >> Op Apr 21, 2011 om 9:35 heeft Santino Codispoti < santino.codispoti at gmail.com> het volgende geschreven: > >> > >>> I know a few years ago some Vo/IP peering points where started. Are > >>> they still around today? I am looking for a solution to hand-off > >>> outbound voice calls to mobile operators > >>> > >> > > > > From bw-ml at mube.co.uk Thu Apr 21 11:55:32 2011 From: bw-ml at mube.co.uk (Ben Whorwood) Date: Thu, 21 Apr 2011 17:55:32 +0100 Subject: VPN over slow Internet connections Message-ID: <4DB06184.30508@mube.co.uk> Dear all, Can anyone share any thoughts or experiences for VPN links running over slow Internet connections, typically 2kB/s - 3kB/s (think 33.6k modem)? We are looking into utilising OpenVPN for out-of-office workers who would be running mobile broadband in rural areas. Typical data across the wire would be SQL queries for custom applications and not much else. Some initial thoughts include... * How well would the connection handle certificate (>= 2048 bit key) based authentication? * Is UDP or TCP better considering the speed and possibility of packet loss (no figures to hand)? * Is VPN over this type of connection simply a bad idea? Many thanks in advance. Kind regards, Ben Whorwood From scott at sberkman.net Thu Apr 21 12:00:58 2011 From: scott at sberkman.net (Scott Berkman) Date: Thu, 21 Apr 2011 13:00:58 -0400 Subject: Voice Peering? In-Reply-To: References: Message-ID: <00cc01cc0045$afc0e6e0$0f42b4a0$@sberkman.net> It's not specific for mobile, but this is one of the most well know VOIP exchanges: http://www.thevpf.com/ -Scott -----Original Message----- From: Santino Codispoti [mailto:santino.codispoti at gmail.com] Sent: Thursday, April 21, 2011 3:36 AM To: nanog at nanog.org Subject: Voice Peering? I know a few years ago some Vo/IP peering points where started. Are they still around today? I am looking for a solution to hand-off outbound voice calls to mobile operators From brandon.kim at brandontek.com Thu Apr 21 12:06:36 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Thu, 21 Apr 2011 13:06:36 -0400 Subject: VPN over slow Internet connections In-Reply-To: <4DB06184.30508@mube.co.uk> References: <4DB06184.30508@mube.co.uk> Message-ID: If I had to guestimate, the performance would be horrible considering the VPN overhead in itself. You can't choose UDP or TCP, that is all based on the applications being used within the tunnel. So the apps will decide what protocols they will need to use, which will then be encapsulated by IPSEC. It could work, but you may not be happy and it may not provide the desired performance that you need to be productive.... > Date: Thu, 21 Apr 2011 17:55:32 +0100 > From: bw-ml at mube.co.uk > To: nanog at nanog.org > Subject: VPN over slow Internet connections > > Dear all, > > Can anyone share any thoughts or experiences for VPN links running over > slow Internet connections, typically 2kB/s - 3kB/s (think 33.6k modem)? > > We are looking into utilising OpenVPN for out-of-office workers who > would be running mobile broadband in rural areas. Typical data across > the wire would be SQL queries for custom applications and not much else. > > Some initial thoughts include... > > * How well would the connection handle certificate (>= 2048 bit key) > based authentication? > * Is UDP or TCP better considering the speed and possibility of > packet loss (no figures to hand)? > * Is VPN over this type of connection simply a bad idea? > > Many thanks in advance. > > Kind regards, > Ben Whorwood > From regnauld at nsrc.org Thu Apr 21 12:07:58 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 21 Apr 2011 19:07:58 +0200 Subject: VPN over slow Internet connections In-Reply-To: <4DB06184.30508@mube.co.uk> References: <4DB06184.30508@mube.co.uk> Message-ID: <20110421170754.GL27269@macbook.catpipe.net> Ben Whorwood (bw-ml) writes: > Some initial thoughts include... > > * How well would the connection handle certificate (>= 2048 bit > key) based authentication? > * Is UDP or TCP better considering the speed and possibility of > packet loss (no figures to hand)? I'd go for a UDP tunnel, as you wouldn't have to renegotiate a TCP session for the tunnel *and* whatever connection you've got going through that. > * Is VPN over this type of connection simply a bad idea? I don't think it's a particularly bad idea. But why don't you make you own tests using FreeBSD/dummynet, simulating 1-2% packet loss, limit bandwidth to 33 Kbit/s, and corresponding latency (say 100ms). I'd say your biggest concern won't be the VPN (you can make it completely stateless with static keys), but whatever protocol you've got running on top of that, and how it deals with the loss. Cheers, Phil From darden at armc.org Thu Apr 21 12:10:09 2011 From: darden at armc.org (Darden, Patrick S.) Date: Thu, 21 Apr 2011 13:10:09 -0400 Subject: VPN over slow Internet connections In-Reply-To: <4DB06184.30508@mube.co.uk> Message-ID: There's not that much overhead--your certs should be ok. TCP for SQL would just make sense. I personally wouldn't want to do what you are contemplating. Here's some stuff to think about: 1. your modems will not be able to do compression. You can't easily compress random data (e.g. encrypted). 2. you won't get 33.6 unless your phone lines are pristine. You better plan on 28.8--if you are lucky. 3. I would hone my SQL sharply so it produces the smallest most relevant data sets possible. 4. you might want to give them some kind of termnial/shell access for doing their SQL remotely, instead of from home. Telnet or SSH. If you used SSH you could obviate using a separate VPN, you could use -C for compression, and you could do your SQL on the server side (or the on-site side)--all in all a speedier alternative. --Patrick Darden -----Original Message----- From: Ben Whorwood [mailto:bw-ml at mube.co.uk] Sent: Thursday, April 21, 2011 12:56 PM To: nanog at nanog.org Subject: VPN over slow Internet connections Dear all, Can anyone share any thoughts or experiences for VPN links running over slow Internet connections, typically 2kB/s - 3kB/s (think 33.6k modem)? We are looking into utilising OpenVPN for out-of-office workers who would be running mobile broadband in rural areas. Typical data across the wire would be SQL queries for custom applications and not much else. Some initial thoughts include... * How well would the connection handle certificate (>= 2048 bit key) based authentication? * Is UDP or TCP better considering the speed and possibility of packet loss (no figures to hand)? * Is VPN over this type of connection simply a bad idea? Many thanks in advance. Kind regards, Ben Whorwood From Valdis.Kletnieks at vt.edu Thu Apr 21 12:17:05 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 21 Apr 2011 13:17:05 -0400 Subject: VPN over slow Internet connections In-Reply-To: Your message of "Thu, 21 Apr 2011 17:55:32 BST." <4DB06184.30508@mube.co.uk> References: <4DB06184.30508@mube.co.uk> Message-ID: <11830.1303406225@localhost> On Thu, 21 Apr 2011 17:55:32 BST, Ben Whorwood said: > * How well would the connection handle certificate (>= 2048 bit key) > based authentication? It will hiccup for a moment (maybe a quarter or half second) for the data. The certificate exchange is the least of your problems. > * Is VPN over this type of connection simply a bad idea? Well, 33.6k is a Bad Idea right there. :) But if you're stuck with that for technical reasons, but need a VPN for security reasons, it won't be all *that* much worse, unless you're doing a lot of SSH or similar short-packet single-keystroke traffic, where the VPN overhead will start being a bit painful. Shouldn't be too hard to model the traffic involved to see if it's too painful - FreeBSD has dummynet IIRC. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From fredr at geexology.org Thu Apr 21 12:22:42 2011 From: fredr at geexology.org (Fred Richards) Date: Thu, 21 Apr 2011 13:22:42 -0400 Subject: VPN over slow Internet connections In-Reply-To: References: <4DB06184.30508@mube.co.uk> Message-ID: > We are looking into utilising OpenVPN for out-of-office workers who > would be running mobile broadband in rural areas. Typical data across > the wire would be SQL queries for custom applications and not much else. > I agree with Patrick, SSH would do nicely. You could even setup a tunnel, and the sql queries could hit localhost:3306 (for mysql for example) and connect, encrypted to a remote server. At 2-3KB/sec, I wouldn't expect the ability to have too many people concurrently connecting to the database. -- ? ? ? ? ? ? ? ? ? ? ? Fred From bill at herrin.us Thu Apr 21 12:24:10 2011 From: bill at herrin.us (William Herrin) Date: Thu, 21 Apr 2011 13:24:10 -0400 Subject: VPN over slow Internet connections In-Reply-To: <4DB06184.30508@mube.co.uk> References: <4DB06184.30508@mube.co.uk> Message-ID: On Thu, Apr 21, 2011 at 12:55 PM, Ben Whorwood wrote: > Can anyone share any thoughts or experiences for VPN links running over slow > Internet connections, typically 2kB/s - 3kB/s (think 33.6k modem)? > > We are looking into utilising OpenVPN for out-of-office workers who would be > running mobile broadband in rural areas. Typical data across the wire would > be SQL queries for custom applications and not much else. > > Some initial thoughts include... > > ?* How well would the connection handle certificate (>= 2048 bit key) based > authentication? Fine. The certificate isn't sent very often and is only 256 bytes when it is sent. > ?* Is UDP or TCP better considering the speed and possibility of packet loss > (no figures to hand)? TCP is more likely to pass firewalls at the user's end, especially if you put your VPN server on port 443. UDP will allow the user's various sessions to recover from packet loss independently (i.e. faster). I would pick UDP and provide an alternate TCP configuration for users who experience trouble. > ?* Is VPN over this type of connection simply a bad idea? No worse than using this slow a connection in the first place. VPN overhead is 5% to 10% tops. I would use a split tunnel though; let general internet destinations go directly through the Internet connection rather than through the VPN. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From brandon.kim at brandontek.com Thu Apr 21 12:32:01 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Thu, 21 Apr 2011 13:32:01 -0400 Subject: VPN over slow Internet connections In-Reply-To: References: <4DB06184.30508@mube.co.uk>, Message-ID: I vote for Patrick's idea of allowing the end user to remote into a machine where the SQL resides. This would eliminate a lot of potential issues....wish I had thought of that first!!! > Subject: RE: VPN over slow Internet connections > Date: Thu, 21 Apr 2011 13:10:09 -0400 > From: darden at armc.org > To: bw-ml at mube.co.uk; nanog at nanog.org > > > There's not that much overhead--your certs should be ok. TCP for SQL would just make sense. I personally wouldn't want to do what you are contemplating. Here's some stuff to think about: > > 1. your modems will not be able to do compression. You can't easily compress random data (e.g. encrypted). > 2. you won't get 33.6 unless your phone lines are pristine. You better plan on 28.8--if you are lucky. > 3. I would hone my SQL sharply so it produces the smallest most relevant data sets possible. > > 4. you might want to give them some kind of termnial/shell access for doing their SQL remotely, instead of from home. Telnet or SSH. If you used SSH you could obviate using a separate VPN, you could use -C for compression, and you could do your SQL on the server side (or the on-site side)--all in all a speedier alternative. > > --Patrick Darden > > > -----Original Message----- > From: Ben Whorwood [mailto:bw-ml at mube.co.uk] > Sent: Thursday, April 21, 2011 12:56 PM > To: nanog at nanog.org > Subject: VPN over slow Internet connections > > > Dear all, > > Can anyone share any thoughts or experiences for VPN links running over > slow Internet connections, typically 2kB/s - 3kB/s (think 33.6k modem)? > > We are looking into utilising OpenVPN for out-of-office workers who > would be running mobile broadband in rural areas. Typical data across > the wire would be SQL queries for custom applications and not much else. > > Some initial thoughts include... > > * How well would the connection handle certificate (>= 2048 bit key) > based authentication? > * Is UDP or TCP better considering the speed and possibility of > packet loss (no figures to hand)? > * Is VPN over this type of connection simply a bad idea? > > Many thanks in advance. > > Kind regards, > Ben Whorwood > > From gladney at stsci.edu Thu Apr 21 12:32:53 2011 From: gladney at stsci.edu (Gary Gladney) Date: Thu, 21 Apr 2011 17:32:53 +0000 Subject: VPN over slow Internet connections In-Reply-To: <4DB06184.30508@mube.co.uk> References: <4DB06184.30508@mube.co.uk> Message-ID: <1B0C5329DB4558419BE8B3440A66ADF306EE5A51@EXCHMAIL2.stsci.edu> If you haven't deployed your VPN environment yet I would seriously consider using SSL VPN instead of IPSec as your tunneling protocol. SSL VPN gives you a lot more options than IPSec. Gary -----Original Message----- From: Ben Whorwood [mailto:bw-ml at mube.co.uk] Sent: Thursday, April 21, 2011 12:56 PM To: nanog at nanog.org Subject: VPN over slow Internet connections Dear all, Can anyone share any thoughts or experiences for VPN links running over slow Internet connections, typically 2kB/s - 3kB/s (think 33.6k modem)? We are looking into utilising OpenVPN for out-of-office workers who would be running mobile broadband in rural areas. Typical data across the wire would be SQL queries for custom applications and not much else. Some initial thoughts include... * How well would the connection handle certificate (>= 2048 bit key) based authentication? * Is UDP or TCP better considering the speed and possibility of packet loss (no figures to hand)? * Is VPN over this type of connection simply a bad idea? Many thanks in advance. Kind regards, Ben Whorwood From bill at herrin.us Thu Apr 21 12:58:59 2011 From: bill at herrin.us (William Herrin) Date: Thu, 21 Apr 2011 13:58:59 -0400 Subject: VPN over slow Internet connections In-Reply-To: <1B0C5329DB4558419BE8B3440A66ADF306EE5A51@EXCHMAIL2.stsci.edu> References: <4DB06184.30508@mube.co.uk> <1B0C5329DB4558419BE8B3440A66ADF306EE5A51@EXCHMAIL2.stsci.edu> Message-ID: On Thu, Apr 21, 2011 at 1:32 PM, Gary Gladney wrote: > If you haven't deployed your VPN environment yet I would seriously >consider using SSL VPN instead of IPSec as your tunneling protocol. > ?SSL VPN gives you a lot more options than IPSec. Hi Gary, Ben was looking at OpenVPN, not IPSec.. He seems to have a field application he wants to talk directly to his SQL server. An SSL VPN that does such a good job protecting interior web services, sometimes also called a Web VPN or a clientless VPN, may not be on the table. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ryanczak at gmail.com Thu Apr 21 13:02:30 2011 From: ryanczak at gmail.com (Matt Ryanczak) Date: Thu, 21 Apr 2011 14:02:30 -0400 Subject: VPN over slow Internet connections In-Reply-To: References: <4DB06184.30508@mube.co.uk>, Message-ID: <4DB07136.90508@gmail.com> On 04/21/2011 01:32 PM, Brandon Kim wrote: > I vote for Patrick's idea of allowing the end user to remote into a machine where the SQL resides. > > This would eliminate a lot of potential issues....wish I had thought of that first!!! I third this idea. Using screen would be a good idea as well. This reminds me a project I worked on last century were we had people direct dialing our facility over modems to use a custom DB front end presented using Citrix. One of the big challenges was dropped calls. Persistence is your friend under these circumstances. At least the end users don't lose work. From ben at bjencks.net Thu Apr 21 13:43:10 2011 From: ben at bjencks.net (Ben Jencks) Date: Thu, 21 Apr 2011 14:43:10 -0400 Subject: VPN over slow Internet connections In-Reply-To: <4DB06184.30508@mube.co.uk> References: <4DB06184.30508@mube.co.uk> Message-ID: <1A20A7F0-6E11-442C-9A0C-9E34946CF8FC@bjencks.net> On Apr 21, 2011, at 12:55 PM, Ben Whorwood wrote: > Dear all, > > Can anyone share any thoughts or experiences for VPN links running over slow Internet connections, typically 2kB/s - 3kB/s (think 33.6k modem)? > > We are looking into utilising OpenVPN for out-of-office workers who would be running mobile broadband in rural areas. Typical data across the wire would be SQL queries for custom applications and not much else. > > Some initial thoughts include... > > * How well would the connection handle certificate (>= 2048 bit key) based authentication? Should be fine. Might take 30 seconds to connect, but after connection it makes no difference > * Is UDP or TCP better considering the speed and possibility of packet loss (no figures to hand)? Since you're running TCP applications (database connections), you definitely want UDP. TCP-in-UDP behaves correctly in the presence of packet loss, TCP-in-TCP behaves horribly (it causes exponential backoff on the outer VPN connection, which causes queueing of the inner packets when they should be dropped. I've seen 20-30 second latencies with TCP VPNs over slow/lossy links). > * Is VPN over this type of connection simply a bad idea? It shouldn't be any worse than running directly over the connection. With a UDP VPN it does packet-by-packet encapsulation, so it only adds the fixed per-packet overhead. From harbor235 at gmail.com Thu Apr 21 13:49:41 2011 From: harbor235 at gmail.com (harbor235) Date: Thu, 21 Apr 2011 14:49:41 -0400 Subject: riverbed steelhead Message-ID: Anyone out there have experience with Riverbed Steelhead products? Do they improve TCP performance over WAN links? is it worth the price? mike From brandon.kim at brandontek.com Thu Apr 21 13:53:55 2011 From: brandon.kim at brandontek.com (Brandon Kim) Date: Thu, 21 Apr 2011 14:53:55 -0400 Subject: VPN over slow Internet connections In-Reply-To: <4DB07136.90508@gmail.com> References: <4DB06184.30508@mube.co.uk>, , , , <4DB07136.90508@gmail.com> Message-ID: Nothing like getting into the groove, then losing your connection, waiting for the modem to dial back up and then try to figure out what you were just doing!!! Again, it goes back to what I mentioned, it "could" work but how will that affect your overall productivity. Is over the air 3G or 4G not available? I'm assuming that modem is being used because broadband is not in the area.... > Date: Thu, 21 Apr 2011 14:02:30 -0400 > From: ryanczak at gmail.com > To: nanog at nanog.org > Subject: Re: VPN over slow Internet connections > > On 04/21/2011 01:32 PM, Brandon Kim wrote: > > I vote for Patrick's idea of allowing the end user to remote into a machine where the SQL resides. > > > > This would eliminate a lot of potential issues....wish I had thought of that first!!! > I third this idea. Using screen would be a good idea as well. > > This reminds me a project I worked on last century were we had people > direct dialing our facility over modems to use a custom DB front end > presented using Citrix. > > One of the big challenges was dropped calls. Persistence is your friend > under these circumstances. At least the end users don't lose work. > > > From sfouant at shortestpathfirst.net Thu Apr 21 13:58:19 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Thu, 21 Apr 2011 14:58:19 -0400 Subject: riverbed steelhead In-Reply-To: References: Message-ID: <020901cc0056$14e4ace0$3eae06a0$@net> > -----Original Message----- > From: harbor235 [mailto:harbor235 at gmail.com] > Sent: Thursday, April 21, 2011 2:50 PM > To: NANOG list > Subject: riverbed steelhead > > Anyone out there have experience with Riverbed Steelhead products? > Do they improve TCP performance over WAN links? is it worth the price? I've had generally good experiences w/ Riverbed's Steelhead as well as Juniper's WX Series product. For certain types of applications, like email and database replication you can expect to see pretty dramatic reductions in throughput because of the technique of replacing symbols for otherwise long strings of repeatable characters. Also because of the local proxying abilities with regards to TCP ACKs and such, you can also get better pipelining of traffic... As far as whether they are worth the price, this really boils down to a proper Cost/Benefit analysis, but most of the ROI calculators show a return after as little as just a few months. Stefan Fouant From sfouant at shortestpathfirst.net Thu Apr 21 14:00:41 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Thu, 21 Apr 2011 15:00:41 -0400 Subject: riverbed steelhead In-Reply-To: <020901cc0056$14e4ace0$3eae06a0$@net> References: <020901cc0056$14e4ace0$3eae06a0$@net> Message-ID: <020c01cc0056$69ac51b0$3d04f510$@net> > -----Original Message----- > From: Stefan Fouant [mailto:sfouant at shortestpathfirst.net] > Sent: Thursday, April 21, 2011 2:58 PM > To: 'harbor235'; 'NANOG list' > Subject: RE: riverbed steelhead > > I've had generally good experiences w/ Riverbed's Steelhead as well as > Juniper's WX Series product. For certain types of applications, like > email > and database replication you can expect to see pretty dramatic > reductions in > throughput because of the technique of replacing symbols for otherwise I'm sorry, this should have read "pretty dramatic increases", not reductions. Sorry for the confusion. Stefan Fouant From jeroen at mompl.net Thu Apr 21 14:11:13 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 21 Apr 2011 12:11:13 -0700 Subject: VPN over slow Internet connections In-Reply-To: <11830.1303406225@localhost> References: <4DB06184.30508@mube.co.uk> <11830.1303406225@localhost> Message-ID: <4DB08151.8000607@mompl.net> Valdis.Kletnieks at vt.edu wrote: > Well, 33.6k is a Bad Idea right there. :) But if you're stuck with that > for technical reasons, but need a VPN for security reasons, it won't > be all *that* much worse, unless you're doing a lot of SSH or similar I would think so too. When I first moved to the States I lived in rural Oregon and used an (attempted) always on dialup for years. I could mostly get a steady 56K connection, except when there was a nest of mice in the local phone exchange/switch/box thing (whatever they're called) or a tree fell in the wrong place or it rained for weeks. Then it would be a tad slower (the fallen tree would only cause an electricity outage ;-) the phoneline often was still fine), but never go below 33.6K. Though the mice were annoying in causing a disconnect every half hour or so. Anyways, at 56K speeds 3/4 of the time and I could stream low bandwidth real audio radio and do some browsing all at the same time whilst chatting. So going from that I would say that a 33.6K connection dedicated to just VPN connectivity would work fine for things such as sql queries. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From up at 3.am Thu Apr 21 14:13:18 2011 From: up at 3.am (up at 3.am) Date: Thu, 21 Apr 2011 15:13:18 -0400 Subject: Stupid Cisco ACL question Message-ID: <85917f6e53edcd7cb06c4f2b18770dbc.squirrel@ssl.pil.net> Ok, I've done a lot of Cisco standard and extended ACLs, but I do not understand why the following does not work the way I think it should. Near the end of this extended named ACL, I have the following: permit tcp any eq 443 any permit tcp any eq 80 any deny ip any host 2.2.3.4 permit ip any any This is applied to an inbound interface(s). We want anybody outside to be able to reach ports 80 and 443 of any host on our network, no matter what, then block ALL other access to select hosts, such as 2.2.3.4, even ICMP. However, as soon as I apply this rule to the interface, ports 80 and 443 of that host become unreachable. A telnet to 2.2.3.4 443 gets "Connection refused" until I tear out the deny ACL above. I even tried adding udp for both ports, to no avail. I had always thought that these ACLs were processed in order, so that the explicit permit statement, though limited to a specific protocol but for all hosts, gets considered before the explicit deny statement for all IP to a particular host. What did I forget to consider? TIA, From dorn at hetzel.org Thu Apr 21 14:17:31 2011 From: dorn at hetzel.org (Dorn Hetzel) Date: Thu, 21 Apr 2011 15:17:31 -0400 Subject: Stupid Cisco ACL question In-Reply-To: <85917f6e53edcd7cb06c4f2b18770dbc.squirrel@ssl.pil.net> References: <85917f6e53edcd7cb06c4f2b18770dbc.squirrel@ssl.pil.net> Message-ID: On Thu, Apr 21, 2011 at 3:13 PM, wrote: > Ok, I've done a lot of Cisco standard and extended ACLs, but I do not > understand why the following does not work the way I think it should. > Near the end of this extended named ACL, I have the following: > > permit tcp any eq 443 any > Don't you want: permit tcp any any eq 443 Since you want the incoming traffic to have 443 as the destination port, not the source? > permit tcp any eq 80 any > deny ip any host 2.2.3.4 > permit ip any any > > This is applied to an inbound interface(s). We want anybody outside to be > able to reach ports 80 and 443 of any host on our network, no matter what, > then block ALL other access to select hosts, such as 2.2.3.4, even ICMP. > However, as soon as I apply this rule to the interface, ports 80 and 443 > of that host become unreachable. A telnet to 2.2.3.4 443 gets "Connection > refused" until I tear out the deny ACL above. I even tried adding udp for > both ports, to no avail. > > I had always thought that these ACLs were processed in order, so that the > explicit permit statement, though limited to a specific protocol but for > all hosts, gets considered before the explicit deny statement for all IP > to a particular host. What did I forget to consider? > > TIA, > > From Josh.Stephens at solarwinds.com Thu Apr 21 14:17:41 2011 From: Josh.Stephens at solarwinds.com (Stephens, Josh) Date: Thu, 21 Apr 2011 19:17:41 +0000 Subject: riverbed steelhead In-Reply-To: <020901cc0056$14e4ace0$3eae06a0$@net> References: <020901cc0056$14e4ace0$3eae06a0$@net> Message-ID: <7715397372EE344E96F03DBEA1E8894E423827@ADF-MBX-01.tul.solarwinds.net> I've had good experiences with the Riverbed appliances as well. Definitely a leader in my mind when compared to Cisco and Juniper although there are some new niche players that have good solutions depending on the details of your traffic and topology. One note on the Riverbeds, if you're trying to monitor their effectiveness and the traffic thru them via netflow you'll need to put them in "application port transparency mode". I may have the name of the mode a little off (going from memory) but effectively it forces the TCP ports to remain consistent as the flows are tore down and reconstructed. HTH, Josh -----Original Message----- From: Stefan Fouant [mailto:sfouant at shortestpathfirst.net] Sent: Thursday, April 21, 2011 1:58 PM To: 'harbor235'; 'NANOG list' Subject: RE: riverbed steelhead > -----Original Message----- > From: harbor235 [mailto:harbor235 at gmail.com] > Sent: Thursday, April 21, 2011 2:50 PM > To: NANOG list > Subject: riverbed steelhead > > Anyone out there have experience with Riverbed Steelhead products? > Do they improve TCP performance over WAN links? is it worth the price? I've had generally good experiences w/ Riverbed's Steelhead as well as Juniper's WX Series product. For certain types of applications, like email and database replication you can expect to see pretty dramatic reductions in throughput because of the technique of replacing symbols for otherwise long strings of repeatable characters. Also because of the local proxying abilities with regards to TCP ACKs and such, you can also get better pipelining of traffic... As far as whether they are worth the price, this really boils down to a proper Cost/Benefit analysis, but most of the ROI calculators show a return after as little as just a few months. Stefan Fouant From jcdill.lists at gmail.com Thu Apr 21 14:19:54 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 21 Apr 2011 12:19:54 -0700 Subject: VPN over slow Internet connections In-Reply-To: References: <4DB06184.30508@mube.co.uk>, , , , <4DB07136.90508@gmail.com> Message-ID: <4DB0835A.9090208@gmail.com> On 21/04/11 11:53 AM, Brandon Kim wrote: > > Nothing like getting into the groove, then losing your connection, waiting for the modem to dial back up > and then try to figure out what you were just doing!!! Again, it goes back to what I mentioned, it "could" work > but how will that affect your overall productivity. > > Is over the air 3G or 4G not available? I'm assuming that modem is being used because broadband is not in the area.... > > The OP said: > Can anyone share any thoughts or experiences for VPN links running > over slow Internet connections, typically 2kB/s - 3kB/s (think 33.6k > modem)? > > We are looking into utilising OpenVPN for out-of-office workers who > would be running mobile broadband in rural areas. It looks like they are using the fastest mobile (cellular) access solutions available in these rural areas with throughput speeds that are *about* the same as dial-up modem speeds. Mobile broadband (sic) is tuned for faster downloads, upload speeds can be very very slow, especially if you are on the edge of their service range. (I used Verizon EVDO devices for several years, have extensive first-hand experience in how slowly they work in many rural areas.) jc From jay-ford at uiowa.edu Thu Apr 21 14:20:09 2011 From: jay-ford at uiowa.edu (Jay Ford) Date: Thu, 21 Apr 2011 14:20:09 -0500 (CDT) Subject: Stupid Cisco ACL question In-Reply-To: <85917f6e53edcd7cb06c4f2b18770dbc.squirrel@ssl.pil.net> References: <85917f6e53edcd7cb06c4f2b18770dbc.squirrel@ssl.pil.net> Message-ID: On Thu, 21 Apr 2011, up at 3.am wrote: > permit tcp any eq 443 any > permit tcp any eq 80 any > deny ip any host 2.2.3.4 > permit ip any any > > This is applied to an inbound interface(s). We want anybody outside to be > able to reach ports 80 and 443 of any host on our network, no matter what, > then block ALL other access to select hosts, such as 2.2.3.4, even ICMP. > However, as soon as I apply this rule to the interface, ports 80 and 443 > of that host become unreachable. A telnet to 2.2.3.4 443 gets "Connection > refused" until I tear out the deny ACL above. I even tried adding udp for > both ports, to no avail. Your ACL is apply the 80 & 443 as source ports, not destination ports. You probably want: permit tcp any any eq 443 permit tcp any any eq 80 deny ip any host 2.2.3.4 permit ip any any ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford at uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From millnert at gmail.com Thu Apr 21 14:25:54 2011 From: millnert at gmail.com (Martin Millnert) Date: Thu, 21 Apr 2011 15:25:54 -0400 Subject: Voice Peering? In-Reply-To: <00cc01cc0045$afc0e6e0$0f42b4a0$@sberkman.net> References: <00cc01cc0045$afc0e6e0$0f42b4a0$@sberkman.net> Message-ID: On Thu, Apr 21, 2011 at 1:00 PM, Scott Berkman wrote: > It's not specific for mobile, but this is one of the most well know VOIP > exchanges: And here I thought IP exchanges would cover the IP in VOIP. When do we get HTTP exchanges? :) Regards, Martin From jsaxe at briworks.com Thu Apr 21 14:26:33 2011 From: jsaxe at briworks.com (Jeff Saxe) Date: Thu, 21 Apr 2011 19:26:33 +0000 Subject: Stupid Cisco ACL question In-Reply-To: <85917f6e53edcd7cb06c4f2b18770dbc.squirrel@ssl.pil.net> References: <85917f6e53edcd7cb06c4f2b18770dbc.squirrel@ssl.pil.net> Message-ID: If this is applied inbound from the Internet, then the first two permits are permitting reply traffic from the far-end Web server's ports 80 or 443 back toward your surfing workstations or servers. You should think of those as permit - just TCP -- where the SOURCE is any IP address, but source PORT of 80 -- and where the DESTINATION is any IP, any port This is more applicable as a "poor man's firewall" where you're trying to permit inside workstations to get to certain services on the outside, and permit return traffic, but not have anyone outside reach services inside. But without a real stateful firewall it doesn't work too well. Probably what you want is for the outside public to be able to reach just ports 80 and 443 on host 2.2.3.4, but no other services on that host, and other than those special cases, to be unrestricted through this interface. In that case, as Dorn Hetzel just chimed in, you probably want (spaced out to be clearer than the syntax naturally prints out) permit tcp any host 2.2.3.4 eq 80 permit tcp any host 2.2.3.4 eq 443 deny ip any host 2.2.3.4 permit ip any any -- Jeff Saxe ________________________________________ From: up at 3.am [up at 3.am] Sent: Thursday, April 21, 2011 3:13 PM To: nanog at nanog.org Subject: Stupid Cisco ACL question Ok, I've done a lot of Cisco standard and extended ACLs, but I do not understand why the following does not work the way I think it should. Near the end of this extended named ACL, I have the following: permit tcp any eq 443 any permit tcp any eq 80 any deny ip any host 2.2.3.4 permit ip any any This is applied to an inbound interface(s). We want anybody outside to be able to reach ports 80 and 443 of any host on our network, no matter what, then block ALL other access to select hosts, such as 2.2.3.4, even ICMP. However, as soon as I apply this rule to the interface, ports 80 and 443 of that host become unreachable. A telnet to 2.2.3.4 443 gets "Connection refused" until I tear out the deny ACL above. I even tried adding udp for both ports, to no avail. I had always thought that these ACLs were processed in order, so that the explicit permit statement, though limited to a specific protocol but for all hosts, gets considered before the explicit deny statement for all IP to a particular host. What did I forget to consider? TIA, From jmaslak at antelope.net Thu Apr 21 14:36:36 2011 From: jmaslak at antelope.net (Joel Maslak) Date: Thu, 21 Apr 2011 13:36:36 -0600 Subject: riverbed steelhead In-Reply-To: References: Message-ID: On Thu, Apr 21, 2011 at 12:49 PM, harbor235 wrote: > Anyone out there have experience with Riverbed Steelhead products? > Do they improve TCP performance over WAN links? is it worth the price? > I'll let others answer the specific question about Riverbed. I've heard plenty of good things about them though. (forgive me if this is extremely basic) If the problem is that someone downloading a big file slows the whole office down, there may be cheaper ways of solving this. Assuming your WAN links are private connections (not VPN over internet), I'd also suggest before spending money that you ensure you are doing some sort of fair queuing with RED/WRED enabled. This will ensure with on a network dominated by typical business TCP that one user can't monopolize a circuit. I'd also ensure that you are not sending bits faster than your provider will allow (beyond your burstable bit rate) by ensuring your bandwidth selections on your interfaces are set correctly. You might be able to fix your users' concerns/complaints just by a few lines of router config (and if you're using anything beyond home routers, your routers probably already support these things). In my experience, the problem isn't that the line is too small for the workload, but rather that bulk transfers keep everyone from doing work over it - that's where fair queuing and WRED come in. If you've already done this, than please ignore this suggestion. :) -- Joel Maslak From up at 3.am Thu Apr 21 14:42:51 2011 From: up at 3.am (up at 3.am) Date: Thu, 21 Apr 2011 15:42:51 -0400 Subject: Stupid Cisco ACL question In-Reply-To: References: <85917f6e53edcd7cb06c4f2b18770dbc.squirrel@ssl.pil.net> Message-ID: Thanks everyone, of course this is what I wanted. Like I said, a stupid ACL question...I'm blaming heavy medication, sorry for the noise! > On Thu, 21 Apr 2011, up at 3.am wrote: >> permit tcp any eq 443 any >> permit tcp any eq 80 any >> deny ip any host 2.2.3.4 >> permit ip any any >> >> This is applied to an inbound interface(s). We want anybody outside to >> be >> able to reach ports 80 and 443 of any host on our network, no matter >> what, >> then block ALL other access to select hosts, such as 2.2.3.4, even ICMP. >> However, as soon as I apply this rule to the interface, ports 80 and 443 >> of that host become unreachable. A telnet to 2.2.3.4 443 gets >> "Connection >> refused" until I tear out the deny ACL above. I even tried adding udp >> for >> both ports, to no avail. > > Your ACL is apply the 80 & 443 as source ports, not destination ports. > > You probably want: > permit tcp any any eq 443 > permit tcp any any eq 80 > deny ip any host 2.2.3.4 > permit ip any any > > ________________________________________________________________________ > Jay Ford, Network Engineering Group, Information Technology Services > University of Iowa, Iowa City, IA 52242 > email: jay-ford at uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 > From wschultz at bsdboy.com Thu Apr 21 14:46:03 2011 From: wschultz at bsdboy.com (Wil Schultz) Date: Thu, 21 Apr 2011 12:46:03 -0700 Subject: VPN over slow Internet connections In-Reply-To: <4DB08151.8000607@mompl.net> References: <4DB06184.30508@mube.co.uk> <11830.1303406225@localhost> <4DB08151.8000607@mompl.net> Message-ID: <4BE63547-E36A-42FF-9522-631380BBA216@bsdboy.com> On Apr 21, 2011, at 12:11 PM, Jeroen van Aart wrote: > Valdis.Kletnieks at vt.edu wrote: >> Well, 33.6k is a Bad Idea right there. :) But if you're stuck with that >> for technical reasons, but need a VPN for security reasons, it won't >> be all *that* much worse, unless you're doing a lot of SSH or similar > > I would think so too. When I first moved to the States I lived in rural Oregon and used an (attempted) always on dialup for years. I could mostly get a steady 56K connection, except when there was a nest of mice in the local phone exchange/switch/box thing (whatever they're called) or a tree fell in the wrong place or it rained for weeks. Then it would be a tad slower (the fallen tree would only cause an electricity outage ;-) the phoneline often was still fine), but never go below 33.6K. Though the mice were annoying in causing a disconnect every half hour or so. > > Anyways, at 56K speeds 3/4 of the time and I could stream low bandwidth real audio radio and do some browsing all at the same time whilst chatting. So going from that I would say that a 33.6K connection dedicated to just VPN connectivity would work fine for things such as sql queries. > > Greetings, > Jeroen > > -- > http://goldmark.org/jeff/stupid-disclaimers/ > http://linuxmafia.com/~rick/faq/plural-of-virus.html > Assuming the slow connection, I would guess there would be some packet loss to go along with it which could make not an ideal situation even worse. We've all done things we're not proud of because of business need, from the outside looking in I would definitely hammer home very low expectations before rolling it out. If they think it's going to be great they've got another thing coming, if they expect it to be barely usable they just might be pleasantly surprised. -wil From bill at herrin.us Thu Apr 21 14:51:11 2011 From: bill at herrin.us (William Herrin) Date: Thu, 21 Apr 2011 15:51:11 -0400 Subject: Stupid Cisco ACL question In-Reply-To: <85917f6e53edcd7cb06c4f2b18770dbc.squirrel@ssl.pil.net> References: <85917f6e53edcd7cb06c4f2b18770dbc.squirrel@ssl.pil.net> Message-ID: On Thu, Apr 21, 2011 at 3:13 PM, wrote: > Ok, I've done a lot of Cisco standard and extended ACLs, but I do not > understand why the following does not work the way I think it should. > Near the end of this extended named ACL, I have the following: > > ?permit tcp any eq 443 any > ?permit tcp any eq 80 any > ?deny ip any host 2.2.3.4 > ?permit ip any any > > This is applied to an inbound interface(s). Many many problems with this ACL. 1. In the inbound (from the Internet) interface you want the destination port, not the source port. I.e. permit tcp any any eq 443. The above would only make sense if your web server was 2.2.3.4 and the ACL was applied to outbound traffic entering the interior router interface (facing the web server). That's a back-assward way to do things since you probably want to limit packets from reaching the web server, not limit the web server's packets from exiting. 2. TCP packets go both ways and the ones you initiate tend to do so on random ports. Implication: the destination port on this packet is the source port on the reply. Your probably meant to block only the connection establishment packet. I.e. permit tcp any any eq 443; permit tcp any any established 3. ICMP destination unreachable messages are MANDATORY for TCP PMTUD function. You didn't disable PMTUD on your server (it's on by default) and we'd beat you up if you did. Your ACL breaks the protocol by blocking those ICMP messages. Add "permit icmp any any unreachable" prior to "deny ip any host 2.2.3.4" 4. Several other ICMP messages help you and your customers figure out what's wrong when things don't work. This includes echo-request and echo-reply. Strongly advise you to enable them. 5. Is your DNS resolver inside your network? If not, you'll need to enable UDP *and* TCP packets to and from the DNS resolver. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From smb at cs.columbia.edu Thu Apr 21 15:19:46 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 21 Apr 2011 16:19:46 -0400 Subject: VPN over slow Internet connections In-Reply-To: <4DB06184.30508@mube.co.uk> References: <4DB06184.30508@mube.co.uk> Message-ID: On Apr 21, 2011, at 12:55 32PM, Ben Whorwood wrote: > Dear all, > > Can anyone share any thoughts or experiences for VPN links running over slow Internet connections, typically 2kB/s - 3kB/s (think 33.6k modem)? > > We are looking into utilising OpenVPN for out-of-office workers who would be running mobile broadband in rural areas. Typical data across the wire would be SQL queries for custom applications and not much else. > > Some initial thoughts include... > > * How well would the connection handle certificate (>= 2048 bit key) based authentication? You're doing this rarely; it shouldn't be a problem. > * Is UDP or TCP better considering the speed and possibility of packet loss (no figures to hand)? For your application or for the VPN? For the VPN, I *strongly* suggest you use UDP, or you're going to get dueling retransmissions and spend a lot of time sending many copies of the same thing. Consider: if a packet is dropped, either due to line noise or queuing delay for the slow link, the sending TCP will resend. If you're using TCP for OpenVPN, that session's TCP will resend. Of course, the TCP running on top of it will resend as well, so you'll get two copies of the data sent to the application's TCP, wasting precious bandwidth. If, on the other hand, OpenVPN is running UDP, it won't resend; the application's TCP will, so you'll only get one copy. I should note: IPsec, being datagram-based, will also work well. PPTP, which runs over TCP as far as I know, will suffer all of the ills I just outlined. I'm assuming that your application is using TCP. Unless the data characteristics are such that you're able to fit every query and every response into a single packet, you'll spend more effort (and probably bandwidth) doing your own retransmissions, backoffs, segementation, etc. > * Is VPN over this type of connection simply a bad idea? > If you do it correctly, a VPN is actually better: you can assign a static internal IP address to each certificate. If the modem connection drops, when you reconnect the applications will still have the same IP address, so their connections won't be interrupted. You do have to watch out for queue limits -- as Jim Gettys has reminded us, many of today's queues are far too long, so we're not getting the very beneficial effects of early drop and consequent TCP slow-down. This will require tuning your end nodes OS and/or the router at your head end. Use active queue management (e.g., RED), and consider a priority queueing scheme. Watch out for other applications -- I've had trouble with MacOS's Mail.App on slow links; it's gotten very confused and more or less forgotten about my mail folders, with the consequent need to rebuild them, reactivate my sorting rules, etc. (Note that this paragraph applies whether or not you're using a VPN; it's the effect of a slow connection, not the crypto.) The real VPN question is what the overhead is. I've never calculated it for OpenVPN; I did for IPsec some years ago (long enough ago that IPsec was still using DES or 3DES because AES and its 16-byte blocksize didn't exist); using average packet size distribution, it came to (as I recall) about 12%. That's unlikely to make or break your system. However, there's no substitute for real data -- what do your packets look like? Fairly obviously, the shorter the packet, the higher the overhead percentage. Someone suggested trying it using a FreeBSD flakeway; that's a good idea. In short -- if your VPN is set up properly, any ill effects are much more likely to be from the link speed itself, not the VPN. --Steve Bellovin, https://www.cs.columbia.edu/~smb From regnauld at nsrc.org Thu Apr 21 15:31:32 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 21 Apr 2011 22:31:32 +0200 Subject: VPN over slow Internet connections In-Reply-To: References: <4DB06184.30508@mube.co.uk> Message-ID: <20110421203129.GQ27269@macbook.catpipe.net> Steven Bellovin (smb) writes: > > I should note: IPsec, being datagram-based, will also work well. PPTP, > which runs over TCP as far as I know, will suffer all of the ills I just > outlined. PPTP uses 1723/tcp for control, but the tunneled traffic is GRE, so that would work fine as well. > If you do it correctly, a VPN is actually better: you can assign a > static internal IP address to each certificate. If the modem connection > drops, when you reconnect the applications will still have the same > IP address, so their connections won't be interrupted. Absolutely, that's the case with OpenVPN, if you assign static IPs to each profile. PPtP can do this as well, for instance using MPD. Very big advantage in fact. > Someone suggested trying it using a FreeBSD flakeway; that's a good idea. Using a dummynet box as a router (or bridge for that matter), you have the benefit that you can run tcpdump on the trafic, and record the packet sizes with and and without VPN, then derive the actual observed overhead. Cheers, Phil From smb at cs.columbia.edu Thu Apr 21 15:33:34 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 21 Apr 2011 16:33:34 -0400 Subject: VPN over slow Internet connections In-Reply-To: <20110421203129.GQ27269@macbook.catpipe.net> References: <4DB06184.30508@mube.co.uk> <20110421203129.GQ27269@macbook.catpipe.net> Message-ID: On Apr 21, 2011, at 4:31 32PM, Phil Regnauld wrote: > Steven Bellovin (smb) writes: >> >> I should note: IPsec, being datagram-based, will also work well. PPTP, >> which runs over TCP as far as I know, will suffer all of the ills I just >> outlined. > > PPTP uses 1723/tcp for control, but the tunneled traffic is GRE, > so that would work fine as well. Ah, thanks for the correction. > >> If you do it correctly, a VPN is actually better: you can assign a >> static internal IP address to each certificate. If the modem connection >> drops, when you reconnect the applications will still have the same >> IP address, so their connections won't be interrupted. > > Absolutely, that's the case with OpenVPN, if you assign static IPs to > each profile. PPtP can do this as well, for instance using MPD. > Very big advantage in fact. Yup, I've done this myself with OpenVPN. --Steve Bellovin, https://www.cs.columbia.edu/~smb From scott at sberkman.net Thu Apr 21 15:38:27 2011 From: scott at sberkman.net (Scott Berkman) Date: Thu, 21 Apr 2011 16:38:27 -0400 Subject: Voice Peering? In-Reply-To: References: <00cc01cc0045$afc0e6e0$0f42b4a0$@sberkman.net> Message-ID: <010701cc0064$11ca6c30$355f4490$@sberkman.net> Among other services, the VPF provides an ENUM infrastructure for doing lookups using DNS for what carrier in the exchange can route calls to a specific TN. But yes, the underlying concept of the actual interconnections are similar to IP exchanges. There are also application specific exchanges out there, especially in the financial markets. -Scott -----Original Message----- From: Martin Millnert [mailto:millnert at gmail.com] Sent: Thursday, April 21, 2011 3:26 PM To: Scott Berkman Cc: Santino Codispoti; nanog at nanog.org Subject: Re: Voice Peering? On Thu, Apr 21, 2011 at 1:00 PM, Scott Berkman wrote: > It's not specific for mobile, but this is one of the most well know VOIP > exchanges: And here I thought IP exchanges would cover the IP in VOIP. When do we get HTTP exchanges? :) Regards, Martin From carlos at race.com Thu Apr 21 16:03:59 2011 From: carlos at race.com (Carlos Alcantar) Date: Thu, 21 Apr 2011 21:03:59 +0000 Subject: Voice Peering? In-Reply-To: <010701cc0064$11ca6c30$355f4490$@sberkman.net> Message-ID: What would be nice is a voice peering that actually act's as a traditional tandem. Carlos Alcantar Race Communications / Race Team Member 101 Haskins Way, So. San Francisco, CA. 94080 Phone: +1 415 376 3314 Fax: +1 650 246 8901 / carlos *at* race.com / http://www.race.com On 4/21/11 1:38 PM, "Scott Berkman" wrote: >Among other services, the VPF provides an ENUM infrastructure for doing >lookups using DNS for what carrier in the exchange can route calls to a >specific TN. But yes, the underlying concept of the actual >interconnections >are similar to IP exchanges. > >There are also application specific exchanges out there, especially in the >financial markets. > > -Scott > >-----Original Message----- >From: Martin Millnert [mailto:millnert at gmail.com] >Sent: Thursday, April 21, 2011 3:26 PM >To: Scott Berkman >Cc: Santino Codispoti; nanog at nanog.org >Subject: Re: Voice Peering? > >On Thu, Apr 21, 2011 at 1:00 PM, Scott Berkman wrote: >> It's not specific for mobile, but this is one of the most well know VOIP >> exchanges: > >And here I thought IP exchanges would cover the IP in VOIP. > >When do we get HTTP exchanges? :) > >Regards, >Martin > > > From tbaranski at mail.com Thu Apr 21 16:28:46 2011 From: tbaranski at mail.com (Terry Baranski) Date: Thu, 21 Apr 2011 17:28:46 -0400 Subject: VPN over slow Internet connections In-Reply-To: References: <4DB06184.30508@mube.co.uk> Message-ID: <000101cc006b$1af5f890$50e1e9b0$@com> On Apr 21, 2011, at 4:20PM, Steven Bellovin wrote: > For your application or for the VPN? For the VPN, I *strongly* > suggest you use UDP, or you're going to get dueling retransmissions > and spend a lot of time sending many copies of the same thing. Consider: > if a packet is dropped, either due to line noise or queuing delay for > the slow link, the sending TCP will resend. If you're using TCP for > OpenVPN, that session's TCP will resend. Of course, the TCP running > on top of it will resend as well, so you'll get two copies of the data > sent to the application's TCP, wasting precious bandwidth. Is this actually how OpenVPN's TCP encapsulation works? I'd be curious to know. It isn't how Cisco's TCP/10000 encapsulation works, at least not with the IOS devices I have experience with. Cisco's TCP/10000 looks like TCP to a firewall, but it really isn't. There is no reliability -- no retransmits, etc. It's pretty close to UDP behavior but with a TCP header, which was confusing to troubleshoot at first but quickly made perfect sense to me for the reasons you state above. -Terry From dwhite at olp.net Thu Apr 21 16:36:50 2011 From: dwhite at olp.net (Dan White) Date: Thu, 21 Apr 2011 16:36:50 -0500 Subject: Youtube Geolocation Message-ID: <20110421213649.GL4718@dan.olp.net> We're experiencing very poor quality with You Tube, and it appears we're subject to a bad entry within a geolocation database somewhere. When we attempt to view videos, the contact comes back to us from IPs like: 208.117.226.21 (traceroute's through Frankfurt) 173.194.50.47 74.125.100.29 All of those IPs are >125ms away from us (67.217.144.0/20, and 216.14.144.0/20). However, we've never experienced redirection problems with Google before (we always land at www.google.com), so I'm not sure where to take our trouble. The page at: http://www.google.com/support/websearch/bin/request.py?contact_type=ip isn't of much help as it assumes the problem is google.com redirection. Are there any contacts at Youtube who could provide some assistance? Thanks, -- Dan White From denys at visp.net.lb Thu Apr 21 16:47:50 2011 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Fri, 22 Apr 2011 00:47:50 +0300 Subject: VPN over slow Internet connections In-Reply-To: <4DB06184.30508@mube.co.uk> References: <4DB06184.30508@mube.co.uk> Message-ID: On Thu, 21 Apr 2011 17:55:32 +0100, Ben Whorwood wrote: IMHO it is not good idea to go to OpenVPN/IPSec/etc level at all (IP layer at least, and in case of Windows it is also ethernet headers). First of all OpenVPN for Windows/different OS sometimes become a headache and need admin privileges. If you have just SQL queries and one TCP port to database - just use stunnel. Maybe even easier, if it is custom application, to embed TLS directly to application, and you can still run nice certificate authorization (same TLS), and it will be much more transparent for user. From smb at cs.columbia.edu Thu Apr 21 16:53:36 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 21 Apr 2011 17:53:36 -0400 Subject: VPN over slow Internet connections In-Reply-To: <000101cc006b$1af5f890$50e1e9b0$@com> References: <4DB06184.30508@mube.co.uk> <000101cc006b$1af5f890$50e1e9b0$@com> Message-ID: On Apr 21, 2011, at 5:28 46PM, Terry Baranski wrote: > On Apr 21, 2011, at 4:20PM, Steven Bellovin wrote: > >> For your application or for the VPN? For the VPN, I *strongly* >> suggest you use UDP, or you're going to get dueling retransmissions >> and spend a lot of time sending many copies of the same thing. Consider: >> if a packet is dropped, either due to line noise or queuing delay for >> the slow link, the sending TCP will resend. If you're using TCP for >> OpenVPN, that session's TCP will resend. Of course, the TCP running >> on top of it will resend as well, so you'll get two copies of the data >> sent to the application's TCP, wasting precious bandwidth. > > Is this actually how OpenVPN's TCP encapsulation works? I'd be curious to > know. It isn't how Cisco's TCP/10000 encapsulation works, at least not with > the IOS devices I have experience with. > > Cisco's TCP/10000 looks like TCP to a firewall, but it really isn't. There > is no reliability -- no retransmits, etc. It's pretty close to UDP behavior > but with a TCP header, which was confusing to troubleshoot at first but > quickly made perfect sense to me for the reasons you state above. > To the OS, OpenVPN is an application that uses the underlying TCP (or UDP)/IP stack; it can't behave any differently than any other application. Since (as far as I know) Windows, Linux, NeBSD, FreeBSD, MacOS, and all of the other platforms that OpenVPN runs on just have normal TCPs, that's what OpenVPN does. --Steve Bellovin, https://www.cs.columbia.edu/~smb From crosevear at skytap.com Thu Apr 21 17:19:08 2011 From: crosevear at skytap.com (Carl Rosevear) Date: Thu, 21 Apr 2011 15:19:08 -0700 Subject: Youtube Geolocation In-Reply-To: <20110421213649.GL4718@dan.olp.net> References: <20110421213649.GL4718@dan.olp.net> Message-ID: I have had this same problem, followed Google's forms, etc... they never seem to fix it. Its really annoying. This is an epic fail on the part of Google in my opinion. My netblocks all show Seattle in whois... my routing is obviously here... I don't think we have an official address in the UK listed on anything. How does Google get this information? Why don't they possibly ever do anything about it? It makes Google's properties perform abysmally to a large percentage of our customer base. And then we get blamed for it. And Google does nothing, even after submitting the web form that clearly states that they will not get back to us about it but will try to resolve the issue. Its quite hideous really. Its in everyone's worst interest. How about maybe trusting my whois data? If whois data leads to incorrect results then it is in the netblock owners' best interest to update the whois data if they want to be directed efficiently with gslb/etc that uses whois data as the source. And I've been working with ip-geo stuff for years... I understand that a lot of effort has gone into making it "better" than the whois data... but every other freaking IP geolocator I type my IP into properly recognizes the addresses are in Seattle... why not Google? Anyway, I at the very least commiserate with you if I'm not perhaps making some passive-aggressive cry for help from Google or anyone else with a clue bat about this issue. :) Thanks! --C On Thu, Apr 21, 2011 at 2:36 PM, Dan White wrote: > We're experiencing very poor quality with You Tube, and it appears we're > subject to a bad entry within a geolocation database somewhere. > > When we attempt to view videos, the contact comes back to us from IPs like: > > 208.117.226.21 (traceroute's through Frankfurt) > 173.194.50.47 > 74.125.100.29 > > All of those IPs are >125ms away from us (67.217.144.0/20, and > 216.14.144.0/20). > > However, we've never experienced redirection problems with Google before > (we always land at www.google.com), so I'm not sure where to take our > trouble. The page at: > > http://www.google.com/support/websearch/bin/request.py?contact_type=ip > > isn't of much help as it assumes the problem is google.com redirection. > > Are there any contacts at Youtube who could provide some assistance? > > Thanks, > -- > Dan White > > -- Carl Rosevear Manager of Operations Skytap, Inc. direct (206) 588-8899 From Mike.Schoenfeld at mediatek.com Thu Apr 21 17:29:31 2011 From: Mike.Schoenfeld at mediatek.com (Mike Schoenfeld) Date: Thu, 21 Apr 2011 18:29:31 -0400 Subject: Youtube Geolocation In-Reply-To: References: <20110421213649.GL4718@dan.olp.net> Message-ID: <1F49C71AB85A1E4DB9AC761F16E2DEE11B0020@MTKMBS60.mediatek.inc> I don't know what Google uses but any company using F5 equipment is using Quova geolocation services. You can request updates and check your circuit here: http://www.quova.com/what/request-ip-update/ The problem is that the F5 devices don't update the database files automatically, they need to be manually updated. Unless I get a specific request at my company I don't bother updating on a regular basis. -Mike -----Original Message----- From: Carl Rosevear [mailto:crosevear at skytap.com] Sent: Thursday, April 21, 2011 6:19 PM To: nanog at nanog.org Subject: Re: Youtube Geolocation I have had this same problem, followed Google's forms, etc... they never seem to fix it. Its really annoying. This is an epic fail on the part of Google in my opinion. My netblocks all show Seattle in whois... my routing is obviously here... I don't think we have an official address in the UK listed on anything. How does Google get this information? Why don't they possibly ever do anything about it? It makes Google's properties perform abysmally to a large percentage of our customer base. And then we get blamed for it. And Google does nothing, even after submitting the web form that clearly states that they will not get back to us about it but will try to resolve the issue. Its quite hideous really. Its in everyone's worst interest. How about maybe trusting my whois data? If whois data leads to incorrect results then it is in the netblock owners' best interest to update the whois data if they want to be directed efficiently with gslb/etc that uses whois data as the source. And I've been working with ip-geo stuff for years... I understand that a lot of effort has gone into making it "better" than the whois data... but every other freaking IP geolocator I type my IP into properly recognizes the addresses are in Seattle... why not Google? Anyway, I at the very least commiserate with you if I'm not perhaps making some passive-aggressive cry for help from Google or anyone else with a clue bat about this issue. :) Thanks! --C On Thu, Apr 21, 2011 at 2:36 PM, Dan White wrote: > We're experiencing very poor quality with You Tube, and it appears > we're subject to a bad entry within a geolocation database somewhere. > > When we attempt to view videos, the contact comes back to us from IPs like: > > 208.117.226.21 (traceroute's through Frankfurt) > 173.194.50.47 > 74.125.100.29 > > All of those IPs are >125ms away from us (67.217.144.0/20, and > 216.14.144.0/20). > > However, we've never experienced redirection problems with Google > before (we always land at www.google.com), so I'm not sure where to > take our trouble. The page at: > > http://www.google.com/support/websearch/bin/request.py?contact_type=ip > > isn't of much help as it assumes the problem is google.com redirection. > > Are there any contacts at Youtube who could provide some assistance? > > Thanks, > -- > Dan White > > -- Carl Rosevear Manager of Operations Skytap, Inc. direct (206) 588-8899 ************* Email Confidentiality Notice ******************** The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you! From crosevear at skytap.com Thu Apr 21 17:46:46 2011 From: crosevear at skytap.com (Carl Rosevear) Date: Thu, 21 Apr 2011 15:46:46 -0700 Subject: Youtube Geolocation In-Reply-To: <1F49C71AB85A1E4DB9AC761F16E2DEE11B0020@MTKMBS60.mediatek.inc> References: <20110421213649.GL4718@dan.olp.net> <1F49C71AB85A1E4DB9AC761F16E2DEE11B0020@MTKMBS60.mediatek.inc> Message-ID: Quova, Maxmind, and others all return accurate results for everything of ours I have tested. Some of the IPs in question have been properly assigned or delegated to us for several years in whois. But yeah, thanks for the input... I actually hadn't checked Quova until now. Perhaps Google rolls their own... --Carl On Thu, Apr 21, 2011 at 3:29 PM, Mike Schoenfeld < Mike.Schoenfeld at mediatek.com> wrote: > I don't know what Google uses but any company using F5 equipment is using > Quova geolocation services. You can request updates and check your circuit > here: > > http://www.quova.com/what/request-ip-update/ > > The problem is that the F5 devices don't update the database files > automatically, they need to be manually updated. Unless I get a specific > request at my company I don't bother updating on a regular basis. > > -Mike > > -----Original Message----- > From: Carl Rosevear [mailto:crosevear at skytap.com] > Sent: Thursday, April 21, 2011 6:19 PM > To: nanog at nanog.org > Subject: Re: Youtube Geolocation > > I have had this same problem, followed Google's forms, etc... they never > seem to fix it. Its really annoying. > > This is an epic fail on the part of Google in my opinion. My netblocks all > show Seattle in whois... my routing is obviously here... I don't think we > have an official address in the UK listed on anything. > > How does Google get this information? Why don't they possibly ever do > anything about it? It makes Google's properties perform abysmally to a > large percentage of our customer base. And then we get blamed for it. > > And Google does nothing, even after submitting the web form that clearly > states that they will not get back to us about it but will try to resolve > the issue. Its quite hideous really. Its in everyone's worst interest. How > about maybe trusting my whois data? If whois data leads to incorrect > results then it is in the netblock owners' best interest to update the whois > data if they want to be directed efficiently with gslb/etc that uses whois > data as the source. > > And I've been working with ip-geo stuff for years... I understand that a > lot of effort has gone into making it "better" than the whois data... but > every other freaking IP geolocator I type my IP into properly recognizes the > addresses are in Seattle... why not Google? > > Anyway, I at the very least commiserate with you if I'm not perhaps making > some passive-aggressive cry for help from Google or anyone else with a clue > bat about this issue. :) Thanks! > > > > --C > > > On Thu, Apr 21, 2011 at 2:36 PM, Dan White wrote: > > > We're experiencing very poor quality with You Tube, and it appears > > we're subject to a bad entry within a geolocation database somewhere. > > > > When we attempt to view videos, the contact comes back to us from IPs > like: > > > > 208.117.226.21 (traceroute's through Frankfurt) > > 173.194.50.47 > > 74.125.100.29 > > > > All of those IPs are >125ms away from us (67.217.144.0/20, and > > 216.14.144.0/20). > > > > However, we've never experienced redirection problems with Google > > before (we always land at www.google.com), so I'm not sure where to > > take our trouble. The page at: > > > > http://www.google.com/support/websearch/bin/request.py?contact_type=ip > > > > isn't of much help as it assumes the problem is google.com redirection. > > > > Are there any contacts at Youtube who could provide some assistance? > > > > Thanks, > > -- > > Dan White > > > > > > > -- > Carl Rosevear > Manager of Operations > Skytap, Inc. > direct (206) 588-8899 > ************* Email Confidentiality Notice ******************** > The information contained in this e-mail message (including any > attachments) may be confidential, proprietary, privileged, or otherwise > exempt from disclosure under applicable laws. It is intended to be > conveyed only to the designated recipient(s). Any use, dissemination, > distribution, printing, retaining or copying of this e-mail (including its > attachments) by unintended recipient(s) is strictly prohibited and may > be unlawful. If you are not an intended recipient of this e-mail, or > believe > that you have received this e-mail in error, please notify the sender > immediately (by replying to this e-mail), delete any and all copies of > this e-mail (including any attachments) from your system, and do not > disclose the content of this e-mail to any other person. Thank you! > > -- Carl Rosevear Manager of Operations Skytap, Inc. direct (206) 588-8899 From dwhite at olp.net Thu Apr 21 19:22:29 2011 From: dwhite at olp.net (Dan White) Date: Thu, 21 Apr 2011 19:22:29 -0500 Subject: Youtube Geolocation In-Reply-To: References: <20110421213649.GL4718@dan.olp.net> <1F49C71AB85A1E4DB9AC761F16E2DEE11B0020@MTKMBS60.mediatek.inc> Message-ID: <20110422002229.GC3420@dan.olp.net> On 21/04/11?15:46?-0700, Carl Rosevear wrote: >Quova, Maxmind, and others all return accurate results for everything of >ours I have tested. Some of the IPs in question have been properly assigned >or delegated to us for several years in whois. But yeah, thanks for the >input... I actually hadn't checked Quova until now. Perhaps Google rolls >their own... I'll have to re-echo your experience, which doesn't bode well for our chances. The link below returns accurate information for me too. Our blocks have been in use for years and we have not experienced even a hint of geolocation related problems before. Direct peering would be our ideal solution to this problem, but Google doesn't appear to play in our smaller market. >On Thu, Apr 21, 2011 at 3:29 PM, Mike Schoenfeld < >Mike.Schoenfeld at mediatek.com> wrote: > >> I don't know what Google uses but any company using F5 equipment is using >> Quova geolocation services. You can request updates and check your circuit >> here: >> >> http://www.quova.com/what/request-ip-update/ >> >> The problem is that the F5 devices don't update the database files >> automatically, they need to be manually updated. Unless I get a specific >> request at my company I don't bother updating on a regular basis. From jeroen at mompl.net Thu Apr 21 20:02:47 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 21 Apr 2011 18:02:47 -0700 Subject: 365x24x7 In-Reply-To: References: <4DA8AA64.2060403@dcrocker.net> Message-ID: <4DB0D3B7.3080900@mompl.net> Bill Stewart wrote: > Rotating shifts between daytime and nighttime is a horrible thing to > do to your workers, both for their health and their attention span. I Fully agree. I think it may pay off to search for people who suffer "Delayed sleep phase syndrome" to do night shift. They'll be happy and you'll actually have someone who is more awake and alert than the average person at that time of day. http://en.wikipedia.org/wiki/Delayed_sleep_phase_syndrome I think the IT world has a more than average incidence of people with this particular syndrome, at least in my experience. Of course in practice you would want to word your vacancy in such a way it doesn't sound silly. But I think it could be worth it to put an emphasis on it. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From bblackford at gmail.com Thu Apr 21 20:24:14 2011 From: bblackford at gmail.com (Bill Blackford) Date: Thu, 21 Apr 2011 18:24:14 -0700 Subject: gmail dropping mesages Message-ID: I've recently observed gmail dropping messages or not forwarding all messages/posts from the nanog list. This is rather annoying. Has anyone else experienced this? Does anyone have any insight as to why? Thanks, -b -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... From morrowc.lists at gmail.com Thu Apr 21 20:31:51 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 21 Apr 2011 21:31:51 -0400 Subject: gmail dropping mesages In-Reply-To: References: Message-ID: On Thu, Apr 21, 2011 at 9:24 PM, Bill Blackford wrote: > I've recently observed gmail dropping messages or not forwarding all > messages/posts ?from the nanog list. This is rather annoying. > > Has anyone else experienced this? Does anyone have any insight as to why? sometimes nanog mail gets marked as spam for me ... I think spam does not get auto-forwarded. From bblackford at gmail.com Thu Apr 21 20:36:51 2011 From: bblackford at gmail.com (Bill Blackford) Date: Thu, 21 Apr 2011 18:36:51 -0700 Subject: gmail dropping mesages In-Reply-To: References: Message-ID: ok, there are some in the spam folder. Hmm, didn't think to look there for the missing ones when my inbox appears to be receivng partial threads. Thanks, -b On Thu, Apr 21, 2011 at 6:31 PM, Christopher Morrow wrote: > On Thu, Apr 21, 2011 at 9:24 PM, Bill Blackford wrote: >> I've recently observed gmail dropping messages or not forwarding all >> messages/posts ?from the nanog list. This is rather annoying. >> >> Has anyone else experienced this? Does anyone have any insight as to why? > > sometimes nanog mail gets marked as spam for me ... I think spam does > not get auto-forwarded. > -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... From jeffrey.lyon at blacklotus.net Thu Apr 21 20:38:11 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 21 Apr 2011 21:38:11 -0400 Subject: 365x24x7 In-Reply-To: <4DB0D3B7.3080900@mompl.net> References: <4DA8AA64.2060403@dcrocker.net> <4DB0D3B7.3080900@mompl.net> Message-ID: On Thu, Apr 21, 2011 at 9:02 PM, Jeroen van Aart wrote: > Bill Stewart wrote: >> >> Rotating shifts between daytime and nighttime is a horrible thing to >> do to your workers, both for their health and their attention span. > > I Fully agree. > > I think it may pay off to search for people who suffer "Delayed sleep phase > syndrome" to do night shift. They'll be happy and you'll actually have > someone who is more awake and alert than the average person at that time of > day. > > http://en.wikipedia.org/wiki/Delayed_sleep_phase_syndrome > > I think the IT world has a more than average incidence of people with this > particular syndrome, at least in my experience. > > Of course in practice you would want to word your vacancy in such a way it > doesn't sound silly. But I think it could be worth it to put an emphasis on > it. > > Greetings, > Jeroen > > -- > http://goldmark.org/jeff/stupid-disclaimers/ > http://linuxmafia.com/~rick/faq/plural-of-virus.html > > I'd just go with "people who really enjoy energy drinks." -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From harry.nanog at harry.lu Thu Apr 21 20:50:59 2011 From: harry.nanog at harry.lu (Harry Strongburg) Date: Fri, 22 Apr 2011 01:50:59 +0000 Subject: Youtube Geolocation In-Reply-To: <20110421213649.GL4718@dan.olp.net> References: <20110421213649.GL4718@dan.olp.net> Message-ID: <20110422015059.GA31811@harry.lu> On Thu, Apr 21, 2011 at 04:36:50PM -0500, Dan White wrote: > We're experiencing very poor quality with You Tube, and it appears we're > subject to a bad entry within a geolocation database somewhere. > > When we attempt to view videos, the contact comes back to us from IPs like: > > 208.117.226.21 (traceroute's through Frankfurt) > 173.194.50.47 > 74.125.100.29 > > All of those IPs are >125ms away from us (67.217.144.0/20, and > 216.14.144.0/20). I had a similar issue, but it was mainly only over IPv6. According to someone I spoke to at Google, bumping up the MTU might help (and did help for me). I don't remember my previous MTU (I think it was 1280), but once I bumped it up to 1480 or so, my packets stopped getting routed to Europe (from NY) and worked properly. Maybe a similar issue could be with their IPv4 routers? Try increasing the MTU. From morrowc.lists at gmail.com Thu Apr 21 20:55:03 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 21 Apr 2011 21:55:03 -0400 Subject: Youtube Geolocation In-Reply-To: <20110422015059.GA31811@harry.lu> References: <20110421213649.GL4718@dan.olp.net> <20110422015059.GA31811@harry.lu> Message-ID: On Thu, Apr 21, 2011 at 9:50 PM, Harry Strongburg wrote: > I had a similar issue, but it was mainly only over IPv6. According to > someone I spoke to at Google, bumping up the MTU might help (and did > help for me). I don't remember my previous MTU (I think it was 1280), > but once I bumped it up to 1480 or so, my packets stopped getting routed > to Europe (from NY) and worked properly. Maybe a similar issue could be > with their IPv4 routers? Try increasing the MTU. how has mtu got anything to do with packet path? -chris From fernattj at gmail.com Thu Apr 21 21:36:38 2011 From: fernattj at gmail.com (Jonathan Fernatt) Date: Thu, 21 Apr 2011 22:36:38 -0400 Subject: riverbed steelhead In-Reply-To: References: Message-ID: On Thu, Apr 21, 2011 at 2:49 PM, harbor235 wrote: > Anyone out there have experience with Riverbed Steelhead products? > Do they improve TCP performance over WAN links? is it worth the price? > > > mike > I've had good experiences with both Riverbed Steelhead and Cisco WAAS products. Both have a very short ROI. I think either are well worth the price. Jon From blakjak at blakjak.net Thu Apr 21 21:48:16 2011 From: blakjak at blakjak.net (Mark Foster) Date: Fri, 22 Apr 2011 14:48:16 +1200 (NZST) Subject: 365x24x7 In-Reply-To: References: <4DA8AA64.2060403@dcrocker.net> <4DB0D3B7.3080900@mompl.net> Message-ID: <7c411111dfabeb1e33d214e0c2ab5f81.squirrel@webmail.blakjak.net> On Fri, April 22, 2011 1:38 pm, Jeffrey Lyon wrote: > On Thu, Apr 21, 2011 at 9:02 PM, Jeroen van Aart wrote: >> Bill Stewart wrote: >>> >>> Rotating shifts between daytime and nighttime is a horrible thing to >>> do to your workers, both for their health and their attention span. >> >> I Fully agree. >> >> I think it may pay off to search for people who suffer "Delayed sleep >> phase >> syndrome" to do night shift. They'll be happy and you'll actually have >> someone who is more awake and alert than the average person at that time >> of >> day. >> >> http://en.wikipedia.org/wiki/Delayed_sleep_phase_syndrome >> >> I think the IT world has a more than average incidence of people with >> this >> particular syndrome, at least in my experience. >> >> Of course in practice you would want to word your vacancy in such a way >> it >> doesn't sound silly. But I think it could be worth it to put an emphasis >> on >> it. >> > > I'd just go with "people who really enjoy energy drinks." Many of you folks actually worked Nightshift for any duration? Most folks I know working in shifts are either IT folks or Emergency Services folks. Both groups recognise the value of actually having conventional working hours, at least for part of the time. Folks on permanent night-shift risk becoming isolated from a good chunk of society and I would expect to see some churn over time. One watch centre I worked with used to run a 3 week rotation of days, 'lates' and 'overnights' which averaged out to 40hrs/week during the course of the year. Another used something similar to the 2days-2nights-4off model I mentioned previously. The remainder split the overnight work into weeknights and weekends, and tended to attract students for the weekend shifts. Mark. From bmanning at vacation.karoshi.com Thu Apr 21 21:51:50 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 22 Apr 2011 02:51:50 +0000 Subject: 365x24x7 In-Reply-To: <7c411111dfabeb1e33d214e0c2ab5f81.squirrel@webmail.blakjak.net> References: <4DA8AA64.2060403@dcrocker.net> <4DB0D3B7.3080900@mompl.net> <7c411111dfabeb1e33d214e0c2ab5f81.squirrel@webmail.blakjak.net> Message-ID: <20110422025150.GA3252@vacation.karoshi.com.> On Fri, Apr 22, 2011 at 02:48:16PM +1200, Mark Foster wrote: > On Fri, April 22, 2011 1:38 pm, Jeffrey Lyon wrote: > > On Thu, Apr 21, 2011 at 9:02 PM, Jeroen van Aart wrote: > >> Bill Stewart wrote: > >>> > >>> Rotating shifts between daytime and nighttime is a horrible thing to > >>> do to your workers, both for their health and their attention span. > >> > >> I Fully agree. > >> > >> I think it may pay off to search for people who suffer "Delayed sleep > >> phase > >> syndrome" to do night shift. They'll be happy and you'll actually have > >> someone who is more awake and alert than the average person at that time > >> of > >> day. > >> > >> http://en.wikipedia.org/wiki/Delayed_sleep_phase_syndrome > >> > >> I think the IT world has a more than average incidence of people with > >> this > >> particular syndrome, at least in my experience. > >> > >> Of course in practice you would want to word your vacancy in such a way > >> it > >> doesn't sound silly. But I think it could be worth it to put an emphasis > >> on > >> it. > >> > > > > I'd just go with "people who really enjoy energy drinks." > > > Many of you folks actually worked Nightshift for any duration? > Most folks I know working in shifts are either IT folks or Emergency > Services folks. Both groups recognise the value of actually having > conventional working hours, at least for part of the time. > Folks on permanent night-shift risk becoming isolated from a good chunk of > society and I would expect to see some churn over time. > > One watch centre I worked with used to run a 3 week rotation of days, > 'lates' and 'overnights' which averaged out to 40hrs/week during the > course of the year. > > Another used something similar to the 2days-2nights-4off model I mentioned > previously. > > The remainder split the overnight work into weeknights and weekends, and > tended to attract students for the weekend shifts. > > Mark. > night/early morning by preference for nearly 20 years.... YMMV. /bill From jeffrey.lyon at blacklotus.net Thu Apr 21 21:53:26 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 21 Apr 2011 22:53:26 -0400 Subject: 365x24x7 In-Reply-To: <20110422025150.GA3252@vacation.karoshi.com.> References: <4DA8AA64.2060403@dcrocker.net> <4DB0D3B7.3080900@mompl.net> <7c411111dfabeb1e33d214e0c2ab5f81.squirrel@webmail.blakjak.net> <20110422025150.GA3252@vacation.karoshi.com.> Message-ID: On Thu, Apr 21, 2011 at 10:51 PM, wrote: > On Fri, Apr 22, 2011 at 02:48:16PM +1200, Mark Foster wrote: >> On Fri, April 22, 2011 1:38 pm, Jeffrey Lyon wrote: >> > On Thu, Apr 21, 2011 at 9:02 PM, Jeroen van Aart wrote: >> >> Bill Stewart wrote: >> >>> >> >>> Rotating shifts between daytime and nighttime is a horrible thing to >> >>> do to your workers, both for their health and their attention span. >> >> >> >> I Fully agree. >> >> >> >> I think it may pay off to search for people who suffer "Delayed sleep >> >> phase >> >> syndrome" to do night shift. They'll be happy and you'll actually have >> >> someone who is more awake and alert than the average person at that time >> >> of >> >> day. >> >> >> >> http://en.wikipedia.org/wiki/Delayed_sleep_phase_syndrome >> >> >> >> I think the IT world has a more than average incidence of people with >> >> this >> >> particular syndrome, at least in my experience. >> >> >> >> Of course in practice you would want to word your vacancy in such a way >> >> it >> >> doesn't sound silly. But I think it could be worth it to put an emphasis >> >> on >> >> it. >> >> >> > >> > I'd just go with "people who really enjoy energy drinks." >> >> >> Many of you folks actually worked Nightshift for any duration? >> Most folks I know working in shifts are either IT folks or Emergency >> Services folks. ?Both groups recognise the value of actually having >> conventional working hours, at least for part of the time. >> Folks on permanent night-shift risk becoming isolated from a good chunk of >> society and I would expect to see some churn over time. >> >> One watch centre I worked with used to run a 3 week rotation of days, >> 'lates' and 'overnights' which averaged out to 40hrs/week during the >> course of the year. >> >> Another used something similar to the 2days-2nights-4off model I mentioned >> previously. >> >> The remainder split the overnight work into weeknights and weekends, and >> tended to attract students for the weekend shifts. >> >> Mark. >> > > ? ? ? ?night/early morning ?by ?preference for nearly 20 years.... > ? ? ? ?YMMV. > > /bill > I've worked night shift as a police officer, 8 x 5. Some of those guys were there for 20+ years and no one seemed to have a serious issue with it. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From frnkblk at iname.com Thu Apr 21 22:23:17 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 21 Apr 2011 22:23:17 -0500 Subject: Voice Peering? In-Reply-To: <00cc01cc0045$afc0e6e0$0f42b4a0$@sberkman.net> References: <00cc01cc0045$afc0e6e0$0f42b4a0$@sberkman.net> Message-ID: <003001cc009c$9f6200c0$de260240$@iname.com> There's also Xconnect. Frank -----Original Message----- From: Scott Berkman [mailto:scott at sberkman.net] Sent: Thursday, April 21, 2011 12:01 PM To: 'Santino Codispoti'; nanog at nanog.org Subject: RE: Voice Peering? It's not specific for mobile, but this is one of the most well know VOIP exchanges: http://www.thevpf.com/ -Scott -----Original Message----- From: Santino Codispoti [mailto:santino.codispoti at gmail.com] Sent: Thursday, April 21, 2011 3:36 AM To: nanog at nanog.org Subject: Voice Peering? I know a few years ago some Vo/IP peering points where started. Are they still around today? I am looking for a solution to hand-off outbound voice calls to mobile operators From harry.nanog at harry.lu Thu Apr 21 23:33:45 2011 From: harry.nanog at harry.lu (Harry Strongburg) Date: Fri, 22 Apr 2011 04:33:45 +0000 Subject: Youtube Geolocation In-Reply-To: References: <20110421213649.GL4718@dan.olp.net> <20110422015059.GA31811@harry.lu> Message-ID: <20110422043345.GA11146@harry.lu> On Thu, Apr 21, 2011 at 09:55:03PM -0400, Christopher Morrow wrote: > how has mtu got anything to do with packet path? PMTUD? From morrowc.lists at gmail.com Fri Apr 22 00:12:35 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 22 Apr 2011 01:12:35 -0400 Subject: Youtube Geolocation In-Reply-To: <20110422043345.GA11146@harry.lu> References: <20110421213649.GL4718@dan.olp.net> <20110422015059.GA31811@harry.lu> <20110422043345.GA11146@harry.lu> Message-ID: On Fri, Apr 22, 2011 at 12:33 AM, Harry Strongburg wrote: > On Thu, Apr 21, 2011 at 09:55:03PM -0400, Christopher Morrow wrote: >> how has mtu got anything to do with packet path? > > PMTUD? that won't change the destination based routed path, it'll cause the endpoints to lower their MTU to a mutually agreeable threshold. The packets will still flow along the same path. (besides pmtud brings the mtu down, not up... the proposal was to raise the mtu) -chris From lists at die.net Fri Apr 22 02:12:04 2011 From: lists at die.net (Aaron Hopkins) Date: Fri, 22 Apr 2011 00:12:04 -0700 (PDT) Subject: Youtube Geolocation In-Reply-To: <20110421213649.GL4718@dan.olp.net> References: <20110421213649.GL4718@dan.olp.net> Message-ID: On Thu, 21 Apr 2011, Dan White wrote: > We're experiencing very poor quality with You Tube, and it appears we're > subject to a bad entry within a geolocation database somewhere. I'm not sure about Youtube, but Google seems to do some some clever but annoying things with correlating requests going through a recursive nameserver with the location of those browsers. If a bunch of browsers in Atlanta use a recursive nameserver in Los Angeles, Google after a while seems to start offering that nameserver Google server IPs close to Atlanta to give back to its clients. This internet draft might be part of a related work: http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-00 > When we attempt to view videos, the contact comes back to us from IPs like: I ran into this problem while running a Tor exit node (which seems to terribly screw with this mechanism) and played with it for a while. I found my nameserver being offered Google server IPs all over the globe; one week it would be London, the next week Germany, then New York, etc. My problem was first solved by changing my browser to use recursive nameservers in a different /24 (changing the last octet didn't seem to help) and later by changing Tor itself to use Google's own 8.8.8.8 nameservers, which caused the problem to go away for other clients of my nameserver. Try using nameservers on a different /24 and see if the problem goes away. -- Aaron From scubacuda at gmail.com Fri Apr 22 08:06:15 2011 From: scubacuda at gmail.com (Rogelio) Date: Fri, 22 Apr 2011 16:06:15 +0300 Subject: best of breed nowadays in DPI space? Message-ID: I have been recently researching DPI for several projects I am working on, and I recently came across this "shoot out" between several vendors in 2009 http://www.internetevolution.com/document.asp?doc_id=178633&page_number=1 Procera (at that time) emerged "the winner" for its ability to process P2P traffic (out of 15 participants), and I was wondering what new players, features, or products others might point me to. I am looking for something that does reporting *and* DPI in a distributed environment. That means, I might have several DPI gateways around the country that need to roll up their reporting into one main one. (I also have some other requirements as far as measuring churn reduction and cellular offloading, but I'm not sure that any of the DPI solutions can really do that well.) If anyone has any good contacts in this space, please let me know and I might discuss with them in more detail these opportunities that I'm looking for. -- Also on LinkedIn?? Feel free to connect if you too are an open networker: scubacuda at gmail.com From scubacuda at gmail.com Fri Apr 22 09:46:13 2011 From: scubacuda at gmail.com (Rogelio) Date: Fri, 22 Apr 2011 17:46:13 +0300 Subject: best of breed nowadays in DPI space? In-Reply-To: References: Message-ID: Those interest in knowing more about the DPI + mobility space (what I'm looking at) might want to check out this Jan 2011 whitepaper. http://www.qosmos.com/resources/whitepapers/new-dpi-challenges-opportunities-lte-era (sorry, sign up required) Not very technical, but a good overview on the subject as it pertains to LTE. -- Also on LinkedIn?? Feel free to connect if you too are an open networker: scubacuda at gmail.com On Fri, Apr 22, 2011 at 4:06 PM, Rogelio wrote: > I have been recently researching DPI for several projects I am working > on, and I recently came across this "shoot out" between several > vendors in 2009 > > http://www.internetevolution.com/document.asp?doc_id=178633&page_number=1 > > Procera (at that time) emerged "the winner" for its ability to process > P2P traffic (out of 15 participants), and I was wondering what new > players, features, or products others might point me to. I am looking > for something that does reporting *and* DPI in a distributed > environment. ?That means, I might have several DPI gateways around the > country that need to roll up their reporting into one main one. ?(I > also have some other requirements as far as measuring churn reduction > and cellular offloading, but I'm not sure that any of the DPI > solutions can really do that well.) > > If anyone has any good contacts in this space, please let me know and > I might discuss with them in more detail these opportunities that I'm > looking for. > > -- > Also on LinkedIn?? Feel free to connect if you too are an open > networker: scubacuda at gmail.com > -- Also on LinkedIn?? Feel free to connect if you too are an open networker: scubacuda at gmail.com From scubacuda at gmail.com Fri Apr 22 10:19:31 2011 From: scubacuda at gmail.com (Rogelio) Date: Fri, 22 Apr 2011 18:19:31 +0300 Subject: best of breed nowadays in DPI space? In-Reply-To: References: Message-ID: ...and of possible interest to those following this thread, here is a PCRF to DPI compatibility matrix. http://broabandtrafficmanagement.blogspot.com/p/pcrf-pcefdpi-compatibility-matrix.html So far, it seems like Sandvine and Bridgewater take the cake when it comes to 3G/4G policy controls (pricy, I'm sure) Sept 2010 PR stuff of their relationship http://www.sys-con.com/node/1550689 On Fri, Apr 22, 2011 at 5:46 PM, Rogelio wrote: > Those interest in knowing more about the DPI + mobility space (what > I'm looking at) might want to check out this Jan 2011 whitepaper. > > http://www.qosmos.com/resources/whitepapers/new-dpi-challenges-opportunities-lte-era > > (sorry, sign up required) > > Not very technical, but a good overview on the subject as it pertains to LTE. > > -- > Also on LinkedIn?? Feel free to connect if you too are an open > networker: scubacuda at gmail.com > > > > On Fri, Apr 22, 2011 at 4:06 PM, Rogelio wrote: >> I have been recently researching DPI for several projects I am working >> on, and I recently came across this "shoot out" between several >> vendors in 2009 >> >> http://www.internetevolution.com/document.asp?doc_id=178633&page_number=1 >> >> Procera (at that time) emerged "the winner" for its ability to process >> P2P traffic (out of 15 participants), and I was wondering what new >> players, features, or products others might point me to. I am looking >> for something that does reporting *and* DPI in a distributed >> environment. ?That means, I might have several DPI gateways around the >> country that need to roll up their reporting into one main one. ?(I >> also have some other requirements as far as measuring churn reduction >> and cellular offloading, but I'm not sure that any of the DPI >> solutions can really do that well.) >> >> If anyone has any good contacts in this space, please let me know and >> I might discuss with them in more detail these opportunities that I'm >> looking for. >> >> -- >> Also on LinkedIn?? Feel free to connect if you too are an open >> networker: scubacuda at gmail.com >> > > > > -- > Also on LinkedIn?? Feel free to connect if you too are an open > networker: scubacuda at gmail.com > -- Also on LinkedIn?? Feel free to connect if you too are an open networker: scubacuda at gmail.com From blake at ispn.net Fri Apr 22 12:24:42 2011 From: blake at ispn.net (Blake Hudson) Date: Fri, 22 Apr 2011 12:24:42 -0500 Subject: VPN over slow Internet connections In-Reply-To: <4DB06184.30508@mube.co.uk> References: <4DB06184.30508@mube.co.uk> Message-ID: <4DB1B9DA.2080507@ispn.net> -------- Original Message -------- Subject: VPN over slow Internet connections From: Ben Whorwood To: nanog at nanog.org Date: Thursday, April 21, 2011 11:55:32 AM > Dear all, > > Can anyone share any thoughts or experiences for VPN links running > over slow Internet connections, typically 2kB/s - 3kB/s (think 33.6k > modem)? > > We are looking into utilising OpenVPN for out-of-office workers who > would be running mobile broadband in rural areas. Typical data across > the wire would be SQL queries for custom applications and not much else. > > Some initial thoughts include... > > * How well would the connection handle certificate (>= 2048 bit key) > based authentication? > * Is UDP or TCP better considering the speed and possibility of > packet loss (no figures to hand)? > * Is VPN over this type of connection simply a bad idea? > > Many thanks in advance. > > Kind regards, > Ben Whorwood > I'm not sure what type of SQL you're using, but MySQL and MS SQL both natively support (and can optionally require) SSL'd connections from clients. --Blake From blake at ispn.net Fri Apr 22 12:33:54 2011 From: blake at ispn.net (Blake Hudson) Date: Fri, 22 Apr 2011 12:33:54 -0500 Subject: Youtube Geolocation In-Reply-To: References: <20110421213649.GL4718@dan.olp.net> Message-ID: <4DB1BC02.8090300@ispn.net> Aaron Hopkins wrote: > > Try using nameservers on a different /24 and see if the problem goes > away. > > -- Aaron > That's a good point. We've worked with Akamai in the past. Their CDN solution works via DNS resolution. If your DNS servers are in Kansas, you'll get the Akamai servers close to Kansas - whether you're there or not. Akamai uses a combination of GeoIP and network operator contributed IP ranges. For example, if you have an Akamai cache on your network, you specifically tell Akamai what IP ranges should be served from that cache - it doesn't seem to matter if these IP addresses belong to you or not. I'm not sure how they deal with overlap. --Blake From cscora at apnic.net Fri Apr 22 13:59:56 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 23 Apr 2011 04:59:56 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201104221859.p3MIxuSS023022@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 23 Apr, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 355581 Prefixes after maximum aggregation: 160822 Deaggregation factor: 2.21 Unique aggregates announced to Internet: 175365 Total ASes present in the Internet Routing Table: 37371 Prefixes per ASN: 9.51 Origin-only ASes present in the Internet Routing Table: 31313 Origin ASes announcing only one prefix: 15071 Transit ASes present in the Internet Routing Table: 5046 Transit-only ASes present in the Internet Routing Table: 135 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 36 Max AS path prepend of ASN (36992) 29 Prefixes from unregistered ASNs in the Routing Table: 564 Unregistered ASNs in the Routing Table: 275 Number of 32-bit ASNs allocated by the RIRs: 1309 Number of 32-bit ASNs visible in the Routing Table: 1012 Prefixes from 32-bit ASNs in the Routing Table: 2274 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 161 Number of addresses announced to Internet: 2418199616 Equivalent to 144 /8s, 34 /16s and 204 /24s Percentage of available address space announced: 65.2 Percentage of allocated address space announced: 65.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 90.5 Total number of prefixes smaller than registry allocations: 147668 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 88888 Total APNIC prefixes after maximum aggregation: 29965 APNIC Deaggregation factor: 2.97 Prefixes being announced from the APNIC address blocks: 85376 Unique aggregates announced from the APNIC address blocks: 36841 APNIC Region origin ASes present in the Internet Routing Table: 4419 APNIC Prefixes per ASN: 19.32 APNIC Region origin ASes announcing only one prefix: 1226 APNIC Region transit ASes present in the Internet Routing Table: 700 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 22 Number of APNIC region 32-bit ASNs visible in the Routing Table: 48 Number of APNIC addresses announced to Internet: 610706464 Equivalent to 36 /8s, 102 /16s and 164 /24s Percentage of available APNIC address space announced: 77.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 140032 Total ARIN prefixes after maximum aggregation: 71172 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 112430 Unique aggregates announced from the ARIN address blocks: 45157 ARIN Region origin ASes present in the Internet Routing Table: 14334 ARIN Prefixes per ASN: 7.84 ARIN Region origin ASes announcing only one prefix: 5473 ARIN Region transit ASes present in the Internet Routing Table: 1492 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 11 Number of ARIN addresses announced to Internet: 798645760 Equivalent to 47 /8s, 154 /16s and 94 /24s Percentage of available ARIN address space announced: 63.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 84022 Total RIPE prefixes after maximum aggregation: 47852 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 77130 Unique aggregates announced from the RIPE address blocks: 51011 RIPE Region origin ASes present in the Internet Routing Table: 15538 RIPE Prefixes per ASN: 4.96 RIPE Region origin ASes announcing only one prefix: 7807 RIPE Region transit ASes present in the Internet Routing Table: 2435 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 749 Number of RIPE addresses announced to Internet: 466814464 Equivalent to 27 /8s, 211 /16s and 6 /24s Percentage of available RIPE address space announced: 75.2 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 32482 Total LACNIC prefixes after maximum aggregation: 7448 LACNIC Deaggregation factor: 4.36 Prefixes being announced from the LACNIC address blocks: 31486 Unique aggregates announced from the LACNIC address blocks: 16475 LACNIC Region origin ASes present in the Internet Routing Table: 1439 LACNIC Prefixes per ASN: 21.88 LACNIC Region origin ASes announcing only one prefix: 432 LACNIC Region transit ASes present in the Internet Routing Table: 261 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 199 Number of LACNIC addresses announced to Internet: 82681984 Equivalent to 4 /8s, 237 /16s and 160 /24s Percentage of available LACNIC address space announced: 54.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7658 Total AfriNIC prefixes after maximum aggregation: 1822 AfriNIC Deaggregation factor: 4.20 Prefixes being announced from the AfriNIC address blocks: 6067 Unique aggregates announced from the AfriNIC address blocks: 1881 AfriNIC Region origin ASes present in the Internet Routing Table: 441 AfriNIC Prefixes per ASN: 13.76 AfriNIC Region origin ASes announcing only one prefix: 133 AfriNIC Region transit ASes present in the Internet Routing Table: 95 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 31 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 5 Number of AfriNIC addresses announced to Internet: 23300352 Equivalent to 1 /8s, 99 /16s and 137 /24s Percentage of available AfriNIC address space announced: 34.7 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2430 9482 904 Korea Telecom (KIX) 17974 1798 515 29 PT TELEKOMUNIKASI INDONESIA 7545 1549 300 81 TPG Internet Pty Ltd 4755 1454 634 167 TATA Communications formerly 7552 1195 1064 7 Vietel Corporation 24560 1140 323 204 Bharti Airtel Ltd., Telemedia 9583 1054 77 495 Sify Limited 4808 1030 2097 293 CNCGROUP IP network: China169 9829 1008 870 50 BSNL National Internet Backbo 17488 942 164 98 Hathway IP Over Cable Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3652 3822 255 bellsouth.net, inc. 4323 2649 1090 398 Time Warner Telecom 1785 1789 681 128 PaeTec Communications, Inc. 18566 1760 349 229 Covad Communications 6478 1636 309 43 AT&T Worldnet Services 20115 1535 1552 638 Charter Communications 19262 1495 4949 298 Verizon Global Networks 7018 1357 6801 886 AT&T WorldNet Services 22773 1299 2865 84 Cox Communications, Inc. 2386 1270 536 912 AT&T Data Communications Serv Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6830 519 1780 321 UPC Distribution Services 34984 508 106 182 BILISIM TELEKOM 3292 455 1997 391 TDC Tele Danmark 29049 450 33 48 AzerSat LLC. 8866 446 134 26 Bulgarian Telecommunication C 20940 439 129 335 Akamai Technologies European 3320 423 7609 368 Deutsche Telekom AG 12479 409 577 6 Uni2 Autonomous System 8551 405 354 47 Bezeq International 702 396 1802 309 UUNET - Commercial IP service Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1437 268 160 TVCABLE BOGOTA 28573 1281 988 87 NET Servicos de Comunicao S.A 8151 1248 2688 369 UniNet S.A. de C.V. 7303 927 467 149 Telecom Argentina Stet-France 6503 907 354 72 AVANTEL, S.A. 14420 663 53 91 CORPORACION NACIONAL DE TELEC 22047 565 310 15 VTR PUNTO NET S.A. 3816 516 225 98 Empresa Nacional de Telecomun 11172 488 99 82 Servicios Alestra S.A de C.V 27947 483 53 53 Telconet S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 836 445 11 TEDATA 24863 778 147 39 LINKdotNET AS number 15475 422 90 8 Nile Online 36992 297 415 13 Etisalat MISR 3741 267 985 227 The Internet Solution 6713 238 215 13 Itissalat Al-MAGHRIB 33776 227 13 5 Starcomms Nigeria Limited 24835 209 78 10 RAYA Telecom - Egypt 29571 161 17 11 Ci Telecom Autonomous system 16637 148 441 86 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3652 3822 255 bellsouth.net, inc. 4323 2649 1090 398 Time Warner Telecom 4766 2430 9482 904 Korea Telecom (KIX) 23456 2274 652 1233 32-bit ASN transition 17974 1798 515 29 PT TELEKOMUNIKASI INDONESIA 1785 1789 681 128 PaeTec Communications, Inc. 18566 1760 349 229 Covad Communications 6478 1636 309 43 AT&T Worldnet Services 7545 1549 300 81 TPG Internet Pty Ltd 20115 1535 1552 638 Charter Communications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2649 2251 Time Warner Telecom 17974 1798 1769 PT TELEKOMUNIKASI INDONESIA 1785 1789 1661 PaeTec Communications, Inc. 6478 1636 1593 AT&T Worldnet Services 18566 1760 1531 Covad Communications 4766 2430 1526 Korea Telecom (KIX) 7545 1549 1468 TPG Internet Pty Ltd 4755 1454 1287 TATA Communications formerly 10620 1437 1277 TVCABLE BOGOTA 11492 1254 1239 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 31.192.112.0/20 30361 Swiftwill Solutions 31.192.128.0/19 31214 TIS-DIALOG Autonomous system 31.192.232.0/23 47271 CJSC "Uralunicom" 31.192.232.0/22 47271 CJSC "Uralunicom" Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:12 /10:28 /11:77 /12:221 /13:458 /14:786 /15:1379 /16:11668 /17:5741 /18:9624 /19:19173 /20:25618 /21:25611 /22:33775 /23:32642 /24:185589 /25:1120 /26:1285 /27:700 /28:38 /29:8 /30:2 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2253 3652 bellsouth.net, inc. 18566 1728 1760 Covad Communications 6478 1590 1636 AT&T Worldnet Services 4323 1346 2649 Time Warner Telecom 10620 1327 1437 TVCABLE BOGOTA 11492 1203 1254 Cable One 23456 1146 2274 32-bit ASN transition 7011 1062 1161 Citizens Utilities 1785 1059 1789 PaeTec Communications, Inc. 22773 843 1299 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:262 2:43 4:14 5:1 6:1 8:347 12:2010 13:1 14:441 15:15 16:3 17:8 20:9 23:5 24:1605 27:722 31:209 32:60 33:3 34:2 37:1 38:764 40:101 41:2400 42:3 44:3 46:866 47:4 49:177 50:365 52:13 55:3 56:2 57:31 58:846 59:478 60:387 61:1268 62:984 63:1919 64:3934 65:2326 66:4353 67:1856 68:1081 69:2977 70:700 71:345 72:1904 73:1 74:2349 75:297 76:335 77:844 78:676 79:452 80:1098 81:829 82:500 83:461 84:647 85:1082 86:559 87:760 88:332 89:1581 90:183 91:3709 92:514 93:1058 94:1260 95:787 96:466 97:251 98:823 99:35 101:63 103:5 106:1 107:5 108:84 109:932 110:550 111:695 112:325 113:361 114:523 115:683 116:949 117:674 118:800 119:1147 120:301 121:672 122:1626 123:1071 124:1250 125:1268 128:265 129:164 130:172 131:566 132:113 133:19 134:217 135:49 136:214 137:142 138:301 139:104 140:486 141:174 142:398 143:397 144:485 145:52 146:441 147:207 148:578 149:233 150:170 151:187 152:307 153:179 154:3 155:395 156:191 157:353 158:132 159:382 160:316 161:243 162:277 163:165 164:487 165:350 166:511 167:426 168:719 169:153 170:784 171:77 172:1 173:1502 174:531 175:359 177:79 178:853 180:821 181:9 182:428 183:201 184:252 185:1 186:1140 187:802 188:985 189:1004 190:4846 192:5792 193:4829 194:3457 195:2964 196:1166 197:16 198:3564 199:3920 200:5522 201:1493 202:8351 203:8446 204:4136 205:2329 206:2745 207:3029 208:3964 209:3505 210:2726 211:1382 212:1973 213:1712 214:744 215:67 216:4879 217:1657 218:561 219:374 220:1195 221:483 222:341 223:143 End of report From george at montco.net Fri Apr 22 14:08:39 2011 From: george at montco.net (George Carey) Date: Fri, 22 Apr 2011 15:08:39 -0400 Subject: Looking for XO routing engineer Message-ID: <4DB1D237.2040908@montco.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Can someone from XO please contact me about this hijacked prefix: 72.44.152.0/24 I see it coming from AS35909 through AS2828. No luck getting anyone on the phone. Thanks George Carey -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) iEYEARECAAYFAk2x0jcACgkQJdlqYKAmD6FO2gCeJd6uToUghlKdjNd38JpAP2VZ SnwAoLQbpi9ygjIkCPDCU6TrnPOFc98r =OkTz -----END PGP SIGNATURE----- From ryan.finnesey at HarrierInvestments.com Fri Apr 22 15:26:16 2011 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Fri, 22 Apr 2011 13:26:16 -0700 Subject: Voice Peering? In-Reply-To: References: <5CC7D3ED-41F7-4305-9688-45D1BDFAB270@A2B-Internet.com><4DAFF19C.4090701@signet.nl> Message-ID: <6EFFEFBAC68377459A2E972105C759EC03892DA0@EXVBE005-2.exch005intermedia.net> Do you need to be a mobile operator to join an IPX/GRX? I know EQUINIX operates I think two IPXs but I do not know witch mobile operator are passing traffic. We are working on a project witch 100% of the outbound voice traffic is going to go to mobiles. There will also be a large volume of SMS/MMS traffic. It would be very useful to "peer" with the mobile operators. Cheers Ryan -----Original Message----- From: Cameron Byrne [mailto:cb.list6 at gmail.com] Sent: Thursday, April 21, 2011 10:24 AM To: Remco Bressers Cc: nanog at nanog.org Subject: Re: Voice Peering? On Apr 21, 2011 1:59 AM, "Remco Bressers" wrote: > > I also thought GRX peering was only data and sms. > There's a SIP peering point on the NL-IX though. Grx is data only. IPX in theory does voice too but I don't think the take rate is very high. Cb > Look at http://www.nl-ix.net/solutions/voice-peering/ for more. > > Regards, > > Remco Bressers > Signet B.V. > AS28878 > > > On 04/21/2011 10:52 AM, Santino Codispoti wrote: > > Thank you I will look into AMS-IX. I was thinking the GRX platforms > > where for SMS and Data only. > > > > On Thu, Apr 21, 2011 at 4:45 AM, Erik Bais wrote: > >> Hi Santino, > >> > >> Did you had a look at AMS-IX ? They have a grx offering for that. > >> > >> Regards, > >> Erik Bais > >> A2B Internet > >> > >> Verstuurd vanaf mijn iPad > >> > >> Op Apr 21, 2011 om 9:35 heeft Santino Codispoti < santino.codispoti at gmail.com> het volgende geschreven: > >> > >>> I know a few years ago some Vo/IP peering points where started. Are > >>> they still around today? I am looking for a solution to hand-off > >>> outbound voice calls to mobile operators > >>> > >> > > > > From fmartin at linkedin.com Fri Apr 22 15:44:59 2011 From: fmartin at linkedin.com (Franck Martin) Date: Fri, 22 Apr 2011 20:44:59 +0000 Subject: gmail dropping mesages In-Reply-To: Message-ID: What is the DKIM check result for those messages? May be time to get nanog mailing list DKIM aware? On 4/22/11 13:24 , "Bill Blackford" wrote: >I've recently observed gmail dropping messages or not forwarding all >messages/posts from the nanog list. This is rather annoying. > >Has anyone else experienced this? Does anyone have any insight as to why? > >Thanks, From cidr-report at potaroo.net Fri Apr 22 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 Apr 2011 22:00:00 GMT Subject: BGP Update Report Message-ID: <201104222200.p3MM00lM020718@wattle.apnic.net> BGP Update Report Interval: 14-Apr-11 -to- 21-Apr-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS19743 31254 1.4% 4464.9 -- 2 - AS9829 20367 0.9% 20.2 -- BSNL-NIB National Internet Backbone 3 - AS17974 19362 0.9% 10.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 4 - AS11492 19099 0.9% 15.0 -- CABLEONE - CABLE ONE, INC. 5 - AS16586 17967 0.8% 58.0 -- CLEARWIRE - Clearwire US LLC 6 - AS32528 17918 0.8% 2239.8 -- ABBOTT Abbot Labs 7 - AS6389 15224 0.7% 4.2 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 8 - AS35931 13544 0.6% 2257.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 9 - AS44609 12775 0.6% 4258.3 -- FNA Fars News Agency Cultural Arts Institute 10 - AS8452 12329 0.6% 14.6 -- TE-AS TE-AS 11 - AS14420 12223 0.6% 18.4 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 12 - AS45595 11814 0.6% 32.5 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 13 - AS20115 11671 0.5% 7.4 -- CHARTER-NET-HKY-NC - Charter Communications 14 - AS7491 11527 0.5% 125.3 -- PI-PH-AS-AP PI-PHILIPINES 15 - AS7545 11205 0.5% 8.3 -- TPG-INTERNET-AP TPG Internet Pty Ltd 16 - AS4323 10876 0.5% 4.1 -- TWTC - tw telecom holdings, inc. 17 - AS8151 10834 0.5% 8.6 -- Uninet S.A. de C.V. 18 - AS28573 10339 0.5% 6.6 -- NET Servicos de Comunicao S.A. 19 - AS17224 9487 0.4% 169.4 -- ATT-CERFNET-BLOCK - AT&T Enhanced Network Services 20 - AS27738 9133 0.4% 26.9 -- Ecuadortelecom S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS19743 31254 1.4% 4464.9 -- 2 - AS44609 12775 0.6% 4258.3 -- FNA Fars News Agency Cultural Arts Institute 3 - AS35931 13544 0.6% 2257.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - AS32528 17918 0.8% 2239.8 -- ABBOTT Abbot Labs 5 - AS49600 1519 0.1% 1519.0 -- LASEDA La Seda de Barcelona, S.A 6 - AS52280 1442 0.1% 1442.0 -- INTERNEXA Chile S.A. 7 - AS32949 1434 0.1% 717.0 -- UNITED-REFRIGERATION - UNITED REFRIGERATION INC 8 - AS20132 874 0.0% 437.0 -- DSC-AS - Dundee Securities Corporation 9 - AS3 408 0.0% 735.0 -- SL-NET-ASN SL-NET s.c. 10 - AS50364 403 0.0% 403.0 -- INPRIME InPrime Ltd 11 - AS48349 395 0.0% 395.0 -- SICE-IT-AS JSC "Siberian Interbank Currency Exchange - Information Technologies" 12 - AS52000 761 0.0% 380.5 -- ALDAN-3-AS LTD "ALDAN-3" 13 - AS11843 700 0.0% 350.0 -- BARNES - Barnes Distribution 14 - AS52126 337 0.0% 337.0 -- IXTERM-AS ixTerm Ltd. 15 - AS46167 325 0.0% 325.0 -- LANDSERVICESUSA - Land Services USA, Inc 16 - AS33362 3680 0.2% 306.7 -- WIKTEL-NET - Wikstrom Telephone Company, Incorporated 17 - AS38757 569 0.0% 284.5 -- ICONPLN-ID-AP PT. Indonesia Comnets Plus 18 - AS31662 569 0.0% 284.5 -- KNSURSELVA aurax connecta AG 19 - AS36059 284 0.0% 284.0 -- MEDMANAGEMENT-LLC - MedManagement, LLC 20 - AS45310 267 0.0% 267.0 -- PISHON-SMARTNET-AS-ID SMARTNET - Broadband Internet Service. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 221.121.96.0/19 9147 0.4% AS7491 -- PI-PH-AS-AP PI-PHILIPINES 2 - 130.36.34.0/24 8943 0.3% AS32528 -- ABBOTT Abbot Labs 3 - 130.36.35.0/24 8943 0.3% AS32528 -- ABBOTT Abbot Labs 4 - 63.211.68.0/22 7754 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - 178.22.72.0/21 6429 0.2% AS44609 -- FNA Fars News Agency Cultural Arts Institute 6 - 178.22.79.0/24 6326 0.2% AS44609 -- FNA Fars News Agency Cultural Arts Institute 7 - 65.122.196.0/24 6261 0.2% AS19743 -- 8 - 198.140.43.0/24 5352 0.2% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 9 - 72.164.144.0/24 5001 0.2% AS19743 -- 10 - 65.162.204.0/24 4999 0.2% AS19743 -- 11 - 66.238.91.0/24 4997 0.2% AS19743 -- 12 - 65.163.182.0/24 4996 0.2% AS19743 -- 13 - 66.89.98.0/24 4996 0.2% AS19743 -- 14 - 202.92.235.0/24 3908 0.1% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 15 - 68.65.152.0/22 3673 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 16 - 202.153.174.0/24 3518 0.1% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 17 - 213.55.75.0/24 2790 0.1% AS24757 -- EthioNet-AS 18 - 213.55.74.0/24 2788 0.1% AS24757 -- EthioNet-AS 19 - 208.54.82.0/24 2734 0.1% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 20 - 213.55.64.0/24 2521 0.1% AS24757 -- EthioNet-AS Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Apr 22 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 Apr 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201104222200.p3MM009q020712@wattle.apnic.net> This report has been generated at Fri Apr 22 21:12:05 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 15-04-11 357492 209863 16-04-11 357568 209705 17-04-11 356846 210150 18-04-11 357824 210186 19-04-11 358136 210366 20-04-11 358373 210576 21-04-11 358318 210619 22-04-11 358888 210705 AS Summary 37468 Number of ASes in routing system 15788 Number of ASes announcing only one prefix 3651 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 110418432 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 22Apr11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 358798 210633 148165 41.3% All ASes AS6389 3651 260 3391 92.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2641 402 2239 84.8% TWTC - tw telecom holdings, inc. AS4766 2430 915 1515 62.3% KIXS-AS-KR Korea Telecom AS6478 1636 214 1422 86.9% ATT-INTERNET3 - AT&T Services, Inc. AS22773 1299 93 1206 92.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS19262 1495 298 1197 80.1% VZGNI-TRANSIT - Verizon Online LLC AS18566 1760 662 1098 62.4% COVAD - Covad Communications Co. AS10620 1437 347 1090 75.9% Telmex Colombia S.A. AS4755 1454 365 1089 74.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1792 764 1028 57.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1281 337 944 73.7% NET Servicos de Comunicao S.A. AS7552 1037 117 920 88.7% VIETEL-AS-AP Vietel Corporation AS7545 1552 758 794 51.2% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 934 151 783 83.8% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8151 1245 529 716 57.5% Uninet S.A. de C.V. AS4808 1034 332 702 67.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS3356 1145 476 669 58.4% LEVEL3 Level 3 Communications AS7303 927 264 663 71.5% Telecom Argentina S.A. AS11492 1256 597 659 52.5% CABLEONE - CABLE ONE, INC. AS17488 942 300 642 68.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS6503 908 280 628 69.2% Axtel, S.A.B. de C.V. AS17676 658 70 588 89.4% GIGAINFRA Softbank BB Corp. AS24560 1140 560 580 50.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS855 632 56 576 91.1% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS14420 663 104 559 84.3% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS3549 944 394 550 58.3% GBLX Global Crossing Ltd. AS22047 565 30 535 94.7% VTR BANDA ANCHA S.A. AS4780 718 188 530 73.8% SEEDNET Digital United Inc. AS22561 863 340 523 60.6% DIGITAL-TELEPORT - Digital Teleport Inc. AS4804 576 82 494 85.8% MPX-AS Microplex PTY LTD Total 38615 10285 28330 73.4% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 24.48.0.0/14 AS5769 VIDEOTRON - Videotron Telecom Ltee 24.225.128.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/23 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.224.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.237.0/24 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.248.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 45.127.0.0/16 AS13767 DBANK - DataBank Holdings, Ltd. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS16626 GNAXNET-AS - Global Net Access, LLC 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 181.82.15.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.16.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.17.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 181.82.18.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.145.251.0/24 AS10026 PACNET Pacnet Global Ltd 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.33.84.0/22 AS9911 CONNECTPLUS-AP Singapore Telecom 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.73.0/24 AS26061 Equant Colombia 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 203.190.32.0/22 AS24564 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.64.240.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.241.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.242.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.243.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.244.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.247.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.105.192.0/23 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.105.196.0/23 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.105.200.0/21 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From askoorb+nanog at gmail.com Fri Apr 22 17:41:41 2011 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Fri, 22 Apr 2011 23:41:41 +0100 Subject: gmail dropping mesages In-Reply-To: References: Message-ID: On Fri, Apr 22, 2011 at 9:44 PM, Franck Martin wrote: > What is the DKIM check result for those messages? Non existent, it's SPF only. This is what GMail sees: Received: from s0.nanog.org (s0.nanog.org [207.75.116.162]) by mx.google.com with ESMTPS id h1si7255610ibn.43.2011.04.22.13.42.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2011 13:42:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of nanog-bounces+askoorb+nanog=gmail.com at nanog.org designates 207.75.116.162 as permitted sender) client-ip=207.75.116.162; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of nanog-bounces+askoorb+nanog=gmail.com at nanog.org designates 207.75.116.162 as permitted sender) smtp.mail=nanog-bounces+askoorb+nanog=gmail.com at nanog.org > > May be time to get nanog mailing list DKIM aware? > > On 4/22/11 13:24 , "Bill Blackford" wrote: > >>I've recently observed gmail dropping messages or not forwarding all >>messages/posts ?from the nanog list. This is rather annoying. >> >>Has anyone else experienced this? Does anyone have any insight as to why? Yes, for example, the message I'm replying to had this at the top of it: "Due to a filter you created, this message was not sent to Spam. Edit Filters" "Warning: This message may not be from whom it claims to be. Beware of following any links in it or of providing the sender with any personal information. Learn more" So GMail thinks it's a phishing message :-/ Quite a lot of my Nanog messages are marked as spam, which is why I created a filter to not send any messages with a list ID header with nanog.nanog.org in it to spam at all. The only way for Nanog to get round this would be for the mail administrator to follow *every* step at https://mail.google.com/support/bin/answer.py?answer=81126 which basically is: - Explicit SPF with hard fail. - Signing with DKIM or DomainKeys. - Useing a consistent IP address to send bulk mail. - Keeping valid reverse DNS records for the IP address(es) from which mail is sent, pointing to the sending domain. - Use the same address in the 'From:' header on every bulk mail that is sent. - Using the "Precedence: bulk" header. - Up-to-date contact information in the WHOIS record, and on abuse.net. But the list administrator would have to do all of that faff. Alex From fmartin at linkedin.com Fri Apr 22 18:01:01 2011 From: fmartin at linkedin.com (Franck Martin) Date: Fri, 22 Apr 2011 23:01:01 +0000 Subject: gmail dropping mesages In-Reply-To: Message-ID: On 4/23/11 10:41 , "Alex Brooks" wrote: >On Fri, Apr 22, 2011 at 9:44 PM, Franck Martin >wrote: >> What is the DKIM check result for those messages? > >Non existent, it's SPF only. My point. > >This is what GMail sees: > >Received: from s0.nanog.org (s0.nanog.org [207.75.116.162]) > by mx.google.com with ESMTPS id >h1si7255610ibn.43.2011.04.22.13.42.53 > (version=TLSv1/SSLv3 cipher=OTHER); > Fri, 22 Apr 2011 13:42:53 -0700 (PDT) >Received-SPF: pass (google.com: best guess record for domain of >nanog-bounces+askoorb+nanog=gmail.com at nanog.org designates >207.75.116.162 as permitted sender) client-ip=207.75.116.162; >Authentication-Results: mx.google.com; spf=pass (google.com: best >guess record for domain of >nanog-bounces+askoorb+nanog=gmail.com at nanog.org designates >207.75.116.162 as permitted sender) >smtp.mail=nanog-bounces+askoorb+nanog=gmail.com at nanog.org > >> >> May be time to get nanog mailing list DKIM aware? >> >> On 4/22/11 13:24 , "Bill Blackford" wrote: >> >>>I've recently observed gmail dropping messages or not forwarding all >>>messages/posts from the nanog list. This is rather annoying. >>> >>>Has anyone else experienced this? Does anyone have any insight as to >>>why? > >Yes, for example, the message I'm replying to had this at the top of it: > >"Due to a filter you created, this message was not sent to Spam. Edit >Filters" >"Warning: This message may not be from whom it claims to be. Beware of >following any links in it or of providing the sender with any personal >information. Learn more" > >So GMail thinks it's a phishing message :-/ Because from: may be from a domain which is known to DKIM sign everything.... (like gmail). > >Quite a lot of my Nanog messages are marked as spam, which is why I >created a filter to not send any messages with a list ID header with >nanog.nanog.org in it to spam at all. > >The only way for Nanog to get round this would be for the mail >administrator to follow *every* step at >https://mail.google.com/support/bin/answer.py?answer=81126 which >basically is: >- Explicit SPF with hard fail. >- Signing with DKIM or DomainKeys. >- Useing a consistent IP address to send bulk mail. >- Keeping valid reverse DNS records for the IP address(es) from which >mail is sent, pointing to the sending domain. >- Use the same address in the 'From:' header on every bulk mail that is >sent. >- Using the "Precedence: bulk" header. >- Up-to-date contact information in the WHOIS record, and on abuse.net. > >But the list administrator would have to do all of that faff. No, it is mailman, just upgrade mailman. Recent versions are more DKIM aware... More info: http://tools.ietf.org/html/draft-ietf-dkim-mailinglists-06 From shrdlu at deaddrop.org Fri Apr 22 18:24:28 2011 From: shrdlu at deaddrop.org (Lynda) Date: Fri, 22 Apr 2011 16:24:28 -0700 Subject: gmail dropping mesages In-Reply-To: References: Message-ID: <4DB20E2C.1040903@deaddrop.org> On 4/22/2011 4:01 PM, Franck Martin wrote: > > On 4/23/11 10:41 , "Alex Brooks" wrote: > >> On Fri, Apr 22, 2011 at 9:44 PM, Franck Martin >> wrote: >>> What is the DKIM check result for those messages? >> >> Non existent, it's SPF only. > > My point. Nearly all of the spam I see is DKIM signed. It just makes messages bigger. I'd just as soon our volunteers spend their times on other things, myself. -- "The person becomes vulnerable to all manner of fads, such as astrology, superstitions, economics, and tarot-card reading." The Black Swan, by Nassim Nicholas Taleb From william.allen.simpson at gmail.com Fri Apr 22 23:26:46 2011 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sat, 23 Apr 2011 00:26:46 -0400 Subject: gmail dropping mesages In-Reply-To: References: Message-ID: <4DB25506.6000008@gmail.com> On 4/21/11 9:24 PM, Bill Blackford wrote: > I've recently observed gmail dropping messages or not forwarding all > messages/posts from the nanog list. This is rather annoying. > > Has anyone else experienced this? Does anyone have any insight as to why? > I've read the thread, and ironically all messages from Franck Martin in this thread were sent to spam by gmail. None of the others! This is like an earlier thread: -------- Previous Message -------- Subject: Re: sudden low spam levels? Date: Tue, 04 Jan 2011 10:10:24 -0500 From: William Allen Simpson To: nanog at nanog.org On 1/3/11 6:42 PM, Jay Farrell wrote: > I noticed a substantial drop in spam in my gmail account in recent days, > from several hundred a day to maybe a hundred. Ironically, gmail filtered > this thread to my spam folder. > Yes, I found these messages my gmail spam today, too. Lately, gmail has been regularly flagging NANOG as spam, particularly the end of week CIDR and BGP reports. From scubacuda at gmail.com Sat Apr 23 06:45:32 2011 From: scubacuda at gmail.com (Rogelio) Date: Sat, 23 Apr 2011 14:45:32 +0300 Subject: "supporting IPv6" <--- what it means exactly? Message-ID: <77FA13A2-5291-46D8-B6F0-6B7821E1710F@gmail.com> Is there any clear understanding of what "supporting IPv6" means? I recently was told by a vendor that they "supported IPv6", and then when I went to go configure an IPv6 address, it was, of course, IPv4. I asked how they supported that, and they said that they "supported it" because they could "pass IPv6" traffic. Well...duh! From askoorb+nanog at gmail.com Sat Apr 23 06:46:55 2011 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Sat, 23 Apr 2011 12:46:55 +0100 Subject: Voice Peering? In-Reply-To: References: Message-ID: On Thu, Apr 21, 2011 at 8:35 AM, Santino Codispoti wrote: > I know a few years ago some Vo/IP peering points where started. ?Are > they still around today? ? I am looking for a solution to hand-off > outbound voice calls to mobile operators While not specifically answering your question, as this thread has had quite a few responses, I thought that I'd point everyone towards The VOIP Operators' Group at http://www.voiceops.org/ They're an excellent resource for anything to do with moving sounds around the intertubes. Anybody who has a VOIP setup or is thinking of getting one really should subscribe. HTH From leigh.porter at ukbroadband.com Sat Apr 23 07:09:09 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Sat, 23 Apr 2011 13:09:09 +0100 Subject: "supporting IPv6" <--- what it means exactly? In-Reply-To: <77FA13A2-5291-46D8-B6F0-6B7821E1710F@gmail.com> References: <77FA13A2-5291-46D8-B6F0-6B7821E1710F@gmail.com> Message-ID: >Is there any clear understanding of what "supporting IPv6" means? >I recently was told by a vendor that they "supported IPv6", and then when I went >to go configure an IPv6 address, it was, of course, IPv4. I asked how they >supported that, and they said that they "supported it" because they could "pass >IPv6" traffic. >Well...duh! Yeah this seems to be a common problem. Vendors who have equipment that does not support a full IPv6 feature set comparable to the IPv4 functionality usually do the "it'll pass Ipv6" in which case my 10Mb/s hub from 1996 is IPv6 ready... Then there are vendors who offer a good IPv6 feature set but who only have IPv4 for the management. Some DPI vendors spring to mind for this. So.. caveat emptor! -- Leigh Porter UK Broadband ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From jcurran at istaff.org Sat Apr 23 07:48:21 2011 From: jcurran at istaff.org (John Curran) Date: Sat, 23 Apr 2011 08:48:21 -0400 Subject: "supporting IPv6" <--- what it means exactly? In-Reply-To: <77FA13A2-5291-46D8-B6F0-6B7821E1710F@gmail.com> References: <77FA13A2-5291-46D8-B6F0-6B7821E1710F@gmail.com> Message-ID: On Apr 23, 2011, at 7:45 AM, Rogelio wrote: > Is there any clear understanding of what "supporting IPv6" means? If you actually want to know what they do or don't support, you could ask the vendor for a "Supplier's Declaration of Conformity" (SDOC) to the US Government IPv4 profile - That profile may not include the particular features that you are most interested in, but it's probably a good start to building your own list. /John From randy at psg.com Sat Apr 23 09:12:19 2011 From: randy at psg.com (Randy Bush) Date: Sat, 23 Apr 2011 23:12:19 +0900 Subject: "supporting IPv6" <--- what it means exactly? In-Reply-To: <77FA13A2-5291-46D8-B6F0-6B7821E1710F@gmail.com> References: <77FA13A2-5291-46D8-B6F0-6B7821E1710F@gmail.com> Message-ID: i think jan zorz, over in slovenia has developed a good check list with the gang there which is being used more and more generally in the ripe region. randy From jared at puck.nether.net Sat Apr 23 09:14:27 2011 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 23 Apr 2011 10:14:27 -0400 Subject: "supporting IPv6" <--- what it means exactly? In-Reply-To: <77FA13A2-5291-46D8-B6F0-6B7821E1710F@gmail.com> References: <77FA13A2-5291-46D8-B6F0-6B7821E1710F@gmail.com> Message-ID: <8911B796-62CC-4A97-BFAF-A9CD0E68DC39@puck.nether.net> On Apr 23, 2011, at 7:45 AM, Rogelio wrote: > Is there any clear understanding of what "supporting IPv6" means? > > I recently was told by a vendor that they "supported IPv6", and then when I went to go configure an IPv6 address, it was, of course, IPv4. I asked how they supported that, and they said that they "supported it" because they could "pass IPv6" traffic. Look for things like: * IPv6 NDP support (RA, ND, NS, etc) * IPv6 native transport to the control-plane + in-band management * Support for IPv6 on bundled interfaces (with RA, ND, NS working) These are the types of things you need to look for. Some of these items depend on what your use case is. Some places you may want to talk about RA-Guard, others may not matter as much. Same for DHCPv6. I don't need this in my core network, but at the edge it's possibly important depending on the device(s). - Jared From jkrejci at usinternet.com Sat Apr 23 09:25:08 2011 From: jkrejci at usinternet.com (jkrejci at usinternet.com) Date: Sat, 23 Apr 2011 14:25:08 +0000 Subject: "supporting IPv6" <--- what it means exactly? Message-ID: <752386293-1303568709-cardhu_decombobulator_blackberry.rim.net-1644612336-@bda2106.bisx.prod.on.blackberry> http://www.ipv6ready.org/?page=phase-2-about You can check phase1 as well. There is a pretty good searchable table of certified ipv6 there as well. Feel free to buy these products and even let the vendor know you chose their product over others because of their ipv6 support which was clearly identifiable. ------Original Message------ From: Jared Mauch To: Rogelio Cc: nanog at nanog.org Subject: Re: "supporting IPv6" <--- what it means exactly? Sent: Apr 23, 2011 9:14 AM On Apr 23, 2011, at 7:45 AM, Rogelio wrote: > Is there any clear understanding of what "supporting IPv6" means? > > I recently was told by a vendor that they "supported IPv6", and then when I went to go configure an IPv6 address, it was, of course, IPv4. I asked how they supported that, and they said that they "supported it" because they could "pass IPv6" traffic. Look for things like: * IPv6 NDP support (RA, ND, NS, etc) * IPv6 native transport to the control-plane + in-band management * Support for IPv6 on bundled interfaces (with RA, ND, NS working) These are the types of things you need to look for. Some of these items depend on what your use case is. Some places you may want to talk about RA-Guard, others may not matter as much. Same for DHCPv6. I don't need this in my core network, but at the edge it's possibly important depending on the device(s). - Jared Sent via BlackBerry from T-Mobile From jmamodio at gmail.com Sat Apr 23 09:49:27 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 23 Apr 2011 09:49:27 -0500 Subject: "supporting IPv6" <--- what it means exactly? In-Reply-To: <8911B796-62CC-4A97-BFAF-A9CD0E68DC39@puck.nether.net> References: <77FA13A2-5291-46D8-B6F0-6B7821E1710F@gmail.com> <8911B796-62CC-4A97-BFAF-A9CD0E68DC39@puck.nether.net> Message-ID: >> Is there any clear understanding of what "supporting IPv6" means? Telling some words of encouragement to your consumer grade home broadband router that barely does IPv4 right ? -J From joelja at bogus.com Sat Apr 23 12:53:40 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 23 Apr 2011 10:53:40 -0700 Subject: "supporting IPv6" <--- what it means exactly? In-Reply-To: <77FA13A2-5291-46D8-B6F0-6B7821E1710F@gmail.com> References: <77FA13A2-5291-46D8-B6F0-6B7821E1710F@gmail.com> Message-ID: <4DB31224.6050705@bogus.com> there's a organization out there that has a logo compliance exercise... http://www.ipv6forum.com/ it's not perfect. when dealing with a vendor as with ipv4 there's generally a list of protocols and features you are looking to have support for, if these are encapsulated in RFCs they're fairly easy to point the finger as and say "do you support that ->" On 4/23/11 4:45 AM, Rogelio wrote: > Is there any clear understanding of what "supporting IPv6" means? > > I recently was told by a vendor that they "supported IPv6", and then when I went to go configure an IPv6 address, it was, of course, IPv4. I asked how they supported that, and they said that they "supported it" because they could "pass IPv6" traffic. > > Well...duh! > > > From toasty at dragondata.com Sat Apr 23 13:09:33 2011 From: toasty at dragondata.com (Kevin Day) Date: Sat, 23 Apr 2011 13:09:33 -0500 Subject: World of Warcraft may begin using IPv6 on Tuesday Message-ID: For those that don't know, World of Warcraft is currently the largest online role playing game, with somewhere over 12 million subscribers. Version 4.1 of the game is expected to be released this Tuesday, which will be automatically pushed to all clients. The current Beta version of 4.1 has full IPv6 support. In the beta, it's automatically enabled if you have native IPv6 (non-6to4, non-Teredo). While Blizzard has been pretty silent about this, barring a last minute revert or delay of this patch, there are suddenly going to be a bunch more users that can potentially use IPv6. And these users are the type who are going to be especially sensitive to latency, jitter and packet loss, since this is a real-time game platform. For those of you with Help Desks who have to support users like this, the associated setting in the game's Options menu is apparently called "Enable IPv6 when available". It's apparently grayed out if you do not have IPv6 at all, unchecked by default if you are on 6to4 or Teredo, and checked by default if you are on native v6. The tooltip says: "Enables the use of IPv6, the technology behind the next-generation Internet. Requires IPv6 connectivity to the internet. Checking this box without IPv6 connectivity may prevent you from playing WoW." Anyone from Activision/Blizzard who would like to chime in with more details? :) -- Kevin From dave at temk.in Sat Apr 23 16:56:34 2011 From: dave at temk.in (Dave Temkin) Date: Sat, 23 Apr 2011 17:56:34 -0400 Subject: RES: Anyone still maintaining altdb.net? In-Reply-To: <00b101cbff82$5c7a9580$156fc080$@com.br> References: <7FE72FAB-94EB-4C6E-860B-C92260608A7B@getjive.com> <00b101cbff82$5c7a9580$156fc080$@com.br> Message-ID: <4DB34B12.2040409@temk.in> On 4/20/11 1:42 PM, Eduardo Schoedler wrote: > On Wed, 20 Apr 2011, Bret Palsson wrote: >> I submitted my objects April 11. the mtrner object needs to be created >> by the db-admin. I realize this is a volunteer thing. Could I help out >> or could the people that are helping out look at adding my record? I >> need to setup some peering relationships. I'd prefer to support open >> communities rather than paying and am willing to help out if need be. > Bret, > > You can try the SCW IRR [1]. > It's free, but is in Portuguese. > > Reference: > [1] http://whois.scw.net.br/ > > -- > Eduardo Schoedler Sounds like that doesn't help the OP, who wanted help with RPSL, not *really* help from AltDB. -Dave From rubensk at gmail.com Sat Apr 23 17:06:47 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Sat, 23 Apr 2011 19:06:47 -0300 Subject: RES: Anyone still maintaining altdb.net? In-Reply-To: <4DB34B12.2040409@temk.in> References: <7FE72FAB-94EB-4C6E-860B-C92260608A7B@getjive.com> <00b101cbff82$5c7a9580$156fc080$@com.br> <4DB34B12.2040409@temk.in> Message-ID: >> You can try the SCW IRR [1]. >> It's free, but is in Portuguese. >> >> Reference: >> [1] http://whois.scw.net.br/ >> >> -- >> Eduardo Schoedler > > Sounds like that doesn't help the OP, who wanted help with RPSL, not > *really* help from AltDB. Actually it does, because of a wizard (http://irr.scw.net.br/new) to generate IRR objects based on currently announced routes. Rubens From dave at temk.in Sat Apr 23 17:22:16 2011 From: dave at temk.in (Dave Temkin) Date: Sat, 23 Apr 2011 18:22:16 -0400 Subject: RES: Anyone still maintaining altdb.net? In-Reply-To: References: <7FE72FAB-94EB-4C6E-860B-C92260608A7B@getjive.com> <00b101cbff82$5c7a9580$156fc080$@com.br> <4DB34B12.2040409@temk.in> Message-ID: <4DB35118.6020005@temk.in> On 4/23/11 6:06 PM, Rubens Kuhl wrote: >>> You can try the SCW IRR [1]. >>> It's free, but is in Portuguese. >>> >>> Reference: >>> [1] http://whois.scw.net.br/ >>> >>> -- >>> Eduardo Schoedler >> Sounds like that doesn't help the OP, who wanted help with RPSL, not >> *really* help from AltDB. > Actually it does, because of a wizard (http://irr.scw.net.br/new) to > generate IRR objects based on currently announced routes. > > > Rubens > Not overly helpful without a native English translation. Sure, I could pass it through Google Translate and get a great result like: "Through it just tell the ASN and its authenticity (an email will be sent to registered contacts in the RIR and / or NIR), in minutes, without any human interference and without any technical complication" and have all the forms be useless (they end up redirecting to themselves) And as douchey as this is going to sound: If you can't be bothered to take 15 minutes to learn RPSL (it's really that easy) I'm afraid for the future of our routing table. -Dave From randy at psg.com Sat Apr 23 17:25:57 2011 From: randy at psg.com (Randy Bush) Date: Sun, 24 Apr 2011 07:25:57 +0900 Subject: "supporting IPv6" <--- what it means exactly? In-Reply-To: <77FA13A2-5291-46D8-B6F0-6B7821E1710F@gmail.com> References: <77FA13A2-5291-46D8-B6F0-6B7821E1710F@gmail.com> Message-ID: > Is there any clear understanding of what "supporting IPv6" means? ripe-501 may be helpful, jan zorz's docco enshrined in ripeness and overwebification. http://www.ripe.net/ripe/docs/ripe-501 randy From tom at ninjabadger.net Sat Apr 23 17:29:49 2011 From: tom at ninjabadger.net (Tom Hill) Date: Sat, 23 Apr 2011 23:29:49 +0100 Subject: World of Warcraft may begin using IPv6 on Tuesday In-Reply-To: References: Message-ID: <1303597789.1965.0.camel@teh-desktop> On Sat, 2011-04-23 at 13:09 -0500, Kevin Day wrote: > For those that don't know, World of Warcraft is currently the largest online role playing game, with somewhere over 12 million subscribers. > > Version 4.1 of the game is expected to be released this Tuesday, which will be automatically pushed to all clients. The current Beta version of 4.1 has full IPv6 support. In the beta, it's automatically enabled if you have native IPv6 (non-6to4, non-Teredo). While Blizzard has been pretty silent about this, barring a last minute revert or delay of this patch, there are suddenly going to be a bunch more users that can potentially use IPv6. And these users are the type who are going to be especially sensitive to latency, jitter and packet loss, since this is a real-time game platform. > > For those of you with Help Desks who have to support users like this, the associated setting in the game's Options menu is apparently called "Enable IPv6 when available". It's apparently grayed out if you do not have IPv6 at all, unchecked by default if you are on 6to4 or Teredo, and checked by default if you are on native v6. The tooltip says: "Enables the use of IPv6, the technology behind the next-generation Internet. Requires IPv6 connectivity to the internet. Checking this box without IPv6 connectivity may prevent you from playing WoW." > > Anyone from Activision/Blizzard who would like to chime in with more details? :) I can't say that I'm from Blizzard, but I'm *seriously* impressed by them for making this happen. Kudos to Blizzard! Tom From fmartin at linkedin.com Sat Apr 23 19:32:19 2011 From: fmartin at linkedin.com (Franck Martin) Date: Sun, 24 Apr 2011 00:32:19 +0000 Subject: gmail dropping mesages In-Reply-To: <4DB20E2C.1040903@deaddrop.org> Message-ID: On 4/23/11 11:24 , "Lynda" wrote: >On 4/22/2011 4:01 PM, Franck Martin wrote: >> >> On 4/23/11 10:41 , "Alex Brooks" wrote: >> >>> On Fri, Apr 22, 2011 at 9:44 PM, Franck Martin >>> wrote: >>>> What is the DKIM check result for those messages? >>> >>> Non existent, it's SPF only. >> >> My point. > >Nearly all of the spam I see is DKIM signed. It just makes messages >bigger. I'd just as soon our volunteers spend their times on other >things, myself. It is like IPv6, it just makes packets bigger... From joe at gonetforward.com Sat Apr 23 19:45:00 2011 From: joe at gonetforward.com (Joe Renwick) Date: Sat, 23 Apr 2011 17:45:00 -0700 Subject: Cisco Firewall ASP Drop Message-ID: So my firewall seems to be dropping an oddly large number of packets on the INSIDE interface: asa1(config)# sh int RACK Interface GigabitEthernet0/1 "RACK", is up, line protocol is up Hardware is i82546GB rev03, BW 1000 Mbps Auto-Duplex(Full-duplex), Auto-Speed(1000 Mbps) MAC address 0024.14d0.4521, MTU 1500 IP address 64.22.76.97, subnet mask 255.255.255.240 28128158809 packets input, 162066888025865 bytes, 4 no buffer Received 186502879 broadcasts, 0 runts, 0 giants 5089 input errors, 0 CRC, 0 frame, 5089 overrun, 0 ignored, 0 abort 0 L2 decode drops 27235942172 packets output, 18181322825213 bytes, 237 underruns 0 output errors, 0 collisions, 0 interface resets 0 late collisions, 0 deferred 0 input reset drops, 0 output reset drops input queue (curr/max packets): hardware (1/33) output queue (curr/max packets): hardware (0/511) Traffic Statistics for "RACK": 144406450470 packets input, 159422361828279 bytes 103754084999 packets output, 16098663171295 bytes 6934615576 packets dropped 1 minute input rate 2056 pkts/sec, 2053935 bytes/sec 1 minute output rate 1678 pkts/sec, 418581 bytes/sec 1 minute drop rate, 270 pkts/sec 5 minute input rate 2519 pkts/sec, 2676286 bytes/sec 5 minute output rate 1887 pkts/sec, 469578 bytes/sec 5 minute drop rate, 283 pkts/sec Looking at ASP drop data they are most coming from "TCP packet SEQ past window (tcp-seq-past-win)": asa1(config)# sh asp drop Frame drop: Invalid TCP Length (invalid-tcp-hdr-length) 31 No valid adjacency (no-adjacency) 88 No route to host (no-route) 1728 Flow is denied by configured rule (acl-drop) 203110 Flow denied due to resource limitation (unable-to-create-flow) 556419 First TCP packet not SYN (tcp-not-syn) 4080584 Bad TCP flags (bad-tcp-flags) 38 Bad option length in TCP (tcp-bad-option-len) 54 TCP data exceeded MSS (tcp-mss-exceeded) 910 TCP failed 3 way handshake (tcp-3whs-failed) 724043 TCP RST/FIN out of order (tcp-rstfin-ooo) 21011574 TCP SEQ in SYN/SYNACK invalid (tcp-seq-syn-diff) 19758 TCP SYNACK on established conn (tcp-synack-ooo) 6 TCP packet SEQ past window (tcp-seq-past-win) 156938345 TCP invalid ACK (tcp-invalid-ack) 15360 TCP ACK in 3 way handshake invalid (tcp-discarded-ooo) 9 TCP Out-of-Order packet buffer full (tcp-buffer-full) 41 TCP Out-of-Order packet buffer timeout (tcp-buffer-timeout) 343 TCP RST/SYN in window (tcp-rst-syn-in-win) 13323 TCP DUP and has been ACKed (tcp-acked) 379384 TCP packet failed PAWS test (tcp-paws-fail) 84304 IP option drop (invalid-ip-option) 12 ICMP Error Inspect no existing conn (inspect-icmp-error-no-existing-conn) 16 DNS Inspect invalid packet (inspect-dns-invalid-pak) 53 DNS Inspect invalid domain label (inspect-dns-invalid-domain-label) 50 DNS Inspect packet too long (inspect-dns-pak-too-long) 5353783 DNS Inspect id not matched (inspect-dns-id-not-matched) 5275 Anybody seen this before? Would be nice to see if there is a command to show offending packets but I cannot seem to find it. Thanks for the time. Cheers, -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD! Direct: 619-800-2055, Emergency Support: 800-719-0504 Is your network moving you forward? From nick at foobar.org Sun Apr 24 05:16:25 2011 From: nick at foobar.org (Nick Hilliard) Date: Sun, 24 Apr 2011 11:16:25 +0100 Subject: RES: Anyone still maintaining altdb.net? In-Reply-To: <4DB35118.6020005@temk.in> References: <7FE72FAB-94EB-4C6E-860B-C92260608A7B@getjive.com> <00b101cbff82$5c7a9580$156fc080$@com.br> <4DB34B12.2040409@temk.in> <4DB35118.6020005@temk.in> Message-ID: <4DB3F879.7060705@foobar.org> On 23/04/2011 23:22, Dave Temkin wrote: > And as douchey as this is going to sound: If you can't be bothered to > take 15 minutes to learn RPSL (it's really that easy) basic rpsl is pretty noddy, but it gets very hairy very quickly. I'd say 15 minutes leaves 20 seconds for each page of rfc2622. Should be more than enough for anyone. Nick From gbonser at seven.com Sun Apr 24 10:17:14 2011 From: gbonser at seven.com (George Bonser) Date: Sun, 24 Apr 2011 08:17:14 -0700 Subject: "supporting IPv6" <--- what it means exactly? In-Reply-To: <77FA13A2-5291-46D8-B6F0-6B7821E1710F@gmail.com> References: <77FA13A2-5291-46D8-B6F0-6B7821E1710F@gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E2F09@RWC-EX1.corp.seven.com> > From: Rogelio > Sent: Saturday, April 23, 2011 4:46 AM > To: nanog at nanog.org > Subject: "supporting IPv6" <--- what it means exactly? > > Is there any clear understanding of what "supporting IPv6" means? > > I recently was told by a vendor that they "supported IPv6", and then > when I went to go configure an IPv6 address, it was, of course, IPv4. I > asked how they supported that, and they said that they "supported it" > because they could "pass IPv6" traffic. > > Well...duh! > I recently ran into a case where the device can be programmed with an IPv6 address, will use v6 for management, etc. (you can use the v6 IP for SNMP and login and stuff), but it won't route v6 even with static routes (not even in using CPU). It will switch v6 traffic, though. From tjc at ecs.soton.ac.uk Sun Apr 24 10:54:35 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Sun, 24 Apr 2011 16:54:35 +0100 Subject: World of Warcraft may begin using IPv6 on Tuesday In-Reply-To: <1303597789.1965.0.camel@teh-desktop> References: <1303597789.1965.0.camel@teh-desktop> Message-ID: On 23 Apr 2011, at 23:29, Tom Hill wrote: > On Sat, 2011-04-23 at 13:09 -0500, Kevin Day wrote: >> For those that don't know, World of Warcraft is currently the largest online role playing game, with somewhere over 12 million subscribers. >> >> Version 4.1 of the game is expected to be released this Tuesday, which will be automatically pushed to all clients. The current Beta version of 4.1 has full IPv6 support. In the beta, it's automatically enabled if you have native IPv6 (non-6to4, non-Teredo). While Blizzard has been pretty silent about this, barring a last minute revert or delay of this patch, there are suddenly going to be a bunch more users that can potentially use IPv6. And these users are the type who are going to be especially sensitive to latency, jitter and packet loss, since this is a real-time game platform. >> >> For those of you with Help Desks who have to support users like this, the associated setting in the game's Options menu is apparently called "Enable IPv6 when available". It's apparently grayed out if you do not have IPv6 at all, unchecked by default if you are on 6to4 or Teredo, and checked by default if you are on native v6. The tooltip says: "Enables the use of IPv6, the technology behind the next-generation Internet. Requires IPv6 connectivity to the internet. Checking this box without IPv6 connectivity may prevent you from playing WoW." >> >> Anyone from Activision/Blizzard who would like to chime in with more details? :) > > I can't say that I'm from Blizzard, but I'm *seriously* impressed by > them for making this happen. Kudos to Blizzard! Confirmed in patch notes: http://us.battle.net/wow/en/game/patch-notes/ptr-patch-notes Tim From cb.list6 at gmail.com Sun Apr 24 11:40:39 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 24 Apr 2011 09:40:39 -0700 Subject: "supporting IPv6" <--- what it means exactly? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E2F09@RWC-EX1.corp.seven.com> References: <77FA13A2-5291-46D8-B6F0-6B7821E1710F@gmail.com> <5A6D953473350C4B9995546AFE9939EE0C9E2F09@RWC-EX1.corp.seven.com> Message-ID: This may be helpful from a cpe perspective http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-09 From trelane at trelane.net Sun Apr 24 22:49:51 2011 From: trelane at trelane.net (Andrew Kirch) Date: Sun, 24 Apr 2011 23:49:51 -0400 Subject: SIXXS contact Message-ID: <4DB4EF5F.4000000@trelane.net> would someone at SIXXS please contact me off-list regarding an account issue? From raymond at prolocation.net Mon Apr 25 03:07:13 2011 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Mon, 25 Apr 2011 10:07:13 +0200 (CEST) Subject: SIXXS contact In-Reply-To: <4DB4EF5F.4000000@trelane.net> References: <4DB4EF5F.4000000@trelane.net> Message-ID: Hi! > would someone at SIXXS please contact me off-list regarding an account > issue? Contact The main contact address for SixXS is info at sixxs.net, which is the sole email address one should use to contact SixXS. Non-English, impolite, clueless, UCE and HTML email gets discarded automatically. The official language used is English, due to archiving issues and the international effort put into SixXS. And you naturally trued that one before sending here, right? Bye, Raymond. From me at payam124.com Mon Apr 25 05:47:18 2011 From: me at payam124.com (Payam Poursaied) Date: Mon, 25 Apr 2011 15:17:18 +0430 Subject: Outage Management/Log Book Message-ID: <0cf501cc0336$265bf5e0$7313e1a0$@com> Hi all May I have your recommendation regarding any outage management software and NOC log book(preferably open source) . I want to get fresh ideas about available software in this area. The below scenario may explain what I am looking for: One of the sites gets down, monitoring team would log it. Technical staffs follow it, they find there is something wrong in the site. Someone gets to the site and find there is a power failure. Make it correct. Monitoring team again see that site UP and update their log book put the recovery time and the reason (i.e. power failure) One of the simplest report from this system would be downtime per site/per reason. The ability to record group outage - manually or automatically based on network topology - (i.e. failure of a core router in a city which would be caused several sites failure) would be also useful. Best Regards Payam Poursaied -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5605 bytes Desc: not available URL: From fmartin at linkedin.com Mon Apr 25 07:14:44 2011 From: fmartin at linkedin.com (Franck Martin) Date: Mon, 25 Apr 2011 12:14:44 +0000 Subject: Outage Management/Log Book In-Reply-To: <0cf501cc0336$265bf5e0$7313e1a0$@com> Message-ID: Zabbix allows to acknowledge events with a comment. On 4/25/11 22:47 , "Payam Poursaied" wrote: >Hi all >May I have your recommendation regarding any outage management software >and NOC log book(preferably open source) . >I want to get fresh ideas about available software in this area. > >The below scenario may explain what I am looking for: >One of the sites gets down, monitoring team would log it. Technical >staffs follow it, they find there is something wrong >in the site. Someone gets to the site and find there is a power failure. >Make it correct. Monitoring team again see that >site UP and update their log book put the recovery time and the reason >(i.e. power failure) >One of the simplest report from this system would be downtime per >site/per reason. > >The ability to record group outage - manually or automatically based on >network topology - (i.e. failure of a core >router in a city which would be caused several sites failure) would be >also useful. > >Best Regards >Payam Poursaied > > From dredd at megacity.org Mon Apr 25 07:47:38 2011 From: dredd at megacity.org (Derek J. Balling) Date: Mon, 25 Apr 2011 08:47:38 -0400 Subject: World of Warcraft may begin using IPv6 on Tuesday In-Reply-To: References: Message-ID: On Apr 23, 2011, at 2:09 PM, Kevin Day wrote: > In the beta, it's automatically enabled if you have native IPv6 (non-6to4, non-Teredo). > [...] > For those of you with Help Desks who have to support users like this, the associated setting in the game's Options menu is apparently called "Enable IPv6 when available". It's apparently grayed out if you do not have IPv6 at all, unchecked by default if you are on 6to4 or Teredo, and checked by default if you are on native v6. The tooltip says: "Enables the use of IPv6, the technology behind the next-generation Internet. Requires IPv6 connectivity to the internet. Checking this box without IPv6 connectivity may prevent you from playing WoW." The PTR notes don't seem to indicate that it will be enabled by default in any way when it goes live (it may be behaving as you describe specifically for data-gathering purposes in PTR, but it doesn't look like they intend to do that in live): http://us.battle.net/wow/en/game/patch-notes/ptr-patch-notes > The Network category contains the options "Optimize network for speed" and "Enable IPv6 when available". "Optimize network for speed" will be enabled by default, and will send packets more frequently at the cost of higher bandwidth. The higher bandwidth may lead to disconnects for some players who have limited bandwidth. Players getting disconnected frequently should try unchecking this box. That call-out to the "optimize network" being enabled by default, with no such reference to the IPv6, leads me to believe that it'll be "proactive only" in the short-term. Probably until they see what the wider impact and problems are from non-PTR folks who test it out. D From nccariaga at stluke.com.ph Mon Apr 25 09:15:40 2011 From: nccariaga at stluke.com.ph (Nathanael Cariaga) Date: Mon, 25 Apr 2011 22:15:40 +0800 Subject: Outage Management/Log Book In-Reply-To: <0cf501cc0336$265bf5e0$7313e1a0$@com> References: <0cf501cc0336$265bf5e0$7313e1a0$@com> Message-ID: <1951D25F-7EE6-44F0-915D-78CC7D21ABAC@stluke.com.ph> Have you tried otrs? On Apr 25, 2011, at 6:47 PM, "Payam Poursaied" wrote: > Hi all > May I have your recommendation regarding any outage management software and NOC log book(preferably open source) . > I want to get fresh ideas about available software in this area. > > The below scenario may explain what I am looking for: > One of the sites gets down, monitoring team would log it. Technical staffs follow it, they find there is something wrong > in the site. Someone gets to the site and find there is a power failure. Make it correct. Monitoring team again see that > site UP and update their log book put the recovery time and the reason (i.e. power failure) > One of the simplest report from this system would be downtime per site/per reason. > > The ability to record group outage - manually or automatically based on network topology - (i.e. failure of a core > router in a city which would be caused several sites failure) would be also useful. > > Best Regards > Payam Poursaied > > From trelane at trelane.net Mon Apr 25 11:53:26 2011 From: trelane at trelane.net (Andrew Kirch) Date: Mon, 25 Apr 2011 12:53:26 -0400 Subject: SIXXS contact In-Reply-To: References: <4DB4EF5F.4000000@trelane.net> Message-ID: <4DB5A706.7000503@trelane.net> On 4/25/2011 4:07 AM, Raymond Dijkxhoorn wrote: > Hi! > >> would someone at SIXXS please contact me off-list regarding an account >> issue? > > Contact > The main contact address for SixXS is info at sixxs.net, which is the > sole email address one should use to contact SixXS. Non-English, > impolite, clueless, UCE and HTML email gets discarded automatically. > The official language used is English, due to archiving issues and the > international effort put into SixXS. > > And you naturally trued that one before sending here, right? > > Bye, > Raymond. > Yes, repeatedly. The response was non-existent, or simply unfortunate, so I'm trying other avenues. Andrew From jmitchell at ll.mit.edu Mon Apr 25 12:12:08 2011 From: jmitchell at ll.mit.edu (Jeff Mitchell) Date: Mon, 25 Apr 2011 13:12:08 -0400 Subject: gmail dropping mesages In-Reply-To: <4DB20E2C.1040903@deaddrop.org> References: <4DB20E2C.1040903@deaddrop.org> Message-ID: <4DB5AB68.1030406@ll.mit.edu> On 04/22/2011 07:24 PM, Lynda wrote: >>> Non existent, it's SPF only. >> >> My point. > > Nearly all of the spam I see is DKIM signed. It just makes messages > bigger. I'd just as soon our volunteers spend their times on other > things, myself. DKIM isn't designed explicitly to stop spam, it's designed to identify senders. If you trust the issued certificates(!) being used to sign the mail, you at least have a good indication that the spam is coming from the domain that it says it's coming from. This can make spam blocking much more effective because instead of simply hoping that a domain-based blocklist will block spam and not ham (due to spoofed sender addresses), you have a pretty good feeling that this will be the case. Of course this relies on various other bits and pieces to fall into place, such as properly handling such messages (Gmail's detection and handling rules aren't public AFAIK), CAs not being compromised, etc. Not to mention that the spammers can simply register another domain and buy a new cert -- but then the argument above still holds. --Jeff From dhc2 at dcrocker.net Mon Apr 25 12:21:02 2011 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Mon, 25 Apr 2011 10:21:02 -0700 Subject: gmail dropping mesages In-Reply-To: <4DB20E2C.1040903@deaddrop.org> References: <4DB20E2C.1040903@deaddrop.org> Message-ID: <4DB5AD7E.7040806@dcrocker.net> On 4/22/2011 4:24 PM, Lynda wrote: > Nearly all of the spam I see is DKIM signed. It just makes messages bigger. > I'd just as soon our volunteers spend their times on other things, myself. In the off-chance you are assuming that the presence of a DKIM signature is supposed to mean something about the quality of a message, please note that it isn't. It is only meant to supply a reliable, valid identifier, with which assessments can then be made. That assessment step is where the fun happens. See: For reference, spammers are typically early adopters of newly security standardized mechanisms, in the (demonstrably valid) belief that some folk confuse identification with quality assurance. In particular, the DKIM d= identifier is primarily helpful for avoiding false positives. That is, it is for an assessment process targeting signers you trust, rather more than for targeting those you don't. If you don't care about the trust side of the filtering equation, I suspect DKIM will not be all that helpful for you. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nderitualex at gmail.com Mon Apr 25 12:25:32 2011 From: nderitualex at gmail.com (Alex Nderitu) Date: Mon, 25 Apr 2011 20:25:32 +0300 Subject: Outage Management/Log Book In-Reply-To: <1951D25F-7EE6-44F0-915D-78CC7D21ABAC@stluke.com.ph> References: <0cf501cc0336$265bf5e0$7313e1a0$@com> <1951D25F-7EE6-44F0-915D-78CC7D21ABAC@stluke.com.ph> Message-ID: Or RT-IR Regards, Alex On 4/25/11, Nathanael Cariaga wrote: > Have you tried otrs? > > > > On Apr 25, 2011, at 6:47 PM, "Payam Poursaied" wrote: > >> Hi all >> May I have your recommendation regarding any outage management software >> and NOC log book(preferably open source) . >> I want to get fresh ideas about available software in this area. >> >> The below scenario may explain what I am looking for: >> One of the sites gets down, monitoring team would log it. Technical staffs >> follow it, they find there is something wrong >> in the site. Someone gets to the site and find there is a power failure. >> Make it correct. Monitoring team again see that >> site UP and update their log book put the recovery time and the reason >> (i.e. power failure) >> One of the simplest report from this system would be downtime per site/per >> reason. >> >> The ability to record group outage - manually or automatically based on >> network topology - (i.e. failure of a core >> router in a city which would be caused several sites failure) would be >> also useful. >> >> Best Regards >> Payam Poursaied >> >> > > -- Sent from my mobile device From me at payam124.com Mon Apr 25 12:30:25 2011 From: me at payam124.com (Payam Poursaied) Date: Mon, 25 Apr 2011 22:00:25 +0430 Subject: Outage Management/Log Book In-Reply-To: <1951D25F-7EE6-44F0-915D-78CC7D21ABAC@stluke.com.ph> References: <0cf501cc0336$265bf5e0$7313e1a0$@com> <1951D25F-7EE6-44F0-915D-78CC7D21ABAC@stluke.com.ph> Message-ID: Hi Otrs seems to be a ticketing system. We are using RT (bestpractical) as our ticketing system and our monitoring guys use RT to issue a trouble ticket to our maintenance team. Sometimes something happened by our upstream provider and for example in less than 7 minutes resolved. In all cases monitoring staff log the start time, type of failure and resolved time in thei log-book. Later they tried to put these data including the affected sites and it would be used to create mane reports regarding sites uptime. S I'm looking for an application with very easy and handy interface to simulate their log book for outages. I can create some custom fields in our RT to maintain these data, but there are some problems: 1- not all of the incidents are recorded in our ticketing system, because they should be followed by someone out of our system 2- some problems may get resolved in a few minutes, I.e. By. Phone call. So, creating a ticket may not make sense. 3- the interface of RT is not good enough to be used as a fast log-book system for our outage On Monday, April 25, 2011, Nathanael Cariaga wrote: > Have you tried otrs? > > > > On Apr 25, 2011, at 6:47 PM, "Payam Poursaied" wrote: > >> Hi all >> May I have your recommendation ?regarding any outage management software and NOC log book(preferably open source) . >> I want to get fresh ideas about available software in this area. >> >> The below scenario may explain what I am looking for: >> One of the sites gets down, monitoring team would log it. Technical staffs follow it, they find there is something wrong >> in the site. Someone gets to the site and find there is a power failure. Make it correct. Monitoring team again see that >> site UP and update their log book put the recovery time and the reason (i.e. power failure) >> One of the simplest report from this system would be downtime per site/per reason. >> >> The ability to record group outage - manually or automatically based on network topology - (i.e. failure of a core >> router in a city which would be caused several sites failure) would be also useful. >> >> Best Regards >> Payam Poursaied >> >> > From khomyakov.andrey at gmail.com Mon Apr 25 12:55:15 2011 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Mon, 25 Apr 2011 13:55:15 -0400 Subject: riverbed steelhead In-Reply-To: References: Message-ID: I personally would take Riverbed over Cisco for one main reason that I have discovered when I was researching them (that was good 3-4 years ago and cisco may have "improved" since). Cisco "accelerates" based on application. That is to say if it's not a well known application protocol, they do not do anything with it. So, they are probably good for HTTP/FTP/Samba etc. Riverbed does not care for applications (they still support application based acceleration, but they also support non standard stuff). They take something along the lines of data hashes and store them (along with data of course). They just store raw bytes as opposed to a let's say a file. That played out well when I had to make a decision about which brand to purchase for the company that had a homegrown application. So in a nutshell, Riverbed improved performance of that application (as well as all the standard players like HTTP/FTP etc), while cicso said outright that they won't. After purchase, we saw a dramatic improvement in "user experience" (basically the complaints stopped) from our EU site that was accessing windows (samba) based file servers in USA. Those guys at the time were connected to the US office over MLPPP (4 T1s). Samba sucked for them along with everything else. The only issue I had with Riverbed is their licensing model feels very backwards. It took me a while to understand what we needed. Andrey On Thu, Apr 21, 2011 at 10:36 PM, Jonathan Fernatt wrote: > On Thu, Apr 21, 2011 at 2:49 PM, harbor235 wrote: > > > Anyone out there have experience with Riverbed Steelhead products? > > Do they improve TCP performance over WAN links? is it worth the price? > > > > > > mike > > > > I've had good experiences with both Riverbed Steelhead and Cisco WAAS > products. Both have a very short ROI. I think either are well worth the > price. > > Jon > -- Andrey Khomyakov [khomyakov.andrey at gmail.com] From jmkeller at houseofzen.org Mon Apr 25 14:30:16 2011 From: jmkeller at houseofzen.org (James Michael Keller) Date: Mon, 25 Apr 2011 15:30:16 -0400 Subject: riverbed steelhead In-Reply-To: References: Message-ID: <4DB5CBC8.2050004@houseofzen.org> On 04/25/2011 01:55 PM, Andrey Khomyakov wrote: > I personally would take Riverbed over Cisco for one main reason that I have > discovered when I was researching them (that was good 3-4 years ago and > cisco may have "improved" since). > Yes, they have improved dramatically in the last few years since the 4.x release. > Cisco "accelerates" based on application. That is to say if it's not a well > known application protocol, they do not do anything with it. > So, they are probably good for HTTP/FTP/Samba etc. > > Riverbed does not care for applications (they still support application > based acceleration, but they also support non standard stuff). They take > something along the lines of data hashes and store them (along with data of > course). They just store raw bytes as opposed to a let's say a file. That > played out well when I had to make a decision about which brand to purchase > for the company that had a homegrown application. So in a nutshell, Riverbed > improved performance of that application (as well as all the standard > players like HTTP/FTP etc), while cicso said outright that they won't. > The current gen of WAAS works this way as well. The accelerators are configurable for defined services along with a default profile. There are several accelerators that are applied to each connection, starting with the most basic TCP session optimization for window sizes and other per packet modifications. It then applies raw data optimizations such as the raw 'bit' database you mentioned, each WAE will attempt to find the largest unique run of bits and create a hash for that sequence and store it in it's local database which decays based on time and hit count. If both WAE's in the path have this hash that is all that needs to be sent, otherwise it sends the entire payload, which will then be cached on the second WAE going forward for repeat occurrences (cache expiration not withstanding...). It can also do LZ compression on the full payload when it needs to send it. After that there are application protocol accelerators for common protocols like CIFS, HTTP, etc. These work on the session level and act as transparent proxies for the protocols and can include file cache's on the WAE. For other protocols like MS Video live streams, it can turn a uni-cast session from multiple clients into a single session up to the video server instead of multiple connections from each client. You also have the option with these to push server certificates and private keys into the WAAS system with the Central Manager, which allows transparent SSL/TLS acceleration for internal applications along with encrypted local storage on the WAEs. As an example, we had a commercial patch deployment system that would bog down on patch days or large updates like services packs. After the WAEs went in it improved a bit but was still a huge tax on the network even with sites that had local deployment servers for this application. After digging through the application traffic it was actually deploying with an HTTP server running on a high port. So we defined a new protocol in the CM for this port (you can also include src/dst in the configuration to narrow matching if needed). Now after the first download at an office location, the follow on requests as folks come into the office and power up are all served from local cache on the WAE. Now that's if you are running something it does have an application level accelerator for, if it's some other protocol you can either take the default or enable or disable some of the packet level optimizations. For example, if your traffic is encrypted - it would make sense to disable the LZ and bit database processing and just leave the TCP session optimization enabled, since the processing time to do the compression will actually take longer then just transferring the original payload and also may be causing the packet to fragment and double the number of packets required, etc. > After purchase, we saw a dramatic improvement in "user experience" > (basically the complaints stopped) from our EU site that was accessing > windows (samba) based file servers in USA. Those guys at the time were > connected to the US office over MLPPP (4 T1s). Samba sucked for them along > with everything else. Yes, deployment of most WAN accelerators that will do file caching will if not gain love from your users, it at least gets them off your back. -James > The only issue I had with Riverbed is their licensing model feels very > backwards. It took me a while to understand what we needed. > > Andrey > > On Thu, Apr 21, 2011 at 10:36 PM, Jonathan Fernattwrote: > >> On Thu, Apr 21, 2011 at 2:49 PM, harbor235 wrote: >> >>> Anyone out there have experience with Riverbed Steelhead products? >>> Do they improve TCP performance over WAN links? is it worth the price? >>> >>> >>> mike >>> >> I've had good experiences with both Riverbed Steelhead and Cisco WAAS >> products. Both have a very short ROI. I think either are well worth the >> price. >> >> Jon >> > > From swmike at swm.pp.se Mon Apr 25 14:51:02 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 25 Apr 2011 21:51:02 +0200 (CEST) Subject: SIXXS contact In-Reply-To: <4DB5A706.7000503@trelane.net> References: <4DB4EF5F.4000000@trelane.net> <4DB5A706.7000503@trelane.net> Message-ID: On Mon, 25 Apr 2011, Andrew Kirch wrote: > Yes, repeatedly. The response was non-existent, or simply unfortunate, > so I'm trying other avenues. I see this quite a lot. I guess one gets what one pays for (or doesn't pay for). Speaking of which, is there an IPv6 tunnel broker that actually charges money and where one can get real support? I would like to be able to refer people who complain about SIXXS and others offering support below expectation from some users. -- Mikael Abrahamsson email: swmike at swm.pp.se From ecables at gmail.com Mon Apr 25 15:48:34 2011 From: ecables at gmail.com (Eric Cables) Date: Mon, 25 Apr 2011 13:48:34 -0700 Subject: riverbed steelhead In-Reply-To: <4DB5CBC8.2050004@houseofzen.org> References: <4DB5CBC8.2050004@houseofzen.org> Message-ID: Some other considerations for Cisco vs. Riverbed are: Unified vs. Partitioned Data Store: Riverbed's data store is unified across all connected appliances, whereas Cisco partitions its data store across each connected appliance. This means that a data pattern seen once on Riverbed will be "warm" for subsequent transfers regardless of the destination office, whereas Cisco will need to perform a cold transfer for each branch, to populate the respective partition. FIFO vs. LRU: Cisco's data store expires patterns using FIFO, whereas Riverbed defaults to LRU (Least Recently Used). I prefer LRU since it means that commonly accessed data won't arbitrarily be deleted. Encrypted MAPI support: Riverbed supports it, and Cisco does not ("it's coming"). Central Manager: Cisco requires a central manager, whereas Riverbed does not. Riverbed does have a Central Management Console, but when the environment is <10 Steelheads, it's really not all that relevant. On-box Reporting: Cisco's on-box reporting is pretty terrible, whereas the Steelhead interface provides a lot of easy to gather statistics & connection information. Cisco's response to this was to invest in a NetFlow tool for visibility, which most environments have, but sometimes running a quick report on the box is easier, and this can add to the overall project cost if a commercial product is used. I'm sure there are more pros to Riverbed, but this is what I could think of off the top of my head. One thing I will mention is that Riverbed's v-Steelhead product, which is their virtual Steelhead offering, may pair very nicely with Cisco's SRE "UCS Express" offering for a single box solution. -- Eric Cables On Mon, Apr 25, 2011 at 12:30 PM, James Michael Keller < jmkeller at houseofzen.org> wrote: > On 04/25/2011 01:55 PM, Andrey Khomyakov wrote: > >> I personally would take Riverbed over Cisco for one main reason that I >> have >> discovered when I was researching them (that was good 3-4 years ago and >> cisco may have "improved" since). >> >> > Yes, they have improved dramatically in the last few years since the 4.x > release. > > > Cisco "accelerates" based on application. That is to say if it's not a >> well >> known application protocol, they do not do anything with it. >> So, they are probably good for HTTP/FTP/Samba etc. >> >> Riverbed does not care for applications (they still support application >> based acceleration, but they also support non standard stuff). They take >> something along the lines of data hashes and store them (along with data >> of >> course). They just store raw bytes as opposed to a let's say a file. That >> played out well when I had to make a decision about which brand to >> purchase >> for the company that had a homegrown application. So in a nutshell, >> Riverbed >> improved performance of that application (as well as all the standard >> players like HTTP/FTP etc), while cicso said outright that they won't. >> >> > > The current gen of WAAS works this way as well. The accelerators are > configurable for defined services along with a default profile. There are > several accelerators that are applied to each connection, starting with the > most basic TCP session optimization for window sizes and other per packet > modifications. > > It then applies raw data optimizations such as the raw 'bit' database you > mentioned, each WAE will attempt to find the largest unique run of bits and > create a hash for that sequence and store it in it's local database which > decays based on time and hit count. If both WAE's in the path have this > hash that is all that needs to be sent, otherwise it sends the entire > payload, which will then be cached on the second WAE going forward for > repeat occurrences (cache expiration not withstanding...). It can also do > LZ compression on the full payload when it needs to send it. > > After that there are application protocol accelerators for common protocols > like CIFS, HTTP, etc. These work on the session level and act as > transparent proxies for the protocols and can include file cache's on the > WAE. For other protocols like MS Video live streams, it can turn a > uni-cast session from multiple clients into a single session up to the video > server instead of multiple connections from each client. > > You also have the option with these to push server certificates and private > keys into the WAAS system with the Central Manager, which allows transparent > SSL/TLS acceleration for internal applications along with encrypted local > storage on the WAEs. > > As an example, we had a commercial patch deployment system that would bog > down on patch days or large updates like services packs. After the WAEs > went in it improved a bit but was still a huge tax on the network even with > sites that had local deployment servers for this application. After > digging through the application traffic it was actually deploying with an > HTTP server running on a high port. So we defined a new protocol in the > CM for this port (you can also include src/dst in the configuration to > narrow matching if needed). Now after the first download at an office > location, the follow on requests as folks come into the office and power up > are all served from local cache on the WAE. > > Now that's if you are running something it does have an application level > accelerator for, if it's some other protocol you can either take the default > or enable or disable some of the packet level optimizations. For example, > if your traffic is encrypted - it would make sense to disable the LZ and bit > database processing and just leave the TCP session optimization enabled, > since the processing time to do the compression will actually take longer > then just transferring the original payload and also may be causing the > packet to fragment and double the number of packets required, etc. > > > After purchase, we saw a dramatic improvement in "user experience" >> (basically the complaints stopped) from our EU site that was accessing >> windows (samba) based file servers in USA. Those guys at the time were >> connected to the US office over MLPPP (4 T1s). Samba sucked for them along >> with everything else. >> > > Yes, deployment of most WAN accelerators that will do file caching will if > not gain love from your users, it at least gets them off your back. > > -James > > > The only issue I had with Riverbed is their licensing model feels very >> backwards. It took me a while to understand what we needed. >> >> Andrey >> >> On Thu, Apr 21, 2011 at 10:36 PM, Jonathan Fernatt> >wrote: >> >> On Thu, Apr 21, 2011 at 2:49 PM, harbor235 wrote: >>> >>> Anyone out there have experience with Riverbed Steelhead products? >>>> Do they improve TCP performance over WAN links? is it worth the price? >>>> >>>> >>>> mike >>>> >>>> I've had good experiences with both Riverbed Steelhead and Cisco WAAS >>> products. Both have a very short ROI. I think either are well worth the >>> price. >>> >>> Jon >>> >>> >> >> > > From rfg at tristatelogic.com Mon Apr 25 17:22:39 2011 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 25 Apr 2011 15:22:39 -0700 Subject: Ongoing ASN and IP Space Hijacks: Update (TimeWarner/Level3/Tiscali) Message-ID: <18699.1303770159@tristatelogic.com> Eleven days ago, I reported here the following highly probable hijacks: AS8143 AS29987 AS11756 AS47024 AS27906 198.23.32.0/20 - NET-198-23-32-0-1 198.57.64.0/20 - NET-198-57-64-0-1 199.88.32.0/20 - NET-199-88-32-0-1 199.192.16.0/20 - NET-199-192-16-0-1 199.196.192.0/19 - NET-199-196-192-0-1 200.107.216.0/21 - GT-AGSA1-LACNIC 204.147.240.0/20 - NET-204-147-240-0-1 207.22.224.0/19 - (NET-207-22-192-0-1 Routing to a few of the above IP blocks has now been terminated, however at present I find that several of them are still very much alive and well, in particular: 199.88.32.0/20 - NET-199-88-32-0-1 199.196.192.0/19 - NET-199-196-192-0-1 200.107.216.0/21 - GT-AGSA1-LACNIC 204.147.240.0/20 - NET-204-147-240-0-1 As I previously mentioned, these are being used by high-end snowshoe spamming operations. Simple question: Does anybody give a damn? Regards, rfg P.S. Routing for the still-live hijacked blocks is as follows: 199.88.32.0/20 hijacked via AS29987 (hijacked ASN) via AS3257 (tiscali.net) 199.196.192.0/19 hijacked via AS8143 (hijacked ASN) via AS19844 (gorack.com) via AS4323/TimeWarner & AS3356/Level3 200.107.216.0/21 hijacked via AS8143 (hijacked ASN) via AS19844 (gorack.com) via AS4323/TimeWarner & AS3356/Level3 204.147.240.0/20 hijacked via AS47024 (hijacked ASN) via AS3257 (tiscali.net) P.P.S. As I also mentioned previously, GoRack seems to have some non-trivial connection to another South Florida company, Joytel Wireless, which itself was caught red-handed performing a sizable number of rather brazen IP block hijackings back in October: http://mailman.nanog.org/pipermail/nanog/2010-October/025997.html Given that Joytel/GoRack are clearly not at all bashful about what they are up to, it seems to me that it is incumbant upon TimeWarner and Level3 to take some action here. Otherwise, these hijackings are obviously just going to go on and on and on. As for Tiscali, and its obvious part in all this... well... if anyone is aware of any concious entity @ Tiscali who might actually give a damn about anything other than short-term profits, please do let me know. The people I've talked to, and the evidence above all indicates that Tiscali is, quite simply, ready, willing, and able to whore itself out to just about anybody. From drc at virtualized.org Mon Apr 25 17:58:33 2011 From: drc at virtualized.org (David Conrad) Date: Mon, 25 Apr 2011 12:58:33 -1000 Subject: Ongoing ASN and IP Space Hijacks: Update (TimeWarner/Level3/Tiscali) In-Reply-To: <18699.1303770159@tristatelogic.com> References: <18699.1303770159@tristatelogic.com> Message-ID: Ron, On Apr 25, 2011, at 12:22 PM, Ronald F. Guilmette wrote: > 199.88.32.0/20 - NET-199-88-32-0-1 > 199.196.192.0/19 - NET-199-196-192-0-1 > 200.107.216.0/21 - GT-AGSA1-LACNIC > 204.147.240.0/20 - NET-204-147-240-0-1 > > As I previously mentioned, these are being used by high-end snowshoe spamming > operations. > > Simple question: Does anybody give a damn? I suspect a lot of folks do, however giving a damn and having the ability to do anything about it may not coincide. Where can people go to gain more understanding of the methodologies you use to establish probable hijacks? Regards, -drc From rfg at tristatelogic.com Mon Apr 25 18:43:34 2011 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 25 Apr 2011 16:43:34 -0700 Subject: Ongoing ASN and IP Space Hijacks: Update (TimeWarner/Level3/Tiscali) In-Reply-To: Message-ID: <19508.1303775014@tristatelogic.com> In message , David Conrad wrote: >> Simple question: Does anybody give a damn? > >I suspect a lot of folks do, however giving a damn and having the >ability to do anything about it may not coincide. Do you or your company connect to Level3, TimeWarner, or Tiscali? For those that do, maybe this is an opportunity to make your opinions regarding the apparently ongoing support of these companies to hijacked ASNs and IP blocks known. >Where can people go to gain more understanding of the methodologies you >use to establish probable hijacks? Find? Or establish? As regards to finding them in the first place, my methodology involves specialized tools I've invented and constructed, and these employ methods that are currently maintained as trade secrets for obvious reasons. Verifying the status of a given block or ASN as being a probable hijack involves simply looking at the publically available evidence, and checking for a number of factors. Among these are (in no particular order): *) Was the block or ASN first allocated prior to the 1997 formation of ARIN? (If so, then it is a "legacy" resource, and these are the ones most frequently hijacked by far.) *) Does the company or other legal entity to which the block or ASN was allocated still even exist? (Google is your friend.) *) Has the relevant WHOIS record been altered recently, in particular the contact information (name, phone, e-mail) ? If so, that alone is somewhat suspicious, but especially so if the current e-mail contact address for the relevant number resource is in a domain which itself was only registered (or re-registered) recently. *) Is it possible to still make contact with the legal entity to which the number resource was allocated via the phone number given in the relevant WHOIS record? (Only meaningful if the relevant WHOIS record has NOT been recently altered.) *) Is it possible to still make contact with the legal entity to which the number resource was allocated via the e-mail address given in the relevant WHOIS record? (Only meaningful if the relevant WHOIS record has NOT been recently altered.) *) Does the block (or the blocks routed by the ASN in question) contain a lot of self-evident snowshoe spamming domains, e.g. domains with nonsense names, or with no web sites, or with no mail servers, or all created relatively recently, perhaps all via the same single registrar? (In the cases I look at, sometimes all of these factors are present.) *) In the case of an IP block, does the company that's routing the block have a prior track record of being involved in hijacking incidents? *) In the case of an ASN that is providing routing to one or more suspicious blocks, does the ASN in question have only a single upstream, as per www.robtex.com? *) In the case of an ASN that is providing routing to one or more suspicious blocks, does the ASN in question have only a single upstream, as per www.robtex.com, AND does that single upstream have a prior track record of being involved in hijacking incidents? Regards, rfg From trelane at trelane.net Mon Apr 25 21:12:48 2011 From: trelane at trelane.net (Andrew Kirch) Date: Mon, 25 Apr 2011 22:12:48 -0400 Subject: SIXXS contact In-Reply-To: References: <4DB4EF5F.4000000@trelane.net> <4DB5A706.7000503@trelane.net> Message-ID: <4DB62A20.7080408@trelane.net> On 4/25/2011 3:51 PM, Mikael Abrahamsson wrote: > On Mon, 25 Apr 2011, Andrew Kirch wrote: > >> Yes, repeatedly. The response was non-existent, or simply >> unfortunate, so I'm trying other avenues. > > I see this quite a lot. I guess one gets what one pays for (or doesn't > pay for). > > Speaking of which, is there an IPv6 tunnel broker that actually > charges money and where one can get real support? I would like to be > able to refer people who complain about SIXXS and others offering > support below expectation from some users. > This is a valid point. We want people to adopt IPv6, and to do this, they either have to be a huge ISP, or deal with 400ms ping times (one broker), or harassing/abusive volunteers (another broker). Now, I understand they're volunteers, I understand it's their own time, I understand that we are all (myself included) complete morons wasting their time. But if these two groups want people to take IPv6 seriously (you know, before the ceiling comes down on our heads), maybe they should take it seriously. Andrew From bruns at 2mbit.com Mon Apr 25 23:00:39 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Mon, 25 Apr 2011 22:00:39 -0600 Subject: SIXXS contact In-Reply-To: <4DB62A20.7080408@trelane.net> References: <4DB4EF5F.4000000@trelane.net> <4DB5A706.7000503@trelane.net> <4DB62A20.7080408@trelane.net> Message-ID: <4DB64367.2040003@2mbit.com> On 4/25/11 8:12 PM, Andrew Kirch wrote: >> Speaking of which, is there an IPv6 tunnel broker that actually >> > charges money and where one can get real support? I would like to be >> > able to refer people who complain about SIXXS and others offering >> > support below expectation from some users. >> > > This is a valid point. We want people to adopt IPv6, and to do this, > they either have to be a huge ISP, or deal with 400ms ping times (one > broker), or harassing/abusive volunteers (another broker). Now, I > understand they're volunteers, I understand it's their own time, I > understand that we are all (myself included) complete morons wasting > their time. But if these two groups want people to take IPv6 seriously > (you know, before the ceiling comes down on our heads), maybe they > should take it seriously. > > Andrew > I do believe Hurricane Electric may offer paid ipv6 services, including tunnel. Could always drop them a line and see. Up until last month when native ipv6 came online with our upstream, we had a ipv6 bgp peer tunnel from them - only issues were mostly bugs in foundry's ipv6 code on our end. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From swmike at swm.pp.se Tue Apr 26 00:28:34 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 26 Apr 2011 07:28:34 +0200 (CEST) Subject: SIXXS contact In-Reply-To: <4DB62A20.7080408@trelane.net> References: <4DB4EF5F.4000000@trelane.net> <4DB5A706.7000503@trelane.net> <4DB62A20.7080408@trelane.net> Message-ID: On Mon, 25 Apr 2011, Andrew Kirch wrote: > But if these two groups want people to take IPv6 seriously (you know, > before the ceiling comes down on our heads), maybe they should take it > seriously. Having run a volunteer service before, I can tell you there are a lot of people complaining about the free service. I would imagine the only alternative to doing what they do now is to either get more money and resources (sponsorship or paying customers) or to shut the service down. What is a preferrable service, a "not great" service, or no service at all? I know I wouldn't have the energy to handle all the abuse I see them getting, I would just tell people to go away and go home and watch tv. I'm happy they have the energy to do what they're doing. That's why I asked for SLA level services I can point people to who complain. I'd imagine most of them wouldn't want to pay anyway, but I hope it'll make them think about complaining too much about a free service. -- Mikael Abrahamsson email: swmike at swm.pp.se From scubacuda at gmail.com Tue Apr 26 05:43:23 2011 From: scubacuda at gmail.com (Rogelio) Date: Tue, 26 Apr 2011 13:43:23 +0300 Subject: best of breed nowadays in DPI space? In-Reply-To: References: Message-ID: For what it's worth, I just found this great report by Sandvine talking about bandwidth trends in various countries (Gotta enter in an email address, unfortunately) http://www.sandvine.com/news/global_broadband_trends.asp From scubacuda at gmail.com Tue Apr 26 05:43:51 2011 From: scubacuda at gmail.com (Rogelio) Date: Tue, 26 Apr 2011 13:43:51 +0300 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: On Apr 9, 2011, at 6:51 AM, John Palmer (NANOG Acct) wrote: > OK, its been a year since my Barracuda subscription expired. The unit still stops some spam. I figured that I would go and see what they would do if I tried to renew my subscription EXACTLY one year after it expired. Would their renewal website say "Oh, you are at your anniversary date", and renew me for a year? > > No such luck: They want me to PAY FOR AN ENTIRE YEAR for which I did NOT receive service and then for the current (upcoming year). Sorry - I don't allow myself to be ripped off like that. Sorry Barracuda - you get no money from me and I'll tell everyone I know about this policy of yours. While I agree with you (in theory), in practice, lots of companies do this baloney and there is little you can do if you need their product. In fact, I just got screwed by this policy at Fluke Networks when I tried to renew my subscription to one of their tools. From dorn at hetzel.org Tue Apr 26 05:54:47 2011 From: dorn at hetzel.org (Dorn Hetzel) Date: Tue, 26 Apr 2011 06:54:47 -0400 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: > > > While I agree with you (in theory), in practice, lots of companies do this > baloney and there is little you can do if you need their product. > > In fact, I just got screwed by this policy at Fluke Networks when I tried > to renew my subscription to one of their tools. > Would it turn out to be less expensive to just start a new subscription as if you never had one before? From scubacuda at gmail.com Tue Apr 26 05:56:55 2011 From: scubacuda at gmail.com (Rogelio) Date: Tue, 26 Apr 2011 13:56:55 +0300 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: On Apr 26, 2011, at 1:54 PM, Dorn Hetzel wrote: > > Would it turn out to be less expensive to just start a new subscription as if you never had one before? Usually places like this do it by serial number, in which case they don't let you update until you backpay. :) From sbenoit at georgianc.on.ca Tue Apr 26 06:11:40 2011 From: sbenoit at georgianc.on.ca (Steve Benoit) Date: Tue, 26 Apr 2011 07:11:40 -0400 Subject: Multi-site, multi-path to Internet - customer question - off topic ? Message-ID: <0B8FBC0B2DC0BF48A614FB38DA27014D1A08F460F4@BAEXMBX01.admin.georgianc.on.ca> Good day I have a question from a customer point of view. We currently have a multi-site WAN with all our Internet connectivity at one site consisting of 3 ISP type connections, full BGP, including our own ASN with IPv4 and v6 addressing space. All up and running. I am now looking to add Internet connectivity from a second site on our WAN for fail over in the event of a site 1 failure. My initial thoughts are towards another full BGP session at site 2, and perhaps something like Cisco's Global Site Selector, or F5's GTM to direct traffic. I'm thinking of phasing this in over a couple of years since the "server" folks will not have full hot fail-over at that site for that period. Of course, in a failure situation, the site will be expected to be live and operational immediately. Any suggestions on where I should start looking ? Any good white papers or case studies you have seen? And technologies we should look at or stay away from ? Thanks Steve Benoit From pekkas at netcore.fi Tue Apr 26 06:52:16 2011 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 26 Apr 2011 14:52:16 +0300 (EEST) Subject: SIXXS contact In-Reply-To: <4DB5A706.7000503@trelane.net> References: <4DB4EF5F.4000000@trelane.net> <4DB5A706.7000503@trelane.net> Message-ID: On Mon, 25 Apr 2011, Andrew Kirch wrote: > On 4/25/2011 4:07 AM, Raymond Dijkxhoorn wrote: >> Hi! >> >>> would someone at SIXXS please contact me off-list regarding an account >>> issue? >> >> Contact >> The main contact address for SixXS is info at sixxs.net, which is the >> sole email address one should use to contact SixXS. Non-English, >> impolite, clueless, UCE and HTML email gets discarded automatically. >> The official language used is English, due to archiving issues and the >> international effort put into SixXS. >> >> And you naturally trued that one before sending here, right? >> >> Bye, >> Raymond. >> > Yes, repeatedly. The response was non-existent, or simply unfortunate, > so I'm trying other avenues. Echo that. IPv6 bgp peering for distributed looking glass has been down for some 6 months or so now. No responses via any channel. It's sad because distributed looking glass has been very useful. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From bruns at 2mbit.com Tue Apr 26 11:11:11 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 26 Apr 2011 10:11:11 -0600 Subject: SIXXS contact In-Reply-To: References: <4DB4EF5F.4000000@trelane.net> <4DB5A706.7000503@trelane.net> <4DB62A20.7080408@trelane.net> Message-ID: <4DB6EE9F.2010309@2mbit.com> On 4/25/11 11:28 PM, Mikael Abrahamsson wrote: >> But if these two groups want people to take IPv6 seriously (you know, >> before the ceiling comes down on our heads), maybe they should take it >> seriously. > > Having run a volunteer service before, I can tell you there are a lot of > people complaining about the free service. I would imagine the only > alternative to doing what they do now is to either get more money and > resources (sponsorship or paying customers) or to shut the service down. > > What is a preferrable service, a "not great" service, or no service at > all? I know I wouldn't have the energy to handle all the abuse I see > them getting, I would just tell people to go away and go home and watch > tv. I'm happy they have the energy to do what they're doing. > > That's why I asked for SLA level services I can point people to who > complain. I'd imagine most of them wouldn't want to pay anyway, but I > hope it'll make them think about complaining too much about a free service. I've run a volunteer/free hosting service since 1997 or so - it never ceases to amaze me how people will complain about free things, but when you ask them to pony up a little monthly support its like you killed their puppy. I just term people who are more of a hassle then they are worth. I confirmed that HE will offer paid tunnel services, however I think I have a good idea of why Andrew was having crazy ping times to some of the tunnel servers. Literally anything I do from my home DSL through qwest that goes through Seattle sometimes doubles or triples the latency as soon as I enter the GBLX network. If I go through my T1, which ends up taking routes through TWTelecom, latency is in the low 20ms-40ms. I have a feeling that there's severe capacity issues on certain networks (may it be specifically between qwest and gblx, or just gblx in general), and unfortunately the lack of ISPs taking native IPv6 seriously puts our dependencies on ipv4 networks that are being held together with duct tape and twine. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From nick at flhsi.com Tue Apr 26 11:30:25 2011 From: nick at flhsi.com (Nick Olsen) Date: Tue, 26 Apr 2011 12:30:25 -0400 Subject: IPv6 Prefix announcing Message-ID: <3e67f6c1$2b23cd7f$74e5177b$@com> Greetings NANOG, I've always been under the impression its best practice to only announce prefixes of a /24 and above when it comes to IPv4 and BGP. I was wondering if something similar had been agreed upon regarding IPv6. And if That's the case, What's the magic number? /32? /48? /64? Nick Olsen Network Operations (855) FLSPEED x106 From streiner at cluebyfour.org Tue Apr 26 11:34:05 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 26 Apr 2011 12:34:05 -0400 (EDT) Subject: IPv6 Prefix announcing In-Reply-To: <3e67f6c1$2b23cd7f$74e5177b$@com> References: <3e67f6c1$2b23cd7f$74e5177b$@com> Message-ID: On Tue, 26 Apr 2011, Nick Olsen wrote: > I've always been under the impression its best practice to only announce > prefixes of a /24 and above when it comes to IPv4 and BGP. > I was wondering if something similar had been agreed upon regarding IPv6. > And if That's the case, What's the magic number? /32? /48? /64? You're likely to get different answers to this, but the 'magic number' appears to be /48. Looking in the v6 BGP table, you will likely find smaller prefixes than that, but a number of the major carriers seem to be settling on /48 as the smallest prefix they will accept. /48 is also the smallest block most of the RIRs will assign to end-users. jms From kate at quadranet.com Tue Apr 26 11:39:02 2011 From: kate at quadranet.com (Kate Gerry) Date: Tue, 26 Apr 2011 09:39:02 -0700 Subject: IPv6 Prefix announcing In-Reply-To: References: <3e67f6c1$2b23cd7f$74e5177b$@com> Message-ID: <4B4120B1642DCF48ACA84E4F82C8E1F65B83E20FC4@EXCH> Funny enough, some carriers actually require the 'smallest' as being /32... :( -----Original Message----- From: Justin M. Streiner [mailto:streiner at cluebyfour.org] Sent: Tuesday, April 26, 2011 9:34 AM To: nanog at nanog.org Subject: Re: IPv6 Prefix announcing On Tue, 26 Apr 2011, Nick Olsen wrote: > I've always been under the impression its best practice to only > announce prefixes of a /24 and above when it comes to IPv4 and BGP. > I was wondering if something similar had been agreed upon regarding IPv6. > And if That's the case, What's the magic number? /32? /48? /64? You're likely to get different answers to this, but the 'magic number' appears to be /48. Looking in the v6 BGP table, you will likely find smaller prefixes than that, but a number of the major carriers seem to be settling on /48 as the smallest prefix they will accept. /48 is also the smallest block most of the RIRs will assign to end-users. jms From patrick at ianai.net Tue Apr 26 11:44:24 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 26 Apr 2011 12:44:24 -0400 Subject: IPv6 Prefix announcing In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F65B83E20FC4@EXCH> References: <3e67f6c1$2b23cd7f$74e5177b$@com> <4B4120B1642DCF48ACA84E4F82C8E1F65B83E20FC4@EXCH> Message-ID: On Apr 26, 2011, at 12:39 PM, Kate Gerry wrote: > Funny enough, some carriers actually require the 'smallest' as being /32... :( Vote with your wallet. Some carriers would prefer if only transit free networks were allowed to originate routes. Doesn't mean you should follow their lead. -- TTFN, patrick > -----Original Message----- > From: Justin M. Streiner [mailto:streiner at cluebyfour.org] > Sent: Tuesday, April 26, 2011 9:34 AM > To: nanog at nanog.org > Subject: Re: IPv6 Prefix announcing > > On Tue, 26 Apr 2011, Nick Olsen wrote: > >> I've always been under the impression its best practice to only >> announce prefixes of a /24 and above when it comes to IPv4 and BGP. >> I was wondering if something similar had been agreed upon regarding IPv6. >> And if That's the case, What's the magic number? /32? /48? /64? > > You're likely to get different answers to this, but the 'magic number' > appears to be /48. Looking in the v6 BGP table, you will likely find smaller prefixes than that, but a number of the major carriers seem to be settling on /48 as the smallest prefix they will accept. /48 is also the smallest block most of the RIRs will assign to end-users. > > jms > > From gbonser at seven.com Tue Apr 26 12:12:40 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 26 Apr 2011 10:12:40 -0700 Subject: IPv6 Prefix announcing In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F65B83E20FC4@EXCH> References: <3e67f6c1$2b23cd7f$74e5177b$@com> <4B4120B1642DCF48ACA84E4F82C8E1F65B83E20FC4@EXCH> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E2F4E@RWC-EX1.corp.seven.com> > From: Kate Gerry > Sent: Tuesday, April 26, 2011 9:39 AM > To: 'Justin M. Streiner'; nanog at nanog.org > Subject: RE: IPv6 Prefix announcing > > Funny enough, some carriers actually require the 'smallest' as being > /32... :( > That might be true in PA space, but PI space is issued down to /48. I am not aware of anyone who filters smaller than a /32 in PI space though that doesn't mean it doesn't happen. The largest holdout was Verizon but my understanding is they now accept a /48 in PI space. So: A /32 is the smallest prefix issued in PA and some networks will not accept a prefix smaller than /32 from PA address space. A /48 is the smallest prefix issued in PI and some networks will not accept a prefix smaller than /48 from PI address space. In other words, if you are going to attempt to multihome a /48 allocation from your provider's aggregate, you are better off getting your own provider independent block. From bill at herrin.us Tue Apr 26 12:13:11 2011 From: bill at herrin.us (William Herrin) Date: Tue, 26 Apr 2011 13:13:11 -0400 Subject: IPv6 Prefix announcing In-Reply-To: <3e67f6c1$2b23cd7f$74e5177b$@com> References: <3e67f6c1$2b23cd7f$74e5177b$@com> Message-ID: On Tue, Apr 26, 2011 at 12:30 PM, Nick Olsen wrote: > Greetings NANOG, > I've always been under the impression its best practice to only announce > prefixes of a /24 and above when it comes to IPv4 and BGP. > I was wondering if something similar had been agreed upon regarding IPv6. > And if That's the case, What's the magic number? /32? /48? /64? Hi Nick, At this point, you can depend on being able to announce a /32 from any block and a /48 from an RIR block designated for end-user assignments. Many carriers have more permissive policies but all of any consequence now allow at least that. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Tue Apr 26 14:32:11 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Apr 2011 13:32:11 -0600 Subject: IPv6 Prefix announcing In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F65B83E20FC4@EXCH> References: <3e67f6c1$2b23cd7f$74e5177b$@com> <4B4120B1642DCF48ACA84E4F82C8E1F65B83E20FC4@EXCH> Message-ID: <0C1729C2-2D85-4B5C-9900-307DBA1FEA2E@delong.com> I know that used to be true, but, to the best of my knowledge, everyone is now accepting down to /48s in provider independent ranges. Some still require /32 or shorter in the provider aggregate ranges. Owen Sent from my iPad On Apr 26, 2011, at 10:39 AM, Kate Gerry wrote: > Funny enough, some carriers actually require the 'smallest' as being /32... :( > > > -----Original Message----- > From: Justin M. Streiner [mailto:streiner at cluebyfour.org] > Sent: Tuesday, April 26, 2011 9:34 AM > To: nanog at nanog.org > Subject: Re: IPv6 Prefix announcing > > On Tue, 26 Apr 2011, Nick Olsen wrote: > >> I've always been under the impression its best practice to only >> announce prefixes of a /24 and above when it comes to IPv4 and BGP. >> I was wondering if something similar had been agreed upon regarding IPv6. >> And if That's the case, What's the magic number? /32? /48? /64? > > You're likely to get different answers to this, but the 'magic number' > appears to be /48. Looking in the v6 BGP table, you will likely find smaller prefixes than that, but a number of the major carriers seem to be settling on /48 as the smallest prefix they will accept. /48 is also the smallest block most of the RIRs will assign to end-users. > > jms > From sethm at rollernet.us Tue Apr 26 14:51:59 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 26 Apr 2011 12:51:59 -0700 Subject: IPv6 Prefix announcing In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F65B83E20FC4@EXCH> References: <3e67f6c1$2b23cd7f$74e5177b$@com> <4B4120B1642DCF48ACA84E4F82C8E1F65B83E20FC4@EXCH> Message-ID: <4DB7225F.10408@rollernet.us> On 4/26/2011 09:39, Kate Gerry wrote: > Funny enough, some carriers actually require the 'smallest' as being /32... :( > This is becoming the exception now, not the rule. Last year I was fighting with Verizon about their refusal to carry /48s. That, together with the impasse of figuring out how to put dual stack IPv6 on an Ethernet port (it was delivered as IPv4 only multiple times), I never accepted it and went with a competitor who got it right the first time. However, I've had several sources tell me Verizon has since backpedaled and now accepts /48s. ~Seth From mksmith at adhost.com Tue Apr 26 15:17:04 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 26 Apr 2011 20:17:04 +0000 Subject: IPv6 Prefix announcing In-Reply-To: <4DB7225F.10408@rollernet.us> References: <3e67f6c1$2b23cd7f$74e5177b$@com> <4B4120B1642DCF48ACA84E4F82C8E1F65B83E20FC4@EXCH> <4DB7225F.10408@rollernet.us> Message-ID: > -----Original Message----- > From: Seth Mattinen [mailto:sethm at rollernet.us] > Sent: Tuesday, April 26, 2011 12:52 PM > To: nanog at nanog.org > Subject: Re: IPv6 Prefix announcing > > On 4/26/2011 09:39, Kate Gerry wrote: > > Funny enough, some carriers actually require the 'smallest' as being /32... :( > > > > This is becoming the exception now, not the rule. > > Last year I was fighting with Verizon about their refusal to carry /48s. > That, together with the impasse of figuring out how to put dual stack > IPv6 on an Ethernet port (it was delivered as IPv4 only multiple times), > I never accepted it and went with a competitor who got it right the > first time. However, I've had several sources tell me Verizon has since > backpedaled and now accepts /48s. > > ~Seth *> 2001:67C:120::/48 2001:504:16::1B1B 150 0 6939 701 12702 43751 6716 i Mike From trelane at trelane.net Tue Apr 26 17:38:49 2011 From: trelane at trelane.net (Andrew Kirch) Date: Tue, 26 Apr 2011 18:38:49 -0400 Subject: SIXXS contact In-Reply-To: <4DB6EE9F.2010309@2mbit.com> References: <4DB4EF5F.4000000@trelane.net> <4DB5A706.7000503@trelane.net> <4DB62A20.7080408@trelane.net> <4DB6EE9F.2010309@2mbit.com> Message-ID: <4DB74979.70108@trelane.net> On 4/26/2011 12:11 PM, Brielle Bruns wrote: > I've run a volunteer/free hosting service since 1997 or so - it never > ceases to amaze me how people will complain about free things, but > when you ask them to pony up a little monthly support its like you > killed their puppy. I just term people who are more of a hassle then > they are worth. I'm not complaining, but I would point out that if these free brokers are the public face of IPv6 for many hobbyists (and much of the various software run on/over the internet is written by volunteers, and/or given away for free), we aren't going to get there. The big deafening silence from SIXXS is really unfortunate in that it does actively affect my opinion of IPv6, my willingness to spend time implementing it, pestering my upstream about it, or having my business give a damn about it. Yes I know they're volunteers, but how much does that matter? Andrew From berni at birkenwald.de Tue Apr 26 18:21:14 2011 From: berni at birkenwald.de (Bernhard Schmidt) Date: Tue, 26 Apr 2011 23:21:14 +0000 (UTC) Subject: World of Warcraft may begin using IPv6 on Tuesday References: Message-ID: Kevin Day wrote: > Anyone from Activision/Blizzard who would like to chime in with more > details? :) I'm definitely not from either of those, but I've found this link: http://us.blizzard.com/support/article.xml?locale=en_US&tag=IPv6&rhtml=true --- What is IPv6? Internet Protocol version 6 (IPv6) is the technology behind the next-generation internet. IPv6 was designed to succeed the current version of IP (known as IPv4) and solve many of the current version's issues, such as the dwindling number of available IP addresses. To get ahead of the issue, we've put an IPv6 option into the World of Warcraft interface with patch 4.1. So as IPv6 starts to become more widely available the game will already be prepared to handle the switch over. For most players, the IPv6 checkbox will remain grayed out until IPv6 becomes available in your area. Once available, enabling this feature will require WoW.exe to detect a valid IPv6 connection to the internet on the computer you are playing from. At some point in the future, WoW realm servers will be able to use IPv6 in addition to the current IPv4. If IPv6 is enabled, the game will attempt to establish an IPv6 connection first. If unable to find an IPv6 connection, or if the IPv6 option is disabled/grayed out, the game will make an IPv4 connection instead. This should not cause any connection or performance issues. --- "At some point in the future" does not sound like we will see much IPv6 traffic immediately, but who knows. Is anyone seeing some traffic that might point to IPv6 adoption on the servers? Bernhard From jdfalk-lists at cybernothing.org Tue Apr 26 19:08:16 2011 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Tue, 26 Apr 2011 17:08:16 -0700 Subject: gmail dropping mesages In-Reply-To: <4DB5AB68.1030406@ll.mit.edu> References: <4DB20E2C.1040903@deaddrop.org> <4DB5AB68.1030406@ll.mit.edu> Message-ID: <12F1D79B-6D78-407B-9734-7EB5B0B08A46@cybernothing.org> On Apr 25, 2011, at 10:12 AM, Jeff Mitchell wrote: > If you trust the issued certificates(!) being used to sign the mail, you at least have a good indication that the spam is coming from the domain that it says it's coming from. This can make spam blocking much more effective because instead of simply hoping that a domain-based blocklist will block spam and not ham (due to spoofed sender addresses), you have a pretty good feeling that this will be the case. > > Of course this relies on various other bits and pieces to fall into place, such as properly handling such messages (Gmail's detection and handling rules aren't public AFAIK), CAs not being compromised, etc. Not to mention that the spammers can simply register another domain and buy a new cert -- but then the argument above still holds. DKIM doesn't use purchased certificates. It's all self-signed. As for catching spammers, using d= as an identifier is more effective at finding the good stuff than the bad stuff. So if this list were signed by nanog.org, we (or our reputation systems) could all recognize that mail signed d=nanog.org rarely resulted in user complaints, and thus it must be mail the users want to receive; conversely, mail which spoofs nanog.org but is not signed can safely* be stored in the big bit bucket in the cloud. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions * assuming nanog.org signs ALL mail -- but that's another long discussion From tshaw at oitc.com Tue Apr 26 19:56:39 2011 From: tshaw at oitc.com (TR Shaw) Date: Tue, 26 Apr 2011 20:56:39 -0400 Subject: SIXXS contact In-Reply-To: <4DB74979.70108@trelane.net> References: <4DB4EF5F.4000000@trelane.net> <4DB5A706.7000503@trelane.net> <4DB62A20.7080408@trelane.net> <4DB6EE9F.2010309@2mbit.com> <4DB74979.70108@trelane.net> Message-ID: <3F047D40-7089-4041-B271-05AF01779E76@oitc.com> On Apr 26, 2011, at 6:38 PM, Andrew Kirch wrote: > On 4/26/2011 12:11 PM, Brielle Bruns wrote: >> I've run a volunteer/free hosting service since 1997 or so - it never >> ceases to amaze me how people will complain about free things, but >> when you ask them to pony up a little monthly support its like you >> killed their puppy. I just term people who are more of a hassle then >> they are worth. > > I'm not complaining, but I would point out that if these free brokers > are the public face of IPv6 for many hobbyists (and much of the various > software run on/over the internet is written by volunteers, and/or given > away for free), we aren't going to get there. The big deafening silence > from SIXXS is really unfortunate in that it does actively affect my > opinion of IPv6, my willingness to spend time implementing it, pestering > my upstream about it, or having my business give a damn about it. Yes I > know they're volunteers, but how much does that matter? I can't say about SIXXS but HE has been great to me. If it wasn't for them I would be out in the cold since neither ATT nor Brighthouse (my 2 options at my colo) can even spell IPv6! Tom From trelane at trelane.net Tue Apr 26 20:00:49 2011 From: trelane at trelane.net (Andrew Kirch) Date: Tue, 26 Apr 2011 21:00:49 -0400 Subject: SIXXS contact In-Reply-To: <3F047D40-7089-4041-B271-05AF01779E76@oitc.com> References: <4DB4EF5F.4000000@trelane.net> <4DB5A706.7000503@trelane.net> <4DB62A20.7080408@trelane.net> <4DB6EE9F.2010309@2mbit.com> <4DB74979.70108@trelane.net> <3F047D40-7089-4041-B271-05AF01779E76@oitc.com> Message-ID: <4DB76AC1.6080501@trelane.net> On 4/26/2011 8:56 PM, TR Shaw wrote: > On Apr 26, 2011, at 6:38 PM, Andrew Kirch wrote: > > I can't say about SIXXS but HE has been great to me. If it wasn't for them I would be out in the cold since neither ATT nor Brighthouse (my 2 options at my colo) can even spell IPv6! > > Tom > > My goal here isn't to bash HE, just to note that I have _REALLY_ bad routes to it. I had no trouble setting up a tunnel with them. Andrew From mike at mtcc.com Tue Apr 26 20:16:52 2011 From: mike at mtcc.com (Michael Thomas) Date: Tue, 26 Apr 2011 18:16:52 -0700 Subject: gmail dropping mesages In-Reply-To: <12F1D79B-6D78-407B-9734-7EB5B0B08A46@cybernothing.org> References: <4DB20E2C.1040903@deaddrop.org> <4DB5AB68.1030406@ll.mit.edu> <12F1D79B-6D78-407B-9734-7EB5B0B08A46@cybernothing.org> Message-ID: <4DB76E84.6000403@mtcc.com> On 04/26/2011 05:08 PM, J.D. Falk wrote: > On Apr 25, 2011, at 10:12 AM, Jeff Mitchell wrote: > > >> If you trust the issued certificates(!) being used to sign the mail, you at least have a good indication that the spam is coming from the domain that it says it's coming from. This can make spam blocking much more effective because instead of simply hoping that a domain-based blocklist will block spam and not ham (due to spoofed sender addresses), you have a pretty good feeling that this will be the case. >> >> Of course this relies on various other bits and pieces to fall into place, such as properly handling such messages (Gmail's detection and handling rules aren't public AFAIK), CAs not being compromised, etc. Not to mention that the spammers can simply register another domain and buy a new cert -- but then the argument above still holds. >> > DKIM doesn't use purchased certificates. It's all self-signed. > Well, they aren't self-signed either; DKIM doesn't use x.509 style certs at all. It's just RSAPublicKey DER-encoded public keys that are placed in the DNS. Mike, but it still requires some crufty ASN.1 which is prolly the confusion From nanog at jima.tk Tue Apr 26 21:26:36 2011 From: nanog at jima.tk (Jima) Date: Tue, 26 Apr 2011 21:26:36 -0500 Subject: SIXXS contact In-Reply-To: <4DB76AC1.6080501@trelane.net> References: <4DB4EF5F.4000000@trelane.net> <4DB5A706.7000503@trelane.net> <4DB62A20.7080408@trelane.net> <4DB6EE9F.2010309@2mbit.com> <4DB74979.70108@trelane.net> <3F047D40-7089-4041-B271-05AF01779E76@oitc.com> <4DB76AC1.6080501@trelane.net> Message-ID: <4DB77EDC.207@jima.tk> On 2011-04-26 20:00, Andrew Kirch wrote: > My goal here isn't to bash HE, just to note that I have _REALLY_ bad > routes to it. I had no trouble setting up a tunnel with them. Have you checked Gogo6 at all? Jima From marka at isc.org Tue Apr 26 21:47:16 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 27 Apr 2011 12:47:16 +1000 Subject: SIXXS contact In-Reply-To: Your message of "Tue, 26 Apr 2011 21:00:49 -0400." <4DB76AC1.6080501@trelane.net> References: <4DB4EF5F.4000000@trelane.net> <4DB5A706.7000503@trelane.net> <4DB62A20.7080408@trelane.net> <4DB6EE9F.2010309@2mbit.com> <4DB74979.70108@trelane.net> <3F047D40-7089-4041-B271-05AF01779E76@oitc.com> <4DB76AC1.6080501@trelane.net> Message-ID: <20110427024716.CC51AE46A2D@drugs.dv.isc.org> In message <4DB76AC1.6080501 at trelane.net>, Andrew Kirch writes: > On 4/26/2011 8:56 PM, TR Shaw wrote: > > On Apr 26, 2011, at 6:38 PM, Andrew Kirch wrote: > > > > I can't say about SIXXS but HE has been great to me. If it wasn't for them > I would be out in the cold since neither ATT nor Brighthouse (my 2 options a > t my colo) can even spell IPv6! > > > > Tom > > > > > My goal here isn't to bash HE, just to note that I have _REALLY_ bad > routes to it. I had no trouble setting up a tunnel with them. Then I suggest that you complain to your current ISP. This is a IPv4 problem that they should be able to deal with. You are paying them good money for IPv4 connectivity and this is a IPv4 connectivity issue. > Andrew > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From vikassharmas at gmail.com Tue Apr 26 21:55:09 2011 From: vikassharmas at gmail.com (Vikas Sharma) Date: Wed, 27 Apr 2011 08:25:09 +0530 Subject: 6PE command for IOS and XR Message-ID: Hi, I was trying command "mpls ipv6 source-interface <>" on SRE3 code, look like there is no command like that on SRE. This command is important for locally generated packets. Have someone used this command? Also what is the command on XR 4.0.1 to achieve the same? Regards, Vikas From swmike at swm.pp.se Wed Apr 27 00:33:42 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 27 Apr 2011 07:33:42 +0200 (CEST) Subject: 6PE command for IOS and XR In-Reply-To: References: Message-ID: On Wed, 27 Apr 2011, Vikas Sharma wrote: > I was trying command "mpls ipv6 source-interface <>" on SRE3 code, look > like there is no command like that on SRE. This command is important for > locally generated packets. Have someone used this command? You already received a good answer on cisco-nsp yesterday, why are you asking the same thing here? -- Mikael Abrahamsson email: swmike at swm.pp.se From vikassharmas at gmail.com Wed Apr 27 00:38:07 2011 From: vikassharmas at gmail.com (Vikas Sharma) Date: Wed, 27 Apr 2011 11:08:07 +0530 Subject: 6PE command for IOS and XR In-Reply-To: References: Message-ID: Sorry, I just saw it... Regards, Vikas On Wed, Apr 27, 2011 at 11:03 AM, Mikael Abrahamsson wrote: > On Wed, 27 Apr 2011, Vikas Sharma wrote: > >> I was trying command "mpls ipv6 source-interface <>" on SRE3 code, look >> like there is no command like that on SRE. This command is important for >> locally generated packets. Have someone used this command? > > You already received a good answer on cisco-nsp yesterday, why are you > asking the same thing here? > > -- > Mikael Abrahamsson ? ?email: swmike at swm.pp.se > From seth.mos at dds.nl Wed Apr 27 01:39:16 2011 From: seth.mos at dds.nl (Seth Mos) Date: Wed, 27 Apr 2011 08:39:16 +0200 Subject: SIXXS contact In-Reply-To: <4DB74979.70108@trelane.net> References: <4DB4EF5F.4000000@trelane.net> <4DB5A706.7000503@trelane.net> <4DB62A20.7080408@trelane.net> <4DB6EE9F.2010309@2mbit.com> <4DB74979.70108@trelane.net> Message-ID: <4DB7BA14.2020102@dds.nl> Op 27-4-2011 0:38, Andrew Kirch schreef: > On 4/26/2011 12:11 PM, Brielle Bruns wrote: >> I've run a volunteer/free hosting service since 1997 or so - it never >> ceases to amaze me how people will complain about free things, but >> when you ask them to pony up a little monthly support its like you >> killed their puppy. I just term people who are more of a hassle then >> they are worth. > > I'm not complaining, but I would point out that if these free brokers > are the public face of IPv6 for many hobbyists (and much of the various > software run on/over the internet is written by volunteers, and/or given > away for free), we aren't going to get there. The big deafening silence > from SIXXS is really unfortunate in that it does actively affect my > opinion of IPv6, my willingness to spend time implementing it, pestering > my upstream about it, or having my business give a damn about it. Yes I > know they're volunteers, but how much does that matter? This same silence you mention is also my personal experience. I work on a open source firewall project in my spare time and found the issue annoying, as such I've decided to forgot Sixxs (dynamic) tunnel support and recommend the free Hurricane Electric tunnelbroker instead. I can spend my time better in getting OpenVPN working with IPv6 then waiting to accumulate kredits(tm). Kind regards, Seth From swmike at swm.pp.se Wed Apr 27 02:19:52 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 27 Apr 2011 09:19:52 +0200 (CEST) Subject: SIXXS contact In-Reply-To: <4DB74979.70108@trelane.net> References: <4DB4EF5F.4000000@trelane.net> <4DB5A706.7000503@trelane.net> <4DB62A20.7080408@trelane.net> <4DB6EE9F.2010309@2mbit.com> <4DB74979.70108@trelane.net> Message-ID: On Tue, 26 Apr 2011, Andrew Kirch wrote: > I'm not complaining, but I would point out that if these free brokers > are the public face of IPv6 for many hobbyists (and much of the various > software run on/over the internet is written by volunteers, and/or given > away for free), we aren't going to get there. The big deafening silence > from SIXXS is really unfortunate in that it does actively affect my > opinion of IPv6, my willingness to spend time implementing it, pestering > my upstream about it, or having my business give a damn about it. Yes I > know they're volunteers, but how much does that matter? So you would prefer that they shut down their service rather than provide current level of support? -- Mikael Abrahamsson email: swmike at swm.pp.se From tjc at ecs.soton.ac.uk Wed Apr 27 06:11:02 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 27 Apr 2011 12:11:02 +0100 Subject: World of Warcraft may begin using IPv6 on Tuesday In-Reply-To: References: <6A1FC60F-6A09-4F5F-B056-342FF312F854@ecs.soton.ac.uk> Message-ID: On 27 Apr 2011, at 00:21, Bernhard Schmidt wrote: > Kevin Day wrote: > ... > To get ahead of the issue, we've put an IPv6 option into the World of > Warcraft interface with patch 4.1. So as IPv6 starts to become more > widely available the game will already be prepared to handle the switch > over. For most players, the IPv6 checkbox will remain grayed out until > IPv6 becomes available in your area. Once available, enabling this > feature will require WoW.exe to detect a valid IPv6 connection to the > internet on the computer you are playing from. > > At some point in the future, WoW realm servers will be able to use IPv6 > in addition to the current IPv4. If IPv6 is enabled, the game will > attempt to establish an IPv6 connection first. If unable to find an IPv6 > connection, or if the IPv6 option is disabled/grayed out, the game will > make an IPv4 connection instead. This should not cause any connection or > performance issues. > --- > > "At some point in the future" does not sound like we will see much IPv6 > traffic immediately, but who knows. Is anyone seeing some traffic that > might point to IPv6 adoption on the servers? I arranged a test this morning. With a laptop running 4.1 on a dual-stack network the IPv6 option is greyed out under Network Options. I'm assuming your suggestion that the Blizzard servers are not yet enabled is probably correct, but that the clients now have capability. Would be interesting to know what they consider a 'valid IPv6 connection'. Tim From tjc at ecs.soton.ac.uk Wed Apr 27 07:20:19 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Wed, 27 Apr 2011 13:20:19 +0100 Subject: SIXXS contact In-Reply-To: References: <4DB4EF5F.4000000@trelane.net> <4DB5A706.7000503@trelane.net> <4DB62A20.7080408@trelane.net> <4DB6EE9F.2010309@2mbit.com> <4DB74979.70108@trelane.net> Message-ID: On 27 Apr 2011, at 08:19, Mikael Abrahamsson wrote: > On Tue, 26 Apr 2011, Andrew Kirch wrote: > >> I'm not complaining, but I would point out that if these free brokers are the public face of IPv6 for many hobbyists (and much of the various software run on/over the internet is written by volunteers, and/or given away for free), we aren't going to get there. The big deafening silence from SIXXS is really unfortunate in that it does actively affect my opinion of IPv6, my willingness to spend time implementing it, pestering my upstream about it, or having my business give a damn about it. Yes I know they're volunteers, but how much does that matter? > > So you would prefer that they shut down their service rather than provide current level of support? I've had very prompt and good replies from SixXS when I've contacted them. Equally students I know who use HE brokers are very happy with their service, e.g. HE have added features in response to feedback. Tim From mch-nanog at xs4all.nl Wed Apr 27 07:47:49 2011 From: mch-nanog at xs4all.nl (Marco Hogewoning) Date: Wed, 27 Apr 2011 14:47:49 +0200 Subject: New IPv6 survey released on labs.ripe.net Message-ID: <2F7F0BC0-94D6-409C-8253-65C7C6711950@xs4all.nl> Hi There, We just released a new version of the IPv6 CPE survey. After lots of feedback on the previous editions, we are now doing a "proper" survey. Based on the responses we receive in this survey we will be able to compile a new edition of our matrix and provide some more statistical background on what is happening in the market. Remember we are totally depending on your feedback to continue this work. The more responses we receive, the easier it gets for us to provide regular updates on which CPE are available on the market and how good they are. So if you have an IPv6 capable router or modem in your house, or you are busy testing them. Please take the time to fill out the survey and help other people to find the device that fits their need. Please see https://labs.ripe.net/Members/marco/ipv6-cpe-survey-please-participate for further details and a link to the survey. Thanks, MarcoH From owen at delong.com Wed Apr 27 07:53:35 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 27 Apr 2011 05:53:35 -0700 Subject: World of Warcraft may begin using IPv6 on Tuesday In-Reply-To: References: <6A1FC60F-6A09-4F5F-B056-342FF312F854@ecs.soton.ac.uk> Message-ID: <20D054F4-2403-4B67-95FB-0EB8A1A02A7C@delong.com> On Apr 27, 2011, at 4:11 AM, Tim Chown wrote: > > On 27 Apr 2011, at 00:21, Bernhard Schmidt wrote: > >> Kevin Day wrote: >> ... >> To get ahead of the issue, we've put an IPv6 option into the World of >> Warcraft interface with patch 4.1. So as IPv6 starts to become more >> widely available the game will already be prepared to handle the switch >> over. For most players, the IPv6 checkbox will remain grayed out until >> IPv6 becomes available in your area. Once available, enabling this >> feature will require WoW.exe to detect a valid IPv6 connection to the >> internet on the computer you are playing from. >> >> At some point in the future, WoW realm servers will be able to use IPv6 >> in addition to the current IPv4. If IPv6 is enabled, the game will >> attempt to establish an IPv6 connection first. If unable to find an IPv6 >> connection, or if the IPv6 option is disabled/grayed out, the game will >> make an IPv4 connection instead. This should not cause any connection or >> performance issues. >> --- >> >> "At some point in the future" does not sound like we will see much IPv6 >> traffic immediately, but who knows. Is anyone seeing some traffic that >> might point to IPv6 adoption on the servers? > > I arranged a test this morning. With a laptop running 4.1 on a dual-stack network the IPv6 option is greyed out under Network Options. > > I'm assuming your suggestion that the Blizzard servers are not yet enabled is probably correct, but that the clients now have capability. > > Would be interesting to know what they consider a 'valid IPv6 connection'. > > Tim Well, with full native IPv6 on ethernet using ARIN direct assigned addresses, it's still grayed out. I'm going to send in a support request and ask why it doesn't work. Owen From jra at baylink.com Wed Apr 27 09:54:37 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 27 Apr 2011 10:54:37 -0400 (EDT) Subject: SIXXS contact In-Reply-To: Message-ID: <28146864.211.1303916077160.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mikael Abrahamsson" > On Tue, 26 Apr 2011, Andrew Kirch wrote: > > > I'm not complaining, but I would point out that if these free brokers > > are the public face of IPv6 for many hobbyists (and much of the various > > software run on/over the internet is written by volunteers, and/or given > > away for free), we aren't going to get there. The big deafening silence > > from SIXXS is really unfortunate in that it does actively affect my > > opinion of IPv6, my willingness to spend time implementing it, pestering > > my upstream about it, or having my business give a damn about it. > > Yes I know they're volunteers, but how much does that matter? > > So you would prefer that they shut down their service rather than > provide current level of support? That sounds like the argument he's making, and there's some credit that should be given to it, yes. IPv6 is about, necessarily, to make the turn to being a consumer service. Consumers are *much* less tolerant of shaky implementations of new technologies that they can't see why they would need anyway. I call your attention, for an example, to electronically-assisted voting. There are half a dozen really good reasons why that would be A Good Thing... but the commercially-inspired miserable first 2 or 3 implementations of it have probably absorbed all of the public's tolerance of it for another 10 or 20 years. Cheers, -- jra From cb.list6 at gmail.com Wed Apr 27 10:39:52 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 27 Apr 2011 08:39:52 -0700 Subject: New IPv6 survey released on labs.ripe.net In-Reply-To: <2F7F0BC0-94D6-409C-8253-65C7C6711950@xs4all.nl> References: <2F7F0BC0-94D6-409C-8253-65C7C6711950@xs4all.nl> Message-ID: On Apr 27, 2011 5:49 AM, "Marco Hogewoning" wrote: > > Hi There, > > We just released a new version of the IPv6 CPE survey. After lots of feedback on the previous editions, we are now doing a "proper" survey. Based on the responses we receive in this survey we will be able to compile a new edition of our matrix and provide some more statistical background on what is happening in the market. > > Remember we are totally depending on your feedback to continue this work. The more responses we receive, the easier it gets for us to provide regular updates on which CPE are available on the market and how good they are. > > So if you have an IPv6 capable router or modem in your house, or you are busy testing them. Please take the time to fill out the survey and help other people to find the device that fits their need. > > Please see https://labs.ripe.net/Members/marco/ipv6-cpe-survey-please-participate for further details and a link to the survey. > Can we get mobile devices added to this? Mobile consumes a large amount of address space and is especially well suited for ipv6-only operations. Unfortunately, the results would be painfully narrow. Now that Nokia no longer supports ipv6, there is no going forward ipv6 support on any mobile device (htc did something special for thunderbolt, it's not an android 3g feature ) It's a very sad state of affairs. Cb > Thanks, > > MarcoH From ulf at Alameda.net Wed Apr 27 10:52:54 2011 From: ulf at Alameda.net (Ulf Zimmermann) Date: Wed, 27 Apr 2011 08:52:54 -0700 Subject: Barracuda Networks is at it again: Any Suggestions as to an Alternative? In-Reply-To: References: Message-ID: <20110427155254.GR94296@evil.alameda.net> On Tue, Apr 26, 2011 at 01:56:55PM +0300, Rogelio wrote: > On Apr 26, 2011, at 1:54 PM, Dorn Hetzel wrote: > > > > > Would it turn out to be less expensive to just start a new subscription as if you never had one before? > > Usually places like this do it by serial number, in which case they don't let you update until you backpay. :) > And don't forget the reinstating fees many companies charge too if you try to renew a month or 3 after the previous subscription has expired. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From tom.pipes at t6mail.com Wed Apr 27 11:19:25 2011 From: tom.pipes at t6mail.com (Tom Pipes) Date: Wed, 27 Apr 2011 11:19:25 -0500 Subject: Carrier Contact Message-ID: Greetings, Does anyone know who I could contact at Verizon Wireless regarding mis-routing one of my NXX blocks? Off list responses are fine. Thanks, -- Tom Pipes Essex Telcom Inc From jra at baylink.com Wed Apr 27 11:28:41 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 27 Apr 2011 12:28:41 -0400 (EDT) Subject: Carrier Contact In-Reply-To: Message-ID: <32208547.229.1303921721235.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Tom Pipes" > Does anyone know who I could contact at Verizon Wireless > regarding mis-routing one of my NXX blocks? Amazingly, customer service might be useful. I once called Sprint/Nextel to tell them that my Nextel phone couldn't call the broadcast call-in number for NPR's Talk of the Nation... and it was fixed in about 2 days. That was an 800 number, but I suspect the same principle applies. Have 4 or 5 employees who have VZW service call and report an inability to reach multiple specific -- and different -- numbers in your block, assuming you don't turn up anyone in their Translations group here. You might try the Outages list too; it's membership isn't, I don't think, a strict subset of NANOG's. Cheers, -- jra From toasty at dragondata.com Wed Apr 27 11:56:57 2011 From: toasty at dragondata.com (Kevin Day) Date: Wed, 27 Apr 2011 11:56:57 -0500 Subject: New IPv6 survey released on labs.ripe.net In-Reply-To: References: <2F7F0BC0-94D6-409C-8253-65C7C6711950@xs4all.nl> Message-ID: <69682373-6240-4FE9-8BB0-786F316A0AA9@dragondata.com> On Apr 27, 2011, at 10:39 AM, Cameron Byrne wrote: > > Can we get mobile devices added to this? Mobile consumes a large amount of > address space and is especially well suited for ipv6-only operations. > > Unfortunately, the results would be painfully narrow. Now that Nokia no > longer supports ipv6, there is no going forward ipv6 support on any mobile > device (htc did something special for thunderbolt, it's not an android 3g > feature ) > > It's a very sad state of affairs. For testing purposes, we try to keep a few phones on each major carrier, and I was actually surprised at how many of our randomly purchased phones did support IPv6. T-Mobile: Nokia N900 works great thanks to you(admittedly a dead-end from Nokia, but it works with the same level of shell script and kernel hacking that all N900 users expect) AT&T: iPhone 4 (works on wifi, but not over 3G. Can't even be disabled if you don't want v6) Verizon: HTC Thunderbolt (works out of the box) No IPv6 on Sprint, US Cellular or Metro PCS though. They don't have anything that supports IPv6 as far as I can tell. For me as a consumer, I actually had no idea that the Thunderbolt or iPhone were even using IPv6, it's totally automatic and seamless. But I am surprised at how few phones/tablets have any IPv6 support at all, with how late in the game this is. -- Kevin From mch-nanog at xs4all.nl Wed Apr 27 12:32:24 2011 From: mch-nanog at xs4all.nl (MarcoH - lists) Date: Wed, 27 Apr 2011 19:32:24 +0200 Subject: New IPv6 survey released on labs.ripe.net In-Reply-To: References: <2F7F0BC0-94D6-409C-8253-65C7C6711950@xs4all.nl> Message-ID: > Can we get mobile devices added to this? Mobile consumes a large amount of address space and is especially well suited for ipv6-only operations. I would rather make it a separate study. Integrating this with CPE might become messy and it would make the survey really long and complicated. Of course anything is possible. We encourage people to contribute on RIPE Labs with ideas and experiments. I think the first thing to do is to start a thread either here or on labs.ripe.net about what people would like to see from a survey on mobile devices. The CPE survey started of as a result of some work I did for my employer at the time. After a round of vendor selecting I was sitting on a pile of data and decided to publish it. Now I know my way around mobile a bit, but I am not an expert. So guidance on what is relevant and what not or help from somebody who knows more about mobile is more than welcome should we decide to push this forward. > Unfortunately, the results would be painfully narrow. Now that Nokia no longer supports ipv6, there is no going forward ipv6 support on any mobile device (htc did something special for thunderbolt, it's not an android 3g feature ) > > It's a very sad state of affairs. From what I know and seen so far this is indeed the sad situation we are in. At this stage I don't think publishing a survey towards end users would make the difference. But I am more than happy to find myself wrong on this one :) Grtx, MarcoH -- "Good tests kill flawed theories; we remain alive to guess again" From jmitchell at ll.mit.edu Wed Apr 27 12:37:11 2011 From: jmitchell at ll.mit.edu (Jeff Mitchell) Date: Wed, 27 Apr 2011 13:37:11 -0400 Subject: gmail dropping mesages In-Reply-To: <4DB76E84.6000403@mtcc.com> References: <4DB20E2C.1040903@deaddrop.org> <4DB5AB68.1030406@ll.mit.edu> <12F1D79B-6D78-407B-9734-7EB5B0B08A46@cybernothing.org> <4DB76E84.6000403@mtcc.com> Message-ID: <4DB85447.80707@ll.mit.edu> On 04/26/2011 09:16 PM, Michael Thomas wrote: > On 04/26/2011 05:08 PM, J.D. Falk wrote: >> On Apr 25, 2011, at 10:12 AM, Jeff Mitchell wrote: >> >> >>> If you trust the issued certificates(!) being used to sign the mail, you at least have a good indication that the spam is coming from the domain that it says it's coming from. This can make spam blocking much more effective because instead of simply hoping that a domain-based blocklist will block spam and not ham (due to spoofed sender addresses), you have a pretty good feeling that this will be the case. >>> >>> Of course this relies on various other bits and pieces to fall into place, such as properly handling such messages (Gmail's detection and handling rules aren't public AFAIK), CAs not being compromised, etc. Not to mention that the spammers can simply register another domain and buy a new cert -- but then the argument above still holds. >>> >> DKIM doesn't use purchased certificates. It's all self-signed. >> > > Well, they aren't self-signed either; DKIM doesn't use x.509 > style certs at all. It's just RSAPublicKey DER-encoded public > keys that are placed in the DNS. Sorry, yes. I've had GPG and X509 on the brain lately. Thanks for the correction, Mike and J.D. --Jeff From Wesley.E.George at sprint.com Wed Apr 27 12:42:38 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Wed, 27 Apr 2011 17:42:38 +0000 Subject: New IPv6 survey released on labs.ripe.net In-Reply-To: <69682373-6240-4FE9-8BB0-786F316A0AA9@dragondata.com> References: <2F7F0BC0-94D6-409C-8253-65C7C6711950@xs4all.nl> <69682373-6240-4FE9-8BB0-786F316A0AA9@dragondata.com> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8AEE9@PDAWM12B.ad.sprint.com> -----Original Message----- From: Kevin Day [mailto:toasty at dragondata.com] Sent: Wednesday, April 27, 2011 12:57 PM To: Cameron Byrne Cc: NANOG list Subject: Re: New IPv6 survey released on labs.ripe.net No IPv6 on Sprint, US Cellular or Metro PCS though. They don't have anything that supports IPv6 as far as I can tell. [WEG] Similar to the iPhone, any of the Android phones in Sprint's device portfolio should support IPv6 on WiFi, but not on the CDMA (3G) interface. I've confirmed it on several of them already. Wes George -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6753 bytes Desc: not available URL: From esavage at digitalrage.org Wed Apr 27 13:21:14 2011 From: esavage at digitalrage.org (Elijah Savage) Date: Wed, 27 Apr 2011 14:21:14 -0400 (EDT) Subject: riverbed steelhead In-Reply-To: <2617293.29601303928361201.JavaMail.root@ubuntu.digitalrage.org> Message-ID: <29644111.29621303928474430.JavaMail.root@ubuntu.digitalrage.org> >Anyone out there have experience with Riverbed Steelhead products? >Do they improve TCP performance over WAN links? is it worth the price? >mike ----------------------- James and Eric have done outstanding contributing here. I just wanted to add a tad bit of information leaving out the name brands. Our environment has a large number of these deployed and we have seen business and end user acceptance. From a business perspective, it could be a cost deferral tool within your toolset. Meaning if you are in an environment, which is sensitive to MRC (monthly recurring cost), implementing this technology can help you defer this cost. For example, I had a remote site that was at 95% of a full ds3 in capacity 6 hours of an 8-hour business day, after implementing this technology I was amazed at what we found. This sites utilization was reduced to 40% capacity max, not to mention the reduction we observed at the datacenter headend. We were preparing to increase capacity at this site, that was going to require swapping the WAN device as well as an increase in the MRC for this site and ongoing operational expense. Introduction of WAN optimization was significantly lower in these categories versus the upgrades. On the end user side due to the physical location/latency of this site a few applications was prone to suffer, the developers agreed to fix this would possibly require rewriting of the apps. Nothing more than the introduction of this technology was done and the support calls into the support center went from 100's per month to zero for a few of these applications. One thing that was important to me WAS MAPI encryption and the fact it was reversed engineered. Meaning if Microsoft at some point changed the way MAPI worked in a patch or upgrade you would end up with broken MAPI support and possibly a long runway to fixing it. The other company from my understanding (do not quote me on this YET) is collaborating and possibly working with Microsoft to license such support. I don't think you could go wrong with either brand/company but understanding your environments traffic patterns and its application usage would go a long way in guiding you towards the product for your environment. Good luck From millnert at gmail.com Wed Apr 27 14:21:44 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 27 Apr 2011 15:21:44 -0400 Subject: New IPv6 survey released on labs.ripe.net In-Reply-To: <69682373-6240-4FE9-8BB0-786F316A0AA9@dragondata.com> References: <2F7F0BC0-94D6-409C-8253-65C7C6711950@xs4all.nl> <69682373-6240-4FE9-8BB0-786F316A0AA9@dragondata.com> Message-ID: Mobile v6 folks, On Wed, Apr 27, 2011 at 12:56 PM, Kevin Day wrote: > T-Mobile: Nokia N900 works great thanks to you(admittedly a dead-end from Nokia, but it works with the same level of shell script and kernel hacking that all N900 users expect) Add the Nokia N97 to this list, with cellular/wifi support but no tethering, etc. Also I don't think IPv6 support on WiFi is as significant by at least two orders of magnitude as IPv6 support on the cellular interfaces is. A survey would be useful though: Firmware, IPv6 support ( WiFi / cellular ), v4/v6 tethering / hot spot operations, etc. I don't see how it can hurt to provide the middle ground between manufacturers and operators by having such a survey in this regard. Cameron probably has more to add (and some that he can't even if he wanted to, I guess). Marco H, understanding your reasons for wanting to keep CPE survey separate from what Cameron suggested, what's your opinion on doing a clone of the survey? (At some level, having not one but two of these surveys should attract you :) ) Best, Martin From tom.pipes at t6mail.com Wed Apr 27 15:42:42 2011 From: tom.pipes at t6mail.com (Tom Pipes) Date: Wed, 27 Apr 2011 15:42:42 -0500 Subject: Carrier Contact In-Reply-To: References: Message-ID: I ended up calling 611 on my Verizon phone and they were extremely nice and tried to help, but were unable to take it any further due the the fact that the call appears to route properly. The problem is that the call does route, but to the wrong switch in the wrong LATA and then routes over failover ISUP trunks. The rep tried to escalate it and reported back that there was nothing they could do because the call routes successfully. She agreed that it was going to be very difficult for me to get that to pass through the layers of support. It's very sad that this has to be so complicated. Thanks for the suggestions, Tom On Wed, Apr 27, 2011 at 11:19 AM, Tom Pipes wrote: > Greetings, > > Does anyone know who I could contact at Verizon Wireless > regarding mis-routing one of my NXX blocks? > > Off list responses are fine. > > Thanks, > > -- > Tom Pipes > Essex Telcom Inc > > From jra at baylink.com Wed Apr 27 17:57:38 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 27 Apr 2011 18:57:38 -0400 (EDT) Subject: Carrier Contact In-Reply-To: Message-ID: <27044327.255.1303945058063.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Tom Pipes" > I ended up calling 611 on my Verizon phone and they were extremely nice and > tried to help, but were unable to take it any further due the the fact that > the call appears to route properly. The problem is that the call does > route, but to the wrong switch in the wrong LATA and then routes over > failover ISUP trunks. The rep tried to escalate it and reported back that > there was nothing they could do because the call routes successfully. She > agreed that it was going to be very difficult for me to get that to pass > through the layers of support. > > It's very sad that this has to be so complicated. Oh. You're "fixing it". You're gonna have to break it, Tom, to get them to fix it. Sorry. "Be liberal in what you accept" is fine for operations, but not for debugging. If necessary, set up test numbers, and nullroute just those 10Ds in the "wrong" destination switch, so that you don't tail-end failover them, and then use *those*. Half a dozen or more, and don't make them look like test numbers. Cheers, -- jra From scott at sberkman.net Wed Apr 27 20:16:45 2011 From: scott at sberkman.net (Scott Berkman) Date: Wed, 27 Apr 2011 21:16:45 -0400 Subject: Carrier Contact In-Reply-To: References: Message-ID: <003e01cc0541$f0c90220$d25b0660$@sberkman.net> Have you tried looking for a Verizon routing or translations contact in the LERG? This is the official way. -Scott -----Original Message----- From: Tom Pipes [mailto:tom.pipes at t6mail.com] Sent: Wednesday, April 27, 2011 4:43 PM To: nanog at nanog.org Subject: Re: Carrier Contact I ended up calling 611 on my Verizon phone and they were extremely nice and tried to help, but were unable to take it any further due the the fact that the call appears to route properly. The problem is that the call does route, but to the wrong switch in the wrong LATA and then routes over failover ISUP trunks. The rep tried to escalate it and reported back that there was nothing they could do because the call routes successfully. She agreed that it was going to be very difficult for me to get that to pass through the layers of support. It's very sad that this has to be so complicated. Thanks for the suggestions, Tom On Wed, Apr 27, 2011 at 11:19 AM, Tom Pipes wrote: > Greetings, > > Does anyone know who I could contact at Verizon Wireless regarding > mis-routing one of my NXX blocks? > > Off list responses are fine. > > Thanks, > > -- > Tom Pipes > Essex Telcom Inc > > From carey at ar-ballbat.org Wed Apr 27 22:20:30 2011 From: carey at ar-ballbat.org (Andrew Carey) Date: Wed, 27 Apr 2011 20:20:30 -0700 Subject: Carrier Contact In-Reply-To: <003e01cc0541$f0c90220$d25b0660$@sberkman.net> References: <003e01cc0541$f0c90220$d25b0660$@sberkman.net> Message-ID: <1BEC0595-7719-44AB-B80C-1F3FF35AA627@ar-ballbat.org> Curious to what it says in the LERG about your switches & NXX's, too. Are your trunks directly connected to VZW's switches or through another carrier? I've had trouble in the past with calls failing to VZW. Their repair organization was less than helpful until we called the the local switch tech who got it fixed. On Apr 27, 2011, at 1816, Scott Berkman wrote: > Have you tried looking for a Verizon routing or translations contact in the > LERG? This is the official way. > > -Scott > > -----Original Message----- > From: Tom Pipes [mailto:tom.pipes at t6mail.com] > Sent: Wednesday, April 27, 2011 4:43 PM > To: nanog at nanog.org > Subject: Re: Carrier Contact > > I ended up calling 611 on my Verizon phone and they were extremely nice and > tried to help, but were unable to take it any further due the the fact that > the call appears to route properly. The problem is that the call does > route, but to the wrong switch in the wrong LATA and then routes over > failover ISUP trunks. The rep tried to escalate it and reported back that > there was nothing they could do because the call routes successfully. She > agreed that it was going to be very difficult for me to get that to pass > through the layers of support. > > It's very sad that this has to be so complicated. > > Thanks for the suggestions, > > Tom > > > On Wed, Apr 27, 2011 at 11:19 AM, Tom Pipes wrote: > >> Greetings, >> >> Does anyone know who I could contact at Verizon Wireless regarding >> mis-routing one of my NXX blocks? >> >> Off list responses are fine. >> >> Thanks, >> >> -- >> Tom Pipes >> Essex Telcom Inc >> >> > > From joe.abley at icann.org Thu Apr 28 12:31:53 2011 From: joe.abley at icann.org (Joe Abley) Date: Thu, 28 Apr 2011 17:31:53 +0000 Subject: Root Zone DNSSEC KSK Ceremony 5 Message-ID: KSK CEREMONY 5 The fifth KSK ceremony for the root zone will take place in Culpeper, VA, USA on Wednesday 2011-05-11. The ceremony is scheduled to begin at 1300 local time (1700 UTC) and is expected to end by 1600 local time (2000 UTC). Video from Ceremony 5 will be recorded for audit purposes. Video and associated audit materials will be published 1 to 2 weeks after the ceremony, and will be available as usual by following the "KSK Ceremony Materials" link at . ICANN will operate a separate camera whose video will not be retained for audit purposes, but which will instead be streamed live in order to provide remote observers an opportunity to watch the ceremony. The live stream will be provided on a best-effort basis. The live video stream will be available at . Ceremony 5 will include processing of a Key Signing Request (KSR) generated by VeriSign, and the resulting Signed Key Response (SKR) will contain signatures for Q3 2011. CONTACT INFORMATION We'd like to hear from you. If you have feedback for us, please send it to rootsign at icann.org. From dhc2 at dcrocker.net Thu Apr 28 14:13:24 2011 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Thu, 28 Apr 2011 12:13:24 -0700 Subject: Root Zone DNSSEC KSK Ceremony 5 In-Reply-To: References: Message-ID: <4DB9BC54.4090106@dcrocker.net> On 4/28/2011 10:31 AM, Joe Abley wrote: > KSK CEREMONY 5 Are 13 ceremonies planned for root signing? Absent anycast for them, that seems like the maximum. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jra at baylink.com Thu Apr 28 21:13:29 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 28 Apr 2011 22:13:29 -0400 (EDT) Subject: OPERATIONAL: Royal Wedding expected to break traffic records Message-ID: <24861917.291.1304043209120.JavaMail.root@benjamin.baylink.com> Preshow coverage on TV starts at 0400 EDT; 6 short hours from now. Did *you* make special plans? :-) Cheers, -- jra From rob at ipninja.net Thu Apr 28 21:26:37 2011 From: rob at ipninja.net (Rob V) Date: Thu, 28 Apr 2011 22:26:37 -0400 Subject: OPERATIONAL: Royal Wedding expected to break traffic records In-Reply-To: <24861917.291.1304043209120.JavaMail.root@benjamin.baylink.com> References: <24861917.291.1304043209120.JavaMail.root@benjamin.baylink.com> Message-ID: <000001cc0614$e0cb6380$a2622a80$@net> Not just that ... Youtube is apparently expecting 400 million (?!) viewers! http://news.yahoo.com/s/zd/20110428/tc_zd/263745 The doomsayers are out with freshly painted signs ... the Internet will break tomorrow morning! :-) > -----Original Message----- > From: Jay Ashworth [mailto:jra at baylink.com] > Sent: April-28-11 10:13 PM > To: NANOG > Subject: OPERATIONAL: Royal Wedding expected to break traffic records > > Preshow coverage on TV starts at 0400 EDT; 6 short hours from now. > > Did *you* make special plans? :-) > > Cheers, > -- jra From gbonser at seven.com Thu Apr 28 22:02:44 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 28 Apr 2011 20:02:44 -0700 Subject: OPERATIONAL: Royal Wedding expected to break traffic records In-Reply-To: <000001cc0614$e0cb6380$a2622a80$@net> References: <24861917.291.1304043209120.JavaMail.root@benjamin.baylink.com> <000001cc0614$e0cb6380$a2622a80$@net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E2FFA@RWC-EX1.corp.seven.com> > From: Rob V > Sent: Thursday, April 28, 2011 7:27 PM > To: 'NANOG' > Subject: RE: OPERATIONAL: Royal Wedding expected to break traffic > records > > Not just that ... Youtube is apparently expecting 400 million (?!) > viewers! > > http://news.yahoo.com/s/zd/20110428/tc_zd/263745 > > > The doomsayers are out with freshly painted signs ... the Internet will > break tomorrow morning! :-) (cough)multicast(cough) From joe at gonetforward.com Thu Apr 28 22:40:24 2011 From: joe at gonetforward.com (Joe Renwick) Date: Thu, 28 Apr 2011 20:40:24 -0700 Subject: MySQL Madness Message-ID: So I am seeing some interesting behavior of TCP during a MySQL connect over the network. The following packets capture shows the packet flow: asa1# sh capture debug-in 8 packets captured 1: 21:49:13.461554 8.25.42.100.32929 > 74.81.76.195.3306: S 4107544000:4107544000(0) win 65535 2: 21:49:13.462073 74.81.76.195.3306 > 8.25.42.100.32929: S 2601320299:2601320299(0) ack 4107544001 win 5792 3: 21:49:13.462210 74.81.76.195.3306 > 8.25.42.100.32929: P 2601320300:2601320363(63) ack 4107544001 win 46 4: 21:49:13.519061 8.25.42.100.32929 > 74.81.76.195.3306: . ack 2601320300 win 8208 5: 21:49:14.135384 8.25.42.100.32929 > 74.81.76.195.3306: P 4107544001:4107544003(2) ack 2601320300 win 8208 6: 21:49:14.135521 74.81.76.195.3306 > 8.25.42.100.32929: . ack 4107544003 win 46 7: 21:49:16.461981 74.81.76.195.3306 > 8.25.42.100.32929: P 2601320300:2601320363(63) ack 4107544003 win 46 8: 21:49:16.618147 8.25.42.100.32929 > 74.81.76.195.3306: . ack 2601320363 win 8208 8 packets shown Packet "1" is Syn from MySQL client to Server Packet "2" is Syn/Ack from Server Packet "3" is a TCP Push! ??? HERE IS WHERE I AM CONFUSED Packet "4" is the Ack from the client completing the 3-way hand shake. My firewall is dropping packet "3" as it is not happy there is a push going on before it sees the completed handshake. Anybody run across this? Is the a MySQL option for a faster connection? Finally the firewall is a Cisco ASA and the "TCP Normalization" feature is dropping the packet. Specifically is the "tcp-3whs-failed" rule that is being offended. I cannot seem to figure out a way to turn this off? Thanks for the help. Cheers, -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD! Direct: 619-800-2055, Emergency Support: 800-719-0504 Is your network moving you forward? From jra at baylink.com Thu Apr 28 23:14:13 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 29 Apr 2011 00:14:13 -0400 (EDT) Subject: OPERATIONAL: Royal Wedding expected to break traffic records In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E2FFA@RWC-EX1.corp.seven.com> Message-ID: <19627025.295.1304050453111.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "George Bonser" > > Not just that ... Youtube is apparently expecting 400 million (?!) > > viewers! > > > > http://news.yahoo.com/s/zd/20110428/tc_zd/263745 > > > > > > The doomsayers are out with freshly painted signs ... the Internet > > will > > break tomorrow morning! :-) > > (cough)multicast(cough) But... but... how do we count the viewers, then? Cheers, -- jra From bill at herrin.us Thu Apr 28 23:31:29 2011 From: bill at herrin.us (William Herrin) Date: Fri, 29 Apr 2011 00:31:29 -0400 Subject: MySQL Madness In-Reply-To: References: Message-ID: On Thu, Apr 28, 2011 at 11:40 PM, Joe Renwick wrote: > ?3: 21:49:13.462210 74.81.76.195.3306 > 8.25.42.100.32929: P > 2601320300:2601320363(63) ack 4107544001 win 46 2581054349 2065216038> > > Packet "1" is Syn from MySQL client to Server > Packet "2" is Syn/Ack from Server > Packet "3" is a TCP Push! ???? HERE IS WHERE I AM CONFUSED > Packet "4" is the Ack from the client completing the 3-way hand shake. > > My firewall is dropping packet "3" as it is not happy there is a push going > on before it sees the completed handshake. ?Anybody run across this? ?Is the > a MySQL option for a faster connection? A) That push appears to be the first data packet containing MySQL's connection banner. B) This would be an OS TCP implementation issue. MySQL has a socket as of when the syn/ack is queued. It has no control over when the OS decides it can begin to transmit the data MySQL writes to that socket. I'm guessing the OS is trying to optimize TCP performance by skipping the syn-received state and going straight to established. I'm not sure whether or not the RFCs allow that. > Specifically is the "tcp-3whs-failed" rule that is > being offended. ?I cannot seem to figure out a way to turn this off? If you figure it out, I'd be interested to learn what you found. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scott at doc.net.au Thu Apr 28 23:33:08 2011 From: scott at doc.net.au (Scott Howard) Date: Thu, 28 Apr 2011 21:33:08 -0700 Subject: MySQL Madness In-Reply-To: References: Message-ID: On Thu, Apr 28, 2011 at 8:40 PM, Joe Renwick wrote: > Packet "1" is Syn from MySQL client to Server > Packet "2" is Syn/Ack from Server > Packet "3" is a TCP Push! ??? HERE IS WHERE I AM CONFUSED > The "Push" is a red herring here. Push is an historic flag that is (almost) always ignored now days, but for historic reasons almost every TCP packet has it set. So packet 3 isn't really a "Push" packet, but it IS a data packet : 3: 21:49:13.462210 74.81.76.195.3306 > 8.25.42.100.32929: P 2601320300:2601320363(63) ack 4107544001 win 46 The "(63)" means the packet has 63 bytes of data in it. So if there's something strange happening here, it's that the server is sending a data packet before it gets the 3rd packet in the 3-way handshake. Whilst that's definitely strange, it's probably legal. It's definitely legal to include data in the SYN-ACK packet itself (and even, I think, in the initial SYN packet!) although I've never seen anything that implements that. In this case, the data isn't in the SYN-ACK itself but in a packet following it. I'm not sure if that's legal or not, but I can't see why it wouldn't be. My firewall is dropping packet "3" as it is not happy there is a push going > on before it sees the completed handshake. Not at all surprising. Most firewalls will drop anything that's even slightly unexpected, and this would certainly fit into that category - even if it's legal. Scott. From adrian at creative.net.au Fri Apr 29 00:08:58 2011 From: adrian at creative.net.au (Adrian Chadd) Date: Fri, 29 Apr 2011 13:08:58 +0800 Subject: OPERATIONAL: Royal Wedding expected to break traffic records In-Reply-To: <19627025.295.1304050453111.JavaMail.root@benjamin.baylink.com> References: <5A6D953473350C4B9995546AFE9939EE0C9E2FFA@RWC-EX1.corp.seven.com> <19627025.295.1304050453111.JavaMail.root@benjamin.baylink.com> Message-ID: <20110429050858.GA6447@skywalker.creative.net.au> On Fri, Apr 29, 2011, Jay Ashworth wrote: > > (cough)multicast(cough) > > But... but... how do we count the viewers, then? With HTML cookies and AJAX, like everyone else[1]. Adrian [1] and small embedded flash apps in small frames. Hi Facebook. From sra at isc.org Fri Apr 29 00:06:52 2011 From: sra at isc.org (Rob Austein) Date: Fri, 29 Apr 2011 01:06:52 -0400 Subject: MySQL Madness In-Reply-To: References: Message-ID: <20110429050652.5FA0C22829@thrintun.hactrn.net> At Thu, 28 Apr 2011 21:33:08 -0700, Scott Howard wrote: ... > The "(63)" means the packet has 63 bytes of data in it. So if there's > something strange happening here, it's that the server is sending a data > packet before it gets the 3rd packet in the 3-way handshake. ... > In this case, the data isn't in the SYN-ACK itself but in a packet following > it. I'm not sure if that's legal or not, but I can't see why it wouldn't be. It's legal. The third packet carries the client's ACK of the server's SYN, so the connection reaches state ESTABLISHED at that point. You don't see this pattern often because it's difficult to produce with the TCP APIs as they evolved on most operating systems, but that's an implementation artifact, not a protocol restriction. Since this is not a common pattern, it could easily be confusing the firewall that the original poster mentioned. Bug report time (reference page 68 of RFC 793), but in the meantime the original poster presumably needs a workaround. From surfer at mauigateway.com Fri Apr 29 01:14:09 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 28 Apr 2011 23:14:09 -0700 Subject: OPERATIONAL: Royal Wedding expected to break traffic records Message-ID: <20110428231409.9EB9FF96@resin13.mta.everyone.net> --- adrian at creative.net.au wrote: On Fri, Apr 29, 2011, Jay Ashworth wrote: > > (cough)multicast(cough) > > But... but... how do we count the viewers, then? With HTML cookies and AJAX, like everyone else[1]. ------------------------------------------------------- 1.3.6.1.3.59.1.1.1.1.11 1.3.6.1.3.59.1.1.1.1.12 :-) scott From scubacuda at gmail.com Fri Apr 29 02:54:42 2011 From: scubacuda at gmail.com (Rogelio) Date: Fri, 29 Apr 2011 10:54:42 +0300 Subject: open source DPI suggestions? Message-ID: Can anyone suggest any open source DPI (deep packet inspection) projects? I am working on various telco projects in emerging markets, but can't quite justify the price for the bigger and more well known players. :/ (Until then, I'll have to rely on some of the more well known Linux and BSD traffic shaping tools) -- Also on LinkedIn?? Feel free to connect if you too are an open networker: scubacuda at gmail.com From tjc at ecs.soton.ac.uk Fri Apr 29 06:09:28 2011 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 29 Apr 2011 12:09:28 +0100 Subject: OPERATIONAL: Royal Wedding expected to break traffic records In-Reply-To: <000001cc0614$e0cb6380$a2622a80$@net> References: <24861917.291.1304043209120.JavaMail.root@benjamin.baylink.com> <000001cc0614$e0cb6380$a2622a80$@net> Message-ID: On 29 Apr 2011, at 03:26, Rob V wrote: > Not just that ... Youtube is apparently expecting 400 million (?!) viewers! > > http://news.yahoo.com/s/zd/20110428/tc_zd/263745 > > > The doomsayers are out with freshly painted signs ... the Internet will break tomorrow morning! :-) Must say the quality of the Youtube coverage has been very good, in all senses. Interesting early on the youtube feed lagged 20+ seconds behind the 'live' BBC TV, then during the ceremony was almost simulataneous. Tim From seth at icir.org Fri Apr 29 07:33:59 2011 From: seth at icir.org (Seth Hall) Date: Fri, 29 Apr 2011 08:33:59 -0400 Subject: open source DPI suggestions? In-Reply-To: References: Message-ID: <9F4E9FBB-B557-4171-98BC-905E91A97A23@icir.org> On Apr 29, 2011, at 3:54 AM, Rogelio wrote: > Can anyone suggest any open source DPI (deep packet inspection) projects? I'll recommend Bro-IDS (http://www.bro-ids.org/) as it's what I spend my days working on. It's essentially a programming language for long term network traffic monitoring which is focused on doing deep decoding of application layer protocols. (and it's BSD licensed!) .Seth -- Seth Hall International Computer Science Institute (Bro) because everyone has a network http://www.bro-ids.org/ From ray at oneunified.net Fri Apr 29 07:55:16 2011 From: ray at oneunified.net (Raymond Burkholder) Date: Fri, 29 Apr 2011 09:55:16 -0300 Subject: open source DPI suggestions? In-Reply-To: <9F4E9FBB-B557-4171-98BC-905E91A97A23@icir.org> References: <9F4E9FBB-B557-4171-98BC-905E91A97A23@icir.org> Message-ID: <09aa01cc066c$b0437fb0$10ca7f10$@oneunified.net> > > Can anyone suggest any open source DPI (deep packet inspection) > projects? > > > I'll recommend Bro-IDS (http://www.bro-ids.org/) as it's what I spend my > days working on. It's essentially a programming language for long term > network traffic monitoring which is focused on doing deep decoding of > application layer protocols. (and it's BSD licensed!) > http://l7-filter.sourceforge.net/ might be another candidate. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From kornholijo at gmail.com Fri Apr 29 07:59:07 2011 From: kornholijo at gmail.com (Kornelijus Survila) Date: Fri, 29 Apr 2011 07:59:07 -0500 Subject: open source DPI suggestions? In-Reply-To: <09aa01cc066c$b0437fb0$10ca7f10$@oneunified.net> References: <9F4E9FBB-B557-4171-98BC-905E91A97A23@icir.org> <09aa01cc066c$b0437fb0$10ca7f10$@oneunified.net> Message-ID: Snort (http://www.snort.org/) is also a nice IDS. They provide paid and free rules/signatures. -k On Fri, Apr 29, 2011 at 7:55 AM, Raymond Burkholder wrote: > > > Can anyone suggest any open source DPI (deep packet inspection) > > projects? > > > > > > I'll recommend Bro-IDS (http://www.bro-ids.org/) as it's what I spend my > > days working on. It's essentially a programming language for long term > > network traffic monitoring which is focused on doing deep decoding of > > application layer protocols. (and it's BSD licensed!) > > > > http://l7-filter.sourceforge.net/ might be another candidate. > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > From kyle.creyts at gmail.com Fri Apr 29 08:55:52 2011 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Fri, 29 Apr 2011 09:55:52 -0400 Subject: Wire-rate Packet Capture on 10gbE Message-ID: How is this being done? I've looked at looked at PF_RING and TNAPI... is there anything better out there? --Kyle From attilla.degroot at ams-ix.net Fri Apr 29 08:59:20 2011 From: attilla.degroot at ams-ix.net (Attilla de Groot) Date: Fri, 29 Apr 2011 15:59:20 +0200 Subject: Wire-rate Packet Capture on 10gbE In-Reply-To: References: Message-ID: On Apr 29, 2011, at 3:55 PM, Kyle Creyts wrote: > How is this being done? I've looked at looked at PF_RING and TNAPI... is > there anything better out there? http://events.ccc.de/congress/2006/Fahrplan/attachments/1225-23c3-slides-av.pdf That should give you some answers. :-) -- Attilla From michael.holstein at csuohio.edu Fri Apr 29 09:43:39 2011 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Fri, 29 Apr 2011 10:43:39 -0400 Subject: Wire-rate Packet Capture on 10gbE In-Reply-To: References: Message-ID: <4DBACE9B.6080204@csuohio.edu> > How is this being done? I've looked at looked at PF_RING and TNAPI... is > there anything better out there? > Those two (thanks to Luca) can get you most of the way there, but to really hit the target you need dedicated kit like Endace (and a few others) make. They basically do what was represented in the CCC slides somebody else posted (FPGA with own logic), but on a PCIe card. Once you've got the ethernet -> interface problem addressed, you need to examine bottlenecks in interface->bus and particularly bus->disk. Regards, Michael Holstein Cleveland State Unversity > --Kyle > > From nathan at robotics.net Fri Apr 29 10:18:57 2011 From: nathan at robotics.net (Nathan Stratton) Date: Fri, 29 Apr 2011 10:18:57 -0500 (CDT) Subject: Wire-rate Packet Capture on 10gbE In-Reply-To: <4DBACE9B.6080204@csuohio.edu> References: <4DBACE9B.6080204@csuohio.edu> Message-ID: On Fri, 29 Apr 2011, Michael Holstein wrote: > Those two (thanks to Luca) can get you most of the way there, but to > really hit the target you need dedicated kit like Endace (and a few > others) make. They basically do what was represented in the CCC slides > somebody else posted (FPGA with own logic), but on a PCIe card. > > Once you've got the ethernet -> interface problem addressed, you need to > examine bottlenecks in interface->bus and particularly bus->disk. One good open source solution on the disk side is Gluster with 10 gig infiniband on the back end. Gluster allows you to build a distributed storage over many servers. You can find 10 gig infiniband cards on ebay for around $50 and a good 24 port topspin/cisco switch will cost you about $1K. ><> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com From Joe.Happe at archlearning.com Fri Apr 29 10:31:43 2011 From: Joe.Happe at archlearning.com (Joe Happe) Date: Fri, 29 Apr 2011 10:31:43 -0500 Subject: Wire-rate Packet Capture on 10gbE In-Reply-To: <4DBACE9B.6080204@csuohio.edu> References: <4DBACE9B.6080204@csuohio.edu> Message-ID: <39FE092FD3E7BC4D92672586FE5F1E250BEA1A3985@SIDFWCRPMSG001.us.si.lan> Might also take a look at Gigamon, Anue Systems, and similar vendors. It's possible to use these switches to "slice and dice" traffic from a 10g input to a farm of 1g tools for packet capture, ids, waf, content filtering etc. Although there is a cost, it's usually cheaper than having to upgrade multiple existing tools to 10g speeds. It also solves the issues with the number of source span's allowed on many Cisco switches, and avoids the bus/disk issues tools run into when dealing with 10g linerates. (For now at least) ~jdh -----Original Message----- From: Michael Holstein [mailto:michael.holstein at csuohio.edu] Sent: Friday, April 29, 2011 9:44 AM To: Kyle Creyts Cc: nanog at nanog.org Subject: Re: Wire-rate Packet Capture on 10gbE > How is this being done? I've looked at looked at PF_RING and TNAPI... > is there anything better out there? > Those two (thanks to Luca) can get you most of the way there, but to really hit the target you need dedicated kit like Endace (and a few others) make. They basically do what was represented in the CCC slides somebody else posted (FPGA with own logic), but on a PCIe card. Once you've got the ethernet -> interface problem addressed, you need to examine bottlenecks in interface->bus and particularly bus->disk. Regards, Michael Holstein Cleveland State Unversity > --Kyle > > ______________________________________________________________________________________________________ The information contained in this electronic message and any attachments is confidential, is for the sole use of the intended recipient(s) and may contain privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, you must not read, use or disseminate the information, and should immediately contact the sender by reply email and destroy all copies of the original message. From jra at baylink.com Fri Apr 29 12:12:54 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 29 Apr 2011 13:12:54 -0400 (EDT) Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <06999366-411d-41d3-becd-37362dbf6365@e21g2000vbz.googlegroups.com> Message-ID: <27337170.307.1304097174940.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Ryan Malayter" > On Apr 28, 11:14 pm, Jay Ashworth wrote: > > > (cough)multicast(cough) > > > > But... but... how do we count the viewers, then? > > Isn't the real problem with global multicast: "How do we ultimately > bill the broadcaster for all that traffic amplification that happened > *inside* every other AS?" It seems like you'd have to do per-packet > accounting at every router, and coordinate billing/reporting amongst > all providers that saw those packets. See, now, I expected to hear that objection. Internet engineers are prone to try to solve this problem in favor of the viewer, and their networks -- with their networks winning in case of a push. *Program providers*, OTOH, have a completely different set of "optimal" parameters -- many of which are directly at odds with that approach, and most of which are completely ignored by Internet engineering types when working on this stuff. And OTGH, even if, say, a local TV station wanted to let people do this sort of thing, *the people they get their programs from* -- both at the Network and the "provider to Network" level -- will expect to have their own say in the matter. *Certainly* there should be a Multicast Cloud, and an easy way for program providers to dump things into it. But, as you say, who's going to pay for it is an issue, and how one enforces that is another even more contentious one. Layer 9 is a *bitch*, isn't it? So: if I *wanted* to put my video in the multicast cloud... how would I do it? I do, after all, now work for a TV network which sells things; this is not an idle question for me: the more people who can see me, the better. Is it a nice, packaged howto, with easily built code? Pointers? Cause it seems to me that the fewer speedbumps there are along the way, the sooner it will happen, all that nassty, nassty commerce, notwithstanding. Cheers, -- jra From tom.pipes at t6mail.com Fri Apr 29 12:20:35 2011 From: tom.pipes at t6mail.com (Tom Pipes) Date: Fri, 29 Apr 2011 12:20:35 -0500 Subject: Carrier Contact In-Reply-To: References: Message-ID: I just wanted to pass on a huge thanks to the members of this list who gave suggestions, and ultimately VZW's LERG Contact and the tech who contacted me this morning and got the routing translation fixed. It once again proves how valuable Nanog list membership can be in identifying the appropriate contacts for a Carrier and resolving technical issues. Sincerely, Tom Pipes Essex Telcom On Wed, Apr 27, 2011 at 11:19 AM, Tom Pipes wrote: > Greetings, > > Does anyone know who I could contact at Verizon Wireless > regarding mis-routing one of my NXX blocks? > > Off list responses are fine. > > Thanks, > > -- > Tom Pipes > Essex Telcom Inc > > From rubensk at gmail.com Fri Apr 29 12:23:23 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 29 Apr 2011 14:23:23 -0300 Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <27337170.307.1304097174940.JavaMail.root@benjamin.baylink.com> References: <06999366-411d-41d3-becd-37362dbf6365@e21g2000vbz.googlegroups.com> <27337170.307.1304097174940.JavaMail.root@benjamin.baylink.com> Message-ID: >> Isn't the real problem with global multicast: "How do we ultimately >> bill the broadcaster for all that traffic amplification that happened >> *inside* every other AS?" It seems like you'd have to do per-packet >> accounting at every router, and coordinate billing/reporting amongst >> all providers that saw those packets. Broadcast encrypted streams. Unicast the key distribution, allowing interested parties to count, bill, block, allow, litigate, agree... Rubens From jra at baylink.com Fri Apr 29 12:48:51 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 29 Apr 2011 13:48:51 -0400 (EDT) Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: Message-ID: <21149940.309.1304099331309.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Rubens Kuhl" > >> Isn't the real problem with global multicast: "How do we ultimately > >> bill the broadcaster for all that traffic amplification that > >> happened > >> *inside* every other AS?" It seems like you'd have to do per-packet > >> accounting at every router, and coordinate billing/reporting > >> amongst > >> all providers that saw those packets. > > Broadcast encrypted streams. Unicast the key distribution, allowing > interested parties to count, bill, block, allow, litigate, agree... And that's the snap answer, yes. But the *load*, while admittedly lessened over unicast, falls *mostly* to the carriers, who cannot anymore bill for it, either to end users, providers, *or* as transit. Will they not complain about having their equipment utilization go up with no recompense -- for something that is only of benefit to commercial customers of some other entity? You're effectively pushing the CDN into the backbone, here; no? Cheers, -- jra From Valdis.Kletnieks at vt.edu Fri Apr 29 13:04:04 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 29 Apr 2011 14:04:04 -0400 Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: Your message of "Fri, 29 Apr 2011 13:48:51 EDT." <21149940.309.1304099331309.JavaMail.root@benjamin.baylink.com> References: <21149940.309.1304099331309.JavaMail.root@benjamin.baylink.com> Message-ID: <152933.1304100244@localhost> On Fri, 29 Apr 2011 13:48:51 EDT, Jay Ashworth said: > Will they not complain about having their equipment utilization go up > with no recompense -- for something that is only of benefit to commercial > customers of some other entity? Like their load didn't go up with no recompense this morning. What's the break-even point, the number of streams being sent at once where multicasting it starts taking less resources than N unicast streams? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rubensk at gmail.com Fri Apr 29 13:26:07 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 29 Apr 2011 15:26:07 -0300 Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <21149940.309.1304099331309.JavaMail.root@benjamin.baylink.com> References: <21149940.309.1304099331309.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, Apr 29, 2011 at 2:48 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Rubens Kuhl" > >> >> Isn't the real problem with global multicast: "How do we ultimately >> >> bill the broadcaster for all that traffic amplification that >> >> happened >> >> *inside* every other AS?" It seems like you'd have to do per-packet >> >> accounting at every router, and coordinate billing/reporting >> >> amongst >> >> all providers that saw those packets. >> >> Broadcast encrypted streams. Unicast the key distribution, allowing >> interested parties to count, bill, block, allow, litigate, agree... > > And that's the snap answer, yes. ?But the *load*, while admittedly > lessened over unicast, falls *mostly* to the carriers, who cannot anymore > bill for it, either to end users, providers, *or* as transit. Why not ? One can set conditions for doing multicast replication prior to doing it, and they might include payment for services. We don`t have a global Multicast RP for everyone to use, each operator chooses if, how and when multicast streams are going into their RPs. > Will they not complain about having their equipment utilization go up > with no recompense -- for something that is only of benefit to commercial > customers of some other entity? Unicast streaming has done it already, as Vladis pointed out... Rubens From dwhite at olp.net Fri Apr 29 13:47:49 2011 From: dwhite at olp.net (Dan White) Date: Fri, 29 Apr 2011 13:47:49 -0500 Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <152933.1304100244@localhost> References: <21149940.309.1304099331309.JavaMail.root@benjamin.baylink.com> <152933.1304100244@localhost> Message-ID: <20110429184749.GG8638@dan.olp.net> On 29/04/11?14:04?-0400, Valdis.Kletnieks at vt.edu wrote: >On Fri, 29 Apr 2011 13:48:51 EDT, Jay Ashworth said: >> Will they not complain about having their equipment utilization go up >> with no recompense -- for something that is only of benefit to commercial >> customers of some other entity? > >Like their load didn't go up with no recompense this morning. For what it's worth, we didn't see much of bump this morning on our broadband network... maybe a 10-15% spike (and non-peak hours at that). >What's the break-even point, the number of streams being sent at once where >multicasting it starts taking less resources than N unicast streams? Video distribution is bound to continue to go in the direction of Netflix/Youtube where ISPs are going to be highly motivated to find cheaper ways to provide internet content to their end users. And directly peered, multicast agreements between CDNs and ISPs are going to be a real quick way to chop operational costs. Even if that doesn't apply to Netflix content today, it's bound to matter for content that consumers are going to want to consume in real time (sporting events). From the perspective of an ISP operating in a small market, we are seeing a big shift in usage toward Netflix and netflix-like services that is necessarily going to change the model of how we provide internet services. We have limited access to CDN or Content-Producer peering agreements (that would help to save costs) and, even if we did, we're in no position to demand ingress cash flow in those agreements (not enough eyeballs!). Since our users are the ones with the business arrangements with Netflix, and since their demand is shifting in that direction, I'd imagine we'd jump at a chance for private multicast agreements, even if demand didn't quite warrant it at this point. -- Dan White From simon at slimey.org Fri Apr 29 13:51:30 2011 From: simon at slimey.org (Simon Lockhart) Date: Fri, 29 Apr 2011 19:51:30 +0100 Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <21149940.309.1304099331309.JavaMail.root@benjamin.baylink.com> References: <21149940.309.1304099331309.JavaMail.root@benjamin.baylink.com> Message-ID: <20110429185129.GG28613@virtual.bogons.net> On Fri Apr 29, 2011 at 01:48:51PM -0400, Jay Ashworth wrote: > Will they not complain about having their equipment utilization go up > with no recompense -- for something that is only of benefit to commercial > customers of some other entity? Sorry, but are your eyeballs not already paying you for that bandwidth that they are consuming. Multicast merely optimises that across your network. You have 200,000 eyeballs all watching the royal wedding on youtube, at 2Mbps per stream. or You have 200,000 eyeballs all watching the royal wedding on multicast, with no more than one copy of 2Mbps going over each of your backbone links. I know which one I'd prefer. The only place it causes some confusion over charging is if you're the content ISP which is originating the multicast. How do you charge your TV Channel customer? Sure, it won't be 2Mbps at your normal per Mbps rate, but equally it won't be 2Mbps * the number of end users watching the stream. It'll be somewhere in the middle, probably tending far more towards the 2Mbps end. Simon From cscora at apnic.net Fri Apr 29 14:00:59 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 30 Apr 2011 05:00:59 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201104291900.p3TJ0xfq030787@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 30 Apr, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 356141 Prefixes after maximum aggregation: 161025 Deaggregation factor: 2.21 Unique aggregates announced to Internet: 175803 Total ASes present in the Internet Routing Table: 37438 Prefixes per ASN: 9.51 Origin-only ASes present in the Internet Routing Table: 31355 Origin ASes announcing only one prefix: 15082 Transit ASes present in the Internet Routing Table: 5058 Transit-only ASes present in the Internet Routing Table: 135 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 36 Max AS path prepend of ASN (36992) 29 Prefixes from unregistered ASNs in the Routing Table: 584 Unregistered ASNs in the Routing Table: 291 Number of 32-bit ASNs allocated by the RIRs: 1317 Number of 32-bit ASNs visible in the Routing Table: 1025 Prefixes from 32-bit ASNs in the Routing Table: 2298 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 148 Number of addresses announced to Internet: 2420666304 Equivalent to 144 /8s, 72 /16s and 111 /24s Percentage of available address space announced: 65.3 Percentage of allocated address space announced: 65.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 90.6 Total number of prefixes smaller than registry allocations: 147936 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 89082 Total APNIC prefixes after maximum aggregation: 29925 APNIC Deaggregation factor: 2.98 Prefixes being announced from the APNIC address blocks: 85522 Unique aggregates announced from the APNIC address blocks: 36919 APNIC Region origin ASes present in the Internet Routing Table: 4425 APNIC Prefixes per ASN: 19.33 APNIC Region origin ASes announcing only one prefix: 1232 APNIC Region transit ASes present in the Internet Routing Table: 703 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 48 Number of APNIC addresses announced to Internet: 611294496 Equivalent to 36 /8s, 111 /16s and 157 /24s Percentage of available APNIC address space announced: 77.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 140235 Total ARIN prefixes after maximum aggregation: 71231 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 112584 Unique aggregates announced from the ARIN address blocks: 45236 ARIN Region origin ASes present in the Internet Routing Table: 14345 ARIN Prefixes per ASN: 7.85 ARIN Region origin ASes announcing only one prefix: 5478 ARIN Region transit ASes present in the Internet Routing Table: 1492 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 11 Number of ARIN addresses announced to Internet: 799837952 Equivalent to 47 /8s, 172 /16s and 143 /24s Percentage of available ARIN address space announced: 63.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 84054 Total RIPE prefixes after maximum aggregation: 47941 RIPE Deaggregation factor: 1.75 Prefixes being announced from the RIPE address blocks: 77228 Unique aggregates announced from the RIPE address blocks: 51126 RIPE Region origin ASes present in the Internet Routing Table: 15564 RIPE Prefixes per ASN: 4.96 RIPE Region origin ASes announcing only one prefix: 7810 RIPE Region transit ASes present in the Internet Routing Table: 2440 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 36 Number of RIPE region 32-bit ASNs visible in the Routing Table: 760 Number of RIPE addresses announced to Internet: 467574528 Equivalent to 27 /8s, 222 /16s and 159 /24s Percentage of available RIPE address space announced: 75.3 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 32502 Total LACNIC prefixes after maximum aggregation: 7466 LACNIC Deaggregation factor: 4.35 Prefixes being announced from the LACNIC address blocks: 31515 Unique aggregates announced from the LACNIC address blocks: 16536 LACNIC Region origin ASes present in the Internet Routing Table: 1442 LACNIC Prefixes per ASN: 21.86 LACNIC Region origin ASes announcing only one prefix: 427 LACNIC Region transit ASes present in the Internet Routing Table: 261 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 201 Number of LACNIC addresses announced to Internet: 82907136 Equivalent to 4 /8s, 241 /16s and 16 /24s Percentage of available LACNIC address space announced: 54.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7748 Total AfriNIC prefixes after maximum aggregation: 1855 AfriNIC Deaggregation factor: 4.18 Prefixes being announced from the AfriNIC address blocks: 6108 Unique aggregates announced from the AfriNIC address blocks: 1916 AfriNIC Region origin ASes present in the Internet Routing Table: 449 AfriNIC Prefixes per ASN: 13.60 AfriNIC Region origin ASes announcing only one prefix: 135 AfriNIC Region transit ASes present in the Internet Routing Table: 97 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 31 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 5 Number of AfriNIC addresses announced to Internet: 23373568 Equivalent to 1 /8s, 100 /16s and 167 /24s Percentage of available AfriNIC address space announced: 34.8 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2434 9482 904 Korea Telecom (KIX) 17974 1827 515 29 PT TELEKOMUNIKASI INDONESIA 7545 1558 301 84 TPG Internet Pty Ltd 4755 1459 634 167 TATA Communications formerly 7552 1214 1064 7 Vietel Corporation 24560 1158 336 190 Bharti Airtel Ltd., Telemedia 9583 1056 77 492 Sify Limited 4808 1035 2090 294 CNCGROUP IP network: China169 9829 1007 870 50 BSNL National Internet Backbo 17488 944 165 100 Hathway IP Over Cable Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3644 3822 254 bellsouth.net, inc. 4323 2630 1086 397 Time Warner Telecom 1785 1791 681 128 PaeTec Communications, Inc. 18566 1790 349 229 Covad Communications 6478 1658 311 46 AT&T Worldnet Services 20115 1534 1552 641 Charter Communications 19262 1495 4949 298 Verizon Global Networks 7018 1343 6782 886 AT&T WorldNet Services 22773 1300 2865 84 Cox Communications, Inc. 2386 1268 536 911 AT&T Data Communications Serv Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6830 520 1780 322 UPC Distribution Services 34984 509 106 182 BILISIM TELEKOM 3292 457 1997 391 TDC Tele Danmark 29049 450 33 48 AzerSat LLC. 8866 446 134 26 Bulgarian Telecommunication C 20940 442 129 338 Akamai Technologies European 3320 423 7609 368 Deutsche Telekom AG 12479 408 577 6 Uni2 Autonomous System 8551 405 354 47 Bezeq International 702 396 1802 309 UUNET - Commercial IP service Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1448 268 160 TVCABLE BOGOTA 28573 1289 988 87 NET Servicos de Comunicao S.A 8151 1251 2690 369 UniNet S.A. de C.V. 7303 926 467 149 Telecom Argentina Stet-France 6503 852 354 73 AVANTEL, S.A. 14420 665 53 91 CORPORACION NACIONAL DE TELEC 22047 564 310 15 VTR PUNTO NET S.A. 3816 517 226 98 Empresa Nacional de Telecomun 11172 489 99 82 Servicios Alestra S.A de C.V 13489 484 221 116 Orbitel S.A. E.S.P. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 881 445 11 TEDATA 24863 779 147 39 LINKdotNET AS number 15475 421 90 8 Nile Online 36992 299 415 13 Etisalat MISR 3741 267 985 227 The Internet Solution 6713 240 215 13 Itissalat Al-MAGHRIB 24835 211 78 10 RAYA Telecom - Egypt 33776 208 12 10 Starcomms Nigeria Limited 29571 161 17 11 Ci Telecom Autonomous system 16637 149 441 86 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3644 3822 254 bellsouth.net, inc. 4323 2630 1086 397 Time Warner Telecom 4766 2434 9482 904 Korea Telecom (KIX) 23456 2298 658 1255 32-bit ASN transition 17974 1827 515 29 PT TELEKOMUNIKASI INDONESIA 1785 1791 681 128 PaeTec Communications, Inc. 18566 1790 349 229 Covad Communications 6478 1658 311 46 AT&T Worldnet Services 7545 1558 301 84 TPG Internet Pty Ltd 20115 1534 1552 641 Charter Communications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2630 2233 Time Warner Telecom 17974 1827 1798 PT TELEKOMUNIKASI INDONESIA 1785 1791 1663 PaeTec Communications, Inc. 6478 1658 1612 AT&T Worldnet Services 18566 1790 1561 Covad Communications 4766 2434 1530 Korea Telecom (KIX) 7545 1558 1474 TPG Internet Pty Ltd 4755 1459 1292 TATA Communications formerly 10620 1448 1288 TVCABLE BOGOTA 11492 1261 1246 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 45.127.0.0/16 13767 NetworkTwo Communications Gro 62.61.220.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:12 /10:28 /11:77 /12:221 /13:459 /14:790 /15:1386 /16:11667 /17:5753 /18:9651 /19:19182 /20:25623 /21:25636 /22:33862 /23:32708 /24:185857 /25:1132 /26:1317 /27:705 /28:39 /29:8 /30:2 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2245 3644 bellsouth.net, inc. 18566 1758 1790 Covad Communications 6478 1612 1658 AT&T Worldnet Services 10620 1338 1448 TVCABLE BOGOTA 4323 1332 2630 Time Warner Telecom 11492 1210 1261 Cable One 23456 1151 2298 32-bit ASN transition 7011 1062 1161 Citizens Utilities 1785 1059 1791 PaeTec Communications, Inc. 22773 844 1300 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:264 2:51 4:14 5:1 6:3 8:351 12:1987 13:1 14:443 15:15 16:3 17:8 20:9 23:5 24:1613 27:720 31:233 32:60 33:3 34:2 37:1 38:765 40:101 41:2441 42:5 44:3 46:885 47:4 49:171 50:375 52:13 55:5 56:2 57:31 58:840 59:481 60:387 61:1266 62:981 63:1932 64:3956 65:2322 66:4374 67:1868 68:1077 69:2971 70:704 71:346 72:1893 73:1 74:2360 75:298 76:334 77:836 78:678 79:454 80:1092 81:814 82:496 83:461 84:650 85:1080 86:566 87:748 88:322 89:1597 90:183 91:3714 92:512 93:1059 94:1263 95:796 96:478 97:253 98:823 99:35 101:68 103:5 106:1 107:6 108:83 109:941 110:561 111:699 112:320 113:397 114:530 115:685 116:952 117:681 118:809 119:1139 120:306 121:671 122:1623 123:1075 124:1255 125:1220 128:264 129:163 130:172 131:568 132:112 133:19 134:217 135:49 136:214 137:141 138:302 139:106 140:479 141:174 142:400 143:403 144:487 145:52 146:441 147:208 148:591 149:243 150:171 151:187 152:309 153:179 154:3 155:396 156:190 157:353 158:133 159:384 160:314 161:247 162:277 163:164 164:494 165:351 166:511 167:426 168:721 169:153 170:788 171:76 172:1 173:1511 174:535 175:361 177:81 178:851 180:817 181:15 182:436 183:204 184:258 185:1 186:1137 187:810 188:988 189:969 190:4836 192:5789 193:4844 194:3470 195:2974 196:1204 197:16 198:3570 199:3910 200:5522 201:1499 202:8374 203:8448 204:4138 205:2325 206:2749 207:3030 208:3952 209:3472 210:2729 211:1386 212:1968 213:1686 214:736 215:67 216:4879 217:1651 218:563 219:374 220:1202 221:484 222:342 223:145 End of report From jra at baylink.com Fri Apr 29 14:03:47 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 29 Apr 2011 15:03:47 -0400 (EDT) Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <20110429185129.GG28613@virtual.bogons.net> Message-ID: <29538153.351.1304103827319.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Simon Lockhart" > On Fri Apr 29, 2011 at 01:48:51PM -0400, Jay Ashworth wrote: > > Will they not complain about having their equipment utilization go up > > with no recompense -- for something that is only of benefit to > > commercial customers of some other entity? > > Sorry, but are your eyeballs not already paying you for that bandwidth > that they are consuming. Multicast merely optimises that across your > network. > > You have 200,000 eyeballs all watching the royal wedding on youtube, > at 2Mbps per stream. > > or > > You have 200,000 eyeballs all watching the royal wedding on multicast, > with no more than one copy of 2Mbps going over each of your backbone links. > > I know which one I'd prefer. He's the devil, I'm just his advocate. Good. :-) > The only place it causes some confusion over charging is if you're the content > ISP which is originating the multicast. How do you charge your TV Channel > customer? Sure, it won't be 2Mbps at your normal per Mbps rate, but equally it > won't be 2Mbps * the number of end users watching the stream. It'll be > somewhere in the middle, probably tending far more towards the 2Mbps end. Sure; people who supply lots of bandwidth to content providers *now* will probably be unhappy about this idea, but... no business is guaranteed its business model; that observation goes back at *least* to Robert Heinlein's first short story, "Lifeline" from 1954(?)... and I *think* he was quoting Supreme Court Justice Learned Hand, but haven't been able to source it. The real problem I see myself is that *the Mbone has to be pervasive* (or mostly so) for this to be a worthwhile investment for providers. Not to mention it being practical for eyeballs to *get* to it; haven't seen that HOWTO pointer yet from anyone. :-) From joelja at bogus.com Fri Apr 29 14:11:36 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 29 Apr 2011 12:11:36 -0700 Subject: How do you put a TV station on the Mbone? In-Reply-To: <27337170.307.1304097174940.JavaMail.root@benjamin.baylink.com> References: <27337170.307.1304097174940.JavaMail.root@benjamin.baylink.com> Message-ID: <4DBB0D68.40108@bogus.com> On 4/29/11 10:12 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Ryan Malayter" > >> On Apr 28, 11:14 pm, Jay Ashworth wrote: >>>> (cough)multicast(cough) >>> >>> But... but... how do we count the viewers, then? >> >> Isn't the real problem with global multicast: "How do we ultimately >> bill the broadcaster for all that traffic amplification that happened >> *inside* every other AS?" It seems like you'd have to do per-packet >> accounting at every router, and coordinate billing/reporting amongst >> all providers that saw those packets. > > See, now, I expected to hear that objection. > > Internet engineers are prone to try to solve this problem in favor of > the viewer, and their networks -- with their networks winning in case > of a push. > > *Program providers*, OTOH, have a completely different set of "optimal" > parameters -- many of which are directly at odds with that approach, and > most of which are completely ignored by Internet engineering types when > working on this stuff. > > And OTGH, even if, say, a local TV station wanted to let people do this > sort of thing, *the people they get their programs from* -- both at the > Network and the "provider to Network" level -- will expect to have their > own say in the matter. > > *Certainly* there should be a Multicast Cloud, and an easy way for > program providers to dump things into it. But, as you say, who's going > to pay for it is an issue, and how one enforces that is another even > more contentious one. > > Layer 9 is a *bitch*, isn't it? > > So: if I *wanted* to put my video in the multicast cloud... how would > I do it? I do, after all, now work for a TV network which sells things; > this is not an idle question for me: the more people who can see me, > the better. It turns out that as a content provider you can unicast video delivery without coordinating the admission of your content onto every edge eyeball network on the planet. It's cheap enough that it makes money on fairly straght-forward internet business models and it apparently scales to meet the needs of justin beiber fans. From simon at slimey.org Fri Apr 29 14:15:00 2011 From: simon at slimey.org (Simon Lockhart) Date: Fri, 29 Apr 2011 20:15:00 +0100 Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <29538153.351.1304103827319.JavaMail.root@benjamin.baylink.com> References: <20110429185129.GG28613@virtual.bogons.net> <29538153.351.1304103827319.JavaMail.root@benjamin.baylink.com> Message-ID: <20110429191459.GH28613@virtual.bogons.net> On Fri Apr 29, 2011 at 03:03:47PM -0400, Jay Ashworth wrote: > The real problem I see myself is that *the Mbone has to be pervasive* (or > mostly so) for this to be a worthwhile investment for providers. What is missing is an adaptive client (be it flash, or HTML5) which will transparently use multicast if it's available, and otherwise fall back to unicast. I've discussed this many times with IPTV technology providers. Many have agreed that it's a superb solution, but none have delivered. Delivering multicast to end users is fundamentally not hard. The biggest issue seems to be with residential CPE (pretty much the same problem as IPv6, really). Simon From silas at dsminc-corp.com Fri Apr 29 14:23:15 2011 From: silas at dsminc-corp.com (Silas Moeckel) Date: Fri, 29 Apr 2011 15:23:15 -0400 Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <20110429184749.GG8638@dan.olp.net> References: <21149940.309.1304099331309.JavaMail.root@benjamin.baylink.com> <152933.1304100244@localhost> <20110429184749.GG8638@dan.olp.net> Message-ID: <4DBB1023.6060104@dsminc-corp.com> On 4/29/2011 2:47 PM, Dan White wrote: > On 29/04/11 14:04 -0400, Valdis.Kletnieks at vt.edu wrote: >> On Fri, 29 Apr 2011 13:48:51 EDT, Jay Ashworth said: >> What's the break-even point, the number of streams being sent at once >> where >> multicasting it starts taking less resources than N unicast streams? > > Video distribution is bound to continue to go in the direction of > Netflix/Youtube where ISPs are going to be highly motivated to find > cheaper > ways to provide internet content to their end users. And directly peered, > multicast agreements between CDNs and ISPs are going to be a real > quick way > to chop operational costs. Even if that doesn't apply to Netflix content > today, it's bound to matter for content that consumers are going to > want to > consume in real time (sporting events). > > From the perspective of an ISP operating in a small market, we are > seeing a > big shift in usage toward Netflix and netflix-like services that is > necessarily going to change the model of how we provide internet > services. > We have limited access to CDN or Content-Producer peering agreements > (that > would help to save costs) and, even if we did, we're in no position to > demand ingress cash flow in those agreements (not enough eyeballs!). > Since > our users are the ones with the business arrangements with Netflix, > and since > their demand is shifting in that direction, I'd imagine we'd jump at a > chance for private multicast agreements, even if demand didn't quite > warrant it at this point. > Is it all just stalling tactics until IPv6 is everywhere, or am I incorrect that multicast is baked into it rather than tacked on. Unlike the current state of multicast islands were looking at global reach to all IPv6 end points. Even if providers try and stem the flow with AUP's banning sourcing of multicast how many major apps poping up with "you have a valid IPv6 address but multicast is not functioning please contact your ISP as your internet is broken, running at reduced capacity/quality" flooding help desks until ISP's cave in? The only loosers are the ones that were getting paid for transit by the sender, the eyeball networks could well see this as a reduction of backbone utilization Silas From gbonser at seven.com Fri Apr 29 14:27:44 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 29 Apr 2011 12:27:44 -0700 Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <27337170.307.1304097174940.JavaMail.root@benjamin.baylink.com> References: <06999366-411d-41d3-becd-37362dbf6365@e21g2000vbz.googlegroups.com> <27337170.307.1304097174940.JavaMail.root@benjamin.baylink.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E301D@RWC-EX1.corp.seven.com> > From: Jay Ashworth > Sent: Friday, April 29, 2011 10:13 AM > To: NANOG > Subject: How do you put a TV station on the Mbone? (was: Royal > Wedding...) > > ----- Original Message ----- > > From: "Ryan Malayter" > > > On Apr 28, 11:14 pm, Jay Ashworth wrote: > > > > (cough)multicast(cough) > > > > > > But... but... how do we count the viewers, then? > > > > Isn't the real problem with global multicast: "How do we ultimately > > bill the broadcaster for all that traffic amplification that happened > > *inside* every other AS?" It seems like you'd have to do per-packet > > accounting at every router, and coordinate billing/reporting amongst > > all providers that saw those packets. > > See, now, I expected to hear that objection. > > Internet engineers are prone to try to solve this problem in favor of > the viewer, and their networks -- with their networks winning in case > of a push. Should be easy enough on your subscriber ports to use igmp to see who has subscribed to which groups, shouldn't it? Just log igmp changes and there's your accounting. From joly at punkcast.com Fri Apr 29 14:35:08 2011 From: joly at punkcast.com (Joly MacFie) Date: Fri, 29 Apr 2011 15:35:08 -0400 Subject: Amazon diagnosis In-Reply-To: <602316126.1304085701368.JavaMail.nobody@james2> References: <602316126.1304085701368.JavaMail.nobody@james2> Message-ID: *http://aws.amazon.com/message/65648/* ___ -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From jra at baylink.com Fri Apr 29 14:37:04 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 29 Apr 2011 15:37:04 -0400 (EDT) Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E301D@RWC-EX1.corp.seven.com> Message-ID: <4089237.361.1304105824423.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "George Bonser" > > Internet engineers are prone to try to solve this problem in favor of > > the viewer, and their networks -- with their networks winning in case > > of a push. > > Should be easy enough on your subscriber ports to use igmp to see who > has subscribed to which groups, shouldn't it? Just log igmp changes > and there's your accounting. You've conflated my two points. That would tell the *carriers* who's watching what, but they probably don't care. I was talking about *the providers* knowing (think DRM and "3096 viewers online"). Cheers, -- jra From johnl at iecc.com Fri Apr 29 14:44:40 2011 From: johnl at iecc.com (John Levine) Date: 29 Apr 2011 19:44:40 -0000 Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <20110429191459.GH28613@virtual.bogons.net> Message-ID: <20110429194440.36991.qmail@joyce.lan> >Delivering multicast to end users is fundamentally not hard. The >biggest issue seems to be with residential CPE (pretty much the same >problem as IPv6, really). Well, more than that, since I don't really want my DSL pipe saturated with TV that I'm not watching, you need some way for the CPE to tell the ISP "send me stream N" I suppose with some sort of spanning three thing it'd even be posssible to do that at multuple levels, so the streams are only fed to people who have clients for it. R's, John From dmm at 1-4-5.net Fri Apr 29 14:47:46 2011 From: dmm at 1-4-5.net (David Meyer) Date: Fri, 29 Apr 2011 12:47:46 -0700 Subject: [NANOG-announce] NANOG 52 agenda available! In-Reply-To: References: Message-ID: Please see http://nanog.org/meetings/nanog52/agenda.php Look forward to seeing you in Denver. Dave (for the NANOG PC) _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From bonomi at mail.r-bonomi.com Fri Apr 29 14:50:18 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 29 Apr 2011 14:50:18 -0500 (CDT) Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: Message-ID: <201104291950.p3TJoIg3037717@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Fri Apr 29 12:24:21 2011 > Date: Fri, 29 Apr 2011 14:23:23 -0300 > Subject: Re: How do you put a TV station on the Mbone? (was: Royal Wedding...) > From: Rubens Kuhl > To: Nanog > > >> Isn't the real problem with global multicast: "How do we ultimately > >> bill the broadcaster for all that traffic amplification that happened > >> *inside* every other AS?" It seems like you'd have to do per-packet > >> accounting at every router, and coordinate billing/reporting amongst > >> all providers that saw those packets. > > Broadcast encrypted streams. Unicast the key distribution, allowing > interested parties to count, bill, block, allow, litigate, agree... > > > Rubens > From jcurran at arin.net Fri Apr 29 15:07:45 2011 From: jcurran at arin.net (John Curran) Date: Fri, 29 Apr 2011 20:07:45 +0000 Subject: Fwd: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date References: <75E9BD24-F12F-42BF-A989-CF6CC282B28E@arin.net> Message-ID: Transfers of IPv4 address space beginning to heat up. FYI, /John John Curran President and CEO ARIN Begin forwarded message: From: John Curran > Date: April 29, 2011 1:08:49 PM EDT To: Public Policy Mailing List > Subject: [arin-ppml] Statistics regarding NRPM 8.3 Transfers to date To date, there have been 10 completed specified transfers under NRPM 8.3: Distribution of IPv4 Resources transferred: 1 /17 3 /20s 1 /21 1 /23 49 /24s All resources were received under an RSA. None under LRSA. Microsoft transaction not counted in the above (pending close) FYI, /John _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From tdurack at gmail.com Fri Apr 29 15:40:45 2011 From: tdurack at gmail.com (Tim Durack) Date: Fri, 29 Apr 2011 16:40:45 -0400 Subject: How do you put a TV station on the Mbone? In-Reply-To: <4DBB0D68.40108@bogus.com> References: <27337170.307.1304097174940.JavaMail.root@benjamin.baylink.com> <4DBB0D68.40108@bogus.com> Message-ID: On Fri, Apr 29, 2011 at 3:11 PM, Joel Jaeggli wrote: > On 4/29/11 10:12 AM, Jay Ashworth wrote: > > It turns out that as a content provider you can unicast video delivery > without coordinating the admission of your content onto every edge > eyeball network on the planet. It's cheap enough that it makes money on > fairly straght-forward internet business models and it apparently scales > to meet the needs of justin beiber fans. > > Imagine: multicast internet radio! Awesome! I have a feeling streaming is going to stay unicast. Multicast is a great technical solution in search of a good business problem. -- Tim:> From gbonser at seven.com Fri Apr 29 16:16:51 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 29 Apr 2011 14:16:51 -0700 Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <4089237.361.1304105824423.JavaMail.root@benjamin.baylink.com> References: <5A6D953473350C4B9995546AFE9939EE0C9E301D@RWC-EX1.corp.seven.com> <4089237.361.1304105824423.JavaMail.root@benjamin.baylink.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E3022@RWC-EX1.corp.seven.com> > > You've conflated my two points. That would tell the *carriers* who's > watching > what, but they probably don't care. I was talking about *the > providers* > knowing (think DRM and "3096 viewers online"). > > Cheers, > -- jra It would be done the same way it is done currently with cable TV. Who tells CBS how many people are watching? The cable provider knows (or has the capability of knowing with modern digital cable) exactly what channel each cable box is watching at any time. How does a provider of broadcast television know who is watching? They don't, unless the subscriber has a ratings service device at their prem. But if "broadcast" events over the internet are treated the same as "broadcast" events over RF, who cares? From gbonser at seven.com Fri Apr 29 16:17:43 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 29 Apr 2011 14:17:43 -0700 Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <20110429194440.36991.qmail@joyce.lan> References: <20110429191459.GH28613@virtual.bogons.net> <20110429194440.36991.qmail@joyce.lan> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E3023@RWC-EX1.corp.seven.com> > > Well, more than that, since I don't really want my DSL pipe saturated > with TV that I'm not watching, you need some way for the CPE to tell > the ISP "send me stream N" That is what igmp is for. Only send what I specifically request. From gbonser at seven.com Fri Apr 29 16:21:06 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 29 Apr 2011 14:21:06 -0700 Subject: How do you put a TV station on the Mbone? In-Reply-To: References: <27337170.307.1304097174940.JavaMail.root@benjamin.baylink.com><4DBB0D68.40108@bogus.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E3024@RWC-EX1.corp.seven.com> > Imagine: multicast internet radio! Awesome! > > I have a feeling streaming is going to stay unicast. > > Multicast is a great technical solution in search of a good business > problem. > > -- > Tim:> Multicast is perfect for a live event. Unicast is best for "on demand" viewing of something. An event such as today's wedding, a conference viewed in real-time, a sports event, etc. is well-suited for multicast. From jra at baylink.com Fri Apr 29 16:40:59 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 29 Apr 2011 17:40:59 -0400 (EDT) Subject: How do you put a TV station on the Mbone? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E3024@RWC-EX1.corp.seven.com> Message-ID: <16431198.375.1304113259111.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "George Bonser" > Multicast is perfect for a live event. Unicast is best for "on demand" > viewing of something. > > An event such as today's wedding, a conference viewed in real-time, a > sports event, etc. is well-suited for multicast. Great. So, as I asked earlier (as yet unanswered): I have in my hand an NTSC video cable and an XLR with audio. How do I hook that to the mbone? :-) Cheers, -- jra From simon at slimey.org Fri Apr 29 16:47:43 2011 From: simon at slimey.org (Simon Lockhart) Date: Fri, 29 Apr 2011 22:47:43 +0100 Subject: How do you put a TV station on the Mbone? In-Reply-To: <16431198.375.1304113259111.JavaMail.root@benjamin.baylink.com> References: <5A6D953473350C4B9995546AFE9939EE0C9E3024@RWC-EX1.corp.seven.com> <16431198.375.1304113259111.JavaMail.root@benjamin.baylink.com> Message-ID: <20110429214742.GI28613@virtual.bogons.net> On Fri Apr 29, 2011 at 05:40:59PM -0400, Jay Ashworth wrote: > Great. So, as I asked earlier (as yet unanswered): > > I have in my hand an NTSC video cable and an XLR with audio. How do I hook > that to the mbone? :-) Simple. Go get yourself an encoder - VBrick, Envivio, Tandberg, etc, etc - there's plenty out there, take your pick. That'll take video + audio as an input, and output the encoded video (typically MPEG-2 or H.264 in an MPEG-2 transport stream) as multicast. Hook that into your favourite ISP that supports global multicast (several of the tier-1's do), and you're all done. Simon From alvarezp at alvarezp.ods.org Fri Apr 29 16:46:23 2011 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Fri, 29 Apr 2011 14:46:23 -0700 Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <21149940.309.1304099331309.JavaMail.root@benjamin.baylink.com> References: <21149940.309.1304099331309.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, 29 Apr 2011 10:48:51 -0700, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Rubens Kuhl" > > And that's the snap answer, yes. But the *load*, while admittedly > lessened over unicast, falls *mostly* to the carriers, who cannot anymore > bill for it, either to end users, providers, *or* as transit. > > Will they not complain about having their equipment utilization go up > with no recompense -- for something that is only of benefit to commercial > customers of some other entity? Why would they bill someone for a service they are already providing? So the first user in a router tunes to a multicast stream. Consumption for the ISP and all the routers in the chain to the source: same as if it were a unicast stream. Then a second user tunes to a multicast stream. Cost for the ISP: zero. So 5000 users connect each to a different multicast source. It is the same as if they all used unicast. The utilization can never be worse than a unicast-only network. So maybe I'm oversimplifying, but I fail to see a problem, only an artificial one created for the sake of it. Other than the potencial CPU load of the routing protocol, I even fail to see the commercial value of not providing multicast. From jra at baylink.com Fri Apr 29 16:47:47 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 29 Apr 2011 17:47:47 -0400 (EDT) Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: Message-ID: <14591308.379.1304113667625.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Octavio Alvarez" > So maybe I'm oversimplifying, but I fail to see a problem, only an > artificial one created for the sake of it. Other than the potencial > CPU load of the routing protocol, I even fail to see the commercial value > of not providing multicast. Yup: that's what the Content Industry does: invents problems just for the sake of it. Cheers, -- jra From jra at baylink.com Fri Apr 29 16:49:11 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 29 Apr 2011 17:49:11 -0400 (EDT) Subject: How do you put a TV station on the Mbone? In-Reply-To: <20110429214742.GI28613@virtual.bogons.net> Message-ID: <12986904.381.1304113751693.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Simon Lockhart" > > I have in my hand an NTSC video cable and an XLR with audio. How do > > I hook that to the mbone? :-) > > Simple. > > Go get yourself an encoder - VBrick, Envivio, Tandberg, etc, etc - there's > plenty out there, take your pick. That'll take video + audio as an input, and > output the encoded video (typically MPEG-2 or H.264 in an MPEG-2 transport > stream) as multicast. > > Hook that into your favourite ISP that supports global multicast > (several of the tier-1's do), and you're all done. Really. It's that trivial? Ok. Cool. Anyone know if Road Runner's one of those? And how do viewers watch it? Cheers, -- jra From jra at baylink.com Fri Apr 29 16:51:25 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 29 Apr 2011 17:51:25 -0400 (EDT) Subject: How do you put a TV station on the Mbone? In-Reply-To: Message-ID: <4934657.385.1304113885537.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Tim Durack" > Imagine: multicast internet radio! Awesome! That would, indeed, be awesome; when everyone in my office was listening to the royal wedding, there would be a *much* higher chance of them all being in sync. Cheers, -- jra From cidr-report at potaroo.net Fri Apr 29 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 Apr 2011 22:00:00 GMT Subject: BGP Update Report Message-ID: <201104292200.p3TM00ZR077156@wattle.apnic.net> BGP Update Report Interval: 21-Apr-11 -to- 28-Apr-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS19743 32039 1.6% 4577.0 -- 2 - AS9829 21443 1.1% 21.3 -- BSNL-NIB National Internet Backbone 3 - AS17974 18475 0.9% 10.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 4 - AS27738 17261 0.9% 50.9 -- Ecuadortelecom S.A. 5 - AS32528 17148 0.9% 2143.5 -- ABBOTT Abbot Labs 6 - AS11492 16263 0.8% 12.8 -- CABLEONE - CABLE ONE, INC. 7 - AS7633 15307 0.8% 75.4 -- SOFTNET-AS-AP Software Technology Parks of India - Bangalore 8 - AS44609 12851 0.7% 4283.7 -- FNA Fars News Agency Cultural Arts Institute 9 - AS11992 12773 0.7% 28.8 -- CENTENNIAL-PR - Centennial de Puerto Rico 10 - AS6389 12491 0.6% 3.4 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 11 - AS14420 12464 0.6% 18.7 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 12 - AS9498 12311 0.6% 15.3 -- BBIL-AP BHARTI Airtel Ltd. 13 - AS7552 12111 0.6% 9.8 -- VIETEL-AS-AP Vietel Corporation 14 - AS35931 12078 0.6% 2013.0 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 15 - AS45595 10417 0.5% 28.8 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 16 - AS7545 10168 0.5% 11.6 -- TPG-INTERNET-AP TPG Internet Pty Ltd 17 - AS4323 9856 0.5% 3.7 -- TWTC - tw telecom holdings, inc. 18 - AS28573 9549 0.5% 7.3 -- NET Servicos de Comunicao S.A. 19 - AS5800 9478 0.5% 50.7 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 20 - AS24560 9088 0.5% 7.8 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS19743 32039 1.6% 4577.0 -- 2 - AS44609 12851 0.7% 4283.7 -- FNA Fars News Agency Cultural Arts Institute 3 - AS32528 17148 0.9% 2143.5 -- ABBOTT Abbot Labs 4 - AS35931 12078 0.6% 2013.0 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - AS49600 1355 0.1% 1355.0 -- LASEDA La Seda de Barcelona, S.A 6 - AS9270 2989 0.1% 597.8 -- APAN-KR-AS Asia Pacific Advanced Network Korea(APAN-KR) Consortium 7 - AS23364 597 0.0% 597.0 -- SECOTOOLS-US - Seco Tools Inc. 8 - AS12732 2169 0.1% 542.2 -- GUTCON-NET GutCon GmbH 9 - AS3 385 0.0% 735.0 -- NETCKRACKER-AS NETCKRACKER Ltd 10 - AS18704 3755 0.2% 375.5 -- T-SYSTEM - T-SYSTEMS INC. 11 - AS5966 375 0.0% 375.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 12 - AS23310 697 0.0% 348.5 -- TASTYLIME - TASTY LIME 13 - AS48349 306 0.0% 306.0 -- SICE-IT-AS JSC "Siberian Interbank Currency Exchange - Information Technologies" 14 - AS24801 902 0.1% 300.7 -- monarch 15 - AS722 2675 0.1% 297.2 -- DNIC-ASBLK-00721-00726 - DoD Network Information Center 16 - AS9476 294 0.0% 294.0 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd. 17 - AS38757 512 0.0% 256.0 -- ICONPLN-ID-AP PT. Indonesia Comnets Plus 18 - AS50324 250 0.0% 250.0 -- ORCO-GSG GSG Asset GmbH & Co. Verwaltungs KG 19 - AS56453 245 0.0% 245.0 -- SMA Panajotis Tolatzis trading as "Secure Media Associates" 20 - AS33362 2929 0.1% 244.1 -- WIKTEL-NET - Wikstrom Telephone Company, Incorporated TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 130.36.35.0/24 8563 0.4% AS32528 -- ABBOTT Abbot Labs 2 - 130.36.34.0/24 8560 0.4% AS32528 -- ABBOTT Abbot Labs 3 - 202.92.235.0/24 8006 0.3% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 4 - 63.211.68.0/22 7021 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - 203.190.151.0/24 6980 0.3% AS7633 -- SOFTNET-AS-AP Software Technology Parks of India - Bangalore 6 - 203.129.236.0/24 6478 0.3% AS7633 -- SOFTNET-AS-AP Software Technology Parks of India - Bangalore 7 - 178.22.79.0/24 6431 0.3% AS44609 -- FNA Fars News Agency Cultural Arts Institute 8 - 178.22.72.0/21 6403 0.3% AS44609 -- FNA Fars News Agency Cultural Arts Institute 9 - 65.122.196.0/24 6331 0.3% AS19743 -- 10 - 221.121.96.0/19 6041 0.3% AS7491 -- PI-PH-AS-AP PI-PHILIPINES 11 - 65.162.204.0/24 5143 0.2% AS19743 -- 12 - 65.163.182.0/24 5143 0.2% AS19743 -- 13 - 66.238.91.0/24 5142 0.2% AS19743 -- 14 - 66.89.98.0/24 5141 0.2% AS19743 -- 15 - 72.164.144.0/24 5137 0.2% AS19743 -- 16 - 208.54.82.0/24 4891 0.2% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 17 - 198.140.43.0/24 4864 0.2% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 18 - 68.65.152.0/22 3763 0.2% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 19 - 64.43.0.0/16 3727 0.2% AS18704 -- T-SYSTEM - T-SYSTEMS INC. 20 - 202.153.174.0/24 3626 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Apr 29 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 Apr 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201104292200.p3TM00r9077151@wattle.apnic.net> This report has been generated at Fri Apr 29 21:12:19 2011 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 22-04-11 358888 210678 23-04-11 359100 210025 24-04-11 359043 210099 25-04-11 359109 210322 26-04-11 359153 210508 27-04-11 359331 210252 28-04-11 359218 210513 29-04-11 359398 210638 AS Summary 37536 Number of ASes in routing system 15812 Number of ASes announcing only one prefix 3646 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 110422528 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 29Apr11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 359485 210619 148866 41.4% All ASes AS6389 3646 261 3385 92.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2622 401 2221 84.7% TWTC - tw telecom holdings, inc. AS4766 2434 915 1519 62.4% KIXS-AS-KR Korea Telecom AS6478 1658 175 1483 89.4% ATT-INTERNET3 - AT&T Services, Inc. AS10620 1448 231 1217 84.0% Telmex Colombia S.A. AS22773 1300 93 1207 92.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS19262 1495 298 1197 80.1% VZGNI-TRANSIT - Verizon Online LLC AS18566 1790 663 1127 63.0% COVAD - Covad Communications Co. AS4755 1459 376 1083 74.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1215 142 1073 88.3% VIETEL-AS-AP Vietel Corporation AS1785 1794 764 1030 57.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1289 416 873 67.7% NET Servicos de Comunicao S.A. AS24560 1158 339 819 70.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7545 1561 764 797 51.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 935 145 790 84.5% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8151 1248 524 724 58.0% Uninet S.A. de C.V. AS4808 1038 333 705 67.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS3356 1128 462 666 59.0% LEVEL3 Level 3 Communications AS7303 927 264 663 71.5% Telecom Argentina S.A. AS17488 944 312 632 66.9% HATHWAY-NET-AP Hathway IP Over Cable Internet AS11492 1261 636 625 49.6% CABLEONE - CABLE ONE, INC. AS17676 660 70 590 89.4% GIGAINFRA Softbank BB Corp. AS855 635 57 578 91.0% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS6503 853 277 576 67.5% Axtel, S.A.B. de C.V. AS14420 665 104 561 84.4% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS3549 948 400 548 57.8% GBLX Global Crossing Ltd. AS22047 564 30 534 94.7% VTR BANDA ANCHA S.A. AS4780 718 188 530 73.8% SEEDNET Digital United Inc. AS22561 863 341 522 60.5% DIGITAL-TELEPORT - Digital Teleport Inc. AS17974 1826 1329 497 27.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia Total 40082 11310 28772 71.8% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 24.48.0.0/14 AS5769 VIDEOTRON - Videotron Telecom Ltee 24.225.128.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/23 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.224.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.237.0/24 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.248.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 31.200.248.0/21 AS45005 GORIZONT-YAROSLAVL-AS Gorizont LTD 31.204.128.0/19 AS49544 INTERACTIVE3D-AS Interactive3D 31.205.0.0/16 AS41230 ASK4 Ask4 Limited 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 45.127.0.0/16 AS13767 DBANK - DataBank Holdings, Ltd. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.171.32.0/20 AS16626 GNAXNET-AS - Global Net Access, LLC 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.22.32.0/19 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 181.82.15.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.16.0/24 AS23982 SENDB-AS-KR Dongbu District Office of Education in Seoul 181.82.17.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 181.82.18.0/24 AS38418 SENSD-AS-KR seoul seondong district office of education 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.145.251.0/24 AS10026 PACNET Pacnet Global Ltd 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.33.84.0/22 AS9911 CONNECTPLUS-AP Singapore Telecom 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.24.73.0/24 AS26061 Equant Colombia 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 203.190.32.0/22 AS24564 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.105.192.0/23 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.105.196.0/23 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.105.200.0/21 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From gbonser at seven.com Fri Apr 29 17:06:11 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 29 Apr 2011 15:06:11 -0700 Subject: How do you put a TV station on the Mbone? In-Reply-To: <16431198.375.1304113259111.JavaMail.root@benjamin.baylink.com> References: <5A6D953473350C4B9995546AFE9939EE0C9E3024@RWC-EX1.corp.seven.com> <16431198.375.1304113259111.JavaMail.root@benjamin.baylink.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E3026@RWC-EX1.corp.seven.com> > Great. So, as I asked earlier (as yet unanswered): > > I have in my hand an NTSC video cable and an XLR with audio. How do I > hook > that to the mbone? :-) > > Cheers, > -- jra Might want to ask the folks at Silicon Valley Linux Users group, they used to broadcast their meetings on the mbone, not sure if they do anymore. Maybe use google a little: http://sitka.triumf.ca/pub/mbone/uclambone-faq.html You should be able to find enough to get you started. From gbonser at seven.com Fri Apr 29 17:15:42 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 29 Apr 2011 15:15:42 -0700 Subject: How do you put a TV station on the Mbone? In-Reply-To: <4934657.385.1304113885537.JavaMail.root@benjamin.baylink.com> References: <4934657.385.1304113885537.JavaMail.root@benjamin.baylink.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E3027@RWC-EX1.corp.seven.com> > > > Imagine: multicast internet radio! Awesome! > > That would, indeed, be awesome; when everyone in my office was > listening to > the royal wedding, there would be a *much* higher chance of them all > being > in sync. > > Cheers, > -- jra Exactly. If more people/networks took advantage of multicast, it would greatly reduce the bandwidth requirements, particularly for live events. If there were 50 people listening to a popular radio show or watching a live TV event in your office, for example, there would be only one feed crossing the wire into your office. And only one feed crossing into your provider's network. I have *no* idea why applications developers have not been more interested in this, particularly with radio and television stations providing live streams on the net. It is absolutely a waste of resources to have a separate stream for each listener of a live event. The mobile networks are more up to speed in this regard. Verizon Vcast is probably the largest implementation that I know of. From jra at baylink.com Fri Apr 29 17:23:28 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 29 Apr 2011 18:23:28 -0400 (EDT) Subject: RoadRunner Tampa Bay - IP Multicast enabled? Message-ID: <21503746.393.1304115808154.JavaMail.root@benjamin.baylink.com> Is it on the Mbone? Replies off-list please, if you are certain either way. Cheers, -- jra From drais at icantclick.org Fri Apr 29 17:34:26 2011 From: drais at icantclick.org (david raistrick) Date: Fri, 29 Apr 2011 18:34:26 -0400 (EDT) Subject: How do you put a TV station on the Mbone? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E3027@RWC-EX1.corp.seven.com> References: <4934657.385.1304113885537.JavaMail.root@benjamin.baylink.com> <5A6D953473350C4B9995546AFE9939EE0C9E3027@RWC-EX1.corp.seven.com> Message-ID: On Fri, 29 Apr 2011, George Bonser wrote: > Exactly. If more people/networks took advantage of multicast, it would > greatly reduce the bandwidth requirements, particularly for live events. > If there were 50 people listening to a popular radio show or watching a 1) As a consumer network (enterprise, home) - that case is VERY rare. 50 people consuming it at your house? Or at the office consuming the same feed? (even at a 10k employee company, the rate of that is fairly low, particularly on the same leg of the network - I'd love to see some statistics that prove me wrong). The amount of work that goes into supporting and maintaining this is much higher than the return I'd get from it. Even assuming the upstreams supported it. 2) as a content provider, there's a lot of extra work involved to maintain this with my upstreams, and every mid-stream between me at the consumer networks. I require specialists in multicast (comparatively speaking unicast specialists are a dime a dozen) and I have to fight a lot of politics with the upstreams, and I -still- have to support the unicast models so the folks who can't consume multicast can see my content. 3) as an a midstream network provider I have almost no motivation to support this. Sure, my network usage would be reduced - but I (more or less simplified here, but) make my living on each bit of traffic I carry - if I offered a way for providers and consumers to reduce their traffic, that would reduce the amount they pay me. Win for them, lose for me. the fact of the matter is that until multicast or it's like -doesn't- require massive end-to-end support (and frequently configuration to support each stream), there won't be heavy use of it. When I can turn up a multicast stream as easily as I can turn up a unicast stream, there is -still- a absolute lack of client-side software to recieve and playback the streams, and very limited support for broadcasting the streams. ...david (one time multicast specialist supporting a 200,000 seat 4 channel multicast infrastructure, so I'm fully aware of what magic is really involved in maintaining it across divergent networks that -WE- owned (or could exercise control of). before that streaming 40Gb/s (~200 channels of unicast video for general consumers + on demand streams) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From jra at baylink.com Fri Apr 29 17:40:18 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 29 Apr 2011 18:40:18 -0400 (EDT) Subject: How do you put a TV station on the Mbone? In-Reply-To: Message-ID: <22260358.397.1304116818150.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "david raistrick" > 1) As a consumer network (enterprise, home) - that case is VERY rare. > 50 people consuming it at your house? Or at the office consuming the same > feed? (even at a 10k employee company, the rate of that is fairly low, > particularly on the same leg of the network - I'd love to see some > statistics that prove me wrong). The amount of work that goes into > supporting and maintaining this is much higher than the return I'd get > from it. Even assuming the upstreams supported it. I'd expect it to be fairly common at colleges; possibly in companies, depending on the content being watched: live news events are the most common example -- igmp aware viewer clients (which would bias towaards this by showing the already running feeds) would also help. > 2) as a content provider, there's a lot of extra work involved towards > maintain this with my upstreams, and every mid-stream between me at the > consumer networks. I require specialists in multicast (comparatively speaking > unicast specialists are a dime a dozen) and I have to fight a lot of > politics with the upstreams, and I -still- have to support the unicast > models so the folks who can't consume multicast can see my content. Is it still this fragile in 2011? > 3) as an a midstream network provider I have almost no motivation to > support this. Sure, my network usage would be reduced - but I (more or > less simplified here, but) make my living on each bit of traffic I carry - > if I offered a way for providers and consumers to reduce their traffic, > that would reduce the amount they pay me. Win for them, lose for me. americafree.tv has a list, compiled (I think) by Marhsall Eubanks, that lists ISPs and backbones with a formal positive position on this. Be fun to put you two in a room together. :-) > the fact of the matter is that until multicast or it's like -doesn't- > require massive end-to-end support (and frequently configuration to > support each stream), there won't be heavy use of it. When I can turn > up a multicast stream as easily as I can turn up a unicast stream, > there is -still- a absolute lack of client-side software to recieve and > playback the streams, and very limited support for broadcasting the streams. Clearly, there's not an *absolute* lack, or people wouldn't be using it for anything anywhere ever, which they demonstrably are. I should think that given Flowplayer, there's a pretty good platform for implementing such a player in the environment in which program providers would want to use it... though I'm not intimately familiar with its code. > ...david (one time multicast specialist supporting a 200,000 seat 4 > channel multicast infrastructure, so I'm fully aware of what magic is > really involved in maintaining it across divergent networks that -WE- > owned (or could exercise control of). before that streaming 40Gb/s > (~200 channels of unicast video for general consumers + on demand streams) And you haven't written the O'Reilly book yet... why? :-) Thanks for the input, David. Cheers, -- jra From drais at icantclick.org Fri Apr 29 18:01:47 2011 From: drais at icantclick.org (david raistrick) Date: Fri, 29 Apr 2011 19:01:47 -0400 (EDT) Subject: How do you put a TV station on the Mbone? In-Reply-To: <22260358.397.1304116818150.JavaMail.root@benjamin.baylink.com> References: <22260358.397.1304116818150.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, 29 Apr 2011, Jay Ashworth wrote: > I'd expect it to be fairly common at colleges; possibly in companies, ok, colleges I can buy. > Is it still this fragile in 2011? It was in 2009, anyway. > And you haven't written the O'Reilly book yet... why? :-) Because it's not an experience I care to repeat. ;-) Today, I make video games. MUCH more fun! (who knew, content CAN be fun) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From dr at cluenet.de Fri Apr 29 18:44:05 2011 From: dr at cluenet.de (Daniel Roesen) Date: Sat, 30 Apr 2011 01:44:05 +0200 Subject: How do you put a TV station on the Mbone? In-Reply-To: <4934657.385.1304113885537.JavaMail.root@benjamin.baylink.com> References: <4934657.385.1304113885537.JavaMail.root@benjamin.baylink.com> Message-ID: <20110429234405.GA31563@srv03.cluenet.de> On Fri, Apr 29, 2011 at 05:51:25PM -0400, Jay Ashworth wrote: > > Imagine: multicast internet radio! Awesome! > > That would, indeed, be awesome; when everyone in my office was listening to > the royal wedding, there would be a *much* higher chance of them all being > in sync. That reminds me of 9/11. When the tragic event unfolded, we sat in the office. News made the rounds verbally, and people started looking for streaming services at their personal desks (no TVs around). People pretty quickly gave up trying to find streams and news portals which were actually working fine and the crowd gathering behind me watching over my shoulder became bigger and bigger. Why? Because I was in the fortunate position of being able to watch an Mbone multicast stream of some news TV broadcaster... cannot remember wether it was CNN or BBC or someone else entirely. Back then, a collegue was playing around with IP multicast and my desktop machine had connectivity to his Mbone-connected playground. :) IP multicast was the only way for us to see what happened, live. Unicast failed miserably. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From millnert at gmail.com Fri Apr 29 19:01:37 2011 From: millnert at gmail.com (Martin Millnert) Date: Fri, 29 Apr 2011 20:01:37 -0400 Subject: How do you put a TV station on the Mbone? In-Reply-To: <20110429234405.GA31563@srv03.cluenet.de> References: <4934657.385.1304113885537.JavaMail.root@benjamin.baylink.com> <20110429234405.GA31563@srv03.cluenet.de> Message-ID: Daniel, On Fri, Apr 29, 2011 at 7:44 PM, Daniel Roesen wrote: > On Fri, Apr 29, 2011 at 05:51:25PM -0400, Jay Ashworth wrote: >> > Imagine: multicast internet radio! Awesome! >> >> That would, indeed, be awesome; when everyone in my office was listening to >> the royal wedding, there would be a *much* higher chance of them all being >> in sync. > > That reminds me of 9/11. When the tragic event unfolded, we sat in the > office. News made the rounds verbally, and people started looking for > streaming services at their personal desks (no TVs around). People > pretty quickly gave up trying to find streams and news portals which were > actually working fine and the crowd gathering behind me watching over my > shoulder became bigger and bigger. > > Why? Because I was in the fortunate position of being able to watch an > Mbone multicast stream of some news TV broadcaster... cannot remember > wether it was CNN or BBC or someone else entirely. Back then, a collegue > was playing around with IP multicast and my desktop machine had connectivity > to his Mbone-connected playground. :) > > IP multicast was the only way for us to see what happened, live. > Unicast failed miserably. +10 I've been meaning to write something similar. Multicast infrastructure in place absolutely and certainly has a role to play in "humanity-wide" events. Also, having a 'free' distribution channel for those moving images carrying such licensing that it does not matter how many eyeballs see them, could be valuable as well. I made sure to get this capability in the network I worked on last. Cheers, Martin From jared at puck.nether.net Fri Apr 29 19:42:49 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 29 Apr 2011 20:42:49 -0400 Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <20110429194440.36991.qmail@joyce.lan> References: <20110429194440.36991.qmail@joyce.lan> Message-ID: On Apr 29, 2011, at 3:44 PM, John Levine wrote: >> Delivering multicast to end users is fundamentally not hard. The >> biggest issue seems to be with residential CPE (pretty much the same >> problem as IPv6, really). > > Well, more than that, since I don't really want my DSL pipe saturated > with TV that I'm not watching, you need some way for the CPE to tell > the ISP "send me stream N" There are CPEs that do this, but some don't do it on a public IP network. Additionally, considering the state of the home CPE market and how horrible it is, I doubt it will get better anytime soon. You have to look no further than the copious numbers of "IPv6 Ready" devices on the shelves in stores today. Oh, and the fact that the NAT on the v4 side breaks multicast. > I suppose with some sort of spanning three thing it'd even be posssible > to do that at multuple levels, so the streams are only fed to people > who have clients for it. This is what IGMP+PIM already do, sometimes with layer-2 support from switches, sometimes not, all depends on your topology. - Jared From jared at puck.nether.net Fri Apr 29 19:46:22 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 29 Apr 2011 20:46:22 -0400 Subject: How do you put a TV station on the Mbone? In-Reply-To: References: <27337170.307.1304097174940.JavaMail.root@benjamin.baylink.com> <4DBB0D68.40108@bogus.com> Message-ID: <8BA5FFDC-871A-4DB5-9B94-FD960B8E20BF@puck.nether.net> On Apr 29, 2011, at 4:40 PM, Tim Durack wrote: > On Fri, Apr 29, 2011 at 3:11 PM, Joel Jaeggli wrote: >> On 4/29/11 10:12 AM, Jay Ashworth wrote: >> >> It turns out that as a content provider you can unicast video delivery >> without coordinating the admission of your content onto every edge >> eyeball network on the planet. It's cheap enough that it makes money on >> fairly straght-forward internet business models and it apparently scales >> to meet the needs of justin beiber fans. >> >> > > Imagine: multicast internet radio! Awesome! > > I have a feeling streaming is going to stay unicast. > > Multicast is a great technical solution in search of a good business problem. I think this is sadly the truth. There are some problems that can be solved by multicast, but I've seen the number of customer requests for v4 multicast go by the wayside over the years. The only people that are generally interested are the conference venues for technical things, e.g.: RIPE, ARIN/NANOG, APRICOT, etc. Plus, conferences like NANOG have beamed the video back to some other site for fanout as well, for both unicast and multicast. The problems at Layer7 and below are solvable with market forces. They're all 8/9 issues, about the content providers wanting to be paid-per-subscriber/viewer. They don't want to know how few people are actually tuned in at that moment in some cases. I'm sure they want to be paid some fraction of that cost that goes to your TV Transport conduit provider. - Jared (who buys and downloads shows, and pays nothing for others as they come OTA "free") From jared at puck.nether.net Fri Apr 29 19:53:22 2011 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 29 Apr 2011 20:53:22 -0400 Subject: How do you put a TV station on the Mbone? In-Reply-To: <20110429234405.GA31563@srv03.cluenet.de> References: <4934657.385.1304113885537.JavaMail.root@benjamin.baylink.com> <20110429234405.GA31563@srv03.cluenet.de> Message-ID: On Apr 29, 2011, at 7:44 PM, Daniel Roesen wrote: > > IP multicast was the only way for us to see what happened, live. > Unicast failed miserably. > I'll say that today with some providers offering streaming to customers iPad and other types of devices, the problem isn't the capacity to the home, nor is it really a concern for them. It clearly doesn't matter if it's switched video, IPTV, or some RF. All the problems that have made the news are about rights holders saying "this violates our contract" of some sort. I'm sure it will be solved, and the internet will just become another transport medium, like RF over Coax or RF-OTA or IPTV/Uverse/FiOS or maybe soon just some standard RJ45/IEEE handoff with mac registration just like you have to register a digital STB with the head-end. I suspect in the next 15 years the concept of broadcast TV handoff to the consumer will change again. Hope everyone is ready for your television firmware and malware. - Jared From bonomi at mail.r-bonomi.com Fri Apr 29 19:57:42 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 29 Apr 2011 19:57:42 -0500 (CDT) Subject: How do you put a TV station on the Mbone? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E3027@RWC-EX1.corp.seven.com> Message-ID: <201104300057.p3U0vgg2039413@mail.r-bonomi.com> > Subject: RE: How do you put a TV station on the Mbone? > Date: Fri, 29 Apr 2011 15:15:42 -0700 > From: George Bonser > > > > > > Imagine: multicast internet radio! Awesome! > > > > That would, indeed, be awesome; when everyone in my office was > > listening to the royal wedding, there would be a *much* higher chance > > of them all being in sync. > > > > Cheers, > > -- jra > > Exactly. If more people/networks took advantage of multicast, it would > greatly reduce the bandwidth requirements, particularly for live events. > If there were 50 people listening to a popular radio show or watching a > live TV event in your office, for example, there would be only one feed > crossing the wire into your office. And only one feed crossing into your > provider's network. > > I have *no* idea why applications developers have not been more > interested in this, particularly with radio and television stations > providing live streams on the net. It is absolutely a waste of resources > to have a separate stream for each listener of a live event. There's a layer 9 (or is it 10? -- required for legal reasons) answer for that. Radio/television stations are required to pay 'performance' royalties to the 'authors' and 'performers' of the works they transmit over the internet. Those royalties are based on the _actual_number_ of persons tuning in to each such work. No 'averaging', no 'estimating', nothing based on 'ratings', or other 'sampling techniques -- you have to count the _actual_number_ of people tuned in. It gets messy, but you have to have 'auditable' records of when each person 'tuned in', and when they 'tuned out'. One _has_ to be able to detect the latter condition under all possible circumstances. This means you must use a 'loss of signal' methodology. You can't trust the tuned-in listener to _actually_ stop listening "just because" they said they would. The people getting the royalties will claim the tuned-in party lied, and they're due royalties even after they said they're tuning out. The people _paying_ the fees won't accept having to pay for people who 'tuned out' in 'non-standard' ways. Ways like a program (or O/S, for that matter) crash, 'backhoe fade, etc. One party worries about people -not- tuning out when they said they are. The other worries about people tuning out -without- saying they are. The only to keep both sides happy is to use a methodology that is not subject to either 'failure' mode. This means a unique 'virtual circuit' (aka data stream) to each user. From saku at ytti.fi Sat Apr 30 01:14:39 2011 From: saku at ytti.fi (Saku Ytti) Date: Sat, 30 Apr 2011 09:14:39 +0300 Subject: How do you put a TV station on the Mbone? In-Reply-To: References: <4934657.385.1304113885537.JavaMail.root@benjamin.baylink.com> <5A6D953473350C4B9995546AFE9939EE0C9E3027@RWC-EX1.corp.seven.com> Message-ID: <20110430061439.GA23911@pob.ytti.fi> On (2011-04-29 18:34 -0400), david raistrick wrote: > 3) as an a midstream network provider I have almost no motivation to > support this. Sure, my network usage would be reduced - but I (more > or less simplified here, but) make my living on each bit of traffic > I carry - if I offered a way for providers and consumers to reduce > their traffic, that would reduce the amount they pay me. Win for > them, lose for me. Aye. I'm always flabbergasted people complaining how other people should see the light and start to support multicast so we could reduce global bandwidth consumption. But multicast does not scale to global use, biggest problem is that for a router multicast is like flow switching, every flow you need to program in hardware. This means we'd need to regulate how and who can establish global multicast flow, which would unavoidably be unfair to some people. Second problem is security, random Internet user cannot change state in your routers today (except edge router ARP, which already is exploitable security problem), with multicast they can cause state to be changed in whole Internet. You need to be able to limit how many groups port can join, how fast port can join/leave per second, what groups port can join, same requirement is true for MSDP peers. It gets quite complex, quite fast, and these filters should be hardware based. We still regularly have security issues in BGP, it would be extremely unlikely if multicast didn't have lot of crash-Internet potential, due to end users ability to add/remove states from the core. Multicast has been and continues today to be solution for enterprise/application specific problems in closed domain and of course academic interest. If we actually want to reduce global bandwidth consumption, we need protocol which is stateless at least in in core. -- ++ytti From young at jsyoung.net Sat Apr 30 04:13:09 2011 From: young at jsyoung.net (Jeffrey S. Young) Date: Sat, 30 Apr 2011 19:13:09 +1000 Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <20110429194440.36991.qmail@joyce.lan> References: <20110429194440.36991.qmail@joyce.lan> Message-ID: <8E003447-CA2C-4B63-B363-CF30BE5230A1@jsyoung.net> On 30/04/2011, at 5:44 AM, "John Levine" wrote: >> Delivering multicast to end users is fundamentally not hard. The >> biggest issue seems to be with residential CPE (pretty much the same >> problem as IPv6, really). > > Well, more than that, since I don't really want my DSL pipe saturated > with TV that I'm not watching, you need some way for the CPE to tell > the ISP "send me stream N" > > I suppose with some sort of spanning three thing it'd even be posssible > to do that at multuple levels, so the streams are only fed to people > who have clients for it. > > R's, > John Or your set top box... multicast joins from STB to DSLAM aren't so hard. AT&T U-Verse has been doing it for more than five years now. jy From lowen at pari.edu Sat Apr 30 08:48:45 2011 From: lowen at pari.edu (Lamar Owen) Date: Sat, 30 Apr 2011 09:48:45 -0400 Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <4089237.361.1304105824423.JavaMail.root@benjamin.baylink.com> References: <4089237.361.1304105824423.JavaMail.root@benjamin.baylink.com> Message-ID: <201104300948.46165.lowen@pari.edu> On Friday, April 29, 2011 03:37:04 PM Jay Ashworth wrote: > You've conflated my two points. That would tell the *carriers* who's watching > what, but they probably don't care. I was talking about *the providers* > knowing (think DRM and "3096 viewers online"). And then if there's music, the SoundExchange rules......to be 'legal' you have to count 'performances' and file forms with information on performances, and pull out the information on the work performed.....preferably with ISRC information. From lowen at pari.edu Sat Apr 30 08:50:43 2011 From: lowen at pari.edu (Lamar Owen) Date: Sat, 30 Apr 2011 09:50:43 -0400 Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E3022@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0C9E301D@RWC-EX1.corp.seven.com> Message-ID: <201104300950.43489.lowen@pari.edu> On Friday, April 29, 2011 05:16:51 PM George Bonser wrote: > But if "broadcast" events over the internet are treated the same as "broadcast" events over RF, who cares? They're not; that's the problem. For the US, at least, the Copyright Office of the Library of Congress has statutory authority in this; for digital performances there is one and only one avenue, and that's through SoundExchange. From cmadams at hiwaay.net Sat Apr 30 12:30:40 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 30 Apr 2011 12:30:40 -0500 Subject: How do you put a TV station on the Mbone? In-Reply-To: <20110429234405.GA31563@srv03.cluenet.de> References: <4934657.385.1304113885537.JavaMail.root@benjamin.baylink.com> <20110429234405.GA31563@srv03.cluenet.de> Message-ID: <20110430173040.GA14461@hiwaay.net> Once upon a time, Daniel Roesen said: > That reminds me of 9/11. When the tragic event unfolded, we sat in the > office. News made the rounds verbally, and people started looking for > streaming services at their personal desks (no TVs around). People > pretty quickly gave up trying to find streams and news portals which were > actually working fine and the crowd gathering behind me watching over my > shoulder became bigger and bigger. We had a TV in the office then, but now we don't. The other big news event of the week, the tornadoes in the south (especially here in Alabama), meant we were filling up our office bandwidth much of the day Wednesday, watching the local weathermen to find out if we (or our family and friends) were next. This was an exceedingly unusual event in terms of magnitude, but the watching to see where the tornadoes go part is fairly regular around here this time of year. Every time there is a severe weather outbreak, we see our bandwidth usage go up significantly (especially when it is during the business day). As an admin at a small ISP, I'll admit we don't have multicast set up in our network, in part because every time I've looked, I just end up confused. Kind of like IPv6 was for a long time, except IPv6 has more attention and so more people writing better (easier to understand) info. Of course, we provide DSL via PPPoE (wholesaler, so we don't have a choice in the setup), so there isn't much we can do to help with that level. That's where we could gain the most of course; we sometimes see nearly double the DSL traffic for big events (not for the wedding though, since most of our customers don't have electricity). The "last mile" is usually the bottleneck, but that's the hardest nut to crack. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From cmadams at hiwaay.net Sat Apr 30 12:34:15 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 30 Apr 2011 12:34:15 -0500 Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: References: <21149940.309.1304099331309.JavaMail.root@benjamin.baylink.com> Message-ID: <20110430173415.GB14461@hiwaay.net> Once upon a time, Octavio Alvarez said: > So the first user in a router tunes to a multicast stream. Consumption > for the ISP and all the routers in the chain to the source: same as if > it were a unicast stream. Then a second user tunes to a multicast > stream. Cost for the ISP: zero. How does this affect peering, when some providers want bandwidth ratios in a certain range? I can also see how this affects the ISPs providing bandwidth to the content providers. In our colo for example, we rate-limit customers to the paid-for bandwidth at the colo port. With multicast however, they could use significantly more bandwidth, because every router in our network could potentially send the stream to many ports. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From tony at lavanauts.org Sat Apr 30 14:35:32 2011 From: tony at lavanauts.org (Antonio Querubin) Date: Sat, 30 Apr 2011 09:35:32 -1000 (HST) Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <20110430173415.GB14461@hiwaay.net> References: <21149940.309.1304099331309.JavaMail.root@benjamin.baylink.com> <20110430173415.GB14461@hiwaay.net> Message-ID: On Sat, 30 Apr 2011, Chris Adams wrote: > I can also see how this affects the ISPs providing bandwidth to the > content providers. In our colo for example, we rate-limit customers to > the paid-for bandwidth at the colo port. With multicast however, they > could use significantly more bandwidth, because every router in our > network could potentially send the stream to many ports. Only if you're using hubs or dumb switches. If your switch is multicast aware, the multicast traffic only goes to ports with active listeners for a particular group. Routers send multicast traffic only if there are active downstream listeners (where "downstream" doesn't mean the same for unicast as it does multicast). -- Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From alvarezp at alvarezp.ods.org Sat Apr 30 15:41:14 2011 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Sat, 30 Apr 2011 13:41:14 -0700 Subject: How do you put a TV station on the Mbone? (was: Royal Wedding...) In-Reply-To: <20110430173415.GB14461@hiwaay.net> References: <21149940.309.1304099331309.JavaMail.root@benjamin.baylink.com> <20110430173415.GB14461@hiwaay.net> Message-ID: On Sat, 30 Apr 2011 10:34:15 -0700, Chris Adams wrote: > Once upon a time, Octavio Alvarez said: >> So the first user in a router tunes to a multicast stream. Consumption >> for the ISP and all the routers in the chain to the source: same as if >> it were a unicast stream. Then a second user tunes to a multicast >> stream. Cost for the ISP: zero. > > How does this affect peering, when some providers want bandwidth ratios > in a certain range? > > I can also see how this affects the ISPs providing bandwidth to the > content providers. In our colo for example, we rate-limit customers to > the paid-for bandwidth at the colo port. With multicast however, they > could use significantly more bandwidth, because every router in our > network could potentially send the stream to many ports. You are billing your content provider for the bandwidth consumption at his port not because you intend to bill him for the bandwidth of content provided, but for the bandwidth of content delivered to the end user! The end-user is ALREADY PAYING for that bandwidth! Something is *really* broken there. -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp From Valdis.Kletnieks at vt.edu Sat Apr 30 16:55:02 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 30 Apr 2011 17:55:02 -0400 Subject: How do you put a TV station on the Mbone? In-Reply-To: Your message of "Fri, 29 Apr 2011 19:57:42 CDT." <201104300057.p3U0vgg2039413@mail.r-bonomi.com> References: <201104300057.p3U0vgg2039413@mail.r-bonomi.com> Message-ID: <257253.1304200502@localhost> On Fri, 29 Apr 2011 19:57:42 CDT, Robert Bonomi said: > There's a layer 9 (or is it 10? -- required for legal reasons) > answer for that. "This layer goes to 11..." :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: