June 2012 - Test - lists.nanog.org

inquire
by Hadi Salem 25 Jun '12

25 Jun '12

Hi, I have inquire regard how to setup pop for terminating voice to telecom carries around the global. May scenario is, Telecom companies will connect to us thru VoIP. And we would like to terminate these voice calls to telecom carrier around the global... At best price. How can I accomplish this? I have read many article to host my equipment’s in co-location provider, where all carries well meet there. Like meet-me-room I’m confused here, is all carriers will be hosting there equipment’s in ixp? Or data center? What equipment’s do I need is Multiplexer and media gateway and Softswitch and patch panel? I need to make 30000 calls do I need 1000xE1 lines from the Multiplexer? What in my mind this picture Softswitch will connect media gateway. Media gateway will connect Multiplexer at DS3. Multiplexer will produce E1line to patch panel and from patch panel will connect cross connect to others telecom carrier Is this right?? Do I have to host my equipment’s at each ixp ? or data center where meet-me-room available Thanks and regards Mike

1 0

Re: NANOG Digest, Vol 53, Issue 105
by Gregg 25 Jun '12

25 Jun '12

It really is possible to have a secure society that does not require identification and authentication at every turn and for every move. We the people will have to demand such freedom in order that it come to pass, however, because it is at odds with what money and power want. And where those go, sex follows. So, you could say, we have ourselves in a bit of a bind at the moment. Gregg Squires Consultant Unimatics, Inc NV Sent from my mobile fruit device. On Jun 25, 2012, at 7:30 AM, nanog-request(a)nanog.org wrote: > Send NANOG mailing list submissions to > nanog(a)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(a)nanog.org > > You can reach the person managing the list at > nanog-owner(a)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: LinkedIn password database compromised (Keith Medcalf) > 2. RE: LinkedIn password database compromised (Keith Medcalf) > 3. Re: LinkedIn password database compromised (Michael Thomas) > 4. Re: How to fix authentication (was LinkedIn) (Kyle Creyts) > 5. EULAs (James Smith) > 6. Re: IPv6 /64 links (was Re: ipv6 book recommendations?) > (Masataka Ohta) > 7. Re: IPv6 /64 links (was Re: ipv6 book recommendations?) > (Tim Franklin) > 8. Re: IPv6 /64 links (was Re: ipv6 book recommendations?) > (Tim Franklin) > 9. Re: How to fix authentication (was LinkedIn) (AP NANOG) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 23 Jun 2012 18:52:10 -0600 > From: "Keith Medcalf" <kmedcalf(a)dessus.com> > To: "Leo Bicknell" <bicknell(a)ufp.org> > Cc: "nanog(a)nanog.org" <nanog(a)nanog.org> > Subject: RE: LinkedIn password database compromised > Message-ID: <2bce6257d310384a9e0cd3b5bf71e3f3(a)mail.dessus.com> > Content-Type: text/plain; charset="us-ascii" > > Leo, > > This will never work. The "vested profiteers" will all get together and make it a condition that in order to use this method the user has to have "purchased" a "verified" key from them. Every site will use different profiteers (probably whoever gives them the biggest kickback). You will end up paying thousands of dollars a year (as a user) to buy multiple keys from the profiteers, and provide them all sorts of private information in the process. They will then also insist that web sites using this method provide "tracking" information on key usage back to the profiteers. The profiteers will then sell all this information to whomever they want, for whatever purpose, so long as it results in a profit. Some of this will get kicked back to participating web sites. Then there will be "affiliate programs" where any web site can "sign up" with the profiteers to "silently" do key exchanges without the users consent so that more tracking information can be collected, for which the participating affiliate web site will get a kickback. Browser vendors will "assist" by making the whole process transparent. Contracts in restraint of trade will be enforced by the profiteers to prevent any browser from using the "method" unless it is completely invisible to the user. > > Then (in the US) the fascist government will step in and require "registration" of issued keys along with the verified real-world identity linkage. > > If it does not use self-generated unsigned keys, it will never fly. > > --- > () ascii ribbon campaign against html e-mail > /\ www.asciiribbon.org > > >> -----Original Message----- >> From: Leo Bicknell [mailto:bicknell@ufp.org] >> Sent: Wednesday, 20 June, 2012 15:39 >> To: nanog(a)nanog.org >> Subject: Re: LinkedIn password database compromised >> >> In a message written on Wed, Jun 20, 2012 at 02:19:15PM -0700, Leo Vegoda >> wrote: >>> Key management: doing it right is hard and probably beyond most end users. >> >> I could not be in more violent disagreement. >> >> First time a user goes to sign up on a web page, the browser should >> detect it wants a key uploaded and do a simple wizard. >> >> - Would you like to create an online identity for logging into web >> sites? Yes, No, Import >> >> User says yes, it creates a key, asking for an e-mail address to >> identify it. Import to drag it in from some other program/format, >> No and you can't sign up. >> >> Browser now says "would you like to sign up for website 'foobar.com'", >> and if the user says "yes" it submits their public key including the >> e-mail they are going to use to log on. User doesn't even fill out >> a form at all. >> >> Web site still does the usual e-mail the user, click this link to verify >> you want to sign up thing. >> >> User goes back to web site later, browser detects "auth needed" and >> "public key foo" accepted, presents the cert, and the user is logged in. >> >> Notice that these steps _remove_ the user filling out forms to sign up >> for simple web sites, and filling out forms to log in. Anyone who's >> used cert-based auth at work is already familiar, the web site >> "magically" knows you. This is MUCH more user friendly. >> >> So the big magic here is the user has to click on "yes" to create a key >> and type in an e-mail once. That's it. There's no web of trust. No >> identity verification (a-la ssl). I'm talking a very SSH like system, >> but with more polish. >> >> Users would find it much more convenient and wonder why we ever used >> passwords, I think... >> >> -- >> Leo Bicknell - bicknell(a)ufp.org - CCIE 3440 >> PGP keys at http://www.ufp.org/~bicknell/ > > > > > > > ------------------------------ > > Message: 2 > Date: Sat, 23 Jun 2012 19:14:31 -0600 > From: "Keith Medcalf" <kmedcalf(a)dessus.com> > To: "Rich Kulawiec" <rsk(a)gsp.org> > Cc: "nanog(a)nanog.org" <nanog(a)nanog.org> > Subject: RE: LinkedIn password database compromised > Message-ID: <8e36f7431646a04c831b2e1b6e02c6a5(a)mail.dessus.com> > Content-Type: text/plain; charset="us-ascii" > > >> 2. Pre-compromised-at-the-factory smartphones and similar. There's >> no reason why these can't be preloaded with spyware similar to CarrierIQ >> and directed to upload all newly-created private keys to a central >> collection point. This can be done, therefore it will be done, and when >> some security researcher discovers it, the usual excuses and justifications >> will be made by the designated spokesliars for the companies involved... >> which will of course keep right on doing it, albeit perhaps with more >> subterfuge. > >> Problem #2 is newer, but I'm willing to bet that it will also last >> at least a decade and that it will get worse, since there are >> substantial economic incentives to make it so. > > This doesn't only apply to "SmartPhones". The most widely used Operating System (by this I mean Windows) has been issued pre-compromised and has "intentionally implanted compromise via Vendor Update" for many years. It is only unethical when a non-American does it. The excuses and justifications are no different. > > --- > () ascii ribbon campaign against html e-mail > /\ www.asciiribbon.org > > > > > > > ------------------------------ > > Message: 3 > Date: Sat, 23 Jun 2012 19:09:32 -0700 > From: Michael Thomas <mike(a)mtcc.com> > To: Keith Medcalf <kmedcalf(a)dessus.com> > Cc: "nanog(a)nanog.org" <nanog(a)nanog.org> > Subject: Re: LinkedIn password database compromised > Message-ID: <4FE676DC.9000108(a)mtcc.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 06/23/2012 05:52 PM, Keith Medcalf wrote: >> Leo, >> >> This will never work. The "vested profiteers" will all get together and make it a condition that in order to use this method the user has to have "purchased" a "verified" key from them. Every site will use different profiteers (probably whoever gives them the biggest kickback). > > What is their leverage to extort? A web site just needs to make the > client and server end agree on a scheme, and they control both ends. > They can't force me to use their scheme any more than they can force > me to not use Basic and use their scheme instead. Keep in mind that > asymmetric keys do not imply certification, and asymmetric keys are > cheap and plentiful -- as in a modest amount of CPU time these days. > > Mike > >> You will end up paying thousands of dollars a year (as a user) to buy multiple keys from the profiteers, and provide them all sorts of private information in the process. They will then also insist that web sites using this method provide "tracking" information on key usage back to the profiteers. The profiteers will then sell all this information to whomever they want, for whatever purpose, so long as it results in a profit. Some of this will get kicked back to participating web sites. Then there will be "affiliate programs" where any web site can "sign up" with the profiteers to "silently" do key exchanges without the users consent so that more tracking information can be collected, for which the participating affiliate web site will get a kickback. Browser vendors will "assist" by making the whole process transparent. Contracts in restraint of trade will be enforced by the profiteers to prevent any browser from using the "method" unless it is completely invisible to the user. >> >> Then (in the US) the fascist government will step in and require "registration" of issued keys along with the verified real-world identity linkage. >> >> If it does not use self-generated unsigned keys, it will never fly. >> >> --- >> () ascii ribbon campaign against html e-mail >> /\ www.asciiribbon.org >> >> >>> -----Original Message----- >>> From: Leo Bicknell [mailto:bicknell@ufp.org] >>> Sent: Wednesday, 20 June, 2012 15:39 >>> To: nanog(a)nanog.org >>> Subject: Re: LinkedIn password database compromised >>> >>> In a message written on Wed, Jun 20, 2012 at 02:19:15PM -0700, Leo Vegoda >>> wrote: >>>> Key management: doing it right is hard and probably beyond most end users. >>> I could not be in more violent disagreement. >>> >>> First time a user goes to sign up on a web page, the browser should >>> detect it wants a key uploaded and do a simple wizard. >>> >>> - Would you like to create an online identity for logging into web >>> sites? Yes, No, Import >>> >>> User says yes, it creates a key, asking for an e-mail address to >>> identify it. Import to drag it in from some other program/format, >>> No and you can't sign up. >>> >>> Browser now says "would you like to sign up for website 'foobar.com'", >>> and if the user says "yes" it submits their public key including the >>> e-mail they are going to use to log on. User doesn't even fill out >>> a form at all. >>> >>> Web site still does the usual e-mail the user, click this link to verify >>> you want to sign up thing. >>> >>> User goes back to web site later, browser detects "auth needed" and >>> "public key foo" accepted, presents the cert, and the user is logged in. >>> >>> Notice that these steps _remove_ the user filling out forms to sign up >>> for simple web sites, and filling out forms to log in. Anyone who's >>> used cert-based auth at work is already familiar, the web site >>> "magically" knows you. This is MUCH more user friendly. >>> >>> So the big magic here is the user has to click on "yes" to create a key >>> and type in an e-mail once. That's it. There's no web of trust. No >>> identity verification (a-la ssl). I'm talking a very SSH like system, >>> but with more polish. >>> >>> Users would find it much more convenient and wonder why we ever used >>> passwords, I think... >>> >>> -- >>> Leo Bicknell - bicknell(a)ufp.org - CCIE 3440 >>> PGP keys at http://www.ufp.org/~bicknell/ >> >> > > > > > > > ------------------------------ > > Message: 4 > Date: Sat, 23 Jun 2012 22:02:25 -0700 > From: Kyle Creyts <kyle.creyts(a)gmail.com> > To: nanog(a)nanog.org > Subject: Re: How to fix authentication (was LinkedIn) > Message-ID: > <CA+TcGd_uhe5s161umexuC=3v2vaC31zFqV+aqEqjP0zYunab-g(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > I would suggest that multiple models be pursued (since each appears to have > a champion) and that the market/drafting process will resolve the issue of > which is better (which is okay by me: widespread adoption of any of the > proposed models would advance the state of the norm; progress beats the > snot out of stagnation in my book) > > My earlier replies were reprehensible. This is not a thread that should > just be laughed off. Real progress may be occurring here, and at the least, > good knowledge and discussion is accumulating in a way which may serve as a > resource for the curious or concerned. > On Jun 22, 2012 7:25 AM, "Leo Bicknell" <bicknell(a)ufp.org> wrote: > >> In a message written on Thu, Jun 21, 2012 at 04:48:47PM -1000, Randy Bush >> wrote: >>> there are no trustable third parties >> >> With a lot of transactions the second party isn't trustable, and >> sometimes the first party isn't as well. :) >> >> In a message written on Thu, Jun 21, 2012 at 10:53:18PM -0400, Christopher >> Morrow wrote: >>> note that yubico has models of auth that include: >>> 1) using a third party >>> 2) making your own party >>> 3) HOTP on token >>> 4) NFC >>> >>> they are a good company, trying to do the right thing(s)... They also >>> don't necessarily want you to be stuck in the 'get your answer from >>> another' >> >> Requirements of hardware or a third party are fine for the corporate >> world, or sites that make enough money or have enough risk to invest >> in security, like a bank. >> >> Requiring hardware for a site like Facebook or Twitter is right >> out. Does not scale, can't ship to the guy in Pakistan or McMurdo >> who wants to sign up. Trusting a third party becomes too expensive, >> and too big of a business risk. >> >> There are levels of security here. I don't expect Facebook to take >> the same security steps as my bank to move my money around. One >> size does not fit all. Making it so a hacker can't get 10 million >> login credentials at once is a quantum leap forward even if doing >> so doesn't improve security in any other way. >> >> The perfect is the enemy of the good. >> >> -- >> Leo Bicknell - bicknell(a)ufp.org - CCIE 3440 >> PGP keys at http://www.ufp.org/~bicknell/ >> > > > ------------------------------ > > Message: 5 > Date: Mon, 25 Jun 2012 00:41:26 -0300 > From: James Smith <james(a)smithwaysecurity.com> > To: "nanog(a)nanog.org" <nanog(a)nanog.org> > Subject: EULAs > Message-ID: <4FE7DDE6.7070606(a)smithwaysecurity.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, > > I was wondering if some one could contact me with regards to ISP's who > share data to private companies if stated in their EULAs . > > -- > Sincerely; > > > James Smith > CEO, Security Analyst > > > > ------------------------------ > > Message: 6 > Date: Mon, 25 Jun 2012 16:06:50 +0900 > From: Masataka Ohta <mohta(a)necom830.hpcl.titech.ac.jp> > To: nanog(a)nanog.org > Subject: Re: IPv6 /64 links (was Re: ipv6 book recommendations?) > Message-ID: <4FE80E0A.5020906(a)necom830.hpcl.titech.ac.jp> > Content-Type: text/plain; charset=ISO-2022-JP > > Justin M. Streiner wrote: > >> I see periodic upticks in the growth of the global v6 routing table (a >> little over 9k prefixes at the moment - the v4 global view is about 415k >> prefixes right now), which I would reasonably attribute an upswing in >> networks getting initial assignments. > > As I already wrote: > > : That's not the point. The problem is that SRAMs scale well but > : CAMs do not. > > it is a lot more difficult to quickly look up 1M routes > with /48 than 2M routes with /24. > >> If anything, I see more of a >> chance for the v4 routing table to grow more out of control, as v4 >> blocks get chopped up into smaller and smaller pieces in an ultimately >> vain effort to squeeze a little more mileage out of IPv4. > > The routing table grows mostly because of multihoming, > regardless of whether it is v4 or v6. > > The only solution is, IMO, to let multihomed sites have > multiple prefixes inherited from their upper ISPs, still > keeping the sites' ability to control loads between incoming > multiple links. > > Masataka Ohta > > > > ------------------------------ > > Message: 7 > Date: Mon, 25 Jun 2012 10:00:16 +0100 (BST) > From: Tim Franklin <tim(a)pelican.org> > To: nanog(a)nanog.org > Subject: Re: IPv6 /64 links (was Re: ipv6 book recommendations?) > Message-ID: <f3cc4bae-f05b-4320-82d0-191f4f6721ff(a)mail.pelican.org> > Content-Type: text/plain; charset=utf-8 > >> Even though it may be easy to make end systems and local >> LANs v6 capable, rest, the center part, of the Internet >> keep causing problems. > > Really? My impression is that it's very much the edge that's hard - CE routers, and in particular cheap, nasty, residential DSL and cable CE routers. Lots of existing kit out there that can't do v6, and the business case for a fork-lift upgrade just doesn't stack up. It's a cost issue, though, not a technology one - it's perfectly possible to deliver v6 over these technologies. Tunnelling, while not ideal, is certainly a workable stop-gap, and I'm *very* happy to have real, globally uniquely addressed end-to-end Internet in my house again as a result. > > Systems can be a problem too - both in convincing IS people to change things, in getting the budget for changes, and in finding all the dark places hidden in the organisation where v4 assumptions are made. > > But in the Internet core? I don't see any huge obstacles at $ISP_DAYJOB, with any of the people I know in the industry, or with the ISPs I do business with. For co-lo, VPS, leased lines, real Ethernet tails, v6 connectivity is being delivered and working fine today. > > Regards, > Tim. > > > > ------------------------------ > > Message: 8 > Date: Mon, 25 Jun 2012 10:04:29 +0100 (BST) > From: Tim Franklin <tim(a)pelican.org> > To: nanog(a)nanog.org > Subject: Re: IPv6 /64 links (was Re: ipv6 book recommendations?) > Message-ID: <d76090e9-983b-420d-beb4-818ff97abdae(a)mail.pelican.org> > Content-Type: text/plain; charset=utf-8 > >> The only solution is, IMO, to let multihomed sites have >> multiple prefixes inherited from their upper ISPs, still >> keeping the sites' ability to control loads between incoming >> multiple links. > > And for the basement multi-homers, RA / SLAAC makes this much easier to do with v6. The larger-scale / more mission-critical multi-homers are going to consume an AS and some BGP space whether you like it or not - at least with v6 there's a really good chance that they'll only *ever* need to announce a single-prefix. (Ignore "traffic engineering" pollution, but that doesn't get better or worse). > > Regards, > Tim. > > > > ------------------------------ > > Message: 9 > Date: Mon, 25 Jun 2012 09:30:02 -0400 > From: AP NANOG <nanog(a)armoredpackets.com> > To: nanog(a)nanog.org > Subject: Re: How to fix authentication (was LinkedIn) > Message-ID: <4FE867DA.8050400(a)armoredpackets.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Kyle, > > I may be mistaken here, but I don't believe anyone is truly laughing the > matter off. > > There may have been some remarks about second or third parties, but the > fact does remain these are the areas which current concerns still lay. > > -- > > Robert Miller > (arch3angel) > > On 6/24/12 1:02 AM, Kyle Creyts wrote: >> I would suggest that multiple models be pursued (since each appears to have >> a champion) and that the market/drafting process will resolve the issue of >> which is better (which is okay by me: widespread adoption of any of the >> proposed models would advance the state of the norm; progress beats the >> snot out of stagnation in my book) >> >> My earlier replies were reprehensible. This is not a thread that should >> just be laughed off. Real progress may be occurring here, and at the least, >> good knowledge and discussion is accumulating in a way which may serve as a >> resource for the curious or concerned. >> On Jun 22, 2012 7:25 AM, "Leo Bicknell" <bicknell(a)ufp.org> wrote: >> >>> In a message written on Thu, Jun 21, 2012 at 04:48:47PM -1000, Randy Bush >>> wrote: >>>> there are no trustable third parties >>> With a lot of transactions the second party isn't trustable, and >>> sometimes the first party isn't as well. :) >>> >>> In a message written on Thu, Jun 21, 2012 at 10:53:18PM -0400, Christopher >>> Morrow wrote: >>>> note that yubico has models of auth that include: >>>> 1) using a third party >>>> 2) making your own party >>>> 3) HOTP on token >>>> 4) NFC >>>> >>>> they are a good company, trying to do the right thing(s)... They also >>>> don't necessarily want you to be stuck in the 'get your answer from >>>> another' >>> Requirements of hardware or a third party are fine for the corporate >>> world, or sites that make enough money or have enough risk to invest >>> in security, like a bank. >>> >>> Requiring hardware for a site like Facebook or Twitter is right >>> out. Does not scale, can't ship to the guy in Pakistan or McMurdo >>> who wants to sign up. Trusting a third party becomes too expensive, >>> and too big of a business risk. >>> >>> There are levels of security here. I don't expect Facebook to take >>> the same security steps as my bank to move my money around. One >>> size does not fit all. Making it so a hacker can't get 10 million >>> login credentials at once is a quantum leap forward even if doing >>> so doesn't improve security in any other way. >>> >>> The perfect is the enemy of the good. >>> >>> -- >>> Leo Bicknell - bicknell(a)ufp.org - CCIE 3440 >>> PGP keys at http://www.ufp.org/~bicknell/ >>> > > > > End of NANOG Digest, Vol 53, Issue 105 > **************************************

1 0

Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
by Masataka Ohta 25 Jun '12

25 Jun '12

Owen DeLong wrote privately to me, but as I think I need public responses, I'm Ccing to nanog fairly quoting part of his response: >> Moreover, it is easy to have a transport protocol with >> 32bit or 48bit port numbers with the end to end fashion >> only by modifying end part of the Internet. > The center part of the internet is the easiest part of > modification for IPv6 and is probably somewhere near 99% > complete at this point. That is a fairy tale once believed by so many infants who thought dual stack were enough. They still believed the fairy tale even when they designed automated tunneling. But, as most of them have grown up a little not to believe fairly tales, they are trying other possibilities. However, so far, they are not so successful. Masataka Ohta PS Rest of his response is omitted, because I think it is not worth quoting.

5 11

LinkedIn password database compromised
by Lynda 25 Jun '12

25 Jun '12

Sorry to be the bearer of such bad tidings. Please note that I'm doing a quick copy/paste from a notification I received. I've edited it a bit. Please note that LinkedIn has weighed in with a carefully worded blog post: http://blog.linkedin.com/2012/06/06/linkedin-member-passwords-compromised/ Further details: 1. The leak took place on June 4 2. LinkedIn was using unsalted SHA-1 for their password store. 3. FYI, there are two lists. The second one appears to be from eHarmony. Unsalted MD5 used there. 4. The posted passwords are believed to be ones the cracker wanted help with, i.e., they have significantly more already cracked. Apparently phishing emails are already active in the wild based on the crack: http://bits.blogs.nytimes.com/2012/06/06/that-was-fast-criminals-exploit-li… In other words, if you have a LinkedIn account, expect that the password has been stolen. Go change your password now. If you used that password elsewhere, you know the routine. In addition, as has been pointed out elsewhere, there's no sign LI has fixed the problem. Expect that the password you change it to will also be compromised. :-( -- A picture is worth 10K words -- but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures.

43 97

EULAs
by James Smith 25 Jun '12

25 Jun '12

Hello, I was wondering if some one could contact me with regards to ISP's who share data to private companies if stated in their EULAs . -- Sincerely; James Smith CEO, Security Analyst

1 0

NYC to DEU packet loss
by Tim Durack 23 Jun '12

23 Jun '12

Trying to troubleshoot packet loss from NYC to DEU. Traceroute shows: tdurack@2ua82715mg:~$ traceroute -I 194.25.250.73 traceroute to 194.25.250.73 (194.25.250.73), 30 hops max, 60 byte packets <snip> 4 216.55.2.85 (216.55.2.85) 1.694 ms 1.698 ms 1.698 ms 5 vb1010.rar3.nyc-ny.us.xo.net (216.156.0.17) 4.788 ms 4.792 ms 4.791 ms 6 207.88.14.178.ptr.us.xo.net (207.88.14.178) 1.684 ms 1.461 ms 1.452 ms 7 62.157.250.245 (62.157.250.245) 40.457 ms 42.980 ms 42.982 ms 8 hh-eb3-i.HH.DE.NET.DTAG.DE (62.154.32.134) 129.417 ms * 129.422 ms 9 194.25.250.73 (194.25.250.73) 139.501 ms 136.192 ms 139.236 ms Packet loss of approx. 20% affects hops 7 and 8, along with end host 9. Loss appears to be data-plane, not control-plane rate limiting. Affected customer confirms this too :-) 62.157.250.245 is in Deutsche Telekom address spaces, so I'm guessing this is either a DTAG problem or an issue between XO and DTAG. I have a ticket open with XO, but I'm having a hard time figuring out what is ~40ms away from NYC on a path to DEU. Any idea what the physical path is? -- Tim:>

2 2

Cogent DNS Contact
by Garret Picchioni 23 Jun '12

23 Jun '12

Hi All, If anyone has a contact at Cogent, who might be able to solve a reverse DNS issue, could they contact me offline? Thanks! Garret

2 1

BGP Update Report
by cidr-report＠potaroo.net 22 Jun '12

22 Jun '12

BGP Update Report Interval: 14-Jun-12 -to- 21-Jun-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8452 113559 4.4% 62.4 -- TE-AS TE-AS 2 - AS9829 50283 2.0% 38.7 -- BSNL-NIB National Internet Backbone 3 - AS8402 45797 1.8% 23.5 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS13188 41623 1.6% 79.3 -- BANKINFORM-AS TOV "Bank-Inform" 5 - AS19361 32335 1.3% 951.0 -- Atrium Telecomunicacoes Ltda 6 - AS12479 28842 1.1% 38.1 -- UNI2-AS France Telecom Espana SA 7 - AS24560 27934 1.1% 26.8 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 8 - AS7303 25098 1.0% 17.4 -- Telecom Argentina S.A. 9 - AS17813 25074 1.0% 188.5 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 10 - AS5800 21992 0.9% 83.3 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 11 - AS13118 20121 0.8% 419.2 -- ASN-YARTELECOM OJSC Rostelecom 12 - AS28057 18560 0.7% 1546.7 -- Contecol 13 - AS26615 16782 0.7% 18.4 -- Tim Celular S.A. 14 - AS17621 16250 0.6% 106.9 -- CNCGROUP-SH China Unicom Shanghai network 15 - AS28573 16052 0.6% 8.1 -- NET Servicos de Comunicao S.A. 16 - AS7552 14335 0.6% 12.1 -- VIETEL-AS-AP Vietel Corporation 17 - AS7029 14153 0.6% 4.1 -- WINDSTREAM - Windstream Communications Inc 18 - AS16814 12125 0.5% 17.9 -- NSS S.A. 19 - AS17974 11505 0.5% 5.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS25620 10104 0.4% 53.7 -- COTAS LTDA. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS45264 4799 0.2% 2399.5 -- BAJAJALLIANZLIFE-AS-AP Bajaj Allianz Life Insurance Company Ltd 2 - AS28057 18560 0.7% 1546.7 -- Contecol 3 - AS45286 1387 0.1% 1387.0 -- EDIINDONESIA-AS-ID PT EDI INDONESIA 4 - AS29421 1371 0.1% 1371.0 -- DCI-AS Digital Communications Incorporated Ltd. 5 - AS30944 1258 0.1% 1258.0 -- DKD-AS Bendra Lietuvos, JAV ir Rusijos imone uzdaroji akcine bendrove "DKD" 6 - AS29126 972 0.0% 972.0 -- DATIQ-AS Datiq B.V. 7 - AS19361 32335 1.3% 951.0 -- Atrium Telecomunicacoes Ltda 8 - AS40848 911 0.0% 911.0 -- FMFCU - Franklin Mint FCU 9 - AS55665 824 0.0% 824.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 10 - AS3 635 0.0% 1139.0 -- UNIXSTORM-AS Unix Storm - Michal Gottlieb 11 - AS3 555 0.0% 1322.0 -- UNIXSTORM-AS Unix Storm - Michal Gottlieb 12 - AS11652 2517 0.1% 503.4 -- TFCL-2 - TERRA FIRMA COMMUNICATIONS, LLC 13 - AS57201 459 0.0% 459.0 -- EDF-AS Estonian Defence Forces 14 - AS13118 20121 0.8% 419.2 -- ASN-YARTELECOM OJSC Rostelecom 15 - AS38857 814 0.0% 407.0 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd. 16 - AS19406 4428 0.2% 402.5 -- TWRS-MA - Towerstream I, Inc. 17 - AS43230 346 0.0% 346.0 -- OMNIPORT-AS OMNIPORT SRL 18 - AS16064 330 0.0% 330.0 -- INFOPAC-AS Joint-Stock Company INFOPAC 19 - AS51624 322 0.0% 322.0 -- ITC21VEK-AS ITC XXI Century Ltd. 20 - AS28666 4398 0.2% 314.1 -- HOSTLOCATION LTDA TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 19886 0.7% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 220.196.26.0/24 15945 0.6% AS17621 -- CNCGROUP-SH China Unicom Shanghai network 3 - 41.43.147.0/24 11685 0.4% AS8452 -- TE-AS TE-AS 4 - 122.161.0.0/16 10614 0.4% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 5 - 62.36.252.0/22 7930 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 6 - 182.64.0.0/16 7567 0.3% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 7 - 62.36.249.0/24 6595 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 8 - 202.56.215.0/24 6459 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 9 - 62.36.241.0/24 6172 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 10 - 59.177.48.0/20 6054 0.2% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 11 - 62.36.210.0/24 6021 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 12 - 194.63.9.0/24 5263 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 13 - 202.159.192.0/19 4837 0.2% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 14 - 202.90.40.0/24 4797 0.2% AS45264 -- BAJAJALLIANZLIFE-AS-AP Bajaj Allianz Life Insurance Company Ltd 15 - 69.38.178.0/24 4408 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 16 - 59.177.64.0/18 3362 0.1% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 17 - 59.177.144.0/20 3097 0.1% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 18 - 115.170.128.0/17 2206 0.1% AS4847 -- CNIX-AP China Networks Inter-Exchange 19 - 215.65.61.0/24 1889 0.1% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 20 - 190.9.120.0/24 1720 0.1% AS11581 -- TRANSTEL S.A. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog(a)nanog.org eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

The Cidr Report
by cidr-report＠potaroo.net 22 Jun '12

22 Jun '12

This report has been generated at Fri Jun 22 21:12:58 2012 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-06-12 416421 242407 16-06-12 416435 242366 17-06-12 416800 242573 18-06-12 417057 242604 19-06-12 416751 242539 20-06-12 416653 242280 21-06-12 417133 242084 22-06-12 417401 241620 AS Summary 41477 Number of ASes in routing system 17307 Number of ASes announcing only one prefix 3401 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 113213920 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'). --- 22Jun12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 417722 241644 176078 42.2% All ASes AS6389 3401 193 3208 94.3% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 3279 1651 1628 49.6% WINDSTREAM - Windstream Communications Inc AS22773 1652 137 1515 91.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4766 2720 1294 1426 52.4% KIXS-AS-KR Korea Telecom AS18566 2091 706 1385 66.2% COVAD - Covad Communications Co. AS28573 1954 581 1373 70.3% NET Servicos de Comunicao S.A. AS2118 1255 14 1241 98.9% RELCOM-AS OOO "NPO Relcom" AS7545 1704 503 1201 70.5% TPG-INTERNET-AP TPG Internet Pty Ltd AS4323 1571 386 1185 75.4% TWTC - tw telecom holdings, inc. AS10620 1967 794 1173 59.6% Telmex Colombia S.A. AS1785 1925 815 1110 57.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1594 540 1054 66.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7303 1440 462 978 67.9% Telecom Argentina S.A. AS7552 1100 217 883 80.3% VIETEL-AS-AP Vietel Corporation AS26615 902 33 869 96.3% Tim Celular S.A. AS17974 1945 1088 857 44.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS8151 1490 672 818 54.9% Uninet S.A. de C.V. AS18101 947 160 787 83.1% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1107 346 761 68.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS9394 892 162 730 81.8% CRNET CHINA RAILWAY Internet(CRNET) AS13977 839 123 716 85.3% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS3356 1113 467 646 58.0% LEVEL3 Level 3 Communications AS855 690 57 633 91.7% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS17676 691 74 617 89.3% GIGAINFRA Softbank BB Corp. AS30036 1439 835 604 42.0% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS4780 841 246 595 70.7% SEEDNET Digital United Inc. AS19262 998 405 593 59.4% VZGNI-TRANSIT - Verizon Online LLC AS22561 1016 424 592 58.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS9808 593 22 571 96.3% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS8452 1275 716 559 43.8% TE-AS TE-AS Total 44431 14123 30308 68.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- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 46.96.0.0/22 AS31733 46.96.4.0/22 AS31733 46.96.8.0/22 AS31733 46.96.12.0/22 AS31733 46.96.16.0/22 AS31733 46.96.20.0/22 AS31733 46.96.24.0/22 AS31733 46.96.28.0/22 AS31733 46.96.32.0/22 AS31733 46.96.36.0/22 AS31733 46.96.40.0/22 AS31733 46.96.44.0/22 AS31733 46.96.48.0/22 AS31733 46.96.52.0/22 AS31733 46.96.56.0/22 AS31733 46.96.60.0/22 AS31733 46.96.64.0/22 AS31733 46.96.68.0/22 AS31733 46.96.72.0/22 AS31733 46.96.76.0/22 AS31733 46.96.80.0/22 AS31733 46.96.84.0/22 AS31733 46.96.88.0/22 AS31733 46.96.92.0/22 AS31733 46.96.96.0/22 AS31733 46.96.100.0/22 AS31733 46.96.104.0/22 AS31733 46.96.108.0/22 AS31733 46.96.112.0/22 AS31733 46.96.116.0/22 AS31733 46.96.120.0/22 AS31733 46.96.124.0/22 AS31733 46.96.128.0/22 AS31733 46.96.132.0/22 AS31733 46.96.136.0/22 AS31733 46.96.140.0/22 AS31733 46.96.144.0/22 AS31733 46.96.148.0/22 AS31733 46.96.152.0/22 AS31733 46.96.156.0/22 AS31733 46.96.160.0/22 AS31733 46.96.164.0/22 AS31733 46.96.168.0/22 AS31733 46.96.172.0/22 AS31733 46.96.176.0/22 AS31733 46.96.180.0/22 AS31733 46.96.184.0/22 AS31733 46.96.188.0/22 AS31733 46.96.192.0/22 AS31733 46.96.196.0/22 AS31733 46.96.200.0/22 AS31733 46.96.204.0/22 AS31733 46.96.208.0/22 AS31733 46.96.212.0/22 AS31733 46.96.216.0/22 AS31733 46.96.220.0/22 AS31733 46.96.224.0/22 AS31733 46.96.228.0/22 AS31733 46.96.232.0/22 AS31733 46.96.236.0/22 AS31733 46.96.240.0/22 AS31733 46.96.244.0/22 AS31733 46.96.248.0/22 AS31733 46.96.252.0/22 AS31733 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 70.34.112.0/20 AS27589 MOJOHOST - MOJOHOST 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.44.16.0/20 AS15054 HAMELTRONICS - Hameltronics, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 74.115.126.0/24 AS11260 EASTLINK-HSI - EastLink 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 83.223.224.0/22 AS31733 83.223.228.0/22 AS31733 83.223.232.0/22 AS31733 83.223.236.0/22 AS31733 83.223.240.0/22 AS31733 83.223.244.0/22 AS31733 83.223.248.0/22 AS31733 83.223.252.0/22 AS31733 94.250.128.0/22 AS31733 94.250.132.0/22 AS31733 94.250.136.0/22 AS31733 94.250.140.0/22 AS31733 94.250.144.0/22 AS31733 94.250.148.0/22 AS31733 94.250.152.0/22 AS31733 94.250.156.0/22 AS31733 94.250.160.0/22 AS31733 94.250.164.0/22 AS31733 94.250.168.0/22 AS31733 94.250.172.0/22 AS31733 94.250.176.0/22 AS31733 94.250.180.0/22 AS31733 94.250.184.0/22 AS31733 94.250.188.0/22 AS31733 94.250.192.0/22 AS31733 94.250.196.0/22 AS31733 94.250.200.0/22 AS31733 94.250.204.0/22 AS31733 94.250.208.0/22 AS31733 94.250.212.0/22 AS31733 94.250.216.0/22 AS31733 94.250.220.0/22 AS31733 94.250.224.0/22 AS31733 94.250.228.0/22 AS31733 94.250.232.0/22 AS31733 94.250.236.0/22 AS31733 94.250.240.0/22 AS31733 94.250.244.0/22 AS31733 94.250.248.0/22 AS31733 94.250.252.0/22 AS31733 98.159.96.0/20 AS46975 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 120.136.17.0/24 AS38779 BMG-AS-ID Badan Meteorologi dan Geofisika 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.14.0.0/24 AS57871 ASTELECENTR TeleCentr Ltd. 172.15.0.0/24 AS57871 ASTELECENTR TeleCentr Ltd. 172.45.1.0/24 AS3356 LEVEL3 Level 3 Communications 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 172.223.60.0/22 AS6910 DIALTELECOMRO Dial Telecom S.R.L. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnológico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 200.75.184.0/21 AS14754 Telgua 200.106.128.0/20 AS3257 TINET-BACKBONE Tinet SpA 200.115.112.0/20 AS3257 TINET-BACKBONE Tinet SpA 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 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.140.128.0/19 AS9583 SIFY-AS-IN Sify Limited 202.160.152.0/22 AS10113 EFTEL-AS-AP Eftel 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.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 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 204.14.0.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.0.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.2.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.3.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 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.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.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 208.93.144.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 208.93.151.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.202.0/24 AS8513 SKYVISION SkyVision Global Networks Ltd 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.194.160.0/20 AS27876 American Data Networks Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)nanog.org eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

[MBONED] PIM survey for operators
by Stig Venaas 22 Jun '12

22 Jun '12

The IETF pim working group is conducting a survey in order to advance the PIM Sparse Mode spec on the IETF Standards Track, and would like input from operators. The survey ends July 20th. Please see below for more information. thank you, pim chairs Mike & Stig Introduction: PIM-SM was first published as RFC 2117 in 1997 and then again as RFC 2362 in 1998. The protocol was classified as Experimental in both of these documents. The PIM-SM protocol specification was then rewritten in whole and advanced to Proposed Standard as RFC 4601 in 2006. Considering the multiple independent implementations developed and the successful operational experience gained, the IETF has decided to advance the PIM-SM routing protocol to Draft Standard. This survey intends to provide supporting documentation to advance the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol from IETF Proposed Standard to Draft Standard. (Due to RFC 6410, now the intention is to progress it to Internet Standard. Draft Standard is no longer used.) This survey is issued on behalf of the IETF PIM Working Group. The responses will be collected by a neutral third-party and kept strictly confidential; only the final combined results will be published. Marshall Eubanks has agreed to anonymize the response to this Questionnaire. Marshall has a long experience with Multicast but has no direct financial interest in this matter, nor ties to any of the vendors involved. He is also a member of the IAOC, Chair of the IETF Trust and co-chair of the IETF Layer 3 VPN Working Group. Please send Questionnaire responses to his email address, marshall.eubanks(a)gmail.com. He requests that such responses include the string "RFC 4601 bis Questionnaire" in the subject field. Before answering the questions, please comple the following background information. Name of the Respondent: Affliation/Organization: Contact Email: Provide description of PIM deployment: Do you wish to keep the information provided confidential: Questions: 1 Have you deployed PIM-SM in your network? 2 How long have you had PIM-SM deployed in your network? Do you know if your deployment is based on the most recent RFC4601? 3 Have you deployed PIM-SM for IPv6 in your network? 4 Are you using equipment with different (multi-vendor) PIM-SM implementations for your deployment? 5 Have you encountered any inter-operability or backward- compatibility issues amongst differing implementations? If yes, what are your concerns about these issues? 6 Have you deployed both dense mode and sparse mode in your network? If yes, do you route between these modes using features such as *,*,RP or PMBR? 7 To what extent have you deployed PIM functionality, like BSR, SSM, and Explicit Tracking? 8 Which RP mapping mechanism do you use: Static, AutoRP, or BSR? 9 How many RPs have you deployed in your network? 10 If you use Anycast-RP, is it Anycast-RP using MSDP (RFC 3446) or Anycast-RP using PIM (RFC 4610)? 11 Do you have any other comments on PIM-SM deployment in your network? _______________________________________________ MBONED mailing list MBONED(a)ietf.org https://www.ietf.org/mailman/listinfo/mboned

1 0