From mark.tinka at seacom.mu Fri Aug 1 05:40:50 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 1 Aug 2014 07:40:50 +0200 Subject: Muni Fiber and Politics In-Reply-To: <20140731120128.GA24465@besserwisser.org> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <10C051BE-0617-4382-B1CB-88E031D45128@ufp.org> <20140731120128.GA24465@besserwisser.org> Message-ID: <201408010740.50741.mark.tinka@seacom.mu> On Thursday, July 31, 2014 02:01:28 PM M?ns Nilsson wrote: > It is better, both for the customer and the provider. If the provider is able to deliver 1Gbps to every home (either on copper or fibre) with little to no uplink oversubscription (think 44x customer-facing Gig-E ports + 4x 10Gbps uplink ports), essentially, there is no limit to what services a provider and its partners can offer to its customers. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Fri Aug 1 05:52:29 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 1 Aug 2014 07:52:29 +0200 Subject: Netflix To Cogent To World In-Reply-To: References: <7243979.6896.1406126897011.JavaMail.root@benjamin.baylink.com> <201407310821.39593.mark.tinka@seacom.mu> Message-ID: <201408010752.32804.mark.tinka@seacom.mu> On Thursday, July 31, 2014 07:10:49 PM Owen DeLong wrote: > You are still misinterpreting my statement, or at least > it appears that you are. The pleasures of e-mail, and tones they do not convey :-)... > I am not saying that Netflix is attempting to ?grab?. Yes, that's what I meant - by "grab them" I meant the traditional ISP's who are also in the content game (U-Verse, Xfinity, FiOS, e.t.c.) are making a deliberate or unconscious play to "grab" Netflix (where grab means either frustrate them or take them out of the equation). So yes, we are on the same page, Owen; the lack of body in e-mail is not either of us justice :-). But, like I said, all this is conjecture on my part. Netflix may not have the might or time to become an ISP, but other networks that play in content (and are currently not known for being ISP's, even though they may run very large global IP networks) might. > (Netflix is also a distributor, not owner). I'm aware - it's easier for me to say "content owner" to encompass that industry (given some content players own and distribute content, while others simply distribute it), but I know this list is well clued in on the nuances of the terminology. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From bbqroast at gmail.com Fri Aug 1 06:54:07 2014 From: bbqroast at gmail.com (mcfbbqroast .) Date: Fri, 1 Aug 2014 18:54:07 +1200 Subject: Muni Fiber and Politics In-Reply-To: <201408010740.50741.mark.tinka@seacom.mu> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <10C051BE-0617-4382-B1CB-88E031D45128@ufp.org> <20140731120128.GA24465@besserwisser.org> <201408010740.50741.mark.tinka@seacom.mu> Message-ID: This would be my humble suggestion: - lines provider runs fibre pair from each home to co. By default the lines provider installs a simple consumer terminal, with gigabit Ethernet outputs and POTS. - lines provider provides a reasonably oversubscribed service to soft hand over to ISPs (think 96 Gbps lines to 2 10gbps ports). Perhaps upgrading so such a ratio never becomes congested could be a requirement? - lines provider also rents individual lines to ISPs which they can use directly. Rent should be lower than soft handover. This way ISPs can easily offer services. POTS over VoIP can be setup on installation of the terminal (so handover to the ISP is seamless). Finally business and residential services can also be provided over the fibre directly (this will be attractive to ISPs with many ports, to reduce costs, and premium/business ISPs to add control). - ideally the lines provider would aid in providing cheap backhaul from the co (while still allowing 3rd party users to bring fibre in). Sorry for the engrish, I'm on a mobile device :(. On 1 Aug 2014 17:43, "Mark Tinka" wrote: > On Thursday, July 31, 2014 02:01:28 PM M?ns Nilsson wrote: > > > It is better, both for the customer and the provider. > > If the provider is able to deliver 1Gbps to every home > (either on copper or fibre) with little to no uplink > oversubscription (think 44x customer-facing Gig-E ports + 4x > 10Gbps uplink ports), essentially, there is no limit to what > services a provider and its partners can offer to its > customers. > > Mark. > From mark.tinka at seacom.mu Fri Aug 1 07:08:07 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 1 Aug 2014 09:08:07 +0200 Subject: Muni Fiber and Politics In-Reply-To: References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> Message-ID: <201408010908.07452.mark.tinka@seacom.mu> On Friday, August 01, 2014 08:54:07 AM mcfbbqroast . wrote: > This would be my humble suggestion: > > - lines provider runs fibre pair from each home to co. By > default the lines provider installs a simple consumer > terminal, with gigabit Ethernet outputs and POTS. > > - lines provider provides a reasonably oversubscribed > service to soft hand over to ISPs (think 96 Gbps lines > to 2 10gbps ports). Perhaps upgrading so such a ratio > never becomes congested could be a requirement? > > - lines provider also rents individual lines to ISPs > which they can use directly. Rent should be lower than > soft handover. > > This way ISPs can easily offer services. POTS over VoIP > can be setup on installation of the terminal (so > handover to the ISP is seamless). Finally business and > residential services can also be provided over the fibre > directly (this will be attractive to ISPs with many > ports, to reduce costs, and premium/business ISPs to add > control). > > - ideally the lines provider would aid in providing cheap > backhaul from the co (while still allowing 3rd party > users to bring fibre in). Wholesale mode. Doable. Works best if the lines provider is not a service provider; or regulation in your market ensures a service provider who is also a lines provider is mandated to unbundle at reasonable cost. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From bbqroast at gmail.com Fri Aug 1 07:30:57 2014 From: bbqroast at gmail.com (mcfbbqroast .) Date: Fri, 1 Aug 2014 19:30:57 +1200 Subject: Muni Fiber and Politics In-Reply-To: <201408010908.07452.mark.tinka@seacom.mu> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> Message-ID: Govt controlled, please. We have tried both in NZ. Before telecom provided internet and ran lines. They were equally shit at both and apparently there were many issues for other ISPs using the lines. Now Chorus owns the and they insist that $40+/mo for wholesale DSL is fair. I think this is a sector the government would do well in. Unlike being an actual ISP there's no ambiguity (oversubscription, customer service, etc). Just provide a gigabit line with no congestion and solid uptime, or a fibre pair with solid uptime. End of story. On 1 Aug 2014 19:08, "Mark Tinka" wrote: > On Friday, August 01, 2014 08:54:07 AM mcfbbqroast . wrote: > > > This would be my humble suggestion: > > > > - lines provider runs fibre pair from each home to co. By > > default the lines provider installs a simple consumer > > terminal, with gigabit Ethernet outputs and POTS. > > > > - lines provider provides a reasonably oversubscribed > > service to soft hand over to ISPs (think 96 Gbps lines > > to 2 10gbps ports). Perhaps upgrading so such a ratio > > never becomes congested could be a requirement? > > > > - lines provider also rents individual lines to ISPs > > which they can use directly. Rent should be lower than > > soft handover. > > > > This way ISPs can easily offer services. POTS over VoIP > > can be setup on installation of the terminal (so > > handover to the ISP is seamless). Finally business and > > residential services can also be provided over the fibre > > directly (this will be attractive to ISPs with many > > ports, to reduce costs, and premium/business ISPs to add > > control). > > > > - ideally the lines provider would aid in providing cheap > > backhaul from the co (while still allowing 3rd party > > users to bring fibre in). > > Wholesale mode. Doable. > > Works best if the lines provider is not a service provider; > or regulation in your market ensures a service provider who > is also a lines provider is mandated to unbundle at > reasonable cost. > > Mark. > From mark.tinka at seacom.mu Fri Aug 1 07:44:28 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 1 Aug 2014 09:44:28 +0200 Subject: Muni Fiber and Politics In-Reply-To: References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010908.07452.mark.tinka@seacom.mu> Message-ID: <201408010944.28220.mark.tinka@seacom.mu> On Friday, August 01, 2014 09:30:57 AM mcfbbqroast . wrote: > I think this is a sector the > government would do well in. Unlike being an actual ISP > there's no ambiguity (oversubscription, customer > service, etc). Just provide a gigabit line with no > congestion and solid uptime, or a fibre pair with solid > uptime. End of story. Couldn't agree more :-). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From josmon at rigozsaurus.com Fri Aug 1 08:34:33 2014 From: josmon at rigozsaurus.com (John Osmon) Date: Fri, 1 Aug 2014 02:34:33 -0600 Subject: Muni Fiber and Politics In-Reply-To: <201408010944.28220.mark.tinka@seacom.mu> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010908.07452.mark.tinka@seacom.mu> <201408010944.28220.mark.tinka@seacom.mu> Message-ID: <20140801083433.GA27811@jeeves.rigozsaurus.com> Anyone know how to summarize this end game well enough for state/federal legislators? Or raise enough money and direction to provide sufficient "lobbying?" Wasn't KC asking for a dept of the Internet at the NANOG 20 in DC? On Fri, Aug 01, 2014 at 09:44:28AM +0200, Mark Tinka wrote: > On Friday, August 01, 2014 09:30:57 AM mcfbbqroast . wrote: > > > I think this is a sector the > > government would do well in. Unlike being an actual ISP > > there's no ambiguity (oversubscription, customer > > service, etc). Just provide a gigabit line with no > > congestion and solid uptime, or a fibre pair with solid > > uptime. End of story. > > Couldn't agree more :-). > > Mark. From rdrake at direcpath.com Fri Aug 1 11:12:22 2014 From: rdrake at direcpath.com (Robert Drake) Date: Fri, 1 Aug 2014 07:12:22 -0400 Subject: Greenfield Access Network In-Reply-To: References: Message-ID: <53DB7616.1070602@direcpath.com> On 7/31/2014 12:07 PM, Colton Conor wrote: > 1. The article mentioned DHCP doesn't do the other part of what PPPoE or > PPPoA does, which is generate RADIUS accounting records that give us the > bandwidth information. So that?s one of the main challenges in switching to > a DHCP based system. So, how do you handle bandwidth tracking in an all > DHCP environment then? If I want to track how many GB a customer used last > month, or the average Mbps used how do you do so? A medium sized NMS could do 95th percentile usage on 10k ports. Normally I wouldn't want to use an NMS for billing usage but the capability is there. > 2. I liked your option 82 example, and that works well for DSL networks > where one port is tied to one customer. But how does option 82 work when > you have multiple customers hanging off a GPON port? What does GPON use a > subport identifier? The ONT can put an option-82 header on the packet and tag whichever port the DHCP request came from. > 3. You mentioned, DHCP is again, not a authentication protocol. So what > handles authentication then if only DHCP is used, and there are no > usernames and passwords? I guess for DSL networks you can enable or disable > the port to allow or disallow access, and Option 82 for identification? I > assume you wouldn't want to shut off the GPON OLT port if one customer > wasn't paying their bill as it would affect the other customers on that > port. I assume access vendors allow you to shut down the sub port or ONT in > this situation for GPON? Still that seems messy having to login to a shelf > or EMS system or API to an EMS system especially if you have multiple > access vendors in a network. Is there a way to do authentication with DHCP? > What about open networks like wifi where anyone can connect, so you don't > have the ability to turn of the port or disable the end device? Most GPON vendors either support TR-69 or some other means to remote provision the ONTs. You can use the DHCP option-82 to identify who a customer is and then send their ONT a specific config. Like DOCSIS you could make a disable profile, or you could make them hop on a different VLAN that redirects all traffic to a billing page or something. There is also DPoE/DPoG (DOCSIS Provisioning of EPON/GPON) that converts DOCSIS provisioning into something PON can use. > 4. I don't think anyone is buying a BRAS anymore, but looks like Cisco, > Juniper, and ALU have what they call BGN, Broadband Subscriber Management, > and other similar software. How are these different from BRAS functionality? I've got no experience with BRAS so I'm not sure. I think the ASR1k can do pppoe termination if you want a Cisco solution. > So it looks like there are open source and commercial solutions for DHCP > and DNS. Some providers like Infloblox seems to integrate all these into > one. Infoblox, Bluecat, 6connect, Incognito, Promptlink, VitalQIP, Cisco BAC There are a bunch of vendors and they all have their ups and downs. A DHCP system can be an expensive part of your network and it's a very critical one, so you might want to look at multiple offerings before deciding. > So if we have a core router that speaks BGP, a 10G aggregation switch to > aggregate the the chassis, and a device like Infloblox or the other > commercial solutions you mentioned that do DHCP/DNS, is there anything else > that is needed besides the access gear already mentioned in the > assumptions? Are these large and expensive commercial BGN/Broadband > Subscriber management products a thing of the past or still very relevant > in todays environment? > > Make sure you've got your provisioning system planned out and working before you run with it. Your DHCP systems will tie heavily into your OSS so you'll need to work that piece out. If you use an NMS for billing reasons then that will need to tie into the OSS as well. It's always possible to roll out a network that just works, turn up a bunch of devices and then realize a critical piece is broken or badly designed. You don't want to be in a position where everything works except.... and you can't take it down because everyone is using it. From owen at delong.com Fri Aug 1 14:44:29 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Aug 2014 07:44:29 -0700 Subject: Muni Fiber and Politics In-Reply-To: <201408010908.07452.mark.tinka@seacom.mu> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> Message-ID: <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> On Aug 1, 2014, at 12:08 AM, Mark Tinka wrote: > On Friday, August 01, 2014 08:54:07 AM mcfbbqroast . wrote: > >> This would be my humble suggestion: >> >> - lines provider runs fibre pair from each home to co. By >> default the lines provider installs a simple consumer >> terminal, with gigabit Ethernet outputs and POTS. The problem with this is it allows the lines provider to dictate the technology to be used by all higher-layer service providers. IMHO, this is undesirable, because it blocks innovation and service differentiation on this basis. Ideally, the lines provider is simply a lines provider and provides a number of dark fiber pairs between the serving wire center (what you called a CO) and each premise served by the SWC. Termination at the customer end should be a box in which a customer terminal can be installed and the fibers should all be terminated on some standard form of patch panel (ST or LC probably preferred, but others may be acceptable). It would then be up to the service provider(s) to provide the terminals and decide between customer self-install and truck-rolls for service turn-up. >> - lines provider provides a reasonably oversubscribed >> service to soft hand over to ISPs (think 96 Gbps lines >> to 2 10gbps ports). Perhaps upgrading so such a ratio >> never becomes congested could be a requirement? Putting the lines provider into this part of the equation preserves many of the problems with the existing model. >> - lines provider also rents individual lines to ISPs >> which they can use directly. Rent should be lower than >> soft handover. Now you?ve got competition operating at a disadvantage to the incumbent lines provider, preserving this aspect of the problems with the current system. IMHO, this should be the only service the lines provider is allowed to sell. In that way, the lines provider is not in competition with its wholesale customers. If you want examples of how well the model you propose tends to work, look no further than the incredible problematic nature of MCI?s attempt to offer local phone service over Pacific Bell/SBC/AT&T circuits. >> This way ISPs can easily offer services. POTS over VoIP >> can be setup on installation of the terminal (so >> handover to the ISP is seamless). Finally business and >> residential services can also be provided over the fibre >> directly (this will be attractive to ISPs with many >> ports, to reduce costs, and premium/business ISPs to add >> control). This is also true of dark fiber pairs, with the added advantage that the service providers can differentiate themselves on chosen technology, can offer innovative services and can leverage existing infrastructure to deploy newer technologies as they develop. >> >> - ideally the lines provider would aid in providing cheap >> backhaul from the co (while still allowing 3rd party >> users to bring fibre in). I don?t think this is so ideal. Again, it creates an opportunity for the lines provider to leverage their infrastructure in a way that it can become a barrier to competition. This is, IMHO, the opposite of good. > Wholesale mode. Doable. > > Works best if the lines provider is not a service provider; > or regulation in your market ensures a service provider who > is also a lines provider is mandated to unbundle at > reasonable cost. Even when mandated to unbundle at a reasonable cost, often other games are played (trouble ticket for service billed by lines provider resolved in a day, trouble ticket for service on unbundled element resolved in 14 days, etc.). IMHO, experience has taught us that the lines provider (or as I prefer to call them, the Layer 1 infrastructure provider) must be prohibited from playing at the higher layers. Owen From corey.touchet at corp.totalserversolutions.com Fri Aug 1 15:04:16 2014 From: corey.touchet at corp.totalserversolutions.com (Corey Touchet) Date: Fri, 1 Aug 2014 15:04:16 +0000 Subject: Muni Fiber and Politics In-Reply-To: <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> Message-ID: Not really, the law can say must provide standards compliant access for interconnections with a agreed upon base set of features it must support. Any provider that wants something extra can negotiate the reasonable costs of implementation. On 8/1/14, 8:44 AM, "Owen DeLong" wrote: > >On Aug 1, 2014, at 12:08 AM, Mark Tinka wrote: > >> On Friday, August 01, 2014 08:54:07 AM mcfbbqroast . wrote: >> >>> This would be my humble suggestion: >>> >>> - lines provider runs fibre pair from each home to co. By >>> default the lines provider installs a simple consumer >>> terminal, with gigabit Ethernet outputs and POTS. > >The problem with this is it allows the lines provider to dictate >the technology to be used by all higher-layer service providers. > >IMHO, this is undesirable, because it blocks innovation and >service differentiation on this basis. > >Ideally, the lines provider is simply a lines provider and provides >a number of dark fiber pairs between the serving wire center (what >you called a CO) and each premise served by the SWC. > >Termination at the customer end should be a box in which a customer >terminal can be installed and the fibers should all be terminated on >some standard form of patch panel (ST or LC probably preferred, >but others may be acceptable). > >It would then be up to the service provider(s) to provide the terminals >and decide between customer self-install and truck-rolls for service >turn-up. > >>> - lines provider provides a reasonably oversubscribed >>> service to soft hand over to ISPs (think 96 Gbps lines >>> to 2 10gbps ports). Perhaps upgrading so such a ratio >>> never becomes congested could be a requirement? > >Putting the lines provider into this part of the equation preserves >many of the problems with the existing model. > >>> - lines provider also rents individual lines to ISPs >>> which they can use directly. Rent should be lower than >>> soft handover. > >Now you?ve got competition operating at a disadvantage to the >incumbent lines provider, preserving this aspect of the problems >with the current system. IMHO, this should be the only service >the lines provider is allowed to sell. In that way, the lines provider >is not in competition with its wholesale customers. > >If you want examples of how well the model you propose tends to >work, look no further than the incredible problematic nature of MCI?s >attempt to offer local phone service over Pacific Bell/SBC/AT&T >circuits. > >>> This way ISPs can easily offer services. POTS over VoIP >>> can be setup on installation of the terminal (so >>> handover to the ISP is seamless). Finally business and >>> residential services can also be provided over the fibre >>> directly (this will be attractive to ISPs with many >>> ports, to reduce costs, and premium/business ISPs to add >>> control). > >This is also true of dark fiber pairs, with the added advantage >that the service providers can differentiate themselves on >chosen technology, can offer innovative services and can >leverage existing infrastructure to deploy newer technologies as >they develop. > >>> >>> - ideally the lines provider would aid in providing cheap >>> backhaul from the co (while still allowing 3rd party >>> users to bring fibre in). > >I don?t think this is so ideal. Again, it creates an opportunity for >the lines provider to leverage their infrastructure in a way that it >can become a barrier to competition. This is, IMHO, the opposite >of good. > >> Wholesale mode. Doable. >> >> Works best if the lines provider is not a service provider; >> or regulation in your market ensures a service provider who >> is also a lines provider is mandated to unbundle at >> reasonable cost. > >Even when mandated to unbundle at a reasonable cost, often >other games are played (trouble ticket for service billed by >lines provider resolved in a day, trouble ticket for service on >unbundled element resolved in 14 days, etc.). > >IMHO, experience has taught us that the lines provider (or as I >prefer to call them, the Layer 1 infrastructure provider) must be >prohibited from playing at the higher layers. > >Owen > From owen at delong.com Fri Aug 1 15:30:08 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Aug 2014 08:30:08 -0700 Subject: Muni Fiber and Politics In-Reply-To: References: Message-ID: <543B75D3-D01B-4748-9A16-CA8550AC5A42@delong.com> As I said, for an example of just how well such an environment works, one need look no further than what happened when MCI attempted to use Pacific Bell/SBC/AT&T unbundled copper pairs to provide local telephone service. In reality, this turns out to be horrible for the customer, unpleasant at best for the competitive service provider, and one of the few areas where I?ve ever seen a traditional telco be truly innovative. Pacific Bell/SBC/AT&T found the most innovative ways to stall/finger-point/avoid responsibility that I have ever seen. Watching the tap-dance they did in front of the PUC at subsequent hearings where nobody seemed to have the sbupoena?d data among the 20+ witnesses that they presented was quite amusing to me. The ALJ was not so amused, but the fine imposed was barely a slap on the wrist and easily less than the revenue impact to the competitive access providers. Believe me when I say that such a law is almost entirely unenforceable and not really worth the paper it is written on if the layer 1 provider is truly motivated to stifle competition which is dependent on their unbundled elements. Canada is struggling with some similar pains under their competitive access cable markets. Owen On Aug 1, 2014, at 8:04 AM, Corey Touchet wrote: > Not really, the law can say must provide standards compliant access for > interconnections with a agreed upon base set of features it must support. > Any provider that wants something extra can negotiate the reasonable costs > of implementation. > > > > > On 8/1/14, 8:44 AM, "Owen DeLong" wrote: > >> >> On Aug 1, 2014, at 12:08 AM, Mark Tinka wrote: >> >>> On Friday, August 01, 2014 08:54:07 AM mcfbbqroast . wrote: >>> >>>> This would be my humble suggestion: >>>> >>>> - lines provider runs fibre pair from each home to co. By >>>> default the lines provider installs a simple consumer >>>> terminal, with gigabit Ethernet outputs and POTS. >> >> The problem with this is it allows the lines provider to dictate >> the technology to be used by all higher-layer service providers. >> >> IMHO, this is undesirable, because it blocks innovation and >> service differentiation on this basis. >> >> Ideally, the lines provider is simply a lines provider and provides >> a number of dark fiber pairs between the serving wire center (what >> you called a CO) and each premise served by the SWC. >> >> Termination at the customer end should be a box in which a customer >> terminal can be installed and the fibers should all be terminated on >> some standard form of patch panel (ST or LC probably preferred, >> but others may be acceptable). >> >> It would then be up to the service provider(s) to provide the terminals >> and decide between customer self-install and truck-rolls for service >> turn-up. >> >>>> - lines provider provides a reasonably oversubscribed >>>> service to soft hand over to ISPs (think 96 Gbps lines >>>> to 2 10gbps ports). Perhaps upgrading so such a ratio >>>> never becomes congested could be a requirement? >> >> Putting the lines provider into this part of the equation preserves >> many of the problems with the existing model. >> >>>> - lines provider also rents individual lines to ISPs >>>> which they can use directly. Rent should be lower than >>>> soft handover. >> >> Now you?ve got competition operating at a disadvantage to the >> incumbent lines provider, preserving this aspect of the problems >> with the current system. IMHO, this should be the only service >> the lines provider is allowed to sell. In that way, the lines provider >> is not in competition with its wholesale customers. >> >> If you want examples of how well the model you propose tends to >> work, look no further than the incredible problematic nature of MCI?s >> attempt to offer local phone service over Pacific Bell/SBC/AT&T >> circuits. >> >>>> This way ISPs can easily offer services. POTS over VoIP >>>> can be setup on installation of the terminal (so >>>> handover to the ISP is seamless). Finally business and >>>> residential services can also be provided over the fibre >>>> directly (this will be attractive to ISPs with many >>>> ports, to reduce costs, and premium/business ISPs to add >>>> control). >> >> This is also true of dark fiber pairs, with the added advantage >> that the service providers can differentiate themselves on >> chosen technology, can offer innovative services and can >> leverage existing infrastructure to deploy newer technologies as >> they develop. >> >>>> >>>> - ideally the lines provider would aid in providing cheap >>>> backhaul from the co (while still allowing 3rd party >>>> users to bring fibre in). >> >> I don?t think this is so ideal. Again, it creates an opportunity for >> the lines provider to leverage their infrastructure in a way that it >> can become a barrier to competition. This is, IMHO, the opposite >> of good. >> >>> Wholesale mode. Doable. >>> >>> Works best if the lines provider is not a service provider; >>> or regulation in your market ensures a service provider who >>> is also a lines provider is mandated to unbundle at >>> reasonable cost. >> >> Even when mandated to unbundle at a reasonable cost, often >> other games are played (trouble ticket for service billed by >> lines provider resolved in a day, trouble ticket for service on >> unbundled element resolved in 14 days, etc.). >> >> IMHO, experience has taught us that the lines provider (or as I >> prefer to call them, the Layer 1 infrastructure provider) must be >> prohibited from playing at the higher layers. >> >> Owen >> From Lee at asgard.org Fri Aug 1 16:01:48 2014 From: Lee at asgard.org (Lee Howard) Date: Fri, 01 Aug 2014 12:01:48 -0400 Subject: Carrier Grade NAT In-Reply-To: References: Message-ID: On 7/30/14 3:45 PM, "joshua rayburn" wrote: > >Starting in 3.10 code you can utilize Bulk Port Allocation to carve out >small consecutive port bundles for end users as to not mess up SIP >functionsand High Speed Logging to log individual customers ports for law >enforcement needs without overrunning your logging server. http://tools.ietf.org/html/rfc6056 documents a security concern with bulk port assignments. Lee From jra at baylink.com Fri Aug 1 16:09:05 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 01 Aug 2014 12:09:05 -0400 Subject: Muni Fiber and Politics In-Reply-To: <201408010740.50741.mark.tinka@seacom.mu> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <10C051BE-0617-4382-B1CB-88E031D45128@ufp.org> <20140731120128.GA24465@besserwisser.org> <201408010740.50741.mark.tinka@seacom.mu> Message-ID: <1d935a3e-8f9d-4511-86ff-12ab72ea8cc9@email.android.com> What is the MRC of a 10GE port? On August 1, 2014 1:40:50 AM EDT, Mark Tinka wrote: >On Thursday, July 31, 2014 02:01:28 PM M?ns Nilsson wrote: > >> It is better, both for the customer and the provider. > >If the provider is able to deliver 1Gbps to every home >(either on copper or fibre) with little to no uplink >oversubscription (think 44x customer-facing Gig-E ports + 4x >10Gbps uplink ports), essentially, there is no limit to what >services a provider and its partners can offer to its >customers. > >Mark. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From owen at delong.com Fri Aug 1 16:34:00 2014 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Aug 2014 09:34:00 -0700 Subject: Muni Fiber and Politics In-Reply-To: <1d935a3e-8f9d-4511-86ff-12ab72ea8cc9@email.android.com> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <10C051BE-0617-4382-B1CB-88E031D45128@ufp.org> <20140731120128.GA24465@besserwisser.org> <201408010740.50741.mark.tinka@seacom.mu> <1d935a3e-8f9d-4511-86ff-12ab72ea8cc9@email.android.com> Message-ID: <806B505C-EBA4-44F5-B7C7-192F82F54FC9@delong.com> Today, somewhere around $6,000 or more depending on provider, location, etc. That?s with IP transit included. Owen On Aug 1, 2014, at 9:09 AM, Jay Ashworth wrote: > What is the MRC of a 10GE port? > > On August 1, 2014 1:40:50 AM EDT, Mark Tinka wrote: >> On Thursday, July 31, 2014 02:01:28 PM M?ns Nilsson wrote: >> >>> It is better, both for the customer and the provider. >> >> If the provider is able to deliver 1Gbps to every home >> (either on copper or fibre) with little to no uplink >> oversubscription (think 44x customer-facing Gig-E ports + 4x >> 10Gbps uplink ports), essentially, there is no limit to what >> services a provider and its partners can offer to its >> customers. >> >> Mark. > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. From jra at baylink.com Fri Aug 1 17:17:24 2014 From: jra at baylink.com (Jay Ashworth) Date: Fri, 01 Aug 2014 13:17:24 -0400 Subject: Muni Fiber and Politics In-Reply-To: <806B505C-EBA4-44F5-B7C7-192F82F54FC9@delong.com> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <10C051BE-0617-4382-B1CB-88E031D45128@ufp.org> <20140731120128.GA24465@besserwisser.org> <201408010740.50741.mark.tinka@seacom.mu> <1d935a3e-8f9d-4511-86ff-12ab72ea8cc9@email.android.com> <806B505C-EBA4-44F5-B7C7-192F82F54FC9@delong.com> Message-ID: <4f33b312-f1de-46c6-8c97-97a2fc121ca6@email.android.com> So we'll assume we could get 4 for 22k to make the arithmetic easy, and that means if we can put 44 people on that, that the MRC cost is 500 dollars a month for a gigabit. That is clearly not consumer pricing. Was consumer pricing the assertion? On August 1, 2014 12:34:00 PM EDT, Owen DeLong wrote: >Today, somewhere around $6,000 or more depending on provider, location, >etc. > >That?s with IP transit included. > >Owen > >On Aug 1, 2014, at 9:09 AM, Jay Ashworth wrote: > >> What is the MRC of a 10GE port? >> >> On August 1, 2014 1:40:50 AM EDT, Mark Tinka >wrote: >>> On Thursday, July 31, 2014 02:01:28 PM M?ns Nilsson wrote: >>> >>>> It is better, both for the customer and the provider. >>> >>> If the provider is able to deliver 1Gbps to every home >>> (either on copper or fibre) with little to no uplink >>> oversubscription (think 44x customer-facing Gig-E ports + 4x >>> 10Gbps uplink ports), essentially, there is no limit to what >>> services a provider and its partners can offer to its >>> customers. >>> >>> Mark. >> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From cscora at apnic.net Fri Aug 1 18:12:11 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 2 Aug 2014 04:12:11 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201408011812.s71ICBpJ030596@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, TRNOG, 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 Aug, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 505153 Prefixes after maximum aggregation: 196190 Deaggregation factor: 2.57 Unique aggregates announced to Internet: 248397 Total ASes present in the Internet Routing Table: 47367 Prefixes per ASN: 10.66 Origin-only ASes present in the Internet Routing Table: 36014 Origin ASes announcing only one prefix: 16383 Transit ASes present in the Internet Routing Table: 6123 Transit-only ASes present in the Internet Routing Table: 172 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 2030 Unregistered ASNs in the Routing Table: 452 Number of 32-bit ASNs allocated by the RIRs: 7109 Number of 32-bit ASNs visible in the Routing Table: 5230 Prefixes from 32-bit ASNs in the Routing Table: 18854 Number of bogon 32-bit ASNs visible in the Routing Table: 470 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 395 Number of addresses announced to Internet: 2710217476 Equivalent to 161 /8s, 138 /16s and 163 /24s Percentage of available address space announced: 73.2 Percentage of allocated address space announced: 73.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.7 Total number of prefixes smaller than registry allocations: 173657 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 121721 Total APNIC prefixes after maximum aggregation: 35794 APNIC Deaggregation factor: 3.40 Prefixes being announced from the APNIC address blocks: 125436 Unique aggregates announced from the APNIC address blocks: 51941 APNIC Region origin ASes present in the Internet Routing Table: 4963 APNIC Prefixes per ASN: 25.27 APNIC Region origin ASes announcing only one prefix: 1228 APNIC Region transit ASes present in the Internet Routing Table: 875 Average APNIC Region AS path length visible: 4.8 Max APNIC Region AS path length visible: 24 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1025 Number of APNIC addresses announced to Internet: 734317184 Equivalent to 43 /8s, 196 /16s and 202 /24s Percentage of available APNIC address space announced: 85.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 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, 150/8, 153/8, 163/8, 171/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: 169960 Total ARIN prefixes after maximum aggregation: 84347 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 171799 Unique aggregates announced from the ARIN address blocks: 80066 ARIN Region origin ASes present in the Internet Routing Table: 16335 ARIN Prefixes per ASN: 10.52 ARIN Region origin ASes announcing only one prefix: 6120 ARIN Region transit ASes present in the Internet Routing Table: 1688 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 154 Number of ARIN addresses announced to Internet: 1090570752 Equivalent to 65 /8s, 0 /16s and 202 /24s Percentage of available ARIN address space announced: 57.7 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, 62464-63487, 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, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 124402 Total RIPE prefixes after maximum aggregation: 62985 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 129274 Unique aggregates announced from the RIPE address blocks: 81810 RIPE Region origin ASes present in the Internet Routing Table: 17723 RIPE Prefixes per ASN: 7.29 RIPE Region origin ASes announcing only one prefix: 8256 RIPE Region transit ASes present in the Internet Routing Table: 2873 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2727 Number of RIPE addresses announced to Internet: 659039108 Equivalent to 39 /8s, 72 /16s and 35 /24s Percentage of available RIPE address space announced: 95.8 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 59392-61439, 61952-62463, 196608-202239 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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 58761 Total LACNIC prefixes after maximum aggregation: 10289 LACNIC Deaggregation factor: 5.71 Prefixes being announced from the LACNIC address blocks: 66487 Unique aggregates announced from the LACNIC address blocks: 29734 LACNIC Region origin ASes present in the Internet Routing Table: 2191 LACNIC Prefixes per ASN: 30.35 LACNIC Region origin ASes announcing only one prefix: 566 LACNIC Region transit ASes present in the Internet Routing Table: 454 Average LACNIC Region AS path length visible: 4.6 Max LACNIC Region AS path length visible: 23 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1276 Number of LACNIC addresses announced to Internet: 167649792 Equivalent to 9 /8s, 254 /16s and 34 /24s Percentage of available LACNIC address space announced: 99.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 11040 Total AfriNIC prefixes after maximum aggregation: 2738 AfriNIC Deaggregation factor: 4.03 Prefixes being announced from the AfriNIC address blocks: 11762 Unique aggregates announced from the AfriNIC address blocks: 4506 AfriNIC Region origin ASes present in the Internet Routing Table: 728 AfriNIC Prefixes per ASN: 16.16 AfriNIC Region origin ASes announcing only one prefix: 213 AfriNIC Region transit ASes present in the Internet Routing Table: 159 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 48 Number of AfriNIC addresses announced to Internet: 58252288 Equivalent to 3 /8s, 120 /16s and 220 /24s Percentage of available AfriNIC address space announced: 57.9 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2948 11590 919 Korea Telecom 17974 2801 899 72 PT Telekomunikasi Indonesia 7545 2331 320 118 TPG Telecom Limited 4755 1866 392 200 TATA Communications formerly 9829 1649 1306 31 National Internet Backbone 9583 1313 103 535 Sify Limited 9498 1298 317 93 BHARTI Airtel Ltd. 7552 1235 1098 14 Viettel Corporation 4808 1207 2155 372 CNCGROUP IP network China169 24560 1153 399 191 Bharti Airtel Ltd., Telemedia 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 2943 3688 51 BellSouth.net Inc. 7029 2771 1905 301 Windstream Communications Inc 22773 2729 2940 141 Cox Communications Inc. 18566 2047 379 178 MegaPath Corporation 20115 1745 1731 546 Charter Communications 4323 1631 1072 411 tw telecom holdings, inc. 30036 1497 322 576 Mediacom Communications Corp 701 1438 11203 726 MCI Communications Services, 6983 1390 817 313 ITC^Deltacom 22561 1305 406 233 CenturyTel Internet Holdings, 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 34984 1720 265 277 TELLCOM ILETISIM HIZMETLERI A 20940 1447 563 1062 Akamai International B.V. 8402 1249 544 15 OJSC "Vimpelcom" 13188 1062 100 30 TOV "Bank-Inform" 31148 1041 45 19 Freenet Ltd. 8551 994 371 42 Bezeq International-Ltd 6849 819 356 27 JSC "Ukrtelecom" 6830 776 2335 432 Liberty Global Operations B.V 12479 767 796 59 France Telecom Espana SA 9198 598 346 28 JSC Kazakhtelecom 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 28573 3778 2030 111 NET Servi?os de Comunica??o S 10620 2939 476 214 Telmex Colombia S.A. 18881 2062 1036 22 Global Village Telecom 7303 1770 1179 237 Telecom Argentina S.A. 8151 1437 2982 418 Uninet S.A. de C.V. 6503 1090 434 62 Axtel, S.A.B. de C.V. 6147 1043 373 28 Telefonica del Peru S.A.A. 7738 977 1882 41 Telemar Norte Leste S.A. 27947 892 130 53 Telconet S.A 26615 860 2325 35 Tim Celular 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 24863 913 280 26 Link Egypt (Link.NET) 6713 673 744 37 Office National des Postes et 8452 594 958 13 TE-AS 36992 310 784 26 ETISALAT MISR 24835 306 144 9 Vodafone Data 3741 249 920 212 Internet Solutions 29571 236 22 17 Cote d'Ivoire Telecom 37054 232 19 6 Data Telecom Service 15706 187 32 6 Sudatel (Sudan Telecom Co. Lt 12258 177 27 68 MWEB CONNECT (PROPRIETARY) LI 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 28573 3778 2030 111 NET Servi?os de Comunica??o S 4766 2948 11590 919 Korea Telecom 6389 2943 3688 51 BellSouth.net Inc. 10620 2939 476 214 Telmex Colombia S.A. 17974 2801 899 72 PT Telekomunikasi Indonesia 7029 2771 1905 301 Windstream Communications Inc 22773 2729 2940 141 Cox Communications Inc. 7545 2331 320 118 TPG Telecom Limited 18881 2062 1036 22 Global Village Telecom 18566 2047 379 178 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2943 2892 BellSouth.net Inc. 17974 2801 2729 PT Telekomunikasi Indonesia 10620 2939 2725 Telmex Colombia S.A. 22773 2729 2588 Cox Communications Inc. 7029 2771 2470 Windstream Communications Inc 7545 2331 2213 TPG Telecom Limited 18881 2062 2040 Global Village Telecom 4766 2948 2029 Korea Telecom 18566 2047 1869 MegaPath Corporation 4755 1866 1666 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 5.109.32.0/19 23456 32bit Transition AS 65456 PRIVATE 5.109.96.0/19 23456 32bit Transition AS 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 55020 UNALLOCATED 8.30.123.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.240.0/20 40430 colo4jax, LLC 23.226.240.0/21 40430 colo4jax, LLC 23.226.248.0/21 40430 colo4jax, LLC 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 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:16 /9:13 /10:30 /11:91 /12:259 /13:498 /14:982 /15:1704 /16:13037 /17:7026 /18:11700 /19:24678 /20:35148 /21:37559 /22:54349 /23:47682 /24:268329 /25:798 /26:808 /27:389 /28:13 /29:18 /30:10 /31:1 /32:15 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2002 2047 MegaPath Corporation 22773 1972 2729 Cox Communications Inc. 6389 1691 2943 BellSouth.net Inc. 7029 1481 2771 Windstream Communications Inc 30036 1338 1497 Mediacom Communications Corp 11492 1185 1237 CABLE ONE, INC. 6983 1096 1390 ITC^Deltacom 34984 1048 1720 TELLCOM ILETISIM HIZMETLERI A 10620 1029 2939 Telmex Colombia S.A. 22561 1003 1305 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1315 2:657 3:3 4:15 5:1049 6:21 8:713 12:1854 13:4 14:1106 15:15 16:2 17:40 18:21 20:36 23:878 24:1748 27:1756 31:1470 32:41 33:2 34:5 36:140 37:1826 38:960 39:7 40:210 41:2663 42:259 43:156 44:15 45:45 46:2092 47:24 49:728 50:830 52:12 54:47 55:6 56:3 57:30 58:1218 59:614 60:424 61:1591 62:1251 63:1852 64:4363 65:2325 66:4229 67:2062 68:1054 69:3338 70:890 71:462 72:2020 74:2624 75:337 76:415 77:1654 78:804 79:704 80:1313 81:1217 82:769 83:771 84:768 85:1320 86:414 87:1146 88:467 89:1786 90:139 91:5713 92:771 93:1763 94:2028 95:1615 96:509 97:361 98:1109 99:49 100:65 101:700 103:5323 104:151 105:36 106:174 107:577 108:582 109:2009 110:1022 111:1333 112:666 113:857 114:772 115:1109 116:1116 117:1016 118:1503 119:1421 120:411 121:853 122:2157 123:1471 124:1427 125:1561 128:573 129:343 130:362 131:680 132:391 133:162 134:322 135:76 136:299 137:289 138:370 139:170 140:210 141:387 142:559 143:412 144:502 145:107 146:652 147:501 148:903 149:404 150:393 151:607 152:448 153:220 154:321 155:521 156:354 157:344 158:271 159:936 160:326 161:572 162:1671 163:332 164:694 165:630 166:344 167:674 168:1115 169:122 170:1380 171:183 172:62 173:1534 174:711 175:618 176:1415 177:3375 178:2073 179:789 180:1783 181:1323 182:1615 183:538 184:702 185:1909 186:2913 187:1652 188:2162 189:1471 190:7647 191:665 192:7444 193:5506 194:4045 195:3566 196:1430 197:668 198:5112 199:5545 200:6322 201:2735 202:9169 203:8997 204:4551 205:2636 206:2966 207:2950 208:3969 209:3745 210:3167 211:1750 212:2316 213:2115 214:878 215:86 216:5705 217:1683 218:615 219:331 220:1282 221:626 222:358 223:597 End of report From shawnl at up.net Fri Aug 1 20:18:18 2014 From: shawnl at up.net (Shawn L) Date: Fri, 1 Aug 2014 16:18:18 -0400 Subject: Carrier Grade NAT In-Reply-To: References: Message-ID: Slightly off-topic but what are people using as a cpe device in a dual-stack scenario like this? On Friday, August 1, 2014, Lee Howard wrote: > > > On 7/30/14 3:45 PM, "joshua rayburn" > > wrote: > > > > >Starting in 3.10 code you can utilize Bulk Port Allocation to carve out > >small consecutive port bundles for end users as to not mess up SIP > >functionsand High Speed Logging to log individual customers ports for law > >enforcement needs without overrunning your logging server. > > > http://tools.ietf.org/html/rfc6056 documents a security concern with bulk > port assignments. > > Lee > > > From bicknell at ufp.org Fri Aug 1 20:25:27 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 1 Aug 2014 15:25:27 -0500 Subject: Muni Fiber and Politics In-Reply-To: <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> Message-ID: On Aug 1, 2014, at 9:44 AM, Owen DeLong wrote: > If you want examples of how well the model you propose tends to > work, look no further than the incredible problematic nature of MCI?s > attempt to offer local phone service over Pacific Bell/SBC/AT&T > circuits. [snip] > IMHO, experience has taught us that the lines provider (or as I > prefer to call them, the Layer 1 infrastructure provider) must be > prohibited from playing at the higher layers. Owen has some really good points here, but may be overstating his case a smidge. If a private company is the Layer 1 (?lines provider?) entity, there will always be a temptation into moving up the stack, and up the value chain. The issue in his first example is that the companies involved compete for higher layer services. Municipalities can be different. It?s possible to write into law that they can offer L1 and L2 services, but never anything higher. There?s also a built in disincentive to risk tax dollars more speculative, but possibly more profitable ventures. So while I agree with Owen that a dark fiber model is preferred, and should be offered, I don?t have a problem with a municipal network also offering Layer 2. In fact, I see some potential wins, imagine a network where you could chose to buy dark fiber access, or a channel on a GPON system? If the customer wants GE/10GE, you get dark fiber, and if they want 50Mbps, you get a GPON channel for less (yes, that?s an assumption) cost. I can also see how some longer-distance links, imagine a link from home to office across 30-40 miles, might be cheaper to deliver as 100M VLAN than raw dark fiber and having to buy long reach optics. I can never see a case where letting them play at Layer 3 or above helps. That?s bad news, stay away. But I think some well crafted L2 services could actually _expand_ consumer choice. I mean running a dark fiber GigE to supply voice only makes no sense, but a 10M channel on a GPON serving a VoIP box may? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From joly at punkcast.com Fri Aug 1 20:24:06 2014 From: joly at punkcast.com (Joly MacFie) Date: Fri, 1 Aug 2014 16:24:06 -0400 Subject: Muni Fiber and Politics In-Reply-To: <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> Message-ID: On Fri, Aug 1, 2014 at 10:44 AM, Owen DeLong wrote: > MHO, experience has taught us that the lines provider (or as I > prefer to call them, the Layer 1 infrastructure provider) must be > prohibited from playing at the higher layers > A few years back Fred Goldstein proposed defining a Layer 1 infrastructure provider as a "LoopCo", where the local loop is passively provided to service providers to light it as they see fit. He even wrote draft legislation, where the incumbent LEC is divided into a "Facilities Entity" and a "Services Entity": http://www.ionary.com/separationbillproposal.htm That proposal generally requires something like a CLEC to light the wire locally, and makes CLECs viable again. He has also proposed requiring ILECs (and cablecos) to provide low-layer (layer 2, mostly) common carriage on an open basis; as filed in the current NN docket: http://www.ionary.com/separationbillproposal.htm j -- --------------------------------------------------------------- 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 khelms at zcorum.com Fri Aug 1 20:32:37 2014 From: khelms at zcorum.com (Scott Helms) Date: Fri, 1 Aug 2014 16:32:37 -0400 Subject: Muni Fiber and Politics In-Reply-To: References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> Message-ID: > > > > I can never see a case where letting them play at Layer 3 or above helps. > That?s bad news, stay away. But I think some well crafted L2 services > could actually _expand_ consumer choice. I mean running a dark fiber > GigE to supply voice only makes no sense, but a 10M channel on a GPON > serving a VoIP box may? > Even in those cases where there isn't a layer 3 operator nor a chance for a viable resale of layer 1/2 services. From cidr-report at potaroo.net Fri Aug 1 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 Aug 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201408012200.s71M00qS013033@wattle.apnic.net> This report has been generated at Fri Aug 1 21:13:59 2014 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 25-07-14 508935 285928 26-07-14 508775 286040 27-07-14 508959 286213 28-07-14 509275 286189 29-07-14 509477 286110 30-07-14 509841 286214 31-07-14 510150 286361 01-08-14 510519 286381 AS Summary 47759 Number of ASes in routing system 19365 Number of ASes announcing only one prefix 3794 Largest number of prefixes announced by an AS AS28573: NET Servi?os de Comunica??o S.A.,BR 120495616 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 01Aug14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 510651 286295 224356 43.9% All ASes AS28573 3794 214 3580 94.4% NET Servi?os de Comunica??o S.A.,BR AS6389 2943 80 2863 97.3% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2801 190 2611 93.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS7029 2887 485 2402 83.2% WINDSTREAM - Windstream Communications Inc,US AS4766 2949 928 2021 68.5% KIXS-AS-KR Korea Telecom,KR AS18881 2062 43 2019 97.9% Global Village Telecom,BR AS7545 2347 677 1670 71.2% TPG-INTERNET-AP TPG Telecom Limited,AU AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation,US AS10620 2939 1463 1476 50.2% Telmex Colombia S.A.,CO AS7303 1775 438 1337 75.3% Telecom Argentina S.A.,AR AS22773 2725 1401 1324 48.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS4755 1866 594 1272 68.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4323 1642 424 1218 74.2% TWTC - tw telecom holdings, inc.,US AS6983 1390 314 1076 77.4% ITCDELTA - Earthlink, Inc.,US AS22561 1305 242 1063 81.5% AS22561 - CenturyTel Internet Holdings, Inc.,US AS7552 1261 237 1024 81.2% VIETEL-AS-AP Viettel Corporation,VN AS9829 1653 738 915 55.4% BSNL-NIB National Internet Backbone,IN AS6147 1043 147 896 85.9% Telefonica del Peru S.A.A.,PE AS38285 956 112 844 88.3% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS24560 1153 345 808 70.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS4808 1207 416 791 65.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS7738 977 190 787 80.6% Telemar Norte Leste S.A.,BR AS4788 1023 261 762 74.5% TMNET-AS-AP TM Net, Internet Service Provider,MY AS8151 1450 691 759 52.3% Uninet S.A. de C.V.,MX AS18101 947 189 758 80.0% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS9808 1101 376 725 65.8% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS26615 860 136 724 84.2% Tim Celular S.A.,BR AS11492 1237 522 715 57.8% CABLEONE - CABLE ONE, INC.,US AS701 1438 726 712 49.5% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US AS27738 772 64 708 91.7% Ecuadortelecom S.A.,EC Total 52550 13208 39342 74.9% Top 30 total Possible Bogus Routes 23.226.240.0/20 AS40430 -Reserved AS-,ZZ 23.226.240.0/21 AS40430 -Reserved AS-,ZZ 23.226.248.0/21 AS40430 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.190.1.0/24 AS37076 -Reserved AS-,ZZ 41.190.2.0/24 AS37076 -Reserved AS-,ZZ 41.190.3.0/24 AS37076 -Reserved AS-,ZZ 41.190.4.0/22 AS37076 -Reserved AS-,ZZ 41.190.4.0/24 AS37076 -Reserved AS-,ZZ 41.190.5.0/24 AS37076 -Reserved AS-,ZZ 41.190.8.0/24 AS37076 -Reserved AS-,ZZ 41.190.10.0/23 AS37076 -Reserved AS-,ZZ 41.190.12.0/24 AS37076 -Reserved AS-,ZZ 41.190.13.0/24 AS37076 -Reserved AS-,ZZ 41.190.14.0/24 AS37076 -Reserved AS-,ZZ 41.190.16.0/20 AS37076 -Reserved AS-,ZZ 41.190.72.0/24 AS37451 CongoTelecom,CG 41.190.73.0/24 AS37451 CongoTelecom,CG 41.190.74.0/24 AS37451 CongoTelecom,CG 41.190.75.0/24 AS37451 CongoTelecom,CG 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.197.0.0/16 AS36934 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.193.160.0/19 AS24801 -Reserved AS-,ZZ 62.193.160.0/20 AS24801 -Reserved AS-,ZZ 62.193.176.0/20 AS24801 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.111.160.0/20 AS40551 -Reserved AS-,ZZ 64.111.160.0/24 AS40551 -Reserved AS-,ZZ 64.111.161.0/24 AS40551 -Reserved AS-,ZZ 64.111.162.0/24 AS40551 -Reserved AS-,ZZ 64.111.167.0/24 AS40551 -Reserved AS-,ZZ 64.111.169.0/24 AS40551 -Reserved AS-,ZZ 64.111.170.0/24 AS40551 -Reserved AS-,ZZ 64.111.171.0/24 AS40551 -Reserved AS-,ZZ 64.111.172.0/24 AS40551 -Reserved AS-,ZZ 64.111.173.0/24 AS40551 -Reserved AS-,ZZ 64.111.174.0/24 AS40551 -Reserved AS-,ZZ 64.111.175.0/24 AS40551 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.6.176.0/20 AS13223 BBTECNETWORKS-HK RM18, 9/F., Kwan Yick Building Phase 1, 430-440A Des Voeux Rd. West.,HK 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 -Reserved AS-,ZZ 74.120.214.0/23 AS32326 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 89.207.8.0/21 AS3292 TDC TDC A/S,DK 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.228.160.0/24 AS56815 -Reserved AS-,ZZ 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 95.215.140.0/22 AS48949 -Reserved AS-,ZZ 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN 103.6.228.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.9.108.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.9.140.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.9.141.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.9.142.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.9.143.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP 103.18.92.0/22 AS13269 103.18.92.0/24 AS13269 103.18.94.0/24 AS13269 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.25.120.0/22 AS13280 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 162.218.168.0/21 AS40430 -Reserved AS-,ZZ 162.218.175.0/24 AS40430 -Reserved AS-,ZZ 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 185.65.208.0/22 AS25394 MK-NETZDIENSTE-AS AS for MK Netzdienste GmbH & Co. KG,DE 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.243.166.0/24 AS44093 -Reserved AS-,ZZ 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.126.251.0/24 AS50818 -Reserved AS-,ZZ 194.146.35.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR 194.146.36.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.39.252.0/23 AS29004 -Reserved AS-,ZZ 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.245.98.0/23 AS48918 GLOBALWAYS GLOBALWAYS AG,DE 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.254.96.0/20 AS40430 -Reserved AS-,ZZ 198.254.96.0/22 AS40430 -Reserved AS-,ZZ 198.254.100.0/22 AS40430 -Reserved AS-,ZZ 198.254.104.0/21 AS40430 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.50.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.10.94.0/23 AS30097 NUWAVE - NuWave,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.155.28.0/22 AS40925 -Reserved AS-,ZZ 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.209.224.0/19 AS19513 -Reserved AS-,ZZ 209.209.248.0/23 AS19513 -Reserved AS-,ZZ 209.209.250.0/23 AS19513 -Reserved AS-,ZZ 209.209.251.0/24 AS19513 -Reserved AS-,ZZ 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 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 cidr-report at potaroo.net Fri Aug 1 22:00:02 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 Aug 2014 22:00:02 GMT Subject: BGP Update Report Message-ID: <201408012200.s71M02G3013047@wattle.apnic.net> BGP Update Report Interval: 12-Jul-14 -to- 19-Jul-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS12858 93683 3.5% 5510.8 -- MYNET A.S.,TR 2 - AS9829 75620 2.8% 53.7 -- BSNL-NIB National Internet Backbone,IN 3 - AS14287 48903 1.8% 8150.5 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 4 - AS1659 47616 1.8% 189.0 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW 5 - AS38141 47282 1.8% 5253.6 -- CITRAMEDIA-AS-ID PT. Citramedia Network,ID 6 - AS8402 33111 1.2% 48.8 -- CORBINA-AS OJSC "Vimpelcom",RU 7 - AS28573 27839 1.0% 8.1 -- NET Servi?os de Comunica??o S.A.,BR 8 - AS57320 26056 1.0% 1532.7 -- T-TELECOM-MNT-AS Ionit-telecom Ltd.,RU 9 - AS26769 24230 0.9% 356.3 -- BANDCON - Bandcon,US 10 - AS647 23081 0.9% 162.5 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center,US 11 - AS23752 19644 0.7% 159.7 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 12 - AS45899 17566 0.7% 41.0 -- VNPT-AS-VN VNPT Corp,VN 13 - AS4775 16355 0.6% 778.8 -- GLOBE-TELECOM-AS Globe Telecoms,PH 14 - AS7029 14465 0.5% 4.0 -- WINDSTREAM - Windstream Communications Inc,US 15 - AS25003 12854 0.5% 1168.5 -- INTERNET_BINAT Internet Binat Ltd,IL 16 - AS7552 12811 0.5% 10.4 -- VIETEL-AS-AP Viettel Corporation,VN 17 - AS25184 12742 0.5% 97.3 -- AFRANET AFRANET Co. Tehran, Iran,IR 18 - AS42337 12067 0.5% 95.8 -- RESPINA-AS Respina Networks & Beyond PJSC,IR 19 - AS8151 11955 0.5% 10.8 -- Uninet S.A. de C.V.,MX 20 - AS4766 10294 0.4% 3.6 -- KIXS-AS-KR Korea Telecom,KR TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS54465 8523 0.3% 8523.0 -- QPM-AS-1 - QuickPlay Media Inc.,US 2 - AS6459 8298 0.3% 8298.0 -- TRANSBEAM - I-2000, Inc.,US 3 - AS14287 48903 1.8% 8150.5 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 4 - AS18135 7821 0.3% 7821.0 -- BTV BTV Cable television,JP 5 - AS3 7265 0.3% 5212.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 6 - AS12858 93683 3.5% 5510.8 -- MYNET A.S.,TR 7 - AS38141 47282 1.8% 5253.6 -- CITRAMEDIA-AS-ID PT. Citramedia Network,ID 8 - AS34873 3337 0.1% 3337.0 -- IGIF-AS ACSS - Administracao Central do Sistema de Saude, I.P.,PT 9 - AS26661 9956 0.4% 3318.7 -- JCPS-ASN - Jeffco Public Schools,US 10 - AS54464 2875 0.1% 2875.0 -- D4LLC - D4 LLC,US 11 - AS23074 5859 0.2% 1953.0 -- Petr?leo Brasileiro S/A - Petrobras,BR 12 - AS33643 1635 0.1% 1635.0 -- JELLYBELLY - Jelly Belly Candy Company,US 13 - AS57320 26056 1.0% 1532.7 -- T-TELECOM-MNT-AS Ionit-telecom Ltd.,RU 14 - AS25003 12854 0.5% 1168.5 -- INTERNET_BINAT Internet Binat Ltd,IL 15 - AS3 1052 0.0% 5517.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 16 - AS58763 959 0.0% 959.0 -- GIGAVIRT-AS Gigavirt Technologies,IN 17 - AS37532 4822 0.2% 803.7 -- ZAMREN,ZM 18 - AS35093 1581 0.1% 790.5 -- RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 19 - AS3 10128 0.4% 134.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 20 - AS4775 16355 0.6% 778.8 -- GLOBE-TELECOM-AS Globe Telecoms,PH TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.115.44.0/22 12799 0.5% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 2 - 23.197.176.0/20 12077 0.4% AS26769 -- BANDCON - Bandcon,US 3 - 23.197.192.0/20 11940 0.4% AS26769 -- BANDCON - Bandcon,US 4 - 176.97.96.0/24 10715 0.4% AS57320 -- T-TELECOM-MNT-AS Ionit-telecom Ltd.,RU 5 - 176.97.111.0/24 10715 0.4% AS57320 -- T-TELECOM-MNT-AS Ionit-telecom Ltd.,RU 6 - 78.109.192.0/20 10094 0.4% AS25184 -- AFRANET AFRANET Co. Tehran, Iran,IR 7 - 185.17.128.0/24 10047 0.4% AS3 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 8 - 208.70.20.0/22 9817 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 9 - 208.73.244.0/22 9775 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 10 - 208.88.232.0/22 9773 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 11 - 216.162.0.0/20 9773 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 12 - 208.78.116.0/22 9761 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 13 - 192.58.232.0/24 9637 0.3% AS6629 -- NOAA-AS - NOAA,US 14 - 202.70.88.0/21 9188 0.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 15 - 206.152.15.0/24 8523 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 16 - 202.70.64.0/21 8486 0.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 17 - 205.247.12.0/24 8298 0.3% AS6459 -- TRANSBEAM - I-2000, Inc.,US 18 - 120.28.62.0/24 8104 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 19 - 222.127.0.0/24 8034 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 20 - 163.15.192.0/24 7844 0.3% AS1659 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW 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 jbaino at gmail.com Fri Aug 1 22:07:19 2014 From: jbaino at gmail.com (Jeremy) Date: Fri, 1 Aug 2014 15:07:19 -0700 Subject: ASR9K xml agent vs netconf Message-ID: Hi There! I'm currently working on writing some automation around the ASR9K platform and I've been looking at both the netconf and xml interfaces. Anyone have experience with either? It looks like the XML interface is much more feature rich, supporting both config and operational state objects where netconf is limited to config only. Currently I'm leaning towards the xml interface, but netconf would come with the appeal of using a standard and any libraries I write for it may be usable with other platforms. Thoughts? experiences? mistakes? wins? Thanks! Jeremy From bicknell at ufp.org Sat Aug 2 00:09:59 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 1 Aug 2014 19:09:59 -0500 Subject: Muni Fiber and Politics In-Reply-To: References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> Message-ID: On Aug 1, 2014, at 3:32 PM, Scott Helms wrote: > Even in those cases where there isn't a layer 3 operator nor a chance for a viable resale of layer 1/2 services. I have a very hard time believing that if a city (no matter what size) had a FTTH deployment, sold on a non-discriminatory basis to any providers, that there would ever be zero layer 3 operators. Maybe it?s a corner case that will occur in one small town somewhere that the long haul is crazy expensive to reach, but it?s not a general problem that policy needs to optimize to handle. -- 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: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From randy at psg.com Sat Aug 2 07:22:28 2014 From: randy at psg.com (Randy Bush) Date: Sat, 02 Aug 2014 09:22:28 +0200 Subject: ASR9K xml agent vs netconf In-Reply-To: References: Message-ID: > netconf would come with the appeal of using a standard and any > libraries I write for it may be usable with other platforms. well, how long do you plan to be around and 9k-only? randy From mark.tinka at seacom.mu Sat Aug 2 07:34:33 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 2 Aug 2014 09:34:33 +0200 Subject: Muni Fiber and Politics In-Reply-To: <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> Message-ID: <201408020934.33782.mark.tinka@seacom.mu> On Friday, August 01, 2014 04:44:29 PM Owen DeLong wrote: > Even when mandated to unbundle at a reasonable cost, > often other games are played (trouble ticket for service > billed by lines provider resolved in a day, trouble > ticket for service on unbundled element resolved in 14 > days, etc.). > > IMHO, experience has taught us that the lines provider > (or as I prefer to call them, the Layer 1 infrastructure > provider) must be prohibited from playing at the higher > layers. Agree. In reality, though, we've seen Layer 1-only providers becoming service providers (even when they previously promised the market it would never happen), due to wanting to stay "relevant". I suppose if a Layer 1 provider were a government entity, there is a higher chance they would never enter the Layer 2 or 3 space, but even then, there is strong lobbying in politics that this could become a reality. I've seen it happen a great deal in south east Asia, Zimbabwe, Tanzania, Kenya, and now even South Africa, particularly with Layer 1 providers that were government entities built to enable fibre connectivity for management of utility services (power, for example) and were then tasked to offer Layer 1 services with the remaining fibre, but currently find themselves now playing in Layer 2 and above to make extra cash for the government. It's hard... Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Sat Aug 2 07:39:42 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 2 Aug 2014 09:39:42 +0200 Subject: Muni Fiber and Politics In-Reply-To: <806B505C-EBA4-44F5-B7C7-192F82F54FC9@delong.com> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <1d935a3e-8f9d-4511-86ff-12ab72ea8cc9@email.android.com> <806B505C-EBA4-44F5-B7C7-192F82F54FC9@delong.com> Message-ID: <201408020939.43045.mark.tinka@seacom.mu> On Friday, August 01, 2014 06:34:00 PM Owen DeLong wrote: > Today, somewhere around $6,000 or more depending on > provider, location, etc. > > That?s with IP transit included. With IP Transit included, perhaps. But 10Gbps ports are not expensive these days. Depends on whether you selling 10Gbps ports off a router line card or an Ethernet switch. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Sat Aug 2 07:43:34 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 2 Aug 2014 09:43:34 +0200 Subject: Muni Fiber and Politics In-Reply-To: <4f33b312-f1de-46c6-8c97-97a2fc121ca6@email.android.com> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <806B505C-EBA4-44F5-B7C7-192F82F54FC9@delong.com> <4f33b312-f1de-46c6-8c97-97a2fc121ca6@email.android.com> Message-ID: <201408020943.34566.mark.tinka@seacom.mu> On Friday, August 01, 2014 07:17:24 PM Jay Ashworth wrote: > So we'll assume we could get 4 for 22k to make the > arithmetic easy, and that means if we can put 44 people > on that, that the MRC cost is 500 dollars a month for a > gigabit. That is clearly not consumer pricing. Was > consumer pricing the assertion? I think Owen's pricing is based on 10Gbps router ports (Owen, correct me if I'm wrong). This is not the only way to sell 10Gbps services. Having said that, in context of home broadband, I was referring to AN's (Access Nodes), particularly based on Active-E (you don't generally place consumer customers directly on to 10Gbps router ports). The 10Gbps ports on an Active-E AN are in the same 1U chassis as the 44x Gig-E ports. And depending on how many you buy from vendors for your Access network, you can get pretty decent deals with good return if you get great uptake and have a sweet price point. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From vristevs at ramapo.edu Sat Aug 2 13:10:43 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Sat, 02 Aug 2014 09:10:43 -0400 Subject: Muni Fiber and Politics In-Reply-To: <201408020939.43045.mark.tinka@seacom.mu> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <1d935a3e-8f9d-4511-86ff-12ab72ea8cc9@email.android.com> <806B505C-EBA4-44F5-B7C7-192F82F54FC9@delong.com> <201408020939.43045.mark.tinka@seacom.mu> Message-ID: <53DCE353.8060909@ramapo.edu> I might be misunderstanding this, but are you guys saying 10G Internet access to a tier 1 costs around $6,000 a month? I ask because I run a network for a small college and the best price I could get on 1Gbps Internet is about $5,500 a month with the fiber loop included which itself costs $2000-$2500. Or are you guys discussing a different type connection? The quotes I got were from Cogent, Lightpath, Level 3, Verizon ($8,000) and I think even ATT a few years back. I'm out in the NJ suburbs about 30 miles from Manhattan. If there is a cheaper way to get good bandwidth, I'm all ears. We're in Mahwah , NJ. Thanks, On 8/2/2014 3:39 AM, Mark Tinka wrote: > On Friday, August 01, 2014 06:34:00 PM Owen DeLong wrote: > >> Today, somewhere around $6,000 or more depending on >> provider, location, etc. >> >> That?s with IP transit included. > With IP Transit included, perhaps. But 10Gbps ports are not > expensive these days. > > Depends on whether you selling 10Gbps ports off a router > line card or an Ethernet switch. > > Mark. From bicknell at ufp.org Sat Aug 2 13:47:46 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 2 Aug 2014 08:47:46 -0500 Subject: Muni Fiber and Politics In-Reply-To: <53DCE353.8060909@ramapo.edu> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <1d935a3e-8f9d-4511-86ff-12ab72ea8cc9@email.android.com> <806B505C-EBA4-44F5-B7C7-192F82F54FC9@delong.com> <201408020939.43045.mark.tinka@seacom.mu> <53DCE353.8060909@ramapo.edu> Message-ID: <57685261-6ABA-43C2-A673-5263EB1536AA@ufp.org> On Aug 2, 2014, at 8:10 AM, Vlade Ristevski wrote: > I might be misunderstanding this, but are you guys saying 10G Internet access to a tier 1 costs around $6,000 a month? I ask because I run a network for a small college and the best price I could get on 1Gbps Internet is about $5,500 a month with the fiber loop included which itself costs $2000-$2500. Or are you guys discussing a different type connection? > > The quotes I got were from Cogent, Lightpath, Level 3, Verizon ($8,000) and I think even ATT a few years back. I'm out in the NJ suburbs about 30 miles from Manhattan. If there is a cheaper way to get good bandwidth, I'm all ears. We're in Mahwah , NJ. I think a 10GE for $6,000 in bandwidth charges is possible, if you meet the provider. What that means is if you are in an Equinix, Coresite, Telehouse, or other sort of carrier neutral colocation point, and you're willing to make the cross connect appear at the providers cage, you can get bandwidth for that price. Basically it's the price when the provider has to do zero other work, already has a large pop, and is selling large wholesale chunks. Add in a local loop, cost for a smaller pop they have to maintain, engineering and so on and your price for 1GE 30 miles away from such places seems perfectly reasonable to me. It's kind of the difference between driving your pickup to the quarry to get a truck load of sand, vrs buying prepackaged sand at the local home improvement store. -- 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: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From owen at delong.com Sat Aug 2 17:28:09 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 2 Aug 2014 10:28:09 -0700 Subject: Muni Fiber and Politics In-Reply-To: <201408020934.33782.mark.tinka@seacom.mu> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> <201408020934.33782.mark.tinka@seacom.mu> Message-ID: <775A7E85-5FD8-415F-B831-39051F7EAA3D@delong.com> That's why I want legislation requiring the operator to be one or the other and not both. Most L1 gets built with tax dollars or subsidies anyway. Owen > On Aug 2, 2014, at 0:34, Mark Tinka wrote: > >> On Friday, August 01, 2014 04:44:29 PM Owen DeLong wrote: >> >> Even when mandated to unbundle at a reasonable cost, >> often other games are played (trouble ticket for service >> billed by lines provider resolved in a day, trouble >> ticket for service on unbundled element resolved in 14 >> days, etc.). >> >> IMHO, experience has taught us that the lines provider >> (or as I prefer to call them, the Layer 1 infrastructure >> provider) must be prohibited from playing at the higher >> layers. > > Agree. > > In reality, though, we've seen Layer 1-only providers > becoming service providers (even when they previously > promised the market it would never happen), due to wanting > to stay "relevant". > > I suppose if a Layer 1 provider were a government entity, > there is a higher chance they would never enter the Layer 2 > or 3 space, but even then, there is strong lobbying in > politics that this could become a reality. > > I've seen it happen a great deal in south east Asia, > Zimbabwe, Tanzania, Kenya, and now even South Africa, > particularly with Layer 1 providers that were government > entities built to enable fibre connectivity for management > of utility services (power, for example) and were then > tasked to offer Layer 1 services with the remaining fibre, > but currently find themselves now playing in Layer 2 and > above to make extra cash for the government. > > It's hard... > > Mark. From owen at delong.com Sat Aug 2 17:24:40 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 2 Aug 2014 10:24:40 -0700 Subject: Muni Fiber and Politics In-Reply-To: References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> Message-ID: <8C91DE6E-B56D-47E1-B826-10B2D024D87F@delong.com> Such a case is unlikely. On Aug 1, 2014, at 13:32, Scott Helms wrote: >> >> >> I can never see a case where letting them play at Layer 3 or above helps. >> That?s bad news, stay away. But I think some well crafted L2 services >> could actually _expand_ consumer choice. I mean running a dark fiber >> GigE to supply voice only makes no sense, but a 10M channel on a GPON >> serving a VoIP box may? > > Even in those cases where there isn't a layer 3 operator nor a chance for a viable resale of layer 1/2 services. > From owen at delong.com Sat Aug 2 17:24:02 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 2 Aug 2014 10:24:02 -0700 Subject: Muni Fiber and Politics In-Reply-To: References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> Message-ID: <047A3A22-983F-4587-AA12-C53CBA75BC68@delong.com> > Municipalities can be different. It?s possible to write into law that > they can offer L1 and L2 services, but never anything higher. There?s > also a built in disincentive to risk tax dollars more speculative, but > possibly more profitable ventures. Sure, a muni could offer that and be likely OK. As long as L1 services were kept a hard requirement. > So while I agree with Owen that a dark fiber model is preferred, and > should be offered, I don?t have a problem with a municipal network also > offering Layer 2. In fact, I see some potential wins, imagine a network > where you could chose to buy dark fiber access, or a channel on a GPON > system? If the customer wants GE/10GE, you get dark fiber, and if they > want 50Mbps, you get a GPON channel for less (yes, that?s an assumption) > cost. If the L1 provider has to have dark fiber to every prem, the cost model of PON is strictly within the SWC and not the outside plant. As such, those savings could be done by the competing access providers without requiring differentiation by the L1 provider. > I can also see how some longer-distance links, imagine a link from > home to office across 30-40 miles, might be cheaper to deliver as 100M > VLAN than raw dark fiber and having to buy long reach optics. This would be served out if multiple SWCs anyway, so there would be some provider able to offer that most likely. > I can never see a case where letting them play at Layer 3 or above helps. > That?s bad news, stay away. But I think some well crafted L2 services > could actually _expand_ consumer choice. I mean running a dark fiber > GigE to supply voice only makes no sense, but a 10M channel on a GPON > serving a VoIP box may? The problem I've seen with this is that the savings achieved by PON primarily come from aggregating fiber pairs at the edge. In order to have competition enabled L1, the fiber must go from prem all the way to SWC. So while I can't see a problem with allowing an L1 provider to also offer L2, usually when that happens, they don't offer L1. If both are offered, the majority of the L2 benefits disappear. Owen From owen at delong.com Sat Aug 2 17:26:09 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 2 Aug 2014 10:26:09 -0700 Subject: Muni Fiber and Politics In-Reply-To: References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> Message-ID: <957BF1AF-8DCE-4C7D-87CA-03D9C04048E8@delong.com> I don't pretend to be the original person with this idea. But I would very much like to see it implemented. > On Aug 1, 2014, at 13:24, Joly MacFie wrote: > > >> On Fri, Aug 1, 2014 at 10:44 AM, Owen DeLong wrote: >> MHO, experience has taught us that the lines provider (or as I >> prefer to call them, the Layer 1 infrastructure provider) must be >> prohibited from playing at the higher layers > > > > A few years back Fred Goldstein proposed defining a Layer 1 infrastructure provider as a "LoopCo", where the local loop is passively provided to service providers to light it as they see fit. He even wrote draft legislation, where the incumbent LEC is divided into a "Facilities Entity" and a "Services Entity": > > http://www.ionary.com/separationbillproposal.htm > > That proposal generally requires something like a CLEC to light the wire locally, and makes CLECs viable again. > > He has also proposed requiring ILECs (and cablecos) to provide low-layer (layer 2, mostly) common carriage on an open basis; as filed in the current NN docket: > > http://www.ionary.com/separationbillproposal.htm > > > j > > -- > --------------------------------------------------------------- > 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 John_Brzozowski at Cable.Comcast.com Sat Aug 2 17:32:26 2014 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Sat, 2 Aug 2014 17:32:26 +0000 Subject: Comcast IPv6 Milestone In-Reply-To: <53D169AA.3040301@jsbc.cc> References: <53D169AA.3040301@jsbc.cc> Message-ID: Absolutely. We are close and are trying to finalize the firmware for a subset of our commercial DOCSIS devices. Stay tuned for news and updates on this front. Be sure to check www.comcast6.net, I will post updates here. John -----Original Message----- From: Jim Burwell Date: Thursday, July 24, 2014 at 16:16 To: John Brzozowski , NANOG Subject: Re: Comcast IPv6 Milestone >Congrats to you and your team John! > >I presume Comcast Business is still a work in progress? > >- Jim > >On 7/24/2014 08:08, Brzozowski, John wrote: >> FYI ? please feel free to contact me directly if you have any questions: >> >> >>http://corporate.comcast.com/comcast-voices/comcast-reaches-key-milestone >>-in-launch-of-ipv6-broadband-network >> >> Thank you, >> >> John >> ========================================= >> John Jason Brzozowski >> Comcast Cable >> w) www.comcast6.net >> e) john_brzozowski at cable.comcast.com >> ========================================= >> >> >> >> > From owen at delong.com Sat Aug 2 17:29:41 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 2 Aug 2014 10:29:41 -0700 Subject: Muni Fiber and Politics In-Reply-To: <201408020943.34566.mark.tinka@seacom.mu> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <806B505C-EBA4-44F5-B7C7-192F82F54FC9@delong.com> <4f33b312-f1de-46c6-8c97-97a2fc121ca6@email.android.com> <201408020943.34566.mark.tinka@seacom.mu> Message-ID: <240186FA-0A89-4E8D-87D6-5C4A6F14B726@delong.com> I thought JRA was asking about the upstream cost. Owen > On Aug 2, 2014, at 0:43, Mark Tinka wrote: > >> On Friday, August 01, 2014 07:17:24 PM Jay Ashworth wrote: >> >> So we'll assume we could get 4 for 22k to make the >> arithmetic easy, and that means if we can put 44 people >> on that, that the MRC cost is 500 dollars a month for a >> gigabit. That is clearly not consumer pricing. Was >> consumer pricing the assertion? > > I think Owen's pricing is based on 10Gbps router ports > (Owen, correct me if I'm wrong). > > This is not the only way to sell 10Gbps services. > > Having said that, in context of home broadband, I was > referring to AN's (Access Nodes), particularly based on > Active-E (you don't generally place consumer customers > directly on to 10Gbps router ports). > > The 10Gbps ports on an Active-E AN are in the same 1U > chassis as the 44x Gig-E ports. And depending on how many > you buy from vendors for your Access network, you can get > pretty decent deals with good return if you get great uptake > and have a sweet price point. > > Mark. From vristevs at ramapo.edu Sat Aug 2 18:13:39 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Sat, 02 Aug 2014 14:13:39 -0400 Subject: Muni Fiber and Politics In-Reply-To: <57685261-6ABA-43C2-A673-5263EB1536AA@ufp.org> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <1d935a3e-8f9d-4511-86ff-12ab72ea8cc9@email.android.com> <806B505C-EBA4-44F5-B7C7-192F82F54FC9@delong.com> <201408020939.43045.mark.tinka@seacom.mu> <53DCE353.8060909@ramapo.edu> <57685261-6ABA-43C2-A673-5263EB1536AA@ufp.org> Message-ID: <53DD2A53.6090102@ramapo.edu> Thanks , makes sense. I was looking on peeringdb.com for some locations nearby but they're all 20+ miles . However, there is a Telx a block from my house that I walk past everyday. Maybe a I can string along a 10G connection to my basement office :) On 8/2/2014 9:47 AM, Leo Bicknell wrote: > On Aug 2, 2014, at 8:10 AM, Vlade Ristevski wrote: > >> I might be misunderstanding this, but are you guys saying 10G Internet access to a tier 1 costs around $6,000 a month? I ask because I run a network for a small college and the best price I could get on 1Gbps Internet is about $5,500 a month with the fiber loop included which itself costs $2000-$2500. Or are you guys discussing a different type connection? >> >> The quotes I got were from Cogent, Lightpath, Level 3, Verizon ($8,000) and I think even ATT a few years back. I'm out in the NJ suburbs about 30 miles from Manhattan. If there is a cheaper way to get good bandwidth, I'm all ears. We're in Mahwah , NJ. > I think a 10GE for $6,000 in bandwidth charges is possible, if you meet the provider. What that means is if you are in an Equinix, Coresite, Telehouse, or other sort of carrier neutral colocation point, and you're willing to make the cross connect appear at the providers cage, you can get bandwidth for that price. Basically it's the price when the provider has to do zero other work, already has a large pop, and is selling large wholesale chunks. > > Add in a local loop, cost for a smaller pop they have to maintain, engineering and so on and your price for 1GE 30 miles away from such places seems perfectly reasonable to me. > > It's kind of the difference between driving your pickup to the quarry to get a truck load of sand, vrs buying prepackaged sand at the local home improvement store. > From khelms at zcorum.com Sat Aug 2 19:04:05 2014 From: khelms at zcorum.com (Scott Helms) Date: Sat, 2 Aug 2014 15:04:05 -0400 Subject: Muni Fiber and Politics In-Reply-To: <8C91DE6E-B56D-47E1-B826-10B2D024D87F@delong.com> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> <8C91DE6E-B56D-47E1-B826-10B2D024D87F@delong.com> Message-ID: Happens all the time, which is why I asked Leo about that scenario. There are large swarths of the US and even more in Canada where that's the norm. On Aug 2, 2014 1:29 PM, "Owen DeLong" wrote: > Such a case is unlikely. > > On Aug 1, 2014, at 13:32, Scott Helms wrote: > > >> >> I can never see a case where letting them play at Layer 3 or above helps. >> That?s bad news, stay away. But I think some well crafted L2 services >> could actually _expand_ consumer choice. I mean running a dark fiber >> GigE to supply voice only makes no sense, but a 10M channel on a GPON >> serving a VoIP box may? >> > > Even in those cases where there isn't a layer 3 operator nor a chance for > a viable resale of layer 1/2 services. > > From bicknell at ufp.org Sat Aug 2 21:15:28 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 2 Aug 2014 16:15:28 -0500 Subject: Muni Fiber and Politics In-Reply-To: References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> <8C91DE6E-B56D-47E1-B826-10B2D024D87F@delong.com> Message-ID: <04940BA3-3D47-425C-BB88-B304DC991159@ufp.org> There are plenty of cities with zero ISP's interested in serving them today, I can't argue that point. However I believe the single largest reason why that is true is that the ISP today has to bear the capital cost of building out the physical plant to serve the customers. 15-20 year ROI's don't work for small businesses or wall street. But if those cities were to build a municipal fiber network like we've described, and pay for it with 15-20 year municipal bonds the ISP's wouldn't have to bear those costs. They could come in drop one box in a central location and start offering service. Which is why I said, if municipalities did this, I am very skeptical there would be more than a handful without a L3 operator. You can imagine a city of 50 people in North Dakota or the Northern Territories might have this issue because the long haul cost to reach the town is so high, but it's going to be a rare case. I firmly believe the municipal fiber networks presence would bring L3 operators to 90-95% of cities. On Aug 2, 2014, at 2:04 PM, Scott Helms wrote: > Happens all the time, which is why I asked Leo about that scenario. There are large swarths of the US and even more in Canada where that's the norm. > > On Aug 2, 2014 1:29 PM, "Owen DeLong" wrote: > Such a case is unlikely. > > On Aug 1, 2014, at 13:32, Scott Helms wrote: > >> >> >> I can never see a case where letting them play at Layer 3 or above helps. >> That?s bad news, stay away. But I think some well crafted L2 services >> could actually _expand_ consumer choice. I mean running a dark fiber >> GigE to supply voice only makes no sense, but a 10M channel on a GPON >> serving a VoIP box may? >> >> Even in those cases where there isn't a layer 3 operator nor a chance for a viable resale of layer 1/2 services. >> -- 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: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mansaxel at besserwisser.org Sat Aug 2 23:31:17 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sun, 3 Aug 2014 01:31:17 +0200 Subject: Muni Fiber and Politics In-Reply-To: <201408010740.50741.mark.tinka@seacom.mu> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <10C051BE-0617-4382-B1CB-88E031D45128@ufp.org> <20140731120128.GA24465@besserwisser.org> <201408010740.50741.mark.tinka@seacom.mu> Message-ID: <20140802233117.GA28317@besserwisser.org> Subject: Re: Muni Fiber and Politics Date: Fri, Aug 01, 2014 at 07:40:50AM +0200 Quoting Mark Tinka (mark.tinka at seacom.mu): > On Thursday, July 31, 2014 02:01:28 PM M?ns Nilsson wrote: > > > It is better, both for the customer and the provider. > > If the provider is able to deliver 1Gbps to every home > (either on copper or fibre) with little to no uplink > oversubscription (think 44x customer-facing Gig-E ports + 4x > 10Gbps uplink ports), essentially, there is no limit to what > services a provider and its partners can offer to its > customers. Oh, yes, there is. Multicast? IPv6? Both CAN be done, but probably won't. Dark fibre to CO is the only way to be sure. As long as that is possible, perhaps mandated by regulation, there's no major issue with providing a packaged service. In the end, though, if we get the quality of Internet access up to sensible levels (today minimum of a /56 and 100Mbit symmetric and no stupid peering wars ;-) there are few reasons not to bundle L1-L3. However, given the nature of monopolies and their tendency to underperform and overcharge, that is an optimisation dream... -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Hello. Just walk along and try NOT to think about your INTESTINES being almost FORTY YARDS LONG!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From owen at delong.com Sat Aug 2 23:30:11 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 2 Aug 2014 16:30:11 -0700 Subject: Muni Fiber and Politics In-Reply-To: References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> <8C91DE6E-B56D-47E1-B826-10B2D024D87F@delong.com> Message-ID: <0CB05F7A-6DBA-4C23-A1ED-490372B98AF8@delong.com> Is it, or is it the norm because it is the result of a lack of facilities in those locations? Show me even one area where there is a rich fiber infrastructure available on an equal footing to multiple competitors to provide L3 services and there are no L3 providers offering service to those residential customers. I bet I can get a provider going there pretty quick. Owen > On Aug 2, 2014, at 12:04 PM, Scott Helms wrote: > > Happens all the time, which is why I asked Leo about that scenario. There are large swarths of the US and even more in Canada where that's the norm. > >> On Aug 2, 2014 1:29 PM, "Owen DeLong" wrote: >> Such a case is unlikely. >> >>> On Aug 1, 2014, at 13:32, Scott Helms wrote: >>> >>>> >>>> >>>> I can never see a case where letting them play at Layer 3 or above helps. >>>> That?s bad news, stay away. But I think some well crafted L2 services >>>> could actually _expand_ consumer choice. I mean running a dark fiber >>>> GigE to supply voice only makes no sense, but a 10M channel on a GPON >>>> serving a VoIP box may? >>> >>> Even in those cases where there isn't a layer 3 operator nor a chance for a viable resale of layer 1/2 services. From corey.touchet at corp.totalserversolutions.com Sun Aug 3 02:16:07 2014 From: corey.touchet at corp.totalserversolutions.com (Corey Touchet) Date: Sun, 3 Aug 2014 02:16:07 +0000 Subject: Muni Fiber and Politics In-Reply-To: <04940BA3-3D47-425C-BB88-B304DC991159@ufp.org> Message-ID: But in the cases of small rural communities it?s perfectly reasonable to just setup wifi to cover the town and backhaul a DS3 back to a more connected location. There?s plenty of small wireless companies out there trying to serve these folks. On 8/2/14, 3:15 PM, "Leo Bicknell" wrote: > >There are plenty of cities with zero ISP's interested in serving them >today, I can't argue >that point. However I believe the single largest reason why that is true >is that the ISP >today has to bear the capital cost of building out the physical plant to >serve the customers. >15-20 year ROI's don't work for small businesses or wall street. > >But if those cities were to build a municipal fiber network like we've >described, and pay >for it with 15-20 year municipal bonds the ISP's wouldn't have to bear >those costs. They >could come in drop one box in a central location and start offering >service. > >Which is why I said, if municipalities did this, I am very skeptical >there would be more than >a handful without a L3 operator. You can imagine a city of 50 people in >North Dakota >or the Northern Territories might have this issue because the long haul >cost to reach the >town is so high, but it's going to be a rare case. I firmly believe the >municipal fiber networks >presence would bring L3 operators to 90-95% of cities. > >On Aug 2, 2014, at 2:04 PM, Scott Helms wrote: > >> Happens all the time, which is why I asked Leo about that scenario. >>There are large swarths of the US and even more in Canada where that's >>the norm. >> >> On Aug 2, 2014 1:29 PM, "Owen DeLong" wrote: >> Such a case is unlikely. >> >> On Aug 1, 2014, at 13:32, Scott Helms wrote: >> >>> >>> >>> I can never see a case where letting them play at Layer 3 or above >>>helps. >>> That?s bad news, stay away. But I think some well crafted L2 services >>> could actually _expand_ consumer choice. I mean running a dark fiber >>> GigE to supply voice only makes no sense, but a 10M channel on a GPON >>> serving a VoIP box may? >>> >>> Even in those cases where there isn't a layer 3 operator nor a chance >>>for a viable resale of layer 1/2 services. >>> > > >-- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > From mark.tinka at seacom.mu Sun Aug 3 03:11:09 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 3 Aug 2014 05:11:09 +0200 Subject: Muni Fiber and Politics In-Reply-To: <20140802233117.GA28317@besserwisser.org> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <20140802233117.GA28317@besserwisser.org> Message-ID: <201408030511.09562.mark.tinka@seacom.mu> On Sunday, August 03, 2014 01:31:17 AM M?ns Nilsson wrote: > Oh, yes, there is. Multicast? IPv6? Both CAN be done, but > probably won't. I'm talking about the opportunities large bandwidth presents, non-technical issues aside. Certainly, IPv6 and Multicast have a place on a 1Gbps link into the customer's home. Unless I misunderstand what you're trying to say... Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From keith at kouzmanoff.com Fri Aug 1 23:11:18 2014 From: keith at kouzmanoff.com (keith kouzmanoff) Date: Fri, 01 Aug 2014 18:11:18 -0500 Subject: The Cidr Report In-Reply-To: <201408012200.s71M00qS013033@wattle.apnic.net> References: <201408012200.s71M00qS013033@wattle.apnic.net> Message-ID: <53DC1E96.2060805@kouzmanoff.com> link didn't work for me, I think http://www.cidr-report.org/as2.0/ is the proper link On 8/1/2014 5:00 PM, cidr-report at potaroo.net wrote: > This report has been generated at Fri Aug 1 21:13:59 2014 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/2.0 for a current version of this report. > > Recent Table History > Date Prefixes CIDR Agg > 25-07-14 508935 285928 > 26-07-14 508775 286040 > 27-07-14 508959 286213 > 28-07-14 509275 286189 > 29-07-14 509477 286110 > 30-07-14 509841 286214 > 31-07-14 510150 286361 > 01-08-14 510519 286381 > > > AS Summary > 47759 Number of ASes in routing system > 19365 Number of ASes announcing only one prefix > 3794 Largest number of prefixes announced by an AS > AS28573: NET Servi?os de Comunica??o S.A.,BR > 120495616 Largest address span announced by an AS (/32s) > AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN > > > 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'). > > --- 01Aug14 --- > ASnum NetsNow NetsAggr NetGain % Gain Description > > Table 510651 286295 224356 43.9% All ASes > > AS28573 3794 214 3580 94.4% NET Servi?os de Comunica??o > S.A.,BR > AS6389 2943 80 2863 97.3% BELLSOUTH-NET-BLK - > BellSouth.net Inc.,US > AS17974 2801 190 2611 93.2% TELKOMNET-AS2-AP PT > Telekomunikasi Indonesia,ID > AS7029 2887 485 2402 83.2% WINDSTREAM - Windstream > Communications Inc,US > AS4766 2949 928 2021 68.5% KIXS-AS-KR Korea Telecom,KR > AS18881 2062 43 2019 97.9% Global Village Telecom,BR > AS7545 2347 677 1670 71.2% TPG-INTERNET-AP TPG Telecom > Limited,AU > AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath > Corporation,US > AS10620 2939 1463 1476 50.2% Telmex Colombia S.A.,CO > AS7303 1775 438 1337 75.3% Telecom Argentina S.A.,AR > AS22773 2725 1401 1324 48.6% ASN-CXA-ALL-CCI-22773-RDC - > Cox Communications Inc.,US > AS4755 1866 594 1272 68.2% TATACOMM-AS TATA > Communications formerly VSNL > is Leading ISP,IN > AS4323 1642 424 1218 74.2% TWTC - tw telecom holdings, > inc.,US > AS6983 1390 314 1076 77.4% ITCDELTA - Earthlink, Inc.,US > AS22561 1305 242 1063 81.5% AS22561 - CenturyTel Internet > Holdings, Inc.,US > AS7552 1261 237 1024 81.2% VIETEL-AS-AP Viettel > Corporation,VN > AS9829 1653 738 915 55.4% BSNL-NIB National Internet > Backbone,IN > AS6147 1043 147 896 85.9% Telefonica del Peru S.A.A.,PE > AS38285 956 112 844 88.3% M2TELECOMMUNICATIONS-AU M2 > Telecommunications Group > Ltd,AU > AS24560 1153 345 808 70.1% AIRTELBROADBAND-AS-AP Bharti > Airtel Ltd., Telemedia > Services,IN > AS4808 1207 416 791 65.5% CHINA169-BJ CNCGROUP IP > network China169 Beijing > Province Network,CN > AS7738 977 190 787 80.6% Telemar Norte Leste S.A.,BR > AS4788 1023 261 762 74.5% TMNET-AS-AP TM Net, Internet > Service Provider,MY > AS8151 1450 691 759 52.3% Uninet S.A. de C.V.,MX > AS18101 947 189 758 80.0% RELIANCE-COMMUNICATIONS-IN > Reliance Communications > Ltd.DAKC MUMBAI,IN > AS9808 1101 376 725 65.8% CMNET-GD Guangdong Mobile > Communication Co.Ltd.,CN > AS26615 860 136 724 84.2% Tim Celular S.A.,BR > AS11492 1237 522 715 57.8% CABLEONE - CABLE ONE, INC.,US > AS701 1438 726 712 49.5% UUNET - MCI Communications > Services, Inc. d/b/a Verizon > Business,US > AS27738 772 64 708 91.7% Ecuadortelecom S.A.,EC > > Total 52550 13208 39342 74.9% Top 30 total > > > Possible Bogus Routes > > 23.226.240.0/20 AS40430 -Reserved AS-,ZZ > 23.226.240.0/21 AS40430 -Reserved AS-,ZZ > 23.226.248.0/21 AS40430 -Reserved AS-,ZZ > 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA > 27.100.7.0/24 AS56096 > 41.73.1.0/24 AS37004 -Reserved AS-,ZZ > 41.73.2.0/24 AS37004 -Reserved AS-,ZZ > 41.73.10.0/24 AS37004 -Reserved AS-,ZZ > 41.73.11.0/24 AS37004 -Reserved AS-,ZZ > 41.73.12.0/24 AS37004 -Reserved AS-,ZZ > 41.73.13.0/24 AS37004 -Reserved AS-,ZZ > 41.73.14.0/24 AS37004 -Reserved AS-,ZZ > 41.73.15.0/24 AS37004 -Reserved AS-,ZZ > 41.73.16.0/24 AS37004 -Reserved AS-,ZZ > 41.73.18.0/24 AS37004 -Reserved AS-,ZZ > 41.73.20.0/24 AS37004 -Reserved AS-,ZZ > 41.73.21.0/24 AS37004 -Reserved AS-,ZZ > 41.76.48.0/21 AS36969 MTL-AS,MW > 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US > 41.78.180.0/23 AS37265 -Reserved AS-,ZZ > 41.78.236.0/24 AS37290 -Reserved AS-,ZZ > 41.78.237.0/24 AS37290 -Reserved AS-,ZZ > 41.78.238.0/24 AS37290 -Reserved AS-,ZZ > 41.78.239.0/24 AS37290 -Reserved AS-,ZZ > 41.189.96.0/20 AS37000 -Reserved AS-,ZZ > 41.189.128.0/24 AS37000 -Reserved AS-,ZZ > 41.190.1.0/24 AS37076 -Reserved AS-,ZZ > 41.190.2.0/24 AS37076 -Reserved AS-,ZZ > 41.190.3.0/24 AS37076 -Reserved AS-,ZZ > 41.190.4.0/22 AS37076 -Reserved AS-,ZZ > 41.190.4.0/24 AS37076 -Reserved AS-,ZZ > 41.190.5.0/24 AS37076 -Reserved AS-,ZZ > 41.190.8.0/24 AS37076 -Reserved AS-,ZZ > 41.190.10.0/23 AS37076 -Reserved AS-,ZZ > 41.190.12.0/24 AS37076 -Reserved AS-,ZZ > 41.190.13.0/24 AS37076 -Reserved AS-,ZZ > 41.190.14.0/24 AS37076 -Reserved AS-,ZZ > 41.190.16.0/20 AS37076 -Reserved AS-,ZZ > 41.190.72.0/24 AS37451 CongoTelecom,CG > 41.190.73.0/24 AS37451 CongoTelecom,CG > 41.190.74.0/24 AS37451 CongoTelecom,CG > 41.190.75.0/24 AS37451 CongoTelecom,CG > 41.191.108.0/22 AS37004 -Reserved AS-,ZZ > 41.191.108.0/24 AS37004 -Reserved AS-,ZZ > 41.191.109.0/24 AS37004 -Reserved AS-,ZZ > 41.191.110.0/24 AS37004 -Reserved AS-,ZZ > 41.191.111.0/24 AS37004 -Reserved AS-,ZZ > 41.197.0.0/16 AS36934 -Reserved AS-,ZZ > 41.223.208.0/22 AS37000 -Reserved AS-,ZZ > 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL > 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL > 62.193.160.0/19 AS24801 -Reserved AS-,ZZ > 62.193.160.0/20 AS24801 -Reserved AS-,ZZ > 62.193.176.0/20 AS24801 -Reserved AS-,ZZ > 64.25.16.0/23 AS19535 -Reserved AS-,ZZ > 64.25.20.0/24 AS19535 -Reserved AS-,ZZ > 64.25.21.0/24 AS19535 -Reserved AS-,ZZ > 64.25.22.0/24 AS19535 -Reserved AS-,ZZ > 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US > 64.111.160.0/20 AS40551 -Reserved AS-,ZZ > 64.111.160.0/24 AS40551 -Reserved AS-,ZZ > 64.111.161.0/24 AS40551 -Reserved AS-,ZZ > 64.111.162.0/24 AS40551 -Reserved AS-,ZZ > 64.111.167.0/24 AS40551 -Reserved AS-,ZZ > 64.111.169.0/24 AS40551 -Reserved AS-,ZZ > 64.111.170.0/24 AS40551 -Reserved AS-,ZZ > 64.111.171.0/24 AS40551 -Reserved AS-,ZZ > 64.111.172.0/24 AS40551 -Reserved AS-,ZZ > 64.111.173.0/24 AS40551 -Reserved AS-,ZZ > 64.111.174.0/24 AS40551 -Reserved AS-,ZZ > 64.111.175.0/24 AS40551 -Reserved AS-,ZZ > 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US > 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US > 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US > 66.6.176.0/20 AS13223 BBTECNETWORKS-HK RM18, 9/F., Kwan Yick Building Phase 1, 430-440A Des Voeux Rd. West.,HK > 66.55.96.0/23 AS17203 -Reserved AS-,ZZ > 66.55.98.0/24 AS17203 -Reserved AS-,ZZ > 66.55.99.0/24 AS17203 -Reserved AS-,ZZ > 66.55.100.0/22 AS17203 -Reserved AS-,ZZ > 66.55.102.0/23 AS17203 -Reserved AS-,ZZ > 66.55.104.0/21 AS17203 -Reserved AS-,ZZ > 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA > 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US > 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US > 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT > 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US > 74.112.100.0/22 AS16764 -Reserved AS-,ZZ > 74.113.200.0/23 AS46939 -Reserved AS-,ZZ > 74.114.52.0/22 AS40818 -Reserved AS-,ZZ > 74.114.52.0/23 AS40818 -Reserved AS-,ZZ > 74.114.52.0/24 AS40818 -Reserved AS-,ZZ > 74.114.53.0/24 AS40818 -Reserved AS-,ZZ > 74.114.54.0/23 AS40818 -Reserved AS-,ZZ > 74.114.54.0/24 AS40818 -Reserved AS-,ZZ > 74.114.55.0/24 AS40818 -Reserved AS-,ZZ > 74.118.132.0/22 AS5117 -Reserved AS-,ZZ > 74.120.212.0/23 AS32326 -Reserved AS-,ZZ > 74.120.214.0/23 AS32326 -Reserved AS-,ZZ > 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US > 77.243.80.0/24 AS42597 -Reserved AS-,ZZ > 77.243.81.0/24 AS42597 -Reserved AS-,ZZ > 77.243.88.0/24 AS42597 -Reserved AS-,ZZ > 77.243.91.0/24 AS42597 -Reserved AS-,ZZ > 77.243.94.0/24 AS42597 -Reserved AS-,ZZ > 77.243.95.0/24 AS42597 -Reserved AS-,ZZ > 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US > 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US > 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US > 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US > 80.250.32.0/22 AS37106 ODUA-AS,NG > 85.202.160.0/20 AS44404 -Reserved AS-,ZZ > 89.31.24.0/23 AS41455 -Reserved AS-,ZZ > 89.31.26.0/23 AS41455 -Reserved AS-,ZZ > 89.31.28.0/22 AS41455 -Reserved AS-,ZZ > 89.207.8.0/21 AS3292 TDC TDC A/S,DK > 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 91.197.36.0/22 AS43359 -Reserved AS-,ZZ > 91.199.90.0/24 AS44330 -Reserved AS-,ZZ > 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE > 91.228.160.0/24 AS56815 -Reserved AS-,ZZ > 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB > 93.190.10.0/24 AS47254 -Reserved AS-,ZZ > 95.215.140.0/22 AS48949 -Reserved AS-,ZZ > 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU > 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN > 103.6.228.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP > 103.9.108.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP > 103.9.140.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU > 103.9.141.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU > 103.9.142.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU > 103.9.143.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU > 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN > 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP > 103.18.92.0/22 AS13269 > 103.18.92.0/24 AS13269 > 103.18.94.0/24 AS13269 > 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP > 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP > 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN > 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN > 103.25.120.0/22 AS13280 > 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP > 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP > 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP > 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US > 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US > 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US > 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN > 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN > 124.158.28.0/22 AS45857 > 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA > 162.218.168.0/21 AS40430 -Reserved AS-,ZZ > 162.218.175.0/24 AS40430 -Reserved AS-,ZZ > 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP > 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US > 172.85.0.0/24 AS29571 CITelecom-AS,CI > 172.85.1.0/24 AS29571 CITelecom-AS,CI > 172.85.2.0/24 AS29571 CITelecom-AS,CI > 172.85.3.0/24 AS29571 CITelecom-AS,CI > 172.86.0.0/24 AS29571 CITelecom-AS,CI > 172.86.1.0/24 AS29571 CITelecom-AS,CI > 172.86.2.0/24 AS29571 CITelecom-AS,CI > 172.87.0.0/24 AS29571 CITelecom-AS,CI > 172.88.0.0/24 AS29571 CITelecom-AS,CI > 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN > 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO > 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN > 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP > 185.65.208.0/22 AS25394 MK-NETZDIENSTE-AS AS for MK Netzdienste GmbH & Co. KG,DE > 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR > 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US > 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US > 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US > 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US > 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US > 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US > 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US > 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA > 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US > 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE > 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US > 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US > 192.154.32.0/19 AS81 NCREN - MCNC,US > 192.154.64.0/19 AS81 NCREN - MCNC,US > 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US > 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US > 193.9.59.0/24 AS1257 TELE2,SE > 193.16.106.0/24 AS31539 -Reserved AS-,ZZ > 193.16.145.0/24 AS31392 -Reserved AS-,ZZ > 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI > 193.22.224.0/20 AS3322 -Reserved AS-,ZZ > 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE > 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB > 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE > 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB > 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB > 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES > 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO > 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO > 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE > 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US > 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO > 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB > 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB > 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT > 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.243.166.0/24 AS44093 -Reserved AS-,ZZ > 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA > 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA > 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE > 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE > 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE > 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB > 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE > 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB > 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE > 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO > 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE > 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 194.126.219.0/24 AS34545 -Reserved AS-,ZZ > 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR > 194.126.251.0/24 AS50818 -Reserved AS-,ZZ > 194.146.35.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR > 194.146.36.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR > 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE > 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE > 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE > 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA > 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO > 195.39.252.0/23 AS29004 -Reserved AS-,ZZ > 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE > 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE > 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE > 195.234.156.0/24 AS25028 -Reserved AS-,ZZ > 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.245.98.0/23 AS48918 GLOBALWAYS GLOBALWAYS AG,DE > 196.3.182.0/24 AS37004 -Reserved AS-,ZZ > 196.3.183.0/24 AS37004 -Reserved AS-,ZZ > 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR > 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US > 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US > 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US > 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US > 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US > 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US > 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US > 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA > 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA > 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA > 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US > 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US > 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US > 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US > 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.254.96.0/20 AS40430 -Reserved AS-,ZZ > 198.254.96.0/22 AS40430 -Reserved AS-,ZZ > 198.254.100.0/22 AS40430 -Reserved AS-,ZZ > 198.254.104.0/21 AS40430 -Reserved AS-,ZZ > 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA > 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US > 199.116.200.0/21 AS22830 -Reserved AS-,ZZ > 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US > 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US > 200.58.248.0/21 AS27849 > 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR > 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR > 200.81.50.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR > 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR > 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK > 202.58.113.0/24 AS19161 -Reserved AS-,ZZ > 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN > 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG > 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN > 203.142.219.0/24 AS45149 > 203.160.48.0/21 AS38008 > 203.189.116.0/22 AS45606 > 203.189.116.0/24 AS45606 > 203.189.117.0/24 AS45606 > 203.189.118.0/24 AS45606 > 203.189.119.0/24 AS45606 > 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 204.10.94.0/23 AS30097 NUWAVE - NuWave,US > 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US > 204.16.96.0/24 AS19972 -Reserved AS-,ZZ > 204.16.97.0/24 AS19972 -Reserved AS-,ZZ > 204.16.98.0/24 AS19972 -Reserved AS-,ZZ > 204.16.99.0/24 AS19972 -Reserved AS-,ZZ > 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US > 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US > 204.155.28.0/22 AS40925 -Reserved AS-,ZZ > 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB > 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA > 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US > 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US > 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA > 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US > 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA > 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US > 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US > 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US > 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US > 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US > 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US > 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US > 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US > 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM > 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM > 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM > 208.66.64.0/24 AS16936 -Reserved AS-,ZZ > 208.66.65.0/24 AS16936 -Reserved AS-,ZZ > 208.66.66.0/24 AS16936 -Reserved AS-,ZZ > 208.66.67.0/24 AS16936 -Reserved AS-,ZZ > 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US > 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US > 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US > 208.75.152.0/21 AS32146 -Reserved AS-,ZZ > 208.76.20.0/24 AS31812 -Reserved AS-,ZZ > 208.76.21.0/24 AS31812 -Reserved AS-,ZZ > 208.77.164.0/24 AS22659 -Reserved AS-,ZZ > 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US > 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US > 208.84.232.0/24 AS33131 -Reserved AS-,ZZ > 208.84.234.0/24 AS33131 -Reserved AS-,ZZ > 208.84.237.0/24 AS33131 -Reserved AS-,ZZ > 208.84.238.0/24 AS33131 -Reserved AS-,ZZ > 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US > 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US > 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US > 209.209.224.0/19 AS19513 -Reserved AS-,ZZ > 209.209.248.0/23 AS19513 -Reserved AS-,ZZ > 209.209.250.0/23 AS19513 -Reserved AS-,ZZ > 209.209.251.0/24 AS19513 -Reserved AS-,ZZ > 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US > 209.234.112.0/23 AS32252 -Reserved AS-,ZZ > 209.234.114.0/23 AS32252 -Reserved AS-,ZZ > 209.234.116.0/24 AS32252 -Reserved AS-,ZZ > 209.234.117.0/24 AS32252 -Reserved AS-,ZZ > 209.234.118.0/24 AS32252 -Reserved AS-,ZZ > 209.234.119.0/24 AS32252 -Reserved AS-,ZZ > 209.234.120.0/24 AS32252 -Reserved AS-,ZZ > 209.234.121.0/24 AS32252 -Reserved AS-,ZZ > 209.234.122.0/24 AS32252 -Reserved AS-,ZZ > 213.184.64.0/24 AS13071 -Reserved AS-,ZZ > 213.184.65.0/24 AS13071 -Reserved AS-,ZZ > 213.184.66.0/24 AS13071 -Reserved AS-,ZZ > 213.184.67.0/24 AS13071 -Reserved AS-,ZZ > 213.184.68.0/24 AS13071 -Reserved AS-,ZZ > 213.184.69.0/24 AS13071 -Reserved AS-,ZZ > 213.184.70.0/24 AS13071 -Reserved AS-,ZZ > 213.184.71.0/24 AS13071 -Reserved AS-,ZZ > 213.184.72.0/24 AS13071 -Reserved AS-,ZZ > 213.184.73.0/24 AS13071 -Reserved AS-,ZZ > 213.184.74.0/24 AS13071 -Reserved AS-,ZZ > 213.184.75.0/24 AS13071 -Reserved AS-,ZZ > 213.184.76.0/24 AS13071 -Reserved AS-,ZZ > 213.184.77.0/24 AS13071 -Reserved AS-,ZZ > 213.184.78.0/24 AS13071 -Reserved AS-,ZZ > 213.255.128.0/20 AS24863 LINKdotNET-AS,EG > 213.255.144.0/20 AS24863 LINKdotNET-AS,EG > 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US > 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US > 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US > 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US > 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US > 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US > 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US > 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US > 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US > > > 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 mansaxel at besserwisser.org Sun Aug 3 14:59:12 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sun, 3 Aug 2014 16:59:12 +0200 Subject: Muni Fiber and Politics In-Reply-To: <201408030511.09562.mark.tinka@seacom.mu> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <20140802233117.GA28317@besserwisser.org> <201408030511.09562.mark.tinka@seacom.mu> Message-ID: <20140803145912.GB28317@besserwisser.org> Subject: Re: Muni Fiber and Politics Date: Sun, Aug 03, 2014 at 05:11:09AM +0200 Quoting Mark Tinka (mark.tinka at seacom.mu): > On Sunday, August 03, 2014 01:31:17 AM M?ns Nilsson wrote: > > > Oh, yes, there is. Multicast? IPv6? Both CAN be done, but > > probably won't. > > I'm talking about the opportunities large bandwidth > presents, non-technical issues aside. > > Certainly, IPv6 and Multicast have a place on a 1Gbps link > into the customer's home. > > Unless I misunderstand what you're trying to say... My point is that "involving active electronics on a link lease may limit the ways that link can be used" and that there is a very high probability -- guesstimated from current "unbundling" infrastructure landscape -- that there will be severe constraints in services possible to provide if you as provider aren't lighting the path yourself. The constraints multiply with every OSI layer that is included in the unbundling offer, of course. A typical Swedish example is the solution with a "communications operator" -- a separate entity that owns and operates a layer 2 environment over which several different providers can sell IP connectivity. In most, if not all, cases in Sweden, the provisioning and management systems installed simply do not have any idea of an IPv6 address. Shortsighted? Yes, but driven by bad decisions and market needs NOW. (FSVO "NOW" that is embarrasingly recent...) A PITA to upgrade? Yes, of course, and the incentives aren't there, because the communications operator is a monopoly, so if you want to sell connections, you have to use them. The limits imposed on unbundled infrastructure are at the core 100% business-related; and as long as they are present, there must be regulated access to passive infrastructure, perhaps even including things like ducting/manholes/etc. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm shaving!! I'M SHAVING!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From corey.touchet at corp.totalserversolutions.com Sun Aug 3 15:32:18 2014 From: corey.touchet at corp.totalserversolutions.com (Corey Touchet) Date: Sun, 3 Aug 2014 15:32:18 +0000 Subject: The Cidr Report In-Reply-To: <53DC1E96.2060805@kouzmanoff.com> References: <201408012200.s71M00qS013033@wattle.apnic.net>, <53DC1E96.2060805@kouzmanoff.com> Message-ID: I wonder if it would be possible to run a bogon style BGP server that tells you about various subnets that have a valid higher aggregation so we can easily filter out the good de-aggregation vs just brute forcing via prefix filters. Sent from my iPhone > On Aug 2, 2014, at 9:31 PM, "keith kouzmanoff" wrote: > > link didn't work for me, I think http://www.cidr-report.org/as2.0/ is the proper link > >> On 8/1/2014 5:00 PM, cidr-report at potaroo.net wrote: >> This report has been generated at Fri Aug 1 21:13:59 2014 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/2.0 for a current version of this report. >> >> Recent Table History >> Date Prefixes CIDR Agg >> 25-07-14 508935 285928 >> 26-07-14 508775 286040 >> 27-07-14 508959 286213 >> 28-07-14 509275 286189 >> 29-07-14 509477 286110 >> 30-07-14 509841 286214 >> 31-07-14 510150 286361 >> 01-08-14 510519 286381 >> >> >> AS Summary >> 47759 Number of ASes in routing system >> 19365 Number of ASes announcing only one prefix >> 3794 Largest number of prefixes announced by an AS >> AS28573: NET Servi?os de Comunica??o S.A.,BR >> 120495616 Largest address span announced by an AS (/32s) >> AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN >> >> >> 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'). >> >> --- 01Aug14 --- >> ASnum NetsNow NetsAggr NetGain % Gain Description >> >> Table 510651 286295 224356 43.9% All ASes >> >> AS28573 3794 214 3580 94.4% NET Servi?os de Comunica??o >> S.A.,BR >> AS6389 2943 80 2863 97.3% BELLSOUTH-NET-BLK - >> BellSouth.net Inc.,US >> AS17974 2801 190 2611 93.2% TELKOMNET-AS2-AP PT >> Telekomunikasi Indonesia,ID >> AS7029 2887 485 2402 83.2% WINDSTREAM - Windstream >> Communications Inc,US >> AS4766 2949 928 2021 68.5% KIXS-AS-KR Korea Telecom,KR >> AS18881 2062 43 2019 97.9% Global Village Telecom,BR >> AS7545 2347 677 1670 71.2% TPG-INTERNET-AP TPG Telecom >> Limited,AU >> AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath >> Corporation,US >> AS10620 2939 1463 1476 50.2% Telmex Colombia S.A.,CO >> AS7303 1775 438 1337 75.3% Telecom Argentina S.A.,AR >> AS22773 2725 1401 1324 48.6% ASN-CXA-ALL-CCI-22773-RDC - >> Cox Communications Inc.,US >> AS4755 1866 594 1272 68.2% TATACOMM-AS TATA >> Communications formerly VSNL >> is Leading ISP,IN >> AS4323 1642 424 1218 74.2% TWTC - tw telecom holdings, >> inc.,US >> AS6983 1390 314 1076 77.4% ITCDELTA - Earthlink, Inc.,US >> AS22561 1305 242 1063 81.5% AS22561 - CenturyTel Internet >> Holdings, Inc.,US >> AS7552 1261 237 1024 81.2% VIETEL-AS-AP Viettel >> Corporation,VN >> AS9829 1653 738 915 55.4% BSNL-NIB National Internet >> Backbone,IN >> AS6147 1043 147 896 85.9% Telefonica del Peru S.A.A.,PE >> AS38285 956 112 844 88.3% M2TELECOMMUNICATIONS-AU M2 >> Telecommunications Group >> Ltd,AU >> AS24560 1153 345 808 70.1% AIRTELBROADBAND-AS-AP Bharti >> Airtel Ltd., Telemedia >> Services,IN >> AS4808 1207 416 791 65.5% CHINA169-BJ CNCGROUP IP >> network China169 Beijing >> Province Network,CN >> AS7738 977 190 787 80.6% Telemar Norte Leste S.A.,BR >> AS4788 1023 261 762 74.5% TMNET-AS-AP TM Net, Internet >> Service Provider,MY >> AS8151 1450 691 759 52.3% Uninet S.A. de C.V.,MX >> AS18101 947 189 758 80.0% RELIANCE-COMMUNICATIONS-IN >> Reliance Communications >> Ltd.DAKC MUMBAI,IN >> AS9808 1101 376 725 65.8% CMNET-GD Guangdong Mobile >> Communication Co.Ltd.,CN >> AS26615 860 136 724 84.2% Tim Celular S.A.,BR >> AS11492 1237 522 715 57.8% CABLEONE - CABLE ONE, INC.,US >> AS701 1438 726 712 49.5% UUNET - MCI Communications >> Services, Inc. d/b/a Verizon >> Business,US >> AS27738 772 64 708 91.7% Ecuadortelecom S.A.,EC >> >> Total 52550 13208 39342 74.9% Top 30 total >> >> >> Possible Bogus Routes >> >> 23.226.240.0/20 AS40430 -Reserved AS-,ZZ >> 23.226.240.0/21 AS40430 -Reserved AS-,ZZ >> 23.226.248.0/21 AS40430 -Reserved AS-,ZZ >> 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA >> 27.100.7.0/24 AS56096 >> 41.73.1.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.2.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.10.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.11.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.12.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.13.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.14.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.15.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.16.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.18.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.20.0/24 AS37004 -Reserved AS-,ZZ >> 41.73.21.0/24 AS37004 -Reserved AS-,ZZ >> 41.76.48.0/21 AS36969 MTL-AS,MW >> 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US >> 41.78.180.0/23 AS37265 -Reserved AS-,ZZ >> 41.78.236.0/24 AS37290 -Reserved AS-,ZZ >> 41.78.237.0/24 AS37290 -Reserved AS-,ZZ >> 41.78.238.0/24 AS37290 -Reserved AS-,ZZ >> 41.78.239.0/24 AS37290 -Reserved AS-,ZZ >> 41.189.96.0/20 AS37000 -Reserved AS-,ZZ >> 41.189.128.0/24 AS37000 -Reserved AS-,ZZ >> 41.190.1.0/24 AS37076 -Reserved AS-,ZZ >> 41.190.2.0/24 AS37076 -Reserved AS-,ZZ >> 41.190.3.0/24 AS37076 -Reserved AS-,ZZ >> 41.190.4.0/22 AS37076 -Reserved AS-,ZZ >> 41.190.4.0/24 AS37076 -Reserved AS-,ZZ >> 41.190.5.0/24 AS37076 -Reserved AS-,ZZ >> 41.190.8.0/24 AS37076 -Reserved AS-,ZZ >> 41.190.10.0/23 AS37076 -Reserved AS-,ZZ >> 41.190.12.0/24 AS37076 -Reserved AS-,ZZ >> 41.190.13.0/24 AS37076 -Reserved AS-,ZZ >> 41.190.14.0/24 AS37076 -Reserved AS-,ZZ >> 41.190.16.0/20 AS37076 -Reserved AS-,ZZ >> 41.190.72.0/24 AS37451 CongoTelecom,CG >> 41.190.73.0/24 AS37451 CongoTelecom,CG >> 41.190.74.0/24 AS37451 CongoTelecom,CG >> 41.190.75.0/24 AS37451 CongoTelecom,CG >> 41.191.108.0/22 AS37004 -Reserved AS-,ZZ >> 41.191.108.0/24 AS37004 -Reserved AS-,ZZ >> 41.191.109.0/24 AS37004 -Reserved AS-,ZZ >> 41.191.110.0/24 AS37004 -Reserved AS-,ZZ >> 41.191.111.0/24 AS37004 -Reserved AS-,ZZ >> 41.197.0.0/16 AS36934 -Reserved AS-,ZZ >> 41.223.208.0/22 AS37000 -Reserved AS-,ZZ >> 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL >> 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL >> 62.193.160.0/19 AS24801 -Reserved AS-,ZZ >> 62.193.160.0/20 AS24801 -Reserved AS-,ZZ >> 62.193.176.0/20 AS24801 -Reserved AS-,ZZ >> 64.25.16.0/23 AS19535 -Reserved AS-,ZZ >> 64.25.20.0/24 AS19535 -Reserved AS-,ZZ >> 64.25.21.0/24 AS19535 -Reserved AS-,ZZ >> 64.25.22.0/24 AS19535 -Reserved AS-,ZZ >> 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 64.111.160.0/20 AS40551 -Reserved AS-,ZZ >> 64.111.160.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.161.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.162.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.167.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.169.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.170.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.171.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.172.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.173.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.174.0/24 AS40551 -Reserved AS-,ZZ >> 64.111.175.0/24 AS40551 -Reserved AS-,ZZ >> 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US >> 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US >> 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US >> 66.6.176.0/20 AS13223 BBTECNETWORKS-HK RM18, 9/F., Kwan Yick Building Phase 1, 430-440A Des Voeux Rd. West.,HK >> 66.55.96.0/23 AS17203 -Reserved AS-,ZZ >> 66.55.98.0/24 AS17203 -Reserved AS-,ZZ >> 66.55.99.0/24 AS17203 -Reserved AS-,ZZ >> 66.55.100.0/22 AS17203 -Reserved AS-,ZZ >> 66.55.102.0/23 AS17203 -Reserved AS-,ZZ >> 66.55.104.0/21 AS17203 -Reserved AS-,ZZ >> 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA >> 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US >> 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US >> 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US >> 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT >> 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US >> 74.112.100.0/22 AS16764 -Reserved AS-,ZZ >> 74.113.200.0/23 AS46939 -Reserved AS-,ZZ >> 74.114.52.0/22 AS40818 -Reserved AS-,ZZ >> 74.114.52.0/23 AS40818 -Reserved AS-,ZZ >> 74.114.52.0/24 AS40818 -Reserved AS-,ZZ >> 74.114.53.0/24 AS40818 -Reserved AS-,ZZ >> 74.114.54.0/23 AS40818 -Reserved AS-,ZZ >> 74.114.54.0/24 AS40818 -Reserved AS-,ZZ >> 74.114.55.0/24 AS40818 -Reserved AS-,ZZ >> 74.118.132.0/22 AS5117 -Reserved AS-,ZZ >> 74.120.212.0/23 AS32326 -Reserved AS-,ZZ >> 74.120.214.0/23 AS32326 -Reserved AS-,ZZ >> 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US >> 77.243.80.0/24 AS42597 -Reserved AS-,ZZ >> 77.243.81.0/24 AS42597 -Reserved AS-,ZZ >> 77.243.88.0/24 AS42597 -Reserved AS-,ZZ >> 77.243.91.0/24 AS42597 -Reserved AS-,ZZ >> 77.243.94.0/24 AS42597 -Reserved AS-,ZZ >> 77.243.95.0/24 AS42597 -Reserved AS-,ZZ >> 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US >> 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US >> 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US >> 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US >> 80.250.32.0/22 AS37106 ODUA-AS,NG >> 85.202.160.0/20 AS44404 -Reserved AS-,ZZ >> 89.31.24.0/23 AS41455 -Reserved AS-,ZZ >> 89.31.26.0/23 AS41455 -Reserved AS-,ZZ >> 89.31.28.0/22 AS41455 -Reserved AS-,ZZ >> 89.207.8.0/21 AS3292 TDC TDC A/S,DK >> 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 91.197.36.0/22 AS43359 -Reserved AS-,ZZ >> 91.199.90.0/24 AS44330 -Reserved AS-,ZZ >> 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE >> 91.228.160.0/24 AS56815 -Reserved AS-,ZZ >> 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB >> 93.190.10.0/24 AS47254 -Reserved AS-,ZZ >> 95.215.140.0/22 AS48949 -Reserved AS-,ZZ >> 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU >> 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN >> 103.6.228.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP >> 103.9.108.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP >> 103.9.140.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU >> 103.9.141.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU >> 103.9.142.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU >> 103.9.143.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU >> 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN >> 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP >> 103.18.92.0/22 AS13269 >> 103.18.92.0/24 AS13269 >> 103.18.94.0/24 AS13269 >> 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP >> 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP >> 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN >> 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN >> 103.25.120.0/22 AS13280 >> 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP >> 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP >> 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP >> 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US >> 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US >> 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US >> 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN >> 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN >> 124.158.28.0/22 AS45857 >> 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA >> 162.218.168.0/21 AS40430 -Reserved AS-,ZZ >> 162.218.175.0/24 AS40430 -Reserved AS-,ZZ >> 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP >> 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US >> 172.85.0.0/24 AS29571 CITelecom-AS,CI >> 172.85.1.0/24 AS29571 CITelecom-AS,CI >> 172.85.2.0/24 AS29571 CITelecom-AS,CI >> 172.85.3.0/24 AS29571 CITelecom-AS,CI >> 172.86.0.0/24 AS29571 CITelecom-AS,CI >> 172.86.1.0/24 AS29571 CITelecom-AS,CI >> 172.86.2.0/24 AS29571 CITelecom-AS,CI >> 172.87.0.0/24 AS29571 CITelecom-AS,CI >> 172.88.0.0/24 AS29571 CITelecom-AS,CI >> 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN >> 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO >> 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN >> 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP >> 185.65.208.0/22 AS25394 MK-NETZDIENSTE-AS AS for MK Netzdienste GmbH & Co. KG,DE >> 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR >> 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US >> 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US >> 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US >> 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US >> 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US >> 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US >> 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US >> 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA >> 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US >> 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE >> 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US >> 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US >> 192.154.32.0/19 AS81 NCREN - MCNC,US >> 192.154.64.0/19 AS81 NCREN - MCNC,US >> 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US >> 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US >> 193.9.59.0/24 AS1257 TELE2,SE >> 193.16.106.0/24 AS31539 -Reserved AS-,ZZ >> 193.16.145.0/24 AS31392 -Reserved AS-,ZZ >> 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI >> 193.22.224.0/20 AS3322 -Reserved AS-,ZZ >> 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE >> 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB >> 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE >> 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB >> 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB >> 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES >> 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO >> 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO >> 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE >> 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US >> 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO >> 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB >> 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB >> 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT >> 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 193.243.166.0/24 AS44093 -Reserved AS-,ZZ >> 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA >> 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA >> 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE >> 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE >> 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE >> 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB >> 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE >> 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB >> 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE >> 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO >> 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE >> 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 194.126.219.0/24 AS34545 -Reserved AS-,ZZ >> 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR >> 194.126.251.0/24 AS50818 -Reserved AS-,ZZ >> 194.146.35.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR >> 194.146.36.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR >> 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE >> 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE >> 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE >> 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA >> 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO >> 195.39.252.0/23 AS29004 -Reserved AS-,ZZ >> 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE >> 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE >> 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE >> 195.234.156.0/24 AS25028 -Reserved AS-,ZZ >> 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 195.245.98.0/23 AS48918 GLOBALWAYS GLOBALWAYS AG,DE >> 196.3.182.0/24 AS37004 -Reserved AS-,ZZ >> 196.3.183.0/24 AS37004 -Reserved AS-,ZZ >> 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR >> 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US >> 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US >> 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US >> 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US >> 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US >> 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US >> 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US >> 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA >> 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA >> 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA >> 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US >> 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US >> 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US >> 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US >> 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US >> 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US >> 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US >> 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US >> 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US >> 198.254.96.0/20 AS40430 -Reserved AS-,ZZ >> 198.254.96.0/22 AS40430 -Reserved AS-,ZZ >> 198.254.100.0/22 AS40430 -Reserved AS-,ZZ >> 198.254.104.0/21 AS40430 -Reserved AS-,ZZ >> 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA >> 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US >> 199.116.200.0/21 AS22830 -Reserved AS-,ZZ >> 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US >> 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US >> 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US >> 200.58.248.0/21 AS27849 >> 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR >> 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR >> 200.81.50.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR >> 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR >> 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK >> 202.58.113.0/24 AS19161 -Reserved AS-,ZZ >> 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN >> 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG >> 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN >> 203.142.219.0/24 AS45149 >> 203.160.48.0/21 AS38008 >> 203.189.116.0/22 AS45606 >> 203.189.116.0/24 AS45606 >> 203.189.117.0/24 AS45606 >> 203.189.118.0/24 AS45606 >> 203.189.119.0/24 AS45606 >> 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US >> 204.10.94.0/23 AS30097 NUWAVE - NuWave,US >> 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US >> 204.16.96.0/24 AS19972 -Reserved AS-,ZZ >> 204.16.97.0/24 AS19972 -Reserved AS-,ZZ >> 204.16.98.0/24 AS19972 -Reserved AS-,ZZ >> 204.16.99.0/24 AS19972 -Reserved AS-,ZZ >> 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US >> 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US >> 204.155.28.0/22 AS40925 -Reserved AS-,ZZ >> 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB >> 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA >> 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US >> 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US >> 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA >> 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US >> 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA >> 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US >> 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US >> 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US >> 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US >> 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US >> 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US >> 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US >> 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US >> 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM >> 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM >> 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM >> 208.66.64.0/24 AS16936 -Reserved AS-,ZZ >> 208.66.65.0/24 AS16936 -Reserved AS-,ZZ >> 208.66.66.0/24 AS16936 -Reserved AS-,ZZ >> 208.66.67.0/24 AS16936 -Reserved AS-,ZZ >> 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US >> 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US >> 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US >> 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US >> 208.75.152.0/21 AS32146 -Reserved AS-,ZZ >> 208.76.20.0/24 AS31812 -Reserved AS-,ZZ >> 208.76.21.0/24 AS31812 -Reserved AS-,ZZ >> 208.77.164.0/24 AS22659 -Reserved AS-,ZZ >> 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US >> 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US >> 208.84.232.0/24 AS33131 -Reserved AS-,ZZ >> 208.84.234.0/24 AS33131 -Reserved AS-,ZZ >> 208.84.237.0/24 AS33131 -Reserved AS-,ZZ >> 208.84.238.0/24 AS33131 -Reserved AS-,ZZ >> 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US >> 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US >> 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US >> 209.209.224.0/19 AS19513 -Reserved AS-,ZZ >> 209.209.248.0/23 AS19513 -Reserved AS-,ZZ >> 209.209.250.0/23 AS19513 -Reserved AS-,ZZ >> 209.209.251.0/24 AS19513 -Reserved AS-,ZZ >> 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US >> 209.234.112.0/23 AS32252 -Reserved AS-,ZZ >> 209.234.114.0/23 AS32252 -Reserved AS-,ZZ >> 209.234.116.0/24 AS32252 -Reserved AS-,ZZ >> 209.234.117.0/24 AS32252 -Reserved AS-,ZZ >> 209.234.118.0/24 AS32252 -Reserved AS-,ZZ >> 209.234.119.0/24 AS32252 -Reserved AS-,ZZ >> 209.234.120.0/24 AS32252 -Reserved AS-,ZZ >> 209.234.121.0/24 AS32252 -Reserved AS-,ZZ >> 209.234.122.0/24 AS32252 -Reserved AS-,ZZ >> 213.184.64.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.65.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.66.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.67.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.68.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.69.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.70.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.71.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.72.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.73.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.74.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.75.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.76.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.77.0/24 AS13071 -Reserved AS-,ZZ >> 213.184.78.0/24 AS13071 -Reserved AS-,ZZ >> 213.255.128.0/20 AS24863 LINKdotNET-AS,EG >> 213.255.144.0/20 AS24863 LINKdotNET-AS,EG >> 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US >> 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US >> 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US >> 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US >> 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US >> 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US >> 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US >> 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US >> 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US >> >> >> 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 refresh.lsong at gmail.com Mon Aug 4 02:29:36 2014 From: refresh.lsong at gmail.com (Song Li) Date: Mon, 04 Aug 2014 10:29:36 +0800 Subject: question about bgp incremental updates Message-ID: <53DEF010.8010601@gmail.com> Hi everyone, I have a question about bgp updates: BGP uses an incremental update strategy to conserve bandwidth and processing power. That is, after initial exchange of complete routing information, a pair of BGP routers exchanges only the changes to that information. ( from RFC4274) According to this principle, if an AS suddenly announced a lot of updates (as below), can it be regarded as an anomaly such as BGP session reset? I wish to know if there are other reasons can result in this anomaly. Thanks! BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.24.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.28.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.16.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.20.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.16.0/20|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.12.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.12.0/22|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.204.0/23|6939 4436 25973 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.208.0/21|6939 4436 25973 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.8.0/24|6939 4436 25973 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|202.1.32.0/20|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.204.0/23|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.208.0/21|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.24.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.28.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.16.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.20.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.16.0/20|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.12.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.12.0/22|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.8.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|202.1.32.0/20|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|114.134.83.0/24|6939 3549 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|203.90.243.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|203.90.251.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|118.143.224.0/20|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|118.143.232.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|202.46.57.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|202.46.53.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|202.46.61.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|202.46.49.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|103.17.240.0/22|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|103.17.240.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|112.73.6.0/23|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|118.194.231.0/24|6939 3549 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|175.100.198.0/24|6939 3549 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|175.100.206.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|210.0.209.0/24|6939 4436 25973 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|210.3.0.0/22|6939 4436 25973 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|210.3.4.0/23|6939 4436 25973 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|103.227.207.0/24|6939 1299 3257 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|114.134.83.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|203.90.243.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|203.90.251.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|118.143.224.0/20|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|118.143.232.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|202.46.57.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|202.46.53.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|202.46.61.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|202.46.49.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|103.17.240.0/22|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|103.17.240.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|112.73.6.0/23|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|118.194.231.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|175.100.206.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|210.0.209.0/24|6939 9304|IGP -- Song Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.lsong at gmail.com From rdobbins at arbor.net Mon Aug 4 08:53:59 2014 From: rdobbins at arbor.net (arbor.net) Date: Mon, 4 Aug 2014 15:53:59 +0700 Subject: question about bgp incremental updates In-Reply-To: <53DEF010.8010601@gmail.com> References: <53DEF010.8010601@gmail.com> Message-ID: <850C858A-EA9A-4CB2-B060-758AD2D42753@arbor.net> On Aug 4, 2014, at 9:29 AM, Song Li wrote: > According to this principle, if an AS suddenly announced a lot of updates (as below), can it be regarded as an anomaly such as BGP session reset? Yes. It's wise to monitor BGP announcements received from peers, and to investigate when large numbers of announcements or withdrawals take place simultaneously. > I wish to know if there are other reasons can result in this anomaly. Human error, deliberate disaggregation for traffic-engineering purposes, accidental or deliberate hijacking, turning up new peering links, et. al. can result in sudden flurries of route announcements/withdrawals. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laoco?n From jra at baylink.com Mon Aug 4 14:38:39 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 4 Aug 2014 10:38:39 -0400 (EDT) Subject: Muni Fiber and Politics In-Reply-To: <240186FA-0A89-4E8D-87D6-5C4A6F14B726@delong.com> Message-ID: <10900562.7801.1407163119466.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > > On Aug 2, 2014, at 0:43, Mark Tinka wrote: > > > >> On Friday, August 01, 2014 07:17:24 PM Jay Ashworth wrote: > >> > >> So we'll assume we could get 4 for 22k to make the > >> arithmetic easy, and that means if we can put 44 people > >> on that, that the MRC cost is 500 dollars a month for a > >> gigabit. That is clearly not consumer pricing. Was > >> consumer pricing the assertion? > > > > I think Owen's pricing is based on 10Gbps router ports > > (Owen, correct me if I'm wrong). > > > > This is not the only way to sell 10Gbps services. > > > > Having said that, in context of home broadband, I was > > referring to AN's (Access Nodes), particularly based on > > Active-E (you don't generally place consumer customers > > directly on to 10Gbps router ports). > > > > The 10Gbps ports on an Active-E AN are in the same 1U > > chassis as the 44x Gig-E ports. And depending on how many > > you buy from vendors for your Access network, you can get > > pretty decent deals with good return if you get great uptake > > and have a sweet price point. That's the assertion Mark made, right there: that you could hook 44 GigE's to 4 10G's, and get "pretty decent deals". Specifically, Mark said (at top of thread): """ If the provider is able to deliver 1Gbps to every home (either on copper or fibre) with little to no uplink oversubscription (think 44x customer-facing Gig-E ports + 4x 10Gbps uplink ports), essentially, there is no limit to what services a provider and its partners can offer to its customers. """ So that implies he really did mean 44x GigE to end-prem, from 4 $5500 10G ports -- or, $500/home in MRC *cost* to the provider. I'm confused. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From bill at herrin.us Mon Aug 4 16:13:41 2014 From: bill at herrin.us (William Herrin) Date: Mon, 4 Aug 2014 12:13:41 -0400 Subject: Muni Fiber and Politics In-Reply-To: References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> Message-ID: On Fri, Aug 1, 2014 at 4:25 PM, Leo Bicknell wrote: > On Aug 1, 2014, at 9:44 AM, Owen DeLong wrote: >> IMHO, experience has taught us that the lines provider (or as I >> prefer to call them, the Layer 1 infrastructure provider) must be >> prohibited from playing at the higher layers. > > Owen has some really good points here, but may be overstating his case > a smidge. [...] > > Municipalities can be different. It?s possible to write into law that > they can offer L1 and L2 services, but never anything higher. There?s > also a built in disincentive to risk tax dollars more speculative, but > possibly more profitable ventures. Hi Leo, I can think of issues that arise when the municipality provides layer 2 services. 1. Enthusiasm (hence funding) for public works projects waxes and wanes. Generally it waxes long enough to get some portion of the original works project built, then it wanes until the project is in major disrepair, then it waxes again long enough to more or less fix it up. Acting as a layer-2 service provider will tend to exacerbate this effect. Let's all build gig-e to the homes! Great. And in 10 years when gige is passe there won't be any money for the 10 gig upgrade but the municipality will still have 20 years to go on the 30 year bond they floated to pay for the gige deployment. And no money for the equipment that corrects the IPv6 glitchiness or supports the brand new LocalVideoProtocol which would allow ultra high def super interactive television or whatever the rage is 10 year out. Single mode fiber's usefulness doesn't expire within any funding horizon applicable to a municipality. Gige service and any other lit service you can come up with today does. 2. It is in government's nature to expand. New big city service not arriving fast enough? We'll do it ourselves! Dear county commissioners, it'll only take a little bit of money (to do it badly), come on approve it, let's do it. You know you want it. > I can also see how some longer-distance links, imagine a link from > home to office across 30-40 miles, might be cheaper to deliver as 100M > VLAN than raw dark fiber and having to buy long reach optics. Long-reach optics are relatively cheap, or at least they can be if you optimize for expense. The better example is when you want ISP #1, phone company #2, TV service #3, data warehouse service #4, etc. With a lit service, you only have to buy the last-mile component once. > I can never see a case where letting them play at Layer 3 or above helps. Layers 2 and 3 are fuzzy these days. I think that's a bad place to draw a line. Rather draw the line between providing a local interconnect versus providing services and out-system communications. With a multi-service provider network there are, IMO, major advantages to implementing it with private-IP IPv4 instead of a layer 2 solution. No complicated vlans, PPoE or gpon channels. Just normal IP routing and normal access control filters available in even the cheap equipment. Then run your various virtual wire technologies (e.g. VPNs) over the IP network. Everybody is a peer on the network, so the infrastructure provider doesn't need to know anything about customer-service provider relationships and doesn't need to implement any special configurations in their network to serve them. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: Can I solve your unusual networking challenges? From owen at delong.com Mon Aug 4 16:35:18 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Aug 2014 09:35:18 -0700 Subject: Muni Fiber and Politics In-Reply-To: References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> Message-ID: <3324397F-6960-41D4-88FA-74B3BA8EF431@delong.com> > Single mode fiber's usefulness doesn't expire within any funding > horizon applicable to a municipality. Gige service and any other lit > service you can come up with today does. Well, not in the foreseeable future, anyway. I'm sure there was a time when that claim could have been made about copper. I would not make that claim about copper today (or even 10 years ago). >> I can also see how some longer-distance links, imagine a link from >> home to office across 30-40 miles, might be cheaper to deliver as 100M >> VLAN than raw dark fiber and having to buy long reach optics. > > Long-reach optics are relatively cheap, or at least they can be if you > optimize for expense. The better example is when you want ISP #1, > phone company #2, TV service #3, data warehouse service #4, etc. With > a lit service, you only have to buy the last-mile component once. In such a case, is there a reason you couldn't use the optics from ISP#1 as lit service to reach PhoneCo #2, TV-Co #3, and Warehouse #4 if that was desirable? Surely at least one of the 4 could provide optics and a convenient layer 2 handoff for the other services at least as easily and cost-effectively as L2 service from the L1 fiber provider. >> I can never see a case where letting them play at Layer 3 or above helps. > > Layers 2 and 3 are fuzzy these days. I think that's a bad place to draw a line. > > Rather draw the line between providing a local interconnect versus > providing services and out-system communications. I think the best line to draw is between passive facilities and active components. If it consumes electricity, regardless of power source, it shouldn't be part of the facilities network provider's purview with the possible exception of technology-agnostic amplifiers, which should be avoided whenever possible. > With a multi-service provider network there are, IMO, major advantages > to implementing it with private-IP IPv4 instead of a layer 2 solution. > No complicated vlans, PPoE or gpon channels. Just normal IP routing > and normal access control filters available in even the cheap > equipment. Then run your various virtual wire technologies (e.g. VPNs) > over the IP network. Everybody is a peer on the network, so the > infrastructure provider doesn't need to know anything about > customer-service provider relationships and doesn't need to implement > any special configurations in their network to serve them. In an already-sunk equipment cost environment, this might be a necessary tradeoff. In a greenfield deployment, there's no reason whatsoever not to use IPv6 GUA in place of RFC-1918 with the added advantage that you are not limited to ~17 million managed entries per management domain. Even ULA would be a better (albeit nearly as bad) choice than RFC-1918. Hmmm... Can one run 802.1q over GRE? (Too lazy to look that one up at the moment). Owen From bill at herrin.us Mon Aug 4 17:27:48 2014 From: bill at herrin.us (William Herrin) Date: Mon, 4 Aug 2014 13:27:48 -0400 Subject: Muni Fiber and Politics In-Reply-To: <3324397F-6960-41D4-88FA-74B3BA8EF431@delong.com> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> <3324397F-6960-41D4-88FA-74B3BA8EF431@delong.com> Message-ID: On Mon, Aug 4, 2014 at 12:35 PM, Owen DeLong wrote: >>> I can never see a case where letting them play at Layer 3 or above helps. >> >> Layers 2 and 3 are fuzzy these days. I think that's a bad place to draw a line. >> >> Rather draw the line between providing a local interconnect versus >> providing services and out-system communications. > > I think the best line to draw is between passive facilities and active components. Hi Owen, You've convinced me. However, I think it's still worth talking about where you draw the second line -- if the infrastructure provider implements a network with active components and some kind of digital data passing protocol, what should the scope of that capability be limited to? >> With a multi-service provider network there are, IMO, major advantages >> to implementing it with private-IP IPv4 instead of a layer 2 solution. >> No complicated vlans, PPoE or gpon channels. Just normal IP routing >> and normal access control filters available in even the cheap >> equipment. Then run your various virtual wire technologies (e.g. VPNs) >> over the IP network. Everybody is a peer on the network, so the >> infrastructure provider doesn't need to know anything about >> customer-service provider relationships and doesn't need to implement >> any special configurations in their network to serve them. > > In an already-sunk equipment cost environment, this might be a > necessary tradeoff. In a greenfield deployment, there's no reason > whatsoever not to use IPv6 GUA in place of RFC-1918 with the > added advantage that you are not limited to ~17 million managed > entries per management domain. Cost and availability of tools, equipment and personnel still strongly favors IPv4. Presumably that will eventually change, but it won't change for the equipment you can purchase today. The only point of providing lit service is to suppress the initial consumer-level cost, so let's not suggest choices that increase it. If the local infrastructure provider has a million customers in a single domain, it is too large to have implemented itself cost-effectively (they'll be using the super-expensive high-capacity low-production-run core equipment) and is straying into that undesirable territory where the infrastructure provider becomes a general service provider. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: Can I solve your unusual networking challenges? From tkaufman at corp.nac.net Mon Aug 4 17:53:48 2014 From: tkaufman at corp.nac.net (Timothy Kaufman) Date: Mon, 4 Aug 2014 17:53:48 +0000 Subject: Recommendations for a decent DWDM optical power meter. In-Reply-To: References: <53266209fb3041f39773a3b2e0afcef1@exch2013-1.hq.nac.net> <53D6B678.3070200@ninjabadger.net> Message-ID: <08e41bbb89e248969a04faa3854f24bb@exch2013-1.hq.nac.net> Correct me if I'm wrong but the solid optics power meter is just rebranded PPI? Also what about a decent but reasonably priced OSA? Suggestions? Tim Kaufman -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jeff Walter Sent: Tuesday, July 29, 2014 8:02 PM To: nanog at nanog.org Subject: Re: Recommendations for a decent DWDM optical power meter. We also have a Solid Optics CWDM meter and it does the job quite nicely. It feels solid (haha...) and is relatively cheap. -- Jeff Walter On Mon, Jul 28, 2014 at 4:34 PM, Neil Davidson wrote: > We have the Solid Optics DWDM and CWDM power meters. Simple, > inexpensive and works well ... > http://www.solid-optics.com/category/cwdm-dwdm/power-meter ... n > > > > -- > > K. Neil Davidson > +1-720-258-6345 > > > On Mon, Jul 28, 2014 at 2:45 PM, Tom Hill wrote: > > > On 28/07/14 19:33, Timothy Kaufman wrote: > > > >> Also maybe the ODPM-48. > >> > > > > I've got the CWDM version of this, and it does the job. Haven't > > explored the test result downloading/archiving features (didn't > > expect them to > work > > with Linux anyway) but overall it was very helpful for measuring > > loss across various passive muxes (where DDM wasn't available). > > > > Tom > > > From mfidelman at meetinghouse.net Mon Aug 4 18:11:44 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 04 Aug 2014 14:11:44 -0400 Subject: Muni Fiber and Politics In-Reply-To: <3324397F-6960-41D4-88FA-74B3BA8EF431@delong.com> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> <3324397F-6960-41D4-88FA-74B3BA8EF431@delong.com> Message-ID: <53DFCCE0.9030003@meetinghouse.net> Owen DeLong wrote: >> Single mode fiber's usefulness doesn't expire within any funding >> horizon applicable to a municipality. Gige service and any other lit >> service you can come up with today does. > Well, not in the foreseeable future, anyway. I'm sure there was a time when that claim could have been made about copper. I would not make that claim about copper today (or even 10 years ago). > Assuming the rodents don't eat your fiber. Miles Fidelman From EDugas at zerofail.com Mon Aug 4 19:56:37 2014 From: EDugas at zerofail.com (Eric Dugas) Date: Mon, 4 Aug 2014 19:56:37 +0000 Subject: Huawei Atom Router Message-ID: Has anyone seen/touched Huawei's Atom Router? It was announced at the Mobile World Congress 2014.. haven't seen anything on the Interweb since. I'd be interested in getting one or two units to play in my lab! http://www.huawei.com/mwc2014/en/articles/hw-328011.htm Eric From ahebert at pubnix.net Mon Aug 4 20:41:22 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Mon, 04 Aug 2014 16:41:22 -0400 Subject: Huawei Atom Router In-Reply-To: References: Message-ID: <53DFEFF2.6070006@pubnix.net> Well, Wasn't the Huawei CEO that stated that they where not interested into the US market. ( And by proxy ... the Canadian one ) http://www.theregister.co.uk/2013/04/23/huawei_not_interested_in_us/ And a bunch of ban's around Oct 2013 from a wide variety of countries... That's maybe why not many people are talking about their products in our corner of the world =D ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 08/04/14 15:56, Eric Dugas wrote: > Has anyone seen/touched Huawei's Atom Router? It was announced at the Mobile World Congress 2014.. haven't seen anything on the Interweb since. I'd be interested in getting one or two units to play in my lab! > > http://www.huawei.com/mwc2014/en/articles/hw-328011.htm > > Eric > > From eugen at imacandi.net Mon Aug 4 22:01:41 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Tue, 5 Aug 2014 01:01:41 +0300 Subject: Muni Fiber and Politics In-Reply-To: <453406B0-E05E-4E08-86BD-EA62268D0E69@delong.com> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <16884438.6618.1405952432741.JavaMail.root@benjamin.baylink.com> <53CD778E.1020406@wholesaleinternet.net> <53CDBF4F.2050305@meetinghouse.net> <53CE82D4.6080803@wholesaleinternet.net> <453406B0-E05E-4E08-86BD-EA62268D0E69@delong.com> Message-ID: On Tue, Jul 22, 2014 at 11:05 PM, Owen DeLong wrote: > > > OTOH, if the municipality provides only L1 concentration (dragging L1 > facilities > back to centralized locations where access providers can connect to large > numbers of customers), then access providers have to compete to deliver > what consumers actually want. They can't ignore the need for newer L2 > technologies because their competitor(s) will leap frog them and take away > their customers. This is what we, as consumers, want, isn't it? In my neck of the woods, the city hall decided that no more fiber cables running all over the poles in the city and somehow combined with some EU regulations that communication links need to be buried, they created a project whereby a 3rd party company would dig the whole city, put in some tubes in which microfibres would be installed by ISPs that reach every street number and ISP would pay per the kilometer from point A to point B (where point A was either a PoP or ISP HQ or whatever; point B is the customer). To be clear, this is single-mode dark fiber so the ISPs can run it at whatever speeds they like between two points. The only drawback is that the 3rd party company has a monopoly on the prices for the leasing of the tubes, but from my understanding this is kept under control by regulation. Eugeniu From nogs at border6.com Mon Aug 4 06:57:31 2014 From: nogs at border6.com (Mateusz Viste) Date: Mon, 04 Aug 2014 08:57:31 +0200 Subject: question about bgp incremental updates In-Reply-To: <1509-b6.nogs.nanog-04082014023510-E3@news.border6.com> References: <1509-b6.nogs.nanog-04082014023510-E3@news.border6.com> Message-ID: <53DF2EDB.1020700@border6.com> Hi, I can think of two reasons for such behavior: - one of the attributes of these routes changed suddenly, so they have been reannounced by your peer, - you sent a 'route refresh' request to this peer, asking him to reannounce all his table. Other than that, I don't see why a peer would resend lots of already-announced prefixes.. cheers, Mateusz On 08/04/2014 04:29 AM, Song Li wrote: > Hi everyone, > > I have a question about bgp updates: > > BGP uses an incremental update strategy to conserve bandwidth and > processing power. That is, after initial exchange of complete routing > information, a pair of BGP routers exchanges only the changes to that > information. ( from RFC4274) > > According to this principle, if an AS suddenly announced a lot of > updates (as below), can it be regarded as an anomaly such as BGP session > reset? I wish to know if there are other reasons can result in this > anomaly. > > Thanks! > > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.24.0/24|6939 > 15412 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.28.0/24|6939 > 15412 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.16.0/24|6939 > 15412 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.20.0/24|6939 > 15412 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.16.0/20|6939 > 15412 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.12.0/24|6939 > 15412 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.12.0/22|6939 > 15412 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.204.0/23|6939 > 4436 25973 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.208.0/21|6939 > 4436 25973 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.8.0/24|6939 4436 > 25973 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|202.1.32.0/20|6939 15412 > 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.204.0/23|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.208.0/21|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.24.0/24|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.28.0/24|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.16.0/24|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.20.0/24|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.16.0/20|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.12.0/24|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.12.0/22|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.8.0/24|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|202.1.32.0/20|6939 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|114.134.83.0/24|6939 > 3549 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|203.90.243.0/24|6939 > 15412 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|203.90.251.0/24|6939 > 15412 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|118.143.224.0/20|6939 > 15412 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|118.143.232.0/24|6939 > 15412 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|202.46.57.0/24|6939 > 15412 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|202.46.53.0/24|6939 > 15412 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|202.46.61.0/24|6939 > 15412 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|202.46.49.0/24|6939 > 15412 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|103.17.240.0/22|6939 > 15412 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|103.17.240.0/24|6939 > 15412 9304|IGP > BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|112.73.6.0/23|6939 15412 > 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|118.194.231.0/24|6939 > 3549 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|175.100.198.0/24|6939 > 3549 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|175.100.206.0/24|6939 > 15412 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|210.0.209.0/24|6939 4436 > 25973 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|210.3.0.0/22|6939 4436 > 25973 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|210.3.4.0/23|6939 4436 > 25973 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|103.227.207.0/24|6939 > 1299 3257 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|114.134.83.0/24|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|203.90.243.0/24|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|203.90.251.0/24|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|118.143.224.0/20|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|118.143.232.0/24|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|202.46.57.0/24|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|202.46.53.0/24|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|202.46.61.0/24|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|202.46.49.0/24|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|103.17.240.0/22|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|103.17.240.0/24|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|112.73.6.0/23|6939 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|118.194.231.0/24|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|175.100.206.0/24|6939 > 9304|IGP > BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|210.0.209.0/24|6939 > 9304|IGP > From marcus at blazingdot.com Mon Aug 4 20:21:48 2014 From: marcus at blazingdot.com (Marcus Reid) Date: Mon, 4 Aug 2014 16:21:48 -0400 Subject: Netflix And AT&T Sign Peering Agreement In-Reply-To: <2760669.7541.1406776865009.JavaMail.root@benjamin.baylink.com> References: <8745834.7529.1406765039876.JavaMail.root@benjamin.baylink.com> <2760669.7541.1406776865009.JavaMail.root@benjamin.baylink.com> Message-ID: <20140804202148.GA16715@blazingdot.com> On Wed, Jul 30, 2014 at 11:21:05PM -0400, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Jay Ashworth" > > > > Previously, Netflix signed similar agreements with Comcast and > > > Verizon. > > > > > > http://techcrunch.com/2014/07/29/netflix-and-att-sign-peering-agreement/ > > > > Am I nuts in thinking that *someone* has mispelt "Netflix agrees to > > buy transit from AT&T"? > > As several people were kind enough to point out to me off-list, "yes" > is the answer to that question. Thanks Jay. Can you put it in a nutshell just in case others are a little vague on the finer points of these arrangements and their significance in the current content provider / network provider row? The best thing about journalists is that they're always right (unless they're writing about something you know about, in which case they seem to always screw it up.) I like how in this case the author declares that "This is the new normal." Marcus From d3e3e3 at gmail.com Mon Aug 4 23:10:52 2014 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Mon, 4 Aug 2014 19:10:52 -0400 Subject: Huawei Atom Router In-Reply-To: <53DFEFF2.6070006@pubnix.net> References: <53DFEFF2.6070006@pubnix.net> Message-ID: Huawei has sales personal in the US and does sell here. See http://huawei.com/us/about-huawei/contact-us/index.htm And for a more recent Huawei management statement, see http://usa.chinadaily.com.cn/epaper/2014-04/28/content_17470474.htm "Huawei executive says it still seeks US sales" Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3 at gmail.com On Mon, Aug 4, 2014 at 4:41 PM, Alain Hebert wrote: > Well, > > Wasn't the Huawei CEO that stated that they where not interested > into the US market. > ( And by proxy ... the Canadian one ) > > http://www.theregister.co.uk/2013/04/23/huawei_not_interested_in_us/ > > And a bunch of ban's around Oct 2013 from a wide variety of countries... > > That's maybe why not many people are talking about their products in > our corner of the world =D > > ----- > Alain Hebert ahebert at pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > > On 08/04/14 15:56, Eric Dugas wrote: >> Has anyone seen/touched Huawei's Atom Router? It was announced at the Mobile World Congress 2014.. haven't seen anything on the Interweb since. I'd be interested in getting one or two units to play in my lab! >> >> http://www.huawei.com/mwc2014/en/articles/hw-328011.htm >> >> Eric >> >> > From jra at baylink.com Mon Aug 4 23:15:14 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 4 Aug 2014 19:15:14 -0400 (EDT) Subject: Muni Fiber and Politics In-Reply-To: Message-ID: <25588782.7821.1407194114728.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Eugeniu Patrascu" > In my neck of the woods, the city hall decided that no more fiber cables > running all over the poles in the city and somehow combined with some EU > regulations that communication links need to be buried, they created a > project whereby a 3rd party company would dig the whole city, put in some > tubes in which microfibres would be installed by ISPs that reach every > street number and ISP would pay per the kilometer from point A to point B > (where point A was either a PoP or ISP HQ or whatever; point B is the > customer). > > To be clear, this is single-mode dark fiber so the ISPs can run it at > whatever speeds they like between two points. > > The only drawback is that the 3rd party company has a monopoly on the > prices for the leasing of the tubes, but from my understanding this is > kept under control by regulation. This one is a bad idea cause you have lots of people pushing fiber through pipes with active fiber in them... and their incentives not to screw up other people's glass are... unclear? :-) Oh, wait: the conduit installer isn't a contractor, they're a monopoly? No, that's even worse. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Mon Aug 4 23:24:03 2014 From: jra at baylink.com (Jay Ashworth) Date: Mon, 4 Aug 2014 19:24:03 -0400 (EDT) Subject: Muni Fiber and Politics In-Reply-To: Message-ID: <9849979.7825.1407194643113.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Herrin" > I can think of issues that arise when the municipality provides layer > 2 services. > > 1. Enthusiasm (hence funding) for public works projects waxes and > wanes. Generally it waxes long enough to get some portion of the > original works project built, then it wanes until the project is in > major disrepair, then it waxes again long enough to more or less fix > it up. > > Acting as a layer-2 service provider will tend to exacerbate this > effect. Let's all build gig-e to the homes! Great. And in 10 years > when gige is passe there won't be any money for the 10 gig upgrade but > the municipality will still have 20 years to go on the 30 year bond > they floated to pay for the gige deployment. And no money for the > equipment that corrects the IPv6 glitchiness or supports the brand new > LocalVideoProtocol which would allow ultra high def super interactive > television or whatever the rage is 10 year out. You have forgotten here, Bill (I am feeling charitable, so I will not add ... no, I said I wouldn't add it) "MRC". Unlike some things for which bonds would be floated, this sort of service *would be being charged to someone, every month*. Sure, you won't get 100% take, but we factor that in. And, the number of times it's been said notwithstanding, I think a resaonably defensible case can be made that consumer services are pretty close to as good as they need to be at this point; for the *average* consumer, you're pretty hard pressed to run out of space on GigE downhill; uphill even moreso. Sure, there are edge cases, but we call them that for a reason. > Single mode fiber's usefulness doesn't expire within any funding > horizon applicable to a municipality. Gige service and any other lit > service you can come up with today does. Stipulated. > 2. It is in government's nature to expand. New big city service not > arriving fast enough? We'll do it ourselves! Dear county > commissioners, it'll only take a little bit of money (to do it badly), > come on approve it, let's do it. You know you want it. Was there an argument there? > > I can also see how some longer-distance links, imagine a link from > > home to office across 30-40 miles, might be cheaper to deliver as > > 100M > > VLAN than raw dark fiber and having to buy long reach optics. > > Long-reach optics are relatively cheap, or at least they can be if you > optimize for expense. The better example is when you want ISP #1, > phone company #2, TV service #3, data warehouse service #4, etc. With > a lit service, you only have to buy the last-mile component once. That sounds like an argument in *favor* of the Muni providing backstop service at L2, rather than the position against I thought you took. > > I can never see a case where letting them play at Layer 3 or above > > helps. > > Layers 2 and 3 are fuzzy these days. I think that's a bad place to > draw a line. > > Rather draw the line between providing a local interconnect versus > providing services and out-system communications. Ah. Then we *are* singing the same song, or most of it. > With a multi-service provider network there are, IMO, major advantages > to implementing it with private-IP IPv4 instead of a layer 2 solution. > No complicated vlans, PPoE or gpon channels. Just normal IP routing > and normal access control filters available in even the cheap > equipment. Then run your various virtual wire technologies (e.g. VPNs) > over the IP network. Everybody is a peer on the network, so the > infrastructure provider doesn't need to know anything about > customer-service provider relationships and doesn't need to implement > any special configurations in their network to serve them. Hmmm. This isn't the view I'd been getting from you on this, I don't believe. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From owen at delong.com Tue Aug 5 01:21:42 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Aug 2014 18:21:42 -0700 Subject: Muni Fiber and Politics In-Reply-To: References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> <3324397F-6960-41D4-88FA-74B3BA8EF431@delong.com> Message-ID: On Aug 4, 2014, at 10:27 AM, William Herrin wrote: > On Mon, Aug 4, 2014 at 12:35 PM, Owen DeLong wrote: >>>> I can never see a case where letting them play at Layer 3 or above helps. >>> >>> Layers 2 and 3 are fuzzy these days. I think that's a bad place to draw a line. >>> >>> Rather draw the line between providing a local interconnect versus >>> providing services and out-system communications. >> >> I think the best line to draw is between passive facilities and active components. > > Hi Owen, > > You've convinced me. However, I think it's still worth talking about > where you draw the second line -- if the infrastructure provider > implements a network with active components and some kind of digital > data passing protocol, what should the scope of that capability be > limited to? I would think that is only acceptable if they are REQUIRED to provide bare-bones passive L1 services wherever possible. (with the possible exception of amplifiers which you deleted from my previous message). >>> With a multi-service provider network there are, IMO, major advantages >>> to implementing it with private-IP IPv4 instead of a layer 2 solution. >>> No complicated vlans, PPoE or gpon channels. Just normal IP routing >>> and normal access control filters available in even the cheap >>> equipment. Then run your various virtual wire technologies (e.g. VPNs) >>> over the IP network. Everybody is a peer on the network, so the >>> infrastructure provider doesn't need to know anything about >>> customer-service provider relationships and doesn't need to implement >>> any special configurations in their network to serve them. >> >> In an already-sunk equipment cost environment, this might be a >> necessary tradeoff. In a greenfield deployment, there's no reason >> whatsoever not to use IPv6 GUA in place of RFC-1918 with the >> added advantage that you are not limited to ~17 million managed >> entries per management domain. > > Cost and availability of tools, equipment and personnel still strongly > favors IPv4. Presumably that will eventually change, but it won't > change for the equipment you can purchase today. The only point of > providing lit service is to suppress the initial consumer-level cost, > so let's not suggest choices that increase it. IPv6 capable tools do not cost more than IPv4 capable tools these days, so cost does not favor IPv4. As to availability, to some minor extent, but that is a matter of demand. If we make IPv6 a requirement in such circumstances, I guarantee you that availability for IPv6 capable tools will improve rapidly. I don?t believe that greenfield lit consumer service will reduce cost anyway. Further, putting anything in the network today that is not IPv6 capable does actually increase costs. Maybe not this week or even this year, but almost certainly in less than 3-5 years at this point. At current growth rates, IPv6 will service more end users than IPv4 by the end of 2016. > If the local infrastructure provider has a million customers in a > single domain, it is too large to have implemented itself > cost-effectively (they'll be using the super-expensive high-capacity > low-production-run core equipment) and is straying into that > undesirable territory where the infrastructure provider becomes a > general service provider. A management domain may span multiple service delivery domains. It may be that a provider which consists of many small service delivery domains wants to manage them as a single domain rather than running some sort of split-brained set of management domains. Owen From owen at delong.com Tue Aug 5 01:29:08 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Aug 2014 18:29:08 -0700 Subject: Muni Fiber and Politics In-Reply-To: <53DFCCE0.9030003@meetinghouse.net> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> <3324397F-6960-41D4-88FA-74B3BA8EF431@delong.com> <53DFCCE0.9030003@meetinghouse.net> Message-ID: <49C5894D-AFE0-4EEF-8F6B-AC186BB77D0A@delong.com> On Aug 4, 2014, at 11:11 AM, Miles Fidelman wrote: > Owen DeLong wrote: >>> Single mode fiber's usefulness doesn't expire within any funding >>> horizon applicable to a municipality. Gige service and any other lit >>> service you can come up with today does. >> Well, not in the foreseeable future, anyway. I'm sure there was a time when that claim could have been made about copper. I would not make that claim about copper today (or even 10 years ago). >> > Assuming the rodents don't eat your fiber. > > Miles Fidelman Most burried fiber is pretty rodent resistant these days. Owen From owen at delong.com Tue Aug 5 02:04:10 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Aug 2014 19:04:10 -0700 Subject: Muni Fiber and Politics In-Reply-To: References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <16884438.6618.1405952432741.JavaMail.root@benjamin.baylink.com> <53CD778E.1020406@wholesaleinternet.net> <53CDBF4F.2050305@meetinghouse.net> <53CE82D4.6080803@wholesaleinternet.net> <453406B0-E05E-4E08-86BD-EA62268D0E69@delong.com> Message-ID: <6DC76101-8DA6-422B-9CD9-72DDC9B30B71@delong.com> On Aug 4, 2014, at 3:01 PM, Eugeniu Patrascu wrote: > On Tue, Jul 22, 2014 at 11:05 PM, Owen DeLong wrote: > > OTOH, if the municipality provides only L1 concentration (dragging L1 facilities > back to centralized locations where access providers can connect to large > numbers of customers), then access providers have to compete to deliver > what consumers actually want. They can't ignore the need for newer L2 > technologies because their competitor(s) will leap frog them and take away > their customers. This is what we, as consumers, want, isn't it? > > In my neck of the woods, the city hall decided that no more fiber cables running all over the poles in the city and somehow combined with some EU regulations that communication links need to be buried, they created a project whereby a 3rd party company would dig the whole city, put in some tubes in which microfibres would be installed by ISPs that reach every street number and ISP would pay per the kilometer from point A to point B (where point A was either a PoP or ISP HQ or whatever; point B is the customer). > > To be clear, this is single-mode dark fiber so the ISPs can run it at whatever speeds they like between two points. > > The only drawback is that the 3rd party company has a monopoly on the prices for the leasing of the tubes, but from my understanding this is kept under control by regulation. As long as the price is regulated at a reasonable level and is available on equal footing to all comers, that?s about as good as it will get whether run by private enterprise or by the city itself. Owen From bbqroast at gmail.com Tue Aug 5 05:34:40 2014 From: bbqroast at gmail.com (mcfbbqroast .) Date: Tue, 5 Aug 2014 17:34:40 +1200 Subject: Muni Fiber and Politics In-Reply-To: <6DC76101-8DA6-422B-9CD9-72DDC9B30B71@delong.com> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <16884438.6618.1405952432741.JavaMail.root@benjamin.baylink.com> <53CD778E.1020406@wholesaleinternet.net> <53CDBF4F.2050305@meetinghouse.net> <53CE82D4.6080803@wholesaleinternet.net> <453406B0-E05E-4E08-86BD-EA62268D0E69@delong.com> <6DC76101-8DA6-422B-9CD9-72DDC9B30B71@delong.com> Message-ID: I agree with this, a monopoly is ok if the government regulates it properly and effectively. I'm a fan of either: Dark fibre to every house. Fiber to every house with a soft handover to the ISP. All ran by an entity forbidden from retail. Ideally a mix of both, soft handover for no thrills ISPs (reduced labour to connect user, reduced maintenance) and dark fibre for others (reduced costs, increased control). On 5 Aug 2014 14:11, "Owen DeLong" wrote: > > On Aug 4, 2014, at 3:01 PM, Eugeniu Patrascu wrote: > > > On Tue, Jul 22, 2014 at 11:05 PM, Owen DeLong wrote: > > > > OTOH, if the municipality provides only L1 concentration (dragging L1 > facilities > > back to centralized locations where access providers can connect to large > > numbers of customers), then access providers have to compete to deliver > > what consumers actually want. They can't ignore the need for newer L2 > > technologies because their competitor(s) will leap frog them and take > away > > their customers. This is what we, as consumers, want, isn't it? > > > > In my neck of the woods, the city hall decided that no more fiber cables > running all over the poles in the city and somehow combined with some EU > regulations that communication links need to be buried, they created a > project whereby a 3rd party company would dig the whole city, put in some > tubes in which microfibres would be installed by ISPs that reach every > street number and ISP would pay per the kilometer from point A to point B > (where point A was either a PoP or ISP HQ or whatever; point B is the > customer). > > > > To be clear, this is single-mode dark fiber so the ISPs can run it at > whatever speeds they like between two points. > > > > The only drawback is that the 3rd party company has a monopoly on the > prices for the leasing of the tubes, but from my understanding this is kept > under control by regulation. > > As long as the price is regulated at a reasonable level and is available > on equal footing to all comers, that?s about as good as it will get whether > run by private enterprise or by the city itself. > > Owen > > From bbqroast at gmail.com Tue Aug 5 05:38:37 2014 From: bbqroast at gmail.com (mcfbbqroast .) Date: Tue, 5 Aug 2014 17:38:37 +1200 Subject: Netflix And AT&T Sign Peering Agreement In-Reply-To: <20140804202148.GA16715@blazingdot.com> References: <8745834.7529.1406765039876.JavaMail.root@benjamin.baylink.com> <2760669.7541.1406776865009.JavaMail.root@benjamin.baylink.com> <20140804202148.GA16715@blazingdot.com> Message-ID: Gah, While I'd agree that Netflix shouldn't get free transit, AT&T shouldn't be charging for better access than Netflix can get over other tier 1s. Likewise, for local delivery there's nothing wrong with peering. Besides, when a small ISP starts up they have to buy transit/lay fibre to a major PoP. I'd not see them, or ISPs in other remote areas, charging for "transit". On 5 Aug 2014 10:57, "Marcus Reid" wrote: > On Wed, Jul 30, 2014 at 11:21:05PM -0400, Jay Ashworth wrote: > > ----- Original Message ----- > > > From: "Jay Ashworth" > > > > > > Previously, Netflix signed similar agreements with Comcast and > > > > Verizon. > > > > > > > > > http://techcrunch.com/2014/07/29/netflix-and-att-sign-peering-agreement/ > > > > > > Am I nuts in thinking that *someone* has mispelt "Netflix agrees to > > > buy transit from AT&T"? > > > > As several people were kind enough to point out to me off-list, "yes" > > is the answer to that question. > > Thanks Jay. Can you put it in a nutshell just in case others are a > little vague on the finer points of these arrangements and their > significance in the current content provider / network provider row? > > The best thing about journalists is that they're always right (unless > they're writing about something you know about, in which case they seem > to always screw it up.) I like how in this case the author declares > that "This is the new normal." > > Marcus > From a.harrowell at gmail.com Tue Aug 5 10:22:27 2014 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Tue, 5 Aug 2014 11:22:27 +0100 Subject: Richard Bennett, NANOG posting, and Integrity In-Reply-To: <20140728035224.GK14709@hezmatt.org> References: <53D56068.1000409@bennett.com> <53D59918.90402@bennett.com> <20140728023408.GG14709@hezmatt.org> <20140728035224.GK14709@hezmatt.org> Message-ID: On Mon, Jul 28, 2014 at 4:52 AM, Matt Palmer wrote: > On Mon, Jul 28, 2014 at 08:16:36AM +0530, Suresh Ramasubramanian wrote: >> On 28-Jul-2014 8:06 am, "Matt Palmer" wrote: >> > On Sun, Jul 27, 2014 at 05:28:08PM -0700, Richard Bennett wrote: >> > > It's more plausible that NAACP and LULAC have correctly deduced that >> > > net neutrality is a de facto subsidy program that transfers money >> > > from the pockets of the poor and disadvantaged into the pockets of >> > > super-heavy Internet users and some of the richest and most >> > > profitable companies in America, the content resellers, on-line >> > > retailers, and advertising networks. >> > >> > I've got to say, this is the first time I've heard Verizon and Comcast >> > described as "poor and disadvantaged". >> > >> > > Recall what happened to entry-level broadband plans in Chile when >> > > that nation's net neutrality law was just applied: the ISPs who >> > > provided free broadband starter plans that allowed access to >> > > Facebook and Wikipedia were required to charge the poor: >> > >> > [...] >> > >> > > Internet Freedom? Not so much. >> > >> > I totally agree. You can't have Internet Freedom when some of the >> > richest and most profitable companies in America, the content resellers, >> > on-line retailers, and advertising networks, are paying to have eyeballs >> > locked into their services. Far better that users be given an >> > opportunity to browse the Internet free of restriction, by providing >> > reasonable cost services through robust and healthy competition. >> > >> > Or is that perhaps not what you meant? >> >> I think he meant the actual poor people that broadband subsidies and free >> walled garden internet to access only fb and Wikipedia are supposed to >> benefit, but I could be wrong > > I've got a whopping great big privilege that's possibly obscuring my view, > but I fail to see how only providing access to Facebook and Wikipedia is (a) > actual *Internet* access, or (b) actually beneficial, in the long run, to > anyone other than Facebook and Wikipedia. I suppose it could benefit the > (no doubt incumbent) telco which is providing the service, since it makes it > much more difficult for competition to flourish. I can't see any lasting > benefit to the end user (or should I say "product"?). FYI it's Bharti-Airtel, not an incumbent, but a multinational GSM operator. > > - Matt > From dwcarder at wisc.edu Tue Aug 5 13:32:28 2014 From: dwcarder at wisc.edu (Dale W. Carder) Date: Tue, 05 Aug 2014 08:32:28 -0500 Subject: ASR9K xml agent vs netconf In-Reply-To: References: Message-ID: <20140805133227.GB72334@ricotta.doit.wisc.edu> Thus spake Jeremy (jbaino at gmail.com) on Fri, Aug 01, 2014 at 03:07:19PM -0700: > > I'm currently working on writing some automation around the ASR9K platform > and I've been looking at both the netconf and xml interfaces. Anyone have > experience with either? > > It looks like the XML interface is much more feature rich, supporting both > config and operational state objects where netconf is limited to config > only. > > Currently I'm leaning towards the xml interface, I wasted a week of my life trying to get xml interface on n9k to work correctly. I would never use it again, as it obviously gets no QA. There is likely a fundamental design flaw in that the cli is not itself an xml client like you see on other platforms. The XML interface, and CLI (presumably netconf) may all be distinct clients to sysdb. I did get (3) ddts' assigned, related to missing data compared to cli, endian issues, etc. My recommendation is DO NOT USE IT. I went back to screen scraping for ios-xr. Related to this and other issues, all of our subsequent purchases have been MX. Dale AS{59,2381,3128} From corey.touchet at corp.totalserversolutions.com Tue Aug 5 13:42:18 2014 From: corey.touchet at corp.totalserversolutions.com (Corey Touchet) Date: Tue, 5 Aug 2014 13:42:18 +0000 Subject: ASR9K xml agent vs netconf In-Reply-To: <20140805133227.GB72334@ricotta.doit.wisc.edu> Message-ID: I always preferred the displays where you have commands without all the bracket garbage and just indented text for sub items. On the MX the show configuration | display set is about as close as you can get, but it?s workable. Kudo?s is that you can just dump it in as well and get what you want. I think the only time I really get annoyed at the JunOS configurations is when I?m staring down any of their switches. On 8/5/14, 7:32 AM, "Dale W. Carder" wrote: > >Thus spake Jeremy (jbaino at gmail.com) on Fri, Aug 01, 2014 at 03:07:19PM >-0700: >> >> I'm currently working on writing some automation around the ASR9K >>platform >> and I've been looking at both the netconf and xml interfaces. Anyone >>have >> experience with either? >> >> It looks like the XML interface is much more feature rich, supporting >>both >> config and operational state objects where netconf is limited to config >> only. >> >> Currently I'm leaning towards the xml interface, > >I wasted a week of my life trying to get xml interface on n9k to work >correctly. I would never use it again, as it obviously gets no QA. > >There is likely a fundamental design flaw in that the cli is not itself >an xml client like you see on other platforms. The XML interface, and >CLI (presumably netconf) may all be distinct clients to sysdb. I did >get (3) ddts' assigned, related to missing data compared to cli, endian >issues, etc. My recommendation is DO NOT USE IT. > >I went back to screen scraping for ios-xr. Related to this and other >issues, all of our subsequent purchases have been MX. > >Dale >AS{59,2381,3128} From owen at delong.com Tue Aug 5 15:00:10 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Aug 2014 08:00:10 -0700 Subject: Muni Fiber and Politics In-Reply-To: References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <16884438.6618.1405952432741.JavaMail.root@benjamin.baylink.com> <53CD778E.1020406@wholesaleinternet.net> <53CDBF4F.2050305@meetinghouse.net> <53CE82D4.6080803@wholesaleinternet.net> <453406B0-E05E-4E08-86BD-EA62268D0E69@delong.com> <6DC76101-8DA6-422B-9CD9-72DDC9B30B71@delong.com> Message-ID: <9E67ECFC-FC70-4947-8ED2-AE6EE86A5386@delong.com> On Aug 4, 2014, at 10:34 PM, mcfbbqroast . wrote: > I agree with this, a monopoly is ok if the government regulates it properly > and effectively. > > I'm a fan of either: > > Dark fibre to every house. > > Fiber to every house with a soft handover to the ISP. The problem with soft handover is that the monopoly provider is in a place to stifle innovation and creativity by creating a limitation on what kinds of handoffs/protocols/etc. can be supported. > All ran by an entity forbidden from retail. > > Ideally a mix of both, soft handover for no thrills ISPs (reduced labour to > connect user, reduced maintenance) and dark fibre for others (reduced > costs, increased control). I don?t mind an optional soft handover, but dark fiber MUST be a required service. Owen > On 5 Aug 2014 14:11, "Owen DeLong" wrote: > >> >> On Aug 4, 2014, at 3:01 PM, Eugeniu Patrascu wrote: >> >>> On Tue, Jul 22, 2014 at 11:05 PM, Owen DeLong wrote: >>> >>> OTOH, if the municipality provides only L1 concentration (dragging L1 >> facilities >>> back to centralized locations where access providers can connect to large >>> numbers of customers), then access providers have to compete to deliver >>> what consumers actually want. They can't ignore the need for newer L2 >>> technologies because their competitor(s) will leap frog them and take >> away >>> their customers. This is what we, as consumers, want, isn't it? >>> >>> In my neck of the woods, the city hall decided that no more fiber cables >> running all over the poles in the city and somehow combined with some EU >> regulations that communication links need to be buried, they created a >> project whereby a 3rd party company would dig the whole city, put in some >> tubes in which microfibres would be installed by ISPs that reach every >> street number and ISP would pay per the kilometer from point A to point B >> (where point A was either a PoP or ISP HQ or whatever; point B is the >> customer). >>> >>> To be clear, this is single-mode dark fiber so the ISPs can run it at >> whatever speeds they like between two points. >>> >>> The only drawback is that the 3rd party company has a monopoly on the >> prices for the leasing of the tubes, but from my understanding this is kept >> under control by regulation. >> >> As long as the price is regulated at a reasonable level and is available >> on equal footing to all comers, that?s about as good as it will get whether >> run by private enterprise or by the city itself. >> >> Owen >> >> From randy at psg.com Tue Aug 5 15:34:14 2014 From: randy at psg.com (Randy Bush) Date: Wed, 06 Aug 2014 00:34:14 +0900 Subject: Huawei Atom Router In-Reply-To: <53DFEFF2.6070006@pubnix.net> References: <53DFEFF2.6070006@pubnix.net> Message-ID: > And a bunch of ban's around Oct 2013 from a wide variety of > countries... you mean fear of implants as there are in cisco products? From hslabbert at stargate.ca Tue Aug 5 16:01:21 2014 From: hslabbert at stargate.ca (Hugo Slabbert) Date: Tue, 5 Aug 2014 09:01:21 -0700 Subject: ASR9K xml agent vs netconf In-Reply-To: References: <20140805133227.GB72334@ricotta.doit.wisc.edu> Message-ID: <20140805160121.GE25965@stargate.ca> >Kudo?s is that you can just dump it in as well and get what you want. You can dump hierarchical config (the bracket stuff) into JunOS with "load" plus the added benefit/flexibility of the merge/replace/override options. -- Hugo On Tue 2014-Aug-05 13:42:18 +0000, Corey Touchet wrote: >I always preferred the displays where you have commands without all the >bracket garbage and just indented text for sub items. > > >On the MX the show configuration | display set is about as close as you >can get, but it?s workable. Kudo?s is that you can just dump it in as >well and get what you want. I think the only time I really get annoyed at >the JunOS configurations is when I?m staring down any of their switches. > >On 8/5/14, 7:32 AM, "Dale W. Carder" wrote: > >> >>Thus spake Jeremy (jbaino at gmail.com) on Fri, Aug 01, 2014 at 03:07:19PM >>-0700: >>> >>> I'm currently working on writing some automation around the ASR9K >>>platform >>> and I've been looking at both the netconf and xml interfaces. Anyone >>>have >>> experience with either? >>> >>> It looks like the XML interface is much more feature rich, supporting >>>both >>> config and operational state objects where netconf is limited to config >>> only. >>> >>> Currently I'm leaning towards the xml interface, >> >>I wasted a week of my life trying to get xml interface on n9k to work >>correctly. I would never use it again, as it obviously gets no QA. >> >>There is likely a fundamental design flaw in that the cli is not itself >>an xml client like you see on other platforms. The XML interface, and >>CLI (presumably netconf) may all be distinct clients to sysdb. I did >>get (3) ddts' assigned, related to missing data compared to cli, endian >>issues, etc. My recommendation is DO NOT USE IT. >> >>I went back to screen scraping for ios-xr. Related to this and other >>issues, all of our subsequent purchases have been MX. >> >>Dale >>AS{59,2381,3128} > From eugen at imacandi.net Tue Aug 5 16:33:22 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Tue, 5 Aug 2014 19:33:22 +0300 Subject: Muni Fiber and Politics In-Reply-To: <25588782.7821.1407194114728.JavaMail.root@benjamin.baylink.com> References: <25588782.7821.1407194114728.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Aug 5, 2014 at 2:15 AM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Eugeniu Patrascu" > > > In my neck of the woods, the city hall decided that no more fiber cables > > running all over the poles in the city and somehow combined with some EU > > regulations that communication links need to be buried, they created a > > project whereby a 3rd party company would dig the whole city, put in some > > tubes in which microfibres would be installed by ISPs that reach every > > street number and ISP would pay per the kilometer from point A to point B > > (where point A was either a PoP or ISP HQ or whatever; point B is the > > customer). > > > > To be clear, this is single-mode dark fiber so the ISPs can run it at > > whatever speeds they like between two points. > > > > The only drawback is that the 3rd party company has a monopoly on the > > prices for the leasing of the tubes, but from my understanding this is > > kept under control by regulation. > > This one is a bad idea cause you have lots of people pushing fiber through > pipes with active fiber in them... and their incentives not to screw up > other people's glass are... unclear? :-) > Not really, if one company starts making mistakes, the other will also mistake their cables. It's like a working mexican standoff :) > > Oh, wait: the conduit installer isn't a contractor, they're a monopoly? > > The people pushing fiber through the conduits are contractors. There are a handful of companies licensed to operate this. > No, that's even worse. It's not perfect, but it works. From owen at delong.com Tue Aug 5 17:26:44 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Aug 2014 10:26:44 -0700 Subject: Muni Fiber and Politics In-Reply-To: References: <25588782.7821.1407194114728.JavaMail.root@benjamin.baylink.com> Message-ID: <885C4E30-8FB9-43EE-A602-836FA7B7C347@delong.com> >> >> This one is a bad idea cause you have lots of people pushing fiber through >> pipes with active fiber in them... and their incentives not to screw up >> other people's glass are... unclear? :-) > > Not really, if one company starts making mistakes, the other will also > mistake their cables. It's like a working mexican standoff :) > > In reality, Mexican standoffs are often fatal. >> Oh, wait: the conduit installer isn't a contractor, they're a monopoly? > The people pushing fiber through the conduits are contractors. There are a > handful of companies licensed to operate this. May be workable, but seems more expensive than operating cross connects in a serving wire center with little or no plausible benefit. > > >> No, that's even worse. > > > It's not perfect, but it works. People say that about windows. I don't use it, either. Owen From ahebert at pubnix.net Tue Aug 5 17:32:54 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Tue, 05 Aug 2014 13:32:54 -0400 Subject: Huawei Atom Router In-Reply-To: References: <53DFEFF2.6070006@pubnix.net> Message-ID: <53E11546.4080200@pubnix.net> Was more a statement of fact. As if it was warranted. I do not know. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 08/05/14 11:34, Randy Bush wrote: >> And a bunch of ban's around Oct 2013 from a wide variety of >> countries... > you mean fear of implants as there are in cisco products? > > From eugen at imacandi.net Tue Aug 5 17:56:18 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Tue, 5 Aug 2014 20:56:18 +0300 Subject: Muni Fiber and Politics In-Reply-To: <885C4E30-8FB9-43EE-A602-836FA7B7C347@delong.com> References: <25588782.7821.1407194114728.JavaMail.root@benjamin.baylink.com> <885C4E30-8FB9-43EE-A602-836FA7B7C347@delong.com> Message-ID: On Tue, Aug 5, 2014 at 8:26 PM, Owen DeLong wrote: > > >> > >> This one is a bad idea cause you have lots of people pushing fiber > through > >> pipes with active fiber in them... and their incentives not to screw up > >> other people's glass are... unclear? :-) > > > > Not really, if one company starts making mistakes, the other will also > > mistake their cables. It's like a working mexican standoff :) > > > > > > In reality, Mexican standoffs are often fatal. > > If you blink. > >> Oh, wait: the conduit installer isn't a contractor, they're a monopoly? > > The people pushing fiber through the conduits are contractors. There are > a > > handful of companies licensed to operate this. > > May be workable, but seems more expensive than operating cross connects in > a serving wire center with little or no plausible benefit. > > So how is blowing microfibre in some tubes more expensive? You pay a one off installation fee and then a small monthly rate for the circuit (payable yearly). The really nice and geeky part is that you can actually choose how your fiber will run, so if you want diverse paths to a location you can achieve that with certainty. > > > > > >> No, that's even worse. > > > > > > It's not perfect, but it works. > > People say that about windows. I don't use it, either. > :) It works because it's very cheap to get high speed internet into all kinds of areas, especially residential ones. From bill at herrin.us Tue Aug 5 18:10:03 2014 From: bill at herrin.us (William Herrin) Date: Tue, 5 Aug 2014 14:10:03 -0400 Subject: Muni Fiber and Politics In-Reply-To: References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <16884438.6618.1405952432741.JavaMail.root@benjamin.baylink.com> <53CD778E.1020406@wholesaleinternet.net> <53CDBF4F.2050305@meetinghouse.net> <53CE82D4.6080803@wholesaleinternet.net> <453406B0-E05E-4E08-86BD-EA62268D0E69@delong.com> <6DC76101-8DA6-422B-9CD9-72DDC9B30B71@delong.com> Message-ID: On Tue, Aug 5, 2014 at 1:34 AM, mcfbbqroast . wrote: > I agree with this, a monopoly is ok if the government regulates it properly > and effectively. > > I'm a fan of either: > > Dark fibre to every house. > > Fiber to every house with a soft handover to the ISP. > > All ran by an entity forbidden from retail. Nonononono, bad plan. I want a fiber from my home to my storefront on main street, but I'm a consumer not a retailer so I can't buy just one? Or hey, so sorry but the cable MuniFiber ran to your home is under contract to XYZ corp. They have to release it before we at ABC corp can provide you service. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: Can I solve your unusual networking challenges? From bill at herrin.us Tue Aug 5 18:26:41 2014 From: bill at herrin.us (William Herrin) Date: Tue, 5 Aug 2014 14:26:41 -0400 Subject: Muni Fiber and Politics In-Reply-To: References: <25588782.7821.1407194114728.JavaMail.root@benjamin.baylink.com> <885C4E30-8FB9-43EE-A602-836FA7B7C347@delong.com> Message-ID: On Tue, Aug 5, 2014 at 1:56 PM, Eugeniu Patrascu wrote: > So how is blowing microfibre in some tubes more expensive? You pay a one > off installation fee and then a small monthly rate for the circuit (payable > yearly). > > The really nice and geeky part is that you can actually choose how your > fiber will run, so if you want diverse paths to a location you can achieve > that with certainty. Hi Eugeniu, The word you're searching for is "microduct." I'm a big fan of Microduct. There's even some wicked cool equipment which will force the core out of in-place coax plant, converting it to microduct suitable for a fiber installation. But here are some of the places you may run in to trouble using it for a municipal fiber installation: 1. 10 miles of fiber optic cable is expensive (from a consumer perspective) even when you're able to float it through a series of ducts instead of having to trench. Who covers the cost? If the service provider amortizes it for the consumer (instead of the municipal infrastructure provider) then you're right back to the consumer lock-in that damages competition. 2. While microduct supports 12 or 24 fibers in a single duct, it does not support adding or removing fibers from a duct. To install a different quantity, you have to remove all the existing fiber and then blow a completely new set of fibers. Obviously service provider A is not motivated to install extra fibers that service provider B can subsequently sell you service on. Only a bare infrastructure provider would have that motivation. 3. Structure is good. It facilitates reuse. If you permit the fiber to be run between arbitrary points you end up with the same cruft as an office without structured cabling. Even if you use microduct, future-proofing requires central cross-connect points where folks patch. 4. I'm not sure how far you can float fiber down a microduct but I'm pretty sure you don't do it miles at a stretch. So, if you build your system with microduct and fiber-blown-later, you'll have a *lot* of points where the ducts have to be joined. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: Can I solve your unusual networking challenges? From rs at seastrom.com Tue Aug 5 20:43:00 2014 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 05 Aug 2014 16:43:00 -0400 Subject: Huawei Atom Router In-Reply-To: <53E11546.4080200@pubnix.net> (Alain Hebert's message of "Tue, 05 Aug 2014 13:32:54 -0400") References: <53DFEFF2.6070006@pubnix.net> <53E11546.4080200@pubnix.net> Message-ID: <86a97ioegb.fsf@valhalla.seastrom.com> To be fair, they've fixed one of the big concerns that were raised with them a couple of years ago: google for huawei + psirt now actually returns usable results. No idea how well the interface with them works when you're actually trying to report a vulnerability (maybe someone can speak up). -r Alain Hebert writes: > Was more a statement of fact. > > As if it was warranted. I do not know. > > ----- > Alain Hebert ahebert at pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > > On 08/05/14 11:34, Randy Bush wrote: >>> And a bunch of ban's around Oct 2013 from a wide variety of >>> countries... >> you mean fear of implants as there are in cisco products? >> >> From eugen at imacandi.net Tue Aug 5 21:06:00 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Wed, 6 Aug 2014 00:06:00 +0300 Subject: Muni Fiber and Politics In-Reply-To: References: <25588782.7821.1407194114728.JavaMail.root@benjamin.baylink.com> <885C4E30-8FB9-43EE-A602-836FA7B7C347@delong.com> Message-ID: On Tue, Aug 5, 2014 at 9:26 PM, William Herrin wrote: > > Hi Eugeniu, > > The word you're searching for is "microduct." > That's it, I wasn't sure about it. > I'm a big fan of Microduct. There's even some wicked cool equipment > which will force the core out of in-place coax plant, converting it to > microduct suitable for a fiber installation. But here are some of the > places you may run in to trouble using it for a municipal fiber > installation: > > > 1. 10 miles of fiber optic cable is expensive (from a consumer > perspective) even when you're able to float it through a series of > ducts instead of having to trench. Who covers the cost? If the service > provider amortizes it for the consumer (instead of the municipal > infrastructure provider) then you're right back to the consumer > lock-in that damages competition. > For business connections, the customer pays the cost from the nearest PoP to its premises as a one time installation fee and then the yearly cost of "renting" is spread out over 12 months. This is what one of my ISPs told me. But the price is pretty much negligible to rent this compared to what you pay for the actual "Internet" connection. For residential areas I'm not sure, but being predominantly apartment blocks, I think the ISP takes the "hit" as at least my bills haven't gone up. > > 2. While microduct supports 12 or 24 fibers in a single duct, it does > not support adding or removing fibers from a duct. To install a > different quantity, you have to remove all the existing fiber and then > blow a completely new set of fibers. Obviously service provider A is > not motivated to install extra fibers that service provider B can > subsequently sell you service on. Only a bare infrastructure provider > would have that motivation. > Each ISP has a microduct. I've seen "output/breakout" boxes in the street with several microducts labeled with different ISP names, so no worries here. I'm not sure how many are installed by default, but probably it depends on the area, maybe 12 in residential areas and 24 in crowded areas. I really don't know. Also, one ISP can have (I think) as many microducts as they can buy. > 3. Structure is good. It facilitates reuse. If you permit the fiber to > be run between arbitrary points you end up with the same cruft as an > office without structured cabling. Even if you use microduct, > future-proofing requires central cross-connect points where folks > patch. > > There are a lot of manholes for this stuff, some bigger and some a little bit smaller. I've never been into one to see how they are organized. Yes, you can get a lot of cruft, but installing OMMRs in the middle of the street tends to be expensive (even if you can somehow burry a room underneath the street to house them) so I guess the current method works best given the conditions. > 4. I'm not sure how far you can float fiber down a microduct but I'm > pretty sure you don't do it miles at a stretch. So, if you build your > system with microduct and fiber-blown-later, you'll have a *lot* of > points where the ducts have to be joined. > > I also have no idea about the length, but it seems to be working so far. Also, splicing fibers is done so fast by qualified technicians that it doesn't add a significant amount of time to get a circuit ready - I think it's around 5 minutes for a pair of fibres. Eugeniu From jra at baylink.com Tue Aug 5 21:13:59 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 5 Aug 2014 17:13:59 -0400 (EDT) Subject: FCC Releases Tenth Broadband Inquiry NOI Message-ID: <3289050.7871.1407273238982.JavaMail.root@benjamin.baylink.com> """ Section 706 of the Telecommunications Act of 1996, as amended (1996 Act), requires the Commission to determine and report annually on "whether advanced telecommunications capability is being deployed to all Americans in a reasonable and timely fashion". 1) This Notice of Inquiry (Inquiry) initiates the Commission?s assessment of the availability of advanced telecommunications capability to all Americans (including, in particular, elementary and secondary schools and classrooms). 2) In conducting this Inquiry, the Commission must ?determine whether advanced telecommunications capability is being deployed to all Americans in a reasonable and timely fashion and, if the answer is negative, the Commission "shall take immediate action to accelerate deployment of such capability" through a variety of means. 3) In this Inquiry, we solicit data and information that will help the Commission make this determination. """ The PDF versions are at: https://apps.fcc.gov/edocs_public/attachmatch/FCC-14-113A1.pdf https://apps.fcc.gov/edocs_public/attachmatch/FCC-14-113A2.pdf https://apps.fcc.gov/edocs_public/attachmatch/FCC-14-113A3.pdf https://apps.fcc.gov/edocs_public/attachmatch/FCC-14-113A4.pdf Unless I'm badly misreading this, in particular, if you have a problem with the FCC's broadband penetration numbers being predicated on "this zip has broadband because *these six houses on the north edge of town have DSL*, then this is where your comments on that will get ignored. (Their current cutoff, for those who did not know, is 4/1, so DSL actually *does not qualify as broadband* for Section 706 purposes.) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Tue Aug 5 21:34:20 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 5 Aug 2014 17:34:20 -0400 (EDT) Subject: Remooted: a deployment design for Muni Fiber (was Re: Muni Fiber and Politics) In-Reply-To: Message-ID: <28415725.7877.1407274460265.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Herrin" > > All ran by an entity forbidden from retail. > > Nonononono, bad plan. I want a fiber from my home to my storefront on > main street, but I'm a consumer not a retailer so I can't buy just > one? Or hey, so sorry but the cable MuniFiber ran to your home is > under contract to XYZ corp. They have to release it before we at ABC > corp can provide you service. Well, yeah; I actually agree with most of that. My plan, to recap it from '12, was this: You can rent, for an MRC (probably plus a deposit): 1) L2 connectivity to a property, talking to an ONT supplied by the utility, that is a virtual circuit to the prem, and delivered to you as (I think) QinQ. That is: you get a completely clean Ethernet connection, over which you can run IPv4 or IPv6, with whatever addressing you want, to a GigE port on the ONT, as long as the customer has one free. If the customer wants their 4 ports to go to 4 different ISPs? Fine. 2) L1 connectivity to a property, over any available pair provisioned to that address -- I was planning on 3 pair drops for 1-3 unit properties, and a declining overbuild from 2 down to about 1.2 pairs per unit for stripcenters and apartment buildings and the like. Obviously, this will cost more, as it's a more limited resource. This would allow you to plug the fiber directly into your switch at both ends, and we'll just xconn the two drops in the fiber room. 3) If you're really motivated for some reason, with an even larger deposit, we will have our contractor pull your fiber into our conduits, running from wherever you need to go to wherever else you need to go. This would be a contractual setup, I suspect, as it needs to handle title in case of abandonment, and like that. Presumably, it would not carry an MRC, unless it appears in our fiber room (which it probably should), in which case a nominal charge for the jumper and any NRCs for special work. I can't see why anyone would actually need this, but I mention it for completeness sake -- I plan to preprovision additional trunking in strategic places, so we can get more than 3 pairs someplace should we really need it; fiber's (mostly) cheap; crews are expensive. As I noted originally, I think providing L2 service is useful as it (sharply) reduces the barrier-to-entry to smaller "boutique" ISP services, at the cost of their perhaps being at our mercy for upgrades and such. If we do our job properly, I don't think too many such speed bumps would affect such people. We're pretty far along the development curve now; anyone who thinks symmetrical gigabit isn't enough either has never used it (with a good backhaul), or needs to be on Internet2. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From matthew at matthew.at Tue Aug 5 23:01:29 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 05 Aug 2014 16:01:29 -0700 Subject: Remooted: a deployment design for Muni Fiber (was Re: Muni Fiber and Politics) In-Reply-To: <28415725.7877.1407274460265.JavaMail.root@benjamin.baylink.com> References: <28415725.7877.1407274460265.JavaMail.root@benjamin.baylink.com> Message-ID: <53E16249.8080906@matthew.at> Is there any way we could stop this discussion until we can get some participants who have experience doing things like emergency post-ice-storm overhead circuit restoration to show up and explain exactly why charging a small one-time fee for a fiber from A to Z is probably not a sustainable model? In the meantime, I'd like to see the city where an ISP can buy as many of the microducts as they want. I'd like to buy them all, please... though I have no intention of running anything though them, as I'm an investor in the local cable TV company. Matthew Kaufman From rs at seastrom.com Wed Aug 6 00:29:26 2014 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 05 Aug 2014 20:29:26 -0400 Subject: Remooted: a deployment design for Muni Fiber (was Re: Muni Fiber and Politics) In-Reply-To: <53E16249.8080906@matthew.at> (Matthew Kaufman's message of "Tue, 05 Aug 2014 16:01:29 -0700") References: <28415725.7877.1407274460265.JavaMail.root@benjamin.baylink.com> <53E16249.8080906@matthew.at> Message-ID: <86mwbijw9l.fsf@valhalla.seastrom.com> Matthew Kaufman writes: > In the meantime, I'd like to see the city where an ISP can buy as many > of the microducts as they want. I'd like to buy them all, > please... though I have no intention of running anything though them, > as I'm an investor in the local cable TV company. The fire ants have beaten you to it and they don't take kindly to people running fiber through their living room. (SFW but kind of disgusting): http://www.rainbowtech.net/products/docs/c51ce4107047eb1b2dc/Ants%20in%20OSP%20Equipment.pdf.pdf -r From nanog at jima.us Wed Aug 6 01:31:47 2014 From: nanog at jima.us (Jima) Date: Tue, 05 Aug 2014 19:31:47 -0600 Subject: Muni Fiber and Politics In-Reply-To: <04940BA3-3D47-425C-BB88-B304DC991159@ufp.org> References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> <8C91DE6E-B56D-47E1-B826-10B2D024D87F@delong.com> <04940BA3-3D47-425C-BB88-B304DC991159@ufp.org> Message-ID: <53E18583.6030500@jima.us> On 2014-08-02 15:15, Leo Bicknell wrote: > But if those cities were to build a municipal fiber network like we've described, and pay > for it with 15-20 year municipal bonds the ISP's wouldn't have to bear those costs. They > could come in drop one box in a central location and start offering service. I've mentioned it before, but UTOPIA in the Salt Lake City area is set up mostly like this -- it's a multi-city entity that built out the fiber L1/L2 using member cities' bond money, and allows ISPs to provide L3 service over it. Most of the ISPs offered 50/50 or 100/100 service, until UTOPIA upgraded their infrastructure to the point where gigabit/gigabit was viable (7/8 now offer gigabit). As a customer for two years now, I can attest that the service is excellent, far more reliable than providers on other media, and priced at or below the closest alternative offering (which isn't all that comparable to begin with). Unfortunately, between aggressive lobbying by the incumbent carriers to prevent other cities from joining up (and thus providing greater economies of scale), mismanagement, political disfavor, and budgetary issues, it's left with an uncertain future. There's presently an offer on the table for an Australian investment firm to step in, finish the buildout, and manage the network for 30 years to recoup their costs, but it's seemed to have made the entire project even more politically toxic, decreasing the likelihood of further funding/deployment. I attended my city's town hall meeting regarding the deal; it was genuinely hard to tell whether some of the concerned citizens were corporate shills, or victims of Stockholm Syndrome at the hands of the duopoly incumbents (which we were repeatedly told provide "good enough" service). At least one complained that the city was wasting money on the existing bond payments (optional, surely) instead of fixing the street in front of their house, a complaint I've been told was also made in other cities' meetings. There were more people speaking up with repeated, unsubstantiated rumors or willful misinformation than there were people who actually understood the ramifications of open, non-monopoly internet infrastructure. (To be fair, there were also well-reasoned persons opposing the project, but they were about as plentiful as the supporters.) So, in theory, the model is great. In practice, it's too soon to tell -- but only due to layer 8+ problems. Jima From contact at winterei.se Wed Aug 6 11:54:24 2014 From: contact at winterei.se (Paul S.) Date: Wed, 06 Aug 2014 20:54:24 +0900 Subject: [j-nsp] Viability of EX4300 in a primarily l3 environment? In-Reply-To: References: <53DC575B.2010202@winterei.se> <20140806101552.GC5577@danton.fire-world.de> Message-ID: <53E21770.9040205@winterei.se> Correct me if I'm wrong, but doesn't OSPF require the AFL license anyway to be 'legitly' ran? Price difference might be a lot smaller depending on that. On 8/6/2014 ?? 08:30, Yucong Sun wrote: > I used ex4200 to do exactly what you did before. ex4200 releases is pretty > rock solid, feature extensive, although with lower arp entry limits. > > Given the price difference maybe you can connect each l2 domain to its own > ex4200 and have them do ospf routing among selves, which maybe give you > better failure tolerances compare to a single core. > > > On Wed, Aug 6, 2014 at 6:35 PM, Giuliano Cardozo Medalha < > giuliano at wztech.com.br> wrote: > >> we are using ex4300 with the last release available >> >> the setup is pretty simple using virtual chassis, lag, L3 and poe >> >> it works pretty fine and we do not have any serious problems >> >> sometimes the poe controller goes down but we have a case oppened in jtac >> to try solve it >> >> Sent from my iPhone >> >>> On 06/08/2014, at 07:15, Sebastian Wiesinger >> wrote: >>> * Paul S. [2014-08-02 05:18]: >>>> Hi folks, >>>> >>>> We're considering the EX4300 to run routing (l3) for a few >>>> hypervisors of ours that are connected via l2. >>>> >>>> Primarily interested due to the rather massive arp limit (64, 000) >>>> on the switch, but we've been told (and searched for ourselves to >>>> find out) that the 4300 platform has been plagued by random issues >>>> since launch. >>> I don't have hands-on experience but I looked at the EX4300 platform >>> for a new deployment. If you look at the current release notes: >>> >>> >> http://www.juniper.net/techpubs/en_US/junos13.2/information-products/topic-collections/ex-qfx-series/release-notes/ex-qfx-series-junos-release-notes-13.2X51-D25.pdf >>> There are a lot of (serious) bugs still getting fixed so I'm not sure >>> how mature this platform is. One big reason for that is probably >>> because EX4300 uses other chips than the rest of the 4xxx series >>> (Broadcom). >>> >>> Regards >>> >>> Sebastian >>> >>> -- >>> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) >>> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE >> SCYTHE. >>> -- Terry Pratchett, The Fifth Elephant >>> _______________________________________________ >>> juniper-nsp mailing list juniper-nsp at puck.nether.net >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >> _______________________________________________ >> juniper-nsp mailing list juniper-nsp at puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > _______________________________________________ > juniper-nsp mailing list juniper-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp From sunyucong at gmail.com Wed Aug 6 12:01:03 2014 From: sunyucong at gmail.com (Yucong Sun) Date: Wed, 6 Aug 2014 20:01:03 +0800 Subject: [j-nsp] Viability of EX4300 in a primarily l3 environment? In-Reply-To: <53E21770.9040205@winterei.se> References: <53DC575B.2010202@winterei.se> <20140806101552.GC5577@danton.fire-world.de> <53E21770.9040205@winterei.se> Message-ID: it appears not, ospf + ipv4 was not mentioned here: http://www.juniper.net/techpubs/en_US/junos11.4/topics/concept/ex-series-software-licenses-overview.html#jd0e135 On Wed, Aug 6, 2014 at 7:54 PM, Paul S. wrote: > Correct me if I'm wrong, but doesn't OSPF require the AFL license anyway > to be 'legitly' ran? > > Price difference might be a lot smaller depending on that. > > > On 8/6/2014 ?? 08:30, Yucong Sun wrote: > >> I used ex4200 to do exactly what you did before. ex4200 releases is >> pretty >> rock solid, feature extensive, although with lower arp entry limits. >> >> Given the price difference maybe you can connect each l2 domain to its own >> ex4200 and have them do ospf routing among selves, which maybe give you >> better failure tolerances compare to a single core. >> >> >> On Wed, Aug 6, 2014 at 6:35 PM, Giuliano Cardozo Medalha < >> giuliano at wztech.com.br> wrote: >> >> we are using ex4300 with the last release available >>> >>> the setup is pretty simple using virtual chassis, lag, L3 and poe >>> >>> it works pretty fine and we do not have any serious problems >>> >>> sometimes the poe controller goes down but we have a case oppened in jtac >>> to try solve it >>> >>> Sent from my iPhone >>> >>> On 06/08/2014, at 07:15, Sebastian Wiesinger < >>>> juniper-nsp at ml.karotte.org> >>>> >>> wrote: >>> >>>> * Paul S. [2014-08-02 05:18]: >>>> >>>>> Hi folks, >>>>> >>>>> We're considering the EX4300 to run routing (l3) for a few >>>>> hypervisors of ours that are connected via l2. >>>>> >>>>> Primarily interested due to the rather massive arp limit (64, 000) >>>>> on the switch, but we've been told (and searched for ourselves to >>>>> find out) that the 4300 platform has been plagued by random issues >>>>> since launch. >>>>> >>>> I don't have hands-on experience but I looked at the EX4300 platform >>>> for a new deployment. If you look at the current release notes: >>>> >>>> >>>> http://www.juniper.net/techpubs/en_US/junos13.2/ >>> information-products/topic-collections/ex-qfx-series/ >>> release-notes/ex-qfx-series-junos-release-notes-13.2X51-D25.pdf >>> >>>> There are a lot of (serious) bugs still getting fixed so I'm not sure >>>> how mature this platform is. One big reason for that is probably >>>> because EX4300 uses other chips than the rest of the 4xxx series >>>> (Broadcom). >>>> >>>> Regards >>>> >>>> Sebastian >>>> >>>> -- >>>> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) >>>> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE >>>> >>> SCYTHE. >>> >>>> -- Terry Pratchett, The Fifth Elephant >>>> _______________________________________________ >>>> juniper-nsp mailing list juniper-nsp at puck.nether.net >>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>> >>> _______________________________________________ >>> juniper-nsp mailing list juniper-nsp at puck.nether.net >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>> >>> _______________________________________________ >> juniper-nsp mailing list juniper-nsp at puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > > From bernat at luffy.cx Wed Aug 6 12:13:45 2014 From: bernat at luffy.cx (Vincent Bernat) Date: Wed, 06 Aug 2014 14:13:45 +0200 Subject: [j-nsp] Viability of EX4300 in a primarily l3 environment? In-Reply-To: <53E21770.9040205@winterei.se> (Paul S.'s message of "Wed, 06 Aug 2014 20:54:24 +0900") References: <53DC575B.2010202@winterei.se> <20140806101552.GC5577@danton.fire-world.de> <53E21770.9040205@winterei.se> Message-ID: ? 6 ao?t 2014 20:54 +0900, "Paul S." ?: > Correct me if I'm wrong, but doesn't OSPF require the AFL license > anyway to be 'legitly' ran? OSPF does not need a feature license on those models (it is needed on EX2200). AFL is needed for BGP, IS-IS and MPLS. -- Use statement labels that mean something. - The Elements of Programming Style (Kernighan & Plauger) From contact at winterei.se Wed Aug 6 12:15:01 2014 From: contact at winterei.se (Paul S.) Date: Wed, 06 Aug 2014 21:15:01 +0900 Subject: [j-nsp] Viability of EX4300 in a primarily l3 environment? In-Reply-To: References: <53DC575B.2010202@winterei.se> <20140806101552.GC5577@danton.fire-world.de> <53E21770.9040205@winterei.se> Message-ID: <53E21C45.90109@winterei.se> On 8/6/2014 ?? 09:13, Vincent Bernat wrote: > ? 6 ao?t 2014 20:54 +0900, "Paul S." : > >> Correct me if I'm wrong, but doesn't OSPF require the AFL license >> anyway to be 'legitly' ran? > OSPF does not need a feature license on those models (it is needed on > EX2200). AFL is needed for BGP, IS-IS and MPLS. 3300 too, apparently -- thanks for the correction. From bicknell at ufp.org Wed Aug 6 15:23:55 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 6 Aug 2014 10:23:55 -0500 Subject: Muni Fiber and Politics In-Reply-To: References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> Message-ID: On Aug 4, 2014, at 11:13 AM, William Herrin wrote: > 1. Enthusiasm (hence funding) for public works projects waxes and > wanes. Generally it waxes long enough to get some portion of the > original works project built, then it wanes until the project is in > major disrepair, then it waxes again long enough to more or less fix > it up. Others have hit on the major points, but just to summarize. The big one is the provider is going to charge an O&M fee for the services, be it the dark fiber or a L2 lit service. Fiber cuts will happen, connectors will be broken, and gear will die. One would hope this continuous funding source could even out some of the municipal funding hurdles, if done ideally the network would be built in tax dollars, but then be fully self-sustaining moving forward. The second one is, if you require both L1 dark fiber, and allow L2 lit services, this problem "self solves". If the L2 is capped at a 1G, and the world has moved to 10G, the people who need it will just move to the L1/dark offering and away from the L2 offering. That is, they have an option, and that's what this is all about, options. Unlike telecoms that might choose not to sell the dark fiber to force you into a lit service, such a muni-network should be required to sell the dark to all providers all the time. By drawing an (admittedly somewhat arbitrary) boundary between L1/L2 and L3-L7, I think a situation can be created where there is maximum flexibility on both sides of that boundary, and the least chance of "stupidity" from players on either side. -- 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: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From psirt at cisco.com Wed Aug 6 16:06:42 2014 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 6 Aug 2014 12:06:42 -0400 Subject: Cisco Security Advisory: Cisco IOS Software and Cisco IOS XE Software EnergyWise Crafted Packet Denial of Service Vulnerability Message-ID: <201408061206.17.energywise@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco IOS Software and Cisco IOS XE Software EnergyWise Crafted Packet Denial of Service Vulnerability Advisory ID: cisco-sa-20140806-energywise Revision 1.0 For Public Release 2014 August 6 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= A vulnerability in the EnergyWise module of Cisco IOS and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause a reload of the affected device. The vulnerability is due to improper parsing of crafted EnergyWise packets destined to an affected device. An attacker could exploit this vulnerability by sending a crafted EnergyWise packet to be processed by an affected device. An exploit could allow the attacker to cause a reload of the affected device. Cisco has released free software updates that address this vulnerability. There are no workarounds for this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140806-energywise -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJT4ivWAAoJEIpI1I6i1Mx30KoP/iN0KYzG01VMF0fbwLcZjIg+ JQn8lY0mTsetm98hLMCRBKB0STTwLZnbDUcfP0HDfncUJKL4Z2/ACIOE/+D4qDmh Mq6EoUwVIP3+w2fdjk2QNbuixbDAfc2RK4c8kT8B/9M2Za+B2+Joz8PjliNzio9j +zCizkbG78k+iPXQUNMeP57Roj8iayh33r2EF5daFp7okhmOkyTcTH2OMHh9FLaz bj7VGP6/ppysmA9zekZE4IeYMVQfCFr6Sb7VbS80jDB8XhjYEmiEtNboumqrdXkG 4syzvYRtNV9JDeRe9sGzBoJYx47EBH89uF8Y9UlPdk0U5iOvFkCc2O/tZsR6GHvt yjHreBvDuZoE/wIksPaAo/BZVudqyH5qz4Hy6Cz3w+XJC4E0Po/IzdKJEIeqt1+b tsgBvKONGUClaDmb501h+V4NKb2JBYapMSl/ohtxDLO43wqGJiY/yNZ5QnJwTjwh mJMTxBofeZTS2sCf9jGWwayNrEO3xAmngzkWy1eTybAB6QiU3VeS3spSsoGnEu5E 3MmfJz8BX6i6XFeQj9tjw5oLs0NXTx1+B85zI7tPzL1D9g4wdUiawZHuBnsg13ME jk9+F8USc2/xGHQ3GJ9OU9Gm0IoFinFyRI1BuzqPZ42XaEJaRnMbWP7jmaksEJew M9tnNIY0SSE5m3JGXZq8 =Hax4 -----END PGP SIGNATURE----- From owen at delong.com Wed Aug 6 16:39:09 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 6 Aug 2014 09:39:09 -0700 Subject: Muni Fiber and Politics In-Reply-To: References: <25588782.7821.1407194114728.JavaMail.root@benjamin.baylink.com> <885C4E30-8FB9-43EE-A602-836FA7B7C347@delong.com> Message-ID: <92158533-D4C0-4A98-8D22-8F95D14B1EF6@delong.com> > On Aug 5, 2014, at 10:56, Eugeniu Patrascu wrote: > >> On Tue, Aug 5, 2014 at 8:26 PM, Owen DeLong wrote: >> >> >> >> >> This one is a bad idea cause you have lots of people pushing fiber through >> >> pipes with active fiber in them... and their incentives not to screw up >> >> other people's glass are... unclear? :-) >> > >> > Not really, if one company starts making mistakes, the other will also >> > mistake their cables. It's like a working mexican standoff :) >> > >> > >> >> In reality, Mexican standoffs are often fatal. > > If you blink. > >> >> Oh, wait: the conduit installer isn't a contractor, they're a monopoly? >> > The people pushing fiber through the conduits are contractors. There are a >> > handful of companies licensed to operate this. >> >> May be workable, but seems more expensive than operating cross connects in a serving wire center with little or no plausible benefit. > > So how is blowing microfibre in some tubes more expensive? You pay a one off installation fee and then a small monthly rate for the circuit (payable yearly). And then when you switch providers, you pay all of that again instead of a quick move of a cross connect inside a building. > > The really nice and geeky part is that you can actually choose how your fiber will run, so if you want diverse paths to a location you can achieve that with certainty. Not particularly important to 99.999+% of residential users. > >> > >> > >> >> No, that's even worse. >> > >> > >> > It's not perfect, but it works. >> >> People say that about windows. I don't use it, either. > > :) It works because it's very cheap to get high speed internet into all kinds of areas, especially residential ones. So is what I am proposing. In fact, I'm pretty sure my proposal is cheaper, especially in the long run. From josmon at rigozsaurus.com Wed Aug 6 17:08:10 2014 From: josmon at rigozsaurus.com (John Osmon) Date: Wed, 6 Aug 2014 11:08:10 -0600 Subject: Muni Fiber and Politics In-Reply-To: References: <19855201.6612.1405951988177.JavaMail.root@benjamin.baylink.com> <201408010740.50741.mark.tinka@seacom.mu> <201408010908.07452.mark.tinka@seacom.mu> <3C91526C-BB7D-4E3D-B960-0D434F1FADEE@delong.com> Message-ID: <20140806170810.GA20354@jeeves.rigozsaurus.com> On Wed, Aug 06, 2014 at 10:23:55AM -0500, Leo Bicknell wrote: [...] > By drawing an (admittedly somewhat arbitrary) boundary between L1/L2 and L3-L7, > I think a situation can be created where there is maximum flexibility on both > sides of that boundary, and the least chance of "stupidity" from players on > either side. I know of areas where multiple ISPs would welcome lit layer 2 services, because of unfamiliarity with provisioning such. So a mixed L1/L2 service where providers can "grow into" things could be very attractive in creating competition. From matthew at matthew.at Wed Aug 6 17:42:43 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 06 Aug 2014 10:42:43 -0700 Subject: Muni Fiber and Politics In-Reply-To: <92158533-D4C0-4A98-8D22-8F95D14B1EF6@delong.com> References: <25588782.7821.1407194114728.JavaMail.root@benjamin.baylink.com> <885C4E30-8FB9-43EE-A602-836FA7B7C347@delong.com> <92158533-D4C0-4A98-8D22-8F95D14B1EF6@delong.com> Message-ID: <53E26913.9040201@matthew.at> On 8/6/2014 9:39 AM, Owen DeLong wrote: > > So is what I am proposing. In fact, I'm pretty sure my proposal is cheaper, especially in the long run. > > So build one already! Matthew Kaufman From jra at baylink.com Thu Aug 7 03:26:11 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 06 Aug 2014 23:26:11 -0400 Subject: Anyone running Knot? Message-ID: LWN this week covers the Knot DNS server, written by/for the .cz root zone ops, which can, amongst other interesting attributes, load the entire 35 million record .net zone in 10 seconds. It also does generated synthetic A, 4A, and PTR records, like the old DENTS server written for mindspring. Is anybody here using it? Or knows of it being used somewhere they're permitted to discuss? Is it suitable for running on... much smaller zones? or does the optimization make it impractical? Cheers, -jra -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From dot at dotat.at Thu Aug 7 11:00:46 2014 From: dot at dotat.at (Tony Finch) Date: Thu, 7 Aug 2014 12:00:46 +0100 Subject: Anyone running Knot? In-Reply-To: References: Message-ID: RIPE have an interesting setup. They are load-balancing their name servers across BIND, NSD, and Knot. $ for i in `seq 10`; do dig +norec +noall +answer version.bind ch txt @ns.ripe.net.; done | sort -u version.bind. 0 CH TXT "9.9.5" version.bind. 0 CH TXT "Knot DNS 1.5.0" version.bind. 0 CH TXT "NSD 4.0.4" Tony. -- f.anthony.n.finch http://dotat.at/ South-east Iceland: Easterly or northeasterly 5 to 7, occasionally gale 8 in northwest, veering southeasterly 4 in south. Slight or moderate, occasionally rough in northwest. Rain or showers. Moderate or poor, occasionally good. From jabley at hopcount.ca Thu Aug 7 13:57:49 2014 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 7 Aug 2014 09:57:49 -0400 Subject: Anyone running Knot? In-Reply-To: References: Message-ID: Hi Jay, On 6 August 2014 at 23:26:36, Jay Ashworth (jra at baylink.com) wrote: > LWN this week covers the Knot DNS server, written by/for the .cz root zone ops, which can, > amongst other interesting attributes, load the entire 35 million record .net zone in > 10 seconds. https://www.knot-dns.cz Knot was written by people at CZ.NIC Labs, as far as I know. When I was at ICANN we were interested in using it for L-Root, but I don't know that that has happened. The team is really, really good. I routinely suffer jawcraig [1] at their apparently outrageous productivity. > Is anybody here using it? Or knows of it being used somewhere they're permitted to discuss? > Is it suitable for running on... much smaller zones? or does the optimization make it > impractical? There's a mailing list: ???knot-dns-users at lists.nic.cz Joe [1]?http://tmoliff.blogspot.co.nz/2011/04/jawcraig-n-medical.html From owen at delong.com Thu Aug 7 14:35:28 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Aug 2014 07:35:28 -0700 Subject: Remooted: a deployment design for Muni Fiber (was Re: Muni Fiber and Politics) In-Reply-To: <53E16249.8080906@matthew.at> References: <28415725.7877.1407274460265.JavaMail.root@benjamin.baylink.com> <53E16249.8080906@matthew.at> Message-ID: <2F3523FB-90D5-4470-8729-41BFA62C52D5@delong.com> On Aug 5, 2014, at 4:01 PM, Matthew Kaufman wrote: > Is there any way we could stop this discussion until we can get some participants who have experience doing things like emergency post-ice-storm overhead circuit restoration to show up and explain exactly why charging a small one-time fee for a fiber from A to Z is probably not a sustainable model? I completely agree that XC without MRC is an unsustainable model, but I believe only one person proposed that, so I don?t think calling for an end to the discussion just because you realize what everyone but one person does is warranted. > In the meantime, I'd like to see the city where an ISP can buy as many of the microducts as they want. I'd like to buy them all, please... though I have no intention of running anything though them, as I'm an investor in the local cable TV company. Which seems to support my argument for direct fiber PREM<->Serving Wire Center. Owen From shawnl at up.net Thu Aug 7 16:43:36 2014 From: shawnl at up.net (Shawn L) Date: Thu, 7 Aug 2014 12:43:36 -0400 Subject: Cisco Switch Matrix Message-ID: Has anyone seen a good matrix of Cisco switches and their port-types, etc? I'm looking for something where I can say 'I need a switch with X 10-gig ports and Y 1-gig sfp ports, which models meet that criteria?' I know I can look through all of the data sheets at cisco's website, but there has to be a better way to see the specs of a large array of switches at a glance. thanks From corbe at corbe.net Thu Aug 7 17:00:45 2014 From: corbe at corbe.net (Daniel Corbe) Date: Thu, 07 Aug 2014 13:00:45 -0400 Subject: Cisco Switch Matrix In-Reply-To: (Shawn L.'s message of "Thu, 7 Aug 2014 12:43:36 -0400") References: Message-ID: I can't think of anything like this off the top of my head but here's what I would do if I were in a pinch and trying to put configurations together: Find someone who sells (or resells) Cisco gear professionally. They'll help you identify equipment which is appropriate for your build. -Daniel Shawn L writes: > Has anyone seen a good matrix of Cisco switches and their port-types, etc? > I'm looking for something where I can say 'I need a switch with X 10-gig > ports and Y 1-gig sfp ports, which models meet that criteria?' > > I know I can look through all of the data sheets at cisco's website, but > there has to be a better way to see the specs of a large array of switches > at a glance. > > thanks From woody at pch.net Thu Aug 7 17:03:51 2014 From: woody at pch.net (Bill Woodcock) Date: Thu, 7 Aug 2014 13:03:51 -0400 Subject: Cisco Switch Matrix In-Reply-To: References: Message-ID: We maintain one in spreadsheet form ONLY FOR FIXED CONFIGURATION SWITCHES with price, performance, and ports, which we're happy to share. I can provide it by email or post it to our wiki, depending how many people want it. -Bill > On Aug 7, 2014, at 12:44, "Shawn L" wrote: > > Has anyone seen a good matrix of Cisco switches and their port-types, etc? > I'm looking for something where I can say 'I need a switch with X 10-gig > ports and Y 1-gig sfp ports, which models meet that criteria?' > > I know I can look through all of the data sheets at cisco's website, but > there has to be a better way to see the specs of a large array of switches > at a glance. > > thanks From chris at aperturefiber.com Thu Aug 7 19:59:52 2014 From: chris at aperturefiber.com (Chris Garrett) Date: Thu, 7 Aug 2014 14:59:52 -0500 Subject: AutoTask as a ticketing system in a MNS NOC Message-ID: Does anyone on list have any firsthand experience with this software as a primary ticketing platform in a high volume NOC? We are moving away from SolarWinds WebHelpDesk as our ticketing platform and this one came into the bidding late. http://www.autotask.com From cma at cmadams.net Thu Aug 7 20:08:45 2014 From: cma at cmadams.net (Chris Adams) Date: Thu, 7 Aug 2014 15:08:45 -0500 Subject: AutoTask as a ticketing system in a MNS NOC In-Reply-To: References: Message-ID: <20140807200845.GD18097@cmadams.net> Once upon a time, Chris Garrett said: > Does anyone on list have any firsthand experience with this software as a primary ticketing platform in a high volume NOC? A small ISP I used to work for switched to Autotask a couple of years ago, and I was not impressed. The web UI was slow, the API was slower, and their standard mail gateway was broken. For example: they used AT for CRM as well, and the mail gateway tried to auto-associate tickets with contacts based on email address. That would be great, but we had some people that were contacts for multiple customers (using the same email address), and emails from them to the ticket system would just go into a black hole (no ticket, no bounce, no notification). There are various third-party tools available to handle the email gateway as well; I don't know how well they may work, but it seemed to me that a ticket system that needed third-party tools to handle email was broken. -- Chris Adams From apishdadi at gmail.com Thu Aug 7 20:49:29 2014 From: apishdadi at gmail.com (Ameen Pishdadi) Date: Thu, 7 Aug 2014 15:49:29 -0500 Subject: AutoTask as a ticketing system in a MNS NOC In-Reply-To: <20140807200845.GD18097@cmadams.net> References: <20140807200845.GD18097@cmadams.net> Message-ID: <81B41B8E-2E7C-4E73-83C2-06D04479A7E3@gmail.com> Well what do u recommend Sent from my iPhone > On Aug 7, 2014, at 3:08 PM, Chris Adams wrote: > > Once upon a time, Chris Garrett said: >> Does anyone on list have any firsthand experience with this software as a primary ticketing platform in a high volume NOC? > > A small ISP I used to work for switched to Autotask a couple of years > ago, and I was not impressed. The web UI was slow, the API was slower, > and their standard mail gateway was broken. > > For example: they used AT for CRM as well, and the mail gateway tried to > auto-associate tickets with contacts based on email address. That would > be great, but we had some people that were contacts for multiple > customers (using the same email address), and emails from them to the > ticket system would just go into a black hole (no ticket, no bounce, no > notification). > > There are various third-party tools available to handle the email > gateway as well; I don't know how well they may work, but it seemed to > me that a ticket system that needed third-party tools to handle email > was broken. > > -- > Chris Adams From chris at aperturefiber.com Thu Aug 7 20:54:01 2014 From: chris at aperturefiber.com (Chris Garrett) Date: Thu, 7 Aug 2014 15:54:01 -0500 Subject: AutoTask as a ticketing system in a MNS NOC In-Reply-To: <20140807200845.GD18097@cmadams.net> References: <20140807200845.GD18097@cmadams.net> Message-ID: This is the same limitation on contacts that is forcing us away from WHD I appreciate your prompt response. On Aug 7, 2014, at 3:08 PM, Chris Adams wrote: > Once upon a time, Chris Garrett said: >> Does anyone on list have any firsthand experience with this software as a primary ticketing platform in a high volume NOC? > > A small ISP I used to work for switched to Autotask a couple of years > ago, and I was not impressed. The web UI was slow, the API was slower, > and their standard mail gateway was broken. > > For example: they used AT for CRM as well, and the mail gateway tried to > auto-associate tickets with contacts based on email address. That would > be great, but we had some people that were contacts for multiple > customers (using the same email address), and emails from them to the > ticket system would just go into a black hole (no ticket, no bounce, no > notification). > > There are various third-party tools available to handle the email > gateway as well; I don't know how well they may work, but it seemed to > me that a ticket system that needed third-party tools to handle email > was broken. > > -- > Chris Adams > From johny at griffintechnology.com Thu Aug 7 20:58:43 2014 From: johny at griffintechnology.com (John York) Date: Thu, 7 Aug 2014 15:58:43 -0500 Subject: IPv6 route annoucement Message-ID: Hoping to not start a war... We (a multi-homed end-user site) are finally getting IPv6-enabled Internet connectivity from one of our ISPs. In conversations regarding our BGP config, the ISP has balked at allowing us to advertise our ARIN-assigned /44, saying things like, "do you know how many addresses that is!!??" Am I way off base in thinking this network size is not out of the norm? I know it's a lot of addresses (19 octillion-something?), but that assignment was based on the same criteria that got us a /22 in v4 space. Should accepting a /44 in v6 not be equivalent, policy-wise, to accepting a /22 in v4? Thanks, John -- John York Information Technology | Network Administrator Phone: 615-399-7000 x:333 Griffin Technology 2030 Lindell Avenue Nashville, TN 37203 USA From stu at actusa.net Thu Aug 7 21:05:50 2014 From: stu at actusa.net (Stuart Sheldon) Date: Thu, 07 Aug 2014 14:05:50 -0700 Subject: IPv6 route annoucement In-Reply-To: References: Message-ID: <53E3EA2E.2010406@actusa.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 No, it's not mis-sized. And no, you should advertise it all. I would advertise the /44 without reservation. Stuart Sheldon ACT USA AS22937 On 08/07/2014 01:58 PM, John York wrote: > Hoping to not start a war... > > We (a multi-homed end-user site) are finally getting IPv6-enabled Internet > connectivity from one of our ISPs. In conversations regarding our BGP > config, the ISP has balked at allowing us to advertise our ARIN-assigned > /44, saying things like, "do you know how many addresses that is!!??" > > Am I way off base in thinking this network size is not out of the norm? I > know it's a lot of addresses (19 octillion-something?), but that > assignment was based on the same criteria that got us a /22 in v4 space. > Should accepting a /44 in v6 not be equivalent, policy-wise, to accepting > a /22 in v4? > > Thanks, > John > > -- > John York > Information Technology | Network Administrator > > Phone: > 615-399-7000 x:333 > > Griffin Technology > 2030 Lindell Avenue Nashville, TN 37203 USA > - -- My pockets are empty though my wife has sent me to the store for some cigarettes and bread... I started walkin there, got as far as the square, then the smell of beer went to my head... The thing about beer, it can make a man hear, voices from days long since past, and with every third drink, it will make you think that your youth will always last... -- BR549 - "Lifetime to Prove Lyrics" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJT4+ouAAoJEFKVLITDJSGSw/oP/i8+UbGLHCDnW/2mlmX0ZnQt DIMNGM4gF+cB4monShUj6bKwUmtfFgtSLIwwZ9PEnStP1g+JTxhUjUFX3EEgLeli JfkdqBAluN/9BouBX0duEJLoxFQSimH/oGCvRETLJUBmojKjhWaTrJmIj4PDjSzb pwU8ZMfPaxzgz5ll3JYySyJ6TkAXNflhDpZcd7vrS3UhYDJIEwNh1JXJOXLd7929 LrS2yel7goaAxrmYzba6qg8q7TXxC/VaIMIsGPbwH+NbOY9vfbki6uMdky/iajw8 IvHz89id1Bae6CgXd+I/v9s+iUuvcP5HhycMaLKWGLcUoABbGRFnadN8E4nHGCvT WX9ZDxhWlRbW0sFkgxcIdAxNGBbxJjZxpaZr6zY0G6pb8ZIibPERdii1qjJOq4Zw Enh4YyMIoumZ+H70yhPPZgUcHpoaNJoSWZ6DvQrcxMuduq1IjfBwlbNyvZRl8vM5 x3/dmrYrl9TdnEPyZdPttn2RH6lsUk1NpyhdndKr1VX9tZD1oWtujAy8rBd5qB6L vn+pOC0SkauwPTqatkq8J2PxqYIKWHNkgEjQ5FZbPK9VDyuUIcM3DXpFtYELODKq m1HwY5pg7yxmcq4EDHsUO42b23u45V5JCdJldio+d8oeG00RQZulgijj0q1Rx29c gk7Se5U8guz0JbUbcn0W =rcZu -----END PGP SIGNATURE----- From corey.touchet at corp.totalserversolutions.com Thu Aug 7 21:18:52 2014 From: corey.touchet at corp.totalserversolutions.com (Corey Touchet) Date: Thu, 7 Aug 2014 21:18:52 +0000 Subject: AutoTask as a ticketing system in a MNS NOC In-Reply-To: <81B41B8E-2E7C-4E73-83C2-06D04479A7E3@gmail.com> Message-ID: It?s not taboo to say Remedy is it? On 8/7/14, 2:49 PM, "Ameen Pishdadi" wrote: >Well what do u recommend > >Sent from my iPhone > >> On Aug 7, 2014, at 3:08 PM, Chris Adams wrote: >> >> Once upon a time, Chris Garrett said: >>> Does anyone on list have any firsthand experience with this software >>>as a primary ticketing platform in a high volume NOC? >> >> A small ISP I used to work for switched to Autotask a couple of years >> ago, and I was not impressed. The web UI was slow, the API was slower, >> and their standard mail gateway was broken. >> >> For example: they used AT for CRM as well, and the mail gateway tried to >> auto-associate tickets with contacts based on email address. That would >> be great, but we had some people that were contacts for multiple >> customers (using the same email address), and emails from them to the >> ticket system would just go into a black hole (no ticket, no bounce, no >> notification). >> >> There are various third-party tools available to handle the email >> gateway as well; I don't know how well they may work, but it seemed to >> me that a ticket system that needed third-party tools to handle email >> was broken. >> >> -- >> Chris Adams From corey.touchet at corp.totalserversolutions.com Thu Aug 7 21:22:49 2014 From: corey.touchet at corp.totalserversolutions.com (Corey Touchet) Date: Thu, 7 Aug 2014 21:22:49 +0000 Subject: IPv6 route annoucement In-Reply-To: Message-ID: Pretty strong reaction for a single prefix. Now if you said you wanted to advertise all your /64?s that would be a different conversation. On 8/7/14, 2:58 PM, "John York" wrote: >Hoping to not start a war... > >We (a multi-homed end-user site) are finally getting IPv6-enabled Internet >connectivity from one of our ISPs. In conversations regarding our BGP >config, the ISP has balked at allowing us to advertise our ARIN-assigned >/44, saying things like, "do you know how many addresses that is!!??" > >Am I way off base in thinking this network size is not out of the norm? I >know it's a lot of addresses (19 octillion-something?), but that >assignment was based on the same criteria that got us a /22 in v4 space. >Should accepting a /44 in v6 not be equivalent, policy-wise, to accepting >a /22 in v4? > >Thanks, >John > >-- >John York >Information Technology | Network Administrator > >Phone: >615-399-7000 x:333 > >Griffin Technology >2030 Lindell Avenue Nashville, TN 37203 USA From streiner at cluebyfour.org Thu Aug 7 18:55:49 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 7 Aug 2014 14:55:49 -0400 (EDT) Subject: IPv6 route annoucement In-Reply-To: References: Message-ID: On Thu, 7 Aug 2014, John York wrote: > Hoping to not start a war... > > We (a multi-homed end-user site) are finally getting IPv6-enabled Internet > connectivity from one of our ISPs. In conversations regarding our BGP > config, the ISP has balked at allowing us to advertise our ARIN-assigned > /44, saying things like, "do you know how many addresses that is!!??" Sounds like the ISP in question is in need of some serious IPv6 clue. The number of hosts means nothing, in terms of BGP advertisements. In fact, fewer announcements is better. De-aggregation bloats the global routing table. Most carriers I've seen will accept IPv6 announcements as small as a /48. If your /44 was assigned by your RIR, and it's documented in their whois/rwhois/route registry, your ISP really doesn't have a leg to stand on, regarding not accepting your announcement. > Am I way off base in thinking this network size is not out of the norm? I > know it's a lot of addresses (19 octillion-something?), but that > assignment was based on the same criteria that got us a /22 in v4 space. > Should accepting a /44 in v6 not be equivalent, policy-wise, to accepting > a /22 in v4? The largest IPv6 prefix I saw in the global Internet routing table the last time I looked (a few months ago) that wasn't for a special purpose was a /19.... ~33 million times larger than a /44. Your ISP should have more constructive things to do than hassling a customer about announcing a /44. jms From chris at aperturefiber.com Thu Aug 7 21:33:42 2014 From: chris at aperturefiber.com (Chris Garrett) Date: Thu, 7 Aug 2014 16:33:42 -0500 Subject: AutoTask as a ticketing system in a MNS NOC In-Reply-To: References: Message-ID: Remedy can be awesome, if you have full time development staff to dedicate to it. On Aug 7, 2014, at 4:18 PM, Corey Touchet wrote: > It?s not taboo to say Remedy is it? > > > > > > On 8/7/14, 2:49 PM, "Ameen Pishdadi" wrote: > >> Well what do u recommend >> >> Sent from my iPhone >> >>> On Aug 7, 2014, at 3:08 PM, Chris Adams wrote: >>> >>> Once upon a time, Chris Garrett said: >>>> Does anyone on list have any firsthand experience with this software >>>> as a primary ticketing platform in a high volume NOC? >>> >>> A small ISP I used to work for switched to Autotask a couple of years >>> ago, and I was not impressed. The web UI was slow, the API was slower, >>> and their standard mail gateway was broken. >>> >>> For example: they used AT for CRM as well, and the mail gateway tried to >>> auto-associate tickets with contacts based on email address. That would >>> be great, but we had some people that were contacts for multiple >>> customers (using the same email address), and emails from them to the >>> ticket system would just go into a black hole (no ticket, no bounce, no >>> notification). >>> >>> There are various third-party tools available to handle the email >>> gateway as well; I don't know how well they may work, but it seemed to >>> me that a ticket system that needed third-party tools to handle email >>> was broken. >>> >>> -- >>> Chris Adams > > From johny at griffintechnology.com Thu Aug 7 21:37:25 2014 From: johny at griffintechnology.com (John York) Date: Thu, 7 Aug 2014 16:37:25 -0500 Subject: IPv6 route annoucement In-Reply-To: References: Message-ID: <55a9a9611506788cb40bc1b25549028e@mail.gmail.com> Yeah, we're good in WHOIS, we're trying to announce only the aggregate, I think we have all our ducks in a row. Thanks to all who replied on- and off-list with your input. I'll go back to the ISP with the info from you guys and girls, and hopefully they'll listen to reason. John -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Justin M. Streiner Sent: Thursday, August 07, 2014 1:56 PM To: North American Network Operators' Group Subject: Re: IPv6 route annoucement On Thu, 7 Aug 2014, John York wrote: > Hoping to not start a war... > > We (a multi-homed end-user site) are finally getting IPv6-enabled Internet > connectivity from one of our ISPs. In conversations regarding our BGP > config, the ISP has balked at allowing us to advertise our ARIN-assigned > /44, saying things like, "do you know how many addresses that is!!??" Sounds like the ISP in question is in need of some serious IPv6 clue. The number of hosts means nothing, in terms of BGP advertisements. In fact, fewer announcements is better. De-aggregation bloats the global routing table. Most carriers I've seen will accept IPv6 announcements as small as a /48. If your /44 was assigned by your RIR, and it's documented in their whois/rwhois/route registry, your ISP really doesn't have a leg to stand on, regarding not accepting your announcement. > Am I way off base in thinking this network size is not out of the norm? I > know it's a lot of addresses (19 octillion-something?), but that > assignment was based on the same criteria that got us a /22 in v4 space. > Should accepting a /44 in v6 not be equivalent, policy-wise, to accepting > a /22 in v4? The largest IPv6 prefix I saw in the global Internet routing table the last time I looked (a few months ago) that wasn't for a special purpose was a /19.... ~33 million times larger than a /44. Your ISP should have more constructive things to do than hassling a customer about announcing a /44. jms From marka at isc.org Thu Aug 7 21:57:12 2014 From: marka at isc.org (Mark Andrews) Date: Fri, 08 Aug 2014 07:57:12 +1000 Subject: IPv6 route annoucement In-Reply-To: Your message of "Thu, 07 Aug 2014 15:58:43 -0500." References: Message-ID: <20140807215712.2812A1C75C87@rock.dv.isc.org> In message , John York writes: > Hoping to not start a war... > > We (a multi-homed end-user site) are finally getting IPv6-enabled Internet > connectivity from one of our ISPs. In conversations regarding our BGP > config, the ISP has balked at allowing us to advertise our ARIN-assigned > /44, saying things like, "do you know how many addresses that is!!??" Your ISP needs a IPv6 clue bat to be applied. Your ISP needs to learn that a /44 is 16 sites. It is also the next nibble boundry above a /48. The ISP shouldn't care about the number of addresses. You have justified your allocation based on the fact you are multi-homed and presumably the number of sites. The ISP appears to be wildly off base. > Am I way off base in thinking this network size is not out of the norm? I > know it's a lot of addresses (19 octillion-something?), but that > assignment was based on the same criteria that got us a /22 in v4 space. > Should accepting a /44 in v6 not be equivalent, policy-wise, to accepting > a /22 in v4? Address allocation in IPv6 is, or should be, number-of-sites based in IPv6 for end customers with a site gettting a /48. The exception is when a site needs more that 2^16 /64 subnets at a site which needs justification. For ISPs it is number-of-customer-sites (1 home == 1 site == 1 customer, commercial customers may have more than one site and need a bigger allocation) based with tuning for number-of-pops along with the customer allocation size (a /48 per customer site is reasonable though some ISPs do /56). IPv4 prefix size should have no bearing on the size of the IPv6 prefix for end customers. In IPv4 you count hosts. In IPv6 you count sites. This is as different as comparing apples and oranges. Just because you need a /22 in IPv4 doesn't mean you need a /44 in IPv6. You should be requesting address space based on the number of sites one has. Mark > Thanks, > John > > -- > John York > Information Technology | Network Administrator > > Phone: > 615-399-7000 x:333 > > Griffin Technology > 2030 Lindell Avenue Nashville, TN 37203 USA -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Thu Aug 7 22:26:26 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Aug 2014 15:26:26 -0700 Subject: IPv6 route annoucement In-Reply-To: References: Message-ID: It may also help to point out to them that under ARIN policy, if you need more than a single /48, you will get at least a /44. ARIN does not issue non-nibble-aligned blocks any more. You can get /12, /16, /20, /24, /28, /32, /36, /40, /44, /48, but you can't get a /45, /46, or /47. IMHO this is a good thing as it simplifies administration, DNS, and likely RPKI. It also reduces table bloat, and human factors related events. (At 3 am it turns out most people are bad at bit math). If your ISP would like, I am available to provide ipv6 training or consulting. Owen > On Aug 7, 2014, at 11:55, "Justin M. Streiner" wrote: > >> On Thu, 7 Aug 2014, John York wrote: >> >> Hoping to not start a war... >> >> We (a multi-homed end-user site) are finally getting IPv6-enabled Internet >> connectivity from one of our ISPs. In conversations regarding our BGP >> config, the ISP has balked at allowing us to advertise our ARIN-assigned >> /44, saying things like, "do you know how many addresses that is!!??" > > Sounds like the ISP in question is in need of some serious IPv6 clue. The number of hosts means nothing, in terms of BGP advertisements. In fact, fewer announcements is better. De-aggregation bloats the global routing table. > > Most carriers I've seen will accept IPv6 announcements as small as a /48. > > If your /44 was assigned by your RIR, and it's documented in their whois/rwhois/route registry, your ISP really doesn't have a leg to stand on, regarding not accepting your announcement. > >> Am I way off base in thinking this network size is not out of the norm? I >> know it's a lot of addresses (19 octillion-something?), but that >> assignment was based on the same criteria that got us a /22 in v4 space. >> Should accepting a /44 in v6 not be equivalent, policy-wise, to accepting >> a /22 in v4? > > The largest IPv6 prefix I saw in the global Internet routing table the last time I looked (a few months ago) that wasn't for a special purpose was a /19.... ~33 million times larger than a /44. > > Your ISP should have more constructive things to do than hassling a customer about announcing a /44. > > jms From kepler62e.lyra at gmail.com Wed Aug 6 23:10:35 2014 From: kepler62e.lyra at gmail.com (Prabhu Gurumurthy) Date: Wed, 6 Aug 2014 16:10:35 -0700 Subject: Verizon FiOS/Alter.net reachability issues Message-ID: Can somebody from Verizon FiOS/Alter.net contact me off-list, we are having issues with customers in FiOS going through Alter.net have bad latency. Thanks, Prabhu - From Steinar.Rimestad at altibox.no Thu Aug 7 22:04:32 2014 From: Steinar.Rimestad at altibox.no (Rimestad, Steinar) Date: Thu, 7 Aug 2014 22:04:32 +0000 Subject: Cisco Switch Matrix In-Reply-To: References: Message-ID: Hi. Have a look at the following pdf?s, I have been using these in the past. http://www.cisco.com/c/dam/en/us/solutions/collateral/wireless/aironet-1130 -ag-series/cisco_switching_family.pdf http://www.cisco.com/c/dam/en/us/products/collateral/switches/catalyst-3560 -series-switches/CatalystPoster_Final.pdf http://www.cisco.com/c/dam/en/us/products/collateral/switches/nexus-4000-se ries-switches/6701_catswitch_guide_v7_r5.pdf Regards, Steinar On 07/08/14 18:43, "Shawn L" wrote: >Has anyone seen a good matrix of Cisco switches and their port-types, etc? >I'm looking for something where I can say 'I need a switch with X 10-gig >ports and Y 1-gig sfp ports, which models meet that criteria?' > >I know I can look through all of the data sheets at cisco's website, but >there has to be a better way to see the specs of a large array of switches >at a glance. > >thanks > From fernando at gont.com.ar Fri Aug 8 04:12:30 2014 From: fernando at gont.com.ar (Fernando Gont) Date: Fri, 08 Aug 2014 00:12:30 -0400 Subject: Fwd: New IETF I-D: IPv6 Extension Headers in the Real World In-Reply-To: <53E44C55.9020306@si6networks.com> References: <53E44C55.9020306@si6networks.com> Message-ID: <53E44E2E.2010504@gont.com.ar> Folks, FYI: . Comments welcome. Thanks! Fernando -------- Forwarded Message -------- Subject: New I-D: IPv6 Extension Headers in the Real World Date: Fri, 08 Aug 2014 00:04:37 -0400 From: Fernando Gont To: IPv6 Operations Folks, We have published a new I-D on the topic of IPv6 Extension Headers (EHs). The I-D is available at: . Abstract: IPv6 Extension Headers allow for the extension of the IPv6 protocol, and provide support for some core functionality such as IPv6 fragmentation. However, IPv6 Extension Headers are deemed to present a challenge to IPv6 implementations and networks, and are known to be intentionally filtered in some existing IPv6 deployments. This summarizes the issues associated with IPv6 extension headers, and presents real-world data regarding the extent to which packets with IPv6 extension headers are filtered in the public Internet, and where in the network such filtering occurs. Additionally, it provides some guidance to operators in troubleshooting IPv6 blackholes resulting from the use of IPv6 extension headers. Finally, this document provides some advice to protocol designers, and discusses areas where further work might be needed. Comments and suggestions are welcome. Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt Date: Thu, 07 Aug 2014 20:57:17 -0700 From: internet-drafts at ietf.org To: J. Linkova , Shucheng LIU (Will) , Tim Chown , Tim Chown , Fernando Gont , Fernando Gont , Will (Shucheng) Liu , J. Linkova A new version of I-D, draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-ipv6-ehs-in-real-world Revision: 00 Title: IPv6 Extension Headers in the Real World Document date: 2014-08-07 Group: Individual Submission Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-in-real-world/ Htmlized: http://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-00 Abstract: IPv6 Extension Headers allow for the extension of the IPv6 protocol, and provide support for some core functionality such as IPv6 fragmentation. However, IPv6 Extension Headers are deemed to present a challenge to IPv6 implementations and networks, and are known to be intentionally filtered in some existing IPv6 deployments. This summarizes the issues associated with IPv6 extension headers, and presents real-world data regarding the extent to which packets with IPv6 extension headers are filtered in the public Internet, and where in the network such filtering occurs. Additionally, it provides some guidance to operators in troubleshooting IPv6 blackholes resulting from the use of IPv6 extension headers. Finally, this document provides some advice to protocol designers, and discusses areas where further work might be needed. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From bortzmeyer at nic.fr Fri Aug 8 08:43:05 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 8 Aug 2014 10:43:05 +0200 Subject: BGP hijacking to steal bitcoins Message-ID: <20140808084305.GA18456@laperouse.bortzmeyer.org> Good report (although I do not understand why they hide the name of the offending ISP since anyone can see it in RouteViews, or in its own BGP traffic). It's ordinary BGP hijacking but the goal is new: stealing bitcoins since the connections inside the mining pool are not authenticated. http://www.secureworks.com/cyber-threat-intelligence/threats/bgp-hijacking-for-cryptocurrency-profit/ Here is an example in RouteViews at LINX, for (among others) the OVH prefix 142.4.195.0/24 (bitcoin pool Hashfaster). This route was withdrawn at 18:35:08. TIME: 03/23/14 18:32:38 TYPE: BGP4MP/MESSAGE/Update FROM: 195.66.224.21 AS6939 TO: 195.66.225.222 AS6447 ORIGIN: IGP ASPATH: 6939 21548 34272 2093 2871 3721 NEXT_HOP: 195.66.224.21 ANNOUNCE 192.99.20.0/24 198.27.75.0/24 192.241.211.0/24 192.99.18.0/24 146.185.179.0/24 162.243.89.0/24 54.197.251.0/24 46.229.169.0/24 107.170.244.0/24 108.61.49.0/24 54.214.242.0/24 107.170.227.0/24 54.194.173.0/24 50.117.92.0/24 95.85.61.0/24 54.84.236.0/24 54.213.177.0/24 162.243.142.0/24 162.243.226.0/24 142.4.195.0/24 107.170.47.0/24 54.194.173.0/24 50.117.92.0/24 95.85.61.0/24 54.84.236.0/24 54.213.177.0/24 162.243.142.0/24 162.243.226.0/24 142.4.195.0/24 107.170.47.0/24 From morrowc.lists at gmail.com Fri Aug 8 13:53:07 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 8 Aug 2014 09:53:07 -0400 Subject: Verizon FiOS/Alter.net reachability issues In-Reply-To: References: Message-ID: On Wed, Aug 6, 2014 at 7:10 PM, Prabhu Gurumurthy wrote: > Can somebody from Verizon FiOS/Alter.net contact me off-list, we are having > issues with customers in FiOS going through Alter.net have bad latency. I take it that you've decided not to buy paid-peering to 701 then? From dquish at gmail.com Fri Aug 8 09:27:49 2014 From: dquish at gmail.com (DQ) Date: Fri, 8 Aug 2014 10:27:49 +0100 Subject: Cisco Switch Matrix In-Reply-To: References: Message-ID: Hi I have found the best way is to find the product you are after, for example 2960 switches and then they have a nice compare models feature. http://goo.gl/K2nC1u Don On 7 August 2014 23:04, Rimestad, Steinar wrote: > Hi. > > Have a look at the following pdf?s, I have been using these in the past. > > http://www.cisco.com/c/dam/en/us/solutions/collateral/wireless/aironet-1130 > -ag-series/cisco_switching_family.pdf > http://www.cisco.com/c/dam/en/us/products/collateral/switches/catalyst-3560 > -series-switches/CatalystPoster_Final.pdf > http://www.cisco.com/c/dam/en/us/products/collateral/switches/nexus-4000-se > ries-switches/6701_catswitch_guide_v7_r5.pdf > > > Regards, > Steinar > > > > > On 07/08/14 18:43, "Shawn L" wrote: > > >Has anyone seen a good matrix of Cisco switches and their port-types, etc? > >I'm looking for something where I can say 'I need a switch with X 10-gig > >ports and Y 1-gig sfp ports, which models meet that criteria?' > > > >I know I can look through all of the data sheets at cisco's website, but > >there has to be a better way to see the specs of a large array of switches > >at a glance. > > > >thanks > > > > > From Valdis.Kletnieks at vt.edu Fri Aug 8 16:01:46 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 08 Aug 2014 12:01:46 -0400 Subject: Cisco Switch Matrix In-Reply-To: Your message of "Fri, 08 Aug 2014 10:27:49 +0100." References: Message-ID: <35440.1407513706@turing-police.cc.vt.edu> On Fri, 08 Aug 2014 10:27:49 +0100, DQ said: > I have found the best way is to find the product you are after, for example > 2960 switches Right. Except the original question was "Which units can provide X Y and Z", and get the answer "you're looking for a 2960, a 3711, or a XMJ-6, each has at least one model that supports the config you want". *Then* you can go hit the nice 2960 model comparison chart. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From dquish at gmail.com Fri Aug 8 16:09:00 2014 From: dquish at gmail.com (DQ) Date: Fri, 8 Aug 2014 17:09:00 +0100 Subject: Cisco Switch Matrix In-Reply-To: <35440.1407513706@turing-police.cc.vt.edu> References: <35440.1407513706@turing-police.cc.vt.edu> Message-ID: feature navigator.... On 8 August 2014 17:01, wrote: > On Fri, 08 Aug 2014 10:27:49 +0100, DQ said: > > I have found the best way is to find the product you are after, for > example > > 2960 switches > > Right. Except the original question was "Which units can provide X Y and > Z", > and get the answer "you're looking for a 2960, a 3711, or a XMJ-6, each > has at > least one model that supports the config you want". > > *Then* you can go hit the nice 2960 model comparison chart. > From cscora at apnic.net Fri Aug 8 18:11:13 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 9 Aug 2014 04:11:13 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201408081811.s78IBDgk022712@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, TRNOG, 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 Aug, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 506245 Prefixes after maximum aggregation: 196119 Deaggregation factor: 2.58 Unique aggregates announced to Internet: 248983 Total ASes present in the Internet Routing Table: 47413 Prefixes per ASN: 10.68 Origin-only ASes present in the Internet Routing Table: 36034 Origin ASes announcing only one prefix: 16386 Transit ASes present in the Internet Routing Table: 6125 Transit-only ASes present in the Internet Routing Table: 177 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1680 Unregistered ASNs in the Routing Table: 441 Number of 32-bit ASNs allocated by the RIRs: 7148 Number of 32-bit ASNs visible in the Routing Table: 5254 Prefixes from 32-bit ASNs in the Routing Table: 19053 Number of bogon 32-bit ASNs visible in the Routing Table: 514 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 438 Number of addresses announced to Internet: 2711353476 Equivalent to 161 /8s, 155 /16s and 248 /24s Percentage of available address space announced: 73.2 Percentage of allocated address space announced: 73.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.7 Total number of prefixes smaller than registry allocations: 174121 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 122248 Total APNIC prefixes after maximum aggregation: 35814 APNIC Deaggregation factor: 3.41 Prefixes being announced from the APNIC address blocks: 125678 Unique aggregates announced from the APNIC address blocks: 51910 APNIC Region origin ASes present in the Internet Routing Table: 4964 APNIC Prefixes per ASN: 25.32 APNIC Region origin ASes announcing only one prefix: 1231 APNIC Region transit ASes present in the Internet Routing Table: 872 Average APNIC Region AS path length visible: 4.8 Max APNIC Region AS path length visible: 28 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1033 Number of APNIC addresses announced to Internet: 734075264 Equivalent to 43 /8s, 193 /16s and 25 /24s Percentage of available APNIC address space announced: 85.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 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, 150/8, 153/8, 163/8, 171/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: 170510 Total ARIN prefixes after maximum aggregation: 84267 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 172356 Unique aggregates announced from the ARIN address blocks: 80407 ARIN Region origin ASes present in the Internet Routing Table: 16357 ARIN Prefixes per ASN: 10.54 ARIN Region origin ASes announcing only one prefix: 6130 ARIN Region transit ASes present in the Internet Routing Table: 1690 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 162 Number of ARIN addresses announced to Internet: 1091961344 Equivalent to 65 /8s, 22 /16s and 2 /24s Percentage of available ARIN address space announced: 57.8 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, 62464-63487, 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, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 124574 Total RIPE prefixes after maximum aggregation: 62986 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 129384 Unique aggregates announced from the RIPE address blocks: 81972 RIPE Region origin ASes present in the Internet Routing Table: 17700 RIPE Prefixes per ASN: 7.31 RIPE Region origin ASes announcing only one prefix: 8244 RIPE Region transit ASes present in the Internet Routing Table: 2871 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2727 Number of RIPE addresses announced to Internet: 658697860 Equivalent to 39 /8s, 66 /16s and 238 /24s Percentage of available RIPE address space announced: 95.8 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 59392-61439, 61952-62463, 196608-202239 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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 58756 Total LACNIC prefixes after maximum aggregation: 10293 LACNIC Deaggregation factor: 5.71 Prefixes being announced from the LACNIC address blocks: 66605 Unique aggregates announced from the LACNIC address blocks: 29814 LACNIC Region origin ASes present in the Internet Routing Table: 2203 LACNIC Prefixes per ASN: 30.23 LACNIC Region origin ASes announcing only one prefix: 567 LACNIC Region transit ASes present in the Internet Routing Table: 451 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1282 Number of LACNIC addresses announced to Internet: 167756416 Equivalent to 9 /8s, 255 /16s and 194 /24s Percentage of available LACNIC address space announced: 100.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 11017 Total AfriNIC prefixes after maximum aggregation: 2722 AfriNIC Deaggregation factor: 4.05 Prefixes being announced from the AfriNIC address blocks: 11784 Unique aggregates announced from the AfriNIC address blocks: 4527 AfriNIC Region origin ASes present in the Internet Routing Table: 733 AfriNIC Prefixes per ASN: 16.08 AfriNIC Region origin ASes announcing only one prefix: 214 AfriNIC Region transit ASes present in the Internet Routing Table: 161 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 50 Number of AfriNIC addresses announced to Internet: 58436864 Equivalent to 3 /8s, 123 /16s and 173 /24s Percentage of available AfriNIC address space announced: 58.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2951 11590 922 Korea Telecom 17974 2802 899 72 PT Telekomunikasi Indonesia 7545 2332 320 118 TPG Telecom Limited 4755 1868 392 200 TATA Communications formerly 9829 1643 1306 31 National Internet Backbone 9583 1315 104 537 Sify Limited 9498 1299 317 92 BHARTI Airtel Ltd. 7552 1239 1098 14 Viettel Corporation 4808 1213 2155 372 CNCGROUP IP network China169 24560 1159 399 191 Bharti Airtel Ltd., Telemedia 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 7029 3211 1905 304 Windstream Communications Inc 6389 2938 3688 51 BellSouth.net Inc. 22773 2735 2940 141 Cox Communications Inc. 18566 2047 379 178 MegaPath Corporation 20115 1749 1735 537 Charter Communications 4323 1633 1072 410 tw telecom holdings, inc. 30036 1560 333 483 Mediacom Communications Corp 701 1442 11227 726 MCI Communications Services, 6983 1416 817 314 ITC^Deltacom 22561 1303 406 234 CenturyTel Internet Holdings, 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 34984 1725 265 278 TELLCOM ILETISIM HIZMETLERI A 20940 1455 567 1071 Akamai International B.V. 8402 1327 544 15 OJSC "Vimpelcom" 13188 1050 97 48 TOV "Bank-Inform" 31148 1043 45 21 Freenet Ltd. 8551 996 371 42 Bezeq International-Ltd 6849 792 356 27 JSC "Ukrtelecom" 12479 773 798 58 France Telecom Espana SA 6830 772 2334 427 Liberty Global Operations B.V 9198 602 346 28 JSC Kazakhtelecom 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 28573 3725 2027 106 NET Servi?os de Comunica??o S 10620 2937 476 224 Telmex Colombia S.A. 18881 2068 1036 22 Global Village Telecom 7303 1771 1180 232 Telecom Argentina S.A. 8151 1444 2989 408 Uninet S.A. de C.V. 6503 1091 434 62 Axtel, S.A.B. de C.V. 6147 1047 373 28 Telefonica del Peru S.A.A. 7738 977 1882 41 Telemar Norte Leste S.A. 27947 897 130 51 Telconet S.A 26615 868 2325 35 Tim Celular 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 24863 932 280 26 Link Egypt (Link.NET) 6713 669 744 37 Office National des Postes et 8452 595 958 13 TE-AS 24835 305 144 9 Vodafone Data 36992 298 784 26 ETISALAT MISR 3741 249 920 212 Internet Solutions 37054 239 19 6 Data Telecom Service 29571 236 22 17 Cote d'Ivoire Telecom 15706 187 32 6 Sudatel (Sudan Telecom Co. Lt 12258 175 26 72 MWEB CONNECT (PROPRIETARY) LI 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 28573 3725 2027 106 NET Servi?os de Comunica??o S 7029 3211 1905 304 Windstream Communications Inc 4766 2951 11590 922 Korea Telecom 6389 2938 3688 51 BellSouth.net Inc. 10620 2937 476 224 Telmex Colombia S.A. 17974 2802 899 72 PT Telekomunikasi Indonesia 22773 2735 2940 141 Cox Communications Inc. 7545 2332 320 118 TPG Telecom Limited 18881 2068 1036 22 Global Village Telecom 18566 2047 379 178 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3211 2907 Windstream Communications Inc 6389 2938 2887 BellSouth.net Inc. 17974 2802 2730 PT Telekomunikasi Indonesia 10620 2937 2713 Telmex Colombia S.A. 22773 2735 2594 Cox Communications Inc. 7545 2332 2214 TPG Telecom Limited 18881 2068 2046 Global Village Telecom 4766 2951 2029 Korea Telecom 18566 2047 1869 MegaPath Corporation 4755 1868 1668 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 55020 UNALLOCATED 8.30.123.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 23.226.240.0/20 40430 colo4jax, LLC 23.226.240.0/21 40430 colo4jax, LLC 23.226.248.0/21 40430 colo4jax, LLC 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 41.70.8.0/21 37098 globe internet limited 41.70.16.0/20 37098 globe internet limited 41.70.40.0/21 37098 globe internet limited 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 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:16 /9:13 /10:30 /11:91 /12:259 /13:497 /14:982 /15:1704 /16:13041 /17:7020 /18:11692 /19:24686 /20:35123 /21:37523 /22:54567 /23:47754 /24:269179 /25:800 /26:811 /27:402 /28:12 /29:17 /30:10 /31:1 /32:15 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2002 2047 MegaPath Corporation 22773 1978 2735 Cox Communications Inc. 7029 1786 3211 Windstream Communications Inc 6389 1691 2938 BellSouth.net Inc. 30036 1401 1560 Mediacom Communications Corp 11492 1194 1243 CABLE ONE, INC. 6983 1122 1416 ITC^Deltacom 34984 1052 1725 TELLCOM ILETISIM HIZMETLERI A 10620 1029 2937 Telmex Colombia S.A. 8402 1028 1327 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1309 2:658 3:3 4:15 5:1053 6:21 8:722 12:1855 13:4 14:1107 15:15 16:2 17:40 18:21 20:53 23:892 24:1764 27:1775 31:1472 32:41 33:2 34:5 36:141 37:1854 38:964 39:7 40:210 41:2581 42:259 43:170 44:17 45:50 46:2157 47:24 49:732 50:836 52:12 54:48 55:2 56:4 57:31 58:1224 59:618 60:427 61:1592 62:1239 63:1866 64:4404 65:2325 66:4234 67:2068 68:1048 69:3338 70:894 71:464 72:2021 74:2637 75:337 76:416 77:1662 78:793 79:711 80:1312 81:1211 82:759 83:767 84:768 85:1320 86:416 87:1144 88:468 89:1778 90:137 91:5703 92:759 93:1768 94:2016 95:1610 96:508 97:363 98:1113 99:49 100:65 101:707 103:5360 104:187 105:36 106:178 107:596 108:585 109:2011 110:1021 111:1340 112:676 113:859 114:783 115:1110 116:1120 117:992 118:1514 119:1419 120:420 121:858 122:2164 123:1538 124:1435 125:1565 128:584 129:336 130:363 131:661 132:405 133:162 134:323 135:76 136:299 137:286 138:371 139:170 140:207 141:390 142:562 143:419 144:506 145:115 146:649 147:498 148:972 149:405 150:420 151:604 152:450 153:219 154:320 155:517 156:354 157:344 158:272 159:936 160:327 161:570 162:1687 163:342 164:694 165:638 166:345 167:668 168:1116 169:124 170:1379 171:181 172:65 173:1539 174:707 175:606 176:1495 177:3488 178:2072 179:773 180:1781 181:1336 182:1611 183:540 184:704 185:1921 186:2924 187:1634 188:2157 189:1458 190:7624 191:686 192:7472 193:5499 194:4056 195:3555 196:1439 197:678 198:5109 199:5522 200:6306 201:2771 202:9168 203:9016 204:4535 205:2669 206:2967 207:2958 208:3974 209:3774 210:3169 211:1798 212:2339 213:2116 214:860 215:87 216:5716 217:1681 218:614 219:331 220:1283 221:625 222:360 223:591 End of report From cidr-report at potaroo.net Fri Aug 8 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 Aug 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201408082200.s78M00hK063068@wattle.apnic.net> This report has been generated at Fri Aug 8 21:14:09 2014 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 01-08-14 510519 286231 02-08-14 510548 286297 03-08-14 510876 286373 04-08-14 510772 280020 05-08-14 510524 280219 06-08-14 511103 280424 07-08-14 511297 280432 08-08-14 511736 280477 AS Summary 47887 Number of ASes in routing system 19408 Number of ASes announcing only one prefix 3723 Largest number of prefixes announced by an AS AS28573: NET Servi?os de Comunica??o S.A.,BR 120512000 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 08Aug14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 511832 280493 231339 45.2% All ASes AS28573 3723 130 3593 96.5% NET Servi?os de Comunica??o S.A.,BR AS6389 2937 80 2857 97.3% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2803 77 2726 97.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS22773 2736 175 2561 93.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS18881 2068 53 2015 97.4% Global Village Telecom,BR AS7029 3335 1540 1795 53.8% WINDSTREAM - Windstream Communications Inc,US AS4766 2951 1197 1754 59.4% KIXS-AS-KR Korea Telecom,KR AS7303 1776 286 1490 83.9% Telecom Argentina S.A.,AR AS4755 1866 558 1308 70.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS8402 1299 27 1272 97.9% CORBINA-AS OJSC "Vimpelcom",RU AS4323 1643 416 1227 74.7% TWTC - tw telecom holdings, inc.,US AS7552 1265 62 1203 95.1% VIETEL-AS-AP Viettel Corporation,VN AS7545 2348 1149 1199 51.1% TPG-INTERNET-AP TPG Telecom Limited,AU AS9498 1299 111 1188 91.5% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2046 863 1183 57.8% MEGAPATH5-US - MegaPath Corporation,US AS20115 1750 611 1139 65.1% CHARTER-NET-HKY-NC - Charter Communications,US AS10620 2937 1821 1116 38.0% Telmex Colombia S.A.,CO AS6983 1416 316 1100 77.7% ITCDELTA - Earthlink, Inc.,US AS22561 1303 265 1038 79.7% AS22561 - CenturyTel Internet Holdings, Inc.,US AS9808 1057 26 1031 97.5% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS7738 977 41 936 95.8% Telemar Norte Leste S.A.,BR AS6147 1047 147 900 86.0% Telefonica del Peru S.A.A.,PE AS38285 956 112 844 88.3% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS24560 1159 341 818 70.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS4788 1022 208 814 79.6% TMNET-AS-AP TM Net, Internet Service Provider,MY AS4780 1027 249 778 75.8% SEEDNET Digital United Inc.,TW AS8151 1453 690 763 52.5% Uninet S.A. de C.V.,MX AS18101 949 190 759 80.0% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS31148 1043 290 753 72.2% FREENET-AS Freenet Ltd.,UA AS26615 868 129 739 85.1% Tim Celular S.A.,BR Total 53059 12160 40899 77.1% Top 30 total Possible Bogus Routes 23.226.240.0/20 AS40430 -Reserved AS-,ZZ 23.226.240.0/21 AS40430 -Reserved AS-,ZZ 23.226.248.0/21 AS40430 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 41.70.8.0/21 AS37098 globe-as,MW 41.70.16.0/20 AS37098 globe-as,MW 41.70.40.0/21 AS37098 globe-as,MW 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.190.1.0/24 AS37076 -Reserved AS-,ZZ 41.190.2.0/24 AS37076 -Reserved AS-,ZZ 41.190.3.0/24 AS37076 -Reserved AS-,ZZ 41.190.4.0/22 AS37076 -Reserved AS-,ZZ 41.190.4.0/24 AS37076 -Reserved AS-,ZZ 41.190.5.0/24 AS37076 -Reserved AS-,ZZ 41.190.8.0/24 AS37076 -Reserved AS-,ZZ 41.190.10.0/23 AS37076 -Reserved AS-,ZZ 41.190.12.0/24 AS37076 -Reserved AS-,ZZ 41.190.13.0/24 AS37076 -Reserved AS-,ZZ 41.190.14.0/24 AS37076 -Reserved AS-,ZZ 41.190.16.0/20 AS37076 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.197.0.0/16 AS36934 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.193.160.0/19 AS24801 -Reserved AS-,ZZ 62.193.160.0/20 AS24801 -Reserved AS-,ZZ 62.193.176.0/20 AS24801 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.68.32.0/20 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.32.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.33.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.34.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.35.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.36.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.37.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.38.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.39.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.40.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.41.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.48.0/20 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.48.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.49.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.50.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.51.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.52.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.53.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.54.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.55.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.56.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.57.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.58.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.59.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.60.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.61.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.62.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.63.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.111.160.0/20 AS40551 -Reserved AS-,ZZ 64.111.160.0/24 AS40551 -Reserved AS-,ZZ 64.111.161.0/24 AS40551 -Reserved AS-,ZZ 64.111.162.0/24 AS40551 -Reserved AS-,ZZ 64.111.167.0/24 AS40551 -Reserved AS-,ZZ 64.111.169.0/24 AS40551 -Reserved AS-,ZZ 64.111.170.0/24 AS40551 -Reserved AS-,ZZ 64.111.171.0/24 AS40551 -Reserved AS-,ZZ 64.111.172.0/24 AS40551 -Reserved AS-,ZZ 64.111.173.0/24 AS40551 -Reserved AS-,ZZ 64.111.174.0/24 AS40551 -Reserved AS-,ZZ 64.111.175.0/24 AS40551 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.6.176.0/20 AS13133 MAXHIGH-HK MAX HIGH,HK 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 -Reserved AS-,ZZ 74.120.214.0/23 AS32326 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 89.207.8.0/21 AS3292 TDC TDC A/S,DK 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.228.160.0/24 AS56815 -Reserved AS-,ZZ 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 93.157.104.0/21 AS47951 TELECONTUR-AS LLC Telecontur,CZ 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN 103.6.228.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.9.88.0/22 AS58598 103.9.108.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.9.140.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.9.141.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.9.142.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.9.143.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP 103.18.92.0/22 AS13269 103.18.92.0/24 AS13269 103.18.94.0/24 AS13269 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.25.120.0/22 AS13280 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.249.8.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.249.104.0/22 AS55536 PSWITCH-HK Pacswitch Colocation & Datacentre,HK 103.249.106.0/24 AS55536 PSWITCH-HK Pacswitch Colocation & Datacentre,HK 103.249.107.0/24 AS55536 PSWITCH-HK Pacswitch Colocation & Datacentre,HK 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.108.16.0/22 AS38904 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 162.210.52.0/24 AS11487 -Reserved AS-,ZZ 162.210.53.0/24 AS11487 -Reserved AS-,ZZ 162.210.55.0/24 AS11487 -Reserved AS-,ZZ 162.218.168.0/21 AS40430 -Reserved AS-,ZZ 162.218.175.0/24 AS40430 -Reserved AS-,ZZ 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.126.251.0/24 AS50818 -Reserved AS-,ZZ 194.146.35.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR 194.146.36.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.245.98.0/23 AS48918 GLOBALWAYS GLOBALWAYS AG,DE 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.254.96.0/20 AS40430 -Reserved AS-,ZZ 198.254.96.0/22 AS40430 -Reserved AS-,ZZ 198.254.100.0/22 AS40430 -Reserved AS-,ZZ 198.254.104.0/21 AS40430 -Reserved AS-,ZZ 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.168.56.0/24 AS54593 -Reserved AS-,ZZ 199.168.58.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 199.168.59.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.50.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.10.94.0/23 AS30097 NUWAVE - NuWave,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.155.28.0/22 AS40925 -Reserved AS-,ZZ 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.246.64.0/18 AS7963 STDIO - OPEN WORLD, INC.,US 207.246.70.0/24 AS7963 STDIO - OPEN WORLD, INC.,US 207.246.75.0/24 AS36480 TROLL-AND-TOAD - Troll and Toad,US 207.246.94.0/24 AS7963 STDIO - OPEN WORLD, INC.,US 207.246.103.0/24 AS7963 STDIO - OPEN WORLD, INC.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.209.224.0/19 AS19513 -Reserved AS-,ZZ 209.209.248.0/23 AS19513 -Reserved AS-,ZZ 209.209.250.0/23 AS19513 -Reserved AS-,ZZ 209.209.251.0/24 AS19513 -Reserved AS-,ZZ 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 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 cidr-report at potaroo.net Fri Aug 8 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 Aug 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201408082200.s78M01ml063074@wattle.apnic.net> BGP Update Report Interval: 12-Jul-14 -to- 19-Jul-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS12858 93683 3.5% 5510.8 -- MYNET A.S.,TR 2 - AS9829 75620 2.8% 53.7 -- BSNL-NIB National Internet Backbone,IN 3 - AS14287 48903 1.8% 8150.5 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 4 - AS1659 47616 1.8% 189.0 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW 5 - AS38141 47282 1.8% 5253.6 -- CITRAMEDIA-AS-ID PT. Citramedia Network,ID 6 - AS8402 33111 1.2% 48.8 -- CORBINA-AS OJSC "Vimpelcom",RU 7 - AS28573 27839 1.0% 8.1 -- NET Servi?os de Comunica??o S.A.,BR 8 - AS57320 26056 1.0% 1532.7 -- T-TELECOM-MNT-AS Ionit-telecom Ltd.,RU 9 - AS26769 24230 0.9% 356.3 -- BANDCON - Bandcon,US 10 - AS647 23081 0.9% 162.5 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center,US 11 - AS23752 19644 0.7% 159.7 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 12 - AS45899 17566 0.7% 41.0 -- VNPT-AS-VN VNPT Corp,VN 13 - AS4775 16355 0.6% 778.8 -- GLOBE-TELECOM-AS Globe Telecoms,PH 14 - AS7029 14465 0.5% 4.0 -- WINDSTREAM - Windstream Communications Inc,US 15 - AS25003 12854 0.5% 1168.5 -- INTERNET_BINAT Internet Binat Ltd,IL 16 - AS7552 12811 0.5% 10.4 -- VIETEL-AS-AP Viettel Corporation,VN 17 - AS25184 12742 0.5% 97.3 -- AFRANET AFRANET Co. Tehran, Iran,IR 18 - AS42337 12067 0.5% 95.8 -- RESPINA-AS Respina Networks & Beyond PJSC,IR 19 - AS8151 11955 0.5% 10.8 -- Uninet S.A. de C.V.,MX 20 - AS4766 10294 0.4% 3.6 -- KIXS-AS-KR Korea Telecom,KR TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS54465 8523 0.3% 8523.0 -- QPM-AS-1 - QuickPlay Media Inc.,US 2 - AS6459 8298 0.3% 8298.0 -- TRANSBEAM - I-2000, Inc.,US 3 - AS14287 48903 1.8% 8150.5 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 4 - AS18135 7821 0.3% 7821.0 -- BTV BTV Cable television,JP 5 - AS3 7265 0.3% 5212.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 6 - AS12858 93683 3.5% 5510.8 -- MYNET A.S.,TR 7 - AS38141 47282 1.8% 5253.6 -- CITRAMEDIA-AS-ID PT. Citramedia Network,ID 8 - AS34873 3337 0.1% 3337.0 -- IGIF-AS ACSS - Administracao Central do Sistema de Saude, I.P.,PT 9 - AS26661 9956 0.4% 3318.7 -- JCPS-ASN - Jeffco Public Schools,US 10 - AS54464 2875 0.1% 2875.0 -- D4LLC - D4 LLC,US 11 - AS23074 5859 0.2% 1953.0 -- Petr?leo Brasileiro S/A - Petrobras,BR 12 - AS33643 1635 0.1% 1635.0 -- JELLYBELLY - Jelly Belly Candy Company,US 13 - AS57320 26056 1.0% 1532.7 -- T-TELECOM-MNT-AS Ionit-telecom Ltd.,RU 14 - AS25003 12854 0.5% 1168.5 -- INTERNET_BINAT Internet Binat Ltd,IL 15 - AS3 1052 0.0% 5517.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 16 - AS58763 959 0.0% 959.0 -- GIGAVIRT-AS Gigavirt Technologies,IN 17 - AS37532 4822 0.2% 803.7 -- ZAMREN,ZM 18 - AS35093 1581 0.1% 790.5 -- RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 19 - AS3 10128 0.4% 134.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 20 - AS4775 16355 0.6% 778.8 -- GLOBE-TELECOM-AS Globe Telecoms,PH TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.115.44.0/22 12799 0.5% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 2 - 23.197.176.0/20 12077 0.4% AS26769 -- BANDCON - Bandcon,US 3 - 23.197.192.0/20 11940 0.4% AS26769 -- BANDCON - Bandcon,US 4 - 176.97.96.0/24 10715 0.4% AS57320 -- T-TELECOM-MNT-AS Ionit-telecom Ltd.,RU 5 - 176.97.111.0/24 10715 0.4% AS57320 -- T-TELECOM-MNT-AS Ionit-telecom Ltd.,RU 6 - 78.109.192.0/20 10094 0.4% AS25184 -- AFRANET AFRANET Co. Tehran, Iran,IR 7 - 185.17.128.0/24 10047 0.4% AS3 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 8 - 208.70.20.0/22 9817 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 9 - 208.73.244.0/22 9775 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 10 - 208.88.232.0/22 9773 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 11 - 216.162.0.0/20 9773 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 12 - 208.78.116.0/22 9761 0.3% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.,US 13 - 192.58.232.0/24 9637 0.3% AS6629 -- NOAA-AS - NOAA,US 14 - 202.70.88.0/21 9188 0.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 15 - 206.152.15.0/24 8523 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 16 - 202.70.64.0/21 8486 0.3% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 17 - 205.247.12.0/24 8298 0.3% AS6459 -- TRANSBEAM - I-2000, Inc.,US 18 - 120.28.62.0/24 8104 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 19 - 222.127.0.0/24 8034 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 20 - 163.15.192.0/24 7844 0.3% AS1659 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW 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 gabriel.j.marais at gmail.com Sun Aug 10 15:19:49 2014 From: gabriel.j.marais at gmail.com (Gabriel Marais) Date: Sun, 10 Aug 2014 17:19:49 +0200 Subject: Dealing with abuse complaints to non-existent contacts Message-ID: Hi Nanog I'm curious. I have been receiving some major ssh brute-force attacks coming from random hosts in the 116.8.0.0 - 116.11.255.255 network. I have sent a complaint to the e-mail addresses obtained from a whois query on one of the IP Addresses. My e-mail bounced back from both recipients. Once being rejected by filter and the other because the e-mail address doesn't exist. I would have thought that contact details are rather important to be up to date, or not? Besides just blocking the IP range on my firewall, I was wondering what others would do in this case? Regards, Gabriel From contact at winterei.se Sun Aug 10 16:44:59 2014 From: contact at winterei.se (Paul S.) Date: Mon, 11 Aug 2014 01:44:59 +0900 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: References: Message-ID: <53E7A18B.7020601@winterei.se> It would appear you've done your part in trying to reach out (and subsequently failed), so the next step to go is dropping all traffic from it. Nothing wrong with trying to protect your own customer from people who cannot be bothered to do their own due diligence. On 8/11/2014 ?? 12:19, Gabriel Marais wrote: > Hi Nanog > > I'm curious. > > I have been receiving some major ssh brute-force attacks coming from random > hosts in the 116.8.0.0 - 116.11.255.255 network. I have sent a complaint to > the e-mail addresses obtained from a whois query on one of the IP Addresses. > > My e-mail bounced back from both recipients. Once being rejected by filter > and the other because the e-mail address doesn't exist. I would have > thought that contact details are rather important to be up to date, or not? > > Besides just blocking the IP range on my firewall, I was wondering what > others would do in this case? > > > Regards, Gabriel From list at satchell.net Sun Aug 10 17:04:54 2014 From: list at satchell.net (Stephen Satchell) Date: Sun, 10 Aug 2014 10:04:54 -0700 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: References: Message-ID: <53E7A636.10609@satchell.net> On 08/10/2014 08:19 AM, Gabriel Marais wrote: > Hi Nanog > > I'm curious. > > I have been receiving some major ssh brute-force attacks coming from random > hosts in the 116.8.0.0 - 116.11.255.255 network. I have sent a complaint to > the e-mail addresses obtained from a whois query on one of the IP Addresses. > > My e-mail bounced back from both recipients. Once being rejected by filter > and the other because the e-mail address doesn't exist. I would have > thought that contact details are rather important to be up to date, or not? > > Besides just blocking the IP range on my firewall, I was wondering what > others would do in this case? > > > Regards, Gabriel > I no longer try to send notices to network operators that don't publish a working abuse mail address for the netrange assignment or the SWIP. For the best-practices-clueless, I just round-file them when I see attacks above a certain level. Ditto mail attacks, particularly from netranges/servers that don't have working postmaster@ addresses or MX. (I'm considering adding a separate network ACL for SMTP/SUBMISSION in my mail servers, but so far all the verifiable mail abusers have had other bad habits, too.) >From my firewall generator's "kill network" list: 116.10.191.0/24 china ssh abuser 2014 August That entry went into the ACL six months ago, but it's only recently that I started dating the entries. I now have canaries (tcpwrappers, logwatch) in four systems on widely separate IP netranges. Those systems have a virtually-everything-closed firewall (IPTables, logwatch) and the resulting logs show where some of the most vicious scans are coming from. PLONK! From johnl at iecc.com Sun Aug 10 17:08:02 2014 From: johnl at iecc.com (John Levine) Date: 10 Aug 2014 17:08:02 -0000 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: Message-ID: <20140810170802.86741.qmail@joyce.lan> >My e-mail bounced back from both recipients. Once being rejected by filter >and the other because the e-mail address doesn't exist. I would have >thought that contact details are rather important to be up to date, or not? Opinions vary. Some providers would rather just cash the customers' checks and not waste valuable staff time on complaints in languages they can barely read. After you block all traffic from the network (in my experience, if they have bogus contacts, they have nothing of interest to say), you might send a note to APNIC telling them that they might want to note that those contacts are invalid. R's, John From jlewis at lewis.org Sun Aug 10 17:18:08 2014 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 10 Aug 2014 13:18:08 -0400 (EDT) Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: References: Message-ID: On Sun, 10 Aug 2014, Gabriel Marais wrote: > I have been receiving some major ssh brute-force attacks coming from random > hosts in the 116.8.0.0 - 116.11.255.255 network. I have sent a complaint to > the e-mail addresses obtained from a whois query on one of the IP Addresses. > > My e-mail bounced back from both recipients. Once being rejected by filter > and the other because the e-mail address doesn't exist. I would have > thought that contact details are rather important to be up to date, or not? Why? > Besides just blocking the IP range on my firewall, I was wondering what > others would do in this case? I've been blocking SSH from random IPs for many years. Unless you have to run an open system that customers SSH into (unlikely in these times), my recommendation is block SSH entirely from non-trusted networks and setup some form of port-knocking or similar access controls such that legitimate users can open a window to make their connection, but the rest of the world never sees your sshd. Playing whack-a-mole with firewall or access log violations is a waste of time. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From phiber at phiber.org Sun Aug 10 17:20:15 2014 From: phiber at phiber.org (Christopher Rogers) Date: Sun, 10 Aug 2014 10:20:15 -0700 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: References: Message-ID: http://www.fail2ban.org/ 2014-08-10 10:18 GMT-07:00 Jon Lewis : > On Sun, 10 Aug 2014, Gabriel Marais wrote: > > I have been receiving some major ssh brute-force attacks coming from >> random >> hosts in the 116.8.0.0 - 116.11.255.255 network. I have sent a complaint >> to >> the e-mail addresses obtained from a whois query on one of the IP >> Addresses. >> >> My e-mail bounced back from both recipients. Once being rejected by filter >> and the other because the e-mail address doesn't exist. I would have >> thought that contact details are rather important to be up to date, or >> not? >> > > Why? > > > Besides just blocking the IP range on my firewall, I was wondering what >> others would do in this case? >> > > I've been blocking SSH from random IPs for many years. Unless you have to > run an open system that customers SSH into (unlikely in these times), my > recommendation is block SSH entirely from non-trusted networks and setup > some form of port-knocking or similar access controls such that legitimate > users can open a window to make their connection, but the rest of the world > never sees your sshd. > > Playing whack-a-mole with firewall or access log violations is a waste of > time. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From alexmern at xi.uz Sun Aug 10 18:25:36 2014 From: alexmern at xi.uz (Alexander Merniy) Date: Sun, 10 Aug 2014 23:25:36 +0500 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: References: Message-ID: <40B688CA-733F-4C48-99C2-1AB16E89DB7F@xi.uz> Move ssh to a non-standart port + fail2ban - best solution. On 10 Aug 2014, at 22:20, Christopher Rogers wrote: > http://www.fail2ban.org/ > > > > > 2014-08-10 10:18 GMT-07:00 Jon Lewis : > >> On Sun, 10 Aug 2014, Gabriel Marais wrote: >> >> I have been receiving some major ssh brute-force attacks coming from >>> random >>> hosts in the 116.8.0.0 - 116.11.255.255 network. I have sent a complaint >>> to >>> the e-mail addresses obtained from a whois query on one of the IP >>> Addresses. >>> >>> My e-mail bounced back from both recipients. Once being rejected by filter >>> and the other because the e-mail address doesn't exist. I would have >>> thought that contact details are rather important to be up to date, or >>> not? >>> >> >> Why? >> >> >> Besides just blocking the IP range on my firewall, I was wondering what >>> others would do in this case? >>> >> >> I've been blocking SSH from random IPs for many years. Unless you have to >> run an open system that customers SSH into (unlikely in these times), my >> recommendation is block SSH entirely from non-trusted networks and setup >> some form of port-knocking or similar access controls such that legitimate >> users can open a window to make their connection, but the rest of the world >> never sees your sshd. >> >> Playing whack-a-mole with firewall or access log violations is a waste of >> time. >> >> ---------------------------------------------------------------------- >> Jon Lewis, MCP :) | I route >> | therefore you are >> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ >> From eyeronic.design at gmail.com Sun Aug 10 18:33:17 2014 From: eyeronic.design at gmail.com (Mike Hale) Date: Sun, 10 Aug 2014 11:33:17 -0700 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: <40B688CA-733F-4C48-99C2-1AB16E89DB7F@xi.uz> References: <40B688CA-733F-4C48-99C2-1AB16E89DB7F@xi.uz> Message-ID: Well...is it really a problem though? I mean, a good password will require how many centuries of effort to brute force? I've never seen a single IP (or even a range of IPs) trying to brute force the same user account over more than a day, much less the huge amount of time required the crack the password. Sure, it fills up your logs, but that's good info to have and pass on (to DShield, for example). On Sun, Aug 10, 2014 at 11:25 AM, Alexander Merniy wrote: > Move ssh to a non-standart port + fail2ban - best solution. > > > On 10 Aug 2014, at 22:20, Christopher Rogers wrote: > >> http://www.fail2ban.org/ >> >> >> >> >> 2014-08-10 10:18 GMT-07:00 Jon Lewis : >> >>> On Sun, 10 Aug 2014, Gabriel Marais wrote: >>> >>> I have been receiving some major ssh brute-force attacks coming from >>>> random >>>> hosts in the 116.8.0.0 - 116.11.255.255 network. I have sent a complaint >>>> to >>>> the e-mail addresses obtained from a whois query on one of the IP >>>> Addresses. >>>> >>>> My e-mail bounced back from both recipients. Once being rejected by filter >>>> and the other because the e-mail address doesn't exist. I would have >>>> thought that contact details are rather important to be up to date, or >>>> not? >>>> >>> >>> Why? >>> >>> >>> Besides just blocking the IP range on my firewall, I was wondering what >>>> others would do in this case? >>>> >>> >>> I've been blocking SSH from random IPs for many years. Unless you have to >>> run an open system that customers SSH into (unlikely in these times), my >>> recommendation is block SSH entirely from non-trusted networks and setup >>> some form of port-knocking or similar access controls such that legitimate >>> users can open a window to make their connection, but the rest of the world >>> never sees your sshd. >>> >>> Playing whack-a-mole with firewall or access log violations is a waste of >>> time. >>> >>> ---------------------------------------------------------------------- >>> Jon Lewis, MCP :) | I route >>> | therefore you are >>> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ >>> > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From goemon at anime.net Sun Aug 10 20:28:14 2014 From: goemon at anime.net (goemon at anime.net) Date: Sun, 10 Aug 2014 13:28:14 -0700 (PDT) Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: <53E7A18B.7020601@winterei.se> References: <53E7A18B.7020601@winterei.se> Message-ID: On Mon, 11 Aug 2014, Paul S. wrote: > It would appear you've done your part in trying to reach out (and > subsequently failed), so the next step to go is dropping all traffic from it. > > Nothing wrong with trying to protect your own customer from people who cannot > be bothered to do their own due diligence. It would be nice if allocations would be revoked due to invalid/fake contact info. -Dan From woody at pch.net Sun Aug 10 21:05:44 2014 From: woody at pch.net (Bill Woodcock) Date: Sun, 10 Aug 2014 14:05:44 -0700 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: References: <53E7A18B.7020601@winterei.se> Message-ID: <7DB563EA-ED6B-4C1A-836F-9BBAFA8E1C50@pch.net> On Aug 10, 2014, at 1:28 PM, goemon at anime.net wrote: > On Mon, 11 Aug 2014, Paul S. wrote: >> It would appear you've done your part in trying to reach out (and subsequently failed), so the next step to go is dropping all traffic from it. >> >> Nothing wrong with trying to protect your own customer from people who cannot be bothered to do their own due diligence. > > It would be nice if allocations would be revoked due to invalid/fake contact info. That?s been debated many times, in most of the RIRs, and has not resulted in any persistent policies that I remember offhand. The tide may turn, as it were, if problems get sufficiently bad, at which point these sorts of policies might receive sufficient support to be passed, and stick. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jcurran at arin.net Sun Aug 10 21:14:17 2014 From: jcurran at arin.net (John Curran) Date: Sun, 10 Aug 2014 21:14:17 +0000 Subject: New ARIN Remittance Address References: <53D91AB6.3020203@arin.net> Message-ID: <678434C3-E0A3-4928-9B42-64635D020C95@corp.arin.net> Folks - ARIN recently changed its lockbox service provider, and hence now has a new mailing address for payments. If you coordinate the registration services payments for your organization, it is worth confirming that payments are now going to the new address (per attached). FYI, /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] New ARIN Remittance Address Date: July 30, 2014 at 12:17:58 PM EDT To: > Please update you address book! Effective 1 August 2014, ARIN will have a new remittance address for payments by mail: American Registry for Internet Numbers P.O. Box 759477 Baltimore, MD 21275-9477 ARIN's mailing address for all other items remains the same. If you have questions, please contact the billing help desk at +1.703.227.9886 or email billing at arin.net. Regards, Val Winkelman Director of Financial Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From drc at virtualized.org Sun Aug 10 21:15:03 2014 From: drc at virtualized.org (David Conrad) Date: Sun, 10 Aug 2014 14:15:03 -0700 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: <7DB563EA-ED6B-4C1A-836F-9BBAFA8E1C50@pch.net> References: <53E7A18B.7020601@winterei.se> <7DB563EA-ED6B-4C1A-836F-9BBAFA8E1C50@pch.net> Message-ID: <0C718BDC-712D-472F-B135-076DF8FDF692@virtualized.org> On Aug 10, 2014, at 2:05 PM, Bill Woodcock wrote: >> It would be nice if allocations would be revoked due to invalid/fake contact info. > > That?s been debated many times, in most of the RIRs, and has not resulted in any persistent policies that I remember offhand. The tide may turn, as it were, if problems get sufficiently bad, at which point these sorts of policies might receive sufficient support to be passed, and stick. Which, of course, would not actually cause address space to be magically returned to the RIR. The RIRs are not the Internet Police and attempting to use the Whois database as a stick to beat ?bad? ISPs will simply result in the Whois database becoming less and less relevant. What might work would be for the RIRs to annotate registration data records with stuff like "valid/invalid contact information? (accessible programmatically via RDAP) and allow ISPs to build filters based on that annotation. But yes, this has been debated many times and nothing ever seems to get done. Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From owen at delong.com Sun Aug 10 22:31:25 2014 From: owen at delong.com (Owen DeLong) Date: Sun, 10 Aug 2014 15:31:25 -0700 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: References: <53E7A18B.7020601@winterei.se> Message-ID: On Aug 10, 2014, at 1:28 PM, goemon at anime.net wrote: > On Mon, 11 Aug 2014, Paul S. wrote: >> It would appear you've done your part in trying to reach out (and subsequently failed), so the next step to go is dropping all traffic from it. >> >> Nothing wrong with trying to protect your own customer from people who cannot be bothered to do their own due diligence. > > It would be nice if allocations would be revoked due to invalid/fake contact info. > > -Dan I kind of agree, but past efforts in this regard have not met with consensus from the ARIN community. If you believe this to be the case, I suggest putting it into template format and submitting to policy at arin.net. I?m happy to help if you would like. Subscribing to arin-ppml will allow you to participate in the community discussion of the policy proposal. Owen From marka at isc.org Mon Aug 11 01:04:18 2014 From: marka at isc.org (Mark Andrews) Date: Mon, 11 Aug 2014 11:04:18 +1000 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: Your message of "Sun, 10 Aug 2014 15:31:25 -0700." References: <53E7A18B.7020601@winterei.se> Message-ID: <20140811010418.E7A2A1CAC27C@rock.dv.isc.org> In message , Owen DeLong writes: > > On Aug 10, 2014, at 1:28 PM, goemon at anime.net wrote: > > > On Mon, 11 Aug 2014, Paul S. wrote: > >> It would appear you've done your part in trying to reach out (and > >> subsequently failed), so the next step to go is dropping all traffic from > >> it. > >> > >> Nothing wrong with trying to protect your own customer from people who > >> cannot be bothered to do their own due diligence. > > > > It would be nice if allocations would be revoked due to invalid/fake > > contact info. > > > > -Dan > > I kind of agree, but past efforts in this regard have not met with > consensus from the ARIN community. > > If you believe this to be the case, I suggest putting it into template > format and submitting to policy at arin.net. > > I'm happy to help if you would like. Subscribing to arin-ppml will allow > you to participate in the community discussion of the policy proposal. > > Owen It really isn't the RIR's job to withdraw allocations due to bad behaviour as much as many of us would like it to be. Failure to maintain valid contact details however is within the purview of the RIRs. If you are being attacked, report the attack to your LEA. Let the LEA's maintain intellegence on which networks are permitting attacks to be launched from their address space. They can work with LEA in the network's juristiction to get the attacks stops and offenders prosecuted. LEA's can in theory also get courts to issue orders to filter offending address blocks by all ISP's in their juristiction. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From goemon at anime.net Mon Aug 11 00:33:12 2014 From: goemon at anime.net (goemon at anime.net) Date: Sun, 10 Aug 2014 17:33:12 -0700 (PDT) Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: <0C718BDC-712D-472F-B135-076DF8FDF692@virtualized.org> References: <53E7A18B.7020601@winterei.se> <7DB563EA-ED6B-4C1A-836F-9BBAFA8E1C50@pch.net> <0C718BDC-712D-472F-B135-076DF8FDF692@virtualized.org> Message-ID: On Sun, 10 Aug 2014, David Conrad wrote: > On Aug 10, 2014, at 2:05 PM, Bill Woodcock wrote: >>> It would be nice if allocations would be revoked due to invalid/fake contact info. >> That?s been debated many times, in most of the RIRs, and has not resulted in any persistent policies that I remember offhand. The tide may turn, as it were, if problems get sufficiently bad, at which point these sorts of policies might receive sufficient support to be passed, and stick. > Which, of course, would not actually cause address space to be magically returned to the RIR. The RIRs are not the Internet Police and attempting to use the Whois database as a stick to beat ?bad? ISPs will simply result in the Whois database becoming less and less relevant. > > What might work would be for the RIRs to annotate registration data records with stuff like "valid/invalid contact information? (accessible programmatically via RDAP) and allow ISPs to build filters based on that annotation. > > But yes, this has been debated many times and nothing ever seems to get done. RBL / BGP blackholes based on bad registration info? Could work. -Dan From david at blue-labs.org Mon Aug 11 02:16:58 2014 From: david at blue-labs.org (David Ford) Date: Sun, 10 Aug 2014 22:16:58 -0400 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: References: Message-ID: <53E8279A.2050507@blue-labs.org> i have numerous servers that must have open ssh access to everyone in multiple datacenters for several hundred users from many different and varying origins that change frequently. whitelist/blacklisting would be a nightmare. i use a PAM module that automatically adds every new ssh connection IP to an xt_recent blacklist, a) if you succeed authenticating, your IP is automatically removed, b) if more packets arrive that exceed the count limit within time limit for your /24, you automatically get blocked for a while. no point wasting time managing blacklists on IPs when nearly all of them are bots and most of the service providers out there either a) don't care, b) don't have a functioning abuse/security contact, c) ignore reports, or d) helplessly clueless. -d On Sun, 10 Aug 2014, Gabriel Marais wrote: >> I have been receiving some major ssh brute-force attacks coming from >> random >> hosts in the 116.8.0.0 - 116.11.255.255 network. I have sent a >> complaint to >> the e-mail addresses obtained from a whois query on one of the IP >> Addresses. From ops.lists at gmail.com Mon Aug 11 03:04:22 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 11 Aug 2014 08:34:22 +0530 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: <20140811010418.E7A2A1CAC27C@rock.dv.isc.org> References: <53E7A18B.7020601@winterei.se> <20140811010418.E7A2A1CAC27C@rock.dv.isc.org> Message-ID: Good luck getting action from foreign LE through the mlat system You might get a response, oh, in the next two years or so. IF you can find local LE willing to push the case forward. Beyond that while RIRs are not the internet police they do owe it to the community to be more vigilant on dud contact addresses, and also do a lot^W bit more due diligence when allocating IP space, and when appointing LIRs. On 11-Aug-2014 6:37 am, "Mark Andrews" wrote: > > In message , Owen DeLong > writes: > > > > On Aug 10, 2014, at 1:28 PM, goemon at anime.net wrote: > > > > > On Mon, 11 Aug 2014, Paul S. wrote: > > >> It would appear you've done your part in trying to reach out (and > > >> subsequently failed), so the next step to go is dropping all traffic > from > > >> it. > > >> > > >> Nothing wrong with trying to protect your own customer from people who > > >> cannot be bothered to do their own due diligence. > > > > > > It would be nice if allocations would be revoked due to invalid/fake > > > contact info. > > > > > > -Dan > > > > I kind of agree, but past efforts in this regard have not met with > > consensus from the ARIN community. > > > > If you believe this to be the case, I suggest putting it into template > > format and submitting to policy at arin.net. > > > > I'm happy to help if you would like. Subscribing to arin-ppml will allow > > you to participate in the community discussion of the policy proposal. > > > > Owen > > It really isn't the RIR's job to withdraw allocations due to bad > behaviour as much as many of us would like it to be. Failure to > maintain valid contact details however is within the purview of the > RIRs. > > If you are being attacked, report the attack to your LEA. Let the > LEA's maintain intellegence on which networks are permitting attacks > to be launched from their address space. They can work with LEA > in the network's juristiction to get the attacks stops and offenders > prosecuted. LEA's can in theory also get courts to issue orders > to filter offending address blocks by all ISP's in their juristiction. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From alh-ietf at tndh.net Mon Aug 11 03:36:36 2014 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 11 Aug 2014 11:36:36 +0800 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: References: <53E7A18B.7020601@winterei.se> <20140811010418.E7A2A1CAC27C@rock.dv.isc.org> Message-ID: <090001cfb515$77562a30$66027e90$@tndh.net> I have found the scaling is better if you make it the abusing providers problem to contact you. Whenever a range gets blocked, the bounce message tells the mail originator to take their money and find a new hosting provider that does not support/tolerate spam. When legitimate originators have contacted their provider about that message, the sources that were inadvertently hosting the abuse are happy to find out more so they can resolve the problem, and they provide a working contact in the process, even if the registered one fails. The down side is that it requires the legitimate originator to pay attention to the bounce and decide they want to take action. The hope is that eventually more money will flow toward those hosting providers that are diligent about resolving issues. Tony > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Suresh > Ramasubramanian > Sent: Monday, August 11, 2014 11:04 AM > To: Mark Andrews > Cc: goemon at anime.net; nanog at nanog.org > Subject: Re: Dealing with abuse complaints to non-existent contacts > > Good luck getting action from foreign LE through the mlat system > > You might get a response, oh, in the next two years or so. IF you can find > local LE willing to push the case forward. > > Beyond that while RIRs are not the internet police they do owe it to the > community to be more vigilant on dud contact addresses, and also do a > lot^W bit more due diligence when allocating IP space, and when appointing > LIRs. > On 11-Aug-2014 6:37 am, "Mark Andrews" wrote: > > > > > In message , > Owen > > DeLong > > writes: > > > > > > On Aug 10, 2014, at 1:28 PM, goemon at anime.net wrote: > > > > > > > On Mon, 11 Aug 2014, Paul S. wrote: > > > >> It would appear you've done your part in trying to reach out (and > > > >> subsequently failed), so the next step to go is dropping all > > > >> traffic > > from > > > >> it. > > > >> > > > >> Nothing wrong with trying to protect your own customer from > > > >> people who cannot be bothered to do their own due diligence. > > > > > > > > It would be nice if allocations would be revoked due to > > > > invalid/fake contact info. > > > > > > > > -Dan > > > > > > I kind of agree, but past efforts in this regard have not met with > > > consensus from the ARIN community. > > > > > > If you believe this to be the case, I suggest putting it into > > > template format and submitting to policy at arin.net. > > > > > > I'm happy to help if you would like. Subscribing to arin-ppml will > > > allow you to participate in the community discussion of the policy > proposal. > > > > > > Owen > > > > It really isn't the RIR's job to withdraw allocations due to bad > > behaviour as much as many of us would like it to be. Failure to > > maintain valid contact details however is within the purview of the > > RIRs. > > > > If you are being attacked, report the attack to your LEA. Let the > > LEA's maintain intellegence on which networks are permitting attacks > > to be launched from their address space. They can work with LEA in > > the network's juristiction to get the attacks stops and offenders > > prosecuted. LEA's can in theory also get courts to issue orders to > > filter offending address blocks by all ISP's in their juristiction. > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > From ops.lists at gmail.com Mon Aug 11 04:13:17 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 11 Aug 2014 09:43:17 +0530 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: <090001cfb515$77562a30$66027e90$@tndh.net> References: <53E7A18B.7020601@winterei.se> <20140811010418.E7A2A1CAC27C@rock.dv.isc.org> <090001cfb515$77562a30$66027e90$@tndh.net> Message-ID: On Mon, Aug 11, 2014 at 9:06 AM, Tony Hain wrote: > I have found the scaling is better if you make it the abusing providers problem to contact you. It scales BEAUTIFULLY .. until your peer in support starts to yell at you about the off the scale ticket volume you've managed to dump on him with your nullroute. In other words, your abusing provider isn't as likely to contact you as your own customers, after they suddenly have a lot of users unable to access their service. > Whenever a range gets blocked, the bounce message tells the mail originator to take their money and find a new hosting provider that does not support/tolerate spam. I thought we were actually talking about filtering random ssh attempts? Oh, ok - so this discussion drifted into SMTP. Good - what I said earlier applies earlier, in spades - end users will start to contact your peers on the postmaster desk. So - block by all means, but be well prepared to handle the ticket volume (and always bear in mind your role is ALSO to deliver legit mail to your users). And for god's sake provide proper error messages with a URL that gives sufficient information as to why there's a block in the first place. > The down side is that it requires the legitimate originator to pay attention to the bounce and decide they want to take action. I would suggest a trip to a future MAAWG meeting. --srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From mksmith at mac.com Mon Aug 11 05:19:15 2014 From: mksmith at mac.com (Michael Smith) Date: Sun, 10 Aug 2014 22:19:15 -0700 Subject: 2015 NANOG Election Announcement Message-ID: <580E1339-632A-4ADC-91E9-049627E7590D@mac.com> Hello NANOGers! We are once again approaching the annual NANOG election and appointment time. In addition to the Call for Nominations message, the following is an overview and timeline of the actual election process. We encourage those in the community who are not currently NANOG Members to consider becoming one and to consider standing for a position within our leadership. Through membership and voting, you will be an active participant in directing all NANOG activities. Only NANOG members are eligible to vote and serve in the 2014 election process. Go to https://www.nanog.org/membership/join to become a Member. If you care about NANOG and think you would like to take a turn at volunteering your time to help make it better please consider joining as a member and running for a position. If you know someone else that you believe would be interested, nominate them by completing the Online Process at https://www.bigpulse.com/97752/signin. Any questions should be submitted to elections at nanog.org. As NANOG continues to evolve, our Committees will continue to play an increasingly important role in our success. By joining now, you can be an integral part of the process. For more information about the role of any Committee, or to find out more about what's involved in being a Committee member, please consult the current NANOG Bylaws or follow the links above to the Committee Member Responsibilities documents. Best regards, Michael K. Smith On behalf of the NANOG Board of Directors Election Timeline Call for Board Member nominations August 8, 2014 Call for Program and Communications Committees nominations August 8, 2014 Bylaws discussed, proposed changes explored August 25, 2014 Board Member nominations close September 17, 2014 Bylaws amendments posted September 15, 2014 Ballot approved September 18, 2014 Voting for the 2014 Board opens at 8:00AM ET October 6, 2014 Program and Communications Committees nominations close at 12:00PM ET October 8, 2014 Voting for the 2014 Board closes at 12:00PM ET October 8, 2014 Board Appointment of New Committee Members October 8, 2014 From gabriel.j.marais at gmail.com Mon Aug 11 06:30:19 2014 From: gabriel.j.marais at gmail.com (Gabriel Marais) Date: Mon, 11 Aug 2014 08:30:19 +0200 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: References: <53E7A18B.7020601@winterei.se> <7DB563EA-ED6B-4C1A-836F-9BBAFA8E1C50@pch.net> <0C718BDC-712D-472F-B135-076DF8FDF692@virtualized.org> Message-ID: <53E862FB.5090500@gmail.com> From rsk at gsp.org Mon Aug 11 08:32:44 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 11 Aug 2014 04:32:44 -0400 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: <40B688CA-733F-4C48-99C2-1AB16E89DB7F@xi.uz> References: <40B688CA-733F-4C48-99C2-1AB16E89DB7F@xi.uz> Message-ID: <20140811083244.GA11613@gsp.org> On Sun, Aug 10, 2014 at 11:25:36PM +0500, Alexander Merniy wrote: > Move ssh to a non-standart port + fail2ban - best solution. No, it is not. The best solution is to enumerate the ranges from which legitimate ssh connections will originate and firewall *everything* else. Yes, this means (gasp! horror!) actually looking at your own logs and understanding what they tell you, but anyone capable of using "grep", "sort", "uniq" et.al. should be able to do that. The second-best solution is to enumerate the ranges from which legitimate ssh connections will never originate and firewall those. The Spamhaus DROP list is a good starting place for everyone. The Okean listings of Chinese and Korean network space are good second stops. And ipdeny.com *was* a good third stop, for which I haven't found an equally-usable replacement just yet. Both of these are proactive approaches that -- if used properly and well-maintained -- may largely eliminate the need to fiddle around with reactive approaches like fail2ban. They also work with other ports/protocols/services, e.g., IMAPS. ---rsk From johnl at iecc.com Mon Aug 11 15:28:56 2014 From: johnl at iecc.com (John Levine) Date: 11 Aug 2014 15:28:56 -0000 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: Message-ID: <20140811152856.2422.qmail@joyce.lan> >RBL / BGP blackholes based on bad registration info? That's sort of what the Spamhaus DROP list does. Many (most?) of the entries are ancient abandoned allocations that have been hijacked by crooks. From charles at thefnf.org Mon Aug 11 17:48:34 2014 From: charles at thefnf.org (charles at thefnf.org) Date: Mon, 11 Aug 2014 12:48:34 -0500 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: References: Message-ID: On 2014-08-10 10:19, Gabriel Marais wrote: > Hi Nanog > > I'm curious. > > I have been receiving some major ssh brute-force attacks coming from > random > hosts in the 116.8.0.0 - 116.11.255.255 network. I have sent a > complaint to > the e-mail addresses obtained from a whois query on one of the IP > Addresses. Did they have a dedicated abuse e-mail? Did you receive an automated confirmation (which generally means the communication went into some sort of ticket queue as opposed to $random_employee_malbox_who_has_moved_on . How did you format the e-mail? What information did you provide? (Folks here, what do you look for in an abuse complaint to take it seriously)? I imagine many here have template/ticket systems for abuse communications? What info do you ask for in those communications? > > My e-mail bounced back from both recipients. Once being rejected by > filter > and the other because the e-mail address doesn't exist. I would have > thought that contact details are rather important to be up to date, or > not? Yes. For operators who actually care about running their networks and being good citizens. At least that's my opinion. > > Besides just blocking the IP range on my firewall, I was wondering what > others would do in this case? > Well of course fail2ban is always good. My personal preference is only expose HTTPS/SMTPS/IMAPS to the world. Zero management traffic on the front channel. SSH is only possible once you have connected to the VPN (which is running on 443 on another IP and is accessible without any firewall restrictions). From fmartin at linkedin.com Mon Aug 11 22:52:09 2014 From: fmartin at linkedin.com (Franck Martin) Date: Mon, 11 Aug 2014 22:52:09 +0000 Subject: Dealing with abuse complaints to non-existent contacts In-Reply-To: References: Message-ID: <76C2208B-B923-44A2-8442-00358556CBB7@linkedin.com> On Aug 10, 2014, at 8:19 AM, Gabriel Marais wrote: > Hi Nanog > > I'm curious. > > I have been receiving some major ssh brute-force attacks coming from random > hosts in the 116.8.0.0 - 116.11.255.255 network. I have sent a complaint to > the e-mail addresses obtained from a whois query on one of the IP Addresses. > > My e-mail bounced back from both recipients. Once being rejected by filter > and the other because the e-mail address doesn't exist. I would have > thought that contact details are rather important to be up to date, or not? > > Besides just blocking the IP range on my firewall, I was wondering what > others would do in this case? > $ host -t txt 0.0.8.116.abuse-contacts.abusix.org 0.0.8.116.abuse-contacts.abusix.org descriptive text "18977164171 at 189.cn" However, I don?t see an mnt-irt: field which is mandatory for APNIC records updated/created after 2010 (unfortunately this object was last updated in 2007). So I would start by pointing to APNIC that no such entry exist and as this network is of importance for the community, the addition of an abuse/IRT POC would be beneficial for everyone and if they could help, this would be greatly appreciated. https://www.apnic.net/services/manage-resources/abuse-contacts But that?s the theory... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From colton.conor at gmail.com Tue Aug 12 00:22:05 2014 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 11 Aug 2014 19:22:05 -0500 Subject: Mikrotik RouterBoard and Ubiquiti Networks Routing and Switching Solutions Message-ID: I am interested to hear opinions on Mikrotik and Ubiquiti Networks routing and switching products. I know both hardware providers are widely deployed in WISP networks, but I am less interested in their wireless solutions and more in their wired products. I know most of their switches and routers are software based, but that might not necessarily be a bad thing since everyone is going to SDN anyways. Their products are 1/10th or less of the cost of the equivalent Cisco/Juniper products. How stable and feature rich are both of their platforms? How do both of their command line interfaces compare to Cisco or Juniper? Is it easy to train a Cisco tech how to use a Mikrotik or Ubiquiti Networks product? *Ubiquiti Networks software is based on a version of Vyatta I believe. As many of you know Vyatta was bought by Brocade. I have heard that Vyatta is very Juniper OS like. *Ubiquiti just release a line of switches that have an amazing price and seem to support wire speed switching. Their EdgeRouter is supposedly faster than Mikrotiks solutions. They are also traded on the stock market, and seem to be doing well as a company. http://www.ubnt.com/products/ Mikrotik also seems to make routers and switches. I am not sure what their software is based on, but it does support advanced features such as MPLS. Not sure about their switches, but they seem to be dirt cheap! What is their command line interface like? I couldn't find any financial information on this company, but they seem to be located in Latvia? http://routerboard.com/ Does anyone have any meaningful insight to both companies? Why haven't they made a dent in the switching and router market with their amazing price points? Am I missing something here? From faisal at snappytelecom.net Tue Aug 12 00:45:57 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Tue, 12 Aug 2014 00:45:57 +0000 (GMT) Subject: Mikrotik RouterBoard and Ubiquiti Networks Routing and Switching Solutions In-Reply-To: References: Message-ID: <1653697751.179034.1407804357487.JavaMail.zimbra@snappytelecom.net> Should we say, both products are an acquired taste ? :) Are they perfect, no, but then what is ? Do they do the Job, yes. Do they work well ? yes. Do they do everything under the sun ? No... but then what does ? Each has it's own set of peculiarities. However, what actually sets them apart from everything else is, their power consumption, Environmental Tolerance, performance and flexibility. While they are not Consumer Grade devices, and definitely need a fair amount of Network/Routing/Tech knowledge to configure and deploy properly, some will argue that they are not Carrier Grade Either.. However they are a great 'tool' in a service provider's network. When used properly, and configured properly, they provide a un-comparable advantage vs most other alternatives in the market place. To use them, and deploy them widely, one has to feel comfortable is dealing with 'perceived opensource' products and deal with "you cannot have an immediate fix for your problem ". Once you get comfortable in understanding the nature of the hardware / software platform along with the choices available, it is hard to justify purpose built appliances which carry a hefty price tag ( which is typically justified / justifiable by the amount of hand-holding / support / and dumbed down configuration interface included with them). We consider these devices to be a good combination of open-source software with reliable, mass produced hardware, without a large price tag.. Regards Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Colton Conor" > To: "NANOG" > Sent: Monday, August 11, 2014 8:22:05 PM > Subject: Mikrotik RouterBoard and Ubiquiti Networks Routing and Switching Solutions > > I am interested to hear opinions on Mikrotik and Ubiquiti Networks routing > and switching products. I know both hardware providers are widely deployed > in WISP networks, but I am less interested in their wireless solutions and > more in their wired products. > > I know most of their switches and routers are software based, but that > might not necessarily be a bad thing since everyone is going to SDN > anyways. Their products are 1/10th or less of the cost of > the equivalent Cisco/Juniper products. > > How stable and feature rich are both of their platforms? How do both of > their command line interfaces compare to Cisco or Juniper? Is it easy to > train a Cisco tech how to use a Mikrotik or Ubiquiti Networks product? > > > *Ubiquiti Networks software is based on a version of Vyatta I believe. As > many of you know Vyatta was bought by Brocade. I have heard that Vyatta is > very Juniper OS like. *Ubiquiti just release a line of switches that have > an amazing price and seem to support wire speed switching. Their EdgeRouter > is supposedly faster than Mikrotiks solutions. They are also traded on the > stock market, and seem to be doing well as a company. > http://www.ubnt.com/products/ > > Mikrotik also seems to make routers and switches. I am not sure what their > software is based on, but it does support advanced features such as MPLS. > Not sure about their switches, but they seem to be dirt cheap! What is > their command line interface like? I couldn't find any financial > information on this company, but they seem to be located in Latvia? > http://routerboard.com/ > > Does anyone have any meaningful insight to both companies? Why haven't they > made a dent in the switching and router market with their amazing price > points? Am I missing something here? > From rubensk at gmail.com Tue Aug 12 00:48:57 2014 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 11 Aug 2014 21:48:57 -0300 Subject: Mikrotik RouterBoard and Ubiquiti Networks Routing and Switching Solutions In-Reply-To: References: Message-ID: On Mon, Aug 11, 2014 at 9:22 PM, Colton Conor wrote: > I am interested to hear opinions on Mikrotik and Ubiquiti Networks routing > and switching products. I know both hardware providers are widely deployed > in WISP networks, but I am less interested in their wireless solutions and > more in their wired products. > > I know most of their switches and routers are software based, but that > might not necessarily be a bad thing since everyone is going to SDN > anyways. Their products are 1/10th or less of the cost of > the equivalent Cisco/Juniper products. > Ubiquiti routers use Cavium chips so they are not 100% software solutions, having a bit of programmable hardware support. Although most Mikrotik products are 100% software-based, their flagship router nowadays, CCR, also has similar hardware acceleration from Tilera. > How stable and feature rich are both of their platforms? How do both of > their command line interfaces compare to Cisco or Juniper? Is it easy to > train a Cisco tech how to use a Mikrotik or Ubiquiti Networks product? > Mikrotik RouterOS is very unstable, notably on dynamic routing scenarios. Wireless and BRAS-type solutions under RouterOS work fine, but routing has been a challenge since they moved from Quagga to XORP due to licensing issues; Mikrotik uses a lot of open source but published very little code, drawing extensive criticism from the open-source community. Although it's unknown to me if they are still using XORP, whatever they use still has flaws. Mikrotik CLI resembles Cisco a bit, Ubiquiti resembles Juniper a lot. It's easier to train a Cisco tech to use Mikrotik than to use Ubiquiti, but me and most networking people I know starts liking the Juniper/Ubiquiti/Vyatta style as soon as they discover "commit rollback" and similar features. > *Ubiquiti Networks software is based on a version of Vyatta I believe. As > many of you know Vyatta was bought by Brocade. I have heard that Vyatta is > very Juniper OS like. VyOS is the Vyatta fork that was used to create EdgeOS, the Ubiquiti version of it. VyOS + GUI + Hardware-offload + a feature or two = EdgeOS. The VyOS fork occurred due to Brocade new ideas for the product, and VyOS on x86 hardware is also an alternative for cheap and reliable replacement of Juniper/Cisco gear. Ubiquiti seized this opportunity and hired two, or something near, developers from Vyatta that also have not liked Brocade guidance of the project. > *Ubiquiti just release a line of switches that have > an amazing price and seem to support wire speed switching. I've only used their routers so I can't comment on their switches... their feature set looks good, but that's all I can say. > Their EdgeRouter > is supposedly faster than Mikrotiks solutions. Mikrotik argues that CCR is faster... they use a 72-core architecture that is actually a "marketecture" since packets usually use only the cores that belong to the port they entered, making the uplink ports their bottleneck. > > Mikrotik also seems to make routers and switches. I am not sure what their > software is based on, Linux kernel with some open source and some not open source additions. > but it does support advanced features such as MPLS. > Not sure about their switches, but they seem to be dirt cheap! Mikrotik switches are just home-gateway class, stay away from any serious use. > What is > their command line interface like? I couldn't find any financial > information on this company, but they seem to be located in Latvia? > They started with ISP wireless software for at the time commodity radios and moved to making their own gear. Their products have good market penetration in Eastern Europe and in Brazil, where their price points enabled lots of small operators to build wireless networks. Does anyone have any meaningful insight to both companies? Why haven't they > made a dent in the switching and router market with their amazing price > points? Am I missing something here? > Mikrotik people is incredibly bad at relating to other people; they always try to prove that customers that point failures are stupid and they(Mikrotik) are right. Most buyers prefer to have someone that will commit to solve problems instead of denying them. Their support forum is public and you will find many examples of this behaviour there. Rubens From tony at wicks.co.nz Tue Aug 12 01:05:41 2014 From: tony at wicks.co.nz (Tony Wicks) Date: Tue, 12 Aug 2014 13:05:41 +1200 Subject: Mikrotik RouterBoard and Ubiquiti Networks Routing and Switching Solutions In-Reply-To: References: Message-ID: <00ad01cfb5c9$89d0f320$9d72d960$@wicks.co.nz> Personally I have a simple matrix for routing and switching, if the customer can afford it I use Juniper, if they can afford it and really want Cisco then I will use Cisco. If the customer wants to put something in that will "just work" for years to come I use Juniper. If they want the cheapest routing solution that will do the job I will use MikroTik. If I was building a service provider that was not huge out of my own money then I would use Juniper switches and MikroTik routing/BNG. I have actually found MikroTik to be very stable and scalable over the years and I have had great support from them. In the early years (10 years ago) I saw some BGP instability under load, but not for several years. MikroTik's also make a great CPE device (Ethernet only). I have not used MikroTik switches so can't comment on them. cheers > I am interested to hear opinions on Mikrotik and Ubiquiti Networks > routing and switching products. I know both hardware providers are > widely deployed in WISP networks, but I am less interested in their > wireless solutions and more in their wired products. > > I know most of their switches and routers are software based, but that > might not necessarily be a bad thing since everyone is going to SDN > anyways. Their products are 1/10th or less of the cost of the > equivalent Cisco/Juniper products. > Ubiquiti routers use Cavium chips so they are not 100% software solutions, having a bit of programmable hardware support. Although most Mikrotik products are 100% software-based, their flagship router nowadays, CCR, also has similar hardware acceleration from Tilera. From eric.harrison at cascadetech.org Tue Aug 12 01:42:31 2014 From: eric.harrison at cascadetech.org (Eric Harrison) Date: Mon, 11 Aug 2014 18:42:31 -0700 Subject: Mikrotik RouterBoard and Ubiquiti Networks Routing and Switching Solutions In-Reply-To: References: Message-ID: I ported one of our Juniper SRX configs to an EdgeRouter Lite and it was a relatively painless experience. I benchmarked the end results and it would do ~1gbps without breaking much of a sweat. Not bad at all for a <$100 box. We keep some on the shelf, just in case of an emergency. At that price, why not? No large scale and/or long term deployments as of yet, which is where the wheat is separated from the chaff. On Mon, Aug 11, 2014 at 5:22 PM, Colton Conor wrote: > I am interested to hear opinions on Mikrotik and Ubiquiti Networks routing > and switching products. I know both hardware providers are widely deployed > in WISP networks, but I am less interested in their wireless solutions and > more in their wired products. > > I know most of their switches and routers are software based, but that > might not necessarily be a bad thing since everyone is going to SDN > anyways. Their products are 1/10th or less of the cost of > the equivalent Cisco/Juniper products. > > How stable and feature rich are both of their platforms? How do both of > their command line interfaces compare to Cisco or Juniper? Is it easy to > train a Cisco tech how to use a Mikrotik or Ubiquiti Networks product? > > > *Ubiquiti Networks software is based on a version of Vyatta I believe. As > many of you know Vyatta was bought by Brocade. I have heard that Vyatta is > very Juniper OS like. *Ubiquiti just release a line of switches that have > an amazing price and seem to support wire speed switching. Their EdgeRouter > is supposedly faster than Mikrotiks solutions. They are also traded on the > stock market, and seem to be doing well as a company. > http://www.ubnt.com/products/ > > Mikrotik also seems to make routers and switches. I am not sure what their > software is based on, but it does support advanced features such as MPLS. > Not sure about their switches, but they seem to be dirt cheap! What is > their command line interface like? I couldn't find any financial > information on this company, but they seem to be located in Latvia? > http://routerboard.com/ > > Does anyone have any meaningful insight to both companies? Why haven't they > made a dent in the switching and router market with their amazing price > points? Am I missing something here? > -- Eric Harrison Network Services Cascade Technology Alliance / Multnomah Education Service District office: 503-257-1554 cell: 971-998-6249 NOC 503-257-1510 From sunyucong at gmail.com Tue Aug 12 02:03:02 2014 From: sunyucong at gmail.com (Yucong Sun) Date: Tue, 12 Aug 2014 10:03:02 +0800 Subject: Mikrotik RouterBoard and Ubiquiti Networks Routing and Switching Solutions In-Reply-To: References: Message-ID: EdgeRouter only support "hardware accelerated" routing with limited features. If you start playing with firewall filters, gre tunnels etc you would have to be careful about how they decrease your performance. I personally tried to use a edgerouter to replace my j2350 with 300mbps traffic. I first tried it at home to replace a NS5GT, But some not-so-obvious problem has made me lost patient during the trail. My plan to use it to replace j2350 is shelved for now.. I personally feel like at this level of traffic, A entry level of linux server (like dell r210) with adequate domain knowledge is the best combination. It would happily do most stuff you throw at it, if you know how to use it. Entry level hardware solution tries to hide details from user, because they want to target clueless consumers, but it sounds like a PITA for me. If I had to learn new stuff, i better spend my time on some real industrial stuff (like m7i/m10i ). From rubensk at gmail.com Tue Aug 12 02:15:56 2014 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 11 Aug 2014 23:15:56 -0300 Subject: Mikrotik RouterBoard and Ubiquiti Networks Routing and Switching Solutions In-Reply-To: References: Message-ID: > > I personally feel like at this level of traffic, A entry level of linux > server (like dell r210) with adequate domain knowledge is the best > combination. It would happily do most stuff you throw at it, if you know > how to use it. Entry level hardware solution tries to hide details from > user, because they want to target clueless consumers, but it sounds like a > PITA for me. If I had to learn new stuff, i better spend my time on some > real industrial stuff (like m7i/m10i ). > General purpose servers are usually good performers, but more network-centric x86 hardware is available, such as: http://www.serveru.us/en/ And running VyOS on those servers, although requiring to learn some new stuff, might prove handy due to nice features in device management. Forgetting to add command lines to /etc/rc.d start-up files is a common cause for issues using general purpose operating systems, and you will its CLI very close to the real industrial stuff. Rubens From swmike at swm.pp.se Tue Aug 12 06:45:20 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 12 Aug 2014 08:45:20 +0200 (CEST) Subject: Mikrotik RouterBoard and Ubiquiti Networks Routing and Switching Solutions In-Reply-To: References: Message-ID: On Mon, 11 Aug 2014, Colton Conor wrote: > How stable and feature rich are both of their platforms? How do both of I have played around with the Edgerouter ER-5. It's a fairly immature product compared to Cisco and Juniper. One of the bigger problems is that they don't really release fixes for earlier versions, instead they keep releasing new versions, combining new features and bug fixes in the same new release. My recommendation is to read the forums they have where people do bug reporting, and after 15-30 minutes I think you will have a fairly good idea about the product, and if it might suit you. For a simpler setup with static IPv4/IPv6 routing and perhaps even OSPF, that wasn't touched much after installation, I'd say it's fine. It's a powerful little box. It has some features most home gateways do not, and it lacks some features some of the highend ones have. They're attractively priced, buy one and try it out! -- Mikael Abrahamsson email: swmike at swm.pp.se From halflife4 at gmx.com Tue Aug 12 14:23:38 2014 From: halflife4 at gmx.com (Toney Mareo) Date: Tue, 12 Aug 2014 16:23:38 +0200 Subject: [HFC] pooling modems in layer2 Message-ID: Hello I think it's kind of an isp secret but I would be curious how do people distribute modems to pools before they would even reach the actual IP network so on layer2: http://dl.packetstormsecurity.net/papers/evaluation/docsis/Service_Distribution.jpg For this I would like to get some clarification because I do not work in the telco industry. As I can figure out of the docsis, cablelabs documents. The CMTS device is connected to the coax segments through fiber. Therefore one could say that the "modem facing" side is a fiber optic interface but it's not 1000 Base-FX, not a regular Ethernet over fiber. It sends signals through a broad range of frequencies. So what I would like to accomplish to provide a different pool of dhcp servers, which provides different config file, tod server, router, dns etc. infos to the modems but to do all this in Layer2. I don't have hands on experience with CMTS-es but I would think that they are able to pool clients by MACs and able to send eg 500 clients to DHCP server1 and the other 1500 to DHCP server2 before they would even get an IP, so I talking of pure layer2 here! Let's say if the CMTS device does not support this, what are the other options for routing layer2 traffic coming out of the CMTS? If I would know more about the device I would say that put a linuxbox after it (on the ISP facing nic) and mark the packets going out with arptables/ebtables then send them out of different nics to different dhcp servers. Any suggestions are welcome. From lists at mtin.net Tue Aug 12 15:15:44 2014 From: lists at mtin.net (Justin Wilson) Date: Tue, 12 Aug 2014 11:15:44 -0400 Subject: Mikrotik RouterBoard and Ubiquiti Networks Routing and Switching Solutions In-Reply-To: References: Message-ID: Another thing to consider is how you feel about the configuration. Mikrotik has a more polished GUI and command subset. UBNT is still working things out. A lot of what you have to to do with the UBNT line has to still be done in command line. If you are cool with that then not a big deal. The RouterOS is a pretty mature product and has a good backing of forums, wiki, and other things. Not saying uBNT doesn?t, just not as mature. Justin -- Justin Wilson http://www.mtin.net Managed Services ? xISP Solutions ? Data Centers http://www.thebrotherswisp.com Podcast about xISP topics On 8/11/14, 8:22 PM, "Colton Conor" wrote: >I am interested to hear opinions on Mikrotik and Ubiquiti Networks routing >and switching products. I know both hardware providers are widely deployed >in WISP networks, but I am less interested in their wireless solutions and >more in their wired products. > >I know most of their switches and routers are software based, but that >might not necessarily be a bad thing since everyone is going to SDN >anyways. Their products are 1/10th or less of the cost of >the equivalent Cisco/Juniper products. > >How stable and feature rich are both of their platforms? How do both of >their command line interfaces compare to Cisco or Juniper? Is it easy to >train a Cisco tech how to use a Mikrotik or Ubiquiti Networks product? > > >*Ubiquiti Networks software is based on a version of Vyatta I believe. As >many of you know Vyatta was bought by Brocade. I have heard that Vyatta is >very Juniper OS like. *Ubiquiti just release a line of switches that have >an amazing price and seem to support wire speed switching. Their >EdgeRouter >is supposedly faster than Mikrotiks solutions. They are also traded on the >stock market, and seem to be doing well as a company. >http://www.ubnt.com/products/ > >Mikrotik also seems to make routers and switches. I am not sure what their >software is based on, but it does support advanced features such as MPLS. >Not sure about their switches, but they seem to be dirt cheap! What is >their command line interface like? I couldn't find any financial >information on this company, but they seem to be located in Latvia? >http://routerboard.com/ > >Does anyone have any meaningful insight to both companies? Why haven't >they >made a dent in the switching and router market with their amazing price >points? Am I missing something here? > From ops.lists at gmail.com Tue Aug 12 16:10:55 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 12 Aug 2014 21:40:55 +0530 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today Message-ID: 512K routes, here we come. Lots of TCAM based routers suddenly become really expensive doorstops. Maybe time to revisit this old 2007 nanog thread? http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=99870;page=1;sb=post_latest_reply;so=ASC;mh=25;list=nanog FYI nanog - https://puck.nether.net/pipermail/outages/2014-August/007091.html [outages] Major outages today, not much info at this time Teun Vink teun at teun.tv Tue Aug 12 11:42:05 EDT 2014 On di, 2014-08-12 at 15:20 +0000, Hoyle Anderson (AM) via Outages wrote: > I know this isn?t much help, but there are major problems with > multiple ISPs since around 4-5 AM EST. I really don?t have much > detail, but I have sites that are unreachable from some providers. > Looks like Comcast, level3, ATT, cogent, etc. > > > > So, it?s probably not just you, but I?m afraid I don?t know who it is. > I heard one report of a datacenter outage. > Hi, Some routing tables hit 512K routes today. Some old hardware and software can't handle that and either crash or ignore newly learned routes. So this may cause some disturbances in the force. HTH, Teun ----------------- From xxnog at ledeuns.net Tue Aug 12 16:44:43 2014 From: xxnog at ledeuns.net (Denis Fondras) Date: Tue, 12 Aug 2014 18:44:43 +0200 Subject: Mikrotik RouterBoard and Ubiquiti Networks Routing and Switching Solutions In-Reply-To: References: Message-ID: <53EA447B.8090007@ledeuns.net> Le 12/08/2014 17:15, Justin Wilson a ?crit : > Another thing to consider is how you feel about the configuration. > Mikrotik has a more polished GUI and command subset. UBNT is still > working things out. A lot of what you have to to do with the UBNT line > has to still be done in command line. If you are cool with that then not > a big deal. The RouterOS is a pretty mature product and has a good > backing of forums, wiki, and other things. Not saying uBNT doesn?t, just > not as mature. > May we discuss IPv6 support ? Last time I checked, UBNT was lagging behind... Denis From rubensk at gmail.com Tue Aug 12 16:53:41 2014 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 12 Aug 2014 13:53:41 -0300 Subject: Mikrotik RouterBoard and Ubiquiti Networks Routing and Switching Solutions In-Reply-To: <53EA447B.8090007@ledeuns.net> References: <53EA447B.8090007@ledeuns.net> Message-ID: On Tue, Aug 12, 2014 at 1:44 PM, Denis Fondras wrote: > Le 12/08/2014 17:15, Justin Wilson a ?crit : > > Another thing to consider is how you feel about the configuration. > > Mikrotik has a more polished GUI and command subset. UBNT is still > > working things out. A lot of what you have to to do with the UBNT line > > has to still be done in command line. If you are cool with that then not > > a big deal. The RouterOS is a pretty mature product and has a good > > backing of forums, wiki, and other things. Not saying uBNT doesn?t, just > > not as mature. > > > > May we discuss IPv6 support ? Last time I checked, UBNT was lagging > behind... > UBNT wireless operating system, AirOS, is lagging behind. UBNT router operating system, EdgeOS, has extensive IPv6 support in the command line interface. GUI has some IPv6 support ( http://wiki.ubnt.com/IPv6_-_GUI_Options). Rubens From warren at kumari.net Tue Aug 12 17:47:05 2014 From: warren at kumari.net (Warren Kumari) Date: Tue, 12 Aug 2014 13:47:05 -0400 Subject: Mikrotik RouterBoard and Ubiquiti Networks Routing and Switching Solutions In-Reply-To: References: Message-ID: On Mon, Aug 11, 2014 at 8:22 PM, Colton Conor wrote: > I am interested to hear opinions on Mikrotik and Ubiquiti Networks routing > and switching products. I know both hardware providers are widely deployed > in WISP networks, but I am less interested in their wireless solutions and > more in their wired products. > Probably not the experiences you are looking for, but I replaced my home CPE (a Netscreen SSG) with a Ubiquiti Edge Router -- there was a very small learning curve (their CLI is different -- feels like somewhat less polished JunOS to me, some simply things like completion don't work), but after 15 minutes or so was all set. Sine then it has remained perfectly stable, has a pretty GUI in case you want a quick graph of bandwith, etc. We have also used them when building the IETF network to start pre-announcing the space (we go to the location a few weeks early, test the circuits and BGP peerings, and then start announcing the space - this helps some with some geo-location systems). We have also used them when cutting over the guest rooms (when we cut over hotel guest rooms to the IETF infrastructure and space, we sometimes continue to route and NAT the hotels (RFC1918) space for a while so that folk who still have a DHCP address can continue to work until their lease expires). W > I know most of their switches and routers are software based, but that > might not necessarily be a bad thing since everyone is going to SDN > anyways. Their products are 1/10th or less of the cost of > the equivalent Cisco/Juniper products. > > How stable and feature rich are both of their platforms? How do both of > their command line interfaces compare to Cisco or Juniper? Is it easy to > train a Cisco tech how to use a Mikrotik or Ubiquiti Networks product? > > > *Ubiquiti Networks software is based on a version of Vyatta I believe. As > many of you know Vyatta was bought by Brocade. I have heard that Vyatta is > very Juniper OS like. *Ubiquiti just release a line of switches that have > an amazing price and seem to support wire speed switching. Their EdgeRouter > is supposedly faster than Mikrotiks solutions. They are also traded on the > stock market, and seem to be doing well as a company. > http://www.ubnt.com/products/ > > Mikrotik also seems to make routers and switches. I am not sure what their > software is based on, but it does support advanced features such as MPLS. > Not sure about their switches, but they seem to be dirt cheap! What is > their command line interface like? I couldn't find any financial > information on this company, but they seem to be located in Latvia? > http://routerboard.com/ > > Does anyone have any meaningful insight to both companies? Why haven't they > made a dent in the switching and router market with their amazing price > points? Am I missing something here? From charles at thefnf.org Tue Aug 12 17:51:23 2014 From: charles at thefnf.org (charles at thefnf.org) Date: Tue, 12 Aug 2014 12:51:23 -0500 Subject: [HFC] pooling modems in layer2 In-Reply-To: References: Message-ID: On 2014-08-12 09:23, Toney Mareo wrote: > Hello > > I think it's kind of an isp secret but I would be curious how do > people distribute modems to pools before they would even reach the > actual IP network so on layer2: > > http://dl.packetstormsecurity.net/papers/evaluation/docsis/Service_Distribution.jpg > > > For this I would like to get some clarification because I do not work > in the telco industry. As I can figure out of the docsis, cablelabs > documents. The CMTS device is connected to the coax segments through > fiber. Therefore one could say that the "modem facing" side is a fiber > optic interface but it's not 1000 Base-FX, not a regular Ethernet over > fiber. It sends signals through a broad range of frequencies. Sounds about right to me. > > So what I would like to accomplish to provide a different pool of dhcp > servers, which provides different config file, tod server, router, dns > etc. infos to the modems but to do all this in Layer2. > Why? Do you have a bunch of cable modems and a CMTS? If so, does the documentation not cover this? Or are you trying to hack your cable modem/cable provider? > I don't have hands on experience with CMTS-es but I would think that > they are able to pool clients by MACs and able to send eg 500 clients > to DHCP server1 and the other 1500 to DHCP server2 before they would > even get an IP, so I talking of pure layer2 here! > > Let's say if the CMTS device does not support this, what are the other > options for routing layer2 traffic coming out of the CMTS? Um. Probably via RADIUS and via VLAN assignment? If I would > know more about the device I would say that put a linuxbox after it > (on the ISP facing nic) and mark the packets going out with > arptables/ebtables then send them out of different nics to different > dhcp servers. Most likely they just use VLANs. This rack of CMTS gear is on port 22 of the agg switch, vlan 2 and ip helper is set for vlan 2 to the desired dhcp server (which is most likely an HA floating IP if not a full blown VIP etc). From hank at efes.iucc.ac.il Tue Aug 12 18:02:47 2014 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 12 Aug 2014 21:02:47 +0300 (IDT) Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: On Tue, 12 Aug 2014, Suresh Ramasubramanian wrote: Many don't need to buy anything new. Just follow the instructions here: http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switche$ We did this in the 1st week of June. Problem solved. -Hank > 512K routes, here we come. Lots of TCAM based routers suddenly become > really expensive doorstops. > > Maybe time to revisit this old 2007 nanog thread? > > http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=99870;page=1;sb=post_latest_reply;so=ASC;mh=25;list=nanog > > FYI nanog - https://puck.nether.net/pipermail/outages/2014-August/007091.html > > [outages] Major outages today, not much info at this time > > Teun Vink teun at teun.tv > Tue Aug 12 11:42:05 EDT 2014 > > On di, 2014-08-12 at 15:20 +0000, Hoyle Anderson (AM) via Outages wrote: >> I know this isn?t much help, but there are major problems with >> multiple ISPs since around 4-5 AM EST. I really don?t have much >> detail, but I have sites that are unreachable from some providers. >> Looks like Comcast, level3, ATT, cogent, etc. >> >> >> >> So, it?s probably not just you, but I?m afraid I don?t know who it is. >> I heard one report of a datacenter outage. >> > > Hi, > > Some routing tables hit 512K routes today. Some old hardware and > software can't handle that and either crash or ignore newly learned > routes. So this may cause some disturbances in the force. > > HTH, > Teun > > ----------------- > From khelms at zcorum.com Tue Aug 12 18:11:54 2014 From: khelms at zcorum.com (Scott Helms) Date: Tue, 12 Aug 2014 14:11:54 -0400 Subject: [HFC] pooling modems in layer2 In-Reply-To: References: Message-ID: Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Tue, Aug 12, 2014 at 10:23 AM, Toney Mareo wrote: > Hello > > I think it's kind of an isp secret but I would be curious how do people > distribute modems to pools before they would even reach the actual IP > network so on layer2: > > > http://dl.packetstormsecurity.net/papers/evaluation/docsis/Service_Distribution.jpg Certainly not secret, DOCSIS is a very well documented protocol with most of the information being publicly available. > > > > For this I would like to get some clarification because I do not work in > the telco industry. As I can figure out of the docsis, cablelabs documents. > The CMTS device is connected to the coax segments through fiber. Therefore > one could say that the "modem facing" side is a fiber optic interface but > it's not 1000 Base-FX, not a regular Ethernet over fiber. It sends signals > through a broad range of frequencies. > While fiber is commonly used in cable plants as part of a HFC network its completely transparent from a protocol standpoint the entire communication is over RF. D3 and older uses QAM modulation and the downstream runs over "normal" 6 MHz channels which are the same as TV channels. > > So what I would like to accomplish to provide a different pool of dhcp > servers, which provides different config file, tod server, router, dns etc. > infos to the modems but to do all this in Layer2. > Why? The operator is the only one who can tell the CMTS which DHCP server(s) to send traffic to and modern CMTSs do that as an IP relay and passes its IP address as the GIADDR. > > I don't have hands on experience with CMTS-es but I would think that they > are able to pool clients by MACs and able to send eg 500 clients to DHCP > server1 and the other 1500 to DHCP server2 before they would even get an > IP, so I talking of pure layer2 here! > Not exactly, first in nearly all cases the DHCP communication is an IP unicast rather than a layer 2 broadcast. Second, the way that the DHCP server is selected is normally based on the type of device so that modems get a specific GIADDR, CPE (PCs, routers behind modems, etc) get another one, and often the EMTA gets a third. It might be possible to do that off a count of devices, but if so it will be more of a load balancing scenario rather than these specific 500 CMs get this DHCP server. It is possible to do open access in a DOCSIS system, but its very difficult and involves creating filters in both the CMTS and CM configurations. > > Let's say if the CMTS device does not support this, what are the other > options for routing layer2 traffic coming out of the CMTS? If I would know > more about the device I would say that put a linuxbox after it (on the ISP > facing nic) and mark the packets going out with arptables/ebtables then > send them out of different nics to different dhcp servers. > It doesn't really work that way, but the closest thing is a "soft" tunnel that gets used for things like transparent LAN services, carrier WiFi, and a few other use cases. http://www.cablelabs.com/wp-content/uploads/specdocs/CM-SP-L2VPN-I09-100611.pdf > Any suggestions are welcome. > From jason at lixfeld.ca Tue Aug 12 18:19:36 2014 From: jason at lixfeld.ca (Jason Lixfeld) Date: Tue, 12 Aug 2014 14:19:36 -0400 Subject: AM dust filters Message-ID: <8C055A5A-5986-4730-9DC3-45605D7551C2@lixfeld.ca> Hi, I'm interested in knowing what sorts of material folks use to make after-market dust filters for their various devices which wouldn't normally have any. This seems to almost be a necessity when these kinds of devices are deployed in environments that are overly dusty and dirty (it should also be implied that these environments are all in-doors and would have less than ideal airflow and climate control). A material that is too dense will hider airflow and cause an immediate increase in inlet temperature, which would exacerbate a potentially threatening temperature situation in environments where the ambient temperature is already in the mid to high twenties and above (that's 77 - 86F+ for my American friends ;)). A material that is not dense enough won't do a very good job at filtering. Do folks just hack up HEPA filters or something? From hank at efes.iucc.ac.il Tue Aug 12 18:42:56 2014 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 12 Aug 2014 21:42:56 +0300 (IDT) Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: On Tue, 12 Aug 2014, Hank Nussbacher wrote: http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html -Hank > On Tue, 12 Aug 2014, Suresh Ramasubramanian wrote: > > Many don't need to buy anything new. Just follow the instructions here: > http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switche$ > We did this in the 1st week of June. Problem solved. > > -Hank > > > >> 512K routes, here we come. Lots of TCAM based routers suddenly become >> really expensive doorstops. >> >> Maybe time to revisit this old 2007 nanog thread? >> >> http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=99870;page=1;sb=post_latest_reply;so=ASC;mh=25;list=nanog >> >> FYI nanog - >> https://puck.nether.net/pipermail/outages/2014-August/007091.html >> >> [outages] Major outages today, not much info at this time >> >> Teun Vink teun at teun.tv >> Tue Aug 12 11:42:05 EDT 2014 >> >> On di, 2014-08-12 at 15:20 +0000, Hoyle Anderson (AM) via Outages wrote: >> > I know this isn?t much help, but there are major problems with >> > multiple ISPs since around 4-5 AM EST. I really don?t have much >> > detail, but I have sites that are unreachable from some providers. >> > Looks like Comcast, level3, ATT, cogent, etc. >> > >> > >> > >> > So, it?s probably not just you, but I?m afraid I don?t know who it is. >> > I heard one report of a datacenter outage. >> > >> >> Hi, >> >> Some routing tables hit 512K routes today. Some old hardware and >> software can't handle that and either crash or ignore newly learned >> routes. So this may cause some disturbances in the force. >> >> HTH, >> Teun >> >> ----------------- >> > From esuarez at fcaglp.fcaglp.unlp.edu.ar Tue Aug 12 18:52:45 2014 From: esuarez at fcaglp.fcaglp.unlp.edu.ar (Eduardo A. =?iso-8859-1?b?U3XhcmV6?=) Date: Tue, 12 Aug 2014 15:52:45 -0300 Subject: fire ants Message-ID: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> Hi, it's not a joke. Here we have a fire ants nest in the fiber patch panel. Are there any DIY ways to manage that? Thanks, Eduardo.- -- Eduardo A. Suarez Facultad de Ciencias Astron?micas y Geof?sicas - UNLP FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From blueneon at gmail.com Tue Aug 12 18:59:46 2014 From: blueneon at gmail.com (Tom Morris) Date: Tue, 12 Aug 2014 14:59:46 -0400 Subject: fire ants In-Reply-To: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> References: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> Message-ID: Terro is my go-to for that... it's basically boric acid mixed with a sugar solution. The ants eat it and perish. It's the only thing I've found that works on the infamous Crazy Rasberry Ants that like to eat electrical panels. On Tue, Aug 12, 2014 at 2:52 PM, Eduardo A. Su?rez < esuarez at fcaglp.fcaglp.unlp.edu.ar> wrote: > Hi, > > it's not a joke. Here we have a fire ants nest in the fiber patch panel. > Are there any DIY ways to manage that? > > Thanks, Eduardo.- > > -- > Eduardo A. Suarez > Facultad de Ciencias Astron?micas y Geof?sicas - UNLP > FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589 > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > -- -- Tom Morris, KG4CYX Mad Scientist and Operations Manager, WDNA-FM 88.9 Miami - Serious Jazz! 786-228-7087 151.820 Megacycles From Valdis.Kletnieks at vt.edu Tue Aug 12 19:01:19 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 12 Aug 2014 15:01:19 -0400 Subject: fire ants In-Reply-To: Your message of "Tue, 12 Aug 2014 15:52:45 -0300." <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> References: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> Message-ID: <13012.1407870079@turing-police.cc.vt.edu> On Tue, 12 Aug 2014 15:52:45 -0300, "Eduardo A. Su?rez" said: > it's not a joke. Here we have a fire ants nest in the fiber patch panel. > Are there any DIY ways to manage that? Does the local zoo have an aardvark they're willing to loan you? :) This might be a tad difficult to deal with, as the usual DIY solution is to spray the nest with something noxious - which may not be good for your fiber terminations either. May be worth it to get a pro to come out and look at it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From EWieling at nyigc.com Tue Aug 12 19:02:11 2014 From: EWieling at nyigc.com (Eric Wieling) Date: Tue, 12 Aug 2014 15:02:11 -0400 Subject: fire ants In-Reply-To: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> References: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> Message-ID: <616B4ECE1290D441AD56124FEBB03D082D1AEF622C@mailserver2007.nyigc.globe> I've used mothballs* in outside enclosures each spring, but I've never had a full blown nest in an enclosure. Fireants are hard to kill, but they will move their nest. * naphthalene, para-dichlorobenzene, p-dichlorobenzene, pDCB, or PDB -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eduardo A. Su?rez Sent: Tuesday, August 12, 2014 2:53 PM To: NANOG Subject: fire ants Hi, it's not a joke. Here we have a fire ants nest in the fiber patch panel. Are there any DIY ways to manage that? Thanks, Eduardo.- -- Eduardo A. Suarez Facultad de Ciencias Astron?micas y Geof?sicas - UNLP FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From AOsgood at Streamline-Solutions.net Tue Aug 12 19:04:25 2014 From: AOsgood at Streamline-Solutions.net (Aaron D. Osgood) Date: Tue, 12 Aug 2014 15:04:25 -0400 Subject: fire ants In-Reply-To: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> References: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> Message-ID: Freeze it with a CO2 extinguisher then clean it out and re-seal the enclosure. You may want to consider a small open dish of repellant/killer in the enclosure in case they get in again :-) Aaron D. Osgood Streamline Solutions L.L.C 274 E. Eau Gallie Blvd. #336 Indian Harbour Beach, FL 32937 TEL: 207-518-8455 MOBILE: 207-831-5829 GTalk: aaron.osgood AOsgood at Streamline-Solutions.net http://www.streamline-solutions.net Introducing Efficiency to Business since 1986. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eduardo A. Su?rez Sent: Tuesday, August 12, 2014 2:53 PM To: NANOG Subject: fire ants Hi, it's not a joke. Here we have a fire ants nest in the fiber patch panel. Are there any DIY ways to manage that? Thanks, Eduardo.- -- Eduardo A. Suarez Facultad de Ciencias Astron?micas y Geof?sicas - UNLP FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From robertg at garlic.com Tue Aug 12 19:07:59 2014 From: robertg at garlic.com (Robert Glover) Date: Tue, 12 Aug 2014 12:07:59 -0700 Subject: fire ants In-Reply-To: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> References: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> Message-ID: <53EA660F.1080303@garlic.com> On 8/12/2014 11:52 AM, Eduardo A. Su?rez wrote: > Hi, > > it's not a joke. Here we have a fire ants nest in the fiber patch panel. > Are there any DIY ways to manage that? > > Thanks, Eduardo.- > Shop vac? From blueneon at gmail.com Tue Aug 12 19:09:11 2014 From: blueneon at gmail.com (Tom Morris) Date: Tue, 12 Aug 2014 15:09:11 -0400 Subject: AM dust filters In-Reply-To: <8C055A5A-5986-4730-9DC3-45605D7551C2@lixfeld.ca> References: <8C055A5A-5986-4730-9DC3-45605D7551C2@lixfeld.ca> Message-ID: One important question: how often is the equipment accessed for maintenance? I've had reasonably good luck with air filter media coated with a tackifier, similar to the Dustlok media here http://www.filtersales.com/pagout.htm?id=Pad%20Media It seems like what happens with it is heavier airborne fibers (lint, hair) get caught up in the first few fibers of the media, not obstructing airflow, and allow the finer dust to travel deeper into the media where it sticks to the tacky layer at the back. It lasts a good long while. It's single use though, so it has to be replenlished every now and then. Foam rubber media tends to have trouble with surface/airflow area vs pore size. The best option, though, will be to enclose the equipment in a cabinet that can be pressurized by one or more fan forced+filtered inlets. Middle Atlantic makes rack cabinets and fan panels that can be used to pressurize them that way. If you get a cabinet that takes a standard furnace filter, I've had good luck with the off the shelf 3M Filtrete Ultra Allergen filters, they have a TON of surface area with great fine dust capture and very low airflow resistance, even when you're drawing the air through them really way too fast. :) On Tue, Aug 12, 2014 at 2:19 PM, Jason Lixfeld wrote: > Hi, > > I'm interested in knowing what sorts of material folks use to make > after-market dust filters for their various devices which wouldn't normally > have any. This seems to almost be a necessity when these kinds of devices > are deployed in environments that are overly dusty and dirty (it should > also be implied that these environments are all in-doors and would have > less than ideal airflow and climate control). > > A material that is too dense will hider airflow and cause an immediate > increase in inlet temperature, which would exacerbate a potentially > threatening temperature situation in environments where the ambient > temperature is already in the mid to high twenties and above (that's 77 - > 86F+ for my American friends ;)). A material that is not dense enough > won't do a very good job at filtering. > > Do folks just hack up HEPA filters or something? -- -- Tom Morris, KG4CYX Mad Scientist and Operations Manager, WDNA-FM 88.9 Miami - Serious Jazz! 786-228-7087 151.820 Megacycles From dougb at dougbarton.us Tue Aug 12 19:22:01 2014 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 12 Aug 2014 12:22:01 -0700 Subject: AM dust filters In-Reply-To: <8C055A5A-5986-4730-9DC3-45605D7551C2@lixfeld.ca> References: <8C055A5A-5986-4730-9DC3-45605D7551C2@lixfeld.ca> Message-ID: <53EA6959.5020002@dougbarton.us> On 08/12/2014 11:19 AM, Jason Lixfeld wrote: > Hi, > > I'm interested in knowing what sorts of material folks use to make after-market dust filters for their various devices which wouldn't normally have any. This seems to almost be a necessity when these kinds of devices are deployed in environments that are overly dusty and dirty (it should also be implied that these environments are all in-doors and would have less than ideal airflow and climate control). > > A material that is too dense will hider airflow and cause an immediate increase in inlet temperature, which would exacerbate a potentially threatening temperature situation in environments where the ambient temperature is already in the mid to high twenties and above (that's 77 - 86F+ for my American friends ;)). A material that is not dense enough won't do a very good job at filtering. > > Do folks just hack up HEPA filters or something? It sort of depends on what kind of stuff you're trying to filter out. Panty hose actually makes a reasonably good filter for larger stuff, but Tom's question about how often are you going to service it comes into play, since you need to remove the debris that it catches periodically in order to avoid obstructing the air flow excessively. OTOH, you also have to have some thought towards what are the benefits of not having the internals of the system coated with dust, vs. slightly reduced air flow. Tom's suggestion of a pressurized cabinet is a good one of course, but that's not possible in all situations. hth, Doug From tshaw at oitc.com Tue Aug 12 19:33:12 2014 From: tshaw at oitc.com (TR Shaw) Date: Tue, 12 Aug 2014 15:33:12 -0400 Subject: fire ants In-Reply-To: <53EA660F.1080303@garlic.com> References: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> <53EA660F.1080303@garlic.com> Message-ID: +1 for CO2 (But stand way back as they will go everywhere) +1 for moth balls in the enclosure (esp prophylactically) +1 for boric acid mixed with molasses (use externally) Also stops carpenter ants in poles.) Tom On Aug 12, 2014, at 3:07 PM, Robert Glover wrote: > On 8/12/2014 11:52 AM, Eduardo A. Su?rez wrote: >> Hi, >> >> it's not a joke. Here we have a fire ants nest in the fiber patch panel. >> Are there any DIY ways to manage that? >> >> Thanks, Eduardo.- >> > Shop vac? > From jason at lixfeld.ca Tue Aug 12 19:44:02 2014 From: jason at lixfeld.ca (Jason Lixfeld) Date: Tue, 12 Aug 2014 15:44:02 -0400 Subject: AM dust filters In-Reply-To: References: <8C055A5A-5986-4730-9DC3-45605D7551C2@lixfeld.ca> Message-ID: <4D7091F3-F5B7-4D92-AB7A-25E46391FE29@lixfeld.ca> On Aug 12, 2014, at 3:09 PM, Tom Morris wrote: > One important question: how often is the equipment accessed for maintenance? Who knows :) Maybe it becomes someone's full time job to go do regular checks and maintenances of every POP? Maybe after an appropriate filter is found, a relatively low temperature threshold monitor is set up in an NMS. When this threshold is reached, it would probably be safe to assume a dirty filter (or some other condition that would require a visit) and someone could be dispatched to replace it. > I've had reasonably good luck with air filter media coated with a tackifier, similar to the Dustlok media here http://www.filtersales.com/pagout.htm?id=Pad%20Media > It seems like what happens with it is heavier airborne fibers (lint, hair) get caught up in the first few fibers of the media, not obstructing airflow, and allow the finer dust to travel deeper into the media where it sticks to the tacky layer at the back. It lasts a good long while. It's single use though, so it has to be replenlished every now and then. > > Foam rubber media tends to have trouble with surface/airflow area vs pore size. > > The best option, though, will be to enclose the equipment in a cabinet that can be pressurized by one or more fan forced+filtered inlets. Middle Atlantic makes rack cabinets and fan panels that can be used to pressurize them that way. If you get a cabinet that takes a standard furnace filter, I've had good luck with the off the shelf 3M Filtrete Ultra Allergen filters, they have a TON of surface area with great fine dust capture and very low airflow resistance, even when you're drawing the air through them really way too fast. :) Unfortunately a cabinet isn't possible due to a variety of issues. > > On Tue, Aug 12, 2014 at 2:19 PM, Jason Lixfeld wrote: > Hi, > > I'm interested in knowing what sorts of material folks use to make after-market dust filters for their various devices which wouldn't normally have any. This seems to almost be a necessity when these kinds of devices are deployed in environments that are overly dusty and dirty (it should also be implied that these environments are all in-doors and would have less than ideal airflow and climate control). > > A material that is too dense will hider airflow and cause an immediate increase in inlet temperature, which would exacerbate a potentially threatening temperature situation in environments where the ambient temperature is already in the mid to high twenties and above (that's 77 - 86F+ for my American friends ;)). A material that is not dense enough won't do a very good job at filtering. > > Do folks just hack up HEPA filters or something? > > > > -- > -- > Tom Morris, KG4CYX > Mad Scientist and Operations Manager, WDNA-FM 88.9 Miami - Serious Jazz! > 786-228-7087 > 151.820 Megacycles From jason at lixfeld.ca Tue Aug 12 19:52:04 2014 From: jason at lixfeld.ca (Jason Lixfeld) Date: Tue, 12 Aug 2014 15:52:04 -0400 Subject: AM dust filters In-Reply-To: <53EA6959.5020002@dougbarton.us> References: <8C055A5A-5986-4730-9DC3-45605D7551C2@lixfeld.ca> <53EA6959.5020002@dougbarton.us> Message-ID: On Aug 12, 2014, at 3:22 PM, Doug Barton wrote: > On 08/12/2014 11:19 AM, Jason Lixfeld wrote: >> Hi, >> >> I'm interested in knowing what sorts of material folks use to make after-market dust filters for their various devices which wouldn't normally have any. This seems to almost be a necessity when these kinds of devices are deployed in environments that are overly dusty and dirty (it should also be implied that these environments are all in-doors and would have less than ideal airflow and climate control). >> >> A material that is too dense will hider airflow and cause an immediate increase in inlet temperature, which would exacerbate a potentially threatening temperature situation in environments where the ambient temperature is already in the mid to high twenties and above (that's 77 - 86F+ for my American friends ;)). A material that is not dense enough won't do a very good job at filtering. >> >> Do folks just hack up HEPA filters or something? > > It sort of depends on what kind of stuff you're trying to filter out. Small-ish stuff. Your every day, run of the mill fine grain dust, tracked-in dirt & sand, some construction particulate (metal shavings, etc). > Panty hose actually makes a reasonably good filter for larger stuff, but Tom's question about how often are you going to service it comes into play, since you need to remove the debris that it catches periodically in order to avoid obstructing the air flow excessively. Yup. Depending, either a vacuum or a straight-up replacement of the 'filter', I'd suspect. Or maybe just a good shake in some cases. > OTOH, you also have to have some thought towards what are the benefits of not having the internals of the system coated with dust, vs. slightly reduced air flow. Indeed. The internals can definitely handle non-metalic dust, as well as a pretty wide temperature range (caused by either reduced airflow or an increase in ambient temperature, or both), so I'd imagine it would be a appropriate balance between the two. > Tom's suggestion of a pressurized cabinet is a good one of course, but that's not possible in all situations. From the.lists at mgm51.com Tue Aug 12 20:02:28 2014 From: the.lists at mgm51.com (Mike.) Date: Tue, 12 Aug 2014 16:02:28 -0400 Subject: fire ants In-Reply-To: References: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> Message-ID: <201408121602280484.01AF8915@smtp.24cl.home> On 8/12/2014 at 2:59 PM Tom Morris wrote: |Terro is my go-to for that... it's basically boric acid mixed with a sugar |solution. The ants eat it and perish. It's the only thing I've found that |works on the infamous Crazy Rasberry Ants that like to eat electrical |panels. ============= In case someone tries to mix up a batch themselves, Terro is better described as Borax in a sugar solution[1]. Borax is the trade name of a salt of boric acid. I've been using a mixture of Borax and honey to keep the ants at bay for a few years. Use the search engine of your choice to search for Borax and ants. You'll find a plethora of recipes. HTH [1] http://www.terro.com/blog/using-borax-around-children-and-pets From jschiel at flowtools.net Tue Aug 12 20:06:26 2014 From: jschiel at flowtools.net (me) Date: Tue, 12 Aug 2014 14:06:26 -0600 Subject: fire ants In-Reply-To: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> References: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> Message-ID: <53EA73C2.9080601@flowtools.net> Ran across this paper the other day and didn't know how big a problem it was. Looks like Eduardo's post confirms it. http://www.rainbowtech.net/products/docs/c51ce4107047eb1b2dc/Ants%20in%20OSP%20Equipment.pdf.pdf --John On 08/12/2014 12:52 PM, Eduardo A. Su?rez wrote: > Hi, > > it's not a joke. Here we have a fire ants nest in the fiber patch panel. > Are there any DIY ways to manage that? > > Thanks, Eduardo.- > From bill at herrin.us Tue Aug 12 20:21:03 2014 From: bill at herrin.us (William Herrin) Date: Tue, 12 Aug 2014 16:21:03 -0400 Subject: AM dust filters In-Reply-To: <8C055A5A-5986-4730-9DC3-45605D7551C2@lixfeld.ca> References: <8C055A5A-5986-4730-9DC3-45605D7551C2@lixfeld.ca> Message-ID: On Tue, Aug 12, 2014 at 2:19 PM, Jason Lixfeld wrote: > Do folks just hack up HEPA filters or something? I've had decent luck with window air conditioner filters available at your local home despot. Trim to size with scissors. Periodically replace. HEPA they are not, but they'll keep out the worst of it without restricting air flow (at least not until they're really dirty) plus they're cheap and readily available. If you have a more or less closed room (like a closet), sometimes it's enough to just buy a freestanding hepa filter at walmart, clean the room with a shop vac once and then leave the filter running in the room. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: Can I solve your unusual networking challenges? From lcaron at unix-scripts.info Tue Aug 12 20:36:05 2014 From: lcaron at unix-scripts.info (Laurent CARON) Date: Tue, 12 Aug 2014 22:36:05 +0200 Subject: Level3 (AS3549) BGP contact off-list Message-ID: <53EA7AB5.2030509@unix-scripts.info> Hi, Currently experiencing trouble with BGP session between 49463 and 3549. Relevant router: cdg2.gblx.net Can you please contact me off-list for resolution ? Thanks From charles at thefnf.org Tue Aug 12 21:02:39 2014 From: charles at thefnf.org (charles at thefnf.org) Date: Tue, 12 Aug 2014 16:02:39 -0500 Subject: fire ants In-Reply-To: <53EA73C2.9080601@flowtools.net> References: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> <53EA73C2.9080601@flowtools.net> Message-ID: <8a851a5b5afc6aa78c709d08b95e82c3@thefnf.org> On 2014-08-12 15:06, me wrote: > Ran across this paper the other day and didn't know how big a problem > it was. Looks like Eduardo's post confirms it. > > http://www.rainbowtech.net/products/docs/c51ce4107047eb1b2dc/Ants%20in%20OSP%20Equipment.pdf.pdf > Now that is fascinating. I like how they reproduced the issue via an ant farm. That's pretty slick. From bicknell at ufp.org Tue Aug 12 21:55:31 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 12 Aug 2014 16:55:31 -0500 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: <44CD37A5-6AAB-4EF3-92C9-D459F6C90EF0@ufp.org> On Aug 12, 2014, at 1:02 PM, Hank Nussbacher wrote: > Many don't need to buy anything new. Just follow the instructions here: > http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switche$ > We did this in the 1st week of June. Problem solved. s/Problem solved/Critical limit pushed out long enough to give us a few more years/ -- 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: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bill at herrin.us Tue Aug 12 22:10:07 2014 From: bill at herrin.us (William Herrin) Date: Tue, 12 Aug 2014 18:10:07 -0400 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: On Tue, Aug 12, 2014 at 2:42 PM, Hank Nussbacher wrote: > http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html I note that the recommended command in that article, "mls cef maximum-routes ip 1000", will throw most of your IPv6 routes out of the TCAM instead. Which if you have any IPv6 traffic of substance just kills you in the other direction. Might want to try something more like "mls cef maximum-routes ip 900". Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: Can I solve your unusual networking challenges? From tom at ninjabadger.net Tue Aug 12 22:15:27 2014 From: tom at ninjabadger.net (Tom Hill) Date: Tue, 12 Aug 2014 23:15:27 +0100 Subject: ****SPAM:5.2**** Re: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: <53EA91FF.1010702@ninjabadger.net> On 12/08/14 23:10, William Herrin wrote: > I note that the recommended command in that article, "mls cef > maximum-routes ip 1000", will throw most of your IPv6 routes out of > the TCAM instead. Which if you have any IPv6 traffic of substance just > kills you in the other direction. Might want to try something more > like "mls cef maximum-routes ip 900". And if you want any MPLS labels (especially if running 6PE) you might want to claw that back a bit further. tl;dr buy new routers next year. :) Tom From Kevin_McElearney at cable.comcast.com Wed Aug 13 00:06:45 2014 From: Kevin_McElearney at cable.comcast.com (McElearney, Kevin) Date: Wed, 13 Aug 2014 00:06:45 +0000 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: http://www.zdnet.com/internet-hiccups-today-youre-not-alone-heres-why-70000 32566/ "According to NANOG, and complaints tracker DownDetector, many Internet providers ? including Comcast, Level3, AT&T, Cogent, Sprint, Verizon, and others ? have suffered from serious performance problems at various times on Tuesday.? While we had a few multi-homed customers have problems with their routers, we did not see anything in the core. Is this just a ZDNET reporting error? - Kevin On 8/12/14, 6:10 PM, "William Herrin" wrote: >On Tue, Aug 12, 2014 at 2:42 PM, Hank Nussbacher >wrote: >> >>http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-s >>witches/117712-problemsolution-cat6500-00.html > >I note that the recommended command in that article, "mls cef >maximum-routes ip 1000", will throw most of your IPv6 routes out of >the TCAM instead. Which if you have any IPv6 traffic of substance just >kills you in the other direction. Might want to try something more >like "mls cef maximum-routes ip 900". > >Regards, >Bill Herrin > >-- >William Herrin ................ herrin at dirtside.com bill at herrin.us >Owner, Dirtside Systems ......... Web: >Can I solve your unusual networking challenges? From mpetach at netflight.com Wed Aug 13 00:49:09 2014 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 12 Aug 2014 17:49:09 -0700 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: On Tue, Aug 12, 2014 at 5:06 PM, McElearney, Kevin < Kevin_McElearney at cable.comcast.com> wrote: > http://www.zdnet.com/internet-hiccups-today-youre-not-alone-heres-why-70000 > 32566/ > > "According to NANOG, and complaints tracker DownDetector, many Internet > providers ? including Comcast, Level3, AT&T, Cogent, Sprint, Verizon, and > others ? have suffered from serious performance problems at various times > on Tuesday.? > > While we had a few multi-homed customers have problems with their routers, > we did not see anything in the core. Is this just a ZDNET reporting error? > > - Kevin > > Unless you guys are miraculously managing to terminate Nx100G bundles into 6509s with Sup2 or sup3s, I would be really, really surprised if this even made it on your radar. Chalk it up to poorly-researched reporting. And if you *are* handling Nx100G bundles on 6509s, please contact me off-list, I need to get the details on your source for magic router pixie dust. ;) Matt From rs at seastrom.com Wed Aug 13 01:13:36 2014 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 12 Aug 2014 21:13:36 -0400 Subject: Mikrotik RouterBoard and Ubiquiti Networks Routing and Switching Solutions In-Reply-To: <53EA447B.8090007@ledeuns.net> (Denis Fondras's message of "Tue, 12 Aug 2014 18:44:43 +0200") References: <53EA447B.8090007@ledeuns.net> Message-ID: <86lhqti43j.fsf@valhalla.seastrom.com> Denis Fondras writes: > May we discuss IPv6 support ? Last time I checked, UBNT was lagging > behind... I've been running an IPv6 tunnel ( FIOS) with one end being Mikrotik and the other being UBNT (ER-Lite) since January 2013. The UBNT is in a fairly simple-minded configuration so I can't speak to things like VRRP, OSPFv3, etc. The Mikrotik is in the datacenter... speaks OSPF[v3] and BGP to Cisco stuff. No difficulties, though I'm pretty sure I didn't create/configure the tunnel via the GUI. -r From ops.lists at gmail.com Wed Aug 13 01:16:00 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 13 Aug 2014 06:46:00 +0530 Subject: fire ants In-Reply-To: <8a851a5b5afc6aa78c709d08b95e82c3@thefnf.org> References: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> <53EA73C2.9080601@flowtools.net> <8a851a5b5afc6aa78c709d08b95e82c3@thefnf.org> Message-ID: On Wednesday, August 13, 2014, wrote: > 2014-08-12 15:06, me wrote: > >> Ran across this paper the other day and didn't know how big a problem >> it was. Looks like Eduardo's post confirms it. >> >> http://www.rainbowtech.net/products/docs/c51ce4107047eb1b2dc/Ants%20in% >> 20OSP%20Equipment.pdf.pdf >> > Now that is fascinating. I like how they reproduced the issue via an ant > farm. That's pretty slick. > Needs an "Anthill Inside" sticker like Hex at the Unseen University. -- --srs (iPad) From rs at seastrom.com Wed Aug 13 01:32:41 2014 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 12 Aug 2014 21:32:41 -0400 Subject: [HFC] pooling modems in layer2 In-Reply-To: (Toney Mareo's message of "Tue, 12 Aug 2014 16:23:38 +0200") References: Message-ID: <86ha1hi37q.fsf@valhalla.seastrom.com> "Toney Mareo" writes: > Hello > > I think it's kind of an isp secret but I would be curious how do > people distribute modems to pools before they would even reach the > actual IP network so on layer2: > > http://dl.packetstormsecurity.net/papers/evaluation/docsis/Service_Distribution.jpg Nobody does CMTRI anymore. That illustration is over a decade and a half old, which is part of what's confusing you. The scheme there is that they use a dialup modem for the upstream and a cablemodem for the downstream. > For this I would like to get some clarification because I do not work in the telco industry. If you're interested in how CMTRI works for historical reasons, the spec is here: http://www.cablelabs.com/wp-content/uploads/specdocs/SP-CMTRI-I01-970804.pdf > As I can figure out of the docsis, cablelabs documents. The CMTS > device is connected to the coax segments through fiber. Therefore > one could say that the "modem facing" side is a fiber optic > interface but it's not 1000 Base-FX, not a regular Ethernet over > fiber. It sends signals through a broad range of frequencies. It sends signals over RF (i.e. truly "broadband"). The RF happens to be on a laser-lit fiber instead of a piece of coax (until it hits the fiber node and gets turned into coax cable). There are Ethernet MAC addresses in there if you look at the right layer, but the DOCSIS data rides as a "program" atop a J.83 single program transport stream on a QAM64 or QAM256 modulated RF signal. It's just like a digital TV program and occupies the same frequency space - but 0x1FFE is the well-known PID that means "DOCSIS data". The upstream channels are comparatively low (under 80 MHz) and the downstream channels are comparatively high (over 80 MHz to 800-1000 MHz depending on the system). Splitting them out is accomplished with bidirectional high and low pass filters called "diplexers". > So what I would like to accomplish to provide a different pool of > dhcp servers, which provides different config file, tod server, > router, dns etc. infos to the modems but to do all this in Layer2. > > I don't have hands on experience with CMTS-es but I would think that > they are able to pool clients by MACs and able to send eg 500 > clients to DHCP server1 and the other 1500 to DHCP server2 before > they would even get an IP, so I talking of pure layer2 here! There are multiple ways to approach this. You need a consultant who is well-versed in the care and feeding of DOCSIS edge networks to walk through your options with you so that you don't find yourself in a painful technical place. > Let's say if the CMTS device does not support this, what are the > other options for routing layer2 traffic coming out of the CMTS? I don't recommend PPPoE. :) > If I would know more about the device I would say that put a > linuxbox after it (on the ISP facing nic) and mark the packets going > out with arptables/ebtables then send them out of different nics to > different dhcp servers. > > Any suggestions are welcome. You might start by sharing a high level overview of what it is that you're trying to accomplish. If it's simply sandboxing people who haven't paid their bills, there are well-known ways to do that. If it's business services over DOCSIS, there are likewise ways to do that. -r From jlewis at lewis.org Wed Aug 13 01:34:22 2014 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 12 Aug 2014 21:34:22 -0400 (EDT) Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: On Tue, 12 Aug 2014, Matthew Petach wrote: > On Tue, Aug 12, 2014 at 5:06 PM, McElearney, Kevin < > Kevin_McElearney at cable.comcast.com> wrote: > >> http://www.zdnet.com/internet-hiccups-today-youre-not-alone-heres-why-70000 >> 32566/ >> >> "According to NANOG, and complaints tracker DownDetector, many Internet >> providers ?? including Comcast, Level3, AT&T, Cogent, Sprint, Verizon, and >> others ?? have suffered from serious performance problems at various times >> on Tuesday.?? >> >> While we had a few multi-homed customers have problems with their routers, >> we did not see anything in the core. Is this just a ZDNET reporting error? >> >> > Unless you guys are miraculously managing to terminate > Nx100G bundles into 6509s with Sup2 or sup3s, I would > be really, really surprised if this even made it on your > radar. Chalk it up to poorly-researched reporting. There are/have been multiple fiber provider outages the past two days, but I suspect there's always a fiber cut / outage somewhere. > And if you *are* handling Nx100G bundles on 6509s, > please contact me off-list, I need to get the details on > your source for magic router pixie dust. ;) Cisco white papers. Where else? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From Kevin_McElearney at cable.comcast.com Wed Aug 13 01:54:12 2014 From: Kevin_McElearney at cable.comcast.com (McElearney, Kevin) Date: Wed, 13 Aug 2014 01:54:12 +0000 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: From: Matthew Petach >Unless you guys are miraculously managing to terminate > >Nx100G bundles into 6509s with Sup2 or sup3s, I would >be really, really surprised if this even made it on your >radar. Chalk it up to poorly-researched reporting. > > >And if you *are* handling Nx100G bundles on 6509s, >please contact me off-list, I need to get the details on >your source for magic router pixie dust. ;) It made the radar with the consumer impact. We traced the issue quickly to customer datacenter routers/512K and worked with them to correct. We were surprised (or not really) with this being called a wide spread provider issue. Just checking if others really had an issue or was this isolated to a few data centers. No pixie dust ;-) - Kevin > From hank at efes.iucc.ac.il Wed Aug 13 05:08:04 2014 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 13 Aug 2014 08:08:04 +0300 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: <5.1.1.6.2.20140813080649.00298e78@efes.iucc.ac.il> At 18:10 12/08/2014 -0400, William Herrin wrote: We went with 768 - enough time to replace the routers with ASR9010s. It is merely a stop-gap measure to give everyone time to replace their routers in an orderly fashion. -Hank >On Tue, Aug 12, 2014 at 2:42 PM, Hank Nussbacher wrote: > > > http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html > >I note that the recommended command in that article, "mls cef >maximum-routes ip 1000", will throw most of your IPv6 routes out of >the TCAM instead. Which if you have any IPv6 traffic of substance just >kills you in the other direction. Might want to try something more >like "mls cef maximum-routes ip 900". > >Regards, >Bill Herrin > >-- >William Herrin ................ herrin at dirtside.com bill at herrin.us >Owner, Dirtside Systems ......... Web: >Can I solve your unusual networking challenges? From Valdis.Kletnieks at vt.edu Wed Aug 13 05:40:29 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 13 Aug 2014 01:40:29 -0400 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: Your message of "Wed, 13 Aug 2014 08:08:04 +0300." <5.1.1.6.2.20140813080649.00298e78@efes.iucc.ac.il> References: <5.1.1.6.2.20140813080649.00298e78@efes.iucc.ac.il> Message-ID: <14485.1407908429@turing-police.cc.vt.edu> On Wed, 13 Aug 2014 08:08:04 +0300, Hank Nussbacher said: > We went with 768 - enough time to replace the routers with ASR9010s. It is > merely a stop-gap measure to give everyone time to replace their routers in > an orderly fashion. The same people who, knowing the 6509 had this default config issue, and neither replaced the gear nor did the reconfig to buy time *before* the wall got hit, are going to replace said 6509 in orderly fashion? Hank, you gotta learn to wear respiratory apparatus when working near open containers of magic router pixie dust - that stuff can screw you up if you inhale it. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mansaxel at besserwisser.org Wed Aug 13 07:10:19 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Wed, 13 Aug 2014 09:10:19 +0200 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: <20140813071019.GF21786@besserwisser.org> Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today Date: Tue, Aug 12, 2014 at 09:40:55PM +0530 Quoting Suresh Ramasubramanian (ops.lists at gmail.com): > 512K routes, here we come. Lots of TCAM based routers suddenly become > really expensive doorstops. We had a planned outage yesterday 2300 UTC to perform the operation Hank mentions. Alas, around 0850UTC the table went "critical" and we had to do an emergency reboot. Well, the good part is that all 10G line cards survived, and we're back in operation. The new routers are bought or in the investment plan for this year. Just need to wait until it's time for our vendors fiscal year end race... -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Am I accompanied by a PARENT or GUARDIAN? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From khelms at zcorum.com Wed Aug 13 12:15:23 2014 From: khelms at zcorum.com (Scott Helms) Date: Wed, 13 Aug 2014 08:15:23 -0400 Subject: [HFC] pooling modems in layer2 In-Reply-To: <86ha1hi37q.fsf@valhalla.seastrom.com> References: <86ha1hi37q.fsf@valhalla.seastrom.com> Message-ID: > > > > The upstream channels are comparatively low (under 80 MHz) and the > downstream channels are comparatively high (over 80 MHz to 800-1000 > MHz depending on the system). Splitting them out is accomplished with > bidirectional high and low pass filters called "diplexers". > The upstream spectrum is (at the moment) is 5-42 MHz in the US, though most people don't use below 20 MHz and often avoid 26-28 MHz because of interference. > > > > Let's say if the CMTS device does not support this, what are the > > other options for routing layer2 traffic coming out of the CMTS? > > I don't recommend PPPoE. :) > PPPoE not supported on any of the DOCSIS 3.0 certified CMTSs except the Cisco UBR and then it must also be the termination point for the PPPoE session, though it can be part of a L2TP (LAC<--LNS) handoff to another device that can handle the PPPoE termination. I will certainly agree that's its not a good technology for DOCSIS systems. > > > If I would know more about the device I would say that put a > > linuxbox after it (on the ISP facing nic) and mark the packets going > > out with arptables/ebtables then send them out of different nics to > > different dhcp servers. > > > > Any suggestions are welcome. > > You might start by sharing a high level overview of what it is that > you're trying to accomplish. If it's simply sandboxing people who > haven't paid their bills, there are well-known ways to do that. If > it's business services over DOCSIS, there are likewise ways to do > that. Nailed it here. From warren at kumari.net Wed Aug 13 13:52:18 2014 From: warren at kumari.net (Warren Kumari) Date: Wed, 13 Aug 2014 09:52:18 -0400 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: <14485.1407908429@turing-police.cc.vt.edu> References: <5.1.1.6.2.20140813080649.00298e78@efes.iucc.ac.il> <14485.1407908429@turing-police.cc.vt.edu> Message-ID: On Wed, Aug 13, 2014 at 1:40 AM, wrote: > On Wed, 13 Aug 2014 08:08:04 +0300, Hank Nussbacher said: > >> We went with 768 - enough time to replace the routers with ASR9010s. It is >> merely a stop-gap measure to give everyone time to replace their routers in >> an orderly fashion. > > The same people who, knowing the 6509 had this default config issue, and > neither replaced the gear nor did the reconfig to buy time *before* the > wall got hit, are going to replace said 6509 in orderly fashion? Sadly enough: A: not everyone knew about the issue - there are a large number of folk running BGP on 65xx and taking full tables who are not plugged into NANOG / the community. In many cases they are single homed enterprise folk, but run BGP anyway (because com consultant set it up, some employee with clue did it years ago and then left, etc). B: they *did* know about the issue, but convincing management to spend the cash to buy hardware that doesn't suck was hard, because "everything is working fine at the moment" -- some folk needed things to fail spectacularity to be able to justify shelling out the $$$ ( yes, they could recard the TCAM, but they are using this as an excuse to get some real gear)... Am I overly cynical, or does this all work out perfectly for some vendors? I'm guessing that a certain vendor is going to see a huge number of orders for new equipment, for an event that could have been (and was) easily predicted... "Here, buy my widget... and then you'll come back in a few years and buy another one.. ". Yup, folk purchasing these *should* have known (not like there was no discussions of this), but, well, not everyone spends all day reading NANOG / RIPE / CIDR report... W > > Hank, you gotta learn to wear respiratory apparatus when working near > open containers of magic router pixie dust - that stuff can screw you up > if you inhale it. :) -- -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From Patrick.Darden at p66.com Tue Aug 12 19:08:57 2014 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Tue, 12 Aug 2014 14:08:57 -0500 Subject: fire ants In-Reply-To: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> References: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> Message-ID: <74825E6950ECDE449817715200CEAD2703BAA0BEDC@BRTEXMB76.phillips66.net> Perhaps diatomaceous earth or Delta Dust. Once they are dead you can air-spray or vacuum the area to get rid of it all. --Patrick Darden -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eduardo A. Su?rez Sent: Tuesday, August 12, 2014 1:53 PM To: NANOG Subject: [EXTERNAL]fire ants Hi, it's not a joke. Here we have a fire ants nest in the fiber patch panel. Are there any DIY ways to manage that? Thanks, Eduardo.- -- Eduardo A. Suarez Facultad de Ciencias Astron?micas y Geof?sicas - UNLP FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From leah.ungstad at gmail.com Tue Aug 12 20:40:49 2014 From: leah.ungstad at gmail.com (Leah Ungstad) Date: Tue, 12 Aug 2014 13:40:49 -0700 Subject: Shaw routing issue 12 Aug 2014 Message-ID: Hi Nanog, anyone know what's up with a nationwide (Canadian) routing issue on Shaw? http://www.theregister.co.uk/2014/08/12/nationwide_outage_at_canadian_isp_shaw/ https://community.shaw.ca/docs/DOC-3455 thanks Leah From fergdawgster at mykolab.com Wed Aug 13 14:05:19 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 13 Aug 2014 07:05:19 -0700 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: <5.1.1.6.2.20140813080649.00298e78@efes.iucc.ac.il> <14485.1407908429@turing-police.cc.vt.edu> Message-ID: <53EB709F.8030300@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 8/13/2014 6:52 AM, Warren Kumari wrote: > Am I overly cynical, or does this all work out perfectly for some > vendors? I'm guessing that a certain vendor is going to see a huge > number of orders for new equipment, for an event that could have > been (and was) easily predicted... "Here, buy my widget... and then > you'll come back in a few years and buy another one.. > ". Yup, folk purchasing these *should* have known (not > like there was no discussions of this), but, well, not everyone > spends all day reading NANOG / RIPE / CIDR report... I am not an operator, but I used to be a *really* active routing engineer once upon a time in the stone age :-) and what really bothers me is the serious lack of general awareness on the issue of routing table size, aggregation, and stability, and what effect it has on the global Internet. Especially questions like this: "Is it time to switch to all IPv6 yet?" http://tech-beta.slashdot.org/story/14/08/13/0048244/the-ipv4-internet-hiccups If anyone *seriously* believes that IPv6 will have any positive effect on this particular issue, you are sorely misinformed. If anything, it will make the problem worse, since the ability to "get aggregation wrong" will be much easier. I'm not being cynical, I'm being a realist. :-/ - - ferg p.s. I recall some IPv6 prefix growth routing projections by Vince Fuller and Tony Li from several years ago which illustrated this, but cannot find a reference at the moment.... - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iF4EAREIAAYFAlPrcJ8ACgkQKJasdVTchbINbAD9FKCQYHW2QTHrUB7NFOzJMpAx 9pbU7474w6CFgkCiBk0A/22u0wD5Mse0oMVCgcpBeopVq0SxChU1fkp9EUgk0+ZS =NCm3 -----END PGP SIGNATURE----- From alumbis at gmail.com Wed Aug 13 15:08:55 2014 From: alumbis at gmail.com (Pete Lumbis) Date: Wed, 13 Aug 2014 11:08:55 -0400 Subject: Shaw routing issue 12 Aug 2014 In-Reply-To: References: Message-ID: Maybe related to the 512k route issue? http://www.bgpmon.net/what-caused-todays-internet-hiccup/ I've seen people reboot to recover from TCAM exception without adjusting TCAM size only to run into the issue all over again. It's a fun way to watch the problems roll around the network. On Tue, Aug 12, 2014 at 4:40 PM, Leah Ungstad wrote: > Hi Nanog, anyone know what's up with a nationwide (Canadian) routing issue > on Shaw? > > > http://www.theregister.co.uk/2014/08/12/nationwide_outage_at_canadian_isp_shaw/ > https://community.shaw.ca/docs/DOC-3455 > > thanks > Leah > From hslabbert at stargate.ca Wed Aug 13 15:24:56 2014 From: hslabbert at stargate.ca (Hugo Slabbert) Date: Wed, 13 Aug 2014 08:24:56 -0700 Subject: Shaw routing issue 12 Aug 2014 In-Reply-To: References: Message-ID: <20140813152456.GA6861@stargate.ca> Outside looking in, but we did get a maintenance notice from Shaw in June for "Core Router reboot to resolve fully utilized IPv4 table"; let's hope for their sake they recarved TCAM while they're at it and that they don't have too many of those hiding around the network. -- Hugo On Wed 2014-Aug-13 11:08:55 -0400, Pete Lumbis wrote: >Maybe related to the 512k route issue? >http://www.bgpmon.net/what-caused-todays-internet-hiccup/ > >I've seen people reboot to recover from TCAM exception without adjusting >TCAM size only to run into the issue all over again. It's a fun way to >watch the problems roll around the network. > > >On Tue, Aug 12, 2014 at 4:40 PM, Leah Ungstad >wrote: > >> Hi Nanog, anyone know what's up with a nationwide (Canadian) routing issue >> on Shaw? >> >> >> http://www.theregister.co.uk/2014/08/12/nationwide_outage_at_canadian_isp_shaw/ >> https://community.shaw.ca/docs/DOC-3455 >> >> thanks >> Leah >> From m4rtntns at gmail.com Wed Aug 13 15:25:11 2014 From: m4rtntns at gmail.com (Martin T) Date: Wed, 13 Aug 2014 18:25:11 +0300 Subject: RTT of ICMP "TTL exceeded" messages in Level3 network remains the same throughout the network Message-ID: Hi, if I make a traceroute to a host in San Jose in Level3 network from DigitalOcean server in Amsterdam, then in Level3 network(hop 6 in example below) the RTT remains the same: # traceroute -q 1 -I ZYNGA-INC.edge1.SanJose3.Level3.net traceroute to ZYNGA-INC.edge1.SanJose3.Level3.net (4.53.208.114), 30 hops max, 60 byte packets 1 5.101.103.253 (5.101.103.253) 0.265 ms 2 95.85.0.229 (95.85.0.229) 0.236 ms 3 ix-4-2-0-0.tcore1.AV2-Amsterdam.as6453.net (195.219.194.25) 0.275 ms 4 if-7-2.tcore1.AD1-Amsterdam.as6453.net (195.219.194.46) 0.630 ms 5 4.68.63.41 (4.68.63.41) 0.635 ms 6 vl-3603-ve-227.csw2.Amsterdam1.Level3.net (4.69.162.153) 155.309 ms 7 ae-56-221.ebr2.Amsterdam1.Level3.net (4.69.153.201) 155.627 ms 8 ae-46-46.ebr2.London1.Level3.net (4.69.143.74) 153.470 ms 9 * 10 ae-61-61.csw1.NewYork1.Level3.net (4.69.134.66) 148.972 ms 11 * 12 ae-2-2.ebr1.SanJose1.Level3.net (4.69.135.185) 147.881 ms 13 ae-91-91.csw4.SanJose1.Level3.net (4.69.153.14) 149.632 ms 14 ae-4-90.edge1.SanJose3.Level3.net (4.69.152.208) 151.107 ms 15 ZYNGA-INC.edge1.SanJose3.Level3.net (4.53.208.114) 154.431 ms # In other words, one sees the RTT of the end-host as a RTT for all the hops in Level3 netwotk. If I make the traceroute to penultimate hop ae-4-90.edge1.SanJose3.Level3.net, then RTT is as expected: root at vserver:~# traceroute -q 1 -I ae-4-90.edge1.SanJose3.Level3.net traceroute to ae-4-90.edge1.SanJose3.Level3.net (4.69.152.208), 30 hops max, 60 byte packets 1 5.101.103.254 (5.101.103.254) 0.228 ms 2 95.85.0.237 (95.85.0.237) 0.217 ms 3 ix-4-2-0-0.tcore1.AV2-Amsterdam.as6453.net (195.219.194.25) 0.276 ms 4 if-7-2.tcore1.AD1-Amsterdam.as6453.net (195.219.194.46) 0.656 ms 5 4.68.63.41 (4.68.63.41) 0.607 ms 6 vl-3604-ve-228.csw2.Amsterdam1.Level3.net (4.69.162.157) 0.696 ms 7 ae-56-221.ebr2.Amsterdam1.Level3.net (4.69.153.201) 0.677 ms 8 ae-45-45.ebr2.London1.Level3.net (4.69.143.70) 7.059 ms 9 ae-44-44.ebr1.NewYork1.Level3.net (4.69.137.78) 76.311 ms 10 ae-81-81.csw3.NewYork1.Level3.net (4.69.134.74) 76.265 ms 11 ae-82-82.ebr2.NewYork1.Level3.net (4.69.148.41) 76.820 ms 12 ae-2-2.ebr1.SanJose1.Level3.net (4.69.135.185) 149.101 ms 13 ae-91-91.csw4.SanJose1.Level3.net (4.69.153.14) 150.557 ms 14 ae-4-90.edge1.SanJose3.Level3.net (4.69.152.208) 162.022 ms root at vserver:~# All the ICMP "TTL exceeded" messages except the first and the penultimate one in Level3 network have MPLS extensions header(s24.postimg.org/4z9at9z45/ICMP_echo_reply_MPLS_extensions.png) which is always the same except the tag value changes. How does this technically work? What are the advantages of such setup? thanks, Martin From hslabbert at stargate.ca Wed Aug 13 15:41:24 2014 From: hslabbert at stargate.ca (Hugo Slabbert) Date: Wed, 13 Aug 2014 08:41:24 -0700 Subject: RTT of ICMP "TTL exceeded" messages in Level3 network remains the same throughout the network In-Reply-To: References: Message-ID: <20140813154124.GA29957@stargate.ca> >How does this technically work? What are the advantages of such setup? http://forums.juniper.net/t5/Routing/what-does-quot-icmp-tunneling-quot-mean-in-mpls-vpn/td-p/164284 http://www.juniper.net/techpubs/en_US/junos12.1/topics/usage-guidelines/mpls-configuring-icmp-message-tunneling.html ...and from https://www.nanog.org/meetings/nanog49/presentations/Sunday/mpls-nanog49.pdf: > Some networks also run MPLS-only cores, which carry no IP routes. > ? This presents a problem, since if they did want to show the hops in > traceroute, the router can?t do IP routing to return the ICMP TTL > Exceed. > ? To solve this problem, an ?icmp tunneling? feature was implemented. > ? If an ICMP message is generated inside an LSP, the ICMP message is > carried all the way to the end of the LSP before being routed back. > ? This can make traceroute look really weird, since you see all the hops > along the LSP, but they all appear to have the same latency as the final > hop. This causes much end-user confusion. -- Hugo On Wed 2014-Aug-13 18:25:11 +0300, Martin T wrote: >Hi, > >if I make a traceroute to a host in San Jose in Level3 network from >DigitalOcean server in Amsterdam, then in Level3 network(hop 6 in >example below) the RTT remains the same: > ># traceroute -q 1 -I ZYNGA-INC.edge1.SanJose3.Level3.net >traceroute to ZYNGA-INC.edge1.SanJose3.Level3.net (4.53.208.114), 30 >hops max, 60 byte packets > 1 5.101.103.253 (5.101.103.253) 0.265 ms > 2 95.85.0.229 (95.85.0.229) 0.236 ms > 3 ix-4-2-0-0.tcore1.AV2-Amsterdam.as6453.net (195.219.194.25) 0.275 ms > 4 if-7-2.tcore1.AD1-Amsterdam.as6453.net (195.219.194.46) 0.630 ms > 5 4.68.63.41 (4.68.63.41) 0.635 ms > 6 vl-3603-ve-227.csw2.Amsterdam1.Level3.net (4.69.162.153) 155.309 ms > 7 ae-56-221.ebr2.Amsterdam1.Level3.net (4.69.153.201) 155.627 ms > 8 ae-46-46.ebr2.London1.Level3.net (4.69.143.74) 153.470 ms > 9 * >10 ae-61-61.csw1.NewYork1.Level3.net (4.69.134.66) 148.972 ms >11 * >12 ae-2-2.ebr1.SanJose1.Level3.net (4.69.135.185) 147.881 ms >13 ae-91-91.csw4.SanJose1.Level3.net (4.69.153.14) 149.632 ms >14 ae-4-90.edge1.SanJose3.Level3.net (4.69.152.208) 151.107 ms >15 ZYNGA-INC.edge1.SanJose3.Level3.net (4.53.208.114) 154.431 ms ># > >In other words, one sees the RTT of the end-host as a RTT for all the >hops in Level3 netwotk. If I make the traceroute to penultimate hop >ae-4-90.edge1.SanJose3.Level3.net, then RTT is as expected: > >root at vserver:~# traceroute -q 1 -I ae-4-90.edge1.SanJose3.Level3.net >traceroute to ae-4-90.edge1.SanJose3.Level3.net (4.69.152.208), 30 >hops max, 60 byte packets > 1 5.101.103.254 (5.101.103.254) 0.228 ms > 2 95.85.0.237 (95.85.0.237) 0.217 ms > 3 ix-4-2-0-0.tcore1.AV2-Amsterdam.as6453.net (195.219.194.25) 0.276 ms > 4 if-7-2.tcore1.AD1-Amsterdam.as6453.net (195.219.194.46) 0.656 ms > 5 4.68.63.41 (4.68.63.41) 0.607 ms > 6 vl-3604-ve-228.csw2.Amsterdam1.Level3.net (4.69.162.157) 0.696 ms > 7 ae-56-221.ebr2.Amsterdam1.Level3.net (4.69.153.201) 0.677 ms > 8 ae-45-45.ebr2.London1.Level3.net (4.69.143.70) 7.059 ms > 9 ae-44-44.ebr1.NewYork1.Level3.net (4.69.137.78) 76.311 ms >10 ae-81-81.csw3.NewYork1.Level3.net (4.69.134.74) 76.265 ms >11 ae-82-82.ebr2.NewYork1.Level3.net (4.69.148.41) 76.820 ms >12 ae-2-2.ebr1.SanJose1.Level3.net (4.69.135.185) 149.101 ms >13 ae-91-91.csw4.SanJose1.Level3.net (4.69.153.14) 150.557 ms >14 ae-4-90.edge1.SanJose3.Level3.net (4.69.152.208) 162.022 ms >root at vserver:~# > >All the ICMP "TTL exceeded" messages except the first and the >penultimate one in Level3 network have MPLS extensions >header(s24.postimg.org/4z9at9z45/ICMP_echo_reply_MPLS_extensions.png) >which is always the same except the tag value changes. > >How does this technically work? What are the advantages of such setup? > > >thanks, >Martin From fergdawgster at mykolab.com Wed Aug 13 15:55:32 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 13 Aug 2014 08:55:32 -0700 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: <53EB709F.8030300@mykolab.com> References: <5.1.1.6.2.20140813080649.00298e78@efes.iucc.ac.il> <14485.1407908429@turing-police.cc.vt.edu> <53EB709F.8030300@mykolab.com> Message-ID: <53EB8A74.3020603@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Apologies for replying to my own post, but... below: On 8/13/2014 7:05 AM, Paul Ferguson wrote: > On 8/13/2014 6:52 AM, Warren Kumari wrote: > >> Am I overly cynical, or does this all work out perfectly for >> some vendors? I'm guessing that a certain vendor is going to see >> a huge number of orders for new equipment, for an event that >> could have been (and was) easily predicted... "Here, buy my >> widget... and then you'll come back in a few years and buy >> another one.. ". Yup, folk purchasing these *should* >> have known (not like there was no discussions of this), but, >> well, not everyone spends all day reading NANOG / RIPE / CIDR >> report... > > I am not an operator, but I used to be a *really* active routing > engineer once upon a time in the stone age :-) and what really > bothers me is the serious lack of general awareness on the issue of > routing table size, aggregation, and stability, and what effect it > has on the global Internet. > > Especially questions like this: > > "Is it time to switch to all IPv6 yet?" > > http://tech-beta.slashdot.org/story/14/08/13/0048244/the-ipv4-internet-hiccups > > If anyone *seriously* believes that IPv6 will have any positive > effect on this particular issue, you are sorely misinformed. If > anything, it will make the problem worse, since the ability to "get > aggregation wrong" will be much easier. > > I'm not being cynical, I'm being a realist. :-/ > > - ferg > > > p.s. I recall some IPv6 prefix growth routing projections by Vince > Fuller and Tony Li from several years ago which illustrated this, > but cannot find a reference at the moment.... > > I found it: "Scaling issues with ipv6 routing+multihoming" Vince Fuller, Cisco Systems http://iab.org/wp-content/IAB-uploads/2011/03/vaf-iab-raws.pdf I think the slides [above] were done for an IAB routing workshop in ~2006. Also: "Scaling of Internet Routing and Addressing: past view, present reality,and possible futures" Vince Fuller, Cisco Systems http://www.vaf.net/~vaf/apricot?workshop.pdf FYI, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iF4EAREIAAYFAlPrinQACgkQKJasdVTchbLU/QD+LB1B4YoSjmVuipl5c5WskbWU CpGkLaxEgOsf7kxssOIA+gPWSlSDMG+86RDREGecy8/WGftSON0EHHi9pBxMDl/P =9XW4 -----END PGP SIGNATURE----- From joelja at bogus.com Wed Aug 13 18:09:36 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 13 Aug 2014 11:09:36 -0700 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: <53EB8A74.3020603@mykolab.com> References: <5.1.1.6.2.20140813080649.00298e78@efes.iucc.ac.il> <14485.1407908429@turing-police.cc.vt.edu> <53EB709F.8030300@mykolab.com> <53EB8A74.3020603@mykolab.com> Message-ID: <53EBA9E0.4060400@bogus.com> On 8/13/14 8:55 AM, Paul Ferguson wrote: > Apologies for replying to my own post, but... below: > > On 8/13/2014 7:05 AM, Paul Ferguson wrote: > > >> p.s. I recall some IPv6 prefix growth routing projections by Vince >> Fuller and Tony Li from several years ago which illustrated this, >> but cannot find a reference at the moment.... The raws workshop report makes for interesting reading, especially with respect to how things actually turned out now that we're a decade on. http://tools.ietf.org/html/rfc4984 > I found it: > > "Scaling issues with ipv6 routing+multihoming" > Vince Fuller, Cisco Systems > http://iab.org/wp-content/IAB-uploads/2011/03/vaf-iab-raws.pdf > > I think the slides [above] were done for an IAB routing workshop in ~2006. > > Also: > > "Scaling of Internet Routing and Addressing: past view, present > reality,and possible futures" > Vince Fuller, Cisco Systems > http://www.vaf.net/~vaf/apricot?workshop.pdf > > > FYI, > > - ferg > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From fergdawgster at mykolab.com Wed Aug 13 18:14:33 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 13 Aug 2014 11:14:33 -0700 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: <53EBA9E0.4060400@bogus.com> References: <5.1.1.6.2.20140813080649.00298e78@efes.iucc.ac.il> <14485.1407908429@turing-police.cc.vt.edu> <53EB709F.8030300@mykolab.com> <53EB8A74.3020603@mykolab.com> <53EBA9E0.4060400@bogus.com> Message-ID: <53EBAB09.3020307@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 8/13/2014 11:09 AM, joel jaeggli wrote: > On 8/13/14 8:55 AM, Paul Ferguson wrote: >> Apologies for replying to my own post, but... below: >> >> On 8/13/2014 7:05 AM, Paul Ferguson wrote: >> >> >>> p.s. I recall some IPv6 prefix growth routing projections by >>> Vince Fuller and Tony Li from several years ago which >>> illustrated this, but cannot find a reference at the >>> moment.... > > The raws workshop report makes for interesting reading, especially > with respect to how things actually turned out now that we're a > decade on. > > http://tools.ietf.org/html/rfc4984 > Thanks for that -- I had completely forgotten about it. :-) - - ferg >> I found it: >> >> "Scaling issues with ipv6 routing+multihoming" Vince Fuller, >> Cisco Systems >> http://iab.org/wp-content/IAB-uploads/2011/03/vaf-iab-raws.pdf >> >> I think the slides [above] were done for an IAB routing workshop >> in ~2006. >> >> Also: >> >> "Scaling of Internet Routing and Addressing: past view, present >> reality,and possible futures" Vince Fuller, Cisco Systems >> http://www.vaf.net/~vaf/apricot?workshop.pdf >> >> >> FYI, >> >> - ferg >> >> >> > > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iF4EAREIAAYFAlPrqwkACgkQKJasdVTchbJcDQEA15MMXnmxFgk3MVVJ0ikgFTtO 6XNwJ6nSqL7a6Lq/xvYA/3MM8xA4wrj6Qfy5KDyjOCu3v+hZbTok9gqNHZ+6JZSO =ef9l -----END PGP SIGNATURE----- From merike at doubleshotsecurity.com Wed Aug 13 18:27:46 2014 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Wed, 13 Aug 2014 11:27:46 -0700 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: <5.1.1.6.2.20140813080649.00298e78@efes.iucc.ac.il> <14485.1407908429@turing-police.cc.vt.edu> Message-ID: On Aug 13, 2014, at 6:52 AM, Warren Kumari wrote: > On Wed, Aug 13, 2014 at 1:40 AM, wrote: >> On Wed, 13 Aug 2014 08:08:04 +0300, Hank Nussbacher said: >> >>> We went with 768 - enough time to replace the routers with ASR9010s. It is >>> merely a stop-gap measure to give everyone time to replace their routers in >>> an orderly fashion. >> >> The same people who, knowing the 6509 had this default config issue, and >> neither replaced the gear nor did the reconfig to buy time *before* the >> wall got hit, are going to replace said 6509 in orderly fashion? > > > Sadly enough: > A: not everyone knew about the issue - there are a large number of > folk running BGP on 65xx and taking full tables who are not plugged > into NANOG / the community. In many cases they are single homed > enterprise folk, but run BGP anyway (because com consultant set it up, > some employee with clue did it years ago and then left, etc). I suspect this is true to some extent. Last NANOG had a record attendance and if I remember correctly, 300(!!!!) NEW attendees. Also, Philip Smith is STILL doing the BGP fundamentals tutorials with a full house every time. Granted this is mostly around rest of world but there are new folks coming along all the time and while many old timers are aware of all the historical info on route aggregation, this should be brought up ad nauseum for new folks. Do enterprise type educational folks who include routing tutorials do anything with route aggregation? Just wondering out loud. > B: they *did* know about the issue, but convincing management to spend > the cash to buy hardware that doesn't suck was hard, because > "everything is working fine at the moment" -- some folk needed things > to fail spectacularity to be able to justify shelling out the $$$ ( > yes, they could recard the TCAM, but they are using this as an excuse > to get some real gear)? Oh yeah, I'd bet this is also the case. Just like in 'security' related issues?. - merike > Am I overly cynical, or does this all work out perfectly for some > vendors? I'm guessing that a certain vendor is going to see a huge > number of orders for new equipment, for an event that could have been > (and was) easily predicted... "Here, buy my widget... and then you'll > come back in a few years and buy another one.. ". > Yup, folk purchasing these *should* have known (not like there was no > discussions of this), but, well, not everyone spends all day reading > NANOG / RIPE / CIDR report... > > W > > >> >> Hank, you gotta learn to wear respiratory apparatus when working near >> open containers of magic router pixie dust - that stuff can screw you up >> if you inhale it. :) > > > > -- > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From corey.touchet at corp.totalserversolutions.com Wed Aug 13 20:01:00 2014 From: corey.touchet at corp.totalserversolutions.com (Corey Touchet) Date: Wed, 13 Aug 2014 20:01:00 +0000 Subject: RTT of ICMP "TTL exceeded" messages in Level3 network remains the same throughout the network In-Reply-To: Message-ID: Depends on the setup. With MPLS and traffic engineering tunnels you can make a 30 hop path look like one hop easily. On 8/13/14, 9:25 AM, "Martin T" wrote: >Hi, > >if I make a traceroute to a host in San Jose in Level3 network from >DigitalOcean server in Amsterdam, then in Level3 network(hop 6 in >example below) the RTT remains the same: > ># traceroute -q 1 -I ZYNGA-INC.edge1.SanJose3.Level3.net >traceroute to ZYNGA-INC.edge1.SanJose3.Level3.net (4.53.208.114), 30 >hops max, 60 byte packets > 1 5.101.103.253 (5.101.103.253) 0.265 ms > 2 95.85.0.229 (95.85.0.229) 0.236 ms > 3 ix-4-2-0-0.tcore1.AV2-Amsterdam.as6453.net (195.219.194.25) 0.275 ms > 4 if-7-2.tcore1.AD1-Amsterdam.as6453.net (195.219.194.46) 0.630 ms > 5 4.68.63.41 (4.68.63.41) 0.635 ms > 6 vl-3603-ve-227.csw2.Amsterdam1.Level3.net (4.69.162.153) 155.309 ms > 7 ae-56-221.ebr2.Amsterdam1.Level3.net (4.69.153.201) 155.627 ms > 8 ae-46-46.ebr2.London1.Level3.net (4.69.143.74) 153.470 ms > 9 * >10 ae-61-61.csw1.NewYork1.Level3.net (4.69.134.66) 148.972 ms >11 * >12 ae-2-2.ebr1.SanJose1.Level3.net (4.69.135.185) 147.881 ms >13 ae-91-91.csw4.SanJose1.Level3.net (4.69.153.14) 149.632 ms >14 ae-4-90.edge1.SanJose3.Level3.net (4.69.152.208) 151.107 ms >15 ZYNGA-INC.edge1.SanJose3.Level3.net (4.53.208.114) 154.431 ms ># > >In other words, one sees the RTT of the end-host as a RTT for all the >hops in Level3 netwotk. If I make the traceroute to penultimate hop >ae-4-90.edge1.SanJose3.Level3.net, then RTT is as expected: > >root at vserver:~# traceroute -q 1 -I ae-4-90.edge1.SanJose3.Level3.net >traceroute to ae-4-90.edge1.SanJose3.Level3.net (4.69.152.208), 30 >hops max, 60 byte packets > 1 5.101.103.254 (5.101.103.254) 0.228 ms > 2 95.85.0.237 (95.85.0.237) 0.217 ms > 3 ix-4-2-0-0.tcore1.AV2-Amsterdam.as6453.net (195.219.194.25) 0.276 ms > 4 if-7-2.tcore1.AD1-Amsterdam.as6453.net (195.219.194.46) 0.656 ms > 5 4.68.63.41 (4.68.63.41) 0.607 ms > 6 vl-3604-ve-228.csw2.Amsterdam1.Level3.net (4.69.162.157) 0.696 ms > 7 ae-56-221.ebr2.Amsterdam1.Level3.net (4.69.153.201) 0.677 ms > 8 ae-45-45.ebr2.London1.Level3.net (4.69.143.70) 7.059 ms > 9 ae-44-44.ebr1.NewYork1.Level3.net (4.69.137.78) 76.311 ms >10 ae-81-81.csw3.NewYork1.Level3.net (4.69.134.74) 76.265 ms >11 ae-82-82.ebr2.NewYork1.Level3.net (4.69.148.41) 76.820 ms >12 ae-2-2.ebr1.SanJose1.Level3.net (4.69.135.185) 149.101 ms >13 ae-91-91.csw4.SanJose1.Level3.net (4.69.153.14) 150.557 ms >14 ae-4-90.edge1.SanJose3.Level3.net (4.69.152.208) 162.022 ms >root at vserver:~# > >All the ICMP "TTL exceeded" messages except the first and the >penultimate one in Level3 network have MPLS extensions >header(s24.postimg.org/4z9at9z45/ICMP_echo_reply_MPLS_extensions.png) >which is always the same except the tag value changes. > >How does this technically work? What are the advantages of such setup? > > >thanks, >Martin From randy at psg.com Wed Aug 13 20:42:50 2014 From: randy at psg.com (Randy Bush) Date: Thu, 14 Aug 2014 04:42:50 +0800 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: half the routing table is deagg crap. filter it. you mean your vendor won't give you the knobs to do it smartly ([j]tac tickets open for five years)? wonder why. randy From geoffk at geoffk.org Wed Aug 13 22:06:13 2014 From: geoffk at geoffk.org (Geoffrey Keating) Date: 13 Aug 2014 15:06:13 -0700 Subject: Shaw routing issue 12 Aug 2014 In-Reply-To: References: Message-ID: Pete Lumbis writes: > Maybe related to the 512k route issue? > http://www.bgpmon.net/what-caused-todays-internet-hiccup/ > > I've seen people reboot to recover from TCAM exception without adjusting > TCAM size only to run into the issue all over again. It's a fun way to > watch the problems roll around the network. In this case, it would probably have "helped" in the same way as rebooting or waving a rubber chicken or whatever sometimes "helps": the route issue was caused initially by a problem at Verizon that caused them to deaggregate, which they fixed, so by the time someone had identified the problem, paged someone, gotten them to the data center, had a teleconference, rebooted the device, waited for it to come back up... Verizon would have fixed it, so when it came back up it'd be back under 512k again. From rekoil at semihuman.com Wed Aug 13 22:47:48 2014 From: rekoil at semihuman.com (Chris Woodfield) Date: Wed, 13 Aug 2014 15:47:48 -0700 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: Same reason no vendor has bothered to prune redundant RIB entries (i.e. more-specific pointing to the same NH as a covering route) when programming the TCAM... -C On Aug 13, 2014, at 1:42 PM, Randy Bush wrote: > half the routing table is deagg crap. filter it. > > you mean your vendor won't give you the knobs to do it smartly ([j]tac > tickets open for five years)? wonder why. > > randy From gih at apnic.net Wed Aug 13 23:37:06 2014 From: gih at apnic.net (Geoff Huston) Date: Thu, 14 Aug 2014 09:37:06 +1000 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: <53EBAB09.3020307@mykolab.com> References: <5.1.1.6.2.20140813080649.00298e78@efes.iucc.ac.il> <14485.1407908429@turing-police.cc.vt.edu> <53EB709F.8030300@mykolab.com> <53EB8A74.3020603@mykolab.com> <53EBA9E0.4060400@bogus.com> <53EBAB09.3020307@mykolab.com> Message-ID: On 14 Aug 2014, at 4:14 am, Paul Ferguson wrote: > >> On 8/13/14 8:55 AM, Paul Ferguson wrote: >>> Apologies for replying to my own post, but... below: >>> >>> On 8/13/2014 7:05 AM, Paul Ferguson wrote: >>> >>> >>>> p.s. I recall some IPv6 prefix growth routing projections by >>>> Vince Fuller and Tony Li from several years ago which >>>> illustrated this, but cannot find a reference at the >>>> moment.... >> I shared some speculation on the next five years of routing table growth at NANOG 60. BGP routing table growth has been remarkably stable for many years, and most of the older predictive exercises have proved to be reasonably accurate. with all the usual caveats applying to a post-V4-exhaustion world having a lot more uncertainties than before the current figures show that the default free zone in IPv4 will hit 1 million entires in 2019 (http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf. slide 30). IPv6 is a much less certain exercise. If we take the most extreme picture of of the recent past and apply en exponential growth model to the IPv6 network, then the V6 table gets to 125,000 entries by the same 2019. (slide 34 of the same pack) Frankly, these figures are not particularly alarming at present. Yes, we've crossed over some equipment thresholds in the past (TCAM banks of 256K entires, now 512K and at some point its looking possible that we'll get to 1M entries. If yesterday is a lot like tomorrow then this is some 4 years out for the global routing table if we add the IPv4 and IPv6 tables together. If I were buying equipment today I'd want a minimum of 2M entries in the TCAM on the forwarding cards, and I'd also want to understand my options for field upgrades to at least 4M over the anticipated operational lifecycle of the equipment. But you may have a different crystal ball of course. Geoff From patrick at ianai.net Wed Aug 13 23:53:45 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 13 Aug 2014 19:53:45 -0400 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: On Aug 13, 2014, at 16:42 , Randy Bush wrote: > half the routing table is deagg crap. filter it. We disagree. Just because you don't like all more specifics doesn't mean they are useless. Not everything is about minimizing FIB size. (And RIB size hasn't been relevant for years.) People pay an ass-ton of money to save a few ms off their RTT, if a more specific will allow packets to travel LHR->FRA directly instead of packets going from LHR -> SFO -> FRA, they are useful even if there is a covering prefix. > you mean your vendor won't give you the knobs to do it smartly ([j]tac > tickets open for five years)? wonder why. Might be useful if you mentioned what you considered a "smart" way to trim the fib. But then you couldn't bitch and moan about people not understanding you, which is the real reason you post to NANOG. -- TTFN, patrick From bill at herrin.us Thu Aug 14 00:12:50 2014 From: bill at herrin.us (William Herrin) Date: Wed, 13 Aug 2014 20:12:50 -0400 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: On Wed, Aug 13, 2014 at 6:47 PM, Chris Woodfield wrote: > On Aug 13, 2014, at 1:42 PM, Randy Bush wrote: >> half the routing table is deagg crap. filter it. >> >> you mean your vendor won't give you the knobs to do it smartly ([j]tac >> tickets open for five years)? wonder why. > Same reason no vendor has bothered to prune redundant RIB > entries (i.e. more-specific pointing to the same NH as a covering > route) when programming the TCAM... Hi Chris, Not so much, no. Pruning seemingly redundant entries from BGP is actually impossible to do safely, or if not impossible at least no one has demonstrated a successful algorithm that can prune even a single entry anywhere but the BGP source node or a BGP leaf node. And there's not much point in pruning the BGP RIB at a BGP leaf node -- DRAM to hold the RIB once received and processed is plentiful and inexpensive. Pruning FIB entries, on the other hand, can be done quite safely as long as you're willing to accept the conversion of "null route" to "don't care." Some experiments were done on this in the IETF a couple years back. Draft-zhang-fibaggregation maybe? Savings of 30% in typical backbone nodes looked possible. That's 30% of your TCAM reclaimable. For the moment it seems to be cheaper to just build bigger TCAMs. Cheaper for the router vendors anyway. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: Can I solve your unusual networking challenges? From rekoil at semihuman.com Thu Aug 14 00:20:16 2014 From: rekoil at semihuman.com (Chris Woodfield) Date: Wed, 13 Aug 2014 17:20:16 -0700 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: > > Pruning FIB entries, on the other hand, can be done quite safely as > long as you're willing to accept the conversion of "null route" to > "don't care." Some experiments were done on this in the IETF a couple > years back. Draft-zhang-fibaggregation maybe? Savings of 30% in > typical backbone nodes looked possible. That's 30% of your TCAM > reclaimable. > Hence the ?when programming the TCAM? part of my original statement :) > For the moment it seems to be cheaper to just build bigger TCAMs. > Cheaper for the router vendors anyway. > I think of it more like ?why spend development dollars on a feature that will cause my customers to keep their existing hardware longer and delay upgrades?? Yes, vendors do think like that. -C > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > Can I solve your unusual networking challenges? From alumbis at gmail.com Thu Aug 14 01:07:08 2014 From: alumbis at gmail.com (Pete Lumbis) Date: Wed, 13 Aug 2014 21:07:08 -0400 Subject: Shaw routing issue 12 Aug 2014 In-Reply-To: References: Message-ID: Yep. Most of the time I've seen this it's two data centers, both go TCAM exception. You reboot DC1, when it comes back up you reboot DC2. This means no iBGP learned routes so DC1 is fine. DC 2 is fine, until the iBGP peer comes back and then start all over again. On Wed, Aug 13, 2014 at 6:06 PM, Geoffrey Keating wrote: > Pete Lumbis writes: > > > Maybe related to the 512k route issue? > > http://www.bgpmon.net/what-caused-todays-internet-hiccup/ > > > > I've seen people reboot to recover from TCAM exception without adjusting > > TCAM size only to run into the issue all over again. It's a fun way to > > watch the problems roll around the network. > > In this case, it would probably have "helped" in the same way as > rebooting or waving a rubber chicken or whatever sometimes "helps": the > route issue was caused initially by a problem at Verizon that > caused them to deaggregate, which they fixed, so by the time someone had > identified the problem, paged someone, gotten them to the data center, > had a teleconference, rebooted the device, waited for it to come back > up... Verizon would have fixed it, so when it came back up it'd be > back under 512k again. > From rbf+nanog at panix.com Thu Aug 14 02:49:51 2014 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Wed, 13 Aug 2014 21:49:51 -0500 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: <20140814024951.GA20892@panix.com> On Wed, Aug 13, 2014 at 07:53:45PM -0400, Patrick W. Gilmore wrote: > > you mean your vendor won't give you the knobs to do it smartly ([j]tac > > tickets open for five years)? wonder why. > > Might be useful if you mentioned what you considered a "smart" way to > trim the fib. But then you couldn't bitch and moan about people not > understanding you, which is the real reason you post to NANOG. Optimization #1 -- elimination of more specifics where there's a less specific that has the same next hop (obviously only in cases where the less specific is the one that would be used if the more specific were left out). Example: if 10.10.4.0/22 has the same next hop as 10.10.7.0/24, the latter can be left out of TCAM (assuming there's not a 10.10.6.0/23 with a different next hop). Optimization #2 -- concatenation of adjacent routes when they have the same next hop Example: If 10.10.12.0/15 and 10.10.14.0/15 have the same next hop, leave them both out of TCAM and install 10.10.14.0/14 Optimization #3 -- elimination of routes that have more specifics for their entire range. Example: Don't program 10.10.4.0/22 in TCAM is 10.10.4.0/23, 10.10.6.0/24 an 10.10.7.0/24 all exist Some additional points: -- This isn't that hard to implement. Once you have a FIB and primitives for manipulating it, it's not especially difficult to extend them to also maintain a minimal-size-FIB. -- The key is that aggregation need not be limited to identical routes. Any two routes *that have the same next hop from the perspective of the router doing the aggregating* can be aggregated in TCAM. DFZ routers have half a million routes, but comparatively few direct adjacencies. So lots of opportunity to aggregate. -- What I've described above gives forwarding behavior *identical* to unaggregated forwarding behavior, but with fewer TCAM entries. Obviously, you can get further reductions if you're willing to accept different behavior (for example, igoring more specifics when there's a less specific, even if the less specific has a different next hop). (This might or might not be what Randy was talking about. Maybe he's looking for knobs to allow some routes to be excluded from TCAM at the expense of changing forwarding behavior. But even without any such things, there's still opportunity to meaningfully reduce usage just by handling the cases where forwarding behavior will not change.) -- Brett From ops.lists at gmail.com Thu Aug 14 02:59:39 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 14 Aug 2014 08:29:39 +0530 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: <20140814024951.GA20892@panix.com> References: <20140814024951.GA20892@panix.com> Message-ID: Swisscom or some other European SP has / used to have a limit where they would not accept more specific routes than say a /22 from provider x, so if you wanted to take a /24 and announce it you were SOL sending packets to them from that /24 over provider y. Still, for elderly and capacity limited routers, that might work. On Thursday, August 14, 2014, Brett Frankenberger wrote: > On Wed, Aug 13, 2014 at 07:53:45PM -0400, Patrick W. Gilmore wrote: > > > you mean your vendor won't give you the knobs to do it smartly ([j]tac > > > tickets open for five years)? wonder why. > > > > Might be useful if you mentioned what you considered a "smart" way to > > trim the fib. But then you couldn't bitch and moan about people not > > understanding you, which is the real reason you post to NANOG. > > Optimization #1 -- elimination of more specifics where there's a less > specific that has the same next hop (obviously only in cases where the > less specific is the one that would be used if the more specific were > left out). > > Example: if 10.10.4.0/22 has the same next hop as 10.10.7.0/24, the > latter can be left out of TCAM (assuming there's not a 10.10.6.0/23 > with a different next hop). > > Optimization #2 -- concatenation of adjacent routes when they have the > same next hop > > Example: If 10.10.12.0/15 and 10.10.14.0/15 have the same next hop, > leave them both out of TCAM and install 10.10.14.0/14 > > Optimization #3 -- elimination of routes that have more specifics for > their entire range. > > Example: Don't program 10.10.4.0/22 in TCAM is 10.10.4.0/23, > 10.10.6.0/24 an 10.10.7.0/24 all exist > > Some additional points: > > -- This isn't that hard to implement. Once you have a FIB and > primitives for manipulating it, it's not especially difficult to extend > them to also maintain a minimal-size-FIB. > > -- The key is that aggregation need not be limited to identical routes. > Any two routes *that have the same next hop from the perspective of the > router doing the aggregating* can be aggregated in TCAM. DFZ routers > have half a million routes, but comparatively few direct adjacencies. > So lots of opportunity to aggregate. > > -- What I've described above gives forwarding behavior *identical* to > unaggregated forwarding behavior, but with fewer TCAM entries. > Obviously, you can get further reductions if you're willing to accept > different behavior (for example, igoring more specifics when there's a > less specific, even if the less specific has a different next hop). > > (This might or might not be what Randy was talking about. Maybe he's > looking for knobs to allow some routes to be excluded from TCAM at the > expense of changing forwarding behavior. But even without any such > things, there's still opportunity to meaningfully reduce usage just by > handling the cases where forwarding behavior will not change.) > > -- Brett > -- --srs (iPad) From cma at cmadams.net Thu Aug 14 03:09:53 2014 From: cma at cmadams.net (Chris Adams) Date: Wed, 13 Aug 2014 22:09:53 -0500 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: <20140814024951.GA20892@panix.com> References: <20140814024951.GA20892@panix.com> Message-ID: <20140814030953.GC28025@cmadams.net> Once upon a time, Brett Frankenberger said: > -- This isn't that hard to implement. Once you have a FIB and > primitives for manipulating it, it's not especially difficult to extend > them to also maintain a minimal-size-FIB. I would say it is hard to implement, or at least non-trivial. Building a reduced FIB from a given RIB is not hard, but then RIB changes become more complex (possibly significantly so) to process into FIB updates. For example, the control plane receives a BGP update that removes a route from the RIB. Right now, the check is simply "was this the best path" (and if so, "was it in the FIB" for systems with RIB->FIB filtering methods). If so, remove it from the FIB. If there's a next-best path in the RIB, add it to the FIB. With a compacted FIB, a RIB update has to check a bunch of different things to see what (if any) FIB updates are required. This could also require other RIB updates (to mark other RIB entries as now in or out of the FIB). The lowest-overhead method would probably be for the control plane to keep a separate (non-compacted) copy of the FIB, with all the pointers to how things were compacted before sending to the forwarding plane compacted FIB. That would take up more control plane RAM (and still add CPU overhead to every RIB change). If you thought things like rpd stalls on JUNOS were fun before, imagine the excitement you could have with FIB compacting! -- Chris Adams From patrick at ianai.net Thu Aug 14 04:15:36 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 14 Aug 2014 00:15:36 -0400 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: <20140814024951.GA20892@panix.com> Message-ID: Composed on a virtual keyboard, please forgive typos. > On Aug 13, 2014, at 22:59, Suresh Ramasubramanian wrote: > > Swisscom or some other European SP has / used to have a limit where they would not accept more specific routes than say a /22 from provider x, so if you wanted to take a /24 and announce it you were SOL sending packets to them from that /24 over provider y. > > Still, for elderly and capacity limited routers, that might work. And Sprint used to filter on /19s outside swamp space. (See NANOG 1999 archives for my [wrong then corrected] interpretation of ACL112.) Etc., etc. For stub networks, especially ones who are not as performance sensitive, this can help extend the life of their routers. But not everyone can make AGS+s work for years past their useful life or get "-doran" IOS builds. The 6500 was first sold in 1999. I'm impressed it has lasted this long, even with new sups. Time to start thinking about upgrading. As for networks providing transit, those were highly unsound policies, IMHO. I specifically did not buy from Sprint then or Verio later when they did it, and I was not alone. Giving your customers less than full routes has lots of bad side effects, such as less revenue when they don't pick you because you don't have the route. -- TTFN, patrick >> On Thursday, August 14, 2014, Brett Frankenberger wrote: >> On Wed, Aug 13, 2014 at 07:53:45PM -0400, Patrick W. Gilmore wrote: >> > > you mean your vendor won't give you the knobs to do it smartly ([j]tac >> > > tickets open for five years)? wonder why. >> > >> > Might be useful if you mentioned what you considered a "smart" way to >> > trim the fib. But then you couldn't bitch and moan about people not >> > understanding you, which is the real reason you post to NANOG. >> >> Optimization #1 -- elimination of more specifics where there's a less >> specific that has the same next hop (obviously only in cases where the >> less specific is the one that would be used if the more specific were >> left out). >> >> Example: if 10.10.4.0/22 has the same next hop as 10.10.7.0/24, the >> latter can be left out of TCAM (assuming there's not a 10.10.6.0/23 >> with a different next hop). >> >> Optimization #2 -- concatenation of adjacent routes when they have the >> same next hop >> >> Example: If 10.10.12.0/15 and 10.10.14.0/15 have the same next hop, >> leave them both out of TCAM and install 10.10.14.0/14 >> >> Optimization #3 -- elimination of routes that have more specifics for >> their entire range. >> >> Example: Don't program 10.10.4.0/22 in TCAM is 10.10.4.0/23, >> 10.10.6.0/24 an 10.10.7.0/24 all exist >> >> Some additional points: >> >> -- This isn't that hard to implement. Once you have a FIB and >> primitives for manipulating it, it's not especially difficult to extend >> them to also maintain a minimal-size-FIB. >> >> -- The key is that aggregation need not be limited to identical routes. >> Any two routes *that have the same next hop from the perspective of the >> router doing the aggregating* can be aggregated in TCAM. DFZ routers >> have half a million routes, but comparatively few direct adjacencies. >> So lots of opportunity to aggregate. >> >> -- What I've described above gives forwarding behavior *identical* to >> unaggregated forwarding behavior, but with fewer TCAM entries. >> Obviously, you can get further reductions if you're willing to accept >> different behavior (for example, igoring more specifics when there's a >> less specific, even if the less specific has a different next hop). >> >> (This might or might not be what Randy was talking about. Maybe he's >> looking for knobs to allow some routes to be excluded from TCAM at the >> expense of changing forwarding behavior. But even without any such >> things, there's still opportunity to meaningfully reduce usage just by >> handling the cases where forwarding behavior will not change.) >> >> -- Brett > > > -- > --srs (iPad) From bmanning at isi.edu Thu Aug 14 04:23:10 2014 From: bmanning at isi.edu (manning bill) Date: Wed, 13 Aug 2014 21:23:10 -0700 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: <20140814024951.GA20892@panix.com> Message-ID: <09F0F6DC-16B6-4C02-96A8-78823EA4E5F4@isi.edu> Sprint used to proxy aggregate? I remember 128.0.0.0/3 the real question, imho, is if folks are going to look into their crystal balls and roadmap where the default offered is a /32 (either v4 or v6) and plan accordingly, or just slap another bandaid on the oozing wound... /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 13August2014Wednesday, at 21:15, Patrick W. Gilmore wrote: > Composed on a virtual keyboard, please forgive typos. > >> On Aug 13, 2014, at 22:59, Suresh Ramasubramanian wrote: >> >> Swisscom or some other European SP has / used to have a limit where they would not accept more specific routes than say a /22 from provider x, so if you wanted to take a /24 and announce it you were SOL sending packets to them from that /24 over provider y. >> >> Still, for elderly and capacity limited routers, that might work. > > And Sprint used to filter on /19s outside swamp space. (See NANOG 1999 archives for my [wrong then corrected] interpretation of ACL112.) Etc., etc. > > For stub networks, especially ones who are not as performance sensitive, this can help extend the life of their routers. But not everyone can make AGS+s work for years past their useful life or get "-doran" IOS builds. The 6500 was first sold in 1999. I'm impressed it has lasted this long, even with new sups. Time to start thinking about upgrading. > > As for networks providing transit, those were highly unsound policies, IMHO. I specifically did not buy from Sprint then or Verio later when they did it, and I was not alone. Giving your customers less than full routes has lots of bad side effects, such as less revenue when they don't pick you because you don't have the route. > > -- > TTFN, > patrick > > >>> On Thursday, August 14, 2014, Brett Frankenberger wrote: >>> On Wed, Aug 13, 2014 at 07:53:45PM -0400, Patrick W. Gilmore wrote: >>>>> you mean your vendor won't give you the knobs to do it smartly ([j]tac >>>>> tickets open for five years)? wonder why. >>>> >>>> Might be useful if you mentioned what you considered a "smart" way to >>>> trim the fib. But then you couldn't bitch and moan about people not >>>> understanding you, which is the real reason you post to NANOG. >>> >>> Optimization #1 -- elimination of more specifics where there's a less >>> specific that has the same next hop (obviously only in cases where the >>> less specific is the one that would be used if the more specific were >>> left out). >>> >>> Example: if 10.10.4.0/22 has the same next hop as 10.10.7.0/24, the >>> latter can be left out of TCAM (assuming there's not a 10.10.6.0/23 >>> with a different next hop). >>> >>> Optimization #2 -- concatenation of adjacent routes when they have the >>> same next hop >>> >>> Example: If 10.10.12.0/15 and 10.10.14.0/15 have the same next hop, >>> leave them both out of TCAM and install 10.10.14.0/14 >>> >>> Optimization #3 -- elimination of routes that have more specifics for >>> their entire range. >>> >>> Example: Don't program 10.10.4.0/22 in TCAM is 10.10.4.0/23, >>> 10.10.6.0/24 an 10.10.7.0/24 all exist >>> >>> Some additional points: >>> >>> -- This isn't that hard to implement. Once you have a FIB and >>> primitives for manipulating it, it's not especially difficult to extend >>> them to also maintain a minimal-size-FIB. >>> >>> -- The key is that aggregation need not be limited to identical routes. >>> Any two routes *that have the same next hop from the perspective of the >>> router doing the aggregating* can be aggregated in TCAM. DFZ routers >>> have half a million routes, but comparatively few direct adjacencies. >>> So lots of opportunity to aggregate. >>> >>> -- What I've described above gives forwarding behavior *identical* to >>> unaggregated forwarding behavior, but with fewer TCAM entries. >>> Obviously, you can get further reductions if you're willing to accept >>> different behavior (for example, igoring more specifics when there's a >>> less specific, even if the less specific has a different next hop). >>> >>> (This might or might not be what Randy was talking about. Maybe he's >>> looking for knobs to allow some routes to be excluded from TCAM at the >>> expense of changing forwarding behavior. But even without any such >>> things, there's still opportunity to meaningfully reduce usage just by >>> handling the cases where forwarding behavior will not change.) >>> >>> -- Brett >> >> >> -- >> --srs (iPad) From snoble at sonn.com Thu Aug 14 04:47:10 2014 From: snoble at sonn.com (Steve Noble) Date: Wed, 13 Aug 2014 21:47:10 -0700 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: <09F0F6DC-16B6-4C02-96A8-78823EA4E5F4@isi.edu> References: <20140814024951.GA20892@panix.com> <09F0F6DC-16B6-4C02-96A8-78823EA4E5F4@isi.edu> Message-ID: <53EC3F4E.2000004@sonn.com> Sprint also had 192/2 in the RADB :) manning bill wrote: > > Sprint used to proxy aggregate? I remember 128.0.0.0/3 > > the real question, imho, is if folks are going to look into their > crystal balls and roadmap where the default offered is a /32 (either > v4 or v6) > and plan accordingly, or just slap another bandaid on the oozing wound... > > /bill > PO Box 12317 > Marina del Rey, CA 90295 > 310.322.8102 > From dorian at blackrose.org Thu Aug 14 05:47:20 2014 From: dorian at blackrose.org (Dorian Kim) Date: Thu, 14 Aug 2014 01:47:20 -0400 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: <20140814024951.GA20892@panix.com> Message-ID: <20140814054720.GD26142@blackrose.org> On Thu, Aug 14, 2014 at 12:15:36AM -0400, Patrick W. Gilmore wrote: > Composed on a virtual keyboard, please forgive typos. > > > On Aug 13, 2014, at 22:59, Suresh Ramasubramanian wrote: > > > > Swisscom or some other European SP has / used to have a limit where they would not accept more specific routes than say a /22 from provider x, so if you wanted to take a /24 and announce it you were SOL sending packets to them from that /24 over provider y. > > > > Still, for elderly and capacity limited routers, that might work. > > And Sprint used to filter on /19s outside swamp space. (See NANOG 1999 archives for my [wrong then corrected] interpretation of ACL112.) Etc., etc. > > For stub networks, especially ones who are not as performance sensitive, this can help extend the life of their routers. But not everyone can make AGS+s work for years past their useful life or get "-doran" IOS builds. The 6500 was first sold in 1999. I'm impressed it has lasted this long, even with new sups. Time to start thinking about upgrading. Just as a historical note, Sprint didn't have AGS+ or such equipment that were being propped up by the /19 filters (at least for the vast majority of the filter's existence). Neither did Verio. Those filters were primarily an attempt to enforce a certain behavior. Also, my recollection is that during that era "named" builds were typically named via receipient's well known email id, e.g."-smd" or first name "-sean" and I don't think I've ever seen it named after the last name unless it was their email id as well. -dorian From mark.tinka at seacom.mu Thu Aug 14 06:04:48 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 14 Aug 2014 08:04:48 +0200 Subject: Muni Fiber and Politics In-Reply-To: <10900562.7801.1407163119466.JavaMail.root@benjamin.baylink.com> References: <10900562.7801.1407163119466.JavaMail.root@benjamin.baylink.com> Message-ID: <201408140804.51459.mark.tinka@seacom.mu> On Monday, August 04, 2014 04:38:39 PM Jay Ashworth wrote: > So that implies he really did mean 44x GigE to end-prem, > from 4 $5500 10G ports -- or, $500/home in MRC *cost* to > the provider. > > I'm confused. With an edge router chassis filled with 10Gbps ports for various things, they quickly become a lot cheaper than US$5,500 a pop :-). I realize that this may not be a universal case. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From randy at psg.com Thu Aug 14 06:13:53 2014 From: randy at psg.com (Randy Bush) Date: Thu, 14 Aug 2014 15:13:53 +0900 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: <20140814024951.GA20892@panix.com> References: <20140814024951.GA20892@panix.com> Message-ID: >>> you mean your vendor won't give you the knobs to do it smartly ([j]tac >>> tickets open for five years)? wonder why. >> >> Might be useful if you mentioned what you considered a "smart" way to >> trim the fib. But then you couldn't bitch and moan about people not >> understanding you, which is the real reason you post to NANOG. i did not get the original of this post, but the ad hominem speaks for it pathetic self. > Optimization #1 -- elimination of more specifics where there's a less > specific that has the same next hop (obviously only in cases where the > less specific is the one that would be used if the more specific were > left out). > > Example: if 10.10.4.0/22 has the same next hop as 10.10.7.0/24, the > latter can be left out of TCAM (assuming there's not a 10.10.6.0/23 > with a different next hop). > > Optimization #2 -- concatenation of adjacent routes when they have the > same next hop > > Example: If 10.10.12.0/15 and 10.10.14.0/15 have the same next hop, > leave them both out of TCAM and install 10.10.14.0/14 > > Optimization #3 -- elimination of routes that have more specifics for > their entire range. > > Example: Don't program 10.10.4.0/22 in TCAM is 10.10.4.0/23, > 10.10.6.0/24 an 10.10.7.0/24 all exist those are some of the cases. i guess i should dig up the old [j]tac tickets. randy From dorian at blackrose.org Thu Aug 14 06:23:12 2014 From: dorian at blackrose.org (Dorian Kim) Date: Thu, 14 Aug 2014 02:23:12 -0400 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: <20140814054720.GD26142@blackrose.org> References: <20140814024951.GA20892@panix.com> <20140814054720.GD26142@blackrose.org> Message-ID: <20140814062312.GF26142@blackrose.org> On Thu, Aug 14, 2014 at 01:47:20AM -0400, Dorian Kim wrote: > On Thu, Aug 14, 2014 at 12:15:36AM -0400, Patrick W. Gilmore wrote: > > Composed on a virtual keyboard, please forgive typos. > > > > > On Aug 13, 2014, at 22:59, Suresh Ramasubramanian wrote: > > > > > > Swisscom or some other European SP has / used to have a limit where they would not accept more specific routes than say a /22 from provider x, so if you wanted to take a /24 and announce it you were SOL sending packets to them from that /24 over provider y. > > > > > > Still, for elderly and capacity limited routers, that might work. > > > > And Sprint used to filter on /19s outside swamp space. (See NANOG 1999 archives for my [wrong then corrected] interpretation of ACL112.) Etc., etc. > > > > For stub networks, especially ones who are not as performance sensitive, this can help extend the life of their routers. But not everyone can make AGS+s work for years past their useful life or get "-doran" IOS builds. The 6500 was first sold in 1999. I'm impressed it has lasted this long, even with new sups. Time to start thinking about upgrading. > > Just as a historical note, Sprint didn't have AGS+ or such equipment that were being propped up by the /19 filters (at least for the vast majority > of the filter's existence). Neither did Verio. Those filters were primarily an attempt to enforce a certain behavior. It was kindly pointed out to me in private that my phrasing could be misleading here. When ACL112 came into being, there were old equipment that were being protected by the /19 filters. However, the filters were in place long after those equipment were replaced. -dorian From randy at psg.com Thu Aug 14 06:36:31 2014 From: randy at psg.com (Randy Bush) Date: Thu, 14 Aug 2014 15:36:31 +0900 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: <20140814062312.GF26142@blackrose.org> References: <20140814024951.GA20892@panix.com> <20140814054720.GD26142@blackrose.org> <20140814062312.GF26142@blackrose.org> Message-ID: > It was kindly pointed out to me in private that my phrasing could be > misleading here. > > When ACL112 came into being, there were old equipment that were being > protected by the /19 filters. However, the filters were in place long > after those equipment were replaced. but by then it had driven all sorts of filtering and a negotiated (at danvers) treaty with the rirs to allocate on /19. another note from our private aside, it is worth noting that verio's satanic phyltres meant we did not even notice the 7007 and 128/9 disasters. we read about them on nanog (or com-priv?). randy From mansaxel at besserwisser.org Thu Aug 14 07:22:45 2014 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Thu, 14 Aug 2014 09:22:45 +0200 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: <5.1.1.6.2.20140813080649.00298e78@efes.iucc.ac.il> <14485.1407908429@turing-police.cc.vt.edu> Message-ID: <20140814072245.GI21786@besserwisser.org> Subject: Re: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today Date: Wed, Aug 13, 2014 at 11:27:46AM -0700 Quoting Merike Kaeo (merike at doubleshotsecurity.com): > > B: they *did* know about the issue, but convincing management to spend > > the cash to buy hardware that doesn't suck was hard, because > > "everything is working fine at the moment" -- some folk needed things > > to fail spectacularity to be able to justify shelling out the $$$ ( > > yes, they could recard the TCAM, but they are using this as an excuse > > to get some real gear)? > > Oh yeah, I'd bet this is also the case. Just like in 'security' related issues?. This is why "test crash" was introduced. http://markmail.org/message/tu46ecy272o3stvp /M?ns, just rebooted. (with a new carving already configured) -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Thousands of days of civilians ... have produced a ... feeling for the aesthetic modules -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From sander at steffann.nl Thu Aug 14 11:13:01 2014 From: sander at steffann.nl (Sander Steffann) Date: Thu, 14 Aug 2014 13:13:01 +0200 Subject: fire ants In-Reply-To: References: <20140812155245.pfyjdfn7woc4c8ck@fcaglp.fcaglp.unlp.edu.ar> <53EA73C2.9080601@flowtools.net> <8a851a5b5afc6aa78c709d08b95e82c3@thefnf.org> Message-ID: <93733F72-A60D-4B51-B304-495BFB093798@steffann.nl> Hi Suresh, Op 13 aug. 2014, om 03:16 heeft Suresh Ramasubramanian het volgende geschreven: > Needs an "Anthill Inside" sticker like Hex at the Unseen University. I should have bought one at the Discworld Convention last weekend :) http://www.pjsmprints.com/stickers/index.html Cheers, Sander From owen at delong.com Thu Aug 14 11:52:13 2014 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Aug 2014 04:52:13 -0700 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: <53EC3F4E.2000004@sonn.com> References: <20140814024951.GA20892@panix.com> <09F0F6DC-16B6-4C02-96A8-78823EA4E5F4@isi.edu> <53EC3F4E.2000004@sonn.com> Message-ID: I believe at one point, SPRINT had in the RADB (and actively advertised) 0.0.0.0/2, 64.0.0.0/2, 128.0.0.0/2, and 192.0.0.0/2 under something called ?Quarter Default Route, see Rational Default Project? or words to that effect. I could be wrong. It was a long time ago and I barely remember SPRINT any more. Owen On Aug 13, 2014, at 9:47 PM, Steve Noble wrote: > Sprint also had 192/2 in the RADB :) > > manning bill wrote: >> >> Sprint used to proxy aggregate? I remember 128.0.0.0/3 >> >> the real question, imho, is if folks are going to look into their crystal balls and roadmap where the default offered is a /32 (either v4 or v6) >> and plan accordingly, or just slap another bandaid on the oozing wound... >> >> /bill >> PO Box 12317 >> Marina del Rey, CA 90295 >> 310.322.8102 >> From halflife4 at gmx.com Thu Aug 14 12:48:58 2014 From: halflife4 at gmx.com (Toney Mareo) Date: Thu, 14 Aug 2014 14:48:58 +0200 Subject: [HFC] pooling modems in layer2 In-Reply-To: References: , Message-ID: Hello ? Thanks for the responses, I think it clarified a lot and I already started reading this CM-SP-L2VPN-I13-140403.pdf documentation. What I need here is that existing clients are sent through ISP1 currently and I would like to add ISP2 for future clients without interfering anything with the current operations. Then later on move the old clients over to ISP2 as well. ? As I see it, this can only be done on the CMTS device not after it unless it's possible to relay packets from the cable side with their original HFC macs through the CMTS. ? Yes indeed I do not want to setup failover or balance DHCP servers, but I want to move every new subscriber to a different pool which gets directed to a different DHCP server which then finally able to provide the modems with ips and other settings to be able to go out on ISP2. ? ? On Tue, Aug 12, 2014 at 10:23 AM, Toney Mareo wrote:Hello I think it's kind of an isp secret but I would be curious how do people distribute modems to pools before they would even reach the actual IP network so on layer2: http://dl.packetstormsecurity.net/papers/evaluation/docsis/Service_Distribution.jpg[http://dl.packetstormsecurity.net/papers/evaluation/docsis/Service_Distribution.jpg] ? Certainly not secret, DOCSIS is a very well documented protocol with most of the information being publicly available. ? For this I would like to get some clarification because I do not work in the telco industry. As I can figure out of the docsis, cablelabs documents. The CMTS device is connected to the coax segments through fiber. Therefore one could say that the "modem facing" side is a fiber optic interface but it's not 1000 Base-FX, not a regular Ethernet over fiber. It sends signals through a broad range of frequencies. ? While fiber is commonly used in cable plants as part of a HFC network its completely transparent from a protocol standpoint the entire communication is over RF. ?D3 and older uses QAM modulation and the downstream runs over "normal" 6 MHz channels which are the same as TV channels. ? ? So what I would like to accomplish to provide a different pool of dhcp servers, which provides different config file, tod server, router, dns etc. infos to the modems but to do all this in Layer2. ? Why? ?The operator is the only one who can tell the CMTS which DHCP server(s) to send traffic to and modern CMTSs do that as an IP relay and passes its IP address as the GIADDR. ? Because I advise the operator, you would think they are expert on the CMTS? Think again, I'm not an expert either but at least I learning. ? I don't have hands on experience with CMTS-es but I would think that they are able to pool clients by MACs and able to send eg 500 clients to DHCP server1 and the other 1500 to DHCP server2 before they would even get an IP, so I talking of pure layer2 here! ? Not exactly, first in nearly all cases the DHCP communication is an IP unicast rather than a layer 2 broadcast. ?Second, the way that the DHCP server is selected is normally based on the type of device so that modems get a specific GIADDR, CPE (PCs, routers behind modems, etc) get another one, and often the EMTA gets a third. ?It might be possible to do that off a count of devices, but if so it will be more of a load balancing scenario rather than these specific 500 CMs get this DHCP server. ?It is possible to do open access in a DOCSIS system, but its very difficult and involves creating filters in both the CMTS and CM configurations. ? Let's say if the CMTS device does not support this, what are the other options for routing layer2 traffic coming out of the CMTS? If I would know more about the device I would say that put a linuxbox after it (on the ISP facing nic) and mark the packets going out with arptables/ebtables then send them out of different nics to different dhcp servers. ? It doesn't really work that way, but the closest thing is a "soft" tunnel that gets used for things like transparent LAN services, carrier WiFi, and a few other use cases.? ? http://www.cablelabs.com/wp-content/uploads/specdocs/CM-SP-L2VPN-I09-100611.pdf[http://www.cablelabs.com/wp-content/uploads/specdocs/CM-SP-L2VPN-I09-100611.pdf] ? Any suggestions are welcome. From khelms at zcorum.com Thu Aug 14 12:54:33 2014 From: khelms at zcorum.com (Scott Helms) Date: Thu, 14 Aug 2014 08:54:33 -0400 Subject: [HFC] pooling modems in layer2 In-Reply-To: References: Message-ID: Toney, Depending on which DHCP server software you're using, its probably easier to do this kind of move with it rather than trying to build layer 2 tunnels. Since each modem MAC is added (usually) to the DHCP server you can simply run two different server instances and with the original server instance handing out ISP1 IP information and the second one handing out ISP2 addresses and info. The only gotcha is that you have to make sure your DHCP servers won't NAK unknown clients, but this is how most of the conversions I've been involved with are done. Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Thu, Aug 14, 2014 at 8:48 AM, Toney Mareo wrote: > Hello > > > Thanks for the responses, I think it clarified a lot and I already started > reading this CM-SP-L2VPN-I13-140403.pdf documentation. > > What I need here is that existing clients are sent through ISP1 currently > and I would like to add ISP2 for future clients without interfering > anything with the current operations. Then later on move the old clients > over to ISP2 as well. > > As I see it, this can only be done on the CMTS device not after it unless > it's possible to relay packets from the cable side with their original HFC > macs through the CMTS. > > Yes indeed I do not want to setup failover or balance DHCP servers, but I > want to move every new subscriber to a different pool which gets directed > to a different DHCP server which then finally able to provide the modems > with ips and other settings to be able to go out on ISP2. > > > > On Tue, Aug 12, 2014 at 10:23 AM, Toney Mareo > wrote:Hello > > I think it's kind of an isp secret but I would be curious how do people > distribute modems to pools before they would even reach the actual IP > network so on layer2: > > > http://dl.packetstormsecurity.net/papers/evaluation/docsis/Service_Distribution.jpg[http://dl.packetstormsecurity.net/papers/evaluation/docsis/Service_Distribution.jpg] > > Certainly not secret, DOCSIS is a very well documented protocol with most > of the information being publicly available. > > > > For this I would like to get some clarification because I do not work in > the telco industry. As I can figure out of the docsis, cablelabs documents. > The CMTS device is connected to the coax segments through fiber. Therefore > one could say that the "modem facing" side is a fiber optic interface but > it's not 1000 Base-FX, not a regular Ethernet over fiber. It sends signals > through a broad range of frequencies. > > While fiber is commonly used in cable plants as part of a HFC network its > completely transparent from a protocol standpoint the entire communication > is over RF. D3 and older uses QAM modulation and the downstream runs over > "normal" 6 MHz channels which are the same as TV channels. > > > So what I would like to accomplish to provide a different pool of dhcp > servers, which provides different config file, tod server, router, dns etc. > infos to the modems but to do all this in Layer2. > > Why? The operator is the only one who can tell the CMTS which DHCP > server(s) to send traffic to and modern CMTSs do that as an IP relay and > passes its IP address as the GIADDR. > > Because I advise the operator, you would think they are expert on the > CMTS? Think again, I'm not an expert either but at least I learning. > > I don't have hands on experience with CMTS-es but I would think that they > are able to pool clients by MACs and able to send eg 500 clients to DHCP > server1 and the other 1500 to DHCP server2 before they would even get an > IP, so I talking of pure layer2 here! > > Not exactly, first in nearly all cases the DHCP communication is an IP > unicast rather than a layer 2 broadcast. Second, the way that the DHCP > server is selected is normally based on the type of device so that modems > get a specific GIADDR, CPE (PCs, routers behind modems, etc) get another > one, and often the EMTA gets a third. It might be possible to do that off > a count of devices, but if so it will be more of a load balancing scenario > rather than these specific 500 CMs get this DHCP server. It is possible to > do open access in a DOCSIS system, but its very difficult and involves > creating filters in both the CMTS and CM configurations. > > Let's say if the CMTS device does not support this, what are the other > options for routing layer2 traffic coming out of the CMTS? If I would know > more about the device I would say that put a linuxbox after it (on the ISP > facing nic) and mark the packets going out with arptables/ebtables then > send them out of different nics to different dhcp servers. > > It doesn't really work that way, but the closest thing is a "soft" tunnel > that gets used for things like transparent LAN services, carrier WiFi, and > a few other use cases. > > > http://www.cablelabs.com/wp-content/uploads/specdocs/CM-SP-L2VPN-I09-100611.pdf[http://www.cablelabs.com/wp-content/uploads/specdocs/CM-SP-L2VPN-I09-100611.pdf] > > Any suggestions are welcome. > From patrick at ianai.net Thu Aug 14 14:34:36 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 14 Aug 2014 10:34:36 -0400 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: <20140814024951.GA20892@panix.com> <20140814054720.GD26142@blackrose.org> <20140814062312.GF26142@blackrose.org> Message-ID: On Aug 14, 2014, at 02:36 , Randy Bush wrote: >> It was kindly pointed out to me in private that my phrasing could be >> misleading here. >> >> When ACL112 came into being, there were old equipment that were being >> protected by the /19 filters. However, the filters were in place long >> after those equipment were replaced. > > but by then it had driven all sorts of filtering and a negotiated (at > danvers) treaty with the rirs to allocate on /19. > > another note from our private aside, it is worth noting that verio's > satanic phyltres meant we did not even notice the 7007 and 128/9 > disasters. we read about them on nanog (or com-priv?). Everything has pluses & minuses. The as7007 debacle was actually made far, far worse by Sprint's policies at the time, including a "-smb" (thanx, Dorian) build. Vinny may have made a major boo-boo by pumping BGP through RIPv1 then back into BGP, but the fact Sprint filtered only on AS path _and_ had an IOS which ignored withdrawals was the real killer. Let's work on the primary protection of the INTERNET. When you were at Verio, you were driving a policy that you wanted, despite being clearly and objectively a tiny minority of the population in question. It might have made the Internet safer, but it had lots of bad side effects, including making it so that large networks have an advantage over small ones. Since those "small networks" are frequently the people paying the bills, and I am here to make money, I am not terribly happy with such policies. A quick list off the top of my head: BCP38, filtering customer announcements properly, putting pressure on networks that needlessly deaggregate, ensuring information (e.g. "your 6500 is about to crash") is properly disseminated, etc. These will have far larger impacts, disadvantage no one, and will not lose you business like your previous policies did. Everyone wins. All that said, I still abide by my primary rule: Your network, your decision. I am arguing for things we can all agree help everyone, not a select few. On Aug 14, 2014, at 02:13 , Randy Bush wrote: >>>> you mean your vendor won't give you the knobs to do it smartly ([j]tac >>>> tickets open for five years)? wonder why. >>> >>> Might be useful if you mentioned what you considered a "smart" way to >>> trim the fib. But then you couldn't bitch and moan about people not >>> understanding you, which is the real reason you post to NANOG. > > i did not get the original of this post, but the ad hominem speaks for > it pathetic self. Ad hominem implies I was going after your character without facts. However, the statement above _is_ fact - at least I believe so and given the private replies I received (and especially who replied), I am not alone. Also, you calling an ad hominem attack "pathetic" is hilarious in more ways than I can count. (Again, not ad hominem. It is trivial to objectively prove that statement hypocritical at least, which I find amusing.) -- TTFN, patrick From patrick at ianai.net Thu Aug 14 14:37:17 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 14 Aug 2014 10:37:17 -0400 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: <20140814024951.GA20892@panix.com> <20140814054720.GD26142@blackrose.org> <20140814062312.GF26142@blackrose.org> Message-ID: <9537D008-5493-4692-B271-44F730E42AAE@ianai.net> > When ACL112 came into being, there were old equipment that were being > protected by the /19 filters. However, the filters were in place long > after those equipment were replaced. This was done for commercial reasons, not to protect the Internet. You know it, I know it, and I'm pretty sure the statute of limitations has expired, so now everyone can know it. Randy may have created Verio's filters for "the good of the Internet" (even though I disagree, as I just posted), but Sean's reasons for keeping those filters were absolutely not so pristine. -- TTFN, patrick From bill at herrin.us Thu Aug 14 15:19:24 2014 From: bill at herrin.us (William Herrin) Date: Thu, 14 Aug 2014 11:19:24 -0400 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: On Wed, Aug 13, 2014 at 8:20 PM, Chris Woodfield wrote: > Hence the ?when programming the TCAM? part of my original statement :) Hi Chris, My point was that Randy's BGP RIB pruning knobs are missing for a different reason than your router FIB pruning knobs. Neither the science nor the technology exists to create Randy's BGP pruning knobs. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: Can I solve your unusual networking challenges? From jra at baylink.com Thu Aug 14 15:24:56 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 14 Aug 2014 11:24:56 -0400 (EDT) Subject: Muni Fiber and Politics In-Reply-To: <201408140804.51459.mark.tinka@seacom.mu> Message-ID: <9677192.8685.1408029896224.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Tinka" > On Monday, August 04, 2014 04:38:39 PM Jay Ashworth wrote: > > So that implies he really did mean 44x GigE to end-prem, > > from 4 $5500 10G ports -- or, $500/home in MRC *cost* to > > the provider. > > > > I'm confused. > > With an edge router chassis filled with 10Gbps ports for > various things, they quickly become a lot cheaper than > US$5,500 a pop :-). > > I realize that this may not be a universal case. Given the context of the conversation, I was hoping it was clear I meant a *wet* port, not just a jack on a card... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jared at puck.nether.net Thu Aug 14 15:41:36 2014 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 14 Aug 2014 11:41:36 -0400 Subject: ASR9K xml agent vs netconf In-Reply-To: <20140805133227.GB72334@ricotta.doit.wisc.edu> References: <20140805133227.GB72334@ricotta.doit.wisc.edu> Message-ID: <1247B91E-7A59-4F32-B450-2637B34B9E5C@puck.nether.net> Did cisco bother to open any DDTSes on the issues you saw? I?ve found that they care very little about these ?automation? issues because they have zero automation in their lab testing that reflects how someone truly uses a device. I?ve been through many iterations with Cisco on this front with their ARF teams, platform teams, BU teams, etc.. they all have to be a very strategic engagement to get these things properly fixed and made usable. I am interested in anyone trying to use any of these agents.. I suspect they all worked before the RP went x86 and like you said, nobody tests them now. (please respond off-list) - Jared > On Aug 5, 2014, at 9:32 AM, Dale W. Carder wrote: > > I wasted a week of my life trying to get xml interface on n9k to work > correctly. I would never use it again, as it obviously gets no QA. > > There is likely a fundamental design flaw in that the cli is not itself > an xml client like you see on other platforms. The XML interface, and > CLI (presumably netconf) may all be distinct clients to sysdb. I did > get (3) ddts' assigned, related to missing data compared to cli, endian > issues, etc. My recommendation is DO NOT USE IT. > > I went back to screen scraping for ios-xr. Related to this and other > issues, all of our subsequent purchases have been MX. From kai at rhynn.com Wed Aug 13 14:36:02 2014 From: kai at rhynn.com (kai) Date: Wed, 13 Aug 2014 16:36:02 +0200 Subject: =?utf-8?B?aW50ZXJnZW5pYSDihpQgbXhsb2dpYyBjb25uZWN0aW9uIGlzc3Vlcw==?= Message-ID: Hello list, most /24 subnets from 85.25.0.0/16 network (PlusServer AG/intergenia AG) seem to be blocked on mxlogic.net inbound email servers (208.65.144.2 208.65.144.3 208.65.145.2 208.65.145.3). Could someone from both parties please check it? I tried to contact MX Logic by whois contacts (dnsadmin at mxlogic.com and hostmaster at mcafee.com) but got no answer. Sorry for the noise, Kai From RCzumbil at xand.com Wed Aug 13 21:33:07 2014 From: RCzumbil at xand.com (Romeo Czumbil) Date: Wed, 13 Aug 2014 21:33:07 +0000 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: Nice little article http://www.bgpmon.net/what-caused-todays-internet-hiccup/ -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Bush Sent: Wednesday, August 13, 2014 4:43 PM To: Suresh Ramasubramanian Cc: North American Network Operators' Group Subject: Re: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today half the routing table is deagg crap. filter it. you mean your vendor won't give you the knobs to do it smartly ([j]tac tickets open for five years)? wonder why. randy From leah.ungstad at gmail.com Thu Aug 14 19:46:45 2014 From: leah.ungstad at gmail.com (Leah Ungstad) Date: Thu, 14 Aug 2014 12:46:45 -0700 Subject: Shaw routing issue 12 Aug 2014 In-Reply-To: References: Message-ID: Thanks for the info Pete, Geoffrey & Hugo! LU On Wed, Aug 13, 2014 at 6:07 PM, Pete Lumbis wrote: > Yep. Most of the time I've seen this it's two data centers, both go TCAM > exception. You reboot DC1, when it comes back up you reboot DC2. This means > no iBGP learned routes so DC1 is fine. DC 2 is fine, until the iBGP peer > comes back and then start all over again. > > > On Wed, Aug 13, 2014 at 6:06 PM, Geoffrey Keating > wrote: > >> Pete Lumbis writes: >> >> > Maybe related to the 512k route issue? >> > http://www.bgpmon.net/what-caused-todays-internet-hiccup/ >> > >> > I've seen people reboot to recover from TCAM exception without adjusting >> > TCAM size only to run into the issue all over again. It's a fun way to >> > watch the problems roll around the network. >> >> In this case, it would probably have "helped" in the same way as >> rebooting or waving a rubber chicken or whatever sometimes "helps": the >> route issue was caused initially by a problem at Verizon that >> caused them to deaggregate, which they fixed, so by the time someone had >> identified the problem, paged someone, gotten them to the data center, >> had a teleconference, rebooted the device, waited for it to come back >> up... Verizon would have fixed it, so when it came back up it'd be >> back under 512k again. >> > > From randy at psg.com Thu Aug 14 20:57:07 2014 From: randy at psg.com (Randy Bush) Date: Fri, 15 Aug 2014 05:57:07 +0900 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: > My point was that Randy's BGP RIB pruning knobs are missing for a > different reason than your router FIB pruning knobs. Neither the > science nor the technology exists to create Randy's BGP pruning knobs. ahhh, you dug out the [j]tac tickets, or are you just conjecturbating? if the former, ticket numbers would be cool. randy From bill at herrin.us Thu Aug 14 22:04:54 2014 From: bill at herrin.us (William Herrin) Date: Thu, 14 Aug 2014 18:04:54 -0400 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: On Thu, Aug 14, 2014 at 4:57 PM, Randy Bush wrote: >> My point was that Randy's BGP RIB pruning knobs are missing for a >> different reason than your router FIB pruning knobs. Neither the >> science nor the technology exists to create Randy's BGP pruning knobs. > > ahhh, you dug out the [j]tac tickets, or are you just conjecturbating? Neither. I'm reporting the state of the science having been engrossed in its research for the better part of a decade. Places like the IRTF RRG. Because no science, also no tech. If you think have some magic new algorithm that the RRG didn't consider, feel free to explain it and I'll demonstrate a scenario for you where it fails too. And I tip my hat to the router vendors for declining to implement knobs which would damage the network, despite the demands of Randy Bush. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: Can I solve your unusual networking challenges? From randy at psg.com Thu Aug 14 22:07:41 2014 From: randy at psg.com (Randy Bush) Date: Fri, 15 Aug 2014 07:07:41 +0900 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: >> ahhh, you dug out the [j]tac tickets, or are you just conjecturbating? > Neither. ROFL. so just ad hominem. smart. randy From bill at herrin.us Thu Aug 14 22:19:39 2014 From: bill at herrin.us (William Herrin) Date: Thu, 14 Aug 2014 18:19:39 -0400 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: Message-ID: On Thu, Aug 14, 2014 at 6:07 PM, Randy Bush wrote: >>> ahhh, you dug out the [j]tac tickets, or are you just conjecturbating? >> Neither. I'm reporting the state of the science. > > ROFL. so just ad hominem. smart. That phrase "ad hominem," I don't think it means what you think it means. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: Can I solve your unusual networking challenges? From vristevs at ramapo.edu Thu Aug 14 23:39:24 2014 From: vristevs at ramapo.edu (=?utf-8?B?dnJpc3RldnNAcmFtYXBvLmVkdQ==?=) Date: Thu, 14 Aug 2014 19:39:24 -0400 Subject: =?utf-8?B?UmU6IFNvIFBoaWxpcCBTbWl0aCAvIEdlb2ZmIEh1c3RvbidzIENJRFIgcmVwb3J0?= =?utf-8?B?IGJlY29tZXMgd29ydGggYSBnb29kIGhhcmQgbG9vayB0b2RheQ==?= Message-ID: <20140814233925.CE3D12A16EA@smtp-3.ramapo.edu> Sent from my Verizon Wireless 4GLTE sm ----- Reply message ----- From: "William Herrin" To: "Randy Bush" Cc: "North American Network Operators' Group" Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today Date: Thu, Aug 14, 2014 6:04 pm On Thu, Aug 14, 2014 at 4:57 PM, Randy Bush wrote: >> My point was that Randy's BGP RIB pruning knobs are missing for a >> different reason than your router FIB pruning knobs. Neither the >> science nor the technology exists to create Randy's BGP pruning knobs. > > ahhh, you dug out the [j]tac tickets, or are you just conjecturbating? Neither. I'm reporting the state of the science having been engrossed in its research for the better part of a decade. Places like the IRTF RRG. Because no science, also no tech. If you think have some magic new algorithm that the RRG didn't consider, feel free to explain it and I'll demonstrate a scenario for you where it fails too. And I tip my hat to the router vendors for declining to implement knobs which would damage the network, despite the demands of Randy Bush. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: Can I solve your unusual networking challenges? From effulgence at gmail.com Thu Aug 14 23:55:20 2014 From: effulgence at gmail.com (Aris Lambrianidis) Date: Fri, 15 Aug 2014 01:55:20 +0200 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: References: <20140814024951.GA20892@panix.com> Message-ID: <53ED4C68.2040905@gmail.com> I think you mean what is best described here: http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt --Aris > Suresh Ramasubramanian > Thursday, August 14, 2014 04:59 > Swisscom or some other European SP has / used to have a limit where they > would not accept more specific routes than say a /22 from provider x, > so if > you wanted to take a /24 and announce it you were SOL sending packets to > them from that /24 over provider y. > > Still, for elderly and capacity limited routers, that might work. > > On Thursday, August 14, 2014, Brett Frankenberger > > > Brett Frankenberger > Thursday, August 14, 2014 04:49 > > Optimization #1 -- elimination of more specifics where there's a less > specific that has the same next hop (obviously only in cases where the > less specific is the one that would be used if the more specific were > left out). > > Example: if 10.10.4.0/22 has the same next hop as 10.10.7.0/24, the > latter can be left out of TCAM (assuming there's not a 10.10.6.0/23 > with a different next hop). > > Optimization #2 -- concatenation of adjacent routes when they have the > same next hop > > Example: If 10.10.12.0/15 and 10.10.14.0/15 have the same next hop, > leave them both out of TCAM and install 10.10.14.0/14 > > Optimization #3 -- elimination of routes that have more specifics for > their entire range. > > Example: Don't program 10.10.4.0/22 in TCAM is 10.10.4.0/23, > 10.10.6.0/24 an 10.10.7.0/24 all exist > > Some additional points: > > -- This isn't that hard to implement. Once you have a FIB and > primitives for manipulating it, it's not especially difficult to extend > them to also maintain a minimal-size-FIB. > > -- The key is that aggregation need not be limited to identical routes. > Any two routes *that have the same next hop from the perspective of the > router doing the aggregating* can be aggregated in TCAM. DFZ routers > have half a million routes, but comparatively few direct adjacencies. > So lots of opportunity to aggregate. > > -- What I've described above gives forwarding behavior *identical* to > unaggregated forwarding behavior, but with fewer TCAM entries. > Obviously, you can get further reductions if you're willing to accept > different behavior (for example, igoring more specifics when there's a > less specific, even if the less specific has a different next hop). > > (This might or might not be what Randy was talking about. Maybe he's > looking for knobs to allow some routes to be excluded from TCAM at the > expense of changing forwarding behavior. But even without any such > things, there's still opportunity to meaningfully reduce usage just by > handling the cases where forwarding behavior will not change.) > > -- Brett > Patrick W. Gilmore > Thursday, August 14, 2014 01:53 > On Aug 13, 2014, at 16:42 , Randy Bush wrote: > >> half the routing table is deagg crap. filter it. > > We disagree. > > Just because you don't like all more specifics doesn't mean they are useless. > > Not everything is about minimizing FIB size. (And RIB size hasn't been relevant for years.) People pay an ass-ton of money to save a few ms off their RTT, if a more specific will allow packets to travel LHR->FRA directly instead of packets going from LHR -> SFO -> FRA, they are useful even if there is a covering prefix. > > >> you mean your vendor won't give you the knobs to do it smartly ([j]tac >> tickets open for five years)? wonder why. > > Might be useful if you mentioned what you considered a "smart" way to trim the fib. But then you couldn't bitch and moan about people not understanding you, which is the real reason you post to NANOG. > > Randy Bush > Wednesday, August 13, 2014 22:42 > half the routing table is deagg crap. filter it. > > you mean your vendor won't give you the knobs to do it smartly ([j]tac > tickets open for five years)? wonder why. > > randy > Suresh Ramasubramanian > Tuesday, August 12, 2014 18:10 > 512K routes, here we come. Lots of TCAM based routers suddenly become > really expensive doorstops. > > Maybe time to revisit this old 2007 nanog thread? > > http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=99870;page=1;sb=post_latest_reply;so=ASC;mh=25;list=nanog > > FYI nanog - > https://puck.nether.net/pipermail/outages/2014-August/007091.html > > [outages] Major outages today, not much info at this time > > Teun Vink teun at teun.tv > Tue Aug 12 11:42:05 EDT 2014 > > Hi, > > Some routing tables hit 512K routes today. Some old hardware and > software can't handle that and either crash or ignore newly learned > routes. So this may cause some disturbances in the force. > > HTH, > Teun > > ----------------- From mark.tinka at seacom.mu Fri Aug 15 06:11:16 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 15 Aug 2014 08:11:16 +0200 Subject: Muni Fiber and Politics In-Reply-To: <9677192.8685.1408029896224.JavaMail.root@benjamin.baylink.com> References: <9677192.8685.1408029896224.JavaMail.root@benjamin.baylink.com> Message-ID: <201408150811.16700.mark.tinka@seacom.mu> On Thursday, August 14, 2014 05:24:56 PM Jay Ashworth wrote: > Given the context of the conversation, I was hoping it > was clear I meant a *wet* port, not just a jack on a > card... Indeed. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From adam.vitkovsky at swan.sk Fri Aug 15 08:10:35 2014 From: adam.vitkovsky at swan.sk (=?iso-8859-2?Q?Vitkovsk=FD_Adam?=) Date: Fri, 15 Aug 2014 08:10:35 +0000 Subject: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today In-Reply-To: <20140814024951.GA20892@panix.com> References: <20140814024951.GA20892@panix.com> Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B0238AB57@EX01.swan.local> It looks great though I would not want to troubleshoot the RIB to FIB programing errors unless there's a note somewhere saying what abbreviation to search for in FIB. The other think that comes to mind is that the more specifics could have different backup next-hops programed. adam > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brett > Frankenberger > Sent: Thursday, August 14, 2014 4:50 AM > > On Wed, Aug 13, 2014 at 07:53:45PM -0400, Patrick W. Gilmore wrote: > > > you mean your vendor won't give you the knobs to do it smartly > > > ([j]tac tickets open for five years)? wonder why. > > > > Might be useful if you mentioned what you considered a "smart" way to > > trim the fib. But then you couldn't bitch and moan about people not > > understanding you, which is the real reason you post to NANOG. > > Optimization #1 -- elimination of more specifics where there's a less specific > that has the same next hop (obviously only in cases where the less specific is > the one that would be used if the more specific were left out). > > Example: if 10.10.4.0/22 has the same next hop as 10.10.7.0/24, the latter can > be left out of TCAM (assuming there's not a 10.10.6.0/23 with a different > next hop). > > Optimization #2 -- concatenation of adjacent routes when they have the > same next hop > > Example: If 10.10.12.0/15 and 10.10.14.0/15 have the same next hop, leave > them both out of TCAM and install 10.10.14.0/14 > > Optimization #3 -- elimination of routes that have more specifics for their > entire range. > > Example: Don't program 10.10.4.0/22 in TCAM is 10.10.4.0/23, > 10.10.6.0/24 an 10.10.7.0/24 all exist > > Some additional points: > > -- This isn't that hard to implement. Once you have a FIB and primitives for > manipulating it, it's not especially difficult to extend them to also maintain a > minimal-size-FIB. > > -- The key is that aggregation need not be limited to identical routes. > Any two routes *that have the same next hop from the perspective of the > router doing the aggregating* can be aggregated in TCAM. DFZ routers have > half a million routes, but comparatively few direct adjacencies. > So lots of opportunity to aggregate. > > -- What I've described above gives forwarding behavior *identical* to > unaggregated forwarding behavior, but with fewer TCAM entries. > Obviously, you can get further reductions if you're willing to accept different > behavior (for example, igoring more specifics when there's a less specific, > even if the less specific has a different next hop). > > (This might or might not be what Randy was talking about. Maybe he's > looking for knobs to allow some routes to be excluded from TCAM at the > expense of changing forwarding behavior. But even without any such things, > there's still opportunity to meaningfully reduce usage just by handling the > cases where forwarding behavior will not change.) > > -- Brett From cscora at apnic.net Fri Aug 15 18:10:52 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 16 Aug 2014 04:10:52 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201408151810.s7FIAqI4022671@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, TRNOG, 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 Aug, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 507509 Prefixes after maximum aggregation: 196575 Deaggregation factor: 2.58 Unique aggregates announced to Internet: 249334 Total ASes present in the Internet Routing Table: 47477 Prefixes per ASN: 10.69 Origin-only ASes present in the Internet Routing Table: 36058 Origin ASes announcing only one prefix: 16386 Transit ASes present in the Internet Routing Table: 6134 Transit-only ASes present in the Internet Routing Table: 175 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1779 Unregistered ASNs in the Routing Table: 470 Number of 32-bit ASNs allocated by the RIRs: 7204 Number of 32-bit ASNs visible in the Routing Table: 5285 Prefixes from 32-bit ASNs in the Routing Table: 19068 Number of bogon 32-bit ASNs visible in the Routing Table: 535 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 417 Number of addresses announced to Internet: 2711918852 Equivalent to 161 /8s, 164 /16s and 153 /24s Percentage of available address space announced: 73.3 Percentage of allocated address space announced: 73.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.8 Total number of prefixes smaller than registry allocations: 174269 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 123030 Total APNIC prefixes after maximum aggregation: 35904 APNIC Deaggregation factor: 3.43 Prefixes being announced from the APNIC address blocks: 126507 Unique aggregates announced from the APNIC address blocks: 52010 APNIC Region origin ASes present in the Internet Routing Table: 4971 APNIC Prefixes per ASN: 25.45 APNIC Region origin ASes announcing only one prefix: 1229 APNIC Region transit ASes present in the Internet Routing Table: 873 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 24 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1050 Number of APNIC addresses announced to Internet: 734277248 Equivalent to 43 /8s, 196 /16s and 46 /24s Percentage of available APNIC address space announced: 85.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 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, 150/8, 153/8, 163/8, 171/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: 170844 Total ARIN prefixes after maximum aggregation: 84598 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 172712 Unique aggregates announced from the ARIN address blocks: 80555 ARIN Region origin ASes present in the Internet Routing Table: 16362 ARIN Prefixes per ASN: 10.56 ARIN Region origin ASes announcing only one prefix: 6125 ARIN Region transit ASes present in the Internet Routing Table: 1698 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 171 Number of ARIN addresses announced to Internet: 1091945216 Equivalent to 65 /8s, 21 /16s and 195 /24s Percentage of available ARIN address space announced: 57.8 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, 62464-63487, 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, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 124601 Total RIPE prefixes after maximum aggregation: 62933 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 129392 Unique aggregates announced from the RIPE address blocks: 81997 RIPE Region origin ASes present in the Internet Routing Table: 17702 RIPE Prefixes per ASN: 7.31 RIPE Region origin ASes announcing only one prefix: 8235 RIPE Region transit ASes present in the Internet Routing Table: 2874 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2729 Number of RIPE addresses announced to Internet: 658888580 Equivalent to 39 /8s, 69 /16s and 215 /24s Percentage of available RIPE address space announced: 95.8 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 59392-61439, 61952-62463, 196608-202239 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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 58825 Total LACNIC prefixes after maximum aggregation: 10369 LACNIC Deaggregation factor: 5.67 Prefixes being announced from the LACNIC address blocks: 66665 Unique aggregates announced from the LACNIC address blocks: 29888 LACNIC Region origin ASes present in the Internet Routing Table: 2223 LACNIC Prefixes per ASN: 29.99 LACNIC Region origin ASes announcing only one prefix: 581 LACNIC Region transit ASes present in the Internet Routing Table: 450 Average LACNIC Region AS path length visible: 4.6 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1286 Number of LACNIC addresses announced to Internet: 167946496 Equivalent to 10 /8s, 2 /16s and 169 /24s Percentage of available LACNIC address space announced: 100.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 11052 Total AfriNIC prefixes after maximum aggregation: 2733 AfriNIC Deaggregation factor: 4.04 Prefixes being announced from the AfriNIC address blocks: 11816 Unique aggregates announced from the AfriNIC address blocks: 4540 AfriNIC Region origin ASes present in the Internet Routing Table: 733 AfriNIC Prefixes per ASN: 16.12 AfriNIC Region origin ASes announcing only one prefix: 216 AfriNIC Region transit ASes present in the Internet Routing Table: 162 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 49 Number of AfriNIC addresses announced to Internet: 58431744 Equivalent to 3 /8s, 123 /16s and 153 /24s Percentage of available AfriNIC address space announced: 58.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2952 11590 920 Korea Telecom 17974 2812 901 75 PT Telekomunikasi Indonesia 7545 2322 336 120 TPG Telecom Limited 4755 1872 393 200 TATA Communications formerly 9829 1654 1307 32 National Internet Backbone 9583 1315 104 537 Sify Limited 9498 1300 317 93 BHARTI Airtel Ltd. 7552 1238 1098 14 Viettel Corporation 4808 1215 2159 371 CNCGROUP IP network China169 24560 1162 403 189 Bharti Airtel Ltd., Telemedia 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 7029 3165 1958 305 Windstream Communications Inc 6389 2938 3688 51 BellSouth.net Inc. 22773 2937 2940 142 Cox Communications Inc. 18566 2047 379 178 MegaPath Corporation 20115 1758 1744 530 Charter Communications 4323 1631 1072 411 tw telecom holdings, inc. 30036 1527 319 580 Mediacom Communications Corp 701 1439 11227 724 MCI Communications Services, 6983 1434 817 313 ITC^Deltacom 22561 1307 407 235 CenturyTel Internet Holdings, 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 34984 1736 298 282 TELLCOM ILETISIM HIZMETLERI A 20940 1460 567 1075 Akamai International B.V. 8402 1289 544 15 OJSC "Vimpelcom" 13188 1049 97 53 TOV "Bank-Inform" 31148 1043 45 21 Freenet Ltd. 8551 988 371 41 Bezeq International-Ltd 6849 790 356 27 JSC "Ukrtelecom" 12479 775 798 58 France Telecom Espana SA 6830 772 2334 427 Liberty Global Operations B.V 9198 605 346 28 JSC Kazakhtelecom 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 28573 3727 2046 108 NET Servi?os de Comunica??o S 10620 2943 476 228 Telmex Colombia S.A. 18881 2068 1036 22 Global Village Telecom 7303 1770 1179 231 Telecom Argentina S.A. 8151 1448 2988 426 Uninet S.A. de C.V. 6503 1091 434 60 Axtel, S.A.B. de C.V. 6147 1049 374 29 Telefonica del Peru S.A.A. 7738 977 1882 41 Telemar Norte Leste S.A. 27947 898 130 51 Telconet S.A 26615 869 2325 35 Tim Celular 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 24863 932 280 26 Link Egypt (Link.NET) 6713 669 744 37 Office National des Postes et 8452 593 958 13 TE-AS 24835 307 144 9 Vodafone Data 36992 300 784 26 ETISALAT MISR 3741 249 920 212 Internet Solutions 29571 237 22 17 Cote d'Ivoire Telecom 37054 236 19 6 Data Telecom Service 15706 187 32 6 Sudatel (Sudan Telecom Co. Lt 12258 175 26 72 MWEB CONNECT (PROPRIETARY) LI 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 28573 3727 2046 108 NET Servi?os de Comunica??o S 7029 3165 1958 305 Windstream Communications Inc 4766 2952 11590 920 Korea Telecom 10620 2943 476 228 Telmex Colombia S.A. 6389 2938 3688 51 BellSouth.net Inc. 22773 2937 2940 142 Cox Communications Inc. 17974 2812 901 75 PT Telekomunikasi Indonesia 7545 2322 336 120 TPG Telecom Limited 18881 2068 1036 22 Global Village Telecom 18566 2047 379 178 MegaPath Corporation Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2938 2887 BellSouth.net Inc. 7029 3165 2860 Windstream Communications Inc 22773 2937 2795 Cox Communications Inc. 17974 2812 2737 PT Telekomunikasi Indonesia 10620 2943 2715 Telmex Colombia S.A. 7545 2322 2202 TPG Telecom Limited 18881 2068 2046 Global Village Telecom 4766 2952 2032 Korea Telecom 18566 2047 1869 MegaPath Corporation 4755 1872 1672 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 55020 UNALLOCATED 8.30.123.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 3356 Level 3 Communicatio 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 41.70.8.0/21 37098 globe internet limited 41.70.16.0/20 37098 globe internet limited 41.70.40.0/21 37098 globe internet limited 41.70.64.0/21 37098 globe internet limited 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 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:16 /9:13 /10:30 /11:91 /12:259 /13:498 /14:983 /15:1707 /16:13044 /17:7016 /18:11716 /19:24689 /20:35142 /21:37581 /22:54586 /23:47878 /24:270181 /25:803 /26:818 /27:404 /28:12 /29:17 /30:10 /31:1 /32:14 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2173 2937 Cox Communications Inc. 18566 2002 2047 MegaPath Corporation 7029 1704 3165 Windstream Communications Inc 6389 1691 2938 BellSouth.net Inc. 30036 1376 1527 Mediacom Communications Corp 11492 1192 1240 CABLE ONE, INC. 6983 1141 1434 ITC^Deltacom 34984 1057 1736 TELLCOM ILETISIM HIZMETLERI A 10620 1033 2943 Telmex Colombia S.A. 8402 1008 1289 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1320 2:661 3:3 4:15 5:1066 6:21 8:724 12:1859 13:4 14:1108 15:15 16:2 17:40 18:21 19:1 20:53 23:894 24:1811 27:1792 31:1470 32:41 33:2 34:5 36:141 37:1840 38:965 39:10 40:210 41:2583 42:266 43:184 44:16 45:52 46:2165 47:24 49:733 50:817 52:12 54:48 55:4 56:4 57:32 58:1247 59:631 60:425 61:1599 62:1239 63:1856 64:4416 65:2303 66:4217 67:2058 68:1040 69:3338 70:901 71:464 72:2103 74:2623 75:337 76:412 77:1620 78:801 79:722 80:1314 81:1212 82:759 83:770 84:766 85:1321 86:422 87:1142 88:463 89:1780 90:136 91:5699 92:754 93:1767 94:2018 95:1603 96:510 97:362 98:1126 99:49 100:65 101:709 103:5398 104:194 105:37 106:178 107:593 108:582 109:2011 110:1027 111:1348 112:687 113:860 114:783 115:1110 116:1118 117:933 118:1529 119:1424 120:418 121:862 122:2168 123:1604 124:1435 125:1561 128:573 129:346 130:363 131:716 132:412 133:162 134:317 135:74 136:300 137:286 138:390 139:172 140:228 141:391 142:562 143:428 144:505 145:116 146:621 147:506 148:954 149:397 150:432 151:598 152:452 153:219 154:326 155:516 156:354 157:329 158:275 159:938 160:329 161:576 162:1695 163:337 164:694 165:640 166:346 167:670 168:1113 169:124 170:1385 171:181 172:64 173:1519 174:711 175:609 176:1475 177:3417 178:2051 179:781 180:1789 181:1360 182:1621 183:540 184:692 185:1943 186:2929 187:1643 188:2192 189:1464 190:7668 191:691 192:7483 193:5504 194:4062 195:3561 196:1433 197:681 198:5130 199:5559 200:6360 201:2783 202:9181 203:9015 204:4549 205:2665 206:2975 207:2951 208:3963 209:3801 210:3286 211:1836 212:2341 213:2125 214:871 215:87 216:5709 217:1682 218:616 219:385 220:1370 221:641 222:480 223:596 End of report From tdurack at gmail.com Fri Aug 15 18:29:55 2014 From: tdurack at gmail.com (Tim Durack) Date: Fri, 15 Aug 2014 14:29:55 -0400 Subject: Public DNS64 Message-ID: Anyone know of a reliable public DNS64 service? Would be cool if Google added a Public DNS64 service, then I could point the NAT64 prefix at appropriately placed boxes in my network. Why? Other people are better than me at running DNS resolvers :-) -- Tim:> From rubensk at gmail.com Fri Aug 15 18:33:02 2014 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 15 Aug 2014 15:33:02 -0300 Subject: Public DNS64 In-Reply-To: References: Message-ID: On Fri, Aug 15, 2014 at 3:29 PM, Tim Durack wrote: > Anyone know of a reliable public DNS64 service? > > Would be cool if Google added a Public DNS64 service, then I could point > the NAT64 prefix at appropriately placed boxes in my network. > > Why? Other people are better than me at running DNS resolvers :-) > No one is better than you at running DNS resolvers with low latency from your network. Even if they can run DNS resolvers with magical capabilities, they will still suffer from transit time. Rubens From tdurack at gmail.com Fri Aug 15 18:40:35 2014 From: tdurack at gmail.com (Tim Durack) Date: Fri, 15 Aug 2014 14:40:35 -0400 Subject: Public DNS64 In-Reply-To: References: Message-ID: Yeah, sort of agree, except I'm allergic to running services that aren't straight bit shoveling. NAT64 is pushing it, but at least that is just announcing a prefix. On Fri, Aug 15, 2014 at 2:33 PM, Rubens Kuhl wrote: > > > > On Fri, Aug 15, 2014 at 3:29 PM, Tim Durack wrote: > >> Anyone know of a reliable public DNS64 service? >> >> Would be cool if Google added a Public DNS64 service, then I could point >> the NAT64 prefix at appropriately placed boxes in my network. >> >> Why? Other people are better than me at running DNS resolvers :-) >> > > No one is better than you at running DNS resolvers with low latency from > your network. Even if they can run DNS resolvers with magical capabilities, > they will still suffer from transit time. > > > Rubens > > -- Tim:> From betty at newnog.org Fri Aug 15 19:21:55 2014 From: betty at newnog.org (Betty Burke ) Date: Fri, 15 Aug 2014 15:21:55 -0400 Subject: [NANOG-announce] NANOG Reminders Message-ID: NANOGers: As we wrap up summer vacation and look toward to fall, let me share a few NANOG reminders with you. ARIN+NOTR - Madison - September 9, 2014. The agenda has been published. This is a one day free mini NANOG which does require registration. NANOG Fellowship Opportunities . This is a great opportunity for those new to NANOG, who are interested in attending NANOG 62 and could benefit from travel assistance. Education Classes - Baltimore are a great opportunity for new and mid career engineers to gain network operational experience, taught by real world operators. Make sure to pass along the information. NANOG 62 Update Agenda - The PC is hard at work reviewing all of the submissions. A Topics list will be published shortly. Travel and Socials - Be sure to make your travel plans and hotel reservations such that you will be in Baltimore for the ever popular NANOG Socials. We have evening activities Sunday, Monday, Tuesday, and Wednesday, October 5-8, 2014. ARIN 34 will follow NANOG on Thursday and Friday, October 9-10, 2014. Sponsorship Opportunities - NANOG 62 sponsorship opportunities remain, be sure your company is supporting NANOG and its efforts to make the Internet better. Lastly, the NANOG Election process is underway. Be sure to become a NANOG Member and participate in the process. Nominations are open. I hope you find these reminders helpful. However, should you have any questions, please do not hesitate to contact us via nanog-support at nanog.org. Sincerely, Betty Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From cidr-report at potaroo.net Fri Aug 15 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 Aug 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201408152200.s7FM00Lf023458@wattle.apnic.net> This report has been generated at Fri Aug 15 21:14:03 2014 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 08-08-14 511736 280442 09-08-14 511719 280722 10-08-14 511762 280563 11-08-14 511719 280860 12-08-14 511648 280869 13-08-14 512521 281173 14-08-14 513191 281215 15-08-14 513370 281443 AS Summary 47961 Number of ASes in routing system 19412 Number of ASes announcing only one prefix 3708 Largest number of prefixes announced by an AS AS28573: NET Servi?os de Comunica??o S.A.,BR 120512000 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 15Aug14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 513330 281447 231883 45.2% All ASes AS28573 3708 121 3587 96.7% NET Servi?os de Comunica??o S.A.,BR AS6389 2937 70 2867 97.6% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS22773 2933 175 2758 94.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2813 81 2732 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS18881 2077 53 2024 97.4% Global Village Telecom,BR AS7029 3396 1539 1857 54.7% WINDSTREAM - Windstream Communications Inc,US AS4766 2952 1197 1755 59.5% KIXS-AS-KR Korea Telecom,KR AS7303 1775 285 1490 83.9% Telecom Argentina S.A.,AR AS4755 1870 540 1330 71.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS8402 1258 25 1233 98.0% CORBINA-AS OJSC "Vimpelcom",RU AS4323 1641 417 1224 74.6% TWTC - tw telecom holdings, inc.,US AS7545 2339 1139 1200 51.3% TPG-INTERNET-AP TPG Telecom Limited,AU AS7552 1264 65 1199 94.9% VIETEL-AS-AP Viettel Corporation,VN AS9498 1300 110 1190 91.5% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2046 863 1183 57.8% MEGAPATH5-US - MegaPath Corporation,US AS20115 1758 609 1149 65.4% CHARTER-NET-HKY-NC - Charter Communications,US AS6983 1434 315 1119 78.0% ITCDELTA - Earthlink, Inc.,US AS9808 1092 31 1061 97.2% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS10620 2943 1898 1045 35.5% Telmex Colombia S.A.,CO AS22561 1307 264 1043 79.8% AS22561 - CenturyTel Internet Holdings, Inc.,US AS7738 977 41 936 95.8% Telemar Norte Leste S.A.,BR AS6147 1051 148 903 85.9% Telefonica del Peru S.A.A.,PE AS2516 1055 202 853 80.9% KDDI KDDI CORPORATION,JP AS38285 956 112 844 88.3% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS24560 1162 339 823 70.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS4788 1029 212 817 79.4% TMNET-AS-AP TM Net, Internet Service Provider,MY AS18101 951 190 761 80.0% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS4780 1026 266 760 74.1% SEEDNET Digital United Inc.,TW AS8151 1457 701 756 51.9% Uninet S.A. de C.V.,MX AS31148 1043 292 751 72.0% FREENET-AS Freenet Ltd.,UA Total 53550 12300 41250 77.0% Top 30 total Possible Bogus Routes 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 41.70.8.0/21 AS37098 globe-as,MW 41.70.16.0/20 AS37098 globe-as,MW 41.70.40.0/21 AS37098 globe-as,MW 41.70.64.0/21 AS37098 globe-as,MW 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.190.1.0/24 AS37076 EMTS-NIGERIA-AS,ZZ 41.190.2.0/24 AS37076 EMTS-NIGERIA-AS,ZZ 41.190.3.0/24 AS37076 EMTS-NIGERIA-AS,ZZ 41.190.4.0/22 AS37076 EMTS-NIGERIA-AS,ZZ 41.190.4.0/24 AS37076 EMTS-NIGERIA-AS,ZZ 41.190.5.0/24 AS37076 EMTS-NIGERIA-AS,ZZ 41.190.8.0/24 AS37076 EMTS-NIGERIA-AS,ZZ 41.190.10.0/23 AS37076 EMTS-NIGERIA-AS,ZZ 41.190.12.0/24 AS37076 EMTS-NIGERIA-AS,ZZ 41.190.13.0/24 AS37076 EMTS-NIGERIA-AS,ZZ 41.190.14.0/24 AS37076 EMTS-NIGERIA-AS,ZZ 41.190.16.0/20 AS37076 EMTS-NIGERIA-AS,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.197.0.0/16 AS36934 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.193.160.0/19 AS24801 -Reserved AS-,ZZ 62.193.160.0/20 AS24801 -Reserved AS-,ZZ 62.193.176.0/20 AS24801 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.68.32.0/20 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.32.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.33.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.34.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.35.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.36.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.37.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.38.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.39.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.40.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.41.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.48.0/20 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.48.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.49.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.50.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.51.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.52.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.53.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.54.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.55.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.56.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.57.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.58.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.59.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.60.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.61.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.62.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.63.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.111.160.0/20 AS40551 -Reserved AS-,ZZ 64.111.160.0/24 AS40551 -Reserved AS-,ZZ 64.111.161.0/24 AS40551 -Reserved AS-,ZZ 64.111.162.0/24 AS40551 -Reserved AS-,ZZ 64.111.167.0/24 AS40551 -Reserved AS-,ZZ 64.111.169.0/24 AS40551 -Reserved AS-,ZZ 64.111.170.0/24 AS40551 -Reserved AS-,ZZ 64.111.171.0/24 AS40551 -Reserved AS-,ZZ 64.111.172.0/24 AS40551 -Reserved AS-,ZZ 64.111.173.0/24 AS40551 -Reserved AS-,ZZ 64.111.174.0/24 AS40551 -Reserved AS-,ZZ 64.111.175.0/24 AS40551 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.6.176.0/20 AS13133 MAXHIGH-HK MAX HIGH,HK 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 -Reserved AS-,ZZ 74.120.214.0/23 AS32326 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 89.207.8.0/21 AS3292 TDC TDC A/S,DK 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.228.160.0/24 AS56815 -Reserved AS-,ZZ 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS37986 TULIP Tulip Telecom Ltd.,IN 103.6.228.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.9.88.0/22 AS58598 103.9.108.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.9.140.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.9.141.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.9.142.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.9.143.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP 103.18.92.0/22 AS13269 103.18.92.0/24 AS13269 103.18.94.0/24 AS13269 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.25.120.0/22 AS13280 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.180.0/22 AS55536 PSWITCH-HK Pacswitch Colocation & Datacentre,HK 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.249.8.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 104.153.224.0/22 AS5580 HIBERNIA TripartZ B.V.,NL 104.163.128.0/17 AS1403 ELECTRONICBOX - ELECTRONIC BOX,CA 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.108.16.0/22 AS38904 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 185.67.116.0/22 AS5381 POWTECH-AS PowerTech Information Systems AS,NO 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.126.251.0/24 AS50818 -Reserved AS-,ZZ 194.146.35.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.245.98.0/23 AS48918 GLOBALWAYS GLOBALWAYS AG,DE 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.168.56.0/24 AS54593 -Reserved AS-,ZZ 199.168.59.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.50.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.10.94.0/23 AS30097 NUWAVE - NuWave,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.155.28.0/22 AS40925 -Reserved AS-,ZZ 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.209.224.0/19 AS19513 -Reserved AS-,ZZ 209.209.248.0/23 AS19513 -Reserved AS-,ZZ 209.209.250.0/23 AS19513 -Reserved AS-,ZZ 209.209.251.0/24 AS19513 -Reserved AS-,ZZ 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 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 cidr-report at potaroo.net Fri Aug 15 22:00:02 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 Aug 2014 22:00:02 GMT Subject: BGP Update Report Message-ID: <201408152200.s7FM02DA023471@wattle.apnic.net> BGP Update Report Interval: 07-Aug-14 -to- 14-Aug-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 208709 4.2% 1630.5 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS16024 150052 3.0% 150052.0 -- GELSEN-NET GELSEN-NET Kommunikationsgesellschaft mbH,DE 3 - AS9829 143586 2.9% 127.1 -- BSNL-NIB National Internet Backbone,IN 4 - AS34744 111292 2.2% 275.5 -- GVM S.C. GVM SISTEM 2003 S.R.L.,RO 5 - AS701 98763 2.0% 5.1 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 6 - AS8402 76354 1.5% 232.1 -- CORBINA-AS OJSC "Vimpelcom",RU 7 - AS4775 51892 1.0% 720.7 -- GLOBE-TELECOM-AS Globe Telecoms,PH 8 - AS26769 50464 1.0% 630.8 -- BANDCON - Bandcon,US 9 - AS1659 48646 1.0% 193.0 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW 10 - AS28573 40628 0.8% 25.9 -- NET Servi?os de Comunica??o S.A.,BR 11 - AS23342 40258 0.8% 13419.3 -- UNITEDLAYER - Unitedlayer, Inc.,US 12 - AS55702 37863 0.8% 9465.8 -- EIT-AS-AP 501 Gloucester Street,NZ 13 - AS41691 30005 0.6% 1500.2 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 14 - AS15657 29802 0.6% 14901.0 -- SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 15 - AS3816 25419 0.5% 39.5 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 16 - AS64777 24188 0.5% 3.1 -- -Private Use AS-,ZZ 17 - AS48159 23071 0.5% 101.2 -- TIC-AS Telecommunication Infrastructure Company,IR 18 - AS25003 22028 0.4% 734.3 -- INTERNET_BINAT Internet Binat Ltd,IL 19 - AS647 21426 0.4% 164.8 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center,US 20 - AS10098 21017 0.4% 428.9 -- HENDERSON-HK Henderson Data Centre Limited,HK TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS16024 150052 3.0% 150052.0 -- GELSEN-NET GELSEN-NET Kommunikationsgesellschaft mbH,DE 2 - AS18135 16357 0.3% 16357.0 -- BTV BTV Cable television,JP 3 - AS15657 29802 0.6% 14901.0 -- SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 4 - AS23342 40258 0.8% 13419.3 -- UNITEDLAYER - Unitedlayer, Inc.,US 5 - AS55702 37863 0.8% 9465.8 -- EIT-AS-AP 501 Gloucester Street,NZ 6 - AS12559 9082 0.2% 9082.0 -- ISIDE-AS I.S.I.D.E. S.p.A.,IT 7 - AS44739 7016 0.1% 7016.0 -- IZO-AS IZO GROUP NETWORK S.R.L.,RO 8 - AS44980 5245 0.1% 5245.0 -- CAIRNEY-AS Paul Cairney,GB 9 - AS62174 5092 0.1% 5092.0 -- INTERPAN-AS INTERPAN LTD.,BG 10 - AS4 4387 0.1% 716.0 -- ISI-AS - University of Southern California,US 11 - AS32336 4312 0.1% 4312.0 -- IPASS-2 - iPass Incorporated,US 12 - AS48173 3410 0.1% 3410.0 -- UNBELIEVABLE-AS The unbelievable Machine Company GmbH,DE 13 - AS26661 12014 0.2% 3003.5 -- JCPS-ASN - Jeffco Public Schools,US 14 - AS54465 7797 0.2% 2599.0 -- QPM-AS-1 - QuickPlay Media Inc.,US 15 - AS33643 2373 0.1% 2373.0 -- JELLYBELLY - Jelly Belly Candy Company,US 16 - AS24814 20914 0.4% 2323.8 -- SCS-AS Syrian Computer Society, scs,SY 17 - AS1767 16007 0.3% 2286.7 -- ILIGHT-NET - Indiana Higher Education Telecommunication System,US 18 - AS60725 6249 0.1% 2083.0 -- O3B-AS O3b Limited,JE 19 - AS3 1826 0.0% 5517.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 20 - AS35093 3369 0.1% 1684.5 -- RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 185.47.232.0/22 150052 2.9% AS16024 -- GELSEN-NET GELSEN-NET Kommunikationsgesellschaft mbH,DE 2 - 202.70.64.0/21 103938 2.0% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 202.70.88.0/21 103159 2.0% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 64.29.130.0/24 40241 0.8% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 5 - 46.53.64.0/19 36783 0.7% AS24814 -- SCS-AS Syrian Computer Society, scs,SY AS29386 -- EXT-PDN-STE-AS Syrian Telecommunications Establishment,SY 6 - 89.221.206.0/24 29765 0.6% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 7 - 120.28.62.0/24 25895 0.5% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 8 - 222.127.0.0/24 25284 0.5% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 9 - 23.197.192.0/20 25227 0.5% AS26769 -- BANDCON - Bandcon,US 10 - 23.197.176.0/20 25061 0.5% AS26769 -- BANDCON - Bandcon,US 11 - 192.115.44.0/22 21803 0.4% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 12 - 202.123.88.0/24 20856 0.4% AS10098 -- HENDERSON-HK Henderson Data Centre Limited,HK 13 - 42.83.48.0/20 16357 0.3% AS18135 -- BTV BTV Cable television,JP 14 - 195.42.232.0/22 14965 0.3% AS15657 -- SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 15 - 193.178.196.0/22 14837 0.3% AS15657 -- SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 16 - 205.247.12.0/24 12311 0.2% AS6459 -- TRANSBEAM - I-2000, Inc.,US 17 - 112.215.16.0/24 12076 0.2% AS24203 -- NAPXLNET-AS-ID PT Excelcomindo Pratama (Network Access Provider),ID 18 - 202.50.252.0/24 9955 0.2% AS55702 -- EIT-AS-AP 501 Gloucester Street,NZ 19 - 192.58.232.0/24 9570 0.2% AS6629 -- NOAA-AS - NOAA,US 20 - 49.0.30.0/24 9303 0.2% AS55702 -- EIT-AS-AP 501 Gloucester Street,NZ 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 bking at inline.com Fri Aug 15 22:03:14 2014 From: bking at inline.com (Bryan King) Date: Fri, 15 Aug 2014 22:03:14 +0000 Subject: peeringdb contact help Message-ID: <48e1aee5f9104889b47a222dd3dec780@INL-EX-01.tcn.msft> I've been trying for 3 days now to get a response from support at peeringdb.com. Someone from peeringdb please respond off list please... From marka at isc.org Fri Aug 15 22:11:04 2014 From: marka at isc.org (Mark Andrews) Date: Sat, 16 Aug 2014 08:11:04 +1000 Subject: Public DNS64 In-Reply-To: Your message of "Fri, 15 Aug 2014 14:40:35 -0400." References: Message-ID: <20140815221104.1F24E1CDA06F@rock.dv.isc.org> For a public DNS64 service you also need a public NAT64. I suppose anyone willing to run a Tor exit node might be also willing to run such a service but it would be a traffic source anonymiser and likely would be abused. That said I could see it as a commercial service where only certain sets of IPv6 clients get to use the service with a strict mapping to IPv4 source addresses, logging etc. A ISP which had already set this up for themselves and had enough IPv4 addresses could offer this to IPv6 only ISP's as a service they could buy. Similarly a consortium of ISPs could set this up for their members possibly pooling IPv4 addresses from the members. Someone like HE might like to run such a service to further promote IPv6. This is something transit providers might get into. IPv6 to IPv4 Translation services for IPv6 only clients. The same arguements also work for DS-Lite. Mark In message , Tim Durack writes: > Yeah, sort of agree, except I'm allergic to running services that aren't > straight bit shoveling. NAT64 is pushing it, but at least that is just > announcing a prefix. > > > On Fri, Aug 15, 2014 at 2:33 PM, Rubens Kuhl wrote: > > > > > > > > > On Fri, Aug 15, 2014 at 3:29 PM, Tim Durack wrote: > > > >> Anyone know of a reliable public DNS64 service? > >> > >> Would be cool if Google added a Public DNS64 service, then I could point > >> the NAT64 prefix at appropriately placed boxes in my network. > >> > >> Why? Other people are better than me at running DNS resolvers :-) > >> > > > > No one is better than you at running DNS resolvers with low latency from > > your network. Even if they can run DNS resolvers with magical capabilities, > > they will still suffer from transit time. > > > > > > Rubens > > > > > > > > -- > Tim:> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mehmet at akcin.net Fri Aug 15 22:13:04 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 15 Aug 2014 15:13:04 -0700 Subject: peeringdb contact help In-Reply-To: <48e1aee5f9104889b47a222dd3dec780@INL-EX-01.tcn.msft> References: <48e1aee5f9104889b47a222dd3dec780@INL-EX-01.tcn.msft> Message-ID: <53ee85f4.61ae440a.34ad.7244@mx.google.com> Replying off list -----Original Message----- From: "Bryan King" Sent: ?8/?15/?2014 15:08 To: "'nanog at nanog.org'" Subject: peeringdb contact help I've been trying for 3 days now to get a response from support at peeringdb.com. Someone from peeringdb please respond off list please... From nanog at jima.us Fri Aug 15 22:31:39 2014 From: nanog at jima.us (Jima) Date: Fri, 15 Aug 2014 16:31:39 -0600 Subject: Public DNS64 In-Reply-To: <20140815221104.1F24E1CDA06F@rock.dv.isc.org> References: <20140815221104.1F24E1CDA06F@rock.dv.isc.org> Message-ID: <53EE8A4B.9000101@jima.us> On 2014-08-15 16:11, Mark Andrews wrote: > For a public DNS64 service you also need a public NAT64. Not necessarily. If the public DNS64 server is using the well-known prefix 64:ff9b::/96 (from RFC6052), then all an eyeball network needs to do is route that /96 toward their own NAT64 environment. Jima From marka at isc.org Fri Aug 15 22:46:21 2014 From: marka at isc.org (Mark Andrews) Date: Sat, 16 Aug 2014 08:46:21 +1000 Subject: Public DNS64 In-Reply-To: Your message of "Fri, 15 Aug 2014 16:31:39 -0600." <53EE8A4B.9000101@jima.us> References: <20140815221104.1F24E1CDA06F@rock.dv.isc.org> <53EE8A4B.9000101@jima.us> Message-ID: <20140815224621.2B8DC1CDDE97@rock.dv.isc.org> In message <53EE8A4B.9000101 at jima.us>, Jima writes: > On 2014-08-15 16:11, Mark Andrews wrote: > > For a public DNS64 service you also need a public NAT64. > > Not necessarily. If the public DNS64 server is using the well-known > prefix 64:ff9b::/96 (from RFC6052), then all an eyeball network needs to > do is route that /96 toward their own NAT64 environment. > > Jima I can see a transfer request being made to TEXAS-WESLEYAN-UNIVERSITY for 64.64.64.0/24. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Fri Aug 15 23:39:29 2014 From: marka at isc.org (Mark Andrews) Date: Sat, 16 Aug 2014 09:39:29 +1000 Subject: Public DNS64 In-Reply-To: Your message of "Sat, 16 Aug 2014 08:46:21 +1000." Message-ID: <20140815233929.8AE2B1CE032D@rock.dv.isc.org> Mark Andrews writes: > > In message <53EE8A4B.9000101 at jima.us>, Jima writes: > > On 2014-08-15 16:11, Mark Andrews wrote: > > > For a public DNS64 service you also need a public NAT64. > > > > Not necessarily. If the public DNS64 server is using the well-known > > prefix 64:ff9b::/96 (from RFC6052), then all an eyeball network needs to > > do is route that /96 toward their own NAT64 environment. > > > > Jima > > I can see a transfer request being made to TEXAS-WESLEYAN-UNIVERSITY > for 64.64.64.0/24. May be no. You need a memerable IPv6 addresses. This all said named supports dns64 in all currently supported versions. e.g. options { dns64 64:ff9b::/96 { }; }; Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From larrysheldon at cox.net Sat Aug 16 00:08:31 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Fri, 15 Aug 2014 19:08:31 -0500 Subject: Public DNS64 In-Reply-To: References: Message-ID: <53EEA0FF.7080608@cox.net> On 8/15/2014 6:39 PM, Mark Andrews wrote: >> >I can see a transfer request being made to TEXAS-WESLEYAN-UNIVERSITY >> >for 64.64.64.0/24. > May be no. You need a memerable IPv6 addresses. "memerable"? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn form their mistakes. From nanog at jima.us Sat Aug 16 00:11:24 2014 From: nanog at jima.us (Jima) Date: Fri, 15 Aug 2014 18:11:24 -0600 Subject: Public DNS64 In-Reply-To: <53EEA0FF.7080608@cox.net> References: <53EEA0FF.7080608@cox.net> Message-ID: <53EEA1AC.10707@jima.us> On 2014-08-15 18:08, Larry Sheldon wrote: > On 8/15/2014 6:39 PM, Mark Andrews wrote: >>> >I can see a transfer request being made to TEXAS-WESLEYAN-UNIVERSITY >>> >for 64.64.64.0/24. >> May be no. You need a memerable IPv6 addresses. > > "memerable"? Yeah, how do you expect anyone to make a meme out of 64:ff9b::/96? :-) Jima From niels=nanog at bakker.net Sat Aug 16 11:06:58 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Sat, 16 Aug 2014 13:06:58 +0200 Subject: Public DNS64 In-Reply-To: <53EEA0FF.7080608@cox.net> References: <53EEA0FF.7080608@cox.net> Message-ID: <20140816110658.GD21878@excession.tpb.net> * larrysheldon at cox.net (Larry Sheldon) [Sat 16 Aug 2014, 02:09 CEST]: >On 8/15/2014 6:39 PM, Mark Andrews wrote: >>>>I can see a transfer request being made to TEXAS-WESLEYAN-UNIVERSITY >>>>for 64.64.64.0/24. >>May be no. You need a memerable IPv6 addresses. > >"memerable"? >-- >The unique Characteristics of System Administrators: > >The fact that they are infallible; and, > >The fact that they learn form their mistakes. 'form'? Cheers, -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com From sh.vahabzadeh at gmail.com Sat Aug 16 13:13:04 2014 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Sat, 16 Aug 2014 17:43:04 +0430 Subject: Cisco ASR 1000 for Broadband Usage Message-ID: Dear Friends, We have near 32K User with ISG support, any body has Idea for the partnumber of device? I decided to but Cisco ASR 1006 with two DC Power and two RP2 and two ESP-20G. Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 1C43 988E 01A8 4D95 B662 9118 CD94 9F10 4DF4 6163 From stuarteclark at yahoo.com Sat Aug 16 15:30:13 2014 From: stuarteclark at yahoo.com (stuart clark) Date: Sat, 16 Aug 2014 16:30:13 +0100 Subject: Is LinkedIn down? Message-ID: <1408203013.7755.YahooMailNeo@web173002.mail.ir2.yahoo.com> Trace/tcptrace to 108.174.2.129 ?via Level3 - last hop is on the Linked/Level3 edge: 14 ?LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) ?76.034 ms ?76.069 ms ?76.066 ms Via?telia.net ?16 ? 236 ms ? 221 ms ? ? * ? ? linkedin-ic-301441-ash-b1.c.telia.net [213.248.103.190] ?17 ? ? * ? ? ? ?* ? ? ? ?* ? ? Request timed out. ?18 ? 259 ms ? 265 ms ? ? * ? ? 108.174.2.129 ?19 ? 257 ms ? 299 ms ? 256 ms ?108.174.2.129 No reply from LinkedIn support, but i see plenty of Verizon and Level3 customers cannot access LinkedIn for 24 hrs. 216.52.242.113 works ok. -SC (ASN25605) From frnkblk at iname.com Sat Aug 16 16:03:17 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 16 Aug 2014 11:03:17 -0500 Subject: Is LinkedIn down? In-Reply-To: <1408203013.7755.YahooMailNeo@web173002.mail.ir2.yahoo.com> References: <1408203013.7755.YahooMailNeo@web173002.mail.ir2.yahoo.com> Message-ID: <000001cfb96b$97aa8dd0$c6ffa970$@iname.com> Stuart, You don't tell us if it's www.linkedin.com or linkedin.com, but in any case, because they serve up that site around the world using some form of GLB it may resolve to different IP depending on where you are. From my perspective it is working via Cogent, and I can hit 108.174.2.129, too: root at nagios:# tcptraceroute www.linkedin.com Selected device eth0.3, address 96.31.0.5, port 43355 for outgoing packets Tracing the path to www.linkedin.com (199.101.163.129) on TCP port 80 (www), 30 hops max 1 router-core-inside.mtcnet.net (96.31.0.254) 0.253 ms 0.193 ms 0.203 ms 2 sxct.sxcy.mtcnet.net (167.142.156.197) 0.194 ms 0.131 ms 0.129 ms 3 premier.sxcy-mlx.fbnt.netins.net (173.215.60.5) 1.632 ms 1.601 ms 1.583 ms 4 38.104.184.26 7.004 ms 6.373 ms 6.437 ms 5 te0-0-1-1.rcr11.dsm01.atlas.cogentco.com (38.104.184.25) 5.913 ms 6.083 ms 5.877 ms 6 te0-2-0-0.ccr41.ord01.atlas.cogentco.com (154.54.46.237) 13.057 ms 13.114 ms 13.075 ms 7 be2156.ccr21.mci01.atlas.cogentco.com (154.54.6.85) 24.995 ms 24.942 ms 25.053 ms 8 be2012.ccr21.dfw01.atlas.cogentco.com (154.54.2.114) 35.013 ms 34.942 ms 34.928 ms 9 be2144.ccr21.iah01.atlas.cogentco.com (154.54.25.105) 40.455 ms 40.749 ms 40.709 ms 10 be2065.ccr21.lax01.atlas.cogentco.com (154.54.5.66) 76.269 ms 76.119 ms 75.970 ms 11 * * * 12 154.24.22.126 76.351 ms 76.296 ms 76.257 ms 13 38.88.244.2 73.135 ms 73.101 ms 73.182 ms 14 border1.po1-20g-bbnet1.lax008.pnap.net (216.52.255.46) 73.354 ms 73.355 ms 73.585 ms 15 linkedin-16.border1.lax008.pnap.net (216.52.220.122) 74.017 ms 74.005 ms 73.965 ms 16 * * * 17 199.101.162.226 74.766 ms 74.391 ms 74.582 ms 18 199.101.163.129 [open] 74.528 ms 74.381 ms 74.421 ms root at nagios:# root at nagios:/# tcptraceroute 108.174.2.129 Selected device eth0.3, address 96.31.0.5, port 49338 for outgoing packets Tracing the path to 108.174.2.129 on TCP port 80 (www), 30 hops max 1 router-core-inside.mtcnet.net (96.31.0.254) 0.295 ms 0.210 ms 0.237 ms 2 sxct.spnc.mtcnet.net (167.142.156.194) 0.206 ms 0.144 ms 0.129 ms 3 premier.spnc-mlx.fbnt.netins.net (173.215.60.1) 15.282 ms 4.743 ms 4.750 ms 4 ins-kb3-et-0-7-0-0.kmrr.netins.net.67.142.167.in-addr.arpa (167.142.67.50) 8.787 ms 8.705 ms 8.505 ms 5 ins-kc2-et-9-3.kmrr.netins.net (167.142.67.49) 7.170 ms 7.183 ms 7.189 ms 6 ins-dc1-po20.desm.netins.net (167.142.67.29) 7.623 ms 8.936 ms 8.135 ms 7 207.87.180.149 12.733 ms 52.226 ms 12.740 ms 8 ae1d0.mcr1.minneapolis-mn.us.xo.net (216.156.1.85) 23.368 ms 22.132 ms 22.052 ms 9 vb1710.rar3.chicago-il.us.xo.net (216.156.0.169) 22.984 ms 23.536 ms 24.016 ms 10 207.88.14.194.ptr.us.xo.net (207.88.14.194) 21.861 ms 21.882 ms 21.880 ms 11 206.111.2.65.ptr.us.xo.net (206.111.2.65) 23.583 ms 22.722 ms 22.876 ms 12 ae-8.r05.chcgil09.us.bb.gin.ntt.net (129.250.4.221) 22.630 ms 22.751 ms 22.817 ms 13 165.254.191.82 22.760 ms 22.726 ms 22.722 ms 14 * * * 15 * * * 16 108.174.2.129 [open] 36.065 ms 36.058 ms 36.042 ms root at nagios:/# root at nagios:/usr/lib/nagios/plugins# ./check_http -H www.linkedin.com -I 199.101.163.129 HTTP OK: HTTP/1.1 301 Moved Permanently - 1706 bytes in 0.167 second response time |time=0.166917s;;;0.000000 size=1706B;;;0 root at nagios:/usr/lib/nagios/plugins# root at nagios:/usr/lib/nagios/plugins# ./check_http -H www.linkedin.com -I 108.174.2.129 HTTP OK: HTTP/1.1 301 Moved Permanently - 1702 bytes in 0.088 second response time |time=0.088261s;;;0.000000 size=1702B;;;0 root at nagios:/usr/lib/nagios/plugins# Regards, Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of stuart clark Sent: Saturday, August 16, 2014 10:30 AM To: nanog at nanog.org Subject: Is LinkedIn down? Trace/tcptrace to 108.174.2.129 ?via Level3 - last hop is on the Linked/Level3 edge: 14 ?LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) ?76.034 ms ?76.069 ms ?76.066 ms Via?telia.net ?16 ? 236 ms ? 221 ms ? ? * ? ? linkedin-ic-301441-ash-b1.c.telia.net [213.248.103.190] ?17 ? ? * ? ? ? ?* ? ? ? ?* ? ? Request timed out. ?18 ? 259 ms ? 265 ms ? ? * ? ? 108.174.2.129 ?19 ? 257 ms ? 299 ms ? 256 ms ?108.174.2.129 No reply from LinkedIn support, but i see plenty of Verizon and Level3 customers cannot access LinkedIn for 24 hrs. 216.52.242.113 works ok. -SC (ASN25605) From stuarteclark at yahoo.com Sat Aug 16 16:45:01 2014 From: stuarteclark at yahoo.com (stuart clark) Date: Sat, 16 Aug 2014 17:45:01 +0100 Subject: Is LinkedIn down? In-Reply-To: <000001cfb96b$97aa8dd0$c6ffa970$@iname.com> References: <1408203013.7755.YahooMailNeo@web173002.mail.ir2.yahoo.com> <000001cfb96b$97aa8dd0$c6ffa970$@iname.com> Message-ID: <1408207501.27813.YahooMailNeo@web173005.mail.ir2.yahoo.com> Thanks Frank - www.linkedin.com is the one i see problems with testing from two locations UK and Frankfurt. London TR is below. If i jump out of our AMS location (ASN109 - via AS1299?) i dont see any problems. [root at ops-netops-util1 ~]# tcptraceroute linkedin.com Selected device eth0, address 10.3.4.38, port 42311 for outgoing packets Tracing the path to linkedin.com (216.52.242.86) on TCP port 80 (http), 30 hops max [removed] ?6 ?xe-5-0-0.edge5.London1.Level3.net (212.187.138.209) ?1.078 ms ?1.040 ms ?1.159 ms ?7 ?* * * ?8 ?ae-56-221.ebr2.London1.Level3.net (4.69.153.129) ?76.147 ms ?75.863 ms ?75.901 ms ?9 ?* * * 10 ?* * * 11 ?ae-48-48.ebr2.Washington1.Level3.net (4.69.202.61) ?75.557 ms ?75.550 ms ?75.511 ms 12 ?ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) ?75.700 ms ?75.502 ms ?75.644 ms 13 ?ae-3-80.edge3.Washington4.Level3.net (4.69.149.146) ?75.639 ms ?75.726 ms ?75.692 ms 14 ?LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) ?75.888 ms ?75.924 ms ?75.912 ms 15 ?* * * 16 ?* * * 17 ?* * * 18 ?* * * 19 ?199.101.162.230 ?149.661 ms ?151.158 ms ?149.616 ms 20 ?careers.linkedin.com (216.52.242.86) [open] ?149.264 ms ?149.369 ms ?149.448 ms [root at ops-netops-util1 ~]# tcptraceroute www.linkedin.com Selected device eth0, address 10.3.4.38, port 57760 for outgoing packets Tracing the path to www.linkedin.com (108.174.2.129) on TCP port 80 (http), 30 hops max [removed] ?5 ?xe-5-0-0.edge5.London1.Level3.net (212.187.138.209) ?1.060 ms ?1.082 ms ?1.041 ms ?6 ?* * * ?7 ?ae-58-223.ebr2.London1.Level3.net (4.69.153.137) ?75.830 ms ?75.929 ms ?75.739 ms ?8 ?* * * ?9 ?* * * 10 ?ae-47-47.ebr2.Washington1.Level3.net (4.69.202.57) ?75.950 ms ?76.001 ms ?75.942 ms 11 ?* ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) 75.713 ms ?75.589 ms 12 ?ae-3-80.edge3.Washington4.Level3.net (4.69.149.146) ?75.702 ms ?75.769 ms ?75.748 ms 13 ?LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) ?75.973 ms ?75.924 ms ?76.664 ms 14 ?* * * 15 ?* * * [timesouts] Cheers! -SC (ASN25605) On Saturday, 16 August 2014, 17:03, Frank Bulk wrote: Stuart, You don't tell us if it's www.linkedin.com or linkedin.com, but in any case, because they serve up that site around the world using some form of GLB it may resolve to different IP depending on where you are.? From my perspective it is working via Cogent, and I can hit 108.174.2.129, too: root at nagios:# tcptraceroute www.linkedin.com Selected device eth0.3, address 96.31.0.5, port 43355 for outgoing packets Tracing the path to www.linkedin.com (199.101.163.129) on TCP port 80 (www), 30 hops max 1? router-core-inside.mtcnet.net (96.31.0.254)? 0.253 ms? 0.193 ms? 0.203 ms 2? sxct.sxcy.mtcnet.net (167.142.156.197)? 0.194 ms? 0.131 ms? 0.129 ms 3? premier.sxcy-mlx.fbnt.netins.net (173.215.60.5)? 1.632 ms? 1.601 ms 1.583 ms 4? 38.104.184.26? 7.004 ms? 6.373 ms? 6.437 ms 5? te0-0-1-1.rcr11.dsm01.atlas.cogentco.com (38.104.184.25)? 5.913 ms 6.083 ms? 5.877 ms 6? te0-2-0-0.ccr41.ord01.atlas.cogentco.com (154.54.46.237)? 13.057 ms 13.114 ms? 13.075 ms 7? be2156.ccr21.mci01.atlas.cogentco.com (154.54.6.85)? 24.995 ms? 24.942 ms? 25.053 ms 8? be2012.ccr21.dfw01.atlas.cogentco.com (154.54.2.114)? 35.013 ms? 34.942 ms? 34.928 ms 9? be2144.ccr21.iah01.atlas.cogentco.com (154.54.25.105)? 40.455 ms? 40.749 ms? 40.709 ms 10? be2065.ccr21.lax01.atlas.cogentco.com (154.54.5.66)? 76.269 ms? 76.119 ms? 75.970 ms 11? * * * 12? 154.24.22.126? 76.351 ms? 76.296 ms? 76.257 ms 13? 38.88.244.2? 73.135 ms? 73.101 ms? 73.182 ms 14? border1.po1-20g-bbnet1.lax008.pnap.net (216.52.255.46)? 73.354 ms 73.355 ms? 73.585 ms 15? linkedin-16.border1.lax008.pnap.net (216.52.220.122)? 74.017 ms? 74.005 ms? 73.965 ms 16? * * * 17? 199.101.162.226? 74.766 ms? 74.391 ms? 74.582 ms 18? 199.101.163.129 [open]? 74.528 ms? 74.381 ms? 74.421 ms root at nagios:# root at nagios:/# tcptraceroute 108.174.2.129 Selected device eth0.3, address 96.31.0.5, port 49338 for outgoing packets Tracing the path to 108.174.2.129 on TCP port 80 (www), 30 hops max 1? router-core-inside.mtcnet.net (96.31.0.254)? 0.295 ms? 0.210 ms? 0.237 ms 2? sxct.spnc.mtcnet.net (167.142.156.194)? 0.206 ms? 0.144 ms? 0.129 ms 3? premier.spnc-mlx.fbnt.netins.net (173.215.60.1)? 15.282 ms? 4.743 ms 4.750 ms 4? ins-kb3-et-0-7-0-0.kmrr.netins.net.67.142.167.in-addr.arpa (167.142.67.50)? 8.787 ms? 8.705 ms? 8.505 ms 5? ins-kc2-et-9-3.kmrr.netins.net (167.142.67.49)? 7.170 ms? 7.183 ms 7.189 ms 6? ins-dc1-po20.desm.netins.net (167.142.67.29)? 7.623 ms? 8.936 ms? 8.135 ms 7? 207.87.180.149? 12.733 ms? 52.226 ms? 12.740 ms 8? ae1d0.mcr1.minneapolis-mn.us.xo.net (216.156.1.85)? 23.368 ms? 22.132 ms 22.052 ms 9? vb1710.rar3.chicago-il.us.xo.net (216.156.0.169)? 22.984 ms? 23.536 ms 24.016 ms 10? 207.88.14.194.ptr.us.xo.net (207.88.14.194)? 21.861 ms? 21.882 ms 21.880 ms 11? 206.111.2.65.ptr.us.xo.net (206.111.2.65)? 23.583 ms? 22.722 ms? 22.876 ms 12? ae-8.r05.chcgil09.us.bb.gin.ntt.net (129.250.4.221)? 22.630 ms? 22.751 ms? 22.817 ms 13? 165.254.191.82? 22.760 ms? 22.726 ms? 22.722 ms 14? * * * 15? * * * 16? 108.174.2.129 [open]? 36.065 ms? 36.058 ms? 36.042 ms root at nagios:/# root at nagios:/usr/lib/nagios/plugins# ./check_http -H www.linkedin.com -I 199.101.163.129 HTTP OK: HTTP/1.1 301 Moved Permanently - 1706 bytes in 0.167 second response time |time=0.166917s;;;0.000000 size=1706B;;;0 root at nagios:/usr/lib/nagios/plugins# root at nagios:/usr/lib/nagios/plugins# ./check_http -H www.linkedin.com -I 108.174.2.129 HTTP OK: HTTP/1.1 301 Moved Permanently - 1702 bytes in 0.088 second response time |time=0.088261s;;;0.000000 size=1702B;;;0 root at nagios:/usr/lib/nagios/plugins# Regards, Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of stuart clark Sent: Saturday, August 16, 2014 10:30 AM To: nanog at nanog.org Subject: Is LinkedIn down? Trace/tcptrace to 108.174.2.129 ?via Level3 - last hop is on the Linked/Level3 edge: 14 ?LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) ?76.034 ms ?76.069 ms ?76.066 ms Via?telia.net ?16 ? 236 ms ? 221 ms ? ? * ? ? linkedin-ic-301441-ash-b1.c.telia.net [213.248.103.190] ?17 ? ? * ? ? ? ?* ? ? ? ?* ? ? Request timed out. ?18 ? 259 ms ? 265 ms ? ? * ? ? 108.174.2.129 ?19 ? 257 ms ? 299 ms ? 256 ms ?108.174.2.129 No reply from LinkedIn support, but i see plenty of Verizon and Level3 customers cannot access LinkedIn for 24 hrs. 216.52.242.113 works ok. -SC (ASN25605) From zaid at zaidali.com Sat Aug 16 17:02:28 2014 From: zaid at zaidali.com (Zaid A. Kahn) Date: Sat, 16 Aug 2014 10:02:28 -0700 Subject: Is LinkedIn down? In-Reply-To: <1408207501.27813.YahooMailNeo@web173005.mail.ir2.yahoo.com> References: <1408203013.7755.YahooMailNeo@web173002.mail.ir2.yahoo.com> <000001cfb96b$97aa8dd0$c6ffa970$@iname.com> <1408207501.27813.YahooMailNeo@web173005.mail.ir2.yahoo.com> Message-ID: <7C81515F-E657-40E3-A9CE-563CE0375A49@zaidali.com> Stuart, I believe someone from our support desk has reached out to you. If you still need help reply to me off list. Zaid Sent from my iPhone > On Aug 16, 2014, at 9:45 AM, stuart clark wrote: > > Thanks Frank - www.linkedin.com is the one i see problems with testing from two locations UK and Frankfurt. London TR is below. > If i jump out of our AMS location (ASN109 - via AS1299 ) i dont see any problems. > > [root at ops-netops-util1 ~]# tcptraceroute linkedin.com > Selected device eth0, address 10.3.4.38, port 42311 for outgoing packets > Tracing the path to linkedin.com (216.52.242.86) on TCP port 80 (http), 30 hops max > > [removed] > > 6 xe-5-0-0.edge5.London1.Level3.net (212.187.138.209) 1.078 ms 1.040 ms 1.159 ms > 7 * * * > 8 ae-56-221.ebr2.London1.Level3.net (4.69.153.129) 76.147 ms 75.863 ms 75.901 ms > 9 * * * > 10 * * * > 11 ae-48-48.ebr2.Washington1.Level3.net (4.69.202.61) 75.557 ms 75.550 ms 75.511 ms > 12 ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) 75.700 ms 75.502 ms 75.644 ms > 13 ae-3-80.edge3.Washington4.Level3.net (4.69.149.146) 75.639 ms 75.726 ms 75.692 ms > 14 LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) 75.888 ms 75.924 ms 75.912 ms > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 199.101.162.230 149.661 ms 151.158 ms 149.616 ms > 20 careers.linkedin.com (216.52.242.86) [open] 149.264 ms 149.369 ms 149.448 ms > > > [root at ops-netops-util1 ~]# tcptraceroute www.linkedin.com > Selected device eth0, address 10.3.4.38, port 57760 for outgoing packets > Tracing the path to www.linkedin.com (108.174.2.129) on TCP port 80 (http), 30 hops max > > [removed] > > 5 xe-5-0-0.edge5.London1.Level3.net (212.187.138.209) 1.060 ms 1.082 ms 1.041 ms > 6 * * * > 7 ae-58-223.ebr2.London1.Level3.net (4.69.153.137) 75.830 ms 75.929 ms 75.739 ms > 8 * * * > 9 * * * > 10 ae-47-47.ebr2.Washington1.Level3.net (4.69.202.57) 75.950 ms 76.001 ms 75.942 ms > 11 * ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) 75.713 ms 75.589 ms > 12 ae-3-80.edge3.Washington4.Level3.net (4.69.149.146) 75.702 ms 75.769 ms 75.748 ms > 13 LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) 75.973 ms 75.924 ms 76.664 ms > 14 * * * > 15 * * * > [timesouts] > > Cheers! > > -SC (ASN25605) > > > > On Saturday, 16 August 2014, 17:03, Frank Bulk wrote: > > > > Stuart, > > You don't tell us if it's www.linkedin.com or linkedin.com, but in any case, > because they serve up that site around the world using some form of GLB it > may resolve to different IP depending on where you are. From my perspective > it is working via Cogent, and I can hit 108.174.2.129, too: > > root at nagios:# tcptraceroute www.linkedin.com > Selected device eth0.3, address 96.31.0.5, port 43355 for outgoing packets > Tracing the path to www.linkedin.com (199.101.163.129) on TCP port 80 (www), > 30 hops max > 1 router-core-inside.mtcnet.net (96.31.0.254) 0.253 ms 0.193 ms 0.203 > ms > 2 sxct.sxcy.mtcnet.net (167.142.156.197) 0.194 ms 0.131 ms 0.129 ms > 3 premier.sxcy-mlx.fbnt.netins.net (173.215.60.5) 1.632 ms 1.601 ms > 1.583 ms > 4 38.104.184.26 7.004 ms 6.373 ms 6.437 ms > 5 te0-0-1-1.rcr11.dsm01.atlas.cogentco.com (38.104.184.25) 5.913 ms > 6.083 ms 5.877 ms > 6 te0-2-0-0.ccr41.ord01.atlas.cogentco.com (154.54.46.237) 13.057 ms > 13.114 ms 13.075 ms > 7 be2156.ccr21.mci01.atlas.cogentco.com (154.54.6.85) 24.995 ms 24.942 > ms 25.053 ms > 8 be2012.ccr21.dfw01.atlas.cogentco.com (154.54.2.114) 35.013 ms 34.942 > ms 34.928 ms > 9 be2144.ccr21.iah01.atlas.cogentco.com (154.54.25.105) 40.455 ms 40.749 > ms 40.709 ms > 10 be2065.ccr21.lax01.atlas.cogentco.com (154.54.5.66) 76.269 ms 76.119 > ms 75.970 ms > 11 * * * > 12 154.24.22.126 76.351 ms 76.296 ms 76.257 ms > 13 38.88.244.2 73.135 ms 73.101 ms 73.182 ms > 14 border1.po1-20g-bbnet1.lax008.pnap.net (216.52.255.46) 73.354 ms > 73.355 ms 73.585 ms > 15 linkedin-16.border1.lax008.pnap.net (216.52.220.122) 74.017 ms 74.005 > ms 73.965 ms > 16 * * * > 17 199.101.162.226 74.766 ms 74.391 ms 74.582 ms > 18 199.101.163.129 [open] 74.528 ms 74.381 ms 74.421 ms > root at nagios:# > > > root at nagios:/# tcptraceroute 108.174.2.129 > Selected device eth0.3, address 96.31.0.5, port 49338 for outgoing packets > Tracing the path to 108.174.2.129 on TCP port 80 (www), 30 hops max > 1 router-core-inside.mtcnet.net (96.31.0.254) 0.295 ms 0.210 ms 0.237 > ms > 2 sxct.spnc.mtcnet.net (167.142.156.194) 0.206 ms 0.144 ms 0.129 ms > 3 premier.spnc-mlx.fbnt.netins.net (173.215.60.1) 15.282 ms 4.743 ms > 4.750 ms > 4 ins-kb3-et-0-7-0-0.kmrr.netins.net.67.142.167.in-addr.arpa > (167.142.67.50) 8.787 ms 8.705 ms 8.505 ms > 5 ins-kc2-et-9-3.kmrr.netins.net (167.142.67.49) 7.170 ms 7.183 ms > 7.189 ms > 6 ins-dc1-po20.desm.netins.net (167.142.67.29) 7.623 ms 8.936 ms 8.135 > ms > 7 207.87.180.149 12.733 ms 52.226 ms 12.740 ms > 8 ae1d0.mcr1.minneapolis-mn.us.xo.net (216.156.1.85) 23.368 ms 22.132 ms > 22.052 ms > 9 vb1710.rar3.chicago-il.us.xo.net (216.156.0.169) 22.984 ms 23.536 ms > 24.016 ms > 10 207.88.14.194.ptr.us.xo.net (207.88.14.194) 21.861 ms 21.882 ms > 21.880 ms > 11 206.111.2.65.ptr.us.xo.net (206.111.2.65) 23.583 ms 22.722 ms 22.876 > ms > 12 ae-8.r05.chcgil09.us.bb.gin.ntt.net (129.250.4.221) 22.630 ms 22.751 > ms 22.817 ms > 13 165.254.191.82 22.760 ms 22.726 ms 22.722 ms > 14 * * * > 15 * * * > 16 108.174.2.129 [open] 36.065 ms 36.058 ms 36.042 ms > root at nagios:/# > > > root at nagios:/usr/lib/nagios/plugins# ./check_http -H www.linkedin.com -I > 199.101.163.129 > HTTP OK: HTTP/1.1 301 Moved Permanently - 1706 bytes in 0.167 second > response time |time=0.166917s;;;0.000000 size=1706B;;;0 > root at nagios:/usr/lib/nagios/plugins# > root at nagios:/usr/lib/nagios/plugins# ./check_http -H www.linkedin.com -I > 108.174.2.129 > HTTP OK: HTTP/1.1 301 Moved Permanently - 1702 bytes in 0.088 second > response time |time=0.088261s;;;0.000000 size=1702B;;;0 > root at nagios:/usr/lib/nagios/plugins# > > Regards, > > Frank > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of stuart clark > Sent: Saturday, August 16, 2014 10:30 AM > To: nanog at nanog.org > Subject: Is LinkedIn down? > > Trace/tcptrace to 108.174.2.129 via Level3 - last hop is on the > Linked/Level3 edge: > > 14 LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) 76.034 ms > 76.069 ms 76.066 ms > > > Via telia.net > > 16 236 ms 221 ms * linkedin-ic-301441-ash-b1.c.telia.net > [213.248.103.190] > 17 * * * Request timed out. > 18 259 ms 265 ms * 108.174.2.129 > 19 257 ms 299 ms 256 ms 108.174.2.129 > > No reply from LinkedIn support, but i see plenty of Verizon and Level3 > customers cannot access LinkedIn for 24 hrs. > 216.52.242.113 works ok. > > > -SC (ASN25605) From frnkblk at iname.com Sat Aug 16 17:26:47 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 16 Aug 2014 12:26:47 -0500 Subject: Is LinkedIn down? In-Reply-To: <1408207501.27813.YahooMailNeo@web173005.mail.ir2.yahoo.com> References: <1408203013.7755.YahooMailNeo@web173002.mail.ir2.yahoo.com> <000001cfb96b$97aa8dd0$c6ffa970$@iname.com> <1408207501.27813.YahooMailNeo@web173005.mail.ir2.yahoo.com> Message-ID: <000201cfb977$41f07c40$c5d174c0$@iname.com> Stuart, You haven't shared your IPs but you could go to Level3's Washington Looking Glass and see if you can trace back to your UK and Frankfurt IPs. Frank From: stuart clark [mailto:stuarteclark at yahoo.com] Sent: Saturday, August 16, 2014 11:45 AM To: Frank Bulk; nanog at nanog.org Subject: Re: Is LinkedIn down? Thanks Frank - www.linkedin.com is the one i see problems with testing from two locations UK and Frankfurt. London TR is below. If i jump out of our AMS location (ASN109 - via AS1299 ) i dont see any problems. [root at ops-netops-util1 ~]# tcptraceroute linkedin.com Selected device eth0, address 10.3.4.38, port 42311 for outgoing packets Tracing the path to linkedin.com (216.52.242.86) on TCP port 80 (http), 30 hops max [removed] 6 xe-5-0-0.edge5.London1.Level3.net (212.187.138.209) 1.078 ms 1.040 ms 1.159 ms 7 * * * 8 ae-56-221.ebr2.London1.Level3.net (4.69.153.129) 76.147 ms 75.863 ms 75.901 ms 9 * * * 10 * * * 11 ae-48-48.ebr2.Washington1.Level3.net (4.69.202.61) 75.557 ms 75.550 ms 75.511 ms 12 ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) 75.700 ms 75.502 ms 75.644 ms 13 ae-3-80.edge3.Washington4.Level3.net (4.69.149.146) 75.639 ms 75.726 ms 75.692 ms 14 LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) 75.888 ms 75.924 ms 75.912 ms 15 * * * 16 * * * 17 * * * 18 * * * 19 199.101.162.230 149.661 ms 151.158 ms 149.616 ms 20 careers.linkedin.com (216.52.242.86) [open] 149.264 ms 149.369 ms 149.448 ms [root at ops-netops-util1 ~]# tcptraceroute www.linkedin.com Selected device eth0, address 10.3.4.38, port 57760 for outgoing packets Tracing the path to www.linkedin.com (108.174.2.129) on TCP port 80 (http), 30 hops max [removed] 5 xe-5-0-0.edge5.London1.Level3.net (212.187.138.209) 1.060 ms 1.082 ms 1.041 ms 6 * * * 7 ae-58-223.ebr2.London1.Level3.net (4.69.153.137) 75.830 ms 75.929 ms 75.739 ms 8 * * * 9 * * * 10 ae-47-47.ebr2.Washington1.Level3.net (4.69.202.57) 75.950 ms 76.001 ms 75.942 ms 11 * ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) 75.713 ms 75.589 ms 12 ae-3-80.edge3.Washington4.Level3.net (4.69.149.146) 75.702 ms 75.769 ms 75.748 ms 13 LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) 75.973 ms 75.924 ms 76.664 ms 14 * * * 15 * * * [timesouts] Cheers! -SC (ASN25605) On Saturday, 16 August 2014, 17:03, Frank Bulk > wrote: Stuart, You don't tell us if it's www.linkedin.com or linkedin.com, but in any case, because they serve up that site around the world using some form of GLB it may resolve to different IP depending on where you are. From my perspective it is working via Cogent, and I can hit 108.174.2.129, too: root at nagios :# tcptraceroute www.linkedin.com Selected device eth0.3, address 96.31.0.5, port 43355 for outgoing packets Tracing the path to www.linkedin.com (199.101.163.129) on TCP port 80 (www), 30 hops max 1 router-core-inside.mtcnet.net (96.31.0.254) 0.253 ms 0.193 ms 0.203 ms 2 sxct.sxcy.mtcnet.net (167.142.156.197) 0.194 ms 0.131 ms 0.129 ms 3 premier.sxcy-mlx.fbnt.netins.net (173.215.60.5) 1.632 ms 1.601 ms 1.583 ms 4 38.104.184.26 7.004 ms 6.373 ms 6.437 ms 5 te0-0-1-1.rcr11.dsm01.atlas.cogentco.com (38.104.184.25) 5.913 ms 6.083 ms 5.877 ms 6 te0-2-0-0.ccr41.ord01.atlas.cogentco.com (154.54.46.237) 13.057 ms 13.114 ms 13.075 ms 7 be2156.ccr21.mci01.atlas.cogentco.com (154.54.6.85) 24.995 ms 24.942 ms 25.053 ms 8 be2012.ccr21.dfw01.atlas.cogentco.com (154.54.2.114) 35.013 ms 34.942 ms 34.928 ms 9 be2144.ccr21.iah01.atlas.cogentco.com (154.54.25.105) 40.455 ms 40.749 ms 40.709 ms 10 be2065.ccr21.lax01.atlas.cogentco.com (154.54.5.66) 76.269 ms 76.119 ms 75.970 ms 11 * * * 12 154.24.22.126 76.351 ms 76.296 ms 76.257 ms 13 38.88.244.2 73.135 ms 73.101 ms 73.182 ms 14 border1.po1-20g-bbnet1.lax008.pnap.net (216.52.255.46) 73.354 ms 73.355 ms 73.585 ms 15 linkedin-16.border1.lax008.pnap.net (216.52.220.122) 74.017 ms 74.005 ms 73.965 ms 16 * * * 17 199.101.162.226 74.766 ms 74.391 ms 74.582 ms 18 199.101.163.129 [open] 74.528 ms 74.381 ms 74.421 ms root at nagios :# root at nagios :/# tcptraceroute 108.174.2.129 Selected device eth0.3, address 96.31.0.5, port 49338 for outgoing packets Tracing the path to 108.174.2.129 on TCP port 80 (www), 30 hops max 1 router-core-inside.mtcnet.net (96.31.0.254) 0.295 ms 0.210 ms 0.237 ms 2 sxct.spnc.mtcnet.net (167.142.156.194) 0.206 ms 0.144 ms 0.129 ms 3 premier.spnc-mlx.fbnt.netins.net (173.215.60.1) 15.282 ms 4.743 ms 4.750 ms 4 ins-kb3-et-0-7-0-0.kmrr.netins.net.67.142.167.in-addr.arpa (167.142.67.50) 8.787 ms 8.705 ms 8.505 ms 5 ins-kc2-et-9-3.kmrr.netins.net (167.142.67.49) 7.170 ms 7.183 ms 7.189 ms 6 ins-dc1-po20.desm.netins.net (167.142.67.29) 7.623 ms 8.936 ms 8.135 ms 7 207.87.180.149 12.733 ms 52.226 ms 12.740 ms 8 ae1d0.mcr1.minneapolis-mn.us.xo.net (216.156.1.85) 23.368 ms 22.132 ms 22.052 ms 9 vb1710.rar3.chicago-il.us.xo.net (216.156.0.169) 22.984 ms 23.536 ms 24.016 ms 10 207.88.14.194.ptr.us.xo.net (207.88.14.194) 21.861 ms 21.882 ms 21.880 ms 11 206.111.2.65.ptr.us.xo.net (206.111.2.65) 23.583 ms 22.722 ms 22.876 ms 12 ae-8.r05.chcgil09.us.bb.gin.ntt.net (129.250.4.221) 22.630 ms 22.751 ms 22.817 ms 13 165.254.191.82 22.760 ms 22.726 ms 22.722 ms 14 * * * 15 * * * 16 108.174.2.129 [open] 36.065 ms 36.058 ms 36.042 ms root at nagios :/# root at nagios :/usr/lib/nagios/plugins# ./check_http -H www.linkedin.com -I 199.101.163.129 HTTP OK: HTTP/1.1 301 Moved Permanently - 1706 bytes in 0.167 second response time |time=0.166917s;;;0.000000 size=1706B;;;0 root at nagios :/usr/lib/nagios/plugins# root at nagios :/usr/lib/nagios/plugins# ./check_http -H www.linkedin.com -I 108.174.2.129 HTTP OK: HTTP/1.1 301 Moved Permanently - 1702 bytes in 0.088 second response time |time=0.088261s;;;0.000000 size=1702B;;;0 root at nagios :/usr/lib/nagios/plugins# Regards, Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org ] On Behalf Of stuart clark Sent: Saturday, August 16, 2014 10:30 AM To: nanog at nanog.org Subject: Is LinkedIn down? Trace/tcptrace to 108.174.2.129 via Level3 - last hop is on the Linked/Level3 edge: 14 LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) 76.034 ms 76.069 ms 76.066 ms Via telia.net 16 236 ms 221 ms * linkedin-ic-301441-ash-b1.c.telia.net [213.248.103.190] 17 * * * Request timed out. 18 259 ms 265 ms * 108.174.2.129 19 257 ms 299 ms 256 ms 108.174.2.129 No reply from LinkedIn support, but i see plenty of Verizon and Level3 customers cannot access LinkedIn for 24 hrs. 216.52.242.113 works ok. -SC (ASN25605) From stuarteclark at yahoo.com Sat Aug 16 17:49:18 2014 From: stuarteclark at yahoo.com (stuart clark) Date: Sat, 16 Aug 2014 18:49:18 +0100 Subject: Is LinkedIn down? In-Reply-To: <000201cfb977$41f07c40$c5d174c0$@iname.com> References: <1408203013.7755.YahooMailNeo@web173002.mail.ir2.yahoo.com> <000001cfb96b$97aa8dd0$c6ffa970$@iname.com> <1408207501.27813.YahooMailNeo@web173005.mail.ir2.yahoo.com> <000201cfb977$41f07c40$c5d174c0$@iname.com> Message-ID: <1408211358.80225.YahooMailNeo@web173005.mail.ir2.yahoo.com> Frank, Reverse is ok from L3's looking glass in Washington. SRC prefix for our London DC is 108.171.128.0/24. Cheers! On Saturday, 16 August 2014, 18:26, Frank Bulk wrote: Stuart, ? You haven?t shared your IPs but you could go to Level3?s Washington Looking Glass and see if you can trace back to your UK and Frankfurt IPs. ? Frank ? From:stuart clark [mailto:stuarteclark at yahoo.com] Sent: Saturday, August 16, 2014 11:45 AM To: Frank Bulk; nanog at nanog.org Subject: Re: Is LinkedIn down? ? Thanks Frank - www.linkedin.com is the one i see problems with testing from two locations UK and Frankfurt. London TR is below. If i jump out of our AMS location (ASN109 - via AS1299?) i dont see any problems. ? [root at ops-netops-util1 ~]# tcptraceroute linkedin.com Selected device eth0, address 10.3.4.38, port 42311 for outgoing packets Tracing the path to linkedin.com (216.52.242.86) on TCP port 80 (http), 30 hops max ? [removed] ? ?6 ?xe-5-0-0.edge5.London1.Level3.net (212.187.138.209) ?1.078 ms ?1.040 ms ?1.159 ms ?7 ?* * * ?8 ?ae-56-221.ebr2.London1.Level3.net (4.69.153.129) ?76.147 ms ?75.863 ms ?75.901 ms ?9 ?* * * 10 ?* * * 11 ?ae-48-48.ebr2.Washington1.Level3.net (4.69.202.61) ?75.557 ms ?75.550 ms ?75.511 ms 12 ?ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) ?75.700 ms ?75.502 ms ?75.644 ms 13 ?ae-3-80.edge3.Washington4.Level3.net (4.69.149.146) ?75.639 ms ?75.726 ms ?75.692 ms 14 ?LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) ?75.888 ms ?75.924 ms ?75.912 ms 15 ?* * * 16 ?* * * 17 ?* * * 18 ?* * * 19 ?199.101.162.230 ?149.661 ms ?151.158 ms ?149.616 ms 20 ?careers.linkedin.com (216.52.242.86) [open] ?149.264 ms ?149.369 ms ?149.448 ms ? ? [root at ops-netops-util1 ~]# tcptraceroute www.linkedin.com Selected device eth0, address 10.3.4.38, port 57760 for outgoing packets Tracing the path to www.linkedin.com (108.174.2.129) on TCP port 80 (http), 30 hops max ? [removed] ? ?5 ?xe-5-0-0.edge5.London1.Level3.net (212.187.138.209) ?1.060 ms ?1.082 ms ?1.041 ms ?6 ?* * * ?7 ?ae-58-223.ebr2.London1.Level3.net (4.69.153.137) ?75.830 ms ?75.929 ms ?75.739 ms ?8 ?* * * ?9 ?* * * 10 ?ae-47-47.ebr2.Washington1.Level3.net (4.69.202.57) ?75.950 ms ?76.001 ms ?75.942 ms 11 ?* ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) 75.713 ms ?75.589 ms 12 ?ae-3-80.edge3.Washington4.Level3.net (4.69.149.146) ?75.702 ms ?75.769 ms ?75.748 ms 13 ?LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) ?75.973 ms ?75.924 ms ?76.664 ms 14 ?* * * 15 ?* * * [timesouts] ? Cheers! ? -SC (ASN25605) ? On Saturday, 16 August 2014, 17:03, Frank Bulk wrote: ? Stuart, You don't tell us if it's www.linkedin.com or linkedin.com, but in any case, because they serve up that site around the world using some form of GLB it may resolve to different IP depending on where you are.? From my perspective it is working via Cogent, and I can hit 108.174.2.129, too: root at nagios:# tcptraceroute www.linkedin.com Selected device eth0.3, address 96.31.0.5, port 43355 for outgoing packets Tracing the path to www.linkedin.com (199.101.163.129) on TCP port 80 (www), 30 hops max 1? router-core-inside.mtcnet.net (96.31.0.254)? 0.253 ms? 0.193 ms? 0.203 ms 2? sxct.sxcy.mtcnet.net (167.142.156.197)? 0.194 ms? 0.131 ms? 0.129 ms 3? premier.sxcy-mlx.fbnt.netins.net (173.215.60.5)? 1.632 ms? 1.601 ms 1.583 ms 4? 38.104.184.26? 7.004 ms? 6.373 ms? 6.437 ms 5? te0-0-1-1.rcr11.dsm01.atlas.cogentco.com (38.104.184.25)? 5.913 ms 6.083 ms? 5.877 ms 6? te0-2-0-0.ccr41.ord01.atlas.cogentco.com (154.54.46.237)? 13.057 ms 13.114 ms? 13.075 ms 7? be2156.ccr21.mci01.atlas.cogentco.com (154.54.6.85)? 24.995 ms? 24.942 ms? 25.053 ms 8? be2012.ccr21.dfw01.atlas.cogentco.com (154.54.2.114)? 35.013 ms? 34.942 ms? 34.928 ms 9? be2144.ccr21.iah01.atlas.cogentco.com (154.54.25.105)? 40.455 ms? 40.749 ms? 40.709 ms 10? be2065.ccr21.lax01.atlas.cogentco.com (154.54.5.66)? 76.269 ms? 76.119 ms? 75.970 ms 11? * * * 12? 154.24.22.126? 76.351 ms? 76.296 ms? 76.257 ms 13? 38.88.244.2? 73.135 ms? 73.101 ms? 73.182 ms 14? border1.po1-20g-bbnet1.lax008.pnap.net (216.52.255.46)? 73.354 ms 73.355 ms? 73.585 ms 15? linkedin-16.border1.lax008.pnap.net (216.52.220.122)? 74.017 ms? 74.005 ms? 73.965 ms 16? * * * 17? 199.101.162.226? 74.766 ms? 74.391 ms? 74.582 ms 18? 199.101.163.129 [open]? 74.528 ms? 74.381 ms? 74.421 ms root at nagios:# root at nagios:/# tcptraceroute 108.174.2.129 Selected device eth0.3, address 96.31.0.5, port 49338 for outgoing packets Tracing the path to 108.174.2.129 on TCP port 80 (www), 30 hops max 1? router-core-inside.mtcnet.net (96.31.0.254)? 0.295 ms? 0.210 ms? 0.237 ms 2? sxct.spnc.mtcnet.net (167.142.156.194)? 0.206 ms? 0.144 ms? 0.129 ms 3? premier.spnc-mlx.fbnt.netins.net (173.215.60.1)? 15.282 ms? 4.743 ms 4.750 ms 4? ins-kb3-et-0-7-0-0.kmrr.netins.net.67.142.167.in-addr.arpa (167.142.67.50)? 8.787 ms? 8.705 ms? 8.505 ms 5? ins-kc2-et-9-3.kmrr.netins.net (167.142.67.49)? 7.170 ms? 7.183 ms 7.189 ms 6? ins-dc1-po20.desm.netins.net (167.142.67.29)? 7.623 ms? 8.936 ms? 8.135 ms 7? 207.87.180.149? 12.733 ms? 52.226 ms? 12.740 ms 8? ae1d0.mcr1.minneapolis-mn.us.xo.net (216.156.1.85)? 23.368 ms? 22.132 ms 22.052 ms 9? vb1710.rar3.chicago-il.us.xo.net (216.156.0.169)? 22.984 ms? 23.536 ms 24.016 ms 10? 207.88.14.194.ptr.us.xo.net (207.88.14.194)? 21.861 ms? 21.882 ms 21.880 ms 11? 206.111.2.65.ptr.us.xo.net (206.111.2.65)? 23.583 ms? 22.722 ms? 22.876 ms 12? ae-8.r05.chcgil09.us.bb.gin.ntt.net (129.250.4.221)? 22.630 ms? 22.751 ms? 22.817 ms 13? 165.254.191.82? 22.760 ms? 22.726 ms? 22.722 ms 14? * * * 15? * * * 16? 108.174.2.129 [open]? 36.065 ms? 36.058 ms? 36.042 ms root at nagios:/# root at nagios:/usr/lib/nagios/plugins# ./check_http -H www.linkedin.com -I 199.101.163.129 HTTP OK: HTTP/1.1 301 Moved Permanently - 1706 bytes in 0.167 second response time |time=0.166917s;;;0.000000 size=1706B;;;0 root at nagios:/usr/lib/nagios/plugins# root at nagios:/usr/lib/nagios/plugins# ./check_http -H www.linkedin.com -I 108.174.2.129 HTTP OK: HTTP/1.1 301 Moved Permanently - 1702 bytes in 0.088 second response time |time=0.088261s;;;0.000000 size=1702B;;;0 root at nagios:/usr/lib/nagios/plugins# Regards, Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of stuart clark Sent: Saturday, August 16, 2014 10:30 AM To: nanog at nanog.org Subject: Is LinkedIn down? Trace/tcptrace to 108.174.2.129 ?via Level3 - last hop is on the Linked/Level3 edge: 14 ?LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) ?76.034 ms ?76.069 ms ?76.066 ms Via?telia.net ?16 ? 236 ms ? 221 ms ? ? * ? ? linkedin-ic-301441-ash-b1.c.telia.net [213.248.103.190] ?17 ? ? * ? ? ? ?* ? ? ? ?* ? ? Request timed out. ?18 ? 259 ms ? 265 ms ? ? * ? ? 108.174.2.129 ?19 ? 257 ms ? 299 ms ? 256 ms ?108.174.2.129 No reply from LinkedIn support, but i see plenty of Verizon and Level3 customers cannot access LinkedIn for 24 hrs. 216.52.242.113 works ok. -SC (ASN25605) From tony at wicks.co.nz Sat Aug 16 19:22:59 2014 From: tony at wicks.co.nz (Tony Wicks) Date: Sun, 17 Aug 2014 07:22:59 +1200 Subject: Cisco ASR 1000 for Broadband Usage In-Reply-To: References: Message-ID: <00a201cfb987$7e893b00$7b9bb100$@wicks.co.nz> With 32k users I would recommend at least the ESP40, or even the ESP100 if you are going to grow your customer base at all. The ESP20 is really a bit small for that number of users. -----Original Message----- From: NANOG [mailto:nanog-bounces+tony=wicks.co.nz at nanog.org] On Behalf Of Shahab Vahabzadeh Sent: Sunday, 17 August 2014 1:13 a.m. To: nanog Subject: Cisco ASR 1000 for Broadband Usage Dear Friends, We have near 32K User with ISG support, any body has Idea for the partnumber of device? I decided to but Cisco ASR 1006 with two DC Power and two RP2 and two ESP-20G. Thanks -- From oz at columbus.rr.com Sat Aug 16 16:51:03 2014 From: oz at columbus.rr.com (oz at columbus.rr.com) Date: Sat, 16 Aug 2014 16:51:03 +0000 Subject: PlayStation network Message-ID: <20140816165103.Q6ZEP.361861.root@dnvrco-web26> Looking for a technical contact at PlayStation network that could help diagnose connectivity issues customers are having. Please feel free to contact me off list. Thanks, Steven Parsons From wbailey at satelliteintelligencegroup.com Sat Aug 16 19:30:40 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sat, 16 Aug 2014 19:30:40 +0000 Subject: Is LinkedIn down? In-Reply-To: <1408211358.80225.YahooMailNeo@web173005.mail.ir2.yahoo.com> References: <1408203013.7755.YahooMailNeo@web173002.mail.ir2.yahoo.com> <000001cfb96b$97aa8dd0$c6ffa970$@iname.com> <1408207501.27813.YahooMailNeo@web173005.mail.ir2.yahoo.com> <000201cfb977$41f07c40$c5d174c0$@iname.com> <1408211358.80225.YahooMailNeo@web173005.mail.ir2.yahoo.com> Message-ID: I am still seeing plenty of spam from them, so I believe they are up. //warren On 8/16/14, 10:49 AM, "stuart clark" wrote: >Frank, > >Reverse is ok from L3's looking glass in Washington. SRC prefix for our >London DC is 108.171.128.0/24. > >Cheers! >On Saturday, 16 August 2014, 18:26, Frank Bulk wrote: > > > >Stuart, > >You haven?t shared your IPs but you could go to Level3?s Washington >Looking Glass and see if you can trace back to your UK and Frankfurt IPs. > >Frank > >From:stuart clark [mailto:stuarteclark at yahoo.com] >Sent: Saturday, August 16, 2014 11:45 AM >To: Frank Bulk; nanog at nanog.org >Subject: Re: Is LinkedIn down? > >Thanks Frank - www.linkedin.com is the one i see problems with testing >from two locations UK and Frankfurt. London TR is below. >If i jump out of our AMS location (ASN109 - via AS1299 ) i dont see any >problems. > >[root at ops-netops-util1 ~]# tcptraceroute linkedin.com >Selected device eth0, address 10.3.4.38, port 42311 for outgoing packets >Tracing the path to linkedin.com (216.52.242.86) on TCP port 80 (http), >30 hops max > >[removed] > > 6 xe-5-0-0.edge5.London1.Level3.net (212.187.138.209) 1.078 ms 1.040 >ms 1.159 ms > 7 * * * > 8 ae-56-221.ebr2.London1.Level3.net (4.69.153.129) 76.147 ms 75.863 >ms 75.901 ms > 9 * * * >10 * * * >11 ae-48-48.ebr2.Washington1.Level3.net (4.69.202.61) 75.557 ms 75.550 >ms 75.511 ms >12 ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) 75.700 ms >75.502 ms 75.644 ms >13 ae-3-80.edge3.Washington4.Level3.net (4.69.149.146) 75.639 ms >75.726 ms 75.692 ms >14 LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) 75.888 ms >75.924 ms 75.912 ms >15 * * * >16 * * * >17 * * * >18 * * * >19 199.101.162.230 149.661 ms 151.158 ms 149.616 ms >20 careers.linkedin.com (216.52.242.86) [open] 149.264 ms 149.369 ms >149.448 ms > > >[root at ops-netops-util1 ~]# tcptraceroute www.linkedin.com >Selected device eth0, address 10.3.4.38, port 57760 for outgoing packets >Tracing the path to www.linkedin.com (108.174.2.129) on TCP port 80 >(http), 30 hops max > >[removed] > > 5 xe-5-0-0.edge5.London1.Level3.net (212.187.138.209) 1.060 ms 1.082 >ms 1.041 ms > 6 * * * > 7 ae-58-223.ebr2.London1.Level3.net (4.69.153.137) 75.830 ms 75.929 >ms 75.739 ms > 8 * * * > 9 * * * >10 ae-47-47.ebr2.Washington1.Level3.net (4.69.202.57) 75.950 ms 76.001 >ms 75.942 ms >11 * ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) 75.713 ms >75.589 ms >12 ae-3-80.edge3.Washington4.Level3.net (4.69.149.146) 75.702 ms >75.769 ms 75.748 ms >13 LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) 75.973 ms >75.924 ms 76.664 ms >14 * * * >15 * * * >[timesouts] > >Cheers! > >-SC (ASN25605) > >On Saturday, 16 August 2014, 17:03, Frank Bulk wrote: > >Stuart, > >You don't tell us if it's www.linkedin.com or linkedin.com, but in any >case, >because they serve up that site around the world using some form of GLB it >may resolve to different IP depending on where you are. From my >perspective >it is working via Cogent, and I can hit 108.174.2.129, too: > >root at nagios:# tcptraceroute www.linkedin.com >Selected device eth0.3, address 96.31.0.5, port 43355 for outgoing packets >Tracing the path to www.linkedin.com (199.101.163.129) on TCP port 80 >(www), >30 hops max >1 router-core-inside.mtcnet.net (96.31.0.254) 0.253 ms 0.193 ms 0.203 >ms >2 sxct.sxcy.mtcnet.net (167.142.156.197) 0.194 ms 0.131 ms 0.129 ms >3 premier.sxcy-mlx.fbnt.netins.net (173.215.60.5) 1.632 ms 1.601 ms >1.583 ms >4 38.104.184.26 7.004 ms 6.373 ms 6.437 ms >5 te0-0-1-1.rcr11.dsm01.atlas.cogentco.com (38.104.184.25) 5.913 ms >6.083 ms 5.877 ms >6 te0-2-0-0.ccr41.ord01.atlas.cogentco.com (154.54.46.237) 13.057 ms >13.114 ms 13.075 ms >7 be2156.ccr21.mci01.atlas.cogentco.com (154.54.6.85) 24.995 ms 24.942 >ms 25.053 > ms >8 be2012.ccr21.dfw01.atlas.cogentco.com (154.54.2.114) 35.013 ms 34.942 >ms 34.928 ms >9 be2144.ccr21.iah01.atlas.cogentco.com (154.54.25.105) 40.455 ms >40.749 >ms 40.709 ms >10 be2065.ccr21.lax01.atlas.cogentco.com (154.54.5.66) 76.269 ms 76.119 >ms 75.970 ms >11 * * * >12 154.24.22.126 76.351 ms 76.296 ms 76.257 ms >13 38.88.244.2 73.135 ms 73.101 ms 73.182 ms >14 border1.po1-20g-bbnet1.lax008.pnap.net (216.52.255.46) 73.354 ms >73.355 ms 73.585 ms >15 linkedin-16.border1.lax008.pnap.net (216.52.220.122) 74.017 ms >74.005 >ms > 73.965 ms >16 * * * >17 199.101.162.226 74.766 ms 74.391 ms 74.582 ms >18 199.101.163.129 [open] 74.528 ms 74.381 ms 74.421 ms >root at nagios:# > > >root at nagios:/# tcptraceroute 108.174.2.129 >Selected device eth0.3, address 96.31.0.5, port 49338 for outgoing packets >Tracing the path to 108.174.2.129 on TCP port 80 (www), 30 hops max >1 router-core-inside.mtcnet.net (96.31.0.254) 0.295 ms 0.210 ms 0.237 >ms >2 > sxct.spnc.mtcnet.net (167.142.156.194) 0.206 ms 0.144 ms 0.129 ms >3 premier.spnc-mlx.fbnt.netins.net (173.215.60.1) 15.282 ms 4.743 ms >4.750 ms >4 ins-kb3-et-0-7-0-0.kmrr.netins.net.67.142.167.in-addr.arpa >(167.142.67.50) 8.787 ms 8.705 ms 8.505 ms >5 ins-kc2-et-9-3.kmrr.netins.net (167.142.67.49) 7.170 ms 7.183 ms >7.189 ms >6 ins-dc1-po20.desm.netins.net (167.142.67.29) 7.623 ms 8.936 ms 8.135 >ms >7 207.87.180.149 12.733 ms 52.226 ms 12.740 ms >8 ae1d0.mcr1.minneapolis-mn.us.xo.net (216.156.1.85) 23.368 ms 22.132 >ms >22.052 ms >9 vb1710.rar3.chicago-il.us.xo.net > (216.156.0.169) 22.984 ms 23.536 ms >24.016 ms >10 207.88.14.194.ptr.us.xo.net (207.88.14.194) 21.861 ms 21.882 ms >21.880 ms >11 206.111.2.65.ptr.us.xo.net (206.111.2.65) 23.583 ms 22.722 ms >22.876 >ms >12 ae-8.r05.chcgil09.us.bb.gin.ntt.net (129.250.4.221) 22.630 ms 22.751 >ms 22.817 ms >13 165.254.191.82 22.760 ms 22.726 ms 22.722 ms >14 * * * >15 * * * >16 108.174.2.129 [open] 36.065 ms 36.058 ms 36.042 ms >root at nagios:/# > > >root at nagios:/usr/lib/nagios/plugins# ./check_http -H www.linkedin.com -I >199.101.163.129 >HTTP OK: HTTP/1.1 301 Moved Permanently - 1706 bytes in 0.167 second >response time |time=0.166917s;;;0.000000 size=1706B;;;0 >root at nagios:/usr/lib/nagios/plugins# >root at nagios:/usr/lib/nagios/plugins# ./check_http -H www.linkedin.com -I >108.174.2.129 >HTTP OK: HTTP/1.1 301 Moved Permanently - 1702 bytes in 0.088 second >response time |time=0.088261s;;;0.000000 size=1702B;;;0 >root at nagios:/usr/lib/nagios/plugins# > >Regards, > >Frank > >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of stuart clark >Sent: Saturday, August 16, 2014 10:30 AM >To: nanog at nanog.org >Subject: Is LinkedIn down? > >Trace/tcptrace to 108.174.2.129 via Level3 - last hop is on the >Linked/Level3 edge: > >14 LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) 76.034 ms > 76.069 ms 76.066 ms > > >Via telia.net > > 16 236 ms 221 ms * linkedin-ic-301441-ash-b1.c.telia.net >[213.248.103.190] > 17 * * * Request timed out. > 18 259 ms 265 ms * 108.174.2.129 > 19 257 ms > 299 ms 256 ms 108.174.2.129 > >No reply from LinkedIn support, but i see plenty of Verizon and Level3 >customers cannot access LinkedIn for 24 hrs. >216.52.242.113 works ok. > > >-SC (ASN25605) From frnkblk at iname.com Sat Aug 16 20:01:42 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 16 Aug 2014 15:01:42 -0500 Subject: PlayStation network In-Reply-To: <20140816165103.Q6ZEP.361861.root@dnvrco-web26> References: <20140816165103.Q6ZEP.361861.root@dnvrco-web26> Message-ID: <001701cfb98c$e63114d0$b2933e70$@iname.com> Anything related at all to this? http://www.product-reviews.net/2014/08/16/time-warner-cable-outage-linked-to-psn-issues/ The "solution" that's suggested is to point to Google's DNS servers. I wish there were more technical details. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of oz at columbus.rr.com Sent: Saturday, August 16, 2014 11:51 AM To: nanog at nanog.org Subject: PlayStation network Looking for a technical contact at PlayStation network that could help diagnose connectivity issues customers are having. Please feel free to contact me off list. Thanks, Steven Parsons From me at payam124.com Sun Aug 17 16:11:05 2014 From: me at payam124.com (Payam Poursaied) Date: Sun, 17 Aug 2014 09:11:05 -0700 Subject: anyone from leaseweb NOC? Message-ID: <004801cfba35$db67f510$9237df30$@payam124.com> Appreciate if anyone from LeaseWeb can contact me off list. Its regarding blocking an IP address. Support team does not deal. regards -payam From job at instituut.net Sun Aug 17 16:16:33 2014 From: job at instituut.net (Job Snijders) Date: Sun, 17 Aug 2014 18:16:33 +0200 Subject: anyone from leaseweb NOC? In-Reply-To: <004801cfba35$db67f510$9237df30$@payam124.com> References: <004801cfba35$db67f510$9237df30$@payam124.com> Message-ID: <20140817161633.GK50101@pc154.home> On Sun, Aug 17, 2014 at 09:11:05AM -0700, Payam Poursaied wrote: > Appreciate if anyone from LeaseWeb can contact me off list. Its regarding > blocking an IP address. Support team does not deal. Replied offlist - Job From zaid at zaidali.com Sun Aug 17 16:23:35 2014 From: zaid at zaidali.com (Zaid A. Kahn) Date: Sun, 17 Aug 2014 09:23:35 -0700 Subject: Verizon FiOS contact Message-ID: <53A15423-05C6-4E12-AFA5-E643D34E2720@zaidali.com> Please ping me off list. Zaid Sent from my iPhone From brunner at nic-naa.net Sun Aug 17 17:06:10 2014 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sun, 17 Aug 2014 10:06:10 -0700 Subject: Gmail contact Message-ID: <53F0E102.8020508@nic-naa.net> Please ping me. TiA, Eric From chris.thompson at solutioninc.com Sun Aug 17 19:56:58 2014 From: chris.thompson at solutioninc.com (Chris R. Thompson) Date: Sun, 17 Aug 2014 16:56:58 -0300 Subject: Verizon FiOS contact Message-ID: <033601cfba56$4f5064ba$14e0e7cf@solutioninc.com> Umm.. Who was this for? Christopher On Aug 17, 2014 1:31 PM, "Zaid A. Kahn" wrote: > > Please ping me off list. > > Zaid > > Sent from my iPhone Please ping me off list. Zaid Sent from my iPhone From jloiacon at csc.com Mon Aug 18 14:07:32 2014 From: jloiacon at csc.com (Joe Loiacono) Date: Mon, 18 Aug 2014 10:07:32 -0400 Subject: Announcement: FlowViewer v4.4 Released In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B0238AB57@EX01.swan.local> References: <20140814024951.GA20892@panix.com> <61DC6BC4ABA10E4489D4A73EBABAC18B0238AB57@EX01.swan.local> Message-ID: FlowViewer version 4.4 (open-source) is now available on SourceForge. FlowViewer provides a dynamic web front-end to two powerful open-source netflow data collector and analyzers, flow-tools and SiLK. FlowViewer provides the user with the ability to report, graph and track (MRTG-like) user specified subsets of network traffic (IPv4 and IPv6.) Version 4.4 is a significant upgrade with several new key features: * A visual Analysis feature that simplifies the identification of major contributors to traffic events (e.g., peak flows.) * The ability to create multiple Dashboards for different user classes (individuals, groups, networks, data centers, etc.) * More flexibility for interfacing with a wide variety of SiLK configurations. The new features extend FlowViewer's security analysis capabilities and enhance the user's general traffic situational awareness. https://sourceforge.net/projects/flowviewer Regards, Joe From Matthew.Black at csulb.edu Mon Aug 18 14:34:44 2014 From: Matthew.Black at csulb.edu (Matthew Black) Date: Mon, 18 Aug 2014 14:34:44 +0000 Subject: Is LinkedIn down? In-Reply-To: References: <1408203013.7755.YahooMailNeo@web173002.mail.ir2.yahoo.com> <000001cfb96b$97aa8dd0$c6ffa970$@iname.com> <1408207501.27813.YahooMailNeo@web173005.mail.ir2.yahoo.com> <000201cfb977$41f07c40$c5d174c0$@iname.com> <1408211358.80225.YahooMailNeo@web173005.mail.ir2.yahoo.com> Message-ID: I would cry for about 37 seconds if LinkedIn went down permanently. Then, get over it and not worry about their spam. Signed up when they first started but stopped using almost immediately when they kept requesting permission to access my contacts. matthew black [Note: speaking only for myself and not my employer or anyone else] -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Warren Bailey Sent: Saturday, August 16, 2014 12:31 PM To: stuart clark; Frank Bulk; nanog at nanog.org Subject: Re: Is LinkedIn down? I am still seeing plenty of spam from them, so I believe they are up. //warren On 8/16/14, 10:49 AM, "stuart clark" wrote: >Frank, > >Reverse is ok from L3's looking glass in Washington. SRC prefix for our >London DC is 108.171.128.0/24. > >Cheers! >On Saturday, 16 August 2014, 18:26, Frank Bulk wrote: > > > >Stuart, > >You haven?t shared your IPs but you could go to Level3?s Washington >Looking Glass and see if you can trace back to your UK and Frankfurt IPs. > >Frank > >From:stuart clark [mailto:stuarteclark at yahoo.com] >Sent: Saturday, August 16, 2014 11:45 AM >To: Frank Bulk; nanog at nanog.org >Subject: Re: Is LinkedIn down? > >Thanks Frank - www.linkedin.com is the one i see problems with testing >from two locations UK and Frankfurt. London TR is below. >If i jump out of our AMS location (ASN109 - via AS1299 ) i dont see any >problems. > >[root at ops-netops-util1 ~]# tcptraceroute linkedin.com Selected device >eth0, address 10.3.4.38, port 42311 for outgoing packets Tracing the >path to linkedin.com (216.52.242.86) on TCP port 80 (http), >30 hops max > >[removed] > > 6 xe-5-0-0.edge5.London1.Level3.net (212.187.138.209) 1.078 ms >1.040 ms 1.159 ms > 7 * * * > 8 ae-56-221.ebr2.London1.Level3.net (4.69.153.129) 76.147 ms 75.863 >ms 75.901 ms > 9 * * * >10 * * * >11 ae-48-48.ebr2.Washington1.Level3.net (4.69.202.61) 75.557 ms >75.550 ms 75.511 ms >12 ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) 75.700 ms >75.502 ms 75.644 ms >13 ae-3-80.edge3.Washington4.Level3.net (4.69.149.146) 75.639 ms >75.726 ms 75.692 ms >14 LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) 75.888 ms >75.924 ms 75.912 ms >15 * * * >16 * * * >17 * * * >18 * * * >19 199.101.162.230 149.661 ms 151.158 ms 149.616 ms >20 careers.linkedin.com (216.52.242.86) [open] 149.264 ms 149.369 ms >149.448 ms > > >[root at ops-netops-util1 ~]# tcptraceroute www.linkedin.com Selected >device eth0, address 10.3.4.38, port 57760 for outgoing packets Tracing >the path to www.linkedin.com (108.174.2.129) on TCP port 80 (http), 30 >hops max > >[removed] > > 5 xe-5-0-0.edge5.London1.Level3.net (212.187.138.209) 1.060 ms >1.082 ms 1.041 ms > 6 * * * > 7 ae-58-223.ebr2.London1.Level3.net (4.69.153.137) 75.830 ms 75.929 >ms 75.739 ms > 8 * * * > 9 * * * >10 ae-47-47.ebr2.Washington1.Level3.net (4.69.202.57) 75.950 ms >76.001 ms 75.942 ms >11 * ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) 75.713 ms >75.589 ms >12 ae-3-80.edge3.Washington4.Level3.net (4.69.149.146) 75.702 ms >75.769 ms 75.748 ms >13 LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) 75.973 ms >75.924 ms 76.664 ms >14 * * * >15 * * * >[timesouts] > >Cheers! > >-SC (ASN25605) > >On Saturday, 16 August 2014, 17:03, Frank Bulk wrote: > >Stuart, > >You don't tell us if it's www.linkedin.com or linkedin.com, but in any >case, because they serve up that site around the world using some form >of GLB it may resolve to different IP depending on where you are. From >my perspective it is working via Cogent, and I can hit 108.174.2.129, >too: > >root at nagios:# tcptraceroute www.linkedin.com Selected device eth0.3, >address 96.31.0.5, port 43355 for outgoing packets Tracing the path to >www.linkedin.com (199.101.163.129) on TCP port 80 (www), >30 hops max >1 router-core-inside.mtcnet.net (96.31.0.254) 0.253 ms 0.193 ms >0.203 ms >2 sxct.sxcy.mtcnet.net (167.142.156.197) 0.194 ms 0.131 ms 0.129 ms >3 premier.sxcy-mlx.fbnt.netins.net (173.215.60.5) 1.632 ms 1.601 ms >1.583 ms >4 38.104.184.26 7.004 ms 6.373 ms 6.437 ms >5 te0-0-1-1.rcr11.dsm01.atlas.cogentco.com (38.104.184.25) 5.913 ms >6.083 ms 5.877 ms >6 te0-2-0-0.ccr41.ord01.atlas.cogentco.com (154.54.46.237) 13.057 ms >13.114 ms 13.075 ms >7 be2156.ccr21.mci01.atlas.cogentco.com (154.54.6.85) 24.995 ms >24.942 ms 25.053 ms >8 be2012.ccr21.dfw01.atlas.cogentco.com (154.54.2.114) 35.013 ms >34.942 ms 34.928 ms >9 be2144.ccr21.iah01.atlas.cogentco.com (154.54.25.105) 40.455 ms >40.749 >ms 40.709 ms >10 be2065.ccr21.lax01.atlas.cogentco.com (154.54.5.66) 76.269 ms >76.119 ms 75.970 ms >11 * * * >12 154.24.22.126 76.351 ms 76.296 ms 76.257 ms >13 38.88.244.2 73.135 ms 73.101 ms 73.182 ms >14 border1.po1-20g-bbnet1.lax008.pnap.net (216.52.255.46) 73.354 ms >73.355 ms 73.585 ms >15 linkedin-16.border1.lax008.pnap.net (216.52.220.122) 74.017 ms >74.005 >ms > 73.965 ms >16 * * * >17 199.101.162.226 74.766 ms 74.391 ms 74.582 ms >18 199.101.163.129 [open] 74.528 ms 74.381 ms 74.421 ms >root at nagios:# > > >root at nagios:/# tcptraceroute 108.174.2.129 Selected device eth0.3, >address 96.31.0.5, port 49338 for outgoing packets Tracing the path to >108.174.2.129 on TCP port 80 (www), 30 hops max >1 router-core-inside.mtcnet.net (96.31.0.254) 0.295 ms 0.210 ms >0.237 ms >2 > sxct.spnc.mtcnet.net (167.142.156.194) 0.206 ms 0.144 ms 0.129 ms >3 premier.spnc-mlx.fbnt.netins.net (173.215.60.1) 15.282 ms 4.743 ms >4.750 ms >4 ins-kb3-et-0-7-0-0.kmrr.netins.net.67.142.167.in-addr.arpa >(167.142.67.50) 8.787 ms 8.705 ms 8.505 ms >5 ins-kc2-et-9-3.kmrr.netins.net (167.142.67.49) 7.170 ms 7.183 ms >7.189 ms >6 ins-dc1-po20.desm.netins.net (167.142.67.29) 7.623 ms 8.936 ms >8.135 ms >7 207.87.180.149 12.733 ms 52.226 ms 12.740 ms >8 ae1d0.mcr1.minneapolis-mn.us.xo.net (216.156.1.85) 23.368 ms >22.132 ms >22.052 ms >9 vb1710.rar3.chicago-il.us.xo.net > (216.156.0.169) 22.984 ms 23.536 ms >24.016 ms >10 207.88.14.194.ptr.us.xo.net (207.88.14.194) 21.861 ms 21.882 ms >21.880 ms >11 206.111.2.65.ptr.us.xo.net (206.111.2.65) 23.583 ms 22.722 ms >22.876 >ms >12 ae-8.r05.chcgil09.us.bb.gin.ntt.net (129.250.4.221) 22.630 ms >22.751 ms 22.817 ms >13 165.254.191.82 22.760 ms 22.726 ms 22.722 ms >14 * * * >15 * * * >16 108.174.2.129 [open] 36.065 ms 36.058 ms 36.042 ms >root at nagios:/# > > >root at nagios:/usr/lib/nagios/plugins# ./check_http -H www.linkedin.com >-I >199.101.163.129 >HTTP OK: HTTP/1.1 301 Moved Permanently - 1706 bytes in 0.167 second >response time |time=0.166917s;;;0.000000 size=1706B;;;0 >root at nagios:/usr/lib/nagios/plugins# >root at nagios:/usr/lib/nagios/plugins# ./check_http -H www.linkedin.com >-I >108.174.2.129 >HTTP OK: HTTP/1.1 301 Moved Permanently - 1702 bytes in 0.088 second >response time |time=0.088261s;;;0.000000 size=1702B;;;0 >root at nagios:/usr/lib/nagios/plugins# > >Regards, > >Frank > >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of stuart clark >Sent: Saturday, August 16, 2014 10:30 AM >To: nanog at nanog.org >Subject: Is LinkedIn down? > >Trace/tcptrace to 108.174.2.129 via Level3 - last hop is on the >Linked/Level3 edge: > >14 LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) 76.034 ms > 76.069 ms 76.066 ms > > >Via telia.net > > 16 236 ms 221 ms * linkedin-ic-301441-ash-b1.c.telia.net >[213.248.103.190] > 17 * * * Request timed out. > 18 259 ms 265 ms * 108.174.2.129 > 19 257 ms > 299 ms 256 ms 108.174.2.129 > >No reply from LinkedIn support, but i see plenty of Verizon and Level3 >customers cannot access LinkedIn for 24 hrs. >216.52.242.113 works ok. > > >-SC (ASN25605) From wbailey at satelliteintelligencegroup.com Mon Aug 18 15:44:09 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 18 Aug 2014 15:44:09 +0000 Subject: Is LinkedIn down? In-Reply-To: References: <1408203013.7755.YahooMailNeo@web173002.mail.ir2.yahoo.com> <000001cfb96b$97aa8dd0$c6ffa970$@iname.com> <1408207501.27813.YahooMailNeo@web173005.mail.ir2.yahoo.com> <000201cfb977$41f07c40$c5d174c0$@iname.com> <1408211358.80225.YahooMailNeo@web173005.mail.ir2.yahoo.com> , Message-ID: I took a picture of my wife for my her profile on my phone, and it ended up on a profile they created for her. She has no idea what LinkedIn is, but she's got a profile and a picture. I wanted to like them, but they are simply douchebags. They give zero thought to how their customer would want to be treated and they consume your entire life. I can't wait to see them at a trade show or get an email about the class action someone is filing soon. And if you're from LinkedIn and reading this.. Quit now and save your soul. Your employer makes the Internet a less valuable tool by degrading it into some mega corporate data fleecing machine. Have a good week....! ;) Speaking for all rational people who expect a "social media" website to stay in their lane. Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Matthew Black Date: 08/18/2014 7:37 AM (GMT-08:00) To: nanog at nanog.org Subject: RE: Is LinkedIn down? I would cry for about 37 seconds if LinkedIn went down permanently. Then, get over it and not worry about their spam. Signed up when they first started but stopped using almost immediately when they kept requesting permission to access my contacts. matthew black [Note: speaking only for myself and not my employer or anyone else] -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Warren Bailey Sent: Saturday, August 16, 2014 12:31 PM To: stuart clark; Frank Bulk; nanog at nanog.org Subject: Re: Is LinkedIn down? I am still seeing plenty of spam from them, so I believe they are up. //warren On 8/16/14, 10:49 AM, "stuart clark" wrote: >Frank, > >Reverse is ok from L3's looking glass in Washington. SRC prefix for our >London DC is 108.171.128.0/24. > >Cheers! >On Saturday, 16 August 2014, 18:26, Frank Bulk wrote: > > > >Stuart, > >You haven?t shared your IPs but you could go to Level3?s Washington >Looking Glass and see if you can trace back to your UK and Frankfurt IPs. > >Frank > >From:stuart clark [mailto:stuarteclark at yahoo.com] >Sent: Saturday, August 16, 2014 11:45 AM >To: Frank Bulk; nanog at nanog.org >Subject: Re: Is LinkedIn down? > >Thanks Frank - www.linkedin.com is the one i see problems with testing >from two locations UK and Frankfurt. London TR is below. >If i jump out of our AMS location (ASN109 - via AS1299 ) i dont see any >problems. > >[root at ops-netops-util1 ~]# tcptraceroute linkedin.com Selected device >eth0, address 10.3.4.38, port 42311 for outgoing packets Tracing the >path to linkedin.com (216.52.242.86) on TCP port 80 (http), >30 hops max > >[removed] > > 6 xe-5-0-0.edge5.London1.Level3.net (212.187.138.209) 1.078 ms >1.040 ms 1.159 ms > 7 * * * > 8 ae-56-221.ebr2.London1.Level3.net (4.69.153.129) 76.147 ms 75.863 >ms 75.901 ms > 9 * * * >10 * * * >11 ae-48-48.ebr2.Washington1.Level3.net (4.69.202.61) 75.557 ms >75.550 ms 75.511 ms >12 ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) 75.700 ms >75.502 ms 75.644 ms >13 ae-3-80.edge3.Washington4.Level3.net (4.69.149.146) 75.639 ms >75.726 ms 75.692 ms >14 LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) 75.888 ms >75.924 ms 75.912 ms >15 * * * >16 * * * >17 * * * >18 * * * >19 199.101.162.230 149.661 ms 151.158 ms 149.616 ms >20 careers.linkedin.com (216.52.242.86) [open] 149.264 ms 149.369 ms >149.448 ms > > >[root at ops-netops-util1 ~]# tcptraceroute www.linkedin.com Selected >device eth0, address 10.3.4.38, port 57760 for outgoing packets Tracing >the path to www.linkedin.com (108.174.2.129) on TCP port 80 (http), 30 >hops max > >[removed] > > 5 xe-5-0-0.edge5.London1.Level3.net (212.187.138.209) 1.060 ms >1.082 ms 1.041 ms > 6 * * * > 7 ae-58-223.ebr2.London1.Level3.net (4.69.153.137) 75.830 ms 75.929 >ms 75.739 ms > 8 * * * > 9 * * * >10 ae-47-47.ebr2.Washington1.Level3.net (4.69.202.57) 75.950 ms >76.001 ms 75.942 ms >11 * ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) 75.713 ms >75.589 ms >12 ae-3-80.edge3.Washington4.Level3.net (4.69.149.146) 75.702 ms >75.769 ms 75.748 ms >13 LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) 75.973 ms >75.924 ms 76.664 ms >14 * * * >15 * * * >[timesouts] > >Cheers! > >-SC (ASN25605) > >On Saturday, 16 August 2014, 17:03, Frank Bulk wrote: > >Stuart, > >You don't tell us if it's www.linkedin.com or linkedin.com, but in any >case, because they serve up that site around the world using some form >of GLB it may resolve to different IP depending on where you are. From >my perspective it is working via Cogent, and I can hit 108.174.2.129, >too: > >root at nagios:# tcptraceroute www.linkedin.com Selected device eth0.3, >address 96.31.0.5, port 43355 for outgoing packets Tracing the path to >www.linkedin.com (199.101.163.129) on TCP port 80 (www), >30 hops max >1 router-core-inside.mtcnet.net (96.31.0.254) 0.253 ms 0.193 ms >0.203 ms >2 sxct.sxcy.mtcnet.net (167.142.156.197) 0.194 ms 0.131 ms 0.129 ms >3 premier.sxcy-mlx.fbnt.netins.net (173.215.60.5) 1.632 ms 1.601 ms >1.583 ms >4 38.104.184.26 7.004 ms 6.373 ms 6.437 ms >5 te0-0-1-1.rcr11.dsm01.atlas.cogentco.com (38.104.184.25) 5.913 ms >6.083 ms 5.877 ms >6 te0-2-0-0.ccr41.ord01.atlas.cogentco.com (154.54.46.237) 13.057 ms >13.114 ms 13.075 ms >7 be2156.ccr21.mci01.atlas.cogentco.com (154.54.6.85) 24.995 ms >24.942 ms 25.053 ms >8 be2012.ccr21.dfw01.atlas.cogentco.com (154.54.2.114) 35.013 ms >34.942 ms 34.928 ms >9 be2144.ccr21.iah01.atlas.cogentco.com (154.54.25.105) 40.455 ms >40.749 >ms 40.709 ms >10 be2065.ccr21.lax01.atlas.cogentco.com (154.54.5.66) 76.269 ms >76.119 ms 75.970 ms >11 * * * >12 154.24.22.126 76.351 ms 76.296 ms 76.257 ms >13 38.88.244.2 73.135 ms 73.101 ms 73.182 ms >14 border1.po1-20g-bbnet1.lax008.pnap.net (216.52.255.46) 73.354 ms >73.355 ms 73.585 ms >15 linkedin-16.border1.lax008.pnap.net (216.52.220.122) 74.017 ms >74.005 >ms > 73.965 ms >16 * * * >17 199.101.162.226 74.766 ms 74.391 ms 74.582 ms >18 199.101.163.129 [open] 74.528 ms 74.381 ms 74.421 ms >root at nagios:# > > >root at nagios:/# tcptraceroute 108.174.2.129 Selected device eth0.3, >address 96.31.0.5, port 49338 for outgoing packets Tracing the path to >108.174.2.129 on TCP port 80 (www), 30 hops max >1 router-core-inside.mtcnet.net (96.31.0.254) 0.295 ms 0.210 ms >0.237 ms >2 > sxct.spnc.mtcnet.net (167.142.156.194) 0.206 ms 0.144 ms 0.129 ms >3 premier.spnc-mlx.fbnt.netins.net (173.215.60.1) 15.282 ms 4.743 ms >4.750 ms >4 ins-kb3-et-0-7-0-0.kmrr.netins.net.67.142.167.in-addr.arpa >(167.142.67.50) 8.787 ms 8.705 ms 8.505 ms >5 ins-kc2-et-9-3.kmrr.netins.net (167.142.67.49) 7.170 ms 7.183 ms >7.189 ms >6 ins-dc1-po20.desm.netins.net (167.142.67.29) 7.623 ms 8.936 ms >8.135 ms >7 207.87.180.149 12.733 ms 52.226 ms 12.740 ms >8 ae1d0.mcr1.minneapolis-mn.us.xo.net (216.156.1.85) 23.368 ms >22.132 ms >22.052 ms >9 vb1710.rar3.chicago-il.us.xo.net > (216.156.0.169) 22.984 ms 23.536 ms >24.016 ms >10 207.88.14.194.ptr.us.xo.net (207.88.14.194) 21.861 ms 21.882 ms >21.880 ms >11 206.111.2.65.ptr.us.xo.net (206.111.2.65) 23.583 ms 22.722 ms >22.876 >ms >12 ae-8.r05.chcgil09.us.bb.gin.ntt.net (129.250.4.221) 22.630 ms >22.751 ms 22.817 ms >13 165.254.191.82 22.760 ms 22.726 ms 22.722 ms >14 * * * >15 * * * >16 108.174.2.129 [open] 36.065 ms 36.058 ms 36.042 ms >root at nagios:/# > > >root at nagios:/usr/lib/nagios/plugins# ./check_http -H www.linkedin.com >-I >199.101.163.129 >HTTP OK: HTTP/1.1 301 Moved Permanently - 1706 bytes in 0.167 second >response time |time=0.166917s;;;0.000000 size=1706B;;;0 >root at nagios:/usr/lib/nagios/plugins# >root at nagios:/usr/lib/nagios/plugins# ./check_http -H www.linkedin.com >-I >108.174.2.129 >HTTP OK: HTTP/1.1 301 Moved Permanently - 1702 bytes in 0.088 second >response time |time=0.088261s;;;0.000000 size=1702B;;;0 >root at nagios:/usr/lib/nagios/plugins# > >Regards, > >Frank > >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of stuart clark >Sent: Saturday, August 16, 2014 10:30 AM >To: nanog at nanog.org >Subject: Is LinkedIn down? > >Trace/tcptrace to 108.174.2.129 via Level3 - last hop is on the >Linked/Level3 edge: > >14 LINKEDIN-CO.edge3.Washington4.Level3.net (4.53.116.150) 76.034 ms > 76.069 ms 76.066 ms > > >Via telia.net > > 16 236 ms 221 ms * linkedin-ic-301441-ash-b1.c.telia.net >[213.248.103.190] > 17 * * * Request timed out. > 18 259 ms 265 ms * 108.174.2.129 > 19 257 ms > 299 ms 256 ms 108.174.2.129 > >No reply from LinkedIn support, but i see plenty of Verizon and Level3 >customers cannot access LinkedIn for 24 hrs. >216.52.242.113 works ok. > > >-SC (ASN25605) From lists at die.net Mon Aug 18 16:38:19 2014 From: lists at die.net (Aaron Hopkins) Date: Mon, 18 Aug 2014 09:38:19 -0700 (PDT) Subject: Akamai charges for IPv6 support? Message-ID: Is it normal to bill for IPv6 service as a separate product? I was surprised to hear from from my Akamai rep they they do: > Hi Aaron, We can add the IPV6 service to the contract at an additional > cost of $XXX/month. Please let me know if you would like to go ahead with > the service and I can create the contract and send it for your review. I've been working on adding IPv6 support to my current project on my own time, and am now ready to enable it. But as soon as there is a recurring cost associated with IPv6 support, I need to be able to justify it. And I'm afraid that I can't currently explain a benefit of enabling IPv6 for our users. I'll likely end up not doing so while we're still an Akamai customer. It's Akamai's network, so it's their choice. But big players adding friction to enabling IPv6 certainly doesn't seem in everyone's best interests in the long-term. -- Aaron From mehmet at akcin.net Mon Aug 18 16:45:39 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 18 Aug 2014 09:45:39 -0700 Subject: Akamai charges for IPv6 support? In-Reply-To: References: Message-ID: <53f22dbc.c2ae440a.16fa.ffffa55f@mx.google.com> What did they say when you asked them(Akamai)? I would imagine ipv6 to be included in price not an additional fee. -----Original Message----- From: "Aaron Hopkins" Sent: ?8/?18/?2014 9:38 AM To: "nanog at nanog.org" Subject: Akamai charges for IPv6 support? Is it normal to bill for IPv6 service as a separate product? I was surprised to hear from from my Akamai rep they they do: > Hi Aaron, We can add the IPV6 service to the contract at an additional > cost of $XXX/month. Please let me know if you would like to go ahead with > the service and I can create the contract and send it for your review. I've been working on adding IPv6 support to my current project on my own time, and am now ready to enable it. But as soon as there is a recurring cost associated with IPv6 support, I need to be able to justify it. And I'm afraid that I can't currently explain a benefit of enabling IPv6 for our users. I'll likely end up not doing so while we're still an Akamai customer. It's Akamai's network, so it's their choice. But big players adding friction to enabling IPv6 certainly doesn't seem in everyone's best interests in the long-term. -- Aaron From sander at steffann.nl Mon Aug 18 16:49:33 2014 From: sander at steffann.nl (Sander Steffann) Date: Mon, 18 Aug 2014 18:49:33 +0200 Subject: Akamai charges for IPv6 support? In-Reply-To: References: Message-ID: <14EACA71-F57C-4EAF-A0A5-91464B3C3ACF@steffann.nl> Hi Aaron, > Is it normal to bill for IPv6 service as a separate product? I was > surprised to hear from from my Akamai rep they they do: > >> Hi Aaron, We can add the IPV6 service to the contract at an additional >> cost of $XXX/month. Please let me know if you would like to go ahead with >> the service and I can create the contract and send it for your review. Sad to hear they are still doing this. I though they had learned by now :( Cheers, Sander From lists at die.net Mon Aug 18 16:53:46 2014 From: lists at die.net (Aaron Hopkins) Date: Mon, 18 Aug 2014 09:53:46 -0700 (PDT) Subject: Akamai charges for IPv6 support? In-Reply-To: <53f22dbc.c2ae440a.16fa.ffffa55f@mx.google.com> References: <53f22dbc.c2ae440a.16fa.ffffa55f@mx.google.com> Message-ID: On Mon, 18 Aug 2014, Mehmet Akcin wrote: > What did they say when you asked them(Akamai)? I quoted their response in my mail; sorry if that wasn't clear. They offered to enable IPv6 service for a non-trivial monthly recurring fee, which they offered to send me a revised contract to include. > I would imagine ipv6 to be included in price not an additional fee. I was surprised to find that wasn't the case. -- Aaron From rubensk at gmail.com Mon Aug 18 16:54:58 2014 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 18 Aug 2014 13:54:58 -0300 Subject: Akamai charges for IPv6 support? In-Reply-To: References: Message-ID: On Mon, Aug 18, 2014 at 1:38 PM, Aaron Hopkins wrote: > Is it normal to bill for IPv6 service as a separate product? I was > surprised to hear from from my Akamai rep they they do: > > Hi Aaron, We can add the IPV6 service to the contract at an additional >> cost of $XXX/month. Please let me know if you would like to go ahead with >> the service and I can create the contract and send it for your review. >> > > I've been working on adding IPv6 support to my current project on my own > time, and am now ready to enable it. But as soon as there is a recurring > cost associated with IPv6 support, I need to be able to justify it. And > I'm > afraid that I can't currently explain a benefit of enabling IPv6 for our > users. I'll likely end up not doing so while we're still an Akamai > customer. > > It's Akamai's network, so it's their choice. But big players adding > friction to enabling IPv6 certainly doesn't seem in everyone's best > interests in the long-term. Is there a chargemoreforipv6.die.die.die newsgroup around ? Rubens From mehmet at akcin.net Mon Aug 18 16:56:24 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 18 Aug 2014 09:56:24 -0700 Subject: Akamai charges for IPv6 support? In-Reply-To: References: <53f22dbc.c2ae440a.16fa.ffffa55f@mx.google.com> Message-ID: <53f23040.c77c420a.4d8e.ffffa012@mx.google.com> I meant to ask. Did you ask akamai why they would be charging for ipv6? Is there any logical reason other than just wanting to make little more money, that makes them have to charge for ipv6? -----Original Message----- From: "Aaron Hopkins" Sent: ?8/?18/?2014 9:53 AM To: "Mehmet Akcin" Cc: "nanog at nanog.org" Subject: RE: Akamai charges for IPv6 support? On Mon, 18 Aug 2014, Mehmet Akcin wrote: > What did they say when you asked them(Akamai)? I quoted their response in my mail; sorry if that wasn't clear. They offered to enable IPv6 service for a non-trivial monthly recurring fee, which they offered to send me a revised contract to include. > I would imagine ipv6 to be included in price not an additional fee. I was surprised to find that wasn't the case. -- Aaron From brent at brentrjones.com Mon Aug 18 17:00:18 2014 From: brent at brentrjones.com (Brent Jones) Date: Mon, 18 Aug 2014 10:00:18 -0700 Subject: Akamai charges for IPv6 support? In-Reply-To: References: <53f22dbc.c2ae440a.16fa.ffffa55f@mx.google.com> Message-ID: Luckily, there are a lot better CDNs out there with better features and pricing :) On Mon, Aug 18, 2014 at 9:53 AM, Aaron Hopkins wrote: > On Mon, 18 Aug 2014, Mehmet Akcin wrote: > > What did they say when you asked them(Akamai)? >> > > I quoted their response in my mail; sorry if that wasn't clear. They > offered to enable IPv6 service for a non-trivial monthly recurring fee, > which they offered to send me a revised contract to include. > > > I would imagine ipv6 to be included in price not an additional fee. >> > > I was surprised to find that wasn't the case. > > -- Aaron > -- Brent Jones brent at brentrjones.com From randy at psg.com Mon Aug 18 17:00:29 2014 From: randy at psg.com (randy at psg.com) Date: Mon, 18 Aug 2014 19:00:29 +0200 (CEST) Subject: Urgent Message-ID: <0031d367e1b385685fedab145c2df48e@dizum.com> Contact for God, please reach out to me offlist. Regards, -AS666 NOC From clayton at MNSi.Net Mon Aug 18 17:08:19 2014 From: clayton at MNSi.Net (Clayton Zekelman) Date: Mon, 18 Aug 2014 13:08:19 -0400 Subject: Akamai charges for IPv6 support? In-Reply-To: <53f23040.c77c420a.4d8e.ffffa012@mx.google.com> References: <53f22dbc.c2ae440a.16fa.ffffa55f@mx.google.com> <53f23040.c77c420a.4d8e.ffffa012@mx.google.com> Message-ID: <1408381700_59615@surgemail.mnsi.net> Just thinking aloud, they may justify it based on the fact that many ISPs they have colocated servers with do not support IPv6 yet, so they end up having to send that traffic through more costly routes. That argument is a bit hollow though - they should be taking a leadership role in adoption, rather than putting up roadblocks. At 12:56 PM 18/08/2014, Mehmet Akcin wrote: >I meant to ask. Did you ask akamai why they >would be charging for ipv6? Is there any logical >reason other than just wanting to make little >more money, that makes them have to charge for ipv6? > >-----Original Message----- >From: "Aaron Hopkins" >Sent: ???8/???18/???2014 9:53 AM >To: "Mehmet Akcin" >Cc: "nanog at nanog.org" >Subject: RE: Akamai charges for IPv6 support? > >On Mon, 18 Aug 2014, Mehmet Akcin wrote: > > > What did they say when you asked them(Akamai)? > >I quoted their response in my mail; sorry if that wasn't clear. They >offered to enable IPv6 service for a non-trivial monthly recurring fee, >which they offered to send me a revised contract to include. > > > I would imagine ipv6 to be included in price not an additional fee. > >I was surprised to find that wasn't the case. > > -- Aaron --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From johns at sstar.com Mon Aug 18 17:09:26 2014 From: johns at sstar.com (John Souvestre) Date: Mon, 18 Aug 2014 12:09:26 -0500 Subject: Akamai charges for IPv6 support? In-Reply-To: References: Message-ID: <011b01cfbb07$2b61d230$82257690$@sstar.com> Is there an equivalent discount for not using IPv4 anymore? :) John ??? John Souvestre - New Orleans LA -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Aaron Hopkins Sent: 2014 August 18, Mon 11:38 To: nanog at nanog.org Subject: Akamai charges for IPv6 support? Is it normal to bill for IPv6 service as a separate product? I was surprised to hear from from my Akamai rep they they do: > Hi Aaron, We can add the IPV6 service to the contract at an additional > cost of $XXX/month. Please let me know if you would like to go ahead > with the service and I can create the contract and send it for your review. I've been working on adding IPv6 support to my current project on my own time, and am now ready to enable it. But as soon as there is a recurring cost associated with IPv6 support, I need to be able to justify it. And I'm afraid that I can't currently explain a benefit of enabling IPv6 for our users. I'll likely end up not doing so while we're still an Akamai customer. It's Akamai's network, so it's their choice. But big players adding friction to enabling IPv6 certainly doesn't seem in everyone's best interests in the long-term. -- Aaron From corbe at corbe.net Mon Aug 18 17:15:09 2014 From: corbe at corbe.net (Daniel Corbe) Date: Mon, 18 Aug 2014 13:15:09 -0400 Subject: Urgent In-Reply-To: <0031d367e1b385685fedab145c2df48e@dizum.com> References: <0031d367e1b385685fedab145c2df48e@dizum.com> Message-ID: <6932803707DD44EA8095D690FE486848@dpctablet> http://www.christianforums.com/t3057187/ -----Original Message----- From: randy at psg.com Sent: Monday, August 18, 2014 1:00 PM To: nanog at nanog.org Subject: Urgent Contact for God, please reach out to me offlist. Regards, -AS666 NOC From bkain1 at ford.com Mon Aug 18 17:20:48 2014 From: bkain1 at ford.com (Kain, Rebecca (.)) Date: Mon, 18 Aug 2014 17:20:48 +0000 Subject: Urgent In-Reply-To: <0031d367e1b385685fedab145c2df48e@dizum.com> References: <0031d367e1b385685fedab145c2df48e@dizum.com> Message-ID: <7DB845D64966DC44A1CC592780539B4B011E00CD@nafmbx47.exchange.ford.com> Which one? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of randy at psg.com Sent: Monday, August 18, 2014 1:00 PM To: nanog at nanog.org Subject: Urgent Contact for God, please reach out to me offlist. Regards, -AS666 NOC From cb.list6 at gmail.com Mon Aug 18 17:29:58 2014 From: cb.list6 at gmail.com (Ca By) Date: Mon, 18 Aug 2014 10:29:58 -0700 Subject: Akamai charges for IPv6 support? In-Reply-To: References: Message-ID: On Mon, Aug 18, 2014 at 9:38 AM, Aaron Hopkins wrote: > Is it normal to bill for IPv6 service as a separate product? I was > surprised to hear from from my Akamai rep they they do: > >> Hi Aaron, We can add the IPV6 service to the contract at an additional >> cost of $XXX/month. Please let me know if you would like to go ahead with >> the service and I can create the contract and send it for your review. > > > I've been working on adding IPv6 support to my current project on my own > time, and am now ready to enable it. But as soon as there is a recurring > cost associated with IPv6 support, I need to be able to justify it. And I'm > afraid that I can't currently explain a benefit of enabling IPv6 for our > users. I'll likely end up not doing so while we're still an Akamai > customer. > > It's Akamai's network, so it's their choice. But big players adding > friction to enabling IPv6 certainly doesn't seem in everyone's best > interests in the long-term. > > -- Aaron Cloudflare has a particularly progressive approach to IPv6 and SSL / TLS, you may want to look at them. http://blog.cloudflare.com/eliminating-the-last-reasons-to-not-enable-ipv6 From dr at cluenet.de Mon Aug 18 17:54:43 2014 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 18 Aug 2014 19:54:43 +0200 Subject: Urgent In-Reply-To: <7DB845D64966DC44A1CC592780539B4B011E00CD@nafmbx47.exchange.ford.com> References: <0031d367e1b385685fedab145c2df48e@dizum.com> <7DB845D64966DC44A1CC592780539B4B011E00CD@nafmbx47.exchange.ford.com> Message-ID: <20140818175443.GA1953@srv03.cluenet.de> Just send your request to the all-gods well-known multicast group. On Mon, Aug 18, 2014 at 05:20:48PM +0000, Kain, Rebecca (.) wrote: > Which one? > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of randy at psg.com > Sent: Monday, August 18, 2014 1:00 PM > To: nanog at nanog.org > Subject: Urgent > > Contact for God, please reach out to me offlist. > > Regards, > -AS666 NOC -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From streiner at cluebyfour.org Mon Aug 18 15:42:36 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 18 Aug 2014 11:42:36 -0400 (EDT) Subject: Urgent In-Reply-To: <20140818175443.GA1953@srv03.cluenet.de> References: <0031d367e1b385685fedab145c2df48e@dizum.com> <7DB845D64966DC44A1CC592780539B4B011E00CD@nafmbx47.exchange.ford.com> <20140818175443.GA1953@srv03.cluenet.de> Message-ID: On Mon, 18 Aug 2014, Daniel Roesen wrote: > Just send your request to the all-gods well-known multicast group. 224.6.6.6? jms > On Mon, Aug 18, 2014 at 05:20:48PM +0000, Kain, Rebecca (.) wrote: >> Which one? >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of randy at psg.com >> Sent: Monday, August 18, 2014 1:00 PM >> To: nanog at nanog.org >> Subject: Urgent >> >> Contact for God, please reach out to me offlist. >> >> Regards, >> -AS666 NOC > > -- > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 > From noam+nanog at noam.com Mon Aug 18 18:10:04 2014 From: noam+nanog at noam.com (Noam Freedman) Date: Mon, 18 Aug 2014 14:10:04 -0400 Subject: Akamai charges for IPv6 support? In-Reply-To: References: Message-ID: <60A16E6A-912B-4C48-88F5-BF252B2C226E@noam.com> Aaron, I?ll make sure someone follows up on your ticket. To help accelerate overall IPv6 adoption, we stopped charging for new conversions to IPv6 over a year ago. Probably just some misinformation in the sales force from the old policy... Feel free to reach out directly to me if you end up needing more help. Thanks, - Noam On Aug 18, 2014, at 12:38 PM, Aaron Hopkins wrote: > Is it normal to bill for IPv6 service as a separate product? I was > surprised to hear from from my Akamai rep they they do: > >> Hi Aaron, We can add the IPV6 service to the contract at an additional >> cost of $XXX/month. Please let me know if you would like to go ahead with >> the service and I can create the contract and send it for your review. > > I've been working on adding IPv6 support to my current project on my own > time, and am now ready to enable it. But as soon as there is a recurring > cost associated with IPv6 support, I need to be able to justify it. And I'm > afraid that I can't currently explain a benefit of enabling IPv6 for our > users. I'll likely end up not doing so while we're still an Akamai > customer. > > It's Akamai's network, so it's their choice. But big players adding > friction to enabling IPv6 certainly doesn't seem in everyone's best > interests in the long-term. > > -- Aaron From kauer at biplane.com.au Mon Aug 18 18:13:32 2014 From: kauer at biplane.com.au (Karl Auer) Date: Tue, 19 Aug 2014 04:13:32 +1000 Subject: Urgent In-Reply-To: <20140818175443.GA1953@srv03.cluenet.de> References: <0031d367e1b385685fedab145c2df48e@dizum.com> <7DB845D64966DC44A1CC592780539B4B011E00CD@nafmbx47.exchange.ford.com> <20140818175443.GA1953@srv03.cluenet.de> Message-ID: <1408385612.24969.67.camel@karl> On Mon, 2014-08-18 at 19:54 +0200, Daniel Roesen wrote: > Just send your request to the all-gods well-known multicast group. Doesn't work with IPv6. All IPv6 multicast addresses start with FF and it's a well-known fact that God is ineffable. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A From joe at nethead.com Mon Aug 18 18:15:39 2014 From: joe at nethead.com (Joe Hamelin) Date: Mon, 18 Aug 2014 11:15:39 -0700 Subject: Urgent In-Reply-To: <0031d367e1b385685fedab145c2df48e@dizum.com> References: <0031d367e1b385685fedab145c2df48e@dizum.com> Message-ID: On Mon, Aug 18, 2014 at 10:00 AM, wrote: > Contact for God, please reach out to me offlist. > > Per Michael Valentine Smith 127.0.0.1 should work. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From surfer at mauigateway.com Mon Aug 18 18:18:46 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 18 Aug 2014 11:18:46 -0700 Subject: Urgent Message-ID: <20140818111846.A7D4FA0C@m0048141.ppops.net> >> -----Original Message----- >> Contact for God, please reach out to me offlist. >> >> Regards, >> -AS666 NOC -------------------------------------- ASN 666 is the US army. I was curious a long time ago and looked it up... ;-) scott From mpetach at netflight.com Mon Aug 18 18:27:45 2014 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 18 Aug 2014 11:27:45 -0700 Subject: Urgent In-Reply-To: <0031d367e1b385685fedab145c2df48e@dizum.com> References: <0031d367e1b385685fedab145c2df48e@dizum.com> Message-ID: On Mon, Aug 18, 2014 at 10:00 AM, wrote: > Contact for God, please reach out to me offlist. > > Regards, > -AS666 NOC > > And this is why we're going to have the "always remember to lock your screen before stepping way from your computer" tutorial at the next member's breakfast... Matt From jschiel at flowtools.net Mon Aug 18 18:28:29 2014 From: jschiel at flowtools.net (me) Date: Mon, 18 Aug 2014 12:28:29 -0600 Subject: Urgent In-Reply-To: <1408385612.24969.67.camel@karl> References: <0031d367e1b385685fedab145c2df48e@dizum.com> <7DB845D64966DC44A1CC592780539B4B011E00CD@nafmbx47.exchange.ford.com> <20140818175443.GA1953@srv03.cluenet.de> <1408385612.24969.67.camel@karl> Message-ID: <53F245CD.4070305@flowtools.net> On 08/18/2014 12:13 PM, Karl Auer wrote: > On Mon, 2014-08-18 at 19:54 +0200, Daniel Roesen wrote: >> Just send your request to the all-gods well-known multicast group. > Doesn't work with IPv6. All IPv6 multicast addresses start with FF and > it's a well-known fact that God is ineffable. HAHAHAHAHA..... boo....groan.... --John > > Regards, K. > From hugo at slabnet.com Mon Aug 18 18:35:21 2014 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 18 Aug 2014 18:35:21 +0000 Subject: Urgent In-Reply-To: References: <0031d367e1b385685fedab145c2df48e@dizum.com> Message-ID: <20140818183521.Horde.mTH5Babj-Bu5Zpiv9cEfbg1@bamboo.slabnet.com> > Per Michael Valentine Smith 127.0.0.1 should work. This also has the benefit of working over IPv6 (::1) without violating the ineffibility Karl referred to. Although, technically, since many gods are omnipresent, shouldn't you just be able to send the packet to any address and it will be received? I'm not clear on the implementation details as I would assume the gods would need to be in promiscuous mode for that to work and I'm pretty sure that would pose a problem for some gods that are said to be omnipresent... ----- Message from Joe Hamelin --------- Date: Mon, 18 Aug 2014 11:15:39 -0700 From: Joe Hamelin Subject: Re: Urgent To: Randy Bush Cc: NANOG list > On Mon, Aug 18, 2014 at 10:00 AM, wrote: > >> Contact for God, please reach out to me offlist. >> >> > Per Michael Valentine Smith 127.0.0.1 should work. > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 ----- End message from Joe Hamelin ----- -- Hugo From jeroen at mompl.net Mon Aug 18 18:38:23 2014 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 18 Aug 2014 11:38:23 -0700 Subject: Urgent In-Reply-To: <20140818111846.A7D4FA0C@m0048141.ppops.net> References: <20140818111846.A7D4FA0C@m0048141.ppops.net> Message-ID: <53F2481F.5050005@mompl.net> Scott Weeks wrote: > >>> -----Original Message----- >>> Contact for God, please reach out to me offlist. >>> >>> Regards, >>> -AS666 NOC > -------------------------------------- > > > ASN 666 is the US army. I was curious a long time > ago and looked it up... ;-) > > scott OP is a troll, best to ignore and block: Received: from sewer.dizum.com (sewer.dizum.com [194.109.206.211]) by mail.nanog.org (Postfix) with ESMTP id B38322D429D for ; Mon, 18 Aug 2014 17:00:30 +0000 (UTC) Received: by sewer.dizum.com (Postfix, from userid 1001) id 2A28B6087A; Mon, 18 Aug 2014 19:00:29 +0200 (CEST) Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at . -- Earthquake Magnitude: 5.7 Date: 2014-08-18 18:08:23.810 UTC Date Local: 2014-08-18 11:08:23 PDT Location: 43km ESE of Dehloran, Iran Latitude: 32.5542; Longitude: 47.698 Depth: 10 km | e-quake.org From lists at die.net Mon Aug 18 18:54:44 2014 From: lists at die.net (Aaron Hopkins) Date: Mon, 18 Aug 2014 11:54:44 -0700 (PDT) Subject: Akamai charges for IPv6 support? In-Reply-To: <60A16E6A-912B-4C48-88F5-BF252B2C226E@noam.com> References: <60A16E6A-912B-4C48-88F5-BF252B2C226E@noam.com> Message-ID: On Mon, 18 Aug 2014, Noam Freedman wrote: > I'll make sure someone follows up on your ticket. To help accelerate > overall IPv6 adoption, we stopped charging for new conversions to IPv6 > over a year ago. Probably just some misinformation in the sales force > from the old policy... Oh, I hadn't expected that to be stale information. That's good to hear. > Feel free to reach out directly to me if you end up needing more help. Hopefully that won't be necessary, but thanks! -- Aaron From larrysheldon at cox.net Mon Aug 18 19:06:11 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Mon, 18 Aug 2014 14:06:11 -0500 Subject: Urgent In-Reply-To: References: Message-ID: <53F24EA3.2040906@cox.net> On 8/18/2014 12:00, randy at psg.com wrote: > Contact for God, please reach out to me offlist. > > Regards, > -AS666 NOC > This is one where YOU have to initiate the contact--response is certain but response content may be other-than-hoped-for. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn form their mistakes. From rgolodner at infratection.com Mon Aug 18 19:07:33 2014 From: rgolodner at infratection.com (Richard Golodner) Date: Mon, 18 Aug 2014 14:07:33 -0500 Subject: Urgent... Message-ID: <1408388853.1934.3.camel@Andromeda> All kidding aside, did someone contact the OP off-list to get him the help he needs? Richard From bbqroast at gmail.com Mon Aug 18 19:49:02 2014 From: bbqroast at gmail.com (mcfbbqroast .) Date: Tue, 19 Aug 2014 07:49:02 +1200 Subject: Urgent In-Reply-To: <53F2481F.5050005@mompl.net> References: <20140818111846.A7D4FA0C@m0048141.ppops.net> <53F2481F.5050005@mompl.net> Message-ID: Op is funny. Best to laugh and smile. On 19/08/2014 6:43 AM, "Jeroen van Aart" wrote: > Scott Weeks wrote: > >> >> -----Original Message----- >>>> Contact for God, please reach out to me offlist. >>>> >>>> Regards, >>>> -AS666 NOC >>>> >>> -------------------------------------- >> >> >> ASN 666 is the US army. I was curious a long time ago and looked it >> up... ;-) >> >> scott >> > > OP is a troll, best to ignore and block: > > > Received: from sewer.dizum.com (sewer.dizum.com [194.109.206.211]) > by mail.nanog.org (Postfix) with ESMTP id B38322D429D > for ; Mon, 18 Aug 2014 17:00:30 +0000 (UTC) > Received: by sewer.dizum.com (Postfix, from userid 1001) > id 2A28B6087A; Mon, 18 Aug 2014 19:00:29 +0200 (CEST) > Comments: This message did not originate from the Sender address above. > It was remailed automatically by anonymizing remailer software. > Please report problems or inappropriate use to the > remailer administrator at . > > > -- > Earthquake Magnitude: 5.7 > Date: 2014-08-18 18:08:23.810 UTC > Date Local: 2014-08-18 11:08:23 PDT > Location: 43km ESE of Dehloran, Iran > Latitude: 32.5542; Longitude: 47.698 > Depth: 10 km | e-quake.org > From m.hallgren at free.fr Mon Aug 18 19:57:32 2014 From: m.hallgren at free.fr (Michael Hallgren) Date: Mon, 18 Aug 2014 21:57:32 +0200 Subject: Urgent In-Reply-To: <53F2481F.5050005@mompl.net> References: <20140818111846.A7D4FA0C@m0048141.ppops.net> <53F2481F.5050005@mompl.net> Message-ID: <53F25AAC.5020802@free.fr> Le 18/08/2014 20:38, Jeroen van Aart a ?crit : > Scott Weeks wrote: >> >>>> -----Original Message----- >>>> Contact for God, please reach out to me offlist. >>>> >>>> Regards, >>>> -AS666 NOC >> -------------------------------------- >> >> >> ASN 666 is the US army. I was curious a long time ago and looked it >> up... ;-) >> >> scott > > OP is a troll, Sure? :-) mh > best to ignore and block: > > > Received: from sewer.dizum.com (sewer.dizum.com [194.109.206.211]) > by mail.nanog.org (Postfix) with ESMTP id B38322D429D > for ; Mon, 18 Aug 2014 17:00:30 +0000 (UTC) > Received: by sewer.dizum.com (Postfix, from userid 1001) > id 2A28B6087A; Mon, 18 Aug 2014 19:00:29 +0200 (CEST) > Comments: This message did not originate from the Sender address above. > It was remailed automatically by anonymizing remailer software. > Please report problems or inappropriate use to the > remailer administrator at . > > From DStaal at usa.net Mon Aug 18 20:22:41 2014 From: DStaal at usa.net (Daniel Staal) Date: Mon, 18 Aug 2014 16:22:41 -0400 Subject: Is LinkedIn down? In-Reply-To: References: <1408203013.7755.YahooMailNeo@web173002.mail.ir2.yahoo.com> <000001cfb96b$97aa8dd0$c6ffa970$@iname.com> <1408207501.27813.YahooMailNeo@web173005.mail.ir2.yahoo.com> <000201cfb977$41f07c40$c5d174c0$@iname.com> <1408211358.80225.YahooMailNeo@web173005.mail.ir2.yahoo.com> , Message-ID: <1A3209186B03B820EB3E45F4@[192.168.1.50]> --As of August 18, 2014 3:44:09 PM +0000, Warren Bailey is alleged to have said: > I took a picture of my wife for my her profile on my phone, and it ended > up on a profile they created for her. She has no idea what LinkedIn is, > but she's got a profile and a picture. > > I wanted to like them, but they are simply douchebags. They give zero > thought to how their customer would want to be treated and they consume > your entire life. > > I can't wait to see them at a trade show or get an email about the class > action someone is filing soon. > > And if you're from LinkedIn and reading this.. Quit now and save your > soul. Your employer makes the Internet a less valuable tool by degrading > it into some mega corporate data fleecing machine. > > Have a good week....! ;) > > Speaking for all rational people who expect a "social media" website to > stay in their lane. --As for the rest, it is mine. To everyone who feels this way, and has *some* influence: Please tell your HR people this as well. I've been searching for a job for months, and getting a LinkedIn account is 'highly recommended' by most job agencies, and outright *required* for application to some companies. Complaining here is complaining to the choir. Talk to the people who think it's a useful tool and are requiring other people to use it, against their own better judgment. Daniel T. Staal --------------------------------------------------------------- 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 Valdis.Kletnieks at vt.edu Mon Aug 18 21:29:22 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 18 Aug 2014 17:29:22 -0400 Subject: Urgent In-Reply-To: Your message of "Mon, 18 Aug 2014 19:00:29 +0200." <0031d367e1b385685fedab145c2df48e@dizum.com> References: <0031d367e1b385685fedab145c2df48e@dizum.com> Message-ID: <37752.1408397362@turing-police.cc.vt.edu> On Mon, 18 Aug 2014 19:00:29 +0200, randy at psg.com said: > Contact for God, please reach out to me offlist. They never want to talk to you unless you have proof of a support contract, and calling them to deal with an issue with one of their customers is futile... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From randy at psg.com Mon Aug 18 22:05:05 2014 From: randy at psg.com (Randy Bush) Date: Tue, 19 Aug 2014 06:05:05 +0800 Subject: Urgent In-Reply-To: <37752.1408397362@turing-police.cc.vt.edu> References: <0031d367e1b385685fedab145c2df48e@dizum.com> <37752.1408397362@turing-police.cc.vt.edu> Message-ID: > On Mon, 18 Aug 2014 19:00:29 +0200, randy at psg.com said: >> Contact for God, please reach out to me offlist. > They never want to talk to you unless you have proof of a support > contract, and calling them to deal with an issue with one of their > customers is futile... the request message was a forge, see below. damned shame i did not think of it, though. otoh, i consider the contact requests useful. randy Received: from sewer.dizum.com (sewer.dizum.com [194.109.206.211]) by mail.nanog.org (Postfix) with ESMTP id B38322D429D for ; Mon, 18 Aug 2014 17:00:30 +0000 (UTC) Received: by sewer.dizum.com (Postfix, from userid 1001) id 2A28B6087A; Mon, 18 Aug 2014 19:00:29 +0200 (CEST) Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at . Message-ID: <0031d367e1b385685fedab145c2df48e at dizum.com> From randy at psg.com Mon Aug 18 22:08:08 2014 From: randy at psg.com (Randy Bush) Date: Tue, 19 Aug 2014 06:08:08 +0800 Subject: Urgent In-Reply-To: References: <0031d367e1b385685fedab145c2df48e@dizum.com> Message-ID: >> Contact for God, please reach out to me offlist. > And this is why we're going to have the > "always remember to lock your screen > before stepping way from your computer" > tutorial at the next member's breakfast... a - the forge was not done from my screen b - my screen locks itself damned quickly the extremely rare times i leave it From jeroen at mompl.net Mon Aug 18 22:16:59 2014 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 18 Aug 2014 15:16:59 -0700 Subject: Urgent In-Reply-To: <53F25AAC.5020802@free.fr> References: <20140818111846.A7D4FA0C@m0048141.ppops.net> <53F2481F.5050005@mompl.net> <53F25AAC.5020802@free.fr> Message-ID: <53F27B5B.6060709@mompl.net> On 08/18/2014 12:57 PM, Michael Hallgren wrote: > Le 18/08/2014 20:38, Jeroen van Aart a ?crit : >> OP is a troll, > > Sure? :-) I drew that conclusion considering normally the emails coming from that address have a different origin (thus coming from a different person), i.e. coming from psg.com as opposed to an "anonymizing remailer". >> Received: from sewer.dizum.com (sewer.dizum.com [194.109.206.211]) >> by mail.nanog.org (Postfix) with ESMTP id B38322D429D >> for ; Mon, 18 Aug 2014 17:00:30 +0000 (UTC) >> Received: by sewer.dizum.com (Postfix, from userid 1001) >> id 2A28B6087A; Mon, 18 Aug 2014 19:00:29 +0200 (CEST) >> Comments: This message did not originate from the Sender address above. >> It was remailed automatically by anonymizing remailer software. >> Please report problems or inappropriate use to the >> remailer administrator at . -- Earthquake Magnitude: 5.7 Date: 2014-08-18 18:08:23.810 UTC Date Local: 2014-08-18 10:08:23 PDT Location: 43km ESE of Dehloran, Iran Latitude: 32.5542; Longitude: 47.698 Depth: 10 km | e-quake.org From lyndon at orthanc.ca Mon Aug 18 22:27:49 2014 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 18 Aug 2014 15:27:49 -0700 Subject: Urgent In-Reply-To: References: <0031d367e1b385685fedab145c2df48e@dizum.com> <37752.1408397362@turing-police.cc.vt.edu> Message-ID: <3551148A-CF19-41F4-ADD2-F8BFD8E05A1F@orthanc.ca> On Aug 18, 2014, at 3:05 PM, Randy Bush wrote: > the request message was a forge, see below. damned shame i did not > think of it, though. otoh, i consider the contact requests useful. You just blew an opportunity to get on every north american late night talk show. Oh ... (sorry) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tlyons at ivenue.com Mon Aug 18 23:42:55 2014 From: tlyons at ivenue.com (Todd Lyons) Date: Mon, 18 Aug 2014 16:42:55 -0700 Subject: Urgent In-Reply-To: <0031d367e1b385685fedab145c2df48e@dizum.com> References: <0031d367e1b385685fedab145c2df48e@dizum.com> Message-ID: I don't claim to be a prophet, but https://twitter.com/TheTweetOfGod ...Todd On Mon, Aug 18, 2014 at 10:00 AM, wrote: > Contact for God, please reach out to me offlist. > > Regards, > -AS666 NOC -- The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to. --John Levine From fmartin at linkedin.com Tue Aug 19 00:28:33 2014 From: fmartin at linkedin.com (Franck Martin) Date: Tue, 19 Aug 2014 00:28:33 +0000 Subject: Urgent In-Reply-To: References: <0031d367e1b385685fedab145c2df48e@dizum.com> Message-ID: On Aug 18, 2014, at 3:08 PM, Randy Bush wrote: >>> Contact for God, please reach out to me offlist. >> And this is why we're going to have the >> "always remember to lock your screen >> before stepping way from your computer" >> tutorial at the next member's breakfast... > > a - the forge was not done from my screen > b - my screen locks itself damned quickly the extremely rare times > i leave it Instead of finding god I found in the headers of ?Randy??s email: Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at . -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From brett at the-watsons.org Tue Aug 19 00:33:33 2014 From: brett at the-watsons.org (Brett Watson) Date: Mon, 18 Aug 2014 17:33:33 -0700 Subject: Urgent In-Reply-To: References: <0031d367e1b385685fedab145c2df48e@dizum.com> Message-ID: If only we had origin and path-based routing? -b On Aug 18, 2014, at 5:28 PM, Franck Martin wrote: > > On Aug 18, 2014, at 3:08 PM, Randy Bush wrote: > >>>> Contact for God, please reach out to me offlist. >>> And this is why we're going to have the >>> "always remember to lock your screen >>> before stepping way from your computer" >>> tutorial at the next member's breakfast... >> >> a - the forge was not done from my screen >> b - my screen locks itself damned quickly the extremely rare times >> i leave it > > > Instead of finding god I found in the headers of ?Randy??s email: > > Comments: This message did not originate from the Sender address above. > It was remailed automatically by anonymizing remailer software. > Please report problems or inappropriate use to the > remailer administrator at . From mpetach at netflight.com Tue Aug 19 00:46:28 2014 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 18 Aug 2014 17:46:28 -0700 Subject: Urgent In-Reply-To: References: <0031d367e1b385685fedab145c2df48e@dizum.com> Message-ID: On Mon, Aug 18, 2014 at 5:28 PM, Franck Martin wrote: > > On Aug 18, 2014, at 3:08 PM, Randy Bush wrote: > > Contact for God, please reach out to me offlist. > > And this is why we're going to have the > "always remember to lock your screen > before stepping way from your computer" > tutorial at the next member's breakfast... > > > a - the forge was not done from my screen > b - my screen locks itself damned quickly the extremely rare times > i leave it > > > Instead of finding god I found in the headers of ?Randy??s email: > > Comments: This message did not originate from the Sender address above. > It was remailed automatically by anonymizing remailer software. > Please report problems or inappropriate use to the > remailer administrator at . > It used to be said that "God is in the details"; for our generation, it may end up being "God is (not) in the headers". Matt From alejandroacostaalamo at gmail.com Tue Aug 19 02:30:20 2014 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Mon, 18 Aug 2014 22:00:20 -0430 Subject: Akamai charges for IPv6 support? In-Reply-To: References: <53f22dbc.c2ae440a.16fa.ffffa55f@mx.google.com> Message-ID: <53F2B6BC.5060101@gmail.com> El 8/18/2014 12:23 PM, Aaron Hopkins escribi?: > On Mon, 18 Aug 2014, Mehmet Akcin wrote: > >> What did they say when you asked them(Akamai)? > > I quoted their response in my mail; sorry if that wasn't clear. They > offered to enable IPv6 service for a non-trivial monthly recurring fee, > which they offered to send me a revised contract to include. it's so sad to hear this in August 2014 > >> I would imagine ipv6 to be included in price not an additional fee. > > I was surprised to find that wasn't the case. > > -- Aaron From matthew at matthew.at Tue Aug 19 02:47:34 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 18 Aug 2014 19:47:34 -0700 Subject: Akamai charges for IPv6 support? In-Reply-To: <53F2B6BC.5060101@gmail.com> References: <53f22dbc.c2ae440a.16fa.ffffa55f@mx.google.com> <53F2B6BC.5060101@gmail.com> Message-ID: <63BF75BE-4E53-4E17-A67A-6D5ADA633745@matthew.at> I guess you expect infrastructure to build itself for free? Matthew Kaufman Sent from my iPad > On Aug 18, 2014, at 7:30 PM, Alejandro Acosta wrote: > > > > El 8/18/2014 12:23 PM, Aaron Hopkins escribi?: >> On Mon, 18 Aug 2014, Mehmet Akcin wrote: >> >>> What did they say when you asked them(Akamai)? >> >> I quoted their response in my mail; sorry if that wasn't clear. They >> offered to enable IPv6 service for a non-trivial monthly recurring fee, >> which they offered to send me a revised contract to include. > > it's so sad to hear this in August 2014 > >> >>> I would imagine ipv6 to be included in price not an additional fee. >> >> I was surprised to find that wasn't the case. >> >> -- Aaron From marka at isc.org Tue Aug 19 03:09:52 2014 From: marka at isc.org (Mark Andrews) Date: Tue, 19 Aug 2014 13:09:52 +1000 Subject: Akamai charges for IPv6 support? In-Reply-To: Your message of "Mon, 18 Aug 2014 19:47:34 -0700." <63BF75BE-4E53-4E17-A67A-6D5ADA633745@matthew.at> References: <53f22dbc.c2ae440a.16fa.ffffa55f@mx.google.com> <53F2B6BC.5060101@gmail.com> <63BF75BE-4E53-4E17-A67A-6D5ADA633745@matthew.at> Message-ID: <20140819030952.D8B2F1D04F8C@rock.dv.isc.org> In message <63BF75BE-4E53-4E17-A67A-6D5ADA633745 at matthew.at>, Matthew Kaufman writes: > I guess you expect infrastructure to build itself for free? > > Matthew Kaufman No, I expect it to be part and parcel of the basic fees, as IPv4 is, which I'm happy to hear it is in this case. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From streiner at cluebyfour.org Tue Aug 19 01:03:09 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 18 Aug 2014 21:03:09 -0400 (EDT) Subject: Akamai charges for IPv6 support? In-Reply-To: <20140819030952.D8B2F1D04F8C@rock.dv.isc.org> References: <53f22dbc.c2ae440a.16fa.ffffa55f@mx.google.com> <53F2B6BC.5060101@gmail.com> <63BF75BE-4E53-4E17-A67A-6D5ADA633745@matthew.at> <20140819030952.D8B2F1D04F8C@rock.dv.isc.org> Message-ID: On Tue, 19 Aug 2014, Mark Andrews wrote: > No, I expect it to be part and parcel of the basic fees, as IPv4 > is, which I'm happy to hear it is in this case. Based on a response I saw in this thread earlier today, it sounds like IPv6 support is no longer a separate charge from Akamai. Perhaps that hasn't filtered out to the salescritters yet. jms From rubensk at gmail.com Tue Aug 19 03:37:47 2014 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 19 Aug 2014 00:37:47 -0300 Subject: Akamai charges for IPv6 support? In-Reply-To: References: <53f22dbc.c2ae440a.16fa.ffffa55f@mx.google.com> <53F2B6BC.5060101@gmail.com> <63BF75BE-4E53-4E17-A67A-6D5ADA633745@matthew.at> <20140819030952.D8B2F1D04F8C@rock.dv.isc.org> Message-ID: On Mon, Aug 18, 2014 at 10:03 PM, Justin M. Streiner < streiner at cluebyfour.org> wrote: > On Tue, 19 Aug 2014, Mark Andrews wrote: > > No, I expect it to be part and parcel of the basic fees, as IPv4 >> is, which I'm happy to hear it is in this case. >> > > Based on a response I saw in this thread earlier today, it sounds like > IPv6 support is no longer a separate charge from Akamai. Perhaps that > hasn't filtered out to the salescritters yet. Or they did get the memo, but realised that no sale == no commission. Rubens From streiner at cluebyfour.org Tue Aug 19 01:19:07 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 18 Aug 2014 21:19:07 -0400 (EDT) Subject: Akamai charges for IPv6 support? In-Reply-To: References: <53f22dbc.c2ae440a.16fa.ffffa55f@mx.google.com> <53F2B6BC.5060101@gmail.com> <63BF75BE-4E53-4E17-A67A-6D5ADA633745@matthew.at> <20140819030952.D8B2F1D04F8C@rock.dv.isc.org> Message-ID: On Tue, 19 Aug 2014, Rubens Kuhl wrote: > Or they did get the memo, but realised that no sale == no commission. If they got the memo and chose to ignore it, then that gives me all the ammunition I need to hit them with the biggest cluebat I have, and squeeze them for a discount for the inconvenience. Trying to charge for something that is known to be a no-charge item is bad business, and will end badly for $salescritter when they get called out for it. jms From Joel.Snyder at Opus1.COM Tue Aug 19 12:09:00 2014 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Tue, 19 Aug 2014 14:09:00 +0200 Subject: Urgent Message-ID: <53F33E5C.8000008@Opus1.COM> > OP is a troll, best to ignore and block: Be nice. Randy can be abrasive, but calling him a troll seems out of line. I like to think of him as a hobbit with shorter temper than average. Not everyone here will agree with me :-) 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 bill at herrin.us Tue Aug 19 14:08:13 2014 From: bill at herrin.us (William Herrin) Date: Tue, 19 Aug 2014 10:08:13 -0400 Subject: Urgent In-Reply-To: <53F25AAC.5020802@free.fr> References: <20140818111846.A7D4FA0C@m0048141.ppops.net> <53F2481F.5050005@mompl.net> <53F25AAC.5020802@free.fr> Message-ID: On Mon, Aug 18, 2014 at 3:57 PM, Michael Hallgren wrote: > Le 18/08/2014 20:38, Jeroen van Aart a ?crit : >>>>> -----Original Message----- >>>>> Contact for God, please reach out to me offlist. >>>>> >>>>> Regards, >>>>> -AS666 NOC >>> -------------------------------------- >> OP is a troll, > > Sure? :-) Definitely. The message may _also_ have a forged sender. ;) -Bill From rob at invaluement.com Tue Aug 19 14:15:47 2014 From: rob at invaluement.com (Rob McEwen) Date: Tue, 19 Aug 2014 10:15:47 -0400 Subject: QOS improvement suggestion for NANOG list members In-Reply-To: References: <20140818111846.A7D4FA0C@m0048141.ppops.net> <53F2481F.5050005@mompl.net> <53F25AAC.5020802@free.fr> Message-ID: <53F35C13.4030507@invaluement.com> RE: QOS improvement suggestion for NANOG list members Go to the search feature of your e-mail, and search for all messages from the NANOG list that has the word "URGENT" in the subject line... then delete them! Then, there will be a LESSER chance of overlooking a truly urgent messages from your own customers! (and hopefully that thread will die soon! Otherwise, you may need to repeat this every couple of days for a hopefully short while.) This might improve the quality of service that you provide to your own clients. -- Rob McEwen +1 (478) 475-9032 From m.hallgren at free.fr Tue Aug 19 14:16:19 2014 From: m.hallgren at free.fr (Michael Hallgren) Date: Tue, 19 Aug 2014 16:16:19 +0200 Subject: Urgent In-Reply-To: References: <20140818111846.A7D4FA0C@m0048141.ppops.net> <53F2481F.5050005@mompl.net> <53F25AAC.5020802@free.fr> Message-ID: <53F35C33.8080802@free.fr> Le 19/08/2014 16:08, William Herrin a ?crit : > On Mon, Aug 18, 2014 at 3:57 PM, Michael Hallgren wrote: >> Le 18/08/2014 20:38, Jeroen van Aart a ?crit : >>>>>> -----Original Message----- >>>>>> Contact for God, please reach out to me offlist. >>>>>> >>>>>> Regards, >>>>>> -AS666 NOC >>>> -------------------------------------- >>> OP is a troll, >> Sure? :-) > Definitely. > > The message may _also_ have a forged sender. ;) Yep, was joke/irony :-) Cheers, mh > > -Bill From eric at ericheather.com Tue Aug 19 14:32:38 2014 From: eric at ericheather.com (Eric C. Miller) Date: Tue, 19 Aug 2014 14:32:38 +0000 Subject: Akamai charges for IPv6 support? In-Reply-To: <63BF75BE-4E53-4E17-A67A-6D5ADA633745@matthew.at> References: <53f22dbc.c2ae440a.16fa.ffffa55f@mx.google.com> <53F2B6BC.5060101@gmail.com> <63BF75BE-4E53-4E17-A67A-6D5ADA633745@matthew.at> Message-ID: I thought that keeping up with the times is part of basic necessity of business. Eric Miller, CCNP Network Engineering Consultant (407) 257-5115 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matthew Kaufman Sent: Monday, August 18, 2014 10:48 PM To: Alejandro Acosta Cc: nanog at nanog.org Subject: Re: Akamai charges for IPv6 support? I guess you expect infrastructure to build itself for free? Matthew Kaufman Sent from my iPad > On Aug 18, 2014, at 7:30 PM, Alejandro Acosta wrote: > > > > El 8/18/2014 12:23 PM, Aaron Hopkins escribi?: >> On Mon, 18 Aug 2014, Mehmet Akcin wrote: >> >>> What did they say when you asked them(Akamai)? >> >> I quoted their response in my mail; sorry if that wasn't clear. They >> offered to enable IPv6 service for a non-trivial monthly recurring >> fee, which they offered to send me a revised contract to include. > > it's so sad to hear this in August 2014 > >> >>> I would imagine ipv6 to be included in price not an additional fee. >> >> I was surprised to find that wasn't the case. >> >> -- Aaron From Valdis.Kletnieks at vt.edu Tue Aug 19 15:00:34 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 19 Aug 2014 11:00:34 -0400 Subject: Akamai charges for IPv6 support? In-Reply-To: Your message of "Tue, 19 Aug 2014 14:32:38 -0000." References: <53f22dbc.c2ae440a.16fa.ffffa55f@mx.google.com> <53F2B6BC.5060101@gmail.com> <63BF75BE-4E53-4E17-A67A-6D5ADA633745@matthew.at> Message-ID: <3471.1408460434@turing-police.cc.vt.edu> On Tue, 19 Aug 2014 14:32:38 -0000, "Eric C. Miller" said: > I thought that keeping up with the times is part of basic necessity of business. Yes, but here in the US, a precedent got set when some communications companies got given really sweet deals to encourage them to deploy next-gen broadband, and the companies instead pocketed the money. We're kind of stuck with this sort of thing until Wall Street stops emphasizing quarterly profits over long-term strategic development. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From fernando at gont.com.ar Tue Aug 19 17:36:34 2014 From: fernando at gont.com.ar (Fernando Gont) Date: Tue, 19 Aug 2014 14:36:34 -0300 Subject: Fwd: DoS attacks (ICMPv6-based) resulting from IPv6 EH drops In-Reply-To: <53F33C4F.2070807@si6networks.com> References: <53F33C4F.2070807@si6networks.com> Message-ID: <53F38B22.6000709@gont.com.ar> Folks, FYI -- currently being discussed on v6ops at ietf.org Cheers, Fernando -------- Forwarded Message -------- Subject: DoS attacks (ICMPv6-based) resulting from IPv6 EH drops Date: Tue, 19 Aug 2014 09:00:15 -0300 From: Fernando Gont To: IPv6 Operations CC: 'opsec at ietf.org' Folks, Ten days ago or so we published this I-D: Section 5.2 of the I-D discusses a possible attack vector based on a combination of "forged" ICMPv6 PTB messages and IPv6 frag drops by operators, along with proposed countermeasures -- on which we'd like to hear your comments. Since Section 5.2 is in the draft, let me offer a more informal and practical explanation: 1) It is known that filtering of packets containing IPv6 Extension Headers (including the Fragment Header) is widespread (see our I-D above) 2) Let us assume that Host A is communicating with Server B, and that some node filters fragments between Host A and Server B. 3) An attacker sends a spoofed ICMPv6 PTB to server B, with a "Next Hop MTU<1280), in the hopes of eliciting "atomic fragments" (see ) from now on. 4) Now server B starts sending IPv6 atomic fragments... And since they include a frag header (and in '2)' above we noted that frags are dropped on that path), these packets get dropped (i.e., DoS). "Demo" with the icmp6 tool () -- (some addresses have been changed (anonimized), but it is trivial to pick a victim server...) "2001:db8:1:10:0:1991:8:25" is the server, and "2001:5c0:1000:a::e7d" is my own address): ---- cut here ---- ***** First of all, I telnet to port 80 of the server, and everything works as expected **** fgont at satellite:~$ telnet 2001:db8:1:10:0:1991:8:25 80 Trying 2001:db8:1:10:0:1991:8:25... Connected to 2001:db8:1:10:0:1991:8:25. Escape character is '^]'. ^CConnection closed by foreign host. **** Now I send the forget ICMPv6 PTB **** fgont at satellite:~$ sudo icmp6 --icmp6-packet-too-big -d 2001:db8:1:10:0:1991:8:25 --peer-addr 2001:5c0:1000:a::e7d --mtu 1000 -o 80 -v icmp6: Security assessment tool for attack vectors based on ICMPv6 error messages IPv6 Source Address: 2001:5c0:1000:a::e7d (automatically selected) IPv6 Destination Address: 2001:db8:1:10:0:1991:8:25 IPv6 Hop Limit: 227 (randomized) ICMPv6 Packet Too Big (Type 2), Code 0 Next-Hop MTU: 1000 Payload Type: IPv6/TCP (default) Source Address: 2001:db8:1:10:0:1991:8:25 (automatically-selected) Destination Address: 2001:5c0:1000:a::e7d Hop Limit: 237 (randomized) Source Port: 80 Destination Port: 38189 (randomized) SEQ Number: 734463213 (randomized) ACK Number: 866605720 (randomized) Flags: A (default) Window: 18944 (randomized) URG Pointer: 0 (default) Initial attack packet(s) sent successfully. ***** And now I try the same telnet command as above... but it fails, because the frags from the server to me are getting dropped somewhere **** fgont at satellite:~$ telnet 2001:db8:1:10:0:1991:8:25 80 Trying 2001:db8:1:10:0:1991:8:25... [timeout] ---- cut here ---- Of course, in this particular case I just "shot myself". But one could do this to DoS connections between mailservers, etc. A nice question is: what if e.g.... 1) some BGP servers accept ICMPv6 PTB that claim an MTU < 1280, and react (as expected) by generating atomic fragments, *and*, 2) These same BGP servers deem fragmentation as "harmful", and hence drop such fragments you could essentially DoS traffic between them As noted in the I-D, the mitigations seem to be: 1) Artificially limit your packets to 1280, and drop all incoming ICMPv6 PTB, or, 2) Have your device just drop ICMPv6 PTB that claim a Next-Hop MTU smaller than 1280. Thoughts? -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From dougb at dougbarton.us Tue Aug 19 17:44:56 2014 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 19 Aug 2014 10:44:56 -0700 Subject: QOS improvement suggestion for NANOG list members In-Reply-To: <53F35C13.4030507@invaluement.com> References: <20140818111846.A7D4FA0C@m0048141.ppops.net> <53F2481F.5050005@mompl.net> <53F25AAC.5020802@free.fr> <53F35C13.4030507@invaluement.com> Message-ID: <53F38D18.3030700@dougbarton.us> On 8/19/14 7:15 AM, Rob McEwen wrote: > RE: QOS improvement suggestion for NANOG list members > > Go to the search feature of your e-mail, and search for all messages > from the NANOG list that has the word "URGENT" in the subject line... > then delete them! Then, there will be a LESSER chance of overlooking a > truly urgent messages from your own customers! (and hopefully that > thread will die soon! Otherwise, you may need to repeat this every > couple of days for a hopefully short while.) This might improve the > quality of service that you provide to your own clients. .... or, learn how to filter e-mail into folders like the big kids. :) From Joshua_Sholes at cable.comcast.com Tue Aug 19 18:09:50 2014 From: Joshua_Sholes at cable.comcast.com (Sholes, Joshua) Date: Tue, 19 Aug 2014 18:09:50 +0000 Subject: QOS improvement suggestion for NANOG list members In-Reply-To: <53F38D18.3030700@dougbarton.us> References: <20140818111846.A7D4FA0C@m0048141.ppops.net> <53F2481F.5050005@mompl.net> <53F25AAC.5020802@free.fr> <53F35C13.4030507@invaluement.com> <53F38D18.3030700@dougbarton.us> Message-ID: Doesn't everyone do that? NANOG was the list that taught me, twelve years ago, that I would suffer terribly if I didn't pre-sort individual mailing lists into their own folders. =) -- Josh On 8/19/14, 1:44 PM, "Doug Barton" wrote: > >.... or, learn how to filter e-mail into folders like the big kids. :) > From mikea at mikea.ath.cx Tue Aug 19 18:34:58 2014 From: mikea at mikea.ath.cx (Mike A) Date: Tue, 19 Aug 2014 13:34:58 -0500 Subject: QOS improvement suggestion for NANOG list members In-Reply-To: References: <20140818111846.A7D4FA0C@m0048141.ppops.net> <53F2481F.5050005@mompl.net> <53F25AAC.5020802@free.fr> <53F35C13.4030507@invaluement.com> <53F38D18.3030700@dougbarton.us> Message-ID: <20140819183458.GC31365@mikea.ath.cx> On Tue, Aug 19, 2014 at 06:09:50PM +0000, Sholes, Joshua wrote: > Doesn't everyone do that? > > NANOG was the list that taught me, twelve years ago, that I would suffer > terribly if I didn't pre-sort individual mailing lists into their own > folders. =) Procmail, while not all that _friendly_, can be *useful*. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From colton.conor at gmail.com Tue Aug 19 19:34:04 2014 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 19 Aug 2014 14:34:04 -0500 Subject: Huawei's Versatile Routing Platform (VRP) Message-ID: How does Huawei's Versatile Routing Platform (VRP) operating system that is on their switches and routers compare to Cisco IOS or Juniper JunOS? Is the CLI syntax similar? How is the overall feature set? Would a tech that knows cisco be able to understand Huawei fairly easy? The pricing and feature set for Huawei's products are impressive, but no one ever seems to talk about their products? They claim to have multiple routers that smoke Cisco and Juniper platforms.We are talking Tbps platforms. What are the overall thoughts on Huawei? From saku at ytti.fi Tue Aug 19 20:09:57 2014 From: saku at ytti.fi (Saku Ytti) Date: Tue, 19 Aug 2014 23:09:57 +0300 Subject: Huawei's Versatile Routing Platform (VRP) In-Reply-To: References: Message-ID: <20140819200957.GA10049@pob.ytti.fi> On (2014-08-19 14:34 -0500), Colton Conor wrote: Hi, > How does Huawei's Versatile Routing Platform (VRP) operating system that is > on their switches and routers compare to Cisco IOS or Juniper JunOS? Is the > CLI syntax similar? How is the overall feature set? Would a tech that knows > cisco be able to understand Huawei fairly easy? If they know IOS they just need to change the nouns to some synonym and it's the same. And generally, if you know what you're doing, it's perfectly workable CLI. By far nothing to write home to, but generally relying to CLI means there are large inefficiencies in your process to address. Overall the design is quite like IOS XE today, linux where single flat process 'vrp' does all the heavy-lifting. > The pricing and feature set for Huawei's products are impressive, but no > one ever seems to talk about their products? They claim to have multiple > routers that smoke Cisco and Juniper platforms.We are talking Tbps > platforms. What are the overall thoughts on Huawei? I recently opened Huawei AR router which is essentially competing with Cisco ISR and to lesser degree with Juniper SRX. To my surprise it was all wastern quality kit, emmerson PSU, marvell ethernet chip, cavium octeon NPU/CPU, so pretty similar to SRX in HW terms. CX competes with ASR9k/MX, and NE as far as I know is like CX but more core-focused marketing (like JNPR T is like MX for people with too much money) I personally wouldn't have trouble committing heavily on Huawei kit if economics otherwise make sense (training, systems, etc) -- ++ytti From tom at ninjabadger.net Tue Aug 19 21:43:05 2014 From: tom at ninjabadger.net (Tom Hill) Date: Tue, 19 Aug 2014 22:43:05 +0100 Subject: Urgent In-Reply-To: <0031d367e1b385685fedab145c2df48e@dizum.com> References: <0031d367e1b385685fedab145c2df48e@dizum.com> Message-ID: <53F3C4E9.6040004@ninjabadger.net> On 18/08/14 18:00, randy at psg.com wrote: > Contact for God, please reach out to me offlist. [18:12:24] 12:38 <@teh-35425> Beer tokens to the man that puts in a request to nanog-ml for 'Contact for God, please contact me offlist' [18:12:36] teh-35425, looks like you owe rbush some beer tokens Looks like I owe you a beer or two, Randy. :) Tom From tom at ninjabadger.net Tue Aug 19 21:46:13 2014 From: tom at ninjabadger.net (Tom Hill) Date: Tue, 19 Aug 2014 22:46:13 +0100 Subject: Urgent In-Reply-To: <53F3C4E9.6040004@ninjabadger.net> References: <0031d367e1b385685fedab145c2df48e@dizum.com> <53F3C4E9.6040004@ninjabadger.net> Message-ID: <53F3C5A5.8000002@ninjabadger.net> On 19/08/14 22:43, Tom Hill wrote: > Looks like I owe you a beer or two, Randy. :) Or, more accurately, some happy soul has nominated that you shall receiveth said beer tokens, by fortune of spoofed e-mails.. ;D Tom From nanog at jack.fr.eu.org Tue Aug 19 19:45:22 2014 From: nanog at jack.fr.eu.org (nanog at jack.fr.eu.org) Date: Tue, 19 Aug 2014 21:45:22 +0200 Subject: Huawei's Versatile Routing Platform (VRP) In-Reply-To: References: Message-ID: <53F3A952.3010400@jack.fr.eu.org> It works fine The cli syntax is quite similar to iOS in shape, but keywords are different You won't (almost) understand everything on the fly, reading to documentation in *not* an option (is it somewhere ?); By the way, Huawei's documentation is a bit ugly, not as versatile as Cisco's; You will have troubles to understand some features if you are "new" with these (eg protocols, techs etc). If you master these, I guess the docs will be more understable for you. I did not used them for routing but switching, they are really performing good If you plan to buy such product, keep in mind these points: - don't mix Huawei & cisco (or anything else), you might have trouble (as you'll get with any other constuctor mix) - low cost switches seems to be less awesome that high-end products; You may get more "not working" unit; On 19/08/2014 21:34, Colton Conor wrote: > How does Huawei's Versatile Routing Platform (VRP) operating system that is > on their switches and routers compare to Cisco IOS or Juniper JunOS? Is the > CLI syntax similar? How is the overall feature set? Would a tech that knows > cisco be able to understand Huawei fairly easy? > > The pricing and feature set for Huawei's products are impressive, but no > one ever seems to talk about their products? They claim to have multiple > routers that smoke Cisco and Juniper platforms.We are talking Tbps > platforms. What are the overall thoughts on Huawei? > From nikm at cyberflunk.com Wed Aug 20 01:53:04 2014 From: nikm at cyberflunk.com (Nikos Mouat) Date: Tue, 19 Aug 2014 18:53:04 -0700 (PDT) Subject: Huawei's Versatile Routing Platform (VRP) In-Reply-To: References: Message-ID: Hi Colton, I've been recently looking at the Huawei 12808 switch - I'm not sure if it's the same OS as the routers, but so far I've had a positive experience. I would say it's not very close at all to IOS - other than being command line - perhaps closer than Extreme's OS, but not by much. That being said, the '?' and tab keys are helpful, and if you understand the concepts, you can usually find the right knobs to turn. In addition, at least for me, the Huawei teams have been extraordinarily helpful in providing configuration templates and support. I think someone commented that it doesn't mix well with Cisco - I would throw in that that's probably only based on the fact that Huawei does not support PVST. Thanks, Nikos On Tue, 19 Aug 2014, Colton Conor wrote: > How does Huawei's Versatile Routing Platform (VRP) operating system that is > on their switches and routers compare to Cisco IOS or Juniper JunOS? Is the > CLI syntax similar? How is the overall feature set? Would a tech that knows > cisco be able to understand Huawei fairly easy? > > The pricing and feature set for Huawei's products are impressive, but no > one ever seems to talk about their products? They claim to have multiple > routers that smoke Cisco and Juniper platforms.We are talking Tbps > platforms. What are the overall thoughts on Huawei? > From shopik at inblock.ru Wed Aug 20 08:53:59 2014 From: shopik at inblock.ru (Nikolay Shopik) Date: Wed, 20 Aug 2014 12:53:59 +0400 Subject: Huawei's Versatile Routing Platform (VRP) In-Reply-To: References: Message-ID: <53F46227.6050803@inblock.ru> CLI is really similar to IOS. But be ready, their documentation suck balls big time, and some of it usually unavailable in open internet. On 19/08/14 23:34, Colton Conor wrote: > How does Huawei's Versatile Routing Platform (VRP) operating system that is > on their switches and routers compare to Cisco IOS or Juniper JunOS? Is the > CLI syntax similar? How is the overall feature set? Would a tech that knows > cisco be able to understand Huawei fairly easy? > > The pricing and feature set for Huawei's products are impressive, but no > one ever seems to talk about their products? They claim to have multiple > routers that smoke Cisco and Juniper platforms.We are talking Tbps > platforms. What are the overall thoughts on Huawei? > From ryanshea at google.com Wed Aug 20 14:55:31 2014 From: ryanshea at google.com (Ryan Shea) Date: Wed, 20 Aug 2014 10:55:31 -0400 Subject: Best US Tunnelbroker for Youtube Message-ID: Just one man's experience, but my YouTube performance over my Hurricane Electric tunnel has been strikingly poor lately - so much so that I was thinking of squashing v6 in my house entirely. Looking for your experiences/thoughts on whether cutting over to SixXS or Routinghouse could be a path to 1080p cat video bliss instead. From jeroen at massar.ch Wed Aug 20 15:05:40 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Wed, 20 Aug 2014 17:05:40 +0200 Subject: Best US Tunnelbroker for Youtube In-Reply-To: References: Message-ID: <53F4B944.5050608@massar.ch> On 2014-08-20 16:55, Ryan Shea wrote: > Just one man's experience, but my YouTube performance over my Hurricane > Electric tunnel has been strikingly poor lately Instead of saying that something is "poor", you might want to do the operational/technical[1] thing and include things like: - IPv4 traceroute from your endpoint to the PoP you are using - IPv6 traceroute over the tunnel to the destination that is "poor" And depending on things tcpdump/wireshark might be an amazing tool too. There are apparently some US ISPs who are throttling protocol-41 btw, which might actually be what your problem is. Only data will tell though. I am fairly sure that bringing problems with HE up to them directly or at least on their forums instead of a mailinglist for Network Operators[1] will get you better results... > - so much so that I was > thinking of squashing v6 in my house entirely. Looking for your > experiences/thoughts on whether cutting over to SixXS or Routinghouse could > be a path to 1080p cat video bliss instead. For SixXS it all depends on which ISP network you are located in and what PoP you select. If you are west-coast, at the moment, you will likely not get the best performance as there are no PoPs in that area and thus you would have to cut through the country. But more importantly: did you consider asking your ISP for native IPv6? Greets, Jeroen [1] https://www.nanog.org/list From streiner at cluebyfour.org Wed Aug 20 12:44:13 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 20 Aug 2014 08:44:13 -0400 (EDT) Subject: Best US Tunnelbroker for Youtube In-Reply-To: References: Message-ID: On Wed, 20 Aug 2014, Ryan Shea wrote: > Just one man's experience, but my YouTube performance over my Hurricane > Electric tunnel has been strikingly poor lately - so much so that I was > thinking of squashing v6 in my house entirely. Looking for your > experiences/thoughts on whether cutting over to SixXS or Routinghouse could > be a path to 1080p cat video bliss instead. I haven't noticed any significant performance degradation to Youtube lately over my HE tunnel. My home ISP is Verizon Fios. Are you experiencing problems _just_ to Youtube, or wider-scale problems in general? If it's the latter, perhaps there's congestion or some other problem between your ISP and HE. jms From blake at ispn.net Wed Aug 20 15:26:23 2014 From: blake at ispn.net (Blake Hudson) Date: Wed, 20 Aug 2014 10:26:23 -0500 Subject: Best US Tunnelbroker for Youtube In-Reply-To: References: Message-ID: <53F4BE1F.1010405@ispn.net> Ryan Shea wrote on 8/20/2014 9:55 AM: > Just one man's experience, but my YouTube performance over my Hurricane > Electric tunnel has been strikingly poor lately - so much so that I was > thinking of squashing v6 in my house entirely. Looking for your > experiences/thoughts on whether cutting over to SixXS or Routinghouse could > be a path to 1080p cat video bliss instead. I've found HE's support to be surprisingly responsive, even to non (paying) customers. You might reach out to them. --Blake From ryanshea at google.com Wed Aug 20 15:28:28 2014 From: ryanshea at google.com (Ryan Shea) Date: Wed, 20 Aug 2014 11:28:28 -0400 Subject: Best US Tunnelbroker for Youtube In-Reply-To: <53F4B944.5050608@massar.ch> References: <53F4B944.5050608@massar.ch> Message-ID: I was attempting to determine the lowest-time-cost path to "happy wife". My candidate paths are "kill v6", "sixxs", "routinghouse" and I was looking for anecdotes that might lead me to test one over another. Yes there are better operational approaches if I ditch the "happy wife" && low-cost (time) concerns, but it certainly seems that the problem of reliable high-quality video streams is more complex than a traceroute/tcpdump are going to indicate. Where is the wireshark button my Chromecast? What is the PoP I am using for this particular video versus another? Is this request filled from Google Global Cache or not? I am choosing not to tilt at these particular windmills. There are not Amazon reviews for tunnel brokers, so yes, I come to an operator mailing list. On Wed, Aug 20, 2014 at 11:05 AM, Jeroen Massar wrote: > On 2014-08-20 16:55, Ryan Shea wrote: > > Just one man's experience, but my YouTube performance over my Hurricane > > Electric tunnel has been strikingly poor lately > > Instead of saying that something is "poor", you might want to do the > operational/technical[1] thing and include things like: > - IPv4 traceroute from your endpoint to the PoP you are using > - IPv6 traceroute over the tunnel to the destination that is "poor" > > And depending on things tcpdump/wireshark might be an amazing tool too. > > There are apparently some US ISPs who are throttling protocol-41 btw, > which might actually be what your problem is. > > Only data will tell though. > > I am fairly sure that bringing problems with HE up to them directly or > at least on their forums instead of a mailinglist for Network > Operators[1] will get you better results... > > > - so much so that I was > > thinking of squashing v6 in my house entirely. Looking for your > > experiences/thoughts on whether cutting over to SixXS or Routinghouse > could > > be a path to 1080p cat video bliss instead. > > For SixXS it all depends on which ISP network you are located in and > what PoP you select. If you are west-coast, at the moment, you will > likely not get the best performance as there are no PoPs in that area > and thus you would have to cut through the country. > > > But more importantly: did you consider asking your ISP for native IPv6? > > Greets, > Jeroen > > > [1] https://www.nanog.org/list > > From jeroen at massar.ch Wed Aug 20 15:43:09 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Wed, 20 Aug 2014 17:43:09 +0200 Subject: Best US Tunnelbroker for Youtube In-Reply-To: References: <53F4B944.5050608@massar.ch> Message-ID: <53F4C20D.2010103@massar.ch> On 2014-08-20 17:28, Ryan Shea wrote: > I was attempting to determine the lowest-time-cost path to "happy wife". Does your wife care it is IPv4 or IPv6 or just "funny cat videos"? I think your answer should be clear from that perspective. As somebody eager to post on NANOG though one would think it prudent and a good challenge to figure out what the problem is and actually resolve that problem. You might learn something from it. > My candidate paths are "kill v6", "sixxs", "routinghouse" and I was > looking for anecdotes that might lead me to test one over another. There are these things called search engines, you might know about them. Depending on the exact query though, you might or might not get an appropriate answer. Remember that the US is a rather large country with a very big network, and a very big variance in ISPs hence the answers found will not always match what you will be looking for, especially when you are unable to provide details of your problem. > Yes there are better operational approaches if I ditch the "happy wife" > && low-cost (time) concerns, but it certainly seems that the problem of > reliable high-quality video streams is more complex than a > traceroute/tcpdump are going to indicate. As the first big leg goes over IPv4, traceroutes and such information can be extremely useful as it might just expose a choke point. That choke point IS something that people on NANOG maybe could do something about. Though the direct thing is to contact your ISP. As you have a tunnel, that means both the IPv4 and IPv6 provider. As an enduser you could also check the various speedtest sites etc. I'll provide you also with the SixXS answer as per google(tunnel is slow): https://www.sixxs.net/faq/connectivity/?faq=slow That lists a variety of other things to look at. Definitely meant for end-users though, not operators. You can also ask around on Freenode's IPv6 channel http://webchat.freenode.net/?channels=ipv6&uio=d4 Lots of knowledgeable people there who can help you debug the issue. > Where is the wireshark button my Chromecast? Does your Chromecast terminate the tunnel? As you seem to have a @google.com address, you might want to ask internally about that feature. > What is the PoP I am using for this particular video > versus another? > Is this request filled from Google Global Cache or not? > I am choosing not to tilt at these particular windmills. It seems you pick the other meaning of PoP. The meaning I referred to was the Tunnel Broker's PoP, see also: https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers And yes, indeed, if you have network issues on the IPv4 leg between your host and the PoP (eg the IPv4 ISP doing ratelimiting of protocol-41) then that will also affect your IPv6 traffic. It is surprising that you have to ask on NANOG about the other kind of PoP (the google kind), as well, you could ask your colleagues about that who will be much more able to answer those kind of questions. > There are not Amazon reviews for tunnel brokers, so yes, I come to an > operator mailing list. Amazon does not sell those things. Also, depending on the setup chosen, you'll find a wide variety of (Tunnel Broker) PoPs and thus they all affect what one might actually be reviewing, hence, better to ask directly at the provider in question. Greets, Jeroen From wbailey at satelliteintelligencegroup.com Wed Aug 20 15:56:02 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 20 Aug 2014 15:56:02 +0000 Subject: Best US Tunnelbroker for Youtube In-Reply-To: <53F4C20D.2010103@massar.ch> References: <53F4B944.5050608@massar.ch> , <53F4C20D.2010103@massar.ch> Message-ID: For the record, I would leave my wife if I found her watching funny cat videos. V6 would increase the settlement amount, but she would be history. Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Jeroen Massar Date: 08/20/2014 8:45 AM (GMT-08:00) To: Ryan Shea Cc: nanog list Subject: Re: Best US Tunnelbroker for Youtube On 2014-08-20 17:28, Ryan Shea wrote: > I was attempting to determine the lowest-time-cost path to "happy wife". Does your wife care it is IPv4 or IPv6 or just "funny cat videos"? I think your answer should be clear from that perspective. As somebody eager to post on NANOG though one would think it prudent and a good challenge to figure out what the problem is and actually resolve that problem. You might learn something from it. > My candidate paths are "kill v6", "sixxs", "routinghouse" and I was > looking for anecdotes that might lead me to test one over another. There are these things called search engines, you might know about them. Depending on the exact query though, you might or might not get an appropriate answer. Remember that the US is a rather large country with a very big network, and a very big variance in ISPs hence the answers found will not always match what you will be looking for, especially when you are unable to provide details of your problem. > Yes there are better operational approaches if I ditch the "happy wife" > && low-cost (time) concerns, but it certainly seems that the problem of > reliable high-quality video streams is more complex than a > traceroute/tcpdump are going to indicate. As the first big leg goes over IPv4, traceroutes and such information can be extremely useful as it might just expose a choke point. That choke point IS something that people on NANOG maybe could do something about. Though the direct thing is to contact your ISP. As you have a tunnel, that means both the IPv4 and IPv6 provider. As an enduser you could also check the various speedtest sites etc. I'll provide you also with the SixXS answer as per google(tunnel is slow): https://www.sixxs.net/faq/connectivity/?faq=slow That lists a variety of other things to look at. Definitely meant for end-users though, not operators. You can also ask around on Freenode's IPv6 channel http://webchat.freenode.net/?channels=ipv6&uio=d4 Lots of knowledgeable people there who can help you debug the issue. > Where is the wireshark button my Chromecast? Does your Chromecast terminate the tunnel? As you seem to have a @google.com address, you might want to ask internally about that feature. > What is the PoP I am using for this particular video > versus another? > Is this request filled from Google Global Cache or not? > I am choosing not to tilt at these particular windmills. It seems you pick the other meaning of PoP. The meaning I referred to was the Tunnel Broker's PoP, see also: https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers And yes, indeed, if you have network issues on the IPv4 leg between your host and the PoP (eg the IPv4 ISP doing ratelimiting of protocol-41) then that will also affect your IPv6 traffic. It is surprising that you have to ask on NANOG about the other kind of PoP (the google kind), as well, you could ask your colleagues about that who will be much more able to answer those kind of questions. > There are not Amazon reviews for tunnel brokers, so yes, I come to an > operator mailing list. Amazon does not sell those things. Also, depending on the setup chosen, you'll find a wide variety of (Tunnel Broker) PoPs and thus they all affect what one might actually be reviewing, hence, better to ask directly at the provider in question. Greets, Jeroen From ryanshea at google.com Wed Aug 20 16:21:18 2014 From: ryanshea at google.com (Ryan Shea) Date: Wed, 20 Aug 2014 12:21:18 -0400 Subject: Best US Tunnelbroker for Youtube In-Reply-To: <53F4C20D.2010103@massar.ch> References: <53F4B944.5050608@massar.ch> <53F4C20D.2010103@massar.ch> Message-ID: IRC is a good suggestion, thanks. They'll likely be helpful. I see no indication of any throttling from my ISP - I can blast data at full speed to my home from my server and work (with native v6 connections). Contacting my ISP (Verizon FiOS) is virtually never a reasonable path to a solution. I just tried poking at iPerf, but my client and server are wildly different versions and it seems to be lying to me about my speed (14748046472308289536 Bytes/sec) To be clear, I was seeking opinions/experiences on a list that was likely to have a high occurrence of folk with v6 tunnels. You have etiquette suggestions, but not YouTube over tunnelbroker suggestions. I apparently bring out your inner grump? Do you need a hug? Burning Google engineering time would be a sub-optimal way to get HD cat videos at home with the least time spent. On Wed, Aug 20, 2014 at 11:43 AM, Jeroen Massar wrote: > On 2014-08-20 17:28, Ryan Shea wrote: > > I was attempting to determine the lowest-time-cost path to "happy wife". > > Does your wife care it is IPv4 or IPv6 or just "funny cat videos"? > > I think your answer should be clear from that perspective. > > As somebody eager to post on NANOG though one would think it prudent and > a good challenge to figure out what the problem is and actually resolve > that problem. You might learn something from it. > > > > My candidate paths are "kill v6", "sixxs", "routinghouse" and I was > > looking for anecdotes that might lead me to test one over another. > > There are these things called search engines, you might know about them. > > Depending on the exact query though, you might or might not get an > appropriate answer. > > Remember that the US is a rather large country with a very big network, > and a very big variance in ISPs hence the answers found will not always > match what you will be looking for, especially when you are unable to > provide details of your problem. > > > Yes there are better operational approaches if I ditch the "happy wife" > > && low-cost (time) concerns, but it certainly seems that the problem of > > reliable high-quality video streams is more complex than a > > traceroute/tcpdump are going to indicate. > > As the first big leg goes over IPv4, traceroutes and such information > can be extremely useful as it might just expose a choke point. > > That choke point IS something that people on NANOG maybe could do > something about. Though the direct thing is to contact your ISP. As you > have a tunnel, that means both the IPv4 and IPv6 provider. > > As an enduser you could also check the various speedtest sites etc. > > I'll provide you also with the SixXS answer as per google(tunnel is > slow): https://www.sixxs.net/faq/connectivity/?faq=slow > > That lists a variety of other things to look at. Definitely meant for > end-users though, not operators. > > You can also ask around on Freenode's IPv6 channel > http://webchat.freenode.net/?channels=ipv6&uio=d4 > > Lots of knowledgeable people there who can help you debug the issue. > > > Where is the wireshark button my Chromecast? > > Does your Chromecast terminate the tunnel? > > As you seem to have a @google.com address, you might want to ask > internally about that feature. > > > What is the PoP I am using for this particular video > > versus another? > > Is this request filled from Google Global Cache or not? > > I am choosing not to tilt at these particular windmills. > > It seems you pick the other meaning of PoP. > > The meaning I referred to was the Tunnel Broker's PoP, see also: > https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers > > And yes, indeed, if you have network issues on the IPv4 leg between your > host and the PoP (eg the IPv4 ISP doing ratelimiting of protocol-41) > then that will also affect your IPv6 traffic. > > > It is surprising that you have to ask on NANOG about the other kind of > PoP (the google kind), as well, you could ask your colleagues about that > who will be much more able to answer those kind of questions. > > > > There are not Amazon reviews for tunnel brokers, so yes, I come to an > > operator mailing list. > > Amazon does not sell those things. > > Also, depending on the setup chosen, you'll find a wide variety of > (Tunnel Broker) PoPs and thus they all affect what one might actually be > reviewing, hence, better to ask directly at the provider in question. > > Greets, > Jeroen > > From dougb at dougbarton.us Wed Aug 20 16:42:43 2014 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 20 Aug 2014 09:42:43 -0700 Subject: Best US Tunnelbroker for Youtube In-Reply-To: References: <53F4B944.5050608@massar.ch> <53F4C20D.2010103@massar.ch> Message-ID: <53F4D003.4080604@dougbarton.us> On 8/20/14 9:21 AM, Ryan Shea wrote: > To be clear, I was seeking opinions/experiences on a list that was likely > to have a high occurrence of folk with v6 tunnels. ... and the suggestion you've received several times now is, "reach out to HE, as they are quite responsive." Good luck, Doug From jeroen at massar.ch Wed Aug 20 16:42:18 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Wed, 20 Aug 2014 18:42:18 +0200 Subject: Best US Tunnelbroker for Youtube In-Reply-To: References: <53F4B944.5050608@massar.ch> <53F4C20D.2010103@massar.ch> Message-ID: <53F4CFEA.40603@massar.ch> On 2014-08-20 18:21, Ryan Shea wrote: > IRC is a good suggestion, thanks. They'll likely be helpful. > > I see no indication of any throttling from my ISP - I can blast data at > full speed to my home from my server and work (with native v6 > connections). Does that path between your $home and $server go over the tunnel you find so "slow"? If so, then you have just nicely excluded that the tunnel is NOT the problem. Hence, why traceroutes would be so extremely useful. > Contacting my ISP (Verizon FiOS) is virtually never a > reasonable path to a solution. google(Verizon FiOS throttle) = 71.900 results. One would almost think that there might sometimes be issues there. Also, do realize that the IPv6 path you are using goes over a shared host (the Tunnel Broker PoP) that has IPv4 and IPv6 capacity that might be shared in various points of the paths your packets cross. Did you test at the same time of your "blast data" that the IPv6 Youtube was working fine? Another thing, as browsers now do "Happy Eyeballs" (which is really horrible to diagnose issues with on OSX), did you check if everything is really going over IPv6? (hence the tcpdump/wireshark). [..] > To be clear, I was seeking opinions/experiences on a list that was > likely to have a high occurrence of folk with v6 tunnels. Tunnels are for endusers who still are at ISPs who don't do IPv6 natively. NANOG has operators who have been running native IPv6 for over a decade. Hence, StackExchange might be useful for your purpose. > You have > etiquette suggestions, but not YouTube over tunnelbroker suggestions. I > apparently bring out your inner grump? Do you need a hug? My cat videos are streaming perfectly fine... > Burning Google engineering time would be a sub-optimal way to get HD cat > videos at home with the least time spent. Interesting, I was not aware they did not care about their eyeballs. Actually I am very confident lots of folks there would love to dig into your issue to actually resolve it. As when it is hitting you, it might hit other customers. Is that also not why there is this huge SRE department with lots of IPv6 knowledgeable folks? Greets, Jeroen From ryanshea at google.com Wed Aug 20 17:26:37 2014 From: ryanshea at google.com (Ryan Shea) Date: Wed, 20 Aug 2014 13:26:37 -0400 Subject: Best US Tunnelbroker for Youtube In-Reply-To: <53F4CFEA.40603@massar.ch> References: <53F4B944.5050608@massar.ch> <53F4C20D.2010103@massar.ch> <53F4CFEA.40603@massar.ch> Message-ID: Not sure I've seen any evidence (or implied) that the tunnel was the problem. My issue as far as I know is at the application layer and other end-user experiences seemed a reasonable way to pick a direction. I will work with HE though and provide them some details. Agreed, from an end-user perspective it can be often be clear as mud whether I am using v6, or whether my Chromecast or Android device even implements happy eyeballs. The relatively new "experiencing problems?" butter bar that shows up beneath a video with notable buffering problems (even at low quality levels) sends the user through to details about the service provider, in this case HE. Over the past couple years YouTube has been my canary to know when I've received a new IP from Verizon and I need to go fix my tunnel -- video loading takes fuuuuuuuurever on Android/Chromecast/GoogleTV (which hints that happy eyeballs, if it exists for Android, isn't working so well for the YouTube app). I can't get native v6 at my home -- I'm probably not in a particularly unique situation. Not to rathole the dicsussion, but as far as I know (save for some small DSL providers) unless I'm in a gFiber city or happen to be in the portion of the Comcast network that provides native v6 I'm out of luck. I don't plan on moving to solve this problem. On Wed, Aug 20, 2014 at 12:42 PM, Jeroen Massar wrote: > On 2014-08-20 18:21, Ryan Shea wrote: > > IRC is a good suggestion, thanks. They'll likely be helpful. > > > > I see no indication of any throttling from my ISP - I can blast data at > > full speed to my home from my server and work (with native v6 > > connections). > > Does that path between your $home and $server go over the tunnel you > find so "slow"? > > If so, then you have just nicely excluded that the tunnel is NOT the > problem. > > Hence, why traceroutes would be so extremely useful. > > > > Contacting my ISP (Verizon FiOS) is virtually never a > > reasonable path to a solution. > > google(Verizon FiOS throttle) = 71.900 results. One would almost think > that there might sometimes be issues there. > > Also, do realize that the IPv6 path you are using goes over a shared > host (the Tunnel Broker PoP) that has IPv4 and IPv6 capacity that might > be shared in various points of the paths your packets cross. > > Did you test at the same time of your "blast data" that the IPv6 Youtube > was working fine? > > Another thing, as browsers now do "Happy Eyeballs" (which is really > horrible to diagnose issues with on OSX), did you check if everything is > really going over IPv6? (hence the tcpdump/wireshark). > > [..] > > To be clear, I was seeking opinions/experiences on a list that was > > likely to have a high occurrence of folk with v6 tunnels. > > Tunnels are for endusers who still are at ISPs who don't do IPv6 natively. > > NANOG has operators who have been running native IPv6 for over a decade. > > Hence, StackExchange might be useful for your purpose. > > > You have > > etiquette suggestions, but not YouTube over tunnelbroker suggestions. I > > apparently bring out your inner grump? Do you need a hug? > > My cat videos are streaming perfectly fine... > > > Burning Google engineering time would be a sub-optimal way to get HD cat > > videos at home with the least time spent. > > Interesting, I was not aware they did not care about their eyeballs. > > Actually I am very confident lots of folks there would love to dig into > your issue to actually resolve it. As when it is hitting you, it might > hit other customers. > > Is that also not why there is this huge SRE department with lots of IPv6 > knowledgeable folks? > > Greets, > Jeroen > > From dr at cluenet.de Wed Aug 20 17:36:42 2014 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 20 Aug 2014 19:36:42 +0200 Subject: Best US Tunnelbroker for Youtube In-Reply-To: References: <53F4B944.5050608@massar.ch> <53F4C20D.2010103@massar.ch> <53F4CFEA.40603@massar.ch> Message-ID: <20140820173642.GA17433@srv03.cluenet.de> On Wed, Aug 20, 2014 at 01:26:37PM -0400, Ryan Shea wrote: > video loading takes fuuuuuuuurever on Android/Chromecast/GoogleTV > (which hints that happy eyeballs, if it exists for Android, isn't > working so well for the YouTube app). Happy Eyeballs is only about TCP session setup race, not how the established session performs. Normally with bias (headstart) for IPv6, sometimes (Apple) egoistic and reckless without. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From ryanshea at google.com Wed Aug 20 18:01:41 2014 From: ryanshea at google.com (Ryan Shea) Date: Wed, 20 Aug 2014 14:01:41 -0400 Subject: Best US Tunnelbroker for Youtube In-Reply-To: <20140820173642.GA17433@srv03.cluenet.de> References: <53F4B944.5050608@massar.ch> <53F4C20D.2010103@massar.ch> <53F4CFEA.40603@massar.ch> <20140820173642.GA17433@srv03.cluenet.de> Message-ID: Sorry, I wasn't clear. When my tunnel is not functioning correctly my end hosts still have global v6 addresses and a route. The v6 tcp connections would fail entirely, so v4 would handily win a tcp setup race. A v4-only client does not experience huge delays in video loading. I'm not sure happy eyeballs is implemented in Android. On Wed, Aug 20, 2014 at 1:36 PM, Daniel Roesen wrote: > On Wed, Aug 20, 2014 at 01:26:37PM -0400, Ryan Shea wrote: > > video loading takes fuuuuuuuurever on Android/Chromecast/GoogleTV > > (which hints that happy eyeballs, if it exists for Android, isn't > > working so well for the YouTube app). > > Happy Eyeballs is only about TCP session setup race, not how the > established session performs. Normally with bias (headstart) for IPv6, > sometimes (Apple) egoistic and reckless without. > > Best regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 > From morrowc.lists at gmail.com Wed Aug 20 20:59:00 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 20 Aug 2014 16:59:00 -0400 Subject: Best US Tunnelbroker for Youtube In-Reply-To: References: <53F4B944.5050608@massar.ch> <53F4C20D.2010103@massar.ch> <53F4CFEA.40603@massar.ch> Message-ID: On Wed, Aug 20, 2014 at 1:26 PM, Ryan Shea wrote: > Not sure I've seen any evidence (or implied) that the tunnel was the > problem. My issue as far as I know is at the application layer and other > end-user experiences seemed a reasonable way to pick a direction. I will > work with HE though and provide them some details. > i have this: yt_ that I should add to a code.google.com location... and will ship you a copy tomorrow of as well. Running this on my home fios + he-tunnel bits now to see what result come out. I'd report that the YT homepage seems to be 'super slow' loading and that when I stream: (was on the YT homepage as a featured video.. though I am a sucker for the song....) I seem to stream from: 2607:f8b0:400d:c06::81 qh-in-x81.1e100.net. that's not TOO far off my homebase, so... it seems reasonable for a geolocation choice. > Agreed, from an end-user perspective it can be often be clear as mud > whether I am using v6, or whether my Chromecast or Android device even > implements happy eyeballs. The relatively new "experiencing problems?" > butter bar that shows up beneath a video with notable buffering problems > (even at low quality levels) sends the user through to details about the > service provider, in this case HE. Over the past couple years YouTube has > been my canary to know when I've received a new IP from Verizon and I need > to go fix my tunnel -- video loading takes fuuuuuuuurever on > Android/Chromecast/GoogleTV (which hints that happy eyeballs, if it exists > for Android, isn't working so well for the YouTube app). > > I can't get native v6 at my home -- I'm probably not in a particularly > unique situation. Not to rathole the dicsussion, but as far as I know (save > for some small DSL providers) unless I'm in a gFiber city or happen to be > in the portion of the Comcast network that provides native v6 I'm out of > luck. I don't plan on moving to solve this problem. > i think jjb's report was that 'all' of comcast (consumer at least) is v6 capable... as a point of reference. I expect the heat-death of the universe before fiosv6 happens though. (back on that 'simply embarassing' commentary from 8+ months ago, of course) -chris > > > On Wed, Aug 20, 2014 at 12:42 PM, Jeroen Massar wrote: > >> On 2014-08-20 18:21, Ryan Shea wrote: >> > IRC is a good suggestion, thanks. They'll likely be helpful. >> > >> > I see no indication of any throttling from my ISP - I can blast data at >> > full speed to my home from my server and work (with native v6 >> > connections). >> >> Does that path between your $home and $server go over the tunnel you >> find so "slow"? >> >> If so, then you have just nicely excluded that the tunnel is NOT the >> problem. >> >> Hence, why traceroutes would be so extremely useful. >> >> >> > Contacting my ISP (Verizon FiOS) is virtually never a >> > reasonable path to a solution. >> >> google(Verizon FiOS throttle) = 71.900 results. One would almost think >> that there might sometimes be issues there. >> >> Also, do realize that the IPv6 path you are using goes over a shared >> host (the Tunnel Broker PoP) that has IPv4 and IPv6 capacity that might >> be shared in various points of the paths your packets cross. >> >> Did you test at the same time of your "blast data" that the IPv6 Youtube >> was working fine? >> >> Another thing, as browsers now do "Happy Eyeballs" (which is really >> horrible to diagnose issues with on OSX), did you check if everything is >> really going over IPv6? (hence the tcpdump/wireshark). >> >> [..] >> > To be clear, I was seeking opinions/experiences on a list that was >> > likely to have a high occurrence of folk with v6 tunnels. >> >> Tunnels are for endusers who still are at ISPs who don't do IPv6 natively. >> >> NANOG has operators who have been running native IPv6 for over a decade. >> >> Hence, StackExchange might be useful for your purpose. >> >> > You have >> > etiquette suggestions, but not YouTube over tunnelbroker suggestions. I >> > apparently bring out your inner grump? Do you need a hug? >> >> My cat videos are streaming perfectly fine... >> >> > Burning Google engineering time would be a sub-optimal way to get HD cat >> > videos at home with the least time spent. >> >> Interesting, I was not aware they did not care about their eyeballs. >> >> Actually I am very confident lots of folks there would love to dig into >> your issue to actually resolve it. As when it is hitting you, it might >> hit other customers. >> >> Is that also not why there is this huge SRE department with lots of IPv6 >> knowledgeable folks? >> >> Greets, >> Jeroen >> >> From morrowc.lists at gmail.com Wed Aug 20 21:03:54 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 20 Aug 2014 17:03:54 -0400 Subject: Best US Tunnelbroker for Youtube In-Reply-To: References: <53F4B944.5050608@massar.ch> <53F4C20D.2010103@massar.ch> <53F4CFEA.40603@massar.ch> Message-ID: On Wed, Aug 20, 2014 at 4:59 PM, Christopher Morrow wrote: > i have this: yt_ funny... part of the filename disappeared here :( ./yt_troubleshooting.py > > that I should add to a code.google.com location... and will ship you a > copy tomorrow of as well. Running this on my home fios + he-tunnel > bits now to see what result come out. > > I'd report that the YT homepage seems to be 'super slow' loading and > that when I stream: > (was on the YT homepage > as a featured video.. though I am a sucker for the song....) > > I seem to stream from: 2607:f8b0:400d:c06::81 > qh-in-x81.1e100.net. > apologies, if I change the 720p I start streaming from: 2607:f8b0:4004:1b::6 which is much closer to verizon-land, so my packets go: me -> verizon -> he -> google -> he -> verizon -> me I'm betting that in one direction or the other the he/verizon links are no-bueno :( From Fred.L.Templin at boeing.com Wed Aug 20 22:45:46 2014 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Wed, 20 Aug 2014 22:45:46 +0000 Subject: DHCPv6 authentication In-Reply-To: References: <53F4B944.5050608@massar.ch> <53F4C20D.2010103@massar.ch> <53F4CFEA.40603@massar.ch> Message-ID: <2134F8430051B64F815C691A62D9831832CF6288@XCH-BLV-504.nw.nos.boeing.com> Hi - does anyone know if DHCPv6 authentication is commonly used in operational networks? If so, what has been the experience in terms of DHCPv6 servers being able to discern legitimate clients from rogue clients? Thanks - Fred fred.l.templin at boeing.com From ryanshea at google.com Wed Aug 20 23:41:06 2014 From: ryanshea at google.com (Ryan Shea) Date: Wed, 20 Aug 2014 19:41:06 -0400 Subject: Best US Tunnelbroker for Youtube In-Reply-To: References: <53F4B944.5050608@massar.ch> <53F4C20D.2010103@massar.ch> <53F4CFEA.40603@massar.ch> Message-ID: FWIW, loading up a lovely 1080p video now at a time when I am guessing the HE/VZ links are running a little more hot than not and I'm getting perfect playback and nload is showing that I hit a max of 67.9Mb/s on my tunnel. I have not tested with _all_ full hd cat videos, but that sounds like a good challenge for tonight. On Wed, Aug 20, 2014 at 5:03 PM, Christopher Morrow wrote: > On Wed, Aug 20, 2014 at 4:59 PM, Christopher Morrow > wrote: > > i have this: yt_ > > funny... part of the filename disappeared here :( > ./yt_troubleshooting.py > > > > > that I should add to a code.google.com location... and will ship you a > > copy tomorrow of as well. Running this on my home fios + he-tunnel > > bits now to see what result come out. > > > > I'd report that the YT homepage seems to be 'super slow' loading and > > that when I stream: > > (was on the YT homepage > > as a featured video.. though I am a sucker for the song....) > > > > I seem to stream from: 2607:f8b0:400d:c06::81 > > qh-in-x81.1e100.net. > > > > apologies, if I change the 720p I start streaming from: > 2607:f8b0:4004:1b::6 > > which is much closer to verizon-land, so my packets go: > me -> verizon -> he -> google -> he -> verizon -> me > > I'm betting that in one direction or the other the he/verizon links > are no-bueno :( > From jared at puck.nether.net Thu Aug 21 00:14:04 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 20 Aug 2014 20:14:04 -0400 Subject: DHCPv6 authentication In-Reply-To: <2134F8430051B64F815C691A62D9831832CF6288@XCH-BLV-504.nw.nos.boeing.com> References: <53F4B944.5050608@massar.ch> <53F4C20D.2010103@massar.ch> <53F4CFEA.40603@massar.ch> <2134F8430051B64F815C691A62D9831832CF6288@XCH-BLV-504.nw.nos.boeing.com> Message-ID: <2F4EA67A-A730-40E6-99DA-6A1FA5C3AFD8@puck.nether.net> If you are already connected to the network you are going to be deemed as authenticated. I'm unaware of anyone doing dhcp authentication. Jared Mauch > On Aug 20, 2014, at 6:45 PM, "Templin, Fred L" wrote: > > Hi - does anyone know if DHCPv6 authentication is commonly used in > operational networks? If so, what has been the experience in terms > of DHCPv6 servers being able to discern legitimate clients from > rogue clients? > > Thanks - Fred > fred.l.templin at boeing.com From rob at invaluement.com Wed Aug 20 00:43:28 2014 From: rob at invaluement.com (Rob McEwen) Date: Tue, 19 Aug 2014 20:43:28 -0400 Subject: QOS improvement suggestion for NANOG list members In-Reply-To: <53F38D18.3030700@dougbarton.us> References: <20140818111846.A7D4FA0C@m0048141.ppops.net> <53F2481F.5050005@mompl.net> <53F25AAC.5020802@free.fr> <53F35C13.4030507@invaluement.com> <53F38D18.3030700@dougbarton.us> Message-ID: <53F3EF30.1090100@invaluement.com> On 8/19/2014 1:44 PM, Doug Barton wrote: > > .... or, learn how to filter e-mail into folders like the big kids. :) At first glance, that sounds wise... but there is a problem with that strategy... doing that can EASILY cause a person to miss (or read too late!) critical "zero hour" issues that come up on occasion... btw - Even thought the following analogy is far from perfect, this sort of reminds me of a poor quality spam filtering system where the end users spend so much time looking for FPs in the "spam folder"...that the spam might as well have been delivered to the inbox! In the meantime, I'm very good at quickly ignoring the messages that aren't relevant to my business nor time-sensitive... based on the subject line... especially since it is easy to ignore entire threads based on their subject line... and NANOG's volume isn't huge... but then the word "URGENT" in all caps gets a little annoying. -- Rob McEwen +1 (478) 475-9032 From randy at psg.com Wed Aug 20 01:29:23 2014 From: randy at psg.com (Randy Bush) Date: Wed, 20 Aug 2014 08:29:23 +0700 Subject: QOS improvement suggestion for NANOG list members In-Reply-To: <20140819183458.GC31365@mikea.ath.cx> References: <20140818111846.A7D4FA0C@m0048141.ppops.net> <53F2481F.5050005@mompl.net> <53F25AAC.5020802@free.fr> <53F35C13.4030507@invaluement.com> <53F38D18.3030700@dougbarton.us> <20140819183458.GC31365@mikea.ath.cx> Message-ID: > Procmail, while not all that _friendly_, can be *useful*. for sure. i he not even seen the pathetic perjorative ad homina which my friends here have reported. all i can do is repeat what my father used to tell me, jealousy will get you nowhere. randy From chris.young at intermetro.net Thu Aug 21 01:46:54 2014 From: chris.young at intermetro.net (Chris Young) Date: Wed, 20 Aug 2014 20:46:54 -0500 Subject: Equipment in Denver, CO. Message-ID: Fellow Nanog Members - Looking for a 19" Rackmound kit, part TMLPMOUNT41. Avnet.com is sold out. Looking for this item in the Dever, CO area. Also what are some other places similar to Graybar in the Denver, Colorado area? Regards, Christopher Young Network Operations InterMetro Communications, Inc. 866-446-2662 NOC 805-433-8000 Main 805-433-0050 Direct 805-433-2589 Mobile From rcarpen at network1.net Thu Aug 21 01:55:35 2014 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 20 Aug 2014 21:55:35 -0400 (EDT) Subject: DHCPv6 authentication In-Reply-To: <2F4EA67A-A730-40E6-99DA-6A1FA5C3AFD8@puck.nether.net> References: <53F4CFEA.40603@massar.ch> <2134F8430051B64F815C691A62D9831832CF6288@XCH-BLV-504.nw.nos.boeing.com> <2F4EA67A-A730-40E6-99DA-6A1FA5C3AFD8@puck.nether.net> Message-ID: <1226973035.363369.1408586135877.JavaMail.zimbra@network1.net> My clients typically do DHCP authentication in order to have the ability to tell which user has which IP at what time. The challenge with doing this with IPv6 is that the original DHCPv6 spec has no provision for there to be any unique identifier that can be tied to a particular user like DHCPv4 does. RFC 6939 defines a way to fix that, but I have yet to see it implemented by anything. thanks, -Randy ----- Original Message ----- > If you are already connected to the network you are going to be deemed as > authenticated. I'm unaware of anyone doing dhcp authentication. > > Jared Mauch > > > On Aug 20, 2014, at 6:45 PM, "Templin, Fred L" > > wrote: > > > > Hi - does anyone know if DHCPv6 authentication is commonly used in > > operational networks? If so, what has been the experience in terms > > of DHCPv6 servers being able to discern legitimate clients from > > rogue clients? > > > > Thanks - Fred > > fred.l.templin at boeing.com > > From Fred.L.Templin at boeing.com Thu Aug 21 03:46:18 2014 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Thu, 21 Aug 2014 03:46:18 +0000 Subject: DHCPv6 authentication In-Reply-To: <2F4EA67A-A730-40E6-99DA-6A1FA5C3AFD8@puck.nether.net> References: <53F4B944.5050608@massar.ch> <53F4C20D.2010103@massar.ch> <53F4CFEA.40603@massar.ch> <2134F8430051B64F815C691A62D9831832CF6288@XCH-BLV-504.nw.nos.boeing.com> <2F4EA67A-A730-40E6-99DA-6A1FA5C3AFD8@puck.nether.net> Message-ID: <2134F8430051B64F815C691A62D9831832CF6476@XCH-BLV-504.nw.nos.boeing.com> Hi Jared, I am assuming 802.1x (or equivalent) security at L2, but the "link" between my DHCPv6 client and server is actually a tunnel that may travel over many network layer hops. So, it is possible for legitimate client A to have its leases canceled by rogue client B unless DHCPv6 auth or something similar is used. Yes, rogue client B would also have to be authenticated to connect to the network the same as legitimate client A, but it could be an "insider attack" (e.g., where B is a disgruntled employee trying to get back at a corporate adversary A). Thanks - Fred fred.l.templin at boeing.com > -----Original Message----- > From: Jared Mauch [mailto:jared at puck.nether.net] > Sent: Wednesday, August 20, 2014 5:14 PM > To: Templin, Fred L > Cc: nanog list > Subject: Re: DHCPv6 authentication > > If you are already connected to the network you are going to be deemed as authenticated. I'm unaware > of anyone doing dhcp authentication. > > Jared Mauch > > > On Aug 20, 2014, at 6:45 PM, "Templin, Fred L" wrote: > > > > Hi - does anyone know if DHCPv6 authentication is commonly used in > > operational networks? If so, what has been the experience in terms > > of DHCPv6 servers being able to discern legitimate clients from > > rogue clients? > > > > Thanks - Fred > > fred.l.templin at boeing.com From alex at howells.me Thu Aug 21 03:54:15 2014 From: alex at howells.me (Alex Howells) Date: Thu, 21 Aug 2014 04:54:15 +0100 Subject: DHCPv6 authentication In-Reply-To: <2134F8430051B64F815C691A62D9831832CF6476@XCH-BLV-504.nw.nos.boeing.com> References: <53F4B944.5050608@massar.ch> <53F4C20D.2010103@massar.ch> <53F4CFEA.40603@massar.ch> <2134F8430051B64F815C691A62D9831832CF6288@XCH-BLV-504.nw.nos.boeing.com> <2F4EA67A-A730-40E6-99DA-6A1FA5C3AFD8@puck.nether.net> <2134F8430051B64F815C691A62D9831832CF6476@XCH-BLV-504.nw.nos.boeing.com> Message-ID: This seems like an attempt to boil the ocean. From jared at puck.Nether.net Thu Aug 21 11:47:51 2014 From: jared at puck.Nether.net (Jared Mauch) Date: Thu, 21 Aug 2014 07:47:51 -0400 Subject: DHCPv6 authentication In-Reply-To: <2134F8430051B64F815C691A62D9831832CF6476@XCH-BLV-504.nw.nos.boeing.com> References: <53F4C20D.2010103@massar.ch> <53F4CFEA.40603@massar.ch> <2134F8430051B64F815C691A62D9831832CF6288@XCH-BLV-504.nw.nos.boeing.com> <2F4EA67A-A730-40E6-99DA-6A1FA5C3AFD8@puck.nether.net> <2134F8430051B64F815C691A62D9831832CF6476@XCH-BLV-504.nw.nos.boeing.com> Message-ID: <20140821114751.GF2700@puck.nether.net> I similarly was counting on 802.1x + RA-Guard and other techniques. I can easier do an insider attack by gaining console or connecting to a trusted wire as most places I've seen don't do 802.1x on wired but do on wireless. I'm not going to enumerate the universe for the sake of 6man/dhc or v6ops, and this seems like a futile effort. - Jared (who sometimes runs a network) On Thu, Aug 21, 2014 at 03:46:18AM +0000, Templin, Fred L wrote: > Hi Jared, > > I am assuming 802.1x (or equivalent) security at L2, but the "link" between > my DHCPv6 client and server is actually a tunnel that may travel over many > network layer hops. So, it is possible for legitimate client A to have its > leases canceled by rogue client B unless DHCPv6 auth or something similar > is used. Yes, rogue client B would also have to be authenticated to connect > to the network the same as legitimate client A, but it could be an "insider > attack" (e.g., where B is a disgruntled employee trying to get back at a > corporate adversary A). > > Thanks - Fred > fred.l.templin at boeing.com > > > > -----Original Message----- > > From: Jared Mauch [mailto:jared at puck.nether.net] > > Sent: Wednesday, August 20, 2014 5:14 PM > > To: Templin, Fred L > > Cc: nanog list > > Subject: Re: DHCPv6 authentication > > > > If you are already connected to the network you are going to be deemed as authenticated. I'm unaware > > of anyone doing dhcp authentication. > > > > Jared Mauch > > > > > On Aug 20, 2014, at 6:45 PM, "Templin, Fred L" wrote: > > > > > > Hi - does anyone know if DHCPv6 authentication is commonly used in > > > operational networks? If so, what has been the experience in terms > > > of DHCPv6 servers being able to discern legitimate clients from > > > rogue clients? > > > > > > Thanks - Fred > > > fred.l.templin at boeing.com -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From Fred.L.Templin at boeing.com Thu Aug 21 12:14:57 2014 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Thu, 21 Aug 2014 12:14:57 +0000 Subject: DHCPv6 authentication In-Reply-To: <20140821114751.GF2700@puck.nether.net> References: <53F4C20D.2010103@massar.ch> <53F4CFEA.40603@massar.ch> <2134F8430051B64F815C691A62D9831832CF6288@XCH-BLV-504.nw.nos.boeing.com> <2F4EA67A-A730-40E6-99DA-6A1FA5C3AFD8@puck.nether.net> <2134F8430051B64F815C691A62D9831832CF6476@XCH-BLV-504.nw.nos.boeing.com> <20140821114751.GF2700@puck.nether.net> Message-ID: <2134F8430051B64F815C691A62D9831832CF671E@XCH-BLV-504.nw.nos.boeing.com> Hi, the question is simply whether anyone is using, or knows of any use of) DHCPv6 Authentication. Does it work? What is the operational experience? Thanks - Fred fred.l.templin at boeing.com From tarko at lanparty.ee Thu Aug 21 13:23:51 2014 From: tarko at lanparty.ee (Tarko Tikan) Date: Thu, 21 Aug 2014 16:23:51 +0300 Subject: Ebay/Paypal blocking HTTP access based on SORBS DUHL / Spamhaus PBL Message-ID: <53F5F2E7.9090803@lanparty.ee> hey, For a while now, we have been getting complains from our broadband customers about not being able to reach ebay.com/paypal.com We have nailed it down to some small prefixes and they are all listed in SORBS DUHL / Spamhaus PBL and have been listed for ages. These are indeed dynamic IP pools and should not send any email (not that SMTP has anything to do with HTTP). For some reason, it looks like ebay/paypal is now blocking HTTP access based on these blacklists. Does anyone have working contact in their NOC or with security people? All emails to public contacts have not been answered to. -- tarko From steve at blighty.com Thu Aug 21 13:46:54 2014 From: steve at blighty.com (Steve Atkins) Date: Thu, 21 Aug 2014 06:46:54 -0700 Subject: Ebay/Paypal blocking HTTP access based on SORBS DUHL / Spamhaus PBL In-Reply-To: <53F5F2E7.9090803@lanparty.ee> References: <53F5F2E7.9090803@lanparty.ee> Message-ID: <7DD7625E-87BC-4CA7-92A9-FAC998887B6B@blighty.com> On Aug 21, 2014, at 6:23 AM, Tarko Tikan wrote: > hey, > > For a while now, we have been getting complains from our broadband customers about not being able to reach ebay.com/paypal.com > > We have nailed it down to some small prefixes and they are all listed in SORBS DUHL / Spamhaus PBL and have been listed for ages. These are indeed dynamic IP pools and should not send any email (not that SMTP has anything to do with HTTP). > > For some reason, it looks like ebay/paypal is now blocking HTTP access based on these blacklists. That seems really unlikely. If they were blocking access purely due to it being from dynamically assigned ranges, someone else would have noticed. High fraud rate or other misbehaviour from those ranges seems more likely. Can you share the data that makes you think it's the former? > Does anyone have working contact in their NOC or with security people? All emails to public contacts have not been answered to. Cheers, Steve From johnl at iecc.com Thu Aug 21 16:15:46 2014 From: johnl at iecc.com (John Levine) Date: 21 Aug 2014 16:15:46 -0000 Subject: Ebay/Paypal blocking HTTP access based on SORBS DUHL / Spamhaus PBL In-Reply-To: <7DD7625E-87BC-4CA7-92A9-FAC998887B6B@blighty.com> Message-ID: <20140821161546.31920.qmail@joyce.lan> >That seems really unlikely. If they were blocking access purely due to it being from dynamically assigned ranges, >someone else would have noticed. My home IP is in both the PBL and the SORBS DUL and I have no trouble using ebay or paypal. Given that the problem range is in Estonia, I expect that it's some combination of abuse from the specific range and general issues with traffic from Estonia. R's, John From gourmetcisco at hotmail.com Thu Aug 21 17:49:50 2014 From: gourmetcisco at hotmail.com (Hank Disuko) Date: Thu, 21 Aug 2014 13:49:50 -0400 Subject: Cabling contractors Message-ID: Hey folks, I wonder if anybody knows of some good cabling contractors (structured cabling, communication racks, patch panels, all cat5e/6) in the Toronto area? My office desperately needs a clean-up. Thanks! Hank From tarko at lanparty.ee Thu Aug 21 19:49:57 2014 From: tarko at lanparty.ee (Tarko Tikan) Date: Thu, 21 Aug 2014 22:49:57 +0300 Subject: Ebay/Paypal blocking HTTP access based on SORBS DUHL / Spamhaus PBL In-Reply-To: <7DD7625E-87BC-4CA7-92A9-FAC998887B6B@blighty.com> References: <53F5F2E7.9090803@lanparty.ee> <7DD7625E-87BC-4CA7-92A9-FAC998887B6B@blighty.com> Message-ID: <53F64D65.8050102@lanparty.ee> hey, > Can you share the data that makes you think it's the former? I can't say I'm absolutely sure, hence the question to wider audience. But I can say that it's only subset of prefixes that are blocked What I can do, is provide some blocked IPs as example: 90.190.226.239 90.191.156.199 84.50.65.135 -- tarko From tarko at lanparty.ee Thu Aug 21 19:51:08 2014 From: tarko at lanparty.ee (Tarko Tikan) Date: Thu, 21 Aug 2014 22:51:08 +0300 Subject: Ebay/Paypal blocking HTTP access based on SORBS DUHL / Spamhaus PBL In-Reply-To: <20140821161546.31920.qmail@joyce.lan> References: <20140821161546.31920.qmail@joyce.lan> Message-ID: <53F64DAC.2000307@lanparty.ee> hey, > My home IP is in both the PBL and the SORBS DUL and I have no trouble > using ebay or paypal. Thanks for confirmation. > Given that the problem range is in Estonia, I expect that it's some > combination of abuse from the specific range and general issues with > traffic from Estonia. What makes you say that? Any specific examples of trouble you are getting from Estonian networks? -- tarko From faisal at snappytelecom.net Fri Aug 22 13:54:53 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Fri, 22 Aug 2014 13:54:53 +0000 (GMT) Subject: Gonodal GS4008 In-Reply-To: <437065633.281645.1408715602956.JavaMail.zimbra@snappytelecom.net> Message-ID: <23861213.281651.1408715693276.JavaMail.zimbra@snappytelecom.net> Anyone who is or has any hands on experience with the Gonadal GS4008 switch, Can you please share your experience, pros's & con's , on list of off-list will be fine. Many Thanks in advance. Regards. Faisal Imtiaz Snappy Internet & Telecom From corbe at corbe.net Fri Aug 22 14:07:23 2014 From: corbe at corbe.net (Daniel Corbe) Date: Fri, 22 Aug 2014 10:07:23 -0400 Subject: Gonodal GS4008 In-Reply-To: <23861213.281651.1408715693276.JavaMail.zimbra@snappytelecom.net> (Faisal Imtiaz's message of "Fri, 22 Aug 2014 13:54:53 +0000 (GMT)") References: <23861213.281651.1408715693276.JavaMail.zimbra@snappytelecom.net> Message-ID: Gnodal doesn't seem to have a website anymore. They've apparently been bought by Cray (as in the supercomputer company). Can one even buy a gnodal switch anymore? -Daniel Faisal Imtiaz writes: > Anyone who is or has any hands on experience with the Gonadal GS4008 switch, > > Can you please share your experience, pros's & con's , on list of > off-list will be fine. > > Many Thanks in advance. > > Regards. > > Faisal Imtiaz > Snappy Internet & Telecom From faisal at snappytelecom.net Fri Aug 22 14:21:49 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Fri, 22 Aug 2014 14:21:49 +0000 (GMT) Subject: Gonodal GS4008 In-Reply-To: References: <23861213.281651.1408715693276.JavaMail.zimbra@snappytelecom.net> Message-ID: <972728721.281907.1408717309199.JavaMail.zimbra@snappytelecom.net> Correct, Gonodal got absorbed by Cray Research... There is some inventory out there on secondary markets, surplus folks. Do you have any experience with their products ? Regards Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Daniel Corbe" > To: "Faisal Imtiaz" > Cc: "NANOG" > Sent: Friday, August 22, 2014 10:07:23 AM > Subject: Re: Gonodal GS4008 > > > Gnodal doesn't seem to have a website anymore. They've apparently been > bought by Cray (as in the supercomputer company). Can one even buy a gnodal > switch anymore? > > -Daniel > > Faisal Imtiaz writes: > > > Anyone who is or has any hands on experience with the Gonadal GS4008 > > switch, > > > > Can you please share your experience, pros's & con's , on list of > > off-list will be fine. > > > > Many Thanks in advance. > > > > Regards. > > > > Faisal Imtiaz > > Snappy Internet & Telecom > From hugo at slabnet.com Fri Aug 22 18:04:19 2014 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 22 Aug 2014 18:04:19 +0000 Subject: DHCPv6 authentication In-Reply-To: <2134F8430051B64F815C691A62D9831832CF671E@XCH-BLV-504.nw.nos.boeing.com> References: <53F4C20D.2010103@massar.ch> <53F4CFEA.40603@massar.ch> <2134F8430051B64F815C691A62D9831832CF6288@XCH-BLV-504.nw.nos.boeing.com> <2F4EA67A-A730-40E6-99DA-6A1FA5C3AFD8@puck.nether.net> <2134F8430051B64F815C691A62D9831832CF6476@XCH-BLV-504.nw.nos.boeing.com> <20140821114751.GF2700@puck.nether.net> <2134F8430051B64F815C691A62D9831832CF671E@XCH-BLV-504.nw.nos.boeing.com> Message-ID: <20140822180419.Horde.b2eH6gnoX6q8Aqqv6CjPEA1@bamboo.slabnet.com> > Hi, the question is simply whether anyone is using, or knows of any > use of) DHCPv6 Authentication. Given the responses thus far, my guess would be "no". On Thu, 21 Aug 2014 12:14:57 +0000, "Templin, Fred L" wrote: > Hi, the question is simply whether anyone is using, or knows of any > use of) DHCPv6 Authentication. Does it work? What is the operational > experience? > > Thanks - Fred > fred.l.templin at boeing.com -- Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-keys Size: 3095 bytes Desc: PGP Public Key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: PGP Digital Signature URL: From cscora at apnic.net Fri Aug 22 18:12:14 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 23 Aug 2014 04:12:14 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201408221812.s7MICEEe007981@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, TRNOG, 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 Aug, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 507746 Prefixes after maximum aggregation: 197121 Deaggregation factor: 2.58 Unique aggregates announced to Internet: 249820 Total ASes present in the Internet Routing Table: 47537 Prefixes per ASN: 10.68 Origin-only ASes present in the Internet Routing Table: 36082 Origin ASes announcing only one prefix: 16389 Transit ASes present in the Internet Routing Table: 6142 Transit-only ASes present in the Internet Routing Table: 179 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1644 Unregistered ASNs in the Routing Table: 436 Number of 32-bit ASNs allocated by the RIRs: 7255 Number of 32-bit ASNs visible in the Routing Table: 5313 Prefixes from 32-bit ASNs in the Routing Table: 19214 Number of bogon 32-bit ASNs visible in the Routing Table: 584 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 387 Number of addresses announced to Internet: 2713759876 Equivalent to 161 /8s, 192 /16s and 176 /24s Percentage of available address space announced: 73.3 Percentage of allocated address space announced: 73.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.8 Total number of prefixes smaller than registry allocations: 174262 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 123564 Total APNIC prefixes after maximum aggregation: 35943 APNIC Deaggregation factor: 3.44 Prefixes being announced from the APNIC address blocks: 127072 Unique aggregates announced from the APNIC address blocks: 52286 APNIC Region origin ASes present in the Internet Routing Table: 4975 APNIC Prefixes per ASN: 25.54 APNIC Region origin ASes announcing only one prefix: 1230 APNIC Region transit ASes present in the Internet Routing Table: 868 Average APNIC Region AS path length visible: 4.8 Max APNIC Region AS path length visible: 24 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1057 Number of APNIC addresses announced to Internet: 735421824 Equivalent to 43 /8s, 213 /16s and 165 /24s Percentage of available APNIC address space announced: 86.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 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, 150/8, 153/8, 163/8, 171/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: 169593 Total ARIN prefixes after maximum aggregation: 84870 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 171510 Unique aggregates announced from the ARIN address blocks: 80574 ARIN Region origin ASes present in the Internet Routing Table: 16364 ARIN Prefixes per ASN: 10.48 ARIN Region origin ASes announcing only one prefix: 6119 ARIN Region transit ASes present in the Internet Routing Table: 1697 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 174 Number of ARIN addresses announced to Internet: 1092923648 Equivalent to 65 /8s, 36 /16s and 177 /24s Percentage of available ARIN address space announced: 57.8 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, 62464-63487, 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, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 124822 Total RIPE prefixes after maximum aggregation: 63061 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 129640 Unique aggregates announced from the RIPE address blocks: 82097 RIPE Region origin ASes present in the Internet Routing Table: 17709 RIPE Prefixes per ASN: 7.32 RIPE Region origin ASes announcing only one prefix: 8230 RIPE Region transit ASes present in the Internet Routing Table: 2884 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2738 Number of RIPE addresses announced to Internet: 658608004 Equivalent to 39 /8s, 65 /16s and 143 /24s Percentage of available RIPE address space announced: 95.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 59392-61439, 61952-62463, 196608-202239 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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 59435 Total LACNIC prefixes after maximum aggregation: 10461 LACNIC Deaggregation factor: 5.68 Prefixes being announced from the LACNIC address blocks: 67321 Unique aggregates announced from the LACNIC address blocks: 29947 LACNIC Region origin ASes present in the Internet Routing Table: 2237 LACNIC Prefixes per ASN: 30.09 LACNIC Region origin ASes announcing only one prefix: 594 LACNIC Region transit ASes present in the Internet Routing Table: 454 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1295 Number of LACNIC addresses announced to Internet: 168010880 Equivalent to 10 /8s, 3 /16s and 164 /24s Percentage of available LACNIC address space announced: 100.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 11029 Total AfriNIC prefixes after maximum aggregation: 2750 AfriNIC Deaggregation factor: 4.01 Prefixes being announced from the AfriNIC address blocks: 11816 Unique aggregates announced from the AfriNIC address blocks: 4600 AfriNIC Region origin ASes present in the Internet Routing Table: 736 AfriNIC Prefixes per ASN: 16.05 AfriNIC Region origin ASes announcing only one prefix: 216 AfriNIC Region transit ASes present in the Internet Routing Table: 162 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 49 Number of AfriNIC addresses announced to Internet: 58419200 Equivalent to 3 /8s, 123 /16s and 104 /24s Percentage of available AfriNIC address space announced: 58.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2932 11589 917 Korea Telecom 17974 2815 901 75 PT Telekomunikasi Indonesia 7545 2329 336 120 TPG Telecom Limited 4755 1891 413 191 TATA Communications formerly 9829 1655 1307 32 National Internet Backbone 9583 1315 104 537 Sify Limited 9498 1301 317 92 BHARTI Airtel Ltd. 7552 1238 1098 14 Viettel Corporation 4808 1200 2156 367 CNCGROUP IP network China169 24560 1167 404 190 Bharti Airtel Ltd., Telemedia 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 22773 2929 2940 142 Cox Communications Inc. 6389 2898 3688 51 BellSouth.net Inc. 18566 2045 379 178 MegaPath Corporation 20115 1763 1749 536 Charter Communications 4323 1631 1073 411 tw telecom holdings, inc. 30036 1542 322 550 Mediacom Communications Corp 6983 1443 817 314 ITC^Deltacom 701 1439 11243 724 MCI Communications Services, 22561 1306 407 235 CenturyTel Internet Holdings, 7029 1259 1958 305 Windstream 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 34984 1736 298 282 TELLCOM ILETISIM HIZMETLERI A 20940 1477 575 1087 Akamai International B.V. 8402 1284 544 15 OJSC "Vimpelcom" 13188 1050 97 48 TOV "Bank-Inform" 31148 1042 45 20 Freenet Ltd. 8551 987 371 41 Bezeq International-Ltd 6849 802 356 27 JSC "Ukrtelecom" 12479 776 798 58 France Telecom Espana SA 6830 772 2334 427 Liberty Global Operations B.V 9198 632 346 28 JSC Kazakhtelecom 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 28573 3361 2017 147 NET Servi?os de Comunica??o S 10620 2960 480 214 Telmex Colombia S.A. 18881 2083 1036 22 Global Village Telecom 7303 1764 1179 231 Telecom Argentina S.A. 6147 1743 374 30 Telefonica del Peru S.A.A. 8151 1466 2995 421 Uninet S.A. de C.V. 6503 1077 434 62 Axtel, S.A.B. de C.V. 7738 977 1882 41 Telemar Norte Leste S.A. 27947 901 130 51 Telconet S.A 26615 869 2325 35 Tim Celular 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 24863 931 280 26 Link Egypt (Link.NET) 6713 669 744 37 Office National des Postes et 8452 598 958 13 TE-AS 36992 312 784 26 ETISALAT MISR 24835 307 144 9 Vodafone Data 3741 249 920 212 Internet Solutions 29571 237 22 17 Cote d'Ivoire Telecom 37054 236 19 6 Data Telecom Service 15706 185 32 6 Sudatel (Sudan Telecom Co. Lt 12258 174 26 71 MWEB CONNECT (PROPRIETARY) LI 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 28573 3361 2017 147 NET Servi?os de Comunica??o S 10620 2960 480 214 Telmex Colombia S.A. 4766 2932 11589 917 Korea Telecom 22773 2929 2940 142 Cox Communications Inc. 6389 2898 3688 51 BellSouth.net Inc. 17974 2815 901 75 PT Telekomunikasi Indonesia 7545 2329 336 120 TPG Telecom Limited 18881 2083 1036 22 Global Village Telecom 18566 2045 379 178 MegaPath Corporation 4755 1891 413 191 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2898 2847 BellSouth.net Inc. 22773 2929 2787 Cox Communications Inc. 10620 2960 2746 Telmex Colombia S.A. 17974 2815 2740 PT Telekomunikasi Indonesia 7545 2329 2209 TPG Telecom Limited 18881 2083 2061 Global Village Telecom 4766 2932 2015 Korea Telecom 18566 2045 1867 MegaPath Corporation 6147 1743 1713 Telefonica del Peru S.A.A. 4755 1891 1700 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 55020 UNALLOCATED 8.30.123.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 41.70.16.0/20 37098 globe internet limited 41.70.40.0/21 37098 globe internet limited 41.70.64.0/21 37098 globe internet limited 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 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:16 /9:13 /10:30 /11:91 /12:260 /13:499 /14:981 /15:1706 /16:13021 /17:7022 /18:11724 /19:24621 /20:35264 /21:37568 /22:54097 /23:47718 /24:271038 /25:806 /26:811 /27:405 /28:13 /29:17 /30:10 /31:1 /32:14 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2165 2929 Cox Communications Inc. 18566 2000 2045 MegaPath Corporation 6389 1675 2898 BellSouth.net Inc. 30036 1391 1542 Mediacom Communications Corp 6147 1316 1743 Telefonica del Peru S.A.A. 11492 1155 1206 CABLE ONE, INC. 6983 1149 1443 ITC^Deltacom 34984 1057 1736 TELLCOM ILETISIM HIZMETLERI A 10620 1036 2960 Telmex Colombia S.A. 22561 1001 1306 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1333 2:657 3:3 4:15 5:1075 6:21 8:727 12:1860 13:4 14:1110 15:15 16:2 17:40 18:21 20:51 23:906 24:1797 27:1795 31:1475 32:41 33:2 34:5 36:146 37:1853 38:967 39:11 40:210 41:2561 42:268 43:199 44:16 45:53 46:2139 47:24 49:734 50:829 52:12 54:49 55:4 56:4 57:32 58:1212 59:662 60:429 61:1681 62:1241 63:1829 64:4391 65:2317 66:4189 67:2057 68:1046 69:3361 70:902 71:459 72:2092 74:2600 75:337 76:415 77:1616 78:799 79:723 80:1315 81:1209 82:760 83:771 84:775 85:1317 86:426 87:1147 88:463 89:1798 90:135 91:5681 92:765 93:1775 94:2023 95:1598 96:513 97:361 98:1126 99:49 100:65 101:704 103:5398 104:208 105:37 106:179 107:598 108:582 109:2015 110:1027 111:1350 112:702 113:864 114:779 115:1149 116:1125 117:984 118:1524 119:1409 120:421 121:970 122:2162 123:1611 124:1423 125:1566 128:583 129:347 130:366 131:722 132:414 133:162 134:319 135:75 136:301 137:287 138:385 139:172 140:228 141:396 142:562 143:422 144:506 145:116 146:617 147:498 148:961 149:410 150:435 151:593 152:457 153:219 154:335 155:524 156:355 157:328 158:280 159:938 160:328 161:575 162:1709 163:342 164:689 165:641 166:345 167:669 168:1112 169:122 170:1385 171:182 172:64 173:1523 174:711 175:623 176:1463 177:3469 178:2067 179:770 180:1777 181:1581 182:1622 183:556 184:702 185:1963 186:2894 187:1623 188:2205 189:1460 190:7989 191:699 192:7512 193:5496 194:4060 195:3567 196:1430 197:679 198:5142 199:5487 200:6466 201:2850 202:9187 203:9017 204:4556 205:2642 206:2966 207:2892 208:3957 209:3704 210:3297 211:1837 212:2338 213:2134 214:881 215:88 216:5605 217:1682 218:615 219:408 220:1369 221:645 222:478 223:595 End of report From rsena at mitre.org Fri Aug 22 19:19:19 2014 From: rsena at mitre.org (Sena, Rich) Date: Fri, 22 Aug 2014 19:19:19 +0000 Subject: Verizon Network Engineer please Message-ID: <424FDD749926764BA44BBE7F0B58802A4C5038D8@IMCMBX01.MITRE.ORG> Can someone contact me please... -- Richard Sena The MITRE Corporation e: rsena at mitre.org Principal Engineer 202 Burlington Road v: +1-781-271-3712 Dept: J86E; MS K319 Bedford, MA 01730-1420 f: +1-781-271-2423 From cidr-report at potaroo.net Fri Aug 22 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 Aug 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201408222200.s7MM00Qg072855@wattle.apnic.net> This report has been generated at Fri Aug 22 21:14:52 2014 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 15-08-14 513370 281409 16-08-14 513322 281328 17-08-14 513157 281506 18-08-14 513397 281735 19-08-14 514110 281203 20-08-14 513954 281342 21-08-14 514569 281915 22-08-14 513246 282438 AS Summary 48057 Number of ASes in routing system 19454 Number of ASes announcing only one prefix 3478 Largest number of prefixes announced by an AS AS28573: NET Servi?os de Comunica??o S.A.,BR 120577536 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 22Aug14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 513537 282338 231199 45.0% All ASes AS28573 3478 128 3350 96.3% NET Servi?os de Comunica??o S.A.,BR AS6389 2897 69 2828 97.6% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS22773 2925 175 2750 94.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2816 81 2735 97.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS18881 2083 53 2030 97.5% Global Village Telecom,BR AS4766 2933 1194 1739 59.3% KIXS-AS-KR Korea Telecom,KR AS6147 1743 164 1579 90.6% Telefonica del Peru S.A.A.,PE AS7303 1771 282 1489 84.1% Telecom Argentina S.A.,AR AS4755 1889 552 1337 70.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS8402 1262 27 1235 97.9% CORBINA-AS OJSC "Vimpelcom",RU AS4323 1642 418 1224 74.5% TWTC - tw telecom holdings, inc.,US AS7552 1264 61 1203 95.2% VIETEL-AS-AP Viettel Corporation,VN AS7545 2345 1146 1199 51.1% TPG-INTERNET-AP TPG Telecom Limited,AU AS9498 1303 112 1191 91.4% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2044 862 1182 57.8% MEGAPATH5-US - MegaPath Corporation,US AS20115 1764 610 1154 65.4% CHARTER-NET-HKY-NC - Charter Communications,US AS6983 1443 316 1127 78.1% ITCDELTA - Earthlink, Inc.,US AS9808 1155 31 1124 97.3% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS10620 2960 1891 1069 36.1% Telmex Colombia S.A.,CO AS7738 977 41 936 95.8% Telemar Norte Leste S.A.,BR AS22561 1306 387 919 70.4% AS22561 - CenturyTel Internet Holdings, Inc.,US AS2516 1055 202 853 80.9% KDDI KDDI CORPORATION,JP AS38285 956 114 842 88.1% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS24560 1167 343 824 70.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS4788 1040 221 819 78.8% TMNET-AS-AP TM Net, Internet Service Provider,MY AS26615 897 129 768 85.6% Tim Celular S.A.,BR AS8151 1474 709 765 51.9% Uninet S.A. de C.V.,MX AS4780 1027 263 764 74.4% SEEDNET Digital United Inc.,TW AS18101 952 191 761 79.9% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS17908 838 96 742 88.5% TCISL Tata Communications,IN Total 51406 10868 40538 78.9% Top 30 total Possible Bogus Routes 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 41.70.16.0/20 AS37098 globe-as,MW 41.70.40.0/21 AS37098 globe-as,MW 41.70.64.0/21 AS37098 globe-as,MW 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.197.0.0/16 AS36934 ARTEL,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.193.160.0/19 AS24801 -Reserved AS-,ZZ 62.193.160.0/20 AS24801 -Reserved AS-,ZZ 62.193.176.0/20 AS24801 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.68.32.0/20 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.32.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.33.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.34.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.35.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.36.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.37.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.38.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.39.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.40.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.41.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.48.0/20 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.48.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.49.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.50.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.51.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.52.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.53.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.54.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.55.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.56.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.57.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.58.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.59.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.60.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.61.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.62.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.68.63.0/24 AS22588 DOMIN-AS - DOMINION ENTERPRISES,US 64.111.160.0/20 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.160.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.161.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.162.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.167.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.169.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.170.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.171.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.172.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.173.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.174.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.175.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 -Reserved AS-,ZZ 74.120.214.0/23 AS32326 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 89.207.8.0/21 AS3292 TDC TDC A/S,DK 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.228.160.0/24 AS56815 -Reserved AS-,ZZ 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.228.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.9.108.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.9.140.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.9.141.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.9.142.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.9.143.0/24 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP 103.18.92.0/22 AS13269 103.18.92.0/24 AS13269 103.18.94.0/24 AS13269 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.25.120.0/22 AS13280 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.249.8.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 104.192.24.0/22 AS26794 DCN-AS - Dakota Carrier Network,US 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.108.16.0/22 AS38904 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.24.0/24 AS55503 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.126.251.0/24 AS50818 -Reserved AS-,ZZ 194.146.35.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.245.98.0/23 AS48918 GLOBALWAYS GLOBALWAYS AG,DE 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 200.81.48.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.49.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 200.81.50.0/24 AS11664 Techtel LMDS Comunicaciones Interactivas S.A.,AR 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.10.94.0/23 AS30097 NUWAVE - NuWave,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.155.28.0/22 AS40925 -Reserved AS-,ZZ 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.209.224.0/19 AS19513 -Reserved AS-,ZZ 209.209.248.0/23 AS19513 -Reserved AS-,ZZ 209.209.250.0/23 AS19513 -Reserved AS-,ZZ 209.209.251.0/24 AS19513 -Reserved AS-,ZZ 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 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 cidr-report at potaroo.net Fri Aug 22 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 Aug 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201408222200.s7MM018c072871@wattle.apnic.net> BGP Update Report Interval: 14-Aug-14 -to- 21-Aug-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 210640 4.4% 1698.7 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS12041 178113 3.7% 1060.2 -- AS-AFILIAS1 - Afilias Canada, Corp.,CA 3 - AS16024 148726 3.1% 148726.0 -- GELSEN-NET GELSEN-NET Kommunikationsgesellschaft mbH,DE 4 - AS9829 143997 3.0% 140.1 -- BSNL-NIB National Internet Backbone,IN 5 - AS8402 86700 1.8% 291.9 -- CORBINA-AS OJSC "Vimpelcom",RU 6 - AS7552 81262 1.7% 64.4 -- VIETEL-AS-AP Viettel Corporation,VN 7 - AS28573 58333 1.2% 16.5 -- NET Servi?os de Comunica??o S.A.,BR 8 - AS4775 53283 1.1% 619.6 -- GLOBE-TELECOM-AS Globe Telecoms,PH 9 - AS38197 49270 1.0% 59.9 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 10 - AS1659 48064 1.0% 223.6 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW 11 - AS17885 42238 0.9% 406.1 -- JKTXLNET-AS-AP PT Excelcomindo Pratama,ID 12 - AS6713 41377 0.9% 63.1 -- IAM-AS,MA 13 - AS4 39401 0.8% 874.0 -- ISI-AS - University of Southern California,US 14 - AS2706 39057 0.8% 1027.8 -- PI-HK Pacnet Internet (Hong Kong) Limited,JP 15 - AS41691 30392 0.6% 1519.6 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 16 - AS45899 29976 0.6% 75.5 -- VNPT-AS-VN VNPT Corp,VN 17 - AS23342 29840 0.6% 4973.3 -- UNITEDLAYER - Unitedlayer, Inc.,US 18 - AS55702 28963 0.6% 7240.8 -- EIT-AS-AP 501 Gloucester Street,NZ 19 - AS6147 23053 0.5% 24.5 -- Telefonica del Peru S.A.A.,PE 20 - AS42525 22960 0.5% 441.5 -- GlobalConnect a/s,DK TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS16024 148726 3.1% 148726.0 -- GELSEN-NET GELSEN-NET Kommunikationsgesellschaft mbH,DE 2 - AS6629 9474 0.2% 9474.0 -- NOAA-AS - NOAA,US 3 - AS15657 15019 0.3% 7509.5 -- SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 4 - AS55702 28963 0.6% 7240.8 -- EIT-AS-AP 501 Gloucester Street,NZ 5 - AS10098 13521 0.3% 6760.5 -- HENDERSON-HK Henderson Data Centre Limited,HK 6 - AS23342 29840 0.6% 4973.3 -- UNITEDLAYER - Unitedlayer, Inc.,US 7 - AS4 4660 0.1% 1486.0 -- ISI-AS - University of Southern California,US 8 - AS12559 8946 0.2% 4473.0 -- ISIDE-AS I.S.I.D.E. S.p.A.,IT 9 - AS61765 4462 0.1% 4462.0 -- VIVA TELECOMUNICA??ES LTDA- ME,BR 10 - AS1767 21863 0.5% 4372.6 -- ILIGHT-NET - Indiana Higher Education Telecommunication System,US 11 - AS37620 4173 0.1% 4173.0 -- VIETTEL-CM-AS,CM 12 - AS62174 3872 0.1% 3872.0 -- INTERPAN-AS INTERPAN LTD.,BG 13 - AS38267 3808 0.1% 3808.0 -- FIBRENET-BD FibreNet Communications Ltd.,BD 14 - AS42449 3660 0.1% 3660.0 -- ASN-MAIRIE_MULHOUSE Commune de Mulhouse,FR 15 - AS25003 21731 0.5% 3621.8 -- INTERNET_BINAT Internet Binat Ltd,IL 16 - AS53168 10772 0.2% 3590.7 -- CIA ESTADUAL DE GERA??O E TRANSMISS?O DE ENERGIA E,BR 17 - AS32336 16684 0.3% 3336.8 -- IPASS-2 - iPass Incorporated,US 18 - AS4 18007 0.4% 834.0 -- ISI-AS - University of Southern California,US 19 - AS47680 2780 0.1% 2780.0 -- NHCS EOBO Limited,IE 20 - AS33643 2697 0.1% 2697.0 -- JELLYBELLY - Jelly Belly Candy Company,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 185.47.232.0/22 148726 3.0% AS16024 -- GELSEN-NET GELSEN-NET Kommunikationsgesellschaft mbH,DE 2 - 202.70.88.0/21 105031 2.1% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 202.70.64.0/21 104693 2.1% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 46.53.64.0/19 40627 0.8% AS24814 -- SCS-AS Syrian Computer Society, scs,SY AS29386 -- EXT-PDN-STE-AS Syrian Telecommunications Establishment,SY 5 - 89.221.206.0/24 30248 0.6% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 6 - 64.29.130.0/24 29811 0.6% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 7 - 120.28.62.0/24 26364 0.5% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 8 - 222.127.0.0/24 26331 0.5% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 9 - 192.115.44.0/22 21722 0.4% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 10 - 216.231.194.0/24 16676 0.3% AS32336 -- IPASS-2 - iPass Incorporated,US 11 - 202.123.88.0/24 13513 0.3% AS10098 -- HENDERSON-HK Henderson Data Centre Limited,HK 12 - 42.83.48.0/20 13216 0.3% AS18135 -- BTV BTV Cable television,JP 13 - 205.247.12.0/24 12173 0.2% AS6459 -- TRANSBEAM - I-2000, Inc.,US 14 - 112.215.16.0/24 11882 0.2% AS17885 -- JKTXLNET-AS-AP PT Excelcomindo Pratama,ID AS24203 -- NAPXLNET-AS-ID PT Excelcomindo Pratama (Network Access Provider),ID 15 - 185.27.8.0/22 11700 0.2% AS42525 -- GlobalConnect a/s,DK 16 - 185.27.10.0/24 11050 0.2% AS42525 -- GlobalConnect a/s,DK 17 - 65.22.158.0/24 10925 0.2% AS12041 -- AS-AFILIAS1 - Afilias Canada, Corp.,CA 18 - 65.22.66.0/24 10759 0.2% AS12041 -- AS-AFILIAS1 - Afilias Canada, Corp.,CA 19 - 65.22.157.0/24 10567 0.2% AS12041 -- AS-AFILIAS1 - Afilias Canada, Corp.,CA 20 - 65.22.65.0/24 10296 0.2% AS12041 -- AS-AFILIAS1 - Afilias Canada, Corp.,CA 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 drc at virtualized.org Sun Aug 24 19:00:59 2014 From: drc at virtualized.org (David Conrad) Date: Sun, 24 Aug 2014 12:00:59 -0700 Subject: 127.0.53.53 in logs? Message-ID: <782404A1-D8F6-4651-A28A-554AC31FCBBD@virtualized.org> Hi, I was wondering if any resolver operators were seeing 127.0.53.53 in log files. For anyone who isn?t aware, seeing that address would suggest a ?name collision? (see https://www.icann.org/resources/pages/name-collision-2013-12-06-en if you don?t know what that is). As currently over 300 new generic TLDs have been delegated and there was much ... ?discussion? about the risk associated with the delegation of those TLDs, I?d be interested in hearing about anything anyone is seeing related to ?name collision". Thanks, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mpetach at netflight.com Sun Aug 24 22:46:26 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 24 Aug 2014 15:46:26 -0700 Subject: Best US Tunnelbroker for Youtube In-Reply-To: References: Message-ID: On Wed, Aug 20, 2014 at 7:55 AM, Ryan Shea wrote: > Just one man's experience, but my YouTube performance over my Hurricane > Electric tunnel has been strikingly poor lately - so much so that I was > thinking of squashing v6 in my house entirely. Looking for your > experiences/thoughts on whether cutting over to SixXS or Routinghouse could > be a path to 1080p cat video bliss instead. > > You might also consider trying alternate sources of video streams such as screen.yahoo.com to see if your cat video bliss might be better fulfilled through a different source than Youtube, if indeed the problem lies between you and Youtube. Matt From ryanshea at google.com Mon Aug 25 12:52:28 2014 From: ryanshea at google.com (Ryan Shea) Date: Mon, 25 Aug 2014 08:52:28 -0400 Subject: Best US Tunnelbroker for Youtube In-Reply-To: References: Message-ID: I expect it would work (ignoring the obvious reasons this is likely not to lead to bliss) - but not for the reasons expected. I get a AAAA back from screen.yahoo.com, but the actual video stream (which I am largely guessing is the "big" content I see in iftop coming from yahoo's CDN) comes over v4. At least it is better than vimeo's, A-only. On Sun, Aug 24, 2014 at 6:46 PM, Matthew Petach wrote: > > > > On Wed, Aug 20, 2014 at 7:55 AM, Ryan Shea wrote: > >> Just one man's experience, but my YouTube performance over my Hurricane >> Electric tunnel has been strikingly poor lately - so much so that I was >> thinking of squashing v6 in my house entirely. Looking for your >> experiences/thoughts on whether cutting over to SixXS or Routinghouse >> could >> be a path to 1080p cat video bliss instead. >> >> > You might also consider trying alternate > sources of video streams such as > screen.yahoo.com to see if your > cat video bliss might be better > fulfilled through a different source > than Youtube, if indeed the problem > lies between you and Youtube. > > Matt > > From rwebb at ropeguru.com Mon Aug 25 19:28:07 2014 From: rwebb at ropeguru.com (Robert Webb) Date: Mon, 25 Aug 2014 15:28:07 -0400 Subject: Route Lookup Message-ID: Can anyone lookup and IP for me, 194.117.106.129, tell me what you see? It should be an IP belonging to SAP in Germany, but it is not accessible and a BGP lookup from Level 3 in Germany gives me "Network not in table". Thanks... From ssaner at hubris.net Mon Aug 25 19:34:17 2014 From: ssaner at hubris.net (Steven Saner) Date: Mon, 25 Aug 2014 14:34:17 -0500 Subject: Route Lookup In-Reply-To: References: Message-ID: <53FB8FB9.9030502@hubris.net> On 08/25/2014 02:28 PM, Robert Webb wrote: > Can anyone lookup and IP for me, 194.117.106.129, tell me what you see? > It should be an IP belonging to SAP in Germany, but it is not accessible > and a BGP lookup from Level 3 in Germany gives me "Network not in table". > > Thanks... > I'm not seeing anything for the entire /19 via Level3, Hurricane Electric, or Cogent in Kansas City. Steve -- -------------------------------------------------------------------------- Steven Saner Voice: 316-858-3000 Director of Network Operations Fax: 316-858-3001 Hubris Communications http://www.hubris.net From listas at esds.com.br Mon Aug 25 19:37:00 2014 From: listas at esds.com.br (Eduardo Schoedler) Date: Mon, 25 Aug 2014 16:37:00 -0300 Subject: Route Lookup In-Reply-To: References: Message-ID: No such route here. PS: I have full table bgp. 2014-08-25 16:28 GMT-03:00 Robert Webb : > Can anyone lookup and IP for me, 194.117.106.129, tell me what you see? It > should be an IP belonging to SAP in Germany, but it is not accessible and a > BGP lookup from Level 3 in Germany gives me "Network not in table". > > Thanks... -- Eduardo Schoedler From rwebb at ropeguru.com Mon Aug 25 19:40:04 2014 From: rwebb at ropeguru.com (Robert Webb) Date: Mon, 25 Aug 2014 15:40:04 -0400 Subject: Route Lookup In-Reply-To: <53FB8FB9.9030502@hubris.net> References: <53FB8FB9.9030502@hubris.net> Message-ID: Thanks everyone. That validates my theory, so now I can put it back on SAP. Robert On Mon, 25 Aug 2014 14:34:17 -0500 Steven Saner wrote: > On 08/25/2014 02:28 PM, Robert Webb wrote: >> Can anyone lookup and IP for me, 194.117.106.129, tell me what you >>see? >> It should be an IP belonging to SAP in Germany, but it is not >>accessible >> and a BGP lookup from Level 3 in Germany gives me "Network not in >>table". >> >> Thanks... >> > > I'm not seeing anything for the entire /19 via Level3, Hurricane > Electric, or Cogent in Kansas City. > > Steve > > -- > -------------------------------------------------------------------------- > Steven Saner Voice: > 316-858-3000 > Director of Network Operations Fax: > 316-858-3001 > Hubris Communications > http://www.hubris.net From kenneth.mcrae at me.com Mon Aug 25 19:59:06 2014 From: kenneth.mcrae at me.com (Kenneth McRae) Date: Mon, 25 Aug 2014 19:59:06 +0000 (GMT) Subject: Optical Transport Platform Message-ID: Greetings Everyone.. Here is one for the transport/backbone/data center guys. ?Can you tell which manufactures you like for optical transport? ?I am looking for a solution to provide 8 channels of DWDM using tuned optics in my network gear. DWDM transport will be used for multiplexing only (no amplification or wavelength generation). ?So far, I have been looking at Fiberstore and PacketLight..? Any suggestions? All feedback is greatly appreciated! Thanks Kenneth From clayton at MNSi.Net Mon Aug 25 20:03:42 2014 From: clayton at MNSi.Net (Clayton Zekelman) Date: Mon, 25 Aug 2014 16:03:42 -0400 Subject: Optical Transport Platform In-Reply-To: References: Message-ID: <1408997023_116316@surgemail.mnsi.net> We've had good luck with BTI Systems http://www.btisystems.com/ At 03:59 PM 25/08/2014, Kenneth McRae wrote: >Greetings Everyone.. Here is one for the transport/backbone/data >center guys. Can you tell which manufactures you like for optical >transport? I am looking for a solution to provide 8 channels of >DWDM using tuned optics in my network gear. DWDM transport will be >used for multiplexing only (no amplification or wavelength >generation). So far, I have been looking at Fiberstore and >PacketLight.. Any suggestions? All feedback is greatly appreciated! >Thanks Kenneth --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From has at google.com Mon Aug 25 20:23:33 2014 From: has at google.com (Heather Schiller) Date: Mon, 25 Aug 2014 16:23:33 -0400 Subject: Verizon Network Engineer please In-Reply-To: <424FDD749926764BA44BBE7F0B58802A4C5038D8@IMCMBX01.MITRE.ORG> References: <424FDD749926764BA44BBE7F0B58802A4C5038D8@IMCMBX01.MITRE.ORG> Message-ID: If you haven't received a response, try being more specific. Verizon is >100 asn's and full of all kinds of network engineers. On Fri, Aug 22, 2014 at 3:19 PM, Sena, Rich wrote: > Can someone contact me please... > > -- > Richard Sena The MITRE Corporation e: rsena at mitre.org rsena at mitre.org> > Principal Engineer 202 Burlington Road v: +1-781-271-3712 > Dept: J86E; MS K319 Bedford, MA 01730-1420 f: +1-781-271-2423 > > From RCzumbil at xand.com Mon Aug 25 20:36:40 2014 From: RCzumbil at xand.com (Romeo Czumbil) Date: Mon, 25 Aug 2014 20:36:40 +0000 Subject: Optical Transport Platform In-Reply-To: References: Message-ID: Check out Ekinops They have been rock solid with me. They are not as expensive as the others and there's no switching in the backplane. Everything happens on the module cards http://www.ekinops.net Romeo Czumbil Sr. Network Engineer ? 1000 Adams Ave |?Norristown, PA 19403 tel?610-994-3046?| cell 609-220-0322 rczumbil at xand.com website??|??news??|??blog??|??data centers??? ? Confidentiality Note:?This e-mail and any attachments are confidential and may be protected by legal privilege. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you for your cooperation. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kenneth McRae Sent: Monday, August 25, 2014 3:59 PM To: NANOG Subject: Optical Transport Platform Greetings Everyone.. Here is one for the transport/backbone/data center guys. ?Can you tell which manufactures you like for optical transport? ?I am looking for a solution to provide 8 channels of DWDM using tuned optics in my network gear. DWDM transport will be used for multiplexing only (no amplification or wavelength generation). ?So far, I have been looking at Fiberstore and PacketLight..? Any suggestions? All feedback is greatly appreciated! Thanks Kenneth From joquendo at e-fensive.net Mon Aug 25 20:26:29 2014 From: joquendo at e-fensive.net (J. Oquendo) Date: Mon, 25 Aug 2014 15:26:29 -0500 Subject: Verizon Network Engineer please In-Reply-To: References: <424FDD749926764BA44BBE7F0B58802A4C5038D8@IMCMBX01.MITRE.ORG> Message-ID: <20140825202629.GB21620@e-fensive.net> On Mon, 25 Aug 2014, Heather Schiller wrote: > If you haven't received a response, try being more specific. Verizon is > >100 asn's and full of all kinds of network engineers. > > > On Fri, Aug 22, 2014 at 3:19 PM, Sena, Rich wrote: > > > Can someone contact me please... > > > > -- > > Richard Sena The MITRE Corporation e: rsena at mitre.org > rsena at mitre.org> > > Principal Engineer 202 Burlington Road v: +1-781-271-3712 > > Dept: J86E; MS K319 Bedford, MA 01730-1420 f: +1-781-271-2423 > > > > Normally I rant: Can someone from Verizon who deals with routers contact me. (Then I filter out the millions of responses from home users running Linksys and DLink routers) -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF From eric at flanery.us Mon Aug 25 23:14:30 2014 From: eric at flanery.us (Eric Flanery (eric)) Date: Mon, 25 Aug 2014 16:14:30 -0700 Subject: Optical Transport Platform In-Reply-To: References: Message-ID: I've been really happy with the Fiberstore muxes/demuxes, although I'm using CWDM not DWDM. They do the job, are entirely passive (no power needed), perform well (real world losses seem to match the test reports to a tee), seem solid enough, and this sort of stuff doesn't get any cheaper (that I've found). If you are looking for a 'platform', with _any_ sort of bells or whistles, they aren't what you are looking for. but, if you just want a cheap way to squeeze multiple channels onto a strand or two, they rock. --Eric On Mon, Aug 25, 2014 at 1:36 PM, Romeo Czumbil wrote: > Check out Ekinops > They have been rock solid with me. They are not as expensive as the others > and there's no switching in the backplane. Everything happens on the module > cards > http://www.ekinops.net > > > > > > > Romeo Czumbil > Sr. Network Engineer > > > 1000 Adams Ave | Norristown, PA 19403 > tel 610-994-3046 | cell 609-220-0322 > rczumbil at xand.com > > website | news | blog | data centers > > Confidentiality Note: This e-mail and any attachments are confidential and > may be protected by legal privilege. If you are not the intended recipient, > be aware that any disclosure, copying, distribution or use of this e-mail > or any attachment is prohibited. If you have received this e-mail in error, > please notify us immediately by returning it to the sender and delete this > copy from your system. Thank you for your cooperation. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kenneth McRae > Sent: Monday, August 25, 2014 3:59 PM > To: NANOG > Subject: Optical Transport Platform > > Greetings Everyone.. > > Here is one for the transport/backbone/data center guys. Can you tell > which manufactures you like for optical transport? I am looking for a > solution to provide 8 channels of DWDM using tuned optics in my network > gear. DWDM transport will be used for multiplexing only (no amplification > or wavelength generation). So far, I have been looking at Fiberstore and > PacketLight.. > > Any suggestions? > > All feedback is greatly appreciated! > > Thanks > > Kenneth > From frnkblk at iname.com Tue Aug 26 04:15:57 2014 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 25 Aug 2014 23:15:57 -0500 Subject: Optical Transport Platform In-Reply-To: References: Message-ID: <008001cfc0e4$6fa5ff60$4ef1fe20$@iname.com> Are you looking for P-OTS or just xWDM? If the first you may want to look at Cyan, which is what we use. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kenneth McRae Sent: Monday, August 25, 2014 2:59 PM To: NANOG Subject: Optical Transport Platform Greetings Everyone.. Here is one for the transport/backbone/data center guys. ?Can you tell which manufactures you like for optical transport? ?I am looking for a solution to provide 8 channels of DWDM using tuned optics in my network gear. DWDM transport will be used for multiplexing only (no amplification or wavelength generation). ?So far, I have been looking at Fiberstore and PacketLight..? Any suggestions? All feedback is greatly appreciated! Thanks Kenneth From mark.tinka at seacom.mu Tue Aug 26 05:45:54 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 26 Aug 2014 07:45:54 +0200 Subject: Optical Transport Platform In-Reply-To: References: Message-ID: <201408260745.57130.mark.tinka@seacom.mu> On Monday, August 25, 2014 10:36:40 PM Romeo Czumbil wrote: > Check out Ekinops > They have been rock solid with me. They are not as > expensive as the others and there's no switching in the > backplane. Everything happens on the module cards > http://www.ekinops.net Transmode have a similar architecture. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mfidelman at meetinghouse.net Tue Aug 26 11:48:32 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 26 Aug 2014 07:48:32 -0400 Subject: where to go to understand DDoS attack vector Message-ID: <53FC7410.9010203@meetinghouse.net> Hi Folks, Possibly a little off-topic for nanog, but I couldn't think of anywhere else to ask this (suggestions please!): We just discovered a vulnerability the hard way - someone used one of our IPMI boards as a vector for a DDoS attack (well, I guess the real hard way would be to have been on the receiving end, but...). Anyway... aside from some obvious issues, I've been learning a lot about the vulnerabilities of Supermicro IPMI boards (and busily locking them down). The one that's tricky, though, is that this was a reflection/amplification attack. Conveniently, the attackee's data center operator managed to capture incoming packets with tcpdump, and they all looked like this: 8:33:58.482193 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c E..... at .8 .....;. 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 @^....i.....C... 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. (obviously, with the IP addresses removed). It could be that someone planted a bot in the IPMI board (just starting to do some forensics - currently hampered by being on travel, and having blocked all the ports from the outside world - need to get to the datacenter and make some hardwired connections) - but it looks a lot more like a reflection/amplification attack - particularly since the target seems to have been a game host, and port 27015 is used by the game halflife. But.... Now I understand reflected DNS and NTP attacks - but the outbound port, 2072 (registered for GlobeCom msync) is neither, nor is it anything that we're running - which kind of begs the question of how this might be working. Any thoughts? Any pointers? Any starting points? Immediate issue is dealt with (at least for us, target seems to be off the air) - but want to understand this, report it, all of that. Thanks very much, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From rdobbins at arbor.net Tue Aug 26 11:57:27 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 26 Aug 2014 18:57:27 +0700 Subject: where to go to understand DDoS attack vector In-Reply-To: <53FC7410.9010203@meetinghouse.net> References: <53FC7410.9010203@meetinghouse.net> Message-ID: <1DDE300E-BAB9-4383-B87B-022F59AEA279@arbor.net> On Aug 26, 2014, at 6:48 PM, Miles Fidelman wrote: > Immediate issue is dealt with (at least for us, target seems to be off the air) - but want to understand this, report it, all of that. IPMI boards are reported as being used in reflection/amplification attacks of various kinds; the ntp one is straightforward, as you note. This may be some sort of chargen-like packet reflector that's either built into the firmware, or that an attacker has managed to insert, somehow. The 'mailto:' bit is interesting; it might work sort of like SNMP reflection/amplification attacks work, where the attacker is using some sort of management functionality to walk the device config or somesuch, packetize it, and blast it out as packet-padding. Does the target of the attack have flow telemetry records or complete packets? Because the one you posted looked incomplete (29 bytes?) . . . ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laoco?n From mfidelman at meetinghouse.net Tue Aug 26 12:18:39 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 26 Aug 2014 08:18:39 -0400 Subject: where to go to understand DDoS attack vector In-Reply-To: <1DDE300E-BAB9-4383-B87B-022F59AEA279@arbor.net> References: <53FC7410.9010203@meetinghouse.net> <1DDE300E-BAB9-4383-B87B-022F59AEA279@arbor.net> Message-ID: <53FC7B1F.9040409@meetinghouse.net> Roland Dobbins wrote: > On Aug 26, 2014, at 6:48 PM, Miles Fidelman wrote: > >> Immediate issue is dealt with (at least for us, target seems to be off the air) - but want to understand this, report it, all of that. > IPMI boards are reported as being used in reflection/amplification attacks of various kinds; the ntp one is straightforward, as you note. > > This may be some sort of chargen-like packet reflector that's either built into the firmware, or that an attacker has managed to insert, somehow. The 'mailto:' bit is interesting; it might work sort of like SNMP reflection/amplification attacks work, where the attacker is using some sort of management functionality to walk the device config or somesuch, packetize it, and blast it out as packet-padding. Can you say a bit more about what I might look for in trying to track this down? > > Does the target of the attack have flow telemetry records or complete packets? Because the one you posted looked incomplete (29 bytes?) . . . > > Unfortunately, all I have is what they sent to our abuse address - understandably, they've been a bit busy and not as responsive to further inquiries as one might hope. But, having said that, this looks like all they have. They seem to be getting these from lots of different places around the net, they just sent a filtered excerpt - here's a larger sample: 18:33:58.482193 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c E..... at .8 .....;. 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 @^....i.....C... 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. 18:33:58.484625 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c E..... at .8 .....;. 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 @^....i.....C... 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. 18:33:58.486137 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c E..... at .8 .....;. 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 @^....i.....C... 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. On closer reading, what they captured does seem to be "proto UDP (17), length 29)" and "UDP, length 1" Thanks! Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From rdobbins at arbor.net Tue Aug 26 13:05:10 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 26 Aug 2014 20:05:10 +0700 Subject: where to go to understand DDoS attack vector In-Reply-To: <53FC7B1F.9040409@meetinghouse.net> References: <53FC7410.9010203@meetinghouse.net> <1DDE300E-BAB9-4383-B87B-022F59AEA279@arbor.net> <53FC7B1F.9040409@meetinghouse.net> Message-ID: <99966945-7A03-4731-A171-C2A8EE6A1B01@arbor.net> On Aug 26, 2014, at 7:18 PM, Miles Fidelman wrote: > Can you say a bit more about what I might look for in trying to track this down? Fuzz your IPMI boards? ;> My guess is that this is going to come to light sooner rather than later. We're getting reports of other DDoS attacks which seem to match this scenario involving IPMI boards. There's no real reason to try and track it down, from an operational standpoint, is there> Management-plane things like IMPI boards shouldn't be open to the general Internet; put them behind ACLs and use a VPN. Problem solved. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laoco?n From list at satchell.net Tue Aug 26 13:26:33 2014 From: list at satchell.net (Stephen Satchell) Date: Tue, 26 Aug 2014 06:26:33 -0700 Subject: where to go to understand DDoS attack vector In-Reply-To: <53FC7B1F.9040409@meetinghouse.net> References: <53FC7410.9010203@meetinghouse.net> <1DDE300E-BAB9-4383-B87B-022F59AEA279@arbor.net> <53FC7B1F.9040409@meetinghouse.net> Message-ID: <53FC8B09.7080505@satchell.net> qotd 17/udp quote You're not blocking small services outbound at the edge? On 08/26/2014 05:18 AM, Miles Fidelman wrote: > Roland Dobbins wrote: >> On Aug 26, 2014, at 6:48 PM, Miles Fidelman >> wrote: >> >>> Immediate issue is dealt with (at least for us, target seems to be >>> off the air) - but want to understand this, report it, all of that. >> IPMI boards are reported as being used in reflection/amplification >> attacks of various kinds; the ntp one is straightforward, as you note. >> >> This may be some sort of chargen-like packet reflector that's either >> built into the firmware, or that an attacker has managed to insert, >> somehow. The 'mailto:' bit is interesting; it might work sort of like >> SNMP reflection/amplification attacks work, where the attacker is >> using some sort of management functionality to walk the device config >> or somesuch, packetize it, and blast it out as packet-padding. > > Can you say a bit more about what I might look for in trying to track > this down? > >> >> Does the target of the attack have flow telemetry records or complete >> packets? Because the one you posted looked incomplete (29 bytes?) . . . >> >> > > Unfortunately, all I have is what they sent to our abuse address - > understandably, they've been a bit busy and not as responsive to further > inquiries as one might hope. > > But, having said that, this looks like all they have. They seem to be > getting these from lots of different places around the net, they just > sent a filtered excerpt - here's a larger sample: > > 18:33:58.482193 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto > UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 > 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c > E..... at .8 .....;. > 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 > @^....i.....C... > 0x0020: 0000 0000 0000 0000 0000 0000 0000 > .............. > 18:33:58.484625 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto > UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 > 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c > E..... at .8 .....;. > 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 > @^....i.....C... > 0x0020: 0000 0000 0000 0000 0000 0000 0000 > .............. > 18:33:58.486137 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto > UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 > 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c > E..... at .8 .....;. > 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 > @^....i.....C... > 0x0020: 0000 0000 0000 0000 0000 0000 0000 > .............. > > On closer reading, what they captured does seem to be "proto UDP (17), > length 29)" and "UDP, length 1" > > Thanks! > > Miles > From rdobbins at arbor.net Tue Aug 26 13:31:54 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 26 Aug 2014 20:31:54 +0700 Subject: where to go to understand DDoS attack vector In-Reply-To: <53FC8B09.7080505@satchell.net> References: <53FC7410.9010203@meetinghouse.net> <1DDE300E-BAB9-4383-B87B-022F59AEA279@arbor.net> <53FC7B1F.9040409@meetinghouse.net> <53FC8B09.7080505@satchell.net> Message-ID: On Aug 26, 2014, at 8:26 PM, Stephen Satchell wrote: > qotd 17/udp quote No, that's the protocol number - 17 is UDP - not the port number. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laoco?n From johny at griffintechnology.com Tue Aug 26 13:37:43 2014 From: johny at griffintechnology.com (John York) Date: Tue, 26 Aug 2014 08:37:43 -0500 Subject: where to go to understand DDoS attack vector In-Reply-To: References: <53FC7410.9010203@meetinghouse.net> <1DDE300E-BAB9-4383-B87B-022F59AEA279@arbor.net> <53FC7B1F.9040409@meetinghouse.net> <53FC8B09.7080505@satchell.net> Message-ID: <7f2ce6cba805dc1fb6cd55d5416ca7c7@mail.gmail.com> In this case, 17 is both the protocol and port number. Confusing coincidence :) > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland > Dobbins > Sent: Tuesday, August 26, 2014 8:32 AM > To: nanog at nanog.org > Subject: Re: where to go to understand DDoS attack vector > > > On Aug 26, 2014, at 8:26 PM, Stephen Satchell wrote: > > > qotd 17/udp quote > > No, that's the protocol number - 17 is UDP - not the port number. > > ---------------------------------------------------------------------- > Roland Dobbins // > > > Equo ne credite, Teucri. > > -- Laoco?n From rdobbins at arbor.net Tue Aug 26 13:58:08 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 26 Aug 2014 20:58:08 +0700 Subject: where to go to understand DDoS attack vector In-Reply-To: <7f2ce6cba805dc1fb6cd55d5416ca7c7@mail.gmail.com> References: <53FC7410.9010203@meetinghouse.net> <1DDE300E-BAB9-4383-B87B-022F59AEA279@arbor.net> <53FC7B1F.9040409@meetinghouse.net> <53FC8B09.7080505@satchell.net> <7f2ce6cba805dc1fb6cd55d5416ca7c7@mail.gmail.com> Message-ID: <26AE7E96-8F1A-4709-8B16-C12A89A86F36@arbor.net> On Aug 26, 2014, at 8:37 PM, John York wrote: > In this case, 17 is both the protocol and port number. Confusing coincidence :) Not in this output which the OP sent to the list: > 8:33:58.482193 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 > 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c E..... at .8 .....;. > 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 @^....i.....C... > 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. > 18:33:58.482193 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 > 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c E..... at .8 .....;. > 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 @^....i.....C... > 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. > 18:33:58.484625 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 > 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c E..... at .8 .....;. > 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 @^....i.....C... > 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. > 18:33:58.486137 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 > 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c E..... at .8 .....;. > 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 @^....i.....C... > 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. Source port 2072, destination port 27015. ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laoco?n From Valdis.Kletnieks at vt.edu Tue Aug 26 16:02:35 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 26 Aug 2014 12:02:35 -0400 Subject: where to go to understand DDoS attack vector In-Reply-To: Your message of "Tue, 26 Aug 2014 18:57:27 +0700." <1DDE300E-BAB9-4383-B87B-022F59AEA279@arbor.net> References: <53FC7410.9010203@meetinghouse.net> <1DDE300E-BAB9-4383-B87B-022F59AEA279@arbor.net> Message-ID: <28000.1409068955@turing-police.cc.vt.edu> On Tue, 26 Aug 2014 18:57:27 +0700, Roland Dobbins said: >. The 'mailto:' bit is interesting; it might work sort of like SNMP reflection/amplificati Nope. It's a red herring, somebody's MUA trying to get *far* too clever with the fact that there's a literal ".... at .8" in the ascii dump part of the packet. Took me a few seconds to figure it out too, am a tad low on caffeine today. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From ncolton at allophone.net Tue Aug 26 16:24:48 2014 From: ncolton at allophone.net (Nick Colton) Date: Tue, 26 Aug 2014 10:24:48 -0600 Subject: Optical Transport Platform In-Reply-To: References: Message-ID: We've been using Cyan for our transport/backbone for several years now and have been very happy with them. Of all the platforms we've used their element management system has been the easiest to train. Nick Colton Director of Network Operations ALLO Communications 610 Broadway - PO Box 1123 Imperial, NE 69033 308-633-7814 On Mon, Aug 25, 2014 at 1:59 PM, Kenneth McRae wrote: > Greetings Everyone.. > > Here is one for the transport/backbone/data center guys. Can you tell > which manufactures you like for optical transport? I am looking for a > solution to provide 8 channels of DWDM using tuned optics in my network > gear. DWDM transport will be used for multiplexing only (no amplification > or wavelength generation). So far, I have been looking at Fiberstore and > PacketLight.. > > Any suggestions? > > All feedback is greatly appreciated! > > Thanks > > Kenneth From rdobbins at arbor.net Tue Aug 26 16:28:15 2014 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 26 Aug 2014 23:28:15 +0700 Subject: where to go to understand DDoS attack vector In-Reply-To: <28000.1409068955@turing-police.cc.vt.edu> References: <53FC7410.9010203@meetinghouse.net> <1DDE300E-BAB9-4383-B87B-022F59AEA279@arbor.net> <28000.1409068955@turing-police.cc.vt.edu> Message-ID: <223DE632-3373-4914-9B66-82D43C5F2EB2@arbor.net> On Aug 26, 2014, at 11:02 PM, Valdis.Kletnieks at vt.edu wrote: > Took me a few seconds to figure it out too, am a tad low on caffeine today. :) doh, lack of proper sanitization/escaping strikes again! ---------------------------------------------------------------------- Roland Dobbins // Equo ne credite, Teucri. -- Laoco?n -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cjp at 0x1.net Tue Aug 26 16:46:31 2014 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Tue, 26 Aug 2014 12:46:31 -0400 Subject: Verizon (NY, LEC) issues around 1200 EDT? Message-ID: We saw multiple service outages from Verizon local in NYC, specifically our offices served out of Broad Street (NYCMNYBS). Lost multiple OC as well as local voice PRI. I haven't dug exact times out of the logs yet, but was around noon EDT. Anyone else see similar or know what went on? -cjp From jschiel at flowtools.net Tue Aug 26 16:52:35 2014 From: jschiel at flowtools.net (me) Date: Tue, 26 Aug 2014 10:52:35 -0600 Subject: where to go to understand DDoS attack vector In-Reply-To: <26AE7E96-8F1A-4709-8B16-C12A89A86F36@arbor.net> References: <53FC7410.9010203@meetinghouse.net> <1DDE300E-BAB9-4383-B87B-022F59AEA279@arbor.net> <53FC7B1F.9040409@meetinghouse.net> <53FC8B09.7080505@satchell.net> <7f2ce6cba805dc1fb6cd55d5416ca7c7@mail.gmail.com> <26AE7E96-8F1A-4709-8B16-C12A89A86F36@arbor.net> Message-ID: <53FCBB53.30505@flowtools.net> On 08/26/2014 07:58 AM, Roland Dobbins wrote: > On Aug 26, 2014, at 8:37 PM, John York wrote: > >> In this case, 17 is both the protocol and port number. Confusing coincidence :) > Not in this output which the OP sent to the list: > >> 8:33:58.482193 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 >> 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c E..... at .8 .....;. >> 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 @^....i.....C... >> 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. > >> 18:33:58.482193 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 >> 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c E..... at .8 .....;. >> 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 @^....i.....C... >> 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. >> 18:33:58.484625 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 >> 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c E..... at .8 .....;. >> 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 @^....i.....C... >> 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. >> 18:33:58.486137 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 >> 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c E..... at .8 .....;. >> 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 @^....i.....C... >> 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. > Source port 2072, destination port 27015. Been awhile since I got to dig into hex tcpdump but spent the time anyway. A UDP data segment that is 9 bytes long and only contains a "C" (0x43) ? And looks like to a Steam/Half-life (27015) gaming port. Not sure what the "C" is used for with those systems but guessing it's some sort of request? --john > > ---------------------------------------------------------------------- > Roland Dobbins // > > Equo ne credite, Teucri. > > -- Laoco?n > From cjp at 0x1.net Tue Aug 26 17:07:18 2014 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Tue, 26 Aug 2014 13:07:18 -0400 Subject: Verizon (NY, LEC) issues around 1200 EDT? In-Reply-To: References: Message-ID: Well, I need to wind my watch... we saw path AIS on our OCs out of that CO at 12:23:39 EDT. Cleared ten seconds later. Voice PRIs took a bit longer to recover. On Tue, Aug 26, 2014 at 12:46 PM, Christopher J. Pilkington wrote: > We saw multiple service outages from Verizon local in NYC, specifically > our offices served out of Broad Street (NYCMNYBS). Lost multiple OC as well > as local voice PRI. > > I haven't dug exact times out of the logs yet, but was around noon EDT. > > Anyone else see similar or know what went on? > > -cjp > From saku at ytti.fi Tue Aug 26 17:13:14 2014 From: saku at ytti.fi (Saku Ytti) Date: Tue, 26 Aug 2014 20:13:14 +0300 Subject: network quality measurement probes+reporting Message-ID: <20140826171314.GA11793@pob.ytti.fi> Anyone can recommend or even just name drop network quality measurement kit? I'm only familiar with IP SLA, RPM and Creanord (and various inhouse tools:) What I'd like to see - 1us or better one-way jitter (no need for clock sync, just accurate clock) - tens or 100us one-way latency (as good as cheaply can get sync, ntp is ok) - 1us or better RTT - any-to-any measurement, not just hub<->spoke (or sufficiently cheap hub) - 100pps to 100 measurement points on 8 CoS (ish, less may be acceptable) - randomized payload pattern + verification (to catch bit mangling) - randomized sport/dport (to put traffic in each ECMP/LAG combo, long term) - programmatic accesss and useful documents to measurement data (e.g. some OSS TSDB) - high quality, fast, useful graphical reporting and alarming - support for TWAMP and OWAMP responders - indicative price <100kEUR CAPEX and <2000EUR YRC for 100 nodes solution -- ++ytti From brak at gameservers.com Tue Aug 26 17:31:23 2014 From: brak at gameservers.com (Brian Rak) Date: Tue, 26 Aug 2014 13:31:23 -0400 Subject: where to go to understand DDoS attack vector In-Reply-To: <53FCBB53.30505@flowtools.net> References: <53FC7410.9010203@meetinghouse.net> <1DDE300E-BAB9-4383-B87B-022F59AEA279@arbor.net> <53FC7B1F.9040409@meetinghouse.net> <53FC8B09.7080505@satchell.net> <7f2ce6cba805dc1fb6cd55d5416ca7c7@mail.gmail.com> <26AE7E96-8F1A-4709-8B16-C12A89A86F36@arbor.net> <53FCBB53.30505@flowtools.net> Message-ID: <53FCC46B.9070200@gameservers.com> On 8/26/2014 12:52 PM, me wrote: > > On 08/26/2014 07:58 AM, Roland Dobbins wrote: >> On Aug 26, 2014, at 8:37 PM, John York >> wrote: >> >>> In this case, 17 is both the protocol and port number. Confusing >>> coincidence :) >> Not in this output which the OP sent to the list: >> >>> 8:33:58.482193 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], >>> proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 >>> 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c >>> E..... at .8 .....;. >>> 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 >>> @^....i.....C... >>> 0x0020: 0000 0000 0000 0000 0000 0000 0000 >>> .............. >> >>> 18:33:58.482193 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], >>> proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 >>> 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c >>> E..... at .8 .....;. >>> 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 >>> @^....i.....C... >>> 0x0020: 0000 0000 0000 0000 0000 0000 0000 >>> .............. >>> 18:33:58.484625 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], >>> proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 >>> 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c >>> E..... at .8 .....;. >>> 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 >>> @^....i.....C... >>> 0x0020: 0000 0000 0000 0000 0000 0000 0000 >>> .............. >>> 18:33:58.486137 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], >>> proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 >>> 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c >>> E..... at .8 .....;. >>> 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 >>> @^....i.....C... >>> 0x0020: 0000 0000 0000 0000 0000 0000 0000 >>> .............. >> Source port 2072, destination port 27015. > > Been awhile since I got to dig into hex tcpdump but spent the time > anyway. A UDP data segment that is 9 bytes long and only contains a > "C" (0x43) ? And looks like to a Steam/Half-life (27015) gaming port. > Not sure what the "C" is used for with those systems but guessing it's > some sort of request? > It's pretty tough to say without knowing exactly what game is running there. While 27015 was originally used for Half Life, it's been used by a wide range of games at this point. Pretty much all the Valve games use this port, as well as a number of third party games that are based on the Steamworks SDK. Trying to figure out exactly what the game server thinks the packet is is not likely to help you figure out why it's being sent. You should instead be figuring out why your IPMI controller is compromised. It could also be reflection, 2072 is within the port range that is usually used for KVM or remote media by the IPMI controllers (though, they're usually TCP and not UDP). From james.sink at freedomvoice.com Tue Aug 26 17:37:53 2014 From: james.sink at freedomvoice.com (James Sink) Date: Tue, 26 Aug 2014 17:37:53 +0000 Subject: network quality measurement probes+reporting In-Reply-To: <20140826171314.GA11793@pob.ytti.fi> References: <20140826171314.GA11793@pob.ytti.fi> Message-ID: <30183fb3bbdc4dc2bbb16a7a446f4849@BL2PR08MB148.namprd08.prod.outlook.com> The licenses can get pricey, but AppNeta is worth a look. http://www.appneta.com/products/pathview/ -James -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Saku Ytti Sent: Tuesday, August 26, 2014 10:13 AM To: nanog at nanog.org Subject: network quality measurement probes+reporting Anyone can recommend or even just name drop network quality measurement kit? I'm only familiar with IP SLA, RPM and Creanord (and various inhouse tools:) What I'd like to see - 1us or better one-way jitter (no need for clock sync, just accurate clock) - tens or 100us one-way latency (as good as cheaply can get sync, ntp is ok) - 1us or better RTT - any-to-any measurement, not just hub<->spoke (or sufficiently cheap hub) - 100pps to 100 measurement points on 8 CoS (ish, less may be acceptable) - randomized payload pattern + verification (to catch bit mangling) - randomized sport/dport (to put traffic in each ECMP/LAG combo, long term) - programmatic accesss and useful documents to measurement data (e.g. some OSS TSDB) - high quality, fast, useful graphical reporting and alarming - support for TWAMP and OWAMP responders - indicative price <100kEUR CAPEX and <2000EUR YRC for 100 nodes solution -- ++ytti From mfidelman at meetinghouse.net Tue Aug 26 17:40:35 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 26 Aug 2014 13:40:35 -0400 Subject: where to go to understand DDoS attack vector In-Reply-To: <53FCBB53.30505@flowtools.net> References: <53FC7410.9010203@meetinghouse.net> <1DDE300E-BAB9-4383-B87B-022F59AEA279@arbor.net> <53FC7B1F.9040409@meetinghouse.net> <53FC8B09.7080505@satchell.net> <7f2ce6cba805dc1fb6cd55d5416ca7c7@mail.gmail.com> <26AE7E96-8F1A-4709-8B16-C12A89A86F36@arbor.net> <53FCBB53.30505@flowtools.net> Message-ID: <53FCC693.8020808@meetinghouse.net> me wrote: > > On 08/26/2014 07:58 AM, Roland Dobbins wrote: >> On Aug 26, 2014, at 8:37 PM, John York >> wrote: >> >>> In this case, 17 is both the protocol and port number. Confusing >>> coincidence :) >> Not in this output which the OP sent to the list: >> >>> 8:33:58.482193 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], >>> proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 >>> 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c >>> E..... at .8 .....;. >>> 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 >>> @^....i.....C... >>> 0x0020: 0000 0000 0000 0000 0000 0000 0000 >>> .............. >> >>> 18:33:58.482193 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], >>> proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 >>> 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c >>> E..... at .8 .....;. >>> 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 >>> @^....i.....C... >>> 0x0020: 0000 0000 0000 0000 0000 0000 0000 >>> .............. >>> 18:33:58.484625 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], >>> proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 >>> 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c >>> E..... at .8 .....;. >>> 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 >>> @^....i.....C... >>> 0x0020: 0000 0000 0000 0000 0000 0000 0000 >>> .............. >>> 18:33:58.486137 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], >>> proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 >>> 0x0000: 4500 001d 0000 4000 3811 088c cf9a 3b8c >>> E..... at .8 .....;. >>> 0x0010: 405e eebf 0818 6987 0009 10f8 4300 0000 >>> @^....i.....C... >>> 0x0020: 0000 0000 0000 0000 0000 0000 0000 >>> .............. >> Source port 2072, destination port 27015. > > Been awhile since I got to dig into hex tcpdump but spent the time > anyway. A UDP data segment that is 9 bytes long and only contains a > "C" (0x43) ? And looks like to a Steam/Half-life (27015) gaming port. > Not sure what the "C" is used for with those systems but guessing it's > some sort of request? > That's about as far as I've gotten. What has me scratching my head is what is setting the source port. This has all the earmarks of a reflection attack, except... I'm not running anything that presents as port 2072 (msync) - so either the attack is making very clever use of some other open server, or the board's BMC is infected by a bot. Unfortunately, with the port now blocked, and what was intermittent in any case - it's a little hard to monitor incoming traffic to see what might be trigger traffic. Sigh... Thanks, Miles From jloiacon at csc.com Tue Aug 26 18:02:30 2014 From: jloiacon at csc.com (Joe Loiacono) Date: Tue, 26 Aug 2014 14:02:30 -0400 Subject: network quality measurement probes+reporting In-Reply-To: <20140826171314.GA11793@pob.ytti.fi> References: <20140826171314.GA11793@pob.ytti.fi> Message-ID: Perhaps you've considered this already ... not sure if it gets 1us or not : bwctl? http://software.internet2.edu/bwctl/ Joe From: Saku Ytti To: nanog at nanog.org Date: 08/26/2014 01:15 PM Subject: network quality measurement probes+reporting Sent by: "NANOG" Anyone can recommend or even just name drop network quality measurement kit? I'm only familiar with IP SLA, RPM and Creanord (and various inhouse tools:) What I'd like to see - 1us or better one-way jitter (no need for clock sync, just accurate clock) - tens or 100us one-way latency (as good as cheaply can get sync, ntp is ok) - 1us or better RTT - any-to-any measurement, not just hub<->spoke (or sufficiently cheap hub) - 100pps to 100 measurement points on 8 CoS (ish, less may be acceptable) - randomized payload pattern + verification (to catch bit mangling) - randomized sport/dport (to put traffic in each ECMP/LAG combo, long term) - programmatic accesss and useful documents to measurement data (e.g. some OSS TSDB) - high quality, fast, useful graphical reporting and alarming - support for TWAMP and OWAMP responders - indicative price <100kEUR CAPEX and <2000EUR YRC for 100 nodes solution -- ++ytti From tarko at lanparty.ee Tue Aug 26 18:42:23 2014 From: tarko at lanparty.ee (Tarko Tikan) Date: Tue, 26 Aug 2014 21:42:23 +0300 Subject: network quality measurement probes+reporting In-Reply-To: <20140826171314.GA11793@pob.ytti.fi> References: <20140826171314.GA11793@pob.ytti.fi> Message-ID: <53FCD50F.9060701@lanparty.ee> hey, > - any-to-any measurement, not just hub<->spoke (or sufficiently cheap hub) May I add: - local data caching on probes (don't want to see holes in data if central collector/NMS is unavailable for short period) - DHCPv4/6 support with possibility to do periodic release/renew -- tarko From sliplever at gmail.com Tue Aug 26 18:42:53 2014 From: sliplever at gmail.com (Dan Snyder) Date: Tue, 26 Aug 2014 14:42:53 -0400 Subject: network quality measurement probes+reporting In-Reply-To: <20140826171314.GA11793@pob.ytti.fi> References: <20140826171314.GA11793@pob.ytti.fi> Message-ID: http://netbeez.net/ On Tue, Aug 26, 2014 at 1:13 PM, Saku Ytti wrote: > Anyone can recommend or even just name drop network quality measurement > kit? > > I'm only familiar with IP SLA, RPM and Creanord (and various inhouse > tools:) > > What I'd like to see > - 1us or better one-way jitter (no need for clock sync, just accurate > clock) > - tens or 100us one-way latency (as good as cheaply can get sync, ntp is > ok) > - 1us or better RTT > - any-to-any measurement, not just hub<->spoke (or sufficiently cheap > hub) > - 100pps to 100 measurement points on 8 CoS (ish, less may be acceptable) > - randomized payload pattern + verification (to catch bit mangling) > - randomized sport/dport (to put traffic in each ECMP/LAG combo, long > term) > - programmatic accesss and useful documents to measurement data (e.g. > some OSS TSDB) > - high quality, fast, useful graphical reporting and alarming > - support for TWAMP and OWAMP responders > - indicative price <100kEUR CAPEX and <2000EUR YRC for 100 nodes solution > > -- > ++ytti > From jw at nuclearfallout.net Tue Aug 26 19:37:12 2014 From: jw at nuclearfallout.net (John) Date: Tue, 26 Aug 2014 12:37:12 -0700 Subject: where to go to understand DDoS attack vector In-Reply-To: <53FCC693.8020808@meetinghouse.net> References: <53FC7410.9010203@meetinghouse.net> <1DDE300E-BAB9-4383-B87B-022F59AEA279@arbor.net> <53FC7B1F.9040409@meetinghouse.net> <53FC8B09.7080505@satchell.net> <7f2ce6cba805dc1fb6cd55d5416ca7c7@mail.gmail.com> <26AE7E96-8F1A-4709-8B16-C12A89A86F36@arbor.net> <53FCBB53.30505@flowtools.net> <53FCC693.8020808@meetinghouse.net> Message-ID: <53FCE1E8.2090500@nuclearfallout.net> On 8/26/2014 10:40 AM, Miles Fidelman wrote: > That's about as far as I've gotten. What has me scratching my head is > what is setting the source port. This has all the earmarks of a > reflection attack, except... I'm not running anything that presents as > port 2072 (msync) - so either the attack is making very clever use of > some other open server, or the board's BMC is infected by a bot. > Unfortunately, with the port now blocked, and what was intermittent in > any case - it's a little hard to monitor incoming traffic to see what > might be trigger traffic. Sigh... From the traffic dump and description, this was highly likely to be a direct attack and not an amplification/reflection hit. I don't know of reflectors that run on port 2072; but, bots are routinely used to send UDP length 29 (payload length 1) packets. Older Supermicro IPMI devices have multiple published exploits including the much-publicized port-49152 vulnerability that provides the admin password in the clear (described at http://blog.cari.net/carisirt-yet-another-bmc-vulnerability-and-some-added-extras/ and other places). Many device owners also never change the default u/p, in which case an exploit doesn't even need to be used. The attacker will typically use a tool to scan the IPv4 space for vulnerable hosts; the tool logs in and installs a bot that connects to a C&C server and is later used for attacks. The same procedure is followed with other easily-compromised devices, including Hikvision DVRs/NVRs and various routers including the Chinese Telecom F420. Resulting botnets can be tens or even hundreds of thousands of hosts in size. IPMI devices have been used quite regularly for attacks for a couple of months now -- as soon as that vulnerability was made public, the toolmakers started using it. The best defense against current and yet-to-be-discovered IPMI vulnerabilities is to make sure that your IPMI devices are not open to the public internet, as Roland said. -John From owen at delong.com Tue Aug 26 21:39:02 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Aug 2014 14:39:02 -0700 Subject: Urgent In-Reply-To: References: <0031d367e1b385685fedab145c2df48e@dizum.com> <7DB845D64966DC44A1CC592780539B4B011E00CD@nafmbx47.exchange.ford.com> <20140818175443.GA1953@srv03.cluenet.de> Message-ID: No, the God?s no longer listen on that address? Try FF0E::6:6:6 Owen On Aug 18, 2014, at 8:42 AM, Justin M. Streiner wrote: > On Mon, 18 Aug 2014, Daniel Roesen wrote: > >> Just send your request to the all-gods well-known multicast group. > > 224.6.6.6? > > jms > >> On Mon, Aug 18, 2014 at 05:20:48PM +0000, Kain, Rebecca (.) wrote: >>> Which one? >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of randy at psg.com >>> Sent: Monday, August 18, 2014 1:00 PM >>> To: nanog at nanog.org >>> Subject: Urgent >>> >>> Contact for God, please reach out to me offlist. >>> >>> Regards, >>> -AS666 NOC >> >> -- >> CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 >> From joesox at gmail.com Wed Aug 27 00:23:50 2014 From: joesox at gmail.com (JoeSox) Date: Tue, 26 Aug 2014 17:23:50 -0700 Subject: Cisco Tech needed in San Franscisco Message-ID: Hi Everyone, Took over a new network and they have no onsite Cisco tech help for one of my remote locations. Can someone email me directly a company I can contract with to get help this Wed night in downtown San Francisco (we can push maintenance to Friday night as well but shooting for tomorrow)? -- Thank You, Joe From larrysheldon at cox.net Wed Aug 27 00:28:45 2014 From: larrysheldon at cox.net (Larry Sheldon) Date: Tue, 26 Aug 2014 19:28:45 -0500 Subject: where to go to understand DDoS attack vector In-Reply-To: References: <53FC7410.9010203@meetinghouse.net> <1DDE300E-BAB9-4383-B87B-022F59AEA279@arbor.net> <53FC7B1F.9040409@meetinghouse.net> <53FC8B09.7080505@satchell.net> Message-ID: <53FD263D.5090002@cox.net> On 8/26/2014 08:31, Roland Dobbins wrote: > > On Aug 26, 2014, at 8:26 PM, Stephen Satchell wrote: > >> qotd 17/udp quote > > No, that's the protocol number - 17 is UDP - not the port number. Really? http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers udp DID used to be protocol 17, but it is a fact that quotd runs on udp port 17. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. From brak at gameservers.com Wed Aug 27 00:37:51 2014 From: brak at gameservers.com (Brian Rak) Date: Tue, 26 Aug 2014 20:37:51 -0400 Subject: where to go to understand DDoS attack vector In-Reply-To: <53FD263D.5090002@cox.net> References: <53FC7410.9010203@meetinghouse.net> <1DDE300E-BAB9-4383-B87B-022F59AEA279@arbor.net> <53FC7B1F.9040409@meetinghouse.net> <53FC8B09.7080505@satchell.net> <53FD263D.5090002@cox.net> Message-ID: <53FD285F.9070601@gameservers.com> On 8/26/2014 8:28 PM, Larry Sheldon wrote: > On 8/26/2014 08:31, Roland Dobbins wrote: >> >> On Aug 26, 2014, at 8:26 PM, Stephen Satchell wrote: >> >>> qotd 17/udp quote >> >> No, that's the protocol number - 17 is UDP - not the port number. > > > Really? > > http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers > > udp DID used to be protocol 17, but it is a fact that quotd runs on > udp port 17. > > Yes, he is correct. This is not UDP port 17. > 8:33:58.482193 IP (tos 0x0, ttl 56, id 0, offset 0, flags [DF], proto UDP (17), length 29) x.x.x.x.2072 > x.x.x.x.27015: UDP, length 1 Protocol: UDP (IP protocol 17) Source Port: 2072 Dest Port: 27015 What protocol is UDP now, if it's not 17? From owen at delong.com Wed Aug 27 00:42:31 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Aug 2014 17:42:31 -0700 Subject: Best US Tunnelbroker for Youtube In-Reply-To: References: <53F4B944.5050608@massar.ch> <53F4C20D.2010103@massar.ch> <53F4CFEA.40603@massar.ch> Message-ID: My understanding is that almost all of the Comcast network is now IPv6 capable. Owen On Aug 20, 2014, at 10:26 AM, Ryan Shea wrote: > Not sure I've seen any evidence (or implied) that the tunnel was the > problem. My issue as far as I know is at the application layer and other > end-user experiences seemed a reasonable way to pick a direction. I will > work with HE though and provide them some details. > > Agreed, from an end-user perspective it can be often be clear as mud > whether I am using v6, or whether my Chromecast or Android device even > implements happy eyeballs. The relatively new "experiencing problems?" > butter bar that shows up beneath a video with notable buffering problems > (even at low quality levels) sends the user through to details about the > service provider, in this case HE. Over the past couple years YouTube has > been my canary to know when I've received a new IP from Verizon and I need > to go fix my tunnel -- video loading takes fuuuuuuuurever on > Android/Chromecast/GoogleTV (which hints that happy eyeballs, if it exists > for Android, isn't working so well for the YouTube app). > > I can't get native v6 at my home -- I'm probably not in a particularly > unique situation. Not to rathole the dicsussion, but as far as I know (save > for some small DSL providers) unless I'm in a gFiber city or happen to be > in the portion of the Comcast network that provides native v6 I'm out of > luck. I don't plan on moving to solve this problem. > > > > On Wed, Aug 20, 2014 at 12:42 PM, Jeroen Massar wrote: > >> On 2014-08-20 18:21, Ryan Shea wrote: >>> IRC is a good suggestion, thanks. They'll likely be helpful. >>> >>> I see no indication of any throttling from my ISP - I can blast data at >>> full speed to my home from my server and work (with native v6 >>> connections). >> >> Does that path between your $home and $server go over the tunnel you >> find so "slow"? >> >> If so, then you have just nicely excluded that the tunnel is NOT the >> problem. >> >> Hence, why traceroutes would be so extremely useful. >> >> >>> Contacting my ISP (Verizon FiOS) is virtually never a >>> reasonable path to a solution. >> >> google(Verizon FiOS throttle) = 71.900 results. One would almost think >> that there might sometimes be issues there. >> >> Also, do realize that the IPv6 path you are using goes over a shared >> host (the Tunnel Broker PoP) that has IPv4 and IPv6 capacity that might >> be shared in various points of the paths your packets cross. >> >> Did you test at the same time of your "blast data" that the IPv6 Youtube >> was working fine? >> >> Another thing, as browsers now do "Happy Eyeballs" (which is really >> horrible to diagnose issues with on OSX), did you check if everything is >> really going over IPv6? (hence the tcpdump/wireshark). >> >> [..] >>> To be clear, I was seeking opinions/experiences on a list that was >>> likely to have a high occurrence of folk with v6 tunnels. >> >> Tunnels are for endusers who still are at ISPs who don't do IPv6 natively. >> >> NANOG has operators who have been running native IPv6 for over a decade. >> >> Hence, StackExchange might be useful for your purpose. >> >>> You have >>> etiquette suggestions, but not YouTube over tunnelbroker suggestions. I >>> apparently bring out your inner grump? Do you need a hug? >> >> My cat videos are streaming perfectly fine... >> >>> Burning Google engineering time would be a sub-optimal way to get HD cat >>> videos at home with the least time spent. >> >> Interesting, I was not aware they did not care about their eyeballs. >> >> Actually I am very confident lots of folks there would love to dig into >> your issue to actually resolve it. As when it is hitting you, it might >> hit other customers. >> >> Is that also not why there is this huge SRE department with lots of IPv6 >> knowledgeable folks? >> >> Greets, >> Jeroen >> >> From itg at itechgeek.com Wed Aug 27 01:17:14 2014 From: itg at itechgeek.com (ITechGeek) Date: Tue, 26 Aug 2014 21:17:14 -0400 Subject: Best US Tunnelbroker for Youtube In-Reply-To: References: <53F4B944.5050608@massar.ch> <53F4C20D.2010103@massar.ch> <53F4CFEA.40603@massar.ch> Message-ID: Someone was telling me this weekend their entire network is native dual stack now. I haven't had a chance to confirm it yet, but he said they are issuing /60's to residential users using DHCPv6. ----------------------------------------------------------------------------------------------- -ITG (ITechGeek) ITG at ITechGeek.Com https://itg.nu/ GPG Keys: https://itg.nu/contact/gpg-key Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: http://fb.me/Jbwa.Net On Tue, Aug 26, 2014 at 8:42 PM, Owen DeLong wrote: > My understanding is that almost all of the Comcast network is now IPv6 > capable. > > Owen > > On Aug 20, 2014, at 10:26 AM, Ryan Shea wrote: > > > Not sure I've seen any evidence (or implied) that the tunnel was the > > problem. My issue as far as I know is at the application layer and other > > end-user experiences seemed a reasonable way to pick a direction. I will > > work with HE though and provide them some details. > > > > Agreed, from an end-user perspective it can be often be clear as mud > > whether I am using v6, or whether my Chromecast or Android device even > > implements happy eyeballs. The relatively new "experiencing problems?" > > butter bar that shows up beneath a video with notable buffering problems > > (even at low quality levels) sends the user through to details about the > > service provider, in this case HE. Over the past couple years YouTube has > > been my canary to know when I've received a new IP from Verizon and I > need > > to go fix my tunnel -- video loading takes fuuuuuuuurever on > > Android/Chromecast/GoogleTV (which hints that happy eyeballs, if it > exists > > for Android, isn't working so well for the YouTube app). > > > > I can't get native v6 at my home -- I'm probably not in a particularly > > unique situation. Not to rathole the dicsussion, but as far as I know > (save > > for some small DSL providers) unless I'm in a gFiber city or happen to be > > in the portion of the Comcast network that provides native v6 I'm out of > > luck. I don't plan on moving to solve this problem. > > > > > > > > On Wed, Aug 20, 2014 at 12:42 PM, Jeroen Massar > wrote: > > > >> On 2014-08-20 18:21, Ryan Shea wrote: > >>> IRC is a good suggestion, thanks. They'll likely be helpful. > >>> > >>> I see no indication of any throttling from my ISP - I can blast data at > >>> full speed to my home from my server and work (with native v6 > >>> connections). > >> > >> Does that path between your $home and $server go over the tunnel you > >> find so "slow"? > >> > >> If so, then you have just nicely excluded that the tunnel is NOT the > >> problem. > >> > >> Hence, why traceroutes would be so extremely useful. > >> > >> > >>> Contacting my ISP (Verizon FiOS) is virtually never a > >>> reasonable path to a solution. > >> > >> google(Verizon FiOS throttle) = 71.900 results. One would almost think > >> that there might sometimes be issues there. > >> > >> Also, do realize that the IPv6 path you are using goes over a shared > >> host (the Tunnel Broker PoP) that has IPv4 and IPv6 capacity that might > >> be shared in various points of the paths your packets cross. > >> > >> Did you test at the same time of your "blast data" that the IPv6 Youtube > >> was working fine? > >> > >> Another thing, as browsers now do "Happy Eyeballs" (which is really > >> horrible to diagnose issues with on OSX), did you check if everything is > >> really going over IPv6? (hence the tcpdump/wireshark). > >> > >> [..] > >>> To be clear, I was seeking opinions/experiences on a list that was > >>> likely to have a high occurrence of folk with v6 tunnels. > >> > >> Tunnels are for endusers who still are at ISPs who don't do IPv6 > natively. > >> > >> NANOG has operators who have been running native IPv6 for over a decade. > >> > >> Hence, StackExchange might be useful for your purpose. > >> > >>> You have > >>> etiquette suggestions, but not YouTube over tunnelbroker suggestions. I > >>> apparently bring out your inner grump? Do you need a hug? > >> > >> My cat videos are streaming perfectly fine... > >> > >>> Burning Google engineering time would be a sub-optimal way to get HD > cat > >>> videos at home with the least time spent. > >> > >> Interesting, I was not aware they did not care about their eyeballs. > >> > >> Actually I am very confident lots of folks there would love to dig into > >> your issue to actually resolve it. As when it is hitting you, it might > >> hit other customers. > >> > >> Is that also not why there is this huge SRE department with lots of IPv6 > >> knowledgeable folks? > >> > >> Greets, > >> Jeroen > >> > >> > > From Valdis.Kletnieks at vt.edu Wed Aug 27 01:22:50 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 26 Aug 2014 21:22:50 -0400 Subject: Best US Tunnelbroker for Youtube In-Reply-To: Your message of "Tue, 26 Aug 2014 21:17:14 -0400." References: <53F4B944.5050608@massar.ch> <53F4C20D.2010103@massar.ch> <53F4CFEA.40603@massar.ch> Message-ID: <79179.1409102570@turing-police.cc.vt.edu> On Tue, 26 Aug 2014 21:17:14 -0400, ITechGeek said: > Someone was telling me this weekend their entire network is native dual > stack now. I haven't had a chance to confirm it yet, but he said they are > issuing /60's to residential users using DHCPv6. I believe the status is "every residential customer should be able to get a /60 via DHCPv6-PD". It's worked for me for a while, and somebody official from Comcast posted a while ago that they'd finished rolling out to 100% of the residential network. If it isn't working, it's time to complain (and hope you get a level-1 guy who knows what IPv6 is. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From itg at itechgeek.com Wed Aug 27 01:27:23 2014 From: itg at itechgeek.com (ITechGeek) Date: Tue, 26 Aug 2014 21:27:23 -0400 Subject: Best US Tunnelbroker for Youtube In-Reply-To: <79179.1409102570@turing-police.cc.vt.edu> References: <53F4B944.5050608@massar.ch> <53F4C20D.2010103@massar.ch> <53F4CFEA.40603@massar.ch> <79179.1409102570@turing-police.cc.vt.edu> Message-ID: On Tue, Aug 26, 2014 at 9:22 PM, wrote: > hope you > get a level-1 guy who knows what IPv6 is > Is that possible? ----------------------------------------------------------------------------------------------- -ITG (ITechGeek) ITG at ITechGeek.Com https://itg.nu/ GPG Keys: https://itg.nu/contact/gpg-key Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: http://fb.me/Jbwa.Net From marka at isc.org Wed Aug 27 01:28:56 2014 From: marka at isc.org (Mark Andrews) Date: Wed, 27 Aug 2014 11:28:56 +1000 Subject: Best US Tunnelbroker for Youtube In-Reply-To: Your message of "Tue, 26 Aug 2014 21:17:14 -0400." References: <53F4B944.5050608@massar.ch> <53F4C20D.2010103@massar.ch> <53F4CFEA.40603@massar.ch> Message-ID: <20140827012856.28BDC1D9F4EA@rock.dv.isc.org> In message , ITechGeek writes: > Someone was telling me this weekend their entire network is native dual > stack now. I haven't had a chance to confirm it yet, but he said they are > issuing /60's to residential users using DHCPv6. The residential network in fully IPv6 capable. The commercial network is still a work in progress. This is based on the last notice I saw from Comcast. Mark > ----------------------------------------------------------------------------- > ------------------ > -ITG (ITechGeek) > ITG at ITechGeek.Com > https://itg.nu/ > GPG Keys: https://itg.nu/contact/gpg-key > Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A > Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: > http://fb.me/Jbwa.Net > > > On Tue, Aug 26, 2014 at 8:42 PM, Owen DeLong wrote: > > > My understanding is that almost all of the Comcast network is now IPv6 > > capable. > > > > Owen > > > > On Aug 20, 2014, at 10:26 AM, Ryan Shea wrote: > > > > > Not sure I've seen any evidence (or implied) that the tunnel was the > > > problem. My issue as far as I know is at the application layer and other > > > end-user experiences seemed a reasonable way to pick a direction. I will > > > work with HE though and provide them some details. > > > > > > Agreed, from an end-user perspective it can be often be clear as mud > > > whether I am using v6, or whether my Chromecast or Android device even > > > implements happy eyeballs. The relatively new "experiencing problems?" > > > butter bar that shows up beneath a video with notable buffering problems > > > (even at low quality levels) sends the user through to details about the > > > service provider, in this case HE. Over the past couple years YouTube has > > > been my canary to know when I've received a new IP from Verizon and I > > need > > > to go fix my tunnel -- video loading takes fuuuuuuuurever on > > > Android/Chromecast/GoogleTV (which hints that happy eyeballs, if it > > exists > > > for Android, isn't working so well for the YouTube app). > > > > > > I can't get native v6 at my home -- I'm probably not in a particularly > > > unique situation. Not to rathole the dicsussion, but as far as I know > > (save > > > for some small DSL providers) unless I'm in a gFiber city or happen to be > > > in the portion of the Comcast network that provides native v6 I'm out of > > > luck. I don't plan on moving to solve this problem. > > > > > > > > > > > > On Wed, Aug 20, 2014 at 12:42 PM, Jeroen Massar > > wrote: > > > > > >> On 2014-08-20 18:21, Ryan Shea wrote: > > >>> IRC is a good suggestion, thanks. They'll likely be helpful. > > >>> > > >>> I see no indication of any throttling from my ISP - I can blast data at > > >>> full speed to my home from my server and work (with native v6 > > >>> connections). > > >> > > >> Does that path between your $home and $server go over the tunnel you > > >> find so "slow"? > > >> > > >> If so, then you have just nicely excluded that the tunnel is NOT the > > >> problem. > > >> > > >> Hence, why traceroutes would be so extremely useful. > > >> > > >> > > >>> Contacting my ISP (Verizon FiOS) is virtually never a > > >>> reasonable path to a solution. > > >> > > >> google(Verizon FiOS throttle) = 71.900 results. One would almost think > > >> that there might sometimes be issues there. > > >> > > >> Also, do realize that the IPv6 path you are using goes over a shared > > >> host (the Tunnel Broker PoP) that has IPv4 and IPv6 capacity that might > > >> be shared in various points of the paths your packets cross. > > >> > > >> Did you test at the same time of your "blast data" that the IPv6 Youtube > > >> was working fine? > > >> > > >> Another thing, as browsers now do "Happy Eyeballs" (which is really > > >> horrible to diagnose issues with on OSX), did you check if everything is > > >> really going over IPv6? (hence the tcpdump/wireshark). > > >> > > >> [..] > > >>> To be clear, I was seeking opinions/experiences on a list that was > > >>> likely to have a high occurrence of folk with v6 tunnels. > > >> > > >> Tunnels are for endusers who still are at ISPs who don't do IPv6 > > natively. > > >> > > >> NANOG has operators who have been running native IPv6 for over a decade. > > >> > > >> Hence, StackExchange might be useful for your purpose. > > >> > > >>> You have > > >>> etiquette suggestions, but not YouTube over tunnelbroker suggestions. I > > >>> apparently bring out your inner grump? Do you need a hug? > > >> > > >> My cat videos are streaming perfectly fine... > > >> > > >>> Burning Google engineering time would be a sub-optimal way to get HD > > cat > > >>> videos at home with the least time spent. > > >> > > >> Interesting, I was not aware they did not care about their eyeballs. > > >> > > >> Actually I am very confident lots of folks there would love to dig into > > >> your issue to actually resolve it. As when it is hitting you, it might > > >> hit other customers. > > >> > > >> Is that also not why there is this huge SRE department with lots of IPv6 > > >> knowledgeable folks? > > >> > > >> Greets, > > >> Jeroen > > >> > > >> > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jra at baylink.com Wed Aug 27 02:29:26 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 26 Aug 2014 22:29:26 -0400 (EDT) Subject: DC opinions? Message-ID: <24974266.10083.1409106566545.JavaMail.root@benjamin.baylink.com> Anyone in Centurylink Ashburn or Seattle? Do you have an opinion? Customary protocols apply. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From joesox at gmail.com Wed Aug 27 03:25:16 2014 From: joesox at gmail.com (JoeSox) Date: Tue, 26 Aug 2014 20:25:16 -0700 Subject: Cisco Tech needed in San Franscisco In-Reply-To: References: Message-ID: Thanks everyone. I have some good leads. and FYI, I learned about this NANOG page :) http://nanog.cluepon.net/index.php/Hands -- Thank You, Joe On Tue, Aug 26, 2014 at 5:23 PM, JoeSox wrote: > Hi Everyone, > Took over a new network and they have no onsite Cisco tech help for one of > my remote locations. > Can someone email me directly a company I can contract with to get help > this Wed night in downtown San Francisco (we can push maintenance to Friday > night as well but shooting for tomorrow)? > > -- > Thank You, Joe > From koalafil at gmail.com Wed Aug 27 09:16:41 2014 From: koalafil at gmail.com (Filiz Yilmaz) Date: Wed, 27 Aug 2014 11:16:41 +0200 Subject: Fwd: Call for Presentations RIPE 69 In-Reply-To: References: Message-ID: Dear Colleagues, Please note the approaching RIPE 69 deadline, 31 August 2014. Kind regards Filiz Yilmaz RIPE PC Chair http://www.ripe.net/ripe/meetings/ripe-meetings/pc ---------- Forwarded message ---------- From: Filiz Yilmaz Date: Wed, Jun 11, 2014 at 5:48 PM Subject: Call for Presentations RIPE 69 To: "ripe-list at ripe.net" , "nanog at nanog.org" < nanog at nanog.org> Dear colleagues, Please find the CFP for RIPE 69 in London below. The deadline for submissions is 31 August 2014. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards Filiz Yilmaz RIPE PC Chair http://www.ripe.net/ripe/meetings/ripe-meetings/pc --------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 69 will take place from 3- November 2014 in London, UK. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary session presentations, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 69. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: ? IPv6 deployment ? Managing IPv4 scarcity in operations ? Commercial transactions of IPv4 addresses ? Data centre technologies ? Network and DNS operations ? Internet governance and regulatory practices ? Network and routing security ? Content delivery ? Internet peering and mobile data exchange Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. The RIPE PC accepts proposals for different presentation formats, including plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. See the full descriptions of these formats at https://ripe69.ripe.net/submit-topic/presentation-formats/ Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. In addition to presentations selected in advance for the plenary, the RIPE PC also offers several time slots for ?lightning talks?, which are selected immediately before or during the conference. The following general requirements apply: - Proposals for plenary session presentations, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 31 August 2014, using the meeting submission system at https://ripe69.ripe.net/submit-topic/guidelines/. Proposals submitted after this date will be considered on a space-available basis. - Lightning talks should also be submitted using the meeting submission system (https://ripe69.ripe.net/submit-topic/submission-form/) and can be submitted just days before the RIPE Meeting starts or even during the meeting week. The allocation of lightning talk slots will be announced in short notice ? in some cases on the same day but often one day prior to the relevant session. - Presenters should indicate how much time they will require. See more information on time slot allocations per presentation format at https://ripe69.ripe.net/submit-topic/presentation-formats/ - Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panelists, presenters and moderators. - Due to potential technical issues, it is expected that most, if not all, presenters/panelists will be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. --------------------- From cristel at iij.ad.jp Wed Aug 27 09:18:16 2014 From: cristel at iij.ad.jp (Pelsser Cristel) Date: Wed, 27 Aug 2014 18:18:16 +0900 Subject: RPKI Message-ID: <28935530-986E-4052-B36C-9D3AFE206750@iij.ad.jp> Hi, With Daniele Iamartino, we are validating BGP routes with the objects stored in the RPKI. On 2014/07/26, for the routes at the LINX RouteViews monitor, we observe the following set of prefixes that are announced both with the correct origin AS and a wrong origin AS. There are very few of them. We believe they could be anycast where there is no ROA for some origin ASs or they could be misconfiguration/attacks. RIB Dump time: 2014/08/26 08:00 UTC prefix,valid AS,invalid AS 5.128.0.0/14,31200,50923 37.19.8.0/21,49964,198585 94.199.232.0/21,49413,5089 179.61.194.0/23,61440,37692 190.94.182.0/24,262195,18678 193.42.215.0/24,30880,50827 193.227.174.0/24,9051,24634 195.69.144.0/22,1200,41313 200.35.183.0/24,26617,27742 213.192.242.0/23,8903,12541 217.113.242.0/24,197860,20721 217.113.244.0/24,197860,20721 217.113.245.0/24,20721,197860 2a02:2928::/32,39288,197530 Prefixes containing private AS numbers prefix,valid AS,invalid AS 176.56.192.0/19,8426,65489 185.36.76.0/22,8426,65489 194.45.46.0/24,286,64951 2a00:fd00::/32,29695,65026 Any feedback is welcome, Cristel From dhubbard at dino.hostasaurus.com Wed Aug 27 10:17:00 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 27 Aug 2014 06:17:00 -0400 Subject: Time Warner outage? Message-ID: Hey all, anyone else having issues with Time Warner residential or business connections? One of our offices is down and the route is not currently in bgp. http://downdetector.com/status/time-warner-cable shows thousands of reports of outages on the consumer side starting an hour or so ago so I figure it's a larger issue than just my one office; couldn't reach anyone by phone. Thanks, David From rob.barbeau at gmail.com Wed Aug 27 10:28:07 2014 From: rob.barbeau at gmail.com (Rob Barbeau) Date: Wed, 27 Aug 2014 05:28:07 -0500 Subject: Time Warner outage? In-Reply-To: References: Message-ID: David, I have a branch office in Syracuse,NY that appears to be down at the moment that uses a time warner business connection for internet access. -rob On Aug 27, 2014 5:20 AM, "David Hubbard" wrote: > Hey all, anyone else having issues with Time Warner residential or > business connections? One of our offices is down and the route is not > currently in bgp. http://downdetector.com/status/time-warner-cable > shows thousands of reports of outages on the consumer side starting an > hour or so ago so I figure it's a larger issue than just my one office; > couldn't reach anyone by phone. > > Thanks, > > David > From david at davidcoulson.net Wed Aug 27 10:39:08 2014 From: david at davidcoulson.net (David Coulson) Date: Wed, 27 Aug 2014 06:39:08 -0400 Subject: Time Warner outage? In-Reply-To: References: Message-ID: <28DA213A-D9FD-4E2A-8CB7-41896A14C684@davidcoulson.net> I've have residential twc in Cleveland. My router has an ip in the 104.139.34/24 network that isn't being advertised via bgp anymore either. I can still trace route out from here half a dozen hops, so seems like an edge/peering issue somewhere. Sent from my iPad > On Aug 27, 2014, at 6:17 AM, David Hubbard wrote: > > Hey all, anyone else having issues with Time Warner residential or > business connections? One of our offices is down and the route is not > currently in bgp. http://downdetector.com/status/time-warner-cable > shows thousands of reports of outages on the consumer side starting an > hour or so ago so I figure it's a larger issue than just my one office; > couldn't reach anyone by phone. > > Thanks, > > David From coloccia at geneseo.edu Wed Aug 27 10:43:12 2014 From: coloccia at geneseo.edu (Rick Coloccia) Date: Wed, 27 Aug 2014 06:43:12 -0400 Subject: Time Warner outage? In-Reply-To: References: Message-ID: My whole campus (~10000 users) is down... Since roughly 6am. TWC is our upstream. -- Sent from my iPhone > On Aug 27, 2014, at 6:28 AM, Rob Barbeau wrote: > > David, > > I have a branch office in Syracuse,NY that appears to be down at the moment > that uses a time warner business connection for internet access. > > -rob > On Aug 27, 2014 5:20 AM, "David Hubbard" > wrote: > >> Hey all, anyone else having issues with Time Warner residential or >> business connections? One of our offices is down and the route is not >> currently in bgp. http://downdetector.com/status/time-warner-cable >> shows thousands of reports of outages on the consumer side starting an >> hour or so ago so I figure it's a larger issue than just my one office; >> couldn't reach anyone by phone. >> >> Thanks, >> >> David >> From maillist at webjogger.net Wed Aug 27 10:46:17 2014 From: maillist at webjogger.net (Adam Greene) Date: Wed, 27 Aug 2014 06:46:17 -0400 Subject: Time Warner outage? In-Reply-To: References: Message-ID: <006201cfc1e4$21507920$63f16b60$@webjogger.net> Same here. Seems like no traffic is exiting TWC: Tracing route to ns03.savvis.net [204.70.25.234] over a maximum of 30 hops: 1 1 ms 1 ms 1 ms 10049.webjogger.net [204.8.80.49] 2 27 ms 6 ms 5 ms cpe-24-29-112-25.nyc.res.rr.com [24.29.112.25] 3 12 ms 8 ms 7 ms rdc-69-193-225-74.nyc.bc.twcable.com [69.193.225.74] 4 9 ms 9 ms 12 ms rdc-69-193-225-137.nyc.bc.twcable.com [69.193.225.137] 5 9 ms 10 ms 8 ms rdc-69-193-225-222.nyc.bc.twcable.com [69.193.225.222] 6 * * * Request timed out. 7 * * * Request timed out. 8 * * * Request timed out. 9 * * * Request timed out. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rick Coloccia Sent: Wednesday, August 27, 2014 6:43 AM To: nanog at nanog.org Subject: Re: Time Warner outage? My whole campus (~10000 users) is down... Since roughly 6am. TWC is our upstream. -- Sent from my iPhone > On Aug 27, 2014, at 6:28 AM, Rob Barbeau wrote: > > David, > > I have a branch office in Syracuse,NY that appears to be down at the > moment that uses a time warner business connection for internet access. > > -rob > On Aug 27, 2014 5:20 AM, "David Hubbard" > > wrote: > >> Hey all, anyone else having issues with Time Warner residential or >> business connections? One of our offices is down and the route is >> not currently in bgp. >> http://downdetector.com/status/time-warner-cable >> shows thousands of reports of outages on the consumer side starting >> an hour or so ago so I figure it's a larger issue than just my one >> office; couldn't reach anyone by phone. >> >> Thanks, >> >> David >> From coloccia at geneseo.edu Wed Aug 27 10:48:29 2014 From: coloccia at geneseo.edu (Rick Coloccia) Date: Wed, 27 Aug 2014 06:48:29 -0400 Subject: Time Warner outage? In-Reply-To: <006201cfc1e4$21507920$63f16b60$@webjogger.net> References: <006201cfc1e4$21507920$63f16b60$@webjogger.net> Message-ID: <90344B7A-BF8A-40B8-A3C5-EA3991F5351D@geneseo.edu> BGPMON shows my routes falling off the net at around 5:49am. We now sit at their mercy.... -- Sent from my iPhone > On Aug 27, 2014, at 6:46 AM, "Adam Greene" wrote: > > Same here. Seems like no traffic is exiting TWC: > > Tracing route to ns03.savvis.net [204.70.25.234] > over a maximum of 30 hops: > > 1 1 ms 1 ms 1 ms 10049.webjogger.net [204.8.80.49] > 2 27 ms 6 ms 5 ms cpe-24-29-112-25.nyc.res.rr.com > [24.29.112.25] > 3 12 ms 8 ms 7 ms rdc-69-193-225-74.nyc.bc.twcable.com > [69.193.225.74] > 4 9 ms 9 ms 12 ms rdc-69-193-225-137.nyc.bc.twcable.com > [69.193.225.137] > 5 9 ms 10 ms 8 ms rdc-69-193-225-222.nyc.bc.twcable.com > [69.193.225.222] > 6 * * * Request timed out. > 7 * * * Request timed out. > 8 * * * Request timed out. > 9 * * * Request timed out. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rick Coloccia > Sent: Wednesday, August 27, 2014 6:43 AM > To: nanog at nanog.org > Subject: Re: Time Warner outage? > > My whole campus (~10000 users) is down... Since roughly 6am. TWC is our > upstream. > > -- > Sent from my iPhone > >> On Aug 27, 2014, at 6:28 AM, Rob Barbeau wrote: >> >> David, >> >> I have a branch office in Syracuse,NY that appears to be down at the >> moment that uses a time warner business connection for internet access. >> >> -rob >> On Aug 27, 2014 5:20 AM, "David Hubbard" >> >> wrote: >> >>> Hey all, anyone else having issues with Time Warner residential or >>> business connections? One of our offices is down and the route is >>> not currently in bgp. >>> http://downdetector.com/status/time-warner-cable >>> shows thousands of reports of outages on the consumer side starting >>> an hour or so ago so I figure it's a larger issue than just my one >>> office; couldn't reach anyone by phone. >>> >>> Thanks, >>> >>> David > From david at davidcoulson.net Wed Aug 27 10:59:29 2014 From: david at davidcoulson.net (David Coulson) Date: Wed, 27 Aug 2014 06:59:29 -0400 Subject: Time Warner outage? In-Reply-To: <90344B7A-BF8A-40B8-A3C5-EA3991F5351D@geneseo.edu> References: <006201cfc1e4$21507920$63f16b60$@webjogger.net> <90344B7A-BF8A-40B8-A3C5-EA3991F5351D@geneseo.edu> Message-ID: Just came back up for me. Sent from my iPad > On Aug 27, 2014, at 6:48 AM, Rick Coloccia wrote: > > BGPMON shows my routes falling off the net at around 5:49am. > > We now sit at their mercy.... > > > -- > Sent from my iPhone > >> On Aug 27, 2014, at 6:46 AM, "Adam Greene" wrote: >> >> Same here. Seems like no traffic is exiting TWC: >> >> Tracing route to ns03.savvis.net [204.70.25.234] >> over a maximum of 30 hops: >> >> 1 1 ms 1 ms 1 ms 10049.webjogger.net [204.8.80.49] >> 2 27 ms 6 ms 5 ms cpe-24-29-112-25.nyc.res.rr.com >> [24.29.112.25] >> 3 12 ms 8 ms 7 ms rdc-69-193-225-74.nyc.bc.twcable.com >> [69.193.225.74] >> 4 9 ms 9 ms 12 ms rdc-69-193-225-137.nyc.bc.twcable.com >> [69.193.225.137] >> 5 9 ms 10 ms 8 ms rdc-69-193-225-222.nyc.bc.twcable.com >> [69.193.225.222] >> 6 * * * Request timed out. >> 7 * * * Request timed out. >> 8 * * * Request timed out. >> 9 * * * Request timed out. >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rick Coloccia >> Sent: Wednesday, August 27, 2014 6:43 AM >> To: nanog at nanog.org >> Subject: Re: Time Warner outage? >> >> My whole campus (~10000 users) is down... Since roughly 6am. TWC is our >> upstream. >> >> -- >> Sent from my iPhone >> >>> On Aug 27, 2014, at 6:28 AM, Rob Barbeau wrote: >>> >>> David, >>> >>> I have a branch office in Syracuse,NY that appears to be down at the >>> moment that uses a time warner business connection for internet access. >>> >>> -rob >>> On Aug 27, 2014 5:20 AM, "David Hubbard" >>> >>> wrote: >>> >>>> Hey all, anyone else having issues with Time Warner residential or >>>> business connections? One of our offices is down and the route is >>>> not currently in bgp. >>>> http://downdetector.com/status/time-warner-cable >>>> shows thousands of reports of outages on the consumer side starting >>>> an hour or so ago so I figure it's a larger issue than just my one >>>> office; couldn't reach anyone by phone. >>>> >>>> Thanks, >>>> >>>> David >> From maillist at webjogger.net Wed Aug 27 12:05:08 2014 From: maillist at webjogger.net (Adam Greene) Date: Wed, 27 Aug 2014 08:05:08 -0400 Subject: Time Warner outage? In-Reply-To: References: <006201cfc1e4$21507920$63f16b60$@webjogger.net> <90344B7A-BF8A-40B8-A3C5-EA3991F5351D@geneseo.edu> Message-ID: <001b01cfc1ef$253cf490$6fb6ddb0$@webjogger.net> Came back for us, too, at about 7am. Outage was a biggie this time: https://news.yahoo.com/time-warner-cable-suffering-massive-nationwide-outage -110549606.html -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Coulson Sent: Wednesday, August 27, 2014 6:59 AM To: Rick Coloccia Cc: Subject: Re: Time Warner outage? Just came back up for me. Sent from my iPad > On Aug 27, 2014, at 6:48 AM, Rick Coloccia wrote: > > BGPMON shows my routes falling off the net at around 5:49am. > > We now sit at their mercy.... > > > -- > Sent from my iPhone > >> On Aug 27, 2014, at 6:46 AM, "Adam Greene" wrote: >> >> Same here. Seems like no traffic is exiting TWC: >> >> Tracing route to ns03.savvis.net [204.70.25.234] over a maximum of 30 >> hops: >> >> 1 1 ms 1 ms 1 ms 10049.webjogger.net [204.8.80.49] >> 2 27 ms 6 ms 5 ms cpe-24-29-112-25.nyc.res.rr.com >> [24.29.112.25] >> 3 12 ms 8 ms 7 ms rdc-69-193-225-74.nyc.bc.twcable.com >> [69.193.225.74] >> 4 9 ms 9 ms 12 ms rdc-69-193-225-137.nyc.bc.twcable.com >> [69.193.225.137] >> 5 9 ms 10 ms 8 ms rdc-69-193-225-222.nyc.bc.twcable.com >> [69.193.225.222] >> 6 * * * Request timed out. >> 7 * * * Request timed out. >> 8 * * * Request timed out. >> 9 * * * Request timed out. >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rick >> Coloccia >> Sent: Wednesday, August 27, 2014 6:43 AM >> To: nanog at nanog.org >> Subject: Re: Time Warner outage? >> >> My whole campus (~10000 users) is down... Since roughly 6am. TWC is >> our upstream. >> >> -- >> Sent from my iPhone >> >>> On Aug 27, 2014, at 6:28 AM, Rob Barbeau wrote: >>> >>> David, >>> >>> I have a branch office in Syracuse,NY that appears to be down at the >>> moment that uses a time warner business connection for internet access. >>> >>> -rob >>> On Aug 27, 2014 5:20 AM, "David Hubbard" >>> >>> wrote: >>> >>>> Hey all, anyone else having issues with Time Warner residential or >>>> business connections? One of our offices is down and the route is >>>> not currently in bgp. >>>> http://downdetector.com/status/time-warner-cable >>>> shows thousands of reports of outages on the consumer side starting >>>> an hour or so ago so I figure it's a larger issue than just my one >>>> office; couldn't reach anyone by phone. >>>> >>>> Thanks, >>>> >>>> David >> From jra at baylink.com Wed Aug 27 13:56:28 2014 From: jra at baylink.com (Jay Ashworth) Date: Wed, 27 Aug 2014 09:56:28 -0400 Subject: Time Warner outage? In-Reply-To: References: Message-ID: <685aa378-35f3-46ab-aac7-1480cafb6ff1@email.android.com> I had a CNN breaking news email on my phone about this when I woke up, their backbone apparently was down from 2 ish to 4 ish AM. On August 27, 2014 6:17:00 AM EDT, David Hubbard wrote: >Hey all, anyone else having issues with Time Warner residential or >business connections? One of our offices is down and the route is not >currently in bgp. http://downdetector.com/status/time-warner-cable >shows thousands of reports of outages on the consumer side starting an >hour or so ago so I figure it's a larger issue than just my one office; >couldn't reach anyone by phone. > >Thanks, > >David -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From Kevin.Irwin at cinbell.com Wed Aug 27 14:34:12 2014 From: Kevin.Irwin at cinbell.com (Irwin, Kevin) Date: Wed, 27 Aug 2014 14:34:12 +0000 Subject: Time Warner outage? In-Reply-To: <685aa378-35f3-46ab-aac7-1480cafb6ff1@email.android.com> Message-ID: TCAM? Those of you with TW, how many routes are they advertising to you via BGP? Kevin On 8/27/14, 9:56 AM, "Jay Ashworth" wrote: >I had a CNN breaking news email on my phone about this when I woke up, >their backbone apparently was down from 2 ish to 4 ish AM. > >On August 27, 2014 6:17:00 AM EDT, David Hubbard > wrote: >>Hey all, anyone else having issues with Time Warner residential or >>business connections? One of our offices is down and the route is not >>currently in bgp. http://downdetector.com/status/time-warner-cable >>shows thousands of reports of outages on the consumer side starting an >>hour or so ago so I figure it's a larger issue than just my one office; >>couldn't reach anyone by phone. >> >>Thanks, >> >>David > >-- >Sent from my Android phone with K-9 Mail. Please excuse my brevity. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and destroy any copies of this document. From nick at wiredmedium.com Wed Aug 27 15:01:09 2014 From: nick at wiredmedium.com (Nick) Date: Wed, 27 Aug 2014 10:01:09 -0500 Subject: centurylink chi2 and level3 -- network issues Message-ID: <53FDF2B5.2060304@wiredmedium.com> Is anyone else having network issue over the past week with centurylink and their peer level3? I spoke with centurylinks noc team. They are not being helpful and blame level3. I'm seeing period of high packet loss and poor throughput speeds. From what I can tell. Its a problem between qwest and level3 border routers. Host Loss% Snt Last Avg Best Wrst StDev .... 2. cer-core-02.inet.qwest.net 0.0% 663 0.5 0.8 0.4 35.0 2.9 3. vlan52.ebr2.Chicago2.Level3.net 2.7% 662 196.0 196.5 192.2 209.2 1.5 4. ??? 5. ae-46-46.ebr2.Washington1.Level3 1.8% 662 196.8 196.0 191.2 201.1 1.1 .... [not the complete traceroute] At the moment, I moved most of my traffic from centurylink. The remaining services are being greatly impacted by the poor network performance. What do you think my next steps should be? Any advice would be greatly appreciated. - Nick From sml at lordsargon.com Wed Aug 27 15:09:46 2014 From: sml at lordsargon.com (SML) Date: Wed, 27 Aug 2014 10:09:46 -0500 Subject: centurylink chi2 and level3 -- network issues In-Reply-To: <53FDF2B5.2060304@wiredmedium.com> References: <53FDF2B5.2060304@wiredmedium.com> Message-ID: On 27 Aug 2014, at 10:01, Nick wrote: > Is anyone else having network issue over the past week with > centurylink and their peer level3? > > I spoke with centurylinks noc team. They are not being helpful and > blame level3. I'm seeing period of high packet loss and poor > throughput speeds. From what I can tell. Its a problem between qwest > and level3 border routers. CL is an upstream of our provider. We complained about this to our provider, and our upstream complained to CL. CL's response was that this is an oversubscription problem due to a CL customer violating its ToS, and CL's lawyers were involved. That was two or three months ago. ...sigh... From chris at aperturefiber.com Wed Aug 27 15:27:49 2014 From: chris at aperturefiber.com (Chris Garrett) Date: Wed, 27 Aug 2014 10:27:49 -0500 Subject: Time Warner outage? In-Reply-To: References: Message-ID: The issue reported on our side was impact to TW from a L3 maintenance that caused the issue. No details beyond that to share unfortunately On Aug 27, 2014, at 9:34 AM, Irwin, Kevin wrote: > TCAM? Those of you with TW, how many routes are they advertising to you > via BGP? > > Kevin > > > > On 8/27/14, 9:56 AM, "Jay Ashworth" wrote: > >> I had a CNN breaking news email on my phone about this when I woke up, >> their backbone apparently was down from 2 ish to 4 ish AM. >> >> On August 27, 2014 6:17:00 AM EDT, David Hubbard >> wrote: >>> Hey all, anyone else having issues with Time Warner residential or >>> business connections? One of our offices is down and the route is not >>> currently in bgp. http://downdetector.com/status/time-warner-cable >>> shows thousands of reports of outages on the consumer side starting an >>> hour or so ago so I figure it's a larger issue than just my one office; >>> couldn't reach anyone by phone. >>> >>> Thanks, >>> >>> David >> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and destroy any copies of this document. > From merike at doubleshotsecurity.com Wed Aug 27 19:47:01 2014 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Wed, 27 Aug 2014 12:47:01 -0700 Subject: Ebay/Paypal blocking HTTP access based on SORBS DUHL / Spamhaus PBL In-Reply-To: <53F64DAC.2000307@lanparty.ee> References: <20140821161546.31920.qmail@joyce.lan> <53F64DAC.2000307@lanparty.ee> Message-ID: <6237C7AD-9293-49F9-BBDA-5D1968D8696E@doubleshotsecurity.com> On Aug 21, 2014, at 12:51 PM, Tarko Tikan wrote: > hey, > >> My home IP is in both the PBL and the SORBS DUL and I have no trouble >> using ebay or paypal. > > Thanks for confirmation. > >> Given that the problem range is in Estonia, I expect that it's some >> combination of abuse from the specific range and general issues with >> traffic from Estonia. > > What makes you say that? Any specific examples of trouble you are getting from Estonian networks? Yeah - funny?it's been years since I heard of specific Estonian issues (and caveat - I am estonian and know Tarko). Back in 2007 there were plenty of problems but many have been cleaned up. Some took a few years. Tarko - have you got this resolved yet? If not, send me private email and I'll get you connected with additional people who may be able to help. - merike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tarko at lanparty.ee Wed Aug 27 19:52:31 2014 From: tarko at lanparty.ee (Tarko Tikan) Date: Wed, 27 Aug 2014 22:52:31 +0300 Subject: Ebay/Paypal blocking HTTP access based on SORBS DUHL / Spamhaus PBL In-Reply-To: <6237C7AD-9293-49F9-BBDA-5D1968D8696E@doubleshotsecurity.com> References: <20140821161546.31920.qmail@joyce.lan> <53F64DAC.2000307@lanparty.ee> <6237C7AD-9293-49F9-BBDA-5D1968D8696E@doubleshotsecurity.com> Message-ID: <53FE36FF.50108@lanparty.ee> hey, > Yeah - funny?it's been years since I heard of specific Estonian issues (and caveat - I am estonian and know > Tarko). Back in 2007 there were plenty of problems but many have been cleaned up. Some took a few years. Still waiting for examples. I can say for sure that none of the major operators in Estonia are spam friendly (and or ignore abuse related issues. There might be one or two hosting/content operators, mostly with Russian origins, but even they have grown up. I'm well connected in local community - if you do have specific complaints, let me know. > Tarko - have you got this resolved yet? Nope :( -- tarko From ryanruuska+nanog at gmail.com Mon Aug 25 17:54:17 2014 From: ryanruuska+nanog at gmail.com (Ryan Ruuska) Date: Mon, 25 Aug 2014 12:54:17 -0500 Subject: Verizon connectivity issues Message-ID: Hello all, We have heard from many of our customers in the Northeast region, specifically PA, MD, and VA who have difficulty connecting to our website (very slow loading times). We have noticed that if our data center provider specifically routes our outbound traffic over Hurricane Electric rather than XO Communications, that connectivity is restored to normal for our customers. The HE path goes from Salt Lake City to Denver where it is handed off to TeliaSonera, and they send it to Chicago where it gets handed off to Verizon. This works great and generally has a ping response of 20-25ms less than the bad route as posted below from one of our servers: Tracing route to pool-108-52-xxx-xxx.phlapa.fios.verizon.net [108.52.xxx.xxx] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 172.xxx.xxx.xxx (Internal IP) 2 <1 ms 10 ms <1 ms 209-41-xxx-xxx.c7dc.com [209.41.xxx.xxx] 3 <1 ms <1 ms <1 ms e1-5.rt08.gp1.c7dc.com [192.41.0.97] 4 2 ms 1 ms 1 ms ip65-46-51-113.z51-46-65.customer.algx.net [65.46.51.113] 5 19 ms 18 ms 19 ms vb1611.rar3.sanjose-ca.us.xo.net [216.156.0.5] 6 21 ms 18 ms 18 ms 207.88.14.226.ptr.us.xo.net [207.88.14.226] 7 18 ms 18 ms 18 ms 206.111.6.122.ptr.us.xo.net [206.111.6.122] >>>> Verizon owned device with an XO IP address 8 87 ms 86 ms 87 ms b100.phlapa-lcr-22.verizon-gni.net [130.81.209.187] >>>> Next hop goes from CA to PA, probably just hidden routing info 9 * * * Request timed out. 10 88 ms 89 ms 90 ms pool-108-52-xxx-xxx.phlapa.fios.verizon.net [108.52.xxx.xxx] As you can see, XO sends this traffic from Salt Lake City to San Jose where it is handed off to Verizon. We've worked with XO and determined that there are no connectivity issues along their path, which seems to point to an issue within Verizon's network. I have a couple of tickets open with Verizon at the moment on behalf of some of our customers, but we have had trouble breaking through Tier 1. Our first thought was saturation of the peering point, but XO states that the link between hops 6 and 7 is using 5Gbps out of 20Gbps capacity, and the latency on hop 7 (the Verizon owned device with an XO IP) seems normal whenever we test. Any Verizon engineers out there willing to take a quick peek at this route for any obvious issues? It would be a lot easier for us if Verizon provided Looking Glass servers, but alas... Thank you, Ryan From ivan at ludios.org Tue Aug 26 01:50:29 2014 From: ivan at ludios.org (Ivan Kozik) Date: Tue, 26 Aug 2014 01:50:29 +0000 Subject: Broken IPv6 firmware on U-Verse 3801HGV Message-ID: I noticed that AT&T released some firmware with IPv6 support back in May for their 3801HGV (and related) gateways. To try this out, I factory-reset my 3801HGV (still on version 6.9) and it installed the 6.11 firmware about 10 minutes later. I then used the obscure page at https://esupport.att3.2wire.com/online-tool/compat-index.jsp to request an IPv6 address ("wait 48 hours" it said) and got a routable IPv6 address in just a few minutes. All for naught, though. With IPv6 enabled, the 3801HGV crashed and rebooted about once an hour. After unchecking "IPv6 LAN Enabled" in http://192.168.1.254/xslt?PAGE=C_2_6 everything went back to normal. If anyone from AT&T is listening, I'm happy to help diagnose your firmware problems. Ivan From beecher at yahoo-inc.com Wed Aug 27 10:51:32 2014 From: beecher at yahoo-inc.com (Tom Beecher) Date: Wed, 27 Aug 2014 10:51:32 +0000 Subject: Time Warner outage? In-Reply-To: References: Message-ID: <6666F7E1-AF32-4FA6-ACC2-D9B2DF042D7E@yahoo-inc.com> All of WNY seems to be dead. Craps out what looks like inside TWC, so looks like they lost something big. --- Sent from Boxer | http://getboxer.com On August 27, 2014 at 6:43:12 AM EDT, Rick Coloccia wrote: My whole campus (~10000 users) is down... Since roughly 6am. TWC is our upstream. -- Sent from my iPhone > On Aug 27, 2014, at 6:28 AM, Rob Barbeau wrote: > > David, > > I have a branch office in Syracuse,NY that appears to be down at the moment > that uses a time warner business connection for internet access. > > -rob > On Aug 27, 2014 5:20 AM, "David Hubbard" > wrote: > >> Hey all, anyone else having issues with Time Warner residential or >> business connections? One of our offices is down and the route is not >> currently in bgp. http://downdetector.com/status/time-warner-cable >> shows thousands of reports of outages on the consumer side starting an >> hour or so ago so I figure it's a larger issue than just my one office; >> couldn't reach anyone by phone. >> >> Thanks, >> >> David >> From alex.suciu.sum at gmail.com Wed Aug 27 13:24:21 2014 From: alex.suciu.sum at gmail.com (Alexandru Suciu) Date: Wed, 27 Aug 2014 16:24:21 +0300 Subject: Time Warner outage? In-Reply-To: <001b01cfc1ef$253cf490$6fb6ddb0$@webjogger.net> References: <006201cfc1e4$21507920$63f16b60$@webjogger.net> <90344B7A-BF8A-40B8-A3C5-EA3991F5351D@geneseo.edu> <001b01cfc1ef$253cf490$6fb6ddb0$@webjogger.net> Message-ID: <53FDDC05.6050307@gmail.com> Can't wait to see the postmortem report on this one. On 8/27/2014 3:05 PM, Adam Greene wrote: > Came back for us, too, at about 7am. > > Outage was a biggie this time: > > https://news.yahoo.com/time-warner-cable-suffering-massive-nationwide-outage > -110549606.html > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Coulson > Sent: Wednesday, August 27, 2014 6:59 AM > To: Rick Coloccia > Cc: > Subject: Re: Time Warner outage? > > Just came back up for me. > > Sent from my iPad > >> On Aug 27, 2014, at 6:48 AM, Rick Coloccia wrote: >> >> BGPMON shows my routes falling off the net at around 5:49am. >> >> We now sit at their mercy.... >> >> >> -- >> Sent from my iPhone >> >>> On Aug 27, 2014, at 6:46 AM, "Adam Greene" > wrote: >>> Same here. Seems like no traffic is exiting TWC: >>> >>> Tracing route to ns03.savvis.net [204.70.25.234] over a maximum of 30 >>> hops: >>> >>> 1 1 ms 1 ms 1 ms 10049.webjogger.net [204.8.80.49] >>> 2 27 ms 6 ms 5 ms cpe-24-29-112-25.nyc.res.rr.com >>> [24.29.112.25] >>> 3 12 ms 8 ms 7 ms rdc-69-193-225-74.nyc.bc.twcable.com >>> [69.193.225.74] >>> 4 9 ms 9 ms 12 ms rdc-69-193-225-137.nyc.bc.twcable.com >>> [69.193.225.137] >>> 5 9 ms 10 ms 8 ms rdc-69-193-225-222.nyc.bc.twcable.com >>> [69.193.225.222] >>> 6 * * * Request timed out. >>> 7 * * * Request timed out. >>> 8 * * * Request timed out. >>> 9 * * * Request timed out. >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rick >>> Coloccia >>> Sent: Wednesday, August 27, 2014 6:43 AM >>> To: nanog at nanog.org >>> Subject: Re: Time Warner outage? >>> >>> My whole campus (~10000 users) is down... Since roughly 6am. TWC is >>> our upstream. >>> >>> -- >>> Sent from my iPhone >>> >>>> On Aug 27, 2014, at 6:28 AM, Rob Barbeau wrote: >>>> >>>> David, >>>> >>>> I have a branch office in Syracuse,NY that appears to be down at the >>>> moment that uses a time warner business connection for internet access. >>>> >>>> -rob >>>> On Aug 27, 2014 5:20 AM, "David Hubbard" >>>> >>>> wrote: >>>> >>>>> Hey all, anyone else having issues with Time Warner residential or >>>>> business connections? One of our offices is down and the route is >>>>> not currently in bgp. >>>>> http://downdetector.com/status/time-warner-cable >>>>> shows thousands of reports of outages on the consumer side starting >>>>> an hour or so ago so I figure it's a larger issue than just my one >>>>> office; couldn't reach anyone by phone. >>>>> >>>>> Thanks, >>>>> >>>>> David From ryanruuska+nanog at gmail.com Wed Aug 27 22:41:28 2014 From: ryanruuska+nanog at gmail.com (Ryan Ruuska) Date: Wed, 27 Aug 2014 17:41:28 -0500 Subject: Request for Verizon Engineer regarding 206.111.6.122 (San Jose) Message-ID: Can someone contact me regarding an issue with connectivity from this hop in San Jose to customers in Maryland, Virginia, and Pennsylvania? The DNS says it is an XO IP but it is actually a Verizon owned device. Thank you, Ryan From morrowc.lists at gmail.com Thu Aug 28 02:51:49 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 27 Aug 2014 22:51:49 -0400 Subject: Verizon connectivity issues In-Reply-To: References: Message-ID: On Mon, Aug 25, 2014 at 1:54 PM, Ryan Ruuska wrote: > Hello all, > > We have heard from many of our customers in the Northeast region, > specifically PA, MD, and VA who have difficulty connecting to our website there's probably vz customer folk on-list, maybe 'what should they test for you' would be nice? :) > (very slow loading times). We have noticed that if our data center > provider specifically routes our outbound traffic over Hurricane Electric > rather than XO Communications, that connectivity is restored to normal for > our customers. The HE path goes from Salt Lake City to Denver where it is > handed off to TeliaSonera, and they send it to Chicago where it gets handed > off to Verizon. This works great and generally has a ping response of > 20-25ms less than the bad route as posted below from one of our servers: > > Tracing route to pool-108-52-xxx-xxx.phlapa.fios.verizon.net > [108.52.xxx.xxx] > over a maximum of 30 hops: > > 1 <1 ms <1 ms <1 ms 172.xxx.xxx.xxx (Internal IP) > 2 <1 ms 10 ms <1 ms 209-41-xxx-xxx.c7dc.com [209.41.xxx.xxx] > 3 <1 ms <1 ms <1 ms e1-5.rt08.gp1.c7dc.com [192.41.0.97] > 4 2 ms 1 ms 1 ms ip65-46-51-113.z51-46-65.customer.algx.net > [65.46.51.113] > 5 19 ms 18 ms 19 ms vb1611.rar3.sanjose-ca.us.xo.net > [216.156.0.5] > 6 21 ms 18 ms 18 ms 207.88.14.226.ptr.us.xo.net [207.88.14.226] > 7 18 ms 18 ms 18 ms 206.111.6.122.ptr.us.xo.net [206.111.6.122] > >>>> Verizon owned device with an XO IP address > 8 87 ms 86 ms 87 ms b100.phlapa-lcr-22.verizon-gni.net > [130.81.209.187] > >>>> Next hop goes from CA to PA, probably just hidden routing info > 9 * * * Request timed out. > 10 88 ms 89 ms 90 ms pool-108-52-xxx-xxx.phlapa.fios.verizon.net > [108.52.xxx.xxx] > > As you can see, XO sends this traffic from Salt Lake City to San Jose where > it is handed off to Verizon. We've worked with XO and determined that > there are no connectivity issues along their path, which seems to point to > an issue within Verizon's network. I have a couple of tickets open with > Verizon at the moment on behalf of some of our customers, but we have had > trouble breaking through Tier 1. > > Our first thought was saturation of the peering point, but XO states that > the link between hops 6 and 7 is using 5Gbps out of 20Gbps capacity, and > the latency on hop 7 (the Verizon owned device with an XO IP) seems normal > whenever we test. > > Any Verizon engineers out there willing to take a quick peek at this route > for any obvious issues? It would be a lot easier for us if Verizon > provided Looking Glass servers, but alas... they have route data sent to routeviews at least... From chris at aperturefiber.com Thu Aug 28 11:05:30 2014 From: chris at aperturefiber.com (Chris Garrett) Date: Thu, 28 Aug 2014 06:05:30 -0500 Subject: Time Warner outage? In-Reply-To: <53FDDC05.6050307@gmail.com> References: <006201cfc1e4$21507920$63f16b60$@webjogger.net> <90344B7A-BF8A-40B8-A3C5-EA3991F5351D@geneseo.edu> <001b01cfc1ef$253cf490$6fb6ddb0$@webjogger.net> <53FDDC05.6050307@gmail.com> Message-ID: I believe this is what is commonly referred to in our industry as a ?resume generating event?. On Aug 27, 2014, at 8:24 AM, Alexandru Suciu wrote: > Can't wait to see the postmortem report on this one. > > On 8/27/2014 3:05 PM, Adam Greene wrote: >> Came back for us, too, at about 7am. >> >> Outage was a biggie this time: >> >> https://news.yahoo.com/time-warner-cable-suffering-massive-nationwide-outage >> -110549606.html >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Coulson >> Sent: Wednesday, August 27, 2014 6:59 AM >> To: Rick Coloccia >> Cc: >> Subject: Re: Time Warner outage? >> >> Just came back up for me. >> >> Sent from my iPad >> >>> On Aug 27, 2014, at 6:48 AM, Rick Coloccia wrote: >>> >>> BGPMON shows my routes falling off the net at around 5:49am. >>> >>> We now sit at their mercy.... >>> >>> >>> -- >>> Sent from my iPhone >>> >>>> On Aug 27, 2014, at 6:46 AM, "Adam Greene" >> wrote: >>>> Same here. Seems like no traffic is exiting TWC: >>>> >>>> Tracing route to ns03.savvis.net [204.70.25.234] over a maximum of 30 >>>> hops: >>>> >>>> 1 1 ms 1 ms 1 ms 10049.webjogger.net [204.8.80.49] >>>> 2 27 ms 6 ms 5 ms cpe-24-29-112-25.nyc.res.rr.com >>>> [24.29.112.25] >>>> 3 12 ms 8 ms 7 ms rdc-69-193-225-74.nyc.bc.twcable.com >>>> [69.193.225.74] >>>> 4 9 ms 9 ms 12 ms rdc-69-193-225-137.nyc.bc.twcable.com >>>> [69.193.225.137] >>>> 5 9 ms 10 ms 8 ms rdc-69-193-225-222.nyc.bc.twcable.com >>>> [69.193.225.222] >>>> 6 * * * Request timed out. >>>> 7 * * * Request timed out. >>>> 8 * * * Request timed out. >>>> 9 * * * Request timed out. >>>> >>>> -----Original Message----- >>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rick >>>> Coloccia >>>> Sent: Wednesday, August 27, 2014 6:43 AM >>>> To: nanog at nanog.org >>>> Subject: Re: Time Warner outage? >>>> >>>> My whole campus (~10000 users) is down... Since roughly 6am. TWC is >>>> our upstream. >>>> >>>> -- >>>> Sent from my iPhone >>>> >>>>> On Aug 27, 2014, at 6:28 AM, Rob Barbeau wrote: >>>>> >>>>> David, >>>>> >>>>> I have a branch office in Syracuse,NY that appears to be down at the >>>>> moment that uses a time warner business connection for internet access. >>>>> >>>>> -rob >>>>> On Aug 27, 2014 5:20 AM, "David Hubbard" >>>>> >>>>> wrote: >>>>> >>>>>> Hey all, anyone else having issues with Time Warner residential or >>>>>> business connections? One of our offices is down and the route is >>>>>> not currently in bgp. >>>>>> http://downdetector.com/status/time-warner-cable >>>>>> shows thousands of reports of outages on the consumer side starting >>>>>> an hour or so ago so I figure it's a larger issue than just my one >>>>>> office; couldn't reach anyone by phone. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> David > From list at satchell.net Thu Aug 28 12:46:54 2014 From: list at satchell.net (Stephen Satchell) Date: Thu, 28 Aug 2014 05:46:54 -0700 Subject: Time Warner outage? In-Reply-To: References: <006201cfc1e4$21507920$63f16b60$@webjogger.net> <90344B7A-BF8A-40B8-A3C5-EA3991F5351D@geneseo.edu> <001b01cfc1ef$253cf490$6fb6ddb0$@webjogger.net> <53FDDC05.6050307@gmail.com> Message-ID: <53FF24BE.2080905@satchell.net> This just keeps getting better and better: "Yahoo Logo Will be right back... Thank you for your patience. Our engineers are working quickly to resolve the issue." My upstream is Charter Business... On 08/28/2014 04:05 AM, Chris Garrett wrote: > I believe this is what is commonly referred to in our industry as a ?resume generating event?. > > > On Aug 27, 2014, at 8:24 AM, Alexandru Suciu wrote: > >> Can't wait to see the postmortem report on this one. >> >> On 8/27/2014 3:05 PM, Adam Greene wrote: >>> Came back for us, too, at about 7am. >>> >>> Outage was a biggie this time: >>> >>> https://news.yahoo.com/time-warner-cable-suffering-massive-nationwide-outage >>> -110549606.html >>> >>> >>> -----Original Message----- >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Coulson >>> Sent: Wednesday, August 27, 2014 6:59 AM >>> To: Rick Coloccia >>> Cc: >>> Subject: Re: Time Warner outage? >>> >>> Just came back up for me. >>> >>> Sent from my iPad >>> >>>> On Aug 27, 2014, at 6:48 AM, Rick Coloccia wrote: >>>> >>>> BGPMON shows my routes falling off the net at around 5:49am. >>>> >>>> We now sit at their mercy.... >>>> >>>> >>>> -- >>>> Sent from my iPhone >>>> >>>>> On Aug 27, 2014, at 6:46 AM, "Adam Greene" >>> wrote: >>>>> Same here. Seems like no traffic is exiting TWC: >>>>> >>>>> Tracing route to ns03.savvis.net [204.70.25.234] over a maximum of 30 >>>>> hops: >>>>> >>>>> 1 1 ms 1 ms 1 ms 10049.webjogger.net [204.8.80.49] >>>>> 2 27 ms 6 ms 5 ms cpe-24-29-112-25.nyc.res.rr.com >>>>> [24.29.112.25] >>>>> 3 12 ms 8 ms 7 ms rdc-69-193-225-74.nyc.bc.twcable.com >>>>> [69.193.225.74] >>>>> 4 9 ms 9 ms 12 ms rdc-69-193-225-137.nyc.bc.twcable.com >>>>> [69.193.225.137] >>>>> 5 9 ms 10 ms 8 ms rdc-69-193-225-222.nyc.bc.twcable.com >>>>> [69.193.225.222] >>>>> 6 * * * Request timed out. >>>>> 7 * * * Request timed out. >>>>> 8 * * * Request timed out. >>>>> 9 * * * Request timed out. >>>>> >>>>> -----Original Message----- >>>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rick >>>>> Coloccia >>>>> Sent: Wednesday, August 27, 2014 6:43 AM >>>>> To: nanog at nanog.org >>>>> Subject: Re: Time Warner outage? >>>>> >>>>> My whole campus (~10000 users) is down... Since roughly 6am. TWC is >>>>> our upstream. >>>>> >>>>> -- >>>>> Sent from my iPhone >>>>> >>>>>> On Aug 27, 2014, at 6:28 AM, Rob Barbeau wrote: >>>>>> >>>>>> David, >>>>>> >>>>>> I have a branch office in Syracuse,NY that appears to be down at the >>>>>> moment that uses a time warner business connection for internet access. >>>>>> >>>>>> -rob >>>>>> On Aug 27, 2014 5:20 AM, "David Hubbard" >>>>>> >>>>>> wrote: >>>>>> >>>>>>> Hey all, anyone else having issues with Time Warner residential or >>>>>>> business connections? One of our offices is down and the route is >>>>>>> not currently in bgp. >>>>>>> http://downdetector.com/status/time-warner-cable >>>>>>> shows thousands of reports of outages on the consumer side starting >>>>>>> an hour or so ago so I figure it's a larger issue than just my one >>>>>>> office; couldn't reach anyone by phone. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> David >> > From clane1875 at gmail.com Thu Aug 28 13:23:08 2014 From: clane1875 at gmail.com (Chris Lane) Date: Thu, 28 Aug 2014 09:23:08 -0400 Subject: Time Warner outage? In-Reply-To: <53FF24BE.2080905@satchell.net> References: <006201cfc1e4$21507920$63f16b60$@webjogger.net> <90344B7A-BF8A-40B8-A3C5-EA3991F5351D@geneseo.edu> <001b01cfc1ef$253cf490$6fb6ddb0$@webjogger.net> <53FDDC05.6050307@gmail.com> <53FF24BE.2080905@satchell.net> Message-ID: I heard the following, It was actually an engineer doing maintenance on the dhpc server that stopped customers from getting an IP address when the connected to the network between 5:30 and 7:00. The funny part is upper Managment heard about it on the today show On Thu, Aug 28, 2014 at 8:46 AM, Stephen Satchell wrote: > This just keeps getting better and better: > > "Yahoo Logo > Will be right back... > > Thank you for your patience. > > Our engineers are working quickly to resolve the issue." > > My upstream is Charter Business... > > On 08/28/2014 04:05 AM, Chris Garrett wrote: > > I believe this is what is commonly referred to in our industry as a > ?resume generating event?. > > > > > > On Aug 27, 2014, at 8:24 AM, Alexandru Suciu > wrote: > > > >> Can't wait to see the postmortem report on this one. > >> > >> On 8/27/2014 3:05 PM, Adam Greene wrote: > >>> Came back for us, too, at about 7am. > >>> > >>> Outage was a biggie this time: > >>> > >>> > https://news.yahoo.com/time-warner-cable-suffering-massive-nationwide-outage > >>> -110549606.html > >>> > >>> > >>> -----Original Message----- > >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David > Coulson > >>> Sent: Wednesday, August 27, 2014 6:59 AM > >>> To: Rick Coloccia > >>> Cc: > >>> Subject: Re: Time Warner outage? > >>> > >>> Just came back up for me. > >>> > >>> Sent from my iPad > >>> > >>>> On Aug 27, 2014, at 6:48 AM, Rick Coloccia > wrote: > >>>> > >>>> BGPMON shows my routes falling off the net at around 5:49am. > >>>> > >>>> We now sit at their mercy.... > >>>> > >>>> > >>>> -- > >>>> Sent from my iPhone > >>>> > >>>>> On Aug 27, 2014, at 6:46 AM, "Adam Greene" > >>> wrote: > >>>>> Same here. Seems like no traffic is exiting TWC: > >>>>> > >>>>> Tracing route to ns03.savvis.net [204.70.25.234] over a maximum of > 30 > >>>>> hops: > >>>>> > >>>>> 1 1 ms 1 ms 1 ms 10049.webjogger.net [204.8.80.49] > >>>>> 2 27 ms 6 ms 5 ms cpe-24-29-112-25.nyc.res.rr.com > >>>>> [24.29.112.25] > >>>>> 3 12 ms 8 ms 7 ms rdc-69-193-225-74.nyc.bc.twcable.com > >>>>> [69.193.225.74] > >>>>> 4 9 ms 9 ms 12 ms rdc-69-193-225-137.nyc.bc.twcable.com > >>>>> [69.193.225.137] > >>>>> 5 9 ms 10 ms 8 ms rdc-69-193-225-222.nyc.bc.twcable.com > >>>>> [69.193.225.222] > >>>>> 6 * * * Request timed out. > >>>>> 7 * * * Request timed out. > >>>>> 8 * * * Request timed out. > >>>>> 9 * * * Request timed out. > >>>>> > >>>>> -----Original Message----- > >>>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rick > >>>>> Coloccia > >>>>> Sent: Wednesday, August 27, 2014 6:43 AM > >>>>> To: nanog at nanog.org > >>>>> Subject: Re: Time Warner outage? > >>>>> > >>>>> My whole campus (~10000 users) is down... Since roughly 6am. TWC is > >>>>> our upstream. > >>>>> > >>>>> -- > >>>>> Sent from my iPhone > >>>>> > >>>>>> On Aug 27, 2014, at 6:28 AM, Rob Barbeau > wrote: > >>>>>> > >>>>>> David, > >>>>>> > >>>>>> I have a branch office in Syracuse,NY that appears to be down at the > >>>>>> moment that uses a time warner business connection for internet > access. > >>>>>> > >>>>>> -rob > >>>>>> On Aug 27, 2014 5:20 AM, "David Hubbard" > >>>>>> > >>>>>> wrote: > >>>>>> > >>>>>>> Hey all, anyone else having issues with Time Warner residential or > >>>>>>> business connections? One of our offices is down and the route is > >>>>>>> not currently in bgp. > >>>>>>> http://downdetector.com/status/time-warner-cable > >>>>>>> shows thousands of reports of outages on the consumer side starting > >>>>>>> an hour or so ago so I figure it's a larger issue than just my one > >>>>>>> office; couldn't reach anyone by phone. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> David > >> > > > > -- //CL From SNaslund at medline.com Thu Aug 28 13:29:23 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 28 Aug 2014 13:29:23 +0000 Subject: Time Warner outage? In-Reply-To: References: <006201cfc1e4$21507920$63f16b60$@webjogger.net> <90344B7A-BF8A-40B8-A3C5-EA3991F5351D@geneseo.edu> <001b01cfc1ef$253cf490$6fb6ddb0$@webjogger.net> <53FDDC05.6050307@gmail.com> <53FF24BE.2080905@satchell.net> Message-ID: <9578293AE169674F9A048B2BC9A081B40124F7B3B5@MUNPRDMBXA1.medline.com> Something sounds really unlikely about that. Lack of DHCP would not cause reachability problems except for the clients. The trace below looks like a transit connection that should be unaffected by DHCP. Looks more like a routing issue. Also sounds unlikely that one DHCP server would be covering this large a scope. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chris Lane Sent: Thursday, August 28, 2014 8:23 AM To: Stephen Satchell Cc: nanog at nanog.org Subject: Re: Time Warner outage? I heard the following, It was actually an engineer doing maintenance on the dhpc server that stopped customers from getting an IP address when the connected to the network between 5:30 and 7:00. The funny part is upper Managment heard about it on the today show On Thu, Aug 28, 2014 at 8:46 AM, Stephen Satchell wrote: > This just keeps getting better and better: > > "Yahoo Logo > Will be right back... > > Thank you for your patience. > > Our engineers are working quickly to resolve the issue." > > My upstream is Charter Business... > > On 08/28/2014 04:05 AM, Chris Garrett wrote: > > I believe this is what is commonly referred to in our industry as a > ?resume generating event?. > > > > > > On Aug 27, 2014, at 8:24 AM, Alexandru Suciu > > > wrote: > > > >> Can't wait to see the postmortem report on this one. > >> > >> On 8/27/2014 3:05 PM, Adam Greene wrote: > >>> Came back for us, too, at about 7am. > >>> > >>> Outage was a biggie this time: > >>> > >>> > https://news.yahoo.com/time-warner-cable-suffering-massive-nationwide- > outage > >>> -110549606.html > >>> > >>> > >>> -----Original Message----- > >>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David > Coulson > >>> Sent: Wednesday, August 27, 2014 6:59 AM > >>> To: Rick Coloccia > >>> Cc: > >>> Subject: Re: Time Warner outage? > >>> > >>> Just came back up for me. > >>> > >>> Sent from my iPad > >>> > >>>> On Aug 27, 2014, at 6:48 AM, Rick Coloccia > wrote: > >>>> > >>>> BGPMON shows my routes falling off the net at around 5:49am. > >>>> > >>>> We now sit at their mercy.... > >>>> > >>>> > >>>> -- > >>>> Sent from my iPhone > >>>> > >>>>> On Aug 27, 2014, at 6:46 AM, "Adam Greene" > >>>>> > >>> wrote: > >>>>> Same here. Seems like no traffic is exiting TWC: > >>>>> > >>>>> Tracing route to ns03.savvis.net [204.70.25.234] over a maximum > >>>>> of > 30 > >>>>> hops: > >>>>> > >>>>> 1 1 ms 1 ms 1 ms 10049.webjogger.net [204.8.80.49] > >>>>> 2 27 ms 6 ms 5 ms cpe-24-29-112-25.nyc.res.rr.com > >>>>> [24.29.112.25] > >>>>> 3 12 ms 8 ms 7 ms rdc-69-193-225-74.nyc.bc.twcable.com > >>>>> [69.193.225.74] > >>>>> 4 9 ms 9 ms 12 ms rdc-69-193-225-137.nyc.bc.twcable.com > >>>>> [69.193.225.137] > >>>>> 5 9 ms 10 ms 8 ms rdc-69-193-225-222.nyc.bc.twcable.com > >>>>> [69.193.225.222] > >>>>> 6 * * * Request timed out. > >>>>> 7 * * * Request timed out. > >>>>> 8 * * * Request timed out. > >>>>> 9 * * * Request timed out. > >>>>> > >>>>> -----Original Message----- > >>>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rick > >>>>> Coloccia > >>>>> Sent: Wednesday, August 27, 2014 6:43 AM > >>>>> To: nanog at nanog.org > >>>>> Subject: Re: Time Warner outage? > >>>>> > >>>>> My whole campus (~10000 users) is down... Since roughly 6am. > >>>>> TWC is our upstream. > >>>>> > >>>>> -- > >>>>> Sent from my iPhone > >>>>> > >>>>>> On Aug 27, 2014, at 6:28 AM, Rob Barbeau > >>>>>> > wrote: > >>>>>> > >>>>>> David, > >>>>>> > >>>>>> I have a branch office in Syracuse,NY that appears to be down > >>>>>> at the moment that uses a time warner business connection for > >>>>>> internet > access. > >>>>>> > >>>>>> -rob > >>>>>> On Aug 27, 2014 5:20 AM, "David Hubbard" > >>>>>> > >>>>>> wrote: > >>>>>> > >>>>>>> Hey all, anyone else having issues with Time Warner > >>>>>>> residential or business connections? One of our offices is > >>>>>>> down and the route is not currently in bgp. > >>>>>>> http://downdetector.com/status/time-warner-cable > >>>>>>> shows thousands of reports of outages on the consumer side > >>>>>>> starting an hour or so ago so I figure it's a larger issue > >>>>>>> than just my one office; couldn't reach anyone by phone. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> David > >> > > > > -- //CL From faisal at snappytelecom.net Thu Aug 28 13:33:31 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Thu, 28 Aug 2014 13:33:31 +0000 (GMT) Subject: Time Warner outage? In-Reply-To: References: <006201cfc1e4$21507920$63f16b60$@webjogger.net> <90344B7A-BF8A-40B8-A3C5-EA3991F5351D@geneseo.edu> <001b01cfc1ef$253cf490$6fb6ddb0$@webjogger.net> <53FDDC05.6050307@gmail.com> Message-ID: <683549255.349829.1409232811707.JavaMail.zimbra@snappytelecom.net> hehe... We call them 'Character Builder Events'. Everyone gets to find out how much pressure they can take, beak new grounds, what they are made off, etc etc. 'Shit Storms' come in waves..... typically these are not caused by singular events, but more like a 'Series of Unfortunate Events'. We don't wish this on any carrier, but sooner or later everyone has to go thru it. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Chris Garrett" > To: "Alexandru Suciu" > Cc: nanog at nanog.org > Sent: Thursday, August 28, 2014 7:05:30 AM > Subject: Re: Time Warner outage? > > I believe this is what is commonly referred to in our industry as a ?resume > generating event?. > > > On Aug 27, 2014, at 8:24 AM, Alexandru Suciu > wrote: > > > Can't wait to see the postmortem report on this one. > > > > On 8/27/2014 3:05 PM, Adam Greene wrote: > >> Came back for us, too, at about 7am. > >> > >> Outage was a biggie this time: > >> > >> https://news.yahoo.com/time-warner-cable-suffering-massive-nationwide-outage > >> -110549606.html > >> > >> > >> -----Original Message----- > >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David Coulson > >> Sent: Wednesday, August 27, 2014 6:59 AM > >> To: Rick Coloccia > >> Cc: > >> Subject: Re: Time Warner outage? > >> > >> Just came back up for me. > >> > >> Sent from my iPad > >> > >>> On Aug 27, 2014, at 6:48 AM, Rick Coloccia wrote: > >>> > >>> BGPMON shows my routes falling off the net at around 5:49am. > >>> > >>> We now sit at their mercy.... > >>> > >>> > >>> -- > >>> Sent from my iPhone > >>> > >>>> On Aug 27, 2014, at 6:46 AM, "Adam Greene" > >> wrote: > >>>> Same here. Seems like no traffic is exiting TWC: > >>>> > >>>> Tracing route to ns03.savvis.net [204.70.25.234] over a maximum of 30 > >>>> hops: > >>>> > >>>> 1 1 ms 1 ms 1 ms 10049.webjogger.net [204.8.80.49] > >>>> 2 27 ms 6 ms 5 ms cpe-24-29-112-25.nyc.res.rr.com > >>>> [24.29.112.25] > >>>> 3 12 ms 8 ms 7 ms rdc-69-193-225-74.nyc.bc.twcable.com > >>>> [69.193.225.74] > >>>> 4 9 ms 9 ms 12 ms rdc-69-193-225-137.nyc.bc.twcable.com > >>>> [69.193.225.137] > >>>> 5 9 ms 10 ms 8 ms rdc-69-193-225-222.nyc.bc.twcable.com > >>>> [69.193.225.222] > >>>> 6 * * * Request timed out. > >>>> 7 * * * Request timed out. > >>>> 8 * * * Request timed out. > >>>> 9 * * * Request timed out. > >>>> > >>>> -----Original Message----- > >>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rick > >>>> Coloccia > >>>> Sent: Wednesday, August 27, 2014 6:43 AM > >>>> To: nanog at nanog.org > >>>> Subject: Re: Time Warner outage? > >>>> > >>>> My whole campus (~10000 users) is down... Since roughly 6am. TWC is > >>>> our upstream. > >>>> > >>>> -- > >>>> Sent from my iPhone > >>>> > >>>>> On Aug 27, 2014, at 6:28 AM, Rob Barbeau wrote: > >>>>> > >>>>> David, > >>>>> > >>>>> I have a branch office in Syracuse,NY that appears to be down at the > >>>>> moment that uses a time warner business connection for internet access. > >>>>> > >>>>> -rob > >>>>> On Aug 27, 2014 5:20 AM, "David Hubbard" > >>>>> > >>>>> wrote: > >>>>> > >>>>>> Hey all, anyone else having issues with Time Warner residential or > >>>>>> business connections? One of our offices is down and the route is > >>>>>> not currently in bgp. > >>>>>> http://downdetector.com/status/time-warner-cable > >>>>>> shows thousands of reports of outages on the consumer side starting > >>>>>> an hour or so ago so I figure it's a larger issue than just my one > >>>>>> office; couldn't reach anyone by phone. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> David > > > > From chris at aperturefiber.com Thu Aug 28 13:35:11 2014 From: chris at aperturefiber.com (Chris Garrett) Date: Thu, 28 Aug 2014 08:35:11 -0500 Subject: Time Warner outage? In-Reply-To: <9578293AE169674F9A048B2BC9A081B40124F7B3B5@MUNPRDMBXA1.medline.com> References: <006201cfc1e4$21507920$63f16b60$@webjogger.net> <90344B7A-BF8A-40B8-A3C5-EA3991F5351D@geneseo.edu> <001b01cfc1ef$253cf490$6fb6ddb0$@webjogger.net> <53FDDC05.6050307@gmail.com> <53FF24BE.2080905@satchell.net> <9578293AE169674F9A048B2BC9A081B40124F7B3B5@MUNPRDMBXA1.medline.com> Message-ID: I have never seen BGP drop peers because of a DHCP failure. I would love to see the breakdown on that. TW NOC had said it was a Level 3 fiber maintenance gone bad that took down their peering connections when we called in at the time of the event. Can anyone confirm one way or the other? On Aug 28, 2014, at 8:29 AM, Naslund, Steve wrote: > Something sounds really unlikely about that. Lack of DHCP would not cause reachability problems except for the clients. The trace below looks like a transit connection that should be unaffected by DHCP. Looks more like a routing issue. Also sounds unlikely that one DHCP server would be covering this large a scope. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chris Lane > Sent: Thursday, August 28, 2014 8:23 AM > To: Stephen Satchell > Cc: nanog at nanog.org > Subject: Re: Time Warner outage? > > I heard the following, > > It was actually an engineer doing maintenance on the dhpc server that stopped customers from getting an IP address when the connected to the network between 5:30 and 7:00. The funny part is upper Managment heard about it on the today show > > > On Thu, Aug 28, 2014 at 8:46 AM, Stephen Satchell wrote: > >> This just keeps getting better and better: >> >> "Yahoo Logo >> Will be right back... >> >> Thank you for your patience. >> >> Our engineers are working quickly to resolve the issue." >> >> My upstream is Charter Business... >> >> On 08/28/2014 04:05 AM, Chris Garrett wrote: >>> I believe this is what is commonly referred to in our industry as a >> ?resume generating event?. >>> >>> >>> On Aug 27, 2014, at 8:24 AM, Alexandru Suciu >>> >> wrote: >>> >>>> Can't wait to see the postmortem report on this one. >>>> >>>> On 8/27/2014 3:05 PM, Adam Greene wrote: >>>>> Came back for us, too, at about 7am. >>>>> >>>>> Outage was a biggie this time: >>>>> >>>>> >> https://news.yahoo.com/time-warner-cable-suffering-massive-nationwide- >> outage >>>>> -110549606.html >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David >> Coulson >>>>> Sent: Wednesday, August 27, 2014 6:59 AM >>>>> To: Rick Coloccia >>>>> Cc: >>>>> Subject: Re: Time Warner outage? >>>>> >>>>> Just came back up for me. >>>>> >>>>> Sent from my iPad >>>>> >>>>>> On Aug 27, 2014, at 6:48 AM, Rick Coloccia >> wrote: >>>>>> >>>>>> BGPMON shows my routes falling off the net at around 5:49am. >>>>>> >>>>>> We now sit at their mercy.... >>>>>> >>>>>> >>>>>> -- >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Aug 27, 2014, at 6:46 AM, "Adam Greene" >>>>>>> >>>>> wrote: >>>>>>> Same here. Seems like no traffic is exiting TWC: >>>>>>> >>>>>>> Tracing route to ns03.savvis.net [204.70.25.234] over a maximum >>>>>>> of >> 30 >>>>>>> hops: >>>>>>> >>>>>>> 1 1 ms 1 ms 1 ms 10049.webjogger.net [204.8.80.49] >>>>>>> 2 27 ms 6 ms 5 ms cpe-24-29-112-25.nyc.res.rr.com >>>>>>> [24.29.112.25] >>>>>>> 3 12 ms 8 ms 7 ms rdc-69-193-225-74.nyc.bc.twcable.com >>>>>>> [69.193.225.74] >>>>>>> 4 9 ms 9 ms 12 ms rdc-69-193-225-137.nyc.bc.twcable.com >>>>>>> [69.193.225.137] >>>>>>> 5 9 ms 10 ms 8 ms rdc-69-193-225-222.nyc.bc.twcable.com >>>>>>> [69.193.225.222] >>>>>>> 6 * * * Request timed out. >>>>>>> 7 * * * Request timed out. >>>>>>> 8 * * * Request timed out. >>>>>>> 9 * * * Request timed out. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rick >>>>>>> Coloccia >>>>>>> Sent: Wednesday, August 27, 2014 6:43 AM >>>>>>> To: nanog at nanog.org >>>>>>> Subject: Re: Time Warner outage? >>>>>>> >>>>>>> My whole campus (~10000 users) is down... Since roughly 6am. >>>>>>> TWC is our upstream. >>>>>>> >>>>>>> -- >>>>>>> Sent from my iPhone >>>>>>> >>>>>>>> On Aug 27, 2014, at 6:28 AM, Rob Barbeau >>>>>>>> >> wrote: >>>>>>>> >>>>>>>> David, >>>>>>>> >>>>>>>> I have a branch office in Syracuse,NY that appears to be down >>>>>>>> at the moment that uses a time warner business connection for >>>>>>>> internet >> access. >>>>>>>> >>>>>>>> -rob >>>>>>>> On Aug 27, 2014 5:20 AM, "David Hubbard" >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hey all, anyone else having issues with Time Warner >>>>>>>>> residential or business connections? One of our offices is >>>>>>>>> down and the route is not currently in bgp. >>>>>>>>> http://downdetector.com/status/time-warner-cable >>>>>>>>> shows thousands of reports of outages on the consumer side >>>>>>>>> starting an hour or so ago so I figure it's a larger issue >>>>>>>>> than just my one office; couldn't reach anyone by phone. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> David >>>> >>> >> >> > > > -- > //CL From wbailey at satelliteintelligencegroup.com Thu Aug 28 13:42:01 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 28 Aug 2014 13:42:01 +0000 Subject: Time Warner outage? In-Reply-To: References: <006201cfc1e4$21507920$63f16b60$@webjogger.net> <90344B7A-BF8A-40B8-A3C5-EA3991F5351D@geneseo.edu> <001b01cfc1ef$253cf490$6fb6ddb0$@webjogger.net> <53FDDC05.6050307@gmail.com> <53FF24BE.2080905@satchell.net> <9578293AE169674F9A048B2BC9A081B40124F7B3B5@MUNPRDMBXA1.medline.com>, Message-ID: Sounds more likely than "we broke the dhcp server". Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Chris Garrett Date: 08/28/2014 6:39 AM (GMT-08:00) To: "Naslund, Steve" Cc: nanog at nanog.org Subject: Re: Time Warner outage? I have never seen BGP drop peers because of a DHCP failure. I would love to see the breakdown on that. TW NOC had said it was a Level 3 fiber maintenance gone bad that took down their peering connections when we called in at the time of the event. Can anyone confirm one way or the other? On Aug 28, 2014, at 8:29 AM, Naslund, Steve wrote: > Something sounds really unlikely about that. Lack of DHCP would not cause reachability problems except for the clients. The trace below looks like a transit connection that should be unaffected by DHCP. Looks more like a routing issue. Also sounds unlikely that one DHCP server would be covering this large a scope. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chris Lane > Sent: Thursday, August 28, 2014 8:23 AM > To: Stephen Satchell > Cc: nanog at nanog.org > Subject: Re: Time Warner outage? > > I heard the following, > > It was actually an engineer doing maintenance on the dhpc server that stopped customers from getting an IP address when the connected to the network between 5:30 and 7:00. The funny part is upper Managment heard about it on the today show > > > On Thu, Aug 28, 2014 at 8:46 AM, Stephen Satchell wrote: > >> This just keeps getting better and better: >> >> "Yahoo Logo >> Will be right back... >> >> Thank you for your patience. >> >> Our engineers are working quickly to resolve the issue." >> >> My upstream is Charter Business... >> >> On 08/28/2014 04:05 AM, Chris Garrett wrote: >>> I believe this is what is commonly referred to in our industry as a >> ?resume generating event?. >>> >>> >>> On Aug 27, 2014, at 8:24 AM, Alexandru Suciu >>> >> wrote: >>> >>>> Can't wait to see the postmortem report on this one. >>>> >>>> On 8/27/2014 3:05 PM, Adam Greene wrote: >>>>> Came back for us, too, at about 7am. >>>>> >>>>> Outage was a biggie this time: >>>>> >>>>> >> https://news.yahoo.com/time-warner-cable-suffering-massive-nationwide- >> outage >>>>> -110549606.html >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David >> Coulson >>>>> Sent: Wednesday, August 27, 2014 6:59 AM >>>>> To: Rick Coloccia >>>>> Cc: >>>>> Subject: Re: Time Warner outage? >>>>> >>>>> Just came back up for me. >>>>> >>>>> Sent from my iPad >>>>> >>>>>> On Aug 27, 2014, at 6:48 AM, Rick Coloccia >> wrote: >>>>>> >>>>>> BGPMON shows my routes falling off the net at around 5:49am. >>>>>> >>>>>> We now sit at their mercy.... >>>>>> >>>>>> >>>>>> -- >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Aug 27, 2014, at 6:46 AM, "Adam Greene" >>>>>>> >>>>> wrote: >>>>>>> Same here. Seems like no traffic is exiting TWC: >>>>>>> >>>>>>> Tracing route to ns03.savvis.net [204.70.25.234] over a maximum >>>>>>> of >> 30 >>>>>>> hops: >>>>>>> >>>>>>> 1 1 ms 1 ms 1 ms 10049.webjogger.net [204.8.80.49] >>>>>>> 2 27 ms 6 ms 5 ms cpe-24-29-112-25.nyc.res.rr.com >>>>>>> [24.29.112.25] >>>>>>> 3 12 ms 8 ms 7 ms rdc-69-193-225-74.nyc.bc.twcable.com >>>>>>> [69.193.225.74] >>>>>>> 4 9 ms 9 ms 12 ms rdc-69-193-225-137.nyc.bc.twcable.com >>>>>>> [69.193.225.137] >>>>>>> 5 9 ms 10 ms 8 ms rdc-69-193-225-222.nyc.bc.twcable.com >>>>>>> [69.193.225.222] >>>>>>> 6 * * * Request timed out. >>>>>>> 7 * * * Request timed out. >>>>>>> 8 * * * Request timed out. >>>>>>> 9 * * * Request timed out. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rick >>>>>>> Coloccia >>>>>>> Sent: Wednesday, August 27, 2014 6:43 AM >>>>>>> To: nanog at nanog.org >>>>>>> Subject: Re: Time Warner outage? >>>>>>> >>>>>>> My whole campus (~10000 users) is down... Since roughly 6am. >>>>>>> TWC is our upstream. >>>>>>> >>>>>>> -- >>>>>>> Sent from my iPhone >>>>>>> >>>>>>>> On Aug 27, 2014, at 6:28 AM, Rob Barbeau >>>>>>>> >> wrote: >>>>>>>> >>>>>>>> David, >>>>>>>> >>>>>>>> I have a branch office in Syracuse,NY that appears to be down >>>>>>>> at the moment that uses a time warner business connection for >>>>>>>> internet >> access. >>>>>>>> >>>>>>>> -rob >>>>>>>> On Aug 27, 2014 5:20 AM, "David Hubbard" >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hey all, anyone else having issues with Time Warner >>>>>>>>> residential or business connections? One of our offices is >>>>>>>>> down and the route is not currently in bgp. >>>>>>>>> http://downdetector.com/status/time-warner-cable >>>>>>>>> shows thousands of reports of outages on the consumer side >>>>>>>>> starting an hour or so ago so I figure it's a larger issue >>>>>>>>> than just my one office; couldn't reach anyone by phone. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> David >>>> >>> >> >> > > > -- > //CL From clane1875 at gmail.com Thu Aug 28 13:51:05 2014 From: clane1875 at gmail.com (Chris Lane) Date: Thu, 28 Aug 2014 09:51:05 -0400 Subject: Time Warner outage? In-Reply-To: References: <006201cfc1e4$21507920$63f16b60$@webjogger.net> <90344B7A-BF8A-40B8-A3C5-EA3991F5351D@geneseo.edu> <001b01cfc1ef$253cf490$6fb6ddb0$@webjogger.net> <53FDDC05.6050307@gmail.com> <53FF24BE.2080905@satchell.net> <9578293AE169674F9A048B2BC9A081B40124F7B3B5@MUNPRDMBXA1.medline.com> Message-ID: Agreed on DHCP, just passing along something i had heard about..... With that said, why wouldn't the TW guys just post something oh right they did, blame the other guy "Level3" On Thu, Aug 28, 2014 at 9:42 AM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > Sounds more likely than "we broke the dhcp server". > > > Sent from my T-Mobile 4G LTE Device > > > > -------- Original message -------- > From: Chris Garrett > Date: 08/28/2014 6:39 AM (GMT-08:00) > To: "Naslund, Steve" > Cc: nanog at nanog.org > Subject: Re: Time Warner outage? > > > I have never seen BGP drop peers because of a DHCP failure. > > I would love to see the breakdown on that. > > TW NOC had said it was a Level 3 fiber maintenance gone bad that took down > their peering connections when we called in at the time of the event. > > Can anyone confirm one way or the other? > > > On Aug 28, 2014, at 8:29 AM, Naslund, Steve wrote: > > > Something sounds really unlikely about that. Lack of DHCP would not > cause reachability problems except for the clients. The trace below looks > like a transit connection that should be unaffected by DHCP. Looks more > like a routing issue. Also sounds unlikely that one DHCP server would be > covering this large a scope. > > > > Steven Naslund > > Chicago IL > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chris Lane > > Sent: Thursday, August 28, 2014 8:23 AM > > To: Stephen Satchell > > Cc: nanog at nanog.org > > Subject: Re: Time Warner outage? > > > > I heard the following, > > > > It was actually an engineer doing maintenance on the dhpc server that > stopped customers from getting an IP address when the connected to the > network between 5:30 and 7:00. The funny part is upper Managment heard > about it on the today show > > > > > > On Thu, Aug 28, 2014 at 8:46 AM, Stephen Satchell > wrote: > > > >> This just keeps getting better and better: > >> > >> "Yahoo Logo > >> Will be right back... > >> > >> Thank you for your patience. > >> > >> Our engineers are working quickly to resolve the issue." > >> > >> My upstream is Charter Business... > >> > >> On 08/28/2014 04:05 AM, Chris Garrett wrote: > >>> I believe this is what is commonly referred to in our industry as a > >> ?resume generating event?. > >>> > >>> > >>> On Aug 27, 2014, at 8:24 AM, Alexandru Suciu > >>> > >> wrote: > >>> > >>>> Can't wait to see the postmortem report on this one. > >>>> > >>>> On 8/27/2014 3:05 PM, Adam Greene wrote: > >>>>> Came back for us, too, at about 7am. > >>>>> > >>>>> Outage was a biggie this time: > >>>>> > >>>>> > >> https://news.yahoo.com/time-warner-cable-suffering-massive-nationwide- > >> outage > >>>>> -110549606.html > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David > >> Coulson > >>>>> Sent: Wednesday, August 27, 2014 6:59 AM > >>>>> To: Rick Coloccia > >>>>> Cc: > >>>>> Subject: Re: Time Warner outage? > >>>>> > >>>>> Just came back up for me. > >>>>> > >>>>> Sent from my iPad > >>>>> > >>>>>> On Aug 27, 2014, at 6:48 AM, Rick Coloccia > >> wrote: > >>>>>> > >>>>>> BGPMON shows my routes falling off the net at around 5:49am. > >>>>>> > >>>>>> We now sit at their mercy.... > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Sent from my iPhone > >>>>>> > >>>>>>> On Aug 27, 2014, at 6:46 AM, "Adam Greene" > >>>>>>> > >>>>> wrote: > >>>>>>> Same here. Seems like no traffic is exiting TWC: > >>>>>>> > >>>>>>> Tracing route to ns03.savvis.net [204.70.25.234] over a maximum > >>>>>>> of > >> 30 > >>>>>>> hops: > >>>>>>> > >>>>>>> 1 1 ms 1 ms 1 ms 10049.webjogger.net [204.8.80.49] > >>>>>>> 2 27 ms 6 ms 5 ms cpe-24-29-112-25.nyc.res.rr.com > >>>>>>> [24.29.112.25] > >>>>>>> 3 12 ms 8 ms 7 ms rdc-69-193-225-74.nyc.bc.twcable.com > >>>>>>> [69.193.225.74] > >>>>>>> 4 9 ms 9 ms 12 ms > rdc-69-193-225-137.nyc.bc.twcable.com > >>>>>>> [69.193.225.137] > >>>>>>> 5 9 ms 10 ms 8 ms > rdc-69-193-225-222.nyc.bc.twcable.com > >>>>>>> [69.193.225.222] > >>>>>>> 6 * * * Request timed out. > >>>>>>> 7 * * * Request timed out. > >>>>>>> 8 * * * Request timed out. > >>>>>>> 9 * * * Request timed out. > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rick > >>>>>>> Coloccia > >>>>>>> Sent: Wednesday, August 27, 2014 6:43 AM > >>>>>>> To: nanog at nanog.org > >>>>>>> Subject: Re: Time Warner outage? > >>>>>>> > >>>>>>> My whole campus (~10000 users) is down... Since roughly 6am. > >>>>>>> TWC is our upstream. > >>>>>>> > >>>>>>> -- > >>>>>>> Sent from my iPhone > >>>>>>> > >>>>>>>> On Aug 27, 2014, at 6:28 AM, Rob Barbeau > >>>>>>>> > >> wrote: > >>>>>>>> > >>>>>>>> David, > >>>>>>>> > >>>>>>>> I have a branch office in Syracuse,NY that appears to be down > >>>>>>>> at the moment that uses a time warner business connection for > >>>>>>>> internet > >> access. > >>>>>>>> > >>>>>>>> -rob > >>>>>>>> On Aug 27, 2014 5:20 AM, "David Hubbard" > >>>>>>>> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Hey all, anyone else having issues with Time Warner > >>>>>>>>> residential or business connections? One of our offices is > >>>>>>>>> down and the route is not currently in bgp. > >>>>>>>>> http://downdetector.com/status/time-warner-cable > >>>>>>>>> shows thousands of reports of outages on the consumer side > >>>>>>>>> starting an hour or so ago so I figure it's a larger issue > >>>>>>>>> than just my one office; couldn't reach anyone by phone. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> > >>>>>>>>> David > >>>> > >>> > >> > >> > > > > > > -- > > //CL > > -- //CL From SNaslund at medline.com Thu Aug 28 14:04:28 2014 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 28 Aug 2014 14:04:28 +0000 Subject: Time Warner outage? In-Reply-To: References: <006201cfc1e4$21507920$63f16b60$@webjogger.net> <90344B7A-BF8A-40B8-A3C5-EA3991F5351D@geneseo.edu> <001b01cfc1ef$253cf490$6fb6ddb0$@webjogger.net> <53FDDC05.6050307@gmail.com> <53FF24BE.2080905@satchell.net> <9578293AE169674F9A048B2BC9A081B40124F7B3B5@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40124F7B435@MUNPRDMBXA1.medline.com> I don?t buy that excuse either. If Level 3 is doing fiber maintenance on any route and takes down your entire network, then you have a pretty poor backbone design. It is not Level 3s fault if you design your network such that a single route loss causes a huge outage. Steven Naslund Chicago IL From: Chris Lane [mailto:clane1875 at gmail.com] Sent: Thursday, August 28, 2014 8:51 AM To: Warren Bailey Cc: Chris Garrett; Naslund, Steve; nanog at nanog.org Subject: Re: Time Warner outage? Agreed on DHCP, just passing along something i had heard about..... With that said, why wouldn't the TW guys just post something oh right they did, blame the other guy "Level3" On Thu, Aug 28, 2014 at 9:42 AM, Warren Bailey > wrote: Sounds more likely than "we broke the dhcp server". Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Chris Garrett > Date: 08/28/2014 6:39 AM (GMT-08:00) To: "Naslund, Steve" > Cc: nanog at nanog.org Subject: Re: Time Warner outage? I have never seen BGP drop peers because of a DHCP failure. I would love to see the breakdown on that. TW NOC had said it was a Level 3 fiber maintenance gone bad that took down their peering connections when we called in at the time of the event. Can anyone confirm one way or the other? On Aug 28, 2014, at 8:29 AM, Naslund, Steve > wrote: > Something sounds really unlikely about that. Lack of DHCP would not cause reachability problems except for the clients. The trace below looks like a transit connection that should be unaffected by DHCP. Looks more like a routing issue. Also sounds unlikely that one DHCP server would be covering this large a scope. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chris Lane > Sent: Thursday, August 28, 2014 8:23 AM > To: Stephen Satchell > Cc: nanog at nanog.org > Subject: Re: Time Warner outage? > > I heard the following, > > It was actually an engineer doing maintenance on the dhpc server that stopped customers from getting an IP address when the connected to the network between 5:30 and 7:00. The funny part is upper Managment heard about it on the today show > > > On Thu, Aug 28, 2014 at 8:46 AM, Stephen Satchell > wrote: > >> This just keeps getting better and better: >> >> "Yahoo Logo >> Will be right back... >> >> Thank you for your patience. >> >> Our engineers are working quickly to resolve the issue." >> >> My upstream is Charter Business... >> >> On 08/28/2014 04:05 AM, Chris Garrett wrote: >>> I believe this is what is commonly referred to in our industry as a >> ?resume generating event?. >>> >>> >>> On Aug 27, 2014, at 8:24 AM, Alexandru Suciu >>> > >> wrote: >>> >>>> Can't wait to see the postmortem report on this one. >>>> >>>> On 8/27/2014 3:05 PM, Adam Greene wrote: >>>>> Came back for us, too, at about 7am. >>>>> >>>>> Outage was a biggie this time: >>>>> >>>>> >> https://news.yahoo.com/time-warner-cable-suffering-massive-nationwide- >> outage >>>>> -110549606.html >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David >> Coulson >>>>> Sent: Wednesday, August 27, 2014 6:59 AM >>>>> To: Rick Coloccia >>>>> Cc: > >>>>> Subject: Re: Time Warner outage? >>>>> >>>>> Just came back up for me. >>>>> >>>>> Sent from my iPad >>>>> >>>>>> On Aug 27, 2014, at 6:48 AM, Rick Coloccia > >> wrote: >>>>>> >>>>>> BGPMON shows my routes falling off the net at around 5:49am. >>>>>> >>>>>> We now sit at their mercy.... >>>>>> >>>>>> >>>>>> -- >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Aug 27, 2014, at 6:46 AM, "Adam Greene" >>>>>>> > >>>>> wrote: >>>>>>> Same here. Seems like no traffic is exiting TWC: >>>>>>> >>>>>>> Tracing route to ns03.savvis.net [204.70.25.234] over a maximum >>>>>>> of >> 30 >>>>>>> hops: >>>>>>> >>>>>>> 1 1 ms 1 ms 1 ms 10049.webjogger.net [204.8.80.49] >>>>>>> 2 27 ms 6 ms 5 ms cpe-24-29-112-25.nyc.res.rr.com >>>>>>> [24.29.112.25] >>>>>>> 3 12 ms 8 ms 7 ms rdc-69-193-225-74.nyc.bc.twcable.com >>>>>>> [69.193.225.74] >>>>>>> 4 9 ms 9 ms 12 ms rdc-69-193-225-137.nyc.bc.twcable.com >>>>>>> [69.193.225.137] >>>>>>> 5 9 ms 10 ms 8 ms rdc-69-193-225-222.nyc.bc.twcable.com >>>>>>> [69.193.225.222] >>>>>>> 6 * * * Request timed out. >>>>>>> 7 * * * Request timed out. >>>>>>> 8 * * * Request timed out. >>>>>>> 9 * * * Request timed out. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rick >>>>>>> Coloccia >>>>>>> Sent: Wednesday, August 27, 2014 6:43 AM >>>>>>> To: nanog at nanog.org >>>>>>> Subject: Re: Time Warner outage? >>>>>>> >>>>>>> My whole campus (~10000 users) is down... Since roughly 6am. >>>>>>> TWC is our upstream. >>>>>>> >>>>>>> -- >>>>>>> Sent from my iPhone >>>>>>> >>>>>>>> On Aug 27, 2014, at 6:28 AM, Rob Barbeau >>>>>>>> > >> wrote: >>>>>>>> >>>>>>>> David, >>>>>>>> >>>>>>>> I have a branch office in Syracuse,NY that appears to be down >>>>>>>> at the moment that uses a time warner business connection for >>>>>>>> internet >> access. >>>>>>>> >>>>>>>> -rob >>>>>>>> On Aug 27, 2014 5:20 AM, "David Hubbard" >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hey all, anyone else having issues with Time Warner >>>>>>>>> residential or business connections? One of our offices is >>>>>>>>> down and the route is not currently in bgp. >>>>>>>>> http://downdetector.com/status/time-warner-cable >>>>>>>>> shows thousands of reports of outages on the consumer side >>>>>>>>> starting an hour or so ago so I figure it's a larger issue >>>>>>>>> than just my one office; couldn't reach anyone by phone. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> David >>>> >>> >> >> > > > -- > //CL -- //CL From rj.bacon at verizon.com Thu Aug 28 14:18:19 2014 From: rj.bacon at verizon.com (Bacon, Ricky (RJ)) Date: Thu, 28 Aug 2014 10:18:19 -0400 Subject: Verizon connectivity issues In-Reply-To: References: Message-ID: <2B7669201D58CD4C8A2150DB12B129CF15DD5247EE@FHDP1LUMXC7V43.us.one.verizon.com> Hi Chris! @Ryan, XO was accurate, the peering connection between 6 and 7 is not congested, nor is it taking any sort of errors. I took a look. The significant increase in rtt seems to happen between 7 and 8 (an Verizon LSP consisting of multiple physical routers). That hop traverses the continental US from San Jose to Philadelphia, so you would expect that, and I don't see anything going on in that path. The end to end rtt is pretty normal, and in any case, it shouldn't prevent your customers from connecting. I am not seeing any packet loss on that path. It's possible that whatever they saw was a transient issue and may be over now. So, please double check with your customers to verify that they still have problems. If so, continue to escalate the ticket. -- rj -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher Morrow Sent: Wednesday, August 27, 2014 10:52 PM To: ryanruuska+nanog at gmail.com Cc: nanog list Subject: Re: Verizon connectivity issues On Mon, Aug 25, 2014 at 1:54 PM, Ryan Ruuska wrote: > Hello all, > > We have heard from many of our customers in the Northeast region, > specifically PA, MD, and VA who have difficulty connecting to our > website there's probably vz customer folk on-list, maybe 'what should they test for you' would be nice? :) > (very slow loading times). We have noticed that if our data center > provider specifically routes our outbound traffic over Hurricane > Electric rather than XO Communications, that connectivity is restored > to normal for our customers. The HE path goes from Salt Lake City to > Denver where it is handed off to TeliaSonera, and they send it to > Chicago where it gets handed off to Verizon. This works great and > generally has a ping response of 20-25ms less than the bad route as posted below from one of our servers: > > Tracing route to pool-108-52-xxx-xxx.phlapa.fios.verizon.net > [108.52.xxx.xxx] > over a maximum of 30 hops: > > 1 <1 ms <1 ms <1 ms 172.xxx.xxx.xxx (Internal IP) > 2 <1 ms 10 ms <1 ms 209-41-xxx-xxx.c7dc.com [209.41.xxx.xxx] > 3 <1 ms <1 ms <1 ms e1-5.rt08.gp1.c7dc.com [192.41.0.97] > 4 2 ms 1 ms 1 ms ip65-46-51-113.z51-46-65.customer.algx.net > [65.46.51.113] > 5 19 ms 18 ms 19 ms vb1611.rar3.sanjose-ca.us.xo.net > [216.156.0.5] > 6 21 ms 18 ms 18 ms 207.88.14.226.ptr.us.xo.net [207.88.14.226] > 7 18 ms 18 ms 18 ms 206.111.6.122.ptr.us.xo.net [206.111.6.122] > >>>> Verizon owned device with an XO IP address > 8 87 ms 86 ms 87 ms b100.phlapa-lcr-22.verizon-gni.net > [130.81.209.187] > >>>> Next hop goes from CA to PA, probably just hidden routing info > 9 * * * Request timed out. > 10 88 ms 89 ms 90 ms pool-108-52-xxx-xxx.phlapa.fios.verizon.net > [108.52.xxx.xxx] > > As you can see, XO sends this traffic from Salt Lake City to San Jose > where it is handed off to Verizon. We've worked with XO and > determined that there are no connectivity issues along their path, > which seems to point to an issue within Verizon's network. I have a > couple of tickets open with Verizon at the moment on behalf of some of > our customers, but we have had trouble breaking through Tier 1. > > Our first thought was saturation of the peering point, but XO states > that the link between hops 6 and 7 is using 5Gbps out of 20Gbps > capacity, and the latency on hop 7 (the Verizon owned device with an > XO IP) seems normal whenever we test. > > Any Verizon engineers out there willing to take a quick peek at this > route for any obvious issues? It would be a lot easier for us if > Verizon provided Looking Glass servers, but alas... they have route data sent to routeviews at least... From wbailey at satelliteintelligencegroup.com Thu Aug 28 14:19:00 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 28 Aug 2014 14:19:00 +0000 Subject: Time Warner outage? In-Reply-To: <9578293AE169674F9A048B2BC9A081B40124F7B435@MUNPRDMBXA1.medline.com> References: <006201cfc1e4$21507920$63f16b60$@webjogger.net> <90344B7A-BF8A-40B8-A3C5-EA3991F5351D@geneseo.edu> <001b01cfc1ef$253cf490$6fb6ddb0$@webjogger.net> <53FDDC05.6050307@gmail.com> <53FF24BE.2080905@satchell.net> <9578293AE169674F9A048B2BC9A081B40124F7B3B5@MUNPRDMBXA1.medline.com> , <9578293AE169674F9A048B2BC9A081B40124F7B435@MUNPRDMBXA1.medline.com> Message-ID: <06cf9jnsh49oc1irwk3qm0xd.1409235532575@email.android.com> As others have said, it's difficult to rationalize a situation where dhcp breaks and your existing routing breaks as well. Especially one that kills the Internet for a couple 100k subs. I'd shoot flames, but all too often I've been the guy working something like this after some maintenance became "service affecting".. Lol If you've ever been responsible for a large Internet connection with a lot of subs, have a beer for the guy answering emails from some no name middle manager about his new found PEP right now. ;) Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: "Naslund, Steve" Date: 08/28/2014 7:06 AM (GMT-08:00) To: nanog at nanog.org Subject: RE: Time Warner outage? I don?t buy that excuse either. If Level 3 is doing fiber maintenance on any route and takes down your entire network, then you have a pretty poor backbone design. It is not Level 3s fault if you design your network such that a single route loss causes a huge outage. Steven Naslund Chicago IL From: Chris Lane [mailto:clane1875 at gmail.com] Sent: Thursday, August 28, 2014 8:51 AM To: Warren Bailey Cc: Chris Garrett; Naslund, Steve; nanog at nanog.org Subject: Re: Time Warner outage? Agreed on DHCP, just passing along something i had heard about..... With that said, why wouldn't the TW guys just post something oh right they did, blame the other guy "Level3" On Thu, Aug 28, 2014 at 9:42 AM, Warren Bailey > wrote: Sounds more likely than "we broke the dhcp server". Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Chris Garrett > Date: 08/28/2014 6:39 AM (GMT-08:00) To: "Naslund, Steve" > Cc: nanog at nanog.org Subject: Re: Time Warner outage? I have never seen BGP drop peers because of a DHCP failure. I would love to see the breakdown on that. TW NOC had said it was a Level 3 fiber maintenance gone bad that took down their peering connections when we called in at the time of the event. Can anyone confirm one way or the other? On Aug 28, 2014, at 8:29 AM, Naslund, Steve > wrote: > Something sounds really unlikely about that. Lack of DHCP would not cause reachability problems except for the clients. The trace below looks like a transit connection that should be unaffected by DHCP. Looks more like a routing issue. Also sounds unlikely that one DHCP server would be covering this large a scope. > > Steven Naslund > Chicago IL > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Chris Lane > Sent: Thursday, August 28, 2014 8:23 AM > To: Stephen Satchell > Cc: nanog at nanog.org > Subject: Re: Time Warner outage? > > I heard the following, > > It was actually an engineer doing maintenance on the dhpc server that stopped customers from getting an IP address when the connected to the network between 5:30 and 7:00. The funny part is upper Managment heard about it on the today show > > > On Thu, Aug 28, 2014 at 8:46 AM, Stephen Satchell > wrote: > >> This just keeps getting better and better: >> >> "Yahoo Logo >> Will be right back... >> >> Thank you for your patience. >> >> Our engineers are working quickly to resolve the issue." >> >> My upstream is Charter Business... >> >> On 08/28/2014 04:05 AM, Chris Garrett wrote: >>> I believe this is what is commonly referred to in our industry as a >> ?resume generating event?. >>> >>> >>> On Aug 27, 2014, at 8:24 AM, Alexandru Suciu >>> > >> wrote: >>> >>>> Can't wait to see the postmortem report on this one. >>>> >>>> On 8/27/2014 3:05 PM, Adam Greene wrote: >>>>> Came back for us, too, at about 7am. >>>>> >>>>> Outage was a biggie this time: >>>>> >>>>> >> https://news.yahoo.com/time-warner-cable-suffering-massive-nationwide- >> outage >>>>> -110549606.html >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of David >> Coulson >>>>> Sent: Wednesday, August 27, 2014 6:59 AM >>>>> To: Rick Coloccia >>>>> Cc: > >>>>> Subject: Re: Time Warner outage? >>>>> >>>>> Just came back up for me. >>>>> >>>>> Sent from my iPad >>>>> >>>>>> On Aug 27, 2014, at 6:48 AM, Rick Coloccia > >> wrote: >>>>>> >>>>>> BGPMON shows my routes falling off the net at around 5:49am. >>>>>> >>>>>> We now sit at their mercy.... >>>>>> >>>>>> >>>>>> -- >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Aug 27, 2014, at 6:46 AM, "Adam Greene" >>>>>>> > >>>>> wrote: >>>>>>> Same here. Seems like no traffic is exiting TWC: >>>>>>> >>>>>>> Tracing route to ns03.savvis.net [204.70.25.234] over a maximum >>>>>>> of >> 30 >>>>>>> hops: >>>>>>> >>>>>>> 1 1 ms 1 ms 1 ms 10049.webjogger.net [204.8.80.49] >>>>>>> 2 27 ms 6 ms 5 ms cpe-24-29-112-25.nyc.res.rr.com >>>>>>> [24.29.112.25] >>>>>>> 3 12 ms 8 ms 7 ms rdc-69-193-225-74.nyc.bc.twcable.com >>>>>>> [69.193.225.74] >>>>>>> 4 9 ms 9 ms 12 ms rdc-69-193-225-137.nyc.bc.twcable.com >>>>>>> [69.193.225.137] >>>>>>> 5 9 ms 10 ms 8 ms rdc-69-193-225-222.nyc.bc.twcable.com >>>>>>> [69.193.225.222] >>>>>>> 6 * * * Request timed out. >>>>>>> 7 * * * Request timed out. >>>>>>> 8 * * * Request timed out. >>>>>>> 9 * * * Request timed out. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rick >>>>>>> Coloccia >>>>>>> Sent: Wednesday, August 27, 2014 6:43 AM >>>>>>> To: nanog at nanog.org >>>>>>> Subject: Re: Time Warner outage? >>>>>>> >>>>>>> My whole campus (~10000 users) is down... Since roughly 6am. >>>>>>> TWC is our upstream. >>>>>>> >>>>>>> -- >>>>>>> Sent from my iPhone >>>>>>> >>>>>>>> On Aug 27, 2014, at 6:28 AM, Rob Barbeau >>>>>>>> > >> wrote: >>>>>>>> >>>>>>>> David, >>>>>>>> >>>>>>>> I have a branch office in Syracuse,NY that appears to be down >>>>>>>> at the moment that uses a time warner business connection for >>>>>>>> internet >> access. >>>>>>>> >>>>>>>> -rob >>>>>>>> On Aug 27, 2014 5:20 AM, "David Hubbard" >>>>>>>> > >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hey all, anyone else having issues with Time Warner >>>>>>>>> residential or business connections? One of our offices is >>>>>>>>> down and the route is not currently in bgp. >>>>>>>>> http://downdetector.com/status/time-warner-cable >>>>>>>>> shows thousands of reports of outages on the consumer side >>>>>>>>> starting an hour or so ago so I figure it's a larger issue >>>>>>>>> than just my one office; couldn't reach anyone by phone. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> David >>>> >>> >> >> > > > -- > //CL -- //CL From morrowc.lists at gmail.com Thu Aug 28 14:32:12 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 28 Aug 2014 10:32:12 -0400 Subject: Verizon connectivity issues In-Reply-To: <2B7669201D58CD4C8A2150DB12B129CF15DD5247EE@FHDP1LUMXC7V43.us.one.verizon.com> References: <2B7669201D58CD4C8A2150DB12B129CF15DD5247EE@FHDP1LUMXC7V43.us.one.verizon.com> Message-ID: On Thu, Aug 28, 2014 at 10:18 AM, Bacon, Ricky (RJ) wrote: > Hi Chris! howdy! > @Ryan, XO was accurate, the peering connection between 6 and 7 is not I had thought Ryan wasn't at XO but an XO customer... I could be mistaken though. congested, nor is it taking any sort of errors. > > I took a look. The significant increase in rtt seems to happen between 7 and 8 (an Verizon LSP consisting of multiple physical routers). That hop traverses the yikes :) lsp's from XT -> LCR now, neat. it's also possible (and likely) that the return path from VZ customer -> Ryan is across either the NYC or DCA links to XO (nyc4 or dca6?)... I agree that the ~65ms cross-country seems on-par with SJC -> PHL on a good day though. continental US from San Jose to Philadelphia, so you would expect that, and I don't see anything going on in that path. The end to end rtt is pretty normal, and in any case, it shouldn't prevent your customers from connecting. I am not seeing any packet loss on that path. It's possible that whatever they saw was a transient issue and may be over now. > > So, please double check with your customers to verify that they still have problems. If so, continue to escalate the ticket. > hopefully ryan's having a better day today :) > -- rj > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher Morrow > Sent: Wednesday, August 27, 2014 10:52 PM > To: ryanruuska+nanog at gmail.com > Cc: nanog list > Subject: Re: Verizon connectivity issues > > On Mon, Aug 25, 2014 at 1:54 PM, Ryan Ruuska wrote: >> Hello all, >> >> We have heard from many of our customers in the Northeast region, >> specifically PA, MD, and VA who have difficulty connecting to our >> website > > there's probably vz customer folk on-list, maybe 'what should they test for you' would be nice? :) > >> (very slow loading times). We have noticed that if our data center >> provider specifically routes our outbound traffic over Hurricane >> Electric rather than XO Communications, that connectivity is restored >> to normal for our customers. The HE path goes from Salt Lake City to >> Denver where it is handed off to TeliaSonera, and they send it to >> Chicago where it gets handed off to Verizon. This works great and >> generally has a ping response of 20-25ms less than the bad route as posted below from one of our servers: >> >> Tracing route to pool-108-52-xxx-xxx.phlapa.fios.verizon.net >> [108.52.xxx.xxx] >> over a maximum of 30 hops: >> >> 1 <1 ms <1 ms <1 ms 172.xxx.xxx.xxx (Internal IP) >> 2 <1 ms 10 ms <1 ms 209-41-xxx-xxx.c7dc.com [209.41.xxx.xxx] >> 3 <1 ms <1 ms <1 ms e1-5.rt08.gp1.c7dc.com [192.41.0.97] >> 4 2 ms 1 ms 1 ms ip65-46-51-113.z51-46-65.customer.algx.net >> [65.46.51.113] >> 5 19 ms 18 ms 19 ms vb1611.rar3.sanjose-ca.us.xo.net >> [216.156.0.5] >> 6 21 ms 18 ms 18 ms 207.88.14.226.ptr.us.xo.net [207.88.14.226] >> 7 18 ms 18 ms 18 ms 206.111.6.122.ptr.us.xo.net [206.111.6.122] >> >>>> Verizon owned device with an XO IP address >> 8 87 ms 86 ms 87 ms b100.phlapa-lcr-22.verizon-gni.net >> [130.81.209.187] >> >>>> Next hop goes from CA to PA, probably just hidden routing info >> 9 * * * Request timed out. >> 10 88 ms 89 ms 90 ms pool-108-52-xxx-xxx.phlapa.fios.verizon.net >> [108.52.xxx.xxx] >> >> As you can see, XO sends this traffic from Salt Lake City to San Jose >> where it is handed off to Verizon. We've worked with XO and >> determined that there are no connectivity issues along their path, >> which seems to point to an issue within Verizon's network. I have a >> couple of tickets open with Verizon at the moment on behalf of some of >> our customers, but we have had trouble breaking through Tier 1. >> >> Our first thought was saturation of the peering point, but XO states >> that the link between hops 6 and 7 is using 5Gbps out of 20Gbps >> capacity, and the latency on hop 7 (the Verizon owned device with an >> XO IP) seems normal whenever we test. >> >> Any Verizon engineers out there willing to take a quick peek at this >> route for any obvious issues? It would be a lot easier for us if >> Verizon provided Looking Glass servers, but alas... > > they have route data sent to routeviews at least... From wesley.george at twcable.com Thu Aug 28 15:16:55 2014 From: wesley.george at twcable.com (George, Wes) Date: Thu, 28 Aug 2014 11:16:55 -0400 Subject: Time Warner outage? In-Reply-To: <06cf9jnsh49oc1irwk3qm0xd.1409235532575@email.android.com> References: <006201cfc1e4$21507920$63f16b60$@webjogger.net> <90344B7A-BF8A-40B8-A3C5-EA3991F5351D@geneseo.edu> <001b01cfc1ef$253cf490$6fb6ddb0$@webjogger.net> <53FDDC05.6050307@gmail.com> <53FF24BE.2080905@satchell.net> <9578293AE169674F9A048B2BC9A081B40124F7B3B5@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B40124F7B435@MUNPRDMBXA1.medline.com> <06cf9jnsh49oc1irwk3qm0xd.1409235532575@email.android.com> Message-ID: I am not cleared to give further details, but in the hopes of providing a little more accurate info, I can point you at the following blog post http://www.twcableuntangled.com/2014/08/twc-identifies-cause-of-internet-ou tage/ Thanks, Wes George Anything below this line has been added by my company?s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From jra at baylink.com Thu Aug 28 16:57:53 2014 From: jra at baylink.com (Jay Ashworth) Date: Thu, 28 Aug 2014 12:57:53 -0400 (EDT) Subject: Time Warner outage? In-Reply-To: <9578293AE169674F9A048B2BC9A081B40124F7B435@MUNPRDMBXA1.medline.com> Message-ID: <23144097.10213.1409245073995.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Steve Naslund" > I don?t buy that excuse either. If Level 3 is doing fiber maintenance > on any route and takes down your entire network, then you have a > pretty poor backbone design. It is not Level 3s fault if you design > your network such that a single route loss causes a huge outage. Does the T-Bone run over L3? I thought it was either owned or dark-leased fiber and their own routers... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From chris at aperturefiber.com Thu Aug 28 17:37:11 2014 From: chris at aperturefiber.com (Chris Garrett) Date: Thu, 28 Aug 2014 12:37:11 -0500 Subject: Time Warner outage? In-Reply-To: <23144097.10213.1409245073995.JavaMail.root@benjamin.baylink.com> References: <23144097.10213.1409245073995.JavaMail.root@benjamin.baylink.com> Message-ID: Based on the link that Wes shared, sounds like someone made a BGP boo boo. Not that I routed damn near the whole internet down a customers DS3 or anything once, but I can see how it could happen and then propagate out of control before it was caught. On Aug 28, 2014, at 11:57 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Steve Naslund" > >> I don?t buy that excuse either. If Level 3 is doing fiber maintenance >> on any route and takes down your entire network, then you have a >> pretty poor backbone design. It is not Level 3s fault if you design >> your network such that a single route loss causes a huge outage. > > Does the T-Bone run over L3? I thought it was either owned or dark-leased > fiber and their own routers... > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From lyle at lcrcomputer.net Thu Aug 28 19:04:22 2014 From: lyle at lcrcomputer.net (Lyle Giese) Date: Thu, 28 Aug 2014 14:04:22 -0500 Subject: Contact at NetSuite DNS operations? Message-ID: <53FF7D36.9050803@lcrcomputer.net> I discovered that NetSuite's dns servers ens0 & 1 .netsuite.com are invisible from Comcast's business services in the Chicago area(limits of my testing abilities) but I can reach these same servers from a Linode virtual system in the Dallas, TX area. Looks like it's been this way for at least two months. If someone from NetSuite could say hi and look into it, I am sure it will help NetSuite more than me. Lyle Giese LCR Computer Services, Inc. From nicotine at warningg.com Thu Aug 28 20:07:04 2014 From: nicotine at warningg.com (Brandon Ewing) Date: Thu, 28 Aug 2014 15:07:04 -0500 Subject: Broken IPv6 firmware on U-Verse 3801HGV In-Reply-To: References: Message-ID: <20140828200704.GC31480@radiological.warningg.com> On Tue, Aug 26, 2014 at 01:50:29AM +0000, Ivan Kozik wrote: > All for naught, though. With IPv6 enabled, the 3801HGV crashed and > rebooted about once an hour. After unchecking "IPv6 LAN Enabled" in > http://192.168.1.254/xslt?PAGE=C_2_6 everything went back to normal. > This happened to me as well. I called support, they rolled a truck and installed the NVG589. Had them come back out a week later and bond the pairs, and IPv6 via their 6RD is working without issue. At the time, I thought it was an actual hardware issue. After a few reboot cycles, it was only staying up ~3 seconds at a time before rebooting again. -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From trelane at trelane.net Thu Aug 28 23:37:13 2014 From: trelane at trelane.net (Andrew Kirch) Date: Thu, 28 Aug 2014 19:37:13 -0400 Subject: Broken IPv6 firmware on U-Verse 3801HGV In-Reply-To: <20140828200704.GC31480@radiological.warningg.com> References: <20140828200704.GC31480@radiological.warningg.com> Message-ID: <53FFBD29.1010407@trelane.net> please refer to the e-mail I sent to this list last December about IPv6 and u-verse. On 8/28/2014 4:07 PM, Brandon Ewing wrote: > On Tue, Aug 26, 2014 at 01:50:29AM +0000, Ivan Kozik wrote: >> All for naught, though. With IPv6 enabled, the 3801HGV crashed and >> rebooted about once an hour. After unchecking "IPv6 LAN Enabled" in >> http://192.168.1.254/xslt?PAGE=C_2_6 everything went back to normal. >> > This happened to me as well. I called support, they rolled a truck and installed > the NVG589. Had them come back out a week later and bond the pairs, and > IPv6 via their 6RD is working without issue. > > At the time, I thought it was an actual hardware issue. After a few reboot > cycles, it was only staying up ~3 seconds at a time before rebooting again. > From lists at tarundua.net Thu Aug 28 16:55:25 2014 From: lists at tarundua.net (Tarun Dua) Date: Thu, 28 Aug 2014 22:25:25 +0530 Subject: Prefix hijacking, how to prevent and fix currently Message-ID: AS Number 43239 AS Name SPETSENERGO-AS SpetsEnergo Ltd. Has started hijacking our IPv4 prefix, while this prefix was NOT in production, it worries us that it was this easy for someone to hijack it. http://bgp.he.net/AS43239#_prefixes 103.20.212.0/22 <- This belongs to us. 103.238.232.0/22 KNS Techno Integrators Pvt. Ltd. 193.43.33.0/24 hydrocontrol S.C.R.L. 193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline Where do we complain to get this fixed. -Tarun AS132420 From eric.stoltz at neovera.com Thu Aug 28 19:17:37 2014 From: eric.stoltz at neovera.com (Eric Stoltz) Date: Thu, 28 Aug 2014 15:17:37 -0400 Subject: Time Warner outage? In-Reply-To: References: <23144097.10213.1409245073995.JavaMail.root@benjamin.baylink.com> Message-ID: <53FF8051.5060300@neovera.com> Looks like TW is having further issues this afternoon. Eric Stoltz Neovera On 08/28/2014 01:37 PM, Chris Garrett wrote: > Based on the link that Wes shared, sounds like someone made a BGP boo boo. > > Not that I routed damn near the whole internet down a customers DS3 or anything once, but I can see how it could happen and then propagate out of control before it was caught. > > On Aug 28, 2014, at 11:57 AM, Jay Ashworth wrote: > >> ----- Original Message ----- >>> From: "Steve Naslund" >>> I don?t buy that excuse either. If Level 3 is doing fiber maintenance >>> on any route and takes down your entire network, then you have a >>> pretty poor backbone design. It is not Level 3s fault if you design >>> your network such that a single route loss causes a huge outage. >> Does the T-Bone run over L3? I thought it was either owned or dark-leased >> fiber and their own routers... >> >> Cheers, >> -- jra >> -- >> Jay R. Ashworth Baylink jra at baylink.com >> Designer The Things I Think RFC 2100 >> Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII >> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From faisal at snappytelecom.net Fri Aug 29 03:23:53 2014 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Fri, 29 Aug 2014 03:23:53 +0000 (GMT) Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: References: Message-ID: <1682409954.354489.1409282633515.JavaMail.zimbra@snappytelecom.net> I would say, start off with the NOC Contact http://bgp.he.net/AS43239#_whois It is most likely that someone has fat-fingered the IP space.. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Tarun Dua" > To: nanog at nanog.org > Sent: Thursday, August 28, 2014 12:55:25 PM > Subject: Prefix hijacking, how to prevent and fix currently > > AS Number 43239 > AS Name SPETSENERGO-AS SpetsEnergo Ltd. > > Has started hijacking our IPv4 prefix, while this prefix was NOT in > production, it worries us that it was this easy for someone to hijack > it. > > http://bgp.he.net/AS43239#_prefixes > > 103.20.212.0/22 <- This belongs to us. > > 103.238.232.0/22 KNS Techno Integrators Pvt. Ltd. > 193.43.33.0/24 hydrocontrol S.C.R.L. > 193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline > > Where do we complain to get this fixed. > > -Tarun > AS132420 > From fred at cisco.com Fri Aug 29 03:24:28 2014 From: fred at cisco.com (Fred Baker (fred)) Date: Fri, 29 Aug 2014 03:24:28 +0000 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: References: Message-ID: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> On Aug 28, 2014, at 9:55 AM, Tarun Dua wrote: > AS Number 43239 > AS Name SPETSENERGO-AS SpetsEnergo Ltd. > > Has started hijacking our IPv4 prefix, while this prefix was NOT in > production, it worries us that it was this easy for someone to hijack > it. > > http://bgp.he.net/AS43239#_prefixes > > 103.20.212.0/22 <- This belongs to us. > > 103.238.232.0/22 KNS Techno Integrators Pvt. Ltd. > 193.43.33.0/24 hydrocontrol S.C.R.L. > 193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline > > Where do we complain to get this fixed. > > -Tarun > AS132420 Do you implement RPKI? Are providers that neighbor with them implementing RPKI? If not, complain to the folks not indicating RPKI and therefore accepting a hijacked prefix. Including yourself. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ops.lists at gmail.com Fri Aug 29 03:27:35 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 29 Aug 2014 08:57:35 +0530 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: <1682409954.354489.1409282633515.JavaMail.zimbra@snappytelecom.net> References: <1682409954.354489.1409282633515.JavaMail.zimbra@snappytelecom.net> Message-ID: In this case.. Google that ASN name. Then go upstream. On 29-Aug-2014 8:56 am, "Faisal Imtiaz" wrote: > I would say, start off with the NOC Contact > > http://bgp.he.net/AS43239#_whois > > It is most likely that someone has fat-fingered the IP space.. > > > Faisal Imtiaz > Snappy Internet & Telecom > > ----- Original Message ----- > > From: "Tarun Dua" > > To: nanog at nanog.org > > Sent: Thursday, August 28, 2014 12:55:25 PM > > Subject: Prefix hijacking, how to prevent and fix currently > > > > AS Number 43239 > > AS Name SPETSENERGO-AS SpetsEnergo Ltd. > > > > Has started hijacking our IPv4 prefix, while this prefix was NOT in > > production, it worries us that it was this easy for someone to hijack > > it. > > > > http://bgp.he.net/AS43239#_prefixes > > > > 103.20.212.0/22 <- This belongs to us. > > > > 103.238.232.0/22 KNS Techno Integrators Pvt. Ltd. > > 193.43.33.0/24 hydrocontrol S.C.R.L. > > 193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline > > > > Where do we complain to get this fixed. > > > > -Tarun > > AS132420 > > > From marka at isc.org Fri Aug 29 03:28:38 2014 From: marka at isc.org (Mark Andrews) Date: Fri, 29 Aug 2014 13:28:38 +1000 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: Your message of "Thu, 28 Aug 2014 22:25:25 +0530." References: Message-ID: <20140829032838.B32F41DC11B5@rock.dv.isc.org> See "whois -r AS43239". The long term solution is to deploy RPKI and only use transits which use RPKI. No RPKI support => no business. Additionally make RPKI a peering requirement. Mark In message , Tarun Dua writes: > AS Number 43239 > AS Name SPETSENERGO-AS SpetsEnergo Ltd. > > Has started hijacking our IPv4 prefix, while this prefix was NOT in > production, it worries us that it was this easy for someone to hijack > it. > > http://bgp.he.net/AS43239#_prefixes > > 103.20.212.0/22 <- This belongs to us. > > 103.238.232.0/22 KNS Techno Integrators Pvt. Ltd. > 193.43.33.0/24 hydrocontrol S.C.R.L. > 193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline > > Where do we complain to get this fixed. > > -Tarun > AS132420 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mawatari at jpix.ad.jp Fri Aug 29 08:34:53 2014 From: mawatari at jpix.ad.jp (MAWATARI Masataka) Date: Fri, 29 Aug 2014 17:34:53 +0900 Subject: JANOG 34 Meeting Report Message-ID: <20140829173453.81D7.8FE1F57E@jpix.ad.jp> Dear Colleagues, We'd like to share some of the discussions from JANOG 34 held in Takamatsu-city, from 17-18 July with over 500 participants. While our discussions are in Japanese, we believe there are issues in common with operators outside Japan. An english version of the Summary Report and a report on anti-spam measures session is be made available this time, below. JANOG 34 Summary Report and "Let's talk about IP anycast" : http://goo.gl/IbKzkQ Pick up Session: "Measures against Spam after OP25B" : http://goo.gl/uY4lxk The topics discussed are not limited to these two topics of course. Please see the translated overview of the program and the presentation slides (in Japanese but some have visual images and data). Program Overview (English): http://goo.gl/KhrpRZ Program and Slides (Japanese): http://goo.gl/Q61oeh Here are some examples of the topics covered: * Use of technologies - Visualising network events - Advantages and disadvantages of "white box networking" * Operational issues - Blind spots of IPv6 PMTU Blackhole Discovery - NTP attacks: "NTP Talk WG": http://goo.gl/5RL50v - OpenSSL heartbleed bug - Stopping full table routing changed my life @ AS55394 * Social aspects - Seeking change in the cost structure of content delivery - Balance of outreach on security issues - What is good higher education for future engineers - Cultural differences in software and network engineers At the meeting, we ran the JANOG 34 network with IPv6 ULA-only and ULA + GUA SSIDs, which was presented at the IPv6 Operations session @ IETF90 in Toronto. ULA Experience at JANOG 34 http://tools.ietf.org/agenda/90/slides/slides-90-v6ops-1.pdf Positive findings - GUA + IPv4 (Private) and ULA is harmless (at least for MAC OS) - SLAAC/ULA and DHCPv6/ULA works well - ULA operation/configuration is not hard Challenges - Android devices did not come up without IPv4 - IPv4 only applications still exist (Skype/dropbox) - NAT66 on ULA only network should not be recommended , but it worked If you have any feedback, we welcome comments or questions on JANOG mailing list "janog at janog.gr.jp": https://www.janog.gr.jp/mailman/listinfo/janog/ * Subscription page first appears in Japanese but it's possible to switch to English from pull-down menu options on the top right The coming meeting, JANOG 35 will be from 14-16 Jan 2015 in Shizuoka Prefecture. We'll update you with more details through our SNS accounts as the date gets closer. Masataka Mawatari, Izumi Okutani JANOG Internationalization(i18n) team http://www.janog.gr.jp/en/index.php?i18n-team Facebook: https://www.facebook.com/janogmeetingi18n Twitter : https://twitter.com/janog_i18n ------------------------------------------------------------------- -- Japan Internet Exchange MAWATARI Masataka From saku at ytti.fi Fri Aug 29 08:55:11 2014 From: saku at ytti.fi (Saku Ytti) Date: Fri, 29 Aug 2014 11:55:11 +0300 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> References: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> Message-ID: <20140829085511.GA4082@pob.ytti.fi> On (2014-08-29 03:24 +0000), Fred Baker (fred) wrote: > Do you implement RPKI? Are providers that neighbor with them implementing RPKI? I feel RPKI would be much more marketable if vendors would implement 'loose' mode. Loose mode would drop failing routes, iff there is covering (i.e. less specific is ok) route already in RIB. This mode would protect from routed hijacks, but not from non-routed hijacks, which are less serious. And it would completely remove false-positive blackholing. There is very small incentive for SP to deploy RPKI, since user-error in far-end, would make my product look worse than competitors product. I'm spending money to lose money. -- ++ytti From randy at psg.com Fri Aug 29 09:25:16 2014 From: randy at psg.com (Randy Bush) Date: Fri, 29 Aug 2014 18:25:16 +0900 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: <20140829085511.GA4082@pob.ytti.fi> References: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> <20140829085511.GA4082@pob.ytti.fi> Message-ID: > Loose mode would drop failing routes, iff there is covering (i.e. less > specific is ok) route already in RIB. isn't that exactly the hole punching attack? randy From job at instituut.net Fri Aug 29 09:29:31 2014 From: job at instituut.net (Job Snijders) Date: Fri, 29 Aug 2014 11:29:31 +0200 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: References: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> <20140829085511.GA4082@pob.ytti.fi> Message-ID: <20140829092931.GM44548@Vurt.local> On Fri, Aug 29, 2014 at 06:25:16PM +0900, Randy Bush wrote: > > Loose mode would drop failing routes, iff there is covering (i.e. less > > specific is ok) route already in RIB. > > isn't that exactly the hole punching attack? The proposed 'loose' mode protects against unauthorized hole punching From brandon at rd.bbc.co.uk Fri Aug 29 09:28:48 2014 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 29 Aug 2014 10:28:48 +0100 (BST) Subject: Prefix hijacking, how to prevent and fix currently Message-ID: <201408290928.KAA02252@sunf10.rd.bbc.co.uk> > From: Saku Ytti > I feel RPKI would be much more marketable if vendors would implement 'loose' > mode. > Loose mode would drop failing routes, iff there is covering (i.e. less > specific is ok) route already in RIB. +10 > And it would completely remove false-positive blackholing. This is why I don't want strict. That and true-positives, I don't think having a switch that allows courts/rir finger trouble etc to take out global routing is sensible. Too many others would start using it. However loose mode could be abused in the same way, they just invalidate your key and advertise a covering route to give themselves effective strict over you. Admittedly there is collateral damage to adjacent address space incurred in doing this but we know there are hijack techniques they could use to mitigate that brandon From karsten_thomann at linfre.de Fri Aug 29 09:34:20 2014 From: karsten_thomann at linfre.de (Karsten Thomann) Date: Fri, 29 Aug 2014 11:34:20 +0200 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: References: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> <20140829085511.GA4082@pob.ytti.fi> Message-ID: <5400491C.8040008@linfre.de> Am 29.08.2014 11:25, schrieb Randy Bush: >> Loose mode would drop failing routes, iff there is covering (i.e. less >> specific is ok) route already in RIB. > isn't that exactly the hole punching attack? > > randy No, as the the more specific route is signed and is preferred (longest match routing) against the less specific hijacked route From randy at psg.com Fri Aug 29 09:39:32 2014 From: randy at psg.com (Randy Bush) Date: Fri, 29 Aug 2014 18:39:32 +0900 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: <5400491C.8040008@linfre.de> References: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> <20140829085511.GA4082@pob.ytti.fi> <5400491C.8040008@linfre.de> Message-ID: >>> Loose mode would drop failing routes, iff there is covering (i.e. less >>> specific is ok) route already in RIB. >> isn't that exactly the hole punching attack? > No, as the the more specific route is signed and is preferred (longest > match routing) against the less specific hijacked route clearly i am missing something. got a write-up? randy From karsten_thomann at linfre.de Fri Aug 29 09:43:39 2014 From: karsten_thomann at linfre.de (Karsten Thomann) Date: Fri, 29 Aug 2014 11:43:39 +0200 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: References: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> <20140829085511.GA4082@pob.ytti.fi> <5400491C.8040008@linfre.de> Message-ID: <54004B4B.4050202@linfre.de> Am 29.08.2014 11:39, schrieb Randy Bush: >>>> Loose mode would drop failing routes, iff there is covering (i.e. less >>>> specific is ok) route already in RIB. >>> isn't that exactly the hole punching attack? >> No, as the the more specific route is signed and is preferred (longest >> match routing) against the less specific hijacked route > clearly i am missing something. got a write-up? > > randy sorry my mistake, you're right From randy at psg.com Fri Aug 29 09:48:47 2014 From: randy at psg.com (Randy Bush) Date: Fri, 29 Aug 2014 18:48:47 +0900 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: <54004B4B.4050202@linfre.de> References: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> <20140829085511.GA4082@pob.ytti.fi> <5400491C.8040008@linfre.de> <54004B4B.4050202@linfre.de> Message-ID: >>>>> Loose mode would drop failing routes, iff there is covering (i.e. less >>>>> specific is ok) route already in RIB. >>>> isn't that exactly the hole punching attack? >>> No, as the the more specific route is signed and is preferred (longest >>> match routing) against the less specific hijacked route >> clearly i am missing something. got a write-up? > sorry my mistake, you're right been around this a few times. no magic pill found. would love to learn of one. but one either wants to stop mis-originations or not. but i would like to see an actual write-up of this 'loose mode' and terse would be fine, heck preferred. :) randy From job at instituut.net Fri Aug 29 10:08:15 2014 From: job at instituut.net (Job Snijders) Date: Fri, 29 Aug 2014 12:08:15 +0200 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: References: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> <20140829085511.GA4082@pob.ytti.fi> <5400491C.8040008@linfre.de> Message-ID: <20140829100815.GO44548@Vurt.local> On Fri, Aug 29, 2014 at 06:39:32PM +0900, Randy Bush wrote: > >>> Loose mode would drop failing routes, iff there is covering (i.e. less > >>> specific is ok) route already in RIB. > >> isn't that exactly the hole punching attack? > > No, as the the more specific route is signed and is preferred (longest > > match routing) against the less specific hijacked route > > clearly i am missing something. got a write-up? I'll attempt to clarify. Assume: ROA: 10.0.0.0/16, max_length = 16, origin = AS123 in RIB: 10.0.0.0/16 origin AS123 (valid) With the above two conditions any updates containing more-specifics of 10.0.0.0/16 would be rejected/not-installed, just like in todays 'strict mode' Loose mode A would look like this: In the case that 10.0.0.0/16 origin AS123 is not in your table, the loose mode would kick in and one could accept more specifics for 10.0.0.0/16, but only when originated by AS123. Loose mode B would look like this: In the case that 10.0.0.0/16 origin AS123 is not in your table, the loose mode would kick in and one could accept more specifics for 10.0.0.0/16 originated by any ASN. The major point is that when the valid route is missing, one might choose to accept invalid routes. When the valid route returns, the invalids are purged from your table. Or in other words: Proposal is, that when additional 'loose' mode is configured, invalid routes are accepted if and only if they are the only route to destination. If there is any other route (less-specific) which is not invalid, it will be used, instead of the invalid route. Kind regards, Job From sandy at tislabs.com Fri Aug 29 10:17:09 2014 From: sandy at tislabs.com (Sandra Murphy) Date: Fri, 29 Aug 2014 06:17:09 -0400 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: <20140829100815.GO44548@Vurt.local> References: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> <20140829085511.GA4082@pob.ytti.fi> <5400491C.8040008@linfre.de> <20140829100815.GO44548@Vurt.local> Message-ID: On Aug 29, 2014, at 6:08 AM, Job Snijders wrote: > On Fri, Aug 29, 2014 at 06:39:32PM +0900, Randy Bush wrote: >>>>> Loose mode would drop failing routes, iff there is covering (i.e. less >>>>> specific is ok) route already in RIB. >>>> isn't that exactly the hole punching attack? >>> No, as the the more specific route is signed and is preferred (longest >>> match routing) against the less specific hijacked route >> >> clearly i am missing something. got a write-up? > > I'll attempt to clarify. > > Assume: > > ROA: 10.0.0.0/16, max_length = 16, origin = AS123 > in RIB: 10.0.0.0/16 origin AS123 (valid) > > With the above two conditions any updates containing more-specifics > of 10.0.0.0/16 would be rejected/not-installed, just like in todays > 'strict mode' > > Loose mode A would look like this: > > In the case that 10.0.0.0/16 origin AS123 is not in your table, the > loose mode would kick in and one could accept more specifics for > 10.0.0.0/16, but only when originated by AS123. > > Loose mode B would look like this: > > In the case that 10.0.0.0/16 origin AS123 is not in your table, the > loose mode would kick in and one could accept more specifics for > 10.0.0.0/16 originated by any ASN. > > The major point is that when the valid route is missing, one might > choose to accept invalid routes. When the valid route returns, the > invalids are purged from your table. > > Or in other words: Proposal is, that when additional 'loose' mode is > configured, invalid routes are accepted if and only if they are the only > route to destination. If there is any other route (less-specific) which > is not invalid, it will be used, instead of the invalid route. In your examples, you presume there's a ROA for the less-specific. Here you say "not invalid", which would mean a route that is "unknown", i.e. no ROA exists. Your Loose Mode A relies on the existence of the ROA - you accept more specifics but only when originated by the ASN in the ROA. So which do you mean? The less specific has a ROA or the less specific may not have a ROA? (Just trying to work this out in my head.) --Sandy P.S. All the RPKI use is subject to local routing policy, so working out impact of different policies is a really good thing. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From job at instituut.net Fri Aug 29 10:25:59 2014 From: job at instituut.net (Job Snijders) Date: Fri, 29 Aug 2014 12:25:59 +0200 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: References: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> <20140829085511.GA4082@pob.ytti.fi> <5400491C.8040008@linfre.de> <20140829100815.GO44548@Vurt.local> Message-ID: <20140829102559.GP44548@Vurt.local> On Fri, Aug 29, 2014 at 06:17:09AM -0400, Sandra Murphy wrote: > > Loose mode A would look like this: > > > > In the case that 10.0.0.0/16 origin AS123 is not in your table, the > > loose mode would kick in and one could accept more specifics for > > 10.0.0.0/16, but only when originated by AS123. > > > > Loose mode B would look like this: > > > > In the case that 10.0.0.0/16 origin AS123 is not in your table, the > > loose mode would kick in and one could accept more specifics for > > 10.0.0.0/16 originated by any ASN. > > > > The major point is that when the valid route is missing, one might > > choose to accept invalid routes. When the valid route returns, the > > invalids are purged from your table. > > > > Or in other words: Proposal is, that when additional 'loose' mode is > > configured, invalid routes are accepted if and only if they are the only > > route to destination. If there is any other route (less-specific) which > > is not invalid, it will be used, instead of the invalid route. > > In your examples, you presume there's a ROA for the less-specific. Correct. > Here you say "not invalid", which would mean a route that is > "unknown", i.e. no ROA exists. Sorry, with "not invalid" i meant "valid". > Your Loose Mode A relies on the existence of the ROA - you accept more > specifics but only when originated by the ASN in the ROA. I'd like to accept more-specifics, only in the absense of the less-specific ROA covered prefix. > So which do you mean? The less specific has a ROA or the less > specific may not have a ROA? The less specific has to have a ROA, for any loose mode to make sense. Loose mode A & B came into existence 15 minutes ago, its good to discuss what a loose mode could mean. ;-) Kind regards, Job From saku at ytti.fi Fri Aug 29 11:37:10 2014 From: saku at ytti.fi (Saku Ytti) Date: Fri, 29 Aug 2014 14:37:10 +0300 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: References: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> <20140829085511.GA4082@pob.ytti.fi> <5400491C.8040008@linfre.de> Message-ID: <20140829113710.GA13827@pob.ytti.fi> On (2014-08-29 18:39 +0900), Randy Bush wrote: > clearly i am missing something. got a write-up? Job got to it, but shortly: Loose mode RPKI: - verified or unknown less-specific route is preferable to failing more-specific The main goal is always to have all routes, never to blackhole, prefering bad route over no route. -- ++ytti From saku at ytti.fi Fri Aug 29 11:47:29 2014 From: saku at ytti.fi (Saku Ytti) Date: Fri, 29 Aug 2014 14:47:29 +0300 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: <20140829113710.GA13827@pob.ytti.fi> References: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> <20140829085511.GA4082@pob.ytti.fi> <5400491C.8040008@linfre.de> <20140829113710.GA13827@pob.ytti.fi> Message-ID: <20140829114729.GB13827@pob.ytti.fi> On (2014-08-29 14:37 +0300), Saku Ytti wrote: > > clearly i am missing something. got a write-up? > > Loose mode RPKI: > - verified or unknown less-specific route is preferable to failing more-specific Or said otherwise when choosing route from Adj-RIBs-In to Loc-RIB longest match is not done to whole population, population is first divided to 'verified', 'unknown' and 'failed' routes, and longest match is done for each sub-population in order, until match is found. -- ++ytti From wesley.george at twcable.com Fri Aug 29 12:13:45 2014 From: wesley.george at twcable.com (George, Wes) Date: Fri, 29 Aug 2014 08:13:45 -0400 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> References: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> Message-ID: On 8/28/14, 11:28 PM, "Mark Andrews" wrote: > The long term solution is to deploy RPKI and only use > transits which use RPKI. No RPKI support => no business. > Additionally make RPKI a peering requirement. WG] So should we ask for that before, or after we get everyone to roll out IPv6 everywhere by voting with our wallets? *ducks* On 8/28/14, 11:24 PM, "Fred Baker (fred)" wrote: >Are providers that neighbor with them implementing RPKI? >If not, complain to the folks not indicating RPKI and therefore accepting >a hijacked prefix. WG] %s/RPKI/inbound route filtering on downstream customers/g There, FTFY Tarun, other than directly contacting the originator, I recommend that you complain to their upstream provider(s) (the neighboring ASN(s) in the AS-Path) that they are accepting routes from their customer that they shouldn't be, include proof that you own the block they are announcing, and ask them to apply a prefix filter. Yes, this presupposes that you can find valid contact info in whois or peeringdb, but it's the best we've got right now. RPKI isn't likely to fix this anytime soon, because it's mostly not deployed where it needs to be to affect this problem. And just like inbound route filtering and lots of other protective security measures, [1, 2] and eating your vegetables, and getting more exercise, most folks agree that it would help, but it's only useful with wide deployment, which mostly needs to happen on "everyone else's network", and those things all have an additional cost (time, money, or both) to deploy and maintain. The unfortunate thing is that RPKI arguably takes more work than the others, with a much longer time-horizon to see benefit during the incremental deployment period. Wes George [1] https://www.routingmanifesto.org/manifesto/ [2] http://tools.ietf.org/html/draft-ietf-opsec-bgp-security Anything below this line has been added by my company?s mail server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From randy at psg.com Fri Aug 29 12:38:41 2014 From: randy at psg.com (Randy Bush) Date: Fri, 29 Aug 2014 21:38:41 +0900 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: <20140829102559.GP44548@Vurt.local> References: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> <20140829085511.GA4082@pob.ytti.fi> <5400491C.8040008@linfre.de> <20140829100815.GO44548@Vurt.local> <20140829102559.GP44548@Vurt.local> Message-ID: > Loose mode A & B came into existence 15 minutes ago, its good to > discuss what a loose mode could mean. ;-) i am ENOTIME. when you have a simple spec i can follow, i would really look forward to it. randy From randy at psg.com Fri Aug 29 13:08:45 2014 From: randy at psg.com (Randy Bush) Date: Fri, 29 Aug 2014 22:08:45 +0900 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: References: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> Message-ID: >> The long term solution is to deploy RPKI and only use >> transits which use RPKI. No RPKI support => no business. >> Additionally make RPKI a peering requirement. > WG] So should we ask for that before, or after we get everyone to roll > out IPv6 everywhere by voting with our wallets? considering that measured rpki registration (which has a very tragic side) is ten time ipv6 penetration, i think we ask for rpki first. but keep shoveling. it's a good week for twt. randy From rdalleva at constantcontact.com Fri Aug 29 13:21:47 2014 From: rdalleva at constantcontact.com (D'Alleva, Ron) Date: Fri, 29 Aug 2014 13:21:47 +0000 Subject: GoDaddy Contact Message-ID: Greetings, Can someone from GoDaddy please contact me off list? Two of our name servers have been block from making DNS lookups against your hosted domains. Many Thanks, -- Ronald D'Alleva Email: rdalleva at constantcontact.com From wesley.george at twcable.com Fri Aug 29 14:27:34 2014 From: wesley.george at twcable.com (George, Wes) Date: Fri, 29 Aug 2014 10:27:34 -0400 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: References: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> Message-ID: On 8/29/14, 9:08 AM, "Randy Bush" wrote: >considering that measured rpki registration (which has a very tragic >side) is ten time ipv6 penetration, i think we ask for rpki first. WG] I guess I should know better than to ask rhetorical questions on NANOG, lest I get an answer. The horse race to determine the fastest lame horse is a rather boring one to watch, but unless you're counting how many ASNs have IPv6 allocations (whether they're using them or not) as a measure of IPv6 penetration, counting RPKI registrations as penetration doesn't lead to a useful comparison. Number of ASNs doing *validation* and discarding invalid routes (especially among top transit N ASNs by reach) would be far more telling as a measure of penetration, since it directly impacts RPKI's relative effectiveness at preventing hijacks such as the original poster was experiencing. > >but keep shoveling. it's a good week for twt. WG] Randy, if you're going to try to poke me in the eye about an outage in lieu of a snappy comeback, the least you could do is get my company's name right. ;-) It'll be in the stupidly long disclaimer at the bottom of this message for future reference, but it's in the first sentence, so you don't even have to read the whole thing. Wes This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From cscora at apnic.net Fri Aug 29 18:11:41 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 30 Aug 2014 04:11:41 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201408291811.s7TIBfK4031987@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, TRNOG, 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 Aug, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 509487 Prefixes after maximum aggregation: 197642 Deaggregation factor: 2.58 Unique aggregates announced to Internet: 249829 Total ASes present in the Internet Routing Table: 47575 Prefixes per ASN: 10.71 Origin-only ASes present in the Internet Routing Table: 36092 Origin ASes announcing only one prefix: 16390 Transit ASes present in the Internet Routing Table: 6138 Transit-only ASes present in the Internet Routing Table: 181 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1642 Unregistered ASNs in the Routing Table: 442 Number of 32-bit ASNs allocated by the RIRs: 7296 Number of 32-bit ASNs visible in the Routing Table: 5345 Prefixes from 32-bit ASNs in the Routing Table: 19533 Number of bogon 32-bit ASNs visible in the Routing Table: 619 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 347 Number of addresses announced to Internet: 2717084100 Equivalent to 161 /8s, 243 /16s and 105 /24s Percentage of available address space announced: 73.4 Percentage of allocated address space announced: 73.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.8 Total number of prefixes smaller than registry allocations: 175050 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 124591 Total APNIC prefixes after maximum aggregation: 36399 APNIC Deaggregation factor: 3.42 Prefixes being announced from the APNIC address blocks: 128175 Unique aggregates announced from the APNIC address blocks: 52441 APNIC Region origin ASes present in the Internet Routing Table: 4981 APNIC Prefixes per ASN: 25.73 APNIC Region origin ASes announcing only one prefix: 1226 APNIC Region transit ASes present in the Internet Routing Table: 865 Average APNIC Region AS path length visible: 4.8 Max APNIC Region AS path length visible: 24 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1071 Number of APNIC addresses announced to Internet: 735509312 Equivalent to 43 /8s, 214 /16s and 251 /24s Percentage of available APNIC address space announced: 86.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 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, 150/8, 153/8, 163/8, 171/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: 169628 Total ARIN prefixes after maximum aggregation: 84831 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 171579 Unique aggregates announced from the ARIN address blocks: 80176 ARIN Region origin ASes present in the Internet Routing Table: 16344 ARIN Prefixes per ASN: 10.50 ARIN Region origin ASes announcing only one prefix: 6114 ARIN Region transit ASes present in the Internet Routing Table: 1690 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 177 Number of ARIN addresses announced to Internet: 1094318080 Equivalent to 65 /8s, 57 /16s and 248 /24s Percentage of available ARIN address space announced: 57.9 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, 62464-63487, 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, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 125003 Total RIPE prefixes after maximum aggregation: 63089 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 129834 Unique aggregates announced from the RIPE address blocks: 82126 RIPE Region origin ASes present in the Internet Routing Table: 17709 RIPE Prefixes per ASN: 7.33 RIPE Region origin ASes announcing only one prefix: 8225 RIPE Region transit ASes present in the Internet Routing Table: 2887 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2738 Number of RIPE addresses announced to Internet: 658843524 Equivalent to 39 /8s, 69 /16s and 39 /24s Percentage of available RIPE address space announced: 95.8 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 59392-61439, 61952-62463, 196608-202239 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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 59604 Total LACNIC prefixes after maximum aggregation: 10545 LACNIC Deaggregation factor: 5.65 Prefixes being announced from the LACNIC address blocks: 67711 Unique aggregates announced from the LACNIC address blocks: 30158 LACNIC Region origin ASes present in the Internet Routing Table: 2256 LACNIC Prefixes per ASN: 30.01 LACNIC Region origin ASes announcing only one prefix: 608 LACNIC Region transit ASes present in the Internet Routing Table: 456 Average LACNIC Region AS path length visible: 4.6 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1306 Number of LACNIC addresses announced to Internet: 169664768 Equivalent to 10 /8s, 28 /16s and 225 /24s Percentage of available LACNIC address space announced: 101.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 11032 Total AfriNIC prefixes after maximum aggregation: 2742 AfriNIC Deaggregation factor: 4.02 Prefixes being announced from the AfriNIC address blocks: 11841 Unique aggregates announced from the AfriNIC address blocks: 4626 AfriNIC Region origin ASes present in the Internet Routing Table: 735 AfriNIC Prefixes per ASN: 16.11 AfriNIC Region origin ASes announcing only one prefix: 217 AfriNIC Region transit ASes present in the Internet Routing Table: 157 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 53 Number of AfriNIC addresses announced to Internet: 58322688 Equivalent to 3 /8s, 121 /16s and 239 /24s Percentage of available AfriNIC address space announced: 57.9 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2934 11591 919 Korea Telecom 17974 2808 900 74 PT Telekomunikasi Indonesia 7545 2333 336 120 TPG Telecom Limited 4755 1893 413 192 TATA Communications formerly 9829 1654 1307 32 National Internet Backbone 9583 1316 104 538 Sify Limited 9498 1301 317 92 BHARTI Airtel Ltd. 7552 1238 1098 14 Viettel Corporation 9808 1236 6639 15 Guangdong Mobile Communicatio 4808 1202 2158 369 CNCGROUP IP network China169 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 22773 2928 2940 142 Cox Communications Inc. 6389 2896 3688 51 BellSouth.net Inc. 18566 2045 379 178 MegaPath Corporation 7029 1916 1957 305 Windstream Communications Inc 20115 1772 1756 524 Charter Communications 4323 1623 1055 407 tw telecom holdings, inc. 30036 1555 326 535 Mediacom Communications Corp 6983 1444 817 314 ITC^Deltacom 701 1437 11242 721 MCI Communications Services, 22561 1308 408 237 CenturyTel Internet Holdings, 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 34984 1743 298 281 TELLCOM ILETISIM HIZMETLERI A 20940 1474 570 1084 Akamai International B.V. 8402 1319 544 15 OJSC "Vimpelcom" 31148 1042 45 20 Freenet Ltd. 13188 1041 97 49 TOV "Bank-Inform" 8551 980 371 41 Bezeq International-Ltd 6849 807 356 27 JSC "Ukrtelecom" 12479 784 798 58 France Telecom Espana SA 6830 773 2335 428 Liberty Global Operations B.V 9198 648 346 28 JSC Kazakhtelecom 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 28573 3357 2315 117 NET Servi?os de Comunica??o S 10620 2961 480 215 Telmex Colombia S.A. 18881 2084 1036 22 Global Village Telecom 7303 1768 1180 234 Telecom Argentina S.A. 6147 1739 374 30 Telefonica del Peru S.A.A. 8151 1467 2999 433 Uninet S.A. de C.V. 6503 1095 434 61 Axtel, S.A.B. de C.V. 7738 977 1882 41 Telemar Norte Leste S.A. 27947 902 130 51 Telconet S.A 26615 897 2325 35 Tim Celular 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 24863 941 280 26 Link Egypt (Link.NET) 6713 669 744 37 Office National des Postes et 8452 599 958 13 TE-AS 36992 315 816 27 ETISALAT MISR 24835 307 144 9 Vodafone Data 3741 249 920 212 Internet Solutions 29571 237 22 17 Cote d'Ivoire Telecom 37054 236 19 6 Data Telecom Service 15706 186 17 6 Sudatel (Sudan Telecom Co. Lt 12258 174 26 71 MWEB CONNECT (PROPRIETARY) LI 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 28573 3357 2315 117 NET Servi?os de Comunica??o S 10620 2961 480 215 Telmex Colombia S.A. 4766 2934 11591 919 Korea Telecom 22773 2928 2940 142 Cox Communications Inc. 6389 2896 3688 51 BellSouth.net Inc. 17974 2808 900 74 PT Telekomunikasi Indonesia 7545 2333 336 120 TPG Telecom Limited 18881 2084 1036 22 Global Village Telecom 18566 2045 379 178 MegaPath Corporation 7029 1916 1957 305 Windstream Communications Inc Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2896 2845 BellSouth.net Inc. 22773 2928 2786 Cox Communications Inc. 10620 2961 2746 Telmex Colombia S.A. 17974 2808 2734 PT Telekomunikasi Indonesia 7545 2333 2213 TPG Telecom Limited 18881 2084 2062 Global Village Telecom 4766 2934 2015 Korea Telecom 18566 2045 1867 MegaPath Corporation 6147 1739 1709 Telefonica del Peru S.A.A. 4755 1893 1701 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 55020 UNALLOCATED 8.30.123.0/24 3356 Level 3 Communicatio 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 15347 UNALLOCATED 8.224.147.0/24 12064 Cox Communications I 33628 UNALLOCATED 12.0.239.0/24 1239 Sprint Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.65.0.0/24 4826 Vocus Connect International B Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 24.231.96.0/24 21548 MTO Telecom Inc. 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.14.0/24 37004 >>UNKNOWN<< 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:16 /9:13 /10:30 /11:91 /12:261 /13:500 /14:982 /15:1705 /16:13031 /17:7045 /18:11746 /19:24647 /20:35359 /21:37764 /22:54294 /23:47822 /24:271327 /25:1091 /26:1039 /27:665 /28:15 /29:19 /30:10 /31:1 /32:14 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2164 2928 Cox Communications Inc. 18566 2000 2045 MegaPath Corporation 6389 1674 2896 BellSouth.net Inc. 30036 1404 1555 Mediacom Communications Corp 6147 1314 1739 Telefonica del Peru S.A.A. 7029 1158 1916 Windstream Communications Inc 6983 1150 1444 ITC^Deltacom 11492 1124 1173 CABLE ONE, INC. 34984 1064 1743 TELLCOM ILETISIM HIZMETLERI A 10620 1036 2961 Telmex Colombia S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1328 2:663 3:3 4:16 5:1081 6:21 8:732 12:1862 13:4 14:1110 15:15 16:2 17:39 18:21 20:50 23:904 24:1799 27:1777 31:1408 32:41 33:2 34:5 36:139 37:1846 38:967 39:12 40:220 41:2535 42:270 43:228 44:16 45:63 46:2144 47:24 49:733 50:820 52:12 54:49 55:5 56:4 57:32 58:1217 59:660 60:425 61:1688 62:1235 63:1836 64:4362 65:2292 66:4200 67:2030 68:1042 69:3252 70:864 71:478 72:2046 74:2575 75:370 76:420 77:1612 78:798 79:715 80:1324 81:1201 82:764 83:780 84:766 85:1324 86:441 87:1149 88:461 89:1793 90:138 91:5692 92:766 93:1782 94:2022 95:1591 96:421 97:344 98:1159 99:49 100:67 101:706 103:5469 104:207 105:37 106:179 107:602 108:566 109:1975 110:1027 111:1354 112:718 113:852 114:780 115:1186 116:1104 117:988 118:1546 119:1425 120:419 121:970 122:2167 123:1606 124:1427 125:1571 128:600 129:348 130:366 131:718 132:423 133:165 134:319 135:75 136:303 137:288 138:384 139:203 140:228 141:401 142:575 143:426 144:505 145:112 146:607 147:489 148:975 149:402 150:452 151:595 152:458 153:241 154:338 155:526 156:358 157:328 158:280 159:939 160:328 161:587 162:1729 163:340 164:702 165:645 166:361 167:673 168:1124 169:122 170:1394 171:183 172:63 173:1603 174:700 175:624 176:1475 177:3530 178:2090 179:774 180:1775 181:1596 182:1629 183:555 184:708 185:2008 186:2927 187:1669 188:2168 189:1473 190:7959 191:757 192:7503 193:5501 194:4049 195:3572 196:1442 197:682 198:5146 199:5469 200:6496 201:2868 202:9178 203:9011 204:4561 205:2643 206:2949 207:2910 208:3931 209:3733 210:3303 211:1836 212:2338 213:2126 214:865 215:88 216:5565 217:1688 218:617 219:406 220:1355 221:688 222:479 223:597 End of report From pauldotwall at gmail.com Fri Aug 29 21:39:01 2014 From: pauldotwall at gmail.com (Paul WALL) Date: Fri, 29 Aug 2014 14:39:01 -0700 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: References: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> <20140829085511.GA4082@pob.ytti.fi> <5400491C.8040008@linfre.de> <20140829100815.GO44548@Vurt.local> <20140829102559.GP44548@Vurt.local> Message-ID: On Friday, August 29, 2014, Randy Bush wrote: > > i am ENOTIME. when you have a simple spec i can follow, i would really > look forward to it. > Thanks for summing up in a few words how most of us outside your ivory tower feel about RPKI. Now if you'll excuse me, I'm a grown-up with real work to do. Drive slow, Paul From matthew at matthew.at Fri Aug 29 21:46:05 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 29 Aug 2014 14:46:05 -0700 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: <20140829032838.B32F41DC11B5@rock.dv.isc.org> References: <20140829032838.B32F41DC11B5@rock.dv.isc.org> Message-ID: <4D8C7C67-73B3-43BB-8443-4906116DA9EF@matthew.at> I look forward to the ARIN fee schedule for legacy IPv4 holder RPKI registrations. Matthew Kaufman (Sent from my iPhone) > On Aug 28, 2014, at 8:28 PM, Mark Andrews wrote: > > > See "whois -r AS43239". > > The long term solution is to deploy RPKI and only use > transits which use RPKI. No RPKI support => no business. > Additionally make RPKI a peering requirement. > > Mark > > In message > , Tarun Dua writes: >> AS Number 43239 >> AS Name SPETSENERGO-AS SpetsEnergo Ltd. >> >> Has started hijacking our IPv4 prefix, while this prefix was NOT in >> production, it worries us that it was this easy for someone to hijack >> it. >> >> http://bgp.he.net/AS43239#_prefixes >> >> 103.20.212.0/22 <- This belongs to us. >> >> 103.238.232.0/22 KNS Techno Integrators Pvt. Ltd. >> 193.43.33.0/24 hydrocontrol S.C.R.L. >> 193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline >> >> Where do we complain to get this fixed. >> >> -Tarun >> AS132420 > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cidr-report at potaroo.net Fri Aug 29 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 Aug 2014 22:00:01 GMT Subject: The Cidr Report Message-ID: <201408292200.s7TM01eq016499@wattle.apnic.net> This report has been generated at Fri Aug 29 21:14:09 2014 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/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 22-08-14 513246 282132 23-08-14 513187 282133 24-08-14 513509 282207 25-08-14 513418 282933 26-08-14 514288 283078 27-08-14 513971 283578 28-08-14 515378 283914 29-08-14 515254 284068 AS Summary 48099 Number of ASes in routing system 19479 Number of ASes announcing only one prefix 3359 Largest number of prefixes announced by an AS AS28573: NET Servi?os de Comunica??o S.A.,BR 120577536 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN 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'). --- 29Aug14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 514693 284199 230494 44.8% All ASes AS28573 3359 130 3229 96.1% NET Servi?os de Comunica??o S.A.,BR AS6389 2895 69 2826 97.6% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS22773 2925 175 2750 94.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS17974 2809 80 2729 97.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS18881 2084 53 2031 97.5% Global Village Telecom,BR AS4766 2934 1195 1739 59.3% KIXS-AS-KR Korea Telecom,KR AS6147 1740 163 1577 90.6% Telefonica del Peru S.A.A.,PE AS7303 1773 284 1489 84.0% Telecom Argentina S.A.,AR AS8402 1306 26 1280 98.0% CORBINA-AS OJSC "Vimpelcom",RU AS4755 1891 632 1259 66.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4323 1635 413 1222 74.7% TWTC - tw telecom holdings, inc.,US AS7552 1264 61 1203 95.2% VIETEL-AS-AP Viettel Corporation,VN AS9808 1236 38 1198 96.9% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS9498 1303 111 1192 91.5% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2044 862 1182 57.8% MEGAPATH5-US - MegaPath Corporation,US AS20115 1774 596 1178 66.4% CHARTER-NET-HKY-NC - Charter Communications,US AS7545 2351 1175 1176 50.0% TPG-INTERNET-AP TPG Telecom Limited,AU AS10620 2961 1839 1122 37.9% Telmex Colombia S.A.,CO AS6983 1443 387 1056 73.2% ITCDELTA - Earthlink, Inc.,US AS7738 977 41 936 95.8% Telemar Norte Leste S.A.,BR AS22561 1308 412 896 68.5% AS22561 - CenturyTel Internet Holdings, Inc.,US AS2516 1055 203 852 80.8% KDDI KDDI CORPORATION,JP AS38285 956 114 842 88.1% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS24560 1171 347 824 70.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS4788 1048 226 822 78.4% TMNET-AS-AP TM Net, Internet Service Provider,MY AS7029 2005 1190 815 40.6% WINDSTREAM - Windstream Communications Inc,US AS8151 1475 696 779 52.8% Uninet S.A. de C.V.,MX AS26615 897 126 771 86.0% Tim Celular S.A.,BR AS18101 953 192 761 79.9% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS4780 1029 273 756 73.5% SEEDNET Digital United Inc.,TW Total 52601 12109 40492 77.0% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 24.231.96.0/24 AS21548 MTO - MTO Telecom Inc.,CA 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.180.0/23 AS37265 -Reserved AS-,ZZ 41.189.96.0/20 AS37000 -Reserved AS-,ZZ 41.189.127.0/24 AS37000 -Reserved AS-,ZZ 41.189.128.0/24 AS37000 -Reserved AS-,ZZ 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.223.208.0/22 AS37000 -Reserved AS-,ZZ 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.193.160.0/19 AS24801 -Reserved AS-,ZZ 62.193.160.0/20 AS24801 -Reserved AS-,ZZ 62.193.176.0/20 AS24801 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.111.160.0/20 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.160.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.161.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.162.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.167.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.169.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.170.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.171.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.172.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.173.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.174.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 64.111.175.0/24 AS40551 ATVI-NETWORK-ASN - Activision Publishing, Inc.,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 -Reserved AS-,ZZ 74.120.214.0/23 AS32326 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.78.133.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/23 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.134.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.78.135.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 89.31.24.0/23 AS41455 -Reserved AS-,ZZ 89.31.26.0/23 AS41455 -Reserved AS-,ZZ 89.31.28.0/22 AS41455 -Reserved AS-,ZZ 89.207.8.0/21 AS3292 TDC TDC A/S,DK 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.228.160.0/24 AS35557 GRITSENKO-AS PE GRITSENKO NADEJDA NIKOLAEVNA,UA 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 100.65.0.0/24 AS4826 VOCUS-BACKBONE-AS Vocus Connect International Backbone,AU 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.6.108.0/22 AS55526 NOIDASOFTWARETECHNOLOGYPARK-IN NOIDA Software Technology Park Ltd,IN 103.6.228.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.9.108.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.18.76.0/22 AS18097 DCN D.C.N. Corporation,JP 103.18.92.0/22 AS13269 103.18.92.0/24 AS13269 103.18.94.0/24 AS13269 103.18.248.0/22 AS18097 DCN D.C.N. Corporation,JP 103.19.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.20.100.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.20.101.0/24 AS45334 AIRCEL-AS-AP Dishnet Wireless Limited,IN 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.25.120.0/22 AS13280 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.37.229.0/24 AS13336 IDNIC-UNPAR-AS-ID Biro Teknologi Informasi,ID 103.248.88.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.248.220.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.249.8.0/22 AS4725 ODN SOFTBANK TELECOM Corp.,JP 103.250.0.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.108.16.0/22 AS38904 124.158.28.0/22 AS45857 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 160.224.0.0/15 AS11259 ANGOLATELECOM,AO 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 182.237.24.0/24 AS55503 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.28.180.0/22 AS18097 DCN D.C.N. Corporation,JP 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.30.152.0/21 AS27216 AIR-ADVANTAGE-ASN - Air Advantage LLC,US 192.34.152.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 192.75.23.0/24 AS2579 AS2579 - Alcatel-Lucent,US 192.75.239.0/24 AS23498 CDSI - COGECODATA,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.53.5.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.39.78.0/23 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.50.8.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT High Tech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.126.251.0/24 AS50818 -Reserved AS-,ZZ 194.146.35.0/24 AS25186 TRANSIT-VPN-AS Orange S.A.,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.245.98.0/23 AS48918 GLOBALWAYS GLOBALWAYS AG,DE 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.6.0.0/24 AS32768 routability-tests,MU 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 196.216.254.0/24 AS32768 routability-tests,MU 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 ADC-ASN - Freeport McMoRan Copper & Gold Inc.,US 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 203.160.48.0/21 AS38008 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.10.94.0/23 AS30097 NUWAVE - NuWave,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.166.231.0/24 AS7029 WINDSTREAM - Windstream Communications Inc,US 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.223.224.0/24 AS21548 MTO - MTO Telecom Inc.,CA 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.66.64.0/24 AS16936 -Reserved AS-,ZZ 208.66.65.0/24 AS16936 -Reserved AS-,ZZ 208.66.66.0/24 AS16936 -Reserved AS-,ZZ 208.66.67.0/24 AS16936 -Reserved AS-,ZZ 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.94.216.0/23 AS13629 -Reserved AS-,ZZ 208.94.219.0/24 AS13629 -Reserved AS-,ZZ 208.94.221.0/24 AS13629 -Reserved AS-,ZZ 208.94.223.0/24 AS13629 -Reserved AS-,ZZ 209.135.171.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.135.175.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.209.224.0/19 AS19513 -Reserved AS-,ZZ 209.209.248.0/23 AS19513 -Reserved AS-,ZZ 209.209.250.0/23 AS19513 -Reserved AS-,ZZ 209.209.251.0/24 AS19513 -Reserved AS-,ZZ 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 213.255.128.0/20 AS24863 LINKdotNET-AS,EG 213.255.144.0/20 AS24863 LINKdotNET-AS,EG 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.14.64.0/20 AS14728 MW-INDIANA - Mercury Wireless, LLC,US 216.146.0.0/19 AS11915 US-TELEPACIFIC - TelePacific Communications,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 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 cidr-report at potaroo.net Fri Aug 29 22:00:02 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 Aug 2014 22:00:02 GMT Subject: BGP Update Report Message-ID: <201408292200.s7TM02bp016524@wattle.apnic.net> BGP Update Report Interval: 21-Aug-14 -to- 28-Aug-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS38197 213766 4.0% 239.4 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 2 - AS23752 197087 3.6% 1877.0 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - AS10098 181987 3.4% 9578.3 -- HENDERSON-HK Henderson Data Centre Limited,HK 4 - AS16024 145466 2.7% 145466.0 -- GELSEN-NET GELSEN-NET Kommunikationsgesellschaft mbH,DE 5 - AS9829 124624 2.3% 104.5 -- BSNL-NIB National Internet Backbone,IN 6 - AS8402 101215 1.9% 383.4 -- CORBINA-AS OJSC "Vimpelcom",RU 7 - AS58404 76755 1.4% 9594.4 -- QWORDS-AS-ID PT Qwords Company International,ID 8 - AS28573 71069 1.3% 38.4 -- NET Servi?os de Comunica??o S.A.,BR 9 - AS14434 69654 1.3% 916.5 -- VIPNAS1 - VI POWERNET, LLC,VI 10 - AS4775 53629 1.0% 1308.0 -- GLOBE-TELECOM-AS Globe Telecoms,PH 11 - AS17974 51905 1.0% 88.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 12 - AS1659 48338 0.9% 1007.0 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW 13 - AS17908 38070 0.7% 96.4 -- TCISL Tata Communications,IN 14 - AS4 37453 0.7% 874.0 -- ISI-AS - University of Southern California,US 15 - AS2706 35734 0.7% 850.8 -- PI-HK Pacnet Internet (Hong Kong) Limited,JP 16 - AS41691 30896 0.6% 1404.4 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 17 - AS3816 23847 0.4% 47.3 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 18 - AS27047 23618 0.4% 482.0 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center,US 19 - AS24814 22295 0.4% 3185.0 -- SCS-AS Syrian Computer Society, scs,SY 20 - AS9583 22162 0.4% 18.2 -- SIFY-AS-IN Sify Limited,IN TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS16024 145466 2.7% 145466.0 -- GELSEN-NET GELSEN-NET Kommunikationsgesellschaft mbH,DE 2 - AS32336 15600 0.3% 15600.0 -- IPASS-2 - iPass Incorporated,US 3 - AS58404 76755 1.4% 9594.4 -- QWORDS-AS-ID PT Qwords Company International,ID 4 - AS10098 181987 3.4% 9578.3 -- HENDERSON-HK Henderson Data Centre Limited,HK 5 - AS60140 7067 0.1% 7067.0 -- BUZINESSWARE Buzinessware FZCO,AE 6 - AS25003 19294 0.4% 4823.5 -- INTERNET_BINAT Internet Binat Ltd,IL 7 - AS4 4663 0.1% 1486.0 -- ISI-AS - University of Southern California,US 8 - AS37620 4604 0.1% 4604.0 -- VIETTEL-CM-AS,CM 9 - AS61765 4457 0.1% 4457.0 -- VIVA TELECOMUNICA??ES LTDA- ME,BR 10 - AS6459 12716 0.2% 4238.7 -- TRANSBEAM - I-2000, Inc.,US 11 - AS38267 4182 0.1% 4182.0 -- FIBRENET-BD FibreNet Communications Ltd.,BD 12 - AS12559 7996 0.1% 3998.0 -- ISIDE-AS I.S.I.D.E. S.p.A.,IT 13 - AS30969 11652 0.2% 3884.0 -- ZOL-AS Zimbabwe OnLine (Private) Ltd.,GB 14 - AS62174 3869 0.1% 3869.0 -- INTERPAN-AS INTERPAN LTD.,BG 15 - AS53168 10815 0.2% 3605.0 -- CIA ESTADUAL DE GERA??O E TRANSMISS?O DE ENERGIA E,BR 16 - AS47680 3438 0.1% 3438.0 -- NHCS EOBO Limited,IE 17 - AS24814 22295 0.4% 3185.0 -- SCS-AS Syrian Computer Society, scs,SY 18 - AS4 18081 0.3% 834.0 -- ISI-AS - University of Southern California,US 19 - AS33643 2569 0.1% 2569.0 -- JELLYBELLY - Jelly Belly Candy Company,US 20 - AS26661 10261 0.2% 2565.2 -- JCPS-ASN - Jeffco Public Schools,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.123.88.0/24 181911 3.2% AS10098 -- HENDERSON-HK Henderson Data Centre Limited,HK 2 - 185.47.232.0/22 145466 2.6% AS16024 -- GELSEN-NET GELSEN-NET Kommunikationsgesellschaft mbH,DE 3 - 202.70.88.0/21 97614 1.7% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 202.70.64.0/21 97517 1.7% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 5 - 46.53.64.0/19 39834 0.7% AS24814 -- SCS-AS Syrian Computer Society, scs,SY AS29386 -- EXT-PDN-STE-AS Syrian Telecommunications Establishment,SY 6 - 89.221.206.0/24 30807 0.5% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 7 - 120.28.62.0/24 26851 0.5% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 8 - 222.127.0.0/24 26666 0.5% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 9 - 192.115.44.0/22 19288 0.3% AS25003 -- INTERNET_BINAT Internet Binat Ltd,IL 10 - 188.75.52.0/22 15643 0.3% AS8888 -- RUSERVICE-LLC-AS LLC RU-service,RU 11 - 216.231.194.0/24 15600 0.3% AS32336 -- IPASS-2 - iPass Incorporated,US 12 - 202.149.72.0/24 15370 0.3% AS58404 -- QWORDS-AS-ID PT Qwords Company International,ID 13 - 103.28.14.0/24 15367 0.3% AS58404 -- QWORDS-AS-ID PT Qwords Company International,ID 14 - 103.28.13.0/24 15361 0.3% AS58404 -- QWORDS-AS-ID PT Qwords Company International,ID 15 - 43.252.137.0/24 15313 0.3% AS58404 -- QWORDS-AS-ID PT Qwords Company International,ID 16 - 43.252.138.0/24 15306 0.3% AS58404 -- QWORDS-AS-ID PT Qwords Company International,ID 17 - 205.247.12.0/24 12710 0.2% AS6459 -- TRANSBEAM - I-2000, Inc.,US 18 - 112.215.16.0/24 12032 0.2% AS17885 -- JKTXLNET-AS-AP PT Excelcomindo Pratama,ID AS24203 -- NAPXLNET-AS-ID PT Excelcomindo Pratama (Network Access Provider),ID 19 - 162.247.210.0/24 10833 0.2% AS6 -- BULL-HN - Bull HN Information Systems Inc.,US 20 - 192.58.232.0/24 8520 0.1% AS6629 -- NOAA-AS - NOAA,US 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 randy at psg.com Fri Aug 29 22:01:25 2014 From: randy at psg.com (Randy Bush) Date: Sat, 30 Aug 2014 07:01:25 +0900 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: References: <23114FE7-CD9E-4881-8EE1-CE1C313A179C@cisco.com> Message-ID: apologies. that was meant to be private. sigh. randy From rs at seastrom.com Fri Aug 29 22:39:07 2014 From: rs at seastrom.com (Rob Seastrom) Date: Fri, 29 Aug 2014 18:39:07 -0400 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: <4D8C7C67-73B3-43BB-8443-4906116DA9EF@matthew.at> (Matthew Kaufman's message of "Fri, 29 Aug 2014 14:46:05 -0700") References: <20140829032838.B32F41DC11B5@rock.dv.isc.org> <4D8C7C67-73B3-43BB-8443-4906116DA9EF@matthew.at> Message-ID: <8661haly44.fsf@valhalla.seastrom.com> Matthew Kaufman writes: > I look forward to the ARIN fee schedule for legacy IPv4 holder RPKI > registrations. I'd assume that it would be included in your annual LRSA maintenance fees. -r From jared at puck.Nether.net Fri Aug 29 23:17:56 2014 From: jared at puck.Nether.net (Jared Mauch) Date: Fri, 29 Aug 2014 19:17:56 -0400 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: <8661haly44.fsf@valhalla.seastrom.com> References: <20140829032838.B32F41DC11B5@rock.dv.isc.org> <4D8C7C67-73B3-43BB-8443-4906116DA9EF@matthew.at> <8661haly44.fsf@valhalla.seastrom.com> Message-ID: <20140829231756.GA21161@puck.nether.net> On Fri, Aug 29, 2014 at 06:39:07PM -0400, Robert E. Seastrom wrote: > > Matthew Kaufman writes: > > > I look forward to the ARIN fee schedule for legacy IPv4 holder RPKI > > registrations. > > I'd assume that it would be included in your annual LRSA maintenance > fees. Make sure you have counsel review the RPA if you are looking at RPKI vs reading it yourself. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From sixsigma44 at hotmail.com Sat Aug 30 02:17:03 2014 From: sixsigma44 at hotmail.com (Ray) Date: Fri, 29 Aug 2014 22:17:03 -0400 Subject: Time Warner outage? In-Reply-To: <53FF8051.5060300@neovera.com> References: <23144097.10213.1409245073995.JavaMail.root@benjamin.baylink.com>, , <53FF8051.5060300@neovera.com> Message-ID: What we noticed on home RoadRunner and on business TWC fiber about 6:15 AM EDT on the 27th: We could access systems from one to another by IP address but not DNS. We could ping other systems by IP. Home DHCP was up but TWC DNS was down at home and at work on the business fiber. Couldn't even reach TWC DNS servers by IP address. I'm not sure why two different classes of systems, business and residential, thirty miles apart would both be down on DNS but up on routing since the DNS servers are on different subnets. (We use TWC business DNS as Forwarders.) It was acting like a DNS failure more than a routing failure for us. I vaguely remembered something about Cox DNS having an outage a few days earlier that someone in the Middle East took credit for but I can't find the article now. I was wondering if TWC was putting in a mitigation and got it wrong, or TWC did not put in a mitigation and the Middle Easters knocked on their door. My impression is that it was acting like all DNS traffic in and out of TWC was getting blocked but it cleared up too soon to perform further testing. Ray > Date: Thu, 28 Aug 2014 15:17:37 -0400 > From: eric.stoltz at neovera.com > To: nanog at nanog.org > Subject: Re: Time Warner outage? > > Looks like TW is having further issues this afternoon. > > Eric Stoltz > Neovera > > > On 08/28/2014 01:37 PM, Chris Garrett wrote: > > Based on the link that Wes shared, sounds like someone made a BGP boo boo. > > > > Not that I routed damn near the whole internet down a customers DS3 or anything once, but I can see how it could happen and then propagate out of control before it was caught. > > > > On Aug 28, 2014, at 11:57 AM, Jay Ashworth wrote: > > > >> ----- Original Message ----- > >>> From: "Steve Naslund" > >>> I don?t buy that excuse either. If Level 3 is doing fiber maintenance > >>> on any route and takes down your entire network, then you have a > >>> pretty poor backbone design. It is not Level 3s fault if you design > >>> your network such that a single route loss causes a huge outage. > >> Does the T-Bone run over L3? I thought it was either owned or dark-leased > >> fiber and their own routers... > >> > >> Cheers, > >> -- jra > >> -- > >> Jay R. Ashworth Baylink jra at baylink.com > >> Designer The Things I Think RFC 2100 > >> Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > >> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 > From dmadory at renesys.com Sun Aug 31 18:04:13 2014 From: dmadory at renesys.com (Doug Madory) Date: Sun, 31 Aug 2014 14:04:13 -0400 Subject: Prefix hijacking, how to prevent and fix currently Message-ID: FWIW, this is from an IP squatting operation I came across in recent weeks. I encounter these things regularly in the course of working with BGP data - probably others do too. Usually I look up the ASN or prefix and often it has already been added to someone's spam source list. When I see that, I assume the "system is working" and move on. In this case, starting late Jun, we have seen IP address ranges from around the world (most ranges are unused, sometimes hijacked space) announced by one of two (formerly unused) ASNs and routed through another formerly unused ASN, 57756, then on to Anders (AS39792) and out to the Internet in the following form: ... 39792 57756 {3.721, 43239} prefix The prefixes are only routed for an hour or two before it moves on to the next range of IP address space. Not sure if this is for spam or something else. Either way, it is probably associated with something bad. Earlier this month I reached out to a contact at Anders in Russia and gave him some details about what was happening. I didn't get a response, but within a couple of days the routing (mostly) shifted from Anders to through Petersburg Internet Network (AS44050). I have no idea if this was due to my email. The day it moved to PIN I sent similar emails to addresses I could find at PIN, but haven't seen any response. Now the these routes take one of two forms: ... 39792 57756 {3.721, 43239} prefix Or ... 44050 57756 {3.721, 43239} prefix This is mostly routed through Cogent (AS174), but Anders (AS39792) also has a lot of peers. I would advise that people treat any route coming through AS57756 is probably bad. AS57756 doesn't originate anything and hasn't since 28-Jun when it very briefly hijacked some NZ space. Also, Pierre-Antoine Vervier from Symantec gave a good talk at NANOG in Feb about IP squatting for spam generation. Pierre and I have since compared notes on this topic. -Doug Madory ----- Original Message ----- > From: "Tarun Dua" > To: nanog at nanog.org > Sent: Thursday, August 28, 2014 12:55:25 PM > Subject: Prefix hijacking, how to prevent and fix currently > > AS Number 43239 > AS Name SPETSENERGO-AS SpetsEnergo Ltd. > > Has started hijacking our IPv4 prefix, while this prefix was NOT in > production, it worries us that it was this easy for someone to hijack > it. > > http://bgp.he.net/AS43239#_prefixes > > 103.20.212.0/22 <- This belongs to us. > > 103.238.232.0/22 KNS Techno Integrators Pvt. Ltd. > 193.43.33.0/24 hydrocontrol S.C.R.L. > 193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline > > Where do we complain to get this fixed. > > -Tarun > AS132420 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From saku at ytti.fi Sun Aug 31 18:36:08 2014 From: saku at ytti.fi (Saku Ytti) Date: Sun, 31 Aug 2014 21:36:08 +0300 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: References: Message-ID: <20140831183608.GA23914@pob.ytti.fi> On (2014-08-31 14:04 -0400), Doug Madory wrote: Hi, > FWIW, this is from an IP squatting operation I came across in recent weeks. I encounter these things regularly in the course of working with BGP data - probably others do too. Usually I look up the ASN or prefix and often it has already been added to someone's spam source list. When I see that, I assume the "system is working" and move on. Some seem to avoid BGP analysis by exposing their attack only to their target. We recently saw MSFT getting our customer's more specific announcement from 60937 originated ostensibly by 35886. No on else (~200 vantage points) was receiving this more specific. Companies who are likely target for this, like MSFT and GOOG, might want to monitor DFZ and see if they are receiving prefixes no one else is receiving. -- ++ytti From matthew at matthew.at Sun Aug 31 18:40:54 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 31 Aug 2014 11:40:54 -0700 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: <8661haly44.fsf@valhalla.seastrom.com> References: <20140829032838.B32F41DC11B5@rock.dv.isc.org> <4D8C7C67-73B3-43BB-8443-4906116DA9EF@matthew.at> <8661haly44.fsf@valhalla.seastrom.com> Message-ID: You're funny. What percentage of legacy holders have or will sign the LRSA do you suppose? Matthew Kaufman (Sent from my iPhone) > On Aug 29, 2014, at 3:39 PM, Rob Seastrom wrote: > > > Matthew Kaufman writes: > >> I look forward to the ARIN fee schedule for legacy IPv4 holder RPKI >> registrations. > > I'd assume that it would be included in your annual LRSA maintenance > fees. > > -r > From dmadory at renesys.com Sun Aug 31 19:47:40 2014 From: dmadory at renesys.com (Doug Madory) Date: Sun, 31 Aug 2014 15:47:40 -0400 Subject: Prefix hijacking, how to prevent and fix currently Message-ID: <61053764-5486-4E4A-B56A-644E005405F6@renesys.com> Ah yes BusinessTorg (AS60937). I have also seen this one doing what you are describing. Not to MSFT or GOOG, but another major technology company that we peer with. In fact, it is going on right now but only visible if you receive routes directly from them. A while ago, I sent them a note describing what was happening and suggested they might want to stop accepting routes from that AS, but they still do. > Some seem to avoid BGP analysis by exposing their attack only to their target. > We recently saw MSFT getting our customer's more specific announcement from > 60937 originated ostensibly by 35886. No on else (~200 vantage points) was > receiving this more specific. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nick at foobar.org Sun Aug 31 20:14:03 2014 From: nick at foobar.org (Nick Hilliard) Date: Sun, 31 Aug 2014 21:14:03 +0100 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: <8661haly44.fsf@valhalla.seastrom.com> References: <20140829032838.B32F41DC11B5@rock.dv.isc.org> <4D8C7C67-73B3-43BB-8443-4906116DA9EF@matthew.at> <8661haly44.fsf@valhalla.seastrom.com> Message-ID: <5403820B.4080703@foobar.org> On 29/08/2014 23:39, Rob Seastrom wrote: > I'd assume that it would be included in your annual LRSA maintenance > fees. it will be interesting to see if we get proposals in the future to move legacy space between RIRs. Nick From mpetach at netflight.com Sun Aug 31 22:19:34 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 31 Aug 2014 15:19:34 -0700 Subject: Prefix hijacking, how to prevent and fix currently In-Reply-To: <61053764-5486-4E4A-B56A-644E005405F6@renesys.com> References: <61053764-5486-4E4A-B56A-644E005405F6@renesys.com> Message-ID: On Sun, Aug 31, 2014 at 12:47 PM, Doug Madory wrote: > Ah yes BusinessTorg (AS60937). I have also seen this one doing what you > are describing. Not to MSFT or GOOG, but another major technology company > that we peer with. In fact, it is going on right now but only visible if > you receive routes directly from them. A while ago, I sent them a note > describing what was happening and suggested they might want to stop > accepting routes from that AS, but they still do. > Be aware that even if you don't think you're peering with them directly, you may be picking up routes via the public route servers at exchange points, so check to see if you need to apply filters on your route server peerings as well. Matt