From mfidelman at meetinghouse.net Sun Mar 1 00:09:42 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 28 Feb 2015 19:09:42 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: Message-ID: <54F258C6.3020608@meetinghouse.net> I'm pretty sure you're wrong about that. Back when we were building the ARPANET, and then Telenet, there were several FCC decisions that made it very clear that leased lines were regulated under Title II, "value added networks" built from those networks were not regulated. I'm pretty sure this was part of the "computer inquiries," the first of which dates back to the 1960s, but I forget which one. As soon as AT&T realized that there was real money to be made, they tried very hard to get the VANs regulate and tariffed (actually, they tried to get them shut down) and abortively tried launching X.25 services of their own. Miles Fidelman Keith Medcalf wrote: > You are forgetting that the Internet and ISPs where originally common carriers and the FCC at the behest of the government decided to de-regulate so that they could raid, arrest, charge, fine and torture ISPs if their customers visited websites the governement did not like, sent email the government did not like, or posted to web forums something that the government did not like. > > Contrast that with things which remained common carriers (wireline telephone) wherein the carrier is not responsible for what the customer does using their telephone. > > --- > Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why. > > >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Owen DeLong >> Sent: Saturday, 28 February, 2015 14:02 >> To: Lamar Owen >> Cc: nanog at nanog.org >> Subject: Re: Verizon Policy Statement on Net Neutrality >> >>>> In the same way, I don't like the BASIS for this authority... and what >> it potentially means in the long term... besides what they state that >> they intend to do with this new authority they've appointed themselves in >> the short term. >>> Had some people not apparently taken advantage of the situation as it >> existed before the proceeding in docket 14-28, it's likely no regulatory >> actions would have been initiated. >> >> There seems to be a lot of forgotten history in this discussion... >> >> The FCC tried a light-weight low-touch form of open internet regulation. >> >> $CABLECOs sued them and got it eliminated. >> >> Then they tried a different light-weight low-touch form of open internet >> regulation. >> >> $TELCOs sued them and got it eliminated. >> >> They were left with two basic choices at that point: >> >> 1. Allow the $TELCO and $CABLECO abuses working against an open >> internet to continue, which, frankly >> is what most of the more cynical among us expected, especially >> when Wheeler (who has traditionally been >> a mouthpiece for the $CABLE_LOBBY) announced his initial fast- >> lane proposal. >> >> 2. Use real authority and real regulations that exist and make >> the internet subject to those regulations, which >> appears to be what actually happened. >> >>> I'm not cheerleading by any means; I would much prefer less regulation >> than more in almost every situation; but the simple fact is that people >> do tend to abuse the lack of regulations long enough for regulatory >> agencies to take notice, and then everyone loses when regulations come. >> >> In this particular case, I think it is primarily >> $INCUMBENT_OLIGOPOLY_PROVIDERs which lose. As near as I can tell from >> what is in the actual regulations, everyone else pretty much wins. Yes, >> there are probably some tradeoffs and I'm sure that the incumbents will >> attempt to find ways to make this as painful as possible for consumers >> while they throw their typical temper tantrums. (Think they're above >> temper tantrums, then look at Verizon's blog in morse code.) >> >>> Reading the R&O once it is released will be very interesting, at least >> in my opinion, since we'll get a glimpse into the rationale and the >> thought processes that went into each paragraph and subparagraph of this >> new section in 47CFR. I'm most interested in the rationale behind the >> pleading requirements, like requiring complainants to serve the >> complaint by hand delivery on the named defendant, requiring the >> complainant to serve two copies on the Market Disputes Resolution >> Division of the EB, etc. This seems to be a pretty high bar to filing a >> complaint; it's not like you can just fill out a form on the FCC website >> to report your ISP for violating 47CFR§8. Heh, part of the rationale >> might be the fact that they got over 2 million filings on this >> docket...... >> >> I suspect that they want to be able to take real complaints seriously and >> not waste resources on a large number of frivolous complaints. Since the >> intent is to primarily deal with the B2B interactions between content and >> service providers where one is abusing the other to the detriment of the >> end-users, I suspect all the intended players have the resources to >> comply with the filing requirements fairly easily, but it prevents every >> Tom, Dick, and Johnny with a web browser from becoming an expensive PITA. >> Sort of a "You must be this tall to ride" process, for lack of a better >> term. However, that's pure speculation on my part, and >> I agree reading the actual R&O will be interesting. >> >> Overall, I think this may well be the first (mostly) functional >> regulatory process to occur in recent memory. >> >> Owen > > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mike at mtcc.com Sun Mar 1 00:14:35 2015 From: mike at mtcc.com (Michael Thomas) Date: Sat, 28 Feb 2015 16:14:35 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <6B8B9E2F-7833-492D-BBA8-F5B75C69D5B3@mnsi.net> References: <12510710.909.1425165605520.JavaMail.mhammett@ThunderFuck> <6B8B9E2F-7833-492D-BBA8-F5B75C69D5B3@mnsi.net> Message-ID: <54F259EB.1090302@mtcc.com> On 02/28/2015 03:35 PM, Clayton Zekelman wrote: > And for historical reasons. The forward path started at TV channel 2. The return path was shoe horned in to the frequencies below that, which limited the amount of available spectrum for return path. > > Originally this didn't matter much because the only thing it was used for was set top box communications and occasionally sending video to the head end for community channel remote feeds. > > To change the split would require replacement of all the active and passive RF equipment in the network. > > Only now with he widespread conversion to digital cable are they able to free up enough spectrum to even consider moving the split at some point in the future. Something else to keep in mind, is that the cable companies wanted to use the upstream for voice using DOCSIS QoS to create a big advantage over anybody else who might want to just do voice over the top. There was lots of talk about business advantage, evil home servers, etc, etc and no care at all about legitimate uses for customer upstream. If they wanted to shape DOCSIS to have better upstream, all they had to say is "JUMP" to cablelabs and the vendors and it would have happened. Mike > > Sent from my iPhone > >> On Feb 28, 2015, at 6:20 PM, Mike Hammett wrote: >> >> As I said earlier, there are only so many channels available. Channels added to upload are taken away from download. People use upload so infrequently it would be gross negligence on the provider's behalf. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> ----- Original Message ----- >> >> From: "Clayton Zekelman" >> To: "Barry Shein" >> Cc: "NANOG" >> Sent: Saturday, February 28, 2015 5:14:18 PM >> Subject: Re: Verizon Policy Statement on Net Neutrality >> >> You do of course realize that the asymmetry in CATV forward path/return path existed LONG before residential Internet access over cable networks exited? >> >> Sent from my iPhone >> >>> On Feb 28, 2015, at 5:38 PM, Barry Shein wrote: >>> >>> >>> Can we stop the disingenuity? >>> >>> Asymmetric service was introduced to discourage home users from >>> deploying "commercial" services. As were bandwidth caps. >>> >>> One can argue all sorts of other "benefits" of this but when this >>> started that was the problem on the table: How do we forcibly >>> distinguish commercial (i.e., more expensive) from non-commercial >>> usage? >>> >>> Answer: Give them a lot less upload than download bandwidth. >>> >>> Originally these asymmetric, typically DSL, links were hundreds of >>> kbits upstream, not a lot more than a dial-up line. >>> >>> That and NAT thereby making it difficult -- not impossible, the savvy >>> were in the noise -- to map domain names to permanent IP addresses. >>> >>> That's all this was about. >>> >>> It's not about "that's all they need", "that's all they want", etc. >>> >>> Now that bandwidth is growing rapidly and asymmetric is often >>> 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire >>> medium-sized ISPs ran on less than 10mbps symmetric not long ago. But >>> it still imposes an upper bound of sorts, along with addressing >>> limitations and bandwidth caps. >>> >>> That's all this is about. >>> >>> The telcos for many decades distinguished "business" voice service >>> from "residential" service, even for just one phone line, though they >>> mostly just winged it and if they declared you were defrauding them by >>> using a residential line for a business they might shut you off and/or >>> back bill you. Residential was quite a bit cheaper, most importantly >>> local "unlimited" (unmetered) talk was only available on residential >>> lines. Business lines were even coded 1MB (one m b) service, one >>> metered business (line). >>> >>> The history is clear and they've just reinvented the model for >>> internet but proactively enforced by technology rather than studying >>> your usage patterns or whatever they used to do, scan for business ads >>> using "residential" numbers, beyond bandwidth usage analysis. >>> >>> And the CATV companies are trying to reinvent CATV pricing for >>> internet, turn Netflix (e.g.) into an analogue of HBO and other >>> premium CATV services. >>> >>> What's so difficult to understand here? >>> >>> -- >>> -Barry Shein >>> >>> The World | bzs at TheWorld.com | http://www.TheWorld.com >>> Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada >>> Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From lyndon at orthanc.ca Sun Mar 1 00:17:33 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 28 Feb 2015 16:17:33 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <21746.17258.270398.162820@world.std.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> Message-ID: > It's not about "that's all they need", "that's all they want", etc. Whenever any vendor spouts "this is what our customers want" you know they are talking pure bullshit. The only customers who know what they "want" are the microscopic percentage who know what's actually possible, and we are dismissed as cranks. Even though they keep hiring us to run their networks. In the spirit of adding real data to the symmetry conversation, let me describe why I would prefer symmetric. Currently I have all-copper DSL running at 3 Mb/s down and about 640 Kb/s up. There are days I wish I had 1.5 Mb each way, as there are times when I need to push large files out (well in excess of 1 GB each). Doing that now is painfully slow, but I can live with the long transfer times because I'm not doing it every day. Where it is painful is how the clogged pipe breaks other things. The big one is my SIP phone service. Because the ACKs on the file upload come back faster than the data can leave, it's almost impossible to avoid queueing delays in my border router, despite it being a real UNIX box vs. a cheap appliance NAT router with buffer bloat. TCP doesn't deal well with the asymmetry, so the only way to address this is to drastically reduce the sendspace window on my uploading box in order to throttle it back to where TCP's flow control works as designed. So do I hack FTP and ssh on my machines to take a command line option to squash the sendspace? Or worse, do I use the existing knobs to turn sendspace down for the entire host? Neither one is pleasant, and I shouldn't have to implement either. Having a DSL link that allocated bandwidth based on real-time need would solve this for me. But since that's not an option, converting the link I have from ADSL to SDSL would solve my problem. I would gladly trade in a portion of my downstream *bandwidth* for a corresponding reduction in my upstream *latency*. And I suspect a lot of those bullshitting ISPs would find this is "what our customers want" if their customers ever learned that it is this asymmetry that underlies many of their perceived performance issues. Mind you, the truly annoying part of this story (for me) is knowing Telus has fibre pedestals not a block away, with enough bandwidth to serve up IPTV to all the condos in the neighbourhood. But I'm in the marina across the street. Since there are only a handful of us here with service of any sort, they aren't about to come out and reroute us to the fibre pedestal. So I get to stay on the very long and corroded copper circuit back to one of the original downtown Vancouver exchanges. As one of the Telus techs said when he came out to help troubleshoot a failing DSL modem: I am amazed it works at all :-) And he's right -- the dB line losses are horrific. --lyndon -------------- 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 mysidia at gmail.com Sun Mar 1 00:33:48 2015 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 28 Feb 2015 18:33:48 -0600 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: References: <54F0E159.2000804@satchell.net> <20150227233223.18612.qmail@ary.lan> Message-ID: On Sat, Feb 28, 2015 at 8:34 AM, John R. Levine wrote: >>> With the "legal content" rule, I expect some bottom feeding bulk >>> mailers to sue claiming that their CAN SPAM compliant spam is legal, [...] > Until yesterday, there were no network neutrality rules, not for spam or for > anything else. There still aren't any network neutrality rules, until the FCC makes the documents public, which they haven't yet. Until the FCC publish the documents: it's kind of pointless to speculate what the unintended consequences might be. However, I believe E-mail is definitely an internet application, not broadband service, so filtering incoming E-mail on the provider's servers should definitely be unaffected. So long as the broadband service provider's e-mail filtering is performed only on their e-mail server and does not involve blocking IP traffic on consumers' connections. What *might* happen is that spammers could sue if the broadband provider terminates a _subscriber's_ broadband service for sending outgoing spam, or the provider Attempts to block outgoing Port 25 traffic from their IP addresses, for the purpose of preventing operating SMTP Server applications, in order to reduce spamming attempts. (Now the service provider is blocking lawful traffic, outgoing SMTP!) My preferred resolution would be for the internet IP connectivity provider and the last mile Broadband/Layer 1 media connectivity carriers to be completely separate companies, with IP providers allowed to manage their Internet Protocol network however they see fit, and Broadband carriers required to provide equal connectivity to all competing local IP carriers. The broadband carrier need-not have an IP network, and the IP carrier might not even connect to the internet, or they might use communication protocols besides IP. > R's, > John -- -JH From jbates at paradoxnetworks.net Sun Mar 1 00:37:41 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Sat, 28 Feb 2015 18:37:41 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> Message-ID: <54F25F55.3000204@paradoxnetworks.net> On 2/28/2015 6:17 PM, Lyndon Nerenberg wrote: > Mind you, the truly annoying part of this story (for me) is knowing > Telus has fibre pedestals not a block away, with enough bandwidth to > serve up IPTV to all the condos in the neighbourhood. But I'm in the > marina across the street. Since there are only a handful of us here > with service of any sort, they aren't about to come out and reroute us > to the fibre pedestal. So I get to stay on the very long and corroded > copper circuit back to one of the original downtown Vancouver > exchanges. As one of the Telus techs said when he came out to help > troubleshoot a failing DSL modem: I am amazed it works at all :-) And > he's right -- the dB line losses are horrific. --lyndon The question is, if YOU paid for the fiber to be run to their ped, would they hook you up? Jack From lyndon at orthanc.ca Sun Mar 1 00:42:54 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 28 Feb 2015 16:42:54 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F25F55.3000204@paradoxnetworks.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F25F55.3000204@paradoxnetworks.net> Message-ID: <30AB8EC2-CF0B-41AE-919E-69BD1BC29E56@orthanc.ca> On Feb 28, 2015, at 4:37 PM, Jack Bates wrote: > The question is, if YOU paid for the fiber to be run to their ped, would they hook you up? No. But that's because they are using the fibre pedestals to deliver a high bandwidth DSL service. The condo customers still get DSLon copper, but because the copper pipe is so short they can crank a hell of a lot of bps over it. Enough to deliver HDTV, at whatever compression rate they use to their set top boxes. It's way more then the 5 Mb/s up/down (S)DSL I would be quite happy with :-) --lyndon -------------- 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 gary.buhrmaster at gmail.com Sun Mar 1 00:43:42 2015 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Sun, 1 Mar 2015 00:43:42 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F259EB.1090302@mtcc.com> References: <12510710.909.1425165605520.JavaMail.mhammett@ThunderFuck> <6B8B9E2F-7833-492D-BBA8-F5B75C69D5B3@mnsi.net> <54F259EB.1090302@mtcc.com> Message-ID: On Sun, Mar 1, 2015 at 12:14 AM, Michael Thomas wrote: .... > If they wanted to shape DOCSIS to have better upstream, > all they had to say is "JUMP" to cablelabs and the vendors > and it would have happened. Like DOCSIS 3.1? If I recall correctly, theoretical upstream up to 2.5gb/s. Your implementation will vary (and so will your roll-out dates). I also seem to recall a Broadcom press release about chips and reference designs becoming available. From johnl at iecc.com Sun Mar 1 01:03:28 2015 From: johnl at iecc.com (John R. Levine) Date: 28 Feb 2015 20:03:28 -0500 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: References: <54F0E159.2000804@satchell.net> <20150227233223.18612.qmail@ary.lan> Message-ID: > So long as the broadband service provider's e-mail filtering is > performed only on their e-mail server and does not involve blocking IP > traffic on consumers' connections. Well, actually, it does. Every broadband network in the US currently blocks outgoing port 25 connections from retail customers. > My preferred resolution would be for the internet IP connectivity > provider and the last mile Broadband/Layer 1 media connectivity carriers > to be completely separate companies, with IP providers allowed to manage > their Internet Protocol network however they see fit, and Broadband > carriers required to provide equal connectivity to all competing local > IP carriers. Yup. Works great in Europe, too easy and effective to do here. R's, John From list at satchell.net Sun Mar 1 01:24:09 2015 From: list at satchell.net (Stephen Satchell) Date: Sat, 28 Feb 2015 17:24:09 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F24614.8030805@paradoxnetworks.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24614.8030805@paradoxnetworks.net> Message-ID: <54F26A39.6030506@satchell.net> On 02/28/2015 02:49 PM, Jack Bates wrote: > On 2/28/2015 4:38 PM, Barry Shein wrote: >> Asymmetric service was introduced to discourage home users from >> deploying "commercial" services. As were bandwidth caps. >> > Hmm, at one point I was going to ask if anyone else remembered a long > time ago ISPs having something in their TOS about not hosting servers. > It's been so long, I thought that perhaps I might be remembering wrong. You remember correctly. How cable companies "enforced" this particular ToS clause would very, but one tactic was to have short DHCP leases, and guaranteee that the IP address would change at lease "renewal". To counter, we got third-party Dynamic DNS service which would allow a cable customer to periodically update the IP address of a domain, with a short TTL so that a change would take effect immediately. The other side of this: cable DNS servers would, on its own dime, cache DNS lookups with week-long TTLs to thwart Dynamic DNS. It was quite a war there for a while. (N.B.: "we forced long TTLs to reduce the traffic necessary across our peering points." At one point, the cable people said they had one, count 'em one, peering link at 44 megabits/s, to serve all cable companies [with their own internal network]. I still don't know whether to buy that or not, and now it's moot.) How did I know about the DNS server manipulation? I worked for a Web hosting company with about 3,000 domains being served. Whenever the company renumbered (until it finally got its own IP allocation in order to multi-home) we would have to service the old addresses and new addresses for a week. When the cable DNS servers finally aged out the old addresses, we could shut down the old ones. Royal admin pain in the neck. Dunno if this is still true anymore. From jbates at paradoxnetworks.net Sun Mar 1 01:33:00 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Sat, 28 Feb 2015 19:33:00 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F26A39.6030506@satchell.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24614.8030805@paradoxnetworks.net> <54F26A39.6030506@satchell.net> Message-ID: <54F26C4C.5050602@paradoxnetworks.net> On 2/28/2015 7:24 PM, Stephen Satchell wrote: > How did I know about the DNS server manipulation? I worked for a Web > hosting company with about 3,000 domains being served. Whenever the > company renumbered (until it finally got its own IP allocation in order > to multi-home) we would have to service the old addresses and new > addresses for a week. When the cable DNS servers finally aged out the > old addresses, we could shut down the old ones. Royal admin pain in the > neck. Actually, until Windows 98 finally died (perhaps ME?), I always did at least a week as windows 98 did not expire its local cache. Things were usually good after a week because windows 98 boxes tended to crash by then. I still allow several days for moves between servers, though. Never know what people are doing that they shouldn't.:) Jack From lyndon at orthanc.ca Sun Mar 1 01:39:41 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 28 Feb 2015 17:39:41 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F26A39.6030506@satchell.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24614.8030805@paradoxnetworks.net> <54F26A39.6030506@satchell.net> Message-ID: <02EAF23E-FAF9-4020-BE7B-ACE6F9EF296B@orthanc.ca> On Feb 28, 2015, at 5:24 PM, Stephen Satchell wrote: > (N.B.: "we forced long TTLs to reduce the traffic necessary across our > peering points." At one point, the cable people said they had one, > count 'em one, peering link at 44 megabits/s, to serve all cable > companies [with their own internal network]. I still don't know whether > to buy that or not, and now it's moot.) Who was the late-90s ISP that had their "geek" mouthing off on TV about them having "multiple T3's to the Internet" ??? It was a very well done commercial. I remember having a good laugh at how it parodied both ends of the "internet pipe" of the time. --lyndon -------------- 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 mark.tinka at seacom.mu Sun Mar 1 01:52:48 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 01 Mar 2015 03:52:48 +0200 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <30AB8EC2-CF0B-41AE-919E-69BD1BC29E56@orthanc.ca> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F25F55.3000204@paradoxnetworks.net> <30AB8EC2-CF0B-41AE-919E-69BD1BC29E56@orthanc.ca> Message-ID: <54F270F0.8050305@seacom.mu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/Mar/15 02:42, Lyndon Nerenberg wrote: > > > No. But that's because they are using the fibre pedestals to deliver a high bandwidth DSL service. The condo customers still get DSLon copper, but because the copper pipe is so short they can crank a hell of a lot of bps over it. Enough to deliver HDTV, at whatever compression rate they use to their set top boxes. It's way more then the 5 Mb/s up/down (S)DSL I would be quite happy with :-) I still don't get why operators do this. In my part of the world, a well-known service provider runs FTTC and then runs VDSL into the home. Ummh... In a previous country I used to work, a network had copper lines deployed as internal last mile in every building they serviced on the back of some MSAN's. When they upgraded their basement infrastructure to fibre, they thought they could get away from having to run fibre to each office/home in the building by delivering that over VDSL. For some reason, even at 6m distances, running the HD-based IPTv service across VDSL didn't work. I think the engineers in that network didn't even bother wasting their time fixing that. In the end, running fibre from the basement to each office/home did the trick - it's not like they were starving... In 2000, a big mobile carrier in an East African country was just about the first network to build Metro fibre that hit lots of commercial buildings. What did they do it with - run E1's for voice. This was their fixed-line solution at the time. Why they didn't run Ethernet instead (in 2000, when the rest of East Africa barely knew what Metro-E was, let alone many parts of the world) escapes me. If it's not fibre to the home or office gateway, where it makes no difference to run either copper or fibre from the basement or the curb, it's foolish. Mark. -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJU8nDwAAoJEGcZuYTeKm+GyAkQALGw6GKKzQ7FvUM1h7gGyMsz TY7PaCexzAHBYYV/Wgq/oJxBKoj0CCwQZwy1krA6R1xuSDlueuUqxBc153wAZKUm P3lI23bIG/IdSVi0LnjU84oM/06Q0mK7nwHAR7LGcHIdZaBrffXnVMh99eZGp0pN AHh7q2AadUHnxDSwyNXU571E9LgsZ2fIrr4ZM3BP/L510X1Fs0TWmftXjOPX7Bc3 DjJfFCWpHr/AIFVEdgq40Nwexk4HzknsUoGthm3yMykv3LQ+vqdVodCZuly0tLbs q6YbWntv+d2fsNwDDkUowY4bOZoJXiM2qngvBXmN6dMmp3AymtlZC6x+iJusgdly g3iwMNSgh4Sab2Gtdb24AvPpVNx6NkE28QUGTPvtSweUAf7IMUog3Ax8XZcJws57 toi2UJ9Q3nXFN6XyzKMvCUrVwAnZkJcP3pDdFFRB5p4Bqa+ZyZAlWii1bXVXF68r QMDL5Oj1QaaAv4tK31zd8T6E+rHnvbn+TQ7mXx626/fF8O6KKjWcD9z1WiouEKCX kIq0InQeI9BCxpuSrfvQSH+nWn/Sw40sedoU4VlPOipaUwGa5nju/rmNcDP0evP4 2JprZSCrahMJko82JPxdwOPzl80Jv+0N/ofw571JHmWv+mmwqsN++lpvzSg2XaoT P8fH+p+lz9wDvW7NfIvZ =uFe1 -----END PGP SIGNATURE----- From khelms at zcorum.com Sun Mar 1 02:15:01 2015 From: khelms at zcorum.com (Scott Helms) Date: Sat, 28 Feb 2015 21:15:01 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F24E5C.1000407@mtcc.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <82748B6A-D6D7-4963-A749-47EF4D94DD8D@mnsi.net> <54F24E5C.1000407@mtcc.com> Message-ID: Michael, You should really learn how DOCSIS systems work. What you're trying to claim it's not only untrue it is that way for very real technical reasons. On Feb 28, 2015 6:27 PM, "Michael Thomas" wrote: > > On 02/28/2015 03:14 PM, Clayton Zekelman wrote: > >> You do of course realize that the asymmetry in CATV forward path/return >> path existed LONG before residential Internet access over cable networks >> exited? >> > > The cable companies didn't want "servers" on residential customers either, > and were > animated by that. Cable didn't really have much of a return path at all at > first -- I remember > the stories of the crappy spectrum they were willing to allocate at first, > but as I recall > that was mainly because they hadn't transitioned to digital downstream and > their analog > down was pretty precious. Once they made that transition, the animus > against residential > "servers" was pretty much the only excuse -- I'm pretty sure they could > map up/down/cable > channels any way they wanted after that. > > Mike > > >> Sent from my iPhone >> >> On Feb 28, 2015, at 5:38 PM, Barry Shein wrote: >>> >>> >>> Can we stop the disingenuity? >>> >>> Asymmetric service was introduced to discourage home users from >>> deploying "commercial" services. As were bandwidth caps. >>> >>> One can argue all sorts of other "benefits" of this but when this >>> started that was the problem on the table: How do we forcibly >>> distinguish commercial (i.e., more expensive) from non-commercial >>> usage? >>> >>> Answer: Give them a lot less upload than download bandwidth. >>> >>> Originally these asymmetric, typically DSL, links were hundreds of >>> kbits upstream, not a lot more than a dial-up line. >>> >>> That and NAT thereby making it difficult -- not impossible, the savvy >>> were in the noise -- to map domain names to permanent IP addresses. >>> >>> That's all this was about. >>> >>> It's not about "that's all they need", "that's all they want", etc. >>> >>> Now that bandwidth is growing rapidly and asymmetric is often >>> 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire >>> medium-sized ISPs ran on less than 10mbps symmetric not long ago. But >>> it still imposes an upper bound of sorts, along with addressing >>> limitations and bandwidth caps. >>> >>> That's all this is about. >>> >>> The telcos for many decades distinguished "business" voice service >>> from "residential" service, even for just one phone line, though they >>> mostly just winged it and if they declared you were defrauding them by >>> using a residential line for a business they might shut you off and/or >>> back bill you. Residential was quite a bit cheaper, most importantly >>> local "unlimited" (unmetered) talk was only available on residential >>> lines. Business lines were even coded 1MB (one m b) service, one >>> metered business (line). >>> >>> The history is clear and they've just reinvented the model for >>> internet but proactively enforced by technology rather than studying >>> your usage patterns or whatever they used to do, scan for business ads >>> using "residential" numbers, beyond bandwidth usage analysis. >>> >>> And the CATV companies are trying to reinvent CATV pricing for >>> internet, turn Netflix (e.g.) into an analogue of HBO and other >>> premium CATV services. >>> >>> What's so difficult to understand here? >>> >>> -- >>> -Barry Shein >>> >>> The World | bzs at TheWorld.com | >>> http://www.TheWorld.com >>> Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, >>> Canada >>> Software Tool & Die | Public Access Internet | SINCE 1989 *oo* >>> >> > From lyndon at orthanc.ca Sun Mar 1 02:28:37 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 28 Feb 2015 18:28:37 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F270F0.8050305@seacom.mu> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F25F55.3000204@paradoxnetworks.net> <30AB8EC2-CF0B-41AE-919E-69BD1BC29E56@orthanc.ca> <54F270F0.8050305@seacom.mu> Message-ID: <1FDDC5E3-041B-49F7-B823-F7B67538ABA5@orthanc.ca> > In my part of the world, a well-known service provider runs FTTC and > then runs VDSL into the home. Ummh... I live in a 3rd word country. Oh Canada! -------------- 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 matthew at matthew.at Sun Mar 1 02:37:23 2015 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 28 Feb 2015 18:37:23 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <82748B6A-D6D7-4963-A749-47EF4D94DD8D@mnsi.net> <54F24E5C.1000407@mtcc.com> Message-ID: <79827677-DF65-4BF8-BC7A-0F95406B82F2@matthew.at> +1 Th spectral split between down and up is real, has existed for a very long time, and isn't a master of remapping. Matthew Kaufman (Sent from my iPhone) > On Feb 28, 2015, at 6:15 PM, Scott Helms wrote: > > Michael, > > You should really learn how DOCSIS systems work. What you're trying to > claim it's not only untrue it is that way for very real technical reasons. >> On Feb 28, 2015 6:27 PM, "Michael Thomas" wrote: >> >> >>> On 02/28/2015 03:14 PM, Clayton Zekelman wrote: >>> >>> You do of course realize that the asymmetry in CATV forward path/return >>> path existed LONG before residential Internet access over cable networks >>> exited? >> >> The cable companies didn't want "servers" on residential customers either, >> and were >> animated by that. Cable didn't really have much of a return path at all at >> first -- I remember >> the stories of the crappy spectrum they were willing to allocate at first, >> but as I recall >> that was mainly because they hadn't transitioned to digital downstream and >> their analog >> down was pretty precious. Once they made that transition, the animus >> against residential >> "servers" was pretty much the only excuse -- I'm pretty sure they could >> map up/down/cable >> channels any way they wanted after that. >> >> Mike >> >> >>> Sent from my iPhone >>> >>>> On Feb 28, 2015, at 5:38 PM, Barry Shein wrote: >>>> >>>> >>>> Can we stop the disingenuity? >>>> >>>> Asymmetric service was introduced to discourage home users from >>>> deploying "commercial" services. As were bandwidth caps. >>>> >>>> One can argue all sorts of other "benefits" of this but when this >>>> started that was the problem on the table: How do we forcibly >>>> distinguish commercial (i.e., more expensive) from non-commercial >>>> usage? >>>> >>>> Answer: Give them a lot less upload than download bandwidth. >>>> >>>> Originally these asymmetric, typically DSL, links were hundreds of >>>> kbits upstream, not a lot more than a dial-up line. >>>> >>>> That and NAT thereby making it difficult -- not impossible, the savvy >>>> were in the noise -- to map domain names to permanent IP addresses. >>>> >>>> That's all this was about. >>>> >>>> It's not about "that's all they need", "that's all they want", etc. >>>> >>>> Now that bandwidth is growing rapidly and asymmetric is often >>>> 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire >>>> medium-sized ISPs ran on less than 10mbps symmetric not long ago. But >>>> it still imposes an upper bound of sorts, along with addressing >>>> limitations and bandwidth caps. >>>> >>>> That's all this is about. >>>> >>>> The telcos for many decades distinguished "business" voice service >>>> from "residential" service, even for just one phone line, though they >>>> mostly just winged it and if they declared you were defrauding them by >>>> using a residential line for a business they might shut you off and/or >>>> back bill you. Residential was quite a bit cheaper, most importantly >>>> local "unlimited" (unmetered) talk was only available on residential >>>> lines. Business lines were even coded 1MB (one m b) service, one >>>> metered business (line). >>>> >>>> The history is clear and they've just reinvented the model for >>>> internet but proactively enforced by technology rather than studying >>>> your usage patterns or whatever they used to do, scan for business ads >>>> using "residential" numbers, beyond bandwidth usage analysis. >>>> >>>> And the CATV companies are trying to reinvent CATV pricing for >>>> internet, turn Netflix (e.g.) into an analogue of HBO and other >>>> premium CATV services. >>>> >>>> What's so difficult to understand here? >>>> >>>> -- >>>> -Barry Shein >>>> >>>> The World | bzs at TheWorld.com | >>>> http://www.TheWorld.com >>>> Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, >>>> Canada >>>> Software Tool & Die | Public Access Internet | SINCE 1989 *oo* >> From khelms at zcorum.com Sun Mar 1 02:38:54 2015 From: khelms at zcorum.com (Scott Helms) Date: Sat, 28 Feb 2015 21:38:54 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F259EB.1090302@mtcc.com> References: <12510710.909.1425165605520.JavaMail.mhammett@ThunderFuck> <6B8B9E2F-7833-492D-BBA8-F5B75C69D5B3@mnsi.net> <54F259EB.1090302@mtcc.com> Message-ID: You're off on this. When PacketCable 1.0 was in development and it's early deployment there were no OTT VOIP providers of note. Vonage at that time was trying sell their services to the MSOs and only when that didn't work or did they start going directly to consumers via SIP. The prioritization mechanisms in PacketCable exist because the thought was that they were needed to compete with POTS and that's it and at that time, when upstreams were more contended that was probably the case. On Feb 28, 2015 7:15 PM, "Michael Thomas" wrote: > > On 02/28/2015 03:35 PM, Clayton Zekelman wrote: > >> And for historical reasons. The forward path started at TV channel 2. >> The return path was shoe horned in to the frequencies below that, which >> limited the amount of available spectrum for return path. >> >> Originally this didn't matter much because the only thing it was used for >> was set top box communications and occasionally sending video to the head >> end for community channel remote feeds. >> >> To change the split would require replacement of all the active and >> passive RF equipment in the network. >> >> Only now with he widespread conversion to digital cable are they able to >> free up enough spectrum to even consider moving the split at some point in >> the future. >> > > Something else to keep in mind, is that the cable companies wanted to use > the > upstream for voice using DOCSIS QoS to create a big advantage over anybody > else who might want to just do voice over the top. > > There was lots of talk about business advantage, evil home servers, etc, > etc > and no care at all about legitimate uses for customer upstream. If they > wanted > to shape DOCSIS to have better upstream, all they had to say is "JUMP" to > cablelabs > and the vendors and it would have happened. > > Mike > > >> Sent from my iPhone >> >> On Feb 28, 2015, at 6:20 PM, Mike Hammett wrote: >>> >>> As I said earlier, there are only so many channels available. Channels >>> added to upload are taken away from download. People use upload so >>> infrequently it would be gross negligence on the provider's behalf. >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> ----- Original Message ----- >>> >>> From: "Clayton Zekelman" >>> To: "Barry Shein" >>> Cc: "NANOG" >>> Sent: Saturday, February 28, 2015 5:14:18 PM >>> Subject: Re: Verizon Policy Statement on Net Neutrality >>> >>> You do of course realize that the asymmetry in CATV forward path/return >>> path existed LONG before residential Internet access over cable networks >>> exited? >>> >>> Sent from my iPhone >>> >>> On Feb 28, 2015, at 5:38 PM, Barry Shein wrote: >>>> >>>> >>>> Can we stop the disingenuity? >>>> >>>> Asymmetric service was introduced to discourage home users from >>>> deploying "commercial" services. As were bandwidth caps. >>>> >>>> One can argue all sorts of other "benefits" of this but when this >>>> started that was the problem on the table: How do we forcibly >>>> distinguish commercial (i.e., more expensive) from non-commercial >>>> usage? >>>> >>>> Answer: Give them a lot less upload than download bandwidth. >>>> >>>> Originally these asymmetric, typically DSL, links were hundreds of >>>> kbits upstream, not a lot more than a dial-up line. >>>> >>>> That and NAT thereby making it difficult -- not impossible, the savvy >>>> were in the noise -- to map domain names to permanent IP addresses. >>>> >>>> That's all this was about. >>>> >>>> It's not about "that's all they need", "that's all they want", etc. >>>> >>>> Now that bandwidth is growing rapidly and asymmetric is often >>>> 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire >>>> medium-sized ISPs ran on less than 10mbps symmetric not long ago. But >>>> it still imposes an upper bound of sorts, along with addressing >>>> limitations and bandwidth caps. >>>> >>>> That's all this is about. >>>> >>>> The telcos for many decades distinguished "business" voice service >>>> from "residential" service, even for just one phone line, though they >>>> mostly just winged it and if they declared you were defrauding them by >>>> using a residential line for a business they might shut you off and/or >>>> back bill you. Residential was quite a bit cheaper, most importantly >>>> local "unlimited" (unmetered) talk was only available on residential >>>> lines. Business lines were even coded 1MB (one m b) service, one >>>> metered business (line). >>>> >>>> The history is clear and they've just reinvented the model for >>>> internet but proactively enforced by technology rather than studying >>>> your usage patterns or whatever they used to do, scan for business ads >>>> using "residential" numbers, beyond bandwidth usage analysis. >>>> >>>> And the CATV companies are trying to reinvent CATV pricing for >>>> internet, turn Netflix (e.g.) into an analogue of HBO and other >>>> premium CATV services. >>>> >>>> What's so difficult to understand here? >>>> >>>> -- >>>> -Barry Shein >>>> >>>> The World | bzs at TheWorld.com | http://www.TheWorld.com >>>> Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada >>>> Software Tool & Die | Public Access Internet | SINCE 1989 *oo* >>>> >>> > From bzs at world.std.com Sun Mar 1 03:05:32 2015 From: bzs at world.std.com (Barry Shein) Date: Sat, 28 Feb 2015 22:05:32 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <00a201d053a2$fbbcdbd0$f3369370$@gwsystems.co.il> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <54F21019.8070700@meetinghouse.net> <00a201d053a2$fbbcdbd0$f3369370$@gwsystems.co.il> Message-ID: <21746.33276.936473.525383@world.std.com> On February 28, 2015 at 17:07 gwardell at gwsystems.co.il (Gary Wardell) wrote: > > Actually, I think the incumbents do get it, at this point - at least Verizon does. FIOS is a pretty nice offering, and they offer some pretty high speeds, > > both up and down. Don't hold your breaths. Back around 2000 Verizon took about $2B in tax breaks to "do something" with fiber. A couple of years later someone in Congress noticed they hadn't done anything (other than took the tax breaks) and got on their case, do something or return the tax breaks (and probably other trouble.) So they formed a unit and spun up FiOS. It's not a business in the traditional sense, it was a way of staying out of jail (metaphorically speaking.) That's why it happened for a while and then came to a halt. Not that the unit didn't give it the old college try, you can do some interesting things with a coupla billion in cash and a mandate. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From bzs at world.std.com Sun Mar 1 03:17:11 2015 From: bzs at world.std.com (Barry Shein) Date: Sat, 28 Feb 2015 22:17:11 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <20150228224632.CB39B2A930D4@rock.dv.isc.org> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> Message-ID: <21746.33975.578280.181107@world.std.com> On March 1, 2015 at 09:46 marka at isc.org (Mark Andrews) wrote: > > Home users should be able to upload a content in the same amount > of time it takes to download content. It doesn't matter if they > only do this occasionally. Without symetric speeds they can't do > this. They are being given a slow path. > > Arguing otherwise is like saying that their time is not important. > > Yes, that capacity is sitting idle most of the time but so what! > We really should be delivering connections where link speed is not > the limiting factor. Yes, good point, the "occasional" argument would better apply to asymmetric up/down monthly bandwidth caps than bandwidth limitations. But I still think it's push/pull. I remember when downloading still images (dial-up days) was considered bandwidth hogging and only something very few people did. Of course no one did it, it took minutes to download even a rather small image and there was little market for image-oriented software (other than porn.) -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From bzs at world.std.com Sun Mar 1 03:23:22 2015 From: bzs at world.std.com (Barry Shein) Date: Sat, 28 Feb 2015 22:23:22 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <27896791.814.1425163775749.JavaMail.mhammett@ThunderFuck> References: <21746.17258.270398.162820@world.std.com> <27896791.814.1425163775749.JavaMail.mhammett@ThunderFuck> Message-ID: <21746.34346.102944.789034@world.std.com> On February 28, 2015 at 16:50 nanog at ics-il.net (Mike Hammett) wrote: > Spoken by someone that apparently has no idea how things work. Now there's a deep and insightful refutation. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Barry Shein" > To: "NANOG" > Sent: Saturday, February 28, 2015 4:38:34 PM > Subject: Re: Verizon Policy Statement on Net Neutrality > > > Can we stop the disingenuity? > > Asymmetric service was introduced to discourage home users from > deploying "commercial" services. As were bandwidth caps. > > One can argue all sorts of other "benefits" of this but when this > started that was the problem on the table: How do we forcibly > distinguish commercial (i.e., more expensive) from non-commercial > usage? > > Answer: Give them a lot less upload than download bandwidth. > > Originally these asymmetric, typically DSL, links were hundreds of > kbits upstream, not a lot more than a dial-up line. > > That and NAT thereby making it difficult -- not impossible, the savvy > were in the noise -- to map domain names to permanent IP addresses. > > That's all this was about. > > It's not about "that's all they need", "that's all they want", etc. > > Now that bandwidth is growing rapidly and asymmetric is often > 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire > medium-sized ISPs ran on less than 10mbps symmetric not long ago. But > it still imposes an upper bound of sorts, along with addressing > limitations and bandwidth caps. > > That's all this is about. > > The telcos for many decades distinguished "business" voice service > from "residential" service, even for just one phone line, though they > mostly just winged it and if they declared you were defrauding them by > using a residential line for a business they might shut you off and/or > back bill you. Residential was quite a bit cheaper, most importantly > local "unlimited" (unmetered) talk was only available on residential > lines. Business lines were even coded 1MB (one m b) service, one > metered business (line). > > The history is clear and they've just reinvented the model for > internet but proactively enforced by technology rather than studying > your usage patterns or whatever they used to do, scan for business ads > using "residential" numbers, beyond bandwidth usage analysis. > > And the CATV companies are trying to reinvent CATV pricing for > internet, turn Netflix (e.g.) into an analogue of HBO and other > premium CATV services. > > What's so difficult to understand here? > > -- > -Barry Shein > > The World | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From lyndon at orthanc.ca Sun Mar 1 03:26:48 2015 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 28 Feb 2015 19:26:48 -0800 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <21746.33975.578280.181107@world.std.com> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <21746.33975.578280.181107@world.std.com> Message-ID: <180FDF7C-170A-4C98-ACCA-039DB453AD63@orthanc.ca> On Feb 28, 2015, at 7:17 PM, Barry Shein wrote: > I remember when downloading still images (dial-up days) was considered > bandwidth hogging and only something very few people did. Of course no > one did it, it took minutes to download even a rather small image and > there was little market for image-oriented software (other than porn.) That was 1992-4ish? I helped spin up early ISPs back then. The traffic analysis we did at the time showed the porn crowd came out after dark and left at sunrise. And they were facing self-limiting servers that could not keep up with the demand anyway, so the 'average' customer base wasn't affected. This crossed a pair of ISPs each backed by a single T1 trunk to "the internet" and two T1 channel banks for the dialup pool. Not quite "The World" but it was big time stuff for where we were. -------------- 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 bzs at world.std.com Sun Mar 1 03:28:16 2015 From: bzs at world.std.com (Barry Shein) Date: Sat, 28 Feb 2015 22:28:16 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <82748B6A-D6D7-4963-A749-47EF4D94DD8D@mnsi.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <82748B6A-D6D7-4963-A749-47EF4D94DD8D@mnsi.net> Message-ID: <21746.34640.36061.415267@world.std.com> On February 28, 2015 at 18:14 clayton at mnsi.net (Clayton Zekelman) wrote: > You do of course realize that the asymmetry in CATV forward path/return path existed LONG before residential Internet access over cable networks exited? You mean back when it was all analog and DOCSIS didn't exist? > > Sent from my iPhone > > > On Feb 28, 2015, at 5:38 PM, Barry Shein wrote: > > > > > > Can we stop the disingenuity? > > > > Asymmetric service was introduced to discourage home users from > > deploying "commercial" services. As were bandwidth caps. > > > > One can argue all sorts of other "benefits" of this but when this > > started that was the problem on the table: How do we forcibly > > distinguish commercial (i.e., more expensive) from non-commercial > > usage? > > > > Answer: Give them a lot less upload than download bandwidth. > > > > Originally these asymmetric, typically DSL, links were hundreds of > > kbits upstream, not a lot more than a dial-up line. > > > > That and NAT thereby making it difficult -- not impossible, the savvy > > were in the noise -- to map domain names to permanent IP addresses. > > > > That's all this was about. > > > > It's not about "that's all they need", "that's all they want", etc. > > > > Now that bandwidth is growing rapidly and asymmetric is often > > 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire > > medium-sized ISPs ran on less than 10mbps symmetric not long ago. But > > it still imposes an upper bound of sorts, along with addressing > > limitations and bandwidth caps. > > > > That's all this is about. > > > > The telcos for many decades distinguished "business" voice service > > from "residential" service, even for just one phone line, though they > > mostly just winged it and if they declared you were defrauding them by > > using a residential line for a business they might shut you off and/or > > back bill you. Residential was quite a bit cheaper, most importantly > > local "unlimited" (unmetered) talk was only available on residential > > lines. Business lines were even coded 1MB (one m b) service, one > > metered business (line). > > > > The history is clear and they've just reinvented the model for > > internet but proactively enforced by technology rather than studying > > your usage patterns or whatever they used to do, scan for business ads > > using "residential" numbers, beyond bandwidth usage analysis. > > > > And the CATV companies are trying to reinvent CATV pricing for > > internet, turn Netflix (e.g.) into an analogue of HBO and other > > premium CATV services. > > > > What's so difficult to understand here? > > > > -- > > -Barry Shein > > > > The World | bzs at TheWorld.com | http://www.TheWorld.com > > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada > > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From frnkblk at iname.com Sun Mar 1 03:32:49 2015 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 28 Feb 2015 21:32:49 -0600 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F1E902.3080205@satchell.net> References: <9934552.473.1425139050703.JavaMail.mhammett@ThunderFuck> <54F1E902.3080205@satchell.net> Message-ID: <000801d053d0$647f1f20$2d7d5d60$@iname.com> Yes, it's changing -- the ratio is higher. At least that's what tracking of our eyeball customers has shown over the last 6+ years. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Stephen Satchell Sent: Saturday, February 28, 2015 10:13 AM To: nanog at nanog.org Subject: Re: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] I will grant you that, today, traffic is still asymmetric. The ratio of downstream/upstream is changing, as well as the total amount of traffic. Who knows what tomorrow will bring? Developers are not sitting on their tails... From bob at FiberInternetCenter.com Sun Mar 1 03:40:01 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Sat, 28 Feb 2015 19:40:01 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <21746.34346.102944.789034@world.std.com> References: <21746.17258.270398.162820@world.std.com> <27896791.814.1425163775749.JavaMail.mhammett@ThunderFuck> <21746.34346.102944.789034@world.std.com> Message-ID: > > Asymmetric service was introduced to discourage home users from > > deploying "commercial" services. As were bandwidth caps. Noooo, it was not. It was a technology issue from the very beginning. Technology limits of coax cable plants even before DOCSIS. Also dslam designs were such that they knew the direction of packets would be based on the need to deliver content. But Byte transfer caps (not bandwidth) were based on the high throughput limits of the C.O. and headend gear together with a marketers ability to over selling to a consumer. Bob Evans From bzs at world.std.com Sun Mar 1 03:41:16 2015 From: bzs at world.std.com (Barry Shein) Date: Sat, 28 Feb 2015 22:41:16 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F24D31.40200@foobar.org> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> Message-ID: <21746.35420.759630.472893@world.std.com> On February 28, 2015 at 23:20 nick at foobar.org (Nick Hilliard) wrote: > On 28/02/2015 22:38, Barry Shein wrote: > > Asymmetric service was introduced to discourage home users from > > deploying "commercial" services. > > there were several reasons for asymmetric services, one of which was > commercial. Another was that most users' bandwidth profiles were massively > asymmetric to start with so it made sense for consumers to have more > bandwidth in one direction than another. How could they have known this before it was introduced? I say that was prescriptive and a best guess that it'd be acceptable and a way to differentiate commercial from residential service. Previously all residential service (e.g., dial-up, ISDN) was symmetrical. Maybe they had some data on that usage but it'd be muddy just due to the low bandwidth they provided. Another still was that cross-talk > causes enough interference to prevent reverse adsl (i.e. greater bandwidth > from customer to exchange) from working well. So SDSL didn't exist? Anyhow, *DSL is falling so far behind it's difficult to analyze what could have been. > > > As were bandwidth caps. > > Bandwidth caps were introduced in many cases to stop gratuitous abuse of > service by the 1% of users who persistently ran their links at a rate that > the pricing model they selected was not designed to handle. You've been > around the block a bit so I'm sure you remember the days when transit was > expensive and a major cost factor in running an isp. It was the combination of asymmetric, no or few IPs (and NAT), and bandwidth caps. But of course they weren't happy with those few who found ways to use a lot of bandwidth but I thought we weren't talking about the few. > Some operators used and continue to use asymmetric bandwidth profiles and > bandwidth caps as methods for driving up revenue rather than anything else > in particular. International cellular roaming plans come to mind as one of > the more egregious example of this, but there are many others. Sure. once it became institutionalized and the market got used to it why not sell tiered bandwidth services at different price points, but that could have been true of symmetrical service also. But in the beginning these were ways to forcibly distinguish residential from more expensive commercial service. "Forcibly" as in not polling actual usage such as for lots of port 80/443 connections inbound or checking postal addresses for residential vs business as telcos used to do for voice service, etc. Maybe "passively" is a better term. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From bzs at world.std.com Sun Mar 1 03:55:19 2015 From: bzs at world.std.com (Barry Shein) Date: Sat, 28 Feb 2015 22:55:19 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <12510710.909.1425165605520.JavaMail.mhammett@ThunderFuck> References: <82748B6A-D6D7-4963-A749-47EF4D94DD8D@mnsi.net> <12510710.909.1425165605520.JavaMail.mhammett@ThunderFuck> Message-ID: <21746.36263.888013.735298@world.std.com> On February 28, 2015 at 17:20 nanog at ics-il.net (Mike Hammett) wrote: > As I said earlier, there are only so many channels available. Channels added to upload are taken away from download. People use upload so infrequently it would be gross negligence on the provider's behalf. And as I said earlier it's push/pull, give people lousy upload speeds and they won't use services which depend on good upload speeds. And given lousy upload speeds the opportunities to develop for example backup services in a world of terabyte disks is limited. At 1mb/s it takes approx 100,000 seconds to upload 1TB, that's roughly one week, blue sky. Doesn't seem like the basis for a good business plan tho obviously it's more complicated than that IRL. Maybe there are enough people with 10+mb/s upload speeds today to make a go of such a business, uploading a TB in 18 hrs might be within reason as one doesn't do that often assuming some sort of incremental backup. Until download speeds approximated video speed I'd imagine few people used streaming video, so NetFlix mailed DVD's via USPS. etc. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Clayton Zekelman" > To: "Barry Shein" > Cc: "NANOG" > Sent: Saturday, February 28, 2015 5:14:18 PM > Subject: Re: Verizon Policy Statement on Net Neutrality > > You do of course realize that the asymmetry in CATV forward path/return path existed LONG before residential Internet access over cable networks exited? > > Sent from my iPhone > > > On Feb 28, 2015, at 5:38 PM, Barry Shein wrote: > > > > > > Can we stop the disingenuity? > > > > Asymmetric service was introduced to discourage home users from > > deploying "commercial" services. As were bandwidth caps. > > > > One can argue all sorts of other "benefits" of this but when this > > started that was the problem on the table: How do we forcibly > > distinguish commercial (i.e., more expensive) from non-commercial > > usage? > > > > Answer: Give them a lot less upload than download bandwidth. > > > > Originally these asymmetric, typically DSL, links were hundreds of > > kbits upstream, not a lot more than a dial-up line. > > > > That and NAT thereby making it difficult -- not impossible, the savvy > > were in the noise -- to map domain names to permanent IP addresses. > > > > That's all this was about. > > > > It's not about "that's all they need", "that's all they want", etc. > > > > Now that bandwidth is growing rapidly and asymmetric is often > > 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire > > medium-sized ISPs ran on less than 10mbps symmetric not long ago. But > > it still imposes an upper bound of sorts, along with addressing > > limitations and bandwidth caps. > > > > That's all this is about. > > > > The telcos for many decades distinguished "business" voice service > > from "residential" service, even for just one phone line, though they > > mostly just winged it and if they declared you were defrauding them by > > using a residential line for a business they might shut you off and/or > > back bill you. Residential was quite a bit cheaper, most importantly > > local "unlimited" (unmetered) talk was only available on residential > > lines. Business lines were even coded 1MB (one m b) service, one > > metered business (line). > > > > The history is clear and they've just reinvented the model for > > internet but proactively enforced by technology rather than studying > > your usage patterns or whatever they used to do, scan for business ads > > using "residential" numbers, beyond bandwidth usage analysis. > > > > And the CATV companies are trying to reinvent CATV pricing for > > internet, turn Netflix (e.g.) into an analogue of HBO and other > > premium CATV services. > > > > What's so difficult to understand here? > > > > -- > > -Barry Shein > > > > The World | bzs at TheWorld.com | http://www.TheWorld.com > > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada > > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From owen at delong.com Sun Mar 1 06:00:49 2015 From: owen at delong.com (Owen DeLong) Date: Sat, 28 Feb 2015 22:00:49 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <21746.35420.759630.472893@world.std.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> Message-ID: >> causes enough interference to prevent reverse adsl (i.e. greater bandwidth >> from customer to exchange) from working well. > > So SDSL didn't exist? Anyhow, *DSL is falling so far behind it's > difficult to analyze what could have been. > SDSL existed, but every bps upstream that you get in SDSL is a bps that you can’t use for downstream. Usually in 128kbps chunks. So, for example, if you have a line that will support ADSL/VDSL at 1536/768, it can also work at 2048/256 or 1280/1024. For SDSL, you’d get a maximum of 1152/1152 on that same line. Looking at my usage patterns, 1536/768 is probably the best balance. However, I’d bet that the vast majority of residential users would be happier with 2048/256 than 1536/768. I know that 1152/1152 definitely wouldn’t be desirable in my case or in most cases. Now, as speeds get higher and the downstream speed starts to be adequate or exceed adequate, getting close to symmetry looks more appealing because stealing from the downstream channel to provide faster uploads on the occasions when the traffic pattern shifts is less painful most of the time. Still, that doesn’t mean that symmetrical is the best choice in all cases. >> Some operators used and continue to use asymmetric bandwidth profiles and >> bandwidth caps as methods for driving up revenue rather than anything else >> in particular. International cellular roaming plans come to mind as one of >> the more egregious example of this, but there are many others. > > Sure. once it became institutionalized and the market got used to it > why not sell tiered bandwidth services at different price points, but > that could have been true of symmetrical service also. And, indeed, it is even at the large end of the spectrum, even today. A 100Mbps circuit will cost you a little more than 10% of a 1G circuit. A 1G circuit will cost a little more than 10% of a 10G circuit, etc. Oddly, however, at the residential side, this often is inverse. Often, a 10M service will cost you less than 1/2 of a 20M service which is again significantly less than 1/2 the price of a 50M service. For example: 10M/1M $45/month 20M/5M $120/month 50M/10M $300/month I don’t know if this is still an accurate reflection of any actual provider’s pricing, but it is adequately exemplary of several that are out there today. Owen From list at satchell.net Sun Mar 1 10:08:04 2015 From: list at satchell.net (Stephen Satchell) Date: Sun, 01 Mar 2015 02:08:04 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <21746.36263.888013.735298@world.std.com> References: <82748B6A-D6D7-4963-A749-47EF4D94DD8D@mnsi.net> <12510710.909.1425165605520.JavaMail.mhammett@ThunderFuck> <21746.36263.888013.735298@world.std.com> Message-ID: <54F2E504.3090408@satchell.net> On 02/28/2015 07:55 PM, Barry Shein wrote: > And given lousy upload speeds the opportunities to develop for example > backup services in a world of terabyte disks is limited. At 1mb/s it > takes approx 100,000 seconds to upload 1TB, that's roughly one week, > blue sky. If that terabyte drive holds little files and the backup program uses incremental backup, a slow upload rate shouldn't be all that painful. Video editors need to look at local-network solutions for their backup, at least until upload rates increase by a factor of 10 or better. It just hit me: when one has just a hammer in his toolbox everything starts to look like nails. Network-based storage could just be one of those. From jgreco at ns.sol.net Sun Mar 1 12:12:50 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 1 Mar 2015 06:12:50 -0600 (CST) Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F2E504.3090408@satchell.net> Message-ID: <201503011212.t21CCoks036339@aurora.sol.net> > On 02/28/2015 07:55 PM, Barry Shein wrote: > > And given lousy upload speeds the opportunities to develop for example > > backup services in a world of terabyte disks is limited. At 1mb/s it > > takes approx 100,000 seconds to upload 1TB, that's roughly one week, > > blue sky. > > If that terabyte drive holds little files and the backup program uses > incremental backup, a slow upload rate shouldn't be all that painful. > Video editors need to look at local-network solutions for their backup, > at least until upload rates increase by a factor of 10 or better. > > It just hit me: when one has just a hammer in his toolbox everything > starts to look like nails. Network-based storage could just be one of > those. That was probably true back when Ethernet was 10Mbps ... let's say 1992. But then along came 100Mbps in 1995, and 1GbE in 1999, and then 10GbE in 2002. In the period of 10 years, the technology became 1000x faster. I don't buy that "network-based storage could just be one of those." Just because the broadband networks we have today aren't up to the task doesn't make this a reasonable point. Remember that the National Information Infrastructure was supposed to deliver 45Mbps symmetric connections to the end user back in the '90's, a visionary goal but one that was ultimately subverted in the name of telco profits. http://it.tmcnet.com/topics/it/articles/70379-net-that-got-away.htm ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From aledm at qix.co.uk Sun Mar 1 11:40:31 2015 From: aledm at qix.co.uk (Aled Morris) Date: Sun, 1 Mar 2015 11:40:31 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <21746.35420.759630.472893@world.std.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> Message-ID: On 1 March 2015 at 03:41, Barry Shein wrote: > Previously all residential service (e.g., dial-up, ISDN) was > symmetrical. The rot set in with V.90 "56k" modems - they were asymmetric - only the downstream was 56k. The only way to achieve this in the analogue realm was by digital synthesis at the head-end, i.e. the T1/E1 handoff to the ISP. The upstream from the subscriber didn't have a clean interface so was still using 33.6k. Sadly we don't have many "killer applications" for symmetric residential bandwidth, but that's likely because we don't have the infrastructure to incubate these applications. It's a chicken and egg situation - of course the average consumer today will say they "don't need" symmetric, but you could have asked them twenty years ago and they'd have said they didn't need the Internet at all. Or smartphones. This all suits the telcos and cablecos very nicely - they are happy when their customers are passive consumers of paid content and services. It gives them control. I don't think it's a conspiracy, but it suits the big players not to "fix" the "problem" since they don't perceive it as being one. Aled From mansaxel at besserwisser.org Sun Mar 1 12:20:28 2015 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sun, 1 Mar 2015 13:20:28 +0100 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F0FCF5.80006@paradoxnetworks.net> References: <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CA30.7080706@paradoxnetworks.net> <20150227230942.GA24347@besserwisser.org> <54F0FCF5.80006@paradoxnetworks.net> Message-ID: <20150301122028.GD24347@besserwisser.org> Subject: Re: Verizon Policy Statement on Net Neutrality Date: Fri, Feb 27, 2015 at 05:25:41PM -0600 Quoting Jack Bates (jbates at paradoxnetworks.net): > On 2/27/2015 5:09 PM, Måns Nilsson wrote: > >What people want, at least once thay have tasted it, is optical > >last mile. And not that PON shit. The real stuff or bust. > > Yeah. Then they complain when a tornado wipes out their power and > they can't make a phone call. Given the state of the partially deregulated phone system and people tending to depend on DECT phones, that is a non-dividing issue, in a lot of cases. Me, I keep a landline with a rotary phone. > It's hard to get DSL in some places in the country. Fiber? ha! The current state of the affairs in rural / semi-rural USA is not the standard we should strive for. Focusing too hard on the limitations appearing as inherent to the casual observer will choke developement. We can look at that techno-echonomical situation and use it as a starting point, but nothing else. (were I more of an entreprenour I'd look at "no DSL available" as a golden opportunity to get lots of fibre customers. Not replacing copper but augmenting it also solves the distress problem. That or a 12V battery to power the Ethernet converter and the ATA Box.) -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Well, I'm a classic ANAL RETENTIVE!! And I'm looking for a way to VICARIOUSLY experience some reason to LIVE!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From rsk at gsp.org Sun Mar 1 12:48:46 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 1 Mar 2015 07:48:46 -0500 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: References: <54F0E159.2000804@satchell.net> <20150227233223.18612.qmail@ary.lan> Message-ID: <20150301124846.GA16378@gsp.org> On Sat, Feb 28, 2015 at 08:03:28PM -0500, John R. Levine wrote: > Well, actually, it does. Every broadband network in the US > currently blocks outgoing port 25 connections from retail customers. Unfortunately, that's not entirely true. (Very) recent direct-to-MX spam from Comcast customers: 24.7.48.153 c-24-7-48-153.hsd1.ca.comcast.net 24.10.217.142 c-24-10-217-142.hsd1.ut.comcast.net 24.129.85.220 c-24-129-85-220.hsd1.fl.comcast.net 50.130.64.172 c-50-130-64-172.hsd1.tn.comcast.net 50.162.220.128 c-50-162-220-128.hsd1.fl.comcast.net 50.165.94.164 c-50-165-94-164.hsd1.il.comcast.net 50.165.121.16 c-50-165-121-16.hsd1.in.comcast.net 68.56.178.193 c-68-56-178-193.hsd1.fl.comcast.net 71.229.180.119 c-71-229-180-119.hsd1.co.comcast.net 71.234.26.63 c-71-234-26-63.hsd1.ct.comcast.net 73.47.106.185 c-73-47-106-185.hsd1.ma.comcast.net 73.163.27.108 c-73-163-27-108.hsd1.dc.comcast.net 73.171.39.246 c-73-171-39-246.hsd1.va.comcast.net 73.198.24.166 c-73-198-24-166.hsd1.nj.comcast.net 75.67.200.133 c-75-67-200-133.hsd1.ma.comcast.net 76.30.102.104 c-76-30-102-104.hsd1.tx.comcast.net 76.116.249.169 c-76-116-249-169.hsd1.nj.comcast.net 98.194.102.63 c-98-194-102-63.hsd1.tx.comcast.net 98.196.186.124 c-98-196-186-124.hsd1.tx.comcast.net 98.229.88.228 c-98-229-88-228.hsd1.ma.comcast.net 98.233.42.2 c-98-233-42-2.hsd1.md.comcast.net 98.242.32.247 c-98-242-32-247.hsd1.ca.comcast.net 107.5.40.153 c-107-5-40-153.hsd1.mi.comcast.net 174.59.200.13 c-174-59-200-13.hsd1.pa.comcast.net And Time-Warner customers: 24.25.253.81 cpe-24-25-253-81.hawaii.res.rr.com 24.27.121.156 cpe-24-27-121-156.tx.res.rr.com 24.29.64.79 cpe-24-29-64-79.nycap.res.rr.com 24.59.66.78 cpe-24-59-66-78.twcny.res.rr.com 24.88.94.165 cpe-024-088-094-165.sc.res.rr.com 24.90.21.156 cpe-24-90-21-156.nyc.res.rr.com 24.163.27.190 cpe-024-163-027-190.triad.res.rr.com 24.163.91.145 cpe-024-163-091-145.nc.res.rr.com 24.164.150.4 cpe-24-164-150-4.si.res.rr.com 24.165.29.203 cpe-24-165-29-203.hawaii.res.rr.com 24.193.228.223 cpe-24-193-228-223.nyc.res.rr.com 65.191.116.113 cpe-065-191-116-113.nc.res.rr.com 66.75.15.251 cpe-66-75-15-251.san.res.rr.com 66.108.180.35 cpe-66-108-180-35.nyc.res.rr.com 67.11.76.246 cpe-67-11-76-246.rgv.res.rr.com 67.246.130.165 cpe-67-246-130-165.stny.res.rr.com 67.252.31.129 cpe-67-252-31-129.nycap.res.rr.com 68.207.225.95 95-225.207-68.tampabay.res.rr.com 68.207.226.177 177-226.207-68.tampabay.res.rr.com 70.92.2.220 cpe-70-92-2-220.wi.res.rr.com 70.92.13.93 cpe-70-92-13-93.wi.res.rr.com 70.124.120.145 cpe-70-124-120-145.stx.res.rr.com 71.65.225.141 cpe-071-065-225-141.nc.res.rr.com 71.72.101.199 cpe-71-72-101-199.columbus.res.rr.com 72.131.3.138 cpe-72-131-3-138.wi.res.rr.com 72.133.60.75 cpe-72-133-60-75.new.res.rr.com 72.181.54.177 cpe-72-181-54-177.rgv.res.rr.com 72.181.88.187 cpe-72-181-88-187.stx.res.rr.com 72.225.154.15 cpe-72-225-154-15.nj.res.rr.com 72.227.137.8 cpe-72-227-137-8.nyc.res.rr.com 74.137.19.108 cpe-74-137-19-108.swo.res.rr.com 74.138.245.76 cpe-74-138-245-76.swo.res.rr.com 75.179.4.175 cpe-75-179-4-175.neo.res.rr.com 75.191.230.203 cpe-075-191-230-203.ec.res.rr.com 76.170.88.22 cpe-76-170-88-22.socal.res.rr.com 98.30.172.37 cpe-98-30-172-37.woh.res.rr.com 104.229.55.248 cpe-104-229-55-248.rochester.res.rr.com 107.15.246.227 cpe-107-015-246-227.nc.res.rr.com 107.184.5.61 cpe-107-184-5-61.socal.res.rr.com 108.183.132.10 cpe-108-183-132-10.maine.res.rr.com 142.105.47.206 cpe-142-105-47-206.nj.res.rr.com 142.136.44.21 cpe-142-136-44-21.socal.res.rr.com 172.248.255.13 cpe-172-248-255-13.socal.res.rr.com 173.172.110.208 cpe-173-172-110-208.kc.res.rr.com 173.172.209.8 cpe-173-172-209-8.elp.res.rr.com 174.97.185.69 cpe-174-097-185-069.nc.res.rr.com 174.98.86.73 cpe-174-098-086-073.triad.res.rr.com 184.57.187.144 cpe-184-57-187-144.cinci.res.rr.com 198.72.234.76 cpe-198-72-234-76.socal.res.rr.com 23.240.176.98 cpe-23-240-176-98.socal.res.rr.com And Charter customers: 24.107.177.229 24-107-177-229.dhcp.stls.mo.charter.com 24.179.114.97 24-179-114-97.dhcp.oxfr.ma.charter.com 24.181.102.209 24-181-102-209.dhcp.leds.al.charter.com 24.216.108.175 24-216-108-175.dhcp.spbg.sc.charter.com 24.216.126.30 24-216-126-30.dhcp.stls.mo.charter.com 24.217.26.70 24-217-26-70.dhcp.stls.mo.charter.com 68.117.145.157 68-117-145-157.dhcp.unas.al.charter.com 68.187.203.34 68-187-203-34.dhcp.ahvl.nc.charter.com 68.188.144.106 68-188-144-106.dhcp.aldl.mi.charter.com 68.190.112.8 68-190-112-8.dhcp.mdsn.wi.charter.com 71.10.113.254 71-10-113-254.dhcp.stpt.wi.charter.com 71.15.87.181 71-15-87-181.dhcp.gnvl.sc.charter.com 71.81.2.94 71-81-2-94.dhcp.ahvl.nc.charter.com 71.82.123.81 71-82-123-81.dhcp.roch.mn.charter.com 71.87.159.214 71-87-159-214.dhcp.hlrg.nc.charter.com 71.88.124.17 71-88-124-17.dhcp.jcsn.tn.charter.com 71.88.162.4 71-88-162-4.dhcp.jcsn.tn.charter.com 71.91.32.99 71-91-32-99.dhcp.leds.al.charter.com 71.93.217.124 71-93-217-124.dhcp.psdn.ca.charter.com 75.134.228.105 75-134-228-105.dhcp.oxfr.ma.charter.com 75.137.29.178 75-137-29-178.dhcp.nwnn.ga.charter.com 75.138.79.107 75-138-79-107.dhcp.gwnt.ga.charter.com 96.33.158.221 96-33-158-221.dhcp.slid.la.charter.com 97.82.153.165 97-82-153-165.dhcp.hckr.nc.charter.com 97.82.173.147 97-82-173-147.dhcp.hckr.nc.charter.com 97.84.50.56 97-84-50-56.dhcp.leds.al.charter.com 97.85.80.159 97-85-80-159.dhcp.trcy.mi.charter.com 97.87.166.194 97-87-166-194.dhcp.stls.mo.charter.com 97.91.197.125 97-91-197-125.dhcp.stls.mo.charter.com 97.93.16.32 97-93-16-32.dhcp.snlo.ca.charter.com And AT&T customers: 71.154.186.54 adsl-71-154-186-54.dsl.chcgil.sbcglobal.net 75.17.194.68 adsl-75-17-194-68.dsl.euclwi.sbcglobal.net 75.34.43.151 adsl-75-34-43-151.dsl.chcgil.sbcglobal.net 76.202.135.216 adsl-76-202-135-216.dsl.lgvwtx.sbcglobal.net 76.235.235.3 adsl-76-235-235-3.dsl.applwi.sbcglobal.net 99.24.30.126 adsl-99-24-30-126.dsl.skt2ca.sbcglobal.net 99.36.221.54 adsl-99-36-221-54.dsl.irvnca.sbcglobal.net 99.56.22.38 adsl-99-56-22-38.dsl.hstntx.sbcglobal.net 99.64.223.246 adsl-99-64-223-246.dsl.stl2mo.sbcglobal.net 99.111.46.195 adsl-99-111-46-195.dsl.kntpin.sbcglobal.net 108.193.239.68 adsl-108-193-239-68.dsl.sndg02.sbcglobal.net 108.210.134.70 adsl-108-210-134-70.dsl.wlfrct.sbcglobal.net And Cox customers: 68.15.172.92 wsip-68-15-172-92.no.no.cox.net 70.165.70.251 wsip-70-165-70-251.hr.hr.cox.net 70.168.33.228 wsip-70-168-33-228.om.om.cox.net 70.168.192.44 wsip-70-168-192-44.br.br.cox.net 72.214.51.94 wsip-72-214-51-94.hr.hr.cox.net 72.215.158.10 wsip-72-215-158-10.hr.hr.cox.net 184.180.176.180 wsip-184-180-176-180.ks.ks.cox.net 184.186.211.103 wsip-184-186-211-103.ok.ok.cox.net And...well, you get the point. ---rsk From clayton at mnsi.net Sun Mar 1 13:08:27 2015 From: clayton at mnsi.net (Clayton Zekelman) Date: Sun, 1 Mar 2015 08:08:27 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <21746.34640.36061.415267@world.std.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <82748B6A-D6D7-4963-A749-47EF4D94DD8D@mnsi.net> <21746.34640.36061.415267@world.std.com> Message-ID: <32D3C16D-0F4D-45BA-99F8-D41FE23D472C@mnsi.net> Yes, so when cable modems were introduced to the network, they had to be designed to work on the EXISTING infrastructure which was designed to deliver cable TV. It's not some conspiracy to differentiate higher priced business services - it was a fact of RF technology and the architecture of the network they were overlaying this "new" service on top of. Sent from my iPhone > On Feb 28, 2015, at 10:28 PM, Barry Shein wrote: > > >> On February 28, 2015 at 18:14 clayton at mnsi.net (Clayton Zekelman) wrote: >> You do of course realize that the asymmetry in CATV forward path/return path existed LONG before residential Internet access over cable networks exited? > > You mean back when it was all analog and DOCSIS didn't exist? > >> >> Sent from my iPhone >> >>> On Feb 28, 2015, at 5:38 PM, Barry Shein wrote: >>> >>> >>> Can we stop the disingenuity? >>> >>> Asymmetric service was introduced to discourage home users from >>> deploying "commercial" services. As were bandwidth caps. >>> >>> One can argue all sorts of other "benefits" of this but when this >>> started that was the problem on the table: How do we forcibly >>> distinguish commercial (i.e., more expensive) from non-commercial >>> usage? >>> >>> Answer: Give them a lot less upload than download bandwidth. >>> >>> Originally these asymmetric, typically DSL, links were hundreds of >>> kbits upstream, not a lot more than a dial-up line. >>> >>> That and NAT thereby making it difficult -- not impossible, the savvy >>> were in the noise -- to map domain names to permanent IP addresses. >>> >>> That's all this was about. >>> >>> It's not about "that's all they need", "that's all they want", etc. >>> >>> Now that bandwidth is growing rapidly and asymmetric is often >>> 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire >>> medium-sized ISPs ran on less than 10mbps symmetric not long ago. But >>> it still imposes an upper bound of sorts, along with addressing >>> limitations and bandwidth caps. >>> >>> That's all this is about. >>> >>> The telcos for many decades distinguished "business" voice service >>> from "residential" service, even for just one phone line, though they >>> mostly just winged it and if they declared you were defrauding them by >>> using a residential line for a business they might shut you off and/or >>> back bill you. Residential was quite a bit cheaper, most importantly >>> local "unlimited" (unmetered) talk was only available on residential >>> lines. Business lines were even coded 1MB (one m b) service, one >>> metered business (line). >>> >>> The history is clear and they've just reinvented the model for >>> internet but proactively enforced by technology rather than studying >>> your usage patterns or whatever they used to do, scan for business ads >>> using "residential" numbers, beyond bandwidth usage analysis. >>> >>> And the CATV companies are trying to reinvent CATV pricing for >>> internet, turn Netflix (e.g.) into an analogue of HBO and other >>> premium CATV services. >>> >>> What's so difficult to understand here? >>> >>> -- >>> -Barry Shein >>> >>> The World | bzs at TheWorld.com | http://www.TheWorld.com >>> Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada >>> Software Tool & Die | Public Access Internet | SINCE 1989 *oo* > > -- > -Barry Shein > > The World | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From mfidelman at meetinghouse.net Sun Mar 1 14:10:06 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sun, 01 Mar 2015 09:10:06 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> Message-ID: <54F31DBE.9060603@meetinghouse.net> Aled Morris wrote: > > Sadly we don't have many "killer applications" for symmetric residential > bandwidth, but that's likely because we don't have the infrastructure to > incubate these applications. > Come to think of it, if USENET software wasn't so cumbersome, I kind of wonder if today's "social network" would consist of home servers running NNTP - and I expect the traffic would be very symmetric. (For that matter, with a few tweaks, the USENET model would be great for "groupware" - anybody remember the Netscape communications server that added private newsgroups and authentication to the mix?) Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From khelms at zcorum.com Sun Mar 1 15:14:07 2015 From: khelms at zcorum.com (Scott Helms) Date: Sun, 1 Mar 2015 10:14:07 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F31DBE.9060603@meetinghouse.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> <54F31DBE.9060603@meetinghouse.net> Message-ID: Anything based on NNTP would be extremely asymmetric without significant changes to the protocol or human behavior. We ran significant Usenet servers with binaries for nearly 20 years and without for another 5 and the servers' traffic was heavily asymmetric. On Mar 1, 2015 9:11 AM, "Miles Fidelman" wrote: > Aled Morris wrote: > > >> Sadly we don't have many "killer applications" for symmetric residential >> bandwidth, but that's likely because we don't have the infrastructure to >> incubate these applications. >> >> > Come to think of it, if USENET software wasn't so cumbersome, I kind of > wonder if today's "social network" would consist of home servers running > NNTP - and I expect the traffic would be very symmetric. (For that matter, > with a few tweaks, the USENET model would be great for "groupware" - > anybody remember the Netscape communications server that added private > newsgroups and authentication to the mix?) > > Miles Fidelman > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > From mfidelman at meetinghouse.net Sun Mar 1 15:24:10 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sun, 01 Mar 2015 10:24:10 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> <54F31DBE.9060603@meetinghouse.net> Message-ID: <54F32F1A.9090201@meetinghouse.net> Scott, Asymmetric measured where? Between client and server or between servers? I'm thinking the case where we each have a server running locally - how do you get a high level of asymmetry in a P2P environment? Miles Fidelman Scott Helms wrote: > > Anything based on NNTP would be extremely asymmetric without > significant changes to the protocol or human behavior. > > We ran significant Usenet servers with binaries for nearly 20 years > and without for another 5 and the servers' traffic was heavily asymmetric. > > On Mar 1, 2015 9:11 AM, "Miles Fidelman" > wrote: > > Aled Morris wrote: > > > Sadly we don't have many "killer applications" for symmetric > residential > bandwidth, but that's likely because we don't have the > infrastructure to > incubate these applications. > > > Come to think of it, if USENET software wasn't so cumbersome, I > kind of wonder if today's "social network" would consist of home > servers running NNTP - and I expect the traffic would be very > symmetric. (For that matter, with a few tweaks, the USENET model > would be great for "groupware" - anybody remember the Netscape > communications server that added private newsgroups and > authentication to the mix?) > > Miles Fidelman > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From khelms at zcorum.com Sun Mar 1 15:37:56 2015 From: khelms at zcorum.com (Scott Helms) Date: Sun, 1 Mar 2015 10:37:56 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F32F1A.9090201@meetinghouse.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> <54F31DBE.9060603@meetinghouse.net> <54F32F1A.9090201@meetinghouse.net> Message-ID: Miles, Usenet was normally asymmetrical between servers, even when server operators try to seed equally as being fed. It's a function of how a few servers are the source original content and how long individual servers choose (and have the disk) to keep specific content. It was never designed to have as many server nodes as you're describing and I'd imagine there's some nasty side effects if we tried get that many active servers going as we have customers. On Mar 1, 2015 10:25 AM, "Miles Fidelman" wrote: > Scott, > > Asymmetric measured where? Between client and server or between servers? > I'm thinking the case where we each have a server running locally - how do > you get a high level of asymmetry in a P2P environment? > > Miles Fidelman > > > > Scott Helms wrote: > >> >> Anything based on NNTP would be extremely asymmetric without significant >> changes to the protocol or human behavior. >> >> We ran significant Usenet servers with binaries for nearly 20 years and >> without for another 5 and the servers' traffic was heavily asymmetric. >> >> On Mar 1, 2015 9:11 AM, "Miles Fidelman" > > wrote: >> >> Aled Morris wrote: >> >> >> Sadly we don't have many "killer applications" for symmetric >> residential >> bandwidth, but that's likely because we don't have the >> infrastructure to >> incubate these applications. >> >> >> Come to think of it, if USENET software wasn't so cumbersome, I >> kind of wonder if today's "social network" would consist of home >> servers running NNTP - and I expect the traffic would be very >> symmetric. (For that matter, with a few tweaks, the USENET model >> would be great for "groupware" - anybody remember the Netscape >> communications server that added private newsgroups and >> authentication to the mix?) >> >> Miles Fidelman >> >> >> >> -- In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> >> > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > From mike at mtcc.com Sun Mar 1 15:51:43 2015 From: mike at mtcc.com (Michael Thomas) Date: Sun, 01 Mar 2015 07:51:43 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <12510710.909.1425165605520.JavaMail.mhammett@ThunderFuck> <6B8B9E2F-7833-492D-BBA8-F5B75C69D5B3@mnsi.net> <54F259EB.1090302@mtcc.com> Message-ID: <54F3358F.7060002@mtcc.com> On 02/28/2015 06:38 PM, Scott Helms wrote: > > You're off on this. When PacketCable 1.0 was in development and it's > early deployment there were no OTT VOIP providers of note. Vonage at > that time was trying sell their services to the MSOs and only when > that didn't work or did they start going directly to consumers via SIP. > > The prioritization mechanisms in PacketCable exist because the thought > was that they were needed to compete with POTS and that's it and at > that time, when upstreams were more contended that was probably the case. > It was both. They wanted to compete with pots *and* they wanted to have something that nobody else (= oot) could compete with. The entire exercise was trying to bring the old telco billing model into the cable world, hence all of the DOCSIS QoS, RSVP, etc, etc. Mike > On Feb 28, 2015 7:15 PM, "Michael Thomas" > wrote: > > > On 02/28/2015 03:35 PM, Clayton Zekelman wrote: > > And for historical reasons. The forward path started at TV > channel 2. The return path was shoe horned in to the > frequencies below that, which limited the amount of available > spectrum for return path. > > Originally this didn't matter much because the only thing it > was used for was set top box communications and occasionally > sending video to the head end for community channel remote feeds. > > To change the split would require replacement of all the > active and passive RF equipment in the network. > > Only now with he widespread conversion to digital cable are > they able to free up enough spectrum to even consider moving > the split at some point in the future. > > > Something else to keep in mind, is that the cable companies wanted > to use the > upstream for voice using DOCSIS QoS to create a big advantage over > anybody > else who might want to just do voice over the top. > > There was lots of talk about business advantage, evil home > servers, etc, etc > and no care at all about legitimate uses for customer upstream. If > they wanted > to shape DOCSIS to have better upstream, all they had to say is > "JUMP" to cablelabs > and the vendors and it would have happened. > > Mike > > > Sent from my iPhone > > On Feb 28, 2015, at 6:20 PM, Mike Hammett > > wrote: > > As I said earlier, there are only so many channels > available. Channels added to upload are taken away from > download. People use upload so infrequently it would be > gross negligence on the provider's behalf. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Clayton Zekelman" > > To: "Barry Shein" > > Cc: "NANOG" > > Sent: Saturday, February 28, 2015 5:14:18 PM > Subject: Re: Verizon Policy Statement on Net Neutrality > > You do of course realize that the asymmetry in CATV > forward path/return path existed LONG before residential > Internet access over cable networks exited? > > Sent from my iPhone > > On Feb 28, 2015, at 5:38 PM, Barry Shein > > wrote: > > > Can we stop the disingenuity? > > Asymmetric service was introduced to discourage home > users from > deploying "commercial" services. As were bandwidth caps. > > One can argue all sorts of other "benefits" of this > but when this > started that was the problem on the table: How do we > forcibly > distinguish commercial (i.e., more expensive) from > non-commercial > usage? > > Answer: Give them a lot less upload than download > bandwidth. > > Originally these asymmetric, typically DSL, links were > hundreds of > kbits upstream, not a lot more than a dial-up line. > > That and NAT thereby making it difficult -- not > impossible, the savvy > were in the noise -- to map domain names to permanent > IP addresses. > > That's all this was about. > > It's not about "that's all they need", "that's all > they want", etc. > > Now that bandwidth is growing rapidly and asymmetric > is often > 10/50mbps or 20/100 it almost seems nonsensical in > that regard, entire > medium-sized ISPs ran on less than 10mbps symmetric > not long ago. But > it still imposes an upper bound of sorts, along with > addressing > limitations and bandwidth caps. > > That's all this is about. > > The telcos for many decades distinguished "business" > voice service > from "residential" service, even for just one phone > line, though they > mostly just winged it and if they declared you were > defrauding them by > using a residential line for a business they might > shut you off and/or > back bill you. Residential was quite a bit cheaper, > most importantly > local "unlimited" (unmetered) talk was only available > on residential > lines. Business lines were even coded 1MB (one m b) > service, one > metered business (line). > > The history is clear and they've just reinvented the > model for > internet but proactively enforced by technology rather > than studying > your usage patterns or whatever they used to do, scan > for business ads > using "residential" numbers, beyond bandwidth usage > analysis. > > And the CATV companies are trying to reinvent CATV > pricing for > internet, turn Netflix (e.g.) into an analogue of HBO > and other > premium CATV services. > > What's so difficult to understand here? > > -- > -Barry Shein > > The World | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | > Dial-Up: US, PR, Canada > Software Tool & Die | Public Access Internet | SINCE > 1989 *oo* > > From khelms at zcorum.com Sun Mar 1 15:55:53 2015 From: khelms at zcorum.com (Scott Helms) Date: Sun, 1 Mar 2015 10:55:53 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F3358F.7060002@mtcc.com> References: <12510710.909.1425165605520.JavaMail.mhammett@ThunderFuck> <6B8B9E2F-7833-492D-BBA8-F5B75C69D5B3@mnsi.net> <54F259EB.1090302@mtcc.com> <54F3358F.7060002@mtcc.com> Message-ID: Michael, Exactly what are you basing that on? Like I said, none of the MSOs or vendors involved in the protocol development had any concerns about OTT. The reason the built QoS was because the networks weren't good enough for OTT On Mar 1, 2015 10:51 AM, "Michael Thomas" wrote: > > On 02/28/2015 06:38 PM, Scott Helms wrote: > > You're off on this. When PacketCable 1.0 was in development and it's > early deployment there were no OTT VOIP providers of note. Vonage at that > time was trying sell their services to the MSOs and only when that didn't > work or did they start going directly to consumers via SIP. > > The prioritization mechanisms in PacketCable exist because the thought was > that they were needed to compete with POTS and that's it and at that time, > when upstreams were more contended that was probably the case. > > > It was both. They wanted to compete with pots *and* they wanted to have > something > that nobody else (= oot) could compete with. The entire exercise was > trying to bring the old > telco billing model into the cable world, hence all of the DOCSIS QoS, > RSVP, etc, etc. > > Mike > > On Feb 28, 2015 7:15 PM, "Michael Thomas" wrote: > >> >> On 02/28/2015 03:35 PM, Clayton Zekelman wrote: >> >>> And for historical reasons. The forward path started at TV channel 2. >>> The return path was shoe horned in to the frequencies below that, which >>> limited the amount of available spectrum for return path. >>> >>> Originally this didn't matter much because the only thing it was used >>> for was set top box communications and occasionally sending video to the >>> head end for community channel remote feeds. >>> >>> To change the split would require replacement of all the active and >>> passive RF equipment in the network. >>> >>> Only now with he widespread conversion to digital cable are they able to >>> free up enough spectrum to even consider moving the split at some point in >>> the future. >>> >> >> Something else to keep in mind, is that the cable companies wanted to use >> the >> upstream for voice using DOCSIS QoS to create a big advantage over anybody >> else who might want to just do voice over the top. >> >> There was lots of talk about business advantage, evil home servers, etc, >> etc >> and no care at all about legitimate uses for customer upstream. If they >> wanted >> to shape DOCSIS to have better upstream, all they had to say is "JUMP" to >> cablelabs >> and the vendors and it would have happened. >> >> Mike >> >> >>> Sent from my iPhone >>> >>> On Feb 28, 2015, at 6:20 PM, Mike Hammett wrote: >>>> >>>> As I said earlier, there are only so many channels available. Channels >>>> added to upload are taken away from download. People use upload so >>>> infrequently it would be gross negligence on the provider's behalf. >>>> >>>> >>>> >>>> >>>> ----- >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> http://www.ics-il.com >>>> >>>> ----- Original Message ----- >>>> >>>> From: "Clayton Zekelman" >>>> To: "Barry Shein" >>>> Cc: "NANOG" >>>> Sent: Saturday, February 28, 2015 5:14:18 PM >>>> Subject: Re: Verizon Policy Statement on Net Neutrality >>>> >>>> You do of course realize that the asymmetry in CATV forward path/return >>>> path existed LONG before residential Internet access over cable networks >>>> exited? >>>> >>>> Sent from my iPhone >>>> >>>> On Feb 28, 2015, at 5:38 PM, Barry Shein wrote: >>>>> >>>>> >>>>> Can we stop the disingenuity? >>>>> >>>>> Asymmetric service was introduced to discourage home users from >>>>> deploying "commercial" services. As were bandwidth caps. >>>>> >>>>> One can argue all sorts of other "benefits" of this but when this >>>>> started that was the problem on the table: How do we forcibly >>>>> distinguish commercial (i.e., more expensive) from non-commercial >>>>> usage? >>>>> >>>>> Answer: Give them a lot less upload than download bandwidth. >>>>> >>>>> Originally these asymmetric, typically DSL, links were hundreds of >>>>> kbits upstream, not a lot more than a dial-up line. >>>>> >>>>> That and NAT thereby making it difficult -- not impossible, the savvy >>>>> were in the noise -- to map domain names to permanent IP addresses. >>>>> >>>>> That's all this was about. >>>>> >>>>> It's not about "that's all they need", "that's all they want", etc. >>>>> >>>>> Now that bandwidth is growing rapidly and asymmetric is often >>>>> 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire >>>>> medium-sized ISPs ran on less than 10mbps symmetric not long ago. But >>>>> it still imposes an upper bound of sorts, along with addressing >>>>> limitations and bandwidth caps. >>>>> >>>>> That's all this is about. >>>>> >>>>> The telcos for many decades distinguished "business" voice service >>>>> from "residential" service, even for just one phone line, though they >>>>> mostly just winged it and if they declared you were defrauding them by >>>>> using a residential line for a business they might shut you off and/or >>>>> back bill you. Residential was quite a bit cheaper, most importantly >>>>> local "unlimited" (unmetered) talk was only available on residential >>>>> lines. Business lines were even coded 1MB (one m b) service, one >>>>> metered business (line). >>>>> >>>>> The history is clear and they've just reinvented the model for >>>>> internet but proactively enforced by technology rather than studying >>>>> your usage patterns or whatever they used to do, scan for business ads >>>>> using "residential" numbers, beyond bandwidth usage analysis. >>>>> >>>>> And the CATV companies are trying to reinvent CATV pricing for >>>>> internet, turn Netflix (e.g.) into an analogue of HBO and other >>>>> premium CATV services. >>>>> >>>>> What's so difficult to understand here? >>>>> >>>>> -- >>>>> -Barry Shein >>>>> >>>>> The World | bzs at TheWorld.com | http://www.TheWorld.com >>>>> Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada >>>>> Software Tool & Die | Public Access Internet | SINCE 1989 *oo* >>>>> >>>> >> > From mike at mtcc.com Sun Mar 1 16:01:19 2015 From: mike at mtcc.com (Michael Thomas) Date: Sun, 01 Mar 2015 08:01:19 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <32D3C16D-0F4D-45BA-99F8-D41FE23D472C@mnsi.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <82748B6A-D6D7-4963-A749-47EF4D94DD8D@mnsi.net> <21746.34640.36061.415267@world.std.com> <32D3C16D-0F4D-45BA-99F8-D41FE23D472C@mnsi.net> Message-ID: <54F337CF.4020304@mtcc.com> On 03/01/2015 05:08 AM, Clayton Zekelman wrote: > Yes, so when cable modems were introduced to the network, they had to be designed to work on the EXISTING infrastructure which was designed to deliver cable TV. It's not some conspiracy to differentiate higher priced business services - it was a fact of RF technology and the architecture of the network they were overlaying this "new" service on top of. > > They didn't want to give channels for internet bandwidth either. Life would have been *far* more simple had the MSO's not *forced* the hardware designer to use their crappy noisy back channel, such as it was. The move from analog -- which was happening around the same time -- pretty much negated that reason, but by then they had a bunch more reasons why they thought slow upstream was great for business. Mike From mike at mtcc.com Sun Mar 1 16:04:22 2015 From: mike at mtcc.com (Michael Thomas) Date: Sun, 01 Mar 2015 08:04:22 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <82748B6A-D6D7-4963-A749-47EF4D94DD8D@mnsi.net> <54F24E5C.1000407@mtcc.com> Message-ID: <54F33886.1060504@mtcc.com> On 02/28/2015 06:15 PM, Scott Helms wrote: > > Michael, > > You should really learn how DOCSIS systems work. What you're trying to > claim it's not only untrue it is that way for very real technical > reasons. > I'm well aware. I was there. Mike > On Feb 28, 2015 6:27 PM, "Michael Thomas" > wrote: > > > On 02/28/2015 03:14 PM, Clayton Zekelman wrote: > > You do of course realize that the asymmetry in CATV forward > path/return path existed LONG before residential Internet > access over cable networks exited? > > > The cable companies didn't want "servers" on residential customers > either, and were > animated by that. Cable didn't really have much of a return path > at all at first -- I remember > the stories of the crappy spectrum they were willing to allocate > at first, but as I recall > that was mainly because they hadn't transitioned to digital > downstream and their analog > down was pretty precious. Once they made that transition, the > animus against residential > "servers" was pretty much the only excuse -- I'm pretty sure they > could map up/down/cable > channels any way they wanted after that. > > Mike > > > Sent from my iPhone > > On Feb 28, 2015, at 5:38 PM, Barry Shein > > wrote: > > > Can we stop the disingenuity? > > Asymmetric service was introduced to discourage home users > from > deploying "commercial" services. As were bandwidth caps. > > One can argue all sorts of other "benefits" of this but > when this > started that was the problem on the table: How do we forcibly > distinguish commercial (i.e., more expensive) from > non-commercial > usage? > > Answer: Give them a lot less upload than download bandwidth. > > Originally these asymmetric, typically DSL, links were > hundreds of > kbits upstream, not a lot more than a dial-up line. > > That and NAT thereby making it difficult -- not > impossible, the savvy > were in the noise -- to map domain names to permanent IP > addresses. > > That's all this was about. > > It's not about "that's all they need", "that's all they > want", etc. > > Now that bandwidth is growing rapidly and asymmetric is often > 10/50mbps or 20/100 it almost seems nonsensical in that > regard, entire > medium-sized ISPs ran on less than 10mbps symmetric not > long ago. But > it still imposes an upper bound of sorts, along with > addressing > limitations and bandwidth caps. > > That's all this is about. > > The telcos for many decades distinguished "business" voice > service > from "residential" service, even for just one phone line, > though they > mostly just winged it and if they declared you were > defrauding them by > using a residential line for a business they might shut > you off and/or > back bill you. Residential was quite a bit cheaper, most > importantly > local "unlimited" (unmetered) talk was only available on > residential > lines. Business lines were even coded 1MB (one m b) > service, one > metered business (line). > > The history is clear and they've just reinvented the model for > internet but proactively enforced by technology rather > than studying > your usage patterns or whatever they used to do, scan for > business ads > using "residential" numbers, beyond bandwidth usage analysis. > > And the CATV companies are trying to reinvent CATV pricing for > internet, turn Netflix (e.g.) into an analogue of HBO and > other > premium CATV services. > > What's so difficult to understand here? > > -- > -Barry Shein > > The World | bzs at TheWorld.com | > http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | > Dial-Up: US, PR, Canada > Software Tool & Die | Public Access Internet | > SINCE 1989 *oo* > > From mike at mtcc.com Sun Mar 1 16:11:11 2015 From: mike at mtcc.com (Michael Thomas) Date: Sun, 01 Mar 2015 08:11:11 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <12510710.909.1425165605520.JavaMail.mhammett@ThunderFuck> <6B8B9E2F-7833-492D-BBA8-F5B75C69D5B3@mnsi.net> <54F259EB.1090302@mtcc.com> <54F3358F.7060002@mtcc.com> Message-ID: <54F33A1F.6060602@mtcc.com> On 03/01/2015 07:55 AM, Scott Helms wrote: > > Michael, > > Exactly what are you basing that on? Like I said, none of the MSOs or > vendors involved in the protocol development had any concerns about > OTT. The reason the built QoS was because the networks weren't good > enough for OTT > Being at Packetcable at the time? Mike > On Mar 1, 2015 10:51 AM, "Michael Thomas" > wrote: > > > On 02/28/2015 06:38 PM, Scott Helms wrote: >> >> You're off on this. When PacketCable 1.0 was in development and >> it's early deployment there were no OTT VOIP providers of note. >> Vonage at that time was trying sell their services to the MSOs >> and only when that didn't work or did they start going directly >> to consumers via SIP. >> >> The prioritization mechanisms in PacketCable exist because the >> thought was that they were needed to compete with POTS and that's >> it and at that time, when upstreams were more contended that was >> probably the case. >> > > It was both. They wanted to compete with pots *and* they wanted to > have something > that nobody else (= oot) could compete with. The entire exercise > was trying to bring the old > telco billing model into the cable world, hence all of the DOCSIS > QoS, RSVP, etc, etc. > > Mike > >> On Feb 28, 2015 7:15 PM, "Michael Thomas" > > wrote: >> >> >> On 02/28/2015 03:35 PM, Clayton Zekelman wrote: >> >> And for historical reasons. The forward path started at >> TV channel 2. The return path was shoe horned in to the >> frequencies below that, which limited the amount of >> available spectrum for return path. >> >> Originally this didn't matter much because the only thing >> it was used for was set top box communications and >> occasionally sending video to the head end for community >> channel remote feeds. >> >> To change the split would require replacement of all the >> active and passive RF equipment in the network. >> >> Only now with he widespread conversion to digital cable >> are they able to free up enough spectrum to even consider >> moving the split at some point in the future. >> >> >> Something else to keep in mind, is that the cable companies >> wanted to use the >> upstream for voice using DOCSIS QoS to create a big advantage >> over anybody >> else who might want to just do voice over the top. >> >> There was lots of talk about business advantage, evil home >> servers, etc, etc >> and no care at all about legitimate uses for customer >> upstream. If they wanted >> to shape DOCSIS to have better upstream, all they had to say >> is "JUMP" to cablelabs >> and the vendors and it would have happened. >> >> Mike >> >> >> Sent from my iPhone >> >> On Feb 28, 2015, at 6:20 PM, Mike Hammett >> > wrote: >> >> As I said earlier, there are only so many channels >> available. Channels added to upload are taken away >> from download. People use upload so infrequently it >> would be gross negligence on the provider's behalf. >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> ----- Original Message ----- >> >> From: "Clayton Zekelman" > > >> To: "Barry Shein" > > >> Cc: "NANOG" > >> Sent: Saturday, February 28, 2015 5:14:18 PM >> Subject: Re: Verizon Policy Statement on Net Neutrality >> >> You do of course realize that the asymmetry in CATV >> forward path/return path existed LONG before >> residential Internet access over cable networks exited? >> >> Sent from my iPhone >> >> On Feb 28, 2015, at 5:38 PM, Barry Shein >> > wrote: >> >> >> Can we stop the disingenuity? >> >> Asymmetric service was introduced to discourage >> home users from >> deploying "commercial" services. As were >> bandwidth caps. >> >> One can argue all sorts of other "benefits" of >> this but when this >> started that was the problem on the table: How do >> we forcibly >> distinguish commercial (i.e., more expensive) >> from non-commercial >> usage? >> >> Answer: Give them a lot less upload than download >> bandwidth. >> >> Originally these asymmetric, typically DSL, links >> were hundreds of >> kbits upstream, not a lot more than a dial-up line. >> >> That and NAT thereby making it difficult -- not >> impossible, the savvy >> were in the noise -- to map domain names to >> permanent IP addresses. >> >> That's all this was about. >> >> It's not about "that's all they need", "that's >> all they want", etc. >> >> Now that bandwidth is growing rapidly and >> asymmetric is often >> 10/50mbps or 20/100 it almost seems nonsensical >> in that regard, entire >> medium-sized ISPs ran on less than 10mbps >> symmetric not long ago. But >> it still imposes an upper bound of sorts, along >> with addressing >> limitations and bandwidth caps. >> >> That's all this is about. >> >> The telcos for many decades distinguished >> "business" voice service >> from "residential" service, even for just one >> phone line, though they >> mostly just winged it and if they declared you >> were defrauding them by >> using a residential line for a business they >> might shut you off and/or >> back bill you. Residential was quite a bit >> cheaper, most importantly >> local "unlimited" (unmetered) talk was only >> available on residential >> lines. Business lines were even coded 1MB (one m >> b) service, one >> metered business (line). >> >> The history is clear and they've just reinvented >> the model for >> internet but proactively enforced by technology >> rather than studying >> your usage patterns or whatever they used to do, >> scan for business ads >> using "residential" numbers, beyond bandwidth >> usage analysis. >> >> And the CATV companies are trying to reinvent >> CATV pricing for >> internet, turn Netflix (e.g.) into an analogue of >> HBO and other >> premium CATV services. >> >> What's so difficult to understand here? >> >> -- >> -Barry Shein >> >> The World | bzs at TheWorld.com >> | http://www.TheWorld.com >> Purveyors to the Trade | Voice: 800-THE-WRLD | >> Dial-Up: US, PR, Canada >> Software Tool & Die | Public Access Internet | >> SINCE 1989 *oo* >> >> > From nick at foobar.org Sun Mar 1 16:13:41 2015 From: nick at foobar.org (Nick Hilliard) Date: Sun, 01 Mar 2015 16:13:41 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <21746.35420.759630.472893@world.std.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> Message-ID: <54F33AB5.3040208@foobar.org> On 01/03/2015 03:41, Barry Shein wrote: > On February 28, 2015 at 23:20 nick at foobar.org (Nick Hilliard) wrote: > > there were several reasons for asymmetric services, one of which was > > commercial. Another was that most users' bandwidth profiles were massively > > asymmetric to start with so it made sense for consumers to have more > > bandwidth in one direction than another. > > How could they have known this before it was introduced? because we had modem banks before we had adsl. > I say that was prescriptive and a best guess that it'd be acceptable > and a way to differentiate commercial from residential > service. Previously all residential service (e.g., dial-up, ISDN) was > symmetrical. Maybe they had some data on that usage but it'd be muddy > just due to the low bandwidth they provided. maybe it was symmetric on your modems; it wasn't on the modems I managed. > Another still was that cross-talk > > causes enough interference to prevent reverse adsl (i.e. greater bandwidth > > from customer to exchange) from working well. > > So SDSL didn't exist? SDSL generally maxes out at 2mbit/s and can be run near adsl without causing problems, but that's not what I was talking about. If you were to run a 24:1 adsl service with the dslam at the customer side, it will cause cross-talk problems at the exchange end and that would trash bandwidth for other adsl users in the exchange->customer direction. > Anyhow, *DSL is falling so far behind it's > difficult to analyze what could have been. not really no. Spectral analysis is clear on efficiency measurement - we know the upper limits on spectral efficiency due to Shannon's law. > > > As were bandwidth caps. > > > > Bandwidth caps were introduced in many cases to stop gratuitous abuse of > > service by the 1% of users who persistently ran their links at a rate that > > the pricing model they selected was not designed to handle. You've been > > around the block a bit so I'm sure you remember the days when transit was > > expensive and a major cost factor in running an isp. > > It was the combination of asymmetric, no or few IPs (and NAT), and > bandwidth caps. let's not rewrite history here: IPv4 address scarcity has been a thing since the very early 1990s. Otherwise why would cidr have been created? > Sure. once it became institutionalized and the market got used to it > why not sell tiered bandwidth services at different price points, but > that could have been true of symmetrical service also. my point is simply that there is often more to asymmetric services than extracting more money from the customer. Nick From khelms at zcorum.com Sun Mar 1 16:19:16 2015 From: khelms at zcorum.com (Scott Helms) Date: Sun, 1 Mar 2015 11:19:16 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F33886.1060504@mtcc.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <82748B6A-D6D7-4963-A749-47EF4D94DD8D@mnsi.net> <54F24E5C.1000407@mtcc.com> <54F33886.1060504@mtcc.com> Message-ID: Michael, Then you understand that having the upstreams and downstreams use the same frequencies, especially in a flexible manner, would require completely redesigning every diplex filter, amplifier, fiber node, and tap filters in the plant. At the same time we'd have to replace all of the modems, set top boxes, TV tuners embedded in TV sets, CableCards, and CMTS blades. We'd also have to change the protocol in significant ways. Deal with many more, and more complicated, ingress and egress problems. We'd also create FEX and NEX problems that we don't have today. On Mar 1, 2015 11:04 AM, "Michael Thomas" wrote: > > On 02/28/2015 06:15 PM, Scott Helms wrote: > > Michael, > > You should really learn how DOCSIS systems work. What you're trying to > claim it's not only untrue it is that way for very real technical reasons. > > > I'm well aware. I was there. > > Mike > > On Feb 28, 2015 6:27 PM, "Michael Thomas" wrote: > >> >> On 02/28/2015 03:14 PM, Clayton Zekelman wrote: >> >>> You do of course realize that the asymmetry in CATV forward path/return >>> path existed LONG before residential Internet access over cable networks >>> exited? >>> >> >> The cable companies didn't want "servers" on residential customers >> either, and were >> animated by that. Cable didn't really have much of a return path at all >> at first -- I remember >> the stories of the crappy spectrum they were willing to allocate at >> first, but as I recall >> that was mainly because they hadn't transitioned to digital downstream >> and their analog >> down was pretty precious. Once they made that transition, the animus >> against residential >> "servers" was pretty much the only excuse -- I'm pretty sure they could >> map up/down/cable >> channels any way they wanted after that. >> >> Mike >> >> >>> Sent from my iPhone >>> >>> On Feb 28, 2015, at 5:38 PM, Barry Shein wrote: >>>> >>>> >>>> Can we stop the disingenuity? >>>> >>>> Asymmetric service was introduced to discourage home users from >>>> deploying "commercial" services. As were bandwidth caps. >>>> >>>> One can argue all sorts of other "benefits" of this but when this >>>> started that was the problem on the table: How do we forcibly >>>> distinguish commercial (i.e., more expensive) from non-commercial >>>> usage? >>>> >>>> Answer: Give them a lot less upload than download bandwidth. >>>> >>>> Originally these asymmetric, typically DSL, links were hundreds of >>>> kbits upstream, not a lot more than a dial-up line. >>>> >>>> That and NAT thereby making it difficult -- not impossible, the savvy >>>> were in the noise -- to map domain names to permanent IP addresses. >>>> >>>> That's all this was about. >>>> >>>> It's not about "that's all they need", "that's all they want", etc. >>>> >>>> Now that bandwidth is growing rapidly and asymmetric is often >>>> 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire >>>> medium-sized ISPs ran on less than 10mbps symmetric not long ago. But >>>> it still imposes an upper bound of sorts, along with addressing >>>> limitations and bandwidth caps. >>>> >>>> That's all this is about. >>>> >>>> The telcos for many decades distinguished "business" voice service >>>> from "residential" service, even for just one phone line, though they >>>> mostly just winged it and if they declared you were defrauding them by >>>> using a residential line for a business they might shut you off and/or >>>> back bill you. Residential was quite a bit cheaper, most importantly >>>> local "unlimited" (unmetered) talk was only available on residential >>>> lines. Business lines were even coded 1MB (one m b) service, one >>>> metered business (line). >>>> >>>> The history is clear and they've just reinvented the model for >>>> internet but proactively enforced by technology rather than studying >>>> your usage patterns or whatever they used to do, scan for business ads >>>> using "residential" numbers, beyond bandwidth usage analysis. >>>> >>>> And the CATV companies are trying to reinvent CATV pricing for >>>> internet, turn Netflix (e.g.) into an analogue of HBO and other >>>> premium CATV services. >>>> >>>> What's so difficult to understand here? >>>> >>>> -- >>>> -Barry Shein >>>> >>>> The World | bzs at TheWorld.com | >>>> http://www.TheWorld.com >>>> Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, >>>> Canada >>>> Software Tool & Die | Public Access Internet | SINCE 1989 >>>> *oo* >>>> >>> >> > From khelms at zcorum.com Sun Mar 1 16:19:53 2015 From: khelms at zcorum.com (Scott Helms) Date: Sun, 1 Mar 2015 11:19:53 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F33A1F.6060602@mtcc.com> References: <12510710.909.1425165605520.JavaMail.mhammett@ThunderFuck> <6B8B9E2F-7833-492D-BBA8-F5B75C69D5B3@mnsi.net> <54F259EB.1090302@mtcc.com> <54F3358F.7060002@mtcc.com> <54F33A1F.6060602@mtcc.com> Message-ID: You mean CableLabs? On Mar 1, 2015 11:11 AM, "Michael Thomas" wrote: > > On 03/01/2015 07:55 AM, Scott Helms wrote: > > Michael, > > Exactly what are you basing that on? Like I said, none of the MSOs or > vendors involved in the protocol development had any concerns about OTT. > The reason the built QoS was because the networks weren't good enough for > OTT > > > Being at Packetcable at the time? > > Mike > > On Mar 1, 2015 10:51 AM, "Michael Thomas" wrote: > >> >> On 02/28/2015 06:38 PM, Scott Helms wrote: >> >> You're off on this. When PacketCable 1.0 was in development and it's >> early deployment there were no OTT VOIP providers of note. Vonage at that >> time was trying sell their services to the MSOs and only when that didn't >> work or did they start going directly to consumers via SIP. >> >> The prioritization mechanisms in PacketCable exist because the thought >> was that they were needed to compete with POTS and that's it and at that >> time, when upstreams were more contended that was probably the case. >> >> >> It was both. They wanted to compete with pots *and* they wanted to have >> something >> that nobody else (= oot) could compete with. The entire exercise was >> trying to bring the old >> telco billing model into the cable world, hence all of the DOCSIS QoS, >> RSVP, etc, etc. >> >> Mike >> >> On Feb 28, 2015 7:15 PM, "Michael Thomas" wrote: >> >>> >>> On 02/28/2015 03:35 PM, Clayton Zekelman wrote: >>> >>>> And for historical reasons. The forward path started at TV channel 2. >>>> The return path was shoe horned in to the frequencies below that, which >>>> limited the amount of available spectrum for return path. >>>> >>>> Originally this didn't matter much because the only thing it was used >>>> for was set top box communications and occasionally sending video to the >>>> head end for community channel remote feeds. >>>> >>>> To change the split would require replacement of all the active and >>>> passive RF equipment in the network. >>>> >>>> Only now with he widespread conversion to digital cable are they able >>>> to free up enough spectrum to even consider moving the split at some point >>>> in the future. >>>> >>> >>> Something else to keep in mind, is that the cable companies wanted to >>> use the >>> upstream for voice using DOCSIS QoS to create a big advantage over >>> anybody >>> else who might want to just do voice over the top. >>> >>> There was lots of talk about business advantage, evil home servers, etc, >>> etc >>> and no care at all about legitimate uses for customer upstream. If they >>> wanted >>> to shape DOCSIS to have better upstream, all they had to say is "JUMP" >>> to cablelabs >>> and the vendors and it would have happened. >>> >>> Mike >>> >>> >>>> Sent from my iPhone >>>> >>>> On Feb 28, 2015, at 6:20 PM, Mike Hammett wrote: >>>>> >>>>> As I said earlier, there are only so many channels available. Channels >>>>> added to upload are taken away from download. People use upload so >>>>> infrequently it would be gross negligence on the provider's behalf. >>>>> >>>>> >>>>> >>>>> >>>>> ----- >>>>> Mike Hammett >>>>> Intelligent Computing Solutions >>>>> http://www.ics-il.com >>>>> >>>>> ----- Original Message ----- >>>>> >>>>> From: "Clayton Zekelman" >>>>> To: "Barry Shein" >>>>> Cc: "NANOG" >>>>> Sent: Saturday, February 28, 2015 5:14:18 PM >>>>> Subject: Re: Verizon Policy Statement on Net Neutrality >>>>> >>>>> You do of course realize that the asymmetry in CATV forward >>>>> path/return path existed LONG before residential Internet access over cable >>>>> networks exited? >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Feb 28, 2015, at 5:38 PM, Barry Shein wrote: >>>>>> >>>>>> >>>>>> Can we stop the disingenuity? >>>>>> >>>>>> Asymmetric service was introduced to discourage home users from >>>>>> deploying "commercial" services. As were bandwidth caps. >>>>>> >>>>>> One can argue all sorts of other "benefits" of this but when this >>>>>> started that was the problem on the table: How do we forcibly >>>>>> distinguish commercial (i.e., more expensive) from non-commercial >>>>>> usage? >>>>>> >>>>>> Answer: Give them a lot less upload than download bandwidth. >>>>>> >>>>>> Originally these asymmetric, typically DSL, links were hundreds of >>>>>> kbits upstream, not a lot more than a dial-up line. >>>>>> >>>>>> That and NAT thereby making it difficult -- not impossible, the savvy >>>>>> were in the noise -- to map domain names to permanent IP addresses. >>>>>> >>>>>> That's all this was about. >>>>>> >>>>>> It's not about "that's all they need", "that's all they want", etc. >>>>>> >>>>>> Now that bandwidth is growing rapidly and asymmetric is often >>>>>> 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire >>>>>> medium-sized ISPs ran on less than 10mbps symmetric not long ago. But >>>>>> it still imposes an upper bound of sorts, along with addressing >>>>>> limitations and bandwidth caps. >>>>>> >>>>>> That's all this is about. >>>>>> >>>>>> The telcos for many decades distinguished "business" voice service >>>>>> from "residential" service, even for just one phone line, though they >>>>>> mostly just winged it and if they declared you were defrauding them by >>>>>> using a residential line for a business they might shut you off and/or >>>>>> back bill you. Residential was quite a bit cheaper, most importantly >>>>>> local "unlimited" (unmetered) talk was only available on residential >>>>>> lines. Business lines were even coded 1MB (one m b) service, one >>>>>> metered business (line). >>>>>> >>>>>> The history is clear and they've just reinvented the model for >>>>>> internet but proactively enforced by technology rather than studying >>>>>> your usage patterns or whatever they used to do, scan for business ads >>>>>> using "residential" numbers, beyond bandwidth usage analysis. >>>>>> >>>>>> And the CATV companies are trying to reinvent CATV pricing for >>>>>> internet, turn Netflix (e.g.) into an analogue of HBO and other >>>>>> premium CATV services. >>>>>> >>>>>> What's so difficult to understand here? >>>>>> >>>>>> -- >>>>>> -Barry Shein >>>>>> >>>>>> The World | bzs at TheWorld.com | http://www.TheWorld.com >>>>>> Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada >>>>>> Software Tool & Die | Public Access Internet | SINCE 1989 *oo* >>>>>> >>>>> >>> >> > From mike at mtcc.com Sun Mar 1 16:20:31 2015 From: mike at mtcc.com (Michael Thomas) Date: Sun, 01 Mar 2015 08:20:31 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <12510710.909.1425165605520.JavaMail.mhammett@ThunderFuck> <6B8B9E2F-7833-492D-BBA8-F5B75C69D5B3@mnsi.net> <54F259EB.1090302@mtcc.com> <54F3358F.7060002@mtcc.com> <54F33A1F.6060602@mtcc.com> Message-ID: <54F33C4F.4080904@mtcc.com> On 03/01/2015 08:19 AM, Scott Helms wrote: > > You mean CableLabs? > Yes. Mike > On Mar 1, 2015 11:11 AM, "Michael Thomas" > wrote: > > > On 03/01/2015 07:55 AM, Scott Helms wrote: >> >> Michael, >> >> Exactly what are you basing that on? Like I said, none of the >> MSOs or vendors involved in the protocol development had any >> concerns about OTT. The reason the built QoS was because the >> networks weren't good enough for OTT >> > > Being at Packetcable at the time? > > Mike > >> On Mar 1, 2015 10:51 AM, "Michael Thomas" > > wrote: >> >> >> On 02/28/2015 06:38 PM, Scott Helms wrote: >>> >>> You're off on this. When PacketCable 1.0 was in development >>> and it's early deployment there were no OTT VOIP providers >>> of note. Vonage at that time was trying sell their services >>> to the MSOs and only when that didn't work or did they start >>> going directly to consumers via SIP. >>> >>> The prioritization mechanisms in PacketCable exist because >>> the thought was that they were needed to compete with POTS >>> and that's it and at that time, when upstreams were more >>> contended that was probably the case. >>> >> >> It was both. They wanted to compete with pots *and* they >> wanted to have something >> that nobody else (= oot) could compete with. The entire >> exercise was trying to bring the old >> telco billing model into the cable world, hence all of the >> DOCSIS QoS, RSVP, etc, etc. >> >> Mike >> >>> On Feb 28, 2015 7:15 PM, "Michael Thomas" >> > wrote: >>> >>> >>> On 02/28/2015 03:35 PM, Clayton Zekelman wrote: >>> >>> And for historical reasons. The forward path >>> started at TV channel 2. The return path was shoe >>> horned in to the frequencies below that, which >>> limited the amount of available spectrum for return >>> path. >>> >>> Originally this didn't matter much because the only >>> thing it was used for was set top box communications >>> and occasionally sending video to the head end for >>> community channel remote feeds. >>> >>> To change the split would require replacement of all >>> the active and passive RF equipment in the network. >>> >>> Only now with he widespread conversion to digital >>> cable are they able to free up enough spectrum to >>> even consider moving the split at some point in the >>> future. >>> >>> >>> Something else to keep in mind, is that the cable >>> companies wanted to use the >>> upstream for voice using DOCSIS QoS to create a big >>> advantage over anybody >>> else who might want to just do voice over the top. >>> >>> There was lots of talk about business advantage, evil >>> home servers, etc, etc >>> and no care at all about legitimate uses for customer >>> upstream. If they wanted >>> to shape DOCSIS to have better upstream, all they had to >>> say is "JUMP" to cablelabs >>> and the vendors and it would have happened. >>> >>> Mike >>> >>> >>> Sent from my iPhone >>> >>> On Feb 28, 2015, at 6:20 PM, Mike Hammett >>> > wrote: >>> >>> As I said earlier, there are only so many >>> channels available. Channels added to upload are >>> taken away from download. People use upload so >>> infrequently it would be gross negligence on the >>> provider's behalf. >>> >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> ----- Original Message ----- >>> >>> From: "Clayton Zekelman" >> > >>> To: "Barry Shein" >> > >>> Cc: "NANOG" >> > >>> Sent: Saturday, February 28, 2015 5:14:18 PM >>> Subject: Re: Verizon Policy Statement on Net >>> Neutrality >>> >>> You do of course realize that the asymmetry in >>> CATV forward path/return path existed LONG >>> before residential Internet access over cable >>> networks exited? >>> >>> Sent from my iPhone >>> >>> On Feb 28, 2015, at 5:38 PM, Barry Shein >>> >> > wrote: >>> >>> >>> Can we stop the disingenuity? >>> >>> Asymmetric service was introduced to >>> discourage home users from >>> deploying "commercial" services. As were >>> bandwidth caps. >>> >>> One can argue all sorts of other "benefits" >>> of this but when this >>> started that was the problem on the table: >>> How do we forcibly >>> distinguish commercial (i.e., more >>> expensive) from non-commercial >>> usage? >>> >>> Answer: Give them a lot less upload than >>> download bandwidth. >>> >>> Originally these asymmetric, typically DSL, >>> links were hundreds of >>> kbits upstream, not a lot more than a >>> dial-up line. >>> >>> That and NAT thereby making it difficult -- >>> not impossible, the savvy >>> were in the noise -- to map domain names to >>> permanent IP addresses. >>> >>> That's all this was about. >>> >>> It's not about "that's all they need", >>> "that's all they want", etc. >>> >>> Now that bandwidth is growing rapidly and >>> asymmetric is often >>> 10/50mbps or 20/100 it almost seems >>> nonsensical in that regard, entire >>> medium-sized ISPs ran on less than 10mbps >>> symmetric not long ago. But >>> it still imposes an upper bound of sorts, >>> along with addressing >>> limitations and bandwidth caps. >>> >>> That's all this is about. >>> >>> The telcos for many decades distinguished >>> "business" voice service >>> from "residential" service, even for just >>> one phone line, though they >>> mostly just winged it and if they declared >>> you were defrauding them by >>> using a residential line for a business they >>> might shut you off and/or >>> back bill you. Residential was quite a bit >>> cheaper, most importantly >>> local "unlimited" (unmetered) talk was only >>> available on residential >>> lines. Business lines were even coded 1MB >>> (one m b) service, one >>> metered business (line). >>> >>> The history is clear and they've just >>> reinvented the model for >>> internet but proactively enforced by >>> technology rather than studying >>> your usage patterns or whatever they used to >>> do, scan for business ads >>> using "residential" numbers, beyond >>> bandwidth usage analysis. >>> >>> And the CATV companies are trying to >>> reinvent CATV pricing for >>> internet, turn Netflix (e.g.) into an >>> analogue of HBO and other >>> premium CATV services. >>> >>> What's so difficult to understand here? >>> >>> -- >>> -Barry Shein >>> >>> The World | bzs at TheWorld.com >>> | >>> http://www.TheWorld.com >>> Purveyors to the Trade | Voice: 800-THE-WRLD >>> | Dial-Up: US, PR, Canada >>> Software Tool & Die | Public Access Internet >>> | SINCE 1989 *oo* >>> >>> >> > From jbates at paradoxnetworks.net Sun Mar 1 16:27:13 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Sun, 01 Mar 2015 10:27:13 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F337CF.4020304@mtcc.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <82748B6A-D6D7-4963-A749-47EF4D94DD8D@mnsi.net> <21746.34640.36061.415267@world.std.com> <32D3C16D-0F4D-45BA-99F8-D41FE23D472C@mnsi.net> <54F337CF.4020304@mtcc.com> Message-ID: <54F33DE1.6020109@paradoxnetworks.net> On 3/1/2015 10:01 AM, Michael Thomas wrote: > > > They didn't want to give channels for internet bandwidth either. Life > would have been > *far* more simple had the MSO's not *forced* the hardware designer to > use their crappy > noisy back channel, such as it was. The move from analog -- which was > happening around > the same time -- pretty much negated that reason, but by then they had > a bunch more > reasons why they thought slow upstream was great for business. > To be fair, because of the size of their loops when they went data, they needed as much download as they could put on the wire and even then we listened to complaints of the "too many customers on a cable loop" for years. Of course, some cable companies shorted their loops and didn't have saturation problems on the loop side. You'd have to ask them how much excess they have during peak that would allow for higher upstreams without sacrificing producing downstream. DSL standards were all over the place, and most models make sense if you take into account what they need for a downstream. This is true for ADSL2+ even, given that it is also used for video and the extra downstream takes that into account more than anything. There are annexes that have higher upstreams, but the vendor support on them is limited. This is why I always argue that standards should cease to look at static allocations and support variable with both default "starting rates" and "cap rates" depending on what the provider needs. Even if we went with a longer term adjustment scheme, it would still be better; so your 1.5mb/s upstream eventually shifts to a 10mb/s upstream because you are actively using it. Simple user controls would be nice (if both are being saturated, allow for balance at symmetric, or downstream is greedy; only give upstream if downstream isn't saturated). I don't design these things, don't have the time for it, so I won't overtax my brain actually trying to design it. However, given the work on GMPLS, I suspect it's very probable that we could have something highly variable based on demand. Wasting timeslots/frequencies in technology is still waste. KISS is only better then the solution meets needs. Over the years, I've found that we have made things a lot more complex to deal with needs. This is just another area that could use some of that complexity. It also removes a lot of the need for annexes which generally weren't all supported in a vendor product anyways. Jack From mike at mtcc.com Sun Mar 1 16:32:28 2015 From: mike at mtcc.com (Michael Thomas) Date: Sun, 01 Mar 2015 08:32:28 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <82748B6A-D6D7-4963-A749-47EF4D94DD8D@mnsi.net> <54F24E5C.1000407@mtcc.com> <54F33886.1060504@mtcc.com> Message-ID: <54F33F1C.5040104@mtcc.com> On 03/01/2015 08:19 AM, Scott Helms wrote: > > Michael, > > Then you understand that having the upstreams and downstreams use the > same frequencies, especially in a flexible manner, would require > completely redesigning every diplex filter, amplifier, fiber node, and > tap filters in the plant. At the same time we'd have to replace all > of the modems, set top boxes, TV tuners embedded in TV sets, > CableCards, and CMTS blades. > They were already changing all of that due to the switch from analog. The MSO's had complete control over what the hardware specs looked like. Since they were actively hostile to "servers", and wanted to reproduce the telco revenue model (which were at some level linked), the upstream being a limited resource became a feature, not a bug. Had the MSO's wanted a better upstream, all they had to do was ask. Mike From morrowc.lists at gmail.com Sun Mar 1 16:58:34 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 1 Mar 2015 11:58:34 -0500 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: <20150301124846.GA16378@gsp.org> References: <54F0E159.2000804@satchell.net> <20150227233223.18612.qmail@ary.lan> <20150301124846.GA16378@gsp.org> Message-ID: On Sun, Mar 1, 2015 at 7:48 AM, Rich Kulawiec wrote: > On Sat, Feb 28, 2015 at 08:03:28PM -0500, John R. Levine wrote: >> Well, actually, it does. Every broadband network in the US >> currently blocks outgoing port 25 connections from retail customers. > > Unfortunately, that's not entirely true. (Very) recent direct-to-MX spam > from customers: > And...well, you get the point. business vs consumer edition products? (that'd be my bet) From dave.taht at gmail.com Sun Mar 1 18:35:50 2015 From: dave.taht at gmail.com (Dave Taht) Date: Sun, 1 Mar 2015 10:35:50 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> Message-ID: I am not normally, willingly, on nanog. My emailbox is full enough. I am responding, mostly, to a post I saw last night, where the author complained about the horrid performance he got when attempting a simultaneous up and download on a X/512k upload DSL link. That is so totally fixable now, at speeds below 60mbit, with any old cast off home router that I had to reply... Honestly I had assumed that everyone here has the chops to fix their own networks (home and business), in circumstances of high latency under load caused by bufferbloat - *by now* - and I hadn't spent any time on this list at all. A DSL product, running openwrt, made in australia, - was the first DSL device to get the excess buffering in the DSL driver ripped out and fq_codel tested. I was over at David Woodhouse's house in England while he fixed it - which was at LEAST 3 years ago. And he's been running it with openwrt and those fixes ever since. The name began with a T, it was a geode, I can't remember the name of it now. These were the results we got on DSL on an old modem that supported pause frames: http://planet.ipfire.org/post/ipfire-2-13-tech-preview-fighting-bufferbloat These are the improvements in bandwidth and latency under load - in both directions - we commonly get on cable modems, using the sqm-scripts now in openwrt and working on any linux box you care to use. http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html http://burntchrome.blogspot.com/2014/05/fixing-bufferbloat-on-comcasts-blast.html Probably the shortest talk I have ever given on these topics (23 minutes long) was at uknof here, where in particular, I demoed the improvements in web load time that are now possible. 2 years ago. https://plus.google.com/u/0/103994842436128003171/posts/Kpogana4pze See also: https://plus.google.com/u/0/explore/bufferbloat And recently I gave much longer talk, which FINALLY includes some bits on how we intend to now focus on *vastly improving wifi*, at nznog, which starts at 2:05 on friday morning here: http://new.livestream.com/i-filmservices/NZNOG2015/videos/75358960 I am tired of looking at myself, and I have to say that the talk before mine was WONDERFUL - the guy went into all sorts of new ways to find latency events, and filter out any false positives and provide new kinds of alerts to operators. And the talk after, from cloudflare, depressing as hell. I will gladly give another bloat talk to nannogers if that helps at some future conference, but jeeze, this stuff is so easy to fix now, and everyone involved is tired of repeating themselves, especially me. but since I haven't ranted here yet... and only intend to do this once, here I go.... ... Since being developed, the core BQL and fq_codel code has become fully available in every linux distribution I know of. The most advanced versions of it are in the "sqm-scripts" that are part of the openwrt "chaos calmer" work - notably - unlike every other shaper I know of, it can correctly compensate for PPPoe and DSL framing problems, and it automatically handles the problems that codel has on links below 2.5Mbits. We worked for over a year to get that right - fixed all the bugs in htb, mainlined and made available for free how to do it all right, as of Linux 3.10.12 and later, and all that logic is in those sqm-scripts - which work best on openwrt but also work on any linux distro with a couple tweaks. (and since then we have worked to pour it all into C with even simpler configuratiojn, that work is not done yet, please feel free to come help). So anyone here, with a spare 60-90 bucks, 5 minutes, and the right re-flashable router no longer has cause to complain about high jitter and latency, even on the slowest and most asymmetric links at home, or in their businesses. Benchmarks of the "fq" portion of fq_codel show it as better than "sfq", and the codel portion, way better than RED. It helps of course, to do valid benchmarking of the real problems in your links - in your switches - and in your routers - at nanog scales - so we have developed a suite of tests you can use called "rrul" real time response under load - available for free as part of "netperf-wrappers" - https://github.com/tohojo/netperf-wrapper The server for which works on everything (netperf is very portable), and the test client driver, analysis tools and gui, work on any linux system and can be made to work on OSX via macports (I was unsuccessful at brew). The data it collects is your own, and aggregatable, and you don't need to share it with anyone if you don't want to. I would certainly like it, if after evaluating and then fixing bits of your own network that way, that anyone doing so, would volunteer to go fix two other networks, and get the people running those networks to go fix two other networks, each, and so on. And of course, feel free to nag and publicly embarrass those providing busted, bloated CPE, DSLAMS, BRAMS, and CMTSes, etc to actually deploy this stuff on their side, so we all can move on, and all have way better networks. Anyone here *making linux based CPE*, can merely update their code to something modern, containing these algorithms. Backports are possible, but so far, I have been quite depressed by the overall buggy results I have seen from the home router makers attempting to so. All the streamboost products I have tested are defective in some respect or another - so I am back to recommending people just reflash their firmware ("friends don't let friends run factory firmware") with something readily available and good off of openwrt's unbelievable large list. https://downloads.openwrt.org/snapshots/trunk/ I have a fondness for the ar71xx products as those generally have the best drivers (ath9k) for wifi. I know full well, that Linux does not rule the world (yet), and most of my ire these days is aimed at those that are not paying attention or helping fix their crappy systems. While half of the solution - codel - is already available as patches to at least one BSD version... I am still waiting patiently for someone to code up a version of fq_codel for BSD. fq_codel was written in a single saturday afternoon, and mainlined in the next week - and despite trying, we have been unable to come up with anything more than marginally better. I have been reluctant to do that port personally as transliterating from GPL to BSD is something that someone else should do, based on the IETF internet draft we produced. https://tools.ietf.org/html/draft-hoeiland-joergensen-aqm-fq-codel-01 We (on the codel or bloat email lists) will gladly review patches and performance data, however. If you are stuck with older gear that can't be updated, perhaps you can apply HFSC + SFQ which works pretty well at lower bandwidths, but has problems that I documented here: http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die As for fixing your interconnects - or any other places you have *any* bufferbloat and/or bad latency - the fq_codel algorithm is incredibly light-weight, and works at 10GE and above. (software rate shaping, not so much) Netperf-wrapper also scales to 10GigE. In fact, it is being used to test stuff running at 40GigE. Most other tools for testing for bandwidth and latency, start showing erroneous results above 20Mbit. I too would like asymmetric networks to behave better, but these are the best tools we got to fix what we have. Go forth, test, and deploy! A plea: please stop debating about policy and just deploy s**t that works. [1] Quite a few bits of DSL firmware are a problem. The only truly "perfect" DSL firmware I know of is in free.fr's revolution v6 router - which was deployed august, 2012 - with a DRR + fq_codel based implementation that works *really well* at line rate, whatever it is - no software shaping required. On Sun, Mar 1, 2015 at 3:40 AM, Aled Morris wrote: > On 1 March 2015 at 03:41, Barry Shein wrote: > >> Previously all residential service (e.g., dial-up, ISDN) was >> symmetrical. > > > The rot set in with V.90 "56k" modems - they were asymmetric - only the > downstream was 56k. The only way to achieve this in the analogue realm was > by digital synthesis at the head-end, i.e. the T1/E1 handoff to the ISP. > The upstream from the subscriber didn't have a clean interface so was still > using 33.6k. > > Sadly we don't have many "killer applications" for symmetric residential > bandwidth, but that's likely because we don't have the infrastructure to > incubate these applications. > > It's a chicken and egg situation - of course the average consumer today > will say they "don't need" symmetric, but you could have asked them twenty > years ago and they'd have said they didn't need the Internet at all. Or > smartphones. I agree totally with this sentiment - if we had symmetric edge networks, we would have come up with ways to use them. offsite backup would be a lot more common, in particular. > This all suits the telcos and cablecos very nicely - they are happy when > their customers are passive consumers of paid content and services. It > gives them control. > > I don't think it's a conspiracy, but it suits the big players not to "fix" > the "problem" since they don't perceive it as being one. > > Aled -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb From mfidelman at meetinghouse.net Sun Mar 1 19:59:28 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sun, 01 Mar 2015 14:59:28 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> <54F31DBE.9060603@meetinghouse.net> <54F32F1A.9090201@meetinghouse.net> Message-ID: <54F36FA0.9060809@meetinghouse.net> Hey Barry - you ran some rather huge NNTP servers, back in the day, you have any comments on this? Scott Helms wrote: > > Miles, > > Usenet was normally asymmetrical between servers, even when server > operators try to seed equally as being fed. It's a function of how a > few servers are the source original content and how long individual > servers choose (and have the disk) to keep specific content. > > It was never designed to have as many server nodes as you're > describing and I'd imagine there's some nasty side effects if we tried > get that many active servers going as we have customers. > > On Mar 1, 2015 10:25 AM, "Miles Fidelman" > wrote: > > Scott, > > Asymmetric measured where? Between client and server or between > servers? I'm thinking the case where we each have a server > running locally - how do you get a high level of asymmetry in a > P2P environment? > > Miles Fidelman > > > > Scott Helms wrote: > > > Anything based on NNTP would be extremely asymmetric without > significant changes to the protocol or human behavior. > > We ran significant Usenet servers with binaries for nearly 20 > years and without for another 5 and the servers' traffic was > heavily asymmetric. > > On Mar 1, 2015 9:11 AM, "Miles Fidelman" > > >> wrote: > > Aled Morris wrote: > > > Sadly we don't have many "killer applications" for > symmetric > residential > bandwidth, but that's likely because we don't have the > infrastructure to > incubate these applications. > > > Come to think of it, if USENET software wasn't so > cumbersome, I > kind of wonder if today's "social network" would consist > of home > servers running NNTP - and I expect the traffic would be very > symmetric. (For that matter, with a few tweaks, the USENET > model > would be great for "groupware" - anybody remember the Netscape > communications server that added private newsgroups and > authentication to the mix?) > > Miles Fidelman > > > > -- In theory, there is no difference between theory > and practice. > In practice, there is. .... Yogi Berra > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From johnl at iecc.com Sun Mar 1 21:19:47 2015 From: johnl at iecc.com (John Levine) Date: 1 Mar 2015 21:19:47 -0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F32F1A.9090201@meetinghouse.net> Message-ID: <20150301211947.27183.qmail@ary.lan> In article <54F32F1A.9090201 at meetinghouse.net> you write: >Scott, > >Asymmetric measured where? Between client and server or between >servers? I'm thinking the case where we each have a server running >locally - how do you get a high level of asymmetry in a P2P environment? There's always a lot more stuff from other people than from you. Unless you expect every server to connect directly to every other server, you're going to end up with a small set of well connected servers that feed stub servers and send way more than they receive, and the stubs that receive way more than they send. I have run usenet servers pretty much continuously for over 20 years, and Usenet has always been like that. R's, John From johnl at iecc.com Sun Mar 1 21:25:50 2015 From: johnl at iecc.com (John Levine) Date: 1 Mar 2015 21:25:50 -0000 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: <20150301124846.GA16378@gsp.org> Message-ID: <20150301212550.27225.qmail@ary.lan> In article <20150301124846.GA16378 at gsp.org> you write: >On Sat, Feb 28, 2015 at 08:03:28PM -0500, John R. Levine wrote: >> Well, actually, it does. Every broadband network in the US >> currently blocks outgoing port 25 connections from retail customers. > >Unfortunately, that's not entirely true. (Very) recent direct-to-MX spam >from Comcast customers: Well, it's supposed to be blocked, according to people I've talked to at Comcast and T-W as recently as a week ago. I can believe that they have configuration problems on a networks of that size. R's, John From owen at delong.com Sun Mar 1 21:26:51 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 1 Mar 2015 13:26:51 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F33AB5.3040208@foobar.org> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> <54F33AB5.3040208@foobar.org> Message-ID: >> It was the combination of asymmetric, no or few IPs (and NAT), and >> bandwidth caps. > > let's not rewrite history here: IPv4 address scarcity has been a thing > since the very early 1990s. Otherwise why would cidr have been created? CIDR had nothing to do with address scarcity. CIDR was invented for routing table slot scarcity in Cisco AGS hardware of the era. Routers running out of BGP table space wasn’t just a fear at the time, it was a real problem on a number of networks, including, but not limited to SPRINT and MCI who were the big dogs in the fight at the time. NAT, OTOH, is an address conservation mechanism which has unfortunately of late been mistaken for a security tool. If only people would realize how much NAT negatively impacts security, manageability, etc. Owen From drc at virtualized.org Sun Mar 1 21:37:34 2015 From: drc at virtualized.org (David Conrad) Date: Sun, 1 Mar 2015 16:37:34 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> <54F33AB5.3040208@foobar.org> Message-ID: <4EDACA29-A706-447B-BD92-A1ED9C88CC41@virtualized.org> > On Mar 1, 2015, at 4:26 PM, Owen DeLong wrote: > >>> It was the combination of asymmetric, no or few IPs (and NAT), and >>> bandwidth caps. >> >> let's not rewrite history here: IPv4 address scarcity has been a thing >> since the very early 1990s. Otherwise why would cidr have been created? > > CIDR had nothing to do with address scarcity. Untrue. CIDR was created in response to the proliferation of "class Cs" being allocated instead of "class Bs". The reason class Cs were being allocated instead of class Bs was due to projections (I believe by Frank Solensky and/or Noel Chiappa) that showed we would exhaust the Class B pool by 1990 or somesuch. This led to the ALE (Address Lifetime Extensions) and CIDRD working groups that pushed for the allocation of blocks of class Cs instead of Class Bs. CIDR also allowed for more appropriately sized blocks to be allocated instead of one-size-fits-most of class Bs. This increased address utilization which likely extended the life of the IPv4 free pool. 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 morrowc.lists at gmail.com Sun Mar 1 21:44:32 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 1 Mar 2015 16:44:32 -0500 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: <20150301212550.27225.qmail@ary.lan> References: <20150301124846.GA16378@gsp.org> <20150301212550.27225.qmail@ary.lan> Message-ID: On Sun, Mar 1, 2015 at 4:25 PM, John Levine wrote: > In article <20150301124846.GA16378 at gsp.org> you write: >>On Sat, Feb 28, 2015 at 08:03:28PM -0500, John R. Levine wrote: >>> Well, actually, it does. Every broadband network in the US >>> currently blocks outgoing port 25 connections from retail customers. >> >>Unfortunately, that's not entirely true. (Very) recent direct-to-MX spam >>from Comcast customers: > > Well, it's supposed to be blocked, according to people I've talked to > at Comcast and T-W as recently as a week ago. I can believe that they > have configuration problems on a networks of that size. fairly certain that none of these folk block port 25 on their business customer links. From johnl at iecc.com Sun Mar 1 22:01:32 2015 From: johnl at iecc.com (John R. Levine) Date: 1 Mar 2015 17:01:32 -0500 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: References: <20150301124846.GA16378@gsp.org> <20150301212550.27225.qmail@ary.lan> Message-ID: >>>> Well, actually, it does. Every broadband network in the US >>>> currently blocks outgoing port 25 connections from retail customers. >>> >>> Unfortunately, that's not entirely true. (Very) recent direct-to-MX spam >>> from Comcast customers: >> >> Well, it's supposed to be blocked, according to people I've talked to >> at Comcast and T-W as recently as a week ago. I can believe that they >> have configuration problems on a networks of that size. > > fairly certain that none of these folk block port 25 on their business > customer links. As I said above, retail customers. Business customers get static IPs and generaly no blocking. R's, John From bmanning at isi.edu Sun Mar 1 22:50:57 2015 From: bmanning at isi.edu (manning bill) Date: Sun, 1 Mar 2015 14:50:57 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <4EDACA29-A706-447B-BD92-A1ED9C88CC41@virtualized.org> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> <54F33AB5.3040208@foobar.org> <4EDACA29-A706-447B-BD92-A1ED9C88CC41@virtualized.org> Message-ID: Frank was the most vocal… the biggest cidr deployment issue was hardware vendors with “baked-in” assumptions about addressing. IPv6 is doing the same thing with its /64 nonsense. /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 1March2015Sunday, at 13:37, David Conrad wrote: >> On Mar 1, 2015, at 4:26 PM, Owen DeLong wrote: >> >>>> It was the combination of asymmetric, no or few IPs (and NAT), and >>>> bandwidth caps. >>> >>> let's not rewrite history here: IPv4 address scarcity has been a thing >>> since the very early 1990s. Otherwise why would cidr have been created? >> >> CIDR had nothing to do with address scarcity. > > Untrue. > > CIDR was created in response to the proliferation of "class Cs" being allocated instead of "class Bs". The reason class Cs were being allocated instead of class Bs was due to projections (I believe by Frank Solensky and/or Noel Chiappa) that showed we would exhaust the Class B pool by 1990 or somesuch. This led to the ALE (Address Lifetime Extensions) and CIDRD working groups that pushed for the allocation of blocks of class Cs instead of Class Bs. > > CIDR also allowed for more appropriately sized blocks to be allocated instead of one-size-fits-most of class Bs. This increased address utilization which likely extended the life of the IPv4 free pool. > > Regards, > -drc > From Jason_Livingood at cable.comcast.com Sun Mar 1 23:16:23 2015 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Sun, 1 Mar 2015 23:16:23 +0000 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: References: <20150301124846.GA16378@gsp.org> <20150301212550.27225.qmail@ary.lan> Message-ID: On 3/1/15, 4:44 PM, "Christopher Morrow" wrote: >>>Unfortunately, that's not entirely true. (Very) recent direct-to-MX >>>spam >>>from Comcast customers: >fairly certain that none of these folk block port 25 on their business >customer links. Bingo! Yes, commercial customers do run mail servers from their locations. The list of IPs certainly looked commercial. Jason From dave.taht at gmail.com Sun Mar 1 23:28:35 2015 From: dave.taht at gmail.com (Dave Taht) Date: Sun, 1 Mar 2015 15:28:35 -0800 Subject: Bufferbloat related censorship at Virgin Media Message-ID: I have put this on a blog post, and my g+ also, here, and submitted the story to slashdot and reddit. How I spend my sunday afternoons these days! The linky version: http://the-edge.blogspot.com/2015/03/virgin-media-fixing-epidemic-of.html or g+: https://plus.google.com/u/0/107942175615993706558/posts/E1yMgbWW81C --snip snip-- To whom it may concern at Virgin Media: My IP address is apparently now banned from accessing your site at all, for "advertising", on this thread: http://community.virginmedia.com/t5/Up-to-152Mb/Bufferbloat-High-Latency-amp-packet-loss-when-connection/td-p/2773495 Believe me, I understand the degree to which advertising pollutes the internet. And certainly, given the brevity of my post, you could assume that I was just some random guy, selling snake oil. Nothing could be further from the truth. Admittedly, it was a short message, it was kind of late, and I was in a hurry, being that I have so many other networks to help fix. To clarify matters: I am the co-founder of the bufferbloat project, and I like to think, a world-wide acknowledged expert on the topic on this thread. In particular, I worked pretty hard on part of the DOCSIS 3.1 standard, which was ratified years ago, and has a specific section on it regarding technologies that can help fix *half* your bufferbloat problem. http://www.cablelabs.com/how-docsis-3-1-reduces-latency-with-active-queue-management/ I admit to some frustration as to how long it is taking DOCSIS 3.1 to roll out. The cablelabs study that led up to the AQM component in the 3.1 standard - in which I participated and am cited in, is here: http://www.cablelabs.com/wp-content/uploads/2013/11/Active_Queue_Management_Algorithms_DOCSIS_3_0.pdf And while I continue to favor fq_codel as the best solution for low and medium bandwidths - I have no problem with you somehow, soon, getting DOCSIS-pie out the door. If you continue to exist in denial of what your own R&D department for your own industry is saying, ghu help you! After giving this talk at uknof, the premier conference for network operators in the UK: https://plus.google.com/u/0/107942175615993706558/posts/immF8Pkj19C *over two years ago*, I met with 6+ technical members of Virgin Media's staff, who all agreed they had a problem, understood what it was, and grokked the various means to fix it. Judging from the enthusiasm in the room, I figured you'd be rolling out fixes by now, but was wrong. A rather human readable explanation of what has gone into the pending 3.1 standard is in the IETF internet draft here: https://datatracker.ietf.org/doc/draft-white-aqm-docsis-pie/ Sadly, just DOCSIS-pie rolling out on the modems is not enough - you have to somehow, yourselves, fix the dramatic overbuffering on the CMTS side, as shown here: http://burntchrome.blogspot.com/2014/05/disabling-shaping-in-one-direction-with.html These downlink problems have been discussed thoroughly on the bufferbloat.net bloat and the ietf aqm mailing lists, and rather than point at direct links I would encourage more people to join the discussions there, and browse the archives. As I have seen no visible progress on the CMTS front yet... The best way to fix bufferbloat for your suffering customers *now*, is to help them - and your customer service departments - recognise the problem when it occurs and propose sane ways to fix it with stuff available off the shelf which includes the free firmware upgrades distributed by openwrt, or nearly any linux derived product and by the products available downstream from those. I have no financial interest in *free firmware*. I'm just trying to fix bufferbloat on a billion+ devices and nearly every network in the world as fast as humanly possible. Furthermore, me and a whole bunch of Internet luminaries gave the theory and code away for *free* also, in the hope that by doing so that might more quickly get the megacorps of the world to adopt them and make the quality of experience of internet access for billions of users of the world vastly better. Fixing bufferbloat was a 50 year old network research problem, now solved, with great joy, thoroughly, by some of the best minds in the business, and the answers are now so simple as to fit into a few hundred lines of code, easy to configure for end-users and easily embeddible in your own devices and networks if only you would get on the stick about it. We have provided the code, are in the standardization process, and provided free tools to diagnose and fix your epidemic bufferbloat accurately on every kind of device you have. Two examples of fixing bufferbloat on cablemodems: http://burntchrome.blogspot.com/2014/05/fixing-bufferbloat-on-comcasts-blast.html http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html And the *free* tool designed not only to accurately measure bufferbloat, but one that you can setup internally to test your networks and devices for it privately and quietly and then fix them with, is here: https://github.com/tohojo/netperf-wrapper So, now, a rant: Now, if me pointing a customer of yours that has correctly identified the root cause of his own problems, at the solutions both available now, and pending, is considered "advertising", then there really is an orwellian mixup between the definition of that word, and the truth, on your side of the water. Please, unblock my dtaht account and unblock my IP, and allow in better information about how customers of yours can solve the incredibly serious, and incredibly epidemic problem of bufferbloat. ... A problem that is now easy to solve with cheap gear now all over the market so that all your customers suffering can fix it for themselves if they so choose. And: I would like a public apology for blocking me, and a clear statement from Virgin, as to how, when, and where, they will begin to roll out their own fixes to bufferbloat across their subscriber base. And perhaps, you could publish some guidelines - like accurate up/download settings to use - to help your customers fix your problems for themselves. Sincerely, Dave Taht Co-founder, bufferbloat.net -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb From mel at beckman.org Sun Mar 1 23:47:11 2015 From: mel at beckman.org (Mel Beckman) Date: Sun, 1 Mar 2015 23:47:11 +0000 Subject: Bufferbloat related censorship at Virgin Media In-Reply-To: References: Message-ID: Dave, I appreciate all your work on buffer bloat. It looks like you have done quite a lot of selfless contribution. However, I don't think you're effectively communicating with the people who can change things. After I read what you said, here is what I would have heard as a service provider: "I am the smartest person in the room. You better listen to me, because if you don't there will be trouble. But you probably won't because you're too stupid. Your customers suffer because you are idiots. Listen to me! This issue is too important for me to be polite, or even coherent. If you can't figure out what I'm saying, do some research and figure it out! Plus, apologize to me! I demand it!" Bees, honey, vinegar, etc. -mel beckman > On Mar 1, 2015, at 3:29 PM, "Dave Taht" wrote: > > I have put this on a blog post, and my g+ also, here, and submitted > the story to slashdot and reddit. How I spend my sunday afternoons > these days! > > The linky version: > http://the-edge.blogspot.com/2015/03/virgin-media-fixing-epidemic-of.html > > or g+: https://plus.google.com/u/0/107942175615993706558/posts/E1yMgbWW81C > > --snip snip-- > > To whom it may concern at Virgin Media: > > My IP address is apparently now banned from accessing your site at > all, for "advertising", on this thread: > > [Unnecessary repetition removed] From dave.taht at gmail.com Mon Mar 2 00:01:02 2015 From: dave.taht at gmail.com (Dave Taht) Date: Sun, 1 Mar 2015 16:01:02 -0800 Subject: Bufferbloat related censorship at Virgin Media In-Reply-To: References: Message-ID: On Sun, Mar 1, 2015 at 3:47 PM, Mel Beckman wrote: > Dave, > > I appreciate all your work on buffer bloat. It looks like you have done quite a lot of selfless contribution. However, I don't think you're effectively communicating with the people who can change things. > > After I read what you said, here is what I would have heard as a service provider: > > "I am the smartest person in the room. I am pretty close to being the smartest person in the room. That said, people like van jacobson, eric dumazet, tom herbert, jim gettys, eric raymond, vint cerf, dave reed, fred baker, and many, many others, smarter than me, have also been banging this drum, politely, and rationally, to not much effect, for 4+ years now. google for any of those names and the word "bufferbloat". > You better listen to me, because if you don't there will be trouble. But you probably won't because you're too stupid. Your customers suffer because you are idiots. Listen to me! This issue is too important for me to be polite, or even coherent. If you can't figure out what I'm saying, do some research and figure it out! Plus, apologize to me! I demand it!" Oh, banning my ip for *3 links to sane benchmarks and fixes*, realllllly pushed me over the edge. > Bees, honey, vinegar, etc. I have been polite, constructive, and helpful, for four+ years. I have worked both in the background and foreground with many companies, to start hopefully, getting bufferbloat fixed across the entire edge of the internet. It hasn't worked fast enough for my liking, and the last batch of new products that claimed to fix it, didn't, and the market is now rife with genuine lies as to whether they did or not. So, this morning, I tried this. Sorry for the noise on these lists. Honestly! I totally agree with your assessment of my tone, btw! but I would rather like the cable industry in particular, to come clean, with schedules for deployable fixes. I am off to go fix wifi next, and I do hope that 2+ billion people in the world - if not the isps, maybe - would like wifi to get better also, and indeed, I spent the weekend constructively starting to implement some of the fixes I outlined at the last 802.11 meeting I attended. That part, on fixing wifi bufferbloat - a much harder problem than edge bufferbloat - , is a lot of fun! For some info on what we plan to do there, see: http://snapon.lab.bufferbloat.net/~d/ieee802.11-sept-17-2014/11-14-1265-00-0wng-More-on-Bufferbloat.pdf So I took a break from that, reared back, and got some stuff off my chest. -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb From jbates at paradoxnetworks.net Mon Mar 2 00:04:22 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Sun, 01 Mar 2015 18:04:22 -0600 Subject: Bufferbloat related censorship at Virgin Media In-Reply-To: References: Message-ID: <54F3A906.7080806@paradoxnetworks.net> On 3/1/2015 5:28 PM, Dave Taht wrote: > > My IP address is apparently now banned from accessing your site at > all, for "advertising", on this thread: > > http://community.virginmedia.com/t5/Up-to-152Mb/Bufferbloat-High-Latency-amp-packet-loss-when-connection/td-p/2773495 > > I don't see how codel is related to the customer complaint from their perspective. The problem appears to be high latency on downstream with little to no upstream. I'd probably call it off-topic advertising. The only thing that seems to relate to codel is the user's use of bufferbloat in the topic. Nothing the user can do will fix the downstream to my knowledge. Not that I'm extremely knowledgeable on the subject. Jack From mel at beckman.org Mon Mar 2 00:08:07 2015 From: mel at beckman.org (Mel Beckman) Date: Mon, 2 Mar 2015 00:08:07 +0000 Subject: Bufferbloat related censorship at Virgin Media In-Reply-To: References: , Message-ID: <458FF796-9D09-48C3-B012-903A3EC10017@beckman.org> Well, with luck probably it will just bounce off their corporate hull and drift into the Kuiper belt. Say hi to Sugar ;) -mel > On Mar 1, 2015, at 4:01 PM, "Dave Taht" wrote: > >> On Sun, Mar 1, 2015 at 3:47 PM, Mel Beckman wrote: >> Dave, >> >> I appreciate all your work on buffer bloat. It looks like you have done quite a lot of selfless contribution. However, I don't think you're effectively communicating with the people who can change things. >> >> After I read what you said, here is what I would have heard as a service provider: >> >> "I am the smartest person in the room. > > I am pretty close to being the smartest person in the room. That said, > people like van jacobson, eric dumazet, tom herbert, jim gettys, eric > raymond, vint cerf, dave reed, fred baker, and many, many others, > smarter than me, have also been banging this drum, politely, and > rationally, to not much effect, for 4+ years now. > > google for any of those names and the word "bufferbloat". > >> You better listen to me, because if you don't there will be trouble. But you probably won't because you're too stupid. Your customers suffer because you are idiots. Listen to me! This issue is too important for me to be polite, or even coherent. If you can't figure out what I'm saying, do some research and figure it out! Plus, apologize to me! I demand it!" > > Oh, banning my ip for *3 links to sane benchmarks and fixes*, > realllllly pushed me over the edge. > >> Bees, honey, vinegar, etc. > > I have been polite, constructive, and helpful, for four+ years. I have > worked both in the background and foreground with many companies, to > start hopefully, getting bufferbloat fixed across the entire edge of > the internet. It hasn't worked fast enough for my liking, and the last > batch of new products that claimed to fix it, didn't, and the market > is now rife with genuine lies as to whether they did or not. > > So, this morning, I tried this. Sorry for the noise on these lists. > Honestly! I totally agree with your assessment of my tone, btw! but I > would rather like the cable industry in particular, to come clean, > with schedules for deployable fixes. > > I am off to go fix wifi next, and I do hope that 2+ billion people in > the world - if not the isps, maybe - would like wifi to get better > also, and indeed, I spent the weekend constructively starting to > implement some of the fixes I outlined at the last 802.11 meeting I > attended. That part, on fixing wifi bufferbloat - a much harder > problem than edge bufferbloat - , is a lot of fun! For some info on > what we plan to do there, see: > > http://snapon.lab.bufferbloat.net/~d/ieee802.11-sept-17-2014/11-14-1265-00-0wng-More-on-Bufferbloat.pdf > > So I took a break from that, reared back, and got some stuff off my chest. > > -- > Dave Täht > Let's make wifi fast, less jittery and reliable again! > > https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb From dave.taht at gmail.com Mon Mar 2 00:14:33 2015 From: dave.taht at gmail.com (Dave Taht) Date: Sun, 1 Mar 2015 16:14:33 -0800 Subject: Bufferbloat related censorship at Virgin Media In-Reply-To: <54F3A906.7080806@paradoxnetworks.net> References: <54F3A906.7080806@paradoxnetworks.net> Message-ID: On Sun, Mar 1, 2015 at 4:04 PM, Jack Bates wrote: > On 3/1/2015 5:28 PM, Dave Taht wrote: >> >> >> My IP address is apparently now banned from accessing your site at >> all, for "advertising", on this thread: >> >> >> http://community.virginmedia.com/t5/Up-to-152Mb/Bufferbloat-High-Latency-amp-packet-loss-when-connection/td-p/2773495 >> >> > > I don't see how codel is related to the customer complaint from their > perspective. The problem appears to be high latency on downstream with > little to no upstream. I'd probably call it off-topic advertising. The only > thing that seems to relate to codel is the user's use of bufferbloat in the > topic. Nothing the user can do will fix the downstream to my knowledge. Not > that I'm extremely knowledgeable on the subject. It is 100% possible to fix excessive downstream buffering from some misconfigured device with a shaper on the download *on the CPE or home router*. I have been doing that for 15 years. So has everyone that uses nearly any of the shapers that are available for Linux, at least. http://burntchrome.blogspot.com/2014_05_01_archive.html doing it yourself, right, requires a good measurement, and you lose just a little bit of single-flow bandwidth - typically 5% - but you get it all back with faster tcp ramp up times, huge improvements in dns lookups, voip, gaming, and other traffic. it generally works way better than policers do. > > Jack -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb From jbates at paradoxnetworks.net Mon Mar 2 00:39:29 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Sun, 01 Mar 2015 18:39:29 -0600 Subject: Bufferbloat related censorship at Virgin Media In-Reply-To: References: <54F3A906.7080806@paradoxnetworks.net> Message-ID: <54F3B141.5080003@paradoxnetworks.net> On 3/1/2015 6:14 PM, Dave Taht wrote: > It is 100% possible to fix excessive downstream buffering from some > misconfigured device with a shaper on the download *on the CPE or > home router*. > > From OP: "However I've recently noticed periods of 500-800ms latency to the CMTS gateway when only using 15-20 of the 60Mbps total (and little to none upstream utilisation)." I agree with you that it is better to run a shaper that insures your shaper hits saturation and handles queue policies before the upstream does. That is great if it is your pipe (and only its queue) that is saturating. I don't think this problem qualifies. I find it difficult to believe that he's hitting a buffer bloat issue on a single (not shared with others) queue using 1/3rd of the total bandwidth available to him at those speeds and with that latency value. His problem is more likely lower down (unable to obtain max speed resulting in saturation) or a shared queue where others are saturating it and him applying a shaper will not keep others from doing so. Jack From dave.taht at gmail.com Mon Mar 2 00:48:07 2015 From: dave.taht at gmail.com (Dave Taht) Date: Sun, 1 Mar 2015 16:48:07 -0800 Subject: Bufferbloat related censorship at Virgin Media In-Reply-To: <54F3B141.5080003@paradoxnetworks.net> References: <54F3A906.7080806@paradoxnetworks.net> <54F3B141.5080003@paradoxnetworks.net> Message-ID: http://burntchrome.blogspot.com/2014/05/disabling-shaping-in-one-direction-with.html On Sun, Mar 1, 2015 at 4:39 PM, Jack Bates wrote: > On 3/1/2015 6:14 PM, Dave Taht wrote: >> >> It is 100% possible to fix excessive downstream buffering from some >> misconfigured device with a shaper on the download *on the CPE or >> home router*. >> >> > From OP: "However I've recently noticed periods of 500-800ms latency to the > CMTS gateway when only using 15-20 of the 60Mbps total (and little to none > upstream utilisation)." Might be. Again, all I did on that thread was provide a few pointers to bufferbloat related resources, and pointed at the downlink being a real problem quite often with links to stuff like this http://burntchrome.blogspot.com/2014/05/disabling-shaping-in-one-direction-with.html and they yanked me. Certainly I could have tried again, from another IP, but ya know, some sundays are more fun than others. > > I agree with you that it is better to run a shaper that insures your shaper > hits saturation and handles queue policies before the upstream does. That is > great if it is your pipe (and only its queue) that is saturating. I don't > think this problem qualifies. Might not. That said, it was hardly an accurate measurement. It is also perfectly feasible for the upstream device or the downstream device to be measuring these problems and deal with them appropriately. It gets progressively easier cpu-wise, as the effective bandwidth goes down. It is unfortunately nearly impossible for the next device in line to do (although we have some tools measuring interpacket "smoothness" that can provide a hint now, they are not baked yet) It was my hope, in working on the DOCSIS 3.1 standard that all the possible downstream problems would be addressed. They weren't. > I find it difficult to believe that he's hitting a buffer bloat issue on a > single (not shared with others) queue using 1/3rd of the total bandwidth > available to him at those speeds and with that latency value. His problem is > more likely lower down (unable to obtain max speed resulting in saturation) > or a shared queue where others are saturating it and him applying a shaper > will not keep others from doing so. > > Jack -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb From owen at delong.com Mon Mar 2 01:53:38 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 1 Mar 2015 17:53:38 -0800 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: References: <20150301124846.GA16378@gsp.org> <20150301212550.27225.qmail@ary.lan> Message-ID: > On Mar 1, 2015, at 14:01 , John R. Levine wrote: > >>>>> Well, actually, it does. Every broadband network in the US >>>>> currently blocks outgoing port 25 connections from retail customers. >>>> >>>> Unfortunately, that's not entirely true. (Very) recent direct-to-MX spam >>>> from Comcast customers: >>> >>> Well, it's supposed to be blocked, according to people I've talked to >>> at Comcast and T-W as recently as a week ago. I can believe that they >>> have configuration problems on a networks of that size. >> >> fairly certain that none of these folk block port 25 on their business >> customer links. > > As I said above, retail customers. Business customers get static IPs and generaly no blocking. > > R's, > John Business customers only get static from Comcast if they pay extra for it. Owen From johnl at iecc.com Mon Mar 2 01:58:20 2015 From: johnl at iecc.com (John R. Levine) Date: 1 Mar 2015 20:58:20 -0500 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: References: <20150301124846.GA16378@gsp.org> <20150301212550.27225.qmail@ary.lan> Message-ID: >> As I said above, retail customers. Business customers get static IPs and generaly no blocking. > Business customers only get static from Comcast if they pay extra for it. I'm in a T-W area, haven't checked Comcast's prices lately. But if you don't have a static IP, it's a poor idea to try to send mail directly since you're sharing your IP range with the usual array of botted Windows boxes and hacked Wordpress servers, so recipients are unlikely to accept it. R's, John From dave.taht at gmail.com Mon Mar 2 02:03:03 2015 From: dave.taht at gmail.com (Dave Taht) Date: Sun, 1 Mar 2015 18:03:03 -0800 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: References: <20150301124846.GA16378@gsp.org> <20150301212550.27225.qmail@ary.lan> Message-ID: On Sun, Mar 1, 2015 at 5:53 PM, Owen DeLong wrote: > >> On Mar 1, 2015, at 14:01 , John R. Levine wrote: >> >>>>>> Well, actually, it does. Every broadband network in the US >>>>>> currently blocks outgoing port 25 connections from retail customers. >>>>> >>>>> Unfortunately, that's not entirely true. (Very) recent direct-to-MX spam >>>>> from Comcast customers: >>>> >>>> Well, it's supposed to be blocked, according to people I've talked to >>>> at Comcast and T-W as recently as a week ago. I can believe that they >>>> have configuration problems on a networks of that size. >>> >>> fairly certain that none of these folk block port 25 on their business >>> customer links. >> >> As I said above, retail customers. Business customers get static IPs and generaly no blocking. >> >> R's, >> John > > Business customers only get static from Comcast if they pay extra for it. I still keep hoping for some way to buy an ipv6/48 from them. Being dynamically renumbered all the time is a PITA, and yet, when comcast's ipv6 works - it is GREAT. I had huge amounts of nat pressure from dns traffic simply vanish once I switched my dns servers over to their ipv6 (and deployed dnssec and got back NXDOMAIN) > > Owen > -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb From owen at delong.com Mon Mar 2 02:01:19 2015 From: owen at delong.com (Owen DeLong) Date: Sun, 1 Mar 2015 18:01:19 -0800 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: References: <20150301124846.GA16378@gsp.org> <20150301212550.27225.qmail@ary.lan> Message-ID: > On Mar 1, 2015, at 17:58 , John R. Levine wrote: > >>> As I said above, retail customers. Business customers get static IPs and generaly no blocking. > >> Business customers only get static from Comcast if they pay extra for it. > > I'm in a T-W area, haven't checked Comcast's prices lately. But if you don't have a static IP, it's a poor idea to try to send mail directly since you're sharing your IP range with the usual array of botted Windows boxes and hacked Wordpress servers, so recipients are unlikely to accept it. > > R's, > John I don’t disagree. I use static IPs, I just don’t get them from Comcast. I use Comcast as an L2 substrate for my GRE tunnels where I run BGP with my real providers. Owen From joelja at bogus.com Mon Mar 2 02:14:01 2015 From: joelja at bogus.com (joel jaeggli) Date: Sun, 01 Mar 2015 18:14:01 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> <54F33AB5.3040208@foobar.org> Message-ID: <54F3C769.5020203@bogus.com> On 3/1/15 1:26 PM, Owen DeLong wrote: >>> It was the combination of asymmetric, no or few IPs (and NAT), and >>> bandwidth caps. >> >> let's not rewrite history here: IPv4 address scarcity has been a thing >> since the very early 1990s. Otherwise why would cidr have been created? > > CIDR had nothing to do with address scarcity. CIDR was invented for routing > table slot scarcity in Cisco AGS hardware of the era. nope sorry, both are justifications... https://tools.ietf.org/html/rfc1519#page-6 There are not according to 1993 era RFC's, enough class B and A networks to go around... (there still aren't) We were around then and we got the patch. > Routers running out of BGP table space wasn’t just a fear at the time, it was > a real problem on a number of networks, including, but not limited to SPRINT > and MCI who were the big dogs in the fight at the time. your cisco ags+ wasn't going to make it over the hump. > NAT, OTOH, is an address conservation mechanism which has unfortunately > of late been mistaken for a security tool. If only people would realize how much > NAT negatively impacts security, manageability, etc. > > Owen > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From list at satchell.net Mon Mar 2 03:05:41 2015 From: list at satchell.net (Stephen Satchell) Date: Sun, 01 Mar 2015 19:05:41 -0800 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: References: <20150301124846.GA16378@gsp.org> <20150301212550.27225.qmail@ary.lan> Message-ID: <54F3D385.9010106@satchell.net> On 03/01/2015 01:44 PM, Christopher Morrow wrote: > fairly certain that none of these folk block port 25 on their business > customer links. Correct as far as Charter goes. Particularly for people with dedicated IP addresses, as I do. I can't speak for DHCP address space. From joelja at bogus.com Mon Mar 2 03:14:05 2015 From: joelja at bogus.com (joel jaeggli) Date: Sun, 01 Mar 2015 19:14:05 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F32F1A.9090201@meetinghouse.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> <54F31DBE.9060603@meetinghouse.net> <54F32F1A.9090201@meetinghouse.net> Message-ID: <54F3D57D.7050201@bogus.com> On 3/1/15 7:24 AM, Miles Fidelman wrote: > Scott, > > Asymmetric measured where? Between client and server or between > servers? I'm thinking the case where we each have a server running > locally - how do you get a high level of asymmetry in a P2P environment? The most densly connected relays by definition have more outgoing than incoming given the nature of a protocol where messages are flooded by senders. this is widely reflected in freenix 1000 rankings. http://top1000.anthologeek.net/ likewise if you are and edge you will undoubtedly receive more than you originate. > Miles Fidelman > > > > Scott Helms wrote: >> >> Anything based on NNTP would be extremely asymmetric without >> significant changes to the protocol or human behavior. >> >> We ran significant Usenet servers with binaries for nearly 20 years >> and without for another 5 and the servers' traffic was heavily >> asymmetric. >> >> On Mar 1, 2015 9:11 AM, "Miles Fidelman" > > wrote: >> >> Aled Morris wrote: >> >> >> Sadly we don't have many "killer applications" for symmetric >> residential >> bandwidth, but that's likely because we don't have the >> infrastructure to >> incubate these applications. >> >> >> Come to think of it, if USENET software wasn't so cumbersome, I >> kind of wonder if today's "social network" would consist of home >> servers running NNTP - and I expect the traffic would be very >> symmetric. (For that matter, with a few tweaks, the USENET model >> would be great for "groupware" - anybody remember the Netscape >> communications server that added private newsgroups and >> authentication to the mix?) >> >> Miles Fidelman >> >> >> >> -- In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From list at satchell.net Mon Mar 2 03:22:50 2015 From: list at satchell.net (Stephen Satchell) Date: Sun, 01 Mar 2015 19:22:50 -0800 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: References: <20150301124846.GA16378@gsp.org> <20150301212550.27225.qmail@ary.lan> Message-ID: <54F3D78A.5080009@satchell.net> On 03/01/2015 05:53 PM, Owen DeLong wrote: > Business customers only get static from Comcast if they pay extra for it. That's also true for Charter. I know of one ISP offering DSL that gives its customers static addresses. Only one. That doesn't mean there aren't more that do. From ml-nanog at techcompute.net Mon Mar 2 01:22:51 2015 From: ml-nanog at techcompute.net (Lewis,Mitchell T.) Date: Sun, 1 Mar 2015 17:22:51 -0800 (PST) Subject: Charter/Comcast Enginner-Contact In-Reply-To: <28408652.35.1425259188962.JavaMail.mtlewis@INTELNUC> Message-ID: <16341025.40.1425259318171.JavaMail.mtlewis@INTELNUC> Any Charter or Comcast Network Folks out there, I would appreciate a contact off-list. I am in the charter new england territory to be transferred to comcast & am seeing unusual network issues. Thanks, Mitchell T. Lewis Mlewis at Techcompute.Net LinkedIn Profile: www.linkedin.com/in/mlewiscc Mobile: (203)816-0371 A computer will do what you tell it to do, but that may be much different from what you had in mind. ~Joseph Weizenbaum From ml-nanog at techcompute.net Mon Mar 2 02:25:41 2015 From: ml-nanog at techcompute.net (Lewis,Mitchell T.) Date: Sun, 1 Mar 2015 18:25:41 -0800 (PST) Subject: Charter/Comcast Enginner-Contact In-Reply-To: <16341025.40.1425259318171.JavaMail.mtlewis@INTELNUC> References: <16341025.40.1425259318171.JavaMail.mtlewis@INTELNUC> Message-ID: <1525385.82.1425263088194.JavaMail.mtlewis@INTELNUC> Any Charter or Comcast Network Folks out there? I would appreciate a contact off-list. I am in the charter new england territory to be transferred to comcast & am seeing unusual network issues. Thanks, Mitchell T. Lewis Mlewis at Techcompute.Net LinkedIn Profile: www.linkedin.com/in/mlewiscc Mobile: (203)816-0371 A computer will do what you tell it to do, but that may be much different from what you had in mind. ~Joseph Weizenbaum From johnl at iecc.com Mon Mar 2 04:49:28 2015 From: johnl at iecc.com (John Levine) Date: 2 Mar 2015 04:49:28 -0000 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: <54F3D78A.5080009@satchell.net> Message-ID: <20150302044928.35324.qmail@ary.lan> In article <54F3D78A.5080009 at satchell.net> you write: >On 03/01/2015 05:53 PM, Owen DeLong wrote: >> Business customers only get static from Comcast if they pay extra for it. > >That's also true for Charter. I know of one ISP offering DSL that gives >its customers static addresses. Only one. That doesn't mean there >aren't more that do. The tiny telco owned DSL ISP here gives you a static IP if you call them up and ask for one. Otherwise you're double-NAT-ed. I switched to cable since their top speed was 6 megabits, even through I'm two blocks from the CO. They said I can have fiber if I pay for them to string it from the CO to my house. Uh, no. R's, John From r.engehausen at gmail.com Mon Mar 2 05:38:52 2015 From: r.engehausen at gmail.com (Roy) Date: Sun, 01 Mar 2015 21:38:52 -0800 Subject: Charter/Comcast Enginner-Contact In-Reply-To: <1525385.82.1425263088194.JavaMail.mtlewis@INTELNUC> References: <16341025.40.1425259318171.JavaMail.mtlewis@INTELNUC> <1525385.82.1425263088194.JavaMail.mtlewis@INTELNUC> Message-ID: <54F3F76C.6010405@gmail.com> The Charter engineers are all working on their IPV6 migration and have been for at least three years now :-( .On 3/1/2015 6:25 PM, Lewis,Mitchell T. wrote: > > Any Charter or Comcast Network Folks out there? I would appreciate a contact off-list. I am in the charter new england territory to be transferred to comcast & am seeing unusual network issues. > > > Thanks, > > > > > > > > Mitchell T. Lewis > Mlewis at Techcompute.Net > LinkedIn Profile: www.linkedin.com/in/mlewiscc > Mobile: (203)816-0371 > > A computer will do what you tell it to do, but that may be much different from what you had in mind. ~Joseph Weizenbaum > > From rsk at gsp.org Mon Mar 2 11:39:46 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 2 Mar 2015 06:39:46 -0500 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: References: <54F0E159.2000804@satchell.net> <20150227233223.18612.qmail@ary.lan> <20150301124846.GA16378@gsp.org> Message-ID: <20150302113946.GB4153@gsp.org> On Sun, Mar 01, 2015 at 11:58:34AM -0500, Christopher Morrow wrote: > business vs consumer edition products? (that'd be my bet) I think these are all residential customers, as business customers appear to use different subdomains and/or host naming conventions, e.g.: 24.7.48.153 c-24-7-48-153.hsd1.ca.comcast.net 24.10.217.142 c-24-10-217-142.hsd1.ut.comcast.net 24.129.85.220 c-24-129-85-220.hsd1.fl.comcast.net vs. 70.88.25.201 70-88-25-201-chesterfield-va.hfc.comcastbusiness.net 70.90.158.37 70-90-158-37-knoxville.hfc.comcastbusiness.net 70.91.133.105 70-91-133-105-ma-ne.hfc.comcastbusiness.net Or: 23.240.176.98 cpe-23-240-176-98.socal.res.rr.com 24.25.253.81 cpe-24-25-253-81.hawaii.res.rr.com 24.27.121.156 cpe-24-27-121-156.tx.res.rr.com vs. 24.106.98.106 rrcs-24-106-98-106.central.biz.rr.com 24.142.142.169 rrcs-24-142-142-169.central.biz.rr.com 24.173.100.134 rrcs-24-173-100-134.sw.biz.rr.com Those are all (very recent) direct-to-MX on port 25 spam sources, but it looks to me like the first group in each set is residential and the second group is business. But perhaps I'm misinterpreting the naming. ---rsk From dtaylor at vocalabs.com Mon Mar 2 13:56:31 2015 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Mon, 02 Mar 2015 07:56:31 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> Message-ID: <54F46C0F.3060702@vocalabs.com> Personally? If the price were the same, I'd go with 50/50. That way my uploads would take even less time. It isn't about the averaged total, it's about how long each event takes, and backing up 4GB of files off-site shouldn't have to take an hour. On 02/27/2015 03:11 PM, Scott Helms wrote: > Daniel, > > > "50MB/s might be tough to fill, but even at home I can get good use > out of the odd 25MB/s upstream burst for a few minutes." > > Which would you choose, 50/50 or 75/25? My point is not that upstream > speed isn't valuable, but merely that demand for it isn't symmetrical > and unless the market changes won't be in the near term. Downstream > demand is growing, in most markets I can see, much faster than > upstream demand. > > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > -- Daniel Taylor VP Operations Vocal Laboratories, Inc. dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 From dtaylor at vocalabs.com Mon Mar 2 14:04:32 2015 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Mon, 02 Mar 2015 08:04:32 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725E3EC@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <9578293AE169674F9A048B2BC9A081B4015725E3EC@MUNPRDMBXA1.medline.com> Message-ID: <54F46DF0.3040904@vocalabs.com> On 02/27/2015 04:49 PM, Naslund, Steve wrote: > On Fri, Feb 27, 2015 at 3:53 PM, Scott Helms wrote: >> "My point is that the option should be there, at the consumer level." >> >> Why? What's magical about symmetry? Is a customer better served by >> having a 5mbps/5mbps over a 25mbps/5mbps? > If the option sells, it will be offered. It didn't. We offer symmetric DLS residentially and it went over like a lead balloon. > > Most people don't know what having a faster upstream would get them (symmetrical or not). Heck, most people only know that they got the cheapest connection with the fastest top-line bandwidth number because marketers don't know how to sell upstream bandwidth (or don't care to). -- Daniel Taylor VP Operations Vocal Laboratories, Inc. dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 From khelms at zcorum.com Mon Mar 2 14:09:46 2015 From: khelms at zcorum.com (Scott Helms) Date: Mon, 2 Mar 2015 09:09:46 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F46C0F.3060702@vocalabs.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <54F46C0F.3060702@vocalabs.com> Message-ID: That's not the norm for consumers, but the important thing to understand is that for most of the technologies we use for broadband there simply is less upstream capacity than downstream. That upstream scarcity means that for DSL, DOCSIS, PON, WiFi, and LTE delivering symmetrical upstream bandwidth will cost the service provider more which means at some point it will cost consumers more. WiFi is a special case, while there is no theoretical reason it must be asymmetrical but it works that way in practice because dedicated APs invariably have both higher transmit power and much better antenna gain. The average AP in the US will put out a watt or more while clients are putting out ~250 milliwatts and with 0 antenna gain. On Mar 2, 2015 8:58 AM, "Daniel Taylor" wrote: > Personally? > If the price were the same, I'd go with 50/50. > > That way my uploads would take even less time. > > It isn't about the averaged total, it's about how long each event takes, > and backing up 4GB of files off-site shouldn't have to take an hour. > > On 02/27/2015 03:11 PM, Scott Helms wrote: > >> Daniel, >> >> >> "50MB/s might be tough to fill, but even at home I can get good use out >> of the odd 25MB/s upstream burst for a few minutes." >> >> Which would you choose, 50/50 or 75/25? My point is not that upstream >> speed isn't valuable, but merely that demand for it isn't symmetrical and >> unless the market changes won't be in the near term. Downstream demand is >> growing, in most markets I can see, much faster than upstream demand. >> >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> > > -- > Daniel Taylor VP Operations Vocal Laboratories, Inc. > dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 > > From dtaylor at vocalabs.com Mon Mar 2 14:22:11 2015 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Mon, 02 Mar 2015 08:22:11 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <54F46C0F.3060702@vocalabs.com> Message-ID: <54F47213.5010004@vocalabs.com> I'm clearly not a normal user, or I wouldn't be here. Normal users have never experienced high-speed symmetrical service. People don't miss what they have never had. On 03/02/2015 08:09 AM, Scott Helms wrote: > > That's not the norm for consumers, but the important thing to > understand is that for most of the technologies we use for broadband > there simply is less upstream capacity than downstream. That upstream > scarcity means that for DSL, DOCSIS, PON, WiFi, and LTE delivering > symmetrical upstream bandwidth will cost the service provider more > which means at some point it will cost consumers more. > > WiFi is a special case, while there is no theoretical reason it must > be asymmetrical but it works that way in practice because dedicated > APs invariably have both higher transmit power and much better antenna > gain. The average AP in the US will put out a watt or more while > clients are putting out ~250 milliwatts and with 0 antenna gain. > > On Mar 2, 2015 8:58 AM, "Daniel Taylor" > wrote: > > Personally? > If the price were the same, I'd go with 50/50. > > That way my uploads would take even less time. > > It isn't about the averaged total, it's about how long each event > takes, and backing up 4GB of files off-site shouldn't have to take > an hour. > > On 02/27/2015 03:11 PM, Scott Helms wrote: > > Daniel, > > > "50MB/s might be tough to fill, but even at home I can get > good use out of the odd 25MB/s upstream burst for a few minutes." > > Which would you choose, 50/50 or 75/25? My point is not that > upstream speed isn't valuable, but merely that demand for it > isn't symmetrical and unless the market changes won't be in > the near term. Downstream demand is growing, in most markets > I can see, much faster than upstream demand. > > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > > -- > Daniel Taylor VP Operations Vocal > Laboratories, Inc. > dtaylor at vocalabs.com > http://www.vocalabs.com/ (612)235-5711 > -- Daniel Taylor VP Operations Vocal Laboratories, Inc. dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 From Jason_Livingood at cable.comcast.com Mon Mar 2 14:22:08 2015 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Mon, 2 Mar 2015 14:22:08 +0000 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: <20150302113946.GB4153@gsp.org> References: <54F0E159.2000804@satchell.net> <20150227233223.18612.qmail@ary.lan> <20150301124846.GA16378@gsp.org> <20150302113946.GB4153@gsp.org> Message-ID: Hostnaming is not always straightforward, as there are variations of commercial service (some with static IPs, others with dynamic, some enterprise, branch office, SMB, etc.). FWIW: 24.7.48.153 c-24-7-48-153.hsd1.ca.comcast.net 24.10.217.142 c-24-10-217-142.hsd1.ut.comcast.net 24.129.85.220 c-24-129-85-220.hsd1.fl.comcast.net Are all SMB customers. -Jason On 3/2/15, 6:39 AM, "Rich Kulawiec" wrote: >On Sun, Mar 01, 2015 at 11:58:34AM -0500, Christopher Morrow wrote: >> business vs consumer edition products? (that'd be my bet) > >I think these are all residential customers, as business customers >appear to use different subdomains and/or host naming conventions, e.g.: > > 24.7.48.153 c-24-7-48-153.hsd1.ca.comcast.net > 24.10.217.142 c-24-10-217-142.hsd1.ut.comcast.net > 24.129.85.220 c-24-129-85-220.hsd1.fl.comcast.net >vs. > 70.88.25.201 70-88-25-201-chesterfield-va.hfc.comcastbusiness.net > 70.90.158.37 70-90-158-37-knoxville.hfc.comcastbusiness.net > 70.91.133.105 70-91-133-105-ma-ne.hfc.comcastbusiness.net > >Or: > 23.240.176.98 cpe-23-240-176-98.socal.res.rr.com > 24.25.253.81 cpe-24-25-253-81.hawaii.res.rr.com > 24.27.121.156 cpe-24-27-121-156.tx.res.rr.com >vs. > 24.106.98.106 rrcs-24-106-98-106.central.biz.rr.com > 24.142.142.169 rrcs-24-142-142-169.central.biz.rr.com > 24.173.100.134 rrcs-24-173-100-134.sw.biz.rr.com > >Those are all (very recent) direct-to-MX on port 25 spam sources, but it >looks to me like the first group in each set is residential and the second >group is business. But perhaps I'm misinterpreting the naming. > >---rsk From list at satchell.net Mon Mar 2 14:40:44 2015 From: list at satchell.net (Stephen Satchell) Date: Mon, 02 Mar 2015 06:40:44 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F47213.5010004@vocalabs.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <54F46C0F.3060702@vocalabs.com> <54F47213.5010004@vocalabs.com> Message-ID: <54F4766C.3080104@satchell.net> On 03/02/2015 06:22 AM, Daniel Taylor wrote: > I'm clearly not a normal user, or I wouldn't be here. > Normal users have never experienced high-speed symmetrical service. > > People don't miss what they have never had. I would agree with that statement in a slightly modified form: "People don't miss what they never had with their home Internet." At work, the story can be different because a business may well be spending the bucks for symmetrical service, or the applications in the business never go off-site. From khelms at zcorum.com Mon Mar 2 14:41:30 2015 From: khelms at zcorum.com (Scott Helms) Date: Mon, 2 Mar 2015 09:41:30 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F47213.5010004@vocalabs.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <54F46C0F.3060702@vocalabs.com> <54F47213.5010004@vocalabs.com> Message-ID: Daniel, For the third or fourth time in this discussion we are tracking and customer satisfaction for users who do have symmetrical bandwidth >24 mbps and have for a number of years. We see customer usage patterns and satisfaction being statically the same on 25/25 and 25/8 accounts. The same is true when we look at 50/50 versus 50/12 accounts. On Mar 2, 2015 9:22 AM, "Daniel Taylor" wrote: > I'm clearly not a normal user, or I wouldn't be here. > Normal users have never experienced high-speed symmetrical service. > > People don't miss what they have never had. > > On 03/02/2015 08:09 AM, Scott Helms wrote: > >> >> That's not the norm for consumers, but the important thing to understand >> is that for most of the technologies we use for broadband there simply is >> less upstream capacity than downstream. That upstream scarcity means that >> for DSL, DOCSIS, PON, WiFi, and LTE delivering symmetrical upstream >> bandwidth will cost the service provider more which means at some point it >> will cost consumers more. >> >> WiFi is a special case, while there is no theoretical reason it must be >> asymmetrical but it works that way in practice because dedicated APs >> invariably have both higher transmit power and much better antenna gain. >> The average AP in the US will put out a watt or more while clients are >> putting out ~250 milliwatts and with 0 antenna gain. >> >> On Mar 2, 2015 8:58 AM, "Daniel Taylor" > dtaylor at vocalabs.com>> wrote: >> >> Personally? >> If the price were the same, I'd go with 50/50. >> >> That way my uploads would take even less time. >> >> It isn't about the averaged total, it's about how long each event >> takes, and backing up 4GB of files off-site shouldn't have to take >> an hour. >> >> On 02/27/2015 03:11 PM, Scott Helms wrote: >> >> Daniel, >> >> >> "50MB/s might be tough to fill, but even at home I can get >> good use out of the odd 25MB/s upstream burst for a few minutes." >> >> Which would you choose, 50/50 or 75/25? My point is not that >> upstream speed isn't valuable, but merely that demand for it >> isn't symmetrical and unless the market changes won't be in >> the near term. Downstream demand is growing, in most markets >> I can see, much faster than upstream demand. >> >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> >> >> -- Daniel Taylor VP Operations Vocal >> Laboratories, Inc. >> dtaylor at vocalabs.com >> http://www.vocalabs.com/ (612)235-5711 >> >> > > -- > Daniel Taylor VP Operations Vocal Laboratories, Inc. > dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 > > From dtaylor at vocalabs.com Mon Mar 2 14:59:40 2015 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Mon, 02 Mar 2015 08:59:40 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <54F46C0F.3060702@vocalabs.com> <54F47213.5010004@vocalabs.com> Message-ID: <54F47ADC.7030805@vocalabs.com> What do those 25 and 50Mb/s download rates amount to in practice? Statistically speaking, those might *be* symmetric. On 03/02/2015 08:41 AM, Scott Helms wrote: > > Daniel, > For the third or fourth time in this discussion we are tracking and > customer satisfaction for users who do have symmetrical bandwidth >24 > mbps and have for a number of years. > > We see customer usage patterns and satisfaction being statically the > same on 25/25 and 25/8 accounts. The same is true when we look at > 50/50 versus 50/12 accounts. > > On Mar 2, 2015 9:22 AM, "Daniel Taylor" > wrote: > > I'm clearly not a normal user, or I wouldn't be here. > Normal users have never experienced high-speed symmetrical service. > > People don't miss what they have never had. > > On 03/02/2015 08:09 AM, Scott Helms wrote: > > > That's not the norm for consumers, but the important thing to > understand is that for most of the technologies we use for > broadband there simply is less upstream capacity than > downstream. That upstream scarcity means that for DSL, > DOCSIS, PON, WiFi, and LTE delivering symmetrical upstream > bandwidth will cost the service provider more which means at > some point it will cost consumers more. > > WiFi is a special case, while there is no theoretical reason > it must be asymmetrical but it works that way in practice > because dedicated APs invariably have both higher transmit > power and much better antenna gain. The average AP in the US > will put out a watt or more while clients are putting out ~250 > milliwatts and with 0 antenna gain. > > On Mar 2, 2015 8:58 AM, "Daniel Taylor" >> wrote: > > Personally? > If the price were the same, I'd go with 50/50. > > That way my uploads would take even less time. > > It isn't about the averaged total, it's about how long > each event > takes, and backing up 4GB of files off-site shouldn't have > to take > an hour. > > On 02/27/2015 03:11 PM, Scott Helms wrote: > > Daniel, > > > "50MB/s might be tough to fill, but even at home I can get > good use out of the odd 25MB/s upstream burst for a > few minutes." > > Which would you choose, 50/50 or 75/25? My point is > not that > upstream speed isn't valuable, but merely that demand > for it > isn't symmetrical and unless the market changes won't > be in > the near term. Downstream demand is growing, in most > markets > I can see, much faster than upstream demand. > > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > > -- Daniel Taylor VP Operations Vocal > Laboratories, Inc. > dtaylor at vocalabs.com > > > http://www.vocalabs.com/ (612)235-5711 > > > > > -- > Daniel Taylor VP Operations Vocal > Laboratories, Inc. > dtaylor at vocalabs.com > http://www.vocalabs.com/ (612)235-5711 > -- Daniel Taylor VP Operations Vocal Laboratories, Inc. dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 From khelms at zcorum.com Mon Mar 2 15:06:34 2015 From: khelms at zcorum.com (Scott Helms) Date: Mon, 2 Mar 2015 10:06:34 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F47ADC.7030805@vocalabs.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <54F46C0F.3060702@vocalabs.com> <54F47213.5010004@vocalabs.com> <54F47ADC.7030805@vocalabs.com> Message-ID: Daniel, The sold speeds are all actually less than the actual speeds. The PON customers are slightly over provisioned and the DOCSIS customers are over provisioned a bit more. On Mar 2, 2015 10:01 AM, "Daniel Taylor" wrote: > What do those 25 and 50Mb/s download rates amount to in practice? > > Statistically speaking, those might *be* symmetric. > > On 03/02/2015 08:41 AM, Scott Helms wrote: > >> >> Daniel, >> For the third or fourth time in this discussion we are tracking and >> customer satisfaction for users who do have symmetrical bandwidth >24 mbps >> and have for a number of years. >> >> We see customer usage patterns and satisfaction being statically the same >> on 25/25 and 25/8 accounts. The same is true when we look at 50/50 versus >> 50/12 accounts. >> >> On Mar 2, 2015 9:22 AM, "Daniel Taylor" > dtaylor at vocalabs.com>> wrote: >> >> I'm clearly not a normal user, or I wouldn't be here. >> Normal users have never experienced high-speed symmetrical service. >> >> People don't miss what they have never had. >> >> On 03/02/2015 08:09 AM, Scott Helms wrote: >> >> >> That's not the norm for consumers, but the important thing to >> understand is that for most of the technologies we use for >> broadband there simply is less upstream capacity than >> downstream. That upstream scarcity means that for DSL, >> DOCSIS, PON, WiFi, and LTE delivering symmetrical upstream >> bandwidth will cost the service provider more which means at >> some point it will cost consumers more. >> >> WiFi is a special case, while there is no theoretical reason >> it must be asymmetrical but it works that way in practice >> because dedicated APs invariably have both higher transmit >> power and much better antenna gain. The average AP in the US >> will put out a watt or more while clients are putting out ~250 >> milliwatts and with 0 antenna gain. >> >> On Mar 2, 2015 8:58 AM, "Daniel Taylor" > > >> wrote: >> >> Personally? >> If the price were the same, I'd go with 50/50. >> >> That way my uploads would take even less time. >> >> It isn't about the averaged total, it's about how long >> each event >> takes, and backing up 4GB of files off-site shouldn't have >> to take >> an hour. >> >> On 02/27/2015 03:11 PM, Scott Helms wrote: >> >> Daniel, >> >> >> "50MB/s might be tough to fill, but even at home I can get >> good use out of the odd 25MB/s upstream burst for a >> few minutes." >> >> Which would you choose, 50/50 or 75/25? My point is >> not that >> upstream speed isn't valuable, but merely that demand >> for it >> isn't symmetrical and unless the market changes won't >> be in >> the near term. Downstream demand is growing, in most >> markets >> I can see, much faster than upstream demand. >> >> >> >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> >> >> -- Daniel Taylor VP Operations Vocal >> Laboratories, Inc. >> dtaylor at vocalabs.com >> > >> http://www.vocalabs.com/ (612)235-5711 >> >> >> >> >> -- Daniel Taylor VP Operations Vocal >> Laboratories, Inc. >> dtaylor at vocalabs.com >> http://www.vocalabs.com/ (612)235-5711 >> >> > > -- > Daniel Taylor VP Operations Vocal Laboratories, Inc. > dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 > > From dtaylor at vocalabs.com Mon Mar 2 15:16:19 2015 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Mon, 02 Mar 2015 09:16:19 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <54F46C0F.3060702@vocalabs.com> <54F47213.5010004@vocalabs.com> <54F47ADC.7030805@vocalabs.com> Message-ID: <54F47EC3.2010009@vocalabs.com> My apologies for the implication. I meant that on the Internet as a whole it is unusual for such speeds to actually be realized in practice due to various issues. 8-10Mb/s seems to be what one can expect without going to distributed protocols. On 03/02/2015 09:06 AM, Scott Helms wrote: > > Daniel, > > The sold speeds are all actually less than the actual speeds. The PON > customers are slightly over provisioned and the DOCSIS customers are > over provisioned a bit more. > > On Mar 2, 2015 10:01 AM, "Daniel Taylor" > wrote: > > What do those 25 and 50Mb/s download rates amount to in practice? > > Statistically speaking, those might *be* symmetric. > > On 03/02/2015 08:41 AM, Scott Helms wrote: > > > Daniel, > For the third or fourth time in this discussion we are > tracking and customer satisfaction for users who do have > symmetrical bandwidth >24 mbps and have for a number of years. > > We see customer usage patterns and satisfaction being > statically the same on 25/25 and 25/8 accounts. The same is > true when we look at 50/50 versus 50/12 accounts. > > On Mar 2, 2015 9:22 AM, "Daniel Taylor" >> wrote: > > I'm clearly not a normal user, or I wouldn't be here. > Normal users have never experienced high-speed symmetrical > service. > > People don't miss what they have never had. > > On 03/02/2015 08:09 AM, Scott Helms wrote: > > > That's not the norm for consumers, but the important > thing to > understand is that for most of the technologies we use for > broadband there simply is less upstream capacity than > downstream. That upstream scarcity means that for DSL, > DOCSIS, PON, WiFi, and LTE delivering symmetrical upstream > bandwidth will cost the service provider more which > means at > some point it will cost consumers more. > > WiFi is a special case, while there is no theoretical > reason > it must be asymmetrical but it works that way in practice > because dedicated APs invariably have both higher transmit > power and much better antenna gain. The average AP in > the US > will put out a watt or more while clients are putting > out ~250 > milliwatts and with 0 antenna gain. > > On Mar 2, 2015 8:58 AM, "Daniel Taylor" > > > > >>> wrote: > > Personally? > If the price were the same, I'd go with 50/50. > > That way my uploads would take even less time. > > It isn't about the averaged total, it's about how long > each event > takes, and backing up 4GB of files off-site > shouldn't have > to take > an hour. > > On 02/27/2015 03:11 PM, Scott Helms wrote: > > Daniel, > > > "50MB/s might be tough to fill, but even at > home I can get > good use out of the odd 25MB/s upstream burst > for a > few minutes." > > Which would you choose, 50/50 or 75/25? My > point is > not that > upstream speed isn't valuable, but merely that > demand > for it > isn't symmetrical and unless the market > changes won't > be in > the near term. Downstream demand is growing, > in most > markets > I can see, much faster than upstream demand. > > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > > > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > > -- Daniel Taylor VP Operations Vocal > Laboratories, Inc. > dtaylor at vocalabs.com > > > >> > http://www.vocalabs.com/ (612)235-5711 > > > > > > -- Daniel Taylor VP Operations Vocal > Laboratories, Inc. > dtaylor at vocalabs.com > > > http://www.vocalabs.com/ (612)235-5711 > > > > > -- > Daniel Taylor VP Operations Vocal > Laboratories, Inc. > dtaylor at vocalabs.com > http://www.vocalabs.com/ (612)235-5711 > -- Daniel Taylor VP Operations Vocal Laboratories, Inc. dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 From aledm at qix.co.uk Mon Mar 2 15:17:33 2015 From: aledm at qix.co.uk (Aled Morris) Date: Mon, 2 Mar 2015 15:17:33 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <54F46C0F.3060702@vocalabs.com> <54F47213.5010004@vocalabs.com> Message-ID: On 2 March 2015 at 14:41, Scott Helms wrote: > We see customer usage patterns and satisfaction being statically the same > on 25/25 and 25/8 accounts. The same is true when we look at 50/50 versus > 50/12 accounts. perhaps because there are no widely-deployed applications that are designed with the expectation of reasonable upstream bandwidth. Average users haven't got into the mindset that they can use lots of upstream (because mainly, they can't.) Without really knowing what they could have, they're happy with what they've got. You've asked them if they're happy with the eggs, and in finding they were, declared nobody wanted for chicken. Aled From nanog at ics-il.net Mon Mar 2 15:23:46 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 2 Mar 2015 09:23:46 -0600 (CST) Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: Message-ID: <21897572.3227.1425309852474.JavaMail.mhammett@ThunderFuck> Your point has been made here many times as has mine. There's enough upstream available on enough carriers that if there were some big upload unicorn out there waiting to be harnessed... they'd be able to do it. All that the consumer has ever had that could benefit is P2P and offsite backup. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Aled Morris" To: "Scott Helms" Cc: "NANOG" Sent: Monday, March 2, 2015 9:17:33 AM Subject: Re: Verizon Policy Statement on Net Neutrality On 2 March 2015 at 14:41, Scott Helms wrote: > We see customer usage patterns and satisfaction being statically the same > on 25/25 and 25/8 accounts. The same is true when we look at 50/50 versus > 50/12 accounts. perhaps because there are no widely-deployed applications that are designed with the expectation of reasonable upstream bandwidth. Average users haven't got into the mindset that they can use lots of upstream (because mainly, they can't.) Without really knowing what they could have, they're happy with what they've got. You've asked them if they're happy with the eggs, and in finding they were, declared nobody wanted for chicken. Aled From khelms at zcorum.com Mon Mar 2 15:28:15 2015 From: khelms at zcorum.com (Scott Helms) Date: Mon, 2 Mar 2015 10:28:15 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <54F46C0F.3060702@vocalabs.com> <54F47213.5010004@vocalabs.com> Message-ID: That's certainly true and why we watch the trends of usage very closely and we project those terms into the future knowing that's imperfect. What we won't do is build networks based purely on guesses. We certainly see demand for upstream capacity increasing for residential customers, but that increase is slower than the increase in downstream demand growth. In all cases but pure greenfield situations the cost of deploying DSL or DOCSIS is significant less than deploying fiber. Even in greenfield situations PON, which is a asynchronous itself, is much less expensive than active Ethernet. In short synchronous connections cost more to deploy. Doing so without a knowing if or when consumers will actually pay for synchronous connections isn't something we're going to do. From josh.rogers at twcable.com Mon Mar 2 15:57:25 2015 From: josh.rogers at twcable.com (Rogers, Josh) Date: Mon, 2 Mar 2015 10:57:25 -0500 Subject: Verizon Policy Statement on Net Neutrality Message-ID: Correct. For those (who don¹tt already know) that are interested in learning about this, do some reading on Diplex Filters (http://en.wikipedia.org/wiki/Diplexer), which are used to ³split² the RF spectrum apart so that the lower portion and the higher portion can be amplified independently, before recombining the two portions. I believe this was done to accomplish unity gain in each direction independently. Also, I¹d like to note that there have been a few comments in this thread that lead me to believe some folks are confusing asymmetrical routing paths with asymmetrical speeds. Don¹t confuse the two as they have nearly nothing to do with one another. -Josh On 3/2/15, 6:00 AM, "nanog-request at nanog.org" wrote: >------------------------------ > >Message: 3 >Date: Sun, 1 Mar 2015 08:08:27 -0500 >From: Clayton Zekelman >To: Barry Shein >Cc: NANOG >Subject: Re: Verizon Policy Statement on Net Neutrality >Message-ID: <32D3C16D-0F4D-45BA-99F8-D41FE23D472C at mnsi.net> >Content-Type: text/plain; charset=us-ascii > >Yes, so when cable modems were introduced to the network, they had to be >designed to work on the EXISTING infrastructure which was designed to >deliver cable TV. It's not some conspiracy to differentiate higher priced >business services - it was a fact of RF technology and the architecture >of the network they were overlaying this "new" service on top of. > > > >Sent from my iPhone > >>On Feb 28, 2015, at 10:28 PM, Barry Shein wrote: >>>On February 28, 2015 at 18:14 clayton at mnsi.net (Clayton Zekelman) wrote: >>>You do of course realize that the asymmetry in CATV forward path/return >>>path existed LONG before residential Internet access over cable >>>networks exited? >>You mean back when it was all analog and DOCSIS didn't exist? >>>Sent from my iPhone >>>>On Feb 28, 2015, at 5:38 PM, Barry Shein wrote: >>>>Can we stop the disingenuity? >>>>Asymmetric service was introduced to discourage home users from >>>>deploying "commercial" services. As were bandwidth caps. >>>>One can argue all sorts of other "benefits" of this but when this >>>>started that was the problem on the table: How do we forcibly >>>>distinguish commercial (i.e., more expensive) from non-commercial >>>>usage? >>>>Answer: Give them a lot less upload than download bandwidth. >>>>Originally these asymmetric, typically DSL, links were hundreds of >>>>kbits upstream, not a lot more than a dial-up line. >>>>That and NAT thereby making it difficult -- not impossible, the savvy >>>>were in the noise -- to map domain names to permanent IP addresses. >>>>That's all this was about. >>>>It's not about "that's all they need", "that's all they want", etc. >>>>Now that bandwidth is growing rapidly and asymmetric is often >>>>10/50mbps or 20/100 it almost seems nonsensical in that regard, entire >>>>medium-sized ISPs ran on less than 10mbps symmetric not long ago. But >>>>it still imposes an upper bound of sorts, along with addressing >>>>limitations and bandwidth caps. >>>>That's all this is about. >>>>The telcos for many decades distinguished "business" voice service >>>>from "residential" service, even for just one phone line, though they >>>>mostly just winged it and if they declared you were defrauding them by >>>>using a residential line for a business they might shut you off and/or >>>>back bill you. Residential was quite a bit cheaper, most importantly >>>>local "unlimited" (unmetered) talk was only available on residential >>>>lines. Business lines were even coded 1MB (one m b) service, one >>>>metered business (line). >>>>The history is clear and they've just reinvented the model for >>>>internet but proactively enforced by technology rather than studying >>>>your usage patterns or whatever they used to do, scan for business ads >>>>using "residential" numbers, beyond bandwidth usage analysis. >>>>And the CATV companies are trying to reinvent CATV pricing for >>>>internet, turn Netflix (e.g.) into an analogue of HBO and other >>>>premium CATV services. >>>>What's so difficult to understand here? >>>>-- >>>> -Barry Shein >>>>The World | bzs at TheWorld.com | >>>>http://www.TheWorld.com >>>>Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, >>>>Canada >>>>Software Tool & Die | Public Access Internet | SINCE 1989 >>>>*oo* >>-- >> -Barry Shein >>The World | bzs at TheWorld.com | >>http://www.TheWorld.com >>Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, >>Canada >>Software Tool & Die | Public Access Internet | SINCE 1989 *oo* > 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 SNaslund at medline.com Mon Mar 2 16:10:30 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 2 Mar 2015 16:10:30 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <27896791.814.1425163775749.JavaMail.mhammett@ThunderFuck> References: <21746.17258.270398.162820@world.std.com> <27896791.814.1425163775749.JavaMail.mhammett@ThunderFuck> Message-ID: <9578293AE169674F9A048B2BC9A081B4015725FC81@MUNPRDMBXA1.medline.com> >Can we stop the disingenuity? > >Asymmetric service was introduced to discourage home users from deploying "commercial" services. As were bandwidth caps. > >One can argue all sorts of other "benefits" of this but when this started that was the problem on the table: How do we forcibly distinguish commercial (i.e., more expensive) from non-commercial usage? > >Answer: Give them a lot less upload than download bandwidth. Not true. Asymmetric service was a response to users wanting more downstream bandwidth and willing to give up bandwidth upstream. It's simple math. A copper media supports so much bandwidth period. You can have that bandwidth in any direction you want and the users wanted it downstream. In our case at InterAccess Chicago, we offered SDSL to both residential and business customers. The distinction between business class and residential service was that business class came with public static addresses where that was an optional extra on residential service. There was also a acceptable usage agreement on the residential side about hosting high bandwidth commercial servers (which was not enforced unless an aggregious case occurred. It just turns out that most residential users found ADSL a better fit for what they did and I think in most cases that is still true. > >Originally these asymmetric, typically DSL, links were hundreds of kbits upstream, not a lot more than a dial-up line. > >That and NAT thereby making it difficult -- not impossible, the savvy were in the noise -- to map domain names to permanent IP addresses. > Wrong again, the DSL was much faster than a dial up from the beginning. The original offering was SDSL with speeds ranging from about 128 kbit to 1.5 mbps which were much faster than any modem ever available. The other compelling thing about DSL was that it was an "always on" service that did not require you to have a phone line or ISDN line from the phone company that you paid for in addition to your ISP services. At the time, an ISDN circuit cost about $40 a month and there was about a 5 cent charge every time you dialed up a B channel. In our area there was not a per minute charge so it was to your advantage to leave your B channels nailed up. I remember customers running up thousands of dollars in calls when they misconfigured their equipment to dial on demand and racked up tons of calls. We originally offered SDSL at $80 per month at whatever speed we could get that line to run at (typically between 512K and 1.5 mbps) which was quite a bargin compared to the ISDN is replaced. Our focus was businesses but we offered residential service as well at $60 per month with private addresses. If I remember right, public IP addresses were a $10 a month option so you would hit the business price if you had more than two of them. As far as block services to residential users. We did block some ports toward the user to protect them from themselves. Especially port 25. Open mail relay was a huge issue back then so we default blocked it for residential users, however if you called support and asked it to be unblocked, we would give you the open relay caution and open it for you. If you spammed the world, you got dumped as a customer. In those days reputation matters and we tried to be good Internet cops when it came to abuse. When ADSL was originally offered we avoided it because most of our customers were businesses but we started losing business on the residential side because people would rather have the downstream bandwidth increase of the ADSL service. That is when we started offering the ADSL service targeted at residential users. We would have preferred doing all SDSL because then we would not have to dedicate card slots in the DSLAMs to two different services. It would have been much more efficient to be able to utilize every port on every slot rather than tie a card up with just a couple users. We did not really care which sold except that there is much less churn in business users so cost of provisioning is overall lower. The DSLAM backhaul was shared ATM circuits so the traffic was not any different to us other than the residential users hitting a NAT. If you wanted static addresses, they were always available. Free with business class service and an additional cost per public IP on the residential side. We had no problem with people having a web server at home on a residential service as long as it was not a huge commercial bandwidth hog. We adjusted the pricing of speeds and public address space in a way that made it more cost effective to buy the right service based on how you used the service. We really tried not to get into the business of policing the residential vs business class for three main reasons. 1. It was hard to do. Very labor intensive to try to monitor traffic. 2. The geeks beating up the residential service are also the early adopters and can be advocates for you if you don't pick on them. 3. Who cares? The businesses kept us busy during the day and the residential kept us busy at night. The backhaul from the CO is not the issue, it is the cost of the upstream services which we have to buy on a 24/7 basis. > >That's all this was about. > >It's not about "that's all they need", "that's all they want", etc. Of course it is. Anyone who was an ISP knows that their customers were all about download speeds and whomever could offer the fastest downloads for the lowest price wins the customer. Since the dawn of the ISP, it has been about download speed as the user's number one priority. Anyone remember the modem wars (the competing 56k standards)? It was all about speed and still is. In my opinion, there are only four factors that make an ISP successful at selling customers or not. SPEED, COST, RELIABILITY, REACH. In that order. Speed they see every day, all day. Cost they see once a month. Reliability is something they don't think about until they have an outage. Reach allows you to service a customer or not, it also allows you to achieve an economy of scale where you can make money. > >Now that bandwidth is growing rapidly and asymmetric is often 10/50mbps or 20/100 it almost seems nonsensical in that regard, entire medium-sized ISPs ran on less than 10mbps symmetric not long ago. But it still imposes an upper >bound of sorts, along with addressing limitations and bandwidth caps. Of course there are upper bounds. The point is that to make the upper bound as painless to the user as possible. I happen to hate NAT but most users just don't care about it or even know what it is. I have yet to see a service provider advertise that they offer the fastest UPSTREAM bandwidth of any other provider. That tells me that the average user just does not care. I don't believe for a minute that traffic is becoming more symmetric. For every new social media site or backup service, there is a new streaming media provider in pro sports or a new video technology (like 4K or even 8K UHDTV) service that just crushes any upstream you can come up with. Do you really believe that users creating content will EVER come close to the explosion that UHDTV with create in the opposite direction? > >That's all this is about. > >The telcos for many decades distinguished "business" voice service from "residential" service, even for just one phone line, though they mostly just winged it and if they declared you were defrauding them by using a residential line >for a business they might shut you off and/or back bill you. Residential was quite a bit cheaper, most importantly local "unlimited" (unmetered) talk was only available on residential lines. Business lines were even coded 1MB (one m >b) service, one metered business (line). Are we talking about phones or Internet service here? Business and residential phone service are different tariffs. Residential tariffs and business tariffs are priced differently because the State utility boards try to keep residential service cheap as possible and use the business side service to subsidize the residential users. Telcos were not early in offering Internet services. Their early offerings were ISDN, Switched 56, and T-1 service. All of those services did not offer "Internet" service. They acted as a data pipe that you or your service provider leased to get your premise to your ISP. The Telco could not have cared less what data you pushed over the line which was really a point-to-point pipe. In fact, early ISPs gamed the Telcos a bit since we were using ISDN services and phone lines in ways that they were never intended to be used. Keeping an ISDN circuit nailed up 24/7 for a usage charge of 10 cents per month (5 cents per B channel call) was not what was they expected and we know the phone network was not designed with people nailing up phone lines 24/7 with data calls. Once the LECs started getting into the Internet business, they had to find a way to fit their services into the existing tariff structure. Not because they wanted to but because the State commissions required them to do so. If you think it took the LECs a long time to react to the Internet, it took the States even longer. When we became a CLEC to offer DSL services, we had to publish a tariff which the State pretty much ignored completely. When Ameritech (begot SBC, begot AT&T again) publishes a tariff it is a huge political football that everyone wants to play with. Here is a synopsis of ISP vs LEC history. ADSL kind of forced the tariff issue since they were running data service over an existing phone line that was already tariffed meaning the service had to be tariffed as well. 1. First we hosed them by nailing their phone lines and ISDN circuits 24/7 and they LECs lost a ton on it. 2. They hosed us by making it almost impossible to access the copper infrastructure. 3. The telecom act allowed us to hose them back by giving us access to a large amount of the LEC infrastructure with little or no capital investment in their construction. DSL exploded. So did the number of ISPs competing for the same customers. Some owned their own equipment and backbone. Lots of others bought access from wholesalers are were nothing more than marketing and sales engines. 4. The ISPs ate each other up in a race to the bottom trying to offer DSL service for $9.95 a month (remember Northpoint wholesaling DSL service to anyone wanting to call themselves an ISP). 5. The LEC finally got a clue and together with the cable providers killed off the traditional ISP by offering the same services over their existing infrastructure with less overhead. Steven Naslund Chicago IL From lowen at pari.edu Mon Mar 2 16:28:08 2015 From: lowen at pari.edu (Lamar Owen) Date: Mon, 2 Mar 2015 11:28:08 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <20150228224632.CB39B2A930D4@rock.dv.isc.org> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> Message-ID: <54F48F98.9060906@pari.edu> On 02/28/2015 05:46 PM, Mark Andrews wrote: > Home users should be able to upload a content in the same amount > of time it takes to download content. This. Once a week I upload a 100MB+ MP3 (that I produced myself, and for which I own the copyright) to a cloud server. I have a reasonable ADSL circuit at home, but it takes quite a bit of my time to upload that one file. Even if the average BW was throttled to 512k, it would be really nice to have 7Mb/s up for just a minute or ten so I can shut the machine down and go to bed. Cloud services are becoming the choice for all kinds of content distribution, and there are more content creators out there than you might think who need to do exactly what I need to do. Yes, I do remember the days of dialup, in particular I remember the quite interesting business model of free.org, which dramatically reduced my long distance bill that I had been paying to dial up Eskimo North (I'm in the Southeast US, incidentally). And then we got dialup locally, and my old Okidata 9600 modem got a workout. And, well, I still use my connection in much the same way as I used dialup, turning it off when I'm not using it. I almost never leave it up all night; if my router isn't online it can't be used for malicious purposes, etc. And, no, I have no alternatives to the ILEC's DSL here, as 3G/4G cell service simply doesn't get to my house (now on the ridge behind my house, great 4G bandwidth, but I'm down in a valley, and the shadowing algorithm's show the story; I ran a Splat simulation from the cell tower site; across the creek from my house is the edge of one of the diffraction zones where good service can be found, and my house is in a deep null....) Thanks all for the interesting symmetry discussion; this has been enjoyable. From lowen at pari.edu Mon Mar 2 16:40:32 2015 From: lowen at pari.edu (Lamar Owen) Date: Mon, 2 Mar 2015 11:40:32 -0500 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: References: <54F0E159.2000804@satchell.net> Message-ID: <54F49280.903@pari.edu> On 02/28/2015 07:33 PM, Jimmy Hess wrote: > On Sat, Feb 28, 2015 at 8:34 AM, John R. Levine wrote: > [...] >> Until yesterday, there were no network neutrality rules, not for spam or for >> anything else. > There still aren't any network neutrality rules, until the FCC makes > the documents public, which they haven't yet. > The rules themselves are public. The area of uncertainty is whether the Report and Order will pull in more rules than just the newly published 47CFR§8. For instance, there's 47CFR§6 which deal with 'telecommunications' carriers and the ADA. But as far as net neutrality is concerned, the actual rules dealing with the gist of it are embodied in 47CFR§8 "Preserving the Open Internet." Link to the eCFR page on it was posted elsewhere on the list. From SNaslund at medline.com Mon Mar 2 17:00:28 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 2 Mar 2015 17:00:28 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <20150228.094712.1305952464703391341.wwaites@tardis.ed.ac.uk> References: <9578293AE169674F9A048B2BC9A081B4015725DE22@MUNPRDMBXA1.medline.com> <20150227.193238.315861968627315258.wwaites@tardis.ed.ac.uk> <9578293AE169674F9A048B2BC9A081B4015725E5B0@MUNPRDMBXA1.medline.com> <20150228.094712.1305952464703391341.wwaites@tardis.ed.ac.uk> Message-ID: <9578293AE169674F9A048B2BC9A081B4015725FE57@MUNPRDMBXA1.medline.com> >> I was an ISP in the 1990s and our first DSL offerings were SDSL >> symmetric services to replace more expensive T-1 circuits. When >> we got into residential it was with SDSL and then the consumers >> wanted more downstream so ADSL was invented. I was there, I >> know this. >So was I and my experience was different. We decided that it would be more profitable as a small ISP to re-sell Bell Canada's ADSL than to try to unbundle central offices all over the place. The arguments from the business side had >nothing whatsoever to do with symmetry or lack thereof. The choice of technology was entirely by the ILEC. What I am trying to tell you is that Bell Canada was way behind the curve in deployment to DSL technology. I am coming to you from the perspective of a guy who designed and built DSL networks not a reseller. By the time the LEC started selling you ADSL, the market had already spoken and ADSL was the customer's choice. The LECs looked at what us facilities based ISPs deployed and decided to start reselling the same thing. If they had the demand to resell SDSL, they would have (and they do, it is called a clear channel DS-1 port). It just makes no difference to them, a loop and a port is just a loop and a port. >> To that I will just say that if your average user spend as much >> time videoconferencing as they do watching streaming media then >> they are probably a business. >No, you misunderstand. I don't dispute that the area under end-user traffic statistics graphs is asymmetric. But that the maximum value -- particularly the instantaneous maximum value which you don't see with five minute sampling -- >wants to be quite a lot higher than it can be with a very asymmetric circuit. If someone works from home one day a week and has a videoconference or too, we still want that to work well, right? The bottom line is that you have to tell me how much downstream speed you want to give up to get more upstream speed. If you don't want that then you are just telling me you want more overall speed which is a different argument. Videoconferencing is a red herring argument because it is also asymmetric in most cases and the bandwidth of a videoconference does not even come close to that of a movie download where quality matters more than lag. >And perfect symmetry is not necessary. Would I notice the difference between 60/60 and 60/40 or even 60/20? Probably not really as long as both numbers are significantly more than the expected peak rate. But 24/1.5, a factor of 16, >is a very different story. If you don't like the up to down ratio, I get it. The problem is you either need more intelligent networks to automatically set this ratio based on usage (which is not actually easy, remember RSVP anyone?) or you have to try to please most of the people most of the time which is how it works today. Steven Naslund Chicago IL From SNaslund at medline.com Mon Mar 2 17:20:53 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 2 Mar 2015 17:20:53 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F14868.7040903@mtcc.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <6C2AD229-D571-4220-8D7B-F2F8CC119185@consultant.com> <9578293AE169674F9A048B2BC9A081B4015725E400@MUNPRDMBXA1.medline.com> <54F14868.7040903@mtcc.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4015725FFBC@MUNPRDMBXA1.medline.com> >Average != Peak. > What is peak? There is a question for you. If we get all the way down to the fundamentals of any network, peak is always 100%. There is either a bit on the wire or not. Your network is either 100% busy or 100% idle at any instantaneous moment in time. What matters is average transfer rate to the user experience and even that varies a lot depending on the app in question and how that app tolerates things like jitter, loss, and latency. It is about whether data is being buffered waiting for a transmission window and is the buffer being cleared as fast as it is being filled. A network is engineered to support some average levels because it would be very cost ineffective to engineer a wide area network to support peak transmission on all ports at all times. All studies of network traffic show that it is not necessary to build a network that way. Our networks are statistical multiplexers in their design and have been all the way back to the Bell System. You do know that not everyone can make a phone call at once, right (but who would you call if everyone was already off hook, get it?)? In fact, it is such a difficult problem that it is very hard to support inside a single data center class Ethernet switch. In the wide area, it would be incredibly expensive to design an entirely non-blocking network at all traffic levels. It could be built if you want to pay for it however. >Why is this so hard to understand? > >Mike Steven Naslund Chicago IL From mike at mtcc.com Mon Mar 2 17:32:59 2015 From: mike at mtcc.com (Michael Thomas) Date: Mon, 02 Mar 2015 09:32:59 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725FFBC@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <6C2AD229-D571-4220-8D7B-F2F8CC119185@consultant.com> <9578293AE169674F9A048B2BC9A081B4015725E400@MUNPRDMBXA1.medline.com> <54F14868.7040903@mtcc.com> <9578293AE169674F9A048B2BC9A081B4015725FFBC@MUNPRDMBXA1.medline.com> Message-ID: <54F49ECB.4020902@mtcc.com> On 03/02/2015 09:20 AM, Naslund, Steve wrote: >> Average != Peak. >> > What is peak? There is a question for you. If we get all the way down to the fundamentals of any network, peak is always 100%. There is either a bit on the wire or not. Your network is either 100% busy or 100% idle at any instantaneous moment in time. What matters is average transfer rate to the user experience and even that varies a lot depending on the app in question and how that app tolerates things like jitter, loss, and latency. It is about whether data is being buffered waiting for a transmission window and is the buffer being cleared as fast as it is being filled. A network is engineered to support some average levels because it would be very cost ineffective to engineer a wide area network to support peak transmission on all ports at all times. All studies of network traffic show that it is not necessary to build a network that way. Our networks are statistical multiplexers in their design and have been all the way back to the Bell System. You do know that not everyone can make a phone call at once, right (but who would you call if everyone was already off hook, get it?)? In fact, it is such a difficult problem that it is very hard to support inside a single data center class Ethernet switch. In the wide area, it would be incredibly expensive to design an entirely non-blocking network at all traffic levels. It could be built if you want to pay for it however. > ::AWOOOOGAAAA:: Strawman Alert! Nobody's talking about taking poor Erlang behind the barn and shooting him. We're talking about being able to send upstream at a reasonable/comparable rate as downstream. Mike From SNaslund at medline.com Mon Mar 2 17:33:49 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 2 Mar 2015 17:33:49 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725E66E@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0B0D8.9080904@paradoxnetworks.net> <9578293AE169674F9A048B2BC9A081B4015725E66E@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B4015726000F@MUNPRDMBXA1.medline.com> > >It is likely not to change when people don't have the available upload to begin with. This is compounded by the queue problems on end devices. >How many more people would stream to twitch or youtube or skype if they didn't have to hear this, "Are you uploading? You're slowing down the download! I can't >watch my movie!" >Jack These are not people a service provider can help because obviously these people don't know what they are talking about. My conversation would go more like this: Q. Your Hypothetical Poor User - "Are you uploading? You're slowing down the download! I can't watch my movie!" A. Me - "Hey genius, why don't you download a movie about networks because my upload does not affect your streaming movie download except for the insignificant amount of control traffic in the opposite direction." Steven Naslund Chicago IL From ops.lists at gmail.com Mon Mar 2 17:37:29 2015 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 2 Mar 2015 23:07:29 +0530 Subject: Large Ontario DC busted for hosting petabytes of child abuse material Message-ID: 18 million dollars revenue in three months so certainly pretty large sized. Any idea which DC this is? http://motherboard.vice.com/en_ca/read/police-could-charge-a-data-center-in-the-largest-child-porn-bust-ever From SNaslund at medline.com Mon Mar 2 17:45:17 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 2 Mar 2015 17:45:17 +0000 Subject: Verizon Policy Statement on Net Neutrality References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <6C2AD229-D571-4220-8D7B-F2F8CC119185@consultant.com> <9578293AE169674F9A048B2BC9A081B4015725E400@MUNPRDMBXA1.medline.com> <54F14868.7040903@mtcc.com> <9578293AE169674F9A048B2BC9A081B4015725FFBC@MUNPRDMBXA1.medline.com> <54F49ECB.4020902@mtcc.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40157260058@MUNPRDMBXA1.medline.com> > > >::AWOOOOGAAAA:: Strawman Alert! > >Nobody's talking about taking poor Erlang behind the barn and shooting him. > >We're talking about being able to send upstream at a reasonable/comparable rate as downstream. > > >Mike Exactly, now you see the dilemma. What is reasonable/comparable? Is it reasonable to assume that users upload as much as they download when every traffic study I have ever done or seen tells me that is not the case? Is it reasonable for me to allocate my customers to 5M down/5M up when they really mostly use 8.5 down/1.5 up? I know it would make you happy to build my network so that you can twiddle the upload/download dials but is it reasonable to make all of my customers pay for that infrastructure rather than ask you to buy a more premium business class service if you want that? Steven Naslund Chicago IL From SNaslund at medline.com Mon Mar 2 17:53:33 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 2 Mar 2015 17:53:33 +0000 Subject: Large Ontario DC busted for hosting petabytes of child abuse material In-Reply-To: References: Message-ID: <9578293AE169674F9A048B2BC9A081B4015726006F@MUNPRDMBXA1.medline.com> Don't know who this is but the legalities are pretty clear I think. The DC is not required to know what data is stored but if the cops can prove that someone DID know what was stored, that person can be criminally charged. IANAL but I have worked with LE on a similar case and that is how it was explained to us by the FBI. It will be hard to prove anyone knew however since anyone that knew and did not report it committed a crime. Charging the company will be a stretch unless they can prove that at least one corporate officer knew. Otherwise the company will fire whichever employee knew and say "He should have told us". This is all about who knew what and when. Steven Naslund Chicago IL > >18 million dollars revenue in three months so certainly pretty large sized. > >Any idea which DC this is? > >http://motherboard.vice.com/en_ca/read/police-could-charge-a-data-center-in-the-largest-child-porn-bust-ever From mikea at mikea.ath.cx Mon Mar 2 18:03:02 2015 From: mikea at mikea.ath.cx (Mike A) Date: Mon, 2 Mar 2015 12:03:02 -0600 Subject: Large Ontario DC busted for hosting petabytes of child abuse material In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015726006F@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B4015726006F@MUNPRDMBXA1.medline.com> Message-ID: <20150302180302.GB94073@mikea.ath.cx> On Mon, Mar 02, 2015 at 05:53:33PM +0000, Naslund, Steve wrote: > Don't know who this is but the legalities are pretty clear I think. The DC > is not required to know what data is stored but if the cops can prove that > someone DID know what was stored, that person can be criminally charged. > IANAL but I have worked with LE on a similar case and that is how it was > explained to us by the FBI. It will be hard to prove anyone knew however > since anyone that knew and did not report it committed a crime. Charging the > company will be a stretch unless they can prove that at least one corporate > officer knew. Otherwise the company will fire whichever employee knew and > say "He should have told us". > > This is all about who knew what and when. True in the USA, I think; but what about Canadian law? Popcorn and hyperhumongous drinks time. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From mhuff at ox.com Mon Mar 2 18:03:22 2015 From: mhuff at ox.com (Matthew Huff) Date: Mon, 2 Mar 2015 18:03:22 +0000 Subject: Large Ontario DC busted for hosting petabytes of child abuse material In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015726006F@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B4015726006F@MUNPRDMBXA1.medline.com> Message-ID: <1c6ee78f6c1e400289fa7797f3ba647b@pur-vm-exch13n1.ox.com> Given the size and that the data is stored in encrypted RAR files, I wonder if they just busted a Usenet service provider rather than a P2P / file sharing site. ---- Matthew Huff             | 1 Manhattanville Rd Director of Operations   | Purchase, NY 10577 OTA Management LLC       | Phone: 914-460-4039 aim: matthewbhuff        | Fax:   914-694-5669 -----Original Message----- From: NANOG [mailto:nanog-bounces+mhuff=ox.com at nanog.org] On Behalf Of Naslund, Steve Sent: Monday, March 2, 2015 12:54 PM To: nanog at nanog.org Subject: RE: Large Ontario DC busted for hosting petabytes of child abuse material Don't know who this is but the legalities are pretty clear I think. The DC is not required to know what data is stored but if the cops can prove that someone DID know what was stored, that person can be criminally charged. IANAL but I have worked with LE on a similar case and that is how it was explained to us by the FBI. It will be hard to prove anyone knew however since anyone that knew and did not report it committed a crime. Charging the company will be a stretch unless they can prove that at least one corporate officer knew. Otherwise the company will fire whichever employee knew and say "He should have told us". This is all about who knew what and when. Steven Naslund Chicago IL > >18 million dollars revenue in three months so certainly pretty large sized. > >Any idea which DC this is? > >http://motherboard.vice.com/en_ca/read/police-could-charge-a-data-center-in-the-largest-child-porn-bust-ever From lists at mtin.net Mon Mar 2 18:04:11 2015 From: lists at mtin.net (Justin Wilson - MTIN) Date: Mon, 2 Mar 2015 13:04:11 -0500 Subject: Large Ontario DC busted for hosting petabytes of child abuse material In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015726006F@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B4015726006F@MUNPRDMBXA1.medline.com> Message-ID: Part of it depends on if the DC was doing managed services as well. If they are just a space tenant then their exposure can be limited. But if it was their servers that will be a little different. Not saying it would make the difference, but opens another avenue to be argued. To me it’s like going after the Landlord of a rental apartment if someone is busted for drugs. How much can be proven that they knew? How much can they interfere with their business? Justin Justin Wilson j2sw at mtin.net http://www.mtin.net Managed Services – xISP Solutions – Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering – Transit – Internet Exchange > On Mar 2, 2015, at 12:53 PM, Naslund, Steve wrote: > > Don't know who this is but the legalities are pretty clear I think. The DC is not required to know what data is stored but if the cops can prove that someone DID know what was stored, that person can be criminally charged. IANAL but I have worked with LE on a similar case and that is how it was explained to us by the FBI. It will be hard to prove anyone knew however since anyone that knew and did not report it committed a crime. Charging the company will be a stretch unless they can prove that at least one corporate officer knew. Otherwise the company will fire whichever employee knew and say "He should have told us". > > This is all about who knew what and when. > > > Steven Naslund > Chicago IL > >> >> 18 million dollars revenue in three months so certainly pretty large sized. >> >> Any idea which DC this is? >> >> http://motherboard.vice.com/en_ca/read/police-could-charge-a-data-center-in-the-largest-child-porn-bust-ever From deleskie at gmail.com Mon Mar 2 18:07:16 2015 From: deleskie at gmail.com (jim deleskie) Date: Mon, 2 Mar 2015 14:07:16 -0400 Subject: Large Ontario DC busted for hosting petabytes of child abuse material In-Reply-To: <20150302180302.GB94073@mikea.ath.cx> References: <9578293AE169674F9A048B2BC9A081B4015726006F@MUNPRDMBXA1.medline.com> <20150302180302.GB94073@mikea.ath.cx> Message-ID: Canadian and US laws are similar. But I'll leave it up to the lawyers to figure it all out, happily I'm no where near this, but it being a small industry here, I suspect I have friends that are dealing with some crap right now On Mon, Mar 2, 2015 at 2:03 PM, Mike A wrote: > On Mon, Mar 02, 2015 at 05:53:33PM +0000, Naslund, Steve wrote: > > Don't know who this is but the legalities are pretty clear I think. The > DC > > is not required to know what data is stored but if the cops can prove > that > > someone DID know what was stored, that person can be criminally charged. > > IANAL but I have worked with LE on a similar case and that is how it was > > explained to us by the FBI. It will be hard to prove anyone knew however > > since anyone that knew and did not report it committed a crime. Charging > the > > company will be a stretch unless they can prove that at least one > corporate > > officer knew. Otherwise the company will fire whichever employee knew and > > say "He should have told us". > > > > This is all about who knew what and when. > > True in the USA, I think; but what about Canadian law? > > Popcorn and hyperhumongous drinks time. > > -- > Mike Andrews, W5EGO > mikea at mikea.ath.cx > Tired old sysadmin > From SNaslund at medline.com Mon Mar 2 18:12:09 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 2 Mar 2015 18:12:09 +0000 Subject: Large Ontario DC busted for hosting petabytes of child abuse material In-Reply-To: <1c6ee78f6c1e400289fa7797f3ba647b@pur-vm-exch13n1.ox.com> References: <9578293AE169674F9A048B2BC9A081B4015726006F@MUNPRDMBXA1.medline.com> <1c6ee78f6c1e400289fa7797f3ba647b@pur-vm-exch13n1.ox.com> Message-ID: <9578293AE169674F9A048B2BC9A081B40157261596@MUNPRDMBXA1.medline.com> Here is what is going to hurt or help the cops case. "The volume of information is so expansive that in order to store and analyze the data safely and securely, police had to purchase storage hardware similar to what was used by Canadian military forces in Afghanistan. To access the files, many of which are password protected, the cops developed password-cracking software in-house that is slowly sifting through the mountain of information." The key there is that the data was protected. Did the datacenter control that protection and have access to the data or did their customer maintain that control? Certainly a data hosting service is not required (or perhaps even allowed) to crack passwords to see what you are storing on their servers. Steven Naslund Chicago IL > >18 million dollars revenue in three months so certainly pretty large sized. > >Any idea which DC this is? > >http://motherboard.vice.com/en_ca/read/police-could-charge-a-data-cente >r-in-the-largest-child-porn-bust-ever From landonstewart at gmail.com Mon Mar 2 18:21:41 2015 From: landonstewart at gmail.com (Landon Stewart) Date: Mon, 2 Mar 2015 10:21:41 -0800 Subject: Large Ontario DC busted for hosting petabytes of child abuse material In-Reply-To: <20150302180302.GB94073@mikea.ath.cx> References: <9578293AE169674F9A048B2BC9A081B4015726006F@MUNPRDMBXA1.medline.com> <20150302180302.GB94073@mikea.ath.cx> Message-ID: <11AFAF0E-C0EC-4832-ABD3-20D4D08F5915@gmail.com> On Mar 2, 2015, at 10:03 AM, Mike A wrote: > > On Mon, Mar 02, 2015 at 05:53:33PM +0000, Naslund, Steve wrote: >> Don't know who this is but the legalities are pretty clear I think. The DC >> is not required to know what data is stored but if the cops can prove that >> someone DID know what was stored, that person can be criminally charged. >> IANAL but I have worked with LE on a similar case and that is how it was >> explained to us by the FBI. It will be hard to prove anyone knew however >> since anyone that knew and did not report it committed a crime. Charging the >> company will be a stretch unless they can prove that at least one corporate >> officer knew. Otherwise the company will fire whichever employee knew and >> say "He should have told us". >> >> This is all about who knew what and when. > > True in the USA, I think; but what about Canadian law? AFAIK it's generally the same in Canada. If a provider is aware of (reported, accidental discovery or otherwise) the existence of child pornography on their network that existence must be reported to LE and the content must be cease to be publicly available. What I've done in the past when such a report is received is created an archive of the whole directory and subdirectories in question, collected all the customer data related to the account including logs of logins and file transfers and sent that directly to law enforcement and through https://www.cybertip.ca/ . Some information for Canadian service providers is in the reporting system itself: https://www.cybertip.ca/app/en/service_provider_report -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From johnl at iecc.com Mon Mar 2 18:22:06 2015 From: johnl at iecc.com (John Levine) Date: 2 Mar 2015 18:22:06 -0000 Subject: Large Ontario DC busted for hosting petabytes of child abuse material In-Reply-To: <1c6ee78f6c1e400289fa7797f3ba647b@pur-vm-exch13n1.ox.com> Message-ID: <20150302182206.38160.qmail@ary.lan> In article <1c6ee78f6c1e400289fa7797f3ba647b at pur-vm-exch13n1.ox.com> you write: >Given the size and that the data is stored in encrypted RAR files, I wonder if they >just busted a Usenet service provider rather than a P2P / file sharing site. Unlikely. There aren't that many large usenet providers, none of them are based in Canada, and they are hyper-aware that they don't want child abuse material on their servers. There aren't that many cloud providers physically located in Canada either, but I have no idea which one it is. R's, John From stephen at sprunk.org Mon Mar 2 18:27:53 2015 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 02 Mar 2015 12:27:53 -0600 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <21746.36263.888013.735298@world.std.com> References: <82748B6A-D6D7-4963-A749-47EF4D94DD8D@mnsi.net> <12510710.909.1425165605520.JavaMail.mhammett@ThunderFuck> <21746.36263.888013.735298@world.std.com> Message-ID: <54F4ABA9.9070000@sprunk.org> On 28-Feb-15 21:55, Barry Shein wrote: > On February 28, 2015 at 17:20 nanog at ics-il.net (Mike Hammett) wrote: >> As I said earlier, there are only so many channels available. >> Channels added to upload are taken away from download. People use >> upload so infrequently it would be gross negligence on the >> provider's behalf. > > And as I said earlier it's push/pull, give people lousy upload speeds > and they won't use services which depend on good upload speeds. > > And given lousy upload speeds the opportunities to develop for > example backup services in a world of terabyte disks is limited. At > 1mb/s it takes approx 100,000 seconds to upload 1TB, that's roughly > one week, blue sky. OTOH, there are clever tricks you can play to reduce this. For instance, hash all every file before uploading, and if the server has seen that hash before (from another user, or from a previous run by the same user), the server just adds the to your collection of files available to restore--no second upload required. Yes, if you're the first person to backup a new version of Windows or a new movie torrent, your upload time is going to suck, but on average, the time to upload each new file will be close to zero. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2394 bytes Desc: S/MIME Cryptographic Signature URL: From list at satchell.net Mon Mar 2 18:38:35 2015 From: list at satchell.net (Stephen Satchell) Date: Mon, 02 Mar 2015 10:38:35 -0800 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015726000F@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0B0D8.9080904@paradoxnetworks.net> <9578293AE169674F9A048B2BC9A081B4015725E66E@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B4015726000F@MUNPRDMBXA1.medline.com> Message-ID: <54F4AE2B.7080408@satchell.net> On 03/02/2015 09:33 AM, Naslund, Steve wrote: > A. Me - "Hey genius, why don't you download a movie about networks > because my upload does not affect your streaming movie download > except for the insignificant amount of control traffic in the > opposite direction." > Unless there is significant stupidly-done bufferbloat, where the "insignificant amount of control traffic in the opposite direction" is delayed because the big blocks of the upload are causing a traffic jam in the upstream pipe. From mfidelman at meetinghouse.net Mon Mar 2 18:42:48 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 02 Mar 2015 13:42:48 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B4015725FFBC@MUNPRDMBXA1.medline.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <6C2AD229-D571-4220-8D7B-F2F8CC119185@consultant.com> <9578293AE169674F9A048B2BC9A081B4015725E400@MUNPRDMBXA1.medline.com> <54F14868.7040903@mtcc.com> <9578293AE169674F9A048B2BC9A081B4015725FFBC@MUNPRDMBXA1.medline.com> Message-ID: <54F4AF28.3070808@meetinghouse.net> Naslund, Steve wrote: >> Average != Peak. >> > What is peak? There is a question for you. If we get all the way down to the fundamentals of any network, peak is always 100%. There is either a bit on the wire or not. Your network is either 100% busy or 100% idle at any instantaneous moment in time. What matters is average transfer rate to the user experience and even that varies a lot depending on the app in question and how that app tolerates things like jitter, loss, and latency. That's simply wrong - at least for folks who do any work related stuff at home. Consider: I've just edited a large sales presentation - say a PPT deck with some embedded video, totaling maybe 250MB (2gbit) - and I want to upload that to the company server. And let's say I want to do that 5 times during 12 hour day (it's crunch time, we're doing lots of edits). On average, we're talking 20gbit/12 hours, or a shade under 500kbps, if we're talking averages. On the other hand, if I try to push a 2gbit file through a 500kbps pipe, it's going to take 4000 seconds (67 minutes) -- that's rather painful, and inserts a LOT of delay in the process of getting reviews, comments, and doing the next round of edits. On the other hand, at 50mbps it takes only 40 seconds - annoying, but acceptable, and at a gig, it only takes 2 seconds. So, tell me, with a straight face, that "what matters is average transfer rate to the user experience." Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From fkittred at gwi.net Mon Mar 2 18:57:08 2015 From: fkittred at gwi.net (Fletcher Kittredge) Date: Mon, 2 Mar 2015 13:57:08 -0500 Subject: Symmetry, DSL, and all that Message-ID: Not a very informative discussion. Points of fact... >From Verizon's January filings regarding 2014Q4: 1. Verizon has about eight million FIOS customers. 2. "Fifty-nine percent of FiOS consumer Internet customers subscribed to data speeds of at least 50Mbps, up from 46 percent one year earlier." >From a Verizon press release last summer, all FIOS speeds are now symmetric. http://arstechnica.com/business/2014/07/verizon-fios-finally-symmetrical-upload-speeds-boosted-to-match-download/ ADSL development proceeded the development of the consumer Internet. The original patent was filed in 1988. DSL was designed originally to deliver video in an ISDN/ATM world. For that reason, it was asymmetric. -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From SNaslund at medline.com Mon Mar 2 18:59:16 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 2 Mar 2015 18:59:16 +0000 Subject: FW: Verizon Policy Statement on Net Neutrality Message-ID: <9578293AE169674F9A048B2BC9A081B40157261624@MUNPRDMBXA1.medline.com> >That's simply wrong - at least for folks who do any work related stuff at home. > >Consider: I've just edited a large sales presentation - say a PPT deck with some embedded video, totaling maybe 250MB (2gbit) - and I want to upload that to the company server. And let's say I want to do that 5 times during 12 >hour day (it's crunch time, we're doing lots of edits). BUSINESS CLASS SERVICE - You can get it but you have to pay for it. Also, not the average user's case. I know this. My support line does not ring with many (hardly any) people complaining about upload speed. Get over it, it is a provable fact. Is any service provider on here seeing this? > >On average, we're talking 20gbit/12 hours, or a shade under 500kbps, if we're talking averages. On the other hand, if I try to push a 2gbit file through a 500kbps pipe, it's going to take 4000 seconds (67 >minutes) -- that's rather painful, and inserts a LOT of delay in the process of getting reviews, comments, and doing the next round of edits. > >On the other hand, at 50mbps it takes only 40 seconds - annoying, but acceptable, and at a gig, it only takes 2 seconds. > Peak, average, whatever. Your local loop does not care. It does not have a "burst speed", it has a maximum transfer rate limited by the physics and electronics attached to it. You might want it to go faster and as a service provider I wish it would go faster because I would love to have lots of free bandwidth to sell you. If you want 50 mbps or 1 gbps on your ADSL circuit I can't help you at all. In fact, no one can because IT IS NOT POSSIBLE TODAY. If you want gig Ethernet service at home break out your checkbook (and a shovel). >So, tell me, with a straight face, that "what matters is average transfer rate to the user experience." > >Miles Fidelman Straight face on- The user cares if his average data rate meets his needs more than he cares if he has a high upload speed the once a month he needs that. If your bottom line argument is that you need more bandwidth for less cost, then welcome to everyone else's world. Steven Naslund Chicago IL From nanog at ics-il.net Mon Mar 2 19:00:04 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 2 Mar 2015 13:00:04 -0600 (CST) Subject: Symmetry, DSL, and all that In-Reply-To: Message-ID: <28319357.4010.1425322812560.JavaMail.mhammett@ThunderFuck> The backend is still symmetric. It's still something like 1.25 gigs up and 2.5 gigs down. You can only beat that going to AE. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Fletcher Kittredge" To: "NANOG list" Sent: Monday, March 2, 2015 12:57:08 PM Subject: Symmetry, DSL, and all that Not a very informative discussion. Points of fact... >From Verizon's January filings regarding 2014Q4: 1. Verizon has about eight million FIOS customers. 2. "Fifty-nine percent of FiOS consumer Internet customers subscribed to data speeds of at least 50Mbps, up from 46 percent one year earlier." >From a Verizon press release last summer, all FIOS speeds are now symmetric. http://arstechnica.com/business/2014/07/verizon-fios-finally-symmetrical-upload-speeds-boosted-to-match-download/ ADSL development proceeded the development of the consumer Internet. The original patent was filed in 1988. DSL was designed originally to deliver video in an ISDN/ATM world. For that reason, it was asymmetric. -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From nanog at ics-il.net Mon Mar 2 19:05:49 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 2 Mar 2015 13:05:49 -0600 (CST) Subject: Symmetry, DSL, and all that In-Reply-To: <28319357.4010.1425322812560.JavaMail.mhammett@ThunderFuck> Message-ID: <24281821.4034.1425323157283.JavaMail.mhammett@ThunderFuck> Damn A key... I mean asymmetric. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mike Hammett" To: "NANOG list" Sent: Monday, March 2, 2015 1:00:04 PM Subject: Re: Symmetry, DSL, and all that The backend is still symmetric. It's still something like 1.25 gigs up and 2.5 gigs down. You can only beat that going to AE. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Fletcher Kittredge" To: "NANOG list" Sent: Monday, March 2, 2015 12:57:08 PM Subject: Symmetry, DSL, and all that Not a very informative discussion. Points of fact... >From Verizon's January filings regarding 2014Q4: 1. Verizon has about eight million FIOS customers. 2. "Fifty-nine percent of FiOS consumer Internet customers subscribed to data speeds of at least 50Mbps, up from 46 percent one year earlier." >From a Verizon press release last summer, all FIOS speeds are now symmetric. http://arstechnica.com/business/2014/07/verizon-fios-finally-symmetrical-upload-speeds-boosted-to-match-download/ ADSL development proceeded the development of the consumer Internet. The original patent was filed in 1988. DSL was designed originally to deliver video in an ISDN/ATM world. For that reason, it was asymmetric. -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From SNaslund at medline.com Mon Mar 2 19:06:03 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 2 Mar 2015 19:06:03 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F4AE2B.7080408@satchell.net> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0B0D8.9080904@paradoxnetworks.net> <9578293AE169674F9A048B2BC9A081B4015725E66E@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B4015726000F@MUNPRDMBXA1.medline.com> <54F4AE2B.7080408@satchell.net> Message-ID: <9578293AE169674F9A048B2BC9A081B40157261649@MUNPRDMBXA1.medline.com> >Unless there is significant stupidly-done bufferbloat, where the "insignificant amount of control traffic in the opposite direction" is delayed because the big blocks of the upload are causing a traffic jam in the upstream pipe. Which has nothing at all to do with the asymmetry of the circuit at all. Buffer bloat is an issue in and of itself. I agree it can be an issue it just has nothing to do with the symmetry argument. In my opinion, it is just a reaction to customers who never want to see a packet lost but not understanding what the cost of that is. Steven Naslund Chicago IL From SNaslund at medline.com Mon Mar 2 19:19:29 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 2 Mar 2015 19:19:29 +0000 Subject: Symmetry, DSL, and all that In-Reply-To: <28319357.4010.1425322812560.JavaMail.mhammett@ThunderFuck> References: <28319357.4010.1425322812560.JavaMail.mhammett@ThunderFuck> Message-ID: <9578293AE169674F9A048B2BC9A081B40157261677@MUNPRDMBXA1.medline.com> >The backend is still symmetric. It's still something like 1.25 gigs up and 2.5 gigs down. You can only beat that going to AE. > > Truth is, once the user is achieving what they consider to be acceptable performance they don't care if it is symmetric or not. > > >Not a very informative discussion. > >Points of fact... > >From Verizon's January filings regarding 2014Q4: > >1. Verizon has about eight million FIOS customers. >2. "Fifty-nine percent of FiOS consumer Internet customers subscribed to data speeds of at least 50Mbps, up from 46 percent one year earlier." > Eight million FIOS customers does not even come close to representing the bulk of users out there. In fact, it does not even represent the majority of "high speed" customers out there. >From a Verizon press release last summer, all FIOS speeds are now symmetric. And no one cares. I don't even see Verizon commercials crowing about how great it is to have symmetry. If customers loved it that much don't you think they would market that way? > >http://arstechnica.com/business/2014/07/verizon-fios-finally-symmetrical-upload-speeds-boosted-to-match-download/ > >ADSL development proceeded the development of the consumer Internet. The original patent was filed in 1988. DSL was designed originally to deliver video in an ISDN/ATM world. For that reason, it was asymmetric. ADSL did not proceed the development of the consumer Internet in the commercial world. If it did, we would never have gone with dial-up modems. Patent dates have very little to do with commercial availability at all. Please give me an example of a purchasable service using ADSL prior to its use in Internet delivery. The number one reason ADSL succeeded and SDSL did not.....you could put an ADSL signal on the phone line you already had in your house, SDSL required a new loop to be ordered. Faster to provision and it can be done without a truck roll. Steven Naslund Chicago IL From nanog at ics-il.net Mon Mar 2 19:21:52 2015 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 2 Mar 2015 13:21:52 -0600 (CST) Subject: Symmetry, DSL, and all that In-Reply-To: <9578293AE169674F9A048B2BC9A081B40157261677@MUNPRDMBXA1.medline.com> Message-ID: <16693871.4074.1425324114866.JavaMail.mhammett@ThunderFuck> The most important point is yes, that no one cares. If people wanted it, it would be sold to them. End. of. story. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Steve Naslund" To: "Mike Hammett" , "NANOG list" Sent: Monday, March 2, 2015 1:19:29 PM Subject: RE: Symmetry, DSL, and all that >The backend is still symmetric. It's still something like 1.25 gigs up and 2.5 gigs down. You can only beat that going to AE. > > Truth is, once the user is achieving what they consider to be acceptable performance they don't care if it is symmetric or not. > > >Not a very informative discussion. > >Points of fact... > >From Verizon's January filings regarding 2014Q4: > >1. Verizon has about eight million FIOS customers. >2. "Fifty-nine percent of FiOS consumer Internet customers subscribed to data speeds of at least 50Mbps, up from 46 percent one year earlier." > Eight million FIOS customers does not even come close to representing the bulk of users out there. In fact, it does not even represent the majority of "high speed" customers out there. >From a Verizon press release last summer, all FIOS speeds are now symmetric. And no one cares. I don't even see Verizon commercials crowing about how great it is to have symmetry. If customers loved it that much don't you think they would market that way? > >http://arstechnica.com/business/2014/07/verizon-fios-finally-symmetrical-upload-speeds-boosted-to-match-download/ > >ADSL development proceeded the development of the consumer Internet. The original patent was filed in 1988. DSL was designed originally to deliver video in an ISDN/ATM world. For that reason, it was asymmetric. ADSL did not proceed the development of the consumer Internet in the commercial world. If it did, we would never have gone with dial-up modems. Patent dates have very little to do with commercial availability at all. Please give me an example of a purchasable service using ADSL prior to its use in Internet delivery. The number one reason ADSL succeeded and SDSL did not.....you could put an ADSL signal on the phone line you already had in your house, SDSL required a new loop to be ordered. Faster to provision and it can be done without a truck roll. Steven Naslund Chicago IL From sclark at netwolves.com Mon Mar 2 19:37:04 2015 From: sclark at netwolves.com (Steve Clark) Date: Mon, 02 Mar 2015 14:37:04 -0500 Subject: Symmetry, DSL, and all that In-Reply-To: <9578293AE169674F9A048B2BC9A081B40157261677@MUNPRDMBXA1.medline.com> References: <28319357.4010.1425322812560.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B40157261677@MUNPRDMBXA1.medline.com> Message-ID: <54F4BBE0.5020303@netwolves.com> On 03/02/2015 02:19 PM, Naslund, Steve wrote: >> The backend is still symmetric. It's still something like 1.25 gigs up and 2.5 gigs down. You can only beat that going to AE. >> >> > Truth is, once the user is achieving what they consider to be acceptable performance they don't care if it is symmetric or not. > >> >> Not a very informative discussion. >> >> Points of fact... >> > >From Verizon's January filings regarding 2014Q4: >> 1. Verizon has about eight million FIOS customers. >> 2. "Fifty-nine percent of FiOS consumer Internet customers subscribed to data speeds of at least 50Mbps, up from 46 percent one year earlier." >> > Eight million FIOS customers does not even come close to representing the bulk of users out there. In fact, it does not even represent the majority of "high speed" customers out there. > > >From a Verizon press release last summer, all FIOS speeds are now symmetric. > > And no one cares. I don't even see Verizon commercials crowing about how great it is to have symmetry. If customers loved it that much don't you think they would market that way? Hi Steve, I live in the Tampa Bay area and I see Verizon commercial all the time where other ISP customers are complaining that theirs ISP take so long to upload pictures, backups, etc. Plus there are commercial with people on an escalator where the up escalator is much slower than the down escalator and people are complaining up should be as fast as down. Regards, Steve > >> http://arstechnica.com/business/2014/07/verizon-fios-finally-symmetrical-upload-speeds-boosted-to-match-download/ >> >> ADSL development proceeded the development of the consumer Internet. The original patent was filed in 1988. DSL was designed originally to deliver video in an ISDN/ATM world. For that reason, it was asymmetric. > ADSL did not proceed the development of the consumer Internet in the commercial world. If it did, we would never have gone with dial-up modems. Patent dates have very little to do with commercial availability at all. Please give me an example of a purchasable service using ADSL prior to its use in Internet delivery. The number one reason ADSL succeeded and SDSL did not.....you could put an ADSL signal on the phone line you already had in your house, SDSL required a new loop to be ordered. Faster to provision and it can be done without a truck roll. > > Steven Naslund > Chicago IL > > > > -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com From fkittred at gwi.net Mon Mar 2 19:41:30 2015 From: fkittred at gwi.net (Fletcher Kittredge) Date: Mon, 2 Mar 2015 14:41:30 -0500 Subject: Symmetry, DSL, and all that In-Reply-To: <16693871.4074.1425324114866.JavaMail.mhammett@ThunderFuck> References: <9578293AE169674F9A048B2BC9A081B40157261677@MUNPRDMBXA1.medline.com> <16693871.4074.1425324114866.JavaMail.mhammett@ThunderFuck> Message-ID: On Mon, Mar 2, 2015 at 2:21 PM, Mike Hammett wrote: > The most important point is yes, that no one cares. If people wanted it, > it would be sold to them. End. of. story. I will repeat myself, speaking very slowly. Please see original message for citations. Verizon has eight million FIOS customers. As of last year, Verizon decided it was worth it to supply all of those customers with symmetric speeds. So, by your reasoning, people wanted it, so it was sold to them. Verizon is only one of many fiber-based ISPs selling symmetric speeds. From lists at mtin.net Mon Mar 2 20:03:19 2015 From: lists at mtin.net (Justin Wilson - MTIN) Date: Mon, 2 Mar 2015 15:03:19 -0500 Subject: Routing objects Message-ID: Anyone out there messed with routing objects lately that would care to let me bounce a few sanity check things off them? Maybe someone bored wanting to talk to a fellow geek on Skype or phone for a few minutes. Thanks, Justin Justin Wilson j2sw at mtin.net http://www.mtin.net Managed Services – xISP Solutions – Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering – Transit – Internet Exchange From mfidelman at meetinghouse.net Mon Mar 2 20:11:57 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 02 Mar 2015 15:11:57 -0500 Subject: FW: Verizon Policy Statement on Net Neutrality In-Reply-To: <9578293AE169674F9A048B2BC9A081B40157261624@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B40157261624@MUNPRDMBXA1.medline.com> Message-ID: <54F4C40D.7000203@meetinghouse.net> Naslund, Steve wrote: >> That's simply wrong - at least for folks who do any work related stuff at home. >> >> Consider: I've just edited a large sales presentation - say a PPT deck with some embedded video, totaling maybe 250MB (2gbit) - and I want to upload that to the company server. And let's say I want to do that 5 times during 12 >hour day (it's crunch time, we're doing lots of edits). > BUSINESS CLASS SERVICE - You can get it but you have to pay for it. Also, not the average user's case. I know this. My support line does not ring with many (hardly any) people complaining about upload speed. Get over it, it is a provable fact. Is any service provider on here seeing this? And that proves what? I expect people understand that large uploads take time, and don't call customer support to complain about something that comes with their grade of service. (Some of us DO, however call customer support when a promised 25mbps upload speed drops to 100kbps - which mine has been known to do - but that's something broken.) > >> On average, we're talking 20gbit/12 hours, or a shade under 500kbps, if we're talking averages. On the other hand, if I try to push a 2gbit file through a 500kbps pipe, it's going to take 4000 seconds (67 >> minutes) -- that's rather painful, and inserts a LOT of delay in the process of getting reviews, comments, and doing the next round of edits. >> >> On the other hand, at 50mbps it takes only 40 seconds - annoying, but acceptable, and at a gig, it only takes 2 seconds. >> > Peak, average, whatever. Your local loop does not care. It does not have a "burst speed", it has a maximum transfer rate limited by the physics and electronics attached to it. You might want it to go faster and as a service provider I wish it would go faster because I would love to have lots of free bandwidth to sell you. > > If you want 50 mbps or 1 gbps on your ADSL circuit I can't help you at all. In fact, no one can because IT IS NOT POSSIBLE TODAY. If you want gig Ethernet service at home break out your checkbook (and a shovel). Umm....... maximum transfer speed is also dependent on how many people you're sharing a channel with (can you say PON?) and the traffic characteristics of the folks you're sharing a link with. > >> So, tell me, with a straight face, that "what matters is average transfer rate to the user experience." >> >> Miles Fidelman > Straight face on- The user cares if his average data rate meets his needs more than he cares if he has a high upload speed the once a month he needs that. In my experience, you're absolutely wrong. People care most when something doesn't perform when they most need it. (By analogy, people suddenly find that they care a lot about how well there car accelerates, or brakes, primarily when they're trying to get out of a bad situation.) > > If your bottom line argument is that you need more bandwidth for less cost, then welcome to everyone else's world. > > No. My argument is that you're full of it when you equate peak with average performance. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mikea at mikea.ath.cx Mon Mar 2 20:14:04 2015 From: mikea at mikea.ath.cx (Mike A) Date: Mon, 2 Mar 2015 14:14:04 -0600 Subject: Symmetry, DSL, and all that In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B40157261677@MUNPRDMBXA1.medline.com> <16693871.4074.1425324114866.JavaMail.mhammett@ThunderFuck> Message-ID: <20150302201404.GC94073@mikea.ath.cx> On Mon, Mar 02, 2015 at 02:41:30PM -0500, Fletcher Kittredge wrote: > On Mon, Mar 2, 2015 at 2:21 PM, Mike Hammett wrote: > > > The most important point is yes, that no one cares. If people wanted it, > > it would be sold to them. End. of. story. > > > I will repeat myself, speaking very slowly. Please see original message for > citations. > > Verizon has eight million FIOS customers. As of last year, Verizon decided > it was worth it to supply all of those customers with symmetric speeds. So, > by your reasoning, people wanted it, so it was sold to them. > > Verizon is only one of many fiber-based ISPs selling symmetric speeds. What Fletcher Wrote, in spades. I will wager that most residential customers have never heard of symmetric speeds. I also will wager that they would like to be able to send large mail faster, upload to Yahoo! and other web hosting services faster, and so on. I know that *this* particular Cox Business customer would like faster uplink speeds, and doesn't see 20 MBps in either direction on the best days; since this is the threshold for "broadband" according to Uncle Charlie, Cox is not providing me "broadband" service. Before I got into this, I "owned" large to very large IBM mainframe computers. There *always* was latent demand for bigger and faster, much the same way an Interstate highway, on the day it is opened for service, is *always* over its design capacity immediately, on the day it is opened. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From owen at delong.com Mon Mar 2 20:20:37 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Mar 2015 12:20:37 -0800 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: <20150302113946.GB4153@gsp.org> References: <54F0E159.2000804@satchell.net> <20150227233223.18612.qmail@ary.lan> <20150301124846.GA16378@gsp.org> <20150302113946.GB4153@gsp.org> Message-ID: Not so sure about that… 240.59.103.76.in-addr.arpa. 7200 IN PTR c-76-103-59-240.hsd1.ca.comcast.net. is most definitely a business class service from Comcast. Seems to match the entry for 24.7.48.153 pretty closely. I think the difference is the type of cable network in the particular area. HFC is Hybrid Fiber Coax. The network in San Jose doesn’t really have any fiber, so it’s likely not an HFC network. I’m not sure what HSD stands for other than possibly “High Speed Data”, but I suspect it’s more likely some cable-specific term for an all-copper alternative to HFC. Owen > On Mar 2, 2015, at 03:39 , Rich Kulawiec wrote: > > On Sun, Mar 01, 2015 at 11:58:34AM -0500, Christopher Morrow wrote: >> business vs consumer edition products? (that'd be my bet) > > I think these are all residential customers, as business customers > appear to use different subdomains and/or host naming conventions, e.g.: > > 24.7.48.153 c-24-7-48-153.hsd1.ca.comcast.net > 24.10.217.142 c-24-10-217-142.hsd1.ut.comcast.net > 24.129.85.220 c-24-129-85-220.hsd1.fl.comcast.net > vs. > 70.88.25.201 70-88-25-201-chesterfield-va.hfc.comcastbusiness.net > 70.90.158.37 70-90-158-37-knoxville.hfc.comcastbusiness.net > 70.91.133.105 70-91-133-105-ma-ne.hfc.comcastbusiness.net > > Or: > 23.240.176.98 cpe-23-240-176-98.socal.res.rr.com > 24.25.253.81 cpe-24-25-253-81.hawaii.res.rr.com > 24.27.121.156 cpe-24-27-121-156.tx.res.rr.com > vs. > 24.106.98.106 rrcs-24-106-98-106.central.biz.rr.com > 24.142.142.169 rrcs-24-142-142-169.central.biz.rr.com > 24.173.100.134 rrcs-24-173-100-134.sw.biz.rr.com > > Those are all (very recent) direct-to-MX on port 25 spam sources, but it > looks to me like the first group in each set is residential and the second > group is business. But perhaps I'm misinterpreting the naming. > > ---rsk From khelms at zcorum.com Mon Mar 2 20:29:06 2015 From: khelms at zcorum.com (Scott Helms) Date: Mon, 2 Mar 2015 15:29:06 -0500 Subject: content regulation, was Verizon Policy Statement on Net Neutrality In-Reply-To: References: <54F0E159.2000804@satchell.net> <20150227233223.18612.qmail@ary.lan> <20150301124846.GA16378@gsp.org> <20150302113946.GB4153@gsp.org> Message-ID: San Jose is most certainly not a pure coax network and is HFC. HSD does mean High Speed Data. On Mar 2, 2015 3:26 PM, "Owen DeLong" wrote: > Not so sure about that… > > 240.59.103.76.in-addr.arpa. 7200 IN PTR > c-76-103-59-240.hsd1.ca.comcast.net. > > is most definitely a business class service from Comcast. Seems to match > the entry for 24.7.48.153 pretty closely. > > I think the difference is the type of cable network in the particular > area. HFC is Hybrid Fiber Coax. The network in San Jose doesn’t really have > any fiber, so it’s likely not an HFC network. I’m not sure what HSD stands > for other than possibly “High Speed Data”, but I suspect it’s more likely > some cable-specific term for an all-copper alternative to HFC. > > Owen > > > On Mar 2, 2015, at 03:39 , Rich Kulawiec wrote: > > > > On Sun, Mar 01, 2015 at 11:58:34AM -0500, Christopher Morrow wrote: > >> business vs consumer edition products? (that'd be my bet) > > > > I think these are all residential customers, as business customers > > appear to use different subdomains and/or host naming conventions, e.g.: > > > > 24.7.48.153 c-24-7-48-153.hsd1.ca.comcast.net > > 24.10.217.142 c-24-10-217-142.hsd1.ut.comcast.net > > 24.129.85.220 c-24-129-85-220.hsd1.fl.comcast.net > > vs. > > 70.88.25.201 > 70-88-25-201-chesterfield-va.hfc.comcastbusiness.net > > 70.90.158.37 70-90-158-37-knoxville.hfc.comcastbusiness.net > > 70.91.133.105 70-91-133-105-ma-ne.hfc.comcastbusiness.net > > > > Or: > > 23.240.176.98 cpe-23-240-176-98.socal.res.rr.com > > 24.25.253.81 cpe-24-25-253-81.hawaii.res.rr.com > > 24.27.121.156 cpe-24-27-121-156.tx.res.rr.com > > vs. > > 24.106.98.106 rrcs-24-106-98-106.central.biz.rr.com > > 24.142.142.169 rrcs-24-142-142-169.central.biz.rr.com > > 24.173.100.134 rrcs-24-173-100-134.sw.biz.rr.com > > > > Those are all (very recent) direct-to-MX on port 25 spam sources, but it > > looks to me like the first group in each set is residential and the > second > > group is business. But perhaps I'm misinterpreting the naming. > > > > ---rsk > > From owen at delong.com Mon Mar 2 20:31:35 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Mar 2015 12:31:35 -0800 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F48F98.9060906@pari.edu> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> Message-ID: <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> > On Mar 2, 2015, at 08:28 , Lamar Owen wrote: > > On 02/28/2015 05:46 PM, Mark Andrews wrote: >> Home users should be able to upload a content in the same amount >> of time it takes to download content. > This. > > Once a week I upload a 100MB+ MP3 (that I produced myself, and for which I own the copyright) to a cloud server. I have a reasonable ADSL circuit at home, but it takes quite a bit of my time to upload that one file. Even if the average BW was throttled to 512k, it would be really nice to have 7Mb/s up for just a minute or ten so I can shut the machine down and go to bed. Cloud services are becoming the choice for all kinds of content distribution, and there are more content creators out there than you might think who need to do exactly what I need to do. How much of your downstream bandwidth are you willing to give up in order to get that? Let’s say your current service is 10Mbps/512Kbps. Would you be willing to switch to 3Mbps/7Mbps in order to achieve what you want? What about 5.25Mbps/5.25Mbps? (same total bandwidth, but split symmetrically)? > And, well, I still use my connection in much the same way as I used dialup, turning it off when I'm not using it. I almost never leave it up all night; if my router isn't online it can't be used for malicious purposes, etc. And, no, I have no alternatives to the ILEC's DSL here, as 3G/4G cell service simply doesn't get to my house (now on the ridge behind my house, great 4G bandwidth, but I'm down in a valley, and the shadowing algorithm's show the story; I ran a Splat simulation from the cell tower site; across the creek from my house is the edge of one of the diffraction zones where good service can be found, and my house is in a deep null….) I think you’re in the minority bothering to turn your router off at night. In my case, since I am hosting some services, turning off the routers wouldn’t fly anyway, but I recognize I’m nowhere near the average home user. As to the rest, your situation isn’t even unusual in the united States, no matter how much the ILECs continue to try and claim otherwise. In reality, 3G/4G cell service isn’t a competition anyway because it’s very hard to get decent service and bandwidth for anything approaching cost effective. Owen From bzs at world.std.com Mon Mar 2 20:46:22 2015 From: bzs at world.std.com (Barry Shein) Date: Mon, 2 Mar 2015 15:46:22 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> <54F31DBE.9060603@meetinghouse.net> Message-ID: <21748.52254.768347.50688@world.std.com> > Anything based on NNTP would be extremely asymmetric without significant > changes to the protocol or human behavior. > > We ran significant Usenet servers with binaries for nearly 20 years and > without for another 5 and the servers' traffic was heavily asymmetric. > On Mar 1, 2015 9:11 AM, "Miles Fidelman" wrote: With all due respect it's like people act purposely obtuse just to argue. If you're a Usenet server (and most likely client) then it'll be somewhat symmetric. Depending on how many nodes you serve the bias could easily be towards upload bandwidth as msgs come in once (ideally) but you flood them to all the other servers you serve once per server, the entire traffic goes out multiple times, plus or minus various optimizations like "already have that msg" oh for the love of all that is good and holy do I have to type the entire NNTP protocol spec in here just to make sure there isn't some microscopic crack of light someone can use to misinterpret and/or pick nits about??? What was the original question because I think this has degenerated into just argumentativeness, we're on the verge of spelling and grammar error flames. I don't know how anyone who claims to have run Usenet servers couldn't know all this, is it just trolling? -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From khelms at zcorum.com Mon Mar 2 20:50:35 2015 From: khelms at zcorum.com (Scott Helms) Date: Mon, 2 Mar 2015 15:50:35 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <21748.52254.768347.50688@world.std.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> <54F31DBE.9060603@meetinghouse.net> <21748.52254.768347.50688@world.std.com> Message-ID: Odd how the graphing for the top 1000 Usenet servers showed exactly the pattern I predicted. On Mar 2, 2015 3:46 PM, "Barry Shein" wrote: > > > Anything based on NNTP would be extremely asymmetric without significant > > changes to the protocol or human behavior. > > > > We ran significant Usenet servers with binaries for nearly 20 years and > > without for another 5 and the servers' traffic was heavily asymmetric. > > On Mar 1, 2015 9:11 AM, "Miles Fidelman" > wrote: > > With all due respect it's like people act purposely obtuse just to > argue. > > If you're a Usenet server (and most likely client) then it'll be > somewhat symmetric. > > Depending on how many nodes you serve the bias could easily be towards > upload bandwidth as msgs come in once (ideally) but you flood them to > all the other servers you serve once per server, the entire traffic > goes out multiple times, plus or minus various optimizations like > "already have that msg" oh for the love of all that is good and holy > do I have to type the entire NNTP protocol spec in here just to make > sure there isn't some microscopic crack of light someone can use to > misinterpret and/or pick nits about??? > > What was the original question because I think this has degenerated > into just argumentativeness, we're on the verge of spelling and > grammar error flames. > > I don't know how anyone who claims to have run Usenet servers couldn't > know all this, is it just trolling? > > -- > -Barry Shein > > The World | bzs at TheWorld.com | > http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, > Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* > From mfidelman at meetinghouse.net Mon Mar 2 21:28:58 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 02 Mar 2015 16:28:58 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <21748.52254.768347.50688@world.std.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> <54F31DBE.9060603@meetinghouse.net> <21748.52254.768347.50688@world.std.com> Message-ID: <54F4D61A.5010106@meetinghouse.net> Barry Shein wrote: > > Anything based on NNTP would be extremely asymmetric without significant > > changes to the protocol or human behavior. > > > > We ran significant Usenet servers with binaries for nearly 20 years and > > without for another 5 and the servers' traffic was heavily asymmetric. > > On Mar 1, 2015 9:11 AM, "Miles Fidelman" wrote: Hey Barry - just to be clear, twasn't I who made the claim - I'm the one who asked for your input re. Scott's claim! > With all due respect it's like people act purposely obtuse just to > argue. > > If you're a Usenet server (and most likely client) then it'll be > somewhat symmetric. > > Depending on how many nodes you serve the bias could easily be towards > upload bandwidth as msgs come in once (ideally) but you flood them to > all the other servers you serve once per server, the entire traffic > goes out multiple times, plus or minus various optimizations like > "already have that msg" oh for the love of all that is good and holy > do I have to type the entire NNTP protocol spec in here just to make > sure there isn't some microscopic crack of light someone can use to > misinterpret and/or pick nits about??? > > What was the original question because I think this has degenerated > into just argumentativeness, we're on the verge of spelling and > grammar error flames. > > I don't know how anyone who claims to have run Usenet servers couldn't > know all this, is it just trolling? > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From bzs at world.std.com Mon Mar 2 21:37:39 2015 From: bzs at world.std.com (Barry Shein) Date: Mon, 2 Mar 2015 16:37:39 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F33AB5.3040208@foobar.org> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> <54F33AB5.3040208@foobar.org> Message-ID: <21748.55331.574654.461250@world.std.com> On March 1, 2015 at 16:13 nick at foobar.org (Nick Hilliard) wrote: > On 01/03/2015 03:41, Barry Shein wrote: > > On February 28, 2015 at 23:20 nick at foobar.org (Nick Hilliard) wrote: > > > there were several reasons for asymmetric services, one of which was > > > commercial. Another was that most users' bandwidth profiles were massively > > > asymmetric to start with so it made sense for consumers to have more > > > bandwidth in one direction than another. > > > > How could they have known this before it was introduced? > > because we had modem banks before we had adsl. And you are asserting that studies were done on user behavior over dial-up modems in order to justify asymmetric service? Well, maybe there was some observation and conclusions from those observations that people tended to download more than they uploaded, it's not inherently hard to believe. I'd've had questions about how well 56kb theoretical max predicted behavior at ~10x higher speeds of *DSL. But whatever you work with what you have. I still think a lot of the motivation was to distinguish residential from commercial products. We are talking about a product sold by regional monopolies, right? > > > I say that was prescriptive and a best guess that it'd be acceptable > > and a way to differentiate commercial from residential > > service. Previously all residential service (e.g., dial-up, ISDN) was > > symmetrical. Maybe they had some data on that usage but it'd be muddy > > just due to the low bandwidth they provided. > > maybe it was symmetric on your modems; it wasn't on the modems I managed. Bandwidth or usage? Are you changing the subject? I was talking about bandwidth, bandwidth on dial-up modems was symmetric or roughly symmetric (perhaps 53kbps down and 33kbps up was common, effectively.) Which is why I said residential SERVICE ... was symmetrical. > > > > It was the combination of asymmetric, no or few IPs (and NAT), and > > bandwidth caps. > > let's not rewrite history here: IPv4 address scarcity has been a thing > since the very early 1990s. Otherwise why would cidr have been created? Because Class A/B/C/(D) was obviously wasteful and inflexible compared to CIDR so it caught on. Yes some were projecting an eventual IPv4 runout 20+ years ago, and IPv4 was a cost factor particularly if you were planning on deploying millions of clients tho not a killer. At any rate NAT played well into the hands of any company which wanted to distinguish a residential from commercial IP service, only a tiny per cent could see their way around a non-static address via DDNS etc. > > > Sure. once it became institutionalized and the market got used to it > > why not sell tiered bandwidth services at different price points, but > > that could have been true of symmetrical service also. > > my point is simply that there is often more to asymmetric services than > extracting more money from the customer. Ok fine. But don't present it as if it never crossed the minds of telcos and cablecos that asymmetric service, no static ips, etc distinguished residential from commercial service. They do include all that with commercial services, right? Well there are these small business "commercial" services particularly from cablecos which are hybrids, asymmetric bandwidth with static IPs etc. It was a challenge early on, the internet particularly in those days just didn't distinguish such thing as residential vs commercial, bits were bits, other than raw link speed perhaps and even then some were buying 9.6kbps and 56kbps nailed-up leased lines for $1,000+/month while others got that kind of speed over dial-up modems for $20/mo (plus POTS) and faster (128kbps) over ISDN for around $100/mo or less. A very early way to distinguish was idle-out, if you weren't sending traffic you were dropped either from dial-up or your ISDN link shut down or whatever. And someone sending at you didn't (unless you had some exotic set-up) bring the link back up. Some sites would just drop your link if you were logged in more than so many hours straight (trust me on that) to see if anyone was really there to log back in, automating that was way into the few per cent. I had an ethernet switch at home with a built-in 56kbps modem which would keep a dial-up link up, keep redialing if it lost it. In theory it should have worked, in practice it was crap. But that was probably more like 1997 when consumer products catering to this stuff really started hitting the market (other than just modems.) So you couldn't run always available servers from those kinds of services, not even an SMTP incoming server unless you adapted to that, after a few minutes idle you went offline. Some of that was resource conservation but a lot of it was to differentiate residential from commercial service. You want to run a server host it somewhere that sells that or buy an always up link (e.g., leased line.) To some extent this is six vs half a dozen. One reason commercial servers were discouraged was that they used more resources, you weren't just reading your email you were running Amazon! That wasn't sustainable for $20/month and billing for actual metered usage was a PITA for other reasons. So you said ok, it's $XX per month, no metering, but here's how we're going to make it nearly impossible for you to run Amazon off your cheap link: Asymmetrical, NAT, bandwidth caps, port blocking, etc. ********* BUT WHAT WAS THE POINT? ******************* Not to do internet archaeology. It was originally just making a point that asymmetrical service was kind of a hack, a kludge, something driven by limited resources and early attempts at market differentiation, and not inherently desirable as a future. I didn't bring that up I just agreed. It's not even clear what asymmetric service in those terms means in a world where you'll be offered 100/25mbps or 100/50mbps links, that's a far cry from 1m/256kb links. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From ttauber at 1-4-5.net Mon Mar 2 22:58:29 2015 From: ttauber at 1-4-5.net (Tony Tauber) Date: Mon, 2 Mar 2015 17:58:29 -0500 Subject: [NANOG-announce] Fwd: CFP Test In-Reply-To: References: Message-ID: Greetings NANOG Folks, NANOG 63 in San Antonio is still a fairly fresh memory (for those who were there). NANOG will hold its 64th meeting in San Francisco, CA on June 1-3, 2015, hosted by Netflix. The NANOG Program Committee is now seeking proposals for presentations, panels, tutorials, tracks sessions, and keynote materials for the NANOG 64 program. We invite presentations highlighting issues relating to technology already deployed or soon-to-be deployed in the Internet, . Vendors are encouraged to work with operators to present real-world deployment experiences with the vendor's products and interoperability. Key dates to track if you wish to submit a presentation: Key Dates For NANOG 64 Event/Deadline Date Registration for NANOG 64 Opens March 2, 2015 (Monday) CFP Opens for NANOG 64 March 2, 2015 (Monday) CFP Deadline #1: Presentation Abstracts Due March 30, 2015 (Monday) CFP Topic List and NANOG Highlights Page Posted April 13, 2015 (Monday) CFP Deadline #2: Presentation Slides Due April 27, 2015 (Monday) Meeting Agenda Published May 4, 2015 (Monday) Speaker FINAL presentations to PC Tool May 29, 2015 (Friday) On-site Registration May 31, 2015 (Sunday) Lightning Talk Submissions Open (Abstracts Only) June 1, 2015 (Monday) NANOG 64 submissions are welcome on the Program Committee Site or email me if you have questions. See the detailed NANOG64 Call for Presentations for more information. You can also view the NANOG events calendar (including the key dates above and more) import in ICS format . Thanks, Tony Tauber Chair, Program Committee North American Network Operator Group (NANOG) -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From ttauber at 1-4-5.net Mon Mar 2 23:01:32 2015 From: ttauber at 1-4-5.net (Tony Tauber) Date: Mon, 2 Mar 2015 18:01:32 -0500 Subject: [NANOG-announce] NANOG 64 - San Francisco - Call for Presentations is Open! Message-ID: Greetings NANOG Folks, NANOG 63 in San Antonio is still a fairly fresh memory (for those who were there). NANOG will hold its 64th meeting in San Francisco, CA on June 1-3, 2015, hosted by Netflix. The NANOG Program Committee is now seeking proposals for presentations, panels, tutorials, tracks sessions, and keynote materials for the NANOG 64 program. We invite presentations highlighting issues relating to technology already deployed or soon-to-be deployed in the Internet, . Vendors are encouraged to work with operators to present real-world deployment experiences with the vendor's products and interoperability. Key dates to track if you wish to submit a presentation: Key Dates For NANOG 64 Event/Deadline Date Registration for NANOG 64 Opens March 2, 2015 (Monday) CFP Opens for NANOG 64 March 2, 2015 (Monday) CFP Deadline #1: Presentation Abstracts Due March 30, 2015 (Monday) CFP Topic List and NANOG Highlights Page Posted April 13, 2015 (Monday) CFP Deadline #2: Presentation Slides Due April 27, 2015 (Monday) Meeting Agenda Published May 4, 2015 (Monday) Speaker FINAL presentations to PC Tool May 29, 2015 (Friday) On-site Registration May 31, 2015 (Sunday) Lightning Talk Submissions Open (Abstracts Only) June 1, 2015 (Monday) NANOG 64 submissions are welcome on the Program Committee Site or email me if you have questions. See the detailed NANOG64 Call for Presentations for more information. You can also view the NANOG events calendar (including the key dates above and more) import in ICS format . Thanks, Tony Tauber Chair, Program Committee North American Network Operator Group (NANOG) -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From lowen at pari.edu Mon Mar 2 23:40:48 2015 From: lowen at pari.edu (Lamar Owen) Date: Mon, 2 Mar 2015 18:40:48 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> Message-ID: <54F4F500.8090303@pari.edu> On 03/02/2015 03:31 PM, Owen DeLong wrote: >> On Mar 2, 2015, at 08:28 , Lamar Owen wrote: >> >> ...it would be really nice to have 7Mb/s up for just a minute or ten >> so I can shut the machine down and go to bed. > How much of your downstream bandwidth are you willing to give up in order to get that? > > Let’s say your current service is 10Mbps/512Kbps. Would you be willing to switch to 3Mbps/7Mbps in order to achieve what you want? > > What about 5.25Mbps/5.25Mbps? (same total bandwidth, but split symmetrically)? Any of those would be nice. Nicer would be something adaptive, but that's a pipe dream, I know. I'm aware of the technological limitations of ADSL, especially the crosstalk and power limitations, how the spectrum is divided, etc. The difference between 10/.5 and 5.25/5.25 on the download would be minimal (half as fast); on the upload, not so minimal (ten times faster). But even a 'less asymmetrical' connection would be better than a 20:1 ratio. 4:1 (with 10Mb/s aggregate) would be better than 20:1. From owen at delong.com Tue Mar 3 00:32:04 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 2 Mar 2015 16:32:04 -0800 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F4F500.8090303@pari.edu> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> <54F4F500.8090303@pari.edu> Message-ID: <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> > On Mar 2, 2015, at 15:40 , Lamar Owen wrote: > > On 03/02/2015 03:31 PM, Owen DeLong wrote: >>> On Mar 2, 2015, at 08:28 , Lamar Owen wrote: >>> >>> ...it would be really nice to have 7Mb/s up for just a minute or ten so I can shut the machine down and go to bed. >> How much of your downstream bandwidth are you willing to give up in order to get that? >> >> Let’s say your current service is 10Mbps/512Kbps. Would you be willing to switch to 3Mbps/7Mbps in order to achieve what you want? >> >> What about 5.25Mbps/5.25Mbps? (same total bandwidth, but split symmetrically)? > > Any of those would be nice. Nicer would be something adaptive, but that's a pipe dream, I know. I'm aware of the technological limitations of ADSL, especially the crosstalk and power limitations, how the spectrum is divided, etc. > > The difference between 10/.5 and 5.25/5.25 on the download would be minimal (half as fast); on the upload, not so minimal (ten times faster). But even a 'less asymmetrical' connection would be better than a 20:1 ratio. 4:1 (with 10Mb/s aggregate) would be better than 20:1. If you would see that as a win, I can personally guarantee you that you are in the minority among consumers. I, even as an advanced user know that overall, my usage pattern would suffer greatly if my 30/7 were converted to 18.5/18.5. (I’m on CMTS instead of ADSL, as all ADSL will do in my neighborhood is 1536/384 (on a good day)). Sure, my uploads would be faster, but that’s less than 1% of what I do and I’m almost never sitting there waiting for my upload to complete. When I upload something large, I pretty much do it as a fire-and-forget. I get notified if it fails and I use software/protocols for large files that are capable of resuming where they left off or recovering from failure with relatively minimal retransmission of previously transferred data. As such, while I’d much rather have 30Mbps of upstream data than 7, if I were given the choice between 30/30 vs. 53/7, I’s probably still choose 53/7. I agree that adaptive is a nice pipedream, but in the realm of reality, fixed is what is currently implemented and due to where the incentives currently reside, likely to stay that way for the foreseeable future. Owen From chuckchurch at gmail.com Tue Mar 3 04:06:36 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Mon, 2 Mar 2015 23:06:36 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> <54F4F500.8090303@pari.edu> <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> Message-ID: <000101d05567$74b58530$5e208f90$@gmail.com> Since this has turned into a discussion on upload vs download speed, figured I'd throw in a point I haven't really brought up. For the most part, uploading isn't really a time-sensitive activity to the general (as in 99% of the ) public. Uploading a bunch of facebook photos, you hit upload, and then expect it to take x amount of time. Could be 30 seconds, could be 30 minutes. Everyone expects that wait. Sending a large email attachment, you hit send, and then get back to doing something else. There just aren't that many apps out there that have a dependence on time-sensitive upload performance. On download, of course no wants to see buffering on their cat videos or watching Netflix. Thus the high speed download. Honesty, I'm willing to bet that even a random sampling of NANOG people would show their download data quantity to be 10x what their upload quantity is in a day. For average users, probably much more than 10x. Why some folks are insisting upload is vital just can't be true for normal home users. Those households trying to do 5 simultaneous Skype sessions aren't typical. Chuck From nmaxpierson at gmail.com Tue Mar 3 04:50:32 2015 From: nmaxpierson at gmail.com (N. Max Pierson) Date: Mon, 2 Mar 2015 22:50:32 -0600 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <000101d05567$74b58530$5e208f90$@gmail.com> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> <54F4F500.8090303@pari.edu> <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> <000101d05567$74b58530$5e208f90$@gmail.com> Message-ID: I don't usually chime in on the list, but since this seems to be another hot item, i'll pitch in my $0.005 (since the $$ has been going up these days). IIRC the entire reason we have asymmetry to begin with is because it was created to resolve an issue with older ADSL hardware. I believe the reason it gave such great benefits at the time of faster downloads while not so good downloads is because simply of the power used in each direction (it takes more power to send than receive delivering farther distances, etc). So in this sense, telecoms decided that if you wanted to use both sides of your connection, you're a "Business Class" user that needed to upload something with download like speeds. Then as cable operators see the telecom vendors charge for it in this very fashion, they decide it's a great idea to charge for it so that they can stay "competitive" (cable also had these issues but have long since been resolved). So it would seem that there ARE legitimate complaints from those who do not want to be in a "Business Class" service just because they want to have the ability to upload content just as they download content. Regardless of the amount, this is something that has been complained about for quite a long time. Times have changed, infrastructure _should_ be upgraded by now for major transport operators, Tier-1/2 carriers, all the way down to last mile (i realize many rural places being worked on). Asymmetry needs to die just like the equipment will, thus the non-sense charges, etc. The only ones still fighting for asymmetry in this conversation are the ones that stand to make money from it. Technical perspective says this is a non-issue and symmetry is how it works by default anywhere inside of "Business Class". max On Mon, Mar 2, 2015 at 10:06 PM, Chuck Church wrote: > Since this has turned into a discussion on upload vs download > speed, figured I'd throw in a point I haven't really brought up. For the > most part, uploading isn't really a time-sensitive activity to the general > (as in 99% of the ) public. Uploading a bunch of facebook photos, you hit > upload, and then expect it to take x amount of time. Could be 30 seconds, > could be 30 minutes. Everyone expects that wait. Sending a large email > attachment, you hit send, and then get back to doing something else. There > just aren't that many apps out there that have a dependence on > time-sensitive upload performance. > On download, of course no wants to see buffering on their cat > videos or watching Netflix. Thus the high speed download. Honesty, I'm > willing to bet that even a random sampling of NANOG people would show their > download data quantity to be 10x what their upload quantity is in a day. > For average users, probably much more than 10x. Why some folks are > insisting upload is vital just can't be true for normal home users. > Those households trying to do 5 simultaneous Skype sessions aren't > typical. > > Chuck > > From marka at isc.org Tue Mar 3 05:14:38 2015 From: marka at isc.org (Mark Andrews) Date: Tue, 03 Mar 2015 16:14:38 +1100 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: Your message of "Mon, 02 Mar 2015 23:06:36 -0500." <000101d05567$74b58530$5e208f90$@gmail.com> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> <54F4F500.8090303@pari.edu> <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> <000101d05567$74b58530$5e208f90$@gmail.com> Message-ID: <20150303051439.B14E72ABEB33@rock.dv.isc.org> In message <000101d05567$74b58530$5e208f90$@gmail.com>, "Chuck Church" writes: > Since this has turned into a discussion on upload vs download > speed, figured I'd throw in a point I haven't really brought up. For the > most part, uploading isn't really a time-sensitive activity to the > general (as in 99% of the ) public. Uploading a bunch of facebook > photos, you hit upload, and then expect it to take x amount of time. > Could be 30 seconds, could be 30 minutes. Everyone expects that wait. > Sending a large email attachment, you hit send, and then get back to > doing something else. There just aren't that many apps out there that > have a dependence on time-sensitive upload performance. Just tell that to your child that has to submit a assignment before midnight or get zero on 20% of the year's marks. There are plenty of cases where uploads are time critical there are also time where it really doesn't matter. > On download, of course no wants to see buffering on their cat > videos or watching Netflix. Thus the high speed download. Honesty, I'm > willing to bet that even a random sampling of NANOG people would show > their download data quantity to be 10x what their upload quantity is in a > day. For average users, probably much more than 10x. Why some folks are > insisting upload is vital just can't be true for normal home users. Once you get over a certain threshold more download speed doesn't buy as much as more upload speed. For movies you want the data there before you need to display it. It really doesn't matter if it is 30 seconds before or 20 minutes before, you only consume the data so fast. > Those households trying to do 5 simultaneous Skype sessions > aren't typical. If the network supported it this would be typical of a household with teenagers. People adapt their usage to the constraints presented. That doesn't mean they are necessarially happy with the constraints. Don't take lack of complaints as indicating people don't want things improved. As speed increases the importance of more speed decreases. We get to the point where thing happen fast enough. We also start to be limited by things other than link speed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bzs at world.std.com Tue Mar 3 05:59:18 2015 From: bzs at world.std.com (Barry Shein) Date: Tue, 3 Mar 2015 00:59:18 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <54F0DC14.1010801@vocalabs.com> <54F46C0F.3060702@vocalabs.com> <54F47213.5010004@vocalabs.com> Message-ID: <21749.19894.716897.902579@world.std.com> That's fine and very practical and understandable. But it's no reason for the net not to keep marching forward at its own pace which I think is more what's being discussed. I'm pretty sure that prior to 2007 (year of the first iphone launch) not many people were clamoring for full, graphical internet in their pocket either. Then all of a sudden they were. And *poof*, down went Nokia and Motorola and Blackberry and others (anyone remember WAP?) who no doubt had reasoned very carefully and responsibly that would never happen, or not nearly at the pace it did. Surely they had no desire to fall from their respective perches or spend money "needlessly". Give people a few sports scores and the weather etc on their phones and they'll be pretty happy. Of course there were also quite a few directions and predictions which failed, we tend to forget those. Such as that users would never stand for widespread CGN, ftp couldn't be made to work properly, etc etc etc. We still hear these predictions and to be honest they have my sympathy but I can't deny the reality of a present where the vast majority of users are NAT'd and seem reasonably satisfied. Predicting the past is much easier than predicting the future, no doubt about it. -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* On March 2, 2015 at 10:28 khelms at zcorum.com (Scott Helms) wrote: > That's certainly true and why we watch the trends of usage very closely and > we project those terms into the future knowing that's imperfect. > > What we won't do is build networks based purely on guesses. We certainly > see demand for upstream capacity increasing for residential customers, but > that increase is slower than the increase in downstream demand growth. In > all cases but pure greenfield situations the cost of deploying DSL or > DOCSIS is significant less than deploying fiber. Even in greenfield > situations PON, which is a asynchronous itself, is much less expensive than > active Ethernet. > > In short synchronous connections cost more to deploy. Doing so without a > knowing if or when consumers will actually pay for synchronous connections > isn't something we're going to do. From rs at seastrom.com Tue Mar 3 08:05:16 2015 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 03 Mar 2015 03:05:16 -0500 Subject: Symmetry, DSL, and all that In-Reply-To: <9578293AE169674F9A048B2BC9A081B40157261677@MUNPRDMBXA1.medline.com> (Steve Naslund's message of "Mon, 2 Mar 2015 19:19:29 +0000") References: <28319357.4010.1425322812560.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B40157261677@MUNPRDMBXA1.medline.com> Message-ID: <86vbiiv743.fsf@valhalla.seastrom.com> "Naslund, Steve" writes: >>From a Verizon press release last summer, all FIOS speeds are now symmetric. > > And no one cares. I don't even see Verizon commercials crowing > about how great it is to have symmetry. If customers loved it that > much don't you think they would market that way? You must not get out much. There's a whole Verizon ad campaign about "half fast Internet". https://www.youtube.com/watch?v=zr5WWFuJeM4 https://www.youtube.com/watch?v=NPqeDokFnok -r From list at satchell.net Tue Mar 3 08:52:38 2015 From: list at satchell.net (Stephen Satchell) Date: Tue, 03 Mar 2015 00:52:38 -0800 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <20150303051439.B14E72ABEB33@rock.dv.isc.org> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> <54F4F500.8090303@pari.edu> <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> <000101d05567$74b58530$5e208f90$@gmail.com> <20150303051439.B14E72ABEB33@rock.dv.isc.org> Message-ID: <54F57656.2010804@satchell.net> On 03/02/2015 09:14 PM, Mark Andrews wrote: > Just tell that to your child that has to submit a assignment before > midnight or get zero on 20% of the year's marks. There are plenty > of cases where uploads are time critical there are also time where > it really doesn't matter. That's what USB thumb drives and school/library computers are all about: if you don't have the moxie at home, find a better path. Of course, if the kid planned better, s/he wouldn't be in photo-finish hell. (And I speak as someone who regularly crowded deadlines in school.) More compelling is the argument of collaborative creation of PowerPoint slide stacks with lots of graphic elements with a geographically distributed group of people. Particularly if any of the information in the slides is company confidential. Better upstream speeds will speed the collaboration, particularly in the final stages. Text is fast; full-color graphics can be slow. From marka at isc.org Tue Mar 3 12:28:39 2015 From: marka at isc.org (Mark Andrews) Date: Tue, 03 Mar 2015 23:28:39 +1100 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: Your message of "Tue, 03 Mar 2015 00:52:38 -0800." <54F57656.2010804@satchell.net> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> <54F4F500.8090303@pari.edu> <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> <000101d05567$74b58530$5e208f90$@gmail.com> <20150303051439.B14E72ABEB33@rock.dv.isc.org> <54F57656.2010804@satchell.net> Message-ID: <20150303122840.428C22AC5068@rock.dv.isc.org> In message <54F57656.2010804 at satchell.net>, Stephen Satchell writes: > On 03/02/2015 09:14 PM, Mark Andrews wrote: > > Just tell that to your child that has to submit a assignment before > > midnight or get zero on 20% of the year's marks. There are plenty > > of cases where uploads are time critical there are also time where > > it really doesn't matter. > > That's what USB thumb drives and school/library computers are all about: > if you don't have the moxie at home, find a better path. I don't know many schools that are open at midnight to accept thumb drives. > Of course, if the kid planned better, s/he wouldn't be in photo-finish > hell. (And I speak as someone who regularly crowded deadlines in school.) Well kids will be kids. > More compelling is the argument of collaborative creation of PowerPoint > slide stacks with lots of graphic elements with a geographically > distributed group of people. Particularly if any of the information in > the slides is company confidential. Better upstream speeds will speed > the collaboration, particularly in the final stages. Text is fast; > full-color graphics can be slow. Yep. The assumption that because you are sending from home it is not time critical is absolutely bogus. Upstream speeds really are just as important as downstream speeds. It just that it is not normally needed as much of the time. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From khelms at zcorum.com Tue Mar 3 13:07:21 2015 From: khelms at zcorum.com (Scott Helms) Date: Tue, 3 Mar 2015 08:07:21 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <20150303122840.428C22AC5068@rock.dv.isc.org> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> <54F4F500.8090303@pari.edu> <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> <000101d05567$74b58530$5e208f90$@gmail.com> <20150303051439.B14E72ABEB33@rock.dv.isc.org> <54F57656.2010804@satchell.net> <20150303122840.428C22AC5068@rock.dv.isc.org> Message-ID: > > I don't know many schools that are open at midnight to accept thumb > drives. I think he was trying to point out that most school libraries, and their computer labs, open before classes start. Ice never heard of a school deadline that was actually in the middle of the night, so if you're working on a paper at night it's because it's due the next day. > > Well kids will be kids. > Very true :) > > Yep. The assumption that because you are sending from home it is > not time critical is absolutely bogus. Upstream speeds really are > just as important as downstream speeds. It just that it is not > normally needed as much of the time. This assertion is counter to the choices that consumers are making. Forget about the access technology and it's symmetry or asymmetry for a moment and consider the growth of WiFi in the home, which is highly asymmetrical because clients have much lower power output and most often 0 dB gain antennas at 2.4 and 5.8. The point is that a great percentage of the traffic we see is from asymmetric sources even on symmetrical broadband connections. The other thing to consider is that LTE is asymmetrical and for the same reasons as WiFi. For consumers to care about symmetrical upload speeds as much as you're saying why have they been choosing to use technologies that don't deliver that in WiFi and LTE? In the WiFi case they're taking a symmetrical connection to their home and making it asymmetrical. I can make a home WiFi network operate more symmetrically by putting in multiple APs but very few consumers take that step. I'm not done collecting all of our data yet, but just looking at what we have right now (~17,000 APs) over half of the clients connected have an upload rate of 5mbps or less. A just over 20% have an average upload rate of 1mbps. BTW, the reason we're working on the WiFi data is that we think this is a huge problem, because consumers don't separate the performance of the in home WiFi from their overall broadband experience and we need to dramatically improve the in home WiFi experience to increase customer satisfaction. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From alex at corp.nac.net Tue Mar 3 14:27:40 2015 From: alex at corp.nac.net (Alex Rubenstein) Date: Tue, 3 Mar 2015 14:27:40 +0000 Subject: optical gear cooling requirements Message-ID: The rock has turned over for a moment and I have crawled out. It is good to see the sunlight from time to time. Those who know me know my life has gotten away from networking and that sort of thing, and I am fully immersed in datacenter design and construction for IT type loads (blades, compute, disk, etc.). However, I am presented with the challenge of having to deal with some optical gear (Ciena stuff, mainly). My question: have the optical folks woken up and made things cool front to back, or are they still in to the bottom to top world? Comments and lambasting: go Thanks! From oscar.vives at gmail.com Tue Mar 3 14:30:57 2015 From: oscar.vives at gmail.com (Tei) Date: Tue, 3 Mar 2015 15:30:57 +0100 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> <54F4F500.8090303@pari.edu> <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> <000101d05567$74b58530$5e208f90$@gmail.com> <20150303051439.B14E72ABEB33@rock.dv.isc.org> <54F57656.2010804@satchell.net> <20150303122840.428C22AC5068@rock.dv.isc.org> Message-ID: imho this two staments are true: - tomorrow a new product or service on the Internet can completely change the ratio download/upload - most probably, this will not happen It may take a few days (hours for early adopters) for a new service to become popular on the Internet, that make a intensive use of upstream. This... so much can happens. But I would bet my fortune and my children's that it will not happen People do try to create this type of service/product. (like this one) http://www.codediesel.com/browser/opera-unite-a-web-server-in-your-browser/ -- -- ℱin del ℳensaje. From jbates at paradoxnetworks.net Tue Mar 3 14:46:51 2015 From: jbates at paradoxnetworks.net (Jack Bates) Date: Tue, 03 Mar 2015 08:46:51 -0600 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <20150303051439.B14E72ABEB33@rock.dv.isc.org> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> <54F4F500.8090303@pari.edu> <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> <000101d05567$74b58530$5e208f90$@gmail.com> <20150303051439.B14E72ABEB33@rock.dv.isc.org> Message-ID: <54F5C95B.3070303@paradoxnetworks.net> On 3/2/2015 11:14 PM, Mark Andrews wrote: > If the network supported it this would be typical of a household with > teenagers. People adapt their usage to the constraints presented. That > doesn't mean they are necessarially happy with the constraints. Don't > take lack of complaints as indicating people don't want things > improved. As speed increases the importance of more speed decreases. > We get to the point where thing happen fast enough. We also start to > be limited by things other than link speed. Mark This. I'm moving considerably out into the country. Discussions about the uncertainty of what we'll be doing for broadband has given me a good insight to my son's expectations. At a minimum he needs the ability for his phone or computer to be able to send messages to his friends; and raise your hand if you believe he'll actually settle for that long term. However, this is not what he wants. He'd like to stream video/video skype more on his phone, but he has to make sure to stay under the plan's data limit. He'd like to host more gaming servers at the house (though he guesses he can settle for the DC based VPS server, but it's limited on supported games). He'd like to stream his games to twitch. He'd like to collaborate with others on his music. He'd like to mine crypto-currency (nothing to do with upload, but I'm not paying for it). As he's gotten older, he's wanted to do a lot more things. He is settling for what the bandwidth will allow him to do. He is finding ways around the limitations, but that does not mean he doesn't want more. I'd like to say that my son is special (He is! I'm his dad!), but in relation to this discussion he's an average teenager. Time moves on. We may not need symmetric bandwidth, but we definitely need much higher upload capacity and, if possible, we should consider how to make things more dynamic as we move forward. Software developers push what the majority can support. When there's enough people able to handle HD, they pump HD. When there is enough upload capacity, they'll develop more apps that utilize it. And if they can get away with developing p2p streaming to save their own costs on bandwidth, they WILL do it. After all, in the end, it's still about the money. Jack From tim at pelican.org Tue Mar 3 16:20:27 2015 From: tim at pelican.org (Tim Franklin) Date: Tue, 3 Mar 2015 16:20:27 +0000 (GMT) Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F47EC3.2010009@vocalabs.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F46C0F.3060702@vocalabs.com> <54F47213.5010004@vocalabs.com> <54F47ADC.7030805@vocalabs.com> <54F47EC3.2010009@vocalabs.com> Message-ID: <910423432.4454.1425399627062.JavaMail.zimbra@pelican.org> > I meant that on the Internet as a whole it is unusual for such speeds to > actually be realized in practice due to various issues. > > 8-10Mb/s seems to be what one can expect without going to distributed > protocols. Really? I have 2 x VDSL (40/10) to my house, running MLPPP. I can get a sustained 60M down or 15M up on a single stream without a lot of difficulty. It does typically need both ends to be aware of window scaling, or you start to run up against the LFN problem, but other than that it's nothing beyond regular HTTP, FTP, SCP, CIFS, ... 15M upstream *utterly* transforms working from home where all the files I'm working on are on a remote file server. Autosave is no longer a cue for a 5-10 minute tea-break. Regards, Tim. From colinj at gt86car.org.uk Tue Mar 3 17:09:58 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Tue, 3 Mar 2015 17:09:58 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <910423432.4454.1425399627062.JavaMail.zimbra@pelican.org> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F46C0F.3060702@vocalabs.com> <54F47213.5010004@vocalabs.com> <54F47ADC.7030805@vocalabs.com> <54F47EC3.2010009@vocalabs.com> <910423432.4454.1425399627062.JavaMail.zimbra@pelican.org> Message-ID: <1F0D50D6-63FE-4F61-814B-E4B2EA626597@gt86car.org.uk> fttc in uk works great for client code push remote installs , even faster than some offices since the fibre nodes are less contended. seen 18mb up work fine and sustained with voip in parallel as well colin Sent from my iPhone On 3 Mar 2015, at 16:20, Tim Franklin wrote: >> I meant that on the Internet as a whole it is unusual for such speeds to >> actually be realized in practice due to various issues. >> >> 8-10Mb/s seems to be what one can expect without going to distributed >> protocols. > > Really? I have 2 x VDSL (40/10) to my house, running MLPPP. I can get a sustained 60M down or 15M up on a single stream without a lot of difficulty. It does typically need both ends to be aware of window scaling, or you start to run up against the LFN problem, but other than that it's nothing beyond regular HTTP, FTP, SCP, CIFS, ... > > 15M upstream *utterly* transforms working from home where all the files I'm working on are on a remote file server. Autosave is no longer a cue for a 5-10 minute tea-break. > > Regards, > Tim. From SNaslund at medline.com Tue Mar 3 17:20:31 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 3 Mar 2015 17:20:31 +0000 Subject: Symmetry, DSL, and all that In-Reply-To: <86vbiiv743.fsf@valhalla.seastrom.com> References: <28319357.4010.1425322812560.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B40157261677@MUNPRDMBXA1.medline.com> <86vbiiv743.fsf@valhalla.seastrom.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401572628CC@MUNPRDMBXA1.medline.com> >>From a Verizon press release last summer, all FIOS speeds are now symmetric. >> >> And no one cares. I don't even see Verizon commercials crowing about >> how great it is to have symmetry. If customers loved it that much >> don't you think they would market that way? >You must not get out much. There's a whole Verizon ad campaign about "half fast Internet". >https://www.youtube.com/watch?v=zr5WWFuJeM4 >https://www.youtube.com/watch?v=NPqeDokFnok And no one seems to care about it. By the way, Verizon commercials do not run everywhere. Like Chicago or anywhere else that FIOS is not available. Steven Naslund Chicago IL From rs at seastrom.com Tue Mar 3 18:25:19 2015 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 03 Mar 2015 13:25:19 -0500 Subject: Symmetry, DSL, and all that In-Reply-To: <9578293AE169674F9A048B2BC9A081B401572628CC@MUNPRDMBXA1.medline.com> (Steve Naslund's message of "Tue, 3 Mar 2015 17:20:31 +0000") References: <28319357.4010.1425322812560.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B40157261677@MUNPRDMBXA1.medline.com> <86vbiiv743.fsf@valhalla.seastrom.com> <9578293AE169674F9A048B2BC9A081B401572628CC@MUNPRDMBXA1.medline.com> Message-ID: <86y4nerl9s.fsf@valhalla.seastrom.com> "Naslund, Steve" writes: >>>From a Verizon press release last summer, all FIOS speeds are now symmetric. >>> >>> And no one cares. I don't even see Verizon commercials crowing about >>> how great it is to have symmetry. If customers loved it that much >>> don't you think they would market that way? > >>You must not get out much. There's a whole Verizon ad campaign about "half fast Internet". > >>https://www.youtube.com/watch?v=zr5WWFuJeM4 > >>https://www.youtube.com/watch?v=NPqeDokFnok > > And no one seems to care about it. By the way, Verizon commercials > do not run everywhere. Like Chicago or anywhere else that FIOS is > not available. So let me get this straight - you conclude that there are no commercials and opine that nobody cares because you're not seeing FIOS commercials that talk about how great their symmetry is... when you live in a place that there is no FIOS. It's almost as if someone knows how to target their marketing dollars isn't it? Shocking. > Steven Naslund > Chicago IL Rob Seastrom Leesburg VA 75 symmetric FIOS, 9.9ms to Equinix. From SNaslund at medline.com Tue Mar 3 18:53:09 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 3 Mar 2015 18:53:09 +0000 Subject: Symmetry, DSL, and all that In-Reply-To: <86y4nerl9s.fsf@valhalla.seastrom.com> References: <28319357.4010.1425322812560.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B40157261677@MUNPRDMBXA1.medline.com> <86vbiiv743.fsf@valhalla.seastrom.com> <9578293AE169674F9A048B2BC9A081B401572628CC@MUNPRDMBXA1.medline.com> <86y4nerl9s.fsf@valhalla.seastrom.com> Message-ID: <9578293AE169674F9A048B2BC9A081B401572634B0@MUNPRDMBXA1.medline.com> Well, it's not quite that simple. I run a global network so I buy lots of services in lots of countries and areas so I can tell you what out there even though I don't see FIOS commercials on my local TV channels, we are quite aware of the capabilities of FIOS and its competitors. I have lots of FIOS services, various cable services, Uverse, Xfinity, most carrier gig E services. I have both business class and residential services as well as dedicated fiber paths and microwave systems so yeah, I know what service is available just about anywhere you would like to discuss. Steven Naslund Chicago IL -----Original Message----- >>>From a Verizon press release last summer, all FIOS speeds are now symmetric. >>> >>> And no one cares. I don't even see Verizon commercials crowing >>> about how great it is to have symmetry. If customers loved it that >>> much don't you think they would market that way? > >>You must not get out much. There's a whole Verizon ad campaign about "half fast Internet". > >>https://www.youtube.com/watch?v=zr5WWFuJeM4 > >>https://www.youtube.com/watch?v=NPqeDokFnok > > And no one seems to care about it. By the way, Verizon commercials do > not run everywhere. Like Chicago or anywhere else that FIOS is not > available. So let me get this straight - you conclude that there are no commercials and opine that nobody cares because you're not seeing FIOS commercials that talk about how great their symmetry is... when you live in a place that there is no FIOS. It's almost as if someone knows how to target their marketing dollars isn't it? Shocking. > Steven Naslund > Chicago IL Rob Seastrom Leesburg VA 75 symmetric FIOS, 9.9ms to Equinix. From bzs at world.std.com Tue Mar 3 19:11:14 2015 From: bzs at world.std.com (Barry Shein) Date: Tue, 3 Mar 2015 14:11:14 -0500 Subject: Symmetry, DSL, and all that In-Reply-To: <16693871.4074.1425324114866.JavaMail.mhammett@ThunderFuck> References: <9578293AE169674F9A048B2BC9A081B40157261677@MUNPRDMBXA1.medline.com> <16693871.4074.1425324114866.JavaMail.mhammett@ThunderFuck> Message-ID: <21750.1874.466881.199934@world.std.com> On March 2, 2015 at 13:21 nanog at ics-il.net (Mike Hammett) wrote: > The most important point is yes, that no one cares. If people wanted it, it would be sold to them. End. of. story. That presumes you can predict what will be sold tomorrow, which is more what this discussion is about. If people wanted smartphones in 2006 they would have been sold to them, etc. Ooops, not really until the iphone launched in 2007. etc. Besides, the comment presumes a competitive market which it isn't, in almost all US markets last mile is a monopoly or very small N (like 2 or 3) oligopoly. You can choose between asymmetric service from the CATV company OR asymmetric service from your telco. Aha, you apparently want asymmetric service! Well I suppose that's settled! -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From bzs at world.std.com Tue Mar 3 19:24:58 2015 From: bzs at world.std.com (Barry Shein) Date: Tue, 3 Mar 2015 14:24:58 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> <54F31DBE.9060603@meetinghouse.net> <21748.52254.768347.50688@world.std.com> Message-ID: <21750.2698.430920.443976@world.std.com> Ok, then I no longer have any confidence that I understand what you were asserting. From: Scott Helms >Odd how the graphing for the top 1000 Usenet servers showed exactly the >pattern I predicted. >On Mar 2, 2015 3:46 PM, "Barry Shein" wrote: > >> >> > Anything based on NNTP would be extremely asymmetric without significant >> > changes to the protocol or human behavior. >> > >> > We ran significant Usenet servers with binaries for nearly 20 years and >> > without for another 5 and the servers' traffic was heavily asymmetric. >> > On Mar 1, 2015 9:11 AM, "Miles Fidelman" >> wrote: >> >> With all due respect it's like people act purposely obtuse just to >> argue. >> >> If you're a Usenet server (and most likely client) then it'll be >> somewhat symmetric. >> >> Depending on how many nodes you serve the bias could easily be towards >> upload bandwidth as msgs come in once (ideally) but you flood them to >> all the other servers you serve once per server, the entire traffic >> goes out multiple times, plus or minus various optimizations like >> "already have that msg" oh for the love of all that is good and holy >> do I have to type the entire NNTP protocol spec in here just to make >> sure there isn't some microscopic crack of light someone can use to >> misinterpret and/or pick nits about??? >> >> What was the original question because I think this has degenerated >> into just argumentativeness, we're on the verge of spelling and >> grammar error flames. >> >> I don't know how anyone who claims to have run Usenet servers couldn't >> know all this, is it just trolling? >> >> -- >> -Barry Shein >> >> The World | bzs at TheWorld.com | >> http://www.TheWorld.com >> Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, >> Canada >> Software Tool & Die | Public Access Internet | SINCE 1989 *oo* -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From rs at seastrom.com Tue Mar 3 19:51:01 2015 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 03 Mar 2015 14:51:01 -0500 Subject: optical gear cooling requirements In-Reply-To: (Alex Rubenstein's message of "Tue, 3 Mar 2015 14:27:40 +0000") References: Message-ID: <86pp8pzwpm.fsf@valhalla.seastrom.com> Alex Rubenstein writes: > My question: have the > optical folks woken up and made things cool front to back, or are > they still in to the bottom to top world? Unless something's changed, AT&T NEDS still reads "Systems exhausting more than 50 W/sq ft must exhaust the air vertically.". You can always put baffles above and beneath to channel the air into/from your hot/cold aisles. Makes it nice to be able to have the connectors on whichever side is convenient. -r From khelms at zcorum.com Tue Mar 3 19:54:48 2015 From: khelms at zcorum.com (Scott Helms) Date: Tue, 3 Mar 2015 14:54:48 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <21750.2698.430920.443976@world.std.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> <54F31DBE.9060603@meetinghouse.net> <21748.52254.768347.50688@world.std.com> <21750.2698.430920.443976@world.std.com> Message-ID: /em shrug I can't help it if you don't like real world data. On Mar 3, 2015 2:25 PM, "Barry Shein" wrote: > > Ok, then I no longer have any confidence that I understand what you > were asserting. > > From: Scott Helms > >Odd how the graphing for the top 1000 Usenet servers showed exactly the > >pattern I predicted. > >On Mar 2, 2015 3:46 PM, "Barry Shein" wrote: > > > >> > >> > Anything based on NNTP would be extremely asymmetric without > significant > >> > changes to the protocol or human behavior. > >> > > >> > We ran significant Usenet servers with binaries for nearly 20 years > and > >> > without for another 5 and the servers' traffic was heavily > asymmetric. > >> > On Mar 1, 2015 9:11 AM, "Miles Fidelman" > > >> wrote: > >> > >> With all due respect it's like people act purposely obtuse just to > >> argue. > >> > >> If you're a Usenet server (and most likely client) then it'll be > >> somewhat symmetric. > >> > >> Depending on how many nodes you serve the bias could easily be towards > >> upload bandwidth as msgs come in once (ideally) but you flood them to > >> all the other servers you serve once per server, the entire traffic > >> goes out multiple times, plus or minus various optimizations like > >> "already have that msg" oh for the love of all that is good and holy > >> do I have to type the entire NNTP protocol spec in here just to make > >> sure there isn't some microscopic crack of light someone can use to > >> misinterpret and/or pick nits about??? > >> > >> What was the original question because I think this has degenerated > >> into just argumentativeness, we're on the verge of spelling and > >> grammar error flames. > >> > >> I don't know how anyone who claims to have run Usenet servers couldn't > >> know all this, is it just trolling? > >> > >> -- > >> -Barry Shein > >> > >> The World | bzs at TheWorld.com | > >> http://www.TheWorld.com > >> Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, > >> Canada > >> Software Tool & Die | Public Access Internet | SINCE 1989 > *oo* > > -- > -Barry Shein > > The World | bzs at TheWorld.com | > http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, > Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* > From morrowc.lists at gmail.com Tue Mar 3 20:26:31 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 3 Mar 2015 15:26:31 -0500 Subject: optical gear cooling requirements In-Reply-To: <86pp8pzwpm.fsf@valhalla.seastrom.com> References: <86pp8pzwpm.fsf@valhalla.seastrom.com> Message-ID: On Tue, Mar 3, 2015 at 2:51 PM, Rob Seastrom wrote: > > You can always put baffles above and beneath to channel the air > into/from your hot/cold aisles. Makes it nice to be able to have the > connectors on whichever side is convenient. or you know, rotate the equipment in the rack... From bzs at world.std.com Tue Mar 3 20:29:15 2015 From: bzs at world.std.com (Barry Shein) Date: Tue, 3 Mar 2015 15:29:15 -0500 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> <54F31DBE.9060603@meetinghouse.net> <21748.52254.768347.50688@world.std.com> <21750.2698.430920.443976@world.std.com> Message-ID: <21750.6555.982808.967978@world.std.com> From: Scott Helms > >/em shrug > >I can't help it if you don't like real world data. >On Mar 3, 2015 2:25 PM, "Barry Shein" wrote: > >> >> Ok, then I no longer have any confidence that I understand what you >> were asserting. Generally when someone says they don't understand me I assume it's my fault for not being clear and try to clarify. Apparently you prefer to be rude. *Plonk* -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From srihari at cse.sc.edu Tue Mar 3 07:13:05 2015 From: srihari at cse.sc.edu (Srihari Nelakuditi) Date: Tue, 3 Mar 2015 02:13:05 -0500 Subject: CFP: IEEE International Conference on Network Protocols (ICNP) Message-ID: <54F55F01.1010802@cse.sc.edu> Call for Papers IEEE ICNP 2015 http://icnp15.cs.ucr.edu/ ICNP, the IEEE International Conference on Network Protocols, is the premier conference on network protocols, covering all aspects of network protocol research, including design, analysis, specification, verification, implementation, and performance. Sponsored by the IEEE, ICNP 2015 is the 23rd edition of the conference, to be held in San Francisco, CA, USA from Nov. 10-13, 2015. ====================================================================== Important dates Paper Submission May 8, 2015, 7:59 PM EST (FIRM) Acceptance Notification June 30, 2015 Camera Ready Version Aug 15, 2015 ====================================================================== We invite papers with significant, original research contributions to the field of network protocols for submission. Topics of interest include, but are not limited to: * All aspects of network protocol research including design, specification, verification, implementation, measurement, testing, and analysis * Domain-specific solutions, including protocols for network security, Internet of Things, routing, user privacy, network management, and data centers * Application-layer protocols for peer-to-peer systems, social networks, and emerging systems * Contributions to network architecture, e.g., specific algorithms and protocols for software defined networks, network virtualization, or future Internet architectures ICNP 2015 will select an accepted full paper for the best paper award. Up to two of the best papers from ICNP will be fast-tracked in the IEEE/ACM Transactions on Networking, with a streamlined journal review process. Acceptance of fast-tracked papers in ToN is not guaranteed, but is more likely than a regular submission. Submission Guidelines * All papers should adhere to the IEEE Computer conference paper formatting requirements (IEEEtran.cls) and should not exceed 10 pages with font size no smaller than 10 pt (details can be found on the submission guidelines and formatting page). * ICNP uses a double-blind review process. The identity of authors and referees will not be revealed to each other. To ensure double-blind reviewing, author names and affiliations should not appear in the paper; bibliographic references should be made in such a way as to preserve author anonymity; acknowledgement with identifiable names and funding sources should be removed. Note that own work should be cited as a third person. Papers violating this double-blind review policy will be rejected without review. * Authors need to indicate on their paper’s submission page all TPC members with whom they have conflicts of interest. * Every paper MUST be presented by an author at the conference. The author list MUST remain the same as when the paper was submitted for review, and any changes in the author list or title is forbidden without prior written permission from the TPC Co-Chairs. At least one author of an accepted paper is expected to register at the full rate of the conference and to present the paper at the conference, in order for the paper to appear in the conference proceedings and be submitted to the IEEE digital library. Papers not presented by an author at the conference will not be published in the proceedings or submitted for inclusion in the IEEE digital library. Integrity Policy Submitted papers should not be previously published nor under review by another conference or journal. In some cases, the ICNP chairs may share information about submitted papers with other conference chairs and journal editors to ensure the integrity of papers under consideration. Authors are prohibited from informing any TPC member of any identifiable information (such as titles) of their submissions. Also, papers containing plagiarized material will be subject to the IEEE plagiarism policy and will be rejected without review. Organizing Committee General Co-Chairs: Srikanth V. Krishnamurthy, University of California, Riverside Prasant Mohapatra, University of California, Davis TPC Co-Chairs: Aditya Akella, University of Wisconsin, Madison Vishal Misra, Columbia University Steering Committee: Kevin Almeroth, University of California, Santa Barbara Ken Calvert, University of Kentucky Sonia Fahmy, Purdue University Mohamed Gouda, University of Texas, Austin Timothy G. Griffin, University of Cambridge Teruo Higashino, Osaka University David Lee, HP Labs K.K. Ramakrishnan (Chair), University of California, Riverside Krishan Sabnani, Bell Laboratories ====================================================================== From ed at edgeoc.net Tue Mar 3 22:12:21 2015 From: ed at edgeoc.net (Edward Salonia) Date: Tue, 3 Mar 2015 17:12:21 -0500 Subject: optical gear cooling requirements In-Reply-To: References: Message-ID: Cisco makes an Air Plenum for front/back air flow. - M6 chassis: http://www.cisco.com/c/en/us/td/docs/optical/hardware/15454install/guide/hig15454/hig_15454M6.html#pgfId-863233 - M2 chassis: http://www.cisco.com/c/en/us/td/docs/optical/hardware/15454install/guide/hig15454/hig_15454M2.html#pgfId-628924 On Tue, Mar 3, 2015 at 9:27 AM, Alex Rubenstein wrote: > The rock has turned over for a moment and I have crawled out. It is good > to see the sunlight from time to time. > > Those who know me know my life has gotten away from networking and that > sort of thing, and I am fully immersed in datacenter design and > construction for IT type loads (blades, compute, disk, etc.). However, I am > presented with the challenge of having to deal with some optical gear > (Ciena stuff, mainly). My question: have the optical folks woken up and > made things cool front to back, or are they still in to the bottom to top > world? > > Comments and lambasting: go > > Thanks! > > > > > From jay at west.net Tue Mar 3 22:37:12 2015 From: jay at west.net (Jay Hennigan) Date: Tue, 03 Mar 2015 14:37:12 -0800 Subject: FCC form 477 geocoding Message-ID: <54F63798.3050603@west.net> The CFO here is working on FCC form 477 and tells me that he needs to enter census tract and block information for our customers. He says that the US Census site is worse than useless and the info isn't on the FCC site. What are others doing in this regard? -- -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From josh at imaginenetworksllc.com Tue Mar 3 22:44:11 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Tue, 3 Mar 2015 17:44:11 -0500 Subject: FCC form 477 geocoding In-Reply-To: <54F63798.3050603@west.net> References: <54F63798.3050603@west.net> Message-ID: Assuming you have LAT/LONG you can use the FCC API: http://www.fcc.gov/encyclopedia/form-477-census-tract-information You also need to provide your coverage. I suggest Towercoverage.com for that, though you may not be a WISP. Non-wireless I'm not sure how you'd go about it. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Tue, Mar 3, 2015 at 5:37 PM, Jay Hennigan wrote: > The CFO here is working on FCC form 477 and tells me that he needs to > enter census tract and block information for our customers. He says that > the US Census site is worse than useless and the info isn't on the FCC > site. > > What are others doing in this regard? > > -- > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > From khelms at zcorum.com Tue Mar 3 22:46:36 2015 From: khelms at zcorum.com (Scott Helms) Date: Tue, 3 Mar 2015 17:46:36 -0500 Subject: FCC form 477 geocoding In-Reply-To: <54F63798.3050603@west.net> References: <54F63798.3050603@west.net> Message-ID: Are you trying to get the census tract for each customer? If so you can get that from most of the gecoding services like Esri etc. On Mar 3, 2015 5:38 PM, "Jay Hennigan" wrote: > The CFO here is working on FCC form 477 and tells me that he needs to > enter census tract and block information for our customers. He says that > the US Census site is worse than useless and the info isn't on the FCC > site. > > What are others doing in this regard? > > -- > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > From jay at west.net Tue Mar 3 22:57:07 2015 From: jay at west.net (Jay Hennigan) Date: Tue, 03 Mar 2015 14:57:07 -0800 Subject: FCC form 477 geocoding In-Reply-To: References: <54F63798.3050603@west.net> Message-ID: <54F63C43.3040903@west.net> On 3/3/15 14:44, Josh Luthman wrote: > Assuming you have LAT/LONG you can use the FCC API: > http://www.fcc.gov/encyclopedia/form-477-census-tract-information > > You also need to provide your coverage. I suggest Towercoverage.com for > that, though you may not be a WISP. Non-wireless I'm not sure how you'd > go about it. Non-wireless, we have street address and zip codes, not lat/long. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From marka at isc.org Tue Mar 3 22:57:04 2015 From: marka at isc.org (Mark Andrews) Date: Wed, 04 Mar 2015 09:57:04 +1100 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: Your message of "Tue, 03 Mar 2015 08:07:21 -0500." References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> <54F4F500.8090303@pari.edu> <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> <000101d05567$74b58530$5e208f90$@gmail.com> <20150303051439.B14E72ABEB33@rock.dv.isc.org> <54F57656.2010804@satchell.net> <20150303122840.428C22AC5068@rock.dv.isc.org> Message-ID: <20150303225705.8DE772AC8A13@rock.dv.isc.org> In message , Scott Helms writes: > > I don't know many schools that are open at midnight to accept thumb > > drives. > > I think he was trying to point out that most school libraries, and their > computer labs, open before classes start. Ice never heard of a school > deadline that was actually in the middle of the night, so if you're working > on a paper at night it's because it's due the next day. Well now you have. See Edmodo. The kids all have accounts. The teachers all have accounts. The communication is all in the open, no private chats. Assignments are handed out and submitted with a timestamp over Edmodo. How many of you have submitted tax returns at 23:00 because you have been running late? Do you do this electronically now. > > Well kids will be kids. > > > > Very true :) > > > > > Yep. The assumption that because you are sending from home it is > > not time critical is absolutely bogus. Upstream speeds really are > > just as important as downstream speeds. It just that it is not > > normally needed as much of the time. > > This assertion is counter to the choices that consumers are making. Forget > about the access technology and it's symmetry or asymmetry for a moment and > consider the growth of WiFi in the home, which is highly asymmetrical > because clients have much lower power output and most often 0 dB gain > antennas at 2.4 and 5.8. The point is that a great percentage of the > traffic we see is from asymmetric sources even on symmetrical broadband > connections. > The other thing to consider is that LTE is asymmetrical and for the same > reasons as WiFi. It is our job as engineers to give consumers what they need even if they don't realise they needed it. > For consumers to care about symmetrical upload speeds as much as you're > saying why have they been choosing to use technologies that don't deliver > that in WiFi and LTE? In the WiFi case they're taking a symmetrical > connection to their home and making it asymmetrical. I can make a home > WiFi network operate more symmetrically by putting in multiple APs but very > few consumers take that step. When you are running a nominally 400Mbps WiFi into 100Mbps fibre you do really want to be able to fill that pipe. > I'm not done collecting all of our data yet, but just looking at what we > have right now (~17,000 APs) over half of the clients connected have an > upload rate of 5mbps or less. A just over 20% have an average upload rate > of 1mbps. Averages hide the peak demands. The last mile should handle the peak demands. Further upstream you get the over subscription savings. Looking at averages and saying that they define the needs limits is *bad* engineering. For POTS you would get a few hertz if you did that. The averaging of POTS comes once you combine multiple sources together at the exchange. Even then you look at the peak periods not the daily average. Asymetry is pushing oversubscription too close to the consumer. It is a undesirable but sometimes necessary trade off. Asymetry traffic volumes don't mean asymetric speeds are desirable. > BTW, the reason we're working on the WiFi data is that we think this is a > huge problem, because consumers don't separate the performance of the in > home WiFi from their overall broadband experience and we need to > dramatically improve the in home WiFi experience to increase customer > satisfaction. There are lots of places that need to fixed. You address all of them in parallel. There are enough engineers in the world to do that. Just because WiFi has issues doesn't mean the next link doesn't have issues as well. > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > --089e010d8c2ae4b8c20510620314 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > >


> >
> > I don't know many schools that are open at midnight to accept thum= > b
> > drives.

>

I think he was trying to point out that most school librarie= > s, and their computer labs, open before classes start.=C2=A0 Ice never hear= > d of a school deadline that was actually in the middle of the night, so if = > you're working on a paper at night it's because it's due the ne= > xt day.

>

>
> > Well kids will be kids.
> >

>

Very true :)

>

>
> > Yep.=C2=A0 The assumption that because you are sending from home it is= >
> > not time critical is absolutely bogus.=C2=A0 Upstream speeds really ar= > e
> > just as important as downstream speeds.=C2=A0 It just that it is not r> > > normally needed as much of the time.

>

This assertion is counter to the choices that consumers are = > making.=C2=A0 Forget about the access technology and it's symmetry or a= > symmetry for a moment and consider the growth of WiFi in the home, which is= > highly asymmetrical because clients have much lower power output and most = > often 0 dB gain antennas at 2.4 and 5.8.=C2=A0 The point is that a great pe= > rcentage of the traffic we see is from asymmetric sources even on symmetric= > al broadband connections.
> The other thing to consider is that LTE is asymmetrical and for the same re= > asons as WiFi.=C2=A0

>

For consumers to care about symmetrical upload speeds as muc= > h as you're saying why have they been choosing to use technologies that= > don't deliver that in WiFi and LTE?=C2=A0 In the WiFi case they're= > taking a symmetrical connection to their home and making it asymmetrical.= > =C2=A0 I can make a home WiFi network operate more symmetrically by putting= > in multiple APs but very few consumers take that step.

>

I'm not done collecting all of our data yet, but just lo= > oking at what we have right now (~17,000 APs) over half of the clients conn= > ected have an upload rate of 5mbps or less.=C2=A0 A just over 20% have an a= > verage upload rate of 1mbps.

>

BTW, the reason we're working on the WiFi data is that w= > e think this is a huge problem, because consumers don't separate the pe= > rformance of the in home WiFi from their overall broadband experience and w= > e need to dramatically improve the in home WiFi experience to increase cust= > omer satisfaction.

>

>
> > Mark
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= > =C2=A0 =C2=A0INTERNET: marka at isc.org<= > br> >

> > --089e010d8c2ae4b8c20510620314-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From josh at imaginenetworksllc.com Tue Mar 3 22:59:49 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Tue, 3 Mar 2015 17:59:49 -0500 Subject: FCC form 477 geocoding In-Reply-To: <54F63C43.3040903@west.net> References: <54F63798.3050603@west.net> <54F63C43.3040903@west.net> Message-ID: Well you'll need to translate those into addresses. That should be easy with Google or Bing. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mar 3, 2015 5:57 PM, "Jay Hennigan" wrote: > On 3/3/15 14:44, Josh Luthman wrote: > > Assuming you have LAT/LONG you can use the FCC API: > > http://www.fcc.gov/encyclopedia/form-477-census-tract-information > > > > You also need to provide your coverage. I suggest Towercoverage.com for > > that, though you may not be a WISP. Non-wireless I'm not sure how you'd > > go about it. > > Non-wireless, we have street address and zip codes, not lat/long. > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > From jay at west.net Tue Mar 3 23:06:08 2015 From: jay at west.net (Jay Hennigan) Date: Tue, 03 Mar 2015 15:06:08 -0800 Subject: FCC form 477 geocoding In-Reply-To: References: <54F63798.3050603@west.net> <54F63C43.3040903@west.net> Message-ID: <54F63E60.5040509@west.net> On 3/3/15 14:59, Josh Luthman wrote: > Well you'll need to translate those into addresses. That should be easy > with Google or Bing. We have the addresses, need census tract and block. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From sean at donelan.com Tue Mar 3 23:13:28 2015 From: sean at donelan.com (Sean Donelan) Date: Tue, 3 Mar 2015 18:13:28 -0500 (EST) Subject: FCC form 477 geocoding In-Reply-To: <54F63E60.5040509@west.net> References: <54F63798.3050603@west.net> <54F63C43.3040903@west.net> <54F63E60.5040509@west.net> Message-ID: On Tue, 3 Mar 2015, Jay Hennigan wrote: >> Well you'll need to translate those into addresses. That should be easy >> with Google or Bing. > > We have the addresses, need census tract and block. For small address batches you can use the Census Geocoder. The documentation is at http://www.census.gov/geo/maps-data/data/geocoder.html Basically you upload a CSV file addresses and you'll get back FIPS codes for state, county, census tract and census block for each address. Concatenate the FIPS state+county+censustract code (not the census block). If you have lots of customers in many different census tracts, you'll probably want a bulk geocoding product. From tetherow at shwisp.net Tue Mar 3 23:14:49 2015 From: tetherow at shwisp.net (Sam Tetherow) Date: Tue, 03 Mar 2015 17:14:49 -0600 Subject: FCC form 477 geocoding In-Reply-To: <54F63E60.5040509@west.net> References: <54F63798.3050603@west.net> <54F63C43.3040903@west.net> <54F63E60.5040509@west.net> Message-ID: <54F64069.6010000@shwisp.net> Address to lat/lng using google api http://maps.googleapis.com/maps/api/geocode/json?address=$address&sensor=true Lat/Lng to Census Block via FCC http://data.fcc.gov/api/block/2010/find?latitude=$latitude&longitude=$longitude&showall=true&format=JSON On 03/03/2015 05:06 PM, Jay Hennigan wrote: > On 3/3/15 14:59, Josh Luthman wrote: >> Well you'll need to translate those into addresses. That should be easy >> with Google or Bing. > We have the addresses, need census tract and block. > > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV From josh at imaginenetworksllc.com Tue Mar 3 23:32:41 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Tue, 3 Mar 2015 18:32:41 -0500 Subject: FCC form 477 geocoding In-Reply-To: <54F64069.6010000@shwisp.net> References: <54F63798.3050603@west.net> <54F63C43.3040903@west.net> <54F63E60.5040509@west.net> <54F64069.6010000@shwisp.net> Message-ID: Use Sam's suggestions. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mar 3, 2015 6:18 PM, "Sam Tetherow" wrote: > Address to lat/lng using google api > http://maps.googleapis.com/maps/api/geocode/json?address= > $address&sensor=true > > Lat/Lng to Census Block via FCC > http://data.fcc.gov/api/block/2010/find?latitude=$latitude& > longitude=$longitude&showall=true&format=JSON > > > On 03/03/2015 05:06 PM, Jay Hennigan wrote: > >> On 3/3/15 14:59, Josh Luthman wrote: >> >>> Well you'll need to translate those into addresses. That should be easy >>> with Google or Bing. >>> >> We have the addresses, need census tract and block. >> >> >> -- >> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net >> Impulse Internet Service - http://www.impulse.net/ >> Your local telephone and internet company - 805 884-6323 - WB6RDV >> > > From surfer at mauigateway.com Tue Mar 3 23:49:32 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 3 Mar 2015 15:49:32 -0800 Subject: FCC form 477 geocoding Message-ID: <20150303154932.39D1D509@m0005296.ppops.net> --- tetherow at shwisp.net wrote: From: Sam Tetherow Lat/Lng to Census Block via FCC http://data.fcc.gov/api/block/2010/find?latitude=$latitude&longitude=$longitude&showall=true&format=JSON -------------------------------------- HTTP Status 404 - Not Found type Status report message Not Found description The requested resource (Not Found) is not available. Apache Tomcat/6.0.30 scott From josh at imaginenetworksllc.com Wed Mar 4 00:01:49 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Tue, 3 Mar 2015 19:01:49 -0500 Subject: FCC form 477 geocoding In-Reply-To: <20150303154932.39D1D509@m0005296.ppops.net> References: <20150303154932.39D1D509@m0005296.ppops.net> Message-ID: Did you do actual coordinates or just click the link? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mar 3, 2015 6:50 PM, "Scott Weeks" wrote: > > > --- tetherow at shwisp.net wrote: > From: Sam Tetherow > > Lat/Lng to Census Block via FCC > > http://data.fcc.gov/api/block/2010/find?latitude=$latitude&longitude=$longitude&showall=true&format=JSON > -------------------------------------- > > > HTTP Status 404 - Not Found > > type Status report > > message Not Found > > description The requested resource (Not Found) is not available. > > Apache Tomcat/6.0.30 > > > > scott > From sfrost at snowman.net Wed Mar 4 00:11:11 2015 From: sfrost at snowman.net (Stephen Frost) Date: Tue, 3 Mar 2015 19:11:11 -0500 Subject: FCC form 477 geocoding In-Reply-To: <54F63798.3050603@west.net> References: <54F63798.3050603@west.net> Message-ID: <20150304001111.GG29780@tamriel.snowman.net> * Jay Hennigan (jay at west.net) wrote: > The CFO here is working on FCC form 477 and tells me that he needs to > enter census tract and block information for our customers. He says that > the US Census site is worse than useless and the info isn't on the FCC > site. The US Census Tiger data set is available from their FTP site in Shapefile format. PostGIS (the spatial extension to PostgreSQL) includes the Tiger geocoder which can be used to geocode addresses, based on that Census data. The PostGIS Tiger extension also includes scripts to load the data into a PostGIS-enabled PostgreSQL database. If there are questions about the geocoder, I can try and answer them, I had a hand in writing it. Thanks! Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From surfer at mauigateway.com Wed Mar 4 00:13:21 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 3 Mar 2015 16:13:21 -0800 Subject: FCC form 477 geocoding Message-ID: <20150303161321.39D1D362@m0005296.ppops.net> > --- tetherow at shwisp.net wrote: > From: Sam Tetherow > > Lat/Lng to Census Block via FCC > > http://data.fcc.gov/api/block/2010/find?latitude=$latitude&longitude=$longitude&showall=true&format=JSON > -------------------------------------- >> ---"Scott Weeks" wrote >> HTTP Status 404 - Not Found --- josh at imaginenetworksllc.com wrote: From: Josh Luthman Did you do actual coordinates or just click the link? --------------------------------- Clicked the link expecting to put in lat/lon after. scott From huc at ieee.org Tue Mar 3 20:47:04 2015 From: huc at ieee.org (huc@ieee) Date: Tue, 3 Mar 2015 21:47:04 +0100 Subject: [OT]call for backers: open source hardware for networking innovation (ONetSwitch) Message-ID: <44C748D7-F4EC-41DD-A809-37863D722AB2@ieee.org> Sorry for a little bit off topic. This email is to inform you a new open source hardware for networking innovation called ONetSwitch. It is an all-programmable networking platform combining ARM and FPGA in a 17cm*13cm area (notebook size) for testing and verifying research idea related to networking. Different from previous FPGA develop board like NetFPGA/Xilinx PCIe board, host PC is not required any more for ONetSwitch, and it is smaller, cheaper, and more power efficient. and more flexible. We have launched the ONetSwitch project on Kickstarter.com weeks ago. You can get an abstract from the short video, which will not take you long to get our idea :-) https://www.kickstarter.com/projects/onetswitch/onetswitch-open-source-hardware-for-networking We had a paper at ONS 2014 presenting the preliminary design of ONetSwitch (https://www.usenix.org/system/files/conference/ons2014/ons2014-paper-hu_chengchen.pdf) and a demo at SIGCOMM'14 setting a data center testbed on only desktop using ONetSwitch (http://nskeylab.xjtu.edu.cn/people/huc/Pub/DesktopDC_2014.pdf). In the new version now at kickstarter, we add further physical support on 802.11 AC, mSATA, which suits for more scenarios. Also, we have open source ref. design and supporting wiki available at github (https://github.com/MeshSr/wiki/wiki/REF-OpenFlowSwitch-HWFT). The processing logic can be modified in both software (ARM) and hardware (FPGA) to fit your own needs. Although it is currently highlighted mainly on SDN and DCN, we aim to provide the research community a way to set their testbeds for any networking innovations easily. I send the info. about ONetSwitch to this mail list since I think it may be useful to guys in this community. Please do us a favor and back us to get your own programmable testbed. We believe ONetSwitch would give much help to your research and development work. Also, can you help distribute it to friends and colleagues who will be interested with this? Even for the guys, who do not need ONetSwitch but think it is good, we greatly appreciate you to back us with $1 for encouraging. Regards, Chengchen ======================================================================= Dr. Chengchen Hu, ERCIM Fellow Norwegian University of Science and Technology (NTNU) Associate Professor (Sabbatical leave till Oct., 2015) Xi'an Jiaotong University http://nskeylab.xjtu.edu.cn/people/cchu ======================================================================= From ops.lists at gmail.com Tue Mar 3 21:08:22 2015 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 4 Mar 2015 02:38:22 +0530 Subject: M3AAWG 34 in Dublin - public call for papers Message-ID: fyi > From: "Alec Peterson" > To: "technical at mailman.m3aawg.org" > Date: Tue, Mar 3, 2015 11:32 PM > Subject: [Technical] M3AAWG 34 Call for Papers > > > The 34th General Meeting of the Messaging Malware Mobile Anti-Abuse Working Group (M3AAWG) will be held in Dublin, Ireland from June 8-11, 2015. You may find information about all of our upcoming meetings at http://www.maawg.org/events/upcoming_meetings. The Technical Committee is currently seeking proposals for sessions for our upcoming meeting in Dublin. Sessions may involve single speakers or panels with up to four participants and are typically 60 minutes long. A successful proposal is of a technical nature that is relevant to the operationally-focused participants of M3AAWG. Topics of relevance include but are not limited to: > + DANE / DNSSEC > + DMARC / (DMARC.org) [http://DMARC.org] > + IPv6 (other than mailbox provider perspective) > + Pervasive Monitoring / Encryption Efforts (Messaging Security) > + Unique Attack and/or Mitigation Analysis > + Emerging Threats > + Viruses, Worms, Trojans, and other Malware > + Exploit Kits > + Pay-Per-Install Campaigns > + Cybercrime Underground Economy > + Targeted Attacks > + Advanced Persistent Threats (APTs) > + Security Issues involving the 'Internet of Things' > + Security Issues involving Critical Infrastructure > + Social Engineering > + Phishing and Other Scams > + The evolution of mobile malware (e.g., NotCompatible) > + Mobile penetration of non-mobile networks barriers > + The rise of Over-the-Top sources of mobile messaging abuse > Please submit your session proposals to https://www.maawg.org/submissions by May 1, 2015 at the latest. Travel assistance is available for special cases. All participants must adhere to the M3AAWG Conduct Policy at https://www.maawg.org/page/m3aawg-conduct-policy. Media will be permitted into sessions only with the speakers’ advance consent. The contents of this CFP are public. Please feel free to redistribute this document. > Alec > > > ALEC H PETERSON > cto > tel +1 443 656 3322 > twitter @ahpeterson > email alec at messagesystems.com > > From jay at west.net Wed Mar 4 01:43:15 2015 From: jay at west.net (Jay Hennigan) Date: Tue, 03 Mar 2015 17:43:15 -0800 Subject: FCC form 477 geocoding In-Reply-To: References: <54F63798.3050603@west.net> <54F63C43.3040903@west.net> <54F63E60.5040509@west.net> Message-ID: <54F66333.6040205@west.net> On 3/3/15 15:13, Sean Donelan wrote: > On Tue, 3 Mar 2015, Jay Hennigan wrote: >>> Well you'll need to translate those into addresses. That should be easy >>> with Google or Bing. >> >> We have the addresses, need census tract and block. > > For small address batches you can use the Census Geocoder. The > documentation is at > > http://www.census.gov/geo/maps-data/data/geocoder.html > > Basically you upload a CSV file addresses and you'll get back FIPS > codes for state, county, census tract and census block for each address. > Concatenate the FIPS state+county+censustract code (not the census block). This turns out to be the least hassle, thanks to all in the group who replied. Note that although the Census website says that it will handle a CSV file of up to 1000 addresses, in reality it pukes on anything greater than about 100 at a time. -- -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From hannigan at gmail.com Wed Mar 4 01:52:44 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 3 Mar 2015 20:52:44 -0500 Subject: optical gear cooling requirements In-Reply-To: References: Message-ID: Alex, Remember the Ascend MAX TNT and the sideways left-right airflow? The preferred method of deployment was three tall in a two post rack, mid mount. At the end of about the 10th row you could literally cook a steak and subsequently burn out the gear beyond that point. We fashioned our own dividers to keep airflow from forming a jet down the line via ACE hardware angle brackets that we cored to EIA screw spec and sheets of 1/4" plexiglass mounted between. Cheap as heck and worked like a champ. Airflow redirection can work. Building a plenum for this could be relatively cheap and easy with a small amount of sheet metal and a pair of tin sheers. Don't forget the warranty; I'd check for anything explicit around airflow. Let us know what you do, love the innovation. Best, -M< On Tue, Mar 3, 2015 at 9:27 AM, Alex Rubenstein wrote: > The rock has turned over for a moment and I have crawled out. It is good > to see the sunlight from time to time. > > Those who know me know my life has gotten away from networking and that > sort of thing, and I am fully immersed in datacenter design and > construction for IT type loads (blades, compute, disk, etc.). However, I am > presented with the challenge of having to deal with some optical gear > (Ciena stuff, mainly). My question: have the optical folks woken up and > made things cool front to back, or are they still in to the bottom to top > world? > > Comments and lambasting: go > > Thanks! > > > > > From cma at cmadams.net Wed Mar 4 02:01:57 2015 From: cma at cmadams.net (Chris Adams) Date: Tue, 3 Mar 2015 20:01:57 -0600 Subject: optical gear cooling requirements In-Reply-To: References: Message-ID: <20150304020157.GB27040@cmadams.net> Once upon a time, Martin Hannigan said: > Remember the Ascend MAX TNT and the sideways left-right airflow? The > preferred method of deployment was three tall in a two post rack, mid > mount. Shoot, only three tall? With the original dual-slot modem cards and separate HDLC cards, it took three chassis just to handle one DS3. Throw another couple in there to start the next DS3 and get cooking! Of course, they came in the crate with that little piece of sheet metal air deflector that I don't think I ever saw how to mount. We had something (Redback SMS-500?) that also cooled side-to-side, but in the opposite direction; had to make sure it was "upwind" of the TNTs. -- Chris Adams From cbone at newroadstelecom.com Wed Mar 4 02:08:35 2015 From: cbone at newroadstelecom.com (Conley Bone) Date: Tue, 03 Mar 2015 20:08:35 -0600 Subject: Cox Communications Peering Message-ID: <54F66923.7050705@newroadstelecom.com> Anyone have a contact with Cox for peering? I have used their peering address, but don't get a reply. Thanks, Conley From nanog at ics-il.net Wed Mar 4 03:02:21 2015 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 3 Mar 2015 21:02:21 -0600 (CST) Subject: Optic Vendor Coding Question In-Reply-To: <15810926.10446.1425438112171.JavaMail.mhammett@ThunderFuck> Message-ID: <768625.10451.1425438146465.JavaMail.mhammett@ThunderFuck> Do Dell 8132s have SFP+ vendor code issues? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com From cbone at newroadstelecom.com Wed Mar 4 14:51:14 2015 From: cbone at newroadstelecom.com (Conley Bone) Date: Wed, 04 Mar 2015 08:51:14 -0600 Subject: Cox Communications Peering In-Reply-To: <54F66923.7050705@newroadstelecom.com> References: <54F66923.7050705@newroadstelecom.com> Message-ID: <54F71BE2.3090806@newroadstelecom.com> Someone suggested I rephrase my question... Does anyone have a contact at Cox for *paid* peering? I realize I am not going to get settlement free peering with Cox, but I have a need to reduce the number of hops between my network and theirs to shorten the distance between some of my customers that are on the Cox network. On 3/3/15 8:08 PM, Conley Bone wrote: > Anyone have a contact with Cox for peering? > I have used their peering address, but don't get a reply. > > Thanks, > Conley -- Conley Bone Newroads Telecom 300 Towson Ave. Fort Smith, AR 72901 479-424-1674 From lowen at pari.edu Wed Mar 4 14:54:06 2015 From: lowen at pari.edu (Lamar Owen) Date: Wed, 4 Mar 2015 09:54:06 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> Message-ID: <54F71C8E.1050302@pari.edu> On 03/03/2015 08:07 AM, Scott Helms wrote: > For consumers to care about symmetrical upload speeds as much as you're > saying why have they been choosing to use technologies that don't deliver > that in WiFi and LTE? For consumers to have choice, there must be an available alternative that is affordable. From aledm at qix.co.uk Wed Mar 4 14:57:31 2015 From: aledm at qix.co.uk (Aled Morris) Date: Wed, 4 Mar 2015 14:57:31 +0000 Subject: Cox Communications Peering In-Reply-To: <54F71BE2.3090806@newroadstelecom.com> References: <54F66923.7050705@newroadstelecom.com> <54F71BE2.3090806@newroadstelecom.com> Message-ID: Generic advice... I'd be more inclined to find someone who already peers with them, who can sell you partial transit; especially if they can hand this to you at a location where this peering happens. Aled On 4 March 2015 at 14:51, Conley Bone wrote: > Someone suggested I rephrase my question... > > Does anyone have a contact at Cox for *paid* peering? I realize I am not > going to get settlement free peering with Cox, but I have a need to reduce > the number of hops between my network and theirs to shorten the distance > between some of my customers that are on the Cox network. > > On 3/3/15 8:08 PM, Conley Bone wrote: > >> Anyone have a contact with Cox for peering? >> I have used their peering address, but don't get a reply. >> >> Thanks, >> Conley >> > > -- > Conley Bone > Newroads Telecom > 300 Towson Ave. > Fort Smith, AR 72901 > 479-424-1674 > From dave.taht at gmail.com Wed Mar 4 16:26:00 2015 From: dave.taht at gmail.com (Dave Taht) Date: Wed, 4 Mar 2015 08:26:00 -0800 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <000101d05567$74b58530$5e208f90$@gmail.com> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> <54F4F500.8090303@pari.edu> <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> <000101d05567$74b58530$5e208f90$@gmail.com> Message-ID: On Mon, Mar 2, 2015 at 8:06 PM, Chuck Church wrote: > Since this has turned into a discussion on upload vs download speed, figured I'd throw in a point I haven't really brought up. For the most part, uploading isn't really a time-sensitive activity to the general (as in 99% of the ) public. Uploading a bunch of facebook photos, you hit upload, and then expect it to take x amount of time. Could be 30 seconds, could be 30 minutes. Everyone expects that wait. Sending a large email attachment, you hit send, and then get back to doing something else. There just aren't that many apps out there that have a dependence on time-sensitive upload performance. But In the bufferbloated era, your upload just trashed he network for everyone else on the link. https://gettys.wordpress.com/2012/02/01/bufferbloat-demonstration-videos/ > On download, of course no wants to see buffering on their cat videos or watching Netflix. Thus the high speed download. Honesty, I'm willing to bet that even a random sampling of NANOG people would show their download data quantity to be 10x what their upload quantity is in a day. For average users, probably much more than 10x. Why some folks are insisting upload is vital just can't be true for normal home users. > Those households trying to do 5 simultaneous Skype sessions aren't typical. A geeky household with dad doing skype, mom uploading to facebook, a kid doing a game, and another kid doing netflix, however, is common. And, it is truly amazing how many households have more than one device per person nowadays. Small businesses (currently) have it worse, if any of the users try to combine these things. > Chuck > -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb From dave.taht at gmail.com Wed Mar 4 16:28:03 2015 From: dave.taht at gmail.com (Dave Taht) Date: Wed, 4 Mar 2015 08:28:03 -0800 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> <54F4F500.8090303@pari.edu> <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> <000101d05567$74b58530$5e208f90$@gmail.com> <20150303051439.B14E72ABEB33@rock.dv.isc.org> <54F57656.2010804@satchell.net> <20150303122840.428C22AC5068@rock.dv.isc.org> Message-ID: On Tue, Mar 3, 2015 at 5:07 AM, Scott Helms wrote: >> >> I don't know many schools that are open at midnight to accept thumb >> drives. > > I think he was trying to point out that most school libraries, and their > computer labs, open before classes start. Ice never heard of a school > deadline that was actually in the middle of the night, so if you're working > on a paper at night it's because it's due the next day. > >> >> Well kids will be kids. >> > > Very true :) > >> >> Yep. The assumption that because you are sending from home it is >> not time critical is absolutely bogus. Upstream speeds really are >> just as important as downstream speeds. It just that it is not >> normally needed as much of the time. > > This assertion is counter to the choices that consumers are making. Forget > about the access technology and it's symmetry or asymmetry for a moment and > consider the growth of WiFi in the home, which is highly asymmetrical > because clients have much lower power output and most often 0 dB gain > antennas at 2.4 and 5.8. The point is that a great percentage of the > traffic we see is from asymmetric sources even on symmetrical broadband > connections. > The other thing to consider is that LTE is asymmetrical and for the same > reasons as WiFi. > > For consumers to care about symmetrical upload speeds as much as you're > saying why have they been choosing to use technologies that don't deliver > that in WiFi and LTE? In the WiFi case they're taking a symmetrical > connection to their home and making it asymmetrical. I can make a home > WiFi network operate more symmetrically by putting in multiple APs but very > few consumers take that step. > > I'm not done collecting all of our data yet, but just looking at what we > have right now (~17,000 APs) over half of the clients connected have an > upload rate of 5mbps or less. A just over 20% have an average upload rate > of 1mbps. > > BTW, the reason we're working on the WiFi data is that we think this is a > huge problem, because consumers don't separate the performance of the in > home WiFi from their overall broadband experience and we need to > dramatically improve the in home WiFi experience to increase customer > satisfaction. +10! If you would like to talk to other researchers poking deeply into these fronts, also equipped with large data sets and some rapidly evolving analysis tools, please talk to me offlist. >> >> Mark >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb From nick at foobar.org Wed Mar 4 16:39:44 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 04 Mar 2015 16:39:44 +0000 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> <54F4F500.8090303@pari.edu> <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> <000101d05567$74b58530$5e208f90$@gmail.com> Message-ID: <54F73550.9090608@foobar.org> On 04/03/2015 16:26, Dave Taht wrote: > A geeky household with dad doing skype, mom uploading to facebook, a > kid doing a game, and another kid doing netflix, however, is common. > And, it is truly amazing how many households have more than one device > per person nowadays. and $kid running a bittorrent hub, maxing out bandwidth in both directions. Nick From dave.taht at gmail.com Wed Mar 4 16:56:00 2015 From: dave.taht at gmail.com (Dave Taht) Date: Wed, 4 Mar 2015 08:56:00 -0800 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <54F73550.9090608@foobar.org> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> <54F4F500.8090303@pari.edu> <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> <000101d05567$74b58530$5e208f90$@gmail.com> <54F73550.9090608@foobar.org> Message-ID: On Wed, Mar 4, 2015 at 8:39 AM, Nick Hilliard wrote: > On 04/03/2015 16:26, Dave Taht wrote: >> A geeky household with dad doing skype, mom uploading to facebook, a >> kid doing a game, and another kid doing netflix, however, is common. >> And, it is truly amazing how many households have more than one device >> per person nowadays. > > and $kid running a bittorrent hub, maxing out bandwidth in both directions. Honestly, if you dramatically improve uplink and downlink latencies by adopting fair queueing + aqm on the cpe and headend - even bittorrent becomes a lot less of a problem. Home networks get slower, but not unusable. Really thorough paper on this: http://perso.telecom-paristech.fr/~drossi/paper/rossi14comnet-b.pdf While I do have some detailed data on torrent's behavior under fq_codel now, I haven't got it together enough to publish, (the above work is lagging behind). These days I basically just say that stuff in IW10 slow start (e.g. web traffic) punches (bittorrent) uTP traffic (no IW10) aside, the FQ bits in fq_codel make everything else work pretty well on low rate traffic like videoconferencing/voip/dns/web in general, the aqm bits keep overall queue links low on any fat flows, and the only major problem remain is torrent using IW10 over tcp inadvertently while competing with other single stream download/upload traffic. You get your edge device configured right, and you're golden, no matter how many darn geeky kids you have. http://burntchrome.blogspot.com/2014_05_01_archive.html Admittedly a little classification can help, on torrent, and I certainly regard the default number of peers (6-50) to be a bit much. You don't need to "just believe" me, please feel free to try what is in openwrt barrier breaker and chaos calmer. I never notice what the kids are doing on my link anymore, nor do they notice me. > Nick > -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb From test12 at implix.com Wed Mar 4 19:19:36 2015 From: test12 at implix.com (Grzegorz Dabrowski) Date: Wed, 04 Mar 2015 20:19:36 +0100 Subject: Looking some one from advance technical help from Godaddy Message-ID: Hi, As in subject because I'm bashing my head against first line of support and they said I'm wrong good bye. So would somebody be so kind and write me privately (It's about GLUE record and where they came from) Many Thanks, -- Greg From jfbeam at gmail.com Wed Mar 4 21:04:33 2015 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 04 Mar 2015 16:04:33 -0500 Subject: optical gear cooling requirements In-Reply-To: References: Message-ID: On Tue, 03 Mar 2015 20:52:44 -0500, Martin Hannigan wrote: > Remember the Ascend MAX TNT and the sideways left-right airflow? ... Indeed I do. I see you've heard the story of PSINet melting components as well. We used USR(3Com) TotalControl hardware: vertical venting. The chimney effect was impressive. (65F in, 100+ -- sometimes 120 -- out.) (I've complained for over a decade about $DAYJOB building crap with side-to-side venting.) --Ricky From jay at west.net Wed Mar 4 21:33:27 2015 From: jay at west.net (Jay Hennigan) Date: Wed, 04 Mar 2015 13:33:27 -0800 Subject: optical gear cooling requirements In-Reply-To: References: Message-ID: <54F77A27.1090500@west.net> On 3/4/15 13:04, Ricky Beam wrote: > On Tue, 03 Mar 2015 20:52:44 -0500, Martin Hannigan > wrote: >> Remember the Ascend MAX TNT and the sideways left-right airflow? > ... > > Indeed I do. I see you've heard the story of PSINet melting components > as well. > > We used USR(3Com) TotalControl hardware: vertical venting. The chimney > effect was impressive. (65F in, 100+ -- sometimes 120 -- out.) We used Livingston Portmaster 3 back in the day. Front to back ventilation, ran cool as a cucumber, plug it in and it just worked. Awesome gear until Lucent bought the company to kill the product in favor of their Ascend TNT space heaters. -- -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From SNaslund at medline.com Wed Mar 4 21:37:58 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 4 Mar 2015 21:37:58 +0000 Subject: optical gear cooling requirements In-Reply-To: References: Message-ID: <9578293AE169674F9A048B2BC9A081B40157265C0A@MUNPRDMBXA1.medline.com> I remember that there was an Ascend DSLAM built on the same chassis and it was collocated by someone into Ameritech central offices. Ameritech shut them all down saying that there was no way, no how that the device could be NEBS compliant. I don't know how that fight ever turned out, they were not ours. Side to side airflow is really bad news. Even with vertical you could at least mount some kind of baffles and lose a few Us. With side to side it is really hard to find a way to redirect air with the flanges in the way. Steven Naslund Chicago IL > Remember the Ascend MAX TNT and the sideways left-right airflow? >... From SNaslund at medline.com Wed Mar 4 21:47:28 2015 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 4 Mar 2015 21:47:28 +0000 Subject: optical gear cooling requirements In-Reply-To: <54F77A27.1090500@west.net> References: <54F77A27.1090500@west.net> Message-ID: <9578293AE169674F9A048B2BC9A081B40157265C64@MUNPRDMBXA1.medline.com> >> On Tue, 03 Mar 2015 20:52:44 -0500, Martin Hannigan >> >> wrote: >>> Remember the Ascend MAX TNT and the sideways left-right airflow? >> ... >> >> Indeed I do. I see you've heard the story of PSINet melting components >> as well. >> >> We used USR(3Com) TotalControl hardware: vertical venting. The chimney >> effect was impressive. (65F in, 100+ -- sometimes 120 -- out.) TotalControl stuff was a tank but to get the density you need, you had to give them "TotalControl" of all of your rack space. >We used Livingston Portmaster 3 back in the day. Front to back ventilation, ran cool as a cucumber, plug it in and it just worked. >Awesome gear until Lucent bought the company to kill the product in favor of their Ascend TNT space heaters. Yep, we called them the "Livingstones" because they were stone age stuff but would never die. We had TONS is issues with the Ascend stuff. On the Ascend Max stuff we had a big problem with their power supplies blowing up. After lots of research we found the same third party supplier and ordered the same voltage with twice the current capacity and had no more problems. They refused to acknowledge that the power supplies were sized too small even after we proved it by replacing them with third party stuff. We preferred the TotalControl stuff but in the days of the modem standards wars, certain modems worked better with Ascend and some with USR so we maintained some of both. We were in firmware fix hell on both the USRs and the Ascends for a period of years. Steven Naslund Chicago IL From nick at foobar.org Wed Mar 4 21:54:10 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 04 Mar 2015 21:54:10 +0000 Subject: optical gear cooling requirements In-Reply-To: <54F77A27.1090500@west.net> References: <54F77A27.1090500@west.net> Message-ID: <54F77F02.7040803@foobar.org> On 04/03/2015 21:33, Jay Hennigan wrote: > We used Livingston Portmaster 3 back in the day. Front to back > ventilation, ran cool as a cucumber, plug it in and it just worked. > Awesome gear until Lucent bought the company to kill the product in > favor of their Ascend TNT space heaters. Ascend kit was a horror to deal with. I ran isdn dialin on some of their lower end kit at one stage. It only worked because I put it on a power timer which power-cycled it twice a day. +1 on portmasters, though. Nick From colinj at gt86car.org.uk Wed Mar 4 22:06:21 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Wed, 4 Mar 2015 22:06:21 +0000 Subject: optical gear cooling requirements In-Reply-To: References: Message-ID: <36E48940-C790-40C3-8746-702445E65A5B@gt86car.org.uk> energis pop the cab doors would not open due to heat warping after loaded with two tnt max colin Sent from my iPhone > On 4 Mar 2015, at 21:04, "Ricky Beam" wrote: > >> On Tue, 03 Mar 2015 20:52:44 -0500, Martin Hannigan wrote: >> Remember the Ascend MAX TNT and the sideways left-right airflow? > ... > > Indeed I do. I see you've heard the story of PSINet melting components as well. > > We used USR(3Com) TotalControl hardware: vertical venting. The chimney effect was impressive. (65F in, 100+ -- sometimes 120 -- out.) > > (I've complained for over a decade about $DAYJOB building crap with side-to-side venting.) > > --Ricky From matthew at corp.crocker.com Wed Mar 4 22:19:49 2015 From: matthew at corp.crocker.com (Matthew Crocker) Date: Wed, 4 Mar 2015 17:19:49 -0500 Subject: optical gear cooling requirements In-Reply-To: <54F77F02.7040803@foobar.org> References: <54F77A27.1090500@west.net> <54F77F02.7040803@foobar.org> Message-ID: <8B84AC2D-6D5A-40BA-8329-C1670C607835@corp.crocker.com> > > On Mar 4, 2015, at 4:54 PM, Nick Hilliard wrote: > > On 04/03/2015 21:33, Jay Hennigan wrote: >> We used Livingston Portmaster 3 back in the day. Front to back >> ventilation, ran cool as a cucumber, plug it in and it just worked. >> Awesome gear until Lucent bought the company to kill the product in >> favor of their Ascend TNT space heaters. > > Ascend kit was a horror to deal with. I ran isdn dialin on some of their > lower end kit at one stage. It only worked because I put it on a power > timer which power-cycled it twice a day. > > +1 on portmasters, though. > My ISP grew up on Livingston Postmaster 2e & 3s. I even had a Postmaster 4 for a bit. Lucent swapped that out for an APX 8000. I still have an Ascend TNT running the remainder of my modem pool. 8 Active users on it at the moment. Recently won a state contract for IP services. The very first order was for a chunk of dialup accounts so the Department of Conservation and Recreation could call in from their firepowers. It just keeps chugging away in a forgotten corner of my datacenter. > Nick > > From tom at ninjabadger.net Wed Mar 4 23:34:58 2015 From: tom at ninjabadger.net (Tom Hill) Date: Wed, 04 Mar 2015 23:34:58 +0000 Subject: Multiple Spanning Tree Instance 0 In-Reply-To: References: <49EE1A35457387418410F97564A3752B013673ECC2@MSG6.westman.int> Message-ID: <54F796A2.7090804@ninjabadger.net> On 27/02/15 11:03, Chris Marget wrote: > On Wed, Feb 25, 2015 at 4:09 PM, Graham Johnston > wrote: > >> > We are planning a migration from Rapid PVST+ to Multiple Spanning Tree to >> > better support a mixed vendor environment. My question today is about MST >> > Instance 0. In practice do you map any VLANs there other than VLAN 1? > > I'd hoped to see some responses to this thread because I recently had some > awkward moments with a vendor after discovering that their switch wouldn't > allow me to map VLANs to STP instances in an arbitrary manner. I took the > position that the implementation was faulty, their position was more along > the lines of "Well, why would you want to do that anyway?" > > Addressing the question directly, I know of two switching platforms which > force the operator to map VLANs other than 1 into instance 0. > > Some Broadcom FASTPATH based platforms fail to mention VLAN 4094 in any > 'show spanning-tree' commands, but always maps it to instance 0. > > The implementation of MST available on Cumulus Linux only supports instance > 0, maps all VLANs there. My Cumulus experience is a bit dated, this may > have changed in the last year. Every vendor of switches has, for a multitude of reasons that I don't want to have to list, implemented VLAN mapping to instances in MSTP differently. Furthermore, if you do manage to have all of your vendors converge (I've done so with 5 different implementations) when it comes to CHANGING those mappings after things go live, you'll wish you never bothered. As soon as the configuration hash differs, you'll fallback to the CIST anyway. The only sane way to do STP today, is to run MSTP and leave everything in instance 0 (configure nothing if you can get away with it). Using only the CIST allows you to interact with RSTP very well. Smarter protocols exist for making better use of your bandwidth. (i.e. ECMP, LACP, etc.) As for migrating away from PVST+: break the loops and config the devices over to MSTP one by one. You should make sure that the connected switch -- singular -- isn't going to down the interface at the sight of MSTP BPDUs, and expect a short period of listening & learning, but it should in theory make for only small amounts of frame loss as it converges. I'd start with your root bridge and work your way outward. HTH -- Tom From alex at corp.nac.net Thu Mar 5 15:09:57 2015 From: alex at corp.nac.net (Alex Rubenstein) Date: Thu, 5 Mar 2015 15:09:57 +0000 Subject: optical gear cooling requirements In-Reply-To: <8B84AC2D-6D5A-40BA-8329-C1670C607835@corp.crocker.com> References: <54F77A27.1090500@west.net> <54F77F02.7040803@foobar.org> <8B84AC2D-6D5A-40BA-8329-C1670C607835@corp.crocker.com> Message-ID: <2ed2b557848f401294ff03d021237814@exch2013-1.hq.nac.net> It is interesting where this conversation turned. But for history's sake... NAC started on PM2e with Microcom's, and then USR Sportster. I remember USR sending us PROM chips to change from 28.8 to 33.6. After that, PM3's. We were early PM3 users, working with Megazone on an almost continuous basis to work on bugs. We tried the PM4, that went nowhere. Then we tried Assured Access - it had promise but ultimately was no good. Ultimately, went to used AS5800's with ChDS3 cards, which ran from a long time ago until just a couple months ago when we finally (and literally) pulled the plug on dialup (I think we had about 30 active accounts from a peak of over 35,000). There was a time where NAC was by far the largest customer of the LEC portion of Sprint in NJ, with two DS3's of PRI's out of NWTNJ alone (look that up, it's in the woods in 07860). Sprint had to actually buy software upgrades for the DMS we were out of to accommodate a hunt-group that large (or, so we were told). This was after we had about 700 POTS lines to a house and they begged us to move to the CO. Ahh, the good old days. And it is amazing how well it all worked, in retrospect, and how much fun the business was. Then you see things like "Net Neutrality", and it makes me want to hide in the woods and shed a tear. > >> We used Livingston Portmaster 3 back in the day. Front to back > >> ventilation, ran cool as a cucumber, plug it in and it just worked. > >> Awesome gear until Lucent bought the company to kill the product in > >> favor of their Ascend TNT space heaters. From jgreco at ns.sol.net Thu Mar 5 16:44:19 2015 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 5 Mar 2015 10:44:19 -0600 (CST) Subject: Optic Vendor Coding Question In-Reply-To: <768625.10451.1425438146465.JavaMail.mhammett@ThunderFuck> Message-ID: <201503051644.t25GiKdb015386@aurora.sol.net> > Do Dell 8132s have SFP+ vendor code issues? As in, do they not-work with non-Dell optics? They don't work with Intel SR optics (whatever it is that comes with the X520-SR's). They do seem to work with generic Finisar 1GB optics. Since the Dell branded FTLX8571D3BCL SR's seem to go for only $20-$30 on eBay I haven't been highly motivated to identify other 10GB modules that work/don't-work. The strategy here has been to simply load up 10GB gear with compatible SR optics and then forget about it. I'm guessing that's not helpful because you're probably interested in non-SR optics, but feel free to ping me if you think I might be able to answer further questions. #show interfaces transceiver properties Yes: Dell Qualified No: Not Qualified N/A : Not Applicable Port Type Media Serial Number Dell Qualified --------- ------- --------------------- --------------------- -------------- Te1/0/3 SFP 1000BASE-T PL7xxxx No Te1/0/4 SFP 1000BASE-T PKLxxxx No Te1/0/5 SFP+ 10GBASE-SR AL3xxxx Yes Te1/0/6 SFP+ 10GBASE-SR AK3xxxx Yes Te1/0/7 SFP+ 10GBASE-SR AP9xxxx Yes Te1/0/8 SFP+ 10GBASE-SR AP9xxxx Yes Te1/0/9 SFP+ 10GBASE-SR AP9xxxx Yes Te1/0/10 SFP+ 10GBASE-SR AP9xxxx Yes Te1/0/11 SFP+ 10GBASE-SR AJCxxxx Yes Te1/0/12 SFP+ 10GBASE-SR AL2xxxx Yes Te1/0/13 SFP+ 10GBASE-SR AJQxxxx Yes Te1/0/14 SFP+ 10GBASE-SR AP9xxxx Yes Te1/0/15 SFP+ 10GBASE-SR AHGxxxx Yes Te1/0/16 SFP+ 10GBASE-SR AJQxxxx Yes Te1/0/17 SFP 1000BASE-T PKLxxxx No Te1/0/18 SFP 1000BASE-T PL7xxxx No Te1/0/19 UNKNOWN N/A H11xxxx N/A Te1/0/20 UNKNOWN N/A P11xxxx N/A Te1/0/22 UNKNOWN N/A H51xxxx N/A Te1/0/23 SFP+ 10GBASE-CU1M 228xxxx08 Yes Te1/0/24 SFP+ 10GBASE-CU1M 115xxxx60 Yes Fo1/1/2 QSFP 40GBASE-CR4-1M CN0xxxxV42N6F37 Yes The 19, 20, 22 SFP's are Finisar 1GB, the 1000baseT are Dell branded but apparently not qualified for use in the switch. I think they showed up differently before the firmware upgrade that made the unit think it's a Dell Networking N4032F. Overall we're pleased with the 8132F, but we're not doing anything too awful stressy with them. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From keefe-af at ethoplex.com Thu Mar 5 16:24:46 2015 From: keefe-af at ethoplex.com (Keefe John) Date: Thu, 05 Mar 2015 10:24:46 -0600 Subject: Optic Vendor Coding Question In-Reply-To: <201503051644.t25GiKdb015386@aurora.sol.net> References: <201503051644.t25GiKdb015386@aurora.sol.net> Message-ID: <54F8834E.5090001@ethoplex.com> Check on ebay for a SFP / SFP+ programmer. You can then buy cheap optics from fiberstore.com and code them to any vendor. You could 'clone' one of your current dell optics to the generic ones. Keefe On 3/5/2015 10:44 AM, Joe Greco wrote: >> Do Dell 8132s have SFP+ vendor code issues? > As in, do they not-work with non-Dell optics? > > They don't work with Intel SR optics (whatever it is that comes with > the X520-SR's). They do seem to work with generic Finisar 1GB optics. > Since the Dell branded FTLX8571D3BCL SR's seem to go for only $20-$30 > on eBay I haven't been highly motivated to identify other 10GB modules > that work/don't-work. > > The strategy here has been to simply load up 10GB gear with compatible > SR optics and then forget about it. I'm guessing that's not helpful > because you're probably interested in non-SR optics, but feel free to > ping me if you think I might be able to answer further questions. > > #show interfaces transceiver properties > > Yes: Dell Qualified No: Not Qualified > N/A : Not Applicable > Port Type Media Serial Number Dell Qualified > --------- ------- --------------------- --------------------- -------------- > Te1/0/3 SFP 1000BASE-T PL7xxxx No > Te1/0/4 SFP 1000BASE-T PKLxxxx No > Te1/0/5 SFP+ 10GBASE-SR AL3xxxx Yes > Te1/0/6 SFP+ 10GBASE-SR AK3xxxx Yes > Te1/0/7 SFP+ 10GBASE-SR AP9xxxx Yes > Te1/0/8 SFP+ 10GBASE-SR AP9xxxx Yes > Te1/0/9 SFP+ 10GBASE-SR AP9xxxx Yes > Te1/0/10 SFP+ 10GBASE-SR AP9xxxx Yes > Te1/0/11 SFP+ 10GBASE-SR AJCxxxx Yes > Te1/0/12 SFP+ 10GBASE-SR AL2xxxx Yes > Te1/0/13 SFP+ 10GBASE-SR AJQxxxx Yes > Te1/0/14 SFP+ 10GBASE-SR AP9xxxx Yes > Te1/0/15 SFP+ 10GBASE-SR AHGxxxx Yes > Te1/0/16 SFP+ 10GBASE-SR AJQxxxx Yes > Te1/0/17 SFP 1000BASE-T PKLxxxx No > Te1/0/18 SFP 1000BASE-T PL7xxxx No > Te1/0/19 UNKNOWN N/A H11xxxx N/A > Te1/0/20 UNKNOWN N/A P11xxxx N/A > Te1/0/22 UNKNOWN N/A H51xxxx N/A > Te1/0/23 SFP+ 10GBASE-CU1M 228xxxx08 Yes > Te1/0/24 SFP+ 10GBASE-CU1M 115xxxx60 Yes > Fo1/1/2 QSFP 40GBASE-CR4-1M CN0xxxxV42N6F37 Yes > > > The 19, 20, 22 SFP's are Finisar 1GB, the 1000baseT are Dell branded > but apparently not qualified for use in the switch. I think they > showed up differently before the firmware upgrade that made the unit > think it's a Dell Networking N4032F. > > Overall we're pleased with the 8132F, but we're not doing anything too > awful stressy with them. > > ... JG From nanog at ics-il.net Thu Mar 5 16:28:24 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 5 Mar 2015 10:28:24 -0600 (CST) Subject: Optic Vendor Coding Question In-Reply-To: <201503051644.t25GiKdb015386@aurora.sol.net> Message-ID: <13450634.5766.1425572894054.JavaMail.mhammett@ThunderFuck> Thanks for this and several off-list responses. The consensus was that I was safe. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Joe Greco" To: "Mike Hammett" Cc: "NANOG list" Sent: Thursday, March 5, 2015 10:44:19 AM Subject: Re: Optic Vendor Coding Question > Do Dell 8132s have SFP+ vendor code issues? As in, do they not-work with non-Dell optics? They don't work with Intel SR optics (whatever it is that comes with the X520-SR's). They do seem to work with generic Finisar 1GB optics. Since the Dell branded FTLX8571D3BCL SR's seem to go for only $20-$30 on eBay I haven't been highly motivated to identify other 10GB modules that work/don't-work. The strategy here has been to simply load up 10GB gear with compatible SR optics and then forget about it. I'm guessing that's not helpful because you're probably interested in non-SR optics, but feel free to ping me if you think I might be able to answer further questions. #show interfaces transceiver properties Yes: Dell Qualified No: Not Qualified N/A : Not Applicable Port Type Media Serial Number Dell Qualified --------- ------- --------------------- --------------------- -------------- Te1/0/3 SFP 1000BASE-T PL7xxxx No Te1/0/4 SFP 1000BASE-T PKLxxxx No Te1/0/5 SFP+ 10GBASE-SR AL3xxxx Yes Te1/0/6 SFP+ 10GBASE-SR AK3xxxx Yes Te1/0/7 SFP+ 10GBASE-SR AP9xxxx Yes Te1/0/8 SFP+ 10GBASE-SR AP9xxxx Yes Te1/0/9 SFP+ 10GBASE-SR AP9xxxx Yes Te1/0/10 SFP+ 10GBASE-SR AP9xxxx Yes Te1/0/11 SFP+ 10GBASE-SR AJCxxxx Yes Te1/0/12 SFP+ 10GBASE-SR AL2xxxx Yes Te1/0/13 SFP+ 10GBASE-SR AJQxxxx Yes Te1/0/14 SFP+ 10GBASE-SR AP9xxxx Yes Te1/0/15 SFP+ 10GBASE-SR AHGxxxx Yes Te1/0/16 SFP+ 10GBASE-SR AJQxxxx Yes Te1/0/17 SFP 1000BASE-T PKLxxxx No Te1/0/18 SFP 1000BASE-T PL7xxxx No Te1/0/19 UNKNOWN N/A H11xxxx N/A Te1/0/20 UNKNOWN N/A P11xxxx N/A Te1/0/22 UNKNOWN N/A H51xxxx N/A Te1/0/23 SFP+ 10GBASE-CU1M 228xxxx08 Yes Te1/0/24 SFP+ 10GBASE-CU1M 115xxxx60 Yes Fo1/1/2 QSFP 40GBASE-CR4-1M CN0xxxxV42N6F37 Yes The 19, 20, 22 SFP's are Finisar 1GB, the 1000baseT are Dell branded but apparently not qualified for use in the switch. I think they showed up differently before the firmware upgrade that made the unit think it's a Dell Networking N4032F. Overall we're pleased with the 8132F, but we're not doing anything too awful stressy with them. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From nanog at ics-il.net Thu Mar 5 16:36:41 2015 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 5 Mar 2015 10:36:41 -0600 (CST) Subject: Optic Vendor Coding Question In-Reply-To: <54F8834E.5090001@ethoplex.com> Message-ID: <16600953.5798.1425573388892.JavaMail.mhammett@ThunderFuck> *nods* I may end up doing that. I was ordering new ones from China (6COM and Gigalight) and they asked me if I needed any particular vendor coding. Thus far people that have used all of the various pieces involved (Mikrotik, Dell, generic Intel) said they should be fine with non-coded optics. BTW Keefe: Do any of you "north side" guys have a link into Cermak? Offlist is fine. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Keefe John" To: "NANOG list" Sent: Thursday, March 5, 2015 10:24:46 AM Subject: Re: Optic Vendor Coding Question Check on ebay for a SFP / SFP+ programmer. You can then buy cheap optics from fiberstore.com and code them to any vendor. You could 'clone' one of your current dell optics to the generic ones. Keefe On 3/5/2015 10:44 AM, Joe Greco wrote: >> Do Dell 8132s have SFP+ vendor code issues? > As in, do they not-work with non-Dell optics? > > They don't work with Intel SR optics (whatever it is that comes with > the X520-SR's). They do seem to work with generic Finisar 1GB optics. > Since the Dell branded FTLX8571D3BCL SR's seem to go for only $20-$30 > on eBay I haven't been highly motivated to identify other 10GB modules > that work/don't-work. > > The strategy here has been to simply load up 10GB gear with compatible > SR optics and then forget about it. I'm guessing that's not helpful > because you're probably interested in non-SR optics, but feel free to > ping me if you think I might be able to answer further questions. > > #show interfaces transceiver properties > > Yes: Dell Qualified No: Not Qualified > N/A : Not Applicable > Port Type Media Serial Number Dell Qualified > --------- ------- --------------------- --------------------- -------------- > Te1/0/3 SFP 1000BASE-T PL7xxxx No > Te1/0/4 SFP 1000BASE-T PKLxxxx No > Te1/0/5 SFP+ 10GBASE-SR AL3xxxx Yes > Te1/0/6 SFP+ 10GBASE-SR AK3xxxx Yes > Te1/0/7 SFP+ 10GBASE-SR AP9xxxx Yes > Te1/0/8 SFP+ 10GBASE-SR AP9xxxx Yes > Te1/0/9 SFP+ 10GBASE-SR AP9xxxx Yes > Te1/0/10 SFP+ 10GBASE-SR AP9xxxx Yes > Te1/0/11 SFP+ 10GBASE-SR AJCxxxx Yes > Te1/0/12 SFP+ 10GBASE-SR AL2xxxx Yes > Te1/0/13 SFP+ 10GBASE-SR AJQxxxx Yes > Te1/0/14 SFP+ 10GBASE-SR AP9xxxx Yes > Te1/0/15 SFP+ 10GBASE-SR AHGxxxx Yes > Te1/0/16 SFP+ 10GBASE-SR AJQxxxx Yes > Te1/0/17 SFP 1000BASE-T PKLxxxx No > Te1/0/18 SFP 1000BASE-T PL7xxxx No > Te1/0/19 UNKNOWN N/A H11xxxx N/A > Te1/0/20 UNKNOWN N/A P11xxxx N/A > Te1/0/22 UNKNOWN N/A H51xxxx N/A > Te1/0/23 SFP+ 10GBASE-CU1M 228xxxx08 Yes > Te1/0/24 SFP+ 10GBASE-CU1M 115xxxx60 Yes > Fo1/1/2 QSFP 40GBASE-CR4-1M CN0xxxxV42N6F37 Yes > > > The 19, 20, 22 SFP's are Finisar 1GB, the 1000baseT are Dell branded > but apparently not qualified for use in the switch. I think they > showed up differently before the firmware upgrade that made the unit > think it's a Dell Networking N4032F. > > Overall we're pleased with the 8132F, but we're not doing anything too > awful stressy with them. > > ... JG From Vinny_Abello at Dell.com Thu Mar 5 22:57:12 2015 From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com) Date: Thu, 5 Mar 2015 22:57:12 +0000 Subject: optical gear cooling requirements In-Reply-To: <2ed2b557848f401294ff03d021237814@exch2013-1.hq.nac.net> References: <54F77A27.1090500@west.net> <54F77F02.7040803@foobar.org> <8B84AC2D-6D5A-40BA-8329-C1670C607835@corp.crocker.com> <2ed2b557848f401294ff03d021237814@exch2013-1.hq.nac.net> Message-ID: Dell - Internal Use - Confidential Still alive and well out here in 07860. :) My memory is somewhat rusty as it's been a while, but at Tellurian I'm pretty positive we ran a DS3+ worth of lines from Sprint from 07860 so I'm not sure if "by far" is totally accurate. ;) We terminated on a PM4 here, mostly with bleeding edge fixed code that I don't think was even officially released by Lucent. It helps if you know the developers. We had access to the source code as well at one time for the Portmaster line. I remember an emergency one time where we basically provisioned an on demand T1 to connect POPs together through the Portmasters via ISDN. They were cool machines. I also used to run a Portmaster ORU at my house which was also rock solid. Great for gaming back then... I know once we ported numbers away from Sprint to Focal/Broadwing/Level 3, at our peak we had two DS3's of PRI's on an AS5800 as well. Those boxes bothered me as the modems frequently rotted over time and required regular maintenance to refresh them and make them happy again... otherwise your call completion rates started dipping. I'm surprised you had so few dialup accounts. When we shutdown all of our dialup (we sent most of them to NAC), we had far more than 30 active accounts based on all RADIUS logs. I don't know how in this day and age, but they were there and dialing in still up to the day I pulled the power on the AS5800, despite customers being warned. Ah, memories... now I'm thinking back when I ran a BBS on Fidonet... FOSSIL drivers, Frontdoor, echomail. :) Now those were the days! -Vinny -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Alex Rubenstein Sent: Thursday, March 5, 2015 10:10 AM To: Matthew Crocker; Nick Hilliard Cc: nanog at nanog.org Subject: RE: optical gear cooling requirements It is interesting where this conversation turned. But for history's sake... NAC started on PM2e with Microcom's, and then USR Sportster. I remember USR sending us PROM chips to change from 28.8 to 33.6. After that, PM3's. We were early PM3 users, working with Megazone on an almost continuous basis to work on bugs. We tried the PM4, that went nowhere. Then we tried Assured Access - it had promise but ultimately was no good. Ultimately, went to used AS5800's with ChDS3 cards, which ran from a long time ago until just a couple months ago when we finally (and literally) pulled the plug on dialup (I think we had about 30 active accounts from a peak of over 35,000). There was a time where NAC was by far the largest customer of the LEC portion of Sprint in NJ, with two DS3's of PRI's out of NWTNJ alone (look that up, it's in the woods in 07860). Sprint had to actually buy software upgrades for the DMS we were out of to accommodate a hunt-group that large (or, so we were told). This was after we had about 700 POTS lines to a house and they begged us to move to the CO. Ahh, the good old days. And it is amazing how well it all worked, in retrospect, and how much fun the business was. Then you see things like "Net Neutrality", and it makes me want to hide in the woods and shed a tear. > >> We used Livingston Portmaster 3 back in the day. Front to back > >> ventilation, ran cool as a cucumber, plug it in and it just worked. > >> Awesome gear until Lucent bought the company to kill the product in > >> favor of their Ascend TNT space heaters. From Vinny_Abello at Dell.com Thu Mar 5 23:00:58 2015 From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com) Date: Thu, 5 Mar 2015 23:00:58 +0000 Subject: optical gear cooling requirements In-Reply-To: <54F77F02.7040803@foobar.org> References: <54F77A27.1090500@west.net> <54F77F02.7040803@foobar.org> Message-ID: Dell - Internal Use - Confidential Was forced to get an Ascend Superpipe to work with a PM4 for one of our customers ages ago. Two ISDN lines... as soon as the 4th channel was thrown into multilink, it would drop the 3rd channel. >:O Finally got it working after a lot of trial and error with stupid settings on the Ascend garbage. It was clearly a bug but I forge the specific setting that caused that to happen. -Vinny -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nick Hilliard Sent: Wednesday, March 4, 2015 4:54 PM To: nanog at nanog.org Subject: Re: optical gear cooling requirements On 04/03/2015 21:33, Jay Hennigan wrote: > We used Livingston Portmaster 3 back in the day. Front to back > ventilation, ran cool as a cucumber, plug it in and it just worked. > Awesome gear until Lucent bought the company to kill the product in > favor of their Ascend TNT space heaters. Ascend kit was a horror to deal with. I ran isdn dialin on some of their lower end kit at one stage. It only worked because I put it on a power timer which power-cycled it twice a day. +1 on portmasters, though. Nick From Bryan at bryanfields.net Fri Mar 6 15:41:23 2015 From: Bryan at bryanfields.net (Bryan Fields) Date: Fri, 06 Mar 2015 10:41:23 -0500 Subject: mpls over microwave In-Reply-To: References: Message-ID: <54F9CAA3.10801@bryanfields.net> On 2/6/15 11:32 AM, Donn Lasher wrote: > Properly engineered, however, is the key. Make sure whom-ever is building > your links looks at vendor specs, builds a real link budget (including > losses from connectors, cable, grounding, etc) properly weather seals > everything, and try to get at least a a 20db fade margin if you can. If > the things I just mentioned are confusing to your RF guy, you might want > to get outside help. Make sure they can know the models for propagation as well. At lower bands fading caused by K factor change can be a bitch and is the predominant mode of fading. on the higher bands (>11GHz) rain fade is the predominant mode of fading. If you want your network to have 99.999% uptime, the links need to be engineered for 99.9999% uptime. Make sure the consultant knows Pathloss5 and is not using a vendor's program for that (orthogon/motorola/cambium/whatever they call them now) loves to push their own shitty program. If you're using a dynamic data rate radio (most are), ensure you engineer for highest data rate you need. If you run the calcs and it shows 99.9999999% at bfsk but you need 128qam to get your full data rate, what good is it? congestion do to link down modulation is still an outage. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From cscora at apnic.net Fri Mar 6 18:12:01 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 7 Mar 2015 04:12:01 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201503061812.t26IC1Wh001184@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, 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 07 Mar, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 535301 Prefixes after maximum aggregation (per Origin AS): 204571 Deaggregation factor: 2.62 Unique aggregates announced (without unneeded subnets): 260830 Total ASes present in the Internet Routing Table: 49580 Prefixes per ASN: 10.80 Origin-only ASes present in the Internet Routing Table: 36492 Origin ASes announcing only one prefix: 16264 Transit ASes present in the Internet Routing Table: 6275 Transit-only ASes present in the Internet Routing Table: 169 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 44 Max AS path prepend of ASN ( 55944) 41 Prefixes from unregistered ASNs in the Routing Table: 1423 Unregistered ASNs in the Routing Table: 428 Number of 32-bit ASNs allocated by the RIRs: 8771 Number of 32-bit ASNs visible in the Routing Table: 6813 Prefixes from 32-bit ASNs in the Routing Table: 24890 Number of bogon 32-bit ASNs visible in the Routing Table: 2 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 382 Number of addresses announced to Internet: 2733757604 Equivalent to 162 /8s, 241 /16s and 212 /24s Percentage of available address space announced: 73.8 Percentage of allocated address space announced: 73.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.2 Total number of prefixes smaller than registry allocations: 181128 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 131849 Total APNIC prefixes after maximum aggregation: 38372 APNIC Deaggregation factor: 3.44 Prefixes being announced from the APNIC address blocks: 137413 Unique aggregates announced from the APNIC address blocks: 55868 APNIC Region origin ASes present in the Internet Routing Table: 5015 APNIC Prefixes per ASN: 27.40 APNIC Region origin ASes announcing only one prefix: 1205 APNIC Region transit ASes present in the Internet Routing Table: 871 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 44 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1331 Number of APNIC addresses announced to Internet: 746142208 Equivalent to 44 /8s, 121 /16s and 58 /24s Percentage of available APNIC address space announced: 87.2 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-64098, 131072-135580 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: 176640 Total ARIN prefixes after maximum aggregation: 87315 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 178608 Unique aggregates announced from the ARIN address blocks: 83891 ARIN Region origin ASes present in the Internet Routing Table: 16506 ARIN Prefixes per ASN: 10.82 ARIN Region origin ASes announcing only one prefix: 6077 ARIN Region transit ASes present in the Internet Routing Table: 1705 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 21 Number of ARIN region 32-bit ASNs visible in the Routing Table: 366 Number of ARIN addresses announced to Internet: 1061694240 Equivalent to 63 /8s, 72 /16s and 43 /24s Percentage of available ARIN address space announced: 56.2 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: 130293 Total RIPE prefixes after maximum aggregation: 64794 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 136645 Unique aggregates announced from the RIPE address blocks: 83857 RIPE Region origin ASes present in the Internet Routing Table: 17899 RIPE Prefixes per ASN: 7.63 RIPE Region origin ASes announcing only one prefix: 8151 RIPE Region transit ASes present in the Internet Routing Table: 2968 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3483 Number of RIPE addresses announced to Internet: 693822852 Equivalent to 41 /8s, 90 /16s and 229 /24s Percentage of available RIPE address space announced: 100.9 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: 58879 Total LACNIC prefixes after maximum aggregation: 11040 LACNIC Deaggregation factor: 5.33 Prefixes being announced from the LACNIC address blocks: 68633 Unique aggregates announced from the LACNIC address blocks: 31804 LACNIC Region origin ASes present in the Internet Routing Table: 2411 LACNIC Prefixes per ASN: 28.47 LACNIC Region origin ASes announcing only one prefix: 627 LACNIC Region transit ASes present in the Internet Routing Table: 490 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1543 Number of LACNIC addresses announced to Internet: 167955456 Equivalent to 10 /8s, 2 /16s and 204 /24s Percentage of available LACNIC address space announced: 100.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + 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: 12558 Total AfriNIC prefixes after maximum aggregation: 3006 AfriNIC Deaggregation factor: 4.18 Prefixes being announced from the AfriNIC address blocks: 13620 Unique aggregates announced from the AfriNIC address blocks: 5068 AfriNIC Region origin ASes present in the Internet Routing Table: 737 AfriNIC Prefixes per ASN: 18.48 AfriNIC Region origin ASes announcing only one prefix: 204 AfriNIC Region transit ASes present in the Internet Routing Table: 154 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 90 Number of AfriNIC addresses announced to Internet: 63654656 Equivalent to 3 /8s, 203 /16s and 75 /24s Percentage of available AfriNIC address space announced: 63.2 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 2874 11553 909 Korea Telecom 17974 2813 904 78 PT Telekomunikasi Indonesia 7545 2575 336 128 TPG Telecom Limited 4755 1988 422 211 TATA Communications formerly 4538 1760 4190 71 China Education and Research 9829 1675 1324 34 National Internet Backbone 9808 1546 8717 28 Guangdong Mobile Communicatio 4808 1459 2251 439 CNCGROUP IP network China169 9583 1397 132 555 Sify Limited 9498 1303 334 95 BHARTI Airtel Ltd. 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 2985 2955 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 3356 2551 10683 480 Level 3 Communications, Inc. 18566 2041 379 183 MegaPath Corporation 20115 1849 1831 434 Charter Communications 6983 1705 866 245 EarthLink, Inc. 4323 1628 1036 409 tw telecom holdings, inc. 30036 1522 312 507 Mediacom Communications Corp 701 1389 11268 677 MCI Communications Services, 22561 1327 412 241 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 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 1971 303 359 TELLCOM ILETISIM HIZMETLERI A 20940 1625 632 1207 Akamai International B.V. 8402 1397 544 15 OJSC "Vimpelcom" 6849 1214 356 24 JSC "Ukrtelecom" 31148 1046 45 21 Freenet Ltd. 13188 1015 96 70 TOV "Bank-Inform" 8551 904 373 48 Bezeq International-Ltd 12479 873 796 82 France Telecom Espana SA 9198 845 349 25 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 10620 3123 507 216 Telmex Colombia S.A. 28573 2321 2156 116 NET Servi�os de Comunica��o S 7303 1793 1190 233 Telecom Argentina S.A. 6147 1579 374 30 Telefonica del Peru S.A.A. 8151 1544 3124 446 Uninet S.A. de C.V. 6503 1200 421 58 Axtel, S.A.B. de C.V. 7738 1001 1882 42 Telemar Norte Leste S.A. 3816 922 400 150 COLOMBIA TELECOMUNICACIONES S 26615 921 2325 35 Tim Celular S.A. 18881 863 1036 22 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1500 958 13 TE-AS 24863 928 282 31 Link Egypt (Link.NET) 36903 479 241 90 Office National des Postes et 36992 402 1101 31 ETISALAT MISR 37492 319 155 71 Orange Tunisie 24835 299 144 9 Vodafone Data 3741 250 921 209 Internet Solutions 29571 234 21 12 Cote d'Ivoire Telecom 36947 196 712 14 Telecom Algeria 15706 172 32 6 Sudatel (Sudan Telecom Co. Lt 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 10620 3123 507 216 Telmex Colombia S.A. 22773 2985 2955 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 4766 2874 11553 909 Korea Telecom 17974 2813 904 78 PT Telekomunikasi Indonesia 7545 2575 336 128 TPG Telecom Limited 3356 2551 10683 480 Level 3 Communications, Inc. 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2321 2156 116 NET Servi�os de Comunica��o S 18566 2041 379 183 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 22773 2985 2844 Cox Communications Inc. 6389 2891 2840 BellSouth.net Inc. 17974 2813 2735 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 7545 2575 2447 TPG Telecom Limited 28573 2321 2205 NET Servi�os de Comunica��o S 3356 2551 2071 Level 3 Communications, Inc. 4766 2874 1965 Korea Telecom 18566 2041 1858 MegaPath Corporation 4755 1988 1777 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 36806 UNALLOCATED 4.21.41.0/24 3356 Level 3 Communicatio 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 47092 UNALLOCATED 8.8.204.0/24 16410 The Reynolds and Rey 53506 UNALLOCATED 8.17.102.0/23 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 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 27205 UNALLOCATED 8.38.16.0/21 6461 Abovenet Communicati 598 UNALLOCATED 8.39.237.0/24 3356 Level 3 Communicatio Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 Bitfinite LLC 23.252.224.0/20 62502 >>UNKNOWN<< 23.252.224.0/21 62502 >>UNKNOWN<< 23.252.232.0/21 62502 >>UNKNOWN<< 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.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:12 /10:34 /11:92 /12:264 /13:505 /14:998 /15:1723 /16:12969 /17:7161 /18:12156 /19:25113 /20:35743 /21:38522 /22:57910 /23:50691 /24:288484 /25:1079 /26:1108 /27:670 /28:17 /29:13 /30:8 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2201 2985 Cox Communications Inc. 18566 1996 2041 MegaPath Corporation 6389 1671 2891 BellSouth.net Inc. 30036 1368 1522 Mediacom Communications Corp 6983 1352 1705 EarthLink, Inc. 34984 1278 1971 TELLCOM ILETISIM HIZMETLERI A 11492 1128 1191 CABLE ONE, INC. 6147 1123 1579 Telefonica del Peru S.A.A. 10620 1108 3123 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:1513 2:674 3:1 4:98 5:1724 6:21 8:1424 12:1840 13:4 14:1306 15:17 16:2 17:42 18:21 20:49 23:1184 24:1672 27:1849 31:1487 32:39 33:2 34:5 35:3 36:118 37:1851 38:1009 39:10 40:237 41:2973 42:258 43:1127 44:25 45:252 46:2187 47:36 49:838 50:789 52:12 54:69 55:8 56:8 57:36 58:1201 59:683 60:465 61:1774 62:1313 63:1912 64:4453 65:2266 66:4116 67:2030 68:1030 69:3248 70:945 71:435 72:1959 74:2610 75:318 76:405 77:1493 78:1295 79:792 80:1319 81:1332 82:817 83:672 84:682 85:1350 86:391 87:1082 88:516 89:1766 90:150 91:5930 92:794 93:2178 94:2032 95:2123 96:429 97:340 98:1056 99:45 100:73 101:797 102:1 103:6871 104:1402 105:61 106:220 107:893 108:610 109:2007 110:1078 111:1474 112:744 113:1044 114:832 115:1245 116:1348 117:1008 118:1682 119:1436 120:442 121:1035 122:2182 123:1726 124:1498 125:1576 128:648 129:356 130:381 131:1134 132:486 133:167 134:412 135:89 136:335 137:299 138:522 139:174 140:231 141:420 142:632 143:477 144:530 145:109 146:690 147:578 148:1103 149:458 150:563 151:607 152:496 153:239 154:387 155:728 156:403 157:331 158:263 159:974 160:370 161:636 162:1922 163:385 164:659 165:677 166:323 167:705 168:1023 169:153 170:1457 171:230 172:42 173:1574 174:698 175:630 176:1432 177:3749 178:2054 179:853 180:1920 181:1629 182:1724 183:610 184:775 185:3057 186:2685 187:1864 188:2018 189:1584 190:7680 191:943 192:8153 193:5576 194:4079 195:3647 196:1664 197:1018 198:5496 199:5534 200:6552 201:3009 202:9501 203:9075 204:4649 205:2740 206:2987 207:2991 208:3951 209:3903 210:3510 211:1850 212:2481 213:2264 214:844 215:69 216:5527 217:1793 218:673 219:469 220:1436 221:788 222:466 223:654 End of report From cidr-report at potaroo.net Fri Mar 6 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Mar 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201503062200.t26M0035099179@wattle.apnic.net> This report has been generated at Fri Mar 6 21:14:23 2015 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 27-02-15 541645 299462 28-02-15 541750 299479 01-03-15 541663 298709 02-03-15 541931 298992 03-03-15 542657 299186 04-03-15 542732 299178 05-03-15 542812 299372 06-03-15 543091 299463 AS Summary 49806 Number of ASes in routing system 19861 Number of ASes announcing only one prefix 3123 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120417792 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'). --- 06Mar15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 542987 299404 243583 44.9% All ASes AS22773 2987 171 2816 94.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2891 120 2771 95.8% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2813 78 2735 97.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2473 12 2461 99.5% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2323 312 2011 86.6% NET Servi�os de Comunica��o S.A.,BR AS3356 2554 697 1857 72.7% LEVEL3 - Level 3 Communications, Inc.,US AS4766 2875 1319 1556 54.1% KIXS-AS-KR Korea Telecom,KR AS7303 1793 283 1510 84.2% Telecom Argentina S.A.,AR AS9808 1546 67 1479 95.7% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS6983 1702 248 1454 85.4% ITCDELTA - Earthlink, Inc.,US AS6147 1579 161 1418 89.8% Telefonica del Peru S.A.A.,PE AS4755 1986 594 1392 70.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS10620 3123 1741 1382 44.3% Telmex Colombia S.A.,CO AS8402 1379 25 1354 98.2% CORBINA-AS OJSC "Vimpelcom",RU AS20115 1850 506 1344 72.6% CHARTER-NET-HKY-NC - Charter Communications,US AS7545 2591 1275 1316 50.8% TPG-INTERNET-AP TPG Telecom Limited,AU AS7552 1473 234 1239 84.1% VIETEL-AS-AP Viettel Corporation,VN AS4323 1635 410 1225 74.9% TWTC - tw telecom holdings, inc.,US AS8452 1787 584 1203 67.3% TE-AS TE-AS,EG AS9498 1303 111 1192 91.5% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2040 869 1171 57.4% MEGAPATH5-US - MegaPath Corporation,US AS34984 1971 901 1070 54.3% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS22561 1329 355 974 73.3% AS22561 - CenturyTel Internet Holdings, Inc.,US AS6849 1211 240 971 80.2% UKRTELNET JSC UKRTELECOM,UA AS7738 1000 84 916 91.6% Telemar Norte Leste S.A.,BR AS38285 983 115 868 88.3% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4538 1778 957 821 46.2% ERX-CERNET-BKB China Education and Research Network Center,CN AS4780 1109 297 812 73.2% SEEDNET Digital United Inc.,TW AS26615 922 137 785 85.1% Tim Celular S.A.,BR AS24560 1197 421 776 64.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN Total 56203 13324 42879 76.3% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.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.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.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 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 64.25.16.0/23 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.20.0/24 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.21.0/24 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.22.0/24 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.24.0/23 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 AS19535 - JetBlue Airways Corporation,US 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 64.140.128.0/18 AS7385 INTEGRATELECOM - Integra Telecom, 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.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 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 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 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.114.184.0/22 AS19888 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.120.212.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.120.214.0/23 AS32326 MORPHOTRUST-USA - MorphoTrust USA, Inc.,US 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 74.123.136.0/21 AS53358 -Reserved AS-,ZZ 77.243.91.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 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 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.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 100.42.176.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc.,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 102.11.1.0/24 AS20135 FILMATA "FILMATA" LTD,BG 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.20.100.0/24 AS23937 103.20.101.0/24 AS23937 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.21.4.0/22 AS12182 INTERNAP-2BLK - Internap Network Services Corporation,US 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.28.232.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.224.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.244.140.0/24 AS49487 ZTELAS Zamir Telecom Limited,GB 103.244.141.0/24 AS49487 ZTELAS Zamir Telecom Limited,GB 103.247.19.0/24 AS18107 ASN-IPSYSTEMS-AP IP SYSTEMS,AU 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 103.253.100.0/22 AS10015 CWJ-NET Cyber Wave Japan Co., Ltd.,JP 103.253.164.0/23 AS13317 103.255.56.0/22 AS18097 DCN D.C.N. Corporation,JP 103.255.132.0/22 AS18097 DCN D.C.N. Corporation,JP 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 113.197.106.0/24 AS15169 GOOGLE - Google Inc.,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.54.184.0/21 AS59092 KRONOS kronos.Co.,Ltd.,JP 121.200.216.0/21 AS59092 KRONOS kronos.Co.,Ltd.,JP 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 142.147.128.0/17 AS62874 WEB2OBJECTS-LLC - Web2Objects LLC,US 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.44.0.0/19 AS11029 BORDER-TECHNOLOGY - Border Technology, LLC,US 173.224.128.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc.,US 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 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,FR 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.155.48.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,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 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.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.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age 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.176.147.0/24 AS49951 -Reserved AS-,ZZ 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 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.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS 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.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.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,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.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.3.136.0/22 AS9009 M247 M247 Ltd,BE 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.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 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 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 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.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 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.30.136.0/23 AS46636 NATCOWEB - NatCoWeb Corp.,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.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 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.204.144.0/21 AS36007 -Reserved AS-,ZZ 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 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 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 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.122.134.0/24 AS38615 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.175.8.0/23 AS23858 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 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.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.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 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.189.0.0/19 AS46879 -Reserved AS-,ZZ 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.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.233.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.93.216.0/22 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 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.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.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,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.158.224.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC,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.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 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 Mar 6 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Mar 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201503062200.t26M01uf099193@wattle.apnic.net> BGP Update Report Interval: 26-Feb-15 -to- 05-Mar-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 322503 5.3% 195.7 -- BSNL-NIB National Internet Backbone,IN 2 - AS23752 224931 3.7% 1799.4 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - AS61894 174402 2.9% 58134.0 -- FreeBSD Brasil LTDA,BR 4 - AS17908 151325 2.5% 200.7 -- TCISL Tata Communications,IN 5 - AS2734 121454 2.0% 6747.4 -- CORESITE - CoreSite,US 6 - AS46230 117507 1.9% 5595.6 -- DUDROP - Dignitas Technology Inc,US 7 - AS42081 103402 1.7% 1378.7 -- SPEEDY-NET-AS Speedy net EAD,BG 8 - AS7782 96817 1.6% 19363.4 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 9 - AS36947 96535 1.6% 784.8 -- ALGTEL-AS,DZ 10 - AS393276 95841 1.6% 19168.2 -- CEA - Chugach Electric Association, Inc.,US 11 - AS3816 92041 1.5% 242.2 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 12 - AS45528 85228 1.4% 105.3 -- TDN Tikona Digital Networks Pvt Ltd.,IN 13 - AS8452 74263 1.2% 47.4 -- TE-AS TE-AS,EG 14 - AS38511 71365 1.2% 126.1 -- TACHYON-AS-ID PT Remala Abadi,ID 15 - AS17488 61125 1.0% 58.7 -- HATHWAY-NET-AP Hathway IP Over Cable Internet,IN 16 - AS24186 59591 1.0% 601.9 -- RAILTEL-AS-IN RailTel Corporation of India Ltd., Internet Service Provider, New Delhi,IN 17 - AS18207 54254 0.9% 100.1 -- YOU-INDIA-AP YOU Broadband & Cable India Ltd.,IN 18 - AS10201 54072 0.9% 163.9 -- DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 19 - AS55831 53493 0.9% 214.8 -- AIRCEL-IN Aircel Ltd.,IN 20 - AS53563 45149 0.7% 15049.7 -- XPLUSONE - X Plus One Solutions, Inc.,US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS61894 174402 2.9% 58134.0 -- FreeBSD Brasil LTDA,BR 2 - AS7782 96817 1.6% 19363.4 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 3 - AS54970 19339 0.3% 19339.0 -- NORTHERN-AIR-CARGO - NORTHERN AIR CARGO,US 4 - AS393276 95841 1.6% 19168.2 -- CEA - Chugach Electric Association, Inc.,US 5 - AS197914 17993 0.3% 17993.0 -- STOCKHO-AS Stockho Hosting SARL,FR 6 - AS61039 16303 0.3% 16303.0 -- ZMZ OAO ZMZ,RU 7 - AS53563 45149 0.7% 15049.7 -- XPLUSONE - X Plus One Solutions, Inc.,US 8 - AS49227 33436 0.6% 11145.3 -- TCI-ANYCAST-NET UKRAINIAN INTERNET NAMES CENTER.LTD,UA 9 - AS131754 10505 0.2% 10505.0 -- IDNIC-UNMUL-AS-ID Universitas Mulawarman,ID 10 - AS33356 9218 0.1% 9218.0 -- CTWS - Eagle-Tech Systems,US 11 - AS54465 9084 0.1% 9084.0 -- QPM-AS-1 - QuickPlay Media Inc.,US 12 - AS46336 7692 0.1% 7692.0 -- GOODVILLE - Goodville Mutual Casualty Company,US 13 - AS2734 121454 2.0% 6747.4 -- CORESITE - CoreSite,US 14 - AS46230 117507 1.9% 5595.6 -- DUDROP - Dignitas Technology Inc,US 15 - AS33529 36148 0.6% 5164.0 -- PEAK-WEB-HOSTING - Peak Web Hosting Inc.,US 16 - AS20151 4700 0.1% 4700.0 -- MCW-12-01 - Mountain Computer Wizards, Inc.,US 17 - AS33721 4182 0.1% 4182.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 18 - AS25563 10674 0.2% 3558.0 -- WEBLAND-AS Webland AG, Autonomous System,CH 19 - AS198053 2938 0.1% 2938.0 -- AMTEL VECTRA S.A.,PL 20 - AS47680 13860 0.2% 2772.0 -- NHCS EOBO Limited,IE TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 177.10.158.0/24 174318 2.8% AS61894 -- FreeBSD Brasil LTDA,BR 2 - 202.70.88.0/21 112393 1.8% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 202.70.64.0/21 111848 1.8% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 105.96.0.0/22 84597 1.4% AS36947 -- ALGTEL-AS,DZ 5 - 199.38.164.0/23 45133 0.7% AS53563 -- XPLUSONE - X Plus One Solutions, Inc.,US 6 - 69.194.4.0/24 36107 0.6% AS33529 -- PEAK-WEB-HOSTING - Peak Web Hosting Inc.,US 7 - 195.123.1.0/24 33420 0.5% AS49227 -- TCI-ANYCAST-NET UKRAINIAN INTERNET NAMES CENTER.LTD,UA 8 - 66.128.148.0/24 23816 0.4% AS2734 -- CORESITE - CoreSite,US 9 - 66.128.148.0/22 23760 0.4% AS2734 -- CORESITE - CoreSite,US 10 - 67.212.149.0/24 23722 0.4% AS2734 -- CORESITE - CoreSite,US 11 - 66.128.149.0/24 23714 0.4% AS2734 -- CORESITE - CoreSite,US 12 - 66.128.156.0/22 23678 0.4% AS2734 -- CORESITE - CoreSite,US 13 - 64.29.130.0/24 22237 0.3% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 14 - 192.206.58.0/24 19443 0.3% AS7782 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 15 - 198.163.32.0/21 19439 0.3% AS7782 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 16 - 162.211.56.0/21 19351 0.3% AS7782 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 17 - 198.17.216.0/24 19339 0.3% AS54970 -- NORTHERN-AIR-CARGO - NORTHERN AIR CARGO,US 18 - 107.152.112.0/20 19309 0.3% AS7782 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 19 - 104.254.224.0/21 19275 0.3% AS7782 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 20 - 192.189.218.0/24 19201 0.3% AS393276 -- CEA - Chugach Electric Association, Inc.,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 frnkblk at iname.com Sat Mar 7 04:35:36 2015 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 6 Mar 2015 22:35:36 -0600 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <20150303225705.8DE772AC8A13@rock.dv.isc.org> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> <54F4F500.8090303@pari.edu> <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> <000101d05567$74b58530$5e208f90$@gmail.com> <20150303051439.B14E72ABEB33@rock.dv.isc.org> <54F57656.2010804@satchell.net> <20150303122840.428C22AC5068@rock.dv.isc.org> <20150303225705.8DE772AC8A13@rock.dv.isc.org> Message-ID: <000101d05890$281f28d0$785d7a70$@iname.com> The download/upload in our residential/business eyeball network has been trending a 95th-percentile based ratio of 9:1. If I look at a higher-ed customer of ours who has symmetric service and has a young demographic the average ratio is 11:1 and the peak ratio 8.8:1. So despite access to symmetric speeds, they're not showing a distinctively heavier symmetricity. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Andrews Sent: Tuesday, March 03, 2015 4:57 PM To: Scott Helms Cc: NANOG Subject: Re: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] Averages hide the peak demands. The last mile should handle the peak demands. Further upstream you get the over subscription savings. Looking at averages and saying that they define the needs limits is *bad* engineering. For POTS you would get a few hertz if you did that. The averaging of POTS comes once you combine multiple sources together at the exchange. Even then you look at the peak periods not the daily average. Asymetry is pushing oversubscription too close to the consumer. It is a undesirable but sometimes necessary trade off. Asymetry traffic volumes don't mean asymetric speeds are desirable. Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From james.cutler at consultant.com Sat Mar 7 14:50:48 2015 From: james.cutler at consultant.com (James R Cutler) Date: Sat, 7 Mar 2015 09:50:48 -0500 Subject: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality] In-Reply-To: <000101d05890$281f28d0$785d7a70$@iname.com> References: <17150973.878.1425142741140.JavaMail.mhammett@ThunderFuck> <54F1F97A.2030000@mtcc.com> <00a601d053a4$2445a3b0$6cd0eb10$@gwsystems.co.il> <20150228224632.CB39B2A930D4@rock.dv.isc.org> <54F48F98.9060906@pari.edu> <6D91D962-9FE6-41CC-AC36-8446E435A3FC@delong.com> <54F4F500.8090303@pari.edu> <0EBB3295-1C3C-44C9-9F15-8235372AA57F@delong.com> <000101d05567$74b58530$5e208f90$@gmail.com> <20150303051439.B14E72ABEB33@rock.dv.isc.org> <54F57656.2010804@satchell.net> <20150303122840.428C22AC5068@rock.dv.isc.org> <20150303225705.8DE772AC8A13@rock.dv.isc.org> <000101d05890$281f28d0$785d7a70$@iname.com> Message-ID: <42BC42FB-846D-456A-A4FF-DE4E69C19661@consultant.com> Frank, Are your measurements taken at the campus boundary or within the campus network? I remember the confusion when Centrex was first introduced at UMich. The statistic there that confounded was call durations wildly exceeding models, but mostly within the campus, not to the outside world. Could there be peer to peer traffic that you do not see? James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu > On Mar 6, 2015, at 11:35 PM, Frank Bulk wrote: > > The download/upload in our residential/business eyeball network has been > trending a 95th-percentile based ratio of 9:1. If I look at a higher-ed > customer of ours who has symmetric service and has a young demographic the > average ratio is 11:1 and the peak ratio 8.8:1. So despite access to > symmetric speeds, they're not showing a distinctively heavier symmetricity. > > > Frank > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 872 bytes Desc: Message signed with OpenPGP using GPGMail URL: From aiwamoto at unleashed-technologies.com Sat Mar 7 15:37:08 2015 From: aiwamoto at unleashed-technologies.com (Andrew Iwamoto) Date: Sat, 7 Mar 2015 15:37:08 +0000 Subject: ASN to IP Mapping Message-ID: Is there a tool or method to determine IP blocks assigned to an organization by ASN? I.e. if I have an organization's ASN number I want to know all blocks assigned to that ASN. Thank you. Andrew Iwamoto Unleashed Technologies From morrowc.lists at gmail.com Sat Mar 7 20:47:17 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 7 Mar 2015 15:47:17 -0500 Subject: ASN to IP Mapping In-Reply-To: References: Message-ID: On Sat, Mar 7, 2015 at 10:37 AM, Andrew Iwamoto wrote: > Is there a tool or method to determine IP blocks assigned to an organization by ASN? I.e. if I have an organization's ASN number I want to know all blocks assigned to that ASN. > you mean like radb? or follow the example for ip -> asn from joe: http://pages.uoregon.edu/joe/one-pager-asn.pdf what's the end goal you have? "make bgp filters" something else? -chris From mansoor.nathani at mnathani.com Sat Mar 7 20:58:54 2015 From: mansoor.nathani at mnathani.com (Mansoor Nathani) Date: Sat, 7 Mar 2015 15:58:54 -0500 Subject: ASN to IP Mapping In-Reply-To: References: Message-ID: Perhaps look at http://bgp.he.net For instance: http://bgp.he.net/AS15169#_prefixes Mansoor On Sat, Mar 7, 2015 at 10:37 AM, Andrew Iwamoto < aiwamoto at unleashed-technologies.com> wrote: > Is there a tool or method to determine IP blocks assigned to an > organization by ASN? I.e. if I have an organization's ASN number I want to > know all blocks assigned to that ASN. > > Thank you. > > Andrew Iwamoto > Unleashed Technologies > > From pmsac.nanog at gmail.com Sat Mar 7 21:04:29 2015 From: pmsac.nanog at gmail.com (Pedro Cavaca) Date: Sat, 7 Mar 2015 21:04:29 +0000 Subject: ASN to IP Mapping In-Reply-To: References: Message-ID: I'm partial to IRR inverse queries on origin: 'whois -h whois.radb.net -- "-i origin AS" | grep route' On 7 March 2015 at 20:58, Mansoor Nathani wrote: > Perhaps look at http://bgp.he.net > > For instance: http://bgp.he.net/AS15169#_prefixes > > Mansoor > > On Sat, Mar 7, 2015 at 10:37 AM, Andrew Iwamoto < > aiwamoto at unleashed-technologies.com> wrote: > > > Is there a tool or method to determine IP blocks assigned to an > > organization by ASN? I.e. if I have an organization's ASN number I want > to > > know all blocks assigned to that ASN. > > > > Thank you. > > > > Andrew Iwamoto > > Unleashed Technologies > > > > > From hank at efes.iucc.ac.il Sat Mar 7 21:04:54 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 07 Mar 2015 23:04:54 +0200 Subject: ASN to IP Mapping In-Reply-To: Message-ID: <5.1.1.6.2.20150307230338.01eeb7a8@efes.iucc.ac.il> At 15:37 07/03/2015 +0000, Andrew Iwamoto wrote: >Is there a tool or method to determine IP blocks assigned to an >organization by ASN? I.e. if I have an organization's ASN number I want >to know all blocks assigned to that ASN. I use the excellent tool: http://bgp.he.net/ and select the "Prefixes V4" tab after entering the ASN in the webform. -Hank >Thank you. > >Andrew Iwamoto >Unleashed Technologies From rubensk at gmail.com Sat Mar 7 21:12:50 2015 From: rubensk at gmail.com (Rubens Kuhl) Date: Sat, 7 Mar 2015 18:12:50 -0300 Subject: ASN to IP Mapping In-Reply-To: References: Message-ID: On Sat, Mar 7, 2015 at 12:37 PM, Andrew Iwamoto < aiwamoto at unleashed-technologies.com> wrote: > Is there a tool or method to determine IP blocks assigned to an > organization by ASN? I.e. if I have an organization's ASN number I want to > know all blocks assigned to that ASN. > That's RIR/NIR-dependent, so you probably have to go thru all of them to map all possible IP blocks. Other references suggested bgp.he.net that will only list advertised networks, and IRRs will only have IRR-listed networks. For instance, on ARIN for AS 15141: http://whois.arin.net/rest/asn/AS15141 Find the organization name; click on the link http://whois.arin.net/rest/org/BAUSCH-1.html Find the networks link: http://whois.arin.net/rest/org/BAUSCH-1/nets Network ResourcesBAUSCH-LOMB (NET-161-242-0-0-1 )161.242.0.0 - 161.242.255.255 Look for the other RIRs; rinse and repeat. Rubens From rali.ahmed at gmail.com Sat Mar 7 21:20:17 2015 From: rali.ahmed at gmail.com (Rashed Alwarrag) Date: Sun, 8 Mar 2015 00:20:17 +0300 Subject: Facebook and Twitter outage Message-ID: Hi All is there any global issue to access Facebook and twitter we are facing a problem from AS25019 for some subnets -- *Rashed Alwarrag * From bob at FiberInternetCenter.com Sat Mar 7 21:37:47 2015 From: bob at FiberInternetCenter.com (Bob Evans) Date: Sat, 7 Mar 2015 13:37:47 -0800 Subject: ASN to IP Mapping In-Reply-To: References: Message-ID: Step 1: Input an IP prefix for the originating ASN of a prefix https://radar.qrator.net Step2: Check the RIR whois (as stated below) for confirmation as to who's assigned space. Thank You Bob Evans CTO > On Sat, Mar 7, 2015 at 12:37 PM, Andrew Iwamoto < > aiwamoto at unleashed-technologies.com> wrote: > >> Is there a tool or method to determine IP blocks assigned to an >> organization by ASN? I.e. if I have an organization's ASN number I want >> to >> know all blocks assigned to that ASN. >> > > That's RIR/NIR-dependent, so you probably have to go thru all of them to > map all possible IP blocks. Other references suggested bgp.he.net that > will > only list advertised networks, and IRRs will only have IRR-listed > networks. > > For instance, on ARIN for AS 15141: > > http://whois.arin.net/rest/asn/AS15141 > > Find the organization name; click on the link > http://whois.arin.net/rest/org/BAUSCH-1.html > > Find the networks link: > http://whois.arin.net/rest/org/BAUSCH-1/nets > > Network ResourcesBAUSCH-LOMB (NET-161-242-0-0-1 > )161.242.0.0 - > 161.242.255.255 > > Look for the other RIRs; rinse and repeat. > > > > Rubens > From nick at foobar.org Sat Mar 7 21:42:24 2015 From: nick at foobar.org (Nick Hilliard) Date: Sat, 07 Mar 2015 21:42:24 +0000 Subject: ASN to IP Mapping In-Reply-To: References: Message-ID: <54FB70C0.4050408@foobar.org> On 07/03/2015 15:37, Andrew Iwamoto wrote: > Is there a tool or method to determine IP blocks assigned to an > organization by ASN? I.e. if I have an organization's ASN number I want > to know all blocks assigned to that ASN. ip address blocks are not assigned to ASNs. IP address blocks and ASNs are assigned to organisations or people. If IP address blocks are used on the public internet, there is no guarantee that the ASN used to announce them is assigned to the same organisation that was assigned those blocks. Several people have made suggestions to use various lookup tools: - IRR databases will often return garbage, and it is unwise to depend on their output being accurate. - live lookups up ASN announcements on the public internet will only tell you who is currently announcing a particular prefix on a particular asn. This will not give any information - some RIR databases provide accurate allocation trails. Probably the RIPE NCC is most accurate / easy to use in this regard because of the way their data is presented in their database. This will only apply to allocations they've made, though. Anyway, it's not fully clear what you're asking. If you need a more specific answer, you will need to ask a more specific question. Nick From gih at apnic.net Sun Mar 8 00:16:07 2015 From: gih at apnic.net (Geoff Huston) Date: Sun, 8 Mar 2015 11:16:07 +1100 Subject: ASN to IP Mapping In-Reply-To: References: Message-ID: > >> Is there a tool or method to determine IP blocks assigned to an >> organization by ASN? I.e. if I have an organization's ASN number I want to >> know all blocks assigned to that ASN. >> > If you want to know the registry assignments / allocations made to a single entity and be able group together these assignments of address prefixes and ASNs you should retrieve the combined extended stats file from the RIRs (https://www.nro.net/wp-content/uploads/apnic-uploads/delegated-extended) and group together all those entries with a common value in column 8 (except for the entries corresponding to assignments and allocations made by the RIPE NCC, where this information is, unfortunately, not published by them in such a convenient format.) Geoff From randy at psg.com Sun Mar 8 02:39:57 2015 From: randy at psg.com (Randy Bush) Date: Sun, 08 Mar 2015 11:39:57 +0900 Subject: ASN to IP Mapping In-Reply-To: References: Message-ID: > If you want to know the registry assignments / allocations made to a > single entity and be able group together these assignments of address > prefixes and ASNs you should retrieve the combined extended stats file > from the RIRs > (https://www.nro.net/wp-content/uploads/apnic-uploads/delegated-extended) > and group together all those entries with a common value in column 8 > (except for the entries corresponding to assignments and allocations > made by the RIPE NCC, where this information is, unfortunately, not > published by them in such a convenient format.) care to give a decode for the fields in that file? :) randy From gih at apnic.net Sun Mar 8 03:37:40 2015 From: gih at apnic.net (Geoff Huston) Date: Sun, 8 Mar 2015 14:37:40 +1100 Subject: ASN to IP Mapping In-Reply-To: References: Message-ID: > On 8 Mar 2015, at 1:39 pm, Randy Bush wrote: > >> If you want to know the registry assignments / allocations made to a >> single entity and be able group together these assignments of address >> prefixes and ASNs you should retrieve the combined extended stats file >> from the RIRs >> (https://www.nro.net/wp-content/uploads/apnic-uploads/delegated-extended) >> and group together all those entries with a common value in column 8 >> (except for the entries corresponding to assignments and allocations >> made by the RIPE NCC, where this information is, unfortunately, not >> published by them in such a convenient format.) > > care to give a decode for the fields in that file? :) sure, I'll try. for example: arin|US|asn|32|1|19840924|assigned|658cc9c515b51665f88b7fd1bc213d20|e-stats Col 1 - RIR name, or 'iana' Col 2 - The country where the entity 'resides' (or 'EU' in some cases), or 'ZZ' for reserved and unassigned blocks Col 3 - 'asn' or 'ipv4' or 'ipv6' Col 4 - The size of the allocation (asn or IPv4) or the prefix length (ipv6) Col 5 - The starting value of the block Col 6 - A date. For some registries this is the date of the original allocation - for others (ARIN) its not so clear precisely what this date signifies (!) Col 7 - Status of the block Col 8 - A hash field of the entity code (mu;ltiple allocations to the same entity have the same code) or null (RIPE NCC, IANA) Col 9 - The source of the record (either "e-stats' where the original source is an extended stats file published by an RIR, or 'iana' if the data is lifted from an IANA registry) From morrowc.lists at gmail.com Sun Mar 8 06:49:22 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 8 Mar 2015 01:49:22 -0500 Subject: ASN to IP Mapping In-Reply-To: References: Message-ID: it looks like Col-8 is normalized on 'OrgId' right? So if the company has many org-ids you'd have to track all of those down to get a clear(er) picture. On Sat, Mar 7, 2015 at 10:37 PM, Geoff Huston wrote: > >> On 8 Mar 2015, at 1:39 pm, Randy Bush wrote: >> >>> If you want to know the registry assignments / allocations made to a >>> single entity and be able group together these assignments of address >>> prefixes and ASNs you should retrieve the combined extended stats file >>> from the RIRs >>> (https://www.nro.net/wp-content/uploads/apnic-uploads/delegated-extended) >>> and group together all those entries with a common value in column 8 >>> (except for the entries corresponding to assignments and allocations >>> made by the RIPE NCC, where this information is, unfortunately, not >>> published by them in such a convenient format.) >> >> care to give a decode for the fields in that file? :) > > > sure, I'll try. > > for example: > arin|US|asn|32|1|19840924|assigned|658cc9c515b51665f88b7fd1bc213d20|e-stats > > Col 1 - RIR name, or 'iana' > Col 2 - The country where the entity 'resides' (or 'EU' in some cases), or 'ZZ' for reserved and unassigned blocks > Col 3 - 'asn' or 'ipv4' or 'ipv6' > Col 4 - The size of the allocation (asn or IPv4) or the prefix length (ipv6) > Col 5 - The starting value of the block > Col 6 - A date. For some registries this is the date of the original allocation - for others (ARIN) its not so clear precisely what this date signifies (!) > Col 7 - Status of the block > Col 8 - A hash field of the entity code (mu;ltiple allocations to the same entity have the same code) or null (RIPE NCC, IANA) > Col 9 - The source of the record (either "e-stats' where the original source is an extended stats file published by an RIR, or 'iana' if the data is lifted from an IANA registry) > > > From mathieu.poussin at netyxia.net Sat Mar 7 20:48:35 2015 From: mathieu.poussin at netyxia.net (Mathieu Poussin) Date: Sat, 7 Mar 2015 21:48:35 +0100 Subject: ASN to IP Mapping In-Reply-To: References: Message-ID: Hi Andrew. Check this script I made sometime ago, it gets the information you want, I was using it to reroute all the networks of specifics AS trough a VPN : https://github.com/mathieupoussin/junos_reroute_asn/blob/master/reroute_asn.pl To make it simpler, use the command "whois -h whois.radb.net -i origin 12345", make sure you use the RIPE whois client. Best regards, Mathieu On 7 March 2015 at 16:37, Andrew Iwamoto wrote: > Is there a tool or method to determine IP blocks assigned to an organization by ASN? I.e. if I have an organization's ASN number I want to know all blocks assigned to that ASN. > > Thank you. > > Andrew Iwamoto > Unleashed Technologies > From randy at psg.com Sun Mar 8 07:07:12 2015 From: randy at psg.com (Randy Bush) Date: Sun, 08 Mar 2015 16:07:12 +0900 Subject: ASN to IP Mapping In-Reply-To: References: Message-ID: > So if the company has many org-ids you'd have to track all of those > down to get a clear(er) picture. and good luck with that in the arin region From hank at efes.iucc.ac.il Sun Mar 8 07:35:58 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 08 Mar 2015 09:35:58 +0200 Subject: ASN to IP Mapping In-Reply-To: References: Message-ID: <5.1.1.6.2.20150308093452.01fba2e8@efes.iucc.ac.il> At 14:37 08/03/2015 +1100, Geoff Huston wrote: > > On 8 Mar 2015, at 1:39 pm, Randy Bush wrote: > > > >> If you want to know the registry assignments / allocations made to a > >> single entity and be able group together these assignments of address > >> prefixes and ASNs you should retrieve the combined extended stats file > >> from the RIRs > >> (https://www.nro.net/wp-content/uploads/apnic-uploads/delegated-extended) > >> and group together all those entries with a common value in column 8 > >> (except for the entries corresponding to assignments and allocations > >> made by the RIPE NCC, where this information is, unfortunately, not > >> published by them in such a convenient format.) > > > > care to give a decode for the fields in that file? :) > > >sure, I'll try. Or: https://www.nro.net/wp-content/uploads/nro-extended-stats-readme5.txt -Hank >for example: > >arin|US|asn|32|1|19840924|assigned|658cc9c515b51665f88b7fd1bc213d20|e-stats > >Col 1 - RIR name, or 'iana' >Col 2 - The country where the entity 'resides' (or 'EU' in some cases), or >'ZZ' for reserved and unassigned blocks >Col 3 - 'asn' or 'ipv4' or 'ipv6' >Col 4 - The size of the allocation (asn or IPv4) or the prefix length (ipv6) >Col 5 - The starting value of the block >Col 6 - A date. For some registries this is the date of the original >allocation - for others (ARIN) its not so clear precisely what this date >signifies (!) >Col 7 - Status of the block >Col 8 - A hash field of the entity code (mu;ltiple allocations to the same >entity have the same code) or null (RIPE NCC, IANA) >Col 9 - The source of the record (either "e-stats' where the original >source is an extended stats file published by an RIR, or 'iana' if the >data is lifted from an IANA registry) From gih at apnic.net Sun Mar 8 09:32:09 2015 From: gih at apnic.net (Geoff Huston) Date: Sun, 8 Mar 2015 20:32:09 +1100 Subject: ASN to IP Mapping In-Reply-To: <5.1.1.6.2.20150308093452.01fba2e8@efes.iucc.ac.il> References: <5.1.1.6.2.20150308093452.01fba2e8@efes.iucc.ac.il> Message-ID: <63A4DB3F-71B6-4F2D-BA7C-61C941438100@apnic.net> > On 8 Mar 2015, at 6:35 pm, Hank Nussbacher wrote: > > At 14:37 08/03/2015 +1100, Geoff Huston wrote: > >> > On 8 Mar 2015, at 1:39 pm, Randy Bush wrote: >> > >> >> If you want to know the registry assignments / allocations made to a >> >> single entity and be able group together these assignments of address >> >> prefixes and ASNs you should retrieve the combined extended stats file >> >> from the RIRs >> >> (https://www.nro.net/wp-content/uploads/apnic-uploads/delegated-extended) >> >> and group together all those entries with a common value in column 8 >> >> (except for the entries corresponding to assignments and allocations >> >> made by the RIPE NCC, where this information is, unfortunately, not >> >> published by them in such a convenient format.) >> > >> > care to give a decode for the fields in that file? :) >> >> >> sure, I'll try. > > Or: > https://www.nro.net/wp-content/uploads/nro-extended-stats-readme5.txt Users of this report should be aware that there are some subtle deviations from this spec in the published data: - the RIPE NCC uses the non-ISO 3166 2 letter code 'EU' for some allocations. I do not know exactly why; - the date field is not quite as described in that file for ARIN entries. Again, I do not know why. - the RIPE NCC does not provide the "opaque-id" in their records From hank at efes.iucc.ac.il Sun Mar 8 10:10:09 2015 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 8 Mar 2015 12:10:09 +0200 (IST) Subject: ASN to IP Mapping In-Reply-To: <63A4DB3F-71B6-4F2D-BA7C-61C941438100@apnic.net> References: <5.1.1.6.2.20150308093452.01fba2e8@efes.iucc.ac.il> <63A4DB3F-71B6-4F2D-BA7C-61C941438100@apnic.net> Message-ID: On Sun, 8 Mar 2015, Geoff Huston wrote: >> https://www.nro.net/wp-content/uploads/nro-extended-stats-readme5.txt > > > Users of this report should be aware that there are some subtle deviations from this spec in the published data: > - the RIPE NCC uses the non-ISO 3166 2 letter code 'EU' for some allocations. I do not know exactly why; I believe ERX records transferred from ARIN to RIPE will have EU listed as country code until RIPE is contacted to correct it. -Hank From drc at virtualized.org Sun Mar 8 20:09:45 2015 From: drc at virtualized.org (David Conrad) Date: Sun, 8 Mar 2015 14:09:45 -0600 Subject: ASN to IP Mapping In-Reply-To: <63A4DB3F-71B6-4F2D-BA7C-61C941438100@apnic.net> References: <5.1.1.6.2.20150308093452.01fba2e8@efes.iucc.ac.il> <63A4DB3F-71B6-4F2D-BA7C-61C941438100@apnic.net> Message-ID: <8D19EDA1-8952-44E6-BDEE-E141907B9725@virtualized.org> > Users of this report should be aware that there are some subtle deviations from this spec in the published data: > - the RIPE NCC uses the non-ISO 3166 2 letter code 'EU' for some allocations. I do not know exactly why; EU is, of course, an ISO-3166 2 letter code, it just happens to be "Exceptionally Reserved". I would naively have assumed EU was used for entities that span multiple European countries. > - the date field is not quite as described in that file for ARIN entries. Again, I do not know why. > - the RIPE NCC does not provide the "opaque-id" in their records http://xkcd.com/927/ 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 jmcc at hackwatch.com Sun Mar 8 12:37:28 2015 From: jmcc at hackwatch.com (John McCormac) Date: Sun, 08 Mar 2015 12:37:28 +0000 Subject: ASN to IP Mapping In-Reply-To: <63A4DB3F-71B6-4F2D-BA7C-61C941438100@apnic.net> References: <5.1.1.6.2.20150308093452.01fba2e8@efes.iucc.ac.il> <63A4DB3F-71B6-4F2D-BA7C-61C941438100@apnic.net> Message-ID: <54FC4288.6060508@hackwatch.com> On 08/03/2015 09:32, Geoff Huston wrote: > > Users of this report should be aware that there are some subtle deviations from this spec in the published data: > - the RIPE NCC uses the non-ISO 3166 2 letter code 'EU' for some allocations. I do not know exactly why; > - the date field is not quite as described in that file for ARIN entries. Again, I do not know why. > - the RIPE NCC does not provide the "opaque-id" in their records Some of the EU allocations seem to be CDNs and other trans-national operators. Regards...jmcc From christian.teuschel at ripe.net Mon Mar 9 11:28:59 2015 From: christian.teuschel at ripe.net (Christian Teuschel) Date: Mon, 09 Mar 2015 12:28:59 +0100 Subject: ASN to IP Mapping In-Reply-To: References: Message-ID: <54FD83FB.9030308@ripe.net> Hi Andrew, RIPEstat makes this easy for resources that belong to the RIPE NCC region: 1. Go to stat.ripe.net https://stat.ripe.net 2. Look up the ASN (for example, AS3333) https://stat.ripe.net/as3333 3. On the "Database" tab, navigate to the Registry Browser widget and click on the organisation object located in the right-hand list 4. The left-hand table lists all aut-num, inetnum and inet6num objects registered under this organisation object. https://stat.ripe.net/as3333#tabId=database&database_registry-browser.resource=organisation:ORG-RIEN1-RIPE Plans are to extend the Registry Browser to other RIR's databases as well. In the meanwhile the Routing Consistency can be of help for resources outside our region. https://stat.ripe.net/widget/as-routing-consistency#w.resource=AS3333 This widget lists and crosschecks routes found in BGP routing data (based on RIS [0]) as well as the RIPE NCC's and RADb's [1] Internet Routing Registries. The "Database" tab might contain other widgets that you find useful in case you are looking for Registry-related information. If you are interested in BGP routing-related data, the "Routing" tab is for you; specifically I'd like to point out the Announced Prefixes and Routing History widget. In case you have any questions on the presented information, please refer to the widget's "Info" button and/or RIPEstat's documentation [2]. Cheers, Christian [0] The Routing Information System (RIS), http://ris.ripe.net [1] http://www.radb.net/ [2] https://stat.ripe.net/docs/widget_api https://stat.ripe.net/docs/data_api On 07/03/15 16:37, Andrew Iwamoto wrote: > Is there a tool or method to determine IP blocks assigned to an organization by ASN? I.e. if I have an organization's ASN number I want to know all blocks assigned to that ASN. > > Thank you. > > Andrew Iwamoto > Unleashed Technologies > -------------- next part -------------- A non-text attachment was scrubbed... Name: christian_teuschel.vcf Type: text/x-vcard Size: 342 bytes Desc: not available URL: From chris.dye at paragon.net Mon Mar 9 17:19:48 2015 From: chris.dye at paragon.net (Christopher Dye) Date: Mon, 9 Mar 2015 17:19:48 +0000 Subject: NDS Resolution Problems between Charter Communications and OpenDNS Message-ID: If anyone from Charter Communications NetOps or OpenDNS NetOps is monitoring, could you please contact me off-list? It would seem AS36692 (OpenDNS) and AS23028 (Charter Communications) are having some issues playing together. Thanks Much, Chris Dye Chief Technical Officer Paragon Solutions Group, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5669 bytes Desc: not available URL: From chuckchurch at gmail.com Mon Mar 9 17:36:36 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Mon, 9 Mar 2015 13:36:36 -0400 Subject: NDS Resolution Problems between Charter Communications and OpenDNS In-Reply-To: References: Message-ID: <00b101d05a8f$9831d450$c8957cf0$@gmail.com> NDS? My first suggestion would be run DSREPAIR. Wow, that brings back memories. But since you probably mean DNS, I'll stop right there. Chuck -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher Dye Sent: Monday, March 09, 2015 1:20 PM To: nanog at nanog.org Subject: NDS Resolution Problems between Charter Communications and OpenDNS If anyone from Charter Communications NetOps or OpenDNS NetOps is monitoring, could you please contact me off-list? It would seem AS36692 (OpenDNS) and AS23028 (Charter Communications) are having some issues playing together. Thanks Much, Chris Dye Chief Technical Officer Paragon Solutions Group, Inc. From amekkaoui at mektel.ca Mon Mar 9 23:07:17 2015 From: amekkaoui at mektel.ca (A MEKKAOUI) Date: Mon, 9 Mar 2015 19:07:17 -0400 Subject: Phone adapter with router Message-ID: <009401d05abd$ca4b5dc0$5ee21940$@ca> Hi Do you know any good router with phone adapters to provide home phone and internet? We tried couple of them like Linksys, Thomson, etc. and no one does the job perfectly. Any comment will be appreciated. Thank you Karim From list_nanog at bluerosetech.com Mon Mar 9 15:55:53 2015 From: list_nanog at bluerosetech.com (list_nanog at bluerosetech.com) Date: Mon, 09 Mar 2015 08:55:53 -0700 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54F079AC.8020103@cox.net> References: <54F079AC.8020103@cox.net> Message-ID: <54FDC289.1010204@bluerosetech.com> They want to bang on about the ruling harming innovation and competition. My response: "Well, you were neither innovating nor competing as is, so no harm done." From Jason_Livingood at cable.comcast.com Tue Mar 10 01:57:48 2015 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Tue, 10 Mar 2015 01:57:48 +0000 Subject: HBO DNS Admins? Message-ID: Any DNS admins for HBO here? Your FQDN for order.hbonow.com looks a little messed up. http://dnsviz.net/d/order.hbonow.com/VP5DKQ/dnssec/ Jason From casey at deccio.net Tue Mar 10 02:18:00 2015 From: casey at deccio.net (Casey Deccio) Date: Mon, 9 Mar 2015 22:18:00 -0400 Subject: HBO DNS Admins? In-Reply-To: References: Message-ID: On Mon, Mar 9, 2015 at 9:57 PM, Livingood, Jason < Jason_Livingood at cable.comcast.com> wrote: > Any DNS admins for HBO here? Your FQDN for order.hbonow.com looks a > little messed up. > http://dnsviz.net/d/order.hbonow.com/VP5DKQ/dnssec/ > > Looks like the DS records for hbonow.com have been pulled, so validation status will return to "insecure" (from "bogus") once the DS records clear the cache. http://dnsviz.net/d/order.hbonow.com/VP5RXw/dnssec/ Casey From Jason_Livingood at cable.comcast.com Tue Mar 10 03:04:11 2015 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Tue, 10 Mar 2015 03:04:11 +0000 Subject: HBO DNS Admins? In-Reply-To: References: Message-ID: And now the DS records are fixed, so we flushed the cache. It appears Google Public DNS has done the same. JL On 3/9/15, 10:18 PM, "Casey Deccio" > wrote: On Mon, Mar 9, 2015 at 9:57 PM, Livingood, Jason > wrote: Any DNS admins for HBO here? Your FQDN for order.hbonow.com looks a little messed up. http://dnsviz.net/d/order.hbonow.com/VP5DKQ/dnssec/ Looks like the DS records for hbonow.com have been pulled, so validation status will return to "insecure" (from "bogus") once the DS records clear the cache. http://dnsviz.net/d/order.hbonow.com/VP5RXw/dnssec/ Casey From joe at nethead.com Tue Mar 10 06:16:19 2015 From: joe at nethead.com (Joe Hamelin) Date: Mon, 9 Mar 2015 23:16:19 -0700 Subject: Phone adapter with router In-Reply-To: <009401d05abd$ca4b5dc0$5ee21940$@ca> References: <009401d05abd$ca4b5dc0$5ee21940$@ca> Message-ID: I've run into a few of these and they seem to do a good job. ftp://ftp.edgewaternetworks.com/pub/docs/CD_contents/DOCS/EdgeMarc/200/200%20Series%20Datasheet.pdf -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Mon, Mar 9, 2015 at 4:07 PM, A MEKKAOUI wrote: > Hi > > > > Do you know any good router with phone adapters to provide home phone and > internet? We tried couple of them like Linksys, Thomson, etc. and no one > does the job perfectly. Any comment will be appreciated. > > > > Thank you > > > > Karim > > > > From Kelly.Setzer at wnco.com Tue Mar 10 13:21:32 2015 From: Kelly.Setzer at wnco.com (Kelly Setzer) Date: Tue, 10 Mar 2015 13:21:32 +0000 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <54FDC289.1010204@bluerosetech.com> References: <54F079AC.8020103@cox.net> <54FDC289.1010204@bluerosetech.com> Message-ID: Many other organizations who were innovating will be affected by the new rules. Many of those organizations are very small and cannot afford the army of lawyers that Verizon can. Judgements as to whether Net Neutrality helps or harms any specific industry will be inevitably guided by politics. The mere fact that politics has become a guiding factor in Internet-related public policy is an indicator that we must tread cautiously. And, no, I do not think recent regulatory efforts have been suitably cautious. Enacting unpublished rules violates the spirit and history of open design, open discussion, and open standards that have made the Internet what it is today. Kelly On 3/9/15, 10:55 AM, "list_nanog at bluerosetech.com" wrote: >They want to bang on about the ruling harming innovation and >competition. My response: "Well, you were neither innovating nor >competing as is, so no harm done." ******* CONFIDENTIALITY NOTICE ******* This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message from your system. Thank you. From spedersen at io.com Tue Mar 10 13:44:40 2015 From: spedersen at io.com (Pedersen, Sean) Date: Tue, 10 Mar 2015 13:44:40 +0000 Subject: Phone adapter with router In-Reply-To: References: <009401d05abd$ca4b5dc0$5ee21940$@ca> Message-ID: +1 Used them in a past life as a SIP ALG and NAT router for a “bring your own broadband” hosted SIP service. Worked well enough. You might get more suggestions if you provide a little bit more about what your requirements are, how they’re being deployed (one-off, ISP, etc.), or what the others didn’t do well. On 3/9/15, 11:16 PM, "Joe Hamelin" wrote: >I've run into a few of these and they seem to do a good job. > >ftp://ftp.edgewaternetworks.com/pub/docs/CD_contents/DOCS/EdgeMarc/200/200%20Series%20Datasheet.pdf > >-- >Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > >On Mon, Mar 9, 2015 at 4:07 PM, A MEKKAOUI wrote: > >> Hi >> >> >> >> Do you know any good router with phone adapters to provide home phone and >> internet? We tried couple of them like Linksys, Thomson, etc. and no one >> does the job perfectly. Any comment will be appreciated. >> >> >> >> Thank you >> >> >> >> Karim >> >> >> >> Founded in 2007, IO provides the data center as a service to businesses and governments around the world. The communication contained in this e-mail is confidential and is intended only for the named recipient(s) and may contain information that is privileged, proprietary, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. Please immediately notify the sender of the error, and delete this communication including any attached files from your system. Thank you for your cooperation. From khelms at zcorum.com Tue Mar 10 19:04:53 2015 From: khelms at zcorum.com (Scott Helms) Date: Tue, 10 Mar 2015 15:04:53 -0400 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: <21750.6555.982808.967978@world.std.com> References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> <54F31DBE.9060603@meetinghouse.net> <21748.52254.768347.50688@world.std.com> <21750.2698.430920.443976@world.std.com> <21750.6555.982808.967978@world.std.com> Message-ID: Barry, First, I want to apologize. I (badly) misread your email, but in case I should not have responded that way. I would have gotten this out sooner, but I was traveling back from the CableLabs conference. Second, my assertion is simply that Usenet servers aren't automagically symmetrical in their bandwidth usage and that trying to build a system off of NNTP so that each broadband subscriber became in effect a Usenet server wouldn't work well without significant modifications. Third, if anyone cares the Usenet server we ran was news.america.net Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Tue, Mar 3, 2015 at 3:29 PM, Barry Shein wrote: > > From: Scott Helms > > > >/em shrug > > > >I can't help it if you don't like real world data. > >On Mar 3, 2015 2:25 PM, "Barry Shein" wrote: > > > >> > >> Ok, then I no longer have any confidence that I understand what you > >> were asserting. > > Generally when someone says they don't understand me I assume it's my > fault for not being clear and try to clarify. > > Apparently you prefer to be rude. > > *Plonk* > > -- > -Barry Shein > > The World | bzs at TheWorld.com | > http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, > Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* > From brandon.galbraith at gmail.com Tue Mar 10 20:04:12 2015 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Tue, 10 Mar 2015 15:04:12 -0500 Subject: Phone adapter with router In-Reply-To: References: <009401d05abd$ca4b5dc0$5ee21940$@ca> Message-ID: Quick hijack: Can anyone recommend a device that will terminate to a phone, supports SIP, *and* can fallback to SIM for emergency calls? On Tue, Mar 10, 2015 at 8:44 AM, Pedersen, Sean wrote: > +1 > > Used them in a past life as a SIP ALG and NAT router for a “bring your own broadband” hosted SIP service. Worked well enough. > > You might get more suggestions if you provide a little bit more about what your requirements are, how they’re being deployed (one-off, ISP, etc.), or what the others didn’t do well. > > > > On 3/9/15, 11:16 PM, "Joe Hamelin" wrote: > >>I've run into a few of these and they seem to do a good job. >> >>ftp://ftp.edgewaternetworks.com/pub/docs/CD_contents/DOCS/EdgeMarc/200/200%20Series%20Datasheet.pdf >> >>-- >>Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 >> >>On Mon, Mar 9, 2015 at 4:07 PM, A MEKKAOUI wrote: >> >>> Hi >>> >>> >>> >>> Do you know any good router with phone adapters to provide home phone and >>> internet? We tried couple of them like Linksys, Thomson, etc. and no one >>> does the job perfectly. Any comment will be appreciated. >>> >>> >>> >>> Thank you >>> >>> >>> >>> Karim >>> >>> >>> >>> > > > Founded in 2007, IO provides the data center as a service to businesses and governments around the world. > > The communication contained in this e-mail is confidential and is intended only for the named recipient(s) and may contain information that is privileged, proprietary, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. Please immediately notify the sender of the error, and delete this communication including any attached files from your system. Thank you for your cooperation. From mhuff at ox.com Tue Mar 10 23:40:43 2015 From: mhuff at ox.com (Matthew Huff) Date: Tue, 10 Mar 2015 23:40:43 +0000 Subject: Purpose of spoofed packets ??? Message-ID: <851dacde19f14eeca82d0c9b6aff89c8@pur-vm-exch13n1.ox.com> We recently got an abuse report of an IP address in our net range. However, that IP address isn't in use in our networks and the covering network is null routed, so no return traffic is possible. We have external BGP monitoring, so unless something very tricky is going on, we don't have part of our prefix hijacked. I assume the source address was spoofed, but this leads to my question. Since the person that submitted the report didn't mention a high packet rate (it was on ssh port 22), it doesn't look like some sort of SYN attack, but any OS fingerprinting or doorknob twisting wouldn't be useful from the attacker if the traffic doesn't return to them, so what gives? BTW, we are in the ARIN region, the report came out of the RIPE region. ---- Matthew Huff             | 1 Manhattanville Rd Director of Operations   | Purchase, NY 10577 OTA Management LLC       | Phone: 914-460-4039 aim: matthewbhuff        | Fax:   914-694-5669 From rdobbins at arbor.net Tue Mar 10 23:51:23 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 11 Mar 2015 06:51:23 +0700 Subject: Purpose of spoofed packets ??? In-Reply-To: <851dacde19f14eeca82d0c9b6aff89c8@pur-vm-exch13n1.ox.com> References: <851dacde19f14eeca82d0c9b6aff89c8@pur-vm-exch13n1.ox.com> Message-ID: <065A0501-2DDE-4216-B785-D3D72E14A635@arbor.net> On 11 Mar 2015, at 6:40, Matthew Huff wrote: > I assume the source address was spoofed, but this leads to my > question. Since the person that submitted the report didn't mention a > high packet rate (it was on ssh port 22), it doesn't look like some > sort of SYN attack, but any OS fingerprinting or doorknob twisting > wouldn't be useful from the attacker if the traffic doesn't return to > them, so what gives? Highly-distributed, pseudo-randomly spoofed SYN-flood happened to momentarily use one of your addresses as a source. pps/source will be relatively low, whilst aggregate at the target will be relatively high. Another very real possibility is that the person or thing which sent you the abuse email doesn't know what he's/it's talking about. ;> ----------------------------------- Roland Dobbins From fred at web2objects.com Tue Mar 10 23:53:43 2015 From: fred at web2objects.com (Fred Hollis) Date: Wed, 11 Mar 2015 00:53:43 +0100 Subject: Purpose of spoofed packets ??? In-Reply-To: <851dacde19f14eeca82d0c9b6aff89c8@pur-vm-exch13n1.ox.com> References: <851dacde19f14eeca82d0c9b6aff89c8@pur-vm-exch13n1.ox.com> Message-ID: <54FF8407.7090503@web2objects.com> Interesting... we had exactly the same an hour ago. That IP was definitely nullrouted for >1 week... Matthew Huff: > We recently got an abuse report of an IP address in our net range. However, that IP address isn't in use in our networks and the covering network is null routed, so no return traffic is possible. We have external BGP monitoring, so unless something very tricky is going on, we don't have part of our prefix hijacked. > > I assume the source address was spoofed, but this leads to my question. Since the person that submitted the report didn't mention a high packet rate (it was on ssh port 22), it doesn't look like some sort of SYN attack, but any OS fingerprinting or doorknob twisting wouldn't be useful from the attacker if the traffic doesn't return to them, so what gives? > > BTW, we are in the ARIN region, the report came out of the RIPE region. > > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-694-5669 > From laszlo at heliacal.net Wed Mar 11 00:01:43 2015 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Wed, 11 Mar 2015 00:01:43 +0000 Subject: Purpose of spoofed packets ??? In-Reply-To: <065A0501-2DDE-4216-B785-D3D72E14A635@arbor.net> References: <851dacde19f14eeca82d0c9b6aff89c8@pur-vm-exch13n1.ox.com> <065A0501-2DDE-4216-B785-D3D72E14A635@arbor.net> Message-ID: Is it possible that they are getting return traffic and it's just a localized activity? The attacker could announce that prefix directly to the target network in an IXP peering session (maybe with no-export) so that it wouldn't set off your bgpmon. I guess that would make more sense if they were doing email spamming instead of ssh though. -Laszlo On Mar 10, 2015, at 11:51 PM, "Roland Dobbins" wrote: > > On 11 Mar 2015, at 6:40, Matthew Huff wrote: > >> I assume the source address was spoofed, but this leads to my question. Since the person that submitted the report didn't mention a high packet rate (it was on ssh port 22), it doesn't look like some sort of SYN attack, but any OS fingerprinting or doorknob twisting wouldn't be useful from the attacker if the traffic doesn't return to them, so what gives? > > Highly-distributed, pseudo-randomly spoofed SYN-flood happened to momentarily use one of your addresses as a source. pps/source will be relatively low, whilst aggregate at the target will be relatively high. > > Another very real possibility is that the person or thing which sent you the abuse email doesn't know what he's/it's talking about. > > ;> > > ----------------------------------- > Roland Dobbins From mhuff at ox.com Wed Mar 11 00:16:00 2015 From: mhuff at ox.com (Matthew Huff) Date: Wed, 11 Mar 2015 00:16:00 +0000 Subject: Purpose of spoofed packets ??? In-Reply-To: <065A0501-2DDE-4216-B785-D3D72E14A635@arbor.net> References: <851dacde19f14eeca82d0c9b6aff89c8@pur-vm-exch13n1.ox.com> <065A0501-2DDE-4216-B785-D3D72E14A635@arbor.net> Message-ID: >> Another very real possibility is that the person or thing which sent >>you >> the abuse email doesn't know what he's/it's talking about. Was my first thought, but wanted to run this by everyone in case I was missing something obvious. On 3/10/15, 7:51 PM, "Roland Dobbins" wrote: > >On 11 Mar 2015, at 6:40, Matthew Huff wrote: > >> I assume the source address was spoofed, but this leads to my >> question. Since the person that submitted the report didn't mention a >> high packet rate (it was on ssh port 22), it doesn't look like some >> sort of SYN attack, but any OS fingerprinting or doorknob twisting >> wouldn't be useful from the attacker if the traffic doesn't return to >> them, so what gives? > >Highly-distributed, pseudo-randomly spoofed SYN-flood happened to >momentarily use one of your addresses as a source. pps/source will be >relatively low, whilst aggregate at the target will be relatively high. > >Another very real possibility is that the person or thing which sent you >the abuse email doesn't know what he's/it's talking about. > >;> > >----------------------------------- >Roland Dobbins From steve at blighty.com Wed Mar 11 01:15:04 2015 From: steve at blighty.com (Steve Atkins) Date: Tue, 10 Mar 2015 18:15:04 -0700 Subject: Purpose of spoofed packets ??? In-Reply-To: <851dacde19f14eeca82d0c9b6aff89c8@pur-vm-exch13n1.ox.com> References: <851dacde19f14eeca82d0c9b6aff89c8@pur-vm-exch13n1.ox.com> Message-ID: On Mar 10, 2015, at 4:40 PM, Matthew Huff wrote: > We recently got an abuse report of an IP address in our net range. However, that IP address isn't in use in our networks and the covering network is null routed, so no return traffic is possible. We have external BGP monitoring, so unless something very tricky is going on, we don't have part of our prefix hijacked. > > I assume the source address was spoofed, but this leads to my question. Since the person that submitted the report didn't mention a high packet rate (it was on ssh port 22), it doesn't look like some sort of SYN attack, but any OS fingerprinting or doorknob twisting wouldn't be useful from the attacker if the traffic doesn't return to them, so what gives? > > BTW, we are in the ARIN region, the report came out of the RIPE region. Either the reporter doesn't know what they're talking about (common enough) or someone is scanning for open ssh ports, hiding their real IP address by burying it in a host of faked source addresses. That's a standard option on some of the stealthier port scanners, IIRC. Cheers, Steve From owen at delong.com Wed Mar 11 01:51:51 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 10 Mar 2015 18:51:51 -0700 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <54F079AC.8020103@cox.net> <54FDC289.1010204@bluerosetech.com> Message-ID: <7C2380D8-21EF-4AB2-8386-FFA28287D33D@delong.com> > On Mar 10, 2015, at 06:21 , Kelly Setzer wrote: > > Many other organizations who were innovating will be affected by the new > rules. Many of those organizations are very small and cannot afford the > army of lawyers that Verizon can. Such as? Can you provide any actual examples of harmful effects or are you just ranting because you don’t like government involvement? > And, no, I do not think recent regulatory efforts have been suitably > cautious. Enacting unpublished rules violates the spirit and history of > open design, open discussion, and open standards that have made the > Internet what it is today. The rules are not unpublished, nor will they be unpublished when they are enacted. It’s true that the R&O isn’t out yet, but the actual rules (47CFR8) are published. Nothing takes effect until the R&O is published and due process is followed. I can accept that there may not have been sufficient caution, but your claim that the current process violates the spirit and history of open design, open discussion, and open standards simply does not apply. The FCC followed the NPRM process and accepted a wide variety of public comment (and actually seems to have listened to the public comment in this case). As near as I can tell, they bent over backwards to be far more inclusive in the process than is historically normal in the FCC NPRM process. I get that you don’t like the outcome, but I feel that your criticisms of the process reflect more of a lack of understanding of the normal federal rulemaking process than any substantive failure of that process. Owen From bzs at world.std.com Wed Mar 11 02:45:04 2015 From: bzs at world.std.com (Barry Shein) Date: Tue, 10 Mar 2015 22:45:04 -0400 Subject: Verizon Policy Statement on Net Neutrality In-Reply-To: References: <13952758.7865.1425055485506.JavaMail.mhammett@ThunderFuck> <54F0A367.1020101@ufl.edu> <5221.1425057216@turing-police.cc.vt.edu> <54F0AAA2.20700@ufl.edu> <9578293AE169674F9A048B2BC9A081B4015725DE77@MUNPRDMBXA1.medline.com> <54F0C3AA.3000400@vocalabs.com> <54F0CC2D.9010900@vocalabs.com> <54F0D533.70100@vocalabs.com> <21746.17258.270398.162820@world.std.com> <54F24D31.40200@foobar.org> <21746.35420.759630.472893@world.std.com> <54F31DBE.9060603@meetinghouse.net> <21748.52254.768347.50688@world.std.com> <21750.2698.430920.443976@world.std.com> <21750.6555.982808.967978@world.std.com> Message-ID: <21759.44080.55863.770636@world.std.com> Not a problem, the discussion was getting a bit out of hand so misunderstandings are unsuprising. Thank you for adding your expertise and experiences. -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From: Scott Helms >Barry, > >First, I want to apologize. I (badly) misread your email, but in case I >should not have responded that way. I would have gotten this out sooner, >but I was traveling back from the CableLabs conference. > > >Second, my assertion is simply that Usenet servers aren't automagically >symmetrical in their bandwidth usage and that trying to build a system off >of NNTP so that each broadband subscriber became in effect a Usenet server >wouldn't work well without significant modifications. > >Third, if anyone cares the Usenet server we ran was news.america.net > > >Scott Helms >Vice President of Technology >ZCorum >(678) 507-5000 >-------------------------------- >http://twitter.com/kscotthelms >-------------------------------- > >On Tue, Mar 3, 2015 at 3:29 PM, Barry Shein wrote: > >> >> From: Scott Helms >> > >> >/em shrug >> > >> >I can't help it if you don't like real world data. >> >On Mar 3, 2015 2:25 PM, "Barry Shein" wrote: >> > >> >> >> >> Ok, then I no longer have any confidence that I understand what you >> >> were asserting. >> >> Generally when someone says they don't understand me I assume it's my >> fault for not being clear and try to clarify. >> >> Apparently you prefer to be rude. >> >> *Plonk* >> >> -- >> -Barry Shein >> >> The World | bzs at TheWorld.com | >> http://www.TheWorld.com >> Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, >> Canada >> Software Tool & Die | Public Access Internet | SINCE 1989 *oo* >> >
Barry,

First, I want to apologize.=C2= >=A0 I (badly) misread your email, but in case I should not have responded t= >hat way.=C2=A0 I would have gotten this out sooner, but I was traveling bac= >k from the CableLabs conference.


Se= >cond, my assertion is simply that Usenet servers aren't automagically s= >ymmetrical in their bandwidth usage and that trying to build a system off o= >f NNTP so that each broadband subscriber became in effect a Usenet server w= >ouldn't work well without significant modifications.

v>
Third, if anyone cares the Usenet server we ran was //news.america.net">news.america.net
ra">
= >

Scott Helms >
Vice President of Technology >
ZCorum >
(678) 507-5000 >
-------------------------------- >
http://twi= >tter.com/kscotthelms >
--------------------------------=C2=A0
>
On Tue, Mar 3, 2015 at 3:29 PM, Barry Shein = ><">bzs at world.std.com> wrote:
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"= >>
>From: Scott Helms <khelms at zcorum.co= >m>
>>
>>/em shrug
>>
>>I can't help it if you don't like real world data.
>>On Mar 3, 2015 2:25 PM, "Barry Shein" <zs at world.std.com">bzs at world.std.com> wrote:
>>
>>>
>>> Ok, then I no longer have any confidence that I understand what yo= >u
>>> were asserting.
>
>Generally when someone says they don't understand me I assume it's = >my
>fault for not being clear and try to clarify.
>
>Apparently you prefer to be rude.
>
>*Plonk*
>
>--
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 -Barry Shein
>
>The World=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | bzs at TheWorld.co= >m=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| com" target=3D"_blank">http://www.TheWorld.com
>Purveyors to the Trade | Voice: 800-THE-WRLD=C2=A0 =C2=A0 =C2=A0 =C2=A0 | D= >ial-Up: US, PR, Canada
>Software Tool & Die=C2=A0 =C2=A0 | Public Access Internet=C2=A0 =C2=A0 = >=C2=A0| SINCE 1989=C2=A0 =C2=A0 =C2=A0*oo*
>

From baconzombie at gmail.com Wed Mar 11 03:16:18 2015 From: baconzombie at gmail.com (Bacon Zombie) Date: Wed, 11 Mar 2015 04:16:18 +0100 Subject: Purpose of spoofed packets ??? In-Reply-To: References: <851dacde19f14eeca82d0c9b6aff89c8@pur-vm-exch13n1.ox.com> Message-ID: Nmap has an option to "hide" your real IP among either a provides or IP list of IP addresses. " D *<**decoy1**>*[,*<**decoy2**>*][,ME][,...] (Cloak a scan with decoys) Causes a decoy scan to be performed, which makes it appear to the remote host that the host(s) you specify as decoys are scanning the target network too. Thus their IDS might report 5–10 port scans from unique IP addresses, but they won't know which IP was scanning them and which were innocent decoys. While this can be defeated through router path tracing, response-dropping, and other active mechanisms, it is generally an effective technique for hiding your IP address." http://nmap.org/book/man-bypass-firewalls-ids.html On 11 Mar 2015 02:17, "Steve Atkins" wrote: On Mar 10, 2015, at 4:40 PM, Matthew Huff wrote: > We recently got an abuse report of an IP address in our net range. However, that IP address isn't in use in our networks and the covering network is null routed, so no return traffic is possible. We have external BGP monitoring, so unless something very tricky is going on, we don't have part of our prefix hijacked. > > I assume the source address was spoofed, but this leads to my question. Since the person that submitted the report didn't mention a high packet rate (it was on ssh port 22), it doesn't look like some sort of SYN attack, but any OS fingerprinting or doorknob twisting wouldn't be useful from the attacker if the traffic doesn't return to them, so what gives? > > BTW, we are in the ARIN region, the report came out of the RIPE region. Either the reporter doesn't know what they're talking about (common enough) or someone is scanning for open ssh ports, hiding their real IP address by burying it in a host of faked source addresses. That's a standard option on some of the stealthier port scanners, IIRC. Cheers, Steve From rafael at gav.ufsc.br Wed Mar 11 03:36:17 2015 From: rafael at gav.ufsc.br (Rafael Possamai) Date: Tue, 10 Mar 2015 22:36:17 -0500 Subject: Spam coming from (possibly) GoDaddy servers - anyone on the list? Message-ID: Received some fake FedEx emails coming from "secureserver.net" servers that afaik belong to GoDaddy. I can give more details if someone speaks up. GMail anti-spam only picked up a few of these, others went straight through to inbox. Regards, Rafael From chenliu419 at gmail.com Wed Mar 11 04:31:40 2015 From: chenliu419 at gmail.com (Chen Liu) Date: Tue, 10 Mar 2015 21:31:40 -0700 Subject: [Deadline Extended] IEEE International Workshop on Manageability and Security of Network Function Virtualization and Software Defined Network (MASONS) Message-ID: --------------------------------------------------------------------------------------------------------------------------- Apologies for cross-postings! --------------------------------------------------------------------------------------------------------------------------- Call for Papers IEEE International Workshop on Manageability and Security of Network Function Virtualization and Software Defined Network (MASONS) With ICCCN 2015 at Las Vegas, Aug 3 – 6, 2015 http://www.icccn.org/icccn15/ MASONS 2015 is Technically Co-Sponsored by the IEEE Communication Society 1. Theme Today, many research organizations in academia, government labs and industry are exploring SDN and NFV technologies to study and materialize their benefits in real world networks. These benefits are enabling automation, reducing time to market in case of new service introductions, optimization and/or improving overall economics of network and system management and operations. However to materialize the benefits of SDN and NFV at larger scale across multiple domains, similar to today’s internet, additional investigations are needed which should focus beyond the core SDN, NFV features and functionalities. This involves: development of multi-domain SDN network to support Internet; large scale deployment of novel applications, identification of technological and operational gaps in research and development over the longer term to increase the capability of SDN and NFV powered networks, and better integrate them with existing public Internet and emerging cloud technologies; Identification of security, manageability gaps, including opportunities to build in additional levels of security, resilience and management capabilities. 2. Topics of interest This workshop aims to show case and disseminate new ideas and high quality research on manageability and security of Software Defined Network and Network Function Virtualization. We solicit original research articles, review papers, theoretical studies, and practical software systems incorporating new paradigms, experimental prototypes, and insightful requirement analysis with the above theme including, but not limited to the topics below: * Design, requirements and prototypes of Software Defined Exchanges (SDX) to enable interoperability and use of new approaches with the current Internet infrastructure. * Security, privacy, authentication, trust, verification for SDN and NFV. * Integration of compute, storage and network under the Software Defined Infrastructure (SDI) paradigm. * Analysis of new management challenges that SDN and NFV has introduced. * Network management practices and business processes for SDN and NFV, in service provider and data center infrastructures. * Tools and operational procedures for managing SDN. * New paradigms in network operations, administration and management (OAM), service orchestration, service engineering, converged network-compute and data center management. * Software Defined Network (SDN), abstraction, programmability, application Interface, south and northbound API. * Network Function Virtualization (NFV), distributed control, virtual switches, routing virtualization. * Network system management, orchestration, resource management and optimization, integration, interoperability. * Network operations management related automation, troubleshooting and management tools. * Cloud based network and system management application paradigms. * Application of artificial intelligence (AI), machine learning (ML), analytics and big data in network and system management. * Insights about Network Management System architectural requirements analysis. * Scalability of SDN, NFV, SDI, NMS systems. * User experience, user interface design issues and challenges in NMS for SDN, NFV, ethnographic studies on network operations centers, usability studies of management applications. 3. Speakers and Industry Panel * Morning keynote: Dr. Gee Rittenhouse, SVP, Cloud & Virtualization Group, Cisco System * Industry panel: Microsoft, IBM, Google, Cisco 4. Instructions for IEEE MASONS 2015 Workshop Authors: Submitted manuscripts must be formatted in standard IEEE camera ready format (double column, 10 pt font) and must be submitted via EasyChair ( http://www.easychair.org/) as PDF files (formatted for 8.5×11 inch paper). It should be no longer than 6 pages with up to two extra pages given the authors are willing to pay an over-length charge per extra page. The detailed information can be found in the ICCCN 2015 (Las Vegas) website. For any workshop related questions or additional information please contact the General, TPC, or Workshop Chairs. Submitted papers should not be previously published in or be under consideration for publication in another conference or journal. Paper titles and/or author names cannot be changed and/or added to the papers once papers are submitted to ICCCN 2015 for review. Submissions must include a title, abstract, keywords, author(s) and affiliation(s) with postal and email address(es) and phone number(s). A paper abstract must be registered on EasyChair by the deadline indicated below. 5. Important dates: * Abstract Due: Mar 21, 2015 * Paper Due: Mar 21, 2015 * Acceptance Notification: Apr 13, 2015 * Camera Ready Due: May 8, 2015 6. Review and Publication of Manuscripts: Submitted papers will be reviewed by the ICCCN 2015 TPC members and judged on originality, technical correctness, relevance, and quality of presentation. An accepted paper must be presented at the conference venue by one (who registered/paid full author reg. fee) of authors to be included in the conference venue. Each full registration covers up to two ICCCN 2015 conference papers authored by the registered/paid author. Accepted and presented papers will be published in the conference proceedings and submitted to IEEE Xplore as well as other Abstracting and Indexing (A&I) databases. The page limit for papers is 6 pages. Papers should be submitted on EDAS, the link for this workshop will be published here shortly. Papers of special merit will be selected for possible fast track at a journal special issue at IJCNDS (see details at http://www.inderscience.com/info/ingeneral/cfplist.php?jcode=ijcnds and http://www.manageability-at-scale.org/cfp/). 7. Workshop chairs * Inder Monga, ESnet and LBNL, USA, imonga at es.net * Amitava Biswas, Cisco Systems, USA, amitavabiswas at ieee.org * Chen Liu, Microsoft, USA, chenliu419 at gmail.com From baldur.norddahl at gmail.com Wed Mar 11 10:02:11 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Wed, 11 Mar 2015 11:02:11 +0100 Subject: Phone adapter with router In-Reply-To: References: <009401d05abd$ca4b5dc0$5ee21940$@ca> Message-ID: It should be possible to do the emergency call without a SIM. That way you got 112 / 911 calls covered... Den 10/03/2015 21.05 skrev "Brandon Galbraith" : > Quick hijack: Can anyone recommend a device that will terminate to a > phone, supports SIP, *and* can fallback to SIM for emergency calls? > > On Tue, Mar 10, 2015 at 8:44 AM, Pedersen, Sean wrote: > > +1 > > > > Used them in a past life as a SIP ALG and NAT router for a “bring your > own broadband” hosted SIP service. Worked well enough. > > > > You might get more suggestions if you provide a little bit more about > what your requirements are, how they’re being deployed (one-off, ISP, > etc.), or what the others didn’t do well. > > > > > > > > On 3/9/15, 11:16 PM, "Joe Hamelin" wrote: > > > >>I've run into a few of these and they seem to do a good job. > >> > >> > ftp://ftp.edgewaternetworks.com/pub/docs/CD_contents/DOCS/EdgeMarc/200/200%20Series%20Datasheet.pdf > >> > >>-- > >>Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > >> > >>On Mon, Mar 9, 2015 at 4:07 PM, A MEKKAOUI wrote: > >> > >>> Hi > >>> > >>> > >>> > >>> Do you know any good router with phone adapters to provide home phone > and > >>> internet? We tried couple of them like Linksys, Thomson, etc. and no > one > >>> does the job perfectly. Any comment will be appreciated. > >>> > >>> > >>> > >>> Thank you > >>> > >>> > >>> > >>> Karim > >>> > >>> > >>> > >>> > > > > > > Founded in 2007, IO provides the data center as a service to businesses > and governments around the world. > > > > The communication contained in this e-mail is confidential and is > intended only for the named recipient(s) and may contain information that > is privileged, proprietary, attorney work product or exempt from disclosure > under applicable law. If you have received this message in error, or are > not the named recipient(s), please note that any form of distribution, > copying or use of this communication or the information in it is strictly > prohibited and may be unlawful. Please immediately notify the sender of the > error, and delete this communication including any attached files from your > system. Thank you for your cooperation. > From nick at foobar.org Wed Mar 11 10:45:03 2015 From: nick at foobar.org (Nick Hilliard) Date: Wed, 11 Mar 2015 10:45:03 +0000 Subject: Phone adapter with router In-Reply-To: References: <009401d05abd$ca4b5dc0$5ee21940$@ca> Message-ID: <55001CAF.7080608@foobar.org> On 11/03/2015 10:02, Baldur Norddahl wrote: > It should be possible to do the emergency call without a SIM. That way you > got 112 / 911 calls covered... emergency calls without sim are part of the gsm standard. So unless the OP's provider is doing something terribly wrong and probably illegal, you can make a 112 call on any mobile device anywhere in the world within range of a compatible radio signal. Nick From aledm at qix.co.uk Wed Mar 11 11:04:19 2015 From: aledm at qix.co.uk (Aled Morris) Date: Wed, 11 Mar 2015 11:04:19 +0000 Subject: Phone adapter with router In-Reply-To: <55001CAF.7080608@foobar.org> References: <009401d05abd$ca4b5dc0$5ee21940$@ca> <55001CAF.7080608@foobar.org> Message-ID: On 11 March 2015 at 10:45, Nick Hilliard wrote: > On 11/03/2015 10:02, Baldur Norddahl wrote: > > It should be possible to do the emergency call without a SIM. That way > you > > got 112 / 911 calls covered... > > emergency calls without sim are part of the gsm standard. So unless the > OP's provider is doing something terribly wrong and probably illegal, you > can make a 112 call on any mobile device anywhere in the world within range > of a compatible radio signal. > > Can't find a definitive reference but this concurs with my recollection of a policy introduced in 2009: http://www.redcross.org.uk/en/What-we-do/Teaching-resources/Quick-activities/999 Some people think that 999 calls can be made from a phone without a SIM. In fact, because of the high number of hoax calls, the United Kingdom decided to block emergency calls from mobile phones without a SIM card. Aled From aledm at qix.co.uk Wed Mar 11 11:07:51 2015 From: aledm at qix.co.uk (Aled Morris) Date: Wed, 11 Mar 2015 11:07:51 +0000 Subject: Phone adapter with router In-Reply-To: References: <009401d05abd$ca4b5dc0$5ee21940$@ca> <55001CAF.7080608@foobar.org> Message-ID: On 11 March 2015 at 11:04, Aled Morris wrote: > Can't find a definitive reference but this concurs with my recollection of > a policy introduced in 2009: > Better reference: http://ec.europa.eu/information_society/newsroom/cf/document.cfm?doc_id=1674 1.3. Availability of 112 from mobile handsets without SIM cards By way of complementary information, the countries were invited to indicate whether SIM-less 112 calls were allowed. Out of the 31 countries that provided this information, SIM-less 112 calls were reported possible in 19 Member States, Norway and Iceland. The remaining eight Member States that do not provide this facility are Bulgaria, Germany (in both these countries the facility was removed in 2009), the Netherlands (removing the facility in 2011) Belgium, France, Romania, Slovenia, and the United Kingdom. Several Member States chose to remove this facility because of the high proportion of hoax calls originating from SIM less phones. Aled From mhuff at ox.com Wed Mar 11 12:07:46 2015 From: mhuff at ox.com (Matthew Huff) Date: Wed, 11 Mar 2015 12:07:46 +0000 Subject: Purpose of spoofed packets ??? In-Reply-To: References: <851dacde19f14eeca82d0c9b6aff89c8@pur-vm-exch13n1.ox.com> Message-ID: >Nmap has an option to "hide" your real IP among either a provides or IP >list of IP addresses. > >" D *<**decoy1**>*[,*<**decoy2**>*][,ME][,...] (Cloak a scan with decoys) > >Causes a decoy scan to be performed, which makes it appear to the remote >host that the host(s) you specify as decoys are scanning the target >network >too. Thus their IDS might report 5­10 port scans from unique IP addresses, >but they won't know which IP was scanning them and which were innocent >decoys. While this can be defeated through router path tracing, >response-dropping, and other active mechanisms, it is generally an >effective technique for hiding your IP address." > >http://nmap.org/book/man-bypass-firewalls-ids.html >On 11 Mar 2015 02:17, "Steve Atkins" wrote: Thanks. I thought it was something obvious that I was missing. This makes sense. From Patrick.Darden at p66.com Wed Mar 11 15:27:45 2015 From: Patrick.Darden at p66.com (Darden, Patrick) Date: Wed, 11 Mar 2015 15:27:45 +0000 Subject: Purpose of spoofed packets ??? In-Reply-To: <851dacde19f14eeca82d0c9b6aff89c8@pur-vm-exch13n1.ox.com> References: <851dacde19f14eeca82d0c9b6aff89c8@pur-vm-exch13n1.ox.com> Message-ID: One more outré purpose for spoofing SIPs is to have you blacklist/nullroute someone, effectively enlisting you to cause a DOS. --p -----Original Message----- From: NANOG [mailto:nanog-bounces+patrick.darden=p66.com at nanog.org] On Behalf Of Matthew Huff Sent: Tuesday, March 10, 2015 6:41 PM To: nanog at nanog.org Subject: [EXTERNAL]Purpose of spoofed packets ??? We recently got an abuse report of an IP address in our net range. However, that IP address isn't in use in our networks and the covering network is null routed, so no return traffic is possible. We have external BGP monitoring, so unless something very tricky is going on, we don't have part of our prefix hijacked. I assume the source address was spoofed, but this leads to my question. Since the person that submitted the report didn't mention a high packet rate (it was on ssh port 22), it doesn't look like some sort of SYN attack, but any OS fingerprinting or doorknob twisting wouldn't be useful from the attacker if the traffic doesn't return to them, so what gives? BTW, we are in the ARIN region, the report came out of the RIPE region. ---- Matthew Huff             | 1 Manhattanville Rd Director of Operations   | Purchase, NY 10577 OTA Management LLC       | Phone: 914-460-4039 aim: matthewbhuff        | Fax:   914-694-5669 From motamedi at cs.uoregon.edu Wed Mar 11 18:32:33 2015 From: motamedi at cs.uoregon.edu (Reza Motamedi) Date: Wed, 11 Mar 2015 14:32:33 -0400 Subject: distinguishing eBGP from show ip BGP Message-ID: Hi Nanog, For a research I want to distinguish the external AS peering from "show ip BGP". In other words I want to see which entry show a path that immediately sends packets to another AS. My understanding is that *status code* shows if the route is internal, right? Does this mean if the *'i' *is not present, the route is goes out of the AS in the next hop. On the same note, can I use "Next Hop" to identify such entries? I just included a sample report from a public looking glass in XO. show ip bgp 207.108.0.0/15 longer-prefixes BGP table version is 529230540, local router ID is 65.106.7.145 * * *Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter, a additional-path Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 207.108.0.0/15 216.156.2.164 3 0 2828 209 i * 65.106.7.101 2 0 2828 209 i * 65.106.7.246 3 0 2828 209 i * 65.106.7.55 3 0 2828 209 i *> 216.156.2.162 2 0 2828 209 i * 65.106.7.54 3 0 2828 209 i * 65.106.7.252 2 0 2828 209 i * 216.156.2.160 2 0 2828 209 i * 65.106.7.56 3 0 2828 209 i * 216.156.2.165 2 0 2828 209 i * 65.106.7.144 2 0 2828 209 i Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon From mark.tinka at seacom.mu Wed Mar 11 18:51:13 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 11 Mar 2015 20:51:13 +0200 Subject: distinguishing eBGP from show ip BGP In-Reply-To: References: Message-ID: <55008EA1.4040102@seacom.mu> On 11/Mar/15 20:32, Reza Motamedi wrote: > Hi Nanog, > > For a research I want to distinguish the external AS peering from "show ip > BGP". In other words I want to see which entry show a path that immediately > sends packets to another AS. My understanding is that *status code* shows > if the route is internal, right? Does this mean if the *'i' *is not > present, the route is goes out of the AS in the next hop. On the same note, > can I use "Next Hop" to identify such entries? > > I just included a sample report from a public looking glass in XO. > > > show ip bgp 207.108.0.0/15 longer-prefixes > BGP table version is 529230540, local router ID is 65.106.7.145 > * * *Status codes: s suppressed, d damped, h history, * valid, > best, i - > internal, > r RIB-failure, S Stale, m multipath, b backup-path, x > best-external, f RT-Filter, a additional-path > Origin codes: i - IGP, e - EGP, ? - incomplete > > Network Next Hop Metric LocPrf Weight Path > * 207.108.0.0/15 216.156.2.164 3 0 2828 209 i > * 65.106.7.101 2 0 2828 209 i > * 65.106.7.246 3 0 2828 209 i > * 65.106.7.55 3 0 2828 209 i > *> 216.156.2.162 2 0 2828 209 i > * 65.106.7.54 3 0 2828 209 i > * 65.106.7.252 2 0 2828 209 i > * 216.156.2.160 2 0 2828 209 i > * 65.106.7.56 3 0 2828 209 i > * 216.156.2.165 2 0 2828 209 i > * 65.106.7.144 2 0 2828 209 i There are two uses of the "i" code in IOS: 1. "i" for Status codes refers to the route being learned via iBGP. 2. "i" for Origin codes refers to the route being learned via a locally-generated route at the origin (or more historically, the IGP). In IOS "show ip bgp" output, the "i" for Status code (iBGP) is to the left of the prefix. On the other hand, the "i" for Origin code (IGP-originated route) is to the right of the originating AS in the AS_PATH. So you need to be more interested in the "i" to the left of the prefix. In your output above, no such "i" exists; ergo, these are eBGP-learned routes from this router's point of view. Use of the NEXT_HOP attribute to identify whether a route is eBGP-learned is not reliable, especially if you do not own the network you're getting your data from. Mark. From jared at puck.Nether.net Wed Mar 11 18:51:32 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Wed, 11 Mar 2015 14:51:32 -0400 Subject: distinguishing eBGP from show ip BGP In-Reply-To: References: Message-ID: <20150311185132.GD18808@puck.nether.net> On Wed, Mar 11, 2015 at 02:32:33PM -0400, Reza Motamedi wrote: > Hi Nanog, > > For a research I want to distinguish the external AS peering from "show ip > BGP". In other words I want to see which entry show a path that immediately > sends packets to another AS. My understanding is that *status code* shows > if the route is internal, right? Does this mean if the *'i' *is not > present, the route is goes out of the AS in the next hop. On the same note, > can I use "Next Hop" to identify such entries? I would take a different route to diagnose the relationship between networks. I would look at the route-views or RIS datasets and parse the MRT data taking a close look at the communties that are tagged on the routes. NTT (2914) tags routes based on if they are a customer, peer and with geographic communities based on where the route enters our network. Many networks perform similar techniques and you can find details at various websites or this one: http://www.onesc.net/communities/ You will likely get far more accurate data. You can also attempt to validate these relationships leveraging the RIPE ATLAS project. You can then perform tests and validate them via traceroutes performed by this global network of probes. You can also look at the NLNOG-RING project as another location to perform these tests from. aside: if you want RIPE Atlas credits, let me know, my cup overflows with credits. > I just included a sample report from a public looking glass in XO. > > show ip bgp 207.108.0.0/15 longer-prefixes > BGP table version is 529230540, local router ID is 65.106.7.145 > * * *Status codes: s suppressed, d damped, h history, * valid, > best, i - > internal, > r RIB-failure, S Stale, m multipath, b backup-path, x > best-external, f RT-Filter, a additional-path > Origin codes: i - IGP, e - EGP, ? - incomplete > > Network Next Hop Metric LocPrf Weight Path > * 207.108.0.0/15 216.156.2.164 3 0 2828 209 i > * 65.106.7.101 2 0 2828 209 i > * 65.106.7.246 3 0 2828 209 i > * 65.106.7.55 3 0 2828 209 i > *> 216.156.2.162 2 0 2828 209 i > * 65.106.7.54 3 0 2828 209 i > * 65.106.7.252 2 0 2828 209 i > * 216.156.2.160 2 0 2828 209 i > * 65.106.7.56 3 0 2828 209 i > * 216.156.2.165 2 0 2828 209 i > * 65.106.7.144 2 0 2828 209 i these next-hops can tell you information about the internal of a network, how they are configured, eg: with route-reflectors, next-hop-self or other policies internally. The i at the end is an "origin" code, which is used as a tie-breaker for the BGP decision process. This can be influenced by people to set it to internal, external or unknown to cause shifts in traffic. internal tagged routes will have a higher preference when reaching a network, so there are some networks that may reset the origin to influence the policy of a 3rd party network. - 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 mark.tinka at seacom.mu Wed Mar 11 18:59:39 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 11 Mar 2015 20:59:39 +0200 Subject: distinguishing eBGP from show ip BGP In-Reply-To: <20150311185132.GD18808@puck.nether.net> References: <20150311185132.GD18808@puck.nether.net> Message-ID: <5500909B.6040403@seacom.mu> On 11/Mar/15 20:51, Jared Mauch wrote: > > NTT (2914) tags routes based on if they are a customer, peer > and with geographic communities based on where the route enters our > network. Many networks perform similar techniques and you can find > details at various websites or this one: > > http://www.onesc.net/communities/ > > You will likely get far more accurate data. The trick with relying on BGP communities to map routing data is that their propagation between AS's is not always guaranteed. Mark. From jared at puck.nether.net Wed Mar 11 19:18:23 2015 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 11 Mar 2015 15:18:23 -0400 Subject: distinguishing eBGP from show ip BGP In-Reply-To: <5500909B.6040403@seacom.mu> References: <20150311185132.GD18808@puck.nether.net> <5500909B.6040403@seacom.mu> Message-ID: > On Mar 11, 2015, at 2:59 PM, Mark Tinka wrote: > > > > On 11/Mar/15 20:51, Jared Mauch wrote: >> >> NTT (2914) tags routes based on if they are a customer, peer >> and with geographic communities based on where the route enters our >> network. Many networks perform similar techniques and you can find >> details at various websites or this one: >> >> http://www.onesc.net/communities/ >> >> You will likely get far more accurate data. > > The trick with relying on BGP communities to map routing data is that their propagation between AS's is not always guaranteed. True, they also can get marked, remarked, or dropped at various network edges. This is why I was suggesting taking the data directly from the MRT files at route-views. I’ve been using this for the routing leak detector just processing the updates over the years and it’s way easier to process a smaller update file than diff the entire RIB dump. (at least for that use-case). Many people who do BGP don’t do a good job with their policy which is how you end up with these full table leaks and seemingly random routes appear that hairpin through networks. eg: 59.188.253.0/24 2497 701 6453 45474 174 17444 It’s unlikely that 6453 or 701 should really be using 45474 to reach 174 or their customer 17444. This has a lot to do with IOS devices which by default send all routes to all configured peers. Cisco does a particularly poor job of educating it’s CCIE and other graduates of this fact. IOS-XR can be made to do the same thing, but requires explicitly enabling this problematic behavior. Similarly send-community on IOS requires beyond the basic “neighbor 1.2.3.4 remote-as 5” type config. - Jared From motamedi at cs.uoregon.edu Wed Mar 11 19:22:46 2015 From: motamedi at cs.uoregon.edu (Reza Motamedi) Date: Wed, 11 Mar 2015 19:22:46 +0000 Subject: distinguishing eBGP from show ip BGP References: <55008EA1.4040102@seacom.mu> Message-ID: Thanks Mark for the reply. Let me try to check what I understood is correct. Does the 'i' on the left (status code) only shows whether the prefix belongs to this AS? What I want to figure out is if this two ASes (the owner of the router and and the first one on the AS-PATH) connect at the location of the router, or if packets need to stay for some hops in the local AS. On Wed, Mar 11, 2015, 2:51 PM Mark Tinka wrote: > > > On 11/Mar/15 20:32, Reza Motamedi wrote: > > Hi Nanog, > > > > For a research I want to distinguish the external AS peering from "show > ip > > BGP". In other words I want to see which entry show a path that > immediately > > sends packets to another AS. My understanding is that *status code* shows > > if the route is internal, right? Does this mean if the *'i' *is not > > present, the route is goes out of the AS in the next hop. On the same > note, > > can I use "Next Hop" to identify such entries? > > > > I just included a sample report from a public looking glass in XO. > > > > > > show ip bgp 207.108.0.0/15 longer-prefixes > > BGP table version is 529230540, local router ID is 65.106.7.145 > > * * *Status codes: s suppressed, d damped, h history, * valid, > best, > i - > > internal, > > r RIB-failure, S Stale, m multipath, b backup-path, x > > best-external, f RT-Filter, a additional-path > > Origin codes: i - IGP, e - EGP, ? - incomplete > > > > Network Next Hop Metric LocPrf Weight Path > > * 207.108.0.0/15 216.156.2.164 3 0 2828 209 > i > > * 65.106.7.101 2 0 2828 209 i > > * 65.106.7.246 3 0 2828 209 i > > * 65.106.7.55 3 0 2828 209 i > > *> 216.156.2.162 2 0 2828 209 i > > * 65.106.7.54 3 0 2828 209 i > > * 65.106.7.252 2 0 2828 209 i > > * 216.156.2.160 2 0 2828 209 i > > * 65.106.7.56 3 0 2828 209 i > > * 216.156.2.165 2 0 2828 209 i > > * 65.106.7.144 2 0 2828 209 i > > There are two uses of the "i" code in IOS: > > 1. "i" for Status codes refers to the route being learned via iBGP. > 2. "i" for Origin codes refers to the route being learned via a > locally-generated route at the origin (or more historically, the IGP). > > In IOS "show ip bgp" output, the "i" for Status code (iBGP) is to the > left of the prefix. On the other hand, the "i" for Origin code > (IGP-originated route) is to the right of the originating AS in the > AS_PATH. > > So you need to be more interested in the "i" to the left of the prefix. > In your output above, no such "i" exists; ergo, these are eBGP-learned > routes from this router's point of view. > > Use of the NEXT_HOP attribute to identify whether a route is > eBGP-learned is not reliable, especially if you do not own the network > you're getting your data from. > > Mark. > > From mark.tinka at seacom.mu Wed Mar 11 19:30:46 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 11 Mar 2015 21:30:46 +0200 Subject: distinguishing eBGP from show ip BGP In-Reply-To: References: <55008EA1.4040102@seacom.mu> Message-ID: <550097E6.7030102@seacom.mu> On 11/Mar/15 21:22, Reza Motamedi wrote: > > Thanks Mark for the reply. Let me try to check what I understood is > correct. Does the 'i' on the left (status code) only shows whether the > prefix belongs to this AS? > Status-code "i" just means the entry was learned by "this" router via iBGP. It does not mean the entry belongs to "this AS". A locally-generated route can be thought of as "belonging to this AS", however, a router cannot assert that a locally-generated route "belongs to this AS". It just asserts that the route was locally-generated within the AS. Ownership of the route is data that needs to be gleaned from other sources, e.g., RIR WHOIS data, speaking to the operator, e.t.c. Whatever the case, a locally-generated route would not have an AS_PATH. That is an easy way to tell for such a use-case. > What I want to figure out is if this two ASes (the owner of the router > and and the first one on the AS-PATH) connect at the location of the > router, or if packets need to stay for some hops in the local AS. > So you want to determine whether traffic is hot- or cold-potato forwarding from the point of view of your reference router? Mark. From mark.tinka at seacom.mu Wed Mar 11 19:32:06 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 11 Mar 2015 21:32:06 +0200 Subject: distinguishing eBGP from show ip BGP In-Reply-To: References: <20150311185132.GD18808@puck.nether.net> <5500909B.6040403@seacom.mu> Message-ID: <55009836.9070102@seacom.mu> On 11/Mar/15 21:18, Jared Mauch wrote: > > Similarly send-community on IOS requires beyond the basic “neighbor 1.2.3.4 remote-as 5” type config. One has the same issue in IOS XR, where BGP communities are only signaled by default for iBGP neighbors. One needs to enable signaling of communities to eBGP neighbors. Junos does the right thing :-). Mark. From motamedi at cs.uoregon.edu Wed Mar 11 19:42:06 2015 From: motamedi at cs.uoregon.edu (Reza Motamedi) Date: Wed, 11 Mar 2015 15:42:06 -0400 Subject: distinguishing eBGP from show ip BGP In-Reply-To: <550097E6.7030102@seacom.mu> References: <55008EA1.4040102@seacom.mu> <550097E6.7030102@seacom.mu> Message-ID: What I ultimately want to determine, is the location of the AS connection. I know for example the router is in, say LA. If hot potato lets me to send the packet to the neighbor AS then they have an AS connection in LA, right? Going back to my example does the fact that the entry does not have 'i' mean that I can send it to AS2828 on the next hop. Network Next Hop Metric LocPrf Weight Path * 207.108.0.0/15 216.156.2.164 3 0 2828 209 i * 65.106.7.101 2 0 2828 209 i * 65.106.7.246 3 0 2828 209 i * 65.106.7.55 3 0 2828 209 i *> 216.156.2.162 2 0 2828 209 i Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon On Wed, Mar 11, 2015 at 3:30 PM, Mark Tinka wrote: > > > On 11/Mar/15 21:22, Reza Motamedi wrote: > > Thanks Mark for the reply. Let me try to check what I understood is > correct. Does the 'i' on the left (status code) only shows whether the > prefix belongs to this AS? > > > Status-code "i" just means the entry was learned by "this" router via > iBGP. It does not mean the entry belongs to "this AS". > > A locally-generated route can be thought of as "belonging to this AS", > however, a router cannot assert that a locally-generated route "belongs to > this AS". It just asserts that the route was locally-generated within the > AS. Ownership of the route is data that needs to be gleaned from other > sources, e.g., RIR WHOIS data, speaking to the operator, e.t.c. > > Whatever the case, a locally-generated route would not have an AS_PATH. > That is an easy way to tell for such a use-case. > > What I want to figure out is if this two ASes (the owner of the router > and and the first one on the AS-PATH) connect at the location of the > router, or if packets need to stay for some hops in the local AS. > > > So you want to determine whether traffic is hot- or cold-potato forwarding > from the point of view of your reference router? > > Mark. > From mark.tinka at seacom.mu Wed Mar 11 19:50:04 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 11 Mar 2015 21:50:04 +0200 Subject: distinguishing eBGP from show ip BGP In-Reply-To: References: <55008EA1.4040102@seacom.mu> <550097E6.7030102@seacom.mu> Message-ID: <55009C6C.20408@seacom.mu> On 11/Mar/15 21:42, Reza Motamedi wrote: > What I ultimately want to determine, is the location of the AS > connection. I know for example the router is in, say LA. If hot potato > lets me to send the packet to the neighbor AS then they have an AS > connection in LA, right? > > Going back to my example does the fact that the entry does not have > 'i' mean that I can send it to AS2828 on the next hop. Yes - the route was not learned via iBGP; which means it was learned via eBGP. But that is just routing. It does not necessarily paint the forwarding topology (remember, routing and forwarding are two different operations). The next-hop may be local to "this router", but it could also be a tunnel (which may be cold-potato forwarded before exiting the local AS), or the eBGP session could be eBGP Multi-Hop. Mark. From motamedi at cs.uoregon.edu Wed Mar 11 20:27:22 2015 From: motamedi at cs.uoregon.edu (Reza Motamedi) Date: Wed, 11 Mar 2015 16:27:22 -0400 Subject: distinguishing eBGP from show ip BGP In-Reply-To: <55009C6C.20408@seacom.mu> References: <55008EA1.4040102@seacom.mu> <550097E6.7030102@seacom.mu> <55009C6C.20408@seacom.mu> Message-ID: Thanks again, Mark. So I guess the short answer is that I can't infer anything about the location of physical connectivity having this level of information from the control plane. Is that a fair statement? What if the "Next Hop" is inside the neighbor AS. I know it is a rather odd and uncommon case, but can it help? Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon On Wed, Mar 11, 2015 at 3:50 PM, Mark Tinka wrote: > > > On 11/Mar/15 21:42, Reza Motamedi wrote: > > What I ultimately want to determine, is the location of the AS connection. > I know for example the router is in, say LA. If hot potato lets me to send > the packet to the neighbor AS then they have an AS connection in LA, right? > > Going back to my example does the fact that the entry does not have 'i' > mean that I can send it to AS2828 on the next hop. > > > Yes - the route was not learned via iBGP; which means it was learned via > eBGP. > > But that is just routing. It does not necessarily paint the forwarding > topology (remember, routing and forwarding are two different operations). > > The next-hop may be local to "this router", but it could also be a tunnel > (which may be cold-potato forwarded before exiting the local AS), or the > eBGP session could be eBGP Multi-Hop. > > Mark. > From mark.tinka at seacom.mu Wed Mar 11 20:36:35 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 11 Mar 2015 22:36:35 +0200 Subject: distinguishing eBGP from show ip BGP In-Reply-To: References: <55008EA1.4040102@seacom.mu> <550097E6.7030102@seacom.mu> <55009C6C.20408@seacom.mu> Message-ID: <5500A753.8000506@seacom.mu> On 11/Mar/15 22:27, Reza Motamedi wrote: > Thanks again, Mark. > > So I guess the short answer is that I can't infer anything about the > location of physical connectivity having this level of information > from the control plane. Not reliably as far as I can tell, no. Someone else can chime in here if they have another perspective. One could rely on traceroutes, but that is crude and sometimes unavailable if you're looking to gather any meaningful data (even though it might be the closest piece of information you'll get without engaging with the network operator). > What if the "Next Hop" is inside the neighbor AS. I know it is a > rather odd and uncommon case, but can it help? Control-plane-wise, that could be eBGP Multi-Hop. Forwarding-plane-wise, that is likely a tunnel operation. Technically, one can build such a topology. I'd hazard that at least someone is doing this out there somewhere. However, it's not typical by any means. Mark. From chris.dye at paragon.net Wed Mar 11 21:56:20 2015 From: chris.dye at paragon.net (Christopher Dye) Date: Wed, 11 Mar 2015 21:56:20 +0000 Subject: NDS Resolution Problems between Charter Communications and OpenDNS In-Reply-To: <00b101d05a8f$9831d450$c8957cf0$@gmail.com> References: , <00b101d05a8f$9831d450$c8957cf0$@gmail.com> Message-ID: <1426110980983.43415@paragon.net> Yea, sorry. DNS -- I was hammering that out before running out the door. DNS is the issue -- as far as I know, it's still an issue. ________________________________________ From: NANOG on behalf of Chuck Church Sent: Monday, March 9, 2015 12:36 PM To: nanog at nanog.org Subject: RE: NDS Resolution Problems between Charter Communications and OpenDNS NDS? My first suggestion would be run DSREPAIR. Wow, that brings back memories. But since you probably mean DNS, I'll stop right there. Chuck -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher Dye Sent: Monday, March 09, 2015 1:20 PM To: nanog at nanog.org Subject: NDS Resolution Problems between Charter Communications and OpenDNS If anyone from Charter Communications NetOps or OpenDNS NetOps is monitoring, could you please contact me off-list? It would seem AS36692 (OpenDNS) and AS23028 (Charter Communications) are having some issues playing together. Thanks Much, Chris Dye Chief Technical Officer Paragon Solutions Group, Inc. From andree+nanog at toonk.nl Thu Mar 12 05:21:51 2015 From: andree+nanog at toonk.nl (Andree Toonk) Date: Wed, 11 Mar 2015 22:21:51 -0700 Subject: NDS Resolution Problems between Charter Communications and OpenDNS In-Reply-To: <1426110980983.43415@paragon.net> References: , <00b101d05a8f$9831d450$c8957cf0$@gmail.com> <1426110980983.43415@paragon.net> Message-ID: <5501226F.7010705@toonk.nl> Hi Christopher, feel free to contact me with more details via andree opendns com Cheers Andree .-- My secret spy satellite informs me that at 2015-03-11 2:56 PM Christopher Dye wrote: > Yea, sorry. DNS -- I was hammering that out before running out the door. DNS is the issue -- as far as I know, it's still an issue. > ________________________________________ > From: NANOG on behalf of Chuck Church > Sent: Monday, March 9, 2015 12:36 PM > To: nanog at nanog.org > Subject: RE: NDS Resolution Problems between Charter Communications and OpenDNS > > NDS? My first suggestion would be run DSREPAIR. Wow, that brings back > memories. But since you probably mean DNS, I'll stop right there. > > Chuck > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher Dye > Sent: Monday, March 09, 2015 1:20 PM > To: nanog at nanog.org > Subject: NDS Resolution Problems between Charter Communications and OpenDNS > > If anyone from Charter Communications NetOps or OpenDNS NetOps is > monitoring, could you please contact me off-list? It would seem AS36692 > (OpenDNS) and AS23028 (Charter Communications) are having some issues > playing together. > > > > Thanks Much, > > Chris Dye > > Chief Technical Officer > > Paragon Solutions Group, Inc. > > > From cb.list6 at gmail.com Thu Mar 12 14:58:43 2015 From: cb.list6 at gmail.com (Ca By) Date: Thu, 12 Mar 2015 07:58:43 -0700 Subject: FCC releases Open Internet document Message-ID: For the first time to the public http://transition.fcc.gov/Daily_Releases/Daily_Business/2015/db0312/FCC-15-24A1.pdf Enjoy. From ag4ve.us at gmail.com Thu Mar 12 15:32:54 2015 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 12 Mar 2015 11:32:54 -0400 Subject: FCC releases Open Internet document In-Reply-To: References: Message-ID: On Mar 12, 2015 11:01 AM, "Ca By" wrote: > > For the first time to the public > http://transition.fcc.gov/Daily_Releases/Daily_Business/2015/db0312/FCC-15-24A1.pdf > > Enjoy. Uh yeah, I'll wait for the reviews when y'all get done trudging through that... From lowen at pari.edu Thu Mar 12 15:48:53 2015 From: lowen at pari.edu (Lamar Owen) Date: Thu, 12 Mar 2015 11:48:53 -0400 Subject: FCC releases Open Internet document In-Reply-To: References: Message-ID: <5501B565.8050008@pari.edu> On 03/12/2015 10:58 AM, Ca By wrote: > For the first time to the public > http://transition.fcc.gov/Daily_Releases/Daily_Business/2015/db0312/FCC-15-24A1.pdf > The actual final rules are in Appendix A, pages 283 through 290 (8 pages), although that's a bit misleading, as the existing Part 8 is not included in full in that Appendix. There are also three amendments to Part 20, as well, in the Definitions, which means other paragraphs of Part 20 may apply. It's interesting that pages 321 through 400 (80 pages) are taken up entirely by the dissenting Commissioner's statements, and Tom Wheeler's statement begins on page 314. This will indeed be an interesting read. From contact at nullivex.com Thu Mar 12 16:13:56 2015 From: contact at nullivex.com (Bryan Tong) Date: Thu, 12 Mar 2015 10:13:56 -0600 Subject: FCC releases Open Internet document In-Reply-To: <5501B565.8050008@pari.edu> References: <5501B565.8050008@pari.edu> Message-ID: I read through the introduction. This document seems like a good thing for everyone. If someone finds something opposing to that I would be interested to know. I definitely didnt make it through the whole thing either :) On Thu, Mar 12, 2015 at 9:48 AM, Lamar Owen wrote: > On 03/12/2015 10:58 AM, Ca By wrote: > >> For the first time to the public >> http://transition.fcc.gov/Daily_Releases/Daily_Business/ >> 2015/db0312/FCC-15-24A1.pdf >> >> > The actual final rules are in Appendix A, pages 283 through 290 (8 pages), > although that's a bit misleading, as the existing Part 8 is not included in > full in that Appendix. There are also three amendments to Part 20, as > well, in the Definitions, which means other paragraphs of Part 20 may apply. > > It's interesting that pages 321 through 400 (80 pages) are taken up > entirely by the dissenting Commissioner's statements, and Tom Wheeler's > statement begins on page 314. > > This will indeed be an interesting read. > > -- eSited LLC (701) 390-9638 From lowen at pari.edu Thu Mar 12 17:28:36 2015 From: lowen at pari.edu (Lamar Owen) Date: Thu, 12 Mar 2015 13:28:36 -0400 Subject: FCC releases Open Internet document In-Reply-To: References: Message-ID: <5501CCC4.908@pari.edu> On 03/12/2015 12:13 PM, Bryan Tong wrote: > I read through the introduction. This document seems like a good thing > for everyone. > > I'm about 50 pages in, reading a little bit at a time. Paragraph 31 is one that anyone who does peering or exchanges should read and understand. I take it to mean something like 'Guys who abuse peering and engage in peering disputes, take note of what we just did to the last mile people; you have been warned.' But, having read Commission R&O's before on the broadcast (Media Bureau) side of the house for years, maybe I'm a bit cynical. Paragraphs 37 through 40, including footnotes, appear tailored as a reply to Verizon's creative Morse reply. It's impossible to know which was first, but it is an interesting thought. The 'Verizon Court' is mentioned numerous times. Paragraph43 and footnote 40 mention the 'Brand X' decision of the Supreme Court, mentioning that that decision left open the reclassification avenue. This could cause any legislation that attempted to thwart this R&O to eventually be ruled unconstitutional, citing Brand X. Prior to reading this R&O I wasn't familiar with this decision, so I've already learned something new.....and I think the reference in paragraph 43, footnote 41, is rather interesting as well. And Justice Scalia's pizza delivery analogy makes a humorous (in the political context!) appearance. Delightful. Paragraphs 60 through 74 give a concise history of the action, and are a great read. And it also shows me that I should have paid a bit closer attention to the Part 8 I read a few days back; that's the part 8 from the R&O of 2010; the part 8 as of today in the eCFR has not been updated with the new sections, including 8.18. So the rules as set into place by this R&O were not public earlier; I stand corrected. Paragraphs 78 through 85 and associated footnotes (I found footnote 131 particularly relevant) state in a nutshell why the FCC thought that this action had to be taken. And I am just in awe of the first sentence of paragraph 92. And paragraph 99 is spot-on on wireless carrier switching costs. One of the more interesting side effects of this is that it would appear that a mass-market BIAS (the FCC's term, not mine, for Broadband Internet Access Service) provider cannot block outbound port 25 (R&O paragraph 105 and footnote 241 in particular). Well, it does depend upon what Paragraph 113 means about a device that 'does not harm the network.' Whether you agree with the R&O or not, I believe that you will find it a very readable document. Some will no doubt strongly disagree. From Jason_Livingood at cable.comcast.com Thu Mar 12 17:28:39 2015 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 12 Mar 2015 17:28:39 +0000 Subject: FCC releases Open Internet document In-Reply-To: References: <5501B565.8050008@pari.edu> Message-ID: Note: IANAL and this is my *personal* reading (in no way the view of my employer). I¹m only 7 pages in as well, so this is likely under-informed and in another 300+ pages I will become more enlightened... Part A.16. No Throttling. "...A person engaged in the provision of broadband Internet access service, insofar as such person is so engaged, shall not impair or degrade lawful Internet traffic on the basis of Internet content,application, or service, or use of a non-harmful device, subject to reasonable network management." They then say in A.17 (which is not the rule I don¹t think but still probably carries weight in some way) "...It prohibits the degrading of Internet traffic based on source, destination, or content." Unfortunately the rule itself only seems to speak to content, not source or destination. Did someone miss adding that to the rule? - Jason From jhamilton at empiredistrict.com Thu Mar 12 13:47:41 2015 From: jhamilton at empiredistrict.com (Jordan Hamilton) Date: Thu, 12 Mar 2015 13:47:41 +0000 Subject: Brocade CES Routing Table Issue Message-ID: <9E011DD002D07D44997466761AE6680961D9E03C@SRV-EMPIRE183V.empiredistrict.com> I have been troubleshooting an issue with Brocade TAC in regards to our Brocade CES that we use for some static routing. The Firmware has been upgraded and hardware has been replaced and still the problem is occurring. I have talked to some other carriers I work with that have previously used Brocade gear and switched because of odd issues that could not be resolved. Curious if anyone on this list has had other odd Layer 3 issues with Brocade/Foundry Networks gear? My issue seems to be somehow related to the table in memory that the ARP and next-hop entries are stored in, entries will point to the wrong mac address or the wrong port for the next-hop, it happens about every 60 days like clockwork. Jordan Hamilton Telecommunications Engineer Empire District Electric Co. 720 Schifferdecker PO Box 127 Joplin, MO 64802 Ph: 417-625-4223 Cell: 417-388-3351 -- Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments. Check your e-mail security settings to determine how attachments are handled. -- This e-mail and any files transmitted with it are the property of THE EMPIRE DISTRICT ELECTRIC COMPANY, are confidential, and are intended solely for the use of the individual or entity to whom this email is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this message in error, please delete this message immediately from your computer and contact the sender by telephone at (417)-625-5100. Any other use, retention, dissemination, forwarding, printing or copying of this email is strictly prohibited. From william.r.kenny at gmail.com Thu Mar 12 17:30:16 2015 From: william.r.kenny at gmail.com (William Kenny) Date: Thu, 12 Mar 2015 12:30:16 -0500 Subject: FCC releases Open Internet document In-Reply-To: References: Message-ID: Page 7 -14 looks to be pretty important. Specifcially: NO BLOCKING: A person engaged in the provision of broadband Internet access service, insofar as such person is so engaged, shall not block lawful content, applications, services, or nonharmful devices, subject to reasonable network management. NO THROTTLING: A person engaged in the provision of broadband Internet access service, insofar as such person is so engaged, shall not impair or degrade lawful Internet traffic on the basis of Internet content, application, or service, or use of a non-harmful device, subject to reasonable network management. NO PAID PRIORITIZATION: A person engaged in the provision of broadband Internet access service, insofar as such person is so engaged, shall not engage in paid prioritization. There is also an interesting bit on gatekeeping: Any person engaged in the provision of broadband Internet access service, insofar as such person is so engaged, shall not unreasonably interfere with or unreasonably disadvantage (i) end users’ ability to select, access, and use broadband Internet access service or the lawful Internet content, applications, services, or devices of their choice, or (ii) edge providers’ ability to make lawful content, applications, services, or devices available to end users. Reasonable network management shall not be considered a violation of this rule. I think there are going to be a lot of complex implications of this announcement (canidate for most obvious statement aware winner!). On Thu, Mar 12, 2015 at 10:32 AM, shawn wilson wrote: > On Mar 12, 2015 11:01 AM, "Ca By" wrote: > > > > For the first time to the public > > > > http://transition.fcc.gov/Daily_Releases/Daily_Business/2015/db0312/FCC-15-24A1.pdf > > > > Enjoy. > > Uh yeah, I'll wait for the reviews when y'all get done trudging through > that... > From rob at invaluement.com Thu Mar 12 18:02:00 2015 From: rob at invaluement.com (Rob McEwen) Date: Thu, 12 Mar 2015 14:02:00 -0400 Subject: FCC releases Open Internet document In-Reply-To: References: Message-ID: <5501D498.3080208@invaluement.com> On 3/12/2015 1:30 PM, William Kenny wrote: > NO BLOCKING: > A person engaged in the provision of broadband Internet access service, > insofar as such person is so engaged, shall not block lawful content, > applications, services, or nonharmful devices, subject to reasonable > network management. The document (if I read it correctly) states that "reasonable network management" includes spam filtering.... (yeah!) However, in spite of that... it seems to give the MISTAKEN impression that: (1) ALL spam is ALWAYS... NOT-lawful content (2) ALL lawful content is NEVER spam. (again, I'm not saying the document says this directly... only that it seems to give that impression at times!) But, in fact, there is actually MUCH spam that is 100% legal, but also 100% unsolicited/undesired and therefore frequently blocked by spam filters, and rightly so. I just hope that nobody argues in a court of law that their exceptions for spam filtering only applies to UNLAWFUL spam!!! THAT would be a DISASTER!!! Nevertheless, in such a circumstance, 47 USC 230(c)(2) should prevail and trump any such interpretation of this! (If anyone thinks that 47 USC 230(c)(2) might not prevail over such an interpretation, please let me know... and let me know why?) -- Rob McEwen From mikea at mikea.ath.cx Thu Mar 12 18:49:34 2015 From: mikea at mikea.ath.cx (Mike A) Date: Thu, 12 Mar 2015 13:49:34 -0500 Subject: FCC releases Open Internet document In-Reply-To: References: Message-ID: <20150312184934.GD2492@mikea.ath.cx> On Thu, Mar 12, 2015 at 12:30:16PM -0500, William Kenny wrote: > Page 7 -14 looks to be pretty important. Specifcially: > > NO BLOCKING: > A person engaged in the provision of broadband Internet access service, > insofar as such person is so engaged, shall not block lawful content, > applications, services, or nonharmful devices, subject to reasonable > network management. > > NO THROTTLING: > A person engaged in the provision of broadband Internet access service, > insofar as such person is so engaged, shall not impair or degrade lawful > Internet traffic on the basis of Internet content, application, or service, > or use of a non-harmful device, subject to reasonable network management. > > NO PAID PRIORITIZATION: > A person engaged in the provision of broadband Internet access service, > insofar as such person is so engaged, shall not engage in paid > prioritization. > > There is also an interesting bit on gatekeeping: > Any person engaged in the provision of broadband Internet access service, > insofar as such person is so engaged, shall not unreasonably interfere with > or unreasonably disadvantage (i) end users’ ability to select, access, and > use broadband Internet access service or the lawful Internet content, > applications, services, or devices of their choice, or (ii) edge providers’ > ability to make lawful content, applications, services, or devices > available to end users. Reasonable network management shall not be > considered a violation of this rule. > > I think there are going to be a lot of complex implications of this > announcement (canidate for most obvious statement aware winner!). > > On Thu, Mar 12, 2015 at 10:32 AM, shawn wilson wrote: > > > On Mar 12, 2015 11:01 AM, "Ca By" wrote: > > > > > > For the first time to the public > > > > > > > http://transition.fcc.gov/Daily_Releases/Daily_Business/2015/db0312/FCC-15-24A1.pdf > > > > > > Enjoy. > > > > Uh yeah, I'll wait for the reviews when y'all get done trudging through > > that... This will be interesting, in the context of cable providers providing inbound access to subscriber-address "server" ports only for "commercial" accounts. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From yardiel at gmail.com Thu Mar 12 19:01:26 2015 From: yardiel at gmail.com (Yardiel D. Fuentes) Date: Thu, 12 Mar 2015 15:01:26 -0400 Subject: BCOP appeals numbering scheme -- feedback requested Message-ID: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> Hello NANOGers, The NANOG BCOP committee is currently considering strategies on how to best create a numbering scheme for the BCOP appeals. As we all know, most public technical references (IETF, etc) have numbers to clarify references. The goal is for NANOG BCOPs to follow some sort of same style. The BCOP committee is looking for feedback and comments on this topic. Currently, the below numbering scheme is being considered: A proposed numbering scheme can be based on how the appeals appeals in the BCOP topics are presented as shown below: http://bcop.nanog.org/index.php/Appeals In the above page, the idea is to introduce a 100-th range for each category and as the BCOPs. This way a 100th number range generally identifies each of the categories we currently have. An example is: BCP Range Area of Practice 100 - 199 EBGPs 200 - 299 IGPs 300 - 399 Ethernet 400 - 499 Class of Service 500 - 599 Network Information Processing 600 - 699 Security 700 - 799 MPLS 800 - 899 Generalized An arguable objection could be that the range is limited...but a counter-argument is that considering more than 100 BCOPs would be either a great success or just a sign of failure for the NANOG community ... Comments or Thoughts ? Yardiel Fuentes From joelja at bogus.com Thu Mar 12 19:06:55 2015 From: joelja at bogus.com (joel jaeggli) Date: Thu, 12 Mar 2015 12:06:55 -0700 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> Message-ID: <5501E3CF.8060807@bogus.com> On 3/12/15 12:01 PM, Yardiel D. Fuentes wrote: > > > Hello NANOGers, > > The NANOG BCOP committee is currently considering strategies on how to best create a numbering scheme for the BCOP appeals. As we all know, most public technical references (IETF, etc) have numbers to clarify references. The goal is for NANOG BCOPs to follow some sort of same style. > > The BCOP committee is looking for feedback and comments on this topic. > > Currently, the below numbering scheme is being considered: > > A proposed numbering scheme can be based on how the appeals appeals in the BCOP topics are presented as shown below: > > http://bcop.nanog.org/index.php/Appeals > > In the above page, the idea is to introduce a 100-th range for each category and as the BCOPs. This way a 100th number range generally identifies each of the categories we currently have. An example is: identifier/locator overload. giving intergers intrinsic meaning is generally a mistake imho. > BCP Range Area of Practice > 100 - 199 EBGPs > 200 - 299 IGPs > 300 - 399 Ethernet > 400 - 499 Class of Service > 500 - 599 Network Information Processing > 600 - 699 Security > 700 - 799 MPLS > 800 - 899 Generalized > > An arguable objection could be that the range is limited...but a counter-argument is that considering more than 100 BCOPs would be either a great success or just a sign of failure for the NANOG community ... > > Comments or Thoughts ? > > > Yardiel Fuentes > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: OpenPGP digital signature URL: From lowen at pari.edu Thu Mar 12 19:11:23 2015 From: lowen at pari.edu (Lamar Owen) Date: Thu, 12 Mar 2015 15:11:23 -0400 Subject: FCC releases Open Internet document In-Reply-To: <5501CCC4.908@pari.edu> References: Message-ID: <5501E4DB.4050402@pari.edu> On 03/12/2015 01:28 PM, Lamar Owen wrote: > On 03/12/2015 12:13 PM, Bryan Tong wrote: >> I read through the introduction. This document seems like a good >> thing for everyone. >> >> > I'm about 50 pages in, reading a little bit at a time. Paragraph 31 > is one that anyone who does peering or exchanges should read and > understand. I take it to mean something like 'Guys who abuse peering > and engage in peering disputes, take note of what we just did to the > last mile people; you have been warned.' But, having read Commission > R&O's before on the broadcast (Media Bureau) side of the house for > years, maybe I'm a bit cynical. Another 40 pages, and found the detailed paragraphs related to this introductory paragraph. Those here who know how peering works in the real world, read paragraphs 194 through 206 of this R&O, including footnotes, and see if the FCC 'gets it' when it comes to how peering works. From job at instituut.net Thu Mar 12 19:12:18 2015 From: job at instituut.net (Job Snijders) Date: Thu, 12 Mar 2015 20:12:18 +0100 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: <5501E3CF.8060807@bogus.com> References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <5501E3CF.8060807@bogus.com> Message-ID: On Mar 12, 2015 8:08 PM, "joel jaeggli" wrote: > > On 3/12/15 12:01 PM, Yardiel D. Fuentes wrote: > > In the above page, the idea is to introduce a 100-th range for each category and as the BCOPs. This way a 100th number range generally identifies each of the categories we currently have. An example is: > > identifier/locator overload. > > giving intergers intrinsic meaning is generally a mistake imho. I agree with Joel From dah at franczek.com Thu Mar 12 19:12:32 2015 From: dah at franczek.com (Hass, Douglas A.) Date: Thu, 12 Mar 2015 19:12:32 +0000 Subject: FCC releases Open Internet document In-Reply-To: <20150312184934.GD2492@mikea.ath.cx> References: <20150312184934.GD2492@mikea.ath.cx> Message-ID: This may have less of an impact than you think on your network (though it certainly will change your terms of service). -----Original Message----- From: NANOG [mailto:nanog-bounces+dah=franczek.com at nanog.org] On Behalf Of Mike A Sent: Thursday, March 12, 2015 1:50 PM To: North American Network Operators Group Subject: Re: FCC releases Open Internet document On Thu, Mar 12, 2015 at 12:30:16PM -0500, William Kenny wrote: > Page 7 -14 looks to be pretty important. Specifcially: > > NO BLOCKING: > A person engaged in the provision of broadband Internet access > service, insofar as such person is so engaged, shall not block lawful > content, applications, services, or nonharmful devices, subject to > reasonable network management. > > NO THROTTLING: > A person engaged in the provision of broadband Internet access > service, insofar as such person is so engaged, shall not impair or > degrade lawful Internet traffic on the basis of Internet content, > application, or service, or use of a non-harmful device, subject to reasonable network management. > > NO PAID PRIORITIZATION: > A person engaged in the provision of broadband Internet access > service, insofar as such person is so engaged, shall not engage in > paid prioritization. > > There is also an interesting bit on gatekeeping: > Any person engaged in the provision of broadband Internet access > service, insofar as such person is so engaged, shall not unreasonably > interfere with or unreasonably disadvantage (i) end users’ ability to > select, access, and use broadband Internet access service or the > lawful Internet content, applications, services, or devices of their choice, or (ii) edge providers’ > ability to make lawful content, applications, services, or devices > available to end users. Reasonable network management shall not be > considered a violation of this rule. > > I think there are going to be a lot of complex implications of this > announcement (canidate for most obvious statement aware winner!). > > On Thu, Mar 12, 2015 at 10:32 AM, shawn wilson wrote: > > > On Mar 12, 2015 11:01 AM, "Ca By" wrote: > > > > > > For the first time to the public > > > > > > > http://transition.fcc.gov/Daily_Releases/Daily_Business/2015/db0312/ > > FCC-15-24A1.pdf > > > > > > Enjoy. > > > > Uh yeah, I'll wait for the reviews when y'all get done trudging > > through that... This will be interesting, in the context of cable providers providing inbound access to subscriber-address "server" ports only for "commercial" accounts. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin Doug Hass Associate 312.786.6502 Franczek Radelet P.C. 300 South Wacker Drive Suite 3400 Chicago, IL 60606 312.986.0300 - Main 312.986.9192 - Fax www.franczek.com Circular 230 Disclosure: Under requirements imposed by the Internal Revenue Service, we inform you that, unless specifically stated otherwise, any federal tax advice contained in this communication (including any attachments) is not intended or written to be used, and cannot be used, for the purposes of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending to another party any transaction or tax-related matter herein. ________________________________________ For more information about Franczek Radelet P.C., please visit franczek.com. The information contained in this e-mail message or any attachment may be confidential and/or privileged, and is intended only for the use of the named recipient. If you are not the named recipient of this message, you are hereby notified that any dissemination, distribution, or copying of this message or any attachment thereto, is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. ________________________________________ Franczek Radelet is committed to sustainability - please consider the environment before printing this email From ttauber at 1-4-5.net Thu Mar 12 19:23:32 2015 From: ttauber at 1-4-5.net (Tony Tauber) Date: Thu, 12 Mar 2015 15:23:32 -0400 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <5501E3CF.8060807@bogus.com> Message-ID: Totally. Also, then what if something is in the intersection of multiple "areas". Complexity that's not needed. Tony On Thu, Mar 12, 2015 at 3:12 PM, Job Snijders wrote: > On Mar 12, 2015 8:08 PM, "joel jaeggli" wrote: > > > > On 3/12/15 12:01 PM, Yardiel D. Fuentes wrote: > > > In the above page, the idea is to introduce a 100-th range for each > category and as the BCOPs. This way a 100th number range generally > identifies each of the categories we currently have. An example is: > > > > identifier/locator overload. > > > > giving intergers intrinsic meaning is generally a mistake imho. > > I agree with Joel > From tony at wicks.co.nz Thu Mar 12 19:24:04 2015 From: tony at wicks.co.nz (Tony Wicks) Date: Fri, 13 Mar 2015 08:24:04 +1300 Subject: Brocade CES Routing Table Issue In-Reply-To: <9E011DD002D07D44997466761AE6680961D9E03C@SRV-EMPIRE183V.empiredistrict.com> References: <9E011DD002D07D44997466761AE6680961D9E03C@SRV-EMPIRE183V.empiredistrict.com> Message-ID: <003d01d05cfa$1b5d8ec0$5218ac40$@wicks.co.nz> I regularly had this many years ago with the old Foundry Big Irons, the Route table on the processor would have the correct information but an individual forwarding table on a line card would be out of sync causing randomly occurring route loops. They never did fix it and that was the last time I used them with full internet route tables. This being said I saw similar issues (that were resolved) on Unisphere (now Juniper) and Extreme kit. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jordan Hamilton Sent: Friday, 13 March 2015 2:48 a.m. To: nanog at nanog.org Subject: Brocade CES Routing Table Issue I have been troubleshooting an issue with Brocade TAC in regards to our Brocade CES that we use for some static routing. The Firmware has been upgraded and hardware has been replaced and still the problem is occurring. I have talked to some other carriers I work with that have previously used Brocade gear and switched because of odd issues that could not be resolved. Curious if anyone on this list has had other odd Layer 3 issues with Brocade/Foundry Networks gear? My issue seems to be somehow related to the table in memory that the ARP and next-hop entries are stored in, entries will point to the wrong mac address or the wrong port for the next-hop, it happens about every 60 days like clockwork. From lowen at pari.edu Thu Mar 12 19:25:00 2015 From: lowen at pari.edu (Lamar Owen) Date: Thu, 12 Mar 2015 15:25:00 -0400 Subject: FCC releases Open Internet document In-Reply-To: <5501D498.3080208@invaluement.com> References: Message-ID: <5501E80C.2060008@pari.edu> On 03/12/2015 02:02 PM, Rob McEwen wrote: > On 3/12/2015 1:30 PM, William Kenny wrote: >> NO BLOCKING: >> A person engaged in the provision of broadband Internet access service, >> insofar as such person is so engaged, shall not block lawful content, >> applications, services, or nonharmful devices, subject to reasonable >> network management. > > The document (if I read it correctly) states that "reasonable network > management" includes spam filtering.... (yeah!) > > However, in spite of that... it seems to give the MISTAKEN impression > that: > > (1) ALL spam is ALWAYS... NOT-lawful content > (2) ALL lawful content is NEVER spam. > > I think the issue is adequately addressed by the R&O's paragraph 222 and its neighbors, with footnotes 571, 572, and 573 elucidating. The short version: the FCC is not going to rigidly define this and leave it up to the providers, but they will address it on a case-by-case basis if need be. At least that was my takeaway. > Nevertheless, in such a circumstance, 47 USC 230(c)(2) should prevail > and trump any such interpretation of this! > > (If anyone thinks that 47 USC 230(c)(2) might not prevail over such an > interpretation, please let me know... and let me know why?) > It would seem, but I am not a lawyer, that perhaps it would. It's not directly addressed in the portions of the R&O that I've read thus far, and that specific paragraph is not cited that I could find. A Good Samaritan law, in 47 USC..... fun stuff. From lowen at pari.edu Thu Mar 12 19:48:31 2015 From: lowen at pari.edu (Lamar Owen) Date: Thu, 12 Mar 2015 15:48:31 -0400 Subject: Unlawful transfers of content and transfers of unlawful content (was:Re: Verizon Policy Statement on Net Neutrality) In-Reply-To: References: Message-ID: <5501ED8F.3040401@pari.edu> On 02/27/2015 02:14 PM, Jim Richardson wrote: > What's a "lawful" web site? > Paragraphs 304 and 305 in today's released R&O address some of this. The wording 'Unlawful transfers of content and transfers of unlawful content' is pretty good, and covers what the Commission wanted to cover. From jason at lixfeld.ca Thu Mar 12 19:58:20 2015 From: jason at lixfeld.ca (Jason Lixfeld) Date: Thu, 12 Mar 2015 15:58:20 -0400 Subject: Google served from non-google IPs? Message-ID: <86FE96C5-C39F-42DE-957E-74BE38B2DAB8@lixfeld.ca> So today, I saw this: BlackBox:~ jlixfeld$ host google.ca 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases: google.ca has address 206.126.112.166 google.ca has address 206.126.112.177 google.ca has address 206.126.112.172 google.ca has address 206.126.112.187 google.ca has address 206.126.112.151 google.ca has address 206.126.112.158 google.ca has address 206.126.112.157 google.ca has address 206.126.112.173 google.ca has address 206.126.112.181 google.ca has address 206.126.112.155 google.ca has address 206.126.112.147 google.ca has address 206.126.112.185 google.ca has address 206.126.112.143 google.ca has address 206.126.112.170 google.ca has address 206.126.112.162 google.ca has IPv6 address 2607:f8b0:4006:808::100f google.ca mail is handled by 50 alt4.aspmx.l.google.com. google.ca mail is handled by 30 alt2.aspmx.l.google.com. google.ca mail is handled by 20 alt1.aspmx.l.google.com. google.ca mail is handled by 10 aspmx.l.google.com. google.ca mail is handled by 40 alt3.aspmx.l.google.com. BlackBox:~ jlixfeld$ That is not Google IPv4 address space, and those IPv4 IPs are not being announced by 15169. Am I dumb in thinking that this is weird or is this sort of thing commonplace? From sf at lists.esoteric.ca Thu Mar 12 20:00:05 2015 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Thu, 12 Mar 2015 16:00:05 -0400 Subject: Google served from non-google IPs? In-Reply-To: <86FE96C5-C39F-42DE-957E-74BE38B2DAB8@lixfeld.ca> References: <86FE96C5-C39F-42DE-957E-74BE38B2DAB8@lixfeld.ca> Message-ID: <5501F045.1030903@lists.esoteric.ca> Local Google caches at QIX? -- Stephen On 2015-03-12 3:58 PM, Jason Lixfeld wrote: > So today, I saw this: > > BlackBox:~ jlixfeld$ host google.ca 8.8.8.8 > Using domain server: > Name: 8.8.8.8 > Address: 8.8.8.8#53 > Aliases: > > google.ca has address 206.126.112.166 > google.ca has address 206.126.112.177 > google.ca has address 206.126.112.172 > google.ca has address 206.126.112.187 > google.ca has address 206.126.112.151 > google.ca has address 206.126.112.158 > google.ca has address 206.126.112.157 > google.ca has address 206.126.112.173 > google.ca has address 206.126.112.181 > google.ca has address 206.126.112.155 > google.ca has address 206.126.112.147 > google.ca has address 206.126.112.185 > google.ca has address 206.126.112.143 > google.ca has address 206.126.112.170 > google.ca has address 206.126.112.162 > google.ca has IPv6 address 2607:f8b0:4006:808::100f > google.ca mail is handled by 50 alt4.aspmx.l.google.com. > google.ca mail is handled by 30 alt2.aspmx.l.google.com. > google.ca mail is handled by 20 alt1.aspmx.l.google.com. > google.ca mail is handled by 10 aspmx.l.google.com. > google.ca mail is handled by 40 alt3.aspmx.l.google.com. > BlackBox:~ jlixfeld$ > > That is not Google IPv4 address space, and those IPv4 IPs are not being announced by 15169. > > Am I dumb in thinking that this is weird or is this sort of thing commonplace? > From listas at esds.com.br Thu Mar 12 20:01:48 2015 From: listas at esds.com.br (Eduardo Schoedler) Date: Thu, 12 Mar 2015 17:01:48 -0300 Subject: Google served from non-google IPs? In-Reply-To: <86FE96C5-C39F-42DE-957E-74BE38B2DAB8@lixfeld.ca> References: <86FE96C5-C39F-42DE-957E-74BE38B2DAB8@lixfeld.ca> Message-ID: Look for GGC. -- Eduardo Schoedler 2015-03-12 16:58 GMT-03:00 Jason Lixfeld : > So today, I saw this: > > BlackBox:~ jlixfeld$ host google.ca 8.8.8.8 > Using domain server: > Name: 8.8.8.8 > Address: 8.8.8.8#53 > Aliases: > > google.ca has address 206.126.112.166 > google.ca has address 206.126.112.177 > google.ca has address 206.126.112.172 > google.ca has address 206.126.112.187 > google.ca has address 206.126.112.151 > google.ca has address 206.126.112.158 > google.ca has address 206.126.112.157 > google.ca has address 206.126.112.173 > google.ca has address 206.126.112.181 > google.ca has address 206.126.112.155 > google.ca has address 206.126.112.147 > google.ca has address 206.126.112.185 > google.ca has address 206.126.112.143 > google.ca has address 206.126.112.170 > google.ca has address 206.126.112.162 > google.ca has IPv6 address 2607:f8b0:4006:808::100f > google.ca mail is handled by 50 alt4.aspmx.l.google.com. > google.ca mail is handled by 30 alt2.aspmx.l.google.com. > google.ca mail is handled by 20 alt1.aspmx.l.google.com. > google.ca mail is handled by 10 aspmx.l.google.com. > google.ca mail is handled by 40 alt3.aspmx.l.google.com. > BlackBox:~ jlixfeld$ > > That is not Google IPv4 address space, and those IPv4 IPs are not being > announced by 15169. > > Am I dumb in thinking that this is weird or is this sort of thing > commonplace? -- Eduardo Schoedler From tfarrell at riotgames.com Thu Mar 12 20:05:40 2015 From: tfarrell at riotgames.com (Trent Farrell) Date: Thu, 12 Mar 2015 13:05:40 -0700 Subject: Google served from non-google IPs? In-Reply-To: <5501F045.1030903@lists.esoteric.ca> References: <86FE96C5-C39F-42DE-957E-74BE38B2DAB8@lixfeld.ca> <5501F045.1030903@lists.esoteric.ca> Message-ID: ^ my thought, they're on the QIX public block On Thu, Mar 12, 2015 at 1:00 PM, Stephen Fulton wrote: > Local Google caches at QIX? > > -- Stephen > > > On 2015-03-12 3:58 PM, Jason Lixfeld wrote: > >> So today, I saw this: >> >> BlackBox:~ jlixfeld$ host google.ca 8.8.8.8 >> Using domain server: >> Name: 8.8.8.8 >> Address: 8.8.8.8#53 >> Aliases: >> >> google.ca has address 206.126.112.166 >> google.ca has address 206.126.112.177 >> google.ca has address 206.126.112.172 >> google.ca has address 206.126.112.187 >> google.ca has address 206.126.112.151 >> google.ca has address 206.126.112.158 >> google.ca has address 206.126.112.157 >> google.ca has address 206.126.112.173 >> google.ca has address 206.126.112.181 >> google.ca has address 206.126.112.155 >> google.ca has address 206.126.112.147 >> google.ca has address 206.126.112.185 >> google.ca has address 206.126.112.143 >> google.ca has address 206.126.112.170 >> google.ca has address 206.126.112.162 >> google.ca has IPv6 address 2607:f8b0:4006:808::100f >> google.ca mail is handled by 50 alt4.aspmx.l.google.com. >> google.ca mail is handled by 30 alt2.aspmx.l.google.com. >> google.ca mail is handled by 20 alt1.aspmx.l.google.com. >> google.ca mail is handled by 10 aspmx.l.google.com. >> google.ca mail is handled by 40 alt3.aspmx.l.google.com. >> BlackBox:~ jlixfeld$ >> >> That is not Google IPv4 address space, and those IPv4 IPs are not being >> announced by 15169. >> >> Am I dumb in thinking that this is weird or is this sort of thing >> commonplace? >> >> -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarrell at riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro From schecter at gmail.com Thu Mar 12 20:07:01 2015 From: schecter at gmail.com (Steven Schecter) Date: Thu, 12 Mar 2015 16:07:01 -0400 Subject: Google served from non-google IPs? In-Reply-To: <86FE96C5-C39F-42DE-957E-74BE38B2DAB8@lixfeld.ca> References: <86FE96C5-C39F-42DE-957E-74BE38B2DAB8@lixfeld.ca> Message-ID: Those IPs appear to be used by to Google cache servers at the QIX. It's common for CDNs to utilize provider space and not maintain their own layer-3. E.g. cache servers connected to switch, connected to provider, without the requirement of a router. /Steve On Thu, Mar 12, 2015 at 3:58 PM, Jason Lixfeld wrote: > So today, I saw this: > > BlackBox:~ jlixfeld$ host google.ca 8.8.8.8 > Using domain server: > Name: 8.8.8.8 > Address: 8.8.8.8#53 > Aliases: > > google.ca has address 206.126.112.166 > google.ca has address 206.126.112.177 > google.ca has address 206.126.112.172 > google.ca has address 206.126.112.187 > google.ca has address 206.126.112.151 > google.ca has address 206.126.112.158 > google.ca has address 206.126.112.157 > google.ca has address 206.126.112.173 > google.ca has address 206.126.112.181 > google.ca has address 206.126.112.155 > google.ca has address 206.126.112.147 > google.ca has address 206.126.112.185 > google.ca has address 206.126.112.143 > google.ca has address 206.126.112.170 > google.ca has address 206.126.112.162 > google.ca has IPv6 address 2607:f8b0:4006:808::100f > google.ca mail is handled by 50 alt4.aspmx.l.google.com. > google.ca mail is handled by 30 alt2.aspmx.l.google.com. > google.ca mail is handled by 20 alt1.aspmx.l.google.com. > google.ca mail is handled by 10 aspmx.l.google.com. > google.ca mail is handled by 40 alt3.aspmx.l.google.com. > BlackBox:~ jlixfeld$ > > That is not Google IPv4 address space, and those IPv4 IPs are not being > announced by 15169. > > Am I dumb in thinking that this is weird or is this sort of thing > commonplace? -- Steven J. Schecter (m) 917.676.1646 From lowen at pari.edu Thu Mar 12 21:14:35 2015 From: lowen at pari.edu (Lamar Owen) Date: Thu, 12 Mar 2015 17:14:35 -0400 Subject: Unlawful transfers of content and transfers of unlawful content In-Reply-To: References: Message-ID: <550201BB.4020405@pari.edu> On 03/12/2015 04:58 PM, Donald Kasper wrote: > > > More then website blocking I've been wondering what this means for > spam prevention? That's a pretty interesting thought, and it is pretty well addressed by paragraphs 376, 377, and 378. Basically, the FCC found that spam blocking is a separate add-on information service. It may be that the consumer now must opt-in to that service after clear disclosure of what the service entails. The FCC even found that DNS is not an information service (paragraphs 366-371), and the argument is compelling. This Commission is not technically illiterate, that's for sure, whether you agree with the R&O or not. From lowen at pari.edu Thu Mar 12 21:23:35 2015 From: lowen at pari.edu (Lamar Owen) Date: Thu, 12 Mar 2015 17:23:35 -0400 Subject: FCC releases Open Internet document In-Reply-To: <5501D498.3080208@invaluement.com> References: Message-ID: <550203D7.9090601@pari.edu> On 03/12/2015 02:02 PM, Rob McEwen wrote: > Nevertheless, in such a circumstance, 47 USC 230(c)(2) should prevail > and trump any such interpretation of this! > > (If anyone thinks that 47 USC 230(c)(2) might not prevail over such an > interpretation, please let me know... and let me know why?) > Found it; paragraph 532 addresses 230(c). In a nutshell, the applicability does not change due to the reclassification of BIAS providers as telecommunications services. From drohan at gmail.com Thu Mar 12 21:51:34 2015 From: drohan at gmail.com (Daniel Rohan) Date: Thu, 12 Mar 2015 14:51:34 -0700 Subject: Broken/trashed/junk Juniper MX5/80 and Cisco 2921 chassis? Message-ID: Hey all, Sorry for the x-post with j-nsp, but I'm looking for something that seems to be a bit hard to find and I'm hoping that someone in the larger community might be able to help. I'm trying to find a totally broken, cheap, MX5/80 and a Cisco 2921 chassis that I can use for demonstration trainings with our edge technicians. We're currently running the demos with spare gear, but even though we transport this gear in shock-mounted cases, I'd much rather be transporting dummy equipment. Our SEs don't have a line on this kind of gear either. Aparently this type of gear is destroyed or refurbished, but there isn't much demand for broken equipment sitting around staying broken. If you have a line on some of this gear that you'd be willing to share, I'd appreciate it. Thanks, Dan From donald.kasper at outlook.com Thu Mar 12 20:58:18 2015 From: donald.kasper at outlook.com (Donald Kasper) Date: Thu, 12 Mar 2015 16:58:18 -0400 Subject: Unlawful transfers of content and transfers of unlawful content (was:Re: Verizon Policy Statement on Net Neutrality) In-Reply-To: <5501ED8F.3040401@pari.edu> References: , <5501ED8F.3040401@pari.edu> Message-ID: > Date: Thu, 12 Mar 2015 15:48:31 -0400 > From: lowen at pari.edu > To: nanog at nanog.org > Subject: Unlawful transfers of content and transfers of unlawful content (was:Re: Verizon Policy Statement on Net Neutrality) > > On 02/27/2015 02:14 PM, Jim Richardson wrote: > > What's a "lawful" web site? > > > Paragraphs 304 and 305 in today's released R&O address some of this. > The wording 'Unlawful transfers of content and transfers of unlawful > content' is pretty good, and covers what the Commission wanted to cover. > More then website blocking I've been wondering what this means for spam prevention? From owen at delong.com Thu Mar 12 23:48:18 2015 From: owen at delong.com (Owen DeLong) Date: Thu, 12 Mar 2015 16:48:18 -0700 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> Message-ID: <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> > On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes wrote: > > > > Hello NANOGers, > > The NANOG BCOP committee is currently considering strategies on how to best create a numbering scheme for the BCOP appeals. As we all know, most public technical references (IETF, etc) have numbers to clarify references. The goal is for NANOG BCOPs to follow some sort of same style. > > The BCOP committee is looking for feedback and comments on this topic. > > Currently, the below numbering scheme is being considered: > > A proposed numbering scheme can be based on how the appeals appeals in the BCOP topics are presented as shown below: > > http://bcop.nanog.org/index.php/Appeals > > In the above page, the idea is to introduce a 100-th range for each category and as the BCOPs. This way a 100th number range generally identifies each of the categories we currently have. An example is: > > BCP Range Area of Practice > 100 - 199 EBGPs > 200 - 299 IGPs > 300 - 399 Ethernet > 400 - 499 Class of Service > 500 - 599 Network Information Processing > 600 - 699 Security > 700 - 799 MPLS > 800 - 899 Generalized > > An arguable objection could be that the range is limited...but a counter-argument is that considering more than 100 BCOPs would be either a great success or just a sign of failure for the NANOG community ... > > Comments or Thoughts ? The problem with any such numbering scheme is how you handle the situation when you exhaust the avaialble number space. What happens with the 101st EBGP BCOP, for example? I also agree with Joel’s comment about identifier/locator overload. Have we learned nothing from the issues created by doing this in IPv4 and IPv6? Instead, how about maintaining a BCOP subject index which contains titular and numeric information for each BCOP applicable to the subjects above. e.g.: BCOP Subject Index: Subjects: 1. EBGP 2. IGP 3. Ethernet 4. Class of Service 5. Network Information Processing 6. Security 7. MPLS 8. Generalized 1. EBGP 104 lorem ipsum 423 ipsum lorem Then, just like the RFCs, maintain the BCOP appeal numbering as a sequential monotonically increasing number and make the BCOP editor responsible for updating the index with the publishing of each new or revised BCOP. Note, IMHO, a revised BCOP should get a new number and the previous revision should be marked “obsoleted by XXXXX” and it’s document status should reflect “Obsoletes XXXX, XXXX, and XXXX” for all previous revisions. The index should probably reflect only BCOPs which have not been obsoleted. Just my $0.02. Owen From jason.iannone at gmail.com Fri Mar 13 00:20:39 2015 From: jason.iannone at gmail.com (Jason Iannone) Date: Thu, 12 Mar 2015 18:20:39 -0600 Subject: Searching for a quote Message-ID: There was once a fairly common saying attributed to an early networking pioneer that went something like, "be generous in what you accept, and send only the stuff that should be sent." Does anyone know what I'm talking about or who said it? From tom at cloudflare.com Fri Mar 13 00:24:59 2015 From: tom at cloudflare.com (Tom Paseka) Date: Thu, 12 Mar 2015 17:24:59 -0700 Subject: Searching for a quote In-Reply-To: References: Message-ID: Be conservative in what you send, be liberal in what you accept ^http://en.wikipedia.org/wiki/Robustness_principle On Thu, Mar 12, 2015 at 5:20 PM, Jason Iannone wrote: > There was once a fairly common saying attributed to an early > networking pioneer that went something like, "be generous in what you > accept, and send only the stuff that should be sent." Does anyone > know what I'm talking about or who said it? > From dave.taht at gmail.com Fri Mar 13 00:27:22 2015 From: dave.taht at gmail.com (Dave Taht) Date: Thu, 12 Mar 2015 17:27:22 -0700 Subject: Searching for a quote In-Reply-To: References: Message-ID: jon postel. http://en.wikipedia.org/wiki/Jon_Postel On Thu, Mar 12, 2015 at 5:20 PM, Jason Iannone wrote: > There was once a fairly common saying attributed to an early > networking pioneer that went something like, "be generous in what you > accept, and send only the stuff that should be sent." Does anyone > know what I'm talking about or who said it? -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb From tdurack at gmail.com Fri Mar 13 00:28:22 2015 From: tdurack at gmail.com (Tim Durack) Date: Thu, 12 Mar 2015 20:28:22 -0400 Subject: Searching for a quote In-Reply-To: References: Message-ID: http://en.wikipedia.org/wiki/Jon_Postel Postel's Law Perhaps his most famous legacy is from RFC 760, which includes a Robustness Principle which is often labeled Postel's Law: "an implementation should be conservative in its sending behavior, and liberal in its receiving behavior" (reworded in RFC 1122 as "Be liberal in what you accept, and conservative in what you send"). On Thu, Mar 12, 2015 at 8:20 PM, Jason Iannone wrote: > There was once a fairly common saying attributed to an early > networking pioneer that went something like, "be generous in what you > accept, and send only the stuff that should be sent." Does anyone > know what I'm talking about or who said it? > -- Tim:> From mfidelman at meetinghouse.net Fri Mar 13 00:29:07 2015 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 12 Mar 2015 20:29:07 -0400 Subject: Searching for a quote In-Reply-To: References: Message-ID: <55022F53.8040605@meetinghouse.net> That was quick. :-) Tom Paseka wrote: > Be conservative in what you send, be liberal in what you accept > > ^http://en.wikipedia.org/wiki/Robustness_principle > > On Thu, Mar 12, 2015 at 5:20 PM, Jason Iannone > wrote: > >> There was once a fairly common saying attributed to an early >> networking pioneer that went something like, "be generous in what you >> accept, and send only the stuff that should be sent." Does anyone >> know what I'm talking about or who said it? >> -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mike at mtcc.com Fri Mar 13 00:31:54 2015 From: mike at mtcc.com (Michael Thomas) Date: Thu, 12 Mar 2015 17:31:54 -0700 Subject: Searching for a quote In-Reply-To: References: Message-ID: <55022FFA.1030309@mtcc.com> Jon Postel. I'm told that it is out of favor these days in protocol-land, from a security standpoint if nothing else. Mike On 3/12/15 5:24 PM, Tom Paseka wrote: > Be conservative in what you send, be liberal in what you accept > > ^http://en.wikipedia.org/wiki/Robustness_principle > > On Thu, Mar 12, 2015 at 5:20 PM, Jason Iannone > wrote: > >> There was once a fairly common saying attributed to an early >> networking pioneer that went something like, "be generous in what you >> accept, and send only the stuff that should be sent." Does anyone >> know what I'm talking about or who said it? >> From jason.iannone at gmail.com Fri Mar 13 00:31:45 2015 From: jason.iannone at gmail.com (Jason Iannone) Date: Thu, 12 Mar 2015 18:31:45 -0600 Subject: Searching for a quote In-Reply-To: References: Message-ID: Thanks all. On Thu, Mar 12, 2015 at 6:28 PM, Tim Durack wrote: > http://en.wikipedia.org/wiki/Jon_Postel > > Postel's Law > Perhaps his most famous legacy is from RFC 760, which includes a Robustness > Principle which is often labeled Postel's Law: "an implementation should be > conservative in its sending behavior, and liberal in its receiving behavior" > (reworded in RFC 1122 as "Be liberal in what you accept, and conservative in > what you send"). > > On Thu, Mar 12, 2015 at 8:20 PM, Jason Iannone > wrote: >> >> There was once a fairly common saying attributed to an early >> networking pioneer that went something like, "be generous in what you >> accept, and send only the stuff that should be sent." Does anyone >> know what I'm talking about or who said it? > > > > > -- > Tim:> From ml-nanog090304q at elcsplace.com Fri Mar 13 00:32:29 2015 From: ml-nanog090304q at elcsplace.com (Ted Cooper) Date: Fri, 13 Mar 2015 10:32:29 +1000 Subject: Searching for a quote In-Reply-To: References: Message-ID: <5502301D.1010907@elcsplace.com> On 13/03/15 10:20, Jason Iannone wrote: > There was once a fairly common saying attributed to an early > networking pioneer that went something like, "be generous in what you > accept, and send only the stuff that should be sent." Does anyone > know what I'm talking about or who said it? > Jon Postel's Robustness Principal. http://en.wikipedia.org/wiki/Jon_Postel From dave.taht at gmail.com Fri Mar 13 00:33:19 2015 From: dave.taht at gmail.com (Dave Taht) Date: Thu, 12 Mar 2015 17:33:19 -0700 Subject: Searching for a quote In-Reply-To: References: Message-ID: On Thu, Mar 12, 2015 at 5:27 PM, Dave Taht wrote: > jon postel. http://en.wikipedia.org/wiki/Jon_Postel Had he lived, email and netnews would have remained usable by mere mortals and met the challenge of extreme growth and abuse. And ICANN, and for that netsol, wouldn't have become the ugly morass they became. Hell, even the IETF might have remained viable. I have few heroes. He was one of them. > > On Thu, Mar 12, 2015 at 5:20 PM, Jason Iannone wrote: >> There was once a fairly common saying attributed to an early >> networking pioneer that went something like, "be generous in what you >> accept, and send only the stuff that should be sent." Does anyone >> know what I'm talking about or who said it? > > > > -- > Dave Täht > Let's make wifi fast, less jittery and reliable again! > > https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb From barney at databus.com Fri Mar 13 00:37:58 2015 From: barney at databus.com (Barney Wolff) Date: Thu, 12 Mar 2015 20:37:58 -0400 Subject: Searching for a quote In-Reply-To: References: Message-ID: <20150313003758.GA41461@pit.databus.com> I feel required to point out that Postel's Law was sage advice for its time, but should now be amended with "but assume that all input is hostile." On Thu, Mar 12, 2015 at 08:28:22PM -0400, Tim Durack wrote: > http://en.wikipedia.org/wiki/Jon_Postel > > Postel's Law > Perhaps his most famous legacy is from RFC 760, which includes a Robustness > Principle which is often labeled Postel's Law: "an implementation should be > conservative in its sending behavior, and liberal in its receiving > behavior" (reworded in RFC 1122 as "Be liberal in what you accept, and > conservative in what you send"). From jason.iannone at gmail.com Fri Mar 13 00:38:14 2015 From: jason.iannone at gmail.com (Jason Iannone) Date: Thu, 12 Mar 2015 18:38:14 -0600 Subject: Searching for a quote In-Reply-To: <55022F53.8040605@meetinghouse.net> References: <55022F53.8040605@meetinghouse.net> Message-ID: Low hanging fruit. On Thu, Mar 12, 2015 at 6:29 PM, Miles Fidelman wrote: > That was quick. :-) > > > Tom Paseka wrote: >> >> Be conservative in what you send, be liberal in what you accept >> >> ^http://en.wikipedia.org/wiki/Robustness_principle >> >> On Thu, Mar 12, 2015 at 5:20 PM, Jason Iannone >> wrote: >> >>> There was once a fairly common saying attributed to an early >>> networking pioneer that went something like, "be generous in what you >>> accept, and send only the stuff that should be sent." Does anyone >>> know what I'm talking about or who said it? >>> > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > From larrysheldon at cox.net Fri Mar 13 00:44:26 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Thu, 12 Mar 2015 19:44:26 -0500 Subject: Searching for a quote In-Reply-To: <2oQE1q0011cZc5601oQF3n> References: <2oQE1q0011cZc5601oQF3n> Message-ID: <550232EA.7040203@cox.net> On 3/12/2015 19:20, Jason Iannone wrote: > There was once a fairly common saying attributed to an early > networking pioneer that went something like, "be generous in what you > accept, and send only the stuff that should be sent." Does anyone > know what I'm talking about or who said it? > Postel's Law: Be generous in what you accept; strict in what you send.* *From aging memory, but I think that is close. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From patrick at ianai.net Fri Mar 13 01:28:35 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 12 Mar 2015 21:28:35 -0400 Subject: Searching for a quote In-Reply-To: <550232EA.7040203@cox.net> References: <2oQE1q0011cZc5601oQF3n> <550232EA.7040203@cox.net> Message-ID: <6193890E-2B71-4760-8ED9-45F9A00EC8EF@ianai.net> On Mar 12, 2015, at 20:44 , Larry Sheldon wrote: > On 3/12/2015 19:20, Jason Iannone wrote: >> There was once a fairly common saying attributed to an early >> networking pioneer that went something like, "be generous in what you >> accept, and send only the stuff that should be sent." Does anyone >> know what I'm talking about or who said it? > > Postel's Law: Be generous in what you accept; strict in what you send.* > > *From aging memory, but I think that is close. https://en.wikipedia.org/wiki/Robustness_principle Be conservative in what you do, be liberal in what you accept from others (often reworded as "Be conservative in what you send, be liberal in what you accept"). -- TTFN, patrick From bmanning at isi.edu Fri Mar 13 01:34:58 2015 From: bmanning at isi.edu (manning bill) Date: Thu, 12 Mar 2015 18:34:58 -0700 Subject: Searching for a quote In-Reply-To: <55022FFA.1030309@mtcc.com> References: <55022FFA.1030309@mtcc.com> Message-ID: <6202315B-B9D4-49F9-8CEF-C30F9EFB929A@isi.edu> it is true that the risk profile has changed in the last 30 years. his core belief in interconnecting things in an open way, enabling _anyone_ to create,build, and deploy is the core of ISOCs “permission less innovation” thrust. crypto/security folks are green with envy … it is somewhat “sour grapes” no? I count my time working for him as one of the highlights of my life. In some respects, I still do… :) /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 12March2015Thursday, at 17:31, Michael Thomas wrote: > Jon Postel. I'm told that it is out of favor these days in protocol-land, > from a security standpoint if nothing else. > > Mike > > On 3/12/15 5:24 PM, Tom Paseka wrote: >> Be conservative in what you send, be liberal in what you accept >> >> ^http://en.wikipedia.org/wiki/Robustness_principle >> >> On Thu, Mar 12, 2015 at 5:20 PM, Jason Iannone >> wrote: >> >>> There was once a fairly common saying attributed to an early >>> networking pioneer that went something like, "be generous in what you >>> accept, and send only the stuff that should be sent." Does anyone >>> know what I'm talking about or who said it? >>> > From rsk at gsp.org Fri Mar 13 02:00:07 2015 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 12 Mar 2015 22:00:07 -0400 Subject: Searching for a quote In-Reply-To: References: Message-ID: <20150313020007.GA20522@gsp.org> On Thu, Mar 12, 2015 at 05:33:19PM -0700, Dave Taht wrote: > Had he lived, email and netnews would have remained usable by mere > mortals and met the challenge of extreme growth and abuse. And ICANN, > and for that netsol, wouldn't have become the ugly morass they became. > Hell, even the IETF might have remained viable. Indeed. That sentiment, and his memory, deserve a toast of MacAllan 18-year. And they shall have it momentarily. ---rsk From kmedcalf at dessus.com Fri Mar 13 05:25:58 2015 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 12 Mar 2015 23:25:58 -0600 Subject: Searching for a quote In-Reply-To: <55022FFA.1030309@mtcc.com> Message-ID: Robustness is desirable from a security perspective. Failure to be liberal in what you accept and not being prepared to deal with malformed input leads to such wonders as the Microsoft bug that led to unexpected/malformed IP datagrams mishandled as "execute payload with system authority". Rather than sloppiness you could also attribute the error to malice -- that it was injected at the specific request of certain government agencies, perhaps under threat, perhaps with just a wink and a nod ... --- Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Michael Thomas >Sent: Thursday, 12 March, 2015 18:32 >To: nanog at nanog.org >Subject: Re: Searching for a quote > >Jon Postel. I'm told that it is out of favor these days in protocol-land, >from a security standpoint if nothing else. > >Mike > >On 3/12/15 5:24 PM, Tom Paseka wrote: >> Be conservative in what you send, be liberal in what you accept >> >> ^http://en.wikipedia.org/wiki/Robustness_principle >> >> On Thu, Mar 12, 2015 at 5:20 PM, Jason Iannone > >> wrote: >> >>> There was once a fairly common saying attributed to an early >>> networking pioneer that went something like, "be generous in what you >>> accept, and send only the stuff that should be sent." Does anyone >>> know what I'm talking about or who said it? >>> From mike at mtcc.com Fri Mar 13 07:17:02 2015 From: mike at mtcc.com (Michael Thomas) Date: Fri, 13 Mar 2015 00:17:02 -0700 Subject: Searching for a quote In-Reply-To: References: <55022FFA.1030309@mtcc.com> Message-ID: <55028EEE.5040300@mtcc.com> On 03/12/2015 11:52 PM, Eygene Ryabinkin wrote: > Thu, Mar 12, 2015 at 05:31:54PM -0700, Michael Thomas wrote: >> Jon Postel. I'm told that it is out of favor these days in protocol-land, >> from a security standpoint if nothing else. > The principle has nothing to do with security: it doesn't mean "accept > all junk that comes in". It is about interoperability of different > implementation and means "use the smallest possible subset of the > protocol when you're sending, but be prepared to accept any subset > of protocol messages when you're receiving". Eric Allman's ACM paper, > http://cacm.acm.org/magazines/2011/8/114933-the-robustness-principle-reconsidered/fulltext > is a good reading for this, I believe. The original principle had little thought toward security, and i was there for the row for which Eric's paper was almost certainly inspired by (started it, actually). In the early days, a lot of people to took it as trying very hard to make sense of the broken -- far beyond rfc 2119's musts and shoulds. A lot of people regret that now for a lot of reasons, including security. I still have mixed emotions about abandoning it. Mike From list at satchell.net Fri Mar 13 13:14:09 2015 From: list at satchell.net (Stephen Satchell) Date: Fri, 13 Mar 2015 06:14:09 -0700 Subject: Searching for a quote In-Reply-To: References: Message-ID: <5502E2A1.90308@satchell.net> On 03/12/2015 10:25 PM, Keith Medcalf wrote: > Robustness is desirable from a security perspective. Failure to be > liberal in what you accept and not being prepared to deal with > malformed input leads to such wonders as the Microsoft bug that led > to unexpected/malformed IP datagrams mishandled as "execute payload > with system authority". Rather than sloppiness you could also > attribute the error to malice -- that it was injected at the specific > request of certain government agencies, perhaps under threat, perhaps > with just a wink and a nod ... "Being liberal in what you accept" and "being prepared to deal with malformed input" are two different concepts. Back when I was involved with protocol design on ARPAnet, what I was taught is that one has to be able to handle *correctly* malformed input, and not yield astonishing results. This is not easy, particularly in assembler language. Blowing buffer boundaries is just plain crap code. As for malice, I've never seen that. Not checking buffer boundaries, in my experience, is always stupidity or laziness. This is particular true when someone threw together a proof of concept quickly, then didn't go in and harden the code before releasing it to the world. (Some of that was born during the "interop" meetings, where groups of coders would assemble in a conference room and bang implementation together -- because it was done quickly, sometimes it was very sloppy.) From kauer at biplane.com.au Fri Mar 13 13:47:18 2015 From: kauer at biplane.com.au (Karl Auer) Date: Sat, 14 Mar 2015 00:47:18 +1100 Subject: Searching for a quote In-Reply-To: <5502E2A1.90308@satchell.net> References: <5502E2A1.90308@satchell.net> Message-ID: <1426254438.2729.151.camel@karl> On Fri, 2015-03-13 at 06:14 -0700, Stephen Satchell wrote: > what I was taught is that one has to be > able to handle *correctly* malformed input, and not yield astonishing > results. "No program should leave its sanity at the mercy of its input". PJ Plauger, I think. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 From wesley.george at twcable.com Fri Mar 13 14:37:10 2015 From: wesley.george at twcable.com (George, Wes) Date: Fri, 13 Mar 2015 10:37:10 -0400 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> Message-ID: On 3/12/15, 7:48 PM, "Owen DeLong" wrote: > >Then, just like the RFCs, maintain the BCOP appeal numbering as a >sequential monotonically increasing number and make the BCOP editor >responsible for updating the index with the publishing of each new or >revised BCOP. > >Note, IMHO, a revised BCOP should get a new number and the previous >revision should be marked “obsoleted by XXXXX” and it’s document status >should reflect “Obsoletes XXXX, XXXX, and XXXX” for all previous >revisions. The index should probably reflect only BCOPs which have not >been obsoleted A note of caution: Please don't exactly replicate the RFC series's model where the existing document can only be updated by new documents but is not always completely replaced/obsoleted such that the reader is left following the trail of breadcrumbs across multiple documents trying to figure out what the union of the two (or 3 or 14) "current" documents actually means in terms of the complete guidance. If what you're suggesting is actually a full replacement of the document so that the new version is complete and standalone, I think that's better, but really I don't understand why these can't be more living documents (like a Wiki) instead of just using the server as a public dropbox for static files. The higher the drag for getting updates done, the more likely they are to go obsolete and be less useful to the community. 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 asullivan at dyn.com Fri Mar 13 14:52:58 2015 From: asullivan at dyn.com (Andrew Sullivan) Date: Fri, 13 Mar 2015 10:52:58 -0400 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> Message-ID: <20150313145257.GG1207@dyn.com> On Fri, Mar 13, 2015 at 10:37:10AM -0400, George, Wes wrote: > Please don't exactly replicate the RFC series's model where the existing > document can only be updated by new documents but is not always completely > replaced/obsoleted such that the reader is left following the trail of > breadcrumbs across multiple documents trying to figure out what the union > of the two (or 3 or 14) "current" documents actually means in terms of the > complete guidance. I have to agree with this. RFCs are the way they are because they represent an archival series (and even so, probably we could do a better job with this). The whole reasoning to create a completely new series with separate ways of creation was supposedly that the RFC series and BCPs didn't do what the community needed. It seems to me that one of the most important differences in operational guidance is that old operational guidance goes away when it is superseded by changed operational conditions, so there's no reason to keep the old documents around except as historical artifacts. If people want an archive for historians' use, I'm ok with it. But it seems to me that updating a document of the same number (and making them version numbered too) would be more useful. Then you could always refer to "BCOP 1234" for "Carrier Pigeon Operational Practices", and wouldn't need to update references and so on. Best regards, A -- Andrew Sullivan Dyn, Inc. email: asullivan at dyn.com voicemail: +1 603 663 0448 From swhyte at gmail.com Fri Mar 13 15:09:56 2015 From: swhyte at gmail.com (Scott Whyte) Date: Fri, 13 Mar 2015 08:09:56 -0700 Subject: What happened to Schprokits? Message-ID: <5502FDC4.3020204@gmail.com> Schprokits was mentioned at NANOG63 but http://www.schprokits.com/ doesn't look too good. What happened? From cscora at apnic.net Fri Mar 13 18:11:40 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 14 Mar 2015 04:11:40 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201503131811.t2DIBej9025027@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, 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 14 Mar, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 536814 Prefixes after maximum aggregation (per Origin AS): 205071 Deaggregation factor: 2.62 Unique aggregates announced (without unneeded subnets): 261783 Total ASes present in the Internet Routing Table: 49643 Prefixes per ASN: 10.81 Origin-only ASes present in the Internet Routing Table: 36509 Origin ASes announcing only one prefix: 16263 Transit ASes present in the Internet Routing Table: 6268 Transit-only ASes present in the Internet Routing Table: 167 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 59 Max AS path prepend of ASN ( 55644) 56 Prefixes from unregistered ASNs in the Routing Table: 1218 Unregistered ASNs in the Routing Table: 423 Number of 32-bit ASNs allocated by the RIRs: 8853 Number of 32-bit ASNs visible in the Routing Table: 6866 Prefixes from 32-bit ASNs in the Routing Table: 25043 Number of bogon 32-bit ASNs visible in the Routing Table: 2 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 397 Number of addresses announced to Internet: 2734437540 Equivalent to 162 /8s, 252 /16s and 52 /24s Percentage of available address space announced: 73.9 Percentage of allocated address space announced: 73.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.2 Total number of prefixes smaller than registry allocations: 181412 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 132367 Total APNIC prefixes after maximum aggregation: 38507 APNIC Deaggregation factor: 3.44 Prefixes being announced from the APNIC address blocks: 137922 Unique aggregates announced from the APNIC address blocks: 56238 APNIC Region origin ASes present in the Internet Routing Table: 5023 APNIC Prefixes per ASN: 27.46 APNIC Region origin ASes announcing only one prefix: 1205 APNIC Region transit ASes present in the Internet Routing Table: 876 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 59 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1345 Number of APNIC addresses announced to Internet: 746144000 Equivalent to 44 /8s, 121 /16s and 65 /24s Percentage of available APNIC address space announced: 87.2 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-64098, 131072-135580 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: 176974 Total ARIN prefixes after maximum aggregation: 87478 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 178978 Unique aggregates announced from the ARIN address blocks: 84017 ARIN Region origin ASes present in the Internet Routing Table: 16508 ARIN Prefixes per ASN: 10.84 ARIN Region origin ASes announcing only one prefix: 6077 ARIN Region transit ASes present in the Internet Routing Table: 1707 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 370 Number of ARIN addresses announced to Internet: 1062170400 Equivalent to 63 /8s, 79 /16s and 111 /24s Percentage of available ARIN address space announced: 56.2 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: 130480 Total RIPE prefixes after maximum aggregation: 64954 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 136837 Unique aggregates announced from the RIPE address blocks: 84064 RIPE Region origin ASes present in the Internet Routing Table: 17900 RIPE Prefixes per ASN: 7.64 RIPE Region origin ASes announcing only one prefix: 8151 RIPE Region transit ASes present in the Internet Routing Table: 2961 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3502 Number of RIPE addresses announced to Internet: 694120324 Equivalent to 41 /8s, 95 /16s and 111 /24s Percentage of available RIPE address space announced: 100.9 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: 59054 Total LACNIC prefixes after maximum aggregation: 11076 LACNIC Deaggregation factor: 5.33 Prefixes being announced from the LACNIC address blocks: 68874 Unique aggregates announced from the LACNIC address blocks: 31949 LACNIC Region origin ASes present in the Internet Routing Table: 2412 LACNIC Prefixes per ASN: 28.55 LACNIC Region origin ASes announcing only one prefix: 624 LACNIC Region transit ASes present in the Internet Routing Table: 494 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1553 Number of LACNIC addresses announced to Internet: 167914240 Equivalent to 10 /8s, 2 /16s and 43 /24s Percentage of available LACNIC address space announced: 100.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + 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: 12706 Total AfriNIC prefixes after maximum aggregation: 3012 AfriNIC Deaggregation factor: 4.22 Prefixes being announced from the AfriNIC address blocks: 13806 Unique aggregates announced from the AfriNIC address blocks: 5154 AfriNIC Region origin ASes present in the Internet Routing Table: 737 AfriNIC Prefixes per ASN: 18.73 AfriNIC Region origin ASes announcing only one prefix: 206 AfriNIC Region transit ASes present in the Internet Routing Table: 153 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 96 Number of AfriNIC addresses announced to Internet: 63579648 Equivalent to 3 /8s, 202 /16s and 38 /24s Percentage of available AfriNIC address space announced: 63.2 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 2867 11553 910 Korea Telecom 17974 2792 904 78 PT Telekomunikasi Indonesia 7545 2531 336 126 TPG Telecom Limited 4755 1990 422 212 TATA Communications formerly 4538 1760 4190 71 China Education and Research 9829 1693 1326 38 National Internet Backbone 9808 1547 8717 28 Guangdong Mobile Communicatio 4808 1462 2251 439 CNCGROUP IP network China169 9583 1396 115 572 Sify Limited 9498 1307 334 95 BHARTI Airtel Ltd. 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 3012 2955 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 3356 2548 10683 478 Level 3 Communications, Inc. 18566 2041 379 183 MegaPath Corporation 20115 1846 1831 428 Charter Communications 6983 1705 866 245 EarthLink, Inc. 4323 1621 1021 407 tw telecom holdings, inc. 30036 1525 312 500 Mediacom Communications Corp 701 1385 11260 673 MCI Communications Services, 22561 1330 412 241 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 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 1973 303 360 TELLCOM ILETISIM HIZMETLERI A 20940 1634 635 1213 Akamai International B.V. 8402 1375 544 15 OJSC "Vimpelcom" 6849 1212 356 24 JSC "Ukrtelecom" 31148 1046 45 21 Freenet Ltd. 13188 1015 96 70 TOV "Bank-Inform" 8551 903 373 48 Bezeq International-Ltd 12479 877 797 83 France Telecom Espana SA 9198 847 349 25 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 10620 3141 511 211 Telmex Colombia S.A. 28573 2370 2170 117 NET Servi�os de Comunica��o S 7303 1793 1190 233 Telecom Argentina S.A. 6147 1574 374 30 Telefonica del Peru S.A.A. 8151 1550 3127 448 Uninet S.A. de C.V. 6503 1199 421 57 Axtel, S.A.B. de C.V. 7738 1000 1882 41 Telemar Norte Leste S.A. 26615 956 2325 35 Tim Celular S.A. 3816 916 404 150 COLOMBIA TELECOMUNICACIONES S 18881 865 1036 22 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1555 958 13 TE-AS 24863 956 284 26 Link Egypt (Link.NET) 36903 479 241 90 Office National des Postes et 36992 402 1101 31 ETISALAT MISR 37492 321 159 70 Orange Tunisie 24835 299 144 9 Vodafone Data 3741 250 921 209 Internet Solutions 29571 236 21 13 Cote d'Ivoire Telecom 36947 193 712 14 Telecom Algeria 15706 172 32 6 Sudatel (Sudan Telecom Co. Lt 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 10620 3141 511 211 Telmex Colombia S.A. 22773 3012 2955 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 4766 2867 11553 910 Korea Telecom 17974 2792 904 78 PT Telekomunikasi Indonesia 3356 2548 10683 478 Level 3 Communications, Inc. 7545 2531 336 126 TPG Telecom Limited 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2370 2170 117 NET Servi�os de Comunica��o S 18566 2041 379 183 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 22773 3012 2871 Cox Communications Inc. 6389 2891 2840 BellSouth.net Inc. 17974 2792 2714 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 7545 2531 2405 TPG Telecom Limited 28573 2370 2253 NET Servi�os de Comunica��o S 3356 2548 2070 Level 3 Communications, Inc. 4766 2867 1957 Korea Telecom 18566 2041 1858 MegaPath Corporation 4755 1990 1778 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 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 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 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 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 Bitfinite LLC 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.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.15.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:12 /10:34 /11:92 /12:264 /13:505 /14:1000 /15:1720 /16:12968 /17:7176 /18:12201 /19:25182 /20:35743 /21:38593 /22:58319 /23:50742 /24:289304 /25:1080 /26:1148 /27:664 /28:17 /29:13 /30:8 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2226 3012 Cox Communications Inc. 18566 1996 2041 MegaPath Corporation 6389 1671 2891 BellSouth.net Inc. 30036 1371 1525 Mediacom Communications Corp 6983 1352 1705 EarthLink, Inc. 34984 1280 1973 TELLCOM ILETISIM HIZMETLERI A 6147 1121 1574 Telefonica del Peru S.A.A. 11492 1120 1184 CABLE ONE, INC. 10620 1108 3141 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:1531 2:675 3:1 4:94 5:1745 6:21 8:1427 12:1827 13:4 14:1309 15:17 16:2 17:42 18:21 20:49 23:1191 24:1677 27:1851 31:1498 32:39 33:2 34:5 35:3 36:118 37:1874 38:1012 39:9 40:237 41:3008 42:259 43:1174 44:26 45:273 46:2174 47:35 48:2 49:795 50:791 52:12 54:69 55:5 56:8 57:37 58:1203 59:685 60:465 61:1775 62:1320 63:1907 64:4458 65:2269 66:4117 67:2050 68:1078 69:3264 70:951 71:441 72:1958 74:2603 75:318 76:405 77:1495 78:1269 79:802 80:1321 81:1352 82:817 83:671 84:686 85:1352 86:391 87:1062 88:515 89:1766 90:151 91:5950 92:803 93:2182 94:2005 95:2112 96:426 97:341 98:1072 99:45 100:73 101:810 102:1 103:6960 104:1394 105:63 106:223 107:897 108:609 109:2000 110:1077 111:1470 112:755 113:1038 114:836 115:1252 116:1344 117:1009 118:1683 119:1444 120:444 121:1029 122:2186 123:1728 124:1487 125:1577 128:637 129:381 130:381 131:1163 132:488 133:168 134:412 135:99 136:336 137:298 138:539 139:176 140:235 141:419 142:637 143:468 144:554 145:109 146:706 147:588 148:1104 149:463 150:561 151:610 152:490 153:239 154:392 155:736 156:405 157:331 158:264 159:976 160:373 161:624 162:1929 163:387 164:664 165:662 166:324 167:691 168:1275 169:149 170:1460 171:232 172:43 173:1522 174:700 175:652 176:1431 177:3798 178:2073 179:880 180:1899 181:1635 182:1733 183:622 184:736 185:3085 186:2679 187:1829 188:1972 189:1578 190:7636 191:957 192:8171 193:5591 194:4093 195:3649 196:1706 197:1025 198:5514 199:5520 200:6550 201:3039 202:9488 203:9066 204:4618 205:2742 206:2995 207:3003 208:3948 209:3920 210:3518 211:1860 212:2493 213:2248 214:876 215:69 216:5535 217:1808 218:674 219:467 220:1421 221:788 222:466 223:657 End of report From rick.casarez at gmail.com Fri Mar 13 12:10:06 2015 From: rick.casarez at gmail.com (Rick Casarez) Date: Fri, 13 Mar 2015 08:10:06 -0400 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> Message-ID: I like the idea of an index better than the proposed numbering scheme. ------------------- Cheers, Rick Experiences not things. On Thu, Mar 12, 2015 at 7:48 PM, Owen DeLong wrote: > > > On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes > wrote: > > > > > > > > Hello NANOGers, > > > > The NANOG BCOP committee is currently considering strategies on how to > best create a numbering scheme for the BCOP appeals. As we all know, most > public technical references (IETF, etc) have numbers to clarify references. > The goal is for NANOG BCOPs to follow some sort of same style. > > > > The BCOP committee is looking for feedback and comments on this topic. > > > > Currently, the below numbering scheme is being considered: > > > > A proposed numbering scheme can be based on how the appeals appeals in > the BCOP topics are presented as shown below: > > > > http://bcop.nanog.org/index.php/Appeals > > > > In the above page, the idea is to introduce a 100-th range for each > category and as the BCOPs. This way a 100th number range generally > identifies each of the categories we currently have. An example is: > > > > BCP Range Area of Practice > > 100 - 199 EBGPs > > 200 - 299 IGPs > > 300 - 399 Ethernet > > 400 - 499 Class of Service > > 500 - 599 Network Information Processing > > 600 - 699 Security > > 700 - 799 MPLS > > 800 - 899 Generalized > > > > An arguable objection could be that the range is limited...but a > counter-argument is that considering more than 100 BCOPs would be either a > great success or just a sign of failure for the NANOG community ... > > > > Comments or Thoughts ? > > The problem with any such numbering scheme is how you handle the situation > when you exhaust the avaialble number space. What happens with the 101st > EBGP BCOP, for example? > > I also agree with Joel’s comment about identifier/locator overload. Have > we learned nothing from the issues created by doing this in IPv4 and IPv6? > > Instead, how about maintaining a BCOP subject index which contains titular > and numeric information for each BCOP applicable to the subjects above. > > e.g.: > > BCOP Subject Index: > > Subjects: > 1. EBGP > 2. IGP > 3. Ethernet > 4. Class of Service > 5. Network Information Processing > 6. Security > 7. MPLS > 8. Generalized > > > 1. EBGP > 104 lorem ipsum > 423 ipsum lorem > > > > Then, just like the RFCs, maintain the BCOP appeal numbering as a > sequential monotonically increasing number and make the BCOP editor > responsible for updating the index with the publishing of each new or > revised BCOP. > > Note, IMHO, a revised BCOP should get a new number and the previous > revision should be marked “obsoleted by XXXXX” and it’s document status > should reflect “Obsoletes XXXX, XXXX, and XXXX” for all previous revisions. > The index should probably reflect only BCOPs which have not been obsoleted. > > Just my $0.02. > > Owen > > From me+nanog at bronwynlewis.com Fri Mar 13 18:17:07 2015 From: me+nanog at bronwynlewis.com (Bronwyn Lewis) Date: Fri, 13 Mar 2015 11:17:07 -0700 Subject: What happened to Schprokits? In-Reply-To: <5502FDC4.3020204@gmail.com> References: <5502FDC4.3020204@gmail.com> Message-ID: That's news to me, and quite a bummer. Trying to confirm on twitter now - but it looks like other folks have also asked about it in the past week, but haven't gotten an answer. So I'm assuming it is dead. Guess it's Ansible + homegrown solutions for now. On Fri, Mar 13, 2015 at 8:09 AM, Scott Whyte wrote: > Schprokits was mentioned at NANOG63 but http://www.schprokits.com/ > doesn't look too good. > > What happened? > From mel at beckman.org Fri Mar 13 18:26:46 2015 From: mel at beckman.org (Mel Beckman) Date: Fri, 13 Mar 2015 18:26:46 +0000 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com>, Message-ID: <8BCF27B8-FB61-4244-AB5B-869BDE86BD9E@beckman.org> The index scheme has worked very well with RFCs, and has the added advantage of their index numbers becoming handy memes. I strongly urge Nanog to take advantage of the RFC system's success. There is no shortage of monotonically ascending integers :) -mel beckman > On Mar 13, 2015, at 11:19 AM, "Rick Casarez" wrote: > > I like the idea of an index better than the proposed numbering scheme. > > ------------------- > Cheers, Rick > > Experiences not things. > >> On Thu, Mar 12, 2015 at 7:48 PM, Owen DeLong wrote: >> >> >>>> On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes >>> wrote: >>> >>> >>> >>> Hello NANOGers, >>> >>> The NANOG BCOP committee is currently considering strategies on how to >> best create a numbering scheme for the BCOP appeals. As we all know, most >> public technical references (IETF, etc) have numbers to clarify references. >> The goal is for NANOG BCOPs to follow some sort of same style. >>> >>> The BCOP committee is looking for feedback and comments on this topic. >>> >>> Currently, the below numbering scheme is being considered: >>> >>> A proposed numbering scheme can be based on how the appeals appeals in >> the BCOP topics are presented as shown below: >>> >>> http://bcop.nanog.org/index.php/Appeals >>> >>> In the above page, the idea is to introduce a 100-th range for each >> category and as the BCOPs. This way a 100th number range generally >> identifies each of the categories we currently have. An example is: >>> >>> BCP Range Area of Practice >>> 100 - 199 EBGPs >>> 200 - 299 IGPs >>> 300 - 399 Ethernet >>> 400 - 499 Class of Service >>> 500 - 599 Network Information Processing >>> 600 - 699 Security >>> 700 - 799 MPLS >>> 800 - 899 Generalized >>> >>> An arguable objection could be that the range is limited...but a >> counter-argument is that considering more than 100 BCOPs would be either a >> great success or just a sign of failure for the NANOG community ... >>> >>> Comments or Thoughts ? >> >> The problem with any such numbering scheme is how you handle the situation >> when you exhaust the avaialble number space. What happens with the 101st >> EBGP BCOP, for example? >> >> I also agree with Joel’s comment about identifier/locator overload. Have >> we learned nothing from the issues created by doing this in IPv4 and IPv6? >> >> Instead, how about maintaining a BCOP subject index which contains titular >> and numeric information for each BCOP applicable to the subjects above. >> >> e.g.: >> >> BCOP Subject Index: >> >> Subjects: >> 1. EBGP >> 2. IGP >> 3. Ethernet >> 4. Class of Service >> 5. Network Information Processing >> 6. Security >> 7. MPLS >> 8. Generalized >> >> >> 1. EBGP >> 104 lorem ipsum >> 423 ipsum lorem >> >> >> >> Then, just like the RFCs, maintain the BCOP appeal numbering as a >> sequential monotonically increasing number and make the BCOP editor >> responsible for updating the index with the publishing of each new or >> revised BCOP. >> >> Note, IMHO, a revised BCOP should get a new number and the previous >> revision should be marked “obsoleted by XXXXX” and it’s document status >> should reflect “Obsoletes XXXX, XXXX, and XXXX” for all previous revisions. >> The index should probably reflect only BCOPs which have not been obsoleted. >> >> Just my $0.02. >> >> Owen >> >> From Adrian.Beaudin at nominum.com Fri Mar 13 18:25:44 2015 From: Adrian.Beaudin at nominum.com (Adrian Beaudin) Date: Fri, 13 Mar 2015 18:25:44 +0000 Subject: What happened to Schprokits? In-Reply-To: <5502FDC4.3020204@gmail.com> References: <5502FDC4.3020204@gmail.com> Message-ID: <72A66234DA8FA043BFD0CCE68931420A5354F0FB@MBX-02.WIN.NOMINUM.COM> it looks like (according to linkedin) that Jeremy has moved to a stealth startup. -a Adrian Beaudin Principal Architect, Special Projects Nominum, Inc. o: +1.650.587.1513 adrian.beaudin at nominum.com ________________________________________ From: NANOG [nanog-bounces at nanog.org] on behalf of Scott Whyte [swhyte at gmail.com] Sent: Friday, March 13, 2015 11:09 AM To: nanog at nanog.org Subject: What happened to Schprokits? Schprokits was mentioned at NANOG63 but http://www.schprokits.com/ doesn't look too good. What happened? From snoble at sonn.com Fri Mar 13 18:36:06 2015 From: snoble at sonn.com (Steve Noble) Date: Fri, 13 Mar 2015 11:36:06 -0700 Subject: What happened to Schprokits? In-Reply-To: <72A66234DA8FA043BFD0CCE68931420A5354F0FB@MBX-02.WIN.NOMINUM.COM> References: <5502FDC4.3020204@gmail.com> <72A66234DA8FA043BFD0CCE68931420A5354F0FB@MBX-02.WIN.NOMINUM.COM> Message-ID: There are other stealth companies the space. I still see activity on Twitter (favorites, etc) so I he is still active. We will see good things in the space. On Mar 13, 2015 11:31 AM, "Adrian Beaudin" wrote: > it looks like (according to linkedin) that Jeremy has moved to a stealth > startup. > > -a > > > Adrian Beaudin > Principal Architect, Special Projects > Nominum, Inc. > o: +1.650.587.1513 > adrian.beaudin at nominum.com > > > > ________________________________________ > From: NANOG [nanog-bounces at nanog.org] on behalf of Scott Whyte [ > swhyte at gmail.com] > Sent: Friday, March 13, 2015 11:09 AM > To: nanog at nanog.org > Subject: What happened to Schprokits? > > Schprokits was mentioned at NANOG63 but http://www.schprokits.com/ > doesn't look too good. > > What happened? > From alec.muffett at gmail.com Fri Mar 13 18:46:31 2015 From: alec.muffett at gmail.com (Alec Muffett) Date: Fri, 13 Mar 2015 18:46:31 +0000 Subject: Friday Fun: UK Government (Dept of Work & Pensions) selling off an entire "/8" Message-ID: Perhaps I'm odd, but I find the novelty of this to be amusing: IPv4 Market Group Announces the Availability of a Significant Portfolio of > IPv4 Addresses for Purchase in the RIPE Region: > > IPv4 Market Group, a global leader in IPv4 sales, has just announced the > availability of up to 2.6 million top quality IPv4 addresses for purchase > in the RIPE region. The firm’s Executive Vice President for Business > Development, Jeff Mehlenbacher, said that the IPv4 blocks are being offered > in multiples of /16, with up to 7 contiguous /16’s and 40 /16’s in total > IPs. ...deletia... http://ipv4marketgroup.com/ipv4-addresses-ripe-region/ It's related to this blogpost: https://governmenttechnology.blog.gov.uk/2015/02/19/freeing-up-unused-ip-addresses/ ...and I gather that perhaps - although it's currently being marketed as a bunch of /16s - they might also entertain the possibility of selling it as an entire /8 for a reasonable price. I'm wondering: have we passed the point of peak IPv4 scarcity? Is selling an entire /8 still a viable proposition? Apparently UK Gov may have more than one... - alec -- http://dropsafe.crypticide.com/aboutalecm From rcarpen at network1.net Fri Mar 13 19:04:08 2015 From: rcarpen at network1.net (Randy Carpenter) Date: Fri, 13 Mar 2015 15:04:08 -0400 (EDT) Subject: Friday Fun: UK Government (Dept of Work & Pensions) selling off an entire "/8" In-Reply-To: References: Message-ID: <752889305.656541.1426273448671.JavaMail.zimbra@network1.net> "Top Quality" ? Are they aged longer in special barrels? Polished extra nicely? (Ouch, I think I injured my eyes from the rolling) thanks, -Randy ----- On Mar 13, 2015, at 2:46 PM, Alec Muffett alec.muffett at gmail.com wrote: > Perhaps I'm odd, but I find the novelty of this to be amusing: > > IPv4 Market Group Announces the Availability of a Significant Portfolio of >> IPv4 Addresses for Purchase in the RIPE Region: >> > > >> IPv4 Market Group, a global leader in IPv4 sales, has just announced the >> availability of up to 2.6 million top quality IPv4 addresses for purchase >> in the RIPE region. The firm’s Executive Vice President for Business >> Development, Jeff Mehlenbacher, said that the IPv4 blocks are being offered >> in multiples of /16, with up to 7 contiguous /16’s and 40 /16’s in total >> IPs. > > > ...deletia... > > http://ipv4marketgroup.com/ipv4-addresses-ripe-region/ > > > It's related to this blogpost: > > https://governmenttechnology.blog.gov.uk/2015/02/19/freeing-up-unused-ip-addresses/ > > > ...and I gather that perhaps - although it's currently being marketed as a > bunch of /16s - they might also entertain the possibility of selling it as > an entire /8 for a reasonable price. > > I'm wondering: have we passed the point of peak IPv4 scarcity? Is selling > an entire /8 still a viable proposition? Apparently UK Gov may have more > than one... > > - alec > > -- > http://dropsafe.crypticide.com/aboutalecm From cdel at firsthand.net Fri Mar 13 19:10:49 2015 From: cdel at firsthand.net (Christian de Larrinaga) Date: Fri, 13 Mar 2015 19:10:49 +0000 Subject: Friday Fun: UK Government (Dept of Work & Pensions) selling off an entire "/8" In-Reply-To: <752889305.656541.1426273448671.JavaMail.zimbra@network1.net> References: <752889305.656541.1426273448671.JavaMail.zimbra@network1.net> Message-ID: <55033639.8020303@firsthand.net> unrouted addresses I expect .... What with their CTO declaring no need for IPv6 last June I do wonder if the Government is in the driving seat of its network policy. It'll be a'rolling in the aisles when HMG wakes up to find they've flogged their v4 and can't deploy v6 and are to be stuck behind a nice vendor's CGNAT policies for the duration. But they love silos. Christian Randy Carpenter wrote: > "Top Quality" ? > > Are they aged longer in special barrels? Polished extra nicely? > > (Ouch, I think I injured my eyes from the rolling) > > thanks, > -Randy > > ----- On Mar 13, 2015, at 2:46 PM, Alec Muffett alec.muffett at gmail.com wrote: > >> Perhaps I'm odd, but I find the novelty of this to be amusing: >> >> IPv4 Market Group Announces the Availability of a Significant Portfolio of >>> IPv4 Addresses for Purchase in the RIPE Region: >>> >> >>> IPv4 Market Group, a global leader in IPv4 sales, has just announced the >>> availability of up to 2.6 million top quality IPv4 addresses for purchase >>> in the RIPE region. The firm’s Executive Vice President for Business >>> Development, Jeff Mehlenbacher, said that the IPv4 blocks are being offered >>> in multiples of /16, with up to 7 contiguous /16’s and 40 /16’s in total >>> IPs. >> >> ...deletia... >> >> http://ipv4marketgroup.com/ipv4-addresses-ripe-region/ >> >> >> It's related to this blogpost: >> >> https://governmenttechnology.blog.gov.uk/2015/02/19/freeing-up-unused-ip-addresses/ >> >> >> ...and I gather that perhaps - although it's currently being marketed as a >> bunch of /16s - they might also entertain the possibility of selling it as >> an entire /8 for a reasonable price. >> >> I'm wondering: have we passed the point of peak IPv4 scarcity? Is selling >> an entire /8 still a viable proposition? Apparently UK Gov may have more >> than one... >> >> - alec >> >> -- >> http://dropsafe.crypticide.com/aboutalecm -- Christian de Larrinaga FBCS, CITP, MCMA ------------------------- @ FirstHand ------------------------- +44 7989 386778 cdel at firsthand.net ------------------------- From Valdis.Kletnieks at vt.edu Fri Mar 13 19:30:14 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 13 Mar 2015 15:30:14 -0400 Subject: Friday Fun: UK Government (Dept of Work & Pensions) selling off an entire "/8" In-Reply-To: Your message of "Fri, 13 Mar 2015 18:46:31 -0000." References: Message-ID: <4288.1426275014@turing-police.cc.vt.edu> On Fri, 13 Mar 2015 18:46:31 -0000, Alec Muffett said: > > IPv4 Market Group, a global leader in IPv4 sales, has just announced the > > availability of up to 2.6 million top quality IPv4 addresses for purchase "top quality"? Well... Yeah. They've probably had no chance to end up in any reputation filters. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Lee at asgard.org Fri Mar 13 19:50:03 2015 From: Lee at asgard.org (Lee Howard) Date: Fri, 13 Mar 2015 15:50:03 -0400 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: <8BCF27B8-FB61-4244-AB5B-869BDE86BD9E@beckman.org> References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> <8BCF27B8-FB61-4244-AB5B-869BDE86BD9E@beckman.org> Message-ID: I think the RFC numbering system is a terrible scheme. As Wes described, you have a document purporting to describe something, with no indicator that parts of it have been rendered obsolete by parts of other documents. I pity implementors who have to figure it all out. I also agree with Joel, that assigning meaning to index numbers is a bad idea. It leads to crossed indexes and unclear references. For the documents to be useful, one should be able to read a single document on a topic. When that topic is too big for a single document, split the document. When something in one document supersedes something in another, confirm consensus and update the canonical document. If that's too dynamic for people, then maintain the index, and when part of a document is obsoleted, the entire updated document should be republished with a new number, and the old one marked "obsoleted by XXXX." Under no circumstances would I support a limited number space. Lee On 3/13/15 2:26 PM, "Mel Beckman" wrote: >The index scheme has worked very well with RFCs, and has the added >advantage of their index numbers becoming handy memes. I strongly urge >Nanog to take advantage of the RFC system's success. There is no shortage >of monotonically ascending integers :) > > -mel beckman > >> On Mar 13, 2015, at 11:19 AM, "Rick Casarez" >>wrote: >> >> I like the idea of an index better than the proposed numbering scheme. >> >> ------------------- >> Cheers, Rick >> >> Experiences not things. >> >>> On Thu, Mar 12, 2015 at 7:48 PM, Owen DeLong wrote: >>> >>> >>>>> On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes >>>> wrote: >>>> >>>> >>>> >>>> Hello NANOGers, >>>> >>>> The NANOG BCOP committee is currently considering strategies on how >>>>to >>> best create a numbering scheme for the BCOP appeals. As we all know, >>>most >>> public technical references (IETF, etc) have numbers to clarify >>>references. >>> The goal is for NANOG BCOPs to follow some sort of same style. >>>> >>>> The BCOP committee is looking for feedback and comments on this topic. >>>> >>>> Currently, the below numbering scheme is being considered: >>>> >>>> A proposed numbering scheme can be based on how the appeals appeals in >>> the BCOP topics are presented as shown below: >>>> >>>> http://bcop.nanog.org/index.php/Appeals >>>> >>>> In the above page, the idea is to introduce a 100-th range for each >>> category and as the BCOPs. This way a 100th number range generally >>> identifies each of the categories we currently have. An example is: >>>> >>>> BCP Range Area of Practice >>>> 100 - 199 EBGPs >>>> 200 - 299 IGPs >>>> 300 - 399 Ethernet >>>> 400 - 499 Class of Service >>>> 500 - 599 Network Information Processing >>>> 600 - 699 Security >>>> 700 - 799 MPLS >>>> 800 - 899 Generalized >>>> >>>> An arguable objection could be that the range is limited...but a >>> counter-argument is that considering more than 100 BCOPs would be >>>either a >>> great success or just a sign of failure for the NANOG community ... >>>> >>>> Comments or Thoughts ? >>> >>> The problem with any such numbering scheme is how you handle the >>>situation >>> when you exhaust the avaialble number space. What happens with the >>>101st >>> EBGP BCOP, for example? >>> >>> I also agree with Joel¹s comment about identifier/locator overload. >>>Have >>> we learned nothing from the issues created by doing this in IPv4 and >>>IPv6? >>> >>> Instead, how about maintaining a BCOP subject index which contains >>>titular >>> and numeric information for each BCOP applicable to the subjects above. >>> >>> e.g.: >>> >>> BCOP Subject Index: >>> >>> Subjects: >>> 1. EBGP >>> 2. IGP >>> 3. Ethernet >>> 4. Class of Service >>> 5. Network Information Processing >>> 6. Security >>> 7. MPLS >>> 8. Generalized >>> >>> >>> 1. EBGP >>> 104 lorem ipsum >>> 423 ipsum lorem >>> >>> >>> >>> Then, just like the RFCs, maintain the BCOP appeal numbering as a >>> sequential monotonically increasing number and make the BCOP editor >>> responsible for updating the index with the publishing of each new or >>> revised BCOP. >>> >>> Note, IMHO, a revised BCOP should get a new number and the previous >>> revision should be marked ³obsoleted by XXXXX² and it¹s document status >>> should reflect ³Obsoletes XXXX, XXXX, and XXXX² for all previous >>>revisions. >>> The index should probably reflect only BCOPs which have not been >>>obsoleted. >>> >>> Just my $0.02. >>> >>> Owen >>> >>> > From cb.list6 at gmail.com Fri Mar 13 19:53:11 2015 From: cb.list6 at gmail.com (Ca By) Date: Fri, 13 Mar 2015 12:53:11 -0700 Subject: Friday Fun: UK Government (Dept of Work & Pensions) selling off an entire "/8" In-Reply-To: <4288.1426275014@turing-police.cc.vt.edu> References: <4288.1426275014@turing-police.cc.vt.edu> Message-ID: On Fri, Mar 13, 2015 at 12:30 PM, wrote: > On Fri, 13 Mar 2015 18:46:31 -0000, Alec Muffett said: > > > > IPv4 Market Group, a global leader in IPv4 sales, has just announced > the > > > availability of up to 2.6 million top quality IPv4 addresses for > purchase > > "top quality"? > > Well... Yeah. They've probably had no chance to end up in any reputation > filters. > One may find that these dark /8s have been co-opted by large networks for private use. That said, these dark /8s and their sub-blocks may have long lasting reach-ability issues that the purchaser may not enjoy. Not saying anything is right or wrong, just saying .... like 1.1.1.0/24, there may reach-ability issues deep in 3rd party networks with these "bottom of the barrel" legacy ipv4 blocks that have been seen as "fair game for squatting on", in some circles, for many years. Caveat emptor / Deploy IPv6 CB From jmaslak at antelope.net Fri Mar 13 19:56:12 2015 From: jmaslak at antelope.net (Joel Maslak) Date: Fri, 13 Mar 2015 13:56:12 -0600 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> Message-ID: You'll get more comments about the numbering scheme than any actual BCOP... On Thu, Mar 12, 2015 at 1:01 PM, Yardiel D. Fuentes wrote: > > > Hello NANOGers, > > The NANOG BCOP committee is currently considering strategies on how to > best create a numbering scheme for the BCOP appeals. As we all know, most > public technical references (IETF, etc) have numbers to clarify references. > The goal is for NANOG BCOPs to follow some sort of same style. > > The BCOP committee is looking for feedback and comments on this topic. > > Currently, the below numbering scheme is being considered: > > A proposed numbering scheme can be based on how the appeals appeals in the > BCOP topics are presented as shown below: > > http://bcop.nanog.org/index.php/Appeals > > In the above page, the idea is to introduce a 100-th range for each > category and as the BCOPs. This way a 100th number range generally > identifies each of the categories we currently have. An example is: > > BCP Range Area of Practice > 100 - 199 EBGPs > 200 - 299 IGPs > 300 - 399 Ethernet > 400 - 499 Class of Service > 500 - 599 Network Information Processing > 600 - 699 Security > 700 - 799 MPLS > 800 - 899 Generalized > > An arguable objection could be that the range is limited...but a > counter-argument is that considering more than 100 BCOPs would be either a > great success or just a sign of failure for the NANOG community ... > > Comments or Thoughts ? > > > Yardiel Fuentes > > > > > > From morrowc.lists at gmail.com Fri Mar 13 20:23:02 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 13 Mar 2015 16:23:02 -0400 Subject: Friday Fun: UK Government (Dept of Work & Pensions) selling off an entire "/8" In-Reply-To: <4288.1426275014@turing-police.cc.vt.edu> References: <4288.1426275014@turing-police.cc.vt.edu> Message-ID: On Fri, Mar 13, 2015 at 3:30 PM, wrote: > On Fri, 13 Mar 2015 18:46:31 -0000, Alec Muffett said: > >> > IPv4 Market Group, a global leader in IPv4 sales, has just announced the >> > availability of up to 2.6 million top quality IPv4 addresses for purchase > > "top quality"? Graded by the Boffins. > Well... Yeah. They've probably had no chance to end up in any reputation > filters. From alec.muffett at gmail.com Fri Mar 13 20:56:48 2015 From: alec.muffett at gmail.com (Alec Muffett) Date: Fri, 13 Mar 2015 20:56:48 +0000 Subject: Friday Fun: UK Government (Dept of Work & Pensions) selling off an entire "/8" In-Reply-To: References: <4288.1426275014@turing-police.cc.vt.edu> Message-ID: Colour me surprised that so many people are talking about the marketing schtick (or: "woe betide the seller for unspecified reasons") - and not the opportunity... but so be it. Digging around on the web I've found: http://blog.jgc.org/2012/09/the-uk-has-entire-unused-ipv4-8-that-is.html ...which suggests that it's 51.0.0.0/8 that is up for grabs. I remember a few years ago there being a bunch of "countdown to doomsday"-type blogposts and articles re: the underadoption of IPv6 and the expected fatal pressure on the declining resource of IPv4; now I'm seeing a lot of 6 in mobile, loads of NAT, and folk seem far less petrified of the future? -a On 13 March 2015 at 20:23, Christopher Morrow wrote: > On Fri, Mar 13, 2015 at 3:30 PM, wrote: > > On Fri, 13 Mar 2015 18:46:31 -0000, Alec Muffett said: > > > >> > IPv4 Market Group, a global leader in IPv4 sales, has just announced > the > >> > availability of up to 2.6 million top quality IPv4 addresses for > purchase > > > > "top quality"? > > Graded by the Boffins. > > > Well... Yeah. They've probably had no chance to end up in any reputation > > filters. > -- http://dropsafe.crypticide.com/aboutalecm From cidr-report at potaroo.net Fri Mar 13 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Mar 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201503132200.t2DM00HY041228@wattle.apnic.net> This report has been generated at Fri Mar 13 21:14:30 2015 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 06-03-15 543091 299481 07-03-15 543037 299657 08-03-15 543201 299673 09-03-15 543424 299454 10-03-15 543046 299662 11-03-15 543332 299804 12-03-15 543235 300009 13-03-15 544187 299901 AS Summary 49884 Number of ASes in routing system 19904 Number of ASes announcing only one prefix 3141 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120417792 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'). --- 13Mar15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 544299 299966 244333 44.9% All ASes AS22773 3013 171 2842 94.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2891 120 2771 95.8% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2808 78 2730 97.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2473 12 2461 99.5% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2365 317 2048 86.6% NET Servi�os de Comunica��o S.A.,BR AS3356 2551 730 1821 71.4% LEVEL3 - Level 3 Communications, Inc.,US AS4766 2868 1318 1550 54.0% KIXS-AS-KR Korea Telecom,KR AS7303 1793 283 1510 84.2% Telecom Argentina S.A.,AR AS9808 1547 67 1480 95.7% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS6983 1703 248 1455 85.4% ITCDELTA - Earthlink, Inc.,US AS6147 1574 158 1416 90.0% Telefonica del Peru S.A.A.,PE AS4755 1988 595 1393 70.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS10620 3141 1751 1390 44.3% Telmex Colombia S.A.,CO AS20115 1847 500 1347 72.9% CHARTER-NET-HKY-NC - Charter Communications,US AS8402 1356 25 1331 98.2% CORBINA-AS OJSC "Vimpelcom",RU AS7545 2549 1224 1325 52.0% TPG-INTERNET-AP TPG Telecom Limited,AU AS4323 1628 408 1220 74.9% TWTC - tw telecom holdings, inc.,US AS9498 1306 111 1195 91.5% BBIL-AP BHARTI Airtel Ltd.,IN AS8452 1771 591 1180 66.6% TE-AS TE-AS,EG AS18566 2040 869 1171 57.4% MEGAPATH5-US - MegaPath Corporation,US AS7552 1153 58 1095 95.0% VIETEL-AS-AP Viettel Corporation,VN AS34984 1972 902 1070 54.3% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS22561 1330 358 972 73.1% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS6849 1209 247 962 79.6% UKRTELNET JSC UKRTELECOM,UA AS7738 999 83 916 91.7% Telemar Norte Leste S.A.,BR AS38285 983 115 868 88.3% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS4538 1778 957 821 46.2% ERX-CERNET-BKB China Education and Research Network Center,CN AS4780 1114 302 812 72.9% SEEDNET Digital United Inc.,TW AS26615 957 145 812 84.8% Tim Celular S.A.,BR AS18101 1000 205 795 79.5% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN Total 55707 12948 42759 76.8% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.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.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.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 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 64.25.16.0/23 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.20.0/24 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.21.0/24 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.22.0/24 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.24.0/23 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 AS19535 - JetBlue Airways Corporation,US 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 64.140.128.0/18 AS7385 INTEGRATELECOM - Integra Telecom, 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.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 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 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 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.114.184.0/22 AS19888 -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.91.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 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 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.230.27.0/24 AS57022 -Reserved AS-,ZZ 96.125.144.0/20 AS22400 SIMPLELINK - SimpleLink LLC,US 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 100.42.176.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc.,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.20.100.0/24 AS23937 103.20.101.0/24 AS23937 103.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.224.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.247.19.0/24 AS18107 ASN-IPSYSTEMS-AP IP SYSTEMS,AU 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 103.253.164.0/23 AS13317 103.255.56.0/22 AS18097 DCN D.C.N. Corporation,JP 103.255.132.0/22 AS18097 DCN D.C.N. Corporation,JP 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 113.197.106.0/24 AS15169 GOOGLE - Google Inc.,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.54.184.0/21 AS59092 KRONOS kronos.Co.,Ltd.,JP 121.200.216.0/21 AS59092 KRONOS kronos.Co.,Ltd.,JP 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 151.216.128.0/17 AS50304 BLIX Blix Solutions AS,NO 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 167.146.16.0/21 AS22527 -Reserved AS-,ZZ 167.146.26.0/23 AS22527 -Reserved AS-,ZZ 167.146.28.0/23 AS22527 -Reserved AS-,ZZ 167.146.32.0/20 AS22527 -Reserved AS-,ZZ 167.146.44.0/24 AS22527 -Reserved AS-,ZZ 167.146.48.0/22 AS22527 -Reserved AS-,ZZ 167.146.90.0/24 AS22527 -Reserved AS-,ZZ 167.146.93.0/24 AS22527 -Reserved AS-,ZZ 167.146.94.0/24 AS22527 -Reserved AS-,ZZ 167.146.100.0/24 AS22527 -Reserved AS-,ZZ 167.146.104.0/24 AS22527 -Reserved AS-,ZZ 167.146.105.0/24 AS22527 -Reserved AS-,ZZ 167.146.128.0/20 AS22527 -Reserved AS-,ZZ 167.146.137.0/24 AS22527 -Reserved AS-,ZZ 167.146.144.0/20 AS22527 -Reserved AS-,ZZ 167.146.160.0/20 AS22527 -Reserved AS-,ZZ 167.146.200.0/22 AS22527 -Reserved AS-,ZZ 167.146.204.0/24 AS22527 -Reserved AS-,ZZ 167.146.205.0/24 AS22527 -Reserved AS-,ZZ 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 173.224.128.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc.,US 182.237.25.0/24 AS10201 DWL-AS-IN Dishnet Wireless Limited. Broadband Wireless,IN 185.91.196.0/22 AS19671 TNETKOM-AS Thueringer Netkom GmbH,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,FR 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.104.159.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC,US 192.107.133.0/24 AS13768 PEER1 - Peer 1 Network (USA) Inc.,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.155.48.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,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 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.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.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age 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.176.147.0/24 AS49951 -Reserved AS-,ZZ 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 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.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS 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.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.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,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.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.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 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 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 198.17.20.0/24 AS1612 FLUXTEL - Flux Telecom, LLC,US 198.17.21.0/24 AS1612 FLUXTEL - Flux Telecom, LLC,US 198.17.22.0/24 AS1612 FLUXTEL - Flux Telecom, LLC,US 198.17.23.0/24 AS1612 FLUXTEL - Flux Telecom, LLC,US 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 198.73.226.0/23 AS62839 -Reserved AS-,ZZ 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.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 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.30.136.0/23 AS46636 NATCOWEB - NatCoWeb Corp.,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.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 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.201.64.0/22 AS54115 -Reserved AS-,ZZ 199.201.66.0/24 AS54115 -Reserved AS-,ZZ 199.204.144.0/21 AS36007 -Reserved AS-,ZZ 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 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 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 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.122.134.0/24 AS38615 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 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.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.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.155.28.0/22 AS14576 HOSTING-SOLUTIONS - Hosting Solution Ltd.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 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.189.0.0/19 AS46879 -Reserved AS-,ZZ 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.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.83.88.0/22 AS15697 BT-BS BT Ignite Intercontinental Satellite Video Streaming,GB 208.83.90.0/23 AS15697 BT-BS BT Ignite Intercontinental Satellite Video Streaming,GB 208.83.91.0/24 AS12910 -Reserved AS-,ZZ 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.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.93.216.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 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 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,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.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,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.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 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 Mar 13 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Mar 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201503132200.t2DM01S9041239@wattle.apnic.net> BGP Update Report Interval: 05-Mar-15 -to- 12-Mar-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS61894 227643 5.2% 56910.8 -- FreeBSD Brasil LTDA,BR 2 - AS23752 220856 5.0% 2629.2 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - AS9829 128125 2.9% 104.8 -- BSNL-NIB National Internet Backbone,IN 4 - AS46230 101249 2.3% 4821.4 -- DUDROP - Dignitas Technology Inc,US 5 - AS36947 94280 2.1% 827.0 -- ALGTEL-AS,DZ 6 - AS2734 91622 2.1% 5389.5 -- CORESITE - CoreSite,US 7 - AS42081 72726 1.7% 2909.0 -- SPEEDY-NET-AS Speedy net EAD,BG 8 - AS10620 68933 1.6% 30.4 -- Telmex Colombia S.A.,CO 9 - AS56426 63222 1.4% 9031.7 -- ASVOLNA-NET CJSC "VOLNA-SERVIS",RU 10 - AS53563 47218 1.1% 15739.3 -- XPLUSONE - X Plus One Solutions, Inc.,US 11 - AS13118 42606 1.0% 1065.2 -- ASN-YARTELECOM OJSC Rostelecom,RU 12 - AS33529 40465 0.9% 4496.1 -- PEAK-WEB-HOSTING - Peak Web Hosting Inc.,US 13 - AS37054 32217 0.7% 97.3 -- TGN,MG 14 - AS62886 29799 0.7% 2292.2 -- OMNITEL - OMNITEL COMMUNICATIONS,US 15 - AS17916 27848 0.6% 1740.5 -- CSC-IGN-AUNZ-AP Computer Sciences Corporation,AU 16 - AS28024 27764 0.6% 18.2 -- Nuevatel PCS de Bolivia S.A.,BO 17 - AS8402 26961 0.6% 19.1 -- CORBINA-AS OJSC "Vimpelcom",RU 18 - AS17974 23203 0.5% 10.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 19 - AS23342 22391 0.5% 589.2 -- UNITEDLAYER - Unitedlayer, Inc.,US 20 - AS8452 21724 0.5% 13.2 -- TE-AS TE-AS,EG TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS61894 227643 5.2% 56910.8 -- FreeBSD Brasil LTDA,BR 2 - AS49227 19741 0.5% 19741.0 -- TCI-ANYCAST-NET UKRAINIAN INTERNET NAMES CENTER.LTD,UA 3 - AS53563 47218 1.1% 15739.3 -- XPLUSONE - X Plus One Solutions, Inc.,US 4 - AS61039 15385 0.3% 15385.0 -- ZMZ OAO ZMZ,RU 5 - AS32830 18986 0.4% 9493.0 -- CCS-325-1 - Connecticut Computer Service, Inc.,US 6 - AS56426 63222 1.4% 9031.7 -- ASVOLNA-NET CJSC "VOLNA-SERVIS",RU 7 - AS46336 8372 0.2% 8372.0 -- GOODVILLE - Goodville Mutual Casualty Company,US 8 - AS197914 18672 0.4% 6224.0 -- STOCKHO-AS Stockho Hosting SARL,FR 9 - AS2734 91622 2.1% 5389.5 -- CORESITE - CoreSite,US 10 - AS46230 101249 2.3% 4821.4 -- DUDROP - Dignitas Technology Inc,US 11 - AS33529 40465 0.9% 4496.1 -- PEAK-WEB-HOSTING - Peak Web Hosting Inc.,US 12 - AS10013 12943 0.3% 4314.3 -- FBDC FreeBit Co.,Ltd.,JP 13 - AS33721 3898 0.1% 3898.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 14 - AS54465 9635 0.2% 3211.7 -- QPM-AS-1 - QuickPlay Media Inc.,US 15 - AS47680 15778 0.4% 3155.6 -- NHCS EOBO Limited,IE 16 - AS198053 3032 0.1% 3032.0 -- AMTEL VECTRA S.A.,PL 17 - AS42081 72726 1.7% 2909.0 -- SPEEDY-NET-AS Speedy net EAD,BG 18 - AS33356 2816 0.1% 2816.0 -- CTWS - Eagle-Tech Systems,US 19 - AS19114 16344 0.4% 2724.0 -- Otecel S.A.,EC 20 - AS23752 220856 5.0% 2629.2 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 177.10.158.0/24 227631 5.0% AS61894 -- FreeBSD Brasil LTDA,BR 2 - 202.70.64.0/21 111012 2.4% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 202.70.88.0/21 109280 2.4% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 105.96.0.0/22 82916 1.8% AS36947 -- ALGTEL-AS,DZ 5 - 193.232.40.0/22 62933 1.4% AS56426 -- ASVOLNA-NET CJSC "VOLNA-SERVIS",RU 6 - 199.38.164.0/23 47210 1.0% AS53563 -- XPLUSONE - X Plus One Solutions, Inc.,US 7 - 93.181.216.0/21 42458 0.9% AS13118 -- ASN-YARTELECOM OJSC Rostelecom,RU 8 - 69.194.4.0/24 40445 0.9% AS33529 -- PEAK-WEB-HOSTING - Peak Web Hosting Inc.,US 9 - 64.29.130.0/24 22247 0.5% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 10 - 195.123.1.0/24 19741 0.4% AS49227 -- TCI-ANYCAST-NET UKRAINIAN INTERNET NAMES CENTER.LTD,UA 11 - 130.0.192.0/21 18670 0.4% AS197914 -- STOCKHO-AS Stockho Hosting SARL,FR 12 - 66.128.148.0/24 18335 0.4% AS2734 -- CORESITE - CoreSite,US 13 - 67.212.149.0/24 18258 0.4% AS2734 -- CORESITE - CoreSite,US 14 - 66.128.156.0/22 18234 0.4% AS2734 -- CORESITE - CoreSite,US 15 - 66.128.149.0/24 18225 0.4% AS2734 -- CORESITE - CoreSite,US 16 - 66.128.148.0/22 18144 0.4% AS2734 -- CORESITE - CoreSite,US 17 - 88.87.160.0/19 15774 0.3% AS47680 -- NHCS EOBO Limited,IE 18 - 91.235.169.0/24 15385 0.3% AS61039 -- ZMZ OAO ZMZ,RU 19 - 91.193.202.0/24 14956 0.3% AS42081 -- SPEEDY-NET-AS Speedy net EAD,BG 20 - 95.47.46.0/24 10985 0.2% AS61308 -- PVONET-AS PVONET LTD,RU 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 owen at delong.com Fri Mar 13 22:05:52 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 13 Mar 2015 15:05:52 -0700 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> Message-ID: <219F79F0-0A8D-4DF8-842A-C919AF7F4D2A@delong.com> Agreed. A new document should be a complete replacement and represent the full text recommendation. Owen > On Mar 13, 2015, at 07:37, George, Wes wrote: > >> On 3/12/15, 7:48 PM, "Owen DeLong" wrote: >> >> >> Then, just like the RFCs, maintain the BCOP appeal numbering as a >> sequential monotonically increasing number and make the BCOP editor >> responsible for updating the index with the publishing of each new or >> revised BCOP. >> >> Note, IMHO, a revised BCOP should get a new number and the previous >> revision should be marked “obsoleted by XXXXX” and it’s document status >> should reflect “Obsoletes XXXX, XXXX, and XXXX” for all previous >> revisions. The index should probably reflect only BCOPs which have not >> been obsoleted > > A note of caution: > Please don't exactly replicate the RFC series's model where the existing > document can only be updated by new documents but is not always completely > replaced/obsoleted such that the reader is left following the trail of > breadcrumbs across multiple documents trying to figure out what the union > of the two (or 3 or 14) "current" documents actually means in terms of the > complete guidance. If what you're suggesting is actually a full > replacement of the document so that the new version is complete and > standalone, I think that's better, but really I don't understand why these > can't be more living documents (like a Wiki) instead of just using the > server as a public dropbox for static files. The higher the drag for > getting updates done, the more likely they are to go obsolete and be less > useful to the community. > > 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 bedard.phil at gmail.com Sat Mar 14 00:06:51 2015 From: bedard.phil at gmail.com (Phil Bedard) Date: Fri, 13 Mar 2015 20:06:51 -0400 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> <8BCF27B8-FB61-4244-AB5B-869BDE86BD9E@beckman.org> Message-ID: <55037bcb.ef268c0a.4a56.ffffeb7c@mx.google.com> The RFC index is updated when a new RFC updates or obsoletes one or more existing RFCs. The old entry has pointers to the new RFCs and vice-versa. Now which parts are updated is usually left as an exercise but it's usually not too hard to figure out. There is also an errata system in place. I think the system works fairly well. Phil -----Original Message----- From: "Lee Howard" Sent: ‎3/‎13/‎2015 3:51 PM To: "Mel Beckman" ; "Rick Casarez" Cc: "bcop-support at nanog.org" ; "nanog at nanog.org" Subject: Re: BCOP appeals numbering scheme -- feedback requested I think the RFC numbering system is a terrible scheme. As Wes described, you have a document purporting to describe something, with no indicator that parts of it have been rendered obsolete by parts of other documents. I pity implementors who have to figure it all out. I also agree with Joel, that assigning meaning to index numbers is a bad idea. It leads to crossed indexes and unclear references. For the documents to be useful, one should be able to read a single document on a topic. When that topic is too big for a single document, split the document. When something in one document supersedes something in another, confirm consensus and update the canonical document. If that's too dynamic for people, then maintain the index, and when part of a document is obsoleted, the entire updated document should be republished with a new number, and the old one marked "obsoleted by XXXX." Under no circumstances would I support a limited number space. Lee On 3/13/15 2:26 PM, "Mel Beckman" wrote: >The index scheme has worked very well with RFCs, and has the added >advantage of their index numbers becoming handy memes. I strongly urge >Nanog to take advantage of the RFC system's success. There is no shortage >of monotonically ascending integers :) > > -mel beckman > >> On Mar 13, 2015, at 11:19 AM, "Rick Casarez" >>wrote: >> >> I like the idea of an index better than the proposed numbering scheme. >> >> ------------------- >> Cheers, Rick >> >> Experiences not things. >> >>> On Thu, Mar 12, 2015 at 7:48 PM, Owen DeLong wrote: >>> >>> >>>>> On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes >>>> wrote: >>>> >>>> >>>> >>>> Hello NANOGers, >>>> >>>> The NANOG BCOP committee is currently considering strategies on how >>>>to >>> best create a numbering scheme for the BCOP appeals. As we all know, >>>most >>> public technical references (IETF, etc) have numbers to clarify >>>references. >>> The goal is for NANOG BCOPs to follow some sort of same style. >>>> >>>> The BCOP committee is looking for feedback and comments on this topic. >>>> >>>> Currently, the below numbering scheme is being considered: >>>> >>>> A proposed numbering scheme can be based on how the appeals appeals in >>> the BCOP topics are presented as shown below: >>>> >>>> http://bcop.nanog.org/index.php/Appeals >>>> >>>> In the above page, the idea is to introduce a 100-th range for each >>> category and as the BCOPs. This way a 100th number range generally >>> identifies each of the categories we currently have. An example is: >>>> >>>> BCP Range Area of Practice >>>> 100 - 199 EBGPs >>>> 200 - 299 IGPs >>>> 300 - 399 Ethernet >>>> 400 - 499 Class of Service >>>> 500 - 599 Network Information Processing >>>> 600 - 699 Security >>>> 700 - 799 MPLS >>>> 800 - 899 Generalized >>>> >>>> An arguable objection could be that the range is limited...but a >>> counter-argument is that considering more than 100 BCOPs would be >>>either a >>> great success or just a sign of failure for the NANOG community ... >>>> >>>> Comments or Thoughts ? >>> >>> The problem with any such numbering scheme is how you handle the >>>situation >>> when you exhaust the avaialble number space. What happens with the >>>101st >>> EBGP BCOP, for example? >>> >>> I also agree with Joel¹s comment about identifier/locator overload. >>>Have >>> we learned nothing from the issues created by doing this in IPv4 and >>>IPv6? >>> >>> Instead, how about maintaining a BCOP subject index which contains >>>titular >>> and numeric information for each BCOP applicable to the subjects above. >>> >>> e.g.: >>> >>> BCOP Subject Index: >>> >>> Subjects: >>> 1. EBGP >>> 2. IGP >>> 3. Ethernet >>> 4. Class of Service >>> 5. Network Information Processing >>> 6. Security >>> 7. MPLS >>> 8. Generalized >>> >>> >>> 1. EBGP >>> 104 lorem ipsum >>> 423 ipsum lorem >>> >>> >>> >>> Then, just like the RFCs, maintain the BCOP appeal numbering as a >>> sequential monotonically increasing number and make the BCOP editor >>> responsible for updating the index with the publishing of each new or >>> revised BCOP. >>> >>> Note, IMHO, a revised BCOP should get a new number and the previous >>> revision should be marked ³obsoleted by XXXXX² and it¹s document status >>> should reflect ³Obsoletes XXXX, XXXX, and XXXX² for all previous >>>revisions. >>> The index should probably reflect only BCOPs which have not been >>>obsoleted. >>> >>> Just my $0.02. >>> >>> Owen >>> >>> > From owen at delong.com Sat Mar 14 00:54:26 2015 From: owen at delong.com (Owen DeLong) Date: Fri, 13 Mar 2015 17:54:26 -0700 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: <55037bcb.ef268c0a.4a56.ffffeb7c@mx.google.com> References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> <8BCF27B8-FB61-4244-AB5B-869BDE86BD9E@beckman.org> <55037bcb.ef268c0a.4a56.ffffeb7c@mx.google.com> Message-ID: <6B1848C6-1AB3-4A1B-824C-D0C66810406C@delong.com> It does, but for BCOP, I do think it would be best if the new document completely obsoleted the previous document and still relevant content was copied into the new document rather than leaving merge as an exercise. Owen > On Mar 13, 2015, at 17:06 , Phil Bedard wrote: > > The RFC index is updated when a new RFC updates or obsoletes one or more existing RFCs. The old entry has pointers to the new RFCs and vice-versa. Now which parts are updated is usually left as an exercise but it's usually not too hard to figure out. There is also an errata system in place. I think the system works fairly well. > > Phil > > -----Original Message----- > From: "Lee Howard" > Sent: ‎3/‎13/‎2015 3:51 PM > To: "Mel Beckman" ; "Rick Casarez" > Cc: "bcop-support at nanog.org" ; "nanog at nanog.org" > Subject: Re: BCOP appeals numbering scheme -- feedback requested > > I think the RFC numbering system is a terrible scheme. As Wes described, > you have a document purporting to describe something, with no indicator > that parts of it have been rendered obsolete by parts of other documents. > I pity implementors who have to figure it all out. > > I also agree with Joel, that assigning meaning to index numbers is a bad > idea. It leads to crossed indexes and unclear references. > > For the documents to be useful, one should be able to read a single > document on a topic. When that topic is too big for a single document, > split the document. When something in one document supersedes something in > another, confirm consensus and update the canonical document. > > If that's too dynamic for people, then maintain the index, and when part > of a document is obsoleted, the entire updated document should be > republished with a new number, and the old one marked "obsoleted by XXXX." > > Under no circumstances would I support a limited number space. > > Lee > > On 3/13/15 2:26 PM, "Mel Beckman" wrote: > >> The index scheme has worked very well with RFCs, and has the added >> advantage of their index numbers becoming handy memes. I strongly urge >> Nanog to take advantage of the RFC system's success. There is no shortage >> of monotonically ascending integers :) >> >> -mel beckman >> >>> On Mar 13, 2015, at 11:19 AM, "Rick Casarez" >>> wrote: >>> >>> I like the idea of an index better than the proposed numbering scheme. >>> >>> ------------------- >>> Cheers, Rick >>> >>> Experiences not things. >>> >>>> On Thu, Mar 12, 2015 at 7:48 PM, Owen DeLong wrote: >>>> >>>> >>>>>> On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes >>>>> wrote: >>>>> >>>>> >>>>> >>>>> Hello NANOGers, >>>>> >>>>> The NANOG BCOP committee is currently considering strategies on how >>>>> to >>>> best create a numbering scheme for the BCOP appeals. As we all know, >>>> most >>>> public technical references (IETF, etc) have numbers to clarify >>>> references. >>>> The goal is for NANOG BCOPs to follow some sort of same style. >>>>> >>>>> The BCOP committee is looking for feedback and comments on this topic. >>>>> >>>>> Currently, the below numbering scheme is being considered: >>>>> >>>>> A proposed numbering scheme can be based on how the appeals appeals in >>>> the BCOP topics are presented as shown below: >>>>> >>>>> http://bcop.nanog.org/index.php/Appeals >>>>> >>>>> In the above page, the idea is to introduce a 100-th range for each >>>> category and as the BCOPs. This way a 100th number range generally >>>> identifies each of the categories we currently have. An example is: >>>>> >>>>> BCP Range Area of Practice >>>>> 100 - 199 EBGPs >>>>> 200 - 299 IGPs >>>>> 300 - 399 Ethernet >>>>> 400 - 499 Class of Service >>>>> 500 - 599 Network Information Processing >>>>> 600 - 699 Security >>>>> 700 - 799 MPLS >>>>> 800 - 899 Generalized >>>>> >>>>> An arguable objection could be that the range is limited...but a >>>> counter-argument is that considering more than 100 BCOPs would be >>>> either a >>>> great success or just a sign of failure for the NANOG community ... >>>>> >>>>> Comments or Thoughts ? >>>> >>>> The problem with any such numbering scheme is how you handle the >>>> situation >>>> when you exhaust the avaialble number space. What happens with the >>>> 101st >>>> EBGP BCOP, for example? >>>> >>>> I also agree with Joel¹s comment about identifier/locator overload. >>>> Have >>>> we learned nothing from the issues created by doing this in IPv4 and >>>> IPv6? >>>> >>>> Instead, how about maintaining a BCOP subject index which contains >>>> titular >>>> and numeric information for each BCOP applicable to the subjects above. >>>> >>>> e.g.: >>>> >>>> BCOP Subject Index: >>>> >>>> Subjects: >>>> 1. EBGP >>>> 2. IGP >>>> 3. Ethernet >>>> 4. Class of Service >>>> 5. Network Information Processing >>>> 6. Security >>>> 7. MPLS >>>> 8. Generalized >>>> >>>> >>>> 1. EBGP >>>> 104 lorem ipsum >>>> 423 ipsum lorem >>>> >>>> >>>> >>>> Then, just like the RFCs, maintain the BCOP appeal numbering as a >>>> sequential monotonically increasing number and make the BCOP editor >>>> responsible for updating the index with the publishing of each new or >>>> revised BCOP. >>>> >>>> Note, IMHO, a revised BCOP should get a new number and the previous >>>> revision should be marked ³obsoleted by XXXXX² and it¹s document status >>>> should reflect ³Obsoletes XXXX, XXXX, and XXXX² for all previous >>>> revisions. >>>> The index should probably reflect only BCOPs which have not been >>>> obsoleted. >>>> >>>> Just my $0.02. >>>> >>>> Owen >>>> >>>> >> > From plucena at coopergeneral.com Sat Mar 14 00:59:13 2015 From: plucena at coopergeneral.com (Pablo Lucena) Date: Fri, 13 Mar 2015 20:59:13 -0400 Subject: What happened to Schprokits? In-Reply-To: References: <5502FDC4.3020204@gmail.com> <72A66234DA8FA043BFD0CCE68931420A5354F0FB@MBX-02.WIN.NOMINUM.COM> Message-ID: I have great hopes for Schprokits. The idea behind it is outstanding - an Ansible for networking. It must be tough though, integrating all major vendor APIs seamlessly into a product. I have faith in Jeremy and his team...hopefully they are close to shipping code =) *Pablo Lucena* On Fri, Mar 13, 2015 at 2:36 PM, Steve Noble wrote: > There are other stealth companies the space. I still see activity on > Twitter (favorites, etc) so I he is still active. We will see good things > in the space. > On Mar 13, 2015 11:31 AM, "Adrian Beaudin" > wrote: > > > it looks like (according to linkedin) that Jeremy has moved to a stealth > > startup. > > > > -a > > > > > > Adrian Beaudin > > Principal Architect, Special Projects > > Nominum, Inc. > > o: +1.650.587.1513 > > adrian.beaudin at nominum.com > > > > > > > > ________________________________________ > > From: NANOG [nanog-bounces at nanog.org] on behalf of Scott Whyte [ > > swhyte at gmail.com] > > Sent: Friday, March 13, 2015 11:09 AM > > To: nanog at nanog.org > > Subject: What happened to Schprokits? > > > > Schprokits was mentioned at NANOG63 but http://www.schprokits.com/ > > doesn't look too good. > > > > What happened? > > > From charles at thefnf.org Sat Mar 14 10:29:19 2015 From: charles at thefnf.org (Charles N Wyble) Date: Sat, 14 Mar 2015 05:29:19 -0500 Subject: What happened to Schprokits? In-Reply-To: References: <5502FDC4.3020204@gmail.com> <72A66234DA8FA043BFD0CCE68931420A5354F0FB@MBX-02.WIN.NOMINUM.COM> Message-ID: <7FD4AF6F-B084-4ABC-9BE1-005FE14C3C9D@thefnf.org> Checkout trigger for what seems to be the most viable system: https://trigger.readthedocs.org/en/latest/ On March 13, 2015 7:59:13 PM CDT, Pablo Lucena wrote: >I have great hopes for Schprokits. The idea behind it is outstanding - >an >Ansible for networking. It must be tough though, integrating all major >vendor APIs seamlessly into a product. I have faith in Jeremy and his >team...hopefully they are close to shipping code =) > >*Pablo Lucena* >On Fri, Mar 13, 2015 at 2:36 PM, Steve Noble wrote: > >> There are other stealth companies the space. I still see activity on >> Twitter (favorites, etc) so I he is still active. We will see good >things >> in the space. >> On Mar 13, 2015 11:31 AM, "Adrian Beaudin" > >> wrote: >> >> > it looks like (according to linkedin) that Jeremy has moved to a >stealth >> > startup. >> > >> > -a >> > >> > >> > Adrian Beaudin >> > Principal Architect, Special Projects >> > Nominum, Inc. >> > o: +1.650.587.1513 >> > adrian.beaudin at nominum.com >> > >> > >> > >> > ________________________________________ >> > From: NANOG [nanog-bounces at nanog.org] on behalf of Scott Whyte [ >> > swhyte at gmail.com] >> > Sent: Friday, March 13, 2015 11:09 AM >> > To: nanog at nanog.org >> > Subject: What happened to Schprokits? >> > >> > Schprokits was mentioned at NANOG63 but http://www.schprokits.com/ >> > doesn't look too good. >> > >> > What happened? >> > >> > >!DSPAM:55038897231179442818726! -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From plucena at coopergeneral.com Sat Mar 14 13:52:51 2015 From: plucena at coopergeneral.com (Pablo Lucena) Date: Sat, 14 Mar 2015 09:52:51 -0400 Subject: What happened to Schprokits? In-Reply-To: <7FD4AF6F-B084-4ABC-9BE1-005FE14C3C9D@thefnf.org> References: <5502FDC4.3020204@gmail.com> <72A66234DA8FA043BFD0CCE68931420A5354F0FB@MBX-02.WIN.NOMINUM.COM> <7FD4AF6F-B084-4ABC-9BE1-005FE14C3C9D@thefnf.org> Message-ID: This is great, had not heard of Trigger. Finding that it has native support for asynchronous processing makes it even better =). Thanks for sharing Charles. Regards, On Sat, Mar 14, 2015 at 6:29 AM, Charles N Wyble wrote: > Checkout trigger for what seems to be the most viable system: > > https://trigger.readthedocs.org/en/latest/ > > > > On March 13, 2015 7:59:13 PM CDT, Pablo Lucena > wrote: >> >> I have great hopes for Schprokits. The idea behind it is outstanding - an >> Ansible for networking. It must be tough though, integrating all major >> vendor APIs seamlessly into a product. I have faith in Jeremy and his >> team...hopefully they are close to shipping code =) >> >> *Pablo Lucena* >> On Fri, Mar 13, 2015 at 2:36 PM, Steve Noble wrote: >> >> There are other stealth companies the space. I still see activity on >>> Twitter (favorites, etc) so I he is still active. We will see good things >>> in the space. >>> On Mar 13, 2015 11:31 AM, "Adrian Beaudin" >>> wrote: >>> >>> it looks like (according to linkedin) that Jeremy has moved >>>> to a stealth >>>> startup. >>>> >>>> -a >>>> >>>> >>>> Adrian Beaudin >>>> Principal Architect, Special Projects >>>> Nominum, Inc. >>>> o: +1.650.587.1513 >>>> adrian.beaudin at nominum.com >>>> >>>> >>>> >>>> ------------------------------ >>>> >>>> From: NANOG [nanog-bounces at nanog.org] on behalf of Scott Whyte [ >>>> swhyte at gmail.com] >>>> Sent: Friday, March 13, 2015 11:09 AM >>>> To: nanog at nanog.org >>>> Subject: What happened to Schprokits? >>>> >>>> Schprokits was mentioned at NANOG63 but http://www.schprokits.com/ >>>> doesn't look too good. >>>> >>>> What happened? >>> >>> >>> >>> >> !DSPAM:55038897231179442818726! >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > From larrysheldon at cox.net Sat Mar 14 14:00:39 2015 From: larrysheldon at cox.net (Larry Sheldon) Date: Sat, 14 Mar 2015 09:00:39 -0500 Subject: Searching for a quote In-Reply-To: <31nz1q00P1cZc56011oAdD> References: <5502E2A1.90308@satchell.net> <31nz1q00P1cZc56011oAdD> Message-ID: <55043F07.1020201@cox.net> On 3/13/2015 08:47, Karl Auer wrote: > On Fri, 2015-03-13 at 06:14 -0700, Stephen Satchell wrote: >> what I was taught is that one has to be >> able to handle *correctly* malformed input, and not yield astonishing >> results. > > "No program should leave its sanity at the mercy of its input". PJ > Plauger, I think. I have no idea where I learned it but early in my career as a programmer and later as a manager of programmers I preached that "Above all else, programmer, your duty and responsibility is to protect your program from its input and its environment." I may very well owe that to somebody smarter than me, but I think the idea solidified in my first paid programming job I got embroiled in a battle with programmers from another district in a huge batch system, Their allegation was that bad input from a program I was responsible-for had caused a massive and expensive outage down-stream of us. (They had amassed a collection of file-dump snap-shots that they said showed that the records from us had errors in them--we were able to show that the file-dumps were fraudulent in and of themselves, but my main argument was an early rendition to the thing quoted above.) Parenthetically, one of my favorite management quotations came out of that when the District Manager that my boss reported to (We called him "The Senator" behind his back) stood up at his desk and announced to us and to the folks from the other District that "we would have a solution to the problem by four PM today or there will be a series of Nine O'Clock Announcements tomorrow morning." (Big company, big inventory of thoroughly distasteful assignments for ambitious managers-on-the-climb.) -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes From wbn at drpeering.net Sat Mar 14 19:19:09 2015 From: wbn at drpeering.net (William Norton) Date: Sat, 14 Mar 2015 12:19:09 -0700 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: <6B1848C6-1AB3-4A1B-824C-D0C66810406C@delong.com> References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> <8BCF27B8-FB61-4244-AB5B-869BDE86BD9E@beckman.org> <55037bcb.ef268c0a.4a56.ffffeb7c@mx.google.com> <6B1848C6-1AB3-4A1B-824C-D0C66810406C@delong.com> Message-ID: <79307C7E-8715-4CB0-9305-0B0B71BFCF42@drpeering.net> > On Mar 13, 2015, at 5:54 PM, Owen DeLong wrote: > > It does, but for BCOP, I do think it would be best if the new document completely obsoleted the previous document and still relevant content was copied into the new document rather than leaving merge as an exercise. Agreed - Hence the “Current” in the title. Maybe the date of the document will be the key to let people know that they have the most current version. > > Owen From dave at temk.in Sat Mar 14 19:55:29 2015 From: dave at temk.in (Dave Temkin) Date: Sat, 14 Mar 2015 12:55:29 -0700 Subject: Google served from non-google IPs? In-Reply-To: References: <86FE96C5-C39F-42DE-957E-74BE38B2DAB8@lixfeld.ca> Message-ID: Seems like an odd waste of resources; what if Google, Akamai, Netflix, and anyone else who wanted caches wanted IPs in that block? The IX would be out of address space pretty quickly, forcing a majority of users to re-number because of a small number of other users. -Dave On Thu, Mar 12, 2015 at 1:07 PM, Steven Schecter wrote: > Those IPs appear to be used by to Google cache servers at the QIX. It's > common for CDNs to utilize provider space and not maintain their own > layer-3. E.g. cache servers connected to switch, connected to provider, > without the requirement of a router. > > > /Steve > > On Thu, Mar 12, 2015 at 3:58 PM, Jason Lixfeld wrote: > > > So today, I saw this: > > > > BlackBox:~ jlixfeld$ host google.ca 8.8.8.8 > > Using domain server: > > Name: 8.8.8.8 > > Address: 8.8.8.8#53 > > Aliases: > > > > google.ca has address 206.126.112.166 > > google.ca has address 206.126.112.177 > > google.ca has address 206.126.112.172 > > google.ca has address 206.126.112.187 > > google.ca has address 206.126.112.151 > > google.ca has address 206.126.112.158 > > google.ca has address 206.126.112.157 > > google.ca has address 206.126.112.173 > > google.ca has address 206.126.112.181 > > google.ca has address 206.126.112.155 > > google.ca has address 206.126.112.147 > > google.ca has address 206.126.112.185 > > google.ca has address 206.126.112.143 > > google.ca has address 206.126.112.170 > > google.ca has address 206.126.112.162 > > google.ca has IPv6 address 2607:f8b0:4006:808::100f > > google.ca mail is handled by 50 alt4.aspmx.l.google.com. > > google.ca mail is handled by 30 alt2.aspmx.l.google.com. > > google.ca mail is handled by 20 alt1.aspmx.l.google.com. > > google.ca mail is handled by 10 aspmx.l.google.com. > > google.ca mail is handled by 40 alt3.aspmx.l.google.com. > > BlackBox:~ jlixfeld$ > > > > That is not Google IPv4 address space, and those IPv4 IPs are not being > > announced by 15169. > > > > Am I dumb in thinking that this is weird or is this sort of thing > > commonplace? > > > > > -- > Steven J. Schecter > (m) 917.676.1646 > From itg at itechgeek.com Sat Mar 14 20:05:50 2015 From: itg at itechgeek.com (ITechGeek) Date: Sat, 14 Mar 2015 16:05:50 -0400 Subject: Google served from non-google IPs? In-Reply-To: References: <86FE96C5-C39F-42DE-957E-74BE38B2DAB8@lixfeld.ca> Message-ID: I'm surprised they don't set aside a small piece of their IP space that an ISP can anycast routes locally to the cache (Maybe a /24?) ----------------------------------------------------------------------------------------------- -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 Sat, Mar 14, 2015 at 3:55 PM, Dave Temkin wrote: > Seems like an odd waste of resources; what if Google, Akamai, Netflix, and > anyone else who wanted caches wanted IPs in that block? The IX would be out > of address space pretty quickly, forcing a majority of users to re-number > because of a small number of other users. > > -Dave > > On Thu, Mar 12, 2015 at 1:07 PM, Steven Schecter > wrote: > > > Those IPs appear to be used by to Google cache servers at the QIX. It's > > common for CDNs to utilize provider space and not maintain their own > > layer-3. E.g. cache servers connected to switch, connected to provider, > > without the requirement of a router. > > > > > > /Steve > > > > On Thu, Mar 12, 2015 at 3:58 PM, Jason Lixfeld wrote: > > > > > So today, I saw this: > > > > > > BlackBox:~ jlixfeld$ host google.ca 8.8.8.8 > > > Using domain server: > > > Name: 8.8.8.8 > > > Address: 8.8.8.8#53 > > > Aliases: > > > > > > google.ca has address 206.126.112.166 > > > google.ca has address 206.126.112.177 > > > google.ca has address 206.126.112.172 > > > google.ca has address 206.126.112.187 > > > google.ca has address 206.126.112.151 > > > google.ca has address 206.126.112.158 > > > google.ca has address 206.126.112.157 > > > google.ca has address 206.126.112.173 > > > google.ca has address 206.126.112.181 > > > google.ca has address 206.126.112.155 > > > google.ca has address 206.126.112.147 > > > google.ca has address 206.126.112.185 > > > google.ca has address 206.126.112.143 > > > google.ca has address 206.126.112.170 > > > google.ca has address 206.126.112.162 > > > google.ca has IPv6 address 2607:f8b0:4006:808::100f > > > google.ca mail is handled by 50 alt4.aspmx.l.google.com. > > > google.ca mail is handled by 30 alt2.aspmx.l.google.com. > > > google.ca mail is handled by 20 alt1.aspmx.l.google.com. > > > google.ca mail is handled by 10 aspmx.l.google.com. > > > google.ca mail is handled by 40 alt3.aspmx.l.google.com. > > > BlackBox:~ jlixfeld$ > > > > > > That is not Google IPv4 address space, and those IPv4 IPs are not being > > > announced by 15169. > > > > > > Am I dumb in thinking that this is weird or is this sort of thing > > > commonplace? > > > > > > > > > > -- > > Steven J. Schecter > > (m) 917.676.1646 > > > From bmanning at karoshi.com Sat Mar 14 20:16:37 2015 From: bmanning at karoshi.com (manning) Date: Sat, 14 Mar 2015 13:16:37 -0700 Subject: Google served from non-google IPs? In-Reply-To: References: <86FE96C5-C39F-42DE-957E-74BE38B2DAB8@lixfeld.ca> Message-ID: <8D551044-A72F-4764-BB8F-E97667CDB7EB@karoshi.com> one of the legacy uses of an IX was to place “content” near the eyeballs. For the adventurous, this meant placing NTP chimers, DNS & route servers, and even content directly on the switch mesh. Akamai might have been the first to pull back from that and move its services behind an Akamai router that was on the switch mesh. These days, most folks use BGP “condoms” to protect themselves. manning bmanning at karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 14March2015Saturday, at 12:55, Dave Temkin wrote: > Seems like an odd waste of resources; what if Google, Akamai, Netflix, and > anyone else who wanted caches wanted IPs in that block? The IX would be out > of address space pretty quickly, forcing a majority of users to re-number > because of a small number of other users. > > -Dave > > On Thu, Mar 12, 2015 at 1:07 PM, Steven Schecter wrote: > >> Those IPs appear to be used by to Google cache servers at the QIX. It's >> common for CDNs to utilize provider space and not maintain their own >> layer-3. E.g. cache servers connected to switch, connected to provider, >> without the requirement of a router. >> >> >> /Steve >> >> On Thu, Mar 12, 2015 at 3:58 PM, Jason Lixfeld wrote: >> >>> So today, I saw this: >>> >>> BlackBox:~ jlixfeld$ host google.ca 8.8.8.8 >>> Using domain server: >>> Name: 8.8.8.8 >>> Address: 8.8.8.8#53 >>> Aliases: >>> >>> google.ca has address 206.126.112.166 >>> google.ca has address 206.126.112.177 >>> google.ca has address 206.126.112.172 >>> google.ca has address 206.126.112.187 >>> google.ca has address 206.126.112.151 >>> google.ca has address 206.126.112.158 >>> google.ca has address 206.126.112.157 >>> google.ca has address 206.126.112.173 >>> google.ca has address 206.126.112.181 >>> google.ca has address 206.126.112.155 >>> google.ca has address 206.126.112.147 >>> google.ca has address 206.126.112.185 >>> google.ca has address 206.126.112.143 >>> google.ca has address 206.126.112.170 >>> google.ca has address 206.126.112.162 >>> google.ca has IPv6 address 2607:f8b0:4006:808::100f >>> google.ca mail is handled by 50 alt4.aspmx.l.google.com. >>> google.ca mail is handled by 30 alt2.aspmx.l.google.com. >>> google.ca mail is handled by 20 alt1.aspmx.l.google.com. >>> google.ca mail is handled by 10 aspmx.l.google.com. >>> google.ca mail is handled by 40 alt3.aspmx.l.google.com. >>> BlackBox:~ jlixfeld$ >>> >>> That is not Google IPv4 address space, and those IPv4 IPs are not being >>> announced by 15169. >>> >>> Am I dumb in thinking that this is weird or is this sort of thing >>> commonplace? >> >> >> >> >> -- >> Steven J. Schecter >> (m) 917.676.1646 >> From morrowc.lists at gmail.com Sat Mar 14 21:09:40 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 14 Mar 2015 17:09:40 -0400 Subject: Google served from non-google IPs? In-Reply-To: References: <86FE96C5-C39F-42DE-957E-74BE38B2DAB8@lixfeld.ca> Message-ID: On Sat, Mar 14, 2015 at 4:05 PM, ITechGeek wrote: > I'm surprised they don't set aside a small piece of their IP space that an 'they' and 'their' here are confusing, which 'they' and 'their' did you mean? > ISP can anycast routes locally to the cache (Maybe a /24?) that sounds like a recipe for disaster with respect to latency and jitter and control of destination of the user request, eh? Have you tried using 6to4 gateways? From itg at itechgeek.com Sat Mar 14 21:32:44 2015 From: itg at itechgeek.com (ITechGeek) Date: Sat, 14 Mar 2015 17:32:44 -0400 Subject: Google served from non-google IPs? In-Reply-To: References: <86FE96C5-C39F-42DE-957E-74BE38B2DAB8@lixfeld.ca> Message-ID: On Sat, Mar 14, 2015 at 5:09 PM, Christopher Morrow wrote: > > I'm surprised they don't set aside a small piece of their IP space that > an > > 'they' and 'their' here are confusing, which 'they' and 'their' did you > mean? In this case they being Google and their being Google's IP space (but you can replace Google w/ any provider using caching servers). When I was using Comcast 6to4 gateway, the latency wasn't too bad (I'm a Comcast customer). If the anycast is being broadcast from a regional datacenter and your ISP has good connectivity, the latency shouldn't be bad (in the QIX case above, the latency shouldn't be any worse than QIX's IPs unless someone started advertising the same anycast subnet w/ a lower cost). ----------------------------------------------------------------------------------------------- -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 morrowc.lists at gmail.com Sat Mar 14 21:43:32 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 14 Mar 2015 17:43:32 -0400 Subject: Google served from non-google IPs? In-Reply-To: References: <86FE96C5-C39F-42DE-957E-74BE38B2DAB8@lixfeld.ca> Message-ID: On Sat, Mar 14, 2015 at 5:32 PM, ITechGeek wrote: > On Sat, Mar 14, 2015 at 5:09 PM, Christopher Morrow > wrote: > >> > I'm surprised they don't set aside a small piece of their IP space that >> an >> >> 'they' and 'their' here are confusing, which 'they' and 'their' did you >> mean? > > > In this case they being Google and their being Google's IP space (but you > can replace Google w/ any provider using caching servers). this has the same uncertainty problems with other folk I imagine. > When I was using Comcast 6to4 gateway, the latency wasn't too bad (I'm a > Comcast customer). If the anycast is being broadcast from a regional > datacenter and your ISP has good connectivity, the latency shouldn't be bad > (in the QIX case above, the latency shouldn't be any worse than QIX's IPs > unless someone started advertising the same anycast subnet w/ a lower cost). there are a lot of ifs there... and failover is where the problems arise :( From rs at seastrom.com Sun Mar 15 13:24:49 2015 From: rs at seastrom.com (Rob Seastrom) Date: Sun, 15 Mar 2015 09:24:49 -0400 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: <79307C7E-8715-4CB0-9305-0B0B71BFCF42@drpeering.net> (William Norton's message of "Sat, 14 Mar 2015 12:19:09 -0700") References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> <8BCF27B8-FB61-4244-AB5B-869BDE86BD9E@beckman.org> <55037bcb.ef268c0a.4a56.ffffeb7c@mx.google.com> <6B1848C6-1AB3-4A1B-824C-D0C66810406C@delong.com> <79307C7E-8715-4CB0-9305-0B0B71BFCF42@drpeering.net> Message-ID: <86wq2ie6la.fsf@valhalla.seastrom.com> William Norton writes: > Agreed - Hence the “Current” in the title. Maybe the date of the > document will be the key to let people know that they have the most > current version. The date of a single document is of scant use in determining its currency unless there is some sort of requirement for periodic recertification and gratuitous reissue of BCOPs (for instance, anything with a date stamp more than 18 months in the past is by definition invalid). That seems like busy work to periodically affirm that a good idea is still a good idea, and I don't volunteer for this job. :) I'm on board for wholesale replacement of the document (with revision history preserved) rather than the RFC series approach. The wiki/living document approach others have suggested seems like a poor one to me, for the same reason that I dislike the current trend of "there's no release tarball, major release, point release, or regression testing - just git clone the repository" in free software development. Releng is hard and thankless but adds enormous value and serves as a forcing function for some level of review, cursory though it may be. -r From charles at thefnf.org Sun Mar 15 15:17:38 2015 From: charles at thefnf.org (Charles N Wyble) Date: Sun, 15 Mar 2015 10:17:38 -0500 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: <86wq2ie6la.fsf@valhalla.seastrom.com> References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> <8BCF27B8-FB61-4244-AB5B-869BDE86BD9E@beckman.org> <55037bcb.ef268c0a.4a56.ffffeb7c@mx.google.com> <6B1848C6-1AB3-4A1B-824C-D0C66810406C@delong.com> <79307C7E-8715-4CB0-9305-0B0B71BFCF42@drpeering.net> <86wq2ie6la.fsf@valhalla.seastrom.com> Message-ID: <1EED65CF-0861-4F60-97D1-CB3CF471C65A@thefnf.org> Use a git repository. Make tagged releases. This enables far easier distributed editing, translating, mirroring etc. And you can still do whatever release engineering you want. A wiki is a horrible solution for something like this. On March 15, 2015 8:24:49 AM CDT, Rob Seastrom wrote: > >William Norton writes: > >> Agreed - Hence the “Current” in the title. Maybe the date of the >> document will be the key to let people know that they have the most >> current version. > >The date of a single document is of scant use in determining its >currency unless there is some sort of requirement for periodic >recertification and gratuitous reissue of BCOPs (for instance, >anything with a date stamp more than 18 months in the past is >by definition invalid). That seems like busy work to periodically >affirm that a good idea is still a good idea, and I don't volunteer >for this job. :) > >I'm on board for wholesale replacement of the document (with revision >history preserved) rather than the RFC series approach. > >The wiki/living document approach others have suggested seems like a >poor one to me, for the same reason that I dislike the current trend >of "there's no release tarball, major release, point release, or >regression testing - just git clone the repository" in free software >development. Releng is hard and thankless but adds enormous value and >serves as a forcing function for some level of review, cursory though >it may be. > >-r > > >!DSPAM:55058872288661838712557! -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From Lee at asgard.org Sun Mar 15 15:40:27 2015 From: Lee at asgard.org (Lee Howard) Date: Sun, 15 Mar 2015 11:40:27 -0400 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> <8BCF27B8-FB61-4244-AB5B-869BDE86BD9E@beckman.org> Message-ID: On 3/13/15 5:14 PM, "mel at becknet.com" wrote: >Lee, > >On the contrary, I think RFCs are pretty consistent about always >referring you to any superseding RFCs, and superseding RFCs reference >their predecessors, creating a very useful historical doubly-linked list. >I've served on IEEE committees that follow a decimal/alpha/french >numbering system, in which it is very hard to track the history of a >standard. > >RFCs, on the other hand, tend to be concisely written and well annotated >with background materials. What's more, RFCxxxx makes an excellent unique >internet-global search term. > >You've made the assertion that RFC numbering is terrible. Can you >provide some examples? The canonical version of the RFC is the plain text version. So here's RFC6204: http://www.rfc-editor.org/rfc/rfc6204.txt No notes about being obsolete. If you want, you can find two other versions officially published, the "tools version" and the "datatracker version": https://tools.ietf.org/html/rfc6204 https://datatracker.ietf.org/doc/rfc6204/ Both of those tell you that this RFC has been obsoleted by RFC7084. But here's one: https://tools.ietf.org/html/rfc791 Let's say I want to implement this protocol. Looks pretty straightforward, once I've read the errata and the three RFCs that obsolete it. The first of those three is RFC1349, which also has been obsoleted by RFC2474, which in turn has been obsoleted by RFC3168 and RFC3260, the first of which is obsoleted by RFC4301 and RFC6040. I didn't follow the other chains of obsoleting documents. How many documents do I have to read if I want to implement this protocol? Ha, ha, you say, nobody's trying to write an IP implementation from scratch. Au contraire, IPv6 is defined in https://tools.ietf.org/html/rfc2460, which lists nine RFCs updating it, plus errata. And while I agree with you that "RFC2460" is an easy, unique search term, it isn't exactly memorable. "I need to write an IPv6 stack for my new ThingOS; what do I need to read?" And one of my least favorite comments at the mic at IETF is, "Have you even read RFC6214?" [1] Because the author is standing there with no way to look up what that particular number means. I know, I should really be having this rant in the RFC evolution WG, or with the RFC editor. It just came up here, and I want BCOP to make different mistakes on useful documents. Lee [1] I included this reference in an RFI, to catch vendors who were only cutting and pasting marketing materials. > > -mel beckman > >> On Mar 13, 2015, at 12:50 PM, "Lee Howard" wrote: >> >> I think the RFC numbering system is a terrible scheme. As Wes >>described, >> you have a document purporting to describe something, with no indicator >> that parts of it have been rendered obsolete by parts of other >>documents. >> I pity implementors who have to figure it all out. >> >> I also agree with Joel, that assigning meaning to index numbers is a bad >> idea. It leads to crossed indexes and unclear references. >> >> For the documents to be useful, one should be able to read a single >> document on a topic. When that topic is too big for a single document, >> split the document. When something in one document supersedes something >>in >> another, confirm consensus and update the canonical document. >> >> If that's too dynamic for people, then maintain the index, and when part >> of a document is obsoleted, the entire updated document should be >> republished with a new number, and the old one marked "obsoleted by >>XXXX." >> >> Under no circumstances would I support a limited number space. >> >> Lee >> >>> On 3/13/15 2:26 PM, "Mel Beckman" wrote: >>> >>> The index scheme has worked very well with RFCs, and has the added >>> advantage of their index numbers becoming handy memes. I strongly urge >>> Nanog to take advantage of the RFC system's success. There is no >>>shortage >>> of monotonically ascending integers :) >>> >>> -mel beckman >>> >>>> On Mar 13, 2015, at 11:19 AM, "Rick Casarez" >>>> wrote: >>>> >>>> I like the idea of an index better than the proposed numbering scheme. >>>> >>>> ------------------- >>>> Cheers, Rick >>>> >>>> Experiences not things. >>>> >>>>> On Thu, Mar 12, 2015 at 7:48 PM, Owen DeLong wrote: >>>>> >>>>> >>>>>>> On Mar 12, 2015, at 12:01 , Yardiel D. Fuentes >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hello NANOGers, >>>>>> >>>>>> The NANOG BCOP committee is currently considering strategies on how >>>>>> to >>>>> best create a numbering scheme for the BCOP appeals. As we all know, >>>>> most >>>>> public technical references (IETF, etc) have numbers to clarify >>>>> references. >>>>> The goal is for NANOG BCOPs to follow some sort of same style. >>>>>> >>>>>> The BCOP committee is looking for feedback and comments on this >>>>>>topic. >>>>>> >>>>>> Currently, the below numbering scheme is being considered: >>>>>> >>>>>> A proposed numbering scheme can be based on how the appeals appeals >>>>>>in >>>>> the BCOP topics are presented as shown below: >>>>>> >>>>>> http://bcop.nanog.org/index.php/Appeals >>>>>> >>>>>> In the above page, the idea is to introduce a 100-th range for each >>>>> category and as the BCOPs. This way a 100th number range generally >>>>> identifies each of the categories we currently have. An example is: >>>>>> >>>>>> BCP Range Area of Practice >>>>>> 100 - 199 EBGPs >>>>>> 200 - 299 IGPs >>>>>> 300 - 399 Ethernet >>>>>> 400 - 499 Class of Service >>>>>> 500 - 599 Network Information Processing >>>>>> 600 - 699 Security >>>>>> 700 - 799 MPLS >>>>>> 800 - 899 Generalized >>>>>> >>>>>> An arguable objection could be that the range is limited...but a >>>>> counter-argument is that considering more than 100 BCOPs would be >>>>> either a >>>>> great success or just a sign of failure for the NANOG community ... >>>>>> >>>>>> Comments or Thoughts ? >>>>> >>>>> The problem with any such numbering scheme is how you handle the >>>>> situation >>>>> when you exhaust the avaialble number space. What happens with the >>>>> 101st >>>>> EBGP BCOP, for example? >>>>> >>>>> I also agree with Joel¹s comment about identifier/locator overload. >>>>> Have >>>>> we learned nothing from the issues created by doing this in IPv4 and >>>>> IPv6? >>>>> >>>>> Instead, how about maintaining a BCOP subject index which contains >>>>> titular >>>>> and numeric information for each BCOP applicable to the subjects >>>>>above. >>>>> >>>>> e.g.: >>>>> >>>>> BCOP Subject Index: >>>>> >>>>> Subjects: >>>>> 1. EBGP >>>>> 2. IGP >>>>> 3. Ethernet >>>>> 4. Class of Service >>>>> 5. Network Information Processing >>>>> 6. Security >>>>> 7. MPLS >>>>> 8. Generalized >>>>> >>>>> >>>>> 1. EBGP >>>>> 104 lorem ipsum >>>>> 423 ipsum lorem >>>>> >>>>> >>>>> >>>>> Then, just like the RFCs, maintain the BCOP appeal numbering as a >>>>> sequential monotonically increasing number and make the BCOP editor >>>>> responsible for updating the index with the publishing of each new or >>>>> revised BCOP. >>>>> >>>>> Note, IMHO, a revised BCOP should get a new number and the previous >>>>> revision should be marked ³obsoleted by XXXXX² and it¹s document >>>>>status >>>>> should reflect ³Obsoletes XXXX, XXXX, and XXXX² for all previous >>>>> revisions. >>>>> The index should probably reflect only BCOPs which have not been >>>>> obsoleted. >>>>> >>>>> Just my $0.02. >>>>> >>>>> Owen >> >> > From rs at seastrom.com Sun Mar 15 16:15:22 2015 From: rs at seastrom.com (Rob Seastrom) Date: Sun, 15 Mar 2015 12:15:22 -0400 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: <1EED65CF-0861-4F60-97D1-CB3CF471C65A@thefnf.org> (Charles N. Wyble's message of "Sun, 15 Mar 2015 10:17:38 -0500") References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> <8BCF27B8-FB61-4244-AB5B-869BDE86BD9E@beckman.org> <55037bcb.ef268c0a.4a56.ffffeb7c@mx.google.com> <6B1848C6-1AB3-4A1B-824C-D0C66810406C@delong.com> <79307C7E-8715-4CB0-9305-0B0B71BFCF42@drpeering.net> <86wq2ie6la.fsf@valhalla.seastrom.com> <1EED65CF-0861-4F60-97D1-CB3CF471C65A@thefnf.org> Message-ID: <86lhiyxmn9.fsf@valhalla.seastrom.com> Charles N Wyble writes: > Use a git repository. > Make tagged releases. > This enables far easier distributed editing, translating, mirroring etc. And A fine idea in theory, but not quite as much traction in reality as bcp38. Creating a need for a BCP for retrieving BCPs so that you get the right version rather than typing "git clone" and erroneously referring to whatever is tagged "-develop" seems like a Bad Plan. It's also not a really reasonable method for distributing point-in-time documents once people are done with collaborating on creating them. Most end consumers will not care about the change history. > you can still do whatever release engineering you want. Sure. > A wiki is a horrible solution for something like this. Agree 100% -r From stenn at ntp.org Sun Mar 15 21:20:25 2015 From: stenn at ntp.org (Harlan Stenn) Date: Sun, 15 Mar 2015 21:20:25 +0000 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: <86wq2ie6la.fsf@valhalla.seastrom.com> References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> <8BCF27B8-FB61-4244-AB5B-869BDE86BD9E@beckman.org> <55037bcb.ef268c0a.4a56.ffffeb7c@mx.google.com> <6B1848C6-1AB3-4A1B-824C-D0C66810406C@delong.com> <79307C7E-8715-4CB0-9305-0B0B71BFCF42@drpeering.net> <86wq2ie6la.fsf@valhalla.seastrom.com> Message-ID: Rob Seastrom writes: > The wiki/living document approach others have suggested seems like a > poor one to me, for the same reason that I dislike the current trend > of "there's no release tarball, major release, point release, or > regression testing - just git clone the repository" in free software > development. And I like wikis for some things, here it might work (I haven't looked) and I still do release tarballs with version numbers and some (we're actively adding more) regression/unit/functional testing. > Releng is hard and thankless :) > but adds enormous value and > serves as a forcing function for some level of review, cursory though > it may be. I think so too. Hey everybody, please support Network Time. Spread the word. OK, I said it. -- Harlan Stenn http://networktimefoundation.org - be a member! From asullivan at dyn.com Sun Mar 15 23:14:05 2015 From: asullivan at dyn.com (Andrew Sullivan) Date: Sun, 15 Mar 2015 19:14:05 -0400 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> <8BCF27B8-FB61-4244-AB5B-869BDE86BD9E@beckman.org> Message-ID: <20150315231404.GB2496@dyn.com> On Sun, Mar 15, 2015 at 11:40:27AM -0400, Lee Howard wrote: > > I know, I should really be having this rant in the RFC evolution WG, or > with the RFC editor. It just came up here, and I want BCOP to make > different mistakes on useful documents. Even if you suppose that the RFC series is arranged ideally, or for that matter if you assume that, given established practice, fixing the RFC series is impossible, that _still_ doesn't make the RFC series a good model. In fact, of course, the RFC series actually has an overlay on it that is intended to be much more like BCOP, which is the BCP series. The thing about the BCP series is that a BCP's number doesn't change even if the document(s) making it up do. That's why (say) BCP 9 is the Internet standards process regardless of whether that's RFC 1602 or 2026-and-updates or whatever. I think that sort of thing is useful, because people can learn the right shorthand for "whatever one is doing now on topic X" and just refer people to that. I don't care if it's "BCOP 32006.1234" or "BCOP on foobar of whazit", but a consistent reference people can go to for the current version is the important feature. I also think that trying to pack more bits of information into the numbering system is a mistake. But then, I would. I think you look those sorts of things up (in the DNS, of course ;-) ) A -- Andrew Sullivan Dyn asullivan at dyn.com From Valdis.Kletnieks at vt.edu Sun Mar 15 23:44:01 2015 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 15 Mar 2015 19:44:01 -0400 Subject: BCOP appeals numbering scheme -- feedback requested In-Reply-To: Your message of "Sun, 15 Mar 2015 19:14:05 -0400." <20150315231404.GB2496@dyn.com> References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> <8BCF27B8-FB61-4244-AB5B-869BDE86BD9E@beckman.org> <20150315231404.GB2496@dyn.com> Message-ID: <5750.1426463041@turing-police.cc.vt.edu> On Sun, 15 Mar 2015 19:14:05 -0400, Andrew Sullivan said: > I also think that trying to pack more bits of information into the > numbering system is a mistake. But then, I would. I think you look > those sorts of things up (in the DNS, of course ;-) ) DANE? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mpetach at netflight.com Mon Mar 16 01:59:26 2015 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 15 Mar 2015 18:59:26 -0700 Subject: Searching for a quote In-Reply-To: <6202315B-B9D4-49F9-8CEF-C30F9EFB929A@isi.edu> References: <55022FFA.1030309@mtcc.com> <6202315B-B9D4-49F9-8CEF-C30F9EFB929A@isi.edu> Message-ID: On Thu, Mar 12, 2015 at 6:34 PM, manning bill wrote: > it is true that the risk profile has changed in the last 30 years. > his core belief in interconnecting things in an open way, enabling > _anyone_ to create,build, and deploy > is the core of ISOCs “permission less innovation” thrust. > I hope it was more "permission-less innovation", and not "permission, less innovation". Ambiguously punctuated statements are *so* open to misunderstandings. ^_^; Matt From jonathan.tomek at gmail.com Sat Mar 14 23:48:45 2015 From: jonathan.tomek at gmail.com (Jonathan Tomek) Date: Sat, 14 Mar 2015 19:48:45 -0400 Subject: Rerouting of UK traffic Message-ID: Hello Everyone, DYN put out an interesting report on how 14 British telecom routes (167 prefixes) were routed through Ukraine for a good portion of time. The ASN in question is AS12883 (Vega in Kiev, Ukraine). Do you think this could be a mistake? Does anyone have any additional information to back this up? The full report is here: http://research.dyn.com/2015/03/uk-traffic-diverted-ukraine/ Respectfully, Jonathan Tomek From dhc2 at dcrocker.net Mon Mar 16 02:57:59 2015 From: dhc2 at dcrocker.net (Dave Crocker) Date: Sun, 15 Mar 2015 19:57:59 -0700 Subject: Searching for a quote In-Reply-To: References: Message-ID: <550646B7.9050107@dcrocker.net> On 3/12/2015 5:24 PM, Tom Paseka wrote: > Be conservative in what you send, be liberal in what you accept > > ^http://en.wikipedia.org/wiki/Robustness_principle As with all terse summaries, the meaning of this is easy to distort. In the unfortunately not-so-uncommon extreme, it is used to argue for demanding acceptance of all manner of random cruft, essentially translating into "the protocol requires you to support anything I send you." This, of course, is not what Jon meant. Rather, he noted the fact that protocol specifications invariably contain some ambiguities which, equally invariably, get interpreted differently by different, reasonable implementers. Hence the stricture to meant to guide the sending of what an implementer should consider to be the most conservative interpretations, and accept the most liberal (different) interpretations. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From rs at seastrom.com Mon Mar 16 19:48:01 2015 From: rs at seastrom.com (Rob Seastrom) Date: Mon, 16 Mar 2015 15:48:01 -0400 Subject: Supporting network time software development/maintenance (was: Re: BCOP appeals numbering scheme -- feedback requested) In-Reply-To: (Harlan Stenn's message of "Sun, 15 Mar 2015 21:20:25 +0000") References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> <8BCF27B8-FB61-4244-AB5B-869BDE86BD9E@beckman.org> <55037bcb.ef268c0a.4a56.ffffeb7c@mx.google.com> <6B1848C6-1AB3-4A1B-824C-D0C66810406C@delong.com> <79307C7E-8715-4CB0-9305-0B0B71BFCF42@drpeering.net> <86wq2ie6la.fsf@valhalla.seastrom.com> Message-ID: <863854911q.fsf_-_@valhalla.seastrom.com> New subject so as to minimize threadjacking, not the least because this is important stuff. Harlan Stenn writes: >> Releng is hard and thankless but adds enormous value and >> serves as a forcing function for some level of review, cursory though >> it may be. > > I think so too. > > Hey everybody, please support Network Time. Spread the word. OK, I said it. The check, as we say, is in the mail (literally). I wish I'd known about Network Time Foundation before you and I started corresponding a little over a week ago about GPS cores. > Harlan Stenn > http://networktimefoundation.org - be a member! NANOG colleagues, I know it can be hard getting the employer to pony up for organizations like this, but if correct timestamps in your logs and being able to correlate your packet captures are something you find personally valuable and sanity-preserving, you might consider an individual membership. I know it's pretty important to me... http://nwtime.org/individual-membership-application/ -r From stenn at ntp.org Mon Mar 16 21:59:55 2015 From: stenn at ntp.org (Harlan Stenn) Date: Mon, 16 Mar 2015 21:59:55 +0000 Subject: Supporting network time software development/maintenance (was: Re: BCOP appeals numbering scheme -- feedback requested) In-Reply-To: <863854911q.fsf_-_@valhalla.seastrom.com> References: <1CC6CC8F-1D82-430F-85BE-CE883249E979@gmail.com> <3F029C30-AC63-4D44-8601-BC5A2046C136@delong.com> <8BCF27B8-FB61-4244-AB5B-869BDE86BD9E@beckman.org> <55037bcb.ef268c0a.4a56.ffffeb7c@mx.google.com> <6B1848C6-1AB3-4A1B-824C-D0C66810406C@delong.com> <79307C7E-8715-4CB0-9305-0B0B71BFCF42@drpeering.net> <86wq2ie6la.fsf@valhalla.seastrom.com> <863854911q.fsf_-_@valhalla.seastrom.com> Message-ID: Rob Seastrom writes: > New subject so as to minimize threadjacking, not the least because > this is important stuff. > > Harlan Stenn writes: > >>> Releng is hard and thankless but adds enormous value and >>> serves as a forcing function for some level of review, cursory though >>> it may be. >> >> I think so too. >> >> Hey everybody, please support Network Time. Spread the word. OK, I >> said it. > > The check, as we say, is in the mail (literally). Very much appreciated! > I wish I'd known about Network Time Foundation before you and I > started corresponding a little over a week ago about GPS cores. > > > Harlan Stenn > > http://networktimefoundation.org - be a member! > > NANOG colleagues, I know it can be hard getting the employer to pony > up for organizations like this, but if correct timestamps in your logs > and being able to correlate your packet captures are something you > find personally valuable and sanity-preserving, you might consider an > individual membership. I know it's pretty important to me... > > http://nwtime.org/individual-membership-application/ And Sue Graves is working with NTF to help with all of this, so if there is anything we can do to help show value to your employers please let her know. The individual donations are great - they've quickly added a bit over 2 weeks' time to the "financial clock" regarding my "full time" efforts (apparently my definition of full time is a bit unusual). Please help keep those coming in. it's going to take Institutional members to provide the more significant resources NTF needs to bring the bigger goals on-line, things like even faster NTP development, completing Ntimed, getting the General Timestamp API spec'd and implemented, and our Certification and Compliance programs operational: http://nwtime.org/membership http://nwtime.org/join http://nwtime.org/projects We've heard from some institutions that they'll be joining us, but nothing has happened there yet. Thanks a bunch, folks! Please keep spreading the word. -- Harlan Stenn http://networktimefoundation.org - be a member! From benno at NLnetLabs.nl Tue Mar 17 15:46:01 2015 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Tue, 17 Mar 2015 16:46:01 +0100 Subject: RIPE 70 draft programme and CFP 2nd deadline 12 april 2015 Message-ID: <55084C39.8030405@NLnetLabs.nl> Dear colleagues, Following the past submission deadline, a Draft Programme for RIPE 70 is now published at: https://ripe70.ripe.net/programme/meeting-plan/draft-programme/ We will accept new proposals until 12 April 2015 for the remaining few slots. You can find the Call for Presentations and guidelines for submissions at: https://ripe70.ripe.net/submit-topic/cpf/ https://ripe70.ripe.net/submit-topic/guidelines/ Kind regards, Benno Overeinder RIPE PC -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From richb.hanover at gmail.com Tue Mar 17 17:20:11 2015 From: richb.hanover at gmail.com (Rich Brown) Date: Tue, 17 Mar 2015 13:20:11 -0400 Subject: Request for clueful person at Apple's mail operation Message-ID: <1847EB97-6156-490C-93AE-F7D34CD60210@gmail.com> Folks, A number of colleagues have been having delayed or rejected mail deliveries (with "451 4.5.3 Too many rejections; try again later." messages) since Saturday morning. Apple's front-line iCloud support people have been helpful, but not terribly clued in. Could someone contact me off-list to talk about this? Many thanks. Rich Brown Blueberry Hill Software richb.hanover at gmail.com +1 603-262-3957 (land line) -------------- 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 ter.devor at gmail.com Tue Mar 17 02:06:27 2015 From: ter.devor at gmail.com (Terrance Devor) Date: Mon, 16 Mar 2015 22:06:27 -0400 Subject: Getting hit hard by CHINANET Message-ID: Hello Everyone, I really hope this is not against group policy etc.. however our network is being hit hard by a China IP for the past 6 months. Our systems our up to date, passwordless ssh etc.. but they're DOS attempts are getting more and more aggressive. Tried to contact their phone number to no success (not valid). Emails don't get any response. The IP is 218.77.79.43. Do we have any options? Terrance From morrowc.lists at gmail.com Wed Mar 18 02:09:52 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 17 Mar 2015 22:09:52 -0400 Subject: Getting hit hard by CHINANET In-Reply-To: References: Message-ID: On Mon, Mar 16, 2015 at 10:06 PM, Terrance Devor wrote: > Hello Everyone, > > I really hope this is not against group policy etc.. however our network is > being hit > hard by a China IP for the past 6 months. Our systems our up to date, > passwordless > ssh etc.. but they're DOS attempts are getting more and more aggressive. please define 'dos attempts' ... perhaps you have some logs? > Tried to > contact their phone number to no success (not valid). Emails don't get any > response. you are not the only one. > The IP is 218.77.79.43. Do we have any options? > probably not? > Terrance From rdobbins at arbor.net Wed Mar 18 02:13:09 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 18 Mar 2015 09:13:09 +0700 Subject: Getting hit hard by CHINANET In-Reply-To: References: Message-ID: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> On 17 Mar 2015, at 9:06, Terrance Devor wrote: > Do we have any options? S/RTBH and/or ACLs at your transit/peering edge, for starters: Also, asking your upstreams/peers to block traffic sourced from this IP to your netblock(s) on their networks. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Wed Mar 18 02:16:11 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 18 Mar 2015 09:16:11 +0700 Subject: Getting hit hard by CHINANET In-Reply-To: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> Message-ID: <2403B179-9DB9-4761-8EE7-F869E44D09A7@arbor.net> On 18 Mar 2015, at 9:13, Roland Dobbins wrote: > Also, asking your upstreams/peers to block traffic sourced from this > IP to your netblock(s) on their networks. It would also be a good idea to ensure that your systems which are being targeted aren't themselves compromised, and being used by miscreants as botnet C&Cs or whatever. A lot of 'inexplicable' attacks are actually internecine disputes amongst miscreants, with compromised systems under the control of miscreant A being targeted by miscreant B - and the legitimate owner/operator of the hosts in question has no idea that they're compromised. ----------------------------------- Roland Dobbins From mark.tinka at seacom.mu Wed Mar 18 05:26:34 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Mar 2015 07:26:34 +0200 Subject: Getting hit hard by CHINANET In-Reply-To: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> Message-ID: <55090C8A.1050804@seacom.mu> On 18/Mar/15 04:13, Roland Dobbins wrote: > > > Also, asking your upstreams/peers to block traffic sourced from this > IP to your netblock(s) on their networks. I'm actually curious how many transit providers would implement data plane filters on their side to block source traffic bound for their downstreams. Personally, as a transit provider, I'm less inclined to filtering traffic in any way; impact to hardware e.t.c. notwithstanding... Perhaps times are changing. Mark. From contact at winterei.se Wed Mar 18 05:31:52 2015 From: contact at winterei.se (Paul S.) Date: Wed, 18 Mar 2015 14:31:52 +0900 Subject: Getting hit hard by CHINANET In-Reply-To: <55090C8A.1050804@seacom.mu> References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> <55090C8A.1050804@seacom.mu> Message-ID: <55090DC8.6050206@winterei.se> All 6 of my upstreams (Most of them tier 1s, except Internap which is a tier 3?) have cooperated just fine in blocking problematic IPs if needed in emergencies. I did not have to argue. On 3/18/2015 午後 02:26, Mark Tinka wrote: > > > On 18/Mar/15 04:13, Roland Dobbins wrote: >> >> >> Also, asking your upstreams/peers to block traffic sourced from this >> IP to your netblock(s) on their networks. > > I'm actually curious how many transit providers would implement data > plane filters on their side to block source traffic bound for their > downstreams. > > Personally, as a transit provider, I'm less inclined to filtering > traffic in any way; impact to hardware e.t.c. notwithstanding... > > Perhaps times are changing. > > Mark. From mark.tinka at seacom.mu Wed Mar 18 05:44:42 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Mar 2015 07:44:42 +0200 Subject: Getting hit hard by CHINANET In-Reply-To: <55090DC8.6050206@winterei.se> References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> <55090C8A.1050804@seacom.mu> <55090DC8.6050206@winterei.se> Message-ID: <550910CA.7090600@seacom.mu> On 18/Mar/15 07:31, Paul S. wrote: > All 6 of my upstreams (Most of them tier 1s, except Internap which is > a tier 3?) have cooperated just fine in blocking problematic IPs if > needed in emergencies. In the data plane for the link facing you, or through RTBH? Mark. From colinj at gt86car.org.uk Wed Mar 18 06:18:39 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Wed, 18 Mar 2015 06:18:39 +0000 Subject: Getting hit hard by CHINANET In-Reply-To: References: Message-ID: <2B69FA7C-F792-4F8A-9BDC-8938577E4BF7@gt86car.org.uk> use block firewall country flags, use strict packet compliance checking, dont bother with abuse email comms as is ignored, mentioned to trade missions but ignored colin Sent from my iPhone > On 17 Mar 2015, at 02:06, Terrance Devor wrote: > > Hello Everyone, > > I really hope this is not against group policy etc.. however our network is > being hit > hard by a China IP for the past 6 months. Our systems our up to date, > passwordless > ssh etc.. but they're DOS attempts are getting more and more aggressive. > Tried to > contact their phone number to no success (not valid). Emails don't get any > response. > The IP is 218.77.79.43. Do we have any options? > > Terrance From rdobbins at arbor.net Wed Mar 18 06:19:07 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 18 Mar 2015 13:19:07 +0700 Subject: Getting hit hard by CHINANET In-Reply-To: <55090C8A.1050804@seacom.mu> References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> <55090C8A.1050804@seacom.mu> Message-ID: On 18 Mar 2015, at 12:26, Mark Tinka wrote: > I'm actually curious how many transit providers would implement data > plane filters on their side to block source traffic bound for their > downstreams. The assumption is that that OP is an end-customer/endpoint network, and willing to pay for same, if necessary. Even if that's not the case, that's how DDoS attacks are routinely and cooperatively mitigated between providers, when it's possible to block based on source, number of sources isn't overwhelming, etc. ----------------------------------- Roland Dobbins From eyeronic.design at gmail.com Wed Mar 18 06:24:07 2015 From: eyeronic.design at gmail.com (Mike Hale) Date: Tue, 17 Mar 2015 23:24:07 -0700 Subject: Getting hit hard by CHINANET In-Reply-To: <2B69FA7C-F792-4F8A-9BDC-8938577E4BF7@gt86car.org.uk> References: <2B69FA7C-F792-4F8A-9BDC-8938577E4BF7@gt86car.org.uk> Message-ID: I null route those IPs that stand out above the background noise at our edge. Seems to work relatively well so far. I do have a request for Roland. Would you mind sharing more details on what you've seen regarding the various miscreants screwing with each others' devices? On Tue, Mar 17, 2015 at 11:18 PM, Colin Johnston wrote: > use block firewall country flags, use strict packet compliance checking, dont bother with abuse email comms as is ignored, mentioned to trade missions but ignored > > colin > > Sent from my iPhone > >> On 17 Mar 2015, at 02:06, Terrance Devor wrote: >> >> Hello Everyone, >> >> I really hope this is not against group policy etc.. however our network is >> being hit >> hard by a China IP for the past 6 months. Our systems our up to date, >> passwordless >> ssh etc.. but they're DOS attempts are getting more and more aggressive. >> Tried to >> contact their phone number to no success (not valid). Emails don't get any >> response. >> The IP is 218.77.79.43. Do we have any options? >> >> Terrance -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From mark.tinka at seacom.mu Wed Mar 18 06:32:36 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 18 Mar 2015 08:32:36 +0200 Subject: Getting hit hard by CHINANET In-Reply-To: References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> <55090C8A.1050804@seacom.mu> Message-ID: <55091C04.8090504@seacom.mu> On 18/Mar/15 08:19, Roland Dobbins wrote: > > > The assumption is that that OP is an end-customer/endpoint network, > and willing to pay for same, if necessary. My general experience is that customers are not willing to pay for implementation of data plane filters. They'd be willing to pay for traffic scrubbing, however. > > Even if that's not the case, that's how DDoS attacks are routinely and > cooperatively mitigated between providers, when it's possible to block > based on source, number of sources isn't overwhelming, etc. That's one of two issues - if the sources are overwhelming how does one scale that up without the use of some scrubbing service? Writing data plane filters that are customer-specific works (assuming you have the hardware for it), but can get unwieldy. The other issues are the chance to boo-boo things when filtering a customer-facing port, and/or forgetting to remove filters after they are needed and customer (or the remote end) ends up having reachability issues. Mark. From contact at winterei.se Wed Mar 18 06:38:23 2015 From: contact at winterei.se (Paul S.) Date: Wed, 18 Mar 2015 15:38:23 +0900 Subject: Getting hit hard by CHINANET In-Reply-To: <550910CA.7090600@seacom.mu> References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> <55090C8A.1050804@seacom.mu> <55090DC8.6050206@winterei.se> <550910CA.7090600@seacom.mu> Message-ID: <55091D5F.1020402@winterei.se> On 3/18/2015 午後 02:44, Mark Tinka wrote: > > > On 18/Mar/15 07:31, Paul S. wrote: >> All 6 of my upstreams (Most of them tier 1s, except Internap which is >> a tier 3?) have cooperated just fine in blocking problematic IPs if >> needed in emergencies. > > In the data plane for the link facing you, or through RTBH? > > Mark. Data plane. PCCW on a separate project even offered to do specific filters like 'drop all udp to port n targetting block x.' My subscription to them is normal internet transit. Suppose I've been lucky, eh. From robert at ripe.net Wed Mar 18 07:12:06 2015 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 18 Mar 2015 08:12:06 +0100 Subject: Getting hit hard by CHINANET In-Reply-To: References: Message-ID: <55092546.6060901@ripe.net> On 2015-03-17 3:06, Terrance Devor wrote: > Hello Everyone, > > I really hope this is not against group policy etc.. however our network is > being hit > hard by a China IP for the past 6 months. Our systems our up to date, > passwordless > ssh etc.. but they're DOS attempts are getting more and more aggressive. > Tried to > contact their phone number to no success (not valid). Emails don't get any > response. > The IP is 218.77.79.43. Do we have any options? > > Terrance > If you don't want to spend more than 2 minutes on this, then move sshd to a different (randomish) port. Sounds naive, but it's dirt cheap and really helps. Robert From marco at paesani.it Wed Mar 18 08:08:38 2015 From: marco at paesani.it (Marco Paesani) Date: Wed, 18 Mar 2015 09:08:38 +0100 Subject: Supplier 100/200Mbps on Canarias Is. Message-ID: Hi, I need a supplier on Canarias Is, do you have some info ? Please answer direct to me, thanks ! Best regards, -- Marco Paesani MPAE Srl Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it From rdobbins at arbor.net Wed Mar 18 09:43:17 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 18 Mar 2015 16:43:17 +0700 Subject: Getting hit hard by CHINANET In-Reply-To: References: <2B69FA7C-F792-4F8A-9BDC-8938577E4BF7@gt86car.org.uk> Message-ID: On 18 Mar 2015, at 13:24, Mike Hale wrote: > Would you mind sharing more details on what you've seen regarding the > various miscreants screwing with each others' devices? They will DDoS and/or work to subvert the C&C infrastructure of botnets run by other miscreants due as a form of retaliation for illicit deals gone wrong, in order to inconvenience perceived competitors, due to 'talking smack' on underground forums, etc. It is quite common for compromised servers to be utilized as botnet C&C servers, with the legitimate owners/operators of said servers being totally unaware of this activity - and thus surprised when they're suddenly on the receiving end of DDoS attacks which are actually spurred by inter-miscreant rivalries. We've observed intra-IDC DDoS attacks launched from hosts belonging to one customer of a host/colocation/VPS provider against hosts belonging to another customer of the same provider, for example; we've even seen the same server compromised by two different groups of miscreants attacked by both groups of miscreants, in this context. ----------------------------------- Roland Dobbins From rdobbins at arbor.net Wed Mar 18 09:49:15 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 18 Mar 2015 16:49:15 +0700 Subject: Getting hit hard by CHINANET In-Reply-To: <55091C04.8090504@seacom.mu> References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> <55090C8A.1050804@seacom.mu> <55091C04.8090504@seacom.mu> Message-ID: On 18 Mar 2015, at 13:32, Mark Tinka wrote: > That's one of two issues - if the sources are overwhelming how does > one scale that up without the use of some scrubbing service? Writing > data plane filters that are customer-specific works (assuming you have > the hardware for it), but can get unwieldy. Some operators have specialized DDoS mitigation capabilities. Others rely exclusively on basic network infrastructure-based mechanisms like D/RTBH, S/RTBH, and/or flowspec. > The other issues are the chance to boo-boo things when filtering a > customer-facing port, and/or forgetting to remove filters after they > are needed and customer (or the remote end) ends up having > reachability issues. Sure. But this doesn't obviate the fact that cooperative DDoS mitigation amongst network operators routinely takes place on the Internet today, and is increasingly made available in one form or another to end-customers who request same. ----------------------------------- Roland Dobbins From bjorn at mork.no Wed Mar 18 09:54:17 2015 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Wed, 18 Mar 2015 10:54:17 +0100 Subject: Supplier 100/200Mbps on Canarias Is. In-Reply-To: (Marco Paesani's message of "Wed, 18 Mar 2015 09:08:38 +0100") References: Message-ID: <87h9tieily.fsf@nemi.mork.no> Marco Paesani writes: > I need a supplier on Canarias Is, do you have some info ? http://www.d-alix.com/ Bjørn From colinj at gt86car.org.uk Wed Mar 18 09:55:15 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Wed, 18 Mar 2015 09:55:15 +0000 Subject: Getting hit hard by CHINANET In-Reply-To: References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> <55090C8A.1050804@seacom.mu> <55091C04.8090504@seacom.mu> Message-ID: would be interested to know of providers using bgp to auto block ranges from china colin Sent from my iPhone > On 18 Mar 2015, at 09:49, "Roland Dobbins" wrote: > > >> On 18 Mar 2015, at 13:32, Mark Tinka wrote: >> >> That's one of two issues - if the sources are overwhelming how does one scale that up without the use of some scrubbing service? Writing data plane filters that are customer-specific works (assuming you have the hardware for it), but can get unwieldy. > > Some operators have specialized DDoS mitigation capabilities. Others rely exclusively on basic network infrastructure-based mechanisms like D/RTBH, S/RTBH, and/or flowspec. > >> The other issues are the chance to boo-boo things when filtering a customer-facing port, and/or forgetting to remove filters after they are needed and customer (or the remote end) ends up having reachability issues. > > Sure. But this doesn't obviate the fact that cooperative DDoS mitigation amongst network operators routinely takes place on the Internet today, and is increasingly made available in one form or another to end-customers who request same. > > ----------------------------------- > Roland Dobbins From rdobbins at arbor.net Wed Mar 18 10:00:38 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 18 Mar 2015 17:00:38 +0700 Subject: Getting hit hard by CHINANET In-Reply-To: References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> <55090C8A.1050804@seacom.mu> <55091C04.8090504@seacom.mu> Message-ID: On 18 Mar 2015, at 16:55, Colin Johnston wrote: > would be interested to know of providers using bgp to auto block > ranges from china This is not an optimal approach, and most providers are unlikely to engage in such behavior due to its potential negative impact (I'm assuming you mean via S/RTBH and/or flowspec). ----------------------------------- Roland Dobbins From rdobbins at arbor.net Wed Mar 18 10:04:19 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Wed, 18 Mar 2015 17:04:19 +0700 Subject: Getting hit hard by CHINANET In-Reply-To: References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> <55090C8A.1050804@seacom.mu> <55091C04.8090504@seacom.mu> Message-ID: On 18 Mar 2015, at 17:00, Roland Dobbins wrote: > This is not an optimal approach, and most providers are unlikely to > engage in such behavior due to its potential negative impact (I'm > assuming you mean via S/RTBH and/or flowspec). Here's one counterexample: ----------------------------------- Roland Dobbins From colinj at gt86car.org.uk Wed Mar 18 11:26:49 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Wed, 18 Mar 2015 11:26:49 +0000 Subject: Getting hit hard by CHINANET In-Reply-To: References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> <55090C8A.1050804@seacom.mu> <55091C04.8090504@seacom.mu> Message-ID: <6BE5D523-AB4F-40F9-9411-197FD6F6F23E@gt86car.org.uk> why not try if chinanet folks refuse to respond to abuse,apac details colin Sent from my iPhone > On 18 Mar 2015, at 10:00, "Roland Dobbins" wrote: > > >> On 18 Mar 2015, at 16:55, Colin Johnston wrote: >> >> would be interested to know of providers using bgp to auto block ranges from china > > This is not an optimal approach, and most providers are unlikely to engage in such behavior due to its potential negative impact (I'm assuming you mean via S/RTBH and/or flowspec). > > ----------------------------------- > Roland Dobbins From colinj at gt86car.org.uk Wed Mar 18 11:27:57 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Wed, 18 Mar 2015 11:27:57 +0000 Subject: Getting hit hard by CHINANET In-Reply-To: References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> <55090C8A.1050804@seacom.mu> <55091C04.8090504@seacom.mu> Message-ID: <0239C42F-C84D-4BDB-A8BD-D093519FD3AF@gt86car.org.uk> interesting use of ripe atlas info :) was thinking same myself colin Sent from my iPhone > On 18 Mar 2015, at 10:04, "Roland Dobbins" wrote: > > >> On 18 Mar 2015, at 17:00, Roland Dobbins wrote: >> >> This is not an optimal approach, and most providers are unlikely to engage in such behavior due to its potential negative impact (I'm assuming you mean via S/RTBH and/or flowspec). > > Here's one counterexample: > > > > ----------------------------------- > Roland Dobbins From eric.sieg at gmail.com Wed Mar 18 13:26:34 2015 From: eric.sieg at gmail.com (Eric Sieg) Date: Wed, 18 Mar 2015 09:26:34 -0400 Subject: Looking for AT&T (Wireless) to contact me off-list. Message-ID: From tom.kac at gmail.com Wed Mar 18 13:40:09 2015 From: tom.kac at gmail.com (Tom Kacprzynski) Date: Wed, 18 Mar 2015 08:40:09 -0500 Subject: CHI-NOG 05 Agenda and Registration Message-ID: We are pleased to announce that the Chicago Network Operators Group will host their 5th meeting (CHI-NOG 05) on May 14th, 2015 in Chicago, IL. Conference agenda can be found at http://chinog.org/meetings/chi-nog-05/agenda/ Registration is still open. For more details please see http://ching.org/meetings/chi-nog-05 Thank you. From rjoffe at centergate.com Wed Mar 18 20:33:46 2015 From: rjoffe at centergate.com (Rodney Joffe) Date: Wed, 18 Mar 2015 16:33:46 -0400 Subject: Looking for AT&T (Wireless) to contact me off-list. In-Reply-To: References: Message-ID: On Mar 18, 2015, at 9:26 AM, Eric Sieg wrote: > Speaking as an unaffiliated, irrelevant, old-timer, but hoping to assist you and all of those who have preceded you and who will no doubt follow you, I have generally found that providing your affiliation and context sometimes helps solicit a response, especially when sending a plain email from a gmail account. And sometimes, of course, it hurts ;-) From anthony.kosednar at gmail.com Wed Mar 18 01:51:24 2015 From: anthony.kosednar at gmail.com (Anthony Kosednar) Date: Tue, 17 Mar 2015 18:51:24 -0700 Subject: Getting hit hard by CHINANET In-Reply-To: References: Message-ID: Hello Terrance, I've seen this IP several times in our threat logs.It is a known threat and has even been called out by Norse ( http://www.norse-corp.com/blog-thursday-140828.html). I recommend blocking the ip at the edge of your network. If it becomes more of a problem, ask one of your upstream providers to block him you upstream of you as well. They shouldn't hesitate as it is clearly labeled a known threat. Thanks, - Anthony On Mon, Mar 16, 2015 at 7:06 PM, Terrance Devor wrote: > Hello Everyone, > > I really hope this is not against group policy etc.. however our network is > being hit > hard by a China IP for the past 6 months. Our systems our up to date, > passwordless > ssh etc.. but they're DOS attempts are getting more and more aggressive. > Tried to > contact their phone number to no success (not valid). Emails don't get any > response. > The IP is 218.77.79.43. Do we have any options? > > Terrance > From ecrogers at precisionds.com Wed Mar 18 12:32:22 2015 From: ecrogers at precisionds.com (Eric Rogers) Date: Wed, 18 Mar 2015 08:32:22 -0400 Subject: Getting hit hard by CHINANET References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> <55090C8A.1050804@seacom.mu> <55091C04.8090504@seacom.mu> Message-ID: We are using Mikrotik for a BGP blackhole server that collects BOGONs from CYMRU and we also have our servers (web, email, etc.) use fail2ban to add a bad IP to the Mikrotik. We then use BGP on all our core routers to null route those IPs. The ban-time is for a few days, and totally dynamic, so it isn't a permanent ban. Seems to have cut down on the attempts considerably. Eric Rogers PDSConnect www.pdsconnect.me (317) 831-3000 x200 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins Sent: Wednesday, March 18, 2015 6:04 AM To: nanog at nanog.org Subject: Re: Getting hit hard by CHINANET On 18 Mar 2015, at 17:00, Roland Dobbins wrote: > This is not an optimal approach, and most providers are unlikely to > engage in such behavior due to its potential negative impact (I'm > assuming you mean via S/RTBH and/or flowspec). Here's one counterexample: ----------------------------------- Roland Dobbins From lyle at lcrcomputer.net Thu Mar 19 21:02:00 2015 From: lyle at lcrcomputer.net (Lyle Giese) Date: Thu, 19 Mar 2015 16:02:00 -0500 Subject: Comodo Message-ID: <550B3948.6010401@lcrcomputer.net> This is a one off message and I will not reply to any public posts. But it's gotten to the point that I am quite angry by the underhanded sales tactics by a company that I once considered reputable. I have available discounted SSL certificates via a small reseller account with SRSPlus. I get a very good price via this service on Thawte's ssl certs. Comodo sales droids are now calling my customers to offer them discounted SSL certificate renewals. However they are quoting them retail prices. I am paying well under posted retail prices and generally sell them to my customers at about 50% of what Comodo is claiming to be a discounted price. Comodo is cold calling business owners that have no idea what a SSL cert is for a website and trying to sell them something they know nothing about. My customers contact me for their website needs and I take it from there. I bill them after I pay for the cert via my resellers discount program. Enough. Just fair warning to rest of this list about this practice from Comodo. End of subject from me. Lyle Giese LCR Computer Services, Inc. From cscora at apnic.net Fri Mar 20 18:11:52 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 21 Mar 2015 04:11:52 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201503201811.t2KIBqVg010968@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, 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 21 Mar, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 537248 Prefixes after maximum aggregation (per Origin AS): 205386 Deaggregation factor: 2.62 Unique aggregates announced (without unneeded subnets): 262112 Total ASes present in the Internet Routing Table: 49750 Prefixes per ASN: 10.80 Origin-only ASes present in the Internet Routing Table: 36563 Origin ASes announcing only one prefix: 16283 Transit ASes present in the Internet Routing Table: 6263 Transit-only ASes present in the Internet Routing Table: 168 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 59 Max AS path prepend of ASN ( 55644) 56 Prefixes from unregistered ASNs in the Routing Table: 1246 Unregistered ASNs in the Routing Table: 420 Number of 32-bit ASNs allocated by the RIRs: 8933 Number of 32-bit ASNs visible in the Routing Table: 6924 Prefixes from 32-bit ASNs in the Routing Table: 25162 Number of bogon 32-bit ASNs visible in the Routing Table: 2 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 386 Number of addresses announced to Internet: 2735724964 Equivalent to 163 /8s, 15 /16s and 217 /24s Percentage of available address space announced: 73.9 Percentage of allocated address space announced: 73.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.2 Total number of prefixes smaller than registry allocations: 181358 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 132643 Total APNIC prefixes after maximum aggregation: 38539 APNIC Deaggregation factor: 3.44 Prefixes being announced from the APNIC address blocks: 138315 Unique aggregates announced from the APNIC address blocks: 56317 APNIC Region origin ASes present in the Internet Routing Table: 5029 APNIC Prefixes per ASN: 27.50 APNIC Region origin ASes announcing only one prefix: 1206 APNIC Region transit ASes present in the Internet Routing Table: 874 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 59 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1356 Number of APNIC addresses announced to Internet: 746249984 Equivalent to 44 /8s, 122 /16s and 223 /24s Percentage of available APNIC address space announced: 87.2 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-64098, 131072-135580 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: 177154 Total ARIN prefixes after maximum aggregation: 87591 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 179130 Unique aggregates announced from the ARIN address blocks: 84060 ARIN Region origin ASes present in the Internet Routing Table: 16522 ARIN Prefixes per ASN: 10.84 ARIN Region origin ASes announcing only one prefix: 6075 ARIN Region transit ASes present in the Internet Routing Table: 1704 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 377 Number of ARIN addresses announced to Internet: 1062603040 Equivalent to 63 /8s, 86 /16s and 9 /24s Percentage of available ARIN address space announced: 56.2 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: 130585 Total RIPE prefixes after maximum aggregation: 65064 RIPE Deaggregation factor: 2.01 Prefixes being announced from the RIPE address blocks: 136953 Unique aggregates announced from the RIPE address blocks: 84165 RIPE Region origin ASes present in the Internet Routing Table: 17924 RIPE Prefixes per ASN: 7.64 RIPE Region origin ASes announcing only one prefix: 8174 RIPE Region transit ASes present in the Internet Routing Table: 2957 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3523 Number of RIPE addresses announced to Internet: 694199940 Equivalent to 41 /8s, 96 /16s and 166 /24s Percentage of available RIPE address space announced: 100.9 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: 58812 Total LACNIC prefixes after maximum aggregation: 11136 LACNIC Deaggregation factor: 5.28 Prefixes being announced from the LACNIC address blocks: 68652 Unique aggregates announced from the LACNIC address blocks: 32063 LACNIC Region origin ASes present in the Internet Routing Table: 2414 LACNIC Prefixes per ASN: 28.44 LACNIC Region origin ASes announcing only one prefix: 621 LACNIC Region transit ASes present in the Internet Routing Table: 492 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1567 Number of LACNIC addresses announced to Internet: 168071168 Equivalent to 10 /8s, 4 /16s and 144 /24s Percentage of available LACNIC address space announced: 100.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + 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: 12709 Total AfriNIC prefixes after maximum aggregation: 3012 AfriNIC Deaggregation factor: 4.22 Prefixes being announced from the AfriNIC address blocks: 13812 Unique aggregates announced from the AfriNIC address blocks: 5157 AfriNIC Region origin ASes present in the Internet Routing Table: 739 AfriNIC Prefixes per ASN: 18.69 AfriNIC Region origin ASes announcing only one prefix: 207 AfriNIC Region transit ASes present in the Internet Routing Table: 159 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 101 Number of AfriNIC addresses announced to Internet: 64104960 Equivalent to 3 /8s, 210 /16s and 42 /24s Percentage of available AfriNIC address space announced: 63.7 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 2870 11553 913 Korea Telecom 17974 2797 904 78 PT Telekomunikasi Indonesia 7545 2541 336 126 TPG Telecom Limited 4755 1998 422 212 TATA Communications formerly 4538 1761 4190 71 China Education and Research 9829 1694 1326 39 National Internet Backbone 9808 1552 8717 28 Guangdong Mobile Communicatio 4808 1472 2243 438 CNCGROUP IP network China169 9583 1398 132 556 Sify Limited 9498 1309 334 94 BHARTI Airtel Ltd. 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 3024 2955 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 3356 2549 10683 477 Level 3 Communications, Inc. 18566 2041 379 183 MegaPath Corporation 20115 1848 1831 428 Charter Communications 6983 1704 866 245 EarthLink, Inc. 4323 1618 1021 408 tw telecom holdings, inc. 30036 1529 313 496 Mediacom Communications Corp 701 1391 11272 679 MCI Communications Services, 22561 1332 412 242 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 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 1976 303 361 TELLCOM ILETISIM HIZMETLERI A 20940 1633 634 1215 Akamai International B.V. 8402 1358 544 15 OJSC "Vimpelcom" 6849 1213 356 24 JSC "Ukrtelecom" 31148 1046 45 21 Freenet Ltd. 13188 1022 96 72 TOV "Bank-Inform" 8551 903 373 48 Bezeq International-Ltd 12479 883 799 85 France Telecom Espana SA 9198 854 349 25 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 10620 3152 514 196 Telmex Colombia S.A. 28573 2331 2171 122 NET Servi�os de Comunica��o S 7303 1781 1178 234 Telecom Argentina S.A. 6147 1581 374 30 Telefonica del Peru S.A.A. 8151 1553 3136 452 Uninet S.A. de C.V. 6503 1207 421 57 Axtel, S.A.B. de C.V. 7738 1001 1882 42 Telemar Norte Leste S.A. 26615 955 2325 35 Tim Celular S.A. 3816 918 408 152 COLOMBIA TELECOMUNICACIONES S 18881 866 1036 22 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1638 958 13 TE-AS 24863 953 284 27 Link Egypt (Link.NET) 36903 479 241 90 Office National des Postes et 36992 406 1101 32 ETISALAT MISR 37492 317 159 70 Orange Tunisie 24835 299 144 9 Vodafone Data 3741 250 921 209 Internet Solutions 29571 233 21 13 Cote d'Ivoire Telecom 36947 191 807 13 Telecom Algeria 15706 172 32 6 Sudatel (Sudan Telecom Co. Lt 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 10620 3152 514 196 Telmex Colombia S.A. 22773 3024 2955 141 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 4766 2870 11553 913 Korea Telecom 17974 2797 904 78 PT Telekomunikasi Indonesia 3356 2549 10683 477 Level 3 Communications, Inc. 7545 2541 336 126 TPG Telecom Limited 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2331 2171 122 NET Servi�os de Comunica��o S 18566 2041 379 183 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 22773 3024 2883 Cox Communications Inc. 6389 2891 2840 BellSouth.net Inc. 17974 2797 2719 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 7545 2541 2415 TPG Telecom Limited 28573 2331 2209 NET Servi�os de Comunica��o S 3356 2549 2072 Level 3 Communications, Inc. 4766 2870 1957 Korea Telecom 18566 2041 1858 MegaPath Corporation 4755 1998 1786 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 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 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 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 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 Bitfinite LLC 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.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.15.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:12 /10:34 /11:92 /12:264 /13:506 /14:1000 /15:1720 /16:12965 /17:7188 /18:12207 /19:25237 /20:35850 /21:38583 /22:58302 /23:50708 /24:289609 /25:1087 /26:1161 /27:661 /28:14 /29:11 /30:8 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2237 3024 Cox Communications Inc. 18566 1996 2041 MegaPath Corporation 6389 1671 2891 BellSouth.net Inc. 30036 1375 1529 Mediacom Communications Corp 6983 1351 1704 EarthLink, Inc. 34984 1281 1976 TELLCOM ILETISIM HIZMETLERI A 6147 1129 1581 Telefonica del Peru S.A.A. 10620 1110 3152 Telmex Colombia S.A. 11492 1101 1165 CABLE ONE, INC. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1535 2:676 3:1 4:95 5:1754 6:21 8:1435 12:1829 13:4 14:1310 15:17 16:2 17:45 18:21 20:48 23:1202 24:1680 27:1856 31:1506 32:39 33:2 34:5 35:3 36:120 37:1878 38:1012 39:9 40:238 41:2979 42:260 43:1224 44:27 45:311 46:2134 47:34 49:843 50:794 52:12 54:69 55:7 56:8 57:37 58:1214 59:685 60:467 61:1782 62:1316 63:1913 64:4446 65:2264 66:4113 67:2043 68:1076 69:3256 70:955 71:442 72:1968 74:2602 75:319 76:406 77:1492 78:1249 79:806 80:1323 81:1354 82:822 83:675 84:688 85:1354 86:386 87:1063 88:514 89:1776 90:151 91:5945 92:830 93:2183 94:1949 95:2088 96:428 97:343 98:1071 99:45 100:68 101:802 103:7021 104:1422 105:63 106:222 107:903 108:617 109:1999 110:1083 111:1480 112:763 113:1052 114:837 115:1253 116:1351 117:1013 118:1688 119:1442 120:443 121:1050 122:2180 123:1728 124:1506 125:1583 128:623 129:379 130:380 131:1154 132:487 133:167 134:416 135:111 136:305 137:309 138:538 139:164 140:237 141:421 142:640 143:483 144:566 145:107 146:716 147:588 148:1108 149:447 150:556 151:609 152:492 153:239 154:387 155:742 156:407 157:331 158:269 159:978 160:374 161:645 162:1938 163:414 164:659 165:674 166:285 167:689 168:1270 169:154 170:1436 171:240 172:41 173:1532 174:702 175:651 176:1432 177:3803 178:2073 179:873 180:1902 181:1644 182:1732 183:614 184:736 185:3122 186:2621 187:1803 188:1999 189:1591 190:7617 191:952 192:8166 193:5603 194:4092 195:3655 196:1718 197:1084 198:5508 199:5514 200:6540 201:3023 202:9507 203:9065 204:4627 205:2747 206:2983 207:2999 208:3940 209:3925 210:3514 211:1862 212:2485 213:2268 214:868 215:70 216:5544 217:1806 218:676 219:451 220:1429 221:789 222:466 223:658 End of report From blair.trosper at gmail.com Fri Mar 20 20:04:46 2015 From: blair.trosper at gmail.com (Blair Trosper) Date: Fri, 20 Mar 2015 15:04:46 -0500 Subject: Comodo In-Reply-To: <550B3948.6010401@lcrcomputer.net> References: <550B3948.6010401@lcrcomputer.net> Message-ID: Seconded. They were blocked two weeks ago on my many numbers after I filed a complaint with the FTC here in the US...quite a fall from grace indeed. On Thu, Mar 19, 2015 at 4:02 PM, Lyle Giese wrote: > This is a one off message and I will not reply to any public posts. But > it's gotten to the point that I am quite angry by the underhanded sales > tactics by a company that I once considered reputable. > > I have available discounted SSL certificates via a small reseller account > with SRSPlus. I get a very good price via this service on Thawte's ssl > certs. > > Comodo sales droids are now calling my customers to offer them discounted > SSL certificate renewals. However they are quoting them retail prices. I > am paying well under posted retail prices and generally sell them to my > customers at about 50% of what Comodo is claiming to be a discounted price. > > Comodo is cold calling business owners that have no idea what a SSL cert > is for a website and trying to sell them something they know nothing > about. My customers contact me for their website needs and I take it from > there. I bill them after I pay for the cert via my resellers discount > program. > > Enough. Just fair warning to rest of this list about this practice from > Comodo. End of subject from me. > > Lyle Giese > LCR Computer Services, Inc. > From woody at pch.net Fri Mar 20 21:55:14 2015 From: woody at pch.net (Bill Woodcock) Date: Fri, 20 Mar 2015 16:55:14 -0500 Subject: Traceroute from within Colombia? Message-ID: Sorry to spam the list with this, but I have a problem that I can’t otherwise solve for myself. If anyone is able to perform traceroutes to the following addresses _from within Colombia_ and email me the results, I’d very much appreciate it, and will owe a favor. 199.7.91.13 192.203.230.10 199.7.83.42 156.154.100.25 156.154.101.25 156.154.102.25 156.154.103.25 156.154.104.25 156.154.105.25 2001:500:2D::D 2001:500:3::42 2001:502:2eda:0:0:0:0:21 2001:502:ad09:0:0:0:0:21 2610:a1:1009:0:0:0:0:21 2610:a1:1010:0:0:0:0:21 2610:a1:1011:0:0:0:0:21 2610:a1:1012:0:0:0:0:21 These are all anycast addresses, so traceroutes performed from machines outside Colombia won’t help me, unfortunately, since they’d be going to other anycast instances. And yes, I’ve already looked for public looking-glasses and traceroute servers; the three I was able to find were all offline. For those who are curious, these are nameservers which may be reachable through NAP Colombia, and I’m trying to verify that. Much appreciated, and my apologies for using the list this way. -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 cidr-report at potaroo.net Fri Mar 20 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Mar 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201503202200.t2KM00r4005598@wattle.apnic.net> This report has been generated at Fri Mar 20 21:14:21 2015 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 13-03-15 544187 299963 14-03-15 544311 299727 15-03-15 544349 299895 16-03-15 544469 300150 17-03-15 544505 300346 18-03-15 544609 300818 19-03-15 544954 301295 20-03-15 544650 297815 AS Summary 49996 Number of ASes in routing system 19980 Number of ASes announcing only one prefix 3152 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120946176 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'). --- 20Mar15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 544491 297892 246599 45.3% All ASes AS22773 3025 170 2855 94.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2890 69 2821 97.6% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2797 78 2719 97.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2473 23 2450 99.1% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2364 315 2049 86.7% NET Servi�os de Comunica��o S.A.,BR AS4755 1996 261 1735 86.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4766 2871 1321 1550 54.0% KIXS-AS-KR Korea Telecom,KR AS7303 1780 283 1497 84.1% Telecom Argentina S.A.,AR AS9808 1552 67 1485 95.7% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS6983 1702 248 1454 85.4% ITCDELTA - Earthlink, Inc.,US AS6147 1581 158 1423 90.0% Telefonica del Peru S.A.A.,PE AS10620 3152 1794 1358 43.1% Telmex Colombia S.A.,CO AS20115 1849 499 1350 73.0% CHARTER-NET-HKY-NC - Charter Communications,US AS8402 1344 27 1317 98.0% CORBINA-AS OJSC "Vimpelcom",RU AS8452 1848 575 1273 68.9% TE-AS TE-AS,EG AS4323 1625 410 1215 74.8% TWTC - tw telecom holdings, inc.,US AS9498 1309 111 1198 91.5% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2040 869 1171 57.4% MEGAPATH5-US - MegaPath Corporation,US AS7545 2559 1408 1151 45.0% TPG-INTERNET-AP TPG Telecom Limited,AU AS7552 1165 61 1104 94.8% VIETEL-AS-AP Viettel Corporation,VN AS34984 1978 882 1096 55.4% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS22561 1332 251 1081 81.2% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS3356 2553 1490 1063 41.6% LEVEL3 - Level 3 Communications, Inc.,US AS6849 1210 170 1040 86.0% UKRTELNET JSC UKRTELECOM,UA AS7738 1000 84 916 91.6% Telemar Norte Leste S.A.,BR AS38285 983 115 868 88.3% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS18881 866 23 843 97.3% Global Village Telecom,BR AS4538 1779 957 822 46.2% ERX-CERNET-BKB China Education and Research Network Center,CN AS26615 955 141 814 85.2% Tim Celular S.A.,BR AS4780 1065 259 806 75.7% SEEDNET Digital United Inc.,TW Total 55643 13119 42524 76.4% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.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.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.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 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 45.41.128.0/18 AS62874 WEB2OBJECTS-LLC - Web2Objects LLC,US 45.41.192.0/18 AS63262 HOSTAWARE - Univera Network,US 64.25.16.0/23 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.20.0/24 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.21.0/24 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.22.0/24 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.24.0/23 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 AS19535 - JetBlue Airways Corporation,US 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 64.140.128.0/18 AS7385 INTEGRATELECOM - Integra Telecom, 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.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 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 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 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.114.184.0/22 AS19888 -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.91.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 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 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.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET 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.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.224.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 103.247.19.0/24 AS18107 ASN-IPSYSTEMS-AP IP SYSTEMS,AU 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 103.253.164.0/23 AS13317 103.255.56.0/22 AS18097 DCN D.C.N. Corporation,JP 103.255.132.0/22 AS18097 DCN D.C.N. Corporation,JP 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 113.197.106.0/24 AS15169 GOOGLE - Google Inc.,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.54.184.0/21 AS59092 KRONOS kronos.Co.,Ltd.,JP 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 167.146.16.0/21 AS22527 -Reserved AS-,ZZ 167.146.26.0/23 AS22527 -Reserved AS-,ZZ 167.146.28.0/23 AS22527 -Reserved AS-,ZZ 167.146.32.0/20 AS22527 -Reserved AS-,ZZ 167.146.44.0/24 AS22527 -Reserved AS-,ZZ 167.146.48.0/22 AS22527 -Reserved AS-,ZZ 167.146.90.0/24 AS22527 -Reserved AS-,ZZ 167.146.93.0/24 AS22527 -Reserved AS-,ZZ 167.146.94.0/24 AS22527 -Reserved AS-,ZZ 167.146.100.0/24 AS22527 -Reserved AS-,ZZ 167.146.104.0/24 AS22527 -Reserved AS-,ZZ 167.146.105.0/24 AS22527 -Reserved AS-,ZZ 167.146.128.0/20 AS22527 -Reserved AS-,ZZ 167.146.137.0/24 AS22527 -Reserved AS-,ZZ 167.146.144.0/20 AS22527 -Reserved AS-,ZZ 167.146.160.0/20 AS22527 -Reserved AS-,ZZ 167.146.200.0/22 AS22527 -Reserved AS-,ZZ 167.146.204.0/24 AS22527 -Reserved AS-,ZZ 167.146.205.0/24 AS22527 -Reserved AS-,ZZ 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 173.224.172.0/22 AS14828 HBCI-1999TA - Hiawatha Broadband Communications, Inc,US 185.17.96.0/24 AS51088 A2B A2B IP B.V.,NL 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 185.92.252.0/22 AS20860 IOMART-AS Iomart,GB 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,FR 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.155.48.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 192.155.57.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.58.0/23 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.61.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.65.0/24 AS6128 CABLE-NET-1 - Cablevision Systems Corp.,US 192.155.66.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.67.0/24 AS174 COGENT-174 - Cogent Communications,US 192.155.68.0/24 AS174 COGENT-174 - Cogent Communications,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 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.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 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.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age 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.176.147.0/24 AS49951 -Reserved AS-,ZZ 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 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.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS 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.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.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.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,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.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.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 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 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.71.17.0/24 AS11268 -Reserved AS-,ZZ 198.71.18.0/23 AS11268 -Reserved AS-,ZZ 198.71.20.0/23 AS11268 -Reserved AS-,ZZ 198.71.22.0/24 AS11268 -Reserved AS-,ZZ 198.71.26.0/24 AS11268 -Reserved AS-,ZZ 198.71.27.0/24 AS11268 -Reserved AS-,ZZ 198.73.226.0/23 AS62839 -Reserved AS-,ZZ 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.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 199.30.132.0/22 AS26003 -Reserved AS-,ZZ 199.30.136.0/23 AS46636 NATCOWEB - NatCoWeb Corp.,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.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 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.201.64.0/22 AS54115 -Reserved AS-,ZZ 199.201.66.0/24 AS54115 -Reserved AS-,ZZ 199.204.144.0/21 AS36007 -Reserved AS-,ZZ 199.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 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 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 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.122.134.0/24 AS38615 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 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.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.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 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.189.0.0/19 AS46879 -Reserved AS-,ZZ 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.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.83.88.0/22 AS15697 BT-BS BT Ignite Intercontinental Satellite Video Streaming,GB 208.83.90.0/23 AS15697 BT-BS BT Ignite Intercontinental Satellite Video Streaming,GB 208.83.91.0/24 AS12910 -Reserved AS-,ZZ 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.233.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.93.216.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 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 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,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.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,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.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 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 Mar 20 22:00:01 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Mar 2015 22:00:01 GMT Subject: BGP Update Report Message-ID: <201503202200.t2KM01UB005613@wattle.apnic.net> BGP Update Report Interval: 12-Mar-15 -to- 19-Mar-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS23752 231109 5.4% 2027.3 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS61894 155165 3.6% 51721.7 -- FreeBSD Brasil LTDA,BR 3 - AS9829 139096 3.2% 91.2 -- BSNL-NIB National Internet Backbone,IN 4 - AS36947 85741 2.0% 625.8 -- ALGTEL-AS,DZ 5 - AS7303 48963 1.1% 29.8 -- Telecom Argentina S.A.,AR 6 - AS53563 48252 1.1% 16084.0 -- XPLUSONE - X Plus One Solutions, Inc.,US 7 - AS13118 47796 1.1% 1016.9 -- ASN-YARTELECOM OJSC Rostelecom,RU 8 - AS33529 37639 0.9% 7527.8 -- PEAK-WEB-HOSTING - Peak Web Hosting Inc.,US 9 - AS28024 37257 0.9% 24.4 -- Nuevatel PCS de Bolivia S.A.,BO 10 - AS17916 35309 0.8% 2206.8 -- CSC-IGN-AUNZ-AP Computer Sciences Corporation,AU 11 - AS3816 30422 0.7% 63.5 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 12 - AS17974 29679 0.7% 11.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 13 - AS22884 29194 0.7% 79.1 -- Iusacell PCS de Mexico, S.A. de C.V.,MX 14 - AS8402 26234 0.6% 31.3 -- CORBINA-AS OJSC "Vimpelcom",RU 15 - AS42081 25960 0.6% 1854.3 -- SPEEDY-NET-AS Speedy net EAD,BG 16 - AS11714 23018 0.5% 298.9 -- ASN-UNEB - University of Nebraska Central Administration,US 17 - AS7545 22786 0.5% 11.7 -- TPG-INTERNET-AP TPG Telecom Limited,AU 18 - AS23342 22307 0.5% 587.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 19 - AS8452 22027 0.5% 13.3 -- TE-AS TE-AS,EG 20 - AS24197 21577 0.5% 392.3 -- BIGNET-AS-ID Elka Prakarsa Utama, PT,ID TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS61894 155165 3.6% 51721.7 -- FreeBSD Brasil LTDA,BR 2 - AS197914 18643 0.4% 18643.0 -- STOCKHO-AS Stockho Hosting SARL,FR 3 - AS53563 48252 1.1% 16084.0 -- XPLUSONE - X Plus One Solutions, Inc.,US 4 - AS47680 13503 0.3% 13503.0 -- NHCS EOBO Limited,IE 5 - AS18135 10831 0.2% 10831.0 -- BTV BTV Cable television,JP 6 - AS61039 8685 0.2% 8685.0 -- ZMZ OAO ZMZ,RU 7 - AS46336 8556 0.2% 8556.0 -- GOODVILLE - Goodville Mutual Casualty Company,US 8 - AS33529 37639 0.9% 7527.8 -- PEAK-WEB-HOSTING - Peak Web Hosting Inc.,US 9 - AS25563 18884 0.4% 6294.7 -- WEBLAND-AS Webland AG, Autonomous System,CH 10 - AS33356 12473 0.3% 6236.5 -- CTWS - Eagle-Tech Systems,US 11 - AS39913 5019 0.1% 5019.0 -- COTEWA-AS Manuel Wannemacher,DE 12 - AS57573 8077 0.2% 4038.5 -- GREENATOM CJSC "Greenatom",RU 13 - AS33721 3745 0.1% 3745.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 14 - AS198053 3439 0.1% 3439.0 -- AMTEL VECTRA S.A.,PL 15 - AS62174 3084 0.1% 3084.0 -- INTERPAN-AS INTERPAN LTD.,BG 16 - AS54465 8601 0.2% 2867.0 -- QPM-AS-1 - QuickPlay Media Inc.,US 17 - AS198581 2294 0.1% 2294.0 -- CEKAB-NET EDB Card Services AB,SE 18 - AS17916 35309 0.8% 2206.8 -- CSC-IGN-AUNZ-AP Computer Sciences Corporation,AU 19 - AS131713 8433 0.2% 2108.2 -- IDNIC-SPICELINK-AS-ID PT Sano Komunikasi,ID 20 - AS21669 10275 0.2% 2055.0 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 177.10.158.0/24 155047 3.5% AS61894 -- FreeBSD Brasil LTDA,BR 2 - 202.70.88.0/21 115671 2.6% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 202.70.64.0/21 114506 2.6% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 105.96.0.0/22 76303 1.7% AS36947 -- ALGTEL-AS,DZ 5 - 199.38.164.0/23 48248 1.1% AS53563 -- XPLUSONE - X Plus One Solutions, Inc.,US 6 - 93.181.216.0/21 47503 1.1% AS13118 -- ASN-YARTELECOM OJSC Rostelecom,RU 7 - 69.194.4.0/24 37633 0.8% AS33529 -- PEAK-WEB-HOSTING - Peak Web Hosting Inc.,US 8 - 64.29.130.0/24 21912 0.5% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 9 - 130.0.192.0/21 18643 0.4% AS197914 -- STOCKHO-AS Stockho Hosting SARL,FR 10 - 91.193.202.0/24 16823 0.4% AS42081 -- SPEEDY-NET-AS Speedy net EAD,BG 11 - 88.87.160.0/19 13503 0.3% AS47680 -- NHCS EOBO Limited,IE 12 - 67.59.81.0/24 12469 0.3% AS33356 -- CTWS - Eagle-Tech Systems,US 13 - 20.134.248.0/24 11968 0.3% AS17916 -- CSC-IGN-AUNZ-AP Computer Sciences Corporation,AU 14 - 20.139.64.0/20 11813 0.3% AS17916 -- CSC-IGN-AUNZ-AP Computer Sciences Corporation,AU 15 - 20.134.64.0/20 11467 0.3% AS17916 -- CSC-IGN-AUNZ-AP Computer Sciences Corporation,AU 16 - 95.47.46.0/24 10838 0.2% AS61308 -- PVONET-AS PVONET LTD,RU 17 - 42.83.48.0/20 10831 0.2% AS18135 -- BTV BTV Cable television,JP 18 - 209.212.8.0/24 10249 0.2% AS21669 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 19 - 192.58.232.0/24 9972 0.2% AS6629 -- NOAA-AS - NOAA,US 20 - 91.235.169.0/24 8685 0.2% AS61039 -- ZMZ OAO ZMZ,RU 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 jared at puck.Nether.net Fri Mar 20 22:05:10 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Fri, 20 Mar 2015 18:05:10 -0400 Subject: Traceroute from within Colombia? In-Reply-To: References: Message-ID: <20150320220510.GA3933@puck.nether.net> Bill, I went and quickly created a traceroute to the first one with RIPE Atlas credits for you. Let me know if you need some, I have a few tens of millions of credits that I will give out to people who need them. https://atlas.ripe.net/measurements/1902119/ - Jared On Fri, Mar 20, 2015 at 04:55:14PM -0500, Bill Woodcock wrote: > Sorry to spam the list with this, but I have a problem that I can’t otherwise solve for myself. > > If anyone is able to perform traceroutes to the following addresses _from within Colombia_ and email me the results, I’d very much appreciate it, and will owe a favor. > > 199.7.91.13 > 192.203.230.10 > 199.7.83.42 > 156.154.100.25 > 156.154.101.25 > 156.154.102.25 > 156.154.103.25 > 156.154.104.25 > 156.154.105.25 > 2001:500:2D::D > 2001:500:3::42 > 2001:502:2eda:0:0:0:0:21 > 2001:502:ad09:0:0:0:0:21 > 2610:a1:1009:0:0:0:0:21 > 2610:a1:1010:0:0:0:0:21 > 2610:a1:1011:0:0:0:0:21 > 2610:a1:1012:0:0:0:0:21 > > These are all anycast addresses, so traceroutes performed from machines outside Colombia won’t help me, unfortunately, since they’d be going to other anycast instances. And yes, I’ve already looked for public looking-glasses and traceroute servers; the three I was able to find were all offline. For those who are curious, these are nameservers which may be reachable through NAP Colombia, and I’m trying to verify that. > > Much appreciated, and my apologies for using the list this way. > > -Bill > > > > -- 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 m4rtntns at gmail.com Sun Mar 22 02:05:35 2015 From: m4rtntns at gmail.com (Martin T) Date: Sun, 22 Mar 2015 04:05:35 +0200 Subject: (network)technologies used by NSA for data collection Message-ID: Hi, I watched "Citizenfour"(imdb.com/title/tt4044364/) documentary and at 41:12 Edward Snowden gives a brief overview of some of the leaked documents to journalists Glenn Greenwald and Ewen MacAskill. At 42:57 Snowden mentions devices which are able to collect data at rate of 1Tbps. This was in 2011. Screen-shots from the movie can be seen here: https://nsa.gov1.info/dni/2014/tumult.jpg Third slide looks like some sort of vendor product roadmap :) Just out of curiosity, what kind of equipment those might be? Is it realistic that NSA/DoD are able to produce their own hardware? Let alone custom silicon like Cisco or Juniper are. Or do they use off the self hardware.. In addition, it's relatively easy to install a passive fiber optical tap for a submarine cable, but how do you get information out of it? I mean all the different wavelengths(CWDM/DWDM) within the same cable, line rates(up to 100GigE), circuit switched and packet switched technologies which those devices should support.. In addition, how(bandwidth and network wise) to transport this data to data analysis and storage equipment if it collected far away from USA.. Some of those questions or thoughts might be naive and stupid, but that's what crossed my mind when I watched the documentary. Maybe somebody, who has done more research in this field, could clarify. thanks, Martin From jason at rice.edu Sun Mar 22 02:27:22 2015 From: jason at rice.edu (Jason Bothe) Date: Sat, 21 Mar 2015 21:27:22 -0500 Subject: (network)technologies used by NSA for data collection In-Reply-To: References: Message-ID: <295EFF74-F847-48C8-85BD-80821AA7479D@rice.edu> They're Narus (Boeing now) STA 6400s most likely. They've been using these for a few years now. Jason Bothe, Manager of Networking Rice University o +1 713 348 5500 m +1 713 703 3552 jason at rice.edu > On Mar 21, 2015, at 21:05, Martin T wrote: > > Hi, > > I watched "Citizenfour"(imdb.com/title/tt4044364/) documentary and at > 41:12 Edward Snowden gives a brief overview of some of the leaked > documents to journalists Glenn Greenwald and Ewen MacAskill. At 42:57 > Snowden mentions devices which are able to collect data at rate of > 1Tbps. This was in 2011. Screen-shots from the movie can be seen here: > https://nsa.gov1.info/dni/2014/tumult.jpg Third slide looks like some > sort of vendor product roadmap :) > Just out of curiosity, what kind of equipment those might be? Is it > realistic that NSA/DoD are able to produce their own hardware? Let > alone custom silicon like Cisco or Juniper are. Or do they use off the > self hardware.. In addition, it's relatively easy to install a passive > fiber optical tap for a submarine cable, but how do you get > information out of it? I mean all the different wavelengths(CWDM/DWDM) > within the same cable, line rates(up to 100GigE), circuit switched and > packet switched technologies which those devices should support.. In > addition, how(bandwidth and network wise) to transport this data to > data analysis and storage equipment if it collected far away from > USA.. > Some of those questions or thoughts might be naive and stupid, but > that's what crossed my mind when I watched the documentary. Maybe > somebody, who has done more research in this field, could clarify. > > > > thanks, > Martin > From jason at rice.edu Sun Mar 22 02:29:13 2015 From: jason at rice.edu (Jason Bothe) Date: Sat, 21 Mar 2015 21:29:13 -0500 Subject: (network)technologies used by NSA for data collection In-Reply-To: References: Message-ID: Sorry. I got trigger happy. The STAs can read data Rey efficiently from multiple wavelengths or grey light simultaneously. Jason Bothe, Manager of Networking Rice University o +1 713 348 5500 m +1 713 703 3552 jason at rice.edu > On Mar 21, 2015, at 21:05, Martin T wrote: > > Hi, > > I watched "Citizenfour"(imdb.com/title/tt4044364/) documentary and at > 41:12 Edward Snowden gives a brief overview of some of the leaked > documents to journalists Glenn Greenwald and Ewen MacAskill. At 42:57 > Snowden mentions devices which are able to collect data at rate of > 1Tbps. This was in 2011. Screen-shots from the movie can be seen here: > https://nsa.gov1.info/dni/2014/tumult.jpg Third slide looks like some > sort of vendor product roadmap :) > Just out of curiosity, what kind of equipment those might be? Is it > realistic that NSA/DoD are able to produce their own hardware? Let > alone custom silicon like Cisco or Juniper are. Or do they use off the > self hardware.. In addition, it's relatively easy to install a passive > fiber optical tap for a submarine cable, but how do you get > information out of it? I mean all the different wavelengths(CWDM/DWDM) > within the same cable, line rates(up to 100GigE), circuit switched and > packet switched technologies which those devices should support.. In > addition, how(bandwidth and network wise) to transport this data to > data analysis and storage equipment if it collected far away from > USA.. > Some of those questions or thoughts might be naive and stupid, but > that's what crossed my mind when I watched the documentary. Maybe > somebody, who has done more research in this field, could clarify. > > > > thanks, > Martin > From nanog at ics-il.net Sun Mar 22 15:35:39 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 22 Mar 2015 10:35:39 -0500 (CDT) Subject: SFP Programmers Message-ID: <20909752.3296.1427038534429.JavaMail.mhammett@ThunderFuck> Where are you guys picking up your SFP programmers? Also, is there a listing anywhere of the vendor codes needed? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com From m4rtntns at gmail.com Sun Mar 22 15:42:06 2015 From: m4rtntns at gmail.com (Martin T) Date: Sun, 22 Mar 2015 17:42:06 +0200 Subject: (network)technologies used by NSA for data collection In-Reply-To: References: Message-ID: I see, thanks! However, this all requires at least some level of Internet operator cooperation? For example if ISP in Northern Europe owns a sub-marine cable between Finland and Sweden and they decide to upgrade their legacy Nortel equipment with STM-64 line-card in both ends of the cable to a Juniper T1600 core routers with 100GigE line-cards, then it's not possible that intelligence agency equipment supports this, is it? In addition, how is the collected data transported for storing in (NSA) datacenters and later analysis? I guess the data collection actually has to be fairly selective simply because the amount of data is so huge. For example take the large Internet Exchanges where several Tbps of data are exchanged in peak hours each day. thanks, Martin On Sun, Mar 22, 2015 at 4:29 AM, Jason Bothe wrote: > Sorry. I got trigger happy. The STAs can read data Rey efficiently from > multiple wavelengths or grey light simultaneously. > > Jason Bothe, Manager of Networking > > Rice University > > > o +1 713 348 5500 > > m +1 713 703 3552 > > jason at rice.edu > > > On Mar 21, 2015, at 21:05, Martin T wrote: > > Hi, > > I watched "Citizenfour"(imdb.com/title/tt4044364/) documentary and at > 41:12 Edward Snowden gives a brief overview of some of the leaked > documents to journalists Glenn Greenwald and Ewen MacAskill. At 42:57 > Snowden mentions devices which are able to collect data at rate of > 1Tbps. This was in 2011. Screen-shots from the movie can be seen here: > https://nsa.gov1.info/dni/2014/tumult.jpg Third slide looks like some > sort of vendor product roadmap :) > Just out of curiosity, what kind of equipment those might be? Is it > realistic that NSA/DoD are able to produce their own hardware? Let > alone custom silicon like Cisco or Juniper are. Or do they use off the > self hardware.. In addition, it's relatively easy to install a passive > fiber optical tap for a submarine cable, but how do you get > information out of it? I mean all the different wavelengths(CWDM/DWDM) > within the same cable, line rates(up to 100GigE), circuit switched and > packet switched technologies which those devices should support.. In > addition, how(bandwidth and network wise) to transport this data to > data analysis and storage equipment if it collected far away from > USA.. > Some of those questions or thoughts might be naive and stupid, but > that's what crossed my mind when I watched the documentary. Maybe > somebody, who has done more research in this field, could clarify. > > > > thanks, > Martin > From mark.tinka at seacom.mu Sun Mar 22 17:24:26 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 22 Mar 2015 19:24:26 +0200 Subject: SFP Programmers In-Reply-To: <20909752.3296.1427038534429.JavaMail.mhammett@ThunderFuck> References: <20909752.3296.1427038534429.JavaMail.mhammett@ThunderFuck> Message-ID: <550EFACA.7070608@seacom.mu> On 22/Mar/15 17:35, Mike Hammett wrote: > Where are you guys picking up your SFP programmers? FlexOptics are good. Mark. From eric at lumaoptics.net Sun Mar 22 18:15:14 2015 From: eric at lumaoptics.net (Eric Litvin) Date: Sun, 22 Mar 2015 11:15:14 -0700 Subject: SFP Programmers In-Reply-To: <550EFACA.7070608@seacom.mu> References: <20909752.3296.1427038534429.JavaMail.mhammett@ThunderFuck> <550EFACA.7070608@seacom.mu> Message-ID: Lumaoptics.com in Northern California has them too. On Sun, Mar 22, 2015 at 10:24 AM, Mark Tinka wrote: > > > On 22/Mar/15 17:35, Mike Hammett wrote: > >> Where are you guys picking up your SFP programmers? >> > > FlexOptics are good. > > Mark. > -- Eric Litvin President eric at lumaoptics.net Direct: (650)440-4382 Mobile:(*650)996-7270* Fax: (650) 618-1870 From nanog at ics-il.net Sun Mar 22 18:24:22 2015 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 22 Mar 2015 13:24:22 -0500 (CDT) Subject: SFP Programmers In-Reply-To: <20909752.3296.1427038534429.JavaMail.mhammett@ThunderFuck> Message-ID: <27205036.3652.1427048638103.JavaMail.mhammett@ThunderFuck> I've received several onlist and offlist replies, but the companies referenced only have the SFPs themselves on their web sites, not the programmers. I'm looking for programmers so in a multi-vendor environment I can stock one kind of SFP (well, SFP+) and change them as required. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mike Hammett" To: "NANOG list" Sent: Sunday, March 22, 2015 10:35:39 AM Subject: SFP Programmers Where are you guys picking up your SFP programmers? Also, is there a listing anywhere of the vendor codes needed? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com From karsten.elfenbein at gmail.com Sun Mar 22 18:51:11 2015 From: karsten.elfenbein at gmail.com (Karsten Elfenbein) Date: Sun, 22 Mar 2015 19:51:11 +0100 Subject: SFP Programmers In-Reply-To: <20909752.3296.1427038534429.JavaMail.mhammett@ThunderFuck> References: <20909752.3296.1427038534429.JavaMail.mhammett@ThunderFuck> Message-ID: Hi, we use stuff from https://www.flexoptix.net/en/ The programmer they/we use is the "flexbox". Karsten 2015-03-22 16:35 GMT+01:00 Mike Hammett : > Where are you guys picking up your SFP programmers? > > Also, is there a listing anywhere of the vendor codes needed? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > From chris at nifry.com Sun Mar 22 19:12:18 2015 From: chris at nifry.com (chris) Date: Sun, 22 Mar 2015 19:12:18 +0000 Subject: SFP Programmers Message-ID: +1 for Flexoptix - great support and sales advice too Sent from Samsung Mobile
-------- Original message --------
From: Karsten Elfenbein
Date:22/03/2015 18:51 (GMT+00:00)
To: Mike Hammett
Cc: NANOG list
Subject: Re: SFP Programmers
Hi, we use stuff from https://www.flexoptix.net/en/ The programmer they/we use is the "flexbox". Karsten 2015-03-22 16:35 GMT+01:00 Mike Hammett : > Where are you guys picking up your SFP programmers? > > Also, is there a listing anywhere of the vendor codes needed? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > From ryan.dirocco at totalserversolutions.com Sun Mar 22 19:15:33 2015 From: ryan.dirocco at totalserversolutions.com (Ryan DiRocco) Date: Sun, 22 Mar 2015 19:15:33 +0000 Subject: SFP Programmers In-Reply-To: References: Message-ID: <1xri4n91td5loby8qbr1amy6.1427051730559@email.android.com> +2 Recently had some programming issues on a batch of optics and support stepped right in and resolved. Sent from my Sprint Samsung Galaxy® Note 4. -------- Original message -------- From: chris Date: 03/22/2015 15:14 (GMT-05:00) To: nanog at nanog.org Subject: Re: SFP Programmers +1 for Flexoptix - great support and sales advice too Sent from Samsung Mobile
-------- Original message --------
From: Karsten Elfenbein
Date:22/03/2015 18:51 (GMT+00:00)
To: Mike Hammett
Cc: NANOG list
Subject: Re: SFP Programmers
Hi, we use stuff from https://www.flexoptix.net/en/ The programmer they/we use is the "flexbox". Karsten 2015-03-22 16:35 GMT+01:00 Mike Hammett : > Where are you guys picking up your SFP programmers? > > Also, is there a listing anywhere of the vendor codes needed? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > From patrick at ianai.net Sun Mar 22 20:41:06 2015 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 22 Mar 2015 16:41:06 -0400 Subject: SFP Programmers In-Reply-To: References: Message-ID: Flexbox rox. But I think you do have to buy their optics, not certain. However, I've never seen a piece of equipment I couldn't use a Flexoptix SFP[+] in. -- TTFN, patrick Composed on a virtual keyboard, please forgive typos. > On Mar 22, 2015, at 15:12, chris wrote: > > > +1 for Flexoptix - great support and sales advice too > > Sent from Samsung Mobile > >
-------- Original message --------
From: Karsten Elfenbein
Date:22/03/2015 18:51 (GMT+00:00)
To: Mike Hammett
Cc: NANOG list
Subject: Re: SFP Programmers
>
Hi, > > we use stuff from https://www.flexoptix.net/en/ > > The programmer they/we use is the "flexbox". > > Karsten > > 2015-03-22 16:35 GMT+01:00 Mike Hammett : >> Where are you guys picking up your SFP programmers? >> >> Also, is there a listing anywhere of the vendor codes needed? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> >> From kilobit at gmail.com Sun Mar 22 21:25:13 2015 From: kilobit at gmail.com (bas) Date: Sun, 22 Mar 2015 22:25:13 +0100 Subject: Traceroute from within Colombia? In-Reply-To: References: Message-ID: Three more from atlas. But I would think PCH has resources to procure and host a RIPE anchor node. https://atlas.ripe.net/about/anchors/ The amount of credits accrued from a single anchor should be enough for all your testing needs. If you are not familiar enough with RIPE Atlas, please create an account and I will transfer you 100.000 credits so you can play around. https://atlas.ripe.net/measurements/1904675/ https://atlas.ripe.net/measurements/1904676/ https://atlas.ripe.net/measurements/1904677/ Good luck. On Fri, Mar 20, 2015 at 10:55 PM, Bill Woodcock wrote: > Sorry to spam the list with this, but I have a problem that I can’t > otherwise solve for myself. > > If anyone is able to perform traceroutes to the following addresses _from > within Colombia_ and email me the results, I’d very much appreciate it, and > will owe a favor. > > 199.7.91.13 > 192.203.230.10 > 199.7.83.42 > 156.154.100.25 > 156.154.101.25 > 156.154.102.25 > 156.154.103.25 > 156.154.104.25 > 156.154.105.25 > 2001:500:2D::D > 2001:500:3::42 > 2001:502:2eda:0:0:0:0:21 > 2001:502:ad09:0:0:0:0:21 > 2610:a1:1009:0:0:0:0:21 > 2610:a1:1010:0:0:0:0:21 > 2610:a1:1011:0:0:0:0:21 > 2610:a1:1012:0:0:0:0:21 > > These are all anycast addresses, so traceroutes performed from machines > outside Colombia won’t help me, unfortunately, since they’d be going to > other anycast instances. And yes, I’ve already looked for public > looking-glasses and traceroute servers; the three I was able to find were > all offline. For those who are curious, these are nameservers which may be > reachable through NAP Colombia, and I’m trying to verify that. > > Much appreciated, and my apologies for using the list this way. > > -Bill > > > > > From woody at pch.net Sun Mar 22 21:36:54 2015 From: woody at pch.net (Bill Woodcock) Date: Sun, 22 Mar 2015 14:36:54 -0700 Subject: Traceroute from within Colombia? In-Reply-To: References: Message-ID: <00158B52-EF9A-4494-80AE-D73BDE2EA4FF@pch.net> PCH does host Atlas nodes. We used the Colombian Atlas nodes, but they weren't sufficient to show what we needed to show. We've collected ten sets of trace routes so far, including those from the three Atlas nodes that were active in Colombia. -Bill > On Mar 22, 2015, at 14:25, bas wrote: > > Three more from atlas. > > But I would think PCH has resources to procure and host a RIPE anchor node. https://atlas.ripe.net/about/anchors/ > The amount of credits accrued from a single anchor should be enough for all your testing needs. > > If you are not familiar enough with RIPE Atlas, please create an account and I will transfer you 100.000 credits so you can play around. > > https://atlas.ripe.net/measurements/1904675/ > https://atlas.ripe.net/measurements/1904676/ > https://atlas.ripe.net/measurements/1904677/ > > Good luck. > >> On Fri, Mar 20, 2015 at 10:55 PM, Bill Woodcock wrote: >> Sorry to spam the list with this, but I have a problem that I can’t otherwise solve for myself. >> >> If anyone is able to perform traceroutes to the following addresses _from within Colombia_ and email me the results, I’d very much appreciate it, and will owe a favor. >> >> 199.7.91.13 >> 192.203.230.10 >> 199.7.83.42 >> 156.154.100.25 >> 156.154.101.25 >> 156.154.102.25 >> 156.154.103.25 >> 156.154.104.25 >> 156.154.105.25 >> 2001:500:2D::D >> 2001:500:3::42 >> 2001:502:2eda:0:0:0:0:21 >> 2001:502:ad09:0:0:0:0:21 >> 2610:a1:1009:0:0:0:0:21 >> 2610:a1:1010:0:0:0:0:21 >> 2610:a1:1011:0:0:0:0:21 >> 2610:a1:1012:0:0:0:0:21 >> >> These are all anycast addresses, so traceroutes performed from machines outside Colombia won’t help me, unfortunately, since they’d be going to other anycast instances. And yes, I’ve already looked for public looking-glasses and traceroute servers; the three I was able to find were all offline. For those who are curious, these are nameservers which may be reachable through NAP Colombia, and I’m trying to verify that. >> >> Much appreciated, and my apologies for using the list this way. >> >> -Bill > From chenliu419 at gmail.com Mon Mar 23 05:03:20 2015 From: chenliu419 at gmail.com (Chen Liu) Date: Sun, 22 Mar 2015 22:03:20 -0700 Subject: [Deadline Extended] IEEE International Workshop on Manageability and Security of Network Function Virtualization and Software Defined Network (MASONS) Message-ID: --------------------------------------------------------------------------------------------------------------------------- Apologies for cross-postings! --------------------------------------------------------------------------------------------------------------------------- Call for Papers IEEE International Workshop on Manageability and Security of Network Function Virtualization and Software Defined Network (MASONS) With ICCCN 2015 at Las Vegas, Aug 3 – 6, 2015 http://www.manageability-at-scale.org/cfp/icccn-masons.html MASONS 2015 is Technically Co-Sponsored by the IEEE Communication Society 1. Theme Today, many research organizations in academia, government labs and industry are exploring SDN and NFV technologies to study and materialize their benefits in real world networks. These benefits are enabling automation, reducing time to market in case of new service introductions, optimization and/or improving overall economics of network and system management and operations. However to materialize the benefits of SDN and NFV at larger scale across multiple domains, similar to today’s internet, additional investigations are needed which should focus beyond the core SDN, NFV features and functionalities. This involves: development of multi-domain SDN network to support Internet; large scale deployment of novel applications, identification of technological and operational gaps in research and development over the longer term to increase the capability of SDN and NFV powered networks, and better integrate them with existing public Internet and emerging cloud technologies; Identification of security, manageability gaps, including opportunities to build in additional levels of security, resilience and management capabilities. 2. Topics of interest This workshop aims to show case and disseminate new ideas and high quality research on manageability and security of Software Defined Network and Network Function Virtualization. We solicit original research articles, review papers, theoretical studies, and practical software systems incorporating new paradigms, experimental prototypes, and insightful requirement analysis with the above theme including, but not limited to the topics below: * Design, requirements and prototypes of Software Defined Exchanges (SDX) to enable interoperability and use of new approaches with the current Internet infrastructure. * Security, privacy, authentication, trust, verification for SDN and NFV. * Integration of compute, storage and network under the Software Defined Infrastructure (SDI) paradigm. * Analysis of new management challenges that SDN and NFV has introduced. * Network management practices and business processes for SDN and NFV, in service provider and data center infrastructures. * Tools and operational procedures for managing SDN. * New paradigms in network operations, administration and management (OAM), service orchestration, service engineering, converged network-compute and data center management. * Software Defined Network (SDN), abstraction, programmability, application Interface, south and northbound API. * Network Function Virtualization (NFV), distributed control, virtual switches, routing virtualization. * Network system management, orchestration, resource management and optimization, integration, interoperability. * Network operations management related automation, troubleshooting and management tools. * Cloud based network and system management application paradigms. * Application of artificial intelligence (AI), machine learning (ML), analytics and big data in network and system management. * Insights about Network Management System architectural requirements analysis. * Scalability of SDN, NFV, SDI, NMS systems. * User experience, user interface design issues and challenges in NMS for SDN, NFV, ethnographic studies on network operations centers, usability studies of management applications. 3. Instructions for IEEE MASONS 2015 Workshop Authors: Submitted manuscripts must be formatted in standard IEEE camera ready format (double column, 10 pt font) and must be submitted via EasyChair ( http://www.easychair.org/) as PDF files (formatted for 8.5×11 inch paper). It should be no longer than 6 pages with up to two extra pages given the authors are willing to pay an over-length charge per extra page. The detailed information can be found in the ICCCN 2015 (Las Vegas) website. For any workshop related questions or additional information please contact the General, TPC, or Workshop Chairs. Submitted papers should not be previously published in or be under consideration for publication in another conference or journal. Paper titles and/or author names cannot be changed and/or added to the papers once papers are submitted to ICCCN 2015 for review. Submissions must include a title, abstract, keywords, author(s) and affiliation(s) with postal and email address(es) and phone number(s). A paper abstract must be registered on EasyChair by the deadline indicated below. 4. Speakers, Panelists * Morning keynote on manageability: Dr. Gee Rittenhouse , Sr. VP, Cloud and Virtualization Group, Cisco Systems * Morning keynote on security: Phillip Porras , Program Director - Internet Security Group, SRI International * Panelists: - Inder Monga (Moderator), CTO, ESNet - Josh Bailey, Google - eepak Bansal, Manager, Microsoft - Douglas Freimuth, STSM - Master Inventor, IBM Research - Dr. Ashutosh Dutta, Lead Member of Technical Staff - Mobility & Cloud Security, AT&T 5. Important dates: * Abstract Due: Apr 15, 2015 (Extended) * Paper Due: Apr 15, 2015 (Extended) * Acceptance Notification: Apr 30, 2015 * Camera Ready Due: May 8, 2015 6. Review and Publication of Manuscripts: Submitted papers will be reviewed by the ICCCN 2015 TPC members and judged on originality, technical correctness, relevance, and quality of presentation. An accepted paper must be presented at the conference venue by one (who registered/paid full author reg. fee) of authors to be included in the conference venue. Each full registration covers up to two ICCCN 2015 conference papers authored by the registered/paid author. Accepted and presented papers will be published in the conference proceedings and submitted to IEEE Xplore as well as other Abstracting and Indexing (A&I) databases. The page limit for papers is 6 pages. Papers should be submitted on EDAS, the link for this workshop will be published here shortly. Papers of special merit will be selected for possible fast track at a journal special issue at IJCNDS (see details at http://www.inderscience.com/info/ingeneral/cfplist.php?jcode=ijcnds and http://www.manageability-at-scale.org/cfp/). 7. Workshop chairs * Inder Monga, ESnet and LBNL, USA, imonga at es.net * Amitava Biswas, Cisco Systems, USA, amitavabiswas at ieee.org * Chen Liu, Microsoft, USA, chenliu419 at gmail.com 8. Technical Program Committee * Christian Rothenberg, University of Campinas, Brasil * Gerhard Hasslinger, T-Systems ENPS Darmstadt * Israat Haque, University of Alberta, Edmonton, Canada * Josh Bailey, Google, USA * Kenichi Ogaki, KDDI Corporation, Japan * Laurent Lefevre, INRIA * Lefteris Mamatas, University of Macedonia, Greece * Lisandro Granville, Institute of Informatcis of the Federal University of Rio Grande do Sul (UFRGS), Brazil * Michael Menth, University of Tübingen, Germany * Rajat Mehrotra, Desert Research Institute, Reno, NV, USA * Rajdeep Bhowmik, Cisco, USA * Roberto Bruschi, DIST - University of Genoa * Satya Mohanty, Cisco, USA * Spyros Denazis, University of Patras, Greece * Steven Latre, University of Antwerp, Belgium * Xenofontas Dimitropoulos, University of Crete and FORTH * Walter Cerroni, DEI - University of Bologna From rps at maine.edu Mon Mar 23 13:06:22 2015 From: rps at maine.edu (Ray Soucy) Date: Mon, 23 Mar 2015 09:06:22 -0400 Subject: Getting hit hard by CHINANET In-Reply-To: References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> <55090C8A.1050804@seacom.mu> <55091C04.8090504@seacom.mu> Message-ID: I did a test on my personal server of filtering every IP network assigned to China for a few months and over 90% of SSH attempts and other noise just went away. It was pretty remarkable. Working for a public university I can't block China outright, but there are times it has been tempting. :-) The majority of DDOS attacks I see are sourced from addresses in the US, though (likely spoofed). Just saw a pretty large one last week which was SSDP 1900 to UDP port 80, 50K+ unique host addresses involved. On Wed, Mar 18, 2015 at 8:32 AM, Eric Rogers wrote: > We are using Mikrotik for a BGP blackhole server that collects BOGONs > from CYMRU and we also have our servers (web, email, etc.) use fail2ban > to add a bad IP to the Mikrotik. We then use BGP on all our core > routers to null route those IPs. > > The ban-time is for a few days, and totally dynamic, so it isn't a > permanent ban. Seems to have cut down on the attempts considerably. > > Eric Rogers > PDSConnect > www.pdsconnect.me > (317) 831-3000 x200 > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins > Sent: Wednesday, March 18, 2015 6:04 AM > To: nanog at nanog.org > Subject: Re: Getting hit hard by CHINANET > > > On 18 Mar 2015, at 17:00, Roland Dobbins wrote: > > > This is not an optimal approach, and most providers are unlikely to > > engage in such behavior due to its potential negative impact (I'm > > assuming you mean via S/RTBH and/or flowspec). > > Here's one counterexample: > > Control.pdf> > > ----------------------------------- > Roland Dobbins > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From colinj at gt86car.org.uk Mon Mar 23 13:19:04 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Mon, 23 Mar 2015 13:19:04 +0000 Subject: Getting hit hard by CHINANET In-Reply-To: References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> <55090C8A.1050804@seacom.mu> <55091C04.8090504@seacom.mu> Message-ID: <851DB437-4230-4ADA-8E1A-F70373FE3094@gt86car.org.uk> China network blocks work great, I wish did not have to use but they never respond to admin or abuse contacts either Colin > On 23 Mar 2015, at 13:06, Ray Soucy wrote: > > I did a test on my personal server of filtering every IP network assigned > to China for a few months and over 90% of SSH attempts and other noise just > went away. It was pretty remarkable. > > Working for a public university I can't block China outright, but there are > times it has been tempting. :-) > > The majority of DDOS attacks I see are sourced from addresses in the US, > though (likely spoofed). Just saw a pretty large one last week which was > SSDP 1900 to UDP port 80, 50K+ unique host addresses involved. > > > On Wed, Mar 18, 2015 at 8:32 AM, Eric Rogers > wrote: > >> We are using Mikrotik for a BGP blackhole server that collects BOGONs >> from CYMRU and we also have our servers (web, email, etc.) use fail2ban >> to add a bad IP to the Mikrotik. We then use BGP on all our core >> routers to null route those IPs. >> >> The ban-time is for a few days, and totally dynamic, so it isn't a >> permanent ban. Seems to have cut down on the attempts considerably. >> >> Eric Rogers >> PDSConnect >> www.pdsconnect.me >> (317) 831-3000 x200 >> >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Roland Dobbins >> Sent: Wednesday, March 18, 2015 6:04 AM >> To: nanog at nanog.org >> Subject: Re: Getting hit hard by CHINANET >> >> >> On 18 Mar 2015, at 17:00, Roland Dobbins wrote: >> >>> This is not an optimal approach, and most providers are unlikely to >>> engage in such behavior due to its potential negative impact (I'm >>> assuming you mean via S/RTBH and/or flowspec). >> >> Here's one counterexample: >> >> > Control.pdf> >> >> ----------------------------------- >> Roland Dobbins >> > > > > -- > Ray Patrick Soucy > Network Engineer > University of Maine System > > T: 207-561-3526 > F: 207-561-3531 > > MaineREN, Maine's Research and Education Network > www.maineren.net From cb.list6 at gmail.com Mon Mar 23 13:37:44 2015 From: cb.list6 at gmail.com (Ca By) Date: Mon, 23 Mar 2015 06:37:44 -0700 Subject: Getting hit hard by CHINANET In-Reply-To: References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> <55090C8A.1050804@seacom.mu> <55091C04.8090504@seacom.mu> Message-ID: On Monday, March 23, 2015, Ray Soucy wrote: > I did a test on my personal server of filtering every IP network assigned > to China for a few months and over 90% of SSH attempts and other noise just > went away. It was pretty remarkable. > > Working for a public university I can't block China outright, but there are > times it has been tempting. :-) > > The majority of DDOS attacks I see are sourced from addresses in the US, > though (likely spoofed). Just saw a pretty large one last week which was > SSDP 1900 to UDP port 80, 50K+ unique host addresses involved. > > Having your upstream apply a permanent udp bw policer, say 5 or 10x busy hour baseline, works well for this. > > On Wed, Mar 18, 2015 at 8:32 AM, Eric Rogers > > wrote: > > > We are using Mikrotik for a BGP blackhole server that collects BOGONs > > from CYMRU and we also have our servers (web, email, etc.) use fail2ban > > to add a bad IP to the Mikrotik. We then use BGP on all our core > > routers to null route those IPs. > > > > The ban-time is for a few days, and totally dynamic, so it isn't a > > permanent ban. Seems to have cut down on the attempts considerably. > > > > Eric Rogers > > PDSConnect > > www.pdsconnect.me > > (317) 831-3000 x200 > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org ] On Behalf > Of Roland Dobbins > > Sent: Wednesday, March 18, 2015 6:04 AM > > To: nanog at nanog.org > > Subject: Re: Getting hit hard by CHINANET > > > > > > On 18 Mar 2015, at 17:00, Roland Dobbins wrote: > > > > > This is not an optimal approach, and most providers are unlikely to > > > engage in such behavior due to its potential negative impact (I'm > > > assuming you mean via S/RTBH and/or flowspec). > > > > Here's one counterexample: > > > > > Control.pdf> > > > > ----------------------------------- > > Roland Dobbins > > > > > > > -- > Ray Patrick Soucy > Network Engineer > University of Maine System > > T: 207-561-3526 > F: 207-561-3531 > > MaineREN, Maine's Research and Education Network > www.maineren.net > From mikea at mikea.ath.cx Mon Mar 23 13:42:52 2015 From: mikea at mikea.ath.cx (Mike A) Date: Mon, 23 Mar 2015 08:42:52 -0500 Subject: (network)technologies used by NSA for data collection In-Reply-To: References: Message-ID: <20150323134252.GB38342@mikea.ath.cx> On Sun, Mar 22, 2015 at 04:05:35AM +0200, Martin T wrote: > Hi, > > I watched "Citizenfour"(imdb.com/title/tt4044364/) documentary and at > 41:12 Edward Snowden gives a brief overview of some of the leaked > documents to journalists Glenn Greenwald and Ewen MacAskill. At 42:57 > Snowden mentions devices which are able to collect data at rate of > 1Tbps. This was in 2011. Screen-shots from the movie can be seen here: > https://nsa.gov1.info/dni/2014/tumult.jpg Third slide looks like some > sort of vendor product roadmap :) > Just out of curiosity, what kind of equipment those might be? Is it > realistic that NSA/DoD are able to produce their own hardware? Let > alone custom silicon like Cisco or Juniper are. Or do they use off the > self hardware.. In addition, it's relatively easy to install a passive > fiber optical tap for a submarine cable, but how do you get > information out of it? I mean all the different wavelengths(CWDM/DWDM) > within the same cable, line rates(up to 100GigE), circuit switched and > packet switched technologies which those devices should support.. In > addition, how(bandwidth and network wise) to transport this data to > data analysis and storage equipment if it collected far away from > USA.. > Some of those questions or thoughts might be naive and stupid, but > that's what crossed my mind when I watched the documentary. Maybe > somebody, who has done more research in this field, could clarify. NSA has had in-house chip fab facilities for at least 10 years, probably closer to 20, and possibly as much as 30, as well as working agreements with big network gear manufacturers. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From streiner at cluebyfour.org Mon Mar 23 14:39:27 2015 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 23 Mar 2015 14:39:27 -0000 Subject: Getting hit hard by CHINANET In-Reply-To: References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> <55090C8A.1050804@seacom.mu> <55091C04.8090504@seacom.mu> Message-ID: On Mon, 23 Mar 2015, Ca By wrote: > Having your upstream apply a permanent udp bw policer, say 5 or 10x busy > hour baseline, works well for this. Many upstreams will not do that, particularly on a permanent basis. They might do something temporarily to deal with an incident, but many of the bigger carriers probably wouldn't want to leave that in place permanently. jms From oscar.vives at gmail.com Mon Mar 23 14:55:08 2015 From: oscar.vives at gmail.com (Tei) Date: Mon, 23 Mar 2015 15:55:08 +0100 Subject: (network)technologies used by NSA for data collection In-Reply-To: <20150323134252.GB38342@mikea.ath.cx> References: <20150323134252.GB38342@mikea.ath.cx> Message-ID: This stuff is soo cool :D I understands less than half of it, but I have found this link that give some light. https://robert.sesek.com/2014/9/unraveling_nsa_s_turbulence_programs.html It seems they had a system to backup 3 days of the internet, all data. But such system failed because Internet generated too much data. So Turmoil is a programmable event based filter, detect events and when the event is triggered, save data from the stream. So they generate as much data they want or can handle. -- -- ℱin del ℳensaje. From cb.list6 at gmail.com Mon Mar 23 14:55:31 2015 From: cb.list6 at gmail.com (Ca By) Date: Mon, 23 Mar 2015 07:55:31 -0700 Subject: Getting hit hard by CHINANET In-Reply-To: References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> <55090C8A.1050804@seacom.mu> <55091C04.8090504@seacom.mu> Message-ID: On Sun, Mar 23, 2014 at 3:43 AM, Justin M. Streiner wrote: > On Mon, 23 Mar 2015, Ca By wrote: > > Having your upstream apply a permanent udp bw policer, say 5 or 10x busy >> hour baseline, works well for this. >> > > Many upstreams will not do that, particularly on a permanent basis. They > might do something temporarily to deal with an incident, but many of the > bigger carriers probably wouldn't want to leave that in place permanently. > > jms > Mine Tier 1 up-streams are fine with it permanent. YMMV. I did have to get my account team involved, but from a technical perspective, a one line policer (all UDP rate-limit to 10% of link speed) is not a technical challenge, and the one-off config element is not overly burdensome. Again, YMMV. And, your frequency and impact of IPv4 UDP based attacks will dictate your needs. CB From contact at winterei.se Mon Mar 23 15:14:12 2015 From: contact at winterei.se (Paul S.) Date: Tue, 24 Mar 2015 00:14:12 +0900 Subject: Getting hit hard by CHINANET In-Reply-To: References: <5490D6B8-C014-4A7A-9962-360A44BDBA06@arbor.net> <55090C8A.1050804@seacom.mu> <55091C04.8090504@seacom.mu> Message-ID: <55102DC4.2050705@winterei.se> +1, I've had good luck with this as well. My experiences pretty much mirror yours, NOC says no, had to ask my SE to take care of it. Didn't have any issues after. On 3/23/2015 午後 11:55, Ca By wrote: > On Sun, Mar 23, 2014 at 3:43 AM, Justin M. Streiner > wrote: >> On Mon, 23 Mar 2015, Ca By wrote: >> >> Having your upstream apply a permanent udp bw policer, say 5 or 10x busy >>> hour baseline, works well for this. >>> >> Many upstreams will not do that, particularly on a permanent basis. They >> might do something temporarily to deal with an incident, but many of the >> bigger carriers probably wouldn't want to leave that in place permanently. >> >> jms >> > Mine Tier 1 up-streams are fine with it permanent. YMMV. I did have to get > my account team involved, but from a technical perspective, a one line > policer (all UDP rate-limit to 10% of link speed) is not a technical > challenge, and the one-off config element is not overly burdensome. > > Again, YMMV. And, your frequency and impact of IPv4 UDP based attacks will > dictate your needs. > > CB From rwfireguru at gmail.com Mon Mar 23 14:59:01 2015 From: rwfireguru at gmail.com (Robert Webb) Date: Mon, 23 Mar 2015 10:59:01 -0400 Subject: HOSTUS Contact Atlanta DC issues Message-ID: Apologies for the noise. Looking for information about Hostus issues in Atlanta. I have two servers that are not accessible, one fails login from the VPS Control Panel. Have had high priority ticket in for over an hour with no response and nothing on the network status as far as any issues. Please contact off list. From nat at nuqe.net Mon Mar 23 21:16:18 2015 From: nat at nuqe.net (Nat Morris) Date: Mon, 23 Mar 2015 21:16:18 +0000 Subject: SFP Programmers In-Reply-To: <550EFACA.7070608@seacom.mu> References: <20909752.3296.1427038534429.JavaMail.mhammett@ThunderFuck> <550EFACA.7070608@seacom.mu> Message-ID: On 22 March 2015 at 17:24, Mark Tinka wrote: > > > On 22/Mar/15 17:35, Mike Hammett wrote: >> >> Where are you guys picking up your SFP programmers? > > > FlexOptics are good. ^ they are great, I have 2 different programmers of theirs, remember you need to buy their optics though. My understanding is their webapp sends LUA to the programmer which gets executed locally. Here are some other devices I've bought to experiment with: https://dimiks.com/en/programmers http://shop.nag.ru/catalog/00007.Avtomatizatsiya-i-monitoring/13766.Drugoe/08255.Prog-miniUSB Not tried this one: http://optics-home.com/pro_details.asp?id=105 Or make your own with an old TwinGig and RaspberryPi - http://eoinpk.blogspot.co.uk/2014/05/raspberry-pi-and-programming-eeproms-on.html Its just I2C after all... -- Nat https://nat.ms +44 7531 750292 From yardiel at gmail.com Mon Mar 23 23:00:14 2015 From: yardiel at gmail.com (Yardiel D. Fuentes) Date: Mon, 23 Mar 2015 19:00:14 -0400 Subject: Last-call DoS/DoS Attack BCOP In-Reply-To: <88F2A9A6-1B7C-4B6E-BD79-390945C48B1E@gmail.com> References: <88F2A9A6-1B7C-4B6E-BD79-390945C48B1E@gmail.com> Message-ID: <8287D712-0327-4DFE-AE80-FC9E6A659458@gmail.com> Thank you all who have contributed your feedback, comments and discussion points towards the DDoS/DoS attack BCOP. I have updated the current version of the BCOP with the agreed upon feedback: http://bcop.nanog.org/index.php/BCOP_Drafts Since there have been good feedback for this BCOP. The committee decided to extend the "last-call period" for another two weeks to give ample chance to further feedback. So, it is not late for more comments, Yardiel Fuentes On Feb 27, 2015, at 11:16 AM, Yardiel D. Fuentes wrote: > > > Hello NANOGers, > > Following up on the below effort from last year, the DDoS/DoS Attack BCOP Draft document is ready for the last call 2-week period. After this period and unless notable objections are raised, the current document will be ratified as such. The current document can be found in the NANOG BCOP site -- link to current document found below: > > http://bcop.nanog.org/index.php/BCOP_Drafts > > Any additional community-wide comments or feedback in order to ensure quality documentation are not only very welcome but encouraged. > > Cheers, > > Yardiel Fuentes > > > On Jul 2, 2014, at 6:48 PM, Yardiel D. Fuentes wrote: > >> >> >> OK NANOGers, >> >> Some of us got the call to arms from Chris G email below and the NANOG BCOP Committee and now we are interested in generating DoS attack-related Best Common Practices (BCOP) appeal to serve the entire NANOG community. >> >> This document, as other BCOP appeals are expected to be as brief as possible and to the point in order to keep it practical and useful. >> >> The goal is to generate a set of best practices of what to do before/during/after a DoS/DDoS attack -- including what seems to have worked best and what hasn't. Time dedicated to this effort should extensive and participation can be non-real-time given that it can be done over email with no need for conference calls if desired. >> >> DoS and DDoS attacks have been a topic that have captured high interest from NANOGers based on the archived list topics and email threads. So, now is your time to help shape a NANOG BCOP Appeal on this topic. >> >> Please contact me off-list if you want participate by either sharing your experience, expertise or opinions towards generating a DoS Attack BCOP. >> >> >> Yardiel Fuentes >> yardiel at gmail.com >> twitter: #techguane >> >> >> >> On Jun 1, 2014, at 5:25 PM, Chris Grundemann wrote: >> >>> Hail NANOGers! >>> >>> As most of you hopefully know, NANOG now has a BCOP Ad Hoc Committee >>> and we are pushing forward with new BCOPs! >>> http://nanog.org/governance/bcop >>> >>> We currently have three BCOPs in active development: >>> >>> eBGP configuration, shepherd Bill Armstrong >>> Public Peering Exchange update, shepherd Shawn Hsiao >>> Ethernet OAM, shepherd Mark Calkins >>> >>> All three of these nascent BCOPs will be presented in the BCOP Track >>> on Monday: http://nanog.org/meetings/abstract?id=2348 >>> >>> We have also collected a list of Appeals (BCOPs that need to be >>> written): http://bcop.nanog.org/index.php/Appeals >>> >>> If you would like to help out with any of these BCOPs (or others yet >>> to be identified) please join the BCOP mailing list and reach out to >>> the shepherd (if applicable of course): >>> http://mailman.nanog.org/mailman/listinfo/bcop >>> >>> Our committee is brand new and we are still finding and smoothing >>> wrinkles, etc. We would love your help in any capacity. As a BCOP >>> shepherd or SME or just to point out potential pit falls or room for >>> improvement, with the process, the wiki, a BCOP or anything at all >>> really. >>> >>> This is a bottom-up, community led effort and it will only succeed >>> with your help - join us in creating what I believe will be a vital >>> and long-lasting institution! >>> >>> Cheers, >>> ~Chris >>> >>> -- >>> @ChrisGrundemann >>> http://chrisgrundemann.com >> > From jtk at cymru.com Mon Mar 23 23:21:42 2015 From: jtk at cymru.com (John Kristoff) Date: Mon, 23 Mar 2015 18:21:42 -0500 Subject: Last-call DoS/DoS Attack BCOP In-Reply-To: <8287D712-0327-4DFE-AE80-FC9E6A659458@gmail.com> References: <88F2A9A6-1B7C-4B6E-BD79-390945C48B1E@gmail.com> <8287D712-0327-4DFE-AE80-FC9E6A659458@gmail.com> Message-ID: <20150323182142.364b56df@localhost> On Mon, 23 Mar 2015 19:00:14 -0400 Yardiel D.Fuentes wrote: > Since there have been good feedback for this BCOP. The committee > decided to extend the "last-call period" for another two weeks to > give ample chance to further feedback. > > So, it is not late for more comments, Hi Yardiel, Nice work so far. A couple of additional ideas for you if you care to use them. If the attack is an infrastructure attack, say a routing interface that wouldn't normally receive or emit traffic from its assigned address except perhaps for network connectivity testing (e.g. traceroute) or control link local control traffic (e.g. local SPF adjacencies, BGP neighbors), you can "hide" those addresses, making them somewhat less easy to target by using something like unnumbered or unadvertised or ambiguous address space (e.g. RFC 1918). A second suggestion, if you want to add a reference to it is the UTRS project, which is a free community project that brings networks together for the purpose of exchanging RTBH announcements. We've recently enabled automated relay for IPv4 /32's that have a history of sole origination from a peer. This is another DDoS mitigation tool in the tool box that many may find helpful. More detail can be found here: John From rs at seastrom.com Tue Mar 24 09:27:30 2015 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 24 Mar 2015 05:27:30 -0400 Subject: Last-call DoS/DoS Attack BCOP In-Reply-To: <20150323182142.364b56df@localhost> (John Kristoff's message of "Mon, 23 Mar 2015 18:21:42 -0500") References: <88F2A9A6-1B7C-4B6E-BD79-390945C48B1E@gmail.com> <8287D712-0327-4DFE-AE80-FC9E6A659458@gmail.com> <20150323182142.364b56df@localhost> Message-ID: <86iodq68zh.fsf@valhalla.seastrom.com> John Kristoff writes: > If the attack is an infrastructure attack, say a routing interface that > wouldn't normally receive or emit traffic from its assigned address > except perhaps for network connectivity testing (e.g. traceroute) or > control link local control traffic (e.g. local SPF adjacencies, BGP > neighbors), you can "hide" those addresses, making them somewhat less > easy to target by using something like unnumbered or unadvertised or > ambiguous address space (e.g. RFC 1918). That comes at a cost, both operational/debugging and breaking pmtud. But if you don't care about collateral damage, setting the interface to admin-down stops attacks against it *cold*. Due to the drawbacks, I wouldn't consider this a good candidate for inclusion in a BCOP document. I have often thought there ought to be a companion series for Questionable Current Operational Practices, or maybe "desperate measures". I volunteer to write the article on "YOLO upgrades", wherein one loads untested software on equipment with no OOB, types "request system reboot", shouts "YOLO", and hits return. -r From mcole.mailinglists at gmail.com Tue Mar 24 13:29:00 2015 From: mcole.mailinglists at gmail.com (Maxwell Cole) Date: Tue, 24 Mar 2015 09:29:00 -0400 Subject: Last-call DoS/DoS Attack BCOP In-Reply-To: <86iodq68zh.fsf@valhalla.seastrom.com> References: <88F2A9A6-1B7C-4B6E-BD79-390945C48B1E@gmail.com> <8287D712-0327-4DFE-AE80-FC9E6A659458@gmail.com> <20150323182142.364b56df@localhost> <86iodq68zh.fsf@valhalla.seastrom.com> Message-ID: <5511669C.7060405@gmail.com> On 3/24/15 5:27 AM, Rob Seastrom wrote: > John Kristoff writes: > >> If the attack is an infrastructure attack, say a routing interface that >> wouldn't normally receive or emit traffic from its assigned address >> except perhaps for network connectivity testing (e.g. traceroute) or >> control link local control traffic (e.g. local SPF adjacencies, BGP >> neighbors), you can "hide" those addresses, making them somewhat less >> easy to target by using something like unnumbered or unadvertised or >> ambiguous address space (e.g. RFC 1918). > That comes at a cost, both operational/debugging and breaking pmtud. > But if you don't care about collateral damage, setting the interface to > admin-down stops attacks against it *cold*. > > Due to the drawbacks, I wouldn't consider this a good candidate for > inclusion in a BCOP document. > > I have often thought there ought to be a companion series for > Questionable Current Operational Practices, or maybe "desperate > measures". I volunteer to write the article on "YOLO upgrades", > wherein one loads untested software on equipment with no OOB, types > "request system reboot", shouts "YOLO", and hits return. > > -r > > You could have a whole blog series about redistributing BGP into IGPs. Or a "tricks and tips" section to add an allow any to all of your ACLs. From eksffa at freebsdbrasil.com.br Tue Mar 24 19:14:49 2015 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Tue, 24 Mar 2015 16:14:49 -0300 Subject: AT&T BGP Operations in Miami, FL Message-ID: <8859F662-ED42-4A88-98EB-B3C64955EBA3@freebsdbrasil.com.br> Hello, Is there anyone from ATT BGP operations who can contact-me off list please for Miami location? I have an open ticket since early morning and a BGP session not exporting other transit ASNs, which were just working by the morning. Thank you. -- Patrick Tracanelli From morrowc.lists at gmail.com Wed Mar 25 04:49:22 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 25 Mar 2015 00:49:22 -0400 Subject: Last-call DoS/DoS Attack BCOP In-Reply-To: <86iodq68zh.fsf@valhalla.seastrom.com> References: <88F2A9A6-1B7C-4B6E-BD79-390945C48B1E@gmail.com> <8287D712-0327-4DFE-AE80-FC9E6A659458@gmail.com> <20150323182142.364b56df@localhost> <86iodq68zh.fsf@valhalla.seastrom.com> Message-ID: On Tue, Mar 24, 2015 at 5:27 AM, Rob Seastrom wrote: > > John Kristoff writes: > >> If the attack is an infrastructure attack, say a routing interface that >> wouldn't normally receive or emit traffic from its assigned address >> except perhaps for network connectivity testing (e.g. traceroute) or >> control link local control traffic (e.g. local SPF adjacencies, BGP >> neighbors), you can "hide" those addresses, making them somewhat less >> easy to target by using something like unnumbered or unadvertised or >> ambiguous address space (e.g. RFC 1918). > > That comes at a cost, both operational/debugging and breaking pmtud. being hidden stops pmtud only if the route isn't in the global table, right? There is not a requirement to do that if you can drop the traffic at your edge in other ways (filter). It's probably (arguably) better to not route to the space, but failing that (because you might like pmtud to work, or other error-type messaages to not be dropped by uRPFers) just rate-limit + filter at the edge seems like a decent compromise. > But if you don't care about collateral damage, setting the interface to > admin-down stops attacks against it *cold*. > > Due to the drawbacks, I wouldn't consider this a good candidate for > inclusion in a BCOP document. this is highly dependent upon your network design and topology though, right? By this i mean, if the device is an LSR and won't have IP traffic hit it's interfaces no harm no foul making them invisible. With some modern platforms you can even specify a single 'filter' and adjunct 'rate limiters' to be used across the entire device, right? This means you can permit traffic into your borders and let the device control access to itself with some relatively simple filters and rate-limits, so your access works, and pmtud works and dos attacks don't kill the device, just fill the interface to the device. > I have often thought there ought to be a companion series for > Questionable Current Operational Practices, or maybe "desperate > measures". I volunteer to write the article on "YOLO upgrades", > wherein one loads untested software on equipment with no OOB, types > "request system reboot", shouts "YOLO", and hits return. YOLO From surfer at mauigateway.com Wed Mar 25 05:40:53 2015 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 24 Mar 2015 22:40:53 -0700 Subject: Last-call DoS/DoS Attack BCOP Message-ID: <20150324224053.39D65EFD@m0005311.ppops.net> ------------------------------ > measures". I volunteer to write the article on "YOLO upgrades", > wherein one loads untested software on equipment with no OOB, types > "request system reboot", shouts "YOLO", and hits return. :: YOLO ----------------------------- If a manager forces me to do this is it a requirement that I have to yell yolo? ;-) One day I'm going to write that into the test plan. I absolutely hate it when they do that... scott From jcurran at arin.net Wed Mar 25 09:49:57 2015 From: jcurran at arin.net (John Curran) Date: Wed, 25 Mar 2015 09:49:57 +0000 Subject: FCC to recharter CSRIC for a Fifth Two-Year Term; Seeks Nominations By March 31, 2015 For Membership Message-ID: <3E858463-BA97-467B-91A9-C3652BD5E46D@arin.net> "The Federal Communications Commission (FCC or Commission) is seeking nominations and expressions of interest for membership on the fifth Communications Security, Reliability, and Interoperability Council (CSRIC or Council), which is expected to commence in March 2015 when the current CSRIC charter expires on March 18, 2015. The Council is a federal advisory committee chartered pursuant to the Federal Advisory Committee Act1 that provides guidance, expertise, and recommendations to the Commission to improve the security, reliability, and interoperability of the nation’s communications systems. Nominations and expressions of interest for membership must be submitted to the FCC no later than March 31, 2015. …” The recommendations of any CSRIC activities takes on additional significance in light of the recent FCC reclassification of Internet providers under title II authority. Additional information on CSRIC IV, recent activities, reports, etc. is available here: http://www.fcc.gov/encyclopedia/communications-security-reliability-and-interoperability-council-iv FYI, /John John Curran President and CEO ARIN From rs at seastrom.com Wed Mar 25 12:27:14 2015 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 25 Mar 2015 08:27:14 -0400 Subject: Last-call DoS/DoS Attack BCOP In-Reply-To: (Christopher Morrow's message of "Wed, 25 Mar 2015 00:49:22 -0400") References: <88F2A9A6-1B7C-4B6E-BD79-390945C48B1E@gmail.com> <8287D712-0327-4DFE-AE80-FC9E6A659458@gmail.com> <20150323182142.364b56df@localhost> <86iodq68zh.fsf@valhalla.seastrom.com> Message-ID: <86619pclel.fsf@valhalla.seastrom.com> Christopher Morrow writes: > On Tue, Mar 24, 2015 at 5:27 AM, Rob Seastrom wrote: >> >> John Kristoff writes: >> >>> If the attack is an infrastructure attack, say a routing interface that >>> wouldn't normally receive or emit traffic from its assigned address >>> except perhaps for network connectivity testing (e.g. traceroute) or >>> control link local control traffic (e.g. local SPF adjacencies, BGP >>> neighbors), you can "hide" those addresses, making them somewhat less >>> easy to target by using something like unnumbered or unadvertised or >>> ambiguous address space (e.g. RFC 1918). >> >> That comes at a cost, both operational/debugging and breaking pmtud. > > being hidden stops pmtud only if the route isn't in the global table, > right? There is not a requirement to do that if you can drop the > traffic at your edge in other ways (filter). Yes, you can filter the incoming traffic at the edge of your network and not have to suffer the "ICMP fragmentation needed" messages coming from addresses that are either (a) 1918 and so likely to be dropped on the floor due to bogon filters, or (b) not in the routing table, and so likely to be dropped on the floor due to loose unicast rpf. > It's probably (arguably) better to not route to the space, but failing > that (because you might like pmtud to work, or other error-type > messaages to not be dropped by uRPFers) just rate-limit + filter at > the edge seems like a decent compromise. Sure, rate limiting potentially bad traffic to some multiple of normal background that doesn't cause you pain and protects you from disaster sounds like a plan. The other end of that telescope os COPP and we've been doing that for years... >> But if you don't care about collateral damage, setting the interface to >> admin-down stops attacks against it *cold*. >> >> Due to the drawbacks, I wouldn't consider this a good candidate for >> inclusion in a BCOP document. > > this is highly dependent upon your network design and topology though, > right? By this i mean, if the device is an LSR and won't have IP > traffic hit it's interfaces no harm no foul making them invisible. Yes, there are many corner cases where all sorts of creative solutions can be deployed. I'll bet the filters for your personal devices are different from the backbone filters at $DAYJOB too. John's statement was in the context of general advice to be included in a BCOP document and I felt compelled to say "whoa there". > With some modern platforms you can even specify a single 'filter' and > adjunct 'rate limiters' to be used across the entire device, right? > > This means you can permit traffic into your borders and let the device > control access to itself with some relatively simple filters and > rate-limits, so your access works, and pmtud works and dos attacks > don't kill the device, just fill the interface to the device. ayup >> I have often thought there ought to be a companion series for >> Questionable Current Operational Practices, or maybe "desperate >> measures". I volunteer to write the article on "YOLO upgrades", >> wherein one loads untested software on equipment with no OOB, types >> "request system reboot", shouts "YOLO", and hits return. > > YOLO YOLO! -r From jtk at cymru.com Wed Mar 25 12:50:15 2015 From: jtk at cymru.com (John Kristoff) Date: Wed, 25 Mar 2015 07:50:15 -0500 Subject: Last-call DoS/DoS Attack BCOP In-Reply-To: <86619pclel.fsf@valhalla.seastrom.com> References: <88F2A9A6-1B7C-4B6E-BD79-390945C48B1E@gmail.com> <8287D712-0327-4DFE-AE80-FC9E6A659458@gmail.com> <20150323182142.364b56df@localhost> <86iodq68zh.fsf@valhalla.seastrom.com> <86619pclel.fsf@valhalla.seastrom.com> Message-ID: <20150325075015.7330e0ea@localhost> On Wed, 25 Mar 2015 08:27:14 -0400 Rob Seastrom wrote: > John's statement was in the context of general advice to be included > in a BCOP document and I felt compelled to say "whoa there". My intent was for it to be taken as a DDoS mitigation response option, not as a general practice. John From chuckchurch at gmail.com Wed Mar 25 14:13:20 2015 From: chuckchurch at gmail.com (Chuck Church) Date: Wed, 25 Mar 2015 10:13:20 -0400 Subject: Last-call DoS/DoS Attack BCOP In-Reply-To: <20150324224053.39D65EFD@m0005311.ppops.net> References: <20150324224053.39D65EFD@m0005311.ppops.net> Message-ID: <00e601d06705$d9459da0$8bd0d8e0$@gmail.com> Other phrases can be substituted. "no guts, no glory" "go big or go home" "no pain, no pain" Chuck -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott Weeks Sent: Wednesday, March 25, 2015 1:41 AM To: nanog at nanog.org Subject: Re: Last-call DoS/DoS Attack BCOP ------------------------------ > measures". I volunteer to write the article on "YOLO upgrades", > wherein one loads untested software on equipment with no OOB, types > "request system reboot", shouts "YOLO", and hits return. :: YOLO ----------------------------- If a manager forces me to do this is it a requirement that I have to yell yolo? ;-) One day I'm going to write that into the test plan. I absolutely hate it when they do that... scott From psirt at cisco.com Wed Mar 25 16:04:07 2015 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Mar 2015 12:04:07 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Virtual Routing and Forwarding ICMP Queue Wedge Vulnerability Message-ID: <201503251204.17.wedge@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco IOS Software Virtual Routing and Forwarding ICMP Queue Wedge Vulnerability Advisory ID: cisco-sa-20150325-wedge Revision 1.0 For Public Release 2015 March 25 16:00 UTC (GMT) Summary ======= A vulnerability within the virtual routing and forwarding (VRF) subsystem of Cisco IOS software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition. The vulnerability is due to a failure to properly process malicious ICMP version 4 (ICMPv4) messages received on a VRF-enabled interface. An attacker could exploit this vulnerability by submitting ICMPv4 messages designed to trigger the vulnerability on an affected device. When the ICMPv4 messages are processed, the packet queue of the affected interface may not be cleared, leading to a queue wedge. When a wedge occurs, the affected device will stop processing any additional packets received on the wedged interface. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are not available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150325-wedge Note: The March 25, 2015, Cisco IOS & XE Software Security Advisory bundled publication includes seven Cisco Security Advisories. The advisories address vulnerabilities in Cisco IOS Software and Cisco IOS XE Software. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS & XE Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar15.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJVEg3FAAoJEIpI1I6i1Mx3DKAQAKh0z1Us2roV3ahSr8fiIDVW /veWzUDTFiGdlGS4xWExyHL92srs+DoT3wRDwX1UqvmkdRUTfQPGIQl1LAyWujMA TkP6xhTBRTYVtQVQVb4Ubya966QlykNs4jEcmlcep/mGWddLDfF0cOpqDAREAc+Y A8FBn946o3m1Ds/zTkRtvuwc2MOEOglZS6A7fc0a/iDCsnD/FaBlaxHjukgt6xbY OShTjGzJZ7IMsbBizCvlVRYiogCED3EGJ4unM+LvjMRSX2JOu1t5CUJmcXmWIP3u KDQQRB/flmhIUkcaBOMxn4FdBc6ISVLRGPLFSyYJBxz3YE05JqER9QPdK+c2wjKl uyVjCa9Iljuxoqn4TYYFR1X5Gxzt3YZgNJIhy6DTZP6O0OI4U4OaJsiBNDrs3ZMo C9Khl63TlzPG0NfbKXaiPc/2ZakUqty1sKkrFagQ1NcyyzRMJL13uhRIm6G8PPhB Kh1K2GBqGuligoHLVSC0r2NR015iTNobmV+54RCb0RuU+LKl2XFQKYWc3UmNRuQG 36Kf5cZT0gJrF4rryaeCfaSA/LkQsBxEUaMci/APLSR/+qGADTR7EHfIW5kkFlZ7 t/Xi7LON6q3KVBavi3Lo1P+wYV9iNHqy1aeRzAGdC4+FKe0rCdU5cgMZrO1Oc+r6 POD7hEJjIhAb4hRZTjqN =qckG -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 25 16:04:40 2015 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Mar 2015 12:04:40 -0400 Subject: Cisco Security Advisory: Cisco IOS Software and IOS XE Software TCP Packet Memory Leak Vulnerability Message-ID: <201503251204.17.tcpleak@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco IOS Software and IOS XE Software TCP Packet Memory Leak Vulnerability Advisory ID: cisco-sa-20150325-tcpleak Revision 1.0 For Public Release 2015 March 25 16:00 UTC (GMT) Summary ======= A vulnerability in the TCP input module of Cisco IOS and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause a memory leak and eventual reload of the affected device. The vulnerability is due to improper handling of certain crafted packet sequences used in establishing a TCP three-way handshake. An attacker could exploit this vulnerability by sending a crafted sequence of TCP packets while establishing a three-way handshake. A successful exploit could allow the attacker to cause a memory leak and eventual reload of the affected device. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are not available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150325-tcpleak Note: The March 25, 2015, Cisco IOS & XE Software Security Advisory bundled publication includes seven Cisco Security Advisories. The advisories address vulnerabilities in Cisco IOS Software and Cisco IOS XE Software. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS & XE Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar15.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJVEg3FAAoJEIpI1I6i1Mx3s7EP/35lG2sxSOAqj5WWow1L0VbB eCYn6sQTavKyg5pXtFKUyUfF8AUHPrySGpcjy77+s+4uDNswIAXplYQrr8r8OifE xJ8OzuvCXOgvyQEAc8H6l7zLLYOkBv6cFAyYPepl0tPac15iOqX6Xv8l2+gnvi6p puKJYc/81bYmqeE0qRvPDzT9rWiccp1pbWUqUu1ZX31zJ86e/mERHFWOTOBA/qC3 Xd/36ljl4sTR8IPOE7Zoq8jfedlc9Bg3cz7aBrFgx8M9jB/V47MPe6eyfLKHHAEI oXPUu8uJBQsrnYa9/MbN3/wmI9weq3mGhaaStmV9JL0oYn/4gsgY+r4f9euXDMqW b/kIkHxtYHrShckox708oHCjCCTdKiTJcGy+GgTagq49c+A7UCzc8XEwgCOyFFbL 5E2AZ6PJUyUEfbPWhPlCj9H/t3G8mfcmH/FZLpwbEGTtfBCb5b1WRdXd0ARqJqD3 ZXy7M9gKGlifenvs9s9rElO+GuIVvmaAZ2anHgH7aLXCxoc7mIQfTxcjV9whXfD2 TBwHhsR7FMrgtqWbBokq/aNrs/ull9RXsubVFLSToj1BAuJlZpyvjbzQw10bPm5b ZL80JvOffzmf2711jIJCoOiVHGdO/jvb518JMY4XoPyBBKSxtTYpKdKXfBQjQgIv L3q5mEH18S0YiHC8yQAz =W7nK -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 25 16:05:13 2015 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Mar 2015 12:05:13 -0400 Subject: Cisco Security Advisory: Cisco IOS Software and IOS XE Software mDNS Gateway Denial of Service Vulnerability Message-ID: <201503251205.17.mdns@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco IOS Software and IOS XE Software mDNS Gateway Denial of Service Vulnerability Advisory ID: cisco-sa-20150325-mdns Revision 1.0 For Public Release 2015 March 25 16:00 UTC (GMT) Summary ======= A vulnerability in the multicast DNS (mDNS) gateway function of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to reload the vulnerable device. The vulnerability is due to improper validation of mDNS packets. An attacker could exploit this vulnerability by sending malformed IP version 4 (IPv4) or IP version 6 (IPv6) packets on UDP port 5353. An exploit could allow the attacker to cause a denial of service (DoS) condition. Cisco has released free software updates that address this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150325-mdns Note: The March 25, 2015, Cisco IOS & XE Software Security Advisory bundled publication includes seven Cisco Security Advisories. The advisories address vulnerabilities in Cisco IOS Software and Cisco IOS XE Software. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS & XE Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar15.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJVEg3FAAoJEIpI1I6i1Mx3h30P/3gJw08jXsXrVu8KO7L3kqLR vKTMc5BYxLQPoLO3SjI2p6uNKn5iMM6oOsKSZt+mehlDZUUe1JBVricFa07bNQmh jW9mCwVrsMMfOF7NL47vJm6GtGZurhc5WlCRp0uE1PNJs6NmMyRgszTxDz1F5Tjh fq6/2SiKnZW0w+MuxZnrck9rPZ+fzjcpe7sKOUr3htAi/Z0cfhadQrEcVXFuRhn9 bSk0D71zzfXt1VazqOIZiciRJOu/cEN5Tq+NZWTUKqFPFlepjT1G/Ho3WPtQWxbp UwZyeh2InlFnc7DWuNCqW+eZ1CFDPWVNGmWcQq3oxNHkvAAvQsn7vsOgNJRr+yNi S8emKrm94iyIaD2ouOMDgof4MireHLNKNnVecsnuJqUui89zZiT6ZIXg5S8eM5sx rkkfoGjTALePenydwM7eAPjUxI4vFzGPwk1ikQrT49a8fZTJ0/p/S6X8BbybJJXK JHiBdOw88ppa7ixOHgSubHH86KKqm5tCqRI13RpTTtDXQpv4Ev0spiDGeTTKtWEA lGmZldoLHO5Tkk+HUwlUMobluwnt1kGKkAFA+wSRukArAt8i52OUziDmQ4WYBf7a CKw+f6WU9YjGxP2jpp/Xy3u9kKkHHXb8R9y009yXLg1ShZS8eiqQhh6O7O7NuiNL k43tGb1gB+D+0SPS3w/x =DuB0 -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 25 16:05:49 2015 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Mar 2015 12:05:49 -0400 Subject: Cisco Security Advisory: Multiple Vulnerabilities in Cisco IOS Software Common Industrial Protocol Message-ID: <201503251205.17.cip@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Multiple Vulnerabilities in Cisco IOS Software Common Industrial Protocol Advisory ID: cisco-sa-20150325-cip Revision 1.0 For Public Release 2015 March 25 16:00 UTC (GMT) Summary ======= The Cisco IOS Software implementation of the Common Industrial Protocol (CIP) feature contains the following vulnerabilities when processing crafted CIP packets that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition: Cisco IOS Software UDP CIP Denial of Service Vulnerability Cisco IOS Software TCP CIP Packet Memory Leak Vulnerability Cisco IOS Software TCP CIP Denial of Service Vulnerability These vulnerabilities are independent of each other; a release that is affected by one of the vulnerabilities may not be affected by the others. Successful exploitation of any of these vulnerabilities could allow an unauthenticated, remote attacker to cause a reload of the forwarding plane, resulting in an interruption of services on an affected device. Repeated exploitation could result in a sustained DoS condition. Additionally, successful exploitation of Cisco IOS Software TCP CIP Packet Memory Leak Vulnerability could allow an unauthenticated, remote attacker to cause a memory leak on an affected device. Cisco has released free software updates that address these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150325-cip Note: The March 25, 2015, Cisco IOS & XE Software Security Advisory bundled publication includes seven Cisco Security Advisories. The advisories address vulnerabilities in Cisco IOS Software and Cisco IOS XE Software. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS & XE Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar15.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJVEg3EAAoJEIpI1I6i1Mx3gQoQAMgga/GDsaG87OcxdBDP3PS0 VWVup8SutEuU6I0Gb+L/PmUYPTNCq7Tc25Cumoqy6z5K7jqNsmsrjzoFeUR86Ksr GYY1hFEc9M4nOapTzoiNFQAxg8bGxh5u4PemCCg9CbEfqP51ItKUmKKcsmT45YpJ M2uidBLWkPum0bcfAvD7JMox/luzMFyAiLnb0IJj217hMVr1OmZou66V8cQfWZZl He+pT5WcPKd116GAB3Gb7B0lcEHduTQAb2psSrPOPJLE4bOwBtyuC17wjCoblQKh W1SLIddEDTUHIkvKt71ZKjvARIiwdEFnZWd9QoH9DygSvTPoooN168Ub5S9rqVDy E84p7pJf0FSyAFrXqTdl0vZHIFmZlDwGZnablle1+E878im49dDY2mSLVEQs21Pr V1iu6R9o+affi4MLFPAQSf1zTx6r6zotCO0Rnp33QfFo97UdLyL7I2qtpZhSczGU 4wTySD8qvM/02rUvszWg/YoJ12A7IU5YMjCXb/Lfkd6UYK/go4BA3BuqZAqSuvAN AWq6MEdOsV4uuchVm0ha1YgdQzt9vNveR4twYpSiQZ0MnzcB9020nLlHmVAB3+lY d04mKF1SMQ568mfes8/lNt0fefc6XkVvrZeIk+9uNn+irAynRRBZR2wpnvQT/Xev qc1FbxmTWdixlVg1kZL6 =b7Xz -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 25 16:06:21 2015 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Mar 2015 12:06:21 -0400 Subject: Cisco Security Advisory: Cisco IOS Software and IOS XE Software Internet Key Exchange Version 2 Denial of Service Vulnerabilities Message-ID: <201503251206.17.ikev2@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco IOS Software and IOS XE Software Internet Key Exchange Version 2 Denial of Service Vulnerabilities Advisory ID: cisco-sa-20150325-ikev2 Revision 1.0 For Public Release 2015 March 25 16:00 UTC (GMT) Summary ======= Devices running Cisco IOS Software or IOS XE Software contain vulnerabilities within the Internet Key Exchange (IKE) version 2 subsystem that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition. The vulnerabilities are due to how an affected device processes certain malformed IKEv2 packets. An attacker could exploit these vulnerabilities by sending malformed IKEv2 packets to an affected device to be processed. A successful exploit could allow the attacker to cause a reload of the affected device or excessive consumption of resources that would lead to a DoS condition. IKEv2 is automatically enabled on devices running Cisco IOS and Cisco IOS XE Software when the Internet Security Association and Key Management Protocol (ISAKMP) is enabled. these vulnerabilities can be triggered only by sending malformed IKEv2 packets. There are no workarounds for the vulnerabilities described in this advisory. Cisco has released free software updates that address these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150325-ikev2 Note: The March 25, 2015, Cisco IOS & XE Software Security Advisory bundled publication includes seven Cisco Security Advisories. The advisories address vulnerabilities in Cisco IOS Software and Cisco IOS XE Software. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS & XE Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar15.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJVEtQfAAoJEIpI1I6i1Mx3cC4QAKmoyPEnSiWyCB/TmzivfNls 2cSx2Xs2sa9KNNhqZ69hW9Q5GYhMeR89fwbNEdp/+rh3g79lE1wh/YlPwai8IJl9 t1pLC15TVky5xiEwFbmhEuqpTQ7QbdODsXR+dAVStRun8l/pnxM/r3yFRwtpeTDO vNsJNoIlIK+Wk3onNlMVdrPaSOkMhFZysuVB8hhCdF1kow5FCoMElZONU25+Tb5u 3+S32WC/L3jyDaWbQvDKTnNeHBp6M3+8Y7eXHg74CQzWLrCXN+CN6dPFaI7aR8oY P4a6lqSrkrPRXHUgxAqGKtDgzw8UDaxWdf3RX5z1r54syKzuUyuqNSnAwhZ9+pyW lhKv6Ai5ic4tyNEL++QFoZxnRg8xSopuD8yJzuyC5ZhP48tfGdZ1IIBBwxo4vKd5 9PfOlw3+oMvZrxzLL8ajGi/Vfk4LMayqe0jfmBWVMLMdBe0Dhz0Wxihyt7l+FNLS 2ovubZhBCtmhHSy+cyEgyXEjIG+5KFFJ35Wrm/U0LwXXyPIR2vgp6xn7MT1mKONi w9hWjuxFV4EAHAERvHvNR1fq6HZV+y+0vhG+GZR65XNEGrynxqBd8Dh5VpgAoX+i z8rvo9oSK/OsfbDA/qdSiNNRKAYQaKMFUy8MTFR7i2rwNduosPD36HvE4BAwhsox NgLDi9f/QtXaABCuBLeG =YsTm -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 25 16:06:54 2015 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Mar 2015 12:06:54 -0400 Subject: Cisco Security Advisory: Multiple Vulnerabilities in Cisco IOS Software and IOS XE Software Autonomic Networking Infrastructure Message-ID: <201503251206.17.ani@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Multiple Vulnerabilities in Cisco IOS Software and IOS XE Software Autonomic Networking Infrastructure Advisory ID: cisco-sa-20150325-ani Revision 1.0 For Public Release 2015 March 25 16:00 UTC (GMT) Summary ======= The Autonomic Networking Infrastructure (ANI) feature of Cisco IOS Software and IOS XE Software has multiple vulnerabilities which could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition or gain limited command and control of the device. Autonomic Networking Registration Authority Spoofing Vulnerability Autonomic Networking Infrastructure Spoofed Autonomic Networking Messages Denial of Service Vulnerability Autonomic Networking Infrastructure Device Reload Denial of Service Vulnerability Cisco has released free software updates that address these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150325-ani Note: The March 25, 2015, Cisco IOS & XE Software Security Advisory bundled publication includes seven Cisco Security Advisories. The advisories address vulnerabilities in Cisco IOS Software and Cisco IOS XE Software. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS & XE Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar15.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJVEg3EAAoJEIpI1I6i1Mx3D4kP/RHXNWflKJAGDDZwOfPHgPTu 3ILcyxaURs0troplCPwsJg94U8NZaeRiOQ8Xsu1s4ajquVEXLRFcdw5WKP/Yulir V7M106xpoemlQGMiw/MNEpAzzP4UNQBCO8A66gLrSGQVFI37C0ysH6yE/307d7Qz LX+aEF7nrOtOw6+ZbVF7irebyMGjaqfblOwDeuXzcyDfHp8hEKuIPfQEh7FaBooQ TnnySenNnhbfu6x0px7gTJteEMcOhDTOaW5m2MuF9STKRRGjauhng1IxJirJPC6k tyIJ+1VOop3Ps49E3czgWUtciFufCjgcl6SbmdYx97KCTQIyt7Mmel2cE37il7wR MzgSyuuIgI4METMdDWwxfTpujXXxdM5iRJNXpoSRzD40NFk9q57QvslwSSO6+1Yf ycnAGDVY+n9ahO3boZdMNne9V9dbCYIbVXES5VXxjaiHvCcRWIDUSJ+JeuX5s+em dMGGIqO8xz3Orl1i77kwWpo22V6txXX6YM07Bg52L+8xbbo7ChKDal5R6UAXsgRB vcA7ckhp28SDtlfy0aJHZHzvHNeOqCD55O8HaSdFoh94mkzBlFVxMkaKHnyeZWyA nWJtC8jHgu+VuyLien930AcUtY4NzO9ZT78c98FePuqkZbqKSvnRqYz69Dgaqu7i aqAAKX2qj2R18xzrUBya =yOgs -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 25 16:07:26 2015 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Mar 2015 12:07:26 -0400 Subject: Cisco Security Advisory: Multiple Vulnerabilities in Cisco IOS XE Software for Cisco ASR 1000 Series, Cisco ISR 4400 Series, and Cisco Cloud Services 1000v Series Routers Message-ID: <201503251207.17.iosxe@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Multiple Vulnerabilities in Cisco IOS XE Software for Cisco ASR 1000 Series, Cisco ISR 4400 Series, and Cisco Cloud Services 1000v Series Routers Advisory ID: cisco-sa-20150325-iosxe Revision 1.0 For Public Release 2015 March 25 16:00 UTC (GMT) Summary ======= Cisco IOS XE Software for Cisco ASR 1000 Series Aggregation Services Routers (ASR), Cisco 4400 Series Integrated Services Routers (ISR), and Cisco Cloud Services Routers (CSR) 1000v Series contains the following vulnerabilities: Cisco IOS XE Software Fragmented Packet Denial of Service Vulnerability Cisco IOS XE Software Crafted TCP Packet Remote Code Execution Vulnerability Cisco IOS XE Software Crafted IPv6 Packet Denial of Service Vulnerability Cisco IOS XE Software Layer 4 Redirect Crafted Packet Denial of Service Vulnerability Cisco IOS XE Software Common Flow Table Crafted Packet Denial of Service Vulnerability These vulnerabilities are independent of each other; a release that is affected by one of the vulnerabilities may not be affected by the others. Successful exploitation of any of these vulnerabilities could allow an unauthenticated, remote attacker to trigger a reload of the forwarding plane, causing an interruption of services. Repeated exploitation could result in a sustained denial of service (DoS) condition. Successful exploitation of Cisco IOS XE Software Crafted TCP Packet Remote Code Execution Vulnerability could allow an unauthenticated remote attacker to execute malicious code on the affected device. Cisco has released free software updates that address these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150325-iosxe Note: The March 25, 2015, Cisco IOS & XE Software Security Advisory bundled publication includes seven Cisco Security Advisories. The advisories address vulnerabilities in Cisco IOS Software and Cisco IOS XE Software. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS & XE Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar15.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJVEg3EAAoJEIpI1I6i1Mx3VW8QAL2oALHAprX3uic7IXrFPW95 Cb4bqya2PjrAzZmGlDFCGr2Mko0j+Q9zgX/AGjrtQkaZaHHp7KhpdLGNrnpyEpgj Da9TYL5k/JW/xxWmh3u9q62tUjlgHRHAUqsWAKq7jgJuftqS6u5BdTIIuBhTZeqo yy9QrHTnKtiDwjW4pyvEXft+2OaRZ2u5w+9jdRk6YO41OEHdeiPBQwzOZNQUPi6C n60N1DsvPm8V+u/3i1h1ApENv8iqm/5PxF4pqPC3QgBAzI0JoV6qUokts3U15B6W 1M1cd+lBBze2ztgP8tMhYbwFcbx8WjydYdNjHpaWhv9S+eCWW63nUmlpU4x0Vx9X bVwsooTAtf+j+bfxxq2Agm14n/mjTb/+7Fwh9idoA3UVC1JfMpXuXwKAPXr7Sumz 00kXL2A44thnrEYB+sZmo24XiC/Y+QC0rILr6S1GBy7t/h6qRA4MzITIu0T54jle lwYwwI1RPmo0QL4XFXUUmtowlfvpH3lu5PFD/BwbV5cdsiDrs/ahqcwBVNnReQQe cUUYGBuYz2t3UOuYLQCyaNrd3OzLOn5wYrGk3veODzpYkNOH23fM1YiTVj/5qdV+ l22QBt/wgcrEN42YroCJxK1hxAMO7sB2qCJO/sCGirxN4AEYmp3xqTPb6T76a8jf lcPMb9mmEb9Mc8shvJmS =j74G -----END PGP SIGNATURE----- From morrowc.lists at gmail.com Wed Mar 25 16:47:10 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 25 Mar 2015 12:47:10 -0400 Subject: Last-call DoS/DoS Attack BCOP In-Reply-To: <20150325075015.7330e0ea@localhost> References: <88F2A9A6-1B7C-4B6E-BD79-390945C48B1E@gmail.com> <8287D712-0327-4DFE-AE80-FC9E6A659458@gmail.com> <20150323182142.364b56df@localhost> <86iodq68zh.fsf@valhalla.seastrom.com> <86619pclel.fsf@valhalla.seastrom.com> <20150325075015.7330e0ea@localhost> Message-ID: On Wed, Mar 25, 2015 at 8:50 AM, John Kristoff wrote: > On Wed, 25 Mar 2015 08:27:14 -0400 > Rob Seastrom wrote: > >> John's statement was in the context of general advice to be included >> in a BCOP document and I felt compelled to say "whoa there". ok, that was my reaction as well. > My intent was for it to be taken as a DDoS mitigation response option, > not as a general practice. ok, I read over the bcop, I'm certain I wouldn't have used some of the words on the page, I'm certain that there are things suggested which I disagree with (mass filtering at your edge, if you are an ISP, all the time)... but I've not got the energy to poke too much more at this document :( and folk will find their balance anyway. From timphp at progressivemarketingnetwork.com Wed Mar 25 22:41:50 2015 From: timphp at progressivemarketingnetwork.com (Tim) Date: Wed, 25 Mar 2015 16:41:50 -0600 Subject: godaddy contact Message-ID: <551339AE.8010203@progressivemarketingnetwork.com> Anyone from godaddy on here or have contact details for them? We are having a routing issue to them. From aaron at heyaaron.com Thu Mar 26 02:31:35 2015 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Wed, 25 Mar 2015 19:31:35 -0700 Subject: Frontier: Blocking port 22 because of illegal files? Message-ID: I've had a handful of clients contact me over the last week with trouble using SCP (usually WinSCP) to manage their website content on my servers. Either they get timeout messages from WinSCP or a message saying they should switch to SFTP. After getting a few helpful users on the phone to run some quick tests, we found port 22 was blocked. When my customers contacted Frontier, they were told that port 22 was blocked because it is used to transfer illegal files. I called them, and got the same ridiculous excuse. Just a friendly heads-up to anyone from Frontier who might be listening, I have a few additional ports you may wish to block: 80 - Allows users to use Google to search for illegal files 443 - Allows users to use Google to search for illegal files in a secure manner 69 - Allows users to trivially transfer illegal files 3389 - Allows users to connect to unlicensed Windows machines 179 - Allows users to exchange routes to illegal file shares 53 - Allows people to look up illegal names -A From rea+nanog at grid.kiae.ru Thu Mar 26 04:21:45 2015 From: rea+nanog at grid.kiae.ru (Eygene Ryabinkin) Date: Thu, 26 Mar 2015 07:21:45 +0300 Subject: Frontier: Blocking port 22 because of illegal files? In-Reply-To: References: Message-ID: Wed, Mar 25, 2015 at 07:31:35PM -0700, Aaron C. de Bruyn wrote: > Just a friendly heads-up to anyone from Frontier who might be > listening, I have a few additional ports you may wish to block: > > 80 - Allows users to use Google to search for illegal files > 443 - Allows users to use Google to search for illegal files in a secure manner > 69 - Allows users to trivially transfer illegal files > 3389 - Allows users to connect to unlicensed Windows machines > 179 - Allows users to exchange routes to illegal file shares > 53 - Allows people to look up illegal names Can't help to add that there are - port 21 that allow users to give commands to examine the existence and initiate transfers of illegal files; - ports 1025 - 65535 that allow users to create data streams to actually transfer illegal files in an (oh my) passive mode. ;) -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. From jlewis at lewis.org Thu Mar 26 04:56:21 2015 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 26 Mar 2015 00:56:21 -0400 (EDT) Subject: Frontier: Blocking port 22 because of illegal files? In-Reply-To: References: Message-ID: On Wed, 25 Mar 2015, Aaron C. de Bruyn wrote: > I've had a handful of clients contact me over the last week with > trouble using SCP (usually WinSCP) to manage their website content on > my servers. Either they get timeout messages from WinSCP or a message > saying they should switch to SFTP. > > After getting a few helpful users on the phone to run some quick > tests, we found port 22 was blocked. > > When my customers contacted Frontier, they were told that port 22 was > blocked because it is used to transfer illegal files. > > I called them, and got the same ridiculous excuse. > > Just a friendly heads-up to anyone from Frontier who might be > listening, I have a few additional ports you may wish to block: I wonder if their support is just confused, and Frontier is really blocking outbound tcp/22 to stop complaints generated by infected customers with sshd scanners. After all, most of their customers probably don't know what SSH is. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From list at satchell.net Thu Mar 26 11:24:38 2015 From: list at satchell.net (Stephen Satchell) Date: Thu, 26 Mar 2015 04:24:38 -0700 Subject: Frontier: Blocking port 22 because of illegal files? In-Reply-To: References: Message-ID: <5513EC76.5060306@satchell.net> On 03/25/2015 07:31 PM, Aaron C. de Bruyn wrote: > After getting a few helpful users on the phone to run some quick > tests, we found port 22 was blocked. It's been a while since I did this, but you can select an additional port to accept SSH connections. A Google search indicates you can specify multiple ports in OpenSSH. Picking the right port to use is an exercise, though, that will depend on what other services you are running on your server. People with sane ISPs can use the standard port. People on Frontier can use the alternate port, which shouldn't be firewalled by the provider. If Frontier is running a mostly-closed firewall configuration, then you have to be damn careful about the port you select. From seth.mos at dds.nl Thu Mar 26 11:56:31 2015 From: seth.mos at dds.nl (Seth Mos) Date: Thu, 26 Mar 2015 12:56:31 +0100 Subject: Frontier: Blocking port 22 because of illegal files? In-Reply-To: <5513EC76.5060306@satchell.net> References: <5513EC76.5060306@satchell.net> Message-ID: <5513F3EF.2080805@dds.nl> Stephen Satchell schreef op 26-3-2015 om 12:24: > On 03/25/2015 07:31 PM, Aaron C. de Bruyn wrote: >> After getting a few helpful users on the phone to run some quick >> tests, we found port 22 was blocked. > > It's been a while since I did this, but you can select an additional > port to accept SSH connections. A Google search indicates you can > specify multiple ports in OpenSSH. Picking the right port to use is an > exercise, though, that will depend on what other services you are > running on your server. > > People with sane ISPs can use the standard port. People on Frontier can > use the alternate port, which shouldn't be firewalled by the provider. > If Frontier is running a mostly-closed firewall configuration, then you > have to be damn careful about the port you select. Ahem, just to clarify, he is not talking about inbound on the Frontier connection, but outbound *from* the Frontier network. Akin to the "Let's block outbound port 25 (smtp)". This is just a really really bad idea m'kay. Cheers From rodrigo at 1telecom.com.br Thu Mar 26 12:07:39 2015 From: rodrigo at 1telecom.com.br (Rodrigo Augusto) Date: Thu, 26 Mar 2015 09:07:39 -0300 Subject: booster to gain distance above 60km Message-ID: Hi folksŠ we have a point and have a 63km between point A to point BŠ. We have a sigle fiber ( only one fiber) and use a fiberstore sfp+ 10GB dibi 1270/1330 module to connect these sites. All attenuation are okŠI don¹t have any trouble on fiber Š. I have received this signal on my sfp+: Receiver signal average optical power : 0.0026 mW / -25.85 dBm Does anyone know if have some possible to amplifier this scenario to get more 7db ? Is it possible to put any booster or any way to solve this? I think to use a optical PreAmlifierŠbut I don¹t know if is possible because my scenario have just one fiberŠor, use a ROPA- remote optical pumping amplifier) because I have 63kmŠ Does anyone have some idea? Rodrigo Augusto Gestor de T.I. Grupo Connectoway http://www.connectoway.com.br http://www.1telecom.com.br * rodrigo at connectoway.com.br ( (81) 3497-6060 ( (81) 8184-3646 ( INOC-DBA 52965*100 From lists at quux.de Thu Mar 26 12:10:35 2015 From: lists at quux.de (Jens Link) Date: Thu, 26 Mar 2015 13:10:35 +0100 Subject: Frontier: Blocking port 22 because of illegal files? In-Reply-To: <5513EC76.5060306@satchell.net> (Stephen Satchell's message of "Thu, 26 Mar 2015 04:24:38 -0700") References: <5513EC76.5060306@satchell.net> Message-ID: <87mw30hscj.fsf@pc8.berlin.quux.de> Stephen Satchell writes: > It's been a while since I did this, but you can select an additional > port to accept SSH connections. That's easy: jens at screen:~$ grep Port /etc/ssh/sshd_config Port 22 Port 443 > Picking the right port to use is an exercise, though, that will depend > on what other services you are running on your server. I always have at least one sshd listening on port 443. For all the hotel, coffee house, customer networks blocking ssh. You can even multiplex and run ssh and ssl on the same port: http://www.rutschle.net/tech/sslh.shtml Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at jabber.quux.de | --------------- | ---------------------------------------------------------------------------- From amps at djlab.com Thu Mar 26 14:08:20 2015 From: amps at djlab.com (Randy) Date: Thu, 26 Mar 2015 07:08:20 -0700 Subject: Prefix hijack by INDOSAT AS4795 / AS4761 Message-ID: On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing more specifics on one of our prefixes. Anyone else seeing similar or is it just us? 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 -- Randy From Jason_Livingood at cable.comcast.com Thu Mar 26 14:09:52 2015 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Thu, 26 Mar 2015 14:09:52 +0000 Subject: Frontier: Blocking port 22 because of illegal files? In-Reply-To: References: Message-ID: ISPs are generally expected to disclose any port blocking. A quick Google search shows this is Frontier’s list: http://www.frontierhelp.com/faq.cfm?qstid=277 On 3/25/15, 10:31 PM, "Aaron C. de Bruyn" > wrote: I've had a handful of clients contact me over the last week with trouble using SCP (usually WinSCP) to manage their website content on my servers. Either they get timeout messages from WinSCP or a message saying they should switch to SFTP. After getting a few helpful users on the phone to run some quick tests, we found port 22 was blocked. When my customers contacted Frontier, they were told that port 22 was blocked because it is used to transfer illegal files. I called them, and got the same ridiculous excuse. Just a friendly heads-up to anyone from Frontier who might be listening, I have a few additional ports you may wish to block: 80 - Allows users to use Google to search for illegal files 443 - Allows users to use Google to search for illegal files in a secure manner 69 - Allows users to trivially transfer illegal files 3389 - Allows users to connect to unlicensed Windows machines 179 - Allows users to exchange routes to illegal file shares 53 - Allows people to look up illegal names -A From morrowc.lists at gmail.com Thu Mar 26 14:27:21 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 26 Mar 2015 10:27:21 -0400 Subject: Prefix hijack by INDOSAT AS4795 / AS4761 In-Reply-To: References: Message-ID: On Thu, Mar 26, 2015 at 10:08 AM, Randy wrote: > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing more > specifics on one of our prefixes. Anyone else seeing similar or is it just > us? is your AS in the path below? (what is your AS so folk can check for your prefixes/customer-prefixes and attempt to help?) > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > -- > Randy From jeff.richmond at gmail.com Thu Mar 26 14:28:57 2015 From: jeff.richmond at gmail.com (Jeff Richmond) Date: Thu, 26 Mar 2015 07:28:57 -0700 Subject: Frontier: Blocking port 22 because of illegal files? In-Reply-To: References: Message-ID: <006E35AD-00E6-4B61-890F-29E580CE91C9@gmail.com> All, I have reached out to Aaron privately for details, but we do not block port 22 traffic unless it is in direct response to an attack or related item. Please let me know directly if you have any specific questions. Thanks, -Jeff > On Mar 26, 2015, at 7:09 AM, Livingood, Jason wrote: > > ISPs are generally expected to disclose any port blocking. A quick Google search shows this is Frontier’s list: > http://www.frontierhelp.com/faq.cfm?qstid=277 > > On 3/25/15, 10:31 PM, "Aaron C. de Bruyn" > wrote: > > I've had a handful of clients contact me over the last week with > trouble using SCP (usually WinSCP) to manage their website content on > my servers. Either they get timeout messages from WinSCP or a message > saying they should switch to SFTP. > > After getting a few helpful users on the phone to run some quick > tests, we found port 22 was blocked. > > When my customers contacted Frontier, they were told that port 22 was > blocked because it is used to transfer illegal files. > > I called them, and got the same ridiculous excuse. > > Just a friendly heads-up to anyone from Frontier who might be > listening, I have a few additional ports you may wish to block: > > 80 - Allows users to use Google to search for illegal files > 443 - Allows users to use Google to search for illegal files in a secure manner > 69 - Allows users to trivially transfer illegal files > 3389 - Allows users to connect to unlicensed Windows machines > 179 - Allows users to exchange routes to illegal file shares > 53 - Allows people to look up illegal names > > -A > From corbe at corbe.net Thu Mar 26 14:32:31 2015 From: corbe at corbe.net (Daniel Corbe) Date: Thu, 26 Mar 2015 10:32:31 -0400 Subject: Frontier: Blocking port 22 because of illegal files? In-Reply-To: (Jason Livingood's message of "Thu, 26 Mar 2015 14:09:52 +0000") References: Message-ID: <874mp7hls0.fsf@corbe.net> Nothing helps promote a free and open Internet more than micromanaging your users' download activity. Not really sure how someone comes to the conclusion that nobody really *needs* ssh for anything. "Livingood, Jason" writes: > ISPs are generally expected to disclose any port blocking. A quick Google search shows this is Frontier’s list: > http://www.frontierhelp.com/faq.cfm?qstid=277 > > On 3/25/15, 10:31 PM, "Aaron C. de Bruyn" > wrote: > > I've had a handful of clients contact me over the last week with > trouble using SCP (usually WinSCP) to manage their website content on > my servers. Either they get timeout messages from WinSCP or a message > saying they should switch to SFTP. > > After getting a few helpful users on the phone to run some quick > tests, we found port 22 was blocked. > > When my customers contacted Frontier, they were told that port 22 was > blocked because it is used to transfer illegal files. > > I called them, and got the same ridiculous excuse. > > Just a friendly heads-up to anyone from Frontier who might be > listening, I have a few additional ports you may wish to block: > > 80 - Allows users to use Google to search for illegal files > 443 - Allows users to use Google to search for illegal files in a secure manner > 69 - Allows users to trivially transfer illegal files > 3389 - Allows users to connect to unlicensed Windows machines > 179 - Allows users to exchange routes to illegal file shares > 53 - Allows people to look up illegal names > > -A From amps at djlab.com Thu Mar 26 14:38:08 2015 From: amps at djlab.com (Randy) Date: Thu, 26 Mar 2015 07:38:08 -0700 Subject: Prefix hijack by INDOSAT AS4795 / AS4761 In-Reply-To: References: Message-ID: On 03/26/2015 7:27 am, Christopher Morrow wrote: > is your AS in the path below? (what is your AS so folk can check for > your prefixes/customer-prefixes and attempt to help?) Sorry, we're 29889. From rocca at start.ca Thu Mar 26 14:43:20 2015 From: rocca at start.ca (Peter Rocca) Date: Thu, 26 Mar 2015 14:43:20 +0000 Subject: Prefix hijack by INDOSAT AS4795 / AS4761 In-Reply-To: References: Message-ID: <44c3b7398b0c46b8a842c44da3f379be@APP02.start.local> We just received a similar alert from bgpmon - part of 108.168.0.0/17 is being advertised as /20's - although we're still listed as the origin. We are 40788. 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Sent: March-26-15 10:08 AM To: nanog at nanog.org Subject: Prefix hijack by INDOSAT AS4795 / AS4761 On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing more specifics on one of our prefixes. Anyone else seeing similar or is it just us? 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 -- Randy From morrowc.lists at gmail.com Thu Mar 26 14:44:28 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 26 Mar 2015 10:44:28 -0400 Subject: Prefix hijack by INDOSAT AS4795 / AS4761 In-Reply-To: References: Message-ID: On Thu, Mar 26, 2015 at 10:38 AM, Randy wrote: > On 03/26/2015 7:27 am, Christopher Morrow wrote: >> >> is your AS in the path below? (what is your AS so folk can check for >> your prefixes/customer-prefixes and attempt to help?) > > > Sorry, we're 29889. > ok, and it looks like the path you clipped is: 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 possibly LAIX is passing along your /24 you didn't mean them to pass on? From morrowc.lists at gmail.com Thu Mar 26 14:45:09 2015 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 26 Mar 2015 10:45:09 -0400 Subject: Prefix hijack by INDOSAT AS4795 / AS4761 In-Reply-To: <44c3b7398b0c46b8a842c44da3f379be@APP02.start.local> References: <44c3b7398b0c46b8a842c44da3f379be@APP02.start.local> Message-ID: On Thu, Mar 26, 2015 at 10:43 AM, Peter Rocca wrote: > We just received a similar alert from bgpmon - part of 108.168.0.0/17 is being advertised as /20's - although we're still listed as the origin. We are 40788. > > 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > common point looks like LAIX ? their routeserver go crazy perhaps? or did they change in/out prefix management information? > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy > Sent: March-26-15 10:08 AM > To: nanog at nanog.org > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > more specifics on one of our prefixes. Anyone else seeing similar or > is it just us? > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > -- > Randy From amps at djlab.com Thu Mar 26 14:46:31 2015 From: amps at djlab.com (Randy) Date: Thu, 26 Mar 2015 07:46:31 -0700 Subject: Prefix hijack by INDOSAT AS4795 / AS4761 In-Reply-To: References: Message-ID: <78c55aee9b1853c827c78adb8527fafb@mailbox.fastserv.com> All, Info gathered off-list indicates this may be a couple of issues in our case - possible routing leak by 18978 (check your tables!) and more specifics on our prefixes from 4795 that we couldn't see before the leak hence the apparent hijack. -- ~Randy From petrus.lt at gmail.com Thu Mar 26 14:46:51 2015 From: petrus.lt at gmail.com (Pierre Emeriaud) Date: Thu, 26 Mar 2015 15:46:51 +0100 Subject: Prefix hijack by INDOSAT AS4795 / AS4761 In-Reply-To: References: Message-ID: Hi, 2015-03-26 15:08 GMT+01:00 Randy : > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing more > specifics on one of our prefixes. Anyone else seeing similar or is it just > us? > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 We (as3215) are seeing almost the same path with 40633 18978 3257 3215, for some quite a lot of prefixes. Some alerts from bgpmon: 193.251.32.0/20 271 6939 40633 18978 3257 3215 193.251.32.0/20 271 6939 40633 18978 3257 3215 We are not directly connected to 3257. Looks like 18978 deaggregated to /20 and reannounced to 40633 (LAIX). Rgds, pierre From contact at winterei.se Thu Mar 26 14:48:12 2015 From: contact at winterei.se (Paul S.) Date: Thu, 26 Mar 2015 23:48:12 +0900 Subject: Prefix hijack by INDOSAT AS4795 / AS4761 In-Reply-To: <44c3b7398b0c46b8a842c44da3f379be@APP02.start.local> References: <44c3b7398b0c46b8a842c44da3f379be@APP02.start.local> Message-ID: <55141C2C.40706@winterei.se> Same here. These Indosat guys can't seem to catch a break =/ On 3/26/2015 午後 11:43, Peter Rocca wrote: > We just received a similar alert from bgpmon - part of 108.168.0.0/17 is being advertised as /20's - although we're still listed as the origin. We are 40788. > > 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy > Sent: March-26-15 10:08 AM > To: nanog at nanog.org > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > more specifics on one of our prefixes. Anyone else seeing similar or > is it just us? > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > From cra at WPI.EDU Thu Mar 26 15:00:31 2015 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 26 Mar 2015 11:00:31 -0400 Subject: Prefix hijack by INDOSAT AS4795 / AS4761 In-Reply-To: References: <44c3b7398b0c46b8a842c44da3f379be@APP02.start.local> Message-ID: <20150326150030.GO9776@angus.ind.WPI.EDU> We are AS 10326 130.215.0.0/16 and I just received a BGPmon alert as well: 130.215.160.0/20 4795 4795 4761 9304 40633 18978 4436 10326 130.215.176.0/20 4795 4795 4761 9304 40633 18978 4436 10326 On Thu, Mar 26, 2015 at 10:45:09AM -0400, Christopher Morrow wrote: > On Thu, Mar 26, 2015 at 10:43 AM, Peter Rocca wrote: > > We just received a similar alert from bgpmon - part of 108.168.0.0/17 is being advertised as /20's - although we're still listed as the origin. We are 40788. > > > > 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > > > common point looks like LAIX ? their routeserver go crazy perhaps? or > did they change in/out prefix management information? > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy > > Sent: March-26-15 10:08 AM > > To: nanog at nanog.org > > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > > > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > > more specifics on one of our prefixes. Anyone else seeing similar or > > is it just us? > > > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > > > -- > > Randy From christian.teuschel at ripe.net Thu Mar 26 15:02:00 2015 From: christian.teuschel at ripe.net (Christian Teuschel) Date: Thu, 26 Mar 2015 16:02:00 +0100 Subject: Prefix hijack by INDOSAT AS4795 / AS4761 In-Reply-To: <78c55aee9b1853c827c78adb8527fafb@mailbox.fastserv.com> References: <78c55aee9b1853c827c78adb8527fafb@mailbox.fastserv.com> Message-ID: <55141F68.9060900@ripe.net> Hi Randy, Assuming that your prefix is 198.98.180.0/22 (AS29889 - FSNET-1 - Fast Serv Networks, LLC) none of the mentioned more specifics are currently seen from the RIPE NCC's RIS network, see the Looking Glass widget: https://stat.ripe.net/198.98.180.0/23#tabId=routing https://stat.ripe.net/198.98.182.0/23#tabId=at-a-glance though there has been some BGP activity going on since 11:49:42, see the BGPlay and BGP Update Activity widget. In both cases the originating ASN was AS29889. Cheers, Christian On 26/03/15 15:46, Randy wrote: > All, > > Info gathered off-list indicates this may be a couple of issues in our > case - possible routing leak by 18978 (check your tables!) and more > specifics on our prefixes from 4795 that we couldn't see before the leak > hence the apparent hijack. > -------------- next part -------------- A non-text attachment was scrubbed... Name: christian_teuschel.vcf Type: text/x-vcard Size: 342 bytes Desc: not available URL: From andree+nanog at toonk.nl Thu Mar 26 15:53:37 2015 From: andree+nanog at toonk.nl (Andree Toonk) Date: Thu, 26 Mar 2015 08:53:37 -0700 Subject: Prefix hijack by INDOSAT AS4795 / AS4761 In-Reply-To: <44c3b7398b0c46b8a842c44da3f379be@APP02.start.local> References: <44c3b7398b0c46b8a842c44da3f379be@APP02.start.local> Message-ID: <55142B81.9000305@toonk.nl> Hi List, this morning our BGPmon system picked up many new more specific announcements by a variety of Origin ASns, the interesting part is that the majority of them were classified as BGP Man In The middle attacks (MITM). A typical alert would look like: ==================================================================== Possible BGP MITM attack (Code: 21) ==================================================================== Your prefix: 23.20.0.0/15: Prefix Description: acxiom-online.com --- Amazon EC2 IAD prefix Update time: 2015-03-26 11:27 (UTC) Detected by #peers: 24 Detected prefix: 23.21.112.0/20 Announced by: AS14618 (AMAZON-AES - Amazon.com, Inc.,US) Upstream AS: AS3257 (TINET-BACKBONE Tinet SpA,DE) ASpath: 4608 24130 7545 6939 40633 18978 3257 14618 All alerts have the following part of the AS Path is common: 40633 1897 We're still looking into the details of this particular cases, but based on past experience it's likely that it is not in fact 14618 AWS, that originated this more specific (in this example), but most likely 18978 (or 40633), which leaked it to AS40633 Los Angeles Internet exchange, where others picked it up and propagated it to their customers. In the past we've seen similar issues caused by BGP traffic optimizers. These devices introduce new more specifics (try to keep the ASpath in tact) for Traffic engineering purposes, and then folks leak those. A good write up of a previous example can be found here: http://www.bgpmon.net/accidentally-stealing-the-internet/ A quick scan show that this affected over 5000 prefixes and about 145 Autonomous systems. All of these appear to be more specific prefixes (which is the scary part). Cheers, Andree PS. It appears this is not related to INDOSAT, they just happen to be one of the peers that picked this up. .-- My secret spy satellite informs me that at 2015-03-26 7:43 AM Peter Rocca wrote: > We just received a similar alert from bgpmon - part of 108.168.0.0/17 is being advertised as /20's - although we're still listed as the origin. We are 40788. > > 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy > Sent: March-26-15 10:08 AM > To: nanog at nanog.org > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > more specifics on one of our prefixes. Anyone else seeing similar or > is it just us? > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > From rocca at start.ca Thu Mar 26 16:00:13 2015 From: rocca at start.ca (Peter Rocca) Date: Thu, 26 Mar 2015 16:00:13 +0000 Subject: Prefix hijack by INDOSAT AS4795 / AS4761 In-Reply-To: <55142B81.9000305@toonk.nl> References: <44c3b7398b0c46b8a842c44da3f379be@APP02.start.local> <55142B81.9000305@toonk.nl> Message-ID: +1 The summary below aligns with our analysis as well. We've reached out to AS18978 to determine the status of the leak but at this time we're not seeing any operational impact. -----Original Message----- From: Andree Toonk [mailto:andree+nanog at toonk.nl] Sent: March-26-15 11:54 AM To: Peter Rocca Cc: nanog at nanog.org Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 Hi List, this morning our BGPmon system picked up many new more specific announcements by a variety of Origin ASns, the interesting part is that the majority of them were classified as BGP Man In The middle attacks (MITM). A typical alert would look like: ==================================================================== Possible BGP MITM attack (Code: 21) ==================================================================== Your prefix: 23.20.0.0/15: Prefix Description: acxiom-online.com --- Amazon EC2 IAD prefix Update time: 2015-03-26 11:27 (UTC) Detected by #peers: 24 Detected prefix: 23.21.112.0/20 Announced by: AS14618 (AMAZON-AES - Amazon.com, Inc.,US) Upstream AS: AS3257 (TINET-BACKBONE Tinet SpA,DE) ASpath: 4608 24130 7545 6939 40633 18978 3257 14618 All alerts have the following part of the AS Path is common: 40633 1897 We're still looking into the details of this particular cases, but based on past experience it's likely that it is not in fact 14618 AWS, that originated this more specific (in this example), but most likely 18978 (or 40633), which leaked it to AS40633 Los Angeles Internet exchange, where others picked it up and propagated it to their customers. In the past we've seen similar issues caused by BGP traffic optimizers. These devices introduce new more specifics (try to keep the ASpath in tact) for Traffic engineering purposes, and then folks leak those. A good write up of a previous example can be found here: http://www.bgpmon.net/accidentally-stealing-the-internet/ A quick scan show that this affected over 5000 prefixes and about 145 Autonomous systems. All of these appear to be more specific prefixes (which is the scary part). Cheers, Andree PS. It appears this is not related to INDOSAT, they just happen to be one of the peers that picked this up. .-- My secret spy satellite informs me that at 2015-03-26 7:43 AM Peter Rocca wrote: > We just received a similar alert from bgpmon - part of 108.168.0.0/17 is being advertised as /20's - although we're still listed as the origin. We are 40788. > > 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy > Sent: March-26-15 10:08 AM > To: nanog at nanog.org > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > more specifics on one of our prefixes. Anyone else seeing similar or > is it just us? > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > From shawnl at up.net Thu Mar 26 16:09:10 2015 From: shawnl at up.net (Shawn L) Date: Thu, 26 Mar 2015 12:09:10 -0400 Subject: Charter Engineer Message-ID: Could a Charter engineer with familiarity with Michigan contact me off-list? We have a mutual client who's having issues communicating between sites. Thanks From amps at djlab.com Thu Mar 26 16:14:25 2015 From: amps at djlab.com (Randy) Date: Thu, 26 Mar 2015 09:14:25 -0700 Subject: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 / AS4761] In-Reply-To: References: <44c3b7398b0c46b8a842c44da3f379be@APP02.start.local> <55142B81.9000305@toonk.nl> Message-ID: On 03/26/2015 9:00 am, Peter Rocca wrote: > +1 > > The summary below aligns with our analysis as well. > > We've reached out to AS18978 to determine the status of the leak but > at this time we're not seeing any operational impact. +2, after the morning coffee sunk in and helpful off list replies I can finally see it's probably not INDOSAT involved at all. FYI, the more specifics are still active: 2015-03-26 13:56:11 Update AS4795 ID 198.98.180.0/23 4795 4795 4761 9304 40633 18978 6939 29889 Active 2015-03-26 13:56:11 Update AS4795 ID 198.98.182.0/23 4795 4795 4761 9304 40633 18978 6939 29889 Active -- ~Randy From nick.rose at enzu.com Thu Mar 26 19:48:38 2015 From: nick.rose at enzu.com (Nick Rose) Date: Thu, 26 Mar 2015 19:48:38 +0000 Subject: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 / AS4761] In-Reply-To: References: <44c3b7398b0c46b8a842c44da3f379be@APP02.start.local> <55142B81.9000305@toonk.nl> Message-ID: This should be resolved from AS18978. If you experience anything else please let me know and I will get it addressed immediately. Regards, Nick Rose CTO @ Enzu Inc. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Sent: Thursday, March 26, 2015 12:14 PM To: Peter Rocca Cc: nanog at nanog.org Subject: RE: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 / AS4761] On 03/26/2015 9:00 am, Peter Rocca wrote: > +1 > > The summary below aligns with our analysis as well. > > We've reached out to AS18978 to determine the status of the leak but > at this time we're not seeing any operational impact. +2, after the morning coffee sunk in and helpful off list replies I can finally see it's probably not INDOSAT involved at all. FYI, the more specifics are still active: 2015-03-26 13:56:11 Update AS4795 ID 198.98.180.0/23 4795 4795 4761 9304 40633 18978 6939 29889 Active 2015-03-26 13:56:11 Update AS4795 ID 198.98.182.0/23 4795 4795 4761 9304 40633 18978 6939 29889 Active -- ~Randy From aaron at heyaaron.com Thu Mar 26 19:55:43 2015 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Thu, 26 Mar 2015 12:55:43 -0700 Subject: Frontier: Blocking port 22 because of illegal files? In-Reply-To: References: Message-ID: Someone with Frontier contacted me off-list and assured me they don't block port 22, and that it could have been related to port scans, infected PCs, etc... They are looking in to it. Apologies for the noise and for being a prat. ;) -A On Wed, Mar 25, 2015 at 7:31 PM, Aaron C. de Bruyn wrote: > I've had a handful of clients contact me over the last week with > trouble using SCP (usually WinSCP) to manage their website content on > my servers. Either they get timeout messages from WinSCP or a message > saying they should switch to SFTP. > > After getting a few helpful users on the phone to run some quick > tests, we found port 22 was blocked. > > When my customers contacted Frontier, they were told that port 22 was > blocked because it is used to transfer illegal files. > > I called them, and got the same ridiculous excuse. > > Just a friendly heads-up to anyone from Frontier who might be > listening, I have a few additional ports you may wish to block: > > 80 - Allows users to use Google to search for illegal files > 443 - Allows users to use Google to search for illegal files in a secure manner > 69 - Allows users to trivially transfer illegal files > 3389 - Allows users to connect to unlicensed Windows machines > 179 - Allows users to exchange routes to illegal file shares > 53 - Allows people to look up illegal names > > -A From amitchell at isipp.com Thu Mar 26 20:07:47 2015 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Thu, 26 Mar 2015 14:07:47 -0600 Subject: godaddy contact In-Reply-To: References: Message-ID: > Anyone from godaddy on here or have contact details for them? We are > having a routing issue to them. > Tim, please contact me offlist. Anne Anne P. Mitchell, Esq. CEO/President ISIPP SuretyMail Email Reputation, Accreditation & Certification Your mail system + SuretyMail accreditation = delivered to their inbox! http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Author: Section 6 of the Federal CAN-SPAM Act of 2003 Member, California Bar Cyberspace Law Committee Ret. Professor of Law, Lincoln Law School of San Jose 303-731-2121 | amitchell at isipp.com | @AnnePMitchell | Facebook/AnnePMitchell From nick.rose at enzu.com Thu Mar 26 22:20:57 2015 From: nick.rose at enzu.com (Nick Rose) Date: Thu, 26 Mar 2015 22:20:57 +0000 Subject: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 / AS4761] In-Reply-To: References: <44c3b7398b0c46b8a842c44da3f379be@APP02.start.local> <55142B81.9000305@toonk.nl> Message-ID: Several people asked me off list for more details, here is what I have regarding it. This morning a tier2 isp that connects to our network made an error in their router configuration causing the route leakage. The issue has been addressed and we will be performing a full post mortem to ensure this does not happen again. While investigating the issue we did find that the noction appliance stopped advertising the no export community string with its advertisements which is why certain prefixes were also seen. Regards, Nick Rose CTO @ Enzu Inc. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nick Rose Sent: Thursday, March 26, 2015 3:49 PM To: amps at djlab.com; Peter Rocca Cc: nanog at nanog.org Subject: RE: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 / AS4761] This should be resolved from AS18978. If you experience anything else please let me know and I will get it addressed immediately. Regards, Nick Rose CTO @ Enzu Inc. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy Sent: Thursday, March 26, 2015 12:14 PM To: Peter Rocca Cc: nanog at nanog.org Subject: RE: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 / AS4761] On 03/26/2015 9:00 am, Peter Rocca wrote: > +1 > > The summary below aligns with our analysis as well. > > We've reached out to AS18978 to determine the status of the leak but > at this time we're not seeing any operational impact. +2, after the morning coffee sunk in and helpful off list replies I can finally see it's probably not INDOSAT involved at all. FYI, the more specifics are still active: 2015-03-26 13:56:11 Update AS4795 ID 198.98.180.0/23 4795 4795 4761 9304 40633 18978 6939 29889 Active 2015-03-26 13:56:11 Update AS4795 ID 198.98.182.0/23 4795 4795 4761 9304 40633 18978 6939 29889 Active -- ~Randy From mike-nanog at tiedyenetworks.com Thu Mar 26 22:38:55 2015 From: mike-nanog at tiedyenetworks.com (Mike) Date: Thu, 26 Mar 2015 15:38:55 -0700 Subject: Broken SSL cert caused by router? Message-ID: <55148A7F.5020209@tiedyenetworks.com> Hi, I have a very odd problem. We've recently gotten a 'real' ssl certificate from godaddy to cover our domain (*.domain.com) and have installed it in several places where needed for email (imap/starttls and etc) and web. This works great, seems ok according to various online TLS certificate checkers, and I get the green lock when testing using my own browsers and such. I have a customer however that uses our web mail system now secured with ssl. I myself and many others use it and get the green lock. But, whenever any station at the customer tries using it, they get a broken lock and 'your connection is not private'. The actual error displayed below is 'cert_authority_invalid' and it's "Go Daddy Secure Certificate Authority - G2". And it gets worse - whenever I go to the location and use my own laptop, the very one that 'works' when at my office, I ALSO get the error. AND EVEN WORSE - when I connect to my cell phone provided hotspot, the error goes away! As weird as this all sounds, I got it nailed down to one device - they have a Cisco/Meraki MX64W as their internet gateway - and when I remove that device from the chain and go 'straight' out to the internet, suddenly, the certificate problem goes away entirely. How is this possible? Can anyone comment on these devices and tell me what might be going on here? Mike- From rdobbins at arbor.net Thu Mar 26 22:51:11 2015 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 27 Mar 2015 05:51:11 +0700 Subject: Broken SSL cert caused by router? In-Reply-To: <55148A7F.5020209@tiedyenetworks.com> References: <55148A7F.5020209@tiedyenetworks.com> Message-ID: <0386AE4A-D2EB-4F4F-89AB-30B5E3A10FB4@arbor.net> On 27 Mar 2015, at 5:38, Mike wrote: > How is this possible? Can anyone comment on these devices and tell me > what might be going on here? It's been compromised and its being used for MITM? Or has some sort of TLS inspection capability built in which is essentially MITM, and which is enabled? Or some kind of content filtering capability which amounts to the same thing? ----------------------------------- Roland Dobbins From jbfixurpc at gmail.com Thu Mar 26 22:54:44 2015 From: jbfixurpc at gmail.com (Joe) Date: Thu, 26 Mar 2015 17:54:44 -0500 Subject: Broken SSL cert caused by router? In-Reply-To: <55148A7F.5020209@tiedyenetworks.com> References: <55148A7F.5020209@tiedyenetworks.com> Message-ID: You might want to look at some of the documentation on that device. Looks like it might be doing some proxy stuff. Regards, -Joe On Thu, Mar 26, 2015 at 5:38 PM, Mike wrote: > Hi, > > I have a very odd problem. > > We've recently gotten a 'real' ssl certificate from godaddy to cover our > domain (*.domain.com) and have installed it in several places where needed > for email (imap/starttls and etc) and web. This works great, seems ok > according to various online TLS certificate checkers, and I get the green > lock when testing using my own browsers and such. > > I have a customer however that uses our web mail system now secured with > ssl. I myself and many others use it and get the green lock. But, whenever > any station at the customer tries using it, they get a broken lock and 'your > connection is not private'. The actual error displayed below is > 'cert_authority_invalid' and it's "Go Daddy Secure Certificate Authority - > G2". And it gets worse - whenever I go to the location and use my own > laptop, the very one that 'works' when at my office, I ALSO get the error. > AND EVEN WORSE - when I connect to my cell phone provided hotspot, the error > goes away! > > As weird as this all sounds, I got it nailed down to one device - they > have a Cisco/Meraki MX64W as their internet gateway - and when I remove that > device from the chain and go 'straight' out to the internet, suddenly, the > certificate problem goes away entirely. > > How is this possible? Can anyone comment on these devices and tell me > what might be going on here? > > Mike- From rea+nanog at grid.kiae.ru Fri Mar 27 00:46:20 2015 From: rea+nanog at grid.kiae.ru (Eygene Ryabinkin) Date: Fri, 27 Mar 2015 03:46:20 +0300 Subject: Broken SSL cert caused by router? In-Reply-To: <55148A7F.5020209@tiedyenetworks.com> References: <55148A7F.5020209@tiedyenetworks.com> Message-ID: <2tE81IXfkDO+4QKT9p10O5HZZ44@xD7c2HZfPDzIruDUr3Qm9QhN1kk> Thu, Mar 26, 2015 at 03:38:55PM -0700, Mike wrote: > I have a customer however that uses our web mail system now secured > with ssl. I myself and many others use it and get the green lock. But, > whenever any station at the customer tries using it, they get a broken > lock and 'your connection is not private'. The actual error displayed > below is 'cert_authority_invalid' and it's "Go Daddy Secure Certificate > Authority - G2". And it gets worse - whenever I go to the location and > use my own laptop, the very one that 'works' when at my office, I ALSO > get the error. AND EVEN WORSE - when I connect to my cell phone provided > hotspot, the error goes away! > > As weird as this all sounds, I got it nailed down to one device - > they have a Cisco/Meraki MX64W as their internet gateway - and when I > remove that device from the chain and go 'straight' out to the internet, > suddenly, the certificate problem goes away entirely. > > How is this possible? Can anyone comment on these devices and tell > me what might be going on here? Sounds like deep packet inspection (DPI) with SSL MITM. Reading https://meraki.cisco.com/lib/pdf/meraki_datasheet_mx.pdf makes me believe that this device can do that. Look for it's configuration, DPI for HTTPS must be active. -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. From ml at kenweb.org Fri Mar 27 03:26:07 2015 From: ml at kenweb.org (ML) Date: Thu, 26 Mar 2015 23:26:07 -0400 Subject: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 / AS4761] In-Reply-To: References: <44c3b7398b0c46b8a842c44da3f379be@APP02.start.local> <55142B81.9000305@toonk.nl> Message-ID: <5514CDCF.2040602@kenweb.org> Wouldn't it be a BCP to set no-export from the Noction device too? On 3/26/2015 6:20 PM, Nick Rose wrote: > Several people asked me off list for more details, here is what I have regarding it. > > This morning a tier2 isp that connects to our network made an error in their router configuration causing the route leakage. The issue has been addressed and we will be performing a full post mortem to ensure this does not happen again. > While investigating the issue we did find that the noction appliance stopped advertising the no export community string with its advertisements which is why certain prefixes were also seen. > > Regards, > Nick Rose > CTO @ Enzu Inc. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nick Rose > Sent: Thursday, March 26, 2015 3:49 PM > To: amps at djlab.com; Peter Rocca > Cc: nanog at nanog.org > Subject: RE: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 / AS4761] > > This should be resolved from AS18978. If you experience anything else please let me know and I will get it addressed immediately. > > Regards, > Nick Rose > CTO @ Enzu Inc. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy > Sent: Thursday, March 26, 2015 12:14 PM > To: Peter Rocca > Cc: nanog at nanog.org > Subject: RE: More specifics from AS18978 [was: Prefix hijack by INDOSAT AS4795 / AS4761] > > On 03/26/2015 9:00 am, Peter Rocca wrote: >> +1 >> >> The summary below aligns with our analysis as well. >> >> We've reached out to AS18978 to determine the status of the leak but >> at this time we're not seeing any operational impact. > +2, after the morning coffee sunk in and helpful off list replies I can > finally see it's probably not INDOSAT involved at all. > > FYI, the more specifics are still active: > > 2015-03-26 13:56:11 Update AS4795 ID 198.98.180.0/23 4795 4795 4761 > 9304 40633 18978 6939 29889 Active > 2015-03-26 13:56:11 Update AS4795 ID 198.98.182.0/23 4795 4795 4761 > 9304 40633 18978 6939 29889 Active > > -- > ~Randy From ml-nanog at techcompute.net Fri Mar 27 03:57:09 2015 From: ml-nanog at techcompute.net (Lewis,Mitchell T.) Date: Thu, 26 Mar 2015 20:57:09 -0700 (PDT) Subject: Broken SSL cert caused by router? In-Reply-To: <55148A7F.5020209@tiedyenetworks.com> References: <55148A7F.5020209@tiedyenetworks.com> Message-ID: <37237.77.1427428575578.JavaMail.mtlewis@T410I> Meraki Access Points are interesting devices. I have found they cause issues with Linux firewalls if the merakis are not configured "correctly". Meraki Access Points do content inspections which I have found can cause produce symptoms similar to yours, although I have not experienced what you are describing. Since the MX64W is both an Access Point & security gateway, it has some additional content inspection/intelligence for it's security appliance role on top of the functions it performs as an access point, the same functions which are found in Meraki standalone access points as well. I am not sure what the specifics are as I do not use Meraki security appliances but it is worth checking. I have found with Meraki that items in the control panel/dashboard are not always labeled the best so I have found it is usually worth putting in a ticket with them and/or a call to them to see what they think (1-888-490-0918). Mitchell T. Lewis Mlewis at Techcompute.Net : www.linkedin.com/in/mlewiscc Mobile: (203)816-0371 PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E Public PGP Key A computer will do what you tell it to do, but that may be much different from what you had in mind. ~Joseph Weizenbaum ----- Original Message ----- From: "Mike" To: nanog at nanog.org Sent: Thursday, March 26, 2015 6:38:55 PM Subject: Broken SSL cert caused by router? Hi, I have a very odd problem. We've recently gotten a 'real' ssl certificate from godaddy to cover our domain (*.domain.com) and have installed it in several places where needed for email (imap/starttls and etc) and web. This works great, seems ok according to various online TLS certificate checkers, and I get the green lock when testing using my own browsers and such. I have a customer however that uses our web mail system now secured with ssl. I myself and many others use it and get the green lock. But, whenever any station at the customer tries using it, they get a broken lock and 'your connection is not private'. The actual error displayed below is 'cert_authority_invalid' and it's "Go Daddy Secure Certificate Authority - G2". And it gets worse - whenever I go to the location and use my own laptop, the very one that 'works' when at my office, I ALSO get the error. AND EVEN WORSE - when I connect to my cell phone provided hotspot, the error goes away! As weird as this all sounds, I got it nailed down to one device - they have a Cisco/Meraki MX64W as their internet gateway - and when I remove that device from the chain and go 'straight' out to the internet, suddenly, the certificate problem goes away entirely. How is this possible? Can anyone comment on these devices and tell me what might be going on here? Mike- From job at instituut.net Fri Mar 27 10:03:53 2015 From: job at instituut.net (Job Snijders) Date: Fri, 27 Mar 2015 11:03:53 +0100 Subject: More specifics from AS18978 In-Reply-To: <5514CDCF.2040602@kenweb.org> References: <44c3b7398b0c46b8a842c44da3f379be@APP02.start.local> <55142B81.9000305@toonk.nl> <5514CDCF.2040602@kenweb.org> Message-ID: <20150327100353.GM791@Vurt.local> On Thu, Mar 26, 2015 at 11:26:07PM -0400, ML wrote: > On 3/26/2015 6:20 PM, Nick Rose wrote: > >While investigating the issue we did find that the noction appliance > >stopped advertising the no export community string with its > >advertisements which is why certain prefixes were also seen. > > Wouldn't it be a BCP to set no-export from the Noction device too? Sure, but even that might not always prevent the fake paths from leaking to your eBGP neighbors. For instance, not too long ago there was this bug: "Routes learned with the no-export community from an iBGP neighbor are being advertised to eBGP neighbors. This may occur on Cisco ASR 9000 Series Aggregation Services Routers." (don't remember BugID) In other words: it can happen to the best of us. You should not lie to yourself by inserting fake more-specific paths into routing tables. The moment your lies somehow manage to escape into the default-free-zone you are taking other businesses down. Whether the leak is caused by a bug in the router's software or human error, destroying other people's online presence is far beyond acceptable. If the same leak would've happened /without/ the fake more-specifics, it'd still be an issue, but the collateral damage would have been dampened. The leaked paths would have to compete with the normal paths and best-path selectors like as-path length apply. Using software to insert fake more-specific paths into your routing domain should be discouraged and frowned upon. Kind regards, Job From mark.tinka at seacom.mu Fri Mar 27 10:10:19 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 27 Mar 2015 12:10:19 +0200 Subject: More specifics from AS18978 In-Reply-To: <20150327100353.GM791@Vurt.local> References: <44c3b7398b0c46b8a842c44da3f379be@APP02.start.local> <55142B81.9000305@toonk.nl> <5514CDCF.2040602@kenweb.org> <20150327100353.GM791@Vurt.local> Message-ID: <55152C8B.6050907@seacom.mu> On 27/Mar/15 12:03, Job Snijders wrote: > Sure, but even that might not always prevent the fake paths from leaking > to your eBGP neighbors. For instance, not too long ago there was this > bug: > > "Routes learned with the no-export community from an iBGP neighbor > are being advertised to eBGP neighbors. This may occur on Cisco ASR > 9000 Series Aggregation Services Routers." (don't remember BugID) > > In other words: it can happen to the best of us. Your upstream could also re-write any BGP communities you attach to your BGP updates; so unless co-ordinated, there is no real guarantee a NO_EXPORT community will be maintained/honoured within your upstream's network. Mark. From jason at lixfeld.ca Fri Mar 27 10:59:30 2015 From: jason at lixfeld.ca (Jason Lixfeld) Date: Fri, 27 Mar 2015 06:59:30 -0400 Subject: 802.11 based WISP hardware Message-ID: <673462AF-2AA5-47AE-A660-1BBC0F8ED737@lixfeld.ca> Hi all, I’m looking to gather some public opinion, links and pointers around the current landscape of WISP hardware vendors. I’m familiar with Cisco, Ruckus, AdTran, Motorola and Aruba (HP) but I’m wondering who else is out there that folks have used with success. My main areas of interest are around controller based (hardware or virtual (in-house, not off-net cloud based)) systems that have a range of indoor & outdoor 802.11AC PoE capable APs. The controller(s) would be capable of tunnelling traffic from the APs for one or more SSIDs, support per-SSID captive portals and unique, intra-SSID captive portals. In a perfect world, an on-board DHCP server would be super handy too. The system should support CAPWAP, but some proprietary alternative is also fine, the usual suite of security protocols per SSID, reliable intra-SSID AP roaming algorithms and multi-SSID capable. Thanks in advance. From dbrisson at uvm.edu Fri Mar 27 11:05:13 2015 From: dbrisson at uvm.edu (Dan Brisson) Date: Fri, 27 Mar 2015 07:05:13 -0400 Subject: 802.11 based WISP hardware In-Reply-To: <673462AF-2AA5-47AE-A660-1BBC0F8ED737@lixfeld.ca> References: <673462AF-2AA5-47AE-A660-1BBC0F8ED737@lixfeld.ca> Message-ID: <55153969.8040709@uvm.edu> Definitely take a look at Mikrotik. The gear is very low-cost with very large feature set. I have not used their CAPWAP functionality, so I can't speak to that. Ubiquiti is also very good and can do most, if not all, of what you want. -dan Dan Brisson Network Engineer University of Vermont On 3/27/15 6:59 AM, Jason Lixfeld wrote: > Hi all, > > I’m looking to gather some public opinion, links and pointers around the current landscape of WISP hardware vendors. I’m familiar with Cisco, Ruckus, AdTran, Motorola and Aruba (HP) but I’m wondering who else is out there that folks have used with success. My main areas of interest are around controller based (hardware or virtual (in-house, not off-net cloud based)) systems that have a range of indoor & outdoor 802.11AC PoE capable APs. The controller(s) would be capable of tunnelling traffic from the APs for one or more SSIDs, support per-SSID captive portals and unique, intra-SSID captive portals. In a perfect world, an on-board DHCP server would be super handy too. The system should support CAPWAP, but some proprietary alternative is also fine, the usual suite of security protocols per SSID, reliable intra-SSID AP roaming algorithms and multi-SSID capable. > > Thanks in advance. From drew.linsalata at gmail.com Fri Mar 27 11:17:10 2015 From: drew.linsalata at gmail.com (Drew Linsalata) Date: Fri, 27 Mar 2015 07:17:10 -0400 Subject: Comcast Postmaster IPv6 issue Message-ID: We're wresting with a Comcast IPv6 SMTP block and none of the Comcast postmaster communication tools allows entering an IPv6 address. End result = brick wall. If anyone from the Comcast postmaster team is listening, a message off-list would be most appreciated. From chipps at chipps.com Fri Mar 27 11:40:35 2015 From: chipps at chipps.com (Kenneth M. Chipps Ph.D.) Date: Fri, 27 Mar 2015 06:40:35 -0500 Subject: 802.11 based WISP hardware In-Reply-To: <673462AF-2AA5-47AE-A660-1BBC0F8ED737@lixfeld.ca> References: <673462AF-2AA5-47AE-A660-1BBC0F8ED737@lixfeld.ca> Message-ID: <02ed01d06882$d782dfe0$86889fa0$@chipps.com> In my experience in the rural areas around DFW most of the smaller operations, such as I had until recently, used Mikrotik equipment. Around here SkyBeam has bought out all of the small and most of the large WISPs. They retired the Mikrotik equipment in favor of Motorola Canopy originally. I was told the Canopy line may have been sold to someone else. I think Cambium. The Mikrotik equipment I had at the top of my 96 foot tall tower was rock solid. Never a hiccup in years of service in all kinds of weather. Of course I did a proper standards based installation including bonding and grounding. Proper installation makes a big difference no matter what you use. Kenneth M. Chipps Ph.D. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jason Lixfeld Sent: Friday, March 27, 2015 6:00 AM To: NANOG Subject: 802.11 based WISP hardware Hi all, I’m looking to gather some public opinion, links and pointers around the current landscape of WISP hardware vendors. I’m familiar with Cisco, Ruckus, AdTran, Motorola and Aruba (HP) but I’m wondering who else is out there that folks have used with success. My main areas of interest are around controller based (hardware or virtual (in-house, not off-net cloud based)) systems that have a range of indoor & outdoor 802.11AC PoE capable APs. The controller(s) would be capable of tunnelling traffic from the APs for one or more SSIDs, support per-SSID captive portals and unique, intra-SSID captive portals. In a perfect world, an on-board DHCP server would be super handy too. The system should support CAPWAP, but some proprietary alternative is also fine, the usual suite of security protocols per SSID, reliable intra-SSID AP roaming algorithms and multi-SSID capable. Thanks in advance. From ecrogers at precisionds.com Fri Mar 27 11:41:46 2015 From: ecrogers at precisionds.com (Eric Rogers) Date: Fri, 27 Mar 2015 07:41:46 -0400 Subject: 802.11 based WISP hardware References: <673462AF-2AA5-47AE-A660-1BBC0F8ED737@lixfeld.ca> Message-ID: Try Unifi by Ubiquiti. We use it for our public hotspots and our internal network. Very easy to manage, and you can load the controller in a VMWare instance. Eric Rogers PDSConnect www.pdsconnect.me (317) 831-3000 x200 -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jason Lixfeld Sent: Friday, March 27, 2015 7:00 AM To: NANOG Subject: 802.11 based WISP hardware Hi all, I’m looking to gather some public opinion, links and pointers around the current landscape of WISP hardware vendors. I’m familiar with Cisco, Ruckus, AdTran, Motorola and Aruba (HP) but I’m wondering who else is out there that folks have used with success. My main areas of interest are around controller based (hardware or virtual (in-house, not off-net cloud based)) systems that have a range of indoor & outdoor 802.11AC PoE capable APs. The controller(s) would be capable of tunnelling traffic from the APs for one or more SSIDs, support per-SSID captive portals and unique, intra-SSID captive portals. In a perfect world, an on-board DHCP server would be super handy too. The system should support CAPWAP, but some proprietary alternative is also fine, the usual suite of security protocols per SSID, reliable intra-SSID AP roaming algorithms and multi-SSID capable. Thanks in advance. From nanog at ics-il.net Fri Mar 27 12:29:18 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 27 Mar 2015 07:29:18 -0500 (CDT) Subject: 802.11 based WISP hardware In-Reply-To: <673462AF-2AA5-47AE-A660-1BBC0F8ED737@lixfeld.ca> Message-ID: <23043010.3848.1427459346367.JavaMail.mhammett@ThunderFuck> Typically WISP refers to an outdoor fixed wireless provider, not local area WiFi deployments. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Jason Lixfeld" To: "NANOG" Sent: Friday, March 27, 2015 5:59:30 AM Subject: 802.11 based WISP hardware Hi all, I’m looking to gather some public opinion, links and pointers around the current landscape of WISP hardware vendors. I’m familiar with Cisco, Ruckus, AdTran, Motorola and Aruba (HP) but I’m wondering who else is out there that folks have used with success. My main areas of interest are around controller based (hardware or virtual (in-house, not off-net cloud based)) systems that have a range of indoor & outdoor 802.11AC PoE capable APs. The controller(s) would be capable of tunnelling traffic from the APs for one or more SSIDs, support per-SSID captive portals and unique, intra-SSID captive portals. In a perfect world, an on-board DHCP server would be super handy too. The system should support CAPWAP, but some proprietary alternative is also fine, the usual suite of security protocols per SSID, reliable intra-SSID AP roaming algorithms and multi-SSID capable. Thanks in advance. From nanog at ics-il.net Fri Mar 27 12:33:59 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 27 Mar 2015 07:33:59 -0500 (CDT) Subject: 802.11 based WISP hardware In-Reply-To: <02ed01d06882$d782dfe0$86889fa0$@chipps.com> Message-ID: <4872309.3862.1427459625775.JavaMail.mhammett@ThunderFuck> Ken Chipps, there's a name I haven't seen in a while. Motorola did sell the Canopy line off to private equity and is now Cambiun Networks. I started with Mikrotik in my WISP and still use them for routers and switches, but I cannot recommend them for the fixed wireless portion. They haven't pursued FCC certification for 5150 - 5350 or 5470 - 5725. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Kenneth M. Chipps Ph.D." To: "NANOG" Sent: Friday, March 27, 2015 6:40:35 AM Subject: RE: 802.11 based WISP hardware In my experience in the rural areas around DFW most of the smaller operations, such as I had until recently, used Mikrotik equipment. Around here SkyBeam has bought out all of the small and most of the large WISPs. They retired the Mikrotik equipment in favor of Motorola Canopy originally. I was told the Canopy line may have been sold to someone else. I think Cambium. The Mikrotik equipment I had at the top of my 96 foot tall tower was rock solid. Never a hiccup in years of service in all kinds of weather. Of course I did a proper standards based installation including bonding and grounding. Proper installation makes a big difference no matter what you use. Kenneth M. Chipps Ph.D. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jason Lixfeld Sent: Friday, March 27, 2015 6:00 AM To: NANOG Subject: 802.11 based WISP hardware Hi all, I’m looking to gather some public opinion, links and pointers around the current landscape of WISP hardware vendors. I’m familiar with Cisco, Ruckus, AdTran, Motorola and Aruba (HP) but I’m wondering who else is out there that folks have used with success. My main areas of interest are around controller based (hardware or virtual (in-house, not off-net cloud based)) systems that have a range of indoor & outdoor 802.11AC PoE capable APs. The controller(s) would be capable of tunnelling traffic from the APs for one or more SSIDs, support per-SSID captive portals and unique, intra-SSID captive portals. In a perfect world, an on-board DHCP server would be super handy too. The system should support CAPWAP, but some proprietary alternative is also fine, the usual suite of security protocols per SSID, reliable intra-SSID AP roaming algorithms and multi-SSID capable. Thanks in advance. From jared at puck.nether.net Fri Mar 27 12:39:28 2015 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 27 Mar 2015 07:39:28 -0500 Subject: 802.11 based WISP hardware In-Reply-To: <4872309.3862.1427459625775.JavaMail.mhammett@ThunderFuck> References: <4872309.3862.1427459625775.JavaMail.mhammett@ThunderFuck> Message-ID: I would also caution those considering ubiquiti for anything fixed right now. They have a number of unaddressed issues with UNII frequencies and DFS. Jared Mauch > On Mar 27, 2015, at 7:33 AM, Mike Hammett wrote: > > Ken Chipps, there's a name I haven't seen in a while. > > Motorola did sell the Canopy line off to private equity and is now Cambiun Networks. > > I started with Mikrotik in my WISP and still use them for routers and switches, but I cannot recommend them for the fixed wireless portion. They haven't pursued FCC certification for 5150 - 5350 or 5470 - 5725. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > ----- Original Message ----- > > From: "Kenneth M. Chipps Ph.D." > To: "NANOG" > Sent: Friday, March 27, 2015 6:40:35 AM > Subject: RE: 802.11 based WISP hardware > > In my experience in the rural areas around DFW most of the smaller operations, such as I had until recently, used Mikrotik equipment. Around here SkyBeam has bought out all of the small and most of the large WISPs. They retired the Mikrotik equipment in favor of Motorola Canopy originally. I was told the Canopy line may have been sold to someone else. I think Cambium. > > The Mikrotik equipment I had at the top of my 96 foot tall tower was rock solid. Never a hiccup in years of service in all kinds of weather. Of course I did a proper standards based installation including bonding and grounding. Proper installation makes a big difference no matter what you use. > > Kenneth M. Chipps Ph.D. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jason Lixfeld > Sent: Friday, March 27, 2015 6:00 AM > To: NANOG > Subject: 802.11 based WISP hardware > > Hi all, > > I’m looking to gather some public opinion, links and pointers around the current landscape of WISP hardware vendors. I’m familiar with Cisco, Ruckus, AdTran, Motorola and Aruba (HP) but I’m wondering who else is out there that folks have used with success. My main areas of interest are around controller based (hardware or virtual (in-house, not off-net cloud based)) systems that have a range of indoor & outdoor 802.11AC PoE capable APs. The controller(s) would be capable of tunnelling traffic from the APs for one or more SSIDs, support per-SSID captive portals and unique, intra-SSID captive portals. In a perfect world, an on-board DHCP server would be super handy too. The system should support CAPWAP, but some proprietary alternative is also fine, the usual suite of security protocols per SSID, reliable intra-SSID AP roaming algorithms and multi-SSID capable. > > Thanks in advance. > From chipps at chipps.com Fri Mar 27 12:55:31 2015 From: chipps at chipps.com (Kenneth M. Chipps Ph.D.) Date: Fri, 27 Mar 2015 07:55:31 -0500 Subject: 802.11 based WISP hardware In-Reply-To: <4872309.3862.1427459625775.JavaMail.mhammett@ThunderFuck> References: <02ed01d06882$d782dfe0$86889fa0$@chipps.com> <4872309.3862.1427459625775.JavaMail.mhammett@ThunderFuck> Message-ID: <02fa01d0688d$506ea3d0$f14beb70$@chipps.com> I have noticed that larger companies do not like Mikrotik. Its market centered on the mom and pop operations around here. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett Sent: Friday, March 27, 2015 7:34 AM To: NANOG Subject: Re: 802.11 based WISP hardware Ken Chipps, there's a name I haven't seen in a while. Motorola did sell the Canopy line off to private equity and is now Cambiun Networks. I started with Mikrotik in my WISP and still use them for routers and switches, but I cannot recommend them for the fixed wireless portion. They haven't pursued FCC certification for 5150 - 5350 or 5470 - 5725. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Kenneth M. Chipps Ph.D." To: "NANOG" Sent: Friday, March 27, 2015 6:40:35 AM Subject: RE: 802.11 based WISP hardware In my experience in the rural areas around DFW most of the smaller operations, such as I had until recently, used Mikrotik equipment. Around here SkyBeam has bought out all of the small and most of the large WISPs. They retired the Mikrotik equipment in favor of Motorola Canopy originally. I was told the Canopy line may have been sold to someone else. I think Cambium. The Mikrotik equipment I had at the top of my 96 foot tall tower was rock solid. Never a hiccup in years of service in all kinds of weather. Of course I did a proper standards based installation including bonding and grounding. Proper installation makes a big difference no matter what you use. Kenneth M. Chipps Ph.D. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jason Lixfeld Sent: Friday, March 27, 2015 6:00 AM To: NANOG Subject: 802.11 based WISP hardware Hi all, I’m looking to gather some public opinion, links and pointers around the current landscape of WISP hardware vendors. I’m familiar with Cisco, Ruckus, AdTran, Motorola and Aruba (HP) but I’m wondering who else is out there that folks have used with success. My main areas of interest are around controller based (hardware or virtual (in-house, not off-net cloud based)) systems that have a range of indoor & outdoor 802.11AC PoE capable APs. The controller(s) would be capable of tunnelling traffic from the APs for one or more SSIDs, support per-SSID captive portals and unique, intra-SSID captive portals. In a perfect world, an on-board DHCP server would be super handy too. The system should support CAPWAP, but some proprietary alternative is also fine, the usual suite of security protocols per SSID, reliable intra-SSID AP roaming algorithms and multi-SSID capable. Thanks in advance. From Jason_Livingood at cable.comcast.com Fri Mar 27 13:15:46 2015 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Fri, 27 Mar 2015 13:15:46 +0000 Subject: Comcast Postmaster IPv6 issue In-Reply-To: References: Message-ID: Someone will reach out. In the future, FYI: http://postmaster.comcast.net/ Thx - Jason On 3/27/15, 12:17 PM, "Drew Linsalata" wrote: >We're wresting with a Comcast IPv6 SMTP block and none of the Comcast >postmaster communication tools allows entering an IPv6 address. End >result >= brick wall. > >If anyone from the Comcast postmaster team is listening, a message >off-list >would be most appreciated. From mike-nanog at tiedyenetworks.com Fri Mar 27 15:35:45 2015 From: mike-nanog at tiedyenetworks.com (Mike) Date: Fri, 27 Mar 2015 08:35:45 -0700 Subject: FIXED - Re: Broken SSL cert caused by router? In-Reply-To: <37237.77.1427428575578.JavaMail.mtlewis@T410I> References: <55148A7F.5020209@tiedyenetworks.com> <37237.77.1427428575578.JavaMail.mtlewis@T410I> Message-ID: <551578D1.8080903@tiedyenetworks.com> I'd like to thank everyone for their kind responses. One person who responded off list and bothered to look at the returned certificates pointed out, and correctly it seems, that my original setup was missing an intermediate certificate. The site was returning 'valid ssl' and all browsers got the green lock and offsite ssl tests came back ok, but apparently the missing intermediate means it would have had to have been fetched and that was the part that was failing at the customer site. Once I put the intermediate certificate in there, the customer site was able to access https without fail. I have not had an opportunity yet to examine in detail the config of the meraki router there but it's either a routing problem or a DPI problem. If I get an answer I'll post again with my results. Thanks all. Mike- From josh at imaginenetworksllc.com Fri Mar 27 15:43:50 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 27 Mar 2015 11:43:50 -0400 Subject: FIXED - Re: Broken SSL cert caused by router? In-Reply-To: <551578D1.8080903@tiedyenetworks.com> References: <55148A7F.5020209@tiedyenetworks.com> <37237.77.1427428575578.JavaMail.mtlewis@T410I> <551578D1.8080903@tiedyenetworks.com> Message-ID: FFR you can use this to verify the site itself is good or not: https://www.sslshopper.com/ssl-checker.html (there are others, this is just what I have bookmarked) Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, Mar 27, 2015 at 11:35 AM, Mike wrote: > > I'd like to thank everyone for their kind responses. One person who > responded off list and bothered to look at the returned certificates > pointed out, and correctly it seems, that my original setup was missing an > intermediate certificate. The site was returning 'valid ssl' and all > browsers got the green lock and offsite ssl tests came back ok, but > apparently the missing intermediate means it would have had to have been > fetched and that was the part that was failing at the customer site. Once I > put the intermediate certificate in there, the customer site was able to > access https without fail. I have not had an opportunity yet to examine in > detail the config of the meraki router there but it's either a routing > problem or a DPI problem. If I get an answer I'll post again with my > results. > > Thanks all. > > Mike- > > From mike-nanog at tiedyenetworks.com Fri Mar 27 16:34:24 2015 From: mike-nanog at tiedyenetworks.com (Mike) Date: Fri, 27 Mar 2015 09:34:24 -0700 Subject: FIXED - Re: Broken SSL cert caused by router? In-Reply-To: References: <55148A7F.5020209@tiedyenetworks.com> <37237.77.1427428575578.JavaMail.mtlewis@T410I> <551578D1.8080903@tiedyenetworks.com> Message-ID: <55158690.8020500@tiedyenetworks.com> On 03/27/2015 08:43 AM, Josh Luthman wrote: > FFR you can use this to verify the site itself is good or not: > > https://www.sslshopper.com/ssl-checker.html (there are others, this is > just what I have bookmarked) > Thanks. Previously while diagnosing this however, I used some others similar and they all were saying I was ok. For example, https://www.ssllabs.com/ssltest/analyze.html and one other I forget now. I am surprised this problem was not being pointed out. From ml at kenweb.org Fri Mar 27 16:52:21 2015 From: ml at kenweb.org (ML) Date: Fri, 27 Mar 2015 12:52:21 -0400 Subject: FIXED - Re: Broken SSL cert caused by router? In-Reply-To: <55158690.8020500@tiedyenetworks.com> References: <55148A7F.5020209@tiedyenetworks.com> <37237.77.1427428575578.JavaMail.mtlewis@T410I> <551578D1.8080903@tiedyenetworks.com> <55158690.8020500@tiedyenetworks.com> Message-ID: <55158AC5.9020308@kenweb.org> I believe the SSLLabs Analyzer should have pointed out an "Extra Download" in the cert chain. That was the hint that there was an intermediate cert that a client would have to go find on it's own because it wasn't included with your server cert. https://community.qualys.com/thread/12831 On 3/27/2015 12:34 PM, Mike wrote: > > > On 03/27/2015 08:43 AM, Josh Luthman wrote: >> FFR you can use this to verify the site itself is good or not: >> >> https://www.sslshopper.com/ssl-checker.html (there are others, this >> is just what I have bookmarked) >> > > Thanks. Previously while diagnosing this however, I used some others > similar and they all were saying I was ok. For example, > https://www.ssllabs.com/ssltest/analyze.html and one other I forget > now. I am surprised this problem was not being pointed out. > > > From josh at imaginenetworksllc.com Fri Mar 27 16:53:23 2015 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Fri, 27 Mar 2015 12:53:23 -0400 Subject: FIXED - Re: Broken SSL cert caused by router? In-Reply-To: <55158690.8020500@tiedyenetworks.com> References: <55148A7F.5020209@tiedyenetworks.com> <37237.77.1427428575578.JavaMail.mtlewis@T410I> <551578D1.8080903@tiedyenetworks.com> <55158690.8020500@tiedyenetworks.com> Message-ID: When I had the same mistake as you, that toll identified it. That's why I mentioned that one :) Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mar 27, 2015 12:34 PM, "Mike" wrote: > > > On 03/27/2015 08:43 AM, Josh Luthman wrote: > >> FFR you can use this to verify the site itself is good or not: >> >> https://www.sslshopper.com/ssl-checker.html (there are others, this is >> just what I have bookmarked) >> >> > Thanks. Previously while diagnosing this however, I used some others > similar and they all were saying I was ok. For example, > https://www.ssllabs.com/ssltest/analyze.html and one other I forget now. > I am surprised this problem was not being pointed out. > > > > From adrian at olddog.co.uk Fri Mar 27 17:14:09 2015 From: adrian at olddog.co.uk (Adrian Farrel) Date: Fri, 27 Mar 2015 17:14:09 -0000 Subject: draft-ietf-mpls-ldp-ipv6-16 In-Reply-To: <54EA01F0.1060505@foobar.org> References: <54EA01F0.1060505@foobar.org> Message-ID: <067b01d068b1$719a44a0$54cecde0$@olddog.co.uk> FWIW, draft-ietf-mpls-ldp-ipv6 [1] is now at revision 17. But it is complete and totally stable. It was approved for publication as an RFC on March 4th and the document is currently with the RFC Editor in the "final stages of sausage grinding" I would predict that you will have an RFC number to reference within about 4 weeks from now. Adrian [1] https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Nick Hilliard > Sent: 22 February 2015 16:21 > To: nanog at nanog.org > Subject: Re: draft-ietf-mpls-ldp-ipv6-16 > > On 21/02/2015 14:28, Rogers, Josh wrote: > > RFC7349 is a nice summary of everything we¹re still missing wrt MPLS and > > is relatively recent so should be close to up to date. In addition to the > > MPLS shortcomings, it also touches on recent IGP updates: > > rfc7439, not 7349: > > https://tools.ietf.org/html/rfc7439 > > Nick > > > > >> 3.2.3.1. Interior Gateway Protocol (IGP) > >> > >> RFC 3630 [RFC3630] specifies a method of adding traffic engineering > >> capabilities to OSPF Version 2. New TLVs and sub-TLVs were added in > >> RFC 5329 [RFC5329] to extend TE capabilities to IPv6 networks in OSPF > >> Version 3. > >> > >> RFC 5305 [RFC5305] specifies a method of adding traffic engineering > >> capabilities to IS-IS. New TLVs and sub-TLVs were added in RFC 6119 > >> [RFC6119] to extend TE capabilities to IPv6 networks. > >> > >> Gap: None. > > > > When you talk to your vendor, ask what code will support these RFC¹s. > > > > > > -Josh > > > > > > > >> On 2/21/15, 6:00 AM, "nanog-request at nanog.org" request at nanog.org> > >> wrote: > >> > >>> ---------------------------------------------------------------------- > >>> > >>> Message: 1 > >>> Date: Fri, 20 Feb 2015 09:00:07 -0500 > >>> From: Tim Durack > >>> To: Saku Ytti > >>> Cc: "nanog at nanog.org" , Juniper-Nsp > >>> , "cisco-nsp at puck.nether.net" > >>> > >>> Subject: Re: draft-ietf-mpls-ldp-ipv6-16 > >>> Message-ID: > >>> > com> > >>> Content-Type: text/plain; charset=UTF-8 > >>> > >>> On Fri, Feb 20, 2015 at 6:39 AM, Saku Ytti wrote: > >>> > >>>> On (2015-02-19 11:06 -0500), Tim Durack wrote: > >>>> > >>>>> What is the chance of getting working code this decade? I would quite > >>>> like > >>>>> to play with this new fangled IPv6 widget... > >>>>> > >>>>> (Okay, I'd like to stop using IPv4 for infrastructure. LDP is the last > >>>>> piece for me.) > >>>> > >>>> Is there 4PE implementation to drive IPv4 edges, shouldn't be hard to > >>>> accept > >>>> IPv6 next-hop in BGP LU, but probably does not work out-of-the-box? > >>>> Isn't Segment Routing implementation day1 IPV4+IPV6 in XR? > >>>> > >>>> -- > >>>> ++ytti > >>>> > >>> > >>> I would gladly take OSPFv2/OSPFv3/ISIS+SR over LDP, but I'm seeing that > >>> is > >>> not all that is needed. > >>> > >>> I also need some flavor of L2VPN (eVPN) and L3VPN (VPNv4/VPNv6) > working > >>> over IPv6. > >>> > >>> IPv6 control plane this decade may yet be optimistic. > >>> > >>> -- > >>> Tim:> > >>> > >> > > > > > > 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 frnkblk at iname.com Fri Mar 27 17:34:16 2015 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 27 Mar 2015 12:34:16 -0500 Subject: FIXED - Re: Broken SSL cert caused by router? In-Reply-To: <551578D1.8080903@tiedyenetworks.com> References: <55148A7F.5020209@tiedyenetworks.com> <37237.77.1427428575578.JavaMail.mtlewis@T410I> <551578D1.8080903@tiedyenetworks.com> Message-ID: <002701d068b4$3f6bdd60$be439820$@iname.com> Glad you figured that out. I've used three SSL evaluation websites to help me with intermediate certificate issues: https://www.ssllabs.com/ssltest/analyze.html (will show the names and details of the certs, missing or not https://www.wormly.com/test_ssl (quick SSL tester, will point out if intermediate certificate is missing) https://www.digicert.com/help/ (will show a green chain link between certs when they're all there *and* in order) Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Sent: Friday, March 27, 2015 10:36 AM Cc: nanog at nanog.org Subject: FIXED - Re: Broken SSL cert caused by router? I'd like to thank everyone for their kind responses. One person who responded off list and bothered to look at the returned certificates pointed out, and correctly it seems, that my original setup was missing an intermediate certificate. The site was returning 'valid ssl' and all browsers got the green lock and offsite ssl tests came back ok, but apparently the missing intermediate means it would have had to have been fetched and that was the part that was failing at the customer site. Once I put the intermediate certificate in there, the customer site was able to access https without fail. I have not had an opportunity yet to examine in detail the config of the meraki router there but it's either a routing problem or a DPI problem. If I get an answer I'll post again with my results. Thanks all. Mike- From cscora at apnic.net Fri Mar 27 18:13:01 2015 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Mar 2015 04:13:01 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <201503271813.t2RID1AF024888@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, 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 28 Mar, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 539583 Prefixes after maximum aggregation (per Origin AS): 205817 Deaggregation factor: 2.62 Unique aggregates announced (without unneeded subnets): 262661 Total ASes present in the Internet Routing Table: 49834 Prefixes per ASN: 10.83 Origin-only ASes present in the Internet Routing Table: 36546 Origin ASes announcing only one prefix: 16280 Transit ASes present in the Internet Routing Table: 6292 Transit-only ASes present in the Internet Routing Table: 172 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 59 Max AS path prepend of ASN ( 55644) 56 Prefixes from unregistered ASNs in the Routing Table: 1158 Unregistered ASNs in the Routing Table: 415 Number of 32-bit ASNs allocated by the RIRs: 9001 Number of 32-bit ASNs visible in the Routing Table: 6996 Prefixes from 32-bit ASNs in the Routing Table: 25268 Number of bogon 32-bit ASNs visible in the Routing Table: 4 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 361 Number of addresses announced to Internet: 2737519268 Equivalent to 163 /8s, 43 /16s and 58 /24s Percentage of available address space announced: 73.9 Percentage of allocated address space announced: 73.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.3 Total number of prefixes smaller than registry allocations: 182122 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 132907 Total APNIC prefixes after maximum aggregation: 38646 APNIC Deaggregation factor: 3.44 Prefixes being announced from the APNIC address blocks: 138626 Unique aggregates announced from the APNIC address blocks: 56513 APNIC Region origin ASes present in the Internet Routing Table: 5030 APNIC Prefixes per ASN: 27.56 APNIC Region origin ASes announcing only one prefix: 1211 APNIC Region transit ASes present in the Internet Routing Table: 882 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 59 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1362 Number of APNIC addresses announced to Internet: 747670784 Equivalent to 44 /8s, 144 /16s and 141 /24s Percentage of available APNIC address space announced: 87.4 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-64098, 131072-135580 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: 178044 Total ARIN prefixes after maximum aggregation: 87849 ARIN Deaggregation factor: 2.03 Prefixes being announced from the ARIN address blocks: 180012 Unique aggregates announced from the ARIN address blocks: 84168 ARIN Region origin ASes present in the Internet Routing Table: 16527 ARIN Prefixes per ASN: 10.89 ARIN Region origin ASes announcing only one prefix: 6081 ARIN Region transit ASes present in the Internet Routing Table: 1707 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 381 Number of ARIN addresses announced to Internet: 1062623008 Equivalent to 63 /8s, 86 /16s and 87 /24s Percentage of available ARIN address space announced: 56.2 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: 130363 Total RIPE prefixes after maximum aggregation: 65087 RIPE Deaggregation factor: 2.00 Prefixes being announced from the RIPE address blocks: 136856 Unique aggregates announced from the RIPE address blocks: 84369 RIPE Region origin ASes present in the Internet Routing Table: 17922 RIPE Prefixes per ASN: 7.64 RIPE Region origin ASes announcing only one prefix: 8164 RIPE Region transit ASes present in the Internet Routing Table: 2965 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 3554 Number of RIPE addresses announced to Internet: 694483588 Equivalent to 41 /8s, 100 /16s and 250 /24s Percentage of available RIPE address space announced: 101.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 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: 60045 Total LACNIC prefixes after maximum aggregation: 11190 LACNIC Deaggregation factor: 5.37 Prefixes being announced from the LACNIC address blocks: 69828 Unique aggregates announced from the LACNIC address blocks: 32119 LACNIC Region origin ASes present in the Internet Routing Table: 2422 LACNIC Prefixes per ASN: 28.83 LACNIC Region origin ASes announcing only one prefix: 624 LACNIC Region transit ASes present in the Internet Routing Table: 497 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1593 Number of LACNIC addresses announced to Internet: 168156416 Equivalent to 10 /8s, 5 /16s and 221 /24s Percentage of available LACNIC address space announced: 100.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-265628 + 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: 12772 Total AfriNIC prefixes after maximum aggregation: 3001 AfriNIC Deaggregation factor: 4.26 Prefixes being announced from the AfriNIC address blocks: 13900 Unique aggregates announced from the AfriNIC address blocks: 5166 AfriNIC Region origin ASes present in the Internet Routing Table: 735 AfriNIC Prefixes per ASN: 18.91 AfriNIC Region origin ASes announcing only one prefix: 200 AfriNIC Region transit ASes present in the Internet Routing Table: 157 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 106 Number of AfriNIC addresses announced to Internet: 64134656 Equivalent to 3 /8s, 210 /16s and 158 /24s Percentage of available AfriNIC address space announced: 63.7 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 2865 11553 913 Korea Telecom 17974 2795 904 78 PT Telekomunikasi Indonesia 7545 2549 336 128 TPG Telecom Limited 4755 1999 422 212 TATA Communications formerly 4538 1757 4190 71 China Education and Research 9829 1683 1324 35 National Internet Backbone 9808 1553 8717 28 Guangdong Mobile Communicatio 4808 1486 2255 440 CNCGROUP IP network China169 9583 1405 116 574 Sify Limited 9498 1312 334 94 BHARTI Airtel Ltd. 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 3016 2956 142 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 3356 2548 10683 476 Level 3 Communications, Inc. 18566 2041 379 183 MegaPath Corporation 20115 1849 1832 429 Charter Communications 6983 1705 866 245 EarthLink, Inc. 4323 1620 1021 409 tw telecom holdings, inc. 30036 1528 312 503 Mediacom Communications Corp 701 1388 11270 676 MCI Communications Services, 22561 1337 412 242 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 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 34984 1980 303 361 TELLCOM ILETISIM HIZMETLERI A 20940 1663 640 1232 Akamai International B.V. 8402 1333 544 15 OJSC "Vimpelcom" 6849 1212 356 24 JSC "Ukrtelecom" 31148 1046 45 21 Freenet Ltd. 13188 1024 96 72 TOV "Bank-Inform" 8551 894 373 48 Bezeq International-Ltd 12479 891 801 79 France Telecom Espana SA 9198 857 349 25 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 10620 3153 514 209 Telmex Colombia S.A. 28573 2389 2173 118 NET Servi�os de Comunica��o S 7303 1752 1150 237 Telecom Argentina S.A. 8151 1557 3152 451 Uninet S.A. de C.V. 28024 1527 105 8 Nuevatel PCS de Bolivia S.A. 6503 1209 421 57 Axtel, S.A.B. de C.V. 6147 1044 374 30 Telefonica del Peru S.A.A. 7738 1001 1882 42 Telemar Norte Leste S.A. 26615 972 2325 35 Tim Celular S.A. 3816 921 414 153 COLOMBIA TELECOMUNICACIONES S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1683 958 13 TE-AS 24863 956 284 27 Link Egypt (Link.NET) 36903 479 241 90 Office National des Postes et 36992 417 1101 32 ETISALAT MISR 37492 317 159 70 Orange Tunisie 24835 299 144 9 Vodafone Data 3741 249 857 208 Internet Solutions 29571 232 21 13 Cote d'Ivoire Telecom 36947 189 807 13 Telecom Algeria 15706 172 32 6 Sudatel (Sudan Telecom Co. Lt 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 10620 3153 514 209 Telmex Colombia S.A. 22773 3016 2956 142 Cox Communications Inc. 6389 2891 3688 51 BellSouth.net Inc. 4766 2865 11553 913 Korea Telecom 17974 2795 904 78 PT Telekomunikasi Indonesia 7545 2549 336 128 TPG Telecom Limited 3356 2548 10683 476 Level 3 Communications, Inc. 39891 2472 128 6 SaudiNet, Saudi Telecom Compa 28573 2389 2173 118 NET Servi�os de Comunica��o S 18566 2041 379 183 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 22773 3016 2874 Cox Communications Inc. 6389 2891 2840 BellSouth.net Inc. 17974 2795 2717 PT Telekomunikasi Indonesia 39891 2472 2466 SaudiNet, Saudi Telecom Compa 7545 2549 2421 TPG Telecom Limited 28573 2389 2271 NET Servi�os de Comunica��o S 3356 2548 2072 Level 3 Communications, Inc. 4766 2865 1952 Korea Telecom 18566 2041 1858 MegaPath Corporation 4755 1999 1787 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 3356 Level 3 Communicatio 46467 UNALLOCATED 8.19.192.0/24 46887 Lightower Fiber Netw 18985 UNALLOCATED 8.21.68.0/22 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 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 32805 UNALLOCATED 12.1.225.0/24 7018 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.100.241.0/24 23456 32bit Transition AS 23.226.112.0/20 62788 Bitfinite LLC 27.100.7.0/24 56096 >>UNKNOWN<< 31.217.248.0/21 44902 COVAGE NETWORKS SASU 41.73.1.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.15.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:12 /10:34 /11:92 /12:264 /13:508 /14:998 /15:1719 /16:12962 /17:7200 /18:12232 /19:25237 /20:35823 /21:38575 /22:58422 /23:50965 /24:291542 /25:1108 /26:1171 /27:657 /28:14 /29:11 /30:8 /31:0 /32:13 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 39891 2432 2472 SaudiNet, Saudi Telecom Compa 22773 2228 3016 Cox Communications Inc. 18566 1996 2041 MegaPath Corporation 6389 1671 2891 BellSouth.net Inc. 30036 1374 1528 Mediacom Communications Corp 6983 1352 1705 EarthLink, Inc. 34984 1285 1980 TELLCOM ILETISIM HIZMETLERI A 10620 1112 3153 Telmex Colombia S.A. 11492 1101 1164 CABLE ONE, INC. 22561 1012 1337 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1534 2:650 3:1 4:94 5:1760 6:21 8:1441 12:1828 13:4 14:1316 15:17 16:2 17:45 18:21 20:49 23:1203 24:1686 27:1856 31:1521 32:39 33:2 34:5 35:3 36:119 37:1884 38:1013 39:10 40:245 41:3024 42:264 43:1235 44:26 45:316 46:2138 47:36 49:881 50:800 52:12 54:69 55:4 56:8 57:37 58:1220 59:685 60:466 61:1769 62:1319 63:1911 64:4439 65:2262 66:4114 67:2048 68:1077 69:3263 70:956 71:441 72:1957 74:2653 75:321 76:406 77:1517 78:1270 79:807 80:1315 81:1352 82:818 83:678 84:678 85:1367 86:384 87:1069 88:516 89:1772 90:151 91:5945 92:823 93:2178 94:1971 95:2079 96:428 97:344 98:1071 99:47 100:68 101:809 103:7049 104:1464 105:62 106:225 107:914 108:616 109:1992 110:1079 111:1481 112:769 113:1057 114:837 115:1245 116:1364 117:1014 118:1696 119:1436 120:443 121:1040 122:2186 123:1734 124:1505 125:1579 128:624 129:377 130:383 131:1149 132:478 133:167 134:416 135:113 136:306 137:308 138:552 139:163 140:221 141:422 142:666 143:461 144:563 145:108 146:710 147:592 148:1118 149:461 150:556 151:605 152:493 153:240 154:378 155:737 156:410 157:333 158:314 159:980 160:374 161:1159 162:1950 163:415 164:659 165:685 166:286 167:802 168:1271 169:157 170:1464 171:238 172:41 173:1538 174:701 175:664 176:1430 177:3773 178:2050 179:1379 180:1924 181:1772 182:1738 183:615 184:738 185:3172 186:2760 187:1792 188:2007 189:1568 190:7415 191:969 192:8192 193:5600 194:4094 195:3658 196:1732 197:1075 198:5498 199:5516 200:6529 201:2990 202:9494 203:9078 204:4708 205:2819 206:3070 207:3009 208:3945 209:3930 210:3519 211:1865 212:2466 213:2274 214:855 215:70 216:5587 217:1808 218:675 219:451 220:1432 221:790 222:466 223:667 End of report From rps at maine.edu Fri Mar 27 19:36:12 2015 From: rps at maine.edu (Ray Soucy) Date: Fri, 27 Mar 2015 15:36:12 -0400 Subject: Broken SSL cert caused by router? In-Reply-To: <37237.77.1427428575578.JavaMail.mtlewis@T410I> References: <55148A7F.5020209@tiedyenetworks.com> <37237.77.1427428575578.JavaMail.mtlewis@T410I> Message-ID: It might be filtering the CRL or OCSP verification for the SSL certificate. For GoDaddy I think this would be: http://crl.godaddy.com/ http://ocsp.godaddy.com/ http://certificates.godaddy.com/ We ran into this when OS X changed how it handles SSL a few years back, our captive portal was presenting a splash page in place of Thawte OCSP and crashing the SSL keychain process. The work-around was either to respond with a TCP RST for these requests or to allow them through. On Thu, Mar 26, 2015 at 11:57 PM, Lewis,Mitchell T. wrote: > Meraki Access Points are interesting devices. > > I have found they cause issues with Linux firewalls if the merakis are not configured "correctly". > > Meraki Access Points do content inspections which I have found can cause produce symptoms similar to yours, although I have not experienced what you are describing. Since the MX64W is both an Access Point & security gateway, it has some additional content inspection/intelligence for it's security appliance role on top of the functions it performs as an access point, the same functions which are found in Meraki standalone access points as well. > > I am not sure what the specifics are as I do not use Meraki security appliances but it is worth checking. I have found with Meraki that items in the control panel/dashboard are not always labeled the best so I have found it is usually worth putting in a ticket with them and/or a call to them to see what they think (1-888-490-0918). > > > > > > > > > > > > Mitchell T. Lewis > Mlewis at Techcompute.Net > : www.linkedin.com/in/mlewiscc > Mobile: (203)816-0371 > PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E Public PGP Key > > > > > A computer will do what you tell it to do, but that may be much different from what you had in mind. ~Joseph Weizenbaum > > ----- Original Message ----- > > From: "Mike" > To: nanog at nanog.org > Sent: Thursday, March 26, 2015 6:38:55 PM > Subject: Broken SSL cert caused by router? > > Hi, > > I have a very odd problem. > > We've recently gotten a 'real' ssl certificate from godaddy to > cover our domain (*.domain.com) and have installed it in several places > where needed for email (imap/starttls and etc) and web. This works > great, seems ok according to various online TLS certificate checkers, > and I get the green lock when testing using my own browsers and such. > > I have a customer however that uses our web mail system now secured > with ssl. I myself and many others use it and get the green lock. But, > whenever any station at the customer tries using it, they get a broken > lock and 'your connection is not private'. The actual error displayed > below is 'cert_authority_invalid' and it's "Go Daddy Secure Certificate > Authority - G2". And it gets worse - whenever I go to the location and > use my own laptop, the very one that 'works' when at my office, I ALSO > get the error. AND EVEN WORSE - when I connect to my cell phone provided > hotspot, the error goes away! > > As weird as this all sounds, I got it nailed down to one device - > they have a Cisco/Meraki MX64W as their internet gateway - and when I > remove that device from the chain and go 'straight' out to the internet, > suddenly, the certificate problem goes away entirely. > > How is this possible? Can anyone comment on these devices and tell > me what might be going on here? > > Mike- > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From hannigan at gmail.com Fri Mar 27 20:07:23 2015 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 27 Mar 2015 16:07:23 -0400 Subject: Google served from non-google IPs? In-Reply-To: <86FE96C5-C39F-42DE-957E-74BE38B2DAB8@lixfeld.ca> References: <86FE96C5-C39F-42DE-957E-74BE38B2DAB8@lixfeld.ca> Message-ID: Hi Jason, This is not commonplace. That prefix is from a specially designated IXP micro allocation block. See http://bit.ly/1OEcHde for detail. The use of these specially designated blocks is for IXPs only. We (Akamai) don't have equipment numbered into this type of address space nor do we have any evidence that we have in the past. We certainly won't in the future. If someone knows of anything that we missed, contact me directly and we'll arrange to renumber. Hope that helps. Best, -M< On Thu, Mar 12, 2015 at 3:58 PM, Jason Lixfeld wrote: > So today, I saw this: > > BlackBox:~ jlixfeld$ host google.ca 8.8.8.8 > Using domain server: > Name: 8.8.8.8 > Address: 8.8.8.8#53 > Aliases: > > google.ca has address 206.126.112.166 > google.ca has address 206.126.112.177 > google.ca has address 206.126.112.172 > google.ca has address 206.126.112.187 > google.ca has address 206.126.112.151 > google.ca has address 206.126.112.158 > google.ca has address 206.126.112.157 > google.ca has address 206.126.112.173 > google.ca has address 206.126.112.181 > google.ca has address 206.126.112.155 > google.ca has address 206.126.112.147 > google.ca has address 206.126.112.185 > google.ca has address 206.126.112.143 > google.ca has address 206.126.112.170 > google.ca has address 206.126.112.162 > google.ca has IPv6 address 2607:f8b0:4006:808::100f > google.ca mail is handled by 50 alt4.aspmx.l.google.com. > google.ca mail is handled by 30 alt2.aspmx.l.google.com. > google.ca mail is handled by 20 alt1.aspmx.l.google.com. > google.ca mail is handled by 10 aspmx.l.google.com. > google.ca mail is handled by 40 alt3.aspmx.l.google.com. > BlackBox:~ jlixfeld$ > > That is not Google IPv4 address space, and those IPv4 IPs are not being > announced by 15169. > > Am I dumb in thinking that this is weird or is this sort of thing > commonplace? From nanog at ics-il.net Fri Mar 27 20:40:50 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 27 Mar 2015 15:40:50 -0500 (CDT) Subject: Denver In-Reply-To: <13756387.5817.1427488452113.JavaMail.mhammett@ThunderFuck> Message-ID: <24883573.5831.1427488857941.JavaMail.mhammett@ThunderFuck> So in Denver Comfluent\CoreSite seems to be the place to be... except as someone that predominately serves eyeball networks, I'm interested in NetFlix. NetFlix is in EdgeConneX... where no other significant peering is happening. Also, my partner who has been looking into the Denver market said that CoreSite costs more than Chicago Equinix. Any recommendations for where to go? Seems like both main options suck, but there aren't any better. This would be for eyeball networks getting peering with the big content guys and cheaper transit than the tier 4\5\6\7\8 (how small of markets get numbers?) where they're located. Any significant web hosting operations in the Denver market? Someone that's bigger than "Bob's DS3 Web Hosting", but not SoftLayer size where they can't get creative with their services. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com From vwittkop at nanog.org Fri Mar 27 21:08:00 2015 From: vwittkop at nanog.org (Valerie Wittkop) Date: Fri, 27 Mar 2015 17:08:00 -0400 Subject: [NANOG-announce] NANOG On The Road Comes to Boston!! Message-ID: <02E4F357-E487-43D2-95CE-8667D0758FED@nanog.org> We are very excited to be holding the next NOTR event in the great city of Boston and we invite you to join us! Are you interested in Internet networking/peering? Do you work at a colocation, hosting or data center facility? Are you a provider of hardware/software solutions for the Internet industry? If so, the NANOG On The Road NANOG On The Road Boston event is perfect for you! Date: April 21, 2015 Time: 9:00 AM - 5:00 PM Location: Courtyard Boston Cambridge Hotel The FREE to attend event is open for registration. Register Now! The agenda is posted - topics to be discussed include: - Keynote Presentation by Scott Bradner - Updates on Boston IX and R&E Interconnection - DNSSEC & RPKI - QUIC - Optical Networking Tutorial - IPv6 Tutorial - Data Center Track - BGP Tutorial If you are, or will be, in the Boston area, we invite you to attend. And don’t forget to share the invitation with your colleagues or others you feel may benefit from attending. Make NANOG On The Road your first step toward learning how you can take the wheel and steer the future of the Internet. Learn more about On The Road events here . Feel free to contact us at nanog-support at nanog.org if you have any questions. Regards, Valerie Valerie Wittkop NANOG Program 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 nanog at ics-il.net Fri Mar 27 21:21:53 2015 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 27 Mar 2015 16:21:53 -0500 (CDT) Subject: Denver In-Reply-To: Message-ID: <25106768.6069.1427491312800.JavaMail.mhammett@ThunderFuck> Right, that's how I saw that NetFlix wasn't in Coresite by using CoreSite's Any2 member list... however accurate it is. (I did check peeringdb as well.) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Reid Fishler" To: "Mike Hammett" Cc: "NANOG" Sent: Friday, March 27, 2015 4:15:45 PM Subject: Re: Denver Just to add a note, at Coresite there is the RMIX exchange, which now is an Any2...but its a fairly nice exchange. Reid On Fri, Mar 27, 2015 at 4:40 PM, Mike Hammett < nanog at ics-il.net > wrote: So in Denver Comfluent\CoreSite seems to be the place to be... except as someone that predominately serves eyeball networks, I'm interested in NetFlix. NetFlix is in EdgeConneX... where no other significant peering is happening. Also, my partner who has been looking into the Denver market said that CoreSite costs more than Chicago Equinix. Any recommendations for where to go? Seems like both main options suck, but there aren't any better. This would be for eyeball networks getting peering with the big content guys and cheaper transit than the tier 4\5\6\7\8 (how small of markets get numbers?) where they're located. Any significant web hosting operations in the Denver market? Someone that's bigger than "Bob's DS3 Web Hosting", but not SoftLayer size where they can't get creative with their services. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com -- Reid Fishler Director Hurricane Electric +1-510-580-4178 From cidr-report at potaroo.net Fri Mar 27 22:00:00 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Mar 2015 22:00:00 GMT Subject: The Cidr Report Message-ID: <201503272200.t2RM00T0086511@wattle.apnic.net> This report has been generated at Fri Mar 27 21:14:39 2015 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 20-03-15 544650 297738 21-03-15 544456 298114 22-03-15 544479 298583 23-03-15 545351 298755 24-03-15 545533 298722 25-03-15 545653 298852 26-03-15 545243 299436 27-03-15 545205 299145 AS Summary 50078 Number of ASes in routing system 20014 Number of ASes announcing only one prefix 3153 Largest number of prefixes announced by an AS AS10620: Telmex Colombia S.A.,CO 120880640 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'). --- 27Mar15 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 546649 299157 247492 45.3% All ASes AS22773 3017 171 2846 94.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS6389 2890 73 2817 97.5% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2795 78 2717 97.2% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS39891 2473 24 2449 99.0% ALJAWWALSTC-AS Saudi Telecom Company JSC,SA AS28573 2390 312 2078 86.9% NET Servi�os de Comunica��o S.A.,BR AS4755 1997 265 1732 86.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS4766 2866 1317 1549 54.0% KIXS-AS-KR Korea Telecom,KR AS28024 1527 24 1503 98.4% Nuevatel PCS de Bolivia S.A.,BO AS9808 1553 67 1486 95.7% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS7303 1752 287 1465 83.6% Telecom Argentina S.A.,AR AS6983 1703 248 1455 85.4% ITCDELTA - Earthlink, Inc.,US AS10620 3153 1792 1361 43.2% Telmex Colombia S.A.,CO AS20115 1850 500 1350 73.0% CHARTER-NET-HKY-NC - Charter Communications,US AS8402 1321 25 1296 98.1% CORBINA-AS OJSC "Vimpelcom",RU AS4323 1627 411 1216 74.7% TWTC - tw telecom holdings, inc.,US AS9498 1312 111 1201 91.5% BBIL-AP BHARTI Airtel Ltd.,IN AS18566 2040 869 1171 57.4% MEGAPATH5-US - MegaPath Corporation,US AS7545 2567 1410 1157 45.1% TPG-INTERNET-AP TPG Telecom Limited,AU AS34984 1981 894 1087 54.9% TELLCOM-AS TELLCOM ILETISIM HIZMETLERI A.S.,TR AS22561 1338 259 1079 80.6% CENTURYLINK-LEGACY-LIGHTCORE - CenturyTel Internet Holdings, Inc.,US AS7552 1123 61 1062 94.6% VIETEL-AS-AP Viettel Corporation,VN AS3356 2552 1491 1061 41.6% LEVEL3 - Level 3 Communications, Inc.,US AS6849 1209 171 1038 85.9% UKRTELNET JSC UKRTELECOM,UA AS6147 1043 90 953 91.4% Telefonica del Peru S.A.A.,PE AS8151 1562 619 943 60.4% Uninet S.A. de C.V.,MX AS7738 1000 84 916 91.6% Telemar Norte Leste S.A.,BR AS38285 983 115 868 88.3% M2TELECOMMUNICATIONS-AU M2 Telecommunications Group Ltd,AU AS18881 867 23 844 97.3% Global Village Telecom,BR AS4538 1775 953 822 46.3% ERX-CERNET-BKB China Education and Research Network Center,CN AS26615 972 150 822 84.6% Tim Celular S.A.,BR Total 55238 12894 42344 76.7% Top 30 total Possible Bogus Routes 5.100.241.0/24 AS19957 -Reserved AS-,ZZ 23.226.112.0/20 AS62788 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 31.217.248.0/21 AS44902 COV-ASN COVAGE NETWORKS SASU,FR 41.73.1.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.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.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 41.242.152.0/22 AS37558 LITC,LY 41.242.156.0/22 AS37558 LITC,LY 64.25.16.0/23 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.20.0/24 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.21.0/24 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.22.0/24 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.24.0/23 AS19535 AS19535 - JetBlue Airways Corporation,US 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.25.28.0/23 AS19535 AS19535 - JetBlue Airways Corporation,US 64.44.0.0/16 AS46879 -Reserved AS-,ZZ 64.112.0.0/17 AS46879 -Reserved AS-,ZZ 64.112.128.0/18 AS46879 -Reserved AS-,ZZ 64.140.128.0/18 AS7385 INTEGRATELECOM - Integra Telecom, 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.78.66.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.68.0/22 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.76.0/23 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.80.0/21 AS10835 VISIONARY - Visionary Communications, Inc.,US 66.78.91.0/24 AS10835 VISIONARY - Visionary Communications, Inc.,US 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 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 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.114.184.0/22 AS19888 -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.91.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 83.142.48.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 83.142.49.0/24 AS13213 UK2NET-AS UK2 - Ltd,GB 91.103.8.0/24 AS42551 -Reserved AS-,ZZ 91.103.9.0/24 AS42551 -Reserved AS-,ZZ 91.103.10.0/24 AS42551 -Reserved AS-,ZZ 91.103.11.0/24 AS42551 -Reserved AS-,ZZ 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.230.27.0/24 AS57022 -Reserved AS-,ZZ 98.143.160.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.161.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.162.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.163.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.164.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.165.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.166.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.167.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.168.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.172.0/22 AS26566 -Reserved AS-,ZZ 98.143.172.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.173.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.174.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 98.143.175.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 102.69.1.0/24 AS59749 CLEANMAT CLEANMAT EOOD,BG 103.10.222.0/24 AS13189 103.15.92.0/22 AS23818 JETINTERNET JETINTERNET 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.20.219.0/24 AS55795 VERBDC1-AS-AP Verb Data Centre Pty Ltd,AU 103.23.148.0/23 AS13209 103.23.148.0/24 AS13209 103.23.149.0/24 AS13209 103.26.116.0/22 AS17676 GIGAINFRA Softbank BB Corp.,JP 103.28.184.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC.,JP 103.224.0.0/22 AS18097 DCN D.C.N. Corporation,JP 103.244.112.0/22 AS23818 JETINTERNET JETINTERNET Corporation,JP 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 103.253.164.0/23 AS13317 103.255.56.0/22 AS18097 DCN D.C.N. Corporation,JP 103.255.132.0/22 AS18097 DCN D.C.N. Corporation,JP 111.92.184.0/22 AS9797 NEXONASIAPACIFIC-AS-AP Nexon Asia Pacific P/L,AU 113.197.106.0/24 AS15169 GOOGLE - Google Inc.,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.54.184.0/21 AS59092 KRONOS kronos.Co.,Ltd.,JP 142.147.62.0/24 AS3958 AIRCANADA - Air Canada,CA 154.168.28.0/23 AS29571 CITelecom-AS,CI 162.216.176.0/22 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.222.128.0/21 AS36114 VERSAWEB-ASN - Versaweb, LLC,US 162.245.64.0/21 AS62788 -Reserved AS-,ZZ 162.248.224.0/21 AS62788 -Reserved AS-,ZZ 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 167.146.16.0/21 AS22527 -Reserved AS-,ZZ 167.146.26.0/23 AS22527 -Reserved AS-,ZZ 167.146.28.0/23 AS22527 -Reserved AS-,ZZ 167.146.32.0/20 AS22527 -Reserved AS-,ZZ 167.146.44.0/24 AS22527 -Reserved AS-,ZZ 167.146.48.0/22 AS22527 -Reserved AS-,ZZ 167.146.90.0/24 AS22527 -Reserved AS-,ZZ 167.146.93.0/24 AS22527 -Reserved AS-,ZZ 167.146.94.0/24 AS22527 -Reserved AS-,ZZ 167.146.100.0/24 AS22527 -Reserved AS-,ZZ 167.146.104.0/24 AS22527 -Reserved AS-,ZZ 167.146.105.0/24 AS22527 -Reserved AS-,ZZ 167.146.128.0/20 AS22527 -Reserved AS-,ZZ 167.146.137.0/24 AS22527 -Reserved AS-,ZZ 167.146.144.0/20 AS22527 -Reserved AS-,ZZ 167.146.160.0/20 AS22527 -Reserved AS-,ZZ 167.146.200.0/22 AS22527 -Reserved AS-,ZZ 167.146.204.0/24 AS22527 -Reserved AS-,ZZ 167.146.205.0/24 AS22527 -Reserved AS-,ZZ 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 173.45.192.0/20 AS62722 -Reserved AS-,ZZ 173.45.208.0/20 AS62722 -Reserved AS-,ZZ 185.17.96.0/24 AS51088 A2B A2B IP B.V.,NL 185.17.98.0/23 AS19798 HILF-AS Hilf Telecom B.V.,NL 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,FR 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 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.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.32.23.0/24 AS2856 BT-UK-AS BT Public Internet Service,GB 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.35.101.0/24 AS57302 -Reserved AS-,ZZ 193.46.200.0/24 AS34243 WEBAGE Web Age 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.176.147.0/24 AS49951 -Reserved AS-,ZZ 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.188.252.0/24 AS38968 TAGORG Abu-Ghazaleh Intellectual Property,JO 193.200.96.0/23 AS2828 XO-AS15 - XO Communications,US 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.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS8437 UTA-AS 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.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.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.61.147.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.150.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.61.151.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.76.224.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,DE 194.76.225.0/24 AS34701 WITZENMANN-AS Witzenmann GmbH, Pforzheim,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.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 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.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 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 196.192.124.0/23 AS37301 AFRINIC-ZA-CPT-AS,MU 198.22.195.0/24 AS54583 -Reserved AS-,ZZ 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC,US 198.73.226.0/23 AS62839 -Reserved AS-,ZZ 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.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 199.30.132.0/22 AS26003 -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.102.240.0/24 AS18508 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 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.233.87.0/24 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.6.87.0/24 AS27947 Telconet S.A,EC 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 202.3.75.0/24 AS18172 202.3.76.0/24 AS18172 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.45.10.0/23 AS24327 202.45.10.0/24 AS24327 202.45.11.0/24 AS24327 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.122.134.0/24 AS38615 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.165.120.0/24 AS19161 -Reserved AS-,ZZ 202.165.124.0/24 AS23749 GLOBAL-TRANSIT-AS-HKCOLO-AP HKCOLO ltd. Internet Service Provider,HK 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited,PK 203.142.219.0/24 AS45149 203.175.11.0/24 AS9229 SPEEDCAST-AP SPEEDCAST Limited,HK 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.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.139.0/24 AS40250 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.86.196.0/23 AS14372 -Reserved AS-,ZZ 204.86.198.0/23 AS33058 PEGASYSTEMS - Pegasystems Inc.,US 204.87.251.0/24 AS22217 -Reserved AS-,ZZ 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 205.137.240.0/20 AS11686 ENA - Education Networks of America,US 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.189.0.0/19 AS46879 -Reserved AS-,ZZ 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.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.83.88.0/22 AS15697 BT-BS BT Ignite Intercontinental Satellite Video Streaming,GB 208.83.90.0/23 AS15697 BT-BS BT Ignite Intercontinental Satellite Video Streaming,GB 208.83.91.0/24 AS12910 -Reserved AS-,ZZ 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.93.216.0/22 AS209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 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 CENTURYLINK-US-LEGACY-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,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.73.81.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.82.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.85.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.88.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.89.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.94.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,US 216.73.95.0/24 AS6432 DOUBLECLICK - Double Click, Inc.,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.212.192.0/19 AS46879 -Reserved AS-,ZZ 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US 216.238.192.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.193.0/24 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.238.194.0/24 AS26566 -Reserved AS-,ZZ 216.238.196.0/22 AS17184 ATL-CBEYOND - CBEYOND COMMUNICATIONS, LLC,US 216.251.50.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.53.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 216.251.62.0/24 AS38191 INFOSYS-AS Infosys Technologies Ltd,IN 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 Mar 27 22:00:03 2015 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Mar 2015 22:00:03 GMT Subject: BGP Update Report Message-ID: <201503272200.t2RM03C4086527@wattle.apnic.net> BGP Update Report Interval: 19-Mar-15 -to- 26-Mar-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4837 702745 13.0% 147.8 -- CHINA169-BACKBONE CNCGROUP China169 Backbone,CN 2 - AS23752 244946 4.5% 1828.0 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - AS9829 189846 3.5% 104.9 -- BSNL-NIB National Internet Backbone,IN 4 - AS61894 178259 3.3% 44564.8 -- FreeBSD Brasil LTDA,BR 5 - AS4134 135742 2.5% 38.6 -- CHINANET-BACKBONE No.31,Jin-rong Street,CN 6 - AS28024 107767 2.0% 70.9 -- Nuevatel PCS de Bolivia S.A.,BO 7 - AS21669 91310 1.7% 6522.1 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 8 - AS36947 81468 1.5% 493.7 -- ALGTEL-AS,DZ 9 - AS4808 72591 1.3% 38.7 -- CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 10 - AS53563 49214 0.9% 4921.4 -- XPLUSONE - X Plus One Solutions, Inc.,US 11 - AS8452 48999 0.9% 23.6 -- TE-AS TE-AS,EG 12 - AS19429 48663 0.9% 37.5 -- ETB - Colombia,CO 13 - AS7713 42512 0.8% 2237.5 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 14 - AS4812 41694 0.8% 59.6 -- CHINANET-SH-AP China Telecom (Group),CN 15 - AS33529 38476 0.7% 1539.0 -- PEAK-WEB-HOSTING - Peak Web Hosting Inc.,US 16 - AS39891 37945 0.7% 15.3 -- ALJAWWALSTC-AS Saudi Telecom Company JSC,SA 17 - AS7782 36584 0.7% 1355.0 -- ALSK-7782 - Alaska Communications Systems Group, Inc.,US 18 - AS393276 36376 0.7% 6062.7 -- CEA - Chugach Electric Association, Inc.,US 19 - AS8402 33140 0.6% 82.6 -- CORBINA-AS OJSC "Vimpelcom",RU 20 - AS28573 31607 0.6% 14.0 -- NET Servi�os de Comunica��o S.A.,BR TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS61894 178259 3.3% 44564.8 -- FreeBSD Brasil LTDA,BR 2 - AS197914 19647 0.4% 19647.0 -- STOCKHO-AS Stockho Hosting SARL,FR 3 - AS33356 17197 0.3% 8598.5 -- CTWS - Eagle-Tech Systems,US 4 - AS46336 8558 0.2% 8558.0 -- GOODVILLE - Goodville Mutual Casualty Company,US 5 - AS25563 24048 0.5% 8016.0 -- WEBLAND-AS Webland AG, Autonomous System,CH 6 - AS198005 14854 0.3% 7427.0 -- UNI-AS UNI BAHRAIN TELECOM Bsc closed,SA 7 - AS54970 7259 0.1% 7259.0 -- NORTHERN-AIR-CARGO - NORTHERN AIR CARGO,US 8 - AS21669 91310 1.7% 6522.1 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 9 - AS393276 36376 0.7% 6062.7 -- CEA - Chugach Electric Association, Inc.,US 10 - AS58396 18009 0.3% 6003.0 -- DETELNETWORKS-AS-ID PT. DEWATA TELEMATIKA,ID 11 - AS53563 49214 0.9% 4921.4 -- XPLUSONE - X Plus One Solutions, Inc.,US 12 - AS39913 4605 0.1% 4605.0 -- COTEWA-AS Manuel Wannemacher,DE 13 - AS33721 3507 0.1% 3507.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 14 - AS393588 3166 0.1% 3166.0 -- MUBEA-FLO - Mubea,US 15 - AS47680 13679 0.2% 2735.8 -- NHCS EOBO Limited,IE 16 - AS50869 2514 0.1% 2514.0 -- AKVARIUSNET Akvarius Ltd.,CZ 17 - AS62174 2484 0.1% 2484.0 -- INTERPAN-AS INTERPAN LTD.,BG 18 - AS7713 42512 0.8% 2237.5 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 19 - AS33440 8745 0.2% 2186.2 -- WEBRULON-NETWORK - webRulon, LLC,US 20 - AS45606 10266 0.2% 2053.2 -- TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 177.10.158.0/24 178221 2.9% AS61894 -- FreeBSD Brasil LTDA,BR 2 - 202.70.64.0/21 122090 2.0% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 202.70.88.0/21 121761 2.0% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 209.212.8.0/24 91244 1.5% AS21669 -- NJ-STATEWIDE-LIBRARY-NETWORK - New Jersey State Library,US 5 - 105.96.0.0/22 77442 1.3% AS36947 -- ALGTEL-AS,DZ 6 - 199.38.164.0/23 49199 0.8% AS53563 -- XPLUSONE - X Plus One Solutions, Inc.,US 7 - 118.98.88.0/24 42487 0.7% AS64567 -- -Private Use AS-,ZZ AS7713 -- TELKOMNET-AS-AP PT Telekomunikasi Indonesia,ID 8 - 69.194.4.0/24 38422 0.6% AS33529 -- PEAK-WEB-HOSTING - Peak Web Hosting Inc.,US 9 - 93.181.216.0/21 23509 0.4% AS13118 -- ASN-YARTELECOM OJSC Rostelecom,RU 10 - 130.0.192.0/21 19647 0.3% AS197914 -- STOCKHO-AS Stockho Hosting SARL,FR 11 - 67.59.81.0/24 17196 0.3% AS33356 -- CTWS - Eagle-Tech Systems,US 12 - 91.193.202.0/24 16220 0.3% AS42081 -- SPEEDY-NET-AS Speedy net EAD,BG 13 - 64.29.130.0/24 15422 0.2% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 14 - 88.87.160.0/19 13675 0.2% AS47680 -- NHCS EOBO Limited,IE 15 - 103.225.173.0/24 11997 0.2% AS58396 -- DETELNETWORKS-AS-ID PT. DEWATA TELEMATIKA,ID 16 - 95.47.46.0/24 11157 0.2% AS61308 -- PVONET-AS PVONET LTD,RU 17 - 42.83.48.0/20 11139 0.2% AS18135 -- BTV BTV Cable television,JP 18 - 192.58.232.0/24 9357 0.1% AS6629 -- NOAA-AS - NOAA,US 19 - 50.200.112.0/24 8558 0.1% AS46336 -- GOODVILLE - Goodville Mutual Casualty Company,US 20 - 92.43.216.0/21 8213 0.1% AS25563 -- WEBLAND-AS Webland AG, Autonomous System,CH 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 debottym.misc at gmail.com Fri Mar 27 15:14:27 2015 From: debottym.misc at gmail.com (Debottym Mukherjee) Date: Fri, 27 Mar 2015 11:14:27 -0400 Subject: Level 3 Outage Message-ID: Did anyone else experience a Level 3 outage in the last couple of days? Seems like we've been affected with quite a few VPNV4 outages (one that lasted for upto 9 hrs) and didn't get resolved until they rebuilt their vpnv4 address family on their PE router(s)? On Thu, Mar 26, 2015 at 8:00 AM, wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. godaddy contact (Tim) > 2. Frontier: Blocking port 22 because of illegal files? > (Aaron C. de Bruyn) > 3. Re: Frontier: Blocking port 22 because of illegal files? > (Eygene Ryabinkin) > 4. Re: Frontier: Blocking port 22 because of illegal files? > (Jon Lewis) > 5. Re: Frontier: Blocking port 22 because of illegal files? > (Stephen Satchell) > 6. Re: Frontier: Blocking port 22 because of illegal files? > (Seth Mos) > 7. booster to gain distance above 60km (Rodrigo Augusto) > 8. Re: Frontier: Blocking port 22 because of illegal files? > (Jens Link) > 9. Prefix hijack by INDOSAT AS4795 / AS4761 (Randy) > 10. Re: Frontier: Blocking port 22 because of illegal files? > (Livingood, Jason) > 11. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Christopher Morrow) > 12. Re: Frontier: Blocking port 22 because of illegal files? > (Jeff Richmond) > 13. Re: Frontier: Blocking port 22 because of illegal files? > (Daniel Corbe) > 14. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Randy) > 15. RE: Prefix hijack by INDOSAT AS4795 / AS4761 (Peter Rocca) > 16. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Christopher Morrow) > 17. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Christopher Morrow) > 18. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Randy) > 19. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Pierre Emeriaud) > 20. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Paul S.) > 21. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Chuck Anderson) > 22. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Christian Teuschel) > 23. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Andree Toonk) > 24. RE: Prefix hijack by INDOSAT AS4795 / AS4761 (Peter Rocca) > 25. Charter Engineer (Shawn L) > 26. RE: More specifics from AS18978 [was: Prefix hijack by > INDOSAT AS4795 / AS4761] (Randy) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 25 Mar 2015 16:41:50 -0600 > From: Tim > To: nanog at nanog.org > Subject: godaddy contact > Message-ID: <551339AE.8010203 at progressivemarketingnetwork.com> > Content-Type: text/plain; charset=utf-8 > > Anyone from godaddy on here or have contact details for them? We are > having a routing issue to them. > > > > ------------------------------ > > Message: 2 > Date: Wed, 25 Mar 2015 19:31:35 -0700 > From: "Aaron C. de Bruyn" > To: NANOG mailing list > Subject: Frontier: Blocking port 22 because of illegal files? > Message-ID: > Qfeg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > I've had a handful of clients contact me over the last week with > trouble using SCP (usually WinSCP) to manage their website content on > my servers. Either they get timeout messages from WinSCP or a message > saying they should switch to SFTP. > > After getting a few helpful users on the phone to run some quick > tests, we found port 22 was blocked. > > When my customers contacted Frontier, they were told that port 22 was > blocked because it is used to transfer illegal files. > > I called them, and got the same ridiculous excuse. > > Just a friendly heads-up to anyone from Frontier who might be > listening, I have a few additional ports you may wish to block: > > 80 - Allows users to use Google to search for illegal files > 443 - Allows users to use Google to search for illegal files in a secure > manner > 69 - Allows users to trivially transfer illegal files > 3389 - Allows users to connect to unlicensed Windows machines > 179 - Allows users to exchange routes to illegal file shares > 53 - Allows people to look up illegal names > > -A > > > ------------------------------ > > Message: 3 > Date: Thu, 26 Mar 2015 07:21:45 +0300 > From: Eygene Ryabinkin > To: "Aaron C. de Bruyn" > Cc: NANOG mailing list > Subject: Re: Frontier: Blocking port 22 because of illegal files? > Message-ID: > Content-Type: text/plain; charset=us-ascii > > Wed, Mar 25, 2015 at 07:31:35PM -0700, Aaron C. de Bruyn wrote: > > Just a friendly heads-up to anyone from Frontier who might be > > listening, I have a few additional ports you may wish to block: > > > > 80 - Allows users to use Google to search for illegal files > > 443 - Allows users to use Google to search for illegal files in a secure > manner > > 69 - Allows users to trivially transfer illegal files > > 3389 - Allows users to connect to unlicensed Windows machines > > 179 - Allows users to exchange routes to illegal file shares > > 53 - Allows people to look up illegal names > > Can't help to add that there are > > - port 21 that allow users to give commands to examine > the existence and initiate transfers of illegal files; > > - ports 1025 - 65535 that allow users to create data streams > to actually transfer illegal files in an (oh my) passive mode. > > ;) > -- > Eygene Ryabinkin, National Research Centre "Kurchatov Institute" > > Always code as if the guy who ends up maintaining your code will be > a violent psychopath who knows where you live. > > > ------------------------------ > > Message: 4 > Date: Thu, 26 Mar 2015 00:56:21 -0400 (EDT) > From: Jon Lewis > To: "Aaron C. de Bruyn" > Cc: NANOG mailing list > Subject: Re: Frontier: Blocking port 22 because of illegal files? > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Wed, 25 Mar 2015, Aaron C. de Bruyn wrote: > > > I've had a handful of clients contact me over the last week with > > trouble using SCP (usually WinSCP) to manage their website content on > > my servers. Either they get timeout messages from WinSCP or a message > > saying they should switch to SFTP. > > > > After getting a few helpful users on the phone to run some quick > > tests, we found port 22 was blocked. > > > > When my customers contacted Frontier, they were told that port 22 was > > blocked because it is used to transfer illegal files. > > > > I called them, and got the same ridiculous excuse. > > > > Just a friendly heads-up to anyone from Frontier who might be > > listening, I have a few additional ports you may wish to block: > > I wonder if their support is just confused, and Frontier is really > blocking outbound tcp/22 to stop complaints generated by infected > customers with sshd scanners. After all, most of their customers probably > don't know what SSH is. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > > ------------------------------ > > Message: 5 > Date: Thu, 26 Mar 2015 04:24:38 -0700 > From: Stephen Satchell > To: nanog at nanog.org > Subject: Re: Frontier: Blocking port 22 because of illegal files? > Message-ID: <5513EC76.5060306 at satchell.net> > Content-Type: text/plain; charset=UTF-8 > > On 03/25/2015 07:31 PM, Aaron C. de Bruyn wrote: > > After getting a few helpful users on the phone to run some quick > > tests, we found port 22 was blocked. > > It's been a while since I did this, but you can select an additional > port to accept SSH connections. A Google search indicates you can > specify multiple ports in OpenSSH. Picking the right port to use is an > exercise, though, that will depend on what other services you are > running on your server. > > People with sane ISPs can use the standard port. People on Frontier can > use the alternate port, which shouldn't be firewalled by the provider. > If Frontier is running a mostly-closed firewall configuration, then you > have to be damn careful about the port you select. > > > > > ------------------------------ > > Message: 6 > Date: Thu, 26 Mar 2015 12:56:31 +0100 > From: Seth Mos > To: nanog at nanog.org > Subject: Re: Frontier: Blocking port 22 because of illegal files? > Message-ID: <5513F3EF.2080805 at dds.nl> > Content-Type: text/plain; charset=utf-8 > > Stephen Satchell schreef op 26-3-2015 om 12:24: > > On 03/25/2015 07:31 PM, Aaron C. de Bruyn wrote: > >> After getting a few helpful users on the phone to run some quick > >> tests, we found port 22 was blocked. > > > > It's been a while since I did this, but you can select an additional > > port to accept SSH connections. A Google search indicates you can > > specify multiple ports in OpenSSH. Picking the right port to use is an > > exercise, though, that will depend on what other services you are > > running on your server. > > > > People with sane ISPs can use the standard port. People on Frontier can > > use the alternate port, which shouldn't be firewalled by the provider. > > If Frontier is running a mostly-closed firewall configuration, then you > > have to be damn careful about the port you select. > > Ahem, just to clarify, he is not talking about inbound on the Frontier > connection, but outbound *from* the Frontier network. > > Akin to the "Let's block outbound port 25 (smtp)". > > This is just a really really bad idea m'kay. > > Cheers > > > > > ------------------------------ > > Message: 7 > Date: Thu, 26 Mar 2015 09:07:39 -0300 > From: Rodrigo Augusto > To: nanog > Subject: booster to gain distance above 60km > Message-ID: > Content-Type: text/plain; charset="ISO-8859-1" > > Hi folksŠ we have a point and have a 63km between point A to point BŠ. We > have a sigle fiber ( only one fiber) and use a fiberstore sfp+ 10GB dibi > 1270/1330 module to connect these sites. All attenuation are okŠI don¹t > have > any trouble on fiber Š. > I have received this signal on my sfp+: > > Receiver signal average optical power : 0.0026 mW / -25.85 dBm > > > Does anyone know if have some possible to amplifier this scenario to get > more 7db ? Is it possible to put any booster or any way to solve this? > I think to use a optical PreAmlifierŠbut I don¹t know if is possible > because > my scenario have just one fiberŠor, use a ROPA- remote optical pumping > amplifier) because I have 63kmŠ > Does anyone have some idea? > > Rodrigo Augusto > Gestor de T.I. Grupo Connectoway > http://www.connectoway.com.br > http://www.1telecom.com.br > * rodrigo at connectoway.com.br > ( (81) 3497-6060 > ( (81) 8184-3646 > ( INOC-DBA 52965*100 > > > > > ------------------------------ > > Message: 8 > Date: Thu, 26 Mar 2015 13:10:35 +0100 > From: Jens Link > To: nanog at nanog.org > Subject: Re: Frontier: Blocking port 22 because of illegal files? > Message-ID: <87mw30hscj.fsf at pc8.berlin.quux.de> > Content-Type: text/plain > > Stephen Satchell writes: > > > It's been a while since I did this, but you can select an additional > > port to accept SSH connections. > > That's easy: > > jens at screen:~$ grep Port /etc/ssh/sshd_config > Port 22 > Port 443 > > > Picking the right port to use is an exercise, though, that will depend > > on what other services you are running on your server. > > I always have at least one sshd listening on port 443. For all the > hotel, coffee house, customer networks blocking ssh. > > You can even multiplex and run ssh and ssl on the same port: > > http://www.rutschle.net/tech/sslh.shtml > > Jens > -- > > ---------------------------------------------------------------------------- > | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 > | > | http://blog.quux.de | jabber: jenslink at jabber.quux.de | > --------------- | > > ---------------------------------------------------------------------------- > > > ------------------------------ > > Message: 9 > Date: Thu, 26 Mar 2015 07:08:20 -0700 > From: Randy > To: nanog at nanog.org > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > more specifics on one of our prefixes. Anyone else seeing similar or > is it just us? > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > -- > Randy > > > ------------------------------ > > Message: 10 > Date: Thu, 26 Mar 2015 14:09:52 +0000 > From: "Livingood, Jason" > To: "Aaron C. de Bruyn" , NANOG mailing list > > Subject: Re: Frontier: Blocking port 22 because of illegal files? > Message-ID: > Content-Type: text/plain; charset="Windows-1252" > > ISPs are generally expected to disclose any port blocking. A quick Google > search shows this is Frontier’s list: > http://www.frontierhelp.com/faq.cfm?qstid=277 > > On 3/25/15, 10:31 PM, "Aaron C. de Bruyn" aaron at heyaaron.com>> wrote: > > I've had a handful of clients contact me over the last week with > trouble using SCP (usually WinSCP) to manage their website content on > my servers. Either they get timeout messages from WinSCP or a message > saying they should switch to SFTP. > > After getting a few helpful users on the phone to run some quick > tests, we found port 22 was blocked. > > When my customers contacted Frontier, they were told that port 22 was > blocked because it is used to transfer illegal files. > > I called them, and got the same ridiculous excuse. > > Just a friendly heads-up to anyone from Frontier who might be > listening, I have a few additional ports you may wish to block: > > 80 - Allows users to use Google to search for illegal files > 443 - Allows users to use Google to search for illegal files in a secure > manner > 69 - Allows users to trivially transfer illegal files > 3389 - Allows users to connect to unlicensed Windows machines > 179 - Allows users to exchange routes to illegal file shares > 53 - Allows people to look up illegal names > > -A > > > > ------------------------------ > > Message: 11 > Date: Thu, 26 Mar 2015 10:27:21 -0400 > From: Christopher Morrow > To: amps at djlab.com > Cc: nanog list > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: > 252pBSEFpdi1QaGXq5ZEJ-AyvA at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Thu, Mar 26, 2015 at 10:08 AM, Randy wrote: > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > more > > specifics on one of our prefixes. Anyone else seeing similar or is it > just > > us? > > is your AS in the path below? (what is your AS so folk can check for > your prefixes/customer-prefixes and attempt to help?) > > > > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > > > -- > > Randy > > > ------------------------------ > > Message: 12 > Date: Thu, 26 Mar 2015 07:28:57 -0700 > From: Jeff Richmond > To: "Livingood, Jason" > Cc: "Aaron C. de Bruyn" , NANOG mailing list > > Subject: Re: Frontier: Blocking port 22 because of illegal files? > Message-ID: <006E35AD-00E6-4B61-890F-29E580CE91C9 at gmail.com> > Content-Type: text/plain; charset=windows-1252 > > All, I have reached out to Aaron privately for details, but we do not > block port 22 traffic unless it is in direct response to an attack or > related item. Please let me know directly if you have any specific > questions. > > Thanks, > -Jeff > > > On Mar 26, 2015, at 7:09 AM, Livingood, Jason < > Jason_Livingood at cable.comcast.com> wrote: > > > > ISPs are generally expected to disclose any port blocking. A quick > Google search shows this is Frontier’s list: > > http://www.frontierhelp.com/faq.cfm?qstid=277 > > > > On 3/25/15, 10:31 PM, "Aaron C. de Bruyn" aaron at heyaaron.com>> wrote: > > > > I've had a handful of clients contact me over the last week with > > trouble using SCP (usually WinSCP) to manage their website content on > > my servers. Either they get timeout messages from WinSCP or a message > > saying they should switch to SFTP. > > > > After getting a few helpful users on the phone to run some quick > > tests, we found port 22 was blocked. > > > > When my customers contacted Frontier, they were told that port 22 was > > blocked because it is used to transfer illegal files. > > > > I called them, and got the same ridiculous excuse. > > > > Just a friendly heads-up to anyone from Frontier who might be > > listening, I have a few additional ports you may wish to block: > > > > 80 - Allows users to use Google to search for illegal files > > 443 - Allows users to use Google to search for illegal files in a secure > manner > > 69 - Allows users to trivially transfer illegal files > > 3389 - Allows users to connect to unlicensed Windows machines > > 179 - Allows users to exchange routes to illegal file shares > > 53 - Allows people to look up illegal names > > > > -A > > > > > > ------------------------------ > > Message: 13 > Date: Thu, 26 Mar 2015 10:32:31 -0400 > From: Daniel Corbe > To: "Livingood\, Jason" > Cc: "Aaron C. de Bruyn" , NANOG mailing list > > Subject: Re: Frontier: Blocking port 22 because of illegal files? > Message-ID: <874mp7hls0.fsf at corbe.net> > Content-Type: text/plain; charset=utf-8 > > > Nothing helps promote a free and open Internet more than micromanaging > your users' download activity. > > Not really sure how someone comes to the conclusion that nobody really > *needs* ssh for anything. > > "Livingood, Jason" writes: > > > ISPs are generally expected to disclose any port blocking. A quick > Google search shows this is Frontier’s list: > > http://www.frontierhelp.com/faq.cfm?qstid=277 > > > > On 3/25/15, 10:31 PM, "Aaron C. de Bruyn" aaron at heyaaron.com>> wrote: > > > > I've had a handful of clients contact me over the last week with > > trouble using SCP (usually WinSCP) to manage their website content on > > my servers. Either they get timeout messages from WinSCP or a message > > saying they should switch to SFTP. > > > > After getting a few helpful users on the phone to run some quick > > tests, we found port 22 was blocked. > > > > When my customers contacted Frontier, they were told that port 22 was > > blocked because it is used to transfer illegal files. > > > > I called them, and got the same ridiculous excuse. > > > > Just a friendly heads-up to anyone from Frontier who might be > > listening, I have a few additional ports you may wish to block: > > > > 80 - Allows users to use Google to search for illegal files > > 443 - Allows users to use Google to search for illegal files in a secure > manner > > 69 - Allows users to trivially transfer illegal files > > 3389 - Allows users to connect to unlicensed Windows machines > > 179 - Allows users to exchange routes to illegal file shares > > 53 - Allows people to look up illegal names > > > > -A > > > ------------------------------ > > Message: 14 > Date: Thu, 26 Mar 2015 07:38:08 -0700 > From: Randy > To: Christopher Morrow > Cc: christopher.morrow at gmail.com, nanog list > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On 03/26/2015 7:27 am, Christopher Morrow wrote: > > is your AS in the path below? (what is your AS so folk can check for > > your prefixes/customer-prefixes and attempt to help?) > > Sorry, we're 29889. > > > > ------------------------------ > > Message: 15 > Date: Thu, 26 Mar 2015 14:43:20 +0000 > From: Peter Rocca > To: "nanog at nanog.org" > Subject: RE: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: <44c3b7398b0c46b8a842c44da3f379be at APP02.start.local> > Content-Type: text/plain; charset="us-ascii" > > We just received a similar alert from bgpmon - part of 108.168.0.0/17 is > being advertised as /20's - although we're still listed as the origin. We > are 40788. > > 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy > Sent: March-26-15 10:08 AM > To: nanog at nanog.org > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > more specifics on one of our prefixes. Anyone else seeing similar or > is it just us? > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > -- > Randy > > > ------------------------------ > > Message: 16 > Date: Thu, 26 Mar 2015 10:44:28 -0400 > From: Christopher Morrow > To: amps at djlab.com > Cc: nanog list > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: > Xo6UUVfAz_4gGR9w at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Thu, Mar 26, 2015 at 10:38 AM, Randy wrote: > > On 03/26/2015 7:27 am, Christopher Morrow wrote: > >> > >> is your AS in the path below? (what is your AS so folk can check for > >> your prefixes/customer-prefixes and attempt to help?) > > > > > > Sorry, we're 29889. > > > > ok, and it looks like the path you clipped is: > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > possibly LAIX is passing along your /24 you didn't mean them to pass on? > > > ------------------------------ > > Message: 17 > Date: Thu, 26 Mar 2015 10:45:09 -0400 > From: Christopher Morrow > To: Peter Rocca > Cc: "nanog at nanog.org" > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: > < > CAL9jLaaLxcncc4uyTKz7SuDUks4B+VjzA56NO6n_tdHRmhJsZA at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Thu, Mar 26, 2015 at 10:43 AM, Peter Rocca wrote: > > We just received a similar alert from bgpmon - part of 108.168.0.0/17 > is being advertised as /20's - although we're still listed as the origin. > We are 40788. > > > > 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > > > common point looks like LAIX ? their routeserver go crazy perhaps? or > did they change in/out prefix management information? > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy > > Sent: March-26-15 10:08 AM > > To: nanog at nanog.org > > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > > > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > > more specifics on one of our prefixes. Anyone else seeing similar or > > is it just us? > > > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > > > -- > > Randy > > > ------------------------------ > > Message: 18 > Date: Thu, 26 Mar 2015 07:46:31 -0700 > From: Randy > To: Christopher Morrow > Cc: christopher.morrow at gmail.com, nanog list > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: <78c55aee9b1853c827c78adb8527fafb at mailbox.fastserv.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > All, > > Info gathered off-list indicates this may be a couple of issues in our > case - possible routing leak by 18978 (check your tables!) and more > specifics on our prefixes from 4795 that we couldn't see before the leak > hence the apparent hijack. > > -- > ~Randy > > > ------------------------------ > > Message: 19 > Date: Thu, 26 Mar 2015 15:46:51 +0100 > From: Pierre Emeriaud > To: amps at djlab.com > Cc: nanog at nanog.org > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: > < > CA+PSOpyoEOAsWgQ1mzG+mLs0zrMOw35o7YTRE_R5YsSM8uCAxA at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi, > > > 2015-03-26 15:08 GMT+01:00 Randy : > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > more > > specifics on one of our prefixes. Anyone else seeing similar or is it > just > > us? > > > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > We (as3215) are seeing almost the same path with 40633 18978 3257 > 3215, for some quite a lot of prefixes. > > Some alerts from bgpmon: > 193.251.32.0/20 271 6939 40633 18978 3257 3215 > 193.251.32.0/20 271 6939 40633 18978 3257 3215 > > We are not directly connected to 3257. Looks like 18978 deaggregated > to /20 and reannounced to 40633 (LAIX). > > > Rgds, > pierre > > > ------------------------------ > > Message: 20 > Date: Thu, 26 Mar 2015 23:48:12 +0900 > From: "Paul S." > To: nanog at nanog.org > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: <55141C2C.40706 at winterei.se> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Same here. These Indosat guys can't seem to catch a break =/ > > On 3/26/2015 午後 11:43, Peter Rocca wrote: > > We just received a similar alert from bgpmon - part of 108.168.0.0/17 > is being advertised as /20's - although we're still listed as the origin. > We are 40788. > > > > 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy > > Sent: March-26-15 10:08 AM > > To: nanog at nanog.org > > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > > > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > > more specifics on one of our prefixes. Anyone else seeing similar or > > is it just us? > > > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > > > > > ------------------------------ > > Message: 21 > Date: Thu, 26 Mar 2015 11:00:31 -0400 > From: Chuck Anderson > To: nanog at nanog.org > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: <20150326150030.GO9776 at angus.ind.WPI.EDU> > Content-Type: text/plain; charset=us-ascii > > We are AS 10326 130.215.0.0/16 and I just received a BGPmon alert as > well: > > 130.215.160.0/20 4795 4795 4761 9304 40633 18978 4436 10326 > 130.215.176.0/20 4795 4795 4761 9304 40633 18978 4436 10326 > > On Thu, Mar 26, 2015 at 10:45:09AM -0400, Christopher Morrow wrote: > > On Thu, Mar 26, 2015 at 10:43 AM, Peter Rocca wrote: > > > We just received a similar alert from bgpmon - part of 108.168.0.0/17 > is being advertised as /20's - although we're still listed as the origin. > We are 40788. > > > > > > 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > > 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > > 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > > > > > > common point looks like LAIX ? their routeserver go crazy perhaps? or > > did they change in/out prefix management information? > > > > > -----Original Message----- > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy > > > Sent: March-26-15 10:08 AM > > > To: nanog at nanog.org > > > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > > > > > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > > > more specifics on one of our prefixes. Anyone else seeing similar or > > > is it just us? > > > > > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > > > > > -- > > > Randy > > > ------------------------------ > > Message: 22 > Date: Thu, 26 Mar 2015 16:02:00 +0100 > From: Christian Teuschel > To: nanog at nanog.org > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: <55141F68.9060900 at ripe.net> > Content-Type: text/plain; charset="windows-1252" > > Hi Randy, > > Assuming that your prefix is 198.98.180.0/22 (AS29889 - FSNET-1 - Fast > Serv Networks, LLC) none of the mentioned more specifics are currently > seen from the RIPE NCC's RIS network, see the Looking Glass widget: > > https://stat.ripe.net/198.98.180.0/23#tabId=routing > https://stat.ripe.net/198.98.182.0/23#tabId=at-a-glance > > though there has been some BGP activity going on since 11:49:42, see the > BGPlay and BGP Update Activity widget. In both cases the originating ASN > was AS29889. > > Cheers, > Christian > > On 26/03/15 15:46, Randy wrote: > > All, > > > > Info gathered off-list indicates this may be a couple of issues in our > > case - possible routing leak by 18978 (check your tables!) and more > > specifics on our prefixes from 4795 that we couldn't see before the leak > > hence the apparent hijack. > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: christian_teuschel.vcf > Type: text/x-vcard > Size: 342 bytes > Desc: not available > URL: < > http://mailman.nanog.org/pipermail/nanog/attachments/20150326/9de6eabc/attachment-0001.vcf > > > > ------------------------------ > > Message: 23 > Date: Thu, 26 Mar 2015 08:53:37 -0700 > From: Andree Toonk > To: Peter Rocca > Cc: "nanog at nanog.org" > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: <55142B81.9000305 at toonk.nl> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi List, > > this morning our BGPmon system picked up many new more specific > announcements by a variety of Origin ASns, the interesting part is that > the majority of them were classified as BGP Man In The middle attacks > (MITM). > > A typical alert would look like: > > ==================================================================== > Possible BGP MITM attack (Code: 21) > ==================================================================== > Your prefix: 23.20.0.0/15: > Prefix Description: acxiom-online.com --- Amazon EC2 IAD prefix > Update time: 2015-03-26 11:27 (UTC) > Detected by #peers: 24 > Detected prefix: 23.21.112.0/20 > Announced by: AS14618 (AMAZON-AES - Amazon.com, Inc.,US) > Upstream AS: AS3257 (TINET-BACKBONE Tinet SpA,DE) > ASpath: 4608 24130 7545 6939 40633 18978 3257 14618 > > All alerts have the following part of the AS Path is common: > 40633 1897 > > We're still looking into the details of this particular cases, but > based on past experience it's likely that it is not in fact 14618 AWS, > that originated this more specific (in this example), but most likely > 18978 (or 40633), which leaked it to AS40633 Los Angeles Internet > exchange, where others picked it up and propagated it to their customers. > > In the past we've seen similar issues caused by BGP traffic optimizers. > These devices introduce new more specifics (try to keep the ASpath in > tact) for Traffic engineering purposes, and then folks leak those. A > good write up of a previous example can be found here: > http://www.bgpmon.net/accidentally-stealing-the-internet/ > > A quick scan show that this affected over 5000 prefixes and about 145 > Autonomous systems. All of these appear to be more specific prefixes > (which is the scary part). > > Cheers, > Andree > > PS. It appears this is not related to INDOSAT, they just happen to be > one of the peers that picked this up. > > > .-- My secret spy satellite informs me that at 2015-03-26 7:43 AM Peter > Rocca wrote: > > We just received a similar alert from bgpmon - part of 108.168.0.0/17 > is being advertised as /20's - although we're still listed as the origin. > We are 40788. > > > > 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy > > Sent: March-26-15 10:08 AM > > To: nanog at nanog.org > > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > > > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > > more specifics on one of our prefixes. Anyone else seeing similar or > > is it just us? > > > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > > > > ------------------------------ > > Message: 24 > Date: Thu, 26 Mar 2015 16:00:13 +0000 > From: Peter Rocca > To: Andree Toonk > Cc: "nanog at nanog.org" > Subject: RE: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > +1 > > The summary below aligns with our analysis as well. > > We've reached out to AS18978 to determine the status of the leak but at > this time we're not seeing any operational impact. > > -----Original Message----- > From: Andree Toonk [mailto:andree+nanog at toonk.nl] > Sent: March-26-15 11:54 AM > To: Peter Rocca > Cc: nanog at nanog.org > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > > Hi List, > > this morning our BGPmon system picked up many new more specific > announcements by a variety of Origin ASns, the interesting part is that the > majority of them were classified as BGP Man In The middle attacks (MITM). > > A typical alert would look like: > > ==================================================================== > Possible BGP MITM attack (Code: 21) > ==================================================================== > Your prefix: 23.20.0.0/15: > Prefix Description: acxiom-online.com --- Amazon EC2 IAD prefix > Update time: 2015-03-26 11:27 (UTC) > Detected by #peers: 24 > Detected prefix: 23.21.112.0/20 > Announced by: AS14618 (AMAZON-AES - Amazon.com, Inc.,US) > Upstream AS: AS3257 (TINET-BACKBONE Tinet SpA,DE) > ASpath: 4608 24130 7545 6939 40633 18978 3257 14618 > > All alerts have the following part of the AS Path is common: > 40633 1897 > > We're still looking into the details of this particular cases, but based > on past experience it's likely that it is not in fact 14618 AWS, that > originated this more specific (in this example), but most likely > 18978 (or 40633), which leaked it to AS40633 Los Angeles Internet > exchange, where others picked it up and propagated it to their customers. > > In the past we've seen similar issues caused by BGP traffic optimizers. > These devices introduce new more specifics (try to keep the ASpath in > tact) for Traffic engineering purposes, and then folks leak those. A good > write up of a previous example can be found here: > http://www.bgpmon.net/accidentally-stealing-the-internet/ > > A quick scan show that this affected over 5000 prefixes and about 145 > Autonomous systems. All of these appear to be more specific prefixes (which > is the scary part). > > Cheers, > Andree > > PS. It appears this is not related to INDOSAT, they just happen to be one > of the peers that picked this up. > > > .-- My secret spy satellite informs me that at 2015-03-26 7:43 AM Peter > Rocca wrote: > > We just received a similar alert from bgpmon - part of 108.168.0.0/17 > is being advertised as /20's - although we're still listed as the origin. > We are 40788. > > > > 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy > > Sent: March-26-15 10:08 AM > > To: nanog at nanog.org > > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > > > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > > more specifics on one of our prefixes. Anyone else seeing similar or > > is it just us? > > > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > > > > ------------------------------ > > Message: 25 > Date: Thu, 26 Mar 2015 12:09:10 -0400 > From: Shawn L > To: nanog > Subject: Charter Engineer > Message-ID: > ep9GS2Kc+AA at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Could a Charter engineer with familiarity with Michigan contact me > off-list? We have a mutual client who's having issues communicating > between sites. > > Thanks > > > ------------------------------ > > Message: 26 > Date: Thu, 26 Mar 2015 09:14:25 -0700 > From: Randy > To: Peter Rocca > Cc: nanog at nanog.org > Subject: RE: More specifics from AS18978 [was: Prefix hijack by > INDOSAT AS4795 / AS4761] > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On 03/26/2015 9:00 am, Peter Rocca wrote: > > +1 > > > > The summary below aligns with our analysis as well. > > > > We've reached out to AS18978 to determine the status of the leak but > > at this time we're not seeing any operational impact. > > +2, after the morning coffee sunk in and helpful off list replies I can > finally see it's probably not INDOSAT involved at all. > > FYI, the more specifics are still active: > > 2015-03-26 13:56:11 Update AS4795 ID 198.98.180.0/23 4795 4795 > 4761 > 9304 40633 18978 6939 29889 Active > 2015-03-26 13:56:11 Update AS4795 ID 198.98.182.0/23 4795 4795 > 4761 > 9304 40633 18978 6939 29889 Active > > -- > ~Randy > > > End of NANOG Digest, Vol 86, Issue 27 > ************************************* > From frnkblk at iname.com Sat Mar 28 03:44:41 2015 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 27 Mar 2015 22:44:41 -0500 Subject: Level 3 Outage In-Reply-To: References: Message-ID: <00ab01d06909$861ec510$925c4f30$@iname.com> Yes, see this thread: https://puck.nether.net/pipermail/outages/2015-March/007687.html Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Debottym Mukherjee Sent: Friday, March 27, 2015 10:14 AM To: nanog at nanog.org Subject: Level 3 Outage Did anyone else experience a Level 3 outage in the last couple of days? Seems like we've been affected with quite a few VPNV4 outages (one that lasted for upto 9 hrs) and didn't get resolved until they rebuilt their vpnv4 address family on their PE router(s)? On Thu, Mar 26, 2015 at 8:00 AM, wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. godaddy contact (Tim) > 2. Frontier: Blocking port 22 because of illegal files? > (Aaron C. de Bruyn) > 3. Re: Frontier: Blocking port 22 because of illegal files? > (Eygene Ryabinkin) > 4. Re: Frontier: Blocking port 22 because of illegal files? > (Jon Lewis) > 5. Re: Frontier: Blocking port 22 because of illegal files? > (Stephen Satchell) > 6. Re: Frontier: Blocking port 22 because of illegal files? > (Seth Mos) > 7. booster to gain distance above 60km (Rodrigo Augusto) > 8. Re: Frontier: Blocking port 22 because of illegal files? > (Jens Link) > 9. Prefix hijack by INDOSAT AS4795 / AS4761 (Randy) > 10. Re: Frontier: Blocking port 22 because of illegal files? > (Livingood, Jason) > 11. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Christopher Morrow) > 12. Re: Frontier: Blocking port 22 because of illegal files? > (Jeff Richmond) > 13. Re: Frontier: Blocking port 22 because of illegal files? > (Daniel Corbe) > 14. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Randy) > 15. RE: Prefix hijack by INDOSAT AS4795 / AS4761 (Peter Rocca) > 16. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Christopher Morrow) > 17. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Christopher Morrow) > 18. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Randy) > 19. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Pierre Emeriaud) > 20. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Paul S.) > 21. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Chuck Anderson) > 22. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Christian Teuschel) > 23. Re: Prefix hijack by INDOSAT AS4795 / AS4761 (Andree Toonk) > 24. RE: Prefix hijack by INDOSAT AS4795 / AS4761 (Peter Rocca) > 25. Charter Engineer (Shawn L) > 26. RE: More specifics from AS18978 [was: Prefix hijack by > INDOSAT AS4795 / AS4761] (Randy) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 25 Mar 2015 16:41:50 -0600 > From: Tim > To: nanog at nanog.org > Subject: godaddy contact > Message-ID: <551339AE.8010203 at progressivemarketingnetwork.com> > Content-Type: text/plain; charset=utf-8 > > Anyone from godaddy on here or have contact details for them? We are > having a routing issue to them. > > > > ------------------------------ > > Message: 2 > Date: Wed, 25 Mar 2015 19:31:35 -0700 > From: "Aaron C. de Bruyn" > To: NANOG mailing list > Subject: Frontier: Blocking port 22 because of illegal files? > Message-ID: > Qfeg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > I've had a handful of clients contact me over the last week with > trouble using SCP (usually WinSCP) to manage their website content on > my servers. Either they get timeout messages from WinSCP or a message > saying they should switch to SFTP. > > After getting a few helpful users on the phone to run some quick > tests, we found port 22 was blocked. > > When my customers contacted Frontier, they were told that port 22 was > blocked because it is used to transfer illegal files. > > I called them, and got the same ridiculous excuse. > > Just a friendly heads-up to anyone from Frontier who might be > listening, I have a few additional ports you may wish to block: > > 80 - Allows users to use Google to search for illegal files > 443 - Allows users to use Google to search for illegal files in a secure > manner > 69 - Allows users to trivially transfer illegal files > 3389 - Allows users to connect to unlicensed Windows machines > 179 - Allows users to exchange routes to illegal file shares > 53 - Allows people to look up illegal names > > -A > > > ------------------------------ > > Message: 3 > Date: Thu, 26 Mar 2015 07:21:45 +0300 > From: Eygene Ryabinkin > To: "Aaron C. de Bruyn" > Cc: NANOG mailing list > Subject: Re: Frontier: Blocking port 22 because of illegal files? > Message-ID: > Content-Type: text/plain; charset=us-ascii > > Wed, Mar 25, 2015 at 07:31:35PM -0700, Aaron C. de Bruyn wrote: > > Just a friendly heads-up to anyone from Frontier who might be > > listening, I have a few additional ports you may wish to block: > > > > 80 - Allows users to use Google to search for illegal files > > 443 - Allows users to use Google to search for illegal files in a secure > manner > > 69 - Allows users to trivially transfer illegal files > > 3389 - Allows users to connect to unlicensed Windows machines > > 179 - Allows users to exchange routes to illegal file shares > > 53 - Allows people to look up illegal names > > Can't help to add that there are > > - port 21 that allow users to give commands to examine > the existence and initiate transfers of illegal files; > > - ports 1025 - 65535 that allow users to create data streams > to actually transfer illegal files in an (oh my) passive mode. > > ;) > -- > Eygene Ryabinkin, National Research Centre "Kurchatov Institute" > > Always code as if the guy who ends up maintaining your code will be > a violent psychopath who knows where you live. > > > ------------------------------ > > Message: 4 > Date: Thu, 26 Mar 2015 00:56:21 -0400 (EDT) > From: Jon Lewis > To: "Aaron C. de Bruyn" > Cc: NANOG mailing list > Subject: Re: Frontier: Blocking port 22 because of illegal files? > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Wed, 25 Mar 2015, Aaron C. de Bruyn wrote: > > > I've had a handful of clients contact me over the last week with > > trouble using SCP (usually WinSCP) to manage their website content on > > my servers. Either they get timeout messages from WinSCP or a message > > saying they should switch to SFTP. > > > > After getting a few helpful users on the phone to run some quick > > tests, we found port 22 was blocked. > > > > When my customers contacted Frontier, they were told that port 22 was > > blocked because it is used to transfer illegal files. > > > > I called them, and got the same ridiculous excuse. > > > > Just a friendly heads-up to anyone from Frontier who might be > > listening, I have a few additional ports you may wish to block: > > I wonder if their support is just confused, and Frontier is really > blocking outbound tcp/22 to stop complaints generated by infected > customers with sshd scanners. After all, most of their customers probably > don't know what SSH is. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > > ------------------------------ > > Message: 5 > Date: Thu, 26 Mar 2015 04:24:38 -0700 > From: Stephen Satchell > To: nanog at nanog.org > Subject: Re: Frontier: Blocking port 22 because of illegal files? > Message-ID: <5513EC76.5060306 at satchell.net> > Content-Type: text/plain; charset=UTF-8 > > On 03/25/2015 07:31 PM, Aaron C. de Bruyn wrote: > > After getting a few helpful users on the phone to run some quick > > tests, we found port 22 was blocked. > > It's been a while since I did this, but you can select an additional > port to accept SSH connections. A Google search indicates you can > specify multiple ports in OpenSSH. Picking the right port to use is an > exercise, though, that will depend on what other services you are > running on your server. > > People with sane ISPs can use the standard port. People on Frontier can > use the alternate port, which shouldn't be firewalled by the provider. > If Frontier is running a mostly-closed firewall configuration, then you > have to be damn careful about the port you select. > > > > > ------------------------------ > > Message: 6 > Date: Thu, 26 Mar 2015 12:56:31 +0100 > From: Seth Mos > To: nanog at nanog.org > Subject: Re: Frontier: Blocking port 22 because of illegal files? > Message-ID: <5513F3EF.2080805 at dds.nl> > Content-Type: text/plain; charset=utf-8 > > Stephen Satchell schreef op 26-3-2015 om 12:24: > > On 03/25/2015 07:31 PM, Aaron C. de Bruyn wrote: > >> After getting a few helpful users on the phone to run some quick > >> tests, we found port 22 was blocked. > > > > It's been a while since I did this, but you can select an additional > > port to accept SSH connections. A Google search indicates you can > > specify multiple ports in OpenSSH. Picking the right port to use is an > > exercise, though, that will depend on what other services you are > > running on your server. > > > > People with sane ISPs can use the standard port. People on Frontier can > > use the alternate port, which shouldn't be firewalled by the provider. > > If Frontier is running a mostly-closed firewall configuration, then you > > have to be damn careful about the port you select. > > Ahem, just to clarify, he is not talking about inbound on the Frontier > connection, but outbound *from* the Frontier network. > > Akin to the "Let's block outbound port 25 (smtp)". > > This is just a really really bad idea m'kay. > > Cheers > > > > > ------------------------------ > > Message: 7 > Date: Thu, 26 Mar 2015 09:07:39 -0300 > From: Rodrigo Augusto > To: nanog > Subject: booster to gain distance above 60km > Message-ID: > Content-Type: text/plain; charset="ISO-8859-1" > > Hi folksŠ we have a point and have a 63km between point A to point BŠ. We > have a sigle fiber ( only one fiber) and use a fiberstore sfp+ 10GB dibi > 1270/1330 module to connect these sites. All attenuation are okŠI don¹t > have > any trouble on fiber Š. > I have received this signal on my sfp+: > > Receiver signal average optical power : 0.0026 mW / -25.85 dBm > > > Does anyone know if have some possible to amplifier this scenario to get > more 7db ? Is it possible to put any booster or any way to solve this? > I think to use a optical PreAmlifierŠbut I don¹t know if is possible > because > my scenario have just one fiberŠor, use a ROPA- remote optical pumping > amplifier) because I have 63kmŠ > Does anyone have some idea? > > Rodrigo Augusto > Gestor de T.I. Grupo Connectoway > http://www.connectoway.com.br > http://www.1telecom.com.br > * rodrigo at connectoway.com.br > ( (81) 3497-6060 > ( (81) 8184-3646 > ( INOC-DBA 52965*100 > > > > > ------------------------------ > > Message: 8 > Date: Thu, 26 Mar 2015 13:10:35 +0100 > From: Jens Link > To: nanog at nanog.org > Subject: Re: Frontier: Blocking port 22 because of illegal files? > Message-ID: <87mw30hscj.fsf at pc8.berlin.quux.de> > Content-Type: text/plain > > Stephen Satchell writes: > > > It's been a while since I did this, but you can select an additional > > port to accept SSH connections. > > That's easy: > > jens at screen:~$ grep Port /etc/ssh/sshd_config > Port 22 > Port 443 > > > Picking the right port to use is an exercise, though, that will depend > > on what other services you are running on your server. > > I always have at least one sshd listening on port 443. For all the > hotel, coffee house, customer networks blocking ssh. > > You can even multiplex and run ssh and ssl on the same port: > > http://www.rutschle.net/tech/sslh.shtml > > Jens > -- > > ---------------------------------------------------------------------------- > | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 > | > | http://blog.quux.de | jabber: jenslink at jabber.quux.de | > --------------- | > > ---------------------------------------------------------------------------- > > > ------------------------------ > > Message: 9 > Date: Thu, 26 Mar 2015 07:08:20 -0700 > From: Randy > To: nanog at nanog.org > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > more specifics on one of our prefixes. Anyone else seeing similar or > is it just us? > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > -- > Randy > > > ------------------------------ > > Message: 10 > Date: Thu, 26 Mar 2015 14:09:52 +0000 > From: "Livingood, Jason" > To: "Aaron C. de Bruyn" , NANOG mailing list > > Subject: Re: Frontier: Blocking port 22 because of illegal files? > Message-ID: > Content-Type: text/plain; charset="Windows-1252" > > ISPs are generally expected to disclose any port blocking. A quick Google > search shows this is Frontier’s list: > http://www.frontierhelp.com/faq.cfm?qstid=277 > > On 3/25/15, 10:31 PM, "Aaron C. de Bruyn" aaron at heyaaron.com>> wrote: > > I've had a handful of clients contact me over the last week with > trouble using SCP (usually WinSCP) to manage their website content on > my servers. Either they get timeout messages from WinSCP or a message > saying they should switch to SFTP. > > After getting a few helpful users on the phone to run some quick > tests, we found port 22 was blocked. > > When my customers contacted Frontier, they were told that port 22 was > blocked because it is used to transfer illegal files. > > I called them, and got the same ridiculous excuse. > > Just a friendly heads-up to anyone from Frontier who might be > listening, I have a few additional ports you may wish to block: > > 80 - Allows users to use Google to search for illegal files > 443 - Allows users to use Google to search for illegal files in a secure > manner > 69 - Allows users to trivially transfer illegal files > 3389 - Allows users to connect to unlicensed Windows machines > 179 - Allows users to exchange routes to illegal file shares > 53 - Allows people to look up illegal names > > -A > > > > ------------------------------ > > Message: 11 > Date: Thu, 26 Mar 2015 10:27:21 -0400 > From: Christopher Morrow > To: amps at djlab.com > Cc: nanog list > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: > 252pBSEFpdi1QaGXq5ZEJ-AyvA at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Thu, Mar 26, 2015 at 10:08 AM, Randy wrote: > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > more > > specifics on one of our prefixes. Anyone else seeing similar or is it > just > > us? > > is your AS in the path below? (what is your AS so folk can check for > your prefixes/customer-prefixes and attempt to help?) > > > > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > > > -- > > Randy > > > ------------------------------ > > Message: 12 > Date: Thu, 26 Mar 2015 07:28:57 -0700 > From: Jeff Richmond > To: "Livingood, Jason" > Cc: "Aaron C. de Bruyn" , NANOG mailing list > > Subject: Re: Frontier: Blocking port 22 because of illegal files? > Message-ID: <006E35AD-00E6-4B61-890F-29E580CE91C9 at gmail.com> > Content-Type: text/plain; charset=windows-1252 > > All, I have reached out to Aaron privately for details, but we do not > block port 22 traffic unless it is in direct response to an attack or > related item. Please let me know directly if you have any specific > questions. > > Thanks, > -Jeff > > > On Mar 26, 2015, at 7:09 AM, Livingood, Jason < > Jason_Livingood at cable.comcast.com> wrote: > > > > ISPs are generally expected to disclose any port blocking. A quick > Google search shows this is Frontier’s list: > > http://www.frontierhelp.com/faq.cfm?qstid=277 > > > > On 3/25/15, 10:31 PM, "Aaron C. de Bruyn" aaron at heyaaron.com>> wrote: > > > > I've had a handful of clients contact me over the last week with > > trouble using SCP (usually WinSCP) to manage their website content on > > my servers. Either they get timeout messages from WinSCP or a message > > saying they should switch to SFTP. > > > > After getting a few helpful users on the phone to run some quick > > tests, we found port 22 was blocked. > > > > When my customers contacted Frontier, they were told that port 22 was > > blocked because it is used to transfer illegal files. > > > > I called them, and got the same ridiculous excuse. > > > > Just a friendly heads-up to anyone from Frontier who might be > > listening, I have a few additional ports you may wish to block: > > > > 80 - Allows users to use Google to search for illegal files > > 443 - Allows users to use Google to search for illegal files in a secure > manner > > 69 - Allows users to trivially transfer illegal files > > 3389 - Allows users to connect to unlicensed Windows machines > > 179 - Allows users to exchange routes to illegal file shares > > 53 - Allows people to look up illegal names > > > > -A > > > > > > ------------------------------ > > Message: 13 > Date: Thu, 26 Mar 2015 10:32:31 -0400 > From: Daniel Corbe > To: "Livingood\, Jason" > Cc: "Aaron C. de Bruyn" , NANOG mailing list > > Subject: Re: Frontier: Blocking port 22 because of illegal files? > Message-ID: <874mp7hls0.fsf at corbe.net> > Content-Type: text/plain; charset=utf-8 > > > Nothing helps promote a free and open Internet more than micromanaging > your users' download activity. > > Not really sure how someone comes to the conclusion that nobody really > *needs* ssh for anything. > > "Livingood, Jason" writes: > > > ISPs are generally expected to disclose any port blocking. A quick > Google search shows this is Frontier’s list: > > http://www.frontierhelp.com/faq.cfm?qstid=277 > > > > On 3/25/15, 10:31 PM, "Aaron C. de Bruyn" aaron at heyaaron.com>> wrote: > > > > I've had a handful of clients contact me over the last week with > > trouble using SCP (usually WinSCP) to manage their website content on > > my servers. Either they get timeout messages from WinSCP or a message > > saying they should switch to SFTP. > > > > After getting a few helpful users on the phone to run some quick > > tests, we found port 22 was blocked. > > > > When my customers contacted Frontier, they were told that port 22 was > > blocked because it is used to transfer illegal files. > > > > I called them, and got the same ridiculous excuse. > > > > Just a friendly heads-up to anyone from Frontier who might be > > listening, I have a few additional ports you may wish to block: > > > > 80 - Allows users to use Google to search for illegal files > > 443 - Allows users to use Google to search for illegal files in a secure > manner > > 69 - Allows users to trivially transfer illegal files > > 3389 - Allows users to connect to unlicensed Windows machines > > 179 - Allows users to exchange routes to illegal file shares > > 53 - Allows people to look up illegal names > > > > -A > > > ------------------------------ > > Message: 14 > Date: Thu, 26 Mar 2015 07:38:08 -0700 > From: Randy > To: Christopher Morrow > Cc: christopher.morrow at gmail.com, nanog list > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On 03/26/2015 7:27 am, Christopher Morrow wrote: > > is your AS in the path below? (what is your AS so folk can check for > > your prefixes/customer-prefixes and attempt to help?) > > Sorry, we're 29889. > > > > ------------------------------ > > Message: 15 > Date: Thu, 26 Mar 2015 14:43:20 +0000 > From: Peter Rocca > To: "nanog at nanog.org" > Subject: RE: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: <44c3b7398b0c46b8a842c44da3f379be at APP02.start.local> > Content-Type: text/plain; charset="us-ascii" > > We just received a similar alert from bgpmon - part of 108.168.0.0/17 is > being advertised as /20's - although we're still listed as the origin. We > are 40788. > > 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy > Sent: March-26-15 10:08 AM > To: nanog at nanog.org > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > more specifics on one of our prefixes. Anyone else seeing similar or > is it just us? > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > -- > Randy > > > ------------------------------ > > Message: 16 > Date: Thu, 26 Mar 2015 10:44:28 -0400 > From: Christopher Morrow > To: amps at djlab.com > Cc: nanog list > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: > Xo6UUVfAz_4gGR9w at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Thu, Mar 26, 2015 at 10:38 AM, Randy wrote: > > On 03/26/2015 7:27 am, Christopher Morrow wrote: > >> > >> is your AS in the path below? (what is your AS so folk can check for > >> your prefixes/customer-prefixes and attempt to help?) > > > > > > Sorry, we're 29889. > > > > ok, and it looks like the path you clipped is: > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > possibly LAIX is passing along your /24 you didn't mean them to pass on? > > > ------------------------------ > > Message: 17 > Date: Thu, 26 Mar 2015 10:45:09 -0400 > From: Christopher Morrow > To: Peter Rocca > Cc: "nanog at nanog.org" > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: > < > CAL9jLaaLxcncc4uyTKz7SuDUks4B+VjzA56NO6n_tdHRmhJsZA at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Thu, Mar 26, 2015 at 10:43 AM, Peter Rocca wrote: > > We just received a similar alert from bgpmon - part of 108.168.0.0/17 > is being advertised as /20's - although we're still listed as the origin. > We are 40788. > > > > 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > > > common point looks like LAIX ? their routeserver go crazy perhaps? or > did they change in/out prefix management information? > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy > > Sent: March-26-15 10:08 AM > > To: nanog at nanog.org > > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > > > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > > more specifics on one of our prefixes. Anyone else seeing similar or > > is it just us? > > > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > > > -- > > Randy > > > ------------------------------ > > Message: 18 > Date: Thu, 26 Mar 2015 07:46:31 -0700 > From: Randy > To: Christopher Morrow > Cc: christopher.morrow at gmail.com, nanog list > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: <78c55aee9b1853c827c78adb8527fafb at mailbox.fastserv.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > All, > > Info gathered off-list indicates this may be a couple of issues in our > case - possible routing leak by 18978 (check your tables!) and more > specifics on our prefixes from 4795 that we couldn't see before the leak > hence the apparent hijack. > > -- > ~Randy > > > ------------------------------ > > Message: 19 > Date: Thu, 26 Mar 2015 15:46:51 +0100 > From: Pierre Emeriaud > To: amps at djlab.com > Cc: nanog at nanog.org > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: > < > CA+PSOpyoEOAsWgQ1mzG+mLs0zrMOw35o7YTRE_R5YsSM8uCAxA at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi, > > > 2015-03-26 15:08 GMT+01:00 Randy : > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > more > > specifics on one of our prefixes. Anyone else seeing similar or is it > just > > us? > > > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > We (as3215) are seeing almost the same path with 40633 18978 3257 > 3215, for some quite a lot of prefixes. > > Some alerts from bgpmon: > 193.251.32.0/20 271 6939 40633 18978 3257 3215 > 193.251.32.0/20 271 6939 40633 18978 3257 3215 > > We are not directly connected to 3257. Looks like 18978 deaggregated > to /20 and reannounced to 40633 (LAIX). > > > Rgds, > pierre > > > ------------------------------ > > Message: 20 > Date: Thu, 26 Mar 2015 23:48:12 +0900 > From: "Paul S." > To: nanog at nanog.org > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: <55141C2C.40706 at winterei.se> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Same here. These Indosat guys can't seem to catch a break =/ > > On 3/26/2015 午後 11:43, Peter Rocca wrote: > > We just received a similar alert from bgpmon - part of 108.168.0.0/17 > is being advertised as /20's - although we're still listed as the origin. > We are 40788. > > > > 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy > > Sent: March-26-15 10:08 AM > > To: nanog at nanog.org > > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > > > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > > more specifics on one of our prefixes. Anyone else seeing similar or > > is it just us? > > > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > > > > > ------------------------------ > > Message: 21 > Date: Thu, 26 Mar 2015 11:00:31 -0400 > From: Chuck Anderson > To: nanog at nanog.org > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: <20150326150030.GO9776 at angus.ind.WPI.EDU> > Content-Type: text/plain; charset=us-ascii > > We are AS 10326 130.215.0.0/16 and I just received a BGPmon alert as > well: > > 130.215.160.0/20 4795 4795 4761 9304 40633 18978 4436 10326 > 130.215.176.0/20 4795 4795 4761 9304 40633 18978 4436 10326 > > On Thu, Mar 26, 2015 at 10:45:09AM -0400, Christopher Morrow wrote: > > On Thu, Mar 26, 2015 at 10:43 AM, Peter Rocca wrote: > > > We just received a similar alert from bgpmon - part of 108.168.0.0/17 > is being advertised as /20's - although we're still listed as the origin. > We are 40788. > > > > > > 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > > 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > > 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > > > > > > common point looks like LAIX ? their routeserver go crazy perhaps? or > > did they change in/out prefix management information? > > > > > -----Original Message----- > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy > > > Sent: March-26-15 10:08 AM > > > To: nanog at nanog.org > > > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > > > > > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > > > more specifics on one of our prefixes. Anyone else seeing similar or > > > is it just us? > > > > > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > > > > > -- > > > Randy > > > ------------------------------ > > Message: 22 > Date: Thu, 26 Mar 2015 16:02:00 +0100 > From: Christian Teuschel > To: nanog at nanog.org > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: <55141F68.9060900 at ripe.net> > Content-Type: text/plain; charset="windows-1252" > > Hi Randy, > > Assuming that your prefix is 198.98.180.0/22 (AS29889 - FSNET-1 - Fast > Serv Networks, LLC) none of the mentioned more specifics are currently > seen from the RIPE NCC's RIS network, see the Looking Glass widget: > > https://stat.ripe.net/198.98.180.0/23#tabId=routing > https://stat.ripe.net/198.98.182.0/23#tabId=at-a-glance > > though there has been some BGP activity going on since 11:49:42, see the > BGPlay and BGP Update Activity widget. In both cases the originating ASN > was AS29889. > > Cheers, > Christian > > On 26/03/15 15:46, Randy wrote: > > All, > > > > Info gathered off-list indicates this may be a couple of issues in our > > case - possible routing leak by 18978 (check your tables!) and more > > specifics on our prefixes from 4795 that we couldn't see before the leak > > hence the apparent hijack. > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: christian_teuschel.vcf > Type: text/x-vcard > Size: 342 bytes > Desc: not available > URL: < > http://mailman.nanog.org/pipermail/nanog/attachments/20150326/9de6eabc/attachment-0001.vcf > > > > ------------------------------ > > Message: 23 > Date: Thu, 26 Mar 2015 08:53:37 -0700 > From: Andree Toonk > To: Peter Rocca > Cc: "nanog at nanog.org" > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: <55142B81.9000305 at toonk.nl> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi List, > > this morning our BGPmon system picked up many new more specific > announcements by a variety of Origin ASns, the interesting part is that > the majority of them were classified as BGP Man In The middle attacks > (MITM). > > A typical alert would look like: > > ==================================================================== > Possible BGP MITM attack (Code: 21) > ==================================================================== > Your prefix: 23.20.0.0/15: > Prefix Description: acxiom-online.com --- Amazon EC2 IAD prefix > Update time: 2015-03-26 11:27 (UTC) > Detected by #peers: 24 > Detected prefix: 23.21.112.0/20 > Announced by: AS14618 (AMAZON-AES - Amazon.com, Inc.,US) > Upstream AS: AS3257 (TINET-BACKBONE Tinet SpA,DE) > ASpath: 4608 24130 7545 6939 40633 18978 3257 14618 > > All alerts have the following part of the AS Path is common: > 40633 1897 > > We're still looking into the details of this particular cases, but > based on past experience it's likely that it is not in fact 14618 AWS, > that originated this more specific (in this example), but most likely > 18978 (or 40633), which leaked it to AS40633 Los Angeles Internet > exchange, where others picked it up and propagated it to their customers. > > In the past we've seen similar issues caused by BGP traffic optimizers. > These devices introduce new more specifics (try to keep the ASpath in > tact) for Traffic engineering purposes, and then folks leak those. A > good write up of a previous example can be found here: > http://www.bgpmon.net/accidentally-stealing-the-internet/ > > A quick scan show that this affected over 5000 prefixes and about 145 > Autonomous systems. All of these appear to be more specific prefixes > (which is the scary part). > > Cheers, > Andree > > PS. It appears this is not related to INDOSAT, they just happen to be > one of the peers that picked this up. > > > .-- My secret spy satellite informs me that at 2015-03-26 7:43 AM Peter > Rocca wrote: > > We just received a similar alert from bgpmon - part of 108.168.0.0/17 > is being advertised as /20's - although we're still listed as the origin. > We are 40788. > > > > 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy > > Sent: March-26-15 10:08 AM > > To: nanog at nanog.org > > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > > > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > > more specifics on one of our prefixes. Anyone else seeing similar or > > is it just us? > > > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > > > > ------------------------------ > > Message: 24 > Date: Thu, 26 Mar 2015 16:00:13 +0000 > From: Peter Rocca > To: Andree Toonk > Cc: "nanog at nanog.org" > Subject: RE: Prefix hijack by INDOSAT AS4795 / AS4761 > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > +1 > > The summary below aligns with our analysis as well. > > We've reached out to AS18978 to determine the status of the leak but at > this time we're not seeing any operational impact. > > -----Original Message----- > From: Andree Toonk [mailto:andree+nanog at toonk.nl] > Sent: March-26-15 11:54 AM > To: Peter Rocca > Cc: nanog at nanog.org > Subject: Re: Prefix hijack by INDOSAT AS4795 / AS4761 > > Hi List, > > this morning our BGPmon system picked up many new more specific > announcements by a variety of Origin ASns, the interesting part is that the > majority of them were classified as BGP Man In The middle attacks (MITM). > > A typical alert would look like: > > ==================================================================== > Possible BGP MITM attack (Code: 21) > ==================================================================== > Your prefix: 23.20.0.0/15: > Prefix Description: acxiom-online.com --- Amazon EC2 IAD prefix > Update time: 2015-03-26 11:27 (UTC) > Detected by #peers: 24 > Detected prefix: 23.21.112.0/20 > Announced by: AS14618 (AMAZON-AES - Amazon.com, Inc.,US) > Upstream AS: AS3257 (TINET-BACKBONE Tinet SpA,DE) > ASpath: 4608 24130 7545 6939 40633 18978 3257 14618 > > All alerts have the following part of the AS Path is common: > 40633 1897 > > We're still looking into the details of this particular cases, but based > on past experience it's likely that it is not in fact 14618 AWS, that > originated this more specific (in this example), but most likely > 18978 (or 40633), which leaked it to AS40633 Los Angeles Internet > exchange, where others picked it up and propagated it to their customers. > > In the past we've seen similar issues caused by BGP traffic optimizers. > These devices introduce new more specifics (try to keep the ASpath in > tact) for Traffic engineering purposes, and then folks leak those. A good > write up of a previous example can be found here: > http://www.bgpmon.net/accidentally-stealing-the-internet/ > > A quick scan show that this affected over 5000 prefixes and about 145 > Autonomous systems. All of these appear to be more specific prefixes (which > is the scary part). > > Cheers, > Andree > > PS. It appears this is not related to INDOSAT, they just happen to be one > of the peers that picked this up. > > > .-- My secret spy satellite informs me that at 2015-03-26 7:43 AM Peter > Rocca wrote: > > We just received a similar alert from bgpmon - part of 108.168.0.0/17 > is being advertised as /20's - although we're still listed as the origin. > We are 40788. > > > > 108.168.64.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.80.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.96.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788 > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Randy > > Sent: March-26-15 10:08 AM > > To: nanog at nanog.org > > Subject: Prefix hijack by INDOSAT AS4795 / AS4761 > > > > On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing > > more specifics on one of our prefixes. Anyone else seeing similar or > > is it just us? > > > > 198.98.180.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > 198.98.182.0/23 4795 4795 4761 9304 40633 18978 4436 29889 > > > > > ------------------------------ > > Message: 25 > Date: Thu, 26 Mar 2015 12:09:10 -0400 > From: Shawn L > To: nanog > Subject: Charter Engineer > Message-ID: > ep9GS2Kc+AA at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Could a Charter engineer with familiarity with Michigan contact me > off-list? We have a mutual client who's having issues communicating > between sites. > > Thanks > > > ------------------------------ > > Message: 26 > Date: Thu, 26 Mar 2015 09:14:25 -0700 > From: Randy > To: Peter Rocca > Cc: nanog at nanog.org > Subject: RE: More specifics from AS18978 [was: Prefix hijack by > INDOSAT AS4795 / AS4761] > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On 03/26/2015 9:00 am, Peter Rocca wrote: > > +1 > > > > The summary below aligns with our analysis as well. > > > > We've reached out to AS18978 to determine the status of the leak but > > at this time we're not seeing any operational impact. > > +2, after the morning coffee sunk in and helpful off list replies I can > finally see it's probably not INDOSAT involved at all. > > FYI, the more specifics are still active: > > 2015-03-26 13:56:11 Update AS4795 ID 198.98.180.0/23 4795 4795 > 4761 > 9304 40633 18978 6939 29889 Active > 2015-03-26 13:56:11 Update AS4795 ID 198.98.182.0/23 4795 4795 > 4761 > 9304 40633 18978 6939 29889 Active > > -- > ~Randy > > > End of NANOG Digest, Vol 86, Issue 27 > ************************************* > From nicotine at warningg.com Sat Mar 28 15:26:39 2015 From: nicotine at warningg.com (Brandon Ewing) Date: Sat, 28 Mar 2015 10:26:39 -0500 Subject: Generating IPv6 list with filtergen.level3.net In-Reply-To: References: <8DD18D69FFC6DB46AE9CDB191CD8B9810F13E43F@PACDCEXMB04.cable.comcast.com> Message-ID: <20150328152639.GE24010@radiological.warningg.com> On Wed, Nov 02, 2011 at 08:00:20PM -0600, Kevin Epperson wrote: > Hi Courtney - > > Try something like: > > whois -h filtergen.level3.net "AS3356 -cp -v6" > or > whois -h filtergen.level3.net "AS3356 -cp -v4v6" > > Using AS7922 or something of that nature (currently I dont see any v6 routes > registered under 7922.) > > -Kevin Digging up a (very) old thread here, apologies. Does anyone know if filtergen is going to support IPv6-length subnet masks? Trying to use -le=128 returns an error. I can work around with sed, but just curious if this tool is still being developed. Emails to rr at level3.net return a bounce directing one to their customer portal. Also curious if the tool now supports IOS-XR RPL -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From job at instituut.net Sat Mar 28 15:33:16 2015 From: job at instituut.net (Job Snijders) Date: Sat, 28 Mar 2015 16:33:16 +0100 Subject: Generating IPv6 list with filtergen.level3.net In-Reply-To: <20150328152639.GE24010@radiological.warningg.com> References: <8DD18D69FFC6DB46AE9CDB191CD8B9810F13E43F@PACDCEXMB04.cable.comcast.com> <20150328152639.GE24010@radiological.warningg.com> Message-ID: <20150328153316.GR791@Vurt.local> On Sat, Mar 28, 2015 at 10:26:39AM -0500, Brandon Ewing wrote: > On Wed, Nov 02, 2011 at 08:00:20PM -0600, Kevin Epperson wrote: > > whois -h filtergen.level3.net "AS3356 -cp -v4v6" > > Digging up a (very) old thread here, apologies. > > Does anyone know if filtergen is going to support IPv6-length subnet > masks? Trying to use -le=128 returns an error. I can work around with > sed, but just curious if this tool is still being developed. May I recommend a different approach instead? Download and compile bgpq3: git clone https://github.com/snar/bgpq3.git && cd bgpq3 && ./configure && make Run bgpq3: Vurt:~ job$ bgpq3 -6 -A -R 128 -l AS15562pfx AS15562 no ipv6 prefix-list AS15562pfx ipv6 prefix-list AS15562pfx permit 2001:67c:208c::/48 le 128 ipv6 prefix-list AS15562pfx permit 2001:67c:2980::/48 le 128 ipv6 prefix-list AS15562pfx permit 2001:728:1808::/48 le 128 > Also curious if the tool now supports IOS-XR RPL bgpq3 supports BIRD, IOS, XR, JunOS & JSON output. See bgpq3 -h for all options Kind regards, Job From mike-nanog at tiedyenetworks.com Sat Mar 28 16:05:38 2015 From: mike-nanog at tiedyenetworks.com (Mike) Date: Sat, 28 Mar 2015 09:05:38 -0700 Subject: FIXED - Re: Broken SSL cert caused by router? In-Reply-To: <002701d068b4$3f6bdd60$be439820$@iname.com> References: <55148A7F.5020209@tiedyenetworks.com> <37237.77.1427428575578.JavaMail.mtlewis@T410I> <551578D1.8080903@tiedyenetworks.com> <002701d068b4$3f6bdd60$be439820$@iname.com> Message-ID: <5516D152.4060707@tiedyenetworks.com> On 03/27/2015 10:34 AM, Frank Bulk wrote: > Glad you figured that out. > > I've used three SSL evaluation websites to help me with intermediate certificate issues: > https://www.ssllabs.com/ssltest/analyze.html (will show the names and details of the certs, missing or not > https://www.wormly.com/test_ssl (quick SSL tester, will point out if intermediate certificate is missing) > https://www.digicert.com/help/ (will show a green chain link between certs when they're all there *and* in order) > > Frank > I went back to Frank's list and did some additional testing. I have a different server which was set up the same way as the previous one discussed, and I thought I would use the above tools and see if my problem would have been identified by any of them. I am sorry to report, no, none of these either caught the problem either. Although I still do not fully understand the dependencies involved, it seems that if my server was failing to supply the full certificate chain, and the browser was compensating for it by (attempting?) to load the missing certificate from elsewhere, and this Meraki router was somehow able to confound that process, that would be an issue worthy of exploring more. I certainly don't blame these ssl check sites but clearly theres more checks needed. Mike- From baldur.norddahl at gmail.com Sat Mar 28 16:51:38 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 28 Mar 2015 17:51:38 +0100 Subject: booster to gain distance above 60km In-Reply-To: References: Message-ID: Hi The easy way to get 63 km is to use a SFP+ module that is rated for 63 km. Fiberstore has 60 km BIDI SFP+ for USD 325 and 80 km BIDI for USD 425. If you want to use a booster you would need DWDM modules instead. And you have to add in the DWDM splitter and two boosters. For each end of the link it would be USD 435 for the SFP+ module, USD 174 for the BIDI DWDM splitter in a rack chassis and USD 1300 for a 13 dBm output booster. So - forget about the booster and just get the 80 km BIDI modules. Regards, Baldur On 26 March 2015 at 13:07, Rodrigo Augusto wrote: > Hi folksŠ we have a point and have a 63km between point A to point BŠ. We > have a sigle fiber ( only one fiber) and use a fiberstore sfp+ 10GB dibi > 1270/1330 module to connect these sites. All attenuation are okŠI don¹t > have > any trouble on fiber Š. > I have received this signal on my sfp+: > > Receiver signal average optical power : 0.0026 mW / -25.85 dBm > > > Does anyone know if have some possible to amplifier this scenario to get > more 7db ? Is it possible to put any booster or any way to solve this? > I think to use a optical PreAmlifierŠbut I don¹t know if is possible > because > my scenario have just one fiberŠor, use a ROPA- remote optical pumping > amplifier) because I have 63kmŠ > Does anyone have some idea? > > Rodrigo Augusto > Gestor de T.I. Grupo Connectoway > http://www.connectoway.com.br > http://www.1telecom.com.br > * rodrigo at connectoway.com.br > ( (81) 3497-6060 > ( (81) 8184-3646 > ( INOC-DBA 52965*100 > > > From frnkblk at iname.com Sat Mar 28 17:16:11 2015 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 28 Mar 2015 12:16:11 -0500 Subject: booster to gain distance above 60km In-Reply-To: References: Message-ID: <00d801d0697a$e3881fa0$aa985ee0$@iname.com> http://www.fiberstore.com/narrow/80km-120km_v993t0/bidi-sfp+_64 http://www.fiberstore.com/narrow/80km-120km_v993t0/bidi-xfp_113What Thanks for sharing. First time I saw 10G BiDi optics at 80 km. I needed them for an application a few months ago and had to take a new approach when I only could find 60 km ones. Frank -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Baldur Norddahl Sent: Saturday, March 28, 2015 11:52 AM To: Rodrigo Augusto Cc: nanog Subject: Re: booster to gain distance above 60km Hi The easy way to get 63 km is to use a SFP+ module that is rated for 63 km. Fiberstore has 60 km BIDI SFP+ for USD 325 and 80 km BIDI for USD 425. If you want to use a booster you would need DWDM modules instead. And you have to add in the DWDM splitter and two boosters. For each end of the link it would be USD 435 for the SFP+ module, USD 174 for the BIDI DWDM splitter in a rack chassis and USD 1300 for a 13 dBm output booster. So - forget about the booster and just get the 80 km BIDI modules. Regards, Baldur On 26 March 2015 at 13:07, Rodrigo Augusto wrote: > Hi folksŠ we have a point and have a 63km between point A to point BŠ. We > have a sigle fiber ( only one fiber) and use a fiberstore sfp+ 10GB dibi > 1270/1330 module to connect these sites. All attenuation are okŠI don¹t > have > any trouble on fiber Š. > I have received this signal on my sfp+: > > Receiver signal average optical power : 0.0026 mW / -25.85 dBm > > > Does anyone know if have some possible to amplifier this scenario to get > more 7db ? Is it possible to put any booster or any way to solve this? > I think to use a optical PreAmlifierŠbut I don¹t know if is possible > because > my scenario have just one fiberŠor, use a ROPA- remote optical pumping > amplifier) because I have 63kmŠ > Does anyone have some idea? > > Rodrigo Augusto > Gestor de T.I. Grupo Connectoway > http://www.connectoway.com.br > http://www.1telecom.com.br > * rodrigo at connectoway.com.br > ( (81) 3497-6060 > ( (81) 8184-3646 > ( INOC-DBA 52965*100 > > > From rodrigo at 1telecom.com.br Sat Mar 28 19:14:21 2015 From: rodrigo at 1telecom.com.br (Rodrigo 1telecom) Date: Sat, 28 Mar 2015 16:14:21 -0300 Subject: booster to gain distance above 60km In-Reply-To: References: Message-ID: <54FFFA95-999A-409B-BA74-3B4B4FD15097@1telecom.com.br> Already use this bidi sfp+ to 80km from fiberstore... But i can't link two sides... Have -24dbi... Everything alright with fiber... If i using this circuit with this signal i will have many trouble... I wiil buy a dwdm simplex solution from fiberstore again to use on this curcuit... What booster and preamplifier i have to use on it?! I will buy a 8channel simplex ... C21/c51, c22/c52 etc.... Do you know what a booster and an amplifier i have to buy? Enviado via iPhone  Grupo Connectoway > Em 28/03/2015, às 13:51, Baldur Norddahl escreveu: > > Hi > > The easy way to get 63 km is to use a SFP+ module that is rated for 63 km. Fiberstore has 60 km BIDI SFP+ for USD 325 and 80 km BIDI for USD 425. > > If you want to use a booster you would need DWDM modules instead. And you have to add in the DWDM splitter and two boosters. For each end of the link it would be USD 435 for the SFP+ module, USD 174 for the BIDI DWDM splitter in a rack chassis and USD 1300 for a 13 dBm output booster. > > So - forget about the booster and just get the 80 km BIDI modules. > > Regards, > > Baldur > > > > >> On 26 March 2015 at 13:07, Rodrigo Augusto wrote: >> Hi folksŠ we have a point and have a 63km between point A to point BŠ. We >> have a sigle fiber ( only one fiber) and use a fiberstore sfp+ 10GB dibi >> 1270/1330 module to connect these sites. All attenuation are okŠI don¹t have >> any trouble on fiber Š. >> I have received this signal on my sfp+: >> >> Receiver signal average optical power : 0.0026 mW / -25.85 dBm >> >> >> Does anyone know if have some possible to amplifier this scenario to get >> more 7db ? Is it possible to put any booster or any way to solve this? >> I think to use a optical PreAmlifierŠbut I don¹t know if is possible because >> my scenario have just one fiberŠor, use a ROPA- remote optical pumping >> amplifier) because I have 63kmŠ >> Does anyone have some idea? >> >> Rodrigo Augusto >> Gestor de T.I. Grupo Connectoway >> http://www.connectoway.com.br >> http://www.1telecom.com.br >> * rodrigo at connectoway.com.br >> ( (81) 3497-6060 >> ( (81) 8184-3646 >> ( INOC-DBA 52965*100 > From dougb at dougbarton.us Sat Mar 28 19:32:04 2015 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 28 Mar 2015 12:32:04 -0700 Subject: FIXED - Re: Broken SSL cert caused by router? In-Reply-To: <5516D152.4060707@tiedyenetworks.com> References: <55148A7F.5020209@tiedyenetworks.com> <37237.77.1427428575578.JavaMail.mtlewis@T410I> <551578D1.8080903@tiedyenetworks.com> <002701d068b4$3f6bdd60$be439820$@iname.com> <5516D152.4060707@tiedyenetworks.com> Message-ID: <551701B4.60702@dougbarton.us> On 3/28/15 9:05 AM, Mike wrote: > I went back to Frank's list and did some additional testing. I have a > different server which was set up the same way as the previous one > discussed, and I thought I would use the above tools and see if my > problem would have been identified by any of them. I am sorry to report, > no, none of these either caught the problem either. Although I still do > not fully understand the dependencies involved, it seems that if my > server was failing to supply the full certificate chain, and the browser > was compensating for it by (attempting?) to load the missing certificate > from elsewhere, and this Meraki router was somehow able to confound > that process, that would be an issue worthy of exploring more. I > certainly don't blame these ssl check sites but clearly theres more > checks needed. The Qualsys site (https://www.ssllabs.com/ssltest/analyze.html) will report whether or not the server supplied the intermediate cert. But I agree with you that the other tools should make a bigger deal about it if the server doesn't supply it. FWIW, it's been the CW to do this for some time now, as there are systems like the one you've run into that were designed before intermediate certs were commonplace, and don't know how to handle them. I've also experienced situations where an enterprise purchases a DV certificate to be used on an offline system, and while that system has access to the "root" CA certs, it cannot retrieve the intermediate cert. Having the end system supply the intermediate cert as well solves this issue. The method of supplying the intermediate cert is simple, just append the intermediate certificate to the end of the file with your server certificate (the .crt file). Any reasonably modern software will handle that transparently, and provide the intermediate cert along with the server cert when doing its business. hope this helps, Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From baldur.norddahl at gmail.com Sat Mar 28 19:47:12 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 28 Mar 2015 20:47:12 +0100 Subject: booster to gain distance above 60km In-Reply-To: <54FFFA95-999A-409B-BA74-3B4B4FD15097@1telecom.com.br> References: <54FFFA95-999A-409B-BA74-3B4B4FD15097@1telecom.com.br> Message-ID: In my experience I would say you probably have dirty connectors, and all you need to do is to clean all connections along the fiber or possibly straighten out any too tight bends you might have. You only gave us the output at the far end. We also need the output directly from the module to calculate the optical power budget. Note that the fiber attenuation is higher at 1310 nm than 1550 nm. So you will gain extra power just by switching to 1550 nm modules. Amplifiers only work at 1550 nm. Typical loss is 0.4 dB/km at 1310 and 0.3 dB/km at 1550. With new fiber it can be as low as 0.22 dB/km at 1550. With a power budget of 23 dB that is more than 100 km. You will however lose a little to insertion loss in the WDM. To work with 1550 nm you would buy two 1550 nm DWDM modules. Remember to use different channels on each module: http://www.fiberstore.com/10gbase-100ghz-dwdm-sfp-80km-single-mode-optical-transceiver-p-31535.html You will need a DWDM Mux type A in one end of the link and type B in the other end: Type A: http://www.fiberstore.com/2-channels-type-a-1ru-rack-mount-simplex-bidi-dwdm-mux-demux-p-26496.html Type B: http://www.fiberstore.com/2-channels-type-b-1ru-rack-mount-simplex-bidi-dwdm-mux-demux-p-30544.html You will actually only need one channel, but they do not appear to have that. So you get another channel, which you could use to make a dual 10 Gbps link. This should work without amplifiers for the given distance. If you do want to add amplification, you could either amplify the output of the module with a booster or you could amplify the input to the module with a preamp. I have no experience in doing that, so I can not tell which option is better. The booster is slightly cheaper. Regards, Baldur On 28 March 2015 at 20:14, Rodrigo 1telecom wrote: > Already use this bidi sfp+ to 80km from fiberstore... But i can't link two > sides... Have -24dbi... Everything alright with fiber... If i using this > circuit with this signal i will have many trouble... > I wiil buy a dwdm simplex solution from fiberstore again to use on this > curcuit... > What booster and preamplifier i have to use on it?! > I will buy a 8channel simplex ... C21/c51, c22/c52 etc.... Do you know > what a booster and an amplifier i have to buy? > > Enviado via iPhone  > Grupo Connectoway > > Em 28/03/2015, às 13:51, Baldur Norddahl > escreveu: > > Hi > > The easy way to get 63 km is to use a SFP+ module that is rated for 63 km. > Fiberstore has 60 km BIDI SFP+ for USD 325 and 80 km BIDI for USD 425. > > If you want to use a booster you would need DWDM modules instead. And you > have to add in the DWDM splitter and two boosters. For each end of the link > it would be USD 435 for the SFP+ module, USD 174 for the BIDI DWDM splitter > in a rack chassis and USD 1300 for a 13 dBm output booster. > > So - forget about the booster and just get the 80 km BIDI modules. > > Regards, > > Baldur > > > > > On 26 March 2015 at 13:07, Rodrigo Augusto > wrote: > >> Hi folksŠ we have a point and have a 63km between point A to point BŠ. We >> have a sigle fiber ( only one fiber) and use a fiberstore sfp+ 10GB dibi >> 1270/1330 module to connect these sites. All attenuation are okŠI don¹t >> have >> any trouble on fiber Š. >> I have received this signal on my sfp+: >> >> Receiver signal average optical power : 0.0026 mW / -25.85 dBm >> >> >> Does anyone know if have some possible to amplifier this scenario to get >> more 7db ? Is it possible to put any booster or any way to solve this? >> I think to use a optical PreAmlifierŠbut I don¹t know if is possible >> because >> my scenario have just one fiberŠor, use a ROPA- remote optical pumping >> amplifier) because I have 63kmŠ >> Does anyone have some idea? >> >> Rodrigo Augusto >> Gestor de T.I. Grupo Connectoway >> http://www.connectoway.com.br >> http://www.1telecom.com.br >> * rodrigo at connectoway.com.br >> ( (81) 3497-6060 >> ( (81) 8184-3646 >> ( INOC-DBA 52965*100 >> >> >> > From baldur.norddahl at gmail.com Sat Mar 28 19:59:33 2015 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 28 Mar 2015 20:59:33 +0100 Subject: booster to gain distance above 60km In-Reply-To: <54FFFA95-999A-409B-BA74-3B4B4FD15097@1telecom.com.br> References: <54FFFA95-999A-409B-BA74-3B4B4FD15097@1telecom.com.br> Message-ID: Sorry I forgot to read you message properly. You are saying you want 8 channels - note this will give you twice as much insertion loss compared to two channels and might tip the balance towards requiring amplification. You should also ask Fiberstore for advice for which channels you choose, as there might be a huge difference in loss. You can not amplify the single fiber. The amplifier will not tolerate a BIDI signal. You will therefore need to amplify each channel in separate amplifiers and that becomes very expensive. In theory the signal could be split using an optical circulator: http://www.fiberstore.com/c/optical-circulator_1311 and then you could amplify either RX or TX - probably you would want to amplify RX to sidestep issues with feedback and reflections disturbing the amplifier. I never tried this but I am very curious if it actually works... Regards, Baldur On 28 March 2015 at 20:14, Rodrigo 1telecom wrote: > Already use this bidi sfp+ to 80km from fiberstore... But i can't link two > sides... Have -24dbi... Everything alright with fiber... If i using this > circuit with this signal i will have many trouble... > I wiil buy a dwdm simplex solution from fiberstore again to use on this > curcuit... > What booster and preamplifier i have to use on it?! > I will buy a 8channel simplex ... C21/c51, c22/c52 etc.... Do you know > what a booster and an amplifier i have to buy? > > Enviado via iPhone  > Grupo Connectoway > > Em 28/03/2015, às 13:51, Baldur Norddahl > escreveu: > > Hi > > The easy way to get 63 km is to use a SFP+ module that is rated for 63 km. > Fiberstore has 60 km BIDI SFP+ for USD 325 and 80 km BIDI for USD 425. > > If you want to use a booster you would need DWDM modules instead. And you > have to add in the DWDM splitter and two boosters. For each end of the link > it would be USD 435 for the SFP+ module, USD 174 for the BIDI DWDM splitter > in a rack chassis and USD 1300 for a 13 dBm output booster. > > So - forget about the booster and just get the 80 km BIDI modules. > > Regards, > > Baldur > > > > > On 26 March 2015 at 13:07, Rodrigo Augusto > wrote: > >> Hi folksŠ we have a point and have a 63km between point A to point BŠ. We >> have a sigle fiber ( only one fiber) and use a fiberstore sfp+ 10GB dibi >> 1270/1330 module to connect these sites. All attenuation are okŠI don¹t >> have >> any trouble on fiber Š. >> I have received this signal on my sfp+: >> >> Receiver signal average optical power : 0.0026 mW / -25.85 dBm >> >> >> Does anyone know if have some possible to amplifier this scenario to get >> more 7db ? Is it possible to put any booster or any way to solve this? >> I think to use a optical PreAmlifierŠbut I don¹t know if is possible >> because >> my scenario have just one fiberŠor, use a ROPA- remote optical pumping >> amplifier) because I have 63kmŠ >> Does anyone have some idea? >> >> Rodrigo Augusto >> Gestor de T.I. Grupo Connectoway >> http://www.connectoway.com.br >> http://www.1telecom.com.br >> * rodrigo at connectoway.com.br >> ( (81) 3497-6060 >> ( (81) 8184-3646 >> ( INOC-DBA 52965*100 >> >> >> > From mpalmer at hezmatt.org Sat Mar 28 20:50:24 2015 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sun, 29 Mar 2015 07:50:24 +1100 Subject: FIXED - Re: Broken SSL cert caused by router? In-Reply-To: <5516D152.4060707@tiedyenetworks.com> References: <55148A7F.5020209@tiedyenetworks.com> <37237.77.1427428575578.JavaMail.mtlewis@T410I> <551578D1.8080903@tiedyenetworks.com> <002701d068b4$3f6bdd60$be439820$@iname.com> <5516D152.4060707@tiedyenetworks.com> Message-ID: <20150328205024.GX12292@hezmatt.org> On Sat, Mar 28, 2015 at 09:05:38AM -0700, Mike wrote: > On 03/27/2015 10:34 AM, Frank Bulk wrote: > >Glad you figured that out. > > > >I've used three SSL evaluation websites to help me with intermediate certificate issues: > >https://www.ssllabs.com/ssltest/analyze.html (will show the names and details of the certs, missing or not > >https://www.wormly.com/test_ssl (quick SSL tester, will point out if intermediate certificate is missing) > >https://www.digicert.com/help/ (will show a green chain link between certs when they're all there *and* in order) > > I went back to Frank's list and did some additional testing. I have a > different server which was set up the same way as the previous one > discussed, and I thought I would use the above tools and see if my problem > would have been identified by any of them. I am sorry to report, no, none of > these either caught the problem either. Are you able to share the URL of the misconfigured site? It would be interesting to examine exactly what's going on. - Matt -- The main advantages of Haynes and Chilton manuals are that they cost $15, where the factory manuals cost $100 and up, and that they will tell you how to use two hammers, a block of wood, and a meerkat to replace "special tool no. 2-112-A" -- Matt Roberds in asr. From courtneysmith at comcast.net Sun Mar 29 00:45:46 2015 From: courtneysmith at comcast.net (Courtney Smith) Date: Sat, 28 Mar 2015 20:45:46 -0400 Subject: Generating IPv6 list with filtergen.level3.net In-Reply-To: References: Message-ID: On Mar 28, 2015, at 8:00 AM, nanog-request at nanog.org wrote: >> >> >> Does anyone know if filtergen is going to support IPv6-length subnet >> masks? Trying to use -le=128 returns an error. I can work around with >> sed, but just curious if this tool is still being developed. > > May I recommend a different approach instead? > > Download and compile bgpq3: > > git clone https://github.com/snar/bgpq3.git && cd bgpq3 && ./configure && make > > Run bgpq3: > > Vurt:~ job$ bgpq3 -6 -A -R 128 -l AS15562pfx AS15562 > no ipv6 prefix-list AS15562pfx > ipv6 prefix-list AS15562pfx permit 2001:67c:208c::/48 le 128 > ipv6 prefix-list AS15562pfx permit 2001:67c:2980::/48 le 128 > ipv6 prefix-list AS15562pfx permit 2001:728:1808::/48 le 128 > >> Also curious if the tool now supports IOS-XR RPL > > bgpq3 supports BIRD, IOS, XR, JunOS & JSON output. See bgpq3 -h for all > options > > Kind regards, > > Job There is a Perl module NET::IRR. That is what I switched to for IPv6 support after using IRRPT for a few years. IRRPT has been rewritten in Python but have not had time to play with. It includes IPv6 support. You probably have to modify it to output in XR's set format. That's what I did with the original IRRPT. http://search.cpan.org/~tcaine/Net-IRR/lib/Net/IRR.pm https://github.com/ktims/irrpt-ng Courtney Smith courtneysmith at comcast.net I wanna devise a virus To bring dire straits to your environment Crush your corporations with a mild touch Trash your whole computer system and revert you to papyrus From mike-nanog at tiedyenetworks.com Mon Mar 30 02:33:03 2015 From: mike-nanog at tiedyenetworks.com (Mike) Date: Sun, 29 Mar 2015 19:33:03 -0700 Subject: FIXED - Re: Broken SSL cert caused by router? In-Reply-To: <20150328205024.GX12292@hezmatt.org> References: <55148A7F.5020209@tiedyenetworks.com> <37237.77.1427428575578.JavaMail.mtlewis@T410I> <551578D1.8080903@tiedyenetworks.com> <002701d068b4$3f6bdd60$be439820$@iname.com> <5516D152.4060707@tiedyenetworks.com> <20150328205024.GX12292@hezmatt.org> Message-ID: <5518B5DF.2060105@tiedyenetworks.com> On 03/28/2015 01:50 PM, Matt Palmer wrote: > On Sat, Mar 28, 2015 at 09:05:38AM -0700, Mike wrote: >> On 03/27/2015 10:34 AM, Frank Bulk wrote: >>> Glad you figured that out. >>> >>> I've used three SSL evaluation websites to help me with intermediate certificate issues: >>> https://www.ssllabs.com/ssltest/analyze.html (will show the names and details of the certs, missing or not >>> https://www.wormly.com/test_ssl (quick SSL tester, will point out if intermediate certificate is missing) >>> https://www.digicert.com/help/ (will show a green chain link between certs when they're all there *and* in order) >> I went back to Frank's list and did some additional testing. I have a >> different server which was set up the same way as the previous one >> discussed, and I thought I would use the above tools and see if my problem >> would have been identified by any of them. I am sorry to report, no, none of >> these either caught the problem either. > Are you able to share the URL of the misconfigured site? It would be > interesting to examine exactly what's going on. > > - Matt > SSLCertificateChainFile /etc/ssl/certs/gd_bundle-g2-g1.crt I have actually fixed it. What was going on seems to be this - I have a new godaddy certificate for *.mydomain.com, and that is what I installed. However, the certificate chain I supplied was missing some intermediate godaddy certificate. Originally, it appeared I was missing 'gdig2.crt', and once installed, that fixed some clients including the ones behind the meraki router. But then there were also some older clients this did not fix (a macos 10.4 something for example). So I went back and installed gd_bundle-g2-g1.crt in it's place, and that seems to have finally done it. I apologize for the diminishing lack of operational content. It just seems that these ssl tests should be tightened up and perhaps some additional tools deployed out there to help us less knowledgeable folks 'get it right'. Mike- From michael at supermathie.net Mon Mar 30 03:55:50 2015 From: michael at supermathie.net (Michael Brown) Date: Sun, 29 Mar 2015 23:55:50 -0400 Subject: FIXED - Re: Broken SSL cert caused by router? In-Reply-To: <5518B5DF.2060105@tiedyenetworks.com> References: <55148A7F.5020209@tiedyenetworks.com> <37237.77.1427428575578.JavaMail.mtlewis@T410I> <551578D1.8080903@tiedyenetworks.com> <002701d068b4$3f6bdd60$be439820$@iname.com> <5516D152.4060707@tiedyenetworks.com> <20150328205024.GX12292@hezmatt.org> <5518B5DF.2060105@tiedyenetworks.com> Message-ID: <20150330035550.6115404.11262.3661@supermathie.net> That's something I suspected at first, it but discounted when your said your laptop also failed at the site. The first intermediate you installed ‎took care of anything with the newer root certificates installed. But for your older 10.4 Mac clients (which presumably haven't had a root certificate bundle update in a while) that wasn't enough - the new root needed to be provided since from their perspective it's an intermediate. M.   Original Message   From: Mike Sent: Sunday, March 29, 2015 23:29 To: nanog at nanog.org Subject: Re: FIXED - Re: Broken SSL cert caused by router? On 03/28/2015 01:50 PM, Matt Palmer wrote: > On Sat, Mar 28, 2015 at 09:05:38AM -0700, Mike wrote: >> On 03/27/2015 10:34 AM, Frank Bulk wrote: >>> Glad you figured that out. >>> >>> I've used three SSL evaluation websites to help me with intermediate certificate issues: >>> https://www.ssllabs.com/ssltest/analyze.html (will show the names and details of the certs, missing or not >>> https://www.wormly.com/test_ssl (quick SSL tester, will point out if intermediate certificate is missing) >>> https://www.digicert.com/help/ (will show a green chain link between certs when they're all there *and* in order) >> I went back to Frank's list and did some additional testing. I have a >> different server which was set up the same way as the previous one >> discussed, and I thought I would use the above tools and see if my problem >> would have been identified by any of them. I am sorry to report, no, none of >> these either caught the problem either. > Are you able to share the URL of the misconfigured site? It would be > interesting to examine exactly what's going on. > > - Matt > SSLCertificateChainFile /etc/ssl/certs/gd_bundle-g2-g1.crt I have actually fixed it. What was going on seems to be this - I have a new godaddy certificate for *.mydomain.com, and that is what I installed. However, the certificate chain I supplied was missing some intermediate godaddy certificate. Originally, it appeared I was missing 'gdig2.crt', and once installed, that fixed some clients including the ones behind the meraki router. But then there were also some older clients this did not fix (a macos 10.4 something for example). So I went back and installed gd_bundle-g2-g1.crt in it's place, and that seems to have finally done it. I apologize for the diminishing lack of operational content. It just seems that these ssl tests should be tightened up and perhaps some additional tools deployed out there to help us less knowledgeable folks 'get it right'. Mike- From johnl at iecc.com Mon Mar 30 03:56:05 2015 From: johnl at iecc.com (John Levine) Date: 30 Mar 2015 03:56:05 -0000 Subject: FIXED - Re: Broken SSL cert caused by router? In-Reply-To: <5518B5DF.2060105@tiedyenetworks.com> Message-ID: <20150330035605.88087.qmail@ary.lan> >SSLCertificateChainFile /etc/ssl/certs/gd_bundle-g2-g1.crt > >I have actually fixed it. Yeah, that's always it. Back in the good aulde days all of the SSL certs one might buy were signed directly by the CA, but now more often than not there are intermediate certs, and a valid cert needs to be accompanied by all of the intermediate certs between it and the CA. What makes debugging hard is that browsers try to be helpful. If a server doesn't provide the intermediate certs, but the browser happens to have them in its cache from some other site, well, close enough and the SSL works. But if some other browser doesn't happen to have them, you lose. So if your SSL is flaky, check those intermediate certs first. R's, John From mkamal at noor.net Mon Mar 30 14:39:14 2015 From: mkamal at noor.net (Mohamed Kamal) Date: Mon, 30 Mar 2015 17:39:14 +0300 Subject: Cisco's IOS-XE and PCEP implementation Message-ID: <55196012.9050508@noor.net> I'm wondering, why there is no MPLS-TE PCE support for IOS-XE till now?! Should I be getting a 9k/CRS on the edge to implement an automatic tool to build MPLS-TE tunnels! -- Mohamed Kamal Core Network Sr. Engineer From mark.tinka at seacom.mu Mon Mar 30 15:07:01 2015 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 30 Mar 2015 17:07:01 +0200 Subject: Cisco's IOS-XE and PCEP implementation In-Reply-To: <55196012.9050508@noor.net> References: <55196012.9050508@noor.net> Message-ID: <55196695.2030603@seacom.mu> On 30/Mar/15 16:39, Mohamed Kamal wrote: > I'm wondering, why there is no MPLS-TE PCE support for IOS-XE till now?! > > Should I be getting a 9k/CRS on the edge to implement an automatic tool > to build MPLS-TE tunnels! My guess is if there is some code, you want to get it through your SE. Mark. From tom.taylor.stds at gmail.com Mon Mar 30 17:41:50 2015 From: tom.taylor.stds at gmail.com (Tom Taylor) Date: Mon, 30 Mar 2015 13:41:50 -0400 Subject: FIXED - Re: Broken SSL cert caused by router? In-Reply-To: <20150330035605.88087.qmail@ary.lan> References: <20150330035605.88087.qmail@ary.lan> Message-ID: <55198ADE.6020307@gmail.com> On 29/03/2015 11:56 PM, John Levine wrote: >> SSLCertificateChainFile /etc/ssl/certs/gd_bundle-g2-g1.crt >> >> I have actually fixed it. > > Yeah, that's always it. > > Back in the good aulde days all of the SSL certs one might buy were > signed directly by the CA, but now more often than not there are > intermediate certs, and a valid cert needs to be accompanied by all of > the intermediate certs between it and the CA. > > What makes debugging hard is that browsers try to be helpful. If a > server doesn't provide the intermediate certs, but the browser happens > to have them in its cache from some other site, well, close enough and > the SSL works. But if some other browser doesn't happen to have them, > you lose. > > So if your SSL is flaky, check those intermediate certs first. > > R's, > John > With all this resolved, I'll note that I just reviewed draft-ietf-tls-sslv3-diediedie, which is in IETF Last Call prior to publication as an RFC. It deprecates the use of any version of SSL in favour of TLS 1.2 in the clientHello negotiations. Tom Taylor From joly at punkcast.com Tue Mar 31 07:40:37 2015 From: joly at punkcast.com (Joly MacFie) Date: Tue, 31 Mar 2015 03:40:37 -0400 Subject: WEBCAST TODAY: NEDAS NYC In-Building Wireless Summit Message-ID: FYI, I will webcast the NENAS NYC Summit today. What: NEDAS NYC In-Building Wireless Summit When: Tuesday, March 31, 2015 9am-5pm EDT | 1300-2100 UTC Agenda: https://www.nedas.com/events/nedas-nyc-spring-building-wireless-summit-agenda Webcast: https://new.livestream.com/internetsociety/nedasnyc -- --------------------------------------------------------------- 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 florian at figula.de Tue Mar 31 09:45:37 2015 From: florian at figula.de (Florian Figula) Date: Tue, 31 Mar 2015 11:45:37 +0200 Subject: Experience Brocade ICX7750 and other vendor SFP Message-ID: <43F351B8-612A-44DD-BFFF-1D65F86E7427@figula.de> Hi all, does anyone have experiences regarding Brocade ICX7750 and other vendors SFP. Information will be helpful for planing new infrastructure and costs. Thanks to all! Greets, Florian From jordan-medlen at bisk.com Tue Mar 31 12:08:34 2015 From: jordan-medlen at bisk.com (Jordan Medlen) Date: Tue, 31 Mar 2015 12:08:34 +0000 Subject: Experience Brocade ICX7750 and other vendor SFP In-Reply-To: <43F351B8-612A-44DD-BFFF-1D65F86E7427@figula.de> References: <43F351B8-612A-44DD-BFFF-1D65F86E7427@figula.de> Message-ID: I use the ICX 6610's which I believe run the same code train. I use other vendor optics to light 3 spans of dark fiber, one of which is 60km, so I have Axiom 80km optics in production there. I have had no issues. I also use the VDX series switches with other vendor optics and no issues. Jordan Medlen Network Engineer Bisk Education Sent from my iPhone > On Mar 31, 2015, at 05:55, Florian Figula wrote: > > Hi all, > > does anyone have experiences regarding Brocade ICX7750 and other vendors SFP. > > Information will be helpful for planing new infrastructure and costs. > > Thanks to all! > > > Greets, > > Florian > From jmcleod at musfiber.net Tue Mar 31 12:44:17 2015 From: jmcleod at musfiber.net (Joe McLeod) Date: Tue, 31 Mar 2015 12:44:17 +0000 Subject: Experience Brocade ICX7750 and other vendor SFP In-Reply-To: References: <43F351B8-612A-44DD-BFFF-1D65F86E7427@figula.de> Message-ID: +1 on Brocade ICX 6610 with other vendor's optics. We're using the 6610's as aggregation route/switches with a mix of Cisco, Alcatel, and 3rd party optics (one of which is a 10G BiDi) and have had no issues. Thanks, Joe -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jordan Medlen Sent: Tuesday, March 31, 2015 8:09 AM To: Florian Figula Cc: nanog at nanog.org Subject: Re: Experience Brocade ICX7750 and other vendor SFP I use the ICX 6610's which I believe run the same code train. I use other vendor optics to light 3 spans of dark fiber, one of which is 60km, so I have Axiom 80km optics in production there. I have had no issues. I also use the VDX series switches with other vendor optics and no issues. Jordan Medlen Network Engineer Bisk Education Sent from my iPhone > On Mar 31, 2015, at 05:55, Florian Figula wrote: > > Hi all, > > does anyone have experiences regarding Brocade ICX7750 and other vendors SFP. > > Information will be helpful for planing new infrastructure and costs. > > Thanks to all! > > > Greets, > > Florian > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From olivier.benghozi at wifirst.fr Tue Mar 31 13:13:08 2015 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Tue, 31 Mar 2015 15:13:08 +0200 Subject: Experience Brocade ICX7750 and other vendor SFP In-Reply-To: References: <43F351B8-612A-44DD-BFFF-1D65F86E7427@figula.de> Message-ID: <85D070E1-B6DC-4143-BE67-946846B5D999@wifirst.fr> I don't know if ICX behave like the FCX, but on those equipments, other_vendor_SFPs work perfectly (Finisar, Skylane CWDM 70km, at least). However the brocade won't let you use "optical-monitor" on them if they are "standard coded", so you won't be able to check optical values (tx/rx dBm levels and so on). Having the other_vendor_SFP coded as a "Brocade SFP" will do the trick however. > Le 31 mars 2015 à 14:44, Joe McLeod a écrit : > > +1 on Brocade ICX 6610 with other vendor's optics. We're using the 6610's as aggregation route/switches with a mix of Cisco, Alcatel, and 3rd party optics (one of which is a 10G BiDi) and have had no issues. > > Thanks, > Joe > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jordan Medlen > Sent: Tuesday, March 31, 2015 8:09 AM > To: Florian Figula > Cc: nanog at nanog.org > Subject: Re: Experience Brocade ICX7750 and other vendor SFP > > I use the ICX 6610's which I believe run the same code train. I use other vendor optics to light 3 spans of dark fiber, one of which is 60km, so I have Axiom 80km optics in production there. I have had no issues. I also use the VDX series switches with other vendor optics and no issues. > > Jordan Medlen > Network Engineer > Bisk Education > > Sent from my iPhone > >> On Mar 31, 2015, at 05:55, Florian Figula wrote: >> >> Hi all, >> >> does anyone have experiences regarding Brocade ICX7750 and other vendors SFP. >> >> Information will be helpful for planing new infrastructure and costs. >> >> Thanks to all! From mehmet at akcin.net Tue Mar 31 17:19:11 2015 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 31 Mar 2015 20:19:11 +0300 Subject: Usage data from Turkey Message-ID: Hello Today March 31 , 2015 GMT +0200 1030am-4pm Turkey has suffered a major power outage impacting nearly 70M people. I am writing a blog post about power outage vs impact to network usage. I am looking for as much as useful network usage information possible related to Turkey. If you can share network usage information, i will be making sure to buy you some drinks at next nanog ;) Cheers Mehmet From colinj at gt86car.org.uk Tue Mar 31 17:22:18 2015 From: colinj at gt86car.org.uk (Colin Johnston) Date: Tue, 31 Mar 2015 18:22:18 +0100 Subject: Usage data from Turkey In-Reply-To: References: Message-ID: <21A9E7E8-45FB-4B7D-A7E6-1BC766D2A26C@gt86car.org.uk> use ripe atlas info :) Colin > On 31 Mar 2015, at 18:19, Mehmet Akcin wrote: > > Hello > > Today March 31 , 2015 GMT +0200 1030am-4pm Turkey has suffered a major power outage impacting nearly 70M people. I am writing a blog post about power outage vs impact to network usage. I am looking for as much as useful network usage information possible related to Turkey. > > If you can share network usage information, i will be making sure to buy you some drinks at next nanog ;) > > Cheers > > Mehmet From jared at puck.Nether.net Tue Mar 31 17:24:22 2015 From: jared at puck.Nether.net (Jared Mauch) Date: Tue, 31 Mar 2015 13:24:22 -0400 Subject: Usage data from Turkey In-Reply-To: References: Message-ID: <20150331172422.GA12990@puck.nether.net> On Tue, Mar 31, 2015 at 08:19:11PM +0300, Mehmet Akcin wrote: > Hello > > Today March 31 , 2015 GMT +0200 1030am-4pm Turkey has suffered a major power outage impacting nearly 70M people. I am writing a blog post about power outage vs impact to network usage. I am looking for as much as useful network usage information possible related to Turkey. > You may want to look at the RIPE Atlas project, they jsut did a similar thing on the power outage in The Netherlands. - 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 jmcleod at musfiber.net Tue Mar 31 17:37:04 2015 From: jmcleod at musfiber.net (Joe McLeod) Date: Tue, 31 Mar 2015 17:37:04 +0000 Subject: Experience Brocade ICX7750 and other vendor SFP In-Reply-To: <85D070E1-B6DC-4143-BE67-946846B5D999@wifirst.fr> References: <43F351B8-612A-44DD-BFFF-1D65F86E7427@figula.de> <85D070E1-B6DC-4143-BE67-946846B5D999@wifirst.fr> Message-ID: That is true for the ICX as well. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Olivier Benghozi Sent: Tuesday, March 31, 2015 9:13 AM To: nanog at nanog.org Subject: Re: Experience Brocade ICX7750 and other vendor SFP I don't know if ICX behave like the FCX, but on those equipments, other_vendor_SFPs work perfectly (Finisar, Skylane CWDM 70km, at least). However the brocade won't let you use "optical-monitor" on them if they are "standard coded", so you won't be able to check optical values (tx/rx dBm levels and so on). Having the other_vendor_SFP coded as a "Brocade SFP" will do the trick however. > Le 31 mars 2015 à 14:44, Joe McLeod a écrit : > > +1 on Brocade ICX 6610 with other vendor's optics. We're using the 6610's as aggregation route/switches with a mix of Cisco, Alcatel, and 3rd party optics (one of which is a 10G BiDi) and have had no issues. > > Thanks, > Joe > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jordan > Medlen > Sent: Tuesday, March 31, 2015 8:09 AM > To: Florian Figula > Cc: nanog at nanog.org > Subject: Re: Experience Brocade ICX7750 and other vendor SFP > > I use the ICX 6610's which I believe run the same code train. I use other vendor optics to light 3 spans of dark fiber, one of which is 60km, so I have Axiom 80km optics in production there. I have had no issues. I also use the VDX series switches with other vendor optics and no issues. > > Jordan Medlen > Network Engineer > Bisk Education > > Sent from my iPhone > >> On Mar 31, 2015, at 05:55, Florian Figula wrote: >> >> Hi all, >> >> does anyone have experiences regarding Brocade ICX7750 and other vendors SFP. >> >> Information will be helpful for planing new infrastructure and costs. >> >> Thanks to all! -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From lists.nanog at monmotha.net Tue Mar 31 20:06:23 2015 From: lists.nanog at monmotha.net (Brandon Martin) Date: Tue, 31 Mar 2015 16:06:23 -0400 Subject: Experience Brocade ICX7750 and other vendor SFP In-Reply-To: References: <43F351B8-612A-44DD-BFFF-1D65F86E7427@figula.de> <85D070E1-B6DC-4143-BE67-946846B5D999@wifirst.fr> Message-ID: <551AFE3F.1080904@monmotha.net> On 03/31/2015 01:37 PM, Joe McLeod wrote: > That is true for the ICX as well. As far as I know, all of the Brocade gear that traces its lineage to Foundry will attempt to work with any SFP/SPF+/etc., but you may or may not get the ability to use the live optical monitoring option as has been mentioned earlier in the thread. This appears to (should) include the entire Fastiron and Netiron family and the ICX families. I've brought this question up with my SE in the past, and the response I've gotten is that there is no intent to change this, but they reserve the right to deny support for anything believed optic related unless you have 1st-party optics. The conclusion we both reached was that, if you want to use 3rd-party optics, it's not a bad idea to have a couple suitable "spares" that are 1st-party on hand to test with. Gear that traces its lineage to Brocade is not always so forgiving. I know the converged NICs will refuse to work with non-Brocade optics, as supposedly will their Fibre Channel switches. I'm not sure where the VDX line ends up in this. It's apparently somewhat the result of actually merging the two technology lines, and it runs somewhat different software as a result. A lot of the 3rd party optic vendors will re-code for either no or some nominal charge, so that's always an option. According to the Brocade SE I talked to, generally either it works up front (99% of the time) and has comparable reliability to 1st-party optics, or it has essentially immediate problems, so you know to do something about it. Personally, I've used non-Brocade/non-Foundry optics on various platforms (mostly Foundry era) with no real problems aside from the loss of optic monitoring. Foundry and Brocade source them from various OEMs, seemingly whoever is cheap that day, so this isn't surprising. -- Brandon Martin